实时系统HBase读写优化--大量写入无障碍

在使用hbase过程中发现在写入hbase的数据量很大时，经常发生写不进去的情况。而我们基于hbase的应用是对实时性要求很高的，一旦hbase不能读写则会大大影响系统的使用。下面将记录hbase写优化的过程。

1.禁止Major Compaction

在hbase进行Major Compaction时，该region将合并所有的storefile，因此整个region都不可读，所有对此region的查询都会block。HBase默认一天左右执行一次Major Compaction。我们将Major Compaction禁掉并用Cron脚本每天在系统空闲时对所有表执行major compaction。

Major Compaction的配置：

 <span style="font-size:18px;"><property>
 <name>hbase.hregion.majorcompactionname>
 <value>0value>
 property>span>

默认是1天，每个region会在创建时以当前时间初始化regionMajorCompactionTime，并将下一次的major compaction时间设为1+-0.2天。配置中将此值设为0禁止major compaction。

major_compaction的脚本：取出所有table，一一执行major_compact：

 "font-size:18px;">TMP_FILE=tmp_tables
 TABLES_FILE=tables.txt

 echo "list" | hbase shell > tmp_tables
 sleep 2
 sed '1,6d' $TMP_FILE | tac | sed '1,2d' | tac > $TABLES_FILE
 sleep 2

 for table in $(cat $TABLES_FILE); do
         echo "major_compact '$table'" | hbase shell
         sleep 10
 done

2.禁掉split

hbase通过split region实现水平的sharding，但在split的过程中旧的region会下线，新region还会做compaction，中间有一段时间大量的数据不能被读写，这对于我们这种online系统是不能忍受的。我们同样禁掉自动的split，而在晚上系统空闲时执行我们的splittool手动的split。

禁止split的配置：

 <span style="font-size:18px;"> <property>
  <name>hbase.hregion.max.filesizename>
  <value>536870912000value>
  property>span>

配置项的含义是当region的大小大于设定值后hbase就会开始split，我们将此值设为500G，我们认为在白天系统繁忙时一个region不会超过此大小，在晚上时运行splittool将region分割开。

splittool的逻辑比较简单。遍历所有region的信息，如果region大小大于某值（比如1G）则split该region，这样为一轮split，如果一轮后没有大于某值的region则结束，如果还有大于某个值的region则继续新一轮split，直到没有region大于某个阈值为止。这里提一下判断split完成的方法：通过检查hdfs上旧region的文件夹是否被清除来判断split是否结束。

3.设置blockingStoreFiles

这个参数的重要性是在我们的性能测试中发现的。我们禁掉major_compaction和split后理论上写入应该无障碍了，但在测试中发现写入单个region速度大于10M/s时还是会出现长时间无法写入的情况。通过查看log，我们发现了这行log“Waited 90314ms on a compaction to clean up 'too many store  files'”，通过查看代码发现原来是blockingStoreFiles这个参数在作怪。

在flushRegion时会检测当前store中hfile的数量是否大于此值，如果大于则会block数据的写入，等待其他线程将hfile compact掉。这样，如果写入速度超过compact的速度，hbase就会阻止该region的数据写入。

 "font-size:18px;">private boolean flushRegion(final FlushRegionEntry fqe) {
     HRegion region = fqe.region;
     if (!fqe.region.getRegionInfo().isMetaRegion() &&
         isTooManyStoreFiles(region)) {
       if (fqe.isMaximumWait(this.blockingWaitTime)) {
         LOG.info("Waited " + (System.currentTimeMillis() - fqe.createTime) +
           "ms on a compaction to clean up 'too many store files'; waited " +
           "long enough... proceeding with flush of " +
           region.getRegionNameAsString());
       }

默认值为7

 "font-size:18px;">this.blockingStoreFilesNumber =
       conf.getInt("hbase.hstore.blockingStoreFiles", 7);
     if (this.blockingStoreFilesNumber == -1) {
       this.blockingStoreFilesNumber = 1 +
         conf.getInt("hbase.hstore.compactionThreshold", 3);
     }

我们将此值设为很大的值，使得此问题不会block我们的写入。

 <span style="font-size:18px;"><property>
 <name>hbase.hstore.blockingStoreFilesname>
 <value>2100000000value>
 property>span>