简介：Kettle 9.4 即 Pentaho Data Integration 9.4,是一款应用广泛的开源 ETL 工具,面向数据集成、数据仓库建设与日常数据清洗场景,常用于企业数据平台建设,适合需要可视化开发数据流程的开发者和数据分析人员使用。压缩包共 1082 个文件,大小约 358MB,其中以 630 个 jar 核心类库、196 个 ktr 转换文件、19 个 kjb 作业文件为主体,另含 xml、properties、sql 等配置文件和 bat、sh 启动脚本,以及 xul、svg、png 等界面资源,目录结构完整,可支撑本地部署与二次开发。已有 7620 人学习或下载,资源内包含 9.4 社区版的完整程序主体与常用启动脚本,便于快速进入图形化开发环境,对初次接触 PDI 的开发者尤其友好。对于需要构建和调试数据抽取、转换、加载流程的读者,可以借助资源中的转换与作业示例,理解 ETL 工程的组织方式,并参考文件分类快速定位核心类库或配置项,解决实际开发中的问题。目录对启动脚本、示例文件与界面资源做了区分,便于按需查找和使用。
1. 还在用 Kettle 9.4 做数据同步，到底图什么
在一家保险公司的数据仓库改造里，我负责把核心系统的几十张业务表按天搬到分析库。团队里没有专职写同步程序的 Java 岗，夜晚两小时的同步窗口又容不得我们临时去开发一套新的数据同步组件。Kettle 9.4 版本（Pentaho Data Integration 9.4，简称 PDI 9.4）就是在这种情况下被重新捡起来的：图形化拖拽排错、自带命令行执行器、社区版免费可用。它解决的是库到库、文件到库、接口到库这三类最常见的同步需求，适合表多、开发人力有限、又必须看得到每一步处理过程的团队。如果你正卡在“数据源太多、写代码太重、又不想被商业同步工具绑定”这个点上，PDI 9.4 是一个值得认真评估的方向。
2. 部署 PDI 9.4：从 JDK 选择到启动脚本的边界条件
2.1 JDK 11 是硬门槛：为什么 PDI 9.4 只认这一代 Java
Kettle 9.4 的代码是基于 Java 11 编译的，这不是一个可以跳过的建议，而是启动之前的硬前提。用 JDK 8 去跑，Spoon 窗口会在启动阶段直接报UnsupportedClassVersionError，日志里会看到org/pentaho相关的类版本号不匹配；用太高版本的 JDK 又会遇到 Java 模块系统的访问限制，典型报错是InaccessibleObjectException，原因是 Kettle 内置的若干库还在用反射访问 JDK 内部包。某开发者图省事装了机器上现成的 JDK 17，结果每次新建转换都报反射告警，折腾一晚上后换回 11 就好了。
部署前先确认当前默认 Java 指向哪里，再决定要不要改JAVA_HOME：
java -version echo "JAVA_HOME=$JAVA_HOME"如果第一行输出的版本号不是11.0.x，或者JAVA_HOME没有指向 JDK 11 的安装目录，后面启动 PDI 9.4 大概率翻车。常见做法是在/etc/profile或~/.bashrc里显式声明：
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk export PATH=$JAVA_HOME/bin:$PATH注意：JAVA_HOME必须指到 JDK 的根目录，而不是bin目录。验证方式是在终端里重新source ~/.bashrc，再用echo $JAVA_HOME检查。生产服务器上如果同时装了多个业务系统，各自对 JDK 版本要求不同，就不要去动/etc/profile这种全局文件，而是把 JDK 11 的路径写进 PDI 的独立启动脚本里，避免影响其他应用。
2.2 下载解压与目录结构：三个容易忽略的确认项
PDI 9.4 的社区版以压缩包形式提供，解压后就是一个名为>mkdir -p /opt/pdi tar -zxvf pdi-ce-9.4.0.0-343.zip -C /opt/pdi chown -R etluser:etluser /opt/pdi
第一行创建安装根目录，第二行解压，第三行把文件属主改成专门跑任务的etluser账号。第三行很容易被省略，但很关键：用 root 解压后，普通账号运行 Spoon 会碰到配置目录.kettle无法写入的问题，表现为“保存转换失败”或“插件加载报错”。
解压后的目录结构要心里有数：
data-integration/ ├── spoon.sh # 图形界面，开发调试用 ├── kitchen.sh # 作业执行器，跑 kjb ├── pan.sh # 转换执行器，跑 ktr ├── lib/ # 数据库驱动等通用依赖 ├── plugins/ # 各类型步骤插件 └── system/ # 全局配置文件模板生产环境里用得最多的是kitchen.sh和pan.sh，spoon.sh更多是在开发机上做转换设计。插件加载失败时，先看plugins目录权限是否被改动过；驱动找不到时，先看lib目录下有没有对应 jar 包。这两个目录是排错时的第一站。
2.3 堆内存与三个启动脚本的分工：开发机和服务器要分开配
PDI 9.4 提供了三个启动入口，很多人第一次接触时搞不清它们的区别：spoon.sh打开图形界面，pan.sh执行单个转换文件（.ktr），kitchen.sh执行作业文件（.kjb）。转换负责数据流处理，作业负责流程编排和调度，所以生产环境定时任务走的是kitchen.sh。
内存参数默认值是编辑器的 Java 堆设置，直接改系统环境变量没用，要改各启动脚本里的OPT字段。服务器上跑同步任务时，一般把初始堆和最大堆设为相同值，避免 JVM 动态扩容带来的停顿。下面是一个修改后的配置片段，以kitchen.sh为例：
OPT="-Xms1024m -Xmx3072m -Dfile.encoding=UTF-8 -Djava.awt.headless=true"-Xms是初始堆大小，-Xmx是最大堆大小，-Dfile.encoding=UTF-8解决中文乱码问题，-Djava.awt.headless=true表示在没有显示器的服务器上运行时不尝试初始化图形环境。如果日志里出现GC overhead limit exceeded，优先看物理机内存够不够，而不是一味把-Xmx往上调，堆给得比物理内存还大只会让系统频繁换页，同步速度反而更慢。
3. 用 Spoon 跑通第一个转换：从表输入到表输出的完整路径
3.1 最小转换的五个动作与数据流模型
Kettle 的转换设计遵循管道模型，数据从“步骤”流向“步骤”，每个步骤只做一件事：读取、转换、写入。以最常见的库到库同步为例，最小转换只需要两个步骤：一个“表输入”负责从源库读数据，一个“表输出”负责写到目标库。Spoon 界面里从左侧面板拖出这两个步骤，用鼠标连线建立 Hop（数据流通道），然后配置数据库连接和 SQL，就能跑通一个完整的数据流。
第一次操作按五步走：新建转换 → 添加“表输入”步骤 → 添加“表输出”步骤 → 绘制 Hop → 点击运行。表输入里的 SQL 是最容易出错的点，Kettle 不是数据库客户端，它不会帮你纠错，如果源库字段名带中文或大小写混用，最好把 SQL 先在数据库客户端里跑一遍再粘进来。一个典型示例：
SELECT order_id, user_id, amount, update_time FROM trade_order WHERE update_time >= DATE_SUB(NOW(), INTERVAL 1 DAY)这个 SQL 查的是近一天的新增订单。注意同一条语句里不要带分号结尾，Kettle 对分号的处理在部分数据库类型上会报语法错误。表输出步骤要配置目标表名和批量写入参数，其中“提交记录数量”默认是 1000，意思是攒够 1000 行一次性提交，值设得太小写入慢，设得太大内存占用高，一般 1000 到 5000 是一个比较稳的区间。
3.2 连接配置里的三个坑：驱动、URL 参数和连接池
数据库连接配置是 PDI 9.4 里最见基本功的地方。MySQL 8 的驱动类名是com.mysql.cj.jdbc.Driver，如果随手选了老版本驱动com.mysql.jdbc.Driver，连接时容易报 SSL 相关错误。驱动 jar 包要放到>jdbc:mysql://10.20.31.8:3306/ods_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true
useUnicode=true和characterEncoding=utf8解决中文写入乱码；serverTimezone=Asia/Shanghai解决 JDBC 驱动与数据库时区不一致导致的时间戳偏移；allowPublicKeyRetrieval=true是在 MySQL 8 默认认证插件下避免“Public Key Retrieval is not allowed”报错的关键参数。Oracle 和 SQL Server 的驱动同样放到lib目录，Oracle 的 URL 形如jdbc:oracle:thin:@host:1521:orcl，SQL Server 用jdbc:sqlserver://host:1433;DatabaseName=xxx。
连接池大小建议控制在 5 到 10 之间。很多开发者以为并发连接开得越大同步越快，实际上源库的并发连接数、CPU 和磁盘 IO 都有限制，连接池设成 30 反而可能把源库压出告警。对绝大多数日常同步场景，一个转换里同时跑 3 到 5 个并发连接已经够用了。
3.3 用 Pan 在命令行跑转换：调试日志的正确姿势
图形界面里点“运行”能跑通，只是第一关。生产上要保证脚本可控、日志可查、退出码可判断，所以必须确认转换能用pan.sh在命令行跑通。命令行执行的好处是绕开 GUI 的干扰，直接看标准输出日志。
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk export PATH=$JAVA_HOME/bin:$PATH ./pan.sh -file=/opt/pdi/ktr/order_daily_sync.ktr \ -level=Detailed \ -param:start_time=2024-11-01 \ -param:end_time=2024-11-02-file指向待执行的转换文件，-level控制日志详细程度，-param传递自定义变量。-level的取值从Error到Rowlevel，Basic是默认级别，适合确认整体流程；Detailed会打印每一步读写的行数和耗时，是排查性能问题的首选；Rowlevel会把每一行数据都打印出来，日志量巨大，只有调试字段映射时才建议用。转换里的 SQL 可以用${start_time}这种占位符引用参数，启动命令传入的-param会自动绑定进去。
4. 生产级同步作业设计：增量抽取、定时调度与失败退出码
4.1 转换（ktr）和作业（kjb）的分工
一个常见的误解是：同步任务就是一个大转换，从源头读到目标写完事。实际生产上，转换只负责“数据怎么流”，作业负责“任务怎么编排”。作业里可以放开始控件、转换步骤、SQL 脚本步骤、条件分支，甚至可以发告警邮件。典型的夜间同步作业结构是：开始 → 读取上次水位 → 执行同步转换 → 更新水位 → 检查日志行数 → 失败则告警。
这种拆分的价值在于容错。转换是数据管道，中间断了就要从头跑；而作业可以在每一步之间增加检查点。例如在同步转换之前先执行一段 SQL，确认目标表的临时分区存在，再决定是直接写入还是先清空临时区。把控制逻辑放在作业层、把数据逻辑放在转换层，后续排错只需看日志里停在哪个作业步骤，不用去翻一大段数据流日志找问题。
4.2 增量抽取的标准做法：时间戳水位表
全量同步简单，但大多数业务表的数据量撑不住每天全量拉一遍，所以增量同步是生产刚需。最稳妥的时间戳增量方案需要一张水位表，记录每个任务上次同步到的位置。设计上不需要复杂，一张两三个字段的表就够了：
CREATE TABLE sync_watermark ( task_name VARCHAR(64) PRIMARY KEY, last_value DATETIME, updated_at DATETIME );task_name标识任务，last_value是上次增量截止时间，updated_at是本次更新时刻。作业第一步用“表输入”或“SQL 脚本”步骤把last_value读出来，通过变量传给同步转换；同步转换里的表输入 SQL 写成范围查询：
SELECT order_id, user_id, amount, update_time FROM trade_order WHERE update_time >= '${start_time}' AND update_time < '${end_time}'start_time来自水位表，end_time用当前时间。这里用左闭右开的区间，是为了避免同一秒内的数据在前后两次任务之间被重复覆盖。同步完成、确认数据落库后，作业里的更新语句再把这个任务的last_value往前推。水位推进的动作必须放在同步转换成功之后，绝不能放在之前，否则任务中途失败，重跑会漏数据。
这个方案有两个天然边界：源表有物理删除操作时，时间戳增量发现不了被删的行；源表的时间戳字段没有索引时，范围查询会全表扫描，数据量大后性能急剧下降。遇到这两种情况，要么改成全量比对加更新，要么引入基于日志的变更捕获方案，时间戳水位只适合“只追加、逻辑删除、时间戳有索引”的表。
4.3 用 Kitchen 接进 crontab：定时调度与失败告警
作业文件通过kitchen.sh执行。由于 crontab 里的环境变量默认只保留了最精简的 PATH，直接在 cron 行里调kitchen.sh经常会遇到java: command not found。我习惯写一个包装脚本，把 JDK 路径、日志目录和退出码判断统一处理：
#!/bin/bash export JAVA_HOME=/usr/lib/jvm/java-11-openjdk export PATH=$JAVA_HOME/bin:$PATH STAMP=$(date +%Y%m%d%H%M) cd /opt/pdi/data-integration ./kitchen.sh -file=/opt/pdi/jobs/order_daily_sync.kjb \ -level=Detailed \ -logfile=/opt/pdi/logs/order_daily_sync_${STAMP}.log exit_code=$? if [ $exit_code -ne 0 ]; then /opt/pdi/bin/send_alert.sh "order_daily_sync failed" fi exit $exit_codelogfile参数让 Kitchen 把日志写到固定文件而不是终端，文件名带上时间戳，方便按天归档和检索。退出码是判断任务是否成功的唯一标准：0 表示成功，非 0 表示失败，这里的失败既包括转换执行异常，也包括作业里某个步骤报错中断。告警脚本收到非 0 退出码后发通知，比人肉看报表更及时。
最后在 crontab 里挂上任务：
30 1 * * * /opt/pdi/bin/run_order_daily_sync.sh >> /dev/null 2>&1这条配置表示每天凌晨 1:30 执行一次。注意>> /dev/null 2>&1会吞掉标准输出和错误输出，所以告警全靠脚本内部判断退出码，不能依赖 cron 的邮件通知。第一次挂 cron 的时候，建议先手动跑一遍包装脚本，确认JAVA_HOME在脚本环境里能正常解析，再放进 crontab，否则很容易出现“手动跑得好好的，定时跑必失败”的怪事。
5. PDI 9.4 避坑指南：启动、编码、内存和驱动的现场修复
5.1 现象：Spoon 刚启动就退，或者双击没反应
原因基本都指向 JDK 版本。PDI 9.4 必须跑在 Java 11 上，用 JDK 8 会在日志里看到UnsupportedClassVersionError，用 JDK 17 及以上会看到InaccessibleObjectException。这两类报错的解决方式完全不同：前者需要把JAVA_HOME指到 JDK 11；后者除了换 JDK 11，还要在启动脚本里补上 JVM 的--add-opens参数，但补参数属于绕路，不如直接换版本干净。我在排错时第一步永远是java -version和echo $JAVA_HOME，先把版本确认了再谈其他。
5.2 现象：界面中文全是方块，导出的 CSV 在 Excel 里打开乱码
原因出在 JVM 的文件编码不是 UTF-8。Kettle 内存中的字符串是 Unicode，但读取 CSV、写出 CSV 和显示界面文本时依赖file.encoding这个系统属性。Linux 服务器默认 locale 如果不是 UTF-8，Spoon 界面就会出现中文方块，CSV 写出也会变成乱码。解决方式是在三个启动脚本的OPT里都显式加上-Dfile.encoding=UTF-8，同时在系统环境变量里执行export LANG=zh_CN.UTF-8。只改一个脚本没用，因为spoon.sh、pan.sh、kitchen.sh各有各的 JVM 进程，改哪个入口就只对哪个入口生效。
5.3 现象：堆内存已经调到 4096m，跑大转换还是 OOM
原因很可能是改错了启动脚本。很多人只改了spoon.sh，但定时任务跑的是kitchen.sh，两个脚本的OPT参数互不相通。还有一种情况是“表输入”步骤一次性SELECT *把整张大表加载进行集缓存，Kettle 默认把行集放在堆内存里，1000 万行数据即便不算字段对象开销也会把堆撑爆。解决的思路不是继续加内存，而是改数据读取方式：在表输入 SQL 里手动分页，或者多个并行流各读一部分数据。另外检查一下表输出步骤的“提交记录数量”，提交频率太低也会导致事务长时间持有大量内存。
5.4 现象：MySQL 8 连接报 Public Key Retrieval is not allowed 或 SSL 连接错误
原因有两个：驱动类名选错，连接 URL 参数不完整。MySQL 8 默认认证插件要求客户端在连接时获取 RSA 公钥，URL 里需要显式加上allowPublicKeyRetrieval=true，同时把useSSL关闭或配置为有效证书，否则 JDBC 驱动会因为拿不到公钥直接中断连接。一个容易忽视的点：驱动 jar 包替换后必须重启整个 Kettle 进程，只保存配置不重启，classpath 里加载的还是老驱动。
5.5 现象：增量任务第二天跑出重复数据，主键冲突
原因大概率是水位更新逻辑放在了同步转换之前。作业一旦在中途失败，水位已经被更新到当前时间，重跑时源表里已经处理过的数据带不上来，或者反过来，水位没推进导致下一轮又从旧时间点捞了一遍。解决方式是调整作业结构：先执行同步转换，成功后再执行水位更新 SQL，两条路径用作业里的“成功”“失败”跳转串联。判断重复最稳妥的标准不是看日志，而是查目标表里的主键是否冲突，以及比对源表和目标表相近时间段内的行数。
6. 从 10 万到 1000 万行的提速验证：并行度、批量与日志
6.1 三个最有效的提速参数
数据量从十万级涨到千万级时，最先要调的不是并行度，而是批量读写。表输入侧在数据库连接配置里开“使用批量插入”，表输出侧把提交记录数从 1000 提到 5000；MySQL 的 JDBC URL 建议追加rewriteBatchedStatements=true&useServerPrepStmts=true，这两个参数能让驱动把多条插入语句重写成批量执行，写入吞吐量会有明显提升。之后才是并行度：在 Spoon 里右键步骤选择“改变开始复制数”，按源库 CPU 核数逐步往上加，从 2、4 到 8 试出拐点。
6.2 用日志验证吞吐量
调优没有玄学，一切以日志数据为准。跑完一个任务后，直接在日志文件里查两个关键标记：
grep -E "Lines output|Finished processing" /opt/pdi/logs/order_daily_sync_*.logLines output表示每个步骤输出的行数，用行数除以步骤耗时就能算出每秒吞吐量。注意对比不同参数下的同一任务耗时，而不是凭感觉判断“好像快了点”。有一回我把并行度调到 8，本地测试库看不出来问题，第二天源库告警被打满，才发现源库是单机小库，8 个连接直接击穿了它的连接上限。此后我养成了一个习惯：大任务先看源库的连接数上限和主键索引情况，再决定并行度；宁可让同步多跑十分钟，也不能因为同步把业务库压垮。希望帮到你。
本文还有配套的精品资源，点击获取
