OLAP 引擎 2025 对比指南：DuckDB、ClickHouse、Snowflake、StarRocks、Pinot、Druid、Trino，基准测试的陷阱，引擎布局（2025）

Season 5 Ep 3 — 如果说 Ep 1 是存储、Ep 2 是流动，那么 Ep 3 就是查询。“一个引擎包办一切”的时代已经结束，引擎布局（Engine placement）成为新的设计领域。

Prologue — “引擎是工具，问题在工作负载”
第1章 · OLAP 引擎分类
- 1.1 四个维度
- 1.2 主要引擎分类
第2章 · DuckDB — “单节点 OLAP 的革命”
第3章 · ClickHouse — “实时 OLAP 之王”
第4章 · Snowflake、BigQuery — “托管巨头”
第5章 · StarRocks、Doris — “MPP 实时 BI”
第6章 · Apache Pinot、Druid — “超低延迟 OLAP”
第7章 · Trino、Presto — “联邦查询（Federated Query）”
第8章 · Databricks SQL、Redshift
第9章 · 基准测试的陷阱
第10章 · 引擎布局（Engine Placement）模式
第11章 · 韩国企业选型指南
第12章 · 性能调优的通用原则
第13章 · 十大反模式
第14章 · 检查清单 — 引入 OLAP 引擎前的 12 项
第15章 · 下一篇预告 — Season 5 Ep 4：“dbt、SQLMesh、Dagster、Airflow、Prefect”

Prologue — “引擎是工具，问题在工作负载”

2015–2020 年的 OLAP 争论是“哪个引擎最快”。2025 年不一样了：

基准测试是营销工具（TPC-H、TPC-DS 的解读是有条件的）
每个引擎都在特定工作负载上拥有压倒性优势
一家公司同时使用 2–4 个引擎是常态
“因地制宜的布局”同时决定了成本、性能和团队能力

本文梳理 2025 年主要 OLAP 引擎的现实优缺点与布局策略。

第1章 · OLAP 引擎分类

1.1 四个维度

部署：单节点 / 分布式 MPP / 无服务器
工作负载：BI（复杂 JOIN）/ Real-time（低延迟）/ Ad-hoc（探索）
托管 vs 自建：SaaS / 开源加自运维
数据位置：内置存储 / Lakehouse 对接

1.2 主要引擎分类

引擎	部署	主要工作负载	模式
DuckDB	单节点	Ad-hoc, Embedded	开源
ClickHouse	分布式	Real-time, Log	开源 + Cloud
Snowflake	无服务器	BI, ELT	SaaS
BigQuery	无服务器	BI, ELT	SaaS
Databricks SQL	分布式	BI + ML	托管
Redshift	分布式	BI	托管
StarRocks	分布式	Real-time BI	开源 + SaaS
Apache Doris	分布式	Real-time BI	开源
Apache Pinot	分布式	超低延迟	开源
Apache Druid	分布式	时序、流	开源
Trino/Presto	分布式	联邦查询	开源

第2章 · DuckDB — “单节点 OLAP 的革命”

2.1 身份

2019 年始于 CWI
Embedded OLAP：正如 SQLite 把 OLTP 带到笔记本上，DuckDB 把 OLAP 带到笔记本上
直接查询 Parquet/CSV/JSON，并有读取 Iceberg、Delta 的扩展

2.2 强项

5 秒安装，单一二进制
Python/R/Node/Go/Rust 绑定
在 8–16GB 内存上即可分析数十亿行（列式 + 向量化）
用“原生 SQL”查询 Parquet

2.3 2024–2025 的势头

MotherDuck：DuckDB 的云端扩展
Iceberg、Delta 读取支持正式化
用 DuckDB WASM 实现浏览器内 OLAP
dbt-duckdb 成为本地开发与 CI 的标准

2.4 限制

单节点（仅限垂直扩展）
并发只在应用内的量级
并非大规模服务器集群的替代品

2.5 使用场景

分析师的本地开发
在 CI 中做数据校验
中小型项目的 OLAP 后端
Notebook/Python 脚本的 SQL 引擎

第3章 · ClickHouse — “实时 OLAP 之王”

3.1 身份

2009 年 Yandex 内部 → 2016 年开源 → 2021 年成立 ClickHouse Inc.
分布式列式，基于 MergeTree 引擎
实时插入数十亿行 + 秒级查询

3.2 强项

压倒性的插入与查询性能（在特定工作负载上）
事实上已成为实时仪表盘的标准
通过 Kafka/Kinesis Engine 直接作为 consumer
成本效率高（自运维时）

3.3 2024–2025 动向

ClickHouse Cloud（SaaS）快速增长
Iceberg 读取范围扩大
Materialized view、Dictionary 更加成熟
许多可观测性平台（Datadog 的一部分、Axiom、Tinybird、PostHog）基于 ClickHouse

3.4 限制

JOIN 优化相比部分引擎偏弱（近期已大幅改善）
运维复杂（自建时）
SQL 兼容性存在部分差异

3.5 使用场景

日志、事件分析
实时仪表盘
Ads/Marketing analytics
APM/Observability 后端

第4章 · Snowflake、BigQuery — “托管巨头”

4.1 Snowflake

无服务器，计算与存储分离
Multi-cluster warehouse（自动扩缩）
Native Iceberg table（2024）
Cortex AI（整合 LLM、ML 功能）
数据共享（Data Sharing）

4.2 BigQuery

Google Cloud 的无服务器方案
基于 Slot 的计算，ad-hoc 很快
Iceberg External + BigLake
Gemini 集成（用自然语言写查询 SQL）
BI Engine（内存加速）

4.3 强项

运维负担为零
初始搭建只需几天
内置安全、审计、备份
在大企业与 enterprise 市场占有压倒性份额

4.4 限制

成本：规模变大后每月数万到数十万美元
锁定（正被 Iceberg 支持所缓解）
不适合部分工作负载（超低延迟）

4.5 2025 年的策略

用 Iceberg External Table 查询 Lake 中的外部数据
Hot/Cold 分离：Hot 用原生，Cold 用 Iceberg
与 dbt、Airflow、Dagster 的集成成为标准

第5章 · StarRocks、Doris — “MPP 实时 BI”

5.1 共同点

同时支持实时 + BI + Lakehouse
读取 Iceberg/Hudi/Delta
兼容 MySQL 协议（对 BI 友好）
起源于中国，正在向全球扩展

5.2 StarRocks

从 Apache DorisDB 分叉 → 独立发展
CelerData 提供商业支持
2024–2025 快速增长
Cost-based optimizer 已趋成熟

5.3 Apache Doris

Apache 基金会项目
起源于百度
Routine Load（直连 Kafka）
在实时仪表盘上很强

5.4 强项

实时与复杂 JOIN 两者都强
Lakehouse + 自有存储的双轨运行
相比 ClickHouse 在 JOIN 上占优

5.5 使用场景

实时运营 BI
作为 Lakehouse 引擎的补充
在中国、韩国、日本的采用持续增加

第6章 · Apache Pinot、Druid — “超低延迟 OLAP”

6.1 Apache Pinot

起源于 LinkedIn → Apache
目标是低于 100ms 的查询延迟
支持 Upsert（2023 年起）
提供 StarTree（SaaS）

6.2 Apache Druid

起源于 Metamarkets → 由 Imply 商业化
专注时序与流
Kafka indexing service

6.3 使用场景

LinkedIn、Uber、Netflix 等的超低延迟分析
面向用户的仪表盘（Customer-facing）
实时推荐与异常检测

6.4 运维难度

搭建复杂，需要运维工程师
SaaS（StarTree/Imply）可减轻负担

6.5 与 ClickHouse、StarRocks 的差异

Pinot/Druid：专注低于 100ms 的超低延迟
ClickHouse：覆盖广泛工作负载 + 出色的性价比
StarRocks：BI 的复杂 JOIN + 对 Lakehouse 友好

第7章 · Trino、Presto — “联邦查询（Federated Query）”

7.1 身份

Facebook Presto → Trino（2020 年分叉，由原开发者们主导）
Iceberg/Delta/Hudi、Hive、MySQL、Postgres、Kafka 等数十种连接器
用一条 SQL 打通多个数据源

7.2 强项

多源 JOIN
Iceberg 读写性能名列前茅
可以自托管
在企业内部承担“中央查询引擎”的角色

7.3 Starburst

Trino 的商业发行版，提供企业级功能与支持
整合 Gateway、缓存、安全

7.4 限制

相比仪表盘用途，更擅长 ad-hoc 与 ELT
运维复杂（管理 Coordinator 与 Worker）
以读取为中心，而非实时采集

7.5 Presto vs Trino

Presto：由 Meta/PrestoDB 维护
Trino：事实上的社区标准
2025 年的新项目普遍选择 Trino

第8章 · Databricks SQL、Redshift

8.1 Databricks SQL

基于 Delta + Spark 的 SQL warehouse
Photon 引擎（向量化）
2024 年支持 Iceberg UniForm
强项在于 ML + BI 的整合

8.2 Redshift

AWS 的传统 DW
通过 RA3 + AQUA 分离计算与存储
通过 Spectrum 访问 S3 Iceberg
与 AWS 生态深度集成

8.3 使用场景

Databricks SQL：已经在用 Databricks 的团队
Redshift：以 AWS 为中心的企业，连接 SAP、Salesforce

8.4 2025 策略

Databricks：Iceberg 兼容 + Mosaic AI
Redshift：强化无服务器与 AI 集成
两者都在朝缓解锁定的方向走

第9章 · 基准测试的陷阱

9.1 TPC-H、TPC-DS

虽是业界标准，却与真实工作负载不同
引擎厂商用自己调优过的结果做宣传
查询计划、数据规模、并发设置会极大左右结果

9.2 ClickBench

由 ClickHouse 团队主导（存在公正性争议）
但它是一个可以比较多种引擎的开放基准

9.3 StarSchema、JOB

复杂 JOIN 基准，更接近真实
有助于暴露引擎之间的差距

9.4 实战评估流程

采样自有数据（10–100GB）
挑出 5–15 条常用查询
模拟 10–100 的并发
计算性能与成本之比
评估运维复杂度（基础设施、监控、on-call）

9.5 “性价比”才是真正的指标

比起单纯的毫秒数，更该看 $/查询 或 $/TB 扫描
并发用户数与等待时间 SLA 也要计入

第10章 · 引擎布局（Engine Placement）模式

10.1 “一个引擎”反模式

只用 Snowflake 做所有事 → 超低延迟失败，成本暴涨
只用 ClickHouse 做所有事 → BI 复杂 JOIN 与管理负担
只用 Trino 做所有事 → 无法实时

10.2 “2–4 个引擎”的现实模式

模式 A：Startup（小规模）

DuckDB：开发与 CI
Snowflake/BigQuery：生产 BI

模式 B：SaaS（以实时仪表盘为中心）

ClickHouse：生产分析与面向客户
DuckDB：本地分析
Snowflake：内部 BI + ELT

模式 C：Enterprise（大企业）

Snowflake/Databricks：全公司 BI
Trino：Lakehouse 联邦查询
ClickHouse/Pinot：特定的高性能应用
DuckDB：分析师开发

模式 D：高性能面向用户

Pinot/Druid：毫秒级 UX
ClickHouse：管理员仪表盘
BigQuery/Snowflake：经营与战略 BI

10.3 数据共享

原始数据集中在 Iceberg
各引擎读取 Iceberg，必要时复制到自有存储
元数据目录保持统一（Polaris/Unity/Glue）

第11章 · 韩国企业选型指南

11.1 现状

金融与公共部门：Teradata/Oracle + Hadoop → 正在迁往 Snowflake/Databricks
电商与游戏：ClickHouse 与 BigQuery、Snowflake 混用
初创公司：DuckDB + Snowflake/BigQuery 急剧增加

11.2 韩国的特殊性

网络隔离要求：更偏好本地部署的引擎（ClickHouse、StarRocks、Trino）
韩语 SQL 工具的兼容性（Metabase、Redash、Superset 等的韩语界面）
大容量日志与游戏分析：ClickHouse 在性价比上占优
金融 BI：Snowflake、Databricks 的采用急剧增加

11.3 实务推荐矩阵

场景	首选	辅助
全公司 BI（大企业）	Snowflake/BigQuery	DuckDB、Trino
实时日志与 APM	ClickHouse	Druid/Pinot
面向用户的仪表盘	Pinot/StarTree	ClickHouse
ML + BI 整合	Databricks SQL	Snowflake
Lakehouse 联邦	Trino	DuckDB
初创公司的第一个 DW	BigQuery/Snowflake	DuckDB
本地部署与金融	StarRocks/Doris	ClickHouse

第12章 · 性能调优的通用原则

12.1 模式设计

Star schema（Fact + Dim）依然强大
按引擎与工作负载调整 Denormalization 的程度
优化列类型（Int32 vs Int64 等）

12.2 分区与排序

时间分区是基础
Sort key 基于 WHERE、JOIN 的模式来定
ClickHouse：Primary key = Sort key

12.3 索引与投影（Projection）

ClickHouse：Skip index, Projection
StarRocks：Bitmap index, MV
Snowflake：Search Optimization Service
Iceberg：Puffin 统计

12.4 缓存

Result cache（查询结果）
Metadata cache
Query plan cache
CDN/edge cache（仪表盘）

12.5 Materialized view

把常用聚合预先计算好
增量更新是关键
ClickHouse、Snowflake、Materialize 在这方面很强

第13章 · 十大反模式

13.1 “用一个引擎搞定一切”

注定失败。按工作负载拆分。

13.2 只看基准测试就做选择

必须用自有数据与查询重新评估。

13.3 没有生产负载就批准 PoC

并发与 SLA 测试不足。

13.4 无视星型模型

Denormalization 过度 → 维护变成噩梦。

13.5 分区过度

数万个小文件 → 规划地狱。

13.6 缺乏对 Materialized view 的管理

它们逐渐过时，只剩成本在堆积。

13.7 没有 on-call 准备就自托管

ClickHouse、Trino、Druid 的 on-call 负担很大。

13.8 无视锁定全面押注 SaaS

数据主权 + 成本风险。

13.9 不做查询调优只做扩容

成本增加而问题没有根本解决。

13.10 缺少用户配额与护栏

会导致“一个人搞垮整体可用性”。

第14章 · 检查清单 — 引入 OLAP 引擎前的 12 项

第15章 · 下一篇预告 — Season 5 Ep 4：“dbt、SQLMesh、Dagster、Airflow、Prefect”

如果说引擎查询数据，那么编排器治理流水线。Ep 4 讲的是数据转换与编排的工具生态。

dbt 的标准化与局限
SQLMesh 的登场：是 dbt 的替代还是补充
Dagster：以数据资产（asset-centric）为中心的编排
Airflow 2.x、3.0 的演进
Prefect 3.0 的重生
与 Temporal 的边界
数据契约（Data Contracts）与模式演进
CI/CD for data pipelines
可观测性 + 告警
韩国企业的技术栈选择
“一个工具全包”与“工具链”之间的平衡

“数据流水线的 CI/CD”才是 2025 年数据工程真正的前线。

下一篇文章再见。

总结：2025 年的 OLAP 已经摆脱“用一个引擎搞定一切”的幻想，进入按工作负载布局引擎的时代。DuckDB 承担单节点与开发、CI，ClickHouse 承担实时分析，Snowflake、BigQuery、Databricks SQL 承担托管 BI，StarRocks、Doris 承担实时 BI + Lakehouse，Pinot、Druid 承担超低延迟的面向用户场景，Trino 承担联邦查询。基准测试只是起点，评估自有工作负载才是必需，而 2–4 个引擎的布局是现实中的主导模式。韩国企业要结合网络隔离、韩语 BI 工具、游戏与金融的特殊性来设计自己的引擎组合。“引擎布局是数据平台设计的核心”正是 2025 年的教训。