【分布式 OLAP 查询引擎】内存、Spill 与资源隔离

第 9 篇 在算子层讲过 hash join 的 build 表与 partial/final aggregation；第 11 篇 讲过 Exchange 缓冲 Page。生产里更常遇到的是：查询还没算完，Coordinator 报 Exceeded memory limit、个别 Worker spill 到盘却更慢、多租户抢内存导致全员排队——这些属于 集群级内存治理，不是单算子代码能单独解释的。

本文是系列 第 16 篇，建立 Trino 主线上的 内存账户 → spill → resource group 心智模型，并和 stream-processing 第 18 篇背压 对照：流式背压 限的是管道 buffer 与 checkpoint；交互式 OLAP 限的是 查询峰值内存与 revocable 回收。

环境说明：本机 未部署 Trino 集群，正文机制来自 Trino 476+ 官方文档 Memory management、Spill、Resource groups（A 级）。不粘贴未实测的 spill 字节数或 EXPLAIN ANALYZE 内存字段。DuckDB 单进程内存行为见 第 14 篇 边界一句。

一、为什么 OLAP 内存是「账户制」

OLTP（postgresql-kernel）单查询内存通常由 work_mem 等参数封顶，超出可能 sort/hash 落盘或直接失败。分布式 OLAP 额外有：

• 多 Stage 并行：每个 Worker 上多个 Driver 同时跑 hash build、agg 状态、Exchange 缓冲。
• 跨节点不可见堆：Coordinator 需要 汇总各节点 memory context 才能 kill 或 spill。
• revocable 内存：join/agg 的 hash 表在压力时可 部分写入 spill 文件，与「已承诺给网络/shuffle 的 non-revocable」区分（Trino docs, Memory management）。

Trino 用 分层 memory pool + query context 跟踪：GENERAL 池、RESERVED、以及 per-query 的 user memory / revocable memory 计数（文档术语，具体类名见源码 ClusterMemoryManager）。

flowchart TB
  CLUSTER["Cluster memory limit"] --> POOL["General pool"]
  POOL --> Q1["Query A context"]
  POOL --> Q2["Query B context"]
  Q1 --> OP["Operators<br/>hash / agg / exchange"]
  OP -->|pressure| SPILL["Local spill files"]
  POOL -->|exceeded| KILL["Query failure / OOM"]

二、Query / User / Cluster 限额

Trino 配置层常见限额（config.properties / session，文档 Properties）：

user memory 近似「算子已分配且短期不会还给池子」的部分；revocable 是 可被 spill 回收 的部分（hash table、部分 agg 状态）。Exchange 缓冲、某些 pipeline 缓冲属于 non-revocable 或单独记账——这就是为什么「query 看起来没跑 join 仍 OOM」：可能是 shuffle 缓冲 + broadcast 表 占满。

与 第 5 篇 联动：broadcast join 把小表复制到每个 Worker，user memory 按 Worker 数放大；估错行数时 broadcast 误判是生产 OOM 主因之一。

三、Spill：哪些算子、什么路径

Trino 文档 Spill（A 级）说明下列算子可在内存压力下 写本地磁盘（格式为引擎内部二进制，非 Parquet）：

流程概要：

1. Memory pool 达到 revocable 回收阈值。
2. Operator 收到 spill 信号，将 部分 hash partition 序列化到 spill 目录（spiller-spill-path 等配置）。
3. 继续处理剩余内存内 partition；probe 阶段 读回 spill 完成 join。

代价：磁盘 IO 与多次 probe 使 wall time 陡增；EXPLAIN ANALYZE 中可见 Spilled 相关指标（文档 Explain analyze；本机未实测数值）。Spill 不保证 一定避免失败——若 spill 速度跟不上分配速度，或 disk 满，仍 Exceeded memory limit。

第 9 篇 实验设计：调低 query.max-memory 构造大 join，观察 plan 是否出现 spill——需在 Docker Trino 栈执行（reproduce/docker-compose.yml），本篇不伪造输出。

四、Resource Group：并发与隔离

Resource group（Trino docs, Resource groups，A 级）在 Coordinator 做 多租户队列：

典型划分：交互式 BI（低并发、短查询、紧 memory limit） vs ETL 批查询（高并发、长查询、独立组）。与 Spark Fair Scheduler pool 类似，但 Trino 在 Coordinator 单点 决策，Worker 只执行已批准 query。

Hard concurrency limit = 0 可维护模式拒绝新查询；soft limit 过高会导致 内存求和仍超 cluster，触发全局 kill。

五、与流式背压的对照

stream-processing/18 的 Flink credit-based 背压 解决 有界 buffer 下生产者别压垮消费者：下游慢 → credit 不释放 → 上游停读。

OLAP 通常无全局 backpressure 协议：慢查询占满 Worker 线程与内存，靠 resource group + kill policy 隔离，而不是逐 Page 反压上游 scan（scan 仍可能全速读直到 memory 触顶）。这是 第 1 篇 交互式 vs 流式 边界在生产资源层的体现。

六、Spark 与 DuckDB 边界（对照一句）

• Spark SQL：Executor memory + disk spill（shuffle、agg）；AQE 在 OOM 前可 coalesce partition（第 13 篇）。配置 spark.memory.fraction、spark.sql.shuffle.partitions 与 Trino 的 query.max-memory 不同口径，不直接换算。
• DuckDB：单进程 temp directory spill（文档 Memory Management），无 resource group；并发靠应用层串行化。

七、运维检查清单

1. Kill 前看 query.max-memory vs 实际 broadcast 表大小 × worker 数。
2. Spill 目录 磁盘空间与本地 SSD；HDD spill 易成 straggler（第 17 篇）。
3. Resource group 是否把重 ETL 与 BI 混在同一 general pool。
4. Revocable 比例：大 join + 大 agg 同 query 时 spill 顺序与重复读盘。
5. Node OOM：区分 JVM heap OOM（调 heap、headroom）与 query limit（调 plan 或 SQL）。

八、小结

• Trino 内存是 cluster / query / operator 分层账户；revocable 可 spill，non-revocable（部分 exchange/broadcast）更易顶满。
• Spill 覆盖 hash join、hash agg、order by 等；是 降级路径 不是免费午餐。
• Resource group 管并发与组级预算，是 multi-tenant 交互式 OLAP 的隔离主手段。
• 流式 背压 与 OLAP 内存 kill/spill 解决不同层问题；读湖裁剪减 IO，不能替代内存治理（第 15 篇）。

上一篇：Iceberg 下推全链路

下一篇：经典故障与排查

返回 系列目录

参考资料

1. Trino Documentation 476+, Memory management / Spill / Resource groups / Properties（A 级）。
2. Trino Documentation, Explain analyze（A 级；字段说明，无本机数值）。
3. stream-processing/18 背压（B 级对照）。
4. DuckDB Documentation, Memory Management（A 级；嵌入式边界）。