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

1. Hbase

HBase是一个开源的NoSQL分布式数据库，是Apache软件基金会顶级项目之一。

参考Google BigTable的设计，对稀疏表提供更高的存储空间使用率和读写效率。

采用存储计算分离架构

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

提供强一致语义，在CAP理论中属于CP系统。

Consistency Availability,Partition Tolerance

1.2 HBase和关系型数据库的区别

1.3 HBase数据模型

HBase以列族(column family)组织数据，以行键(rowkey)索引l数据。

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

1.3.2HBase数据模型---逻辑结构

HBase是半结构化数据模型。以列族(column family)为单位存储数据，以行键(rowkey)索引数据。

• 列族需要在使用前预先创健，列名(column qualifier)不需要预先声明，因此支持半结构化数据模型。
• 支持保留多个版本的数据，（行键+列族+列名+版本号)定位一个具体值。

1.3.3 HBase数据模型---物理结构

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

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

1.4 HBase数据模型的优缺点

2. HBase的架构设计

主要组件包括：

• HMaster:元数据管理，集群调度、保活。
• RegionServer:提供数据读写服务，每个实例

负责若干个互不重叠的rowkey区间内的数据。

• ThriftServer:提供Thrift API读写的代理层。

依赖组件包括：

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

2.1 HMaster主要职责

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

主要组件：

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

2.2 Region Server的主要职责

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

主要组件：

• MemStore:基于SkipList数据结构实现的内存态存储，定期批量写入硬盘
• Write-Ahead-Log:顺序记录写请求到特久化存储，用于故障恢复内存中丢失的数据
• StoreFile:即HFile,表示HBase在HDFS存储数据的文件格式，其内数据按rowkey字典序有序排列
• BlockCache:HBase以数据块为单位读取数据

并缓存在内存中以加速重复数据的读取

2.3 ZooKeeper的主要职责

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

2.4 ThriftServer的主要职责

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

3. 大数据支持

定位：

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

3.1 水平扩展能力

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

3.2 Region热点切分

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

3.2.1 Region热点切分---切分点选取

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

目标：优先把最大的数据文件均匀切分。

切分点选择步骤 1.找到该表中哪个region的数据大小最大

2.找到该region内哪个column family的数据大小最大

3.找到column family内哪个HFile的数据大小最大

4.找到HFile里处于最中间位置的Data Block;

5.用这个Data Block的第一条KeyValue的Rowkey作为切分点。

3.2.2 Region热点切分---切分过程

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

切分出的新region分别负责rowkey区间[2000,2500)和[2500,4000)

• 每个新region分别负责原region的上下半部分rowkey区间的数据
• 在compaction执行前不实际切分文件，新region下的文件通过reference file指向原文件读取实际数据。

3.2.3 Region热点切分---流程设计

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

3.3 Region碎片整合

• 当某些region数据量过小、碎片化，合并相邻region整合优化数据分布。
• AssignmentManager创建MergeTableRegionsProcedure执行整合操作。
• 不搬迁实际数据，通过reference file定位原region的文件，直到下次compaction时实际处理数据。

*注意：只允许合并相邻region,否则会打破rowkey空间连续且不重合的约定。

3.3.1 Region碎片整合---流程设计

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

3.4 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分配步骤2选取的regions 尽量使每个RS的region数量都不低于下限；

4.处理边界情况，无法满足所有RS的region数量 都在合理范围内时，尽量保持region数量相近。

3.4.1 Region负载均衡---其他策略

StochasticLoadBalancer

• 随机尝试不同的region放置策略，根据提供的cost function计算不同策略的分值排名(0为最优策略，1为最差策略)；
• cost计算将下列指标纳入统计：

region负载、表负载、数据本地性（本地访问HDFS)、Memstore大小、HFile大小。

• 根据配置加权计算最终cost,选择最优方案进行负载均衡；

FavoredNodeLoadBalancer

• 用于充分利用本地读写HDFS文件来优化读写性能。
• 每个region会指定优选的3个RegionServer地址，同时会告知HDFS在这些优选节点上放置该region的数据；
• 即使第一节点出现故障，HBase也可以将第二节点提升为第一节点，保证稳定的读时延；

3.5 故障恢复机制---HMaster

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

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

3.5.1 故障恢复机制---HMaster恢复流程

一、HMaster自身恢复流程：

1.监听到hbase/active-master临时节点被删除的事件，触发选主逻辑；

2.选主成功后执行HMaster启动流程，从持久化存储读取未完成的procedures从之前状态继续执行：

3.故障HMaster实例恢复后发现主节点已存在，继续监听hbase/active-master。

二、调度RegionServer的故障恢复流程：

1.AssignmentManager从procedure列表中找出Region-ln-Transition状态的region继续调度过程；

2.RegionServerTracker从Zookeeper梳理online状态的RegionServer列表，结合ServerCrashProcedure列表、HDFS中WAL目录里alive/splitting状态的RegionServer记录，获取掉线RegionServer的列表，分别创建ServerCrashProcedure执行恢复流程。

3.6 故障恢复机制---RegionServer

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

3.6.1 故障恢复机制---RegionServer恢复流程

启动流程：

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

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

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

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

3.7 Distributed Log Split原理

1.写入HBase的数据首先顺序持久化到Vrite-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 恢复读写服务