简介：面向大学课程设计中的数据预处理作业场景，Kettle学习资源包适合正在学习ETL工具、需要完成数据清洗与转换任务的学生，也可作为瑞翼工坊项目实训的辅助材料。压缩包内含9个文件，总大小136.82MB，主要文件包括6个SQL数据源脚本、1份复杂数据预处理实践指导手册（docm）、1份数据表说明文档（doc），可覆盖从数据导入、清洗转换到输出加载的完整流程。目前已有1825人浏览学习该资源。借助其中内容，学习者可以结合真实的学生信息、成绩、一卡通等业务表结构，在Kettle图形化环境中演练去重、缺失值填补、日期与数字格式统一、字段编码、聚合统计等预处理操作，掌握数据集成与分区的设计方法；而SQL脚本导入即可生成所需的源数据表，能减少搭建实验环境的成本。此外，docm指导手册提供了带批注的实践步骤，数据表说明文档帮助快速厘清表间关系，整个包文件数量适中、结构清晰，便于在课程设计或大作业中直接复用，也适合作为课程设计文档撰写的素材来源，并为后续数据分析建模打下基础。
1. 数据预处理作业，为什么选择 Kettle
临近提交数据预处理作业的截止时间，A同学还在用 Excel 手工清洗一份带脏数据的订单表：空值要填、日期格式要统一、重复记录要删、两个表要关联……每一步都是复制粘贴和下拉公式，稍不注意就串行错位。如果你也经历过这种状态，Kettle 是一个更值得投入的工具。它是一款开源的图形化数据集成工具，全称叫 PDI，核心用法是把数据抽取、清洗、转换、加载这些操作，变成一个个可以拖拽的步骤，连成一条可视化流程。做数据预处理作业时，你不用写复杂代码，却能完成字段拆分、空值替换、去重排序、多表关联这些日常工作。它尤其适合初次接触数据清洗的开发者，因为每一步操作都能立刻看到数据变化，出错时也能顺着步骤排查，而不是在黑匣子里猜问题。
2. Kettle 环境准备与跑通第一个转换
2.1 为什么用 Kettle 而不是直接写 Python
做数据预处理作业，你当然可以用 Python 写 Pandas 脚本，但 Kettle 的核心优势在于可视化与可维护性。常见做法是：把清洗流程拆成一个个步骤节点，每个节点处理一种操作，数据流在节点之间传递。这种模式有三个好处。第一，调试直观，每个步骤可以右键预览数据，不用打印中间结果；第二，交接方便，别人打开你的转换文件，一眼就能看清清洗链路，而不是阅读几百行代码；第三，Kettle 自带大量数据源连接器，Excel、文本文件、各种主流数据库都能直接读写。如果你的作业要求里明确写了“使用 Kettle 完成数据预处理”，那选型更不需要犹豫。
不过也要说明边界：Kettle 不适合做复杂的机器学习特征工程，也不适合大规模实时流计算。它擅长的是批处理场景，把一堆杂乱的静态数据处理成规范的结构化数据。作业场景里，它覆盖了绝大部分需求。
2.2 PDI 下载安装与 JDK 版本匹配的关键点
Kettle 的发行包叫 PDI，进入官网下载页面后，你会看到两个主要版本：稳定版和月度更新版。做作业建议选稳定版，别追新。下载时注意压缩包格式，Windows 选.zip，Linux 选.tar.gz。
安装 Kettle 前后最容易被坑的是 JDK 环境。PDI 本身基于 Java 开发，不同版本的 PDI 对 JDK 版本要求不同。有些同学下载了最新版 PDI 却配了旧版 JDK，启动直接报错。我一般会按这个顺序来检查：
# 检查本机 JDK 版本 java -version # 如果系统里装了多个 JDK，确认当前生效的是哪个 which java echo $JAVA_HOME配置 JDK 时，注意两点：第一，JDK 版本要和 PDI 要求匹配，常见组合是 PDI 9.x 配 JDK 8 或 JDK 11，具体以解压目录里的启动脚本说明为准；第二，环境变量JAVA_HOME必须指向 JDK 安装根目录，而不是 bin 目录。Windows 上安装完 JDK 后，在系统环境变量里确认JAVA_HOME和PATH配置正确，然后运行 PDI 解压目录下的Spoon.bat启动图形界面。Linux 环境部署 Kettle 则运行spoon.sh，如果报错提示无法打开图形界面，大概率是服务器没有 X11 转发或者内存不足。
提示：启动时如果弹出多个日志窗口，属于正常现象。真正要关注的是主界面左上角是否出现 Spoon 的欢迎页面。
2.3 跑通第一个最小转换：CSV 读取到文本输出
环境准备好后，先别急着做整个作业，跑通一个最小流程建立信心。目标是从一个 CSV 文件读取数据，经过一个简单的字段过滤，再输出到另一个文本文件。
打开 Spoon 后，左侧面板是步骤树，分门别类放着各种组件。按下面的路径操作：
- 在左侧找到“转换”节点，先新建一个转换。
- 在“输入”分类下，拖拽一个“CSV 文件输入”步骤到画布。
- 在“输出”分类下，拖拽一个“文本文件输出”步骤到画布。
- 按住 Shift 键，从 CSV 输入步骤连线到文本文件输出步骤。
双击“CSV 文件输入”步骤，配置文件路径。关键配置项有三个：文件路径、分隔符、编码。文件路径用绝对路径最省事，分隔符改成英文逗号，编码建议统一用 UTF-8。配置好后，点“预览”按钮，应该能看到 CSV 内容按列拆分的效果。这一步能立刻暴露编码和分隔符问题。
再双击“文本文件输出”步骤，设置输出文件的路径、文件扩展名和编码。运行整个转换时，画布上的步骤会依次执行，每行数据的流向都会实时刷新颜色。运行结束后，去目标路径打开输出文件，如果内容无误，说明你的 Kettle 环境已经通了。从这里开始，就可以把作业里的真实数据处理任务逐步加到流程里。
3. 用 Kettle 完成数据预处理的四类典型任务
3.1 字段清洗与值映射：从脏数据到规范字段
拿到原始数据后，第一步通常是清洗字段。常见的脏数据形态包括：字段前后有空格、中文全角字符混入、性别字段出现“男/女/M/F/1/0”等多种写法、空值散落在各列。Kettle 里对应的处理组件主要有三个：“字段选择”“字符串操作”“值映射”。
先拖一个“字段选择”步骤到流程里。它的作用是重命名字段、删除不需要的列、调整字段顺序。作业里如果你的原始表有 20 列，但只需要其中 8 列，在这里就能完成裁剪。配置时，切换到“选择/改名”标签页，勾选要保留的字段，需要改名时在“名称”列里直接改成目标字段名。这个步骤还能干一件容易被忽略的事：修改字段元数据，比如把id字段从字符串类型改成整数类型，后续做关联操作时类型不一致的问题能在这里提前解决。
接下来处理空格和全角字符。用“字符串操作”步骤，选中要清理的字段，在“清除类型”列里选择清空格，同时可以设置去除换行符、去除制表符等选项。注意：这里的去空格默认只去前后空格，不会动字符串中间的空格，如果你要处理中间空格，得用“替换字符串”步骤，配置“查找”为空格、“替换为”为空字符串。
值映射适合把所有同义但不同写法的值统一成标准值。比如性别字段，建立映射关系如下：
| 原值 | 映射后 |
|---|---|
| 男 | 1 |
| M | 1 |
| male | 1 |
| 女 | 0 |
| F | 0 |
| female | 0 |
配置“值映射”步骤时，选中要处理的字段，逐条添加原值和映射值。如果原值在映射表里找不到，可以设置“如果不匹配”选项：选择“什么都不做”保留原值，或选择“设置为 NULL”丢弃无效值。作业场景里，建议先做统计数据再决定，不要直接丢弃。
空值替换在 Kettle 里推荐用“空操作”组里的“替换 NULL 值”步骤。它按字段配置替换值：数值字段替换成 0，字符字段替换成“未知”或空字符串。这里有个选择：要不要把空值统一替换？如果后续要做聚合统计，空值参与求平均和求和的逻辑不一样，我习惯先确认作业要求对缺失值的处理策略，再决定替换为什么值。
3.2 排序、去重与记录过滤：保证数据唯一性
数据清洗的第二类任务是保证数据的规范性和唯一性。典型操作是排序和去重。
排序用“排序记录”步骤，指定一个或多个排序字段，选择升序或降序。配置里有一个“内存中的最大行数”参数，默认值几百，如果数据量大而且该字段有重复值，建议调大。这里容易翻车的地方在后面：排序之后做去重，去重效果和排序顺序强相关。比如按客户编号排序后再去重，保留的是按当前顺序第一次出现的记录；如果要求保留最近一次记录，排序时要把时间字段排在后面，配合去重方向来控制。
去重本身用“去除重复记录”步骤。配置方式很简单：勾选需要判断重复的字段，Kettle 会基于这些字段的组合值判断两条记录是否重复。需要注意的是，“去除重复记录”步骤只保留重复记录中的第一条，具体保留哪一条取决于记录到达这个步骤时的顺序，所以才需要前面先做排序。如果作业要求里没有明确的保留规则，我建议先按业务主键字段排序，再去重，这样结果可控。
过滤操作用“过滤记录”步骤。它需要设置一个条件表达式，比如“订单金额大于 1000”。配置时点“条件”列，Kettle 会弹出条件编辑器，支持等于、大于、小于、包含、起始于等操作符。过滤步骤有两个输出分支：第一个分支是满足条件的记录，第二个分支是不满足的。这个特性在做数据拆分时非常有用，比如把 1 月数据和 2 月数据分两条链路处理。
字段拆分和合并也经常遇到。如果有一个字段叫“地址”，里面包含了省市和详细街道，想拆成“省份”“城市”“详细地址”三个字段，用“拆分字段”步骤，指定分隔符（中文地址常用逗号或空格），然后定义目标字段名。反过来，把多个字段合成一个新字段，用“增加常量”旁边的“字符串操作”或“分组”相关步骤实现。还有一种常见用法是“字段选择”里勾选“使用通配符”，批量选择以某一前缀开头的字段，批量清洗时能省不少时间。
如果作业里涉及类似夜间灯光数据的经纬度点数据，Kettle 的处理思路是一样的：把经纬度当普通字段做清洗，拆分、去重、过滤照常进行。Kettle 本身不区分行业数据，它只看字段类型和数据流，理解这一点，遇到什么数据都不慌。
3.3 多表数据关联与合并：三种方式按需选择
数据预处理作业里最难的一部分通常是多表数据合并。Kettle 提供三种常见方案。
第一种是“数据库查询”步骤。它相当于 SQL 里的 LEFT JOIN：主数据流中的记录，按关联字段到目标表里查数据，查询结果作为新字段拼接到当前记录上。配置时要设置目标数据源、查询 SQL、关联字段。这个方式的优点是灵活，查询条件可以写得很复杂；缺点是性能一般，逐条查询对数据量敏感，数据量大时明显变慢。
第二种是“合并记录”步骤。它要求两个输入流都先按同一个排序字段排好序，然后按字段匹配，比对两个流的异同，输出“新增”“删除”“相同”三类标记。这个步骤适合做数据对比，比如比对前一天数据和当天数据的差异，常用于数据同步场景。作业里如果要求“找出 A 表和 B 表中不一致的记录”，用它最合适。
第三种是“记录集连接”步骤。这个更接近数据库里的 JOIN 语义，支持 INNER JOIN、LEFT OUTER JOIN、FULL OUTER JOIN。配置时指定两个输入流的关键字字段，选择连接类型。与“数据库查询”相比，它先把两个数据源全部读入内存再匹配，匹配速度更快，但对内存占用更高。数据量在百万行以内时，这个步骤表现稳定，是日常使用频率最高的一种关联方式。
需要注意的是，无论用哪种方式，参与关联的字段类型必须一致。字符串和整数关联时，要么在“字段选择”里提前转换类型，要么在连接配置里给两个字段分别做转换。这里就是 Kettle 的一处坑：它不像数据库那么智能地做隐式类型转换，类型不匹配时，运行不会报错，而是直接匹配失败，结果为空，排查时你根本想不到是类型问题。
4. 作业调度与批量处理：从转换到作业
4.1 转换与作业的分工：什么场景用哪个
很多初学者分不清 Kettle 里的“转换”和“作业”。简单区分：转换强调数据流，作业强调控制流。转换里各步骤是并行的，数据从一个步骤流到下一个步骤；作业里则是串行执行多个转换或脚本，可以根据执行结果决定分支走向。
作业里的“转换”控件只是其中一个节点，实际干活的是它引用的转换文件。作业节点之间通过“成功”连线和“失败”连线连接，前置转换跑成功了才轮到后面的节点。做数据预处理作业时，常见做法是：一个作业里挂多个转换，比如第一个转换负责抽取原始文件，第二个转换负责清洗，第三个转换负责关联和输出。这样每个转换单独调试，组合起来运行，出问题时只要看作业日志里哪个节点标红，就能定位。
4.2 批量处理多个文件：使用通配符与获取文件名
作业场景里经常遇到一种需求：数据按日期拆分成多个 CSV 文件，比如20250101.csv、20250102.csv，需要一次性处理全部文件。Kettle 的文本文件输入步骤本身支持通配符，但更通用的做法是配合“获取文件”相关步骤。
先放一个“获取文件名”步骤，配置里填入文件所在目录路径和文件通配符，比如*.csv。运行后，这个步骤会把匹配的文件路径输出为一个字段。后续接一个“复制记录到结果”步骤，把文件路径列表暂存到 Kettle 的内存结果集里。然后再切换到主数据流：文本文件输入步骤里，开启“从结果获取文件名”选项，Kettle 会逐个读取结果集里的文件路径，循环执行后续清洗流程。
这种“先收集文件名，再逐个处理”的模式非常通用，不仅在处理多个 CSV 时有效，处理 Excel 多 sheet、多个数据表场景也能复用。需要注意的是，文件名字段要通过“字段选择”步骤重命名成固定名称，否则文本输入步骤可能找不到字段。
4.3 命令行执行：用 Pan 与 Kitchen 跑批处理
图形界面调试完成后，真正的批量跑批要走命令行。Windows 下用Pan.bat执行转换，用Kitchen.bat执行作业；Linux 下对应的脚本是pan.sh和kitchen.sh。这也是 Linux 环境部署 Kettle 之后最常见的运行方式。一个典型的命令行执行任务如下：
# 执行一个作业，指定作业文件和日志级别 ./kitchen.sh -file=/opt/kettle/jobs/preprocess_job.kjb \ -level=Basic \ -logfile=/opt/kettle/logs/job_$(date +%Y%m%d).log参数说明：-file指定作业文件路径，-level控制日志详细程度，Basic级别下只输出关键节点信息，适合日常跑批；如果排查问题，可以临时改成Debug或Rowlevel，会输出每一行数据的处理细节。-logfile把日志写入文件，跑批时可以配合系统定时任务实现无人值守。
命令行执行的最大好处是稳定和可编排。图形界面下窗口容易误关，命令行方式在服务器上长期运行不受影响。作业里还可以通过-param:参数名=值的方式传入参数，比如-param:INPUT_DATE=20250101，转换内部用${INPUT_DATE}引用这个值，这样同一份作业就能处理不同日期的数据。
需要注意的一点：命令行启动时的工作目录问题。很多人图形界面跑得好好的，命令行执行就报“找不到文件”，原因是相对路径是相对于命令行启动时的目录解析的。解决方法是统一使用绝对路径，或者在作业里配置变量路径，比如${KETTLE_HOME}指向项目根目录，所有文件路径都基于这个变量拼接。
5. Kettle 数据预处理作业的常见坑与排查记录
5.1 中文字段变成乱码或问号
现象：从 CSV 读入的中文字段在预览时显示正常，但输出到数据库或文本文件后变成乱码。
原因：数据源文件的编码、Kettle 步骤的编码、目标数据源的编码三者不一致。最常见的组合是源文件是 GBK 编码，而 Kettle 默认用 UTF-8 读取，或者目标数据库连接配置了错误的字符集参数。
解决：统一编码。在“CSV 文件输入”步骤的“编码”项里明确指定源文件编码，比如GBK或UTF-8；输出到数据库时，在数据库连接的高级选项里添加characterEncoding=utf-8参数；文本文件输出步骤同样显式设置编码。做完这三处检查，乱码问题基本能消除。
5.2 大数据量跑批时内存溢出
现象：小数据量测试没问题，换成完整数据集后，运行到某个步骤直接报 OutOfMemory，整个转换中断。
原因：Kettle 默认 JVM 堆内存设置较小，一些步骤需要把数据加载到内存处理，比如“记录集连接”“去除重复记录”，数据量上来后内存不足。
解决：修改 Kettle 启动脚本里的 JVM 参数。Windows 下编辑Spoon.bat，Linux 下编辑spoon.sh，找到PENTAHO_DI_JAVA_OPTIONS，把初始堆和最大堆调大，比如设置为-Xms512m -Xmx2048m。如果处理的是几千万行级别的数据，可以考虑给到 4GB 以上。改完重启 Spoon 生效。另外，优化转换本身也能降低内存压力：尽早用“字段选择”裁剪不必要的列，用过滤条件提前减少数据量。
5.3 日期字段变成无法识别的数字
现象：从 Excel 读入日期字段后，预览看到的是45000这样的数字，而不是日期格式。
原因：Excel 内部把日期存储为序列号，Kettle 在某些读取模式下没有自动识别数据类型，把它当数字读了出来。
解决：在“Excel 输入”步骤里，明确指定该字段的类型为“日期”，并设置格式为yyyy-MM-dd等对应格式。如果数据已经到了转换流程里，也可以用“字符串转为日期”步骤或“日期类型”步骤做类型转换。这里常见的误区是直接在“字段选择”里改类型，但那只是改了元数据定义，不保证实际值能正确解析，还是要看字段格式是否匹配。
5.4 数据库输出时报主键冲突导致作业中断
现象：数据写入目标表时，提示唯一约束冲突，作业停在输出步骤，后续节点全部不执行。
原因：源数据中存在重复记录，或者源表与目标表的关联字段没有去重就直接输出。
解决：先在上游加一步“去除重复记录”，按业务唯一键去重；如果作业要求保留重复记录，就改用“数据库更新”步骤，配置更新条件，让存在时更新、不存在时插入。另一个措施是给输出步骤配置错误处理，把冲突记录单独输出到一张错误表，不影响主流程继续跑。错误处理模式在 Kettle 里是步骤右键的“处理错误”选项，建议所有输出节点都配上。
5.5 图形界面能跑命令行却报错
现象：在 Spoon 里调试一切正常，保存后用 Pan 或 Kitchen 命令行执行，报错信息指向文件找不到或步骤不存在。
原因：大多情况是路径问题或变量未定义。图形界面会加载当前项目的配置文件，而命令行执行时没有自动加载这些配置，相对路径解析的基准目录不同，命名参数没有被传值。
解决：执行前先检查作业和转换里是否引用了外部文件，统一改成绝对路径或基于变量的路径；如果用了命名参数，命令行调用时必须显式传-param:参数名=值，不能依赖图形界面的默认值。还有一个习惯值得养成：命令行执行前先cd到 PDI 安装目录或作业目录再执行，减少工作目录变化带来的不确定性。
6. 用变量和参数把作业变成可复用的数据处理工具
做到这一步，你的 Kettle 作业已经能处理一份完整的数据。但距离“可复用工具”还差最后一步：参数化。
先学会用环境变量。在 Spoon 界面里，按快捷键或从菜单打开“显示变量”面板，你可以定义自定义变量，比如设置ROOT_PATH指向项目根目录，然后在转换里所有文件路径都写成${ROOT_PATH}/input/xxx.csv。这样项目迁移到另一台机器，或者从 Windows 换到 Linux 环境部署，只需要修改变量值，不用改每个步骤。
命名参数更适合命令行场景。在作业或转换的属性里声明一个命名参数，比如REPORT_DATE，默认值填当天的日期。在 SQL 查询、文件名、数据库 schema 里都可以通过${REPORT_DATE}引用。命令行执行时通过-param:REPORT_DATE=20250101传入。我一般会把参数设计成两层：顶层必须传的参数，比如业务日期；内部自动推导的参数，比如从REPORT_DATE拼接出的月度目录${ROOT_PATH}/${REPORT_DATE:0:6}。
调试参数化作业时有个习惯值得借鉴：先用图形界面手动传一个测试值，验证逻辑正确，再切到命令行用小数据量试跑，最后才挂到定时任务上。我曾经因为跳过中间一步，直接把参数化作业挂进定时任务，结果参数没传对，处理了错误日期的数据，花了不少功夫补救。从那以后，我再也不敢跳过试跑环节。日志级别也建议保持Basic，既能看到节点执行情况，又不会因为输出太多影响性能。
到这里，你已经具备用 Kettle 独立完成一份数据预处理作业的能力，从环境安装、转换设计、作业调度到问题排查，再到参数化复用，这条路每一步都经得起实操验证。遇到具体问题，优先看运行日志和步骤预览数据，大多数坑都能自己解决。希望帮到你。
本文还有配套的精品资源，点击获取
