kettle定时调度监控方案选型策略

前段时间实施才实施了一个金融业的中小型数据类支撑平台项目。由于种种原因，选择了目前使用最广的开源ETL工具-Kettle。其实kettle用来做ETL还是蛮方便的，使用门槛也不高，作业效率也将就。只要把规则标准制定好，开发也很快！但是kettle当时没有成熟的调度监控方案，以至于后来各种坑，好在现在都解决了。总结一下Kettle调度监控方案过程，避免kettle新手再入之前的坑。

       我们都知道调用kettle作业（job/ktr）有三种方法：

       1、kettle自带的spoon

       2、pan和kitchen

       3、java调kettle core

 

       本质上1和3是同一种方法，都是调用 kettle 核心类库。但是官方却建议我们采用pan和kitchen方式来调用kettle作业。也许这种方式接口更全面，但是不一定适合我们的调度监控需求。比如并行调用大量kettle作业就很崩溃。直接列表格，简单易懂：

		spoon自带 图形客户端	kitchen/pan 外部命令	java调kettle 核心库
调度能力	调度功能	☆	★	★
	调度性能	★	☆	★
	稳定性	☆	★	★
	资源占用	★	☆	★
	并行能力	☆	☆	★
	扩展性	☆	★	★
监控能力	图形监控	★	☆	☆
	日志功能	★	★	☆
注：“kitchen/pan” 和“java调kettle核心” 的调度能力由外部调度程序决定

 

       我们在设计一个方案时，有两个重要指标需要考虑：“稳定性和性能”。所以我们否决了用spoon来调，因为它不稳定，而且无法扩展，当调试工具用用还差不多。然后我们采取了官方建议，用pan和kitchen命令来调。但是在测试跑并行作业的时候，发现十分消耗系统资源。经常抛出内存溢出错误，我们曾一度认为是kettle优化的问题，各种内存调优也无法满足我们的并行度需求。最后不得以，我们研究了kettle的源代码发现：每次执行pan和kitchen都会初始化kettle环境，这个过程相当耗时间和资源。

       经过预算、资源、项目规模等充分评估。我们采用了“调度工具TASKCTL+java调kettle核心库”的方式。效率和并行能力都得以解决，并且监控管理能力也满足了我们行的需求！下面总结下选型建议吧：

       1、kettle自带的spoon：适合稳定性要求不高的小型定时需求的小企业。

       2、pan和kitchen：适合并行度要求不高的中小型企业。

       3、java调kettle core：适合IT技术能力较强，有实力的大中型企业。