简介：本资源是一份面向1–3年经验研发人员的Kettle（Pentaho Data Integration）入门级教学PPT，聚焦ETL核心流程与工具实操，帮助开发者快速掌握数据同步、转换与加载的基础能力。内容覆盖ETL概念解析、Kettle 9.2安装部署、目录结构详解、转换（Transformation）与作业（Job）的核心差异、数据库连接配置、步骤（Step）与跳（Hop）的数据流机制、元数据定义及并行处理原理，并延伸至Kafka、Avro/Parquet等现代数据源支持特性。压缩包为单个859KB的pptx文件，结构完整、图文并茂，适合作为课堂讲义或自学提纲。目前已有1465人学习下载，内容强调实践导向，要求读者具备MySQL/Oracle等数据库基础，便于结合真实场景调试与调优，切实理解Kettle优势与局限，夯实数据集成工程能力。
1. 为什么一个“只讲基础”的 Kettle PPT，反而成了我带三个毕设小组时最常翻出来的参考资料？
不是因为里面写了多少高深算法，而是它用 26 张幻灯片，把 ETL 工程里最容易被学生忽略的「执行逻辑断层」给补上了——比如：为什么你拖好了「MySQL 输入 → 字段过滤 → Oracle 输出」，一运行却卡在第一步？为什么「作业里调转换」能成功，但反过来在转换里嵌套作业就报错？为什么本地调试通了，部署到 Linux 服务器上连 JDBC 驱动都找不到？这些不是玄学，是 Kettle 的线程模型、类加载机制、路径解析规则在真实环境里的必然反馈。这份 PPT 不讲抽象理论，它从 PDI 9.2 的spoon.sh启动脚本开始拆，讲清楚每个.bat/.sh文件到底在干啥；它用一张图说清「转换是数据流并发，作业是任务流串行」这个根本区别；它甚至标出了set-pentaho-env.sh里哪一行必须改、改错会触发什么具体报错码。适合刚写完 JDBC 连接池、能手写 MyBatis 动态 SQL、但第一次面对「图形化 ETL 工具」时两眼发懵的研发新人——你不需要先成为 Java 虚拟机专家，但得知道 Kettle 在哪个环节替你封装了、又在哪留了缝让你去填。
2. 总体架构设计：PDI 9.2 的三层结构与四个核心模块职责划分
Kettle（PDI）不是单体黑匣子，它的可维护性、可调试性、可迁移性，全系于对这三层结构的理解是否到位。很多同学做完毕设答辩被问「如果目标库从 MySQL 换成达梦，你改几处？」答「重画一遍流程图」，这就是没吃透模块边界。下面这张结构图，是我带项目时白板上画过最多次的：
┌─────────────────────────────────────────────────────┐ │ 用户交互层（UI） │ │ spoon.sh/spoon.bat：启动 Swing 界面 │ │ → 加载 plugins/ 下插件（如 Kafka、Avro） │ │ → 读取 system/ 下配置（如 logging.xml） │ └─────────────────────────────────────────────────────┘ ↓（通过 classloader 加载） ┌─────────────────────────────────────────────────────┐ │ 核心引擎层（Engine） │ │ • TransformationEngine：驱动所有 Step 并发执行 │ │ • JobEntryRunner：按顺序执行 Job 中每个 JobEntry │ │ • RowSet 缓存管理：控制 hop 间数据流吞吐量 │ │ • 数据类型系统：String/Number/Date/Binary 等强类型 │ └─────────────────────────────────────────────────────┘ ↓（通过 JDBC/HTTP/FS API 调用） ┌─────────────────────────────────────────────────────┐ │ 外部连接层（Connectors） │ │ • JDBC Driver：由 lib/ 下 jar 提供，非 UI 内置 │ │ • SSH Client：依赖 jsch-*.jar，需手动放 plugins/ │ │ • JSON/XML 解析器：内置 Jackson + 自定义 Schema 映射│ └─────────────────────────────────────────────────────┘提示：PDI 9.2 的
system/kettle.properties文件里默认关闭了KETTLE_DISABLE_XML_VALIDATION=true，但如果你处理的是不规范的 XML（比如某些老系统返回的<user id="1"/>缺少闭合标签），必须显式开启该参数，否则XML Input步骤直接抛SAXParseException。这不是 bug，是设计选择——它把校验权交给了使用者。
2.1 转换（Transformation）：数据流的并发执行模型与行集（RowSet）控制
转换是 Kettle 的心脏，但它的「并发」不是无约束的多线程。关键在于RowSet—— 它是两个步骤之间唯一的通信管道，本质是一个有界阻塞队列。默认大小为 50,000 行，这个值藏在Tools → Options → Spoon → Number of rows in rowset里，但绝不能只改 UI 设置。原因如下：
# 查看当前生效的 rowset 大小（Linux 环境） $ grep -r "rowset.size" /path/to/data-integration/ # 输出示例： # system/kettle.properties:KETTLE_ROWSET_SIZE=10000 # classes/kettle-engine.properties:org.pentaho.di.trans.RowSet.size=50000这两处配置优先级不同：kettle.properties是全局覆盖，kettle-engine.properties是引擎级默认。若你只在 UI 改，而kettle.properties里写了KETTLE_ROWSET_SIZE=1000，那 UI 设置会被静默忽略。我在某高校课设中见过学生因未检查此配置，导致「CSV 输入 → 字段分割 → Excel 输出」流程在 10 万行数据时内存 OOM —— 实际是RowSet缓存溢出后，上游步骤持续写入、下游步骤无法及时消费，最终 JVM 堆被填满。
正确做法是：
① 先确认kettle.properties中无KETTLE_ROWSET_SIZE；
② 在转换设置中（右键转换空白处 → Properties → Misc）显式设置Number of rows in rowset；
③ 对内存敏感场景（如处理 1GB+ CSV），建议设为5000~10000，并勾选Execute for every input row（逐行执行模式，牺牲速度保稳定）。
2.2 作业（Job）：任务流的串行控制与错误传播机制
作业解决的是「顺序」和「分支」问题，但它不是简单的「A→B→C」。PDI 9.2 的作业执行模型有三个关键特性：
- 失败即中断：默认情况下，任一
JobEntry（如Simple Evaluation、SQL、Transformation）返回false，后续所有 JobEntry 停止执行。这与转换中「某个步骤失败，其他步骤仍可能继续」截然不同。 - 条件跳转依赖返回值：
Success/Failure/Every time三种跳转类型，其判断依据是 JobEntry 的getResult().getResult()值。例如SQL步骤执行UPDATE t SET status=1 WHERE id=?，即使影响行数为 0，只要 SQL 语法正确、连接正常，getResult()仍为true。 - 变量作用域隔离：作业内定义的变量（如
${JOB_NAME}、${Internal.Job.Filename.Directory}）不会自动透传给子转换。必须显式使用Set Variables步骤或在TransformationJobEntry 的Parameters标签页中手动映射。
下面是一个典型的数据同步作业片段，用于将 MySQL 订单表增量同步至 Hive 分区表：
<!-- job.kjb 中的关键 JobEntry 配置 --> <job-entry> <name>Check Last Sync Time</name> <type>SQL</type> <sql>SELECT MAX(update_time) FROM sync_log WHERE job_name = 'order_sync';</sql> <result_variable>last_sync_time</result_variable> </job-entry> <job-entry> <name>Run Sync Transformation</name> <type>Transformation</type> <transformation>order_sync.ktr</transformation> <parameters> <parameter> <name>START_TIME</name> <value>${last_sync_time}</value> </parameter> </parameters> </job-entry>注意：last_sync_time变量必须在SQL步骤的Result variable字段中填写，且该字段名要与后续Transformation的参数名严格一致（区分大小写）。漏填或拼错，order_sync.ktr里收到的就是空字符串，导致 SQL 查询WHERE update_time > ''全表扫描。
3. 核心模块实现：从数据库连接到数据同步的完整链路落地
这一章不贴「Hello World」式代码，只讲真实项目里必须亲手敲、亲手调、亲手压测的四个模块。它们覆盖了 90% 的毕设/课设需求：连接建立、元数据获取、增量同步、异常兜底。
3.1 数据库连接：JDBC 驱动加载路径与 Oracle/MySQL/PostgreSQL 的差异化配置
Kettle 不自带任何数据库驱动，这是它「绿色免安装」的前提，也是新手第一道坎。驱动 JAR 必须放在>步骤名：Generate Current Timestamp 步骤类型：Get System Info → Info Type: System date → Date format: yyyy-MM-dd HH:mm:ss → Target fieldname: current_time
该步骤输出单行单字段current_time，可直连至Table Output步骤写入sync_log表。优点：无外部依赖；缺点：精度为秒级，高并发下可能重复。
方案二：用SQL步骤查MAX(update_time)（推荐用于生产级课设）
-- 在 SQL 步骤中执行（注意：必须勾选 "Execute for each row" 为 false） SELECT COALESCE(MAX(update_time), '1970-01-01 00:00:00') AS last_time, NOW() AS current_time FROM order_sync_log WHERE job_name = 'order_to_hive';输出字段last_time和current_time会作为变量注入后续步骤。关键技巧：COALESCE防止首次运行时last_time为 NULL 导致整个转换中断；NOW()确保日志记录时间与数据抽取时间一致。
3.3 增量同步：基于时间戳的 CDC（Change Data Capture）实现与性能调优
这是 ETL 课设的核心得分点。PDI 9.2 的Table Input步骤支持参数化 SQL，但必须配合「参数传递」机制才能生效：
-- Table Input 步骤中的 SQL（注意：? 是占位符，非字符串拼接） SELECT id, order_no, amount, update_time FROM t_order WHERE update_time > ? AND update_time <= ?参数绑定在Table Input步骤的Parameters标签页中设置：
| Parameter # | Field name | Type |
|---|---|---|
| 1 | last_time | Date |
| 2 | current_time | Date |
避坑：
Table Input的SQL文本框里不能写${last_time}！那是变量替换语法，仅在Job的SQL步骤或Transformation的JavaScript步骤中有效。此处必须用?占位符，由 Kettle 引擎在执行时绑定。
性能调优三原则：
①索引必须建在update_time字段上（单列索引足够，无需联合索引）；
②Table Input步骤的Limit值设为0（不限制），避免分页查询导致漏数据；
③ 在Table Output步骤中，勾选Specify database fields并手动映射字段，关闭Auto commit，启用Batch update size（建议 1000），大幅降低网络往返次数。
3.4 异常兜底：用「成功/失败」跳转 + 「邮件通知」构建可观测性闭环
一个合格的 ETL 流程，必须回答三个问题：
- 是否运行了？（
Job启动日志） - 是否成功了？（
Job返回码） - 失败在哪里？（具体步骤日志）
PDI 9.2 的Mail步骤是唯一开箱即用的通知方式。配置要点：
- SMTP 服务器：用公司企业邮箱（如
smtp.exmail.qq.com:465），禁用 163/qq 免费邮箱（PDI 9.2 默认 TLS 版本不兼容）； - 认证方式：勾选
Use authentication，用户名填完整邮箱（user@domain.com），密码填授权码（非登录密码）； - 邮件内容模板（HTML 格式，提升可读性）：
<h3>【Kettle 同步告警】订单同步任务失败</h3> <p><strong>作业名称：</strong> ${Internal.Job.Name}</p> <p><strong>失败时间：</strong> ${Internal.Date}</p> <p><strong>错误步骤：</strong> ${Internal.Entry.Current.Name}</p> <p><strong>详细日志：</strong> <a href="file:///opt/kettle/logs/${Internal.Job.Name}_${Internal.Date}.log">点击查看</a></p> <hr> <p style="color:#999;font-size:12px;">此邮件由 Kettle 自动发送，请勿直接回复。</p>关键变量说明：${Internal.Entry.Current.Name}是当前失败 JobEntry 的名称，${Internal.Date}是格式化后的当前时间（需在Mail步骤的Advanced标签页中启用Use variables in message）。
4. 常见问题排查：Kettle 9.2 在 Windows/Linux/macOS 上的 5 类高频翻车现场
别再问「为什么我的转换跑不通」——先对照这五条自查。每一条都来自真实课设答辩现场的血泪经验，不是文档抄来的。
4.1 现象：spoon.sh启动报错No X11 DISPLAY variable was set
原因：Linux/macOS 服务器无图形界面，但spoon.sh默认尝试启动 Swing GUI。
解决：
① 开发阶段：用Xvfb虚拟帧缓冲（sudo yum install xorg-x11-server-Xvfb），然后Xvfb :99 -screen 0 1024x768x24 & export DISPLAY=:99 && ./spoon.sh；
② 生产阶段：彻底放弃 Spoon UI，改用pan.sh命令行运行转换：
./pan.sh -file=/home/user/job/order_sync.ktr -param:START_TIME="2024-01-01" -level=Basic -logfile=/tmp/order_sync.log4.2 现象：Table Input步骤报错ORA-00942: table or view does not exist，但 SQL Developer 里能查
原因：Oracle 用户权限不足，或未指定 schema。t_order在 DBA 用户下是DBA.t_order，但当前连接用户无权限访问DBA.*。
解决：
① 在Database Connection中，Default Schema字段填你的用户名（如SCOTT）；
②Table Input的 SQL 改为SELECT * FROM SCOTT.t_order WHERE ...；
③ 或在 Oracle 中执行GRANT SELECT ON SCOTT.t_order TO your_user;。
4.3 现象：JSON Input步骤解析{ "data": [ { "id": 1 }, { "id": 2 } ] }，只取到第一条
原因：PDI 9.2 的JSON Input默认只解析顶层字段，数组需显式展开。
解决：
①JSON Input步骤 →Fields标签页 →Path列填$.data[*]（[*]表示遍历数组）；
②Name列填id，Type选Integer；
③ 勾选Repeat（否则只取第一个对象的id）。
4.4 现象：SSH步骤执行sh /opt/script/sync.sh成功，但脚本里的mysql -u root -p123456 -e "..."报Access denied
原因：SSH 登录的是非交互式 shell，.bashrc未加载，导致mysql命令未找到，或密码被 shell 解析错误。
解决：
① 将mysql命令改为绝对路径/usr/bin/mysql；
② 密码不要写在命令行（安全风险），改用配置文件：
# 在目标服务器创建 ~/.my.cnf [client] user=root password=123456 host=localhost③SSH步骤中执行sh -l -c "/opt/script/sync.sh"（-l表示 login shell，加载环境）。
4.5 现象：Carte集群模式下，远程调用kitchen.sh执行作业返回401 Unauthorized
原因：Carte 默认启用 Basic Auth，但kitchen.sh未传凭据。
解决：
① 启动 Carte 时指定用户：./carte.sh carte-config.xml --user=admin --password=password；
②kitchen.sh命令中加入-rep（Repository）参数指向 Carte 地址，并用-user/-pass传参：
./kitchen.sh -file=/home/user/job/order_sync.kjb -rep=http://192.168.1.100:8080/kettle -user=admin -pass=password5. 毕设/课设验收与答辩：用「三张表 + 一次压测」让导师当场点头
答辩不是讲 PPT，是证明你真的跑通了、调优了、扛住了。我带过的项目，凡用这套方法的，90% 一次性通过。核心就三点：可验证的日志、可复现的压测、可追溯的变更。下面这张「验收证据包」清单，就是你答辩时打开笔记本直接展示的内容。
5.1 日志验证表：证明流程真实执行且结果可信
| 日志类型 | 存放位置 | 关键验证点 | 达标标准 |
|---|---|---|---|
| 转换日志 | pan.sh指定的-logfile路径（如/tmp/order_sync.log） | 搜索Finished processing和Errors: 0 | 必须存在，且Errors为 0，Lines read/written数值合理（如 10 万行数据，Lines written应 ≈ 100000） |
| 作业日志 | kitchen.sh的-logfile路径 | 搜索Job has ended和Result=[true] | Result=[true]表示作业整体成功，Result=[false]即使某步骤失败也会出现 |
| Carte 集群日志 | carte.log（同级目录） | 搜索Started on port 8080和Received request | 证明集群服务已就绪，且接收到了远程调用请求 |
实操技巧：答辩前 1 小时，用
tail -f /tmp/order_sync.log实时监控日志滚动，当看到Finished processing瞬间截图——这张图比任何 PPT 都有说服力。
5.2 压测对比表：用真实数据量证明调优价值
别信「理论上很快」，拿数字说话。以下是我要求所有学生必须做的最小压测（数据源：本地 MySQL，目标：同一台机器的 Hive）：
| 数据量 | 未调优配置（默认） | 调优后配置 | 性能提升 | 关键调优点 |
|---|---|---|---|---|
| 10 万行 | 218 秒 | 89 秒 | 2.45× | RowSet size=5000+Batch size=1000+Disable auto-commit |
| 100 万行 | 内存溢出（OOM） | 742 秒 | 稳定运行 | 增加 JVM 参数-Xms2g -Xmx4g，RowSet size=2000 |
注意：压测必须在同一台机器、关闭其他应用、用
time ./pan.sh ...命令精确计时。time输出的real时间才是真实耗时。
5.3 变更追溯表：让导师一眼看清你的工程能力
导师最怕「代码是抄的，改了哪不知道」。这张表必须手写（或用 Git log 生成），放在答辩 PPT 最后一页：
| 修改日期 | 模块 | 修改内容 | 解决问题 | 验证方式 |
|---|---|---|---|---|
| 2024-03-15 | 连接配置 | 将 MySQL JDBC URL 从useSSL=true改为useSSL=false&allowPublicKeyRetrieval=true | 解决Access denied连接失败 | Test connection按钮变绿 |
| 2024-03-18 | 增量逻辑 | Table InputSQL 从WHERE update_time > '2024-01-01'改为WHERE update_time > ?，并绑定last_time参数 | 实现真正的增量同步 | 对比两次运行sync_log表中last_time字段值 |
| 2024-03-20 | 性能调优 | Table Output步骤启用Batch update size=1000，关闭Auto commit | 10 万行耗时从 218s 降至 89s | time命令实测 |
从那以后我每次带毕设，都会强制学生在开题报告里附上这张表的初稿，并在每次迭代后更新。不是为了应付检查，是逼自己养成「改一行，记一行，验一行」的工程师习惯。希望帮到你。
本文还有配套的精品资源，点击获取
