HBase HFile Compact吞吐量参数控制优化剖析-OLAP商业环境实战

版权声明：本套技术专栏是作者（秦凯新）平时工作的总结和升华，通过从真实商业环境抽取案例进行总结和分享，并给出商业应用的调优建议和集群环境容量规划等内容，请持续关注本套博客。期待加入IOT时代最具战斗力的团队。QQ邮箱地址：[email protected]，如有任何学术交流，可随时联系。 https://blog.csdn.net/shenshouniu/article/details/84642440

1 Compaction机制是惹事王

莫名其妙的出现IO突然降低，调查的最终结果肯定就是Compaction造成的，但是Compaction又是绝对不可或缺的。因为数据删除的操作并不会真正的删除。

2 吞吐量的获得

Hbase 是运行在JVM内部的程序，如何获取吞吐量呢？HBase内部具体操作就是通过【要合并的文件大小/处理时间】得出的，如果上一次合并没有发生，是无法获取吞吐量的。

3 HBase吞吐量参数控制

hbase.regionserver.throughput.controller:是限制合并和刷写控制器选择，具体场景具体选择：
- 控制合并相关指标：PressureAwareCompactionThroughputController
- 控制刷写相关指标：PressureAwareFlushThroughputController
默认值是：PressureAwareCompactionThroughputController
hbase.hstore.blockingStoreFiles:当StoreFile数量达到该值时，阻塞MemStore刷写动作，注意这里不会阻塞写入请求。
hbase.hstore.compaction.throughput.lower.bound:合并占用吞吐量下限。
hbase.hstore.compaction.throughput.higher.bound:合并占用吞吐量上限。

4 hbase.hstore.blockingStoreFiles 杀手锏

默认值是7，当Store中的HFile数量达到这个数量的时候就会阻塞MemStore刷写动作，注意这里不会阻塞写入请求。
当HFile数量达到这个阻塞值后，会发生MemStore的占用内存数量急剧上升，因此，可能很快的到达Memstore的写入上限：
```
      hbase.hregion.memstore.flush.size * hbase.hregion.memstore.block.multiplier
```

此时HBase集群就崩溃了。所以需要适当的调大hbase.hstore.blockingStoreFiles数值，比如调到20，30，50都差不多，因为HFile文件越多，数据的读取性能会有所下降。但并不会产生致命的阻塞响应。

5 合并刷写与吞吐量的权衡策略

hbase.offpeak.start.hour: 每天非高峰的起始时间，取值为0-23的整数，包含0和23。
hbase.offpeak.end.hour: 每天非高峰的结束时间，取值为0-23的整数，包含0和23。
hbase.hstore.compaction.throughput.lower.bound: 默认是10MB/sec。
hbase.hstore.compaction.throughput.higher.bound:默认是20MB/sec。
pressureRatio:压力比，限制合并时，该参数就是合并压力，限制刷写时，该参数就是刷写压力。这个值就是0-1.0。是一个监控计算值。当大于1时，说明压力太大了，再不合并，集群就不能工作了，pressureRatio越大，代表HFile堆积得越多，或者即将产生越多的HFile。
在非高峰期是不会进行吞吐量限速的，只有在高峰期期间当合并/刷写占用了太大的吞吐量才会休眠，休眠意味着为业务相应留出足够的吞吐量。休眠吞吐量的计算方式为：
```
   lowerBound + (upperBound-lowerBound)*pressureRatio
```
因为保证业务响应的流畅度和合并刷写稳定性（不至于因为HFile过多导致系统阻塞）同等重要，但是却可以进行权衡出优先级。

6 pressureRatio 的孵化

合并压力（compactionPressure）
刷写压力（flushPressure）

合并压力计算公式：

（storefileCount-minFilesToCompact）/(blockingFileCount-minFilesToCompact)

storefileCount:当前StoreFile数量
minFilesToCompact:单次合并文件数量下限（hbase.hstore.compaction.min）
blockingFileCount:就是hbase.hstore.blockingStoreFiles。

结论: 当前StoreFile越大，或者阻塞上限越小，那么合并的压力就越大，因为可能发生阻塞。

刷写压力计算公式：

globalMemstoreSize/memstoreLowerLimitSize

globalMemstoreSize:当前全局的Memstore大小。
memstoreLowerLimitSize：Memstore刷写下限，当全局Memstore达到这个内存占用的数量的时候就会开始刷写。

结论：当前全局的Memstore占用的内存越大，或者刷写的触发条件越小，越有可能引发刷写。最坏结果就是HFile文件数量会越来越多，从而触发阻塞。

结论

通过本文总结一切豁然开朗，你呢？

秦凯新于深圳