本次分享来自中国HBase技术社区第七届MeetUp成都站,分享嘉宾郑浩南 爱奇艺 资深研发工程师,专注于大数据领域,负责Hadoop服务的运维研究以及DevOps平台开发。
分享主题:HBase在爱奇艺的应用实践
内容概要:随着大数据存储计算对延时吞吐要求越来越高,需求日益复杂化,HBase在爱奇艺中被广泛应用和实践以应对多样化的业务场景。本次演讲将介绍HBase在爱奇艺的部署模式和使用场景,以及在爱奇艺私有云环境下的运维策略。
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小时写入的数据
非重复读,每条数据只会访问一次
优化
数据同步
同步管理
表级别控制
定义同步链路
表同步设置
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问题
启动过程中,部分节点阻塞影响恢复
及时处理启动过程中阻塞节点
启动恢复过程中,停止业务访问(需要一种安全模式)
大家工作学习遇到HBase技术问题,把问题发布到HBase技术社区论坛http://hbase.group,欢迎大家论坛上面提问留言讨论。想了解更多HBase技术关注HBase技术社区公众号(微信号:hbasegroup),非常欢迎大家积极投稿。
领取专属 10元无门槛券
私享最新 技术干货