數倉建模——事實表乾貨教程

事實在字典裡指事情的真實情形,在維度建模中,通常表示某個業務的度量,如商品的數量、金額等。本文作者針對維度建模事實表進行了分析,一起來看一下吧。

數倉建模——事實表乾貨教程

上週在一文中,給大家簡單介紹了數倉建模的常見模型:ER模型和維度建模的一些基本知識,本週我們針對維度建模事實表進行更詳細的講解。

一、什麼是事實

事實在字典裡指事情的真實情形,在維度建模中,通常表示某個業務的度量。如訂單中商品的數量、金額等。

1. 事實型別

此處的事實型別是指度量值的型別,而非事實表的型別。事實(度量值)共分為三類,分別是可加事實,半可加事實和不可加事實。

1)可加事實

可加事實是指可以按照與事實表相關的所有維度進行累加,事務型事實表中的事實,例如上篇文章講述的訂單事實表。

2)半可加事實

半可加事實是指只能按照與事實表相關的一部分維度進行累加,例如週期型快照事實表中的事實。以上述各倉庫中各商品的庫存每天快照事實表為例,這張表中的庫存事實可以按照倉庫或者商品維度進行累加,但是不能按照時間維度進行累加,因為將每天的庫存累加起來是沒有任何意義的。

3)不可加事實

不可加事實是指完全不具備可加性,例如比率型事實。不可加事實通常需要轉化為可加事實,例如比率可轉化為分子和分母。

二、什麼是事實表

事實表是指儲存有事實記錄的表,如使用者登入記錄表、下單記錄、優惠券領取記錄表等,事實表作為資料倉庫維度建模的核心,其緊緊圍繞著業務過程來設計。一般包含與該業務過程有關的維度引用(維度表外來鍵)以及該業務過程的度量(通常是可累加的數字型別欄位)。

引用上篇文章我們講過的下單業務過程為例,如圖所示:訂單明細表作為訂單業務的事實表,訂單明細表中含有買家、賣家、時間、地域、商品、物流等維度,訂單價格作為訂單過程的度量。

事實表有三種類型:分別是

事務事實表、週期快照事實表和累積快照事實表

,每種事實表都具有不同的特點和適用場景,我們依次介紹一下:

1. 事務型事實表

事務型事實表用來記錄各業務過程,它儲存的是各業務過程的原子操作事件,即最細粒度的操作事件。粒度是指事實表中一行資料所表達的業務細節程度。事務型事實表可用於分析與各業務過程相關的各項統計指標,由於其儲存了最細粒度的記錄,可以提供最大限度的靈活性,可以支援無法預期的各種細節層次的統計需求。

1)事務型事實表設計流程

設計事務事實表時一般可遵循以下四個步驟:

選擇業務過程→宣告粒度→確認維度→確認事實。

①選擇業務過程

在業務系統中,挑選我們要分析的業務過程,業務過程可以概括為一個個不可拆分的行為事件,例如電商交易中的下單,取消訂單,付款,退單等,都是業務過程。通常情況下,一個業務過程對應一張事務型事實表。

②宣告粒度

業務過程確定後,需要為每個業務過程宣告粒度。即精確定義每張事務型事實表的每行資料表示什麼,應該儘可能選擇最細粒度,以此來應各種細節程度的需求。

典型的粒度宣告如下:

訂單事實表中一行資料表示的是一個訂單中的一個商品項。

③確定維度

確定維度具體是指,確定與每張事務型事實表相關的維度有哪些。確定維度時應儘量多地選擇與業務過程相關的環境資訊。因為維度的豐富程度就決定了維度模型能夠支援的指標豐富程度。

④確定事實

此處的“事實”一詞,指的是每個業務過程的度量值(通常是可累加的數字型別的值,例如:次數、個數、件數、金額等)。

經過上述四個步驟,事務型事實表就基本設計完成了。第一步選擇業務過程可以確定有哪些事務型事實表,第二步可以確定每張事務型事實表的每行資料是什麼,第三步可以確定每張事務型事實表的維度外來鍵,第四步可以確定每張事務型事實表的度量值欄位。

數倉建模——事實表乾貨教程

(事務事實表 示例)

2)事務型事實表不足之處

事務型事實表可以儲存所有業務過程的最細粒度的操作事件,故理論上其可以支撐與各業務過程相關的各種統計粒度的需求。但對於某些特定型別的需求,其邏輯可能會比較複雜,或者效率會比較低下。例如:

1)存量型指標

對於商品庫存,賬戶餘額等指標,虛擬貨幣業務包含的業務過程主要包括獲取貨幣和使用貨幣,兩個業務過程各自對應一張事務型事實表,一張儲存所有的獲取貨幣的原子操作事件,另一張儲存所有使用貨幣的原子操作事件。

假定現有一個需求,要求統計截至當日的各使用者虛擬貨幣餘額。由於獲取貨幣和使用貨幣均會影響到餘額,故需要對兩張事務型事實表進行聚合,且需要區分兩者對餘額的影響(加或減),另外需要對兩張表的全表資料聚合才能得到統計結果。可以看到,不論是從邏輯上還是效率上考慮,這都不是一個好的方案。

2)多事務關聯統計

如現需要統計最近30天,使用者下單到支付的時間間隔的平均值。統計思路應該是找到下單事務事實表和支付事務事實表,過濾出最近30天的記錄,然後按照訂單id對兩張事實表進行關聯,之後用支付時間減去下單時間,然後再求平均值。 邏輯上雖然並不複雜,但是其效率較低,因為下單事務事實表和支付事務事實表均為大表,大表join大表的操作應儘量避免。

在上述兩種場景下事務型事實表的表現並不理想。下面要介紹的另外兩種型別的事實表就是為了彌補事務型事實表的不足的。

2. 週期型快照事實表

週期快照事實表以具有規律性的、可預見的時間間隔來記錄事實,主要用於分析一些存量型(例如線上人數,賬戶餘額,商品庫存)或者狀態型(空氣溫度,行駛速度)指標。

對於商品庫存、賬戶餘額這些存量型指標,業務系統中通常就會計算並儲存最新結果,所以定期同步一份全量資料到資料倉庫,構建週期型快照事實表,就能輕鬆應對此類統計需求,而無需再對事務型事實表中大量的歷史記錄進行聚合了。

對於空氣溫度、行駛速度這些狀態型指標,由於它們的值往往是連續的,我們無法捕獲其變動的原子事務操作,所以無法使用事務型事實表統計此類需求。而只能定期對其進行取樣,構建週期快照事實表。

1)週期快照事實表設計流程

①確定粒度

週期型快照事實表的粒度可由取樣週期和維度描述,故確定取樣週期和維度後即可確定粒度。

取樣週期通常選擇每日。

維度可根據統計指標決定,例如指標為統計每個倉庫中每種商品的庫存,則可確定維度為倉庫和商品。

確定完取樣週期和維度後,即可確定該表粒度為每日-倉庫-商品。

②確認事實

事實也可根據統計指標決定,例如指標為統計每個倉庫中每種商品的庫存,則事實為商品庫存。

數倉建模——事實表乾貨教程

(週期快照事實表 示例)

3. 累積快照事實表

累計快照事實表是基於一個業務流程中的多個關鍵業務過程聯合處理而構建的事實表,如交易流程中的下單、支付、發貨、確認收貨業務過程。

累積快照事實表通常具有多個日期欄位,每個日期對應業務流程中的一個關鍵業務過程(里程碑)。

累積快照事實表主要用於分析業務過程(里程碑)之間的時間間隔等需求。例如前文提到的使用者下單到支付的平均時間間隔,使用累積型快照事實表進行統計,就能避免兩個事務事實表的關聯操作,從而變得十分簡單高效。

1)累積快照事實表設計流程

累積快照事實表的設計流程同事務型事實表類似,也可採用以下四個步驟,下面重點描述與事務型事實表的不同之處。

選擇一個業務流程中需要關聯分析的多個關鍵業務過程,多個業務過程對應一張累積型快照事實表。

②宣告粒度

精確定義每行資料表示的是什麼,儘量選擇最小粒度。

③確認維度

選擇與各業務過程相關的維度,需要注意的是,各個業務過程均需要一個日期維度。

④確認事實

選擇各業務過程的度量值。

數倉建模——事實表乾貨教程

(累積型事務事實表 示例)

本文由 @菜鳥資料之旅 原創釋出於人人都是產品經理,未經作者許可,禁止轉載

題圖來自Unsplash,基於CC0協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供資訊儲存空間服務。