利用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表明刪除操做。

建議採用度：五星