为什么实时数仓正在重新定义高并发？

摘要：传统 OLAP 谈高并发，盯的只是查询快慢；实时业务把查询、写入、更新和多业务抢资源全压在了一起。Doris 和 StarRocks 在查询并发上都能打，但落到真实生产环境，Doris 在高频小批量写入（Group Commit）、高频更新（灵活列更新、Time Series Compaction）和资源治理这几层覆盖更完整。选型别只盯 Benchmark 数字，要看复杂负载下系统能不能长期稳。

过去几年企业选实时分析数据库，盯得最紧的往往是同一件事：SQL 跑得快不快。TPC-H、ClickBench 这些公开 Benchmark，大家基本都是看查询耗时、吞吐和复杂 SQL 的执行效率来给数据库打分。这种比法确实把实时分析库往前推了一截，MPP、CBO 优化器、向量化执行也顺势成了行业标配。

但业务越来越实时之后，数据库背的压力早就不是那么回事了。

今天一个实时分析系统身上往往同时压着好几样活：实时 BI 查询、用户画像、风控决策、推荐系统、CDC 同步、日志分析，还有 AI 应用的数据访问。它们凑在一起带来一个共同难题——数据库不光得把查询算得快，还得在高频写入、实时更新、多业务同时打过来的时候不抖。

所以现在聊实时分析库的高并发，已经不能只问"一条 SQL 多快"，更要看它在真实生产那种乱糟糟的负载下，能不能一直稳得住。

Doris 与 StarRocks：高并发的竞争早就超出了查询本身

在实时分析库这块，Apache Doris 和 StarRocks 都是绕不开的选项。两者底子都够现代 MPP 分析库的水准：CBO 优化器、Pipeline 执行、向量化计算、Runtime Filter 一个不缺，单看传统 OLAP 查询，都能扛住大量分析场景。

传统高并发只看 Query，实时业务要的是整条链路

老 OLAP 系统干的事很单纯：数据落进数仓，用户甩过来一条 SQL，数据库把结果丢回去。那时候查询快慢基本就是唯一标尺。

可现在越来越多公司希望分析库直接顶到业务前面。用户画像和推荐，得实时读出用户的标签、行为历史、兴趣偏好和最近干了什么；风控在交易发生的那一瞬要查用户风险等级、历史交易、设备信息和异常行为；运营平台要实时盯着活动效果、转化和商品状态。这些场景的共同点是请求量大、延迟还要低，而且后台的数据写入和更新一刻不停。

换句话说，实时分析库现在要扛的已经不是单纯的查询并发，而是查询、写入、更新再加多业务抢资源叠在一起的综合压力。

第一类能力：高并发查询靠的是执行引擎

高并发查询从来不只是把 SQL 调优就完事。一堆用户同时打过来，真正麻烦的是：多个查询怎么把 CPU 用匀、大查询怎么别把小查询拖垮、延迟怎么一直压住。这些都要靠执行引擎本身的设计。

Doris 和 StarRocks 都走 Pipeline 执行模型，把任务拆细来提升 CPU 利用率。Doris 这边在这个模型上又往前走了一步，用更细的调度粒度、多线程并行，把复杂查询和高并发场景下的资源利用率再往上提。受益最明显的是 Dashboard 高并发访问、多用户实时分析、即席查询，以及多业务共用一个分析集群的情况。

不过查询并发还只是实时系统的一半。真正头疼的是：查询在跑，数据也在不停变。

第二类能力：高并发写入要压住事务、版本和 Compaction

实时业务最大的变化就是数据活了。早先数据基本是追加写，现在是一直在变：订单从创建、支付、发货到退款，状态从头到尾在动；用户从浏览、点击、收藏到下单；设备在线、离线、状态来回切。每一步都会甩出大量 Insert、Update、Delete、Upsert。

所以实时库必须解决高频写入。小批量写入要是处理得不好，事务数会暴涨、数据版本堆得快、Compaction 压力上来，最后把查询也拖慢。

Doris 的 Group Commit 怎么扛住高频写入

Apache Doris 有 Group Commit 机制，专门对付高频小批量写入——思路很直接：把多个并发的小写入攒一批合并提交，少走几趟事务提交，把多余开销降下来。Flink CDC 同步、Kafka 写入、用户行为分析、IoT 采集这类场景都吃这一套。

材料里 Doris 标了支持 Group Commit，StarRocks 没有。所以在实时、小批量数据持续灌进来的场景，Doris 的写入链路明显更贴高并发实时业务。

第三类能力：高并发更新比查询更考设计

很多实时业务真正的坑不在查询，在更新。查询只读已有数据，更新却要改已有数据，还得顺手维护数据版本、索引、存储结构和后台整理。

拿用户画像举例，原数据里 user_id 10001 是 Gold、score 900，行为一变 score 变成 950。数据库得想清楚：要不要整行重写、怎么快速定位、索引维护成本怎么压、几十亿次更新之后查询还能不能稳。

Doris 在高频更新上的设计

Doris 给实时更新准备了一整套：行更新、部分列更新、灵活列更新、Segment 存储索引按需加载、并发更新索引，还有 Time Series Compaction。这些主要就是压高频更新带来的维护压力，典型场景就是用户画像、实时标签、订单状态和风控数据。它们关心的不是一次 UPDATE 多快，而是每天几十亿次变化之后系统还稳不稳。

反过来 StarRocks 也支持行更新和部分列更新，但从材料列的对比看，Doris 在灵活列更新、索引维护、高频导入优化和 Time Series Compaction 这些点上覆盖得更全。

第四类能力：混合负载下高并发靠的是资源治理

生产环境里一个集群很少只跑一种业务，BI 报表、实时接口查询、数据开发任务、CDC 导入经常挤在一起。没点资源治理，一条复杂查询就能把别的业务全带崩。

所以高并发库还得有查询隔离、资源隔离、多租户和大查询控制。Doris 支持物理资源分组、逻辑队列限制，以及 CPU、内存、IO 的资源隔离，就是为了让不同业务互相少干扰。对企业级数据平台来说，这套东西往往比单次 Benchmark 的数字更实在。

Doris 与 StarRocks 高并发能力总结

单看传统 OLAP 查询，Doris 和 StarRocks 都够强；真进了生产环境——查询不停、写入不停、更新不停、多业务一起打——差距才会慢慢显出来。

结论其实不复杂：传统分析场景的高并发查询，两者都能撑住；但落到实时业务那种复杂高并发，Doris 的整体能力更完整。这背后不是某一个 Benchmark 数字赢了，而是 Doris 从查询执行、实时写入、数据更新到资源治理，每一层都是照着现代实时数据平台的复杂负载去设计的。

对企业往后的数据底座来说，高并发早就不是"能撑多少 QPS"那么简单，而是数据和业务一直在变的压力下，数据库还能不能长期稳定地给实时服务。这也是实时分析库下一阶段真正要比的地方。