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

狂野的拉布拉多哎
89 阅读12分钟

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

  • 介绍HBase的设计理念、数据模型、适用场景、业界典型用例
  • 介绍HBase的整体架构设计、主要模块设计
  • 介绍Hbase针对海量数据场景所做的设计优化，包括水平扩展能力、负载均衡策略、故障恢复机制
  • 分享HBase 实战经验总结与最佳实践

01 适用场景

1.1 HBase简介

HBase是一个开源的NoSQL分布式数据库，对稀疏表提供更高的存储空间使用率和读写效率。

采用存储计算分离架构：

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

提供强一致语义，在CAP理论中属于CP系统。 注：一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)

HBase与关系型数据库对比：

HBaseRelational DB
数据结构半结构化，无数据类型；按列族稀疏存储，缺省数据不占用存储空间；支持多版本数据结构化，数据类型丰富；按完整行存储，缺省的列需要存储占位符；不支持多版本数据
读写模式支持按需读写部分列必须整行读取
事物支持仅支持单行内原子性支持完整的事物语义
数据规模适用于 TB、PB 级海量数据，水平扩展快速平滑仅适用于 GB、小量TB级，扩展过程较复杂
索引支持仅支持rowkey住建索引支持二级索引

1.2 HBase数据模型

逻辑结构： HBase以列族（column family)为单位存储数据，以行键(rowkey)索引数据。 个人感觉有点像DataFrame结构，它适合稀疏数据，缺省列不占用存储空间；通过(rowkey, column family, column qualifier, version)唯一指定一个具体的值；允许批量读取多行的部分列族/列数据。

  • 列族需要在使用前预先创建，列名(column qualifier)不需要预先声明，因此支持半结构化数据模型。
  • 支持保留多个版本的数据，(行键＋列族＋列名＋版本号）定位一个具体的值。
概念名称概念用途
行键（rowkey）用于唯一索引一行数据的”主键”，以字典序组织。一行可以包含多个列族
列族（column family）用于组织一系列列名、一个列族可以包含任意多个列名。每个列族的数据物理上相互独立地存储，以支持按列读取部分数据
列名（column qualifier）用于定义到一个具体的列，一个列名可以包含多个版本的数据。不需要预先定义列名，以支持半结构化的数据模型
版本号（version）用于标识一个列内多个不同版本的数据，每个版本号对应一个值
值（value）存储的一个具体的值

物理结构： 物理数据结构最小单元是KeyValue结构:

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

物理结构.png

1.3 使用场景

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

典型应用： 电商订单数据、搜索推荐引擎、广告数据流、用户交互数据、时序数据引擎、图存储引擎、大数据生态

HBase数据模型的优缺点： 优缺点.png

2 架构设计

2.1 HBase整体架构

HBase架构设计.png

主要组件包括：

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

依赖组件：

  • Zookeeper：分布式一致性共识协作管理，例如HMaster选主、任务分发、元数据变更管理等。
  • HDFS：分布式文件系统，HBase数据存储底座。

2.2 HMaster主要职责/组件

HMaster 主要组件：

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

HMaster主要职责：

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

2.3 RegionServer主要职责/组件

e39e4066-53fe-4a62-89d0-2e109b5d47b7.png

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

RegionServer 主要组件：

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

2.4 ZooKeeper主要职责

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

2.5 ThriftServer主要职责

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

ThriftServer主要职责.png

3 大数据支撑

3.1 水平扩展能力

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

水平扩展能力.png

3.2 Region热点切分

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

切分点选取 HBase原生提供的多种切分策略使用相同的切分点选择策略。目标是优先把最大的数据文件均匀切分。

切分点选择步骤：

  1. 找到该表中哪个region的数据大小最大；
  2. 找到该region内哪个column family的数据大小最大；
  3. 找到column family内哪个HFile的数据大小最大；
  4. 找到HFile里处于最中间位置的Data Block；
  5. 用这个Data Block的第一条KeyValue的Rowkey 作为切分点。

切分点找取.png

切分过程 所有Column Family都按照统一的切分点来切分数据。目的是优先均分最大的文件，不保证所有Column Family的所有文件都被均分。

切分过程步骤：

  1. HFile 1作为最大的文件被均分，其他文件也必须以相同的 rowkey切分以保证对齐新region的rowkey区间；
  2. 切分出的新region 分别负责rowkey区间[2000,2500)和[2500,4000)；
  3. 每个新region 分别负责原region的上/下半部分rowkey区间的数据；
  4. 在compaction执行前不实际切分文件，新region下的文件通过reference file指向原文件读取实际数据。

0d1c7131-7962-4ed7-804a-92105becf093.png

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

image.png

3.3 Region碎片整合

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

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

image.png

3.4 Region负载均衡

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

  • SimpleLoadBalancer策略
  • StochasticLoadBalancer策略
  • FavoredNodeLoadBalancer策略

3.5 故障恢复机制

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

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

HMaster自身恢复流程：

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

调度RegionServer的故障恢复流程：

  1. AssignmentManager 从procedure列表中找出Region-In-Transition状态的region继续调度过程；
  2. RegionServerTracker 从Zookeeper梳理online状态的RegionServer列表，结合ServerCrashProcedure列表、HDFS 中 WAL目录里alive / splitting状态的RegionServer记录，获取掉线RegionServer的列表，分别创建ServerCrashProcedure执行恢复流程。
  • 每个RegionServer实例启动时都会往Zookeeper的/hbase/rs路径下创建对应的临时节点。
  • HMaster通过监听RegionServer在Zookeeper的临时节点状态，监控数据读写服务的可用性，及时调度恢复不可用的regions。
  • RegionServer的故障恢复需要将内存中丢失的数据从WAL 中恢复，HMaster利用Zookeeper配合所有RegionServer实例，分布式地处理WAL数据，提升恢复速度。

启动流程：

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

3.6 Distributed Log Split原理

背景：

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

实现原理：

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

73fa1a17-8c91-4944-bee8-13a9bff2ac2e.png

进一步优化Distributed Log Replay：

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

4 最佳实践

4.1 Rowkey设计策略

  1. 不需要顺序扫描批量连续rowkey：对原始rowkey做哈希(如MD5)，作为真实rowkey的前缀。建议取适当长度的子串，避免过多占用存储空间。
  2. 需要顺序扫描批量连续rowkey：首先用groupID/applD/uSerID前缀也建议哈希处理，避免非预期的热点。 比如MD5(grouplD):grouplD:timestamp:...
  3. rowkey长度尽量保持较短，因为会冗余存储到每个KeyValue中。

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

4.2 Column Family设计策略

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

4.3 参数调优经验

参数调优经验.png

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

参考信息

【大数据专场 学习资料四】第四届字节跳动青训营

avatar
文章
阅读
粉丝