OpenAI披露Habitat存储架构演进：支撑十亿级ChatGPT用户

OpenAI 旗下所有产品均依赖底层在线存储平台 Habitat 提供快速、可靠的数据访问。如今，Habitat 需要为全球 40 个区域的超 10 亿用户提供毫秒级响应，承载数据量超过 500PB。继第一篇讲述服务化与 Python 优化后，OpenAI 深入公开了底层存储 Azure Cosmos DB 的架构重构经验。

多租户演进：从单体到隔离，再回归共享

随着业务爆发，基础设施面临多租户与单租户的权衡。单租户容器隔离性好，但容易导致过度配置与高昂成本；多租户能统一管控容量，却极易产生「吵闹邻居」（noisy-neighbor）问题。

Habitat 的架构经历了三次迭代：

过度依赖原生机制：早期所有业务共享默认容器，客户端自行指定逻辑分区键（如 user_id），引发大量热点键冲突。同时，Cosmos DB 的吞吐量限制实际在物理分区层面生效，存储扩容导致物理分区不断分裂，每个分区的有效吞吐量随之缩减，引发「弱分区」问题。
尝试单租户隔离：团队开始为关键业务独立分配容器，虽然解决了隔离问题，但各产品团队必须自行做容量规划。新功能上线常因未提前扩容而触发故障。
多租户默认化与联合优化：团队最终回归共享多租户容器，并联合微软 Azure 团队在内核层面攻坚：
- 热点键限流：优先限制最热分区键，避免单点拖垮整库。
- 请求分级（QoS）：优先保障用户交互请求，离线批处理流量自动降级限流。
- 定制 Serverless 模式：引入基于 RU 使用量的自动切分机制，单分区上限提升至 10K RU/s，彻底省去人工扩缩容。

超大规模下的「联合共管」模式

当系统规模达数十 PB 且 QPS 突破 2000 万时，商业托管服务（Managed Services）往往超出常规设计边界。2024 年底的一次区域电力故障及随后的流量踩踏，促使 OpenAI 与 Azure 团队打破组织壁垒，开启深度共管：

双方共享测试环境、仪表盘与即时沟通渠道，可绕过技术支持层直接调动核心研发。
联合优化网关元数据缓存、连接池复用机制，并重构 SDK 的检查点（checkpointing）提交逻辑。

全球读延迟降低 12 倍

Habitat 超过 90% 的请求为读操作。针对跨地域计算与存储分离带来的延迟难题，OpenAI 实施了四层加速策略：

就近存储：在具备条件的区域将数据靠近用户部署。
关键小数据集全域复制：将鉴权元数据等核心配置广播至全球 40 个区域。
基于 CDC 的分布式缓存：在算力节点侧挂载基于 Valkey 的缓存层。通过 Cosmos DB 变更数据捕获（CDC）流，在数秒内完成全球缓存主动失效，兼顾极高命中率与强一致性。
核心服务 Rust 重写：用 Rust 替换高耗能的 Python 代理层，大幅压缩处理开销。

经此优化，Habitat 全球读请求 p50 延迟从约 120ms 下降至 10ms，提速达 12 倍。

自研 EB 级存储架构

为应对下一个十亿级用户的对话存储需求，OpenAI 正基于 Rockset 的 RocksDB Cloud 核心与 Raft 一致性协议，自主研发支持 EB 级容量的自研在线存储系统。新系统将在兼容 Cosmos DB 文档模型的同时，采用存算分离和物理副本机制，在满足海量吞吐的前提下大幅降低闪存介质成本。