SeaTunnel 增量同步实战：从快照到 CDC 续传

增量同步的难点从来不在"能不能读到变化数据"，而在全量与增量的衔接、断点续传、以及同步作业的稳定性。SeaTunnel 的 CDC 能力把一次从零开始的同步拆成 Snapshot（快照）、Backfill（回填）、Incremental（增量）三个阶段，配合水位线（watermark）记录进度，让"全量+增量无缝衔接、失败后从断点继续"变成可设计的机制而不是碰运气。这篇文章按三阶段机制讲清楚作业是怎么跑的、参数分别控制什么，再给出作业设计与失败恢复的要点。

先看场景与挑战。典型需求是把 MySQL、Oracle 等业务库的数据持续同步到数仓或湖仓，用于报表、分析或下游数仓分层。直接做全量同步的问题很明显：数据量大了之后全量窗口拉长、频繁全量浪费资源，而业务数据是持续变化的，两次全量之间产生的变更如果不采集，下游永远滞后。增量同步要同时解决三件事：第一，全量与增量的衔接——快照那一刻之后产生的变更不能丢，也不能重复；第二，断点续传——作业失败重启后，从上次成功的位置继续，而不是重跑全部；第三，一致性——同步过程中读到的不应是"半张表"的中间状态。CDC（Change Data Capture，变更数据捕获）是解决这些问题的通用技术，SeaTunnel 把 CDC 封装成了开箱即用的连接器（官方文档见 SeaTunnel 的 PostgreSQL-CDC 与 Zeta 引擎说明）。

三阶段机制是理解 SeaTunnel CDC 作业的钥匙。第一阶段 Snapshot：作业启动时先对目标表做一致性快照，读取当前所有数据行，并记录快照对应的 binlog（或 WAL）位点。这一阶段的关键是"一致性"：快照读取与位点记录必须是同一时刻的语义，避免出现"数据读到一半、位点已经往前跳"的窗口。第二阶段 Backfill（回填）：把快照数据写入目标端，同时增量部分在后台从记录位点开始消费。有些实现会把"快照数据写入"与"变更数据消费"并行推进，快照完成时增量消费已经追上了快照时刻，两者自然衔接。第三阶段 Incremental：快照与回填完成后，作业进入纯增量模式，持续消费变更事件并写入目标端，用水位线记录"已处理到哪个位点"。水位线就是作业的进度指针，它同时是断点续传的依据：重启时从持久化的水位线继续，而不是从头再来。SeaTunnel 的 Zeta 引擎为 CDC 作业提供了内置的状态管理与 checkpoint 机制（社区对这套机制有较多分析，可参考 SeaTunnel CDC 原理相关文章与 MySQL CDC in SeaTunnel 的实践），让水位线可以可靠落盘。

作业设计要点决定三阶段跑得顺不顺。第一是分片（split）：SeaTunnel 会把快照阶段的目标表按主键范围拆成多个分片，分片并行读取，分片数量直接影响快照速度；分片粒度要根据表大小与主键分布调整，大表分片过少会拖慢快照，分片过多会放大对源库的查询压力。第二是并发：快照并发与增量并发是两回事，快照并发受源库负载约束，增量并发通常与分区数相关，要分开配置而不是一把梭。第三是状态存储：水位线与 checkpoint 需要可靠的持久化位置，配置好状态后端，作业重启后才有恢复的依据；状态目录的权限与容量也要提前规划。第四是 checkpoint 频率：checkpoint 越频繁恢复粒度越细，但开销越大；对延迟敏感的链路可以调高频率，对低频报表链路可以放宽。

参数含义是配置作业时最容易懵的地方，挑几个高频的讲。table-list（或类似命名）指定要同步的表清单，支持通配，精确到库表；startup.mode 决定增量起始位置，常见的取值包括 initial（从快照开始，全量加增量）、earliest（从最早的可用位点开始）、latest（只同步作业启动之后的新变更）、specific-offset（从指定位点开始）；snapshot.split.size 控制快照分片大小；server-id 在 MySQL CDC 场景里是源库为同步连接分配的从库标识，多个并行读任务要用不同的 server-id，否则会被源库当成同一连接导致冲突。理解参数不能只看名字，要把它对应到三阶段里的具体行为：startup.mode 决定第一阶段从哪里开始，split.size 决定第一阶段的速度，checkpoint 决定第三阶段的恢复粒度。

断点续传与失败恢复是生产环境最看重的能力。SeaTunnel 作业重启后，Zeta 引擎从 checkpoint 恢复状态，CDC 连接器从持久化的水位线继续消费，目标端通过幂等写入或主键更新去重，保证"不重不漏"。恢复演练值得在正式上线前做一次：故意在增量阶段终止作业，重启后检查目标端数据是否与源库一致、是否有重复或丢失。与直接使用 Flink CDC 相比，SeaTunnel 的差异一句话概括：Flink CDC 需要你用流处理的方式组织整个管道（写代码或 SQL 作业），而 SeaTunnel 用配置文件声明式地定义"从哪读到哪写"，对以数据集成任务为主、不想引入完整流计算体系的团队更轻量。

常见失败模式要提前防。第一是 server-id 冲突：多个并行任务共用 server-id 导致源库连接被踢或数据错乱，务必为每个并行任务分配独立 server-id。第二是分片与源库压力：大表快照分片过细会压垮源库，监控源库慢查询与连接数，分片数量要有上限。第三是 DDL 变更：源表加列、改类型会导致增量事件解析失败或写入目标端报错，需要提前约定 DDL 同步策略（忽略、告警或暂停）。第四是 checkpoint 过大：长时间运行且未清理的状态会拖慢恢复，定期维护状态目录并评估清理策略。第五是水位线回退：目标端写入延迟导致水位线虚高，重启后可能出现位点跳跃，需要保证写入成功后才推进水位线。

目标端写入策略与源端读取同样重要。增量数据落库时，最常用的模式是按主键做 upsert：目标表有主键就采用"存在则更新、不存在则插入"，配合源端删除事件的同步，保证目标表与源表状态一致；没有主键的表要谨慎处理删除与更新，否则重复执行会产生脏数据。写入方式上还要考虑整库同步与单表同步的取舍：整库同步配置简单、方便后续新增表，但单表失败会影响整批任务；单表同步故障隔离好、便于单独调优，但表多了之后配置与运维成本上升。实际项目里常见的做法是核心表单表同步、外围表整库同步，两条链路共用同一套参数模板。此外，目标端的写入并发要与源端读取并发解耦，避免把源库的压力传导到目标端写入链路，也方便在目标端单独限流。

给你的下一步很具体：选一张真实的业务表（数据量中等、有主键），用 initial 模式跑通"快照→回填→增量"全过程，人为制造一次失败（重启作业）验证断点续传，然后观察一个完整业务周期（比如一周）的延迟曲线，把 checkpoint 频率与分片参数调到稳定区间。跑通这一张表，你就有了一个可复制的增量同步作业模板，其余表按同样的参数模板套用即可。