推荐系统思考小结(基于Mahout)
来源:互联网 发布:淘宝买东西返利软件 编辑:程序博客网 时间:2024/06/04 18:14
同时,自己也在思考,若结合实际的推荐系统中,针对不同的协同过滤算法,如何来划分动态、静态数据,它们是怎样的结构,怎么存储的,又是怎么合并分析的。根据文章作者对推荐系统的设计思路,结合Mahout的源码实现,我似乎找到了一些相似之处,来解释上面的问题。
首先,仔细缕一遍Mahout产生推荐的算法流程:
1. 原始数据,Mahout中所有协同过滤算的的输入数据,都要求这样的结构(UserID、ItemID、Preference)为一条记录,表示一个用户对某一个商品的喜爱程度;怎么得出这样的结果,Mahout并没实现,值需要你输入;一般来讲是通过分析用户各类行为日志记录,结合一些特征属性,计算出来。
2. 根据不同的协同过滤算法,得到用户与用户的关系(基于用户的) 或 商品与商品的关系(基于商品的);这时的数据结构,更像是矩阵:UserAID(ItemAID)、UserBID(ItemBID)、Value(相似度)。
3. 计算推荐列表,这一步比较细碎,根据不同的推荐算法,会有些许不同,但大体流程是不变;首先会计算出可能被推荐的书籍(基于用户的协同过滤算法,会先找出此用户的邻居,依次找出这些邻居喜欢的商品且此用户未浏览的商品;而基于商品的协同过滤算法,则直接找出所有此用户未浏览的商品);其次逐个计算这些可能被推荐的商品的得分,并以此得分由高到底的排序;最后返回前面N个(N可有客户端作为请求参数而指定)。
都知道,Mahout框架式基于Hadoop的,这样分布式的运算以便海量数据的处理;然而Mahout的实现却又很多种(哪怕是同一个算法),也许Mahout是为了给开发者提供多种实现的选择;我自己总结了一下,它的实现模式根据Hadoop框架的使用情况大概可分为三种:
第一种:完全不使用Hadoop,上述的逻辑均在单机里完成,为了达到效率,在第二步时,Mahout提供一个参数maxEntries来控制总数据量。
第二种:部分使用Hadoop,即在上述逻辑中第二步运算用户与用户关系或商品与商品关系时使用Hadoop,将运算结果持久化;后续的计算由单机完成后并展示。
第三种;完全是Hadoop运算,运算完以后的结果为:每个用户有一个推荐列表;展示的话直接查库就OK
根据那片文章中作者描述的推荐系统结构,采用第二种实现是相对合理的,因为关系数据相对静态,并且此部分的数据量是十分庞大,它类似矩阵,若你用户数量或商品数量而M,那它的数据量为M*(M-1)/2,若全部放在内存中,会占用大量的资源,对静态数据来讲完全没有必要。
而在第三步为用户计算推荐列表时,又可以结合用户的一些在线属性或浏览情况得到一些实时变化的推荐产生更好的用户体验。- 推荐系统思考小结(基于Mahout)
- 推荐系统思考小结(基于Mahout)
- 推荐系统思考小结(基于Mahout)
- 推荐系统思考(基于Mahout)
- 推荐系统思考小结
- 基于Mahout的电影推荐系统(MVC架构)
- 基于Mahout的电影推荐系统
- 基于Mahout的电影推荐系统
- 基于Mahout的电影推荐系统
- 基于Mahout的电影推荐系统
- 基于Mahout的电影推荐系统
- 基于Mahout的电影推荐系统
- 基于Mahout的电影推荐系统
- 基于Mahout的电影推荐系统
- 基于Mahout的电影推荐系统
- 基于Mahout的电影推荐系统
- 基于Mahout的图书推荐系统
- 基于Mahout的电影推荐系统
- 程序员不错的网站
- Android自制发送短信程序
- 缓存图片并显示的ImageView
- 详解iOS开发之将XML转换成树
- posix多线程有感--线程高级编程(线程属性函数总结)(代码)
- 推荐系统思考小结(基于Mahout)
- MTK
- 目标检测的图像特征提取之(二)LBP特征
- 程序员技术练级攻略
- SQL函数大全
- C#解析xml(获取指定节点值)
- 笔记:Linux Shell (五):标准输入输出重定向
- mysql+hibernate数据库查询问题
- API问题 求教