你是否也遇到过这样的场景：同一个商品页面，仅仅因为链接后面跟了不同的广告追踪参数、会话ID或点击来源，就被系统当成了多个不同的页面来抓取和渲染？对于处理数百万个商家域名的 Pinterest 工程师来说，这可不是小麻烦。
Pinterest 工程团队开发了一套名为“最小重要查询参数集”（MIQPS）的 URL 标准化系统，专门用于优化其大规模数据采集管道中的内容去重处理。这套系统的核心任务，就是判断 URL 中哪些查询参数真正影响页面内容、必须保留，哪些只是无伤大雅的“装饰”，可以安全移除。最终目标很明确：在保证数据采集准确性的同时，大幅度削减数百万个域名上重复内容带来的额外处理开销。
这套系统部署在 Pinterest 的内容采集基础设施中，负责应对来自不同商家和发布商网站的 URL。现实中的情况是，大量 URL 实际上指向同一个底层页面，但它们因为携带了五花八门的跟踪参数、活动标识符、会话令牌等查询字符串变量而变得千差万别。虽然下游系统最终也能发现这些内容重复，但在此之前，每一个 URL 变体都已经独立地消耗了抓取、渲染和索引资源。在 Pinterest 这种体量下，这无疑是一笔巨大的基础设施开销。
对于这个问题的棘手程度，Pinterest 软件工程师 Shanhai Liao 在一篇博文中做了很形象的说明：
这个问题看似简单，但当你像 Pinterest 这样，运营在数百万个商家域名上，而这些域名的 URL 规范又千差万别时，它就变得异常复杂。静态白名单只在主流平台上好用，面对海量的长尾场景，我们必须拿出更智能的解决方案。
这正是 MIQPS 的用武之地。它一改过去那种依赖人工维护白名单、黑名单或特定域名启发式规则的“手工作坊”式做法。对于那些 URL 结构五花八门的长尾域名，传统方法很难规模化。MIQPS 则另辟蹊径，采用数据驱动的方式来做判断：移除一个查询参数后，页面的渲染内容会不会变？如果内容变化超过预设的阈值，该参数就会被标记为“重要”并予以保留；否则，它就会被视为噪声，在规范化过程中被移除。
这套系统的运作逻辑可以拆解为几步：首先，它会从 Pinterest 的数据采集管线中汇聚海量 URL，并根据查询参数的模式进行分类。接着，系统会渲染页面并生成内容指纹，然后比对移除某个参数前后的内容差异。这样一来，参数的重要性就不再依赖预设规则或 canonical 标签这类元数据了。Pinterest 特别指出，规范标签经常缺失、自相矛盾，甚至本身就混杂着追踪参数，无法作为大规模去重的可靠依据。
MIQPS 内置了一套可调参数，用来控制内容不匹配的阈值和最小样本量。为了提升效率，它还采用了“早期退出”逻辑：经过有限次的测试后，若发现参数移除导致的不匹配率已经越过红线，就会立刻停止评估，避免无谓的页面渲染开销。当数据不足时，系统会保守地将参数视为非中立参数来处理。最终产出的是一份参数重要性映射表，存放在配置服务中，可以在运行时与静态规则一同生效。此外，异常检测机制为 MIQPS 上了一道保险：它会拒绝那些导致重要参数降级的更新，同时允许安全地向非中立参数集里添加新成员。
在架构设计上，MIQPS 将离线分析与在线处理清晰地剥离开来。最耗时的内容渲染和参数评估工作都放在离线环境执行，而线上系统在处理 URL 时，只需要直接套用预先算好的规则即可。Pinterest 表示，通常 URL 结构的演变非常缓慢。对于这种体量的数据摄取系统来说，离线计算是在数据时效性、成本和运维复杂度之间做出的务实权衡。
对于像 Pinterest 这样需要处理海量异构数据的平台而言，如何在自动化与准确性之间找到平衡，始终是工程师们面临的核心挑战。这套基于内容指纹的 URL 标准化方案，或许能给正在处理类似问题的你带来一些新的思路。在 云栈社区，我们持续关注这类大规模 后端 & 架构 领域的工程实践，欢迎来分享你的见解。
原文链接：
https://www.infoq.com/news/2026/06/pinterest-miqps-url-dedup/
声明：本文由 InfoQ 翻译，未经许可禁止转载。
| 
发表于 昨天 23:59
|
查看: 3|
回复: 0
