ETL是將業務系統的數據通過抽取、清洗轉換以後加載到數據倉庫的過程，目的是將企業中的分散、零亂、標準不統一的數據整合到一塊兒，爲企業的決策提供分析依據。
ETL是BI項目重要的一個環節。 一般狀況下，在BI項目中ETL會花掉整個項目至少1/3的時間,ETL設計的好壞直接關接到BI項目的成敗。 數據庫
ETL的設計分三部分：數據抽取、數據的清洗轉換、數據的加載。在設計ETL的時候咱們也是從這三部分出發。數據的抽取是從各個不一樣的數據源抽取到ODS(Operational Data Store，操做型數據存儲)中——這個過程也能夠作一些數據的清洗和轉換)，在抽取的過程當中須要挑選不一樣的抽取方法，儘量的提升ETL的運行效率。ETL三個部分中，花費時間最長的是「T」(Transform，清洗、轉換)的部分，通常狀況下這部分工做量是整個ETL的2/3。數據的加載通常在數據清洗完了以後直接寫入DW(Data Warehousing，數據倉庫)中去。編程
ETL的實現有多種方法，經常使用的有三種。一種是藉助ETL工具(如Oracle的OWB、SQL Server 2000的DTS、SQL Server2005的SSIS服務、Informatic等)實現，一種是SQL方式實現，另一種是ETL工具和SQL相結合。前兩種方法各有各的優缺點，藉助工具能夠快速的創建起ETL工程，屏蔽了複雜的編碼任務，提升了速度，下降了難度，可是缺乏靈活性。SQL的方法優勢是靈活，提升ETL運行效率，可是編碼複雜，對技術要求比較高。第三種是綜合了前面二種的優勢，會極大地提升ETL的開發速度和效率。服務器
1、 數據的抽取（Extract）
這一部分須要在調研階段作大量的工做，首先要搞清楚數據是從幾個業務系統中來,各個業務系統的數據庫服務器運行什麼DBMS,是否存在手工數據，手工數據量有多大，是否存在非結構化的數據等等，當收集完這些信息以後才能夠進行數據抽取的設計。工具
一、對於與存放DW的數據庫系統相同的數據源處理方法post
這一類數據源在設計上比較容易。通常狀況下，DBMS(SQLServer、Oracle)都會提供數據庫連接功能，在DW數據庫服務器和原業務系統之間創建直接的連接關係就能夠寫Select 語句直接訪問。編碼
二、對於與DW數據庫系統不一樣的數據源的處理方法spa
對於這一類數據源，通常狀況下也能夠經過ODBC的方式創建數據庫連接——如SQL Server和Oracle之間。若是不能創建數據庫連接，能夠有兩種方式完成，一種是經過工具將源數據導出成.txt或者是.xls文件，而後再將這些源系統文件導入到ODS中。另一種方法是經過程序接口來完成。設計
三、對於文件類型數據源(.txt,.xls)，能夠培訓業務人員利用數據庫工具將這些數據導入到指定的數據庫，而後從指定的數據庫中抽取。或者還能夠藉助工具實現。日誌
四、增量更新的問題orm
對於數據量大的系統，必須考慮增量抽取。通常狀況下，業務系統會記錄業務發生的時間，咱們能夠用來作增量的標誌,每次抽取以前首先判斷ODS中記錄最大的時間，而後根據這個時間去業務系統取大於這個時間全部的記錄。利用業務系統的時間戳，通常狀況下，業務系統沒有或者部分有時間戳。
2、數據的清洗轉換（Cleaning、Transform）
通常狀況下，數據倉庫分爲ODS、DW兩部分。一般的作法是從業務系統到ODS作清洗，將髒數據和不完整數據過濾掉，在從ODS到DW的過程當中轉換，進行一些業務規則的計算和聚合。
一、 數據清洗
數據清洗的任務是過濾那些不符合要求的數據，將過濾的結果交給業務主管部門，確認是否過濾掉仍是由業務單位修正以後再進行抽取。
不符合要求的數據主要是有不完整的數據、錯誤的數據、重複的數據三大類。
(1)不完整的數據：這一類數據主要是一些應該有的信息缺失，如供應商的名稱、分公司的名稱、客戶的區域信息缺失、業務系統中主表與明細表不能匹配等。對於這一類數據過濾出來，按缺失的內容分別寫入不一樣Excel文件向客戶提交，要求在規定的時間內補全。補全後才寫入數據倉庫。
(2)錯誤的數據：這一類錯誤產生的緣由是業務系統不夠健全，在接收輸入後沒有進行判斷直接寫入後臺數據庫形成的，好比數值數據輸成全角數字字符、字符串數據後面有一個回車操做、日期格式不正確、日期越界等。這一類數據也要分類，對於相似於全角字符、數據先後有不可見字符的問題，只能經過寫SQL語句的方式找出來，而後要求客戶在業務系統修正以後抽取。日期格式不正確的或者是日期越界的這一類錯誤會致使ETL運行失敗，這一類錯誤須要去業務系統數據庫用SQL的方式挑出來，交給業務主管部門要求限期修正，修正以後再抽取。
(3)重複的數據：對於這一類數據——特別是維表中會出現這種狀況——將重複數據記錄的全部字段導出來，讓客戶確認並整理。
數據清洗是一個反覆的過程，不可能在幾天內完成，只有不斷的發現問題，解決問題。對因而否過濾，是否修正通常要求客戶確認，對於過濾掉的數據，寫入Excel文件或者將過濾數據寫入數據表，在ETL開發的初期能夠天天向業務單位發送過濾數據的郵件，促使他們儘快地修正錯誤,同時也能夠作爲未來驗證數據的依據。數據清洗須要注意的是不要將有用的數據過濾掉，對於每一個過濾規則認真進行驗證，並要用戶確認。
二、 數據轉換
數據轉換的任務主要進行不一致的數據轉換、數據粒度的轉換，以及一些商務規則的計算。
(1)不一致數據轉換：這個過程是一個整合的過程，將不一樣業務系統的相同類型的數據統一，好比同一個供應商在結算系統的編碼是XX0001,而在CRM中編碼是YY0001，這樣在抽取過來以後統一轉換成一個編碼。
(2)數據粒度的轉換：業務系統通常存儲很是明細的數據，而數據倉庫中數據是用來分析的，不須要很是明細的數據。通常狀況下，會將業務系統數據按照數據倉庫粒度進行聚合。
(3)商務規則的計算：不一樣的企業有不一樣的業務規則、不一樣的數據指標，這些指標有的時候不是簡單的加加減減就能完成，這個時候須要在ETL中將這些數據指標計算好了以後存儲在數據倉庫中，以供分析使用。
3、ETL日誌、警告發送
一、 ETL日誌
ETL日誌分爲三類。
一類是執行過程日誌，這一部分日誌是在ETL執行過程當中每執行一步的記錄，記錄每次運行每一步驟的起始時間，影響了多少行數據，流水帳形式。
一類是錯誤日誌，當某個模塊出錯的時候寫錯誤日誌，記錄每次出錯的時間、出錯的模塊以及出錯的信息等。
第三類日誌是整體日誌，只記錄ETL開始時間、結束時間是否成功信息。若是使用ETL工具,ETL工具會自動產生一些日誌，這一類日誌也能夠做爲ETL日誌的一部分。
記錄日誌的目的是隨時能夠知道ETL運行狀況，若是出錯了，能夠知道哪裏出錯。
二、 警告發送
若是ETL出錯了，不只要造成ETL出錯日誌，並且要向系統管理員發送警告。發送警告的方式多種，通常經常使用的就是給系統管理員發送郵件，並附上出錯的信息，方便管理員排查錯誤。
ETL是BI項目的關鍵部分，也是一個長期的過程，只有不斷的發現問題並解決問題，才能使ETL運行效率更高，爲BI項目後期開發提供準確與高效的數據。
後記
作數據倉庫系統，ETL是關鍵的一環。說大了，ETL是數據整合解決方案，說小了，就是倒數據的工具。回憶一下工做這麼長時間以來，處理數據遷移、轉換的工做倒還真的很多。可是那些工做基本上是一次性工做或者很小數據量。但是在數據倉庫系統中，ETL上升到了必定的理論高度，和原來小打小鬧的工具使用不一樣了。究竟什麼不一樣，從名字上就能夠看到，人家已經將倒數據的過程分紅3個步驟，E、T、L分別表明抽取、轉換和裝載。
其實ETL過程就是數據流動的過程，從不一樣的數據源流向不一樣的目標數據。但在數據倉庫中，
ETL有幾個特色，
一是數據同步，它不是一次性倒完數據就拉到，它是常常性的活動，按照固定週期運行的，甚至如今還有人提出了實時ETL的概念。
二是數據量，通常都是巨大的，值得你將數據流動的過程拆分紅E、T和L。
如今有不少成熟的工具提供ETL功能，且不說他們的好壞。從應用角度來講，ETL的過程其實不是很是複雜，這些工具給數據倉庫工程帶來和很大的便利性，特別是開發的便利和維護的便利。但另外一方面，開發人員容易迷失在這些工具中。舉個例子，VB是一種很是簡單的語言而且也是很是易用的編程工具，上手特別快，可是真正VB的高手有多少？微軟設計的產品一般有個原則是「將使用者看成傻瓜」，在這個原則下，微軟的東西確實很是好用，可是對於開發者，若是你本身也將本身看成傻瓜，那就真的傻了。ETL工具也是同樣，這些工具爲咱們提供圖形化界面，讓咱們將主要的精力放在規則上，以期提升開發效率。從使用效果來講，確實使用這些工具可以很是快速地構建一個job來處理某個數據，不過從總體來看，並不見得他的總體效率會高多少。問題主要不是出在工具上，而是在設計、開發人員上。他們迷失在工具中，沒有去探求ETL的本質。能夠說這些工具應用了這麼長時間，在這麼多項目、環境中應用，它必然有它成功之處，它一定體現了ETL的本質。若是咱們不透過表面這些工具的簡單使用去看它背後蘊涵的思想，最終咱們做出來的東西也就是一個個獨立的job，將他們整合起來仍然有巨大的工做量。你們都知道「理論與實踐相結合」，若是在一個領域有所超越，必需要在理論水平上達到必定的高度.