推薦系統架構，推薦系統由品類平台，素材、特徵召回平台、模型計算打分服務，排序服務構成。
將請求封裝成queryinfo物件，通過物件來向下完成一步步資料召回。首先是通過queryinfo物件召回品類、分類資訊。
前邊有人問到是怎樣實現通用化？好問題，當時答得不太好，現在梳理總結一下，分類平台通過配置品類、分類資訊，
配置選取個數、配置過濾品類資訊，通過每一種配置情況構建分類資訊，分類資訊完全由配置檔案構成。
召回品類擴充套件queryinfo物件構成queryinfoextern物件，為下一步進行素材、特徵召回做準備，因為品類、分類資料量
少，傳輸時不會因為資料量消耗太多時間，而素材、特徵召回量極大，可通過分布式形式將素材進行召回，此時召回量最大
可滿足線上服務要求，召回之後，每組分別進行打分計算，打分之後進行取前邊資料進行返回。
再由品類召回節點合併將高分素材進行返回，熟悉elasticsearch同學，會發現和elasticsearch集群架構很像，其實推
薦本身和搜尋就有很多相似之處，研究搜尋引擎對於推薦引擎構建也會大有益處。
資料返回之前由排序服務對資料按展示效果進行商品按照品類、分類進行分隔，文章內容按標籤、主題進行分隔。分隔
目的是為了好的展示效果，提公升使用者體驗，通過上面這一系列過程構建成推薦系統大致過程。
除了上邊架構邏輯，還存在儲存以及資料流轉體系。分類、素材、特徵儲存在redis、hbase中供服務讀取使用。
對於實時反饋，使用者點選、瀏覽會通過儲存在redis中用於過濾，以及調整後續推薦分類、素材權重，已作為一種最實時
反饋手段。
上報特徵本身通過jdq訊息佇列進行上報，上報非同步進行，通過先寫日誌檔案再上報日誌檔案內容，來達到非同步上報，
以避免同步上報導致線上服務效能受影響。jdq本身基於開源kafka打造。
jdq本身為了資源情況限制上報速度為5m/s,為了更好利用上報機器資源，會構建記憶體佇列，充分利用記憶體資源來控制發
送速度，而不是一味通過擴容來解決問題。
面展示，方便快速定位線上問題。
監控本身除了ump對系統功能、效能、可用性進行監控，引擎本身就要配備全面監控避免程式某個分支存在問題，導致
線上服務正確性、可用性存在問題，再有因為程式很多由配置檔案動態構成，效能也要進行全面監控。
對於線上效果，線上模型與分支進行繫結，當分支a效果實時效果好於b效果，要將線上模型進行更新調整，監控時間
以幾個小時效果為準。線上效果也要進行相應監控，如效果不好要對效果進行報警，以便演算法人員對情況進行處理。
推薦系統本身涉及演算法層、資料層、業務層、線上服務多個層，實際也會涉及多個組，怎樣溝通效率以及開發效率以及
整個系統架構開發靈活性也是每個參與其中的人應該去思考的。其他公司同學也遇到類似問題，我們也進行相應溝通，能夠
效率最大化溝通就是我們一致的目標。
推薦系統抽象性需要對推薦業務有足夠理解，並能跳脫推薦業務站在更高層次，將系統進行元件式、動態式、配置化設計
以及實現。一是避免重複開發，一是留有更多時間去思考如何去做更有價值的事。
值資訊，不單單是推薦一些低俗無底線內容來達成kpi，如果工作全部以kpi為導向，我們最終能獲得多少提公升呢？
最近一段時間對於推薦系統一點總結，以便後續檢視，如對讀者有些幫助，就更好了。
掃碼關注
京東個性化推薦系統實戰（上）
推薦系統核心任務是排序，從線上服務角度看，就是將資料從給定集合中資料選擇出來，選出後根據一定規則策略方法 進行排序。線上服務要根據一定規則進行架構設計，架構設計是什麼？每一次權衡取捨都是設計，設計需要理解需求 深入理解需 求基礎上做權衡取捨。複雜系統架構需要需求方與研發人員反覆溝通 這需要技術領導者...
個性化推薦系統
基於協同過濾的推薦大體包括 基於專案的協同過濾 item basedcf 基於使用者的協同過濾 user basedcf 基於模型的協同過濾演算法 1 3 基於專案的協同過濾 item basedcf 首先根據不同使用者歷史購買商品的評分資訊計算出各專案之間的相似度，構建各專案之間的相似度矩陣 再找...
個性化推薦系統（六） 超大數量業務個性化實戰
線上系統有些業務是每天幾百篇增量資料個性化，或者是運營每天選定幾百 幾千個商品sku 池子個性化，這種是比較好進行儲存管理以及實現的。全站資料進行個性化，每個人相關資料一般 就只有幾個幾十個多個上百個，這個量級資料還可以快取儲存，可以存下來的。經分析歷史資料發現95 以上使用者只看前30頁，也就是3...