最近研究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的話，我有點根兒顫，但一次全部查出再計算，肯定是個慢查詢，且查詢後的數據不是規則的，需要整，又添加了計算量；若各位有好的優化思路，望能分享下，先謝過。