寫在前面

本篇先不討論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代表刪除操作。

建議採用度：