百分点个性化推荐引擎的学习
一、百分点的主要特点
1、用户全网兴趣偏好平台
满足针对用户全网兴趣偏好进行精准分析，打通用户在多个网站的兴趣偏好。
个人点评：全网数据指的是所有目前与其合作的网站的的数据，从目前合作的规模看，目前与百分点合作的大型网站没有几个，其他的都是些冷门的网站。对于一些大型网站，处于商业信息的保密，基本上不会将此部分数据与其他网站共享。
2、互联网用户的兴趣图谱
浏览和收藏代表用户的偏好，购买行为则最贴近用户的真实需求，通常在互联网上完成购买行为越多的用户，他的兴趣展示越充分。
3、海量消费偏好挖掘能力
在群体智慧与复杂网络领域的多年耕耘让百分点科技拥有海量消费偏好挖掘能力，确保每次送达的精准性和时效性。
个人点评：以上信息均为百分点公司商业介绍资料，具体算法是什么，具体效果有多少不得而知。
二、N年前的百分点
以下资料来自百分点2010年公开下载的文档。
百分点推荐引擎提供了三项基于客户的个性化推荐和四项常规推荐。
三项个性化推荐包括：
- 基于顾客购物车的推荐
- 基于顾客浏览历史的推荐
- 基于顾客购买历史的推荐
四项常规推荐包括：
- 浏览过本商品的顾客还浏览过什么
- 购买过本商品的顾客还购买了什么
- 浏览过本商品的顾客最终购买了什么
- 经常与本商品一起购买的商品是什么
个人点评：三项个性化推荐为数据来源，对于普通的网站来说基本上都能实现。四项常规推荐中第一、第二点在先前的文章中已经介绍过了。 推荐系统之Also Buy和Also View的实现。第三种情况为决策性推荐，和第四种组合推荐在技术是实现上也没有难度。
三、百分点的前端实现
有两种方法可以帮助您在购物页面上嵌入百分点推荐引擎的推荐栏：
1、基于JavaScript 的实现方式，需要在多个页面中 嵌入百分点的JavaScript 代码：
①通过“产品展示页面”上传商品信息和发送推荐请求；
②通过“购买确认页面”上传商品购买记录。
2. 直接调用webservice 接口，详情请参见API 文档 购物网站需要上传商品信息（比如商品 ID，商品名称，商品价格，商品链接等信息） 到百分点服务器。
个人评价：百分点在做跨浏览器、跨站时采用了Flash Cooike技术，这点可以学习，具体Flash Cookie的介绍如下:
用户数据跟踪之Flash Cookies
四、百分点的系统架构
1、百分点需要实现的需求
- 科学高效的推荐算法，并且根据网站特点选择最佳的推荐算法和推荐策略；
- 根据用户的全网行为分析他们的潜在偏好，帮助网站实现站内站外精准营销；
- 根据全网的商品和资讯信息分析各种内容之间的相关度，帮助网站优化站外流量导入工作。
2、百分点需要解决的技术要求
- 支持各种推荐算法和科学衡量指标。研究人员们已经提出了数百种推荐算法以及相应的标准数据集和推荐效果衡量指标，百分点推荐引擎必须足够灵活以便能够支持这些算法。明确每种算法在各个数据集上的性能指标，以便为具体需求选择合适的推荐算法。
- 大数据处理。面对全网资源和用户行为，如何安全可靠的存储和分析这些数据是非常关键的。最低要求是每天能够处理1亿级别的数据输入和推荐请求，并且保证数据绝对安全。分布式和云服务是唯一的选择。
- 高可用性和实时性。作为一个Web Service提供商，提供稳定可靠低延时的服务是基本要求，从用户体验角度出发，要求每个推荐请求都能在2ms内处理完成。
- 可扩展性。这是所有计算机系统的普遍需求，我们要求百分点推荐引擎可以很方便的添加各种新的推荐逻辑，提供新的推荐服务。并且当整个系统需要升级扩容的时候，人力和硬件成本是线性可控的。
- 便于管理。运维是Web Service的重头戏，我们要求百分点推荐引擎中的各个部件（或逻辑单元）都是独立可拆卸可替换的，每个部件都要有完善的容灾备份恢复机制，这样整个系统的管理工作逐步细分，有利于分工协作。
3、百分点架构图
百分点推荐引擎可以分为存储层，业务层，算法层和管理层四大功能组件。每个组件内部又可以细分为更小的单元，或者服务模块，提供基本的存储或运算服务。单元与单元之间尽量解耦和，仅通过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掉并重新启动，因为很可能是该进程出现异常了。
参考文章： http://www.infoq.com/cn/articles/baifendian-recommendation-engine
Related posts:
- Flickr API 中的URL规则
- 当当网：从搜索到发现
- 《结网》PDF下载