随着工业互联网逐步兴起，在加速工业自动化、智能化的同时，也进一步加速工业生产时间序列数据的产生速度。但对于工业生产中的数据分析，仍然存在重复样本多，数据膨胀率大，缺乏专业易用的平台，这些问题成为阻碍工业数据分析的最大障碍。

工业是现代文明的基础，提起工业，我们就能想到滚动向前的火车，轰鸣的飞机，为现代工业生产、出行提供便利。同时，衡量一个国家的综合实力时，也离不开工业。工业数字化浪潮随着信息基础设施的建设，通过人工智能、大数据技术与行业的不断深入行业场景，使得数据在企业单位内得以正确使用，享受数据价值红利。

近年来，全球多个国家将数据列为战略资源，并颁布数项数据政策，旨在进一步通过数据提升经济实力，让人能享受数据带来的巨大进化红利。而在工业生产过程中，早期以流水线、自动化为主，对比其他产业，中国各行业的数字化整体规模仍存在差距第二产业数字化发展之后，但近年来增速较快，以能源业为代表的陕煤、山能、三峡集团等大中型企业，以“上云用数赋智”为牵引，不断提升生产效率，实现精细化运营。当前，中国是当前世界上最大的制造业国家，规模等于美日德综合，在数字化转型道路上道艰且长。

随着云计算、大数据、物联网、5G等场景对于时序数据需求的持续增长，专门用于存储和处理时间序列数据的时序数据库应运而生。时序数据库面临着采集频率密、采集精度高、采集跨度大、存储周期长、实时要求高等有别于传统数据库的挑战。

1 什么是时序数据及工业时序数据的特点

工业数字化滚滚而来，在信息基础设施之上，工业生产环境产出了大量的以物联网IoT(Internet Of Things)数据，并随着时间的演进连续不断地产生大量传感器数值或事件数据。时间序列数据(time series data)就是以数据(事件)发生的时刻（时间戳）为时间轴形成的连续不断的数值序列。

例如，下表为某物联网设备不同时刻的的温度数据构成的一个时间序列数据样本：

无论是机器产生的传感器数据，还是工业生产活动的数据，都有一些共同的特征：

（1）实时性要求高：处理上无论是传感器数据还是事件数据，都需要毫秒级、秒级的实时处理能力，以确保对实时响应和处理能力；采集最少支持毫秒级采集，有些需要支持微秒级、纳秒级采集；

（2）采集频率高：每秒采集几十次、上百次、十万次乃至百万次；

（3）存储分析周期长：需要支持时序数据的持久存储，甚至对有些数据需要进行长达上百年的永久存储（例如地震数据）；分析需7*24小时持续不断地连续采集几年、乃至数十年数据；查询窗口长：需要支持从毫秒、秒、分钟、小时到日、月、年等不同粒度的时间窗口查询；也需要支持万、十万、百万、千万等不同粒度的数量窗口查询；

（4）数据清洗难：时间序列数据存在乱序、缺失、异常等复杂情况，需要专用算法进行高效实时处理；

（5）算法专业强：时间序列数据在工业、金融、电力、交通等不同领域，都有很多垂直领域的专业时序分析需求，需要利用时序趋势预测、相似子序列分析、周期性预测、时间移动平均、指数平滑、时间自回归分析以及基于LSTM的时序神经网络等算法进行专业分析。

从时序数据的共同特征可以看出，时间序列特殊的场景需求给传统的关系数据库存储和大数据存储都带来了挑战，无论是采用关系数据库进行结构化存储，还是采用NoSQL数据库进行存储，都无法满足海量时序数据高并发实时写入和查询的需求。因此，迫切需要一种专门用于存储时间序列数据的专用数据库，时序数据库的概念和产品就这样诞生了。

2 时序数据库和其他数据库的区别

需要注意的是，时序数据库不同于时态数据库和实时数据库。时态数据库(Temporal Database)是一种能够记录对象变化历史，即能够维护数据的变化经历的数据库，比如TimeDB。时态数据库是对传统关系数据库中时间记录的时间状态进行细粒度维护的系统，而时序数据库完全不同于关系数据库，只存储不同时间戳对应的测点值。

时序数据库也不同于实时数据库。实时数据库诞生于传统工业，主要是因为现代工业制造流程及大规模工业自动化的发展，传统关系数据库难以满足工业数据的存储和查询需求。因此，在80年代中期，诞生了适用于工业监控领域的实时数据库。由于实时数据库诞生早，在扩展性、大数据生态对接、分布式架构、数据类型等方面存在局限，但是也有产品配套齐全、工业协议对接完整的优势。时序数据库诞生于物联网时代，在大数据生态对接、云原生支持等方面更有优势。

时序数据库与时态数据库、实时数据库的基本对比信息如下：

2.1 当前主流时序数据库的基本情况

为了高效存储、处理、查询和分析海量时序数据，市面上先后出现了几十种时序数据库。

时序数据库是时间序列数据库的简称，指的是专门对带时间标签（按照时间的顺序变化，即时间序列化）的数据进行存储、查询、分析等处理操作的专用数据库系统。通俗来说，时序数据库就是专门用来记录例如物联网设备的温度、湿度、速度、压力、电压、电流以及证券买入卖出价等随着时间演进不断变化的各类数值（测点、事件）的数据库。

这些时序数据库架构形态和性能特性各异，但是基本上可以概括为以下几种：

2.1.1 基于传统关系库扩展的时序数据库

在传统关系数据库的基础上，利用关系数据库的内核引擎，把时间序列作为一个插件扩展实现。例如，TimescaleDB是基于PostgreSQL数据库打造的一款时序数据库。PostgreSQL是一个功能非常强大的、源代码开放的客户/服务器关系型数据库管理系统。PostgreSQL拥有强劲的功能集，其中包括多版本并发控制(MVCC)、时点恢复、细粒度访问控制、表空间、异步复制、嵌套事务、联机/热备份、完善的查询规划器/优化器以及预写式日志。

由于TimescaleDB基于PostgreSQL，因此同时具备了传统关系数据库的优点和缺点，优点在于PostgreSQL完备地实现了关系数据库标准，因此具有强大的生态兼容能力和强一致性的保障。Timescale作为PostgreSQL的一个插件，为快速获取和复杂查询进行了优化。它执行的是完整的SQL，相应地很容易像传统的关系数据库那样使用。然而，TimescaleDB也继承了传统关系数据库的不足：单边列数有上限、单表行数不宜过多（少于一千万行）、需要手动进行分库分表，缺乏自动伸缩能力，时间序列数据随着导入时间的增加，导入速度不断下降，海量（GB或千万条以上）时序数据遍历速度缓慢等。

2.1.2 基于KV数据库的时序数据库

随着大数据技术的兴起，以KV数据库为代表的NoSQL数据库大量涌现，打破了关系数据库ACID的严格限制，以CAP作为约束，底层以大数据分布式文件系统为存储引擎，突破了传统关系数据库面对海量数据存储的局限。其中，HBase是NoSQL数据库的典型代表，具备海量数量的灵活扩展存储能力。时序数据库OpenTSDB基于HBase的这种能力，专门针对时序数据的海量存储和查询做了扩展。OpenTSDB的整体架构如下所示，由运行在HBase之上的一个或者多个时间序列守护程序TSD (Time Series Daemon) 组成，每个TSDB都是无状态的独立节点，因此可以根据系统负载情况进行任意节点的横向扩展：

OpenTSDB的数据模型是基于tag的单值模型，即写入的每行记录（数据点）中只有一个指标值，如下所示：

由于基于HBase，OpenTSDB具备了HBase的优势：可以轻松管理海量时间序列数据，支持时序分区和并行查询，具备分布式集群部署和扩展能力。但是，同样也具备基于HBase带来的不足：由于HBase是弱类型列式数据库，使用Java语言操作，使得OpenTSDB也存在查询受限问题，对于多序列时间对齐查询等复杂查询支持能力受限，但客户和技术人员通常仅具备标准SQL语言技术知识储备，使用门槛高。同时由于采用的是HBase通用存储格式，没有针对时间序列数据的特性进行针对性压缩，因此导致压缩比低，读写速度较慢，通常1份数据要膨胀3倍，使用和运维成本居高不下。OpenTSDB的存储模型，其主要设计特点是采用了UID编码，大大节省了存储空间，并且利用UID编码的固定字节数的特性，利用HBase的Filter做了很多查询的优化。但是采用UID编码后也带来了很多的缺陷，一是需要维护metric/tagKey/tagValue到UID的映射表，所有data point的写入和读取都需要经过映射表的转换，映射表通常会缓存在TSD或者client，增加了额外的内存消耗；二是由于采用了UID编码，导致metric/tagKey/tagValue的基数是有上限的，取决于UID使用的字节数，并且在UID的分配上会有冲突，会影响写入。

另外一款基于Cassandra的时序数据库KairosDB也是类似OpenTSDB。Cassandra是一个高度可扩展的高性能分布式NoSQL数据库，用于处理大量商用服务器上的大量数据，提供高可用性，无单点故障。它是一个通用NoSQL，面向列的数据库, 分布设计基于Amazon的Dynamo及其在Google的Bigtable上的数据模型，并不依赖于Hadoop生态体系，对于现网存在大数据平台的客户，将会造成进一步的数据孤岛、数据冗余和更多的数据搬迁工作。Cassandra实现了一个没有单点故障的Dynamo风格的复制模型，但增加了一个更强大的“列族”数据模型。Cassandra适应所有可能的数据格式，包括：结构化，半结构化和非结构化，可以根据需要动态地适应变化的数据结构。KairosDB采取的存储模型，是利用了Cassandra宽表的特性。Cassandra的底层文件存储格式与HBase不同，它一行数据不会为每一列都重复的存储Rowkey，所以它不需要使用UID编码。虽然Cassandra针对OpenTSDB的不足做了改进，本质都是依靠大数据领域已有的通用NoSQL分布式数据库引擎作为底层存储，因此从根本上受制于底层存储的限制，无法针对时间序列数据的特点进行针对性优化。

2.1.3 基于专有时序数据引擎的时序数据库

吸收了基于关系数据库和KV数据库在时序数据存储方面的经验教训，逐步出现了基于专有时序数据引擎的专业时序数据库，其中最有代表性的就是InfluxDB。InfluxDB是由InfluxData公司开发的时间序列数据库（TSDB）。InfluxDB使用Go语言编写，适用于各类时间序列数据的高效存储与检索。InfluxDB专为时间序列数据编写的定制高性能数据存储，TSM引擎可实现高提取速度和数据压缩。InfluxDB采用了专属文件结构和专属优化，具有高压缩比、高并发、海量存储等显著优势。但是其在易用性和生态对接方面仍需提供更多支持投入。

2.1.4 华为云MRS IoTDB “专快易稳省”的专业时序数据库

专业时序数据库的另一个代表就是MRS IoTDB，它是华为FusionInsight MRS大数据套件中的时序数据库产品，在深度参与Apache IoTDB社区开源版的基础上推出的高性能企业级时序数据库产品。IoTDB顾名思义，是针对IoT物联网领域推出的专用时序数据库软件，是由清华大学发起的国产Apache开源软件。自IoTDB诞生之初，华为就深度参与IoTDB的架构设计和核心代码贡献，对IoTDB集群版的稳定性、高可用和性能优化投入了大量人力并提出了大量的改进建议和贡献了大量的代码。

IoTDB在设计之初，全面分析了市面上的时序数据库相关产品，包括基于传统关系数据库的Timescale、基于HBase的OpenTSDB、基于Cassandra的KariosDB、基于时序专属结构的InfluxDB等主流时序数据库，借鉴了不同时序数据在实现机制方面的优势，形成了自己独特的技术优势：

（1）支持高速数据写入

独有的基于两阶段LSM合并的tLSM算法有效保障了IoTDB即使在乱序数据存在的情况下也能轻松实现单机每秒千万测点数据的并发写入能力。

（2）支持高速查询

支持TB级数据毫秒级查询

（3）功能完备

支持CRUD等完整的数据操作（更新通过对同一设备同一时间戳的测点数据覆盖写入来实现，删除通过设置TTL过期时间来实现），支持频域查询，具备丰富的聚合函数，支持相似性匹配、频域分析等专业时序处理。

（4）接口丰富，简单易用

支持JDBC接口、Thrift API接口和SDK等多种接口。采用类SQL语句，在标准SQL的语句上增加了对于时间滑动窗口的统计等时序处理常用的功能，提供了系统使用效率。Thrift API接口支持Java、C\C++、Python、C#等多语言接口调用。

（5）低存储成本

IoTDB独立研发的TsFile时序文件存储格式，专门针对时序处理处理做了优化，基于列式存储，支持显式的数据类型声明，不同数据类型自动匹配SNAPPY、LZ4、GZIP、SDT等不同的压缩算法，可实现1:150甚至更高的压缩比（数据精度进一步降低的情况下），极大地降低了用户的存储成本。例如某用户原来用9台KariosDB服务器存储的时序数据，IoTDB用1台同等配置的服务器即可轻松实现。

（6）云边端多形态部署

IoTDB独有的轻量级架构设计保障了IoTDB可以轻松实现“一套引擎打通云边端，一份数据兼容全场景”。在云服务中心，IoTDB可以采用集群部署，充分发挥云的集群处理优势；在边缘计算位置，IoTDB可以在边缘服务器上部署单机IoTDB，也可以部署少量节点的集群版，具体视边缘服务器配置而定；在设备终端，IoTDB可以TsFile文件的形态直接嵌入到终端设备的本地存储中，并直接被设备终端的直接读写TsFile文件，不需要IoTDB数据库服务器的启动运行，极大地减少了对终端设备处理能力的要求。由于TsFile文件格式开放，终端任意语言和开发平台可以直接读写TsFile的二进制字节流，也可以利用TsFile自带的SDK进行读写，对外甚至可以通过FTP将TsFile文件发送到边缘或云服务中心。

（7）查询分析一体化

IoTDB一份数据同时支持实时读写与分布式计算引擎分析，TsFile与IoTDB引擎的松耦合设计保障了一方面IoTDB可以利用专有的时序数据处理引擎对时序数据进行高效写入和查询，同时TsFile也可以被Flink、Kafka、Hive、Pulsar、RabbitMQ、RocketMQ、Hadoop、Matlab、Grafana、Zeepelin等大数据相关组件进行读写分析，极大地提升了IoTDB的查询分析一体化能力和生态扩展能力。

​MRS IoTDB对Apache IoTDB内核架构尤其是分布式集群架构做了大量的重构优化，在稳定性、可靠性、可用性和性能方面做了大量的系统级增强。

（1）接口兼容性：

进一步完善北向接口和南向接口，支持JDBC、Cli、API、SDK、MQTT、CoAP、Https等多种访问接口，进一步完善类SQL语句，兼容大部分Influx SQL，支持批量导入导出。

（2）分布式对等架构：

MRS IoTDB在基于Raft协议的基础上，采用了改进的Multi-Raft协议，并对Muti-Raft协议的底层实现进行了优化，采用了Cache Leader等优化策略在保障无单节故障的基础上，进一步提升MRS IoTDB数据查询路由的性能；同时，对强一致性、中等一致性和弱一致性策略进行了细粒度优化；对一致性哈希算法加入虚拟节点策略避免数据倾斜，同时融合了查表与哈希分区的算法策略，在提升集群高可用的基础上进一步保障集群调度的性能。

（3）双层粒度元数据管理：

由于采用了对等架构，元数据信息自然分布在集群所有节点上进行存储，但是由于元数据的存储量较大会带来内存的较大消耗。为了平衡内存消耗与性能，MRS IoTDB采用了双层粒度元数据管理架构，首先在所有节点间进行时间序列组元数据的同步，其次在分区节点间进行时间序列元数据的同步。这样在查询元数据的时候，首先会基于时间序列组进行过滤树剪枝，大大减少搜寻空间，然后在进一步在过滤后的分区节点进行时间序列元数据的查询。

（4）本地磁盘高性能访问：

MRS IoTDB采用专用的TsFile文件格式进行时间序列优化存储，采用列存格式进行自适应编码与压缩，支持流水线优化访问和乱序数据高速插入

（5）HDFS生态集成：

MRS IoTDB支持HDFS文件读写，并对HDFS进行了本地缓存、短路读、HDFS I/O线程池等多种优化手段，全面提升MRS IoTDB对HDFS的读写性能，同时，MRS IoTDB支持华为OBS对象存储并进行了更加高性能的深度优化。在HDFS集成的基础上，MRS IoTDB支持Spark、Flink、Hive等MRS组件对TsFile的高效读写。

（6）多级权限管控：

• 支持存储组、设备、传感器等多级权限管控
• 支持创建、删除、查询等多级操作
• 支持Kerberos认证
• 支持Ranger权限架构

（7）云边端部署：

支持云边端灵活部署，边缘部分可以基于华为的IEF产品进行对接，也可以直接部署在华为的IES中。

MRS IoTDB集群版支持动态扩缩容，可以为云边端提供更加灵活的部署支持。

总之，MRS IoTDB在Apache IoTDB已有架构的基础上，融合FusionInsight MRS Manager强大的日志管理、运维监控、滚动升级、安全加固、高可用保障、灾备恢复、细粒度权限管控、大数据生态集成、资源池优化调度等企业级核心能力，针对工业级时间序列数据实时性高，采集频率高，存储周期长，算法专业强等特点，提供海量时序数据高并发实时写入和查询的能力，有力支撑新一代信息技术与工业深度融合发展，将进一步加速工业乃至产业数字化。