HBase 在爱奇艺的应用实践

本次分享来自中国HBase技术社区第七届MeetUp成都站，分享嘉宾郑浩南 爱奇艺 资深研发工程师，专注于大数据领域，负责Hadoop服务的运维研究以及DevOps平台开发。
分享主题：HBase在爱奇艺的应用实践

内容概要：随着大数据存储计算对延时吞吐要求越来越高，需求日益复杂化，HBase在爱奇艺中被广泛应用和实践以应对多样化的业务场景。本次演讲将介绍HBase在爱奇艺的部署模式和使用场景，以及在爱奇艺私有云环境下的运维策略。

下载链接： http://hbase.group/slides/168

1.使用现状

• 概况

  

• HBase版本

• 1.2.0-CDH5.14.4-qiyi-1

• 规模

• 物理机数量6000+，最大集群1500节点

• 数据总量约3PB（单备份），大表>100TB

• 离线QPS 50 Mil+，线上QPS 3 Mil+

• 服务使用架构

• 私有云环境

• 大数据平台化服务

• 大数据产品栈

• 数据库@iQIYI 产品定位

  

• 按访问模式：NoSQL -> SQL

• schema

• 访问接口

• ACID

• 按应用场景：OLTP -> HTAP -> OLAP

• 目的：交易处理 vs 数据分析

• 延时：ms vs s/m

• 按分布式系统特点

• 可扩展性 CAP

• QPS量级：10K vs 10M

• 数据量：GB vs TB/PB

• HBase@iQIYI 产品定位

  

• 大数据产品应用场景

• QPS量级 100K以上

• 数据量级 TB ~PB

• 需要计算资源，计算本地性

• 选择HBase的理由

• 大数据场景下的随机访问

• 稀疏动态表，支持百万列

• 适应各计算框架

• 实时跨集群同步

• 稳定易扩展，现有集群规模大，能支持更大量级

• 应用场景

  

2.架构实践

• 架构概览

  

• 3-4个主力DC

• 业务分流

• 运营商

• HA

• HBase相关集群分类

• 公共集群

• Kylin HBase集群

• HBase专用集群

• 业务独立集群

• 公共集群

  

• 场景

• 1000+节点

• 用于大规模数据计算

• 亚秒延时、单表10M qps

• 架构

• 拆分ZooKeeper 

• 分离Kylin

• 异构存储 WAL-on-SSD

• BucketCache 20G offheap

• 非实时访问禁用BlockCache

• HBase专用集群

  

• 场景

• 100节点

• 线上实时访问，简单OLAP分析

• 150ms以下延时，均值50ms

• 架构

• SSD

两备份（计算本地性要求低，HA）

• BucketCache 50G offheap

• 控制计算任务执行

• 分离线上访问-计算分析

• Phoenix：SQL、二级索引、Salt

• 调研中：Solr+JanusGraph  Atalas

• 业务独立集群

  

• 场景

• 10-50节点

• 用于业务特定需求

• 案例-Flink流关联

• 全量消息，数据量大，需5ms以下延时

• 写入足够分散，无更新特性

• 91.52%读最近1小时写入的数据

• 非重复读，每条数据只会访问一次

• 优化

• 7天TTL，2备份，压缩后150TB

• cache索引，cache_data_on_write 缓存最近数据

• 读不替换缓存，减少缓存置换开销

• compactionThreshold + compaction.max.size +BloomFilter

  缩小随机访问范围，减少compaction压力

• 数据同步

  

• 同步管理

• 表级别控制

• 定义同步链路

• 表同步设置

• export snapshort 

• 目标表设置purge.deletes（24h）

• 设置表同步

• copyTable补数据

• 定期一致性检查

• 基于ReplicationCompare改造

• 迭代多轮比较，验证最终一致性

• 监控

  

• 统计型排查

• 整合关键指标

• 集群整体->服务器、表

• 子维度 排序 、展开详情

• 拨测

• 表分布到每个RS，put/get

• 表RowCounter检查

• 指标存储

• OpenTSDB + InfluxDB

• 长时间、高基数聚合慢

  转型使用Druid

• 升级策略

  

• 需要持续关注社区release、patch

• 升级历程：5.2.0→5.11.0→5.14.2→5.14.4

• 5.11.0 HBase bugs：CDH-55446、HBase-17319、17069…

• 版本管理

• CDH Major、Minor、Maintenance 升级

• QIYI Maintenance ：5.14.4-qiyi-1

• 源码开发、发布、部署

• Gitlab管理源码，比较各release分支

• 维护QIYI内部版本，发布到maven

• 复用CDH rpm包

  ansible maven_artifact模块指定jar包版本

3.服务策略

• 向业务提供服务的策略

• HBase单集群多租户

• 硬件资源利用率高

• 部署管理方便

• 隔离性差

• 策略

• 定义资源：HBase表

• 集群容量：空间大小、region总数

• 提供方式：模板化建表

• 资源隔离性：尽可能确保各表健康

• 资源与配额

  

• HBase表资源

• Default namespace

• 未使用RS group

• 通过平台工单申请，控制建表

• 线上统一控制DDL、权限操作

• 健康检查，确保表均匀无热点

• 配额定义

• 集群资源总容量

• 部门配额

• 资源分配配额

• 资源实际使用量

• 压测与容量

  

• 确定Space容量

• /hbase目录的总Quota

• 确定Region容量

• 根据Memstore估算大概范围

• 单节点压测，HBase pe，估算最佳region数、最佳并发数、读写峰值

  300个region，64并发数

  随机读 78K，  随机写 231K

  顺序读 133K，顺序写 426K

• 300/RS，每个region容量：5~20GB

  读qps 0.26K~0.6K， 写qps 0.77K~1.5K

• 模板化建表

  

• 确定应用场景

• 选择集群类型

• 运行计算任务、实时访问、线上业务…

• 关键表属性设置

• 用户确定Version、TTL、同步链路

• 自动设置BlockCache、MOB、分裂策略、压缩等

• 确定表预分区方法

• 16进制字符串、10进制字符串、采样

• 配额

• 数据量估算+峰值qps，推算Region数量

• 用户可以只给出数据量估算

• 定期整理与健康度检查

  

• 表定期整理

• major compact

• 自定义normalize

• balance

• 表健康度检查

• 热点

• 数据倾斜

• 分区数不匹配

4.问题瓶颈

• ZooKeeper重选，RS重连超时

• 问题：

• ZooKeeper发生重选时，Session重连，RegionServer发生ZK sessionTimeout宕机

• ZooKeeper Zxid rollover，定期引发重选

• 连接数过多，单个ZK-server 5000个连接

• 限制maxClientCnxns，找出错误使用HBase Conn任务

• Znode过多，25w个

• 定期清理Replication残留Znode

• ZooKeeper关闭连接时的瓶颈

• ZOOKEEPER-1669，HashSet并发瓶颈

• ZooKeeper Leader session激活（revalidation）瓶颈

• ZOOKEEPER-3169，未解决，通过调高max session timeout应对

• 减少对ZooKeeper依赖

• 调研：ZK-less，AssignmentMananger v2

• HBase启动恢复慢

• 问题：

• 1500节点，25w region

• clean-startup 15min；主动关闭集群，经常无法正常进入clean-startup

• 恢复流程需要1 hour左右

• 错误判定为恢复流程

• HBASE-14223，清理残留的Meta WALs

• HBASE-15251，错误判断为failover

• SplitWAL ZK阻塞

• 参考HBASE-19290，调节RS遍历Znode停顿时间

• SplitWAL并发控制，易引起gc问题

• master.executor.serverops.threads x bulk.assignment.threadpool.size

• 启动过程中，部分节点阻塞影响恢复

• 及时处理启动过程中阻塞节点

• 启动恢复过程中，停止业务访问(需要一种安全模式)

大家工作学习遇到HBase技术问题，把问题发布到HBase技术社区论坛http://hbase.group，欢迎大家论坛上面提问留言讨论。想了解更多HBase技术关注HBase技术社区公众号(微信号:hbasegroup)，非常欢迎大家积极投稿。