/%E5%A2%9E%E9%87%8F%E6%8A%BD%E5%8F%96/ Recent content in 增量抽取 on 老张开工了 Hugo zh-cn Mon, 13 Apr 2026 00:00:00 +0000 /posts/2026/04/etl-cdc/ Mon, 13 Apr 2026 00:00:00 +0000 /posts/2026/04/etl-cdc/ 为什么全量刷新不够用 在 ETL 入门阶段，全量刷新听起来很省事：每次把源表的所有数据删掉，重新拉一遍。对于小数据量表，这没什么问题。但当数据量增长到百万、千万甚至亿级时，全量刷新就成了一场噩梦。 来看几个数字。假设你有一个订单表，每天新增 5 万条记录，总计 2000 万行。全量读取 2000 万行可能耗费 30 分钟，但实际发生变化的数据只有 5 万行，占总量的 0.25%。这意味着你浪费了 99.75% 的传输量和计算量。 全量刷新还有几个更棘手的问题： 窗口时间不够：数据量越大，刷新窗口越长。如果每天只有 2 小时的维护窗口，全量同步 10 亿条数据根本跑不完 对源库压力大：全表扫描会对业务数据库造成巨大压力，影响在线交易 浪费存储和带宽：每次传输全部数据，压缩、网络、磁盘 IO 的成本成倍增加 增量抽取就是为了解决这些问题而生的。 增量抽取的三种主要策略 增量抽取的核心是回答一个问题：“上次处理完之后，哪些数据发生了变化？” 针对不同的数据源和业务场景，有三种主流策略。 时间戳增量 时间戳策略是最简单、应用最广泛的增量抽取方式。原理是：源表里有一个时间字段（如 updated_at、modified_date），记录每条数据最后修改的时间。每次抽取时，只取时间大于上次抽取时间的记录。 -- 最后一次抽取的时间是 2026-04-12 03:00:00 -- 只抽取此后修改的数据 SELECT * FROM orders WHERE updated_at > '2026-04-12 03:00:00' AND updated_at <= '2026-04-13 03:00:00'; 时间戳策略的优点是实现简单，对源库改造小。但缺点也很明显： 需要源表有时间戳字段，且业务代码正确维护该字段 物理删除的数据无法被捕获（删除不更新时间戳） 时间精度不够时可能漏数据（如果两行在同一毫秒内修改） 批量更新时间戳的情况可能导致重复或遗漏 增量文件/日志 有些系统会主动生成包含变更的文件或日志。例如： 应用日志：业务系统把每次增删改操作输出到日志文件 增量文件：ERP 系统每天生成变更文件，记录当天修改的记录 ID Binlog：MySQL 的二进制日志记录了所有数据变更 增量文件的方式对源系统侵入最小，但依赖应用配合生成这些文件。 基于日志的 CDC（Change Data Capture） CDC 是增量抽取的终极方案。它的原理是直接读取数据库的事务日志（如 MySQL 的 binlog、PostgreSQL 的 WAL），从中解析出所有数据变更事件。