作者介紹
佔懷旻，花名心渡，阿里雲數字產業產研部-工業大腦團隊的大數據工程師，目前的工作方向是利用大數據與AI技術，為工業企業客戶構建數據中臺，支撐工業企業的數字化轉型和智能製造落地，用大數據技術來普惠更多的中國製造企業。
隨著2020年雲棲大工業大腦3.0的發佈，工業大腦已經經歷了多年的發展。本文將為大家分享，在工業數據中臺建設中使用DeltaLake的優秀實踐，主要包括：
(1) 異地異構流消息的處理
(2) 流批融合的數據分析
(3) 對事務的處理和對算法的支持
- 1.異地異構流消息的處理
對工業企業來說，數據源往往分散於世界各地，集團級別的用戶，往往希望以數據中臺為中心獲取數據，如下圖所示：
其中DeltaLake與Structured Streaming結合作用，完成以下兩件事情：
1、將各廠區的Kafka實時數據彙總後寫入中臺的Kafka，供實時類型數據應用使用
2、將各廠區的Kafka數據歸檔寫入中臺的HDFS，供離線分析類型數據應用使用
有很多大數據組件可以完成上面的任務，比如Flink和Flume等，但是以下理由讓我們最終選擇了DeltaLake：
1、支持使用正則消費多個Kafka Topic
使用SubscribePattern，可以使用正則實現同時消費多個Topic的數據，在一個園區有許多個Topic需要消費的場景下非常方便
2、對HDFS的支持和小文件合併的封裝
在遇到“將Kafka的數據實時寫入HDFS”的場景時，用DeltaLake也很方便，主要有2點原因：
1、天然對寫HDFS的支持，可以免去使用Flink的時候需要編寫HDFS Sinker，或者額外運維Flume集群帶來的麻煩
2、每一個流式入庫的場景，對於數據架構師來說都是一個性能與時效性的權衡取捨過程，不管是Flink、Flume還是SparkStreaming，都會有“滾動寫入容量(或條數)閾值”和“滾動寫入時間閾值”的設計，在實際的實施過程中，根據業務對於數據延遲和性能的需求不同，來權衡二者。例如對於延遲容忍度很低的場景，可以將容量或條數閾值設置的很小（甚至為1）來讓新的數據快速滾動寫入，但是這樣帶來的副作用是Sinker的頻繁IO，比如在HDFS產生很多的小文件，影響數據讀寫或DataNode的性能；在延遲容忍度較高的場景下，交付工程師則往往選擇將條數閾值和時間閾值加大，帶來更好的IO性能，但犧牲數據延遲。這是一種通用的方法，但在實際生產過程中，你會發現，要為許多的流作業維護許多不同的配置，這項工作的成本依然不小。
使用DeltaLake來處理，則可以輕鬆很多，你可以將所有的流作業的滾動寫入閾值設置成一樣的（比如都比較小），這樣所有的流作業都可以得到比較好的數據延遲，同時結合使用DeltaLake的特性功能Optimize和Vacuum，配置定時調度任務來週期執行，對小文件進行合併或刪除，來保障HDFS的性能，這樣可以使整個數據開發工作簡單很多，也更好運維。
關於Optimize特性的參考
- 2.流批融合的數據分析
在生產製造環節，機器設備的穩定運行對於產成品質量至關重要，而判定設備是否穩定運行的最直觀方法，就是查看某些傳感器的歷史長時間歷史趨勢，在實際項目實施過程中，交付工程師往往使用流作業，將Kafka中大量的傳感器時序數據加工後寫入OLAP存儲（例如阿里雲ADB、TSDB或HBase等），來支撐上層數據分析應用的高併發、低響應時間的實時查詢需求。
但是實際情況往往比這複雜得多，由於工業企業的信息化和數字化水平普遍不高，不同行業的生產過程自動化程度也參次不齊，有許多的設備實時數據其實並不準確，它們需要在若干時間以後（數分鐘或者數小時），經過人工干預或者重新計算較正後才能使用。
所以在實際實施過程中，往往採用一種“滾動覆蓋”的模式來不斷改寫OLAP存儲中的數據，將OLAP分為“實時增量區”和“週期覆蓋區”，例如下圖所示：
上圖使一個OLAP存儲，所有的數據被分為橙色和藍色兩部分，上層數據應用可以無差別地查詢這兩個區域的數據，唯一的差別是：橙色的最新數據，由流計算作業實時從Kafka獲取，做加工後寫入；而藍色區域，則由歷史數據週期性計算（加入矯正邏輯）後寫入，對昨天或更久之前的實時數據進行訂正，這樣週期往復，在保障數據時效性的同時，對歷史數據做訂正覆蓋，來保障數據的正確性。
在以往的做法中，往往使用一個流+批的Lambda架構，用兩種不同的計算引擎來處理流與批，如下圖所示：
Lambda架構的弊端也可由此可見，在兩個不同的平臺維護兩臺代碼，還要保障它們兩的計算邏輯完全一致，是比較費功夫的事情，在引入DeltaLake之後，事情變得相對簡單，Spark天生的流批一體設計，就很好地解決了代碼複用和跨平臺邏輯統一的問題，結合DeltaLake的特性（例如ACID，OPTIMIZE等），可以更優雅地完成這項工作，如下圖：
另外值得一提的是，流批一體並不是Spark的獨有特性，但是阿里雲EMR在SparkSQL和Spark Streaming之上又對SQL進行了一層封裝，使得業務人員能夠更低門檻地使用類似Flink SQL的語法來進行作業開發，使得流批場景下的代碼複用和運維工作變得更加簡單，這一點對於項目交付提效意義很大，點擊此處可具體參考。
- 3.對事務的處理和對算法的支持
傳統的數據倉庫，很少會在建模過程中引入事務，由於數據倉庫要反映數據的變化情況，所以往往使用緩慢變化維度等方法來記錄數據的狀態變化，而並不會用ACID來讓數據倉庫與業務系統保持一致。
但是在工業數據中臺的實施過程中，事務有他獨特的使用場景，例如排產排程，是每一個工業企業都關心的重大問題，排產，往往從集團級別進行，根據客戶訂單、物料庫存和工廠產能等角度來對當期的生產需求進行合理的分解和編排，來達到產能合理分配；排程則往往更加微觀，在工廠級別，根據工單、物料和實際的生產情況來實時動態調整生產計劃，達到資源利用率最大。它們都是需要眾多數據融合求解的規劃問題，如下圖所示：
排產排程算法所需要的原始數據，往往來自多個業務系統，例如ERP提供訂單和計劃數據，WMS提供物料數據，MES提供工單和工序數據，這些數據必須融合到一起（物理上和邏輯上），才能作為排產排程算法的有效輸入，所以在實施過程中往往需要一個統一的存儲來存放來自各系統的數據。同時排產排程算法對數據的實效性也有一定的要求，它需要輸入的數據能夠儘量與各個業務系統保持一致，這樣才能真實地反映出當時的生產情況，以便更好的進行排程。
在以往，我們這麼處理這種場景：
1）利用各個業務系統的CDC能力，或者單獨編寫程序來輪詢，準實時地獲取數據變化
2）寫入關係型數據庫，在此過程中處理數據Merge的邏輯，讓關係型數據庫中的數據與業務系統數據準實時地保持一致
3）排產排程引擎在被觸發的時候，從RDB拉取數據進行運算
這種架構有一些顯而易見的問題，主要有：
1）用RDB替代大數據存儲，計算的時候把數據Query到內存中，對於數據量比較大的情況會很困難
2）如果用Hive引擎來替代中間的RDB，雖然在Hive3.X支持ACID，但是實時性和MapReduce編程框架對於算法（求解器）的支持都難以滿足工程需求
目前我們正在嘗試引入DeltaLake，結合Spark的特性來優化這個架構，如下圖：
優化後的架構，有如下優點：
1）使用HDFS+Spark替代RDB作為中颱存儲，解決數據量大時候的存儲問題
2）使用Spark Streaming+DeltaLake來對接原始數據，利用DeltaLake的ACID特性來處理數據進入中臺存儲時的Merge邏輯，同時在流式入庫的時候同時對數據進行Merge+Optimize，保障讀寫性能
3）排產排程引擎不再從中臺Query數據到內存計算，而是把算法任務封裝成Spark作業，下發到計算平臺完成計算，這樣利用Spark ML編程框架對算法和Python的良好支持，以及Spark本身的分佈式計算能力，對需要多輪迭代的規劃算法進行分佈式處理
4）利用DeltaLake的Time Travel特性，對數據版本進行管理或回滾，這對於算法模型的調試和評估是非常有利的
- 4.總結
1）DeltaLake的核心能力ACID對於數據實時性和準確性要求較高的應用很有幫助，尤其是算法應用，可以更有效地利用Spark對ML的天然支持
2）結合使用DeltaLake的Optimize+Vacuum和Streaming的流式入庫能力，在大批量對接上游Kafka數據的時候會有更好的兼容性，同時可以有效的降低運維成本
3）利用阿里雲EMR團隊封裝的Streaming SQL開發流作業，在大規模的數據中臺項目實施過程中可以有效降低開發門檻和成本
目前，DeltaLake在工業大腦的應用尚在實驗階段，例如流式入庫、排產排程引擎、流批融合等多個場景正在工業大腦多個項目中應用，同時這些場景也在逐漸沉澱為工業大腦的標準產品，後續結合工業大腦3.0的數據+算法場景的可視化編輯和複製能力，可以快速複製到離散製造、汽車、鋼鐵等多個行業的場景中，用AI能力普惠中國工業。
感興趣的同學可以點擊此處參考
瞭解更多相關技術信息，掃描下方釘群二維碼
