事件概述

OpenAI 工程团队发布技术博客《Rapidly scaling online storage to serve over 1 billion ChatGPT users》，首次系统披露其在线存储平台 Habitat 的演进路径。文章作者为 Jon Lee、Chaomin Yu 和 Ben Ries（均属 OpenAI Members of Technical Staff），是”如何扩展在线存储”两篇系列文章中的第一篇。

Habitat 的定位是”在线存储平台”（online storage platform）：OpenAI 的每一个产品——包括 ChatGPT、API、Codex 以及各类内部服务——在用户登录、读取 Codex 设置、发起新对话等动作时，都需要经历多次独立的数据查询。Habitat 的作用是让产品团队无需关心底层数据库管理，就能快速、可靠地存取数据。

根据文中给出的数据，Habitat 目前的规模为：

  • 7000 万次以上/秒的请求处理量
  • 支撑每周超过 10 亿人使用的产品
  • 覆盖近 40 个地理区域
  • 管理超过 500 PB 的数据

需要指出的是，本文提供的摘要中提到”22M requests per second”，与正文中的”70M+ requests per second”口径不一致，原文未说明这一差异的原因，此处如实记录。

时间线上，Habitat 在 2024 年中期以一个小型 Python 库起步，直连 Azure Cosmos DB；到 2025 年中期触达客户端实现的能力上限；如今已是一个复杂的分布式系统。过去三年，其规模每年同比增长超过 10 倍。

关键技术点

1. 从客户端库到独立服务

Habitat 最初（2024 年中）是一个嵌在 ChatGPT 主服务中的 Python 库，支持的是一小组映射到底层 Azure Cosmos DB 的操作。它对产品工程师屏蔽了 schema 查找、路由、鉴权、加密、序列化、请求整形、连接池等细节，甚至不暴露数据来自 Azure Cosmos DB、缓存还是其他存储。

但到 2025 年中期，客户端库模式走到了尽头。文章举了一个非常具体的案例：为了降低单一区域故障对关键数据集的影响，团队希望把数据迁移到一组按区域分布的 Cosmos DB 账号上。这需要在客户端引入额外路由逻辑，并隐藏在 feature flag 之后：

  • 需要确保新逻辑推送到所有客户端 —— 跨数十个服务协调部署，耗时数天；
  • 决定增加 shadowing 来验证分片逻辑 —— 又花了两天；
  • 发现 bug 并修复 —— 再花两天；
  • 最终准备开启开关时，某个团队因无关原因把服务回滚到了带 bug 的旧客户端 —— 于是”我们费尽心机想避免的故障还是发生了”。

结论是：客户端库的每次变更都要求跨数十个服务的复杂协调，过程越来越脆弱、低效，且容易引发运维故障。因此 Habitat 被抽离为独立服务，从而获得部署、可观测性和平台增强的单一控制点。

2. 为什么继续用 Python

文章明确承认，用 Python 做高吞吐服务会增加网络延迟，并带来相比本地库执行显著更高的 CPU 与内存扩展成本；团队也意识到 Python 的低效在 100 倍规模下将不可接受，几乎注定要重写。但他们把这视为一次”技术债的战略性引入”（a strategic incursion of technical debt），理由与团队当时的首要目标有关——原文在此处截断，完整论述未给出。

3. 架构分层与组件

文中以架构图形式给出 Habitat 的职责边界，主要包括：

  • 缓存层：Caches（Valkey 等）
  • 安全与合规：ACL 策略、鉴权、加密、数据驻留（data residency）、多租户隔离
  • 流量治理：限流、请求整形、路由（含 schema 查找与数据驻留路由）
  • 存储资源：Azure Cosmos DB、Nanobase、Valkey、Blob storage
  • CDC 链路：Change Data Capture 服务，对接 Databricks、Rockset、Kafka 等

服务化之后，Habitat 成为集中执行访问控制策略、审计日志（audit logging）、以及限制对底层存储资源访问的单一咽喉点（single chokepoint）。文章特别提到，Habitat 在保护用户数据、阻止来自”外部、内部和 agent 行为体”的未授权访问方面扮演关键角色。

4. 后续内容

作者说明这是两篇系列文章的第一篇。第二篇将详细展开：大规模多租户可靠性、读性能优化的分层策略，以及如何扩展与 Azure Cosmos DB 的合作以应对前所未有的需求。

对数据科学或 AI Agent 落地的意义

这篇文章表面讲存储扩展，实际触及了几个对 AI 系统落地极具参考价值的点。

第一，存储层的抽象决定了上层迭代速度。 Habitat 的核心价值不是性能数字，而是让产品工程师”不必思考数据库管理”。对于数据科学团队而言，这意味着特征读取、会话状态、配置存储可以走统一接口，而不必每个模型/产品线各自维护一套连接与权限逻辑。

第二，权限管控正在从”人”扩展到”agent”。 文章明确把 agent 列为需要防范未授权访问的行为体之一。这是很关键的信号：当 AI Agent 开始自主发起数据和工具调用时，存储平台必须成为策略执行的收口点，而不是依赖每个调用方自觉遵守。做 Agent 系统的团队应当考虑把 ACL、审计、限流放在统一的平台层，而不是分散在 agent 框架内部。

第三，规模增长的非线性是可预期的工程前提。 “连续三年每年 10 倍增长”意味着任何”够用几年”的架构假设都会快速失效。文章中”用战术决策换取基础投资时间”的做法——先榨干现有栈的性能，再为根本性重构争取窗口——是高速增长期数据平台常见的现实路径。

第四，Python 服务化的取舍值得抄作业。 OpenAI 明知 Python 在服务侧有额外开销、明知最终要重写，仍然选择短期保留，以换取迁移路径上的其他收益。对以 Python 为主的数据团队来说，这是一个务实的判断框架：技术债是否”战略性”，取决于它换来的时间是否被用在了更高优先级的事情上。

我的技术点评

这篇博客最有价值的部分不是那些漂亮的数字，而是那个feature flag 回滚导致故障的故事。它把”客户端库 vs 独立服务”的争论从架构美学拉回到了运维现实：当协议变更需要跨数十个服务协调、且任何一个团队的回滚都能让整体退回到有 bug 的状态时，架构就已经不是技术选择，而是组织风险。

我认为这篇文章隐含的一个判断是：在超高速增长期，控制平面（control plane）的收敛比数据平面的极致性能更优先。 服务化带来的延迟增加是真实成本，但它换来了一次部署即全局生效、一个地方做审计、一个地方做鉴权的确定性。对多数团队来说，这个交换是划算的。

同时也要保持清醒：文章坦承 Python 在 100 倍规模下不可接受、重写”几乎必然”，这说明服务化只是阶段性解法，不是终局。OpenAI 选择先解决组织协作问题、再解决语言性能问题，是一种排序，而不是一种信仰。至于这个技术债最终以什么形式偿还——是换语言、换运行时，还是把热路径下沉到其他组件——本文没有给出，需要等第二篇或后续文章。

另外，摘要与正文关于 QPS 的数字不一致（22M vs 70M+），对一个以工程严谨著称的团队来说是个小瑕疵。如果这不是笔误，那么它可能反映的是不同时间窗口或不同统计口径（例如是否包含缓存命中、是否包含非 ChatGPT 流量），但原文未说明，不宜过度推测。

最后提醒一句：文章提到的 500 PB、7000 万 QPS、40 个区域这些指标，都是在 OpenAI 自身的流量结构和工作负载特征下取得的。直接照搬其架构结论到中小规模系统，很可能是在为不存在的问题付出复杂度成本。

原文链接