深入浅出 HBase 实战 | 青训营笔记这是我参与「第四届青训营」笔记创作活动的第9天什么是HBase HBa

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

什么是HBase

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

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

采用存储计算分离架构

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

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

HBase 和关系数据库的区别：

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

HBase 数据模型：

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

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

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

HBase 数据模型的优缺点：

HBase的优缺点

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

适合稀疏数据，缺省列不占用内存
通过（rowkey，column family，column qualifier，version）
唯一指定一个具体的值
允许批量读取多行的部分列族/列数据

HBase 数据模型——物理结构

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

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

HBase 数据模型--物理结构 1 .jpg

HBase 数据模型--物理结构.jpg

适用场景

“近在线”的海量分布式KV/宽表存储，数据量级达到百TB级以上
写密集型应用，高吞吐，可接受一定的时延抖动
需要按行顺序扫描的能力
接入Hadoop大数据生态
结构化、半结构化数据，可以经常新增/更新列属性
平滑的水平扩展能力，快速响应数据体量、流量变化

业务落地场景包括：

电商订单数据 抖音电商每日交易订单数据基于 HBase 存储，支持海量数据存储的同时满足稳定低延时的查询需求，并且只需相对很低的存储成本。通过多个列存储订单信息和处理进度，快速查询近期新增/待处理订单列表。同时也可将历史订单数据用于统计、用户行为分析等离线任务。
搜索推荐引擎 存储网络爬虫持续不断抓取并处理后的原始网页信息，通过 MapReduce、Flink、Spark 等大数据计算框架分析处理原始数据后产出粗选、精选、排序后的网页索引集，再存储到 HBase 以提供近实时的随机查询能力，为上层的多个字节跳动应用提供通用的搜索和推荐能力。
大数据生态 天生融入 Hadoop 大数据生态。对多种大数据组件、框架拥有良好的兼容性，工具链完善，快速打通大数据链路，提高系统构建落地效率，并借助 HDFS 提供可观的成本优势。敏捷平滑的水平扩展能力可以自如地应对数据体量和流量的快速增长。
广告数据流 存储广告触达、点击、转化等事件流，为广告分析系统提供快速的随机查询及批量读取能力，助力提升广告效果分析和统计效率。
用户交互数据 Facebook 曾使用 HBase 存储用户交互产生的数据，例如聊天、评论、帖子、点赞等数据，并利用 HBase 构建用户内容搜索功能。
时序数据引擎 基于 HBase 构建适用于时序数据的存储引擎，例如日志、监控数据存储。例如 OpenTSDB（Open Time Series Database）是一个基于 HBase 的时序存储系统，适用于日志、监控打点数据的存储查询。
图存储引擎 基于 HBase 设计图结构的数据模型，如节点、边、属性等概念，作为图存储系统的存储引擎。例如 JanusGraph 可以基于 HBase 存储图数据。

典型用例：

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

商家订单系统使用 HBase.jpg

HBase 架构设计

主要组件包括：

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

依赖组件包括：

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

HMaster 主要职责：

HMaster 主要职责.jpg

HMaster 主要组件：

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

Master 主要组件.jpg RegionServer 主要职责：

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

RegionServer 主要职责.jpg RegionServer 主要组件：

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

RegionServer 主要组件.jpg

zookeeper 主要职责

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

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

登记 meta 表位置信息，供 SDK 查询读写位置信息供HMaster 和 RegionServer 协作处理分布式任务

zookeeper 主要职责.jpg ThriftServer 主要职责

实现 HBASE 定义的Thrift API，作为代理层向用户提供 RPC 读写服务，用户可根据 IDL 自行生成客户端实现，独立于 RegionServer 水平扩展，用户可访问任意 ThriftServer 实例

ThriftServer 主要职责.jpg

大数据支撑

HBase 在大数据生态的定位

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

水平扩展能力

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

水平扩展能力.jpg

region 热点切分

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

region 热点切分.jpg

region热点切分-切分点选取：

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

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

切分点选择步骤：

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

生态

通过在 HBase之上引入各种组件可以使HBase应用场景得到极大扩展，例如监控、车联网、风控、实时推荐、人工智能等场景的需求。

Phoenix

主要提供SQL的方式来查询HBase里面的数据。一般能够在毫秒级别返回，比较适合OLTP以及操作性分析等场景，支持构建二级索引。

Spark

很多企业使用HBase存储海量数据，一种常见的需求就是对这些数据进行离线分析，我们可以使用Spark(Spark SQL) 来实现海量数据的离线分析需求。同时，Spark还支持实时流计算，我们可以使用 HBase+Spark Streaming 解决实时广告推荐等需求。

HGraphDB

分布式图数据库，可以使用其进行图 OLTP查询，同时结合 Spark GraphFrames 可实现图分析需求，帮助金融机构有效识别隐藏在网络中的黑色信息，在团伙欺诈、黑中介识别等。

GeoMesa

目前基于NoSQL数据库的时空数据引擎中功能最丰富、社区贡献人数最多的开源系统。提供高效时空索引，支持点、线、面等空间要素存储，百亿级数据实现毫秒(ms)级响应;提供轨迹查询、区域分布统计、区域查询、密度分析、聚合、OD 分析等常用的时空分析功能;提供基于Spark SQL、REST、GeoJSON、OGC服务等多种操作方式，方便地理信息互操作。

OpenTSDB

基于HBase的分布式的，可伸缩的时间序列数据库，适合做监控系统；比如收集大规模集群(包括网络设备、操作系统、应用程序)的监控数据并进行存储，查询。

Solr

原生的HBase只提供了Rowkey单主键，仅支持对Rowkey进行索引查找。可以使用 Solr来建立二级索引/全文索引来扩展更多查询场景的支持。

功能

Bulkload

大批量向HBase导入数据的功能。使用MapReduce任务直接生成底层存储的HFile文件，并直接移动到HBase存储目录下，节省HBase写路径的开销从而提高写入效率。

Coprocessor

提供一套接口框架，给HBase原生接口添加类似lifecycle hook函数的能力，用来执行用户自定义的功能来扩展HBase的能力，例如二级索引、Observer等功能。

Filter

将用户的过滤逻辑下推到HBase服务端，避免无用数据传输处理开销来提高查询效率。

MOB

Medium Object Storage解决HBase对中等大小对象（10-100MB）的低延迟读写支持，拓宽HBase适用场景。

Snapshot

数据备份功能，将某一时刻的数据以及元数据备份，用于数据恢复、快照读、复制表等功能。

Replication

将一个HBase集群中的数据复制到目标HBase集群，使用WAL将变更记录同步到其他集群。

数据组织方式

HBase是半结构化存储。数据以行（row）组织，每行包括一到多个列簇（column family）。使用列簇前需要通过创建表或更新表操作预先声明column family。

column family是稀疏存储，如果某行数据未使用部分column family则不占用这部分存储空间。

每个column family由一到多个列（column qualifier）组成。column qualifier不需要预先声明，可以使用任意值。

最小数据单元为cell，支持存储多个版本的数据。由rowkey + column family + column qualifier + version指定一个cell。

同一行同一列族的数据物理上连续存储，首先以column qualifier字典序排序，其次以timestamp时间戳倒序排序。

简单起见可以将HBase数据格式理解为如下结构：

 // table名格式："${namespace}:${table}"
 // 例如：table = "default:test_table"
 [
     "rowKey1": { // rowkey定位一行数据
         "cf1": { // column family需要预先定义到表结构
             "cq_a": { // column qualifier无需定义，使用任意值
                 "timestamp3": "value3", 
                 // row=rowKey1, column="cf1:cf_a", timestamp=timestamp2
                 // 定位一个cell
                 "timestamp2": "value2", 
                 "timestamp1": "value1"
             },
             "cq_b": {
                 "timestamp2": "value2",
                 "timestamp1": "value1"
             }
         }, 
         "cf3": {
             "cq_m": {
                 "timestamp1": "value1"
             },
             "cq_n": {
                 "timestamp1": "value1"
             }
         },
     },   
     "rowKey3": { 
         "cf2": { // 缺省column family不占用存储空间
             "cq_x": {
                 "timestamp3": "value3",
                 "timestamp2": "value2",
                 "timestamp1": "value1"
             },
             "cq_y": {
                 "timestamp1": "value1"
             }
         },
     }
 ]
 复制代码

主要数据结构

HDFS目录结构

 hdfs://base_dir/hbase_cluster_name/data/default/table_name/region_name(e.g.fffe6d7a8e19490f8770fbe8637a686c)/column_family_name/hfile_name(e.g.7a8b82e197274fd7ade1a7f6b20b9417)
 复制代码

MemStore

MemStore数据结构详细介绍可参考 hbasefly.com/2019/10/18/…

MemStore使用SkipList组织KeyValue数据，提供O(logN)的查询/插入/删除操作，支持双向遍历。

具体实现采用JDK标准库的ConcurrentSkipListMap，结构如下图：

图片选自 hbasefly.com/2019/10/18/…

写一个KeyValue到MemStore的顺序如下：

在JVM堆中为KeyValue对象申请一块内存区域。
调用ConcurrentSkipListMap的put(K key, V value)方法将这个KeyValue对象作为参数传入。

图片选自 hbasefly.com/2019/10/18/…

HFile

HFile结构介绍详见hbasefly.com/2016/03/25/…

HFile是HBase存储数据的文件组织形式，参考BigTable的SSTable和Hadoop的TFile实现。HFile共经历了三个版本，其中V2在0.92引入，V3在0.98引入。HFileV1版本的在实际使用过程中发现它占用内存多，HFileV2版本针对此进行了优化，HFileV3版本基本和V2版本相同，只是在cell层面添加了Tag数组的支持。这里主要针对V2版本进行分析。

官方文档的HFile结构图如下：

图片选自 hbase.apache.org/book.html#_…

HFlie主要分为4个section

Scanned block section：顾名思义，表示顺序扫描HFile时所有的数据块将会被读取，包括Leaf Index Block和Bloom Block。
Non-scanned block section：表示在HFile顺序扫描的时候数据不会被读取，主要包括Meta Block和Intermediate Level Data Index Blocks两部分。
Load-on-open-section：这部分数据在HBase的region server启动时，需要加载到内存中。包括FileInfo、Bloom filter block、data block index和meta block index。
Trailer：这部分主要记录了HFile的基本信息、各个部分的偏移值和寻址信息。

一个HFile内的数据会被切分成等大小的block，每个block的大小可以在创建表列簇的时候通过参数blocksize ＝> ‘65535’进行指定，默认为64k，大号的Block有利于顺序Scan，小号Block利于随机查询，需要根据使用场景来权衡block大小。

图片选自 hbasefly.com/2016/03/25/…

HFileBlock

block有多种类型，除了data block还包括index block和bloom block来优化数据读取。但格式统一抽象如下：

图片选自 hbasefly.com/2016/03/25/…

Data Block

HBase中数据存储的最小文件单元。主要存储用户的KeyValue数据。KeyValue是HBase数据表示的最基础单位，每个数据都是以KeyValue结构在HBase中进行存储。KeyValue结构的内存/磁盘表示如下：

图片选自 hbasefly.com/2016/03/25/…

可以看出Row、ColumnFamily、ColumnQualifier是每个KeyValue都会存储，有明显的信息冗余。因此设计名称时最好比较精简，尽量减小重复信息占用的存储。

Block Index

可参见hbasefly.com/2016/04/03/…

索引分为单层和多层两种。单层即root data index，在打开HFile时就全量加载进内存。结构表示如下：

图片选自 hbasefly.com/2016/04/03/…

Block Offset 表示索引指向数据块的偏移量，
BlockDataSize 表示索引指向数据块在磁盘上的大小，
BlockKey 表示索引指向数据块中的第一个key
其他三个字段记录HFile所有Data Block中最中间的一个Data Block，用于在对HFile进行split操作时，快速定位HFile的中间位置

Root Index Entry不是定长的，因此需要在Trail Block中的dataIndexCount记录entry数量才能保证正常加载。

NonRoot Index一般有intermediate和leaf两层，具有相同结构。Index Entry指向leaf索引块或者数据块。NonRoot index通过entry Offset实现索引块内的二分查找来优化查询效率。

图片选自 hbasefly.com/2016/04/03/…

完整的索引流程如下图，rowkey通过多级索引以类似B+树的方式定位到所属的数据块。

图片选自 hbasefly.com/2016/04/03/…

HBase集群架构

Zookeeper

提供分布式一致性的元数据管理服务。HBase使用Zookeeper实现master节点信息登记、master节点选主、RegionServer信息登记、分布式任务管理等功能。

HMaster

元信息管理组件，以及集群调度、保活等功能。通常部署一个主节点和一到多个备节点，通过Zookeeper选主。

RegionServer

提供数据读写服务，每个实例负责一段不重叠的连续rowkey范围内的数据

ThriftServer

提供一层以Thrift协议访问数据的代理层。

HMaster主要组件

CatalogJanitor

定期扫描元数据hbase:meta的变化，回收无用的region（仅当没有region-in-transition时）。

scan方法执行扫描、回收操作：

扫描一遍hbase:meta找出可回收的region，检查元数据一致性并生成报告实例
已完成merge或split的region都可被回收，即子目录/父目录没有reference文件后
创建GCMultipleMergedRegionsProcedure/GCRegionProcedure异步回收regions
1. GCMultipleMergedRegionsProcedure步骤：
  1. merge的两个源region分别创建GCRegionProcedure删除region数据
  2. 删除merge生成region元信息的merge qualifiers（info:mergeN）
2. GCRegionProcedure步骤：
  1. archive要回收region的HFiles
  2. 删除region对应的WAL
3. assignmentManager删除region state
4. meta表删除该region记录
5. masterService、FavoredNodesManager删除该region

AssignmentManager

管理region分配，processAssignQueue方法每当pendingAssignQueue放满RegionStateNode时批量处理。单独启动daemon线程循环处理。

processAssignmentPlans方法雇用LoadBalancer

首先尝试尽量保持现有分配
将分配plan的目标server region location更新到对应RegionStateNode中
将regionNNode的ProcedureEvent放入队列，统一唤醒所有regionNodes的events上等待的procedures
不保持原有分配的通过loadbalancer的round-robin策略分配（原则是不能降低availability）
分配失败的塞回pendingAssignQueue下次重新处理

setupRIT方法处理RIT，仅仅是设置RegionStateNode的this.procedure和ritMap

HMaster启动流程

先将自己加到backup master的ZK目录下，这样抢主失败了active master能感知到backup；
除非关闭master，无限循环尝试写入active master的ZK目录来抢主，成功的话从backup目录删除自己的znode；失败的话监听ZK上activeMaster的znode，主挂了就再次抢主
初始化文件系统相关组件
1. MasterFileSystem - 封装对底层HDFS文件系统的交互
2. MasterWalManager - 封装master分裂WAL操作，管理WAL文件、目录
3. TableDescriptor - 管理table信息，预加载所有table的信息
发布clusterID到ZK，位于/hbase/hbaseid
加文件锁防止hbck1在hbase2集群执行造成数据损坏
初始化以下master状态管理组件
1. ServerManager - 管理regionserver状态（online/dead），处理rs启动、关闭、恢复
2. SplitWALManager - 代替ZK管理split WAL的procedures，
3. ProcedureExecutor - 负责调度、执行、恢复procedures，包含以下组件
  1. WALProcedureStore - 持久化记录procedure状态，用于故障恢复未完成的procedure。
  2. MasterProcedureScheduler - 针对procedure类型选择合适的并发控制，例如region是server/namespace/table/region等粒度，大致原理是提供不同等级的queue来跑任务。
  4. 只init procedureExecutor来加载procedures但不开始让workers执行，因为要等DeadServers的ServerCrashProcedures调度执行完成，避免重复执行SCP。
4. AssignmentManager - 负责调度region，包含以下组件
  1. RegionStates - 管理内存态的region状态，包括online/offline/RIT的region信息 RegionStateNode表示一个region的内存态状态，和meta表保持一致，会关联TransitRegionStateProcedure以保证最多一个RIT在并发
  2. RegionStateStore - 负责更新region state到meta表 AssignmentManager::start()方法从ZK路径meta-region-server加载meta region state，对第一个meta region（hbase:meta,,1.1588230740）上锁后设置region location、state、唤醒等待着meta region online的event
  3. 从procedure列表里找出RIT，即未完成的TransitRegionStateProcedure，由AssignmentManager::setupRIT方法将RIT的procedures绑定到regionStates里对应的region
5. RegionServerTracker - 监听ZK的rs目录管理online servers，对比ServerCrashProcedure列表、HDFS的WAL目录里的alive/splitting rs记录，delta就是dead servers，并分别调用ServerManager::expireServer安排ServerCrashProcedures；将online rs添加到ServerManager管理。ServerCrashProcedure流程如下：
  1. SERVER_CRASH_START：如果挂了的rs负责meta表，先进入SERVER_CRASH_SPLIT_META_LOGS状态split meta WAL，将rs状态设为*SPLITTING_META* ， MasterWalManager::splitMetaLog在HDFS找到该rs的WAL目录，移动到-splitting结尾的新路径避免更多WAL写入。这里支持用ZK或不用ZK两种模式，先介绍用ZK的模式： SplitLogManager::splitLogDistributed方法过滤出该路径下.meta结尾的WAL文件，为每个文件提交一个Task并记录到ZK目录splitWAL下，由ZkSplitLogWorkerCoordination协调online的regionserver认领并通过SplitLogWorker::splitLog方法处理，核心逻辑在WALSplitter::splitLogFile里，依次读取WAL文件每条entry，格式如下：
    3. 对每个WAL entry的region检查lastFlushedSeqID，如果大于WAL entry的seqID就跳过，否则放入buffer，LogRecoveredEditsOutputSink异步批量写到临时目录里对应region的recovered.edits目录下，具体实现在OutputSink::duRun里，调用LogRecoveredEditsOutputSink::append，最终在ProtobufLogWriter::append方法将rowkey和cells追加写到HDFS里tmp目录下对应region的recovered.edits目录；
    5. 等所有log split都结束后设置serverState为SPLITTING_META_DONE。 不用ZK的模式将上述步骤封装成SplitWALProcedure，由HMaster协调全过程。
    6. \
  2. SERVER_CRASH_ASSIGN_META：ZK模式进入此状态assign meta region上线，然后进入SERVER_CRASH_GET_REGIONS状态获取该宕机rs上的region列表，进入SERVER_CRASH_SPLIT_LOGS状态处理用户数据的WAL split，过程类似上述meta WAL split，全部完成后标记rs的ServerState状态OFFLINE。（非ZK模式通过SplitWALProcedure处理）
  3. SERVER_CRASH_ASSIGN状态assign该rs上所有挂掉的region后进入SERVER_CRASH_FINISH状态删除该rs，标记这个dead server处理完成
6. TableStateManager - meta表确认已online才能启动，负责更新table state到meta表
初始化一系列ZK相关的trackers
1. LoadBalancer
2. RegionNormalizer
3. LoadBalancerTracker
4. RegionNormalizerTracker
5. SplitOrMergeTracker
6. ReplicationPeerManager
7. DrainingServerTracker
8. MetaLocationSyncer + MasterAddressSyncer （client ZK不是observer mode时需要）
9. SnapshotManager
10. MasterProcedureManagerHost
InitializationMonitor - zombie master检测 HBASE-21535
如果是新建集群，安排InitMetaProcedure来初始化元数据，即创建AssignProcedure把meta表region拉起
初始化以下后台服务
1. Balancer
2. CatalogJanitor
3. ExecutorServices
4. LogCleaner
5. HFileCleaner
6. ReplicationBarrierCleaner
等待元数据构建完成
等待足够多RegionServer加入集群，默认至少1个，可配置数量： hbase.master.wait.on.regionservers.maxtostart hbase.master.wait.on.regionservers.mintostart
AssignmentManager::joinCluster扫描meta表每行数据，构建regionStates，wake等待meta加载后执行的任务。
启动其他Chore服务，如：
1. RITChore - 定期巡检RIT数量是否过多并打warn日志和打metrics
2. DeadServerMetricRegionChore - 定期打deadServer相关metrics
TableStateManager::start扫描meta表的table:state column和HDFS上每个table目录下.tabledesc目录下最新的$seqNum.tableinfo文件（即seqNum最大的.tableinfo文件），将meta表里的tableState添加到内存中的tableState，HDFS里不存在则设置为ENABLED
assignmentManager::processOfflineRegions对每个offline region创建AssignProcedure，按round-robin策略分配
如果开启了favoredNode功能，扫meta创建一个索引多种查询模式（rs->region, region->rs等）的元数据快照来初始化favoredNodesManager
启动Chore服务
1. ClusterStatusChore
2. BalancerChore
3. RegionNormalizerChore
4. CatalogJanitor
5. HbckChore
assignmentManager检查regionserver实例是否存在不同版本，是则移动所有system table到版本最新的rs上以保证兼容性。
初始化quota
serverManager.clearDeadServersWithSameHostNameAndPortOfOnlineServer清楚deadServer里相同host和port的已经online的rs，因master初始化期间加入的rs未更新状态，见HBASE-5916
检查ZK上ACL配置
初始化MobCleaner
最后刷新下balancer的RegionLocationFinder
创建master addr tracker，注册到zk，阻塞等待master上线
等待master实例在zk设置集群状态为已上线
从zk读取clusterID
等待active master上线
初始化RegionServerProcedureManagerHost并加载procedures，包括：

RegionServerSnapshotManager

RegionServerFlushTableProcedureManager

创建cluster connection和联系master用的rpc client
创建RegionServerCoprocessorHost
反复尝试向master rpc通知本region server上线，直到成功
1. 通过masterAddressTracker.getMasterAddress获取master地址
2. 创建rpc通道并调用rpc regionServerStartup。 master实现如下：
  1. MasterRpcServices.regionServerStartup确认master启动完成
  2. 调用ServerManager.regionServerStartup检查clock ske，以及发起请求的region server是否被记录为dead，是则返回异常让rs自杀。（每次rs启动会携带递增的start code以唯一标识每次重启）通过检查后将该rs加入ServerManager实例内部的onlineServers中（基于ConcurrentSkipListMap）同时移出rsAdmins（HashMap），这里存着未纳入集群的rs。
  3. response返回master看到的该rs的hostname信息，rs发现不一致的话抛异常
在zk创建该region server的临时节点并存储infoPort、versionInfo信息
response还可能返回hbase.rootdir让rs以此目录初始化filesystem。把conf里的rootDir更新成匹配hbase.rootdir配置对应的fs类型，以免用错fs。
初始化WAL和replication。在filesystem创建该region server的wal目录。通过反射创建新replication实例
启动RegionServerPrecedureManagerHost，启动snapshot handler和其他procesure handlers
启动quotaManager
定期向master上报负载信息，调用regionServerReport RPC

Master故障恢复

故障恢复流程即从master实例从ZK监听到主master节点掉了，抢主成功后执行上述启动流程。

RegionServer启动流程

先初始化所有组件但不启动，直到reportForDuty成功注册到Hmaster后才启动所有服务。

在ctor里初始化（不启动）
1. 初始化Netty server event loop用于RPC server/client和WAL
2. 检查Memory limit，HFile version，codecs，初始化UserProvider，配置短路读等
3. 初始化RSRpcServices，其中是所有RPC接口的实现
4. 初始化HFileSystem和FSTableDescriptors
5. 初始化ZK，创建：
  1. ZkCoordinatedStateManager来协调WAL split
  2. MasterAddressTracker管理ZK上当前active master信息，监听主master变化
  3. ClusterStatusTracker管理ZK上的cluster配置信息
6. 创建ChoreService和ExecutorService
7. 拉起rs的webUI
reportForDuty成功上报HMaster（启动服务）
1. 上报前初始化ZK，创建RegionServerProcedureManagerHost并从配置项hbase.procedure.regionserver.classes加载system procedures、RegionServerSnapshotManager和RegionServerFlushTableProcedureManager
2. 初始化可以短路优化本地请求的ClusterConnection和用于HMaster通信的client
3. 从ZK获取当前active master地址，发送RegionServerStartupRequest向master注册本rs
4. 成功收到resp后在handleReportForDutyResponse方法把master返回的KV对加入自身conf，在ZK创建ephemeral znode（默认目录rs/$hostname,$port,$startcode），把rsInfo写入value,PB格式如下：
6. 如果resp里有hbase.rootdir这个key，需要重新初始化FS更新rootDir
7. ZNodeClearer::writeMyEphemeralNodeOnDisk把rs的ZK ephemeral节点路径写入FS里HBASE_ZNODE_FILE环境变量设置的路径。server正常退出时会删除该文件，用来识别server是否正常退出，加速恢复
8. 创建WAL相关目录，并初始化replication的source和sink实例并启动
9. 唤醒等待rs online的线程
10. 启动snapshotManager和其他procedureHandlers，quotaManager
11. 定期调用HMaster的regionServerReport RPC上报server load，报错则尝试重建连接

RegionServer故障恢复

regionserver每次启动的startcode不同，都视为一个新的rs实例，因此走一遍启动流程。

Region上线流程

Region状态转换统一抽象成TransitRegionStateProcedure。RIT即一个region有未完成的TRSP。常见的状态转换包括以下几种：

assign region： GET_ASSIGN_CANDIDATE ------> OPEN -----> CONFIRM_OPENED
1. 设置region的candidate rs，AssignmentManager异步用balancer选择rs打开region。assign是封装成一个AssignmentProcedureEvent创建在RegionStateNode里，AssignmentManager::processAssignQueue批量获取待assign region的regionStateNodes，acceptPlan方法里依次调用每个AssignmentProcedureEvent的wakeInternal方法，将阻塞等待在event上的procedures保序加入procedureScheduler调度队列恢复执行。
2. AssignmentManager::regionOpening更新regionNode状态为OPENING，regionStates添加region和对应的rs记录，创建子过程OpenRegionProcedure，这个RemoteProcedure会向目标rs发送executeProcedures RPC，在RSRpcServices::executeOpenRegionProcedures方法里提交AssignRegionHandler异步地通过HRegion.openHRegion做以下操作：
  1. 写RegionInfo到HDFS上region的目录/ns/table/encodedRegionName下的.regioninfo文件用于恢复meta表数据。如果相同文件内容已存在就跳过，否则覆盖写（先写到region目录下.tmp目录，再move）
  2. initializeStores并发初始化每个cf的HStore，创建cf的hdfs目录，配置blocksize、hdfs storagePolicy、dataBlockEncoding、cell comparator、TTL、低峰期等，创建memstore，创建StoreEngine（集成storeFlusher，compactionPolicy，Compactor，storeFileManager的工厂实例），遍历HDFS上该region该cf的HFiles创建StoreFileInfo集合，并发打开reader，从HFIie读取元信息compectedFiles并移动到archive目录下WIP here
unassign region： CLOSE -----> CONFIRM_CLOSED
reopen/move region： CLOSE -----> CONFIRM_CLOSED -----> GET_ASSIGN_CANDIDATE ------> OPEN -----> CONFIRM_OPENED

同一时刻一个region只能最多有一个TRSP。

HRegion

Region name格式：

 <tablename>,<startKey>,<regionId>_<replicaId>.<encodedName>.
 复制代码

regionId: Usually timestamp from when region was created

encodedName: MD5 hash of the ",,_" part (included only for the new format)

例如：

 ycsb_test,user6399,1600830539266_0.3be086687f0a59f0f3fd74d5041be1bd.
 复制代码

MD5哈希值（上例中的3be086687f0a59f0f3fd74d5041be1bd）作为hbase:meta表的rowkey用于查对应region信息。建表时的region pre-split过程就是预先在hbase:meta表写入记录切分好region，比如用"0000"到"9999"之间的多个数值分别作为region start_key。

代码见private void locateInMeta(TableName tableName, LocateRequest req)

Region Split 热点切分

hbasefly.com/2017/08/27/…

HBase支持的几种常见region split触发策略如下：

ConstantSizeRegionSplitPolicy：0.94版本前默认切分策略。一个region中最大store的大小大于设置阈值之后触发切分。阈值（hbase.hregion.max.filesize）设置较大对大表比较友好，但是小表就有可能不会触发分裂，极端情况下可能就1；设置较小则对小表友好，但一个大表就会在整个集群产生大量的region。
IncreasingToUpperBoundRegionSplitPolicy: 0.94版本~2.0版本默认切分策略。总体来看和ConstantSizeRegionSplitPolicy思路相同，一个region中最大store大小大于设置阈值就会触发切分。阈值计算公式：(#regions) * (#regions) * (#regions) * flush size * 2，最大不超过用户设置的MaxRegionFileSize。这种切分策略很好的弥补了ConstantSizeRegionSplitPolicy的短板，能够自适应大表和小表。
SteppingSplitPolicy: 2.0版本默认切分策略。如果region个数等于1，切分阈值为flush size * 2，否则为MaxRegionFileSize。这种切分策略对于大集群中的大表、小表会比IncreasingToUpperBoundRegionSplitPolicy更加友好，小表不会再产生大量的小region，而是适可而止。

Region split 步骤如下：

找到切分点splitpoint，一般是整个region中最大store中的最大HFile文件中最中心的一个block的首个rowkey。

HBase将整个切分过程包装成了一个事务，意图能够保证切分事务的原子性。整个分裂事务过程分为三个阶段：prepare – execute – (rollback)
prepare阶段：在内存中初始化两个子region，具体是生成两个HRegionInfo对象，包含tableName、regionName、startkey、endkey等。同时会生成一个transaction journal，这个对象用来记录切分的进展
execute阶段：HBase 1.0 版本的 region split 核心操作如下图：

图片选自：blog.cloudera.com/apache-hbas…

regionserver 更改ZK节点 /region-in-transition 中该region的状态为SPLITING。
master通过watch节点/region-in-transition检测到region状态改变，并修改内存中region的状态，在master页面RIT模块就可以看到region执行split的状态信息。
在父存储目录下新建临时文件夹.split保存split后的daughter region信息。
关闭parent region：parent region关闭数据写入并触发flush操作，将写入region的数据全部持久化到磁盘。此后短时间内客户端落在父region上的请求都会抛出异常NotServingRegionException。
核心分裂步骤：在.split文件夹下新建两个子文件夹，称之为daughter A、daughter B，并在文件夹中生成reference文件，分别指向父region中对应文件。生成reference文件的日志如下：

 2017-08-12 11:53:38,158 DEBUG [StoreOpener-0155388346c3c919d3f05d7188e885e0-1] regionserver.StoreFileInfo: reference 'hdfs://hdfscluster/hbase-rsgroup/data/default/music/0155388346c3c919d3f05d7188e885e0/cf/d24415c4fb44427b8f698143e5c4d9dc.00bb6239169411e4d0ecb6ddfdbacf66' to region=00bb6239169411e4d0ecb6ddfdbacf66 hfile=d24415c4fb44427b8f698143e5c4d9dc。
 复制代码

reference文件名前半段是父region对应的HFile文件名，后半段是父region的目录名。

图片选自 hbasefly.com/2017/08/27/…

reference文件内容包括切分点的rowkey，和一个boolean值表示该子文件夹是上半还是下半部分。

父region分裂为两个子region后，将daughter A、daughter B拷贝到HBase根目录下，形成两个新的region。
parent region通知修改 hbase.meta 表后下线，不再提供服务。下线后parent region在meta表中的信息并不会马上删除，而是标注split列、offline列为true，并记录两个子region。
开启daughter A、daughter B两个子region。通知修改 hbase.meta 表，正式对外提供服务。

rollback阶段：如果execute阶段出现异常，则执行rollback操作。为了实现回滚，整个切分过程被分为很多子阶段，回滚程序会根据当前进展到哪个子阶段清理对应的垃圾数据。具体见下图：

图片选自 hbasefly.com/2017/08/27/…

Region split过程不会实际移动文件，而是等到下次compaction时处理。在此之前通过子region的reference文件重定向到原来父region的文件去读数据，流程如下：

图片选自 hbasefly.com/2017/08/27/…

HBase 2.x 版本的 region split 实现去除了对 Zookeeper 的依赖，通过持久化存储的 Procedure 框架在 HMaster 内部闭环管理切分进度，在 HMaster 故障恢复后可恢复进度继续执行或取消。其他部分的实现和 1.0 版本类似。

Region Merge 碎片整合

region merge可以通过HBaseAdmin手动触发，或由normalization触发。merge流程如下：

调用MasterRpcServices::mergeTableRegions方法，从AssignmentManager查找对应regionInfo并调用HMaster::mergeRegions()方法，检查master已完成初始化且merge功能启用后提交NonceProcedureRunnable（关于Nonce的介绍见zhuanlan.zhihu.com/p/75734938）…
MergeTableRegionsProcedure检查待合并的parent regions是否有重复，是否同table，是否相邻，是否重叠，是否主副本，是否online，集群和table状态是否可以merge。检查通过后排序regions并生成合并后region的RegionInfo（计算合并后的startKey，endKey，regionID取待合并regions最大值+1）
调用executeFromState，从MERGE_TABLE_REGIONS_PREPARE状态开始，检查table不能正在打snapshot，merge功能必须开启，如果region上有已merge标记需要成功清除并archive对应HDFS文件。具体逻辑是检查region的目录下是否有referenceFile，没有则提交GCMultipleMergedRegionsProcedure清理已merge的regions文件，并清理HMaster内存里对应的region信息。

GCMultipleMergedRegionsProcedure调用MetaTableAccessor.getMergeRegions检查hbase:meta表里该region的cells，过滤出column为"info:merge.*" regex格式的cell，从value解析RegionInfo，这些就是该region merge前的parent regions。

对父母region分别创建一个GCRegionProcedure，具体在GC_REGION_ARCHIVE状态下调用HFileArchiver.archiveRegion移动region文件到archive目录，如果archive目录下已存在同名文件，尝试加时间戳后缀重命名该文件，失败就删除之。move成功后删除region目录。

然后删除该region对应的WAL文件目录（存着seqid等文件），格式：$rootDir/$cluster/WALs/data/$namespace/table/regionName

然后删除AssignmentManager里该region的状态，再删除meta表里该region的info cf下所有信息。ServerManager::removeRegion清楚该region的两个seqID信息：

The last flushed sequence id for a store in a region
The last flushed sequence id for a region

再清理该region的FavoredNodes。

从meta表删除子region上对应"info:merge.*" regex格式的cq。至此完成清理父母regions里上次merge留下的元数据。
设置AssignmentManager里父母region的状态为MERGING
检查quota是否够，跳过正在执行的normalizer
MERGE_TABLE_REGIONS_CLOSE_REGIONS 关闭父母regions
MERGE_TABLE_REGIONS_CHECK_CLOSED_REGIONS 检查关闭都完成后
MERGE_TABLE_REGIONS_CREATE_MERGED_REGION移除只读副本，创建merge出的新region。具体步骤：
1. 在第一个父region目录下创建.merges临时目录
2. 对父母regions的每个cf分别遍历所有storeFiles，每个storeFile分别创建referenceFile，文件名称格式：${parent_HFile_name_before_merge}.${parent_region_name} 文件内容统一指向原文件的startKey，等效于split里指向上半部分的referenceFile内容。
3. commitMergedRegion将.merged临时目录下的内容move到合并后的子region目录下
4. AssignmentManager创建新region的状态为MERGING_NEW
MERGE_TABLE_REGIONS_WRITE_MAX_SEQUENCE_ID_FILE：从父母region的seqid里找到最大值，写入子region的seqid文件
MERGE_TABLE_REGIONS_UPDATE_META：AssignmentManager将子region的状态设为MERGED， 将父母region删除，regionStateStore.mergeRegions方法原子地操作meta表，删除父母region，添加子region。子region的info cf下会写入父母regions的RegionInfo，cq分别是merge0000和merge0001 。子region状态为CLOSED防止过早被master调度拉起。子region需要添加父母regions作为replication barrier，保证父母regions都完成同步再开始同步子region。
创建AssignProcedure打开子region

Merge过程也只是创建reference等compaction才移动数据，移动前读数据方式如下图：