OpenAI 扩展存储基础设施以支持超10亿ChatGPT用户

# Habitat：OpenAI在线存储平台的扩展之旅

OpenAI的每个产品都依赖于快速可靠的数据访问，无论是有人登录、检查Codex设置，还是在ChatGPT中开启新对话。这些操作中的每一项在产品做出响应之前可能需要进行许多独立的数据查询。如果这些请求变慢，产品就会感到缓慢。如果这些请求失败，产品就会完全停止工作。

Habitat是我们构建的在线存储平台，使OpenAI产品能够快速可靠地访问所需信息。Habitat现在每秒处理超过7000万个请求，支持每周被超10亿人使用的产品，覆盖近40个地理区域。Habitat首次在2023年DevDay时推出，作为一个客户端简单Python库与单个数据库连接，用于支持GPTs。如今它已成为一个复杂的分布式系统，服务超过500拍字节的数据。

在这种规模下构建和运营基础设施并不容易，但也不是特别困难。让我们的情况独特的是，我们必须以前所未有的速度扩展，以支持巨大的用户增长和产品需求，同时构建一个成熟的平台。通常，系统工程师会为大10倍的规模构建，并期望在准备应对10倍增长时服务几年。在我们的情况下，过去三年我们每年增长都超过10倍。因此，构建和运营Habitat是一系列战术决策和排序：我们深入理解每个组件到最低级别以从现有堆栈中获得最大收益，同时避免存储和计算容量不足，以便为根本性投资争取时间。

随着OpenAI的增长，Habitat也必须随之增长：首先它变得足够可靠以处理关键产品流量，然后足够快以服务全球用户，最后能够以巨大的规模熟练地运营。本文是关于我们如何扩展在线存储的两部分系列的第一部分。在这里，我们将分享Habitat如何演变，为什么我们将其从库转变为服务，以及我们如何将一个用不常见语言编写的服务——Python——扩展为可靠的存储平台层。

在未来的出版物中，我们将详细解释我们如何在大规模上实现多租户可靠性、我们用于读取优化的分层策略，以及我们如何扩展与Azure Cosmos DB的合作关系以可靠地满足前所未有的需求。

Habitat开始于一个简单的想法：产品工程师不应该必须考虑管理数据库。Habitat在2023年DevDay首次作为一个小型Python库推出，用于支持GPTs，该库与ChatGPT的主服务器通信。它支持的一小部分操作在内部映射到Azure Cosmos DB上的数据库应用程序操作。

该库的工作是为产品团队提供一个简单的方式来存储和检索数据，而无需学习底层细节。Habitat处理所需的工作：确定涉及什么类型的数据、它应该来自或去往何处、请求是否被允许等等。

产品工程师不必担心模式查询、路由、授权、加密、序列化、请求签名和连接池化。他们也不必考虑数据来自哪里：Azure Cosmos DB、缓存或其他存储类型。

通过将存储逻辑分离为一个独立的服务，我们为部署、可观测性和平台改进创建了一个统一的控制点。

这个Python库运行良好，尽管没有集中的倡议来鼓励自助使用Postgres和Azure Cosmos DB，Habitat仍被OpenAI的产品工程师迅速采用。

随着产品需求的演变，开发人员也很容易向共享库添加对客户端缓存、压缩或加密等功能的支持。

到2025年中期，Habitat作为客户端库的实现已经达到了极限。随着Habitat层变得更加复杂，OpenAI服务数量的增加，向后兼容的协议变更不再可行。

在一个案例中，我们想通过将最关键的数据集迁移到一组地域分布的Azure Cosmos DB账户来减少区域故障对它们的影响。这个变更需要在客户端上添加额外的路由逻辑，在功能标志后面禁用，向所有客户端的推出，然后激活功能标志。

在数十个服务之间协调部署，并与每个团队合作推出它花费了数周时间。在我们激活它之前，我们意识到我们需要引入影子追踪以确保分片逻辑是正确的。为此我们需要额外两天。一个我们意识到的损坏事物中的错误的解决方案？再加两天。最终我们准备好激活标志，但他们的一个团队因与客户端问题无关的原因回滚了其服务，该服务涉及先前的一个错误，这引起了正好是我们努力防止的服务中的故障。

客户端库的更改需要在数十个服务之间进行复杂的协调，这个过程变得越来越脆弱、低效，并且容易出现运营故障。为了减少未来部署中的这种运营负担，我们决定将Habitat分离为自己的服务。

通过将存储逻辑分离为一个独立的服务，我们为部署、可观测性和平台改进创建了一个统一的控制点。而不是管理零散的更新，我们可以集中实施改进，并立即为每个OpenAI产品提供优势。

一个集中的服务也为我们提供了一个单一的拥塞点，我们在这里提供数据安全和隐私的最强元素。在Habitat服务中，我们可以集中执行访问控制策略、审计日志，并限制对底层存储资源（如Azure Cosmos DB）的访问。Habitat在保护用户数据和防止来自外部行为者、内部威胁和代理的未授权访问方面发挥着关键作用。

我们知道我们需要一个服务，但现在我们不想离开Python，尽管它作为服务有额外的成本。将Python用于高吞吐量服务增加了网络延迟，与在本地运行库相比，CPU和内存扩展的成本更高。此外，我们理解Python的低效率在100倍规模时将不可接受，因此重写似乎几乎是必然的。

然而，我们将此视为战略上接受的技术债。当时我们的主要目标不是优化成本或资源，而是让产品开发人员前进，在平台中实现稳定性。通过暂时接受Python服务的性能权衡，我们可以优先处理更紧迫的挑战、建立核心API并构建强大的基础设施。

我们也做了一个经过计算的赌注，即我们代码模型的快速进步将简化技术路径。我们相信，当从Python完整迁移成为必要时，Codex和GPT将使其成为可能。最终，这个赌注证明是正确的。

将Habitat作为Python服务运行并不是理想的性能，但这是必要的选择。Python让我们快速前进，但这并不意味着我们可以忽视风险和接受更糟糕的延迟。当平均用户请求导致数百个数据库调用时，最慢的数据库调用是用户将感受到的那一个。我们发现，在这种规模运行Python服务的主要挑战是管理极端延迟。

Asyncio帮助Python并发执行I/O绑定的工作负载，但它不能克服Python的GIL，也不提供CPU并行性。除了使用许多...