【分布式 OLAP 查询引擎】引擎选型与数据平台阅读地图

本系列前 17 篇从 SQL 与逻辑计划 追到 Iceberg planner 下推，从 Coordinator/Worker 追到 故障排查。读者最后需要一个 不带营销排名 的收束：我的场景该用哪类引擎、全栈还缺哪几块知识。

本文是系列 第 18 篇（末篇）：

1. 选型决策树：交互式联邦、批 ETL、嵌入式分析、流批一体四条路径。
2. 能力对照表：下推深度、并发模型、湖格式成熟度、运维复杂度——不给假 benchmark。
3. 数据平台全栈阅读地图：postgresql-kernel → columnar-engine → lakehouse → stream-processing → 本系列 的依赖与闭合点。

环境说明：对照表依据各项目 2026 年官方文档（A 级）与系列前文机制；Trino/Spark 吞吐对比不在此篇出现（本机无 JVM 集群实测）。开放问题（Substrait、Velox）标注 B 级前瞻，不冒充结论。

一、数据平台栈：五段闭合

flowchart LR
  PG["postgresql-kernel<br/>行存 OLTP"]
  COL["columnar-engine<br/>列存 OLAP"]
  LAKE["lakehouse<br/>表格式 + 文件"]
  STREAM["stream-processing<br/>实时计算"]
  QE["query-engine<br/>本系列"]
  PG --> COL
  COL --> LAKE
  LAKE --> STREAM
  LAKE --> QE
  STREAM -.->|入湖| LAKE

闭合点：lakehouse 公式 Lakehouse = 列式文件 + 对象存储 + 表格式 + catalog + 查询引擎 中，前五项由 lakehouse/stream 系列覆盖 文件与表；查询引擎 由本系列覆盖 planning 与 MPP。读完 18 篇，读者应能解释：lakehouse/18 的四层漏斗 在 Trino 哪一步被发起（第 15 篇），以及 join shuffle 与 spill 如何与裁剪无关地拖慢查询（第 11、16、17 篇）。

二、选型决策树（不排名）

flowchart TD
  START["分析需求"] --> Q1{"需要多用户远程 SQL 服务?"}
  Q1 -->|否| Q2{"数据与并发能否单机?"}
  Q2 -->|是| DDB["DuckDB / 嵌入式 DataFusion"]
  Q2 -->|否| Q3{"以批 ETL + 湖维护为主?"}
  Q1 -->|是| Q3
  Q3 -->|是| SPARK["Spark SQL + Iceberg/Delta 维护"]
  Q3 -->|否| Q4{"亚秒交互 + 多源联邦?"}
  Q4 -->|是| TRINO["Trino / Presto 系"]
  Q4 -->|否| Q5{"自有列存集群 + 高 QPS?"}
  Q5 -->|是| CH["ClickHouse"]
  Q5 -->|否| TRINO
  START --> Q6{"无界流 + 状态?"}
  Q6 -->|是| FLINK["Flink / RisingWave 等<br/>见 stream-processing"]

2.1 路径说明

组合常见：Spark/Flink 写湖 + Trino 交互查湖 + DuckDB CI/本地校验；ClickHouse Serving 层 + 湖作冷数据。

三、能力对照表（口径：自托管读路径，2026 文档）

下推深度：四层漏斗定义见 lakehouse/18；planner 发起见 第 15 篇。同一 Iceberg 表 上 Trino/Spark/DuckDB 共享 manifest stats；差异在 dynamic filter、分布式 split、写入 procedure。

禁止用法：用「Trino 比 Spark 快 N 倍」营销页支撑选型；应用 第 17 篇 的 planning/runtime 分解做 POC。

四、按读者目标的阅读路径

本系列 18 篇内部依赖见 系列 index 第二节 flowchart。

五、开放问题（B 级前瞻）

以下社区方向 尚未形成单一标准答案，选型 POC 时单独评估：

不在此下「某技术将统一一切」的结论。

六、本系列核心结论收束

1. 查询引擎 = SQL 前端 + 优化 + 执行 + MPP + Connector 下推（第 1 篇）。
2. 读湖快不快 一半在 布局与 stats（lakehouse），一半在 join/shuffle/内存（本系列 4–11、16–17）。
3. 嵌入式与分布式 分界在并发与 shuffle，不在「能否读 Parquet」（第 14 篇）。
4. lakehouse/18 讲漏斗；第 15 篇讲 planner 发起——两篇合读才完整。
5. 生产稳定性 靠 resource group、统计维护、compaction 与 catalog 健康（第 16–17 篇、lakehouse/17–20）。

七、小结

数据平台栈从 行存事务 到 列存扫描、开放表格式、流式入湖，最后到 交互式 SQL 规划与 MPP——本系列补全最后一块。选型按 远程 SQL、批维护、单机嵌入、流状态 分叉，不按虚构 benchmark 排名。继续深入可阅 数据库索引、db-frontier HTAP 与 distributed 理论。

上一篇：经典故障与排查

返回 系列目录 · Lakehouse · 流式处理

参考资料

1. Trino / Spark / DuckDB / ClickHouse / PostgreSQL 官方文档（2026 年 stable 线，A 级）。
2. 本系列 PLAN.md 与 index（系列结构）。
3. lakehouse/18、stream-processing/18（栈闭合）。
4. Substrait / Velox 社区文档与博客（B 级前瞻）。