最近研究mahout比較多，特別是裡面協同過濾演算法；於是把協同過濾演算法的這個實現思路與資料流程，總結了一下，以便以後對系統做優化時，有個清晰的思路，這樣才能知道該如何優化且優化後資料亦能正確。
推薦中的協同過濾演算法簡單說明下：
首先，通過分析使用者的偏好行為，來挖掘出裡面物品與物品、或人與人之間的關聯。
其次，通過對這些關聯的關係做一定的運算，得出人與物品間喜歡程度的猜測，即推薦值。
最後，將推薦值高的物品推送給特定的人，以完成一次推薦。
這裡只是籠統的介紹下，方便下邊的理解，ibm的一篇部落格對其原理講解得淺顯易懂，同時也很詳細《
深入推薦引擎相關演算法 - 協同過濾》，我這裡就不細講了。
協同過濾演算法大致可分為兩類，基於物品的與基於使用者的；區分很簡單，根據上面的邏輯，若你挖掘的關係是物品與物品間的，就是基於物品的協同過濾演算法，若你挖掘的關係是使用者與使用者間的，就是基於使用者的協同過濾演算法；由於它們實現是有所不同，所以我分開整理，先來看看基於物品的協同過濾實現，我自己畫了一幅圖：
我通過數字的順序，來標示資料變化的方向（由小到大）；下面分析下每乙個步驟的功能以及實現。
首先，說明下兩個大的資料來源，使用者偏好資料：userid、itemid、preference：表示乙個對乙個物品的喜好程度；關係資料：itemida(userida)、itemidb(useridb)、similarity：表示兩個人或物品間的相似程度；接著
乙個使用者來了，我們需要為其推薦，得拿到他的身份標示，一般是userid，於是： ①
. 查詢這個使用者喜歡過的物品（即偏好的產品，並查出偏好值後面會用），以及還沒有喜歡過的商品，前者是推薦運算的根據，後者作為乙個產生推薦的乙個集合；如
② 畫的那樣。
②. 這裡是乙個可擴充套件的地方（我自己理解）；因為這兩部分的資料的作用非常明顯，修改這兩個集合對後面產生的推薦結果可產生非常直觀的影響，比如清洗過濾，或根據使用者屬性縮小集合；不僅使後面推薦效果更優，運算效能也可以大幅度提高。
③. 查詢這兩個集合之間的關係，這是一對多的關係：乙個沒有偏好過的物品與該使用者所有偏好過的物品間的關係，有乙個值來衡量這個關係叫相似度similarity；這個關係怎麼來的，看藍色箭頭的指向。步驟⑥
④.得到這個一對多的關係後，就可以計算這個物品對於這個使用者的推薦值了，圖中similarity_i-x表示item_i 與 item_x 之間的相似度，item_x是該使用者偏好過得，該使用者對其偏好值記為 value_x ，相乘；item_i 與 該使用者偏好過的所有物品以此做以上運算後，得到的值取平均值 便是 item_i的推薦值了。注：有可能item_i 不是與所有 該使用者偏好過的物品都都存在相似性，不存在的，不計算即可；另外這裡方便理解介紹的都是最簡單的實現；你也可以考一些複雜的數學元素，比如方差來判斷離散性等。
⑤. 這步就簡單多了，剛才對該使用者沒有偏好過的集合中的所有item都計算了推薦值，這裡就會得到乙個list，按推薦值由大到小排序，返回前面的乙個子集即可。
⑥。 前面已經提到，關係資料時怎麼來的，也是根據使用者的偏好資料；你把其看成乙個矩陣，橫著看過來，參考兩個item間的共同使用者，以及共同使用者的偏好的值的接近度；這裡的可選擇的相似度演算法很多，不一一介紹了，前面提到的ibm部落格也詳細講解了。
基於物品的協同過濾演算法分析完了，下面是基於使用者的協同過濾演算法，還是自己畫了一幅圖：
①. 同樣也是查詢，只是查詢的物件不一樣了，查詢的是與該使用者相似的使用者，所以一來直接查了關係資料來源。以及相似使用者與該使用者的相似度。
②. 與剛才類似，也是對資料集的乙個優化，不過作用可能沒那麼大。（個人感覺）
③. 查詢關係資料來源，得到相似使用者即鄰居偏好過的物品；如步驟
④；圖中由於空間小，沒有把所有鄰居的偏好關係都列出來，用……表示。其次還要得到該使用者偏好過的物品集合。
④. 被推薦的item集合是由該使用者的所有鄰居的偏好過的物品的並集，同時再去掉該使用者自己偏好過的物品。作用就是得到你的相似使用者喜歡的物品，而你還沒喜歡過的。
⑤. 集合優化同基於物品的協同過濾演算法的步驟②。⑥
. 也是對應類似的，依次計算被推薦集合中item_i 的推薦值，計算的方式略有不同，
value_1_i表示鄰居1對，item_i的偏好值，乘以該使用者與鄰居1的相似度 similarity1；若某個鄰居對item_i偏好過，就重複上述運算，然後取平均值；得到item_i的推薦值。 ⑦、
⑧. 與上乙個演算法的最後兩部完全類似，只是步驟
⑧你豎著看，判斷兩個使用者相似的法子和判斷兩個物品相似的法子一樣。
詳細的實現過程分析完了，但mahout裡面的實現時，似乎不太考慮查詢的成本，並非一次全部查出，每計算個item的推薦值查一次，你計算5000個就查5000次，若資料來源都使用的是mysql的話，我有點根兒顫，但一次全部查出再計算，肯定是個慢查詢，且查詢後的資料不是規則的，需要整，又新增了計算量；若各位有好的優化思路，望能分享下，先謝過。
推薦系統中協同過濾演算法實現分析
最近研究mahout比較多，特別是裡面協同過濾演算法 於是把協同過濾演算法的這個實現思路與資料流程，總結了一下，以便以後對系統做優化時，有個清晰的思路，這樣才能知道該如何優化且優化後資料亦能正確。推薦中的協同過濾演算法簡單說明下 首先，通過分析使用者的偏好行為，來挖掘出裡面物品與物品 或人與人之間的...
推薦系統中協同過濾演算法實現分析
最近研究mahout比較多，特別是裡面協同過濾演算法 於是把協同過濾演算法的這個實現思路與資料流程，總結了一下，以便以後對系統做優化時，有個清晰的思路，這樣才能知道該如何優化且優化後資料亦能正確。推薦中的協同過濾演算法簡單說明下 首先，通過分析使用者的偏好行為，來挖掘出裡面物品與物品 或人與人之間的...
協同過濾推薦演算法 協同過濾推薦演算法總結
推薦演算法具有非常多的應用場景和商業價值，因此對推薦演算法值得好好研究。推薦演算法種類很多，但是目前應用最廣泛的應該是協同過濾類別的推薦演算法，本文就對協同過濾類別的推薦演算法做乙個概括總結，後續也會對一些典型的協同過濾推薦演算法做原理總結。推薦演算法概述 1 基於內容的推薦 這一類一般依賴於自然語...