Apache Doris 4.1 正式发布！面向 Agent 三分归一统

见字如面，我是一臻

90后新手奶爸，探索Doris x AI

“深夜，Agent异常告警疯狂刷屏ing：知识库暂不可用。 这看着不是简单的bug，是架构问题。 小林心里清楚，Agent对接了多套存储系统：向量数据库存语义embedding、全文检索引擎存日志和文档、时序数据库存监控指标、OLAP用于决策分析。 Agent要回答一个问题，数据通常得在多个系统之间兜风，光数据序列化和网络延迟就够受的了。更别说还有个致命问题——这些系统之间没有统一的事务语义，数据一致性几乎没法保证。 "也许该换个思路了。"小林关掉电脑前，看着刚发版的Apache Doris 4.1，在备忘录里敲下这句话。

Doris 4.1 与 Agent

这两年Agent火得一塌糊涂，但真正动手做过的人都在吐槽： demo简单，生产玩具。

核心矛盾在于：Agent的本质是决策循环——感知、理解、规划、行动、记忆。

大家做决策时依赖过往经验和知识储备，Agent也一样。只不过人类的记忆是神经网络，Agent的记忆是数据基础设施。

一个成熟的Agent系统，需要同时处理几种截然不同的数据：

结构化业务数据——用户的订单、账户、配置，这类数据讲究精确查询和一致性

海量知识库——产品手册、常见问答、历史工单、FQA...这类数据需要语义理解和相似度召回

行为轨迹——Agent的思考链、工具调用记录、中间状态，这类数据是活的，随对话进行不断增长，还要支持回溯分析

可观测分析——模型服务、Agent、RAG等AI应用的实时可观测分析

传统的数据库擅长其一其二，但面对Agent这种什么都要的场景，不是扩展性不够，就是运维复杂度爆炸。

问题的根源在于：大多数OLTP和OLAP系统是静态数据的产物。它们被设计用来管理一个已经存在、相对稳定的业务模型。

但Agent的数据需求是动态的——对话上下文在变、工具调用链在变、知识库内容在变、甚至查询模式也在变。

Agent需要一种新型数据基础设施：既能管理静数据，又能承载实时数据；既能做精确查询，又能做模糊召回；既能保证一致性，又能保持灵活性...

Doris 4.1的演进方向，正是在回应这个需求。

向量+全文+结构化：三分归一统

向量检索、全文搜索、结构化分析，这三者长期被视为独立的技术领域。

Milvus们做向量、Elasticsearch们做全文、各路OLAP做分析，大家井水不犯河水。

但Agent场景把这三者强行拧在了一起。

拿RAG（检索增强生成）举例。

用户问："你们家客服最近处理最快的一个投诉是什么？从进线到结案用了多久？"

这个问题拆解开来：

第一步，要从向量数据库里召回语义相关的工单记录；

第二步，要从全文索引里精确定位到处理时长这个关键字段；

第三步，还要从结构化数据里快速关联计算时间差。

三个步骤、三套系统、三个接口，数据还得对得上。

Doris 4.1的核心方向是：用统一SQL把这三件事一次做完。

向量检索

向量检索层面，4.1版本的重点不是有没有，而是能不能规模化生产。

Ann Index Only Scan优化让向量搜索可以完全跳过原始列的I/O读取，配合IVF索引和IVF_ON_DISK的混合存储模式，100万向量规模下能做到900QPS、97%召回率：

# IVF 索引 示例
CREATETABLE sift_1M (
idintNOTNULL,
  embedding array<float>  NOTNULLCOMMENT"",
INDEX ann_index (embedding) USING ANN PROPERTIES(
      "index_type"="ivf",
      "metric_type"="l2_distance",
      "dim"="128",
      "nlist"="1024"
  )
) ENGINE=OLAP
DUPLICATEKEY(id) COMMENT"OLAP"
DISTRIBUTEDBYHASH(id) BUCKETS 1
PROPERTIES (
"replication_num" = "1"
);

# IVF_ON_DISK 示例
CREATETABLE for_ivf_on_disk (
idBIGINTNOTNULL,
  embedding ARRAY<FLOAT> NOTNULL,
INDEX idx_emb (embedding) USING ANN PROPERTIES (
    "index_type"="ivf_on_disk",
      "metric_type"="l2_distance",
      "dim"="128",
      "nlist"="1024"
  )
) ENGINE=OLAP
DUPLICATEKEY(id)
DISTRIBUTEDBYHASH(id) BUCKETS 8
PROPERTIES ("replication_num" = "1");

如上性能跑分有合意味？

直观而言：大多数企业的Agent场景已经完全够用，不需要为了一点性能提升去维护独立的向量集群！

并且，Doris 4.1索引构建速度优于Milvus、Qdrant、pgvector。

全文检索

在全文检索层面，search()函数的出现值得重点关注：将全文搜索能力直接嵌入 SQL 中，一条 SQL 同时完成搜索过滤与聚合分析。

-- Multi-condition: TERM + PHRASE + NOT evaluated in a single pass
SELECT request_id, error_msg, latency_ms
FROM inference_logs
WHEREsearch('
  level:ERROR 
  AND error_msg:"CUDA out of memory" 
  AND NOT module:healthcheck 
  AND model_name:gpt*
')
AND log_time > NOW() - INTERVAL1HOUR
ORDERBY latency_ms DESCLIMIT100;

-- BM25 relevance scoring
SELECT request_id, error_msg, score() AS relevance
FROM inference_logs
WHEREsearch('error_msg:"memory allocation failed" OR error_msg:"CUDA error"')
ORDERBY relevance DESCLIMIT20;

-- Nested search: query inside a VARIANT array
SELECT * FROM agent_logs
WHEREsearch('NESTED(steps, status:error AND tool:code_exec)');

-- search + aggregation: filter and analyze in one query
SELECT model_name, COUNT(*) AS error_count,
       PERCENTILE_APPROX(latency_ms, 0.99) AS p99_latency
FROM inference_logs
WHEREsearch('level:ERROR AND error_msg:"CUDA out of memory"')
AND log_time > NOW() - INTERVAL1HOUR
GROUPBY model_name ORDERBY error_count DESC;

⚠️ 全文检索的结果可以直接跟结构化数据做联合分析，不需要额外的应用层处理逻辑！

结构化

人类在工作时会动用工作记忆——一次只能处理有限信息，但处理速度极快。

AI Agent也有类似的机制，只不过它们的工作记忆受限于大模型的上下文窗口。

当上下文窗口从4K扩展到128K甚至1M时，一个新问题浮现出来：这些长上下文本身怎么存储和管理？

传统的做法是外部存储+按需加载。

大模型需要什么，从对象存储或KV数据库里读出来，塞进上下文。

但这种模式的缺陷显而易见：数据是游离的，没法直接被查询和分析；上下文组装和解析需要额外的工程开销；数据的一致性和版本管理也是问题。

Doris 4.1原生支持单行100MB JSON文档，直接把长上下文这件事数据库化。

对于Agent何意味？

完整的对话历史、Agent的执行轨迹、工具调用的完整链条——这些以往只能存日志文件或者对象存储的数据，现在可以作为一个整体存入数据库，直接参与SQL查询。

换个角度说，Doris在这里扮演的角色更像是Agent的外部海马体——不仅存储，而且支持高效检索和联合分析。

对于那些需要回顾历史或分析决策过程的Agent场景，这个能力打开了很多可能性。

比如分析Agent最近一周的工具调用模式、找出导致回答质量下降的典型对话结构、或者快速定位某个复杂问题的决策链条。

另外，Agent场景的数据有个特点：杂、乱、多。

日志是杂的——字段随时可能新增；用户画像是乱的——不同用户的属性集差异巨大；埋点数据是多变的——业务迭代频繁，采集方案动不动就调整...

传统数据库要求schema提前定义、严格执行，这种设计在Agent场景里几乎没法用。

Doris的VARIANT类型和Segment V3存储格式，本质上是在解决同一个问题：如何让数据库适应数据的自然形态，而不是强迫数据适应数据库的刚性结构。

Segment V2的元数据集中在文件尾部，每次随机读取都要把整个footer加载进来。7000列的表、10000个segment，这个操作本身的I/O和解析开销就够喝一壶的。

V3把元数据按需加载，打开速度提升16倍、内存占用降低60倍——这组数字背后，是超宽表和半结构化数据场景终于有了靠谱的存储方案。

稀疏列优化则更进一步。

它解决的是热点path少、长尾path多的问题——实际查询中可能90%的请求都集中在10%的字段上，但如果存储层不做区分对待，每次查询都要扫描全部字段，效率自然上不去。

Sparse Sharding把长尾path分散到多个稀疏列，避免单列读放大；Sparse Cache则减少了重复I/O。

......

对于Agent场景来说，这些升级在于：数据结构可以快速演进，而不需要每次都做schema迁移或者数据重新导入，也能做到超宽表和高并发高性能访问

OLAP老本行

看到这儿，有小伙伴可能会问：Doris花了这么大篇幅迭代AI能力，会不会丢了OLAP的老本行？

数据说话：

SSB 14.3%、TPC-H 22.6%、TPC-DS 19.1%——这三个数字代表的是多表关联和复杂聚合能力，也是OLAP最核心的性能指标。

ClickBench冷查询性能和存储空间同样双项第一，说明在超大规模数据场景下的综合表现依然能打！

以下几个关键优化点，同样值得玩味：

聚合下推：让关联之前先瘦身

关联计算最怕什么？数据量太大。

几百GB的表join在一起，光是中间结果就能把内存撑爆。

Doris 4.1的升级思路是先压缩、再关联——把聚合操作下推到join两侧，先各自完成局部聚合，大幅削减数据规模，再做关联。

基准测试中，整体性能提升超过 200%,超过半数的查询提升超过50%，三分之一直接快了一百倍以上。

聚合扩展优化：先抓主要矛盾

多维聚合场景里，很多查询其实在做重复劳动——不同维度的聚合组之间存在冗余计算。

Doris 4.1会智能识别最细粒度的聚合组，先完成这层聚合把数据量压下去，再基于结果计算其他维度。

整体提升超过10%，最大能达到160%，而回退幅度始终控制在5%以内。

嵌套列裁剪：只读你关心的那部分

查询JSON嵌套字段时，传统做法是先把整行数据拉出来再过滤。

Doris 4.1能精确识别查询涉及哪些子字段，只读对应数据，无关字段统统跳过。

对包含大量嵌套结构的日志或用户画像数据，这个优化效果尤为明显——部分场景直接快了超 700%。

Condition Cache：过滤结果也能缓"

线上分析有个特点：同一类过滤条件会被反复执行。比如查区域、查日期、查用户群，这些where子句每次都要重新扫描一遍Segments。

Condition Cache把过滤结果缓存下来，下次查询直接复用。

改动不大，但复杂查询场景下能稳定省出10%以上的开销。

中间结果 Cache：重复的聚合不用重算

T+1报表跑得好好的，早上六点准时出结果。但业务突然要求实时看同一个指标，查询压力就上来了——数据没变，但每次刷新都要重新扫描、重新聚合。

中间结果Cache解决的就是这个问题：相同的聚合查询，在数据未变更时直接返回缓存结果，拒绝无效计算。

CASE WHEN优化：让分支判断更聪明

CASE WHEN是分析场景的万能语法，但也是查询引擎的噩梦——分支多、条件杂、重复计算到处都是。

Doris 4.1通过分支合并、公共子表达式提取、枚举值下推等手段，让包含大量条件判断的查询跑得更快。

平均提升200%，个别场景直接快了五十倍。

除了以上的升级迭代，还有存算分离、湖仓一体、离线计算、易用性等能力增强，具体可查阅：Apache Doris 4.1：面向 AI & Search 的统一数据存储与检索底座

我一直有个观点：OLAP性能不是孤立存在的，它最终要服务于数据洞察的实时性。当查询延迟从分钟级压到秒级，业务决策的节奏就会随之改变；当分析结果能从T+1变成实时，运营策略就能更快迭代。

Doris在4.1版本的表现，某种程度上验证了这个逻辑——性能提升从来不是终点，而是让更多Agent业务场景敢用实时分析的手段。

结语

回到开头那个背景。

小林后来真的把Agent数据底座改为了Doris 4.1。迁移过程比预想的顺利，两个月时间，三套系统并成一套。

他说最大的改变不是性能提升了多少，而是终于不用每天盯着不同DB了。

"Agent需要什么数据，系统就能提供什么数据，不需要我去协调三四个存储团队。这大概是我第一次觉得，数据架构变得以Agent为中心了。"

这大概就是Doris 4.1想做的事——不是做一个能做向量检索的OLAP，而是做一个能让Agent专注决策的数据引擎。

数据的问题交给数据库，Agent的精力留给业务。

这个方向对不对，时间会给出答案。