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

betalemon
93 阅读11分钟

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

HDFS 是一种分布式文件系统，基于常见商用硬件构建海量大规模存储集群，存储成本低，容量大。HDFS 通常采用三副本冗余存储数据道不同的机器来实现容灾备份。

一、HBase 定义

HBase 基于 HDFS 实现存储计算分离架构的分布式表格存储服务，是一个 NoSQL 分布式数据库。 其采用存储计算分离架构，

  • 存储层基于 HDFS 存储数据，提供容错机制和高可靠性；
  • 计算层提供水平扩展、负载均衡和故障恢复能力。

提供强一致语义，在CAP理论中属于 CP 系统。（Consistency, Availability, Partition Tolerance）

1. 与关系型数据库的区别

image.png

2. 数据模型

2.1 逻辑结构

Hbase 以 列族（column family） 为单位存储，以 行键（rowkey） 索引数据

  • 列族需要在使用前预先创建，列名不需要预先声明 -> 支持半结构化数据模型
  • 支持保留多个版本数据，（行键 rowkey + 列族 column family + 列名 column qulifier + 版本号 version）定位一个具体的值 image.png

例如：

image.png

  • 适合稀疏数据，缺省列不占用存储空间
  • 允许批量读取多行的部分列族/列数据

2.2 物理结构

  • 物理数据结构最小单元是 KeyValue 结构
  • 每个版本的数据携带全部行列信息
  • 同一行、同一列族的数据，物理上连续有序存储
  • 同列族内的 KeyValue 按 rowkey 字典序升序，column qualifier 升序，version 降序排列

image.png

  • 不同列族的数据存储在相互独立的物理文件，列族间不保证数据全局有序
  • 同列族下不同物理文件间不保证数据全局有序
  • 仅单个为文件内有序

image.png

3. 适用场景

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

应用

  • 电商订单数据：查询最新/待处理订单进度等“近在线”海量分布式 KV / 宽表存储
  • 搜索推荐引擎：存储原始数据、排序推荐结果等半结构化有序索引的数据
  • 广告数据流：触达、点击、转化等事件流
  • 用户交互数据：IM、Email、点赞、搜索
  • 时序数据引擎：日志、监控数据存储（OpenTSDB, Open Time Series Database）等写密集型的高吞吐场景
  • 图存储引擎：JanusGraph
  • 大数据生态：高度融入 Hadoop 生态

4. Hbase 优缺点

image.png

二、HBase 架构设计

1. 架构设计

image.png

主要组件：

  • HMaster：元数据管理，集群调度、保活
  • RegionServer：提供数据读写服务，每个实例负责若干个互不重叠的 rowkey 区间内的数据
  • ThriftServer：提供 Thrift API 读写的代理层

依赖组件：

  • ZooKeeper：分布式一致性共识写作管理（Hadoop动物园管理员），例如 HMaster 选主、任务分发、元数据变更管理等
  • HDFS：分布式文件系统，HBase 数据存储底座

2. Hmaster

类似于 master 节点

image.png

主要职责

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

主要组件

  • ActiveMasterManager：管理 HMaster 的 active/backup 状态
  • ServerManager：管理集群内 RegionServer 的状态
  • AssignmentManager：管理数据分配（region）的状态
  • SplitWalManager：负责故障数据恢复的 WAL 拆分工作
  • LoadBalancer：定期巡检、调整集群负载状态
  • RegionNormalizer：定期巡检并拆分热点、整合碎片
  • CatalogJanitor：定期巡检、清理元数据
  • Cleaners：定期清理废弃的 HFile/WAL 等文件
  • MasterFileSystem：封装访问 HDFS 的客户端 SDK

3. RegionServer

类似于 worker 节点

image.png

主要职责

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

主要组件

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

4. ZooKeeper

image.png

主要职责

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

5. ThriftServer

image.png

主要职责

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

三、大数据支撑 —— HBase 的设计优化

1. 功能

  • 对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 是上/下半部分的数据

image.png

如上图所示，

  1. 在路径 table/cf/ 下发生切分的位置 ${parentRegionName}/ 创建一个临时文件夹 .splits/，再创建两个切分后的位置 ${daughterA_regionName}/ 和 ${daughterB_regionName}/，分别在两个子目录上创建两个文件，名称同为 ${parentHFileName}.${parentRegionName} ，即文件被分为上下两块。其中， parentHFileName 表示原来的父 region 的文件，parentRegionName 表示父 region 的名字
  2. 在 reference 创建好以及原数据分析完之后，${parentHFileName}.${parentRegionName} 会被移动到正式路径下，作为两个独立的 region。具体文件格式如图中右边代码所示（包括分裂key，属于上/下半部分）。
  3. Reference 中的这些信息把真实路径请求指引回原始的文件 $table/cf/{parentRegionName}/${parentHFileName}

3.1 切分点选取

HBase 原生提供的多种切分策略使用相同的切分点选择策略

  • 目标：优先把最大的数据文件均匀切分
  • 步骤
    • 找到该表中数据大小最大的 region
    • 找到该 region 内数据大小最大的 column family
    • 选择 column family 内最大的 HFile（HFile 就是物理文件）
    • 找到 HFile 里处于 最中间位置 的 Data Block
    • 用这个 Data Block 的第一条 KeyValue 的 Rowkey 作为切分点

HBase 存储的物理文件数据是以固定长度的块来组织的，且在整个 HFile 内有序排列。 image.png

切分过程

  • 所有 Column Family 都按照统一的切分点来切分数据
  • 目的是优先均分最大的文件，不保证所有 Column Family 的所有文件都被均分
  • HFile X 作为最大的文件被均分，其他文件也必须以相同的 rowkey 切分以保证对其新 region 的 rowkey 区间
  • 切分出的新 region 分别负责原 region 的上/下半部分 rowkey 区间的数据
    • HMaster 把新的 region 分别调度到不同的 RegionServer 上就实现了把热点一分为二，负载均衡
  • 在 compaction 执行前不实际切分文件，新 region 下的文件通过 reference file 指向源文件读取实际数据

流程设计

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

image.png

4. 碎片整合

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

流程设计

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

image.png

5. 负载均衡

定期巡检各 RegionServer 上的 region 数量，保持其数量均匀分布在各个 RegionServer 上

调度策略

SimpleLoadBalancer 具体步骤：

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

image.png

  • 如图所示，将 RS1 上过载的 region 全部均摊到 RS2 和 RS3 上
  • 按照 region 数量降序排序

image.png

  • 如图所示，region 被分摊到 RS2 和 RS3 上，是比较理想的情况

其他策略

  • StochasticLoadBalancer：随即尝试不同的 region 放置策略，根据提供的 cost function 计算不同策略的分值排名（0为最优策略，1为最差策略）
  • FavoredNodeLoadBalancer：充分利用本地读写 HDFS 文件来优化读写性能

6. 故障恢复机制

HMaster

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

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

image.png

恢复流程

（1）HMaster 自身恢复流程

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

（2）调度 RegionServer 的故障恢复流程

  • AssignmentManager 从 procedure 列表中找出 Region-In_Transition 状态的 region 继续调度过程
  • RegionServerTacker 从 ZooKeeper 梳理 online 状态的 Region Server 列表，结合 ServerCrashProcedure 列表、HDFS 中 WAL 目录里 alive / splitting 状态的 RegionServer 记录，获取掉线 RegionServer 的列表，分别创建 ServerCrashProcedure 执行恢复流程。

RegionServer

image.png

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

恢复流程

启动流程：

  • 启动时去 ZooKeeper 登记自身信息，告知主HMaster实例有新RS实例接入集群
  • 接收和执行来自 HMaster 的 region 调度命令
  • 打开 region 前先从 HDFS 读取该 region 的 recovered.edits 目录下的 WAL 记录，回放恢复数据
  • 恢复完成，认领 ZooKeeper 上发布的分布式任务（如 WAL 切分）帮助其他数据恢复

8. Distributed Log Split 原理

背景

  • 写入HBase的数据首先顺序持久化到 Write-Ahead-Log，然后写入内存态的 MemStore 即完成，不立即写盘，RegionServer 故障会导致内存中的数据丢失，需要回放 WAL 来恢复
  • 同 RegionServer 的所有 region 复用 WAL，因此不同 region 的数据交错穿插，RegionServer 故障后重新分配 region 前需要先按 region 纬度拆分 WAL

image.png

具体流程（实现原理）

image.png

  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 恢复读写服务

进一步优化：Distributed Log Replay

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

四、实践经验

1. Rowkey 设计策略

场景分类

（1）不需要顺序扫描批量连续 rowkey【点读】

  • 对原始 rowkey 做哈希（如MD5），作为真实 rowkey 的前缀
  • 建议取适当长度的子串，避免过多占用存储空间

（2）需要顺序扫描批量连续 rowkey

  • 首先用 groupID/appID/userID 前缀避免数据热点，然后加上定义顺序的信息（如时间戳等）
  • ID 前缀也建议哈希处理，避免非预期的热点
  • （常见模式）例：MD5(groupID):groupID:timestamp:...

（3）Rowkey 长度尽量保持较短，因为会冗余存储到每个 KeyValue 中

  • 避免用时间戳直接作为 rowkey 前缀，否则会导致最新的数据始终集中在单个 RegionServer 上，造成热点瓶颈，且无法通过水平扩容缓解。

2. Column Family 设计策略

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

3. 参数调优经验

image.png

avatar
文章
阅读
粉丝