人們的生活水平逐漸提高，物質生活得到滿足的同時，精神需求進而隨之增加，電腦已經成為我們生活中和工作中不可缺少的一部分，電腦是由一些軟件、系統、程序等組成，那么我們如果想要對電腦更好的使用，我們必須對這些有所了解，下面小編就帶領大家一起來學習如何用Kettle開源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商業套件中。

選用Kettle開源ETL工具教程圖1

因為ETL屬于偏底層的數據基礎性工作，國內的項目甲方用戶往往并不太懂這方面的具體需求和技術要求，因而也不太關注項目開發服務商使用了什么底層產品，對于這類數據產品在功能性、易用性、交換性能、數據實時性(最小延遲)、可靠穩定性、可運維管理性等方面缺乏具體的指標要求，通常不會要求通過嚴格的POC測試選型，再加上Kettle基礎版是開源免費的，因此許多集成商/開發商在項目中為了想節省成本而盲目使用，結果往往是適得其反，造成了前期投入了相當大的開發人力成本及后期高昂的運維成本而達不到預期效果，騎虎難下。根據筆者二十多年的項目實施經驗及大數據領域所面臨的新要求，總結了選用kettle應注意的問題：

選用Kettle開源ETL工具教程圖2

Kettle不支持實時數據同步場景。盡管kettle可以使用trigger方式獲取表級的增量數據，但源端的應用系統方一般不會同意使用這種侵入性很強的方式，而且trigger方式無法保證事務復制的完整性和時間次序性。

Kettle交換性能往往達不到要求。由于kettle采用了二十多年前老舊的Java調用技術，在任務多、數據量大的場景下，往往消枆過大的計算資源，交換性能急劇下降，造成系統阻塞的狀況出現。

Kettle對斷點信息沒有記錄和保存，無法保證斷點續傳及數據不丟失等可靠性要求。

Kettle的ETL 處理流程與目標輸出耦合性強，新的數據要求往往會造成處理流程的重新設計，靈活性差，導致時間周期和成本不斷增加。新出現的ELT（把T-處理放在了末端數倉中處理）技術架構和方案，將抽取、加載過程與轉換過程分開，并將所有需要的全量和實時增量數據快速加載至數倉，意味著在數倉結構設計中更具有靈活性來考慮新的變化需求，有利于項目的運維和管理，將項目的風險最小化。

選用Kettle開源ETL工具教程圖3

日益增加的異構數據源環境，包括各種關系型數據庫、結構化及非結構化數據、以及NoSQL、MPP數據庫/倉庫和大數據平臺Hadoop/Kafka的應用環境，Kettle缺乏對新數據源的有效支持能力。

免費版的Kettle缺乏必要的數據異常處理和監控運維等管理功能服務，項目開發商/服務商在項目成本及時間的約束下，難于滿足這類管理功能需求，造成后續系統運維質量及用戶滿意度的下降。

在企業私有云和混合云的計算環境下，Kettle等傳統產品的C/S架構難于滿足構建云與邊緣端的數據交換，并支持遠程多用戶共享使用的要求。