您当前的位置:首页 >> 设计
云HBase之OpenTSDB时序引擎压缩优化
发布时间:2019-07-08
 

本文根据演讲视频以及PPT整理而成。

本文将主要围绕以下四个方面进行分享:

  1. OpenTSDB的介绍
  2. OpenTSDB的常见问题
  3. OpenTSDB的压缩优化
  4. 云OpenTSDB的使用模式

本文首先会对OpenTSDB简单介绍,以及使用OpenTSDB时所遇到的常见问题,之后则会重点介绍相对于社区版的OpenTSDB所做的相应改进,最后介绍云OpenTSDB的几种使用模式。

在这里还是要推荐下我自己建的大数据学习交流群740041381,群里都是学大数据开发的,如果你正在学习大数据 ,小编欢迎你加入,大家都是软件开发党,不定期分享干货(只有大数据软件开发相关的),包括我自己整理的一份最新的大数据进阶资料和高级开发教程,欢迎进阶中和进想深入大数据的小伙伴加入。

一、OpenTSDB的介绍

OpenTSDB是一款基于HBase构建的时序数据库,时序数据具有以下特点:

(1)数据为数值类型,常用于监控。

(2)数据通常按照时间顺序抵达。

(3)数据基本不会被更新。

(4)写入较多,读入较少。目前用户在阿里云上部署时序数据库所选择的架构通常为对SLB进行挂载后,对一定数量的OpenTSDB进行部署,最后底层与HBase相关联。

云HBase之OpenTSDB时序引擎压缩优化

OpenTSDB对时序数据具有如下定义,首先在数据存储过程中会创建Metric,可以理解为一个监控的group,并用Tags对数据进行进一步的标识,Metric+Tags的组合代表一个具体的时间线,每一条时间线上会存储多个数据点,其中数据点是一个包含时间和值的二元组,每一条时间线会不断的产生相关数据并进行写入。对于时间精度,OpenTSDB支持秒级和毫秒级的时间精度,在写入的数据中如果数据点的时间戳为10位,则时间精度为秒,如果写入的时间戳为13位,则时间精度为毫秒。接下来简单介绍一下OpenTSDB的存储结构,以写metric=host.cpu, timestamp=1552643656, tags={region:HangZhou,host:30,43,111,255}, value=100为例,这条数据到达HBase存储层后经过了如下转换,其中存储数据metric=host.cpu时,将其映射成唯一UID进行存储。为了减少存储空间,每条时间线每一小时存储一行。因此对于timestamp=1552643656,会将数据转换成小时的起始整秒,同样,对于tags的信息,也会映射成唯一UID进行存储。至此整个RowKey部分便存储完成,对于Column部分,将会记录和这个小时起始时间的偏移量,以及value的值。

云HBase之OpenTSDB时序引擎压缩优化

下面对RowKey和Column的数据格式进行更为详细的介绍,实际上,为了避免同一个Metric拥有很多条时间线导致的写入热点问题,在Metric前面会有加盐的一位数据salt,来打散同一Metric下不同时间线的热点。同时Metric和Tag的默认长度为3个字节,即最多只能分配16777216个UID,为了防止UID超量的问题,可以通过修改相应的参数(tsd.storage.uid.width.metric, tsd.storage.uid.width.tagk, tsd.storage.uid.width.tagv)来进行调整,但需要注意的是,一旦集群已经写入数据后参数便无法再次进行修改。对于Column部分的数据格式来说,秒级和毫秒级的数据格式是有差异的,毫秒级的数据需要更多的空间来进行存储,

二、OpenTSDB的常见问题

接下来介绍OpenTSDB的常见问题,在上文提到,为了避免同一个Metric拥有很多条时间线导致的写入热点问题,会通过对数据加盐一位来将热点打散,但打散后会将Metric分到多个buckets中,此时在进行查询时,有多少个buckets便会并发多少个查询请求到HBase中,此时便有了写入热点与并发查询的权衡问题,过多的并发度很容易将HBase打爆,因此需要考虑实际的HBase的业务规模来进行参数的设置。同样需要注意的一点,该项设置写入数据后,也无法进行修改。

云HBase之OpenTSDB时序引擎压缩优化

第二个问题是Tags的笛卡儿积影响查询效率,假设一个监控机器CPU情况的mertric=host.cpu有三个tag,分别是机房区域region,主机名host,cpu单核编号core。这三个tag的数量分别为10,100,8。那么该mertric会包含101008=8000条时间线,假使现在需要查询某一条时间线上的数据,也需要访问8000条时间线上的数据才能得到所需要的结果,其根本原因在于tag是没有索引的,目前常见的解决办法主要有两种,一种是将tag提至RowKey前,来进行索引的建立,另一种是在RowKey中拼接tag的部分信息来减少笛卡儿积。OpenTSDB还有一些其他的查询问题,比如数据不是流式处理,数据点要全部放入到TSDB内存后才会开始进行聚合处理,容易OOM;一个大的查询只会分配给一台TSDB上进行处理,不能分布式处理;即使只查询15分钟的数据,也需要遍历一小时的数据等。

云HBase之OpenTSDB时序引擎压缩优化

第三个问题便是OpenTSDB的压缩问题,即整点压缩对HBase产生流量冲击。为了节省存储空间,OpenTSDB会将离散的KV合成为一个大的KV,来减少重复字段,所以在整点时间便会有读取-压缩-重写-删除一系列的操作产生,这些操作会对HBase发起大量的IO请求,导致长时间的数倍流量波峰,很容易将HBase打爆。因此需要更高的机器规模来抵抗波峰。

云HBase之OpenTSDB时序引擎压缩优化

三、OpenTSDB的压缩优化

事实上,如果能够消除流量波峰,可以极大的降低运营成本,提高系统的稳定性。传统数据压缩的步骤是先从HBase中读取上一个小时写入的所有数据,然后在OpenTSDB中压缩这些读出的数据,并将压缩好的数据写入HBase中,最后将旧的数据从HBase中删除,可以看出压缩数据中存在了大量的OpenTSDB对于HBase的IO请求。为了解决这一问题,需要对OpenTSDB的压缩进行优化,具体的实现思路是将OpenTSDB的压缩过程下沉到底层HBase中,因为HBaes自身压缩数据时便会对数据进行读写,在此时对数据进行处理,复用HBase压缩过程的流量,在合并HFile的时候将KV按照OpenTSDB的数据格式进行合并,便可以避免OpenTSDB对HBase发起大量的IO请求,从而避免了流量波峰。

云HBase之OpenTSDB时序引擎压缩优化

四、云OpenTSDB的使用模式

最后介绍一下云OpenTSDB的几种使用模式,一种是独享模式,即完全独立部署的时序数据库,适合时序业务较重,需要分离部署的情况。

云HBase之OpenTSDB时序引擎压缩优化

另一种是共享模式,可以复用已经购买的云HBase,适合时序业务较小,或者使用HBase云资源较小的情况,可以在一定程度上节约成本。

云HBase之OpenTSDB时序引擎压缩优化