实时系统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的配置：

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

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

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

禁止split的配置：

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的数据写入。