我们都知道，大多数的推荐算法都是单机版的。如果不进行任何处理是不能够分布式执行，也就不能充分利用像hadoop这样的分布式计算集群。这严重限制了
推荐算法的实际应用。比如协同过滤，像亚马逊、天猫这些包含大量用户、大量物品及大量行为的平台，用户-物品矩阵巨大。要实现协同过滤，时间复杂度不说，就是存储，单机的也没法
搞定。所以，实现分布式的推荐算法，充分利用集群的资源就变得非常的必要。
在我们自己的推荐算法实践过程中，已经，并且将来会更加频繁的遇到推荐算法的可扩展性问题。因此，决定对扩展性这块系统的研究一下。本篇主要是关于采用hadoop来解决扩展性问题。后面会补充“MF篇”等。
首先，讲下如何在hadoop上实现基于用户的协同过滤算法。详细可以参考文献[1]。
如何实现一个能在hadoop上执行的协同过滤算法，也就是算法要能拆分成map-reduce形式的计算模块。具体做法分为以下三步：
1、数据拆分阶段
将用户分组到不同的文件中。每个文件的每行对应一个用户的id。
数据拆分要满足两个原则：
1）在整个的运行时间上，计算时间的占比要越大越好。意思就是运行时间的大多数耗在计算上，而不是频繁的初始化mapper上。
比如，如果我们针对1000个用户创建1000个mapper，就需要频繁初始化mapper这样不如创建40或者50个要好。
2）所有task的执行完成时间相同。
2、Map阶段
mapper的setup函数首先会创建用户-物品评分矩阵，然后读取user ID文件，文件的行号为输入的key，对应的user ID为value。
然后计算用户间相似度–>找到用户的最近邻–>预测用户对所有物品的评分。最后按评分排序得到用户id及其推荐列表作为中间key/value,将其
作为reduce阶段的输入。
3、Reduce阶段
reducer根据userID排序，并将最终的结果输出到hdfs。
整个流程如下图所示：

参考文献【2】：
Sales–>Rate transform
将销售数据转换成推荐系统中的评分数据
两种转换方式：
方式1：

Sui为商店u对物品i的销售量
方式2：

Sales<–Rate transform
对应 Sales–>Rate transform的两种方式：
方式1：

方式2：

当推荐（协同过滤）完成后，又需要将评分数据转换为实际销售数据
如下图：

整个推荐算法在mapreduce上执行的流程：