六个数据库答一个问题，Agent先受不了了

深夜的广告平台机房里，一条“这个计划昨天花了多少钱、效果怎么样、要不要调价”的查询，要穿过数仓、湖仓和一排点查库才能得到答案。这并非个别团队的工程事故，而是行业普遍形态：广告平台把批量OLAP和实时服务拆在warehouse、lakehouse和一排point stores上，用六个数据库回答一个问题。而Agent时代的到来，正在把这种“分而治之”的架构逼到墙角——StepFun用一套基于Apache Doris的平台给出了另一种答案。

📉 六个数据库，答一个问题的日常

“数据库的数量，从来不是技术先进性的证明，而是架构演化欠账的计价单位。

先看一个典型场景。一家规模化广告平台的数据团队，每天要回答三类问题：运营要报表，算法要特征，服务要毫秒级响应。三类问题对应三套系统——离线数仓跑T+1的批量OLAP，湖仓存原始行为数据，线上服务靠KV点查库扛毫秒延迟，语义召回再叠加向量库，中间还要缓存和时序库补位。

这就是所谓的数据架构"sprawl"（蔓延）：一个业务问题，被切成了六份，分别躺在六个存储引擎里。

产业逻辑很直白：这套分裂架构是十几年需求叠加的结果，每一代新技术出现，团队就“加一个库”而不是“换一个库”。加法容易，减法没人敢做——因为每一次合并都意味着迁移风险和口径重构。这种多库拼装并非小团队的困境：在Apache Doris社区公开的技术案例中，小米、美团、腾讯等团队的一线工程师都曾描述过类似的“多引擎拼装、管道缝合”架构，且普遍把“系统数量”当作技术债的量化指标。真要收敛，阻力首先来自组织，而不是技术。

🧩 蔓延是怎么一步步形成的

“每一个新需求，都会催生一个新库；每一个新库，都会固化一支团队。

蔓延不是谁的设计失误，而是"best-of-breed"选型逻辑的必然产物。行为分析要列存扫描，选分析型数仓；人群圈选要点查，选KV存储；特征服务要低延迟，选内存数据库；embedding召回要向量检索，选专用向量库。每一项选型单拎出来都合理，叠在一起就是灾难。

这张图的问题不在节点，在边——每条边背后都是一条ETL管道、一套同步逻辑、一种一致性缺口。数据在六个系统之间来回搬运，同一张“用户表”有六个版本，同一个指标的口径要对齐六次。美团在公开的技术博客中就曾估算，其数据管道体系中仅“数据同步”环节就涉及数百条链路，专职维护成本高企。一位在广告平台做数据架构的朋友私下吐槽：他们最贵的工程师，一半时间在维护库与库之间的“数据摆渡船”。

从产业逻辑看，这种蔓延在三重力量下被固化：组织上，算法团队要自主可控，自建serving存储；技术上，没有一个引擎能同时覆盖分析、点查和向量，只能拼接；供应商上，每个品类都有自己的商业推手，预算越切越碎。值得注意的是，2019年之后湖仓概念的兴起，本质上是行业第一次尝试“往回收”——但湖仓主要解决的是离线侧的分析统一，线上服务侧的点查与向量检索，仍然是各管各的。

🚀 StepFun 用一个引擎扛住 PB 级 Agent 轨迹

“当负载变了，架构的答案也会变——Agent 可观测性就是那个新负载。

变化来自AI侧。大模型Agent跑进生产环境后，产生了一种全新的数据负载：每一条Agent执行轨迹（trace）里，包含工具调用、搜索行为、中间推理、成本开销、评估回环，量级直接上到PB。这就是StepFun面对的问题。

他们的解法是StepTrace——一个基于Apache Doris的PB级Agent可观测平台，用来实时分析Agent轨迹、成本、搜索行为、评估循环以及基础设施运行状况。

注意这个负载的特征：高吞吐实时写入、实时聚合统计、灵活多维查询、语义检索，全部要在同一个引擎里完成。放在五年前，这是一个典型的“多库拼装”场景——trace进日志库、指标进时序库、统计进数仓、语义检索进向量库，中间用管道缝合。StepFun选择用Doris一个引擎覆盖，说明这套负载在今天的实时引擎上已经可以收敛。

据StepFun工程师在Apache Doris社区技术分享中的公开披露，StepTrace的核心运行指标大致如下：

作为参照，Apache Doris官方公开的基准数据是：单集群可支撑数万QPS的毫秒级点查，亿级数据的聚合查询普遍在亚秒级返回；其3.0版本引入的原生向量索引与hybrid search能力，正是StepTrace能在单引擎内跑通混合负载的前提。而成本侧，StepFun在分享中给出的对比是：相比此前“日志库+时序库+数仓+向量库”的多系统组合，统一到Doris后，存储与计算资源成本下降了一半左右，且省去了多条跨系统同步链路的人力维护。

产业判断：Agent可观测性是一个信号弹。它和广告平台的高并发分析+实时服务负载在结构上高度同构——都是“写多读也多、既要统计又要检索”的混合负载。已有不止一家做Agent基础设施的公司在选型时，不再默认把向量库和分析库拆开采购。这不是某个产品的胜利，而是负载结构变化倒逼架构收敛的开始。

🔍 Agent 要的不只是向量检索

“只给Agent一个向量库，等于只给分析师一叠便利贴。

很多团队对Agent数据栈的第一反应是“上个向量库就行”。这个判断错在低估了Agent的运行时需求。一个生产级Agent，每次决策都要回答两类完全不同的问题：

第一类是检索问题：找出与当前任务相似的历史案例，靠embedding做语义召回；同时要按用户ID、时间窗口、权限标签做严格的标量过滤。

第二类是分析问题：过去一小时某工具的调用成功率是多少？失败轨迹的成本分位在哪？哪类任务的平均步数在恶化？这些是实时的聚合统计，向量库完全无能为力。

如果这两类问题分别落在向量库和分析库，Agent在运行时就要跨两个系统查询——延迟叠加、数据不同步、运维翻倍。这正是StepTrace用Doris一个引擎回答的问题：AI Agent需要实时分析，而不仅仅是向量搜索；Doris的思路是在一个实时引擎里提供原生混合检索（hybrid search），把向量检索和标量过滤、实时聚合放进同一个查询。

这里有一个容易被忽略的工程细节：混合检索的价值不只是“省一个库”，而是过滤与召回在同一个查询计划里完成。先在向量库召回一千条、再用标量条件过滤到十条，和在分析引擎里“带过滤条件的向量检索”，在正确性和延迟上是两回事——后者避免了召回集与过滤集之间的不一致窗口。对实时性要求高的Agent运行时来说，这个窗口就是故障隐患。

⚖️ 收敛的账怎么算

“架构收敛从来不是信仰问题，是成本问题。

把前面几个点串起来，可以算一笔账。六个数据库的显性成本是许可证和机器，隐性成本是四条同步管道的维护、六套口径的对齐、以及跨系统排查问题时的人时。而收敛到统一实时引擎后，管道消失、口径归一、故障域收窄——代价是单引擎必须同时把分析、点查、向量三件事都做到生产级水位，这对引擎本身是极高的门槛。

从公开案例的数据看，这笔账已经能算出量级：StepTrace用单引擎替代四类系统，资源成本降约一半；Doris社区中另有电商与广告类团队的分享显示，把“分析+服务”双负载从多引擎迁到统一引擎后，运维人力通常能省出一个专职团队。当然，这些数字各有各的口径，不能直接平移到任何一家公司——但方向一致：省的不是机器钱，是管道钱。

所以我的判断是：收敛不是六个库变一个库，而是中间地带的持续扩大。冷数据归档和极端点查短期内仍会独立存在，但过去必须靠三四个库拼装的核心业务负载——实时分析加混合检索——正在被单一实时引擎覆盖。StepTrace的意义不在于它是一个产品案例，而在于它验证了“PB级+实时+混合负载”这个此前必须拆分的组合，如今可以在一个引擎里跑通。

对广告平台和其他重数据负载行业而言，真正的动作项是：盘点自己的“数据摆渡船”，把那些为了绕开引擎能力缺口而存在的同步管道，逐条标记出来——每一条管道，都是下一轮架构收敛的候选标的。

小结

六个数据库回答一个问题，是十几年的需求叠加和best-of-breed选型共同造成的架构债；Agent的实时负载把这层债的利息放大了。StepFun基于Apache Doris的StepTrace用公开数据证明：每秒百万行的写入、亚秒级的聚合、数百毫秒内的混合检索、约一半的成本节省——实时分析、混合检索和PB级可观测，已经可以在一个引擎里收敛。接下来两年，值得盯的不是“又一个新数据库”，而是统一实时引擎的能力边界往哪扩——边界每推一寸，就有一条同步管道该被拆掉。下一次深夜机房里那条查询，也许只需要问一个库。