麦包包也看到了个性化推荐：数据驱动销售——个性化推荐引擎

作者简朝阳，麦包包技术保障部总监，Oracle ACE，擅长MySQL和Oracle数据库应用系统的性能调优与高可用可扩展架构设计。曾就职于阿里巴巴，参与多个核心数据库应用系统的设计与实施，负责MySQL数据库应用系统的架构设计与相关维护。

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

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

 

图1 数据层基础架构

 

 

数据层基础架构

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

• 在线交易数据层

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

• 离线分析数据层

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

• 在线分析数据层

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

个性化推荐引擎

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

• 关联个性化

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

• 页面个性化

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

• 搜索个性化

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

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

• 海量

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

• 多维度

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

• 访问高并发

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

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

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

• 用户固定属性：年龄、性别、职业类型、地域、价格承受范围、色彩喜好、品牌喜好等。

• 产品固定属性：品牌、类别、材质、价格、色系等。

• 用户以往行为：浏览历史、购买历史等。

• 用户当前行为：当前点击、浏览等。

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

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

 

图2 推荐引擎基本架构

 

架构设计

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

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

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

• MySQL更便于维护与备份等运维需求。

• NoSQL不满足我们的一些分析型查询需求。

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

图3 推荐引擎整体架构

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

• 前端应用产生用户的浏览日志、购买日志、搜索日志以及用户及产品属性数据进入。

• 通过文件日志收集程序以及基于MySQL开放复制协议所定制的数据同步工具（注：在我的个人网站上有介绍：http://isky000.com/database/mysql-replication-extend）将数据同步至离线分析系统中。

• 通过离线任务的统计分析，得出会员的各种喜好属性，并将之与产品属性进行关联分析，得出一个用户产品倾向性关联结果，然后再通过应用程序定期从离线分析系统将上述分析结果写入在线合并分析数据库中。

• 推荐引擎根据前端应用（如Search）传入的用户当前运行时操作属性，与在线合并分析数据库中属性进行合并（Merge），再过滤（Filter）。

• 前端应用从推荐引擎处获取Merge与Filter之后的数据，再在前端页面上完成展现。

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

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

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

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

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

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