選用開源ETL工具應注意的問題
Kettle是一個Java編寫的ETL工具，從4.2版本開始遵守Apache Licence 2.0協議，最新穩定版爲7.1。Kettle在2006年初加入了開源的BI公司Pentaho, 正式命名爲：Pentaho Data Integeration，簡稱“PDI”。自2017年9月20日起，Pentaho已經被合併於日本日立集團下的新公司： Hitachi Vantara。企業版Kettle不是免費獨立的，而是集成在Pentaho Business Analytics商業套件中。
因爲ETL屬於偏底層的數據基礎性工作，國內的項目甲方用戶往往並不太懂這方面的具體需求和技術要求，因而也不太關注項目開發服務商使用了什麼底層產品，對於這類數據產品在功能性、易用性、交換性能、數據實時性(最小延遲)、可靠穩定性、可運維管理性等方面缺乏具體的指標要求，通常不會要求通過嚴格的POC測試選型，再加上Kettle基礎版是開源免費的，因此許多集成商/開發商在項目中爲了想節省成本而盲目使用，結果往往是適得其反，造成了前期投入了相當大的開發人力成本及後期高昂的運維成本而達不到預期效果，騎虎難下。根據筆者二十多年的項目實施經驗及大數據領域所面臨的新要求，總結了選用kettle應注意的問題：
-
Kettle不支持實時數據同步場景。儘管kettle可以使用trigger方式獲取表級的增量數據，但源端的應用系統方一般不會同意使用這種侵入性很強的方式，而且trigger方式無法保證事務複製的完整性和時間次序性。
-
Kettle交換性能往往達不到要求。由於kettle採用了二十多年前老舊的Java調用技術，在任務多、數據量大的場景下，往往消枆過大的計算資源，交換性能急劇下降，造成系統阻塞的狀況出現。
-
Kettle對斷點信息沒有記錄和保存，無法保證斷點續傳及數據不丟失等可靠性要求。
-
Kettle的ETL 處理流程與目標輸出耦合性強，新的數據要求往往會造成處理流程的重新設計，靈活性差，導致時間週期和成本不斷增加。新出現的ELT（把T-處理放在了末端數倉中處理）技術架構和方案，將抽取、加載過程與轉換過程分開，並將所有需要的全量和實時增量數據快速加載至數倉，意味着在數倉結構設計中更具有靈活性來考慮新的變化需求，有利於項目的運維和管理，將項目的風險最小化。
-
日益增加的異構數據源環境，包括各種關係型數據庫、結構化及非結構化數據、以及NoSQL、MPP數據庫/倉庫和大數據平臺Hadoop/Kafka的應用環境，Kettle缺乏對新數據源的有效支持能力。
-
免費版的Kettle缺乏必要的數據異常處理和監控運維等管理功能服務，項目開發商/服務商在項目成本及時間的約束下，難於滿足這類管理功能需求，造成後續系統運維質量及用戶滿意度的下降。
-
在企業私有云和混合雲的計算環境下，Kettle等傳統產品的C/S架構難於滿足構建雲與邊緣端的數據交換，並支持遠程多用戶共享使用的要求。
-
關於幾種主流數據同步/ETL產品與Kettle的功能比較，請參閱:
幾種主流數據同步/ETL工具的比較(TurboDX、Goldengate、Kettle、DataX、Informatica)
參考
http://www.synball.com/blog/article/ETL/
