1.  时序数据概述

最近在做一个工业方面的项目，第一次接触到了一种数据-时序数据。这种数据估计很多人跟我一样，之前没什么概念，更没有听过。不过对这种数据产生的另外一种常见的场景-物联网（IOT，Internet of Things），多少所耳闻。在工业方向，对应的场景叫做工业物联网。

我大学就读的是一所化工学院的自动化系的计算机专业，所以，我第一眼见到所参与的工业项目的时序数据产生的场景，就发现这些数据产生于工业自动化控制系统。工业自动化控制系统似乎是一个非常古老的概念了，比计算机系统诞生的时间更早（机器时代），而计算机系统目前最火的智能化方向，也更像是自动化控制系统的一个前沿。

所以，我参与的项目的时序数据其实就是工业控制系统上的记录某个设备的传感器监控的某个监测值。（就像家里的小米温度计，每个时刻都会有温度、湿度的值。）这些值会时时刻刻的传递给控制系统，来调节控制设备的运转。

1.1.   时序数据的定义

什么是时间序列数据（Time Series Data，TSD，以下简称时序）从定义上来说，就是一串按时间维度索引的数据。用描述性的语言来解释什么是时序数据，简单的说，就是这类数据描述了某个被测量的主体在一个时间范围内的每个时间点上的测量值。它普遍存在于IT基础设施、运维监控系统和物联网中。

对时序数据进行建模的话，会包含三个重要部分，分别是：主体，时间点和测量值。套用这套模型，你会发现你在日常工作生活中，无时无刻不在接触着这类数据。

• 如果你是一个股民，某只股票的股价就是一类时序数据，其记录着每个时间点该股票的股价。
• 如果你是一个运维人员，监控数据是一类时序数据，例如对于机器的CPU的监控数据，就是记录着每个时间点机器上CPU的实际消耗值。

时序数据从时间维度上将孤立的观测值连成一条线，从而揭示软硬件系统的状态变化。孤立的观测值不能叫时序数据，但如果把大量的观测值用时间线串起来，我们就可以研究和分析观测值的趋势及规律。

1.2. 时序数据的数学模型

上面介绍了时序数据的基本概念，也说明了分析时序数据的意义。那么时序数据该怎样存储呢？数据的存储要考虑其数学模型和特点，时序数据当然也不例外。所以这里先介绍时序数据的数学模型和特点。

下图为一段时序数据，记录了一段时间内的某个集群里各机器上各端口的出入流量，每半小时记录一个观测值。这里以图中的数据为例，介绍下时序数据的数学模型：

• measurement： 度量的数据集，类似于关系型数据库中的 table；
• point： 一个数据点，类似于关系型数据库中的 row；
• timestamp： 时间戳，表征采集到数据的时间点；
• tag： 维度列，代表数据的归属、属性，表明是哪个设备/模块产生的，一般不随着时间变化，供查询使用；
• field： 指标列，代表数据的测量值，随时间平滑波动，不需要查询。

如上图所示，这组数据的measurement为Network，每个point由以下部分组成：

timestamp：时间戳

• 两个tag：host、port，代表每个point归属于哪台机器的哪个端口
• 两个field：bytes_in、bytes_out，代表piont的测量值，半小时内出入流量的平均值。同一个host、同一个port，每半小时产生一个point，随着时间的增长，field（bytes_in、bytes_out）不断变化。如host：host4，port：51514，timestamp从02:00到02:30的时间段内，bytes_in 从 37.937上涨到38.089，bytes_out从2897.26上涨到3009.86，说明这一段时间内该端口服务压力升高。

1.3. 时序数据的特点

• 数据模式：时序数据随时间增长，相同维度重复取值，指标平滑变化：这点从上面的Network表的数据变化可以看出。
• 写入：持续高并发写入，无更新操作：时序数据库面对的往往是百万甚至千万数量级终端设备的实时数据写入（如摩拜单车2017年全国车辆数为千万级），但数据大多表征设备状态，写入后不会更新。
• 查询：按不同维度对指标进行统计分析，且存在明显的冷热数据，一般只会频繁查询近期数据。

2.  数据架构设计

时序数据在阿里云平台存储可以有很多选择，最开始架构师选择了MaxCompute+HoloGres这两款款产品。但是在了解了时序数据的应用场景和与实际使用数据的合作伙伴沟通后，我还是选择了在架构中增加了时序数据库（阿里云TSDB/InfluxDB）来实时存储时序数据。

时序数据库可以：

1.   降低存储成本

• 利用时间递增、维度重复、指标平滑变化的特性，合理选择编码压缩算法，提高数据压缩比；
• 通过预降精度，对历史数据做聚合，节省存储空间。

2.   高并发写入

• 批量写入数据，降低网络开销；
• 数据先写入内存，再周期性的dump为不可变的文件存储。

3.   低查询延时，高查询并发

• 优化常见的查询模式，通过索引等技术降低查询延时；
• 通过缓存、routing等技术提高查询并发。

时序数据在存储成本，高并发写入、查询方面的特征都是HoloGres这种数据库不具备的能力。考虑服务客户的很多日常场景目前都是基于时序数据库，所以还是选择补充了把大数据产品datahub+flink作为实时时序数据计算，MaxCompute+HoloGres作为时序数据离线存储计算与实时分析来填补时序数据库对实时计算与历史数据分析的不足。

2.1. 整体架构设计

通过时序数据集成服务集成工业时序数据，数据在写入时分成全量和按需两种发送到下一级存储。全量写入是将全量数据全部写入到influxDB，数据在influxDB存储周期为三年（暂定，后期可以根据实际存储情况调整）。全量数据被写入到influxDB后，使用实时同步工具同步到datahub，再从datahub归档到MaxCompute（图上方案后期被调整过，因为从influxdb离线获取数据的方案，验证后效率不尽如意）。按需写入是将需要多点关联计算、关联管理系统数据库数据的数据发送至DataHub，经过Flink消费DataHub中的数据并进行分析计算后再写入到influxDB或者HoloGres中。

时序数据在influxDB存储周期为三年（暂定，后期可以根据实际存储情况调整），过期数据会被从时序数据库中释放。时序数据在MaxCompute/OSS存储周期为五年（暂定，后期可以根据实际存储情况调整），当应用需在influxDB使用更久的数据时，再通过DataWorks的离线同步将MaxCompute/OSS数据同步回influxDB中。

在这个架构设计中，我认为如果能基于时序数据库自己的数据就可以完成的数据需求。比如一些基于单独的测点的历史数据分析，可以直接使用时序数据库influxDB来实现。但是如果时序数据要与存储在关系数据库的管理系统数据关联，如果要多个测点时序数据进行组合分析，或者基于历史数据做挖掘与计算。这些需求是无法基于时序数据库实现的，也是不适合在时序数据库实现的。而大数据平台就可以弥补时序数据库的这些不足，并对时序数据的使用更加的丰富与多样化。

注意：时序数据库导出的性能并不是太好，目前DataWorks支持的influxDB导出性能还不能完成太长时间区间的导出。

3.  存储规划

前面的内容可能没有提到存储这个问题，而这篇文章的内容也是以存储规划为题目，其实作为架构师的我在这个项目中最头疼的就是存储的问题。

时序数据库本身是集群的，阿里云influxDB可以选择双副本与三副本，但是最终我选择的单机版的,最大的原因就是存储的压力。我们有个基本的常识，单机数据库存储在GB级别基本是可用的，到Tb级别就会遇到很多的困难。但是时序数据大到我这个做了多年大数据的人，仍然觉得的不可攀附。

3.1. 数据场景

最开始我进入项目组，获得的信息是：企业下面有20-30个工厂，大约有100万个测点（调研后确定本期集成的是120万个），这些测点产生秒级数据传输到阿里云平台。

每日数据：120万 * 24小时 * 3600秒=1036亿8千万 （行）

每年存储：103680000000/1024/1024/1024 * 365天=35Tb（每行1Byte）

按照存储3-5年计算，数据存储的规模会达到100TB以上，这对一个企业来说是十分巨大的。但是，虽然时序数据是很简单的数据结构，每行数据的存储即便是在压缩后，也是大于1Byte的。一般存储2个field的时序数据，在时序数据库压缩存储后大约是2Byte(经验值)。而且，其他数据存储产品同样的数据存储更大。根据样例数据测算，数据在influxDB存储1Gb，对应在MaxCompute为4Gb(归档压缩后为2Gb)，对应到OSS为12.5GB和HoloGres为16Gb。

大概测算一下，存储5年，在influxDB数据库需要350TB，对应在MaxCompute的存储700TB。这个规模，超过了我所交付的项目的上限。

好在最后时序数据在写入的时候对开关量的时序数据做了写入优化，并且时效上大约为3-5秒。经过优化后，120万个测点的时序数据在influxDB的年存储最终实测为4.5TB。

3.2.  存储规划

时序数据在传输的过程中有2种格式，一种是二维表结构，一种是JSON结构。如果是从时序数据库导出的数据，是二维表的结构。

MaxCompute的时序数据从influxDB集成，或者从datahub归档。集成与归档频次为15分钟1次，MaxCompute的表分区在ODS临时层中也以分钟作为分区。表的一级分区为企业三位字母缩写，表的二级分区格式为集成时间，格式为“yyyymmddhhmi”，时间不设置多级分区。例如,202110080115。

在MaxCompute集成的时序数据，如果是从DataHub集成的JSON结构，需要把临时层的JSON在镜像层转为二维表格式。

如果集成到临时层的数据是JSON结构，则在临时层只保留最近1个月历史数据，全量历史数据存储在镜像层表。因为JSON结构不利于列压缩，所以，长期存储的历史数据不能以JSON结构存储。镜像层中超过1个月的历史数据，使用归档压缩存储。

MaxCompute存储的历史数据频次为分钟级，主要被用来做离线分析与计算。按时序数据在MaxCompute存储与InfluxDB存储占用大小比（2：1）规划，MaxCompute可以存储大约5年以上历史数据，超过5年历史数据可以归档到OSS。

根据实际存储占用测算，influxDB数据与MaxCompute（归档）的存储大小的比例为1：2。所以，时序数据在MaxCompute存储5年占用的存储占用约为60TB，存储10年的存储占用约为120TB。因为MaxCompute还需考虑其他数据的历史存储，暂且认为时序数据在MaxCompute的上限存储为10年。10年以上数据有存储需要的，建议存储到OSS。

OSS被用于存储不能在MaxCompute中存储的历史数据，存储方式为按需存储，历史数据可以分为当前还有可能使用的历史数据和暂时不需要使用的历史数据。

使用DataWorks同步到OSS的数据格式为二维表格式，可以使用MaxCompute的外表和HoloGres的外表直接访问存储在OSS的历史数据。

二维表格式的时序数据在OSS存储与InfluxDB存储占用大小比（12.5：1），压缩比很低。所以，如果考虑数据暂时不再使用，只是备份。建议可以使用压缩格式存储（压缩格式存储，压缩比与MaxCompute一致），不压缩存储5年占用存储300TB，压缩存储5年占用存储60TB。所以，建议只针对有真实存储需要的数据从MaxCompute同步到OSS存储，存储时间在5-10年之间可选。

4.  时序数据集成总结

时序数据长期以来在企业侧都是存储在时序数据库的。因为其数据存储的规模非常大所以，在大数据平台未建设之前，只能在时序数据库存储使用。使用的方式局限于时序数据库的单点区间历史，属于在线实时存储与分析场景。

在引入了大数据平台的丰富的产品线后，时序数据可以进行更久的历史数据的批量的计算，也可以与管理系统的关系数据进行关联计算。这些计算可以是实时也可以是离线，手段更加多样化。而且在阿里云大数据平台，还有PAI这种算法计算平台，可以让企业数据分析更加智慧化。

另外时序数据其实也有一些其他的集成手段，例如ELK平台的ES产品其实也是对时序数据有一定的支持。还有阿里云的log service产品，都是声称可以存储和计算时序数据的。这些都是对时序数据的应用的多样化，给出了更多的选择。

在做时序数据历史集成的时候，我们实际调研发现，之前在厂侧存储的3-5年的历史数据，在时序数据库是很难导出来给我们集成的。一方面是因为时序数据库存储的历史数据太久，导出会占用大量的资源影响在线系统使用。另一方面也说明了缺乏这种大数据平台，单一的时序数据库还是有一定的欠缺。

在进入项目2个月了，我们和合作伙伴和客户其实对时序数据存储在大数据平台和时序数据库，为什么在线的时序数据库和离线的MaxCompute都会存储还会有疑问。主要是因为传统工业行业对大数据平台还是缺乏了解，应用还是局限于原来的场景。所以，希望未来大数据平台的引入，能给这个行业的客户和从业公司带来更多的改变和可能。

 

以上文字内容，部分来自：

时序数据库介绍和使用

https://blog.csdn.net/liukuan73/article/details/79950329

物联网、工业互联网大数据的特点

https://www.taosdata.com/blog/2019/07/09/105.html

更多关于大数据计算、云数据仓库技术交流，欢迎扫码查看咨询。