企业官网建设流程全解析

第 4 章 Seatunnel Zeta Engine 与多引擎适配

章节定位：第 3 章把环境搭起来了，Smoke Test 跑通了。但你可能还是不太清楚"Zeta 到底是什么——和 Flink/Spark 到底差在哪"。本章深入 Zeta Engine 的内部架构，画出 Master-Worker 拓扑、解释 Pipeline 级容错和动态线程共享的实现，再给出一张诚实的三引擎能力边界表，最后给一个引擎选择决策树。看完这章，你就能在"Zeta vs Flink vs Spark"之间做出有依据的选择。

学习目标

• ✓ 能说出 Zeta Engine 的四大设计特性（Faster / More stable / Space-saving / Simple and easy），每条对应一个具体的生产场景；
• ✓ 能画出 Zeta Master-Worker 拓扑 + Autonomous Cluster 去中心化模式；
• ✓ 能解释 Pipeline 级容错 vs Flink/Spark Task 级容错的差异，以及在多目标分发场景下 Pipeline 级容错到底有多值钱；
• ✓ 能说出动态线程共享、数据缓存、分布式快照 + 2PC 三个 SeaTunnel 特有的核心机制；
• ✓ 能根据"我有 Flink/Spark 集群吗？"→"需要复杂流计算吗？"→"Pipeline 级容错重要吗？"→"Zeta vs Flink vs Spark 的决策树"做出引擎选择。

4.1 Zeta Engine 架构

Zeta Engine 是 SeaTunnel 的原生执行引擎——不是 Flink/Spark 的"适配器"，是自己从零设计、专为数据同步场景优化的引擎。2.3.0 起成为默认引擎，3.0 进一步完善（状态存储支持 RocksDB、动态线程共享优化）。

官方 About 页面给 Zeta 起了四个标签：Faster、More stable、Space-saving、Simple and easy。让我们把这四个字拆开，看每个字背后的具体设计。

Master-Worker 拓扑

图 4-1 Zeta Master-Worker 拓扑 ┌─────────────────┐ │ Zeta Master │ │ ┌────────────┐ │ │ │ JobManager │ │ │ │ 调度作业 │ │ │ ├────────────┤ │ │ │ CheckpointCoordinator │ │ │ │ Barrier 协调 │ │ │ ├────────────┤ │ │ │ ClusterManager │ │ │ │ Worker 管理 │ │ │ └────────────┘ │ └────────┬────────┘ │ 心跳 + 调度 ┌──────────────┼──────────────┐ ▼ ▼ ▼ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ Zeta Worker │ │ Zeta Worker │ │ Zeta Worker │ │ ┌─────────┐ │ │ ┌─────────┐ │ │ ┌─────────┐ │ │ │ Pipeline │ │ │ │ Pipeline │ │ │ │ Pipeline │ │ │ │ Source │ │ │ │ Source │ │ │ │ Source │ │ │ │ Transform│ │ │ │ Transform│ │ │ │ Transform│ │ │ │ Sink │ │ │ │ Sink │ │ │ │ Sink │ │ │ └─────────┘ │ │ └─────────┘ │ │ └─────────┘ │ └─────────────┘ └─────────────┘ └─────────────┘

Master 负责三件事：作业调度、Checkpoint 协调、Worker 管理。Worker 负责执行——一个 Worker 可以跑多条 Pipeline（动态线程共享）。

三种 Cluster 模式

Autonomous Cluster是 SeaTunnel 特有的——Flink/Spark 需要你明确指定 JobManager/Driver 的地址，Zeta 不需要。所有 Worker 配置同一个cluster_name，启动后自动组成集群，Master 由集群自选举产生。Master 挂了，剩下的 Worker 会自动选出新的 Master，作业从最近一次 Checkpoint 恢复。

四大设计特性

Faster——减少数据序列化开销，支持限速

SeaTunnel 的执行计划优化器（Execution Plan Optimizer）会在翻译层之前做一层优化：尽量减少数据在 Pipeline 中的网络传输和序列化/反序列化。一个 Source 直接连多个 Sink 时，Zeta 会用零拷贝技术把数据推给多条 Sink，而不是每条 Sink 各自序列化一次。

同时支持限速——如果你不想 SeaTunnel 把源库打挂，可以配置source.speed.limit = 10000（每秒处理 10000 行）。这在生产迁移场景下很有用：先限速到 2000 条/s，同步稳定后再逐步放大。

More stable——Pipeline 级容错 + 数据缓存

Pipeline 级容错（SeaTunnel 特有的）：前面反复强调过，这里再和 Flink 对比一次：

Flink Task 级容错： ┌─ Job ─────────────────────────────────┐ │ Task1 ──► Task2 ──► Task3 ──► Task4 │ │ （Task3 挂了 → 整条 Job 回滚）│ └───────────────────────────────────────┘ SeaTunnel Pipeline 级容错： ┌─ Pipeline A ──────────┐ ┌─ Pipeline B ──────────┐ │ Source → Transform → │ │ Source → Transform → │ │ Sink1 (Doris) │ │ Sink2 (Paimon) │ │ （Sink1 挂了 → │ │ 正常运行，不受影响） │ │ 只回滚 Pipeline A）│ │ │ └────────────────────────┘ └─────────────────────────┘

在多目标分发场景下（MySQL CDC → Doris + Paimon + Kafka），Pipeline 级容错的价值会让你拍大腿——Doris BE 偶发故障，只影响 Doris 那条 Pipeline，Paimon 和 Kafka 照常写入。如果是 Flink，整条 Job 会回滚，所有 Sink 都停。

数据缓存（3.0 新特性）：当 Source 数据有存储时间限制（比如 Kafka 消息只保留 7 天）、但 Sink 因为故障暂时写不进去时，Zeta 会把 Source 读出来的数据自动缓存到本地磁盘，等 Sink 恢复后从缓存继续写。这样即使 Sink 故障持续了 3 天，Kafka 消息也不会过期丢——数据在 Zeta 本地缓存里。

Space-saving——动态线程共享 + JDBC 连接复用 + CDC 资源复用

动态线程共享（SeaTunnel 特有的）：实时同步场景下，很多"大数据量但每条数据很小"的表（比如配置表、字典表），Zeta 会把这些小表的同步任务跑在共享线程里，节省线程创建开销。100 条小表同步，如果每条开独立线程，就是 100 个线程；动态线程共享后，可能只需要 10 个线程就能跑。

JDBC 连接复用：SeaTunnel 的 JDBC Source 连接池会在多个 Pipeline 之间复用——一个 MySQL 库有 50 张表要同步，50 个 Pipeline 共享 5~10 个 JDBC 连接，而不是 Flink CDC 每个 Pipeline 开一套连接。

CDC 日志读取资源复用：同一个 MySQL 库有多个 CDC Pipeline 时，SeaTunnel 会只开一套 binlog 读取 + 解析，解析出来的 CDC Event 推给多个 Pipeline。Flink CDC 每个 Pipeline 独立读 binlog，相当于一套 binlog 读三遍。

Simple and easy——无外部依赖

Zeta Engine 不需要 ZooKeeper、不需要 HDFS、不需要 YARN/K8s（Autonomous Cluster 模式下）。集群管理、快照存储（默认本地磁盘，可配 S3/HDFS）、HA（Master 自选举 + Checkpoint 恢复）——全部自己实现。这对"没有大数据平台、不想依赖大数据组件"的团队特别友好。

核心功能清单（官方 Core functions 原文）

状态存储

Zeta Engine 默认用内存存状态——轻量但作业重启后状态丢失（相当于 At-Least-Once 语义）。3.0 起支持RocksDB 持久化（配置zeta.state.storage = rocksdb），适合大状态场景（快照阶段几十亿行表、CDC 长周期增量消费）。

小结

Zeta Engine 的设计哲学用一句话概括：为数据同步场景做到极致优化。它不做 Flink/Spark 那样的计算，只做 Source → Transform → Sink 的搬运，把搬运这件事做到最快（零拷贝 + 限速）、最稳（Pipeline 级容错 + 数据缓存）、最省（动态线程共享 + JDBC 复用 + CDC 复用）、最简单（无外部依赖 + Autonomous Cluster）。

4.2 三引擎能力边界表

4.1 讲了 Zeta 有多好，但 Zeta 不是万能的——它做不了 Flink/Spark 的计算能力。这一节把 Zeta、Flink、Spark 三引擎放在一张表里，逐项对比，诚实不吹。

表 4-1 Zeta vs Flink vs Spark 能力边界表

对比解读

这张表最重要的几行，我单独拎出来说：

Pipeline 级容错（第 5 行）是 Zeta 独有的、在多目标分发场景下碾压 Flink/Spark 的能力。如果你的作业是"MySQL CDC → Doris + Paimon + Kafka + Redis"四条 Pipeline，Doris BE 故障只影响 Doris 那条 Pipeline，其他三条照常写。如果用 Flink，一个 Task 挂了整条 Job 回滚，所有 Sink 都停。这就是 SeaTunnel 多引擎适配的核心价值——同一个 HOCON 配 Zeta vs Flink，容错粒度差了一个量级。

CDC 日志读取复用（第 9 行）在"一个 MySQL 库 50 张表同步到湖"的场景下，Zeta 只开一套 binlog 读取 + 解析资源，Flink CDC 每张表独立读——50 张表就是 50 套 binlog 读取，MySQL 服务器资源占用直接翻几十倍。

资源开销（第 10 行）Zeta 远低于 Flink/Spark——不需要 Flink Cluster（至少需要 TaskManager + JobManager + ResourceManager + ZooKeeper）或 Spark Cluster（至少需要 Driver + 多个 Executor），不需要 Flink Session 或 Spark Context，一个 SeaTunnel Worker 进程就能跑。这在"100 条小同步作业 + 2 条大同步作业"的场景下，资源差 5~10 倍。

复杂流计算（第 12 行）Zeta 做不了——Transform 只能做 EL（字段映射/过滤/重命名），做不了 JOIN/窗口/CEP。如果你的同步链路需要"车辆 CDC + 告警配置维表 JOIN + 10 分钟窗口聚合 + 写 Doris"，必须改 Flink Engine 适配层，用 Flink SQL 在同一个作业里做 JOIN 和聚合。

4.3 Flink 引擎适配

什么时候需要 Flink Engine 适配？两个典型场景：

1. 已有 Flink 集群——不想单独部署 Zeta 集群；
2. 需要复杂流计算——同步链路里要做 JOIN/窗口/CEP，Zeta Transform 做不了。

适配层做了什么

SeaTunnel HOCON 配置 │ │ Translation Layer - Flink Adapter │ ├─ SeaTunnel Source Interface → Flink Source (SourceFunction / Source) ├─ SeaTunnel Transform Interface → Flink MapFunction / FilterFunction ├─ SeaTunnel Sink Interface → Flink Sink (SinkFunction / Sink) ├─ HOCON parallelism → Flink parallelism ├─ HOCON checkpoint.interval → Flink execution.checkpointing.interval ├─ SeaTunnelRow → Flink Row └─ CDC RowKind(+I/-U/+U/-D) → Flink RowKind(INSERT/UPDATE_BEFORE/UPDATE_AFTER/DELETE)

提交命令

# Flink Standalone 模式flink run-c org.apache.seatunnel.core.starter.flink.SeatunnelFlink ^ flink/seatunnel-flink-3.0.0.jar ^--config examples\mysql_to_doris.hocon# Flink Session 模式（复用现有集群）flink run-m yarn-cluster-d ^-c org.apache.seatunnel.core.starter.flink.SeatunnelFlink ^ flink/seatunnel-flink-3.0.0.jar ^--config examples\mysql_to_doris.hocon

性能损耗与坑点

适配层 vs 原生 Flink Connector 性能

SeaTunnel Connector 在 Flink 上跑，和原生 Flink Connector 比性能如何？官方 Engines Overview 页面诚实标注：可能慢 10~20%——因为 SeaTunnel Connector 先实现了引擎无关接口，再由翻译层翻译成 Flink 原生接口，多了一层抽象开销。如果你只跑 Flink、不需要多引擎平移、追求极致性能，直接用原生 Flink Connector 更快。

但这个 10~20% 的开销换来了什么？换来了同一个 HOCON 配置改一行引擎就能在 Zeta/Flink/Spark 上跑——如果你的作业未来可能从 Flink 迁移到 Zeta（比如发现 Pipeline 级容错更重要），或者需要同时维护 Zeta 和 Flink 两套运行底座，这 10~20% 的性能代价是值得的。

4.4 Spark 引擎适配

Spark Engine 适配的覆盖度比 Flink 低——CDC 场景不支持快照并发、Exactly-Once 需要 Delta/Paimon/Iceberg 支持、不支持 2PC Sink。Spark 适配层主要服务于大数据量批处理场景（比如 Oracle → Paimon 的 T+1 全库同步），利用 Spark 集群的大数据量处理能力。

适配层做了什么

SeaTunnel HOCON 配置 │ │ Translation Layer - Spark Adapter │ ├─ SeaTunnel Source Interface → Spark DataSource V2 Source ├─ SeaTunnel Transform Interface → Spark MapPartitions ├─ SeaTunnel Sink Interface → Spark DataSource V2 Sink ├─ HOCON parallelism → Spark repartition ├─ Spark Checkpoint → 不支持（Spark 不原生支持 Exactly-Once 状态） └─ SeaTunnelRow → Spark Row

Spark 适配层的硬限制

提交命令

spark-submit--classorg.apache.seatunnel.core.starter.spark.SeatunnelSpark ^ spark/seatunnel-spark-3.0.0.jar ^--config examples\oracle_to_paimon.hocon

什么时候选 Spark 适配

只有一个场景：大数据量批处理 + 已有 Spark 集群。比如：Oracle 10 亿行表 → Paimon T+1 全库同步，Spark 集群有 100+ 节点，并行处理能力远超 Zeta。除此之外——CDC、实时同步、多目标分发、Exactly-Once、Pipeline 级容错，全部选 Zeta。

4.5 引擎选择决策树

三引擎能力边界表给了"什么能做、什么不能做"，但选哪个引擎还需要结合你的实际场景。下面这棵决策树把选型过程压缩成 5 个问题，跟着走一遍就能得出答案。

图 4-2 引擎选择决策树 ┌────────────────────┐ │ 我有 Flink/Spark 集群吗？│ └─────────┬──────────┘ │ ┌───────────┴───────────┐ │ │ ▼ ▼ ┌─────────┐ ┌─────────┐ │ 没有 │ │ 有 │ └────┬────┘ └────┬────┘ │ │ ▼ ▼ ┌────────────────┐ ┌────────────────┐ │ 需要复杂流计算吗？│ │ 需要复杂流计算吗？│ │ JOIN/窗口/CEP │ │ JOIN/窗口/CEP │ └────┬───────────┘ └────┬───────────┘ │ │ ┌───┴───┐ ┌───┴───┐ │ 是 / 否 │ │ 是 / 否 │ ▼ ▼ ▼ ▼ ┌────┐ ┌───────────┐ ┌────┐ ┌───────────┐ │转Flink│ │ 选 Zeta │ │Flink│ │ 选哪个？ │ │ │ │ │ │ │ │ 继续往下 │ └────┘ └─────┬─────┘ └────┘ └─────┬─────┘ │ │ ▼ ▼ ┌────────────────┐ ┌────────────────┐ │ Pipeline 级容错 │ │ Pipeline 级容错 │ │ / 多目标分发 │ │ / 多目标分发 │ │ / CDC 快照并发 │ │ / CDC 快照并发 │ │ 重要吗？ │ │ 重要吗？ │ └────┬───────────┘ └────┬───────────┘ │ │ ┌───┴───┐ ┌───┴───┐ │ 是 / 否 │ │ 是 / 否 │ ▼ ▼ ▼ ▼ ┌────┐ ┌───────────┐ ┌────┐ ┌───────────┐ │ Zeta│ │ Zeta │ │ Zeta│ │ 看决策树 │ │ │ │（够用就行） │ │ │ │ 继续判断 │ └────┘ └───────────┘ └────┘ └───────────┘ ┌────────────────────┐ │ 批量处理 > 10 亿行吗？ │ └─────────┬──────────┘ │ ┌───┴───┐ │ 是 / 否 │ ▼ ▼ ┌────┐ ┌──────────────────┐ │Spark│ │ 回到 Zeta 决策 │ │ │ │ （Spark 适配层 CDC │ └────┘ │ 快照并发不支持） │ └──────────────────┘ ┌────────────────────┐ │ AI 训练湖仓集成吗？ │ └─────────┬──────────┘ │ ┌───┴───┐ │ 是 / 否 │ ▼ ▼ ┌────┐ ┌────┐ │Zeta│ │ 回到最上面 │ │ 3.0│ │ 决策树 │ └────┘ └────┘

决策树解读

让我们把几个关键路径拎出来，用真实场景验证：

路径一：没有 Flink/Spark 集群 → 不需要复杂流计算

→选 Zeta。这是 SeaTunnel 的最短路径——不需要搭任何大数据集群，seatunnel.cmd --config job.hocon -m local就能跑。多目标分发、Pipeline 级容错、CDC 快照并发、Exactly-Once，全部原生支持。如果业务只做数据同步（不做 JOIN/窗口/CEP），Zeta 是 90% 场景的正确答案。

路径二：没有 Flink/Spark 集群 → 需要复杂流计算

→转 Flink。Zeta Transform 只能做 EL，做不了 JOIN/窗口/CEP。如果你的同步链路需要"车辆 CDC + 告警配置维表 JOIN + 10 分钟窗口聚合 + 写 Doris"，必须引入 Flink。两种选择：自己搭 Flink 集群，或者用 Flink Engine 适配层（但还需要 Flink 集群）。

路径三：有 Flink 集群 → 不需要复杂流计算 → Pipeline 级容错重要

→选 Zeta（虽然有 Flink 集群）。Pipeline 级容错在多目标分发场景下的价值，比"复用现有集群"省下来的那点部署成本值钱得多。Flink 适配层会把 Pipeline 级容错降级成 Task 级——Doris BE 故障导致整条 Job 回滚，而 Zeta 只影响 Doris 那条 Pipeline。

路径四：有 Spark 集群 → 批量处理 > 10 亿行

→选 Spark 适配层。Spark 的 Tungsten + Catalyst 引擎在海量批处理上的性能，是 Zeta 和 Flink 都比不了的。但 Spark 适配层有硬限制——CDC 快照不支持并发、Exactly-Once 不原生支持、Fluss Sink 跑不了。所以 Spark 适配层只适合批量场景，CDC/实时同步还是回 Zeta。

路径五：AI 训练湖仓集成

→选 Zeta 3.0 原生 AI 数据支持。Zeta 3.0 原生支持文本/图像/音频数据从源头同步到 AI 训练湖仓；Spark 也能做，但需要自己写 Spark AI Pipeline；Flink AI 插件还在演进中。

决策口诀

把决策树收束成一句口诀，面试或选型会上可以直接念：

没有 Flink/Spark 集群 → Zeta；有但 Pipeline 级容错重要 → Zeta；有且需要复杂流计算 → Flink；海量批处理 → Spark。

车联网场景选型验证

回到第 1 章的车联网场景，用决策树过一遍：

五条链路里，四条选 Zeta，一条选 Flink——Zeta 是主角，Flink 是特定链路的补充。这就是 SeaTunnel 多引擎适配的正确姿势：不是"三引擎分庭抗礼"，而是"Zeta 扛主力、Flink 补计算、Spark 补海量批"。

工程要点

1. Zeta Engine 四大特性：Faster（零拷贝 + 限速）/ More stable（Pipeline 级容错 + 数据缓存）/ Space-saving（动态线程共享 + JDBC 复用 + CDC 复用）/ Simple and easy（无外部依赖 + Autonomous Cluster）。
2. Pipeline 级容错是 Zeta 独有的核心竞争点——多目标分发场景下，一个 Sink 挂只影响所在 Pipeline，其他 Pipeline 照常运行；Flink/Spark 是 Task 级，一个 Task 挂整条 Job 回滚。
3. Autonomous Cluster 去中心化 Master——不需要指定 Master 节点，所有 Worker 配同一个cluster_name自动发现 + 自选举 Master；Master 挂了自动重选。Flink/Spark 做不到。
4. 动态线程共享——100 条小表同步共享 10 个线程，Flink/Spark 每条同步开独立 Task，资源差 10 倍。
5. CDC 日志读取复用——一个 MySQL 库 50 张表同步，Zeta 只开一套 binlog 读取 + 解析；Flink CDC 每张表独立读，资源翻几十倍。
6. 数据缓存（3.0 新特性）——Sink 故障时把 Source 读出来的数据自动缓存到本地磁盘，防止 Source 数据过期（Kafka 消息只保留 7 天）。
7. Autonomous Cluster（去中心化）——Zeta K8s 部署最简洁，不需要 StatefulSet 固定 Master。
8. Flink 适配层性能损耗 10~20%——多了一层 Translation Layer 抽象开销；但换来了同一个 HOCON 改一行引擎就能平移。
9. Flink 适配层硬限制：Pipeline 级容错丢失、CDC RowKind 可能丢部分信息、类路径冲突（flink-connector-jdbcvsconnector-jdbc）。
10. Spark 适配层硬限制：CDC 快照不支持并发、Exactly-Once 不原生支持、2PC Sink 不支持、Pipeline 级容错不支持、Fluss Sink 不支持。Spark 适配层只适合批量场景。
11. 决策口诀：没有 Flink/Spark 集群 → Zeta；有但 Pipeline 级容错重要 → Zeta；有且需要复杂流计算 → Flink；海量批处理 → Spark。
12. 车联网场景选型：5 条链路 4 条选 Zeta（多目标分发 + CDC + 实时），1 条选 Flink（JOIN + 窗口聚合）——Zeta 是主力，Flink 补计算。
13. Zeta 无外部依赖——不需要 ZooKeeper、不需要 HDFS、不需要 YARN/K8s；Autonomous Cluster 模式下集群管理、快照存储、HA 全部自己实现。
14. 限速控制：source.speed.limit原生支持，生产迁移场景先限速 2000 条/s 再逐步放大，防止打挂源库。
15. 状态存储：Zeta 默认内存（轻量但重启丢状态 → At-Least-Once）；3.0 起支持 RocksDB 持久化（zeta.state.storage = rocksdb）。
16. Flink 适配层 RowKind 映射：SeaTunnel CDC Event 的 RowKind 枚举值和 Flink RowKind 不完全一致，Translation Layer 做双向映射——但 Flink CDC 原生 Event 格式更丰富，适配层可能丢部分信息。
17. 类路径冲突避坑：不需要 Flink/Spark 集群就选 Zeta——不存在 classpath 冲突，这是"最短路径从安装到作业"的根本原因。
18. 复杂流计算必须 Flink：Zeta Transform 只能做 EL（字段映射/过滤/重命名），做不了 JOIN/窗口/CEP；同步链路需要计算时，用 Flink Engine 适配层或单独起 Flink 作业。
19. Spark 适配层 CDC 快照不支持并发——只能单线程读全表；海量批处理（10 亿行以上）Spark Tungsten 引擎的性能优势是 Zeta/Flink 都比不了的，但 CDC/实时同步还是回 Zeta。
20. AI 训练湖仓集成选 Zeta 3.0——原生支持文本/图像/音频数据集成；Spark 也能做但需要自己写 Spark AI Pipeline；Flink AI 插件还在演进。

本章小结

• ✓ 画出了 Zeta Master-Worker 拓扑 + Autonomous Cluster 去中心化模式；
• ✓ 拆解了 Zeta 四大设计特性——Faster（零拷贝 + 限速）/ More stable（Pipeline 级容错 + 数据缓存）/ Space-saving（动态线程共享 + JDBC 复用 + CDC 复用）/ Simple and easy（无外部依赖 + Autonomous Cluster）——每条对应一个具体生产场景；
• ✓ 给出了三引擎能力边界表（表 4-1），诚实标注了 Flink/Spark 适配层做不到的地方（Pipeline 级容错、CDC 快照并发、2PC、Fluss Sink 等）；
• ✓ 深扒了 Flink 适配层的 Translation Layer 做了什么、性能损耗 10~20% 的代价换来了什么、类路径冲突坑点；
• ✓ 深扒了 Spark 适配层的硬限制清单（6 项不支持）；
• ✓ 给出了引擎选择决策树（图 4-2）+ 决策口诀 + 车联网场景选型验证表；
• ✓ 收束出"Zeta 是主力、Flink 补计算、Spark 补海量批"的三引擎协同定位。

下章预告：第 5 章讲 HOCON 配置语法与作业开发全流程——env/source/transform/sink四段式结构、plugin_input/plugin_output显式命名、参数继承与覆盖、多表/全库同步配置、Transform 链、CLI 参数全表。这一章会把"零代码配置"这个 SeaTunnel 最直观的卖点讲透，给你三套可以直接复制的 HOCON 模板（单表批同步 / CDC 增量同步 / 多表全库同步）。

官方参考资料

版本取证说明

1. Pipeline 级容错：Zeta About 页面原文 “Pipeline-level fault tolerance: failures are isolated at the pipeline level”——SeaTunnel 特有，Flink/Spark 做不到。
2. 动态线程共享：Zeta About 页面原文 “Use Dynamic Thread Sharing technology internally”——3.0 新特性。
3. 数据缓存（Sink 故障时）：Zeta About 页面原文 “SeaTunnel Engine also supports data cache for scenarios where the source data has a storage time limit”——3.0 新特性。
4. Autonomous Cluster（去中心化）：Zeta About 页面原文 “Support autonomous cluster (decentralized), which saves the users from specifying a master node”——SeaTunnel 特有。
5. 无外部依赖：Zeta About 页面原文 “No external dependencies: cluster management, snapshot storage, and HA do not depend on services such as Zookeeper or HDFS”。
6. Flink/Spark 适配层性能损耗：Engines Overview 页面诚实标注翻译层多了一层抽象开销。
7. Spark 适配层 CDC 快照不支持并发：Spark CDC Source 页面原文标注"Spark CDC 只能单线程读全表"。

实操清单