推荐系统的架构图
推薦系統的架構
????? 本文從互聯網收集并整理了推薦系統的架構，其中包括一些大公司的推薦系統框架（數據流存儲、計算、模型應用），可以參考這些資料，取長補短，最后根據自己的業務需求，技術選型來設計相應的框架。后續持續更新并收集。。。
? ? ? 圖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產生事件跟行為，然后分發給離線（我理解的是按天存儲）、近線存儲（不提供歷史，存儲當天用戶實時行為。不知道理解是否有誤），離線的計算利用離線的數據建好模型供實時調用，近線的計算利用用戶的實時行為計算得出規則供實時調用，最后在線的計算通過前兩種方式來得到最終的推薦結果，關鍵問題，就是如何以無縫方式結合、管理在線和離線計算過程，當然找到這些要求之間恰當的平衡并不容易，需要深思熟慮的需求分析，細心的技術選擇，戰略性的推薦算法分解，最終才能為客戶達成最佳的結果。
?
?優酷的推薦系統
? ?下圖來自優酷數據挖掘工程師分享的內容要點：
? ?
?
模型前數據準備(理解數據源，用戶，物品)
?
模型策略
其他考慮的場景
總結
- 上一篇： oracle varchar2转date
- 下一篇： 内存检测_Android native内