快手把A/B实验提速145倍之后
快手将全公司A/B实验指标链路从Spark迁移至Apache Doris，指标计算提速145倍、资源消耗下降72%；同时基于Doris与Paimon 2.0落地向量检索与Agentic AI数据闭环。本文拆解这组生产实践背后的产业信号：湖仓竞争正从架构叙事转向账本叙事。
快手把全公司A/B实验的指标链路从Spark搬到了Apache Doris，指标计算提速145倍，资源消耗直接砍掉72%。同一家公司，又把向量检索和Agent的数据闭环建在了Apache Paimon与Doris的组合上。这两件事发生在同一家头部内容平台的生产环境里，值得认真读一读。
我的核心判断是：湖仓这条赛道的竞争，正在从架构图叙事转向账本叙事。谁能拿出「快多少倍、省多少钱」这种可以直接复述给CFO的数字，谁才真正拿到了下一轮话语权。
📉 一本算得清的账：145倍与72%
先讲场景。快手的体量摆在那里，A/B实验是全公司级别的日常动作——产品、算法、运营任何一次改动，几乎都要挂实验、看指标。指标链路的特点是：口径多、并行实验多、查询频次高，业务方要的是「点开就能看」，而不是「明天早上再看」。
过去这条链路跑在Spark上。批处理引擎擅长大规模离线计算，但在交互式指标查询面前，它的短板暴露得很典型：任务排队、调度开销、数据多跳搬运，用户体感就是「慢」和「等」。
快手做了一次彻底的重建：把指标计算链路整体迁到Apache Doris上。结果是两组数字——指标计算速度提升145倍，资源消耗下降72%。
| 维度 | 迁移前（Spark） | 迁移后（Doris） |
|---|---|---|
| 指标计算速度 | 基线 | 提升约145倍 |
| 资源消耗 | 基线 | 下降约72% |
| 数据模式 | 批处理离线计算 | 实时摄取+即席查询 |
| 业务体感 | 等报表 | 点开即看 |
这组数字的含金量要拆开看。145倍是体验问题，72%是成本问题，两者叠加意味着这条链路的性价比曲线发生了代际变化。据多位接近快手数据团队的人士说法，这类迁移不是拍脑袋决定，前期经过了严格的灰度验证与口径比对，指标结果对齐是硬门槛。
产业逻辑层面，我要说一句可能不太讨好Spark社区的话：批处理引擎并没有被否定，但「交互式指标计算」这个场景的主导权，已经被MPP引擎+实时摄取的组合接管了。场景和引擎的匹配度，比引擎本身的先进性更重要。这也是为什么「把Spark换成Doris」在很多公司成立，而「把Spark全砍掉」在多数公司并不成立。
🧩 Paimon的位置：湖不是缓冲区，是底座
很多公司的数据湖，实际角色是个缓冲区——数据落成文件，等着计算引擎来扫，扫完就没人管了。这是湖仓一体喊了多年、落地始终别扭的根源。
快手这条实践里，Apache Paimon扮演的角色不同：它是流式湖存储的底座，承接实时的数据变更，而Doris作为查询引擎直接对湖上数据进行检索和分析。数据不需要在湖和仓之间反复搬运，一份存储，多引擎直达。
Spark承担离线指标计算
引入Paimon承接实时湖存储
A/B指标链路整体迁移Doris
向量索引与Agent闭环落地
Paimon 2.0与Doris的集成深化，是这条路径成立的技术前提。湖格式层的更新能力、主键表的支持，让「湖上数据可实时变更」从论文里的目标变成了生产里的事实。
产业判断是：湖仓一体的真正落地形态，不是某一家的产品叫「湖仓」，而是湖存数据、仓算数据的分工协作。存储归湖格式，计算归高速引擎，中间省掉的每一次数据搬运，都是真金白银。那些还在为「湖和仓谁吃掉谁」站队的人，没看懂这场戏的主角其实是「搬运成本归零」。
🔍 向量检索进湖仓：IVF-RQ与Top-K下推
再往深处走一层。快手的内容生态天然产生海量embedding——视频、图文、用户行为，都是向量检索的用武之地。传统做法里，向量数据要从湖仓里抽出来，灌进专用的向量库，两套系统、两份数据、一条同步链路。
这次公开的生产实践里，快手的选择是：在Doris上、针对Paimon湖上数据，直接构建向量索引，用的是IVF-RQ这类索引结构，配合Top-K下推的优化手段——把Top-K的筛选逻辑下推到数据文件层，先粗筛再精排，减少实际扫描的数据量，在召回率和查询延迟之间取得工程上的平衡。
这里没有炫技的成分，全是工程取舍：召回率是底线，延迟是体验，索引结构选IVF-RQ而非更花哨的方案，图的就是稳定和可控。
产业判断更关键：向量检索正在从「独立产品品类」退化成「查询引擎的一种索引类型」。专用向量库当然有它的场景，但当业务需求是「过滤条件+排序+向量召回在同一条SQL里完成」时——这在推荐、搜索、风控里是常态——引擎内建向量索引的优势就是碾压式的。数据不用搬、事务不用对账、SQL生态直接复用。2024年以来向量数据库赛道的估值收缩，和快手这类实践的出现，是同一枚硬币的两面。
🤖 Agentic AI的数据闭环：被低估的另一半
聊到AI数据，大多数人第一反应是训练数据集和标注。但快手这组实践指向的是另一半：Agent运行时的数据供给。
一个Agent应用要跑起来，需要什么数据能力？Apache Doris与Apache Paimon 2.0的组合给出了一张完整的清单：
| 能力 | 作用 | 对应Agent环节 |
|---|---|---|
| 向量索引 | 语义召回与相似检索 | 上下文感知 |
| 实时数据摄取 | 提供新鲜的业务上下文 | 感知环境变化 |
| SQL查询能力 | 结构化事实的精确查询 | 推理依据获取 |
| 反馈写回 | 执行结果回流存储 | 学习与迭代闭环 |
注意最后一行。Agent要形成闭环，光能「读」不够，还得能把执行结果、用户反馈「写」回系统，供下一轮决策使用。这就要求底座引擎同时具备低延迟的读和高吞吐的写——恰好是湖仓引擎最近一直在补的能力短板。
产业判断：Data for AI分两层，训练侧已经被讲烂了，运行时侧才是下一个窗口。Agent大规模落地的瓶颈，不会是模型推理速度，而是「能不能在几百毫秒内把该有的上下文喂进模型，再把结果沉淀下来」。谁能同时搞定SQL和向量、读和写、湖和仓，谁就卡住了这个位置。
⚠️ 泡沫退潮后，工程判断的三个标尺
最后说点方法论。这两年数据基础设施领域的概念密度极高：湖仓一体、存算分离、多模融合、AI Native……PPT一个比一个漂亮，能拿出生产环境账本的凤毛麟角。
据多位接近头部平台数据团队的人士说法，大家在私下里反复比对的，从来不是功能清单，而是三个东西：延迟曲线、成本账单、回滚方案。快手这组实践之所以值得写，恰恰是因为三条全占了——145倍的延迟改善、72%的成本下降、完整的灰度迁移路径。
我把它总结成工程判断的三个标尺：
1. 可观测的延迟——数字要能被监控体系复现，不能只活在发布会里；
2. 可核算的成本——资源省了多少，财务口径要对得上；
3. 可回滚的路径——迁移失败时能不能体面地退回去。
凡是不能落进这三条的叙事，无论概念多新，都应该打折听。反过来，凡是能被这三条检验的实践，无论包装多朴素，都值得研读。快手没有讲「AI Native数据平台」的故事，它讲的是一条链路迁完了、账算清楚了——这才是这个行业稀缺的表达方式。
📌 小结
快手的这组生产实践，本质上是给整个湖仓赛道换了一把尺子：不再问「架构是不是先进」，而是问「账本好不好看」。145倍、72%、IVF-RQ、Agent反馈写回，每一个都是可以被验证的工程事实。往后的 twelve 个月，看数据基础设施公司，别看融资和概念，去看它的客户里有没有人愿意公开迁移前后的对比数字——有，就值得多看两眼；没有，就等一等。
账本叙事的时代，故事讲得再好，也不如一次算得清的重建。