阿里巴巴大數據之路-數據模型篇

一、大數據領域建模綜述

1、典型的數據倉庫建模方法論

• ER模型：數據倉庫之父Bill Inmon提出從全企業的高度設計一個3NF模型，用ER模型來描述企業業務。數據倉庫中的3NF與OLTP系統中的3NF的區別在於數據倉庫是站在企業角度面向主題的抽象，而不是針對某個具體業務流程的實體對象關係的抽象。其具有幾個特點--需要全面了解企業業務和數據，實施周期長，對建模人員的能力要求非常高。ER模型的典型代表是Teradata公司發布的金融業務模型FS-LDM。
• 維度模型：數據倉庫領域的Ralph Kimball大師所倡導的，維度建模從分析決策的需求出發構建模型，為分析需求服務，因此它重點關注用戶如何更快速地完成需求分析，同時具有較好的大規模複雜查詢的響應性能。其典型的代表是星興模型，以及在一些特殊場景下使用的雪花模型。

2、阿里巴巴數據模型實踐綜述

• 第一個階段：只有兩層--ODS+DSS
• 第二個階段：ODL（操作數據層）+BDL（基礎數據層）+IDL（介面數據層）+ADL（應用數據層）；ODL和源系統保持一致，BDL希望引入ER模型構建一致的基礎數據模型，IDL基於維度模型方法構建集市層，ADL完成應用的個性化和基於展現需求的數據組裝。實際情況是，ER模型遲遲不能產出，因此得到一個經驗--在不太成熟、快速變化的業務面前，構建ER模型的風險非常大，不太適合去構建ER模型。
• 第三個階段：選擇以Kimball的維度建模為核心理念的模型方法論，同時對其進行一定的升級和擴展，構建阿里巴巴集團的公共層模型數據架構體系。

阿里巴巴數據公共層建設的指導方法是一套統一化的集團數據整合及管理的方法體系（OneData），其包括一致性的指標定義體系、模型設計方法體系以及配套工具。

二、阿里巴巴數據整合及管理體系

1、目標：可管理、可追溯、可規避重複建設。

2、規範定義：以維度建模作為理論基礎，構建匯流排矩陣，劃分和定義數據域、業務過程、維度、度量/原子指標、修飾類型、修飾詞、時間周期、派生指標。

• 指標定義：事務型指標--指對業務活動進行衡量的指標，例如新發商品數、新增會員數等。存量型指標--指對實體對象某些狀態的統計，例如商品總數、會員總數。複合型指標--包括比率型、比例型、變化量型、變化率型等。
• 指標命名規範：需要對原子指標、派生指標進行命名規範。

3、模型層次

• 模型設計原則：高內聚低耦合、核心模型與擴展模型分離、公共處理邏輯下沉及單一、成本與性能平衡、數據可回滾、一致性、命名清晰可理解。
• 模型實施方法：Kimball模型實施方法、OneData模型實施方法（見下圖）。

三、維度設計

1、基本概念：在維度建模中，將度量成為「事實」，將環境稱為「維度」。代理鍵和自然鍵--例如，對於前台應用系統來說，商品ID是代理鍵；而對於數據倉庫系統來說，商品ID則屬於自然鍵。

2、規範化和反規範化：當屬性層次被實例化為一系列維度，而不是單一維度時被稱為雪花模型。大多數OLTP系統模型採用雪花模型這種規範化操作。採用雪花模型，除了可以節約一部分存儲外，對於OLAP系統來說沒有其他效用，而現階段存儲的成本很低，所以在實際應用中幾乎總是使用維表的空間來換取簡明性和查詢性能。

3、維度整合

• 命名規範的統一
• 欄位類型的統一
• 公共代碼及代碼值的統一
• 業務含義相同的表的統一：通常有3種方式--主從表（將多個表都有的欄位放在主表中，而從屬信息分別放在各自的從表中）、直接合併、不合併，具體可以根據源表重合度及差異等狀況確定。
• 垂直整合：不同的來源表包含相同的數據集，比如淘寶會員在源系統中有多個表，包括會員基礎信息表、會員擴展信息表等，可以盡量垂直整合到會員維度模型中。
• 水平整合：不同的來源表包含不同的數據集，不同子集之間無交叉，也可以存在部分交叉，如果要整合則可以採用各子集的自然鍵作為聯合主鍵的方式來實現。

4、維度拆分

• 水平拆分：比如商品表，可以分為淘寶商品、天貓商品、飛豬商品等，而飛豬航旅商品與普通的淘系商品有相同的地方，也有不同的地方，那麼如何處理呢？方案1是將維度的不同分類實例化為不同的維度，同時在主維度中保存公共屬性；方案2是維度單一維度，包含所有可能的屬性。可以根據維度不同分類的屬性差異情況、及業務的關聯程度確定採用哪種方案。
• 垂直拆分：出於擴展性、產出時間、易用性等方面的考慮，設計主從維度，主維表存放穩定、產出時間早、熱度高的屬性，從維表存放變化較快、產出時間晚、熱度低的屬性，比如商品主維表在每日的1：30左右產出，而商品擴展維度在每日的3：00左右產出。

5、維度變化

• 緩慢變化維：有三種處理方式--1、重寫維度值，不保留歷史數據；2、插入新的維度行，保留歷史數據，這種方式不能將變化前後記錄的事實歸一化為變化前或變化後的維度；3、添加維度列，記錄新舊維度值，可以解決方案2的不足。
• 阿里巴巴內部處理緩慢變化維的方法是採用快照維表方式。

6、特殊維度

• 遞歸維度：可以直接採用遞歸模型支撐遞歸維度，但很多工具不支持遞歸SQL，且遞歸SQL成本高，所以可以在維度模型中對層次結構進行扁平化處理。大部分時候，扁平化設計足夠滿足需求了。
• 多值維度：常見的有三種處理方式--1、降低事實表的粒度，避免出現多值；2、採用多欄位來處理多值維度（如果值的數量固定）；3、採用橋接表來表達一對多關係（複雜成本高需慎重）。

四、事實表設計

1、事實表特性：作為度量業務過程的事實，有可加性、半可加性（一般是時間維度不可加）、不可加性。

2、事實表類型

• 事務事實表：用來描述業務過程，跟蹤空間或時間上某點的度量事件，保存的是最原子的數據，也稱為原子事實表。
• 周期快照事實表：以具有規律性、可預見的時間間隔記錄事實，時間間隔如每天、每月、每年等。一般針對長生命周期的對象，比如用戶。
• 累計快照事實表：用來描述過程開始和結束之間的關鍵步驟事件，覆蓋過程的整個生命周期，通常具有多個日期欄位來記錄關鍵時間點，當過程隨著生命周期不斷變化時，記錄也會隨著過程的變化而被修改。一般針對短生命周期的對象，比如交易過程。

3、事實表設計原則

• 儘可能包含所有與業務過程相關的事實
• 只選擇與業務過程相關的事實
• 分解不可加性事實為可加事實
• 在選擇維度和事實之前必須先聲明粒度
• 在同一個事實表中不能有多個不同粒度的事實
• 事實的單位要保持一致
• 對事實的null值要處理
• 使用退化維度提高事實表的易用性
• 事實完整性（儘可能多的獲取業務過程相關的度量）、事實一致性（有一些事實可以提前計算好確保下游使用的一致性）、事實可加性。

4、事務事實表

• 單事務事實表：針對每個業務過程設計一個事實表。
• 多事務事實表：多事務事實表在設計時有兩種方法進行事實的處理--1、不同業務過程的事實使用不同的事實欄位進行存放；2、不同業務過程的事實使用同一個事實欄位進行存放，但增加一個業務過程標籤。
• 多事務事實表的選擇：當不同業務過程的度量比較相似、差異不大時，可以採用第二種多事務事實表的設計方式，使用同一個欄位來表示度量數據，但存在一個問題--在同一個周期內會有多條記錄存在。當不同業務過程的度量差異較大時，可以選擇第一種多事務事實表的設計方式。
• 例子：淘寶交易事務事實表如下

5、周期快照事實表的注意事項

• 事務事實表與周期快照事實表往往是成對設計的，互相補充，以滿足更多的下游統計分析需求。
• 附加事實：一般在設計周期快照事實表時會附加一些上一個採樣周期的狀態度量。

6、累計快照事實表的物理實現

• 第一種方式是全量表，一般按日期分區，每天分區存儲昨天的全量+當天的增量合併的結果。適用於全量數據比較少的情況。
• 第二種方式是全量表的變化形式，針對事實表數據量很大的情況，根據業務實體從產生到消亡的最大時間間隔來測算，比如交易訂單以200天計算最大間隔。
• 第三種方式是以業務實體的結束時間分區，每天的分區存放當天結束的數據，設計一個時間非常大的分區，比如3000-12-31，存放截止當前未結束的數據，每天將當天結束的數據歸檔至當天分區中。

7、三種事實表的比較