Netflix 技术博客

RSS: https://netflixtechblog.com/feed

Netflix 工程技术博客，分享工程实践、产品文化与架构经验。

Nexflix: Workload Attestation on Managed Compute

收藏4 天前

用云身份换取你自己的：托管计算上的工作负载证明

Netflix 描述在 Amazon EMR 托管计算上为 Apache Spark 工作负载建立内部身份的机制。核心难题：托管环境只给进程一个 AWS IAM 身份，但内部服务需要自己的第一类身份。设计要点：每个 Data Project（数据所有权单元）映射到一个专用 IAM 角色；控制平面生成并签署工作负载元数据；驱动端插件利用 execution role 凭证生成预签名 URL 作为"持有证明"；身份服务将 AWS STS 的陈述与控制平面签名做交叉验证，再签发短期 X.509 证书。关键设计决策：应用身份取自签名的元数据而非从角色名推导，避免脆弱的字符串匹配。还讨论了 executor fan-out 问题和单账号无法承载数万角色的分片方案。

收藏5 天前

把 classpath 留在后视镜里：Netflix 发布基于 Java 模块系统的新一代 CLI 工具 ja

引入可组合、模块系统原生且代理友好的命令行工具，用于现代 Java 开发作者：Danny Thomas，JVM生态系统团队最近对Java语言的研究它使得使用完整语言和平台启动并进化 Java 程序变得前所未有的容易。在这条入口的尽头，是 Java 成熟的构建与依赖管理生态系统，能够将软件承载到极其大规模和复杂的规模。该生态系统通过开发强有力的项目、依赖和构建模型而达到成熟。当这些模型已经为开发者提供了极佳的服务。模块描述符因此成为项目的另一种描述，需要保持一致。我们很高兴宣布预览以及其可组合工具家族，这些工具基于 Java 模块系统的能力，提供现代命令行开发体验。我们将模块描述符变成项目的完整描述，依赖版本自然地置于需求指令和通过文档标签提供的模块元数据旁边：<pre>/** * @mainClass com.example.application.Main */ module com.example.application { requires com.example.framework; // @1.2.3 }</pre>再加上你在其他语言中习惯的命令行人体工学设计，创建和使用Java模块从未如此简单。<h3>可组合工具</h3>Java开发者长期以来一直非常依赖图形工具。IDE格式化源代码，在声明和使用之间导航，呈现API文档，并维护项目的编译视图。这种体验非常完整，以至于Java几乎…

收藏12 天前

Netflix规模化多模态资产个性化实践

Netflix用CLIP和MediaFM多模态嵌入解决推荐系统冷启动问题，将艺术品和视频预览的个性化提前到内容上线初期。用CLIP图像嵌入替代纯ID嵌入，使模型能"看懂"资产内容，跨画布共享信号，将5个独立模型合并为1个统一模型。查询感知排名直接利用CLIP的文本-图像共享空间，无需额外建模。MediaFM融合视觉、音频和字幕信号，优于仅用帧的SeqCLIP。用线性探针作为新嵌入的快速筛选机制，避免每次全量A/B测试。

收藏25 天前

Netflix大规模多模态资产个性化系统MAPS

Netflix用CLIP图像嵌入解决推荐系统中的冷启动问题，将5个独立模型合并为1个统一模型。新上线内容的素材无需积累交互数据即可立即个性化推荐，因为CLIP嵌入在创建时已携带视觉语义信息。通过奖励加权平衡不同画布的数据分布，用逆倾向评分做离线评估。

收藏33 天前

Netflix 的双 Flink 自动扩缩容实践：从自建到开源的迁移之路

,以及如今，Netflix运行着两台Flink自动缩放器。这正好比我们想要的多一个。我们多年前就自己建了第一台，当时还没有适合我们平台的成熟方案。 第二个来自Apache Flink社区，它能够扩展我们自制系统从未设计过的工作负载。我们现在两者都在生产环境中运行，并且正稳步向开源版本汇聚。 在这个过程中，我们学到了关于指标、成本以及维护基础设施的实际成本的严峻经验教训，我们希望无论你运行的是少数几个Flink项目还是数万个项目，这些经验都能有所帮助。<h2>为什么在我们这个尺度上，自动缩放不是可选的</h2>Netflix 自 2017 年起就在 Apache Flink 上运行流处理。截至2026年，我们在多个AWS区域运营超过3万个Flink任务。大多数不是手动部署;它们由我们的托管平台生成，所以大多数用户从未直接接触过Flink的任务。 较少但不断增长的部分是定制工作，由公司各团队为个性化、广告和现场活动等用例开发和运营。它们从单操作员作业（在Kafka主题间穿梭记录）到有状态的流水线（包含分支、连接和状态数，以及每日周期、启动和区域故障切换）的负载波动。为高峰期提供所有这些岗位是浪费;平均配置会导致浪涌期间的延迟。在我们的平台上，缩放动作并非免费：默认情况下，它意味着取一个存档点，优雅地停止工作，然后以新大小重启，而对于大型有状态作业来说，这可能需…

收藏40 天前

Netflix 用 gRPC 查询实时分布式图：亚百毫秒延迟的设计抉择

Netflix 构建了实时分布式图（RDG），在数十亿节点和边的规模下将查询延迟控制在 100ms 以内。采用广度优先遍历替代深度优先，用 16-24 个线程通过异步组合处理数千并发请求。缓存策略按数据变化频率分层，稳定数据缓存命中率达 70-80%。外部元数据按需获取，服务不可用时降级返回图数据本身。

收藏52 天前

Netflix如何构建实时分布式图（第三部分）：查询层设计

Netflix工程师分享实时分布式图查询层设计，采用广度优先遍历和异步执行实现sub-100ms延迟。系统支持两种查询模式：浅而宽的账户设备查询和深而窄的观看历史追踪。通过邻接列表、流式读取和选择性缓存，处理数十亿节点和边的查询。

收藏53 天前

Netflix 如何构建实时分布式图（三）：用 gRPC 查询图

Netflix 技术博客第三篇，介绍实时分布式图（RDG）的查询层设计。核心决策：用广度优先而非深度优先遍历，避免分布式环境下多次网络调用累积延迟；采用异步非阻塞架构，16-24 个线程处理数千并发请求；按数据变更频率分层缓存，稳定属性用 EVCache 带 TTL，频繁变化的边数据不缓存。查询延迟目标 sub-100ms，支撑账号-设备-内容等多跳遍历场景。

收藏54 天前

Netflix 设备能力建模：用数据驱动功能投放决策

由、、、提供Netflix 拥有丰富且不断演进的各类功能与内容，从 4K 流媒体和沉浸式音效，到直播流媒体和云游戏，覆盖了多元化的设备生态系统。 然而，并非所有设备都是一样的。硬件限制，例如可用内存、CPU 核心数、显示能力或平台支持等因素，意味着某些功能在特定的设备型号上可能无法得到支持。 为了确保用户获得最佳的使用体验，我们深入理解每款设备的能力。我们投入大量资源，构建了全面的设备能力数据模型，并将内部系统的功能标志进行整合，为在全球范围内实现更智能、更精细的功能管理铺平了道路。 这一方法有助于我们识别功能普及过程中的瓶颈，并加速创新步伐。我们精心设计了数据存储与建模策略，以高效支持大规模分析。我们采用累积表来处理设备各项能力的相关信息。该表结构合理，能够高效地捕捉每台设备的最新状态及其所关联的能力（如屏幕分辨率、视频格式支持、环绕声、内存大小等），因此非常适合用于分析与报表生成等应用场景。<pre>{ "屏幕高度": ["720"], "屏幕宽度": ["1280"], "视频格式": [ "playready", "hevc", ], }</pre>对于聚合分析，我们利用了一个直方图表，该表记录了过去 28 天内各设备的活跃数量，并按设备型号和软件版本进行了细分。此外，该表还记录了支持特定功能的设备数量，从而实现了对设备分布情况的细致分析。 直方图…

收藏61 天前

Netflix 推出 GenRec：基于大语言模型的推荐系统新范式

作者：,,<h2>简介</h2>推荐是Netflix体验的核心。我们当前的生产模型依赖于数千个手工打造的功能，覆盖用户、物品和交互，以及专门的序列建模、特征交互和多任务目标架构。 该技术栈经过多年发展，支持多样化的内容类型（电影、剧集、游戏、直播、播客）和产品表面，但其复杂性使得引入新用例成本高昂：添加内容类型或表面可能需要大量特征工程、架构变更、基础设施工作和实验。与此同时，大型语言模型（LLM）正在改变我们对推荐的看法，正如近期研究所示,，和.他们广泛的世界知识和强大的语言理解，使得用户历史和项目元数据能够直接以文本形式呈现，在共享语义空间中捕捉丰富的关系，并通过自然语言提示引导推荐。 然而，现成的大型语言模型仍远未达到生产级推荐：它们常常过度推荐全球热门内容，误导目录外的商品，忽视业务限制，且仅提供有限的个性化服务。为此，我们建立了GenRec，一个基于LLM支持的推荐排名器，用于针对Netflix特定数据和目标进行内部基础LLM的后期训练。GenRec 表明，基于 LLM 的排名器可以在依赖更少标记样本和输入信号的情况下，匹配甚至超越成熟的生产系统。图1：GenRec 流水线。用户历史、商品元数据和上下文的原始日志通过上下文工程转化为自然语言提示，并输入GenRec，GenRec以仅预填充模式运行于vLLM上，为每个目录项目输出评分，从而生成推…

收藏62 天前

规模化构建服务拓扑图：架构、挑战与经验教训

Netflix 分享构建实时服务依赖拓扑图的工程实战。针对大规模流量，采用流式处理而非批处理，利用背压机制防止数据丢失。核心创新在于三阶段分布式聚合管道：解决网络中间件（如负载均衡器）导致的链路断裂问题，通过重哈希将相关流量汇聚到同一节点解析。文章详细记录了生产环境中的痛点，如Kafka消费延迟、热点节点导致的GC停顿和内存溢出，以及通过动态一致性哈希实现自动负载均衡的经验。适合对分布式系统架构、可观测性基础设施和大规模数据处理感兴趣的工程师。

收藏71 天前

规模化构建服务拓扑：架构、挑战与经验教训

由帕尔特·贾因、拉凯什·苏库马尔、赵英武、伦佐·桑切斯-席尔瓦和内森·费舍尔撰写：深入探讨在Netflix规模下构建实时服务依赖关系图所面临的工程挑战：从流媒体架构与分布式聚合管道，到时间旅行查询，以及使这一方案得以成功运行的方法论。 引言在我们的第一篇帖子中，我们介绍了这一问题：Netflix 的工程师需要一种统一的、实时的服务依赖关系视图，以便更快地进行故障排除、了解影响范围，并…

收藏79 天前

GenPage：Netflix 如何实现端到端的生成式主页构建

作者：王乐群、潘江伟和利纳斯·巴尔特鲁纳斯图1：自回归式主页生成。GenPage 会逐行或逐个实体地构建 Netflix 主页，每一行都基于页面上已有的内容以及用户的上下文来决定。 简介 Netflix 主页是用户打开应用时首先看到的内容，也是他们发现并享受内容的主要途径。其几乎每一个部分都经过个性化定制，包括哪些行会显示、哪些实体会出现在这些行中，以及所有内容的呈现方式……

收藏93 天前