1. 程式人生 > >利用Data Vault對資料倉庫進行建模(二)

利用Data Vault對資料倉庫進行建模(二)

寫在前面

本篇先不討論Data Vault其本身,因為不見得所有人都接受這個。但是裡邊有一些很不錯的東西跟主流的資料倉庫方法是有共同點的,所以這裡主要討論這些共同的方法,在筆者看來,無論是Kimball還是DV,這些方法都是很有用的。這個系列為作者本人哥本哈士奇的個人理解和總結,可能會有理解上的偏差,也歡迎大家一起來討論。

 

雜湊計算

常用的雜湊計算,HASH KEY, HASH FULL, HASH DIF,這裡會有簡單的介紹。

關於如何做雜湊計算,可以參考這個連結:

https://www.hansmichiels.com/2016/04/09/hash-diff-calculation-with-sql-server-datavault-series/

 

 

HASH KEY

雜湊鍵,通常是根據業務鍵來生成的,比如車輛的唯一識別號,如果已知一個系統的業務鍵跟另外一個系統的業務鍵可能有重合,那麼可以考慮把RECORD SOURCE(後面會有介紹)也加進來參與計算。

在傳統的資料倉庫方法論裡,出於效能角度的考慮,會在維度載入的時候去維護一個維度鍵和代理鍵的對映表,生成一個數值作為代理鍵,然後在維度表裡只保留這個數值。維度載入完畢之後,載入事實表的時候,遇到了這個維度鍵,先會去對映表裡查對應的代理鍵,然後在維度表裡也只會保留這個代理鍵。這樣可以確保事實表和維度表做JOIN時的效能。

同樣在Data Vault的最初1.0版本中,也是先建議先載入HUB表,然後有對應的對映表,最後保留代理鍵。

這種方法確保了查詢時的效能,但是有一個不好的地方就是維度表和事實表,或者HUB表對LINK和SAT表的載入順序就有了要求。所以在Data Vault版本2.0裡,沒有再沿用這種方法,而是採用HASH KEY的方式,這樣HUB,LINK和SAT三類表就可以同時載入。

是的,你會對這樣做同樣有效能上的疑慮,因為生成的HASH KEY從資料表的底層組織上不是最優的,相比於用數值型別的代理鍵,由於數值型別是連續的,所以底層的資料儲存也是連續的,HASH KEY的生成很明顯不是連續的,所以在資料的儲存上不如數值型別的代理鍵效率好,會有頁分裂導致的效能問題。

這個問題Dan有一個討論在此:

http://roelantvos.com/blog/using-a-natural-business-key-the-end-of-hash-keys/

從我個人來理解,如果說其好的一面,雖然這樣會降低ETL載入的效能,但是這個方法使並行載入變得可行,而且避免了ETL過程中的key look up,所以總體來說對ETL的效能收益是正向的還是負面的,需要具體去看。

另外還有一種情況可以不使用雜湊鍵,比如公民身份證號,這個是絕對不會重複的,還有比如車輛識別編碼等。

建議採用度:四星(五星滿星)

 

HASH DIF

這是一個很有用的列。其做計算的時候會根據除了業務鍵列之外的所有列,生成一個唯一串。其好處就是在於,當源端系統不能自己告訴你資料是否變化了的時候,通過這個方法就可以很容易的判斷。

比如一個表有20個列,為了判斷新來的資料是否發生了變化,你是會去一列一列的對比呢,還是將這些列先計算成一個雜湊值,然後只對這個雜湊列去進行比對?很明顯後者更高效。

Dan提到過一點,對於有些資料平臺比如Teredata,其本身是自帶這個列的,所以不需要去自己生成這個列。所以我覺得Dan是從此借鑑過來的吧。

建議採用度:五星

 

RECORD SOURCE

記錄這個資料是從哪個資料來的。

在需要對大量的系統做整合的時候,這個列就很有用,比如在快消領域,標識一個產品的編碼到底是從產品系統中來的,還是從價格管理系統中來。

這裡我想強調的一點是,很多人都誤以為這個欄位是記錄資料怎麼來的,實際上不是,這個只記錄資料從哪裡來,通常都是源系統的名稱,而不是你期望的A+B這種資訊。

它的作用也更在於如前面提到,當生成HASH KEY的時候,如果已知業務鍵在不同的系統間可能有重複,為了能將他們整合到一起,需要用到RECCORD SOURCE來參與計算。

建議採用度:五星

 

LOAD DATE

資料載入時間,這個是指資料在第一次載入到資料倉庫的時間,而這個範圍要從STAGE層算起。

提及這個欄位不得不說另外一個欄位,LOAD END DATE,就是資料在哪次載入時消失或者被更改了。

按照SCD2的規則,如果是刪除的資料,會先把歷史記錄的LOAD END DATE更新,這樣這條記錄的時間線在資料倉庫中中止。如果是更新的資料,首先還是會去更新歷史資料的LOAD END DATE,然後會再新加一條更新後的記錄。

這樣根據這個記錄的生效開始時間和結束時間,就可以在時間線上看到一條資料的變更歷史線。

在很多我看到的Data Vault社群討論中,尤其是對於PSA的設計,都傾向於只插入,不更新歷史記錄的方法。也就是說,沒有LOAD END DATE。其中一個理由就是對於記錄的物理更新,在大量ETL資料操作的時候對效能影響會很大。

這樣做不會耽誤對歷史資料的變更追溯,因為根據LOAD DATE,同樣能拉出一條時間線。只是需要配合CHANGE INDICATOR列,不然刪除的資料只靠LOAD DATE是無法辨識的。

建議採用度:五星

 

DATE EXPORT DATE

資料匯出或者生成的時間。通常是針對無法直接連線到源資料庫的情況,比如源系統需要把資料匯出來,或者通過中間的ESB或者webservice之類的介面。這個主要是為了資料審計的目的,有時候對於資料問題的排查也很重要。

這個資訊需要源系統端帶過來,不過確實很難指望所有的系統都能帶過來這個資訊,所有可以考慮置空。

建議採用度:三星

 

CHANGE INDICATOR

資料變更的指示器。

很多源系統很難提供這個列,而且即使源系統提供了也不見得跟資料倉庫的載入週期一致,所以會在資料倉庫比對得出,這個時候LOAD_DTS和HASH KEY以及HASH DIFF就發揮了作用。

通常用I代表資料是第一次插入的,U代表資料這次載入是一個更新操作,D代表刪除操作。

建議採用度: