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

6、日志集中管理:统一平台管理日志,从图形节点追踪作业日志,更加直观快捷。

7、学习轻松入门:文档资料齐全。核心团队技术交流QQ群在线手把手指导,还有完整的入门进阶指导视频教程。kettle调度监控最佳实践-LMLPHP(扫码关注后->产品方案->产品视频)

kettle调度监控最佳实践-LMLPHP

(web统一调度监控平台)

kettle调度监控最佳实践-LMLPHP

(Windows客户端-Monitor)

kettle调度监控最佳实践-LMLPHP

(Monitor-日志快速定位)

05-28 00:32