Hbase split Region-Toy模板网

这篇具有很好参考价值的文章主要介绍了Hbase split Region。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

Split(Region拆分)

自动拆分

根据region大小触发拆分

早期（0.94版本前）HBase仅根据Region中最大的列簇大小（即一个Store，也即HFile）进行自动拆分，默认拆分阈值为10G，当大小达到10G后，将这个region拆分为两个region。参数为：

hbase.hregion.max.filesize

根据文件大小动态触发拆分

0.94版本之后，有了IncreasingToUpperBoundRegionSplitPolicy策略。即动态限制region大小上限策略。这也是默认的触发方式。

当region数量较少时，触发切分的阈值也较低，随着region数量提升，触发拆分的阈值也随之提升，但不会超过一个限定的值。

当region的数量在0~100之间，则根据以下公式计算触发拆分的阈值：

Math.min( region数量 ^ 3 * 初始大小, 默认最大文件大小  )


#初始大小: 由hbase.increasing.policy.initial.size参数控制，如果没有设置的话，则用memstore的刷写大小的2倍，即hbase.hregion.memstore.flush.size * 2。
#默认最大文件大小: 由hbase.hregion.max.filesize参数控制，即Region最大大小。

例子：

假如hbase.hregion.memstore.flush.size定义为128MB，那么文件大小的上限增长将是这样：
（1）刚开始只有一个文件的时候，上限是256MB，因为1^3 * 1282 = 256MB。
（2）当有2个文件的时候，上限是2GB，因为2^3 * 1282 = 2048MB。
（3）当有3个文件的时候，上限是6.75GB，因为3^3 * 128 * 2 = 6912MB。
（4）以此类推，直到计算出来的上限达到hbase.hregion.max.filesize region所定义的10GB。

Region大小上限的增加如图：当Region个数达到4个的时候由于计算出来的上限已经达到了16GB大于10GB了，所以后面当Region数量再增加的时候文件大小上限已经不会增加了。在最新的版本里IncreasingToUpperBoundRegionSplitPolicy是默认的配置。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HbJgtwsG-1689926911187)(md_photo_file/NoteBook/image-20230721154630826.png)]

以长度自定义拆分前缀

KeyPrefixRegionSplitPolicy 是IncreasingToUpperBoundRegionSplitPolicy的子类。在以文件大小触发region拆分的基础上，可以在拆分时根据rowkey的前缀进行拆分。

如：某个region内包含两种前缀的rowkey，分别为：cn001_{cn999和us001}us999。当触发了对这个region的拆分时，可能前缀为cn的数据中列较多，数据大小更大，按照默认的拆分方式，将这个region按照文件大小平均拆分成两份，则可能有部分前缀为cn的rowkey会和前缀为us的rowkey被放在同一个新的region，如图：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GeXzO1o8-1689926911188)(md_photo_file/NoteBook/image-20230721155900261.png)]

当使用KeyPrefixRegionSplitPolicy的方式拆分，则结果如下：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-PrcTI01H-1689926911188)(md_photo_file/NoteBook/image-20230721155916631.png)]

KeyPrefixRegionSplitPolicy可以保证相同前缀的rowkey不会被拆分到两个不同的Region里面。通过以下参数来指定rowkey前几个字符为前缀：

KeyPrefixRegionSplitPolicy.prefix_length


这个策略适用的场景是：
	1. 数据有多种前缀。
	2. 查询多是针对前缀，比较少跨越多个前缀来查询数据。

以分隔符自定义拆分前缀

DelimitedKeyPrefixRegionSplitPolicy与上面的KeyPrefixRegionSplitPolicy方式相同，都是在以文件大小为触发拆分的基础上根据rowkey前缀进行拆分。区别在于，KeyPrefixRegionSplitPolicy是以字符串长度指定前缀，而DelimitedKeyPrefixRegionSplitPolicy是以分隔符区分前缀，书中举例：如果以服务器的名字来当前缀，有的服务器叫host12有的叫host1,甚至有的服务器较host101。那么以字符串长度就难以区分各服务器名。

但是可以通过如下参数定义前缀分隔符：比如定义了前缀分隔符为_，那么host1_001和host12_999的前缀就分别是host1和host12。

DelimitedKeyPrefixRegionSplitPolicy.delimiter

热点region拆分策略

上述几种都是根据文件大小为触发条件进行region拆分。但是，假如两个大小相同的region，且都远没有达到触发拆分条件的文件大小，而其中一个region由于包含较多的热点rowkey，导致这个region的访问量远大于另一个region，已经不堪重负，但是region大小离触发拆分条件还遥遥无期，拆分这个region已迫在眉睫。

BusyRegionSplitPolicy就是为了解决这种场景而产生的。

BusyRegionSplitPolicy策略通过以下参数判断哪些region为热点region：

hbase.busy.policy.blockedRequests：请求阻塞率，即请求被阻塞的严重程度。取值范围是0.0~1.0，默认是0.2，即20%的请求被阻塞的意思。

hbase.busy.policy.minAge：拆分最小年龄，当Region的年龄比这个小的时候不拆分，这是为了防止在判断是否要拆分的时候出现了短时间的访问频率波峰，结果没必要拆分的Region被拆分了，因为短时间的波峰会很快地降回到正常水平。单位毫秒，默认值是600000，即10分钟。

hbase.busy.policy.aggWindow：计算是否繁忙的时间窗口，单位毫秒，默认值是300000，即5分钟。用以控制计算的频率。

判断Region是否属于热点region的逻辑如下：

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

禁止拆分region

DisabledRegionSplitPolicy策略会禁止Region自动拆分，但是可以通过手动拆分来拆分Region。

预拆分

即在建表时就指定region个数以及拆分条件。书中介绍的是通过命令行创建，但是一般在HBase的web界面创建更加方便，所以不做记录。文章来源地址https://www.toymoban.com/news/detail-602400.html

手动拆分

可以在hbase shell中调用split方法手动拆分region。
split方法的调用方式如下:

split 'tableName'
split 'namespace:tableName'
split 'regionName' # format: 'tableName,startKey,id'
split 'tableName', 'splitKey'
split 'regionName', 'splitKey'