README.md · 喵了个咪/基于Spark电子商务推荐系统

# ECommerceRecommendSystem

#### 介绍
电子商务推荐系统

#### 模块
DataLoader              数据预处理模块
StatisticsRecommender   离线推荐模块
OfflineRecommender      基于隐语义模型的协同过滤推荐模块
OnlineRecommender       实时推荐模块
    KafkaStreaming          kafka 处理
ContentRecommender      基于内容的离线推荐系模块
businessServer          前端项目

#### 架构说明

**数据加载准备** 
    在src/main/目录下，可以看到已有的默认源文件目录是java，我们可以将其改名为scala。将数据文products.csv，ratings.csv复制到资源文件目录src/main/resources下，我们将从这里读取数据并加载到mongodb中。

**### 离线推荐服务建设** 
    离线推荐服务是综合用户所有的历史数据，利用设定的离线统计算法和离线推荐算法周期性的进行结果统计与保存，计算的结果在一定时间周期内是固定不变的，变更的频率取决于算法调度的频率。
    离线推荐服务主要计算一些可以预先进行统计和计算的指标，为实时计算和前端业务相应提供数据支撑。
    离线推荐服务主要分为统计推荐、基于隐语义模型的协同过滤推荐以及基于内容和基于Item-CF的相似推荐。
**基于隐语义模型的协同过滤推荐**

项目采用ALS作为协同过滤算法，根据MongoDB中的用户评分表计算离线的用户商品推荐列表以及商品相似度矩阵。
    用户商品推荐列表
    通过ALS训练出来的Model来计算所有当前用户商品的推荐列表，主要思路如下：
        1.userId和productId做笛卡尔积，产生（userId，productId）的元组
        2.通过模型预测（userId，productId）对应的评分。
        3.将预测结果通过预测分值进行排序。
        4.返回分值最大的K个商品，作为当前用户的推荐列表。
 **实时推荐服务建设**

实时计算与离线计算应用于推荐系统上最大的不同在于实时计算推荐结果应该反映最近一段时间用户近期的偏好，而离线计算推荐结果则是根据用户从第一次评分起的所有评分记录来计算用户总体的偏好。
    用户对物品的偏好随着时间的推移总是会改变的。比如一个用户u 在某时刻对商品p 给予了极高的评分，那么在近期一段时候，u 极有可能很喜欢与商品p 类似的其他商品；而如果用户u 在某时刻对商品q 给予了极低的评分，那么在近期一段时候，u 极有可能不喜欢与商品q 类似的其他商品。所以对于实时推荐，当用户对一个商品进行了评价后，用户会希望推荐结果基于最近这几次评分进行一定的更新，使得推荐结果匹配用户近期的偏好，满足用户近期的口味。
    如果实时推荐继续采用离线推荐中的ALS 算法，由于算法运行时间巨大，不具有实时得到新的推荐结果的能力；并且由于算法本身的使用的是评分表，用户本次评分后只更新了总评分表中的一项，使得算法运行后的推荐结果与用户本次评分之前的推荐结果基本没有多少差别，从而给用户一种推荐结果一直没变化的感觉，很影响用户体验。
    另外，在实时推荐中由于时间性能上要满足实时或者准实时的要求，所以算法的计算量不能太大，避免复杂、过多的计算造成用户体验的下降。鉴于此，推荐精度往往不会很高。实时推荐系统更关心推荐结果的动态变化能力，只要更新推荐结果的理由合理即可，至于推荐的精度要求则可以适当放宽。
    所以对于实时推荐算法，主要有两点需求：
    （1）用户本次评分后、或最近几个评分后系统可以明显的更新推荐结果；
    （2）计算量不大，满足响应时间上的实时或者准实时要求；
    5.2 实时推荐模型和代码框架
    5.2.1 实时推荐模型算法设计
    当用户u 对商品p 进行了评分，将触发一次对u 的推荐结果的更新。由于用户u 对商品p 评分，对于用户u 来说，他与p 最相似的商品们之间的推荐强度将发生变化，所以选取与商品p 最相似的K 个商品作为候选商品。
    每个候选商品按照“推荐优先级”这一权重作为衡量这个商品被推荐给用户u 的优先级。
    这些商品将根据用户u 最近的若干评分计算出各自对用户u 的推荐优先级，然后与上次对用户u 的实时推荐结果的进行基于推荐优先级的合并、替换得到更新后的推荐结果。
    具体来说：
    首先，获取用户u 按时间顺序最近的K 个评分，记为RK；获取商品p 的最相似的K 个商品集合，记为S；
    然后，对于每个商品q S ，计算其推荐优先级 ，计算公式如下：
     
        其中：
     表示用户u 对商品r 的评分；
    sim(q,r)表示商品q 与商品r 的相似度，设定最小相似度为0.6，当商品q和商品r 相似度低于0.6 的阈值，则视为两者不相关并忽略；
    sim_sum 表示q 与RK 中商品相似度大于最小阈值的个数；
    incount 表示RK 中与商品q 相似的、且本身评分较高（>=3）的商品个数；
    recount 表示RK 中与商品q 相似的、且本身评分较低（<3）的商品个数；
    公式的意义如下：
    首先对于每个候选商品q，从u 最近的K 个评分中，找出与q 相似度较高（>=0.6）的u 已评分商品们，对于这些商品们中的每个商品r，将r 与q 的相似度乘以用户u 对r 的评分，将这些乘积计算平均数，作为用户u 对商品q 的评分预测即
     
    然后，将u 最近的K 个评分中与商品q 相似的、且本身评分较高（>=3）的商品个数记为 incount，计算lgmax{incount,1}作为商品 q 的“增强因子”，意义在于商品q 与u 的最近K 个评分中的n 个高评分(>=3)商品相似，则商品q 的优先级被增加lgmax{incount,1}。如果商品 q 与 u 的最近 K 个评分中相似的高评分商品越多，也就是说n 越大，则商品q 更应该被推荐，所以推荐优先级被增强的幅度较大；如果商品q 与u 的最近K 个评分中相似的高评分商品越少，也就是n 越小，则推荐优先级被增强的幅度较小；
    而后，将u 最近的K 个评分中与商品q 相似的、且本身评分较低（<3）的商品个数记为 recount，计算lgmax{recount,1}作为商品 q 的“削弱因子”，意义在于商品q 与u 的最近K 个评分中的n 个低评分(<3)商品相似，则商品q 的优先级被削减lgmax{incount,1}。如果商品 q 与 u 的最近 K 个评分中相似的低评分商品越多，也就是说n 越大，则商品q 更不应该被推荐，所以推荐优先级被减弱的幅度较大；如果商品q 与u 的最近K 个评分中相似的低评分商品越少，也就是n 越小，则推荐优先级被减弱的幅度较小；
    最后，将增强因子增加到上述的预测评分中，并减去削弱因子，得到最终的q 商品对于u 的推荐优先级。在计算完每个候选商品q 的 后，将生成一组<商品q 的ID, q 的推荐优先级>的列表updatedList：
     
    而在本次为用户u 实时推荐之前的上一次实时推荐结果Rec 也是一组<商品m,m 的推荐优先级>的列表，其大小也为K：
     
    接下来，将updated_S 与本次为u 实时推荐之前的上一次实时推荐结果Rec进行基于合并、替换形成新的推荐结果NewRec：
     
    其中，i表示updated_S 与Rec 的商品集合中的每个商品，topK 是一个函数，表示从 Rec updated _ S中选择出最大的 K 个商品，cmp =   表示topK 函数将推荐优先级 值最大的K 个商品选出来。最终，NewRec 即为经过用户u 对商品p 评分后触发的实时推荐得到的最新推荐结果。
    总之，实时推荐算法流程流程基本如下：
    （1）用户u 对商品p 进行了评分，触发了实时推荐的一次计算；
    （2）选出商品p 最相似的K 个商品作为集合S；
    （3）获取用户u 最近时间内的K 条评分，包含本次评分，作为集合RK；
    （4）计算商品的推荐优先级，产生<qID,>集合updated_S；
    将updated_S 与上次对用户u 的推荐结果Rec 利用公式(4-4)进行合并，产生新的推荐结果NewRec；作为最终输出。

#### 使用说明
启动zookeeper
    ./bin/zkServer.sh start
启动kafka
    /bin/kafka-server-start.sh -daemon config/server.properties

喵了个咪/基于Spark电子商务推荐系统

简介

发行版

贡献者

近期动态

喵了个咪/基于Spark电子商务推荐系统 .gitee-modal { width: 500px !important; }

简介

发行版

贡献者

近期动态

搜索帮助

喵了个咪/基于Spark电子商务推荐系统