项目的背景
推荐系统可以在用户没有明确表述需求的情况下，给出准确的，甚至超出预期的建议结果，以提升用户满意度和GMV。
典型的推荐场景如下：
电商，根据商品推荐商品
根据推荐位置划分合适的推荐算法
推荐算法有很多种，但是在互联网行业使用较多实现效率高的算是“协同过滤”。但是根据不同的位置用户接受程度的不同，又有所区分。
推荐算法的分类，可以参考这篇博文
（http://www.ibm.com/developerworks/cn/web/1103_zhaoct_recommstudy1/index.html）
本项目的主要目标：
基于项目的协同过滤推荐
基于项目的协同过滤推荐的基本原理也是类似的，只是说它使用所有用户对物品或者信息的偏好，发现物品和物品之间的相似度，然后根据用户的历史偏好信息，将类似的物品推荐给用户，下图 很好的诠释了它的基本原理。
基于item的推荐
假设用户 A 喜欢物品 A 和物品 C，用户 B 喜欢物品 A，物品 B 和物品 C，用户 C 喜欢物品 A，从这些用户的历史喜好可以分析出物品 A 和物品 C 时比较类似的，喜欢物品 A 的人都喜欢物品 C，基于这个数据可以推断用户 C 很有可能也喜欢物品 C，所以系统会将物品 C 推荐给用户 C。
与上面讲的类似，基于项目的协同过滤推荐和基于内容的推荐其实都是基于物品相似度预测推荐，只是相似度计算的方法不一样，前者是从用户历史的偏好推断，而后者是基于物品本身的属性特征信息。
架构设计目标
实时：订阅推荐系统关注的数据流：推荐商品点击数据。实时记录推荐过，点击过的商品。
非实时：复用现有的离线数据集，如：用户属性，商品属性，商品喜欢，买手关注，商品购买记录。
初版推荐算法，基于item推荐item。结果出现在app商品详情页。
数据出现的具体策略：
（1） 优先基于item的协同过滤items 集合
（2） 同类目下最热门的items集合（by search）
（3） 同类目下最新的items集合（by search）在商品详情页的底部尝试如下算法流程
A）基于协同过滤的item推荐
1） 使用详情页item内容；使用该用户历史购买/喜欢/点击商品的item内容的共现性质的协同过滤算法。
原因：此处给出基于物品的推荐更好被用户理解（没有差别特别巨大的商品推荐出来）。
为了解决冷启动问题：
B）基于item内容的推荐
1） 同二级分类下面的热门商品／最新鲜商品
2） 基于搜索，标题丢进query检索，取top k结果，也可以使用类目做进一步的限制。
3） 将来有更多的标签后，可以使用elasticsearch的more like this功能。
C）过滤掉已经沟通过/喜欢过/展示过的数据未来
随着分享和晒单的数据增多，可以在“发现”tab引入基于用户维度的协同过滤推荐。
“今日推荐”：根据user维度的协同过滤和热度综合。
整体架构
说明
离线系统负责算法的数据搜集，数据来源于2处
1）mysql集群：如用户表，商品表，赞等等。
2）消息队列：如用户准实时的点击，赞等交互行为日志。在线使用elastic search提供服务
我个人感觉的优点如下：
1）复用搜索服务集群，开发效率稳定性比较有保证。
2）通过搜索的方式召回，天然去除了热点带来的“马太效应”的问题。
3）通过elastic search的多列，天然支持多列的boosting推荐。
具体请参考这篇博客:http://occamsmachete.com/ml/2014/10/07/creating-a-unified-recommender-with-mahout-and-a-search-engine/计算集群
1）需要先搭建好spark和mahout
2）本项目主要使用了其中的spark-itemsimilarity 算法，我们主要集中于数据实时全面的准备即可。
详细请参考：https://mahout.apache.org/users/algorithms/intro-cooccurrence-spark.html在线请求
一个典型的query如下：
{
"query":{
"query_string":{
"query":"rec_buy^3:68827 OR rec_like^1: 68827 "
}}
}
通过购买或者喜欢召回item相似的商品作为推荐list。并可根据业务调整不同的重要性，如这个query，我们认为购买行为比点赞行为更能反映用户的喜好。
最终返回的结果list需要去除用户已经购买过或浏览过的商品集合。
上线效果
由于使用elastic search集群，在gc正常下，系统运行十分稳定
显著提升了用户的停留时间和gmv
在更全面更快速搜集好用户行为数据后，有希望进一步提升推荐的效果
