简介：这份资源面向数据工程师、ETL 初学者及需要搭建数据集成流程的技术人员，提供开源 ETL 工具 Kettle（Pentaho Data Integration）9.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 17，JAVA_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.encoding=UTF-8"

-Xms是初始堆，-Xmx是最大堆，两者设成一样可以避免运行中反复扩容带来的抖动；-Dfile.encoding=UTF-8强制 JVM 默认编码，比事后改文件编码省事。这里没有唯一正确答案，机器内存 8G 就给 4G 上限，16G 可以给到 8G，但别把-Xmx设得比物理内存还大，否则系统开始换页，转换速度反而断崖式下跌。

2.3 系统依赖对照表

Linux 服务器如果没有图形界面，Spoon 是起不来的，这时候要用pan.sh跑转换、kitchen.sh跑作业，这两个是命令行入口，部署定时任务时反而更常用。表格里磁盘那行别省，Kettle 解压后加上后续放的 JDBC 驱动和日志，1.5G 是保守估计，临时文件目录还要单独留空间。

3. 解压与目录规划：别把包随手丢在桌面

3.1 解压路径与目录结构

拿到 9.3 的压缩包后，我习惯解压到一个不带空格、不带中文的路径，比如 Windows 下D:\pdi-ce-9.3，Linux 下/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.bat，Linux 有图形环境就执行./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 还是 lib

Kettle 本身不带 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 要加useSSL=false&serverTimezone=Asia/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 的高级参数里加serverTimezone=Asia/Shanghai和useSSL=false，或者在“选项”页签里手动加这两个参数。加完重启 Spoon 再测。

5.3 转换跑一半内存溢出

现象是处理大数据量时抛java.lang.OutOfMemoryError: Java heap space。原因是默认堆内存太小，或者转换里用了“排序记录”这类全量加载内存的步骤。解决办法是调大PENTAHO_DI_JAVA_OPTIONS里的-Xmx，同时检查转换设计，能分页抽取就别一次性全拉，排序尽量交给数据库做。

5.4 中文乱码，CSV 打开是问号

现象是抽取出的文本文件中文变成乱码。原因是 JVM 默认编码不是 UTF-8，或者“文本文件输出”步骤里编码没选对。解决办法是启动参数加-Dfile.encoding=UTF-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 -level=Basic echo "退出码：$?"

-file后面跟作业文件的绝对路径，用绝对路径是为了避免 cron 里工作目录不对导致找不到文件；-level=Basic输出基础日志，排查时可以用Detailed看每一步耗时。echo $?那行是关键，退出码 0 表示成功，非 0 就要去日志里找ERROR行。定时任务里我一般把这条命令写进 crontab，日志重定向到单独文件，方便回溯。

验证清单可以按这个顺序走一遍：命令行执行退出码为 0、日志里读写行数和预期一致、目标表数据抽查几条对得上、连续跑两次不报主键冲突。这四步过了，这套 Kettle 9.3 环境才算真正落地，而不是“我这儿能打开界面”。从那以后我每次部署完 Kettle，都不看界面能不能开，而是直接拿 kitchen 跑一个最小作业，退出码对了才敢交给业务用。希望帮到你。

本文还有配套的精品资源，点击获取