（馬蜂窩技術原創內容，公衆號ID：mfwtech）
一、馬蜂窩數據倉庫與數據中臺
最近幾年，數據中臺概念的熱度一直不減。2018 年起，馬蜂窩也開始了自己的數據中臺探索之路。
數據中臺到底是什麼？要不要建？和數據倉庫有什麼本質的區別？相信很多企業都在關注這些問題。
我認爲數據中臺的概念非常接近傳統數據倉庫+大數據平臺的結合體。它是在企業的數據建設經歷了數據中心、數據倉庫等積累之後，藉助平臺化的思路，將數據更好地進行整合與統一，以組件化的方式實現靈活的數據加工與應用，以更清晰的數據職能組織應對業務的快速變化，以服務的方式更好地釋放數據價值的一種方式。
所以，數據中臺更多的是體現一種管理思路和架構組織上的變革。在這樣的思想下，我們結合自身業務特點建設了馬蜂窩的數據中臺，核心架構如下：
在中臺建設之前，馬蜂窩已經建立了自己的大數據平臺，並積累了一些通用、組件化的工具，這些可以支撐數據中臺的快速搭建。作爲中颱的另一大核心部分，馬蜂窩數據倉庫主要承擔數據統一化建設的工作，包括統一數據模型，統一指標體系等。下面介紹馬蜂窩在數據倉庫建設方面的具體實踐。
二、數據倉庫核心架構
馬蜂窩數據倉庫遵循標準的三層架構，對數據分層的定位主要採取維度模型設計，不會對數據進行抽象打散處理，更多注重業務過程數據整合。現有數倉主要以離線爲主，整體架構如下：
如圖所示，共分爲 3 層：業務數據層、公共數據層與應用數據層，每層定位、目標以及建設原則各不相同。
（1）業務數據層：包含 STG（數據緩衝層）與 ODS（操作數據層）兩層，這兩層數據結構與業務數據幾乎一致。
- STG：也叫數據準備區，定位是緩存來自 DB 抽取、消息、日誌解析落地的臨時數據，結構與業務系統保持一致；負責對垃圾數據、不規範數據進行清洗轉換；該層只爲 ODS 層服務；
- ODS：操作數據層定位於業務明細數據保留區，負責保留數據接入時點後歷史變更數據，數據原則上全量保留。模型設計依據業務表數據變更特性採取拉鍊、流水錶兩種形式。
（2）公共數據層：細分爲 DWD（明細數據層）、DWS（彙總數據層）、DIM（公共維度層） 三層，主要用於加工存放整合後的明細業務過程數據，以及經過輕度或重度彙總粒度公共維度指標數據。公共數據層作爲倉庫核心層，定位於業務視角，提煉出對數據倉庫具有共性的數據訪問、統計需求，從而構建面向支持應用、提供共享數據訪問服務的公共數據。
- DWD：這一層是整合後的業務過程明細數據，負責各業務場景垂直與水平數據整合、常用公共維度冗餘加工，以及明細業務標籤信息加工；
- DWS：彙總數據層按照主題對共性維度指標數據進行輕度、高度聚合；
- DIM：對維度進行統一標準化定義，實現維度信息共享。
（3）應用數據層：DWA 層，主要用於各產品或各業務條線個性化的數據加工，例如商業化產品數據、搜索推薦，風控等。
三、數據模型設計
3.1 方法選擇
數據模型是對現實世界數據特徵的抽象，數據模型的設計方法就是對數據進行歸納和概括的方法。目前業界主要的模型設計方法論有兩種，一是數據倉庫之父 Bill Inmon 提出的範式建模方法，又叫 ER 建模，主張站在企業角度自上而下進行數據模型構建；二是 Ralph Kimball 大師倡導的維度建模方法，主張從業務需求出發自下而上構建數據模型。
大數據環境下，業務系統數據體系龐雜，數據結構多樣、變更頻繁，並且需要快速響應各種複雜的業務需求，以上兩種傳統的理論都已無法滿足互聯網數倉需求。在此背景下，馬蜂窩數據倉庫採取了「以需求驅動爲主、數據驅動爲輔」的混合模型設計方式，來根據不同的數據層次選擇模型。主要從以下四個方面綜合考慮：
1. 面向主題：採用範式模型理論中的主題劃分方法對業務數據進行分類。
2. 一致性保證：採用維度模型理論中的總線結構思想，建立統一的一致性維度表和一致性事實表來保證一致性。
3. 數據質量保證：無論範式建模還是維度建模都非常重視數據質量問題，綜合使用兩個理論中的方法保證數據質量。
4. 效率保證：合理採取維度退化、變化維、增加冗餘等方法，保證數據的計算和查詢效率。
其中，ODS 選擇保持貼源的範式模型，不做進一步模型抽象，只是從節省存儲角度考慮，對該層採取拉鍊處理。DWD 與 DWS 基於對構建成本、性能，易用性角度的考慮，主要採取維度模型和一些寬表模型。寬表模型的本質是基於維度模型的擴展，對整個業務以及全節點信息進行垂直與水平方式整合；同時採用退化維度的方式，將不同維度的度量放入數據表的不同列中，實現業務全流程視圖的構建，來提升寬表模型的易用性、查詢效率，且易於模型的擴展。
- 水平整合：水平整合就是將同一業務多數據源的數據整合到一個模型中，如果多數據源業務數據存在交集，則需要按照預設的業務規則選取一份保留，避免整合後的業務數據交叉。例如商品數據如果未進行主數據管理，不同業務線的商品信息就會散落在各業務系統表中，無法滿足企業級的數據分析需求，這時就需要將這些商品數據按照業務主題進行水平整合。
- 垂直整合：一次完整的業務流轉通常要經歷多個環節，各節點信息產生的時點不同、儲存的數據表不同。垂直整合就是將同一業務中各關鍵節點信息整合至業務全流程寬表模型中。馬蜂窩訂單交易模型的構建就採用了這種方式，下文將進行詳細介紹。
3.2 設計目標
馬蜂窩數據倉庫在模型設計上以準確性、易用性、及時性爲設計目標，以滿足業務人員對數據的多樣需求。
- 準確性：數據質量管控要在建模過程中落地，爲數據準確性保駕護航。
- 易用性：兼顧模型的可擴展性和可理解性。
- 及時性：充分考慮模型的使用效率，提供方便快捷的數據查詢和數據計算服務。
3.3 設計流程
馬蜂窩數倉模型設計的整體流程涉及需求調研、模型設計、開發測試、模型上線四個主要環節，且規範設計了每個階段的輸出與輸入文檔。
- 需求調研：收集和理解業務方需求，就特定需求的口徑達成統一，在對需求中涉及到的業務系統或系統模塊所承擔的功能進行梳理後進行表字段級分析，並對數據進行驗證，確保現有數據能夠支持業務需求。
- 模型設計：根據需求和業務調研結果對模型進行初步歸類，選擇合適的主題域進行模型存放；確定主題後進入數據模型的設計階段，邏輯模型設計過程要考慮總線結構構建、模型規範定義等關鍵問題；物理模型設計以邏輯模型爲基礎，兼顧存儲性能等因素對邏輯模型做的物理化的過程，是邏輯模型的最終物理實現.物理模型在一般情況下與邏輯模型保持一致，模型設計完成後需要進入評審與 Mapping 設計。
- 模型開發：就是對模型計算腳本的代碼實現過程，其中包含了數據映射、腳本實現、測試驗證等開發過程。單元測試完成後需要通知業務方一起對模型數據進行業務驗證，對驗證問題做收集，返回驗證模型設計的合理性。
- 模型上線：完成驗證後的模型就可以在線上生產環境進行部署。上線後需要爲模型配置監控，及時掌握爲業務提供數據服務的狀況。我們還將模型的實體和屬性說明文檔發佈給倉庫數據的使用者，使模型得到更好地應用。
3.4 主題分類
基於對目前各個部門和業務系統的梳理，馬蜂窩數據倉庫共設計了 4 個大數據域(交易、流量、內容、參與人)，細分爲 11 個主題：
以馬蜂窩訂單交易模型的建設爲例，基於業務生產總線的設計是常見的模式，即首先調研訂單交易的完整過程，定位過程中的關鍵節點，確認各節點上發生的核心事實信息。模型是數據的載體，我們要做的就是通過模型（或者說模型體系）歸納生產總線中各個節點發生的事實信息。
訂單生產總線：
如上圖所示，我們需要提煉各節點的核心信息，爲了避免遺漏關鍵信息，一般情況下抽象認爲節點的參與人、發生時間、發生事件、發生協議屬於節點的核心信息，需要重點獲取。以下單節點爲例，參與人包括下單用戶、服務商家、平臺運營人員等；發生時間包括用戶的下單時間、商家的確認時間等；發生的事件即用戶購買了商品，需要記錄圍繞這一事件產生的相關信息；發生協議即產生的訂單，訂單金額、約定內容等都是我們需要記錄的協議信息。
在這樣的思路下，總線架構可以在模型中不斷添加各個節點的核心信息，使模型支撐的應用範圍逐步擴展、趨於完善。因此，對業務流程的理解程度將直接影響產出模型的質量。
涉及的業務節點越多，業務流程也就越複雜。從數據的角度看，這些業務過程會產生兩種基本的場景形態，即數據的拆分和匯聚。隨着流程的推進，前一節點的原子業務單位在新節點中可能需要拆分出更多信息，或者參與到新節點的多向流程。同樣，也可能發生數據的匯聚。以某個訂單爲例，下單節點數據是訂單粒度的，而到支付節點就發生了數據拆分。數據的拆分、匯聚伴隨着總線的各節點，可能會一直髮散下去。
鑑於上述情況，在模型實現過程中，我們不能把各節點不同粒度的數據信息都堆砌在一起，那樣會產生大量的冗餘信息，也會使模型本身的定位不清晰，影響使用。因此，需要輸出不同粒度的模型來滿足各類應用需求。例如既會存在訂單粒度的數據模型，也會存在分析各個訂單在不同時間節點狀態信息的數據模型。
基於維度建模的思路，在模型整合生產總線各節點核心信息之後，會根據這些節點信息進一步擴展常用的分析維度，以減少應用層面頻繁關聯相關分析維度帶來的資源消耗，模型會反範式冗餘相關維度信息，以獲取應用層的使用便捷。最終建立一個整合旅遊、交通、酒店等各業務線與各業務節點信息的馬蜂窩全流程訂單模型。
四、數據倉庫工具鏈建設
爲提升數據生產力，馬蜂窩數據倉庫建立了一套工具鏈，來實現採集、研發、管理流程的自動化。現階段比較重要的有以下三大工具：
1. 數據同步工具
同步工具主要解決兩個問題：
- 從源系統同步數據到數據倉庫
- 將數據倉庫的數據同步至其他環境
下面重點介紹從源系統同步數據到數據倉庫。
馬蜂窩的數據同步設計支撐靈活的數據接入方式，可以選擇抽取方式以及加工方式。抽取方式主要包括增量抽取或者全量抽取，加工方式面向數據的存儲方式，是需要對數據進行拉鍊式保存，或者以流水日誌的方式進行存儲。
接入時，只需要填寫數據表信息配置以及具體的字段配置信息，數據就可以自動接入到數據倉庫，形成數倉的 ODS 層數據模型，如下：
2. 任務調度平臺
我們使用 Airflow 配合自研的任務調度系統，不僅能支持常規的任務調度，還可以支持任務調度系統各類數據重跑，歷史補數等需求。
別小看數據重跑、歷史補數，這兩項功能是在選擇調度工具中重要的參考項。做數據的人都清楚，在實際數據處理過程中會面臨諸多的數據口徑變化、數據異常等，需要進行數據重跑、刷新、補數等操作。
我們設計的「一鍵重跑」功能，可以將相關任務依賴的後置任務全部帶出，並支持選擇性地刪除或虛擬執行任意節點的任務：
- 如果選擇刪除，這該任務之後所依賴的任務均不執行
- 如果選擇虛擬執行，則會忽略（空跑）掉該任務，後置的所有依賴任務還是會正常執行。
如下是基於某一個任務重跑下游所有任務所列出的關係圖，選中具體的執行節點，就可以執行忽略或者刪除。
3. 元數據管理工具
元數據範疇包括技術元數據、業務元數據、管理元數據，在概念上不做過多闡述了。元數據管理在數據建設起着舉足輕重的作用，這部分在數倉應用中主要有 2 個點：
（1）血緣管理
血緣管理可以追溯數據加工整體鏈路，解析表的來龍去脈，用於支撐各類場景，如：
- 支持上游變更對下游影響的分析與調整
- 監控各節點、各鏈路任務運行成本，效率
- 監控數據模型的依賴數量，確認哪些是重點模型
如下是某一個數據模型中的血緣圖，上下游以不同顏色進行呈現：
（2）數據知識管理
通過對技術、業務元數據進行清晰、詳盡地描述，形成數據知識，給數據人員提供更好的使用嚮導。我們的數據知識主要包括實體說明與屬性說明，具體如下：
當然，數倉工具鏈條中還有非常多工具，例如自動化建模工具，數據質量管理工具，數據開發工具等，都已經得到了很好地實現。
五、數倉應用——指標平臺
有了合理的數倉架構、工具鏈條支撐數據研發，接下來，就要考慮如何把產出的數據對外賦能。下面以馬蜂窩數據應用利器-指標平臺，進行簡單介紹。
幾乎所有的企業都會構建自己的指標平臺，每個企業建立的標準都不一樣。在這個過程中會遇到指標繁多、定義不清楚、查詢緩慢等問題。爲儘量避免這些問題，指標平臺在設計時需要遵循幾大原則：
- 指標定義標準，清晰，容易理解，且不存在二義性，分類明確
- 指標生產過程簡單、透明、可配置化
- 指標查詢效率需要滿足快速響應
- 指標權限管理靈活可控
基於以上原則，馬蜂窩的指標平臺按照精細化的設計進行打造，指標平臺組成架構如下圖：
其中：
- 數據倉庫是指標數據的來源，所有指標目前都是通過數據倉庫統一加工的
- 指標管理包括指標創建與指標元數據管理：數倉負責生產並創建最核心、最基礎的指標；其他人員可以基於這些指標，按照規則進行指標的派生；元數據管理記錄指標的具體來源路徑，說明指標的數據來源是數倉表，或者是 Kylin，MySQL 或 ES
- 指標字典對外呈現指標的定義、口徑、說明等，保證指標的透明化及可解釋性
- 數據服務接受指標的查詢請求，針對不同場景判斷查詢的成本，選擇最優鏈路進行指標查詢，並返回指標查詢的結果
- 多維查詢將可以提供查詢服務的指標與維度通過界面呈現，用戶可以基於維度選擇指標或基於指標選擇維度，查詢具體需要的數據
- 權限管理貫徹始終，可以支持表級、指標級、維值級別的權限管理
六、總結
企業的數據建設需要經歷幾個大的步驟：
- 第一步，業務數據化：顧名思義，一切業務都能通過數據反映，主要指的是將傳統線下流程線上化；
- 第二步，數據智能化：光有數據還不行，還需要足夠的智能，如何通過智能化的數據支撐運營、營銷及各類業務，這是數據中臺當前解決的主要問題；
- 第三步，數據業務化：也就是我們常說的數據驅動業務，數據不能只是數據，數據價值最大化在於可以驅動新的業務創新，帶動企業增長。
目前大部企業目前都停留在第二個階段，因爲這一步需要足夠夯實，才能爲第三步打好基礎，這也是爲什麼各大企業要投入很大成本到大數據平臺、數據倉庫乃至數據中臺的建設中。
馬蜂窩數據中臺的建設纔剛剛起步。我們認爲，理想的數據中臺需要具備數據標準化、工具組件化、組織清晰化這三個核心前提。爲了向這一目標邁進，我們將建立統一、標準化的數據倉庫作爲當下數據中臺的重點工作之一。
數據來源於業務，最終也將應用於業務。只有對數據足夠重視，與業務充分銜接，才能實現數據價值的最大化。在馬蜂窩，從管理層，到公司研發、產品、運營、銷售等各角色，對數據非常重視，數據產品的使用人數佔公司員工比例高達 75%。
大量用戶的使用，驅動着我們在數據中臺建設的路上不斷前進。如何將新興技術能力應用到數據倉庫的建設，如何以有限的成本高效解決企業在數據建設中面臨的問題，將是馬蜂窩數倉建設一直的思考。
本文作者：顏博，馬蜂窩數據倉庫研發負責人。
