HBase 底层的IO详解：Region的split工作原理

问题导读

1.Hbase Region 不同版本分别采用什么split策略？
2.HBase整个切分过程是否为事务？
3.整个分裂过程包含哪三个阶段？




相关文章：
HBase数据量过大变慢原因必知：Compaction的原理
https://www.aboutyun.com/forum.php?mod=viewthread&tid=28055


HBase 底层的IO详解：Flush的工作原理
https://www.aboutyun.com/forum.php?mod=viewthread&tid=28047

一个Region代表一个表的一段Rowkey的数据集合，当Region太大，Master会将其拆分。Region太大会导致读取效率太低，遍历时间太长，通过将大数据拆分到不同机器上，分别查询再聚合，Hbase也被人称为“一个会自动分片的数据库”。Region可以手动和自动拆分。




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

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

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

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

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

• prepare阶段：在内存中初始化两个子region，具体是生成两个HRegionInfo对象，包含tableName、regionName、startkey、endkey等。同时会生成一个transaction journal，这个对象用来记录切分的进展，具体见rollback阶段。
  

• execute阶段：切分的核心操作。见下图：
  

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文件日志如下所示： 2017-08-12 11:53:38,158 DEBUG [StoreOpene-0155388346c3c919d3f05d7188e885e0-1] regionserver.StoreFileInfo: reference'hdfs://hdfscluster/hbase-rsgroup/data/default/music/0155388346c3c919d3f05d7188e885e0/cf/d24415c4fb44427b8f698143e5c4d9dc00 其中reference文件名为d24415c4fb44427b8f698143e5c4d9dc.00bb6239169411e4d0ecb6ddfdbacf66，格式看起来比较特殊，那这种文件名具体什么含义呢？那来看看该reference文件指向的父region文件，根据日志可以看到，切分的父region是00bb6239169411e4d0ecb6ddfdbacf66，对应的切分文件是d24415c4fb44427b8f698143e5c4d9dc，可见reference文件名是个信息量很大的命名方式，如下所示：



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


看官可以使用hadoop命令亲自来查看reference文件的具体内容： hadoopdfs-cat/hbase-rsgroup/data/default/music/0155388346c3c919d3f05d7188e885e0/cf/d24415c4fb44427b8f698 6. 父region分裂为两个子region后，将daughter A、daughter B拷贝到HBase根目录下，形成两个新的region。

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



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





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





相关文章：HBase数据量过大变慢原因必知：Compaction的原理
https://www.aboutyun.com/forum.php?mod=viewthread&tid=28055

HBase 底层的IO详解：Flush的工作原理
https://www.aboutyun.com/forum.php?mod=viewthread&tid=28047


HBase 底层的IO详解：Region的split工作原理
https://www.aboutyun.com/forum.php?mod=viewthread&tid=28065


HBase 底层的IO详解：WAL的原理
https://www.aboutyun.com/forum.php?mod=viewthread&tid=28083


————————————————
原文链接：https://blog.csdn.net/qq_42316200/article/details/103210837

感谢分享