企业官网建设流程全解析

简介：Kettle 9.3（PDI CE 9.3.0.0-428）是面向数据集成场景的开源 ETL 工具包，纯 Java 编写，支持 Windows/Linux/Unix，绿色免安装，适合数据抽取、转换与加载的日常开发与学习。由于单文件超过 1000MB，作者将其拆分为两部分分卷压缩，当前文件为第二部分，需与第一部分合并后解压使用。压缩包内共 2000 个文件，约 799.81MB，核心类型包括 jar（Java 运行库）、ktr/kjb（转换与作业定义）、xml/cfg/properties（配置信息）、bat/sh（启动及辅助脚本），以及少量 xlsx/csv 示例数据，整体符合 Kettle 安装目录结构，便于按需检索。包内已内置 JRE，配合第一部分解压后可直接运行 spoon.bat，免去单独配置 Java 环境的步骤，可帮助读者快速搭建 ETL 环境、研究作业调度或进行数据清洗与迁移练习。目前已有 837 人学习下载，作为 Kettle 9.3 分卷包之一，具有较高的参考与复用价值。 最近又有不少朋友在群里问 Kettle 9.3 怎么装、怎么配驱动、怎么读 API，我想着与其一个个回答，不如把这次基于 pdi-ce-9.3.0.0-428 这个版本从头到尾的实操过程整理出来。标题虽然是“压缩包2”，但本质上我们要解决的是同一个问题：拿到 Kettle 9.3 的安装包之后，怎么把它跑起来，怎么把日常最常用的几个场景做顺。

这篇内容适合刚接触 Kettle 的人照着做，也适合已经在用 8.x/9.2 但想升级到 9.3 的老手快速避坑。我会先讲版本选择和安装细节，再讲数据库迁移、API 分页读取、动态 SQL、字段校验这几个高频场景，最后把常见的坑统一列出来。内容全部基于 pdi-ce-9.3.0.0-428 这个具体版本，不会泛泛而谈。

1. 版本背景与选型思路：为什么是 pdi-ce-9.3.0.0-428

1.1 这个版本的定位与核心价值

Kettle 的官方名称是 Pentaho Data Integration（简称 PDI），社区版压缩包命名规则是 pdi-ce-版本号-内部构建号。pdi-ce-9.3.0.0-428 代表这是 9.3.0.0 这个发布线下的第 428 个构建，属于 9.3 系列里比较稳定的发行快照，后续不会再有大改动。9.3 在功能上比 8.x 多了一大截，尤其是对 JSON 格式的处理、API 对接组件、以及性能监控面板，这些在数据同步、接口抽取场景里非常实用。

正因为 9.3 是一个功能完整且生态成熟的版本，很多企业做数据平台选型时都会固定在这个版本上。它同时支持 Java 8 和 Java 11，不像 10.x 那样强制要求高版本 JDK，也不像 8.x 那样缺不少新组件。如果你需要在生产环境跑定时任务、做多数据源迁移，pdi-ce-9.3.0.0-428 是一个投入产出比很高的选择。

1.2 版本选型对比：9.2、9.3、10.x 到底怎么挑

我见过不少人盲目追新，直接上 10.x，结果发现第三方驱动兼容性出问题，又灰溜溜退回 9.x。这里把几个常见版本放在一起对比，方便你做判断：

从表格能看出来，9.3 处在“功能全”和“踩坑少”的平衡点上。这次我用的 pdi-ce-9.3.0.0-428 在 9.3 系列里属于成熟构建，你从官网或镜像站拿到这个压缩包后，解压即可用，不需要额外破解或授权，这是社区版最大的优势。

2. 安装前的关键准备：JDK、解压与启动配置

2.1 JDK 版本：先把最容易翻车的坑填平

Kettle 9.3 官方推荐 Java 8 或 Java 11，但这里有个细节：Oracle JDK 8 和 OpenJDK 8 都可以，不过建议优先用 OpenJDK 11，因为 9.3 对 Java 11 的支持更完善，长时间跑作业时内存管理更好。千万不要用 Java 17 或更高版本直接跑 pdi-ce-9.3.0.0-428，我实测会直接报UnsupportedClassVersionError，因为 Kettle 9.3 的很多类库还没针对高版本 JDK 重新编译。

安装好 JDK 后，检查一下环境变量。在命令行执行java -version，确认输出里显示的版本是 1.8 或 11。如果电脑上装了多个 JDK，建议在启动 Kettle 前，先在当前终端里临时指定 JAVA_HOME，避免系统 PATH 指向错误版本：

# Windows 临时指定 set JAVA_HOME=C:\Program Files\Java\jdk-11.0.20 set PATH=%JAVA_HOME%\bin;%PATH% # Linux / macOS 临时指定 export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 export PATH=$JAVA_HOME/bin:$PATH

这里踩过的坑是：有人明明装了 JDK 11，但系统 PATH 里还有旧版 JDK 8 的 bin 目录，结果 Kettle 启动时用的是旧版本，导致某些组件行为异常。所以安装前先确认java -version输出，是最简单也最关键的一步。

2.2 解压、目录结构与首次启动

解压 pdi-ce-9.3.0.0-428 压缩包时，我建议把路径选在纯英文目录下，比如D:\pdi\data-integration或/opt/pdi/data-integration，绝对不要放在带中文或空格的路径里，否则后面配置数据库驱动、跑作业时可能出现莫名其妙的路径解析问题。

解压完成后，进入>PENTAHO_DI_JAVA_OPTIONS="-Xmx4096m -Xms1024m -XX:MaxMetaspaceSize=512m"

-Xmx4096m表示最大堆内存 4GB，如果你的机器内存是 8GB 以上，这个值可以调成 6144m 或 8192m。注意是修改Spoon.bat里对应的行，不是在系统环境变量里随便加。Linux 下改spoon.sh里的PENTAHO_DI_JAVA_OPTIONS同样效果。

我建议在开始做任何复杂作业之前，先把这个参数调好，否则后面跑大表同步时频繁 GC 或直接内存溢出，特别影响效率。

3. 核心实操：数据库迁移、API 分页读取与动态场景

3.1 让 Kettle 9.3 连接 MySQL、达梦、taos 的驱动配置经验

之前有热搜词提到“kettle 支持 taos 数据库迁移到 mysql”和“kettle 连接达梦”，这两个都是数据迁移里的典型需求。Kettle 9.3 自带的lib目录里只有一些基础驱动，比如旧的 MySQL 驱动、PostgreSQL 驱动，但连接达梦、taos 这种数据库，必须手动把 JDBC 驱动 jar 包放进>SELECT * FROM ${tableName} WHERE create_time >= '${startTime}'

然后在转换里通过“获取变量”或“设置变量”步骤来给tableName和startTime赋值。但有个容易被忽略的选项，在“表输入”步骤的底部，有一个“替换 SQL 语句里的变量”复选框，必须勾选上，变量才会被真正替换。如果不勾，Kettle 会把变量当普通字符串发给数据库，结果就是 SQL 语法错误。

动态 SQL 的进阶用法是结合 JavaScript 步骤拼接 SQL，比如根据入参判断查询条件：

var sql = "SELECT * FROM t_order WHERE 1=1 "; if (startTime != null && startTime != "") { sql += " AND create_time >= '" + startTime + "'"; }

然后把sql字段传给表输入的 SQL。注意，用这种方法时，SQL 里的字段名和表名必须信任可控，否则会引入 SQL 注入风险。如果只是内部数据处理，问题不大，但对外部输入要格外小心。

再讲字段校验组件。Kettle 9.3 里有一个“Validator”步骤（有的汉化版叫“校验”），就是热搜词里说的“检验字段的值组件”。它可以对一行的字段做空值检查、类型检查、范围检查等。比如要校验用户输入的年龄必须是 18 到 60 之间的数字，可以这样配置：

• 在 Validator 步骤里添加一个校验规则，选择字段age。
• 校验类型选“Number range”，填最小值 18、最大值 60。
• 错误处理可以选“丢弃错误行”，也可以把错误信息写入某个字段，方便后续排查。

实际使用中，我习惯在数据入库前加一个 Validator 步骤，专门检查关键字段是否为空、日期格式是否正确。这样可以把脏数据在源头拦下来，而不是等报错再去翻日志。不过要注意校验步骤的性能，如果数据量很大，建议只在关键字段上做必要校验，不要一口气配几十条规则，否则会拖慢整个转换。

4. 常见问题排查与避坑记录

4.1 启动与连接层面的高频故障

我把这段时间群里问得最多的问题整理成了表格，每一条都是真实遇到过的情况：