Kettle 9.3 完整安装包与ETL实战：从数据清洗到集群调度

简介这份资源面向数据工程师、ETL开发初学者及需要搭建数据集成流程的技术人员提供KettlePentaho Data Integration9.3版本的获取渠道。Kettle以纯Java编写可在Windows、Linux、Unix等平台运行通过Spoon图形化界面拖拽完成数据抽取、转换与加载支持MySQL、Oracle、SQL Server及MongoDB、Hadoop HDFS等多种数据源并具备与Amazon S3、Google Cloud Storage等云存储集成的能力。资源包内共1个docx文档压缩包约14KB文档中整理了百度云盘链接与提取码便于在国内网络环境下获取安装包。内容涵盖Transformation与Job两类脚本文件的说明、9.3版本的更新方向以及ETL流程设计的基本思路适合希望快速上手Kettle、了解其核心组件与云端数据处理能力的读者参考。目前已有5724人学习下载可作为入门选型与版本获取的实用指引。1. 从一次凌晨三点的数据对账说起Kettle 9.3 到底解决了什么凌晨三点某公司数据组的 A 同学还在手动比对两张 Excel 表的差异——上游业务库导出的 CSV 有 47 万行下游报表系统只认进去 46 万 2 千行中间那 8 千行去哪了这种场景在数据工程里太常见了数据抽取、清洗、转换、加载每一步都可能悄悄丢数据。KettlePentaho Data IntegrationPDI就是冲着这类问题来的——纯 Java 编写的开源 ETL 工具用图形化界面把「数据从哪来、怎么变、到哪去」画成一条可调试、可复用、可调度的流水线。9.3 版本在连接池管理、集群执行和云存储插件上做了不少修补对于还在用 8.x 甚至更早版本、被内存泄漏和调度不稳定折磨的团队来说升级到 9.3 是一个值得认真评估的节点。这份资源包就是 Kettle 9.3 的完整安装包适合数据仓库开发、报表供数、跨库同步这类日常任务新手能照着拖拽出第一条转换熟手能直接翻它的插件目录看底层实现。2. 拆开安装包Spoon、Pan、Kitchen 到底谁在干活下载完资源包解压后你会看到一堆.bat和.sh文件名字五花八门。很多人第一次打开就懵了——到底该点哪个这一章把 Kettle 9.3 的目录结构和核心组件拆清楚后面配环境、写转换才不会迷路。2.1 图形化客户端 Spoon 与命令行工具的分工Kettle 的安装包是典型的「绿色版」结构解压即用不需要写注册表。根目录下最显眼的是Spoon.batWindows和spoon.shLinux/Unix这是图形化设计器你 90% 的时间会花在它上面。但真正跑在生产调度里的往往是另外两个命令行工具Pan.bat用来执行单个 TransformationKitchen.bat用来执行 Job。为什么要有命令行版本因为生产环境不可能让你开个远程桌面去点「运行」按钮调度系统比如 Crontab、XXL-JOB、Airflow需要的是可传参、可返回退出码、可写日志的进程。Spoon 里设计好的.ktr和.kjb文件最终都是交给 Pan 和 Kitchen 去执行的。资源包里通常包含># Windows 下查看 Java 版本 java -version # 如果输出不是 1.8 或 11需要手动指定 # 编辑 Spoon.bat在开头添加 set JAVA_HOMEC:\Program Files\Java\jdk1.8.0_301 set PATH%JAVA_HOME%\bin;%PATH%Linux 下同理编辑spoon.sh在开头导出JAVA_HOME。启动 Spoon 后如果界面能正常打开且菜单栏没有报错弹窗说明环境没问题。第一次启动会稍慢因为要初始化插件缓存。提示如果启动时卡在 Splash 界面超过 30 秒大概率是plugins目录下有插件冲突。可以先把plugins重命名为plugins_bak再启动试试确认是哪个插件的问题后再放回去。3.2 用「CSV 输入」「字段选择」「表输出」搭一条最小流水线在 Spoon 里新建一个 Transformation快捷键 CtrlN从左侧「核心对象」树里拖三个步骤到画布CSV 输入配置文件路径、分隔符、编码。编码这里坑最多Windows 下 Excel 导出的 CSV 默认是 GBK而 Kettle 默认用 UTF-8 读中文会变乱码。在「内容」标签页把编码改成GBK或GB2312。字段选择用来重命名字段、改类型、去掉不需要的列。比如 CSV 里有一列叫user_id目标表要求uid就在这里改。表输出配置目标数据库连接、目标表名、字段映射。用 Shift 键把三个步骤连起来顺序是 CSV 输入 → 字段选择 → 表输出。然后点「预览」按钮看数据能不能正常流出来。如果预览报错先检查 CSV 文件路径有没有写对再看字段类型是否匹配——比如 CSV 里age列有非数字字符而你在字段选择里把它设成了 Integer就会报转换错误。3.3 数据库连接配置从 JDBC 驱动到连接池参数Kettle 连接 MySQL 需要把 JDBC 驱动 jar 包放到lib目录下。以 MySQL 8.0 为例下载mysql-connector-java-8.0.xx.jar丢进>连接类型MySQL 主机名192.168.1.100 数据库名dw_test 端口号3306 用户名etl_user 密码******点「测试」按钮如果显示「连接成功」就 OK。但生产环境要注意连接池参数。在「选项」标签页里可以加KETTLE_DB_CONNECTION_POOL_SIZE10 KETTLE_DB_CONNECTION_POOL_MAX_IDLE5这两个参数控制连接池的最小和最大空闲连接数。设太小高并发时频繁创建连接拖慢速度设太大数据库端可能达到max_connections上限。我一般按目标库的承受能力来先设 10 个跑压测看监控再调。注意如果目标表是分区表或者有触发器表输出步骤的「批量提交」大小要调小。默认 1000 行提交一次遇到触发器逐行处理时可能锁表。改成 100 或 200 试试。4. 调度与参数化让转换在无人值守时也能跑手工点「运行」只能应付临时任务真正的 ETL 要能定时跑、传参跑、失败重跑。这一章讲 Job 调度、变量传递和日志排查。4.1 Kitchen 命令行执行 Job 与退出码含义假设你有一个daily_load.kjb里面串联了三个转换。用 Kitchen 执行# Linux 下执行 Job ./kitchen.sh -file/data/kettle/jobs/daily_load.kjb \ -levelBasic \ -logfile/data/kettle/logs/daily_load_$(date %Y%m%d).log # Windows 下 Kitchen.bat /file:D:\kettle\jobs\daily_load.kjb /level:Basic-level控制日志详细程度Basic 只记录关键信息Debug 会打印每一行数据生产环境别用 Debug日志会爆炸。Kitchen 的退出码很重要0 表示成功1 表示步骤出错2 表示初始化失败3 表示文件找不到7 表示被用户中断8 表示意外错误。调度系统就是靠这个退出码判断要不要重试或告警。4.2 变量与参数传递从 kettle.properties 到命令行覆盖Kettle 的变量可以在四个地方定义优先级从低到高kettle.properties全局文件 → Job 或 Transformation 的「命名参数」→ 命令行-param传入 → 步骤里的「变量替换」。举个例子你希望每天处理不同日期的数据# 命令行传入日期参数 ./pan.sh -file/data/kettle/trans/extract_orders.ktr \ -param:PROC_DATE2024-06-01 \ -param:SRC_DBorder_db在转换里SQL 步骤的查询语句写成SELECT * FROM orders WHERE dt ${PROC_DATE}Kettle 会自动替换。注意变量名大小写敏感${PROC_DATE}和${proc_date}是两个不同的变量。另外如果变量没定义Kettle 不会报错而是原样保留${PROC_DATE}字符串导致 SQL 查不到数据。排查时先看日志里替换后的 SQL 长什么样。4.3 日志分级与错误处理Job 里的「发送邮件」和「失败重试」Job 里可以拖「发送邮件」步骤配置 SMTP 服务器和收件人在转换失败时触发。但更实用的是「简单评估」和「JavaScript」步骤组合实现条件重试。比如// 在 JavaScript 步骤里判断上一步是否失败 var exitCode parent_job.getVariable(STEP_EXIT_CODE); if (exitCode ! 0 retryCount 3) { // 设置重试标志 parent_job.setVariable(RETRY_FLAG, Y); }这段代码放在 Job 的「JavaScript」步骤里配合「简单评估」判断RETRY_FLAG的值决定是否跳回上一个转换重新执行。重试次数用另一个变量retryCount控制每次加一。注意 Kettle 的变量作用域是 Job 级别的Transformation 里要读 Job 变量需要用${变量名}或者getVariable函数。提示日志文件建议按天切割并在 Job 开头加一个「删除旧日志」的步骤只保留最近 30 天。不然半年后日志目录能占满磁盘。5. 避坑与排查那些让我加班到深夜的 Kettle 问题这一章记录几个真实踩过的坑每个都按「现象 → 原因 → 解决」写。如果你刚开始用 Kettle这些坑大概率会碰到。5.1 中文乱码CSV 编码与数据库字符集的三方博弈现象CSV 文件用 Excel 打开正常Kettle 预览也正常但写入 MySQL 后中文变成问号或乱码。原因三个环节的字符集不一致。Excel 保存 CSV 默认用系统编码Windows 中文版是 GBKKettle 的 CSV 输入步骤如果设成 UTF-8读进来就已经错了即使读对了MySQL 表的字符集如果是latin1写入时又会转错。解决第一步用 Notepad 或file -i命令确认 CSV 的真实编码第二步在 CSV 输入步骤里显式设置对应编码第三步检查 MySQL 连接 URL 是否加了useUnicodetruecharacterEncodingutf8第四步确认目标表的CHARACTER SET是utf8mb4。四个地方全对齐乱码才会消失。5.2 内存溢出JVM 堆大小与「复制记录」步骤的陷阱现象转换跑了几十万行后突然报OutOfMemoryError: Java heap spaceSpoon 界面卡死。原因Kettle 默认 JVM 堆内存只有 512MB 或 1GB而某些步骤比如「排序记录」「聚合」需要把全部数据加载到内存里才能完成。如果数据量超过堆大小直接崩。解决编辑Spoon.bat或Pan.bat找到PENTAHO_DI_JAVA_OPTIONS这一行把-Xmx调大set PENTAHO_DI_JAVA_OPTIONS-Xms1024m -Xmx4096m -XX:MaxPermSize256m-Xms是初始堆-Xmx是最大堆建议设成一样避免动态扩容开销。但更根本的解决办法是避免用全内存步骤——排序可以用数据库的ORDER BY聚合可以用 SQL 的GROUP BY把压力转移给数据库。5.3 连接超时数据库连接池与防火墙的「静默断链」现象转换在测试环境跑得好好的放到生产环境跑十几分钟后就报「Communications link failure」。原因生产环境的防火墙或数据库中间件会主动断开空闲超过一定时间的连接而 Kettle 连接池里的连接被断开后下次取出来用的时候才发现已经失效。解决在数据库连接的「选项」里加autoReconnecttrueMySQL或对应的重连参数。同时把连接池的KETTLE_DB_CONNECTION_POOL_MAX_IDLE设小一点比如 2让空闲连接尽快释放。另外可以在 Job 里加一个「心跳」转换每隔几分钟执行一次SELECT 1保持连接活跃。5.4 调度不执行Crontab 环境变量与 Kettle 路径问题现象手动执行kitchen.sh没问题但加到 Crontab 后就是不跑日志也没有。原因Crontab 的环境变量和登录 Shell 不一样JAVA_HOME、PATH可能都没设置导致kitchen.sh找不到 Java 或者找不到 Kettle 的lib目录。解决在 Crontab 里显式导出环境变量或者写一个包装脚本#!/bin/bash export JAVA_HOME/usr/local/jdk1.8.0_301 export PATH$JAVA_HOME/bin:$PATH export KETTLE_HOME/data/kettle/data-integration cd $KETTLE_HOME ./kitchen.sh -file/data/kettle/jobs/daily_load.kjb -levelBasic /data/kettle/logs/cron.log 21包装脚本里cd到 Kettle 目录很重要因为有些插件用相对路径找配置文件。21把错误输出也重定向到日志不然报错了你都不知道。5.5 版本兼容9.3 打开旧版 .ktr 文件时的字段丢失现象用 9.3 打开 8.x 创建的.ktr文件发现某些步骤的配置项变空了或者字段映射丢失。原因9.3 对部分步骤的元数据格式做了调整旧版文件里的某些属性在新版里被重命名或废弃了。解决不要直接在生产环境打开旧文件。先在测试环境用 9.3 打开逐个检查步骤配置特别是「字段选择」「表输出」这类依赖元数据的步骤。确认无误后另存为新文件再部署。如果步骤很多可以用 Kettle 自带的「导出为 XML」功能对比新旧文件的差异定位具体是哪个属性变了。6. 进阶技巧用「映射」子转换和 Carte 集群把 ETL 跑出并行度当你把单机转换跑顺了下一步自然会遇到性能瓶颈——单线程处理几百万行太慢或者多个转换需要共享同一段清洗逻辑。Kettle 提供了两个进阶能力映射Mapping子转换和 Carte 集群。这一章讲怎么用它们以及我踩过的参数坑。6.1 映射子转换把重复的清洗逻辑封装成「函数」假设你有 10 个转换都需要做同样的手机号脱敏和日期格式化。复制粘贴 10 遍是维护噩梦改一个规则要改 10 个地方。正确做法是新建一个子转换clean_phone.ktr只做脱敏和格式化然后在主转换里用「映射」步骤引用它。配置「映射」步骤时需要指定子转换的文件路径以及输入输出字段的对应关系。子转换里的「映射输入规范」定义接收哪些字段「映射输出规范」定义返回哪些字段。主转换把数据传给映射步骤映射步骤调用子转换处理再把结果返回主流程。这样清洗逻辑只维护一份所有调用方自动生效。注意映射子转换里的步骤不能用「数据库连接」以外的外部资源比如文件路径。因为子转换的执行上下文和主转换不同相对路径会解析错。如果子转换要读文件把文件路径作为参数传进去。6.2 Carte 集群把转换拆到多台机器上跑Carte 是 Kettle 的轻量级集群组件启动后是一个 HTTP 服务接收 Spoon 或 Kitchen 发来的转换执行请求。配置步骤在每台 worker 机器上启动 Carte./carte.sh 192.168.1.101 8080在 Spoon 里配置「集群」主菜单 → 工具 → 集群 → 新建填入各 worker 的 IP 和端口。在转换的「转换属性」里把「集群」选项指向刚配置的集群并勾选「在集群上运行」。集群模式下Kettle 会把转换的步骤分配到不同 worker 上执行步骤之间的数据通过网络传输。这里有个关键参数KETTLE_CLUSTER_TIMEOUT默认 60 秒如果网络延迟高或者数据量大要调大不然 worker 之间握手超时就报错。6.3 性能调优参数速查表下面这张表是我常用的调优参数按场景查参数作用建议值适用场景-XmxJVM 最大堆物理内存的 50%~70%所有场景KETTLE_DB_CONNECTION_POOL_SIZE连接池初始大小5~20高并发写入KETTLE_DB_CONNECTION_POOL_MAX_IDLE最大空闲连接2~5连接容易被防火墙断KETTLE_STEP_PERFORMANCE_SNAPSHOT_LIMIT步骤性能快照行数10000调试性能瓶颈KETTLE_ROWSET_SIZE步骤间行集大小1000~5000内存充足时调大提速KETTLE_CLUSTER_TIMEOUT集群握手超时120~300跨机房集群调参的原则是先跑基线看日志里的「步骤性能」输出找到最慢的步骤再针对性调。不要一上来就把所有参数拉满那样只会掩盖真正的问题。6.4 一个验证技巧用「写日志」步骤做数据探针最后分享一个我常用的调试习惯在转换的关键路径上插入「写日志」步骤把行数和关键字段打印出来。比如在过滤步骤前后各加一个写日志日志里输出Rows: ${行数变量}跑一遍就能知道过滤掉了多少行。这个办法比开 Debug 日志轻量比断点调试直观。我一般会在每个转换的入口和出口各放一个写日志步骤输出时间戳和行数这样出问题时一眼就能看出是哪个环节丢的数据。从那以后我每次部署新转换到生产环境都强制走一遍「测试环境全量跑 日志行数比对 目标表抽样校验」这三步再急也不跳过。希望帮到你。本文还有配套的精品资源点击获取