论文笔记：Query Optimization in Microsoft SQL Server PDW

摘要：现阶段，MMP（Massively Parallel Processors）更多地被用于分布式并行查询数据，对于这种类型的系统，本文解释了SQL Server PWD （并行数据仓库）内部的查询优化器（PDW QO）。利用现有的QO技术来实现分布式查询执行的基于成本的优化器。通过适当的抽取 Metadata ，重用现有的逻辑来简化查询、探索空间和估计基数。

Overview of SQL Server PDW（PDW 概述）

SQL Server PDW是一种share-noting 的并行数据库APP，用于处理存储管理和查询海量数据，是SQL Server的MMP系统。

下图为SQL Server PDW的框架图。具体模块功能在下文描述。

MICROSOFT SQL SERVER PDW ARCHITECTURE OVERVIEW（PDW 并行优化概述）

Appliance

PDW APP由硬件和软件组成，被封装成一个box，用户通过接口访问box。多客户端之间以share-nothing的方式共同处理大规模并发查询。

实现查询处理功能的有两种类型的节点：

• Control node：控制节点管理计算节点在query执行节点的部署，提供PDW设备客户端的接口，并且管理客户端的用户验证。用户可以通过客户端访问工具（例如：ODBC、OLE DB、ADO.NET等）访问PWD控制节点。
  • a SQL Server instance：内有一个Shell DB，用于存储全局数据。
  • PDW Engine：查询解析、生成分布式执行计划、向计算节点发布计划step、追踪计划的执行step，并将最终结果的各个部分封装成返回给用户的单个结果集。
  • DMS（Data Movement Service）：运行在设备节点，设备中节点之前传输通信的接口。
• Compute Nodes：听从PDW　Engine的调度，执行分布式的子查询计划。存储部分用户数据，可通过DMS进程与其他节点进行同通信。

表数据有两种分片方式：在计算节点上的replicated和跨计算节点在指定列上的hash-partitioned。

控制节点和计算节点各有一个的SQL Server RDBMS实例，用户数据存储在计算节点上SQL Server实例之间的哈希分区或复制表中。

Shell Database

SQL server上有一个shell DB

• 用于存储所有的Metadata和表的统计信息，但不存储用户数据。
• 测试和调试编译问题，不需要copy大型DB
• 储有关用户和权限的所有信息
• 存储所有表全局信息。

Data Movement

负责所有节点的数据的移动。在执行查询时，可能会需要将中间结果集从一个节点移动到另一个节点，或者需要将中间结果集在返回给客户端之前进行最终的聚合处理。PDW根据需求在节点生成临时表来移动或存储中间结果集。

The DSQL Plan and its Execution

对于用户给定的SQL查询，PDW Engine 需要负责生成一个并行的执行计划（DSQL Plan），DSQL 计划包含以下操作：

• SQL operation：直接在一个或多个计算节点上的SQL Server DBMS实例上执行的SQL操作
• DMS operation：在节点之间移动数据以进行进一步处理的DMS操作
• Temp table operations：生成临时表以供进一步处理。
• Return operations：将数据返回给客户端的操作。

SQL Plan 是按照顺序执行的。但是每个step中并发执行。

举个栗子：

以TPC-H模式为例，假设Customer表在c_custkey上进行了hash-partitioned，Orders表在o_orderkey上进行了hash-partitioned，SQL语句如下：

SELECT  c_custkey,
        o_orderdate
FROM Orders, Customer
WHERE o_custkey = c_custkey AND o_totalprice > 100

DSQL plan主要分为两个step：

• Step1：DMS Operation：在o_custkey上重新划分Orders数据。PDW Engine 将DMS operation 广播到每个节点。节点收到消息后，发出以下SQL语开始执行数据移动。DMS实例从SQL Server中抽取结果tuples，通过hash将tuples插入到相应的DMS实例中，然后将从其他DMS实例接收到的tuples保存到中间结果表中（本例中为Temp_table）。

SELECT o_custkey,
o_orderdate
FROM Orders
WHERE o_totalprice > 100

• Step2：Return SQL Operation：从每个计算节点提取结果元组的SQL操作。PDW Engine 发出以下SQL语句：

  SELECT c.c_custkey,
  tmp.o_orderdate
  FROM Customer c,
  Temp_Table tmp
  WHERE c.c_custkey = tmp.o_custkey
  

  引擎服务从每个计算节点收集结果元组，将它们集成为最终结果，并返回客户端。

Cost-Based Query Optimization in PDW

下图为PDW QO的数据流图。其组件有：

• PDW Parser：负责解析输入的query ，生成语法抽象树（AST），传递给SQL Server。
• SQL Server Compilation: 根据shell数据库存储的全局数据进行编译输出最优执行计划（串行），但是不会生成最优分布式执行计划。
  • 将输入运算符树简化成通用模式。将其作为初始计划加入MEMO结构中。MEMO中保存备选的查询计划。
  • 对查询计划进行逻辑枚举。
  • 估计每个备选执行计划的中间结果的size
  • 为算子进行逻辑枚举，比较成本，进行剪枝。
  • 提取最佳执行计划。但是PDW并不选择最优的串行执行计划，而是将Memo中整个search space都保留下来。
• XML Generator:将MEMO数据结构中表示的SQL Server优化器生成的搜索空间编译成XML。
• PDW Query Optimizer:解析 XML Generator 输出的搜索空间构建MEMO 数据结构，在成本模型的辅助下进行自底向下的优化。
  • 添加data Movement策略来枚举分布式的执行计划
  • 根据PDW从成本模型对生成的备选执行计划进行成本估算
  • 选择最佳（成本最低）执行计划

下图为查询语句的查询优化处理流程。主要分为以下几个步骤:

1. 解析输入的查询
2. 生成逻辑查询树
3. 在控制节点的SQL Server 实例中进行优化，生成MEMO搜索空间（串行）
4. 传递给PDW QO，枚举Shuffle/Replicate等算子，生成分布式并行执行计划。
5. 基于成本模型选出最优执行计划
6. 生成DSQL Plan，DMS operation + SQL operation

SELECT *
FROM CUSTOMER C, ORDERS O
WHERE C.C_CUSTKEY = O.O_CUSTKEY
AND O.O_TOTALPRICE > 1000

IMPLEMENTATION OF PDW QO( PDW QO的实现)

Changes to SQL Server

需要对SQL Sever 进行一些修改，以支持PDW QO

• 支持导出搜索空间。定义了一个新的编译入口点来请求优化器MEMO。当 PDW编译被请求时，SQL Server 的输出是MEMO数据结构的XML表示。
• 扩展SQL语法，主要针对的是能够处理一些PDW相关的分布式策略的 query hints。
• 扩展搜索空间以能够处理分布式的查询执行计划。
• 在enumeration过程中，也会倾向对分布执行更有利的一些优化方式。

Plan Enumeration

因为搜索空间非常大，而且因为分布式执行计划的引入，除了简单的query外，朴素枚举方法已经不能够满足。PDW采用自下而上的搜索策略，但是自上而下的策略也同样适用。

自下而上：从优化查询中最小的表达式开始，然后使用这些信息逐步优化较大的表达式，直到找到完整查询的最佳物理计划。

Interesting properties：系统R中引入的 interesting order 概念的扩展，添加了distribution属性。

处理流程如下图：

1. 解析MEMO XML成PDW MEMO
2. MEMO预处理，比如修正基于PDW拓扑的部分聚合的基数估计
3. 从group角度合并等价 group expression
4. 生成每个group的interesting property
5. 对每个group
   1. 枚举：对来自group的所有可能输入枚举PDW分布式执行计划，生成新的group expression。
   2. 基于成本的修剪：只保留总体最佳执行计划和每个interesting property的最佳执行计划。每次向MEMO中添加新的PDW group expression时都要进行剪枝。
   3. 基于之前当前 group 生成的interesting property，枚举可能的move group expressions。然后在进行步骤2的剪枝操作。
6. 从root group中获取最优计划树。
7. 生成DSQL Plan

Cost Model

为建立DMS成本模型，做出以下基本假设：

• DSQL Plan 的step之间是串行执行的
• query 是独立运行的，不考虑并发
• 所有节点的都是同质的
• 数据是均匀分布的

DMS Operations

• Shuffle Move (many-to-many)
• Partition Move (many-to-one)
• Control-Node Move
• Broadcast Move.
• Trim Move
• Replicated broadcast
• Remote copy to single node

Cost of a DMS operator

下图为DMS operator 的基本架构，他有两个独立的组件source 和 target。

source 用于发送数据，有两部分成本组成：

• Creader：针对SQL Server执行的查询中读取元组，并将它们打包到缓冲区中的cost
• Cnetwork：通过网络发送数据缓冲区的cost

数据通过网络异步发送，因此source的cost如下：
$$Csource=max(Creader,Cnetwork).$$
target 用于接收数据，有两部分成本组成：

• Cwriter:从发送过程发送的缓冲区中解压缩元组，并准备插入临时表的缓冲区。
• CSQLBlkCpy:将数据缓冲区插入SQL Server临时表的大容量复制操作。

临时表中的大容量插入是异步完成，因此target的cost如下：
$$Ctarget=max(Cwriter,CSQLBulkCpy).$$
DMS operator 的source和target在每个节点上并行运行，因此，DMS operator 的成本定义如下：
$$CDMS=max(Csource,Ctarget).$$
随着时间的推移，调试和维护成本模型变得更加困难。当前版本的成本模型根据处理的原始字节数对每个组件进行成本计算：
$$CX=B\ast \lambda$$
其中B是原始字节数，λ是特定组件（CX）的每字节成本。

DSQL Generation

一旦PDW查询优化器确定了查询执行计划，就需要将其转换为DSQL格式。与其他MMP系统向计算节点发送operator tree 不同的是，PDW发送的是SQL语句。因此，执行DSQL生成需要将一个运算符树并将其转换回SQL。这里采用的是QRel编程框架。过程如图6所示。