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

HBase基于HDFS实现存储计算分离架构的分布式表格存储服务。

01.适用场景

介绍HBase的设计理念、数据模型、适用场景、业界典型用例

1.1 什么是HBase ?

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

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

采用存储计算分离架构，

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

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

▪️ Consistency, Availability, Partion Tolerance

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

截屏2022-08-06 15.50.55.png

1.3 HBase数据模型

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

1）列族需要在使用前预先创建，列名(column qualifier) 不需要预先声明，因此支持半结构化数据模型。

2）支持保留多个版本的数据，(行键+列族+列名+版本号)定位一个具体的值。

截屏2022-08-06 15.52.31.png

1.3 HBase 数据模型-逻辑结构

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

1）列族需要在使用前预先创建，列名(column qualifier)不需要预先声明，因此支持半结构化数据模型。

2）支持保留多个版本的数据，(行键+列族+列名+版本号)定位一个具体值。

截屏2022-08-06 15.54.02.png

➢通过非关系型视图理解HBase数据模型:

1）适合稀疏数据，缺省列不占用存储空间。

2）通过(rowkey, column family, column qualifier, version)

3）唯一指定一个具体的值。

4）允许批量读取多行的部分列族/列数据。

截屏2022-08-06 15.55.22.png

1.3 HBase数据模型 - 物理结构

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

1）每个版本的数据都携带全部行列信息。

2）同一行，同一列族的数据物理.上连续有序存储。

3）同列族内的KeyValue按rowkey字典序升序，column qualifier升序，version 降序排列。

4）不同列族的数据存储在相互独立的物理文件，列族间不保证数据全局有序。

5）同列族下不同物理文件间不保证数据全局有序。

6）仅单个物理文件内有序。

截屏2022-08-06 15.57.23.png

截屏2022-08-06 15.57.45.png

1.4 使用场景

➢适用场景:

1）“近在线”的海量分布式KV/宽表存储，数据量级可达到PB级以上

2）写密集型、高吞吐应用，可接受一-定程度的时延抖动

3）字典序主键索引、批量顺序扫描多行数据的场景

4）Hadoop大数据生态友好兼容

5）半结构化数据模型，行列稀疏的数据分布，动态增减列名

6）敏捷平滑的水平扩展能力，快速响应数据体量、流量变化

1.4使用场景-典型应用

典型应用:

1）电商订单数据:查询最新/待处理订单进度

2）搜索推荐引擎:存储原始数据、排序推荐结果

3）广告数据流:触达、点击、转化等事件流

4）用户交互数据: IM、 Email、点赞、搜索

5）时序数据引擎:日志、监控(OpenTSDB)

6）图存储引擎: JanusGraph

7）大数据生态:高度融入Hadoop生态

截屏2022-08-06 16.00.46.png

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

典型用例:

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

截屏2022-08-06 16.03.25.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, ..）”

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

典型用例:

-商家订单系统使用HBase管理买家、卖家的订单操作信息

数据格式：

截屏2022-08-06 16.05.24.png

查询模式：

查询指定orderlD订单最近新增/待处理的操作记录。例如:

rowkey: e1cb:orderlD1", column family: customer"

对应多个column的数据:

column1: actionType1_ actionlD1, value1: timestamp=21, action-='.')",

column2: actionType2_ actionlD2, value2: [timestamp-26, action-'..'",

column3: checkpoint, value: timestamp-23"

...

典型用例:

- Facebook在2010年开始使用HBase存储用户的互动消息，包括电子邮件、即时消息、短信等

数据格式：

截屏2022-08-06 16.07.44.png

查询模式:

查询指定userlD用户包含给定词语word的最近N条消息的messagelD.例如:

rowkey:“userlD1", column:“cf:hello"对应多个版本的数据:

value1: "offset=23", version:“messagelD=1234"

value2: "offset=12", version:“messagelD=1134",

value3: "offset=41", version:“messagelD=1034"，

...

1.4使用场景-写密集型的高吞吐场景

典型用例:

时序存储引擎，典型场景是日志、监控数据存储，例如OpenTSDB (Open Time Series Database)

数据格式:

截屏2022-08-06 16.09.46.png

查询模式：

查询指定metric_ uid 指标在指定时间段的所有数据。例如:

start rowkey: [hash]metric1:1655386954",

end rowkey: [hash]metric1:1665386954",

column_ family: "dp",

查询1655386954 到 1665386954 时间内该监控的所有数据点.

*rowkey和column通过编码尽量简短，减少空间用量。

1.5HBase数据模型的优缺点

截屏2022-08-06 16.12.40.png

02.HBase 架构设计

2.1 HBase架构设计

➢主要组件包括:

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

➢依赖组件包括:

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

截屏2022-08-06 16.14.51.png

2.2 Hmaster主要职责

1）管理RegionServer实例生命周期，保证服务可用性

2）协调RegionServer数据故障恢复，保证数据正确性

3）集中管理集群元数据，执行负载均衡等维护集群稳定性

4）定期巡检元数据，调整数据分布，清理废弃数据等

5）处理用户主动发起的元数据操作如建表、删表等

截屏2022-08-06 16.16.44.png

2.2 HMaster - 主要组件

1）ActiveMasterManager:管理HMaster的active/backup状态

2）ServerManager:管理集群内RegionServer的状态

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

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

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

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

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

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

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

截屏2022-08-06 16.18.54.png

2.3 RegionServer 主要职责

1）提供部分rowkey区间数据的读写服务

2）如果负责meta表，向客户端SDK提供rowkey位置信息

3）认领HMaster发布的故障恢复任务，帮助加速数据恢复过程

4）处理HMaster下达的元数据操作，如region打开/关闭/分裂/合并操作等

截屏2022-08-06 16.20.09.png

2.3 RegionServer - 主要组件

1）MemStore:基于SkipList数据结构实现的内存态存储，定期批量写入硬盘

2）Write. Ahead-Log:顺序记录写请求到持久化存储，用于故障恢复内存中丢失的数据

3）Store:对应-个Column Family在一个region下的数据集合，通常包含多个文件

4）StoreFile:即HFile,表示HBase在HDFS存储数据的文件格式，其内数据按rowkey字典序有序排列

5）BlockCache：HBase 以数据块为单位读取数据并缓存在内存中以加速重复数据的读取

截屏2022-08-06 16.22.57.png

2.4 ZooKeeper主要职责

1）HMaster登记信息，对active/backup分工达成共识

2）RegionServer登记信息，失联时HMaster保活处理

3）登记meta表位置信息，供SDK查询读写位置信息

4）供HMaster和RegionServer协作处理分布式任务

截屏2022-08-06 16.24.05.png

2.5 ThriftServer主要职责

1）实现HBase定义的Thrift API，作为代理层向用户提供RPC读写服务

2）用户可根据IDL自行生成客户端实现

3）独立于RegionServer水平扩展，用户可访问任意ThriftServer 实例 (scan操作较特殊，需要同实例维护scan状态)

截屏2022-08-06 16.25.26.png

03.大数据支撑

3.1 HBase在大数据生态的定位

1）对TB、PB级海量数据支持强一致、近实时的读写性能，支持快速的ad-hoc分析查询任务;

2）支持字典序批量扫描大量数据，支持只读取部分列族的数据，灵活支持不同查询模式，避免读取不必要的数据;

3）存储大规模任务(例如MapReduce, Spark, Flink) 的中间/最终计算结果;

4）平滑快速的水平扩展能力，能够敏捷应对大数据场景高速增长的数据体量和大规模的并发访问;

5）精细化的资源成本控制，计算层和存储层分别按需扩展，避免资源浪费。

3.2水平扩展能力

1）增加RegionServer实例，分配部分region到新实例。

2）扩展过程平滑，无需搬迁实际数据。

3）可用性影响时间很短，用户基本无感知。

截屏2022-08-06 16.28.13.png

3.3 Region热点切分

1）当某个region数据量过多，切分成两个独立的子region分摊负载。

2）RegionServer在特定时机(flush、 compaction) 检查region是否应该切分，计算切分点并RPC上报HMaster, 由AssignmentManager负责执行RegionState Transition。

3）不搬迁实际数据，切分产生的新region数据目录下生成一个以原region文件信息命名的文件，内容是切分点对应的rowkey,以及标识新region是上/下半部分的数据。

截屏2022-08-06 16.29.40.png

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

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

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

切分点选择步骤:

1.找到该表中哪个region的数据大小最大

截屏2022-08-06 16.30.50.png

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

截屏2022-08-06 16.31.57.png

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

截屏2022-08-06 16.33.19.png

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

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

截屏2022-08-06 16.34.11.png

3.3 Region热点切分 - 切分过程

➢所有Column Family都按照统一的切分点来切分数据。

➢目的是优先均分最大的文件，不保证所有Column Family的所有文件都被均分。

➢HFile 1作为最大的文件被均分，其他文件也必须以相同的rowkey切分以保证对齐新region的rowkey区间。

截屏2022-08-06 16.35.16.png

➢所有Column Family都按照统一的切分点来切分数据。

➢目的是优先均分最大的文件，不保证所有Column Family的所有文件都被均分。

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

截屏2022-08-06 16.37.00.png

➢所有Column Family都按照统一的切分点来切分数据。

➢目的是优先均分最大的文件，不保证所有Column Family的所有文件都被均分。

➢每个新region分别负责原region的，上/下半部分rowkey区间的数据。

➢在compaction执行前不实际切分文件，新region下的文件通过reference file指向原文件读取实际数据。

截屏2022-08-06 16.38.45.png

➢每个新region分别负责原region的.上/下半部分rowkey区间的数据。

➢在compaction执行前不实际切分文件，新region下的文件通过reference file 指向原文件读取实际数据。

截屏2022-08-06 16.39.44.png

截屏2022-08-06 16.40.07.png

3.3 Region热点切分 - 流程设计

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

截屏2022-08-06 16.41.03.png

3.4 Region碎片整合

➢当某些region数据量过小、碎片化，合并相邻region整合优化数据分布。

➢AssignmentManager 创建Merge TableRegionsProcedure执行整合操作。

➢不搬迁实际数据，通过reference file定位原region的文件，直到下次compaction时实际处理数据。

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

3.4 Region碎片整合-流程设计

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

截屏2022-08-06 16.42.39.png

3.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并按创建时间从新到老排序;

截屏2022-08-06 16.44.04.png

3.5 Region负载均衡-调度策略

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

SimpleLoadBalancer具体步骤:

3.选取出region数量低于下限的RegionServer列表，round-robin分配步骤2选取的regions,尽量使每个RS的region数量都不低于下限;

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

截屏2022-08-06 16.45.25.png

3.5 Region负载均衡 - 其他策略

➢StochasticL oadBalancer 1）随机尝试不同的region放置策略，根据提供的cost function计算不同策略的分值排名(0 为最优策略，1 为最差策略)

2）cost计算将下列指标纳入统计:region负载、表负载、数据本地性(本地访问 HDFS)、Memstore 大小、HFile 大小。

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

➢FavoredNodel oadBalancer 1）用于充分利用本地读写HDFS文件来优化读写性能。

2）每个region会指定优选的3个RegionServer地址，同时会告知HDFS在这些优选节点上放置该region的数据;

3）即使第一节点出现故障， HBase也可以将第二节点提升为第一节点，保证稳定的读时延;

3.6故障恢复机制- HMaster

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

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

截屏2022-08-06 16.48.21.png

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

一、HMaster 自身恢复流程:

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

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

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

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

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

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

3.7故障恢复机制- RegionServer

➢每个RegionServer实例启动时都会往Zookeeper的/hbase/rs路径下创建对应的临时节点。

➢HMaster 通过监听RegionServer在Zookeeper的临时节点状态，监控数据读写服务的可用性，及时调度恢复不可用的regions。

➢RegionServer 的故障恢复需要将内存中丢失的数据从WAL中恢复，HMaster 利用Zookeeper配合所有RegionServer实例，分布式地处理WAL数据，提升恢复速度。

截屏2022-08-06 16.52.10.png

启动流程:

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

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

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

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

3.8 Distributed Log Split原理

背景:

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

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

截屏2022-08-06 16.54.14.png

3.8 Distributed Log Split原理-具体流程

实现原理:

RegionServer故障，Zookeeper检测到心跳超时或连接断开，删除对应的临时节点并通知监听该节点的客户端
active HMaster监听到RS临时节点删除事件，从HDFS梳理出该RS负责的WAL文件列表
HMaster为每个WAL文件发布一个log split task到ZK

截屏2022-08-06 16.56.26.png

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

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

HMaster监听到log split任务完成，调度region到其他RS
RS打开region前在HDFS找到先回放recovered.edits目录下的WAL文件将数据恢复到Memstore里，再打开region恢复读写服务

截屏2022-08-06 16.58.01.png

3.8 Distributed Log Split原理 - 具体流程

完整流程示意图

截屏2022-08-06 16.58.54.png

3.8 Distributed Log Split原理 - 优化空间

进一步优化: Distributed Log Replay

1）HMaster 先将故障RegionServer.上的所有region以Recovering状态调度分配到其他正常RS.上;

2）再进行类似Distributed Log Split的WAL日志按region维度切分;

3）切分后不写入HDFS,而是直接回放，通过SDK写流程将WAL记录写到对应的新RS;

4） Recovering 状态的region接受写请求但不提供读服务，直到WAL回放数据恢复完成。

04.最佳实践分享

4.1 Rowkey设计策略

场景分类

1.不需要顺序扫描批量连续rowkey

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

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

首先用grouplD/applD/userlD前缀避免数据热点，然后加上定义顺序的信息(如时间戳等)ID前缀也建议哈希处理，避免非预期的热点。e.g. MD5(grouplD):grouplD:timestamp...

rowkey长度尽量保持较短，因为会冗余存储到每个KeyValue中。

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

4.2 Column Family设计策略

Column family数量过多容易影响性能，建议尽量少，不超过5个。

2.需要同时读取的数据尽量放在相同列族，反之尽量放在不同列族，读取时尽量只读取必需的列族，避免读不必要的列族。

3.列族(以及column qualifier) 名称尽量短，因为会冗余存储到每个KeyValue中。

4.3参数调优经验

截屏2022-08-06 17.04.08.png

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

优势:

1.存储层基于字节跳动自研分布式存储底座，从设计.上充分支持在线场景的性能、功能需求;

2.采用C++编写构建，杜绝了Garbage Collection 在Stop-The-World阶段带来的性能抖动;

3.架构设计.上支持更细粒度、更灵活的数据分片组织方式，激活更多优化空间;

4.元数据设计提供更好的故障域控制，避免多租户相互影响;

5.更短的故障恢复时间，对在线场景的高可用性支持更好;

浅入深出HBase丨青训营笔记

01.适用场景

1.1 什么是HBase ?

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

1.3 HBase数据模型

1.3 HBase 数据模型-逻辑结构

1.3 HBase数据模型 - 物理结构

1.4 使用场景

1.4使用场景-典型应用

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

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

1.4使用场景-写密集型的高吞吐场景

1.5HBase数据模型的优缺点

02.HBase 架构设计

2.1 HBase架构设计

2.2 Hmaster主要职责

2.2 HMaster - 主要组件

2.3 RegionServer 主要职责

2.3 RegionServer - 主要组件

2.4 ZooKeeper主要职责

2.5 ThriftServer主要职责

03.大数据支撑

3.1 HBase在大数据生态的定位

3.2水平扩展能力

3.3 Region热点切分

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

3.3 Region热点切分 - 切分过程

3.3 Region热点切分 - 流程设计

3.4 Region碎片整合

3.4 Region碎片整合-流程设计

3.5 Region负载均衡

3.5 Region负载均衡-调度策略

3.5 Region负载均衡 - 其他策略

3.6故障恢复机制- HMaster

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

3.7故障恢复机制- RegionServer

3.8 Distributed Log Split原理

3.8 Distributed Log Split原理-具体流程

3.8 Distributed Log Split原理 - 具体流程

3.8 Distributed Log Split原理 - 优化空间

04.最佳实践分享

4.1 Rowkey设计策略

4.2 Column Family设计策略

4.3参数调优经验

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