0到1再到100 蘑菇街搜索與推薦架構(gòu)的探索之路

作者：王雪燕 2017-05-24 11:29:10

本文將和大家分享蘑菇街在搜索推薦上踩過的坑及在探索路上的經(jīng)驗總結(jié)。我們的經(jīng)驗雖算不上業(yè)界最佳實踐，但也是一步步從0到1再到100，希望大家可以從中得到一些收獲。

【51CTO.com原創(chuàng)稿件】丁小明，花名小寶，蘑菇街搜索技術(shù)團隊負責(zé)人。2011年底加入蘑菇街，2013年開始負責(zé)搜索團隊，見證了蘑菇街一路蓬勃發(fā)展的歷程，也和團隊一起從零起步摸爬滾打，打造了蘑菇街的搜索推薦體系，包括自主研發(fā)的C++主搜引擎和廣告引擎、實時個性化推薦系統(tǒng)、基于開源Solr/ES深度定制的實時搜索平臺等。

小寶·蘑菇街搜索技術(shù)團隊負責(zé)人

以下內(nèi)容根據(jù)小寶老師在WOTA2017 “電商大促背后的技術(shù)挑戰(zhàn)”專場的演講內(nèi)容整理。

我將和大家分享蘑菇街在搜索推薦上踩過的坑及在探索路上的經(jīng)驗總結(jié)。我們的經(jīng)驗雖算不上業(yè)界最佳實踐，但也是一步步從0到1再到100，希望大家可以從中得到一些收獲。

搜索架構(gòu)的探索之當(dāng)前現(xiàn)狀

蘑菇街搜索當(dāng)前架構(gòu)

如上圖，是蘑菇街當(dāng)前搜索架構(gòu)，分為在線和離線兩部分。在線部分主要職責(zé)是處理在線的搜索請求。離線部分的主要職責(zé)是處理數(shù)據(jù)流。

在線請求鏈路

如上圖，是整個在線請求鏈路，主要分為topn->qr->引擎->精排->透出五個環(huán)節(jié)。

第一步，請求首先進入topn系統(tǒng)，做ab配置/業(yè)務(wù)請求鏈路配置。

第二步，請求進入QR改寫系統(tǒng)做切詞，同義詞擴展，類目相關(guān)性，插件化等。

第三步，進入UPS用戶個性化數(shù)據(jù)存儲系統(tǒng)。

第四步，投放層得到UPS和QR兩部分的數(shù)據(jù)后，放入搜索引擎做召回。搜索主要會經(jīng)過一輪海選，海選的依據(jù)是文本相關(guān)性和商品質(zhì)量，這樣做是為確保召回的商品質(zhì)量大致可靠。之后會經(jīng)過多輪初選，過程中會應(yīng)用到更復(fù)雜的算法模型，對海選的結(jié)果進行排序。搜索引擎得到粗排的結(jié)果約千級別。

第五步，粗排結(jié)果進入到精排系統(tǒng)，精排系統(tǒng)主要通過算法，做個性化排序、實時預(yù)測，精排和引擎類似，也支持多輪排序。經(jīng)過精排系統(tǒng)之后，最終把結(jié)果透出給業(yè)務(wù)層。

蘑菇街統(tǒng)一引擎系統(tǒng)

如上圖，左側(cè)紅色框內(nèi)是蘑菇街統(tǒng)一引擎系統(tǒng)，包含用戶個性化存儲系統(tǒng)、精排存儲、商品引擎、廣告引擎等。由于這樣的形式維護成本特別高，故做了右圖這個統(tǒng)一的Zindex內(nèi)核架構(gòu)。這個架構(gòu)的最底層是共享內(nèi)存分配器，再上層是可支持不同數(shù)據(jù)結(jié)構(gòu)的各種引擎，再上層是索引管理。基于這個架構(gòu)，不同的引擎可根據(jù)各自需求去創(chuàng)建自己的索引。

跟這個架構(gòu)相關(guān)的，就是我們的運維平臺，是基于公司Docker虛擬化技術(shù)做的一個運維平臺，能夠非常快的支持索引創(chuàng)建，包括創(chuàng)建之后整個索引數(shù)據(jù)的管理。還有就是排序平臺，用來提供算法配置變更服務(wù)。

搜索架構(gòu)離線部分的數(shù)據(jù)流程

如上圖，是離線的數(shù)據(jù)流程的情況，主要職責(zé)是數(shù)據(jù)流的處理，完整的索引數(shù)據(jù)分為算法數(shù)據(jù)和業(yè)務(wù)數(shù)據(jù)。

算法數(shù)據(jù)參與排序，整個鏈路從最前端ACM打點、再落到整個數(shù)據(jù)倉庫、經(jīng)過清洗之后，在數(shù)據(jù)平臺上跑訓(xùn)練腳本，得出的特征導(dǎo)到特征平臺，再同步到線上。

業(yè)務(wù)數(shù)據(jù)的主要來源就是DB，DB中主要存儲商品、店鋪之間的數(shù)據(jù)，業(yè)務(wù)變更主要基于mysql bin-log事件監(jiān)聽，變更之后做全量和增量。全量每天定時索引操作、增量會流到MQ，再通過業(yè)務(wù)拼裝推到線上。

搜索架構(gòu)的探索之演變歷程

蘑菇街搜索架構(gòu)主要經(jīng)歷導(dǎo)購時期（~2013.11）、電商初期（2013.11~2014.11）、Solr主搜（2015.4~2016.3）、C++主搜（2015.8~2016.11）、平臺化（2017.1~now）五大階段。

蘑菇街搜索架構(gòu)現(xiàn)狀簡化版

為了更清晰直觀進行對比，我把當(dāng)前搜索架構(gòu)簡化成如上圖所示的業(yè)務(wù)、投放、排序、召回、數(shù)據(jù)流五大層。接下來我們來看看，我們從最早期，都經(jīng)歷哪些演變，一步步走到現(xiàn)在。

蘑菇街搜索架構(gòu)導(dǎo)購時期架構(gòu)

如上圖，是~2013.11導(dǎo)購時期的架構(gòu)，有用到放在PHP代碼里的業(yè)務(wù)+投放、用Java搜索引擎Solr做的召回+排序和數(shù)據(jù)流三層。這個時期，排序需求不是很迫切，更多側(cè)重的是商品整體的豐富度和新穎度。簡單理解，熱銷排序等于喜歡乘10加上收藏乘50，基于Solr的改造來實現(xiàn)。

在電商轉(zhuǎn)型初期（2013.11~2014.11），由于賣自己的商品，流量變得更值錢了，工程師會想法設(shè)法去提升流量的效率。同時用戶行為也在增加，產(chǎn)生更多的數(shù)據(jù)。還有增量管理復(fù)雜，數(shù)據(jù)量大、Optimaize風(fēng)險大、導(dǎo)購、廣告和搭配等多類型商品透出等等。其中最明顯挑戰(zhàn)就是排序特征變多、數(shù)據(jù)變大、次數(shù)頻繁。

蘑菇街搜索架構(gòu)轉(zhuǎn)型初期架構(gòu)

面對這些挑戰(zhàn)，當(dāng)時的思路是把算法獨立成單獨Java工程做算分，但百萬商品百種排序，算法排序達G級別，這些排序數(shù)據(jù)需要作用于搜索引擎，快速生效，問題是用增量的方式會引來索引碎片的增加，會給線上引擎穩(wěn)定性帶來波動。故另辟蹊徑，用在Solr進程中設(shè)置堆外內(nèi)存來管理這部分排序數(shù)據(jù)。

總結(jié)來說，轉(zhuǎn)型初期整體的解決方案就是把算法獨立出來單獨去做，把部分分數(shù)盡快同步到引擎，進行生效。這樣的方法，當(dāng)時線上效果很顯著，但隨時間推移又有新問題出來：

規(guī)則排毒->LTR，算法排序需求多；
排序靈活性制約：計算好的分數(shù)離線推送到Solr；
Solr內(nèi)存壓力：GC/段合并；
靜態(tài)分，相關(guān)性差；
大促相關(guān)性問題：搜索“雨傘”，雨傘圖案的連衣裙會排在前面；

Solr主搜整體架構(gòu)

針對這些新問題，（2015.4）Solr主搜改造，支持Rank插件（Ranker->Scorer）,配置化+動態(tài)化，整體架構(gòu)如上圖。應(yīng)對相關(guān)性問題，新增QR系統(tǒng)、應(yīng)對內(nèi)存壓力，做Solr升級（Docvalues），算法分走動態(tài)字段增量，同時投放方式也漸漸形成Topn系統(tǒng)，對外對接不同的搜索場景。

Solr架構(gòu)解決相關(guān)性、算法變更線上排序等問題，但新問題在于雖用機器學(xué)習(xí)的排序做法，但那個時期主要是爆款模型，有很多個性化需求模型同時對不同人要有不同的排序結(jié)果，還有一些重排序或打散等更加復(fù)雜的需求。因Solr實現(xiàn)機制的限制，只能做一輪排序，想要改動比較難。另外，Solr整個索引結(jié)構(gòu)非常復(fù)雜，二次開發(fā)成本高，內(nèi)存、性能上也慢慢地暴露出很多問題，同時還有Java的GC也是不可逾越的鴻溝。

當(dāng)時多輪排序的需求，除了做一些文本相關(guān)性，還相對商品做品牌加權(quán)，如想扶持某些品牌、做類目打散等，這些在單輪排序內(nèi)做不到，原來的方式只能把多輪融合在一個排序中搞定，但效果會很差。

C++主搜架構(gòu)

如上圖，是C++主搜架構(gòu)（2015.8~2016.11）上線，在整個性能和排序方面做了定制，可支持多輪排序、整個內(nèi)存采用內(nèi)存方式，由排序體系支撐。這個階段整體來看，相對是完善的，每層，整個系統(tǒng)都成型，可數(shù)據(jù)流環(huán)節(jié)又出現(xiàn)了三個問題：

全量無調(diào)度，都要依靠流程制約
增量帶來算法分數(shù)不可比，會帶來一些線上排序的抖動
業(yè)務(wù)數(shù)據(jù)增量對服務(wù)接口壓力過大（促銷故障）

全量的整個鏈路

如上圖，是全量的整個鏈路，算法序列的整個鏈路靠時間約定，數(shù)據(jù)容災(zāi)機制弱。所以大促時，前置任務(wù)延遲全量做不了，線上內(nèi)存幾乎撐爆，經(jīng)常性全量延時，必須手動去處理。還有算法誤導(dǎo)排序分，導(dǎo)致線上錯亂，增量恢復(fù)時間長。

要解決這個問題，我們首要引入一個基于Zookeeper的調(diào)度系統(tǒng)，把整個數(shù)據(jù)流驅(qū)動起來同時支持錯誤報警。容災(zāi)部分的思路就是增加排序SOS字段、基于HBase定期生成全量快照，快速回檔、單算法字段修復(fù)等。

兩次算法增量分數(shù)不可比，增量生效特別慢。如時刻1算出商品是90分，時刻2是60分，就會引起線上排序抖動，主要因算法兩次序列導(dǎo)致整個數(shù)據(jù)分布不同，特別到大促時期，不同時段成交數(shù)據(jù)變化特別快，商品排序的波動非常明顯，增量數(shù)據(jù)同一批正常，但兩次見就會出錯。當(dāng)0點大家在瘋狂購物的時候，變更非常頻繁，會導(dǎo)致排序錯亂。算法數(shù)據(jù)出錯后，生效時間也會比較慢。

如上圖，我們的解決方案是通過小全量的方式把算法、分數(shù)單獨拖到線上引擎本地，在引擎本地依次一次加載，直接切換的方式，讓每一次算法增量數(shù)據(jù)的數(shù)據(jù)加速生效，容災(zāi)也會加快。

如上圖，由于變更都是Doc級更新，每一個字段更新都會調(diào)用所有的接口去拼裝成一條完整的數(shù)據(jù)去更新，這導(dǎo)致業(yè)務(wù)增量壓力特別大。大促期間，增量QPS可以達到幾千~上萬，對下游40多個接口的壓力非常大。

如上圖，這個問題解決的思路是讓引擎，包括數(shù)據(jù)流支持字段更新。只拼裝變更字段、不需要拼裝完整的數(shù)據(jù)，這需要引擎本身支持才能做到。當(dāng)時上線，收益非常明顯，關(guān)鍵接口QPS減少80%以上。

平臺化（2017.1~now）是現(xiàn)在正在做的事情。面對UPS、廣告、商品多套引擎系統(tǒng)與廣告、搜索多套投放系統(tǒng)分別從不同團隊合并過來，維護成本問題。排序計算需求變得更加復(fù)雜，嘗試用非線性模型等方面挑戰(zhàn)，就有了現(xiàn)在整理的架構(gòu)，思路就是平臺化、統(tǒng)一化，把重復(fù)的系統(tǒng)整合、數(shù)據(jù)流做統(tǒng)一。