插曲：hashdiff與DV 2.0

在進入實際創建DV資料模型之前，要先簡單解釋一下hash key和hashdiff的用法。簡單來說，散列演算法（hasing algorithm）是一種快速壓縮資訊的辦法，將任意字串通過一個特定演算法轉換成較短的隨機字符串，而通過這個演算法計算出來的字符串叫做散列值（hash value）。

所有散列函數都有如下一個基本特性：如果兩個散列值是不相同的（根據同一函數），那麼這兩個散列值的原始輸入也是不相同的。
來自維基百科

基於這個特性，DV2.0主要的一個改進就是在需要比對資料的時候將所有的輸入列先通過演算法變成散列值，而在根據需要做比對。一般來說，有兩個重要用法：

1. 將各個表的商務鍵（business keys）轉換成散列鍵（hash keys）
   概念上來說，商務鍵可比某個資料表的唯一鍵（例：產品表<>產品序列號），但在實際商務用途上可能會需要透過多個資訊才能唯一辨識一個實體（例：產品表<>產品序列號 + 產出日期）。
   
   在這種情況下，一般的解決方式可能會使用複合鍵（composite key）或者是多條件鏈接（multi-conditional join），但這可能會導致運算速度較慢，使用更多儲存空間，並且可能會引入意外的邊緣情況（edge case）。 相對的，將複合鍵通過散列演算法就可以通過一個固定長度的資料列來唯一辨識一個實體。

2. 通過hash difference來比對衛星表（satellite tables）內的描述性資料
   衛星表是一種簡單實現CDC（Change Data Capture/譯：異動資料擷取）功能的辦法，而如果你的資料源沒有實現這類功能的話，唯一的做法就是在每一次執行資料管道時，與最後一次上傳的原資料與新加入的資料做比對。如果原資料很“寬”的話，這會是一項計算成本非常高的做法。
   
   如果每一次上傳時都將描述性資料列處理成一個散列值的話，下一次處理資料就可以只比對兩個散列值，確定有變化再上傳了。
   
   在以上的案例可以看到，行3與4的資料雖然日期不同，但實際資料是沒有變動，而兩行的散列值（HASHDIFF_OF_THIS_ROW）也是一樣的。

參考

對DV 2.0裡散列演算法的用途、設計有興趣的朋友，可以參考datavault4dbt的作者Scalefree的網站。

對 dbt 或 data 有興趣 :wave:？歡迎加入 dbt community 到 #local-taipei 找我們，也有實體 Meetup 請到 dbt Taipei Meetup 報名參加