Hbase优化之Region分割设置的问题

Hbase一张表可以分别存储在几个Region上，一个Region又分成了好多store，一个store又分成了Memstore和StoreFile,当Memstore满64MB后，会把数据flush到disk上而成为storefile，当storefile数量超过3（设置）时，会启动compaction过程将它们合并为一个storefile。这个过程中会删除一些timestamp过期的数据，比如update的数据。而当合并后的storefile大小大于hfile默认最大值时，会触发split动作，也就是说，当一个Region内的所有存储文件中最大的那个HFile大于hbase.hregion.max.filesize所设置的大小，则将一个Region切分成两个Region。

调整hbase-site.xml中的 hbase.hregion.max.filesize属性.旧版本默认为256MB，可以自行配置。

<property>
    <name>hbase.hregion.max.filesize</name>
    <value>1073741824</value>
    <description>
    Maximum HStoreFile size. If any one of a column families' HStoreFiles has
    grown to exceed this value, the hosting HRegion is split in two.
    Default: 1G.   
    </description>
  </property>

当实时系统进行大量写入时，hbase通过split region实现水平的sharding，但在split的过程中旧的region会下线，新region还会做compaction，中间有一段时间大量的数据不能被读写，这对于online系统是不能忍受的。
我们可以禁掉自动的split，而在晚上系统空闲时执行我们的splittool手动的split。或者将Region设置的大一点，splittool的逻辑比较简单。遍历所有region的信息，如果region大小大于某值（比如1G）则split该region，这样为一轮split，如果一轮后没有大于某值的region则结束，如果还有大于某个值的region则继续新一轮split，直到没有region大于某个阈值为止。这里提一下判断split完成的方法：通过检查hdfs上旧region的文件夹是否被清除来判断split是否结束。
a 当hbase.hregion.max.filesize比较小时，触发split的机率更大，而split的时候会将region offline，因此在split结束的时间前，访问该region的请求将被block住，客户端自我block的时间默认为1s。当大量的region同时发生split时，系统的整体访问服务将大受影响。因此容易出现吞吐量及响应时间的不稳定现象。
b 当hbase.hregion.max.filesize比较大时，单个region中触发split的机率较小，大量region同时触发split的机率也较小，因此吞吐量较之小hfile尺寸更加稳定些。但是由于长期得不到split，因此同一个region内发生多次compaction的机会增加了。compaction的原理是将原有数据读一遍并重写一遍到hdfs上，然后再删除原有数据。无疑这种行为会降低以io为瓶颈的系统的速度，因此平均吞吐量会受到一些影响而下降。
综合以上两种情况，hbase.hregion.max.filesize不宜过大或过小，但是更大的Region可以使你集群上的Region的总数量较少，而更少的Region可以使你的集群运行更加流畅。一般在线型应用的max.filesize是线下型应用设置参数的两倍。