深入浅出 HBase 实战 | 青训营笔记

Rainbow_Sea
71 阅读14分钟

这是我参与「第四届青训营 」笔记创作活动的的第10天

今天是大数据专场基础班的第十次课，主要内容是深入浅出 HBase 实战，主要分为下面四个板块。

一、 适用场景

1. 什么是 HBase ?

  • HBase是一个开源的NoSQL分布式数据库，是 Apache 软件基金会顶级项目之一
  • 参考Google BigTable的设计，对稀疏表提供更高的存储空间使用率和读写效率
  • 采用存储计算分离架构
    • 存储层基于HDFS存储数据，提供容错机制和高可靠性
    • 计算层提供灵活快速的水平扩展、负载均衡和故障恢复能力
  • 提供强─致语义，在CAP理论中属于CP系统
    • Consistency，Availability，Partition Tolerance

2. HBase和关系型数据库的区别

image.png

3. HBase 数据模型

  • HBase 以列族（column family)为单位存储数据，以行键(rowkey)索引数据
    • 列族需要在使用前预先创建，列名(column qualifier)不需要预先声明，因此支持半结构化数据模型
    • 支持保留多个版本的数据，(行键＋列族＋列名＋版本号）定位一个具体的值

image.png

3.1 逻辑结构

image.png

  • 通过非关系型视图理解HBase数据模型:
    • 适合稀疏数据，缺省列不占用存储空间
    • 通过(rowkey, column family, column qualifier, version)
    • 唯一指定一个具体的值
    • 允许批量读取多行的部分列族/列数据

3.2 物理结构

  • 物理数据结构最小单元是KeyValue结构:
    • 每个版本的数据都携带全部行列信息
    • 同一行，同一列族的数据物理上连续有序存储
    • 同列族内的KeyValue按rowkey字典序升序，column qualifier升序，version降序排列
    • 不同列族的数据存储在相互独立的物理文件，列族间不保证数据全局有序
    • 同列族下不同物理文件间不保证数据全局有序
    • 仅单个物理文件内有序

image.png

image.png

4. 使用场景

  • 适用场景:
    • “近在线”的海量分布式KV/宽表存储，数据量级可达到PB级以上
    • 写密集型、高吞吐应用，可接受一定程度的时延抖动
    • 字典序主键索引、批量顺序扫描多行数据的场景
    • Hadoop大数据生态友好兼容
    • 半结构化数据模型，行列稀疏的数据分布，动态增减列名
    • 敏捷平滑的水平扩展能力，快速响应数据体量、流量变化

4.1 使用场景-典型应用

  • 典型应用:
    • 电商订单数据:查询最新/待处理订单进度
    • 搜索推荐引擎:存储原始数据、排序推荐结果
    • 广告数据流:触达、点击、转化等事件流
    • 用户交互数据:IM、Email、点赞、搜索
    • 时序数据引擎:日志、监控(OpenTSDB)
    • 图存储引擎:JanusGraph
    • 大数据生态:高度融入Hadoop生态

image.png

4.2 使用场景-半结构化/字典序有序索引的数据

  • 典型用例:
    • 字节跳动推荐中台基于HBase提供“近在线”读写的推荐候选数据集
  • 数据格式:

image.png

  • 查询模式:
    • 批量查询指定tenantID租户的制定channellD频道下的推荐候选集。例如:
    • start rowkey: "part1:tenant1:channel1",
    • end rowkey: "part1:tenant1:channel2",
  • 对应数据:
    • value: "features (e.g. sport, basketball,...)”
    • columns: "additional labels (e.g. region=CN,...)”

4.3 使用场景-“近在线”海量分布式KV/宽表存储

  • 典型用例:
    • 商家订单系统使用HBase管理买家、卖家的订单操作信息
  • 查询模式:
    • 查询指定orderlID订单最近新增/待处理的操作记录。例如:
    • rowkey: "e1cb:orderlD1", column family: "customer"
  • 对应多个column的数据:
    • column1: actionType1_actionID1, value1: "{timestamp=21, action='..."l",
    • column2: actionType2_actionID2, value2: "{timestamp=26, action='...'}",
    • column3: checkpoint,value:"timestamp=23”

4.4 使用场景–写密集型的高吞吐场景

  • 典型用例:
    • 时序存储引擎，典型场景是日志、监控数据存储，例如OpenTSDB (Open Time Series Database)
  • 查询模式:
    • 查询指定metric_uid指标在指定时间段的所有数据，例如:
    • start rowkey: "[hash]metric1:1655386954”,
    • end rowkey:"[hash]metric1:1665386954”,
    • column_family: "dp",
    • 查询1655386954到1665386954时间内该监控的所有数据点 rowkey和column通过编码尽量简短，减少空间用量

5. HBase数据模型的优缺点

image.png

二、 架构设计

1. HBase架构设计

  • 主要组件包括:
    • HMaster:元数据管理，集群调度、保活
    • RegionServer:提供数据读写服务，每个实例负责若干个互不重叠的rowkey区间内的数据
    • ThriftServer:提供Thrift API读写的代理层
  • 依赖组件包括:
    • Zookeeper:分布式一致性共识协作管理，例如HMaster 选主、任务分发、元数据变更管理等
    • HDFS:分布式文件系统，HBase数据存储底座

image.png

2. Hmaster

image.png

2.1 Hmaster-主要职责

  • 管理RegionServer 实例生命周期，保证服务可用性
  • 协调RegionServer 数据故障恢复，保证数据正确性
  • 集中管理集群元数据，执行负载均衡等维护集群稳定性
  • 定期巡检元数据，调整数据分布，清理废弃数据等
  • 处理用户主动发起的元数据操作如建表、删表等

2.2 HMaster-主要组件

  • ActiveMasterManager:管理HMaster的active/backup状态

  • ServerManager:管理集群内RegionServer的状态

  • AssignmentManager:管理数据分片(region)的状态

  • SplitWalManager:负责故障数据恢复的WAL拆分工作

  • LoadBalancer:定期巡检、调整集群负载状态

  • RegionNormalizer:定期巡检并拆分热点、整合碎片

  • CatalogJanitor:定期巡检、清理元数据

  • Cleaners:定期清理废弃的HFile / WAL等文件

  • MasterFileSystem:封装访问HDFS的客户端 SDK

3. RegionServer

image.png

3.1 RegionServer-主要职责

  • 提供部分rowkey 区间数据的读写服务
  • 如果负责meta表，向客户端 SDK提供rowkey位置信息
  • 认领HMaster 发布的故障恢复任务，帮助加速数据恢复过程
  • 处理HMaster下达的元数据操作，如region打开/关闭/分裂/合并操作等

3.2 RegionServer-主要组件

  • MemStore:基于SkipList数据结构实现的内存态存储，定期批量写入硬盘
  • Write-Ahead-Log:顺序记录写请求到持久化存储，用于故障恢复内存中丢失的数据
  • Store:对应一个 Column Family在一个region下的数据集合，通常包含多个文件
  • StoreFile:即HFile，表示 HBase在 HDFS存储数据的文件格式，其内数据按rowkey字典序有序排列
  • BlockCache: HBase以数据块为单位读取数据并缓存在内存中以加速重复数据的读取

4. ZooKeeper主要职责

  • HMaster登记信息，对active/backup 分工达成共识
  • RegionServer 登记信息，失联时HMaster保活处理
  • 登记meta表位置信息，供SDK查询读写位置信息
  • 供HMaster 和RegionServer 协作处理分布式任务

image.png

5. ThriftServer主要职责

  • 实现 HBase定义的Thrift API，作为代理层向用户提供RPC读写服务
  • 用户可根据IDL自行生成客户端实现
  • 独立于RegionServer 水平扩展，用户可访问任意ThriftServer 实例(scan操作较特殊，需要同实例维护scan状态)

image.png

三、 大数据支撑

1. HBase在大数据生态的定位

  • 对TB、PB级海量数据支持强一致、近实时的读写性能，支持快速的ad-hoc分析查询任务
  • 支持字典序批量扫描大量数据，支持只读取部分列族的数据，灵活支持不同查询模式，避免读取不必要的数据
  • 存储大规模任务（例如MapReduce，Spark，Flink)的中间/最终计算结果
  • 平滑快速的水平扩展能力，能够敏捷应对大数据场景高速增长的数据体量和大规模的并发访问
  • 精细化的资源成本控制，计算层和存储层分别按需扩展，避免资源浪费

2. 水平扩展能力

  • 增加RegionServer 实例，分配部分region 到新实例
  • 扩展过程平滑，无需搬迁实际数据
  • 可用性影响时间很短，用户基本无感知

image.png

3. Region热点切分

  • 当某个region数据量过多，切分成两个独立的子region分摊负载
  • RegionServer在特定时机(flush、compaction)检查region是否应该切分，计算切分点并RPC上报HMaster，由AssignmentManager负责执行RegionStateTransition
  • 不搬迁实际数据，切分产生的新 region 数据目录下生成一个以原region文件信息命名的文件，内容是切分点对应的rowkey，以及标识新region是上/下半部分的数据

3.1 Region热点切分–切分点选取

  • HBase原生提供的多种切分策略使用相同的切分点选择策略
  • 目标:优先把最大的数据文件均匀切分
  • 切分点选择步骤:
    1. 找到该表中哪个region的数据大小最大
    2. 找到该region内哪个column family的数据大小最大
    3. 找到column family内哪个HFile的数据大小最大
    4. 找到HFile里处于最中间位置的Data Block
    5. 用这个Data Block的第一条 KeyValue 的Rowkey 作为切分点

3.2 Region 热点切分–切分过程

  • 所有Column Family都按照统一的切分点来切分数据。
  • 目的是优先均分最大的文件，不保证所有Column Family 的所有文件都被均分。
  • HFile 1作为最大的文件被均分，其他文件也必须以相同的rowkey切分以保证对齐新region的rowkey区间

image.png

3.3 Region热点切分–流程设计

  • AssignmentManager检查cluster、table、region的状态后，创建SplitTableRegionProcedure通过状态机实现执行切分过程

image.png

4. Region碎片整合

  • 当某些region 数据量过小、碎片化，合并相邻 region整合优化数据分布
  • AssignmentManager创建MergeTableRegionsProcedure 执行整合操作
  • 不搬迁实际数据，通过reference file定位原region的文件，直到下次compaction时实际处理数据 注意:只允许合并相邻region，否则会打破rowkey空间连续且不重合的约定

4.1 Region 碎片整合–流程设计

  • 类似于region切分，不立刻处理实际数据文件，而是通过创建reference files引用到原文件，然后原子地更新元数据来完成碎片整合，后续靠compaction整合数据文件，靠CatalogJanitor异步巡检元数据处理遗留数据

image.png

5. Region负载均衡

  • 定期巡检各RegionServer上的 region数量，保持region的数量均匀分布在各个RegionServer 上
  • SimpleLoadBalancer具体步骤:
    1. 根据总region数量和RegionServer 数量计算平均region数，设定弹性上下界避免不必要的操作例如默认slop为0.2，平均region数为5，负载均衡的RS 上 region数量应该在[4,6]区间内。
    2. 将RegionServer按照region数量降序排序，对region数量超出上限的选取要迁出的region并按创建时间从新到老排序
    3. 选取出region数量低于下限的RegionServer列表round-robin分配步骤⒉选取的regions，尽量使每个RS的region 数量都不低于下限
    4. 处理边界情况，无法满足所有RS的region数量都在合理范围内时，尽量保持region数量相近 image.png

6. 故障恢复机制– HMaster

HMaster 通过多实例基于Zookeeper选主实现高可用性

  • 所有实例尝试向Zookeeper的/hbaselactive-master l临时节点CAS地写入自身信息
  • 写入成功表示成为主实例，失败即为从实例，通过watch 监听/hbase/active-master节点的变动
  • 主实例不可用时临时节点被删除，此时触发其他从实例重新尝试选主

image.png

6.1 HMaster自身恢复流程

  1. 监听到/hbaselactive-master 临时节点被删除的事件，触发选主逻辑
  2. 选主成功后执行HMaster启动流程，从持久化存储读取未完成的procedures 从之前状态继续执行
  3. 故障HMaster 实例恢复后发现主节点已存在，继续监听/hbaselactive-master

6.2 调度RegionServer的故障恢复流程

  1. AssignmentManager 从 procedure列表中找出Region-In-Transition 状态的region继续调度过程
  2. RegionServerTracker 从Zookeeper梳理 online状态的RegionServer列表，结合ServerCrashProcedure列表HDFS中 WAL目录里alive / splitting 状态的RegionServer记录，获取掉线RegionServer 的列表，分别创建ServerCrashProcedure执行恢复流程

7. 故障恢复机制– RegionServer

  • 每个RegionServer实例启动时都会往Zookeeper的/hbase/rs路径下创建对应的临时节点
  • HMaster通过监听RegionServer在Zookeeper的临时节点状态，监控数据读写服务的可用性，及时调度恢复不可用的regions
  • RegionServer的故障恢复需要将内存中丢失的数据从WAL中恢复，HMaster利用Zookeeper配合所有RegionServer 实例，分布式地处理WAL数据，提升恢复速度

image.png

  • 启动流程:

  1. 启动时去Zookeeper登记自身信息，告知主HMaster实例有新RS实例接入集群

  2. 接收和执行来自HMaster的region调度命令

  3. 打开region前先从 HDFS读取该region 的recovered.edits目录下的WAL记录，回放恢复数据

  4. 恢复完成，认领Zookeeper上发布的分布式任务（如WAL切分）帮助其他数据恢复

8. Distributed Log Split原理

  • 背景:

  1. 写入HBase 的数据首先顺序持久化到Write-Ahead-Log，然后写入内存态的MemStore即完成，不立即写盘，RegionServer故障会导致内存中的数据丢失，需要回放WAL来恢复

  2. 同RegionServer的所有region复用WAL，因此不同region的数据交错穿插，RegionServer故障后重新分配region前需要先按region维度拆分WAL

image.png

8.1 Distributed Log Split原理–具体流程

  • 实现原理:

  1. RegionServer 故障，Zookeeper检测到心跳超时或连接断开，删除对应的临时节点并通知监听该节点的客户端

  2. active HMaster 监听到RS 临时节点删除事件，从 HDFS梳理出该RS负责的WAL文件列表

  3. HMaster为每个WAL文件发布一个log split task到ZK

  4. 其他在线的RS 监听到新任务，分别认领

  5. 将WAL entries按region拆分，分别写入HDFS上该region的recovered.edits目录

  6. HMaster 监听到 log split任务完成，调度region到其他 RS

  7. RS打开region前在HDFS找到先回放recovered.edits目录下的WAL文件将数据恢复到 Memstore里，再打开region恢复读写服务

image.png

8.2 Distributed Log Split原理-优化空间

  • 进—步优化: Distributed Log Replay
    • HMaster 先将故障RegionServer上的所有region以Recovering状态调度分配到其他正常RS上
    • 再进行类似Distributed Log Split的 WAL日志按region维度切分
    • 切分后不写入HDFS，而是直接回放，通过SDK写流程将WAL记录写到对应的新RS
    • Recovering状态的region接受写请求但不提供读服务，直到 WAL回放数据恢复完成

四、 最佳实践

1. Rowkey 设计策略

  • 场景分类
    1. 不需要顺序扫描批量连续rowkey
    • 对原始rowkey做哈希（如MD5)，作为真实rowkey的前缀。建议取适当长度的子串，避免过多占用存储空间
    1. 需要顺序扫描批量连续rowkey
    • 首先用groupIDlapplD/userID前缀避免数据热点，然后加上定义顺序的信息（(如时间戳等)ID前缀也建议哈希处理，避免非预期的热点 e.g.MD5(groupID):groupID:timestamp:...
    1. rowkey长度尽量保持较短，因为会冗余存储到每个KeyValue中 避免用时间戳直接作为rowkey前缀，会导致最新的数据始终集中在单个RegionServer上，造成热点瓶颈，且无法通过水平扩容缓解

2. Column Family 设计策略

  1. Column family数量过多容易影响性能，建议尽量少，不超过5个
  2. 需要同时读取的数据尽量放在相同列族，反之尽量放在不同列族，读取时尽量只读取必需的列族，避免读不必要的列族
  3. 列族（以及column qualifier）名称尽量短，因为会冗余存储到每个KeyValue 中

3. 参数调优经验

image.png

4. ByteTable -字节跳动自研分布式表格存储系统

  • 优势:
  1. 存储层基于字节跳动自研分布式存储底座，从设计上充分支持在线场景的性能、功能需求
  2. 采用C++编写构建，杜绝了Garbage Collection在 Stop-The-World 阶段带来的性能抖动
  3. 架构设计上支持更细粒度、更灵活的数据分片组织方式，激活更多优化空间
  4. 元数据设计提供更好的故障域控制，避免多租户相互影响
  5. 更短的故障恢复时间，对在线场景的高可用性支持更好

引用参考

内容主要参考了王玮老师在「深入浅出 HBase 实战」课程里所教授的内容，同时也参考了学员手册里第一节的内容，图片来自于老师的PPT，链接如下：

  1. 【大数据专场 学习资料四】第四届字节跳动青训营 - 掘金 (juejin.cn)
  2. 深入浅出 HBase 实战- 王玮- ppt.pptx - 飞书文档 (feishu.cn)
avatar
文章
阅读
粉丝