（论文阅读-优化器）Orca: A Modular Query Optimizer Architecture for Big Data

目录

摘要

一、简介

二、背景知识

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作为一个整合开发的产品，在融合最先进查询优化技术和原创研究的基础上构建了一个模块化且具有移植性的优化架构。

除了概述总体架构之外

一、简介

大数据推动了查询优化成为新的研究焦点。一种新型的数据管理系统在伸缩性、可用性和处理能力等方面达到了前所未有的水平，并使 terabytes甚至 petabytes规模的数据集可以通过 SQL 或类似 SQL 的接口进行分析。两者的性能差距被认为具有重要意义。然而，在数据量持续增长的情况下出现的‘优化错误’问题的影响程度比以往任何时候都更为突出。

本文中, 我们系统地介绍了Orca, 它是基于Greenplum/Pivotal平台的研究与开发成果之一。Orca作为最先进的一类查询优化器, 是专为满足高需求的数据分析任务而设计的。它与现有优化器相比, 在多个关键方面存在显著差异:主要体现在以下几个方面:

模块化设计

Orca通过平等对待每个查询及其在整个优化过程中所涉及的所有元素来实现对扩展性的支持。众所周知，在实际应用中发现多阶段设计存在局限性：新的算法或查询构建往往不符合先前设定好的分界线。

多核支持：Orca采用了先进的多核感知调度器，并通过动态分配每个优化子任务到多个核心来提升优化效率。

可验证性

可验证性

性能表现：Orca作为对旧系统的一次重大升级，在多数场景下实现了十至千倍的查询效率提升。

本文其余内容按如下组织：首先，在第二章里我们简要介绍了计算架构的基本概念。第三章则详细阐述了Orca架构及其组成部分。第四章专门描述查询优化的工作流程。第五部分则深入探讨Orca如何通过后端数据库系统更新元数据。第六章介绍了用于维护可验证查询优化器的相关工具开发过程。第七章概述了我们的实验研究，并在第八章讨论了相关领域的最新进展。第九章总结全文并提出了对未来研究方向的建议。

二、背景知识

在本章中, 我们将阐述大规模并行处理数据库及其相关的Hadoop查询引擎背景知识.

2.1 大规模并行处理

Pivotal's Greenplum Database (GPDB) 是基于 非共享内存架构 的大规模并行处理平台（Massively Parallel Processing）。该平台采用了多个协同处理器（Co-Processors），每个处理器都独立配置了内存、操作系统以及本地存储设备。通过该系统的高性能架构将负载均匀分配至PB级数据仓库，并同时充分利用系统资源以高效执行查询请求。

下图Figure 1则直观地呈现了GPDB的高层次架构。大数据的存储与处理则是通过将负载分发至多个服务器或主机来创建一组独立数据库。所有工作整合在一起以形成一个单一数据库视图。Master作为GPDB的核心入口级节点，在接收到客户端连接请求后会发送SQL语句请求。Master不仅会与其他数据库实例协同执行数据处理与存储任务，并且这些实例被命名为segments。当一个查询提交至Master时，则会经过优化后分解为小组件分别发送至segments以实现最终结果。Networking层则负责管理segments之间的内部通信与数据传输。各段之间采用标准Gigabit Ethernet交换 fabric进行交互。

在数据查询执行的过程中, 数据可以通过多种方式分布在segments中, 包括哈希分发(利用哈希函数将元组分配至segments中)、副本复制分发(将完整的table副本复制并存储在每个segments里)以及集中分发(将整个分布式表从多个segments集中分配给一个特定的host节点, 通常是主节点master)。

2.2 SQL on Hadoop

分析查询逐渐成为越来越受欢迎的处理方案，在Hadoop环境中日益普及。最初阶段, 许多数据处理工作主要以MapReduce任务的形式呈现, 而这一设计特点使得其具有极强的扩展能力和容错能力优势。然而, 开发人员发现编写、优化和维护复杂的MapReduce脚本非常具有挑战性, 因此开发出了基于类SQL语言如Hive等更为高效的解决方案。这些Query会被自动转换并编译为相应的MapReduce tasks, 然后通过该生态系统进行执行操作, 这一过程显著地加速了复杂Query编码效率的同时也揭示出需要在该生态系统中引入一个高效的优化器才能改善其整体性能表现

为了克服这一挑战,Pivotal采用了HAWQ技术。这是一个高性能的大规模并行SQL兼容引擎,该引擎运行于HDFS平台上。其核心模块采用Orca技术,以实现高效的查询优化。该架构融合了基于成本优化的独特创新技术和基础组件具备良好的扩展性和容错能力,从而能够高效处理PB级别规模的数据交互过程。

近期研究中包括Cloudera Impala[17]及Facebook Preso[7]等都引入了新型优化器以增强对Hadoop SQL处理的支持。然而目前这些方案仅能支撑一小部分标准SQL特性且其优化受限于单一规则框架相比之下HAWQ凭借其成熟的标准化兼容性接口与基于成本策略的成本化优化方案实现了前所未有的功能与性能优势我们在第7节详细探讨Orca如何通过区分功能与性能将HAWQ与其他Hadoop SQL引擎区分开来

三、Orca架构

Orca represents a novel query optimizer within the Pivotal data management suite, encompassing GPDB and HAWQ. It draws upon the advanced top-down query optimization architecture of the Cascades framework. A standout feature is its ability to function independently as an optimizer outside the database system. This characteristic is particularly significant for supporting optimized processing across diverse computing architectures, including Message-Passing Parallelism (MPP) and Hadoop. Additionally, it provides a foundation for applying relational query optimizations to emerging computing platforms such as Hadoop. Notably, operating as an independent product allows for detailed testing without altering the underlying database system structure.

为了使优化器与数据库系统解耦化而需构建一种用于处理查询的通信机制

展示出与外部数据库系统进行交互的Orca架构图。其输入端对应于一个基于DXL语言构建的查询语句；输出端则映射到一系列按照优化策略编排好的执行计划；在优化过程中；数据库系统能够接收关于元数据查询的信息（例如表结构信息）。通过动态注册一个 metadata provider (MD Provider)，Orca能够有效地管理元数据访问细节；该机制负责将元数据序列化为可传输的数据格式以便后续处理；此外；元数据还可以通过将标准化格式化的元数据对象保存在常规文件中等方式获取。

数据库系统必须包含Translator来以XML格式接收和发送数据。Query2XML Translator将查询解析树转换为一个基于XML格式的查询语句（XML-based Query），而XML-to-Plan Translator则将基于XML的计划转换为可执行的计划（Executable Plan）。这些Translator完全不在Orca内部实现，并因此使得多个系统能够通过提供自定义Translator来接入Orca平台。

该系统架构具有高度可扩展性；各个组件均可独立替换和单独配置。图中呈现了该系统中的各个组件；随后我们将简要阐述各组件的作用

Memo：我们称优化器生成的可选计划空间作为一个紧凑存储在内存中的数据结构，并将其命名为Memo。该数据结构由一组称为group的容器集合构成，在其中每个group都包含一组逻辑上等价的操作表达式。通过Memo group能够捕获查询中不同子目标（例如，在一张表上的过滤操作或是在两张表之间的连接操作）。这些Group成员被称为group expressions，在它们内部会以不同的逻辑方式（如不同的join顺序）来实现该组的目标。每一个group expression都是一个操作符，并将它的子项作为其他Group存在（即其children则为其他groups）。这种递归式的组织架构使得Memo能够高效地编码海量可能计划的空间，并将在4.1章中进行详细阐述

Search and Job Scheduler ：Orca基于特定算法实现了高效的搜索功能，在可能的plan选择空间中进行遍历，并最终输出具有最低计算开销的结果。该系统的核心组件——Job Scheduler 由多个并行执行的任务单元构成，在三个关键步骤中完成了查询优化：首先生成必要的中间数据；其次对这些数据进行排序和合并；最后完成结果筛选并返回。每个任务单元不仅独立运行还能与其他单元协同工作，在确保系统稳定性的前提下显著提升了整体性能。

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

implementation：生成physical plans

The optimization process will ensure that key physical characteristics are met, which will be enforced as necessary, and the cost associated with optional plans will be calculated as part of the cost analysis.

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

变换：通过使用能够生成等价 logical 表达式的变换规则来创建可选方案（例如将 InnerJoin(A,B) 转换为 InnerJoin(B,A)），或者基于现有表达式进行物理化处理（例如将 Join(A,B) 转换为 HashJoin(A,B)）。这些变换规则的应用结果会被复制到 Memo 中，这可能导致新组的创建或现有组中新增表达式。每个变换规则作为一个独立模块，在 Orca 配置中可显式启用或禁用

Orca采用了可扩展架构以实现对形式化属性规范的支持

Metadata Cache：考虑到metadata（如table定义）通常不会频繁更改，在每次查询时传递metadata可能会导致额外开销。Orca通过缓存这些信息于优化器侧，并且只有当缓存中的某些信息缺失时才需要从catalog中检索相关的片段；或者当上次加载至cache依赖发生变更的时候，则重新获取最新的数据以更新缓存内容。此外，在测试与调试阶段利用优化器能够 abstraction出数据库系统的核心细节

GPOS ：为了实现跨不同API操作系统交互的目的，Orca采用了OS抽象层，并将其命名为GPOS。该层为Orca提供了广泛的基础设施体系结构，并包含内存管理器这一核心组件；此外还提供了基础的并发控制原语功能以及相关的异常处理机制；同时该体系结构还集成了一套完整的文件输入输出功能模块以及一套基于同步机制相关的数据结构。

四、查询优化

我们对第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)等方面的信息。通过 metadata ids (Mdid's) 进行标注（METADATA），以便在优化过程中进一步获取相关信息。其中, Mdid 是一个由数据库系统标识符（DBSI）、对象标识符（OID）以及版本号组成的唯一标识符（unique identifier）。例如,"0.96.1.0" 对应于 GPDB 的 integer equality operator（整数等式操作符），其版本号为 1.0 版本号 (version 1.0) 的 metadata 可能会影响缓存的有效性，在后续章节中我们将详细讨论 metadata 的交换机制

DXL query messages are forwarded to Orca, where they are parsed and converted into a logical expression tree stored in memory. Following these steps, the optimization process proceeds systematically. Figure 4 illustrates the initial state of the Memo buffer. The logical expression was responsible for creating three groups, with join conditions being omitted for brevity. Group 0 is referred to as the root group, as it corresponds to the root node of the logical expression tree. The operators within this structure establish dependencies that are represented as group references. For instance, InnerJoin[1,2] refers to Group1 and Group2 as its children. This hierarchical relationship is essential for maintaining efficient data processing within the system.

Process能够生成逻辑等价expressions的transformation rules被触发。例如，在一个Join Commutativity rule的情况下（如基于InnerJoin[1,2]），会产生InnerJoin[2,1]。Process将导致在已有的groups中添加新的group expressions，并且有可能会创建新的groups。Memo结构包含了一个内置于expression拓扑上的重复检测机制，并用于检测并去除由不同transformations所创建的不同版本带来的重复expressions。

(2) Statistics Derivation ：在探索过程中最后阶段时,Memo负责维护给定查询所对应的完全逻辑空间。随后,Orca启动了其统计数据推导机制,用于计算Memo组内的统计数据信息。Orca的核心部分主要由一系列列直方图构成,这些对象专门用于推导与估计每个字段的数据分布特性及其分布偏差情况。这些统计数据信息将在紧凑地组织好的Memo结构上进行处理,从而有效避免搜索范围出现不必要的扩大现象

为了从目标组中推导统计信息。Orca选择了最有可能生成可靠统计数据的组表达式。统计估算基于指定表达式进行。举例来说，在内联连接操作中只有少量连接条件的情况相比其他情况更具优势。其核心理念在于：随着连接条件数量增加，估计误差传播和放大的可能性也随之提升。因为要在给定表达式的每个节点上综合置信度分数，并且这些值对于估算基数具有重要意义。同时计算这些值对于估算基数具有重要意义，并且是一个具有挑战性的任务。

在目标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方式下的传递时，请确保所有必要的数据已准备就绪。这一过程将在完成对T1.a和T2.b上的处理（可能经过某些修改）后生成新的直方图，并考虑join condition可能会对列的数据分布产生影响

生成的统计指标被系统性地整合到独立的groups中，在优化过程中这些指标可能会逐步得到补充（如新增数据图表）。这有助于确保整个系统的计算开销得以控制在合理范围内。

(3) Implementation：在处理逻辑表达式时, 能够为逻辑表达式生成物理表达式的转换规则会被触发. 例如, Get2Scan规则会将逻辑上的Get转换为物理上的表扫描操作. 类似地, 内联连接操作分别采用哈希连接和逐层循环实现方法.

(4) Optimization：在这一阶段中, properties将被强制执行,并用于计算可选计划的成本.优化过程通过发起一个初始的优化请求至Memo的根组启动,并指定了必要的要求,例如结果分布或排序.随后,将请求r提交至group g,以指示root物理操作器应返回满足r所需的最低成本计划.

每当处理一个 incoming request 时，在优化过程中会多次提交相同类型的 requests 到同一个 group 中。Orca 会将计算完成后的 requests 缓存至 dedicated group hash tables 中，并且只有当待处理的 request 不在该 group 的缓存表中时才进行计算。每个 physical group expression 配备有 dedicated local hash tables 来存储其接收的 request 映射关系，并通过这些 local hash tables 提供 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]所实施的优化方案。该方法的核心在于根据 join conditions 对 child distribution 进行精确配准,从而确保参与 join 的元组位于同一位置（co-located）。这一配准过程具体体现在两个子组别中：group1要求所有元组需满足 Hashed(T1.a),而 group2则要求所有元组需满足 Hashed(T2.b)。需要注意的是,这两个子组别都必须满足 Any sort order 的条件才能完成 join 操作。在确定最优 child plan 后,InnerHashJoin将整合 child properties 来决定最终的 distribution 和 sort order 策略。特别地,group2的最佳计划要求对 T2 按照 T2.b 进行 hash 分布;然而,由于 T2 的原始数据本应按照 T2.a 进行 hash 分布（而 group1的最佳计划则采用了简单的扫描方式）,因此这一策略得以实施的原因也得到了合理解释

当确认交付的properties未能满足初始设定的要求时, 未被要求满足的部分需经由enforcement机制处理. Orca框架内的Property enforcement机制设计灵活, 允许每个operator根据其本地行为及child plans交付的结果来制定必要的行为规范. 例如, 在某些情况下（如保持顺序的操作）, 一个NL Join operator可能无需在join顶部强制排序.

将Enforcers纳入包含正在优化的关键表达式的组别中

最后,该计划会基于优化请求提供的链接结构从Memo中提取出来。如图6所示,该计划提取的过程进行了运行示例展示。我们展示了相关group expressions的local hash tables,这些数据结构用于记录与每个优化相关的中间结果信息,并为后续处理提供了基础支持。每个local hash table将接受到的优化request映射到了对应的child optimization requests中进行处理

随后，在root组内进行查询操作以获取所需的目标分组表达式, 该操作指向的是Gather Merge操作符.In Hashtable表中发现该目标分组表达式的子请求即为目标#3号请求; 对于目标#3号请求, 其最佳分组表达式对应的是排序算法; 因此我们建立了将目标#3与排序算法相关联的关系; 在本地Hashtable表中发现排序算法对应的目标#4号请求; 对于目标#4号请求, 其最佳分组表达式对应的是内层哈希连接操作[1,2]; 因此我们建立了将排序算法与内层哈希连接操作相关联的关系; 按照同样的步骤继续执行上述操作流程, 最终获得如图6所示的目标提取方案

The extracted plan will be serialized into the DXL format and transmitted to the database system for execution. Within the database system, the DXL2Plan translator, operating based on the underlying execution framework, will convert the DXL plan into an executable plan.

Multi-Stage Optimization 包括在Orca中的持续工作中的多阶段优化过程。在Orca系统中每个optimization stage基于transformation rules的一个子集以及可选设置中的timeout参数和cost阈值被定义为完整的优化流程。一旦以下任一条件得到满足，则该stage就会停止：

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

超时

transformation rules子集执行完毕

该系统允许用户设定特定的欧化阶段（Stage），从而实现对计算资源的有效管理与优化（Optimization）。这种方法通过将耗时最长的任务配置（Transformation Rule）延迟至后期阶段执行（Execute），能够在不显著增加整体优化时间的前提下（Without noticeably increasing the overall optimization time）实现资源的最佳利用效率（Efficiency）。此外，在规划查询执行流程时（During Query Plan Construction），采用此方法能够更快地获得初始查询计划（Initial Plan），从而有效减少复杂查询中的搜索空间（Search Space）。

Query Execution：在分布式查询执行过程中，在每一个segment上都会依次传递一个final plan副本。每个segment上的distribution enforcer不仅接收来自本地的数据请求，并且会转发这些请求至其他segment进行处理。例如，在Redistribute(T2.b)实例运行于Segment S时，该实例基于T2.b的hash值会将Segment S上的元组分发至其他segment进行处理，并持续接收自其他segment的Redistribute(T2.b)实例而来的元组进行处理。

4.2 并行查询优化

查询优化可能涉及数据库系统中对CPU的最敏感环节。高效率地利用中央处理器资源能够转化为更为有效的查询策略，并最终带来更高的执行结果。并行查询优化器 在适应采用越来越多cores的高级处理器设计方面扮演着关键角色。

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中的参数和优化请求req生成相应的计划。其中该计划具有minimal estimated cost.

Opt(gexpr, req) ：在组g中基于gexpr作为根节点进行调整，并返回一个满足优化请求req、且具有最低估计成本的计划。

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

对于一个给定的查询，在其每个类型中都会生成大量（成百上千）jobs。

Orca features a custom-designed job scheduler from the outset. This scheduler aims to maximize the fan-out of dependency graphs and provides the necessary infrastructure for parallel query optimization. The scheduler offers APIs to define optimized jobs as interruptible processes. It also maintains the dependency graph to identify parallel opportunities (for example, in different groups, transformations are executed). When dependent tasks complete, it notifies blocked jobs.

During the process of optimizing parallel query performance, multiple concurrent requests to modify Memo groups may be triggered by different optimization requests. The primary objective is to minimize synchronization overhead among jobs with identical goals, such as exploring the same group. Without jobs being aware of each other’s existence, when an optimization job with specific goals is processing, all jobs sharing these goals will be blocked until they receive a notification indicating that a running job has completed. This functionality is achieved by associating each group with a dedicated job queue, ensuring efficient task management.

五、Metadata Exchange

Orca被特意设计为不直接与数据库系统进行交互，默认情况下它专注于执行外部操作. 元数据交换成为优化器与数据库系统之间的主要交互机制. 例如，在设计查询计划时, 优化器需要了解每个表格是否具备索引. 元数据通过一组特定的元数据提供者（metadata providers）访问, 这些提供者都是系统定制化的插件模块, 可以从预定义的存储位置中提取这些信息.

如图9所示，在与不同后端系统的互动中

除了系统内预定义的providers外（system-specific predefined providers除外），Orca还开发了一个基于文件的方法（method）引入MD数据源（data source），以便从DXL文件（DXL file）加载元数据（metadata）。这种设计彻底去除了对活动后端系统的访问权限依赖（dependency）。Orca内置了自动化的数据整理模块（module），专门提取并整合所需元数据到最小规模的DXL文件中（smallest DXL file）。在第6章1节中阐述了如何通过无需连接后端数据库的方式执行客户端查询优化方案（scheme）。

六、可行性

6.1 Minimal Repros

AMPRe[3]专门用于捕捉最低限度的、易于执行的最小可移植且可执行性保证的再现工具。建立AMPRe的目的在于能够在优化器环境中实现对客户问题进行还原与调试，并且无需访问客户的生产系统。

略

6.2 优化器准确性测试

Orca的成本模型可能存在一定的准确性问题，并非完全没有影响。这些准确性问题主要源于基数cardinality估计不够精准以及所采用的成本模型参数设置不当两个方面的原因，在计划执行wall clock时间时会体现出明显的局限性。量化优化器的准确性在防止因bug修复或新增特性而导致的性能回滚方面具有至关重要的作用

Orca内置了一个名为TAQO[15]的工具。该工具用于评估查询优化器准确性。具体而言,TAQO衡量任何两个给定计划在实际运行时间上正确排序的能力。例如,在图11中,正确的排序是对(p1,p3)这一组计划,因为它们的实际成本与计算的成本估计直接成比例;而对(p1,p2)这一组计划,则不正确的排序是因为它们的实际成本与计算的成本估计呈反比关系。

略

七、实验

略

八、相关工作

过去几十年间, 查询优化始终被视为推动信息技术进步的关键领域. 本节中, 我们将会深入探讨一系列基础性的查询优化技术, 并结合MPP数据库及基于Hadoop的系统领域的最新发展建议.

8.1 查询优化基础

该分布式系统基于并行计算实现了数据库的核心功能。该框架引入了交换算子（Exchange operators），支持通过流水线实现算子间的并行以及跨进程划分元组实现算子内部的并行（Operator-level parallelism）。这种设计使得每一种操作符可以在本地数据集上独立运行，并与位于不同进程的操作符副本同步协作（Synchronized execution across operator instances）。参考文献中的多个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, SIGMOD Conference, 2009）中首次提出了一种并行化查询优化架构。这种架构能够支持多核架构上的类级联查询优化任务。此外，在文献[30]所提出的分层架构基础上进行延伸和改进后，在Orca系统中实现了分层式并行查询处理机制。

8.2 基于MPP数据库的SQL优化

略

8.3 SQL on Hadoop

略

九、总结

基于Orca平台的开发项目旨在构建一个支持高效查询优化的平台系统。该系统集成了最前沿的技术方案，并具备强大的功能模块和良好的扩展性特点，在实现新型优化技术和复杂高级查询功能方面均展现出显著的技术优势和应用潜力。

在本文中, 我们阐述了一个自足式构建系统的工程工作流程. 将关键的技术保障融入Orca系统构成了重大的投资, 然而, 通过高效的开发节奏与由此产出的高质量软件, Orca系统已实现了显著的价值回报. Orca系统的架构模块化设计使其能够灵活应对多种数据管理系统, 并采用简洁统一的数据抽象来组织系统的功能与元数据.