推薦系統核心任務是排序，從線上服務角度看，就是將資料從給定集合中資料選擇出來，選出後根據一定規則策略方法
進行排序。
線上服務要根據一定規則進行架構設計，架構設計是什麼？每一次權衡取捨都是設計，設計需要理解需求、深入理解需
求基礎上做權衡取捨。複雜系統架構需要需求方與研發人員反覆溝通**。這需要技術領導者能理解並鼓勵這種行為，才能
有所謂技術驅動，否則光喊口號不會產生什麼所謂的技術驅動。
品類召回配置化，通過對每乙個key進行配置管理，配置項包含偏好取得數量以及卡分配置、排序優先順序等多個配置項。
每乙個配置生成乙個配置物件，配置繫結到乙個abtest演算法上。配置管理介面、配置管理服務構成配置管理平台。
素材、特徵召回配置化，根據分類召回素材，根據使用者、分類、素材、裝置、季節等多個條件拉取素材。素材與特徵全
部通過配置化進行實現，由人管理配置檔案由xml構成、素材、特徵召回這兩項特點是召回量大，要注意有大量此類偏好數量
，這種資料獲取最好用執行緒池，設定超時如超時則這次請求有部分資料未請求到，並進行記錄。
特徵上報，為了方便模型組進行模型訓練，因為一些資料是比較散的，就是說這種情況下需要對資料進行進行響應處理，
在進行上報，每一種資料處理方式是不同的，需要對特徵進行分類處理。
並且為了避免增加新特徵或者修改特徵就進行上線，這是與模型組**，根據需求設計可配置，或者說基於配置檔案的
特徵計算。要建立一套與特徵歸一化相應多種計算規則，以支援多種型別特徵配置歸一化。
分類召回級平台，素材、特徵召回級平台，均存在乙個配置更新後怎樣獲取問題。配置更新是乙個通用問題，大概存在
幾種方式：一種是配置管理介面更新時更新服務配置資訊，一種是定時更新方式，一種是通過通知方式，當有變更時發起更
新。服務節點不是一種可行方式，在過去單體web系統中是可行的。
定時更新方式實現簡單，並且能保證比較好一致性，並且就算這次更新集群存在個別節點更新失敗，下一次更新也會更
新成功。但這種方式要注意不要用線上服務定時拉取資料庫，因為會導致資料庫壓力過大，可以採取將資料庫節點資料同步
到redis方式，通過redis來支援定時更新，因redis能支援極大讀qps。
通知方式最優雅，即觀察者模式。觀察者訂閱事件，事件發生時，各個訂閱節點根據事件進行響應操作，當配置更新發
生時，線上服務節點更新配置到最新，通過zookeeper可以很容易實現此種配置方式，其實也需要比較懂zookeeper原理與程式設計。
過濾建立職責鏈進行實現，擴充套件性強，可讀性強。分類過濾，最近購買過分類，分類過濾白名單。過濾包括但不限於使用者
已購買、以**。在問答業務上，像我提問我已經回答，構建職責鏈邏輯清晰易理解。
配置化，通過配置檔案實現整個邏輯通用化，是小夥伴最初的夢想和模型組構建出來配置化召回素材以及特徵架構，很給力。
通過配置實現對於品類素材特徵召回，並且支援分層abtest,並且配置中包含對特徵計算，特徵計算主要是上報特徵用於模型計算
，但是有些資料需要進行歸一化處理，以方便模型訓練使用。並且給人編輯配置檔案為xml，通過程式轉換成json，並且通過json
來支援程式使用，能夠方便程式進行解析，xml對人友好，json對程式解析友好。
特徵歸一化是特徵上報很重要一環，他的特點是情況多，要根據資料分布情況做相應處理，就需要提前歸納總結多種情況，
因為反射效能差線上服務是接受不了的，就需要提前對資料處理分成幾類，提前想好處理邏輯，根據配置項選擇相應邏輯進行處理。
上報特徵服務、日誌白名單服務，上報特徵服務將兩部分特徵進行上報，一部分是簡單特徵由服務本身進行配置上報，另一部分
是複雜特徵由其他服務計算後呼叫上報特徵服務，兩部分合併進行特徵上報。
日誌白名單平台，服務可以配置相應使用者資訊，並且提供服務支援其他服務上報使用者在白名單中進行相應記錄，並且提供平台界
面支援檢索。這樣可以方便定位線上服務問題，快速解決問題。
推薦系統是個複雜系統，由多個模組構成，構建推薦引擎，我們在一步步探索。
掃碼關注
京東個性化推薦系統實戰（下）
推薦系統架構，推薦系統由品類平台，素材 特徵召回平台 模型計算打分服務，排序服務構成。將請求封裝成queryinfo物件，通過物件來向下完成一步步資料召回。首先是通過queryinfo物件召回品類 分類資訊。前邊有人問到是怎樣實現通用化？好問題，當時答得不太好，現在梳理總結一下，分類平台通過配置品類...
個性化推薦系統
基於協同過濾的推薦大體包括 基於專案的協同過濾 item basedcf 基於使用者的協同過濾 user basedcf 基於模型的協同過濾演算法 1 3 基於專案的協同過濾 item basedcf 首先根據不同使用者歷史購買商品的評分資訊計算出各專案之間的相似度，構建各專案之間的相似度矩陣 再找...
個性化推薦系統（六） 超大數量業務個性化實戰
線上系統有些業務是每天幾百篇增量資料個性化，或者是運營每天選定幾百 幾千個商品sku 池子個性化，這種是比較好進行儲存管理以及實現的。全站資料進行個性化，每個人相關資料一般 就只有幾個幾十個多個上百個，這個量級資料還可以快取儲存，可以存下來的。經分析歷史資料發現95 以上使用者只看前30頁，也就是3...