OpenTSDB造成Hbase整点压力过大问题的排查和解决

来源：动视网责编：小采时间：2020-11-09 13:03:10

OpenTSDB造成Hbase整点压力过大问题的排查和解决

OpenTSDB造成Hbase整点压力过大问题的排查和解决:业务背景 OpenTSDB 是一款非常适合存储海量时间序列数据的开源软件，使用 HBase 作为存储让它变的非常容易扩展。我们在建设美团性能监控平台的过程中，每天需要处理数以亿计的数据，经过几番探索和调研，最终选取了 OpenTSDB 作为数据存储层的重要组件。Op

推荐度：

点击下载本文 文档为doc格式

导读OpenTSDB造成Hbase整点压力过大问题的排查和解决:业务背景 OpenTSDB 是一款非常适合存储海量时间序列数据的开源软件，使用 HBase 作为存储让它变的非常容易扩展。我们在建设美团性能监控平台的过程中，每天需要处理数以亿计的数据，经过几番探索和调研，最终选取了 OpenTSDB 作为数据存储层的重要组件。Op

这段话很好的解释了 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 的流量会平缓很多。