需求
当下，个性化时代的潮流势不可挡，业界普遍意识到了推荐是网站的一项基本服务。但是，人们对推荐该如何来做，也就是推荐技术本身，还不甚了解。我们经常会遇到这样的疑问：“购买过该商品的用户还购买过哪些商品这种推荐，不是一个SQL语句就搞定了吗？”其实不然，推荐技术远远不是这么简单。广义上讲，推荐技术属于数据挖掘和机器学习范畴，这也意味着好的推荐服务依赖于科学的推荐算法和大量的学习数据。对于电子商务和资讯网站来讲，想在推荐技术领域精耕细作，研发高端的推荐算法并应用到海量数据上是非常困难的。正是在这样的背景下，百分点推荐引擎应运而生。在百分点推荐引擎产品的开发过程中，我们与麦包包、红孩子、走秀网、耀点100等知名电子商务网站，以及天极网、亿邦动力等知名媒体资讯类网站的技术部门进行了深入探讨，从他们那里得到了很多帮助与启发。在与这些行业先锋的交流中我们发现，有一些需求是行业共有的，比如推荐的实时性、高可用性。另外一些需求是行业性的，比如婴幼儿用品的单品重复购买率比较高，但相同的包包的重复购买率就不算高。对于一位正在育儿的母亲，我们可以给她重复推荐符合她们偏好的、相同的奶粉和尿片，但对于一位时尚的女孩，我们向她重复推荐相同的包包可能就不合适了。
经过广泛的市场需求和交流，我们要求百分点推荐引擎能够从方方面面支持客户的市场营销策略，概括的讲主要包括：
- 科学高效的推荐算法，并且根据网站特点选择最佳的推荐算法和推荐策略；
- 根据用户的全网行为分析他们的潜在偏好，帮助网站实现站内站外精准营销；
- 根据全网的商品和资讯信息分析各种内容之间的相关度，帮助网站优化站外流量导入工作。
百分点推荐引擎面对的是全网的商品资讯信息以及用户行为，如何科学有效的利用这些数据为电子商务和资讯网站提供丰富的推荐服务，满足其推广营销目标，成为了我们最大的技术挑战。为此我们对百分点推荐引擎提出了以下技术要求：
- 支持各种推荐算法和科学衡量指标。研究人员们已经提出了数百种推荐算法以及相应的标准数据集和推荐效果衡量指标，百分点推荐引擎必须足够灵活以便能够支持这些算法。而且我们要明确每种算法在各个数据集上的性能指标，以便为具体需求选择合适的推荐算法。
- 大数据处理。面对全网资源和用户行为，如何安全可靠的存储和分析这些数据是非常关键的。我们的最低要求是每天能够处理1亿级别的数据输入和推荐请求，并且保证数据绝对安全。显然，分布式和云服务是我们唯一的选择。
- 高可用性和实时性。作为一个Web Service提供商，提供稳定可靠低延时的服务是基本要求，我们从用户体验角度出发，要求每个推荐请求都能在2ms内处理完成。
- 可扩展性。这是所有计算机系统的普遍需求，我们要求百分点推荐引擎可以很方便的添加各种新的推荐逻辑，提供新的推荐服务。并且当整个系统需要升级扩容的时候，人力和硬件成本是线性可控的。
- 便于管理。运维是Web Service的重头戏，我们要求百分点推荐引擎中的各个部件（或逻辑单元）都是独立可拆卸可替换的，每个部件都要有完善的容灾备份恢复机制，这样整个系统的管理工作逐步细分，有利于分工协作。
架构设计
根据上节提出的需求，我们将百分点推荐引擎设计为一组云服务的有机组合，如上图，百分点推荐引擎可以分为存储层，业务层，算法层和管理层四大功能组件。每个组件内部又可以细分为更小的单元，或者服务模块，提供基本的存储或运算服务。单元与单元之间尽量解耦和，仅通过API协议进行协作，这样一个单元的升级变动带来的影响是可控的。每个单元都要做到可靠可用。下面，我们全面介绍百分点推荐引擎四大功能组件。
存储层
存储层提供基本的数据存取服务，并做好备份和灾难恢复工作，以保证数据的安全可靠。根据不同的应用需求，存储层细分为Redis集群，Membase集群，MySQL集群和Hadoop/HDFS四类。
- Redis集群。百分点推荐引擎采用了Redis作为缓存，用于存储热门数据，包括资源（商品或者咨询）ID，名称，链接，图片，分类，品牌等。这些信息数量不算非常多，但是使用频率非常高，基本上我们的每次推荐都要用到数十甚至数百个商品信息。之所以选用Redis，我们看重的是它的速度，持久化和以及主从机制。目前，我们使用Redis的方式是一个Master带若干个Slaves以便实现读写分离，Master只负责写，Slaves只负责读，其中两个Slave有序列化机制，并且必定有两个Slave在不同的机器上以消除单点故障隐患。
- Membase集群。Membase在百分点推荐引擎中扮演了主存的角色，主要用于支持百分点推荐引擎的计算。目前，百分点推荐引擎包含了大大小小十多个在线和离线计算模块，这些模块计算过程中需要用到很多数据，并产生以及大量的中间结果，包括用户在各个网站的行为历史，资源之间的关系等等。这些数据的特点是不需要Schema，数量多，但绝大多的使用频率很低。之所以选用Membase，主要原因是因为它可以很方便的进行横向扩展以及有丰富的Client API支持。
- MySQL集群。在百分点推荐引擎的最初阶段，我们赋予MySQL的主要任务是存储所有客户的原始数据（包括用户行为，推荐请求及推荐结果等）以作备份之用，并在后期统计推荐效果。但很快我们就发现MySQL数据库变得极其庞大，以至于每周都需要对其进行压缩备份和切割，运维工作量太大。现在，我们已经将数据备份和后期统计工作转移到了Hadoop/HDFS平台，只在MySQL中存储最终的统计数据以及其他客户配置信息等小规模的数据。由于MySQL的任务量不重，我们仅对其做了双机热备以避免单机崩溃造成无法继续服务。
- Hadoop/HDFS。正如前面所说，目前我们使用Hadoop/HDFS来存储客户的原始数据，并在其上做一些统计处理。另外，我们也在计划将一些离线算法和数据转移到Hadoop平台上以便发挥Hadoop的潜力。Hadoop的NameNode存在单点故障隐患，为此我们为建立了一个备份的NameNode，并在主服务器出现问题时将服务切换至备份服务器上。
算法层
这是百分点推荐引擎最核心也是最具挑战性的部分，我们将这一层设计为一系列抽象算法的集合。我们深入研究了学术界在基于用户行为的推荐算法，基于内容的推荐算法和关联规则等多方面的理论知识，在此之上自主研发了十多种适用于大数据处理的在线和离线推荐算法。目前，我们的在线算法包括协同过滤（UserBased/ItemBased CF），基于内容的推荐（Content Based），热扩散（Heat Diffusion），用户行为模式分析（Behavior PatterAnalysis）等等。离线算法包括KNN聚类，基于FP Tree的关联规则挖掘，基于上下文统计的关联规则挖掘，序列模式算法，文档建模算法等等。
算法层并不关心具体的业务逻辑，而只负责数据处理和结果返回。以热扩散算法为例，一方面它接受（用户，资源，偏好指数）的三元组作为计算输入，实时计算用户与用户/资源之间的关系；另外，我们也可以向它请求某个用户对哪些资源最感兴趣，或者某个资源与哪些资源最相关。
将业务逻辑和推荐算法本身剥离这样的设计方式使得推荐算法具有了最大的通用性，也保证了前端的推荐功能模块可以根据逻辑需求综合多个算法。以百分点推荐引擎的“基于浏览历史的个性化推荐”为例，它就使用到了热扩散和基于内容的推荐两种算法。
得益于存储和算法的分离，算法层并不需要考虑数据的备份容灾等问题。这样，如果某个算法模块由于服务器故障出现异常，我们可以很快在另外的服务器上启动同一个它的一个备份来替换它，而不涉及任何数据迁移问题，最大限度满足了可用性。
业务层
这是百分点推荐引擎中直接面对客户的部分，也就是我们的HTTP Web Service，它主要负责两件事：收集客户提交的数据，并将其转换为各个推荐算法需要的输入数据，交由推荐算法计算；根据客户提交的推荐请求，向一个或几个推荐算法请求数据，并转换为客户需要的数据格式。可以看出，业务层起到了连接具体需求与推荐算法，真实世界与计算机世界之间的作用。
以“购买过该商品的用户还购买过哪些商品”为例，我们来简介这个推荐功能模块是如何沟通客户需求和推荐算法。目前我们主要采用热扩散算法来实现这个推荐功能模块。首先，客户提交购买数据时，百分点推荐引擎会根据一定的业务逻辑将这个事件处理为算法可以接受的三元组。例如用户U购买了商品K，我们可能会向算法发送一个输入数据(U, K, 1.0)。其次，当客户请求买过K的用户还买过哪些商品时，我们一方面以K作为参数向算法请求与K最相近的资源；另一方面如果客户提交了用户ID，我们还会向算法请求该用户可能感兴趣的商品；最后我们将两个结果加权整合，挑选其中权重最大同时满足客户额外需求（例如过滤用户的购买历史，按照商品类别/价格过滤等）的几个商品作为最终推荐结果。
可见，业务层完全将推荐算法作为黑盒子来使用，这样业务层就可以集中注意力满足客户多种多样的需求。另外，同算法层一样，业务层也无须关心数据的存储备份和容灾。
管理层
在百分点推荐引擎中，管理层负责内部DNS，配置管理，服务部署，服务监控和自动应急处理。
- 内部DNS是实现高可用性的重要环节。百分点推荐引擎的各个组件都是通过内部域名访问其他服务的，所有服务器的主次DNS也都设置成了内部DNS。这样，当有关键的服务器，例如Hadoop的NameNode，出现故障时，我们可以通过修改域名对应的IP保证服务不间断。
- 配置管理。这个模块的主要功能是实现配置的自动化更新和通知。我们曾经考虑过用Zookeeper来实现这一功能，但后来觉得Zookeeper太过重型，于是自己根据自己的需求开发了一个配置管理服务。百分点推荐引擎的内部服务可以将自己注册在配置管理的某个项目下，在改配置项变动时，配置管理模块会通知该服务以便其获得最新的配置信息。
- 服务监控。这个模块主要用于监控服务器的健康状况，各个进程是否能够正常提供服务，并在出现异常情况时执行短信报警和触发自动应急处理。我们的方法包括：
- 通过top，ps，free等一些基本工具来查看系统负载以及各个进程是否存活，CPU，Memroy等资源占用情况。利用redis-cli，memstats等特定工具来查看Redis，Membase的运行状况。
- 对于自主开发的程序，我们都要求提供一个可供测试的调用，这个调用可以走完主要的服务流程，并返回执行流程中是否出现异常，例如配置项设置错误，执行流程超时等等。
- 我们会对各个服务输出的LOG进行分析，找出异常状况。例如短期内出现大量EXCEPTION或者ERROR，请求处理时间超长，大量推荐请求得不到结果等等。
- 监控模块一旦检测到异常情况，会立即短信通知我们的运维人员，并通知自动应急处理模块尝试修复异常。
- 自动应急处理。我们在自动应急模块中实现了修改DNS配置，启动/停止业务层服务程序和推荐算法的功能。举个例子，当MySQL主服务器宕机时，自动应急模块会收到来自监控模块的通知，而后它会尝试修改将主从DNS中的MySQL服务器域名修改为MySQL从服务器的IP；又或者如果自动应急模块收到监控模块的通知说业务层某个服务进程在连续的1分钟内一直占用了100%的CPU，应急模块会将它kill掉并重新启动，因为很可能是该进程出现异常了。
小结
本文较为细致的介绍了百分点推荐引擎的总体架构和功能划分，不难看出，在整个架构设计中，我们一直坚持模块化，低耦合，消除单点等原则，力求将百分点推荐引擎打造成扩展性和可靠性极佳的推荐技术平台。经过近两年的多个大中型电子商务合作网站的实践检验，这套架构完全满足了我们一开始提出的各项需求，而且在可见的未来内，它也足以胜任百分点推荐引擎的战略规划。这套架构在稳定性和灵活性等多方面体现了出了百分点推荐引擎团队在推荐技术和服务上积极的努力耕耘和领先的技术。
