简介面向数据工程师与分析师的Web版数据集成平台完整工程包基于KettlePDI开发支持在浏览器中拖拽式构建数据采集、转换与加载任务大幅降低ETL工具的使用门槛。资源共含1645个文件压缩包约160.93MB主体为Java后端源码912个与Vue前端代码74个同时配套xml/properties配置、ktr转换定义、yaml/Dockerfile部署文档与RPM安装包等便于直接阅读、二次开发和容器化部署。已有727人学习下载。除完整平台源码外还可系统了解Kettle Web化的实现路径包括数据源管理、图形化转换与作业设计、执行监控、版本控制、用户权限等关键模块并参考Spring Boot后端与Vue前端的技术选型、MySQL配置及构建脚本。适合需要搭建数据集成中台、研究Kettle二次封装或设计低代码数据开发工具的开发者和团队。1. 基于Kettle的Web数据集成平台把拖拽式ETL搬进浏览器基于 Kettle 实现 Web 版数据集成平台不少人以为就是把桌面客户端搬到浏览器——画布、拖拽、连线看起来差不多。真正拆过源码才发现这背后是一整套架构转换Kettle 引擎怎么变成后端服务、前端画布怎么映射成步骤和跳、任务配置怎么落库管理每一层都有讲究。这个项目做的事情是把 Kettle 的 ETL 能力封装成浏览器可用的拖拽式平台数据源管理、转换设计、作业调度、执行监控全部 Web 化操作。它解决的不只是“少装一个客户端”的问题更把数据采集和数据集成能力开放给了不懂代码的同事。适合数据工程师搭自助取数平台也适合后端开发者研究 Kettle Web 化的完整实现。2. 核心原理与架构拆解Kettle Web化的底层逻辑2.1 先搞懂Kettle的三大概念转换、作业、步骤与跳Kettle 能成为数据集成领域的“老黄牛”靠的是对 ETL 流程足够稳定的抽象。转换Transformation是一条数据处理管道由步骤Step和跳Hop构成步骤是具体的处理单元“表输入”负责从数据库读数据“字段选择”负责过滤和重命名“表输出”负责写目标表跳则是步骤之间的数据流连接像一个管道把数据从上游传给下游。作业Job是更高层的调度容器按顺序执行转换还可以调用脚本、发邮件、检查文件存在性。Web 平台前端画布上拖来拖去的本质就是在编辑这些步骤和跳的关系。保存时画布内容被序列化成 Kettle 的.ktr或.kjbXML 文件格式后端收到 XML 后解析成 Kettle 引擎的TransMeta、JobMeta、StepMeta等元数据对象再调用Trans.execute()或Job.execute()真正跑起来。我在拆项目时第一步就是把TransMeta和JobMeta的调用链理顺后面所有功能——从保存到监控——都建立在这条链路上。Kettle 里还有一个“存储仓库”的概念分文件仓库和数据库仓库两种。原生客户端通常用文件仓库把.ktr/.kjb存成本地文件而这个 Web 平台走的是数据库仓库路线把转换和作业的内容直接存进 MySQL这样才支撑得起多用户共享、版本回溯和权限隔离。提示源码里出现的.ktr、.kjb后缀文件可以直接用文本编辑器打开XML 里能看到step和hop标签结构比想象中直观。2.2 架构分层前端拖拽、后端接口与Kettle引擎怎么配合这个平台的架构可以用“三层两段”概括。前端是一层基于 Vue 和 Element UI 实现——源码里的date-picker.css、select.css、transfer.css这些文件就是 Element UI 按需引入的组件样式从侧面印证了技术栈选型。后端是一层基于 Spring Boot 和 Maven 构建mvnw.cmd是 Maven Wrapper 的启动脚本说明构建环境不强制要求全局安装 Maven。第三层是 Kettle 引擎本体负责真正执行 ETL 任务。前端层负责“可视化编辑”把数据源、步骤、跳对应成画布上的组件和连线拖拽完成后序列化为 JSON 或 XML 提交给后端。后端层做“桥接调度”接收请求后调用 Kettle 的 Java API或者通过 Kettle Server 的 REST API 提交作业同时把执行状态和日志写回数据库。这里要强调一个认知Web 平台不是把 Kettle Desktop 嵌进浏览器而是只用了 Kettle 的执行引擎。前端画布上那些图标只是对 Kettle 步骤的视觉化映射真正的数据搬运发生在 Kettle 引擎内部。部署时有一个取舍Kettle 依赖库直接打进 Spring Boot 进程还是单独部署 Carte Server。这个项目源码里同时具备两种模式的配置入口——application.yml中的kettle.mode可以切换。如果只是研究性地跑起来standalone 模式最省事不额外多维护一个进程但生产环境任务量大时我建议单独部署 Carte用carte-config.xml做并发配置这样后端 Web 服务重启不会中断正在跑的 ETL 任务。2.3 元数据存储为什么任务配置要落库而不是只存文件原生 Kettle 的转换和作业以.ktr/.kjb文件保存在本地文件系统。Web 平台要引入 MySQL 的原因本质上就两个词协作和权限。文件存储下一份转换被三个人改版本立刻乱掉数据库存储可以做到任务配置以 XML 内容保存在表里每次修改记录版本号。数据源连接信息集中管理不再散落在各个转换文件中执行历史和异常日志都入库方便后续查询分析。项目里t_datasource、t_transformation、t_execution_log这三张表基本就是这个平台的核心理解了它们就理解了平台的元数据模型。权限控制也能做到按行隔离——用户 A 只能看自己的任务相同的数据源可以被多个转换复用这种能力在纯文件模式下几乎不可能优雅实现。数据库存储还带来一个隐层好处任务版本管理。原生 Kettle 做版本对比基本靠文件名后缀xxx_v2.ktr而数据库表加一个version字段就能实现。上线审批链路、任务发布记录都可以基于这个版本字段扩展这在企业场景里非常实用。3. 部署实操从源码包到浏览器可访问的完整流程3.1 环境准备JDK、Maven、MySQL版本怎么搭这份源码包拿到手之后第一步不是急着启动而是先把环境对一遍版本。根目录的mvnw.cmd和.babelrc已经暗示了技术栈后端是 Java Maven 工程前端用了 Babel 编译链路。mysqld.cnf则说明目标环境需要 MySQL。我把版本搭配整理成了一张表按这个组合踩的坑最少组件推荐版本说明JDK8 或 11Kettle 8.x/9.x 对 JDK 8 支持最稳JDK 17 反射调用容易报错Maven3.6用项目自带mvnw.cmd则不需要全局安装MySQL5.7 / 8.x8.x 必须用mysql-connector-java 8.0.x驱动Kettle 引擎8.x / 9.x源码lib目录里自带版本以实际为准Node.js14前端构建需要建议 16 LTS环境验证的方式很直接命令行执行java -version确认 JDK 版本在 1.8 到 11 之间mvn -version确认 Maven 可用MySQL 用mysql -uroot -p能登录即可。这里有一个很现实的坑Kettle 依赖的commons-*系列库版本较老JDK 版本一旦超过 12反射相关的调用会抛IllegalAccessException。所以我个人强烈建议本地开发环境固定用 JDK 8省得后面排查一堆莫名其妙的类加载问题。3.2 数据库初始化建库建表与初始化SQL源码包的sql/或db/目录下应该有初始化脚本。如果没有最常见的做法是根据application.yml里的数据库配置手动建库。参考这类平台的核心表结构初始化 SQL 大概长这样CREATE DATABASE IF NOT EXISTS kettle_web DEFAULT CHARACTER SET utf8mb4; USE kettle_web; CREATE TABLE IF NOT EXISTS t_datasource ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100) NOT NULL, type VARCHAR(20) NOT NULL COMMENT mysql/oracle/csv..., host VARCHAR(100), port INT, database_name VARCHAR(100), username VARCHAR(100), password VARCHAR(200), create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB; CREATE TABLE IF NOT EXISTS t_transformation ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100) NOT NULL, content TEXT NOT NULL COMMENT ktr XML内容, version INT DEFAULT 1, created_by VARCHAR(50), update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINEInnoDB; CREATE TABLE IF NOT EXISTS t_execution_log ( id INT AUTO_INCREMENT PRIMARY KEY, task_type VARCHAR(10) COMMENT trans/job, task_name VARCHAR(100), status VARCHAR(20) COMMENT running/success/fail, start_time DATETIME, end_time DATETIME, error_message TEXT ) ENGINEInnoDB;上面这段 SQL 建了三张核心表t_datasource存数据源连接信息t_transformation存转换的 XML 内容并带版本号t_execution_log记录每次执行的状态。表名可能因项目结构略有差异但职责基本一致在源码里搜关键字就能对上。导入命令如下mysql --default-character-setutf8mb4 -uroot -p sql/init.sql导入后执行SHOW TABLES;看到至少三张以上的业务表就算成功。如果导入报字符集错误把--default-character-setutf8mb4加上——这是最常被忽略的参数不指定的话中文乱码会一路传递到任务名称和日志里。3.3 后端配置application.yml与Kettle引擎对接后端 Spring Boot 的配置集中在src/main/resources/application.yml。需要修改的重点是三个MySQL 连接串、Kettle 引擎模式、临时文件目录。参考配置spring: datasource: url: jdbc:mysql://localhost:3306/kettle_web?useSSLfalseallowPublicKeyRetrievaltruecharacterEncodingutf8 username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver kettle: # 引擎执行模式standalone 或 server mode: standalone # server 模式下需要配置 Carte 地址 server-url: http://localhost:8081/kettle repository-path: ./data-integration-repo temp-dir: ./tmp server: port: 8080kettle.mode是这里最关键的参数。standalone模式下后端进程直接内嵌 Kettle 引擎执行效率和调试便利性最高server模式则把任务提交给独立的 Carte 服务适合分布式部署。默认配置通常给的是 standalone依赖的 Kettle 库直接打包进 Spring Boot 的lib目录。allowPublicKeyRetrievaltrue这一项在 MySQL 8.x 下必须显式加上否则数据源测试连接会直接报Public Key Retrieval is not allowed。repository-path是 Kettle 文件仓库的根路径standalone 模式下如果任务里引用了本地文件比如 CSV 数据源相对路径基于这个目录解析。改完配置启动后端./mvnw spring-boot:run启动日志里看到Tomcat started on port 8080和Kettle engine initialized这两行说明后端就绪。如果只想部署运行可以打包./mvnw clean package -DskipTests java -Xms512m -Xmx2048m -jar target/data-integration-1.0.jar-Xms512m -Xmx2048m这对参数建议从一开始就带上。Kettle 引擎加载插件时非常吃堆内存默认 256MB 大概率直接 OOM。3.4 前端构建与联调npm install到页面可访问前端部分如果是独立目录通常叫web或frontend需要先安装依赖再构建。Vue 项目的标准流程npm install npm run buildnpm install按package.json拉取 Vue、Element UI、拖拽组件库比如vuedraggable等依赖。npm run build产出dist目录里面是编译后的静态资源。前后端部署有两种常见方式第一种是把dist里的文件直接拷贝到后端 Spring Boot 的src/main/resources/static/目录下重新打包后端让 Tomcat 一并托管静态资源。第二种是前后端分离部署前端跑 Nginx接口反向代理到后端 8080 端口。本地联调时推荐用 Vue dev server 的 proxy 配置// vue.config.js module.exports { devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } };这里的/api前缀要和后端控制器类的RequestMapping(/api)保持一致否则请求全部 404。之前有个同事就是把后端接口路径配成了/api/v1前端代理只配了/api排查了整整一个下午。前端联调成功后浏览器访问http://localhost:8080应该能看到数据源管理、转换设计、作业调度三个主要入口。源码里通常有内置的默认账号比如 admin/admin先用它登录建一个测试数据源并点击“测试连接”通了就说明整个链路已经走通。4. 拖拽实战数据源、转换和调度的配置要点4.1 数据源管理MySQL与CSV两类数据源的接入区别Web 平台里的数据源管理是整个流程的起点也是最容易埋坑的地方。以 MySQL 为例创建数据源时需要填主机、端口、库名、用户名、密码。后端拿到这些参数后会调用 Kettle 的DatabaseMeta类构造数据库连接定义所以你在界面上填的连接信息本质上就是 Kettle 的DatabaseMeta参数。CSV 文件数据源的配置逻辑完全不同。不需要数据库连接但要配置文件路径、分隔符、是否包含表头、字符集。这里有一个特别容易踩的坑路径权限。Kettle 引擎如果以系统服务运行访问C:\Users\xxx\Desktop\data.csv这种用户目录下的文件经常因为权限不足直接读不出来。我习惯把文件统一放到一个固定的数据目录并在kettle.repository-path下建一个files/子目录所有文件类数据源都放那里避免权限问题。数据源类型必填参数特别注意事项MySQLhost, port, database, username, passwordJDBC URL 加allowPublicKeyRetrievaltrueCSV 文件filePath, delimiter, header, charset确认启动用户有目录读权限Oraclehost, port, serviceName, username, password驱动需要手动放入 Kettle 的 lib 目录数据源配置完成后平台一般会提供一个“测试连接”功能。这个操作实际是调用了 Kettle 的Database.testConnection()方法能拿到很具体的错误信息比如Access denied for user、Communications link failure等。排错时优先看这条错误信息比直接建转换试跑要快得多。4.2 转换设计表输入→字段清洗→表输出的最小闭环在转换设计页面新建一个转换左侧步骤面板拖一个“表输入”到画布。双击弹配置框选择数据源填 SQL 语句比如SELECT id, name, age FROM user WHERE create_time ${startDate}。这里的${startDate}是一个变量占位符执行任务前由用户传入值实现按天增量抽取。再拖一个“表输出”到画布配置目标数据源、目标表名和字段映射。然后从表输入的输出节点拉到表输出的输入节点一条跳Hop就建好了。整个操作过程和原生 Kettle Desktop 几乎一致区别在于 Web 平台把步骤和连线变成了可视化小组件生成的是 XML 而不是手工拖动的桌面文件。保存转换时前端会把画布内容序列化成 KTR 格式的 XML 提交到后端。后端解析 XML 构建TransMeta对象调用执行引擎跑起来。建议保存后先做“试运行”只跑前 100 行数据验证逻辑。前端试运行的请求载荷大概长这样{ transformationId: 23, previewRows: 100, variables: { startDate: 2024-06-01 } }后端收到这个请求会调用 Kettle 转换执行把输出行数限制在 100 行内返回字段预览结果给前端表格展示。previewRows在实际执行中可以传更大的值但预览场景传 100 就够了——数据量大时只会拖慢响应对排查逻辑没有额外帮助。这里说一下字段映射的细节规则。表输入的 SQL 查询结果字段要和表输出的目标字段在名称上一一对应。如果源字段叫user_name目标字段叫name中间必须加一个“字段选择”步骤做重命名或者用“字段映射”步骤处理。很多新手第一次跑不通问题都出在这一步——Kettle 的自动映射只对同名且同类型的字段生效。4.3 作业调度与执行监控定时任务和日志怎么查转换解决的是一个数据处理流程作业Job解决的是多个流程的组合调度。在作业设计页面可以拖入一个“转换”条目指向已保存的转换再拖一个“成功”连线指向下一个转换在失败分支上挂一个“发送邮件”条目配置告警通知。Web 平台的调度功能一般有两种实现方式一种是前端定时器按 cron 表达式定时请求后端接口提交作业另一种是后端集成 Quartz 做进程内调度。从稳定性角度我推荐 Quartz 方案——它跑在 JVM 进程里不受浏览器开关影响。你把浏览器关掉后端的定时任务照样按计划执行。执行监控页面上重点看三个指标数据量读取/写入行数、耗时、错误记录。Kettle 转换执行结束后每一步会返回LinesRead和LinesWritten统计平台把这些数据写入t_execution_log表并展示在前端。有一个排查技巧看日志时永远先定位“是哪个步骤报的错”。Kettle 的错误日志会携带步骤名比如Step name [table_input] failed你要先跳到那个步骤去看它的配置而不是从头到尾读一遍堆栈。作业调度的 cron 表达式配置也是被抓到最多的。在 Kettle 里写 cron 用秒 分 时 日 月 周六段格式和 Linux 的五段格式不一样。一个常见的乌龙是把0 0 2 * * ?写成了0 2 * * *结果任务每小时的第二秒就跑一次。这种问题在 Web 平台上尤其隐蔽因为前端选完表达式后不会做合法性校验只能在下一次触发时暴露。5. 避坑指南部署运行中常见的五个翻车点5.1 现象Kettle 启动报 OutOfMemoryError第一次启动这个 Web 平台Kettle 引擎初始化阶段就抛java.lang.OutOfMemoryError: Java heap space连续跑第三个转换时进程直接崩溃。原因Kettle 引擎初始化要加载大量插件类默认 JVM 堆内存只有 256MB根本不够用。尤其在云服务器上部署服务器虽然 2GB 内存但启动脚本没配 JVM 参数等于白瞎。解决启动命令显式加内存参数java -Xms512m -Xmx2048m -jar>curl -X POST http://localhost:8080/api/execution/run \ -H Content-Type: application/json \ -d { transformationId: 23, variables: {startDate: 2024-06-01, endDate: 2024-06-30}, callbackUrl: http://scheduler.internal/data-integration-callback }callbackUrl参数很关键。任务如果耗时长调用方不希望一直阻塞等结果就让后端在任务执行完后主动 POST 结果到这个回调地址。我有一次在这里吃了亏——刚开始用同步调用外部系统 HTTP 超时时间设的 30 秒任务跑了 5 分钟客户端早就断开了。改成回调模式后整个链路才算稳定。6.2 自定义步骤插件扩展如果要在平台里增加 Kettle 原生没有的处理能力比如对接内部系统的加解密算法可以写一个自定义插件。基础做法是继承BaseStep并实现StepInterface在processRow()方法里写数据处理逻辑。Web 平台要做的是在步骤面板注册这个插件的图标拖拽后生成的 XML 里带上插件 ID后端执行时就能自动加载。这一步门槛较高适合有 Java 基础的人。我建议先在原生 Kettle Desktop 里把插件跑通再集成进 Web 平台——原生环境能看到更详细的插件加载日志Web 端日志会被包装一层报错信息容易丢关键栈帧。6.3 上线前的检查单部署稳定之后我每次上线都会强制走一遍这个检查单确认 JVM 堆内存至少 2GB、MySQL 连接池最大连接数不超过 20、Kettle 并发数不超过 3、前端请求超时时间至少 120 秒、执行日志保留天数不超过 30 天。这套参数不是拍脑袋定的而是从一次生产事故里换来的——日志表无限增长导致数据库磁盘写满整个平台连带业务库一起挂了。从那以后我每次部署都强制走一遍这个检查单先看内存再看磁盘最后确认并发数。希望帮到你。本文还有配套的精品资源点击获取