一. ETL 過程概覽
本章將按照 ETL 系統規劃與實現的流程組織討論 。其中隱含地討論上一章所討論的 34 個 ETL 子系統 ，大致按照獲取數據 、清洗與一致性、用於展現的發佈 、ETL 環境的管理等分類 。
在開始談論針對維度模型 的 ETL 系統設計前 ，您應當已完成了邏輯設計 、勾畫完成了高層結構規劃井勾畫出有關源到目標的所有數據的映射 。
ETL 系統設計過程至關重要 。收集所有的相關信息 ，包括處理從操作型數據源中獲取的代價，測試某些關鍵的替代品 。將轉換過程駐留到源系統 、目標系統或其本身的平臺上 是否有意義？在每種情況下，可以使用哪些工具 ？這些工具 的有效性如何？
二. ETL 開發規劃
ETL 開發從高層次的計劃開始 ，該技術獨立於所有特定技術或方法 。然而 ，在開始制 定詳細 的規劃前，決定採用某種 ETL 工具是一種好辦法 ，這樣做可以在後續過程中避免重新設計和返工。
2.1 第 1 步：設計高層規劃
設計過程始於規劃的己知片段的簡單示意圖 ：源和目標 ，如下 所示 。該示意圖表 示虛擬公用事業公司的數據倉庫 ，其主要的數據源來自於己有 30 年曆史的 COBOL 系統。 如果多數或所有數據來自於 一個現代關係型事務處理系統 ，那麼圖中的框通常 表示事務系 統模型中的表的邏輯分組 。
在開發詳細的 ETL 系統定義時 ，高層視圖需要額外的細節 。上圖詳細強調了當前 的問題和尚未解決的問題 ，該規劃將會被頻繁地更新和發佈 。有時需要保留該示例的兩個 版本 ：一個與小組外人員交互的圖以及 一個作爲內部 DW/BI 小組文檔的詳細版本 。
2.2 第 2 步：選擇 ETL 工具
在數據倉庫市場中存在多種可應用的 ETL 工具 。大多數主要的數據倉庫提供商都提供
ETL 工具 ，通常需要額外的許可權開銷 。第三方提供商也提供優異的 ETL 工具。
ETL 工具從一系列數據源中讀取數據 ，包括平面文件 、ODBC 、OLE DB 以及大多數 關係數據庫本身自帶的數據庫驅動程序 。它們可以將數據寫入到各種各樣的目標文件格式 。 它們都包含一些功能用於管理 ETL 系統的整體邏輯流程 。
如果源系統是關係型 的，那麼轉換需求就比較直接 ，在具有優秀員工的前提下 ，ETL工具的價值可能不會立即顯現出來 。然而，使用 ETL 工具是行業標準的最佳實踐 ，其原因 如下：
• 使用圖形工具可自動構建文檔 。硬代碼系統通常是造成臨時表 、SQL 腳本 、存儲過程 、操作系統腳本混亂的主要原因 。
• ETL 過程的所有步驟的元數據基礎 。
• 多人開發環境需要使用的版本控制 ，版本控制還可實現備份和恢復 一致性的版本。
• 高級轉換邏輯 ，例如模糊匹配算法 、對名稱和地址集 成訪問的重複數據刪除
(deduplication）實用程序 ，以及數據挖掘算法等 。
• 以最基本的經驗改進系統性能 。真正能夠成爲使用關係數據庫處理大數據且能具 備良好經驗的專家型 SQL 開發人員相對較少 。
• 複雜的處理能力 ，包括自動實現任務並行化 ，以及當處理源不可用時具有自動容 錯能力等 。
• 將圖形化數據轉換模塊 一步轉化爲其物理等價物 。
不要指望在 DW/BI 項目的第 1 階段就能收回 ETL 工具的投資 。由於學習曲線非常陡 峭，導致開發者有時感覺通過編碼的方式可能會使項目開發更快 。對ETL 工具投資的好處 在後續的過程中，特別是在未來對系統改進時才能逐漸顯現出來 。
2.3 第 3 步：開發默認策略
對什麼可能會發生以及什麼是 ETL 工具的基本需求進行總體考慮 ，應當針對 ETL 系 統中的公共活動開發默 認策略 。這些活動包括 ：
• 從每個主要的源系統獲取數 據 。在設計過程的這一點上 ，您能決定從每個源系統 獲取數據的默認方法 。您通常將來自源系統的數據放入平面文件中嗎 ？是從數據 流獲取的嗎 ？是利用工具讀取數據庫日誌嗎 ？是採用其他方法嗎 ？這一決定可以 逐表進行修改 。如果使用 SQL 訪問源系統數據 ，則確保利用本地數據獲取器而不 是使用 ODBC ，如果存在這樣 的選項的話。
• 歸檔獲取的數據或分級的數據 。獲取的或分級的數據在被轉換前 ，應該被歸檔至 少一個月。有些組織對獲取的和分級的數據採取永久歸檔的策略 。
• 監管維度和特定事實 的數據質量 。應在 ETL 處理過程中監控數據質量 ，而不應當 在用戶發現問題時纔開始監控數據質 量。子系統 4 到子系統 8 描述了度 量和響應數據質量問題的完整結構。
• 維度屬性變化的管理。我們在 ETL 子系統 9 中描述了管理維度屬 性變化所需要 的邏輯。
• 確保數據倉庫和 ETL 系統滿足系統可用性需求 。滿足可用性需求的第 l 步是將它 們文檔化 。當每個數據源開始使用時以及在高層任務序列中被完成時 ，應當將它 們文檔化 。
• 設計數據審計子系統 。數據倉庫表中的每行應該用相關審計信息標記 ，用以描述 數據如何進入系統 。
• 組織 ETL 過渡區。多數 ETL 系統在 ETL 處理過程中至少有 1 次或 2 次將數據放入過渡區中 。通過過渡方式 ，數據將被寫入磁盤中 ，用於後續的 ETL 步驟以及系 統恢復和歸檔工作 。
2.4 第 4 步：按照目標表鑽取數據
在開發完所有的公共ETL任務後 ，應當開始深入研究詳細的轉換工作 ，以填充數據倉 庫中的目標表 。在完成源到目標的映射後 ，您將完成更多的數據概要描述工作 ，以完整理 解每個表和列所需要的數據轉換 。
確保層次的清楚性
研究維度數據中存在的層次 關係是否被清楚 地描述是非常重要的工作 。考慮包含從 產品庫存單元（SKU)到產品分類層次上卷的產品維度 。
以我們的經驗來看，最可靠的層次應當在源系統中管理 。最好的源系統規範化層 次， 將不同級別放入多個表中 ，兩個級別間以外鍵關聯 。在此情況下 ，可以相信層次級別是 清 楚的。如果源系統沒有被規範化，特別是如果包含層次的源是業務用戶的臺式電腦的 Excel 電子報表時 ，則您必須要麼對其進行清洗 ，要麼承認沒有層次存在 。-
開發詳細的表示意圖
下圖描述了可方便用於特定表下鑽的細節 層次，該圖描述了前述公用事業公司案例 的一個表。
![]()
在對事實表執行關鍵查詢步驟 前，所有維度表必須經過處理 。維度表相互之間通常是 無關的 ，但有時它們也存在過程依賴 。分清這些依賴是非常重要的 ，因爲它們是任務控制 流程的固定點。
2.5 開發 ETL 規範文檔
我們已經討論了一些用於ETL系統的高層規劃和物理設計的一般策略 。現在應該考慮 將所有情 況統一起來併爲整個 ETL 系統開發詳細規範 。
到目前爲止，所有文檔開發一 一源到目標的映射 、數據檔案報表 、物理設計決策都應當進入 ETL 規範的第一部分 。然後文檔化所有本章所討論的相關決策 ，包括 ：
• 從每個主要的源系統獲取的默認策略 。
• 歸檔策略 。
• 數據質量跟蹤和元數據 。
• 管理維度屬性變化的默認策略 。
• 系統可用性需求與策略 。
• 數據審計子系統的設計 。
• 過渡區的定位 。
ETL 規範的下一個部分描述每個錶的歷史和增量加載策略 。好的規範其每個表都包括 幾頁細節 ，文檔化下述信息和決策 ：
• 表設計（列名 、數據類型 、鍵和約束）。
• 歷史數據加載參數（月數）和容量（行計數）。
• 增量數據容量 ，對每個加載週期涉及的新的和史新的行 。
• 處理事實表和維度表的遲到數據 。
• 加載頻率 。
• 處理每個維度屬性的緩慢變化維度（ SCD）變化。
• 表分區 ，例如按月 。
• 數據來源概述 ，包括討論所 有不常見的源特徵 ，例如不常見的簡短存取窗口 。
• 詳細的源到目標的映射 。
• 源數據概要 ，包括每個數字列的最小值和最大值 ，每個列中出現的不同值的計數 ， 包括空值的發生率 。
• 源數據獲取策略 （例如 ，源系統的 API 、直接從數據庫查詢或轉儲到平面文件）。
• 依賴 ，包括某個表在處理前必須加載哪些其 他表。
• 文檔化轉換邏輯 。該部分最好用僞代碼或圖 表來撰寫 ，而不是試圖手工編制完整 的句子。
• 避免產生錯誤 的前提條件 。例如 ，在繼續開展工作前 ，ETL 系統必須檢查文件或 數據庫空間。
• 清洗步驟，例如刪除工作文件。
• 估計該部分 ETL 系統實現是容易、中等程度或難於實現。
注意：
儘管多數人贊同 ETL 系統規範文檔中描述的所有項都是必要的 ，但要將這些文檔彙總 到一起需要花費大量的時間 ，當 變化發生時 ，要保持當前狀態需要更多 的工作。實際上， 如果您將 “一份” 高層流程圖 、數據模型和數據源到目標的映射 ，以及有關您計劃做什麼 的幾頁描述放在一起 ，您將會獲得比其他大多 數小組史好的開始 。
開發一個沙箱源系統
在ETL開發過程中 ，需要對源系統數據進行深入的調查 。如果源系統加載數量較大 ，且 不存在操作型查詢的報表實例 ，DBA 可能願意爲 ETL 開發小組設置數據庫靜態快照 。在開發過程初期 ，瀏覽源系統的沙箱版本是比較方便的 ，不需要擔心會推出一種致命的查詢 。
建立沙箱源系統比較容易 ，可簡單地拷貝源系統 。只有當數據容量非常巨大時，才建 立一個包含數據子集的沙箱 。好處是，這種沙箱在系統投產後 ，可成爲培訓教材和教程的 基礎。
三. 開發一次性的歷史加載過程
ETL 規範建立完成後 ，您通常會關注開發 一次性加載歷史數據的 ETL 過程 。偶爾 ，同 樣的 ETL 代碼可用於完成初始歷史數據加載和後續的增量加載 ，但通常會爲初始歷史數據 加載和後續加載建 立不同的 ETL 處理過程 。歷史和增量加載過程有許多共同點 ，與 ETL 工具有關 ，主要的功能是可以重用的 。
3.1 第 5 步：用歷史數據填充維度表
一般來說，在開始建立 ETL 系統時 ，會採用最簡單的維度表 。在這些簡單 的維度表被 成功建立後 ，可以處理包含一個或多個其列具有 SCD類型 2 的維度錶的歷史數據加載工作 。
3.1.1 填充類型 1 維度表
最簡單的表填充類型是那些所有屬性都包含類型1重寫的維度表。在只包含類型1的維度中，直接從源系統獲取每個維度屬性的當前值 。
3.1.2 維度轉換
即使是最簡單的維度表也可能需要大量的數據清洗工作並需要爲其分配代理鍵 。
簡單數據轉換
最常見、最簡單的數據轉換形式是數據類型轉換 。所有ETL 工具都具有豐富的數據類
型轉換功能 。執行該任務是非常乏味的工作 ，但幾乎不會出現麻煩 。我們強烈建議以默認 值替換維度表中可能存在的空值 。正如前文所討論的那樣 ，在直接對其進行查詢時 ，空值 可能會出問題 。不同源的數據合併
通常維度來自幾個源 。客戶信息可能需要融合幾個業務工 頁 ，且這些業務項可能來自外 部源 。通常不同源很少具有通用的預先嵌入的鍵 ，這種情況會導致融合操作非常困難 。
如果首先將名稱和地址分解爲組成部件 ，則多數整合和重複數據刪除工具及過程用起 來非常方便 。然後可以使用多遍模糊邏輯發現拼寫錯誤 、打字錯誤 ，並對拼寫進行整合 ， 例如整合諸如 I.B.M. 、IBM 或 International Business Machines 這樣的拼寫 。多數組織中 ， 都具有大型的一次性項目用於整合現存客戶 。對主數據庫管理系統來說 ，這一工作具有巨 大的價值。產品碼解碼
數據預處理中常見的融合工作是爲 產品碼查找文本等價解釋 。有時，文本等價物是來 自非產品源 ，例如電子報表的非正式來源 。代碼查找通常存儲在過渡區的數據庫表中 。確保ETL系統包含建立默認解碼文本等價物的邏輯 ，不要出現產品碼不在查找表中的情況 。-
驗證多對一和一對一關係
最主要的維度可能具有一個或多個上卷路徑 ，例如產品上捲到產品模型 、子分類和分 類，如下圖 所示 。針對這些層次的 上卷需要非常清楚的層次 。
![]()
屬性間的多對一關係，例如產品到產品模型 ，可 以通過排序“多” 屬性檢驗並驗證“ 一” 屬性具有唯一值 。例如，下列查詢返回包含多個產 品模型的產品：
SELECT ProductSKU , count(*) a s RowCount,
count(distinct ProductModel) as ModelCount FROM StagingDatabase.Product
GROUP BY ProductSKU
HAVING count(distinct ProductModel) > 1
數據庫管理 員有時希望通過將數據 加載到過渡 區數據庫中的規範維度表雪花版本來 驗證多對一關係，如下圖所示 。注意規範版本需要在層次的每個級別上具有獨立建 。如果源系統支持該鍵 ，則不會出現任何問題 ，但是 如果您將ETL環境中的維度表規範化，則需要建立這些鍵。
雪花結構在過渡區中具有某種價值 ：它可以防止您加載那些違反多對一關係的數據。 然而 ，一般來說 ，正如剛剛討論過的那樣 ，關係應該預先被驗證 ，這樣就不會將壞數據加載到維度表中 。在數據已經經過預先驗證的情況下 ，在加載表時是否需要數據庫引擎重新 證實表之間的關係就顯得不那麼重要了 。
如果維度層次的源系統是 一種規範化的數據庫 ，通常在 ETL 過渡區不需要重建規範化 的結構。然而 ，如果層次信息來自非規範的數據源 ，例如市場部門管理的報表 ，則可能會從對 ETL 層次的規範化工作中受益。
- 維度代理鍵分配
在確信維度表中每一行都是真正唯一的維度成員後 ，可以開始分配代理鍵的工作 。應 當在 ETL 過渡區數據庫中維護 一張匹配代理鍵與 生產鍵的表 ，這樣可 以在後續的事實表處 理期間利用表中的鍵映射 。
代理鍵通常以整數形式分配 ，對每個新鍵 ，其代理鍵進行加 l處理。如果過渡區包含 在 RDBMS 中，代理鍵分配可通過建 立序列方便地實現 。儘管不 同的關係引擎可能會有語 法上的差異 ，但過程都是首先建立序列 ，然後填充鍵映射表 。
以下給出了一次性建立序列 的語法：
create sequence dim1_seq cache= 1000 ；一 choose appropr iate cache level
後續填充鍵映射表的語法如下 ：
insert into dim1key_map ( production_key_id , diml_ key ) select production_key_id, dim1_seq .NEXT from dim1extracttable;
3.1.3 維度表加載
維度數據準備完成後 ，加載到目標表的過程相當直接 。即使第 1個維度表相對較小 ， 也可利用數據庫的批量或快速加載實用程序或接口 。對大多數表插入操作來說，可以使用快速加載技術 。有些數據庫對SQL語法進行了擴展 ，包括 了 BULK INSERT 子句。而有些 數據庫發佈了 API 以通過數據流加載到數據表中。
批量加載實用程序和 API 包含一系列參數 ，包括以下的轉換能力：
• 關閉日誌 。事務日誌顯著地增加了開銷，在加載數據倉庫表時幾乎沒有什麼價值。 ETL 系統應該設計一個或多個具有可恢復性 的點，一旦 出現錯誤，您可在此重新 開始處理過程 。
• 快速模式批量加載 。然而，多數數據庫引擎的批量加載實用程序或 API 需要 目標 表滿足幾個嚴格的條件 ，才能執行快速模式 的批量加載。如果這些條件 未被滿足， 則加載將會失敗 。不使用 “ 快速” 模式要簡單得多。
• 文件預排序 。按照主索引順序對文件進行排序將顯著地加快索引操作 。
• 謹慎轉換 。某些情況下 ，加載器支持數據轉 換、計算 ，以及字符 串和日期／時間操 作。使用這些特性時要仔細並注意要 測試性能。某些情況下 ，這些轉換操作會導 致加載器關閉高速模式 ，進入對加載文件按行 處理的模式 。
• 在開始完全刷新之前執行截斷表操作 。TRUNCATE TABLE 是最有效 的刪除表中 所有行的子句 。在開始一天的 ETL 處理前通常可使用該子句清除 過渡區數據庫中 表的 內容。
3.1.4 加載類型 2 維度表歷史
維度表屬性變化通常是按照類型 1（重寫）或類型 2（通過在 維度表中增加新行以跟蹤歷史）管理的 。多數維度表包含類型 1 和類型 2 屬性 。
在歷史加載期間 ，需要重建那些按照類型 2 來管理的維度屬性的歷史 。如果業務用戶 確定某個屬性對跟蹤歷史來說非常 重要 ，則他們希望能夠及時獲得歷史情況 ，而不是僅僅 從數據倉庫實現 的時間開始。通常重新建立維度屬 性歷史是非常困難的工作 ，有時甚至是 不可能實現的工作。
該過程並不適合用標 準 SQL 處理 。最好利用數據庫遊標構件 ，甚至更好的 處理方法是， 使用過程語 言（例如 Visual Basic 、C 或 Java）來執行這一工作 。多數 ETL 工具使用腳本處理 流過 ETL 系統的數據。
重構歷史的 工作完成後 ，最後一啓要瀏覽數據 以設置行結束 日期列。重要的是在此 序列中沒有差異 。如果行的日期粒度爲整天的話，我們寧願將舊版本的維度成員的行結束日期設置爲新行的行生效日期 。如果生效日期和結束日期包含準確的日期 ／時間戳，其精度到分或秒，則結束日期／時間必須被設置爲下一行的開始日期／時間 ，這樣就消除了行間的差異。
3.1.5 對日期和其他靜態維度的填充
幾乎所有數據倉庫都包含日期維度 ，通常其粒度爲每天 一行。日期維度通常涉及數據 的歷史範圍 ，從數據倉庫中最早的 事務事實開始。爲歷史數據設置日期維度是比較容易的， 因爲您知道被加載的歷史 事實數據的日期範圍。多數項目通過手工建 立 日期維度，通常建 立在一個電子報表中 。
大量其他維度可以以同樣的方式建立 。例如 ，您可以建立包含實際和預算值的預算場 景維度 。業務數據管理代表應當對所有構建的維度表簽字負責 。
3.2 第 6 步：完成事實表歷史加載
一次性事實表歷史數據加載與後續的增量加載過程有比較大的差別。在加載歷史數據 時最大的疑慮是數據量 ，有時其加載的數據量是 日常增量加載數據量的幾千倍。另一方面， 您有幸將那些未在生產系統中的數據加載到表中 。如果歷史數據的加載需要幾天的時間才能完成，您就會感到難以忍受 。
歷史事實表獲取
當您確定了那些滿足獲取基本參數的記錄後，要確認這些記錄是否對數據倉庫有用 。 多數事務系統在其源系統中所保存的操作型信息可能從業務角度來看沒有什麼意義 。
在該步驟中 ，積累審計統計信息是一個好主意。當通過獲取建立結果集後 ，通常可以 獲得小記、總計和行計數信息 。審計統計信息
在 ETL 系統的規劃階段 ，您會確定各種針對數據質量的度量 。這些度量通常是可計算的，例如計數和彙總，可以比較數據倉庫和源系統的數據以交叉檢查數據 的完整性 。這些數值可聯繫操作型報表及數據倉庫加載過程的結果 。能夠回朔到操作型系統是非常重要的， 因爲它是建立可信任數據倉庫的基礎。
注意：
在某些場景中，想要從數據倉庫建立與源系統的反向聯繫是不大容易實現的 。多數情 況下，數據倉庫獲取包括未被應用到源系統的業務規則 。更令人苦惱的是源系統中的錯誤 。 另外，時間上的差異也使得交又檢查變得異常困難 。如果無法實現數據的反向聯繫 ，則需要解釋其中的差異 。
- 事實錶轉換
多數項目中 ，事實數據相對比較乾淨 。ETL系統開發者花費大量的時間改進維度表的 內容，但是事實通常需要適度的轉換。多數情況下，當來自事務系統的事實被用於組織的執行時 ，這一工作非常有意義 ，
針對事實表最常見的轉換包括空值轉換 、旋轉或逆透視數據，以及預先計算導出計算 。 此後，所有事實行進入 ETL 系統代理鍵流水線 以將自然鍵轉換爲 ETL 系統管理需要的維度代理鍵。
1） 空事實值
所有數據庫引擎都支持空值 。然而 ，在大多數源系統中 ，空值都被表示爲合法事實 的 一個特殊的值 。也許用特殊值1表示空值。對大多數事實表度量來說 ，其場景中的 “ 1” 應該被真正的 NULL 取代。空值用於數字度量在多數事實表中是合理的 、常見的 。在跨事實行計算彙總和平均時 ，空值能夠執行 “ 正確的事情”。僅在維度表中您應當盡力將空值替 換爲特殊的專 門制定的默認值 。最後 ，不應當允許以事實表列中的空值引用維度表鍵 。這 些外鍵列應當始終被定 義爲非空(NOT NULL）。
2） 改進事實表內容
正如我們所強調的那樣 ，最終事實錶行的所有事實必須以同 一粒度表示 。這意味着在 以天爲粒度的事實表中不會存在表示年彙總情況的事實 ，也不會存在對某些 地理情況的匯 總比事實表粒度大的情況。如果獲取包括不同粒度的交錯的事實 ，則必須要消除這些聚集 ， 或者將它們移入適當 的聚集表中 。
事實行包括導出的事實 ，儘管在多數情 況下 ，在視圖中或聯機分析處理（ OLAP）多維數據庫中而不是在物理表中計算導出事實效率會更高 。例如 ，包含收入和成本的事實行可能希望表示淨利潤的事實 。重要的是儘量在用戶需要獲取淨利潤時通過計算得到 。如果數據倉庫要求所有用戶通過視圖訪問數據，則最好在視圖中計算淨利潤 。如果允許用戶直接訪 問物理表 ，或者如果用戶經常過濾淨利潤從而使您想要對它進行索 引時，則最好是預先計 算出淨利潤並物理地存儲它 。
類似地 ，如果一些事實需要同時表示多種度量單 位 ，可以採用同樣的邏輯 。如果業務 用屍通過視圖或 OLAP 多維數據庫訪問數據，最好在用戶訪問時計算各種不同版本的事實。
3） 維度代理鍵查詢流水線
在事實表與維度表之間保持參照完整性是非常重要的，事實行不會引用不存在的維度成員。因此，事實表中的所有外鍵不應存在空值 ，所有事實行對任何維度不會違反參照完整性 。
代理鍵流水線是將數據 加載到目標事實表 的最終操作。此時所有清洗 、轉換和處理都己經完成。輸入數據看起來類 似維度模型中 的目標事實表 ，只是其仍然包含從數據源獲得 的自然鍵而沒有用數據倉庫的代理鍵 替代。代理鍵流水線過程負 責交換自然鍵與代理鍵井 處理所有參照完整性錯誤 。
在事實數據進入代理鍵流水線前 ，維度表必須處理完成 。任何新的維度成員或已經 存在的推度成員的類型 2 變化必須都處理完成 ，這樣它們的鍵對代理鍵流 水線來說纔是可用的。
首先來討論與參照完整性有關的問題 。確認維度表中每個歷史數據事實包含自然鍵是非常簡單的事情 。這一步驟是手工完成的步驟 。此時，歷史加載暫停，以便您能夠在處理前檢查並修改任何的參照完整性問題 。要麼修改維度表 ，要麼重新設計事實表獲取以過濾錯誤行 ，具體可視情況而定。
現在己確信不存在參照完整性錯誤 ，您可以設計歷史代理鍵流水線 。 在此場景中 ，在加載歷史事實度量時，您可以針對所有受到影響的包含類型 2 變化的維度 使用 BETWEEN 邏輯以定位維度行 。
可以採用幾種方法設計歷史加載的代理鍵流水線以提高其性能 ，其設計取決於所使用的 ETL 工具的特性、需要處理的數據容量以及維度設計。理論上說，您可以定義一個查詢 ， 通過自然鍵實現事實過渡表與每個維度表的連接 ，該查詢返回事實和來自所有維度表的代理鍵 。如果歷史數據容量不是很大 ，假定您將過渡事實數據放在關係數據庫中並且爲支持 該大型查詢對維度表建立了索引 ，則這種方法效果很好 。使用該方法的好處包括 ：
• 該方法利用了關係數據庫的強大功能 。
• 使用並行技術完成代理鍵查找 。
• 該方法簡化了獲得正確的類型 2 維度的維度鍵存在的問題 。連接到類型 2 維度必 須包含定義爲表中維度成員的事務日期分類在行有效日期和行失效日期之間的子句。
如果歷史事實數據容量大到幾百GB或幾TB時，沒有人願意採用上述方法 。與類型2 維度表的複雜連接對系統資源構成了巨大的威脅 。大多數維度設計包括數量巨大（但每個表本身不大）的類型 1 維度表 ，只有少量的維度包含類型 2 屬性。您可以使用這一關係技術一 遍執行對所有的類型 1 維度的代理鍵查找 ，然後對類型 2 維度另行處理 。您應當確保對有 效日期和結束日期列建立了適當的索引 。
如果不使用數據庫連接技術 ，可以採用 ETL 工具的查找操作符 。 當所有事實源的鍵被用代理鍵替換後 ，就可以加載事實行了 。事實錶行中的鍵被選爲不同維度表的適當外鍵 ，事實表與維度表滿足參照完整性要求 。
4） 分配審計維度鍵
事實表的每個行通常都包含一個審計鍵 。審計鍵指向描述加載特徵的審計維度 ，審計維度包括相對靜態的環境以及數據質量度量 。審計維度可以很小 。最初設計的審計維度僅包含兩個環境變量（主 ETL 版本號和利益分配的邏輯號）和一個質量標誌 ，該標誌的值是 Quality Checks Passed（質量檢查通過）和 Quality Problems Encountered （發生質量問題）。隨着時間的推移 ，這些變量和診斷指標可能會變得非常複雜和詳細 。增加到事實表的維度審計鍵要麼在代理鍵流水線之前立即增加 ，要麼在之後立即增加。
- 事實表加載
加載事實表時主要關注的是加載性能 。一些數據庫技術支持包含特定批量大小的快速加載 。可通過查閱有關快速加載技術的文檔 學習如何設置這一參數 。您可以通過實驗發現 理想的以行數量計的批量大小以及服務器內存配置 。多數人不願意爲實現準確執行而採取 一種簡單地選擇數量（例如 ，10 000 、100 000 或 l 000 000）的方式 。
除了使用批量加載器以及合理的批量大小（適合數據庫引擎的）外，改進加載歷史數據性能 的最好方式是加載到分區表中 ，理想情況可以並行加載多個分區 。加載到分區表的步驟包括 ：
(1） 在加載數據前 ，禁用事實表與每個維度表之間的外鍵 （參照完整性）約束
(2） 刪除或禁用事實表的索引
(3） 使用快速加載技術加載數據
(4） 建立或啓用事實表索引
(5） 如果有必要 ，將分區表合併到 一起
(6） 確認每個維度表在代理鍵列具有唯 一索引
(7） 啓用事實表與維度表之間的外鍵約束
四. 開發增量式 ETL 過程
增量 ETL 過程的最大挑戰之一是區分新的 、發生變化的以及被刪除的行 。在插入 、刪除、更新流處理之後 ，ETL 系統可以按照幾乎相同的歷史數據加載業務規則執行轉換工作 。
維度和事實的歷史加載包含大量的或整個的插入工作 。在增量處理過程中 ，主要執行 插入 ，但對維度表和某些事實表的更新是不可避免的 。更新和刪除在數據倉庫環境中是非常昂貴的操作，因此我們將描述改進這些任務執行性能的技術 。
4.1 第 7 步：維度表增量處理過程
正如您所期望的 ，增量 ETL 系統開發是從維度表開始 。維度增量處理與前文描述的歷史處理類似。
維度表獲取
多數情況下，客戶主文件或產品主文件都可以成爲維度的單一來源 。另外也存在一些 情況，原始來源數據既涉及維度也涉及事實數據 。
通常最簡單的方法是將維度表當前快照組織爲 一個整體並通過轉換步驟確定什麼發生了變化以及如何處理變化 。在大型維度表中查找每個條目需要花費大量的時間 ，即使變化發生在存在的條目上。
如果可能，構建只獲取那些發生變化的行 。如果源系統維護 一個變化類型的指示器的 話 ，這樣做特 別方便且有價值 。識別新的和變化的維度行
DW/BI小組將識別新的 、更新的、刪除的行的責任推給源系統擁有者將帶來巨大的問 題。在此情況下，ETL 過程需要執行昂貴的比較操作以發現新的和變化的行 。
若輸入數據是乾淨的 ，則非常容易發現新的維度行。原始數據具有操作型自然鍵 ，該鍵必須與當前維度行的同樣的列匹配 。記住 ，維度表中的自然鍵就是一個普通的維度屬性 ， 它不是維度的代理主鍵。
通過針對主維度的輸入流執行查詢，比較自然鍵，可以發現新的維度成員 。不滿足查詢條件的所有行均爲新的維度成員，應該將它們插入到維度表中。
如果維度包含類型 2 屬性 ，將行中有效日期列設 置爲維度成員出現在系統中的日期 。 如果是在晚間處理該工作，那麼這個時間通常是昨天。將行結束日期列設 置爲 當前行的默 認值 。這個值通常 是系統能夠支持的，指向遙遠未來的最大的日期 。應當避免在結束日期 列使用空值，因爲如果試圖將某一特定值與空值進行比較 ，則關係數據庫可能會產生錯誤 或返 問未知的特殊值 。
一步是確定到來的維度行是否有變化。最簡單的技術是一列一列地對輸入數據與存儲在主維度表巾的當前對應成員進行比較。
如果維度比較大，包含 100 萬行 ，採用簡單的列問比較的技術可能 太慢，特別是如果維度表中的列還比較多的情況下。比較好的替換策略是使用哈希或校驗功能加快比較處理的速度。可以在維度表中增加兩個新的管理列 ：哈希類型 1 和哈希類型 2 。應當在哈希類型 1 列放置連接類型 1 屬性的哈希值 ，同樣道理應用於哈希類型 2。哈希算法將非常大的字符串轉換爲相對小得多的且幾乎具有唯一性的值 。哈希值在維度表中計算及存儲 。然後用完全相同的方法對輸入行集合計算哈希值 ，並將它們與存儲的值比較 。與單一的 、相對較短的字符串列比較比成對比較大量不同列的方法更有效 。另外，關係數據庫引擎可能包含類似 EXCEPT 語法能夠確保高性能地執行發現改變行的查詢。
作爲一種一般性的原則 ，不應當刪除己經在源系統中被刪除的維度行 ，因爲這些維度 成員仍然可能與數據倉庫中的事實表數據存在關聯 。處理維度屬性的變化
ETL 應用包含確定如何處理己經存儲在數據倉庫中的屬性值變化的業務規則 。如果修 改的描述被認定是對先前信息的合法的且可靠的更新，則必須使用緩慢變化維度技術 。
準備維度行的第 1 步是決定是否已經擁有該行 。如果所有的輸入維度信息與維 度表中 的對應行匹配，則不需要採取進 一步的行動 。如果維度信息發生了變化 ，則可以將變化應 用到維度中 ，例如類型 1 或類型 2。
注意：
類 型 3 需要改變維度表結構 ，建立新的列 集合以擁有該屬性的 “先前” 與 “ 當前” 版本。此 類結構化改變很少應用到 ETL 系統中 ，更常見的是作爲數據模型的 一次性變化來處理 。
處理獲取階段的變化維度記錄的查詢和鍵分配邏輯 。在此情況下 ，邏輯 流程並不能使輸入數據流限制於僅僅針對新的或 變化的行 。
4.2 第 8 步：事實表增量處理過程
多數數據倉庫都非常巨大 ，因此要在一個單一時間窗口內完全替換事實表是很難實現的。相反 ，新的和更新的事實行都採用增量處理方式 。
注意：
只加載那些在上一次加載完成後發生變化和新增的記錄是非常有效的方法 。這種情況特別適合具有雜誌風格的系統 ，其歷史絕不會發生改變 ，僅允許對當前期進行調整 。
事實表增量處理的 ETL 處理過程與歷史加載不同，歷史ETL處理不需要完全實現自動化，您可以暫停該過程以檢查數據併爲下一階段做好準備 。作爲比較 ，增量處理必須完全自動地完成。
事實表獲取與數據質量檢查點
一旦從源系統獲得了發生變化的和被更新的事實行，就必須在過渡區中建立一個未轉換數據的拷貝。同時，對有關原始獲取數據 的數據質量度量開展計算工作 。數據過渡包含三種意圖 ：
• 爲實現審計歸檔。
• 爲後續的數據質量驗證提供開始點 。
• 爲重啓過程提供開始點 。事實錶轉換與代理鍵流水線
增量事實數據的代理鍵流水線與歷史數據的代理鍵流水線類似 。主要的差別在於違反參照完整性的錯誤處理方面 ，增量事實處理必須自動化執行。處理違反參照完整性的方法 有以下幾種：
• 終止加載 。這不是 一個常用的方法 ，但在大多數 ETL 工具中，該方法常常是默認的配置方法。
• 拋棄錯誤行。某些情況下 ，丟失維度值是一種信號，表明數據與底層數據倉庫的 業務需求不相關。
• 將錯誤行寫入文件或表中以便後續分析 。設計一種機制將 需要改正的行移入掛起 文件中 。對財務系統來 說，該方法不是一個好的選擇 ，在這樣的系統中 ，所有的行都需要加載。
• 通過建立虛擬維度行並返回其代理鍵到流水線中對錯誤行進行修改 。在增量代理鍵流水線中最有吸引力的處理違反參照完整性錯誤的方法是在執行過程中爲未知 的自然鍵建立虛擬維度行 。自然鍵是有關維度成員的僅有的信息塊 ，所有其他屬 性必須被設置爲默認值 。當有關維度成員的詳細信息可用時 ，該虛擬維度行將 以 類型 1 進行更新 。
• 通過映射到每個維度中單一的未知成員修改錯誤行 。該方法不是我們推薦的方法 。 問題是，對所有事實表獲取中得到的未知自然鍵值 ，所有錯誤行被映射到同 一個 維度成員上。
對大多數系統來說，針對查詢 、視圖或物理表（維度表的子集）來執行代理鍵查找。維度錶行被過濾，以便能夠僅針對當前版本的每個維度成員進行查找工作 。
延遲到來的事實與代理鍵流水線
在大多數數據倉庫中 ，增量加載過程都是在午夜後不久開始 ，同時需要處理前一天發生的所有事務 。然而 ，也存在一些事實延遲到達的情況 。這種情況通常發生在數據源是分佈式的 ，處於多臺機器上甚至是全球範圍內的，連接或延遲問題導致不能及時完成數據收集工作。
如果所有維度都以類型 1重寫模式被管理的話，延遲到達事實不會存在什麼特別的挑戰。但是多數系統都同時包含類型 1 和類型 2 屬性 。延遲到達的事實必須與事實發生時有 效的維度成員版本關聯 。要實現這一工作需要對維度表中的行開始和結束有效日期進行查詢。增量事實表加載
在歷史事實加載時，重要的是採用快速加載技術 。在大多數數據倉庫中，對增量加載來說，這些快速加載技術是無法執行的 。快速加載技術通常對目標 表有嚴格的條件要求（例如，空或未索引） 。對增量加載來說 ，使用非快速加載技術通常比完全插入或索引表更快 。 對小型到中型系統來說，插入操作的性能通常是比較適合的。
若事實表非常大 ，出於管理方面的考慮 ，應當對事實表進行分區 。如果增量數據始終 被加載到空的分區中 ，則可以使用快速加載技術 。在每天加載的情況下 ，您可能會在每年 建立 365 個新的事實表分區 。這樣做 ，對那些包含較長曆史的事實表來說 ，可能會建立了 太多的分區 。因此考慮設計一個將日分區合併爲按周或按月進行分區的處理方法 。加載快照事實 表
最大的事實表通常是事務型的 。事務事實表通常僅通過插入進行加載 。週期快照事實 表通常在月末被加載 。當前月的數據有時會在當前月至今的每一天被更新 。在此情況下， 按月的事實表的分區使 重新加載當前月的工作具有極高的性 能。
累積快照事實表監控相對較短的存活過程 ，例如訂單填充 。累積快照事實表的每個事實行在其整個生命週期中會多次發生改變 。儘管累積快照幾乎總是比 其他兩類事實表小得多，但對該表維護需要較高的成本 。加速加載週期
僅處理那些發生變化的數據是加速 ETL 週期的辦法之 一。下面介紹幾種其他技術 。
1）提高加載頻率
儘管從按月或按周加載處理轉變到每晚加載是 一個巨大的飛躍 ，但縮短加載窗口的確 不失爲一種有效的方法 。每天晚上處理與每月處理比較 ，僅需要處理後者 1/30 的數據量。 多數數據倉庫都採用每晚加載一次的週期。
如果晚間加載成本太高 ，可以考慮在白天執行 一些針對數據的預處理工作 。白天時間將數據移動到過渡數據庫或操作型數據庫並在此執行數據清洗任務。午夜後，將維度成員的多個變化合並，執行最後的數據質量檢查，分配代理鍵，最後將數據移入數據倉庫中 。
2） 並行處理
另外一種縮短加載時間的方法是並行 化 ETL 過程。並行化可以以兩種方式展開 ：多步 並行化運行和單步並行化運行 。
• 多步加載 。ETL 任務流被劃分爲幾個同時提交的獨立任務 。您需要仔細考慮每個 任務涉及何種工作 ：主要的目標是建立 獨立的任務 。
• 並行執行 。數據庫本身也可以識別特定 的能夠並行執行的任務 。例如 ，建立索引 通常可以在機器上可用的多個處理器中並行 處理。
注意：
將過程劃分爲 並行執行的步驟包含好的方法和不好的方法 。並行化的簡羊方法是獲取所有源數據 ，然後加載並轉換維度，最後同時在事實表和維度表中檢查參照完整性 。遺憾的是，該方法可能不夠快 一一也許會比更簡單的順序方法慢得多 ，因爲每個並行處理的步 驟都需要競爭系統資源 ，例如網絡帶寬 、IO 和內存 。要構建良好的並行任務 ，不僅需要考慮步驟的邏輯順序 ，也需要考慮系統資源 。
3） 並行結構
您可能設置一種三方鏡像或兩個服務器 的集羣配置以維護對數據倉庫的連續加載 ，一個服務器管理加載，另外一個處理查詢 。維護窗口將縮減到每天幾分鐘 ，用於交換附加在每個服務器上的磁盤 。這種方式是提供系統高可用性的最佳方式。
按照對需求和可用性預算的要求，可以採用幾種類似的方式實現表、分區和數據庫 。 例如，可以離線加載分區或表 ，並以最小的停機時間交換它 ，使其在線可用 。其他系統包 含數據倉庫數據庫的兩個版本 ，一個版本用於加載 ，一個版本用於查詢 。雖然這樣的方式效率並不高 ，但成本低，想要的功能可以由集羣服務器提供 。
4.3 第 9 步：聚集表與 OLAP 加載
從邏輯上來看 ，聚集表易於建立 。聚集表是將大型聚集查詢結果存儲到一個表中 。從針對事實表的查詢來建立聚集表的問題，當然發生在事實表太大以至於無法在加載窗口內處理的時候。
如果聚集表包括對日期維度的聚集結果，也許以月爲粒度 ，聚集維護過程將更加複雜 。 當前月數據必須被更新 ，或者刪除及重建 ，以反映當前天的數據 。
如果聚集表是按照作爲類型 1 重寫的維度屬性定義的 ，類似問題將會發生 。維度屬性 的所有類型 1 變化將會影響所有的事實表聚集 以及按照該屬性定義的 OLAP 多維數據庫 。 ETL 過程必須將原有聚集層次 的事實刪除並以新值替代 。
保持聚集與底層 的事實數據同步是聚集管理系統中極其重要的工作 。如果查詢直接面對底層細節事實或來自預先計算的聚集，則不要指望建立一個返回不同結果集的系統。
4.4 第 10 步：ETL 系統操作與自動化
理想的 ETL 操作以熄燈的方式運行定期加載過程 ，而不需要人爲干預 。儘管這是一個 很難達到的目標 ，但我們可以盡力接近這一理想 。
調度任務
調度任務通常是比較明確的 。ETL 工具應當包含調度任務並在一定時間開始的功能 。 大多數 ETL 工具還包含在第 一個任務成功執行完成後 ，協調執行第二個任務的功能 。通常將 ETL 任務流設置爲在一定時間發起 ，然後查詢數據庫或文件系統 ，觀察某個事件是否已 經發生 。
還可以編寫腳本執行此類控制任務 。每個ETL 工具具有從操作系統命令行激活任務的 途徑。多數組織非常願意使用腳本語言 ，例如 Perl ，來管理任務調度工作 。自動處理預料之中的例外和錯誤
儘管開始工作是比較容易的 ，但要保證這些任務能夠順利完成 ，優雅地處理數據錯誤 和例外 ，就比較困難了 。綜合錯誤處理在 ETL 任務的一開始就需要加以考慮並建 立。優雅地處理未知的錯誤
有些錯誤是可以預料到的 ，例如 ，接受早到的事實或列中存在空值都是比較常見的 。 對這些錯誤 ，一般可以設計ETL系統來修改數據並繼續處理 。而有些錯誤是完全無法預測的，其範圍包括在處理過程中 ，由於經歷停電導致接受混亂的數據。
我們希望得到 ETL 工具特性和系統設計實踐來幫助克服這些例外 。一般建議在事實表上爲被加載的新記錄配備單 一的順序分配的代理鍵列 。如果某個大型加載任務遭遇到意外的停機，事實表代理鍵允許重新從可靠點開始加載 ，或者通過對範圍連續的代理鍵進行約束延後加載 。
五. 實時的影晌
實時處理是數據倉庫中日益增長的常見需求之 一。數據倉庫系統可能會存在強烈的實 時性需求 。一些業務用戶希望數據倉庫能夠連 續不斷地按天更新 ，對過時數據 一點也不感興趣。建立實時 DW/BI 系統需要收集對實時數據業務 需求的準確的理解並確認適當的 ETL 結構，包括與固定平臺配搭的範圍廣泛的技術 。
5.1 實時分類
詢問業務用戶他們是否希望 “ 實時” 發佈數據對於 DW/BI 小組來說是一個令人沮喪的經歷 。在沒有任何約束的前提下，多數用戶回答說，“聽起來不錯 ，放手去做吧 ！” 這樣的 回答基本上沒有什麼價值 。
爲避免出現這種情況 ，我們建議將實時設計面臨的挑戰劃分爲 三個類別 ，分別稱爲即時、日內和每天。在與業務用戶討論他們的需求和之後在設計我們的數據發佈流水線時，都採用不同的選項進行討論，並使用這些術語 。下表總結了不同的發佈速度環境下將 產生的問題。
即時（instantaneous）意味着屏幕上所 見的數據表示的是源事務系統每個時刻的真實狀 態。當源系統狀態發生改變時 ，屏幕將實時且同步響應 。即時性的實時系統通常作爲企業 信息集成(Enterprise Information Integration , Ell）解決方案被實現，其源系統本身負責 主持 遠程用戶的屏幕更新並對查詢請求提供服務 。顯然，該類系統必須限制查詢請求的複雜性 ， 因爲所有的處理都是在源系統完成的 。Ell 解決方案通常包括不需要在 ETL 流水線上緩存數據 ，因爲按照定義，ETL 解決方案在源系統與用戶屏幕之間沒有延遲 。某些情況下 ，可能邊擇採用即時性的實時解決方案 。庫存狀態跟蹤可能是一個好的例子 ，其決策人員具有爲客戶實時提交可用庫存的權利。
日內（intra-day）意味着屏幕上可見的數據每天被更新多次，但是不 能保證這些當前被顯示的數據肯定是最新的真實數據 。我們中的多數人都熟悉股票市場報價數據是當前15分鐘內的數據，但並不是即時數據 。以一定頻率發佈實時數據（以及更慢一些的每天數據）的技術與即時實時數據發佈的技術具有較大的差別。以一定頻率發佈數據通常被作爲傳統 ETL 結構中的微批量處理 。這意味着數據將經歷各種各樣的變化數據的捕獲 、獲取，過渡到 ETL 後端數據倉庫的文件存儲 ，清洗並執行錯誤檢查 ，遵守企業數據標準 ，分配代理鍵以及可 能的其他一些轉換工作使數 據準備好可以加載到展現服務器中 。幾乎所有這些步驟 ，在一 個 ETL解決方案中必須被忽略或基本不存在 。日內發佈數據和每天發佈數據的主要差別在於前兩步 ：變化數據捕獲和獲取 。爲每天從源系統中多次捕獲數據 ，數據倉庫通常必須利用高帶寬通信通道 ，例如遺留應用的消息隊列流量 ，累積事務日誌文件，或每當有事情發 生時米自事務系統低級別的數據庫觸發器等。
每日（daily）意味着屏幕上可見的數據被當作批文件而在前一個工作日結束後從源系統中下載或調整是合法的 。對每日數據我們提供一些建議 。更正原始數據的過程通常在工作日結束時在源系統運行。當該調整可實現時 ，也標誌着 ETL 系統執行一個可靠和平穩的數據下載 。如果您處於這樣的環境中，應當向業務用戶解釋如果他們要求即時或日內被更新的數據時 ，他們將經歷何種妥協 。每日更新數據通常涉及獲得由源系統準備的批文件或者當源系統的就緒標誌被設置後 ，通過執行獲取查詢獲得 。當然，這是一種最簡單的獲取場景 ，因爲您只需要等待源系統準備好並可用 。
5.2 實時結構權衡
對實時需求的響應意味着您需要改變 DW/BI 結構，加快數據到用戶屏幕的速度 。結構性的選擇涉及對影響數據質量和管理的問題的權衡 。
您可能認爲ETL 系統所有者的總體目標是不要發生變化或通過轉移到實時系統進行折中。您可能一如既往地考慮數據質量、集成 、安全、兼容性 、備份、恢復和歸檔等問題， 這些問題在開始設計實時系統前已經在做 。如果您有同感 ，那麼請仔細閱讀後續部分 ！後 續部分討論當需要構建具有更實時性的結構時需要考慮的典型權衡 。
替換批處理文件
考慮將批處理文件獲取替換爲從消息隊列或事務日誌文件中獲取 。源系統發佈的批處理文件可以表示一種被清洗且具有一致性的源數據 。批處理文件可包含那些完成的事務的結果的記錄 。批處理文件中的外鍵可能被分解 ，例如當文件包含某個其完整的身份可能被 發佈到批處理文件中的新客戶的訂單時 。另一方面，消息隊列和日誌文件數據是原始的即時數據，可能並不屬於任何源系統中的更正過程或業 務規則執行 。最壞的情況下 ，這樣的原始數據有三種可能 ：①因爲額外的事務可能尚未到達而未被更正或完成 ：②包含 DW/BI 系統尚未處理的未分解的外鍵 ；③需要並行化的面向批處理的 ETL 數據流來更正甚至替換 每天 24 小時的最新的實時數據 。如果源系統隨後對消息隊列或日誌文件中的輸入事務應用複雜的業務規則，則您真的不希望在ETL 系統中重新執行這些業務規則 。限制數據質量檢查
考慮限制僅針對列檢查的數據質量檢查並簡化解碼查詢。由於通過 ETL流水線的數據處理時間被縮減了 ，因此可能需要去掉一些高開銷的數據質量檢查 ，特別是結構方面的以及業務規則方面的檢查 。記住列檢查涉及單一字段測試與／或簡單查詢以替換或擴展己知值。即使在最爲激進的實時應用中 ，也應當保留大多數的列檢查 。但是按照定義 ，結構檢查和業務規則檢查需要多個字段 ，可能涉及多個表 。您可能沒有時間傳遞字段的地址塊到某個地址分析器中去 。您可能不需要檢查表間的參照完整性。您可能無法通過 Web 服務執行遠程信用檢查 。所有這些可能都需要通知用戶 ，他們使用的數據是臨時的且存在不可靠狀態的原始實時數據 ，可能需要您實現並行的面向批處理的 ETL 流水線 ，用於週期性地以檢查後的數據重寫實時數據 。連接事實與維度
應當允許早先得到的事實與舊版本的維度共存 。在實時環境下 ，通常事務事件被接收到了 ，而其環境尚未更新（例如客戶的身份） 。換句話說 ，事實在維度到達前就先到了 。如果實時系統不能等待維度 ，則如果維度可用的話 ，必須使用維度的舊拷貝 ，或者使用具有一般性的空的維度版本 。如果收到修改後的維度版本 ，則數據倉庫可能會決定將它們放入熱分區或延遲更新維度直到批處理過程接管爲止 ，可能在一天的結束時 。無論如何，用戶需要理解可能會存在短暫的時間窗口，其維度無法準確地描述事實 。消除數據過渡區
某些實時結構 ，特別是 Ell 系統，流數據直接從生產源系統到用戶的屏幕 ，並未將數 據寫入ETL流水線中的持久性存儲中 。如果此類系統是由 DW/Bl 小組負責的，則小組應當與高級主管就是否需要備份 、恢復、歸檔，以及兼容性是否能夠滿足或者這些責任現在 是否是生產源系統唯一的關注等進行嚴肅的討論。
5.3 展現服務器上的實時分區
爲支持對實時性的需求，數據倉庫必須無縫地擴展其己經存在的歷史事件序列到當前時刻。如果客戶在前一個小時發出訂單 ，那麼您需要在完整的客戶關係環境中看到這一訂單 。此外，您想要跟蹤這些最新訂單每小時的狀態以及在一天中 的變化情況 ，即使生產事務處理系統與 DW/BI 系統之間存在的差別己縮減到 24 小時 ，業務用戶的即時性 需求也仍 然需要數據倉庫以實時數據填充其間存在的差異。
響應這一處理的設計解決方案之一是建立實時分區 ，將其作爲傳統的靜態數據倉庫的一種擴展 。爲實現實時報表 ，建立一種特殊的分區 ，其物理存在和管理與傳統數據倉庫表分開 。理想情況下，實時分區是一種真實的數據庫分區 ，其中正在考慮的事實表按照活動日期分區。
無論發生何種情況 ，理想的實時分區應當滿足下列難辦的需求集合 ：
• 包括上一次更新靜態數據倉庫 以來發生的所有活動。
• 儘可能無縫連接靜態數據倉庫事實表的粒度和內容 ，作爲理想的真正的事實表物 理分區 。
• 被輕巧地索引而到達的數據能夠不斷地 “ 滴入”。 理想情況下 ，實時分區應當完全不用索引 。然而 ，這在某些 RDBMS 中是不可能實現的，其建立的索引與分區 模式邏輯上是不同的 。
• 即使缺乏索引，通過將實時分區放入內存中，也可以支持高度敏感的查詢 。 是在事務和週期快照事實表中 ，實時分區都可 以被有效地使用。我們還未發現需要將這種情況用累積快照事實表的情況。
事務實時分區
如果靜態數據倉庫事實表存在事務粒度 ，那麼它對源系統中的每個獨立事務從 “ 被記求的歷史” 開始包含確切 的一行。這樣的實時分區與其底層的靜態事實表具有同樣的維度結構 。它僅包含上一次您定期加載事務事實表直到午夜爲止的事務 。實時分區可能完全未被索引，原因可能是囚爲您想要維護 一個不斷開放的加載窗口 ，也可能是因爲沒有時間序列（因爲 ，表中僅保持今天的數據 ）。
在相對比較大的售業環境中，大約每天會產生 1000 萬事務 。靜態事實表會很人 。假設句箇中務粒皮行包含 40 個字節寬（7個維度加上 3個事實，都被包裝到 4 個字節的列中）。 每天將會積累 400MB 的數據。一年後 ，這一數據會達到約 150GB 的原始數據。此類事實點包含大量的索引並支持聚集 。但是 400MB 的每日實時分片可以放到內存中。實時分區趨向非常快的加載性能 ，但是同時提供快捷的查詢性能 。週期快照實時分區
如果靜態數據倉庫事實表具有周期粒度（例如按月），則實時分區可被視爲當前熱滾動月。假設有一個包含 1500 萬賬戶的大型零售銀行 。賬戶的靜態事實表粒度是以月爲基礎的。36 個月的時間序列將在事實表中產生 5.4 億行事實 。另外，該表可能存在大量聚集索引以提供良好的查詢性能。另一方面 ，實時分區僅僅是當前月的圖像，隨着月的變化 ，會不斷被更新 。半可加的餘額和完全可加的事實在報告期被頻繁地調整 。在零售銀行 ，涉及所有的賬戶類型的超類事實表可能非常窄 ，也許包括4個維度和4個事實 ，產生的實時分 區可能有 480MB 。實時分區仍然可以放入內存中 。
在月末的那一天 ，週期實時分區可以比較幸運地僅僅融合大多數當前月中少 量的不穩 定的事實表 ，再次開始時可以將實時分區清空 。
參考:
- 《數據倉庫工具箱 維度建模權威指南》第三版