Netflix 的 TimeSeries Abstraction 利用 Apache Cassandra 作为存储，以毫秒级延迟摄入和查询 PB 级的时序事件数据。宽分区（即单个分区随时间累积大量事件）对时序工作负载构成重大挑战，导致 Cassandra 集群中出现高读取延迟、超时、CPU 利用率上升以及垃圾回收停顿。为此，TimeSeries 数据被划分为离散的时间块，形成可管理的段。 初始的预配策略依赖用户指定的工作负载特征和蒙特卡洛模拟来确定最优的基础设施和分区配置。然而，当工作负载未知、估算不准确、随时间演变或包含数据异常值时，该方法证明不足。为自动化调整，引入了后台工作进程，用于监控分区直方图，并根据观测到的数据密度动态重新划分未来的时间片。这种时间片重划分策略在大多数数据表现出类似宽分区行为时，能有效降低读取延迟和超时。 然而，该策略并未解决仅少数 ID 在表中呈现宽分区的场景。针对此类情况，以及当调用方即使面临较高延迟也需要获取全部数据时，开发了按 ID 的动态分区。该异步流水线在读取操作期间检测宽分区，并将其透明地分割为最优大小。该过程包括检测、规划与分割，以及通过重定向查询至分割后的分区来服务读取请求。 检测发生在读取操作超过配置的字节阈值时，此时会向 Kafka 发出事件。系统最初专注于不可变分区以简化实现。规划阶段读取整个分区以生成分割计划，并利用检查点机制处理故障。分割涉及将数据划分委托给特定策略，例如将更多事件桶分配给时间桶。验证分割至关重要，通过校验和确保数据完整性后再标记分割完成。最后，TimeSeries 服务器使用内存中的布隆过滤器高效地将读取查询重定向至分割后的分区，使得该重定向对调用方而言几乎不可见。

Netflix 构建了一种图抽象层，以处理高吞吐、低延迟的图操作，尤其适用于实时分布式图和社会关系图等场景。该抽象层涵盖两个类别：用于深度分析的 OLAP 和用于流式用户体验的 OLTP。该抽象层采用属性图模型，具有强类型的节点和边，并划分为隔离的命名空间。每个命名空间拥有预定义的图模式，通过数据网关控制平面进行管理。该模式支持数据质量强制约束和高效查询规划等优化措施。实时索引对节点和边采用键值存储，并为链接和属性分别建立索引。边链接通过源 - 目标关系进行索引。为确保无论方向如何均可访问，该设计按字典序组织标识符。缓存机制用于最小化写放大和读放大。该抽象层的架构优先考虑高性能，并采用了如写旁路缓存等策略。

Netflix 开发了一种名为“服务拓扑”（Service Topology）的分布式基础设施“动态地图”，以帮助工程师理解服务依赖关系并排查问题。该地图旨在满足更快识别服务关联及故障期间潜在影响的需求，能够回答诸如哪些服务相互依赖、问题源头何在等关键问题。数据来自三个来源：eBPF 网络流、IPC 指标以及端到端追踪。每个数据源提供独特的视角——网络连接性、应用层细节以及实际请求流。这种多层架构将这些视图整合为统一的实时地图。系统为每个数据源使用独立的图数据库，以保持独立性并支持并行查询。工程师可以单独查看每个图，或将它们组合起来，以获得对服务交互的全面理解。系统从多个区域的 Kafka 中摄入流日志，进行处理，并将数据存储于图数据库中。这一动态地图帮助 Netflix 工程师快速诊断并解决问题，从而确保流畅的流媒体体验。

Netflix 采用多仓库策略，管理着数千个 Java 仓库，需要高效的构建逻辑共享。为此，他们构建了 Nebula 系列 Gradle 插件，其中包括 ArchRules，用于管理依赖并强制执行代码规范。该举措源于对 Java 库生命周期管理的改进需求，起因是一次向后不兼容变更引发的事故。Netflix 利用 API 生命周期注解（@Deprecated、@Public、@Experimental）来识别废弃代码可能带来的问题。ArchUnit 是一款广受欢迎的用于强制执行架构规则的库，被选中用于检测这些注解的误用及其他技术债务问题。Nebula ArchRules 插件实现了 ArchUnit 规则在多个仓库间的共享与应用，从而增强了功能。ArchRules 使用字节码分析（ASM）支持跨语言，并通过易于使用的构建者模式简化规则创建。规则可以打包在库中，或定义在独立的规则库中，由插件自动检测并运行。ArchRules Runner 插件针对源集评估规则，并生成 JSON 和控制台报告，从而提升了报告能力。通过使用 ArchRules，Netflix 为库作者提供了一个平台，用于追踪 API 使用情况并检测废弃 API 的误用。

Netflix 在个性化、制片厂制作、支付和广告等多个业务领域广泛采用机器学习。随着机器学习（ML）应用的扩展，一个挑战随之出现：模型与数据分散在孤岛中，阻碍了协作与发现。机器学习从业者难以理解模型血缘、特征来源及其在不同系统中的影响。这种碎片化使得关于现有特征、数据来源、管道依赖以及变更影响的查询难以获得便捷答案。 核心难点在于连接生成元数据的异构机器学习基础设施组件。从管道编排器到实验平台和特征存储，数十个系统以各种格式产生数据。解决这一问题需要收集异构元数据，将其转换为统一模型，并构建一个用于探索的连接图。 解决方案是元数据服务（MDS），它在 Netflix 内部构建模型生命周期图（Model Lifecycle Graph），以互联机器学习实体。MDS 实时摄入机器学习元数据，支持跨域查询，例如识别使用特定模型的实验，或共享某些特征的模型。其愿景是使公司内所有机器学习资产均可被发现、可理解且可复用。 MDS 基于以下核心抽象构建：组件（Component），每个拥有唯一的 AIP URI；实体（Entity），即具有属性的机器学习专用资产；实体类型（Entity Type），定义数据形状；域（Domain），用于分组相关的实体类型；以及提供者（Provider），即来自源系统的域的具体实现。这种基于 URI 的地址机制允许任何服务以通用方式引用任何机器学习资产。构建该图的过程包含多个阶段。 首先，MDS 通过 Kafka 和 AWS SNS/SQS 与源系统集成，消费表示变更的轻量级事件。专用的事件处理器处理来自管道编排、模型注册表、特征存储、实验平台和身份平台等系统的事件。其次，MDS 实现水合契约（hydration contract），验证事件并调用源系统 API 获取完整状态，随后将其转换为标准化实体。这种“变更通知”模式确保了针对事件顺序问题的鲁棒性，但会将读取负载施加到源系统上。 第三，原始事件被转换为具有标准化字段的统一实体模型，为下游消费者提供一致接口。标准化实体统一字段名称和格式，并将平台特定 ID 转换为全局 AIP URI。最后，标准化实体被持久化到 Datomic 用于缓存和关系存储，同时也在 Elasticsearch 中建立索引。Datomic 凭借其不可变事实模型，支持复杂的图遍历和实体关系查询，使得跨多域查询无需低效的 N+1 查询模式。

该博客文章深入探讨了 Netflix 机器学习（ML）模型服务基础设施如何在多个领域以大规模方式支撑个性化体验的技术见解。中央 ML 模型服务平台向多个领域特定的微服务暴露了与领域无关的 API 抽象和流量路由能力，用于模型推理。这一统一的 API 加快了现有 ML 体验新版本的迭代创新速度，并支持通过 ML 实现新产品体验。ML 模型服务基础设施的成功取决于使研究人员能够快速验证新假设，并安全地将模型发布到生产环境。该平台服务于数百种模型类型和版本，每秒处理 100 万次请求，其运作层级为工作流，而不仅仅是单个评分函数。 模型定义包含一组用于计算特征的必要事实，并依赖模型服务平台在推理时通过调用其他微服务来提供这些事实。调用服务仅需提供标准请求上下文和相关领域上下文，模型即可在执行流程中自行计算特征并执行推理。该平台作为快速 ML 创新的推动者，同时将 ML 模型迭代对客户端应用的暴露降至最低。平台的关键原则包括：模型创新与客户端应用解耦、客户端与模型分片解耦，以及灵活的流量路由规则。 该平台使用一个名为 Switchboard 的自定义服务，作为所有流量的灵活代理层，每秒处理超过 100 万次请求，同时保持高可用性和高可靠性。Switchboard 为所有客户端的模型需求提供单一接入点，并可根据丰富的上下文特征集对请求进行路由。平台还引入了"Objective"的概念，这是由服务平台定义的一种枚举，系统中每个进入的请求都必须提供该 Objective。Objective 将客户端与具体模型解耦，并指导平台的流量路由和模型选择决策。 Switchboard Rules 是一种 JavaScript 配置，允许研究人员在不修改客户端代码的情况下，将模型变体、实验和流量拆分绑定到 Objective 上。这些规则规定了给定 Objective 的默认模型、为一系列 Objective 配置的 A/B 实验，以及逐步将流量迁移到新模型的自定义策略。这些规则由 Switchboard 和模型服务集群共同消费，服务平台组件可基于这些规则采取各种操作。总体而言，该平台为 Netflix 提供了一套可扩展且灵活的 ML 模型服务解决方案，在最小化对客户端应用影响的同时，实现了快速创新与实验。

Netflix 构建了媒体制作套件（Media Production Suite，简称 MPS），旨在为全球制作项目优化媒体工作流程，以实现效率与一致性。MPS 的核心依托 FilmLight 的应用程序接口（FLAPI）进行图像处理，这一合作避免了从零开始构建所有功能。MPS 解决了文件管理混乱和媒体处理不一致等挑战，通过自动化任务并最大限度减少错误来提升效率。FLAPI 用于检查相机文件的元数据、对其进行标准化处理并使其可搜索，从而确保数据的一致性。此外，FLAPI 还能生成具有精确色彩管理和去马赛克处理的视觉特效底片及交付成果。MPS 通过 Cosmos 实现云集成，支持在 Docker 化环境中仅使用 CPU 实例，从而最大化运行效率。生产负载采用弹性处理方式，可根据需求动态扩展，确保快速交付。MPS 既适用于经验丰富的团队，也能为需要指导的团队提供支持，而 FLAPI 则负责处理其中的复杂性。这一合作促进了开放沟通与联合验证，有利于标准化生态系统的建设。总体而言，其成效包括减少延误、加快交付周期以及提升制作流程的整体效率。

自 Netflix 推出首场直播节目以来，其直播流媒体业务迅速扩张，目前已实现每日多场活动同步直播。早期的直播节目依赖工程师和临时搭建的方案，缺乏专门的运营团队。随着业务发展，Netflix 建立了专用的广播运营中心（BOC），以管理直播播出流程。为确保信号可靠性，Netflix 对场馆提供的音视频素材制定了严格的技术规范。Netflix 的运营模式经历了多个阶段演进，从以工程为主导的运营模式逐步发展为由专业化工程团队支撑的体系。为此，公司推出了传输运营中心（TOC）模式，以提升效率并支持高并发事件的管理。在 TOC 模式中，传输、流媒体和广播控制操作员等关键角色各司其职。对于重大高关注度活动，Netflix 采用专门的“大赌注”（Big Bet）模式，配置专属资源。直播指挥中心（LCC）负责监控整个直播流媒体链路，为操作人员提供实时数据支持。LCC 采用自研的可观测性技术栈，以应对海量数据并快速响应各类问题。LCC 运营负责人与技术发布经理则负责突发事件的应急响应。

Netflix 旨在优化其庞大内容库的简介筛选流程。数千部作品使用户的选择变得复杂，因此简介在决策过程中至关重要。高质量的简介能够提升用户参与度，而低质量的简介则会导致用户沮丧并放弃观看。挑战在于如何将质量验证规模化，以覆盖数十万条简介。Netflix 开发了一种基于大语言模型（LLM）的方法，从四个关键维度评估简介质量。该系统与创意撰稿人的意见一致性超过 85%，确保了由专家主导的质量标准。简介质量既通过撰稿人定义的创意质量进行评估，也结合会员的隐性反馈（如流媒体指标）进行衡量。"LLM 作为裁判”系统采用分层推理、共识评分和事实核查代理等技术，以优化评估准确性。这些由 LLM 生成的质量评分与关键流媒体指标（如取用比例和放弃率）存在相关性。这使得 Netflix 能够主动识别并修复简介问题，从而提升会员体验和内容发现效果。

Netflix 使用 eBPF 捕获大规模 TCP 流日志以获取增强的网络见解，但准确地将流 IP 地址归因于工作负载身份是一个significant挑战。初始归因方法依赖于 Sonar，一个内部 IP 地址跟踪服务，但它由于分布式系统中的延迟和故障而导致了误归因。误归因使流数据不可靠，用于决策，并且在归因前等待 15 分钟的解决方法也无法消除该问题。为了解决这个问题，Netflix 开发了一种新的归因方法，该方法通过确定环境中的本地工作负载身份来归因本地 IP 地址。对于容器工作负载，Netflix 利用 IPMan，一个容器 IP 地址分配服务，来归因本地 IP 地址。一旦本地 IP 地址被归因，远程 IP 地址可以通过学习每个工作负载拥有的 IP 地址的时间范围来归因。FlowCollector 维护一个内存哈希表来表示这种知识，并使用 Kafka 与其他节点共享学习的时间范围。新的方法实现了准确的归因，并且可以优雅地处理暂时性问题，同时由于其简单性和内存查找也具有成本效益。该方法被扩展到归因跨区域 IP 地址，方法是将流转发到相应区域的节点。最后，该方法进一步扩展到归因非工作负载 IP 地址，如 Netflix 的内容交付网络所属的 IP 地址。