简介：webKettle是Pentaho Data Integration的Web化版本，将Kettle强大的ETL能力迁移到浏览器中，适合需要远程协作、跨设备完成数据抽取转换加载工作的数据工程师和运维人员。压缩包内含完整的webKettle部署与运行文件，共1002个、157.7MB，其中jar和class构成核心业务逻辑，png/svg等提供图形界面资源，sh/bat用于启动Spoon、Kitchen、Pan、Carte等组件，xml和properties则覆盖配置需求。包内还收集了12个sh与12个bat脚本，方便在Linux或Windows环境快速启动相应工具，整体目录结构清晰，可帮助使用者省去自行搜集依赖的麻烦。目前已有1549人学习下载，适合希望突破桌面工具限制、快速搭建在线ETL工作台的开发者参考。
1. 先把 kettle 的 web 版用起来：拆包之前，先想清楚三件事
Kettle 的 web 版不是给桌面工具套一层网页皮肤，它的本质是把“单机执行”改成“多人共用一个执行引擎”的 B/S 化改造。这份 zip 要解决的场景很具体：业务方要一个能提交任务、看进度的界面，运维要一份能纳入监控的日志，而你手里已经攒了几十个 ktr 和一堆别人留下的作业。真正难的不是把一个转换搬到页面上跑，而是调度、权限和远端日志这一整套联动关系。我拆过这类包，也帮某个项目搭过一套 WebETL 环境，最大感受是配置点比想象中多，但把链路理顺之后完全可控。适合正在做交付部署、夜间批量同步、或者打算给别人搭执行界面的从业者。
2. 为什么桌面版 Kettle 不能直接上线：调度、协作与资源占用的三个硬伤
如果只有一个人、一台电脑、跑一个转换，用桌面版没有任何问题。一旦任务进入生产环境，问题会从三个方向同时涌过来。
2.1 C/S 界面的致命短板：没人守着 GUI 会话，任务就断
桌面版 Kettle 跑转换时，Spoon 主进程会在前台维护一个执行上下文，界面一旦关闭，正在跑的任务往往跟着停。我曾经见过某个项目用桌面版挂夜间批量，结果屏幕保护程序触发锁屏后远程会话被回收，第二天早上发现转换只跑了三分之一。这不是偶发故障，而是 C/S 结构的天然缺陷：执行上下文绑定在用户会话上，会话消失，任务也就消失了。
常见补救方式是用 nohup 或者让机器保持远程登录不退出，但这些都是临时手段。改到 Web 版之后，正确的做法是把执行上下文绑定在服务端任务实例上，页面只做观察者。换句话说，任务提交之后，即使浏览器关掉，执行节点上的作业必须继续跑完。所以拿到这类 zip 之后，我第一个动作不是看前端界面，而是找里面有没有独立的执行节点模块，比如 Kettle 生态里常见的 Carte 服务，或者类似的独立进程脚本。只有存在这样的模块，这个 web 版才是真正解决了“没人守着会话”的问题。
判断方法很简单：把 zip 解包后，看启动脚本数量。如果一个包里只有一个 web 应用的启动脚本，没有单独的执行节点启动脚本，那它大概率是远程桌面式的改造，生产环境仍然会踩断连的坑。
2.2 多用户、权限与版本冲突：本地 ktr 文件根本管不住
传统方式下，三个开发者在各自电脑上改同一份 ktr，靠网盘共享或者人肉合并。出问题只是时间问题。我在模拟项目 X 里见过一个典型事故：A 同学改了数据库连接，把文件传到共享目录，B 同学没有拉取最新版本，直接基于旧文件改了步骤并覆盖保存，结果第二天定时任务全部连错库，排查了大半天才发现是本地文件覆盖造成的。
桌面版没有真正意义上的“服务端单一版本”概念。ktr 文件本质上是一份 XML 格式的作业描述，两个人同时改，留下来的那一方往往是最后保存的人，而不是改动更合理的人。Web 版如果要解决协作问题，必须把转换文件收归到服务端资源目录，每次执行从服务端读取，日志统一落盘。页面上至少要有上传、列表、版本回退这几个基本功能。没有资源管理接口，只允许本地上传临时跑一下的 web 版，并没有解决多人协作的根源问题。
拆包时我一般会找“资源列表”相关的接口路径，比如/api/repository或者/api/trans这类前缀。如果接口只有 execute 没有 list 和 upload，说明这个资源包把重心放在了执行上，协作能力是缺失的，后面落到多人环境要自己做补齐。
2.3 资源占用与瘦客户端改造：为什么瘦客户端更适合生产
桌面版每个实例都按富客户端启动，加载插件、初始化数据库浏览器、渲染界面，内存占用很容易到 1GB 以上。三个同事同时开着，普通电脑就开始卡。生产服务器上如果每个人都远程桌面进去开一个实例，内存开销是线性增长的。
Web 版的价值在于把资源集中：浏览器只负责提交请求和展示状态，真正吃内存的是服务端执行节点。任务统一排队，执行节点有最大并发限制，不会因为某个人连续点了十次“运行”就把服务器内存打爆。我通常会在资源包配置里找max_jobs、max_trans这类并发参数，把它们设置成与服务器内存匹配的数值，而不是维持默认的无限并发。
瘦客户端改造还有一个容易被忽略的好处：执行节点可以单独配置 JVM 堆大小，而不受客户端环境约束。后续部署章节会详细说，但先记住一个原则：把执行引擎当作独立进程管理，是 Web 版能落地的根基，任何把执行和展示塞进同一个进程的方案，都会在批量任务场景付出代价。
3. 从 zip 到可运行的 WebETL：war 包、执行节点与第一个转换上屏
这一章是完整的落地操作。我一般会把 zip 直接解压到 Linux 服务器，不建议在 Windows 上跑生产环境，原因后面避坑章节会展开。
3.1 解包先看结构：一份标准 Web 版资源里该有什么
拿到 zip 后先不要急着启动，先看目录结构。我用的是这套命令：
unzip kettle-web.zip -d /opt/kettle-web cd /opt/kettle-web tree -L 2 --dirsfirst | head -60-d指定解压目标目录；tree -L 2只展示两层目录，避免输出太长；--dirsfirst让目录排在最前面，方便先看清模块划分；head -60截断输出。我一般会找三类目录：一是 Web 应用相关目录，可能是 war 包或静态页面加上后端 jar；二是执行引擎目录，通常是bin/、carte/或类似名称；三是配置目录，存放数据库连接、日志级别、端口等文件。
如果这些目录都不存在，只有一个可视化页面和一堆打包好的 lib，那这个 web 版可能是“半成品”，后面接执行节点会非常痛苦。如果有 war 包，解包后一般能看到WEB-INF/lib、WEB-INF/classes这样的结构，数据库配置文件通常落在WEB-INF/classes下的application.yml或.properties。
还有一个容易忽略的文件是初始化 SQL 脚本，通常在docs/或者sql/目录。这个脚本会建立任务表、日志表、用户表，是判断资源包完整度的重要依据。没有初始化脚本的包，后面表结构冲突时会很麻烦。
3.2 第一次启动：先改配置，再谈功能
先改端口、改数据库、调堆内存，然后才启动。很多资源包默认带内置 H2 或 SQLite，跑 demo 没问题，换成 MySQL 就卡在驱动或权限上。先做一轮替换：
# 以 conf/application.yml 为例，把端口从 8080 换成 18080 sed -i 's/8080/18080/g' conf/application.yml # 把内置 H2 连接改成 MySQL sed -i 's|jdbc:h2:file:./data/kettle|jdbc:mysql://10.0.0.10:3306/etl|g' conf/application.yml这两条sed是常见的部署预处理。第一条把 Web 服务端口换到 18080，避开默认端口冲突；第二条把 H2 数据库换成 MySQL，注意这里用竖线作为分隔符，是因为 URL 里本身有斜杠，避免转义混乱。改完数据库连接后，要确认 MySQL 驱动 jar 已经放在lib/目录下，没有就把驱动文件复制进去，否则启动时只会报 ClassNotFound。
接着调整执行节点内存。很多资源包默认堆大小只有 256MB，跑大转换直接 OOM：
# 在执行节点启动脚本头部追加 JVM 参数 echo 'JAVA_OPTS="-Xms1g -Xmx2g"' >> bin/start-carte.sh这里-Xms1g表示堆初始值 1GB，-Xmx2g表示堆最大值 2GB。初始值设 1GB 是为了避免启动后频繁扩容，最大值 2GB 是按中等数据量预估的。如果同步量级达到千万行，Xmx 建议给到 3GB 以上，但不要超过物理内存的一半，否则会跟数据库争内存。
然后依次启动执行节点和 Web 服务：
bash bin/start-carte.sh & bash bin/start-web.sh & sleep 10 curl -s http://127.0.0.1:18080/api/health | head -5执行节点先启动，是因为 Web 服务在启动时通常会做一次节点连通性检查。节点没起来，页面能开但任务提交不出去，排错时还会误以为是鉴权问题。sleep 10给两个服务留出初始化时间，curl健康检查接口确认 Web 服务已经响应。如果返回 503 或空内容，去看logs/console_*.out文件，通常会有数据库连接失败或者端口被占用的具体报错。
3.3 让第一个 ktr 跑起来：上传、执行与状态
页面登录后，先在资源管理模块找到上传入口。上传一个本地测试转换：
# 上传本地 ktr 文件 curl -s -F "file=@/data/etl/ods_sync.ktr" \ -H "Authorization: Bearer YOUR_TOKEN" \ http://127.0.0.1:18080/api/trans/upload-F表示文件表单字段，file=@路径指定要上传的文件；Authorization头按资源包实际的鉴权方式替换，有的包用 Cookie，有的用 Token。上传成功后，接口会返回资源 ID 之类的主键。再提交执行：
curl -s -X POST http://127.0.0.1:18080/api/trans/execute \ -H "Content-Type: application/json" \ -H "Authorization: Bearer YOUR_TOKEN" \ -d '{"resourceId":"res_1001","params":{"source_db":"mysql_01","target_table":"ods_user"}}'resourceId对应上传后拿到的资源标识，params里的字段会映射到转换的命名参数。第一次跑强烈建议用只读取少量数据的 ktr，不要直接全量同步，否则排错时分不清是数据问题还是配置问题。
提交执行后，用一个小循环轮询任务状态，确认任务真正进入了执行节点：
task_id=task_20240115_001 for i in $(seq 1 12); do echo "=== check $i ===" curl -s "http://127.0.0.1:18080/api/trans/status?taskId=$task_id" echo "" sleep 5 done这段脚本每五秒查一次状态，连续查十二轮，相当于一分钟的观察窗口。taskId 来自前一个 execute 接口的返回，实际字段名以资源包定义为准。如果轮询过程中返回了SUCCESS和FAILURE，基本可以确定转换已经跑完；如果一直是QUEUED，说明执行节点接收了任务但没在处理，需要去看节点日志。
4. 页面到执行引擎之间的账：JNDI、变量、日志与权限怎么对起来
单个转换跑通只是起点。Web 版 ETL 能不能长期稳定运行，取决于这一章讲的四个联动配置。
4.1 数据源配置：JNDI 与连接池参数
桌面版的数据连接直接存在 ktr 文件里，用户名密码明文不说，改一次连接要重新保存并重新分发。Web 版推荐用 JNDI 方式，把数据库连接放到应用服务器或执行节点的配置里，ktr 内部只引用 JNDI 名称。这样数据库密码只存在服务端配置中，ktr 文件里不会有敏感信息。
一个典型的 Tomcat JNDI 数据源配置长这样：
<Resource name="jdbc/ods_mysql" auth="Container" type="javax.sql.DataSource" driverClassName="com.mysql.cj.jdbc.Driver" url="jdbc:mysql://10.0.0.10:3306/ods?useSSL=false&characterEncoding=utf8" username="etl_user" password="etl_pass" maxTotal="10" maxIdle="5" maxWaitMillis="3000" validationQuery="select 1" testOnBorrow="true" timeBetweenEvictionRunsMillis="60000"/>参数含义如下：name是 JNDI 名称，ktr 里数据库连接类型选 JNDI 时填这个名字；maxTotal是最大连接数，按并发任务数和单任务数据库线程数估算；maxIdle是最大空闲连接数；maxWaitMillis表示拿不到连接时最长等待 3 秒，超过就报错，避免线程无限挂起；validationQuery配合testOnBorrow=true，每次借用连接前执行一次心跳查询，确保拿到的连接是活的；timeBetweenEvictionRunsMillis控制后台清理空闲连接的频率。
配置好后，ktr 里不要再使用 DriverManager 直连方式，否则又退回每步建连的旧路，性能差且容易把数据库连接数打满。我一般会逐个检查 ktr 的数据库连接步骤，确认连接类型是 JNDI，而不是重新填了一次 URL。
4.2 参数传递：从页面表单到转换变量
转换里的 SQL 建议写成带变量占位符的形式，比如SELECT * FROM ${table_name} WHERE update_time >= ${last_time}。这样同一个 ktr，只要页面上传入不同的表名和时间，就能复用在多个同步任务上。
传递链路通常是：页面表单字段 → Web 后端 Map → 执行接口请求参数 → 转换命名参数。上一章 curl 里的params就对应这条链路。如果页面没有传某个变量，转换会退回读取环境变量。启动脚本里也可以设默认值：
export KETTLE_DEFAULT_PARAM_TABLE_NAME=ods_user export KETTLE_DEFAULT_PARAM_LAST_TIME='2024-01-01 00:00:00'命名规则是KETTLE_DEFAULT_PARAM_加变量名。转换里${table_name}没收到页面传值时，会退回到环境变量里的默认值。这个机制对日常运维很友好，白天指定表跑增量，夜间用默认配置跑全量，不需要改 ktr。注意变量名大小写敏感，页面字段与转换变量不一致时，日志里会出现“参数未找到”的警告，排查第一步就是核对名字。
页面上做参数表单时，我一般建议提供“默认值”和“每次执行手动输入”两个模式。默认值给得合理的情况下，操作员每天只需要修改时间范围，出错概率大幅降低。
4.3 日志链路：页面上的进度条是怎么刷出来的
页面显示“已完成 1000 行”看着很直观，实现机制通常是前端在轮询执行节点的任务日志。我在部署时一般会先把执行节点的日志输出重定向到独立文件，而不是只靠页面内存保存：
log_dir=/data/kettle-web/logs exec_time=$(date +%Y%m%d_%H%M%S) nohup bash bin/start-carte.sh \ --logfile "$log_dir/carte_${exec_time}.log" \ --level Basic > "$log_dir/console_${exec_time}.out" 2>&1 &nohup让执行节点脱离当前 SSH 会话继续运行；--logfile指定结构化日志文件；--level Basic是日志级别，可选 Basic、Detailed、Debug、Rowlevel。平时用 Basic，信息量适中且性能影响小；排查行数据处理问题时切到 Rowlevel，能打印每一行数据的内容，但文件增长很快，不要长期开启。> ... 2>&1把标准输出和错误输出都重定向到同一个文件，避免服务启动报错时屏幕上没有信息。
页面状态和日志文件对不上的时候，优先看console_*.out里有没有 JVM 异常，往往比页面上的红字更接近根因。页面上的进度数字通常是节点日志的摘要，节点崩了，页面还在轮询旧状态，就会一直转圈。
4.4 权限与角色：看客、操作员、管理员的边界
多用户场景一定要有角色概念，否则任何人登录都能删任务、改连接，生产事故随时发生。常见权限矩阵按最小权限原则设计：
| 功能 | 看客 | 操作员 | 管理员 |
|---|---|---|---|
| 查看任务与日志 | 只读 | 是 | 是 |
| 执行任务 | 否 | 是 | 是 |
| 上传/修改转换 | 否 | 是 | 是 |
| 修改数据源 | 否 | 否 | 是 |
| 用户管理 | 否 | 否 | 是 |
这个矩阵覆盖了最常见的三类人。看客通常是业务方，他们只需要确认任务有没有跑完；操作员是日常维护数据的同事，能执行和上传转换，但不能碰数据源配置；管理员负责整体配置和用户管理。权限校验一定要在 Web 后端统一做，不能在页面端隐藏按钮就算完事，因为绕过前端直接调 API 太容易了。前面 curl 里用的Authorization头，到了生产环境建议配合 HTTPS，否则 Token 明文暴露在网络上，权限形同虚设。
实际操作中，我通常会给每个数据源单独配置只读账号，避免 ETL 账号权限过大，操作员即使拿到连接信息也无法直接改表。这是防数据事故的最后一道防线。
5. 避坑：Web 化 Kettle 最容易翻车的 5 个现场
把踩过的现场逐一列出来，每一条都按“现象 → 原因 → 解决”整理，方便你直接对照处理。
5.1 中文参数变问号：字符集源头在哪
现象：页面上填的中文表名或时间条件，跑出来的 SQL 中文全变成???，查不到数据；页面提交显示成功，但目标表没有内容。
原因：链路里某个节点用了非 UTF-8 编码。常见是执行节点 JVM 默认编码不是 UTF-8，或者数据库连接串没带characterEncoding参数。还有一种情况是页面提交表单时用了application/x-www-form-urlencoded，后端容器按 ISO-8859-1 解码，中文就变成了乱码。
解决：先给执行节点强制 UTF-8 编码：
export JAVA_OPTS="$JAVA_OPTS -Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8"重启执行节点后再试。如果还乱码，检查数据库连接串是否带了characterEncoding=utf8，同时确认useSSL=false避免证书警告干扰。注意 MySQL 连接串的编码参数要放在 URL 中，放在属性文件里不一定生效。
5.2 定时任务不触发：时区与 cron 表达式的坑
现象：任务是每 5 分钟跑一次，但实际触发总是在整点过后几分钟；有的任务在服务器本地时间正常，放到 Docker 容器里就完全不触发。
原因：服务器系统时区、容器时区、应用 JVM 时区三者不一致。系统是 CST，容器默认 UTC，应用读到的本地时间比北京时间慢 8 小时。cron 表达式本身没有时区概念，执行器按应用所在 JVM 的时区解析。
解决：统一时区：
# 查看当前时区 date +%Z # Linux 服务器设置时区 timedatectl set-timezone Asia/Shanghai # JVM 启动参数兜底 export JAVA_OPTS="$JAVA_OPTS -Duser.timezone=GMT+8"改完时区后，把 cron 往后调两轮，确认能按新时区触发，再切回正式节奏。还有一个容易被忽略的点：Web 版任务调度表里存了next_run_time字段，页面修改 cron 后要确认数据库里这个值同步更新了。有时候页面保存成功，但调度器读的是缓存，旧任务仍然按照老时间触发。
5.3 大转换提交后页面卡死：Web 容器线程阻塞
现象：提交一个千万行的同步任务，几秒后页面一直转圈，刷新也慢，重启 Web 服务才能恢复。
原因：Web 后端把任务提交和执行放到了同一个线程里，执行阻塞时，处理请求的容器线程全被占满，连健康检查接口都响应不了。执行引擎被当成了应用内部的一个方法调用，而不是独立服务。
解决：把执行逻辑从 Web 进程中剥离开。确认执行节点是独立进程：
ps aux | grep -E "start-web|start-carte" | grep -v grep如果只看到一个 Java 进程，说明执行逻辑内嵌在 Web 服务里了，需要按资源包提供的配置把它改成独立模式。临时缓解手段是给 Web 服务单独加大线程池，但这只是拖延。长期必须做到页面提交后立即返回任务 ID，执行由独立节点完成。
5.4 数据库连接反复断开：连接池与执行节点超时
现象：任务白天正常，晚上闲置几小时后，第一次执行必报Connection is not available, request timed out，重试一次又好了。
原因：数据库端有空闲超时机制，把长时间不用的连接回收了，而连接池不知道，还在发放旧连接。连接池的心跳配置没有跟上，导致空闲连接被销毁后没有主动补偿。
解决：回到第 4 章数据源配置，确认validationQuery和testOnBorrow是开启的。如果资源包用的是连接池框架，比如 HikariCP，对应配置是：
spring: datasource: hikari: connection-test-query: "select 1" connection-timeout: 3000 validation-timeout: 1000 idle-timeout: 600000 max-lifetime: 1800000connection-test-query等同于前面的validationQuery；idle-timeout要小于数据库空闲回收时间；max-lifetime要小于数据库的wait_timeout，这样连接在失效前就会被池替换掉。配置完成后，观察一夜，第二天早上手动触发一次任务，确认不再报连接超时。
5.5 日志一直转圈：执行状态回传的丢失
现象：页面显示任务运行中，转圈转了半小时，但检查目标表发现数据根本没有更新；再等一会儿页面显示成功，结果表里依然没有数据。
原因：有两个可能。一是页面轮询的状态接口读的是 Web 后端内存缓存，执行节点进程重启后缓存丢失，页面读不到新内容，只能拿旧状态一直显示。二是日志采集链路阻塞，页面读不到执行节点的最新日志。本质原因是页面把“任务运行中”和“任务执行成功”混为一谈了。
解决：不要以页面状态为最终依据。以执行节点落盘日志和最终结果表为准。排查命令：
grep -E "ERROR|Exception|Finished processing" /data/kettle-web/logs/carte_*.log | tail -20看到Finished processing说明执行节点确实处理完了；看到Exception说明任务执行过程中出了错，但状态回传失败，页面没拿到错误信息。如果连Finished processing都没有，说明任务根本没有到达执行节点，问题出在提交链路，需要去 Web 后端日志里查接口调用记录。
6. 一次完整的观察实验：确认你的 Web 版 ETL 是真在跑，而不是假成功
环境搭好之后，我会用一次带观测点的实验来验证整套链路。先准备一个简单转换：读源表数据，写目标表，中间加一个“增加序列”步骤生成流水号，目标表加一个update_time字段，每次执行写入当前时间。这个设计是为了后续能做行数对比和时间对比。
先提交一个转换执行：
curl -s -X POST http://127.0.0.1:18080/api/trans/execute \ -H "Content-Type: application/json" \ -H "Authorization: Bearer YOUR_TOKEN" \ -d '{"resourceId":"res_1001","params":{"source_table":"ods_user","target_table":"dw_user"}}'拿到返回的任务 ID 后，用循环脚本拉取执行节点日志，观察任务是否真的在节点上跑：
task_id=task_20240115_001 log_file="/data/kettle-web/logs/carte_$(date +%Y%m%d).log" for i in $(seq 1 12); do echo "=== check $i ===" grep "$task_id" "$log_file" | tail -5 sleep 5 done如果日志里始终没有这个任务 ID，说明提交链路断在了 Web 后端；如果出现了任务 ID，但没有步骤级日志，说明转换本身可能卡在了某个数据源连接上。这个脚本的作用不是复杂监控，而是让新环境第一次跑任务时，你能够在终端里看到任务从提交到处理的完整过程。
任务结束后，用 SQL 核对数据是否真正落地：
select count(*) from ods_user; select count(*) from dw_user; select count(*) from dw_user where update_time >= now() - interval 30 minute;前两条 SQL 对比源表和目标表行数，第三条确认目标表里确实有本次执行写入的新数据。行数一致，并且目标表里能看到本次执行时间戳，才算真正成功。最后再用状态接口做一次复核：
curl -s "http://127.0.0.1:18080/api/trans/status?taskId=$task_id" | grep -o "SUCCESS\|FAILURE"从那以后，我每次为 Web 版 ETL 上线新转换，不管任务多简单，都强制走一遍“提交 → 日志对拍 → 行数核对 → 状态码复核”的流程。这套方法帮我排查过多次假成功：页面显示完成，但目标表数据纹丝不动。执行节点日志和最终结果表才是唯一真相，页面上的绿勾只是辅助。希望这个习惯也能帮到你。
本文还有配套的精品资源，点击获取
