推薦系統的架構

  本文從互聯網收集並整理了推薦系統的架構，其中包括一些大公司的推薦系統框架（數據流存儲、計算、模型應用），能夠參考這些資料，取長補短，最後根據本身的業務需求，技術選型來設計相應的框架。後續持續更新並收集。。。

      圖1

       界面UI那一塊包含3塊東西：1) 經過必定方式展現推薦物品(物品標題、縮略圖、簡介等)；2) 給的推薦理由；3) 數據反饋改進個性化推薦；關於用戶數據的存放地方：1)數據庫/緩存用來實時取數據；2) hdfs文件上面；

      抽象出來的三種推薦方式

 

 

 

  圖2        

 

 

  圖3

       圖3中，推薦引擎的構建來源於不一樣的數據源(也就是用戶的特徵有不少種類，例如統計的、行爲的、主題的)+不一樣的推薦模型算法，推薦引擎的架構能夠試多樣化的(實時推薦的+離線推薦的)，而後融合推薦結果（人工規則+模型結果），融合方式多樣的，有線性加權的或者切換式的等

  圖4

       圖4中，A模塊負責用戶各種型特徵的收集，B模塊的相關表是根據圖3中的推薦引擎來生成的，B模塊的輸出推薦結果用來C模塊的輸入，中間通過過濾模塊(用戶已經產生行爲的物品，非候選物品，業務方提供的物品黑名單等)，排名模塊也根據預設定的推薦目標來制定，最後推薦解釋的生成（這是多是最容易忽視，但很關鍵的一環，微信的好友推薦遊戲，這一解釋已經賽過後臺的算法做用了）

       HULU的推薦系統

      

       總結：這個也就跟圖3有點相似了，葫蘆的推薦系統，至少在他blog中寫的比較簡單。更多的是對推薦系統在線部分的一種描述，離線部分我猜測也是經過分佈式計算或者不一樣的計算方式將算法產生的數據存儲進入一種介質中，供推薦系統在線部分調用。系統的整個流程是這樣的，首先獲取用戶的行爲，包括(watch、subscribe、vote)，這樣行爲會到後臺獲取show-show對應的推薦數據。同時這些行爲也會產生對應的topic，系統也會根據topic到後臺獲取topic-show對應的推薦數據。兩種數據進行混合，而後通過fliter、explanation、ranking這一系列過程，最後生成用戶看到的推薦數據。

 

     淘寶的推薦系統(詳細跟簡單版)

 

       總結：淘寶的推薦系統，描述了推薦引擎搭建的總體架構，包括離線的分佈式計算和存儲、監控、數據統計和分析、實驗平臺等。給咱們搭建推薦引擎提供了很好的建議。總體流程大體這樣。經過後臺的分佈式計算，將算法產生的算法結果數據存儲進入一種介質中，首推hbase。而後，經過一種叫作雲梯的機制將算法結果推入中間層介質中，供推薦系統在線部分調用。在線部分提供引擎和實驗分流，用戶的行爲將存儲進入hadoop中，數據統計分析平臺由hive來搭建，主要用來分析和統計hadoop中的用戶行爲log。這張圖不只講了，推薦系統的架構流程，也講了跟這個平臺有關係的人，是怎麼介入的，我以爲提供的信息可很好的參考。

 

    Netflix的推薦系統

       總結：netflix的推薦系統，描述了推薦引擎搭建的總體架構，採用了三種計算方式的結合。總體流程：用戶經過UI產生事件跟行爲，而後分發給離線（我理解的是按天存儲）、近線存儲（不提供歷史，存儲當天用戶實時行爲。不知道理解是否有誤），離線的計算利用離線的數據建好模型供實時調用，近線的計算利用用戶的實時行爲計算得出規則供實時調用，最後在線的計算經過前兩種方式來獲得最終的推薦結果，關鍵問題，就是如何以無縫方式結合、管理在線和離線計算過程，固然找到這些要求之間恰當的平衡並不容易，須要深思熟慮的需求分析，細心的技術選擇，戰略性的推薦算法分解，最終才能爲客戶達成最佳的結果。

 

  優酷 的推薦系統

       備註：上圖來至easyhadoop舉辦的技術沙龍中優酷數據挖掘工程師的演講，有關詳細信息請移步 http://virtual.51cto.com/exp/Hadoop_20130330/index.html#top。做者在演講中講的 一些 "乾貨"跟推薦議題是頗有價值的，下圖簡單描述。

模型前數據準備(理解數據源，用戶，物品)

 

模型策略

其餘考慮的場景

參考資料：推薦系統實踐，互聯網資料