2026 年人工智能对建筑商的预测（赞助内容）
人工智能领域正在快速变化——到 2026 年，构建人工智能系统的方式将截然不同。
1 月 28日，我们将在线解读 Redis 2026 年预测报告的第一部分：为什么如果没有统一的上下文引擎，AI 应用将无法成功。
你将学到：
-
跨团队的人工智能架构标准
-
通过共享上下文基础架构降低运营开销
-
可预测的、生产级的性能
-
对代理数据访问进行清晰的可观察性和治理
-
加快人工智能新功能的上市速度
Netflix不再仅仅是一家流媒体服务公司。它已将业务拓展至现场活动、移动游戏和广告支持的订阅计划。这种转型带来了一个意想不到的技术挑战。
为了理解这一挑战，不妨考虑一下典型的会员体验流程。假设用户先在智能手机上观看《怪奇物语》，然后在智能电视上继续观看，最后在平板电脑上启动《怪奇物语》手机游戏。这些操作发生在不同的时间，使用不同的设备，并涉及不同的平台服务。然而，它们都属于同一个会员体验。
免责声明：本文基于 Netflix 工程团队公开分享的信息。如果您发现任何不准确之处，请留言。
理解这些跨域用户旅程对于打造个性化体验至关重要。然而，Netflix 的架构却使这一切变得困难。
Netflix 采用微服务架构，数百个服务由不同的团队开发。每个服务都可以独立开发、部署和扩展，团队可以根据自身需求选择最佳的数据存储技术。然而，当每个服务管理自己的数据时，信息就容易形成孤岛。视频流数据存储在一个数据库中，游戏数据存储在另一个数据库中，身份验证数据也单独存储。传统的数据仓库虽然收集这些信息，但数据最终会存储在不同的表中，并在不同的时间进行处理。
手动整合来自数十个孤立数据库的信息变得异常繁重。因此，Netflix 工程团队需要一种不同的方法来处理和存储相互关联的数据，同时还要实现快速查询。他们选择使用图表示法，原因如下：
-
首先，图可以实现快速的关系遍历，而无需昂贵的数据库连接。
-
其次，当出现新的连接时，图可以轻松适应，而无需进行重大的模式更改。
-
第三，图天然支持模式识别。与孤立的查找相比，使用图遍历来识别隐藏的关系和循环更为高效。
这促使 Netflix 构建了实时分布式图（RDG）。在本文中，我们将探讨 RDG 的架构以及 Netflix 在开发过程中面临的挑战。
构建数据管道
RDG由三层组成：摄取和处理、存储以及服务。请参见下图：
当会员在 Netflix 应用中执行任何操作（例如登录或开始观看节目）时，API 网关会将这些事件作为记录写入 Apache Kafka 主题。
Apache Kafka 作为数据摄取骨干，提供持久且可重放的数据流，供下游处理器实时使用。Netflix 选择 Kafka 是因为它能够以极低的延迟满足构建和更新数据图的需求。传统的批处理系统和数据仓库无法提供维护实时应用所需的低延迟数据图。
这些 Kafka 主题的数据流量规模巨大。例如，Netflix 的应用程序会使用多个不同的 Kafka 主题，每个主题每秒最多可生成一百万条消息。记录采用 Apache Avro 格式编码，模式则持久化存储在集中式注册表中。为了平衡数据可用性和存储基础设施成本，Netflix 会根据吞吐量和记录大小为每个主题定制数据保留策略。此外，他们还会将主题记录持久化到 Apache Iceberg 数据仓库表中，以便在 Kafka 主题中的旧数据过期时进行回填。
Apache Flink 作业从 Kafka 流中摄取事件记录。Netflix 选择 Flink 是因为它在近实时事件处理方面拥有强大的能力。此外，Netflix 内部平台对 Flink 也提供了强大的支持，这使得作业能够与 Kafka 和各种存储后端无缝集成。
RDG 流水线中的典型 Flink 作业遵循一系列处理步骤：
-
首先，该作业会从上游 Kafka 主题中消费事件记录。
-
接下来，它会根据事件中是否存在哪些字段，应用滤波和投影来消除噪声。
-
然后，它通过侧边输入存储和访问额外的元数据来丰富事件。
然后，该作业将事件转换为图原语，创建代表实体（如会员帐户和节目标题）的节点，以及代表它们之间关系或交互的边。
转换完成后，作业会在可配置的小时间窗口内缓存、检测并去重对相同节点和边的重叠更新。此步骤会降低下游发布的数据吞吐量，并使用有状态进程函数和定时器来实现。最后，作业会将节点和边记录发布到数据网格（Data Mesh），这是一个连接数据应用程序和存储系统的抽象层。
请看下图：
作为参考，Netflix 每秒向数据网格写入超过 500 万条记录，数据网格负责将这些记录持久化到数据存储中，供其他内部服务查询。
从失败中学习
Netflix 最初尝试使用一个 Flink 作业来消费所有 Kafka 主题。不同主题的数据量和吞吐量模式差异巨大，导致调优几乎不可能。于是他们转向了主题到作业的一对一映射。虽然这增加了运维开销，但每个作业的维护和调优都变得更加简单。
同样，每种节点和边类型都有其专属的 Kafka 主题。虽然这意味着需要管理更多主题，但 Netflix 非常重视能够独立调整和扩展每个主题的能力。他们将图数据模型设计得非常灵活，因此很少会添加新的节点和边类型。
存储挑战
在通过会员互动创建了数十亿个节点和边之后，Netflix 面临着如何实际存储它们的关键问题。
RDG 使用属性图模型。节点代表实体，例如会员账号、头衔、设备和游戏。每个节点都有一个唯一的标识符和包含附加元数据的属性。边代表节点之间的关系，例如开始观看、登录地点或播放次数。边也具有唯一的标识符和时间戳等属性。
请看下图：
当会员观看某个节目时，系统可能会创建一个帐户节点，其中包含创建日期和计划类型等属性；创建一个标题节点，其中包含标题名称和运行时长等属性；以及一条开始观看边，将它们连接起来，其中包含上次观看时间戳等属性。
这种简单的抽象使得 Netflix 能够展现其生态系统中极其复杂的会员旅程。
传统图数据库为何失败
Netflix 工程团队评估了 Neo4j 和 AWS Neptune 等传统图数据库。虽然这些系统在原生图查询支持方面提供了丰富的功能，但它们在可扩展性、工作负载和生态系统方面存在诸多挑战，使其无法满足 Netflix 的需求。
-
原生图数据库难以横向扩展以处理大型实时数据集。其性能通常会随着节点和边的数量或查询深度的增加而下降。
-
在早期的评估中，Neo4j 在处理数百万条记录时表现良好，但由于内存需求高、分布式能力有限，处理数亿条记录时效率低下。
-
由于 AWS Neptune 采用单写入多读取架构，因此也存在类似的局限性，这在实时摄取大量数据时（尤其是在跨多个区域）会出现瓶颈。
这些系统本身也并非为应对 Netflix 运营所必需的持续、高吞吐量事件流工作负载而设计。它们经常难以处理涉及完整数据集扫描、基于属性的过滤和索引的查询模式。
对 Netflix 而言，最重要的是，与图数据库相比，该公司拥有更强大的内部平台支持关系型数据库和文档型数据库。非图数据库的操作也更加便捷。Netflix 发现，在现有数据存储系统中模拟类似图的关系比采用专门的图基础设施更为简单。
KVDAL解决方案
Netflix 工程团队采用了其内部数据网关平台中的键值数据抽象层 (KVDAL)。KVDAL 基于 Apache Cassandra 构建，无需直接管理底层存储即可提供高可用性、可调一致性和低延迟。
请看下图：
KVDAL 采用两级映射架构。数据被组织成记录，每个记录由一个唯一的记录 ID 标识。每条记录包含已排序的项，其中项是一个键值对。要查询 KVDAL，您可以按 ID 查找记录，然后可以选择按键筛选项。这既能实现高效的单点查找，又能灵活地检索相关数据。
对于节点，唯一标识符即为记录 ID，所有属性都存储在一个单独的项中。对于边，Netflix 使用邻接表。记录 ID 代表源节点，而项则代表与其连接的所有目标节点。如果一个帐户观看过多个影片，则邻接表会为每个影片创建一个项，其中包含时间戳等属性。
这种格式对于图遍历至关重要。为了查找会员观看过的所有影片，Netflix 会通过一次 KVDAL 查询来检索整个记录。他们还可以使用键值筛选来按特定影片进行筛选，而无需获取不必要的数据。
管理数据生命周期
当 Netflix 摄取实时流时，KVDAL 会为新的节点或边创建新记录。如果一条边的起点已存在但终点已更改，则会在现有记录中创建一个新项。当多次摄取同一节点或边时，KVDAL 会覆盖现有值，从而保持时间戳等属性的最新状态。KVDAL 还可以按命名空间、记录或项自动设置数据过期时间，从而在限制图增长的同时提供精细的控制。
命名空间实现大规模扩展
命名空间是 Netflix 利用的 KVDAL 最强大的功能。命名空间就像数据库表，是对记录进行逻辑分组，它定义了物理存储，同时抽象了底层系统细节。
您可以先将所有命名空间都放在同一个 Cassandra 集群上。如果某个命名空间需要更多存储空间或流量容量，您可以将其迁移到单独的集群进行独立管理。不同的命名空间可以使用完全不同的存储技术。低延迟数据可以使用带有 EVCache 缓存的 Cassandra。高吞吐量数据可以使用每个命名空间专用的集群。
KVDAL 可扩展至每个命名空间处理数万亿条记录，延迟仅为个位数毫秒级。Netflix 为每种节点类型和边缘类型都配置了独立的命名空间。虽然这看似有些过度，但它实现了独立的扩展和调优、每个命名空间灵活的存储后端，以及运维隔离，确保一个命名空间的问题不会影响其他命名空间。
结论
这些数据展现了实际性能。Netflix 的图拥有超过 80 亿个节点和 1500 亿条边。该系统每秒可支持约 200 万次读取和 600 万次写入。它运行在一个拥有约 27 个命名空间的 KVDAL 集群上，并由分布在 2400 个 EC2 实例上的约 12 个 Cassandra 集群提供支持。
这些数字并非限制。每个组件都呈线性扩展。随着架构的增长，Netflix 可以添加更多命名空间、集群和实例。
Netflix 的 RDG 架构提供了重要的借鉴意义。
-
有时候，正确的解决方案并非显而易见。Netflix 本可以使用专门构建的图数据库，但出于运营方面的考虑，例如内部专业知识和现有平台支持，他们选择使用键值存储来模拟图数据库的功能。
-
扩展策略是通过实验不断演进的。Netflix 最初使用 Flink 构建的单体作业失败了。他们最终通过实践发现，尽管增加了复杂性，但一对一的主题-作业映射效果更好。
-
规模化应用中，隔离性和独立性至关重要。将每种节点和边类型分离到各自的命名空间中，可以实现独立调优，并缩小问题的影响范围。
-
基于成熟的基础设施进行开发会带来丰厚的回报。Netflix 没有采用全新的系统，而是利用了 Kafka、Flink 和 Cassandra 等久经考验的技术，构建抽象层来满足自身需求，同时受益于这些技术的成熟度和运营经验。
RDG 使 Netflix 能够分析其不断扩展的生态系统中的会员互动情况。随着业务发展和新产品的推出，这种灵活的架构可以进行调整，而无需进行重大架构重构。
参考：
赞助我们
让您的产品触达超过 100 万名科技专业人士。
我们的新闻简报会将您的产品和服务直接推送给重要的受众——数十万名工程领导者和高级工程师——他们对重大的技术决策和大宗采购具有影响力。
名额有限，立即预订！
广告位通常提前约 4 周售罄。为确保您的广告触达这一极具影响力的受众群体，请立即发送电子邮件至[email protected] 预订您的广告位。
原文： https://blog.bytebytego.com/p/how-netflix-built-a-real-time-distributed