簡介
國內關於Data Vault的資訊很少，所以決定寫點什麼，純粹都是自己在這個行業10多年的摸爬滾打。不過為了效率，儘量做到簡短，直接上乾貨。對於各個細節大家有不同的理解歡迎來討論。
資料倉儲建模的方法有哪些。
首先最經典的是資料倉儲Inmon基於3NF的方法。這個方法知道概念的人很多，但是實際用的很少，也不建議你去了解更多，因為目前在國內的招聘網站上你會很少找到這個。
其次是Kimball的維度建模方法，這個基本上做過資料倉儲的都用過，比如事實表和維度表，基於這種理論也可以構建資料立方體方便分析。其特點是簡單快速，適合中小型資料倉儲。招聘網站上九成以上關於資料倉儲的招聘都會要求這個。
然後是Dan的Data Vault建模方法。這個國內知道的不多。不同於維度方法，它的基本表是LINK，HUB以及SAT表。這個方法論連Inmon都說好，只是圈子實在太小。這個方法論比較適合企業級資料倉儲，以及大資料的場景。
為什麼要Data Vault
關於DV的各種好處官方站點提了好多，但說得都很marketing。以下是我個人的理解：
- 適合企業級資料倉儲。
- 適合大資料專案，是的，在大資料中你怎麼去組織資料，直接扔那？還是用維度模型？是不是都不太合適？那你應該考慮Data Vault。
- 比較容易根據後設資料系統去自動生成相應的程式碼。這個在下面我會介紹一些。
誰更愛DV？
這是一個很有意思的問題，同時你也可以看到這個話題在國內是多麼冷門。
從我閱讀到的文章觀察到資訊來看，首先是歐洲比較火熱，其次是北美，然後是澳洲。
在歐洲，德國人似乎更愛這個話題，在海外網站偶爾能看到德國人寫的文章以及在討論相關的問題，所以，汽車領域會見到的比較多。開源的專案以及商業相關的專案，也大多數都是歐洲的公司。
在國內看到的討論和文章真的是少之又少，目前我所觀察到的是阿里有人在討論，但是不確定是在哪個部門。
維度模型還是DV？
維度模型和DV的關係，我覺得他倆是不衝突的。在我自己參考別人的方法制定的規範中，核心層用的方法是DV，然後在集市層用到的方法就是維度模型和寬表。
如果你的前端有對應的OLAP Cube工具的話，那麼維度模型確實是必要的。
在核心層，相比維度模型，DV就比較容易對各個系統的資料進行整合和關係的管理。
想知道關於Data Vault更多的資訊？
首先你可以去都Dan的網站：
對英文多少有點要求，主要是他們的思路和文風有時候真的好飄逸。
其次是Roelant的網站：
裡邊的乾貨也很多，當然某些細節對大家的英語也是個挑戰。他的部落格裡有好多細節的實現，其次他也有自己的開源專案可以作為不錯的參考。
最後，也可以參考我正在翻譯的DV規範：
https://github.com/microsoftbi/DWH-Standard-code-69/blob/master/DV2ModelingSpeci.md
這裡面我按照英文-中文對照的方式，根據自己掌握的知識和理解去進行本地化的翻譯。
進度很慢，但是如果你想要知道個大概的話那麼看我中文翻譯出來的部分基本就夠了。
結合Data Vault我也自己編寫了一個資料倉儲的各方面標準：
https://github.com/microsoftbi/DWH-Standard-code-69/wiki/Data-Warehouse-standard--Code-Branch-69
Code name 69，我會不斷加入更多專案的實施細節進去。
當然實際專案中會有很多實現的分支，比如對資料的變更處理，有SCD2等很多方法，在我的這個規範裡就是insert only。
當然沒有一個方法能適用所有場景，這個69規範也不見得就是最專業的，如果你的專案是start from zero的話，那麼或許可以拿來做一個參考然後製作出自己的專案規範。