數倉建模——事實表干貨教程
事實在字典里指事情的真實情形,在維度建模中,通常表示某個業務的度量,如商品的數量、金額等。本文作者針對維度建模事實表進行了分析,一起來看一下吧。
上周在《數據倉庫建模超詳細攻略》一文中,給大家簡單介紹了數倉建模的常見模型:ER模型和維度建模的一些基本知識,本周我們針對維度建模事實表進行更詳細的講解。
一、什么是事實
事實在字典里指事情的真實情形,在維度建模中,通常表示某個業務的度量。如訂單中商品的數量、金額等。
1. 事實類型
此處的事實類型是指度量值的類型,而非事實表的類型。事實(度量值)共分為三類,分別是可加事實,半可加事實和不可加事實。
1)可加事實
可加事實是指可以按照與事實表相關的所有維度進行累加,事務型事實表中的事實,例如上篇文章講述的訂單事實表。
2)半可加事實
半可加事實是指只能按照與事實表相關的一部分維度進行累加,例如周期型快照事實表中的事實。以上述各倉庫中各商品的庫存每天快照事實表為例,這張表中的庫存事實可以按照倉庫或者商品維度進行累加,但是不能按照時間維度進行累加,因為將每天的庫存累加起來是沒有任何意義的。
3)不可加事實
不可加事實是指完全不具備可加性,例如比率型事實。不可加事實通常需要轉化為可加事實,例如比率可轉化為分子和分母。
二、什么是事實表
事實表是指存儲有事實記錄的表,如用戶登錄記錄表、下單記錄、優惠券領取記錄表等,事實表作為數據倉庫維度建模的核心,其緊緊圍繞著業務過程來設計。一般包含與該業務過程有關的維度引用(維度表外鍵)以及該業務過程的度量(通常是可累加的數字類型字段)。
引用上篇文章我們講過的下單業務過程為例,如圖所示:訂單明細表作為訂單業務的事實表,訂單明細表中含有買家、賣家、時間、地域、商品、物流等維度,訂單價格作為訂單過程的度量。
事實表有三種類型:分別是事務事實表、周期快照事實表和累積快照事實表,每種事實表都具有不同的特點和適用場景,我們依次介紹一下:
1. 事務型事實表
事務型事實表用來記錄各業務過程,它保存的是各業務過程的原子操作事件,即最細粒度的操作事件。粒度是指事實表中一行數據所表達的業務細節程度。事務型事實表可用于分析與各業務過程相關的各項統計指標,由于其保存了最細粒度的記錄,可以提供最大限度的靈活性,可以支持無法預期的各種細節層次的統計需求。
1)事務型事實表設計流程
設計事務事實表時一般可遵循以下四個步驟:
選擇業務過程→聲明粒度→確認維度→確認事實。
①選擇業務過程
在業務系統中,挑選我們要分析的業務過程,業務過程可以概括為一個個不可拆分的行為事件,例如電商交易中的下單,取消訂單,付款,退單等,都是業務過程。通常情況下,一個業務過程對應一張事務型事實表。
②聲明粒度
業務過程確定后,需要為每個業務過程聲明粒度。即精確定義每張事務型事實表的每行數據表示什么,應該盡可能選擇最細粒度,以此來應各種細節程度的需求。
典型的粒度聲明如下:
訂單事實表中一行數據表示的是一個訂單中的一個商品項。
③確定維度
確定維度具體是指,確定與每張事務型事實表相關的維度有哪些。確定維度時應盡量多地選擇與業務過程相關的環境信息。因為維度的豐富程度就決定了維度模型能夠支持的指標豐富程度。
④確定事實
此處的“事實”一詞,指的是每個業務過程的度量值(通常是可累加的數字類型的值,例如:次數、個數、件數、金額等)。
經過上述四個步驟,事務型事實表就基本設計完成了。第一步選擇業務過程可以確定有哪些事務型事實表,第二步可以確定每張事務型事實表的每行數據是什么,第三步可以確定每張事務型事實表的維度外鍵,第四步可以確定每張事務型事實表的度量值字段。
(事務事實表 示例)
2)事務型事實表不足之處
事務型事實表可以保存所有業務過程的最細粒度的操作事件,故理論上其可以支撐與各業務過程相關的各種統計粒度的需求。但對于某些特定類型的需求,其邏輯可能會比較復雜,或者效率會比較低下。例如:
1)存量型指標
對于商品庫存,賬戶余額等指標,虛擬貨幣業務包含的業務過程主要包括獲取貨幣和使用貨幣,兩個業務過程各自對應一張事務型事實表,一張存儲所有的獲取貨幣的原子操作事件,另一張存儲所有使用貨幣的原子操作事件。
假定現有一個需求,要求統計截至當日的各用戶虛擬貨幣余額。由于獲取貨幣和使用貨幣均會影響到余額,故需要對兩張事務型事實表進行聚合,且需要區分兩者對余額的影響(加或減),另外需要對兩張表的全表數據聚合才能得到統計結果。可以看到,不論是從邏輯上還是效率上考慮,這都不是一個好的方案。
2)多事務關聯統計
如現需要統計最近30天,用戶下單到支付的時間間隔的平均值。統計思路應該是找到下單事務事實表和支付事務事實表,過濾出最近30天的記錄,然后按照訂單id對兩張事實表進行關聯,之后用支付時間減去下單時間,然后再求平均值。 邏輯上雖然并不復雜,但是其效率較低,因為下單事務事實表和支付事務事實表均為大表,大表join大表的操作應盡量避免。
在上述兩種場景下事務型事實表的表現并不理想。下面要介紹的另外兩種類型的事實表就是為了彌補事務型事實表的不足的。
2. 周期型快照事實表
周期快照事實表以具有規律性的、可預見的時間間隔來記錄事實,主要用于分析一些存量型(例如在線人數,賬戶余額,商品庫存)或者狀態型(空氣溫度,行駛速度)指標。
對于商品庫存、賬戶余額這些存量型指標,業務系統中通常就會計算并保存最新結果,所以定期同步一份全量數據到數據倉庫,構建周期型快照事實表,就能輕松應對此類統計需求,而無需再對事務型事實表中大量的歷史記錄進行聚合了。
對于空氣溫度、行駛速度這些狀態型指標,由于它們的值往往是連續的,我們無法捕獲其變動的原子事務操作,所以無法使用事務型事實表統計此類需求。而只能定期對其進行采樣,構建周期快照事實表。
1)周期快照事實表設計流程
①確定粒度
周期型快照事實表的粒度可由采樣周期和維度描述,故確定采樣周期和維度后即可確定粒度。
采樣周期通常選擇每日。
維度可根據統計指標決定,例如指標為統計每個倉庫中每種商品的庫存,則可確定維度為倉庫和商品。
確定完采樣周期和維度后,即可確定該表粒度為每日-倉庫-商品。
②確認事實
事實也可根據統計指標決定,例如指標為統計每個倉庫中每種商品的庫存,則事實為商品庫存。
(周期快照事實表 示例)
3. 累積快照事實表
累計快照事實表是基于一個業務流程中的多個關鍵業務過程聯合處理而構建的事實表,如交易流程中的下單、支付、發貨、確認收貨業務過程。
累積快照事實表通常具有多個日期字段,每個日期對應業務流程中的一個關鍵業務過程(里程碑)。
累積快照事實表主要用于分析業務過程(里程碑)之間的時間間隔等需求。例如前文提到的用戶下單到支付的平均時間間隔,使用累積型快照事實表進行統計,就能避免兩個事務事實表的關聯操作,從而變得十分簡單高效。
1)累積快照事實表設計流程
累積快照事實表的設計流程同事務型事實表類似,也可采用以下四個步驟,下面重點描述與事務型事實表的不同之處。
選擇業務過程→聲明粒度→確認維度→確認事實。
①選擇業務過程
選擇一個業務流程中需要關聯分析的多個關鍵業務過程,多個業務過程對應一張累積型快照事實表。
②聲明粒度
精確定義每行數據表示的是什么,盡量選擇最小粒度。
③確認維度
選擇與各業務過程相關的維度,需要注意的是,各個業務過程均需要一個日期維度。
④確認事實
選擇各業務過程的度量值。
(累積型事務事實表 示例)
本文由 @菜鳥數據之旅 原創發布于人人都是產品經理,未經作者許可,禁止轉載
題圖來自Unsplash,基于CC0協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
辛苦了