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

0x00 适用场景

0.1 什么是HBase

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

参考Google BigTable的设计，对稀疏表提供更高的存储空间使用率和读写效率。
采用存储计算分离架构
- 存储层基于HDFS存储数据，提供容错机制和高可靠性；
- 计算层提供灵活快速的水平扩展、负载均衡和故障恢复能力；
提供强一致语义，在CAP理论中属于CP系统。

Consistency,Availability,Partition Tolerance

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

9_与关系型数据库的区别.png

0.3 HBase数据模型

HBase 是存储计算分离架构，以 HDFS 作为分布式存储底座。数据实际存储在 HDFS
HBase 依赖 Zookeeper 实现元数据管理和服务发现。Client 通过 Zookeeper 配置连接到 HBase集群
Log-Structured Merge Tree 了解 LSM tree 的基本结构和特性

0.3.1 逻辑结构

HBase以列族(column family)为单位存储数据，以行键(rowkey)索引数据。

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

10_数据模型.png

0.3.2 物理结构

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

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

10_物理结构0.png 10_物理结构1.png

0.3.3 写数据

数据先写入 WAL 持久化，用于宕机时恢复内存里丢失的数据；
再写入内存态 MemStore，以一种跳表（SkipList）数据结构提供有序的数据和高效的随机读写；
当满足特定条件时（比如内存中数据过多，或间隔时间过长），MemStore 数据以 HFile 格式写入 HDFS

0.3.4 读数据

首次读某个 rowkey 时，client 需要从 Zookeeper 获取 hbase:meta 表位于哪个 RegionServer上；
然后访问该 RegionServer 查询 hbase:meta 表该 rowkey 对应 region 所在的 RegionServer B；
Client 缓存该位置信息，去 RegionServer B 读取 rowkey；
基于该region内可能存在该 rowkey 的 HFile 和 MemStore 构建一个最小堆，用以全局有序地 scan 数据（具体实现可搜索参考 LSM tree 设计原理）

0.3.5 Compaction

HBase 基于策略并定期整理 HFile 文件集合，将多个有序小文件合并成若干个有序的大文件。
HBase 提供两种 compaction 类型：
- Minor compaction：指选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile，在这个过程中不会处理已经Deleted或Expired的Cell。一次 Minor Compaction 的结果是更少并且更大的StoreFile。
- Major compaction：指将所有的StoreFile合并成一个StoreFile，这个过程会清理三类没有意义的数据：被删除的数据、TTL过期数据、版本号超过设定版本号的数据。另外，一般情况下，major compaction时间会持续比较长，整个过程会消耗大量系统资源，对上层业务有比较大的影响。因此线上业务都会将关闭自动触发major compaction功能，改为手动在业务低峰期触发。

0.3.6 Compaction触发条件

memstore flush：可以说compaction的根源就在于flush，memstore 达到一定阈值或其他条件时就会触发flush刷写到磁盘生成HFile文件，正是因为HFile文件越来越多才需要compact。HBase每次flush之后，都会判断是否要进行compaction，一旦满足minor compaction或major compaction的条件便会触发执行。
后台线程周期性检查：后台线程 CompactionChecker 会定期检查是否需要执行compaction，检查周期为hbase.server.thread.wakefrequency*hbase.server.compactchecker.interval.multiplier，这里主要考虑的是一段时间内没有写入请求仍然需要做compact检查。其中参数 hbase.server.thread.wakefrequency 默认值 10000 即 10s，是HBase服务端线程唤醒时间间隔，用于log roller、memstore flusher等操作周期性检查；参数 hbase.server.compactchecker.interval.multiplier 默认值1000，是compaction操作周期性检查乘数因子。10 * 1000 s 时间上约等于2hrs, 46mins, 40sec。
手动触发：是指通过HBase Shell、Master UI界面或者HBase API等任一种方式执行 compact、major_compact等命令。

0.4 HBase数据模型优缺点

10_数据模型优缺点.png

0x01 架构设计

1.1 HBase架构设计

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

10_架构设计.png

1.2 Hmaster主要职责

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

10_Hmaster主要职责.png

1.3 Hmaster主要组件

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

1.4 RegionServer主要职责

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

10_RegionServer主要职责.png

1.5 RegionServer主要组件

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

1.6 Zookeeper主要职责

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

10_ZooKeeper主要职责.png

1.7 ThriftServer主要职责

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

10_ThriftServer主要职责.png

0x02 大数据支撑

2.1 HBase在大数据生态的定位

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

2.2 水平扩展能力

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

10_水平扩展能力0.png 10_水平扩展能力1.png

2.3 Region热点切分

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

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

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

10_切分过程.png

2.4 Region碎片整合

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

2.5 Region负载均衡

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

2.5.1 Region负载均衡-调度策略

SimpleLoadBalancer
StochasticLoadBalancer
FavoredNodeLoadBalancer

2.6 故障恢复机制-HMaster

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

2.7 故障恢复机制-RegionServer

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

10_故障恢复RegionServer.png

2.8 Distributed Log Split原理

RegionServer故障，Zookeeper检测到心跳超时或连接断开，删除对应的临时节点并通知监听该节点的客户端
active HMaster监听到RS临时节点删除事件，从HDFS梳理出该RS负责的WAL文件列表
HMaster为每个WAL文件发布一个log split task到ZK
其他在线的RS监听到新任务，分别认领
将WAL entries按region拆分，分别写入HDFS上该region的recovered.edits目录
HMaster监听到log split任务完成，调度region到其他RS
RS打开region前在HDFS找到先回放recovered.edits目录下的WAL文件将数据恢复到Memstore里，再打开region 恢复读写服务

10_Distributed原理.png

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

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