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 的革命”
  • 2.1 身份
  • 2.2 强项
  • 2.3 2024–2025 的势头
  • 2.4 限制
  • 2.5 使用场景
• 第3章 · ClickHouse — “实时 OLAP 之王”
  • 3.1 身份
  • 3.2 强项
  • 3.3 2024–2025 动向
  • 3.4 限制
  • 3.5 使用场景
• 第4章 · Snowflake、BigQuery — “托管巨头”
  • 4.1 Snowflake
  • 4.2 BigQuery
  • 4.3 强项
  • 4.4 限制
  • 4.5 2025 年的策略
• 第5章 · StarRocks、Doris — “MPP 实时 BI”
  • 5.1 共同点
  • 5.2 StarRocks
  • 5.3 Apache Doris
  • 5.4 强项
  • 5.5 使用场景
• 第6章 · Apache Pinot、Druid — “超低延迟 OLAP”
  • 6.1 Apache Pinot
  • 6.2 Apache Druid
  • 6.3 使用场景
  • 6.4 运维难度
  • 6.5 与 ClickHouse、StarRocks 的差异
• 第7章 · Trino、Presto — “联邦查询（Federated Query）”
  • 7.1 身份
  • 7.2 强项
  • 7.3 Starburst
  • 7.4 限制
  • 7.5 Presto vs Trino
• 第8章 · Databricks SQL、Redshift
  • 8.1 Databricks SQL
  • 8.2 Redshift
  • 8.3 使用场景
  • 8.4 2025 策略
• 第9章 · 基准测试的陷阱
  • 9.1 TPC-H、TPC-DS
  • 9.2 ClickBench
  • 9.3 StarSchema、JOB
  • 9.4 实战评估流程
  • 9.5 “性价比”才是真正的指标
• 第10章 · 引擎布局（Engine Placement）模式
  • 10.1 “一个引擎”反模式
  • 10.2 “2–4 个引擎”的现实模式
  • 10.3 数据共享
• 第11章 · 韩国企业选型指南
  • 11.1 现状
  • 11.2 韩国的特殊性
  • 11.3 实务推荐矩阵
• 第12章 · 性能调优的通用原则
  • 12.1 模式设计
  • 12.2 分区与排序
  • 12.3 索引与投影（Projection）
  • 12.4 缓存
  • 12.5 Materialized view
• 第13章 · 十大反模式
  • 13.1 “用一个引擎搞定一切”
  • 13.2 只看基准测试就做选择
  • 13.3 没有生产负载就批准 PoC
  • 13.4 无视星型模型
  • 13.5 分区过度
  • 13.6 缺乏对 Materialized view 的管理
  • 13.7 没有 on-call 准备就自托管
  • 13.8 无视锁定全面押注 SaaS
  • 13.9 不做查询调优只做扩容
  • 13.10 缺少用户配额与护栏
• 第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 主要引擎分类

---

第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 实战评估流程

1. 采样自有数据（10–100GB）
2. 挑出 5–15 条常用查询
3. 模拟 10–100 的并发
4. 计算性能与成本之比
5. 评估运维复杂度（基础设施、监控、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 实务推荐矩阵

---

第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 项

• 拆解工作负载（BI/实时/Ad-hoc/面向用户）
• 对 3–5 个候选引擎做自有基准测试
• 性价比矩阵
• 评估运维复杂度（托管 vs 自建）
• 安全、审计、RBAC 需求
• Lakehouse 兼容性（Iceberg/Delta/Hudi）
• BI 工具与 ETL 工具的兼容性
• 数据共享与目录策略
• 灾难恢复与备份
• 扩展性模拟（10–100 倍）
• 人力与培训计划
• 引擎布局图的最终版

---

第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 年的教训。