同程旅行吳祥平：同程湖倉一體應用與實踐

　　本文根據吳祥平老師在【第十五屆中國系統架構師大會（SACC2022）】線上演講內容整理而成。

　　 本文摘要：

　　為了解決數倉存在的一些問題比如：數倉的實時性，資源消耗，更新需求日益變多，我們跟進業界步伐實踐了從數倉到湖倉的轉變。目前我們將大多數hive表改造湖倉表，替換內部數倉base層hive表為hudi表，時效性由T+1降低為分鐘級延遲，同時基於hudi實現了流式寬表，實時join等場景的落地，為業務降低了大量計算資源的使用。

　　本次分享，湖倉架構的演進實踐。分享內容包括：數倉架構和規模，碰到過什麼問題、資料湖與數倉的區別，為什麼選擇hudi、湖倉架構在同程旅行的實踐過程，架構演進思路是什麼、湖倉實踐過程中的問題等。同時，對湖倉技術方案未來發展、實踐經驗與思考等內容。

　　 同程旅行數倉現狀

　　在引入湖倉之前，我們採用Lambda架構數倉，一條實時鏈路和一條離線鏈路，實時鏈路基於Kafka和Kudu實現，離線鏈路基於Hive和olap引擎如GP/CK/StarRocks等加速資料應用。

　　我們目前有80%的離線場景，每天8萬+離線任務，40萬+hive表；20%實時場景，4000+實時任務。要知道Lambda架構在大資料時代主導了很長時間，但隨著資料應用場景的不斷豐富，實時性需求越來越多，Lambda架構的缺點就被逐漸放大。　　

　　基於Lambda架構數倉痛點主要體現在四個方面：

　　1，資料計算冗餘：Binglog實時入倉，離線任務每天定時合併，且業務計算需要等待。

　　2，開發和維護困難：兩條鏈路，邏輯一致性保障，技術要求不一樣，結果往往不一樣。

　　3，資料儲存冗餘：合併產生大量臨時表，中間結果表等資料急速膨脹造成儲存壓力，實時離線可能多份。

　　4，計算壓力變大：夜間計算視窗可能完不成白天累積的資料。

　　 資料湖與數倉區別

　　正因為Lambda架構問題居多，我們開始調研資料湖相關技術，資料湖與數倉的區別有很多，我主要從兩個維度來分享。

　　區別一：計算模型。資料湖能夠支援增量更新的方式增量流讀，但數倉是基於全量或分割槽覆蓋的方式，不支援區域性更新。

　　區別二：資料管理。資料湖基於統計資訊，索引管理檔案，能夠更細粒度的管理資料檔案，加速資料入湖或資料在湖上查詢，而數倉更多是基於分割槽管理。

　　不僅如此，資料湖還具備如快照、時間旅行、結構演進等數倉不具備的特性。

　　 資料湖基本概念和原理

　　選擇hudi的原因是因為其包含了資料湖的多個基本特性，如ACID事物支援、Merge-On-Read、Bulk Load、Incremental Query、Time travel等等；其次，hudi在設計開始就擁有任務自管理功能，包括快照commit、過期快照清理、小檔案合併、mor表的定期壓縮、rollback、回滾等；最後是因為比較鍵、Payload抽象，比較鍵既能應對CDC場景又包括普通訊息，payload能夠在合併階段完成包括更新，區域性更新等特殊場景。　　

　　在hudi整體應用架構方面，hudi是介於HDFS或物件儲存和查詢引擎之間的抽象，自身提供了資料湖的基本功能之外，還包括自帶的資料攝入模組，同時在應用架構中還劃出了增量流讀的過程，為後續構建流式數倉提供了可能性。

　　hudi如何進行資料更新？模式一：Copy-On-Write，寫時合併，寫放大，讀最佳化；模式二：Merge-On-Read，讀時合併/定期合併，讀放大，寫最佳化；

　　hudi的最大特點是具有索引技術，資料湖索引包括如Bloom/bucket/hbase等，我們可以透過主鍵索引實現高效區域性更新，還可基於索引最佳化查詢。

　　時間抽也是hudi不得不提的一個概念，一個時間軸由三部分組成：Action：COMMITS,CLEANS；State：REQUESTED,INFLIGHT和time。時間軸是hudi實現快照流讀，回滾不可或缺的一個設計。

　　 湖倉一體實踐

　　在湖倉一體整體架構上，我們採用了批流一體的統一實時離線鏈路，並自研了資料整合方案。　　

　　目前，我們的湖倉一體現狀是：700+核心ODS表入湖；基於ODS清洗任務啟動時間提前至：0：05；核心ODS層資料新鮮度由T+1提升至分鐘級；完成多個業務線流式數倉場景落地。

　　在流式數倉場景上，我們從底層資料、數倉模型到報表全面切到湖倉一體中，支撐用車業務能更及時監控壞賬、經營資料。同時，我們還運用區域性更新Payload實現了實時關聯維度資料打寬。

　　在增量統計場景上，我們結合Flink Cumulate視窗實現資料增量統計入hudi。

　　在資料湖應用過程中碰到了一些挑戰：如何讓業務更快的入湖？後設資料多引擎多次宣告如何解決？入湖的資料脫敏和資料質量怎麼做？資料丟失？

　　資料整合選型我們有兩種方案，即Flink CDC和自研基於MQ。雖然Flink CDC已經很完善了，但是我們內部還是出於資料安全和MQ複用這兩點的考慮選擇自研。　　

　　資料整合架構V1的優點和問題：優點是適合中等資料量場景，可實現線上補數（全量、增量）。問題是全量資料參與了入湖Upsert計算，資料量較大時全量叢集IO壓力大，並行任務數受限。　　

　　資料整合架構V2做出了最佳化，其更適合超大資料量場景，同時並行多工。透過最佳化，我們遮蔽了相關資源申請、Flink同步任務、Hudi引數等細節，實現一鍵同步功能。　　

　　下一個挑戰是後設資料的問題：Flink任務宣告Hudi表，開啟同步到Hive，Flink流讀/批任務需再次重新宣告Hudi表；Mq表的宣告同樣，多次消費多次定義；資料血緣採集困難。　　

　　我們如何解決上述問題呢？以後設資料宣告為例，我們針對痛點提供了一套統一後設資料方案，具體實現方式是：改造Hive-Connector，使用原生Meta列屬性；Flink使用透過like方式修改屬性；擴充套件hive引擎支援透過Hive Sql查詢訊息佇列。

　　統一後設資料之後，實現Flink/Hive/Spark/Presto多引擎共用，一次宣告多次使用。　　

　　在資料脫敏方面，如何取樣落在MQ中的資料來源？我們自研了Flink sql資料預覽，基於On yarn Session叢集實現，支援多Flink版本，可複用FlinkTaskManager（1小時過期），最快5s內返回結果。在預覽脫敏方面，我們即席預覽資料，透過自定義加密函式進行資料脫敏。

　　下一個挑戰是資料質量的問題：每日凌晨MQ資料抽樣資料時間；批處理前置增加資料質量監控依賴。

　　在資料丟失方面，主要有兩個代表性的情況，HUDI-4311和HUDI-3912。同時，我們對hudi應用過程中還有很多其他的修復。

　　給大家分享一些部分hudi使用建議，在提升入湖速度方面，可以增加任務Checkpoint時間間隔，增加相鄰兩次Checkpoint間隔，減少管理記憶體大小（Bucket Index)，增加Hudi合併記憶體大小。

　　在提升入湖穩定性方面，增加Flink任務堆外記憶體的配比（合併階段，Flink預設為0），設定合理的保留策略避免.hoodie路徑下檔案過多，關注儲存RPC壓力情況。

　　 未來規劃

　　針對未來，我們還將不斷完善在資料湖上的應用，具體方向包括：提升湖倉易用性，擴大湖倉應用範圍和完善湖上分析能力。

　　嘉賓介紹

　　吳祥平，同程旅行資料中心計算叢集研發組技術負責人。2012年畢業於浙江海洋大學，熱愛Coding、熱愛開源，是flink、hudi開源社群貢獻者。