mahout中Taste提交job的流程：

Taste提交job的流程：

 

1. 获得job处理所需要的样本信息；推荐引擎定义的有几种文件格式，有从数据库读取，有从文件系统里读取，我觉得从文件系统里最方便，可能是我现在使用Hadoop的缘故吧。不同的数据来源会由不同的DataModel来进行数据读取。例如文件系统的是FileDataModel，文件系统内的文件格式是 userID ItemID value,中间通过”\t”或者”,”进行分割。数据库系统的读取也是通过指定userID ItemID value相对于的数据表字段就可以了。这些熟悉Taste的人应该都了解。

 

2. 获取需要得到相似对象的userID队列，这个队列应该是每行一个用户ID

 

3. 将第一个获取到的样本信息全部下载到本地

 

4. 在本地构建一个推荐引擎

 

5. 对map中的每一个userID，通过推荐引擎给其推荐相似对象

 

 

 

看到这个流程后，大家也就明白了，所谓的分布式，其实只是对需要计算相似对象的userID进行了分布运算而已，而计算相似度的本身还是在本地构建推荐引擎，然后计算。

 

 

 

这里最要注意的问题是，这个userIDS列表，我们一定不要再Map中就直接做计算，因为默认的通过TextFileFormat中，Hadoop按照文件的大小来划分Map，所以如果在Map做计算的话，很有可能所有的userID寻找相似对象的工作都在一个Map或者少量的几个Map中做了（笔者就犯了这个错误，结果Map就启动了两个，计算速度并没有比单机快多少）。

 

 

 

具体解决办法由两种

 

1.     在Map端，使用NLineFileFormat对userIDS进行切割，这样一个列表就可以划分到多个Map中了；

 

2.     在Reduce端，如果我们在Map端不做任何工作，仅仅是将userIDS输出到Reduce中，这时通过对userID的hash，userIDS这个列表就会被划分到多个Reduce中了，那么计算的速度自然就提高了。

 

 

 

笔者在对10万的记录做笛卡尔积时，1G内存，CPU不详（公司的机器应该也不差）。几个小时下来也不能结束。将计算搬到Hadoop上，通过第二种方案，计算时间被压缩到了10分钟以内。