kettle調度監控最佳實踐

    Kettle做爲用戶規模最多的開源ETL工具，強大簡潔的功能深受廣大ETL從業者的歡迎。但kettle自己的調度監控功能卻很是弱。

    連Pentaho官方都建議採用crontab(Unix平臺)和計劃任務(Windows平臺)來完成調度功能。因此你們在實施kettle做業調度功能的時候，一般採用如下幾種方式：使用spoon程序來啓動Job，使用crontab或計劃任務，自主開發java程序來調用kettle的類庫。下面分析這幾種調度方式的利弊。

1、spoon 程序調用Job（kjb做業）：

    該方式是kettle原生的調度方式，實現了基本的定時調度功能。好比按月，周，日，時點的方式來啓動。而且執行速度很快。可是對於ETL做業來講，其本質是後臺數據處理邏輯，卻要必須保持spoon桌面程序一直運行。

    不管從ETL平臺穩定性來講，仍是自動化管理標準來講，都很是不適宜。因此通常來講企業是不會選擇此方案。

 

2、官方建議的crontab或計劃任務：

    該方式是目前比較流行的方案。對於通常用戶來講，系統自帶的時間計劃能夠知足基本的調度功能需求。可是對於複雜的調度邏輯，好比依賴、互斥、自定義條件分支，錯誤重試、斷點續跑等高級調度特性，就沒法應對了。

    因爲是採用系統外部命令來調用kettle做業，因此每次調起一個轉換或做業的時候，就會消耗大量的時間（>10秒）來初始化一個新的kettle運行環境。在並行調用多個kettle做業的時候，特別是調用數據資源庫裏的做業，容易引發系統級別的錯誤，帶來不穩定性。

    另外初始化kettle運行環境實際就是啓動一個JVM進程。若是多個kettle做業同時運行，很容易把系統內存撐爆。筆者測試過經過此方式同時運行5個轉換（簡單文本操做）就把2GB的內存撐爆了。因此此方式不太適合並行調用kettle做業。

    你們試想一下，若是咱們有1000個做業須要調用。那計劃任務腳本應該怎麼寫呢？咱們應該怎麼維護呢？顯而易見的是，隨着做業數的增多，維護成本將會成倍增長。

    咱們費盡心力，寫了長長的腳本程序，終於把這1000個做業調起了！正在爲後臺自動化調度的成功實施而自喜的時候，結果領導又安排了新的任務：我要監控一下做業的運行狀況和日誌哦......

 

3、自主開發java程序來調kettle類庫。

    領導不是要監控做業的運行狀況和日誌麼？我自認爲java水平還不錯。大不了我寫一個web應用來讀取資源庫的日誌信息吧。而且以前的調度方式效率過低了，我用java程序模擬spoon環境來調kettle類庫。這樣子效率也提升，這確定是一個不錯的方案。調度功能不強大？採用oozie吧，挺流行的... 算算工期6我的月？嗯...仍是再考慮考慮吧。

    總而言之，打算採用自主開發java調kettle的話，不是一個小工程，仍是得當成單獨項目來立項吧。

 

    難道就沒有其它敏捷適用的方案了嗎？其實在ETL調度領域，TASKCTL早就實現了對kettle做業實時調度監控管理了。而且在最新的版本中，直接調用kettle核心，調度效率大幅度提高！咱們來看看使用TASKCTL調度kettle到底有哪些優點：

一、完整的調度核心：能夠實現關係（依賴互斥、串並引用）策略，排程計劃策略，容錯策略，自定義策略。怎麼調均可以。

二、企業級特性：支持跨平臺、分佈式、高可靠。不管是linux上仍是windows上面的kettle做業，都能統一監控管理。

三、靈活的人工干預：人工運行任意流程分支，對做業流程實現斷點，暫停。對做業實現強制經過，重跑等。

四、效率大幅提高:經筆者測試：運行60次一樣的ktr。 採用傳統的pan來調大約耗時：21分15秒（沒法並行,並行即報錯）。而採用TASKCTL來調，則耗時不到5秒（並行度爲20）

五、全方位實時監控：採用實時刷新、圖形、多角度多口徑統計以及短信等方式對整個平臺做業進行全方位監控，以便用戶及時掌握哪些做業正在運行、錯誤緣由、失敗、警告等信息

六、日誌集中管理：統一平臺管理日誌，從圖形節點追蹤做業日誌，更加直觀快捷。

七、學習輕鬆入門：文檔資料齊全。核心團隊技術交流QQ羣在線手把手指導，還有完整的入門進階指導視頻教程。(掃碼關注後->產品方案->產品視頻)

 

（web統一調度監控平臺）

（Windows客戶端-Monitor）

(Monitor-日誌快速定位)