HBase技术与应用实践 | HBase在爱奇艺的应用实践

本次分享来自中国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+

  • 服务使用架构

    • 私有云环境

    • 大数据平台化服务

    • 大数据产品栈

• 数据库@iQIYI 产品定位

• • 按访问模式：NoSQL -> SQL

    • schema

    • 访问接口

    • ACID

  • 按应用场景：OLTP -> HTAP -> OLAP

    • 目的：交易处理 vs 数据分析

    • 延时：ms vs s/m

  • 按分布式系统特点

    • 可扩展性 CAP

    • QPS量级：10K vs 10M

    • 数据量：GB vs TB/PB

• [email protected] 产品定位
  

• • 大数据产品应用场景

    • 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小时写入的数据

    • 非重复读，每条数据只会访问一次

  • 优化

    • 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单集群多租户

    • 硬件资源利用率高

    • 部署管理方便

    • 隔离性差

  • 策略

    • 定义资源：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

• 模板化建表

• • 表定期整理

    • 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

  • 启动过程中，部分节点阻塞影响恢复

    • 及时处理启动过程中阻塞节点

    • 启动恢复过程中，停止业务访问(需要一种安全模式)