第一部分：创建关于印象的真相来源

作者: Tulika Bhatt

想象你在 Netflix 上浏览，每一张电影海报或推广横幅都在抢夺你的注意力。你鼠标悬停过的每一幅图像不只是一个视觉占位符，它们是驱动我们个性化引擎的关键数据点。在 Netflix，我们把这些图像称为“印象”，简称“印象”。它们在将浏览体验转变为个性化沉浸式追剧体验方面发挥关键作用，这一切都是根据你独特的口味量身打造的。

捕捉这些时刻并将它们转化为个性化的旅程绝非易事。这需要一个先进的系统来跟踪和处理这些印象，并保持每个资料的曝光记录的详细记录。这种数据和技术的细微整合使我们能够提供个性化的内容推荐。

在这个多部分博客系列中，我们将带您深入了解我们每天处理数十亿次印象的系统的幕后情况。我们将探讨我们遇到的挑战和问题，并揭秘我们如何构建一个稳健的解决方案，将这些客户端的印象转化为每个Netflix观众的个性化的内容发现体验。

首页给我的感觉

为了更有效地个性化推荐，跟踪用户已经看过的内容非常重要。拥有浏览记录有助于我们通过识别已经在首页展示但未被用户互动的内容，从而实现这一目标，提供新鲜且吸引人的内容推荐。

通过记录用户的印象历史，我们可以实施频率限制，以防止用户过度暴露于相同内容。这确保用户不会反复看到相同的内容选项，保持观看体验的新鲜感，并减少用户因厌倦或无聊而脱离的风险。

对于新内容，用户互动记录帮助我们监控用户初次互动，并据此调整我们的营销方式。我们可以通过尝试不同的内容展示方式或促销策略来提高关注度和参与度。

此外，印象历史提供了很多有关平台相关分析查询的有用信息。分析印象历史可以帮助我们评估特定主页行的表现，或者评估销售策略的有效性。

管理印象的第一步是从创建一个源数据真相集（SOT，Source-of-Truth的简称）开始。这个基础数据集非常重要，因为它支持各种下游工作流程并适用于多种应用场景。

当我们的用户在探索 Netflix 平台时，他们与用户界面的互动会产生大量原始数据。这些数据会迅速从客户端发送到我们的服务器，进入一个集中的事件处理队列中。这个队列确保我们能够持续收集来自全球用户的原始数据。

当原始事件被收集到集中队列后，自定义事件提取器会处理这些数据，以识别并提取所有的曝光事件。提取出的事件随后会被路由到一个Apache Kafka主题，以满足即时处理需求的满足，同时也会被存储到一个Apache Iceberg表中，以实现长期保留和历史分析的目的。这种方法使用了双路径，利用了Kafka的低延迟流处理能力和Iceberg对大规模、不可变数据集的有效管理，确保了实时响应能力以及全面的历史数据可用性。

收集原始感知数据

一旦原始印象事件被加入队列后，一个无状态的Apache Flink任务开始处理这些数据。它会过滤掉所有无效条目，并为有效条目补充额外的元数据，比如节目或电影的标题信息，以及具体的页面和行位置，每个印象在用户面前显示的位置。经过处理的数据将按照Avro模式进行结构化，从而成为Netflix印象数据的标准来源。这些增强的数据可以通过Kafka供实时应用访问，也可以存储在Apache Iceberg表中以供历史分析使用。这种双管齐下的可用性确保了即时处理能力与全面长期数据保留的兼顾。

关于单一事实来源的印象

保持最高质量的印象是我们的重要任务。我们通过收集详细的列级指标来实现这一目标，这些指标涵盖从验证标识符到确保必要列正确填充的各个方面。收集的数据会输入到一个全面的质量仪表盘，并支持分层阈值警报系统，这些警报及时通知我们任何潜在问题。这些警报会及时通知我们任何潜在问题，使我们能够迅速解决问题。此外，在丰富数据的同时，我们确保各个列之间的一致性，并在可能的情况下提供就地修正，确保数据的准确性。

仪表盘显示实体ID和视频ID间的不匹配计数

我们每秒在全球范围内处理高达100万到150万次的展示事件，每次事件大约1.2KB。为了高效实时处理如此庞大的数据流，我们采用了Apache Flink，利用其低延迟的流处理功能，该功能能够无缝集成批处理和流处理，从而实现历史数据的高效回溯，并确保实时分析与历史分析的一致。我们的Flink配置每个区域包含8个任务管理器，每个任务管理器拥有8个CPU核心和32GB的内存，并行度设置为48，这使我们能够处理所需的规模和速度，以实现无缝的性能交付。Flink作业的输出端配备了数据网平台连接器，详情请参阅我们关于数据网平台的文章，该平台有两个输出选项：Kafka和Iceberg。此配置允许实时数据通过Kafka高效流式传输，并将历史数据保存在Iceberg中，从而提供全面且灵活的数据处理和存储方案。

每秒原始数据记录数

我们采用“岛屿模型”来部署Flink作业，其中特定应用的所有依赖位于同一区域内。这种方法通过隔离各个区域确保高可用性，因此，如果某个区域出现问题，其他区域不受波及，可以将流量在各个区域间转移以保证服务的连续性。因此，该区域内的所有数据均由部署在该区域的Flink作业进行处理。

允许原始事件未经结构化地进入我们的集中处理队列提供了很大的灵活性，但也带来了一些挑战。没有定义的模式，很难判断缺失的数据是故意的还是由于日志错误。我们正在研究解决方案，以引入既能保持灵活性又能提供清晰度的模式管理方法。

我们目前手动调整 Apache Flink 作业的性能。下一步是将自动扩展器集成到系统中，自动扩展器可以根据工作负载需求动态调整资源。这种集成不仅会优化性能，还会提高资源利用效率。

目前有很多业务规则规定了数据质量警报需要在何时触发。这导致了大量误报，需要人工干预。很多时候由于缺乏足够的数据血缘信息，追踪导致回归的变化变得困难。我们正在建立一个全面的数据质量平台，该平台能够更智能地识别数据流中的异常，跟踪数据血缘，实施数据治理，并生成警报，通知生产者任何回归。这种方法将提高效率，减少人工干预，并确保更高的数据完整性标准。

创建一个可靠的印象数据源是一项复杂但必不可少的任务，它能增强个性化和发现过程。敬请期待本系列的下一篇，我们将深入探讨如何利用这个SOT数据集（即源数据集）来创建一个提供印象历史记录的微服务。欢迎您在评论区分享您的看法，并继续与我们一同探索印象的旅程。

我们真的很感谢为“印象”项目的成功做出重要贡献的出色同事：Julian Jaffe，Bryan Keller，Yun Wang，Brandon Bremen，Kyle Alford，Ron Brown和Shriya Arora。