Netflix推荐系统(Part two)-系统架构

Netflix在2013年公布了本身推荐系统的架构，本文主要总结和翻译自System Architectures for Personalization and Recommendation，但这并非一篇完整的翻译文章。

Overview

首先，咱们在下图中提供推荐系统的总体系统图。 该体系结构的主要组件包含一个或多个机器学习算法。

计算能够被online，nearline或者offline完成。 online计算能够更好地响应最近的事件和用户交互，但必须实时响应请求。这会限制所采用的算法的计算复杂性以及能够处理的数据量。offline计算对数据量和算法的计算复杂性的限制较少，由于它以批量方式运行且具备宽松的时序要求。个性化架构中的关键问题之一是如何以无缝方式组合和管理在线和离线计算。近线计算是这两种模式之间的中间折衷，咱们能够在其中执行相似在线的计算，但不要求它们实时提供。模型训练是另外一种计算形式，它使用现有数据生成模型，该模型稍后将在实际计算结果期间使用。该体系结构的另外一部分描述了事件和数据分发系统如何处理不一样类型的事件和数据。相关问题是如何组合离线，近线和在线制度所需的不一样信号和模型。最后，咱们还须要弄清楚如何以对用户有意义的方式组合中间推荐结果。本文的其他部分将详细介绍此体系结构的这些组件及其交互。Netflix的整个基础架构都在Amazon Web Services云上运行。

Computation

Online计算能够快速响应事件并使用最新数据。 一个示例是使用当前context为action movie gallery排序。 联机组件受可用性和响应时间服务级别协议（SLA）的约束，该协议指定响应来自客户端应用程序的请求的进程的最大延迟。 这使得在复杂且计算成本高的算法难以在online service中使用。 此外，纯粹的在线计算在某些状况下可能没法知足其SLA，所以考虑快速回退机制（例如恢复到预先计算的结果）很重要。 online计算还意味着所涉及的各类数据源也须要在线提供，这可能须要额外的基础设施。

Offline计算容许使用更复杂的算法和更多的数据一个简单的例子多是按期汇总数百万电影播放事件的统计数据，以计算baseline的流行度指标。离线系统也有更简单的工程要求。例如，能够轻松知足客户施加的宽松响应时间SLA。能够在生产中部署新算法，而无需在性能调优上投入太多精力。这种灵活性支持敏捷创新。Netflix利用这一点来支持快速实验：若是新的实验算法执行速度较慢，咱们能够选择简单地部署更多Amazon EC2实例来实现运行实验所需的吞吐量，而不是花费宝贵的工程时间来优化性能对于可能被证实具备很小商业价值的算法。可是，因为脱机处理没有强大的延迟要求，所以它不会对上下文或新数据的更改作出快速反应。这可能会下降用户体验。离线计算还须要具备用于存储，计算和访问大量预先计算结果的基础结构。

Nearline计算能够看做是前两种模式之间的折衷。Nearline计算是响应于用户事件而完成的。

在任何状况下，online/nearline/offline均可以并且应该结合起来。有不少方法能够将它们组合在一块儿。咱们已经提到了使用离线计算做为后备的想法。另外一种选择是使用离线过程预先计算部分结果，并留下算法中成本较低的部分或者上下文敏感的部分用于online计算。 甚至建模部分也能够以混合离线/在线方式完成。传统的监督分类应用必须从标记数据批量训练分类器，而且在线进行预测。可是，矩阵分解等方法更适合混合在线/离线建模：某些因素能够离线预先计算，而其余因素能够实时更新以建立更新鲜的结果。其余无监督方法（例如cluster）还容许cluster center的离线计算和cluster的在线分配。

Offline Jobs

offline jobs的主要内容是数据统计和模型的离线训练，这些内容一般以batch为单位完成。 这两个任务都须要处理数据，这一般是经过运行数据库查询生成的。因为这些查询会运行大量数据，它们适合以分布式方式经过Hive或Pig做业在Hadoop上运行。查询完成后，咱们须要一种机制来发布结果数据。咱们对该机制有几个要求：首先，它应该在查询结果准备好时通知订阅者。其次，它应该支持不一样的存储库（不只是HDFS，还有S3或Cassandra）。最后，它应该透明地处理错误，容许监视和警报。Netflix使用一个名为Hermes的内部工具，从某种意义上说，它涵盖了与Apache Kafka相同的一些用例，但它不是消息/事件队列系统。

Signals & Models & Event & Data

不管咱们是在进行在线仍是离线计算，咱们都须要考虑算法如何处理三种输入：model，data和signal。 Model一般是先前已离线培训的参数的小文件。 Data是先前处理的信息，已存储在某种数据库中，例如电影元数据或流行度。 咱们使用术语“signal”来指代咱们输入算法的新信息。 该数据从实时服务得到，而且能够由用户相关信息（例如，成员最近观看的内容）或诸如会话，设备，日期或时间的上下文数据构成。

Netflix尝试区别event和data。他们将事件视为时间敏感信息的小单位，须要以尽量少的延迟进行处理，以触发后续操做或过程，例如更新nearline结果集。另外一方面，他们将数据视为可能须要处理和存储以供之后使用的更密集的信息单元。这里的延迟并不像信息质量和数量那么重要。固然，有些用户事件能够被视为事件和数据，所以被发送到两个流。

Recommendation Results

Netflix将offline和intermediate结果存储在各类存储库中，以便稍后在请求时使用：他们使用的主要数据存储是Cassandra，EVCache和MySQL。每种解决方案都有其优势和缺点。

MySQL容许存储结构化关系数据，这些数据多是经过通用查询进行的某些将来过程所必需的。可是，这种通用性是以牺牲分布式环境中的scalability为代价的。 Cassandra和EVCache都提供了键值存储的优点。当须要分布式和可扩展的无SQL存储时，Cassandra是一个众所周知的标准解决方案。 Cassandra在某些状况下运行良好，但EVCache更适合密集和持续的写操做。