OLAP 引擎对比与选型
问题
ClickHouse、Doris、StarRocks、Druid 等 OLAP 引擎如何选择？
答案
主流引擎总览
| 引擎 | 架构 | 核心优势 | 核心劣势 |
|---|---|---|---|
| ClickHouse | Shared Nothing | 极致单表聚合性能 | JOIN 弱、运维复杂 |
| Apache Doris | MPP（FE+BE） | 简单运维、MySQL 兼容 | 生态较 CH 小 |
| StarRocks | MPP（FE+BE） | 功能丰富、查询优化器强 | 商业版本差异 |
| Apache Druid | Lambda | 实时摄入、亚秒级时序查询 | SQL 能力弱 |
| Presto/Trino | MPP 查询引擎 | 跨源联邦查询 | 无自有存储 |
| Spark SQL | 批处理引擎 | 大规模 ETL + 分析 | 延迟高 |
决策流程
详细对比
| 维度 | ClickHouse | Doris | StarRocks | Druid |
|---|---|---|---|---|
| 单表性能 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| JOIN 性能 | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐ |
| 实时写入 | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| SQL 兼容 | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐ |
| 运维难度 | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐ |
| 更新能力 | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐ |
| 生态成熟 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ |
| 中国社区 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐ |
典型场景推荐
| 场景 | 推荐引擎 | 理由 |
|---|---|---|
| 大宽表聚合分析 | ClickHouse | 单表性能最强 |
| BI 看板 + MySQL 工具链 | Doris | MySQL 协议兼容 |
| 多表 JOIN 分析 | StarRocks | MPP + 优化器强 |
| 实时事件统计 | Druid | 亚秒级实时摄入 |
| 跨数据源查询 | Trino | 联邦查询引擎 |
| 数仓 ETL 后的分析 | Spark + Parquet | 批处理生态成熟 |
| 数据量较小（< 1TB） | PostgreSQL | 避免过度架构 |
混合架构
生产中常见的组合
- Flink + Doris：实时数仓（Flink 做 ETL，Doris 做查询）
- Spark + ClickHouse：离线数仓（Spark 做 ETL，ClickHouse 做分析）
- Trino + 数据湖：湖仓一体（Trino 查询 Iceberg/Hudi）
- Doris + Elasticsearch：OLAP + 全文搜索
常见面试问题
Q1: 如何评估和验证选型？
答案：
- 明确需求：查询模式（聚合/JOIN/点查）、数据量、延迟要求、并发量
- PoC 测试：用真实数据和查询跑 Benchmark
- 评估运维：团队能否驾驭（ClickHouse 运维成本高于 Doris）
- 评估生态：与现有 BI 工具、ETL 工具的集成
- 评估成本：硬件、人力、商业授权
Q2: ClickHouse 和 Doris 有什么本质区别？
答案：
| 维度 | ClickHouse | Doris |
|---|---|---|
| 架构 | 单机极致 + 分布式扩展 | 原生 MPP 分布式 |
| JOIN | 基于子查询 | Shuffle / Broadcast JOIN |
| 更新 | 异步 Merge | 主键模型实时更新 |
| 运维 | ZooKeeper 依赖 | 无外部依赖 |
| 优化器 | 规则优化为主 | CBO 代价优化 |
Q3: 什么时候不需要专门的 OLAP 引擎？
答案：
- 数据量 < 100GB：PostgreSQL 配合索引和物化视图足够
- 团队小、数据量不大：DuckDB（嵌入式 OLAP）
- 已有数仓 + BI：直接在现有数仓上查询
相关链接
- ClickHouse - ClickHouse 详解
- Doris/StarRocks - Doris/StarRocks 详解
- 列式存储原理 - 底层存储原理
- Presto/Trino - 联邦查询引擎
- 大数据引擎对比 - 更广泛的引擎对比