这段话很好的解释了 OpenTSDB 的 Compaction 机制的工作原理，OpenTSDB 内部的工作原理比这个更复杂，下面我说下我通俗的理解：
为了节省存储空间和提高数据读取速度，OpenTSDB 内部有个数据压缩（即 Compaction）的机制，将设定的某个时间段内某个指标的所有数据压缩成单行，重新写到 HBase；
OpenTSDB 运行时默认把收到的数据（原始数据点）每秒1次的速度批量写到 HBase 上，然后会周期性的触发上面提到的数据压缩机制，把原始数据点拿出来，压缩后重新写回HBase，然后把原始数据点删除，这就虽然我们只往 OpenTSDB 写数据但大量的读和删操作还是会发生的原因；
OpenTSDB 默认的配置是以 3600 秒为区间压缩，实际运行时就是整点触发，这样整点发生的大量读、删操作就可以解释了；
至此，线上 OpenTSDB 实例整点大量读操作造成 HBase 集群压力过大的问题原因基本明了。
找到问题的原因之后，我们想到了以下 2 种解决方案：
禁用 OpenTSDB 的 Compaction 机制，这样 OpenTSDB 就变成了 1 个纯粹的写实例，数据读取速度会有牺牲，因为每次读取需要扫描更多的数据，这个对于业务数据量很大的系统来说可能并不合适；
想办法让 OpenTSDB 的数据压缩过程缓慢进行，这样到 HBase 的流量压力就会平缓很多，但是这样做还是有风险，因为如果从业务系统到 OpenTSDB 的流量暴涨仍然有可能会 HBase 压力过大，不过这就是另外1个问题了，HBase 需要扩容；
实际操作过程中，我们使用了第 2 种方案，修改 OpenTSDB 的源代码中 src/core/CompactionQueue.java 中的 FLUSH_SPEED 常量为 1，重新编译即可。这样改动的实际影响是：默认压缩速度是 2 倍速，即最多半个小时内完成前 1 个小时数据的压缩，重新写回到 HBase，可以把这个调成 1 倍速，给它 1 个小时的时间来完成前 1 个小时数据的 Compaction，这样到 HBase 的流量会平缓很多。
几经辗转，终于找到问题原因所在（离解决问题还有距离），下面是我的几点感受：
解决问题之前，要能够稳定重现，找到真正的问题所在，不能停留在表面，如果不进行几个小时的 HBase 读操作监控，不会发现整点暴涨持续半小时然后回落的问题；
系统的运行环境很复杂，必要的时候要想办法把问题隔离到影响因素更少的环境中，更容易发现问题，比如性能监控平台各组件的混合部署给机器间的流量分析造成了困难；
使用开源软件，最好能深入了解下运行机制，用起来才得心应手，不然出了问题就很麻烦，这次的排查过程让我更加详细的了解了 OpenTSDB 的运行机制；
至此，本文完~
原文地址：OpenTSDB 造成 Hbase 整点压力过大问题的排查和解决, 感谢原作者分享。
下载本文