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

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

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

本质上1和3是同一种方法，都是调用 kettle 核心类库。但是官方却建议我们采用pan和kitchen方式来调用kettle作业。也许这种方式接口更全面，但是不一定适合我们的调度监控需求。比如并行调用大量kettle作业就很崩溃。直接列表格，简单易懂： 调度功能 调度性能 调度能力 稳定性 资源占用 并行能力 扩展性 监控能力 图形监控 日志功能 spoon自带 图形客户端 ☆ ★ ☆ ★ ☆ ☆ ★ ★ kitchen/pan 外部命令 ★ ☆ ★ ☆ ☆ ★ ☆ ★ java调kettle 核心库 ★ ★ ★ ★ ★ ★ ☆ ☆ 我们都知道调用kettle作业（job/ktr）有三种方法： 1、kettle自带的spoon 2、pan和kitchen 3、java调kettle core

注：“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技术能力较强，有实力的大中型企业。