如果我們想要優化乙個etl（ktr或者kjb）的效能，我們首先需要知道的就是它的瓶頸在**。而這些資訊一般只能在etl執行的步驟度量中看到，並且是不會持久化的。如果你希望把一些資料記錄下來，幫助以後進行查閱，那麼可以開啟資料庫日誌和效能監控。
作業
edit -> settings -> log轉化
edit -> settings -> loggingedit -> settings -> monitoringstep performance measurement interval(ms) (對每一步進行效能監測的度量間隔)：這乙個選項的大小會影響你在資料庫記錄的詳細程度，一般以執行總時長的十分之一左右的數值即可，這樣對於每一步可以記錄10組左右的資料，足夠做一些基本的分析，注意單位是毫秒。
maximum number of snapshots in memory（在記憶體中儲存的最大的快照數量）：這乙個選項在我們系統的記憶體不是很足夠時可以使用，但是太小可能會導致無法分析出來，和上面的選項搭配使用。
我們在執行過程中會輸出大量日誌，這樣我們在定位問題的時候需要去日誌裡找出錯的位置在**。kettle中可以對ktr單獨配置日誌，如果我們把ktr的錯誤日誌直接輸出出來，那麼在定位問題的時候就會非常方便，設定的方法如下：
在job中，選擇需要輸出錯誤日誌的步驟（經常出錯或者可能出錯的步驟），編輯，選擇logging，勾選specfify logfile（指定日誌檔案），選擇路徑、字尾，日誌級別選擇錯誤日誌（除錯時可以選詳細或者行級）。
後面的選項：
create parent folder（建立父資料夾）：該選項是指如果給定的路徑中有不存在的資料夾會自動建立。
include date in logfile：日誌中包含日期。
include time in logfile：日誌中包含時間。
資料庫配置
連線池配置
資料庫連線池在業務資料量比較多，而且短連線很多的時候適合配置。在這個時候，每次資料庫連線建立和斷開所花費的時間遠長於進行資料庫操作的時間，配置連線池可以更好的利用網路資源，將連線建立和斷開的開銷降低到最小。因此在大多數情況下，配置kettle資料庫連線池均可提高etl的效能，如果沒有配置連線池，那麼在資料量大時候很容易出現error connecting database error。
該設定主要是在建立及管理連線的部分：
資料庫連線 -> 連線池 -> 使用連線池
設定連線池的大小及相應引數，這些引數需要根據資料庫實際情況及使用情況進行配置，可以諮詢dba。
在資料庫連線的面板中，選擇「選項」，（上面兩個是普通和高階），在引數列表中，根據情況新增以下引數：
defaultrowprefetch = 200; (default = 10)(oracle only) readtimeout = 60;(mysql only) useserverprepstmts=false;
rewritebatchedstatements=true ; usecompression=true ;
提高資料庫操作中的commit size
在寫入資料庫的時候，有乙個commit size的選項，這個值在預設的情況下是1,我們可以根據伺服器的效能，將這個值改大一些，通常會改為100以上的值。這個值在寫入量比較大的時候可以顯著提公升資料庫的效能，但是並不是越大越好，通常範圍在100〜10000,需要根據實際情況進行配置，具體數值可以根據效能監控的記錄來確定。
這個值從1調整到合適值效能大約可以翻倍，一般情況下也有20%左右的效率提公升。
insert/update增加錯誤處理步驟分離insert和update
kettle的原作者在他的部落格中提到過，盡量不要使用insert/update元件，因為這個元件慢的他都受不了，正常情況下在幾百條每秒（對比tableinsert幾萬的速度）。如果必須使用這個元件的時候，那麼可以在insert/update中勾選don't perform any updates（不做任何更新操作），然後把錯誤的資料指向一具資料庫更新的操作，這要就把新增和更新分離了開來。根據官網描述，在少量更新大量插入的時候效能可以提高到原來的3倍左右，實測時達不到，可能和資料集有關。
資料庫分組和排序優於etl分組和排序
在etl中減少排序和分組的操作，盡量使用資料庫完成排序和分組。在ktr中，資料是使用流的方式在不同的步驟間傳遞資料，使用排序和分組的操作會在這一步阻塞ktr的執行，直到接收到前面所有步驟傳過來的資料為止，導致etl的執行時間增長，占用的記憶體增大。
使用blocking step也會將流阻塞到這一步，和以上情況類似。
調整步驟之間的快取
ktr是乙個流式的處理過程，步驟與步驟之間的資料傳遞是通過快取來完成的，調整快取的大小可以對ktr的執行產生明顯的影響。
edit —> settings —> miscellaneous —> nr of rows in rowset （快取的記錄行數）
在效能監測時，這也是乙個用來找到瓶頸的核心引數。如果某一步的輸入和配置的快取大小接近，但是輸出很小，那麼這一步就是效能的瓶頸。如果快取大小配置了10000,但是幾乎所有步驟的輸入輸出都只有很低的乙個值，比如50,那麼，效能的瓶頸就是輸入。
延遲轉化
很多欄位在讀入到最後輸出，實際上都沒有被操作過，開啟延遲轉化可以讓kettle在必要的時候再進行轉化。這裡的轉化是指從二進位製到字串之間的轉化，在輸入和輸出都是文字的時候更為明顯。事實上，select values在轉化的效率上也高於讀取時直接轉化。
使用複製並行處理某個步驟
現在的機器都是多核的，使用多cpu並行處理對cpu使用密集的步驟可以提公升etl的執行效率。
在需要並行處理的步驟上，選擇change number of copies to start, 修改這個值為小於機器核心總數的乙個值，一般2〜4就可以滿足要求。
ktr中，儘量減少步驟的數量
步驟的數量會在影響ktr的執行效率，包含並行處理時複製的數量。ktr中步驟的數量為機器核心總數的3〜4倍最佳，如果超過這個範圍，可以考慮通過減少步驟數量的方式以提高ktr的執行效率。
不要在select values的步驟刪除某個字段
如果在select values的步驟刪除某個字段，kettle會需要調整現有的儲存結構，在可以不刪除的時候盡量不要刪除字段。
這部分和所有使用到資料庫的地方一樣，優化查詢語句，優化表結構設計，新增合適的索引等。
總體來說，這部分的內容主要就是資料庫配置的優化及etl本身的優化，當然在提高效率的時候也要兼顧資源的使用情況，有的方法可以提高效率，但是會消耗更多資源。因此我們需要綜合考慮，通過一些合理的方式既能充分的利用資源，又不會因壓力過大影響業務的正常進行。
etl可以看作是乙個視覺化的、資料處理領域的程式設計工具，因此，etl編寫過程不僅需要了解業務，還需要一些資料庫方面的知識進行支援，如果寫出來的etl效率低下，執行時間長，吃資源多，那麼，是時候需要考慮優化一下etl了。.
ETL開源工具kettle中Job流程的理解
job流程 可執行執行緒，代表etl控制流中的一項邏輯任務。job節點將會順序執行，每個job節點會產生乙個結果，能作為別的分支上job節點的條件。jobentry節點 自定義外掛程式 代表著功能 hop連線 代表流程邏輯 result結果物件 流程job繼承執行緒thread類，就是乙個可執行執行...
Kettle和ETL的基本構成
不多說，直接上乾貨！這裡，我說的通俗易懂點，好方便大家的理解。etl解決方案就像業務流程一樣，具有輸入 輸出，以及乙個或多個工作環節，處理步驟。同樣的，這些步驟也具有輸入和輸出，並可以執行將乙個輸人轉化為輸出的操作。想一想，例如，在一家保險公司理賠部，門上有乙個大牌子，上面寫著理賠部，這就意味著它描...
關於使用ETL工具Kettle的簡單介紹（二）
該篇主要描述已實現的一種 etl過程 環境描述 由於源端的表結構和正式庫的表結構大部分是一一對應的，所以對於這大部分表進行設計了一套通用的過程進行轉換。現在先來描述該套設計，對於一對多和多對一的過程下章進行描述。設計概述 主要需要設計幾個所需的表，n 第乙個表 該表是用來配置源端表結構與目的端表結構...