B. 數據倉庫 --- 建模技術 --- 事實表 --- 針對事實表的時間跟蹤

B. 數據倉庫 — 建模技術 — 事實表 — 針對事實表的時間跟蹤

概述

存在三種基本事實表粒度：事務級別、週期快照和累積快照。個別情況下，在事實表中增加行有效時期、行截止日期和當前行標識是非常有用的，與採用類型2緩慢變化維度，在事實行有效時獲取時間的方式類似。儘管不太常用，但該模型能夠解決諸如緩慢變化庫存平衡的場景，其中頻繁週期快照可以在每個快照上加載同一行。

事務事實表

• 步驟 — 交易事務設計事實表
  • 業務分析：交易事務包括下單、支付、發貨、完結四個業務過程
  • 確定粒度：同一個訂單中可以包含多個在商品，每個商品對應一個子訂單。在上述四個業務過程中下單、支付、完結選擇子訂單作爲粒度，而發貨業務過程包含物流信息，以父訂單爲粒度
  • 確定維度：賣家、買家、商品、商品類目、發貨地區、收貨地區、父訂單一級雜項維度
  • 確定事實：每個業務過程有自己的事實，如下單過程的下單金額、下單數量；支付過程的支付金額、積分金額等
  • 冗餘維度：爲了提升效率，把常用的維度榮譽到事實表
• 實現方式
  • 單事務事實表：一個業務過程一張事實表，方便對每個業務做獨立分析
  • 將不同業務過程放在同一個事實表中，又可以分爲不同業務過程使用不同事實字段和不同業務過程使用相同事實字段兩種
• 要點：是否採用混合事務事實表，還是爲每個事務類型建立不同的事實表，需要有所權衡
  • 用戶的分析需求是什麼？
    • 用戶分析數據的方式是什麼？
    • 哪種方法能夠最自然地與他們的業務爲中心的期望符合？
  • 的確存在多個獨特的業務過程嗎？ — 跟源系統（業務系統）的設計也有關
    • 採購系統中，每個步驟都有不同的控制號，因此傾向於多事務，庫存模型中，不同的庫存事務是單一庫存過程的組成部分，因此傾向於單一事實表設計
  • 多個源系統獲取同樣粒度的度量嗎？
    • 本例中包含多個源系統：購買、倉庫和應付賬款。這種情況下應該採用不同的事實表
  • 事實的維度是什麼？ — 可以使用維度矩陣展示信息
    • 不同事務的維度不盡相同，因此因此需要不同的事實表

週期快照事實表

• 特點
  • 統計的是間隔週期內的度量統計，如歷史至今、自然年至今、季度至今等等
  • 週期快照表沒有粒度的概念，取而代之的是週期+狀態度量的組合，如歷史至今的訂單總數
  • 事實事務表是稀疏表，週期快照表是稠密表
    • 稀疏表：當天只有發生了操作纔會有記錄
    • 稠密表：當天沒有操作也會有記錄，便於下游使用
• 例子
  • 單維度的週期快照事實表
  • 混合維度的週期快照事實表
  • 全量快照事實表：對於狀態一直變化的數據，用全量快照表統計至今最新的狀態，如訂單評價，好中差評會每天變化，事實表的粒度確定爲每一條評價，加之冗餘常用維表屬性

累積快照事實表：獲取多個過程里程碑，每個都包含日期外鍵並可能包含日期/時間戳。商業用戶通常希望分析這些里程碑之間的滯後及延遲時間。有時這些延遲僅僅是日期上的差異，但某些情況下，延遲可能基於更復雜的業務規則。

• 特點
  • 數據不斷更新：不同於前面說的兩種事實表，累計快照事實表中的數據實例會定期更新。
  • 適用於業務過程有明確的起止時間的短生命週期場景，如交易訂單、物流訂單。長生命週期的實體記錄完全可以由週期快照表實現，如商品、用戶。
  • 業務的流程不是隻有一種，如交易流程可能是1. 下單、支付、發貨、確認2. 下單、關閉訂單對於不同過程，要設計統一的結束標誌，沒有的業務時間置空
• 物理實現
  • 全量表：一般是日分區，每天存儲前一天的全量數據和當天增量數據進行合併，保證每條數據的最新狀態，此方式適用於數據量不大的情況
  • 全量變化表：累積事實表用於保存生命週期短的實例，所以可以根據業務實體從開始到結束的最大時間間隔，如交易業務最大時間跨度200天，每天保存的是過去200天的全量數據，200天之前的數據存儲在歸檔表中。適用於數據量大的場景
  • 以業務結束時間分區：每天分區中存放的是當天結束的業務，然後用一個非常大的分區（如 3000-12-31）保存所有至今未結束的記錄，這種方式不會浪費存儲資源