魅族推薦平臺架構

作推薦模塊的能夠看看~ 內容來源： 2017年4月8日，倪江利在「七牛架構師實踐日-大數據技術最佳實踐」進行《魅族推薦平臺架構》演講分享。IT大咖說做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：2889 | 5分鐘閱讀

摘要

魅族推薦平臺實現了在海量的數據中對算法模型進行在線及離線訓練，在高併發的場景下實時進行預測爲用戶推薦更感興趣的信息。同時支撐多算法組合A/B測試，以供算法進行在線實驗，並能在線進行動態機器資源分配以達到資源的最大化利用。

嘉賓分享視頻地址：t.cn/R9AQnzV

推薦介紹

推薦能作什麼

推薦能夠在合適的場景或時機，經過合適的渠道，把相關內容推薦給合適的用戶。

推薦的做用

推薦能夠提高總體的系統目標，增長用戶粘性，提升用戶忠誠度，發現長尾。

推薦在魅族中的應用

推薦效果

與人工編輯相比，推薦的優點很是明顯；而與行業內的一線公司相比，咱們有超越他們的地方，也有還須要努力的部分。

魅族推薦平臺架構演進

推薦平臺須要作的事

• 平臺的核心需求：
  

支撐5個以上的大產品線的不一樣場景的推薦業務需求，保證業務穩定運行，可用性達到99.9%，推薦場景當次請求響應在100毫秒之內，一天須要支撐億級別的PV量。

• 技術難點：
  

1. 針對於每個用戶的一次推薦須要從萬級甚至是十萬級別以上的物品中進行挑選用戶可能感興趣的物品。
   
2. 每一次推薦須要同時計算十個甚至是數十個算法數據，一個算法須要計算成百上千個維度。
   
3. 一天須要實時處理上億條行爲日誌，進行百億到千億次計算。
   
4. 天天須要訪問數據存儲上十億次以上。
   
5. 天天須要支撐上百個數據模型在線更新及實驗。
   

推薦平臺第一代架構——存在的問題

離線計算量大，須要將全部用戶的數據進行結果計算，同時浪費機器資源；

結果數據更新困難，大批量數據更新對數據庫衝擊大，可能直接形成用戶訪問超時，服務不可用；

數據更新延時大，超大數據量計算基本上只能實現T+1的方式進行數據更新，因此數據推薦都是基於舊行爲數據進行預測；

數據庫的瓶頸直接影響算法結果數據輸出頻率，算法調優困難；

擴展困難，全部結果數據已經固定輸出，很難插入一些業務上特定的需求。

推薦平臺第二代架構——優點

用戶推薦數據實時根據用戶請求進行計算，減小離線計算量及減小數據存儲空間；

原始模型的輸出到線上比起結果數據輸出更輕便，對線上性能影響更小，更方便於算法在線調優；

模塊分離，業務各性化處理與模型計算分離，系統更抽象化，可複用度越高，可擴展性越好。

推薦平臺第二代架構——存在的問題

模型離線訓練，用戶實時產生的行爲沒法反饋到模型當中；

業務混布，各業務之間相互影響；

因爲把離線的部分計算放到線上進行計算，在請求過程當中計算量增大，系統相應時長挑戰增大；

業務接入越多，模型會愈來愈多，單臺機器已經沒法裝載全部的模型。

魅族推薦平臺現狀

三代架構的核心需求

集羣資源動態管理，解決模型存儲及計算資源利用率問題；

用戶行爲數據可以實時的進行計算，並最終反饋到模型，提升推薦結果的準確性；

優法算法模型訓練過程，將大部分工做能經過可視化的方式完成，提升工做效率；

解決業務之間的互相影響，優化高效的性能及穩定性。

推薦平臺架構分層

推薦系統被分爲三層。

Offline運算層：該層主要是離線對海量的數據進行建模加工，生產有價值的數據，如Item類似庫、user相關庫、CF離線推薦結果等。

Nearline運算層：該層主要是利用流式處理的技術對用戶實時產生的行爲日誌進行加工，利用一些高效、高性能的算法生產有價值的數據。

Online運算層：該層主要處理一些相對簡單的運算邏輯，在線進行計算。

在線模塊——OpenAPI

統一接入規範：全部應用接入按照統一規範進行接入，全部提供出去的接口模式統一，這樣大大下降接入方的難度。

路由：根據用戶標識、版本、服務器IP以及權重規則路由到不一樣的Online計算插件服務。這樣一來能夠實現流量分流、A/B Test、灰度發佈的目的、接口代理。

接入權限管理：統一管理接口調用權限。

統一監控：統一進行業務設用監控，如業務調用量、QPS、響應時長、業務設用失敗告警等。

A/B測試模塊

在推薦平臺中最重要的一個功能就是A/B測試，A/B測試主要是對用戶進行抽樣分流道不一樣的算法組合當中，最後經過評估數據來驅動算法工程師對算法效果不斷的進行調優。

A/B測試效果評估過程

用戶請求數據後，APP端及Web端對用戶看到的推薦數據所產生的一系列行爲進行上報，數據採集服務端對日誌數據進行收集並經過流平臺將數據進行歸併，同時對部分的實時數據進行在線統計分析，最終產生效果評估數據。

在線模塊——計算模塊

業務策略計算主要是處理業務相關的一些排序、過濾、人工干預競價排名等與具體業務相關的邏輯，不一樣的業務各性化需求採用插件化的方式進行接入。

初始化模塊主要處理算法模型的管理（模型加載、卸載，存儲等等）、模型計算。

推薦通常性的數據處理過程從召回階段到預測再到業務重排階段，數據量依次減小。

精選階段的數據是來源於召回的數據，有可能同時存在幾個或者十幾個召回算法，對不一樣召回的數據及相關的資源可能存儲在不一樣的機器上或數據庫中，因此請求接收點結在接收請求後，須要根據配置將不一樣的處理請求分發到不一樣的機器上進行計算，而後再歸併返回。

近線模塊

該層主要是利用流式處理的技術對用戶實時產生的行爲日誌進行加工，利用一些高效、高性能的算法生產有價值的數據，如處理算法數據召回、實時數據統計等等。

資源管理調度

機器動態劃分分組，能夠按業務進行劃分，也能夠按照模型資源狀況進行劃分。

解決業務之間相互影響，按照業務對性能的要求及複雜度分配不一樣的硬件機器。同時可以整合資源，不一樣大小的配置均可以在集羣中獲得應用。

解決內存模型存儲限制問題，將模型分散到不一樣的集羣中進行橫向擴展。

在請求過程當中，請求根據master進行動態調度，大型資源加載過程當中機器請求自動調度到其它機器，解決大型資源加載過程當中對業務的影響。

在線模塊——存儲

在存儲上多樣性，不一樣類型的組合使用，根據不一樣的場景與性能指標採用不一樣的存儲組合。

LocalCache：通常用來處理一次請求中訪問數據頻次超高但數據容量不須要太大的數據，如LR模型數據。

Mysql、Hbase、Redis：這三種存儲的選擇通常從性能和各自的特性出發點來選擇是最合適的，各自都是集羣的方式，Mysql能夠按業務數據進行拆分紅不一樣的集羣進行訪問。

離線——機器學習平臺

提供特徵工程、統計、訓練、評估、預測和模型發佈等功能，覆蓋機器學習全流程，能夠經過拖拽的方式完成模型訓練和評估。

模型訓練及評估界面化，與調度平臺無縫集成，使得算法離線模型處理及模型發佈上線等更加高效簡單。

系統集成多種算法可進行邏輯迴歸LR、聚類Kmeans、模型LDA、協同過濾CF等多種模型訓練。

進行分佈式數據處理與計算。

監控告警

細粒度性能監控，能夠細粒度到具體的業務請求接口，從業務QPS、PV量、響應時長等等；

應用服務器及操做系統各項指標監控；

業務指標監控，如算法效果及其它業務指標監控；

監控指標可根據具體的需求擴展。

魅族推薦平臺挑戰和願景

挑戰10億/天天以上在線實時計算請求PV數；

支撐起百億條/天天的日誌進行實時計算，毫秒級別地進行用戶模型更新；

支撐更多的特徵集計算，同時在線計算響應時長更短；

支撐更多的魅族產品線業務；

推薦平臺對外開放，能爲行業其它的企業提供專業的推薦服務；

深度學習集成。

今天的分享到此結束，謝謝你們！

推薦文章

• TiDB 原理與實戰｜架構師實踐日
  

• Mars在移動網絡的探索和實踐