用户画像和推荐系统关系
用户画像是将用户的特征进行标签化，有简单的标签，也有复杂的标签，复杂的标签来自原始的标签，这其中有复杂的规则逻辑，用sql或这sparkCore来执行产生，也有利用算法模型来产生的，利用SVM,LR,RF等等分类聚类算法。可以看到其实用户画像也离不开算法当满足一定目标的用户画像产生之后，就要利用这部分标签数据，进行推荐，进行关联分析或协同过滤分析，自然会有算法，就是推荐涉及的算法。
推荐系统当然是在用户画像标签产生的基础上来做，推荐系统有两个层要考虑，一个是数据的分类，找到相似的几个部分，一个是利用ALS或SVD等跟推荐算法密切相关的算法，另外有个重要的考虑点在于用户的反馈数据，用户的反馈数据并不是实时的，会有延迟，并且反馈的数据会进入到用户画像系统的中间数据层，而正常的做法是反馈数据应该进入到推荐系统的数据分类层和推荐算法层，用于推荐的迭代优化。
也就是说我们 需要建立两套相对独立的系统，各自支持自己的业务。当前我们的用户画像系统是利用hive通过规则，利用python通过算法产生标签，标签系统有不同的层级，基础数据层，中间数据层，应用数据层。生成的应用数据一开始是放入hive中，一方面加载入impala用于交互式查询，一方面会通过程序灌入hbase中，对方提供查询接口，用于实时调用。
基于用户和物品的协同过滤区别：
计算复杂度
Item CF 和 User CF 是基于协同过滤推荐的两个最基本的算法，User CF 是很早以前就提出来了，Item CF 是从 Amazon 的论文和专利发表之后（2001 年左右）开始流行，大家都觉得 Item CF 从性能和复杂度上比 User CF 更优，其中的一个主要原因就是对于一个在线网站，用户的数量往往大大超过物品的数量，同时物品的数据相对稳定，因此计算物品的相似度不但计算量较小，同时也不必频繁更新。但我们往往忽略了这种情况只适应于提供商品的电子商务网站，对于新闻，博客或者微内容的推荐系统，情况往往是相反的，物品的数量是海量的，同时也是更新频繁的，所以单从复杂度的角度，这两个算法在不同的系统中各有优势，推荐引擎的设计者需要根据自己应用的特点选择更加合适的算法。
适用场景
在非社交网络的网站中，内容内在的联系是很重要的推荐原则，它比基于相似用户的推荐原则更加有效。比如在购书网站上，当你看一本书的时候，推荐引擎会给你推荐相关的书籍，这个推荐的重要性远远超过了网站首页对该用户的综合推荐。可以看到，在这种情况下，Item CF 的推荐成为了引导用户浏览的重要手段。同时 Item CF 便于为推荐做出解释，在一个非社交网络的网站中，给某个用户推荐一本书，同时给出的解释是某某和你有相似兴趣的人也看了这本书，这很难让用户信服，因为用户可能根本不认识那个人；但如果解释说是因为这本书和你以前看的某本书相似，用户可能就觉得合理而采纳了此推荐。
相反的，在现今很流行的社交网络站点中，User CF 是一个更不错的选择，User CF 加上社会网络信息，可以增加用户对推荐解释的信服程度。
详细：
https://www.ibm.com/developerworks/cn/web/1103_zhaoct_recommstudy2/index.html
ALS算法
ALS算法属于User-Item CF，也叫做混合CF。它同时考虑了User和Item两个方面。