什么是去重？
Scrapeless Agent Browser提供了管理的浏览器会话，用于收集JavaScript渲染的公共页面，这些页面可以为去重和实体解析工作流提供数据。
TL;DR
- 去重解决的是身份，而不是视觉相似性。 匹配规则必须说明记录所代表的现实世界实体或事件。
- 当精确键稳定时，它们是最安全的。 源标识符或规范URL可以避免文本相似性的歧义。
- 模糊匹配需要审查阈值。 相似性评分并不证明两个记录是相同的。
- 生存规则保护信息。 合并必须定义哪些值获胜以及保留哪个来源。
- 质量通过标记对进行测量。 精确度和召回率揭示了被一个匹配率隐藏的不同成本。
去重的定义没有空话。
去重是识别代表相同现实世界项、事件或实体的记录的过程，然后应用明确的政策来保留、连接、合并或丢弃它们。政策与匹配方法同样重要，因为两行相似数据并不意味着可以互换。
精确去重比较稳定的值或指纹。键控去重使用一个或多个字段来识别该实体。模糊方法比较名称、地址、描述或其他不完美属性，并生成必须根据错误匹配的成本进行解释的分数。正式边界与 PostgreSQL唯一性约束一致，适用于该术语在产品讨论中的宽松使用。
去重并不意味着删除每一个重复的值。两个合法订单可能共享一个客户和总额，两个页面可能重复一个产品标题，两个事件可能在不同时间携带相同的有效负载。身份、观察时间和业务粒度决定重复是否为重复。命名边界可以防止团队请求概念提供属于存储、调度、安全或业务政策的保证。
重复候选如何变成一条记录
可靠的去重路径将候选生成、比较、决策和生存分开。将这些阶段合并到一个不透明的函数中会使错误合并难以诊断，并阻止审查者查看哪些证据推动了结果。
- 仅规范化比较所需的字段，同时保留原始值。此阶段应暴露其输入、决策、输出和所有者，以便后续调查能够区分源问题和处理问题。
- 使用阻塞键生成候选，以便不相关的记录不会被彻底比较。此阶段应暴露其输入、决策、输出和所有者，以便后续调查能够区分源问题和处理问题。
- 使用精确、语音、标记、距离或领域特定证据为每对候选评分。此阶段应暴露其输入、决策、输出和所有者，以便后续调查能够区分源问题和处理问题。
- 根据文档阈值将对分类为匹配、不匹配或审查。此阶段应暴露其输入、决策、输出和所有者，以便后续调查能够区分源问题和处理问题。
- 应用保留、链接或合并政策，并保留生存记录背后的源血统。此阶段应暴露其输入、决策、输出和所有者，以便后续调查能够区分源问题和处理问题。
数据库约束可以防止新的精确重复，但它们无法解决历史记录、拼写变体、变更标识符或跨系统分割的记录。实体解析处理更广泛的证据，而唯一约束在写入时强制执行更窄的不变性。第二个技术视图出现在 Apache Spark dropDuplicates API. 该引用描述了一个具体模型，而不是依赖于类比。
精确、键控和模糊去重
| 方法 | 最佳契合 | 主要风险 |
|---|---|---|
| 精确行哈希 | 字节稳定的重复记录 | 格式变化隐藏重复 |
| 复合业务键 | 稳定字段组合 | 键更改或被重用 |
| 规范标识符 | 源ID或规范化URL | 源身份不完整 |
| 模糊相似性 | 名称和描述性文本 | 相似实体被合并 |
| 人工审查团队 | 高成本模糊配对 | 审查队列在没有政策的情况下增长 |
精确的方法更容易解释，而模糊的方法覆盖更复杂的身份。许多系统使用级联：首先是确定性标识符，其次是精确的标准化键，仅针对未解决的候选者进行评分比较。
当其合同与工作负载匹配时，较小或简单的选项可以是正确的，而更复杂的选项会产生成本，如果团队无法操作或测试它。
重复控制的收益所在
客户和帐户记录
将源记录链接到一个实体，而不删除地址、同意状态或特定于系统的标识符。
产品目录
统一因商家命名而异的列表，同时保持包裹大小、变体和区域差异。
事件摄取
防止相同事件标识符在生产者多次提交时更改汇总。
网站监控
避免在保留捕获历史的同时将未更改的页面或重复列表计为新的观察。
当下游用户需要一个稳定的实体视图、一个事件计数或一个当前列表时，价值才会显现。当虚假合并删除了合法差异时，成本就会显现，因此匹配政策必须遵循业务规律。每个用例都需要一个指定的消费者、一个被接受的来源和一个可衡量的成功条件。没有这三个细节，实施工作往往倾向于优化活动，而非结果。
选择匹配键和存活规则
从身份和后果开始。定义实体，列出可信的标识符，描述特定于源的缺陷，并决定不确定的配对是否应保持分离或进入审查。
- 声明粒度。 说明一个记录是否代表一个实体、版本、事件、列表或观察。
- 保持源标识符。 一个黄金记录不应删除追踪或撤销合并所需的键。
- 将匹配与合并分开。 一个可能的匹配可以链接，而不立即覆盖任何记录。
- 在标记配对上进行校准。 阈值应反映真实的假阳性和假阴性成本。
- 使决策可逆。 存储合并历史以及足够的证据以拆分一个错误集群。
集群级审查很重要，因为成对匹配可以形成链条。如果A匹配B，而B匹配C，系统仍然需要决定这三个是否属于一个实体。相关约束在 RFC 8785 JSON 规范化 提供了另一个主要参考，用于选择背后的互操作性、数据或执行假设。
生产设计应记录稳定状态和变更路径。团队需要知道如何将新字段、工作者、部署、时间表或消费者引入系统；如何判断兼容性；以及哪些证据允许接受或拒绝更改。
损坏数据的去重错误
大多数有害缺陷来自假设一个方便的字段是永久标识符。名称、标题、地址和URL可能会更改或被共享，而一个所谓的唯一源键可能缺失或被回收。
- 在定义身份之前删除。 重复字段被视为重复记录，而不考虑粒度。
- 过度规范化比较文本。 不同的产品变体或人归并为相同的标记。
- 一个全局阈值。 不同的源和实体类型接收相同的风险政策。
- 没有不确定状态。 每对配对被强制为匹配或非匹配，尽管证据薄弱。
- 失去来源。 存活的行无法追溯其贡献来源。
当计数意外变化时，要分别检查候选生成、配对证据、阈值版本、集群形成和存活情况。从最小的责任层开始，比较预期和观察状态，并将纠正措施与证据相结合。该方法避免了模糊的指令来增加容量或放宽验证。
去重收集的网站记录
收集的网络数据通常会重复，因为页面重叠，URL携带跟踪参数，列表出现在多个类别中，以及计划捕获会随时间观察同一实体。
对于公共网络输入，获取记录应包括请求的URL、最终URL、收集时间、响应模式和在下游处理开始前的内容检查。Scrapeless Agent Browser处理受管理的浏览器会话；应用程序仍然拥有源批准、选择器、工作负载边界、保留和字段含义。
仅规范化文档化的URL部分，保留捕获时间，并区分重复实体与重复观察。当前状态表可以每个列表保留一行，而观察表则保留每个有意义的日期状态。当用例需要审计时，保持原始证据与策划表示相分离。原始证据支持在解析器或合同更改后重新处理，而策划记录支持稳定的分析和自动化。
收集层证明了哪一页被检索；去重层定义了身份；消费者选择链接记录是成为当前视图还是保持独立的历史证据。这种分离还使成本和失败可见。收集、转换、验证、存储和交付可以独立测量，而不是隐藏在一个作业状态中。
去重准备清单
在设计审查期间使用这些问题。书面的答案可以及早暴露分歧，为审查人员提供稳定的基础来测试实施情况。
- 一行代表现实世界中的什么事物？
- 每个来源中哪些标识符是稳定的？
- 哪些字段可以在不创建新实体的情况下更改？
- 错误合并的成本是多少？
- 哪些配对需要审查？
- 集群是如何从配对决策形成的？
- 合并可以被逆转吗？
- 哪些指标是从标记的事实计算得出的？
当审查人员能够重现匹配，解释不匹配，并在错误合并后恢复记录时，过程就准备好了。随着数量、来源行为、消费者期望或服务边界的变化，重新审视答案。适合探索性批处理的设计可能不适合连续的生产路径。
结论：去重需要身份合同
去重将重复或冲突的记录转化为明确的身份决策。安全系统从粒度开始，尽可能使用确定性证据，孤立不确定情况，保留来源，并根据标记实例评估结果。目标不是最小行数；而是实体和观察的最准确表示。
下一步的实际步骤是为一个真实的工作负载编写最小的可测试合同，在每个边界捕获证据，仅在测量的行为与合同匹配后再扩展。
准备构建可追溯的去重管道吗？
收集已批准的公共页面，保留来源，并在明确的身份合同下解决重复记录。
今天注册并获得 $5的免费信用 — 无须信用卡.
领取你的$5信用→常见问题
去重和数据清理有什么区别？
去重是一个特定的数据质量任务，解析代表相同实体或事件的记录。数据清理则更广泛，可能会修正类型、格式、缺失值、无效代码或不一致单位。清理步骤可以改善匹配，但应保留用于审计合并的源值。
唯一约束是否取代去重？
不。唯一约束防止违反声明的数据库不变式的值。它无法发现历史重复、跨系统身份、拼写变体、重用的源标识符或模糊匹配。在定义身份规则后，它最好作为预防措施使用。
模糊匹配应该多准确？
准确性必须与标记配对以及每个错误的业务成本进行评估。高成本的错误合并通常会证明保守的自动阈值加上审核带是合理的。一个总的准确率数字可能掩盖稀有来源或实体类型的糟糕结果。
重复记录是否应该删除？
不应该自动删除。系统可以链接记录，保留一个当前表示，保留所有源行，或合并选定字段。保留血统和合并历史通常是审计、纠正和源特定属性所必需的。
去重如何适用于网络数据？
网络去重可以统一规范的URLs或列表，同时保留每个捕获作为历史证据。关键是将实体身份与观察身份分开，以便重复的收集不会抹去有意义的价格、可用性或内容变化。