做推薦模組的可以看看~內容來源：2017年4月8日，倪江利在“七牛架構師實踐日-大資料技術最佳實踐”進行《魅族推薦平臺架構》演講分享。IT大咖說作為獨家視訊合作方，經主辦方和講者審閱授權釋出。
閱讀字數：2889 | 5分鐘閱讀
摘要
魅族推薦平臺實現了在海量的資料中對演算法模型進行線上及離線訓練，在高併發的場景下實時進行預測為使用者推薦更感興趣的資訊。同時支撐多演算法組合A/B測試，以供演算法進行線上實驗，並能線上進行動態機器資源分配以達到資源的最大化利用。
嘉賓分享視訊地址：t.cn/R9AQnzV
推薦介紹
推薦能做什麼
推薦可以在合適的場景或時機，通過合適的渠道，把相關內容推薦給合適的使用者。
推薦的作用
推薦可以提升整體的系統目標，增加使用者粘性，提高使用者忠誠度，發現長尾。
推薦在魅族中的應用
推薦效果
與人工編輯相比，推薦的優勢非常明顯；而與行業內的一線公司相比，我們有超越他們的地方，也有還需要努力的部分。
魅族推薦平臺架構演進
推薦平臺需要做的事
- 平臺的核心需求：
- 技術難點：
- 針對於每一個使用者的一次推薦需要從萬級甚至是十萬級別以上的物品中進行挑選使用者可能感興趣的物品。
- 每一次推薦需要同時計算十個甚至是數十個演算法資料，一個演算法需要計算成百上千個維度。
- 一天需要實時處理上億條行為日誌，進行百億到千億次計算。
- 每天需要訪問資料儲存上十億次以上。
- 每天需要支撐上百個資料模型線上更新及實驗。
推薦平臺第一代架構——存在的問題
離線計算量大，需要將所有使用者的資料進行結果計算，同時浪費機器資源；
結果資料更新困難，大批量資料更新對資料庫衝擊大，可能直接造成使用者訪問超時，服務不可用；
資料更新延時大，超大資料量計算基本上只能實現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數；
支撐起百億條/每天的日誌進行實時計算，毫秒級別地進行使用者模型更新；
支撐更多的特徵集計算，同時線上計算響應時長更短；
支撐更多的魅族產品線業務；
推薦平臺對外開放，能為行業其它的企業提供專業的推薦服務；
深度學習整合。
今天的分享到此結束，謝謝大家！
