简介Kettle 9.3pdi-ce-9.3.0.0-428分卷压缩包的第二部分面向需要快速搭建开源ETL环境的数据工程师与数据分析人员。工具基于Java开发绿色免安装压缩包内已集成JRE解压后双击spoon.bat即可运行适用于Windows、Linux、Unix等平台。包体共2000个文件以618个jar库文件、196个ktr转换脚本、19个kjb作业文件及xml、properties、bat/sh脚本等为主体涵盖Java依赖、ETL流程定义与启动配置压缩包整体约799.81MB。已有883人学习下载。该分卷与资源1合并后可得到完整可运行的Kettle环境配套丰富的示例转换与作业文件适合直接导入Spoon进行流程调试与改写也可作为学习Kettle组件、步骤与数据源连接的参考素材。1. 还在坚持用 Kettle 9.3这份老牌 ETL 工具到底能帮你省多少事如果你手头的数据抽取需求还停留在“每天把业务库的表同步到数仓、清洗完再落宽表”那 Kettle 9.3pdi-ce-9.3.0.0-428依然是个不用写代码就能扛住日常任务的工具箱。它全称是 Pentaho Data Integration 社区版Spoon 图形界面里拖几个步骤就能拼出一条数据流相比写 Python 脚本轮询数据库它把“连接管理、字段映射、增量同步、定时调度”这几件事固化成了可复用的工程化组件。对多数数据工程师来说9.3 是社区版里比较省心的一个版本八代界面还不算老插件生态完整JDK 8 或 11 都能稳稳跑起来不像更高版本那样对 Java 版本挑三拣四。这篇笔记我按自己的拆解顺序写先落地、再连接、后调试、最后调度你照着做就能把这份压缩包用顺手。2. 解压、JDK、内存Kettle 9.3 落地前的三项确认安装 Kettle 9.3 没有安装向导本质上就是把压缩包解压到本地目录然后让 Spoon 能找到正确的 Java 环境。很多人在这一阶段就卡住往往不是包坏了而是 JDK 版本不对、目录带空格、内存参数太小这三个问题。2.1 解压路径与目录结构别把># Windows 解压示例在压缩包所在目录执行 tar -xf pdi-ce-9.3.0.0-428.zip -C D:\etl\ cd D:\etl\data-integration dir Spoon.bat参数说明-C指定解压目标目录Kettle 对目录名有依赖解压后不要手工改>unzip pdi-ce-9.3.0.0-428.zip -d /opt/etl/ ls /opt/etl/data-integration/spoon.sh解压后重点确认两件事一是lib文件夹里有没有数据库驱动二是Spoon.bat文件能不能正常执行。不要直接双击.bat就把窗口关了建议从命令行启动窗口里会打印完整的启动日志报错时能看到具体是哪一步挂了。2.2 JDK 版本与 JAVA_HOME9.3 对 Java 8/11 的兼容边界Kettle 9.3 官方兼容 Java 8 和 Java 11我自己在实践中更倾向于 Java 8 的长期维护版因为社区里大多数插件和第三方驱动都在 8 上验证过。如果你本机已经装了 JDK 17Spoon 大概率会启动到一半退出或者能打开界面但连接数据库时抛UnsupportedClassVersionError。所以落地之前先把 JAVA_HOME 指到一个合规版本。# Windows 命令行临时设置 set JAVA_HOMEC:\Program Files\Java\jdk1.8.0_202 set PENTAHO_JAVA_HOME%JAVA_HOME% set PATH%JAVA_HOME%\bin;%PATH% cd D:\etl\data-integration Spoon.bat逻辑说明Kettle 启动脚本优先读取PENTAHO_JAVA_HOME如果这个变量不存在才去读JAVA_HOME。所以不想改动系统全局变量时在启动 Spoon 的同一命令行里临时设置这两个变量就够用。Linux 下是同样的思路export JAVA_HOME/usr/lib/jvm/java-8-openjdk-amd64 export PENTAHO_JAVA_HOME$JAVA_HOME cd /opt/etl/data-integration ./spoon.sh参数说明如果你机器上同时装有多个 JDK务必确认JAVA_HOME指向的是 JDK 目录本身而不是 JDK 下一级目录。Spoon 启动时会检查$JAVA_HOME\bin\java.exe是否存在指向错误会直接报Java could not be started。从 9.x 开始Kettle 用modules和plugins两个目录装载组件JDK 版本不对时经常是插件加载静默失败界面能打开但某些步骤找不到排查时先怀疑 JDK。2.3 调整 Spoon 启动参数把 -Xmx 从默认值抬上去默认内存配置对几千行的表没问题但如果你在转换里连了三个数据库、中间还做排序合并512MB 的堆很容易触发OutOfMemoryError。Kettle 9.3 的启动参数写在Spoon.bat里搜索PENTAHO_DI_JAVA_OPTIONS这一行就能看到当前堆设置。# 编辑 Spoon.bat找到原行后改为如下配置 set PENTAHO_DI_JAVA_OPTIONS-Xms512m -Xmx2048m -Dfile.encodingUTF-8逻辑说明-Xms512m是初始堆大小-Xmx2048m是最大堆上限-Dfile.encodingUTF-8是为中文数据准备的 JVM 默认编码。前期调试时不需要给太大够用就好堆越大GC 暂停时间反而可能变长。Linux 下编辑spoon.sh找到同一行变量后改为export PENTAHO_DI_JAVA_OPTIONS-Xms512m -Xmx2048m -Dfile.encodingUTF-8这里有个容易忽视的点如果你的 JDK 是 32 位版本最大堆只能设置到 1.5GB 左右强行设 2048m 会在启动时报Could not reserve enough space。排查时先运行java -version确认是 64 位还是 32 位再做内存调优。窗口界面启动后在 Spoon 右上角帮助菜单的 About 里能看到当前生效的 Java 版本和内存信息这个和命令行里配的对不上说明环境变量没生效。3. 数据库连接与中文乱码先解决九成的连接报错压缩包装完只是第一步真正的坑几乎全集中在数据库连接环节。Kettle 9.3 的连接管理虽然做成图形化但驱动版本、连接串参数、JVM 编码这三样东西只要错一个要么连不上要么数据乱码。3.1 JDBC 驱动的选择MySQL 8 为什么用 com.mysql.cj.jdbc.Driver9.3 自带的 MySQL 驱动是 5.1.x直接用它连 MySQL 5.7 没问题但如果目标库是 MySQL 8你会遇到Communications link failure或者SSL connection error。原因很简单驱动版本太老和 8.x 的握手协议对不上。解决办法是去下载 MySQL 8.0.x 的官方 JDBC 驱动把mysql-connector-java-8.0.x.jar扔到>useSSLfalse characterEncodingUTF-8 allowPublicKeyRetrievaltrue serverTimezoneAsia/Shanghai参数说明useSSLfalse是为了本地和测试环境不强制走 SSL 握手省去证书配置characterEncodingUTF-8保证中文字符以 UTF-8 传输allowPublicKeyRetrievaltrue是 MySQL 8 在useSSLfalse时可能要求的一次性公钥获取开关serverTimezoneAsia/Shanghai解决驱动与数据库服务器时区不一致导致的CST时间偏移问题。如果你的数据库不是 MySQL对应驱动也有类似参数比如 PostgreSQL 的characterEncoding要写在 JDBC URL 里而不是选项页。我还遇到过一个情况连接串里写了serverTimezoneGMT%2B8结果数据里的date字段整体快了 14 小时。原因是我在选项里加了两次 timezone一个参数覆盖了另一个。排查方法是打开连接配置把参数列表截图或导出逐条对比不要靠记忆。3.3 界面与数据乱码设置 JVM 文件编码后重启 Spoon这是最隐蔽的一个坑——Spoon 界面上的中文都是正常的但跑到“表输入”读取数据时中文变成了连续的问号。原因不是数据库编码而是 JVM 的file.encoding没显式指定。Windows 中文系统默认编码是 GBKKettle 内部很多字符串操作依赖默认编码两边打架就产生乱码。# 同 2.3确认 PENTAHO_DI_JAVA_OPTIONS 里带上了 file.encoding set PENTAHO_DI_JAVA_OPTIONS-Xms512m -Xmx2048m -Dfile.encodingUTF-8 Spoon.bat设置后重启 Spoon再跑一次读取中文字段的转换。如果乱码依旧检查数据库连接串里的characterEncoding是否和表结构字符集一致。比如表是utf8mb4连接串只写UTF-8没问题但如果表是gbk而你强制 UTF-8 读取反而会出现字符替换。数据库表字符集和连接编码要匹配JVM 编码是最后一道兜底不是万能药。4. 从表输入到写库做一个能跑通的转换与作业安装和连接都打通后真正干活的方式是搭转换和作业。不少新手把这两个概念搞混以为作业里直接放步骤就行结果保存成.kjb文件再用 Kitchen 调度跑出来只有第一个步骤执行。这一章把两者分清楚并给一条可以直接复制的实现路径。4.1 转换 vs 作业各自的门派与分工转换Transformation保存为.ktr负责具体的数据流处理比如从 A 表读取、做字段处理、写入 B 表步骤之间有数据传递是“数据管道”的逻辑作业Job保存为.kjb负责调度和控制比如判断前一天有没有跑成功、失败时发邮件、定时去执行某个转换。简单说转换管数据作业管流程。打开 Spoon 后按CtrlN新建转换从左侧面板拖入“表输入”“表输出”等步骤连线后点运行按钮这是最基础的调试跑法。比调试更重要的几个步骤名需要提前记住表输入Table Input、表输出Table Output、插入/更新Insert/Update、执行 SQL 脚本Execute SQL Script、值映射Value Mapper。“表输入”里写的 SQL 支持参数绑定后面的测试会很依赖这一点。4.2 搭一个表输入 → 字段转换 → 表输出下面是一个最小可跑的转换设计从 MySQL 读取未处理的订单数据把状态字段从 1/0 映射成“成功/失败”再写入目标表。在 Spoon 里拖入三个步骤连线顺序是表输入 → 值映射 → 表输出。表输入步骤配置连接的数据库业务库此前已建好的连接 SQL 查询语句 SELECT order_id, order_status, order_amount FROM t_order WHERE order_status ?参数说明SQL 里这个?问号不是 JDBC 的占位符而是 Kettle 的变量写法。运行时对应的是一个具体值比如后面调度时通过参数传入。如果不确定变量怎么定义先写死WHERE order_status 1跑通后续再替换成${status}。值映射步骤配置字段名源值目标值order_status1成功order_status0失败表输出步骤配置目标表t_order_clean 提交记录数Commit Size500 批量插入开启如果你用的驱动支持逻辑说明提交记录数控制在 500意思是攒够 500 行才提交一次事务。设太大会导致事务持有时间过长数据库锁冲突概率升高设太小又会让写库变慢。批量插入开关决定了是逐行执行 INSERT 还是攒成批发送MySQL 8 驱动建议开启速度能提升一个量级。连线后点运行下方“执行结果”会显示输入行数、输出行数和耗时。如果只改了字段映射没改字段类型输出表可能报字段类型不匹配这时候在“字段选择”步骤里手工指定目标字段类型更稳妥。4.3 用 Pan.bat 和 Kitchen.bat 做命令行调度图形界面只是调试用真实生产环境里通常是命令行批处理调用转换和作业方便挂到系统计划任务里。Pan.bat 跑转换Kitchen.bat 跑作业二者参数格式基本一样核心是/file指定文件路径、/level指定日志级别、/param传参。# 直接运行一个转换 Pan.bat /file:D:\etl\jobs\load_order.ktr /level:Basic /logfile:D:\etl\logs\pan.log # 带参数运行一个作业 Kitchen.bat /file:D:\etl\jobs\daily_order.kjb /level:Detailed /param:status1 /logfile:D:\etl\logs\kitchen.log参数说明/level:Basic只输出阶段性的关键日志Detailed会逐行打印步骤数据流信息调试时用 Detailed稳定后改成 Basic 减少日志量/param是作业级变量变量名前不加-直接冒号赋值/logfile把控制台输出重定向到文件挂定时任务后主要靠这个文件排查问题。Windows 计划任务里调用 Kitchen 时记得在“操作”里填全路径程序指向kitchen.bat参数里不要加cmd /c。Linux 下用sh kitchen.sh调用即可。我习惯把带日期的日志文件名放到/logfile里比如daily_%Y%m%d.log但这个通配符不是 Kettle 原生支持的实际做法是在批处理外层拼好文件名再传进去不要在 Kettle 参数里依赖这种格式化。5. 避坑Kettle 9.3 的五个典型翻车现场以下五条是我在实际使用和给团队排障时反复遇到的坑每一条都对应真实的运行现场按“现象 → 原因 → 解决”记录。5.1 双击 Spoon.bat 后一闪而过现象双击Spoon.bat黑色命令行窗口闪一下界面没有任何反应。原因绝大多数情况是JAVA_HOME没有指向有效的 JDK。系统装了 JDK 17 或者只有 JRE 时启动脚本第一轮检查就会失败并退出。解决打开命令行手动执行下面命令后再启动set JAVA_HOMEC:\Program Files\Java\jdk1.8.0_202 set PENTAHO_JAVA_HOME%JAVA_HOME% cd D:\etl\data-integration call Spoon.bat如果命令窗口里打印了Java not found或者version信息不符合预期就说明 JDK 配置没生效。不要在 PATH 里放多个 Java 目录Kettle 优先用PENTAHO_JAVA_HOME。5.2 表输入测试连接成功但运行时提示表或视图不存在现象在 Spoon 连接配置里点“测试”能通过但跑到“表输入”步骤报Table xxx.xxx doesnt exist。原因连接的用户有权限访问连接串里配置的默认库但手动写 SQL 时表名前没带库名而且该用户对当前默认库没有该表的查询权限。常见于多个数据库实例共用一个账号的场景。解决SQL 里把表名写成全限定名例如db_name.t_order。同时回连接配置的“选项”里确认databaseName参数没有写错——有些驱动不识别这个参数连接串直接写到 URL 里更直观。5.3 乱码从界面蔓延到写库现象Spoon 界面中文正常但表输入读入的数据到了目标库全是问号或者反过来界面里看到的是中文写进库成了???。原因JVM 默认编码和数据库连接编码不一致。Windows 中文系统的file.encoding默认是 GBKMySQL 连接串characterEncodingUTF-8时Kettle 内部拿 GBK 去解析 UTF-8 字节流必然出错。解决先改Spoon.bat里的PENTAHO_DI_JAVA_OPTIONS加-Dfile.encodingUTF-8再检查连接串里的characterEncoding是否和表字符集一致最后在“表输入”步骤里不要手工把字段转成bytes让 Kettle 按连接串自动处理。三步都确认过之后乱码基本消失。5.4 作业调度失败但日志里没有明显报错现象用Kitchen.bat调起的作业日志停在某个转换开始之后若干秒没有任何异常信息作业结果却是失败。原因多数是作业内部的某个步骤“等待完成”失败或者是上一个转换占用了某个共享的连接资源。Kettle 作业默认不是一个严格的事务容器步骤失败后后续步骤还会继续跑但整体被标记为失败。解决查看日志时不要只看最后几行搜一下ERROR和WARN关键字在作业里把步骤连接改成“串行执行”并给关键转换加上“成功”分支把失败分支引到一个写日志的步骤。设置路径作业编辑区选中连接线双击后在菜单里选“执行下一个作业项当上一个结果为成功”显式定义依赖关系。5.5 处理大数据量时 Spoon 假死几分钟后内存溢出现象在 Spoon 里调试一个大转换前面跑得好好的处理几十万行时界面卡住最后弹出内存溢出对话框。原因Spoon 的 JVM 堆只有默认的 512MB 左右而且预览数据时 Kettle 会把样本行缓存在内存里。表输入、排序、去重这些有状态步骤消耗更多超出后就触发 GC 风暴。解决先按 2.3 节把-Xmx调到 2048m 或 3072m64 位 JDK 下重启后再跑同时把“表输入”步骤里的“限制行数Limit”设成一个调试值比如 10000 行跑通后再放开。注意不要在生产命令行里也跑这么大的上限Kitchen 的-Xmx是独立配置的和 Spoon 互不影响。6. 一个小习惯每条大任务先跑 1000 行再放开全量把这份 pdi-ce-9.3.0.0-428 装好、连接配好、作业跑通之后日常维护的核心问题变成了“怎么改才不炸”。我每次修改一个别人留下的转换或者新建一条同步逻辑都强制自己先做一遍小样本验证。具体做法在“表输入”步骤的 SQL 最外层套一个LIMIT条件。以 MySQL 为例原来写的是SELECT ... FROM t_order WHERE create_time ${lastTime}验证阶段改成SELECT ... FROM t_order WHERE create_time ${lastTime} LIMIT 1000跑通之后再把LIMIT去掉。如果目标库是 Oracle写成FETCH FIRST 1000 ROWS ONLYSQL Server 用SELECT TOP 1000 ...。这样做的价值不只是防内存溢出更重要的是快速暴露字段映射错误1000 行数据覆盖不了所有边界值但能覆盖最常见的问题比如某列为空、金额带负数、状态值超出了映射范围。样本跑通后我还会在转换里临时插一个“字段选择”步骤对比输入输出字段的行数再连一个“写日志”步骤打印当前时间戳。原因是我吃过一次亏某次全量跑完才发现逻辑对日期的处理差了一天小样本时因为当天没有跨零点数据根本没暴露。从那以后我每次接新的同步任务都强迫自己在小样本阶段把日期边界、空值、重复值这三个检查点过一遍再放开全量。这套习惯救了我很多次希望你也能少走这些弯路。本文还有配套的精品资源点击获取