HBase在爱奇艺的应用实践

本次分享来自中国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)，非常欢迎大家积极投稿。