Netflix批处理为何换掉自研队列

你可以把批处理平台想成一间共用厨房：训练模型、视频转码和离线数据加工都来排队，争抢有限的 CPU、GPU 和内存。厨房越大，决定谁先用、每家能用多少、空出来的位置能否借给别人，就越难。Netflix 曾为此自建一套系统。如今，它正把大部分批处理迁往开源组件 Kueue。这件事值得看，不只因为规模大，更因为它展示了平台团队如何承认：过去必须自己造的基础设施，现在可能更适合交给通用生态。

本文事实均来自 InfoQ 对 Netflix 技术博客等材料的二手转述，只有一个独立信源；迁移比例、资源利用率提升幅度等细节并未公开。

自研系统为什么不再划算？

Netflix 在 2018 年创建 Compute Managed Batch（CMB），用于在其容器平台 Titus 上管理和执行批处理作业。它能按 tenant hierarchy——可理解为组织及其下属团队的层级——分配容量，也能借助 Titus 的控制接口，把任务分派到多个 cell，也就是多个 Kubernetes 集群。

Kubernetes 是管理容器化应用的平台，负责把任务安排到一组机器上，并处理扩缩容和故障恢复。CMB 最初解决的是当时缺少现成工具的问题。但据 InfoQ 报道，后来 Kubernetes 生态逐渐吸收了不少类似能力，CMB 与 Kubernetes 的结合却不够紧密，继续增加功能变得越来越困难。

Netflix 最终选择 Kueue。它是 Kubernetes 原生的开源排队和配额管理组件：先判断哪些批处理任务有资格进入集群，再把具体运行交给 Kubernetes 及相应控制器。报道转述的选择理由包括功能和灵活性、采用范围以及创新速度。不过，这些都是 Netflix 的主观判断，材料没有提供横向评测。

真正难的不是替换，而是不断服务

换掉基础设施，最怕“一刀切”：旧接口失效，所有使用团队被迫同时改造，一旦出错也很难退回去。Netflix 采用的是 API parity，也就是让新系统保留旧系统的调用方式。对使用者来说，柜台没有变，后台却逐步换了设备。

迁移按 tenant 分批进行，并保留回滚能力。Netflix 还把 CMB 的内部 tenant 映射到 Kueue 的 Cohort——一组可以共享资源的队列；把最末级 tenant 映射为一对 ClusterQueue 和 LocalQueue。前者管理集群范围的资源配额，后者是任务提交时使用的本地入口。原有容量配置则通过 ResourceFlavor 和 nominal quota 导入，分别表达资源类别和名义配额。

团队没有把最难的客户留到最后，而是先迁移规模最大、情况最复杂的用例。按报道转述，这让团队较早验证了新平台能否承受真实压力；该生产迁移历时四周。团队也在非生产环境做负载测试，调整性能配置，以满足既有的吞吐要求。

空着的资源，可以先借出去

Netflix 目前已用 Kueue 在生产环境管理数百万个批处理工作负载，但整体迁移仍未完成。这里的“数百万”没有统计周期，也没有说明作业定义和并发规模，因此不能理解成日均吞吐量。

报道还提到，Netflix 使用基于 preemption（抢占）的 fair sharing（公平共享）：某个 tenant 暂时不用自己的预留容量时，系统可以先借给别人；原租户需要资源后，再按规则收回。Netflix 称这显著提高了平均资源利用率，但没有公布基线和提升幅度。

为什么值得关注

这个案例给平台团队的启示，不是“自研一定不好”。CMB 曾填补真实缺口，也承载了 Netflix 多年的特殊需求。变化在于，外部生态后来追了上来。此时继续自研，不只是维护旧代码，还要独自承担新功能、集成和演进成本。

Netflix 的做法提供了一个更实用的判断框架：先看通用方案是否已经覆盖核心能力，再看内部系统的差异化价值是否足以抵消长期维护成本；决定迁移后，则用兼容接口、分批切换、可回滚和提前攻克复杂用例来控制风险。放弃自研并不等于推倒重来，也可以是一场对用户近乎无感的后台换轨。

局限与未知

• 迁移仍在进行，材料没有披露剩余工作负载的比例、完成时间或最终是否彻底停用 CMB。
• “数百万个工作负载”和“显著提高利用率”都缺少统计口径及具体数据，无法判断实际吞吐与收益。
• 现有供稿是单一二手报道，且经验总结被截断；Kueue 与 Netflix 内部平台各自承担哪些边界职责，也没有完整说明。