2022 IoTDB Summit：阿里白渐《迈向物联网时代大数据计算平台——MaxCompute 基于 IoTDB 构建解决方案》

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

我们邀请到阿里云技术专家，Apache IoTDB Committer 白渐参加此次大会，并做主题演讲——《迈向物联网时代的大数据计算平台 —— MaxCompute 基于 Apache IoTDB 构建的解决方案》。以下为内容全文。

大家好，我分享的题目是《迈向物联网时代的大数据计算平台 —— MaxCompute 基于 Apache IoTDB 构建的解决方案》。我是来自阿里云 MaxCompute 团队的白渐，我本人目前就职于 MaxCompute 团队，致力于大数据物联网解决方案的设计与开发。MaxCompute 是阿里云自研的大数据平台，我本人也是 Apache IoTDB 的 Committer。

我的分享包含以下三个部分，首先介绍一下物联网时代的大数据计算平台都要应对哪些技术挑战。第二部分则通过一个用户案例来介绍 MaxCompute 物联网边缘端解决方案 Lemming 是如何应对上述挑战的。第三部分则对我们的工作做一个总结以及展望。

01 物联网时代的大数据计算平台

下面我们介绍第一部分，物联网时代的大数据计算平台要应对哪些技术挑战。首先我们回顾一下大数据的发展历史，在最早的时期是没有大数据这个概念的，所有的数据都要存在数据库中，这些数据的来源则是企业的订单、合同等信息，这些信息的数量取决于企业的生产经营规模，对于一个中层企业来说，它每年产生的合同和订单可能是上百或者千级别的，这种数据量对于一个单机的数据库实例是完全能够管理好的。对于这些数据，它们是有一些特征的。首先这些数据是一个非常高度结构化的数据，并且这些数据的价值密度也非常的高。这就意味着对于一个企业来说，他只需要仅有的几个订单或者合同信息，就可以猜测出将来的市场的一个发展的方向，根据这些信息，他从而指导自己的生产经营决策。在这个时候，由于数据量少，价值密度高，是没有任何的大数据分析需求的。

但是随着互联网的普及，我们进入了互联网大数据时代，这个时候很多互联网用户产生了一些互联网行为日志，这将作为互联网大数据时代的数据来源。这些行为日志的数据规模，它们取决于参与互联网活动的人口以及每个人参与互联网活动的时间。这些数据的特征则是半结构化的特征，因为不同的用户在浏览不同系统的时候，产生的数据以及要介入的数据是不一样的，并且这些数据具有非常低的价值密度，对于一个用户的单条互联网行为日志是没有任何分析价值的，我们往往需要结合用户在不同系统的浏览日志，然后做一个综合的分析。对于跨系统跨结构的这种数据分析，已有的数据库实例是没有办法完成这个任务的，因为数据量非常的大，这个时候互联网的参与人数已经是百万、千万级别，产生的数据量每天可能是亿级别的。

为了完成这个数据分析需求，很多开源的大数据系统应运而生，这些大数据系统的一个最显著的特点就是能够利用廉价的计算资源，完成分布式的计算，然后完成我们的数据分析需求。一个比较典型的系统，就是我们常见的推荐系统，比如你打开的首页可能会看到一些推荐的商品，这些推荐的商品则是在后台根据你的行为去做一些大数据的计算，然后得到要推荐哪些商品的，例如你的浏览结果、搜索结果、购物车购买结果，然后以及商品的一些促销的信息，综合这些信息会给你推荐出一些你可能会感兴趣的商品。虽然这个时期产生的数据量非常大，但是随着大数据的技术的发展的完善，现在的大数据系统已经能够很好的支持互联网时代大数据分析的需求。在这个时期阿里云也推出了自己非常领先的大数据分析平台 MaxCompute。到了现在，互联网的发展规模其实已经到了瓶颈，在下一个时期，大数据的分析又要面临哪些技术挑战呢？

在下一个时期其实我们可以观察到一些现象。首先现在很多的机器随着无线技术的发展，它们的传感器的数据可以发送并且收集了，这些数据它的产生的频率要远高于互联网时代用户产生的数据频率。这些数据的信息密度和那个互联网时代相比，它的数据信息密度会更低。因为一个机器在正常工作的时候，我们是不太关心它的收集的数据的，但是我们往往要关心它在异常的时候产生的数据，然后根据这些异常数据，我们要进一步对这些机器的下一步的行为做一些调整乃至管理。对于一个企业来说，它有很多的车间，每个车间有很多的设备，对于一个车间来说，它会有成千上万的设备，一个设备又有成千上万的传感器，对于一个车间来说，它产生的数据源就要有百万甚至千万级别，这个数据量也是非常的大的。还有一个显著的特点就是机器产生的数据并不像互联网时代那样直接发送到云上，而是会先将这些数据发送到机房内的数据采集服务中，这些数据采集服务会进一步处理，将这些数据再同步到云上。

根据以上对物联网时代大数据的场景的分析，我们可以看到现在大数据平台都需要具备哪些功能呢？首先这个设备它是在边缘端，数据上传要收集到边缘端的采集服务中，但是我们的大数据平台又部署在云端。现在这个云端的大数据平台是没有办法去直接用边缘端的数据做数据分析的，这些数据就需要有一个机制去将边缘端的数据同步到云端。

在同步的过程中，我们又面临了网络边界的问题，因为边缘端和云端它是两个不同的网络，我们在数据传输的时候就一定要走到公网，企业有可能为了数据安全的一些考虑，会考虑自己建专线。专线的带宽的代价是非常高的，但同时我们上传的数据量又非常的大，因为设备非常的多，并且它产生的频率也非常的高，过大的数据量就需要我们有非常高的专项的带宽，这样的话会导致整个企业的带宽成本会非常的高。同时这些数据的价值密度也非常的低，因为我们刚才可以看到我们关心的是那些异常数据，对于正常数据其实是没有必要向云端同步的，也就是说这些正常的数据其实是浪费我们这些带宽的。同时由于公网本身是不稳定的，在传输的时候可能会出现一些网络中断的问题，对于一些重传的操作来说，也会进一步消耗我们宝贵的带宽资源。

除了这个数据同步，我们还需要在边缘端有一些数据计算和展示的工作，因为边缘端的数据它的实时性是要远高于云端数据的，所以在边缘端比如说一个管理员，他希望能够实时的看到我当前这个车间内所有设备的最新的一个工作状态，这就意味着我边缘端就需要能够处理这个收集的工程数据，然后做一些计算，比如说聚合计算这种，将这些计算结果展示在我边缘端的系统中。这个时候为了完成边缘数据的计算任务，我们可能会采用一些传统的大数据系统或者数据库来完成，但是它们都会有一个问题，就是它们并不是针对物联网数据来设计的，而物联网数据的一个结构特点就是它是一个时序数据，也就是说它在上传的时候是一个以非常高的频率上传它的设备信息以及时间戳以及监测值的。对于已有的关系型数据来说，它很难去满足一个高并发的写入和高并发的查询，这就意味着我光靠一个系统是没有办法解决边缘端的计算问题的，我需要使用很多的已有的数据存储或者是业务处理系统。更多的系统意味着我的架构会变得非常复杂，我的学习和运维成本非常高，同时这些系统越多，我边缘端的算力又有限，这些非常多的系统会额外占用很多边缘端的资源，也会极大的提高我们边缘端的架构成本。所以对于一个大数据平台来说，如果他想在物联网时代解决大数据分析需求，它就需要从这两个方面去降低它的成本。

02 MaxCompute 物联网边缘端解决方案 Lemming

下面我们看一下第二部分，MaxCompute 物联网边缘端解决方案 Lemming 是如何应对这些技术挑战的。Lemming 是阿里云大数据平台 MaxCompute 基于 IoTDB 实现的物联网大数据计算解决方案，它主要包含三个模块。首先它具有 Apache IoTDB 的内核，它本身就是一个十分高效的 IoT 数据的存储和查询引擎。我们在这个基础上自研物化视图引擎和云边同步引擎，物化视图引擎负责完成边缘端数据计算的任务，云边同步引擎则负责实现数据从云同步到边的功能。

为什么我们会选择 IoTDB 呢？首先 IoTDB 是自主可控的，IoTDB 100% 开源，具有国内名校的背景，是 Apache 的顶级项目，有完善的文档和活跃的社区。IoTDB 是商业友好的，遵循 Apache 2.0 开源协议，它的本身生态也是十分丰富，可以无缝去集成其他主流的大数据系统，这意味着对于一个云产品来说，它在将来可以服务更广的用户，实现更广的需求解决方案。从技术上来看，它具有十分健壮的架构，它内置大规模并行处理框架，可以按需扩展。IoTDB 本身的性能也是十分优异的，它具有高数据的压缩率、低写入延迟和资源占用，十分适合边缘端物联网数据的处理。

我们团队在社区其实也做了很多的贡献。主要包括像最近马上发布的 1.0 的版本中，我们主要贡献了 MPP 框架的调度以及内存管理的一些模块的开发和设计。为了保证我们在 1.0 的开发过程中的一个快速迭代，我们贡献了集群测试框架，在集群测试框架的实现中，我们可以完成集群模式下数据一写多读的测试以及多架构的测试。同时我们本身还将一些云边同步的插件功能以及查询引擎设计的一些新的 feature 反馈回到这个社区。同时我们还紧密的和这个社区达成合作，在社区的一些活动或者是双周会中做很充分的一些分享。

下面我们来通过一个实际的客户案例，看一下 MaxCompute 是如何解决云边同步的技术难题的。这是一个工程车辆公司，下面这个图是原有的 MaxCompute 云边一体的解决方案，数据是从工程车辆公司的工作的车辆上收集出来的，这些车辆每天在工作的时候会将油温、水温、工作时间这种常规的数据传递到边端的数据采集服务中。边端的数据采集服务的下游是一个他们的业务 App，业务 App 为了维护数据的完整性，他们要将这些实际数据存在本地的 TSDB 中。为了做这个大数据的分析，他们又需要将数据做一些预处理，然后发送到云端的 MaxCompute 的服务中。

从整个解决方案中，其实我们可以看到很多问题，首先它的架构是非常复杂的，除了用到云边的服务之外，他们在边缘端还需要用一些开源的大数据系统来解决他们边缘端的计算问题，这也导致了他们在边缘端需要有很高的学习和运维成本。其次它的存储是十分冗余的，可以看到全量数据不仅存在 TSDB 中，还需要存在云端的 MaxCompute 中，这种冗余的存储也会给它们带来比较高的存储成本。由于它的数据是全量的同步到云端，这个过程就会浪费很多的带宽，因为我们在第一部分的分析中已经看到，其实对于 IoT 数据它的价值密度是十分低的。如果我们只上传这些高价值密度的数据，是可以非常大程度的去降低它的成本的。由于我们原有的方案是没有办法在边端得到这些高价值数据的，我们就需要将所有的数据发送到云端，然后在云端计算出这些高价值数据，这样也会浪费了云端的一些计算的一些资源。从这个解决方案中可以看到，整个解决方案的成本是非常的高的，我们的目的就是为了降低用户云边同步的方案的实施成本。

下面我们看一下有哪些数据是高价值的。我们统计了某一天这个车辆上传的温度数据，这个车辆上传的水温数据每天大约有 4 个 G，但是我们要关心的只是这些水温数据中比较高水温的那些数据。我们计算了一下高水温数据一共只占 7 KB，这些数据占比是 0.18%，也就是说这个其实也是验证了我们之前说的，这个时序数据量巨大，但是它的信息密度是十分低的。如果能在边缘端，我们把 0.18% 的数据计算出来再同步到云端的话，我们可以节省非常大的成本。

应用 Lemming 后这个解决方案就是下面这个图，在业务 App 这个端，因为 Lemming 本身它是支持 IoT 数据的存储和查询，所以数据就不需要再向额外的 TSDB 去存了，它直接存在 Lemming 中就可以了。并且 Lemming 本身是内置了物化视图引擎，可以承担所有的边缘端的数据计算任务。Lemming 由于它本身还具有云边同步的功能，它可以将这些计算出来的高价值数据同步到云端的 MaxCompute 中，这样 MaxCompute 它就不需要存储这些冗余的低价值数据了，它把这些高价值数据存出来之后计算，就可以发送给上游的一些系统。可以看到整个应用 Lemming 之后，它的数据传输成本、存储、计算成本以及系统架构都得到了大幅的简化和效能的一些提升。

下面我们来看一下 Lemming 内部物化视图和云边同步引擎它们的一些技术的架构和实验细节。首先介绍一下物化视图的实现，对于 Lemming 来说，由于它是基于 Apache IoTDB 实现的，它本身也是支持时序数据的写入的，时序数据会写入存储在存储引擎中，这些数据本身具有质量大、价值密度低的特点，这些数据会异步的被物化视图引擎做消费，物化视图引擎会将这些写入的数据作为物化视图的计算的算子的输入。算子的输入一旦满足条件，会触发物化视图算子的计算，物化视图将计算结果也可以写回到 Lemming 的存储引擎中。写回的这个计算结果还可以当作其它物化视图的输入，这样会形成这种流水线的这种计算过程，这些计算结果因为是存储在存储引擎中，它可以是直接被外部的客户端去做查询的。计算的结果会通过云边同步引擎实时地向云端进行同步，同步的数据就是我们期望的数量少，但是价值密度高的。整个物化视图的这些功能，我们之后会按照我们的计划逐渐的回馈到社区。

下面是一个物化视图的一个使用示例，我们可以看到在这个例子中，其实我们只要通过一条 SQL 语句就可以完成一个物化视图的定义，这个 SQL 语句本身它的主要逻辑其实和我们日常的查询语句它的语法是非常类似的，它具有一个非常低的使用和学习成本。

下面我们看一下云边同步内部的一些实现细节。云边同步的它的最核心的模块就是同步模块，同步模块它现在是支持 TsFile 的增量和存量数据的一个同步过程。同步模块它可以将数据高效地同步到云端的 Lemming 实例中，它也可以通过云边同步的插件机制将数据同步到 MaxCompute 或者是其他的云端 DB 中。这个插件机制它是一个非常强大的设计，它可以支持非常强的扩展能力，之后如果有其他的云边同步需求，我们只需要扩展插件系统就可以完成数据向其他系统的数据同步。

在同步的时候，我们会因为本身的 TsFile 它是具有一个高压缩比的，它的传输速度是非常快的，可以极高的运用我们的带宽。同步模块它本身是高可靠的，它会在同步的过程中实时地记录同步的进度，一旦网络中断或者边缘端的 Lemming 出现宕机，在恢复后它可以根据接入的进度继续同步数据。云边同步引擎的插件机制，目前我们已经回馈到 IoTDB 社区了。

下面这个例子则是一个云边同步的使用的场景。也可以看到云边同步的建立是非常简单的，只需要通过两条 SQL 语句就可以完成，所以我们的功能其实都是为了增强解决用户的能力，并且降低用户的学习、使用以及运维成本。

我们最后来看一下成本的一个降低效果。旧有的方案，因为每天需要同步全量的数据，假设我每天同步 5T 的数据，我们要计算一个最低的带宽，这个最低的带宽的计算方式是我这 5T 的数据，如果我传输 24 小时需要传输完毕的话，我这个时候会算出一个带宽大约是 485 兆的一个大小，那也就是说我至少需要一个千兆的网。如果我把这个千兆网打满的话，我传输 5T 数据需要 11.37 个小时。当我们使用新方案的之后，我们同样的去计算带宽，它每天的最低带宽只需要 1 兆。那这个情况下，如果我们使用百兆网做数据同步的话，把百兆网打满，也只需要 14 分钟。可以看到在光是带宽这一项就已经非常大的降低了它的一个成本。

再看一下我们产品生态，我们是支持多种客户端协议以及数采协议写入的。我们在数据技术的输出形态上，除了公有云之外，我们还支持一体机、专有云、云盒的输出模式。根据用户的硬件环境和业务需求的不同，我们可以提供单机版、高可用版乃至集群版的部署形态。因为 IoTDB 本身具有十分强大的生态能力，它是可以无缝的去衔接像 Grafana、Prometheus 这种监控数据展示的。我们 Lemming 的强大的云边同步引擎，它是可以将数据同步到云端的 Lemming 池里、MaxCompute 服务乃至其他的一些云边的存储或者大数据服务中。

03 总结与展望

最后，对我们的工作做一个总结以及展望。越来越多的客户需求表明，在物联网时代，大数据系统要面临的技术挑战会越来越多。比如在数字孪生这个方向，他的需求是在边缘端有限的硬件资源环境下，要支持高并发的实时查询，这就要求大数据系统在边缘端要有非常好的性能。在新能源方面，它需要支持时序数据以及关系数据的联合查询，这意味着对于一个大数据平台来说，它需要能够同时支持时序数据以及关系数据的联合分析功能。像对于一些水泥企业来说，他们希望将计算的结果反控回边缘端的设备，以指导优化边缘端的设备工作，这就要求大数据解决方案需要具有云边协同的能力。

Gartner 预测，到 2025 年，超过 50% 的企业的关键数据将在数据中心以外或者云以外的地点创建或处理，这意味着任何的大数据解决方案不能再只限于云端。为了解决物联网时代数据分析需求，需要拓展自己的边界，将能力辐射到边缘端，以符合时代发展的需求。工业界的发展趋势也是从工业制造到工业“智”造，也就是说从单纯的工业生产变成智能化生产，这个转变过程也要依托于物联网大数据的技术能力才能实现。我们在这方面的架构的演进也是十分开放的，我们会紧贴时代和市场的需求，拥抱变化，应对未来的挑战，谢谢大家。

可加欧欧获取大会相关 PPT

微信号：apache_iotdb