作者：美的楼宇科技事业部 先行研究中心智能技术部
美的楼宇科技 IoT 数据平台建设背景
美的楼宇科技事业部（以下简称楼宇科技）是美的集团旗下五大板块之一，产品覆盖多联机组、大型冷水机组、单元机、机房空调、扶梯、直梯、货梯以及楼宇自控软件和建筑弱电集成解决方案，远销海内外200多个国家。针对当前设备数据量庞大且持续增长、数据呈现半结构化特点的现状，现有系统仅停留在数据存储和基础使用层面，缺乏深度挖掘数据价值的能力，导致大量潜在信息未被充分利用。因此，迫切需要构建一个统一且通用的 IoT 数据平台，平台不仅要具备高度的弹性和轻量化特性，还应具备强大的大规模数据处理能力以及数据科学和 AI 技术支持，以实现快速的数据分析与智能化挖掘，推动楼宇系统的智能化升级，支持节能、设备管理和运维等方面的精确决策。我们的 IoT 数据平台建设基于阿里云 EMR Serverless Spark ，我们将就IoT数据平台建设技术选型上的一些思考，以及 Spark 技术栈尤其是场景应用实践做一下分享。
Lakehouse 架构
楼宇科技通过阿里云EMR Serverless Spark，实现了数据与 AI技术的有效融合，并结合EMR Serverless StarRocks搭建了Lakehouse 平台。该平台核心部分如下：
首先，上游设备或传感器数据通过Serverless Spark提交Streaming作业，实时以Apache Hudi格式写入数据湖，湖表元数据同步至DLF，以保持数据的实时性。
接着，采用天级调度执行Hudi分区数据的Compaction，并使用 Z-order 来优化数据布局，实现了10倍以上的查询加速。同时，DLF的锁机制确保了实时写入与异步湖表任务的并发事务管理，为作业稳定性、数据一致性提供了保障。
此外，还通过 Serverless Spark构建了数据Medallion架构，从加载的源始数据开始(Bronze)，经过清洗转化为明细数据(Silver)，然后根据不同业务需求将明细层数据转化为高质量的指标数据(Gold)，为上层业务系统提供支持。
在AI应用方面，楼宇科技通过Serverless Spark PySpark 任务，并基于PyArrow UDF调用自研算法实现了千亿级别数据在百万级维度的聚合，推动了Data + AI技术在实际业务中的应用。最后，处理后的指标数据从数据湖中被加载到StarRocks中，为上层应用提供Dashboard和报表支持，提升了数据的可视化和决策能力。
以下架构图展示了如何利用Serverless Spark结合开源湖格式Hudi、ML/AI的多种工具库，以及阿里云 DLF 统一湖仓管理平台，实现高效的数据处理和AI赋能，使用Serverless StarRocks实现极速数据分析，为业务应用带来显著的提升。
选择 Spark 技术栈
在数据平台计算引擎层技术选型上，前期的架构选型我们做了很多的调研，综合各个方面考虑，希望选择一个成熟且统一的平台：既能够支持数据处理、数据分析场景，也能够很好地支撑数据科学场景。加上团队成员对 Python 及 Spark 的经验丰富，所以，从一开始就将目标锁定到了 Spark 技术栈。
为什么选择阿里云EMR Serverless Spark
EMR Serverless Spark 解决了我们什么痛点
-
自建集群 POC 测试需要花费大量的成本，周期也比较长；
-
针对千亿级别的IOT设备上报数据，引擎性能非常关键。对原始数据做一轮点位提取(t+1处理)，用于后续数据开发和分析，每日的点位提取需要在短时间内运行大量资源对湖原始数据进行查询和处理；
-
需要完善的Spark 生态，来实现全链路数据流转，来满足批、流、交互式、机器学习等不同场景需求；
-
弹性计算能力，需要一次性支持大规模计算，缩短数据使用延迟。多联机能耗运行月度报告生成的过程中，每月5号之前需要大量资源去生成上月的月度报告指标；
-
Data+AI场景的支持能力。
成本相比过去架构提升
-
不同场景下的整体性能提升50%以上
-
综合成本下降30%左右
IoT 数据链条
我们接入的 IoT 数据分为两部分，历史存量数据和实时数据。目前，历史存量数据是通过 Spark SQL 以天为单位从不同客户关系数据库批量导入 Hudi Lake 表中；实时数据通过 IoT 平台采集到云 Kafka ，经由 Spark Structured Streaming 消费后实时写入到 Hudi Lake 表中。在这个过程中，我们将实时数据和历史数据都 sink 到同一张 Hudi 表里，这种批流一体操作可大大简化我们的 ETL 流程（参考后面的案例部分）。数据管道下游，我们对接数据分析及数据科学工作流。
IoT 数据采集：从 Little Data 到 Big Data
作为 IoT 场景的典型应用，美的暖通最核心的数据均来自 IoT 终端设备。在整个 IoT 环境下，分布着无数个终端传感器。从小的维度看，传感器产生的数据本身属于 Small Data（或者称为 Little Data）。当把所有传感器连接成一个大的 IoT 网络，产生自不同传感器的数据经由 Gateway 与云端相连接，并最终在云端形成 Big Data 。
在我们的场景下，IoT 平台本身会对不同协议的数据进行初步解析，通过定制的硬件网络设备将解析后的半结构化 JSON 数据经由网络发送到云 Kafka。云 Kafka 扮演了整个数据管道的入口。
数据入湖：Hudi
IoT 场景下的数据有如下几个特点：
时序数据：传感器产生的数据记录中包含时间相关的信息，数据本身具有时间属性，因此不同的数据之间可能存在一定的相关性。利用 as-of-join 将不同时间序列数据 join 到一起是下游数据预测分析的基础
数据的实时性：传感器实时生成数据并以最低延迟的方式传输到数据管道,触发规则引擎，生成告警和事件，通知相关工作人员。
数据体量巨大：IoT 网络环境下遍布各地的成千上万台设备及其传感器再通过接入服务将海量的数据归集到平台
数据协议多样：通常在 IoT 平台接入的不同种类设备中，上传数据协议种类多样，数据编码格式不统一
数据半结构化: 不同设备包含不同的属性，基于JSON 结构把所有IoT模型抽象为JSON 字符串
IoT 数据上述特点给数据处理、数据分析及数据科学等带来了诸多挑战，庆幸的是，这些挑战借助 Spark 和 Delta Lake 都可以很好地应对。Hudi Lake 提供了 ACID 事务保证，支持增量更新数据表以及流批同时写数据。借助 Spark Structed Streaming 可以实现 IoT 时序数据实时入湖。
以下是 Hudi Lake 经典的三级数据表架构。具体到楼宇科技 IoT 数据场景，我们针对每一层级的数据表分别做了如下定义：
Bronze 表：存储原生数据（Raw Data），数据经由 Spark Structed Streaming 从 Kafka 消费下来后 Append/Upsert 进 Hudi Lake 表，该表作为唯一的真实数据表 （Single Source of Truth）
Silver表：该表是在对 Bronze 表的数据进行加工处理的基础上生成的中间表，在美的暖通的场景下，数据加工处理的步骤涉及到一些复杂的时序数据计算逻辑，这些逻辑都包装在了 Pandas UDF 里提供给 Spark 计算使用
Gold 表：Silver 表的数据施加 Schema 约束并做进一步清洗后的数据汇入 Gold 表，该表提供给下游的 Ad Hoc 查询分析及数据科学使用
数据分析：Ad-Hoc 查询 & 实时分析
我们内部在开源 Superset 基础上定制了内部版本的 SQL 查询与数据可视化平台，通过StarRocks Lake Catalog实现对湖数据查询。借助 Superset ，数据分析师及数据科学家可以快速高效的对 Hudi Lake 表进行数据探索。
StarRocks主要应用于BI报表分析平台 、实时大屏(如设备实时跟踪场景)，通过Serverless StarRocks可大大提高对数据湖的分析和查询性能，相较于Trino等查询性能有3-5倍性能提升。且利用物化视图可以对实时写入数据进行再次近实时加工和处理，满足大屏分析等实时数据展示、进一步提升查询性能、降低资源使用。
数据科学：Jupyter 交互式开发
楼宇能耗优化与设备故障诊断预测是楼宇科技IoT 大数据平台建设的两个主要业务目标。在 IoT 数据管道下游，需要对接机器学习平台。现阶段为了更快速方便地支撑起数据科学场景，Serverless Spark 支持对接在数据科学场景下更友好的 Jupyter Notebook ，通过在 Jupyter 上使用 PySpark ，可以将作业运行到Serverless Spark上；对于有周期性执行的作业，也可以借助 Apache Airflow 对作业进行调度。同时，考虑到机器学习模型构建、迭代训练、指标检测、部署等基本环节，我们也在探索 MLOps ，目前已概念验证通过OSS+MLflow+Serverless Spark
Hudi Lake 数据入湖（批流一体）
query = (df.writeStream.outputMode("append").options(**hudi_options).format("hudi").option("path", table_oss_path).option("checkpointLocation", streaming_checkpoint_location).trigger(availableNow=True).start()
)
湖表管理
Compaction & Z-Ordering
通过Spark Streaming实时的将数据写入到Hudi湖存储上能够提升数据的新鲜度，但同时也产生大量的小文件影响下游系统的查询性能。另外，对于查询模式相对固定的Hudi表，我们也通过Z-Order来优化数据布局，再借助Data-Skipping能力能够进一步提高查询性能。同时由于Z-Order使得局部数据结构相似，也使得以Parquet格式存储时有更大的压缩效果，降低了存储成本。
美的楼宇客户IoT数据以天为维度进行分区管理，数据实时注入到特定的天级分区内，因此我们通过EMR Serverless Spark产品以T+1的方式对T分区内的数据进行带有Z-Order的Compaction实现了高效的Hudi表的文件管理，有效的提升了查询性能。
call run_clustering(table => '{db_name}.{table_name}',op => 'scheduleAndExecute',order => 'device_id',order_strategy => 'z-order',predicate => '({predicate})',show_involved_partition => false,options => "{options}"
);
Clean
Hudi Lake支持事务提交提供了多版本、TimeTravel等丰富的功能，但也使得历史的过期的文件依然保留在文件系统中造成存储的浪费。我们也基于EMR Serverless Spark实现了天级调度Clean作业来定期清除不需要的数据文件，避免存储资源浪费。
总结与展望
我们基于阿里云 EMR Serverless Spark技术栈快速构建了 IoT 数据处理平台，Serverless Spark全托管免运维、自研 Fusion 引擎，内置高性能向量化计算和 RSS 能力，相比开源版本3倍以上的性能优势以及计算/存储分离的架构，为我们节省了总体成本。同时，EMR Serverless Spark自身提供的丰富特性，也极大提升了我们数据团队的生产力，为数据分析业务的快速开展交付奠定了基础。未来，美的楼宇科技希望与阿里云 EMR 团队针对 IoT 场景输出更多行业先进解决方案。
