01

事實表基礎

1、事實表特征

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

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

• 可加性事實 是指可以按照與事實表關聯的任意維度進行彙總。
• 半可加性事實 隻能按照特定維度彙總，不能對所有維度彙總，比如庫存可以按照地點和商品進行彙總，而按時第門章事實表設計丁一間維度把一年中每個月的庫存累 加起來則毫無意義。
• 不可加事實 不具備可加性，比如比率型事實。對于不可加性事實可分解為可加的組件來實現聚集。

2、有事實的事實表

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

3、無事實的事實表

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

02事實表設計規則

• 盡可能包含所有與業務過程相關的事實；
• 隻選擇與業務過程相關的事實；
• 分解不可加性事實為可加的組件；比如訂單的優惠率，應該分解為訂單原價金額與訂單優惠金額
• 在選擇維度和事實之前必須先聲明粒度；
• 在同一個事實表中不能有多種不同粒度的事實；粒度的聲明是事實表設計中不可忽視的重要一步，粒度用于确定事實表中一行所表示業務的細節層次，決定了維度模型的擴展性，在選擇維度和事實之前必須先聲明粒度，且每個維度和事實必須與所定義的粒度保持一緻
• 在同一個事實表中不能有多種不同粒度的事實；
• 事實的單位要保持一緻；
• 對事實的 null 值要處理；在數據庫中null值對常用的大于或小于等SQL不生效，建議使用零值填充
• 使用退化維度提高事實表的易用性；目的主要是為了減少下遊用戶使用時關聯多個表的操作。直接通過退化維度實現對事實表的過濾查詢、控制聚合層次、排序數據以及定義主從關系等。

03

事實表設計方法

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

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

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

Step 2:聲明粒度 。

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

Step 3 :确定維度 。

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

Step 4 : 确定事實 。

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

Step 5:冗餘維度 。

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

04

有事實的事實表

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

1、事務事實表

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

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

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

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

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

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

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

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

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

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

設計準則

1. 事實完整性
2. 事實表包含與其描述的過程有關的所有事實，即盡可能多地獲取所有的度量。
3. 事實一緻性
4. 在确定事務事實表的事實時，明确存儲每一個事實以确保度量的一緻性。
5. 事實可加性
6. 事實表确定事實時，往往會遇到非可加性度量，比如分攤比例、利潤率等，雖然它們也是下遊分析的關鍵點，但往往在事務事實表中關注更多的是可加性事實，下遊用戶在聚合統計時更加方便。

2、周期快照事實表

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

特征

1. 用快照采樣狀态
2. 快照事實表以預定的間隔采樣狀态度量。這種間隔聯合一個或多個維度，将被用來定義快照事實表的粒度，每行都将包含記錄所涉及狀态的事實。
3. 快照粒度
4. 事務事實表的粒度可以通過業務過程中所涉及的細節程度來描述，但快照事實表的粒度通常總是被多維聲明，可以簡單地理解為快照需要采樣的周期以及什麼将被采樣。
5. 密度與稀疏性
6. 快照事實表和事務事實表的一個關鍵區别在密度上。事務事實表是稀疏的，隻有當天發生的業務過程，事實表才會記錄該業務過程的事實，如下單、支付等；而快照事實表是稠密的，無論當天是否有業務過程發生，都會記錄一行，比如針對賣家的曆史至今的下單和支付金額，無論當天賣家是否有下單支付事實，都會給該賣家記錄一行。
7. 半可加性
8. 在快照事實表中收集到的狀态度量都是半可加的。與事務事實表的可加性事實不同，半可加性事實不能根據時間維度獲得有意義的彙總結果。

設計實例

單維度的每天快照事實表

确定粒度、确定維度

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

确定粒度、确定維度、确定狀态度量

全量快照事實表

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

3、累計快照事實表

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

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

特征

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

特殊處理

1. 非線性過程
2. 購物網站一般流程是：下單、支付、發貨、确認收貨。但并不是所有的交易都會走此流程，比如買家下單之後不支付或關閉訂單。針對這種非線性過程，處理情況主要有以下幾種：(1）業務過程的統一
3. 我們以流程結束标志為依據，關閉訂單也是結束标志，統一起來。
4. (2）針對業務關鍵裡程碑構建全面的流程
5. 對于沒有支付或沒有發貨的交易訂單也将其納入流程來，相關的業務字段置孔。
6. (3）循環流程的處理
7. 主要解決問題是一個業務過程有多個日期。使用業務過程的第一次發生日期還是最近發生日期，根據用戶決定。
8. 多源過程 針對多源業務建模，主要考慮事實表的粒度問題。
9. 業務過程取舍 當擁有大量的業務過程時，模型的實現複雜度會增加，特别是對于多源業務過程，模型的精合度過高，此時需要根據商業用戶需求，選取關鍵的裡程碑。

物理實現

邏輯模型和物理模型密不可分，針對累積快照事實表模型設計，其有不同的實現方式。第一種：增量存儲 以業務實體的結束時間分區。即每周期僅處理增量部分的數據，針對狀态無變化的數據比較适合 ；第二種：全量快照 狀态有變化，每天的分區存儲昨天的全量數據和當天的增量數據合并的結果，對于數據量在可控範圍内的情況可以采用如下 保存策略: 如果存儲空間和成本可接受，完整存儲，确保能夠追溯到曆史每天數據狀态 存儲空間有限，考慮移動曆史快照數據到冷盤，需要使用的時候可恢複 數據曆史狀态數據無太大價值，可以考慮部分删除，比如近保留每月最後一天的快照數據 ；第三種：拉鍊 針對于全量表的變化形式，數據量大、但緩慢變化、需要跟蹤曆史狀态，和緩慢漸變維類似。Hive 拉鍊表實踐。

設計準則

同事務事實表設計一樣。

05

無事實的事實表

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

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

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

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

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

06

聚集型事實表

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

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

1、基本原則

• 一緻性 聚集表必須提供與查詢明細粒度數據一緻的查詢結果。
• 避免單一表設計 不要在同一個表中存儲不同層次的聚集數據；否則将會導緻雙重計算或出現更糟糕的事情。
• 聚集粒度可不同 聚集并不需要保持與原始明細粒度數據一樣的粒度，聚集隻關心所需要查詢的維度。

2、基本步驟

Step 1：确定聚集維度。

Step 2：确定一緻性上鑽。

Step 3：确定聚集事實。

3、常見聚集型事實表

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

公共維度層-通用彙總

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

日粒度

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

周期性累積

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

曆史累積

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

4、聚集補充說明

聚集是不跨越事實的

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

聚集帶來的問題

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

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!