HBase Region自动切分的所有细节都在这里了

Region主动切分是HBase可以或许拥有优胜扩大性的最重要身分之一，也必定是所有分布式体系寻求无穷扩大性的一副良药。HBase体系中Region主动切分是若何实现的，这琅绫擎涉及很多常识点，比如Region切分的触发前提是什么、Region切分的切分点在哪里、若何切分才能最大年夜的包管Region的可用性、若何做好切分过程中的异常处理、切分过程中要不要将数据移动等，这篇文┞仿将会对这些细节进行根本的解释，一方面可以让大年夜家对HBase中Region主动切分有加倍深刻的懂得，另一方面如不雅想实现类似的功能也可以参考HBase的实现筹划。

Region切分触发策略

在最新稳定版（1.2.6）中，HBase已经有多达6种切分触发策略。当然，每种触发策略都有各自的实用处景，用户可以根据营业在表级别选择不合的切分触发策略。常见的切分策略如下图：

ConstantSizeRegionSplitPolicy：0.94版本前默认切分策略。这是最轻易懂得但也最轻易产生误会的切分策略，大年夜字面意思来看，当region大年夜小大年夜于某个阈值（hbase.hregion.max.filesize）之后就会触发切分，实际上并不是如许，真正实现中这个阈值是对于某个store来说的，即一个region中最大年夜store的大年夜小大年夜于设置阈值之后才会触发切分。

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

别的一个大年夜家比较关怀的问题是这里所说的store大年夜小是紧缩后的文件总大年夜小照样未紧缩文件总大年夜小，实际实现中store大年夜小为紧缩后的文件大年夜小（采取紧缩的场景）。ConstantSizeRegionSplitPolicy相对来来说最轻易想到，然则在临盆线上这种切分策略却竽暌剐相昔时夜的弊病：切分策略对于大年夜表和小表没有明显的区分。阈值（hbase.hregion.max.filesize）设置较大年夜对大年夜表比较友爱，然则小表就有可能不会触发决裂，极端情况下可能就1个，这对营业来说并不是什么功德。如不雅设置较小则对小表友爱，但一个大年夜表就会在全部集群产生大年夜量的region，这对于集群的治理、资本应用、failover来说都不是一件功德。

3. 父region什么时刻会被删除？

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中。

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

Region切分预备工作：寻找Splitpoint

那切分点是若何定位呢？全部region中最大年夜store中的最大年夜文件中最中间的一个block的首个rowkey。这是一句比较消费脑力的语句，须要细细咀嚼。别的，HBase还规定，如不雅定位到的rowkey是全部文件的首个rowkey或者最后一个rowkey的话，就认为没有切分点。

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

什么情况下会出现没有切分点的场景呢？最常见的就是一个文件只有一个block，履行split的时刻就会发明无法切分。很多新同窗在测试split的时刻往往都是新建一张新表，然后往新表中插入几条数据并履行一下flush，再履行split，事业般地发明数据表并没有真正履行切分。原因就在这里，这个时刻细心的话你翻看debug日记是可以看到如许的日记滴：

Region核心切分流程

HBase将全部切分过程包装成了一个事务，意图可以或许包管切分事务的原子性。全部决裂事务过程分为三个阶段：prepare – execute – (rollback) ，操作模版如下：

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

execute阶段：切分的核心操作。见下图（来自Hortonworks）：

1、regionserver 更改ZK节点 /region-in-transition 中该region的状况为SPLITING。

3、在父存储目次下新建临时文件夹.split保存split后的daughter region信息。

4、封闭parent region：parent region封闭数据写入并触发flush操作，将写入region的数据全部持久化稻磁逄。此后短时光内客户端落在父region上的请求都邑抛出异常NotServingRegionException。

5、核心决裂步调：在.split文件夹下新建两个子文件夹，称之为daughter A、daughter B，并在文件夹中生成reference文件，分别指向父region中对应文件。这个步调是所有步调中最核心的一个环节，生成reference文件日记如下所示：

个中reference文件名为

2、master经由过程watch节点/region-in-transition检测到region状况改变，并修改内存中region的状况，在master页面RIT模块就可以看到region履行split的状况信息。

d24415c4fb44427b8f698143e5c4d9dc.00bb6239169411e4d0ecb6ddfdbacf66，格局看起来比较特别，那这种文件名具体什么含义呢？那来看看该reference文件指向的父region文件，根据日记可以看到，切分的父region是00bb6239169411e4d0ecb6ddfdbacf66，对应的切分文件是d24415c4fb44427b8f698143e5c4d9dc，可见reference文件名是个信息量很大年夜的定名方法，如下所示：

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

看官可以应用Hadoop敕令亲自来查看reference文件的具体内容：

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

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

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

rollback阶段：如不雅execute阶段出现异常，则履行rollback操作。为了实现回滚，全部切分过程被分为很多子阶段，回滚法度榜样会根据当进步展到哪个子阶段清理对应的垃圾数据。代码中应用 JournalEntryType 来表征各个子阶段，具体见下图：

Region切分事务性包管

全部region切分是一个比较复杂的过程，涉及到父region中HFile文件的切分、两个子region的生成、体系meta元数据的更改等很多子步调，是以必须包管全部切分过程的事务性，即要么切分完全成功，要么切分完全未开端，在任何情况下也不克不及出现切分只完成一半的情况。

为了实现事务性，HBase设计了应用状况机（见SplitTransaction类）的方法保存切分过程中的每个子步调状况，如许一旦出现异常，体系可以根据当前所处的状况决定是否回滚，以及若何回滚。遗憾的是，今朝实现中这些中心状况都只存储在内存中，是以一旦在切分过程中出现regionserver宕机的情况，有可能会出现切分处于中心状况的情况，也就是RIT状况。这种情况下须要应用hbck对象进行具体查看并分析解决筹划。在2.0版本之后，HBase实现了新的分布式事务框架Procedure V2(HBASE-12439)，新框架将会应用HLog存储这种单机事务（DDL操作、Split操作、Move操作等）的中心状况，是以可以包管即使在事务履行过程中介入者产生了宕机，依然可以应用HLog作为调和者对事务进行回滚操作或者重试提交，大年夜大年夜削减甚至杜绝RIT现象。这也是是2.0在可用性方面最值得等待的一个亮点！

Region切分对其它模块的影响经由过程region切分流程的懂得，我们知道全部region切分过程并没有涉及数据的移动，所以切分成本本身并不是很高，可以很快完成。切分后子region的文件实际没有任何用户数据，文件中存储的仅是一些元数据信息－切分点rowkey等，那经由过程引用文件若何查找数据呢？子region的数据现其实什么时刻完成真正迁徙？数据迁徙完成之后父region什么时刻会被删掉落？

1. 经由过程reference文件若何查找数据？

这里就会看到reference文件名、文件内容的实际意义啦。全部流程如下图所示：

根据reference文件名（region名+真实文件名）定位到真实数据地点文件路径。

定位到真实数据文件就可以在全部文件中扫描待查KV了么？非也。因为reference文件平日都只引用了数据文件的一折半据，以切分点为界，要么上半部分文件数据，要么下半部分数据。那到底哪部分数据？切分点又是哪个点？还记得上文又提到reference文件的文件内容吧，没错，就记录在文件中。

2. 父region的数据什么时刻会迁徙到子region目次？

谜底是子region产生major_compaction时。我们知道compaction的履行实际上是将store中所有小文件一个KV一个KV大年夜小到大年夜读出来之后再次序写入一个大年夜文件，完成之后再将小文件删掉落，是以compaction本身就须要攫取并写入大年夜量数据。子region履行major_compaction后会将父目次中属于该子region的所稀有据读出来并写入子region目次数据文件中。可见将数据迁徙放到compaction这个阶段来做，是一件趁便的事。

有些时刻会有同窗反馈说集群中部分region处于长时光RIT，region状况为spliting。平日情况下都邑建议应用hbck看下什么报错，然后再根据hbck供给的一些对象进行修复，hbck供给了部分敕令对处于split状况的rit region进行修复，重要的敕令如下：

实际上HMaster会启动一个线程按期遍历检查所有处于splitting状况的父region，肯定检查父region是否可以被清理。检测线程起首会在meta表中揪出所有split列为true的region，并加载出其决裂后生成的两个子region（meta表中splitA列和splitB列），只须要检查此两个子region是否还存在引用文件，如不雅都不存在引用文件就可以认为该父region对应的文件可以被删除。如今再来看看上文中父目次在meta表中的信息，就大年夜概可以懂得为什么会存储这些信息了：

4. split模块在临盆线的一些坑？

个中最常见的问题是 ：

简单解释一下，这个缺点是说reference文件所引用的父region文件不存在了，如不雅查看日记的话有可能看到如下异常：

父region文件为什么会莫名其妙不存在？经由和同伙的评论辩论，确认有可能是因为官方bug导致，详见HBASE-13331。这个jira是说HMaster在确认父目次是否可以被删除时，如不雅检查引用文件（检查是否存在、检查是否可以正常打开）抛出IOException异常，函数就会返回没有引用文件，导致父region被删掉落。正常情况下应当保险起见返回存在引用文件，保存父region，并打印日记手工介入查看。如不雅大年夜家也碰到类似的问题，可以看看这个问题，也可以将修复patch打到线上版本或者进级版本。