作者:场景研读
摘要: 8月24日阿里云数据库技术峰会上,来自阿里数据库事业部高级专家钟宇带来HiTSDB 时序数据库方面的演讲。本文主要从时序数据开始介绍,包括时序序列数据的特点,接着介绍了时序数据业务场景,以及OpenTSDB在HBase上的优化,最后分享了HiTSDB的优化和提高。
8月24日阿里云数据库技术峰会上,来自阿里数据库事业部高级专家钟宇带来HiTSDB 时序数据库方面的演讲。本文主要从时序数据开始介绍,包括时序序列数据的特点,接着介绍了时序数据业务场景,以及OpenTSDB在HBase上的优化,最后分享了HiTSDB的优化和提高。
时序数据就是在时间上分布的一系列数值,时间和数值是两个关键字,时序数据一般指指标型数据,比如股票价格、广告数据、气温变化、网站的PV/UV、个人健康数据、工业传感器数据,还有关于应用程序的性能监控,像服务器系统监控数据,比如cpu和内存占用率,此外还有车联网。
据统计,在大数据领域中时序数据会超过一半。
图为广告的监测数据,可以看到事例中跟踪了三个广告来源,每个来源跟踪了三个指标,包括展示了多少次、点击了多少次以及产生了多少收入。广澳来源是用不同的标签来区分的,比如由谁发布、广告商、针对目标用户的性别和发布在哪个国家等。 大家可以清晰的看到每个指标,在不同的时间点有不同的数值,这就构成了一系列的时间数据。左边成为数据源,中间成为metric,右边称为时间序列,时间序列在时间上具有不同的值,
如果对时间序列建模会有两种方式,一种是单值,一种是多值。单值是把每一个数据源的每一个指标的每一个值当成一行。多值模型是把同一个数据源的不同指标放在不同列中,也就是每个数据源在每个时间点只会产生一行数据。
多值模型一定能用单值模型来模拟,多值模型在处理某些数据时更方便些,但是单值建模可以模拟所有场景。
时间序列数据的处理和一般数据库处理有所不同,一般数据库基于行,每一个数据点是一行,时间序列数据是按时间线处理数据。每个时间线上的数据是非常关联的,比如某一个广告源收入在不同时间上就构成时间序列,这些时间序列中的收入可以画成一条变化曲线,针对曲线我们可以做时间序列变化处理,最常见的是插值和降精度。由于数据源采样的原因,往往会丢失一些点,我们用插值在中间插上常见的线性插值或者零值补偿;如果广告数据不一定需要最细时间粒度来看,我们就可以降精度,不同数据降精度的方式不一样。
针对时间数据,还有一个最常见的处理——聚合,我们往往看的不仅仅是从一个数据源来的指标,如果我们要看北美地区某一个广告源在一段时间内产生的所有收入的总和,我们就需要把跟广告源标签对应的时间线全部挑出来,然后将广告收入时间点加和在一起,得到一个新的求和曲线,如图所示,我们找到了非常多的时间线,最后用某种聚合函数聚合在一起。每一种业务需要的聚合方式也是不一样的,比如广告数据算加和,或者按广告源作平均,也有可能找最大最小值,或者作统计性事情,比如99%值都在某个数值以上。
因此,我们得出时间序列特点包括以下几方面:
阿里巴巴鹰眼系统
阿里巴巴鹰眼系统能跟踪一个分布式系统的系统调用情况,其中就有监控应用指标。包括系统内存处理器占用以及应用本身的TPS和QPS,在实际内部的阿里巴巴系统中,去年的写入峰值是570万点/秒,平均写入350万点/秒,产生了上万个不同的metric,几千万个时间序列,每个时间序列平均有5个维度(tags),每秒几百次聚合展示。
阿里巴巴智慧园区
还有物联网方面,物联网数据与系统监控很像,你可以把设备中的传感器想象成服务器应用的不同指标,比如每盏灯、每个空调出风口的温度等都有指标,阿里巴巴接入的数据跨越两个城市,三个园区,有数以万计的设备,每秒产生数百万的采集点,要求数据写入立即可用。
当传统数据库遇到时间序列数据
时间序列数据存到传统数据库中会遇到一些问题,例如时间序列数据直接保存到关系数据库中(例如MySQL 的InnoDB引擎),使用SQL语句进行分析。这里就会遇到以下一些问题:
OpenTSDB时间序列数据库架构如图所示,它的存储基于HBase,HBase具有高性能,可以线性扩展。TSD被设计为无状态节点,任何一个节点可以随时替换另一个节点进行服务,对外提供的RPC协议是HTTP/Json接口,很方便使用。TSD依赖HBase解决一致性,当TSD产生写时,它一定会将写及时更新到HBase, 而产生读不命中时候,也会从HBase中将数据读回来。
OpenTSDB 存储格式如图所示,它的存储上做了很多针对时序的考虑和优化。
OpenTSDB的缺点
OpenTSDB也有很多缺点,具体如下:
倒排索引
参考搜索引擎的倒排索引实现,每个时间序列作为一个文档,通过tags的倒排索引到时间序列ID,把timestamp + 时间序列ID作为RowKey,取代由timestamp + metric ID + tag IDs拼接成的RowKey。
使用倒排索引的解决的问题和对比如下:
高压缩比算法
我们一般认为最近的数据是最热的,我们希望最近的数据能够完全的被内存缓存,但是时序数据量比较大,因此我们需要采用高压缩比算法:平均每个时间点压缩到1.37字节。timestamp采用delta-delta压缩,value采用二进制xor压缩。
高压缩比使得最近一段时间(若干小时)的数据可以完全缓存在内存里,查询的时候避免了HBase的mget操作。解压缩速度很快,而且降精度可以在解压的过程中同时处理,减少内存的开销。
预降精度功能
我们做了预降精度,HiTSDB会在写入之前根据很多预测好的降精度级别将数据计算好,预降精度在逻辑上会有一些问题,包括以下几个方面:
End.
来源: http://www.36dsj.com/archives/94962