資料虛擬化環境設計步驟分解

寫在前面：

資料虛擬化設計思想是敏捷大資料理念的重要組成部分，敏捷大資料團隊也研發並推出了資料虛擬化開源實現—計算服務平臺Moonbox。為了讓大家更加了解資料虛擬化技術，我們會陸續推薦並翻譯一些精品文章。歡迎大家一起交流探討。

本文譯自“Designing a Data Virtualization Environment - A Step-By-Step Approach”（by Rick F。 van der Lans），介紹如何利用Red Hat基於社群專案Teiid的JBoss資料虛擬化伺服器，逐步設計出資料虛擬化環境。希望本文會對大家使用開源計算服務平臺Moonbox有一定的啟發作用~

一、摘要

本文介紹了一種基於社群專案Teiid，利用Red Hat JBoss資料虛擬化（JDV）伺服器逐步構建資料虛擬化環境的方法。文中包括一些注意事項和設計準則，幫助企業組織開發有效且高效的資料虛擬化環境。

文中所推薦的設計架構包含四層檢視（views）：

虛擬基礎層

檢視，負責接入儲存在源系統中的資料，與資料質量有一定關係。

企業資料層

檢視，提供所有源系統資料的一個整合檢視。

共享規範層

檢視，包含共享規範，避免資料消費檢視中出現重複或者相互矛盾的規範。

資料消費層

檢視，簡化資料消費者的資料訪問。

此外，本文還推薦採用縱向設計和開發的方式，即在本層中確定少量檢視之後，就可以開始定義下一層檢視。縱向設計方式非常適合當前快速迭代開發的敏捷設計技術；同時，它還適用於現代資料倉庫，現代數倉的要求便是更快地開發以及更快的更改現有報表。

開發一個新的JDV環境或者改變現有的JDV環境包括以下步驟：

1。設計並實現虛擬基礎層

2。設計並實現企業資料層

3。設計並實現共享規範層

4。設計並實現資料消費層

5。設計並實現自助使用檢視

6。設計並實現資料質量管理檢視

7。最佳化效能

我們並不是要逐個執行實施這7步，而是要把其看做一個快速迭代的過程。

注：Red Hat JBoss 資料虛擬化（JDV），是一種資料供應和整合解決方案，它處於多個數據源的前端，並將這些資料來源作為單個數據源進行處理，以符合業務需求的形式、在正確的時間，向任意應用程式或使用者提供所需資料。

參考：https：//www。redhat。com/zh/technologies/jboss-middleware/data-virtualization

二、資料虛擬化解決方案的總體架構

條條大路通羅馬。同樣，設計開發JDV環境也有許多方法。但無論採用哪種方法，我們始終推薦至少包含四層檢視的分層架構（見圖1）。

圖1 包含四層檢視的JDV環境

虛擬基礎層連結到源系統，如SQL和NoSQL資料庫，基於SOAP / REST的服務，雲應用程式以及JSON或XML格式的檔案等。虛擬基礎層還負責運用清洗規則，提高資料質量。資料消費者（應用程式、報表和使用者）透過訪問資料消費層檢視來檢索資料，所有層都參與轉換和重組資料以滿足資料消費者的需求。

在這個架構中，每一個檢視層都有自己的作用（從底層開始）：

虛擬基礎層（Virtual Base Layer）：

虛擬基礎層中的檢視包含儲存在源系統中的資料。我們為源系統中的每個物理表或檔案都建立一個檢視，每個檢視定義都可能包含清洗規範，從而提高源系統資料的質量。除了修正資料之外，這層檢視的虛擬內容與源系統的內容相同。

企業資料層（Enterprise Data Layer）：

第二層的檢視提供了源系統中所有資料的整合檢視，因此稱為企業資料層。每個檢視的結構都是“中性的”，換句話說，它不針對某個資料消費者的需求，而是支援儘可能多的使用形式。如果可能的話，每個檢視都根據第三正規化構建。

共享規範層（Shared Specifications Layer）：

為避免資料消費檢視中存在太多重複或可能相互矛盾的規範，第三層主要包含共享規範。共享規範層存在的目的是避免重複規範，構建儘可能敏捷的環境。共享規範層也可以包含授權規範（允許誰使用哪個檢視）。

資料消費層（Data Consumption Layer）：

資料消費層每個檢視的結構側重於簡化資料消費者的資料訪問。例如，某些資料消費者希望將資料組織為星型模式，而另外一些資料消費者則希望能夠在一個包含大量列的檢視中檢視所需的所有資料。在資料消費層指定過濾、對映、轉換和聚合等操作，僅向資料消費者展示他們所需的相關資料。

圖1還展示了檢視的三種使用場景，或者說是使用形式：傳統使用形式、自助使用形式以及管理使用形式：

傳統使用形式涉及資料消費者對檢視的重複使用，這些檢視由技術人員設計、開發、測試和管理。在傳統的使用形式中，每個檢視通常都有多個數據消費者使用，其虛擬內容的資料質量十分重要。

自助使用形式所涉及的檢視由使用者自己而非技術人員開發。特別是在商業智慧領域，報表的自助開發非常流行，其中比較知名的工具有Qlikview、Tableau和Tibco Spotfire。透過允許使用者開發自己的檢視，工具自身的自助功能也得以擴充套件。

管理使用形式涉及的檢視由負責資料管理方面（如資料質量和使用）的技術人員開發併為他們所用。例如，有的管理檢視可以顯示具有錯誤資料值的記錄，有的則可以顯示資料消費者在一段時間裡使用的不同檢視。

三、自下而上，自頂向下還是由內及外？

設計開發這四個檢視層有幾種方法：自下而上，自頂向下和由內及外（見圖2）。

自下而上的設計方法（Bottom‐up approach）：

採用自下而上的設計方法，以源系統的結構為起點，設計出符合資料消費者需求的檢視：首先開發虛擬基礎層，然後是企業資料層，接下來是共享規範層，最後是資料消費層。自下而上設計方法的挑戰來自於源系統的結構：源系統資料結構的設計通常是為了儘可能有效且高效地支援它們自己的應用程式；另外，有些結構是很久以前設計的，經過多次調整，隨著時間的推移變得有些非結構化。自下而上的設計方法可能會導致頂層檢視的結構更多的受源系統資料結構的影響，而不是根據資料消費者需求而設計。

自頂向下的設計方法（Top‐down approach）：

採用自頂向下的設計方法，首先要分析資料消費者的資訊需求，從而在資料消費層上開發一組檢視。接下來，開發共享規範層、企業資料層和虛擬基礎層的檢視，使資料消費層上的檢視起作用。因此，這些層是按照從頂層到底層的順序設計的，是一種非常實用的方法，資料消費者可以快速訪問資料。這種設計方法的風險在於，最終整個環境會產生許多重複或相似的規範，難以組織規範共享，從長遠來看，這會降低整個JDV環境的潛在敏捷性。

由內及外的設計方法（Inside‐out approach）：

採用由內及外的設計方法，首先要設計的是企業資料層。定義企業資料層的檢視結構時要儘可能中性（neutral），最大限度的支援資料消費者需求。接下來，定義虛擬基礎層上的檢視，將檢視根據一對一對映到物理表；企業資料層的檢視要對映到虛擬基礎層的檢視上。最後，定義資料消費層的檢視。這些檢視的結構完全是針對資料消費者的需求而設計。由內及外是首選的設計方法，但在現實工作中，專案開發人員有時會因為種種原因而採用另外兩種方法，或單獨使用，或組合在一起。

圖2 設計開發JDV環境的三種方法

四、縱向設計？橫向設計？

除了在上一節的三種檢視設計方法中做出選擇，我們還需要決定採用縱向設計方法還是橫向設計方法（見圖3）。橫向設計方法指在設計下一層檢視之前，本層的設計和開發應全部完成；縱向設計方法指在設計下一層檢視之前，在本層中只需定義少量檢視。如果我們使用“迭代”這個術語來形容，採用縱向設計方法，迭代週期會非常之短，而採用橫向設計方法，迭代週期可能會非常長。

圖3 圖左為橫向設計方法，圖右為縱向設計方法

採用橫向設計方法，在設計下一個檢視層之前，要完成本層檢視的設計開發。橫向設計方法與企業級方式及“瀑布模型”設計技術相一致，其優點在於更容易得到一組不包含冗餘規範或冗餘規範最小化的檢視。

採用縱向設計方法，在設計下一層檢視之前，在本層中只需定義少量檢視。縱向設計方法非常適合當前快速迭代開發的敏捷設計技術。此外，它還適用於現代資料倉庫，現代數倉的要求是能夠更快地開發，更快地更改現有報表。縱向設計方法的總體優勢是：高生產率和敏捷的解決方案。如果使用者需要來自某個源系統的資料，採用縱向設計可以在最短的時間內定義所需檢視。換句話說，縱向設計的反應時間很短。在不考慮與其他系統整合問題的情況下，採用縱向設計方法來開發一份報表只需要幾天或幾周，而不是幾個月。在大多數資料虛擬化專案中，縱向設計方法都因其敏捷性而倍受青睞。

五、樣例資料庫

從下一節開始，我們會介紹逐步設計和開發資料虛擬化環境的方法，其中會用到許多例子來詳細解釋步驟。本文的例子選自同一個樣例資料庫，它是一家虛擬線上零售公司的產品資料庫，公司名為World Class Movies（WCM），提供影片出售和租賃服務。該資料庫由一組表組成，表用來記錄顧客資訊以及銷售和租賃資訊。

這個資料庫是Roland Bouman和Jos van Dongen為他們的書“Pentaho Solutions： Business Intelligence and Data Warehousing with Pentaho and MySQL”所設計。此外，“Data Virtualization for Business Intelligence Systems”一書中也使用了該資料庫。本文僅採用了圖4資料模型中所顯示的表。

圖4 WCM樣例資料庫的資料模型

六、Step 1：設計並實現虛擬基礎層

匯入源系統

在第一層中，迭代所需的所有源系統都要被匯入JDV，這裡的匯入指的是匯入源系統的技術規範。源系統可以是基於SQL的生產系統、資料倉庫和資料集市，利用Hadoop， NoSQL資料庫伺服器開發的非基於SQL的系統，包含JSON/XML格式資料的外部檔案，甚至是電子表格。相對於大多數源系統來說，第一步的匯入是相對簡單的。

非SQL系統則需要定義非關係型資料結構如何對映到平面關係檢視中（通常稱為資料扁平化）。

伴隨著匯入源系統的這個過程，產生了所謂的“源表”。在JDV中，源表只是源資料的副本，其內容與底層源系統的內容相同。

利用資料虛擬化清洗資料的不同之處

源系統中儲存的資料並不總是正確的：名稱拼寫錯誤，數值超出實際邊界，兩個欄位中的值互換位置，儲存值不符合實際，特定值或特定行完全丟失等。如果不採取任何措施，JDV就會向資料消費者提供錯誤資料，最終資料消費者根據錯誤資料做出業務決策。

在傳統的資料倉庫環境中，我們使用ETL指令碼將資料從源系統複製到資料倉庫和資料集市，可以在這些ETL指令碼中執行一些規則來檢測錯誤資料。這樣做的結果就是正確的資料被複制到資料倉庫，而錯誤資料被複制到一個單獨的資料儲存（垃圾箱）中。之後，我們透過研究這個垃圾箱裡的資料，決定如何處理這些錯誤資料。是應該執行更多轉換規則，還是應該告知擁有這些資料的人其資料的不正確性，並要求更正？

這種處理錯誤資料的方式不適用於資料虛擬化伺服器。當我們按需轉換時，每個對映只有一個結果，並且此結果會返回給資料消費者。換句話說，資料虛擬化伺服器中沒有上文提到的“垃圾箱”來暫存錯誤資料。因此，JDV中執行資料清洗的方式是不同的。

要清洗資料，先要指定規則。由於在源表中無法指定過濾、轉換和投影操作，因此必須在源表之上定義一層檢視；每個源表都需要一個檢視（見圖5）。這些檢視包括的清洗規則是，把來自於源系統的資料清洗完畢之後，再傳遞到下一層。因此，從技術上講，虛擬基礎層由兩層表格組成：第一層是從可用源系統中提取資料的源表，第二層是為每個源表設計的包含清洗規則的檢視。

圖5 在源系統上定義源表，為每個源表定義一個包含資料清洗規範的檢視

注意：這裡假設虛擬基礎層中定義的檢視進行所有的資料清洗處理。但是，我們建議儘量將更多的資料清洗規則下推到源系統中進行，儘可能地靠近源。

資料清洗的五種方法

下面我們介紹處理錯誤資料，在檢視中定義清洗規則的五種方法：

Nothing（無任何操作）：不在檢視中新增任何邏輯來檢測錯誤資料，且錯誤資料未經修正直接返回給資料消費者。在這種情況下，資料消費者負責檢測錯誤資料並確定如何處理。從JDV的角度來考慮，這是最簡單的方法，但就決策質量而言，這並不是首選方法。

Filtering of rows（行過濾）：行過濾指的是將清洗規則新增到虛擬基礎層的檢視定義中，從而過濾掉錯誤資料。檢視內容中包含一個或多個錯誤值的行都會被移除。最終資料消費者只能看到所有資料都正確的行。

Filtering of values（值過濾）：另一種過濾方法是值過濾，即如果檢測到某一行中的值不正確，該行仍保留在檢視內容中，但該錯誤值會被刪除，用空值或特殊程式碼代替，表示原始值不正確並已被替換。

Flagging（做標記）：做標記的方法是指在檢視中新增一個額外的列（在源表中無法使用），該列包含指示錯誤值的程式碼。這個額外新增列中的程式碼稱為“標記”。例如，新增列中可以有這樣的值：NAM和CIT，它們表示NAME和CITY列中有不正確的值。每個保留有錯誤資料的列都可以新增單獨的標記列。資料消費者來決定如何處理標記和資料。

Restoring（還原）：以上四種方法都不會修正錯誤資料。用正確的值替換不正確的值稱為還原。還原邏輯可以新增到虛擬基礎層的檢視定義中。

本節後半部分介紹後面四種清洗方法的檢視定義示例。

★

透過過濾資料來清洗資料

如上所述，存在兩種過濾方式：一個是過濾掉行，一個是過濾掉單個的值。通常，行過濾是更容易實現的。檢視定義中的清洗規則當做過濾器使用。

例1：以下規則適用於樣例資料庫的CUSTOMER_ORDER表：ORDER_TIMESTAMP列中的日期值都必須在1999年12月31日之後，因為該公司是在此日期之後成立的。以下是CUSTOMER_ORDER表上檢視的定義，此規則當做過濾器使用：

說明：所有包含1999年12月31日之前日期值的行都已經從檢視內容中移除了，因此資料消費者看不到這些行。

在檢視定義中很多規則都可以當做過濾器使用，如下一個示例所示。

例2：以下規則適用於DVD_RELEASE表：RATING的值X不正確，ASPECT列不能包含值LBX和VAR，STATUS列的值必須等於Cancelled， Discontinued， Out， Pending， Postponed或者Recalled中的一種。

下表顯示了CUSTOMER表中不屬於VT1_DVD_RELEASE_CHECKED檢視內容的某些行和列：

除了行過濾，我們還可以過濾掉單個的值，結果中會保留所有行，但是錯誤值會被移除，並用特殊值來代替。

例3：在ORDER_TIMESTAMP列中執行例1中指定的規則，使其作為過濾器執行。

說明：如果ORDER_TIMESTAMP的值在1999年12月31日之前，可以用空值代替，也可以選擇其他值。這個檢視的內容包括底層表的所有行。

例4：執行例2中指定的3條規則，使其作為過濾器執行。

下表顯示了這個檢視內容中的一些行和列：

說明：移除STATUS， RATING和ASPECT列中的錯誤值，插入空值。

★

透過標記資料來清洗資料

在不同的列中標記出錯誤值和過濾單個的值類似，其規則的執行方式也相同。

例5：定義一個檢視，執行例1中的規則，但是這裡使用的是標記的方法。

說明：此檢視的虛擬內容包括含有未轉換值的ORDER_TIMESTAMP列，以及名為ORDER_TIMESTAMP_FLAG的新列。值過濾和標記之間的本質區別在於，前者刪除了錯誤值，後者錯誤值仍然可見，但是用一個特殊值表示該值不正確，由資料消費者決定如何處理這個錯誤資料。

每給一列標記一個清洗規則，就會定義一個單獨的標記列。下個例子我們會介紹如何用一個標記列來為多列做標記。

例6：執行例2中指定的3條規則；新增1列來做標記。

下表顯示了這個檢視內容中的一些行和列：

說明：如果一行中包含錯誤的status， rating或者aspect，那麼FLAGS列中的值設定為STA， RAT或者ASP。

★

透過還原資料來清洗資料

若使用過濾或標記的方法，錯誤資料不會被修正，而是被移除或者標記為“錯誤資料”。我們也可以利用檢視，用正確資料來代替錯誤資料，但是這項技術只能用來還原拼寫錯誤的資料。

例7：定義一個檢視，在STATUS， SOUND， RATING和ASPECT列上執行規則，儘可能多的還原這些列中的錯誤值。

下表顯示了此檢視內容中的一些行和列：

說明： STATUS列中含有一個拼寫錯誤的值Discontineud，它被轉換為Discontinued。在SOUND，ASPECT和RATING列中，我們也應用了同一型別的轉換。這種方案執行良好，但也有限制：它不會自動發現輸入到源系統中的新的錯誤值，也不會將其新增到檢視定義中，需有專門的技術人員留意錯誤值的輸入和還原。

另一種方法是建立一個專用表，表中包含所有錯誤值及其對應的正確值。例如，建立一個包含以下內容的SOUND_CODES表：

相比長長的CASE表示式，轉換的表示式是這樣的：

說明：如果程式碼拼寫錯誤，表示式將從SOUND_CODES表中返回正確的程式碼；如果沒有拼寫錯誤，則返回SOUND列本身的值。

使用轉換表的優點在於，如果檢測到新的有拼寫錯誤的程式碼，不必更改檢視定義，只需更新SOUND_CODES表即可。這是一種更易於維護的方法。

在示例中，有拼寫錯誤的值的數量相對較低。當涉及諸如公司、客戶和城市的名稱時，問題就會更加難以解決。在這種情況下，兩種解決方案（CASE表示式或轉換表）都不起作用。要確定名稱拼寫是否有錯誤，需要使用更高階的技術，例如模糊匹配，也可能需要訪問具有正確資料的資料集。例如，即使州、城市以及街道的名稱拼寫正確，三者的從屬關係也可能有錯誤。因此，檢測地址是否正確的唯一方法是訪問一個包含所有正確地址的列表。

七、Step 2：設計並實現企業資料層

中性表

企業資料層中檢視結構以儘可能中性的形式表示所有資料。當資料消費者訪問該層時，他們看不到資料來自多個源系統，看不到虛擬基礎層中的檢視結構並不完善，也看不到某些資料甚至沒有儲存在非關係型資料結構中。企業資料層隱藏了所有這些。該層中的檢視有時被稱為“規範化資料模型”（canonical data model）。

我們建議儘量根據“第三正規化”設計這些檢視。在這樣的表格中，“每個沒有關鍵屬性的表格必須依賴於主鍵，依賴於整個主鍵，且僅僅依賴於主鍵。”這句話略微改編了一下威廉·肯特對第三正規化的定義。這樣的話，所有檢視的虛擬內容就會沒有任何冗餘。這種中性結構可能並不是適合每一位訪問這些檢視的資料消費者，但對於大多數的使用形式來說，這種結構足夠了。

注意：企業資料層中的檢視必須只基於虛擬基礎層中的檢視構建，類似的規則適用於其他層。但是，從技術上來講無法保證構建者一定會遵循這種規則。JDV不能阻止開發人員在資料消費層中直接引用源表的檢視。因此，必須定期進行校驗。

源系統的整合

我們需要將邏輯上聯絡在一起，但儲存在不同源系統中的資料整合起來。企業資料層中的檢視負責所有的資料整合。例如，如果多個源系統包含客戶資料，那麼企業資料層中的一個檢視會整合這些資料。

整合可以基於Join或Union操作。Join Integration連線的兩個源系統包含可比較的物件集，但具有不同的屬性集。例如，一個源系統包含客戶的地址相關資料，另一個包含客戶的消費資料，那我們就可以用客戶檢視定義中的Join來整合它們。

例8：想象一下，WCM公司執行著兩個包含客戶資料的系統。一個系統包含所有名稱和地址的相關資料，另一個系統包含其他列。在這種情況下，需要一個full outer join才能讓它們看起來像一個表：

相反，當兩個源系統包含獨有的物件集和可比較的屬性時，則需要union integration。檢視定義中的union運算子可以整合這兩個源系統。

例9：想象一下，WCM公司擁有兩個用於儲存客戶資料的系統。一個系統包含來自北部地區的所有客戶資料，另一個系統包含來自南部地區的所有客戶資料。這就需要union運算子讓它們看起來像一個表：

當兩個表實際上沒有相同的列集時，一個表中缺少的列必須用空值或其他一些有代表性的值來填充。

對主資料的需求

某些Join整合無法僅僅靠在檢視定義中包含Join操作來完成。例如，假設WCM公司有兩個儲存了客戶資料的IT系統，但其中的客戶ID不匹配。在這種情況下，主資料是必不可少的。如果客戶數量有限，則可以開發一個包含兩個客戶系統ID關聯關係的表格，並在表格中指出兩個ID之間的相互關係。這個表格可以儲存在任意一個現有源系統中，並且需要為其定義一個源表和一個檢視。接下來，就可以Join WCM的兩個客戶表。

當我們需要多個主資料解決方案，並且主資料量很大時，那就需要一個更加結構化的解決方案。換句話說，我們需要一個主資料管理系統（master data management system，MDM system），這個系統包含足夠多的資料，能夠將一個源系統中的正確客戶關聯到另一個源系統中的正確客戶。這種MDM系統成為虛擬基礎層的源系統。從技術上講，如果MDM系統允許透過SQL介面訪問主資料，那麼SQL介面就是首選，因為比起更加面向服務的介面（例如SOAP或REST），SQL介面更有效率。

合併更多表格

當企業資料層中的一個檢視指向虛擬基礎層中的大量檢視和源表時，就會出現一種特殊情況。例如，假設WCM公司向遍佈全國的數百家商店提供DVD，想象一下，每個商店都執行自己的本地資料庫來儲存銷售資料，如果盲目地遵循本節所提出的規則，則必須定義數百個檢視，每個檢視都要指向其中一個商店的物理表。為了提供一個對所有銷售情況的概覽，企業資料層中的檢視就成為了數百個源系統的聯合體。這個解決方案是不切實際的。但是還有一種更有效的實現手段，那就需要利用JDV的多源模型特徵（multi‐source model feature）。定義如下所示：

當所有遠端源系統中的表具有相同的schema時，此解決方案有效。與源系統相比，每個檢視都有一個額外的列，用於指示每個記錄的位置。

八、Step 3：設計並實現共享規範層

共享規範層中定義的檢視展示企業資料層中可見的資料，但共享規範層中的資料結構更易於資料消費者消費。共享規範層中的檢視不會更改資料，也不會過濾掉資料，主要是一種資料重組。

原則上，我們並不需要共享規範層。從技術上講，共享規範層之上的層（資料消費層）也可以直接在企業資料層上開發。但是出於對效能、規範共享和處理派生資料三個角度的考量，我們還是建議引入共享規範層。

效能最佳化

如果資料消費者更喜歡以星型模式或雪花模式檢視資料（許多人都這樣做），在企業資料層的規範化檢視上直接定義檢視可能會非常複雜，導致底層源系統必須處理複雜且執行緩慢的SQL語句。因此，我們建議在共享規範層中定義一種非常通用的星型模式結構。定義檢視時，必須對其進行快取以提升效能。快取的重新整理率由所需的資料延遲確定。這些星型模式檢視必須包含所有資料，不僅僅是當前的資料，因為它們包含的資料越多，就會有越多的資料消費者和使用者可以利用相同的檢視集，也因此，利用相同的快取。第12節中我們會介紹更多關於快取的資訊。

例10：在共享規範層中定義一個包含樣例資料庫中

fact data

的檢視。假設企業資料層上檢視的資料結構與圖4中指定的表相同。

例11：在共享規範層中定義一個包含樣例資料庫中

dimension data

的檢視。假設企業資料層上檢視的資料結構與圖4中指定的表相同。

檢視定義中的兩種查詢都不簡單，當資料消費者透過聚合將這兩個檢視Join在一起時，就會變得更加複雜。

從虛擬事實表的定義中可以看出，需要有一個包含日期/時間相關資料的維度。我們建議開發這樣一個包含日期/時間相關資料的表，和所有其他快取表儲存在同一資料庫中。這避免了federated join。

規範共享角度

在資料消費層中定義的許多檢視可以共享相同的規範。例如，假設兩個資料消費者檢視企業資料層的同一檢視的不同列，一個人看到聚合形式的資料，而另一個看不到。儘管如此，兩者在其檢視定義中可能運用相同的過濾器，如僅顯示去年新增的行，或僅針對來自北部地區的客戶。兩個檢視定義中都有兩個過濾器，這在技術上並沒錯，但把這些通用規範定義在共享規範層的檢視中會更高效。這就有了規範的共享，共享讓維護更容易。如果表明客戶來自北部或南部地區的規則發生變化，只需在共享規範層的一個檢視中進行更改即可。

處理派生資料角度

共享規範層的檢視中可以包括派生的資料列。例如，企業資料層的檢視中包含出生日期，如果消費者想看關於年齡的資料，那麼就可以在共享規範層的檢視中定義額外的列來顯示年齡。或者，當檢視顯示華氏溫度時，共享規範層中的檢視也可以包含顯示攝氏溫度的列。

例12：在共享規範層中定義一個新檢視，這個新檢視定義在VT2_CUSTOMER檢視上，並且包含一個由TIMESTAMP_CHANGED列派生出的“NEXT_SUNDAY”列。

新增派生資料的好處是，所有對NEXT_SUNDAY列感興趣的資料消費者使用相同的定義，看到一致的結果。此外，資料消費者不必重新寫公式來計算下週日的日期。這有利於提高生產力，並且易於維護。

注意：派生規則只能包含轉換操作，不能有聚合操作，將聚合操作都放在資料消費層來定義。

九、Step 4：設計並實現資料消費層

定義檢視

在某種程度上，這是最簡單的一步：根據資料消費者的需求來定義適當的檢視。如果資料消費者需要星型模式，那我們就定義一組星型模式檢視；如果他們喜歡類似雪花的資料組織，那我們就定義雪花模式的檢視；如果資料消費者更喜歡包含他們所需的所有資料的大寬表檢視，那麼我們也會開發出這樣的檢視。這種方法會導致資料消費層中的幾個檢視在內容上有重疊，但這不是問題，因為它不涉及儲存。

嘗試在此層的檢視中找出常用規範，並將它們移到底層的共享規範層。

定義主鍵和外來鍵

許多用於報表和分析的工具需要知道它們正在訪問的表的主鍵和外來鍵，因此，我們需要在資料消費層的檢視上定義適當的主鍵和外來鍵。定義主鍵和外來鍵有助於工具生成更最佳化的程式碼以訪問檢視。

釋出檢視

檢視須先“釋出”，之後才能訪問。釋出意味著檢視內容可供任何資料消費者使用。檢視釋出涉及定義技術API和語言，透過這些技術API和語言必須能訪問到檢視。諸如JDBC / SQL，SOAP和REST等是技術介面。而選擇哪個API具體取決於訪問檢視的工具和應用程式。通常，它們需要特定的API。

資料安全

釋出檢視時，可以定義安全方面的機制。與公司內部安全專家合作確定需部署哪些安全機制。

十、Step 5：為自助服務設計檢視

業務驅動BI（Business-Driven BI）

在我們的實際工作中存在許多不同形式的BI，所有這些形式可以分為兩類：IT驅動BI和業務驅動BI。IT驅動BI，報表由IT部門設計和開發（部分或全部），並且必須進行測試、治理和審計。通常，這些報表在未來幾年內必須是可複用的，其中一些須分送給監管機構、客戶或供應商。與IT驅動BI相關的典型術語是：行業規模，規範驅動流程，專業測試，SLA指標，治理和控制。

業務驅動BI與業務使用者設計和開發的所有報表相關。自助BI，調查分析，資料發現和資料科學都是業務驅動BI的形式。業務驅動BI的典型特徵是：自助服務、敏捷、非治理、不可審計、可調查、一次性使用、無共享或最小共享。

步驟一到四中定義的檢視支援IT驅動BI。對於業務驅動BI的形式，重要的是在資料消費層和共享規範層中保留一些區域，用於檢視的自助服務開發。在這些區域裡，使用者可以在屬於企業資料層的檢視之上定義自己的檢視。我們不建議允許使用者定義可以直接訪問源系統的檢視，因為他們需要處理錯誤資料，整合來自源系統的資料，這些非常複雜，並且會耗費他們寶貴的時間。此外，還可能導致錯誤定義的檢視，從而導致錯誤的報表結果。

監控和管理

BI技術人員必須校驗和監控使用者對檢視的定義和用法。要檢查的事項有：

使用者是否使用最有效的程式碼來定義檢視？

使用者是否正確的Join企業資料層中的檢視？

使用者是否有重複造輪子，做無用功？

使用者是否真的使用了正確的檢視？

SQL技術人員知道，可以用許多不同的方式編寫查詢，有些公式是有效的，有些則不是。但是使用者並不一定知道最有效的編寫方式，這就可能導致不必要的慢查詢。透過監控查詢效能，技術人員可以確定哪些檢視總是執行很慢。然後，他們可以研究檢視定義，看看能否提出一個更快的解決方案。如果能，就會把這個更快的解決方案提交給使用者。技術人員還可以幫助使用者執行更有效的檢視定義。

這種監控使自助使用檢視的開發成為使用者和BI技術人員密切合作的一個過程。

響應式開發（Reactive Development）

請注意，BI技術人員在自助環境中的所有工作都可以稱為“響應式”。此環境中的檢視不是先定義，然後在使用之前進行測試、調整和最佳化。相反，在使用者定義好自己的檢視後，他們可以立即使用這些檢視。監控用於確定是否需要專家的響應，確定之後，專家才會做出響應。這與第8節和第9節中描述的檢視開發非常不同。這些檢視在測試和最佳化後就可以訪問了。

十一、Step 6：為資料質量管理設計檢視

在第6節中我們提到過，使用JDV等資料虛擬化技術與使用ETL技術不同，特別是在處理資料質量問題上。示例1到7描述瞭如何定義過濾掉錯誤資料或恢復正確資料的檢視，除了做標記的檢視中的錯誤資料是可見的之外，其他檢視中的錯誤資料都是不可見的。

但是，如果負責資料質量的技術人員想要檢視不正確、丟失或拼寫錯誤的數值呢？因為如果他們能看到這些數值，就可以去和源系統的所有者討論如何修復錯誤資料。這樣一來，資料的整體質量都能得到改善。

為了支援負責資料質量的技術人員，可以定義專用檢視來顯示所有錯誤資料，這些專用檢視可以顯示已過濾、已標記或不正確的資料。定義這種型別的檢視相對比較簡單，我們來看例子：

例13：定義一個檢視，它可以顯示例2中過濾掉的所有資料：

說明：查詢第一部分的結果返回所有DVD發行版本，第二部分返回所有正確的DVD發行版本。兩個部分做減法，剩下的就是包含錯誤資料的行。這個方法同樣適用於過濾和恢復值。

十二、Step 7：最佳化效能

我們可以利用一些技術來改善四層檢視的查詢效能。本節主要討論一些查詢最佳化技術，更多相關技術和詳細描述，請參閱JDV手冊和源系統使用的資料庫伺服器。

快取檢視

快取檢視是JDV提供的用於提高查詢效能的最強大技術之一。但是，提高查詢效能並不是定義快取的唯一原因，實際原因還包括：

源系統執行緩慢：當我們訪問源系統時，某些源系統執行可能會非常緩慢。例如，某些雲應用程式的介面具有一個特點，即每訪問一次，都只能返回一個數據，這種訪問形式十分緩慢。因此，我們最好快取訪問此類應用程式的檢視，這個快取的重新整理頻率滿足訪問此檢視的所有使用者的需求。

網路延時：由於頻寬不足或網路不可靠，訪問遠端源系統可能會非常慢。這兩個都是快取檢視的原因。

利用率低：資料消費者可能一天24小時都要訪問源系統裡的資料。但是，如果源系統每晚8點關閉，第二天早上6點再次啟動，那麼只有快取檢視才可以滿足所需的24小時的訪問時間，提高資料的利用率。

複雜的檢視定義：大多數虛擬基礎層中的檢視定義都十分簡單，但並非所有的檢視定義都是如此。清洗規則的複雜性可能導致查詢效能不佳，或者源系統不一定是關係型資料庫，還有一些文件型資料庫，將巢狀資料展平是複雜且耗時的。這兩種情況我們都建議使用快取。

注意，某些資料消費者需要使用實時資料，另外一些資料消費者需要在源系統中插入、更新和刪除資料，這兩種情況都無法定義快取。如果既存在具有上述兩種要求的資料消費者，又存在需要快速查詢訪問的其他消費者，則可以在同一源系統上定義兩個檢視。兩個檢視具有相同的資料結構，但一個不定義快取（給想要檢視實時資料的資料消費者），一個定義快取（給想要執行報表的資料消費者）。

快取檢視指南

如果我們需要快取，可以把快取定義在共享規範層的檢視上。這樣做的好處是源系統的所有處理，資料的清洗，資料的整合和規範化以及資料的重組都已經在資料消費層的下層執行完畢。

我們也可以在資料消費層的檢視上定義快取，但如果可以，還是推薦在共享規範層上定義快取，因為這樣一來，許多資料消費者都可以從一個快取中受益。

如果資料消費者經常一起使用特定的幾個檢視，那就將快取儲存在同一資料庫中，以避免分散式連線處理。

在快取表中定義索引

當快取物理儲存在SQL資料庫中時，JDV不會在其上定義索引。我們建議在快取表中定義索引。如果快取表上存在主鍵，在其上定義唯一索引，同時還要在外來鍵的列上定義索引。這有助於查詢最佳化器生成最佳查詢計劃。此外，在經常聚合以及經常過濾的列上也要定義索引。請注意，新增額外的索引可能會在一定程度上減慢快取的速度。

在快取上開發索引無法在JDV中完成，必須使用SQL資料庫伺服器來完成。定義額外的索引時，請確保設定了正確的引數；詳細內容請參閱SQL資料庫伺服器的相應手冊。

更新統計資訊

如果表和索引的統計資訊過時，或者換句話說，如果它不能反映當前情況，那麼SQL資料庫伺服器的查詢效能就會較差。SQL資料庫伺服器的查詢最佳化器查詢計劃是基於此統計資訊的，所以統計資訊應該儘可能更新，這是至關重要的。過時的統計資訊可能導致查詢效能不佳。因此，快取檢視的統計資訊也應該是最新的，這同樣十分重要。在每次重新整理快取之後，必須考慮統計資訊的更新。參閱SQL資料庫伺服器的相應手冊，確定如何更新統計資訊。

此外，JDV本身也需要源表上的統計資訊來最佳化它在源系統上執行的查詢。因此，在源表上提供統計資訊來獲得最佳查詢計劃非常重要。

使用效能最佳化功能

每個SQL資料庫伺服器都有許多最佳化效能的功能：對錶進行分割槽，放大和調整緩衝區，最佳化表空間引數，將表移動到更快的儲存中等等。與資料庫管理員核實，看看他們是否可以調整和最佳化對快取表的訪問。

注意：無論使用資料庫伺服器的哪些功能來最佳化效能，都不要更改快取檢視的結構或內容，因為這可能會對快取檢視的執行造成損害。

其他效能最佳化功能

網路延時會對效能產生負面影響。想象一下，JDV在一臺伺服器上執行，源系統在另一臺伺服器上執行，資料來源沒有任何執行SQL的能力。換句話說，JDV必須透過網路從源系統中拉取所有資料，並在自己的伺服器上執行所有查詢處理。為了減小網路流量，可以安裝兩個JDV例項（見圖6），在本地伺服器上執行的JDV例項會將整個查詢傳送到在遠端伺服器上執行的JDV例項。遠端伺服器上執行的JDV例項從源系統中提取所有資料，處理查詢，並僅將查詢結果返回給本地服務。這可以大大減少透過網路傳輸的資料量。