這個有可能是kettle併發執行引起的

例如下面圖所示

執行kettle報以下錯誤

couldn't get row from result

kettle your server commond encountered a deaklock situation

報這個異常，解決方法是利用kettle本身的一個屬性進行規避，就是修改kettle的併發執行為單步執行，缺點為執行效率會下降。

經過測試，後期沒有在發現這個問題

參考文件

http://type-exit.org/adventures-with-open-source-bi/2010/11/transactional-kettle-transformations/

下面是摘抄自上面地址中的內容

事務性轉換

• 鳴叫
• 分享
• 電子郵件

在水壺中執行轉換時，如果出現錯誤，則有時會使整個轉換的效果回滾。如果您的資料庫系統支援事務，則Kettle可以利用該功能在失敗時啟用回滾。通過在轉換設定對話方塊的“其他”選項卡上啟用“生成轉換資料庫事務”複選框，可以在水壺中啟用事務行為。本文解釋了此功能的用途，以及它在其他情況下的用途。

仔細看看預設行為

如果關閉“make transformation database transactional”功能（預設值），則使用資料庫的步驟的每個副本都會建立並維護自己與資料庫的連線。考慮一個適用於示例資料庫“MyData”的簡單轉換。

啟用交易模式

但在某些情況下，預設的並行模型可能不是最佳選擇。啟用“交易”功能有兩個作用：

1. 所有使用資料庫的步驟都共享一個連線。
2. 每個連線在開啟時都會開始一個事務。如果轉換成功完成，則事務將被提交。如果轉換遇到錯誤並且過早結束，它將回滾。

共享資料庫連線通常意味著轉換執行速度稍慢。

寫和重讀記錄

水壺初學者有時很難理解為什麼他們不能一步寫出記錄，並在相同的轉換過程中更可靠地在下游進行檢視。這是因為在預設模式下寫入步驟和查詢步驟建立自己的資料庫連線，寫入步驟通常設定為以相當大的批量寫入。如果啟用“事務性”模式，則資料庫連線將被共享。因此，如果寫入步驟配置為批量大小為1（即時查詢執行），則可以在轉換的下一個步驟中可靠地查詢寫入的記錄：沒有併發問題，沒有延遲查詢造成的問題。有人可能會認為，利用這一事實進行轉換的設計並不完善（大多數情況下它們可能不是），

併發修改

我有時會看到轉換，這些轉換會在單獨的更新步驟中更新相同的記錄（可能是它們的不同欄位）。在預設模式下，這可能會導致零星的死鎖情況。假設這兩個步驟都嘗試在併發執行批次中更改相同的記錄。根據資料庫系統的不同，這可能會導致死鎖（有希望不會導致系統停頓，但會被RDBMS檢測到）。這種情況也可以通過將資料庫連線設定為“事務性”來彌補。事實上，使用單個連線會阻止併發批處理的執行，所以永遠不會發生死鎖。同樣，最好不要設計圍繞該事實的轉換，而是嘗試收集對記錄的所有更改並僅更新每條記錄一次。但是，如果您需要快速修復受此影響的轉換，