使用mapreduce并行化基于物品的协同过滤算法
2014-01-14 00:01
295 查看
由于item-based CF算法能对新用户进行推荐,并且能对推荐做出合理的解释,因此它在商用中的应用是很普遍的。[35]主要的贡献则是将item-based CF算法使用map-reduce框架并行化。作者指出,在0-1评分下,基于物品的相似度的计算可以写成这个这样子(A是以user为行,item为列的矩阵,S是要计算的物品相似度矩阵):
其中,a_u表示用户u在A中对应的行,也就是u的评分记录(比如有看过的电影为1,没有的为0)。
所以,将整个评分矩阵按行(用户)存于HDFS中。每个map task求每一行与自身的外积(outer product),最后使用reduce task将map的结果聚合起来,就能将物品的相似度计算并行化了。具体算法如下:
from [1]
算法中相似度的计算用函数similarity(d, n[i], n[j])表示。很多基于两个向量内积(inner product, dot)的相似度都可以在这个框架中实现,最常见的有Cosine (余弦相似度),Pearson correlation(皮尔逊系数),和 Jaccard coeffieient(雅卡尔系数)。具体计算还涉及预处理,可以参见论文。整个相似度的计算涉及2次map-reduce迭代。第3次map-reduce迭代用于去掉低于某个threshold的相似度,以此降低物品相似度矩阵的密度。这种做法对item-based
CF 算法性能的影响是很小的,因为一个物品的邻域一般定义为:与他相似度最高的前K个其他物品。
得到相似度矩阵S后,如果一个mapper task的内存能容下整个矩阵,那么可以将S放在hadoop的分布式缓存(distributed cache)中。接下来只使用map阶段就能进行推荐计算。但是一般情况下S会很大,那得将S和用户评分记录都存在磁盘上,推荐最后使用reduce来完成。不管怎么样,使用map-reduce框架来做推荐只适合批量推荐的情况。
最后,从公式(1)可以看到,处理一行的计算量最坏情况决于,评分最多的那个用户到底评了多少个。假设为N个,那么计算量就是N^2。不幸的是,虽然数量很少很少,但总有那么一些个用户的评分是很多的。如下图所示:
from [1]
可以看到,在Yahoo! Music数据集中,虽然50%以上的用户评论数最多不超过1000个,但有少数用户的(被作者称为”power user”)评分数达到了1w多个。于是乎,这些power user在公式(1)中处理起来则比一般用户要慢100倍。为了处理这个问题,作者采用对这些”power user”采用的方法——每个人只抽取p个物品。 最终,相似度矩阵S计算的复杂度只有|U|p^2——随着用户数线性增长。
实验结果表示,这种采样的做法不会对性能造成多少影响。其中的一个解释是:这些”power user” 由于评论了太多东西,它对物品相似度贡献的参考价值反而降低了。 Why? 回顾一下,这里物品相似度计算的基本思路是:对于物品i和j,共同评价(喜欢)它们的用户越多,则他们越相似。评分少的用户u可能是因为他更趋向于某一类的物品,因而被u共同评分的两个物品相互之间很可能是有借鉴价值的。On the other hand, 虽然很可能有用户评论了所有的物品,但很明显不是所有物品都相似。这个问题在推荐问题中可以被称为active
user problem。
[1] Scalable Similarity-Based Neighborhood Methods with MapReduce
其中,a_u表示用户u在A中对应的行,也就是u的评分记录(比如有看过的电影为1,没有的为0)。
所以,将整个评分矩阵按行(用户)存于HDFS中。每个map task求每一行与自身的外积(outer product),最后使用reduce task将map的结果聚合起来,就能将物品的相似度计算并行化了。具体算法如下:
from [1]
算法中相似度的计算用函数similarity(d, n[i], n[j])表示。很多基于两个向量内积(inner product, dot)的相似度都可以在这个框架中实现,最常见的有Cosine (余弦相似度),Pearson correlation(皮尔逊系数),和 Jaccard coeffieient(雅卡尔系数)。具体计算还涉及预处理,可以参见论文。整个相似度的计算涉及2次map-reduce迭代。第3次map-reduce迭代用于去掉低于某个threshold的相似度,以此降低物品相似度矩阵的密度。这种做法对item-based
CF 算法性能的影响是很小的,因为一个物品的邻域一般定义为:与他相似度最高的前K个其他物品。
得到相似度矩阵S后,如果一个mapper task的内存能容下整个矩阵,那么可以将S放在hadoop的分布式缓存(distributed cache)中。接下来只使用map阶段就能进行推荐计算。但是一般情况下S会很大,那得将S和用户评分记录都存在磁盘上,推荐最后使用reduce来完成。不管怎么样,使用map-reduce框架来做推荐只适合批量推荐的情况。
最后,从公式(1)可以看到,处理一行的计算量最坏情况决于,评分最多的那个用户到底评了多少个。假设为N个,那么计算量就是N^2。不幸的是,虽然数量很少很少,但总有那么一些个用户的评分是很多的。如下图所示:
from [1]
可以看到,在Yahoo! Music数据集中,虽然50%以上的用户评论数最多不超过1000个,但有少数用户的(被作者称为”power user”)评分数达到了1w多个。于是乎,这些power user在公式(1)中处理起来则比一般用户要慢100倍。为了处理这个问题,作者采用对这些”power user”采用的方法——每个人只抽取p个物品。 最终,相似度矩阵S计算的复杂度只有|U|p^2——随着用户数线性增长。
实验结果表示,这种采样的做法不会对性能造成多少影响。其中的一个解释是:这些”power user” 由于评论了太多东西,它对物品相似度贡献的参考价值反而降低了。 Why? 回顾一下,这里物品相似度计算的基本思路是:对于物品i和j,共同评价(喜欢)它们的用户越多,则他们越相似。评分少的用户u可能是因为他更趋向于某一类的物品,因而被u共同评分的两个物品相互之间很可能是有借鉴价值的。On the other hand, 虽然很可能有用户评论了所有的物品,但很明显不是所有物品都相似。这个问题在推荐问题中可以被称为active
user problem。
[1] Scalable Similarity-Based Neighborhood Methods with MapReduce
相关文章推荐
- MapReduce简单实现基于物品的协同过滤算法
- 用Hadoop流实现mapreduce版推荐系统基于物品的协同过滤算法
- Hadoop 2.6 使用MapReduce实现基于物品的推荐系统
- MapReduce:基于物品的协同过滤算法的MapReduce实现
- Mahout并行基于物品的协同过滤算法源码分析(Distributed item-based CF)
- Python读取PostgreSQL数据并使用基于物品的协同过滤算法计算推荐结果
- (译)碰撞检测和收集物品:如何使用cocos2d制作基于tiled地图的游戏:第二部分
- 基于MongoDB分布式存储进行MapReduce并行查询
- 推荐算法--基于物品协同过滤算法实现(python: Item-CF)
- [推荐算法]ItemCF,基于物品的协同过滤算法
- 推荐算法之基于物品的协同过滤算法
- 实战智能推荐系统(8)-- 基于物品的协同过滤算法
- 推荐引擎之Mahout 基于用户协同过滤算法的使用
- 使用Scikit-learn实现基于内存的协同过滤算法(使用movieLens数据集)
- 基于用户的协同过滤算法和基于物品的协同过滤算法之java实现
- 实战智能推荐系统(8)-- 基于物品的协同过滤算法
- 推荐算法——基于物品的协同过滤算法
- 11. 碰撞检测和收集物品:如何使用cocos2d制作基于tiled地图的游戏:第二部分
- 实战智能推荐系统(8)-- 基于物品的协同过滤算法
- 用协同过滤算法对电影评分,并使用RMSE算出预测误差的MapReduce实现