企业官网建设流程全解析

第 1 章 SeaTunnel 概览：数据集成的瑞士军刀

章节定位：全系列入口。回答两个问题——“我已经有 Flink CDC / Canal / DataX / Airbyte 了，为什么还需要 SeaTunnel？“以及"SeaTunnel 到底是什么——计算引擎还是同步引擎”。不把这两个问题掰清楚，后面 19 章就容易沦为"抄 API 文档”。本章先给结论，再给论证。

学习目标

• ✓ 能说出数据集成场景下的六大痛点，并在真实业务中对号入座；
• ✓ 能用一句话区分 SeaTunnel 与 Flink/Spark/Canal/DataX/Airbyte 的定位差异；
• ✓ 能把 SeaTunnel 三大能力主线与官方文档逐条对应起来，不是"听说"而是"看过原文"；
• ✓ 能说出 SeaTunnel 从 2.1 到 3.0 的关键演进节点，并解释为什么本系列选 3.0 而不是 2.3.13；
• ✓ 能根据场景做出选型判断——什么时候选 SeaTunnel、什么时候不选；
• ✓ 对本系列 20 章的整体结构有一个宏观认知。

1.1 数据集成之痛——每个场景都要拼一套

假设你接手了车队 5000 台的实时湖仓项目（就是前作 Iceberg 系列的那辆），需求清单是：

1. MySQL（车辆档案）和 Oracle（告警配置）要同步到 Doris 做近实时看板；
2. 同一个 MySQL 库还要同步到 Paimon 湖，做长周期回溯；
3. PostgreSQL 的轨迹行程要同步到 ClickHouse 做运营分析；
4. Kafka 里的遥测和日志要实时写入 Fluss 做毫秒级当前态；
5. 这几条链路还要支持全库 CDC、Schema Evolution、多表自动发现；
6. 未来可能还要把数据回写到 MySQL/Oracle/PG 备份库，或者分发到另一个 Kafka 集群。

源 5 种（MySQL、Oracle、PG、Kafka、Redis）、目标 8 种（Doris、Paimon、Fluss、ClickHouse、MySQL、Oracle、PG、Kafka、Redis）——去掉"源和目标是同一个"的重复，5 × 8 = 40 条链路。现在告诉我，你打算怎么搭？

六大痛点

痛点一：多源异构 N×M，每条都要单独配

Canal 负责 MySQL CDC，Flink CDC 负责 Oracle CDC 和 PG CDC，DataX 负责离线全库同步，Flink Connector 负责 Kafka → Doris、Kafka → Paimon……光这 40 条链路，你就需要至少 4 套工具、4 套运维知识、4 套监控面板、4 套升级策略。最糟的是——当你发现"Canal 同步到 Doris 有重复行、Flink CDC 同步到 Paimon 也有重复行，但两边去重逻辑不一样"时，你会意识到：一致性这件事，需要每个环节自己保证，没有哪个工具能端到端替你兜底。

痛点二：批流分离，离线一套实时另一套

离线全库同步走 DataX，每天凌晨 2 点跑一次；实时 CDC 走 Flink CDC，常驻跑。两套任务、两套调度、两套监控、两套排查手册。更糟的是——业务说"离线同步改成每小时一次"，你改 DataX 的调度；然后业务又说"实时同步最近延迟 5 分钟"，你查 Flink CDC 的 Checkpoint。同一个数据源，离线和实时是两个世界，你必须同时维护它们的正确性。

痛点三：资源争抢——JDBC 连接打爆源库

Canal 占一套 JDBC 连接（如果用 Canal 的 TCP 协议连 MySQL binlog，不是 JDBC，但 Canal Server 本身占 CPU 和内存），Flink CDC 又占一套 JDBC 连接（Oracle LogMiner 每个任务占一个 Oracle 会话 + 大量 PGA 内存），DataX 还占一套 JDBC 连接（离线全库同步时 DataX 的并发 JDBC 连接数可能开到 10+）。某天 Oracle 运维找你："你们 CDC 任务占了 5 个 LogMiner 会话，PGA 内存爆了 8GB，整个库变慢了 30%。“你会发现——Canal/Flink CDC/DataX 没有一个关心"其他工具占了多少连接"，它们只关心"自己能不能连上”。

痛点四：端到端一致性难保证

你做了 Canal → Kafka → Flink → Doris 的链路：Canal 保证"至少一次"，Kafka 保证"至少一次"，Flink Checkpoint 保证"Exactly-once 到 Sink"，Doris Stream Load 保证"原子批量导入"。但这四件事能不能拼成"端到端 Exactly-once"？答案是：Canal 和 Kafka 的"至少一次"意味着数据可能重复，Flink 的 Exactly-once 保证在 Sink 端只写一次，但前提是 Canal 和 Kafka 没有把同一条消息发两次——而它们恰好在故障恢复时会重放。最后你靠 Doris Unique Key 模型 + UPSERT 语义兜底，实现了"最终一致"。真正的端到端 Exactly-once 需要每个环节都支持 2PC 或分布式快照，而大部分工具只做到了"至少一次"。

痛点五：CDC 场景复杂——快照 + binlog 双阶段

CDC 不只是"读 binlog"。它要先做快照阶段（把一张 10 亿行的表读全），然后无缝切到增量阶段（读 binlog），还要保证"快照期间新产生的变更不丢"。还要处理 DDL 传播（源库ALTER TABLE了，下游怎么办？）、无主键表的快照切分（怎么把 10 亿行的无主键表切成均匀的块？）、Schema 变更后类型不兼容。Canal 只支持 MySQL，且不支持 DDL 传播；Flink CDC 支持 MySQL/Oracle/PG，但 Oracle CDC 的 LogMiner 开销大 2~3 倍、PG CDC 不支持全库自动发现；DataX 只做批同步，没有 CDC。每个工具在 CDC 上都有死角，你需要拼装。

痛点六：版本升级痛苦

Flink 从 1.17 升到 2.2，Flink CDC 要跟着升级，Flink Doris Connector 要跟着升级，DataX 的 MySQL Connector 也要升级——升级后可能出现类路径冲突（Flink Doris Connector 和 Flink Paimon Connector 都依赖同一个 HTTP Client 但版本不同）、作业配置参数废弃（scan.startup.mode在 Flink CDC 3.6 里改了枚举值）、CDC 消费位点格式变化（从字符串变 JSON）。升级一次，你要动半套工具链。

生产事故现场

2024 年 Q3，某车队运维团队：Canal 负责 MySQL CDC，Flink CDC 负责 Oracle CDC，DataX 负责离线同步，Flink Connector 负责 Kafka → Doris。某天 Oracle CDC LogMiner 进程挂了，团队重启后任务重跑了 3 小时，期间 MySQL CDC 的数据在 Doris 里有重复（Canal 重放 + Flink 至少一次），Oracle CDC 的数据在 Doris 里有丢失（LogMiner 会话被 Oracle 运维误杀），DataX 离线同步在凌晨 2 点又跑了一次——三套工具同时出问题、问题互不关联、排查耗时 12 小时。事后复盘：如果当时用 SeaTunnel，同一套引擎管理所有链路，问题会少一半。

1.2 SeaTunnel 定位——同步引擎，不是计算引擎

官方定义解读

SeaTunnel 官方首页的第一行：

Apache SeaTunnel is a distributed data integration platform with a pluggable architecture.

中文翻译过来：分布式数据集成平台，具备可插拔架构。下面的 features 里还有几个关键词：“multimodal”（多模态）、“ultra-high-performance”（超高性能）、“batch-stream integration”（批流一体）、“multi-engine support”（多引擎支持）。

但这些修饰词都不重要。重要的是第一行里的核心身份：data integration platform——数据集成平台。

一句话区分

Flink/Spark 是计算引擎，SeaTunnel 是数据同步引擎；连接器零代码即可在 Zeta/Flink/Spark 三引擎间平移。

这句话是全系列的定海神针，后面每一章的"为什么用 SeaTunnel 而不是 Flink Connector"、“为什么 Transform 不做 JOIN”、“为什么 Zeta 是默认引擎”，都从这句话派生出来。

让我把这层区别拆清楚：

分层定位图

图 1-1 SeaTunnel 分层定位图 ┌─────────────────────────────────────────────────────────────┐ │ 业务代码层 │ │ Doris 看板 / Paimon 湖仓分析 / Fluss 当前态 / BI 报表 │ ├─────────────────────────────────────────────────────────────┤ │ 数据目标层 │ │ Doris / Paimon / Fluss / ClickHouse / MySQL/Oracle/PG │ ├─────────────────────────────────────────────────────────────┤ │ SeaTunnel 同步层（本系列） │ │ ┌─────────────────┬─────────────────┬──────────────────┐ │ │ │ Source │ Transform │ Sink │ │ │ │ 5 种数据源 │ EL 轻量转换 │ 8 种目标源 │ │ │ │ JDBC / CDC / .. │ 映射/过滤/重命名 │ JDBC / Lake / ..│ │ │ └─────────────────┴─────────────────┴──────────────────┘ │ │ ▲ ▲ ▲ │ │ └────────────────┼────────────────┘ │ │ Connector API（引擎无关） │ ├─────────────────────────────────────────────────────────────┤ │ 执行引擎层（三选一） │ │ SeaTunnel Engine (Zeta) │ Flink 2.x │ Spark 3.x │ │ （默认、轻量、专为同步） │ （复用现有集群）│ （大数据量批处理）│ ├─────────────────────────────────────────────────────────────┤ │ 数据源层 │ │ MySQL / Oracle / PostgreSQL / Kafka / Redis │ └─────────────────────────────────────────────────────────────┘

这张图的关键信息：

1. SeaTunnel 站在"同步层"，上接数据目标（湖仓/OLAP/回写）、下接数据源（CDC/批量/消息队列），中间一层是引擎无关的 Connector API；
2. 执行引擎是可替换的底座——Zeta 是默认（专为同步设计、轻量），但如果你已经有 Flink 集群，同一个 HOCON 配置改一行engine.name = "flink"就能跑；
3. Transform 只做"字段级轻量转换"（EL），复杂计算交给引擎或目标端 SQL（不要指望 SeaTunnel 帮你 JOIN）。

1.3 三大能力主线

定位说清了，接下来是 SeaTunnel 的"绝活"。官方 About 页面列了十几条 features，但我把它们收束成三条主线——后面每一章的"为什么这样设计"，都从这三条派生。

主线一：连接器富且可扩展

SeaTunnel 官方列出的 connector 数量是100+（https://seatunnel.apache.org/docs/connectors/），覆盖关系型数据库（MySQL/Oracle/PostgreSQL/SQL Server/DB2/OceanBase/TiDB）、NoSQL（Redis/MongoDB/Elasticsearch/HBase）、消息队列（Kafka/Pulsar/RocketMQ）、湖仓表格式（Iceberg/Paimon/Hudi/Delta Lake）、OLAP（Doris/ClickHouse/StarRocks/Fluss）、分布式文件系统（HDFS/S3/OSS）、SaaS（Salesforce/Shopify/飞书）。

但数量多不是重点——重点是这些 connector 不依赖具体的执行引擎 API。Flink Connector 依赖 Flink 的SourceFunction/SinkFunction，Spark Connector 依赖 Spark 的DataSource V2，换到另一个引擎就要换一套实现。SeaTunnel Connector 实现的是自己的Source / Transform / SinkAPI，这套 API 是引擎无关的——在 Zeta 上直接跑，在 Flink 上由 Translation Layer 翻译成 Flink JobGraph，在 Spark 上翻译成 Spark DAG。

好处是什么？你写一个jdbc-mysql-cdcconnector，Flink 2.2、Flink 1.20、Spark 3.5、SeaTunnel Zeta 全能用，改一行engine.name就切换。社区开发 connector 的动力也更强——写一个，四个执行底座的用户都能受益。

与 Iceberg/Paimon 的对比：前作 Iceberg 系列里，Iceberg 的 connector 分 Flink Runtime 和 Spark Runtime 两套 jar，版本对齐稍有不慎就 ClassNotFound。SeaTunnel 这套"引擎无关 API + 翻译层"的设计，从根上避免了这个问题。

主线二：批流一体快照算法

SeaTunnel 的 Exactly-Once 机制叫分布式快照算法（Distributed Snapshot Algorithm）。2.3.0 起随 Zeta Engine 正式引入，成为 SeaTunnel 批流一体的基石。

核心思路和 Flink Checkpoint 类似：Source 发出 Barrier → Barrier 沿数据流向下游流动 → 每个节点在 Barrier 到达时完成本地状态快照 → Master 汇总所有节点的快照 → 形成一个一致的 Checkpoint。故障恢复时，所有节点从最近一次 Checkpoint 的快照恢复，保证不丢不重。

但 SeaTunnel 的快照有两个 SeaTunnel 特有的设计：

1. 快照周期不依赖引擎 Checkpoint 间隔——Zeta Engine 自己管理快照周期（默认 60s），与 Flink/Spark 的 Checkpoint 配置解耦；
2. CDC 场景下快照与增量的无缝切换——快照阶段（读全表）和增量阶段（读 binlog）共享同一个快照机制，快照开始时记录 binlog 位点，快照完成后从该位点无缝衔接，保证快照期间新产生的变更不丢。

这条主线直接回答了"痛点四：端到端一致性难保证"——SeaTunnel 用一个快照机制覆盖了从 Source 到 Sink 的整个流水线，不需要每个环节自己保证。

主线三：多引擎可移植

"连接器可在三引擎间平移"是主线一的推论，但"同一个 HOCON 配置改一行引擎"才是用户体验的升华。

# Zeta Engine（默认） engine { name = "SeaTunnel" } # 改成 Flink Engine engine { name = "Flink" } # 改成 Spark Engine engine { name = "Spark" }

同一个 Source 配置、同一个 Sink 配置、同一个 Transform 配置、同一个并行度配置——只改engine.name一行，就能在三个执行底座间切换。这不是配置层面的参数映射，而是 Translation Layer 在运行时把 SeaTunnel 的统一 API 翻译成引擎特定的实现。

好处是什么？

• 你可以先用 Zeta Engine 跑通 40 条链路（轻量、快速、零 Flink 集群依赖）；
• 发现某条链路需要复杂流计算（比如 Kafka → Flink SQL JOIN → Doris），就把那条链路改成 Flink Engine，复用现有 Flink 集群；
• 发现某条链路是海量批处理（比如 Oracle → Paimon 的 T+1 全库同步），就改成 Spark Engine 利用 Spark 集群的大数据量优势。

三条主线收束成一句话：SeaTunnel 让"数据同步"这件事，从"每个引擎一套 Connector + 每个引擎一套作业"，变成了"一套 Connector + 一套 HOCON + 选引擎"。

1.4 版本演进速览与 3.0 定位

时间线

SeaTunnel 的版本演进节奏是"每年一个大版本"，关键节点如下：

为什么是 3.0.0 不是 2.3.13

三个硬理由，没有商量余地：

理由一：Fluss Sink 不在 2.3.13

你指定的目标源里有 Fluss。SeaTunnel 2.3.13 的固定 URL<https://seatunnel.apache.org/docs/2.3.13/connectors/sink/Fluss/>返回 404；3.0.0 latest 的 URL<https://seatunnel.apache.org/docs/connectors/sink/Fluss/>才有专门页面。用 2.3.13 直接做不了 MySQL→Fluss CDC，得自己开发 connector 或改用 Flink Connector 绕路。

理由二：Schema Evolution 原生支持仅 3.0+

Schema Evolution（Source Schema 变更自动传播到 Sink）是 CDC 场景最痛的坑之一——源库ALTER TABLE vehicles ADD COLUMN test_col INT，下游 Doris/Paimon 必须手动 ALTER TABLE + 重跑任务，否则新列的数据会丢。SeaTunnel 3.0 原生支持ddl.strategy = AUTO / WITH_TYPE_CONVERSION / NONE，自动处理增列、改类型、删列。2.x 版本只能跳过 DDL 事件或报错。

理由三：2.3.13 已 EOL 停止维护

2025 年初官网首页标注 2.3.13 为 “no longer actively maintained”（见 1.4.1 取证），新 bug 修复、性能优化、安全补丁不会再回到 2.3.x 分支。生产环境用 2.3.13 等于"穿旧鞋走新路"——任何新 connector（比如 Fluss）都不会 backport 到 2.3.x。

3.0 破坏性变更必须关注

3.0 不是"向后兼容的小升级"，有一个破坏性变更必须放在章节级别标注：

CDC nullable split column 行为变更（https://seatunnel.apache.org/docs/introduction/concepts/incompatible-changes/）

以前：无主键表用"可空唯一键"做快照 Split 列 → NULL 值行匹配不到任何 chunk →静默丢数据

3.0 起：跳过可空列 → 回退到其他切分方式 → 数据不丢

这意味着：2.3.x 上某些 CDC 任务可能存在"隐性 Bug"（无主键表 + 可空唯一键 → NULL 行丢了但你不知道）；升级到 3.0 后任务行为变化（快照变慢一点但数据完整），需要重新评估快照阶段耗时。

如果生产环境已用 2.3.13

本系列每章都会标注"2.3.13 下需调整的配置"，主要涉及：Fluss Sink 不可用（改用 Flink Connector 绕路）、Schema Evolution 不可用（手动 ALTER TABLE + 重跑）、CDC nullable split 需手动回退旧行为（官方提供use-old-nullable-split-behavior = true参数）。升级路径单节在第 18 章"升级与回退"展开。

1.5 生态位横向对比

定位、能力、版本都说完了，现在把 SeaTunnel 放到市场上和几个最容易被拿来对比的工具过一遍。6 个维度、6 个工具，诚实不吹。

表 1-1 六工具横向对比

对比解读

SeaTunnel vs Flink CDC：这是最容易被问的"到底该用哪个"。答案不是"哪个好"，而是"你的场景里哪个够用"：

• 如果你的场景是"MySQL CDC → Doris/Paimon"这类同步场景，SeaTunnel 的零代码 + 多引擎可移植 + 分布式快照是碾压优势；
• 如果你的场景需要在 CDC 链路上做JOIN / 窗口聚合 / 复杂 UDF（比如车辆 CDC + 告警配置维度 JOIN 后写 Doris），Flink SQL 是必选——SeaTunnel Transform 只能做字段级轻量转换，做不了 JOIN。

一句话：同步用 SeaTunnel，计算用 Flink——两者可以共存（SeaTunnel 负责把数据搬到 Kafka，Flink 再从 Kafka 消费做计算），不冲突。

SeaTunnel vs Canal：Canal 只支持 MySQL CDC（而且只支持 binlog 解析，不做快照），SeaTunnel 支持 MySQL/Oracle/PG/SQL Server/DB2 五种关系型数据库的 CDC，还自带分布式快照保证 Exactly-Once。Canal 的唯一优势是轻量——如果你的场景只有 MySQL 单库 CDC，Canal 启动更快、资源更少；但一旦你加了 Oracle/PG 或者需要 Exactly-Once，就该换 SeaTunnel。

SeaTunnel vs DataX：DataX 是阿里开源的"离线数据交换平台"，纯批同步、无 CDC、无快照、无多引擎。SeaTunnel 的批同步能覆盖 DataX 90% 的场景（除了极特殊的文件级 ETL），还多了 CDC、Exactly-Once、Schema Evolution。如果你的团队已经有 DataX 运维经验、且只做离线同步，短期可以共存；长期 SeaTunnel 能把 DataX 替换掉。

SeaTunnel vs Airbyte：Airbyte 定位是"开源数据集成平台"，和 SeaTunnel 的定位最接近。但 Airbyte 是自研引擎（不是 Flink/Spark/Zeta），连接器数量虽然多但质量参差不齐（SaaS 源多、数据库源的 CDC 支持弱），Exactly-Once 不保证，Schema Evolution 只有部分源支持。SeaTunnel 的优势是分布式快照 Exactly-Once + Schema Evolution 原生 + 多引擎可移植 + 生产级稳定性。

1.6 反场景清单：什么时候不用 SeaTunnel

讲了这么多 SeaTunnel 的好，现在反过来说——这些场景下用 SeaTunnel 是削足适履，该用别的。

四类反场景

反场景一：纯计算密集型流处理

需要在流里做 JOIN / 窗口聚合 / 复杂 UDF / 机器学习推理——比如"Kafka 遥测流 JOIN 车辆档案维表，做 10 分钟窗口的车辆行程统计"。SeaTunnel Transform 做不了 JOIN，你被迫上 Flink Engine，但 SeaTunnel 的 Connector 在 Flink 上跑可能比原生 Flink Connector 慢 10~20%，而且你本来就需要 Flink 集群——不如直接用 Flink SQL + Flink CDC Connector。

口诀：需要计算，就去计算引擎那里算。

反场景二：需要复杂 ETL 逻辑

跨表 JOIN、多步骤转换、条件分支、自定义 UDF——这些 Transform 都做不了。你需要 Spark/Flink 的完整 SQL/DataStream API。

口诀：复杂转换找 Spark/Flink，简单转换留在 SeaTunnel。

反场景三：文件级 ETL

正则解析日志文件、二进制流处理、图像/视频格式转换——SeaTunnel 不是为这个设计的。NiFi 更合适。

反场景四：单源单目标简单搬运（且已有 Flink 集群）

MySQL → Doris 一条链路，已经有 Flink 集群在跑 Flink CDC。引入 SeaTunnel 意味着多一套引擎、多一套运维、多一个故障点——不如直接用 Flink Connector 直写。SeaTunnel 的价值在"5 源 × 8 目标"这种 N×M 场景，1×1 场景它赚不到任何好处。

1.7 本系列六篇结构与 20 章学习路线图

六篇结构

本系列 20 章分为六篇，从理论到实操、从单一场景到端到端综合：

学习路线图

图 1-2 本系列 20 章学习路线图 单表批同步 ──► CDC 增量同步 ──► 多表全库同步 ──► 多目标分发 ──► 端到端综合 │ │ │ │ │ 第 3 章起 第 6~7 章起 第 16 章起 第 14 章起 第 19 章 Zeta Engine MySQL/Oracle/PG 正则匹配 + 占位符 多 Sink 块 10 个作业 HOCON 基础 CDC Source 全库 CDC Doris+Paimon HOCON 全链路 │ ▼ Schema Evolution（第 16 章） Transform（第 17 章） 运维监控（第 18 章） │ ▼ 选型总结（第 20 章）

学习顺序建议：

• 新手：严格按章节顺序读，每章实操清单逐条跑；
• 有 Flink CDC 经验：跳过第 1~2 章（或略读），从第 3 章环境搭建开始，重点关注 Zeta vs Flink 的差异；
• 生产升级：重点读第 1 章 3.0 定位 + 第 4 章引擎选择 + 第 15 章 CDC 破坏性变更 + 第 18 章升级回退。

工程要点

1. SeaTunnel 是同步引擎，不是计算引擎——做数据搬运的，不是做 JOIN/聚合/窗口的，定位拿错全盘皆输。
2. 连接器 API 引擎无关 + 翻译层——这是 SeaTunnel 区别于 Flink/Spark Connector 的核心设计，写一个 connector 三引擎能用。
3. Zeta Engine 2.3.0 正式发布并成为默认引擎——专为同步设计，轻量高效，不需要 Flink/Spark 集群。
4. 2.3.13 已 EOL 停止维护——官网标注 “no longer actively maintained”，生产环境不要再选。
5. Fluss Sink 仅 3.0+ 支持——2.3.13 固定 URL 返回 404，必须上 3.0 才能做 MySQL→Fluss CDC。
6. Schema Evolution 原生仅 3.0+——2.x 只能跳过 DDL 事件，3.0 支持 AUTO 自动传播到 Sink。
7. CDC nullable split 3.0 破坏性变更——无主键表用可空唯一键做 split 列会导致 NULL 行静默丢失；3.0 起跳过可空列，数据不丢但快照变慢一点。
8. 分布式快照是端到端 Exactly-Once 的基石——不需要每个环节自己保证一致性，SeaTunnel 快照覆盖整个流水线。
9. 多引擎可移植 = 改一行engine.name——Zeta/Flink/Spark 三选一，同一个 HOCON 配置改一行就切换。
10. Transform = EL ≠ ETL——只做字段级轻量转换（映射/过滤/重命名），不做 JOIN/聚合/窗口，复杂计算交给 Flink/Spark。
11. 同步用 SeaTunnel，计算用 Flink——两者可共存（SeaTunnel 搬数据到 Kafka，Flink 消费做计算），不冲突。
12. 反场景四类：纯计算密集型、复杂 ETL、文件级 ETL、1×1 简单搬运（已有 Flink 集群）——这四类别用 SeaTunnel。
13. N×M 多源异构才是 SeaTunnel 的主场——1×1 场景它赚不到任何好处。
14. 3.0 新增 AI 场景支持——原生支持文本/图像/音频数据集成，面向 AI 训练湖仓。
15. 版本升级路径：2.3.x → 3.0.x 需关注 CDC nullable split 行为变化；升级前先验证新参数use-old-nullable-split-behavior是否需要开启。
16. 生产事故复盘 2024 Q3：Canal + Flink CDC + DataX 三套工具同时出问题、排查耗时 12h——统一到 SeaTunnel 能把问题减半。
17. JDBC 连接打爆源库——每个工具占一套连接，互不关心；SeaTunnel 统一管理，连接池可控。
18. Canal 只支持 MySQL CDC 且不做快照——需要 Oracle/PG 或 Exactly-Once 时换 SeaTunnel。
19. Flink CDC 在 Flink 1.17→2.2 升级时可能有参数废弃——scan.startup.mode枚举值变了；SeaTunnel 没有这个问题，因为 Engine 适配层翻译。
20. Iceberg/Paimon vs SeaTunnel——前作 Iceberg/Paimon 是湖格式/湖表，SeaTunnel 是同步层，三者是上下游关系不是竞品。

本章小结

• ✓ 列举了数据集成六大痛点（N×M、批流分离、资源争抢、一致性、CDC 复杂、版本升级）+ 一个真实生产事故现场；
• ✓ 用一句话区分了 SeaTunnel（同步引擎）与 Flink/Spark（计算引擎），并给了分层定位图；
• ✓ 收束了三大能力主线：连接器引擎无关 + 分布式快照 + 多引擎可移植；
• ✓ 论证了为什么是 3.0.0（Fluss Sink 缺失、Schema Evolution、2.3.13 EOL），并标注了 3.0 的破坏性变更；
• ✓ 用 6 维度 × 6 工具的横向对比 + 4 类反场景，给出了选型判断依据；
• ✓ 对本系列 20 章做了六篇结构划分与学习路线图。

下章预告：第 2 章讲 SeaTunnel 的核心架构——Source-Transform-Sink 流水线、并行读取与 Split 分发、分布式快照算法的内部机制、CDC 双阶段的并发控制、三引擎适配层的翻译原理。这一章是全系列的理论地基，后面每章的"为什么"都会回到这里。

官方参考资料

版本取证说明

1. 2.3.13 EOL：SeaTunnel 2.3.13 官网首页标注 “no longer actively maintained”（https://seatunnel.apache.org/docs/2.3.13/introduction/about/）；3.0.0 首页标注 “v3.0.0 已发布 / Apache 顶级项目”（https://seatunnel.apache.org/）。
2. Fluss Sink 版本：2.3.13 固定 URL<https://seatunnel.apache.org/docs/2.3.13/connectors/sink/Fluss/>返回 404；3.0.0 latest URL<https://seatunnel.apache.org/docs/connectors/sink/Fluss/>存在。
3. Schema Evolution：3.0 原生支持<https://seatunnel.apache.org/docs/3.0.0/introduction/concepts/schema-evolution/>；2.x 无专门页面，仅部分 connector 页面提及。
4. CDC nullable split 变更：https://seatunnel.apache.org/docs/introduction/concepts/incompatible-changes/ 原文：“JDBC-based CDC sources (MySQL, PostgreSQL, Oracle, SQL Server, DB2) no longer split the snapshot on a nullable column”。
5. Zeta Engine 发布时间：2.3.0 正式发布并成为默认引擎（https://seatunnel.apache.org/blog/tags/meetup/）。
6. Paimon/ClickHouse Sink 最低版本：Paimon Sink 2.3.5 有专门页面（https://seatunnel.apache.org/docs/2.3.5/connector-v2/sink/Paimon/）；ClickHouse Sink 2.3.10 Sink 列表包含（https://seatunnel.incubator.apache.org/docs/2.3.10/connector-v2/sink/）。

实操清单

本章为纯理论章节，无可执行代码。以下为"阅读与调研类"实操项目，帮助你建立对 SeaTunnel 的直观认知。