简介这是一份基于Kettle Carte服务开发的ETL任务管理系统源码面向Java开发人员、ETL工程师以及信息化管理方向学习者重点解决Kettle作业/转换的远程管控、任务并发调度与分布式执行问题。压缩包共82个文件整体约220KB以41个Java源文件为核心搭配5个XML、5个Properties、3个YML等配置文件同时包含HTML、JavaScript前端页面以及Maven相关构建脚本zbak备份文件保留了不同阶段代码便于对照排错。系统后端采用Java实现、前端使用HTML5/CSS3/JavaScript构建界面涉及Carte RESTful API集成、任务优先级控制、执行状态监控、并发与分布式管理等关键设计并附有项目模块划分与依赖配置适合作为课程设计或企业级ETL任务管理二次开发的参考资料。资源已有80人学习浏览内容来源于网络分享仅供学习交流使用请遵守版权规范。1. Kettle Carte 不是调度中心先把它当分布式执行器多数团队把 Kettle 用成了单机工具在 Spoon 里调好转换设个 Windows 计划任务能跑就算交付。可一旦任务数量超过二十个节点换机器、任务重跑、状态查看就全乱了。这套系统里最难的部分反而在 Kettle 之外。Carte 是 Kettle 自带的轻量级 Web 服务能远程接收作业Job和转换Transformation的执行请求。它没有内置调度器不负责“几点跑”只负责“把活接到并跑完”。所谓基于 Kettle Carte 的任务管理系统就是把 Carte 部署到一个或多个节点上由一套独立的管理端负责任务登记、节点注册、心跳检测和并发控制。适合已经在用 Kettle 做数据同步、报表抽取想从“每台机器各自跑”升级成“集中调度、分布执行”的团队。2. Carte 节点部署与配置参数先把执行器立起来2.1 kettle 安装包里的 Carte 启动方式从官网下载的 Kettle 安装包解压后直接可用里面自带 Carte 的启动脚本。Linux 下是carte.shWindows 下是carte.bat位置在安装包的根目录和 Spoon 同级。不需要额外编译也不需要装独立服务一个解压目录就是一个可运行的节点。# Linux 启动 Carte第一个参数是绑定地址第二个是端口 ./carte.sh 0.0.0.0 80810.0.0.0表示监听所有网卡接口这样管理端和其他 Carte 节点才能远程访问如果只写127.0.0.1那这个 Carte 就只能本机自己调用注册到 master 时也大概率失败。端口随意避免和现有服务冲突即可常见的是 8081。Windows 下双击carte.bat会弹出控制台窗口生产环境建议注册成服务或者用nssm托管避免窗口被误关导致任务中断。启动完后浏览器访问http://节点IP:8081能看到 Carte 自带的网页状态页说明服务已经起来了。确认端口正常监听后再进入下一步配置。2.2 用 carte-config.xml 定义节点角色与端口Carte 不配置也能启动但只有一个默认角色适合单节点跑。要组建真正意义上的任务管理系统每个节点都要明确身份这个节点是主节点还是从节点注册到谁用什么账号认证。这些写在 Kettle 安装目录下的carte-config.xml里以 8.x/9.x 常见模板为参考字段随版本略有差异?xml version1.0 encodingUTF-8? slave_config slave nameetl-node-01/name hostname192.168.10.21/hostname port8081/port usernamecluster/username passwordcluster/password masterN/master ssl_modeN/ssl_mode /slave repository nameetl-repo/name /repository system sleep_time5/sleep_time /system /slave_config这个配置里最关键的是master和username/password。master取Y时当前节点作为主节点其他节点启动后会向它注册取N时作为从节点负责实际执行任务。用户名密码默认是cluster/cluster管理端调用 Carte 的 REST 接口时要用同一套凭据做 Basic Auth生产环境一定要改掉。下面是几个必须调的参数参数作用建议值name节点在集群中的唯一标识注册后靠它区分带环境前缀如prod-node-01hostname对外可达的地址从节点注册时用写内网 IP别写 localhostportCarte HTTP 服务端口与启动命令第二个参数保持一致master是否作为主节点一个集群只设一个 Yusername/password调用接口的认证凭据不用默认值改成强密码sleep_time节点与 master 之间的心跳间隔秒数5 左右即可过小徒增请求量同一条机器上可以跑多个 Carte 实例端口不同就行。但要注意多个实例共享同一份 Kettle 安装目录时临时文件目录和日志目录会互相干扰。稳妥做法是每个实例单独复制一份解压目录路径隔离排查问题时也更干净。2.3 堆内存与字符集影响长任务的两个启动参数Kettle 启动脚本默认的堆内存不算大跑短任务没问题但 Carte 作为常驻服务会被持续提交任务堆设置不合理时跑上几天就会出现内存溢出表现还很隐蔽错误信息可能指向数据库连接超时实际是 GC 频繁导致响应变慢。打开carte.sh或同目录下的set-env.sh找到 JVM 参数区# 调整堆内存与编码放在 JVM 参数区 PENTAHO_DI_JAVA_OPTIONS-Xms1024m -Xmx4096m -Dfile.encodingUTF-8 -Djava.awt.headlesstrue # 导出后启动 export PENTAHO_DI_JAVA_OPTIONS ./carte.sh 0.0.0.0 8081-Xms和-Xmx分别控制初始堆和最大堆。Carte 节点上同时跑的转换越多需要的堆越大建议至少-Xms1024m -Xmx2048m如果单节点并发五六个转换直接给到 4G。-Dfile.encodingUTF-8强烈建议加上否则 CSV 输出、表输入的中文字段会出现乱码而且这类问题在开发环境复现不出来只有到了生产数据量下才暴露。之前遇到过一次管理端连续提交 12 个转换后第三个开始全部报“无法获取数据库连接”。当时怀疑是连接池满了查下来其实是 Carte 进程堆内存不足频繁 Full GC数据库连接的等待时间被拖到了超时阈值以上。所以 Carte 节点的内存监控一定要前置不能等告警。3. Carte 任务发布与远程调用怎样让 job 真正跑起来3.1 先统一发布路径再谈远程调用Carte 执行的是本地文件系统里的.kjb和.ktr文件通过 URL 参数传入路径来执行。这带来一个硬性要求所有 Carte 节点上的任务文件路径必须一致否则同一个任务分发给不同节点会有一半节点报文件不存在。常见做法是建立一个固定基目录比如/data/kettle/jobs和/data/kettle/trans所有任务文件按“系统名/任务名/版本号”存放。管理端通过 SFTP 或对象存储把 Spoon 调好的文件推送到各节点再把路径登记到数据库。发布完成后用ls -l确认文件权限和校验和这一步别省跑批脚本最常见的故障不是逻辑错而是文件没同步到位。# 发布 job 到目标节点01 是版本号 scp order_daily_sync.kjb kettle192.168.10.21:/data/kettle/jobs/order/01/Spoon 里保存的文件通常带着本地绝对路径发布前要检查里面的引用是否都是相对路径。比如一个 job 里引用了转换文件写成/Users/me/trans/order_transform.ktr肯定跑不起来要改成../trans/order_transform.ktr这种相对引用。如果任务依赖数据库连接、文件路径这类环境差异把这些配置抽到变量文件里用 Carte 的-param参数注入而不是写死在 job 里。3.2 Carte REST API 的最小调用组合Kettle 的 Carte 服务对外提供一组 REST 接口常见路径前缀是/kettle/。以 8.x/9.x 常见构建为参考启动一个 Job 的请求长这样# 启动 jobfile 参数指向节点本地路径 curl -u cluster:cluster \ http://192.168.10.21:8081/kettle/startJob?job/data/kettle/jobs/order/01/order_daily_sync.kjblevelBasic # 查询 job 执行状态 curl -u cluster:cluster \ http://192.168.10.21:8081/kettle/jobStatus?joborder_daily_sync-u cluster:cluster对应carte-config.xml里配置的用户名密码。startJob的job参数是节点上的完整文件路径level是日志级别常用Basic或Detailed生产推荐Basic否则日志量会非常大。jobStatus的job参数填的不是路径而是 Job 名称也就是.kjb文件内部配置的 job 名字和文件名可能不一样这一点很多人栽过跟头。jobStatus返回内容在不同版本里格式差异较大旧版本返回 XML新版本可能返回 JSON 或者取决于请求头。建议在调用时统一加上Accept: application/json同时做好两种解析的兼容。返回里重点看几个字段statusRunning / Finished / Failed、executionStartDate、executionDuration、logText。状态轮询间隔不要小于 2 秒否则 Carte 忙于响应状态查询真正执行任务的能力反而被挤占。如果提交后一直查不到状态先确认 job 名字是否填对再看 Carte 的日志输出。REST 调用本身不报错不代表任务提交成功Carte 对不存在的 job 路径会返回一个 HTTP 200但内容里带着错误说明解析时不能只看状态码。3.3 Carte 注册机制让 master 聚合节点状态任务管理系统要管理多个 Carte 节点最直接的办法是把每个节点都配成 slave启动后向 master 注册。注册不是从管理端发起的而是 slave 节点启动时主动上报。在carte-config.xml里把master设为N然后在system段增加 master 地址system sleep_time5/sleep_time master_server nameetl-master/name hostname192.168.10.10/hostname port8080/port usernamecluster/username passwordcluster/password /master_server /system配置完成并重启 slave 后可以在 master 上查询已注册节点# 在 master 节点上查看注册过来的 slave 列表 curl -u cluster:cluster http://192.168.10.10:8080/kettle/slaves“Carte 注册”这个操作指的就是这一步。注册成功意味着 master 已经能感知 slave 的存在管理端只需要连 master 就能拿到全部节点状态。实际干活时管理端向 master 或某个 slave 提交任务都可以如果要做到“一个入口、多节点执行”就统一通过 master 分发。注意一点注册是单向的。slave 启动时上报一次之后靠心跳维持。如果 slave 宕机master 不会主动把它从列表里立刻移除而是等若干次心跳超时后才标记不可用。管理端在展示节点状态时要以自己发出的 HTTP 探活结果为准不能完全依赖 master 的节点列表否则会出现“界面显示在线、实际执行超时”的假象。4. Kettle Carte 任务管理系统的调度、心跳与并发控制4.1 调度器只解决一个核心问题现在该不该跑Kettle 本身不带可靠的分布式调度器Carte 不负责定时任务管理系统里的调度模块要自己写。最小可行的方案是一张任务表加一个轮询进程调度器每隔一段时间扫描任务表找到“到达执行时间且状态为 pending”的记录把状态改成 running再调用 Carte 的 REST 接口提交任务。以 MySQL 为例任务表设计如下字段类型用途task_idvarchar(64)唯一标识如 order_daily_syncjob_namevarchar(128)Carte 中 job 的名称查询状态时用job_pathvarchar(512)节点本地文件路径node_groupvarchar(64)归属节点组控制分发范围cron_exprvarchar(32)调度表达式如 0 0 2 * * ?statusvarchar(16)pending / running / success / failedlast_success_timedatetime上次执行成功时间用于重试判断timeout_minutesint超时阈值超过则判定失败retry_countint已重试次数调度轮询最核心的一个动作先把任务标记为 running再提交给 Carte。这一步能避免多个调度进程同时取到同一个任务造成重复执行。哪怕只有一个调度进程也建议先更新状态再调用接口养成习惯。# 伪代码轮询任务表达到时间后提交给 Carte while true; do task_id$(mysql -N -e select task_id from task_schedule where statuspending and cron_exprNOW limit 1;) if [ -n $task_id ]; then mysql -e update task_schedule set statusrunning where task_id$task_id; curl -s -u cluster:cluster \ http://192.168.10.21:8081/kettle/startJob?job/data/kettle/jobs/${task_id}.kjblevelBasic fi sleep 5 doneNOW表示由管理系统直接下发不走 cron 解析适合手工触发或上游依赖完成后的连续跑批。实际项目里cron 解析可以做成单独的模块把0 0 2 * * ?转成最近一个触发时间再和当前时间比较。触发窗口设 60 秒避免轮询周期和触发时刻错开导致漏跑。4.2 并发控制Carte 的瓶颈不在线程池在共享资源Carte 一个节点上可以同时运行多个 job 和转换没有硬性的并行数限制瓶颈来自外部资源。最典型的就是文件型任务几个 job 同时往同一个 CSV 或 Excel 文件追加数据轻则数据错乱重则文件句柄冲突直接报错。很多团队早期用“两个数据表合并输出一个 CSV”这类任务时调度时间重叠某一天文件里多了一半重复数据就是因为并发写同一个输出文件。常见的并发控制策略是按文件维度加锁而不是按节点加锁。两张表合并输出到一个 CSV 的任务调度时间必须错开或者在任务表里加一个output_file字段调度器发现两个待执行任务的输出文件相同就排队执行而不是同时提交。数据库型任务的坑更隐蔽Kettle 的“表输出”步骤默认不检查目标表唯一性。如果任务失败后重试而源端查询每次都全量捞数据目标表有主键就报主键冲突没主键就直接翻倍写入。“匹配多行输出单行”这类逻辑最容易在这里出问题——查询写错了匹配条件一行源数据匹配出多行结果重试几次后目标表数据量直接失控。所以涉及目标表写入的任务重试前先核对这次要写入的行数和上一次成功时的行数差异超过预期就停住等人处理。另一条建议把 Carte 节点按任务类型分组。写数据库的任务和写文件的任务不要混在同一个节点组里避免文件型任务的 IO 波动拉低数据库型任务的执行速度。节点的并发上限可以粗略按“一个任务平均占用 512MB 堆内存、节点总堆 4G”来估算留出 20% 余量给 Carte 自身的状态上报。4.3 心跳与超时把“节点慢了”和“任务挂了”分开判任务管理系统的告警最怕把“慢任务”误报成“节点故障”。Carte 提供了一组状态接口可以区分这两种情况。# 获取节点当前空闲时间秒 curl -u cluster:cluster http://192.168.10.21:8081/kettle/getIdleTime # 获取节点整体状态包含内存使用和运行中任务数 curl -u cluster:cluster http://192.168.10.21:8081/kettle/statusgetIdleTime返回的是节点空闲了多少秒。空闲时间短说明有任务在跑正常空闲时间持续很久但任务状态还显示 running就说明任务卡住了。心跳探活只负责回答“进程活着吗”真正的任务健康检查要看最细粒度任务的最后心跳时间。超时判定建议做成两层。第一层是节点探活每 30 秒请求一次status连续 3 次失败标记节点不可用不再向该节点分发新任务。第二层是任务超时任务表里记录start_time超过timeout_minutes还没有进入 finished 状态先不急着 kill而是调一次jobStatus看执行进度确认卡死后调 Carte 的removeJob或stopJob清理。重试逻辑要设计成幂等而不是简单重放。Kettle 的表输入“从一个表读数据同步到另一个表”重跑一次和重跑十次目标表应该一样才说明同步逻辑没问题。实现方式是每次抽取前记录源表最大 ID 或时间戳重试时只拉取大于该位置的增量数据。做不到增量同步的任务宁可失败告警人工介入也不要无限重试把目标表写乱。5. 验证与进阶一分钟看清 Carte 节点的任务状态任务系统跑起来后第一个要验证的不是执行成功率而是“节点状态能否被稳定观测”。Carte 自带的状态页能看但不可能每次登录浏览器去刷新。用两条命令组合可以快速拿到节点上所有任务的可读快照。# 查看节点上所有 job 的运行状态 curl -s -u cluster:cluster \ http://192.168.10.21:8081/kettle/jobStatus?job* | jq .jobStatusList[] | {jobName, status, executionDuration} # 查看节点空闲秒数判断是否已被任务占满 curl -s -u cluster:cluster \ http://192.168.10.21:8081/kettle/getIdleTime | jq .idleTimejob*是通配查询返回节点上所有历史 job 记录的最终状态适合巡检配合jq过滤后只看 job 名、状态和执行时长。如果执行时长一直在涨状态却始终是 Running就要对照getIdleTime看到底是卡死还是在处理大数据量idleTime在涨说明任务已经停止消费数据属于假死idleTime不涨说明还在跑只是慢。进阶一点的验证方法是让 Carte 主动暴露性能数据。Kettle 支持通过 JMX 暴露 JVM 指标在set-env.sh里加上远程 JMX 参数然后用jstat -gcutil pid观察 GC 频率。节点频繁 Full GC 时任务状态看起来是 RunninggetIdleTime也在涨但实际已经停滞这类问题只有靠 GC 指标才能定位。把这两条 curl 命令接入巡检脚本设置阈值idleTime超过任务超时时间且状态非 Finished自动触发一次jobStatus详细日志抓取连同堆内存快照一起落到日志目录。这套组合比单纯的心跳探活可靠得多——心跳只能回答“进程在不在”这套能回答“任务到底在干什么”。本文还有配套的精品资源点击获取
简介这是一份基于Kettle Carte服务开发的ETL任务管理系统源码面向Java开发人员、ETL工程师以及信息化管理方向学习者重点解决Kettle作业/转换的远程管控、任务并发调度与分布式执行问题。压缩包共82个文件整体约220KB以41个Java源文件为核心搭配5个XML、5个Properties、3个YML等配置文件同时包含HTML、JavaScript前端页面以及Maven相关构建脚本zbak备份文件保留了不同阶段代码便于对照排错。系统后端采用Java实现、前端使用HTML5/CSS3/JavaScript构建界面涉及Carte RESTful API集成、任务优先级控制、执行状态监控、并发与分布式管理等关键设计并附有项目模块划分与依赖配置适合作为课程设计或企业级ETL任务管理二次开发的参考资料。资源已有80人学习浏览内容来源于网络分享仅供学习交流使用请遵守版权规范。1. Kettle Carte 不是调度中心先把它当分布式执行器多数团队把 Kettle 用成了单机工具在 Spoon 里调好转换设个 Windows 计划任务能跑就算交付。可一旦任务数量超过二十个节点换机器、任务重跑、状态查看就全乱了。这套系统里最难的部分反而在 Kettle 之外。Carte 是 Kettle 自带的轻量级 Web 服务能远程接收作业Job和转换Transformation的执行请求。它没有内置调度器不负责“几点跑”只负责“把活接到并跑完”。所谓基于 Kettle Carte 的任务管理系统就是把 Carte 部署到一个或多个节点上由一套独立的管理端负责任务登记、节点注册、心跳检测和并发控制。适合已经在用 Kettle 做数据同步、报表抽取想从“每台机器各自跑”升级成“集中调度、分布执行”的团队。2. Carte 节点部署与配置参数先把执行器立起来2.1 kettle 安装包里的 Carte 启动方式从官网下载的 Kettle 安装包解压后直接可用里面自带 Carte 的启动脚本。Linux 下是carte.shWindows 下是carte.bat位置在安装包的根目录和 Spoon 同级。不需要额外编译也不需要装独立服务一个解压目录就是一个可运行的节点。# Linux 启动 Carte第一个参数是绑定地址第二个是端口 ./carte.sh 0.0.0.0 80810.0.0.0表示监听所有网卡接口这样管理端和其他 Carte 节点才能远程访问如果只写127.0.0.1那这个 Carte 就只能本机自己调用注册到 master 时也大概率失败。端口随意避免和现有服务冲突即可常见的是 8081。Windows 下双击carte.bat会弹出控制台窗口生产环境建议注册成服务或者用nssm托管避免窗口被误关导致任务中断。启动完后浏览器访问http://节点IP:8081能看到 Carte 自带的网页状态页说明服务已经起来了。确认端口正常监听后再进入下一步配置。2.2 用 carte-config.xml 定义节点角色与端口Carte 不配置也能启动但只有一个默认角色适合单节点跑。要组建真正意义上的任务管理系统每个节点都要明确身份这个节点是主节点还是从节点注册到谁用什么账号认证。这些写在 Kettle 安装目录下的carte-config.xml里以 8.x/9.x 常见模板为参考字段随版本略有差异?xml version1.0 encodingUTF-8? slave_config slave nameetl-node-01/name hostname192.168.10.21/hostname port8081/port usernamecluster/username passwordcluster/password masterN/master ssl_modeN/ssl_mode /slave repository nameetl-repo/name /repository system sleep_time5/sleep_time /system /slave_config这个配置里最关键的是master和username/password。master取Y时当前节点作为主节点其他节点启动后会向它注册取N时作为从节点负责实际执行任务。用户名密码默认是cluster/cluster管理端调用 Carte 的 REST 接口时要用同一套凭据做 Basic Auth生产环境一定要改掉。下面是几个必须调的参数参数作用建议值name节点在集群中的唯一标识注册后靠它区分带环境前缀如prod-node-01hostname对外可达的地址从节点注册时用写内网 IP别写 localhostportCarte HTTP 服务端口与启动命令第二个参数保持一致master是否作为主节点一个集群只设一个 Yusername/password调用接口的认证凭据不用默认值改成强密码sleep_time节点与 master 之间的心跳间隔秒数5 左右即可过小徒增请求量同一条机器上可以跑多个 Carte 实例端口不同就行。但要注意多个实例共享同一份 Kettle 安装目录时临时文件目录和日志目录会互相干扰。稳妥做法是每个实例单独复制一份解压目录路径隔离排查问题时也更干净。2.3 堆内存与字符集影响长任务的两个启动参数Kettle 启动脚本默认的堆内存不算大跑短任务没问题但 Carte 作为常驻服务会被持续提交任务堆设置不合理时跑上几天就会出现内存溢出表现还很隐蔽错误信息可能指向数据库连接超时实际是 GC 频繁导致响应变慢。打开carte.sh或同目录下的set-env.sh找到 JVM 参数区# 调整堆内存与编码放在 JVM 参数区 PENTAHO_DI_JAVA_OPTIONS-Xms1024m -Xmx4096m -Dfile.encodingUTF-8 -Djava.awt.headlesstrue # 导出后启动 export PENTAHO_DI_JAVA_OPTIONS ./carte.sh 0.0.0.0 8081-Xms和-Xmx分别控制初始堆和最大堆。Carte 节点上同时跑的转换越多需要的堆越大建议至少-Xms1024m -Xmx2048m如果单节点并发五六个转换直接给到 4G。-Dfile.encodingUTF-8强烈建议加上否则 CSV 输出、表输入的中文字段会出现乱码而且这类问题在开发环境复现不出来只有到了生产数据量下才暴露。之前遇到过一次管理端连续提交 12 个转换后第三个开始全部报“无法获取数据库连接”。当时怀疑是连接池满了查下来其实是 Carte 进程堆内存不足频繁 Full GC数据库连接的等待时间被拖到了超时阈值以上。所以 Carte 节点的内存监控一定要前置不能等告警。3. Carte 任务发布与远程调用怎样让 job 真正跑起来3.1 先统一发布路径再谈远程调用Carte 执行的是本地文件系统里的.kjb和.ktr文件通过 URL 参数传入路径来执行。这带来一个硬性要求所有 Carte 节点上的任务文件路径必须一致否则同一个任务分发给不同节点会有一半节点报文件不存在。常见做法是建立一个固定基目录比如/data/kettle/jobs和/data/kettle/trans所有任务文件按“系统名/任务名/版本号”存放。管理端通过 SFTP 或对象存储把 Spoon 调好的文件推送到各节点再把路径登记到数据库。发布完成后用ls -l确认文件权限和校验和这一步别省跑批脚本最常见的故障不是逻辑错而是文件没同步到位。# 发布 job 到目标节点01 是版本号 scp order_daily_sync.kjb kettle192.168.10.21:/data/kettle/jobs/order/01/Spoon 里保存的文件通常带着本地绝对路径发布前要检查里面的引用是否都是相对路径。比如一个 job 里引用了转换文件写成/Users/me/trans/order_transform.ktr肯定跑不起来要改成../trans/order_transform.ktr这种相对引用。如果任务依赖数据库连接、文件路径这类环境差异把这些配置抽到变量文件里用 Carte 的-param参数注入而不是写死在 job 里。3.2 Carte REST API 的最小调用组合Kettle 的 Carte 服务对外提供一组 REST 接口常见路径前缀是/kettle/。以 8.x/9.x 常见构建为参考启动一个 Job 的请求长这样# 启动 jobfile 参数指向节点本地路径 curl -u cluster:cluster \ http://192.168.10.21:8081/kettle/startJob?job/data/kettle/jobs/order/01/order_daily_sync.kjblevelBasic # 查询 job 执行状态 curl -u cluster:cluster \ http://192.168.10.21:8081/kettle/jobStatus?joborder_daily_sync-u cluster:cluster对应carte-config.xml里配置的用户名密码。startJob的job参数是节点上的完整文件路径level是日志级别常用Basic或Detailed生产推荐Basic否则日志量会非常大。jobStatus的job参数填的不是路径而是 Job 名称也就是.kjb文件内部配置的 job 名字和文件名可能不一样这一点很多人栽过跟头。jobStatus返回内容在不同版本里格式差异较大旧版本返回 XML新版本可能返回 JSON 或者取决于请求头。建议在调用时统一加上Accept: application/json同时做好两种解析的兼容。返回里重点看几个字段statusRunning / Finished / Failed、executionStartDate、executionDuration、logText。状态轮询间隔不要小于 2 秒否则 Carte 忙于响应状态查询真正执行任务的能力反而被挤占。如果提交后一直查不到状态先确认 job 名字是否填对再看 Carte 的日志输出。REST 调用本身不报错不代表任务提交成功Carte 对不存在的 job 路径会返回一个 HTTP 200但内容里带着错误说明解析时不能只看状态码。3.3 Carte 注册机制让 master 聚合节点状态任务管理系统要管理多个 Carte 节点最直接的办法是把每个节点都配成 slave启动后向 master 注册。注册不是从管理端发起的而是 slave 节点启动时主动上报。在carte-config.xml里把master设为N然后在system段增加 master 地址system sleep_time5/sleep_time master_server nameetl-master/name hostname192.168.10.10/hostname port8080/port usernamecluster/username passwordcluster/password /master_server /system配置完成并重启 slave 后可以在 master 上查询已注册节点# 在 master 节点上查看注册过来的 slave 列表 curl -u cluster:cluster http://192.168.10.10:8080/kettle/slaves“Carte 注册”这个操作指的就是这一步。注册成功意味着 master 已经能感知 slave 的存在管理端只需要连 master 就能拿到全部节点状态。实际干活时管理端向 master 或某个 slave 提交任务都可以如果要做到“一个入口、多节点执行”就统一通过 master 分发。注意一点注册是单向的。slave 启动时上报一次之后靠心跳维持。如果 slave 宕机master 不会主动把它从列表里立刻移除而是等若干次心跳超时后才标记不可用。管理端在展示节点状态时要以自己发出的 HTTP 探活结果为准不能完全依赖 master 的节点列表否则会出现“界面显示在线、实际执行超时”的假象。4. Kettle Carte 任务管理系统的调度、心跳与并发控制4.1 调度器只解决一个核心问题现在该不该跑Kettle 本身不带可靠的分布式调度器Carte 不负责定时任务管理系统里的调度模块要自己写。最小可行的方案是一张任务表加一个轮询进程调度器每隔一段时间扫描任务表找到“到达执行时间且状态为 pending”的记录把状态改成 running再调用 Carte 的 REST 接口提交任务。以 MySQL 为例任务表设计如下字段类型用途task_idvarchar(64)唯一标识如 order_daily_syncjob_namevarchar(128)Carte 中 job 的名称查询状态时用job_pathvarchar(512)节点本地文件路径node_groupvarchar(64)归属节点组控制分发范围cron_exprvarchar(32)调度表达式如 0 0 2 * * ?statusvarchar(16)pending / running / success / failedlast_success_timedatetime上次执行成功时间用于重试判断timeout_minutesint超时阈值超过则判定失败retry_countint已重试次数调度轮询最核心的一个动作先把任务标记为 running再提交给 Carte。这一步能避免多个调度进程同时取到同一个任务造成重复执行。哪怕只有一个调度进程也建议先更新状态再调用接口养成习惯。# 伪代码轮询任务表达到时间后提交给 Carte while true; do task_id$(mysql -N -e select task_id from task_schedule where statuspending and cron_exprNOW limit 1;) if [ -n $task_id ]; then mysql -e update task_schedule set statusrunning where task_id$task_id; curl -s -u cluster:cluster \ http://192.168.10.21:8081/kettle/startJob?job/data/kettle/jobs/${task_id}.kjblevelBasic fi sleep 5 doneNOW表示由管理系统直接下发不走 cron 解析适合手工触发或上游依赖完成后的连续跑批。实际项目里cron 解析可以做成单独的模块把0 0 2 * * ?转成最近一个触发时间再和当前时间比较。触发窗口设 60 秒避免轮询周期和触发时刻错开导致漏跑。4.2 并发控制Carte 的瓶颈不在线程池在共享资源Carte 一个节点上可以同时运行多个 job 和转换没有硬性的并行数限制瓶颈来自外部资源。最典型的就是文件型任务几个 job 同时往同一个 CSV 或 Excel 文件追加数据轻则数据错乱重则文件句柄冲突直接报错。很多团队早期用“两个数据表合并输出一个 CSV”这类任务时调度时间重叠某一天文件里多了一半重复数据就是因为并发写同一个输出文件。常见的并发控制策略是按文件维度加锁而不是按节点加锁。两张表合并输出到一个 CSV 的任务调度时间必须错开或者在任务表里加一个output_file字段调度器发现两个待执行任务的输出文件相同就排队执行而不是同时提交。数据库型任务的坑更隐蔽Kettle 的“表输出”步骤默认不检查目标表唯一性。如果任务失败后重试而源端查询每次都全量捞数据目标表有主键就报主键冲突没主键就直接翻倍写入。“匹配多行输出单行”这类逻辑最容易在这里出问题——查询写错了匹配条件一行源数据匹配出多行结果重试几次后目标表数据量直接失控。所以涉及目标表写入的任务重试前先核对这次要写入的行数和上一次成功时的行数差异超过预期就停住等人处理。另一条建议把 Carte 节点按任务类型分组。写数据库的任务和写文件的任务不要混在同一个节点组里避免文件型任务的 IO 波动拉低数据库型任务的执行速度。节点的并发上限可以粗略按“一个任务平均占用 512MB 堆内存、节点总堆 4G”来估算留出 20% 余量给 Carte 自身的状态上报。4.3 心跳与超时把“节点慢了”和“任务挂了”分开判任务管理系统的告警最怕把“慢任务”误报成“节点故障”。Carte 提供了一组状态接口可以区分这两种情况。# 获取节点当前空闲时间秒 curl -u cluster:cluster http://192.168.10.21:8081/kettle/getIdleTime # 获取节点整体状态包含内存使用和运行中任务数 curl -u cluster:cluster http://192.168.10.21:8081/kettle/statusgetIdleTime返回的是节点空闲了多少秒。空闲时间短说明有任务在跑正常空闲时间持续很久但任务状态还显示 running就说明任务卡住了。心跳探活只负责回答“进程活着吗”真正的任务健康检查要看最细粒度任务的最后心跳时间。超时判定建议做成两层。第一层是节点探活每 30 秒请求一次status连续 3 次失败标记节点不可用不再向该节点分发新任务。第二层是任务超时任务表里记录start_time超过timeout_minutes还没有进入 finished 状态先不急着 kill而是调一次jobStatus看执行进度确认卡死后调 Carte 的removeJob或stopJob清理。重试逻辑要设计成幂等而不是简单重放。Kettle 的表输入“从一个表读数据同步到另一个表”重跑一次和重跑十次目标表应该一样才说明同步逻辑没问题。实现方式是每次抽取前记录源表最大 ID 或时间戳重试时只拉取大于该位置的增量数据。做不到增量同步的任务宁可失败告警人工介入也不要无限重试把目标表写乱。5. 验证与进阶一分钟看清 Carte 节点的任务状态任务系统跑起来后第一个要验证的不是执行成功率而是“节点状态能否被稳定观测”。Carte 自带的状态页能看但不可能每次登录浏览器去刷新。用两条命令组合可以快速拿到节点上所有任务的可读快照。# 查看节点上所有 job 的运行状态 curl -s -u cluster:cluster \ http://192.168.10.21:8081/kettle/jobStatus?job* | jq .jobStatusList[] | {jobName, status, executionDuration} # 查看节点空闲秒数判断是否已被任务占满 curl -s -u cluster:cluster \ http://192.168.10.21:8081/kettle/getIdleTime | jq .idleTimejob*是通配查询返回节点上所有历史 job 记录的最终状态适合巡检配合jq过滤后只看 job 名、状态和执行时长。如果执行时长一直在涨状态却始终是 Running就要对照getIdleTime看到底是卡死还是在处理大数据量idleTime在涨说明任务已经停止消费数据属于假死idleTime不涨说明还在跑只是慢。进阶一点的验证方法是让 Carte 主动暴露性能数据。Kettle 支持通过 JMX 暴露 JVM 指标在set-env.sh里加上远程 JMX 参数然后用jstat -gcutil pid观察 GC 频率。节点频繁 Full GC 时任务状态看起来是 RunninggetIdleTime也在涨但实际已经停滞这类问题只有靠 GC 指标才能定位。把这两条 curl 命令接入巡检脚本设置阈值idleTime超过任务超时时间且状态非 Finished自动触发一次jobStatus详细日志抓取连同堆内存快照一起落到日志目录。这套组合比单纯的心跳探活可靠得多——心跳只能回答“进程在不在”这套能回答“任务到底在干什么”。本文还有配套的精品资源点击获取
