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),非常欢迎大家积极投稿。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181103G1MBS000?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券