馬蜂窩資料倉儲的架構、模型與應用實踐

最近幾年，資料中臺概念的熱度一直不減。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 設計流程

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

1. 需求調研：收集和理解業務方需求，就特定需求的口徑達成統一，在對需求中涉及到的業務系統或系統模組所承擔的功能進行梳理後進行表欄位級分析，並對資料進行驗證，確保現有資料能夠支援業務需求。

2. 模型設計：根據需求和業務調研結果對模型進行初步歸類，選擇合適的主題域進行模型存放；確定主題後進入資料模型的設計階段，邏輯模型設計過程要考慮匯流排結構構建、模型規範定義等關鍵問題；物理模型設計以邏輯模型為基礎，兼顧儲存效能等因素對邏輯模型做的物理化的過程，是邏輯模型的最終物理實現.物理模型在一般情況下與邏輯模型保持一致，模型設計完成後需要進入評審與 Mapping 設計。

3. 模型開發：就是對模型計算指令碼的程式碼實現過程，其中包含了資料對映、指令碼實現、測試驗證等開發過程。單元測試完成後需要通知業務方一起對模型資料進行業務驗證，對驗證問題做收集，返回驗證模型設計的合理性。

4. 模型上線：完成驗證後的模型就可以線上上生產環境進行部署。上線後需要為模型配置監控，及時掌握為業務提供資料服務的狀況。我們還將模型的實體和屬性說明文件釋出給倉庫資料的使用者，使模型得到更好地應用。

3.4 主題分類

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

以馬蜂窩訂單交易模型的建設為例，基於業務生產匯流排的設計是常見的模式，即首先調研訂單交易的完整過程，定位過程中的關鍵節點，確認各節點上發生的核心事實資訊。模型是資料的載體，我們要做的就是透過模型（或者說模型體系）歸納生產匯流排中各個節點發生的事實資訊。

訂單生產匯流排：

如上圖所示，我們需要提煉各節點的核心資訊，為了避免遺漏關鍵資訊，一般情況下抽象認為節點的參與人、發生時間、發生事件、發生協議屬於節點的核心資訊，需要重點獲取。以下單節點為例，參與人包括下單使用者、服務商家、平臺運營人員等；發生時間包括使用者的下單時間、商家的確認時間等；發生的事件即使用者購買了商品，需要記錄圍繞這一事件產生的相關資訊；發生協議即產生的訂單，訂單金額、約定內容等都是我們需要記錄的協議資訊。

在這樣的思路下，匯流排架構可以在模型中不斷新增各個節點的核心資訊，使模型支撐的應用範圍逐步擴充套件、趨於完善。因此，對業務流程的理解程度將直接影響產出模型的質量。

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

鑑於上述情況，在模型實現過程中，我們不能把各節點不同粒度的資料資訊都堆砌在一起，那樣會產生大量的冗餘資訊，也會使模型本身的定位不清晰，影響使用。因此，需要輸出不同粒度的模型來滿足各類應用需求。例如既會存在訂單粒度的資料模型，也會存在分析各個訂單在不同時間節點狀態資訊的資料模型。

基於維度建模的思路，在模型整合生產匯流排各節點核心資訊之後，會根據這些節點資訊進一步擴充套件常用的分析維度，以減少應用層面頻繁關聯相關分析維度帶來的資源消耗，模型會反正規化冗餘相關維度資訊，以獲取應用層的使用便捷。最終建立一個整合旅遊、交通、酒店等各業務線與各業務節點資訊的馬蜂窩全流程訂單模型。

為提升資料生產力，馬蜂窩資料倉儲建立了一套工具鏈，來實現採集、研發、管理流程的自動化。現階段比較重要的有以下三大工具：

1. 資料同步工具

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

• 從源系統同步資料到資料倉儲 

• 將資料倉儲的資料同步至其他環境

  
  

下面重點介紹從源系統同步資料到資料倉儲。

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

接入時，只需要填寫資料表資訊配置，以及具體的欄位配置資訊，資料就可以自動接入到資料倉儲，形成數倉的 ODS 層資料模型，如下：

我們使用 Airflow 配合自研的任務排程系統，不僅能支援常規的任務排程，還可以支援任務排程系統各類資料重跑，歷史補數等需求。

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

我們設計的「一鍵重跑」功能，可以將相關任務依賴的後置任務全部帶出，並支援選擇性地刪除或虛擬執行任意節點的任務：

• 如果選擇刪除，這該任務之後所依賴的任務均不執行

• 如果選擇虛擬執行，則會忽略（空跑）掉該任務，後置的所有依賴任務還是會正常執行。

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

3. 後設資料管理工具

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

（1）血緣管理

血緣管理可以追溯資料加工整體鏈路，解析表的來龍去脈，用於支撐各類場景，如：

• 支援上游變更對下游影響的分析與調整

• 監控各節點、各鏈路任務執行成本，效率

• 監控資料模型的依賴數量，確認哪些是重點模型

如下是某一個資料模型中的血緣圖，上下游以不同顏色進行呈現：

（2）資料知識管理

透過對技術、業務後設資料進行清晰、詳盡地描述，形成資料知識，給資料人員提供更好的使用嚮導。我們的資料知識主要包括實體說明與屬性說明，具體如下：

當然，數倉工具鏈條中還有非常多工具，例如自動化建模工具，資料質量管理工具，資料開發工具等，都已經得到了很好地實現。

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

幾乎所有的企業都會構建自己的指標平臺，每個企業建立的標準都不一樣。在這個過程中會遇到指標繁多、定義不清楚、查詢緩慢等問題。為儘量避免這些問題，指標平臺在設計時需要遵循幾大原則：

1. 指標定義標準，清晰，容易理解，且不存在二義性，分類明確

2. 指標生產過程簡單、透明、可配置化

3. 指標查詢效率需要滿足快速響應

4. 指標許可權管理靈活可控

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

其中：

1. 資料倉儲是指標資料的來源，所有指標目前都是透過資料倉儲統一加工的。

2. 指標管理包括指標建立與指標後設資料管理：數倉負責生產並建立最核心、最基礎的指標；其他人員可以基於這些指標，按照規則進行指標的派生；後設資料管理記錄指標的具體來源路徑，說明指標的資料來源是數倉表，或者是 Kylin，MySQL 或 ES。

3. 指標字典對外呈現指標的定義、口徑、說明等，保證指標的透明化及可解釋性。

4. 資料服務接受指標的查詢請求，針對不同場景判斷查詢的成本，選擇最優鏈路進行指標查詢，並返回指標查詢的結果。

5. 多維查詢將可以提供查詢服務的指標與維度透過介面呈現，使用者可以基於維度選擇指標或基於指標選擇維度，查詢具體需要的資料。

6. 許可權管理貫徹始終，可以支援表級、指標級、維值級別的許可權管理。

企業的資料建設需要經歷幾個大的步驟：

• 第一步，業務資料化：顧名思義，一切業務都能透過資料反映，主要指的是將傳統線下流程線上化；

• 第二步，資料智慧化：光有資料還不行，還需要足夠的智慧，如何透過智慧化的資料支撐運營、營銷及各類業務，這是資料中臺當前解決的主要問題；

• 第三步，資料業務化：也就是我們常說的資料驅動業務，資料不能只是資料，資料價值最大化在於可以驅動新的業務創新，帶動企業增長。

目前大部企業目前都停留在第二個階段，因為這一步需要足夠夯實，才能為第三步打好基礎，這也是為什麼各大企業要投入很大成本到大資料平臺、資料倉儲乃至資料中臺的建設中。

馬蜂窩資料中臺的建設才剛剛起步。我們認為，理想的資料中臺需要具備 資料標準化、工具元件化、組織清晰化這三個核心前提。 為了向這一目標邁進，我們將建立統一、標準化的資料倉儲作為當下資料中臺的重點工作之一。

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

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

本文作者：顏博，馬蜂窩資料倉儲研發負責人。

（題圖來源： 網路）