OpenAI 重整 Habitat 存储以支撑十亿级用户

Habitat 在大规模用户场景中的存储设计

OpenAI 10 月 23 日发表 Habitat 在线存储架构系列的第二篇工程文章。公司称，该平台服务分布在四十个地理区域的十亿以上用户，管理超过五百 PB 数据。这些都是厂商对自有系统的描述，不是本刊独立测得的指标。系列第一篇介绍从 Python 客户端库走向存储服务的过程；第二篇重点讨论底层 Azure Cosmos DB 的多租户设计和超大规模运维。

最值得注意的是架构路线发生了回转。Habitat 起初采用共享 Cosmos DB 容器，后来为了隔离工作负载而给服务配置独立容器，经过与 Azure 联合改造后，又以共享租户作为默认选择。独立容器能减轻邻居负载干扰，却要求每个产品团队单独规划容量。一个新服务可能从测试流量迅速增长到每秒一百万次查询；团队若忘记预先扩容，发布当天就可能在事故会议中被迫紧急处理。

共享方案为何能够重新成立

OpenAI 称，新方案优先限制最热的分区键，避免单个热点占满整块物理分区的请求吞吐量。Azure Cosmos DB 为其改进的无服务器模式，让每个物理分区可扩至每秒一万请求单元，并根据请求单元使用量而不只是存储量拆分分区。这里的一万是公告所述服务设计能力，不是每个应用的延迟承诺。自动扩展减少了人工预扩容工作，但团队仍需检查热点键与租户之间的影响。

文章说，OpenAI 最大的 Cosmos DB 账户存储数十 PB，处理每秒两千万次以上查询。它还回顾了 2024 年末一次区域断电事件：在对应规模下，故障切换到备用区域需要数小时，而双方此前都未充分测试这一情形。技术教训是，即使使用托管服务，极端规模下仍须与供应商共同演练真实流量和数据规模。普通文档里的切换目标无法替代实际演习。

OpenAI 报告其全球读取延迟中位数从约 120 毫秒降至约 10 毫秒，称为十二倍改进。这是其特定时间段、架构与工作负载下的公司测量，不能推广成其他系统采用 Cosmos DB 后也会获得十二倍速度。评估自己的系统时，应同时记录读取分布、写入压力、缓存命中、尾延迟和故障恢复，而不只摘取一个最快的数字。

可迁移的是验证方法

较小规模的服务不必在“全部共享”和“全部隔离”之间凭口号做选择。应按租户列出吞吐、分区键热度、增长速度和故障容忍度，模拟新功能上线时的流量跃升，演练区域切换时何时能恢复可用读取，并明确由谁负责扩容与限制热点租户。Habitat 的经历说明，运维责任的分配有时比纸面上的隔离架构更决定可靠性。

本文依据 OpenAI 10 月 23 日的 Habitat 第二篇原文，刊于 10 月 26 日。它解释所述设计与局限，不声称接触 OpenAI 的内部遥测、Azure 的未公开合同，也没有独立复现上述性能数字。

读懂容量数字的边界

请求单元是 Cosmos DB 用来计量数据库操作消耗的资源，与“每秒查询次数”不是同一个量纲。一个复杂查询和一个简单点读取，可能消耗不同请求单元；因此不能把每个分区每秒一万请求单元直接换算成一万次用户请求。类似地，平台总数据量超过五百 PB，并不表示所有数据都在单个 Cosmos DB 容器中。文章分别提到整体平台和最大账户，读者应保留这些层级差别。

多租户方案的核心风险还包括公平性和故障影响面。限制最热的键会保护其他工作负载，却也可能让热点业务自身变慢；运营团队需要知道何时提高容量、何时调整数据分区、何时把特别敏感的租户隔离。上线前演练应记录每一步的责任人与恢复时间，而不是仅在正常流量下跑出漂亮的中位数延迟。这样才能把 OpenAI 的案例转化成适用于自己系统的检查清单。

OpenAI 的选择也受其组织结构影响。产品团队数量、上线节奏与 Azure 团队的直接沟通渠道，可能与一般企业不同。读者若只复制共享容器的结论，却没有相同的监控、限流和共同排障能力，便可能重新遇到早期的热点问题。架构决策应从可观测的风险和责任出发，而非把超大公司的最终配置当作默认模板。