Kettle入门实战：从零完成CSV到数据库的ETL转换

Kettle这个词，在搞数据的圈子里几乎就是ETL的代名词。哪怕这两年各种云上数据集成服务、大数据平台把数据同步包装得再花哨，很多公司内部跑得最稳的报表、数仓、接口对接，底子还是Kettle——也就是PDI（Pentaho Data Integration）。说白了，你手里有一堆Excel、CSV、各类数据库表，每天要做合并、清洗、格式转换、导入导出，Kettle就是那个能让你少写几百行代码的图形化工具。这个系列我计划从零开始写，今天这篇是第一篇，重点解决三件事：Kettle到底解决了什么问题、怎么把它装好跑起来、以及如何用拖拽的方式做出第一个把CSV导入数据库的转换。适合刚接触数据的业务分析师、运维同学，以及想从脚本里解放出来的开发者。

1. Kettle到底是什么，为什么到现在还有大量公司在用

1.1 ETL这件事，过去是怎么干的

ETL是Extract、Transform、Load的缩写，翻译成人话就是：从数据源取数、按业务规则做清洗和转换、最后写入目标存储。在Kettle这类工具普及之前，做这件事的主流方式无非三种：写Python脚本、写SQL存储过程、写Java定时任务。

写脚本灵活度高，但问题在于：脚本散落在各个服务器上，谁也说不清哪个脚本负责哪条链路；Python环境升级了，某个脚本可能就挂了；字段格式变了，脚本直接抛异常，没人第一时间知道。SQL存储过程的管理相对集中，但跨数据库迁移时语法差异让人头疼，而且逻辑稍微复杂一点，嵌套的SQL能写到一千行，后期维护的人心里只剩问候。Java定时任务稳定、可控，但对维护者的开发能力要求高，一个报表需求下来，可能得写一整天代码。

我当时第一次接触Kettle，是在某公司的数据组做报表对接。对方丢过来一个zip包，说"用这个工具，今天下班前把那个订单表的导入跑起来"。从没见过Kettle的我也没多想，解压、点开Spoon界面、拖了几个组件、跑了二十分钟，目标表里就已经有数据了。那个下午我印象很深：原来ETL这件事，不一定非要写代码。

1.2 Kettle解决的核心痛点

Kettle把ETL抽象成一堆可以在画布上拖拽的"步骤"（Step），每个步骤负责单一功能：读文件、查数据库、做字段计算、去重、排序、写表等等。步骤之间用"跳"（Hop）连接起来，构成一条数据流。它真正解决了几个核心痛点：

• 上手门槛低：不需要懂编译，不需要会设计模式，拖拽组件、填配置就能跑通一条数据链路。
• 跨库能力好：同一个转换里可以同时连接MySQL、Oracle、SQL Server、PostgreSQL，甚至文本文件、Excel、接口返回的JSON，数据在不同来源之间流转非常自然。
• 可视化排错：每一步都可以单独预览数据，哪一步出了问题一眼就能看到，不像脚本那样只能靠日志猜。
• 部署维护简单：写好一个转换或作业，既可以放在本机跑，也能导成脚本交给调度平台定时执行，运维成本很低。

1.3 PDI和Kettle的名字为什么总混着叫

很多新手会困惑：有人说Kettle，有人说PDI，还有人叫Pentaho，到底是不是同一个东西？

说句实在的，它们指的是同一个工具的不同时期叫法。早期这个开源项目叫Kettle，后来被商业化公司收购，产品改名成了PDI（Pentaho Data Integration），但社区版和很多老资料仍然沿用Kettle这个名字。你在网上搜"Kettle教程""PDI教程"，内容基本可以互相参考，不用太纠结。下载的时候官方现在一般叫"Pentaho Data Integration"，社区里习惯叫Kettle，认准Spoon这个图形界面就没跑。搞清楚这点，能帮你少浪费不少找资料的时间。

2. 装好、能跑：从JDK到Spoon窗口的完整准备过程

2.1 版本选择里最常见的翻车点

我见过太多人卡在安装这一步，原因不是操作问题，而是JDK版本和Kettle版本不匹配。Kettle本身是Java写的，它依赖特定版本的JDK运行，装错了直接启动失败，报错信息还特别隐晦。

我的建议是：

• 用Kettle 8.2或8.3，配JDK 8。这个组合最经典，网上教程资料最多，各种数据库驱动兼容性也最好。
• 用Kettle 9.x，配JDK 11。新版界面稍微好看一点，但遇到的部分插件可能还是按老版本习惯走的，需要自己绕一些坑。
• 用Kettle 10.x，配JDK 17。最新版功能完善，但对新手不算友好，驱动和插件的兼容问题也更多。

如果你想快速上手，我实际推荐Kettle 8.3配JDK 8，踩坑成本最低。先跑通全流程，再考虑要不要升级版本，这是最务实的路径。

2.2 下载、解压与目录结构

下载下来的包通常是一个zip，解压后会看到一个名为>PENTAHO_DI_JAVA_OPTIONS="-Xms1024m -Xmx2048m -XX:MaxPermSize=256m"

如果你机器内存够大，可以改成：

PENTAHO_DI_JAVA_OPTIONS="-Xms1024m -Xmx4096m -XX:MaxPermSize=512m -Dfile.encoding=UTF-8"

-Xmx决定了JVM能用的最大堆内存，处理大文件时特别关键。-Dfile.encoding=UTF-8是保证控制台日志和读取文本文件时的默认编码是UTF-8，能少很多乱码问题。改完保存，重新启动Spoon就生效了。

3. Kettle的三个核心概念，搞懂它们才能不迷路

3.1 转换（Transformation）：流水线模型

Kettle里最核心的东西是"转换"。每个转换里可以放多个步骤，步骤之间用Hop连线，数据就像流水线上的零件，从一个工位流向下一个工位。最重要的特点是：转换里的数据是流式和并行处理的，每个步骤拿到数据后边处理边向下传，不是等全部读进来再统一加工。正因为这样，几十万行数据在转换里跑起来也很快，因为内存里同一时刻只保留一小部分数据。

举个例子，一个最简单的转换可以是"CSV文件输入 -> 字段过滤 -> 文本文件输出"。CSV输入逐行读，过滤步骤逐行判断，文本输出逐行写，三个步骤几乎同时在干活。

转换解决的问题是"单条数据怎么变"，它适合做数据加工，但不适合做流程编排。

3.2 作业（Job）：做决策的老板

如果说转换是流水线，那作业就是安排流水线的老板。作业是面向"任务流程"的：先执行一个转换、成功了就给指定邮箱发邮件、失败了就写一条日志再重跑，这些都靠作业来编排。

作业里的组件叫"作业项"，常见的有：转换、SQL脚本、发送邮件、复制文件、检查文件是否存在、Javascript等。作业项之间靠连线决定执行顺序，连线上还可以设置成功/失败的条件连接，形成条件分支。

一个典型作业的流程是：检查今天的文件是否到达 -> 到了就执行转换导入数据 -> 导入成功发邮件通知 -> 导入失败触发告警脚本。

搞不清转换和作业的区别，是新手最开始最容易犯的混淆。一张表帮你分清楚：

注意：作业本身不处理数据，它只负责"指挥"。真正干活的还是它调用的那些转换。

3.3 资源库（Repository）：保存你的工作成果

每次新建的转换和作业，如果不主动保存，关闭Spoon就没了。保存的地方叫资源库，有两种最基本的类型：文件资源库和数据库资源库。

文件资源库就是把所有内容存成本地的XML文件，好处是简单、离线可用、不怕数据库挂掉，适合单人或小团队。数据库资源库是把所有内容保存在数据库表里，适合多人协作，谁都能看到同一套最新版本。

新手阶段我建议直接用文件资源库，路径选一个好找的目录，每个转换保存成独立的.ktr文件，每个作业保存成.kjb文件。这种文件可以拷贝、可以交给同事、也可以放进版本管理工具里做备份，最灵活。数据库资源库虽然协作方便，但里面关系表很多，出问题后处理起来麻烦，等你有经验了再用不迟。

3.4 变量与命名参数

写死的文件路径和数据库连接串，在测试环境和生产环境切换时要一个个改，特别容易漏。Kettle支持用${变量名}的方式引用环境变量或自定义参数。

Spoon右上角可以设置环境变量，转换里也可以定义命名参数。比如文件路径写成D:/data/${report_date}/order.csv，运行转换时通过命令行传入report_date=20250420，就能自动切换到对应日期的文件。这个习惯值得一开始就养成，否则后面做定时调度会很痛苦。

4. 动手做第一个转换：把一个CSV变成数据库表

4.1 先说要干什么：一个真实的订单导入场景

假设你现在遇到一个实际的业务需求：某部门每天会导出一个订单明细的CSV文件，字段包括订单号、下单时间、订单金额、订单状态，大概几万行。你需要把它清洗一遍，过滤掉状态为"已取消"的记录，然后导入MySQL数据库的表里，供报表系统使用。

第一步肯定不是在Kettle里乱拖，而是先在纸上理一遍数据流向：

• 读取CSV原始数据
• 把金额字段从字符串转成数字
• 过滤掉"已取消"的订单
• 只保留我们关心的几个字段
• 写入数据库

这个思路跟写程序一模一样，只是现在用Kettle把它可视化出来。

4.2 新建转换和CSV文件输入组件

打开Spoon，在菜单里选"文件 -> 新建 -> 转换"，画布就出来了。左侧的"核心对象"面板里找到"输入"分类，拖一个CSV文件输入到画布上。

双击组件开始配置：

1. 文件路径：填CSV的实际路径，比如D:/data/order_20250420.csv。
2. 分隔符：多数CSV是逗号，如果你的文件是别的符号就对应改。
3. 编码：这里选UTF-8，关于乱码问题后面有专门的坑要讲。
4. 点"获取字段"按钮，Kettle会自动读文件头几行，把字段名列出来，你只需要确认类型对不对。

这里有个非常实用的心得：能点"获取字段"就不要手动敲字段。自动识别又快又准，还不会漏掉字段。识别出来以后，把所有字段的"类型"检查一遍，金额类字段如果读成了String，后面可以靠另一个步骤改，也可以在这直接改。

配置完后先点"预览"按钮，能直接看到这个步骤产生的前100行数据。预览是Kettle最值钱的功能之一，每步都能预览，意味着你可以在每个环节确认数据长什么样，而不是最后跑完才发现问题。

4.3 数据清洗：字段选择、过滤、值映射

CSV读进来以后，先做字段整理。从"转换"分类里拖一个字段选择组件，连到CSV输入后面。双击后，可以把不要的字段从右侧"删除"列表里移除，也可以在"元数据"标签里修改字段名称和类型。金额字段如果没有被正确识别成数值，在这里把它改成BigDecimal或Number类型更稳妥。

接下来是过滤规则。拖一个过滤记录组件，连在字段选择后面，双击配置条件：比如筛选订单状态不等于"已取消"的记录。条件表达式可以点"编辑"按钮生成，不用手写语法，选择字段、选择运算符、填上比较值就行。

如果你还需要做更灵活的映射，比如把"待发货""已发货"统一成"处理中"，可以用值映射组件。这些都是非常基础的转换组件，组合起来已经能解决大部分清洗需求。

4.4 数据库连接和表输出

清洗完数据，要写进MySQL。先把MySQL的JDBC驱动jar包（mysql-connector-java-xxx.jar）拷贝到Kettle的lib目录下，然后重启Spoon。这一步经常有人忘，驱动没放进去，后面配置数据库连接时怎么都测试不通过。

完成驱动部署后，在左侧"输出"分类里拖一个表输出组件，连线接在过滤记录后面。双击配置：

1. 连接按钮右边点"新建"，选择MySQL类型，填入主机名、端口（默认3306）、数据库名、用户名、密码。
2. 点"测试"按钮，提示连接成功后保存。
3. 目标表里填你要写入的表名，比如ods_order。
4. 如果表还不存在，可以切换到"SQL"标签页，让Kettle根据你流里的字段生成建表语句，确认后执行。

表输出组件还有个关键参数是"批量插入大小"，默认值可能较小。如果数据量很大，可以适当调大，比如设置成1000或2000，写入速度会有肉眼可见的提升。事务方面，建议勾选"忽略错误"的选项时谨慎一点，生产环境宁可报错也不要静默丢数据。

4.5 运行、预览与排错

配置完成后，点击画布上方的"运行"按钮，选择"本地执行"，Kettle就开始跑。跑的过程中每个步骤旁边会有行数统计：读了多少行、过滤掉多少行、写了多少行，一目了然。

如果中间某个步骤报错，日志面板里会显示具体是哪一步、什么样的异常。最常见的是类型转换错误，比如某一行数据里金额字段出现了一个空字符串或者特殊符号，转数字时失败。解决办法看你业务场景：可以用数据校验组件提前把异常数据分流，也可以用过滤记录先把脏数据拦掉，总之不要让异常数据直接打到报错那一层。

跑完之后去数据库里SELECT COUNT(*)验证一下行数，再随机抽几行看字段值是否正确，这就算完成了一个完整的Kettle转换。

5. 新手最容易踩的几个坑，我替你踩过了

5.1 中文乱码到底是谁的锅

乱码是新手报错率最高的问题，而且一旦乱码，数据基本就不能用了。关键是：乱码可能发生在三个环节，任何一个不对，最终结果就是一堆问号。

• CSV文件本身的编码：很多Windows环境下导出的CSV是GBK编码，不是UTF-8。用记事本另存为或先看一眼文件编码，明确真正的编码。
• Kettle读取组件里的"编码"选项：必须跟文件实际编码一致。文件是GBK，组件里却选UTF-8，读进来就是乱码；反过来的情况也一样。
• 数据库连接编码：MySQL连接串上要加characterEncoding=utf8，同时表和库的字符集也要是utf8mb4或utf8。

排查乱码的思路很简单：先预览CSV输入步骤的输出，如果这一步已经乱了，说明是文件编码和读取编码不一致；如果这一步正常，写进数据库才乱，那问题在数据库连接和表字符集上。用排除法定位，不要瞎蒙。

5.2 装了驱动还是报找不到驱动

"数据库连接测试失败，找不到驱动类"是高频报错。很多人明明把jar包放进lib目录了，依然报错，那多半是这几个原因：

• jar包放错位置或没有重启Spoon。Kettle启动时加载lib目录下的jar，放完文件必须重启才生效。
• 驱动版本和数据库版本不匹配。老MySQL配新驱动、新MySQL配太老的驱动，都有问题。一般建议MySQL用mysql-connector-java-5.1.x系列兼容性最好，8.x数据库可以配8.0.x驱动。
• 连接类型选错。选MySQL时驱动类名一般是com.mysql.jdbc.Driver或com.mysql.cj.jdbc.Driver，Kettle自动填充，理论上不需要手动改，但如果你从网上复制了别的连接串覆盖了默认值，就可能填错。

驱动问题排查时，先看日志里提示缺哪个类，然后去lib目录搜一下那个类在不在，这在大多数情况下能直接定位。

5.3 内存不足的崩溃体验

处理几十万行数据时，Spoon可能直接报OutOfMemoryError或者闪退。很多人第一反应是"Kettle不行"，其实大多数是启动内存配置太小的锅。

前面第2.4节里改的-Xmx参数，就是应对这个问题的。如果你处理的是上百万行级别，建议把-Xmx给到4G或更大。但内存粉饰不了一切的过度设计，转换里也别把所有数据都攒在一个步骤里不往下流，尽量保持流式处理。

另一个思路是不要一次全量抽取，用增量抽取：每次只处理新增或变更的数据，比如按日期字段过滤，或者记录上次处理的ID和位置。Kettle里做增量抽取的方式很多，命名参数、变量、SQL里写WHERE update_time > '${last_time}'都是常用做法。先把全量做通，再考虑增量优化，这是最稳的上手路线。

5.4 运行结果和预期不一致

还有一种比较隐蔽的问题：转换跑成功了，但结果跟你预期不一样。比如行数少了一些、某个字段全是空值、或者某些数字对不上。我遇到过几种典型情况：

• 预览和实际运行结果不一致：预览只取前100行，汇总字段（比如分组统计）在预览时算出来的可能只是部分数据的结果，不要拿预览当全量结果。
• 类型转换静默失败：字符串转数字时，遇到非数字内容Kettle会按它的"非严格模式"处理，可能把这一行置空而不报错。你看到某列大量空值但日志没有异常时，先怀疑这里。
• 过滤条件写反了：过滤记录组件里"发送true到第一个步骤，false到第二个"，新手容易把条件方向搞反，导致想要的数据走了错的分支。

跑完后对账是好习惯：源表总行数、过滤后行数、目标表行数，三者要能对上逻辑。对不上就按步骤逐个预览排查，很快能锁定是哪一步出了问题。

6. 写在第一篇的末尾：我的一点使用心得

6.1 一套稳定的学习路径

回首我自己刚学Kettle那会儿，最实用的路径其实是：先跑通一个完整的转换（CSV到数据库就够），再把"转换"和"作业"的关系搞清楚，最后学会用变量和参数。掌握这三样，你已经能解决日常七八成的ETL需求。至于集群、资源库、复杂性能调优，都是遇到真实场景后再针对性补课的事，一上来就啃难点反而容易劝退。

6.2 从维护成本角度看Kettle的价值

很多团队宁可让开发写Python脚本也不愿意用Kettle，理由往往是"代码能进版本库、看得懂"。这个理由有一定道理，但脚本散落之后的管理问题同样会反噬。我在实际项目里体会最深的是：图形化链路讲解起来太方便了——把画布打开，谁是上游、谁是下游、哪里过滤、哪里写入，一清二楚。交接给新同事的成本比贴一堆代码低得多。

下一篇我准备写Kettle作业的调度和自动化：怎么定时跑、怎么传变量、怎么失败重试和邮件告警。这些是让Kettle从"手工工具"变成"生产链路"的关键一步。如果你正在被重复的数据处理折磨，先把今天这篇的转换跑通，下一篇文章你就能把它挂上定时任务了。