（馬蜂窩技術原創內容，公眾號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%，
大量用戶的使用，驅動著我們在資料中臺建設的路上不斷前進，如何將新興技術能力應用到資料倉庫的建設，如何以有限的成本高效解決企業在資料建設中面臨的問題，將是馬蜂窩數倉建設一直的思考，
本文作者：顏博，馬蜂窩資料倉庫研發負責人，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/48439.html
標籤：大數據
上一篇：sybase 12.5 執行動態SQL并取得結果，如何處理？
下一篇：MySQL 什么時候建立外鍵？