Doris赌大的，StarRocks做减法

同一个技术源头长出来的两个实时 OLAP 引擎，在这个周期里交出了两份气质完全相反的答卷。

Apache Doris 推出了 5.0 Preview，主打一个关键词：统一多模态湖仓（Unified Multimodal Lakehouse），把开放格式集成、Variant 半结构化分析、向量分析、乃至 Physical AI 和 agent 场景一股脑塞进了预览版路线图。StarRocks 则发布了 4.1，标题写得很克制——Built for Production, Designed to Simplify，为生产而生，为简化而设计。

一个在讲三年后的故事，一个在讲这个季度的理由。这个分叉本身就是产业信号：实时分析引擎的竞争维度，正在从单纯的查询性能，转向『数据底座叙事』与『生产确定性』两条赛道的争夺。

🧬 同一个起点，两条岔路

圈内聊起这两个引擎，常用一句话概括：一树两枝。

Doris 源自百度开源的 Palo 项目，进入 Apache 基金会后逐步成长为准顶级项目，在国内实时分析、用户行为分析、报表加速场景铺开了大量案例；StarRocks 由 Doris 早期核心成员出走后创立，走商业化公司路线，主打湖上查询加速与存算分离。同一个协议兼容生态、同一批早期用户心智，但组织路径决定了产品哲学的分化。

这次两个版本的发布，把分化摆到了台面上：

这背后是开源基础设施最经典的两种活法：社区广度派，靠不断吸收新叙事扩张边界；商业深度派，靠把成熟能力打磨到『敢签 SLA』换取大客户续约。

没有谁对谁错。但值得记住的是：当一家公司停止追逐新概念、开始强调『为生产而生』时，说明它的重心已经从获客转向留客；而当一个社区项目开始做 Preview、讲多模态时，说明它在为下一个三年的心智卡位下注。

🚀 Doris 5.0：把实时湖仓往多模态推

这一版 Doris 的野心，写在标题里：A Unified Multimodal Lakehouse for Real-Time Analytics。

拆开看，四个动作指向同一个目标——把实时分析引擎升级为 AI 时代的数据底座。

第一，开放格式集成。湖仓这些年的共识是数据不动、格式先行，Iceberg、Paimon、Hudi 这类开放表格式成为事实标准。引擎与开放格式打通，意味着数据可以留在湖上、按需加速，而不是被锁进私有存储。这是湖仓一体从口号走向落地的分水岭。

第二，Variant 类型。半结构化数据（JSON 一类）长期是分析引擎的痛点：要么提前建好 schema 做重 ETL，要么牺牲查询性能做宽松解析。Variant 的思路是原生承载任意结构、按需解析，让『先入湖、后建模』真正可用——这对日志、埋点、设备上报这类 schema 漂移严重的场景是实打实的减负。

第三，向量分析。RAG 与语义检索的爆发，让向量库一度独立成栈。但当主分析引擎内建向量能力后，一个 agent 的『SQL 精确查询 + 向量语义召回』可以在同一张引擎里完成，不用再为了一次检索多养一套系统。

第四，Physical AI 与 agent 场景。机器人、车端、IoT 产生的多模态物理世界数据，需要实时落入分析底座，再被智能体消费。这是『Data for AI』叙事在 OLAP 领域的具体投射：

产业逻辑很清晰：Doris 5.0 对标的已经不是隔壁的实时数仓，而是 Snowflake、Databricks 那套『一站式 AI 数据云』的叙事。代价也很明显——Preview 意味着能力尚在验证期，多模态意味着每个方向都要打磨。战线拉得越宽，工程纵深越要够。

🏭 StarRocks 4.1：赌注押在『别出事』

和 Doris 的高举高打相比，StarRocks 4.1 的发布姿态几乎是反着来的。没有新叙事，只有两个词：Production 和 Simplify。

别小看这两个词。在商业化公司的语境里，这是最贵的两个词。

所谓生产化，落到底层是稳定性、可观测性、升级平滑、资源隔离这些『不出事』的能力。所谓简化，是部署更轻、运维更少、组件更收敛——直击的是企业客户的总拥有成本（TCO）。数据平台选型到了深水区，决定续约的往往不是 benchmark 上快百分之几，而是『半夜告警少几次』『版本敢不敢升』『要不要养一个专职 DBA 团队』。

一位在金融行业做数据平台的朋友私下说过大实话：『评审会上没人因为一个新特性拍板，但会因为一次升级事故否掉整个方案。』

StarRocks 这条路线的产业逻辑在于：湖上分析已经是存量竞争。当大家都能对接 Iceberg、Paimon、Hudi，查询性能的差距在缩小，客户比拼的变成运维成本和确定性。此时做减法，是精准踩点。

两个版本的路线对比，一张表看清楚：

一句话总结：预览版讲的是三年后的故事，4.1 讲的是这个季度续约的理由。

🤖 AI 数据正在改写 OLAP 的边界

把镜头拉远，这次分叉背后有一个更大的变量：AI 正在改变『分析』的定义。

过去 OLAP 引擎的服务对象是 BI 报表和数据分析师，核心指标是查询延迟和并发。而现在，新的负载正在涌入：agent 需要混合检索（SQL 精确查 + 向量语义查 + 全文检索），Physical AI 场景需要承接机器人与车端的多模态数据流，合成数据、训练集治理也需要分析引擎参与质量评估与血缘追踪。

这意味着引擎的评价体系正在重构。『能不能一张引擎伺候 SQL 与向量』『能不能原生吃下 schema 漂移的半结构化数据』『数据能否以开放格式在湖上自由流转』——这些正在成为新的竞争维度。

去年圈子里聊架构，画的是湖仓分层图；今年很多团队聊的已经是 agent 编排图。图表换了，底层要解决的问题没换：数据在哪、怎么查、谁来消费。区别只在于，消费方从人变成了机器，而机器对延迟、格式、一致性的要求比人苛刻得多。

Doris 5.0 的多模态押注，本质上是对这个变化的提前响应。而 StarRocks 的选择则隐含另一个判断：无论 AI 负载怎么变，生产环境的确定性需求不会消失，而且会随着 AI 负载上线变得更尖锐——毕竟没有人敢让一个不稳定的引擎托底 agent 的实时决策链路。

两条路线，其实都是在回答同一个问题：AI 时代的数据底座，到底该长什么样。

⚠️ 给选型者的三句话

叙事很热闹，回到工程落地，给正在选型或正在观望的团队三句实在话。

第一，预览版是信号，不是产品。Doris 5.0 Preview 展示的多模态方向值得认真跟踪，但 Preview 就是 Preview，核心生产链路不要第一时间切换。正确的姿势是：在非关键链路搭测试环境，验证 Variant 与向量能力在真实数据规模下的表现，把结论沉淀进自己的技术雷达。

第二，稳态业务优先看工程成熟度。如果你的核心场景是湖上分析、报表加速、面向大客户的稳定服务，StarRocks 4.1 的路线更对味——『简化』省下来的人力和故障成本，往往比性能提升值钱。

第三，迁移的隐性成本永远被低估。SQL 方言、权限体系、调度链路、上下游生态，任何一环的适配都可能吃掉几周的工程时间。没有明确的痛点，不要为了版本号迁移。

一张表给三类典型场景：

结语

同一个起点，两条岔路，这不是内耗，是市场分层。

实时分析这个赛道已经跑过了『拼性能』的阶段，接下来是拼叙事兑现能力和拼生产确定性的双线竞争。Doris 赌 AI 数据底座会成为引擎的新主业，StarRocks 赌确定性和 TCO 才是大客户的终极考题。

判断谁赢还太早。但有一点可以确定：2026 年回头看，真正重要的不是这两个版本讲了什么故事，而是预览版的能力有没有兑现成正式版的版本号，简化路线的承诺有没有兑现成客户续约的合同额。叙事会过期，落地不会。