連載7：阿裡巴巴大資料實踐：OneData模型實施介紹

前言：

-更多關于數智化轉型、資料中台内容請加入

阿裡雲資料中台交流群—數智俱樂部 和關注官方微信公總号（文末掃描二維碼或 點此加入 ）

-阿裡雲資料中台官網 https://dp.alibaba.com/index

來源：數智化轉型俱樂部

如何從具體的需求或項目轉換為可實施的解決方案，如何進行需求分析、架構設計、詳細模型設計等，則是模型實施過程中讨論的内容。本節先簡單介紹業界常用的模型實施過程，然後重點講解阿裡巴巴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的實施過程是一個高度疊代和動态的過程，一般采用螺旋式實施方法。在總體架構設計完成之後，開始根據資料域進行疊代式模型設計和評審。在架構設計、規範定義和模型設計等模型實施過程中，都會引入評審機制，以確定模型實施過程的正确性。

注：本書中出現的部分專有名詞、專業術語、産品名稱、軟體項目名稱、工具名稱等，是淘寶（中國）軟體有限公司内部項目的慣用詞語，如與第三方名稱雷同，實屬巧合。

節選自《大資料之路：阿裡巴巴大資料實踐》已受版權保護，未經授權不得轉載

連載1：阿裡巴巴大資料實踐—資料開發平台>> 連載2：阿裡巴巴大資料實踐—實時技術>> 連載3：阿裡巴巴大資料實踐—資料服務>> 連載4：阿裡巴巴大資料實踐—資料模組化綜述 連載5：阿裡巴巴大資料實踐—阿裡巴巴的資料模型實踐綜述>>

資料中台是企業數智化的新基建，阿裡巴巴認為資料中台是集方法論、工具、組織于一體的，“快”、“準”、“全”、“統”、“通”的智能大資料體系。目前正通過阿裡雲資料中台解決方案對外輸出，包括

零售

、

金融 網際網路 政務

等領域，其中核心産品有：

• Dataphin，一站式、智能化的資料建構及管理平台 ；
• Quick BI，随時随地 智能決策
• Quick Audience，全方位洞察、全域營銷、智能增長
• Quick A+， 跨多端全域應用體驗分析及洞察的一站式資料化營運平台

官方站點：

資料中台官網

https://dp.alibaba.com