pinterest使用 Apache Flink（近）实时地检测图像相似性

Pinterest是世界上最大的图片社交分享网站。网站允许用户创建和管理主题图片集合,例如事件、兴趣和爱好。以下为来自Pinterest工程师关于代码审查的一些思考。

作者：Shaji Chennan Kunnummel，Iaroslav Tymchenko

概览

Pinterest 的核心是一个视觉平台，因此理解图像并采取行动的需求至关重要。几年前，内容质量团队设计并实施了我们自己的批处理管道来检测相似图像。相似度信号在 Pinterest 被广泛用于各种用例，从改进基于相似图像的推荐到删除垃圾邮件和滥用内容。然而，为新创建的图像计算信号需要几个小时，这是垃圾邮件发送者和滥用者损害平台的一个漫长的窗口。所以最近，该团队实施了一个流管道来近乎实时地检测相似图像。

鉴于平台的规模，识别重复图像一直很困难，而实时识别则更具挑战性。这篇博文重点介绍了内容质量团队最近所做的工作，即利用 Apache Flink （近乎）实时地检测重复图像。

该项目的目标是将延迟减少到亚秒级，而不是批处理流水线需要数小时的延迟，而不会影响准确性和覆盖范围。

具体来说，我们想解决以下两个问题：

给定一张图片，查找之前在 Pinterest 上是否使用过相同的图片（或轻微的变化，也就是 NearDup）
给定一张图片，找到 Pinterest 上使用的所有相似图片的列表

出于实际原因，Pinterest 使用的整个图像世界被分解为一组不重叠的集群。请注意，相似关系不是传递的，因此使用近似关系来划分图像。对于每个集群，都会（随机）选择一个代表成员并将其用作集群 ID。更具体地说，我们使用图像之间的以下关系来表示不相交的集群：

图像（又名簇成员）到规范图像（又名簇头）
集群成员列表的规范图像

本文的其余部分重点介绍实时管道的设计和实现。请注意，本文不是关于检测图像相似性，而是关于如何实时进行。

挑战

Pinterest 上的大量图像在可扩展性和稳健性方面提出了一系列挑战。下面给出的数字可以让我们一窥我们正在处理的规模：

在 Pinterest 上保存的 Pin 图数：300B
每秒图像创建速率：~100（峰值为 200）
集群成员数量：平均 6 个，但少数集群高达 1.1M

鉴于信号的重要性以及如果信号延迟/损坏可能产生的影响，我们必须从一开始就将以下方面纳入系统：

易于调试
信号的可解释性
实时和长期监控信号的健康状况
在发生灾难性故障时重新处理图像子集的能力
能够尽可能无缝地从批处理管道切换到新管道

设计与实现

对于每个新创建的图像，我们运行以下步骤来检测相似图像：

从视觉嵌入中提取 LSH 项
查询自定义搜索引擎（使用 LSH 术语索引引导）以识别一组潜在候选人。根据与相关图像匹配的词条数量对候选者进行排序。
使用基于 TensorFlow 的分类器评估候选集。我们使用经验确定的阈值来过滤掉不匹配的图像
如果检测到类似的图像，则识别集群并更新存储。

整个系统构建为 Apache Flink 工作流。在高层次上，一旦嵌入准备好，就会触发相似性计算。 Pinterest 的媒体团队已通过 Kafka 提供通知。

架构图

本节给出的图表显示了管道架构的本质。

流与流的连接

相似度计算使用不同的嵌入（部分用于历史目的）进行 LSH 和机器学习评估。通常嵌入在几秒钟内可用，并且管道使用流-流连接来同步多个嵌入的可用性。

Manas：自定义搜索引擎

我们使用 Manas（Pinterest 的可配置搜索引擎）通过 LSH 词匹配来寻找潜在的候选图片。上一篇博文中解释了如何使用 LSH 术语识别相似图像的详细信息。

由于我们需要根据重叠项的数量对候选者进行排序，因此搜索集群已针对延迟的正确性进行了优化。

与传统搜索引擎不同，我们的用例通常需要扫描整个语料库，并期望返回具有最高术语重叠的结果。广泛的文档扫描确实对搜索基础设施造成了压力，并且需要严格的速率限制来规范搜索查询的速率。

一旦计算出相似度分数，搜索索引也会更新以使新创建的图像可搜索。

Tensorflow模型保存

我们利用 Pinterest 的名为 Scorpion 的 ML 服务基础设施来评估选定的候选图片。考虑到问题的规模（峰值时，每秒评估近 50 万个实例），模型服务使用较好的优化，如 GPU 和微批处理以获得更好的性能。

存储与服务

如果检测到重复图像，则需要更新底层存储以提供映射服务。如上所述，我们在存储中持久化了两种关系：

图像到簇头的映射
簇头到簇成员列表

图像到簇头的映射很简单，并且存储在 RocksDB 的本地变量中，它为我们提供了低延迟和线性可扩展性。

然而，簇头到成员列表的关系是一个更复杂的关系，因为簇大小严重倾斜（平均大小为 6，但少数簇达到一百万左右）。簇头到成员列表的关系在 Pinterest 自己的名为 Zen 的图形存储系统中存储为图形（节点是图像，边缘表示簇头到图像的映射）。使用图存储的主要原因是利用其分页支持来获取边（如果没有分页，K-V 对将具有非常大的 V，这将限制其在在线 K-V 系统中的使用）。

这些关系通过称为 Galaxy 的通用信号传递系统提供服务，该系统提供低延迟的信号获取。

引导现有关系

我们利用 Flink 的文件观察器功能来引导 RocksDB 和 Zen 图形存储。历史数据被转换为 Flink 工作流程可以理解的模式，并保存在 AWS S3 上的目录中。工作流中添加了一个文件观察器操作符，以观察 S3 位置并将数据批量上传到存储系统中。

管道的可操作性

该管道的设计和实施具有可操作性。

可调试性

由于管道很复杂，我们通过 Flink 算子实现了特殊的调试数据传播。调试详细信息被推送到 Kafka 队列，并使用 Pinterest 自己的名为 Merced 的可扩展 Kafka 物化基础设施进行持久化。系统还内置了功能，可以选择性地将图像 ID 提取到管道中，并实时检查中间结果，以便更好、更轻松地进行调试。