資料倉儲資料模型之 極限儲存 歷史拉鍊表

2021-10-10 16:43:58 字數 2994 閱讀 9695

在資料倉儲的資料模型設計過程中,經常會遇到這樣的需求:

資料量比較大;

2. 表中的部分欄位會被update,如使用者的位址,產品的描述資訊,訂單的狀態等等;

3. 需要檢視某乙個時間點或者時間段的歷史快照資訊,比如,檢視某乙個訂單在歷史某乙個時間點的狀態,

比如,檢視某乙個使用者在過去某一段時間內,更新過幾次等等;

4. 變化的比例和頻率不是很大,比如,總共有1000萬的會員,每天新增和發生變化的有10萬左右;

5. 如果對這邊表每天都保留乙份全量,那麼每次全量中會儲存很多不變的資訊,對儲存是極大的浪費;拉鍊歷史表,既能滿足反應資料的歷史狀態,又可以最大程度的節省儲存;舉個簡單例子,比如有一張訂單表,6月20號有3條記錄:

訂單建立日期

訂單編號

訂單狀態

2012-06-20

001建立訂單

2012-06-20

002建立訂單

2012-06-20

003支付完成

到6月21日,表中有5條記錄:

訂單建立日期

訂單編號

訂單狀態

2012-06-20

001支付完成(從建立到支付)

2012-06-20

002建立訂單

2012-06-20

003支付完成

2012-06-21

004建立訂單

2012-06-21

005建立訂單

到6月22日,表中有6條記錄:

訂單建立日期

訂單編號

訂單狀態

2012-06-20

001支付完成(從建立到支付)

2012-06-20

002建立訂單

2012-06-20

003已發貨(從支付到發貨)

2012-06-21

004建立訂單

2012-06-21

005支付完成(從建立到支付)

2012-06-22

006建立訂單

資料倉儲中對該錶的保留方法:

只保留乙份全量,則資料和6月22日的記錄一樣,如果需要檢視6月21日訂單001的狀態,則無法滿足;

每天都保留乙份全量,則資料倉儲中的該錶共有14條記錄,但好多記錄都是重複儲存,沒有任務變化,如訂單002,004,資料量大了,會造成很大的儲存浪費;

如果在資料倉儲中設計成歷史拉鍊表儲存該錶,則會有下面這樣一張表:

訂單建立日期

訂單編號

訂單狀態

dw_begin_date

dw_end_date

2012-06-20

001建立訂單

2012-06-20

2012-06-20

2012-06-20

001支付完成

2012-06-21

9999-12-31

2012-06-20

002建立訂單

2012-06-20

9999-12-31

2012-06-20

003支付完成

2012-06-20

2012-06-21

2012-06-20

003已發貨

2012-06-22

9999-12-31

2012-06-21

004建立訂單

2012-06-21

9999-12-31

2012-06-21

005建立訂單

2012-06-21

2012-06-21

2012-06-21

005支付完成

2012-06-22

9999-12-31

2012-06-22

006建立訂單

2012-06-22

9999-12-31

說明:dw_begin_date表示該條記錄的生命週期開始時間,dw_end_date表示該條記錄的生命週期結束時間;

dw_end_date = 『9999-12-31』表示該條記錄目前處於有效狀態;

如果查詢當前所有有效的記錄,則select * from order_his where dw_end_date = 『9999-12-31′

如果查詢2012-06-21的歷史快照,則select * from order_his where dw_begin_date <= 『2012-06-21′ and end_date >= 『2012-06-21』,這條語句會查詢到以下記錄:

訂單建立日期

訂單編號

訂單狀態

dw_begin_date

dw_end_date

2012-06-20

001支付完成

2012-06-21

9999-12-31

2012-06-20

002建立訂單

2012-06-20

9999-12-31

2012-06-20

003支付完成

2012-06-20

2012-06-21

2012-06-21

004建立訂單

2012-06-21

9999-12-31

2012-06-21

005建立訂單

2012-06-21

2012-06-21

和源表在6月21日的記錄完全一致:

訂單建立日期

訂單編號

訂單狀態

2012-06-20

001支付完成(從建立到支付)

2012-06-20

002建立訂單

2012-06-20

003支付完成

2012-06-21

004建立訂單

2012-06-21

005建立訂單

可以看出,這樣的歷史拉鍊表,既能滿足對歷史資料的需求,又能很大程度的節省儲存資源;

關於這種歷史拉鍊表的etl重新整理策略和方法,下次再談吧。。。

資料倉儲資料模型之 極限儲存 歷史拉鍊表

在資料倉儲的資料模型設計過程中,經常會遇到這樣的需求 1.資料量比較大 2.表中的部分欄位會被update,如使用者的位址,產品的描述資訊,訂單的狀態等等 3.需要檢視某乙個時間點或者時間段的歷史快照資訊 比如,檢視某乙個訂單在歷史某乙個時間點的狀態,比如,檢視某乙個使用者在過去某一段時間內,更新過...

資料倉儲資料模型之 極限儲存 歷史拉鍊表

在資料倉儲的資料模型設計過程中,經常會遇到這樣的需求 1.資料量比較大 2.表中的部分欄位會被update,如使用者的位址,產品的描述資訊,訂單的狀態等等 3.需要檢視某乙個時間點或者時間段的歷史快照資訊,比如,檢視某乙個訂單在歷史某乙個時間點的狀態,比如,檢視某乙個使用者在過去某一段時間內,更新過...

資料倉儲 資料模型

資料模型是抽象描述現實世界的一種工具和方法,是通過抽象的實體及實體之間聯絡的形式,來表示現實世界中事務的相互關係的一種對映。在這裡,資料模型表現的抽象的是實體和實體之間的關係,通過對實體和實體之間關係的定義和描述,來表達實際的業務中具體的業務關係。資料倉儲模型是資料模型中針對特定的資料倉儲應用系統的...