Orca: A Modular Query Optimizer Architecture for Big Data 论文解读

Orca: A Modular Query Optimizer Architecture for Big Data 论文解读

Abstract

大型数据管理系统中数据查询的效率和表现一直是研究的热点，具体来说，像是对数据库系统，就体现在 SQL 查询语句的执行效率上，而 SQL 语句的执行效率，除了和数据库本身的存储结构相关以外，最重要的还是和数据库查询优化器对 SQL 的优化相关。因此，对于查询优化器的研究和开发从未停止。Orca 就是pivotal 开发的一款开源查询优化器，主要用于 Pivotal Greenplum Database and Pivotal HAWQ 这两个项目，其中，Greenplum 在 github 上开源。

1 INTRODUCTION

虽然查询优化的技术已经经过了很多年的研究，但是已有的开源技术大多是比较落后，参考性并不强，Orca 使用了较新的技术，保证了其查询优化的能力，具体来说，在以下几个方面都具备优势：

• 模块化

  Orca 分为多个模块，分别承担不同的功能，包括对系统元数据的缓存，优化模块等，不同模块间独立性强。

• 延伸性

  通过将查询及其优化的所有元素表示为同等重要的一等公民，Orca避免了多阶段优化的陷阱。其中某些优化是作为一个事后想法处理的。众所周知，多阶段优化器很难扩展，因为新的优化或查询结构体通常与先前设置的阶段边界不匹配。

• 多核

  Orca部署了一个高效的多核感知调度器，将各个细粒度的优化子任务分配到多个核心上，以加速优化过程。

• 验证工具

  开发者在验证工具上做了许多开发，保证能测试 orac 的准确度和性能

• 性能

  Orca 的性能较先前开发的系统提高了千倍以上。

2 PRELIMINARIES

预备知识

​ 这部分主要介绍了 Orca 部署测试的数据管理系统：GPDB 和 Hadoop

2.1 Massively Parallel Processing

GPDB是一种大规模并行处理（MPP）分析数据库，采用无共享的计算架构，由两个或多个处理器协同工作。每个处理器都有自己的处理器、内存、操作系统和磁盘。每个用户与一个 master server进行连接，并传递 SQL 进行查询优化处理，下面是 GPDB 的架构图：

GPDB 的master 与存储数据的 Segment Servers 相联系，在处理 SQL 优化的任务时，会将优化的任务分为多个部分，分配给不同的 Segment Server ， GPDB 可以使用外部数据源，这时候需要通过 Segment Server 去和外部数据源沟通。

在 Query 执行的过程中，数据会被散列分布到不同的 Segment Server 上，分布的方式包括散列分布（tuples 依据散列函数进行分布）或者复制分布（整个表的数据被收集并分布在一个 Segment Server 上）。

2.2 SQL on Hadoop

Hadoop 上的 SQL 执行正在变得流行，简单的 SQL 语句可以以 MapReduce 任务在 Hadoop 上处理，但是对于复杂的 SQL 语句并不适用，HiveQL 正是在 Hadoop 上实现的一种类 SQL 语言，负责将 SQL 语句翻译为 MapReduce 任务并执行。

pivotal 实现了 HAWQ，一个在HDFS执行的并行的 SQL 编译引擎。HAWQ 以 Orca为核心，设计高效的查询计划，最大限度地降低Hadoop 集群中访问数据的成本。

现在有许多系统 Cloudera’s Impala，Facebook’s Prest 都设计了在 Hadoop 上的 SQL 语句查询优化器，但是效果欠佳，作者以为是不如HAWQ 的。

3 ORCA ARCHITECTURE

Orca是一个基于Cascades 优化框架的自顶向下的现代查询优化器。关于Cascades，会写一篇解读相关论文的文章。

虽然许多 Cascades 优化器与它们的宿主系统紧密耦合，但 Orca 的一个独特特性是它能够作为一个独立的优化器在数据库系统之外运行。这种能力对于支持具有不同计算架构的产品（例如MPP和Hadoop）而使用一个优化器是至关重要的。它还允许在新的查询处理范式（如Hadoop）中利用关系优化的广泛遗产。

DXL

解耦优化器和数据库系统需要建立一种通信机制来处理查询。Orca 包含一个用于在优化器和数据库系统之间交换信息的框架，称为数据交换语言（Data eXchange Language, DXL）。该框架使用基于 xml 的语言对通信所需的信息进行编码，例如查询输入、输出计划和元数据等。下图展示了一个数据库系统是如何和 Orca 系统进行沟通的：

这其中有几个部分是至关重要的：数据库系统需要有 使用/发出 DXL格式数据的转换器。

• Query2DXL translator 将查询解析树转换为 DXL查询。
• DXL2Plan translator 将 DXL 计划转换为可执行计划。
• 元数据的传递也是通过 MD provider 传递的。

这种转换器的实现完全在 Orca 之外完成，通过提供适当的 translator ，Orca 可以被多种系统使用。

Memo

优化器生成的备选计划空间编码在一个紧凑的内存数据结构中，称为 Memo。Memo 结构由一组称为组（group）的容器组成，每个组包含逻辑上等价的表达式。Memo Group 捕获一个查询的不同子目标，例如对一个表的过滤操作或者是表之间的连接操作，这些都可以以一个 Group 表示，不同的 Group 之间有父子关系。Memo 的这种递归结构允许对大量可能的计划进行紧凑编码，Section 4.1会详述这种结构。

Memo 的设计上与 cascades 查询优化器相同。

Search and Job Scheduler

Orca使用搜索机制在可能的计划空间中搜索查询计划的代替计划，并以最小的估计成本确定计划。搜索机制由专门的 Job Scheduler 启用，该 Job Scheduler 创建依赖的并行的工作单元，以执行查询优化，分为三个主要步骤：

• exploration，即生成等效的逻辑表达式；
• implementation，即生成物理计划；
• optimization，即强制执行所需的物理属性（例如，排序顺序）并计算计划替代计划的成本。

section 4.2 将会详细讨论这个过程。

Transformations

替代方案是通过应用转换规则生成的，这些转换规则可以生成等价的逻辑表达式（例如，InnerJoin(A,B)→InnerJoin(B,A)），或者现有表达式的物理实现（例如，Join(A,B)→HashJoin(A,B)）。

Property Enforcement

Orca　包括一个可扩展的框架，用于描述基于形式化属性规范的查询需求和规划特征。属性有不同的类型，包括逻辑属性（例如输出列）、物理属性（例如排序顺序和数据分布）和标量属性（例如连接条件中使用的列）。在查询优化期间，每个操作符可以从其子节点请求特定的属性。

Metadata Cache

由于元数据（例如表定义）不经常更改，因此将其与每个查询一起发送会产生额外的开销。Orca　在优化器端缓存元数据，只有在缓存中不可用或自上次加载到缓存以来已更改时，才从目录中检索元数据。

GPOS

为了与可能使用不同 API 的操作系统交互，Orca 使用了一个称为 GPOS 的操作系统抽象层。

4 QUERY OPTIMIZATION

Section 4 中以

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

为例，展示 Orca 的优化流程。

以下是 DXL 表示下的查询计划：

4.1 Optimization Workflow

在优化流程开始之前，查询计划在 Memo 中保持下面的状态：

在最初的状态中，查询计划被分成3个Group，根 Group 是 Group 0 表示T1表和T2表的内连接，Group 1 表示对 T1 表的数据获取，而 Group 2表示对 T2 表的数据获取。

(1) Exploration

在这个阶段，触发生成逻辑上等价表达式的转换规则。

探索结果是向现有 Group 添加新的 Group 表达式，并可能创建新的组。例如，触发连接的交换性规则，从 InnerJoin[1,2] 中生成InnerJoin[2,1]。Memo 结构具有内置的基于表达式拓扑的重复检测机制，可以检测和消除因不同变换而产生的重复表达式。

(2) Statistics Derivation

在 Exploration 的最后，Memo 维护给定查询的完整逻辑空间（这里如果按照 Cascades 的逻辑，应该并不是一个完备的搜索空间？）。然后触发 Orca 的统计信息派生机制来计算 Memo Group 的统计信息。Orca 中的统计对象主要是用于估计基数和数据倾斜的列直方图的集合。统计数据的推导发生在压缩 Memo 结构，避免扩大搜索空间。

为了获得目标组的统计信息，Orca 选择了具有最高承诺（the highest promise）的 Group expression，以提供可靠的统计信息。统计量承诺的计算是特定于表达式的。例如，具有少量连接条件的 InnerJoin 表达式比具有大量连接条件的等效 InnerJoin 表达式更有承诺（more promising）（在生成多个连接顺序时可能会出现这种情况）。其基本原理是，连接条件的数量越多，估计错误传播和放大的可能性就越大。

在目标 Group 中选择最有希望的组表达式后，Orca 递归地触发所选 Group Expression 的子组（Child Group） 的统计信息推导。最后，结合子组（Child Group） 的统计对象构造目标 Group 的统计对象。

图5说明了运行示例的统计信息派生机制。首先，执行自顶向下的传递，父组表达式从其子组请求统计信息。例如，（a=b）上的InnerJoin(T1,T2) 请求 T1.a 和 T2.b 上的直方图。所请求的直方图通过已注册的 MD Provider 按需从目录加载，解析为 DXL 并存储在MD 缓存中，以服务未来的请求。接下来，执行自底向上的传递，将子统计对象组合为父统计对象。这将导致列 T1.a 和 T2.b 上的直方图可能经过修改，因为连接条件会影响列的直方图。

(3) Implementation

触发创建逻辑表达式的物理实现的转换规则。例如，触发 Get2Scan 规则依据逻辑 Get 生成物理表 Scan 。类似地，InnerJoin2HashJoin和 InnerJoin2NLJoin 规则被触发来生成哈希和嵌套循环连接实现。

(4) Optimization

在此步骤中，Orca 执行属性并计算计划替代方案的成本。优化开始于向 Memo 的 root group 提交初始优化要求，优化要求是指定的查询需求，如结果分布和排序顺序。向组 g 提交要求 r，意为请求满足要求 r 且以组 g 中物理表达式为根算子的查询计划（组 g 中有多个等价表达式实现的物理表达式）。

对于优化过程中的优化要求，物理表达式会将这些优化要求传递到其对应的子组中，在这个递归的过程中，可能会出现对某一个 group 的基于相同的优化要求的计算，这时就依赖于group hash table来防止重复计算。

下图6展现了上述 SQL 语句在 Memo 中运行优化的全过程：

初始优化要求为 req.#1:{Singleton，<T1。a>}，它指定需要根据 T1.a1 给出的顺序将查询结果收集到主数据库． 左侧的 Group hash Tables 展示了其中每个优化要求都与满足最少估计代价的最佳组表达式（GExpr）相关联。

图7显示了由 InnerHashJoin[1,2] 对req.#1 的优化过程。对于这个要求，一种替代方案是根据连接条件调整子分布，以便要连接的元组是的分布是同步的。这是通过对组1进行 Hashed(T1.a) 和对组2进行 Hashed(T2.b)。两组都被要求排序。找到子最佳计划后，InnerHashJoin[1,2] 结合子属性来确定交付的分布和排序顺序。组1的最佳计划是简单的 Scan，因为 T1已经按照 T1.a 进行了散列分布（a是T1的主键，之前已经保持散列分布）。注意，组2的最佳计划需要在 T2 上散列分布 T2.b，而T2.b 本身并不是 T2 的分布键，因此需要加入 Redistribute(T2.b) 操作符，这是一个enforcer（属性执行操作符）。

关于 enforcer

当确定交付的属性不满足初始优化要求时，必须强制执行未满足的属性。Orca 中的属性强制执行在一个灵活的框架中实现 ，允许每个操作符根据子计划交付的属性和操作符本地行为定义需要强制执行的属性。例如， NL Join 操作符的子操作符已经排过序，那么操作符之上不再需要排序操作。若否，则需要添加额外的 enforcer（执行操作符）。

其中黑色方框表示在 Memo 中插入的 enforcer（执行操作符），用于传递排序顺序和数据分发。其中，Gather operator从所有Segment Server 向 Master 收集元组。 GatherMerge operator 从所有 Segemnt Server 收集到 Master Server，时保持排序顺序。**Redistribute operator **根据给定的哈希值，在段中分发元组。

执行操作符会在 group 被优化时加入，图7显示了满足 req. #1 强制属性的两种可能的计划。左边的计划对 Segment Server上的连接结果进行排序，然后在 Master Server上收集已排序的结果。右边的计划收集 Segment Server 上的连接结果到 Master Server，然后对它们进行排序。这些不同的替代方案使用了不同的 enforcer（执行操作符），并在在 Memo 中进行了编码，由成本模型来区分它们的成本。

最后，根据优化要求给出的链接结构，从 Memo 中提取出最佳方案。图6说明了运行示例的计划提取。每个本地哈希表将传入的优化要求映射到相应的子优化请求。

我们首先在 root group 查找 req. #1 的最佳 group 表达式。它指向 GatherMerge 操作符。在GatherMerge 的本地哈希表中对应的子请求是req# 3。req# 3的最佳组表达式是 Sort。因此，我们将 GatherMerge 链接到 Sort 。Sort 的本地哈希表中对应的子请求是 req# 4。req# 4 对应的最佳 group 表达式是 InnerHashJoin[1,2]。因此，我们将 Sort 链接到 InnerHashJoin。按照相同的过程完成方案提取，最终得到如图6所示的方案。

Multi-Stage Optimization.

可以看到 Orac 的优化算法是多阶段的。这种多阶段的优化算法会在下面情况发生时被终止：

• 代价剪枝
• 搜索超时
• 规则已经被穷尽

Query Execution.

最终的执行计划会被分发到不同的 Segment Server 上进行执行。

4.2 Parallel Query Optimization

SQL 查询优化是 CPU 消耗型地操作，因此最大程度地利用 CPU 的性能可以极大地提升 SQL 优化地效率，例如，利用 CPU 的多核执行并行计算。Orca是一个支持多核的优化器。优化过程被分解为称为优化作业的小工作单元。Orca目前有七种不同类型的优化工作：

• Exp(g)
• Exp(gexpr)
• Imp(g)
• Imp(gexpr)
• Opt(g, req)
• Opt(gexpr, req
• Xform(gexpr, t)

下图展示了这些工作在一个查询计划的优化过程中是如何分配的。

5 METADATA EXCHANGE

MD 获取的设计提前其作为外挂优化器的灵活性：

不同的外部系统，都可以基于 MD Provider 提供适配的元数据，元数据会在优化期间保存在MD Cache中，优化结束后可以释放，有个有趣的地方是最左侧的File based Provider，也就是说Orca可以完全不依赖于一个在线系统，这种用local file来mock一个DB的方式，使得Orca可以被更好的测试、调试和验证。