搞数据的人桌面上基本都躺着一个反复打开的 Spoon。KettlePentaho Data Integration做 ETL 确实方便拖拖拽拽就把流程搭好了但问题很快就来了业务系统要的是自动化、可监控、点个按钮就能跑而不是每次人都坐到电脑前手动点“运行”。我在好几个项目里被同一个需求追着跑——“能不能把那个 Kettle 转换集成到我们系统里定时跑、跑完通知我”于是就有了这篇实战总结。这篇内容我打算把 Spring Boot 集成 Kettle 从环境准备、依赖引入、核心 API 调用到参数传递、日志回传、定时调度、常见坑位一次性讲清楚。适合两类人看一类是已经把 Kettle 用熟但没在 Java 工程里嵌入过 Kettle 的开发者另一类是刚接触 Kettle想搞明白它运行原理的新手。按这个顺序往下看大概率能少走我当初踩过的弯路。代码我会尽量给全同时把每一个“为什么这么干”也解释清楚。毕竟 Kettle 集成的难点从来不是代码量而是那些坑你预先不知道。1. 为什么非要把 Kettle 塞进 Spring Boot1.1 独立运行 Kettle 的三大痛点先从使用场景说起。我见过很多数据团队的日常工作流是Spoon 里画好转换导出 KTR 文件然后在 Windows 上通过计划任务去调用 Kitchen/Pan 命令行执行。听起来没毛病但需求一复杂痛点非常明显。第一个痛点是状态不可控。命令行跑完之后只有一个退出码成功失败你只能靠翻日志文件去猜。业务方问你“昨天凌晨那批数据到底同步了没有”你得打开三四个日志文件才能拼出答案这个体验实在不怎么样。第二个痛点是无法和业务系统联动。数据同步往往是业务流程的一部分用户在前台提交了一个申请后台就要触发一次增量抽取。这种场景靠定时任务根本解决不了需要应用内部直接调用 Kettle 引擎。第三个痛点是运维成本。十几台机器都要装 Kettle、配驱动、维护资源库版本一升级全得重来。如果能像引一个普通第三方库一样把 Kettle 嵌入到统一的 Java 服务里环境一致发布就是打一个 Jar运维负担会小很多。尤其是我最近排查过的新手项目中很多团队连驱动版本不一致的问题都是从这儿来的。1.2 集成方案与技术选型把 Kettle 集成进 Java 工程的方案其实就两条主线。第一条是大而全的方案引入 Pentaho 完整平台组件比如 Pentaho Server、BA Server通过 REST 接口提交任务。功能确实强大但系统体量非常重和 Spring Boot 这种轻量应用八字不合我一般不推荐。第二条就是轻量嵌入方案直接在 Spring Boot 工程里引入 Kettle 核心库通过 KettleEngine API 执行 KTR 和 KJB 文件。不需要额外部署服务也不依赖图形界面Jar 包跑起来就能调用转换。我这次要讲的就是这条线。轻量嵌入方案里面还有资源库和本地文件两种方式。资源库方式适合 Kettle 文件集中管理、多人协作的场景但会在应用里多一层 Repository 依赖配置繁琐。本地文件方式直接只要把 KTR / KJB 文件路径传给 API 就行最适合大多数中小团队。我自己的习惯是文件放在应用可以访问到的固定目录需要调整转换时用 Spoon 改完另存。开发环境甚至可以不用重启服务这在小团队里非常省事。2. 环境和准备版本选型与 JDBC 驱动的坑2.1 Kettle 版本选择与 Java 环境匹配Kettle 的版本选择是整个集成里经常被忽略但非常重要的一环。不同版本的 API 有差异如果你在网上抄了一个 7.x 的代码片段去跑 9.x 的依赖大概率会踩到同名类但方法签名不同的坑。我实际用的是 9.2 这个版本线也就是 PDI 9.2.0.0-290Pentaho 公共仓库里坐标比较稳定API 也相对现代。如果你是老项目用的还是 JDK 8那 8.3 或 9.x 都可以选但真不建议再碰 7.xMaven 依赖解析和历史 bug 修复上维护成本太高。有一点必须先说Java 版本和 Kettle 版本必须要匹配。Kettle 9 依赖 Java 8 以上的特性但如果你用 Java 17 或更高版本编译和运行时容易碰到模块化限制比如 JAXB 被移出 JDK 这类问题。我用 Java 8 / Java 11 跑 Kettle 9.2 是最稳的如果你非要用 Java 21建议至少把 JAXB 相关依赖显式引入不然启动时会收到一堆 ClassNotFound 的问候。下载安装这块我简单提一句因为搜“kettle下载安装教程”的人非常多。Kettle 不需要安装器去官网下载对应版本的压缩包解压后根据操作系统运行 Spoon.bat 或 Spoon.sh 就行。解压出来是一个 pdi-ce-xxx 目录里面最关键的是 lib 目录后续我们要用到的一些依赖 jar 就躺在这里。2.2 最容易被放倒的 JDBC 驱动问题接着聊驱动。做数据同步必然要连各种数据库Kettle 自带一批驱动但企业里常用的 Oracle、老版本 MySQL 驱动经常不在自带清单里需要手动补。热词里有人问“kettle ojdbc6.jar 11.2.0.4”说明大家在 Oracle 连接上栽过跟头。ojdbc6 对应的是 JDK 6 时代的 Oracle 11.2.0.4 驱动Kettle 连接面板里虽然有 Oracle 选项但如果你在转换里配置的数据库连接一直报驱动找不到最简单的处理是把 ojdbc6.jar 或 ojdbc8.jar 拷贝到 Kettle 安装目录的 lib 文件夹下重启 Spoon。在 Spring Boot 集成场景里则要把对应的 ojdbc 依赖加到工程的 pom 里Kettle 运行时才能找到驱动类。这里还有一个很隐蔽的坑Oracle 驱动和 MySQL 驱动的版本冲突。Kettle 自带的 MySQL 驱动往往比较老如果你在 pom 里额外引入新 mysql-connector-javaclasspath 里同时有两份驱动时Kettle 的连接池可能加载到旧的那份出现连不上或者时区识别错乱的情况。我的做法是工程里明确排除掉 Kettle 传递依赖中的 mysql 驱动统一使用自己指定的版本。这类问题排查起来特别耗时间最好在项目初始就定好驱动矩阵写进 README。2.3 Maven 依赖引入与仓库配置再说依赖引入。Kettle 的核心库并不默认在 Maven 中央仓库需要额外配置 Pentaho 的公共 Nexus 仓库或者把本地安装目录下的 jar 用 install-file 命令装进本地仓库。我给出我的配置方式。第一种在 pom 里加仓库repositories repository idpentaho-public/id urlhttps://public.nexus.pentaho.org/repository/maven-public//url /repository /repositories dependencies dependency groupIdpentaho-kettle/groupId artifactIdkettle-core/artifactId version9.2.0.0-290/version /dependency dependency groupIdpentaho-kettle/groupId artifactIdkettle-engine/artifactId version9.2.0.0-290/version /dependency /dependencies这里要提醒一下如果公司内网用不了外部仓库就退回到本地 jar 方案。具体操作是从 Kettle 安装目录的 lib 下找到 kettle-core-9.2.0.0-290.jar、kettle-engine-9.2.0.0-290.jar以及它们依赖的 commons-logging、guava 等 jar逐个执行mvn install:install-file -Dfilekettle-core-9.2.0.0-290.jar \ -DgroupIdpentaho-kettle -DartifactIdkettle-core \ -Dversion9.2.0.0-290 -Dpackagingjar本地库方案的好处是不依赖外部网络坏处是依赖解析全凭经验缺一个 jar 就报 NoClassDefFoundError排错比较费时间。我的建议能联网用公共仓库就用公共仓库第一次构建下载时间长一点后面就顺畅了。3. 核心原理Kettle 嵌入调用的 API 逻辑3.1 引擎初始化的正确姿势Kettle 本质是一个独立的数据处理引擎通过 KettleEnvironment 类来初始化整个运行时环境。Spring Boot 工程里我们要把这个初始化动作放到应用启动阶段执行而且只执行一次。Kettle 引擎初始化会做很多事情加载插件系统、注册数据库驱动、初始化日志系统、准备各种扩展点。如果你漏了这一步直接 new TransMeta通常会遇到 NullPointerException 或者各种插件找不到的报错。我建议把初始化放在一个配置类里用 PostConstruct 确保 Spring 容器启动后就绪Configuration public class KettleConfig { PostConstruct public void initKettleEnvironment() { if (!KettleEnvironment.isInitialized()) { KettleEnvironment.init(); } } }注意这里不要盲目调用 KettleEnvironment.init()加上 isInitialized 判断更保险因为单元测试或者应用重启时可能重复初始化。还有极少数情况不同 ClassLoader 加载了两份 Kettle 类导致 isInitialized 一直返回 false那就要检查依赖冲突把重复的 jar 排除掉。这个我在第 6 章会展开讲。3.2 转换Transformation的执行链路理解执行链路比记代码重要。一个 KTR 文件通过 TransMeta 加载其元数据它描述的是步骤、连接、映射等结构定义Trans 才是运行时对象负责真正执行这个结构并维护行集、变量、日志等运行时状态。执行的基本流程是new TransMeta 加载元数据 - new Trans 创建运行时实例 - 可选地设置变量或参数 - execute 启动 - waitUntilFinished 阻塞等待 - 通过 getErrors 判断结果。这里最容易被忽略的是 execute 方法的参数它对应命令行运行 Kettle 时传入的参数数组如果代码里没用到传 null 或者 new String[0] 都行但千万不要传一个带内容的数组否则可能影响参数解析。我写一个最精简的转换执行代码TransMeta transMeta new TransMeta(ktrPath); Trans trans new Trans(transMeta); trans.setVariable(batchDate, 20250101); trans.execute(new String[0]); trans.waitUntilFinished(); if (trans.getErrors() 0) { throw new RuntimeException(Kettle 转换执行失败错误数 trans.getErrors()); }这里有个经验Kettle 步骤里最常用的占位符是 ${batchDate} 这种写法解析的是变量作用域。使用 trans.setVariable 设置变量在大部分场景下都能生效。如果脚本步骤里要读参数需要结合 TransMeta 的 getParameterValue 或事件监听器很多时候造成困惑是因为把“变量”和“参数”两个概念混在一起。我自己用下来的结论优先用变量简单直接符合 Spoon 里的 ${} 习惯。3.3 作业Job与参数传递机制KTR 负责数据处理KJB 是作业用来编排多个转换也支持循环、条件判断、发送邮件等。Spring Boot 里执行 KJB 的 API 和 Trans 类似但注意Job 的启动方式是 run()不是 execute()。一个典型的作业执行代码如下JobMeta jobMeta new JobMeta(kjbPath, null); Job job new Job(null, jobMeta); job.setVariable(batchDate, 20250101); job.run(); job.waitUntilFinished(); if (job.getErrors() 0) { throw new RuntimeException(Kettle 作业执行失败错误数 job.getErrors()); }这里有个细节new JobMeta 的第二个参数是 Repository我们用本地文件方式直接传 null。如果传了一个不存在的资源库反而会报错。还有作业里的变量传递方向值得注意Java 代码里用 job.setVariable 设置的变量会传递给作业内部包含的所有转换但转换里如果单独设置了同名变量可能会覆盖外层值。遇到变量“传不进去”的情况先检查作业里是否在“设置变量”步骤中重新赋值或者作业入口是否勾选了不继承外部变量的选项。4. 完整实操Spring Boot 集成代码落地4.1 封装 KettleService 服务类上面的 API 是底座但直接暴露给 Controller 不合适我们需要封装一个专门的服务类。这个服务类要解决几个问题引擎初始化、KTR / KJB 统一入口、参数标准化、日志回传、错误状态。我设计了一个 KettleService方法签名尽量简洁调用方只需要传文件路径和参数 MapService public class KettleService { private static final String KETTLE_FILE_BASE /data/kettle/; PostConstruct public void init() { if (!KettleEnvironment.isInitialized()) { KettleEnvironment.init(); } } public KettleResult executeTrans(String fileName, MapString, String variables) { try { String filePath KETTLE_FILE_BASE fileName; TransMeta transMeta new TransMeta(filePath); Trans trans new Trans(transMeta); if (variables ! null) { variables.forEach(trans::setVariable); } trans.execute(new String[0]); trans.waitUntilFinished(); KettleResult result new KettleResult(); result.setSuccess(trans.getErrors() 0); result.setErrorCount(trans.getErrors()); result.setLog(collectLog(trans.getLogChannelId())); return result; } catch (Exception e) { throw new RuntimeException(Kettle 转换执行失败, e); } } public KettleResult executeJob(String fileName, MapString, String variables) { try { String filePath KETTLE_FILE_BASE fileName; JobMeta jobMeta new JobMeta(filePath, null); Job job new Job(null, jobMeta); if (variables ! null) { variables.forEach(job::setVariable); } job.run(); job.waitUntilFinished(); KettleResult result new KettleResult(); result.setSuccess(job.getErrors() 0); result.setErrorCount(job.getErrors()); result.setLog(collectLog(job.getLogChannelId())); return result; } catch (Exception e) { throw new RuntimeException(Kettle 作业执行失败, e); } } private String collectLog(String channelId) { int start 0; int end KettleLogStore.getLastBufferLineNr(); StringBuilder sb new StringBuilder(); KettleLogStore.getLogBufferFromTo(channelId, start, end) .forEach(event - sb.append(event.getMessage()).append(\n)); return sb.toString(); } }这里有几个设计上的考量。文件路径统一放到系统配置里不散落在业务代码中方便换环境。参数用 Map 透传调用方不需要关心 Kettle 变量机制内部的细节。日志采集用 KettleLogStore 存量日志避免自己写监听器实时性差一点但稳定性好、够用。如果你要在高并发下精确区分日志那是另一个话题我后面会提一嘴。对应的 KettleResult 类很轻量public class KettleResult { private boolean success; private long errorCount; private String log; // 省略 getter / setter }4.2 暴露接口与异步执行有了 Service 还不够业务系统里直接同步等一个 ETL 跑完显然不现实尤其是抽取大数据量时一个转换可能跑十几分钟。所以接口层要设计成异步任务模型提交任务返回任务 ID前端通过任务 ID 轮询状态或者用 WebSocket 推送结果。我之前的做法是用 Spring 自带的 Async 配合线程池。注意 Kettle 执行是 CPU 密集和 IO 密集混合型任务线程池不适合太小也不适合无限大。我一般用 corePoolSize2、maxPoolSize8、queueCapacity100 的配置ETL 场景下并发跑的转换不会特别多真遇到突发流量宁可排队也不要去打爆数据库。Configuration EnableAsync public class AsyncConfig { Bean(kettleTaskExecutor) public Executor kettleTaskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(2); executor.setMaxPoolSize(8); executor.setQueueCapacity(100); executor.setThreadNamePrefix(kettle-); executor.initialize(); return executor; } }任务服务层这样写Service public class KettleTaskService { private final MapString, FutureKettleResult taskStore new ConcurrentHashMap(); Autowired private KettleService kettleService; public String submitTrans(String fileName, MapString, String variables) { String taskId UUID.randomUUID().toString().replace(-, ); FutureKettleResult future doSubmit(fileName, variables); taskStore.put(taskId, future); return taskId; } Async(kettleTaskExecutor) public FutureKettleResult doSubmit(String fileName, MapString, String variables) { KettleResult result kettleService.executeTrans(fileName, variables); return new AsyncResult(result); } }Controller 层就很简单了接收参数后调用 submit 方法立即返回 taskId。再提供一个查询状态接口内部通过 Future 的 isDone 判断是否结束get 拿到最终结果。这种模式很成熟比自己在代码里写 while 循环等状态要干净得多。4.3 日志归集与状态回传日志归集是很多项目集成 Kettle 时做得最差的一块。有时业务方抱怨“任务失败了但看不到原因”其实就是日志没有落库或者没有回传。我的方案是双轨制KettleResult 里带一份执行日志同时把关键状态写进一个任务日志表。如果 Kettle 本身在 KTR 里配置了“写日志表”步骤那是 Kettle 进程内的日志而我们更关心的是应用层对任务生命周期状态的记录比如什么时间提交、什么时间开始执行、执行了多久、错误数量、最后一条错误日志是什么。日志表字段可以简单设计为task_id、file_name、task_type、status、start_time、end_time、error_count、log_content。这里不需要复杂表结构业务方查问题只需要看 log_content 和 error_count。但要注意Kettle 日志可能很长log_content 字段建议用 Text 或 LongText 类型避免超过 VARCHAR 长度把日志写失败。实际项目中我还遇到过日志乱码问题尤其是 Windows 环境下执行 Kettle 脚本中文乱码非常普遍。解决套路是JVM 启动参数加 -Dfile.encodingUTF-8同时检查 Kettle 安装目录下的配置是否设置了 UTF-8。在 Spring Boot 里重点保证启动脚本里明确指定编码而不是依赖系统默认编码。5. 进阶实操批处理、日期遍历与自动部署5.1 在 KTR 里设计批量日期遍历查数数据抽取场景里最典型的需求是“遍历一段日期把每一天的数据都查出来”。有人会写一个巨大的 SQL 从 startDate 到 endDate 一次性拉取但数据量大时容易把内存打爆。正确的姿势是在 Kettle 里做日期循环。实现方式很多我常用的是 Job 配合“循环日期”的 JavaScript 步骤。具体来说在 Job 里设置一个起始日期和一个结束日期变量用 JavaScript 计算当前是否越界越界就跳转到作业结束否则把当前日期传给转换并追加日期然后回到循环判断。这里有个关键点Kettle 的 Job 是流程编排器但它的循环能力不像编程语言那么直观。用 Jump 条件连线时要小心死循环。我的实践经验是用一个简单的变量计数器来控制循环次数每次循环加 1超过设定的最大天数就退出。这样即使日期判断逻辑写错最多跑完一个上限不会永久卡住。在转换内部日期参数通过 SQL 里的 ${currentDate} 变量引用SQL 写法类似SELECT id, name, amount FROM daily_order WHERE biz_date ${currentDate}这样每个日期只抽取一天的数据内存占用可控而且中间某个日期跑失败重跑时只需要调整起始日期即可。这种“日增量循环”模式在报表数据同步场景里非常好用。5.2 Windows 部署后如何自动执行转换和作业热词里专门有人问 Windows 部署后怎么自动执行看来这个场景确实普遍。在 Windows 上没有 crontab大家常规用的是任务计划程序。在 Spring Boot 集成场景里任务调度应该尽量在应用内完成而不是依赖外部计划任务。原因很简单应用内调度可以拿到执行状态能写日志能统一配置。外部计划任务只会无脑调接口失败重试、依赖关系都难管理。我建议在 Spring Boot 里直接用 Scheduled 注解加自定义调度线程池。比如每天凌晨 2 点执行前一天的增量抽取Component public class KettleScheduler { Autowired private KettleService kettleService; Scheduled(cron 0 0 2 * * ?) public void runDailySync() { MapString, String variables new HashMap(); variables.put(businessDate, LocalDate.now().minusDays(1).format(DateTimeFormatter.BASIC_ISO_DATE)); KettleResult result kettleService.executeJob(daily_sync.kjb, variables); if (!result.isSuccess()) { // 通过邮件或企业微信机器人告警 } } }如果你确实需要在进程外调度Kettle 提供了命令行工具 Kitchen执行作业和 Pan执行转换。Windows 下写一个 bat 脚本然后用任务计划程序触发即可。bat 内容大致是echo off set KETTLE_HOMED:\pdi-ce-9.2.0.0-290 call %KETTLE_HOME%\kitchen.bat /file:D:\kettle_jobs\daily_sync.kjb /param:businessDate20250101这个方式和 Spring Boot 集成其实是两条路实际项目里可以共存核心业务跑在应用内临时的数据修复任务用命令行脚本。不过我的建议是如果系统复杂度上来了尽量收敛到应用内命令行只作为应急手段。5.3 用调度表驱动任务的实践经验你要管理的 KJB / KTR 数量多了Scheduled 里写死的 cron 就不好维护了。这个时候建议引入一张任务配置表字段包括任务名称、文件路径、cron 表达式、是否启用、最近执行时间等。定时框架可以继续用 Spring 自带的调度也可以用 Quartz。在任务调度这个层面Quartz 完全够用把 Kettle 任务看成 Quartz 里的 Job 即可Quartz 负责触发器管理Kettle 真正执行 ETL。如果你已经在用 XXL-Job 这类分布式调度平台那就更简单了把 KettleService 暴露成执行器任务调度平台统一管理执行计划这也是我目前最喜欢的架构方式。不管选哪种调度器有个点必须提前考虑同一个 KJB 文件如果被两个调度任务同时触发Kettle 的变量在同一个 JVM 里可能互相覆盖。我的处理方式是给每次执行都生成一个独立的执行 ID并且把 KTR / KJB 的输入输出文件路径全部做成带执行 ID 的目录比如 /data/kettle/output/{taskId}/这样即使并行跑也不会撞文件。这个习惯让我少踩了很多并发问题。6. 常见问题与排查实录6.1 “the server time zone value” 乱码问题这个报错几乎在每个连 MySQL 的项目里都会遇到。完整报错一般是 “The server time zone value ?й??????? is unrecognized” 之类在 Windows 上经常变成一堆乱码。其实问题本质是 MySQL JDBC 驱动要求客户端显式指定时区而咱们连的 MySQL 服务器时区参数可能是不太规范的字符串驱动解析不了。解决办法有两层。第一层是治标在数据库连接 URL 上加上 serverTimezone 参数比如 jdbc:mysql://localhost:3306/test?useSSLfalseserverTimezoneAsia/Shanghai。这里要注意Kettle 连接面板和 Spring 数据源两处都可能要改因为 Kettle 内部执行步骤时用自己的连接配置不是用 Spring 的数据源。第二层是治本看到乱码要意识到 Kettle 默认编码和系统编码不一致。在 Windows 上最好把 Kettle 相关的环境变量、JVM 参数都设置成 UTF-8。在 Linux 上一般好一点但如果你用容器部署基础镜像的语言环境是 POSIX同样会出现编码问题记得加上环境变量 LANGzh_CN.UTF-8或者在启动命令里加 -Dfile.encodingUTF-8。6.2 驱动加载失败与 ClassNotFound集成 Kettle 后最常见的异常有两类一是转换里有数据库连接运行时报找不到驱动二是 Spring Boot 启动时就报 NoClassDefFoundError / NoSuchMethodError。驱动找不到的排查路径很简单确认数据库类型再确认 classpath 里是否有对应驱动。报错信息里通常会有 “Driver class oracle.jdbc.driver.OracleDriver was not found” 这样的关键字说明 Kettle 连接配置里的驱动类别与实际引入的 jar 不匹配。Oracle 要用 ojdbc 系列MySQL 8 要配 mysql-connector-java 8.xSQL Server 要用 mssql-jdbc。驱动要放在 Spring Boot 可加载的 classpath 中最简单是加到 pom 依赖。NoSuchMethodError 这类则多半是依赖冲突。Kettle 自带的老版本 guava、commons-* 库和 Spring Boot 自带的版本不一致JVM 加载了旧版本的类调用新方法就报错。解决思路是先用 mvn dependency:tree 查看依赖树确定冲突点再用 exclusions 排除 Kettle 传递进来的旧版本库统一用 Spring Boot 管理的版本。这里没有捷径只能慢慢对照。6.3 内存溢出、并发冲突和文件路径问题ETL 是内存消耗大户。一个大表几千万行Kettle 默认的行集缓冲可能直接让 JVM 堆外溢。我建议给 JVM 堆内存留足空间同时最关键的是在 KTR 设计阶段就使用“分页 流式读取”的思路不要一个步骤试图把所有数据全 load 进内存。并发冲突这个坑我前面提到过主要是变量互相覆盖的问题。另一种情况是多个并发任务同时写一个输出文件导致文件锁冲突或数据错乱。所以每个任务的输出路径、临时文件路径尽量带上任务 ID。Kettle 本身的数据源连接池也需要关注某些旧版本 Kettle 连接池在某些驱动下不支持并发获取连接报连接池耗尽错误时先看是不是同一时间跑的转换太多。还有文件路径问题。如果你把 KTR / KJB 文件放到 Spring Boot Jar 包内部的 resources 目录运行时用 new TransMeta(file:...) 去加载是不稳定的因为 fat jar 里文件不是普通磁盘路径。我推荐把 ETL 文件放在 Jar 外部的固定目录通过配置项注入路径。要么就在程序启动时把 classpath 下的文件复制到临时目录再加载但这个方案在文件更新时并不方便。实际项目经验KTR / KJB 文件放外部目录配合版本管理是最省心的。6.4 Excel 列转行、JSON 输出等数据处理要点热词里有人问 Excel 列转行怎么处理我顺带说下。Kettle 里做列转行有两个步骤Row Normaliser行规约做“列转行”Row Denormalizer行逆规约做“行转列”。Excel 导入后如果一列包含多个维度你希望拆成多行用的就是 Row Normaliser选中要拆的列配置 target 字段名和要生成的新列即可。不过要提醒的是Kettle 的“行转列 / 列转行”在数据量偏大时性能一般更适合数据准备阶段的小规模处理。如果是几百万行级别的宽表转长表我更推荐在 SQL 层或 Java 层用流式逻辑处理把 Kettle 聚焦在它最擅长的流程编排和多种异构数据源抽取上。还有热词里提到 Kettle 转换成 JSON其实可以直接用 JSON Output 步骤也可以把 Kettle 的结果集转成列表然后在 Spring Boot 里用 Jackson 序列化。我通常是在 Kettle 里把查询结果写到一个临时表或文本文件应用层再读取并组装接口所需的 JSON 结构。这样职责边界清晰Kettle 专注取数应用专注接口两边都好维护。这几年我用这套方式在多个项目里把 Kettle 从桌面工具变成了应用内可调度的数据引擎最大的体会是千万不要一上来就追求功能大而全先把一条最小链路跑通把日志和异常处理做好再慢慢扩展。像时区、驱动冲突这类坑提前在文档里记下来团队其他人就不会再踩一遍。如果你也在做 Spring Boot 集成 Kettle卡在某个报错上可以照着这篇文章的排查顺序走一遍应该能解决八九成的问题。后面如果再遇到新的坑我再单独写一篇来整理。