OpenAI 为超大规模代码库构建 Git 分布式存储系统 Pando

在 OpenAI 扩展 Git 规模

在投资 Git 生态的同时，构建面向 agent 规模级别的源代码控制系统。

作者：Aaron Friel、Taylor Blau 和 Ted Nyman，技术员工成员

分享

我们为什么需要新的源代码控制系统 面向规模的 Git 工程 Git 对象存储入门 现有的分布式 Git 服务模式 三阶段提交（3PC） 预写日志（WAL） 架构 Pando 重新思考约束 因果一致性（CC） 方法比较 扩展推送 线速 fetch 和 clone 性能 压缩与首字节时间 构建 Pando 部署 Pando 回馈 Git 项目 下一步

我们为什么需要新的源代码控制系统 面向规模的 Git 工程 Git 对象存储入门 现有的分布式 Git 服务模式 三阶段提交（3PC） 预写日志（WAL） 架构 Pando 重新思考约束 因果一致性（CC） 方法比较 扩展推送 线速 fetch 和 clone 性能 压缩与首字节时间 构建 Pando 部署 Pando 回馈 Git 项目 下一步

过去一年里，我们 monorepo 的规模和对它的需求都以惊人的速度增长。很明显，我们需要改造源代码控制系统，使其能够扩展到 Codex 所带来的并发工作水平。

我们构建了 Pando，一个用于 Git 仓库的新后端，同时没有中断任何工程工作，也没有改变团队使用 Git 的方式。Pando 现在为 OpenAI monorepo 中的所有开发提供支持。Pando 旨在实现两个雄心勃勃的目标：第一，水平可扩展的写入，针对向许多分支的并发推送进行优化。第二，最大化读取吞吐量，使客户端能够以足够快的速度下载数据，从而完全占满其可用网络带宽。

我们在实现这些目标的同时，保持了与 Git 协议和客户端的兼容性，使我们工程师和 agent 都能将 Pando 无缝融入现有工作流。在生产环境中，Pando 将推送延迟中位数降低了近 5 倍。它现在每天交付近 1 PB 的 Git 数据。

在这里，我们将介绍构建新源代码控制系统的动机，以及为什么选择保持与 Git 的兼容性。我们会将我们的系统与扩展 Git 的常见方法进行比较，说明为什么 Pando 具有独特能力来满足 OpenAI 的可扩展性需求。我们还会讨论下一步计划，以及我们将如何继续为 Git 做贡献，以支持 agent 规模的工作。

Codex 改变了 OpenAI 的开发规模和节奏，使工程师能够并行完成多得多的工作。这意味着更多的分支和推送、更多的合并，以及来自开发环境、研究任务和 CI 的更多 fetch 和 clone。

这些需求会叠加。一名工程师现在可能同时有多个变更准备进入 CI，而每次推送都可能让多个任务去 fetch 同一个 commit。

大约从去年年底开始，支撑我们 monorepo 的系统越来越难以跟上。我们遭遇了缓慢的 fetch 和 push，以及失败的合并，可靠性有时甚至低于 90%。我们是遇到了 Git 本身的极限，还是我们服务 monorepo 的方式的极限？Git 诞生于一个通过电子邮件交换内核补丁的社区。二十多年来，随着开发者构建软件的方式发生变化，他们一直围绕 Git 调整自己的工具。当我们开始在自己的 monorepo 中感受到摩擦时，对我们来说重要的是，我们能够继续建立在这项工作之上。

我们看到了一种方法，可以保留这种熟悉的工作流，同时重建后端，以并行处理推送到不同分支的操作，并同时向许多读者提供相同的历史。以 Git 作为我们源代码控制工作流的基础，意味着对客户端的改进可能不仅有益于 OpenAI。我们希望把我们这份 Git 副本中的这些改进贡献给上游，与更广泛的社区分享。

扩展源代码控制系统有两个关键维度：许多写入者推送到不同分支，以及许多读者 fetch 相同的历史。Pando 对两者都进行了优化。

首先，Pando 独立协调对每个分支的更新。对无关分支的更新可以并行进行，而 fetch 某个分支的读者会获得该修订所需的历史。代价是，查看多个分支的读者可能会在不同时间点看到它们。

其次，Pando 在多次 fetch 之间复用 packfile（Git 将多个对象一起压缩的格式），而不是为每个客户端生成单独的 packfile。客户端可能会下载一些它已经拥有的对象，但服务器可以用很少的计算量向许多客户端提供相同的字节。

这些选择使我们能够跨分支扩展写入，并从缓存中提供读取。为了看清它们如何协同工作，我们先从 Git 如何存储和传输历史开始。

Git 必须能够让仓库的两个部分保持同步：对象和引用。

Git 仓库将文件快照以及连接它们的历史记录为对象图。对象可以是 blob、tree、commit 或 tag。blob 保存单个文件的内容，tree 将名称与 blob 或其他 tree 关联起来，形成目录结构。commit 指向一个根 tree 和零个或多个父 commit，形成仓库的历史。

对象通过其类型和内容的哈希来标识。对象也是不可变的：记录一个已更改的文件会创建一个新的 blob，而未更改的文件和目录可以复用现有对象。

分支和标签是引用，或称“ref”，它们指向 commit。在分支上提交会创建一个新的 commit，并更新该分支的 ref 指向它。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）