針對電商交易，設計了交易下單/支付/確認收貨事務事實表， 用於統計下單/支付/確認收貨的子訂單數、GMV等。但仍然有很多需求, 此事務事實表很難滿足，比如統計買家下單到支付的時長、買家支付到賣家發貨的時長、買家從下單到確認收貨的時長等。如果使用事務事實表進行統計，則邏輯複雜且性能很差。對於類似於研究事件之間時間間隔的需求，釆用累積快照事實表可以很好地解決。
累積型快照事實表的設計過程
2.1.選擇業務過程
選擇業務過程，在多事務事實表當中介紹了業務的流轉過程，主要有四個事件，即買家下單、買家支付、賣家發貨、 買家確認收貨業務過程。對於這四個業務過程，在事務統計中只關注下單、支付和確認收貨三個業務過程；而在統計事件時間間隔的需求中， 賣家發貨也是關鍵環節。所以針對累積快照事實表，我們選擇這四個業務過程進行討論。
2.2.確定粒度
確定粒度，一般都是參考多事務事實表，遵循最小粒度優先原則，比如訂單商品粒度。
2.3.確定維度
確定維度，拿交易的多事務事實表來講，維度主要有買家、賣家、 店鋪、商品、類目、發貨地區、收貨地區等。四個業務過程對應的時間字段，格式爲日期+時間，分別爲下單時間、支付時間、發貨時間、確認收貨時間等。
2.4.確定事實
確定事實，對於累積快照事實表，需要將各業務過程對應的事實均放入事實表中。比如淘寶交易累積快照事實表，包含了各業務過程對應的事實，如下單對應的下單金額，支付對應的折扣、郵費和支付金額，確認收貨對應的金額等。累積快照事實表解決的最重要的問題是統計不同業務過程之間的時間間隔，建議將每個過程的時間間隔作爲事實放在事實表中。
2.5.退化維度
退化維度，在大數據的事實表模型設計中，更多的是考慮提高下游用戶的使用效率，降低數據獲取的複雜性，減少關聯的表數量。 一方面，存儲成本降低了，而相比之下CPU成本仍然較高；另一方面, 在大數據時代，很多維表比事實表還大，如淘寶幾十億的商品、幾億的買家等，在分佈式數據倉庫系統中，事實表和維表關聯的成本很高。所以在傳統的維度模型設計完成之後，在物理實現中將各維度的常用屬性退化到事實表中，以大大提高對事實表的過濾查詢、統計聚合等操作的效率，具體詳情不再贅述。
2.6.實例
累積快照事實表和事務性事實表直觀上差異比較大的一點就是：累積快照事實表，多個業務過程，只存在一條記錄，當業務過程發生了，只是修改這一條記錄，而事務性事實表是會產生多條記錄，表相對比較稀疏。
三.累積型快照事實表的特性
累積快照事實表適用於具有較明確起止時間的短生命週期的實體， 比如交易訂單、物流訂單等，對於實體的每一個實例，都會經歷從誕生到消亡等一系列步驟。對於商品、用戶等具有長生命週期的實體，一般採用週期快照事實表更合適。
累積快照事實表的典型特徵是多業務過程日期，用於計算業務過程之間的時間間隔。但結合阿里巴巴數據倉庫模型建設的經驗，對於累積快照事實表，還有一個重要作用是保存全量數據。對於淘寶交易，需要保留歷史截至當前的所有交易數據，其中一種方式是在ODS層保留和源系統結構完全相同的數據；但由於使用時需要關聯維度，較爲麻煩， 所以在公共明細層需要保留一份全量數據，淘寶交易累積快照事實表就承擔了這樣的作用——存放加工後的事實，並將各維度常用屬性和訂單雜項維度退化到此表中。通常用於數據探查、統計分析、數據挖掘等。
四.累積型快照事實表的特殊處理
4.1非線性過程
實際實踐中，累積型快照事實表累積的業務過程不一定都是線性的，買家下單、買家支付、賣家發貨、 買家確認收貨這是正常的流程，也有可能存在買家手工或者第三方人員手工關閉訂單，即訂單關閉狀態，這也意味着該幾個業務過程生命週期的終結。所以應該設立一個標識，當訂單交易完成或者訂單關閉都算作生命週期的終結。
4.2多源過程
實際實踐中，可能還存在買家退貨退款，物流相關情況等，這些都是可能發現循環業務過程的情況，針對這些情況，考慮是否將售後和物流等業務過程加入，就需要考慮加入以後是否會影響粒度，還有針對不確定循環次數的業務過程，是加第一次還是最後一次，都是需要考慮具體業務情況來定的。
五.累積型快照事實表如何實現
5.1全量表的實現方式
第一種方式是全量表的形式。此全量表一般爲日期分區表，每天的分區存儲昨天的全量數據和當天的增量數據合併的結果，保證每條記錄的狀態最新。(保存歷史分區，而不是隻保留最新的狀態，實踐證明歷史分區也有存在的必要性，雖然不常用。)此種方式適用於全量數據較少的情況。如果數據量很大， 此全量表數據量不斷膨脹，存儲了大量永遠不再更新的歷史數據，對 ETL和分析統計性能影響較大。可以想象一下，每天每個分區都要存儲歷史至今所有的數據，這個帶來的存儲開銷是非常巨大的。
5.2全量表的改進方式（解決存儲開銷問題）
第二種方式是全量表的變化形式。此種方式主要針對事實表數據量很大的情況。較短生命週期的業務實體一般從產生到消亡都有一定的時間間隔，可以測算此時間間隔，或者根據商業用戶的需求確定一個相對較大的時間間隔。比如針對交易訂單，我們以200天作爲訂單從產生到消亡的最大間隔（一個用戶基本上不可能200天前支付了，200天以後還沒有確認收貨的情況，但是實際情況往往存在那麼幾單異常情況）。設計最近200天的交易訂單累積快照事實表，每天的分區存儲最近200天的交易訂單，而200天之前的訂單則按照gmt_Create創建分區存儲在歸檔表中。此方式存在的一個問題是200天的全量表根據商業需求需要保留多天的分區數據，而由於數據量較大，存儲消耗較大。
六.三種事實表的比較
6.1事務性事實表
事務事實表記錄的事務層面的事實，用於跟蹤業務過程的行爲，並 支持幾種描述行爲的事實，保存的是最原子的數據，也稱爲“原子事實 表”。事務事實表中的數據在事務事件發生後產生，數據的粒度通常是 每個事務一條記錄。一旦事務被提交，事實表數據被插入，數據就不能 更改，其更新方式爲增量更新。
6.2週期型快照事實表
週期快照事實表以具有規律性的、可預見的時間間隔來記錄事實， 如餘額、庫存、層級、溫度等，時間間隔爲每天、每月、每年等，典型的例子如庫存日快照表等。週期快照事實表的日期維度通常記錄時間段 的終止日，記錄的事實是這個時間段內一些聚集事實值或狀態度量。事 實表的數據一旦插入就不能更改，其更新方式爲增量更新。
6.3累積型快照事實表
累積快照事實表被用來跟蹤實體的一系列業務過程的進展情況，它 通常具有多個日期字段，用於研究業務過程中的里程碑過程的時間間 隔。另外，它還會有一個用於指示最後更新日期的附加日期字段。由於事實表中許多日期在首次加載時是不知道的，而且這類事實表在數據加 載完成後，可以對其數據進行更新，來補充業務狀態變更時的日期信息和事實。
