数据驱动销售——个性化推荐引擎

标签: 推荐技术 | 发表时间:2013-02-18 07:28 | 作者:黄言之
出处:http://blog.sina.com.cn/netreview

在当前这个信息量飞速增长的时代,一个企业,尤其是电子商务企业的成功已经越来越多地与其海量数据处理能力相关联。高效、迅速地从海量数据中挖掘出潜在价值并转化为决策依据的能力,将成为企业的核心竞争力。

数据的重要性毋庸置疑,但随着数据的产生速度越来越快,数据量越来越大,数据处理技术的挑战自然也越来越大。如何从海量数据中挖掘出价值所在,分析出深层含义,进而转化为可操作的信息,已经成为各互联网企业尤其是电子商务公司不得不研究的课题。本文将介绍国内箱包行业电子商务领军者麦包包如何利用海量数据的分析处理(个性化推荐引擎)来协助用户更好地完成购买体验。

图1 数据层基础架构
图1 数据层基础架构

数据层基础架构

如图1所示,麦包包的数据层基础架构与其他很多互联网公司相比,可能会有一点儿差异,那就是有一个用于实时分析处理的在线分析数据层,用来处理一些对实时性要求较高的分析任务。
总的来说,麦包包的数据层分为下面三个部分。

  • 在线交易数据层

用于存放网站对外访问数据,如交易相关、产品相关、用户相关等数据。

  • 离线分析数据层

用于分析各种报表、数据挖掘,如购买行为、销售分析、浏览跟踪等。

  • 在线分析数据层

用于处理一些对实时性要求较高的分析,如在线交易分析、用户浏览推荐等。在线交易数据层和离线分析数据层对于大家来说都已经比较熟悉了,二者的数据特点和访问特点都很清晰明确,架构方向也相对明确。只有在线分析系统比较特别,既有高并发的用户访问,同时又兼具了分析型复杂查询及海量的基础数据,构建起来相对要复杂一些。所以下面简单介绍一下麦包包如何构建在线分析系统的应用之一——“个性化推荐引擎”。

个性化推荐引擎

我们首先分析一下这个推荐引擎的需求。

  • 关联个性化

根据用户的喜好倾向以及访问历史记录,不同用户浏览同一个产品时,将给出不同的关联推荐结果。

  • 页面个性化

不同用户访问同一个页面,我们将会根据用户的以往购买历史及浏览行为而展示个性化的内容。

  • 搜索个性化

随着用户的多次搜索及结果点击行为,我们会对搜索结果进行过滤重组,尽可能展示更符合用户需求的搜索结果。也就是说,在完全相同的基础数据中,不同用户在同一时间搜索同一个关键词,可能会给出不一样的结果;或者同一个用户重复多次搜索同一个关键词,也可能会有不一样的结果。

我们再来看一看推荐引擎的数据特点。

  • 海量

超过500万会员,5位数的SKU,7位数的访问量。将这些数据与会员及SKU的各类属性相互关联,数据量之庞大可想而知。

  • 多维度

从性能优化角度来说,数据量大并不可怕,只要访问方式简单,很容易通过索引等手段进行优化。可偏偏不幸的是,由于将用户和产品进行多维度关联,既需要根据用户去分析,又需要根据产品去关联,再辅以运行时的各类属性;既可能各个维度同时存在,也可能只有任何一个维度;多维度就多维度吧,可还有很多访问是分析型,比较难以优化扩展。

  • 访问高并发

当然,数据量大也并不一定就可怕,如果并发访问较小,响应时间要求不是太高,那也容易解决,可以用Hadoop之类的分布式系统来分析计算。可恰恰不巧的就是这个系统面对的是网站上的访问客户,对并发及响应时间的要求和OLTP系统一样。

需求已经确定,数据特点也已了解,下一步就是根据数据的特点,设计一个切实可行的架构来实现这些应用需求了。

在如此 海量数据中进行 高并发复杂分析查询,还要能够快速响应,看上去就像是一个不可能的任务。但仔细分析之后,我们不难发现,推荐引擎结果主要由以下几个因素决定。

  • 用户固定属性:年龄、性别、职业类型、地域、价格承受范围、色彩喜好、品牌喜好等。
  • 产品固定属性:品牌、类别、材质、价格、色系等。
  • 用户以往行为:浏览历史、购买历史等。
  • 用户当前行为:当前点击、浏览等。

以上四个因素实际上对应了四种数据,在分析每一种数据的特点之后,可以发现前面三个因素所对应的数据都是相对静态的,只有用户当前行为才是一个在不断变化的动态数据。也就是说,在海量数据中,只有少部分数据是动态的,其他大部分都是静态。
当然,用户属性中的各种喜好,也需要我们通过用户以往的历史购买以及浏览行为进行各种分析挖掘才能获得,但这都是由历史积淀数据分析得来,而不是由当前的运行时动态数据决定。价格承受范围以及地域特性也同样如此。

数据的这一特性对我们的架构设计起到了一个非常关键的作用,因为我们可以使用完全不同的方式来将静态数据和动态数据分开处理,再合并分析。静态数据的变化较小,实时性要求较低,我们将进行离线分析;动态数据相对较少,但实时性要求较高,我们在线实时处理。动、静数据在线合并分析。这样一来,我们就可以很轻松地绕过海量数据的高并发在线分析的问题,将这一动作交由离线分析系统定时作业批量完成,既不会有高并发问题,又不存在响应时间的压力。至于在线实时数据的处理,由于数据量的大幅缩减,以及访问方式的简化,比在线交易的OLTP系统复杂度高不了太多,自然也就容易优化了。

图2 推荐引擎基本架构
图2 推荐引擎基本架构

架构设计

简单来说,推荐引擎系统本身的基础架构就如图2所展现的一样,一部分数据进行离线计算,另一部分数据在线计算合并,最终通过推荐引擎API将数据处理后返回给前端应用。

看上去简单,但有几个问题并没有展现出来,那就是离线计算和在线计算这两部分具体是如何构建的?数据如何进入离线计算系统?又如何将离线运算结果回送至在线计算系统中?最终数据又如何交由前端应用使用?让我们再来看看图3。

离线分析层完全可以通过成熟的产品来构建,如Greenplum、Hadoop等,目前我们已经使用了Greeplum,后续很快还会引入 Hadoop,通过HBase + Hive来对处理我们的用户与各SKU的关系数据,帮助进一步完善我们的协同过滤算法,进而优化推荐引擎。在线合并分析层我们选择MySQL数据库。可能有些人会问,为什么不使用当前如此流行的NoSQL产品呢?主要原因有以下两点。

  • MySQL更便于维护与备份等运维需求。
  • NoSQL不满足我们的一些分析型查询需求。

NoSQL产品虽然流行,但每种产品都还只适于某些特定的应用场景,很多听上去完美的理论目前暂时还仅仅只是听上去完美,实际用起来仍然存在各种各样的问题。所以我们选择了更适合于我们的MySQL作为在线合并分析层的数据库。

图3 推荐引擎整体架构

图3 推荐引擎整体架构

整个架构的数据流,如图3所示。

  • 前端应用产生用户的浏览日志、购买日志、搜索日志以及用户及产品属性数据进入。
  • 通过文件日志收集程序以及基于MySQL开放复制协议所定制的数据同步工具(注:在我的个人网站上有介绍:http://isky000.com/database/mysql-replication-extend)将数据同步至离线分析系统中。
  • 通过离线任务的统计分析,得出会员的各种喜好属性,并将之与产品属性进行关联分析,得出一个用户产品倾向性关联结果,然后再通过应用程序定期从离线分析系统将上述分析结果写入在线合并分析数据库中。
  • 推荐引擎根据前端应用(如Search)传入的用户当前运行时操作属性,与在线合并分析数据库中属性进行合并(Merge),再过滤(Filter)。
  • 前端应用从推荐引擎处获取Merge与Filter之后的数据,再在前端页面上完成展现。

以上就是整个推荐引擎的数据流架构方案,乍一看也没有太多特别的内容,但在实际实施过程中,会遇到以下几个难点。

  • 各种日志传输到离线分析系统,如何做到尽可能实时并不影响在线系统。

这个难点,我们首先在每一个页面部署监测点,通过请求一个gif图片来获得用户的各种浏览信息,并存入到MySQL数据库,交易相关的数据自然也会有在数据库中进行存储。然后使用通过扩展MySQL复制协议而实现的日志解析合并程序,实时解析 MySQL日志,再将其以我们需要的格式传输至离线分析系统中进行分析运算。

  • 如何将用户的运行时操作属性与我们的离线分析结果进行Merge及Filte。

这个难点,实际上在6月刊的《程序员》杂志对麦包包首席架构师盛国军的采访稿中,已经有了相应的介绍。我们主要使用了基于用户(User)、商品(Item)、话题(Topic)以及曝光(Exposure)这四种协同过滤技术,来实现推荐算法。

总的来说,数据量的增长,以及分析需求的越来越复杂,将会对互联网公司的数据处理能力提出越来越高的要求、越来越大的挑战。但每一个场景都有其特性,充分分析其数据特性,将合适的软件用在合适的场景下,才能更好地解决实际问题。

 

全文转载自: http://isky000.com/database/data-drive-sale-recommendation


  青春就应该这样绽放   游戏测试:三国时期谁是你最好的兄弟!!   你不得不信的星座秘密

相关 [数据 销售 mdash] 推荐:

数据驱动销售——个性化推荐引擎

- - 互联网旁观者
在当前这个信息量飞速增长的时代,一个企业,尤其是电子商务企业的成功已经越来越多地与其海量数据处理能力相关联. 高效、迅速地从海量数据中挖掘出潜在价值并转化为决策依据的能力,将成为企业的核心竞争力. 数据的重要性毋庸置疑,但随着数据的产生速度越来越快,数据量越来越大,数据处理技术的挑战自然也越来越大.

大数据的秘密——社会化媒体的开放之路

- - 微博之博
大数据可以说是近来年最火热的一个话题. 微博等社交化媒体因其独特的开放性特征,也成为大数据利用最令人关注的领域. 而这两年,随着微博、微信等社交平台商业化尝试的深入,及其结果的不尽如人意,大数据的利用成为了一个能否实现商业化实质突破的关键点. 而这个点的关键又在于 社交平台是否能做到对大数据的真正开放.

拿数据说话—一位首席产品架构师的体悟

- - 互联网旁观者
孙云丰2004年进入百度,从之前普通的包装材料推销员变身成为百度的产品经理. 通过之后8年的努力,他最终跃升为百度首席产品架构师,并成为代表最核心团队的“fellow”级人物. 这归功于他每天花十几个小时与搜索引擎的产品和用户习惯打交道,让自己成为不折不扣的“网虫”. 现在百度用户体验部已经有190多名员工,而其他研究、开发、运营的人员同样也是提升用户体验的一分子.

关于深度学习——Deep Learning

- - 互联网旁观者
转载自: http://blog.csdn.net/abcjennifer/article/details/7826917. Deep Learning是机器学习中一个非常接近AI的领域,其动机在于建立、模拟人脑进行分析学习的神经网络,最近研究了机器学习中一些深度学习的相关知识,本文给出一些很有用的资料和心得.

社交搜索——百度知道,不如你我知道

- - 微博之博
本篇文章作者王德超,程序员一枚,创业在路上,微博@哀木涕啊. 当你想订购一台吐司机的时候,你会去哪儿寻找参考信息. 我想大概有许多人像我一样,习惯了使用Google 、百度或者Bing. 但他们真的会给我们最需要的答案吗. 作为一名使用微博3年以上的老围脖,突然发现自己在搜索答案时出现了另一个习惯.

软件架构设计(二)——软件架构设计过程

- - BlogJava-首页技术区
      一般来讲,涉众包括客户(资方)代表、承接方(劳方)代表、用户代表.       对于要明确实现某种标准的软件系统,通常确定边界非常容易,直接按标准圈定的scope分析即可,比如像SIPServlet容器,是要求遵从JSR168规范的,那么软件系统的Scope就是JSR168规定的Scope,但是也有例外,比如客户或者劳方明确指定要复用一个现有的实现了部分功能的系统或组件,那么Scope就不同了.

软件设计之UML—UML中的六大关系

- - BlogJava-首页技术区
在UML类图中,常见的有以下几种关系: 泛化(Generalization), 实现(Realization),关联(Association),聚合(Aggregation),组合(Composition),依赖(Dependency). 1.1、 继承关系—泛化(Generalization). 指的是一个类(称为子类、子接口)继承另外的一个类(称为父类、父接口)的功能,并可以增加它自己的新功能的能力,继承是类与类或者接口与接口之间最常见的关系;在Java中用extends关键字.

卫报:一场关于三星平板销售数据的争论

- Yibie - 爱范儿 · Beats of Bits
在三星(Samsung)推出自己的 Android 平板产品 Galaxy Tab 之后两个月,他们宣称出货量达到了 100 万台,其中大本营韩国市场已经售出 10 万台,而且高调宣布 2010 年的总目标是 150 万台. 有媒体认为 Galaxy Tab 的出现是 iPad 面临的第一个对手,三星在 2011 年 1 月时表示“销量远远超出预期”,进展“相当顺利”.

美博客称Android平板电脑销售数据存在水份

- 洞箫 - cnBeta.COM
市场调研机构的数据称,今年第三季度Android平板电脑已经占据了27%的全球市场份额,但是美国科技博客GigaOM认为,这一数据存在很大的水份. 上周五,市场调研公司Strategy Analytics发布报告称,今年第三季度全球平板电脑市场出货总量达到1670万部,苹果iOS和谷歌Android设备占据了94%的市场份额,其 中苹果iPad的出货总量为1110万部,占据67%的市场份额,Android平板电脑的出货总量为450万部,市场份额攀升到了27%.

库存销售规划分析之番外篇——也谈数据系统

- - i天下网商
零售公司发展进入成熟期之后,需要考虑盈利的问题,而不是全力利用资本市场进行融资,这时就需要实现成熟的库存销售规划分析体系,以保证利润率、库存率、销售库存比等因素. 随着对国内零售电商后台的库存销售规划分析系统的进一步了解,我觉得目前零售电商应该向国外同行学习的不是如何做数据分析,而是首先应该考虑,在公司日益发展、营收日益稳定的情况下,怎样建立一个成熟的库存销售规划分析系统,由最合适的团队来正确解读分析数据,从而更精确地指导未来的产品销售、库存和市场策略.