17370845950

火山模型是SQL执行器中最经典的拉取式算子模型，以迭代器接口（open/next/close）实现可组合、可中断的延迟计算，支持LIMIT短路、算子复用与可控内存，至今仍是PostgreSQL等主流系统的执行基础。

SQL数据库执行器中的“算子模型”是查询执行的核心抽象，而“火山模型（Volcano Model）”正是最经典、影响最深远的一种实现范式。它不直接执行查询，而是通过“拉取式（pull-based）”的数据流机制，让上层算子主动向下游算子请求下一条元组（tuple），从而形成可组合、可复用、支持中断与迭代的执行结构。

火山模型的核心思想：迭代器模式 + 拉取驱动

火山模型将每个执行算子（如Scan、Filter、HashJoin、Sort等）建模为一个统一接口的迭代器（Iterator），对外只暴露三个方法：

• open()：初始化资源（如打开文件、构建哈希表）
• next()：返回下一个元组；若无更多数据，返回 null 或特殊标记
• close()：释放资源（如关闭扫描器、清空临时内存）

执行时，根算子（通常是Project或Result）反复调用其子算子的next()，子算子再递归调用更下层的next()——就像熔岩从火山口逐层向下涌出，故称“火山”。这种设计天然支持延迟计算、短路执行（如LIMIT 10只需取10次next）、以及运行时动态剪枝。

与管道/推送模型的关键区别

对比“推送式（push-based）”模型（如某些流处理引擎中Operator接收输入后主动触发下游处理），火山模型的拉取特性带来几个实际优势：

• 控制流由上而下，执行节奏由消费者决定，便于实现LIMIT、TOP-N、嵌套循环连接中的早期终止
• 算子间解耦清晰，同一Filter算子可插在Scan后，也可插在Join后，复用性高
• 内存压力更可控——上游不会盲目生产数据，下游按需索取，避免缓冲区溢出
• 调试友好：可单步调用next()观察每条元组的流转路径

典型算子的火山式实现要点

真实系统中，不同算子需适配火山契约，但行为逻辑差异显著：

• TableScan：open()定位到起始页/行，next()顺序读取下一行，到达末尾返回null
• Filter：next()循环调用子算子next()，直到获得满足WHERE条件的元组；可能多次调用子next()才返回一个有效结果
• NestedLoopJoin：外层每次next()触发内层重置（rewind），内层next()逐条匹配；常配合Block Nested Loop优化批量读取
• HashJoin（Build side）：open()阶段完成哈希表构建；next()仅代理给Probe侧，自身不产生元组

注意：纯火山模型对复杂算子（如Sort、Aggregate）易造*量物化，现代系统常混合使用物化点（Materialization Points）或引入流水线并行来缓解。

为什么至今仍是主流执行模型的基础

尽管存在内存效率、并行扩展等方面的局限，火山模型胜在简单、正交、可预测：

• 语义清晰：每个算子职责单一，符合关系代数直觉
• 易于优化：CBO可独立估算各算子的cardinality和cost，代价模型成熟
• 广泛兼容：PostgreSQL、Greenplum、早期SQL Server、Calcite、Doris（部分模式）均基于此构建执行器
• 便于扩展：新增算子只需实现Iterator接口，无缝接入现有树形执行计划

当前趋势是在火山骨架上叠加新能力——比如向量化执行（一次处理一批而非一行）、GPU加速、或融合轻量推送（如Exchange算子内部用消息队列），但核心拉取契约仍被保留。