4、数据采集策略：增量采集与全量采集、定时调度与事件触发、采集去重机制
数据采集，说白了就是决定「什么时候拿数据」和「拿哪些数据」。
我见过不少团队，一上来就搞全量采集，结果每天跑十几个小时，数据还没跑完新的又来了。嗯，这里面的坑，我今天跟你好好聊聊。
4.1 全量采集 vs 增量采集
先搞清楚这两个概念。全量采集，就是把数据源里所有的数据都拉一遍。增量采集，只拉「上次之后新增或变化」的数据。
全量采集，适合什么场景？
- 数据量小，比如几千条配置表
- 数据源不支持增量标记（比如某些老旧系统）
- 需要做数据对账，确保两边完全一致
增量采集，才是日常主力。
- 数据量大，比如每天几亿条日志
- 数据源有明确的变更标记（时间戳、版本号、CDC日志）
- 对时效性有要求，需要分钟级甚至秒级同步
我的经验： 我个人习惯，第一次部署时先跑一次全量，把历史数据拉进来。之后全部切到增量。这叫「全量初始化 + 增量持续」。你想想看，如果每天几十亿条数据还全量跑，那不是采集，是自残。
小技巧： 增量采集时，一定要记录好「上次采集的断点」。比如记录最后一条数据的时间戳或ID。否则断点丢了，下次增量就变成了全量，数据量直接爆炸。
4.2 定时调度与事件触发
数据采集什么时候跑？两种方式：定时调度和事件触发。
定时调度，就是按固定时间间隔跑。比如每小时跑一次，或者每天凌晨2点跑。
- 适合数据更新频率稳定、可预测的场景
- 实现简单，用Cron表达式就能搞定
- 缺点是：如果数据在调度间隔内变了，你得等到下次调度才能拿到
事件触发，就是数据源有变化时，主动通知采集系统来拿数据。
- 适合实时性要求高的场景
- 需要数据源支持回调、消息队列或Webhook
- 延迟低，秒级甚至毫秒级响应
我在项目中遇到过一个问题：某个业务系统每天凌晨3点批量更新数据，但我们的定时调度设在凌晨2点。结果每次跑完，数据又变了，第二天对账永远对不上。后来改成事件触发，数据更新完立刻通知采集，问题就解决了。
注意： 事件触发虽然实时性好，但容易丢消息。如果消息队列挂了，或者网络断了，数据变更就丢了。我建议「事件触发 + 定时补偿」双保险。事件触发为主，每天凌晨再跑一次全量或增量做补偿，确保数据不丢。
4.3 采集去重机制
数据采集最头疼的问题是什么？重复数据。
为什么会重复？原因很多：
- 网络重试导致同一条数据发了两次
- 增量采集的断点没记准，重复拉了一部分
- 事件触发和定时补偿同时跑，数据重叠
去重机制，我把它分成三个层次：
| 层次 | 方法 | 适用场景 |
|---|---|---|
| 源头去重 | 数据源自带唯一ID，采集时按ID去重 | 数据源有主键或业务唯一键 |
| 采集层去重 | 采集时记录已采集的ID或指纹，重复则跳过 | 数据源没有唯一ID，或ID不可靠 |
| 存储层去重 | 写入时用UPSERT（存在则更新，不存在则插入） | 所有场景兜底 |
我曾经踩过一个坑：某个数据源没有唯一ID，我用时间戳+内容哈希做指纹去重。结果同一条数据在不同时间戳下被采集了两次，因为数据源的时间戳精度只到秒，而两次采集间隔不到一秒。嗯，后来我把时间戳精度改成毫秒，问题才解决。
核心原则： 去重一定要做幂等设计。也就是说，同一条数据采集多少次，最终结果都一样。这样即使去重机制偶尔失效，也不会造成数据混乱。
4.4 知识体系总览
下面这张图，把数据采集策略的核心逻辑串起来了。你可以看到全量和增量怎么选，定时和事件怎么配，去重机制怎么兜底。
我的建议： 别想着一步到位。先跑全量，再切增量。定时调度先跑起来，再考虑事件触发。去重机制从存储层做起，再慢慢优化到源头去重。一口吃不成胖子，数据管道也一样。
公众号:蓝海资料掘金营，微信deep3321