【HBase 进阶】-- Region 过多的影响 & 合理分区数量

1 背景

          最近，在使用 HBase 预分区时，创建的 region 太多 ，集群不堪重负，由此带来了 HBase 的意外宕机。

 

2 一些概念

推荐查看此文章：https://www.cnblogs.com/swordfall/p/8737328.html

 

3 Region 数量和大小

3.1 Region 数量

我的理解：较少的 region 数量能使群集运行的更加平稳，官方建议：每个 regionserver 拥有小于 100 个 region 时集群最稳定。

3.1.1 为什么合理分配 region 数量有益于集群稳定？

我的理解：

1、MSLAB: 有助于防止堆内存的碎片化，减轻 Full GC , GC 的问题，默认是开启的。但每个 MemStore 需要 2MB（一个列簇对应一个写缓存 Memstore ）。所以如果每个 region 有 2 个列簇，总有 1000 个 region ，就算不存储数据也要 3.95GB 内存空间

2、过多的 region，导致 Memstore 也过多，内存大小触发 Region Server 级别限制导致 flush，这会对用户请求产生较大的影响，可能阻塞该 Region Server 上的更新操作

3、HMaster 要花大量的时间来分配和移动 Region，且过多 Region 会增加 ZooKeeper 的负担

4、从 HBase 读入数据进行处理的 Mapreduce程序，过多 Region 会产生太多Map任务数量，默认情况下一个 region 对应一个map。因此，如果一个 HRegion 中 Memstore 过多，而且大部分都频繁写入数据，每次 flush 的开销必然会很大，因此也建议在进行表设计的时候尽量减少 ColumnFamily 的个数

 
3.1.2 Region 数量计算的公式

((RegionServer Xmx) * hbase.regionserver.global.memstore.size) / (hbase.hregion.memstore.flush.size * (列族数量))

举例：一个 Region Server 有 16GB 内存，则 16384*0.4 / 128 mb 等于 51 个活跃的 region

注意

• 在写多读少的场景下，可适当调高 hbase.regionserver.global.memstore.size，以容纳更多的 region 数量
• 建议分配合理的region数量，根据写请求量的情况，一般 20-200 个之间，可以提高集群稳定性，排除很多不确定的因素，提升读写性能
• 监控 Region Server 中所有 Memstore 的大小总和是否达到了上限（hbase.regionserver.global.memstore.upperLimit ＊ hbase_heapsize，默认 40%的JVM内存使用量），超过可能会导致不良后果，如服务器反应迟钝或 compact 风暴

3.2 region 大小

HBase 1.x 以上版本：官方建议每个 region 大小为 10GB ~20GB  或者 5GB～ 10GB 为最优。

• HBase 中的数据一开始会写入 Memstore，当达到 128MB（默认）后，会 flush 到 disk 上而成为 storefile。
• 当 storefile 数量超过触发因子时（可以配置），会启动 compaction 过程将它们合并为一个 storefile。对集群的性能有一定影响。
• 当合并后的 storefile 大于 max.filesize ，会触发分割动作，将它切分成两个 region。

region 大小的影响：

1. 当hbase.hregion.max.filesize 比较小时，触发split的机率更大，系统的整体访问服务会出现不稳定现象。
2. 当hbase.hregion.max.filesize 比较大时，由于长期得不到split，因此同一个region内发生多次compaction的机会增加了。这样会降低系统的性能、稳定性，因此平均吞吐量会受到一些影响而下降。

所以，hbase.hregion.max.filesize 不宜过大或过小，生产高并发运行下，建议最佳大小 5-10GB！关闭某些重要场景的 hbase 表的major_compact！在非高峰期的时候再去调用 major_compact，这样可以减少 split 的同时，显著提供集群的性能，吞吐量、非常有用。

 

4 参考

• hbase 2.2  book ：http://hbase.apache.org/2.2/book.html#ops.capacity