Netflix应用架构之用于个性化和推荐的系统架构

无论我们是在线计算还是离线计算，我们都需要考虑算法将如何处理三种输入:模型、数据和信号。模型通常是之前离线训练的参数的小文件。数据是预先处理的信息，这些信息已经存储在某种数据库中，比如电影元数据或流行度。我们使用"信号"这个术语来指代我们输入到算法中的新信息。这些数据来自live services，可以由用户相关的信息(如成员最近观看了什么)或上下文数据(如会话、设备、日期或时间)组成。

Event & Data Distribution

我们的目标是将成员交互数据转换为可用于改进成员体验的洞察力。因此，我们希望Netflix的各种用户界面应用程序(智能电视、平板电脑、游戏机等)不仅能提供令人愉快的用户体验，还能收集尽可能多的用户事件。这些操作可以与任何时候的单击、浏览、查看，甚至是视图的内容相关。然后可以聚合事件，为我们的算法提供基本数据。在这里，我们试图在数据和事件之间做出区分，尽管边界肯定是模糊的。我们认为事件是时间敏感信息的小单元，需要以尽可能少的延迟处理。这些事件被路由来触发后续的操作或过程，例如更新近线结果集。另一方面，我们认为数据是更密集的信息单元，可能需要处理和存储以便稍后使用。在这里，延迟并不像信息的质量和数量那么重要。当然，有些用户事件可以同时作为事件和数据处理，因此可以发送到两个流。

在Netflix，我们近乎实时的活动流程是通过一个名为Manhattan的内部框架来管理的。曼哈顿是一个分布式计算系统，它是我们推荐算法体系结构的核心。这有点类似于Twitter的Storm，但它解决了不同的问题，并响应了不同的一组内部需求。数据流主要通过从Chukwa到Hadoop的日志记录来管理，以完成流程的初始步骤。稍后，我们使用Hermes作为发布-订阅机制。

推荐结果

我们机器学习方法的目标是提出个性化的建议。这些推荐结果可以直接从我们之前计算过的列表中得到，也可以通过在线算法动态生成。当然，我们可以考虑同时使用这两种方法，离线计算推荐的大部分内容，并使用使用实时信号的在线算法对列表进行后处理，从而增加一些新鲜度。

在Netflix，我们将离线和中间结果存储在各种存储库中，以便稍后在请求时使用:我们使用的主要数据存储库是Cassandra、EVCache和MySQL。每种解决方案都有其优缺点。MySQL允许存储结构化关系数据，这些数据将来可能需要通过通用查询进行处理。然而，这种通用性是以分布式环境中的可伸缩性问题为代价的。Cassandra和EVCache都提供了键值存储的优点。当需要分布式和可伸缩的无sql存储时，Cassandra是一个著名的标准解决方案。Cassandra在某些情况下工作得很好，但是在我们需要密集且持续的写操作的情况下，我们发现EVCache更适合。然而，关键问题不在于将它们存储在哪里，而在于如何以一种相互冲突的目标(如查询复杂性、读写延迟和事务一致性)在每个用例的最优点上满足的方式处理需求。

结论

在以前的文章中，我们强调了数据、模型和用户界面对于创建世界级推荐系统的重要性。在构建这样一个系统时，还必须考虑将在其中部署该系统的软件体系结构。我们希望能够使用复杂的机器学习算法，可以增长到任意的复杂性，并能够处理大量的数据。我们还需要一个允许灵活和敏捷创新的体系结构，在这个体系结构中可以轻松地开发和插入新方法。此外，我们希望我们的推荐结果是新鲜的，并快速响应新的数据和用户操作。在这些需求之间找到最佳平衡点并非易事:它需要对需求进行深思熟虑的分析，仔细选择技术，并对推荐算法进行战略性分解，从而为我们的成员实现最佳结果。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!