倪江利：魅族推薦平臺的架構演進之路

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

魅族整個產品線都有用到推薦，包括資訊、視頻、應用中心、個性化中心、廣告等業務，魅族的推薦平臺在其中起到了關鍵的做用，下文將會全面分析從開始到如今的架構演進，以及其中涉及的技術難點分析，以期給讀者帶來更多的思考。

1、魅族推薦平臺架構演進

1. 平臺的核心需求

• 支撐5個以上大產品線在不一樣場景下推薦業務的需求；

• 保證業務穩定運行，可用性達到99.9%；

• 推薦場景當次請求響應在200毫秒之內；

• 廣告預測場景當次請求響應在100毫秒之內；

• 一天須要支撐億級別的PV量。

2. 技術難點：

• 針對於每個用戶的一次推薦須要從萬級甚至是十萬級別以上的物品中進行挑選用戶可能感興趣的物品；

• 每一次推薦須要同時計算十個甚至是數十個算法數據，一個算法須要計算成百上千個維度；

• 一天須要實時處理上億條行爲日誌，進行百億到千億次計算；

• 天天須要訪問數據存儲上十億次；

• 天天須要支撐上百個數據模型在線更新及實驗。

3、魅族推薦平臺架構的演變過程

3.1 第一代架構

上圖展現的是咱們的第一代架構，在這個圖裏能夠看到整個過程比較簡單，能夠經過這個一線模型計算，計算之後整個用戶的數據經過這個模型直接寫到庫裏。

第一代架構存在的問題

這個架構可以知足網站用戶訪問量在幾十萬或者幾百萬規模的數據處理需求。可是當用戶訪問量呈現大規模增加，問題就暴露出來了。

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

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

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

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

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

3.2 第二代架構

從圖中能夠看到，第二代架構開始有了清晰的分層。

整個架構分爲兩層：

第一層是離線，離線是處理大批量的模型計算，根據離線日誌，計算只會產生數據算法的模型。也就是說這個計算只產生了數據模型，而不會計算全部用戶並推薦內容，因此比實際推薦結果要小不少，可能只有幾百兆或幾個G的內容，存儲量減小。
第二層是在線，咱們把在線模塊切割成3個板塊：OpenAPI、業務策略計算、實際模型計算。

針對於模型計算板塊這個架構的有不少優點。由於從這一代開始變成實時計算，都是基於模型實時在線計算出來，原始的模型推薦的實際數據處理起來方便不少，難度也會減小。

總結起來第二代架構的優點有：

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

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

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

固然也仍是存在一些問題：

• 模型離線訓練，用戶實時產生的行爲沒法反饋到模型當中，可能形成推薦結果數據的延遲；

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

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

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

2、魅族推薦平臺現狀

1. 第三代架構的核心需求

爲了解決上述問題，咱們對魅族推薦平臺架構進行了優化。根據業務須要以及對一二代架構優缺點的總結，咱們首先肯定了第三代架構的核心需求：

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

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

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

• 解決業務之間的相互影響

• 優化高效的性能及穩定性

二、推薦平臺數據處理模型

上圖是推薦平臺數據處理的模型，咱們把整個流程切割成幾塊，離線、近線、在線部分，不一樣的階段處理不一樣的事情，處理數據量級別及複雜度也在各階段不斷的減小.

三、 推薦平臺現有架構

上圖是推薦平臺現有架構圖，咱們有一些資源管理和在線計算，還有機器學習平臺解決離線計算的問題。

3.1 推薦平臺架構分層

看架構主要看裏面的層次。魅族推薦平臺現有架構分爲三層：

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

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

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

3.2 推薦架構各模塊的實現原理

3.2.1 在線模塊-OpenAPI

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

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

第三，接入權限管理
統一管理接口調用權限。

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

3.2.2 A/B測試模塊

在推薦平臺中最重要的一個功能就是A/B測試，A/B測試主要是對用戶進行抽樣分流到不一樣的算法組合當中，最後經過評估數據來驅動算法工程師對算法效果不斷的進行調優。它的好壞直接決定了算法以及對模型優化的難度。

在作A/B測試的時候咱們會經過必定的抽樣方式選取目標人羣，根據必定的規則作配置，讓他們訪問不一樣的算法組合，咱們再根據不一樣的組合作評估，上圖中我只寫了一個轉化率，真正的評估數據不僅這些。

3.2.3 A/B測試效果評估過程：

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

上圖是截取的一個A/B測試效果評估圖。真正的效果評估也不僅這些，每一組業務場景的效果評估都是不同的。

3.2.4 在線模塊-計算模塊

計算模塊分爲兩大塊：

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

第二大塊是初始化模塊，主要是對物品進行精選相關的計算，同時管理對新的算法的支持及模型的存儲。

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

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

3.2.5 近線模塊

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

如圖，近線模塊-流式日誌數據傳輸分爲如下幾個部分：

• 數據經過Uxip從移動端、Web端進行收集；

• 收集後的數據經過Agent轉發到Flume進行專線或公網等網絡傳輸；

• 在中心機房的Flume將日誌數據等進行歸併傳輸到MetaMq；

• 基於MQ消息能夠對數據進行流式處理如實時計算、數據落地等等。

3.2.6 資源調度管理

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

資源調度管理的做用在於：

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

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

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

3.2.7 在線模塊-存儲

在存儲上實現多樣性，根據不一樣的場景與性能指標採用不一樣類型的存儲組合，實現業務隔離，根據模型的存儲狀況劃分結果，實時調動管理全部分配數據。

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

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

3.2.8 離線-機器學習平臺

咱們的離線-機器學習平臺能夠呀提供特徵工程、統計、訓練、評估、預測和模型發佈等功能，覆蓋機器學習全流程，算法同窗能夠經過拖拽的方式就能完成模型訓練和評估。

其優點在於：

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

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

• 分佈式數據處理與計算。

3.2.9 監控告警

整個模型和訓練的過程都是處於離線和分佈式環境下，監控在整個系統中必不可少。咱們的監控告警系統的特色是：

• 細粒度性能監控，能夠細粒度到具體的業務請求接口，從業務QPS、PV量、響應時長（P50.P70,P99,P999…）等；

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

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

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

3、魅族推薦平臺挑戰和願景

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

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

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

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

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

• 深度學習集成。

本文來自由魅族和麥思博（msup）聯合主辦的魅族技術開放日第七期——數據探索，邀請了騰訊、華爲等企業的4位技術專家，深刻剖析了企業如何利用數據以及將數據轉化爲有價值的信息。