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

        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 的格式，或者自己的序列化的格式，并没有针对时序数据做一些通用的压缩、存储和编码等等。

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

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