Kettle之深度思考---Kettle構建數據倉庫

  我在上兩篇博客的隨筆中，已經大概的介紹過Kettle的安裝以及小的JOB設計。在這個學習過程中，有兩個問題引起我想進一步學習ETL相關設計以及對於數據倉庫設計的好奇。在這篇文章以及下篇將就如下兩個問題引起的深思做出說明：

1. 事實表和維度表ETL都是通過什么順序加載到數據倉庫。
2. 什么叫做遲到的事實表以及如何處理遲到的事實表。

-------------------------------------------------------------------------------------------------------------------------

    首先先解釋維度表，在數據倉庫當中維度表有兩種類型：

•       第一種維度表為業務系統（一般為OLTP系統）中已經包含所有的信息
•       另外一種維度信息來自事實表以及周圍數據

以上圖數據模型說明，其中user_dim為第一種維度，Time_dim以及page_dim為第二種維度。

 

 首先更新user_diim維度表， 由於這一類的維度表信息，均來自業務系統的一個表或者多個表，因此在加載這類維度表時只需要考慮到緩慢變化維度以及通過技術健來標識不同數據。  

   這類維度數據，會遇到兩種操作。

•       新數據insert
•       舊數據更新

    新數據沒啥好說的，主要是舊數據更新的緩慢變化維度設計。

1.      一種是直接覆蓋
2. 一種是加上start_date以及end_date標志，先更新舊記錄，再插入一條記錄。（在數據倉庫當中，此種情況用的多）

  前兩個過程分別是從源數據庫讀取數據，並filter，不做說明。

第二步是user的緩慢變化維度設計過程，

     

     到這一步，第一種維度表的緩慢變化維度算是處理完畢。

-------------------------------------------------------------------------

  第二種維度表的處理會復雜很多，因為包含了事實表以及維度表的處理。

  這里有個思考，先有事實表的page_id(也就是維度主鍵，想請問是怎么得到其維度主鍵的？)

  答：維度表的id也是通過代理鍵實現的，先加載維度表。

由於在我們如上的例子中，包括了兩種維度變化的處理。處理倉庫數據加載分為了兩個transformation:

1.    首先，chef執行第一種維度變化轉換
2. 如果失敗，發送郵件
3. 成功，則加載第二種維度變化轉換並發送郵件。
4. job的實現如下圖。

 

--------------------------------------------------------------

   裝載日期在生效日期后的事實就是遲到的事實。晚於訂單日期進入源數據的銷售訂單可以看做是一個遲到事實的例子。銷售訂單被裝載進其事實表時，裝載的日期晚於銷售訂單的訂單日期，因此是一個遲到的事實。（因為定期裝載的是前一天的數據，所以這里的晚於指的是晚2天及其以上。） 遲到事實影響周期快照事實表的裝載。