作者：冉辰，騰訊 WXG 后臺開發(fā)工程師

微信掃一掃識物是典型的“離線寫，在線讀”的業(yè)務(wù)，業(yè)務(wù)數(shù)據(jù)的存儲和檢索庫的構(gòu)建都是在離線環(huán)節(jié)完成。我們通過爬蟲系統(tǒng)收錄了小程序生態(tài)下的商品圖片，下載后進(jìn)行檢測摳圖，提取檢索特征，最終構(gòu)建成檢索庫交付到線上環(huán)境。這篇文章將主要介紹這一部分的工作。

0 什么是識物

識物是以圖像或視頻作為輸入，用以挖掘微信生態(tài)下商品、物品等有價值等信息。這里我們基本覆蓋了微信全量優(yōu)質(zhì)小程序電商，涵蓋上億商品 SKU，聚合了微信內(nèi)的搜一搜、搜狗等資訊，最終聚合后呈現(xiàn)給用戶。百度識圖和阿里拍立淘也是基于該技術(shù)發(fā)展而來。

工程上，識物工作主要可以分為三塊，如圖 1 所示：

圖1

算法模型

算法側(cè)主要是對檢測模型和多類目的檢索模型等持續(xù)煉丹，檢測模型需要返回圖片中物品的準(zhǔn)確位置；檢索模型需要保證同款物品的特征表達(dá)越近越好。

離線工程

識物是典型的“離線寫，在線讀”的業(yè)務(wù)，業(yè)務(wù)數(shù)據(jù)的存儲和檢索庫的構(gòu)建都是在離線環(huán)節(jié)完成。我們通過爬蟲系統(tǒng)收錄了小程序生態(tài)下的商品圖片，下載后進(jìn)行檢測摳圖，提取檢索特征，最終構(gòu)建成檢索庫 交付到線上環(huán)境。這篇文章將主要介紹這一部分的工作。

3.在線部署

算法模型和離線生成的檢索庫最終完成部署，對外服務(wù)。用戶識物時，檢索庫會召回一批相似物品，再經(jīng)過一系列復(fù)雜的精排、過濾邏輯，最終返回用戶看到的結(jié)果。

1 挑戰(zhàn)

1. 數(shù)據(jù)版本

數(shù)據(jù)版本主要分為兩類，一是算法模型版本，我們有 10+種業(yè)務(wù)模型，平均每周有 2-3 個模型迭代升級。二是檢索庫版本，在模型不迭代的情況下，每天有新數(shù)據(jù)的合并，即增量迭代；而每次算法模型變更，特征表達(dá)發(fā)生改變，需要根據(jù)新特征重新構(gòu)建檢索庫，即全量迭代。

在高頻的版本變更場景下，如何兼顧靈活性與安全性。

2. 數(shù)據(jù)處理性能

目前我們收錄的圖片數(shù)為 10 億左右，平均每天新增 1500w。除了圖片數(shù)量多，任務(wù)的流程也很多，如圖片下載、目標(biāo)檢測、特征提取等任務(wù)，每個任務(wù)每天都是千萬級的數(shù)據(jù)處理量。

如何高效的處理數(shù)據(jù)，提升業(yè)務(wù)的迭代效率。

3. 繁雜的流程

隨著業(yè)務(wù)的發(fā)展，簡單的業(yè)務(wù)流程已經(jīng)不能滿足我們?nèi)找鎻?fù)雜的業(yè)務(wù)需求。為了提升業(yè)務(wù)指標(biāo)，我們可能還需要圖片質(zhì)量，文本語義，死鏈、下架商品的過濾等任務(wù)。

如何在流程日益變多的情況下，不導(dǎo)致整個系統(tǒng)的臃腫。

4. 數(shù)據(jù)質(zhì)量

離線工程屬于重流程的業(yè)務(wù)，數(shù)據(jù)從產(chǎn)生和落地將經(jīng)歷九九八十一環(huán)，任何一環(huán)出錯都會導(dǎo)致結(jié)果有問題。發(fā)現(xiàn)問題的時間越晚，修復(fù)的成本越高，對業(yè)務(wù)的影響越難以估計(jì)。

如何科學(xué)的監(jiān)控和管理數(shù)據(jù)質(zhì)量，使系統(tǒng)有良好的可維護(hù)性。

2 數(shù)據(jù)版本

這里有多種維度的數(shù)據(jù)版本，例如模型版本，特征版本，檢索庫版本等，上游環(huán)節(jié)的版本變更將引發(fā)后續(xù)環(huán)節(jié)的變更，最終都將導(dǎo)致檢索庫版本變更。

圖2 數(shù)據(jù)流程簡圖

2.1 檢索庫

在我們的業(yè)務(wù)場景下，檢索庫的迭代是高頻操作，正常情況下每天會增量更新，而模型的變更又會引發(fā)檢索庫全量更新。數(shù)據(jù)量級上，我們的全量圖像是億級別的，按類目分庫后每個類目也是千萬級。

我們調(diào)研了業(yè)界內(nèi)主要用于圖像檢索的技術(shù)，如圖 3 所示。綜合考慮后，我們選取了靈活性更強(qiáng)、相對內(nèi)存占用更小的的 faiss-ivf 作為我們的索引庫構(gòu)建算法。

圖3 圖像檢索庫選型

對于每天的增量數(shù)據(jù)，我們每天對每個類目(10+個類目)都會構(gòu)造一個對應(yīng)當(dāng)天數(shù)據(jù)檢索庫。每個類目的全量檢索庫是由N 天的檢索庫合并生成(faiss-ivf 特性)，2000w 的數(shù)據(jù)合并僅需要 4 分鐘。基于這樣的設(shè)計(jì)，使得我們可以靈活的選取時間窗口的范圍，如圖 3 所示了窗口為 2 的合并方法。

這樣的好處是，如果某天數(shù)據(jù)發(fā)現(xiàn)有問題，只需要修復(fù)當(dāng)天數(shù)據(jù)后再進(jìn)行合并即可；如果需要丟棄某些數(shù)據(jù)，如舊數(shù)據(jù)，合并時不選取即可。

圖4?檢索庫生成

2.2 數(shù)據(jù)版本兼容

前面我們講到，模型變更最終都將引發(fā)檢索庫的全量迭代，這里的模型有檢測模型和檢索特征模型。新檢索庫上線時，本質(zhì)上是新舊數(shù)據(jù)的過渡，一般實(shí)現(xiàn)新舊數(shù)據(jù)的切換都會設(shè)計(jì)復(fù)雜的系統(tǒng)來保證數(shù)據(jù)一致性。

2.2.1 檢測模型變更

這種場景下的檢索庫變更，嚴(yán)格上來講我們并沒有實(shí)現(xiàn)新舊數(shù)據(jù)的一致性，我們只是通過簡單的方法使得即使新舊數(shù)據(jù)同時存在也不影響用戶的體驗(yàn)。

這里主要涉及到如何構(gòu)建我們的映射關(guān)系，我們?yōu)槊看螜z測出的結(jié)果都賦予一個唯一的單調(diào)遞增 id。替換模型后，同一張圖片的檢測結(jié)果會變化。可能摳圖的位置有變化、可能會扣取不同的物品、可能會扣取多個物品。

如圖 5 所示，檢索庫 v1 里只有上衣，對應(yīng)檢索 id 為 1；變更檢測模型后，檢索庫 v2 可以同時檢測出上衣和下衣，對應(yīng)檢索 id 為 2，3。這樣在線模塊可以逐步更新檢索庫，線上同時存在新舊檢索庫也沒有影響，如果請求落到舊庫返回 1，落到新庫返回 2，但最終都將返回正確的結(jié)果，結(jié)果上是一致的。

圖5 檢測模型變更

2.2.2 檢索特征模型變更

這種場景下的檢索庫變更則復(fù)雜許多，檢索庫存的特征來自于檢索特征模型。檢索模型變更后，同一個物品圖片的特征表達(dá)完全不同，維度甚至也發(fā)生了變化，如圖 6 所示。

我們需要同步變更檢索特征模型服務(wù)和新檢索庫，通過雙 buffer 的方式實(shí)現(xiàn)新舊數(shù)據(jù)的共存，而且要實(shí)現(xiàn)嚴(yán)格的路由協(xié)議來保證同一個請求在同版本的特征檢索服務(wù)和檢索庫中完成。

圖6 檢索特征模型變更

2.3 數(shù)據(jù)版本管理系統(tǒng)

在開發(fā)過程中，算法需要交付各種模型給離線和在線，離線生成的檢索庫也需要交付給在線，數(shù)據(jù)版本的迭代也需要考慮版本的可回退性。為了解耦多方之間的依賴，且避免在同步過程中直接操作文件帶來的風(fēng)險，設(shè)計(jì)了一套數(shù)據(jù)版本管理系統(tǒng)。

如圖 7 所示，資源發(fā)布者上傳資源到該系統(tǒng)，并附帶對應(yīng)業(yè)務(wù)、版本號及 md5。資源使用者只需要理解對應(yīng)業(yè)務(wù)當(dāng)前的版本號，版本管理系統(tǒng)會返回對應(yīng)的資源文件。線上實(shí)際使用時，在線模塊會定期輪訓(xùn)某業(yè)務(wù)對應(yīng)數(shù)據(jù)版本文件的 md5 和本地文件 md5 是否一致，不一致則會拉取最新的文件，拉取完成后校驗(yàn) md5 是否一致，最終實(shí)現(xiàn)更新。

在業(yè)務(wù)模型或檢索庫需要回退時，只需修改配置文件，重啟服務(wù)即可。

圖7 數(shù)據(jù)版本管理系統(tǒng)

2.4 docker 化

目標(biāo)檢測、檢索特征提取等是典型的圖像深度學(xué)習(xí)任務(wù)，業(yè)界內(nèi)有 caffe、pytorch、tensorflow、tensorRT 等多種深度學(xué)習(xí)框架，有的框架不能保證向上兼容。而我們負(fù)責(zé)煉丹的同學(xué)第一要務(wù)是追求效果指標(biāo)，在嘗試各種奇淫巧技時練出來的丹通常并不能和微信的線上環(huán)境很好的兼容。

簡而言之，在重算法的工程系統(tǒng)中，不僅有業(yè)務(wù)代碼的更新，還有工程環(huán)境的迭代。這非常適合使用 docker 來封裝和迭代業(yè)務(wù)環(huán)境。通過 docker 化部署，我們可以更方便的引入更多開源組件來支撐業(yè)務(wù)，也可以讓我們在一些框架選型上更加靈活。

就我們自己的業(yè)務(wù)場景而言，我們還可以利用微信深度學(xué)習(xí)任務(wù)平臺(yard)的計(jì)算資源，這部分屬于公用資源，需要搶占式使用。yard 也是 docker 化去執(zhí)行任務(wù)。這為我們業(yè)務(wù)可以借助 yard 公用資源作為臨時擴(kuò)容 worker 節(jié)點(diǎn)做了很好的鋪墊。

3 分布式計(jì)算

我們每天平均有 1500w 增量數(shù)據(jù)，全量為十億級別的數(shù)據(jù)。單機(jī)必然無法滿足處理的實(shí)效性，唯有分布式計(jì)算才能滿足要求。

3.1 數(shù)據(jù)拆分

正如 mapreduce，map 階段的工作我們需要對數(shù)據(jù)進(jìn)行拆分。這里對拆分原則除了平均外，還考慮了拆分后到數(shù)據(jù)的運(yùn)行時間。如果拆分太細(xì) GPU 的運(yùn)行效率會降低，拆分太粗會導(dǎo)致錯誤修復(fù)的時間成本變大。我們讓每個拆分后的任務(wù)都盡量控制在 1 小時內(nèi)完成，最終拆分的粒度為每個包 10w 左右。

3.2 數(shù)據(jù)并行計(jì)算

拆分后的數(shù)據(jù)進(jìn)行并行計(jì)算相當(dāng)于 reduce 階段，這里的重點(diǎn)是如何將拆分后的數(shù)據(jù)分發(fā)到多臺機(jī)進(jìn)行計(jì)算。此外，我們還希望公用資源空閑時可以非常靈活的進(jìn)行擴(kuò)容接入，提高并發(fā)處理能力。

我們結(jié)合 zookeeper 的分布式鎖特性，實(shí)現(xiàn)了一套可靠分布式任務(wù)隊(duì)列。worker 采用拉模式拉取隊(duì)列的任務(wù)。這樣的優(yōu)點(diǎn)是伸縮性好，可以靈活的增加和減少 yard 的機(jī)器資源。如圖 8，當(dāng)新 worker 接入后，從隊(duì)列中拉到任務(wù)直接執(zhí)行，可以實(shí)現(xiàn)秒級的擴(kuò)容。

圖8 伸縮性好

對于我們的場景，任務(wù)需要被可靠消費(fèi)，這里的可靠包含來兩層含義。

第一是避免任務(wù)被重復(fù)消費(fèi)，我們借助 zookeeper 的保活鎖，鎖通過心跳保持活性。如圖 9 中第 1，2 時刻，worker 拿到隊(duì)列里的任務(wù)搶鎖成功才可執(zhí)行；如果出現(xiàn)機(jī)器宕機(jī)，如圖 9 第三 3 時刻，鎖會自動釋放。

第二是完整消費(fèi)，我們在 task 被完全消費(fèi)結(jié)束后才刪掉隊(duì)列里的對應(yīng) task，如時刻 4 的 task2。時刻 3 由于機(jī)器宕機(jī)，task1 并未被完整消費(fèi)，因此依舊存在，后續(xù)可被繼續(xù)消費(fèi)。

圖9 可靠消費(fèi)

理論上講，我們的消費(fèi)模式屬于至少一次消費(fèi)(at least once)，極端情況下，如果 worker 執(zhí)行完任務(wù)還沒有回傳狀態(tài)時宕機(jī)，那任務(wù)仍處于未成功消費(fèi)，仍可能被后續(xù) worker 消費(fèi)。這里需要保證任務(wù)的冪等性。

引入公用計(jì)算資源提升了我們的處理能力，但同時也給我們帶來了一些小問題。例如，公用集群的機(jī)器配置比我們自己集群要好很多，為了使不同集群都能發(fā)揮最大的 GPU 性能，我們支持不同集群使用不同的全局參數(shù)配置。而且公用集群和文件系統(tǒng)不在同一個 idc，導(dǎo)致網(wǎng)絡(luò) IO 時間過長，降低了 GPU 利用時間，我們在公用集群的同 idc 實(shí)現(xiàn)了一套文件預(yù)拉取系統(tǒng)，根據(jù)任務(wù)隊(duì)列中存在的任務(wù)，提前同步待消費(fèi)文件到同 idc 的文件緩存系統(tǒng)。

為了提高 GPU 利用率，我們還做了大量的工程優(yōu)化，這里就不展開敘述了。基于分布式計(jì)算的框架，極大提升了我們的計(jì)算效率。拿計(jì)算效率最低的目標(biāo)檢測任務(wù)舉例，目前我們集群的處理能力可達(dá)到 5600w 圖/天，如果加上公用計(jì)算資源，可以達(dá)到 1.2 億圖/天(集群 12 臺 P4 雙卡，公用集群 yard-g7a 集群平均 10 個雙卡，深度學(xué)習(xí)框架使用的 tensorRT)。

4 任務(wù)調(diào)度

雖然我們每天有 1500w 左右的原始圖片，但最終符合錄入檢索庫的商品僅有一半不到。因?yàn)闉榱舜_保檢索數(shù)據(jù)的質(zhì)量，我們會在多個維度做數(shù)據(jù)過濾。現(xiàn)在我們的圖片從下載到建庫一共會經(jīng)歷 30+種中間任務(wù)，圖 10 僅展示了主要的任務(wù)流程模型。

圖10 任務(wù)流

4.1 任務(wù)系統(tǒng)

隨著任務(wù)的增多，尤其是許多任務(wù)間存在著復(fù)雜的依賴關(guān)系，每個任務(wù)都不是一個獨(dú)立的個體，每個任務(wù)的成敗都將影響最終的結(jié)果。為了更好的管理每個任務(wù)的狀態(tài)，梳理任務(wù)間的依賴，使得工程的復(fù)雜度不隨任務(wù)變多而變大，我們自研了一套任務(wù)調(diào)度系統(tǒng)。

調(diào)度系統(tǒng)主要由以下幾個部分組成：

• 文件系統(tǒng)：文件系統(tǒng)這里使用了微信自研分布式文件存儲系統(tǒng)的 WFS，我們所有中間數(shù)據(jù)和結(jié)果數(shù)據(jù)都存放在這里

• 存儲系統(tǒng)：主要有任務(wù)存儲和實(shí)例存儲，與一般實(shí)例存儲不同的是，為了分布式計(jì)算，我們在數(shù)據(jù)維度和類目維度做了拆分，一個實(shí)例包含一個或多個子實(shí)例

• 調(diào)度系統(tǒng)：主要負(fù)責(zé)收集、管理任務(wù)狀態(tài)，檢查任務(wù)依賴

• 觸發(fā)器：定時輪訓(xùn)調(diào)度系統(tǒng)，找到滿足執(zhí)行條件的任務(wù)實(shí)例

• 任務(wù)隊(duì)列：存儲待執(zhí)行的任務(wù)實(shí)例，由 worker 獲取依次消費(fèi)

圖11 任務(wù)調(diào)度系統(tǒng)

容災(zāi)性上，調(diào)度系統(tǒng)相關(guān)的模塊均是多機(jī)多園區(qū)部署，只要不是某個模塊完全掛掉，整套任務(wù)調(diào)度都可以正常執(zhí)行。

4.2 在線服務(wù)合并部署

對于每天的例行任務(wù)，實(shí)效性并不敏感，早幾個小時或晚幾個小時對業(yè)務(wù)影響不大。但 GPU 資源是是十分寶貴的，我們將部分 GPU 機(jī)器和在線 GPU 服務(wù)合并部署。結(jié)合在線流量屏蔽策略，實(shí)現(xiàn)高峰時期資源借給在線服務(wù)，低峰時期運(yùn)行離線任務(wù)。

如圖 12 所示，其為一臺參與離線任務(wù)閑時調(diào)度的在線模塊，我們擬定每天 0 點(diǎn)-7 點(diǎn)的低峰時間為離線運(yùn)行時間，7 點(diǎn)-24 點(diǎn)的高峰時間為在線模塊服務(wù)時間。最大限度的利用了寶貴的機(jī)器資源。

圖12 分時調(diào)度運(yùn)行

5 數(shù)據(jù)質(zhì)量

前面做的工作保證了我們以任務(wù)為粒度的工程可靠性，但任務(wù)的成功并不能保證業(yè)務(wù)數(shù)據(jù)是完整的，如數(shù)據(jù)丟失、代碼邏輯有問題等。為了監(jiān)控數(shù)據(jù)維度上的業(yè)務(wù)質(zhì)量，我們基于 ELK 搭建了一套數(shù)據(jù)系統(tǒng)，主要用于收集重要的基礎(chǔ)數(shù)據(jù)、業(yè)務(wù)數(shù)據(jù)、運(yùn)行結(jié)果等。

5.1 數(shù)據(jù)可視化

我們曾在幾次版本迭代過程中，發(fā)現(xiàn)數(shù)據(jù)出錯，但發(fā)現(xiàn)時已經(jīng)付出了極高的時間代價。因此我們希望在任意時刻都能觀察離線系統(tǒng)的運(yùn)作是否正常，數(shù)據(jù)的流轉(zhuǎn)是否符合預(yù)期。出現(xiàn)問題后可以及時干預(yù)修正，降低錯誤成本。

我們對涉及數(shù)據(jù)流轉(zhuǎn)的核心任務(wù)都做了數(shù)據(jù)結(jié)果上報，這樣子我們可以通過數(shù)據(jù)漏斗發(fā)現(xiàn)是否出現(xiàn)問題。這個問題在全量數(shù)據(jù)重跑的時候尤其重要。圖 13 展示了項(xiàng)目中核心任務(wù)的數(shù)據(jù)情況。

圖13 數(shù)據(jù)漏斗可視化

上圖看上去是每天任務(wù)級的數(shù)據(jù)監(jiān)控，但實(shí)際上我們我們的設(shè)計(jì)是擴(kuò)展到了每次任務(wù)級（這里定義為 planid），既可以是每天，也可以是每次覆蓋多天的重跑。? 我們按圖 14 的字段上報業(yè)務(wù)的運(yùn)行結(jié)果，前 4 個字段組成聯(lián)合唯一索引，planid 作為區(qū)分每次運(yùn)行的邏輯字段。這樣即使同一個任務(wù)在不同時期運(yùn)行結(jié)果是不同的，我們也能區(qū)分每一次運(yùn)行后，真實(shí)的數(shù)據(jù)結(jié)果。這個設(shè)計(jì)在保證每次大版本數(shù)據(jù)迭代時，對于把控數(shù)據(jù)整體運(yùn)行質(zhì)量十分重要也十分有效。

圖14 上報字段

5.2 一致性檢查

數(shù)據(jù)可視化方便了我們檢查問題，但是還不利于我們發(fā)現(xiàn)問題。我們還需要在數(shù)據(jù)出問題時，能及時告警、迅速修復(fù)。這最最重要的就是數(shù)據(jù)一致性，這里的一致性主要是一些核心任務(wù)的數(shù)據(jù)漏斗，輸入和輸出應(yīng)該是一致的。圖 15 中展示了一些存在關(guān)聯(lián)的任務(wù)，帶顏色線段代表數(shù)據(jù)存在關(guān)聯(lián)性。

為了滿足各種維度的統(tǒng)計(jì)、校驗(yàn)，同時又能快速支持新任務(wù)的檢查。我們封裝了核心的統(tǒng)計(jì)和校驗(yàn)邏輯，配置化告警任務(wù)，確保層層流程運(yùn)轉(zhuǎn)后的結(jié)果準(zhǔn)確無誤。

圖15 一致性檢查

5.3 評測系統(tǒng)

我們在對我們的檢索庫做比較大的版本迭代，或是線上策略有比較大調(diào)整時，直接灰度上線再觀察曲線有時并不能及時發(fā)現(xiàn)問題，存在很大的隱患。基于這種情況，我們開發(fā)了自動化測試系統(tǒng)。我們提前收集和整理了部分帶標(biāo)簽的數(shù)據(jù)樣本，每次更新都需要在測試環(huán)境自動化評測一次，如圖 16 所示。我們在結(jié)合具體指標(biāo)分析此次迭代是否可以安全上線(關(guān)鍵數(shù)據(jù)打碼)。

圖16 評測系統(tǒng)

5.4 數(shù)據(jù)淘汰

我們平均每天流入數(shù)據(jù)超過千萬，數(shù)據(jù)膨脹的速度非常快，這給我們帶來了極大的存儲成本和迭代成本。但回顧業(yè)務(wù)本身，其實(shí)許多商品數(shù)據(jù)在隨著時間的推進(jìn)，將變成過期、死鏈、下架數(shù)據(jù)。最簡單的做法就是使用窗口期來維護(hù)我們的數(shù)據(jù)，窗口外的數(shù)據(jù)自動淘汰，我們在 faiss 檢索庫選型時也是這樣考慮的。

但是我們也想到，直接暴力的淘汰舊數(shù)據(jù)也會有個致命問題。對于我們的業(yè)務(wù)而言，什么數(shù)據(jù)對我們是重要的，常見的熱門商品固然重要，但是相對冷門長尾商品同樣重要，后者決定來商品庫長尾的多樣性。如果刪掉某個商品，檢索庫可能就沒有這個商品了，這是十分糟糕的。

因此我們在做數(shù)據(jù)淘汰的時候，需要考慮對有價值的長尾商品做保留。? 圖 17 展示了我們數(shù)據(jù)淘汰的方式，通過這種方式，我們窗口期內(nèi)的數(shù)據(jù)質(zhì)量將變得越來越高，全量數(shù)據(jù)的增長也相對可控。

圖17 窗口期為K的數(shù)據(jù)淘汰

6 總結(jié)

以上我們大致介紹了“掃一掃識物”的離線系統(tǒng)中的所涉及的一些關(guān)鍵點(diǎn)，部分模塊仍在持續(xù)優(yōu)化中。未來掃一掃識物將引入更多場景的識別，拓展更多維度的物品，追求“萬物皆可掃”的目標(biāo)。

推薦閱讀

微信「掃一掃識物」的背后技術(shù)揭秘

揭秘微信「掃一掃」識物為什么這么快？

?騰訊技術(shù)沙龍?|?日均20億流量，攜程機(jī)票查詢系統(tǒng)的架構(gòu)升級?

更多內(nèi)容：

總結(jié)

以上是生活随笔為你收集整理的微信扫一扫识物的技术揭秘：抠图与检索的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。