Data Vault 簡介Data Vault 簡介 - DB樂之者 - 博客園 Data Vault 2.0 不僅是建模技術(shù)，也提供了一整套數(shù)據(jù)倉庫項目的方法論。它能

Data Vault 簡介

Data Vault 簡介 - DB樂之者 - 博客園
Data Vault 2.0 不僅是建模技術(shù)，也提供了一整套數(shù)據(jù)倉庫項目的方法論。它能提供一套非常可行的方案來滿足數(shù)據(jù)倉庫項目中對于歷史軌跡和審核兩個方面的需求。
多年來，商業(yè)智能(BI)項目一直并將繼續(xù)在瀑布模型下運行。它是由每個階段的長時間延伸的序列定義的，該序列需要一份詳盡的前期需求列表、一個完整的數(shù)據(jù)模型設(shè)計，然后將所有硬業(yè)務(wù)規(guī)則和軟業(yè)務(wù)規(guī)則編入ETL流程。可視化層是按順序構(gòu)建的，并從最初的開始日期算起，在幾個月甚至幾年之后提交給最終用戶。

我們經(jīng)常看到團(tuán)隊采用“縮小范圍”的瀑布模式，目的是將大型BI計劃分解成較小的項目。雖然有助于降低整體的復(fù)雜性，但是這種方法在應(yīng)用于BI時仍然有很大的風(fēng)險，因為有兩個主要的問題:

• 業(yè)務(wù)需求的變化速度遠(yuǎn)快于BI研發(fā)的交付能力;
• 預(yù)算不愿意花在沒有短期利益的長期項目.

以上兩個原因就是為什么我們設(shè)計模式從瀑布轉(zhuǎn)向可迭代敏捷模式，這種模式提供了一些方法來解決問題。但是在數(shù)據(jù)分析領(lǐng)域，敏捷本身并不能解決我們在更詳細(xì)的數(shù)據(jù)倉庫或BI項目級別上遇到的重大挑戰(zhàn)。這些包括:

• 迭代數(shù)據(jù)建模
• 減少重構(gòu)
• 設(shè)計ETL或ELT流程，使其能夠快速響應(yīng)業(yè)務(wù)邏輯的變化或新增數(shù)據(jù)
• 收集設(shè)計決策的輸入數(shù)據(jù)相關(guān)的業(yè)務(wù)需求

為了應(yīng)對這些問題，Data Vault 2.0應(yīng)運而生，它定義了一種方法，該方法側(cè)重于從敏捷實踐中獲得最大收益，并使用其他已被證明有效的規(guī)程和技術(shù)，看起來是迄今為止最迭代的BI方法
什么是Data Vault
Data Vault (DV)將敏捷、BEAM需求收集、CMMI、TQM、六西格瑪和DV建模等方面結(jié)合在一起，以定義一種旨在提高BI項目速度和質(zhì)量的方法。因為它既能提高適應(yīng)性，又能提高準(zhǔn)確性。
DV還包括關(guān)于DW項目評估和敏捷任務(wù)分級的敏捷方法，以確復(fù)雜性或跨DW所涉及的工作。在較低的層次上，它還提供了一種非常簡潔和迭代的方法來處理常見的功能需求。這些包括全面的、可重復(fù)的、漸進(jìn)的、基于敏捷的流程，以完成日常的任務(wù)。這些任務(wù)包括(但不限于)在ETL和建模階段增加數(shù)據(jù)屬性、切片、新增加數(shù)據(jù)源、擴(kuò)大源、歷史跟蹤、棄用源和源結(jié)構(gòu)更改。
簡單地說，DV模型是一個存在于常規(guī)維度建模(OLAP、星型模式)和分段之間的層，它根據(jù)不斷增長的業(yè)務(wù)需求提供伸縮性，并分解建模和ETL的復(fù)雜性。它由中心(業(yè)務(wù)實體)、鏈接(關(guān)系)和衛(wèi)星(描述性屬性)組成，它們在3NF和星型模式之間建模。該模型被放置在數(shù)據(jù)倉庫的數(shù)據(jù)集成層(通常稱為原始數(shù)據(jù)庫)中，并與Kimball的模型有效地結(jié)合使用。

Data Vault 2.0 優(yōu)點
下面概述了Data Vault 2.0方法的一些主要優(yōu)點:

• 它假設(shè)了數(shù)據(jù)建模關(guān)系的最壞情況。業(yè)務(wù)對象之間的N:M關(guān)系，以消除在將1:M變?yōu)镸:M時需要更新的情況。因此，當(dāng)關(guān)系的程度發(fā)生變化時，幾乎不需要再做額外工作。
• 它是為歷史跟蹤數(shù)據(jù)而設(shè)計的,所有的關(guān)系和屬性，以及數(shù)據(jù)在一段時間內(nèi)的來源都可以被追溯記錄。
• 提出了一套設(shè)計原則和結(jié)構(gòu)，在數(shù)倉中增加歷史跟蹤性能(坑和橋梁)。數(shù)據(jù)倉庫模型足夠靈活，可以在迭代建模過程中的任何時間點采用這些結(jié)構(gòu)，并且不需要進(jìn)行前瞻規(guī)劃設(shè)計。
• 在邏輯上分隔包含原始數(shù)據(jù)和修改數(shù)據(jù)的空間。原始數(shù)據(jù)倉庫是源系統(tǒng)可審計的數(shù)據(jù)的基礎(chǔ)，并且業(yè)務(wù)倉庫為需要訪問數(shù)據(jù)集市下一級數(shù)據(jù)的高級用戶提供了一個查詢空間。
• 將軟業(yè)務(wù)規(guī)則和硬業(yè)務(wù)規(guī)則分離到數(shù)據(jù)集成的不同部分。這加強了跨多個終端使用的數(shù)據(jù)的可重用性。例如，原始數(shù)據(jù)只在數(shù)據(jù)倉庫中獲得一次(較少重新集成到分段中)，可以多次提供給下游需求。
• 對于每個敏捷迭代，存儲所有數(shù)據(jù)歷史軌跡的數(shù)據(jù)倉庫模型很容易擴(kuò)展，而不必?fù)?dān)心丟失歷史數(shù)據(jù)。此外，歷史軌跡是獨立于維度模型存儲的。
• Data Vault 2.0提倡業(yè)務(wù)鍵使用hash key實現(xiàn)，以減少lookups，從而增加加載并行度。這導(dǎo)致較少的順序加載依賴性
• 原始數(shù)據(jù)倉庫（ods）被設(shè)計為完全可審計的.
• 在數(shù)據(jù)倉庫中作為一個整體，從Staging到星型架構(gòu)和OLAP的處理變得更加平滑和迭代。
• 它提供了一種全面的方法，將來自異構(gòu)數(shù)據(jù)源帶有多個不同業(yè)務(wù)鍵的數(shù)據(jù)組合在一起(跨多個源系統(tǒng)在倉庫內(nèi)集成數(shù)據(jù))。業(yè)務(wù)鍵并不總是1:1或格式相同。
• “及時”建模的心態(tài)與敏捷方法非常匹配.

缺點
雖然DV優(yōu)點很多，但是其缺點也不少, 比如:

• DV 其實就是在數(shù)據(jù)集市或者星型結(jié)構(gòu)層和臨時存儲層之間的一層。在ETL開發(fā)和建模方面，開發(fā)這個層會帶來一些額外的開銷。如果項目是小規(guī)模的，或者項目的生命周期很短，那么就不值得采用數(shù)據(jù)庫模型
• 使用Data Vault背后的主要驅(qū)動因素之一是出于審計和歷史軌跡的目的。如果這些都不重要，那么將另一層引入到建模中所需要的開銷就會變得得不償失。然而，從長期的需求來看，這可能是一項值得的前期投資。
• DV代表了對關(guān)系、業(yè)務(wù)鍵和屬性的分解方法，因此與非規(guī)范化結(jié)構(gòu)(如星型模式)相比，創(chuàng)建的表的數(shù)量更多。但是，考慮到Data Vault是對星型模式的補充，所以多也只是相對的。由于這個原因，需要許多 joins 來查看DV中的數(shù)據(jù)
• 缺少大規(guī)模實際應(yīng)用案例.
• 這種建模方法，一般來說，對于那些使用Kimball和Inmon的模型的人來說是不太常規(guī)和方便的。

何時使用DV?
有幾個關(guān)鍵變量才是判斷的標(biāo)準(zhǔn)。比如，
l 我們認(rèn)為DV建模是滿足數(shù)據(jù)倉庫項目需求的一種非常可行的方法，其中歷史軌跡跟蹤和審核是兩個重要的因素。
l 此外，如果跨業(yè)務(wù)實體的關(guān)系在數(shù)據(jù)倉庫中不斷發(fā)展(例如1:M到M:M)，那么data Vault將簡化這些關(guān)系的捕獲，并更關(guān)注于交付真正的價值。
l 如果計劃在倉庫中存儲PII數(shù)據(jù)，并受GDPR、HIPPA或其他法規(guī)的約束，data Vault將幫助進(jìn)行數(shù)據(jù)審計和可追溯性
權(quán)衡DV的利弊，找到更好的適用于自身情況的建模方法才是最佳方案。