Presto、Trino 为什么查询快？和 Spark SQL 怎么选？
湖仓与 OLAP第 33 / 34 题
自测：先别看答案
试着用 1～2 分钟把这道题讲出来（说出声或写下要点），再展开对照。
面试怎么回答
Trino 是常驻的 MPP 引擎，查询拆成多个 Stage 后在内存里流水线执行，Shuffle 默认不落盘，也没有为每个查询拉起资源的开销，所以即席查询快；还能通过 Connector 跨多种数据源联查。代价是中间结果主要依赖内存，超大 JOIN 容易失败，传统模式下任务失败就整体重跑，不适合长时间批处理。我会让 Spark 负责大规模 ETL 和长批任务，Trino 负责交互式分析和 BI 即席查询。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
即席查询场景经常被问：同样查 Hive 表，为什么 Trino 几秒出结果，Spark SQL 要几十秒？那为什么不全用 Trino？
为什么快
- MPP + 流水线执行：Trino 是常驻的 Coordinator + Worker 集群，查询被拆成多个 Stage，Stage 之间的数据在内存里流水线传递，上游算子一边产出、下游一边处理，不需要等整个 Stage 结束。
- 不落盘的 Shuffle：默认的数据交换走内存和网络，不像 Spark 那样把 Shuffle 数据写到磁盘。
- 常驻进程、无启动开销：不需要为每个查询申请资源、拉起 Executor，小查询的固定开销很低。
- Connector 架构：同一个 SQL 可以查 Hive、Iceberg、MySQL、Kafka 等多种数据源，还能跨源 JOIN。
代价是什么
快的来源同时也是限制：
- 中间结果主要放在内存里，大表 JOIN 或大聚合容易因为内存不足失败（可以开启 Spill，但会变慢）。
- 传统模式下一个任务失败整个查询就失败，不适合跑数小时的批处理。Trino 后来提供了容错执行模式（task 级重试，需要配置外部 Exchange 存储），但会牺牲一部分性能。
怎么选
- Trino / Presto：交互式分析、BI 报表即席查询、数据探查、跨数据源联查；查询通常在秒级到分钟级。
- Spark SQL：大规模 ETL、长时间运行的批处理、需要复杂 UDF 或和机器学习流程结合的场景；容错强，能处理超过内存的数据量。
很多公司的做法是：Spark 负责离线加工，产出明细和汇总表；Trino 负责对这些结果做即席查询。