作者簡介

Chengrui，攜程后端開發(fā)專家，關注實時數(shù)據(jù)處理、AI基礎平臺建設以及數(shù)據(jù)產(chǎn)品等領域。

一、業(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)建設。如下圖：

圖片

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ī)范等

三、項目架構

項目架構如下圖，該系統(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ù)處理模塊進行分層分域建設，生產(chǎn)好的數(shù)據(jù)使用數(shù)據(jù)服務模塊直接將數(shù)據(jù)進行數(shù)據(jù)api部署，最終供業(yè)務應用使用，整個鏈路會有對應的質(zhì)量和運維保障體系。

圖片

四、項目建設

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)分層建設。

圖片

但是由于kafka和olap存儲引擎是兩個個體，可能會存在數(shù)據(jù)不一致的情況，比如kafka正常，數(shù)據(jù)庫異常，會導致中間分層的數(shù)據(jù)異常，但是最終結果正常。為了解決上述問題，如下圖，采用了傳統(tǒng)數(shù)據(jù)庫使用的binlog模式開發(fā)，kafka數(shù)據(jù)強依賴DB的數(shù)據(jù)變更，這樣最終結果強依賴中間分層結果，還是不能避免組件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ù)聚合
• 無需關心binlog亂序、update等帶來的問題

劣勢：

• 并發(fā)扛不起來，強依賴olap引擎性能，我們在數(shù)據(jù)源的時候會window限流，或者水平擴容db
• sink時與回撤流結合被打斷，比如：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血緣）管理等，提供了按需進行各類性能要求接口部署和運維保障能力。

架構如下：

圖片

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ù)對其進行外顯。

離在線一致性

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

圖片

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

上游任務

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

圖片

當前任務

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

圖片

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

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

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

圖片

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

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

五、展望

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