☰
Kettle 9.3 实战:从百度云部署到数据迁移避坑指南
2026/10/17 14:10:07 网站建设 项目流程

简介:这份资源面向数据工程师、ETL开发初学者及需要搭建数据集成流程的技术人员,提供Kettle(Pentaho Data Integration)9.3版本的获取渠道。Kettle是一款纯Java编写的开源ETL工具,支持Windows、Linux、Unix多平台运行,通过Spoon图形化界面以拖拽方式设计Transformation与Job,实现跨数据库的数据抽取、清洗、转换与工作流调度,并可与云计算平台集成。资源包内共1个docx文档,压缩包约14KB,文档中整理了Kettle核心特性、两类脚本文件说明、9.3版本更新亮点及百度云下载链接与提取码,便于读者快速定位安装包并了解版本变化。目前已有5724人学习下载,适合希望系统认识Kettle、获取最新版本安装资源并用于实际数据集成项目的读者参考。

1. 从一次数据迁移翻车说起:Kettle 9.3 到底能干什么

去年帮一个做电商的朋友处理订单数据迁移,源库是 MySQL,目标库是 PostgreSQL,中间还要做字段清洗、空值填充、时间格式统一。他一开始想让我写 Python 脚本,我看了下需求,大概二十几个转换逻辑,还要定时跑、失败重试、发邮件告警。写脚本不是不行,但维护成本太高,改一个字段就得动代码。后来我直接上了 Kettle,拖了十几个组件,半天搞定,后面他运营自己就能改流程。

Kettle 就是干这个的——ETL 工具,中文叫水壶,纯 Java 写的,Windows、Linux、Unix 都能跑。它的核心价值在于:把数据抽取、转换、加载这件事从代码里解放出来,变成可视化流程。你不需要写SELECT * FROM然后INSERT INTO,而是拖一个「表输入」、拖一个「表输出」,中间想怎么清洗就怎么连。对于需要频繁调整的数据管道,这种图形化方式省下来的时间不是一点半点。

这次要聊的是 Kettle 9.3 版本,社区里常说的 PDI(Pentaho Data Integration)。网上流传的百度云资源包,我拿到手拆了一遍,下面把安装、配置、核心概念、实际跑通一个转换的完整过程,以及我踩过的坑,全部摊开讲。如果你手头正好有数据同步、数据清洗、异构数据库迁移的活,这篇能让你少走弯路。

2. 拆开百度云里的 Kettle 9.3:目录结构与运行环境

2.1 资源包里到底有什么

从百度云拿到的 Kettle 9.3 压缩包,解压后大概 1.2GB 左右,目录结构跟官方发行版一致。核心目录我列一下,方便你对照:

目录/文件作用
>set JAVA_HOME=C:\Program Files\Java\jdk1.8.0_301 set PATH=%JAVA_HOME%\bin;%PATH%

Linux 下改Spoon.sh,在#!/bin/sh后面插入:

export JAVA_HOME=/usr/local/jdk1.8.0_301 export PATH=$JAVA_HOME/bin:$PATH

改完之后,命令行执行java -version确认输出的是你指定的版本。这一步不做,后面连数据库时可能报No suitable driver found,你以为是驱动没放对,其实是 Java 版本冲突导致的类加载问题。

2.3 内存参数:默认配置跑小数据没事,上量就 OOM

Kettle 默认给 JVM 分配的内存偏保守,Spoon.bat里有一行PENTAHO_DI_JAVA_OPTIONS,默认大概是-Xms1024m -Xmx2048m。如果你要处理几十万行以上的数据,或者做多表关联,这个值不够用。

我一般改成:

PENTAHO_DI_JAVA_OPTIONS="-Xms4096m -Xmx8192m -XX:MaxPermSize=512m"

-Xms是初始堆大小,-Xmx是最大堆,-XX:MaxPermSize在 JDK 8 里控制永久代大小。JDK 11 及以上没有永久代,这个参数要去掉,换成-XX:MaxMetaspaceSize=512m。改完重启 Spoon,在「帮助」→「关于」里能看到当前 JVM 内存配置。

3. 用 Spoon 跑通第一个 Transformation:从 CSV 到数据库

3.1 新建转换与数据库连接配置

打开 Spoon 之后,先新建一个「转换」(Transformation),然后配置数据库连接。Kettle 支持两种连接方式:JDBC 直连和 JNDI。JDBC 直连适合临时测试,JNDI 适合生产环境统一管理。

JDBC 直连的配置路径是:左侧「主对象树」→「DB连接」→ 右键「新建」。关键参数如下:

参数说明示例
连接名称自定义标识mysql_order_db
连接类型数据库类型MySQL
主机名称IP 或域名192.168.1.100
数据库名称具体库名order_center
端口号数据库端口3306
用户名登录账号etl_user
密码登录密码******

配完之后点「测试」,如果报Access denied,先确认账号密码;如果报Communications link failure,检查防火墙和端口。测试通过后,Kettle 会自动把驱动类名填上,MySQL 8 以上要用com.mysql.cj.jdbc.Driver,老版本用com.mysql.jdbc.Driver,这个细节后面避坑章节会展开。

3.2 设计一个完整的转换流程

假设我们要把一个 CSV 文件里的订单数据,清洗后写入 MySQL。CSV 字段包括:订单号、用户ID、金额、下单时间。需求是:过滤掉金额为空的记录,把下单时间从yyyy/MM/dd转成yyyy-MM-dd,然后入库。

在 Spoon 画布上拖四个组件:

  1. CSV 文件输入:读取源文件
  2. 过滤记录:剔除金额为空的行
  3. 字段选择:做时间格式转换
  4. 表输出:写入 MySQL

连接顺序是:CSV输入 → 过滤记录 → 字段选择 → 表输出。每个组件双击配置,CSV 输入里指定文件路径和分隔符,过滤记录里设置条件金额 IS NOT NULL,字段选择里用「元数据」标签页修改时间字段的格式,表输出里选好目标库和表名。

配置完成后,点画布上方的「预览」按钮,可以逐步骤查看数据流。确认无误后点「运行」,Spoon 会弹出执行结果窗口,显示读写行数、执行时间、错误数。

3.3 命令行执行:Pan 和 Kitchen 的用法

图形界面适合开发和调试,生产环境一般用命令行。Transformation 用Pan,Job 用Kitchen。

# Linux 下执行转换 ./pan.sh -file:/data/etl/order_transform.ktr -level:Basic # Windows 下执行作业 Kitchen.bat /file:D:\etl\daily_job.kjb /level:Detailed

参数说明:-file指定脚本文件路径,-level控制日志级别,可选Basic、Detailed、Debug、Rowlevel。Rowlevel会打印每一行数据,调试时用,生产环境千万别开,日志能把磁盘写满。

执行结果会输出到控制台,同时可以在logs/目录下找到日志文件。如果返回码是 0,表示成功;非 0 就是有错误,具体看日志里的ERROR行。

4. 避坑指南:Kettle 9.3 部署与运行中的五个高频问题

4.1 启动 Spoon 闪退,没有任何报错

现象:双击Spoon.bat,窗口一闪而过,命令行执行也看不到错误信息。

原因:最常见的是 Java 环境变量没配好,或者JAVA_HOME指向了 JRE 而不是 JDK。Kettle 编译 JSP 和某些插件时需要 JDK 里的tools.jar,JRE 没有这个文件。

解决:确认JAVA_HOME指向 JDK 安装目录,且%JAVA_HOME%\lib\tools.jar存在。如果用的是 JDK 11 以上,tools.jar已经移除,需要额外加--add-opens参数,在Spoon.bat的PENTAHO_DI_JAVA_OPTIONS里追加:

--add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED

4.2 连接 MySQL 8 报驱动类找不到

现象:测试数据库连接时提示No suitable driver found for jdbc:mysql://...。

原因:Kettle 9.3 自带的 MySQL 驱动版本较老,不支持 MySQL 8 的caching_sha2_password认证插件。另外,驱动 jar 包没有放到lib目录下。

解决:去 MySQL 官网下载mysql-connector-java-8.0.xx.jar,放到>0 2 * * * export JAVA_HOME=/usr/local/jdk1.8.0_301 && export PATH=$JAVA_HOME/bin:$PATH && /data/etl/kitchen.sh -file:/data/etl/job.kjb >> /data/etl/logs/cron.log 2>&1

把标准输出和错误输出都重定向到日志文件,出问题时有据可查。

5. 进阶技巧:用 JNDI 统一管理连接与参数化配置

5.1 JNDI 连接配置:让转换文件不再裸奔

JDBC 直连的问题是,数据库密码明文写在.ktr文件里,一旦文件泄露,密码就暴露了。而且多个转换用同一个库时,改密码要一个个改。JNDI 就是解决这个问题的。

在>mysql_order_db/type=javax.sql.DataSource mysql_order_db/driver=com.mysql.cj.jdbc.Driver mysql_order_db/url=jdbc:mysql://192.168.1.100:3306/order_center?useSSL=false&characterEncoding=utf8 mysql_order_db/user=etl_user mysql_order_db/password=your_password

然后在 Spoon 里新建数据库连接时,连接类型选「JNDI」,名称填mysql_order_db。这样转换文件里只存 JNDI 名称,不存密码。迁移环境时,只改jdbc.properties就行。

5.2 参数化:用变量替换硬编码路径和日期

Kettle 支持在转换和作业里使用变量,变量可以在启动时通过命令行传入,也可以写在kettle.properties文件里。

在转换里,字段值可以用${变量名}引用。比如表输入 SQL 里写:

SELECT * FROM orders WHERE create_time >= '${START_DATE}' AND create_time < '${END_DATE}'

启动时通过Pan传入:

./pan.sh -file:/data/etl/order_transform.ktr -param:START_DATE=2024-01-01 -param:END_DATE=2024-02-01

这样同一个转换文件可以跑不同时间段的数据,不用改脚本。我一般会把日期变量和文件路径变量都抽出来,配合调度工具传参,灵活性提升很明显。

5.3 验证方法:用「检查」和「统计」步骤做数据质量校验

转换跑完之后,怎么确认数据没问题?我习惯在流程末尾加两个步骤:一个「统计」步骤,统计读写行数;一个「检查」步骤,校验关键字段是否为空。

「统计」步骤可以输出written、read、updated、errors四个指标,跟源数据行数对比,差太多就说明中间有过滤或异常。「检查」步骤可以设置多个校验规则,比如「订单号不能为空」「金额必须大于 0」,校验失败的行会走错误分支,可以单独输出到错误文件。

这两个步骤加上之后,每次跑完转换,看一眼统计数字和错误行数,心里就有底了。从那以后我每次部署新转换,都强制走一遍「预览 → 统计 → 检查」三步,再也没出现过数据写了一半才发现字段对不上的情况。

希望帮到你。

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

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询