2022 IoTDB Summit：IoTDB PMC 乔嘉林《端边云协同：Apache IoTDB 全新单机分布式架构》

2023-03-06
北京
本文字数：8936 字
阅读完需：约 29 分钟

12 月 3 日、4 日，2022 Apache IoTDB 物联网生态大会在线上圆满落幕。大会上发布 Apache IoTDB 的分布式 1.0 版本，并分享 Apache IoTDB 实现的数据管理技术与物联网场景实践案例，深入探讨了 Apache IoTDB 与物联网企业如何共建活跃生态，企业如何与开源社区紧密配合，实现共赢。

我们邀请到 Apache IoTDB PMC 乔嘉林参加此次大会，并做主题演讲——《端边云协同：Apache IoTDB 全新单机分布式架构》。以下为内容全文。

大家好，我是乔嘉林，现在是 Apache IoTDB 社区的 PMC，同时也是清华大学的助理研究员。今天为大家带来的是 Apache IoTDB 1.0 的新架构，一套全新的单机分布式的架构。这套架构能够在一套代码下面同时支持单机和分布式的两种部署模式，能够适配物联网的端边云等不同的部署场景，从而为用户带来更大的价值。今天的介绍主要分为两个方面，第一个是端边云的协同，第二个就是全新的单机分布式架构的解析。

01 端边云协同

第一部分，我们介绍一下物联网的端边云协同的场景需求。云原生这个词最近比较火，也出现了很多云原生的优秀系统，它们能够在云侧进行一个存量分离，并且按需的去扩展资源。

但是在我们过去几年接触物联网工业企业的实践中，我们会发现，物联网场景里面的数据大多从端侧设备产生出来的。这些数据首先会服务于工厂的应用管理，所以他们会首先传到工厂内部的边缘网关，再传输到数据库里面去。这些数据去服务设备的实时监控以及告警等等。

这些数据为了支持很高的实时性，所以上云是不能满足这些实时性的，因此最开始在工业场景里面去服务工业数据的软件通常叫实时数据库。当满足了工厂内部的实时处理的需求之后，有部分企业会选择把所有的边侧的数据汇聚到云端，进行统一的管理和分析，这个时候才会用到云的资源。

因此我们认为物联网场景，云原生只是一部分，更全面应该是端侧、边侧、云侧都需要进行数据管理和分析。因此我们的端边云的场景需要的是一个能够在端侧、边侧、云侧等不同资源下面都能够适配，并且运行良好的数据管理软件。同时我们可以看到数据需要从端侧传到边侧，又从边侧传到云侧，这时候也需要有一个比较高效的数据传输方案来去支持这整个数据流转的过程。

我们先来看一下在物联网场景里面，大家管理时序数据的时候的方案演进。首先，在最开始关系数据库和键值数据库刚出生的时候，大家通常在用关系数据库或者键值数据库来存储时序数据，人们会发现这两类数据库在管理时序数据的时候，遇到模型扩展性较差的问题，包括它的压缩比可能比较低。于是人们就开始在这两类数据库之上，去构造一些时序数据的处理逻辑。这一类的系统支持了时序数据的一些数据模型以及读写的流程，但是它也拥有关系数据库以及键值数据库的一些问题。

因此在下一个阶段，人们开始去探索能不能有一套数据库来专门管理时序数据，而不是在原来的这种通用型的数据库上面进行改装。于是就诞生了两类比较典型的产品，第一类是 OSIsoft PI 系统，这类系统是专门针对工业的 OT 领域来去研发的，部署在工厂内部、更贴近设备侧，来支持用户的时序数据的管理，它更强调实时性。第二类就是以 InfluxDB 为首的一类时序数据库，它们的目标场景是互联网的 IT 场景，InfluxDB 通常部署在云端，来接收用户的写入和查询的请求。

这两类数据库在两个方面进行了一个改进。第一个他们拥有更灵活的数据模型，这套数据模型以标签或者以测点为度量单位，来管理用户的监控项。第二个就是专门为时序数据做了很多优化，包括压缩比，它们的压缩比通常相对于传统的关系型和键值型来说，能够达到十倍以上的提升。因此这类数据库大规模的取代了上一类的传统型的通用型数据库。

在物联网的新的时代，我们在想能不能在物联网的端边云场景下面，把 OT 和 IT 结合起来，去提供一个完整的物联网的时序数据的管理方案，于是 IoTDB 这个产品就诞生了。它不仅在时序数据领域，优化了时序数据的一些处理方式，包括存储的性能，同时增加了很多物联网 IoT 的特性，就是端边云的场景，并且相比于 OSIsoft PI 以及 InfluxDB 来讲，它提供了一个全新的开源的分布式的版本，来帮助物联网的用户去部署一个更加方便、更加可扩展性的一个数据库，这就是 IoTDB 的目标。

好，我们先来看一下传统的端边云的方案。数据通常由数采程序在端侧采集起来，接下来会通过消息队列，传给边侧和云侧的时序数据库以及数据仓库。这里面当端侧到边侧的网络不通的时候，数据通常就会先要缓存在端侧里面，这个时候大多数的工业用户会自己去选择一个自定义的文件，把数据存到端侧。

那么这里面就会有三个问题。第一个就是文件格式不统一，因为每种文件格式都是不同的厂商自己去定义的，因此它们的格式不能去互相融合起来。第二个就是压缩比不高，这类文件很多都是直接写成了 CSV 的格式，或者自己的序列化的格式，并没有针对时序数据做一些通用的压缩、存储和编码等等。

第二个问题就是我们可以看到在边侧和云侧分别部署了实时数据库以及数据仓库，这两个就是两个不同的系统，对于我们运维人员来说，其实带来了更大的复杂性。

第三个问题就是我们可以看到，在边侧和云侧，我们分别需要消息队列里面的数据，来写到数据库里面，这里面就会造成一个重复的资源消耗。我们不仅在边侧需要把数据写到数据库里一次，在云侧同样需要重复计算一次。这个时候我们会发现，如果我们这个边侧在不断的扩展，那么边侧需要多少资源去处理这些数据，那么云侧就需要这些资源的总和，来把这些数据进行一个汇总和处理，所以这样就不能够做到云侧以更高效的方式，来去支持更多的边侧的扩展性了。

我们可以看一下 IoTDB 的端边云的解决方案怎么样去解决这些问题的。首先，方案一就是传统的从端侧的初采程序到边侧的消息队列，去写到单机的 IoTDB 里面，它可以支持工厂内部的实时的数据管理和监控。第二种，如果我们的端侧有一些存储资源，我们也可以在端侧部署一个比较轻量的单机的 IoTDB。这种方式用户就不需要自己去处理数据的转发与写入了，只需要在端侧把数据写到数据库里面一次，那么我们可以通过 IoTDB 的操作级的同步，把数据每一条都上传到边侧的数据库里面去，这个方式有一个比较高的实时性，可以在边侧去看到最新的端侧产生的数据，能够监测设备的实时状态。

从边侧到云侧我们也做了一个创新的优化，这个就是将 IoTDB 底层的数据文件直接去同步到云侧的数据库里面，进行加载。这种方式相对于传统的我们要把一条数据从边侧传到云侧，再写到数据库里面相比，这种方案只需要加载文件的索引信息，而不需要做一些文件数据的解析，这样的话云侧去加载数据消耗的资源，就比边侧处理数据消耗的资源要少很多。

因此这种方案有三个优势，第一个就是在端侧的 IoTDB，因为它采用了一个高压缩比的文件格式，所以能够节省用户更多的磁盘空间。第二个就是从边侧到云侧的传输，我们一方面能够节省网络传输的资源消耗，同时也能够节省云端的计算资源的消耗。第三个就是从头到尾可以看到，都是 IoTDB 这一整套系统，它底层的数据文件格式也贯穿了端边云，没有采用更多的数据格式，为用户带来了更大的统一性，带来了更多的运维的便捷性。

我们看一下 IoTDB 项目的一个发展阶段。首先 2011 年是我们蕴育期，在三一重工等企业的海量机器设备管理中，我们发现了一些物联网的特有的问题，包括海量序列的管理、动态扩列的需求以及模型映射的需求等等。于是我们开始去自研 IoTDB 这样一个系统，从底层的数据文件 TsFile 开始研发，首创了物联网数据模型。

同时 2018 年，我们又根据物联网的数据写入的负载，发现了里面顺乱序分离这样一个优化项，并且形成了 IoTLSM 这样一个针对物联网设计的存储引擎。同时在 2018 年我们也进入了 Apache 的开源软件基金会，开始建设全球的开源软件社区。经过两年在 Apache 孵化器里面的孵化，我们成功毕业成为了一个 Apache 的全球顶级项目，于是也成为了我国高校在 Apache 里面唯一的一个孵化成功的一个项目。

在 2021 年，Apache IoTDB 社区参加了国家的“十三五”科技成就展，并且获得了北京市的科技进步一等奖，这两个都是比较重量级的奖项。同时，社区也孵化出了商业化的公司 Timecho 天谋科技，来为社区进行更大的赋能。

在 2022 年，在整个社区的努力下，我们开始去共创新的分布式的架构，并且发布了 1.0 的版本，这套版本能够更好地支持物联网的端边云协同的场景。

IoTDB 项目的核心优势主要有六项。第一是独立自研，从底层的数据文件到分布式的管理系统，从头不依赖第三方系统，整个都是在一套系统里面完成的，这样节省了很多用户运维和部署的复杂性。

第二是 IoTDB 是 Apache 的一个唯一的时序数据库的顶级项目，这也就意味着它的开源协议是比较商业友好的，而且没有任何的使用风险，大家可以放心的去使用。

第三是产学研的结合，因为 IoTDB 这个项目诞生于清华大学，同时现在也有很多的互联网的公司参与到社区的研发，所以产学研的结合在 IoTDB 的社区有比较好的实践。现在我们已经拥有了 30 多项时序数据管理领域的发明专利，同时也在数据库的顶会发表了 10 多篇论文，这些科研的成果有很多已经在 IoTDB 里面真正去服务用户了。

第四是 IoTDB 的模式是非常齐全的，有边缘模式、有单机模式、有分布式模式，能够适配端边云不同的场景需求。

同时，为物联网场景我们也设计了专属的数据模型，包括存储引擎以及共识协议，全方位的去提升数据在物联网领域的存储和优化。

最后一个就是在现有的一些案例里面 IoTDB 已经管理起了上亿的序列，包括支持了数千万的数据写入吞吐以及十倍的压缩比，以及极致的性能在很多工业场景里面得到了一个检验。

接下来就是 IoTDB 的物联网数据模型。这里面我们创造了设备、测点等这些语义，把这些语义融合到数据模型里面去，来更好的适配物联网的场景。同时这套树形模型支持任意的层级，并且支持任意的规模。同时它具有弱模式的特点，用户可以随着数据的写入，去自动的把数据模型扩展起来，而不需要人工手动创建表或者创建测点，这样极大地节省了 DBA 的工作分担。

同时可以看到，在不同的物联网场景里面，设备去采集传感器的时候其实是有不同的采集模式的。一种模式就是一个设备的不同的测点去独立采集，这样的话不同的时间序列就拥有不同的时间戳。第二个方式就是一个设备的所有特点可以同时采集，最后让它赋予相同的时间戳。通过这种采集方式，其实有不同的存储模型来适配这两种采集方式是更加优化的。因此 IoTDB 也是第一个能够让用户通过数据模型，去控制底层到底选择哪种存储模型，存储我们的数据。这样的话能够减少时间列的存储负担，在不同的场景里面我们去全方位的提升读写性能以及压缩比。

在一些用户的评测结果，以及第三方的测评结果，我们可以看到，IoTDB 相比于一些国际的数据库和国内的一些数据库，它有比较好的读写性能以及压缩比的优势。

那么为了支持刚才说到的物联网的端边云的场景，我们希望在 1.0 的新架构里面，支持两种部署模式，一种是单机，一种是分布式。

同时 IoTDB 为了支持端边云的协同，它的这个架构也是为了端边云处理而诞生的。这里面首先大的架构上面，我们是支持一个可插拔的数据文件的数据库架构，这个数据文件 Tsfile 可以从数据库引擎里面卸载出来，也可以加载到另外一个数据库引擎里面去，于是文件的卸载和加载变得非常方便。

同时，搭配三项更高的一些功能来去支持端边云的协同。第一项就是一个高效的压缩文件格式 Tsfile，第二个就是我们可以在 IoTDB 单机版里面增量的把数据文件收集起来，这样的话我们能够支持一个增量的数据同步。第三项就是当我们收集到这些增量的数据文件之后，怎么样能够把数据文件加载到集群里面，让它更加高效。这里面我们可以去直接加载 TsFile 里面压缩好的数据，而不需要把它进行一个解压缩、再去处理。这种方式和现在压缩好的数据进行计算的一些思想不谋而合。这三种能力以及架构就能够让 IoTDB 在端边云里面发挥更大的作用。

02 全新单机分布式架构

第二部分我们可以看一下，全新的单机分布式的架构，它的思想以及具体的一些设计的模块。

首先，新架构的核心思想有两点：第一点就是潜力无上限，第二点就是适配低成本。那么，第一点其实我们想说的是，如果用户的资源非常充足，那么这套分布式架构能够为用户提供一个完美的服务，它的性能能够达到非常高。第二点就是我们也可以看到在不同的物联网场景里面，用户能提供的资源也是不一样的，有的时候可能只能提供一个一核 2G 的一个内存这样一个机器。于是在这些资源有限的场景下面，怎么为用户提供更大的价值，这是我们希望支持的一个目标。

具体来看，系统目标有以下几个方面。第一个就是多模式，一套架构多种部署模式。第二个就是大容量，这套分布式架构我们不希望有容量的上限，希望能够管理上亿的设备和特点，而且对数据量没有任何限制，只取决于用户的磁盘空间。在可用性方面，这套分布式也应该去容忍部分节点的失效，从而保证系统的高可用。在扩展性方面，系统应该能够随着用户负载的增加，能够进行随时的扩容，并且这个扩容应该变得非常平滑，而不影响用户线上的读写负载。同时，系统应该拥有比较高的性能，而且随着节点的增加，应该有一个高的线性比。最后就是可观测性，对于一套分布式系统来说，调优以及运维是比较复杂的事情，这时候我们就需要引入可观测性手段，来降低运维的复杂度。

我们可以看到，集群当前有两种角色的节点。第一种角色就是数据的管理节点，这种节点其实相当于集群的大脑，去整体操作集群的一些节点信息，包括管理数据的分区信息以及任务调度。第二类角色就是数据节点，数据节点主要的能力是，一方面存储序列的元数据和数据，第二方面就是进行一个高效查询以及计算。这两类节点分别形成了两层的平台层，这两层都可以独立部署并且按需扩容。上层才是应用层，应用层会直接跟这个数据节点进行对接，来提供用户的读写服务。

接下来如果我们细看一下的话，架构图里面分别包含以下几个更细节的模块。第一个是管理节点，内部包括节点管理、分区路由、负载均衡、操作调度等这些模块，同时通过共识协议和其他的管理节点进行一个同步，保证数据的多副本以及强一致性。

在数据节点里面，我们支持多种网络的协议的接口，包括原生接口 Session、MQTT、RestAPI、JDBC 等不同的协议，同时进行统一的会话管理。数据节点里面还包括一个大规模并行处理架构，有完整的查询处理的优化流程，以及一个计算引擎。这里面我们提供了连续查询、触发器、UDF 以及物联网的函数库等比较丰富的边缘计算的工具，来为用户在端侧直接进行计算提供了方便。

底层有两类引擎，第一类是管理元数据的元数据引擎，第二类是管理数据的数据引擎。这两类引擎分别都是数据和元数据的复制的单位，所以它们的不同副本会分配在不同的数据节点上面。这些不同的副本之间就会通过共识协议层来去进行数据的共识，保证副本的一致性。这里面我们也提供了多种的共识协议来去适配不同的场景。

为了支持边云协同，我们有边云协同模块以及文件加载模块，同时在这个过程进行比较全面的权限管理。这两类节点我们都支持比较丰富的指标的采集，去进行系统的监控，同时 IoTDB 也支持比较多的生态，这里面我们支持 Spark、Flink、Kafka 等大数据生态对接，同时提供了比较丰富的可视化的工具，像 Grafana、Zeppelin 等等，以及一些控制台和命令行的这些工具。

IoTDB 1.0 的部署模式有这四个方面，第一是轻量单机模式，这种模式有最高的性能，而且是最轻量的，通过一个脚本就可以一键启动。第二是默认模式，一个可扩展的单节点的模式，这种模式有比较高的性能，同时用户可以随着负载的增加，把这个系统给扩展成多个节点。同时它的一致性也是比较高的，因为它只会有一个副本，因此它的磁盘占用也是最低的。第三种，也是我们比较推荐的，在分布式部署模式的时候的这个方式，这是一个拥有高性能的分布式的模式。它的这个性能和扩展性，以及高可用，都是达到了最高的水平。最后一点就是强一致的分布式模式，这种模式为用户提供了强一致性的保证，同时它会牺牲部分的写入性能。用户可以根据自己的需求去选择不同的部署模式了。

在时序数据管理里面，我们认为元数据和数据其实是同等重要的。这里面元数据和关系数据库的表结构不一样的是，这里面的元数据包括设备的信息，以及测点的信息，以及它们的属性信息。人们通常会对这些信息进行比较丰富的查询，而且这些信息的数据量也比数据点能够达到相同的量级。因此我们为了不造成单点瓶颈，以及能够利用多节点并行处理的方式，我们将元数据和数据都进行一个分区存储。

将元数据和数据通过分区策略，打成一个小小的分区之后，接下来就是怎么把这些数据分区和元数据分区分配到不同的数据节点上面了。这里面我们选择了分配策略，有两个选型。第一类就是一致性哈希，这类方式就是把分配全部交给哈希函数去做控制，这样我们不能去控制数据的分配。第二种就是通过查找表的方式，这种方式我们会接管分配策略，我们会严格控制每一个数据分区，它去分配到哪一个节点上面。

这两种分配策略其实在集群扩容的时候，是有比较大的不同的。一致性哈希它在扩容的时候，我们必须去迁移数据，来保证一致性哈希环的正确性。查找表这种方式，我们就可以按需的去进行数据的迁移，我们可以选择集群扩容的时候不去迁移数据，也可以选择去迁移数据来达到一个磁盘的平衡。通过前面的去掌控分配策略，IoTDB 能够达到 1 秒扩容的这样一个效果。

那在共识协议层，我们支持了一个可配置的共识协议的框架。这套共识协议会构建在不同的副本上面，去保证写入，去写到三个副本上，同时查询也可以查到比较新的数据。

当前我们一共支持了三种协议，第一种就是 Raft 协议，这种协议能够提供强一致的保证。第二种就是 Simple 协议，这种协议只能够在单副本情况下运行，它能够提供一个极致的性能，因为它是最简的一个共识协议。同时我们也支持了一个 IoT 物联网的共识协议。这种协议是为物联网场景设计的，它的最大特点是通过两个副本，就能够提供一个高可用的能力。通过 IoT 协议我们也最低成本实现了这个高可用的功能。

为什么我们能够去创新一个 IoT 协议？这里面我们要去看场景的负载，去进行一个分析。首先在互联网的场景里面，大多数的数据产生都是人的行为，人的行为很可能造成数据的冲突，所以它的冲突会比较多，它的这个共识协议也需要更多的机制去处理冲突解决。在物联网场景里面，数据都是从设备采集上来，并且上传到数据库里面去的，不同设备采集的数据通过不同的链路传上来，基本没有有这个冲突的概率。所以，由于物联网场景里面冲突比较少，所以这就给我们优化共识协议提供了更多的可能，也是我们去研发 IoT 协议的一个起因。

在读写流程里面，IoTDB 通过原生的接口 Session，把数据请求发送到一个数据节点上面之后，这个节点会去通过 ConfigNode 拉取数据分区，并且通过其他的数据节点来去拉取元数据，因为我们的元数据和数据可能不在同一个节点里面。经过元数据的拉取之后，我们进行一个数据的校验，这个时候就通过共识协议来去传到多个副本上，进行多副本的读写，最后再向用户返回结果。这个里面我们通过缓存，来去节省了里面这些虚线部分的网络传输，实现了一个最短的读写路径，通过负载均衡模块也实现了一个高线性扩展比的特点。

好，在 0.13 以前的版本里面，我们经常说“推荐 CPU 核数个存储组”，这句话已经成为了过去时。在新的版本里面，存储组这个概念升级成了 Database，那么用户只需要创建一个 Database 即可。所有的负载和资源都由 IoTDB 来去进行一个监控，并且能够在不同的场景下面，为用户的写入负载进行一个优化。

在查询方面，IoTDB 支持多种表结构。第一种就是测点表，第二种就是设备表。这两种表结构表达的语义，以及提供的一些 SQL 的格式也是不太一样的，能够提供用户更多选择的方式。

这里存算分离是最近比较火的一个概念，但是我们认为存算分离只是手段，不是目的，在物联网场景里面很多时候资源不是特别多，因此我们希望优先让计算靠近数据，而不是把数据拉到另外一个节点，再去做一些计算。

这里面我们也支持了多种的计算模式，包括触发器在数据写入的时候，就能够进行一些实时的计算。即席查询就是用户可以随时的输入 SQL，快速的返回数据，拥有比较高的实时性。还有一个就是周期调度，用户可以去注册一些任务，这些任务就可以在后台不断的去把数据进行一些处理，并且生成一些物化视图，去提升查询的效率。

在存储引擎方面，IoTDB 选择了基于 LSM 架构进行了一个优化。在这里面，我们发现乱序数据在物联网时序数据里面是一个比较常见的场景，不管是由于采集的问题还是由于分布式处理的问题，我们没法避免数据可能会乱序写入数据库里。这个时候，我们将乱序数据从顺序里面拆离出来，这样能够节省顺序数据的一些处理的代价，来节省系统整体的资源消耗。

为了适配轻量单机模式，我们做了三个地方的优化。第一个就是协议层的简化，我们提供了一个单副本的共识协议。第二个就是执行器的优化，因为单机的模式下面，数据和元数据都是在一个节点内部的，所以这个时候很多网络通信就可以改成本地方法调用。第三个就是缓存的优化，我们可以去释放多余的、在分布式里面为了远端传输的一些分布式的缓存。

最后一个就是系统可观测性。这里面我们支持采集操作系统、以及 IoTDB 系统内部各个模块的一些不同的监控项，并且支持以节点为单位去配置这个监控项。同时，支持指标的分级管理，让用户可以根据自己的需要，去打开不同级别的监控指标，并且这些不同的指标能够支持热加载，能够随时去方便动态的修改。同时，支持把监控指标输出到 JXM、Prometheus 和 IoTDB 等不同的外部系统中，同时指标也可以去写回到 IoTDB 本地。

当前我们支持了 134 个核心的监控项，这些监控项能够帮助用户去更好监控一个 IoTDB 的分布式系统，它是否处于一个比较优秀的状态，是否需要调优等等。