系统架构 - tag - 沐木https://oldletter.cn/tags/%E7%B3%BB%E7%BB%9F%E6%9E%B6%E6%9E%84/系统架构 - 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，同时持续告警“当前链路无法直接识别物理删除”。若系统只把模式保存为一个枚举，维护人员看不到能力缺口，也无法判断将权限补齐后能获得什么收益。

]]>