ETL 工具 VS SQL 整理

兩個都用過，感覺informatica易於後期管理，尤其是糾正資料，後期補資料的時候，資料流一目瞭然。 SQL的效率高，但是後期維護實在不方便。找個資料流要糾結半天。。 ＥＴＬ工具更易於管理維護，　尤其是複雜的清洗過程．

ETL 工具適用於固定的，穩定的流程； 而SQL代碼適用於個人化，獨立，可變性比較大的情況！ ETL工具能做的事，SQL也都可以完成，反過說就不行了。 ETL工具的好處在於流程處理的標準化管理，以及任務調度的可視性、資料稽核過程的可視性等。 個人以為，對於工程項目，這兩者將是共存的情況。 ETL工具顯然有助於標準化。 好的DBA可以寫出更優美精鍊的語句，但是不利於維護和標準化。 第一要根據商務項目的規模，現在有些BI項目甲方規劃的投入就很少了，如果再買第三方工具乙方根本就沒錢賺了，一般這樣的項目開發時候使用sql做etl過程的多，或者是乙方自己開發的etl工具，但是基本不能達到DS那樣的水平。 第二在夠大的BI項目或者甲方有ETL工具的投入時候才會採用，但是也要和sql結合使用。 第三要看etl邏輯的複雜度，一般的清洗工作etl工具使用比sql靈活簡單，但是在複雜商務邏輯處理就不行了，例如有資料拆分，一條記錄根據商務規則拆分幾條，這樣要涉及數值型小數保留位元，最後拆分後的幾條記錄合計值是否能保證和拆分前一致這樣的問題都是存在的。 一些異構的資料庫還是需要用ETL工具的吧。遇到需要把文本，MF資料，DB2,SQLServer, paradox的資料一起抽取到用oracle的warehouse中，似乎只有用ETL工具。 另外ETL在大型企業裡的分工還是很細的， 做mapping,建workflow,做monitor，做資料處理都是由不同的team來完成的， 我之前的一個項目，老美負責做mapping,workflow. 中國這邊只有monitor的許可權，主要monitor ETL工具的裝載速度和進度，如果遇到效能問題或者資料錯誤，就page DBA團隊或者另外的團隊來處理。 大公司對許可權要求比較高，類似於這樣的需求都必須通過ETL工具來實現的。 ETL工具相對於SQL的一個很大的優勢在於代碼的可維護性上 寫SQL，取決於開發人員的經驗與習慣，如原開發人員離職，由其他人接手任務的話，讀懂之前開發人員的代碼會花費較長的時間 但在複雜的資料處理中，還是應該用SQL來處理，嵌套在ETL工具中。 ETL 工具開發效率高、便於後期維護。SQL代碼靈活，如果開發人員編碼水平過硬，資料處理效率高 個人感覺吧大家輕噴， 從以前工作的中來總結出來一些東西吧       etl 和sql是完全不同的方面，     etl正如其名一樣，當然大家也可以說elt 呼呼，更多的是清洗裝載過程，當然你也可以說我可以直接用SQL建立呀，    etl更多的是一種方案，一個資料倉儲上資料來源清洗載入的過程，拿我們以前舉例，可以定製自己 的觸發機制以及通過系統 的子線程 來分配任務運行機制， 當然你也可以用SQL+其它語言來解決 。   如果說不同的方面，我個人感覺SQL只是一種語言，一種操作資料的方式，而ETL更多的是一種方案，一種資料加工挖掘的方案。 認同大家的觀點： 1.  工具容易正常化，易於維護； 2. 工具有自身的特有優勢，比如各個點的平行處理。CDC、行列轉換、SCD的簡單設定就可實現。中繼資料管理等； 3. 工具能實現的基本SQL也能實現，有時可能要寫複雜SQL而已； 4. SQL在處理複雜邏輯時靈活性更高，優勢明細； 5. SQL的不易維護和管理。 sql（含預存程序）做轉換清晰邏輯，開源etl做調度。  省成本。效率高。 “很多人認為用工具沒有純手工打造的人牛B，那是這些人根本就沒把工具玩透” 非常贊同你的觀點！ 順便說句：在打造企業級的應用平台時，是純SQL無法企及的坎。 很多人理解ETL工具都狹義的理解為ETL任務設計管理工具了， 在我看來，ETL工具要分 ETL任務設計管理和ETL調度監控管理兩個方面。 最近網上這個TASKCTL貌似火了，而且現在還開源了。 free的ETL調度平台　＋　free的ETL任務設計(例如用kettle) = free的ETL解決方案，多好啊 二者互相補充，我一般是習慣於，複雜的商務邏輯由程式實現，調度和簡單的商務邏輯由工具實現； 工具和代碼都有各自的應用情境，比如工具在異構資料來源之間的同步有優勢，但適用於資料量不是很大的情況下；另工具的調度的功能也特別好，這樣你就不用再寫專門的程式來實現調度了，在工具基礎層可以方便的進行二次開發設計，對異常情況可以較好的進行處理。 結構化資料，資料庫引擎效率更高。 http://www.itpub.net/thread-1581786-1-1.html