蘑菇街搜尋與推薦架構
轉載：https://blog.csdn.net/hu948162999/article/details/78862573
搜尋架構的探索之當前現狀
蘑菇街搜尋當前架構
如上圖，是蘑菇街當前搜尋架構，分為線上和離線兩部分。線上部分主要職責是處理線上的搜尋請求。離線部分的主要職責是處理資料流。
線上請求鏈路
如上圖，是整個線上請求鏈路，主要分為topn->qr->引擎->精排->透出五個環節。
第一步，請求首先進入topn系統，做ab配置/業務請求鏈路配置。
第二步，請求進入QR改寫系統做切詞，同義詞擴充套件，類目相關性，外掛化等。
第三步，進入UPS使用者個性化資料儲存系統。
第四步，投放層得到UPS和QR兩部分的資料後，放入搜尋引擎做召回。搜尋主要會經過一輪海選，海選的依據是文字相關性和商品質量，這樣做是為確保召回的商品質量大致可靠。之後會經過多輪初選，過程中會應用到更復雜的演算法模型，對海選的結果進行排序。搜尋引擎得到粗排的結果約千級別。
第五步，粗排結果進入到精排系統，精排系統主要通過演算法，做個性化排序、實時預測，精排和引擎類似，也支援多輪排序。經過精排系統之後，最終把結果透出給業務層。
蘑菇街統一引擎系統
如上圖，左側紅色框內是蘑菇街統一引擎系統，包含使用者個性化儲存系統、精排儲存、商品引擎、廣告引擎等。由於這樣的形式維護成本特別高，故做了右圖這個統一的Zindex核心架構。這個架構的最底層是共享記憶體分配器，再上層是可支援不同資料結構的各種引擎，再上層是索引管理。基於這個架構，不同的引擎可根據各自需求去建立自己的索引。
跟這個架構相關的，就是我們的運維平臺，是基於公司Docker虛擬化技術做的一個運維平臺，能夠非常快的支援索引建立，包括建立之後整個索引資料的管理。還有就是排序平臺，用來提供演算法配置變更服務。
搜尋架構離線部分的資料流程
如上圖，是離線的資料流程的情況，主要職責是資料流的處理，完整的索引資料分為演算法資料和業務資料。
演算法資料參與排序，整個鏈路從最前端ACM打點、再落到整個資料倉庫、經過清洗之後，在資料平臺上跑訓練指令碼，得出的特徵導到特徵平臺，再同步到線上。
業務資料的主要來源就是DB，DB中主要儲存商品、店鋪之間的資料，業務變更主要基於mysql bin-log事件監聽，變更之後做全量和增量。全量每天定時索引操作、增量會流到MQ，再通過業務拼裝推到線上。
搜尋架構的探索之演變歷程
蘑菇街搜尋架構主要經歷導購時期（~2013.11）、電商初期（2013.11~2014.11）、Solr主搜（2015.4~2016.3）、C++主搜（2015.8~2016.11）、平臺化（2017.1~now）五大階段。
蘑菇街搜尋架構現狀簡化版
為了更清晰直觀進行對比，我把當前搜尋架構簡化成如上圖所示的業務、投放、排序、召回、資料流五大層。接下來我們來看看，我們從最早期，都經歷哪些演變，一步步走到現在。
蘑菇街搜尋架構導購時期架構
如上圖，是~2013.11導購時期的架構，有用到放在PHP程式碼裡的業務+投放、用Java搜尋引擎Solr做的召回+排序和資料流三層。這個時期，排序需求不是很迫切，更多側重的是商品整體的豐富度和新穎度。簡單理解，熱銷排序等於喜歡乘10加上收藏乘50，基於Solr的改造來實現。
在電商轉型初期（2013.11~2014.11），由於賣自己的商品，流量變得更值錢了，工程師會想法設法去提升流量的效率。同時使用者行為也在增加，產生更多的資料。還有增量管理複雜，資料量大、Optimaize風險大、導購、廣告和搭配等多型別商品透出等等。其中最明顯挑戰就是排序特徵變多、資料變大、次數頻繁。
蘑菇街搜尋架構轉型初期架構
面對這些挑戰，當時的思路是把演算法獨立成單獨Java工程做算分，但百萬商品百種排序，演算法排序達G級別，這些排序資料需要作用於搜尋引擎，快速生效，問題是用增量的方式會引來索引碎片的增加，會給線上引擎穩定性帶來波動。故另闢蹊徑，用在Solr程序中設定堆外記憶體來管理這部分排序資料。
總結來說，轉型初期整體的解決方案就是把演算法獨立出來單獨去做，把部分分數儘快同步到引擎，進行生效。這樣的方法，當時線上效果很顯著，但隨時間推移又有新問題出來：
- 規則排毒->LTR，演算法排序需求多；
- 排序靈活性制約：計算好的分數離線推送到Solr；
- Solr記憶體壓力：GC/段合併；
- 靜態分，相關性差；
- 大促相關性問題：搜尋“雨傘”，雨傘圖案的連衣裙會排在前面；
Solr主搜整體架構
針對這些新問題，（2015.4）Solr主搜改造，支援Rank外掛（Ranker->Scorer）,配置化+動態化，整體架構如上圖。應對相關性問題，新增QR系統、應對記憶體壓力，做Solr升級（Docvalues），演算法分走動態欄位增量，同時投放方式也漸漸形成Topn系統，對外對接不同的搜尋場景。
Solr架構解決相關性、演算法變更線上排序等問題，但新問題在於雖用機器學習的排序做法，但那個時期主要是爆款模型，有很多個性化需求模型同時對不同人要有不同的排序結果，還有一些重排序或打散等更加複雜的需求。因Solr實現機制的限制，只能做一輪排序，想要改動比較難。另外，Solr整個索引結構非常複雜，二次開發成本高，記憶體、效能上也慢慢地暴露出很多問題，同時還有Java的GC也是不可逾越的鴻溝。
當時多輪排序的需求，除了做一些文字相關性，還相對商品做品牌加權，如想扶持某些品牌、做類目打散等，這些在單輪排序內做不到，原來的方式只能把多輪融合在一個排序中搞定，但效果會很差。
C++主搜架構
如上圖，是C++主搜架構（2015.8~2016.11）上線，在整個效能和排序方面做了定製，可支援多輪排序、整個記憶體採用記憶體方式，由排序體系支撐。這個階段整體來看，相對是完善的，每層，整個系統都成型，可資料流環節又出現了三個問題：
- 全量無排程，都要依靠流程制約
- 增量帶來演算法分數不可比，會帶來一些線上排序的抖動
- 業務資料增量對服務介面壓力過大（促銷故障）
全量的整個鏈路
如上圖，是全量的整個鏈路，演算法序列的整個鏈路靠時間約定，資料容災機制弱。所以大促時，前置任務延遲全量做不了，線上記憶體幾乎撐爆，經常性全量延時，必須手動去處理。還有演算法誤導排序分，導致線上錯亂，增量恢復時間長。
要解決這個問題，我們首要引入一個基於Zookeeper的排程系統，把整個資料流驅動起來同時支援錯誤報警。容災部分的思路就是增加排序SOS欄位、基於HBase定期生成全量快照，快速回檔、單演算法欄位修復等。
兩次演算法增量分數不可比，增量生效特別慢。如時刻1算出商品是90分，時刻2是60分，就會引起線上排序抖動，主要因演算法兩次序列導致整個資料分佈不同，特別到大促時期，不同時段成交資料變化特別快，商品排序的波動非常明顯，增量資料同一批正常，但兩次見就會出錯。當0點大家在瘋狂購物的時候，變更非常頻繁，會導致排序錯亂。演算法資料出錯後，生效時間也會比較慢。
如上圖，我們的解決方案是通過小全量的方式把演算法、分數單獨拖到線上引擎本地，在引擎本地依次一次載入，直接切換的方式，讓每一次演算法增量資料的資料加速生效，容災也會加快。
如上圖，由於變更都是Doc級更新，每一個欄位更新都會呼叫所有的介面去拼裝成一條完整的資料去更新，這導致業務增量壓力特別大。大促期間，增量QPS可以達到幾千~上萬，對下游40多個介面的壓力非常大。
如上圖，這個問題解決的思路是讓引擎，包括資料流支援欄位更新。只拼裝變更欄位、不需要拼裝完整的資料，這需要引擎本身支援才能做到。當時上線，收益非常明顯，關鍵介面QPS減少80%以上。
平臺化（2017.1~now）是現在正在做的事情。面對UPS、廣告、商品多套引擎系統與廣告、搜尋多套投放系統分別從不同團隊合併過來， 維護成本問題。排序計算需求變得更加複雜，嘗試用非線性模型等方面挑戰，就有了現在整理的架構，思路就是平臺化、統一化，把重複的系統整合、資料流做統一。
搜尋架構的探索之經驗總結
這一路走來，整個搜尋架構的探索經驗就是在發展前期要簡單快速支援線上業務，之後在逐步演變，來滿足演算法的需求，最後在考慮整個利用平臺化、統一化的思路去提升效率，降低成本。
不同階段要有不同的選擇，我們最早基於Solr改寫，待團隊、人員，包括技術儲備上也有實力後，直接重寫搜尋引擎，覆蓋演算法的離線、線上鏈路，做體系化建設。
我們的後續規劃是新架構整體平臺化繼續深入，演算法方面加強學習，如深度學習、線上學習等。如深度學習框架的研究和使用，以及圖搜工程體系的建設。
推薦架構的探索之發展概述
蘑菇街的推薦架構已經覆蓋大部分的使用者行為路徑，從使用進入APP，到下單成交完成都會有推薦場景出現。推薦架構的整個發展分為發展早期（2103.11~2015.6）、1.0時期：從0到1（2015.6~2016.3）、2.0：投放+個性化（2016.3~2016.12）、3.0：平臺化（2016.2~now）四大階段。
發展早期（2103.11~2015.6）推薦的場景並不多，需求也比較簡單，資料離線更新到Redis就好，當時明顯的問題是沒有專門的推薦系統來承載推薦場景、效果跟蹤差、場景對接、資料匯入等效率低等。
1.0時期的推薦架構
1.0時期：從0到1（2015.6~2016.3）把推薦系統搭建起來，包含Service層對接場景、推薦實時預測、自寫的K-V的系統用來儲存推薦結果。這裡踩的一個坑是，把實時預測做到離線部分，但其實實時預測更多的是線上流程。
隨著時間推移，場景型別（猜你喜歡、搜相似、店鋪內）、相似場景（首頁、購物車、詳情頁…）不斷增加，演算法方面需要實時排序，應對實時的點選、加購等，還有一些個性化排序需求，如店鋪、類目、離線偏好等。1.0階段主要面臨三大問題：
- 多型別多場景：上線系統不一，缺少統一對接層，成本高；
- 場景配置化：場景演算法一對一，重複程式碼拷貝，維護難；
- 個性化+實時：缺系統支援；
2.0時期的推薦架構
如上圖，2.0時期的推薦架構（2016.3~2016.12）主要解決1.0的三大問題，增加投放層Prism，統一對外對接不同的業務場景，對Prism做動態配置和規則模板。個性化實時方面增加UPS與精排系統。
2.0時期推薦架構投放層配置化
如上圖，2.0時期推薦架構投放層配置化思路是把不變的部分模板化，可變的部分配置化。系統提供召回組建、資料補全、格式化等模板。當時效果很明顯，321大促運營位置個性化效果提升20%+，雙11大促，會場樓層個性化提升100%+。
大促帶來的巨大收益，給整個系統帶來很正面的影響，後續推薦架構又面臨更多的需求與挑戰：
- 日益增長的資源位、直播、影象等場景和型別；
- 跟美的融合，跨團隊跨地域的挑戰；
- 工程演算法用一套程式碼，整個策略的開發除錯都非常複雜，包括工程部分的職責不清問題；
- 由於原來模板化的配置，導致一些簡單場景複雜化。
針對這些問題，我們需要做的事情就是通用化、平臺化。針對整套系統進行統一推薦方案，自動化整體演算法對接核心業務流程、以及和演算法人員的職責劃分清晰，提升雙方的工作效率。
3.0時期推薦架構
3.0時期推薦架構 （2016.2~now）與搜尋架構類似，系統間職能更加明晰，統一和平臺化，主要還是投放層做了改造。
3.0時期推薦架構投放層細節
如上圖， 3.0時期推薦架構投放層重要的概念就是場景化，場景應對推薦業務，不同場景會對應不同的策略實現。
轉載：https://blog.csdn.net/hu948162999/article/details/78862573
搜尋架構的探索之當前現狀
蘑菇街搜尋當前架構
如上圖，是蘑菇街當前搜尋架構，分為線上和離線兩部分。線上部分主要職責是處理線上的搜尋請求。離線部分的主要職責是處理資料流。
線上請求鏈路
如上圖，是整個線上請求鏈路，主要分為topn->qr->引擎->精排->透出五個環節。
第一步，請求首先進入topn系統，做ab配置/業務請求鏈路配置。
第二步，請求進入QR改寫系統做切詞，同義詞擴充套件，類目相關性，外掛化等。
第三步，進入UPS使用者個性化資料儲存系統。
第四步，投放層得到UPS和QR兩部分的資料後，放入搜尋引擎做召回。搜尋主要會經過一輪海選，海選的依據是文字相關性和商品質量，這樣做是為確保召回的商品質量大致可靠。之後會經過多輪初選，過程中會應用到更復雜的演算法模型，對海選的結果進行排序。搜尋引擎得到粗排的結果約千級別。
第五步，粗排結果進入到精排系統，精排系統主要通過演算法，做個性化排序、實時預測，精排和引擎類似，也支援多輪排序。經過精排系統之後，最終把結果透出給業務層。
蘑菇街統一引擎系統
如上圖，左側紅色框內是蘑菇街統一引擎系統，包含使用者個性化儲存系統、精排儲存、商品引擎、廣告引擎等。由於這樣的形式維護成本特別高，故做了右圖這個統一的Zindex核心架構。這個架構的最底層是共享記憶體分配器，再上層是可支援不同資料結構的各種引擎，再上層是索引管理。基於這個架構，不同的引擎可根據各自需求去建立自己的索引。
跟這個架構相關的，就是我們的運維平臺，是基於公司Docker虛擬化技術做的一個運維平臺，能夠非常快的支援索引建立，包括建立之後整個索引資料的管理。還有就是排序平臺，用來提供演算法配置變更服務。
搜尋架構離線部分的資料流程
如上圖，是離線的資料流程的情況，主要職責是資料流的處理，完整的索引資料分為演算法資料和業務資料。
演算法資料參與排序，整個鏈路從最前端ACM打點、再落到整個資料倉庫、經過清洗之後，在資料平臺上跑訓練指令碼，得出的特徵導到特徵平臺，再同步到線上。
業務資料的主要來源就是DB，DB中主要儲存商品、店鋪之間的資料，業務變更主要基於mysql bin-log事件監聽，變更之後做全量和增量。全量每天定時索引操作、增量會流到MQ，再通過業務拼裝推到線上。
搜尋架構的探索之演變歷程
蘑菇街搜尋架構主要經歷導購時期（~2013.11）、電商初期（2013.11~2014.11）、Solr主搜（2015.4~2016.3）、C++主搜（2015.8~2016.11）、平臺化（2017.1~now）五大階段。
蘑菇街搜尋架構現狀簡化版
為了更清晰直觀進行對比，我把當前搜尋架構簡化成如上圖所示的業務、投放、排序、召回、資料流五大層。接下來我們來看看，我們從最早期，都經歷哪些演變，一步步走到現在。
蘑菇街搜尋架構導購時期架構
如上圖，是~2013.11導購時期的架構，有用到放在PHP程式碼裡的業務+投放、用Java搜尋引擎Solr做的召回+排序和資料流三層。這個時期，排序需求不是很迫切，更多側重的是商品整體的豐富度和新穎度。簡單理解，熱銷排序等於喜歡乘10加上收藏乘50，基於Solr的改造來實現。
在電商轉型初期（2013.11~2014.11），由於賣自己的商品，流量變得更值錢了，工程師會想法設法去提升流量的效率。同時使用者行為也在增加，產生更多的資料。還有增量管理複雜，資料量大、Optimaize風險大、導購、廣告和搭配等多型別商品透出等等。其中最明顯挑戰就是排序特徵變多、資料變大、次數頻繁。
蘑菇街搜尋架構轉型初期架構
面對這些挑戰，當時的思路是把演算法獨立成單獨Java工程做算分，但百萬商品百種排序，演算法排序達G級別，這些排序資料需要作用於搜尋引擎，快速生效，問題是用增量的方式會引來索引碎片的增加，會給線上引擎穩定性帶來波動。故另闢蹊徑，用在Solr程序中設定堆外記憶體來管理這部分排序資料。
總結來說，轉型初期整體的解決方案就是把演算法獨立出來單獨去做，把部分分數儘快同步到引擎，進行生效。這樣的方法，當時線上效果很顯著，但隨時間推移又有新問題出來：
- 規則排毒->LTR，演算法排序需求多；
- 排序靈活性制約：計算好的分數離線推送到Solr；
- Solr記憶體壓力：GC/段合併；
- 靜態分，相關性差；
- 大促相關性問題：搜尋“雨傘”，雨傘圖案的連衣裙會排在前面；
Solr主搜整體架構
針對這些新問題，（2015.4）Solr主搜改造，支援Rank外掛（Ranker->Scorer）,配置化+動態化，整體架構如上圖。應對相關性問題，新增QR系統、應對記憶體壓力，做Solr升級（Docvalues），演算法分走動態欄位增量，同時投放方式也漸漸形成Topn系統，對外對接不同的搜尋場景。
Solr架構解決相關性、演算法變更線上排序等問題，但新問題在於雖用機器學習的排序做法，但那個時期主要是爆款模型，有很多個性化需求模型同時對不同人要有不同的排序結果，還有一些重排序或打散等更加複雜的需求。因Solr實現機制的限制，只能做一輪排序，想要改動比較難。另外，Solr整個索引結構非常複雜，二次開發成本高，記憶體、效能上也慢慢地暴露出很多問題，同時還有Java的GC也是不可逾越的鴻溝。
當時多輪排序的需求，除了做一些文字相關性，還相對商品做品牌加權，如想扶持某些品牌、做類目打散等，這些在單輪排序內做不到，原來的方式只能把多輪融合在一個排序中搞定，但效果會很差。
C++主搜架構
如上圖，是C++主搜架構（2015.8~2016.11）上線，在整個效能和排序方面做了定製，可支援多輪排序、整個記憶體採用記憶體方式，由排序體系支撐。這個階段整體來看，相對是完善的，每層，整個系統都成型，可資料流環節又出現了三個問題：
- 全量無排程，都要依靠流程制約
- 增量帶來演算法分數不可比，會帶來一些線上排序的抖動
- 業務資料增量對服務介面壓力過大（促銷故障）
全量的整個鏈路
如上圖，是全量的整個鏈路，演算法序列的整個鏈路靠時間約定，資料容災機制弱。所以大促時，前置任務延遲全量做不了，線上記憶體幾乎撐爆，經常性全量延時，必須手動去處理。還有演算法誤導排序分，導致線上錯亂，增量恢復時間長。
要解決這個問題，我們首要引入一個基於Zookeeper的排程系統，把整個資料流驅動起來同時支援錯誤報警。容災部分的思路就是增加排序SOS欄位、基於HBase定期生成全量快照，快速回檔、單演算法欄位修復等。
兩次演算法增量分數不可比，增量生效特別慢。如時刻1算出商品是90分，時刻2是60分，就會引起線上排序抖動，主要因演算法兩次序列導致整個資料分佈不同，特別到大促時期，不同時段成交資料變化特別快，商品排序的波動非常明顯，增量資料同一批正常，但兩次見就會出錯。當0點大家在瘋狂購物的時候，變更非常頻繁，會導致排序錯亂。演算法資料出錯後，生效時間也會比較慢。
如上圖，我們的解決方案是通過小全量的方式把演算法、分數單獨拖到線上引擎本地，在引擎本地依次一次載入，直接切換的方式，讓每一次演算法增量資料的資料加速生效，容災也會加快。
如上圖，由於變更都是Doc級更新，每一個欄位更新都會呼叫所有的介面去拼裝成一條完整的資料去更新，這導致業務增量壓力特別大。大促期間，增量QPS可以達到幾千~上萬，對下游40多個介面的壓力非常大。
如上圖，這個問題解決的思路是讓引擎，包括資料流支援欄位更新。只拼裝變更欄位、不需要拼裝完整的資料，這需要引擎本身支援才能做到。當時上線，收益非常明顯，關鍵介面QPS減少80%以上。
平臺化（2017.1~now）是現在正在做的事情。面對UPS、廣告、商品多套引擎系統與廣告、搜尋多套投放系統分別從不同團隊合併過來， 維護成本問題。排序計算需求變得更加複雜，嘗試用非線性模型等方面挑戰，就有了現在整理的架構，思路就是平臺化、統一化，把重複的系統整合、資料流做統一。
搜尋架構的探索之經驗總結
這一路走來，整個搜尋架構的探索經驗就是在發展前期要簡單快速支援線上業務，之後在逐步演變，來滿足演算法的需求，最後在考慮整個利用平臺化、統一化的思路去提升效率，降低成本。
不同階段要有不同的選擇，我們最早基於Solr改寫，待團隊、人員，包括技術儲備上也有實力後，直接重寫搜尋引擎，覆蓋演算法的離線、線上鏈路，做體系化建設。
我們的後續規劃是新架構整體平臺化繼續深入，演算法方面加強學習，如深度學習、線上學習等。如深度學習框架的研究和使用，以及圖搜工程體系的建設。
推薦架構的探索之發展概述
蘑菇街的推薦架構已經覆蓋大部分的使用者行為路徑，從使用進入APP，到下單成交完成都會有推薦場景出現。推薦架構的整個發展分為發展早期（2103.11~2015.6）、1.0時期：從0到1（2015.6~2016.3）、2.0：投放+個性化（2016.3~2016.12）、3.0：平臺化（2016.2~now）四大階段。
發展早期（2103.11~2015.6）推薦的場景並不多，需求也比較簡單，資料離線更新到Redis就好，當時明顯的問題是沒有專門的推薦系統來承載推薦場景、效果跟蹤差、場景對接、資料匯入等效率低等。
1.0時期的推薦架構
1.0時期：從0到1（2015.6~2016.3）把推薦系統搭建起來，包含Service層對接場景、推薦實時預測、自寫的K-V的系統用來儲存推薦結果。這裡踩的一個坑是，把實時預測做到離線部分，但其實實時預測更多的是線上流程。
隨著時間推移，場景型別（猜你喜歡、搜相似、店鋪內）、相似場景（首頁、購物車、詳情頁…）不斷增加，演算法方面需要實時排序，應對實時的點選、加購等，還有一些個性化排序需求，如店鋪、類目、離線偏好等。1.0階段主要面臨三大問題：
- 多型別多場景：上線系統不一，缺少統一對接層，成本高；
- 場景配置化：場景演算法一對一，重複程式碼拷貝，維護難；
- 個性化+實時：缺系統支援；
2.0時期的推薦架構
如上圖，2.0時期的推薦架構（2016.3~2016.12）主要解決1.0的三大問題，增加投放層Prism，統一對外對接不同的業務場景，對Prism做動態配置和規則模板。個性化實時方面增加UPS與精排系統。
2.0時期推薦架構投放層配置化
如上圖，2.0時期推薦架構投放層配置化思路是把不變的部分模板化，可變的部分配置化。系統提供召回組建、資料補全、格式化等模板。當時效果很明顯，321大促運營位置個性化效果提升20%+，雙11大促，會場樓層個性化提升100%+。
大促帶來的巨大收益，給整個系統帶來很正面的影響，後續推薦架構又面臨更多的需求與挑戰：
- 日益增長的資源位、直播、影象等場景和型別；
- 跟美的融合，跨團隊跨地域的挑戰；
- 工程演算法用一套程式碼，整個策略的開發除錯都非常複雜，包括工程部分的職責不清問題；
- 由於原來模板化的配置，導致一些簡單場景複雜化。
針對這些問題，我們需要做的事情就是通用化、平臺化。針對整套系統進行統一推薦方案，自動化整體演算法對接核心業務流程、以及和演算法人員的職責劃分清晰，提升雙方的工作效率。
3.0時期推薦架構
3.0時期推薦架構 （2016.2~now）與搜尋架構類似，系統間職能更加明晰，統一和平臺化，主要還是投放層做了改造。
3.0時期推薦架構投放層細節
如上圖， 3.0時期推薦架構投放層重要的概念就是場景化，場景應對推薦業務，不同場景會對應不同的策略實現。