Doris 5.0，把赌注押在了湖上

OLAP 圈这两年喊了太多『湖仓一体』，但大多数读者已经免疫了。真正值得盯的信号是：当 Apache Doris 4.1 开始认真做全文检索、5.0 Preview 直接打出多模态湖仓的牌时，说明实时分析引擎的竞争，已经从『谁的 Join 更快』变成了『谁能在湖上吃下更多数据形态』。这一轮，胜负手不在加速器，而在数据类型和查询接口的边界。

🔍 先从一条日志说起

凌晨两点，SRE 的告警群里炸出一条错误日志。老派的玩法是：先把日志扔进 Elasticsearch 建倒排索引，搜出关键字段，再导回到 ClickHouse 或者 Doris 里跑聚合、算错误率。两套系统、两份数据、两个查询接口，中间还隔着一个 ETL。

这是几乎所有做可观测性和 SIEM 的团队都踩过的坑。Apache Doris 4.1 给出的答案是 search() 函数：在标准 SQL 里直接写全文检索条件，底层用倒排索引加速，打分用 BM25，匹配结果再无缝接入实时聚合与窗口计算。日志搜索和实时分析，第一次在同一个引擎、同一个接口里完成。

素材里的定位很明确：面向可观测性、SIEM 和产品搜索三类负载。这三类负载过去分别归属 ES、SIEM 专业产品和独立搜索引擎，现在被一个分析引擎横向切入。据多位接近开源社区的人士透露，这种『用一个 SQL 函数合并两套栈』的思路，在社区内部的优先级比单纯再快 10% 的执行器优化要高得多。

产业逻辑很清晰：OLAP 引擎的同质化已经到了瓶颈期，大家都是向量化、都是 MPP、都是列存。差别在于谁能把新的查询形态——全文检索、向量检索——原生纳进 SQL 语义。接口即入口，谁能承接更多查询形态，谁就多一条迁移的理由。

⚡ 版本节奏里藏着两条路线图

把两个版本的发布动作摆在一起看，路线图其实非常清楚。

4.1 关键词是『统一』：把搜索负载统一进 SQL。5.0 Preview 关键词是『多模态』：把数据形态统一进湖仓。前者解决的是查询接口的问题，后者解决的是数据模型的问题——半结构化数据用 Variant 类型直接存查，向量数据原生支持相似度分析，开放格式让湖上的 Parquet 等数据无需搬运即可分析。

这不是孤立动作。同期 StarRocks 发布 4.1，官方口径是『Built for Production, Designed to Simplify』——为生产环境打造，为简化设计。看得出两个同源引擎的分工出现了微妙分化：Doris 在往前抢新场景的叙事制高点，StarRocks 在往回夯实生产可用性。

私下有做引擎选型的人说过一句大白话：『聊 POC 聊得热闹的是新功能，决定客户敢不敢上生产的是稳定性和运维简化。』两条路线没有对错，但节奏差，反映的是对客户决策链的不同判断。

🌊 Variant 才是 5.0 的底牌

很多人看到 Doris 5.0 Preview，注意力都在向量分析和 AI 上。但真正改变工程落地成本的是 Variant 类型和开放格式集成。

做过数据平台的人都懂那种痛：上游业务改一个埋点字段，下游数仓就要跑 schema migration；一条嵌套很深的 JSON 日志，要么拍平成几十列，要么塞进字符串列牺牲查询性能。Variant 这类半结构化类型的出现，本质是让引擎自己『读懂』嵌套结构，按需展开列存，schema 变更的运维成本被大幅压低。

这张结构图里的关键假设是：数据不再需要为了分析而搬家。开放格式集成意味着湖上的数据保持原样，Doris 作为统一的计算和分析层直接接进去。这正是对『湖仓一体』最工程化的诠释——不是建一个新的存储格式取代谁，而是让分析引擎成为开放格式之上的通用查询层。

产业判断：过去十年，OLAP 引擎靠『存储格式+执行器』的垂直整合取胜；下一个十年，存储已经被 Iceberg 等开放格式的事实标准锁定，竞争焦点转移到计算层对数据形态的覆盖广度。Variant 和向量类型，就是覆盖广度的两个新刻度。

🤖 Physical AI 是叙事，Agent 是落地

5.0 Preview 里最容易被低估的两个词，是 Physical AI 和 Agent。

Physical AI 通常指机器人、自动驾驶、智能硬件这类与物理世界交互的 AI 系统，它们产生的数据是大规模传感器流、点云、视频——典型的多模态数据。而 Agent 应用的特点是：高并发的上下文查询、向量检索、行为日志分析混在一起，且要求低延迟。

对这类负载，传统的『向量数据库 + 数据仓库』组合会重演日志搜索的老故事：两套系统、两份数据、两种延迟语义。Doris 5.0 的思路是把向量分析和 SQL 分析放进同一个引擎，让 Agent 的记忆检索和业务聚合共用一条管道。

需要泼一盆冷水的是：向量检索目前有 Pinecone、Qdrant 等专业玩家，传统数据库厂商也都在补这块。Doris 的胜算不在于向量索引本身多强，而在于『向量 + SQL + 全文』三合一带来的架构简化红利。真实场景里，Agent 的查询从来不是纯向量查询，而是过滤条件 + 向量相似度 + 聚合统计的混合查询——这恰恰是通用分析引擎的主场。

⚔️ 同源双雄，正在镜像竞争

Apache Doris 和 StarRocks 同出百度 PALO 一脉，多年的路线分歧如今越拉越明显。

这组镜像竞争对用户其实是利好：一个在前面探路，把 AI、搜索、多模态这些需求趟成标准能力；一个在后面托底，把生产可用性打磨到位。两条路线最终大概率会互相借鉴——Doris 的多模态能力要过生产关，StarRocks 的生产口碑也需要新场景续血。

有一个数据产业层面的观察值得记录：这两个中国起源的顶级开源项目，如今是在全球范围内定义实时分析引擎下一代形态的主要玩家。过去这个位置属于 Snowflake、Databricks 和 ClickHouse。开源社区版本迭代的速度，正在成为全球 OLAP 创新的事实节奏器。

🧭 结语：从更快到更多

回到开头那个凌晨两点的告警。下一代的实时分析引擎，目标是让 SRE 在一个接口里搜完日志、算完指标、再顺手喂给一个排障 Agent。Doris 4.1 到 5.0 Preview 的演进，画出的正是这条路径：接口统一、模型统一、形态统一。

2026 年值得盯的判断是：多模态湖仓的叙事能否在真实生产负载里兑现。AI 的故事大家都会讲，但决定胜负的，永远是 Variant 的查询性能、向量检索的延迟曲线、以及开放格式集成的稳定性这些不性感的基础件细节。