注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

anqiang专栏

不要问细节是怎么搞的,源码说明一切

 
 
 

日志

 
 

Mahout分布式推荐引擎介绍  

2010-03-01 23:49:50|  分类: Hadoop & Mahout |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

一直以为在Mahout的在分布式上做了很多东西,很高深。最近一段时间由于工作中要实现一些分布式算法,所以硬着头皮看了一下它的源码。当时我匆忙的看过KMeans的实现,这次我的工作是在搜索引擎日志记录中找相似query。我是按照query以及它对应的点击商品来进行相似query匹配的,其实就是一个协同推荐问题。

开始时,我实现了一个单机版的算法,每个query对整个query集合进行相似度计算,这相当于一个笛卡尔积的计算。在独立query较小的情况下,这个计算了还可以接受,但是一旦query的量表达,例如10w级别,单机就无法容忍了。

 

所以很有必要把这个计算搬到hadoop上来做。于是我就分析了一下Mahout taste部分的源码。分享下来。

 

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端,使用NLineFileFormatuserIDS进行切割,这样一个列表就可以划分到多个Map中了;

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

 

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

 

具体的源码介绍,在后面进行介绍。
  评论这张
 
阅读(1339)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017