推薦系統思考小結（基於Mahout）

     最近一直學習Mahout和推薦引擎相關的知識，一直想搞清楚，什麼樣的推薦系統的架構纔是合理，既能對海量數據進行復雜運算，又能及時響應作出推薦。在網上發現一篇對推薦系統結構講解的很好的文章數：據驅動銷售——個性化推薦引擎，裏面提到這樣的思想「 數據的特性對咱們的架構設計起到了一個很是關鍵的做用，由於咱們可使用徹底不一樣的方式來將靜態數據和動態數據分開處理，再合併分析 」，對於一個數據挖掘初學者的我，很受啓發。

     同時，本身也在思考，若結合實際的推薦系統中，針對不一樣的協同過濾算法，如何來劃分動態、靜態數據，它們是怎樣的結構，怎麼存儲的，又是怎麼合併分析的。根據文章做者對推薦系統的設計思路，結合Mahout的源碼實現，我彷佛找到了一些類似之處，來解釋上面的問題。

     首先，仔細縷一遍Mahout產生推薦的算法流程：

     1. 原始數據，Mahout中全部協同過濾算的的輸入數據，都要求這樣的結構（UserID、ItemID、Preference）爲一條記錄，表示一個用戶對某一個商品的喜好程度；怎麼得出這樣的結果，Mahout並沒實現，值須要你輸入；通常來說是經過分析用戶各種行爲日誌記錄，結合一些特徵屬性，計算出來。

     2. 根據不一樣的協同過濾算法，獲得用戶與用戶的關係（基於用戶的） 或 商品與商品的關係（基於商品的）；這時的數據結構，更像是矩陣：UserAID（ItemAID）、UserBID（ItemBID）、Value（類似度）。

     3. 計算推薦列表，這一步比較細碎，根據不一樣的推薦算法，會有些許不一樣，但大致流程是不變；首先會計算出可能被推薦的書籍（基於用戶的協同過濾算法，會先找出此用戶的鄰居，依次找出這些鄰居喜歡的商品且此用戶未瀏覽的商品；而基於商品的協同過濾算法，則直接找出全部此用戶未瀏覽的商品）；其次逐個計算這些可能被推薦的商品的得分，並以此得分由高到底的排序；最後返回前面N個（N可有客戶端做爲請求參數而指定）。

     都知道，Mahout框架式基於Hadoop的，這樣分佈式的運算以便海量數據的處理；然而Mahout的實現卻又不少種（哪怕是同一個算法），也許Mahout是爲了給開發者提供多種實現的選擇；我本身總結了一下，它的實現模式根據Hadoop框架的使用狀況大概可分爲三種：

     第一種：徹底不使用Hadoop，上述的邏輯均在單機裏完成，爲了達到效率，在第二步時，Mahout提供一個參數maxEntries來控制總數據量。

     第二種：部分使用Hadoop，即在上述邏輯中第二步運算用戶與用戶關係或商品與商品關係時使用Hadoop，將運算結果持久化；後續的計算由單機完成後並展現。

     第三種；徹底是Hadoop運算，運算完之後的結果爲：每一個用戶有一個推薦列表；展現的話直接查庫就OK

     根據那片文章中做者描述的推薦系統結構，採用第二種實現是相對合理的，由於關係數據相對靜態，而且此部分的數據量是十分龐大，它相似矩陣，若你用戶數量或商品數量而M，那它的數據量爲M*（M-1）/2，若所有放在內存中，會佔用大量的資源，對靜態數據來說徹底沒有必要。

     而在第三步爲用戶計算推薦列表時，又能夠結合用戶的一些在線屬性或瀏覽狀況獲得一些實時變化的推薦產生更好的用戶體驗。

    原創博客，轉載請註明http://my.oschina.net/BreathL/blog/60725