zoukankan      html  css  js  c++  java
  • 推荐系统--揭开推荐的神奇面纱


    开篇


    先推荐几篇关于推荐的文章,个人感觉对于入门非常有实际意义,是IBM的project师写的,例如以下:

    探索推荐引擎内部的秘密,第 1 部分: 推荐引擎初探

    探索推荐引擎内部的秘密,第 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引擎帮我们做的。

    另外,对于第三方的流量分析,则必须是插码,不可能使用日志分析。

  • 相关阅读:
    第44月第9天 iOS开发-illegal text-relocation错误解决
    第44月第8天 高可用 zookeeper
    第44月第7天 bitcode 生成各机型的包
    第44月第6天 iOS静态库冲突 framework瘦身
    第44月第5天 VMware centos7并配置网络 git-for-windows
    第44月第2天 解决MySQL报错:1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated column 'informat
    第43月第29天 rtp分包
    第43月第28天 libyuv裁剪
    label不换行的问题
    解决scrollview不滚动
  • 原文地址:https://www.cnblogs.com/mengfanrong/p/4374737.html
Copyright © 2011-2022 走看看