为企业做网站策划案,大学校园网站模板图片,专业集团门户网站建设公司,黑龙江省建设集团有限公司网站Netflix在2013年公布了自己推荐系统的架构#xff0c;本文主要总结和翻译自System Architectures for Personalization and Recommendation#xff0c;但这并不是一篇完整的翻译文章。 Overview 首先#xff0c;我们在下图中提供推荐系统的整体系统图。 该体系结构的主要组件…Netflix在2013年公布了自己推荐系统的架构本文主要总结和翻译自System Architectures for Personalization and Recommendation但这并不是一篇完整的翻译文章。 Overview 首先我们在下图中提供推荐系统的整体系统图。 该体系结构的主要组件包含一个或多个机器学习算法。 计算可以被onlinenearline或者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 无论我们是在进行在线还是离线计算我们都需要考虑算法如何处理三种输入modeldata和signal。 Model通常是先前已离线培训的参数的小文件。 Data是先前处理的信息已存储在某种数据库中例如电影元数据或流行度。 我们使用术语“signal”来指代我们输入算法的新信息。 该数据从实时服务获得并且可以由用户相关信息例如成员最近观看的内容或诸如会话设备日期或时间的上下文数据构成。 Netflix尝试区别event和data。他们将事件视为时间敏感信息的小单位需要以尽可能少的延迟进行处理以触发后续操作或过程例如更新nearline结果集。另一方面他们将数据视为可能需要处理和存储以供以后使用的更密集的信息单元。这里的延迟并不像信息质量和数量那么重要。当然有些用户事件可以被视为事件和数据因此被发送到两个流。 Recommendation Results Netflix将offline和intermediate结果存储在各种存储库中以便稍后在请求时使用他们使用的主要数据存储是CassandraEVCache和MySQL。每种解决方案都有其优点和缺点。 MySQL允许存储结构化关系数据这些数据可能是通过通用查询进行的某些未来过程所必需的。但是这种通用性是以牺牲分布式环境中的scalability为代价的。 Cassandra和EVCache都提供了键值存储的优势。当需要分布式和可扩展的无SQL存储时Cassandra是一个众所周知的标准解决方案。 Cassandra在某些情况下运行良好但EVCache更适合密集和持续的写操作。
