增量抽取 - tag - 沐木https://oldletter.cn/tags/%E5%A2%9E%E9%87%8F%E6%8A%BD%E5%8F%96/增量抽取 - 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 实战（三）：Hash Wheel、行指纹与删除识别https://oldletter.cn/posts/data-sync-etl-03-hash-wheel-fingerprint/Sun, 19 Jul 2026 01:00:00 +0800mumuhttps://oldletter.cn/posts/data-sync-etl-03-hash-wheel-fingerprint/

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

有些源表只有主键和业务字段，没有更新时间、行版本、删除标记，也拿不到数据库日志。要发现历史记录被修改或删除，完整周期仍需检查全部记录。工程上的问题变成：怎样把一次重扫描拆开，怎样保证同一条记录总落到同一个分区，怎样避免读取中断造成误删除，以及怎样把目标写入量限制在真实变化量附近。

Hash Wheel 负责把全表检查平摊到时间轴，Fingerprint Index 保存上一次看到的状态，Generation 在完整扫描后识别删除。这三个组件必须共同工作。只实现“主键取模加定时查询”，无法形成可恢复的变化检测链路。

一、身份键和内容指纹分开

每条记录先抽象为二元组：

$$ Entry=(IdentityKey, RowFingerprint) $$

IdentityKey 由稳定主键或业务键得到，用于确认记录身份。RowFingerprint 由参与同步的字段计算，用于判断内容变化。两者的判断关系如下：

旧状态 本轮状态 结果
不存在 存在 INSERT
存在 指纹不同 UPDATE
存在 指纹相同 NO_CHANGE
存在 完整扫描后未见 DELETE

业务键允许修改时，它不再是稳定身份。系统只能把键变更表达成旧键删除和新键新增，除非源端另有不可变 ID 或变更日志能够关联前后值。这个限制需要进入数据集契约。

身份键可直接保存原主键，也可以保存带命名空间的摘要：

$$ IdentityKey=H(datasetId \parallel canonical(primaryKey)) $$

跨数据集使用同一主键时，datasetId 防止状态键冲突。原主键是否保留取决于审计和回查需求；只有摘要会增加碰撞处理与问题定位成本。

二、Hash 前先定义 Canonicalization

指纹错误通常源于编码规则，而非 Hash 函数。以下值在某些业务语义下相同，直接转字符串却会得到不同字节：

Decimal: 1、1.0、1.00
Time:    2026-07-19 10:00:00、2026-07-19T02:00:00Z
JSON:    {"a":1,"b":2}、{"b":2,"a":1}
String:  Unicode 组合字符与预组合字符

每次编码口径调整都要提升 canonicalizationVersion，旧指纹只按旧口径解释。字段规则包括：

]]>