第一篇：ETL問題總結

1.如果kettle端使用readonly賬號登錄SQLServer服務器，調用DB中的一個sp（傳入參數并寫入到該DB的表中），1.1只讀賬號能將參數能傳入sp中嗎？ 1.2如果能傳入，sp能執行寫入操作嗎？

2.關于各種變量、參數的設置聲明，傳入參數，取出參數的問題

2.1在kettle端圖形界面，有一種能用“CTR+ALT+空格”來選擇的變量,這是什么變量？為什么在總job中的 “設置變量”控件中，用“CTR+ALT+空格”來選擇，該變量既能作為變量名來被選擇，又能作為屬性文件名來被選擇？（在轉換中該變量只能作為變量名被選擇）其中的一個變量（END_TIME）是通過設置設置變量設置JVM產生的，但是它一直存在里面，這些變量可以在哪里管理，比如實現刪除END_TIME變量的操作。如下圖。

2.2除了kettle.properties一個job可以使用其他自定義的properties設置文件嗎?(已解決)

2.3 命名參數怎么設置,怎么傳入參數怎么獲取參數,總控job的命名參數,和轉換的命名參數有什么區別?(已解決)通過點擊job或者轉換的屬性可以設置命名參數.可以同時指定默認值,不指定的話就要 可以使用,只要指定路徑,文件名,就能讀取到自定義配置文件中的配置參數.在運行job時輸入.總控Job的命名參數在整個job包括其中的控件,子job中都有效,而轉換的命名參數只在該轉換中有效.3.sp參數傳入對參數有什么要求嗎.(已解決)

要求的參數:順序上符合sp的參數;類型要對的上 格式要對得上

例如:時間的類型,sp中要求datetime型的參數,且格式要求為:yyyy/MM/ddHH:mm:ss

;參數從數據庫的一張表中獲得(表輸入->設置變量->獲取變量).變量獲取過來后是date型,但是沒有指定格式,因此需要在獲取變量中設置其格式為sp要求的格式.

第二篇：ETL學習心得

ETL學習心得：探求數據倉庫關鍵環節ETL的本質

元數據是描述數據的數據，他的含義非常廣泛，這里僅指ETL的元數據。11 : 10 探求ETL本質之六（元數據漫談）對于元數據（Metadata）的定義到目前為止沒有什么特別精彩的，這個概念非常廣，一般都是這樣定義，“元數據

做數據倉庫系統，ETL是關鍵的一環。說大了，ETL是數據整合解決方案，說小了，就是倒數據的工具。回憶一下工作這么些年來，處理數據遷移、轉換的工作倒還真的不少。但是那些工作基本上是一次性工作或者很小數據量，使用access、DTS或是自己編個小程序搞定。可是在數據倉庫系統中，ETL上升到了一定的理論高度，和原來小打小鬧的工具使用不同了。究竟什么不同，從名字上就可以看到，人家已經將倒數據的過程分成3個步驟，E、T、L分別代表抽取、轉換和裝載。

其實ETL過程就是數據流動的過程，從不同的數據源流向不同的目標數據。但在數據倉庫中，ETL有幾個特點，一是數據同步，它不是一次性倒完數據就拉到，它是經常性的活動，按照固定周期運行的，甚至現在還有人提出了實時ETL的概念。二是數據量，一般都是巨大的，值得你將數據流動的過程拆分成E、T和L。

現在有很多成熟的工具提供ETL功能，例如datastage、powermart等，且不說他們的好壞。從應用角度來說，ETL的過程其實不是非常復雜，這些工具給數據倉庫工程帶來和很大的便利性，特別是開發的便利和維護的便利。但另一方面，開發人員容易迷失在這些工具中。舉個例子，VB是一種非常簡單的語言并且也是非常易用的編程工具，上手特別快，但是真正VB的高手有多少？微軟設計的產品通常有個原則是“將使用者當作傻瓜”，在這個原則下，微軟的東西確實非常好用，但是對于開發者，如果你自己也將自己當作傻瓜，那就真的傻了。ETL工具也是一樣，這些工具為我們提供圖形化界面，讓我們將主要的精力放在規則上，以期提高開發效率。從使用效果來說，確實使用這些工具能夠非常快速地構建一個job來處理某個數據，不過從整體來看，并不見得他的整體效率會高多少。問題主要不是出在工具上，而是在設計、開發人員上。他們迷失在工具中，沒有去探求ETL的本質。

可以說這些工具應用了這么長時間，在這么多項目、環境中應用，它必然有它成功之處，它必定體現了ETL的本質。如果我們不透過表面這些工具的簡單使用去看它背后蘊涵的思想，最終我們作出來的東西也就是一個個獨立的job，將他們整合起來仍然有巨大的工作量。大家都知道“理論與實踐相結合”，如果在一個領域有所超越，必須要在理論水平上達到一定的高度

探求ETL本質之一

ETL的過程就是數據流動的過程，從不同異構數據源流向統一的目標數據。其間，數據的抽取、清洗、轉換和裝載形成串行或并行的過程。ETL的核心還是在于T這個過程，也就是轉換，而抽取和裝載一般可以作為轉換的輸入和輸出，或者，它們作為一個單獨的部件，其復雜度沒有轉換部件高。和OLTP系統中不同，那里充滿這單條記錄的insert、update和select等操作，ETL過程一般都是批量操作，例如它的裝載多采用批量裝載工具，一般都是DBMS系統自身附帶的工具，例如Oracle SQLLoader和DB2的autoloader等。

ETL本身有一些特點，在一些工具中都有體現，下面以datastage和powermart舉例來說。

1、靜態的ETL單元和動態的ETL單元實例；一次轉換指明了某種格式的數據如何格式化成另一種格式的數據，對于數據源的物理形式在設計時可以不用指定，它可以在運行時，當這個ETL單元創建一個實例時才指定。對于靜態和動態的ETL單元，Datastage沒有嚴格區分，它的一個Job就是實現這個功能，在早期版本，一個Job同時不能運行兩次，所以一個Job相當于一個實例，在后期版本，它支持multiple instances，而且還不是默認選項。Powermart中將這兩個概念加以區分，靜態的叫做Mapping，動態運行時叫做Session。

2、ETL元數據；元數據是描述數據的數據，他的含義非常廣泛，這里僅指ETL的元數據。主要包括每次轉換前后的數據結構和轉換的規則。ETL元數據還包括形式參數的管理，形式參數的ETL單元定義的參數，相對還有實參，它是運行時指定的參數，實參不在元數據管理范圍之內。

3、數據流程的控制；要有可視化的流程編輯工具，提供流程定義和流程監控功能。流程調度的最小單位是ETL單元實例，ETL單元是不能在細分的ETL過程，當然這由開發者來控制，例如可以將抽取、轉換放在一個ETL單元中，那樣這個抽取和轉換只能同時運行，而如果將他們分作兩個單元，可以分別運行，這有利于錯誤恢復操作。當然，ETL單元究竟應該細分到什么程度應該依據具體應用來看，目前還沒有找到很好的細分策略。比如，我們可以規定將裝載一個表的功能作為一個ETL單元，但是不可否認，這樣的ETL單元之間會有很多共同的操作，例如兩個單元共用一個Hash表，要將這個Hash表裝入內存兩次。

4、轉換規則的定義方法；提供函數集提供常用規則方法，提供規則定義語言描述規則。

5、對數據的快速索引；一般都是利用Hash技術，將參照關系表提前裝入內存，在轉換時查找這個hash表。Datastage中有Hash文件技術，Powermart也有類似的Lookup功能。

探求ETL本質之二（分類）

昨在IT-Director上閱讀一篇報告，關于ETL產品分類的。一般來說，我們眼中的ETL工具都是價格昂貴，能夠處理海量數據的家伙，但是這是其中的一種。它可以分成4種，針對不同的需求，主要是從轉換規則的復雜度和數據量大小來看。它們包括

1、交互式運行環境，你可以指定數據源、目標數據，指定規則，立馬ETL。這種交互式的操作無疑非常方便，但是只能適合小數據量和復雜度不高的ETL過程，因為一旦規則復雜了，可能需要語言級的描述，不能簡簡單單拖拖拽拽就可以的。還有數據量的問題，這種交互式必然建立在解釋型語言基礎上，另外他的靈活性必然要犧牲一定的性能為代價。所以如果要處理海量數據的話，每次讀取一條記錄，每次對規則進行解釋執行，每次在寫入一條記錄，這對性能影響是非常大的。

2、專門編碼型的，它提供了一個基于某種語言的程序框架，你可以不必將編程精力放在一些周邊的功能上，例如讀文件功能、寫數據庫的功能，而將精力主要放在規則的實現上面。這種近似手工代碼的性能肯定是沒話說，除非你的編程技巧不過關（這也是不可忽視的因素之一）。對于處理大數據量，處理復雜轉換邏輯，這種方式的ETL實現是非常直觀的。

3、代碼生成器型的，它就像是一個ETL代碼生成器，提供簡單的圖形化界面操作，讓你拖拖拽拽將轉換規則都設定好，其實他的后臺都是生成基于某種語言的程序，要運行這個ETL過程，必須要編譯才行。Datastage就是類似這樣的產品，設計好的job必須要編譯，這避免了每次轉換的解釋執行，但是不知道它生成的中間語言是什么。以前我設計的ETL工具大挪移其實也是歸屬于這一類，它提供了界面讓用戶編寫規則，最后生成C++語言，編譯后即可運行。這類工具的特點就是要在界面上下狠功夫，必須讓用戶輕松定義一個ETL過程，提供豐富的插件來完成讀、寫和轉換函數。大挪移在這方面就太弱了，規則必須手寫，而且要寫成標準c++語法，這未免還是有點難為最終用戶了，還不如做成一個專業編碼型的產品呢。另外一點，這類工具必須提供面向專家應用的功能，因為它不可能考慮到所有的轉換規則和所有的讀寫，一方面提供插件接口來讓第三方編寫特定的插件，另一方面還有提供特定語言來實現高級功能。例如Datastage提供一種類Basic的語言，不過他的Job的腳本化實現好像就做的不太好，只能手工繪制job，而不能編程實現Job。

4、最后還有一種類型叫做數據集線器，顧名思義，他就是像Hub一樣地工作。將這種類型分出來和上面幾種分類在標準上有所差異，上面三種更多指ETL實現的方法，此類主要從數據處理角度。目前有一些產品屬于EAI（Enterprise Application Integration），它的數據集成主要是一種準實時性。所以這類產品就像Hub一樣，不斷接收各種異構數據源來的數據，經過處理，在實施發送到不同的目標數據中去。

雖然，這些類看似各又千秋，特別在BI項目中，面對海量數據的ETL時，中間兩種的選擇就開始了，在選擇過程中，必須要考慮到開發效率、維護方面、性能、學習曲線、人員技能等各方面因素，當然還有最重要也是最現實的因素就是客戶的意象。

探求ETL本質之三（轉換）

ETL探求之一中提到，ETL過程最復雜的部分就是T，這個轉換過程，T過程究竟有哪些類型呢？

一、宏觀輸入輸出

從對數據源的整個宏觀處理分，看看一個ETL過程的輸入輸出，可以分成下面幾類：

1、大小交，這種處理在數據清洗過程是常見了，例如從數據源到ODS階段，如果數據倉庫采用維度建模，而且維度基本采用代理鍵的話，必然存在代碼到此鍵值的轉換。如果用SQL實現，必然需要將一個大表和一堆小表都Join起來，當然如果使用ETL工具的話，一般都是先將小表讀入內存中再處理。這種情況，輸出數據的粒度和大表一樣。

2、大大交，大表和大表之間關聯也是一個重要的課題，當然其中要有一個主表，在邏輯上，應當是主表Left Join輔表。大表之間的關聯存在最大的問題就是性能和穩定性，對于海量數據來說，必須有優化的方法來處理他們的關聯，另外，對于大數據的處理無疑會占用太多的系統資源，出錯的幾率非常大，如何做到有效錯誤恢復也是個問題。對于這種情況，我們建議還是盡量將大表拆分成適度的稍小一點的表，形成大小交的類型。這類情況的輸出數據粒度和主表一樣。

3、站著進來，躺著出去。事務系統中為了提高系統靈活性和擴展性，很多信息放在代碼表中維護，所以它的“事實表”就是一種窄表，而在數據倉庫中，通常要進行寬化，從行變成列，所以稱這種處理情況叫做“站著進來，躺著出去”。大家對Decode肯定不陌生，這是進行寬表化常見的手段之一。窄表變寬表的過程主要體現在對窄表中那個代碼字段的操作。這種情況，窄表是輸入，寬表是輸出，寬表的粒度必定要比窄表粗一些，就粗在那個代碼字段上。

4、聚集。數據倉庫中重要的任務就是沉淀數據，聚集是必不可少的操作，它是粗化數據粒度的過程。聚集本身其實很簡單，就是類似SQL中Group by的操作，選取特定字段（維度），對度量字段再使用某種聚集函數。但是對于大數據量情況下，聚集算法的優化仍是探究的一個課題。例如是直接使用SQL的Group by，還是先排序，在處理。

二、微觀規則

從數據的轉換的微觀細節分，可以分成下面的幾個基本類型，當然還有一些復雜的組合情況，例如先運算，在參照轉換的規則，這種基于基本類型組合的情況就不在此列了。ETL的規則是依賴目標數據的，目標數據有多少字段，就有多少條規則。

1、直接映射，原來是什么就是什么，原封不動照搬過來，對這樣的規則，如果數據源字段和目標字段長度或精度不符，需要特別注意看是否真的可以直接映射還是需要做一些簡單運算。

2、字段運算，數據源的一個或多個字段進行數學運算得到的目標字段，這種規則一般對數值型字段而言。

3、參照轉換，在轉換中通常要用數據源的一個或多個字段作為Key，去一個關聯數組中去搜索特定值，而且應該只能得到唯一值。這個關聯數組使用Hash算法實現是比較合適也是最常見的，在整個ETL開始之前，它就裝入內存，對性能提高的幫助非常大。

4、字符串處理，從數據源某個字符串字段中經常可以獲取特定信息，例如身份證號。而且，經常會有數值型值以字符串形式體現。對字符串的操作通常有類型轉換、字符串截取等。但是由于字符類型字段的隨意性也造成了臟數據的隱患，所以在處理這種規則的時候，一定要加上異常處理。

5、空值判斷，對于空值的處理是數據倉庫中一個常見問題，是將它作為臟數據還是作為特定一種維成員？這恐怕還要看應用的情況，也是需要進一步探求的。但是無論怎樣，對于可能有NULL值的字段，不要采用“直接映射”的規則類型，必須對空值進行判斷，目前我們的建議是將它轉換成特定的值。

6、日期轉換，在數據倉庫中日期值一般都會有特定的，不同于日期類型值的表示方法，例如使用8位整型20040801表示日期。而在數據源中，這種字段基本都是日期類型的，所以對于這樣的規則，需要一些共通函數來處理將日期轉換為8位日期值、6位月份值等。

7、日期運算，基于日期，我們通常會計算日差、月差、時長等。一般數據庫提供的日期運算函數都是基于日期型的，而在數據倉庫中采用特定類型來表示日期的話，必須有一套自己的日期運算函數集。

8、聚集運算，對于事實表中的度量字段，他們通常是通過數據源一個或多個字段運用聚集函數得來的，這些聚集函數為SQL標準中，包括sum,count,avg,min,max。

9、既定取值，這種規則和以上各種類型規則的差別就在于它不依賴于數據源字段，對目標字段取一個固定的或是依賴系統的值。

探求ETL本質之四（數據質量）

“不要絕對的數據準確，但要知道為什么不準確。”

這是我們在構建BI系統是對數據準確性的要求。確實，對絕對的數據準確誰也沒有把握，不僅是系統集成商，包括客戶也是無法確定。準確的東西需要一個標準，但首先要保證這個標準是準確的，至少現在還沒有這樣一個標準。客戶會提出一個相對標準，例如將你的OLAP數據結果和報表結果對比。雖然這是一種不太公平的比較，你也只好認了吧。

首先在數據源那里，已經很難保證數據質量了，這一點也是事實。在這一層有哪些可能原因導致數據質量問題？可以分為下面幾類：

1、數據格式錯誤，例如缺失數據、數據值超出范圍或是數據格式非法等。要知道對于同樣處理大數據量的數據源系統，他們通常會舍棄一些數據庫自身的檢查機制，例如字段約束等。他們盡可能將數據檢查在入庫前保證，但是這一點是很難確保的。這類情況諸如身份證號碼、手機號、非日期類型的日期字段等。

2、數據一致性，同樣，數據源系統為了性能的考慮，會在一定程度上舍棄外鍵約束，這通常會導致數據不一致。例如在帳務表中會出現一個用戶表中沒有的用戶ID，在例如有些代碼在代碼表中找不到等。

3、業務邏輯的合理性，這一點很難說對與錯。通常，數據源系統的設計并不是非常嚴謹，例如讓用戶開戶日期晚于用戶銷戶日期都是有可能發生的，一個用戶表中存在多個用戶ID也是有可能發生的。對這種情況，有什么辦法嗎？

構建一個BI系統，要做到完全理解數據源系統根本就是不可能的。特別是數據源系統在交付后，有更多維護人員的即興發揮，那更是要花大量的時間去尋找原因。以前曾經爭辯過設計人員對規則描述的問題，有人提出要在ETL開始之前務必將所有的規則弄得一清二楚。我并不同意這樣的意見，倒是認為在ETL過程要有處理這些質量有問題數據的保證。一定要正面這些臟數據，是丟棄還是處理，無法逃避。如果沒有質量保證，那么在這個過程中，錯誤會逐漸放大，拋開數據源質量問題，我們再來看看ETL過程中哪些因素對數據準確性產生重大影響。

1、規則描述錯誤。上面提到對設計人員對數據源系統理解的不充分，導致規則理解錯誤，這是一方面。另一方面，是規則的描述，如果無二義性地描述規則也是要探求的一個課題。規則是依附于目標字段的，在探求之三中，提到規則的分類。但是規則總不能總是用文字描述，必須有嚴格的數學表達方式。我甚至想過，如果設計人員能夠使用某種規則語言來描述，那么我們的ETL單元就可以自動生成、同步，省去很多手工操作了。

2、ETL開發錯誤。即時規則很明確，ETL開發的過程中也會發生一些錯誤，例如邏輯錯誤、書寫錯誤等。例如對于一個分段值，開區間閉區間是需要指定的，但是常常開發人員沒注意，一個大于等于號寫成大于號就導致數據錯誤。

3、人為處理錯誤。在整體ETL流程沒有完成之前，為了圖省事，通常會手工運行ETL過程，這其中一個重大的問題就是你不會按照正常流程去運行了，而是按照自己的理解去運行，發生的錯誤可能是誤刪了數據、重復裝載數據等。

探求ETL本質之五（質量保證）

上回提到ETL數據質量問題，這是無法根治的，只能采取特定的手段去盡量避免，而且必須要定義出度量方法來衡量數據的質量是好還是壞。對于數據源的質量，客戶對此應該更加關心，如果在這個源頭不能保證比較干凈的數據，那么后面的分析功能的可信度也都成問題。數據源系統也在不斷進化過程中，客戶的操作也在逐漸規范中，BI系統也同樣如此。本文探討一下對數據源質量和ETL處理質量的應對方法。

如何應對數據源的質量問題？記得在onteldatastage列表中也討論過一個話題－”-1的處理"，在數據倉庫模型維表中，通常有一條-1記錄，表示“未知”，這個未知含義可廣了，任何可能出錯的數據，NULL數據甚至是規則沒有涵蓋到的數據，都轉成-1。這是一種處理臟數據的方法，但這也是一種掩蓋事實的方法。就好像寫一個函數FileOpen(filename)，返回一個錯誤碼，當然，你可以只返回一種錯誤碼，如-1，但這是一種不好的設計，對于調用者來說，他需要依據這個錯誤碼進行某些判斷，例如是文件不存在，還是讀取權限不夠，都有相應的處理邏輯。數據倉庫中也是一樣，所以，建議將不同的數據質量類型處理結果分別轉換成不同的值，譬如，在轉換后，-1表示參照不上，-2表示NULL數據等。不過這僅僅對付了上回提到的第一類錯誤，數據格式錯誤。對于數據一致性和業務邏輯合理性問題，這仍有待探求。但這里有一個原則就是“必須在數據倉庫中反應數據源的質量”。

對于ETL過程中產生的質量問題，必須有保障手段。從以往的經驗看，沒有保障手段給實施人員帶來麻煩重重。實施人員對于反復裝載數據一定不會陌生，甚至是最后數據留到最后的Cube，才發現了第一步ETL其實已經錯了。這個保障手段就是數據驗證機制，當然，它的目的是能夠在ETL過程中監控數據質量，產生報警。這個模塊要將實施人員當作是最終用戶，可以說他們是數據驗證機制的直接收益者。首先，必須有一個對質量的度量方法，什么是高質什么是低質，不能靠感官感覺，但這卻是在沒有度量方法條件下通常的做法。那經營分析系統來說，聯通總部曾提出測試規范，這其實就是一種度量方法，例如指標的誤差范圍不能高于5%等，對系統本身來說其實必須要有這樣的度量方法，先不要說這個度量方法是否科學。對于ETL數據處理質量，他的度量方法應該比聯通總部測試規范定義的方法更要嚴格，因為他更多將BI系統看作一個黑盒子，從數據源到展現的數據誤差允許一定的誤差。而ETL數據處理質量度量是一種白盒的度量，要注重每一步過程。因此理論上，要求輸入輸出的指標應該完全一致。但是我們必須正面完全一致只是理想，對于有誤差的數據，必須找到原因。

在質量度量方法的前提下，就可以建立一個數據驗證框架。此框架依據總量、分量數據稽核方法，該方法在高的《數據倉庫中的數據稽核技術》一文中已經指出。作為補充，下面提出幾點功能上的建議：

1、提供前端。將開發實施人員當作用戶，同樣也要為之提供友好的用戶界面。《稽核技術》一文中指出測試報告的形式，這種形式還是要依賴人為判斷，在一堆數據中去找規律。到不如用OLAP的方式提供界面，不光是加上測試統計出來的指標結果，并且配合度量方法的計算。例如誤差率，對于誤差率為大于0的指標，就要好好查一下原因了。

2、提供框架。數據驗證不是一次性工作，而是每次ETL過程中都必須做的。因此，必須有一個框架，自動化驗證過程，并提供擴展手段，讓實施人員能夠增加驗證范圍。有了這樣一個框架，其實它起到規范化操作的作用，開發實施人員可以將主要精力放在驗證腳本的編寫上，而不必過多關注驗證如何融合到流程中，如何展現等工作。為此，要設計一套表，類似于DM表，每次驗證結果數據都記錄其中，并且自動觸發多維分析的數據裝載、發布等。這樣，實施人員可以在每次裝載，甚至在流程過程中就可以觀察數據的誤差率。特別是，如果數據倉庫的模型能夠統一起來，甚至數據驗證腳本都可以確定下來，剩下的就是規范流程了。

3、規范流程。上回提到有一種ETL數據質量問題是由于人工處理導致的，其中最主要原因還是流程不規范。開發實施人員運行單獨一個ETL單元是很方便的，雖然以前曾建議一個ETL單元必須是“可重入”的，這能夠解決誤刪數據，重復裝載數據問題。但要記住數據驗證也是在流程當中，要讓數據驗證能夠日常運作，就不要讓實施者感覺到他的存在。總的來說，規范流程是提高實施效率的關鍵工作，這也是以后要繼續探求的。

探求ETL本質之六（元數據漫談）

對于元數據（Metadata）的定義到目前為止沒有什么特別精彩的，這個概念非常廣，一般都是這樣定義，“元數據是描述數據的數據（Data about Data）”，這造成一種遞歸定義，就像問小強住在哪里，答，在旺財隔壁。按照這樣的定義，元數據所描述的數據是什么呢？還是元數據。這樣就可能有元元元...元數據。我還聽說過一種對元數據，如果說數據是一抽屜檔案，那么元數據就是分類標簽。那它和索引有什么區別？ 元數據體現是一種抽象，哲學家從古至今都在抽象這個世界，力圖找到世界的本質。抽象不是一層關系，它是一種逐步由具體到一般的過程。例如我->男人->人->哺乳動物->生物這就是一個抽象過程，你要是在軟件業混會發現這個例子很常見，面向對象方法就是這樣一種抽象過程。它對世界中的事物、過程進行抽象，使用面向對象方法，構建一套對象模型。同樣在面向對象方法中，類是對象的抽象，接口又是對類的抽象。因此，我認為可以將“元”和“抽象”換一下，叫抽象數據是不是好理解一些。

常聽到這樣的話，“xx領導的講話高屋建瓴，給我們后面的工作指引的清晰的方向”，這個成語“高屋建瓴”，站在10樓往下到水，居高臨下，能砸死人，這是指站在一定的高度看待事物，這個一定的高度就是指他有夠“元”。在設計模式中，強調要對接口編程，就是說你不要處理這類對象和那類對象的交互，而要處理這個接口和那個接口的交互，先別管他們內部是怎么干的。元數據存在的意義也在于此，雖然上面說了一通都撤到哲學上去，但這個詞必須還是要結合軟件設計中看，我不知道在別的領域是不是存在Metadata這樣的叫法，雖然我相信別的領域必然有類似的東東。元數據的存在就是要做到在更高抽象一層設計軟件。這肯定有好處，什么靈活性啊，擴展性啊，可維護性啊，都能得到提高，而且架構清晰，只是彎彎太多，要是從下往上看，太復雜了。很早以前，我曾看過backorifice的代碼，我靠，一個簡單的功能，從這個類轉到父類，又轉到父類，很不理解，為什么一個簡單的功能不在一個類的方法中實現就拉到了呢？現在想想，還真不能這樣，這雖然使代碼容易看懂了，但是結構確實混亂的，那他只能干現在的事，如果有什么功能擴展，這些代碼就廢了。

我從98年剛工作時就開始接觸元數據的概念，當時叫做元數據驅動的系統架構，后來在QiDSS中也用到這個概念構建QiNavigator，但是現在覺得元數據也沒啥，不就是建一堆表描述界面的元素，再利用這些數據自動生成界面嗎。到了數據倉庫系統中，這個概念更強了，是數據倉庫中一個重要的部分。但是至今，我還是認為這個概念過于玄乎，看不到實際的東西，市面上有一些元數據管理的東西，但是從應用情況就得知，用的不多。之所以玄乎，就是因為抽象層次沒有分清楚，關鍵就是對于元數據的分類（這種分類就是一種抽象過程）和元數據的使用。你可以將元數據抽象成0和1，但是那樣對你的業務有用嗎？必須還得抽象到適合的程度，最后問題還是“度”。

數據倉庫系統的元數據作用如何？還不就是使系統自動運轉，易于管理嗎？要做到這一步，可沒必要將系統抽象到太極、兩儀、八卦之類的，業界也曾定義過一些元數據規范，向CWM、XMI等等，可以借鑒，不過俺對此也是不精通的說，以后再說

第三篇：ETL學習心得

ETL學習心得：探求數據倉庫關鍵環節ETL的本質

做數據倉庫系統，ETL是關鍵的一環。說大了，ETL是數據整合解決方案，說小了，就是倒數據的工具。回憶一下工作這么些年來，處理數據遷移、轉換的工作倒還真的不少。但是那些工作基本上是一次性工作或者很小數據量，使用access、DTS或是自己編個小程序搞定。可是在數據倉庫系統中，ETL上升到了一定的理論高度，和原來小打小鬧的工具使用不同了。究竟什么不同，從名字上就可以看到，人家已經將倒數據的過程分成3個步驟，E、T、L分別代表抽取、轉換和裝載。

其實ETL過程就是數據流動的過程，從不同的數據源流向不同的目標數據。但在數據倉庫中，ETL有幾個特點，一是數據同步，它不是一次性倒完數據就拉到，它是經常性的活動，按照固定周期運行的，甚至現在還有人提出了實時ETL的概念。二是數據量，一般都是巨大的，值得你將數據流動的過程拆分成E、T和L。

現在有很多成熟的工具提供ETL功能，例如datastage、powermart等，且不說他們的好壞。從應用角度來說，ETL的過程其實不是非常復雜，這些工具給數據倉庫工程帶來和很大的便利性，特別是開發的便利和維護的便利。但另一方面，開發人員容易迷失在這些工具中。舉個例子，VB是一種非常簡單的語言并且也是非常易用的編程工具，上手特別快，但是真正VB的高手有多少？微軟設計的產品通常有個原則是“將使用者當作傻瓜”，在這個原則下，微軟的東西確實非常好用，但是對于開發者，如果你自己也將自己當作傻瓜，那就真的傻了。ETL工具也是一樣，這些工具為我們提供圖形化界面，讓我們將主要的精力放在規則上，以期提高開發效率。從使用效果來說，確實使用這些工具能夠非常快速地構建一個job來處理某個數據，不過從整體來看，并不見得他的整體效率會高多少。問題主要不是出在工具上，而是在設計、開發人員上。他們迷失在工具中，沒有去探求ETL的本質。

可以說這些工具應用了這么長時間，在這么多項目、環境中應用，它必然有它成功之處，它必定體現了ETL的本質。如果我們不透過表面這些工具的簡單使用去看它背后蘊涵的思想，最終我們作出來的東西也就是一個個獨立的job，將他們整合起來仍然有巨大的工作量。大家都知道“理論與實踐相結合”，如果在一個領域有所超越，必須要在理論水平上達到一定的高度

探求ETL本質之一

ETL的過程就是數據流動的過程，從不同異構數據源流向統一的目標數據。其間，數據的抽取、清洗、轉換和裝載形成串行或并行的過程。ETL的核心還是在于T這個過程，也就是轉換，而抽取和裝載一般可以作為轉換的輸入和輸出，或者，它們作為一個單獨的部件，其復雜度沒有轉換部件高。和OLTP系統中不同，那里充滿這單條記錄的insert、update和select等操作，ETL過程一般都是批量操作，例如它的裝載多采用批量裝載工具，一般都是DBMS系統自身附帶的工具，例如Oracle SQLLoader和DB2的autoloader等。

ETL本身有一些特點，在一些工具中都有體現，下面以datastage和powermart舉例來說。

1、靜態的ETL單元和動態的ETL單元實例；一次轉換指明了某種格式的數據如何格式化成另一種格式的數據，對于數據源的物理形式在設計時可以不用指定，它可以在運行時，當這個ETL單元創建一個實例時才指定。對于靜態和動態的ETL單元，Datastage沒有嚴格區分，它的一個Job就是實現這個功能，在早期版本，一個Job同時不能運行兩次，所以一個Job相當于一個實例，在后期版本，它支持multiple instances，而且還不是默認選項。Powermart中將這兩個概念加以區分，靜態的叫做Mapping，動態運行時叫做Session。

2、ETL元數據；元數據是描述數據的數據，他的含義非常廣泛，這里僅指ETL的元數據。主要包括每次轉換前后的數據結構和轉換的規則。ETL元數據還包括形式參數的管理，形式參數的ETL單元定義的參數，相對還有實參，它是運行時指定的參數，實參不在元數據管理范圍之內。

3、數據流程的控制；要有可視化的流程編輯工具，提供流程定義和流程監控功能。流程調度的最小單位是ETL單元實例，ETL單元是不能在細分的ETL過程，當然這由開發者來控制，例如可以將抽取、轉換放在一個ETL單元中，那樣這個抽取和轉換只能同時運行，而如果將他們分作兩個單元，可

以分別運行，這有利于錯誤恢復操作。當然，ETL單元究竟應該細分到什么程度應該依據具體應用來看，目前還沒有找到很好的細分策略。比如，我們可以規定將裝載一個表的功能作為一個ETL單元，但是不可否認，這樣的ETL單元之間會有很多共同的操作，例如兩個單元共用一個Hash表，要將這個Hash表裝入內存兩次。

4、轉換規則的定義方法；提供函數集提供常用規則方法，提供規則定義語言描述規則。

5、對數據的快速索引；一般都是利用Hash技術，將參照關系表提前裝入內存，在轉換時查找這個hash表。Datastage中有Hash文件技術，Powermart也有類似的Lookup功能。

探求ETL本質之二（分類）

昨在IT-Director上閱讀一篇報告，關于ETL產品分類的。一般來說，我們眼中的ETL工具都是價格昂貴，能夠處理海量數據的家伙，但是這是其中的一種。它可以分成4種，針對不同的需求，主要是從轉換規則的復雜度和數據量大小來看。它們包括

1、交互式運行環境，你可以指定數據源、目標數據，指定規則，立馬ETL。這種交互式的操作無疑非常方便，但是只能適合小數據量和復雜度不高的ETL過程，因為一旦規則復雜了，可能需要語言級的描述，不能簡簡單單拖拖拽拽就可以的。還有數據量的問題，這種交互式必然建立在解釋型語言基礎上，另外他的靈活性必然要犧牲一定的性能為代價。所以如果要處理海量數據的話，每次讀取一條記錄，每次對規則進行解釋執行，每次在寫入一條記錄，這對性能影響是非常大的。

2、專門編碼型的，它提供了一個基于某種語言的程序框架，你可以不必將編程精力放在一些周邊的功能上，例如讀文件功能、寫數據庫的功能，而將精力主要放在規則的實現上面。這種近似手工代碼的性能肯定是沒話說，除非你的編程技巧不過關（這也是不可忽視的因素之一）。對于處理大數據量，處理復雜轉換邏輯，這種方式的ETL實現是非常直觀的。

3、代碼生成器型的，它就像是一個ETL代碼生成器，提供簡單的圖形化界面操作，讓你拖拖拽拽將轉換規則都設定好，其實他的后臺都是生成基于某種語言的程序，要運行這個ETL過程，必須要編譯才行。Datastage就是類似這樣的產品，設計好的job必須要編譯，這避免了每次轉換的解釋執行，但是不知道它生成的中間語言是什么。以前我設計的ETL工具大挪移其實也是歸屬于這一類，它提供了界面讓用戶編寫規則，最后生成C++語言，編譯后即可運行。這類工具的特點就是要在界面上下狠功夫，必須讓用戶輕松定義一個ETL過程，提供豐富的插件來完成讀、寫和轉換函數。大挪移在這方面就太弱了，規則必須手寫，而且要寫成標準c++語法，這未免還是有點難為最終用戶了，還不如做成一個專業編碼型的產品呢。另外一點，這類工具必須提供面向專家應用的功能，因為它不可能考慮到所有的轉換規則和所有的讀寫，一方面提供插件接口來讓第三方編寫特定的插件，另一方面還有提供特定語言來實現高級功能。例如Datastage提供一種類Basic的語言，不過他的Job的腳本化實現好像就做的不太好，只能手工繪制job，而不能編程實現Job。

4、最后還有一種類型叫做數據集線器，顧名思義，他就是像Hub一樣地工作。將這種類型分出來和上面幾種分類在標準上有所差異，上面三種更多指ETL實現的方法，此類主要從數據處理角度。目前有一些產品屬于EAI（Enterprise Application Integration），它的數據集成主要是一種準實時性。所以這類產品就像Hub一樣，不斷接收各種異構數據源來的數據，經過處理，在實施發送到不同的目標數據中去。

雖然，這些類看似各又千秋，特別在BI項目中，面對海量數據的ETL時，中間兩種的選擇就開始了，在選擇過程中，必須要考慮到開發效率、維護方面、性能、學習曲線、人員技能等各方面因素，當然還有最重要也是最現實的因素就是客戶的意象。

探求ETL本質之三（轉換）

ETL探求之一中提到，ETL過程最復雜的部分就是T，這個轉換過程，T過程究竟有哪些類型呢？

一、宏觀輸入輸出

從對數據源的整個宏觀處理分，看看一個ETL過程的輸入輸出，可以分成下面幾類：

1、大小交，這種處理在數據清洗過程是常見了，例如從數據源到ODS階段，如果數據倉庫采用

維度建模，而且維度基本采用代理鍵的話，必然存在代碼到此鍵值的轉換。如果用SQL實現，必然需要將一個大表和一堆小表都Join起來，當然如果使用ETL工具的話，一般都是先將小表讀入內存中再處理。這種情況，輸出數據的粒度和大表一樣。

2、大大交，大表和大表之間關聯也是一個重要的課題，當然其中要有一個主表，在邏輯上，應當是主表Left Join輔表。大表之間的關聯存在最大的問題就是性能和穩定性，對于海量數據來說，必須有優化的方法來處理他們的關聯，另外，對于大數據的處理無疑會占用太多的系統資源，出錯的幾率非常大，如何做到有效錯誤恢復也是個問題。對于這種情況，我們建議還是盡量將大表拆分成適度的稍小一點的表，形成大小交的類型。這類情況的輸出數據粒度和主表一樣。

3、站著進來，躺著出去。事務系統中為了提高系統靈活性和擴展性，很多信息放在代碼表中維護，所以它的“事實表”就是一種窄表，而在數據倉庫中，通常要進行寬化，從行變成列，所以稱這種處理情況叫做“站著進來，躺著出去”。大家對Decode肯定不陌生，這是進行寬表化常見的手段之一。窄表變寬表的過程主要體現在對窄表中那個代碼字段的操作。這種情況，窄表是輸入，寬表是輸出，寬表的粒度必定要比窄表粗一些，就粗在那個代碼字段上。

4、聚集。數據倉庫中重要的任務就是沉淀數據，聚集是必不可少的操作，它是粗化數據粒度的過程。聚集本身其實很簡單，就是類似SQL中Group by的操作，選取特定字段（維度），對度量字段再使用某種聚集函數。但是對于大數據量情況下，聚集算法的優化仍是探究的一個課題。例如是直接使用SQL的Group by，還是先排序，在處理。

二、微觀規則

從數據的轉換的微觀細節分，可以分成下面的幾個基本類型，當然還有一些復雜的組合情況，例如先運算，在參照轉換的規則，這種基于基本類型組合的情況就不在此列了。ETL的規則是依賴目標數據的，目標數據有多少字段，就有多少條規則。

1、直接映射，原來是什么就是什么，原封不動照搬過來，對這樣的規則，如果數據源字段和目標字段長度或精度不符，需要特別注意看是否真的可以直接映射還是需要做一些簡單運算。

2、字段運算，數據源的一個或多個字段進行數學運算得到的目標字段，這種規則一般對數值型字段而言。

3、參照轉換，在轉換中通常要用數據源的一個或多個字段作為Key，去一個關聯數組中去搜索特定值，而且應該只能得到唯一值。這個關聯數組使用Hash算法實現是比較合適也是最常見的，在整個ETL開始之前，它就裝入內存，對性能提高的幫助非常大。

4、字符串處理，從數據源某個字符串字段中經常可以獲取特定信息，例如身份證號。而且，經常會有數值型值以字符串形式體現。對字符串的操作通常有類型轉換、字符串截取等。但是由于字符類型字段的隨意性也造成了臟數據的隱患，所以在處理這種規則的時候，一定要加上異常處理。

5、空值判斷，對于空值的處理是數據倉庫中一個常見問題，是將它作為臟數據還是作為特定一種維成員？這恐怕還要看應用的情況，也是需要進一步探求的。但是無論怎樣，對于可能有NULL值的字段，不要采用“直接映射”的規則類型，必須對空值進行判斷，目前我們的建議是將它轉換成特定的值。

6、日期轉換，在數據倉庫中日期值一般都會有特定的，不同于日期類型值的表示方法，例如使用8位整型20040801表示日期。而在數據源中，這種字段基本都是日期類型的，所以對于這樣的規則，需要一些共通函數來處理將日期轉換為8位日期值、6位月份值等。

7、日期運算，基于日期，我們通常會計算日差、月差、時長等。一般數據庫提供的日期運算函數都是基于日期型的，而在數據倉庫中采用特定類型來表示日期的話，必須有一套自己的日期運算函數集。

8、聚集運算，對于事實表中的度量字段，他們通常是通過數據源一個或多個字段運用聚集函數得來的，這些聚集函數為SQL標準中，包括sum,count,avg,min,max。

9、既定取值，這種規則和以上各種類型規則的差別就在于它不依賴于數據源字段，對目標字段取一個固定的或是依賴系統的值。

探求ETL本質之四（數據質量）

“不要絕對的數據準確，但要知道為什么不準確。”

這是我們在構建BI系統是對數據準確性的要求。確實，對絕對的數據準確誰也沒有把握，不僅是系統集成商，包括客戶也是無法確定。準確的東西需要一個標準，但首先要保證這個標準是準確的，至少現在還沒有這樣一個標準。客戶會提出一個相對標準，例如將你的OLAP數據結果和報表結果對比。雖然這是一種不太公平的比較，你也只好認了吧。

首先在數據源那里，已經很難保證數據質量了，這一點也是事實。在這一層有哪些可能原因導致數據質量問題？可以分為下面幾類：

1、數據格式錯誤，例如缺失數據、數據值超出范圍或是數據格式非法等。要知道對于同樣處理大數據量的數據源系統，他們通常會舍棄一些數據庫自身的檢查機制，例如字段約束等。他們盡可能將數據檢查在入庫前保證，但是這一點是很難確保的。這類情況諸如身份證號碼、手機號、非日期類型的日期字段等。

2、數據一致性，同樣，數據源系統為了性能的考慮，會在一定程度上舍棄外鍵約束，這通常會導致數據不一致。例如在帳務表中會出現一個用戶表中沒有的用戶ID，在例如有些代碼在代碼表中找不到等。

3、業務邏輯的合理性，這一點很難說對與錯。通常，數據源系統的設計并不是非常嚴謹，例如讓用戶開戶日期晚于用戶銷戶日期都是有可能發生的，一個用戶表中存在多個用戶ID也是有可能發生的。對這種情況，有什么辦法嗎？

構建一個BI系統，要做到完全理解數據源系統根本就是不可能的。特別是數據源系統在交付后，有更多維護人員的即興發揮，那更是要花大量的時間去尋找原因。以前曾經爭辯過設計人員對規則描述的問題，有人提出要在ETL開始之前務必將所有的規則弄得一清二楚。我并不同意這樣的意見，倒是認為在ETL過程要有處理這些質量有問題數據的保證。一定要正面這些臟數據，是丟棄還是處理，無法逃避。如果沒有質量保證，那么在這個過程中，錯誤會逐漸放大，拋開數據源質量問題，我們再來看看ETL過程中哪些因素對數據準確性產生重大影響。

1、規則描述錯誤。上面提到對設計人員對數據源系統理解的不充分，導致規則理解錯誤，這是一方面。另一方面，是規則的描述，如果無二義性地描述規則也是要探求的一個課題。規則是依附于目標字段的，在探求之三中，提到規則的分類。但是規則總不能總是用文字描述，必須有嚴格的數學表達方式。我甚至想過，如果設計人員能夠使用某種規則語言來描述，那么我們的ETL單元就可以自動生成、同步，省去很多手工操作了。

2、ETL開發錯誤。即時規則很明確，ETL開發的過程中也會發生一些錯誤，例如邏輯錯誤、書寫錯誤等。例如對于一個分段值，開區間閉區間是需要指定的，但是常常開發人員沒注意，一個大于等于號寫成大于號就導致數據錯誤。

3、人為處理錯誤。在整體ETL流程沒有完成之前，為了圖省事，通常會手工運行ETL過程，這其中一個重大的問題就是你不會按照正常流程去運行了，而是按照自己的理解去運行，發生的錯誤可能是誤刪了數據、重復裝載數據等。

探求ETL本質之五（質量保證）

上回提到ETL數據質量問題，這是無法根治的，只能采取特定的手段去盡量避免，而且必須要定義出度量方法來衡量數據的質量是好還是壞。對于數據源的質量，客戶對此應該更加關心，如果在這個源頭不能保證比較干凈的數據，那么后面的分析功能的可信度也都成問題。數據源系統也在不斷進化過程中，客戶的操作也在逐漸規范中，BI系統也同樣如此。本文探討一下對數據源質量和ETL處理質量的應對方法。

如何應對數據源的質量問題？記得在onteldatastage列表中也討論過一個話題－“-1的處理”，在數據倉庫模型維表中，通常有一條-1記錄，表示“未知”，這個未知含義可廣了，任何可能出錯的數據，NULL數據甚至是規則沒有涵蓋到的數據，都轉成-1。這是一種處理臟數據的方法，但這也是一種掩蓋

事實的方法。就好像寫一個函數FileOpen(filename)，返回一個錯誤碼，當然，你可以只返回一種錯誤碼，如-1，但這是一種不好的設計，對于調用者來說，他需要依據這個錯誤碼進行某些判斷，例如是文件不存在，還是讀取權限不夠，都有相應的處理邏輯。數據倉庫中也是一樣，所以，建議將不同的數據質量類型處理結果分別轉換成不同的值，譬如，在轉換后，-1表示參照不上，-2表示NULL數據等。不過這僅僅對付了上回提到的第一類錯誤，數據格式錯誤。對于數據一致性和業務邏輯合理性問題，這仍有待探求。但這里有一個原則就是“必須在數據倉庫中反應數據源的質量”。

對于ETL過程中產生的質量問題，必須有保障手段。從以往的經驗看，沒有保障手段給實施人員帶來麻煩重重。實施人員對于反復裝載數據一定不會陌生，甚至是最后數據留到最后的Cube，才發現了第一步ETL其實已經錯了。這個保障手段就是數據驗證機制，當然，它的目的是能夠在ETL過程中監控數據質量，產生報警。這個模塊要將實施人員當作是最終用戶，可以說他們是數據驗證機制的直接收益者。

首先，必須有一個對質量的度量方法，什么是高質什么是低質，不能靠感官感覺，但這卻是在沒有度量方法條件下通常的做法。那經營分析系統來說，聯通總部曾提出測試規范，這其實就是一種度量方法，例如指標的誤差范圍不能高于5%等，對系統本身來說其實必須要有這樣的度量方法，先不要說這個度量方法是否科學。對于ETL數據處理質量，他的度量方法應該比聯通總部測試規范定義的方法更要嚴格，因為他更多將BI系統看作一個黑盒子，從數據源到展現的數據誤差允許一定的誤差。而ETL數據處理質量度量是一種白盒的度量，要注重每一步過程。因此理論上，要求輸入輸出的指標應該完全一致。但是我們必須正面完全一致只是理想，對于有誤差的數據，必須找到原因。

在質量度量方法的前提下，就可以建立一個數據驗證框架。此框架依據總量、分量數據稽核方法，該方法在高的《數據倉庫中的數據稽核技術》一文中已經指出。作為補充，下面提出幾點功能上的建議：

1、提供前端。將開發實施人員當作用戶，同樣也要為之提供友好的用戶界面。《稽核技術》一文中指出測試報告的形式，這種形式還是要依賴人為判斷，在一堆數據中去找規律。到不如用OLAP的方式提供界面，不光是加上測試統計出來的指標結果，并且配合度量方法的計算。例如誤差率，對于誤差率為大于0的指標，就要好好查一下原因了。

2、提供框架。數據驗證不是一次性工作，而是每次ETL過程中都必須做的。因此，必須有一個框架，自動化驗證過程，并提供擴展手段，讓實施人員能夠增加驗證范圍。有了這樣一個框架，其實它起到規范化操作的作用，開發實施人員可以將主要精力放在驗證腳本的編寫上，而不必過多關注驗證如何融合到流程中，如何展現等工作。為此，要設計一套表，類似于DM表，每次驗證結果數據都記錄其中，并且自動觸發多維分析的數據裝載、發布等。這樣，實施人員可以在每次裝載，甚至在流程過程中就可以觀察數據的誤差率。特別是，如果數據倉庫的模型能夠統一起來，甚至數據驗證腳本都可以確定下來，剩下的就是規范流程了。

3、規范流程。上回提到有一種ETL數據質量問題是由于人工處理導致的，其中最主要原因還是流程不規范。開發實施人員運行單獨一個ETL單元是很方便的，雖然以前曾建議一個ETL單元必須是“可重入”的，這能夠解決誤刪數據，重復裝載數據問題。但要記住數據驗證也是在流程當中，要讓數據驗證能夠日常運作，就不要讓實施者感覺到他的存在。總的來說，規范流程是提高實施效率的關鍵工作，這也是以后要繼續探求的。

第四篇：DataStage(ETL)技術總結介紹篇

DataStage（ETL）技術總結--介紹篇(轉載)

數據整合的核心內容是從數據源中抽取數據，然后對這些數據進行轉化，最終加載的目標數據庫或者數據倉庫中去，這也就是我們通常所說的 ETL 過程(Extract,Transform, Load)。

IBM WebSphere DataStage（下面簡稱為DataStage）為整個 ETL 過程提供了一個圖形化的開發環境,它是一套專門對多種操作數據源的數據抽取、轉換和維護過程進行簡化和自動化，并將其輸入數據集或數據倉庫的集成工具。

通常數據抽取工作分抽取、清洗、轉換、裝載幾個步驟:

抽取主要是針對各個業務系統及不同網點的分散數據，充分理解數據定義后，規劃需要的數據源及數據定義，制定可操作的數據源，制定增量抽取的定義。

清洗主要是針對系統的各個環節可能出現的數據二義性、重復、不完整、違反業務規則等問題，允許通過試抽取，將有問題的紀錄先剔除出來，根據實際情況調整相應的清洗操作。

轉換主要是針對數據倉庫建立的模型，通過一系列的轉換來實現將數據從業務模型到分析模型，通過內建的庫函數、自定義腳本或其他的擴展方式，實現了各種復雜的轉換，并且支持調試環境，清楚的監控數據轉換的狀態。

裝載主要是將經過轉換的數據裝載到數據倉庫里面，可以通過數據文件直接裝載或直連數據庫的方式來進行數據裝載，可以充分體現高效性。在應用的時候可以隨時調整數據抽取工作的運行方式，可以靈活的集成到其他管理系統中。

一．數據源連接能力：

數據整合工具的數據源連接能力是非常重要的，這將直接決定它能夠應用的范圍。DataStage 能夠直接連接非常多的數據源，包括：

1、文本文件

2、XML 文件

3、企業應用程序，比如 SAP、PeopleSoft、Siebel、Oracle Application

4、幾乎所有的數據庫系統，比如 DB2、Oracle、SQL Server、Sybase ASE/IQ、Teradata、Informix等以及可通過ODBC連接的數據庫

5、Web Services

6、SAS、WebSphere MQ

二．多國語言支持(NLS): DataStage能夠支持幾乎所有編碼，以及多種擴展編碼(IBM、NEC、富士通、日立等)，可以添加編碼的支持，DataStage內部為UTF8編碼。

三．并行運行能力: ETL Job的控件大多數都支持并行運行，此外DataStage企業版還可以在多臺裝有DataStage Server的機器上并行執行，這也是傳統的手工編碼方式難以做到的。這樣，DataStage就可以充分利用硬件資源。而且，當你的硬件資源升級的時候也不用修改已經開發好的ETL Job，只需要修改一個描述硬件資源的文件即可。并行執行能力是DataStage所能處理數據的速度可以得到趨近于線性的擴展，輕松處理大量數據。

四．便捷的開發環境: DataStage 的開發環境是基于 C/S 模式的，通過 DataStage Client 連接到DataStage Server 上進行開發。這里有一點需要注意，DataStage Client 只能安裝在 Windows平臺上面(在Win2000/XP上運行過)。而 DataStage Server 則支持多種平臺，比如 Windows、Solaris、Redhat Linux、AIX、HP-UNIX。(在WinXP/Solaris8上運行過)DataStage Client 有四種客戶端工具。分別是 DataStage Administrator、DataStage Designer、DataStage Manager、DataStage Director。下面介紹這幾種客戶端工具在 DataStage 架構中所處的位置以及它們如何協同工作來開發 ETL Job 的。(1)DataStage Administrator

DataStage Administrator 的主要功能有以下幾個： 1． 設置客戶端和服務器連接的最大時間。

以管理員的身份登陸 DataStage Administrator(默認安裝下管理員為dsadm)。你可以設置客戶端和服務器的最大連接時間，默認的最大連接時間是永不過期。最大連接時間的意思就是如果客戶端和服務器的連接時間超過了最大連接時間，那么客戶端和服務器之間的連接將被強行斷開。

2． 添加和刪除項目

在 Projects標簽中，可以新建或者刪除項目，以及設置已有項目的屬性。要用 DataStage 進行 ETL 的開發，首先就要用 DataStage Administrator 新建一個項目，然后在這個項目里面進行 ETL Job 的開發。

在Property里,能夠設置該Project全局設置、用戶權限以及License的管理

(2)DataStage Designer DataStage Designer是ETL Job開發的核心環境。值得注意的是，登陸DataStage Designer 的時候，不僅要指定DataStage Server 的IP或Server名，而且要指定連接到這個DataStage Server上的哪個項目上面，上面已經提到DataStage的項目是由DataStage Administrator 來創建的。

DataStage Designer的主要功能可以概括為以下三個方面： 1． ETL Job的開發

DataStage Designer里面包含了DataStage為ETL開發已經構建好的組件, 主要分為兩種，一種是用來連接數據源的組件，另一種是用來做數據轉換的組件。此外DataStage還提供自定義函數(Basic)，利用這些組件，開發人員可以通過圖形化的方式進行ETL Job的開發，此外ETL Job支持參數的傳遞。

2． ETL Job的編譯

開發好ETL Job后，可以直接在DataStage Designer里面進行編譯。如果編譯不通過，編譯器會幫助開發人員定位到出錯的地方。

3． ETL Job的執行

編譯成功后，ETL Job就可以執行了，在DataStage Designer里面可以運行ETL Job。ETL Job的運行情況可以在DataStage Director中看到，這方面的內容將在介紹DataStage Director的時候提到。

4.ETL Job的DEBUG ETL Job可以在Designer中設置斷點，跟蹤監視Job執行時的中間變量。

5.ETL Job Report的生成

可以為ETL Job生成文檔報告，該報告非常詳細，只通過該報告，就可以完全了解該Job的結構與處理過程，非常便于分析。

DataStage提供很多實用的控件，常用的控件有: 1.DB操作控件

主要用于各種DB的連接，連接方式有多種，有面向廠家的Native方式，如Sybase的OpenClient方式,也有通用的ODBC等方式,此外也有些比較特別的DB操作控件，如Sybase的IQ Load、BCP控件,主要用于數據的快速導入和導出。

2.文件操作控件

常用的有Sequential File、Hashed File, Sequential File是可指定編碼形式和格式的CSV文件,Hashed File主要是為了加快檢索效率，而替代DB控件的一種比較好的選擇,這兩種控件可用于輸入或輸出。

3．處理控件

主要的處理空間有Transformer、Aggregator, Transformer是負責數據轉換的關鍵控件，在該控件中可以調用一些自定義函數，Aggregator是用于統計的控件，非常類似于SQL中的 GROUP BY，也提供Count、Max、Min、Sum的統計操作，還支持如First、Last、Average等操作。

DataStage的ETL Job分類: 1.Server Job 最為常用的Job類型，Job可以組合使用，Server Job是Job的最小單位。

2.Job Sequence Job Sequence主要用于Job間的協作工作控制，如各Job的實行流程，出錯處理，文件監控等。

3.Job Control Job Control是一種特殊的Server Job，這種Server Job不是通過Designer來設計的，而是直接通過DataStage內嵌支持的Basic語言來開發，因此方式更為靈活，完全可以利用Job Control替代Job Sequence，至少在出錯處理和Log輸出等方面要靈活很多。（我參與開發的一個項目中完全用Job Control替代了Job Sequence，做出了更為詳細的Log輸出）

(3)DataStage Manager DataStage Manager主要用來管理項目資源。一個項目可能包含多個ETL Job，可以用DataStage Manager把一個項目里面的ETL Job導出來。然后再用DataStage Manager導入到另外一個項目中去，利用這個功能一方面可以實現ETL Job的備份，另一方面就是可以在多個項目之間來重復使用開發好的ETL Job。在DataStage Manager里面可以把數據庫中的表結構直接導入到項目中來，供這個項目中的所有ETL Job使用。DataStage Designer也提供了從數據庫中直接導入表結構的功能。

(4)DataStage Director DataStage Director 主要有以下兩個功能： 1． 監測ETL Job的運行狀態

ETL Job在DataStage Designer中編譯好后，可以通過DataStage Director來運行它。前面在介紹DataStage Designer的時候提到在DataStage Designer中也可以運行ETL Job，但是如果要監測ETL Job的運行情況還是要登陸到DataStage Director中。在這里，你可以看到ETL Job運行的詳細的日志文件，還可以查看一些統計數據，比如ETL Job每秒所處理的數據量。

2． 設置何時運行ETL Job ETL Job開發完成后，我們可能希望ETL Job在每天的某個時間都運行一次。DataStage Director為這種需求提供了解決方案。在DataStage Director中可以設置在每天、每周或者每月的某個時間運行ETL Job。(Windows平臺下需要打開的Task Scheduler服務,此外,在Unix等平臺下,更常用的是用Cron結合dsjob命令來定時運行ETL Job)

五．命令行形式的運行: ETL Job支持在DataStage Server側用命令行形式的調用,可以用dsadmin命令來管理DataStage的Project，包括Project的新建，刪除以及一些環境變量的增刪(DataStage 7.5.1下未能通過dsadmin來設置全局NLS和一些項目屬性)。使用dsjob命令，能夠同步或非同步的運行DataStage的Job，并傳遞需要的Job參數，能夠檢查Job運行的狀態，并能恢復Job的運行狀態。

六.DataStage的不足: 以上都是說DataStage優點，但實際上DataStage也有不少缺點和不足,這些不足點，會直接影響到能否采用DataStage來達到我們的客戶或設計要求。下面就談一下，最近利用DataStage7.5.1來開發一個項目中遇到的問題。1．缺點: 存在一個Bug,在利用DB控件的參照功能時，如果指定的SQL文有錯誤的話，那可能會直接造成DataStage出錯，然后客戶端會和服務端直接斷開，需要關閉客戶端，重新連接服務端，并且更為嚴重的是，DB連接將不會被釋放（可能是服務器端的執行進程并沒有停掉的緣故）

DataStage的表定義的使用，可以通過PlugIn的方式導入，但是導入后基本就只起一個模版的作用，當表結構發生改變而需要修改表定義時，使用該表定義的地方并不能同步，需要手動修改，容易出現遺漏。2．不足: 一些高級控件的功能不夠全面，在實際應用時，會出現不能完全利用DataStage提供的控件來滿足要求，如:Sybase的BCP，DataStage的Sybase BCP控件只支持導出，無法支持導入。當然這些不足，后來我都使用JAVA API來實現了Sybase BCP和Sybase IQ Load。錯誤處理功能不夠，DataStage對業務錯誤，如:檢索0件等錯誤，很難捕獲和處理。某些應用要求無法滿足，如需要對DB某表的某數據進行狀態監視，這時，由于DataStage只有監視文件的功能，DB訪問也只有DB控件才可以，因此該應用最后也是用JAVA來實現。

第五篇：申請ETL認證需要準備資料總結

申請ETL認證需要準備資料總結

ETL+CETL認證標識，右下方的“us”表示適用于美國，左下方的“c”表示適用于加拿大，同時具有“us”和“c”則在兩個國家都適用。

ETL認證目前也是北美最被市場認可的認證之一，ETL試驗室是由美國發明家愛迪生在1896年創立，在美國享有極高的聲譽，目前在國內ETL認證也是眾多出口廠家首選的認證，因此作為廠家了解申請ETL認證需要提供哪些資料，也是必備的常識之一，了解清楚后對申請ETL認證也大有裨益。

那么申請ETL/CETL需要準備哪些資料呢？ 1，填寫ETL認證申請表 需要提供：

A，申請公司中英文名稱、中英文地址（國外廠家不用提供中文）、聯系人信息包括：電話、傳真、郵件等

B，制造工廠中英文名稱、中英文地址（國外廠家不用提供中文）、聯系人信息包括：電話、傳真、郵件等

注意：聯系人肯定要能隨時聯系上，郵箱也必須是常用的，因為后續很多信息是通過郵件確認的；

2，產品資料 需要提供：

A，每個型號銘牌，包括廠名或商標、產品名稱、型號、參數、警告語等； B，多個型號需要提供差異性聲明； C，產品圖片； D，英文說明書/規格書

E，爆炸圖/裝配圖/尺寸圖/PCB布局圖/電路原理圖 爆炸圖模板：

PCB布局圖模板：

電路原理圖模板：

F，BOM表及關鍵零部件清單，關鍵零部件清單參考格式：

常見需要提供的關鍵零部件包括：插頭、電源線、安規電容、保險絲/管、線束、接插件、熱敏電阻、繼電器、溫控器、開關、光耦、套管、塑料材料、絕緣材料、PCB、燈座、膠水等等；

G，馬達、變壓器、加熱管等部件需要提供規格書；

另外特殊產品申請ETL認證時，最好能提供一些有助于判斷測試標準的信息，比如類似的產品某某公司有做個ETL或UL。

通過以上資料發現，其實ETL認證跟申請UL認證提供的資料基本上一樣，沒有什么區別。