Kettle作為用戶規模最多的開源ETL工具，強大簡潔的功能深受廣大ETL從業者的歡迎。但kettle本身的調度監控功能卻非常弱。
連Pentaho官方都建議采用crontab(Unix平台)和計划任務(Windows平台)來完成調度功能。所以大家在實施kettle作業調度功能的時候，通常采用以下幾種方式：使用spoon程序來啟動Job，使用crontab或計划任務，自主開發java程序來調用kettle的類庫。下面分析這幾種調度方式的利弊。
一、spoon 程序調用Job（kjb作業）：
該方式是kettle原生的調度方式，實現了基本的定時調度功能。比如按月，周，日，時點的方式來啟動。並且執行速度很快。但是對於ETL作業來說，其本質是后台數據處理邏輯，卻要必須保持spoon桌面程序一直運行。
無論從ETL平台穩定性來說，還是自動化管理標准來說，都非常不適宜。所以一般來說企業是不會選擇此方案。
二、官方建議的crontab或計划任務：
該方式是目前比較流行的方案。對於一般用戶來說，系統自帶的時間計划可以滿足基本的調度功能需求。但是對於復雜的調度邏輯，比如依賴、互斥、自定義條件分支，錯誤重試、斷點續跑等高級調度特性，就無法應對了。
由於是采用系統外部命令來調用kettle作業，所以每次調起一個轉換或作業的時候，就會消耗大量的時間（>10秒）來初始化一個新的kettle運行環境。在並行調用多個kettle作業的時候，特別是調用數據資源庫里的作業，容易引起系統級別的錯誤，帶來不穩定性。
另外初始化kettle運行環境實際就是啟動一個JVM進程。如果多個kettle作業同時運行，很容易把系統內存撐爆。筆者測試過通過此方式同時運行5個轉換（簡單文本操作）就把2GB的內存撐爆了。所以此方式不太適合並行調用kettle作業。
大家試想一下，如果我們有1000個作業需要調用。那計划任務腳本應該怎么寫呢？我們應該怎么維護呢？顯而易見的是，隨着作業數的增多，維護成本將會成倍增加。
我們費盡心力，寫了長長的腳本程序，終於把這1000個作業調起了！正在為后台自動化調度的成功實施而自喜的時候，結果領導又安排了新的任務：我要監控一下作業的運行情況和日志哦......
三、自主開發java程序來調kettle類庫。
領導不是要監控作業的運行情況和日志么？我自認為java水平還不錯。大不了我寫一個web應用來讀取資源庫的日志信息吧。並且之前的調度方式效率太低了，我用java程序模擬spoon環境來調kettle類庫。這樣子效率也提高，這肯定是一個不錯的方案。調度功能不強大？采用oozie吧，挺流行的... 算算工期6個人月？嗯...還是再考慮考慮吧。
總而言之，打算采用自主開發java調kettle的話，不是一個小工程，還是得當成單獨項目來立項吧。
難道就沒有其它敏捷適用的方案了嗎？其實在ETL調度領域，TASKCTL早就實現了對kettle作業實時調度監控管理了。並且在最新的版本中，直接調用kettle核心，調度效率大幅度提升！我們來看看使用TASKCTL調度kettle到底有哪些優勢：
1、完整的調度核心：可以實現關系（依賴互斥、串並引用）策略，排程計划策略，容錯策略，自定義策略。怎么調都可以。
2、企業級特性：支持跨平台、分布式、高可靠。無論是linux上還是windows上面的kettle作業，都能統一監控管理。
3、靈活的人工干預：人工運行任意流程分支，對作業流程實現斷點，暫停。對作業實現強制通過，重跑等。
4、效率大幅提升:經筆者測試：運行60次同樣的ktr。 采用傳統的pan來調大約耗時：21分15秒（無法並行,並行即報錯）。而采用TASKCTL來調，則耗時不到5秒（並行度為20）
5、全方位實時監控：采用實時刷新、圖形、多角度多口徑統計以及短信等方式對整個平台作業進行全方位監控，以便用戶及時掌握哪些作業正在運行、錯誤原因、失敗、警告等信息
TASKCTL說得這么好。到底好不好用？安裝方便不方便呢？ok，我們來部署一套試試吧。
1、安裝TASKCTL服務端：http://www.taskctl.com/forum/detail_99.html
2、安裝TASKCTL桌面客戶端：http://www.taskctl.com/Public/file/tar/TaskctlClientInstall_5.0.zip
3、安裝TASKCTL-kettle插件和實例流程 http://www.taskctl.com/forum/detail_124.html
如果您有一定的linux基礎的話。整個步驟30分鍾之內就能搞定咯。
原文地址：https://blog.csdn.net/qq_38797366/article/details/83272555