4、数据抽取策略：全量抽取、增量抽取（时间戳、CDC）、实时抽取（Kafka）、批量抽取调度
数据抽取，说白了就是ETL的第一步，也是决定整个管道效率的关键。我见过太多项目，前期没想清楚怎么抽，后面天天加班补数据。今天咱们就把这几种策略掰开揉碎了讲清楚。
核心观点：没有最好的抽取策略，只有最合适的。选错了，轻则跑得慢，重则数据对不上。
4.1 全量抽取：简单粗暴，但别滥用
全量抽取，就是把源表的数据全部捞过来。每次跑，都是整张表。嗯，这招最直接，但也最笨重。
什么时候用？
- 数据量小（百万级以内），每天全量刷一次，成本可控
- 维度表、配置表，变化不频繁，全量覆盖最省心
- 第一次初始化数据，必须全量
什么时候千万别用？
- 上亿级的流水表，全量一次跑几个小时，业务方等不起
- 源系统性能敏感，全量查询可能把数据库拖垮
我的经验：有一次客户要求每天全量抽取订单表，5000万行。跑了三天，源库CPU飙到99%，DBA直接打电话骂人。后来改成增量，问题全解决了。
4.2 增量抽取：省时省力的主流方案
增量抽取，说白了就是只拿变化的数据。这里有两种主流玩法：时间戳和CDC。
4.2.1 时间戳增量
原理很简单：源表里有个字段记录最后修改时间，比如update_time。每次抽取时，只拿update_time > 上次抽取时间的数据。
-- 伪代码示例
SELECT * FROM orders
WHERE update_time > '2024-01-01 00:00:00'
AND update_time <= '2024-01-02 00:00:00';坑在哪里？
- 源表必须有时间戳字段，且更新时必须正确维护
- 时间精度问题：如果同一秒内有多条数据更新，可能漏掉
- 删除操作无法捕获（除非用软删除）
我曾经踩过的坑：有个系统的时间戳只精确到秒，业务高峰期同一秒内更新了1000条记录。结果增量抽取只拿到了998条，对账对了一周才发现。后来我强制要求源系统把时间戳精度提升到毫秒级。
4.2.2 CDC（变更数据捕获）
CDC是增量抽取的进阶版。它不依赖时间戳，而是直接从数据库的日志（比如MySQL的binlog、Oracle的redo log）里读取变更记录。
CDC的优势：
- 实时性高，秒级延迟
- 能捕获所有操作（插入、更新、删除）
- 对源系统几乎无侵入
常见的CDC工具：
- Debezium（开源，支持多种数据库）
- Canal（阿里巴巴开源，专攻MySQL）
- Oracle GoldenGate（商业，稳定但贵）
我个人习惯：新项目我优先推荐Debezium + Kafka的组合。Debezium监听binlog，把变更事件推送到Kafka，下游随便消费。这套架构我用了三年，基本没出过问题。
4.3 实时抽取（Kafka）：流式处理的基石
实时抽取，说白了就是数据一产生，马上就能拿到。Kafka是这里的主角。
Kafka在ETL中的角色：
- 作为消息队列，解耦数据生产和消费
- 作为数据缓冲，应对流量高峰
- 作为数据管道，连接多个系统
// Kafka生产者示例（Java）
Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
Producer producer = new KafkaProducer<>(props);
producer.send(new ProducerRecord<>("orders", "order_id", "order_data_json")); 实时抽取的典型场景：
- 用户行为日志（点击、浏览、下单）
- 金融交易流水（需要秒级监控）
- IoT设备数据（传感器上报）
注意：实时不等于零延迟。Kafka的延迟通常在毫秒到秒级，但如果你需要毫秒级的实时性，那得考虑其他方案（比如直接写内存队列）。
4.4 批量抽取调度：让一切有序运行
批量抽取，就是按固定时间间隔（比如每小时、每天）拉取数据。调度是这里的核心。
常见的调度工具：
| 工具 | 特点 | 适用场景 |
|---|---|---|
| Apache Airflow | DAG编排，依赖管理强 | 复杂ETL流程 |
| DolphinScheduler | 国产，可视化好 | 中小团队 |
| Crontab + Shell | 简单，零成本 | 小规模任务 |
| XXL-JOB | 轻量级，分布式 | Java生态 |
调度策略的核心要点：
- 依赖管理：任务A跑完才能跑任务B，别搞反了
- 失败重试：网络抖动是常态，自动重试3次是标配
- 监控告警：任务挂了要第一时间通知，别等业务方来骂
- 幂等性：同一个任务跑两次，结果应该一样
我建议：新项目直接上Airflow。虽然学习曲线陡一点，但它的DAG可视化、依赖管理、重试机制都做得很好。我带的团队从Crontab迁移到Airflow后，ETL故障率下降了70%。
4.5 知识体系总览
下面这张图，把本章的核心逻辑串起来了。你想想看，从数据源到目标，到底该选哪种策略？
这张图的核心逻辑是：先看数据量，小就全量，大就增量。增量里再分时间戳和CDC，实时场景上Kafka。最后，不管哪种策略，都得靠调度来管理。
最后提醒一句：别把全量和增量混在一起用，除非你很清楚自己在做什么。我见过有人全量跑一半，增量又启动，结果数据重复得一塌糊涂。
公众号:蓝海资料掘金营，微信deep3321