简介：data-integration.zip 是一套面向数据工程师与 ETL 初学者的 Kettle（Pentaho Data Integration）开发环境资源包，用于解决多源数据采集、清洗、转换与调度问题。压缩包共 965 个文件，约 106.65MB，以 446 个 png 界面截图、172 个 jar 依赖库、147 个 ktr 转换脚本、15 个 kjb 作业文件为主，另含 xml 配置、pdf 文档、properties 参数文件及 bat/sh 启动脚本，覆盖 Spoon、Kitchen、Pan、Carte 等组件的运行所需。资源内含示例转换与作业、环境配置脚本及说明文档，可帮助读者快速搭建图形化 ETL 开发环境，理解转换与作业的编排逻辑，掌握关系型数据库、文件系统、云服务等多数据源接入方式，并借助日志监控与并行处理机制优化数据集成流程。目前已有 1178 人学习下载，适合需要系统上手 Kettle、积累数据集成实战经验的技术人员参考。
1.># 解压到无空格无中文的路径 unzip># 编辑 spoon.sh，找到 JAVA_OPTIONS 相关行，修改 -Xmx # 常见写法：-Xmx2048m 改为 -Xmx4096m grep -n "Xmx" spoon.sh # 临时验证：启动时直接传参（部分版本支持） ./spoon.sh -Xmx4096m
参数说明：-Xmx控制最大堆，-Xms控制初始堆，建议两者设成一样避免动态扩展开销。改完脚本后所有通过该脚本启动的 Spoon、Pan、Kitchen 都会继承这个内存设置。如果只改图形界面不改命令行，调度时照样 OOM，所以三个入口脚本最好统一改。
3. 用 Spoon 跑通第一条转换：CSV 到数据库的最小闭环
3.1 新建转换与核心步骤的连线逻辑
打开 Spoon 后，文件 → 新建 → 转换，得到一张空白画布。左侧核心对象树里找到「输入」下的「CSV 文件输入」，拖到画布；再找「输出」下的「表输出」，拖到画布。按住 Shift 从 CSV 步骤拖一条线到表输出步骤，这条线叫跳（Hop），代表数据流向。双击 CSV 步骤，选择文件路径，点「获取字段」让工具自动扫描列名和类型。双击表输出步骤，新建数据库连接，填主机、端口、库名、用户名密码，点「测试」确认连通，然后在「目标表」里填表名，勾选「指定数据库字段」，把输入字段和目标表字段做映射。
这里有个容易翻车的地方：CSV 里的日期格式和数据库字段类型不匹配，测试连接通过但运行时报转换错误。解决办法是在 CSV 输入步骤里手动把日期字段类型改成 String，再在后面加一个「字段选择」或「计算器」步骤做格式转换，不要指望自动识别百分百准确。
转换文件保存为 csv_to_db.ktr 步骤1：CSV文件输入 → 文件路径 /data/input/user.csv，分隔符逗号，编码 UTF-8 步骤2：表输出 → 连接 mysql_target，目标表 user_info，勾选指定数据库字段 跳：CSV文件输入 → 表输出上面是转换的文本描述，实际在 Spoon 里是图形化配置。保存后点工具栏的绿色播放按钮，选「本地执行」，看下方执行结果窗口的步骤度量：输入多少行、输出多少行、读写速度、耗时。如果输出行数为 0 但输入有值，八成是字段映射没对上或者目标表主键冲突被静默丢弃。
3.2 命令行跑转换：Pan 的参数与日志排查
设计好的.ktr文件放到服务器上，用pan.sh执行。常用参数：-file指定转换文件，-level指定日志级别（Basic、Detailed、Debug），-logfile把日志写到文件方便排查。生产环境建议用-level Basic减少日志量，出问题时临时切Debug看每一步的数据流。
# 在># 执行作业，指定日志和参数 ./kitchen.sh -file=/data/jobs/daily_etl.kjb \ -level=Basic \ -logfile=/data/logs/daily_etl_$(date +%Y%m%d).log \ -param:ETL_DATE=$(date +%Y-%m-%d)参数说明：-param:可以传自定义参数，在转换里用${ETL_DATE}引用，实现按日期增量抽取。-level和-logfile与 Pan 一致。作业里还可以加「发送邮件」步骤做失败告警，但邮件服务器配置建议放在kettle.properties里统一管理，不要硬编码在作业文件中。
5.2 增量抽取的三种常见做法与选型
全量抽取简单但数据量大时慢且浪费资源。增量抽取常见三种：基于时间戳字段，每次取update_time > 上次最大时间；基于自增 ID，取id > 上次最大 ID；基于数据库日志或 CDC 工具。Kettle 本身做前两种最顺手。时间戳方式要注意时区和数据库时间精度，自增 ID 方式要注意物理删除的数据抽不到。选型建议：源表有可靠的update_time就用时间戳，没有就用自增 ID 配合定期全量校对。
-- 在转换里用「表输入」步骤写增量 SQL，${LAST_MAX_TIME} 由作业参数传入 SELECT id, name, amount, update_time FROM orders WHERE update_time > '${LAST_MAX_TIME}' ORDER BY update_time;上面 SQL 里的${LAST_MAX_TIME}是 Kettle 变量替换，执行前由作业或命令行传入。每次跑完要把本次最大update_time写回一个记录表或文件，下次作为起点。这个「记录位点」的步骤不能省，否则每次都是全量。
5.3 参数传递与变量作用域
Kettle 的变量分几个层级：命令行-param:传入的、kettle.properties里定义的、转换内部「设置变量」步骤定义的。作用域从大到小，同名时内层覆盖外层。常见错误是在转换里用${VAR}但变量没定义，运行时直接报错或替换成空字符串。排查方法：在转换开头加一个「写日志」步骤，把关键变量打印出来，确认值是否符合预期。
注意：
kettle.properties文件在用户家目录的.kettle目录下，不是>-- 源库和目标库分别执行，比对结果 SELECT COUNT(*) AS cnt, SUM(amount) AS total FROM orders; SELECT status, COUNT(*) FROM orders GROUP BY status;上面两个 SQL 在源库和目标库各跑一次，把结果贴到同一个表格里对比。金额差异往往是精度问题，比如源是
DECIMAL(10,2)目标是FLOAT，累加后尾差会放大。状态计数差异通常是过滤条件写错或者 NULL 值处理不一致。一个习惯：每次改完转换，先在测试库跑一遍，确认无误再改生产调度。生产调度文件不要直接编辑，用版本控制管起来，改之前先备份。Kettle 的
.ktr和.kjb都是 XML 文本，可以 diff，出问题能回滚。我吃过亏——直接在服务器上改生产转换，改错一个字段映射，第二天对账才发现，补数据补了一整天。从那以后所有转换文件进 Git，服务器上只拉取不手改。希望帮到你。本文还有配套的精品资源，点击获取
