推薦系統架構，推薦系統由品類平台，素材、特征召回平台、模型計算打分服務，排序服務構成。
將請求封裝成QueryInfo對象，通過對象來向下完成一步步數據召回。首先是通過QueryInfo對象召回品類、分類信息。
前邊有人問到是怎樣實現通用化？好問題，當時答得不太好，現在梳理總結一下，分類平台通過配置品類、分類信息，
配置選取個數、配置過濾品類信息，通過每一種配置情況構建分類信息，分類信息完全由配置文件構成。
召回品類擴展QueryInfo對象構成QueryInfoExtern對象，為下一步進行素材、特征召回做准備，因為品類、分類數據量
少，傳輸時不會因為數據量消耗太多時間，而素材、特征召回量極大，可通過分布式形式將素材進行召回，此時召回量最大
可滿足線上服務要求，召回之后，每組分別進行打分計算，打分之后進行取前邊數據進行返回。
再由品類召回節點合並將高分素材進行返回，熟悉ElasticSearch同學，會發現和ElasticSearch集群架構很像，其實推
薦本身和搜索就有很多相似之處，研究搜索引擎對於推薦引擎構建也會大有益處。
數據返回之前由排序服務對數據按展示效果進行商品按照品類、分類進行分隔，文章內容按標簽、主題進行分隔。分隔
目的是為了好的展示效果，提升用戶體驗，通過上面這一系列過程構建成推薦系統大致過程。
除了上邊架構邏輯，還存在存儲以及數據流轉體系。分類、素材、特征存儲在redis、HBase中供服務讀取使用。
對於實時反饋，用戶點擊、瀏覽會通過存儲在redis中用於過濾，以及調整后續推薦分類、素材權重，已作為一種最實時
反饋手段。
上報特征本身通過JDQ消息隊列進行上報，上報異步進行，通過先寫日志文件再上報日志文件內容，來達到異步上報，
以避免同步上報導致線上服務性能受影響。JDQ本身基於開源kafka打造。
JDQ本身為了資源情況限制上報速度為5M/s,為了更好利用上報機器資源，會構建內存隊列，充分利用內存資源來控制發
送速度，而不是一味通過擴容來解決問題。
日志白名單本身按照服務、屬性、關鍵字進行存儲，在ElasticSearch中可方便按屬性、關鍵詞檢索使用，通過圖形化界
面展示，方便快速定位線上問題。
監控本身除了Ump對系統功能、性能、可用性進行監控，引擎本身就要配備全面監控避免程序某個分支存在問題，導致
線上服務正確性、可用性存在問題，再有因為程序很多由配置文件動態構成，性能也要進行全面監控。
對於線上效果，線上模型與分支進行綁定，當分支A效果實時效果好於B效果，要將線上模型進行更新調整，監控時間
以幾個小時效果為准。線上效果也要進行相應監控，如效果不好要對效果進行報警，以便算法人員對情況進行處理。
推薦系統本身涉及算法層、數據層、業務層、線上服務多個層，實際也會涉及多個組，怎樣溝通效率以及開發效率以及
整個系統架構開發靈活性也是每個參與其中的人應該去思考的。其他公司同學也遇到類似問題，我們也進行相應溝通，能夠
效率最大化溝通就是我們一致的目標。
推薦系統抽象性需要對推薦業務有足夠理解，並能跳脫推薦業務站在更高層次，將系統進行組件式、動態式、配置化設計
以及實現。一是避免重復開發，一是留有更多時間去思考如何去做更有價值的事。
推薦系統不單單是去不斷提升轉化率、點擊率、gmv，同時我們也要多考慮考慮怎么樣給用戶帶去更多有價值內容，有價
值信息，不單單是推薦一些低俗無底線內容來達成kpi，如果工作全部以kpi為導向，我們最終能獲得多少提升呢？
最近一段時間對於推薦系統一點總結，以便后續查看，如對讀者有些幫助，就更好了。
掃碼關注