京東個性化推薦系統實戰（下）

        推薦系統架構，推薦系統由品類平臺，素材、特徵召回平臺、模型計算打分服務，排序服務構成。

       將請求封裝成QueryInfo對象，經過對象來向下完成一步步數據召回。首先是經過QueryInfo對象召回品類、分類信息。

       前邊有人問到是怎樣實現通用化？好問題，當時答得不太好，如今梳理總結一下，分類平臺經過配置品類、分類信息，

配置選取個數、配置過濾品類信息，經過每一種配置狀況構建分類信息，分類信息徹底由配置文件構成。

 

       召回品類擴展QueryInfo對象構成QueryInfoExtern對象，爲下一步進行素材、特徵召回作準備，由於品類、分類數據量

少，傳輸時不會由於數據量消耗太多時間，而素材、特徵召回量極大，可經過分佈式形式將素材進行召回，此時召回量最大

可知足線上服務要求，召回以後，每組分別進行打分計算，打分以後進行取前邊數據進行返回。

       再由品類召回節點合併將高分素材進行返回，熟悉ElasticSearch同窗，會發現和ElasticSearch集羣架構很像，其實推

薦自己和搜索就有不少類似之處，研究搜索引擎對於推薦引擎構建也會大有益處。

 

       數據返回以前由排序服務對數據按展現效果進行商品按照品類、分類進行分隔，文章內容按標籤、主題進行分隔。分隔

目的是爲了好的展現效果，提高用戶體驗，經過上面這一系列過程構建成推薦系統大體過程。

 

       除了上邊架構邏輯，還存在存儲以及數據流轉體系。分類、素材、特徵存儲在redis、HBase中供服務讀取使用。

       對於實時反饋，用戶點擊、瀏覽會經過存儲在redis中用於過濾，以及調整後續推薦分類、素材權重，已做爲一種最實時

反饋手段。

       

 

       上報特徵自己經過JDQ消息隊列進行上報，上報異步進行，經過先寫日誌文件再上報日誌文件內容，來達到異步上報，

以免同步上報致使線上服務性能受影響。JDQ自己基於開源kafka打造。

       JDQ自己爲了資源狀況限制上報速度爲5M/s,爲了更好利用上報機器資源，會構建內存隊列，充分利用內存資源來控制發

送速度，而不是一味經過擴容來解決問題。

 

       日誌白名單自己按照服務、屬性、關鍵字進行存儲，在ElasticSearch中可方便按屬性、關鍵詞檢索使用，經過圖形化界

面展現，方便快速定位線上問題。

       監控自己除了Ump對系統功能、性能、可用性進行監控，引擎自己就要配備全面監控避免程序某個分支存在問題，致使

線上服務正確性、可用性存在問題，再有由於程序不少由配置文件動態構成，性能也要進行全面監控。

 

       對於線上效果，線上模型與分支進行綁定，當分支A效果實時效果好於B效果，要將線上模型進行更新調整，監控時間

以幾個小時效果爲準。線上效果也要進行相應監控，如效果很差要對效果進行報警，以便算法人員對狀況進行處理。

       推薦系統自己涉及算法層、數據層、業務層、線上服務多個層，實際也會涉及多個組，怎樣溝通效率以及開發效率以及

整個系統架構開發靈活性也是每一個參與其中的人應該去思考的。其餘公司同窗也遇到相似問題，咱們也進行相應溝通，可以

效率最大化溝通就是咱們一致的目標。

       推薦系統抽象性須要對推薦業務有足夠理解，並能跳脫推薦業務站在更高層次，將系統進行組件式、動態式、配置化設計

以及實現。一是避免重複開發，一是留有更多時間去思考如何去作更有價值的事。

       

       推薦系統不僅僅是去不斷提高轉化率、點擊率、gmv，同時咱們也要多考慮考慮怎麼樣給用戶帶去更多有價值內容，有價

值信息，不僅僅是推薦一些低俗無底線內容來達成kpi，若是工做所有以kpi爲導向，咱們最終能得到多少提高呢？

       最近一段時間對於推薦系統一點總結，以便後續查看，如對讀者有些幫助，就更好了。  

            掃碼關注