企业官网建设流程全解析

搞数据的人，桌面上基本都躺着一个反复打开的 Spoon。Kettle（Pentaho Data Integration）做 ETL 确实方便，拖拖拽拽就把流程搭好了，但问题很快就来了：业务系统要的是自动化、可监控、点个按钮就能跑，而不是每次人都坐到电脑前手动点“运行”。我在好几个项目里被同一个需求追着跑——“能不能把那个 Kettle 转换集成到我们系统里，定时跑、跑完通知我？”于是就有了这篇实战总结。

这篇内容我打算把 Spring Boot 集成 Kettle 从环境准备、依赖引入、核心 API 调用，到参数传递、日志回传、定时调度、常见坑位一次性讲清楚。适合两类人看：一类是已经把 Kettle 用熟，但没在 Java 工程里嵌入过 Kettle 的开发者；另一类是刚接触 Kettle，想搞明白它运行原理的新手。按这个顺序往下看，大概率能少走我当初踩过的弯路。代码我会尽量给全，同时把每一个“为什么这么干”也解释清楚。毕竟 Kettle 集成的难点从来不是代码量，而是那些坑你预先不知道。

1. 为什么非要把 Kettle 塞进 Spring Boot

1.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-290，Pentaho 公共仓库里坐标比较稳定，API 也相对现代。如果你是老项目，用的还是 JDK 8，那 8.3 或 9.x 都可以选，但真不建议再碰 7.x，Maven 依赖解析和历史 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-java，classpath 里同时有两份驱动时，Kettle 的连接池可能加载到旧的那份，出现连不上或者时区识别错乱的情况。我的做法是：工程里明确排除掉 Kettle 传递依赖中的 mysql 驱动，统一使用自己指定的版本。这类问题排查起来特别耗时间，最好在项目初始就定好驱动矩阵，写进 README。

2.3 Maven 依赖引入与仓库配置

再说依赖引入。Kettle 的核心库并不默认在 Maven 中央仓库，需要额外配置 Pentaho 的公共 Nexus 仓库，或者把本地安装目录下的 jar 用 install-file 命令装进本地仓库。

我给出我的配置方式。第一种，在 pom 里加仓库：

<repositories> <repository> <id>pentaho-public</id> <url>https://public.nexus.pentaho.org/repository/maven-public/</url> </repository> </repositories> <dependencies> <dependency> <groupId>pentaho-kettle</groupId> <artifactId>kettle-core</artifactId> <version>9.2.0.0-290</version> </dependency> <dependency> <groupId>pentaho-kettle</groupId> <artifactId>kettle-engine</artifactId> <version>9.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 -Dfile=kettle-core-9.2.0.0-290.jar \ -DgroupId=pentaho-kettle -DartifactId=kettle-core \ -Dversion=9.2.0.0-290 -Dpackaging=jar

本地库方案的好处是不依赖外部网络，坏处是依赖解析全凭经验，缺一个 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，方法签名尽量简洁，调用方只需要传文件路径和参数 Map：

@Service 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, Map<String, 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, Map<String, 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 密集混合型任务，线程池不适合太小，也不适合无限大。我一般用 corePoolSize=2、maxPoolSize=8、queueCapacity=100 的配置，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 Map<String, Future<KettleResult>> taskStore = new ConcurrentHashMap<>(); @Autowired private KettleService kettleService; public String submitTrans(String fileName, Map<String, String> variables) { String taskId = UUID.randomUUID().toString().replace("-", ""); Future<KettleResult> future = doSubmit(fileName, variables); taskStore.put(taskId, future); return taskId; } @Async("kettleTaskExecutor") public Future<KettleResult> doSubmit(String fileName, Map<String, 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.encoding=UTF-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() { Map<String, 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_HOME=D:\pdi-ce-9.2.0.0-290 call %KETTLE_HOME%\kitchen.bat /file:D:\kettle_jobs\daily_sync.kjb /param:businessDate=20250101

这个方式和 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?useSSL=false&serverTimezone=Asia/Shanghai。这里要注意，Kettle 连接面板和 Spring 数据源两处都可能要改，因为 Kettle 内部执行步骤时用自己的连接配置，不是用 Spring 的数据源。

第二层是治本：看到乱码要意识到 Kettle 默认编码和系统编码不一致。在 Windows 上最好把 Kettle 相关的环境变量、JVM 参数都设置成 UTF-8。在 Linux 上一般好一点，但如果你用容器部署，基础镜像的语言环境是 POSIX，同样会出现编码问题，记得加上环境变量 LANG=zh_CN.UTF-8，或者在启动命令里加 -Dfile.encoding=UTF-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.x，SQL 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，卡在某个报错上，可以照着这篇文章的排查顺序走一遍，应该能解决八九成的问题。后面如果再遇到新的坑，我再单独写一篇来整理。