詳解支撐7億使用者搜尋的百度圖片處理收錄中臺

導讀：在百度搜索中，主要由「搜尋線上」和「搜尋離線」兩部分構成，「線上」服務主要用於響應使用者請求，「離線」服務則將各種來源的資料轉換處理後送入「線上」服務中。「搜尋離線」的資料處理是一個典型的海量資料批次/實時計算結合的場景。

全文4142字，預計閱讀時間8分鐘。

一、多模態檢索背後的」離線「與「線上」

在百度搜索中，主要由「搜尋線上」和「搜尋離線」部分構成，「線上」服務主要用於響應使用者請求，「離線」服務則將各種來源的資料轉換處理後送入「線上」服務中。「搜尋離線」的資料處理是一個典型的海量資料批次/實時計算結合的場景。

2015年起，百度App上線了多模態檢索能力，將智慧化搜尋直觀體現在使用者面前。多模態檢索是在傳統文字檢索之上，增加了視覺檢索和語音檢索的能力。

其中，「視覺檢索」和「文字檢索圖片」這兩類業務的離線、線上技術上，有很多地方是共通的。以視覺檢索為例，產品形態包括：猜詞、更多尺寸圖片、圖片來源、垂類圖片（短視訊、商品、等）、相似推薦等，其背後依託的核心技術有分類（GPU線上模型預估）與ann檢索。

在ann檢索方面，目前主要採用的檢索方法有基於聚類的gno-imi、基於圖的hnsw，以及局部敏感hash方法，選型的主要考慮是技術方案成本與特徵的適用性，比如gno-imi是百度內開源的，記憶體佔用比較小的方案，應用到百億規模的ann檢索上成本可接受；局部敏感hash的方法，應用到SIFT這類局部特徵上，可以加強手機拍照識別場景下召回效果。

這些線上技術的背後，依賴的特徵有百餘種，離線要收錄全網圖片，並對圖片計算特徵，其算力開銷是非常龐大的；另外，圖片在網際網路上依附於網頁，還需要維護「圖片-圖片連結-網頁連結」的關係（離線資料處理、線上應用都離不開資料關係，比如為了溯源，需要提供圖片的來源網頁url等）。

此種情況下，搜尋架構部與內容技術架構部依據自身業務與技術特點，聯合設計與開發了「圖片處理收錄中臺」，以期達到以下目的：

統一的資料獲取與處理能力，可整合圖片類業務的資料獲取、處理、儲存邏輯，提升人效，降低儲存&計算成本。百億~千億級別的圖片應用，可實現快速調研、資料採集、全網資料更新能力。建設圖片實時篩選與定製下發資料通路，提升圖片資源引入的時效性。

該項目在內部名為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：網頁與圖片連結的邊。邊的特徵：圖片上下文、altoc：圖片連結與圖片的邊。邊的特徵：圖片爬取時間

內容關係引擎，需要能夠刻畫如下行為：

為刻畫網際網路中各元素完整關係描述，這是一個千億節點規模，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對應的CF表採用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內部細節監控；

作者：百度Geek說連結：https://juejin.cn/post/6963510398817419271來源：掘金