前面写了一些关于优化器的文章，现在开个小差，写一些执行器的paper介绍，从这篇开始。

这篇是Graefe的Volcano Project的执行器框架，其概念已被广泛接受和使用，也就是我们最为熟悉的Volcano iterator的执行框架，关于volcano/cascades的优化器介绍

内容

paper中提出了使用iterator + 标准接口(open/next/close)的思路来执行查询计划。（IBM Starburst当时已经使用了这种方式）

这是一篇1990年的paper了，概念也为大家所熟知，而且其中的内容细节已比较过时，因此不再详细描述，只大概总结下其思想核心和几个有趣的点：

• 解耦 + 抽象 + 标准接口，从而将各个operator独立起来考虑，提供data stream的抽象，各个operator可以灵活组合和协作，增加新算子/算法，对原有完全不需要修改，很容易扩展（似乎灵活性+扩展性是整个volcano project的核心目标）
  
• 整个框架实现了operator的组合和数据的整体处理流程，每个operator实现的就是数据的处理流程，但这些都是机制(mechanism)，与具体的执行策略(policy)无关，两者是隔离的，因此具有很强的灵活性
  

比如算法配置/算法实现，都可以support function的形式接入到operator中作为policy，从而同一个operator可以实现各种不同的算法。

也可以将对数据的解析/处理，封装在support function中，从而实现与data type/data model的正交，整个框架是可以应用到任何data model的

• 给出了2个meta-operator，它们不处理数据，只是做一些控制性的任务
  

1. choose plan operator
   

可以帮助实现dynamic query plan，其输入可以是bind variables的值，后续接入各种不同的plan，实际在真正执行时，根据value的不同，动态启用不同的plan，是一种AQE的方式。

2. exchange operator

可以帮助实现parallel query，将数据处理与并行化进行了隔离。

算子间并行，仍然是通过标准接口，实现算子间的pipelining，并可以以support function的方式，提供流控等功能。

算子内并行，通过exchange算子实现repartition等机制。

子树间并行，更大粒度。

单个进程/线程内的数据流是demand-driven的（和常规iterator一致），而进程/线程间的数据流是data-driven的。

总结

iterator这种机制虽然简单却很强大，非常灵活而具有扩展性，比如单个operator的执行逻辑完全不需要考虑其上下游是什么，也不需要考虑自身是否是并行在执行，这些逻辑都被放到了外部，而自身的策略也是注入式的，可以由外层灵活修改，整个iterator tree只负责整体处理流程。

考虑到当时的硬件环境（CPU没有pipelining并行能力 + 小内存 + 慢速IO），这是一种非常先进灵活的框架。但我们都知道它对于现代硬件已不再那么适用，海量的数据+tuple-at-a-time的执行方式，使得大量的虚函数调用破坏了cpu的流水线并导致data cache + TLB cache失效。由于内存的容量扩大，负载在逐渐从IO bound像memory bound发展，因此更需要对于cache level/instruction level的极致优化。人们提出了向量化/编译执行的这些方法，无非都是以此为目标，但从现有的一些state of the art执行器方案中，仍然处处可以看到volcano执行器的影子，其影响力是毋庸置疑的。