Data Vault 2.0 不僅是建模技術，也提供了一整套數據倉庫項目的方法論。它能提供一套非常可行的方案來滿足數據倉庫項目中對於歷史軌跡和審核兩個方面的需求。
多年來，商業智能(BI)項目一直並將繼續在瀑布模型下運行。它是由每個階段的長時間延伸的序列定義的，該序列需要一份詳盡的前期需求列表、一個完整的數據模型設計，然後將所有硬業務規則和軟業務規則編入ETL流程。可視化層是按順序構建的，並從最初的開始日期算起，在幾個月甚至幾年之後提交給最終用戶。
我們經常看到團隊採用“縮小範圍”的瀑布模式，目的是將大型BI計劃分解成較小的項目。雖然有助於降低整體的複雜性，但是這種方法在應用於BI時仍然有很大的風險，因為有兩個主要的問題:
- 業務需求的變化速度遠快於BI研發的交付能力;
- 預算不願意花在沒有短期利益的長期項目.
以上兩個原因就是為什麼我們設計模式從瀑布轉向可迭代敏捷模式，這種模式提供了一些方法來解決問題。但是在數據分析領域，敏捷本身並不能解決我們在更詳細的數據倉庫或BI項目級別上遇到的重大挑戰。這些包括:
- 迭代數據建模
- 減少重構
- 設計ETL或ELT流程，使其能夠快速響應業務邏輯的變化或新增數據
- 收集設計決策的輸入數據相關的業務需求
為了應對這些問題，Data Vault 2.0應運而生，它定義了一種方法，該方法側重於從敏捷實踐中獲得最大收益，並使用其他已被證明有效的規程和技術，看起來是迄今為止最迭代的BI方法
什麼是Data Vault
Data Vault (DV)將敏捷、BEAM需求收集、CMMI、TQM、六西格瑪和DV建模等方面結合在一起，以定義一種旨在提高BI項目速度和質量的方法。因為它既能提高適應性，又能提高準確性。
DV還包括關於DW項目評估和敏捷任務分級的敏捷方法，以確複雜性或跨DW所涉及的工作。在較低的層次上，它還提供了一種非常簡潔和迭代的方法來處理常見的功能需求。這些包括全面的、可重複的、漸進的、基於敏捷的流程，以完成日常的任務。這些任務包括(但不限於)在ETL和建模階段增加數據屬性、切片、新增加數據源、擴大源、歷史跟蹤、棄用源和源結構更改。
簡單地說，DV模型是一個存在於常規維度建模(OLAP、星型模式)和分段之間的層，它根據不斷增長的業務需求提供伸縮性，並分解建模和ETL的複雜性。它由中心(業務實體)、鏈接(關係)和衛星(描述性屬性)組成，它們在3NF和星型模式之間建模。該模型被放置在數據倉庫的數據集成層(通常稱為原始數據庫)中，並與Kimball的模型有效地結合使用。
Data Vault 2.0 優點
下面概述了Data Vault 2.0方法的一些主要優點:
- 它假設了數據建模關係的最壞情況。業務對象之間的N:M關係，以消除在將1:M變為M:M時需要更新的情況。因此，當關系的程度發生變化時，幾乎不需要再做額外工作。
- 它是為歷史跟蹤數據而設計的,所有的關係和屬性，以及數據在一段時間內的來源都可以被追溯記錄。
- 提出了一套設計原則和結構，在數倉中增加歷史跟蹤性能(坑和橋樑)。數據倉庫模型足夠靈活，可以在迭代建模過程中的任何時間點採用這些結構，並且不需要進行前瞻規劃設計。
- 在邏輯上分隔包含原始數據和修改數據的空間。原始數據倉庫是源系統可審計的數據的基礎，並且業務倉庫為需要訪問數據集市下一級數據的高級用戶提供了一個查詢空間。
- 將軟業務規則和硬業務規則分離到數據集成的不同部分。這加強了跨多個終端使用的數據的可重用性。例如，原始數據只在數據倉庫中獲得一次(較少重新集成到分段中)，可以多次提供給下游需求。
- 對於每個敏捷迭代，存儲所有數據歷史軌跡的數據倉庫模型很容易擴展，而不必擔心丟失歷史數據。此外，歷史軌跡是獨立於維度模型存儲的。
- Data Vault 2.0提倡業務鍵使用hash key實現，以減少lookups，從而增加加載並行度。這導致較少的順序加載依賴性
- 原始數據倉庫（ods）被設計為完全可審計的.
- 在數據倉庫中作為一個整體，從Staging到星型架構和OLAP的處理變得更加平滑和迭代。
- 它提供了一種全面的方法，將來自異構數據源帶有多個不同業務鍵的數據組合在一起(跨多個源系統在倉庫內集成數據)。業務鍵並不總是1:1或格式相同。
- “及時”建模的心態與敏捷方法非常匹配.
缺點
雖然DV優點很多，但是其缺點也不少, 比如:
- DV 其實就是在數據集市或者星型結構層和臨時存儲層之間的一層。在ETL開發和建模方面，開發這個層會帶來一些額外的開銷。如果項目是小規模的，或者項目的生命週期很短，那麼就不值得采用數據庫模型
- 使用Data Vault背後的主要驅動因素之一是出於審計和歷史軌跡的目的。如果這些都不重要，那麼將另一層引入到建模中所需要的開銷就會變得得不償失。然而，從長期的需求來看，這可能是一項值得的前期投資。
- DV代表了對關係、業務鍵和屬性的分解方法，因此與非規範化結構(如星型模式)相比，創建的表的數量更多。但是，考慮到Data Vault是對星型模式的補充，所以多也只是相對的。由於這個原因，需要許多 joins 來查看DV中的數據
- 缺少大規模實際應用案例.
- 這種建模方法，一般來說，對於那些使用Kimball和Inmon的模型的人來說是不太常規和方便的。
何時使用DV?
有幾個關鍵變量才是判斷的標準。比如，
l 我們認為DV建模是滿足數據倉庫項目需求的一種非常可行的方法，其中歷史軌跡跟蹤和審核是兩個重要的因素。
l 此外，如果跨業務實體的關係在數據倉庫中不斷髮展(例如1:M到M:M)，那麼data Vault將簡化這些關係的捕獲，並更關注於交付真正的價值。
l 如果計劃在倉庫中存儲PII數據，並受GDPR、HIPPA或其他法規的約束，data Vault將幫助進行數據審計和可追溯性
權衡DV的利弊，找到更好的適用於自身情況的建模方法才是最佳方案。
