简介data-integration.zip 是一套面向数据工程师与 ETL 初学者的 KettlePentaho Data Integration开发环境资源包用于解决多源数据采集、清洗、转换与调度问题。包内共 965 个文件以 446 个 png 界面截图、172 个 jar 依赖库、147 个 ktr 转换脚本、15 个 kjb 作业文件为主另含 pdf 文档、properties 配置、bat/sh 启动脚本及少量 csv、xls 示例数据压缩包约 106.65MB。资源涵盖 Spoon 图形化设计器、Carte/Pan/Kitchen 等运行组件与示例转换作业可帮助读者快速搭建本地 ETL 实验环境理解转换与作业的编排逻辑、数据源接入方式及插件扩展机制并借助日志与监控排查数据集成过程中的常见问题。目前已有 1178 人学习下载适合需要系统掌握 Kettle 数据集成流程的开发者参考使用。1. 拿到># 确认 Java 版本Kettle 启动脚本会读 JAVA_HOME java -version echo $JAVA_HOME # 如果没配临时指定写进 ~/.bashrc 才能持久 export JAVA_HOME/usr/lib/jvm/java-11-openjdk-amd64 export PATH$JAVA_HOME/bin:$PATH逻辑说明spoon.sh图形界面和pan.sh转换执行、kitchen.sh作业执行这三个脚本内部都会调用java它们优先用JAVA_HOME找不到才用 PATH 里的 java。参数上唯一要盯的是内存默认堆往往偏小数据量一大就 OOM。# 解压注意目录名里不要带空格和中文 unzip># 无图形界面下执行一个转换-file 指定 ktr-level 控制日志详细程度 ./pan.sh -file:/data/jobs/first_transform.ktr -level:Basic # 执行作业作业里可以串多个转换、加判断和循环 ./kitchen.sh -file:/data/jobs/daily_load.kjb -level:Detailed # 想看更细的日志把 level 换成 Debug但生产别长期开日志会爆 ./pan.sh -file:/data/jobs/first_transform.ktr -level:Debug逻辑说明pan.sh只跑单个转换kitchen.sh跑作业。作业是「流程编排」转换是「数据流水线」这是 Kettle 里最容易混的一对概念。参数-level有Nothing、Minimal、Basic、Detailed、Debug、Rowlevel六档Rowlevel会把每一行数据都打出来只在排查具体某行数据错在哪时用平时用Basic就够。提示Linux 上跑 Pan 之前先确认>CSV 文件输入 配置要点 文件名 /data/in/orders.csv 分隔符 ,逗号如果是制表符填 \t 编码 UTF-8中文乱码九成是这里和数据库字符集不一致 NIO 缓冲 开启大文件读取快很多 字段 点「获取字段」自动解析然后手动核对类型 表输出 配置要点 目标表 ods_orders 提交记录数 1000每 1000 行提交一次别设太大也别设 1 批量更新 勾选能显著提速 数据库连接 提前在「数据库连接」里建好并测试通过逻辑说明提交记录数是 Kettle 写库的核心参数。设成 1 就是逐行提交慢到无法接受设成 10 万事务太大一旦失败回滚代价高而且数据库的 undo 空间可能扛不住。1000 到 5000 是常见区间。批量更新勾上后Kettle 会把多条 insert 合并成 JDBC batch这是写库提速最直接的一招。3. 转换里的核心步骤字段处理、连接查询与性能取舍3.1 字段选择和元数据类型不对后面全白干Kettle 是强类型的每个字段都有 String、Integer、Number、Date、Boolean、BigNumber 这些类型。CSV 读进来默认全是 String直接往数值列写会报类型转换错误。所以「字段选择」步骤几乎是标配用来改类型、改名字、去掉不需要的列。字段选择 配置 选择和修改 标签页 字段名 类型 格式 order_id Integer - amount Number #,##0.00 created_at Date yyyy-MM-dd HH:mm:ss 元数据 标签页 可以在这里改字段的默认类型影响下游所有步骤参数说明格式这一列对 Date 和 Number 特别关键。日期格式写错比如源数据是2024/01/05而你写yyyy-MM-ddKettle 不会报错会直接给个 null然后你在下游查半天「数据怎么少了」。血泪经验是字段选择配完先用「预览」看几行确认类型和值都对再往下接。3.2 数据库连接查询为什么你的转换越跑越慢两个表关联新手第一反应是拖「数据库查询」Database Lookup对每一行去目标库查一次。数据量小的时候没感觉几万行以上就开始肉眼可见地变慢因为这是 N 次查询。方案对比 数据库查询Lookup 逐行查库N 行 N 次 SQL适合维表小、行数少 流查询Stream Lookup 把维表一次性读进内存做哈希匹配适合维表能放进内存 合并连接Merge Join 两边都按连接键排序后归并适合大表对大表逻辑说明选哪个取决于数据规模。维表几千行、事实表几十万行用流查询把维表全量加载到内存匹配是 O(1)。两边都是百万级用合并连接但前提是两边都必须先按连接键排序否则结果会错——这是 Kettle 里最隐蔽的坑之一它不报错只是默默给你错误的结果。合并连接 使用前提 1. 两个输入步骤都必须按连接字段升序排序 2. 排序可以用「排序记录」步骤也可以让数据库 ORDER BY 后输出 3. 连接类型选 INNER / LEFT / RIGHT / FULL和 SQL 语义一致注意合并连接如果没排序Kettle 不会拦你跑出来的行数可能对也可能不对取决于数据本身的物理顺序。上线前一定拿小数据集对一遍结果。3.3 参数与变量让同一个转换跑不同环境硬编码数据库地址、文件路径的转换换一个环境就得改一遍这是维护灾难。Kettle 支持参数Parameter和变量Variable配合kettle.properties或命令行-param传值。# 命令行传参转换里用 ${变量名} 引用 ./pan.sh -file:/data/jobs/load.ktr \ -param:INPUT_DIR/data/in \ -param:DB_HOST10.0.0.5 \ -param:BATCH_DATE2024-01-05转换里引用方式 步骤里的文件路径 ${INPUT_DIR}/orders_${BATCH_DATE}.csv 数据库连接主机 ${DB_HOST} 注意参数在转换启动时求值一次变量可以在运行中改变参数说明-param传进去的是参数作用域是整个转换/作业变量可以通过「设置变量」步骤在流程中动态改。区别在于参数是只读的变量可写。日常做增量抽取BATCH_DATE这种用参数最合适因为一次运行就该固定一个日期。4. 作业编排与调度把单次转换变成每天自动跑4.1 作业里的判断、循环和错误处理单个转换解决「一次搬运」作业解决「什么时候搬、搬失败了怎么办」。作业里最常用的几个条目Start定时或立即启动、转换调用 ktr、成功判断上一步结果、发送邮件、Shell。典型日调度作业结构 Start每天 02:00 → 转换抽取源库到 ods → 成功 是 → 转换ods 清洗到 dw → 成功是 → 发送邮件「完成」 否 → 发送邮件「dw 失败」 否 → 发送邮件「ods 失败」逻辑说明作业里的连线分两种颜色绿色是「成功」走向红色是「失败」走向。新手常犯的错是只连绿色线结果某一步失败后整个作业静默结束第二天才发现数据没更新。正确做法是每个关键转换后面都接判断失败路径至少发个告警。4.2 用 crontab 还是用 Kettle 自带调度Kettle 的作业里Start条目可以设定时但那个定时要求进程一直挂着。生产上更常见的是用系统 crontab 调kitchen.sh让操作系统负责触发Kettle 只负责跑。# crontab -e 加一行每天凌晨 2 点跑日志按日期归档 0 2 * * * cd /opt/data-integration \ ./kitchen.sh -file:/data/jobs/daily_load.kjb \ -level:Basic /data/logs/kettle_$(date \%Y\%m\%d).log 21参数说明追加日志21把错误输出也重定向进去否则报错信息会丢。日志文件名里的%在 crontab 里要转义成\%这是很多人第一次写 crontab 会翻车的地方。日志一定要留Kettle 出问题时日志是唯一的黑匣子。4.3 增量抽取时间戳、自增 ID 还是 CDC全量抽取简单但慢数据一大就跑不动。增量抽取常见三种做法按时间戳字段update_time 上次最大值、按自增 ID、按数据库日志做 CDC。Kettle 社区版对 CDC 支持有限绝大多数团队用的是时间戳方案。-- 抽取时带上水位线${LAST_MAX_TIME} 由上一次运行结果写入 SELECT order_id, amount, update_time FROM orders WHERE update_time ${LAST_MAX_TIME} AND update_time ${CURRENT_MAX_TIME} ORDER BY update_time;逻辑说明水位线要「左开右闭」避免边界那条记录被重复抽或漏抽。每次跑完把本次的CURRENT_MAX_TIME写回一张控制表下次读出来当LAST_MAX_TIME。这个控制表用 Kettle 的「表输入」读、「表输出」写就行不需要额外工具。注意时间戳方案对「物理删除」无能为力源库删了一行增量抽取永远发现不了。如果业务要求同步删除要么用逻辑删除字段要么上 CDC别指望时间戳能兜住。5. 避坑与排查Kettle 跑起来之后最容易翻车的 5 个地方5.1 中文乱码现象是入库变问号原因是编码链没对齐现象CSV 里的中文写进数据库变成???或者乱码。原因文件编码、Kettle 步骤编码、数据库连接字符集、目标表字符集这四处只要有一处不是 UTF-8 就会出问题。解决CSV 输入步骤显式指定 UTF-8数据库连接的高级里加characterEncodingutf8建表时确认是utf8mb4。排查时先用「预览」看 Kettle 读进来的是不是正常中文能快速定位是读的问题还是写的问题。5.2 内存溢出现象是跑一半 OOM原因是排序和聚合把数据全压内存现象转换跑到某个步骤突然java.lang.OutOfMemoryError。原因排序记录、分组、去重、流查询这些步骤都是内存操作数据量超过堆就崩。解决优先用数据库做排序和聚合SQL 里ORDER BY、GROUP BYKettle 只做搬运实在要在 Kettle 里做把-Xmx调大同时检查有没有意外的笛卡尔积把行数放大了几十倍。5.3 连接不释放现象是跑几天后数据库连接数爆满现象Kettle 连续跑几天数据库端连接数只增不减最后新连接建不上。原因转换里每个数据库连接步骤都会开连接如果没配连接池或者转换异常退出连接可能没正常关闭。解决在数据库连接里勾选连接池设置初始连接数和最大连接数作业层面加错误处理确保异常时也能走到清理逻辑。5.4 日期格式静默失败现象是数据莫名少了一批原因是格式不匹配给了 null现象抽取结果比预期少但日志没有任何报错。原因日期字段格式和实际数据不一致Kettle 转换失败时默认给 null而下游过滤条件把 null 行过滤掉了。解决字段选择里日期格式必须和源数据严格一致开启步骤的「错误处理」把转换失败的行写到单独的错误表而不是默默丢弃。5.5 版本与驱动不匹配现象是连不上库或报方法不存在现象换了数据库驱动 jar 之后连接报NoSuchMethodError或ClassNotFoundException。原因>#!/bin/bash # batch_load.sh循环 30 张分表逐张跑同一个转换 for i in $(seq -w 1 30); do TABLEorders_${i} echo 开始处理 ${TABLE} $(date %F %T) /opt/data-integration/pan.sh \ -file:/data/jobs/load_one.ktr \ -param:TABLE_NAME${TABLE} \ -param:BATCH_DATE$(date %F) \ -level:Basic /data/logs/batch_$(date %F).log 21 if [ $? -ne 0 ]; then echo 处理 ${TABLE} 失败退出 /data/logs/batch_$(date %F).log exit 1 fi done逻辑说明seq -w 1 30生成01到30的补零序号拼出表名。$?取上一条命令的退出码Pan 成功返回 0失败返回非 0靠这个判断要不要中断。参数TABLE_NAME在转换里用${TABLE_NAME}引用表输入和表输出的表名都写成变量。这样加一张分表只改循环上限不用动转换。跑完之后的校验同样重要。我习惯在转换末尾加一个「表输入」统计目标表行数和源表行数对比把差值写进一张校验表。行数对不上就告警比等业务方发现数据缺了再回头查要主动得多。-- 校验 SQL源表和目标表行数对比差值不为 0 就是有问题 SELECT (SELECT COUNT(*) FROM orders_01) AS src_cnt, (SELECT COUNT(*) FROM ods_orders_01) AS dst_cnt, (SELECT COUNT(*) FROM orders_01) - (SELECT COUNT(*) FROM ods_orders_01) AS diff;参数说明diff为 0 说明行数一致但不代表内容一致严格校验还要比对金额合计、最大更新时间这些业务指标。我一般把行数校验做成每次必跑金额校验做成每天跑一次兼顾速度和可靠性。最后说个习惯任何转换上线前我都会拿一份「已知答案」的小数据集跑一遍人工核对输出。Kettle 的坑大多不报错只是安静地给你错的结果后悔药是没有的只能靠上线前的对照。这套东西不复杂难的是每次都坚持做。希望帮到你。本文还有配套的精品资源点击获取