简介Kettle 现已更名为 Pentaho Data IntegrationPDI这份 9.4 版本资源对应 PDI 9.4 社区版适合 ETL 开发工程师、数据仓库建设者、数据运维人员以及正在从旧版 Kettle 迁移到 PDI 的团队使用可直接解决可视化数据抽取、转换、加载及作业调度的环境搭建、开发调试和离线部署问题。压缩包共 1082 个文件、约 358.13MB除核心 jar 库外还包含 196 个 ktr 转换、19 个 kjb 作业、80 个 xml 配置以及 Spoon、Kitchen、Pan、Carte 对应的 bat/sh 启动与调度脚本文件类型以 630 个 jar、196 个 ktr、80 个 xml、31 个 svg 为主jar 支撑程序运行ktr/kjb 定义转换与作业xml 存放资源库和步骤配置bat/sh 适配 Windows 与 Linux 环境另配套 xlsx、txt、properties、xul 等示例说明和界面参数文件。已有 7620 人浏览学习。读者拿到后可直接获得 PDI 9.4 社区版的完整目录结构快速启动 Spoon 图形化设计器并通过自带转换与作业示例理解数据库连接、资源库配置、命令行批量调度和集群部署等常见落地方式。1. Kettle 9.4 与 PDI 9.4这版 ETL 工具解决什么问题拿到 Kettle 9.4 这个安装包时我第一反应是Pentaho Data Integration 9.4 到底比 8.x 强在哪值不值得把线上正跑的作业迁过去。用了一段时间后我的结论是它最大的价值不在某个炫酷的新组件而在对旧作业的兼容性上资源库和连接管理这两块比老版本稳当不少。对每天要拉业务库、清洗数据、写报表层的开发来说这就是一套拿到就能用的 ETL 工具箱适合从每天几百行的小同步到千万级批处理。也正因为它是 Java 写的桌面加命令行混合体很多人兴致勃勃装完第一步启动就卡住。门是开着的但要先进得去还得先认准 Java 版本和几个环境变量。后面几章我会按一个生产项目的推进顺序把 9.4 的安装、配置、同步链路、典型故障和调度技巧拆开讲。新手能顺着步骤把第一条链路跑起来熟手也能在我踩过的坑里省下几个小时的排查时间。2. 环境准备与启动配置Java 8、内存参数和目录结构2.1 装之前先锁 Java 8别拿高版本赌兼容Kettle 9.4 虽然是用 Java 写的但官方默认链路是 Java 8。我做过一次想当然的操作直接拿 JDK 11 去启动 spoon.sh控制台刷出一片类加载错误界面根本起不来。原因在于它内置的依赖对 JAXB 这类模块有硬引用JDK 9 之后这些模块从标准库里被移除所以“高版本肯定兼容”这句话在 PDI 9.4 面前不成立。正确做法是先确认系统 JAVA_HOME 指向 Java 1.8再看操作系统位数两边都统一再考虑启动。还有一个常见问题机器上装了多个 JDKjava -version 指向 11但 kettle 启动脚本里 PENTAHO_JAVA_HOME 没有设置脚本会优先用 JAVA_HOME环境变量一错后面全错。我一般会在每台服务器上先把下面这组命令跑一遍再决定下载哪个 JDK而不是直接双击安装包。java -version echo JAVA_HOME$JAVA_HOME which java update-alternatives --list java 2/dev/null || ls /usr/lib/jvm/这段命令的作用是把默认 JDK、JAVA_HOME 位置和候选 JDK 全部列出来。第一行看版本号是否为 1.8 系列第二行确认环境变量有没有指错第三行定位实际执行文件最后一行在多 JDK 的机器上列出系统里还装了哪些版本。Kettle 9.4 的启动脚本会读取 PENTAHO_JAVA_HOME如果这个变量没设它就退回 JAVA_HOME这时两个变量必须一致否则脚本选的是 A 版本、系统实际用的却是 B 版本启动时的报错指向会很别扭明明 9.4 支持 Java 8却一直报版本错误。2.2 目录解压和环境变量生产环境推荐的写法解压后核心目录是>export KETTLE_HOME/opt/pdi/kettle-home export JAVA_HOME/usr/lib/jvm/java-8-openjdk-amd64 export PENTAHO_JAVA_HOME$JAVA_HOME export KETTLE_MAX_LOG_SIZE_IN_LINES100000 export KETTLE_MAX_LOG_TIMEOUT_IN_MINUTES1440 mkdir -p /opt/pdi/kettle-home/.kettle这五行的作用分别是KETTLE_HOME 确定所有配置文件的根目录JAVA_HOME 和 PENTAHO_JAVA_HOME 把运行环境锁死在 Java 8两个 KETTLE_MAX 参数限制内部日志的行数和保留时间防止长时间跑批把磁盘撑爆。还有一个细节kettle.properties 文件里可以写 default.properties如果机器内存充足我会在启动前设置 PENTAHO_DI_JAVA_OPTIONS例如 -Xmx2048m -Xms512m否则默认堆大小对大批量转换来说确实偏小跑三十分钟就报内存不足。2.3 首次启动文件资源库还是数据库资源库第一次打开 spoon.sh登录弹窗会让你选资源库。资源库里放的是转换、作业、连接配置这些元数据。我的建议很简单个人用选文件资源库多人协作选数据库资源库但前提是协作人数超过两个再说。文件资源库本质是一堆 .ktr 和 .kjb 文件放在某个共享目录里适合一个人维护脚本的场景备份直接拷贝文件即可。数据库资源库把元数据写到数据库表里好处是多人同时编辑、版本冲突有日志坏处是数据库一旦连不上连设计器都进不去。这里给一个对比资源库类型适用人数部署成本备份方式风险点文件资源库1 人零成本直接拷贝目录多人共用易覆盖数据库资源库2 人以上需要建库建表备份数据库库挂了打不开界面实际项目中我更推荐一种混合方式设计期用文件资源库定时调度直接跑 .ktr 文件路径不经过资源库。这样即使资源库连不上已经验证过的任务在命令行下照样执行不会因为一个连接配置问题把整个数据链路的命脉都掐断。3. 用一条增量同步链路串起 PDI 9.4变量连接、时间戳策略与命令行3.1 数据库连接用变量占位别把连接写死在转换里实际项目里最踩的配置坑是把数据库连接写死在转换里。开发库和线上库一换整个转换都要重新打开改连接改完还不一定记得全有时候主机名换了密码忘了同步链路半夜挂了才被发现。我一般会这样做新建数据库连接时主机名、端口、库名、用户名、密码全部写成 ${PG_HOST} 这种变量然后通过 kettle.properties 或命令行参数传入真实值。这样同一份 .ktr 文件可以在多套环境之间复用也只有连接那一层变了转换本身的逻辑完全不动。在 spoon.sh 里新建连接时主机名填 ${PG_HOST}端口填 ${PG_PORT}数据库名填 ${PG_DB}密码填 ${PG_PASSWORD}。这些变量不一定要提前写进配置文件运行时通过命令行 -param 传入即可。比写死好在哪里下面这张表可以说明变量名用途开发环境示例值生产环境示例值PG_HOST数据库主机192.168.10.2110.20.30.41PG_PORT端口54325432PG_DB库名ods_devods_prodPG_USER账号etl_useretl_userPG_PASSWORD密码dev_passprod_pass这套变量替换机制生效的时机在转换启动之前所以不必担心执行到一半才去读变量。要注意的是变量名不要和 Kettle 内置的 ${user.home}、${java.home} 冲突命名尽量带前缀避免莫名其妙的路径错误。经验做法是统一用环境名加对象名的格式例如 ${PG_HOST} 里的 PG 代表 PostgreSQL一眼能看出是哪套连接。3.2 时间戳增量同步表输入 SQL 与字段选择的配合增量同步是 ETL 里最常见的需求PDI 9.4 里很多人做这个会直接用“表输入”步骤把整张表 select 出来再靠“表输出”的数据库 merge 去比对数据量一大就卡死。更省事的做法是借助时间戳字段做增量条件每次只取上次同步时间之后的新数据。下面这个 SQL 是表输入步骤里经常用的写法SELECT id, user_id, order_status, update_time FROM source_order WHERE update_time ${LAST_RUN_START}SQL 里 ${LAST_RUN_START} 是变量占位每次运行时传入上一次成功同步的时间点。关键点在于这个时间点必须在转换启动前从外部传入而不是在 SQL 里写死。PDI 9.4 的变量替换发生在步骤执行之前所以只要时间点传对两次运行之间的记录不会重复也不会漏。字段选择步骤我一般要专门做一次因为源表里常有不需要的字段比如内部备注字段、临时计算列别让这些数据直接落到目标表既减少网络传输又避免目标表字段数量对不上导致“表输出”报错。在字段选择里只保留 id、user_id、order_status、update_time 四个字段勾选数据类型目标表表结构保持一致运行起来会比全量搬运干净很多。3.3 用 pan.sh 跑通转换日志级别与返回码检查在 spoon 里做完转换、保存成 sync_order.ktr 之后我一般不会一直开着图形界面等它跑完而是直接关掉界面用命令行执行。命令行方式的优势在于可以放进 cron 或者其他调度平台返回码能告诉外部系统这次执行成没成功。下面是一个生产环境常用的执行脚本#!/bin/bash # 增量同步日志按天落盘 KETTLE_HOME/opt/pdi/kettle-home LOG_DIR/data/etl/logs STAMP$(date %Y%m%d_%H%M%S) /data/software/data-integration/pan.sh \ -file/data/etl/sync_order.ktr \ -param:LAST_RUN_START$(date -d -1 hour %Y-%m-%d\ %H:%M:%S) \ -level:Basic \ -logfile${LOG_DIR}/sync_order_${STAMP}.log # 返回码检查 if [ $? -eq 0 ]; then echo 同步成功 else echo 同步失败退出码 $? fi解释一下几个参数-file 指定转换文件的绝对路径-param 传入变量这里 LAST_RUN_START 取的是当前时间往前推一小时实际生产一般会从状态表里读上一次成功时间-level:Basic 是日志级别Basic 只输出关键步骤和错误信息比 Debug 少很多噪音-logfile 把日志写到固定目录文件名带时间戳方便回溯。返回码这里有点讲究。pan.sh 在转换成功时返回 0失败时返回非 0但这个非 0 值与具体错误原因没有一一对应关系所以脚本里不能只判断返回值还要在日志里搜 ERROR 关键字。我一般会写成执行完立即 grep 日志文件里有没有 “ERROR” 或 “Exception”有的话再检查日志尾部内容而不是盲目重跑。4. 避坑与排查PDI 9.4 运行中的五个典型故障4.1 启动阶段的三类硬坑JAVA_HOME、驱动冲突、驱动版本不匹配第一个坑是启动 spoon.sh 时报 “Could not find or load main class” 或者直接报版本错误。现象是双击脚本后窗口一闪而过控制台显示 Java 版本不支持。原因是 JAVA_HOME 指向了 JDK 11 或更高而 PDI 9.4 硬性依赖 Java 8。解决方法是先执行 java -version 确认版本如果是 11就把 JAVA_HOME 和 PENTAHO_JAVA_HOME 都改成 Java 8 的路径再重新启动这一步能解决七成以上的启动失败。第二个坑是数据库连接测试通过但一跑转换就报 “No suitable driver found”。现象是 JDBC URL 看着没问题驱动也放进了 lib 目录可执行时还是找不到驱动类。原因是 lib 目录下有多个版本的驱动 jar 冲突或者 jar 没有给到正确的执行权限。解决方法是清理掉多余版本只保留一个与数据库版本匹配的驱动 jar然后确认文件权限是 755再重启 spoon 或 pan千万别图省事把整个 lib 目录拷贝覆盖。第三个坑是 MySQL 8 的驱动连不上。现象是测试连接时提示 SSL 连接失败或者握手协议错误。原因是 MySQL 8 默认开启 useSSL而旧版驱动不支持。解决方法是把驱动换成 mysql-connector-java 8.x 版本并且在连接参数里显式加上 useSSLfalse 和 allowPublicKeyRetrievaltrue这两个参数很多老项目写死换到新库时必须检查一遍。4.2 数据正确性的两类坑中文乱码和增量漏数第四个坑是源表中文数据导入后变成问号。现象是表输入查出来没问题表输出落库后中文全部变成 gbk 乱码。原因是 kettle.properties 里没有设置默认字符集或者 JDBC URL 里缺失 characterEncoding 参数。解决方法是在 kettle.properties 里加一行统一编码同时在 JDBC URL 末尾加上 characterEncodingutf8生产环境字符集必须全链路一致数据库的 character_set_server、JDBC URL、文件编码三处都要是 utf8缺一个就会在某些记录上翻车。第五个坑是时间戳增量同步漏数据。现象是某一天发现目标表比源表少了部分记录检查 SQL 条件也没问题。原因是服务器时区与数据库时区不一致SQL 里的 NOW() 取的是应用服务器时间而表里的 update_time 是数据库时间两边差几个小时就会漏掉边界数据。解决方法是统一应用服务器和数据库的时区或者更稳妥的做法是让增量条件不从应用服务器取时间而是从目标表里查已有的最大时间再传给下一次转换把时区的干扰从源头掐掉。5. 让作业跑得更稳日志落盘、失败重试与集群节点的一个提醒5.1 失败重试直接写在 shell 层比在作业里做循环简单PDI 9.4 的作业里虽然有“循环”能力但做失败重试体验并不好作业分支逻辑一复杂界面就乱别人接手难维护。我更习惯在 shell 层做重试思路是先执行 pan.sh判断返回值失败就等三十秒再跑最多重试三次然后把每次的日志单独落一个文件方便事后看是哪次失败、哪次成功。这样一个脚本可以套用给所有转换不用在 spoon 里逐个画。#!/bin/bash # 带重试的 pan 执行包装通用版本 run_pdi() { local ktr_path$1 local max_retry${2:-3} local attempt1 until [ $attempt -gt $max_retry ]; do echo [$(date %F %T)] 开始第 ${attempt} 次执行 if /data/software/data-integration/pan.sh \ -file$ktr_path \ -level:Basic \ -logfile/data/etl/logs/$(basename $ktr_path .ktr)_${attempt}.log; then echo 执行成功 return 0 fi echo 执行失败进入重试 attempt$((attempt 1)) sleep 30 done return 1 } run_pdi /data/etl/sync_order.ktr 3这里要理解一个关键点pan.sh 只要某一个步骤报错整个转换就会以非 0 状态退出所以失败时重试整个转换是安全的因为表输出步骤有“提交”机制单条数据失败不会直接污染主表只是重试时可能重复读源表数据。如果你的转换里包含“删除再插入”或“清空目标表”的操作重试风险会变大这种场景下重试次数不建议超过 2 次而且日志文件必须保留完整方便定位问题出在哪一步。5.2 集群节点的一个提醒PDI 9.4 支持集群模式可以把一个转换拆分到多个节点并行跑但实际项目里真正受益的场景不多。数据量几十万级别时单机加合理分片比搭集群简单得多集群配置本身又是一套黑匣子主从节点之间要同步元数据版本不一致就会造成步骤运行一半报错。我的习惯是优先看转换里有没有可以水平拆分的步骤比如表输入按日期分区、字段选择里过滤掉无用列这些优化做完如果还慢再考虑集群而不是一上来就搭一套分布式。这套 PDI 9.4 的安装包和相关驱动我已经整理在下载页里解压后按第二章的环境变量配置直接就能用。从那以后我每次接手新的 Kettle 任务都强制走一遍这个检查顺序先看 JAVA_HOME 指向是不是 1.8再查驱动 jar 版本和 JDBC URL 是否匹配最后用最小数据量把转换跑通再上调度。希望帮到你。本文还有配套的精品资源点击获取