数据采集中的去重策略：URL去重、内容指纹和增量更新实战

重复数据的代价比你想的大

一个典型的企业级数据采集项目，如果不做去重处理，重复率可以高达30%到60%。这意味着近一半的存储空间、网络带宽和处理算力在做无用功。更严重的是，重复数据会干扰后续的数据分析和模型训练，导致统计偏差和结论失真。

去重不是采集完再清洗的事后工作，而是应该贯穿采集全流程的核心策略。从URL层面避免重复抓取，到内容层面识别近似重复，再到增量采集只抓新内容，每个环节都有成熟的技术方案。

URL去重：从入口杜绝重复抓取

基于集合的精确去重

最简单的URL去重方案是维护一个已访问URL的集合。每次抓取前检查URL是否在集合中，不在则抓取并加入集合。

用 Python 的 set 在内存中做去重，适合小规模采集（百万级以内的URL）。但当URL量级到千万甚至上亿时，内存占用会成为瓶颈。一个 URL 平均 100 字节，1 亿个就要近 10GB 内存。

Redis 集合方案：把已访问URL存入 Redis 的 Set 数据结构，用 SISMEMBER 命令做存在性检查。Redis 支持集群部署，可以水平扩展。但内存消耗仍然是主要问题。

布隆过滤器：以误判换空间

布隆过滤器（Bloom Filter）是大规模URL去重的经典方案。它是一种概率型数据结构，用极少的内存实现近似的集合成员判断。

核心原理：用 k 个哈希函数将每个URL映射到一个位数组上。查询时，如果所有对应位都为1，则"可能存在"；只要有一位为0，则"肯定不存在"。

布隆过滤器的优势在于空间效率。存储1亿个URL，在1%的误判率下只需要约114MB内存，相比直接存储节省了近百倍空间。误判只会导致少量URL被跳过（漏采），不会导致重复采集。

Python 中可以用 pybloom-live 或 redis-py 的 BF 模块直接使用。Redis 4.0 以上版本原生支持布隆过滤器模块，适合分布式环境。

URL标准化

URL去重的前提是 URL 标准化。同一个页面可能有多种 URL 形式：

• 协议不同：http 和 https
• 大小写差异：/News/ 和 /news/
• 参数顺序不同：?a=1&b=2 和 ?b=2&a=1
• 带不带尾部斜杠：/news 和 /news/
• 追踪参数：?utm_source=xxx

在加入去重集合之前，统一做 URL 标准化处理（scheme 小写、path 小写、参数排序、去除追踪参数、统一斜杠），可以大幅降低因URL格式差异导致的重复抓取。

内容去重：识别"换了马甲"的重复

URL去重只能解决完全相同URL的重复问题。实际中，很多网站同一篇内容有多个入口URL，或者不同页面内容高度相似。这就需要基于内容的去重。

精确去重：哈希指纹

对页面的核心文本内容（去掉HTML标签、导航、广告等模板部分）计算 MD5 或 SHA256 哈希值。哈希值完全相同，内容就完全相同。

这种方案简单高效，但只能处理完全一致的内容。如果两篇文章只差了一个字或一个日期，哈希值就完全不同，无法识别为近似重复。

近似去重：SimHash算法

SimHash 是 Google 用来做网页去重的算法，核心思想是把文本转换成一个固定长度的指纹（通常64位），内容相似的文本指纹也相似。

算法流程：

1. 对文本分词，每个词计算传统哈希
2. 根据每个词的权重（TF-IDF），对哈希值的每一位做加权累加
3. 累加结果为正取1、为负取0，得到最终指纹

两个指纹之间的海明距离（不同位数的个数）代表内容的差异程度。经验值是海明距离小于3时，内容高度相似。

MinHash与LSH

MinHash 是另一种近似去重方案，基于集合的 Jaccard 相似度。它特别适合判断两个文档的关键词集合是否高度重叠。

配合局部敏感哈希（LSH），可以在海量文档中快速找到相似文档对，时间复杂度从 O(n²) 降到近似 O(n)。这在千万级文档的去重场景中几乎是必选方案。

增量采集：只抓新内容

去重的最高境界不是采集后去重，而是根本不采集已有的内容。

基于时间戳的增量

最简单的增量策略：记录上次采集的时间，下次只采集该时间之后发布的内容。很多网站的列表页按时间排序，翻到上次最后采集的位置就停止。

这要求目标网站有可靠的时间信息，并且不会修改老内容。适合新闻类、论坛类网站。

基于HTTP头的增量

利用 HTTP 协议的缓存机制：发送请求时带上 If-Modified-Since 或 If-None-Match 头。如果内容没变，服务器返回 304 状态码而不是完整内容，节省带宽和处理时间。

但很多网站不正确实现这些HTTP头，实际可用性有限。

基于内容变化检测的增量

对已采集页面保存一个内容摘要（如正文前200字的哈希值）。再次访问时，先获取页面，计算摘要与已保存的对比。相同则跳过，不同则更新。

这个方案适合需要监控页面内容变化的场景，比如价格监控、舆情跟踪。

数据库层面的兜底去重

即使前端采集做了充分的去重，入库时仍需要一道兜底检查。常用方案：

1. 唯一索引：在数据库中对URL或内容哈希字段建立唯一索引，重复数据直接被数据库拒绝
2. UPSERT操作：使用 INSERT ON DUPLICATE KEY UPDATE（MySQL）或 INSERT ON CONFLICT（PostgreSQL），遇到重复自动更新而非报错
3. 定期清洗：对已入库数据定期运行 SimHash 近似去重，清理漏网的相似内容

实际效果对比

去重不是一个单点技术，而是一套组合策略。实际项目中通常是 URL 标准化 + 布隆过滤器 + 内容SimHash + 数据库唯一索引的多层配合使用。广州万户网络在企业数据采集项目中，会根据数据规模和业务场景设计合适的去重方案，确保采集效率和数据质量。如果您的采集项目正受重复数据困扰，欢迎访问 万户网络官网 或致电 020-22103921 / 135-3532-1113 获取技术支持。