trino 的容错执行通过任务级细粒度恢复、阶段化执行模型和可重入数据源读取实现，失败时仅重做受影响task而非整条sql重试。
Trino 的 fault-tolerant execution（容错执行）不是靠传统意义上的“查询重试”实现的，而是通过**任务级细粒度恢复 + 阶段化执行模型 + 可重入的数据源读取**来达成高可用查询处理。它不简单地整条 SQL 重跑，而是在失败时只重做受影响的最小计算单元。
容错执行的核心：Stage 和 Task 分层恢复
Trino 将查询拆分为多个 Stage（如 Exchange、Join、Aggregation），每个 Stage 拆为多个并行 Task。当某个 Task 因节点宕机、OOM 或网络中断失败时：
- Coordinator 检测到 Task 失败后，不会中止整个查询，而是重新调度该 Task 到其他健康 Worker 上运行；
- 只要该 Task 的输入数据可重复读取（例如 Hive 表支持 split-level 重试、Iceberg 支持 snapshot-based 一致性读），就能从失败点继续；
- 上游 Stage 已完成的输出（缓存在内存或 spill 到本地磁盘）会被复用，避免重复计算；
- 下游依赖该 Task 的其他 Task 会等待重试完成，而非立即失败。
真正起作用的“重试”发生在数据读取层
Trino 本身不主动重试 SQL，但底层 Connector 决定了是否支持容错。关键能力包括：
- Hive Connector：支持 split 级别重试，单个 HDFS 文件读取失败可重试该 split，不影响其他 splits；
- Iceberg Connector：基于 snapshot ID 读取，即使并发写入发生，重试仍读取同一 snapshot，保证语义一致性；
- Delta Lake Connector（v415+）：利用 transaction log 实现可重放读取；
- 若使用不支持重入的自定义数据源（如某些 HTTP API connector），Task 失败即导致查询失败，无法自动恢复。
配置项控制容错行为边界
以下参数决定系统在多大程度上启用和限制恢复逻辑：
- task.max-partial-aggregation-memory：防止聚合内存溢出导致 Task 崩溃，间接提升稳定性；
- exchange.max-buffer-size：控制跨 Stage 数据交换缓冲区大小，避免因网络抖动引发连锁失败；
- query.max-execution-time：全局超时，防止无限重试；
- task.min-drivers-per-task：影响并行度与单点故障影响范围，值过小会放大 Task 失败概率。
用户侧需配合的设计习惯
要真正发挥容错能力，SQL 编写和环境配置也需适配：
- 避免在 WHERE 或 JOIN 条件中调用不可重入函数（如
NOW()、RANDOM()），否则重试结果可能不一致； - 优先使用 Iceberg / Hive ACID / Delta 等支持事务快照的表格式；
- 对长耗时查询，开启 spill-to-disk（
spiller-spill-path）防止内存不足直接失败； - 监控
task_failed_total和task_retried_total指标，识别频繁失败的 Task 类型（如 shuffle-heavy 或 scan-heavy），针对性优化。
