Apache IoTDB时序数据库是面向工业物联网领域的、由我国自主研发并开源给Apache的顶级开源项目。随着触发器、UDF等功能不断引入，IoTDB的应用场景越来越丰富。本文重点分享IoTDB的新特性，以及在工业物联网应用解决方案中的技术选型思考，希望对相关从业人员在做技术选型和整体架构设计有所帮助。

▲清华大学软件学院助理研究员黄向东

嘉宾介绍：黄向东，清华大学软件学院助理研究员，中国科协青年托举人才，CCF数据库专委会通讯委员，中国通信学会开源技术专委会委员，Apache国际开源软件基金会委员，Apache IoTDB项目V.P.。主要研究领域为大数据管理技术，聚焦工业大数据管理。获国家发明专利授权30余项。参与研制了我国新一代气象大数据平台，负责研制了工业物联网时序数据库管理系统软件IoTDB，开源版成为我国高校发起的首个Apache顶级项目。主持国家自然科学基金项目、中国博士后科学金金各一项。获2018年教育部技术发明一等奖，2018年中国气象学会科技进步一等奖。

以下是黄向东老师在DTCC2021大会现场的演讲实录：

IoTDB项目介绍

工业物联网时序数据是工业设备物理量的数字化记录，是带时间戳的数据，蕴含丰富的工业语义。IoTDB是清华大学发起研发的一款聚焦工业物联网、高性能轻量级的时序数据管理系统，提供数据采集、存储、分析的功能。

国际工业互联网领导者通用电气(GE)公司2012年指出：“充分利用海量时序数据驱动工业创新、竞争和成长，是大数据技术为新工业革命带来的历史性机遇。”

大家可以观察数据库领域的西雅图报告，指出未来五年会形成一个数据库的发展前景。有报告专门提到，IoT会给数据库的写入查询，都带来一些新的挑战，包括：海量序列存储、复杂元数据管理、丰富的查询需求、边云协同等。这样一来，在产业界和学术界，时序数据都变得更加受关注。

如果把图中工业物联网时序数据的纵坐标删掉，改成“值”。那么，它就会从工业物联网时序数据变成时序数据。可见，其实时序数据是非常普遍的，人、软件、机器的行为，都在不断产生时序数据。

关于TSDB，维基百科上的解释是，时序列数据库用来存储时序列(time-series)数据并以时间(点或区间)建立索引的软件。它的主要应用场景分为APM监控、物联网应用、数据分析三种。目前，时序数据管理系统的选型多种多样，包括ClickHouse、Druid、HBase、OpenTSDB、Parquet on HDFS/S3、PG/MySQL、TimeScaleDB、MatrixDB、InfluxDB、M3DB、TDengine、Apache IoTDB、Skywalking EMQx等。所以，在面向不同的系统时，会有不同的选型解决方案。

Apache IoTDB新特性

IoTDB在Apache社区走开源模式，和一系列开源软件做适配集成，最终目标是打造时序数据全生命周期管理的开源解决方案，包含从数据的采集、存储、处理，到分析、应用，所有的环节进行打通。

在采集阶段，有很多开源的软件，像EDGENT、PLC4X。在分析阶段，可以用Spark、Hive来做大数据分析。在应用阶段，可以选择Grafana、calcite、karaf等开源程序。

从发行历史来看，IoTDB来自于清华大学软件学院。2017年，我们对它进行开源。2018年，Apache社区很多有经验的伙伴一起协助改善IoTDB，从demo形式逐渐变到产品形式。2019年，发行第一个Apache IoTDB版本。其实可以看到，IoTDB的发版速度并不是很快，但是基本上每年都会有一两个版本在发行，每个版本在写入、查询、稳定性方面都做了改进。2019年，IoTDB优化了乱序数据整理的功能。2020年，IoTDB的查询性能大幅提升，提供全新内存控制功能。2021年，社区正式推出了IoTDB 0.12系列版本，并在0.12版本上维护了0.12.0 - 0.12.4共计5个小版本。

特性1：数据模式从后台定义到边缘设备定义

近几年，传统工业企业的设备零部件升级频率越来越高。在升级系统的过程中，数据的采量方式也在发生变化，新增或者减少测点。最后会形成这样的表结构。但真正读数据的时候会发现，一张表的列是需要经常变的。

特性2：从规则负载到复杂负载

由于设备的测点过多，在关系型数据库模式下，这样一张表会被迫要纵向拆掉。因为如果一个数据库不设定表的列数，就无法分配内存，还会对系统造成一定的影响。

此外，复杂的工业设备是由很多独立的子设备或零部件构成。从数据库的角度来看，各测点独立采集，采集频率不一致，时间不齐。虽然在做查询的时候，表的结构是最适合的，这时候用户的表达能力最强。但是在写入和管理的时候，不需要用户看到这样一张表。基于此，层次化结构来管理数据是工业企业的天然想法。在这个层次化结构上，设备上的测点的采集频率可以不一。

在应用的过程中，IoTDB一直坚持使用上图的树形结构，比较符合资产管理和资产调度的方式。

IoTDB定义了多个概念，面向工业物联网的场景下，直接拥有物理量的设备或装置，会产生数据，所有物理量都有归属叫做实体。比如，一台风力发电机、一辆车、一座桥等，都属于实体。多个实体的集合，其数据在磁盘上物理隔离，称为存储组(Storage group)。

物理量(工况、字段、测点、变量)可以度量装置所记录的测量信息，它可以是一元的或者多元的。一元物理量可以独立采集功率、电压值、电流、支座位移、风速、车速、经度、纬度等。多元物理量可以同时采集GPS(经度、纬度)等。

由此，我们定义了时间序列(实体+物理量)，包括一元序列(实体+一元物理量)和多元序列(实体+多元物理量)。对于IoTDB来说，我们的存储就变成了实体+物理量，如某台风机的转速，某车辆的GPS。

不同的建模方式会对系统产生怎样的影响呢?显而易见，每个一元序列会有自己的时间轴。如果多个一元序列的时间轴完全相同，那时间轴一定是重复的，会导致空间资源的浪费，此时应该将它存储为多元序列。

IoTDB未来会尝试着去识别，场景适用于一元序列还是多元序列。现阶段，需要用户自己去定义。

现实应用中，也会存在海量同类型、同型号的实体，每个实体有相同的物理量集合，比如一批相同型号的车，一批相同型号的风机，我们将其称为物理量模版。使用物理量模板，可以大幅减少元数据管理代价。

不同序列的类型有不同的编码和压缩方法选择，来提供更好的压缩率。其中，PLAIN适用于变化幅度较大，无规律，难预测的数据。RLE适用于大部分值相同的数据。TS_2DIFF适用于变化稳定的数据。GORILLA适用于数据变化较小的浮点数。DICTIONARY适用于基数较小的TEXT类型。

特性3：从时序数据查询到时序数据处理

存储数据对用户来说是成本付出，而分析数据中的价值才能给用户创造利益。所以说，要让IoTDB具备分析能力，尤其是面向工业领域的分析。那么，能否把分析任务，以及哪些处理分析任务，交给IoTDB来完成?

对于database，做数据分析有几个时机。第一个时机是数据刚进来的时候，有可能会经过一次处理。当当数据到达时，IoTDB提供基于滑动窗口和单点的计算模型，来实现有状态和无状态的计算。同时，为了限制计算的复杂度，IoTDB只允许分析计算任务计算单条序列或者一个设备下的多条序列。

第二个时机是，当数据已经存储到数据库中，但还没有被查询。这段时间，我们可以对数据提前进行分析计算，这部分可以用索引来表示，索引的目的是让用户更快地使用数据。

第三个时机是查询时计算，例如把原始数据求平均值，或者绝对值。查询时计算这一概念映射到数据库中，就不得不提用户自定义函数(UDF)。对于UDF来讲，时序数据有两种，一种是UDTF(用户自定义时间序列函数)，即输入n条序列，输出1条序列;另外一种UDAF(用户自定义聚合函数)，即输入n条序列，输出1个点。

过去几年，我们一直在做时序数据的数据质量方面的研究。借助UDF，把这些算法与IoTDB集成，形成了一套IoTDB-Quality面向时序数据的数据质量算法库，当然这套算法并不与IoTDB强绑定。

IoTDB支持用户自定义降采样。如果系统提供的降采样能力或者功能与业务不满足，比如，当数据密集时，选用平均值，当数据稀疏时，选用最大值最小值。这种情况下，DB的降采样能力无法支持如此丰富的自定义，就可以用自定义函数来实现。

又如，时序数据的一个重要的工业应用是实时告警。一旦出现告警之后，就要快速的做出响应控制。但是在真实的应用中，观测值低于指定阈值会导致大量的告警。如果想要在生产中可用，往往需要把虚警过滤掉。所谓虚警就是由于数据的波动形成的异常。

我们通过UDF来解决虚警的问题。对于这样的告警，我们分为几个步骤来走，跳变清除、阀值过滤、匹配真警、异常度计算、异常报警、人工确认。

写在最后

从IoTDB 0.12、0.13的两个版本里，我们一直在思考：随着对数据的使用程度越来越高，IoTDB应该会有哪些新的特性随之出现。所以我们一直在做UDF和触发器的功能。同时，在分布式版本研发中，IoTDB也会不断加强时间分区和虚拟存储组的能力。未来，IoTDB将给大家提供越来越丰富的能力和更好的性能。