目录

摘要

一、简介

二、背景知识

2.1 大规模并行处理

2.2 SQL on Hadoop

三、Orca架构

四、查询优化

4.1 优化工作流

4.2 并行查询优化

五、Metadata Exchange

六、可行性

6.1 Minimal Repros

6.2 优化器准确性测试

七、实验

八、相关工作

8.1 查询优化基础

8.2 基于MPP数据库的SQL优化

8.3 SQL on Hadoop

九、总结

摘要

数据管理系统中分析查询处理的性能主要依赖于系统查询优化器的能力。增长的数据量和对处理复杂分析查的兴趣提高促使了Pivotal构建了新的查询优化器。

本文提出了一种新的查询优化器Orca架构，适用于所有的Pivotal数据管理产品，包括Pivotal Greenplum Database和Pivotal HAWQ。Orca是一个综合开发的产物，结合了最先进的查询优化技术和自己的原始研究，形成了一个模块化和可移植的优化架构。

除了描述整体架构外，我们还着重介绍了一些独特的特性，并与其他系统进行了性能比较。

一、简介

大数据带来了查询优化的新兴趣，因为一种新的数据管理系统在前所未有的伸缩性、可用性和处理能力方面推动了极限，它使数百tb甚至pb的大型数据集可以通过SQL或类似SQL的接口进行分析。优秀和平庸的优化器之间的差异一直被认为是实质性的。然而，这些系统必须处理的数据量的增加放大了优化错误，并比以往任何时候都强调了查询优化的重要性。

本文中，我们介绍了Orca，它是进来在Greenplum/Pivotal上的研究和开发成果。Orca是一种最先进的查询优化器，专门为高要求的分析工作负载设计。它与其他优化器在几个重要方面有所区别:

• 模块化：通过使用高度可扩展的元数据和系统描述抽象，Orca不再像传统优化器一样局限于特定的主机系统。相反，它可以通过元数据提供方SDK支持的插件快速地移植到其他数据管理系统中。

• 扩展性：通过将查询和其优化过程中的所有元素作为一等公民，Orca避免了多阶段优化的限定，即某些优化是事后才处理的。众所周知，多阶段优化器是很难扩展的，因为新的优化或是查询构造通常不匹配先前设置的阶段边界。

• 多核支持：Orca部署了一个高效的多核感知调度器，它将单个细粒度的优化子任务分布在多个核上，以加快优化过程。

• 可验证性：Orca有专门的条款来确定内置机制级别的正确性和性能。除了改进工程实践之外，这些工具还能够以高信心快速开发，并减少新特性和bug修复的周转时间

• 性能：Orca是对我们以前的系统的重大改进，在许多情况下提供了10倍到1000倍的查询速度。

本文的其余部分组织如下。我们在第2节中对计算架构进行初步介绍。在第3节中，我们将介绍Orca的架构并描述其组件。第4节介绍查询优化工作流。第5节描述Orca如何使用后端数据库系统更改元数据。在第6节中，我们描述了为维护可验证的查询优化器而构建的工具。第7节介绍了我们的实验研究，然后在第8节讨论了相关的工作。我们在第9节对本文进行了总结和最后的评论。

二、背景知识

本章中中我们会介绍大规模并行处理数据库和Hadoop查询引擎相关的背景知识。

2.1 大规模并行处理

Pivotal's Greenplum Database(GPDB)是一个大规模并行处理（Massively Parallel Processing）。GPDB采用无共享的计算架构，具有两个或多个协同处理器。每一个处理器有自己的内存、操作系统和磁盘。GPDB利用这种高性能的系统架构来分配pb级别数据仓库的负载，并并行使用系统资源来处理给定的查询。

下图Figure 1展示了GPDB的high level架构。对大数据的存储和处理是通过将负载分发给多个servers或是hosts去创建一组独立的database来处理的，所有的工作汇总在一起来呈现一个单独的database视图。Master是GPDB的入口，client会向它连接并提交SQL statements。Master会和其他database实例协调工作，我们称之为segments，来负责数据处理和存储。当一个query提交给master，它会被优化并拆分为小的组件分发到segments上来，共同交付最终结果。Networking层负责segments之间的内部处理通信交互。交互使用了标准的Gigabit Ethernet switching fabric。

在查询执行过程中，数据可以通过多种方式分布到segments中，包括hash分布（基于hash函数将元组分布到segments中）、复制分布（table的完整副本存储在每个segments中）和单分布（整个分布式的table从多个segments收集到单个host上，通常是master）。

2.2 SQL on Hadoop

在Hadoop中处理分析查询变得越来越流行。最初，查询会以MapReduce任务来表示，Hadoop的吸引力在于它的可扩展性和容错能力。在MapRduce中，编程、手动优化和维护复杂查询是很困难的，因此类SQL的声明语言，比如Hive，从Hadoop基础之上发展起来了。HiveQL查询会被编译为MapReduce任务并通过Hadoop执行。HiveQL加速了复杂查询的编码，但也说明了Hadoop生态系统中需要一个优化器，因为编译后的MapReduce任务表现出来的性能较差。

Pivotal通过引入HAWQ来应对这一挑战，它是一个大规模并行的SQL兼容引擎，运行在HDFS之上。HAWQ在其核心部分利用Orca来设计高效的查询，最大限度地降低在Hadoop集群中访问数据的cost。HAWQ的架构结合了创新的、最先进的基于成本的优化器和Hadoop的伸缩性和容错性，使得处理pb级别的数据交互成为可能。

最近，包括Cloudera的Impala[17]和Facebook的Presto[7]在内的其他一些努力都引入了新的优化器来支持Hadoop上的SQL处理。目前，这些努力只支持SQL标准特性的一个子集，而且它们的优化仅限于基于规则的。相比之下，HAWQ拥有成熟的标准兼容SQL接口和基于成本的优化器，这两者在Hadoop查询引擎中都是前所未有的特性。我们在第7节的实验研究中阐述了Orca在将HAWQ与其他Hadoop SQL引擎在功能和性能上区分开来方面所起的关键作用。

三、Orca架构

Orca是Pivotal数据管理产品（包括GPDB和HAWQ）中的新的查询优化器。Orca是一个基于Cascades优化器框架的现代top-down查询优化器。虽然许多Cascades优化器与它们的主机系统紧密耦合，但Orca的一个独特特性是它能够作为独立的优化器在数据库系统之外运行。这个特性对于用一个优化器支持其他计算架构（例如，MPP和Hadoop）的产品来说至关重要。它也允许在新的查询处理范例，例如Hadoop中，利用关系优化的丰富遗产。此外，将优化器作为一个独立的产品运行，可以在不经过数据库系统整体结构的情况下进行详细的测试。

DXL：将优化器从数据库系统解耦需要构建一种通信机制来处理查询。Orca中包含了一种用于在优化器和数据库系统之间交换信息的框架，我们称之为Data eXchange Language(DXL)。这个框架使用基于XML的语言来对必要信息进行编码以进行通信，例如，input queries、output plans和metadata。DXL之上是一个简单的通信协议，用于发送初始查询结构并检索优化后的执行计划。DXL的一个主要优点是将Orca打包为一个独立的产品。

下图展示了Orca和一个外部数据库系统的交互。Orca的input是一个DXL query。Orca的output是一个DXL plan。在优化过程中，数据库系统可以接受metadata的查询（例如，table的定义）。Orca允许数据库系统注册一个metadata provider（MD Provider）来抽象元数据访问细节，该provider负责在将Metadata发送给Orca之前将其序列化到DXL中。Metadata也可以从包含以DXL格式序列化的metadata对象的常规文件中获取。

数据库系统需要包含translator来以DXL格式consume/emit数据。Query2DXL translator将query parse tree转换为一个DXL query，而DXL2Plan translator将一个DXL plan转换为一个可执行的plan。这些translator的实现完全在Orca之外，这就允许了多个系统通过提供合适的translator来使用Orca。

Orca的架构是高度可扩展的；所有的组件都可以独立被替换并分别配置。下图展示了Orca中的不同组件。我们接下来会简要介绍各组件。

Memo：优化器生成的可选plan的空间被编码成为一个紧凑的内存数据结构，我们称之为Memo。Memo结构由一组被称为group的容器集合组成，其中每个group都包含逻辑等价的expressions。Memo group捕获query中不同的子目标（例如，table上的一个filter，或是两个table的join）。Group的成员，被称为group expressions，会用不同的逻辑方式（例如，不同的join orders）来达成这个group的目标。每一个group expression都是一个operator，其children为其他的groups。Memo的这种递归结构允许对一个可能plan的海量空间进行紧凑编码，我们将在4.1章中介绍。

Search and Job Scheduler：Orca使用一个搜索机制，在可能的plan选择空间中导航，并确定成本最低的方案。这个search机制是通过特定的Job Scheduler实现的，它会创建依赖的或是并行的工作单元，来在3个主要的步骤中实现查询优化：

• exploration：这一步中会生成等价的logical expressions

• implementation：生成physical plans

• optimization：required physical properties会被enforced并计算可选plan的cost。

我们将在4.2章中讨论optimization job是scheduling的细节。

Transformation：通过应用可以产生等价logical expressions的transformation rules来生成可选的plan（例如，InnerJoin(A,B) -> InnerJoin(B,A) ），或是基于已有expressions进行物理实现（eg. Join(A,B) -> HashJoin(A,B)）。transformation rules应用的结果会被拷贝到Memo中，这可能会导致创建新的groups或是在已有的groups中新增新的group expressions。每一个transformation rule都是一个独立的组件，可以在Orca的配置中显式地激活或是取消。

Property Enforcement：Orca包含一个可扩展的框架，用于根据形式化的属性（Property）规范描述查询需求和计划特征。Properties有不同的类型，包含logical properties（例如，output columns），physical properties（例如，sort order、data distribution），和scalar properties（例如，join条件中用到的columns）。在查询优化过程，每一个operator可能会要求它的children具有特定的properties。一个优化后的child plan可能本身就能满足required properteis，或是需要在plan中添加一个enforcer（例如，一个Sort operator）才能交付required property。框架允许每个operator基于其child plan的properties和operator的本地行为来控制enforcer的放置。我们将在4.1中描述这个框架的细节。

Metadata Cache：由于metadata（例如，table的定义）不会频繁的变更，将它和每个查询一起发送过来会带来额外的开销。Orca将metadata缓存到优化器侧并置在cache中无法获取到某些信息时才会从catalog中检索这些片段，或是自从上次加载到cache依赖发生了变更。Metadata cache还从优化器中抽象出了数据库系统的细节，这在测试和调试期间特别有用。

GPOS：为了与可能使用不同API的操作系统进行交互，Orca使用了OS抽象层，称之为GPOS。GPOS层为Orca提供了一个广泛的基础设施，包括内存管理器、并发控制原语控制、异常处理、文件I/O和同步数据结构

四、查询优化

我们在4.1中介绍了Orca的优化工作流。然后在4.1中展示了如何并行执行优化过程。

4.1 优化工作流

我们使用下面的运行案例来展示查询优化工作流：

SELECT T1.a FROM T1, T2 
WHERE T1.a = T2.b 
ORDER BY T1.a;

其中T1的分布是Hashed(T1.a)，T2的分布是Hashed(T2.b)。

下表Listing 1展示了前面这个查询用DXL的表现形式，我们给出了要求的output columns、sorting columns、data distribution和logical query。Metadata（例如，tables和operator的定义）用metadata ids（Mdid's）来装饰，以便于在优化过程中进一步请求信息。Mdid是一个由数据库系统标识、对象标识符和版本号组成的唯一标识。例如，“0.96.1.0”指向了GPDB的integer equality opeartor，版本为1.0。Metadata的version用于使缓存但有可能在查询过程中被修改的metadata对象失效。我们将在第5章更详细地讨论metadata exchange。

DXL query message会被发送到Orca，在这里它会被解析并转换为一个内存中的logical expression tree，然后被复制到Memo中。Figure 4展示了Memo的初始内容。logical expression为两个table和InnerJoin operation创建了3个groups。为了简洁，我们省略了join condition。Group0被称为root group因为它对应于logical expression的root节点。logical expression中的operators之间的依赖关系被捕获为groups之间的引用。例如，InnerJoin[1,2]引用了Group1和Group2作为children。优化过程按照下面的步骤执行：

(1) Exploration：能够生成逻辑等价expressions的transformation rules被触发。例如，一个Join Commutativity rule 被触发以基于InnerJoin[1,2]生成InnerJoin[2,1]。Exploration会导致在已有的groups中添加新的group expressions，并且有可能会创建新的groups。Memo结构有一个内置的重复检测机制，基于expression拓扑，去检测和消除被不同transformations创建的重复expressions。

(2) Statistics Derivation：在exploration的最后，Memo会维护给定查询的完全logical space。然后Orca的statistics derivation mechanism（统计推导机制）会被触发来计算Memo groups的统计信息。Orca的一个统计对象主要是列直方图的集合，用于推导和估计基数cardinality和数据倾斜。统计信息的推导会在紧凑的Memo结构上执行，以避免扩大搜索空间。

为了从目标group中推导统计信息。Orca选择了最有希望（highest promise）提供可靠统计数据的group expression。Statistics promise 计算是基于指定表达式的。例如，一个有很少的join condition的InnerJoin expression比其他有更多join condition的InnerJoin expressions的promise更高。其基本原理是，连接条件的数量越多，估计误差被传播和放大的几率就越高。由于需要在给定表达式的所有节点上聚合置信度分数，计算基数估计的置信度分数（a confidence score for cardinality estimation）是一项艰巨的任务。我们目前正在探索几种方法来计算紧凑Memo结构中的置信度分数。

在目标group中选择了最有希望的group expression后，Orca会递归地触发所选group expression的child group上的统计信息推导。最后，结合child group的统计对象构造目标group的统计对象。

Figure 5展示了运行中的统计信息推导的例子。首先，一个top-down的传递会被执行，即parent group expression会请求它的child groups的统计信息。例如，InnerJoin(T1, T2) on (a=b)会请求T1.a和T2.b的直方图。请求的直方图根据需求从注册的MD Provider的catalog中加载，解析为DXL并存储在MD Cache中以服务将来的请求。下一步，一个bottom-up的传递会被执行，以将child统计对象整合到parent统计对象中。这将在T1.a和T2.b上生成（可能经过修改）的直方图，因为join condition可能会影响列的直方图。

构建出来的统计对象被附加再独立的groups上，在优化期间它们可能会被增量更新（例如，添加新的直方图）。这对于保持统计推导的成本可控至关重要。

(3) Implementation：能够为logical expressions创建physical expressions的transformation rules被触发。例如，Get2Scan rule会给logical的Get生成physical的table Scan。类似地，InnerJoin2HashJoin和InnerJoin2NLJoin rules会生成Hash或是Nested Loop implementations。

(4) Optimization：在这一步中，properties会被enforced，并计算可选plan的成本。优化过程通过提交一个初始化的优化请求到Memo的root group开始，指定查询requirement，例如result distribution或是sort order。向group g提交一个请求r，对应于向g中的root physical operator 请求一个满足r的最小cost的plan。

对于每一个收到的request，每一个physical group expression根据接收到请求的requirement和operator的local requirement将对应的请求传递给child groups。在优化过程中，许多相同的request可能会被提交到相同的group。Orca会将计算完成的请求缓存到一个group hash table中。接收到请求只要在不存在于这个group hash table中时才会进行计算。另外，每一个physical group expression会维护一个local hash table，存储接收到request到对应的child requests的映射。Local hash table会提供从Memo中提取physical plan时使用的链接结构，我们将在本节稍后介绍。

Figure 6展示了Memo中运行的优化请求示例。初始的优化request是 req. #1: {Singleton, <T1.a>}，它指定了query result需要按照T1.a有序聚集在master上。我们同样展示了group hash table，其中每个request都与满足要求的最少估计成本的最佳group expression（GExpr）相关联。黑色的各自标明了enforcer operators，它们是被插入到Memo中的，用于传递order和data distribution。Gather operator将元组从所有的segments收集到master上。GatherMerge operator将有序的数据从所有的segments收集到master。Redistribute operator基于给定参数的hash value将元组在segments中分发。

Figure 7展示了对于req. #1对于InnerHashJoin[1,2]的优化。对于这个request，可选方案之一是基于join condition对child distribution进行对齐，这样就要求需要被join的元组是co-located的。这是通过对于group1要求Hashed(T1.a)和对于group2要求Hashed(T2.b)达成的。这两个group都被要求交付Any sort order。在找到最佳child plan后，InnerHashJoin会将child properties结合起来决定交付的distribution和sort order。注意group2的best plan需要对T2按照T2.b进行hash-distribute，由于T2原始数据是按照T2.a进行hash-distributed的，而group1的best plan是简单的scan，因为T1已经在T1.a进行了hash-distributed。

当确定交付的properties不满足初始的requirements时，没有被满足的properties需要被enforced。Orca中的Property enforcement是一个灵活的框架，允许每一个operator来基于child plans交付的properties和operator的本地行为enforcing required properteis定义所需的行为。例如，一个保持顺序的NL Join operator可能不需要在join的顶部强制sort order，前提是它的outer child已经交付了该order。（即property可能具有传递性）。

Enforcers被添加到包含正在被优化的expression的group中。上图Figure 7展示两个通过property enforcement满足req. #1的两个可能的plans。左边的plan在segments上对结果进行排序，然后在master上通过gather-merge对结果排序。右边的plan将join的结果从segments gather到master上，然后再对它们进行排序。这些不同的可选方案会被编码到Memo中，它们的成本区别取决于cost model。

最后，best plan会基于优化请求提供的链接结构从Memo中提取出来。Figure 6展示了plan提取的运行示例。我们展示了相关group expressions的local hash tables。每一个local hash table将接受到的优化request映射到了对应的child optimization requests。

我们首先在root group中查找req. #1的best group expression，它指向了GatherMerge operator。Hash table中GatherMerge对应的child request是req. #3。req. #3的best group expression是Sort。因此我们将GatherMerge链接到Sort。Local hash table中Sort对应child request是req. #4。req. #4的best group expression是InnerHashJoin[1.2]。因此我们将Sort链接到InnerHashJoin。遵循相同的过程来完成方案提取，得到图6所示的最终方案。

提取出来的plan会被以DXL格式序列化，并传输到database system来执行。Database system中的DXL2Plan translator会基于底层执行框架将DXL plan转换为一个可执行的plan。

Multi-Stage Optimization：我们在Orca的持续工作包括实现多阶段优化Multi-Stage Optimization。Orca中的一个optimization stage使用一个transformation rules的子集和（可选的）timeout和cost阈值定义为一个完全的优化工作流。当下面的任一条件满足时，一个stage就会停止：

1. 一个低于cost阈值的plan被找到。（对应于Columbia中的Eplison剪枝）

2. 超时

3. transformation rules子集执行完毕

用户可以通过Orca的配置来指定一个特定的欧化stage。这种技术允许资源受限的优化，例如，将最昂贵的transformation rule配置为在稍后的阶段执行，以避免增加优化时间。这种技术也可以尽早地获得查询计划，以减少复杂查询的search space。

Query Execution：一个final plan的副本会被分发到每一个segment上。在分布式的query execution中，每个segment上的distribution enforcer会同时作为数据的接收者和发送者运行。例如，一个Redistribute(T2.b)实例运行在Sgement S上，它基于T2.b的hash value将S上的元组分发到其他segment上，同时接受其他segment的Redistribute(T2.b)实例发送来的元组。

4.2 并行查询优化

查询优化可能是数据库系统中CPU最敏感的过程。高效的CPU使用可以转换为更好的查询计划，从而获得更好的系统性能。并行查询优化器对于从利用越来越多core的高级CPU设计中获益至关重要。

Orca是一个多核的优化器。优化程序会拆分为小的工作单元，我们称之为optimization jobs。Orca当前有以下几种类型的optimization jobs：

• Exp(g)：生成group g中所有group expressions的逻辑等价expressions。

• Exp(gexpr)：对一个group expression gexpr生成逻辑等价的expressions。

• Imp(g)：生成group g中所有group expressions的implementations。

• Imp(gexpr)：对一个group expression gexpr生成implementation选项。

• Opt(g, req)：针对group g中以某个operator为root，返回满足优化request req，且估算成本最小的plan。

• Opt(gexpr, req)：镇对group g中以gexpr为root，返回满足优化request req，且估算成本最小的plan。

• Xform(gexpr, t)：使用rule t对group expression gexpr进行transform。

对于一个给定的查询，每个类型的job都可能会产生上千个jobs。这就带来了处理job依赖关系的挑战。例如，一个group expression要等到其child groups被优化后才能优化。Figure 8展示了一个部分的job graph，其中在优化请求req9下对于group g0的优化会触发一个依赖jobs的深度树。依赖被以child-parent链接进行编码；一个parent不能在它的child jobs结束之前结束。当一个child jobs正在处理时，parent job需要阻塞。这允许了child jobs利用可用的线程来并行执行，前提是它们不再依赖于其他的jobs。当所有的child jobs都完成时，阻塞的parent job会被通知来恢复执行。

Orca包含一个从零开始设计的专门job scheduler，以最大化作业依赖图的fan-out，并提供并行查询优化所需的基础设施。Scheduler提供API来将优化job定义为可冲入的过程，由可用的处理线程拾取。它同时也会维护job的依赖图，以识别并行的机会（例如，在不同的groups中执行transformation），并在依赖的jobs终止时通知被阻塞的job。

在并行查询优化过程中，多个修改Memo group的并发请求可能会被不同的优化request触发。为了最小化具有相同目标的job之间的同步开销（例如，exploring相同的group），jobs不应该知道彼此的存在。当一个具有某些目标的优化job在处理时，所有具有相同目标的jobs将被迫等待，知道接收到正在运行job结束的通知。此时，阻塞的jobs可以获取已完成jobs的结果。这个功能是通过将每个group关联到一个job queue来实现的，这样，只要存在相同目标的active jobs，传入的jobs就会排队。

五、Metadata Exchange

Orca被设计在数据库系统之外工作。优化器和数据库系统之间的一个主要交互点是元数据交换metadata exchange。例如，欧化器需要知道一个给定的table是否有index定义，以便设计高效的query plan。Metadata的访问由一组元数据提供者(metadata provider)提供，它们是系统特定的插件，用于从数据库系统检索元数据。

Figure 9 展示了Orca是如何与不同的后端系统交换metadata的。在查询优化过程中，所有被Orca访问的metadata对象会被固定在一个内存cache中，在优化完成或是异常抛出时解除固定。所有对于metadata对象的访问都是通过MD Accessor完成的，它会跟踪在一个优化session中访问到的对象，并保证不再需要它们时进行释放。MD Accessor还负责在请求的元数据对象不在cache中时透明地从外部MD Provider获取metadata。服务于不同优化session的不同MD Accessor可能有不同的外部MD Provider来获取metadata。

除了系统特定的providers之外，Orca还实现了一个基于file的MD Provider来从DXL file中加载metadata，消除了访问活动后端系统的需要。Orca包含了一个自动化工具，用于将优化器需要的metadata收集到一个最小的DXL file中。我们在6.1中展示了如何在后端数据库系统脱机时replay客户端查询优化。（debug工具）

六、可行性

6.1 Minimal Repros

AMPERe[3]是一个自动捕获最小可移植和可执行再现的工具。建立AMPERe的动机是能够在优化器中再现和调试客户问题，而不需要访问客户生产系统。

略

6.2 优化器准确性测试

Orca cost model的准确性可能会受到一些误差来源的影响，包括基数cardinality估计不准确和不适当的成本模型参数。因此，cost model为plan执行的wall clock time提供了不完善的预测。量化优化器的准确性对于避免bug修复和新添加特性带来的性能回归至关重要。

Orca包含一个名为TAQO[15]的内置工具，用于测试查询优化器的准确性。TAQO衡量优化器成本模型正确对任意两个给定计划排序的能力，也就是说，估计成本较高的计划实际上会运行更长时间。例如，在图11中，优化器或- ders (p1,p3)是正确的，因为它们的实际成本与计算的成本估计直接成比例。另一方面，优化器不正确地排序(p1,p2)，因为它们的实际成本与计算的成本估计成反比。

略

七、实验

略

八、相关工作

在过去的几十年里，查询优化一直是许多突破性创新的沃土。在本节中，我们将讨论一些基本的查询优化技术，以及MPP数据库和基于hadoop的系统领域的最新建议。

8.1 查询优化基础

Volcano Paralle Database介绍了实现数据库并行的基本原理。该框架引入了exchange opeartors，支持两种并行方式，即通过流水线实现的operator间并行，以及通过跨运行在不同进程上的操作符划分元组实现的operator内并行。该设计允许每个operator在本地数据上独立执行，并与运行在其他进程中的operator的其他副本并行工作。一些MPP数据库[6,8,18,20,23]利用这些原则来构建商业成功的产品。

Cascades[13]是一个可扩展的优化器框架，其原理已被用于构建MS-SQL Server、SCOPE[6]、PDW[23]和本文中介绍的优化器Orca。该框架的流行是由于其逻辑和物理规划空间的清晰分离。这主要是通过将操作符和转换规则封装到自包含组件中来实现的。这种模块化设计使Cascades能够在逻辑上对等价表达式进行分组，以消除冗余工作，与Volcano的穷举方法相比，允许按需触发规则，并允许基于规则对给定算子的有用性对规则的应用进行排序。

在级联原理的基础上，[30] （F. M. Waas and J. M. Hellerstein. Parallelizing Extensible Query Optimizers. In SIGMOD Conference, pages 871–878,2009.）中提出了一个并行优化框架，可以为多核架构构建类级联优化器。Orca中的并行查询优化框架(参见第4.2节)是基于[30]中引入的原则。

8.2 基于MPP数据库的SQL优化

略

8.3 SQL on Hadoop

略

九、总结

通过开发Orca，我们的目标是开发一个查询优化平台，它不仅代表了最先进的技术，而且具有足够的功能和可扩展性，以支持新优化技术和高级查询特性的快速开发。

在本文中，我们描述了完全从零开始构建这样一个系统所需的工程工作。将大量的技术保障措施整合到Orca系统中是一笔巨大的投资，然而，通过快速的开发速度和由此产生的高质量软件，Orca系统已经获得了显著的回报。Orca的模块化使得它可以轻松适应不同的数据管理系统，通过使用干净统一的抽象来编码系统的功能和元数据。