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

　　一、業(yè)務痛點

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

　　實時需求煙囪開發(fā)模式

　　中間數(shù)據(jù)可復用性差

　　離在線數(shù)據(jù)開發(fā)割裂

　　數(shù)據(jù)生產(chǎn)->服務周期長

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

　　實時血緣/基本信息/監(jiān)控等缺失

　　實時數(shù)據(jù) 質(zhì)量監(jiān)控無工具

　　實時任務 運維門檻高 質(zhì)量體系弱

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

　　二、業(yè)務目標

　　圍繞已知業(yè)務痛點，依托于公司現(xiàn)有的計算資源、存儲資源、離線數(shù)倉標準規(guī)范等，我們的目標是在人效、質(zhì)量、管理這幾個層面進行系統(tǒng)建設(shè)。如下圖：

　　2.1 人效層面

　　實現(xiàn)離在線數(shù)據(jù)開發(fā)方案標準化，如標準化數(shù)據(jù)處理、離在線代碼兼容、算力融合等

　　分鐘級數(shù)據(jù)部署，實現(xiàn)BI同學層面的數(shù)據(jù)接口注冊、發(fā)布、調(diào)試等可視化操作

　　2.2 質(zhì)量層面

　　數(shù)據(jù)內(nèi)容DQC，如內(nèi)容對不對、全不全、是否及時、是否離在線一致等

　　數(shù)據(jù)任務預警，如有無延遲、有無反壓、吞吐怎么樣、系統(tǒng)資源夠不夠等

　　2.3 管理層面

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

　　一體化數(shù)倉全流程規(guī)范，如數(shù)據(jù)建模規(guī)范、數(shù)據(jù)質(zhì)量規(guī)范、數(shù)據(jù)治理規(guī)范、存儲選型規(guī)范等

　　三、項目架構(gòu)

　　項目架構(gòu)如下圖，該系統(tǒng)主要包括：原始數(shù)據(jù) -> 數(shù)據(jù)開發(fā) -> 數(shù)據(jù)服務 -> 數(shù)據(jù)質(zhì)量 -> 數(shù)據(jù)管理等模塊，提供實時數(shù)據(jù)秒級處理、數(shù)據(jù)服務分鐘級部署的能力，供實時數(shù)據(jù)開發(fā)同學、后端數(shù)據(jù)服務開發(fā)使用。

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

　　四、項目建設(shè)

　　4.1 數(shù)據(jù)開發(fā)

　　該模塊主要包含數(shù)據(jù)預處理工具、數(shù)據(jù)開發(fā)方案選型。

　　4.1.1 流量轉(zhuǎn)發(fā)工具

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

　　同維度的數(shù)據(jù)來源、解析方式可能有多種

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

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

　　如下圖，流量轉(zhuǎn)發(fā)工具，具備動態(tài)接入多個數(shù)據(jù)源，并且做簡單的數(shù)據(jù)處理，并且將有效數(shù)據(jù)進行標準化后寫入下游，可解決上述問題。

　　4.1.2 業(yè)務數(shù)據(jù)處理方案演進

　　方案1-離在線數(shù)據(jù)簡單融合

　　背景

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

　　解決方案

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

　　方案2 - 支持SQL

　　背景

　　雖然說方案1有如下優(yōu)勢：

　　分層簡單，時效性強

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

　　規(guī)則引擎等處理

　　兼容整個java生態(tài)

　　但是也存在明顯劣勢：

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

　　SQL很多場景，使用java開發(fā)成本高，穩(wěn)定性差

　　沒有有效的數(shù)據(jù)分層

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

　　解決方案

　　如下圖，kafka承載數(shù)據(jù)分層功能，F(xiàn)link SQL的計算引擎，OLAP承載數(shù)據(jù)存儲、分層查詢，完成典型的數(shù)倉系統(tǒng)分層建設(shè)。

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

　　方案3

　　背景

　　雖然說方案2有如下優(yōu)勢：

　　SQL化

　　天然分層查詢

　　但是也存在明顯劣勢：

　　數(shù)據(jù)不一致的問題

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

　　長時間數(shù)據(jù)聚合，部分算子如max、min等flink狀態(tài)大，容易不穩(wěn)定

　　還要考慮kafka數(shù)據(jù)亂序，導致的數(shù)據(jù)覆蓋問題

　　解決方案

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

　　優(yōu)勢：

　　SQL化

　　天然分層查詢

　　數(shù)據(jù)一致

　　FLink狀態(tài)小

　　可支持長時間的持久化數(shù)據(jù)聚合

　　無需關(guān)心binlog亂序、update等帶來的問題

　　劣勢：

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

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

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

　　4.2 數(shù)據(jù)服務

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

　　架構(gòu)如下：

　　4.3 數(shù)據(jù)質(zhì)量

　　該模塊主要分為數(shù)據(jù)內(nèi)容質(zhì)量和數(shù)據(jù)任務質(zhì)量。

　　4.3.1 數(shù)據(jù)內(nèi)容

　　正確性/及時性/穩(wěn)定性

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

　　讀取一致性

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

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

　　離在線一致性

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

　　圖片

　　4.3.2 數(shù)據(jù)任務

　　上游任務

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

　　當前任務

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

　　4.4 數(shù)據(jù)管理

　　該模塊可將數(shù)據(jù)處理、質(zhì)量等各模塊進行串聯(lián)，提供可視化的管理平臺，如：表血緣/基本信息、DQC配置、任務狀態(tài)、監(jiān)控等。

　　下圖為各數(shù)據(jù)表上下游數(shù)據(jù)生產(chǎn)任務血緣關(guān)系。

　　下圖為數(shù)據(jù)表質(zhì)量信息詳情

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

　　五、展望

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