2026年很多团队面对的不再是做不做数仓的问题而是统一数仓到底选谁。Apache Doris 和 StarRocks 的对比是我在各种技术社群里被问得最多的问题尤其是当话题从哪个SQL跑得快延展到AI时代能不能作为统一数仓的时候场面往往特别热闹。我的态度很明确要对齐AI时代的数据基础设施我会优先选 Apache Doris。这不算一个拍脑袋的结论而是从架构演进路径、生态整合程度、以及在真实项目中踩过的坑一步步验证出来的。这篇文章我会把判断逻辑完整拆开包括两者同源又分叉的历史、AI数据栈对统一数仓的真实要求、几个实际场景的对比测试结果以及最终可以带走的选型清单。1. AI时代的统一数仓先想清楚要统一什么1.1 过去的统一数仓是统一报表今天的统一数仓是统一事实在很长一段时间里统一数仓这个词对应的是明确的KPI把各个业务线的数据汇总到一套模型里统一指标口径统一报表出口。那时候选型核心看三件事离线批处理跑不跑得动、实时链路接不接得上、并发查询扛不扛得住。Apache Doris 和 StarRocks 都是在这个背景下壮大的二者在SQL性能、列式存储、MPP架构上都非常能打所以选型时经常被放在天平两端。但AI时代把统一的含义改变了。现在数据要服务的对象不只是BI报表还有模型训练、特征工程、RAG检索增强、实时推理、AI Agent的记忆管理。这些工作负载有个共同点它们需要的不只是报表能出数,而是同一份事实数据能在不同计算形态之间平滑流动。今天你在Doris里维护的订单事实表明天可能要被特征任务拉出去做宽表后天又要被一个Agent应用实时查询拼接成Prompt上下文。如果这些场景各搞一套数据副本那统一就是空话。1.2 为什么AI让数仓的边界重新模糊传统数仓边界很清晰业务库进数仓数仓出报表。但AI应用让数据链路变成了网状。以RAG为例一个问答系统既需要数仓里的结构化业务数据又需要向量库里的文档切片还需要实时更新的用户画像。如果数仓只负责报表那一亩三分地它就会被边缘化成为整个AI数据链路里的一个普通下游。反过来看那些在AI落地中走得比较快的团队都开始把数仓当作数据事实的中枢要求它既能管结构化表也能读数据湖里的文件还能直接做向量相似度检索并且能跟外部大模型API协作。也就是说统一数仓在AI时代的真正定位是成为所有数据形态的统一查询入口和统一事实层。基于这个定义再去评价Apache Doris和StarRocks你会发现两者的差距不在某个SQL的毫秒级性能上而在谁能更完整地承接AI带来的新数据负载。2. 同源双星从Doris到StarRocks的架构分化之路2.1 一段不太被提起的家族史很多刚接触这两个项目的人不知道StarRocks和Apache Doris并不是两个完全独立发明的东西。StarRocks早期是从Doris代码库分叉出去的所以两者的核心基因非常像都是MPP架构都是列式存储都做向量化执行都强调单集群内同时支撑高并发查询和复杂分析。这也是为什么网上那么多对比文章会纠结于TPC-H差多少倍物化视图谁刷新快因为底层架构的血缘关系太近了。但分叉之后两者的路线开始分化。Doris在2022年正式成为Apache顶级项目走的是开放治理、社区共建的路子代码演进、版本规划、功能优先级都会听取更广范围用户的声音。StarRocks走的是商业公司主导的路线迭代速度也很快尤其在性能调优、缓存策略、运维工具上有非常强的执行力。路线差异没有绝对的对错但它直接决定了后来很多功能特性的走向。你在2026年回头看会发现这两个项目已经长成了形态相近但性格很不一样的两套系统。2.2 分化之后生态路线与性能路线的分岔Doris这几年的主线非常清晰往全链路数据平台的方向走。它用Multi-Catalog统一了数据源接入用湖仓一体把外部数据湖纳入查询范围用存算分离把计算和存储解耦让一个集群同时扮演数仓、数据湖引擎、向量检索服务多个角色。相比单纯追求某个查询更快Doris更在意的是你能不能少搭几套系统就把事办了。StarRocks则把更多精力放在更快、更稳、更好用的OLAP体验上。它的查询优化器、物化视图、主键模型更新机制都非常成熟在纯分析场景下能交出很漂亮的性能数据。对一个以BI报表和实时分析为核心、暂时不需要太多外部数据交互的团队来说StarRocks是非常强力的选择。问题在于当AI负载涌进来之后你会发现自己需要的不仅是快的查询引擎而是一个能跟数据湖格式、向量检索、大模型API深度耦合的平台。在这一层Doris的生态路线显然走得更远。3. Doris在AI数据栈里真正站得住脚的地方3.1 湖仓一体不只是能连而是能算很多数仓产品都宣称支持数据湖但实际用起来差别很大。能连指的是能建一个外部表查一下湖上的Parquet文件这叫连上了。而AI时代的数据场景要求的是能算你在Iceberg、Hudi、Delta Lake上存了几百TB的原始数据Doris要去扫描它的时候能不能把过滤条件下推到文件层面能不能利用湖表的元数据做分区裁剪能不能在读取时直接完成数据转换和聚合如果只是把数据拉回本地再算那跟你用Spark跑一遍没有本质区别统一数仓的意义就没了。Doris的Multi-Catalog在这一点上做得比较扎实。它对外部表不是勉强能用而是把谓词下推、分区裁剪、向量化读取都打通了实测在Iceberg上的查询性能已经接近查询本地表的水平。这对AI场景极其关键因为AI应用很少只查数仓内部那几张小表大量训练样本、日志数据、文档快照都放在数据湖里。统一数仓如果能把数据湖当成自己的一部分来算而不是当成一个需要导数据的外部系统整个AI链路的复杂度会直线下降。3.2 向量检索与AI函数的原生整合RAG、向量检索、文本嵌入是过去两年AI应用里最热的基础设施词汇。很多团队的做法是单独搭一个向量数据库再写一堆同步任务把数仓里的数据往向量库里灌。这套方案能用但维护成本很高最麻烦的是数据一致性数仓里的业务字段改了向量库里对应的切片往往没跟上。Doris从数仓侧给了另一种解法在表结构里原生支持向量类型和向量索引让同一个表既能存结构化字段又能存Embedding向量还能在同一套SQL里完成业务条件过滤加向量相似度排序。这意味着你的统一数仓可以直接变成一个带向量能力的OLAP引擎而不需要再额外引入一套专用向量库。再加上它内置的AI相关函数可以直接调用外部大模型API做文本分类、信息抽取、向量化等操作很多以前要写Python服务才能完成的活现在一句SQL就解决了。这个整合度在2026年看依然是Doris对比StarRocks的一个明显优势。3.3 存算分离架构对AI工作负载的适配AI数据负载有个典型特征潮汐性极强。白天在线服务要低延迟查询晚上训练任务要大规模批量扫数周末还可能跑一轮全量特征重算。传统的一体化MPP架构遇到这种负载会很痛苦因为计算和存储绑在一起扩缩容都是集群级别的操作为了晚上的重算任务去买一堆机器白天就闲置了。Doris的存算分离模式把这个问题解决得比较优雅。计算节点可以独立扩缩容存储落在对象存储或HDFS上数据在多个计算组之间共享。训练任务来的时候临时拉一批计算节点跑几个小时跑完再释放成本弹性非常好。而且存算分离不是把Doris改造成另一个架构而是保留了原有的SQL能力、导入能力和查询优化逻辑对上层应用是透明的。这个特性对AI团队特别友好因为你不需要专门为训练负载再造一套数据管道直接用现有数仓的计算组就能弹性应对。3.4 社区演进速度与可迭代性选型的时候很多人只盯着当前版本的功能对比但我更看重这个项目明年会长成什么样。Apache Doris的社区治理模式决定了它的功能演进会更贴近用户的实际声音而不是只服务于某几家大客户的定制需求。过去两年Doris在湖仓格式、AI函数、存算分离上的快速迭代就是这种社区驱动模式的结果。Apache孵化器和顶级项目的身份也让它在代码合规、版本发布、演进透明度上有更强的约束这些都是企业级选型时不能忽视的隐性价值。StarRocks的社区和商业团队的执行力同样很强尤其在企业版工具链、技术支持响应方面商业客户会有不错的体验。但如果你对自己的数据平台有长期自主掌控的诉求希望核心路线不被单一厂商绑定Doris的开放社区结构会更舒服。我在实际项目里体会很深的一点是遇到问题去Doris社区提Issue或PR响应链路是公开透明的而不是在一个商业支持工单系统里等着被排优先级。这种可迭代性在AI这种变化很快的领域里价值会越来越大。4. 场景对比实测湖仓一体、特征回填与Prompt实时拼接4.1 场景一湖上Iceberg全量表与Doris实时表Join第一个实际场景是典型的湖仓一体混合查询订单明细全量表存在Iceberg上按天分区实时变更流则在Doris里维护了一张当日增量表。以前我们是用Spark先读湖表、再拿增量数据做一次批量合并链路长、延迟高运营看板的数据经常慢半天。后来改成直接在Doris里建Iceberg外部Catalog再用一条SQL把湖表跟内部实时表做Join整个流程缩短到分钟级而且口径完全统一。StarRocks也能做类似的外表Join但对比下来的感受是Doris在湖表上的分区裁剪和谓词下推更彻底尤其是Iceberg这种带Manifest文件的格式Doris对它的元数据解析做得更细。这条场景对AI链路很重要因为很多特征任务需要历史全量加今日增量的拼接视角统一数仓能直接用SQL完成这件事就不需要再额外维护一套批次合并的代码了。对比项Apache DorisStarRocksIceberg外表查询元数据解析与谓词下推更彻底可用但复杂谓词下推有限湖表与内表Join单SQL直接完成优化器全局考虑可用调优成本稍高运维链路Catalog统一管理多个湖同样支持但外部生态整合略少这个表格是实际对比的大致结论不否认不同版本、不同数据分布下结果会有差异但从整体架构取向上看Doris在湖仓一体场景里确实是更顺手的那一个。4.2 场景二特征回填任务的SQL化替代第二个场景更贴近AI特征回填。以前我们做用户行为特征是拿Python脚本从Hive里扫数据、清洗、拼特征、写回宽表一个任务几百行代码每次改特征都要重新调试非常痛苦。后来我们把核心特征表迁到了Doris并且把回填逻辑改成了SQL物化视图加INSERT OVERWRITE的方式效果立竿见影。比如用户最近7天活跃天数这类特征用Doris的窗口函数和聚合能力几行SQL就能写完而且跑批速度比原来的Python加Spark脚本快不少。更关键的是SQL化的特征逻辑可以直接复用原来数仓里的维度模型和口径不会出现特征工程和BI报表各说各话的情况。StarRocks在SQL能力上同样不弱但结合Doris对数据湖和外部数据的统一访问能力我们可以把更多原始来源直接纳入特征计算不需要先导成内部表。这个少一次导入的差距在特征数量多了以后会被放大得非常明显。4.3 场景三RAG应用里的实时上下文拼接第三个场景是我觉得最能体现Doris适合AI时代的案例也是和RAG强相关的。我们有一个内部知识问答Agent回答问题时需要实时取用户的权限信息、历史行为、最近浏览过的文档再跟大模型API做上下文拼接。这套逻辑以前是Redis存用户状态、ES做文档检索、MySQL取业务属性一个请求要查三四个系统然后自己在代码里把结果拼成一段Prompt。后来我们尝试让Doris承接这个实时上下文服务的角色。用户在Doris里有一张视图把权限、行为、文档切片全部通过视图关联好再配合向量检索能力应用只需要一条SQL就能拿到所有需要的上下文。这条SQL既做了结构化过滤又做了向量相似度排序最后直接把结果交给大模型。实测下来同样的业务逻辑Doris方案比原来多系统拼装的方案延迟还低一些而且代码量骤减。StarRocks也在往这个方向走但Doris在AI函数和向量索引层面的原生度目前更胜一筹这正好是RAG应用最需要的那块能力。4.4 对比结论差距不在峰值性能而在链路完整性把三个场景放在一起看会发现一个有意思的结论单论某个查询的峰值性能StarRocks在很多情况下并不输甚至在纯大查询上有时还更快。但AI时代的统一数仓比的不是一条SQL能跑多快而是从数据湖里的原始文件到特征宽表再到实时上下文上下文你能不能尽量用一套系统、一组SQL、一个口径把它完整串起来。Doris在这条链路上的完整性做得更好湖仓一体管住数据源的多样性向量检索管住非结构化数据的相关性AI函数管住大模型API的协作这些能力在同一个查询里可以自由组合而StarRocks目前更擅长的还是极致的OLAP查询。所以如果你只需要一个性能强劲的分析引擎StarRocks是很好的选择但如果你想构建的是AI时代的统一数仓Doris的整体适配度确实更高。5. 2026年选型我判断的边界条件与落地清单5.1 什么时候StarRocks仍然值得选我不想制造一边倒的错觉任何选型都有边界条件StarRocks在一些场景下依然会是我推荐的那一个。如果你的核心业务是传统的BI报表、实时大屏、金融风控这类对查询延迟极度敏感的场景数据源比较单一团队也已经有成熟的StarRocks运维经验那完全没必要为了追AI概念而强行切换。商业版的技术支持、成熟的备份恢复工具、还有在生产环境里已经跑了一两年的稳定心态这些都是StarRocks的护城河。另一个要考虑的因素是团队的学习成本和历史包袱。如果你们的数仓团队这几年积累了大量StarRocks的调优经验核心模型也已经固化在StarRocks里那短期切换到Doris并不划算。最好的方式不是推翻重来而是把Doris作为一个新的AI数据节点引入让它在增量场景里发挥价值再逐步形成两套系统并行的过渡方案。5.2 我的落地决策清单下面这份清单是我在多个项目里反复用过的每当有团队问到底选Doris还是StarRocks我就让他们对着清单给自己打分。决策维度如果偏Doris如果偏StarRocks数据源多样性多湖格式、多外部数据源需要统一接入以内部表、少数外部源为主AI工作负载有RAG、特征工程、向量检索、大模型API协作以BI报表、实时分析、监控看板为主架构演进偏好希望一套系统承载数仓加湖表加向量希望极致单查询性能接受多系统组合社区与治理看重Apache开源治理、可自主迭代看重商业支持、企业级工具体验弹性成本有明显潮汐计算、需要存算分离弹性扩缩容负载相对稳定对扩缩容频率要求不高这个清单没有绝对正确答案但它能逼着团队把需求讲清楚。我见过太多选型失败案例不是因为技术不行而是因为根本没想清楚我到底要统一的是什么。拿这张表去问业务方和算法团队各打一遍分分歧基本就能浮出水面。5.3 一条经验选型永远是在选一个能持续进化的系统最后说一个我自己的体会。数据基础设施这个领域不存在一步到位的选项今天的最优解三年后可能就成了历史包袱。所以选型的时候比起当前版本的性能对比更重要的是看这个项目的演进方向是否符合你对未来的判断。Doris在AI方向上的布局包括湖仓一体、存算分离、向量检索、AI函数每一步都踩在AI数据需求的关键节点上而且这些能力是原生整合在一个引擎里的不是靠外部插件拼凑出来的。这种系统级的适配比任何单一Benchmark都更有说服力。我在实际项目里踩过不少坑最深的体会是不要被快牵着走要想清楚快是服务哪个目标的。如果目标只是报表查询变快那StarRocks依然能打但如果目标是让数据在AI时代持续流动、被反复使用、甚至在模型和应用之间来回循环那真正重要的就不是速度而是系统能帮你吞下多少种数据形态、整合多少种计算模式。从这一点看2026年的统一数仓选型我会更放心地把这一票投给Apache Doris。
