OpenTSDB的设计之道

OpenTSDB是一个架构在Hbase系统之上的实时监控信息收集和展示平台。

它在海量数据的压力下，仍然保证了存储的效率，那么它背后有什么值得借鉴的地方呢？

1）使用AsyncHbase而非HBase自带的HTable。使用线程安全、非阻塞、异步、多线程并发的HBase API，在高并发和高吞吐时，可以获得更好的效果。建议在使用AsyncHBase​时，在CPU core有保证的前提下，可以设置16或者24。

2）采用固定长度的Rowkey，让Rowkey包含尽可能多的检索信息。这一点的话，OpenTSDB存储的数据要包含大量的metrics和tag信息，这些信息的长度是变长的，因此，在实现上设置了一个表格uid-tsdb存储这些信息，作为一个全局唯一的编号，并把编号与TimeStamp合并作为Rowkey。

 

3）每一行要存储尽可能多的信息，这一点在OpenTSDB被发挥到了极致。例如，把某个时间段的分散采集的数据合并在一起，按照一个Row来提交给hbase。这种方案，会减少整个表格Rowkey的个数，从而提高检索Row的速度，但是该方法并没有节省存储空间。

在这个基础上，OpenTSDB又推动了一步，让一个column记录多条内容，从而降低存储空间的浪费。

 

4）按照时间的Boundary来存储，仍采用无状态的存储方案，从而提供系统的容错能力。

 

附录：OpenTSDB中一个KeyValue的存储结构如下：

 

众所周知，与通常RDMS相比，hbase是一个schema-less、面向列存储的nosql数据库，定位一个列元数据至多会经过rowkey->cf->qualifier->version四层索引，其中cf必须在表定义时就指定无法通过后期动态扩展，而version的定位是通过timestamp解决cell数据冲突的，所以大多数实际情况下只有rowkey和qualifier两级索引可以利用。对于time-serial性质的数据，如果每个时间细粒度(假设为秒)的数据都放入rowkey，则会导致region数暴增第一级索引成为瓶颈，opentsdb采用将秒粒度的时间戳变为小时粒度后保留在rowkey中，而将具体的秒信息转化为对小时粒度时间戳的偏移量放入quliafier中，这样一来region数量大大减少，quliafier的数量也不会成为瓶颈（60*60=3600个）。更重要的是每个row中的数据更加聚合，为高效检索提供了保证，因为

a)              hbase的底层存储是HFile文件（基于Hdfs的block数据块），row中的cf可以拥有多个HFile文件，但同一HFile文件中的数据必定属于同一cf，这有利于在读取同一cf数据时尽量少跨HFile或不跨HFile，使需求密集型的数据聚合在同一row中的cf下迎合了hbase这种天然的物理存储特性，大大提高了数据的访问效能。

b)              以时间粗粒度rowkey+细粒度qualifer的方式也很容易满足用户不同粒度的检索需求，假设要查询某小时前10分钟的数据，可以通过hbase自带的qualifierFilter在服务端过滤数据，而无需将小时的数据由服务端全部返回客户端后再自行过滤

另外，opentsdb为了让rowkey包含更多的检索信息，将维度信息以kv对的形式放入rowkey中，当然kv对的数量必须是有限的，opentsdb以正则过滤的方式满足用户对源数据不同维度的检索要求。同时，opentsdb还对metric和tag进行了编码、以及入库数据的压缩，这些都大大降低了数据存储量。

Ø  异步hbase模型

相比hbase自带的同步HTable API，OpenTsdb自己实现了的AsynHbase具有高效、非阻塞、线程安全等特点，在顺序读和写的响应性能上提高了一倍^[4]。

 

Figure 1.2 opentsdb之AsynHbase

       如图1.2，异步化过程描述为：请求者（Data Sink）发送数据请求，获得异步化结果Deferred，注册回调器callbacks到Deferred，完成客户端逻辑所在线程返回；服务端异步执行数据请求服务，将结果写入Deferred，之后触发并执行回调器callbacks，继续数据请求后暂停的逻辑。其中关键的两个地方在于Deferred和Callbacks（异常处理时对应errbacks）

a)      Deferred

同JDK中的Future类似，Deferred也是一种在有限状态机中表示结果暂不可达（not yet available）的状态。不同的是，Deferred绑定了callbacks，而Future只能在后续某个时刻手动地通过get方式拿到异步调用结果，Future的问题就在于调用者并不清楚什么时候结果准备好了。

b)      Callbacks

准确地说，应该是回调链（callbakc chain），链上的前一个callback将返回结果作为参数传递给下一个callback，以此类推直到链末。下面以一个由浅入深的例子来理解下回调链。

假设我们要以RPC的方式从远程主机上获得一些感兴趣的数据，如图1.2，首先通过一个socket发送请求，获得Deferred，并将后续逻辑以callback方式注册到Deferred上。此时回调链上只有我们定义的一个callback

1st callback

Deferred:  user callback

进一步我们需要在客户端增加一层cache以提高性能。考虑缓存未命中的情况，RPC返回的结果首先需要在cache中缓存起来，然后才执行RPC后的逻辑。这时，回调链上是两个callback

     1st callback       2nd callback

                          Deferred:  add to cache  -->  user callback

更进一步，考虑到网络上回来的都是原始字节流，而cache和使用时都是数据对象，所以抽象出更底层的逻辑：验证字节流并反序列化为对象。这时，回调链上是三个callback

               1st callback          2nd callback       3rd callback

Deferred: validate & de-serialize  -->  add to cache  -->  user callback

              result: de-serialized object

最后，考虑复杂的情况，RPC的数据服务方是一个分布式集群，有master/slave之分，这意味着需要两阶段的RPC来请求数据。第一阶段，与master通信获得数据所在的slave；第二阶段，从slave上获取需要的数据，分别对应下面的A和B

(A)     1nd callback    2nd callback    |    (B)      1st callback

Deferred: index lookup    user callback   |   Deferred:  resume (A)

result: lookup response   Deferred (B)    |   result: byte array

在A中，1nd callback通过与master通信返回了slave地址，传递slave地址给user callback并执行第二阶段RPC。由于A的user callback返回的是一个Deferred，调用链在user callback时被中止了（not yet available），所以需要在B中的callback返回结果后恢复A中的调用链。这里体现了Deferred与Future不同的另一大特点：嵌套。通过Deferred的嵌套和调用链组合，可以灵活动态地构建异步处理管道（processing pipeline）。

在使用AsynHbase模型的时候需要明确和注意以下几点：

l  任何时候回调链上最多只能有一个线程在执行

l  回调链上的回调执行有严格的先后顺序，如果一个变量不是共享的，则无需同步

l  将初始结果放入Deferred的线程即执行回调链的线程，中间没有线程切换

l  只要callback开始执行了，Deferred就失去了对其引用

l  向Deferred增加一个callback的代价是O(1)

l  相互循环的Deferred依赖可能导致无限递归，应避免

l  Callback和Errback不能接受Deferred本身为参数

 

参考：http://luoshi0801.iteye.com/blog/1938835