本文主要介紹攜程旅行團隊資料倉儲建設的實施與實踐，將從業務痛點、業務目標、專案架構、專案建設等維度進行。
一、業務痛點
隨著對實時資料需求的不斷增加，離線資料倉儲暴露出的業務痛點越來越多，例如：
煙囪開發模式的實時需求。
中間資料的可重用性較差。
與資料開發分離。
資料生產服務周期長。
實時表任務雜亂無章且難以管理。
缺少實時譜系、基本資訊、監控等。
實時資料：沒有質量監控工具。
實時任務：運維門檻高，質量體系薄弱。
這種典型問題會給我們人類的效率、素質、管理等帶來極大的考驗，亟需乙個系統的平台來解決。
2. 業務目標
圍繞已知業務痛點，依託公司現有的計算資源、儲存資源、離線數倉標準規範等，我們的目標是構建乙個在人力、質量、管理層面的體系。 如下圖所示：
1.人類效率水平
實現資料開發解決方案的標準化，如標準化資料處理、相容性、算力整合等。
分鐘級資料部署，實現BI學生級資料介面註冊、發布、除錯等視覺化操作。
2.質量水平
資料內容DQC，如內容是否正確、不完整、及時、是否符合**等。
資料任務預警，如有無延遲、有無背壓、吞吐量如何、系統資源是否充足等。
3.管理層
視覺化管理平台，如端到端血緣、資料表任務、質量覆蓋率等基礎資訊。
規範一體化資料倉儲的全流程，如資料建模規範、資料質量規範、資料治理規範、儲存選型規範等。
三、專案結構
專案架構如下，系統主要包括：原始資料、資料開發、資料服務、資料質量、資料管理等模組，提供秒級實時資料處理和分鐘級資料服務部署，用於實時資料開發學生和後端資料服務開發。
不同資料的資料首先由標準化的ETL元件進行標準化，資料由流量工具進行預處理，採用流批融合工具和業務資料處理模組進行分層域構建，產生的資料由資料服務模組直接部署進行資料API部署， 最後被業務應用使用，整個環節都會有相應的質量和運維保障體系。
四、專案建設
1.資料開發
本模組主要包括資料預處理工具和資料開發方案選擇。
1）流量**工具
由於入口數量多，人流量大，主要問題如下：
可能有多種方法可以解析同一維度中的資料**;
使用的埋地資料佔總量的20%左右，資源消耗嚴重，每個下游都會重複操作;
新增埋點後，需要對資料處理進行開發和干預（極端情況下，所有使用者都參與其中）;
如下圖所示，流量工具動態接入多個資料來源，資料處理簡單，標準化後將有效資料寫入下游，可以解決上述問題。
2） 業務資料處理解決方案的演變
選項 1 - 簡單融合來自 ** 的資料
背景
剛開始的時候，業務需求比較簡單，比如計算使用者歷史的實時訂單量，彙總使用者歷史購買的景點資訊等。 這些簡單的要求可以抽象為離線資料和實時資料的簡單聚合，如數值加減乘除、字元追加、去重和彙總等。
溶液
如下圖所示，資料提供者提供標準化的T+1和實時資料訪問; 資料處理：T+1和實時資料融合; 一致性檢查; 動態規則引擎處理等; 資料儲存：聚合資料的水平擴充套件; 標籤對映等。
方案 2 - 支援 SQL
背景
儘管選項 1 具有以下優點：
分層簡單且對時間敏感。
規則配置速度快，可以處理大量複雜的 UDF
規則引擎等
相容整個 J**A 生態系統。
但也有明顯的缺點：
BI SQL開發人員基本上無法干預並依賴開發。
在很多SQL場景下，使用J**A的開發成本高，穩定性差。
沒有有效的資料分層。
過程資料基本不可用，如果要儲存過程資料，需要重複計算，浪費計算資源。
溶液
如下圖所示，Kafka 承載資料分層功能，Flink SQL 計算引擎，OLAP 承載資料儲存和分層查詢，完成了資料倉儲系統的典型分層構建。
但是，由於 Kafka 和 OLAP 儲存引擎是兩個實體，因此可能會存在資料不一致的情況，例如 Kafka 正常，資料庫異常，這會導致中間分層資料異常，但最終結果是正常的。 為了解決上述問題，如下圖所示，採用傳統資料庫使用的binlog模式，Kafka資料很大程度上依賴於DB的資料變化，因此最終結果強烈依賴於中間的分層結果，無法避免元件BIG導致的資料不一致， 但大多數場景基本上都可用。
方案 3
背景
但是，選項 2 具有以下優點：
SQL格式。 自然分層查詢。
但也有明顯的缺點：
資料不一致。
插入binlog時沒有問題，但是更新刪除不容易，更新時需要大量的去重操作，SQL非常不友好。
對於長期的資料聚合，一些運算元，如max和min，具有較大的flink狀態，容易出現不穩定。
還要考慮 Kafka 資料亂序導致的資料覆蓋問題。
溶液
如下圖所示，借用儲存引擎的算力，以 Kafka 的二進位日誌作為資料計算的觸發邏輯，使用 Flink udf 查詢資料庫進行直接連線。
優勢：
SQL格式。 自然分層查詢。
資料是一致的。 flink 狀態很小。
它可以支援長期持久的資料聚合。
您無需擔心無序的二進位日誌和更新引起的問題。
弊：
併發是不能承載的，很大程度上取決於OLAP引擎的效能，所以當資料來源在資料來源中時，我們會限制視窗的速率或水平擴容資料庫。
sink 和 drawdown 流的組合被打斷了，比如：group by，其實就是乙個無腦的upsert，UDF的聚合無法取代Flink的原生聚合;
每個解決方案都有自己的場景，您需要根據不同的業務場景和時延需求來選擇解決方案。 目前，我們 86% 的場景可以使用解決方案 3 進行，並且由於 Flink 116、在各類整合特性的加持下，基本可以覆蓋後期的所有場景。
2.資料服務
該模組提供資料同步、資料儲存、資料查詢、資料服務等能力，可在簡單場景下實現分鐘級資料服務部署能力，節省90%的開發工時。 實現離線資料DQC強依賴、工程端DQC異常、客戶端>介面層資源隔離、限流、斷路器、全鏈路沿襲（客戶端-伺服器端表Hive沿襲）管理等，提供部署各種效能需求介面的能力，按需提供運維保障能力。
架構如下：
3.資料質量
該模組主要分為資料內容質量和資料任務質量。
1） 資料內容
正確性、及時性、穩定性
這部分又分為資料操作變更、資料內容一致性、資料讀取一致性、資料正確性和及時性等。 如下圖所示，如果資料異常，可以將資料錄入公司的HickWall報警中心，並根據預警規則生成報警。 資料內容：會有定時任務，執行使用者自定義的SQL語句，將資料寫入告警平台，可實現秒級、分鐘級預警。
讀取一致性
如下圖所示，如果在資料讀取過程中存在跨表聯合查詢，如果其中乙個表出現問題，大多數情況下不會顯示錯誤的資料，只會顯示歷史記錄中的正確資料，恢復表後會顯示所有資料。
例如，如果表2中的資料異常，最近2小時內沒有資料，則當資料暴露給使用者時，業務需要展示2小時前的資料，異常資料會給出前端異常提醒。
一致性
關於離線和實時資料一致性。 如下圖所示，我們用一種簡單的方法，直接將實時資料同步到Hudi，使用Hudi對照離線和實時資料進入告警平台。
2） 資料任務
上游任務
依託公司定製的預警埋點、告警中臺、計算平台等工具，對上游訊息佇列是否延遲、音量是否異常等關鍵指標進行監控預警。
當前任務
您可以對資料處理任務的吞吐量、時延、反壓、資源等關鍵指標進行監控和預警，防止資料處理任務出現長期異常。
4.資料管理
該模組可以串聯資料處理、質量等模組，並提供視覺化管理平台，如：表沿襲、DQC配置、任務狀態、監控等基本資訊。
下圖顯示了每個資料表中上下游資料生產任務的血緣關係。
資料表的質量資訊詳情如下圖所示。
下圖總結了各種UDF表的基本資訊。
第5章 展望
目前系統基本能夠承接團隊大部分資料開發需求，後期我們還會在可靠性、穩定性、易用性等方面繼續探索，如完善整個資料治理體系、構建資料自動恢復工具、排查運維智慧型元件、探索服務分析一體化等。
作者丨成瑞**丨***攜程科技 （ID： 攜程科技） DBAPLUS社群歡迎技術人員投稿，投稿郵箱editor@dbapluscn