3. 增量采集基础
在金融新闻与公告数据采集中，全量采集与增量采集是两种最基础的抓取策略。全量采集每次运行都重新抓取目标范围内的全部数据，而增量采集只抓取自上次采集以来新增或发生变化的数据。理解二者的差异，是设计稳定、高效、可长期运行的数据管道的前提。
一、核心原理：两种采集策略的本质差异
全量采集的逻辑是“每次从零开始”。例如每天凌晨重新抓取某财经网站过去30天的全部新闻列表，再逐条入库。它的优点是实现简单、数据一致性强，因为每次都能拿到完整快照；缺点是随着数据量增长，重复抓取和重复存储的成本急剧上升，且对目标站点造成较大压力。
增量采集的逻辑是“只取变化部分”。它依赖一个增量标识来判断哪些数据是新的或已更新的。金融场景中常见的增量标识包括：
- 时间戳：新闻发布时间、公告披露时间、交易所行情时间。
- 自增ID或序列号：公告编号、新闻ID、接口返回的游标。
- 内容指纹：对标题+正文计算哈希，用于识别内容是否真正变化。
- 版本号或更新时间：部分公告平台会提供“最后修改时间”。
增量采集的核心不是“少抓”，而是“准确地知道从哪里继续”。它需要维护一个水位线（watermark），记录上次成功采集到的最大时间戳或最大ID，下次从该位置之后继续拉取。
二、适用场景：什么时候用全量，什么时候用增量
选择策略不能凭感觉，而要根据数据源特征、业务时效要求和系统资源来决定。以下清单可作为判断依据：
| 判断维度 | 优先全量采集 | 优先增量采集 |
|---|---|---|
| 数据量级 | 小规模、可一次性拉完 | 大规模、持续增长 |
| 更新频率 | 低频、变化少 | 高频、实时或准实时 |
| 接口能力 | 无分页、无时间过滤参数 | 支持时间范围、游标或ID过滤 |
| 业务时效 | 对延迟不敏感，如历史归档 | 对时效敏感，如公告监控、舆情预警 |
| 容错要求 | 允许重复，可覆盖写入 | 需要精确去重和断点续传 |
| 典型场景 | 初始化历史库、小站点备份 | 每日新闻增量、公告实时抓取 |
在金融新闻与公告场景中，常见做法是混合策略：首次上线时做一次全量初始化，之后切换为增量采集；同时定期（如每周）做一次小范围全量校验，用于修复增量过程中可能出现的漏抓或错位。
三、核心挑战：增量采集为什么容易出错
增量采集看似简单，但在真实金融数据源上会面临一系列工程挑战：
- 时间戳不可靠：部分新闻页面的发布时间是“今天 10:30”这类相对时间，或者时区不统一，直接作为水位线会导致漏抓或重复。
- 数据乱序到达：公告平台可能先发布后修改，或者接口返回顺序与时间顺序不一致，水位线推进过快会跳过迟到的数据。
- 分页边界问题：当新数据在翻页过程中插入时，固定页码会导致重复或遗漏，必须使用游标或时间范围过滤。
- 去重不彻底：同一篇新闻被多个栏目转载，标题相同但URL不同，需要内容指纹或业务主键去重。
- 断点丢失：采集程序崩溃后，如果水位线没有持久化，下次可能从旧位置重新开始，造成大量重复。
常见误区：把“增量”简单理解为“只抓第一页”。如果目标站点第一页混有旧数据，或者分页排序不稳定，只抓第一页会同时造成漏抓和重复。增量采集必须配合明确的时间过滤或游标机制。
四、设计原则与最小可用流程
一个健壮的增量采集模块，通常遵循以下设计原则：
- 水位线持久化：将上次成功采集的最大时间戳或最大ID写入数据库或文件，重启后能恢复。
- 重叠窗口：每次从水位线往前回退一小段时间（如5分钟），用重叠换取容错，再通过去重消除重复。
- 幂等写入：入库时使用唯一键或内容哈希做 upsert，保证重复数据不会产生副作用。
- 可观测性：记录每次采集的起止时间、拉取条数、新增条数、重复条数，便于发现异常。
- 失败隔离：单条数据解析失败不应阻塞整批，应记录错误并继续。
下面是一个最小可用的增量采集伪代码流程，展示了水位线读取、重叠窗口和幂等写入的配合方式：
# 增量采集核心流程（伪代码）
watermark = load_watermark("finance_news") # 读取上次水位线
start_time = watermark - timedelta(minutes=5) # 重叠窗口，防止边界漏抓
items = fetch_news(start_time=start_time, end_time=now())
for item in items:
fingerprint = md5(item.title + item.content)
if not exists(fingerprint): # 幂等去重
save_to_db(item, fingerprint)
new_watermark = max(item.publish_time for item in items)
save_watermark("finance_news", new_watermark) # 持久化新水位线
log.info(f"拉取={len(items)}, 新增={new_count}, 水位线={new_watermark}")
实践建议：在金融公告场景中，优先使用交易所或平台提供的“公告ID”作为水位线，而不是发布时间。ID通常单调递增且不受时区影响，比时间戳更可靠。如果只有时间戳，务必统一转换为UTC并保留原始时区字段。
总结来说，全量采集适合初始化和小规模场景，增量采集适合持续运行的生产管道。增量采集的关键不在于“少抓”，而在于准确记录进度、容忍边界重叠、保证写入幂等。掌握这些原则后，才能进一步处理金融新闻与公告中更复杂的反爬、限流和解析问题。