hbase集群负载均衡与高性能的关键——region分割与合并_hbase region均衡

HBase通过对表的Region数量实现简单的负载均衡，官方认为这种实现是简洁而高效的，能满足绝大部分的需求。接下来和大家和分享一下自动的负载均衡和手动控制的负载均衡。如下几种情况时，当前集群不会执行负载均衡：
1、master没有被初始化
2、当前已有负载均衡方法在运行
3、有region处于splitting状态
4、集群中有死掉的region server

---

#第一部分、分割(split)

split是切分、切割、分裂的意思，用来描述region的切分行为。

【与region有关的存储结构介绍】
hbase中的Region是一张表的子集，也就是说把一张表在水平方向上切割成若干个region。一张表一开始的时候只有一个region(区域)，随着数据量的增长，会自动(或手动)切分出来越来越多的region。HBase中针对表采用”Range分区”，把rowkey的完整区间切割成一个个的”Key Range” ，每一个”Key Range”称为一个Region，所以说region其实是按照连续的rowKey存储的区间。
不同Region分布到不同Region Server上，region是Hbase集群分布数据的最小单位，或者说region是HBase中分布式存储和负载均衡的最小单元，但不是存储的最小单元。存储的最小单元是store file（也叫Hfile）。Store File是存放数据的地方，里面存的是一个列簇的数据，每一条数据都是key-value，store file的内部是按照rowkey有序排列的，但是store file之间是无序的。

【为什么要切分region】
更大的Region使得我们集群上的Region的总数量更少，而数量更少的region能让集群运行更顺畅。如果region数目太多就会造成读写性能下降，也会增加ZooKeeper的负担。但是region数目太少会妨碍可扩展性，降低读写并发性能，会导致压力不够分散。综合权衡集群的负载和性能，需要把过大的region做切分，切成更小的region分散到更多regionServer上去，以缓解region server过大的压力，从而均衡每一台region server负载。根据写请求量的情况，region数量在20~200个之间可以提高集群稳定性、提升读写性能。

【与切分region有关的配置】
对于在线型应用来说，store file（hbase.hregion.max.filesize）的大小一般是线下型应用设置参数的两倍。
监控Region Server中所有Memstore的大小总和是否达到了上限（hbase.regionserver.global.memstore.upperLimit ＊ hbase_heapsize，默认40%的JVM内存使用量），超过会导致不良后果，如服务器反应迟钝或compact风暴。
hbase.regionserver.global.memstore.upperLimit 的缺省值为0.4，即JVM内存的40%.

【region切分策略】
常用的有三种策略：
（1）ConstantSizeRegionSplitPolicy：小于0.94版本的hbase只有这个分裂策略。当region中的一个store（对应的是一个列簇的一个 Hfile ）超过了配置参数hbase.hregion.max.filesize 的阈值时拆分成两个。region拆分线是最大storefile的中间rowkey。
（2）IncreasingToUpperBoundRegionSplitPolicy：这个是0.94~1.x版本默认的分裂策略。按固定长度分割region，固定长度取值优先获取table的”MAX_FILESIZE” 值，若没有设定该属性，则采用在hbase-site.xml中配置的hbase.hregion.max.filesize值，从0.94版本开始，这个值的缺省值已经被调整为：10 * 1024 * 1024 * 1024L 也就是10G，网上很多关于 hbase.hregion.max.filesize 默认值 1G的文章应该都是基于0.92的hbase的。采用该策略后，当table的某一region中的某一store大小超过了预定的最大固定长度时，对该region进行split。切割点(splitPoint)算法的选择是依据“数据对半”原则找到该region的最大store的中间长度的rowkey进行切割。不论是哪种切分策略，ConstantSizeRegionSplitPolicy、IncreasingToUpperBoundRegionSplitPolicy 或 SteppingSplitPolicy，对切分点的定义都是一致的。但是用户手动执行切分时是可以指定切分点进行切分的。
（3）SteppingSplitPolicy: 2.x版本的默认切分策略。这种策略的切分阈值发生了变化，相比IncreasingToUpperBoundRegionSplitPolicy简单了一些，依然和待分裂region所属表在当前RegionServer上的region个数有关系：如果region个数等于1，切分阈值为flush size * 2，否则为MaxRegionFileSize。这种策略对于大集群中的大表、小表会比IncreasingToUpperBoundRegionSplitPolicy更加友好，小表不会再产生大量的小region，而是适可而止。

【 拆分region的步骤 】
Region的拆分操作是不可见的，因为Master不会参与其中，REGION SERVER负责拆分。RegionServer拆分region的步骤是：
将待切割的region下线 ==> 拆分成2个子region ==> 将子region加入到hbase:meta中，再将它们加入到原本的RegionServer中 ==> RegionServer将本机最新的region信息汇报给Master

####[官方文档的切分过程描述]

1. RegionServer decides locally to split the region, and prepares the split. As a first step, it creates a znode in zookeeper under /hbase/region-in-transition/region-name in SPLITTING state.
2. The Master learns about this znode, since it has a watcher for the parent region-in-transition znode.
3. RegionServer creates a sub-directory named “.splits” under the parent’s region directory in HDFS.
4. RegionServer closes the parent region, forces a flush of the cache and marks the region as offline in its local data structures. At this point, client requests coming to the parent region will throw NotServingRegionException. The client will retry with some backoff.
5. RegionServer create the region directories under .splits directory, for daughter regions A and B, and creates necessary data structures. Then it splits the store files, in the sense that it creates two Reference files per store file in the parent region. Those reference files will point to the parent regions files.
6. RegionServer creates the actual region directory in HDFS, and moves the reference files for each daughter.
7. RegionServer sends a Put request to the .META. table, and sets the parent as offline in the .META. table and adds information about daughter regions. At this point, there won’t be individual entries in .META. for the daughters. Clients will see the parent region is split if they scan .META., but won’t know about the daughters until they appear in .META… Also, if this Put to .META. succeeds, the parent will be effectively split. If the RegionServer fails before this RPC succeeds, Master and the next region server opening the region will clean dirty state about the region split. After the .META. update, though, the region split will be rolled-forward by Master.
8. RegionServer opens daughters in parallel to accept writes.
9. RegionServer adds the daughters A and B to .META. together with information that it hosts the regions. After this point, clients can discover the new regions, and issue requests to the new region. Clients cache the .META. entries locally, but when they make requests to the region server or .META., their caches will be invalidated, and they will learn about the new regions from .META…
10. RegionServer updates znode /hbase/region-in-transition/region-name in zookeeper to state SPLIT, so that the master can learn about it. The balancer can freely re-assign the daughter regions to other region se