馬蜂窩數據倉庫的架構、模型與應用實踐

（馬蜂窩技術原創內容，公衆號ID：mfwtech）

1、馬蜂窩數據倉庫與數據中臺

最近幾年，數據中臺概念的熱度一直不減。2018 年起，馬蜂窩也開始了本身的數據中臺探索之路。

數據中臺究竟是什麼？要不要建？和數據倉庫有什麼本質的區別？相信不少企業都在關注這些問題。

我認爲數據中臺的概念很是接近傳統數據倉庫+大數據平臺的結合體。它是在企業的數據建設經歷了數據中心、數據倉庫等積累以後，藉助平臺化的思路，將數據更好地進行整合與統一，以組件化的方式實現靈活的數據加工與應用，以更清晰的數據職能組織應對業務的快速變化，以服務的方式更好地釋放數據價值的一種方式。

因此，數據中臺更多的是體現一種管理思路和架構組織上的變革。在這樣的思想下，咱們結合自身業務特色建設了馬蜂窩的數據中臺，核心架構以下：

在中臺建設以前，馬蜂窩已經創建了本身的大數據平臺，並積累了一些通用、組件化的工具，這些能夠支撐數據中臺的快速搭建。做爲中颱的另外一大核心部分，馬蜂窩數據倉庫主要承擔數據統一化建設的工做，包括統一數據模型，統一指標體系等。下面介紹馬蜂窩在數據倉庫建設方面的具體實踐。

2、數據倉庫核心架構

馬蜂窩數據倉庫遵循標準的三層架構，對數據分層的定位主要採起維度模型設計，不會對數據進行抽象打散處理，更多注重業務過程數據整合。現有數倉主要以離線爲主，總體架構以下：

如圖所示，共分爲 3 層：業務數據層、公共數據層與應用數據層，每層定位、目標以及建設原則各不相同。

（1）業務數據層：包含 STG（數據緩衝層）與 ODS（操做數據層）兩層，這兩層數據結構與業務數據幾乎一致。

• STG：也叫數據準備區，定位是緩存來自 DB 抽取、消息、日誌解析落地的臨時數據，結構與業務系統保持一致；負責對垃圾數據、不規範數據進行清洗轉換；該層只爲 ODS 層服務；
• ODS：操做數據層定位於業務明細數據保留區，負責保留數據接入時點後歷史變動數據，數據原則上全量保留。模型設計依據業務表數據變動特性採起拉鍊、流水錶兩種形式。

（2）公共數據層：細分爲 DWD（明細數據層）、DWS（彙總數據層）、DIM（公共維度層） 三層，主要用於加工存放整合後的明細業務過程數據，以及通過輕度或重度彙總粒度公共維度指標數據。公共數據層做爲倉庫核心層，定位於業務視角，提煉出對數據倉庫具備共性的數據訪問、統計需求，從而構建面向支持應用、提供共享數據訪問服務的公共數據。

• DWD：這一層是整合後的業務過程明細數據，負責各業務場景垂直與水平數據整合、經常使用公共維度冗餘加工，以及明細業務標籤信息加工；
• DWS：彙總數據層按照主題對共性維度指標數據進行輕度、高度聚合；
• DIM：對維度進行統一標準化定義，實現維度信息共享。

（3）應用數據層：DWA 層，主要用於各產品或各業務條線個性化的數據加工，例如商業化產品數據、搜索推薦，風控等。

3、數據模型設計

3.1 方法選擇

數據模型是對現實世界數據特徵的抽象，數據模型的設計方法就是對數據進行概括和歸納的方法。目前業界主要的模型設計方法論有兩種，一是數據倉庫之父 Bill Inmon 提出的範式建模方法，又叫 ER 建模，主張站在企業角度自上而下進行數據模型構建；二是 Ralph Kimball 大師倡導的維度建模方法，主張從業務需求出發自下而上構建數據模型。

大數據環境下，業務系統數據體系龐雜，數據結構多樣、變動頻繁，而且須要快速響應各類複雜的業務需求，以上兩種傳統的理論都已沒法知足互聯網數倉需求。在此背景下，馬蜂窩數據倉庫採起了「以需求驅動爲主、數據驅動爲輔」的混合模型設計方式，來根據不一樣的數據層次選擇模型。主要從如下四個方面綜合考慮：

1. 面向主題：採用範式模型理論中的主題劃分方法對業務數據進行分類。

2. 一致性保證：採用維度模型理論中的總線結構思想，創建統一的一致性維度表和一致性事實表來保證一致性。

3. 數據質量保證：不管範式建模仍是維度建模都很是重視數據質量問題，綜合使用兩個理論中的方法保證數據質量。

4. 效率保證：合理採起維度退化、變化維、增長冗餘等方法，保證數據的計算和查詢效率。

其中，ODS 選擇保持貼源的範式模型，不作進一步模型抽象，只是從節省存儲角度考慮，對該層採起拉鍊處理。DWD 與 DWS 基於對構建成本、性能，易用性角度的考慮，主要採起維度模型和一些寬表模型。寬表模型的本質是基於維度模型的擴展，對整個業務以及全節點信息進行垂直與水平方式整合；同時採用退化維度的方式，將不一樣維度的度量放入數據表的不一樣列中，實現業務全流程視圖的構建，來提高寬表模型的易用性、查詢效率，且易於模型的擴展。

• 水平整合：水平整合就是將同一業務多數據源的數據整合到一個模型中，若是多數據源業務數據存在交集，則須要按照預設的業務規則選取一份保留，避免整合後的業務數據交叉。例如商品數據若是未進行主數據管理，不一樣業務線的商品信息就會散落在各業務系統表中，沒法知足企業級的數據分析需求，這時就須要將這些商品數據按照業務主題進行水平整合。
• 垂直整合：一次完整的業務流轉一般要經歷多個環節，各節點信息產生的時點不一樣、儲存的數據表不一樣。垂直整合就是將同一業務中各關鍵節點信息整合至業務全流程寬表模型中。馬蜂窩訂單交易模型的構建就採用了這種方式，下文將進行詳細介紹。

3.2 設計目標

馬蜂窩數據倉庫在模型設計上以準確性、易用性、及時性爲設計目標，以知足業務人員對數據的多樣需求。

• 準確性：數據質量管控要在建模過程當中落地，爲數據準確性保駕護航。
• 易用性：兼顧模型的可擴展性和可理解性。
• 及時性：充分考慮模型的使用效率，提供方便快捷的數據查詢和數據計算服務。

3.3 設計流程

馬蜂窩數倉模型設計的總體流程涉及需求調研、模型設計、開發測試、模型上線四個主要環節，且規範設計了每一個階段的輸出與輸入文檔。

1. 需求調研：收集和理解業務方需求，就特定需求的口徑達成統一，在對需求中涉及到的業務系統或系統模塊所承擔的功能進行梳理後進行表字段級分析，並對數據進行驗證，確保現有數據可以支持業務需求。
2. 模型設計：根據需求和業務調研結果對模型進行初步歸類，選擇合適的主題域進行模型存放；肯定主題後進入數據模型的設計階段，邏輯模型設計過程要考慮總線結構構建、模型規範定義等關鍵問題；物理模型設計以邏輯模型爲基礎，兼顧存儲性能等因素對邏輯模型作的物理化的過程，是邏輯模型的最終物理實現.物理模型在通常狀況下與邏輯模型保持一致，模型設計完成後須要進入評審與 Mapping 設計。
3. 模型開發：就是對模型計算腳本的代碼實現過程，其中包含了數據映射、腳本實現、測試驗證等開發過程。單元測試完成後須要通知業務方一塊兒對模型數據進行業務驗證，對驗證問題作收集，返回驗證模型設計的合理性。
4. 模型上線：完成驗證後的模型就能夠在線上生產環境進行部署。上線後須要爲模型配置監控，及時掌握爲業務提供數據服務的情況。咱們還將模型的實體和屬性說明文檔發佈給倉庫數據的使用者，使模型獲得更好地應用。

3.4 主題分類

基於對目前各個部門和業務系統的梳理，馬蜂窩數據倉庫共設計了 4 個大數據域(交易、流量、內容、參與人)，細分爲 11 個主題：

以馬蜂窩訂單交易模型的建設爲例，基於業務生產總線的設計是常見的模式，即首先調研訂單交易的完整過程，定位過程當中的關鍵節點，確認各節點上發生的核心事實信息。模型是數據的載體，咱們要作的就是經過模型（或者說模型體系）概括生產總線中各個節點發生的事實信息。

訂單生產總線：

如上圖所示，咱們須要提煉各節點的核心信息，爲了不遺漏關鍵信息，通常狀況下抽象認爲節點的參與人、發生時間、發生事件、發生協議屬於節點的核心信息，須要重點獲取。如下單節點爲例，參與人包括下單用戶、服務商家、平臺運營人員等；發生時間包括用戶的下單時間、商家的確認時間等；發生的事件即用戶購買了商品，須要記錄圍繞這一事件產生的相關信息；發生協議即產生的訂單，訂單金額、約定內容等都是咱們須要記錄的協議信息。

在這樣的思路下，總線架構能夠在模型中不斷添加各個節點的核心信息，使模型支撐的應用範圍逐步擴展、趨於完善。所以，對業務流程的理解程度將直接影響產出模型的質量。

涉及的業務節點越多，業務流程也就越複雜。從數據的角度看，這些業務過程會產生兩種基本的場景形態，即數據的拆分和匯聚。隨着流程的推動，前一節點的原子業務單位在新節點中可能須要拆分出更多信息，或者參與到新節點的多向流程。一樣，也可能發生數據的匯聚。以某個訂單爲例，下單節點數據是訂單粒度的，而到支付節點就發生了數據拆分。數據的拆分、匯聚伴隨着總線的各節點，可能會一直髮散下去。

鑑於上述狀況，在模型實現過程當中，咱們不能把各節點不一樣粒度的數據信息都堆砌在一塊兒，那樣會產生大量的冗餘信息，也會使模型自己的定位不清晰，影響使用。所以，須要輸出不一樣粒度的模型來知足各種應用需求。例如既會存在訂單粒度的數據模型，也會存在分析各個訂單在不一樣時間節點狀態信息的數據模型。

基於維度建模的思路，在模型整合生產總線各節點核心信息以後，會根據這些節點信息進一步擴展經常使用的分析維度，以減小應用層面頻繁關聯相關分析維度帶來的資源消耗，模型會反範式冗餘相關維度信息，以獲取應用層的使用便捷。最終創建一個整合旅遊、交通、酒店等各業務線與各業務節點信息的馬蜂窩全流程訂單模型。

4、數據倉庫工具鏈建設

爲提高數據生產力，馬蜂窩數據倉庫創建了一套工具鏈，來實現採集、研發、管理流程的自動化。現階段比較重要的有如下三大工具：

1. 數據同步工具

同步工具主要解決兩個問題：

• 從源系統同步數據到數據倉庫 
• 將數據倉庫的數據同步至其餘環境

下面重點介紹從源系統同步數據到數據倉庫。

馬蜂窩的數據同步設計支撐靈活的數據接入方式，能夠選擇抽取方式以及加工方式。抽取方式主要包括增量抽取或者全量抽取，加工方式面向數據的存儲方式，是須要對數據進行拉鍊式保存，或者以流水日誌的方式進行存儲。

接入時，只須要填寫數據表信息配置以及具體的字段配置信息，數據就能夠自動接入到數據倉庫，造成數倉的 ODS 層數據模型，以下：

2. 任務調度平臺

咱們使用 Airflow 配合自研的任務調度系統，不只能支持常規的任務調度，還能夠支持任務調度系統各種數據重跑，歷史補數等需求。

別小看數據重跑、歷史補數，這兩項功能是在選擇調度工具中重要的參考項。作數據的人都清楚，在實際數據處理過程當中會面臨諸多的數據口徑變化、數據異常等，須要進行數據重跑、刷新、補數等操做。

咱們設計的「一鍵重跑」功能，能夠將相關任務依賴的後置任務所有帶出，並支持選擇性地刪除或虛擬執行任意節點的任務：

• 若是選擇刪除，這該任務以後所依賴的任務均不執行
• 若是選擇虛擬執行，則會忽略（空跑）掉該任務，後置的全部依賴任務仍是會正常執行。

以下是基於某一個任務重跑下游全部任務所列出的關係圖，選中具體的執行節點，就能夠執行忽略或者刪除。

3. 元數據管理工具

元數據範疇包括技術元數據、業務元數據、管理元數據，在概念上不作過多闡述了。元數據管理在數據建設起着舉足輕重的做用，這部分在數倉應用中主要有 2 個點：

（1）血緣管理

血緣管理能夠追溯數據加工總體鏈路，解析表的前因後果，用於支撐各種場景，如：

• 支持上游變動對下游影響的分析與調整
• 監控各節點、各鏈路任務運行成本，效率
• 監控數據模型的依賴數量，確認哪些是重點模型

以下是某一個數據模型中的血緣圖，上下游以不一樣顏色進行呈現：

（2）數據知識管理

經過對技術、業務元數據進行清晰、詳盡地描述，造成數據知識，給數據人員提供更好的使用嚮導。咱們的數據知識主要包括實體說明與屬性說明，具體以下：

固然，數倉工具鏈條中還有很是多工具，例如自動化建模工具，數據質量管理工具，數據開發工具等，都已經獲得了很好地實現。

5、數倉應用——指標平臺

有了合理的數倉架構、工具鏈條支撐數據研發，接下來，就要考慮如何把產出的數據對外賦能。下面以馬蜂窩數據應用利器-指標平臺，進行簡單介紹。

幾乎全部的企業都會構建本身的指標平臺，每一個企業創建的標準都不同。在這個過程當中會遇到指標繁多、定義不清楚、查詢緩慢等問題。爲儘可能避免這些問題，指標平臺在設計時須要遵循幾大原則：

1. 指標定義標準，清晰，容易理解，且不存在二義性，分類明確
2. 指標生產過程簡單、透明、可配置化
3. 指標查詢效率須要知足快速響應
4. 指標權限管理靈活可控

基於以上原則，馬蜂窩的指標平臺按照精細化的設計進行打造，指標平臺組成架構以下圖：

其中：

1. 數據倉庫是指標數據的來源，全部指標目前都是經過數據倉庫統一加工的
2. 指標管理包括指標建立與指標元數據管理：數倉負責生產並建立最核心、最基礎的指標；其餘人員能夠基於這些指標，按照規則進行指標的派生；元數據管理記錄指標的具體來源路徑，說明指標的數據來源是數倉表，或者是 Kylin，MySQL 或 ES
3. 指標字典對外呈現指標的定義、口徑、說明等，保證指標的透明化及可解釋性
4. 數據服務接受指標的查詢請求，針對不一樣場景判斷查詢的成本，選擇最優鏈路進行指標查詢，並返回指標查詢的結果
5. 多維查詢將能夠提供查詢服務的指標與維度經過界面呈現，用戶能夠基於維度選擇指標或基於指標選擇維度，查詢具體須要的數據
6. 權限管理貫徹始終，能夠支持表級、指標級、維值級別的權限管理

6、總結

企業的數據建設須要經歷幾個大的步驟：

• 第一步，業務數據化：顧名思義，一切業務都能經過數據反映，主要指的是將傳統線下流程線上化；
• 第二步，數據智能化：光有數據還不行，還須要足夠的智能，如何經過智能化的數據支撐運營、營銷及各種業務，這是數據中臺當前解決的主要問題；
• 第三步，數據業務化：也就是咱們常說的數據驅動業務，數據不能只是數據，數據價值最大化在於能夠驅動新的業務創新，帶動企業增加。

目前大部企業目前都停留在第二個階段，由於這一步須要足夠夯實，才能爲第三步打好基礎，這也是爲何各大企業要投入很大成本到大數據平臺、數據倉庫乃至數據中臺的建設中。

馬蜂窩數據中臺的建設纔剛剛起步。咱們認爲，理想的數據中臺須要具有數據標準化、工具組件化、組織清晰化這三個核心前提。爲了向這一目標邁進，咱們將創建統1、標準化的數據倉庫做爲當下數據中臺的重點工做之一。

數據來源於業務，最終也將應用於業務。只有對數據足夠重視，與業務充分銜接，才能實現數據價值的最大化。在馬蜂窩，從管理層，到公司研發、產品、運營、銷售等各角色，對數據很是重視，數據產品的使用人數佔公司員工比例高達 75%。

大量用戶的使用，驅動着咱們在數據中臺建設的路上不斷前進。如何將新興技術能力應用到數據倉庫的建設，如何以有限的成本高效解決企業在數據建設中面臨的問題，將是馬蜂窩數倉建設一直的思考。

本文做者：顏博，馬蜂窩數據倉庫研發負責人。