数据同步 - tag - 沐木https://oldletter.cn/tags/%E6%95%B0%E6%8D%AE%E5%90%8C%E6%AD%A5/数据同步 - tag - 沐木Hugo -- gohugo.iozh-cnSun, 19 Jul 2026 01:00:00 +0800千万级数据同步与 ETL 实战（一）：边界、降级策略与整体架构https://oldletter.cn/posts/data-sync-etl-01-boundaries-and-architecture/Sun, 19 Jul 2026 01:00:00 +0800mumuhttps://oldletter.cn/posts/data-sync-etl-01-boundaries-and-architecture/

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

数据同步项目开工时，团队常先讨论 Kafka、Flink 或 Debezium。这个顺序容易忽略一个基础问题：源系统究竟能提供什么。很多企业数据源只有只读账号、分页接口或定期投递的文件。数据库日志权限拿不到，表里也未必有可靠的更新时间。此时直接套用 CDC 架构，实施阶段会在权限、版本、网络和运维能力上不断返工。

本文先给系统划定边界。目标数据集以单表或单集合不超过 1000 万行为基准，变更速率不高，业务接受几十秒到数小时的延迟。系统需要发现新增、修改和删除，支持断点恢复，并限制对源库的影响。每秒数十万事件、复杂事件时间计算、强实时交易链路不在这套微批架构的处理范围内，第六篇会单独讨论真正的流式系统。

一、先盘点数据源能力

同一个“查询数据”接口，能提供的增量能力差别很大。建任务前要探测并固化以下信息：

能力 需要确认的内容 缺失后的影响
变更日志 Binlog、WAL、LSN、SCN、日志保留时间 无法按日志位置持续消费
版本字段 单调版本号、精度、是否覆盖删除 只能依赖时间或扫描
更新时间 是否有索引、是否随每次修改更新 历史回改可能漏读
稳定键 单主键、复合业务键、键是否会变化 无法可靠识别同一条记录
一致性快照 隔离级别、快照时长、日志衔接点 首次全量与增量可能断层
分页方式 游标、Keyset、页码、排序稳定性 并发写入时可能漏读或重复
删除信息 删除日志、软删字段、墓碑记录 需要周期扫描才能识别删除
源端改造 能否加索引、生成列、触发器 分桶扫描可能退化成全表计算

能力探测结果进入数据集版本，不能只留在部署人员的经验里。任务发布后如果主键、时区或更新时间精度发生变化，旧 Checkpoint 可能失效。调度器需要暂停任务，完成迁移验证后再恢复。

建议把增量策略设计成一条降级链：

flowchart LR A["读取源端能力"] --> B{"可消费变更日志"} B -->|是| C["CDC / 日志增量"] B -->|否| D{"有版本号或更新时间"} D -->|是| E["Version / Watermark"] D -->|否| F{"数据只追加"} F -->|是| G["自增键增量"] F -->|否| H["Hash Wheel 分桶扫描"] H --> I["全量指纹校验兜底"]

降级需要记录原因。例如数据库支持 Binlog，但账号缺少复制权限，任务可以暂时使用 Watermark，同时持续告警“当前链路无法直接识别物理删除”。若系统只把模式保存为一个枚举，维护人员看不到能力缺口，也无法判断将权限补齐后能获得什么收益。

]]>千万级数据同步与 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。快照读取看到边界时刻的一致状态，增量从该位置之后消费，衔接关系能够精确定义。

]]>