ETL架構中考慮的六個關鍵因素
2024-07-21 02:45:09
供稿：網友
原文地址：http://intelligent-enterPRise.informationweek.com/showArticle.jhtml?articleID=220600174&pgno=1
設計一個數據倉庫ETL架構中有些關鍵因素是我們應該必須關注？它將決定整個數據倉庫ETL架構的成本、復雜性、甚至最后數據倉庫的成敗。本文闡述了六個關鍵因素。
是否應該使用集成的ETL工具？
在哪個階段整合數據，如何做數據整合？
選擇哪種變化數據捕獲機制？
是否需要設置Staging Area
哪個階段應該進行數據質量控制？
數據的加載頻率？
是否應該使用集成的ETL工具？
在ETL系統架構中首先需要考慮的一個基本因素是應該使用手工寫ETL代碼方式還是采用集成的ETL工具。它不簡單是技術和license的問題。架構應 該從更加長遠的角度考慮，它將會影響我們整個的ETL環境、設計方法、元數據管理策略、實施的周期等等。
目前，基于ETL系統的規模和管理角度考慮，大部分ETL架構應該考慮使用集成的ETL工具，集成的工具采用圖形化、拖 拽組件的方式進行ETL開發。然 而，一些老的開發人員更愿意使用直接寫存儲過程或是其他代碼的形式實現ETL功能，它們更熟悉編程語言，認為這種方式更好。
ETL工具并不會從一開始就帶來顯著的好處，它的優點會在數據倉庫不斷的迭代實施中逐漸顯現。使用ETL工具將會在可維護性、文檔化、元數據方面獲益不少。
我的觀點：在以前工作實施的項目中使用過兩個ETL工具－DataStage和Sagent。ETL 工具主要有以下幾方面的優勢：在性能方面主要表現在并行、流水線技術、靈活的分區技術；較好的元數據管理，現在的ETL工具大部分基于元數據開發，所有 MAPPING和ETL的血緣關系自動生成，自動維護，多數據源支持：可以支持不同類型的源系統和目標系統的抽取和加載。但是它也有其不足之處，就是受組 件功能所現，不利于處理較為復雜的業務邏輯，數據倉庫系統中的業務邏輯往往較為復雜，程序語言這時就體現出他的先天優勢-靈活性。在國內往往是兩者結合起 來在數據倉庫中應用比較好，在ETL的抽取、和數據整合階段，涉及業務邏輯較為簡單，選擇使用ETL工具；而在偏分析應用的數據處理ETL層使用編寫 ETL代碼方式更為合適。
在哪個階段整合數據，如何做數據整合？
數據整合對于IT來說是個大的話題，它的終極目標是所有系統都無縫地整合在一起。企業有一個全局的、統一的視角分析數 據。在許多時候，本應該在事務交易系 統中就應該整合的數據，被強推在數據倉庫中處理。整合的最大關鍵問題，是我們需要知道哪些應該整合在一起，整合的程度。整合的粒度必須要符合實際的業務規 則要求，在實際中，往往不同部門確實對于同一個數據有不同的統計業務規則需求，我們是不能進行整合的。按照維度建模的思想，整合的目標是一致的維度和一致 的事實。一致的維度意味著整合整合后，不同的部門，系統的人員從分析數據的角度、粒度是一樣的；一致的事實意味著指標數據算法的統一。
我的觀點：我們在進行數據倉庫數據整合的過程中，可以基于從兩方面進行整合：邏輯上的整合和物理上的整合。我們在邏輯上 可以從企業的全局視角，而不以非常 詳細的業務系統流程為對象進行實體抽象，抓住不同系統間的本質，進行一定的邏輯抽象，而做到邏輯上的整合。在物理實現上，根據具體業務規則，能整合的源系 統進行整合處理，不能整合的可以進行個性化物理實現。
選擇哪種變化數據捕獲機制？
數據倉庫系統在初始加載后，不管從效率、時間窗口考慮，ETL系統都不可能處理全量數據。增量數據如何捕獲就是一個ETL系統重要的能力。增量數據捕獲聽起來簡單，但是它卻是一個非常復雜的事情。必須根據源系統的狀況，數據量的情況采用不同的策略，
目前常見的策略有：
時間戳的的方式：源系統必須記錄了表中記錄的最新更新的時間，根據更新時間進行抽取。
日志解析：解析數據庫系統的日志文件，獲取當天在數據庫上發生的操作，而捕獲變化數據。
文本比較：前后兩天的數據進行全文本比較，其中根據業務邏輯的需要可以采用部分字段比較和HASH比較的方式。
源系統記錄方式：在源系統中建立觸發器，或者應用系統直接記錄變化數據的情況。這種情況對源系統依賴極大，簡單，但是，很難實施 。
是否需要設置Staging Area
目前許多ETL工具支持不落地的流水線數據處理，數據直接處理完成進入最后的目標表。從性能上看，它確實是一個不錯的選擇。但是它有可能不是一種最好的處理策略，以下幾種情況，數據登臺區還是有必要的。
一些CDC(change data capture)工具需要進行兩份不同時間數據的比較。
一些組織選擇使用數據登臺區進行數據歸檔。
數據登臺區可以做到一次抽取，后面的ETL過程多次重運行，重運行不依賴于源系統的開放程度。
長時間的ETL處理過程，超過源系統開放的時間窗口，為了對源系統影響小，可以先抽取，而不做數據轉換。
Staging Area的可選擇的處理方式也有多種，在源系統時間窗口允許的情況下，可以選擇并行登臺，數據Staging和轉換并行進行?？杉骖櫺屎蜕厦?，2，3的好處。
哪個階段應該進行數據質量控制？
數據質量是在數據倉庫中非常關注的一個問題，他影響數據的可信度，甚至整個數據倉庫的可信度。數據質量問題不僅僅是數據 倉庫團隊的問題，是整個企業IT系統 的問題，但是往往這種問題全部推給了數據倉庫處理。我們又很難抉擇在哪個階段進行數據質量控制，如何進行控制？進行臟數據處理的策略主要有：
停止ETL過程，等待人工介入處理。
把臟數據reject到另外一個地方，再進行處理。
將臟數據打上標簽，建立一個錯誤數據維度并按業務邏輯繼續處理。
第三中策略是目前為止較好的一種策略。他既不全面影響ETL過程調用，又可以根據業務邏輯的實際情況，在后面根據錯誤數據的不同情況，分別處理，不影響業務數據的正確展現。
數據的加載頻率？
數據的加載頻率 是指與源系統相比，ETL系統延遲多久加載數據。這個因素應該結合成本、業務需求考慮。數據加載的頻率對ETL架構的成本和復雜性影響很大。采用何種策略 是和業務需求相關的，有些業務應該要求能實時的分析數據，而有很多應該，并沒有這樣的要求。目前主要有三種加載策略：
實時加載
每天多次加載
每日一次加載
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/wsbupt/archive/2009/12/30/5109393.aspx
