关于后端:详解支撑7亿用户搜索的百度图片处理收录中台

导读：在百度搜寻中，次要由“搜寻在线”和“搜寻离线”两局部形成，“在线”服务次要用于响应用户申请，“离线”服务则将各种起源的数据转换解决后送入“在线”服务中。“搜寻离线”的数据处理是一个典型的海量数据批次 / 实时计算联合的场景。

全文 4142 字，预计浏览工夫 8 分钟。

一、多模态检索背地的”离线“与“在线”

在百度搜寻中，次要由“搜寻在线”和“搜寻离线”局部形成，“在线”服务次要用于响应用户申请，“离线”服务则将各种起源的数据转换解决后送入“在线”服务中。“搜寻离线”的数据处理是一个典型的海量数据批次 / 实时计算联合的场景。

2015 年起，百度 App 上线了多模态检索能力，将智能化搜寻直观体现在用户背后。多模态检索是在传统文本检索之上，减少了视觉检索和语音检索的能力。

其中，“视觉检索”和“文本检索图片”这两类业务的离线、在线技术上，有很多中央是共通的。以视觉检索为例，产品状态包含：猜词、更多尺寸图片、图片起源、垂类图片（短视频、商品、等）、类似举荐等，其背地依靠的核心技术有分类（GPU 在线模型预估）与 ann 检索。

在 ann 检索方面，目前次要采纳的检索办法有基于聚类的 gno-imi、基于图的 hnsw，以及部分敏感 hash 办法，选型的次要思考是技术计划老本与特色的适用性，比方 gno-imi 是百度内开源的，内存占用比拟小的计划，利用到百亿规模的 ann 检索上老本可承受；部分敏感 hash 的办法，利用到 SIFT 这类部分特色上，能够增强手机拍照辨认场景下召回成果。

这些在线技术的背地，依赖的特色有百余种，离线要收录全网图片，并对图片计算特色，其算力开销是十分宏大的；另外，图片在互联网上依附于网页，还须要保护“图片 - 图片链接 - 网页链接”的关系（离线数据处理、在线利用都离不开数据关系，比方为了溯源，须要提供图片的起源网页 url 等）。

此种状况下，搜寻架构部与内容技术架构部根据本身业务与技术特点，联结设计与开发了“图片解决收录中台”，以期达到以下目标：

1. 对立的数据获取与解决能力，可整合图片类业务的数据获取、解决、存储逻辑，晋升人效，升高存储 & 计算成本。
2. 百亿~ 千亿级别的图片利用，可实现疾速调研、数据采集、全网数据更新能力。
3. 建设图片实时筛选与定制下发数据通路，晋升图片资源引入的时效性。

该我的项目在外部名为 Imazon 我的项目。Imazon 来自于 Image + Amazon，其中 amazon 代表中台能力的吞吐能力、DAG 解决能力、图片容量。

目前，图片解决收录中台，提供简单业务场景下单日解决数十亿级图片数据，秒级实时收录百 gps，全网收录万级别 gps。平台目前反对多个业务线的图片解决与收录需要，大幅提高了业务执行效率。

二、图片解决收 录中台的架构与关键技术

搜寻成果的继续优化，离不开数据与算力，次要以收录，存储，计算为外围。图片解决收录中台，心愿通过中台提供的通用能力包含：从时效、全网图片收录通路中筛选数据、提供大吞吐的流式解决机制、图片 - 网页关系刻画能力、原图 & 缩图存储、在线解决机制等。

2.1 图片解决收录中台解决什么问题？

图片解决收录中台的主体流程，经验 6 个阶段：网页 spider（获取网页内容），图片内容提取，图片 spider（爬取图片），特色计算（百余种特色），内容关系存储，建库。如下图所示：

2.2 图片解决收录中台的技术指标

中台的技术指标定义，从架构指标、成果、研发效率 3 方面来形容。

架构指标包含吞吐、扩展性、稳定性：

• 吞吐，即在老本限度内，进步吞吐，具体指标为：单数据大小：百 K bytes（图片 + 特色）；实时收录 百 qps；全网收录万级别 qps

• 扩展性，即云原生部署、算力资源弹性调度，有资源时快点算，没资源时慢点算。
• 稳定性，即不丢数据，主动重试，主动回放；时效性数据分钟级解决成功率；全网数据天级解决成功率

成果指标次要关注数据关系：

• 实在的图片 - 网页链接关系（e.g. 网页 / 图片登场了，关系更新）

研发效率指标包含业务通用性和语言灵活性：

• 业务通用性：撑持依赖全网图片的业务获取数据；特色迭代
• 语言灵活性：C++&go&php

2.3 图片解决收录中台的架构设计

图片解决收录是一个无界数据的流式处理过程，因而整体架构设计以流式实时处理零碎为主，兼反对批处理输出。同时，为了解决大吞吐需要、业务研发效率等问题，设计中采纳了弹性计算 & 事件驱动、业务逻辑与 DAG 框架解耦部署等思维。具体如下图所示，后文会具体解说。

2.4 图片解决收录中台的基础设施

百度基础设施：

• 存储：table、bdrp(redis)、undb、bos

• 音讯队列：bigpipe

• 服务框架：baidurpc、GDP(go)、ODP(php)

依靠 & 构建的业务基础设施

• Pipeline 调度：odyssey，撑持架构全景中的各 DAG
• 流控系统：在外围入口层，提供平衡流量、调节流量的能力
• 千仞：托管 / 调度 / 路由 百~ 千类上万实例的 cpu/gpu 算子
• 内容关系引擎：刻画图 - 网页关系，基于事件驱动计算，与 blades 联动弹性调度
• 离线微服务组件：Tigris，DAG 节点的具体业务逻辑放到近程 RPC 中执行

三、优化实际

上面简略介绍在面向大吞吐高算力场景下，中台的一些优化实际。

3.1 大吞吐流式解决架构的实际

老本（算力、存储）是无限的，面对大吞吐需要，在如下方向做了针对性优化：

• 音讯队列老本高
• 流量毛刺、波峰波谷带来的资源利用率有余
• 算力不够带来的数据沉积

3.1.1 音讯队列老本优化

在离线流式数据处理中，通过音讯队列在 DAG/pipeline 中传输数据是比拟惯例的计划，该计划能够借助音讯队列的长久化来保障业务对数据的不丢的要求（at least once）。业务特点：

• Pipeline/DAG 中的传输的是图片及其特色，百 K bytes，音讯队列的老本比拟昂扬
• 上游算子，不肯定须要所有数据，通过 message queue 透传所有字段性价比低

具体优化思路如下：

• DAG 中 message queue 传援用（trigger msg），DAG 中算子的输入存储到旁路 cache
• 旁路 cache 的高吞吐低成本优化，利用 DAG 中数据的生命周期，被动删除 & 脏写优化

具体协定设计为：

• Trigger msg（bytes），通过 message queue，miner 间点对点传输
• TigrisTuple（100K~ bytes）通过 redis 实现 miner 间共享
• ProcessorTuple（M~ bytes）通过旁路 cache 实现按需读写

3.1.2 流量平衡与波峰滞后计算

入口流量的波峰波谷或毛刺，使得全零碎必须依照峰值容量部署，然而低峰期资源利用率又不够。如下图：

具体优化思路如下：

通过反压 / 流控机制，在资源恒定的前提下，将零碎的总吞吐最大化

• 流控系统平滑流量，缩小均值与峰值的 gap，使得全零碎各模块的“容量利用率”稳固维持在高位
• DAG/pipeline 具备反压能力，当部分模块容量有余，反压到流控模块，流控模块自适应调节，波峰数据滞后到波谷计算
• 为解决业务上不可承受的数据滞后，辨别数据优先级，保障高优数据优先散发（全零碎的吞吐设计至多 cover 高优数据的吞吐）

△图 3 3 个优先级的流控

3.1.3 解决大吞吐场景下算力长期不够带来的数据沉积

全网数据收录场景下，特色计算存在 GPU 资源瓶颈，这些特色耗费的 GPU 卡十分微小，能够通过“错峰”与“离在线混布、长期资源应用”等思路能够解决该问题，然而引入了新问题：离线 pipeline 中无奈 buffer 这么多的数据，且不心愿反压影响上游 DAG 解决吞吐

具体优化思路：

• 剖析瓶颈点，拆分 DAG；利用存储 DB 作为“人造的流控”零碎，事件驱动（弹性调度计算特色、特色就位触发调度上游 DAG）。

3.2 内容关系引擎

互联网的图片内容关系，能够用一个三部图来刻画。采纳上面的概念定义进行形容：

• f：fromurl，代表网页，f 下有多个 o。f 纬度的特色：title、page type 等
• o：objurl，代表图片链接，一个 o 只能指向一张图片。o 纬度的特色：死链
• c：图片 content sign，图片内容的签名，代表图片。c 纬度的特色：图片内容、ocr、清晰度、人物，等
• fo：网页与图片链接的边。边的特色：图片上下文、alt
• oc：图片链接与图片的边。边的特色：图片爬取工夫

内容关系引擎，须要可能刻画如下行为：

为刻画互联网中各元素残缺关系形容，这是一个千亿节点规模，P 级别存储的图数据库，须要达成的零碎指标如下：

• 写性能：
• vertex：万级别 qps，单节点属性（100~K bytes）
• edge：十万级别 qps
• 读性能（全量筛选、特色迭代）：
• 导出的点、边属性信息（scan 吞吐需要：G bytes/s）

为了解决读写性能问题，基于 table 设计了 COF 三部图内容关系引擎，外围设计思路如下：

• C 表采纳前缀 hash 做数据划分，保障 scan 的程序性，并读到残缺关系（c 来源于哪些 o，o 来源于哪些 f），P 级存储
• O 表采纳 SSD 机制，反对查 O 对应的 C
• F 表采纳 SSD 介质，进步随机读性能；保留反向映射关系，反对通过 F 查找 O 与 C

为缩小随机写带来的 IO 瓶颈、升高零碎事务复杂性，采纳了“基于版本的校验办法，读时校验，异步登场”来保障关系的正确性。

3.3 其余实际

为晋升业务研发迭代效率、晋升零碎本身维护性，零碎解决了一些问题，然而在晋升“研发幸福感”的路上，才刚刚上路。咱们着重解决研发效率和保护老本的问题。

比方在业务接入效率方面：

数据源复用

• Problem：10 个业务的数据，有 10 种格局，proto 嵌入太多，看不懂
• Try：从异构 schema=> 规范 schema；OP 的 input/output 治理

DAG产出复用

• Problem：不能影响上游的 DAG 解决吞吐和速度。
• Try：DAG rpc 串联，解决级联阻塞；DAG 原生连接，数据生存周期问题，copy on write&erase

资源存储复用：

• Problem：我用了他产生缩图，然而这个缩图当初打不开了！什么，原图也被删了？
• Try：多租户机制，援用计数登场，cdn 对立接入、在线对立智能裁剪与压缩

在多语言反对方面：

• Problem：
• 想用 C ++/Python/PHP/go，框架兼容简单！速度慢了，谁的问题？
• 我只实现一个业务逻辑就行了，不想关怀 DAG 的太多细节
• Try：
• DAG 框架语言对立，通过近程 rpc 隔离业务实现
• Rpc Echo(trigger msg[in], tigris tuple[in], processor input list[in], processor output list[out])

在保护老本方面：

• Problem：
• 这个数据为什么没有收录？
• 短信 99+（warning、fatal 混淆）、怎么办：音讯队列又梗塞了
• Try：
• 分布式 app 日志 trace
• 监控 & 报警，分类 +howto
• 业务外围指标：收录规模 /s，按分位收录工夫，特色覆盖率，业务散发规模 /s，数据失落率，超时收录占比
• 系统核心指标：DAG 提交 PV，DAG 容量 / 利用率，OP status（OK、FAIL、RETRY、…），OP 容量 / 利用率，OP 耗时 / 超时率
• 关键点指标：依赖服务吞吐、时延、失败；OP 外部细节监控；

本期作者 | imazon

咱们近期正在招聘计算机视觉解决，索引检索，离线流式解决等岗位，欢送同学们关注同名公众号百度 Geek 说投递简历，期待大家退出！

举荐浏览

|这个好用的分布式应用配置核心，咱们把它开源了

|详解百度富媒体广告检索比对系统的关键技术

浏览原文
| 详解撑持 7 亿用户搜寻的百度图片解决收录中台

欢送大家关注同名公众号百度 Geek 说，更多干货、福利、内推等着你~