推荐系统–揭开推荐的神秘面纱
最后更新于：2022-04-01 11:02:57
### 开篇
先推荐几篇关于推荐的文章，个人感觉对于入门很有实际意义，是IBM的工程师写的，如下：
[探索推荐引擎内部的秘密，第 1 部分: 推荐引擎初探](http://www.ibm.com/developerworks/cn/web/1103_zhaoct_recommstudy1/index.html)
[探索推荐引擎内部的秘密，第 2 部分: 深入推荐引擎相关算法 - 协同过滤](http://www.ibm.com/developerworks/cn/web/1103_zhaoct_recommstudy2/index.html)
[探索推荐引擎内部的秘密，第 3 部分: 深入推荐引擎相关算法 - 聚类](http://www.ibm.com/developerworks/cn/web/1103_zhaoct_recommstudy3/index.html)
**推荐两本书，如下：**
项亮：《推荐系统实践》
蒋凡：《推荐系统》
### 推荐系统是什么
推荐，就是把你可能喜欢的商品，推到你的面前。构建一个推荐系统，就是构建如何把商品推到你面前的过程。
经常有人说，推荐就是算法，从某种角度来说，这未尝不对。但在接触推荐系统之前，我们还是先不研究算法，一说到算法，可能就以为很高深了，也很唬人，立马产生一种膜拜之感，也就变得神秘起来了。
对于我们没有多少推荐理论支撑的工程师，进入推荐，还是先求入门。我们不缺实践，先通过工作中的实践领会某种推荐方案，再求通过阅读书籍、学习算法加深领会和理解，进而通过不同的推荐方案，以及其效果的客观评估，提高水平和境界。
第一步，当我们真正完完整整的接触到推荐系统，达到一个入门级水平，可以独立构建一个千万级PV网站的推荐系统之后，可能基本的观点会是：
（1）推荐是一个整体的计算过程，在编码中，关于算法的部分所占的工作量可能1%都不到；
（2）每一种推荐方案的选择，都是一种整体的计算过程。
构建一个千万PV级别的推荐系统相对容易，一天的日志不过几百M，计算过程中的数据，单台机器的内存可以存下，当PV达到几亿几十亿时，就需要进行稍微复杂一点的分布式计算了；
推荐的计算方法很多，如何选择，效果难以预料，只有通过横向和纵向多做效果分析，才有意义。
随着理解的加深，境界的提升，知识的更多了解，认知也都会处于不断的调整中。。。
### 推荐的计算过程
### 计算的数据来源
Web访问日志、购买、收藏，这些实际是用户的行为数据；
用户，这是分析的基础数据；
商品，这是分析的基础数据；
### 计划日志的存储格式
如何标记同一个未登陆用户；如何找出未登陆用户和登陆用户是用一个人。
这是很重要的，这是以后日志分析计算的基础。
**示例如下：**
27.189.237.91 - - [27/Jun/2014:15:00:01 +0800] "GET 某个URL HTTP/1.1" 200 75 "前一个URL" "95907011.390482691.1402709325.1403851977.1403852394.7" "95907011.8a8a8aeb385a8c6b013860df24501310" [- - -] [image/webp,*/*;q=0.8] "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36"
以上Web日志URL，95907011.390482691.1402709325.1403851977.1403852394.7 和 95907011.8a8a8aeb385a8c6b013860df24501310 ，使用google analysis的js代码记录的，分别用来标记未登录用户的ID和登录用户的ID。
对于google analysis的js代码的用途，这里衍生一下，实际上，完全可以基于它建立第三方的流量分析系统，流程如下：
（1）需要统计流量的网站进行查码，用来记录cookie等，并触发到服务器端的请求（可以是去请求一个不存在的图片）
（2）当服务器端接收到请求后，会把Head里面的网站访问流量相关信息进行记录，服务器端的程序是一个简单的Servlet即可。
### 计算过程第一步
根据用户行为数据，分析出用户和商品的关系；用户<-->浏览、用户<-->购买、用户<-->收藏等。
### 计算过程的第二步
根据第一步计算的数据，分析中常用的推荐结果，比如根据浏览数据，计算出“看了又看”，根据购买数据，计算出“买了又买”等。
### 计算过程的算法（或者叫规则）
算法，是广义的，数学公式；规则，是小众的，公司自己定义的，复杂自己场景的业务规则，在计算过程的第二步，计算最终的推荐结果时，大部分使用的都是自行定义的业务规则。
以推荐“看了又看”为例，根据一个商品，如何推荐出其他商品呢：
可以就根据这个推荐类型的基本含义，一个商品 ---> 看了这个商品的很多人，又看了 ---> 很多的商品，这就是推荐结果了，但是这个推荐结果有非常非常多，如何推荐呢？
可以推荐购买次数最终的，推荐最新的，推荐两个商品的View人群最相似的......
### 推荐结果的接口提供
这就没有什么了，都是通用的。
### 推荐系统的核心
基于业务的，推荐效果的评价体系；
基于技术的，大数据量时的分布式计算
### 代码说明
**前置项目：**这个相关项目就比较多了，网站、商品、订单，都有相关性。
**最新源码：**git clone git@github.com:pumadong/cl-recommend.git 。
### 推荐的发展
大数据量计算、数据流实时计算、用户行为精准分析、用户聚簇细化、个性化推荐等。
可能更高级别的搜索推荐，还是需要搜索推荐理论的支撑，不同于实现层面的东西，这个可能存在境界层次方面的不同，认知了才知道。。。
### 日志分析扩展和流量统计
对于日志的分析，可以统计网站的流量，但是要过滤掉对JS/CSS/IMG等静态资源的URL，只保留真实有效的访问。
在一个页面的访问过程中，浏览器会向服务器发起很多个请求，把HTML/CSS/IMG/JS等都下载下来，解析成美观的页面，展现给访问者，在这个过程中其实会在NGINX等Web服务器中，记录很多行日志。
关于流量统计，也有很多采用插码的方式，插码这种方式，业界的代码标准是Google的GA，插码的好处是可以统计记录更多信息（超出日志），可以自定义很多事件，收集更多信息。
当前google由于特殊原因国内不能直接访问，但是对于ga代码的统计是没有问题的，访问地址是：http://www.google-analytics.com/ga.js。
比较日志分析和插码两种方式，日志分析是有访问就记录日志，此时页面可能没展示完成访问者就关闭了；插码这种方式，只有执行到插入的JS代码的时候，才会记录流星；也就是前一种强调来过，后一种强调有效访问。
日志分析这种流量分析方式，需要过滤掉爬虫的IP地址；而插码就不需要，因为爬虫只会爬页面内容，并不会执行JS，JS的执行实际是浏览器的JS引擎帮我们做的。
另外，对于第三方的流量分析，则必须是插码，不可能使用日志分析。
官方网址：[https://support.google.com/analytics](https://support.google.com/analytics) 。