Apache SeaTunnel 2026 年 6 月提交盘点：控制面能力上探，Connector 生态继续外扩

https://github.com/apache/

点击蓝字

关注我们

Hi Community，今年 Apache SeaTunnel 6 月份月报准时来啦！总体上来看，6 月整个月 Apache SeaTunnel 共合入 125 个 PR，明显高于 5 月的 87 个。整体上看，6 月不是单纯的“修修补补”，而是沿着三条主线同步推进：

• 控制面与引擎抽象继续上探：多表同步的表级故障隔离、StateStore 抽象、任务繁忙度监控、非终态作业状态上报，说明 Zeta 正从“能跑作业”走向“更可治理、更易恢复、更易观察”。

• Connector-V2 持续扩展边界：BigQuery Sink、MQTT Source、Salesforce Source、Vitess CDC、Google Cloud Bigtable 等新连接器/新能力陆续落地，生态覆盖面继续扩大。

• 文件与 SQL 处理链路增强：文件格式 schema evolution、Calcite SQL transform plugin、Base64 SQL functions 等特性，显示 SeaTunnel 正在补齐“复杂数据加工层”能力，而不只是做简单同步。

一、当月总体画像

1.1 四大维度统计

• 功能特性：18
• 性能优化：0
• Bug 修复：40
• 架构改进：67

相比 5 月，6 月最明显的变化是：架构改进类 PR 激增。这意味着社区不只是上线新 Connector，而是在系统性地补齐文档、稳定性、抽象层和工程治理。

1.2 模块分布

• seatunnel-connectors-v2：35

• docs：27

• seatunnel-engine：22

• seatunnel-connectors-v2/connector-cdc：14

• seatunnel-e2e：12

• seatunnel-api：3

• .github/ci：2

• other：10

这里有一个值得注意的信号：docs 在 6 月出现了高占比，说明社区开始把越来越多“隐性知识”沉淀为显式文档，例如 Zeta 状态存储与恢复、CDC 生产 cookbook、REST API 生命周期说明等。这类工作不直接提升吞吐，但直接提升 SeaTunnel 的可用性与可维护性。

三、关键变更一览

如果把 6 月所有 PR 放到一张技术地图里，大致可以分为四组：

3.1 多表同步进入“可降级、可隔离、可治理”阶段

• #10600

  支持 table-level fault isolation，意味着多表同步不再只能“全成或全挂”。
• 这类能力很关键，因为 SeaTunnel 的多表同步已经从“单一链路优化”走向“批量任务治理”。

3.2 文件与 SQL 处理能力明显增强

• #10744

  为 file connector 增加 schema evolution 支持（ADD/DROP/RENAME/UPDATE column）。

• #11062

  引入 Calcite SQL transform plugin，并开放 UDF SPI。

• #11114

  增加 Base64 SQL functions，说明 SQL transform 已经不只是“做投影/过滤”，而是逐步成为通用数据加工层。

3.3 Zeta 正在摆脱对 Hazelcast IMap 的强耦合

• #10812

  通过 StateStore 抽象解耦 Hazelcast IMap，这是典型的架构级演进。
• 这一动作对未来的状态后端切换、混合存储、TTL/Iterable/Counter 等能力抽象都非常关键。

3.4 Connector 生态继续扩大，但重心从“数量”转向“可用性”

• 新增：BigQuery Sink、MQTT Source、Salesforce Source、Vitess CDC、Bigtable Source/Sink。
• 同时伴随大量修复：Paimon、CDC、JdbcHiveIT、UI NaN 显示、E2E 稳定性、JDK8 兼容等。

四、关键技术变更深度分析

本节挑选 5 项最能代表 Apache SeaTunnel 项目 6 月技术方向的变更，分别从背景、实现原理、影响范围三个角度做分析。

4.1 #10600 表级故障隔离：多表同步从“全局失败”转向“局部可控”

PR 规模：23 files changed, 1648 insertions(+), 144 deletions(-)。

背景与痛点：

• 多表同步是 SeaTunnel 的核心使用场景之一，但此前如果单张表在 sink 阶段失败，往往会把整个作业拖死。
• 在生产环境里，这会形成典型的“长尾问题”：99 张表正常，1 张表异常，却要整体重跑，成本极高。

核心设计：新增 MultiTableCommonOptions 与 MultiTableFailurePolicy 等抽象，把“多表失败策略”显式配置化。

关键代码片段：

diff --git a/seatunnel-api/src/main/java/org/apache/seatunnel/api/options/MultiTableCommonOptions.java b/seatunnel-api/src/main/java/org/apache/seatunnel/api/options/MultiTableCommonOptions.javanew file mode 100644@@ -0,0 +1,46 @@+public class MultiTableCommonOptions {++    @Experimental+    public static final Option<MultiTableFailurePolicy> MULTI_TABLE_FAILURE_POLICY =+            Options.key("multi_table.failure_policy")+                    .enumType(MultiTableFailurePolicy.class)

实现原理：

• 通过把“失败策略”从隐式逻辑提升为显式 option，作业可以按表做容错决策。
• 这意味着运行时不再只有“失败即终止”一种分支，而是可能出现“记录失败表、继续推进其它表”的策略。

影响范围：

• 对 connector：多表 sink/writer 需要感知失败策略与失败表元信息。
• 对引擎：任务协调层需要保留失败上下文并在 job 生命周期中传播。
• 对用户：这是一个面向生产治理的强增强，尤其适合大批量 schema 相近的多表同步任务。

4.2 #10744 文件 connector 支持 schema evolution：文件链路首次具备结构变更感知

PR 规模：4 files changed, 168 insertions(+), 2 deletions(-)。

背景与痛点：

• 传统文件 sink 对 schema 变化的容忍度很低，尤其在 CDC 场景下，一旦源端 DDL 变化，文件写入很容易失败或者写出不可读文件。
• SeaTunnel 把文件 connector 纳入 schema evolution 范式，意味着文件链路不再只是“静态落盘”。

关键代码片段：

diff --git a/seatunnel-connectors-v2/connector-file/connector-file-base/src/main/java/org/apache/seatunnel/connectors/seatunnel/file/config/FileBaseSinkOptions.java b/seatunnel-connectors-v2/connector-file/connector-file-base/src/main/java/org/apache/seatunnel/connectors/seatunnel/file/config/FileBaseSinkOptions.java@@ -336,4 +336,14 @@ public class FileBaseSinkOptions extends FileBaseOptions {+    public static final Option<Boolean> SCHEMA_EVOLUTION_ENABLED =+            Options.key("schema_evolution_enabled")+                    .booleanType()+                    .defaultValue(false)+                    .withDescription(+                            "Whether to enable schema evolution for the file sink. "+                                    + "When true, ALTER TABLE events (ADD/DROP/RENAME/UPDATE column) "+                                    + "from CDC sources are applied to the sink schema at runtime. "+                                    + "Files are rotated at each schema change boundary. Default: false.");

实现原理：

• 新增 schema_evolution_enabled 开关，把 ALTER TABLE 事件显式引入 file sink 的运行时处理逻辑。
• 采用“schema 变更边界触发文件轮转”的策略，避免同一文件中出现多套不兼容的 schema。

影响范围：

• 对 CDC to file 场景价值最高，例如 MySQL-CDC -> Parquet/ORC。
• 对下游消费系统更友好，因为文件天然以 schema 变更边界切分。

4.3 #11062 Calcite SQL Transform Plugin：SeaTunnel 的 SQL 加工能力进入插件化阶段

PR 规模：40 files changed, 8257 insertions(+), 1 deletion(-)，是 6 月最重的一批功能开发之一。

背景与痛点：

• SeaTunnel 过去的 transform 更偏向固定功能算子，而复杂计算、内置函数扩展、自定义 UDF 能力相对分散。
• 引入 Calcite SQL transform plugin，本质上是在 SeaTunnel 内部补上一层更通用的“声明式计算面”。

关键代码片段：

diff --git a/seatunnel-api/src/main/java/org/apache/seatunnel/api/transform/CalciteUdf.java b/seatunnel-api/src/main/java/org/apache/seatunnel/api/transform/CalciteUdf.javanew file mode 100644@@ -0,0 +1,54 @@+/**+ * SPI for Calcite SQL transform UDFs. Implementations must provide a <b>public static</b> {@code+ * eval} method whose signature determines the SQL function's input/output types.+ *+ * <p>The {@code eval} method <b>must be static</b> because Calcite's code generation calls it+ * directly without creating an instance.

实现原理：

• 新增 CalciteUdf SPI，明确了 UDF 的发现机制与静态 eval 约束。
• 补齐文档、E2E 与多组示例配置，说明这不是“API 雏形”，而是可以实际落地的 transform 子系统。

影响范围：

• 对用户：可以用统一的 SQL 方式表达更复杂的转换逻辑。
• 对生态：插件化 UDF 为后续函数库扩展、企业自定义函数沉淀提供了标准入口。

4.4 #10812 StateStore 抽象：Zeta 去 Hazelcast 耦合的关键一步

PR 规模：28 files changed, 2071 insertions(+), 92 deletions(-)。

背景与痛点：

• 当引擎状态强绑定到 Hazelcast IMap 时，后续要切换/扩展状态后端会非常困难。
• 这类问题在系统做大后会变成架构债：测试难、替换难、局部优化也受限。

关键代码片段：

diff --git a/seatunnel-engine/seatunnel-engine-server/src/main/java/org/apache/seatunnel/engine/server/common/statestore/ExpiringStateStore.java b/seatunnel-engine/seatunnel-engine-server/src/main/java/org/apache/seatunnel/engine/server/common/statestore/ExpiringStateStore.javanew file mode 100644@@ -0,0 +1,43 @@+/**+ * Storage capability for TTL-based writes.+ *+ * <p>This is intended only for implementations where TTL-based storage is a natural fit, such as+ * Hazelcast-backed stores.+ */+public interface ExpiringStateStore<K, V> extends StateStore<K, V> {

实现原理：

• 将状态能力拆分为 StateStore、ExpiringStateStore、IterableStateStore 等接口族，而不是直接把 Hazelcast 语义泄漏到所有上层逻辑。
• 这意味着上层代码面向“能力接口”编程，而底层可替换为不同状态的实现。

影响范围：

• 对引擎架构极其重要，是后续做混合状态存储、独立状态服务或更细粒度 TTL/计数器能力的前提。

4.5 #10485 BigQuery Sink Connector：云数仓生态继续补齐

PR 规模：40 files changed, 3169 insertions(+), 1 deletion(-)。

背景与痛点：

• GCP 用户过去若想把 SeaTunnel 纳入云数仓链路，BigQuery sink 是非常关键的一环。
• 这个 PR 不只是“接了一个新 connector”，而是补齐了对应配置、序列化、异常码、文档与插件映射。

关键代码片段：

diff --git a/seatunnel-connectors-v2/connector-bigquery/src/main/java/org/apache/seatunnel/connectors/bigquery/option/BigQuerySinkOptions.java b/seatunnel-connectors-v2/connector-bigquery/src/main/java/org/apache/seatunnel/connectors/bigquery/option/BigQuerySinkOptions.javanew file mode 100644@@ -0,0 +1,83 @@+public class BigQuerySinkOptions {++    public static final String IDENTIFIER = "BigQuery";++    public static final Option<String> PROJECT_ID =+            Options.key("project_id")+                    .stringType()+                    .noDefaultValue()

影响范围：

• SeaTunnel 与 GCP 数据生态的衔接进一步增强。
• 对多云/跨云数据集成平台而言，是典型利好。

五、性能与稳定性数据如何验证

6 月的大部分关键变更并不是单纯的“吞吐提升型”优化，而是治理能力、抽象能力、兼容性、恢复能力的增强。因此性能对比不宜只看 rows/s，而应该按变更类型设计观测口径：

• 表级故障隔离（#10600）：
• 验证指标：多表作业在单表失败时的成功表保留率、失败表记录完整性、整体重跑成本。
• 文件 schema evolution（#10744）：
• 验证指标：DDL 变更后作业是否持续运行、文件切分边界是否正确、下游读取是否可持续。
• Calcite SQL plugin（#11062）：
• 验证指标：复杂 SQL transform 的表达能力、UDF 可发现性、端到端执行成功率。
• StateStore 抽象（#10812）：
• 验证指标：恢复链路是否稳定、不同状态能力接口的兼容覆盖率、引擎行为是否回归。

换句话说，6 月更适合用 可靠性测试、恢复测试、配置兼容性测试、E2E 覆盖率 来评价，而不是仅看吞吐数字。

从 6 月的合入内容看，SeaTunnel 的技术路线越来越清晰：

6.1 从“连接器框架”走向“数据集成平台”

• 新 connector 仍在持续增加，但更值得注意的是：文件 schema evolution、SQL transform plugin、表级故障隔离、StateStore 抽象，这些都已经超出“单个 connector 功能”的范畴。

6.2 Zeta 正在补齐平台级治理能力

• 非终态作业状态上报、任务繁忙度监控、状态存储抽象、恢复与 cookbook 文档完善，说明 Zeta 正从“执行引擎”向“可治理执行平台”演进。

6.3 文档和 cookbook 不再是边缘工作

• 6 月 docs 占比很高，不是因为“写了很多说明书”，而是社区开始系统沉淀复杂主题：状态存储、CDC 生产实践、REST API 生命周期等。
• 这会直接降低企业落地门槛，提高 SeaTunnel 的可采纳性。

附录：2026 年 6 月全部合入 PR 清单（125 条）

同步Demo

MySQL→Doris | MySQLCDC | MySQL→Hive | HTTP → Doris | HTTP → MySQL | MySQL→StarRocks|MySQL→Elasticsearch |Kafka→ClickHouse

新手入门

SeaTunnel 让数据集成变得 So easy！/ 3 分钟入门指南

0 到 1 快速入门 /初探/深入理解

分布式集群部署 | CDC数据同步管道 | Oracle-CDC

最佳实践

中控技术天翼云多点OPPO | 清风马蜂窝孩子王哔哩哔哩唯品会众安保险兆原数通 | 亚信科技|映客|翼康济世|信也科技|华润置地|Shopee|京东科技|58同城|互联网银行|JPMorgan

测试报告

SeaTunnel VS GLUE | VS Airbyte | VS DataX|SeaTunnel 与 DataX 、Sqoop、Flume、Flink CDC 对比

源码解析

Zeta引擎源码解析（一） |（二） |（三）| API 源码解析 |2.1.1源码解析|封装 Flink 连接数据库解析

https://x.com/ASFSeaTunnel