DV 使用狀況、定位

在這一篇文裡有提到過，在傳統用法裡DV基本上只會用在整合資料層（Integration Layer），而一般狀況下不會讓一般使用者（DA、DS）直接使用。而就算在整合資料層裡，也不是所有的案例都需要這種高複雜性的設計的，也只有在特定需要考慮原資料或組織複雜性的狀況下才會套用。

在我個人最常見並建議使用DV的狀況是：
1. DE、AE、DA有明確分工的組織
或換句話說，不管實際職稱是什麼，如果你的原資料層（Product / Eng）、整合層（DE）、集市層（AE）、與最終使用者（DA）有明確的組織上的職權與分工，DV是個很好的選擇。

在這種狀況下，不管原資料層有什麼樣的變動與改版都僅對一個資料層產生影響，而只有一個團隊需要應對（通常是DE ：P）。相對的，其他團隊決定做什麼樣的變化，只要對接的資料格式相容對其他的團隊也不會有太大的影響。另外，由於DV的設計重複性高，內部工具開發也比較容易平台化。

2. 資料源複雜而經常變化
由於將衛星（Satellite）和中心（Hub）分成不同的實體，相對一般單一化的資料模型設計DV對資料源變化的兼容性較高。這類問題其實在需要載入很多第三方資料源的狀況很常見。

例如在唯一鍵不變但要對應實體的敘述性資料設計變化，DV只需要開一個新的衛星表，而不用做任何其他的的表列改變。在對應一些舊型資料基礎設施（legacy data infrastructure）的狀況下，這個功能對DV採用是個很重要的考量。在一些非縱列資料庫（Columnar Database）存儲架構下，要增加新的表列是非常低效能並高風險的操作。

就算商務唯一鍵需要改變，也可以通過添加中心與鏈接表的商務鍵與改變散列唯一鍵的產生辦法來做調整，而達到向後相容性（backwards compatibility）。

現代資料工程考量

除了將DV在整合資料層內使用，以最近各種現代資料工程、工具的進步，也有一些值得一提的例外案例。

從工具來說，DV很適合對接一些自助服務資料工具（self-serve data tools）。只要工具上可以接受多層的鏈接且SQL查詢引擎（SQL Query Engine）在效能上可以應付的話，這種嚴謹與模塊化的設計其實很適合自動產生Query。相對的，可能要權衡考慮的是metric定義上可能會增加的複雜度，不過這類問題可能也可以過簡化的Business Vault來解決。

另外，在資料工程比較先進的環境下，也可能直接跳過集市層而直接使用語義層（semantic layer）。與以上提到的狀況相似，由於DV的設計適合自動產生SQL，而在如果資料團隊的組織趨近基於分散式業務領域（distributed business-domain based)的環境下也可以考慮各個領域團隊直接在DV整合資料層行設計語義層。

總結

零零總總結果將一個題目寫了12篇文，增添了一些相對罕見的中文資源，也希望對有需要用到Data Vault的人用幫助！如果對DV有問題的朋友也可以通過以下dbt Slack社群聯絡我，很樂意與志同道合的朋友討論、切磋！

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