数据周刊｜2026年第37周：AI落地，先算清性能、语义和价值三笔账
一次无关的回滚，把原本要避免的故障引了出来。
OpenAI 的 Habitat 团队要给关键数据做跨区域路由，先把逻辑放进 Python 客户端库，再协调几十个服务逐一升级。几天后功能终于能开，一个无关回滚却把某个服务退回旧客户端，原本要避免的故障还是发生了。这个过程来自 OpenAI 公开复盘，不是我的亲历。它让人发愁的地方很具体：新功能已经写完，风险却还藏在几十个调用方各自的版本里。
这周我从 Data Engineering Weekly #287 发现并读完三篇公开原文。它们表面上分别谈在线存储、旧数仓和因果推断，背后其实是 AI 落地前的三笔账：性能账、语义账、价值账。少一笔，演示仍然可能很漂亮；到了生产环境，账单、错误答案和预算会轮流来敲门。
本期证据窗口是 2026 年 9 月 7 日至 13 日。DEW #287 在 9 月 14 日发布，只是发现来源，不拿它替代三篇原文的发布日期。
第一笔：性能账，不是换一种语言就算还清
9 月 11 日，OpenAI 发布了在线存储平台 Habitat 的工程复盘。这里的“在线”，指登录、读取设置、发起对话等产品请求正在等待的那条链路，不是离线跑报表的数据仓库。官方文章称，它如今跨近 40 个区域，每秒处理超过 7000 万次请求，服务每周超过 10 亿用户，承载超过 500 PB 数据。这些数字均为 OpenAI 自述，没有公开可独立复现的数据集。
它最早只是连接 Azure Cosmos DB 的 Python 客户端库，替产品团队处理模式查找、路由、授权、加密、序列化和连接池。早期这样做很合理：离调用方近，开发快，产品同学也不用先读一本数据库管理手册才能保存一条记录。
麻烦出在规模和组织一起长大之后。协议变更要协调几十个服务；新路由要等所有客户端升级；补一个影子流量验证，还得再滚一轮。于是团队把 Habitat 从共享库收成独立服务，把部署、可观测性、访问控制和审计集中到一个控制点。这里的关键不是“微服务比库高级”，而是当客户端版本分叉已经成为运维放大器时，平台化才开始值得。
AI 生成解释图：在线服务与离线任务应划清资源边界；不是 Habitat 真实架构图，也不是性能数据证据。
集中以后，Python 的开销又变成下一张账单。文章给了几个很具体的故障机制：asyncio 只能让等待重叠，不会凭空得到 CPU 并行；无抖动的定时配置刷新，会让同一 Pod 的多个进程同时解析大文件；aiohttp 连接池默认的后进先出复用，还可能把新流量继续压回较慢的进程，形成越慢越忙的反馈环。
团队先用事件循环延迟、CPU 剖析和连接复用实验定位问题，再缩小配置、延长刷新间隔并加抖动；用 Envoy 做连接汇聚、HTTP/2 多路复用、限流和熔断。更重要的是，Habitat 故意提供受限的 NoSQL API，不允许调用方随手写无界 SQL。复杂分析和搜索经变更数据捕获流向隔离的 Rockset 实例，避免读重负载拖垮在线请求。
到 2026 年第二季度，团队才用 Rust 重写服务。OpenAI 称新服务已承接 95% 生产请求，相比 Python，CPU 效率为 6 倍、内存效率为 15 倍；此前 Python 峰值已超过每秒 2000 万次请求。几个数字不能混写：2000 万是 Python 峰值，7000 万以上是当前整个平台口径；语言对比也是 OpenAI 自测，不是所有公司的通用换算表。
我更愿意把这篇看成“还债顺序”的案例：先解除多客户端协调风险，再测事件循环和连接池，再限制昂贵请求，最后才换语言。国内团队若在线服务刚到每秒几千请求，最忙的工程师却已经打开 Rust 招聘页面，多半不是技术前瞻，是会议开早了。
第二笔：语义账，AI 不会替你猜出公司的暗号
9 月 9 日，BlaBlaCar 发布了另一类系统的重建复盘：用于公交竞争情报的离线分析数仓。它每天处理 TB 级公共 GTFS 交通数据和私有市场数据，要回答班次、价格、供给等问题。这里不要和 Habitat 混在一起：前者主要服务分析、指标与决策，后者主要保障产品在线读写；一个优化 BigQuery 扫描成本，一个防止热路径被拖慢。
旧系统的问题很像不少公司的数仓储物间：一次性模型越堆越多，指标逻辑散在几十处，命名依赖熟人翻译，维护每月要花 4 个完整工程日，原始 BigQuery 计算费用每月超过 1000 欧元。LLM 能写出语法正确的 SQL，却不知道某个 axis 到底是线路名称还是标识符，也不知道算票价前要排除哪些内部取消记录。
团队重建时做了四件并不新鲜、但很难偷懒的事：文档、分层建模、指标治理、质量检查。文档贴着 dbt 代码保存，表说明明确用途、粒度、业务规则、常见问题、关键过滤条件和使用者；易混字段采用更精确的命名，例如把对象、地理层级、类型和方向写进名字。复杂指标另存业务定义、技术定义、公式和 SQL 示例。
AI 生成解释图：指标口径、模型文档和质量检查共同支撑 AI 问数；不是 BlaBlaCar 的真实目录截图，也不是成本下降证据。
他们还用了两个 AI Agent：一个生成文档，一个独立审查重复定义、裸写描述和缺失单位；之后再跑 dbt compile 与 dbt docs generate。有意思的是，AI 在这里没有坐上驾驶位，只是接过了最枯燥的抄写活，业务定义仍要由工程师和业务经理在同一间屋里对齐。机器很勤快，但它不知道公司里一句“有效订单”曾经吵过几次会。
数仓被分成 Staging、Intermediate、Core、Mart、Reporting 五层，并配合分区、聚簇、增量刷新和列裁剪。消费层的核心表与 Mart 表各收敛到少于 10 张，常用查询走预聚合的轻量事实表，复杂指标单独隔离。BlaBlaCar 称改造后维护量降到每月不足 0.5 天，BigQuery 月费由约 1000 欧元降到约 140 欧元，作者将降幅概括为 85%。团队是在旧系统的困难环境中工作两年多后决定重建，原文没有披露重建工期；结果来自单一公交竞争情报域的团队复盘，没有外部审计，更不是全公司数仓成本下降 85%。
这笔账给国内旧数仓的启发，不是立刻照搬五层目录。先挑一个 AI 最常答错、业务又真正在用的主题域，补齐表粒度、指标定义、负责人、更新时间和质量规则；再让 AI 生成初稿，让另一个流程找矛盾。语义没进代码和目录之前，所谓“AI-ready”常常只是给旧仓库换了块新门牌。
第三笔：价值账，调用量热闹不等于业务受益
Meta 的文章把视线从系统转向预算会。基础设施团队通常能说清吞吐、延迟、稳定性和采用率，却很难回答一句朴素的问题：这项平台投入究竟带来了多少新增业务结果？共享平台通过下游团队间接产生价值，又不能把工程师随机分成“允许用”和“不许用”两组，普通 A/B 测试并不好做。
作者团队把一次模型上线提案作为分析单元，把“是否采用某项基础设施能力”当作处理变量，把上线对应的广告收入结果作为结果变量。他们评估七类机器学习平台，并控制算力、团队规模与资历、模型大小与复杂度、上线时间等已观测混杂因素。对照组也不是所有未采用者，而是技术上本可采用、实际未采用的提案。
AI 生成解释图：使用率不能直接证明业务增量，选择偏差和因果假设仍需检验；不是 Meta 的真实实验图，也不代表任何收入数值。
结果出现了反差：一个几乎所有生产模型都经过的基础层，按采用率看像头号功臣；控制上述因素后，它对每次采用上线的增量贡献较小。另一个采用率不高的训练扩展平台，估计贡献约为前者两倍，并带来更多增量收入。团队因此调整了下一轮投资方向。
但方法和事实要分开。文章采用的是观察性因果推断，核心假设是：控制足够丰富的已观测因素后，采用平台近似随机。未被记录的团队能力、项目优先级或管理关注仍可能改变结论。文章还提到，早期样本约为单个半年度的 258 个提案，扩展到连续两个半年度后样本翻倍、估计更稳定；这能增强可信度，却不能把观察研究变成随机试验。
这篇文章由 Analytics at Meta 发布，署名为 Tong Wu 等七位作者。原始时间戳为 9 月 11 日 23:16 UTC，即上海时间 9 月 12 日；完整署名与原文链接列在文末。
国内数据平台做 ROI 复盘时，最容易拿登录人数、SQL 次数、覆盖表数当价值证明。这些是采用证据，不是业务增量。可借鉴的是证据结构：把采用记录落到项目或上线单元；找出有资格采用但未采用的可比对象；让业务结果与采用粒度对齐；同时记录算力、团队、复杂度和时间。若公司没有可归因到项目的收入，也可以换成审核时长、事故损失、交付周期等结果，但应诚实地称为近似证据，而不是在 PPT 上给相关性戴一顶因果关系的帽子。
拾穗判断：三笔账要分开记，也要一起看
这三篇材料没有给出一套可复制的 AI 架构，反而提醒我们：AI 项目常把不同问题塞进同一个预算名称。在线存储的性能账，关心热路径是否可预测、容量是否有闸门、分析负载是否隔离；离线数仓的语义账，关心指标、粒度、负责人和质量规则能否被人和机器共同理解；平台投入的价值账，关心采用之后究竟改变了什么结果。三者相互影响，却不能拿一张“大模型调用量上涨”的图一起报销。
下周回到工位，可以只做三件小事。第一，选一条最关键的在线链路，画出请求上限、连接上限、尾延迟和离线逃生通道；第二，选一个 AI 常答错的指标，把业务定义、技术口径、粒度、负责人和质量规则写到同一处；第三，把平台使用记录落到项目，并提前约定要观察的业务结果与可比对象。先留下能复查的证据，再讨论重写、重建和追加预算。这样慢一点，却比让 AI 替一堆旧问题写一份漂亮总结便宜。
我叫石头，在数据行业里摸爬滚打了十几年，数字背后的逻辑，比数字本身更值得看。这里写的，就是这些教训——我觉得值得说出来的那部分。
来源
发现来源：Data Engineering Weekly #287 · by Ananth Packkildurai @ Data Engineering Weekly · 2026-09-14。聚合刊日期不代替原文日期。
- 原文：Rapidly scaling online storage to serve over 1 billion ChatGPT users · by Jon Lee, Chaomin Yu, Ben Ries @ OpenAI · 2026-09-11。
- 原文：(Re)Building an AI-Ready data universe at BlaBlaCar · by Maxime Rosina @ BlaBlaCar · 2026-09-09。
- 原文：Measuring What Matters: How Causal Inference Turned AI Infrastructure Into a Quantifiable Business Investment · by Tong Wu, Yang Zhang, Maggie Chen, Brad Hedges, Konstantin Golyaev, Gniewko Lubecki, Paolo Massimi @ Analytics at Meta · 上海时间2026-09-12（UTC 2026-09-11）。
