?數據倉庫：詳解維度建模之事實表

摘要：

本文主要講述事實表和維度表建模技巧，每個數據倉庫都包含一個或者多個事實數據表。其中可能包含業務銷售數據，如現金登記事務所產生的數據，通常包含大量的行。事實數據表的主要特點是包含數字數據（事實），并...

每個數據倉庫都包含一個或者多個事實數據表。其中可能包含業務銷售數據，如現金登記事務所產生的數據，通常包含大量的行。事實數據表的主要特點是包含數字數據（事實），并且這些數字信息可以匯總，以提供有關單位作為歷史的數據，每個事實數據表包含一個由多個部分組成的索引，該索引包含作為外鍵的相關性維度表的主鍵，而維度表包含事實記錄的特性。

事實表基礎

1、事實表特征

事實表作為數倉維度建模的核心，緊緊圍繞著業務過程來設計，通過獲取描述業務過程的度量來表達業務過程，包含了引用的維度和業務過程有關的度量。事實表中一條記錄所表達的業務細節程度被稱為粒度(業務中的細節程度)。通常粒度可以通過兩種方式來表達：一種是維度屬性組合所表示的細節程度，另一種是所表示的具體業務含義。

作為度量業務過程的事實（事實表屬性），一般為整型或浮點型的十進制數值，有可加性、半可加性和不可加性三種類型：

可加性事實?是指可以按照與事實表關聯的任意維度進行匯總。
?

半可加性事實?只能按照特定維度匯總，不能對所有維度匯總。
?

不可加事實?不具備可加性，比如比率型事實。對于不可加性事實可分解為可加的組件來實現聚集。

2、有事實的事實表

有事實表分為三種類型 ：?事務事實表、周期快照事實表和累積快照事實表。

3、無事實的事實表

無事實的事實表可以用來跟蹤事件的發生。例如，在給定的某一天中發生的學生參加課程的事件，可能沒有可記錄的數字化事實，但該事實行帶有一個包含日期、學生、教師、地點、課程等定義良好的外鍵。利用無事實的事實表可以按各種維度計數上報這個事件。

事實表設計規則

盡可能包含所有與業務過程相關的事實；
?

只選擇與業務過程相關的事實；
?

分解不可加性事實為可加的組件；比如訂單的優惠率，應該分解為訂單原價金額與訂單優惠金額
?

在選擇維度和事實之前必須先聲明粒度；
?

在同一個事實表中不能有多種不同粒度的事實；粒度的聲明是事實表設計中不可忽視的重要一步，粒度用于確定事實表中一行所表示業務的細節層次，決定了維度模型的擴展性，在選擇維度和事實之前必須先聲明粒度，且每個維度和事實必須與所定義的粒度保持一致
?

在同一個事實表中不能有多種不同粒度的事實；
?

事實的單位要保持一致；
?

對事實的 null 值要處理；在數據庫中null值對常用的大于或小于等SQL不生效，建議使用零值填充
?

使用退化維度提高事實表的易用性；目的主要是為了減少下游用戶使用時關聯多個表的操作。直接通過退化維度實現對事實表的過濾查詢、控制聚合層次、排序數據以及定義主從關系等。

事實表設計方法

Kimball的四步維度建模方法：選擇業務過程、聲明粒度、確定維度、確定事實。

Step 1:選擇業務過程及確定事實表類型。

在明確了業務需求以后，接下來需要進行詳細的需求分析，對業務的整個生命周期進行分析，明確關鍵的業務步驟，從而選擇與需求有關的業務過程。(業務過程通常使用行為動詞表示業務執行的活動)

Step 2:聲明粒度 。

粒度的聲明是事實表建模非常重要的一步，意味著精確定義事實表的每一行所表示的業務含義，粒度傳遞的是與事實表度量有關的細節層次。明確的粒度能確保對事實表中行的意思的理解不會產生混淆，保證所有的事實按照同樣的細節層次記錄。

Step 3 :確定維度 。

完成粒度聲明以后，也就意味著確定了主鍵，對應的維度組合以及相關的維度字段就可以確定了，應該選擇能夠描述清楚業務過程所處的環境的維度信息。

Step 4 : 確定事實 。

事實可以通過回答“過程的度量是什么”來確定。應該選擇與業務過程有關的所有事實，且事實的粒度要與所聲明的事實表的粒度一致。事實有可加性、半可加性、非可加性三種類型 ， 需要將不可加性事實分解為可加的組件。

Step 5:冗余維度 。

冗余維度是在kimball維度建模方法基礎上新增的步驟。主要是因為在大數據的事實表模型設計中，需要考慮更多的是提高下游用戶的使用效率，降低數據獲取的復雜性，減少關聯的表數量。所以通常事實表中會冗余方便下游用戶使用的常用維度，以實現對事實表的過濾查詢、控制聚合層次、排序數據以及定義主從關系等操作。

有事實的事實表

有事實表分為三種類型 ：?事務事實表、周期快照事實表和累積快照事實表。

1、事務事實表

單事務事實表，針對于每個業務過程設計一個事實表，方便每個業務過程進行獨立分析研究。

優點：更方便跟蹤業務流程細節數據，針對特殊的業務分析場景比較方便和靈活，數據處理上也更加靈活;

弊端：數倉中需要管理太多的事實表，同時跟蹤業務流轉不夠直觀

多事務事實表，將不同的事實放到同一個事實表中，即同一個事實表包含不同的業務過程。多事務事實表在設計時有兩種方法進行事實的處理：

一是不同業務過程的事實使用不同的事實字段進行存放：

二是不同業務過程的事實使用同一個事實字段進行存放，但增加一個業務過程標簽。

優點：能夠更直觀的跟蹤業務流轉和當前狀態，流程事實集中，方便大部分的通用分析應用場景，由于和業務側的數據模型設計思路一致，也是目前最常用的事實表設計;

弊端：細節數據跟蹤不到位，特殊場景的分析不夠靈活;

兩種表的設計區別在于對業務流程的拆分思路不同，具體選擇事實表的構建思路，需要根據實際的業務確定，一般建議兩者結合。

父子事實的處理方式，通過分攤父訂單的金額將所有業務過程的度量全部帶進購物網站交易事務事實表中，包括下單數量、商品價格、子訂單折扣、下單分攤比例、父訂單支付金額、父訂單支付郵費、父訂單折扣、子訂單下單金額、子訂單下單有效金額、支付分攤比例、子訂單支付金額等，將父子事實同時冗余到事務表中。

設計準則

事實完整性

事實表包含與其描述的過程有關的所有事實，即盡可能多地獲取所有的度量。
?

事實一致性

在確定事務事實表的事實時，明確存儲每一個事實以確保度量的一致性。
?

事實可加性
?

事實表確定事實時，往往會遇到非可加性度量，比如分攤比例、利潤率等，雖然它們也是下游分析的關鍵點，但往往在事務事實表中關注更多的是可加性事實，下游用戶在聚合統計時更加方便。

2、周期快照事實表

快照事實表在確定的間隔內對實體的度量進行抽樣，這樣可以很容易地研究實體的度量值，而不需要聚集長期 的事務歷史。

特征

用快照采樣狀態
?

快照事實表以預定的間隔采樣狀態度量。這種間隔聯合一個或多個維度，將被用來定義快照事實表的粒度，每行都將包含記錄所涉及狀態的事實。
?

快照粒度

事務事實表的粒度可以通過業務過程中所涉及的細節程度來描述，但快照事實表的粒度通?？偸潜欢嗑S聲明，可以簡單地理解為快照需要采樣的周期以及什么將被采樣。
?

密度與稀疏性
?

快照事實表和事務事實表的一個關鍵區別在密度上。事務事實表是稀疏的，只有當天發生的業務過程，事實表才會記錄該業務過程的事實，如下單、支付等；而快照事實表是稠密的，無論當天是否有業務過程發生，都會記錄一行，比如針對賣家的歷史至今的下單和支付金額，無論當天賣家是否有下單支付事實，都會給該賣家記錄一行。
?

半可加性
?

在快照事實表中收集到的狀態度量都是半可加的。與事務事實表的可加性事實不同，半可加性事實不能根據時間維度獲得有意義的匯總結果。

設計實例

單維度的每天快照事實表

確定粒度、確定維度

混合維度的每天快照事實表

確定粒度、確定維度、確定狀態度量

全量快照事實表

?

相比單維度的快照事實表，多了一些冗余維度。例如，商品評價表，多了子訂單維度、商品維度、評論者維度。

3、累計快照事實表

對于類似于研究事件之間時間間隔的需求，采用累計快照事實表可以很好地解決。

如在統計買家下單到支付的時長、買家支付到賣家發貨的時長等，事務事實表很難滿足，需要用到累計快照事實表。

特征

數據不斷更新

針對于實體中的某一實例定期更新。
?

多業務過程日期

累積快照事實表適用于具有較明確起止時間的短生命周期的實體，比如交易訂單、物流訂單等，對于實體的每一個實例，都會經歷從誕生到消亡等一系列步驟。對于商品、用戶等具有長生命周期的實體，一般采用周期快照事實表更合適。累積快照事實表的典型特征是多業務過程日期，用于計算業務過程之間的時間間隔。但結合阿里巴巴數據倉庫模型建設的經驗，對于累積快照事實表，還有一個重要作用是保存全量數據。

特殊處理
?

非線性過程

購物網站一般流程是：下單、支付、發貨、確認收貨。但并不是所有的交易都會走此流程，比如買家下單之后不支付或關閉訂單。針對這種非線性過程，處理情況主要有以下幾種：(1）業務過程的統一
?

我們以流程結束標志為依據，關閉訂單也是結束標志，統一起來。
?

(2）針對業務關鍵里程碑構建全面的流程
?

對于沒有支付或沒有發貨的交易訂單也將其納入流程來，相關的業務字段置孔。
?

(3）循環流程的處理
?

主要解決問題是一個業務過程有多個日期。使用業務過程的第一次發生日期還是最近發生日期，根據用戶決定。
?

多源過程?

針對多源業務建模，主要考慮事實表的粒度問題。
?

業務過程取舍?

當擁有大量的業務過程時，模型的實現復雜度會增加，特別是對于多源業務過程，模型的精合度過高，此時需要根據商業用戶需求，選取關鍵的里程碑。
?

物理實現
?

邏輯模型和物理模型密不可分，針對累積快照事實表模型設計，其有不同的實現方式。

第一種：增量存儲?以業務實體的結束時間分區。即每周期僅處理增量部分的數據，針對狀態無變化的數據比較適合 ；

第二種：全量快照?狀態有變化，每天的分區存儲昨天的全量數據和當天的增量數據合并的結果，對于數據量在可控范圍內的情況可以采用如下 保存策略: 如果存儲空間和成本可接受，完整存儲，確保能夠追溯到歷史每天數據狀態 存儲空間有限，考慮移動歷史快照數據到冷盤，需要使用的時候可恢復 數據歷史狀態數據無太大價值，可以考慮部分刪除，比如近保留每月最后一天的快照數據 ；

第三種：拉鏈?針對于全量表的變化形式，數據量大、但緩慢變化、需要跟蹤歷史狀態，和緩慢漸變維類似。

設計準則

同事務事實表設計一樣。

無事實的事實表

在維度模型中，事實表用事實來度量業務過程，不包含事實或度量的事實表稱為無事實的事實表。雖然沒有明確的事實，但可以用來支持業務過程的度量。常見的無事實的事實表主要有如下兩種：

第一種是事件類的，記錄事件的發生。

如阿里巴巴數據倉庫中，最常見的是日志類事實表。

第二種是條件、范圍或資格類的，記錄維度與維度多對多之 間的關系。

如客戶和銷售人員的分配情況、產品的促銷范圍等。

聚集型事實表

數據倉庫的性能是數據倉庫建設是否成功的重要標準之一。聚集主要是通過匯總明細粒度數據來獲得改進查詢性能的效果。通過訪問聚集數據，可以減少數據庫在響應查詢時必須執行的工作量，能夠快速響應用戶的查詢，同時有利于減少不同用戶訪問明細數據帶來的結果不一致問題。如阿里巴巴將使用頻繁的公用數據，通過聚集進行沉淀，比如賣家最近 l 天的交易匯總表、賣家最近 N 天的交易匯總表、賣家自然年交易匯總表等。這類聚集匯總數據，被叫作公共匯總層。

相對于明細事實表，聚合事實表通常是在明細事實表的基礎上，按照一定的粒度粗細進行的匯總、聚合操作，它的粒度較明細數據粒度粗，同時伴隨著細節信息的丟失;在數倉層次結構中，通常位于dws層，一般作為通用匯總數據存在，也可以是更高粒度的指標數據。

1、基本原則
?

一致性?聚集表必須提供與查詢明細粒度數據一致的查詢結果。
?

避免單一表設計?不要在同一個表中存儲不同層次的聚集數據；否則將會導致雙重計算或出現更糟糕的事情。
?

聚集粒度可不同?聚集并不需要保持與原始明細粒度數據一樣的粒度，聚集只關心所需要查詢的維度。

2、基本步驟
?

Step 1：確定聚集維度。
?

Step 2：確定一致性上鉆。
?

Step 3：確定聚集事實。
?

3、常見聚集型事實表
?

數據倉庫中，按照日期范圍的不同，通常包括以下類別的聚集事實表

公共維度層-通用匯總
?

應對大部分可預期的、常規的數據需求，通常針對模式相對穩定的分析、BI指標計算、特征提取等場景，封裝部分業務處理、計算邏輯，盡量避免用戶直接使用底層明細數據，該層用到的數據范圍比較廣泛。

日粒度

主要應對模式穩定的分析、BI日報、特征提取場景，同時日粒度也為后續累積計算提供粗粒度的底層，數據范圍一般為上一日的數據 。

周期性累積

主要應對明確的周期性分析、BI周期性報表，數據范圍一般在某周期內的。

歷史累積

顧名思義，歷史以來某一特定數據的累積，通常在用戶畫像、經營分析、特征提取方面場景較多，設計數據范圍比較廣泛，通常是計算耗時較長的一部分，比如某門店累積營業額、某用戶累積利潤貢獻、用戶首次下單時間(非可度量、描述性)。

4、聚集補充說明

聚集是不跨越事實的

聚集是針對原始星形模型進行的匯總，為了獲取和查詢與原始模型一致的結果，聚集的維度和度量必須與原始模型保持一致，因 此聚集是不跨越事實的。

聚集帶來的問題

聚集會帶來查詢性能的提升，但聚集也會增加 ETL 維護的難度。當子類目對應的一級類目發生變更時，先前存在的、已經被匯總到聚集表中的數據需要被重新調整。這一額外工作隨著業務復雜性的增加，會導致多數 ETL 人員選擇簡單強力的方法，刪除并重新聚集數據。