【分布式 OLAP 查询引擎】OLAP 查询引擎全景：从单进程到 MPP

读者在 lakehouse 第 18 章 已经看到：Trino 读 Iceberg 表时，partition predicate 可以在 manifest 层裁掉大量文件。那条链路回答的是 引擎如何把读表范围缩小到必要的 Parquet 文件。但同一套湖仓 SQL 里还有另一组问题：一条带多表 join 的 SELECT 在 Coordinator 上怎么变成 Stage、Worker 之间为什么要 shuffle、CBO 估错行数后 join 顺序怎么把集群打满——lakehouse/18 讲下推漏斗，不讲引擎内部的 IR、优化与 MPP 执行。

本文是本系列 第 1 篇，不教 Trino 安装，而是建立三个贯穿全系列 18 篇的心智模型：

• 分布式 OLAP 查询引擎 = SQL 前端 + 逻辑/物理优化 + 执行模型 + MPP 调度 + Connector 下推。
• 嵌入式与分布式 的分界不在「能不能读 Parquet」，而在 数据量、并发、跨源联邦、shuffle 网络代价 是否迫使引入 Coordinator/Worker。
• 批式扫描与交互式查询 共享列存与向量化直觉（columnar-engine 系列），但延迟目标、资源隔离与失败重试语义不同（stream-processing 第 1 篇 的流批边界）。

后文默认读者具备 SQL 与基本分布式概念，但不假设读过 Calcite 源码或调过 Trino resource group。

环境说明：本机为 WSL2（Linux 6.6.87.2）、i9-12900K / 32 GiB，未部署 Docker Compose Trino/Spark 栈（无 JVM 查询集群）。架构与机制结论来自 Trino 476+、Spark 3.5+、DuckDB 1.5.x 官方文档；Trino/Spark 的 EXPLAIN 片段不在此篇粘贴未实测输出。DuckDB 本机实验见 第 2 篇 与 reproduce/run_duckdb_experiments.py。

一、OLTP、OLAP 与 HTAP：优化目标不同

postgresql-kernel 的 B-Tree + MVCC 优化 单行与短范围；OLAP 引擎优化 少次 I/O 读大量列、在内存/network 预算内完成 join/agg。把 PG 的「索引选错」直觉（PG 第 10 篇）迁移到 Trino 时，对应问题往往是 统计过期导致 broadcast 误判 或 Iceberg 分区谓词未下推（第 15 篇）。

1.1 延迟口径：交互式 OLAP 指什么

Trino 文档把产品定位在 interactive analytics：秒级到分钟级 ad-hoc SQL，而非 MapReduce 小时级批 job。口径上区分：

本系列 以交互式分布式 OLAP（Trino 主线） 为锚；Spark SQL 作批/湖仓与 AQE 对照（第 13 篇）；流式窗口与 state 不重复（stream-processing 第 1 篇）。

二、嵌入式 vs 分布式：何时需要 MPP shuffle

flowchart TB
  subgraph embed ["Embedded OLAP"]
    APP["App / Notebook"]
    DDB["DuckDB / DataFusion"]
    FILES["Local Parquet / Iceberg files"]
    APP --> DDB --> FILES
  end
  subgraph mpp ["Distributed MPP"]
    CLI["JDBC / CLI"]
    COORD["Coordinator<br/>plan + schedule"]
    W1["Worker"]
    W2["Worker"]
    S3["Object storage / Hive metastore"]
    CLI --> COORD
    COORD --> W1
    COORD --> W2
    W1 --> S3
    W2 --> S3
  end

DuckDB 可在单进程内做 向量化 + 多线程 pipeline（columnar-engine DuckDB 篇）；一旦 fact 表分布在对象存储、join 维表需跨节点 repartition，就必须引入 Exchange（第 11 篇）。选型不在此篇做排名，第 18 篇 给决策树。

三、一条 SELECT 的分层：IR 地图预览

Trino 查询路径（来源：Trino Documentation，Overview / SQL）可粗分为：

flowchart LR
  SQL["SQL text"] --> PARSE["Parser → AST"]
  PARSE --> ANALYZE["Analyzer<br/>types, names"]
  ANALYZE --> LOG["Logical plan"]
  LOG --> OPT["Optimizer<br/>rules + CBO"]
  OPT --> PHYS["Physical plan<br/>operators"]
  PHYS --> DIST["Distributed plan<br/>stages, exchange"]
  DIST --> TASK["Tasks on Workers"]

lakehouse/18 的 layout constraint（分区/文件/row-group）在 Trino 中由 Iceberg connector + planner 在 logical/physical 边界注入（第 15 篇）；本系列从 谁发起 constraint 补全 lakehouse 未展开的内核层。

四、执行模型三角：Volcano、向量化、morsel-driven

三种执行语义在本系列 第 6–7 篇 展开；此处只定坐标：

columnar-engine 第 4 篇 从 ClickHouse Block/IProcessor 拆解 batch 执行；本系列 第 7 篇 对照 Trino Page 与 DuckDB pipeline。列存文件格式（lakehouse/02 Parquet）与 执行 batch 是衔接关系：读路径产出向量，算子链在向量上算。

五、数据平台栈闭合图

flowchart TB
  PG["postgresql-kernel<br/>行存 OLTP"]
  COL["columnar-engine<br/>MergeTree / 向量化"]
  LAKE["lakehouse<br/>Iceberg + Parquet"]
  STREAM["stream-processing<br/>Flink 入湖"]
  QE["query-engine<br/>本系列"]
  PG --> COL
  COL --> LAKE
  LAKE --> STREAM
  LAKE --> QE
  STREAM -.->|CDC / 入湖| LAKE

Lakehouse 公式 Lakehouse = 列式文件 + 对象存储 + 表格式 + catalog + 查询引擎 中，前五项已有系统文章；查询引擎 独立成系列，避免把 Trino 当成「扫 Iceberg 的黑盒」。

六、引擎对照：Trino 主线与 Spark / DuckDB

Presto/Trino 分叉：2019 年 Presto 商标与 governance 分裂，Trino 为 trinodb/trino 延续（B 级历史事实，一句带过）。本系列代码与行为以 Trino 为准。

七、全系列 18 篇地图

flowchart TB
  subgraph base ["基础 1–3"]
    A1["01 全景"]
    A2["02 逻辑计划"]
    A3["03 Calcite/规则"]
  end
  subgraph cbo ["CBO 4–5"]
    B4["04 统计代价"]
    B5["05 Join 规划"]
  end
  subgraph exec ["执行 6–9"]
    C6["06 Volcano"]
    C7["07 向量化"]
    C8["08 Scan"]
    C9["09 HashJoin/Agg"]
  end
  subgraph mpp ["MPP 10–12"]
    D10["10 Coordinator"]
    D11["11 Shuffle"]
    D12["12 Trino 全路径"]
  end
  subgraph eng ["引擎 13–15"]
    E13["13 Spark"]
    E14["14 DuckDB"]
    E15["15 Iceberg 下推"]
  end
  subgraph prod ["生产 16–18"]
    F16["16 内存 Spill"]
    F17["17 故障排查"]
    F18["18 选型地图"]
  end
  A1 --> A2 --> A3 --> B4 --> B5
  A1 --> C6 --> C7 --> C8 --> C9
  A1 --> D10 --> D11
  B5 --> D12
  C8 --> D12
  D10 --> D12
  D12 --> E13 --> E14 --> E15
  C9 --> F16
  D11 --> F16
  D12 --> F16 --> F17 --> F18

7.1 阅读路径

八、与 stream-processing 的边界

stream-processing 系列 解决 无界 log + 有状态计算 + EOS 入湖；本系列解决 有界表上的 declarative SQL + CBO + MPP。交叉点：

Flink SQL 与 Trino SQL 语法相似但运行时完全不同；勿用流作业 mental model 直接推断 Trino 的 stage 并行度。

九、本系列边界

承诺展开：IR 层级、CBO 与统计、三种执行模型、Trino MPP、EXPLAIN ANALYZE 判读、Iceberg planner 下推（对读 lakehouse/18）。

十、本地实验入口

DuckDB（本机可跑）：post/db/query-engine/reproduce/run_duckdb_experiments.py 生成 10 万行 orders、5000 行 customer，输出 EXPLAIN 与 3 次 EXPLAIN ANALYZE 中位数（见 第 2 篇）。

Trino + Iceberg（需 Docker）：reproduce/docker-compose.yml 扩展 lakehouse reproduce；未在本写作环境启动时不粘贴 Trino plan 片段。

十一、小结

OLAP 查询引擎的核心不是「把 PG 放大到集群」，而是 在列存/湖文件上，用 CBO 选 join 与 scan 路径，用 MPP shuffle 扩展单机算力，用 connector 把谓词推到 layout 层。嵌入式 DuckDB 与分布式 Trino 共享 逻辑计划与向量化 直觉，差在 Exchange 与资源隔离。

下一篇进入 Parser、Analyzer 与 LogicalPlan：同一条 SQL 在 DuckDB EXPLAIN 与 Trino logical plan 文档结构上的对照。

参考资料

1. Trino Documentation, Overview / SQL（架构与 SQL 执行路径）。
2. Apache Spark Documentation, Spark SQL Guide（3.5+）。
3. DuckDB Documentation, Architecture / SQL（1.5.x）。
4. lakehouse 第 18 章（读湖下推漏斗）。
5. stream-processing 第 1 篇（流批边界）。
6. columnar-engine 第 4 篇（向量化执行）。
7. 本系列 index（18 篇依赖与阅读路径）。

返回 系列目录 ｜ 下一篇：SQL 解析、分析与逻辑计划