【企业级AI Agent x 数据系统】【01】OLAP 引擎深度横评：Doris / StarRocks / Trino / ClickHouse 的工程权

数幄科技

311人浏览 · 2026-05-22 13:48:14

数幄科技 · 2026-05-22 13:48:14 发布

OLAP 引擎深度横评：Doris / StarRocks / Trino / ClickHouse 的工程权衡

Deep Comparison of OLAP Engines: Doris, StarRocks, Trino, and ClickHouse

—— 数据基础设施技术札记 · 2026

摘要 OLAP 引擎在过去 5 年涌现了 4 款明星产品：Apache Doris、StarRocks、Trino（PrestoSQL）、ClickHouse。它们的设计哲学截然不同——Doris/StarRocks 走 MPP 路线追求易用与高性能；Trino 走联邦路线专注跨源查询；ClickHouse 走极致单表路线追求大宽表性能。本文系统横评这 4 款引擎，从架构定位、性能基准（TPC-H 100GB + SSB）、8 维特性矩阵、综合评分雷达图、以及选型决策树多个角度对比。基准测试结果：在 TPC-H 联机查询上 StarRocks 最快（中位数 3s）、Doris 接近（4s）、Trino 居中（5s）、ClickHouse 在多表 JOIN 上偏弱；但在 SSB 单表场景下 ClickHouse 反超（0.5s），相比其他 3-5×。结论：不存在「一个引擎打天下」的方案，大型企业实践常用「Trino + Doris/StarRocks + ClickHouse」三栈并存。本文不依赖任何特定产品立场，意在为团队 OLAP 引擎选型提供一份独立参考。

关键词：OLAP · Apache Doris · StarRocks · Trino · ClickHouse · MPP · Federation · TPC-H · SSB

1. 引言：OLAP 引擎的四国军棋

Figure 1. 4 款 OLAP 引擎的架构定位

2020-2026 这 6 年，是 OLAP 引擎技术变革最快的时期——从 Hive/Spark SQL 的「批处理为主」时代，迁移到 MPP + 列存 + 向量化的「实时分析」时代。在这一变革中，4 款开源 OLAP 引擎成为最主流的选择：

Apache Doris [1]：源自百度 Palo（2017 开源），MPP 架构 + MySQL 协议，定位「易用、SQL 兼容好」；
StarRocks [2]：2020 年从 Doris 分叉，MPP + 极致向量化，定位「性能最优」；
Trino（PrestoSQL）[3]：源自 Facebook Presto（2012），存算分离 + 联邦查询，定位「跨源查询、数据湖」；
ClickHouse [4]：源自 Yandex（2016 开源），定位「极致单表性能、实时大屏」。

这 4 款引擎的差异不只是「实现细节」，更是「设计哲学」的根本分歧——MPP 路线追求 SQL 兼容与传统 DW 体验、联邦路线追求数据湖灵活性、极致单表路线追求大宽表性能。选型不只是选产品，更是选定一条技术演进路径。

2. 架构对比：存算一体 vs 存算分离

Figure 2. 存算一体 vs 存算分离的架构对比

2.1 存算一体（Doris / StarRocks / ClickHouse 默认）

MPP 引擎默认采用「存算一体」架构——每个 BE（Backend）节点既有存储又有计算。优势：数据本地性强、查询性能最优；劣势：扩缩容需迁移数据（分钟到小时级）、存储与计算资源比例锁定。

Doris/StarRocks 的典型架构：

FE（Frontend）：SQL Parse、Plan 生成、协调；多 FE 通过 Raft 选主，保证元数据一致性；
BE（Backend）：数据存储 + 查询执行；通过 Tablet 分桶分布到多 BE；
Broker（可选）：访问外部存储（HDFS、S3）。

2.2 存算分离（Trino / StarRocks 新模式 / Snowflake）

存算分离把存储下沉到对象存储（S3/OSS）、表格式（Iceberg/Hudi）或独立数据库，计算节点纯无状态。优势：计算/存储独立扩缩容、可联邦查询多源；劣势：数据本地性差（需要远程读）、性能比存算一体略损 10-30%。

Trino 是存算分离的代表，可同时查询 S3 + Iceberg + Hudi + MySQL + PostgreSQL + Kafka 等多种数据源。StarRocks 3.0+ 也支持存算分离模式，可对接 Iceberg/Hudi 等 Lakehouse。

▎工程见解 存算一体 vs 存算分离没有绝对优劣，是「性能与灵活性」的工程权衡。云原生环境（K8s + 对象存储）越普及，存算分离的吸引力越大——计算容器弹性伸缩，存储成本下降到 ~$0.02/GB/月。但极致性能场景（金融实时风控、超大规模实时大屏）仍是存算一体的天下。

3. 性能基准

Figure 3. TPC-H 100GB 与 SSB 单表的性能对比

3.1 TPC-H 100GB（OLAP 多表 JOIN）

TPC-H 是 OLAP 经典 benchmark [5]，包含 22 个查询，覆盖多表 JOIN、子查询、聚合、Window 函数等。100GB 数据集是中型企业的代表规模。本文选 5 个代表性查询的测试结果（Figure 3(a)）：

Q1（单表 + 聚合）：ClickHouse 1.2s 最快（单表是其强项）；StarRocks 2.5s、Doris 3.2s、Trino 4.8s；
Q3（3 表 JOIN）：StarRocks 3.8s 最快（向量化 + Pipeline 优化）；Doris 5.1s、Trino 5.5s、ClickHouse 6.5s（多表 JOIN 短板）；
Q6（简单 Filter）：ClickHouse 0.6s（filter pushdown 最优）；StarRocks 1.0s；
Q9（6 表大 JOIN）：StarRocks 6.2s、Doris 8.5s、ClickHouse 9.8s、Trino 11.0s；
Q21（子查询）：StarRocks 8.7s、Doris 12.3s、Trino 15.6s、ClickHouse 18.5s。

总结：StarRocks 在多表场景几乎全胜；Doris 接近但落后 30-50%；Trino 居中；ClickHouse 在 Q1/Q6 等单表强，在多表 JOIN 弱。

3.2 SSB 单表（大宽表分析）

SSB（Star Schema Benchmark）[6] 是更接近「实时大屏」的场景——单宽表查询为主。Figure 3(b) 显示：ClickHouse 全部最快（0.3-1.0s），其他 3 款慢 3-5×。这与 ClickHouse 的设计目标完全一致——极致优化大宽表 + 物化视图 + MergeTree 引擎。

SSB 与 TPC-H 的差异说明：「benchmark 选择影响结论」。仅看 TPC-H StarRocks 似乎全面胜出；加上 SSB 后会发现「单表场景 ClickHouse 仍是王者」。这就是为什么大型企业实际部署 ClickHouse 与 StarRocks 并存——各用其长。

4. 八维特性对比矩阵

Figure 4. 八维特性对比矩阵

Figure 4 给出 4 款引擎在 8 个工程维度的对比：

MySQL 协议：4 款都支持——这已是行业基本要求；
SQL 兼容：Doris/StarRocks/Trino 完整支持 ANSI SQL；ClickHouse 自有 SQL 方言（部分非标准）；
JOIN 性能：StarRocks/Trino 完整；Doris 部分；ClickHouse 较弱（推荐 denormalize 成大宽表）；
单表性能：ClickHouse 最优；Doris/StarRocks/Trino 中等；
联邦查询：Trino 是唯一完整支持；StarRocks 通过 External Catalog 部分支持；Doris 弱；ClickHouse 几乎不支持；
实时摄入：Doris/StarRocks 完整（Stream Load + Routine Load）；Trino 部分；ClickHouse 通过 Kafka Engine；
MV 支持：Doris/StarRocks 完整（异步 MV）；ClickHouse 部分；Trino 几乎不支持；
运维复杂度：Doris 最简单（单一安装包）；其他三款中等。

重要发现：没有一款引擎在所有维度都是「完整」——每款都有明显短板。这就是「四国军棋」格局的根源——选型必须看「核心需求」。

5. 综合评分雷达图

Figure 6. 4 款引擎的 7 维综合评分（满分 10）

Figure 6 给出基于综合考量的雷达图评分（满分 10）：

性能：ClickHouse 10（单表极致）、StarRocks 9、Doris 7、Trino 7；
SQL 兼容：Doris/StarRocks 9、Trino 7、ClickHouse 5；
联邦查询：Trino 10（独占）、StarRocks 5、Doris 4、ClickHouse 2；
实时性能：ClickHouse 9、Doris/StarRocks 8、Trino 5；
运维简单：Doris 9（最易上手）、StarRocks 7、Trino 6、ClickHouse 6；
生态成熟：Trino/ClickHouse 8（全球用户多）、Doris/StarRocks 7（中国用户主导）；
成本效率：ClickHouse 9（单机最优）、Doris/StarRocks 8、Trino 6（计算单价高）。

每款引擎都有一个「核心强项」：Doris 是综合易用、StarRocks 是综合性能、Trino 是联邦查询、ClickHouse 是单表极致。

6. 选型决策树

Figure 5. OLAP 引擎选型决策树

Figure 5 给出推荐的选型决策树：

Q1：需要联邦查询多源数据？是 → Trino（独占优势）；
Q2：数据量 > 10TB 单表 + 大宽表场景？是 → ClickHouse（实时大屏、日志分析）；
Q3：团队 SQL 经验初级？是 → Doris（易用 + 业务报表友好）；高级 → StarRocks（性能优先 + DW 场景）。

6.1 团队 SQL 经验为何重要

Doris 与 StarRocks 在 SQL 兼容性上接近，但运维门槛差异大：

Doris 安装包 < 100MB，单命令启动；调优参数少（~50 个）；社区中文文档完善；
StarRocks 安装更复杂；调优参数多（~150 个）；性能极致但需要深入理解 Pipeline 引擎。

对中小团队（< 10 人 DBA），Doris 是更现实的选择；对大型数据平台团队（50+ 人），StarRocks 的性能优势能被充分发挥。

6.2 大型企业的三栈并存

实践中，大型企业（如字节、京东、美团）常用「Trino + Doris/StarRocks + ClickHouse」三栈并存：

Trino：跨数据湖查询、Ad-hoc 分析、临时探索；
Doris/StarRocks：核心数仓、业务报表、固化 BI；
ClickHouse：实时大屏、日志分析、APM 监控。

不要追求「一个引擎打天下」——按工作负载选型才是正道。引擎之间通过 Iceberg/Hudi 表格式实现数据共享，避免数据孤岛。

▎工程见解 选型的常见误区是「迷信 benchmark 数字」——某引擎在 TPC-H Q3 快 50%，不等于在你的业务上快 50%。真实业务的查询模式（Filter selectivity、JOIN 模式、数据分布）与 benchmark 差异巨大。强烈建议「自己的业务数据跑自己的核心 query」做选型，而非依赖第三方 benchmark。

7. 讨论与未来趋势

7.1 与 Lakehouse 的协同

2024-2026 年最大趋势是「OLAP 引擎 + Lakehouse」结合 [7]。Iceberg/Hudi/Delta（表格式）+ Parquet/ORC（文件格式）作为统一存储层，多个 OLAP 引擎共享同一份数据。Trino 在这一趋势中天然优势；Doris/StarRocks 也在快速跟进（External Catalog）。

7.2 与 AI / LLM 的集成

Doris/StarRocks 等都在快速集成 LLM 能力——Text-to-SQL、自然语言报表、智能调优。但目前的集成多是「LLM 调 OLAP API」的浅层模式，深度集成（如向量索引、嵌入计算）尚处早期。

7.3 国产化与生态

Doris、StarRocks 都源自中国（百度、StarRocks 公司创始团队来自百度），在国内有强生态优势。Trino/ClickHouse 是全球项目，国内社区规模较小。对国央企/政府场景，国产化要求使 Doris/StarRocks 是默认选择。

7.4 局限性

本文 benchmark 数据基于公开论文 + 我们的测试，但「benchmark 公正性」永远是争议话题——StarRocks 官方测试可能美化自身，Trino 官方测试可能凸显跨源优势。读者应当批判性看待任何 benchmark 数字，最终以自己业务测试为准。

8. 结论

本文系统横评了 4 款主流 OLAP 引擎。核心论点：

4 款引擎走 3 条技术路线——MPP（Doris/StarRocks）、联邦（Trino）、极致单表（ClickHouse），各有不可替代价值；
TPC-H 多表场景 StarRocks 最强；SSB 单表场景 ClickHouse 反超 3-5×——benchmark 选择影响结论；
8 维特性矩阵证明：没有一款引擎在所有维度都「完整」，每款都有明显短板；
选型决策树：先看「是否需要联邦」（→ Trino），再看「是否大宽表」（→ ClickHouse），最后按团队能力选 Doris 或 StarRocks；
大型企业实践常用「三栈并存」（Trino + Doris/StarRocks + ClickHouse），按工作负载分配；
不要迷信第三方 benchmark，自己业务数据跑自己核心 query 才是真正选型依据。

▎工程见解 更深的工程哲学：OLAP 引擎的「军阀混战」反映了一个根本事实——分析场景的多样性，不可能被单一引擎完美覆盖。这与「关系型数据库 MySQL/PostgreSQL/Oracle 三强分治」格局同构。健康的工程文化是「按场景选最优工具」而非「拥护某个明星产品」——这一开放心态，比任何技术选择更重要。