Watermark - tag - 沐木https://oldletter.cn/tags/watermark/Watermark - tag - 沐木Hugo -- gohugo.iozh-cnSun, 19 Jul 2026 01:00:00 +0800千万级数据同步与 ETL 实战（二）：快照、Watermark 与无漏数分页https://oldletter.cn/posts/data-sync-etl-02-snapshot-watermark/Sun, 19 Jul 2026 01:00:00 +0800mumuhttps://oldletter.cn/posts/data-sync-etl-02-snapshot-watermark/

系列导航：1 | 2 | 3 | 4 | 5 | 6

增量查询写成 WHERE update_time > ? 很容易，难点集中在三个交界处：首次快照进行时源表仍在写；同一时间戳容纳多行；目标端已提交而 Checkpoint 尚未提交。任一处处理不清，系统都会在低负载测试中正常运行，在真实并发和故障下出现漏数或旧值覆盖。

本文从一个约束明确的例子展开。源表有 1000 万行，主键 id，更新时间精确到毫秒，业务允许 1 分钟调度周期。源端只提供普通查询权限，没有日志消费能力。目标端支持按业务键 Upsert。

一、首次快照需要 Epoch

快照不是简单的 SELECT *。它是目标数据集的一次基线构建，必须能和快照期间发生的变化衔接。为每次基线分配单调递增的 snapshotEpoch：

task = customer_sync
snapshotEpoch = 42
schemaId = customer-v7

Epoch 42 的每个 Batch 都引用 customer-v7，其编码口径在本轮基线构建期间保持冻结。新的快照开始后，旧 Epoch 仍可继续服务，直到新 Epoch 完成校验并原子切换。直接清空目标表再写入，会把数小时的快照过程暴露给查询方，也失去快速回退能力。

完整流程如下：

sequenceDiagram participant C as Control Plane participant S as Source participant B as Batch Store participant T as Target C->>S: 捕获快照边界 H0 C->>S: 在边界内按主键分页读取 S-->>B: 生成 Epoch 42 的快照 Batch C->>S: 从 H0 开始累积增量 B->>T: 幂等写入 Epoch 42 C->>T: 校验行数、摘要和约束 C->>T: 原子切换当前 Epoch C->>S: 继续消费增量并提交 Checkpoint

如果数据库支持一致性快照和可对应的日志位置，H0 可以是事务快照对应的 LSN、SCN 或 Binlog Position。快照读取看到边界时刻的一致状态，增量从该位置之后消费，衔接关系能够精确定义。

]]>