mahout協同過濾推薦演算法

㈠ 推薦演算法的基於協同過濾的推薦

基於協同過濾的推薦演算法理論上可以推薦世界上的任何一種東西。圖片、音樂、樣樣可以。 協同過濾演算法主要是通過對未評分項進行評分 預測來實現的。不同的協同過濾之間也有很大的不同。
基於用戶的協同過濾演算法: 基於一個這樣的假設「跟你喜好相似的人喜歡的東西你也很有可能喜歡。」所以基於用戶的協同過濾主要的任務就是找出用戶的最近鄰居，從而根據最近鄰 居的喜好做出未知項的評分預測。這種演算法主要分為3個步驟：
一，用戶評分。可以分為顯性評分和隱形評分兩種。顯性評分就是直接給項目評分（例如給網路里的用戶評分），隱形評分就是通過評價或是購買的行為給項目評分 （例如在有啊購買了什麼東西）。
二，尋找最近鄰居。這一步就是尋找與你距離最近的用戶，測算距離一般採用以下三種演算法：1.皮爾森相關系數。2.餘弦相似性。3調整餘弦相似性。調整餘弦 相似性似乎效果會好一些。
三，推薦。產生了最近鄰居集合後，就根據這個集合對未知項進行評分預測。把評分最高的N個項推薦給用戶。 這種演算法存在性能上的瓶頸，當用戶數越來越多的時候，尋找最近鄰居的復雜度也會大幅度的增長。
因而這種演算法無法滿足及時推薦的要求。基於項的協同過濾解決了這個問題。 基於項的協同過濾演算法 根基於用戶的演算法相似，只不過第二步改為計算項之間的相似度。由於項之間的相似度比較穩定可以在線下進行，所以解決了基於用戶的協同過濾演算法存在的性能瓶頸。

㈡ 協同過濾演算法是大數據嗎

不是。
協同過濾演算法側重於從大數據（集體智慧）中尋找某些隱含的模式，即通過用戶對於商品的歷史交互記錄來尋找相似的用戶。是一種較為著名和常用的推薦演算法。它側重大數據但不是大數據。
大數據（bigdata），或稱巨量資料，指的是所涉及的資料量規模巨大到無法透過主流軟體工具，在合理時間內達到擷取、管理、處理、並整理成為幫助企業經營決策更積極目的的資訊。

㈢ 推薦系統為什麼用mahout實現

mahout 有基於用戶的協同過濾演算法的hadoop實現經驗豐富 體製程序健全,ok ,原創/

㈣ 信息流的那點事：3 推薦演算法是如何實現的

講完信息流流行的原因（ 信息流的那點事：2 為什麼信息流如此流行 ），這一篇，我們來從產品的視角，來看看推薦演算法在技術上是如何實現的。

根據需要的技術和運營成本，可以將主流的推薦演算法分為三類：基於內容元數據的推薦、基於用戶畫像的推薦、基於協同過濾演算法的推薦。

基於元數據的推薦是比較基礎的推薦演算法，基本原理是給內容打標簽，具體元數據的選取根據的內容有所不同，比較通用的角度有內容的關鍵詞、類型、作者、來源等，打開一款頭條類app，選擇屏蔽一條內容，就可以看到一些該內容的元數據。

有了內容的元數據，就可以根據內容間的關聯，可以進行相關內容的推薦，喜歡看奇葩說的用戶，可能也會喜歡看同是米未傳媒出品的飯局的誘惑。根據內容的元數據，也可以記錄並逐漸明確用戶的內容偏好，進行數據積累，便於結合用戶的喜好進行對應的精準推薦，這也就是下面要說的基於用戶畫像的推薦的內容。

用戶畫像，類比一下就是給用戶打標簽，主要由三部分組成：用戶的基礎數據（年齡、性別等）、應用使用數據（應用使用頻率、時長等）和內容偏好數據（喜好的內容分類、種類等）。

對於基礎數據，不同年齡的用戶的內容偏好有很大差異，年輕人可能更喜歡新歌熱歌，而中年人可能更愛聽懷舊一些的歌曲；根據應用使用數據，可以進行用戶分層，活躍用戶可以多推薦內容促進使用，快要流失用戶可以推送一些打開率較高的內容來挽回，運營活動也可以更有針對性；基於內容偏好數據，可以記錄並逐漸明確用戶的內容偏好，從而進行更精準的推薦，從愛看娛樂新聞，到愛看國內明星，再到愛看某個小鮮肉，隨著內容偏好數據的逐步積累，頭條類產品的推薦也就越精確。

協同過濾演算法，簡單來說，就是尋找相近的用戶或內容來進行推薦，主要有基於用戶的協同過濾推薦和基於項目的協同過濾推薦兩種。

（1）基於用戶的協同過濾推薦

基於用戶的協同過濾推薦演算法，就是通過演算法分析出與你內容偏好相近的用戶，將他喜歡的內容推薦給你，這種推薦給你志同道合的人愛看的內容的思路，更相近於生活中的朋友作為同道中人的推薦。舉例來說，如果你喜歡ABC，而其他用戶在和你一樣喜歡ABC的同時，還都喜歡D，那麼就會把D推薦給你。

（2）.基於內容的協同過濾推薦

基於內容的協同過濾推薦演算法，就是通過演算法分析出內容和內容之間的關聯度，根據你喜歡的內容推薦最相關的內容，常見的看了這個內容的用戶85%也喜歡xxx，就是這種思路。舉例來說，如果你喜歡A，而喜歡A的用戶都喜歡B，那麼就會把B推薦給你。

相比於純粹的基於內容元數據的推薦，基於內容的協同過濾推薦更能發現一些內容間深層次的聯系，比如羅輯思維經常推薦各種內容，僅僅根據內容元數據來推薦，一集羅輯思維最相關的應該是另外一集，並不能推薦內容元數據相關性不太大的節目里推薦的內容；但由於可能很多用戶看完後都會搜索查看節目里推薦的內容，基於內容的協同過濾推薦就會發現兩者的相關性，進行推薦。

介紹推薦演算法的思路時，我們一直談到一個詞「內容偏好」，這也就是實現推薦演算法時一個核心的問題——需要通過怎樣的數據，才能判定用戶的內容偏好？主流的思路有一下三種：

讓用戶手動選擇，顯然是最簡單的思路，然而由於選擇的空間必然有限，只能讓用戶從幾個大類中間挑選，無法涵蓋全部內容的同時，粒度過大推薦也就很難精準。而且剛打開應用就讓用戶選擇，或者是讓用戶使用一段時間後在去補充選擇，這樣的操作都太重可能造成用戶流失。

既然手動選擇很難實現，我們就需要從用戶的使用數據中挖掘，主流的思路就是根據用戶一些主動操作來判斷，點擊閱讀了就說明喜歡，點了贊或者回復分享就是特別喜歡，如果跳過了內容就減少推薦，點擊了不感興趣，就不再推薦。

根據用戶使用的操作來判斷內容偏好，在不斷地使用中積累與細化數據，對內容偏好的判斷也就越來越准確，這就是頭條系應用的主要策略，這樣的策略對於下沉市場的不願做出主動選擇的沉默用戶，是一個非常適合的策略，但這樣只看點擊與操作，不關注內容實際質量的策略也會造成標題黨、內容低俗等問題，在後文會進一步介紹。

既然選擇不能完全代表用戶的內容偏好，如何使判斷更加精準呢？就要從一些更加隱性的數據入手了，比如對於文章，除了點擊，閱讀時間，閱讀完成度，是否查看文章的相關推薦內容，都是可以考慮的角度，相比純粹的點擊判斷，可以一定程度上解決標題黨的問題。再比如看視頻，如果快進次數過多，雖然看完了，可能也不是特別感興趣，而值得反復回看的內容，命中內容偏好的幾率就相對較高。

介紹完了推薦演算法的原理與數據來源，讓我們來試著還原一下一條內容的完整分發流程。

首先，是內容的初始化與冷啟動。可以通過演算法對內容進行分析提取或者人工處理，提取內容的來源、分類、關鍵詞等元數據，再根據用戶畫像計算內容興趣匹配度，分發給有對應內容偏好的用戶，,也可以通過內容原匹配度,向關系鏈分發,完成內容的冷啟動。

然後，可以根據用戶閱讀時間，閱讀完成度,互動數等數據，對該內容的質量進行分析，相應的增加或者減少推薦,實現內容動態分發調節。

最後，就是協同過濾演算法發揮作用的時間，對於優質內容，可以通過基於用戶的協同過濾推薦，推薦給與該內容受眾有類似愛好的用戶，也可以基於項目的協同過濾推薦，推薦給愛觀看同類內容的用戶,讓優質內容的傳播不在局限於關系鏈。

在真正的推薦演算法實現過程中，除了基礎的內容原匹配度,內容匹配度和內容質量,還有很多值得考慮的問題，比如新聞通知等時效性內容就要短時間加權，超時則不推薦；對於用戶的內容偏好也不能永遠維持，隨著時間用戶可能會喜歡新的內容，如果一定時間內用戶對以前喜歡的內容不感興趣，就要減少該種類推薦；還有為了不陷入越喜歡越推薦，最後全部是一種內容，讓用戶厭煩的境地，對於用戶的偏好也要設定一個上限；為了保持新鮮度，需要幫助用戶發現他可能喜歡的新內容.....

最後，通過數據可以了解我們如何閱讀這篇文章，但任何數據都無法准確描述我們閱讀後的感受與收獲；再高級的演算法也只是演算法，它雖然可能比我們更了解我們實際的的內容偏好，但無法了解到我們對於內容的追求。

這可能也就是頭條系產品雖然收獲了巨大成功，但也收到了標題黨、低俗化、迴音室效應等指責的原因，下一篇，讓我們來聊聊，信息流產品的面臨的問題與可能的解決方法。

㈤ 個性化推薦演算法——協同過濾

有三種：協同過濾
用戶歷史行為
物品相似矩陣

㈥ mahout包括哪些演算法

一、分類演算法

（一）Logistic 回歸（SGD）

（二）Bayesian 

（三）SVM

（四）Perceptron 和Winnow

（五）神經網路

（六）隨機森林

（七）受限玻爾茲曼機

（八）Boosting

（九）HMM

（十）Online Passive Aggressive

二、聚類演算法

（一）Canopy

（二）K-Means

（三）Fuzzy K-means

（四）EM

（五）Mean shift

（六）層次聚類

（七）Dirichlet process 

（八）LDA

（九）Spectral 

（十）MinHash

（十一）Top Down

三、推薦演算法

           Mahout包括簡單的非並行的推薦和基於Hadoop的並行推薦的實現。

（一）非並行推薦

（二）分布式的基於Item的協同過濾

（三）並行矩陣分解的協同過濾

四、關聯規則挖掘演算法

 

並行FP-Growth 

五、回歸

Locally Weighted Linear Regression

六、降維

（一）SVD

（二）SSVD

（三）PCA

（四）ICA

（五）GDA

七、進化演算法

八、向量相似性計算

㈦ 基於協同過濾的推薦演算法

協同過濾推薦演算法是最經典的推薦演算法，它的演算法思想為 物以類聚，人以群分 ，基本的協同過濾演算法基於以下的假設：

實現協同過濾的步驟：
1). 找到相似的Top-N個人或者物品 ：計算兩兩的相似度並進行排序
2). 根據相似的人或物品產生推薦結果 ：利用Top-N生成初始推薦結果，然後過濾掉用戶已經有過記錄或者明確表示不喜歡的物品

那麼，如何計算相似度呢？

根據數據類型的不同，相似度的計算方式也不同，數據類型有：

一般的，相似度計算有 傑卡德相似度、餘弦相似度、皮爾遜相關系數

在協同過濾推薦演算法中，我們更多的是利用用戶對物品的評分數據集，預測用戶對沒有評分過的物品的評分結果。

用戶-物品的評分矩陣，根據評分矩陣的稀疏程度會有不同的解決方案。

目的：預測用戶1對於物品E的評分

步驟分析：

實現過程

用戶之間的兩兩相似度：

物品之間的兩兩相似度：

㈧ 協同過濾演算法

用戶行為數據在網站上最簡單的存在形式就是日誌，比如用戶在電子商務網站中的網頁瀏覽、購買、點擊、評分和評論等活動。 用戶行為在個性化推薦系統中一般分兩種——顯性反饋行為(explicit feedback)和隱性反饋 行為(implicit feedback)。顯性反饋行為包括用戶明確表示對物品喜好的行為。網站中收集顯性反饋的主要方式就是評分和喜歡/不喜歡。隱性反饋行為指的是那些不能明確反應用戶喜好 的行為。最具代表性的隱性反饋行為就是頁面瀏覽行為。 按照反饋的明確性分，用戶行為數據可以分為顯性反饋和隱性反饋，但按照反饋的方向分， 又可以分為正反饋和負反饋。正反饋指用戶的行為傾向於指用戶喜歡該物品，而負反饋指用戶的 行為傾向於指用戶不喜歡該物品。在顯性反饋中，很容易區分一個用戶行為是正反饋還是負反饋， 而在隱性反饋行為中，就相對比較難以確定。

在利用用戶行為數據設計推薦演算法之前，研究人員首先需要對用戶行為數據進行分析，了解 數據中蘊含的一般規律，這樣才能對演算法的設計起到指導作用。

(1) 用戶活躍度和物品流行度

(2) 用戶活躍度和物品流行度的關系

一般認為，新用戶傾向於瀏覽熱門的物品，因為他 們對網站還不熟悉，只能點擊首頁的熱門物品，而老用戶會逐漸開始瀏覽冷門的物品。如果用橫坐標表示用戶活躍度，縱坐標表示具有某個活躍度的所有用戶評過分的物品的平均流行度。圖中曲線呈明顯下 降的趨勢，這表明用戶越活躍，越傾向於瀏覽冷門的物品。

僅僅基於用戶行為數據設計的推薦演算法一般稱為協同過濾演算法。學術界對協同過濾演算法進行了深入研究，提出了很多方法，比如基於鄰域的方法(neighborhood-based)、隱語義模型 (latent factor model)、基於圖的隨機遊走演算法(random walk on graph)等。在這些方法中， 最著名的、在業界得到最廣泛應用的演算法是基於鄰域的方法，而基於鄰域的方法主要包含下面兩種演算法。

基於用戶的協同過濾演算法 ：這種演算法給用戶推薦和他興趣相似的其他用戶喜歡的物品

基於物品的協同過濾演算法： 這種演算法給用戶推薦和他之前喜歡的物品相似的物品

基於鄰域的演算法是推薦系統中最基本的演算法，該演算法不僅在學術界得到了深入研究，而且在 業界得到了廣泛應用。基於鄰域的演算法分為兩大類，一類是基於用戶的協同過濾演算法，另一類是 基於物品的協同過濾演算法。現在我們所說的協同過濾，基本上就就是指基於用戶或者是基於物品的協同過濾演算法，因此，我們可以說基於鄰域的演算法即是我們常說的協同過濾演算法

(1) 基於用戶的協同過濾演算法（UserCF）

基於用戶的協同過濾演算法的基本思想是：在一個在線個性化推薦系統中，當一個用戶A需要個性化推薦 時，可以先找到和他有相似興趣的其他用戶，然後把那些用戶喜歡的、而用戶A沒有聽說過的物品推薦給A。

Ø 從上面的描述中可以看到，基於用戶的協同過濾演算法主要包括兩個步驟。 第一步：找到和目標用戶興趣相似的用戶集合。 第二步： 找到這個集合中的用戶喜歡的，且目標用戶沒有聽說過的物品推薦給目標用戶。

這里，步驟1的關鍵是計算兩個用戶的興趣相似度，協同過濾演算法主要利用行為的相似度計算興趣的相似度。給定用戶u和用戶v，令N(u)表示用戶u曾經有過正反饋的物品集合，令N(v) 為用戶v曾經有過正反饋的物品集合。那麼我們可以通過以下方法計算用戶的相似度：

基於餘弦相似度

(2) 基於物品的協同過濾演算法（itemCF）
與UserCF同理
(3) UserCF和itemCF的比 較

首先我們提出一個問題，為什麼新聞網站一般使用UserCF，而圖書、電商網站一般使用ItemCF呢？ 首先回顧一下UserCF演算法和ItemCF演算法的推薦原理。UserCF給用戶推薦那些和他有共同興 趣愛好的用戶喜歡的物品，而ItemCF給用戶推薦那些和他之前喜歡的物品類似的物品。從這個算 法的原理可以看到，UserCF的推薦結果著重於反映和用戶興趣相似的小群體的熱點，而ItemCF 的推薦結果著重於維系用戶的歷史興趣。換句話說，UserCF的推薦更社會化，反映了用戶所在的小型興趣群體中物品的熱門程度，而ItemCF的推薦更加個性化，反映了用戶自己的興趣傳承。 在新聞網站中，用戶的興趣不是特別細化，絕大多數用戶都喜歡看熱門的新聞。個性化新聞推薦更加強調抓住 新聞熱點，熱門程度和時效性是個性化新聞推薦的重點，而個性化相對於這兩點略顯次要。因 此，UserCF可以給用戶推薦和他有相似愛好的一群其他用戶今天都在看的新聞，這樣在抓住熱 點和時效性的同時，保證了一定程度的個性化。同時，在新聞網站中，物品的更新速度遠遠快於新用戶的加入速度，而且 對於新用戶，完全可以給他推薦最熱門的新聞，因此UserCF顯然是利大於弊。

但是，在圖書、電子商務和電影網站，比如亞馬遜、豆瓣、Netflix中，ItemCF則能極大地發 揮優勢。首先，在這些網站中，用戶的興趣是比較固定和持久的。一個技術人員可能都是在購買 技術方面的書，而且他們對書的熱門程度並不是那麼敏感，事實上越是資深的技術人員，他們看 的書就越可能不熱門。此外，這些系統中的用戶大都不太需要流行度來輔助他們判斷一個物品的 好壞，而是可以通過自己熟悉領域的知識自己判斷物品的質量。因此，這些網站中個性化推薦的 任務是幫助用戶發現和他研究領域相關的物品。因此，ItemCF演算法成為了這些網站的首選演算法。 此外，這些網站的物品更新速度不會特別快，一天一次更新物品相似度矩陣對它們來說不會造成 太大的損失，是可以接受的。同時，從技術上考慮，UserCF需要維護一個用戶相似度的矩陣，而ItemCF需要維護一個物品 相似度矩陣。從存儲的角度說，如果用戶很多，那麼維護用戶興趣相似度矩陣需要很大的空間， 同理，如果物品很多，那麼維護物品相似度矩陣代價較大

下表是對二者的一個全面的表較：

㈨ 如何讓Hadoop結合R語言做大數據分析

R語言和Hadoop讓我們體會到了，兩種技術在各自領域的強大。很多開發人員在計算機的角度，都會提出下面2個問題。問題1: Hadoop的家族如此之強大，為什麼還要結合R語言？
問題2: Mahout同樣可以做數據挖掘和機器學習，和R語言的區別是什麼？下面我嘗試著做一個解答：問題1: Hadoop的家族如此之強大，為什麼還要結合R語言？

a. Hadoop家族的強大之處，在於對大數據的處理，讓原來的不可能（TB,PB數據量計算），成為了可能。
b. R語言的強大之處，在於統計分析，在沒有Hadoop之前，我們對於大數據的處理，要取樣本，假設檢驗，做回歸，長久以來R語言都是統計學家專屬的工具。
c. 從a和b兩點，我們可以看出，hadoop重點是全量數據分析，而R語言重點是樣本數據分析。 兩種技術放在一起，剛好是最長補短！
d. 模擬場景：對1PB的新聞網站訪問日誌做分析，預測未來流量變化
d1:用R語言，通過分析少量數據，對業務目標建回歸建模，並定義指標d2:用Hadoop從海量日誌數據中，提取指標數據d3:用R語言模型，對指標數據進行測試和調優d4:用Hadoop分步式演算法，重寫R語言的模型，部署上線這個場景中，R和Hadoop分別都起著非常重要的作用。以計算機開發人員的思路，所有有事情都用Hadoop去做，沒有數據建模和證明，」預測的結果」一定是有問題的。以統計人員的思路，所有的事情都用R去做，以抽樣方式，得到的「預測的結果」也一定是有問題的。所以讓二者結合，是產界業的必然的導向，也是產界業和學術界的交集，同時也為交叉學科的人才提供了無限廣闊的想像空間。問題2: Mahout同樣可以做數據挖掘和機器學習，和R語言的區別是什麼？

a. Mahout是基於Hadoop的數據挖掘和機器學習的演算法框架，Mahout的重點同樣是解決大數據的計算的問題。
b. Mahout目前已支持的演算法包括，協同過濾，推薦演算法，聚類演算法，分類演算法，LDA, 樸素bayes，隨機森林。上面的演算法中，大部分都是距離的演算法，可以通過矩陣分解後，充分利用MapRece的並行計算框架，高效地完成計算任務。
c. Mahout的空白點，還有很多的數據挖掘演算法，很難實現MapRece並行化。Mahout的現有模型，都是通用模型，直接用到的項目中，計算結果只會比隨機結果好一點點。Mahout二次開發，要求有深厚的JAVA和Hadoop的技術基礎，最好兼有 「線性代數」，「概率統計」，「演算法導論」 等的基礎知識。所以想玩轉Mahout真的不是一件容易的事情。
d. R語言同樣提供了Mahout支持的約大多數演算法(除專有演算法)，並且還支持大量的Mahout不支持的演算法，演算法的增長速度比mahout快N倍。並且開發簡單，參數配置靈活，對小型數據集運算速度非常快。
雖然，Mahout同樣可以做數據挖掘和機器學習，但是和R語言的擅長領域並不重合。集百家之長，在適合的領域選擇合適的技術，才能真正地「保質保量」做軟體。

如何讓Hadoop結合R語言？

從上一節我們看到，Hadoop和R語言是可以互補的，但所介紹的場景都是Hadoop和R語言的分別處理各自的數據。一旦市場有需求，自然會有商家填補這個空白。

1）. RHadoop

RHadoop是一款Hadoop和R語言的結合的產品，由RevolutionAnalytics公司開發，並將代碼開源到github社區上面。RHadoop包含三個R包 (rmr，rhdfs，rhbase)，分別是對應Hadoop系統架構中的，MapRece, HDFS, HBase 三個部分。

2）. RHiveRHive是一款通過R語言直接訪問Hive的工具包，是由NexR一個韓國公司研發的。

3）. 重寫Mahout用R語言重寫Mahout的實現也是一種結合的思路，我也做過相關的嘗試。

4）.Hadoop調用R

上面說的都是R如何調用Hadoop，當然我們也可以反相操作，打通JAVA和R的連接通道，讓Hadoop調用R的函數。但是，這部分還沒有商家做出成形的產品。

5. R和Hadoop在實際中的案例

R和Hadoop的結合，技術門檻還是有點高的。對於一個人來說，不僅要掌握Linux, Java, Hadoop, R的技術，還要具備 軟體開發，演算法，概率統計，線性代數，數據可視化，行業背景 的一些基本素質。在公司部署這套環境，同樣需要多個部門，多種人才的的配合。Hadoop運維，Hadoop演算法研發，R語言建模，R語言MapRece化，軟體開發，測試等等。所以，這樣的案例並不太多。

㈩ mahout推薦當uid是uuid（16進制字元串）而不是Long型的處理方式

最近在做使用mahout做協同過濾推薦的時候，發現無論是數據源還是推薦函數的介面user_id必須是Long型的變數

由於業務提供的 user_id 是 uuid ，所以是個字元串類型，並且 item_id （做的是崗位推薦，即為job_id）也是 uuid 類型，於是另外再弄三張表 uid-uuid ， jid-jjid ， uid-jid-score 的映射，但是這樣做實在太麻煩了，我分析用戶日誌存儲用戶偏好表還要再多維護所有用戶和所有崗位表，遂開始研究 uuid 和 uid 能不能做個映射。

首先了解一下 UUID :

重點來了：

我現在需要處理的 uuid 就是這個 標準的UUID格式 ，了解了UUID的構成以後我們就好辦了：

1. 首先將uuid去掉連接符，從原先的uuid格式字元串轉化為沒有連接符的16進制字元串

2. 將16進制字元串轉化為10進制數(內部使用mahout介面)

用BigInt來存儲這個唯一的十進制數，這樣就構成了一種映射。

查了下python的內置uuid庫的API用法：

這里我直接用 python 演示( python3 )

輸出見下圖

寫完的時候google了一下發現牆外面也有不少討論這個的，mahout官方也是說要做轉換，直接用字元串類型進入推薦演算法，效率會特別慢！

如下：
Why user id and item id must be long type ?
how to map uuid to userid in preference class to use mahout recommender
mahout-user mailing list archives：UUID based user IDs

參考：
Python 3.x 格式化輸出字元串 % & format 筆記
python常用的十進制、16進制、字元串、位元組串之間的轉換