最近一直學習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，若全部放在記憶體中，會占用大量的資源，對靜態資料來講完全沒有必要。
推薦系統 基於itemCF推薦模型
雖然目前工業界很少再直接通過itemcf來進行推薦，但可以從這個演算法中體會到這種集體智慧型的應用。充分利用集體智慧型，即在大量的人群的行為和資料集中收集答案，以幫助我們對整個人群得到統計意義上的結論，推薦的個性化程度高。基於以下兩個出發點 1 興趣相近的使用者可能會對同樣的東西感興趣 2 使用者可...
推薦系統 基於UGC的推薦
使用者用標籤描述對物品的看法，所以使用者生成標籤 ugc 是聯絡使用者和物品的紐帶，也是反應使用者興趣的重要資料來源。乙個使用者標籤行為的資料集一般有乙個三元組 使用者，物品，標籤 的集合組成，其中一條記錄 a,b,c 表示使用者a給物品b打上了標籤c 乙個簡單的演算法 統計每隔使用者最常用的標籤 ...
推薦系統02 基於近鄰的推薦
推薦策略 近鄰推薦方法的關鍵點 推進系統要找到的是最優項 best item 和最優n項 top n 符號定義說明 使用者集u user 物品集i item 評價分數集合s score ru i 是使用者u對i的評分iu 是使用者u評分過的物品集合ui 是對i打過分的使用者集合iu v 同時被使用者...