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

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

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

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

1. 平臺的核心需求

支撐5個以上大產品線在不同場景下推薦業務的需求； 保證業務穩定執行，可用性達到99.9%； 推薦場景當次請求響應在200毫秒以內； 廣告預測場景當次請求響應在100毫秒以內； 一天需要支撐億級別的PV量。 2. 技術難點：

針對於每一個使用者的一次推薦需要從萬級甚至是十萬級別以上的物品中進行挑選使用者可能感興趣的物品； 每一次推薦需要同時計算十個甚至是數十個演算法資料，一個演算法需要計算成百上千個維度； 一天需要實時處理上億條行為日誌，進行百億到千億次計算； 每天需要訪問資料儲存上十億次； 每天需要支撐上百個資料模型線上更新及實驗。 三、魅族推薦平臺架構的演變過程

3.1 第一代架構

上圖展示的是我們的第一代架構，在這個圖裡可以看到整個過程比較簡單，可以通過這個一線模型計算，計算以後整個使用者的資料通過這個模型直接寫到庫裡。

第一代架構存在的問題

這個架構能夠滿足網站使用者訪問量在幾十萬或者幾百萬規模的資料處理需求。但是當使用者訪問量呈現大規模增長，問題就暴露出來了。

離線計算量大，需要將所有使用者的資料進行結果計算,同時浪費機器資源； 結果資料更新困難，大批量資料更新對資料庫的衝擊大，可能直接造成使用者訪問超時,服務不可用； 資料更新延時大，超大資料量計算基本上只能實現T+1的方式進行資料更新，所以資料推薦都是基於舊行為資料進行預測； 資料庫的瓶頸直接影響演算法結果資料輸出頻率，演算法調優困難； 擴充套件困難，所有結果資料已經固定輸出，很難插入一些業務上特定的需求。

3.2 第二代架構

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

整個架構分為兩層：

第一層是離線，離線是處理大批量的模型計算，根據離線日誌，計算只會產生資料演算法的模型。也就是說這個計算只產生了資料模型，而不會計算所有使用者並推薦內容，所以比實際推薦結果要小很多，可能只有幾百兆或幾個G的內容，儲存量減少。 第二層是線上，我們把線上模組切割成3個板塊：OpenAPI、業務策略計算、實際模型計算。

針對於模型計算板塊這個架構的有很多優勢。因為從這一代開始變成實時計算，都是基於模型實時線上計算出來，原始的模型推薦的實際資料處理起來方便很多，難度也會減少。

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

使用者推薦資料實時根據使用者請求進行計算，減少離線計算量及減少資料儲存空間； 模組分離，業務各性化處理與模型計算分離，系統更抽像化，可複用度越高及可擴充套件性越好； 原始模型的輸出到線上比起結果資料輸出更輕便，對線上效能影響更小，更方便於演算法線上調優。 當然也還是存在一些問題：

模型離線訓練，使用者實時產生的行為無法反饋到模型當中，可能造成推薦結果資料的延遲； 業務混布，各業務之間相互影響； 由於把離線的部分計算放到線上進行計算，在請求過程中計算量增大，系統響應時長挑戰增大； 業務接入越多，模型會越來越多，單臺機器已經無法裝載所有的模型。

二、魅族推薦平臺現狀

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

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

叢集資源動態管理，解決模型儲存及計算資源利用率的問題 使用者行為資料能夠實時的進行計算，並最終反饋到模型，提高推薦結果的準確性 優法演算法模型訓練過程，將大部分工作能通過視覺化的方式完成，提高工作效率 解決業務之間的相互影響 優化高效的效能及穩定性

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

3、 推薦平臺現有架構

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

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…）等； 應用伺服器及作業系統各指標監控； 業務指標監控，如演算法效果及其它業務指標監控； 監控指標可根據具體的需求擴充套件。

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

挑戰10億/每天以上線上實時計算請求PV數； 支撐起百億條/每天的日誌進行實時計算，毫秒級別的進行使用者模型更新； 支撐更多的特徵集計算，同時線上計算響應時長更加的短； 支撐更多的魅族產品線業務； 推薦平臺對外開放，能為行業其它的企業提供專業的推薦服務； 深度學習整合。

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