简介Kettle 7.1是一套经典开源ETL工具完整发行包面向数据仓库、数据集成及大数据开发人员用于解决多源数据抽取、清洗、转换与加载问题。基于Java跨平台运行自带Spoon图形化界面支持无编码拖拽式搭建数据管道可对接传统数据库、文件、大数据平台及流数据源。压缩包共包含1928个文件以1302个Java归档库、200个Kettle转换文件、99个XML配置及大量脚本、界面资源为主整体体积约827MB目录组织完整便于直接部署和二次开发。包内附有可运行启动脚本、示例作业与转换、数据库驱动及各类配置文件其中ktr与kjb文件可直观展示转换和作业流程能有效帮助使用者快速搭建环境并参考实际管道设计。该资源已有1485人学习下载适合需要离线安装或研究Kettle内部结构的初中级ETL开发者。1. 开源的ETL工具 Kettle 7.1为什么十年后还有一堆项目在用它你翻开任何一份七年前的数据仓库项目文档大概率能在技术选型那一页看到 Kettle。如今新一代 ETL 工具层出不穷但生产环境里还在跑 Kettle 7.1 的团队一点不少。这个版本之所以被很多老项目锁死不是因为情怀而是因为它把“能干活”三个字贯彻得很彻底数据抽取、转换、加载的每个环节都有图形化步骤部署就是解压一个压缩包驱动放到 lib 目录就能连库新手上手成本极低。开源的 ETL 工具里Kettle 7.1 是资料最全、网上的报错解决方案最多的一代之一。这篇笔记面向正在做数仓初建、报表库同步、或者想把手工导数据的活改成定时任务的人按工程项目里的落地顺序来讲组件怎么选、怎么跑通第一条同步链路、哪些参数必须改、哪些坑我替你踩过。2. 先把 Kettle 的运行模型拆开转换、作业与四个启动器的分工2.1 转换ktr和作业kjb的区别用到什么选什么Kettle 7.1 的核心概念只有两个转换Transformation和作业Job。新手最容易混淆的地方是把它们当成同一种东西其实分工完全不同。转换解决“一条数据流怎么走”。它由步骤Step和跳Hop组成步骤是具体的处理动作——读表、过滤、字段选择、拼接、写表跳是步骤之间的数据通道。数据以行的形式从输入步骤流向下游整个过程是流式的上一行处理完下一行才进来。所以转换强调的是单条数据如何处理一个转换里可以有几十个步骤但它只解决一段数据加工逻辑。作业解决“整个任务怎么调度”。它把转换、发送邮件、检查文件是否存在、执行 SQL 脚本、删除文件这些动作按顺序或者按条件串起来。作业里的组件叫“作业项”Job Entry作业项之间用箭头连接表示执行顺序。真正跑定时任务时你调度的一定是作业而不是转换。从文件后缀也能看出门道转换文件是.ktr作业文件是.kjb。在 Spoon 图形界面里新建转换和新建作业是两个独立的入口。我一般会按这个标准区分只要是“这张表的数据要经过几步加工后落到另一张表”就建转换只要是“每天凌晨三点先把数据抽过来再发一封邮件通知失败了重跑一次”就建作业。2.2 Spoon、Pan、Kitchen、Carte四个组件谁在什么时候用Kettle 7.1 解压后有四个核心启动脚本很多初次接触的人只认识 Spoon导致项目上线后不知道用什么执行还以为必须开着图形界面跑。这四个组件各自守一个位置。Spoon是图形化设计工具负责建转换、建作业、调试。日常开发基本都在它里面完成。但在生产环境里Spoon 不是一个适合常驻的工具它本身要占几百 MB 内存图形界面在远程服务器上也不方便。很多人以为要拿 Spoon 挂着跑定时任务这是最大的误解。Pan是命令行执行转换的入口。它能直接运行一个.ktr文件并支持通过参数把值传进去。服务器上的定时任务如果要执行某个转换一般用 Pan。Kitchen是命令行执行作业的入口。它跑的是.kjb文件负责按作业里定义的顺序去调度各个转换和作业项。生产环境里 crontab 调度的对象绝大多数是 Kitchen。Carte是嵌入式服务器。它可以把一个转换发布成远程可调用的 HTTP 服务主要用于集群和跨机器调度。单机同步的团队基本用不到但需要并发执行多个转换时会发现它很有用。组件文件作用使用场景SpoonSpoon.sh / Spoon.bat图形化设计转换、作业开发、调试PanPan.sh / Pan.bat命令行执行转换直接跑 ktrKitchenKitchen.sh / Kitchen.bat命令行执行作业跑 kjb、定时调度CarteCarte.sh / Carte.bat远程执行转换/作业集群、并发执行2.3 7.1 与新版本的关键差异为什么有人专门锁这个版本Kettle 7.1 之后Pentaho 的版本号策略和周边生态发生了不少变化7.1 也因此成了一部分团队刻意保留的版本。首先要理解一个背景Kettle 的开源版本中7.1 是社区资料最完整的代际之一网上搜得到的问题几乎都有对应博客或论坛帖子。团队接手老项目时遇到问题能靠搜索引擎解决这个隐性价值非常大。从使用习惯上看7.1 与后续版本有几个明显差异。一是安装包结构相对简单lib目录里放驱动、改几个启动脚本就能用没有额外的容器依赖二是 Spoon 的界面操作逻辑稳定很多 2018 年写的操作教程今天依然能对着做三是它与 Java 8 的配合非常成熟而新版 Kettle 对 JDK 版本的要求更苛刻老机器上反而容易出问题。当然7.1 也不是没有短板它对高版本数据库驱动的适配需要手动处理对大规模并行计算的调度能力弱于新版。但绝大多数中小团队的数据同步场景单机执行、串行调度已经完全够用。选择 7.1 本质上是选择稳定性和资料密度而不是追求功能前沿。这一点在生产选型时要想清楚“旧”不等于“不能跑”但也要接受它需要手工打补丁的现实。3. 跑通第一个同步流程Spoon 建转换命令行定时执行3.1 第一步确认 JDK 与启动脚本把 Spoon 拉起来Kettle 7.1 是基于 Java 8 构建的这一步是整个项目的地基。如果你装的是 JDK 11 或更高版本Spoon 大概率会闪退或者在面板渲染时报各种奇怪的错。这里的教训是先确认版本再启动工具顺序别反。# 查看当前默认 JDK 版本 java -version # 如果返回的不是 1.8.x需要显式切换 # 假设 JDK 8 安装在 /usr/lib/jvm/java-8-openjdk-amd64 export JAVA_HOME/usr/lib/jvm/java-8-openjdk-amd64 export PATH$JAVA_HOME/bin:$PATH java -version这段命令的作用是确保 Kettle 7.1 的启动脚本拿到的是 JDK 8而不是系统默认的其他版本。为什么非要用 JDK 8因为 7.1 的启动脚本和嵌入组件是按 Java 8 编译的在高版本 JDK 上运行时经常遇到类库访问权限被拒绝的问题尤其是 Spoon 的图形界面和内部数据库组件表现得非常像“玄学”。如果 JDK 8 是解压安装的一定要显式设置JAVA_HOME再启动。确认无误后进入 Kettle 7.1 解压目录执行启动cd /opt/data-integration ./spoon.sh能看到 Spoon 的欢迎界面并成功新建转换说明基础环境没问题。Windows 上对应的是Spoon.bat双击即可。如果启动报了UnsupportedClassVersionError不用怀疑百分之百是 JDK 版本的问题回到上一步切换回 JDK 8 就行。3.2 建立一张表的最小抽取链路表输入到表输出的操作路径打开 Spoon 后按下CtrlN新建一个转换。这时你会看到一个空白的画布左侧栏是步骤面板右侧空白区域用来搭建数据流。要完成“从 A 表抽数据到 B 表”这个最小闭环只需要两个步骤。首先从左侧面板的“输入”分类中找到表输入Table Input拖到画布上。双击它会看到一个配置窗口最上面是数据库连接选择。如果没有现成连接点“新建”创建选择对应的数据库类型填主机、端口、库名、用户名和密码。需要注意Kettle 7.1 自带的连接器中MySQL 驱动停留在 5.x 时代如果连的是 MySQL 8需要先下载 mysql-connector-java 8.x 驱动放到lib目录再重启 Spoon。这个坑在第 5 章会专门展开。接着在 SQL 查询区域写抽取语句。这里有一条实用建议写具体的字段名不要写select *因为后面接表输出时字段映射会少很多麻烦。-- 从源表读取增量数据假设业务时间字段是 update_time SELECT id, user_name, phone, status, update_time FROM src_user_info WHERE update_time 2024-01-01 00:00:00填写完 SQL 后可以点“预览”看前 100 行数据。如果预览正常说明连接和语句都没问题。接下来从“输出”分类中找到表输出Table Output拖到画布上。双击配置选择目标库连接填写目标表名例如ods_user_info。如果目标表不存在可以勾选“SQL 生成”区域中的Generate CREATE SQL一项先让 Kettle 自动生成建表语句并执行。此时画布上已经有“表输入”和“表输出”两个步骤用鼠标从表输入右侧拖出一条连线到表输出这就是 hop表示数据从源表流向目标表。保存这个转换命名为sync_user_info.ktr。这一步已经能完成一张表的全量或增量抽取了点击画布上方的运行按钮就会在本地执行。但这一步只是开发态下一步要把它变成命令行能执行的脚本。3.3 从图形界面到命令行用 Pan 执行转换并动态切换目标表生产环境里没有图形界面所以要把刚建好的转换搬到命令行执行。Kettle 7.1 的转换支持命名参数通过参数把容易变化的值抽出来。这样同一个 ktr 文件可以往不同的目标表里写数据。先在 Spoon 中定义一个命名参数。点击转换画布空白处打开“转换设置”窗口切到“参数”Parameters标签添加一个参数名字写成TARGET_TABLE默认值可以留空或者写ods_user_info。然后把表输出步骤中的“目标表名”改成${TARGET_TABLE}。保存后再执行Kettle 会要求你输入参数值。命令行执行时用 Pan 传入参数值cd /opt/data-integration # 执行转换并传入目标表名参数 ./pan.sh -file/data/etl/sync_user_info.ktr \ -param:TARGET_TABLEods_user_info \ -levelBasic-file指定待执行的 ktr 文件路径-param:TARGET_TABLEods_user_info把命名参数传入参数名必须和 Spoon 里定义的一致大小写敏感-levelBasic指定日志级别Basic 只输出关键节点日志适合日常执行。如果需要看每行数据的变化可以改用-levelRowlevel调试时再用。如果执行过程中有报错Pan 会打印到控制台并返回非零退出码这一步在 crontab 里可以直接用来判断任务成败。3.4 用 Kitchen 编排作业把多张表同步串成凌晨定时任务单张表的同步可以用 Pan 直接跑但实际业务里往往是几十张表按顺序同步有些表之间还有先后依赖。这时候就需要作业来编排。在 Spoon 里按下CtrlAltN新建一个作业。从左侧面板的“通用”分类中拖入一个Start组件再从“转换”分类中拖入一个转换作业项。双击“转换”作业项选择刚刚保存的sync_user_info.ktr文件。同一个作业里可以放多个转换作业项用箭头按顺序连接Kettle 会依次执行。作业保存为sync_nightly.kjb。在服务器上调度时用 Kitchen 执行cd /opt/data-integration # 执行作业把目标表参数传递给作业中的转换 ./kitchen.sh -file/data/etl/sync_nightly.kjb \ -param:TARGET_TABLEods_user_info \ -levelBasicKitchen 的参数格式和 Pan 完全一致-file指 kjb 文件-param向作业传递参数。作业里的所有转换都能直接读到这个参数无需为每个转换单独设置。这就是为什么在 Spoon 里建转换时建议统一使用${...}方式引用目标表名、数据库名等动态值。到这一步你已经有了能跑通的最小链路Spoon 建转换和作业 ⇒ Pan 执行转换 ⇒ Kitchen 执行作业。往 crontab 里加一行0 2 * * * cd /opt/data-integration ./kitchen.sh -file/data/etl/sync_nightly.kjb -levelBasic定时同步就有雏形了。4. 把参数调到不会崩7.1 必改的 JVM 与性能配置4.1 默认堆内存根本不够用修改 Spoon.sh / Pan.sh 的 JVM 参数Kettle 7.1 的默认启动脚本里JVM 堆内存设置的非常保守。默认情况下可能只有 512MB 或 1GB遇到稍大一点的表转着转着就报OutOfMemoryError。这是 7.1 最经典的翻车场景而且很多人不是在开发时遇到是在定时任务跑了半个月后遇到。先看启动脚本里的位置。在># 编辑 spoon.sh / pan.sh / kitchen.sh找到类似这一行 # PENTAHO_DI_JAVA_OPTIONS-Xmx1024m # 修改为 export PENTAHO_DI_JAVA_OPTIONS-Xms512m -Xmx4096m -XX:MaxMetaspaceSize512m -Dfile.encodingUTF-8几个参数对应的问题不一样。-Xms512m是初始堆大小-Xmx4096m是最大堆上限决定了整个进程能用的堆内存-XX:MaxMetaspaceSize控制类元数据区域-Dfile.encodingUTF-8解决的是中文字符编码问题。为什么这三个脚本都要改因为 Spoon 负责开发调试Pan 负责执行转换Kitchen 负责跑作业它们是三个独立的 JVM 进程只改一个不能覆盖所有场景。内存改到多大合适没有绝对标准要看单次抽取的数据量和本机物理内存。服务器有 16GB 内存的话给 Kitchen 分 4~6GB 是常见做法4GB 内存的小机器建议把抽取逻辑改成按天分区拉取而不是盲目加大堆内存。堆内存不是后悔药改大了会带来 GC 停顿变长4GB 以上堆的 Full GC 经常让任务卡顿几十秒。4.2 kettle.properties 里的变量配置统一管理路径与公共参数kettle.properties是 Kettle 7.1 的全局配置文件位置在用户目录下的.kettle文件夹里。很多项目把数据库地址、备份路径、公共过滤条件写死在每个转换里换环境时一个个改非常痛苦。更可取的做法是让它们成为全局变量。# 文件位置~/.kettle/kettle.properties # 项目公共路径 ETL_BASE_DIR/data/etl ETL_LOG_DIR/data/etl/logs # 公共数据库信息仅作为变量参考数据库连接建议在 Spoon 中另配 SRC_DB_HOST192.168.1.10 DST_DB_HOST192.168.1.20 # 公共抽取参数 DEFAULT_BATCH_SIZE5000配置保存后在 Spoon 的转换里可以直接用${ETL_BASE_DIR}这类形式引用。命令行执行时也可以用-param覆盖./kitchen.sh -file/data/etl/sync_nightly.kjb \ -param:ETL_BASE_DIR/data/etl_new \ -levelBasic这个机制解决了一个很隐蔽的痛点同一份 ktr 文件在开发机和服务器上指向不同路径时不需要改文件只需要传不同的参数。项目里维护一套转换部署到多套环境时只需要维护各自环境的kettle.properties和调度脚本。4.3 表输出步骤的批量提交参数让写入速度翻倍的设置点很多人的同步任务慢不是数据库的问题而是 Kettle 默认的提交方式太保守。表输出步骤默认每行一次提交相当于把每条记录都当成一个独立事务在批量场景下性能非常差。在 Spoon 中双击“表输出”步骤在配置窗口找到Commit size提交大小字段默认值是 1建议改成 1000~5000。这个数字的含义是Kettle 攒够多少行再真正写库一次。改成 5000 后写入效率通常会有几倍的提升因为减少了网络往返和事务开销。配置项默认值建议值说明Commit size11000~5000表输出步骤的批量提交行数-Xmx堆内存脚本内置 1024m4096m 视机器而定防止大表 OOM表输入 SQL无尽量带 WHERE 条件减少网络传输日志级别BasicBasic / Rowlevel 调试用降低日志写盘压力除了提交大小表输入步骤也有一个隐藏的优化点SQL 里加WHERE条件做增量过滤宁可拆成多个小抽取也不要一次性拉全表。很多人觉得“抽全表再让 Kettle 慢慢过滤”没毛病但表输入会把全部数据拉到 JVM 内存里再做后续处理源表几百万行时这一步就可能把堆内存打满。更稳的做法是在 SQL 里直接过滤让数据库把压力扛下来。5. Kettle 7.1 的常见坑从驱动到编码的 5 条现场排错记录5.1 启动即报 UnsupportedClassVersionErrorJDK 版本对不上现象执行./spoon.sh控制台直接抛出UnsupportedClassVersionError或者声称org/w3c/dom/Element等类文件无法读取Spoon 界面闪退。原因Kettle 7.1 的 class 文件源于 JDK 8你用 JDK 11 或更高版本运行时部分依赖组件因模块化限制拒绝加载。最典型的是 XML 解析和图形界面相关的库。解决切换到 JDK 8。如果你需要用JAVA_HOME指定路径启动前显式执行一次设置命令。注意只切换JAVA_HOME还不够PATH里如果没有包含新 JDK 的bin目录操作系统仍会调用旧版本。生产服务器上如果同时装了多个 JDK建议在启动脚本顶部加两行export从根上锁死。5.2 MySQL 8 连不上驱动还停留在 5.x 时代现象Spoon 里测试 MySQL 连接报错Unable to load authentication plugin caching_sha2_password或者提示Public Key Retrieval is not allowed。连接测试过不去数据同步无从谈起。原因Kettle 7.1 自带的 MySQL 驱动是 5.1.x而 MySQL 8 默认开启caching_sha2_password认证方式老驱动不认识这种握手协议。即使连接串写成jdbc:mysql://host:3306/db协商阶段就会失败。解决从 Maven Central 下载mysql-connector-java-8.0.x.jar放到 Kettle 的lib目录下删掉或重命名旧的mysql-connector-java-5.1.x.jar重启 Spoon。同时在数据库连接的“选项”里加上allowPublicKeyRetrievaltrue和useSSLfalse避免 MySQL 8 在连接时怀疑身份。这里有个细节不要直接改系统 CLASSPATHKettle 只会扫描lib目录驱动扔别处无效。5.3 中文乱码与文件编码Windows 上最典型的三个乱码源现象表数据里中文变成问号或者日志里出现大量??。在 Windows 开发机上尤其常见同一套转换放到 Linux 服务器上又恢复正常。原因三个位置都可能出问题。第一JVM 默认文件编码在中文 Windows 下是 GBK而数据源是 UTF-8第二数据库连接 URL 没有指定characterEncodingUTF-8第三CSV 文件输入步骤没有设置编码格式。解决JVM 层启动参数加-Dfile.encodingUTF-8JDBC 连接 URL 加characterEncodingUTF-8文本文件输入/输出步骤里明确写UTF-8。如果项目里已经大量扩散了 mess先用SELECT HEX(字段) FROM定位是数据库存储乱码还是读取乱码再决定从哪一层改。5.4 作业执行时找不到转换相对路径的判定基准现象用 Kitchen 执行 kjb 时报错Invalid job entry ... Could not load transformation但同样的文件在 Spoon 里打开运行正常。调度日志里给的路径看起来是对称的就是找不到文件。原因Kettle 的作业项里使用相对路径时路径基准是 Kitchen 启动时的当前工作目录而不是 kjb 文件所在目录。在 Spoon 里调试时工作目录恰好是项目目录所以没问题在服务器上通过 crontab 启动工作目录是 crontab 的家目录相对路径自然失效。解决在作业的设置里把转换的路径改成内置变量方式或者用命名参数统一传。我会在作业创建之初把所有外部引用都写成${ETL_BASE_DIR}/sync_user_info.ktr这样的形式然后在调度脚本里强制传入ETL_BASE_DIR。这样无论从哪个目录启动都不会走偏。顺带一提Windows 下路径里的反斜杠要改成斜杠或双反斜杠否则也会解析失败。5.5 同步到一半内存溢出行集缓存与全量抽取叠加现象转换跑到一半日志出现java.lang.OutOfMemoryError: Java heap space任务失败。重试几次卡在同一个数据量级别。原因表输入一次性把所有记录读进 JVM而表输出步骤的下游如果处理缓慢Kettle 的默认行集会把积压的数据缓存在内存里。两头一叠加堆内存就被打穿。解决双管齐下。第一加大 JVM 堆内存这是基础第二重点在表输入 SQL 里加入分页或时间范围切片让每次抽取的数据量可控。例如针对大表定义一个WHERE update_time ? AND update_time ?的条件然后通过作业循环传入时间片。不要指望 Kettle 自己帮你在内存里管理大数据集它不是这样设计的。6. 用一套分钟级的数据比对法验证同步没丢没重数据抽过去之后最怕的是目标表比源表多几行或者少几行。这里给出一套我在项目里一直用的比对方法先比总数再比分组分布最后按唯一键查重。以 MySQL 为例源表在192.168.1.10目标表在192.168.1.20执行下面的 SQL 完成第一层校验-- 源表行数 SELECT COUNT(*) AS src_cnt FROM src_db.src_user_info; -- 目标表行数 SELECT COUNT(*) AS dst_cnt FROM ods_db.ods_user_info; -- 再看分组分布是否一致以状态字段为例 SELECT status, COUNT(*) AS cnt FROM ods_db.ods_user_info GROUP BY status ORDER BY status;先确认总数一致再做分组分布对比。如果总数一致但分组不一致说明有行被错误合并或字段转换出错。最后检查唯一键是否重复这是 Kettle 在多次重复同步时最容易踩的雷-- 查目标表是否有重复主键 SELECT id, COUNT(*) FROM ods_db.ods_user_info GROUP BY id HAVING COUNT(*) 1 LIMIT 10;这套 SQL 建议直接做成一个比对脚本挂在同步作业的最后一步。我自己的习惯是在 Kitchen 作业里加一个“执行 SQL 脚本”作业项把比对 SQL 放在里面查出来有异常就通过邮件步骤通知。这套流程上线后我再也没有遇到过“数据跑了三天才发现少了一个分区”的事故。最后留一个教训同步逻辑写完先把日志级别调成Rowlevel跑一张小表确认字段映射没有错位再切回Basic跑正式任务。大表全量同步前先手动跑一次带LIMIT 1000的预览看看目标表字段值是否符合预期。我早年因为偷懒跳过这步把源表的时间戳字段直接灌进了日期字段下游报表整整错了一个季度才发现。Kettle 7.1 本身只是工具校验逻辑才是数据质量的最后一道防线。希望这篇笔记能帮你少踩几个坑更快把同步链路稳定跑起来。本文还有配套的精品资源点击获取