作者:美的樓宇科技事業部 先行研究中心智能技術部
美的樓宇科技 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 場景輸出更多行業先進解決方案。