本文主要介紹離在線數據倉庫建設在攜程旅游團隊的落地與實踐，將從業務痛點、業務目標、項目架構、項目建設等維度展開。

　　一、業務痛點

　　隨著數據實時化需求增多，離線數倉暴露出來的業務痛點也越來越多，例如：

　　實時需求煙囪開發模式

　　中間數據可復用性差

　　離在線數據開發割裂

　　數據生產->服務周期長

　　實時表/任務雜亂、無法管理

　　實時血緣/基本信息/監控等缺失

　　實時數據 質量監控無工具

　　實時任務 運維門檻高 質量體系弱

　　這類典型的問題，會對我們的人效、質量、管理等方面帶來較大考驗，亟待一個體系化的平臺來解決。

　　二、業務目標

　　圍繞已知業務痛點，依托于公司現有的計算資源、存儲資源、離線數倉標準規范等，我們的目標是在人效、質量、管理這幾個層面進行系統建設。如下圖：

　　2.1 人效層面

　　實現離在線數據開發方案標準化，如標準化數據處理、離在線代碼兼容、算力融合等

　　分鐘級數據部署，實現BI同學層面的數據接口注冊、發布、調試等可視化操作

　　2.2 質量層面

　　數據內容DQC，如內容對不對、全不全、是否及時、是否離在線一致等

　　數據任務預警，如有無延遲、有無反壓、吞吐怎么樣、系統資源夠不夠等

　　2.3 管理層面

　　可視化管理平臺，如全鏈路血緣、數據表/任務、質量覆蓋率等基本信息

　　一體化數倉全流程規范，如數據建模規范、數據質量規范、數據治理規范、存儲選型規范等

　　三、項目架構

　　項目架構如下圖，該系統主要包括：原始數據 -> 數據開發 -> 數據服務 -> 數據質量 -> 數據管理等模塊，提供實時數據秒級處理、數據服務分鐘級部署的能力，供實時數據開發同學、后端數據服務開發使用。

　　不同數據來源的數據首先經過標準化ETL組件進行數據標準化，并經過流量轉發工具進行數據預處理，使用流批融合工具以及業務數據處理模塊進行分層分域建設，生產好的數據使用數據服務模塊直接將數據進行數據api部署，最終供業務應用使用，整個鏈路會有對應的質量和運維保障體系。

　　四、項目建設

　　4.1 數據開發

　　該模塊主要包含數據預處理工具、數據開發方案選型。

　　4.1.1 流量轉發工具

　　由于入口多、流量大，主要存在如下問題：

　　同維度的數據來源、解析方式可能有多種

　　使用到的埋點數據占總量的比例大約20%，全量消費資源浪費嚴重，且每個下游都會重復操作

　　新增埋點后，數據處理需要開發介入(極端情況下涉及到全部使用方)

　　如下圖，流量轉發工具，具備動態接入多個數據源，并且做簡單的數據處理，并且將有效數據進行標準化后寫入下游，可解決上述問題。

　　4.1.2 業務數據處理方案演進

　　方案1-離在線數據簡單融合

　　背景

　　由于最開始的時候業務需求比較單一，如計算用戶歷史的實時訂單量、聚合用戶歷史購買過的景點信息等。這類簡單需求可以抽象成離線數據和實時數據簡單聚合，如數值型的加減乘除、字符型的append、去重匯總等。

　　解決方案

　　如下圖，其中數據提供方：提供標準化的T+1和實時數據接入;數據處理：T+1與實時數據融合;一致性校驗;動態規則引擎處理等;數據存儲：支持聚合數據水平擴展;標簽映射等。

　　方案2 - 支持SQL

　　背景

　　雖然說方案1有如下優勢：

　　分層簡單，時效性強

　　規則配置響應迅速，可承接大量的復雜UDF

　　規則引擎等處理

　　兼容整個java生態

　　但是也存在明顯劣勢：

　　BI SQL開發人員基本無法介入、強依賴開發

　　SQL很多場景，使用java開發成本高，穩定性差

　　沒有有效的數據分層

　　過程數據基本不可用，如果要保存過程數據，需要重復計算，浪費計算資源

　　解決方案

　　如下圖，kafka承載數據分層功能，Flink SQL的計算引擎，OLAP承載數據存儲、分層查詢，完成典型的數倉系統分層建設。

　　但是由于kafka和olap存儲引擎是兩個個體，可能會存在數據不一致的情況，比如kafka正常，數據庫異常，會導致中間分層的數據異常，但是最終結果正常。為了解決上述問題，如下圖，采用了傳統數據庫使用的binlog模式開發，kafka數據強依賴DB的數據變更，這樣最終結果強依賴中間分層結果，還是不能避免組件big導致的數據不一致問題，但大部分場景已經基本可用。

　　方案3

　　背景

　　雖然說方案2有如下優勢：

　　SQL化

　　天然分層查詢

　　但是也存在明顯劣勢：

　　數據不一致的問題

　　binlog在insert的時候沒啥問題，但是更新和刪除不好搞，而且更新的時候要做大量的去重操作，sql很不友好

　　長時間數據聚合，部分算子如max、min等flink狀態大，容易不穩定

　　還要考慮kafka數據亂序，導致的數據覆蓋問題

　　解決方案

　　如下圖借用存儲引擎的計算能力，kafka的binlog只是作為數據計算的觸發邏輯，直接使用Flink UDF進行直連DB查詢。

　　優勢：

　　SQL化

　　天然分層查詢

　　數據一致

　　FLink狀態小

　　可支持長時間的持久化數據聚合

　　無需關心binlog亂序、update等帶來的問題

　　劣勢：

　　并發扛不起來，強依賴olap引擎性能，我們在數據源的時候會window限流，或者水平擴容db

　　sink時與回撤流結合被打斷，比如：group by，其實就是無腦的upsert，udf的聚合沒法替代flink原生的聚合

　　各個方案都有適用場景，需要根據不同的業務場景和延遲需求，進行方案選型。目前我們86%的場景都可以使用方案3進行承接，并且由于Flink 1.16各類離在線一體的特性加持，后期基本可覆蓋全部場景。

　　4.2 數據服務

　　該模塊提供了數據同步 -> 數據存儲 -> 數據查詢 -> 數據服務等能力，簡單場景可實現分鐘級的數據服務部署能力，可節約90%的開發工時。實現了離線數據DQC強依賴、工程側DQC異常兜底、客戶端->接口級別的資源隔離/限流/熔斷、全鏈路血緣(客戶端->服務端->表->hive表->hive血緣)管理等，提供了按需進行各類性能要求接口部署和運維保障能力。

　　架構如下：

　　4.3 數據質量

　　該模塊主要分為數據內容質量和數據任務質量。

　　4.3.1 數據內容

　　正確性/及時性/穩定性

　　該部分又分為數據操作變化、數據內容一致性、數據讀取一致性、數據正確性/及時性等。如下圖所示，數據變更：如果異常，可將數據打入公司的hickwall告警中臺，并根據預警規則告警。數據內容：會有定時任務，執行用戶自定義的sql語句，將數據寫入告警中臺，可實現秒級和分鐘級預警。

　　讀取一致性

　　如下圖，數據讀取時，如果存在跨表的聯合查詢，如果其中某張表出現問題，大多數情況下不會展示錯誤數據，只會展示歷史上的正確數據，待該表恢復后才會全部展示。

　　如：外露需要將表1和表2的數據做除法(表1/表2)，如果表2數據生產異常，最近2小時沒數據，在外露給用戶時，業務需要只是展示2小時之前的數據，異常數據給出前端異常提醒 參照flink watermark的概念，將正確數據對其進行外顯。

　　離在線一致性

　　關于離線和實時的數據一致性。如下圖，我們采用較為簡單的方法，直接將實時數據同步至hudi，并且使用hudi進行離線和實時數據對比，打入告警中臺。

　　圖片

　　4.3.2 數據任務

　　上游任務

　　依托公司自定義預警埋點、告警中臺、計算平臺等工具，可將上游的消息隊列是否延遲、量是否異常等關鍵指標進行監控預警。

　　當前任務

　　可將數據處理任務的吞吐、延遲、反壓、資源等關鍵指標進行監控預警，避免數據任務長時間異常

　　4.4 數據管理

　　該模塊可將數據處理、質量等各模塊進行串聯，提供可視化的管理平臺，如：表血緣/基本信息、DQC配置、任務狀態、監控等。

　　下圖為各數據表上下游數據生產任務血緣關系。

　　下圖為數據表質量信息詳情

　　下圖為各類UDF表的基本信息匯總

　　五、展望

　　目前該系統基本上已經能承接團隊絕大多數數據開發需求，后期我們會在可靠性、穩定性、易用性等層面繼續探索，如完善整個數據治理體系、建設自動數據恢復工具、排障運維智能組件、服務分析一體化探索等。