显示标签为“mahout”的博文。显示所有博文
显示标签为“mahout”的博文。显示所有博文

2012年6月8日星期五

Mahout 之(四)Taste的架构和部署Demo

Taste简介
Taste是Apache Mahout提供的一个协同过滤算法的高效实现,它是一个基于Java实现的可扩展的,高效的推荐引擎。Taste既实现了最基本的基于用户的和基于内容的推荐算法,同时也提供了扩展接口,使用户可以方便的定义和实现自己的推荐算法。同时,Taste不仅仅只适用于Java应用程序,它可以作为内部服务器的一个组件以HTTP和Web Service的形式向外界提供推荐的逻辑。Taste的设计使它能满足企业对推荐引擎在性能、灵活性和可扩展性等方面的要求。

Taste的架构
Taste Architecture

Taste由以下五个主要的组件组成:

  • DataModel:DataModel是用户喜好信息的抽象接口,它的具体实现支持从任意类型的数据源抽取用户喜好信息。Taste默认提供JDBCDataModel和FileDataModel,分别支持从数据库和文件中读取用户的喜好信息。
  • UserSimilarity和ItemSimilarity:UserSimilarity用于定义两个用户间的相似度,它是基于协同过滤的推荐引擎的核心部分,可以用来计算用户的“邻居”,这里我们将与当前用户口味相似的用户称为他的邻居。ItemSimilarity 类似的,计算内容之间的相似度。
  • UserNeighborhood:用于基于用户相似度的推荐方法中,推荐的内容是基于找到与当前用户喜好相似的“邻居用户”的方式产生的。UserNeighborhood定义了确定邻居用户的方法,具体实现一般是基于 UserSimilarity 计算得到的。
  • Recommender:Recommender是推荐引擎的抽象接口,Taste中的核心组件。程序中,为它提供一个DataModel,它可以计算出对不同用户的推荐内容。实际应用中,主要使用它的实现类 GenericUserBasedRecommender或者GenericItemBasedRecommender,分别实现基于用户相似度的推荐引擎或者基于内容的推荐引擎。

运行Demo
1. 下载mahout-0.2
    svn checkout https://svn.apache.org/repos/asf/mahout/branches/mahout-0.2/
2. 准备数据源,从Grouplen下载"1 Million MovieLens Dataset",链接:http://www.grouplens.org/system/files/ml-1m.zip
3. 解压数据源压缩包,将movie.dat和ratings.dat拷贝到/mahout-0.2/examples/src/main/java/org/apache/mahout/cf/taste/example/grouplens
4. 回到/mahout-0.2/examples目录下,运行"mvn install"
5. 进入/mahout-0.2/taste-web目录,拷贝 ../examples/target/grouplens.jar到 taste-web/lib目录
    cp ../examples/target/grouplens.jar ./lib
6. 在/mahout-0.2下运行"mvn package"
7. 将 taste-web/target 目录下生成的war包“mahout-taste-webapp-0.2.war”拷贝到Tomcat的webapp下
8. 启动Tomcat,在/bin目录运行“./startup.sh”
9. 访问“http://localhost:8080/mahout-taste-webapp-0.2/RecommenderServlet?userID=1”
Build Demo

2012年4月4日星期三

Mahout 之(三)相似性度量

User CF 和 Item CF 都依赖于相似度的计算,因为只有通过衡量用户之间或物品之间的相似度,才能找到用户和物品的“邻居”,才能完成推荐。上文简单的介绍了相似性的计算,但不完全,下面就对常用的相似度计算方法进行详细的介绍:

1. 基于皮尔森相关性的相似度 —— Pearson correlation-based similarity
皮尔森相关系数反应了两个变量之间的线性相关程度,它的取值在[-1, 1]之间。当两个变量的线性关系增强时,相关系数趋于1或-1;当一个变量增大,另一个变量也增大时,表明它们之间是正相关的,相关系数大于0;如果一个变量增大,另一个变量却减小,表明它们之间是负相关的,相关系数小于0;如果相关系数等于0,表明它们之间不存在线性相关关系。

用数学公式表示,皮尔森相关系数等于两个变量的协方差除于两个变量的标准差。
 Pearson Correlation

协方差(Covariance):在概率论和统计学中用于衡量两个变量的总体误差。如果两个变量的变化趋于一致,也就是说如果其中一个大于自身的期望值,另一个也大于自身的期望值,那么两个变量之间的协方差就是正真;如果两个变量的变化趋势相反,则协方差为负值。
协方差

其中u表示X的期望E(X), v表示Y的期望E(Y)

标准差(Standard Deviation):标准差是方差的平方根
标准差

方差(Variance):在概率论和统计学中,一个随机变量的方差表述的是它的离散程度,也就是该变量与期望值的距离。
方差

即方差等于误差的平方和的期望

基于皮尔森相关系数的相似度有两个缺点:
(1) 没有考虑(take into account)用户间重叠的评分项数量对相似度的影响;
(2) 如果两个用户之间只有一个共同的评分项,相似度也不能被计算
 Table1 Pearson Correlation 的缺点

上表中,行表示用户(1~5)对项目(101~103)的一些评分值。直观来看,User1和User5用3个共同的评分项,并且给出的评分走差也不大,按理他们之间的相似度应该比User1和User4之间的相似度要高,可是User1和User4有一个更高的相似度1。

同样的场景在现实生活中也经常发生,比如两个用户共同观看了200部电影,虽然不一定给出相同或完全相近的评分,他们之间的相似度也应该比另一位只观看了2部相同电影的相似度高吧!但事实并不如此,如果对这两部电影,两个用户给出的相似度相同或很相近,通过皮尔森相关性计算出的相似度会明显大于观看了相同的200部电影的用户之间的相似度。

Mahout对基于皮尔森相关系数的相似度给出了实现,它依赖一个DataModel作为输入。
PearsonCorrelationSimilarity

同时,Mahout还针对缺点(1)进行了优化,只需要在构造PearsonCorrelationSimilarity时多传入一个Weighting.WEIGHTED参数,就能使有更多相同评分项目的用户之间的相似度更趋近于1或-1。
UserSimilarity similarity1 = new PearsonCorrelationSimilarity(model);
double value1 = similarity1.userSimilarity(1, 5);

UserSimilarity similarity2 = new PearsonCorrelationSimilarity(model, Weighting.WEIGHTED);
double value2 = similarity2.userSimilarity(1, 5);

结果:
Similarity of User1 and User5: 0.944911182523068
Similarity of User1 and User5 with weighting: 0.9655694890769175

2. 基于欧几里德距离的相似度 —— Euclidean Distance-based Similarity
欧几里德距离计算相似度是所有相似度计算里面最简单、最易理解的方法。它以经过人们一致评价的物品为坐标轴,然后将参与评价的人绘制到坐标系上,并计算他们彼此之间的直线距离。
欧几里德距离
Table2 通过欧几里德距离计算相似性

图中用户A和用户B分别对项目X、Y进行了评分。用户A对项目X的评分为2,对项目Y的评分为4,表示到坐标系中为坐标点A(1.8, 4);同样用户B对项目X、Y的评分表示为坐标点B(4.5, 2.5),因此他们之间的欧几里德距离(直线距离)为:sqrt((B.x - A.x)^2 + (A.y - B.y)^2)
Euclidean Distance

计算出来的欧几里德距离是一个大于0的数,为了使其更能体现用户之间的相似形,可以把它规约到(0, 1]之间,具体做法为:1 / (1 + d)。参见 Table2
Euclidean Distance-based Similarity

只要至少有一个共同评分项,就能用欧几里德距离计算相似度;如果没有共同评分项,那么欧几里德距离也就失去了作用。其实照常理理解,如果没有共同评分项,那么意味着这两个用户或物品根本不相似。

3. 余弦相似度 —— Cosine Similarity
余弦相似度用向量空间中两个向量夹角的余弦值作为衡量两个个体间差异的大小。相比距离度量,余弦相似度更加注重两个向量在方向上的差异,而非距离或长度上。
Cosine Similarity

与欧几里德距离类似,基于余弦相似度的计算方法也是把用户的喜好作为n-维坐标系中的一个点,通过连接这个点与坐标系的原点构成一条直线(向量),两个用户之间的相似度值就是两条直线(向量)间夹角的余弦值。因为连接代表用户评分的点与原点的直线都会相交于原点,夹角与小代表两个用户越相似,夹角越大代表两个用户的相似度越小。同时在三角系数中,角的余弦值是在[-1, 1]之间的,0度角的余弦值是1,180角的余弦值是-1。

借助三维坐标系来看下欧氏距离和余弦相似度的区别:
Distance and Cosine 3-Coordinates

从图上可以看出距离度量衡量的是空间各点间的绝对距离,跟各个点所在的位置坐标(即个体特征维度的数值)直接相关;而余弦相似度衡量的是空间向量的夹角,更加的是体现在方向上的差异,而不是位置。如果保持A点的位置不变,B点朝原方向远离坐标轴原点,那么这个时候余弦相似度cosθ是保持不变的,因为夹角不变,而A、B两点的距离显然在发生改变,这就是欧氏距离和余弦相似度的不同之处。

根据欧氏距离和余弦相似度各自的计算方式和衡量特征,分别适用于不同的数据分析模型:欧氏距离能够体现个体数值特征的绝对差异,所以更多的用于需要从维度的数值大小中体现差异的分析,如使用用户行为指标分析用户价值的相似度或差异;而余弦相似度更多的是从方向上区分差异,而对绝对的数值不敏感,更多的用于使用用户对内容评分来区分用户兴趣的相似度和差异,同时修正了用户间可能存在的度量标准不统一的问题(因为余弦相似度对绝对数值不敏感)。

Mahout没有专门给出基于余弦相似度的实现。

4. 调整余弦相似度 —— Adjusted Cosine Similarity
在余弦相似度的介绍中说到:余弦相似度更多的是从方向上区分差异,而对绝对的数值不敏感。因此没法衡量每个维数值的差异,会导致这样一个情况:比如用户对内容评分,5分制,X和Y两个用户对两个内容的评分分别为(1,2)和(4,5),使用余弦相似度得出的结果是0.98,两者极为相似,但从评分上看X似乎不喜欢这2个内容,而Y比较喜欢,余弦相似度对数值的不敏感导致了结果的误差,需要修正这种不合理性,就出现了调整余弦相似度,即所有维度上的数值都减去一个均值,比如X和Y的评分均值都是3,那么调整后为(-2,-1)和(1,2),再用余弦相似度计算,得到-0.8,相似度为负值并且差异不小,但显然更加符合现实。

5. 斯皮尔曼相关 —— Spearman Correlation
注:在Google上搜了下相关概念,理解的不是很明白~所以此处只是结合Mahout中的实现进行说明。
斯皮尔曼相关性可以理解为是排列后(Rank)用户喜好值之间的Pearson相关度。《Mahout in Action》中有这样的解释:假设对于每个用户,我们找到他最不喜欢的物品,重写他的评分值为“1”;然后找到下一个最不喜欢的物品,重写评分值为“2”,以此类推。然后我们对这些转换后的值求Pearson相关系数,这就是Spearman相关系数。

斯皮尔曼相关度的计算舍弃了一些重要信息,即真实的评分值。但它保留了用户喜好值的本质特性——排序(ordering),它是建立在排序(或等级,Rank)的基础上计算的。

回顾前面表中User1~5对Item101~103的喜好(评分)值,通过斯皮尔曼相关系数计算出的相似度为:
Table 3 Spearman Correlation

我们发现,计算出来的相似度值要么是1,要么是-1,因为这依赖于用户的喜好值和User1的喜好值是否趋于“一致变化”还是呈“相反趋势变化"。

Mahout对斯皮尔曼相关系数给出了实现,具体可参考SpearmanCorrelationSimilarity,它的执行效率不是非常高,因为斯皮尔曼相关性的计算需要花时间计算并存储喜好值的一个排序(Ranks),具体时间取决于数据的数量级大小。正因为这样,斯皮尔曼相关系数一般用于学术研究或者是小规模的计算。
UserSimilarity similarity1 = new SpearmanCorrelationSimilarity(model); // construct a Spearman Correlation-based Similarity
User1 to User1 : 1.0
User2 to User1 : -1.0
User3 to User1 : NaN
User4 to User1 : 1.0
User4 to User1 : 1.0

考虑到Spearman Correlation的效率,可以把SpearmanCorrelationSimilarity包装一层Cache,具体做法为:
UserSimilarity similarity2 = new CachingUserSimilarity(new SpearmanCorrelationSimilarity(model), model);
这样,每次计算的结果会直接放入Cache,下一次计算的时候可以立即得到结果,而不是重新再计算一次。

6. 基于谷本系数的相似性度量 —— Tanimoto Coefficient-based Similarity
Tanimoto Coefficient和前面的5中相关度计算方式有很大的不同,它不关心用户对物品的具体评分值是多少,它在关心用户与物品之间是否存在关联关系。还记得上一篇文章《Mahout学习笔记——数据承载》里面提到的布尔喜好值(Boolean Preference)吧!Tanimoto Coefficient依赖于用户和物品之间的这种Boolean关系作为输入。

更准确的说法为:Tanimoto Coefficient主要用于计算符号度量或布尔值度量的个体间的相似度,因为个体的特征属性都是由符号度量或者布尔值标识,因此无法衡量差异具体值的大小,只能获得“是否相同”这个结果,所以Tanimoto Coefficient只关心个体间共同具有的特征是否一致这个问题。Tanimoto Coefficient又被叫做Jaccard Coefficient,其值等于两个用户共同关联(不管喜欢还是不喜欢)的物品数量除于两个用户分别关联的所有物品数量。
Union/Intersection

也就是关联的交集除于关联的并集,用公式表示为:
Tanimoto/Jaccard Coefficient

其值介于[0, 1]之间,如果两个用户关联的物品完全相同,交集等于并集,值为1;如果没有任何关联,交集为空,值为0。

注:本块中说道的关联指用户对物品有评分值

2012年3月17日星期六

Mahout 之(二)协同过滤推荐

协同过滤 —— Collaborative Filtering
协同过滤简单来说就是根据目标用户的行为特征,为他发现一个兴趣相投、拥有共同经验的群体,然后根据群体的喜好来为目标用户过滤可能感兴趣的内容。

协同过滤推荐 —— Collaborative Filtering Recommend
协同过滤推荐是基于一组喜好相同的用户进行推荐。它是基于这样的一种假设:为一用户找到他真正感兴趣的内容的最好方法是首先找到与此用户有相似喜好的其他用户,然后将他们所喜好的内容推荐给用户。这与现实生活中的“口碑传播(word-of-mouth)”颇为类似。

协同过滤推荐分为三类:

  • 基于用户的推荐(User-based Recommendation)
  • 基于项目的推荐(Item-based Recommendation)
  • 基于模型的推荐(Model-based Recommendation)


基于用户的协同过滤推荐 —— UserCF
原理:基于用户对物品的喜好找到相似邻居用户,然后将邻居用户喜欢的物品推荐给目标用户
UserCF

上图示意出User CF的基本原理,假设用户A喜欢物品A和物品C,用户B喜欢物品B,用户C喜欢物品A、物品C和物品D;从这些用户的历史喜好信息中,我们可以发现用户A和用户C的口味和偏好是比较类似的,同时用户C还喜欢物品D,那么我们可以推断用户A可能也喜欢物品D,因此可以将物品D推荐给用户A。
实现:将一个用户对所有物品的偏好作为一个向量(Vector)来计算用户之间的相似度,找到K-邻居后,根据邻居的相似度权重以及他们对物品的喜好,为目标用户生成一个排序的物品列表作为推荐,列表里面都是目标用户为涉及的物品。

基于物品的协同过滤推荐 ——ItemCF
原理:基于用户对物品的喜好找到相似的物品,然后根据用户的历史喜好,推荐相似的物品给目标用户。与User CF类似,只是关注的视角变成了Item。
ItemCF

假设用户A喜欢物品A和物品C,用户B喜欢物品A、物品B和物品C,用户C喜欢物品A,从这些用户的历史喜好可以分析出物品A和物品C是比较类似的,喜欢物品A的人都喜欢物品C,基于这个数据可以推断用户C 很有可能也喜欢物品C,所以系统会将物品C推荐给用户C。
实现:将所有用户对某一个物品的喜好作为一个向量来计算物品之间的相似度,得到物品的相似物品后,根据用户历史的喜好预测目标用户还没有涉及的物品,计算得到一个排序的物品列表作为推荐。

相似度的计算 —— Similarity Metrics Computing
关于相似度的计算,现有的几种基本方法都是基于向量(Vector)的,其实也就是计算两个向量的距离,距离越近相似度越大。在推荐的场景中,在用户 - 物品偏好的二维矩阵中,我们可以将一个用户对所有物品的偏好作为一个向量来计算用户之间的相似度,或者将所有用户对某个物品的偏好作为一个向量来计算物品之间的相似度。下面我们详细介绍几种常用的相似度计算方法:
(1) 欧几里德距离(Euclidean Distance)
最初用于计算欧几里德空间中两个点的距离,假设 x,y 是 n 维空间的两个点,它们之间的欧几里德距离是:

可以看出,当 n=2 时,欧几里德距离就是平面上两个点的距离。
当用欧几里德距离表示相似度,一般采用以下公式进行转换:距离越小,相似度越大

(2) 皮尔森相关系数(Pearson Correlation Coefficient)
皮尔森相关系数一般用于计算两个定距变量间联系的紧密程度,它的取值在 [-1,+1] 之间。

(3) Cosine 相似度(Cosine Similarity)
Cosine 相似度被广泛应用于计算文档数据的相似度:


相似邻居的计算
邻居就是上文说到的“兴趣相投、拥有共同经验的群体”,在协同过滤中,邻居的计算对于推荐数据的生成是至关重要的,常用的划分邻居的方法有两类:
(1) 固定数量的邻居:K-neighborhoods 或者 Fix-size neighborhoods
用“最近”的K个用户或物品最为邻居。如下图中的 A,假设要计算点 1 的 5- 邻居,那么根据点之间的距离,我们取最近的 5 个点,分别是点 2,点 3,点 4,点 7 和点 5。但很明显我们可以看出,这种方法对于孤立点的计算效果不好,因为要取固定个数的邻居,当它附近没有足够多比较相似的点,就被迫取一些不太相似的点作为邻居,这样就影响了邻居相似的程度,比如图 1 中,点 1 和点 5 其实并不是很相似。

(2) 基于相似度门槛的邻居:Threshold-based neighborhoods
与计算固定数量的邻居的原则不同,基于相似度门槛的邻居计算是对邻居的远近进行最大值的限制,落在以当前点为中心,距离为 K 的区域中的所有点都作为当前点的邻居,这种方法计算得到的邻居个数不确定,但相似度不会出现较大的误差。如下图中的 B,从点 1 出发,计算相似度在 K 内的邻居,得到点 2,点 3,点 4 和点 7,这种方法计算出的邻居的相似度程度比前一种优,尤其是对孤立点的处理。

Threshold-based neighborhoods要表现的就是“宁缺勿滥”,在数据稀疏的情况下效果是非常明显的。Mahout对这两类邻居的计算给出了自己的实现,分别是NearestNUserNeighborhood和ThresholdUserNeighborhood,从名字就可以看出它们的对应关系
UserNeighborhood

2012年3月10日星期六

Mahout 之(一)数据承载

推荐数据的处理是大规模的,在集群环境下一次要处理的数据可能是数GB,所以Mahout针对推荐数据进行了优化。

Preference
在Mahout中,用户的喜好被抽象为一个Preference,包含了userId,itemId和偏好值(user对item的偏好)。Preference是一个接口,它有一个通用的实现是GenericPreference。
Preference

但因为用户的喜好数据是大规模的,我们通常会选择把它放入集合或者数组。但是因为Java的对象的内存消耗机制,在大数据量下使用Collection<Preference>和Preference[]是非常低效的。为什么呢?
   
在Java中,一个对象占用的字节数 = 基本的8字节 + 基本数据类型所占的字节 + 对象引用所占的字节
(1) 先说这基本的8字节
在JVM中,每个对象(数组除外)都有一个头,这个头有两个字,第一个字存储对象的一些标志位信息,如:锁标志位、经历了几次gc等信息;第二个字节是一个引用,指向这个类的信息。JVM为这两个字留了8个字      节的空间。这样一来的话,new Object()就占用了8个字节,那怕它是个空对象。
(2) 基本类型所占用的字节数
    byte/boolean   1bytes
    char/short       2bytes
    int/float           4bytes
    double/long     8bytes
(3) 对象引用所占用的字节数
    reference        4bytes
注:实际中,有数据成员的话,要把数据成员按基本类型和对象引用分开统计。基本类型按(2)进行累加,然后对齐到8个倍数;对象引用按每个4字节进行累加,然后对齐到8的倍数。
    class test {
        Integer i;
        long    l;
        byte    b;
    }
占 8(基本) + 16(数据成员——基本类型:8 + 1,对齐到8) + 8(数据成员——对象引用Integer,4,对齐到8) = 32字节

如此一来的话,一个GenericPreference的对象就需要占用28个字节,userId(8bytes) + itemId(8bytes) + preference(4bytes) + 基本的8bytes = 28。如果我们使用了Collection<Preference>和Preference[],就会浪费很多这基本的8字节。设想如果我们的数据量是上GB或是上TB,这样的开销是很难承受的。

为此Mahout封装了一个PreferenceArray,用于表示喜好数据的集合
PreferenceArray
GenericUserPreferenceArray

我们看到,GenericUserPreferenceArray包含了一个userId,一个itemId的数组long[],一个用户的喜好评分数据float[]。而不是一个Preference对象的集合。下面我们做个比较,分别创建一个PreferenceArray和Preference数组

在size为5,但只包含一条喜好数据的情况下:PreferenceArray需要20Bytes(userId 8bytes + preference 4bytes + itemId 8bytes),而Preference[]需要48字节(基本8bytes + 一个Preference对象28bytes + 4个空的引用4×3 12Bytes)。如果在有多条喜好数据的情况下,PreferenceArray中将只有一个itemId,这样它所占用的8Bytes微乎其微。所以PreferenceArray用它特殊的实现节省了4倍内存。
   
用《Mahout in action》一书中的原话“mahout has alreadly reinvented an 'array of Java objects'”——"mahout已经重新改造了Java对象数组"。PreferenceArray和它的具体实现减少的内存开销远远比它的的复杂性有价值,它减少了近75%的内存开销(相对于Java的集合和对象数组)

除了PreferenceArray,Mahout中还大量使用了像Map和Set这些非常典型的数据结构,但是Mahout没有直接使用像HashMap和TreeSet这些常用的Java集合实现,取而代之的是专门为Mahout推荐的需要实现了两个API,FastByIDMap和FastIDSet,之所以专门封装了这两个数据结构,主要目的是为了减少内存的开销,提升性能。它们之间主要有以下区别:
  • 和HashMap一样,FastByIDMap也是基于hash的。不过FastByIDMap使用的是线性探测来解决hash冲突,而不是分割链;
  • FastByIDMap的key和值都是long类型,而不是Object,这是基于节省内存开销和改善性能所作的改良;
  • FastByIDMap类似于一个缓存区,它有一个“maximum size”的概念,当我们添加一个新元素的时候,如果超过了这个size,那些使用不频繁的元素就会被移除。
FastByIDMap和FastIDSet在存储方面的改进非常显著。FastIDSet的每个元素平均占14字节,而HashSet而需要84字节;FastByIDMap的每个entry占28字节,而HashMap则需要84字节。

DataModel
Mahout推荐引擎实际接受的输入是DataModel,它是对用户喜好数据的压缩表示。DataModel的具体实现支持从任意类型的数据源抽取用户喜好信息,可以很容易的返回输入的喜好数据中关联到一个物品的用户ID列表和count计数,以及输入数据中所有用户和物品的数量。具体实现包括内存版的GenericDataModel,支持文件读取的FileDataModel和支持数据库读取的JDBCDataModel。
DataModel

GenericDataModel是DataModel的内存版实现。适用于在内存中构造推荐数据,它仅只是作为推荐引擎的输入接受用户的喜好数据,保存着一个按照用户ID和物品ID进行散列的PreferenceArray,而PreferenceArray中对应保存着这个用户ID或者物品ID的所有用户喜好数据。
GenericDataModel

FileDataModel支持文件的读取,Mahout对文件的格式没有太多严格的要求,只要满足一下格式就OK:
  • 每一行包含一个用户Id,物品Id,用户喜好
  • 逗号隔开或者Tab隔开
  • *.zip 和 *.gz 文件会自动解压缩(Mahout 建议在数据量过大时采用压缩的数据存储)

FileDataModel从文件中读取数据,然后将数据以GenericDataModel的形式载入内存,具体可以查看FileDataModel中的buildModel方法。

JDBCDataModel支持对数据库的读取操作,Mahout提供了对MySQL的默认支持MySQLJDBCDataModel,它对用户喜好数据的存储有以下要求:
  • 用户ID列需要是BIGINT而且非空
  • 物品ID列需要是BIGINT而且非空
  • 用户喜好值列需要是FLOAT
  • 建议在用户ID和物品ID上建索引

有的时候,我们会忽略用户的喜好值,仅仅只关心用户和物品之间存不存在关联关系,这种关联关系在Mahout里面叫做“boolean preference”。 之所以会有这类喜好,是因为用户和物品的关联要么存在,要么不存在,记住只是表示关联关系存不存在,不代表喜欢和不喜欢。实际上一条“boolean preference”可有三个状态:喜欢、不喜欢、没有任何关系。

在喜好数据中有大量的噪音数据的情况下,这种特殊的喜好评定方式是有意义的。 同时Mahout为“boolean preference”提供了一个内存版的DataModel——GenericBooleanPrefDataModel
GenericBooleanPrefDataModel

可以看到,GenericBooleanPrefDataModel没有对喜好值进行存储,仅仅只存储了关联的userId和itemId,注意和GenericDataModel的差别,GenericBooleanPrefDataModel采用了FastIDSet,只有关联的Id,没有喜好值。因此它的一些方法(继承自DataModel的)如getItemIDsForUser()有更好的执行速度,而getPreferencesFromUser()的执行速度会更差,因为GenericBooleanPrefDataModel本来就没存储喜好值,它默认用户对物品的喜好值都是1.0
@Override
public Float getPreferenceValue(long userID, long itemID) throws NoSuchUserException {
    FastIDSet itemIDs = preferenceFromUsers.get(userID);
    if (itemIDs == null) {
        throw new NoSuchUserException(userID);
    }
    if (itemIDs.contains(itemID)) {
        return 1.0f;
    }
    return null;
}