離在線一體化數(shù)倉系統(tǒng)在攜程的落地實(shí)踐

　　本文主要介紹離在線數(shù)據(jù)倉庫建設(shè)在攜程旅游團(tuán)隊(duì)的落地與實(shí)踐，將從業(yè)務(wù)痛點(diǎn)、業(yè)務(wù)目標(biāo)、項(xiàng)目架構(gòu)、項(xiàng)目建設(shè)等維度展開。

　　一、業(yè)務(wù)痛點(diǎn)

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

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

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

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

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

　　實(shí)時表/任務(wù)雜亂、無法管理

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

　　實(shí)時數(shù)據(jù) 質(zhì)量監(jiān)控?zé)o工具

　　實(shí)時任務(wù) 運(yùn)維門檻高 質(zhì)量體系弱

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

　　二、業(yè)務(wù)目標(biāo)

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

　　2.1 人效層面

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

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

　　2.2 質(zhì)量層面

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

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

　　2.3 管理層面

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

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

　　三、項(xiàng)目架構(gòu)

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

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

　　四、項(xiàng)目建設(shè)

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

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

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

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

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

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

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

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

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

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

　　背景

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

　　解決方案

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

　　方案2 - 支持SQL

　　背景

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

　　分層簡單，時效性強(qiáng)

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

　　規(guī)則引擎等處理

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

　　但是也存在明顯劣勢：

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

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

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

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

　　解決方案

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

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

　　解決方案

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

　　優(yōu)勢：

　　SQL化

　　天然分層查詢

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

　　FLink狀態(tài)小

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

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

　　劣勢：

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

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

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

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

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

　　架構(gòu)如下：

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

　　該模塊主要分為數(shù)據(jù)內(nèi)容質(zhì)量和數(shù)據(jù)任務(wù)質(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ù)預(yù)警規(guī)則告警。數(shù)據(jù)內(nèi)容：會有定時任務(wù)，執(zhí)行用戶自定義的sql語句，將數(shù)據(jù)寫入告警中臺，可實(shí)現(xiàn)秒級和分鐘級預(yù)警。

　　讀取一致性

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

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

　　離在線一致性

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

　　圖片

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

　　上游任務(wù)

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

　　當(dāng)前任務(wù)

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

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

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

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

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

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

　　五、展望

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