引言距离上次更新快两个月了。前段时间手头事情比较多这篇文章一直没有静下心来整理直到最近才把本次更新的内容完整梳理出来。在数据平台中可视化 ETL 很容易被理解为一张可以拖拽节点、连接流程的画布。但真正进入复杂项目后决定系统是否好用的并不只是“能不能跑”而是多路数据能否按照真实业务关系准确合并大数据量下能否保持稳定流程能否及时停止专用节点能否灵活扩展以及整套系统能否以更成熟的方式完成部署和交付。因此这次更新没有停留在界面和节点数量上而是同时调整了可视化 ETL 的执行底座、流程能力和部署结构。ETL 执行引擎由轮询模式改为事件驱动数据合并节点支持星型、树型 JOINUNION 改为按字段名对齐大数据量 JOIN 则通过落盘降低内存压力。在此基础上平台补充了条件分支、脚本节点、流程参数、字段契约和外部插件机制并接入 DolphinScheduler 流程级调度。部署方面业务 jar 改为目录挂载前端交由独立 nginx 托管端口、JVM 和基础环境参数统一收归.env管理。功能扩展、运行稳定性和现场交付不再是几套彼此割裂的方案而是建立在同一套执行模型和部署结构之上。执行引擎从轮询推进到事件驱动可视化 ETL 呈现给用户的是画布真正承载流程运行的则是背后的执行器。原有模式下节点之间依靠定时轮询感知状态通道满时每 20ms 检查一次队列每个节点还需要独立的超时监控线程。流程规模较小时影响并不明显但随着节点和数据量增加线程数量、空转消耗和停止响应都会逐渐成为负担。新的执行模型以边级数据通道为基础使用行数据、结束信号和错误信号三类数据包完成节点间通信。本地执行器根据节点启动事件推进 DAG不再一次性提交整张流程图后持续等待。数据连线直接阻塞读取通道控制依赖和流程结束通过流程级事件处理。流程停止也改为事件广播。已经启动的节点会立即取消正在等待执行权限的节点会被及时唤醒节点超时统一交由共享定时调度处理不再为每个节点创建独立监控循环。通道背压同样由轮询改为条件等待。输出达到高水位后上游在通道上等待由下游消费事件负责唤醒。Excel 字段映射基于当前批次首条数据初始化Kafka 设置最小轮询超时并在流程停止时调用wakeup()避免消费者线程长时间阻塞。节点循环、通道消费、异常传递、停止检查和批量 flush 也已收归公共模板。源节点、转换节点和写入节点完成迁移后节点内部可以更专注于业务处理逻辑新增节点时无需重复实现完整的运行生命周期。这些变化不会直接出现在画布上却决定了复杂流程和大数据量任务能否稳定运行也为后续的数据合并、脚本控制和插件扩展打下了统一基础。数据合并支持链式、星型与树型拓扑数据合并是本次更新中最直观的一项变化。真实业务数据通常不会沿一条直线展开订单与明细、人员与组织、事实表与多张维表都可能形成星型或树型关系。UNION 现在按字段名纵向对齐。某一路数据缺少字段时自动补空不再依赖字段所处的列位置避免因字段顺序不同造成数据错位。JOIN 则按照关联图执行支持链式、星型和树型拓扑。同一对数据源可以配置多条关联条件并按 AND 组成组合键。订单号与行号联合关联这类场景无需再提前拼接字段。每条关联还可以独立配置内连接、左连接或右连接也可以继承全局设置。流程保存和发布时系统会检查关联条件是否覆盖并连通所有数据源。关系不完整时直接拦截把问题留在配置阶段而不是等任务运行后再暴露。在执行层JOIN 不再等待多路数据全部堆积到内存后统一计算。上游数据持续写入 H2 临时表内存缓存达到上限后自动转入磁盘执行结束后清理临时目录。这种方式在保留本地执行效率的同时也降低了大数据量合并对 JVM 内存的冲击。APPEND 按顺序追加保留各路原始字段结构适合只拼接、不对齐的场景。条件分支、脚本与流程参数数据加工并不只有字段转换。实际流程中经常需要根据业务规则分流或者先完成一段脚本和预处理任务再启动后续的数据读取。条件节点支持按照「如果 / 否则如果 / 否则」分流比较值可以引用流程参数并支持等于、不等于、大于、小于、包含和为空等判断。未命中任何分支时可以终止流程也可以丢弃当前数据。SQL、Shell、Python 归入脚本类节点用于执行预处理、外部命令或通过控制连线约束后续节点的启动时机。脚本节点不向下游传递字段流程停止或节点超时后系统会同步终止对应的外部进程避免任务退出后仍有脚本在后台运行。流程参数支持文本、整数、小数和布尔类型每次运行都会保存参数快照。节点启动前系统统一解析配置中的流程参数、系统时间和包含变量的数值表达式。参数未定义时在启动阶段直接报错避免任务运行到中途才发现${params.xxx}未被正确替换。字段契约让连线关系可推导、可检查可视化编排要真正降低使用门槛连线和字段关系就不能完全依赖手工维护。除数据合并外其余节点只允许一个直接上游。多余连线会在画布、保存和发布阶段被拦截。写入节点可以连接读取节点此时连线表达的是“写入完成后再读取”的控制依赖不传递字段其他不符合规则的写入下游连线同样会被阻止。画布已经接入 schema 推导。配置节点字段时可以直接从上游输出中选择也保留手工输入能力。连线上会展示传递的字段数量并可进一步查看具体字段。发布前系统会校验上游依赖、字段映射、字段是否存在以及已知类型是否兼容后端发布接口还会执行二次检查。流程保存时系统根据入边自动推导依赖并落库用于运行快照和数据血缘。前端不再单独维护depend_no手工选择来源和填写依赖的配置也已移除。节点输入由画布连线决定合并节点自动读取全部入边。外部插件把通用平台与项目扩展分开对于普通的「输入 → 处理 → 输出」类节点现在可以通过独立插件完成扩展。插件实现 SPI 并声明configSchema打包为 jar 放入plugins/etl后重启数据开发服务即可加载。前端根据 schema 动态生成输入框、数字、开关、下拉和多行文本等配置项未声明 schema 时则使用 JSON 配置作为兜底。服务启动时会根据插件 code 同步工具箱元数据兼容历史分类 ID 和逻辑删除记录。新增内置节点也不再依赖额外的菜单 SQL。条件分支和多路合并等涉及连线规则与发布校验的节点仍由主工程提供。插件更适合项目中的专用转换能力既不需要修改平台主干也不必将每一个个性化节点都纳入通用版本。仓库中已经提供手机号归属地解析示例工程可作为独立插件开发模板。Docker 部署已将plugins/etl挂载到数据开发服务的工作目录。更新插件时只需替换宿主机目录中的 jar并重启对应容器。调度集成接入 DolphinScheduler 统一编排ETL 目前支持本地执行和 DolphinScheduler 流程级调度两种运行模式。DolphinScheduler 负责流程触发和外部编排执行结果回调同一条 SRT 运行记录。ETL 内部仍复用本地 DAG、数据通道和节点日志无需为调度模式维护另一套执行引擎。项目第一次保存海豚模式的 ETL 时系统会自动创建对应的 DolphinScheduler 项目每条 ETL 流程首次保存时会创建专属工作流和 HTTP 调度任务并将编码回填至 SRT。后续保存不会覆盖用户在 DolphinScheduler 中追加的节点。流程发布、取消发布、删除和实例启动均已实现联动。项目同时提供 standalone 加 PostgreSQL 的独立 Docker 编排便于快速完成集成联调。对于已经使用 DolphinScheduler 的环境数睿通 ETL 可以进入现有调度体系与其他任务统一编排和管理。部署优化降低版本更新与环境配置成本业务 Java 服务不再将 jar 打入自定义镜像而是统一使用eclipse-temurin:17-jre并将jar/xxx.jar只读挂载到/app/app.jar。更新服务时替换宿主机 jar 并重建对应容器即可无需再次执行docker compose build。单个服务可以通过--no-deps --force-recreate独立更新不影响其他容器。前端静态资源从网关和 BI 后端的static目录中拆分出来由独立 nginx 托管。主应用部署在/BI 部署在/bi-web/接口继续反向代理至网关。前端更新只需替换nginx/web或nginx/bi-web中的文件并重启 nginx不再与后端 jar 的发布周期绑定。端口、JVM、基础镜像、数据库名称和密码统一收归同目录.env。业务服务的宿主机端口和容器监听端口同步调整MySQL、Redis、Nacos 只修改宿主机映射容器内部继续使用默认端口避免与 Nacos 中已经导入的连接配置冲突。Nacos 首次启动时会执行一次性配置导入业务服务在导入成功后错峰启动减少集中注册导致的失败。Flink 执行器默认不随主项目启动可通过--profile按需开启Hive、SeaTunnel 同样采用旁路编排主项目可以独立运行。系统库支持 MySQL、PostgreSQL、达梦等多种数据库中台库也可根据项目需要选择数据源并不绑定单一引擎。结语这次更新并不只是增加几个画布节点而是进一步补齐可视化 ETL 走向生产应用所需要的关键能力事件驱动的执行模型、贴近业务关系的数据合并、发布前的字段校验、可独立扩展的插件机制、与统一调度体系的联动以及更清晰的部署结构。从数据接入、加工、调度到部署上线数睿通 2.0 正在把原本分散的环节逐步连接起来。ETL 不再只是一张可视化画布而是数据进入指标体系、数据服务和 BI 应用之前一条可以配置、校验、执行、扩展和追踪的生产链路。