OpenTSDB的设计之道

原文地址:http://san-yun.iteye.com/blog/1993519

 

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的线程即执行回调链的线程,中间没有线程切换

你可能感兴趣的:(hbase)