OpenTSDB的compact操作是为了节约存储，那么其是否在读取的时候存在逆向处理的过程？
OpenTSDB的compact只是把数据从多个KeyValue压成一个KeyValue，并没有做其他的工作，而Query的时候，无论有没有进行compact，OpenTSDB总是会根据rowkey进行scan，并且对具有相同的rowkey的KeyValue进行合并，然后进行后续的数值的翻译，再处理好，以rows的形式返回给前端/调用方。如果预先进行了compact，对于Query的性能显然是有帮助的
一个集群中部署了多个OpenTSDB节点后，其各自的compact是否存在冲突、资源浪费或是饥饿？
数据从多个OpenTSDB流入，单个OpenTSDB将只持有经由自己流入的数据的rowkey，如果集群中全部开启了compact，那么每个OpenTSDB节点都将对存在于自己的queue中的rowkey进行周期性的scan、merge，然后写入合并后的cell，删除其它。这个读写的过程，不会存在饥饿，一方面因为，compact并不需要一定凑全一整个row，减少Cell数量同样是积极的，另一方面，任何节点都可以根据rowkey去检索到当前HBase中全部的Cell。这个操作尽管是幂等的，但是必然会为HBase带来多余的读写开销以及OpenTSDB层面的负载。集群模式下，推荐使用单独的节点进行compact操作。
OpenTSDB的查询带来的compaction
OpenTSDB的查询，是通过转义指定的查询条件为rowkey来对HBase进行scan。对于指定的测点与tag，同一个小时的数据有着相同的rowkey，故在这个过程中，OpenTSDB将会以小时为粒度对数据进行merge与sort。因而即使没有开启compact选项，查询的过程中也会进行一次若干KeyValue合并为一个KeyValue的过程，并且该合并操作将写入HBase并删除原始数据，该操作与compaction是等效的。
