架构设计

　　简单来说，推荐引擎系统本身的基础架构就如图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及Filte。

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

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