推薦系統--揭開推薦的神秘面紗 · 電商系統

### 開篇先推薦幾篇關于推薦的文章，個人感覺對于入門很有實際意義，是IBM的工程師寫的，如下： [探索推薦引擎內部的秘密，第 1 部分: 推薦引擎初探](http://www.ibm.com/developerworks/cn/web/1103_zhaoct_recommstudy1/index.html) [探索推薦引擎內部的秘密，第 2 部分: 深入推薦引擎相關算法 - 協同過濾](http://www.ibm.com/developerworks/cn/web/1103_zhaoct_recommstudy2/index.html) [探索推薦引擎內部的秘密，第 3 部分: 深入推薦引擎相關算法 - 聚類](http://www.ibm.com/developerworks/cn/web/1103_zhaoct_recommstudy3/index.html) **推薦兩本書，如下：** 項亮：《推薦系統實踐》蔣凡：《推薦系統》 ### 推薦系統是什么推薦，就是把你可能喜歡的商品，推到你的面前。構建一個推薦系統，就是構建如何把商品推到你面前的過程。經常有人說，推薦就是算法，從某種角度來說，這未嘗不對。但在接觸推薦系統之前，我們還是先不研究算法，一說到算法，可能就以為很高深了，也很唬人，立馬產生一種膜拜之感，也就變得神秘起來了。對于我們沒有多少推薦理論支撐的工程師，進入推薦，還是先求入門。我們不缺實踐，先通過工作中的實踐領會某種推薦方案，再求通過閱讀書籍、學習算法加深領會和理解，進而通過不同的推薦方案，以及其效果的客觀評估，提高水平和境界。第一步，當我們真正完完整整的接觸到推薦系統，達到一個入門級水平，可以獨立構建一個千萬級PV網站的推薦系統之后，可能基本的觀點會是：（1）推薦是一個整體的計算過程，在編碼中，關于算法的部分所占的工作量可能1%都不到；（2）每一種推薦方案的選擇，都是一種整體的計算過程。構建一個千萬PV級別的推薦系統相對容易，一天的日志不過幾百M，計算過程中的數據，單臺機器的內存可以存下，當PV達到幾億幾十億時，就需要進行稍微復雜一點的分布式計算了；推薦的計算方法很多，如何選擇，效果難以預料，只有通過橫向和縱向多做效果分析，才有意義。隨著理解的加深，境界的提升，知識的更多了解，認知也都會處于不斷的調整中。。。 ### 推薦的計算過程 ### 計算的數據來源 Web訪問日志、購買、收藏，這些實際是用戶的行為數據；用戶，這是分析的基礎數據；商品，這是分析的基礎數據； ### 計劃日志的存儲格式如何標記同一個未登陸用戶；如何找出未登陸用戶和登陸用戶是用一個人。這是很重要的，這是以后日志分析計算的基礎。 **示例如下：** 27.189.237.91 - - [27/Jun/2014:15:00:01 +0800] "GET 某個URL HTTP/1.1" 200 75 "前一個URL" "95907011.390482691.1402709325.1403851977.1403852394.7" "95907011.8a8a8aeb385a8c6b013860df24501310" [- - -] [image/webp,*/*;q=0.8] "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36"? 以上Web日志URL，95907011.390482691.1402709325.1403851977.1403852394.7 和?95907011.8a8a8aeb385a8c6b013860df24501310 ，使用google analysis的js代碼記錄的，分別用來標記未登錄用戶的ID和登錄用戶的ID。對于google analysis的js代碼的用途，這里衍生一下，實際上，完全可以基于它建立第三方的流量分析系統，流程如下：（1）需要統計流量的網站進行查碼，用來記錄cookie等，并觸發到服務器端的請求（可以是去請求一個不存在的圖片）（2）當服務器端接收到請求后，會把Head里面的網站訪問流量相關信息進行記錄，服務器端的程序是一個簡單的Servlet即可。 ### 計算過程第一步根據用戶行為數據，分析出用戶和商品的關系；用戶<-->瀏覽、用戶<-->購買、用戶<-->收藏等。 ### 計算過程的第二步根據第一步計算的數據，分析中常用的推薦結果，比如根據瀏覽數據，計算出“看了又看”，根據購買數據，計算出“買了又買”等。 ### 計算過程的算法（或者叫規則）算法，是廣義的，數學公式；規則，是小眾的，公司自己定義的，復雜自己場景的業務規則，在計算過程的第二步，計算最終的推薦結果時，大部分使用的都是自行定義的業務規則。以推薦“看了又看”為例，根據一個商品，如何推薦出其他商品呢：可以就根據這個推薦類型的基本含義，一個商品 ?---> ?看了這個商品的很多人，又看了 ?---> ?很多的商品，這就是推薦結果了，但是這個推薦結果有非常非常多，如何推薦呢？可以推薦購買次數最終的，推薦最新的，推薦兩個商品的View人群最相似的...... ### 推薦結果的接口提供這就沒有什么了，都是通用的。 ### 推薦系統的核心基于業務的，推薦效果的評價體系；基于技術的，大數據量時的分布式計算 ### 代碼說明 **前置項目：**這個相關項目就比較多了，網站、商品、訂單，都有相關性。 **最新源碼：**git clone git@github.com:pumadong/cl-recommend.git 。 ### 推薦的發展大數據量計算、數據流實時計算、用戶行為精準分析、用戶聚簇細化、個性化推薦等。可能更高級別的搜索推薦，還是需要搜索推薦理論的支撐，不同于實現層面的東西，這個可能存在境界層次方面的不同，認知了才知道。。。? ### 日志分析擴展和流量統計對于日志的分析，可以統計網站的流量，但是要過濾掉對JS/CSS/IMG等靜態資源的URL，只保留真實有效的訪問。在一個頁面的訪問過程中，瀏覽器會向服務器發起很多個請求，把HTML/CSS/IMG/JS等都下載下來，解析成美觀的頁面，展現給訪問者，在這個過程中其實會在NGINX等Web服務器中，記錄很多行日志。關于流量統計，也有很多采用插碼的方式，插碼這種方式，業界的代碼標準是Google的GA，插碼的好處是可以統計記錄更多信息（超出日志），可以自定義很多事件，收集更多信息。當前google由于特殊原因國內不能直接訪問，但是對于ga代碼的統計是沒有問題的，訪問地址是：http://www.google-analytics.com/ga.js。比較日志分析和插碼兩種方式，日志分析是有訪問就記錄日志，此時頁面可能沒展示完成訪問者就關閉了；插碼這種方式，只有執行到插入的JS代碼的時候，才會記錄流星；也就是前一種強調來過，后一種強調有效訪問。日志分析這種流量分析方式，需要過濾掉爬蟲的IP地址；而插碼就不需要，因為爬蟲只會爬頁面內容，并不會執行JS，JS的執行實際是瀏覽器的JS引擎幫我們做的。另外，對于第三方的流量分析，則必須是插碼，不可能使用日志分析。官方網址：[https://support.google.com/analytics](https://support.google.com/analytics)?。