推荐系统--揭开推荐的神奇面纱
开篇
先推荐几篇关于推荐的文章，个人感觉对于入门非常有实际意义，是IBM的project师写的，例如以下：
探索推荐引擎内部的秘密，第 2 部分: 深入推荐引擎相关算法 - 协同过滤
探索推荐引擎内部的秘密，第 3 部分: 深入推荐引擎相关算法 - 聚类
推荐两本书，例如以下：
项亮：《推荐系统实践》
蒋凡：《推荐系统》
推荐系统是什么
推荐，就是把你可能喜欢的商品，推到你的面前。构建一个推荐系统，就是构建怎样把商品推到你面前的过程。
常常有人说，推荐就是算法，从某种角度来说，这未尝不正确。但在接触推荐系统之前，我们还是先不研究算法，一说到算法，可能就以为非常高深了，也非常唬人，立刻产生一种膜拜之感，也就变得神奇起来了。
对于我们没有多少推荐理论支撑的project师，进入推荐，还是先求入门。我们不缺实践，先通过工作中的实践领会某种推荐方案，再求通过阅读书籍、学习算法加深领会和理解，进而通过不同的推荐方案，以及其效果的客观评估，提高水平和境地。
第一步，当我们真正完完整整的接触到推荐系统，达到一个入门级水平，能够独立构建一个千万级PV站点的推荐系统之后，可能主要的观点会是：
（1）推荐是一个总体的计算过程，在编码中，关于算法的部分所占的工作量可能1%都不到；
（2）每一种推荐方案的选择，都是一种总体的计算过程。
构建一个千万PV级别的推荐系统相对easy，一天的日志只是几百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等，并触发到server端的请求（能够是去请求一个不存在的图片）
（2）当server端接收到请求后，会把Head里面的站点訪问流量相关信息进行记录，server端的程序是一个简单的Servlet就可以。
计算过程第一步
依据用户行为数据，分析出用户和商品的关系；用户<-->浏览、用户<-->购买、用户<-->收藏等。
计算过程的第二步
依据第一步计算的数据，分析中经常使用的推荐结果，比方依据浏览数据，计算出“看了又看”，依据购买数据，计算出“买了又买”等。
计算过程的算法（或者叫规则）
算法，是广义的，数学公式；规则，是小众的，公司自定义的，复杂自己场景的业务规则，在计算过程的第二步，计算终于的推荐结果时，大部分使用的都是自行定义的业务规则。
以推荐“看了又看”为例，依据一个商品，怎样推荐出其它商品呢：
能够就依据这个推荐类型的基本含义，一个商品 ---> 看了这个商品的非常多人，又看了 ---> 非常多的商品，这就是推荐结果了，可是这个推荐结果有非常非常多，怎样推荐呢？
能够推荐购买次数终于的，推荐最新的，推荐两个商品的View人群最相似的......
推荐结果的接口提供
这就没有什么了，都是通用的。
推荐系统的核心
基于业务的，推荐效果的评价体系；
基于技术的，大数据量时的分布式计算
代码说明
前置项目：这个相关项目就比較多了，站点、商品、订单，都有相关性。
最新源代码：git clone git@github.com:pumadong/cl-recommend.git 。
推荐的发展
大数据量计算、数据流实时计算、用户行为精准分析、用户聚簇细化、个性化推荐等。
可能更高级别的搜索推荐，还是须要搜索推荐理论的支撑，不同于实现层面的东西，这个可能存在境地层次方面的不同，认知了才知道。。。
日志分析扩展和流量统计
对于日志的分析，能够统计站点的流量，可是要过滤掉对JS/CSS/IMG等静态资源的URL，仅仅保留真实有效的訪问。
在一个页面的訪问过程中，浏览器会向server发起非常多个请求，把HTML/CSS/IMG/JS等都下载下来，解析成美观的页面，展现给訪问者，在这个过程中事实上会在NGINX等Webserver中，记录非常多行日志。
关于流量统计，也有非常多採用插码的方式，插码这样的方式，业界的代码标准是Google的GA，插码的优点是能够统计记录很多其它信息（超出日志），能够自己定义非常多事件，收集很多其它信息。
当前google因为特殊原因国内不能直接訪问，可是对于ga代码的统计是没有问题的，訪问地址是：http://www.google-analytics.com/ga.js。
比較日志分析和插码两种方式，日志分析是有訪问就记录日志，此时页面可能没展示完毕訪问者就关闭了；插码这样的方式，仅仅有运行到插入的JS代码的时候，才会记录流星；也就是前一种强调来过，后一种强调有效訪问。
日志分析这样的流量分析方式，须要过滤掉爬虫的IP地址；而插码就不须要，由于爬虫仅仅会爬页面内容，并不会运行JS，JS的运行实际是浏览器的JS引擎帮我们做的。
另外，对于第三方的流量分析，则必须是插码，不可能使用日志分析。
