kettle调度监控最佳实践

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、全方位实时监控：采用实时刷新、图形、多角度多口径统计以及短信等方式对整个平台作业进行全方位监控，以便用户及时掌握哪些作业正在运行、错误原因、失败、警告等信息