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-日志快速定位)