HBase技术与应用实践 | HBase在爱奇艺的应用实践
本次分享来自中国HBase技术社区第七届MeetUp成都站，分享嘉宾郑浩南 爱奇艺 资深研发工程师，专注于大数据领域，负责Hadoop服务的运维研究以及DevOps平台开发。
分享主题：HBase在爱奇艺的应用实践
内容概要：随着大数据存储计算对延时吞吐要求越来越高，需求日益复杂化，HBase在爱奇艺中被广泛应用和实践以应对多样化的业务场景。本次演讲将介绍HBase在爱奇艺的部署模式和使用场景，以及在爱奇艺私有云环境下的运维策略。
下载链接：http://hbase.group/slides/168
1.使用现状
概况
私有云环境
大数据平台化服务
大数据产品栈
物理机数量6000+，最大集群1500节点
数据总量约3PB（单备份），大表>100TB
离线QPS 50 Mil+，线上QPS 3 Mil+
1.2.0-CDH5.14.4-qiyi-1
HBase版本
规模
服务使用架构
数据库@iQIYI 产品定位
可扩展性 CAP
QPS量级：10K vs 10M
数据量：GB vs TB/PB
目的：交易处理 vs 数据分析
延时：ms vs s/m
schema
访问接口
ACID
按访问模式：NoSQL -> SQL
按应用场景：OLTP -> HTAP -> OLAP
按分布式系统特点
HBase@iQIYI 产品定位
大数据场景下的随机访问
稀疏动态表，支持百万列
适应各计算框架
实时跨集群同步
稳定易扩展，现有集群规模大，能支持更大量级
QPS量级 100K以上
数据量级 TB ~PB
需要计算资源，计算本地性
大数据产品应用场景
选择HBase的理由
应用场景
2.架构实践
架构概览
公共集群
Kylin HBase集群
HBase专用集群
业务独立集群
业务分流
运营商
HA
3-4个主力DC
HBase相关集群分类
公共集群
拆分ZooKeeper
分离Kylin
异构存储 WAL-on-SSD
BucketCache 20G offheap
非实时访问禁用BlockCache
1000+节点
用于大规模数据计算
亚秒延时、单表10M qps
场景
架构
HBase专用集群
SSD
100节点
线上实时访问，简单OLAP分析
150ms以下延时，均值50ms
场景
架构
两备份（计算本地性要求低，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表
集群容量：空间大小、region总数
提供方式：模板化建表
资源隔离性：尽可能确保各表健康
硬件资源利用率高
部署管理方便
隔离性差
HBase单集群多租户
策略
资源与配额
集群资源总容量
部门配额
资源分配配额
资源实际使用量
Default namespace
未使用RS group
通过平台工单申请，控制建表
线上统一控制DDL、权限操作
健康检查，确保表均匀无热点
HBase表资源
配额定义
压测与容量
根据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
/hbase目录的总Quota
确定Space容量
确定Region容量
模板化建表
数据量估算+峰值qps，推算Region数量
用户可以只给出数据量估算
16进制字符串、10进制字符串、采样
用户确定Version、TTL、同步链路
自动设置BlockCache、MOB、分裂策略、压缩等
选择集群类型
运行计算任务、实时访问、线上业务…
确定应用场景
关键表属性设置
确定表预分区方法
配额
定期整理与健康度检查
热点
数据倾斜
分区数不匹配
major compact
自定义normalize
balance
表定期整理
表健康度检查
4.问题瓶颈
ZooKeeper重选，RS重连超时
调研：ZK-less，AssignmentMananger v2
ZOOKEEPER-3169，未解决，通过调高max session timeout应对
ZOOKEEPER-1669，HashSet并发瓶颈
定期清理Replication残留Znode
限制maxClientCnxns，找出错误使用HBase Conn任务
ZooKeeper发生重选时，Session重连，RegionServer发生ZK sessionTimeout宕机
ZooKeeper Zxid rollover，定期引发重选
问题：
连接数过多，单个ZK-server 5000个连接
Znode过多，25w个
ZooKeeper关闭连接时的瓶颈
ZooKeeper Leader session激活（revalidation）瓶颈
减少对ZooKeeper依赖
HBase启动恢复慢
及时处理启动过程中阻塞节点
启动恢复过程中，停止业务访问(需要一种安全模式)
master.executor.serverops.threads x bulk.assignment.threadpool.size
参考HBASE-19290，调节RS遍历Znode停顿时间
HBASE-14223，清理残留的Meta WALs
HBASE-15251，错误判断为failover
1500节点，25w region
clean-startup 15min；主动关闭集群，经常无法正常进入clean-startup
恢复流程需要1 hour左右
问题：
错误判定为恢复流程
SplitWAL ZK阻塞
SplitWAL并发控制，易引起gc问题
启动过程中，部分节点阻塞影响恢复
©著作权归作者所有：来自51CTO博客作者mb5fdb0a6739180的原创作品，如需转载，请注明出处，否则将追究法律责任