Region 分裂策略补充

最新推荐文章于 2022-07-22 11:50:27 发布

有数的编程笔记

最新推荐文章于 2022-07-22 11:50:27 发布

阅读量638

点赞数

分类专栏： HBase

本文链接：https://blog.csdn.net/qq_33446500/article/details/108552369

版权

HBase 专栏收录该内容

24 篇文章 6 订阅

订阅专栏

文章目录

Region分裂策略补充

Region分裂策略补充

Region分裂详见参见Region 分裂

KeyPrefixRegionSplitPolicy

除了简单粗暴地根据大小来拆分，还可以自己定义拆分点。 KeyPrefixRegionSplitPolicy 是 IncreasingToUpperBoundRegionSplitPolicy 的子类，在前者的基础上增加了对分裂点（splitPoint，分裂点就是 Region 被拆分处的 rowkey）的定义。它保证了有相同前缀的 rowkey 不会被拆分到两个不同的 Region 里面。这个策略用到的参数是：KeyPrefixRegionSplitPolicy.prefix_length 表示 rowkey 前缀长度。

该策略会根据 KeyPrefixRegionSplitPolicy.prefix_length 所定义的长度来截取 rowkey 作为分组的依据，同一个组的数据不会被划分到不同的 Region 上。

用 IncreasingToUpperBoundRegionSplitPolicy 拆分策略如下图所示：
在这里插入图片描述用 KeyPrefixRegionSplitPolicy 拆分策略如下图所示：

按照默认的配置肯定会把同一个前缀的数据切分到不同的 Region 上。如果所有数据都只有一两个前缀，那么 KeyPrefixRegionSplitPolicy 就无效了，此时采用默认的策略比较好。如果前缀划分的比较细，那么查询就比较容易发生跨 Region 查询的情况，此时采用 KeyPrefixRegionSplitPolicy 比较好。

KeyPrefixRegionSplitPolicy 策略适用的场景：

数据有多种前缀。
查询多是针对前缀，比较少跨越多个前缀来查询数据。

DelimitedKeyPrefixRegionSplitPolicy

DelimitedKeyPrefixRegionSplitPolicy 策略也是继承自 IncreasingToUpperBoundRegionSplitPolicy，它也是根据 rowkey 前缀来进行切分的。唯一的不同就是： KeyPrefixRegionSplitPolicy 是根据 rowkey 的固定前几位字符来进行判断，而 DelimitedKeyPrefixRegionSplitPolicy 是根据分隔符来判断的。在有些系统中 rowkey 的前缀可能不一定都是定长的。这些场景下严格地要求所有前缀都定长可能比较难，而且这个定长如果未来想改也不容易。使用这个策略需要在表定义中加入以下属性：DelimitedKeyPrefixRegionSplitPolicy.delimiter 表示前缀分隔符。

BusyRegionSplitPolicy

其余的拆分策略都没有考虑热点问题。所谓热点问题就是数据库中的 Region 被访问的频率并不一样，某些 Region 在短时间内被访问的很频繁，承载了很大的压力，这些 Region 就是热点 Region。 BusyRegionSplitPolicy 就是为了解决这种场景而产生的。

如何判断 region 是热点 region?
先要介绍它用到的参数：

hbase.busy.policy.blockedRequests：请求阻塞率，即请求被阻塞的严重程度。取值范围是0.0~1.0，默认是0.2，即20%的请求被阻塞的意思。
hbase.busy.policy.minAge：拆分最小年龄，单位毫秒，默认值是600000，即10分钟，当 Region 的年龄比这个小的时候不拆分，这是为了防止在判断是否要拆分的时候出现了短时间的访问频率波峰，结果没必要拆分的 Region 被拆分了，因为短时间的波峰会很快地降回到正常水平。。
hbase.busy.policy.aggWindow：计算是否繁忙的时间窗口，单位毫秒，默认值是300000，即5分钟。用以控制计算的频率。

计算该 Region 是否繁忙的计算方法如下：

如果“当前时间–上次检测时间>= hbase.busy.policy.aggWindow”，则进行如下计算：这段时间被阻塞的请求/这段时间的总请求 = 请求的被阻塞率（aggBlockedRate）
如果“aggBlockedRate > hbase.busy.policy.blockedRequests”，则判断该 Region 为繁忙。

如果系统常常会出现热点 Region，而对性能有很高的追求，那么这种策略可能会比较适合。它会通过拆分热点 Region 来缓解热点 Region 的压力，但是根据热点来拆分 Region 也会带来很多不确定性因素，因为不清楚下一个被拆分的 Region 是哪个。

DisabledRegionSplitPolicy

设置成 DisabledRegionSplitPolicy 表示关闭 Region 自动拆分。这个策略的源码就一个方法 shouldSplit，并且永远返回 false。
如果使用 DisabledRegionSplitPolicy 让 Region 永不自动拆分之后，依然可以通过手动拆分来拆分 Region。

DisabledRegionSplitPolicy 的作用：
无论设置了哪种拆分策略，一开始数据进入 HBase 的时候都只会往一个 Region 塞数据。必须要等到一个 Region 的大小膨胀到某个阀值的时候才会根据拆分策略来进行拆分。但是当大量的数据涌入的时候，可能会出现一边拆分一边写入大量数据的情况，由于拆分要占用大量 IO，有可能对 HBase 造成一定的压力。如果事先就知道这个 Table 应该按怎样的策略来拆分 Region 的话，可以事先定义拆分点(SplitPoint)。所谓拆分点就是拆分处的 rowkey，比如可以按26个字母来定义25个拆分点，这样数据一到 HBase 就会被分配到各自所属的 Region 里面。这时候就可以把自动拆分关掉，只用手动拆分。