本次分享来自中国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+
- 服务使用架构
- 私有云环境
- 大数据平台化服务
- 大数据产品栈
- HBase版本
- 数据库@iQIYI 产品定位
-
- 按访问模式：NoSQL -> SQL
- schema
- 访问接口
- ACID
- 按应用场景：OLTP -> HTAP -> OLAP
- 目的：交易处理 vs 数据分析
- 延时：ms vs s/m
- 按分布式系统特点
- 可扩展性 CAP
- QPS量级：10K vs 10M
- 数据量：GB vs TB/PB
- 按访问模式：NoSQL -> SQL
- HBase@iQIYI 产品定位
-
- 大数据产品应用场景
- QPS量级 100K以上
- 数据量级 TB ~PB
- 需要计算资源，计算本地性
- 选择HBase的理由
- 大数据场景下的随机访问
- 稀疏动态表，支持百万列
- 适应各计算框架
- 实时跨集群同步
- 稳定易扩展，现有集群规模大，能支持更大量级
- 大数据产品应用场景
- 应用场景
2.架构实践
- 架构概览
-
- 3-4个主力DC
- 业务分流
- 运营商
- HA
- HBase相关集群分类
- 公共集群
- Kylin HBase集群
- HBase专用集群
- 业务独立集群
- 3-4个主力DC
- 公共集群
-
- 场景
- 1000+节点
- 用于大规模数据计算
- 亚秒延时、单表10M qps
- 架构
- 拆分ZooKeeper
- 分离Kylin
- 异构存储 WAL-on-SSD
- BucketCache 20G offheap
- 非实时访问禁用BlockCache
- 场景
- HBase专用集群
-
- 场景
- 100节点
- 线上实时访问，简单OLAP分析
- 150ms以下延时，均值50ms
- 架构
- SSD
- 场景
-
- 场景
- 10-50节点
- 用于业务特定需求
- 案例-Flink流关联
- 全量消息，数据量大，需5ms以下延时
- 写入足够分散，无更新特性
- 91.52%读最近1小时写入的数据
- 非重复读，每条数据只会访问一次
- 优化
- 7天TTL，2备份，压缩后150TB
- cache索引，cache_data_on_write 缓存最近数据
- 读不替换缓存，减少缓存置换开销
- compactionThreshold + compaction.max.size +BloomFilter 缩小随机访问范围，减少compaction压力
- 7天TTL，2备份，压缩后150TB
- 场景
- 数据同步
-
- 同步管理
- 表级别控制
- 定义同步链路
- 表同步设置
- 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包版本
- 需要持续关注社区release、patch
3.服务策略
- 向业务提供服务的策略
- HBase单集群多租户
- 硬件资源利用率高
- 部署管理方便
- 隔离性差
- 策略
- 定义资源：HBase表
- 集群容量：空间大小、region总数
- 提供方式：模板化建表
- 资源隔离性：尽可能确保各表健康
- HBase单集群多租户
- 资源与配额
-
-
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生态+Spark社区大群”点击加入：
dwz.cn/Fvqv066s