推荐系统思考小结（基于Mahout）

最近一直学习Mahout和推荐引擎相关的知识，一直想搞清楚，什么样的推荐系统的架构才是合理，既能对海量数据进行复杂运算，又能及时响应做出推荐。在网上发现一篇对推荐系统结构讲解的很好的文章数：据驱动销售——个性化推荐引擎，里面提到这样的思想“ 数据的特性对我们的架构设计起到了一个非常关键的作用，因为我们可以使用完全不同的方式来将静态数据和动态数据分开处理，再合并分析 ”，对于一个数据挖掘初学者的我，很受启发。

同时，自己也在思考，若结合实际的推荐系统中，针对不同的协同过滤算法，如何来划分动态、静态数据，它们是怎样的结构，怎么存储的，又是怎么合并分析的。根据文章作者对推荐系统的设计思路，结合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，若全部放在内存中，会占用大量的资源，对静态数据来讲完全没有必要。

而在第三步为用户计算推荐列表时，又可以结合用户的一些在线属性或浏览情况得到一些实时变化的推荐产生更好的用户体验。

原创博客，转载请注明/article/3478148.html