1.推荐系统是一个非常复杂的系统，需要很多子模块、多子系统之间协同完成，但是其系统原理精髓是猜出用户喜欢来完善系统的推荐功能、提高用户对该软件的依赖性，也可以提高广告的接受率（相关广告的定点推送，比如你是搞it的，可以对你推荐各种型号的假发）。
2.那么怎样计算用户的喜好？
通过收集用户的所有行为信息（网站浏览信息、关注信息、收藏信息、评论信息、转发信息、订单信息、支付信息、外部信息），一般通过点击流系统来获取，计算之后向用户推荐符合喜好的相关产品、新闻、音频、视频等等。具体步骤如下：
2.1收集用户的所有信息。
2.2使用大数据计算平台对收集的信息进行处理，的到用户偏好数据。
2.3将偏好数据导入喜好类型计算算法中进行预算计算，的到预算结果。
2.4将推荐的结果导入数据库（redis、hbase）。
2.5发开一个推荐引擎，对外开放接口，输出推荐结果（通过js代码展现给用户）。
3.大数据平台完成计算流程：
3.1离线平台简单架构：可以设计将用户产生的行为信息记录到分库分表的数据库中（mysql）-----由每个子系统的dba推送到大数据平台（ftp）定时上传到hdfs-----在数据仓库中就包含了用户的相关行为数据表（hive）------通过hsql编写操作计算（底层是mr程序）得到结果表（记录用户偏好数据）-----将结果表放到算法中进行计算（算法：可以由多语言实现Python、java、Scala、c/c++）-----计算得到偏好数据或者直接产生推荐结果--------将数据导出（redis、HBASE）-------开发推荐引擎（javaweb开发）-----用户访问（通过ajax异步加载）通过用户id去推荐结果存储库（redis、HBASE）中查找返回推荐结果。离线平台计算的周期可以设定（一个月或者15天）。
3.2 实时平台简单架构：用户行为信息导入kafka创建多个对应行为信息的topic-----storm去消费topic计算得到结果-----计算得到数据或者直接产生推荐结果--------将数据导出（redis、HBASE）-------开发推荐引擎（javaweb开发）-----用户访问（通过ajax异步加载）通过用户id去推荐结果存储库（redis、HBASE）中查找返回推荐结果。
阿里推荐系统架构
4.怎样才可以让推荐系统更加的合理与科学？主要取决于计算算法、机器学习、和数据建模层面。而其他层面简单理解就是操作数据或者理解为操作数据的工具。
5.完善推荐系统的主要因素：
5.1 推荐系统如果准确性越高，越贴近用户说明完善程度越高，因此如何收集好用户偏好信息就成为推荐效果好与坏的决定因素之一。用户有很多方式向系统提供自己的偏好信息。以下举例：
同时也可以根据项目要求与功能不同开发人员可以自定义用户行为与偏好，根据以上的用户行为，我们处理分析方式大体上分为以下两种情况：
5.1.1将不同行为进行分组，计算相似度，这种方式最终的体现是：“购买了该商品的用户还买了哪些商品”、“查看该图书的用户还查看了哪些图书”、“观看了该视频的用户又观看了哪些视频”、“听了该歌曲的用户又听了哪些视频”。
5.1.2 根据不同用户行为进行加权处理，得到用户对该事物的总体喜好，比如在购买商品的时候，用户在该页面的停留时间、用户点赞关注该商品、这两个行为对于该用户的喜好影响肯定是不一样的，点赞关注在喜好权重上一定大于仅仅浏览的行为因素。这样加权处理对于用户喜好分析而言会更准确。
5.2 算法也是影响推荐系统的因素之一
5.2.1 基于用户的协同过滤算法：第一代协同过滤技术是用户的协同过滤算法是推荐系统算法的比较成功的一个，推出的时候就引起比较大的轰动，这个算法的实质就是计算用户与用户之间的相似度，相似用户称为邻居，算法找出邻居集合，集合的用户拥有较相同的喜好，根据喜好对该集合的和的用户进行相关推荐和预测。
步骤：
计算用户与用户之间的相似度
（1）根据用户购买和关注的数据，计算出用户与用户之间的相似度
A a b c d g
B a b c d e f
C a b e f
-----------------------------------------
A->B 4
A->C 2
A->D 10
A->E 5
（2）如果给A推荐商品
寻找相似度用户集:D(10) E(5) B(4)
A a b c d g(用户购买过的商品尽可能不推荐)
D a b c d g....x y z
E a b c d g..h
B a b c d g...o
---------------------------
可以推荐的结果集：{x,y,z,h,o}
（3）冷启动问题：
由于基于用户的协同过滤算法是基于用户购买过的商品进行推荐，只有已经被用户选择（购买）的物品才有机会推荐给其他用户。对于一次都没有被购买过的商品，是一个巨大灾难，没机会出头了。
（4）计算量大的问题：
对于一个拥有千万级活跃用户的电商网站来说，每计算一个用户都涉及到了上亿级别的计算。
基于用户的推荐逻辑有两个问题：冷启动与计算量巨大。基于用户的算法只有已经被用户选择（购买）的物品才有机会推荐给其他用户。在大型电商网站上来讲，商品的数量实在是太多了，没有被相当数量的用户购买的物品实在是太多了，直接导致没有机会推荐给用户了，这个问题被称之为协同过滤的“冷启动”。另外，因为计算用户的相似度是通过目标用户的历史行为记录与其他每一个用户的记录相比较的出来的，对于一个拥有千万级活跃用户的电商网站来说，每计算一个用户都涉及到了上亿级别的计算，虽然我们可以先通过聚类算法经用户先分群，但是计算量也是足够的大。
问题：
新用户怎么推荐？--------默认推荐
基于用户的协同过滤算法，推荐的商品都是已经被购买过的，对于没有被用户 购买过的商品，该如何推荐？ ---------混合推荐，将多种推荐模型的结果打乱混合推荐
商品数据和用户数量都很大的情况下，如何处理？
------ 按照一定的聚类策略，将用户聚类/物品聚类
计量大的情况怎么解决？
-------将网站中不同的用户群体通过聚类算法计算出来。
实际开发过程中如果用户几千万，我们还需要去将一个用户与几千万全比较计算相似度的话就工程量太大了，几千万相互根据笛卡尔积比较是一个很恐怖的情况，我们针对这个问题提出来最近领域来解决。
最近领域：规定了范围，比如只选出五个与用户相似度最高的相关用户，或者选择出相似度高于某个值（比如相似度满分100分，选择高于70分的用户）得相关用户组成的集合，逻辑选择入下图所示：
5.2.2 基于物品（item）的协同过滤算法：第二代协同过滤技术是基于物品的协同过滤算法，基于物品的协同过滤算法与基于用户的协同过滤算法基本类似。它使用所有用户对物品或者信息的偏好，简单理解就是有几类商品同时被人购买了，就可以理解这几件商品是相似的，在用户购买某一类商品的时候，就会推荐该商品相似的商品，可能这几件商品的商品名称风马牛不相及，产品属性有天壤之别，但通过模型算出来之后就是认为他们是相似的。
5.2.3基于人口统计学的推荐算法：
基于人口统计学的推荐机制（Demographic-based Recommendation）是一种最易于实现的推荐方法，它只是简单的根据系统用户的基本信息发现用户的相关程度，然后将相似用户喜爱的其他物品推荐给当前用户。
基于人口统计学的推荐机制的好处在于：因为不使用当前用户对物品的喜好历史数据，所以对于新用户来讲没有“冷启动（Cold Start）”的问题。这个方法不依赖于物品本身的数据，所以这个方法在不同物品的领域都可以使用，它是领域独立的（domain-independent）
5.3 如何使用过滤算法？
5.3.1 这里我们介绍的是用java语言编写的一个算法库 ：myhout，它支持协同过滤，在使用的时候需要注意输入与输出的参数即可。
5.3.2 myhout：是一个算法库，集成了很多算法，它提供一些可扩展的机器学习领域经典算法的实现，让我们开发人员直接调用使用即可，不需要去编写算法的底层，很方便，但是如果是很特殊的要求，功能很新颖的模块，还是需要去自己编写算法的底层。Myhout最早是基于mr程序的，但是现在已经基于spark了，
5.3.3 myhout能做什么？
推荐引擎：
在目前采用的机器学习技术中，推荐引擎是最容易被一眼认出来的，也是应用范围最广的。服务商或网站会根据你过去的行为为你推荐书籍、电影或文章。
在部署了推荐系统的电子商务中，亚马逊大概是最有名的。亚马逊基于用户的交易行为和网站记录为你推荐你可能喜欢的商品。
而facebook这样的社交网络则利用推荐技术为你找到最可能尚未关联的朋友。
同时，这一技术也被各大知名国内网站所使用，如腾讯、人人、京东、淘宝。
聚类：
顾名思义，物以类聚，人以群分。聚类是把具有共同属性的物品进行归类。
Google news使用聚类技术通过标题把新闻文章进行分组，从而按照逻辑线索来显示新闻，而并非给出所有新闻的原始列表。
分类：
分类技术决定了一个事物多大程度上从属于某种类别或类型，或者多大程度上具有或者不具有某些属性。与聚类一样，分类无处不在，但更多隐身于幕后。通常这些系统会考察类别中的大量实例，来学习推到出分类的规则。
雅虎邮箱基于用户以前对正常右键和垃圾邮件的报告，以及电子右键自身的特征，来判别到来的消息是否是垃圾邮件。
5.4 myhout协同过滤算法的简单使用步骤（离线情况计算分析）：
5.4.1 创建一个java maven项目，导入相关依赖
5.4.2 这里我们主要举例列出操作myhout的类，其他的不做多余的说明
public static void main(String[] args) throws Exception {
//1) 准备数据
File file = new File("用户相关喜好数据的地址");
//2) 将数据加载到内存中，
DataModel dataModel = new GroupLensDataModel(file);
//3) 计算相似度，相似度算法有很多种，欧几里得、皮尔逊等等。
UserSimilarity similarity = new PearsonCorrelationSimilarity(dataModel);
//4) 计算最近邻域，邻居有两种算法，基于固定数量的邻居和基于相似度的邻居，这里使用基于固定数量的邻居
UserNeighborhood userNeighborhood = new NearestNUserNeighborhood(100, similarity, dataModel);
//5) 构建推荐器，协同过滤推荐有两种，分别是基于用户的和基于物品的，这里使用基于用户的协同过滤推荐
Recommender recommender = new GenericUserBasedRecommender(dataModel, userNeighborhood, similarity);
//给用户ID等于5的用户推荐10个相关喜好商品或者产品
List<RecommendedItem> recommendedItemList = recommender.recommend(5, 10);
//打印推荐的结果
System.out.println("使用基于用户的协同过滤算法");
System.out.println("为用户5推荐10个产品");
for (RecommendedItem recommendedItem : recommendedItemList) {
System.out.println(recommendedItem);
}
long start = System.currentTimeMillis();
recommendedItemList = recommender.recommend(11, 10);
System.out.println(System.currentTimeMillis()-start);
}
在真实的开发环境中，通过myhout的这一步计算之后得到的推送结果集是不能直接用在项目里面的，还需要对推送的产品进行校验，去重排序等等。然后将这个打包上传到hdfs，执行命令：hadoop jar +（包名+驱动类路径）--input/sanbox/movie/10M.txt --output /sanbox/movie/r -s SIMILARITY_LOGLIKELIHOOD
- --input(path) : 存储用户偏好数据的目录，该目录下可以包含一个或多个存储用户偏好数据的文本文件；
- --output(path) : 结算结果的输出目录
- --numRecommendations (integer) : 为每个用户推荐的item数量，默认为10
- --usersFile (path) : 指定一个包含了一个或多个存储userID的文件路径，仅为该路径下所有文件包含的userID做推荐计算 (该选项可选)
- --itemsFile (path) : 指定一个包含了一个或多个存储itemID的文件路径，仅为该路径下所有文件包含的itemID做推荐计算 (该选项可选)
- --filterFile (path) : 指定一个路径，该路径下的文件包含了[userID,itemID] 值对，userID和itemID用逗号分隔。计算结果将不会为user推荐 [userID,itemID] 值对中包含的item (该选项可选)
- --booleanData (boolean) : 如果输入数据不包含偏好数值，则将该参数设置为true，默认为false
- --maxPrefsPerUser (integer) : 在最后计算推荐结果的阶段，针对每一个user使用的偏好数据的最大数量，默认为10
- --minPrefsPerUser (integer) : 在相似度计算中，忽略所有偏好数据量少于该值的用户，默认为1
- --maxSimilaritiesPerItem (integer) : 针对每个item的相似度最大值，默认为100
- --maxPrefsPerUserInItemSimilarity (integer) : 在item相似度计算阶段，针对每个用户考虑的偏好数据最大数量，默认为1000
- --similarityClassname (classname) : 向量相似度计算类
- outputPathForSimilarityMatrix ：SimilarityMatrix输出目录
- --randomSeed ：随机种子 -- sequencefileOutput ：序列文件输出路径
- --tempDir (path) : 存储临时文件的目录，默认为当前用户的home目录下的temp目录
- --threshold (double) : 忽略相似度低于该阀值的item对
查看我们得到的结果文件，可以得到类似于（用户：该用户推荐产品结果集）这样的数据之后存储到数据库（redis、HBASE）中。
在实际开发模式中存储结果集的数据库（redis、HBASE）一般情况下要存储离线计算的推荐数据、用户与用户之间的相似度数据、物品与物品之间相似度的数据、相关产品（商品、视频、音频、新闻文档等等）的信息（标题、类别、属性等等）、用户的信息（基础信息、点击流信息、购买等等），这样当我们一个用户在前端访问的时候，根据用户的id，开发好的推荐引擎去redis或者HBASE中查找已经计算完毕的相关喜好产品结果集，在这里要对推送的产品进行校验，去重排序、产品状态是否上线、产品种类的丰富性之后返回结果给用户（json/xml），从而实现相关推送这个功能。
6.目前巨头电商网站在相关推送这一模块的架构（简单说明）：
6.1我们上面所做的推荐模块是简单的案列，推荐算法单一，缺点是：要想紧紧的抓住用户的消费心理，要采用多种推荐算法来计算，成为混合推荐。
6.2混合推荐：在现行的 Web 站点上的推荐往往都不是单纯只采用了某一种推荐的机制和策略，他们往往是将多个方法混合在一起，从而达到更好的推荐效果。关于如何组合各个推荐机制，这里讲几种比较流行的组合方法。
6.3举个例子：当我们在电商网站购物成功提交订单付款之后，会在页面下方看到五六个左右的相关推送产品，如果这些推荐的商品都用同一个算法计算得到的，那么可能因为算法与用户的需求和心理的匹配程度不高而导致推荐效果不好（虽然这种可能性比较小），如果购买之后有六个推荐商品，而这六个商品的计算算法架构如下：
-
- 第一位：基于物品的实时推荐结果
- 第二位：基于用户的离线推荐结果
- 第三位：基于物品的离线推荐结果
- 第四位：基于内容的实时推荐结果
- 第五位：基于物品的实时推荐结果
- 第六位：基于用户的离线推荐结果
这样就会让用户自身感觉到在不同算法下得到的推荐方式不一，但是很可能有一种算法计算下的商品是自己需求的，同时我们还可以对这六个进行位置的改变，比如我们计算得出一般用户第一眼最先看到的是第一个的概率比较大，那么就把目前用户体验最好的算法排在第一个，以此类推。为了公司的利益还可以开展竞价排行，举例：用户购买手机之后，我们计算得出在第一个推荐位的商品应该是手机壳，但是手机壳的店家有很多，在计算结果的基础上店家竞价或者vip等级越高那么可以放在最前面。