时间序列数据的处理

摘要： 随着云计算和IoT的发展，时间序列数据的数据量急剧膨胀，高效的分析时间序列数据，使之产生业务价值成为一个热门话题。阿里巴巴数据库事业部的HiTSDB团队为您分享时间序列数据的计算分析的通常方法以及优化手段。

演讲嘉宾简介：钟宇（悠你） 阿里巴巴 数据库高级专家，时间序列数据库HiTSDB的研发负责人。在数据库、操做系统、函数式编程等方面有丰富的经验。

本次直播视频精彩回顾，戳这里！

本次直播视频PPT，戳这里！

本次分享主要分为如下几个方面：

1. 时序数据库的应用场景
2. 面向分析的时序数据存储
3. 时序数据库的时序计算
4. 时序数据库的计算引擎
5. 时序数据库展望

一、时序数据库的应用场景

时序数据就是在时间上分布的一系列数值。生活中常见的时序数据包括，股票价格、广告数据、气温变化、网站的PV/UV、我的健康数据、工业传感器数据、服务器系统监控数据（好比CPU和内存占用率）、车联网等。

下面介绍IoT领域中的时间序列数据案例。IoT给时序数据处理带来了很大的挑战。这是因为IoT领域带来了海量的时间序列数据：

1. 成千上万的设备
2. 数以百万计的传感器
3. 每秒产生百万条数据
4. 24×7整年无休（区别于电商数据，电商数据存在高峰和低谷，所以能够利用低谷的时间段进行数据库维护，数据备份等工做）
5. 多维度查询/聚合
6. 最新数据实时可查

IoT中的时间序列数据处理主要包括如下四步：

1. 采样
2. 传输
3. 存储
4. 分析

二、面向分析的时序数据存储

下面介绍时间序列数据的一个例子。这是一个新能源风力发电机的例子。每一个风力发电机上有两个传感器，一个是功率，一个是风速，并定时进行采样。三个设备，一共会产生六个时间序列。每一个发电机都有多种标签，这就会产生多个数据维度。好比，基于生产厂商这个维度，对功率作聚合。或基于风场，对风速作聚合等。如今的时序数据库底层存储通常用的是单值模型。由于多值模型也能够一对一的映射到单值模型，但这个过程可能会致使性能损失。可是，在对外提供服务时，单值模型和多值模型都有应用。好比，OpenTSDB就是用单值模型对外提供服务的，而influxDB则是多值模型。但这两种数据库的底层存储用的都是单值模型。

现实中的应用案例事实上会更复杂。像风力发电机这样的案例，它的设备和传感器的数量，咱们能够认为是稳中有增的，不会发生特别剧烈的改变。它的数据采样的周期也是严格的按期采样。下图是一个工业案例，以滴滴这样的运营商为例。因为其业务特性，其车辆数量的增加和降低会出现暴涨暴跌。

整体而言，现实世界的复杂之处在于:

1. 未必是老是定时采样。
2. 时间线多是高度发散。以互联网广告为例，在对广告进行采样时，新广告的增加和老广告的下线速度很快，时间线就颇有可能时高度发散的。
3. 主键和schema修改。前面例子中提到的Tag，能够对应数据库的schema，在实际业务中可能会频繁改动。如今通常的时序数据库中，主键是会默认生成的，即全部tag的组合。所以，在新增tag时，主键就会改变，则变为了另外一个对象。
4. 分布式系统和片键。因为数据量很大，所以须要对数据进行分片，片键的选择也是一个难以抉择的问题。
5. 数据类型。以刚才提到的单值模型为例。假设有一个三维的加速度传感器，同一时间点上会产生三个关联的数据，这时的数据类型就应该是一个维度为3的矢量，即一个新的数据类型。
6. 须要对每一个数据点的值作过滤。假设每辆车上都装有GPS传感器，假设要统计某一时间段内，一千米内，出现了哪些车辆，分别由哪些厂商生产。此时须要对地理位置进行过滤。

下图是过去提出利用HiTSDB对时序问题的解决方案。在这种方案中，未解决发散问题，较高维数据和值过滤问题。用倒排索引来存储设备信息，并把时间点上的数据存在高压缩比缓存中。这二者结合，实际上将逻辑上的一个表分红了两个表，用以解决多维度查询和聚合的问题。但使用这种方案依然有不少问题没法解决。

下面是HiTSDB的一些优点和不足：

1.优点：

• 倒排索引能够很方便的筛选设备；
• 高压缩比缓存具备很高的写入和读取能力
• 方便的时间切片
• 无schema，灵活方便支持各类数据模型

2.不足：

• 在非定时采样场景下可能致使数据稀疏
• 值没有索引，所以值过滤只能线性过滤
• Schema改动致使时间线变更
• 广播查限制了QPS

在此基础上，进行了演进，以下图。

1. 引入了Adaptive schema，即若是未指定一个数据表的schema，则认为写入的第一条数据中包含的TagKV便是片键也是主键，用以肯定惟一性以及数据会被分片到哪个节点上。
2. 压缩块也再也不是按固定的时间切片了，引入了meta index，用以查询每一个数据块的开始和结束时间。在一个时间段内攒够了足够的数据后，把整个数据块进行压缩。
3. 参考列存的思路，值索引到压缩块。值索引再也不像传统数据库那样索引到行。
4. 多值索引和空间切分。

三、时序数据库的时序算法

上面所述的存储结构主要是为了方便进行时序数据的加工和分析。时序有一些特殊算法。

1.降采样和插值：传感器采样出的点可能特别密集，在分析趋势时，会但愿进行过滤。经过降采样能够利用一段时间内的最小值/最大值/平均值来替代。

• 降采样算法：min/max/avg。
• 插值算法：补零/线性/贝塞尔曲线

2.聚合计算：因为采样是精确到每一个传感器的，但有时须要的数据并不只是精确到某个传感器的。好比，但愿比较两个不一样厂商的发电机，哪一个在风场中产生了更多的电。那么就须要对传感器数据进行聚合。

• 逻辑聚合：min/max
• 算术聚合：sum/count/avg
• 统计：histogram/percentile/Standard Deviation

3.时间轴计算

• 变化率：rate

对时序数据进行加工的分析的重要目的是发现异常。下面介绍在异常检测中如何定义问题。从异常检测的角度来看时间序列数据，分为三个维度：time, object, metric。

1.固定两个维度，只考虑一个维度的数据。

• T: only consider time dim，单一对象单一metric即单个时间序列）：spikes &
  dips、趋势变化、范围变化。
• M: only consider metric，找出不符合metric之间相互关系的数据。
• O: only consider object，找出不同凡响的对象。

2.固定一个维度，只考虑两个维度的数据。

• MT：固定对象，考虑多个时间序列（每一个对应一个metric)，并找出其相互变化方式不一样的做为异常。
• MO：不考虑时间特性，考虑多个对象且每一个对象均可以用多个metric表示，如何从中找出不一样的对象。
• TO：多个对象单一metric，找出变化趋势不一样的对象。

在异常检测中，面向问题有以下计算方法：

1. 内置函数

·高压缩比缓存直接做为窗口缓存

·对于知足数据局部性的问题，直接在高压缩比缓存上运行

·结果直接写回

·定时调度 vs 数据触发

1. 外置计算

·定时查询 vs 流式读取

·使用一样的查询语言执行查询或定义数据源

·数据库内置时间窗口

·数据流的触发机制

针对时序数据，又能够将计算分为预计算和后计算。

f2ffb2fe6da6aa136b998b1070467b035da67cca

预计算:事先将结果计算完并存储。这是流计算中经常使用的方式。其特色以下：

·数据存储量低

·查询性能高

·须要手工编写计算过程

·新的计算没法当即查看结果

·灵活性差

·不保存原始数据

后计算：先存数据，须要时进行计算。这是数据库中经常使用的方式。其特色以下：

·数据存储量大

·查询/聚合性能瓶颈

·任何查询均可以随时得到结果

·使用DSL进行查询

·灵活性好

·保存原始数据

4、时序数据库的计算引擎

基于两种计算的特色，在时序数据处理中，咱们使用的是一种混合架构。有数据进来时，有预聚合规则，若是符合规则就进行预聚合，把数据写入数据库中。在查询时，若是符合预聚合规则，就能够很快获得结果。对于不知足预聚合规则的数据，会将其从数据库中读出，进行后聚合。中间的聚合引擎是一种相似流式计算的架构，数据库或者数据源均可以做为数据源。数据源的来源对于引擎是不可见的，它的功能是接收数据，计算并产生结果。所以，预计算和后计算均可以利用这一种逻辑进行，并放在同一个运行环境中。

在逻辑上，上图是可行的。但实际上，若是要用这种方式进行流计算，因为数据源可能出现乱序等问题，就必需要利用窗口函数，将数据放入时间窗口中整理好，但这种缓存的效率其实并不高，实际状况下，是按照下图这种逻辑进行的。数据会被写进数据库，因为数据库有高压缩比缓存，是专门针对时序数据的。当一个时间窗口结束时，利用持续查询来进行预计算。它会将高压缩比缓存中的数据拿一部分出来作预聚合再写回数据库中。这样，这个缓存机制就替代了原来的时间窗口，节省了不少内存，下降了不少计算开销。

使用相似于流的架构的好处是能够将其很快的接入异构计算的环境中。正如你们熟知的，流计算能够转化为一个DAG。结合前面提到的降采样和聚合的例子。以一个加法为例，能够把数据切成三片放入不一样的工做节点上计算，计算完后再进行一次聚合输出数据。工做节点既多是CPU也多是GPU。接入异构计算的环境中，能够加速数据的计算。

5、时序数据库展望

下图是对将来架构的展望。

1.存储层

• 相似lambda架构，基于一系列不可修改的文件
• 针对不一样的场景提供不一样的存储格式

2.计算层

• 流式架构，基于内存的异构计算，自动填充热数据
• 数据分片，支持高QPS读取

3.索引

• 全局的索引 vs 文件局部索引

4.大数据

• 能够直接在大量的文件上跑MR，也能够经过高压缩比缓存以流的方式订阅数据

将来，这个数据库将会演化成时序数据平台。它能够兼容SQL生态，一系列大数据平台，以及融合边缘计算。在部署时能够在云和边缘部署一整套的管理架构，同时把用SQL描述的规则下放到云板和边缘板上，造成一整套数据处理方案。

本文由云栖志愿小组马JY整理

本文做者：斑马不睡觉
原文连接本文为云栖社区原创内容，未经容许不得转载。