Data Vault 2.0架構(gòu)

Data Vault 2.0架構(gòu)解決了上一節(jié)定義的可擴展性和可伸縮性維度，方法是改進一個典型的三層數(shù)據(jù)倉庫架構(gòu)，這在《數(shù)據(jù)倉庫架構(gòu)》中已經(jīng)介紹過了。
正如我們在《企業(yè)數(shù)據(jù)倉庫環(huán)境》中所概述的，企業(yè)數(shù)據(jù)倉庫的主要目的是提供和顯示信息——即在上下文中聚合、匯總和合并數(shù)據(jù)。為了強調(diào)這個最終的EDW目標，我們更喜歡使用術(shù)語信息集市，而不是數(shù)據(jù)集市(這是Bl社區(qū)通常使用的術(shù)語)。

《數(shù)據(jù)倉庫架構(gòu)》中對典型架構(gòu)的其他修改包括：

• 一個集結(jié)區(qū)，它不存儲歷史信息，也不對數(shù)據(jù)進行任何更改，除非需要統(tǒng)一的數(shù)據(jù)類型。
• 基于Data Vault 建模技術(shù)的數(shù)據(jù)倉庫層。
• 依賴于數(shù)據(jù)倉庫層的一個或多個信息集市層。
• 一個可選的指標庫，用于捕獲和記錄運行時信息。
• 可選的業(yè)務(wù)倉庫，用于存儲應(yīng)用了業(yè)務(wù)規(guī)則的信息。在許多情況下，業(yè)務(wù)規(guī)則在將數(shù)據(jù)轉(zhuǎn)換為有用信息時會對數(shù)據(jù)進行轉(zhuǎn)換或更改。這是另一種信息集市。
• 可選的作業(yè)倉庫，存儲從業(yè)務(wù)系統(tǒng)輸入到數(shù)據(jù)倉庫的數(shù)據(jù)。
• 托管式自服務(wù)BI的功能允許業(yè)務(wù)用戶在不涉及IT的情況下，執(zhí)行他們自己的數(shù)據(jù)分析任務(wù)，包括將信息回寫到企業(yè)數(shù)據(jù)倉庫層。

所有可選庫(指標庫、業(yè)務(wù)數(shù)倉和作業(yè)數(shù)倉)都是Data Vault的一部分，并集成到數(shù)據(jù)倉庫層中。DataVault2.0標準中的參考架構(gòu)如圖2.2所示。

圖 2.2 DataVault2.0架構(gòu)

DataVault2.0架構(gòu)基于三層:

• 集結(jié)區(qū)，它從源系統(tǒng)收集原始數(shù)據(jù);
• 企業(yè)數(shù)據(jù)倉庫層，建模為DataVault2.0模型；
• 信息交付層，使用星型模式和其他結(jié)構(gòu)的信息集市。

這架構(gòu)既支持源系統(tǒng)的批量加載，也支持來自企業(yè)服務(wù)總線(ESB)或任何其他面向服務(wù)的架構(gòu)(SOA)的實時加載。但是也可以將非結(jié)構(gòu)化的NoSQL數(shù)據(jù)庫系統(tǒng)集成到這種架構(gòu)中。由于DataVault2.0的平臺獨立性，NoSQL可以用于每個數(shù)據(jù)倉庫層，包括集結(jié)區(qū)、企業(yè)數(shù)據(jù)倉庫層和信息交付層。因此，可以將NoSQL數(shù)據(jù)庫用作集結(jié)區(qū)，并將數(shù)據(jù)加載到關(guān)系型DataVault層中。然而，它也可以通過散列業(yè)務(wù)主鍵以上述的多種方式與數(shù)據(jù)倉庫層集成。在這種情況下，它將成為一個混合解決方案，信息集市將使用來自這兩個環(huán)境的數(shù)據(jù)。
然而，實時系統(tǒng)和NoSQL系統(tǒng)超出了本文的范圍。因此，我們將集中于架構(gòu)的關(guān)系部分。

與典型數(shù)據(jù)倉庫架構(gòu)最大的區(qū)別之一是，在構(gòu)建信息集市時強制執(zhí)行大多數(shù)業(yè)務(wù)規(guī)則，并將這些規(guī)則向最終用戶轉(zhuǎn)移。在DataVault中，硬業(yè)務(wù)規(guī)則和軟業(yè)務(wù)規(guī)則是有區(qū)別的。這個區(qū)別將在下一節(jié)中討論。

業(yè)務(wù)規(guī)則定義

在Data Vault 2.0中，我們區(qū)分了硬業(yè)務(wù)規(guī)則和軟業(yè)務(wù)規(guī)則。一般來說，業(yè)務(wù)規(guī)則修改傳入的數(shù)據(jù)以適應(yīng)業(yè)務(wù)的需求。硬業(yè)務(wù)規(guī)則和軟業(yè)務(wù)規(guī)則之間的區(qū)別是，硬業(yè)務(wù)規(guī)則是對齊數(shù)據(jù)域的技術(shù)規(guī)則，即所謂的數(shù)據(jù)類型匹配。例如，一個典型的硬業(yè)務(wù)規(guī)則是截斷比集結(jié)區(qū)表中定義的字段長度還長的源字符串。當從源系統(tǒng)提取數(shù)據(jù)并加載到集結(jié)區(qū)時，將強制執(zhí)行硬業(yè)務(wù)規(guī)則。這些業(yè)務(wù)規(guī)則只影響數(shù)據(jù)類型的實施(如字符串長度或Unicode字符)，但不轉(zhuǎn)換任何值以適應(yīng)業(yè)務(wù)的分析需求(如在美國單位和公制單位之間轉(zhuǎn)換)。硬業(yè)務(wù)規(guī)則的其他例子包括對來自大型機系統(tǒng)或XML結(jié)構(gòu)的分層COBOL copybooks進行規(guī)范化。此外，系統(tǒng)列計算也是硬業(yè)務(wù)規(guī)則的例子。根據(jù)經(jīng)驗，硬業(yè)務(wù)規(guī)則永遠不會改變傳入數(shù)據(jù)的含義，只改變存儲數(shù)據(jù)的方式。

與硬業(yè)務(wù)規(guī)則相反，軟業(yè)務(wù)規(guī)則強制執(zhí)行業(yè)務(wù)用戶聲明的業(yè)務(wù)需求。這些業(yè)務(wù)規(guī)則更改數(shù)據(jù)或數(shù)據(jù)的含義，例如通過修改粒度或解釋。例子包括數(shù)據(jù)聚合，例如將數(shù)據(jù)分配到諸如收入范圍、年齡組、客戶細分等類別中，或合并來自多個來源的數(shù)據(jù)。軟業(yè)務(wù)規(guī)則定義了如何聚合或整合數(shù)據(jù)。它們還定義如何轉(zhuǎn)換數(shù)據(jù)以滿足業(yè)務(wù)需求。

業(yè)務(wù)規(guī)則應(yīng)用

因為我們必須將源系統(tǒng)的數(shù)據(jù)類型與集結(jié)區(qū)表的數(shù)據(jù)類型對齊，所以在加載集結(jié)區(qū)時必須強制執(zhí)行硬業(yè)務(wù)規(guī)則(圖2.3)。這是在最新的執(zhí)行將數(shù)據(jù)插入到集結(jié)區(qū)表,因為數(shù)據(jù)庫管理服務(wù)器將檢查傳入的數(shù)據(jù)的類型以及觸發(fā)傳入的數(shù)據(jù)無法轉(zhuǎn)換為集結(jié)區(qū)表數(shù)據(jù)定義中指定數(shù)據(jù)類型的列的異常。例如，如果我們試圖將字母和數(shù)字組合的客戶編號插入整型的列，則會出現(xiàn)這種情況，因為我們期望類型為“integer”的客戶編號。我們可以通過向?qū)?shù)據(jù)加載到集結(jié)區(qū)的ETL數(shù)據(jù)流中添加數(shù)據(jù)類型轉(zhuǎn)換邏輯來支持這個過程。通過這樣做，我們也實現(xiàn)了硬業(yè)務(wù)規(guī)則。

圖 2.3 軟硬業(yè)務(wù)規(guī)則

硬業(yè)務(wù)規(guī)則給我們的ETL流程帶來了風險，因為如果數(shù)據(jù)違反了規(guī)則，并且沒有考慮到這種情況，那么ETL流程將停止并中斷加載過程。這與只更改數(shù)據(jù)或數(shù)據(jù)含義的軟業(yè)務(wù)規(guī)則不同。因此，我們需要區(qū)別對待硬業(yè)務(wù)規(guī)則和軟業(yè)務(wù)規(guī)則。我們通過分離這兩種規(guī)則類型來實現(xiàn)這一點。

在典型的數(shù)據(jù)倉庫系統(tǒng)中，例如前一章描述的兩層和三層數(shù)倉架構(gòu)中，軟業(yè)務(wù)規(guī)則也在數(shù)據(jù)倉庫加載過程的早期應(yīng)用。這是由于數(shù)據(jù)倉庫層要么是Kimball風格的星型模式，要么是第三范式標準的數(shù)據(jù)倉庫。為了將數(shù)據(jù)適應(yīng)到這樣的結(jié)構(gòu)中，加載的ETL數(shù)據(jù)流必須轉(zhuǎn)換數(shù)據(jù)以滿足用戶的業(yè)務(wù)需求。這種轉(zhuǎn)換對軟業(yè)務(wù)規(guī)則的實現(xiàn)有影響，包括所需的對傳入數(shù)據(jù)的聚合或合并。業(yè)務(wù)規(guī)則的早期實現(xiàn)改進了規(guī)則的通用應(yīng)用程序，并通常提高了的數(shù)據(jù)質(zhì)量。
然而，隨著對這些業(yè)務(wù)規(guī)則的更改，問題就出現(xiàn)了。在數(shù)據(jù)倉庫的架構(gòu)中實現(xiàn)業(yè)務(wù)規(guī)則的時間越早，它在數(shù)據(jù)倉庫的高層中所具有的依賴關(guān)系就越多。

考慮以下來自航空業(yè)的示例:飛機注冊號碼是飛機的標準化的字母和數(shù)字組合的標識符，在全世界范圍內(nèi)使用。每個號碼都有一個前綴，表明飛機注冊的國家。例如,注冊號“D-EBUT”
的國家是來自德國(因為前綴“D”)。來自德國的數(shù)字實際上是“智能鑰匙”，這個概念在第4章“數(shù)據(jù)倉庫建?！敝杏懈敿毜拿枋?。以注冊為“D-EBUT”的德國飛機為例，第二個字符表明該飛機是單引擎飛機。在美國，前綴“N”很常見。直到1948年12月31日，還有第二個前綴(號碼中的第二個字母)用來表示飛機的類別(見下表)。

例如，注冊號為N-X-211的飛機注冊在實驗類。
然而，美國聯(lián)邦航空局決定停止使用第二個前綴，現(xiàn)在發(fā)布的數(shù)字介于3 (NIA)和6個字符(N9999)之間，沒有任何其他含義，除了第一個前綴表示起源國家。事實上，第二個字母總是1到9之間的數(shù)字。

現(xiàn)在，考慮一下這個更改對數(shù)據(jù)倉庫的影響。如果類別已經(jīng)從(現(xiàn)在具有歷史意義的)n數(shù)字中提取出來，那么在將數(shù)據(jù)從集結(jié)區(qū)加載到規(guī)范化數(shù)據(jù)倉庫之后，第二個字母將用于標識飛機類別，其中類別很可能是aircraft表中的一列。然而，一旦號碼改變，注冊號碼的第二個位置就只有1到9之間的數(shù)字，這是沒有意義的。為了更新業(yè)務(wù)規(guī)則，最簡單的方法是引入一個新的category(“未知類別”)，如果注冊號碼中的第二個字母是1到9，就將這些飛機映射到該類別。然而，因為沒有新的飛機類別，除了未知，完全刪除這一類別是合理的(除非你專注于分析歷史上的飛機)。如果考慮到今天的飛機同時按照操作代碼、適航等級和其他類別進行分類，那么就更有意義了，因此上表中的分類已經(jīng)過時。

因此，業(yè)務(wù)規(guī)則中的此更改需要用多個新類別替換類別。在規(guī)范化數(shù)據(jù)倉庫中，我們必須刪除舊的類別列，并向飛機添加多個類別引用。在更改將數(shù)據(jù)從集結(jié)區(qū)加載到規(guī)范化數(shù)據(jù)倉庫的ETL作業(yè)之后，我們可以更改構(gòu)建在數(shù)據(jù)倉庫層之上的信息集市，并修改數(shù)據(jù)集市ETL流程。當使用這種方法時，會出現(xiàn)幾個問題

• 我們?nèi)绾翁幚硪?guī)范化數(shù)據(jù)倉庫中的歷史數(shù)據(jù)?
• 我們在哪里保存歷史數(shù)據(jù)以供以后分析(如果業(yè)務(wù)在以后需要的話)?
• 我們?nèi)绾畏治鰵v史飛機和現(xiàn)代飛機(商業(yè)決策)?
• 在同一個信息集市中會有多個維度(歷史類和現(xiàn)代類)，還是會有多個歷史類和現(xiàn)代類飛機的信息集市?
• 現(xiàn)代飛機歷史類別的默認值是什么?
• 古代飛機的現(xiàn)代類別的默認值是什么?

在DataVault2.0架構(gòu)中，飛機的分類將被加載到一個名為“衛(wèi)星”的表中，該表包含描述性數(shù)據(jù)(我們將在后續(xù)文章詳細解釋DataVault2.0建模的基本實體)。當源系統(tǒng)中的邏輯發(fā)生變化時——在本例中是N-Number的格式——舊的衛(wèi)星就關(guān)閉了(沒有新數(shù)據(jù)加載到當前衛(wèi)星中)。所有新數(shù)據(jù)都被加載到一個新的衛(wèi)星上，該衛(wèi)星的結(jié)構(gòu)經(jīng)過了更新，符合源數(shù)據(jù)的結(jié)構(gòu)。在此過程中，沒有實現(xiàn)業(yè)務(wù)規(guī)則。加載了所有的數(shù)據(jù)。因為現(xiàn)在有兩張表，一個保存歷史數(shù)據(jù)，另一個保存新數(shù)據(jù)，在將數(shù)據(jù)從DataVault加載到信息集市時很容易實現(xiàn)業(yè)務(wù)規(guī)則。建立一個用于分析歷史上的老飛機的信息集市和另一個用于分析1948年以后建造的現(xiàn)代飛機的信息集市也很容易。

但是，當考慮到需要調(diào)整以適應(yīng)新的分類的ETL工作時，分離硬規(guī)則和軟規(guī)則的真正優(yōu)勢就變得清晰起來。加載歷史數(shù)據(jù)的ETL作業(yè)保持不變，并準備加載更多的歷史數(shù)據(jù)(例如，重新加載歸檔的平面文件)。新數(shù)據(jù)被加載到另一個目標(第二個衛(wèi)星)，因此是“歷史”ETL流程的修改副本。除了信息集市(及其加載流程)，其他都不需要更改。

集結(jié)區(qū)

集結(jié)區(qū)用于將批處理數(shù)據(jù)加載到數(shù)據(jù)倉庫中。它的主要目的是從源系統(tǒng)中盡可能快地提取源數(shù)據(jù)，以減少業(yè)務(wù)系統(tǒng)的工作負載。此外，集結(jié)區(qū)允許對源數(shù)據(jù)執(zhí)行SQL語句，這可能不適用于直接訪問平面文件(如CSV文件或Excel表)。

注意，集結(jié)區(qū)不包含歷史數(shù)據(jù)，這與前一章中描述的傳統(tǒng)架構(gòu)不同。取而代之的是，集結(jié)區(qū)中只存在下一個必須加載到數(shù)據(jù)倉庫層的批處理。但是，這條規(guī)則有一個例外:如果有多個批處理需要加載，例如，當周末發(fā)生錯誤時，必須將過去幾天的數(shù)據(jù)加載到數(shù)據(jù)倉庫中，在集結(jié)區(qū)可能有多個批處理。在集結(jié)區(qū)中沒有歷史記錄的主要目的是不必處理不斷變化的數(shù)據(jù)結(jié)構(gòu)?？紤]這樣一個事實:源表可能會隨著時間的推移而改變。如果集結(jié)區(qū)保存了歷史數(shù)據(jù)，這里必須有用于將加載過程定義到數(shù)據(jù)倉庫的邏輯。這個邏輯(實際上是業(yè)務(wù)規(guī)則)將隨著時間的推移變得越來越復(fù)雜。正如我們在前一節(jié)中所描述的，Data Vault 2.0架構(gòu)的目標是將復(fù)雜的業(yè)務(wù)規(guī)則移動到最終用戶，以確?？焖龠m應(yīng)更改。

集結(jié)區(qū)由復(fù)制源系統(tǒng)結(jié)構(gòu)的表組成。這包括源的所有表和列，包括主鍵。但是，用于確保源系統(tǒng)中引用完整性的索引和外鍵是不重復(fù)的。此外，所有列都是可為空的，因為我們希望允許數(shù)據(jù)倉庫從源系統(tǒng)加載原始數(shù)據(jù)，包括可能存在于源系統(tǒng)中的壞數(shù)據(jù)(特別是平面文件)。應(yīng)用于傳入數(shù)據(jù)的唯一業(yè)務(wù)規(guī)則是所謂的硬業(yè)務(wù)規(guī)則。通常的做法是保留源系統(tǒng)中用于命名表和列的原始名稱;然而，這不是必須的。

除了源系統(tǒng)中的列之外，集結(jié)區(qū)中的每個表還包括:

• 一個序列號
• 一個時間戳
• 記錄源
• 所有業(yè)務(wù)鍵及其組合的散列鍵計算

這些字段是將數(shù)據(jù)加載到下一層(數(shù)據(jù)倉庫層)所需的元數(shù)據(jù)信息。序列號標識源系統(tǒng)中數(shù)據(jù)的順序。當源系統(tǒng)中的順序?qū)τ趯?shù)據(jù)加載到數(shù)據(jù)倉庫很重要時，我們可以使用它，例如RSS新聞訂閱或不包含時間戳信息的事務(wù)性數(shù)據(jù)。時間戳是記錄到達數(shù)據(jù)倉庫時的日期和時間。記錄源表示產(chǎn)生數(shù)據(jù)記錄的源系統(tǒng)，散列鍵用于標識目的。后續(xù)文章將提供這些字段的詳細描述。

數(shù)據(jù)倉庫層

DataVault2.0架構(gòu)中的第二層是數(shù)據(jù)倉庫，它的目的是保存所有歷史的、時變的數(shù)據(jù)。

數(shù)據(jù)倉庫保存原始數(shù)據(jù)，除硬業(yè)務(wù)規(guī)則外，其他任何業(yè)務(wù)規(guī)則都不會修改這些數(shù)據(jù)。因此，數(shù)據(jù)是以源系統(tǒng)提供的粒度存儲的。數(shù)據(jù)是非易失的，源系統(tǒng)中的每個更改都由數(shù)據(jù)倉庫結(jié)構(gòu)來追蹤。來自多個源系統(tǒng)的數(shù)據(jù)，以及一個源系統(tǒng)中的數(shù)據(jù)，通過業(yè)務(wù)鍵進行集成，在后續(xù)文章進行討論。與信息集市中面向主題的信息不同，數(shù)據(jù)倉庫中的數(shù)據(jù)是面向功能的。

在批量加載中，數(shù)據(jù)從集結(jié)區(qū)提供，而在實時加載中，數(shù)據(jù)直接從企業(yè)服務(wù)總線(ESB)或微服務(wù)等SOA架構(gòu)中提供到數(shù)據(jù)倉庫。然而，如前所述，實時數(shù)據(jù)倉庫超出了本文的范圍。我們將在后續(xù)文章介紹業(yè)務(wù)數(shù)據(jù)的加載，它也直接應(yīng)用于數(shù)據(jù)倉庫，并遵循類似的模式。
數(shù)據(jù)倉庫層是在DataVault2.0建模技術(shù)的基礎(chǔ)上建模的，該技術(shù)將在后續(xù)文章討論。
這一層通常稱為原始DataVault層，因為它包含使用Data Vault 2.0模型建模的原始數(shù)據(jù)。

信息集市層

與傳統(tǒng)的數(shù)據(jù)倉庫不同，DataVault2.0架構(gòu)的數(shù)據(jù)倉庫層不是由終端用戶直接訪問的。通常，終端用戶只訪問以終端用戶最喜歡的方式提供數(shù)據(jù)的信息集市。因為企業(yè)數(shù)據(jù)倉庫的目標是向其最終用戶提供有價值的信息，所以我們在這一層使用術(shù)語信息而不是數(shù)據(jù)。信息集市中的信息是面向主題的，可以是聚合表單、平面文件或?qū)挶恚部梢允菫閳蟾孀鰷蕚涞臄?shù)據(jù)，還可以是高度索引的、冗余的和質(zhì)量清洗后的數(shù)據(jù)。它通常遵循星型模式，并形成關(guān)系型報告和多維OLAP立方體的基礎(chǔ)。因為最終用戶只訪問信息集市層，在數(shù)據(jù)倉庫層中擁有DataVault模型對最終用戶來說是透明的。如果最終用戶需要第三范式的規(guī)范化數(shù)據(jù)倉庫，我們也可以提供滿足這些需求的信息集市。前端工具還能夠?qū)⑿畔⒒貙懙?strong>企業(yè)數(shù)據(jù)倉庫層。

信息集市的其他示例包括異常信息集市和元數(shù)據(jù)集市。它們分別是數(shù)據(jù)倉庫的異常信息中心和元數(shù)據(jù)中心。作為這些數(shù)據(jù)的中心也是與標準信息集市不同的特殊集市:
與信息集市不同的是，異常信息集市和元數(shù)據(jù)集市不能從原始數(shù)據(jù)倉庫或任何其他數(shù)據(jù)源重建。然而,他們是相似的,因為最終用戶,如管理員,使用這些集市分析加載過程中的異?；?strong>數(shù)據(jù)倉庫中的其他問題,或數(shù)據(jù)倉庫的元數(shù)據(jù)存儲,它的來源和轉(zhuǎn)化主導(dǎo)了信息集市中呈現(xiàn)的信息。后續(xù)文章《加載維度信息集市》，提供了關(guān)于如何從DataVault2.0結(jié)構(gòu)的數(shù)據(jù)倉庫中加載維度OLAP立方體的信息集市的廣泛討論

指標庫

在Data Vault 2.0架構(gòu)中，前面的三個層（集結(jié)區(qū)、數(shù)據(jù)倉庫層和信息集市）是必需的（除了本書中覆蓋到的實時案例），指標庫（本節(jié)中介紹），業(yè)務(wù)倉庫（見下節(jié)）和作業(yè)倉庫（見第下下節(jié)）是Data Vault 2.0架構(gòu)的可選擴展。

指標庫用于捕獲和記錄運行時信息，包括運行歷史、進程指標和技術(shù)指標，如CPU負載、RAM使用、磁盤IO指標和網(wǎng)絡(luò)吞吐量。與數(shù)據(jù)倉庫類似，指標庫是按照Data Vault 2.0建模技術(shù)建模的。數(shù)據(jù)是原始格式，系統(tǒng)或過程驅(qū)動，不可審計，它可能包括技術(shù)元數(shù)據(jù)和ETL作業(yè)的技術(shù)指標或數(shù)據(jù)倉庫的環(huán)境。在指標庫的頂部，指標集市向用戶提供了性能指標信息。

后續(xù)文章《元數(shù)據(jù)管理》包括一個示例，說明如何在ETL加載數(shù)據(jù)期間跟蹤審計信息，并將數(shù)據(jù)存儲到指標庫中。

業(yè)務(wù)倉庫

由于應(yīng)用于Data Vault 2.0結(jié)構(gòu)的一些業(yè)務(wù)規(guī)則往往會變得復(fù)雜，可以選擇將業(yè)務(wù)倉庫結(jié)構(gòu)添加到數(shù)據(jù)倉庫層。業(yè)務(wù)倉庫是一個基于Data Vault 設(shè)計原則的稀疏建模數(shù)據(jù)倉庫，但包含業(yè)務(wù)規(guī)則更改的數(shù)據(jù)。換句話說，業(yè)務(wù)倉庫中的數(shù)據(jù)已經(jīng)被業(yè)務(wù)規(guī)則更改。在大多數(shù)情況下，業(yè)務(wù)倉庫是原始Data Vault和信息集市之間的中間層，可以簡化最終用戶結(jié)構(gòu)的創(chuàng)建
圖2.4顯示了Data Vault企業(yè)數(shù)據(jù)倉庫之上的業(yè)務(wù)倉庫。

圖 2.4 Data Vault企業(yè)數(shù)據(jù)倉庫之上的業(yè)務(wù)倉庫

這是因為業(yè)務(wù)倉庫是在加載信息集市之前預(yù)加載的，從而簡化了它們的加載過程。復(fù)雜的業(yè)務(wù)規(guī)則(軟規(guī)則)從原始數(shù)據(jù)倉庫和業(yè)務(wù)倉庫實體中獲取數(shù)據(jù)。

雖然業(yè)務(wù)倉庫是按照Data Vault 2.0設(shè)計原則建模的，但它對源數(shù)據(jù)的可審核性沒有相同的要求。相反，可以在任何時候從原始Data Vault刪除并重新生成業(yè)務(wù)倉庫。業(yè)務(wù)倉庫為輸入數(shù)據(jù)到信息集市的開發(fā)人員提供原始Data Vault中的數(shù)據(jù)的整合視圖。

與指標庫類似，業(yè)務(wù)倉庫不存儲在單獨的層中。相反，它存儲為數(shù)據(jù)倉庫層中的Data Vault模型的擴展。后續(xù)文章《加載維度信息集市》，展示了如何使用業(yè)務(wù)倉庫來輸入數(shù)據(jù)到信息集市。

作業(yè)倉庫

作業(yè)倉庫是DataVault的擴展，業(yè)務(wù)系統(tǒng)可以直接訪問DataVault(圖2.5)。有時，這樣的系統(tǒng)需要從企業(yè)數(shù)據(jù)倉庫中檢索數(shù)據(jù)，或者需要將數(shù)據(jù)寫回數(shù)據(jù)倉庫。示例包括主數(shù)據(jù)管理(MDM)系統(tǒng)，如微軟的主數(shù)據(jù)服務(wù)(MDS)或元數(shù)據(jù)管理系統(tǒng)。在這兩種情況下，直接在數(shù)據(jù)倉庫層上操作而不是使用信息集市或集結(jié)區(qū)都具有優(yōu)勢。其他情況包括直接分析存儲在數(shù)據(jù)倉庫層中的原始數(shù)據(jù)的數(shù)據(jù)挖掘應(yīng)用程序。通常，每當接口應(yīng)用程序需要實時支持時，無論是讀還是寫，直接訪問作業(yè)倉庫都是最佳選擇。

圖2.5 作業(yè)倉庫

因此，集成來自面向服務(wù)架構(gòu)(SOA)或企業(yè)服務(wù)總線(ESB)的實時數(shù)據(jù)將直接寫入作業(yè)倉庫。雖然我們在本節(jié)的開頭將作業(yè)倉庫定義為DataVault的擴展，但應(yīng)用程序的接口直接從現(xiàn)有的DataVault結(jié)構(gòu)中實現(xiàn)。因此，DataVault結(jié)構(gòu)在某種程度上成為作業(yè)倉庫結(jié)構(gòu)。

托管式自助服務(wù)BI

數(shù)據(jù)倉庫項目的一個常見經(jīng)驗是，在數(shù)據(jù)倉庫計劃取得初步成功之后，業(yè)務(wù)對功能的需求越來越大。但是，由于IT團隊資源有限，不是企業(yè)的所有請求都可以滿足。在許多情況下，所請求的功能只對有限數(shù)量的業(yè)務(wù)用戶重要或適用，或者對業(yè)務(wù)的影響很小。然而，它對那些要求它的人來說很重要。但是為了使用他們自己的IT資源，IT必須對他們的請求進行優(yōu)先級排序。由于延遲或完全丟棄新功能的影響。這種對業(yè)務(wù)請求的低響應(yīng)增加了業(yè)務(wù)用戶的不舒適感。
一種稱為自助服務(wù)BI的方法允許終端用戶完全繞過它，因為它沒有響應(yīng)。在這種方法中，業(yè)務(wù)用戶可以自己處理從業(yè)務(wù)系統(tǒng)獲取數(shù)據(jù)、集成和整合原始數(shù)據(jù)的整個過程。這種缺乏IT參與的自助服務(wù)方法存在許多問題:

• 直接訪問源系統(tǒng) : 最終用戶不應(yīng)該直接訪問源系統(tǒng)中的數(shù)據(jù)。這將公開潛在私有的原始數(shù)據(jù)，并且允許訪問該數(shù)據(jù)可能會繞過安全訪問，而安全訪問是在訪問控制列表(ACL)中實現(xiàn)的。
• 未集成的原始數(shù)據(jù) : 當從多個源系統(tǒng)獲取數(shù)據(jù)時，業(yè)務(wù)用戶將獨自處理原始數(shù)據(jù)集成。如果手動執(zhí)行(例如在Excel中)，這將成為一項乏味且容易出錯的任務(wù)。
• 低數(shù)據(jù)質(zhì)量 : 來自源系統(tǒng)的數(shù)據(jù)經(jīng)常存在數(shù)據(jù)質(zhì)量方面的問題。在使用數(shù)據(jù)進行分析之前，需要對其進行清洗。同樣，如果沒有正確的工具，這可能成為最終用戶的負擔。
• 未整合的原始數(shù)據(jù):為了分析來自多個源系統(tǒng)的數(shù)據(jù)，數(shù)據(jù)通常需要整合。如果沒有這種整合，業(yè)務(wù)分析的結(jié)果將毫無意義。
• 非標準化業(yè)務(wù)規(guī)則:因為最終用戶在自助服務(wù)BI中只處理原始數(shù)據(jù)，所以他們必須實現(xiàn)將原始數(shù)據(jù)轉(zhuǎn)換為有意義的信息的所有業(yè)務(wù)規(guī)則。但是誰來檢查這個實現(xiàn)是否與組織的其他部分一致呢?

在許多情況下，最終用戶——即使他們是掌握SQL、MDX和其他技術(shù)的高級用戶——也沒有可用的正確工具來解決這些任務(wù)。相反，很多工作都是手工完成的，而且很容易出錯。

但是根據(jù)我們的經(jīng)驗，完全阻止這樣的高級用戶從源系統(tǒng)獲取數(shù)據(jù)、準備數(shù)據(jù)并最終將數(shù)據(jù)報告給上層管理是不可能的。組織需要的是IT敏捷性和數(shù)據(jù)管理之間的妥協(xié)，允許高級用戶以可用的質(zhì)量快速獲取他們需要的數(shù)據(jù)。

為了克服這些問題，Data Vault 2.0標準允許有經(jīng)驗或高級業(yè)務(wù)用戶對數(shù)據(jù)倉庫的原始數(shù)據(jù)執(zhí)行自己的數(shù)據(jù)分析任務(wù)。實際上，支持Data Vault 2.0的IT歡迎業(yè)務(wù)用戶使用企業(yè)數(shù)據(jù)倉庫(原始Data Vault或業(yè)務(wù)倉庫)中可用的數(shù)據(jù)，并使用自己的工具將數(shù)據(jù)轉(zhuǎn)換為有意義的信息。這是因為IT無法在給定的時間范圍內(nèi)交付所請求的功能。

取而代之的是，IT從業(yè)務(wù)系統(tǒng)或其他數(shù)據(jù)源獲取原始數(shù)據(jù)，并使用原始數(shù)據(jù)庫的業(yè)務(wù)鍵將其集成。IT還可能創(chuàng)建業(yè)務(wù)倉庫結(jié)構(gòu)，以提供模型各部分的統(tǒng)一視圖或預(yù)計算關(guān)鍵性能指標(KPIs)，以確保這些計算之間的一致性。

然后，業(yè)務(wù)用戶使用原始數(shù)據(jù)(來自原始DataVault)和業(yè)務(wù)數(shù)據(jù)(來自業(yè)務(wù)倉庫)使用專用工具創(chuàng)建本地信息集市。這些工具從企業(yè)數(shù)據(jù)倉庫檢索數(shù)據(jù)，應(yīng)用一組用戶定義的業(yè)務(wù)規(guī)則，并將輸出顯示給最終用戶。

這種方法稱為托管式自助服務(wù)BI，是Data Vault 2.0標準的一部分。在這種方法中，它發(fā)展為一個服務(wù)組織，為那些高級用戶在他們需要的時間范圍內(nèi)提供他們想要的數(shù)據(jù)。數(shù)據(jù)由業(yè)務(wù)鍵集成，如果最終用戶需要，還可以進行整合和質(zhì)量檢查。整合和質(zhì)量檢查發(fā)生在進入業(yè)務(wù)倉庫的過程中，正如我們將在本書后面說明的那樣。業(yè)務(wù)倉庫還實現(xiàn)了一些最重要的業(yè)務(wù)規(guī)則。高級用戶可以直接訪問原始Data Vault和業(yè)務(wù)倉庫，并且可以根據(jù)手頭的任務(wù)選擇原始數(shù)據(jù)或經(jīng)過整合、清洗的數(shù)據(jù)。實際上，這兩種類型的數(shù)據(jù)都已經(jīng)集成了，因此業(yè)務(wù)用戶還可以將合并后的數(shù)據(jù)與來自特定源系統(tǒng)的原始數(shù)據(jù)連接起來。

后續(xù)文章將演示將原始數(shù)據(jù)加載到原始Data Vault是非常容易的，包括使用業(yè)務(wù)鍵進行集成。事實上，它可以在短的沖刺迭代中完成，我們將在《Data Vault 2.0方法論》中解釋。當用戶要求更多數(shù)據(jù)，而數(shù)據(jù)倉庫中無法提供這些數(shù)據(jù)時，可以將這些數(shù)據(jù)獲取并集成到原始Data Vault中，以便為高級用戶提供托管式自助服務(wù)BI任務(wù)。

其他特性

Data Vault 2.0架構(gòu)提供了額外的功能，以支持實時(RT)和近實時(NRT)環(huán)境、非結(jié)構(gòu)化數(shù)據(jù)和NoSQL環(huán)境。然而，對這些選項的描述超出了本博客的范圍。

本文介紹了Data Vault 2.0架構(gòu)，它是Data Vault 2.0架構(gòu)標準中的一項基本內(nèi)容。接下來的文章將著重于項目方法論和Data Vault 建模，這是Data Vault 2.0架構(gòu)標準的另外兩個基本支柱。