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进制、字符串、字节串之间的转换