阿里巴巴大數據實踐：OneData模型實施介紹

如何從具體的需求或項目轉換爲可實施的解決方案，如何進行需求分析、架構設計、詳細模型設計等，則是模型實施過程當中討論的內容。本節先簡單介紹業界經常使用的模型實施過程，而後重點講解阿里巴巴OneData模型設計理論及實施過程。

1．業界經常使用的模型實施過程

**Kimball模型實施過程
**
Kimball維度建模主要探討需求分析、高層模型、詳細模型和模型審查整個過程。

構建維度模型通常要經歷三個階段：第一個階段是高層設計時期，定義業務過程維度模型的範圍，提供每種星形模式的技術和功能描述；第二個階段是詳細模型設計時期，對每一個星形模型添加屬性和度量信息；第三個階段是進行模型的審查、再設計和驗證等工做，第四個階段是產生詳細設計文檔，提交ETL設計和開發。

高層模型：高層模型設計階段的直接產出目標是建立高層維度模型圖，它是對業務過程當中的維表和事實表的圖形描述。肯定維表建立初始屬性列表，爲每一個事實表建立提議度量。

詳細模型：詳細的維度建模過程是爲高層模型填補缺失的信息，解決設計問題，並不斷測試模型可否知足業務需求，確保模型的完備性。肯定每一個維表的屬性和每一個事實表的度量，並肯定信息來源的位置、定義，肯定屬性和度量如何填入模型的初步業務規則。

模型審查、再設計和驗證：本階段主要召集相關人員進行模型的審查和驗證，根據審查結果對詳細維度進行再設計。

提交ETL設計和開發：最後，完成模型詳細設計文檔，提交ETL開發人員，進入ETL設計和開發階段，由ETL人員完成物理模型的設計和開發。

上述內容主要引用自Ralph Kimball等的The Data Warehouse Lifecycle Toolkit，具體細節請參考原著做。

Inmon模型實施過程

Inmon對數據模型的定位是：扮演着通往數據倉庫其餘部分的智能路線圖的角色。因爲數據倉庫的建設不是一蹴而就的，爲了協調不一樣人員的工做以及適應不一樣類型的用戶，很是有必要創建一個路線圖——數據模型，描述數據倉庫各部分是如何結合在一塊兒的。

Inmon將模型劃分爲三個層次，分別是ERD（Entity Relationship Diagram，實體關係圖）層、DIS（Data Item Set，數據項集）層和物理層（Physical Model，物理模型）。

ERD層是數據模型的最高層，該層描述了公司業務中的實體或主題域以及它們之間的關係；DIS層是中間層，該層描述了數據模型中的關鍵字、屬性以及細節數據之間的關係；物理層是數據建模的最底層，該層描述了數據模型的物理特性。

Inmon對於構建數據倉庫模型建議採用螺旋式開發方法，採用迭代方式完成屢次需求。但須要採用統一的ERD模型，纔可以將每次迭代的結果整合在一塊兒。ERD模型是高度抽象的數據模型，描述了企業完整的數據。而每次迭代則是完成ERD模型的子集，經過DIS和物理數據模型實現。

上述內容主要引用自Inmon的Building the Data Warehouse，具體細節請參考原著做。

其餘模型實施過程

在實踐中常常會用到以下數據倉庫模型層次的劃分，和Kimball、Inmon的模型實施理論有必定的相通性，但不涉及具體的模型表達。

業務建模，生成業務模型，主要解決業務層面的分解和程序化。

領域建模，生成領域模型，主要是對業務模型進行抽象處理，生成領域概念模型。

邏輯建模，生成邏輯模型，主要是將領域模型的概念實體以及實體之間的關係進行數據庫層次的邏輯化。

物理建模，生成物理模型，主要解決邏輯模型針對不一樣關係數據庫的物理化以及性能等一些具體的技術問題。

2．OneData實施過程

本節重點講解怎麼使用OneData這套體系和相配套的工具實施大數據系統的模型建設，在講解中會以阿里巴巴的具體業務進行說明。

指導方針

首先，在建設大數據數據倉庫時，要進行充分的業務調研和需求分析。這是數據倉庫建設的基石，業務調研和需求分析作得是否充分直接決定了數據倉庫建設是否成功。其次，進行數據整體架構設計，主要是根據數據域對數據進行劃分；按照維度建模理論，構建總線矩陣、抽象出業務過程和維度。再次，對報表需求進行抽象整理出相關指標體系，使用OneData工具完成指標規範定義和模型設計。最後，就是代碼研發和運維。本文將會重點講解物理模型設計以前（含）步驟的內容。

實施工做流

數據調研——業務調研：整個阿里集團涉及的業務涵蓋電商、數字娛樂、導航（高德）、移動互聯網服務等領域。各個領域又涵蓋多個業務線，如電商領域就涵蓋了C類（淘寶、天貓、天貓國際）與B類（阿里巴巴中文站、國際站、速賣通）業務。數據倉庫是要涵蓋全部業務領域，仍是各個業務領域獨自建設，業務領域內的業務線也一樣面臨着這個問題。因此要構建大數據數據倉庫，就須要瞭解各個業務領域、業務線的業務有什麼共同點和不一樣點，以及各個業務線能夠細分爲哪幾個業務模塊，每一個業務模塊具體的業務流程又是怎樣的。業務調研是否充分，將會直接決定數據倉庫建設是否成功。

在阿里巴巴，通常各個業務領域獨自建設數據倉庫，業務領域內的業務線因爲業務類似、業務相關性較大，進行統一集中建設。

數據調研——需求調研：能夠想象一下，在沒有考慮分析師、業務運營人員的數據需求的狀況下，根據業務調研建設的數據倉庫無疑等於閉門造車。瞭解了業務系統的業務後並不表明就能夠進行實施了，此刻要作的就是收集數據使用者的需求，能夠去找分析師、業務運營人員瞭解他們有什麼數據訴求，此時更多的就是報表需求。

需求調研的途徑有兩種：一是根據與分析師、業務運營人員的溝通（郵件、IM）獲知需求；二是對報表系統中現有的報表進行研究分析。經過需求調研分析後，就清楚數據要作成什麼樣的。不少時候，都是由具體的數據需求驅動數據倉庫團隊去了解業務系統的業務數據，這二者並無嚴格的前後順序。

舉例：分析師須要瞭解大淘寶（淘寶、天貓、天貓國際）一級類目的成交金額。當獲知這個需求後，咱們要分析根據什麼（維度）彙總，以及彙總什麼（度量），這裏類目是維度，金額是度量；明細數據和彙總數據應該怎樣設計？這是一個公用的報表嗎？是須要沉澱到彙總表裏面，仍是在報表工具中進行彙總？
架構設計——數據域劃分：數據域是指面向業務分析，將業務過程或者維度進行抽象的集合。業務過程能夠歸納爲一個個不可拆分的行爲事件，以下單、支付、退款。爲保障整個體系的生命力，數據域須要抽象提煉，而且長期維護和更新，但不輕易變更。在劃分數據域時，既能涵蓋當前全部的業務需求，又能在新業務進入時無影響地被包含進已有的數據域中或者擴展新的數據域。

架構設計——構建總線矩陣：在進行充分的業務調研和需求調研後，就要構建總線矩陣了。須要作兩件事情：明確每一個數據域下有哪些業務過程；業務過程與哪些維度相關，並定義每一個數據域下的業務過程和維度。

規範定義：規範定義主要定義指標體系，包括原子指標、修飾詞、時間週期和派生指標。

模型設計：模型設計主要包括維度及屬性的規範定義，維表、明細事實表和彙總事實表的模型設計。相關實踐詳解請參考後續章節。

總結：OneData的實施過程是一個高度迭代和動態的過程，通常採用螺旋式實施方法。在整體架構設計完成以後，開始根據數據域進行迭代式模型設計和評審。在架構設計、規範定義和模型設計等模型實施過程當中，都會引入評審機制，以確保模型實施過程的正確性。
注：本書中出現的部分專有名詞、專業術語、產品名稱、軟件項目名稱、工具名稱等，是淘寶（中國）軟件有限公司內部項目的慣用詞語，如與第三方名稱雷同，實屬巧合。

原文連接本文爲阿里雲原創內容，未經容許不得轉載。