简介这份资源面向数据工程师、ETL 初学者及需要搭建数据集成流程的技术人员提供开源 ETL 工具 KettlePentaho Data Integration9.3 版本的获取入口帮助读者解决官方渠道下载不便的问题。资源包共 1 个 docx 文档压缩后约 14KB文档内整理了百度云盘链接与提取码便于按需获取安装包。Kettle 以纯 Java 编写可跨 Windows、Linux、Unix 运行通过 Spoon 图形化界面拖拽构建 Transformation 与 Job支持 MySQL、Oracle、SQL Server 及 MongoDB、HDFS 等多种数据源并可与 S3、Azure Blob 等云存储集成。文档还围绕 9.3 版本的性能优化与稳定性改进作了说明适合用于数据抽取、清洗、聚合与工作流调度的学习实践。目前已有 5739 人学习下载可作为入门了解与版本获取的参考。1. 从一次“双击没反应”说起Kettle 9.3 到底装的是什么上周帮一个做数据迁移的朋友看环境他双击 Spoon.bat 之后窗口闪一下就没了任务管理器里 java 进程起来又消失折腾一下午以为是包坏了。结果只是机器上同时装了 JDK 8 和 JDK 17JAVA_HOME 指到了 17而 Kettle 9.3 这套老牌 ETL 工具对高版本 JDK 的兼容性并不好。这类“装完打不开”的场景在 Kettle 的部署里太常见了。Kettle 中文叫水壶正式名称是 Pentaho Data Integration纯 Java 编写Windows、Linux、Unix 都能跑靠 Spoon 这个图形化客户端拖拽出 Transformation 和 Job。它适合谁适合手上有一堆异构数据源、需要定时抽取清洗落库又不想从零写调度代码的人。装不好会怎样轻则连不上数据库重则转换跑一半内存溢出日志还看不出所以然。这篇就按我实际部署的顺序把 9.3 这套环境从版本选择、解压配置、驱动放置到跑通验证一步步写清楚。2. 装前把环境列清JDK 版本与系统依赖的取舍2.1 JDK 选 8 还是 11这是第一个分水岭Kettle 9.3 官方推荐的是 JDK 8实际部署里我一般也锁 8。原因不玄学Spoon 的 SWT 图形库、部分老插件、以及连接池组件在 JDK 11 上虽然能起但会遇到反射访问被模块系统拦截的警告严重时直接抛InaccessibleObjectException。如果你机器上已经有高版本 JDK不要改全局 JAVA_HOME而是给 Kettle 单独指定。Windows 下改Spoon.bat里的启动参数Linux 下改spoon.sh把 java 路径写死到 JDK 8 的 bin 目录。# Linux 下确认当前 java 指向避免全局污染 which java java -version # 假设 JDK 8 解压在 /opt/jdk8临时切换只对当前 shell 生效 export JAVA_HOME/opt/jdk8 export PATH$JAVA_HOME/bin:$PATH java -version # 必须显示 1.8.x这段的逻辑是先看清现状再动手which java告诉你实际调用的是哪个二进制java -version确认大版本。临时 export 只影响当前终端不会把服务器上其他服务的 Java 环境带偏这是运维里最基本的隔离习惯。参数上唯一要记的是Kettle 9.3 认JAVA_HOME但启动脚本里如果写死了路径环境变量会被覆盖所以改脚本比改环境变量更稳。2.2 内存与字符集两个容易被忽略的前置项Kettle 默认启动内存偏小处理几十万行以上就容易OutOfMemoryError。Spoon 的启动脚本里有PENTAHO_DI_JAVA_OPTIONS这个变量我一般设成-Xms1024m -Xmx4096m具体看机器内存别超过物理内存的七成。字符集方面如果源库有中文务必确认file.encoding是 UTF-8否则抽取出来的 CSV 打开是乱码排查半天以为是数据库编码问题。# 在 spoon.sh 或 Spoon.bat 中找到该变量并调整 export PENTAHO_DI_JAVA_OPTIONS-Xms1024m -Xmx4096m -Dfile.encodingUTF-8-Xms是初始堆-Xmx是最大堆两者设成一样可以避免运行中反复扩容带来的抖动-Dfile.encodingUTF-8强制 JVM 默认编码比事后改文件编码省事。这里没有唯一正确答案机器内存 8G 就给 4G 上限16G 可以给到 8G但别把-Xmx设得比物理内存还大否则系统开始换页转换速度反而断崖式下跌。2.3 系统依赖对照表项目WindowsLinux说明JDK8u202 及以上 8.xOpenJDK 8不建议 11图形环境自带需 X11 或 VNC无界面用 kitchen/pan磁盘约 1.5G约 1.5G含驱动与日志空间字符集UTF-8UTF-8避免中文乱码Linux 服务器如果没有图形界面Spoon 是起不来的这时候要用pan.sh跑转换、kitchen.sh跑作业这两个是命令行入口部署定时任务时反而更常用。表格里磁盘那行别省Kettle 解压后加上后续放的 JDBC 驱动和日志1.5G 是保守估计临时文件目录还要单独留空间。3. 解压与目录规划别把包随手丢在桌面3.1 解压路径与目录结构拿到 9.3 的压缩包后我习惯解压到一个不带空格、不带中文的路径比如 Windows 下D:\pdi-ce-9.3Linux 下/opt/pdi-ce-9.3。带空格的路径会让部分启动脚本解析参数出错中文路径在日志里会变成问号排查时很痛苦。解压后重点看几个目录># Linux 解压示例假设包在当前目录 unzip pdi-ce-9.3.zip -d /opt/ mv /opt/data-integration /opt/pdi-ce-9.3 ls /opt/pdi-ce-9.3 | head先解压再改名是为了让目录名带上版本号以后升级 9.4 时可以并存出问题能快速回退。ls那一步是确认解压完整正常应该能看到Spoon.sh、kitchen.sh、pan.sh、lib等。如果解压报错说文件损坏别急着重下先核对压缩包大小和校验值百度云下载偶尔会有传输不完整的情况这是血泪经验。3.2 首次启动 Spoon 与工作目录设置Windows 下双击Spoon.batLinux 有图形环境就执行./spoon.sh。第一次启动会弹出一个选择工作目录的窗口这里建议单独建一个D:\kettle-workspace或/opt/kettle-workspace不要用默认的用户目录。原因很简单转换和作业文件、日志、临时文件都会往这里写混在系统目录里以后清理和备份都麻烦。# Linux 启动 Spoon指定工作目录通过界面选择即可 cd /opt/pdi-ce-9.3 ./spoon.sh启动后如果界面正常出现说明 JDK 和图形库都没问题。如果闪退回到第 2 章检查 JAVA_HOME 和PENTAHO_DI_JAVA_OPTIONS把启动脚本里的 java 路径改成绝对路径再试。这一步的验证标准很朴素能看到 Spoon 主界面、左侧能展开“转换”和“作业”两个节点就算环境通了。3.3 数据库驱动放置libext 还是 libKettle 本身不带 MySQL、Oracle 这些商业或第三方数据库的驱动需要自己放。常见做法是放到libext目录而不是lib。lib里是 Kettle 自身的核心包往里塞东西容易在升级时被覆盖libext是专门给扩展 jar 用的优先级也合适。放完之后必须重启 Spoon驱动才会被类加载器扫到。# 以 MySQL 8 驱动为例把 jar 复制到 libext cp mysql-connector-java-8.0.28.jar /opt/pdi-ce-9.3/libext/ ls /opt/pdi-ce-9.3/libext | grep mysql驱动版本要和数据库版本匹配MySQL 8 用 8.x 驱动MySQL 5.7 用 5.1.x 驱动混用会报Unknown system variable或时区错误。放完ls确认文件在然后重启 Spoon在“数据库连接”里测试连接能弹出“连接成功”才算数。Oracle 的驱动同理注意 ojdbc 版本和 JDK 版本对应JDK 8 用 ojdbc8。4. 配置连接与跑通第一个转换从建库到预览数据4.1 新建数据库连接并测试Spoon 里点“文件 → 新建 → 数据库连接”类型选 MySQL填主机、端口、库名、用户名密码。这里有个参数坑MySQL 8 的连接 URL 要加useSSLfalseserverTimezoneAsia/Shanghai否则要么 SSL 握手失败要么时间字段差 8 小时。填完点“测试”成功后再点“确认”连接会保存在当前工作目录的shared.xml里下次打开还在。连接名称local_mysql 连接类型MySQL 主机名称127.0.0.1 数据库名称demo_db 端口号3306 用户名etl_user 密码******连接名称建议带环境前缀比如prod_、test_以后连接多了不至于点错。测试连接这一步不能省很多人直接建转换跑到一半才发现连不上日志里一堆Communications link failure回头查连接配置又得重来。如果测试失败先看驱动是否在libext再看端口和防火墙最后看账号权限顺序别乱。4.2 拖一个“表输入”到“表输出”新建转换从左侧“核心对象”里拖“表输入”和“表输出”两个步骤用 Shift 键连线。双击“表输入”选刚才的连接点“获取SQL查询语句”选一张表确定。再双击“表输出”选目标连接和目标表勾选“指定数据库字段”做字段映射。这一步是 Kettle 最基础的抽取加载流程跑通它后面的清洗、聚合才有意义。-- 表输入里可以手写 SQL比图形选表灵活 SELECT id, user_name, created_at FROM source_user WHERE created_at 2024-01-01手写 SQL 的好处是能加过滤条件减少抽取数据量。注意 Kettle 的 SQL 里不要带分号结尾部分驱动会报语法错误。字段映射时如果源和目标字段名不一致在“数据库字段”页签里手动对应别指望自动匹配自动匹配在字段多的时候经常错位。4.3 预览与运行先看数据再落库连线完成后右键“表输入”选“预览”能看到前 100 行数据说明源端通了。然后点工具栏的绿色三角运行弹窗里选“本地执行”跑完看“执行结果”里的读写行数。如果读到了但写不进去多半是目标表字段类型不匹配或主键冲突日志里会有明确提示。执行结果示例 - 读取1200 行 - 写入1200 行 - 速度约 800 行/秒 - 状态完成预览这一步是 Kettle 最好用的调试手段比跑完整转换再查日志快得多。速度那行不用太在意本地小数据量参考意义有限真正压测要上几十万行看内存和耗时。跑通之后把转换保存成.ktr文件放在工作目录的trans子目录里命名带上业务含义比如user_extract_daily.ktr。5. 避坑与排查五条装完才发现的坑5.1 双击 Spoon 闪退日志里什么都没有现象是窗口一闪而过任务管理器里 java 进程短暂出现又消失。原因通常是 JAVA_HOME 指向了不兼容的 JDK 版本或者启动脚本里的 java 路径不存在。解决方法是打开命令行手动执行Spoon.bat这样报错会留在窗口里Linux 下执行./spoon.sh看终端输出。确认java -version是 1.8 之后再改脚本里的路径为绝对路径。5.2 连 MySQL 报时区错误或 SSL 警告现象是测试连接失败日志提示The server time zone value is unrecognized或 SSL 相关异常。原因是 MySQL 8 驱动默认要求时区和 SSL 配置。解决办法是在连接 URL 的高级参数里加serverTimezoneAsia/Shanghai和useSSLfalse或者在“选项”页签里手动加这两个参数。加完重启 Spoon 再测。5.3 转换跑一半内存溢出现象是处理大数据量时抛java.lang.OutOfMemoryError: Java heap space。原因是默认堆内存太小或者转换里用了“排序记录”这类全量加载内存的步骤。解决办法是调大PENTAHO_DI_JAVA_OPTIONS里的-Xmx同时检查转换设计能分页抽取就别一次性全拉排序尽量交给数据库做。5.4 中文乱码CSV 打开是问号现象是抽取出的文本文件中文变成乱码。原因是 JVM 默认编码不是 UTF-8或者“文本文件输出”步骤里编码没选对。解决办法是启动参数加-Dfile.encodingUTF-8同时在步骤配置里把编码显式设为 UTF-8。两边都设别只改一处。5.5 驱动放了但连接里选不到现象是libext里明明有 jar新建连接时类型列表里却没有对应数据库。原因是放完驱动没重启 Spoon或者 jar 放错了目录。解决办法是确认 jar 在libext下完全退出 Spoon 再启动还不行就检查 jar 是否完整、版本是否和 JDK 匹配。这类问题没有捷径就是重启加核对路径。6. 装完怎么验证用 kitchen 跑一个定时作业才算真通图形界面能跑通只是第一步真正部署到服务器上验证标准是命令行能跑、定时能调。我一般会建一个最简单的 Job里面串一个 Transformation然后用kitchen.sh在命令行执行看退出码和日志。这一步能暴露图形界面掩盖的问题比如环境变量在非交互 shell 里不生效、相对路径找不到文件。# Linux 下用 kitchen 执行作业-file 指定 .kjb 文件-level 控制日志级别 cd /opt/pdi-ce-9.3 ./kitchen.sh -file/opt/kettle-workspace/jobs/daily_load.kjb -levelBasic echo 退出码$?-file后面跟作业文件的绝对路径用绝对路径是为了避免 cron 里工作目录不对导致找不到文件-levelBasic输出基础日志排查时可以用Detailed看每一步耗时。echo $?那行是关键退出码 0 表示成功非 0 就要去日志里找ERROR行。定时任务里我一般把这条命令写进 crontab日志重定向到单独文件方便回溯。验证清单可以按这个顺序走一遍命令行执行退出码为 0、日志里读写行数和预期一致、目标表数据抽查几条对得上、连续跑两次不报主键冲突。这四步过了这套 Kettle 9.3 环境才算真正落地而不是“我这儿能打开界面”。从那以后我每次部署完 Kettle都不看界面能不能开而是直接拿 kitchen 跑一个最小作业退出码对了才敢交给业务用。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/31 2:23:09 · 阅读 1.2k Kettle 9.3 安装配置全攻略：从JDK选择到定时作业验证
简介这份资源面向数据工程师、ETL 初学者及需要搭建数据集成流程的技术人员提供开源 ETL 工具 KettlePentaho Data Integration9.3 版本的获取入口帮助读者解决官方渠道下载不便的问题。资源包共 1 个 docx 文档压缩后约 14KB文档内整理了百度云盘链接与提取码便于按需获取安装包。Kettle 以纯 Java 编写可跨 Windows、Linux、Unix 运行通过 Spoon 图形化界面拖拽构建 Transformation 与 Job支持 MySQL、Oracle、SQL Server 及 MongoDB、HDFS 等多种数据源并可与 S3、Azure Blob 等云存储集成。文档还围绕 9.3 版本的性能优化与稳定性改进作了说明适合用于数据抽取、清洗、聚合与工作流调度的学习实践。目前已有 5739 人学习下载可作为入门了解与版本获取的参考。1. 从一次“双击没反应”说起Kettle 9.3 到底装的是什么上周帮一个做数据迁移的朋友看环境他双击 Spoon.bat 之后窗口闪一下就没了任务管理器里 java 进程起来又消失折腾一下午以为是包坏了。结果只是机器上同时装了 JDK 8 和 JDK 17JAVA_HOME 指到了 17而 Kettle 9.3 这套老牌 ETL 工具对高版本 JDK 的兼容性并不好。这类“装完打不开”的场景在 Kettle 的部署里太常见了。Kettle 中文叫水壶正式名称是 Pentaho Data Integration纯 Java 编写Windows、Linux、Unix 都能跑靠 Spoon 这个图形化客户端拖拽出 Transformation 和 Job。它适合谁适合手上有一堆异构数据源、需要定时抽取清洗落库又不想从零写调度代码的人。装不好会怎样轻则连不上数据库重则转换跑一半内存溢出日志还看不出所以然。这篇就按我实际部署的顺序把 9.3 这套环境从版本选择、解压配置、驱动放置到跑通验证一步步写清楚。2. 装前把环境列清JDK 版本与系统依赖的取舍2.1 JDK 选 8 还是 11这是第一个分水岭Kettle 9.3 官方推荐的是 JDK 8实际部署里我一般也锁 8。原因不玄学Spoon 的 SWT 图形库、部分老插件、以及连接池组件在 JDK 11 上虽然能起但会遇到反射访问被模块系统拦截的警告严重时直接抛InaccessibleObjectException。如果你机器上已经有高版本 JDK不要改全局 JAVA_HOME而是给 Kettle 单独指定。Windows 下改Spoon.bat里的启动参数Linux 下改spoon.sh把 java 路径写死到 JDK 8 的 bin 目录。# Linux 下确认当前 java 指向避免全局污染 which java java -version # 假设 JDK 8 解压在 /opt/jdk8临时切换只对当前 shell 生效 export JAVA_HOME/opt/jdk8 export PATH$JAVA_HOME/bin:$PATH java -version # 必须显示 1.8.x这段的逻辑是先看清现状再动手which java告诉你实际调用的是哪个二进制java -version确认大版本。临时 export 只影响当前终端不会把服务器上其他服务的 Java 环境带偏这是运维里最基本的隔离习惯。参数上唯一要记的是Kettle 9.3 认JAVA_HOME但启动脚本里如果写死了路径环境变量会被覆盖所以改脚本比改环境变量更稳。2.2 内存与字符集两个容易被忽略的前置项Kettle 默认启动内存偏小处理几十万行以上就容易OutOfMemoryError。Spoon 的启动脚本里有PENTAHO_DI_JAVA_OPTIONS这个变量我一般设成-Xms1024m -Xmx4096m具体看机器内存别超过物理内存的七成。字符集方面如果源库有中文务必确认file.encoding是 UTF-8否则抽取出来的 CSV 打开是乱码排查半天以为是数据库编码问题。# 在 spoon.sh 或 Spoon.bat 中找到该变量并调整 export PENTAHO_DI_JAVA_OPTIONS-Xms1024m -Xmx4096m -Dfile.encodingUTF-8-Xms是初始堆-Xmx是最大堆两者设成一样可以避免运行中反复扩容带来的抖动-Dfile.encodingUTF-8强制 JVM 默认编码比事后改文件编码省事。这里没有唯一正确答案机器内存 8G 就给 4G 上限16G 可以给到 8G但别把-Xmx设得比物理内存还大否则系统开始换页转换速度反而断崖式下跌。2.3 系统依赖对照表项目WindowsLinux说明JDK8u202 及以上 8.xOpenJDK 8不建议 11图形环境自带需 X11 或 VNC无界面用 kitchen/pan磁盘约 1.5G约 1.5G含驱动与日志空间字符集UTF-8UTF-8避免中文乱码Linux 服务器如果没有图形界面Spoon 是起不来的这时候要用pan.sh跑转换、kitchen.sh跑作业这两个是命令行入口部署定时任务时反而更常用。表格里磁盘那行别省Kettle 解压后加上后续放的 JDBC 驱动和日志1.5G 是保守估计临时文件目录还要单独留空间。3. 解压与目录规划别把包随手丢在桌面3.1 解压路径与目录结构拿到 9.3 的压缩包后我习惯解压到一个不带空格、不带中文的路径比如 Windows 下D:\pdi-ce-9.3Linux 下/opt/pdi-ce-9.3。带空格的路径会让部分启动脚本解析参数出错中文路径在日志里会变成问号排查时很痛苦。解压后重点看几个目录># Linux 解压示例假设包在当前目录 unzip pdi-ce-9.3.zip -d /opt/ mv /opt/data-integration /opt/pdi-ce-9.3 ls /opt/pdi-ce-9.3 | head先解压再改名是为了让目录名带上版本号以后升级 9.4 时可以并存出问题能快速回退。ls那一步是确认解压完整正常应该能看到Spoon.sh、kitchen.sh、pan.sh、lib等。如果解压报错说文件损坏别急着重下先核对压缩包大小和校验值百度云下载偶尔会有传输不完整的情况这是血泪经验。3.2 首次启动 Spoon 与工作目录设置Windows 下双击Spoon.batLinux 有图形环境就执行./spoon.sh。第一次启动会弹出一个选择工作目录的窗口这里建议单独建一个D:\kettle-workspace或/opt/kettle-workspace不要用默认的用户目录。原因很简单转换和作业文件、日志、临时文件都会往这里写混在系统目录里以后清理和备份都麻烦。# Linux 启动 Spoon指定工作目录通过界面选择即可 cd /opt/pdi-ce-9.3 ./spoon.sh启动后如果界面正常出现说明 JDK 和图形库都没问题。如果闪退回到第 2 章检查 JAVA_HOME 和PENTAHO_DI_JAVA_OPTIONS把启动脚本里的 java 路径改成绝对路径再试。这一步的验证标准很朴素能看到 Spoon 主界面、左侧能展开“转换”和“作业”两个节点就算环境通了。3.3 数据库驱动放置libext 还是 libKettle 本身不带 MySQL、Oracle 这些商业或第三方数据库的驱动需要自己放。常见做法是放到libext目录而不是lib。lib里是 Kettle 自身的核心包往里塞东西容易在升级时被覆盖libext是专门给扩展 jar 用的优先级也合适。放完之后必须重启 Spoon驱动才会被类加载器扫到。# 以 MySQL 8 驱动为例把 jar 复制到 libext cp mysql-connector-java-8.0.28.jar /opt/pdi-ce-9.3/libext/ ls /opt/pdi-ce-9.3/libext | grep mysql驱动版本要和数据库版本匹配MySQL 8 用 8.x 驱动MySQL 5.7 用 5.1.x 驱动混用会报Unknown system variable或时区错误。放完ls确认文件在然后重启 Spoon在“数据库连接”里测试连接能弹出“连接成功”才算数。Oracle 的驱动同理注意 ojdbc 版本和 JDK 版本对应JDK 8 用 ojdbc8。4. 配置连接与跑通第一个转换从建库到预览数据4.1 新建数据库连接并测试Spoon 里点“文件 → 新建 → 数据库连接”类型选 MySQL填主机、端口、库名、用户名密码。这里有个参数坑MySQL 8 的连接 URL 要加useSSLfalseserverTimezoneAsia/Shanghai否则要么 SSL 握手失败要么时间字段差 8 小时。填完点“测试”成功后再点“确认”连接会保存在当前工作目录的shared.xml里下次打开还在。连接名称local_mysql 连接类型MySQL 主机名称127.0.0.1 数据库名称demo_db 端口号3306 用户名etl_user 密码******连接名称建议带环境前缀比如prod_、test_以后连接多了不至于点错。测试连接这一步不能省很多人直接建转换跑到一半才发现连不上日志里一堆Communications link failure回头查连接配置又得重来。如果测试失败先看驱动是否在libext再看端口和防火墙最后看账号权限顺序别乱。4.2 拖一个“表输入”到“表输出”新建转换从左侧“核心对象”里拖“表输入”和“表输出”两个步骤用 Shift 键连线。双击“表输入”选刚才的连接点“获取SQL查询语句”选一张表确定。再双击“表输出”选目标连接和目标表勾选“指定数据库字段”做字段映射。这一步是 Kettle 最基础的抽取加载流程跑通它后面的清洗、聚合才有意义。-- 表输入里可以手写 SQL比图形选表灵活 SELECT id, user_name, created_at FROM source_user WHERE created_at 2024-01-01手写 SQL 的好处是能加过滤条件减少抽取数据量。注意 Kettle 的 SQL 里不要带分号结尾部分驱动会报语法错误。字段映射时如果源和目标字段名不一致在“数据库字段”页签里手动对应别指望自动匹配自动匹配在字段多的时候经常错位。4.3 预览与运行先看数据再落库连线完成后右键“表输入”选“预览”能看到前 100 行数据说明源端通了。然后点工具栏的绿色三角运行弹窗里选“本地执行”跑完看“执行结果”里的读写行数。如果读到了但写不进去多半是目标表字段类型不匹配或主键冲突日志里会有明确提示。执行结果示例 - 读取1200 行 - 写入1200 行 - 速度约 800 行/秒 - 状态完成预览这一步是 Kettle 最好用的调试手段比跑完整转换再查日志快得多。速度那行不用太在意本地小数据量参考意义有限真正压测要上几十万行看内存和耗时。跑通之后把转换保存成.ktr文件放在工作目录的trans子目录里命名带上业务含义比如user_extract_daily.ktr。5. 避坑与排查五条装完才发现的坑5.1 双击 Spoon 闪退日志里什么都没有现象是窗口一闪而过任务管理器里 java 进程短暂出现又消失。原因通常是 JAVA_HOME 指向了不兼容的 JDK 版本或者启动脚本里的 java 路径不存在。解决方法是打开命令行手动执行Spoon.bat这样报错会留在窗口里Linux 下执行./spoon.sh看终端输出。确认java -version是 1.8 之后再改脚本里的路径为绝对路径。5.2 连 MySQL 报时区错误或 SSL 警告现象是测试连接失败日志提示The server time zone value is unrecognized或 SSL 相关异常。原因是 MySQL 8 驱动默认要求时区和 SSL 配置。解决办法是在连接 URL 的高级参数里加serverTimezoneAsia/Shanghai和useSSLfalse或者在“选项”页签里手动加这两个参数。加完重启 Spoon 再测。5.3 转换跑一半内存溢出现象是处理大数据量时抛java.lang.OutOfMemoryError: Java heap space。原因是默认堆内存太小或者转换里用了“排序记录”这类全量加载内存的步骤。解决办法是调大PENTAHO_DI_JAVA_OPTIONS里的-Xmx同时检查转换设计能分页抽取就别一次性全拉排序尽量交给数据库做。5.4 中文乱码CSV 打开是问号现象是抽取出的文本文件中文变成乱码。原因是 JVM 默认编码不是 UTF-8或者“文本文件输出”步骤里编码没选对。解决办法是启动参数加-Dfile.encodingUTF-8同时在步骤配置里把编码显式设为 UTF-8。两边都设别只改一处。5.5 驱动放了但连接里选不到现象是libext里明明有 jar新建连接时类型列表里却没有对应数据库。原因是放完驱动没重启 Spoon或者 jar 放错了目录。解决办法是确认 jar 在libext下完全退出 Spoon 再启动还不行就检查 jar 是否完整、版本是否和 JDK 匹配。这类问题没有捷径就是重启加核对路径。6. 装完怎么验证用 kitchen 跑一个定时作业才算真通图形界面能跑通只是第一步真正部署到服务器上验证标准是命令行能跑、定时能调。我一般会建一个最简单的 Job里面串一个 Transformation然后用kitchen.sh在命令行执行看退出码和日志。这一步能暴露图形界面掩盖的问题比如环境变量在非交互 shell 里不生效、相对路径找不到文件。# Linux 下用 kitchen 执行作业-file 指定 .kjb 文件-level 控制日志级别 cd /opt/pdi-ce-9.3 ./kitchen.sh -file/opt/kettle-workspace/jobs/daily_load.kjb -levelBasic echo 退出码$?-file后面跟作业文件的绝对路径用绝对路径是为了避免 cron 里工作目录不对导致找不到文件-levelBasic输出基础日志排查时可以用Detailed看每一步耗时。echo $?那行是关键退出码 0 表示成功非 0 就要去日志里找ERROR行。定时任务里我一般把这条命令写进 crontab日志重定向到单独文件方便回溯。验证清单可以按这个顺序走一遍命令行执行退出码为 0、日志里读写行数和预期一致、目标表数据抽查几条对得上、连续跑两次不报主键冲突。这四步过了这套 Kettle 9.3 环境才算真正落地而不是“我这儿能打开界面”。从那以后我每次部署完 Kettle都不看界面能不能开而是直接拿 kitchen 跑一个最小作业退出码对了才敢交给业务用。希望帮到你。本文还有配套的精品资源点击获取