HBase Region划分策略总结

不念不忘少年蓝@ 2022-06-02 00:22 219阅读 0赞

## 1.Region切分触发策略 ##

在最新稳定版(1.2.6)中，HBase已经有多达6种切分触发策略。当然，每种触发策略都有各自的适用场景，用户可以根据业务在表级别选择不同的切分触发策略。常见的切分策略如下图

![这里写图片描述][wKioL1mjyuSjy_9oAAAjEFQ20JA132.jpg-wh_651x-s_333393195.jpg]

*  **ConstantSizeRegionSplitPolicy：0.94版本前默认切分策略**

这是最容易理解但也最容易产生误解的切分策略，从字面意思来看，当region大小大于某个阈值(hbase.hregion.max.filesize)之后就会触发切分，实际上并不是这样，真正实现中这个阈值是对于某个store来说的，即一个region中最大store的大小大于设置阈值之后才会触发切分。另外一个大家比较关心的问题是这里所说的store大小是压缩后的文件总大小还是未压缩文件总大小，实际实现中store大小为压缩后的文件大小(采用压缩的场景)。ConstantSizeRegionSplitPolicy相对来来说最容易想到，但是在生产线上这种切分策略却有相当大的弊端：切分策略对于大表和小表没有明显的区分。阈值(hbase.hregion.max.filesize)设置较大对大表比较友好，但是小表就有可能不会触发分裂，极端情况下可能就1个，这对业务来说并不是什么好事。如果设置较小则对小表友好，但一个大表就会在整个集群产生大量的region，这对于集群的管理、资源使用、failover来说都不是一件好事。

*  **IncreasingToUpperBoundRegionSplitPolicy : 0.94版本~2.0版本默认切分策略**

切分策略稍微有点复杂，总体看和ConstantSizeRegionSplitPolicy思路相同，一个region中最大store大小大于设置阈值就会触发切分。但是这个阈值并不像ConstantSizeRegionSplitPolicy是一个固定的值，而是会在一定条件下不断调整，调整规则和region所属表在当前regionserver上的region个数有关系 ：(\#regions) \* (\#regions) \* (\#regions) \* flush size \* 2，当然阈值并不会无限增大，最大值为用户设置的MaxRegionFileSize。这种切分策略很好的弥补了ConstantSizeRegionSplitPolicy的短板，能够自适应大表和小表。而且在大集群条件下对于很多大表来说表现很优秀，但并不完美，这种策略下很多小表会在大集群中产生大量小region，分散在整个集群中。而且在发生region迁移时也可能会触发region分裂。

*  **SteppingSplitPolicy: 2.0版本默认切分策略**

这种切分策略的切分阈值又发生了变化，相比 IncreasingToUpperBoundRegionSplitPolicy 简单了一些，依然和待分裂region所属表在当前regionserver上的region个数有关系，如果region个数等于1，切分阈值为flush size \* 2，否则为MaxRegionFileSize。这种切分策略对于大集群中的大表、小表会比 IncreasingToUpperBoundRegionSplitPolicy 更加友好，小表不会再产生大量的小region，而是适可而止。

另外，还有一些其他分裂策略，比如使用DisableSplitPolicy:可以禁止region发生分裂;而KeyPrefixRegionSplitPolicy，DelimitedKeyPrefixRegionSplitPolicy对于切分策略依然依据默认切分策略，但对于切分点有自己的看法，比如KeyPrefixRegionSplitPolicy要求必须让相同的PrefixKey待在一个region中。

在用法上，一般情况下使用默认切分策略即可，也可以在cf级别设置region切分策略，命令为：

create ’table’, {NAME => ‘cf’, SPLIT_POLICY => ‘org.apache.hadoop.hbase.regionserver. ConstantSizeRegionSplitPolicy'}

**Region切分准备工作-寻找SplitPoint**

region切分策略会触发region切分，切分开始之后的第一件事是寻找切分点-splitpoint。所有默认切分策略，无论是ConstantSizeRegionSplitPolicy、 IncreasingToUpperBoundRegionSplitPolicy 抑或是SteppingSplitPolicy，对于切分点的定义都是一致的。当然，用户手动执行切分时是可以指定切分点进行切分的，这里并不讨论这种情况

那切分点是如何定位的呢? 整个region中最大store中的最大文件中最中心的一个block的首个rowkey 。这是一句比较消耗脑力的语句，需要细细品味。另外，HBase还规定，如果定位到的rowkey是整个文件的首个rowkey或者最后一个rowkey的话，就认为没有切分点。

什么情况下会出现没有切分点的场景呢?最常见的就是一个文件只有一个block，执行split的时候就会发现无法切分。很多新同学在测试split的时候往往都是新建一张新表，然后往新表中插入几条数据并执行一下flush，再执行split，奇迹般地发现数据表并没有真正执行切分。

**Region核心切分流程**

HBase将整个切分过程包装成了一个事务，意图能够保证切分事务的原子性。整个分裂事务过程分为三个阶段：prepare – execute – (rollback)

*  prepare阶段：在内存中初始化两个子region，具体是生成两个HRegionInfo对象，包含tableName、regionName、startkey、endkey等。同时会生成一个transaction journal，这个对象用来记录切分的进展，具体见rollback阶段。
 *  execute阶段：切分的核心操作。见下图(来自 Hortonworks )：

![这里写图片描述][wKiom1mjyw2jkDE2AACG3viC158735.jpg]

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

![这里写图片描述][wKiom1mjyxrg_i6iAAAXDxn-_P0243.jpg]

除此之外，还需要关注reference文件的文件内容，reference文件是一个引用文件(并非linux链接文件)，文件内容很显然不是用户数据。文件内容其实非常简单，主要有两部分构成：其一是切分点 splitkey，其二是一个boolean类型的变量(true或者false)，true表示该reference文件引用的是父文件的上半部分(top)，而false表示引用的是下半部分 (bottom)。

6.父region分裂为两个子region后， 将daughter A、daughter B拷贝到HBase根目录下，形成两个新的region。

7.parent region通知修改 hbase.meta 表后下线，不再提供服务。下线后parent region在meta表中的信息并不会马上删除，而是标注split列、offline列为true，并记录两个子region

![这里写图片描述][wKiom1mjyyejVU8XAAA6lEp3Gf8160.jpg]

8.开启daughter A、daughter B两个子region。通知修改 hbase.meta 表，正式对外提供服务

![这里写图片描述][wKiom1mjyzWx6vEGAAA-Rr4zyq0854.jpg]

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

![这里写图片描述][wKioL1mjyy_xVQ-gAACIJcAHPJQ635.jpg]

[wKioL1mjyuSjy_9oAAAjEFQ20JA132.jpg-wh_651x-s_333393195.jpg]: /images/20220602/95d38c9cb86a4ec8abfb6aa18e2e0d6e.png
[wKiom1mjyw2jkDE2AACG3viC158735.jpg]: /images/20220602/9d92cca53dc14b3e9d368327a32f6349.png
[wKiom1mjyxrg_i6iAAAXDxn-_P0243.jpg]: /images/20220602/5e1987a9b1cb458ab76938c92b0831a4.png
[wKiom1mjyyejVU8XAAA6lEp3Gf8160.jpg]: /images/20220602/8499b2aeb8c2467fbc64462e3bc1d605.png
[wKiom1mjyzWx6vEGAAA-Rr4zyq0854.jpg]: /images/20220602/a59c337f39824a3c8f9239969dee9a7f.png
[wKioL1mjyy_xVQ-gAACIJcAHPJQ635.jpg]: /images/20220602/b3eabcd8eac8473d8b8e4ca80f19dbc9.png