引言
距离上次更新快两个月了。前段时间手头事情比较多，这篇文章一直没有静下心来整理，直到最近才把本次更新的内容完整梳理出来。
在数据平台中，可视化 ETL 很容易被理解为一张可以拖拽节点、连接流程的画布。但真正进入复杂项目后，决定系统是否好用的并不只是"能不能跑"，而是多路数据能否按照真实业务关系准确合并，大数据量下能否保持稳定，流程能否及时停止，专用节点能否灵活扩展，以及整套系统能否以更成熟的方式完成部署和交付。
因此，这次更新没有停留在界面和节点数量上，而是同时调整了可视化 ETL 的执行底座、流程能力和部署结构。
ETL 执行引擎由轮询模式改为事件驱动，数据合并节点支持星型、树型 JOIN，UNION 改为按字段名对齐，大数据量 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 应用之前，一条可以配置、校验、执行、扩展和追踪的生产链路。