PolyBase中的拆分查询处理

最新推荐文章于 2024-03-30 14:36:32 发布

夏天de雪

最新推荐文章于 2024-03-30 14:36:32 发布

阅读量3.7k

点赞数

分类专栏：算法

算法专栏收录该内容

6 篇文章 0 订阅

订阅专栏

DavidJ. DeWitt, Alan Halverson, Rimma Nehme, Srinath Shankar,

JosepAguilar-Saborit, Artin Avanes, Miro Flasza, and Jim Gramling

微软公司

dewitt,alanhal, rimman, srinaths, jaguilar, artinav, miflasza, jigramli @microsoft.com

摘要

本文提出的PolyBase,，SQL Server PDW第二版有的一个特点，它允许用户中用标准的SQL查询语句去管理和查询存储在Hadoop 集群的数据。不像其他的数据库系统那样，通过使用外部表机制，提供一个基于分布式文件系统当时数据的关系视图，PolyBase采用了拆分查询处理的模式，通过这种方式，SQL语句操作符把分布式文件系统当时数据通过PDW查询优化器翻译成MapReduce(一种编程模型)指令，然后在Hadoop集群上执行。本文介绍了PolyBase在使用过程中的设计和实施，及评估采用一种拆分查询处理模式的好处，该模式执行涉及与关系型数据库管理系统中的结构化数据及Hadoop架构下的非结构化的数据的查询。我们的测试结果表明，当采用基于拆分查询的模式时，可以使某些查询的效率提高10倍之多，但这是基于提高查询优化器的成本。当决定把SQL操作提升到Hadoop架构是否的有利时，得考虑一系列的因素。这些因素包括谓词的选择性因素，两个集群的相对大小，及他们的节点是否在同一位置，此外，要仔细考虑Java和SQL语言的语义的不同，以避免改变一个查询的预期结果。

分类和主题描述

H.2.4[数据库管理]：并行数据库查询处理。

关键字

拆分查询，并行数据库系统，Hadoop架构，HDFS

1 简介

存储和分析大量数据，这曾仅限于少数大型企业中，但现在已经扩大并快速增长了。在此数据中的大部分和用传统的方式通过数据仓库管理的数据类似。因此，它可以理所当然地在关系型数据库系统存储和处理。然而，越来越多的时候，此数据还没有存储在RDBMS中，它被存储在一种文件系统中，留供特设方案来分析。一个常见的例子：存储在Hadoop分布式文件系统上的数据，通过Hadoop组件去分析，应用MapReduce, Hive, 或者Pig等方式。

公司选择使用HDFS/Hadoop，而不是RDBMS.，是有许多原因的。一个显然的原因是成本问题---一个HDFS/Hadoop要获得并行数据库管理系统的性能，花费会比它小很多。另一个原因是编程模式--------有些人乐于编程，兴趣高于写SQL语句。此外，虽然关系数据库管理系统的分析功能增加，但看起来，它描述文件中特定的独立程序分析与SQL语句分析扩展更自然了。此外，对于某些类型的数据，用户看不到所需的努力价值，需要清除数据、定义架构，将数据转换到适合的架构，然后将其加载到一个RDBMS，最后产生个大的数据集，它表面上没有任何结构----可以认为是文本的集合，如电子邮件或网页。截至目前，处理RDBMS外面的数据比其内部的数据更容易。

在本文中，存储在一种文件系统，如分布式文件系统的数据，它是非结构化的数据，它是RDBMS之外的，而RDBMS里的数据是结构化的。非结构化数据是很少真正的“非结构化”。事实上，大多数存储在HDFS中的数据集包括大量的高度结构化的记录。

处理结构化和非结构化数据是分开的，经过不断的努力，人们渐渐地不再满足这种情况。人们在分析结构数据时，也希望对相关的非结构化数据进行分析，并希望分析两种类型的数据的组合。此外，即使RDBMS中的数据分析，可能要使用工具，如用MapReduce完成某些任务。同样，人们分析非结构化数据集使用声明式的编程技术，如HiveQL 和 Pig技术。保持结构化和非结构化的数据完全隔离，不再可行。我们相信，企业将越来越多地需要系统，在该系统中，两种数据都可以存储，都可以有效的分析，他们之间毫无障碍。已经开始出现了各种各样的解决方案，包括连接器，如Sqoop[1]，在HDFS文件的外部表
允许SQL查询，透明地访问存储在HDFS中的数据，和新颖的“拆分查询”系统、及具有Hadoop组件的紧密集成到一个单一的系统。

在本文中，我们描述的PolyBase，有个SQLServer的特征，它是并行数据仓库产品(PDW) V2。像Oracle [3], Greenplum [4], 及 Asterdata [5], Polybase提供了一个外部表机制，给了SQL用户一个存储在HDFS里的数据的“关系的”视图。虽然Polybase像Hadapt[2]，提供了和Hadoop组件无缝集成，但这两个系统的设计是完全不同的。hadapt使用MapReduce（至少在第1版），作为其执行并行查询的基础设施，并用它增加和Hadoop集群中的每一个节点相关的DBMS；另一方面，ploybase一开始，就是个全功能的并行数据库系统，其中包括一个并行查询优化器和执行引擎，为适度处理，当查询优化器决定是这样做有利的，就采用MapReduce的“辅助”查询引擎处理HDFS当时的数据。

本文的其余部分安排如下：第2节介绍相关工作。第3节提出Polybase的的架构与所有关键部件的详细描述。第4节包含三个不同的群集配置系统全面评估。在进行这些实验，我们发现，评估系统用拆分查询处理模式处理两种结果数据时的性能时，一些基准如TPC-H标准，不是很有用。因此，我们制定了新的基于拆分查询处理的评价方法处理。我们的结论记录在第5节。

2 相关工作

Sqoop[1] -----在大数据时代, ,这个Hadoop组件(可以把SQL转换成Hadoop),是Hadoop和关系型数据库转换的主要工具。sqoop有几个元件，其中包括命令行工具，它可用于关系表和HDFS之间的转换,用它可生成一个java类，这个类允许MapReduce 程序员和DBMS中数据交互，一个重要的实用是把RDBMS中的表迁移到Hive 数据仓库中。

Teradata和Asterdata-----Teradata努力提高Sqoop连接器的性能，此版本是Q版修改后开始使用的[6]，在其中插入输入流。假设，M(一个映射器),有临时表Ti,1<=i<=M,他们都在Teradata设备的每一节点的每个分区上。然后每个mapper附带的SQL查询扫描适当表的Ti,和标准的Sqoop连接器比较，对于大量的mappers，这种方法显然是更好的尺度。但这控制/应用的头结点仍然是一个瓶颈。有一个扩展，它允许Teradata设备里的节点和Hadoop集群描述的节点之间直接翻译[7]。

Teradata还提供了一个基于表的UDF方法，可以把HDFS的数据导入到Teradata设备中[8]。每个UDF实例，每一个节点，负责不同部分HDFS文件检索。UDF可以做数据滤波和变换，被UDF分割的数据记录交由随后的SQL处理。

Asterdata通过SQL-MR和SQL-H提供一些和Hadoop相关的扩展。SQL-MR允许用户对SQL表和分布式文件系统中的数据执行类似MapReduce的计算。通过高度集成HCatalog，SQL-H允许对分布式文件系统像对标准的关系表一样查询，就像Greenplum和Oracle提供的外部表机制。最后，Aster还提供了一个并行批量上传器，它在Aster的集群、及HDFS和Teradata上使用。

Greenplum ----------Greenplum通过把这些数据看成外部表的方式，提供SQL语句去查询、分析分布式文件系统中的数据。下面的例子可以解释：

CREATE EXTERNAL TABLE Expenses

(name text, date date, amountfloat4,

category text, desc1 text)

LOCATION

('gphdfs: //hdfshost1:8081/filename.txt')

FORMAT 'TEXT' (DELIMITER ',');

这个例子说明了三个要点：首先，它定义了存储在HDFS上的记录的字段，及和Greenplum 查询执行引擎观点相关形式。第二，通过LOCATION子句，存储实际数据文件的名称和Hadoop集群（包括的名字hdfshost-1和端口号：8081）信息一起，被详细记录。最后，FORMAT子句表明在HDFS中用逗号作为字段分隔符，将记录中每个字段存储为文本。除了文本，Greenplum还支持逗号分隔值和具有Greenplum原生序列化格式属性的记录文件。

Oracle--------------在Oracle DBMS和HDFS之间转移数据，Oracle提供了两种机制., OLH提供了从HDFS到Oracle数据库的批量加载数据器，为了提高负载性能，OLH 提供了MapReduce库，用于把存储在HDFS 文本里的记录转换成相应的Oracle二进制码。

Oracle还提供了一个外部表机制，可用于访问存储在HDFS中的数据，允许HDFS里的数据不必加载成文本就能访问。HDFS文件也可以通过OLH MapReduce工作，用Oracle二进制码格式创建。

IBM DB2 and Netezza[9]--------------IBM提供了多种用Hadoop和DB2、Netezza 连接的方式。Jaql(具有JSON数据模型和类似Pig-like的查询语言)为每个Map工作提供了拆分机制，去并行获取表中记录的不同子集，而这些表是分散在Netezza应用的各个节点上的。为了能够SQL查询访问HDFS数据，DB2提供了UDF表，名为HDFS记录。，它支持逗号分隔的文本文件和Avro文件格式，它用HTTP协议连接HDFS，并读取数据。这种方法也有其缺点，多个DB2节点不能并行读一个单一的文件。

Vertica ---- Vertica[10]，像Greenplum、Oracle、Aster一样，支持对HDFS文件的外部表的接口。

Hadapt----------Hadapt始于耶鲁大学的一个HadoopDB项目，它是第一个一开始就支持用类SQL语句查询结构化和非结构化数据集的系统，Hadapt用PostgreSQL DBMS在Hadoop集群的每个节点上部署了实例。关联表中的行哈希散列到所有PostgreSQL实例的节点上。HDFS是用来存储非结构化数据。

解析和优化后，查询被一种名为“拆分查询处理”的新查询处理机制编译成MapReduce序列。为了说明该方法，用一个简单的查询，有两个选项，其中一个连接两个表，一个是存储在PostgreSQL里的表，另一个是存储在HDFS的表。HDFS中的长存表选区将会翻译成Map工作并在Hadoop集群上执行，关系表将会翻译成SQL查询，被PostgreSQL实例并行执行。

评估Hadapt查询优化器，有两个选项，策略之一是加载从HDFS表到PostgreSQL实例区域中的结果记录行，还有正在运行的连接表。加载完成后，两个表的连接可以并行执行(来源于关系表的分区可能得先重新分区)。查询优化器评估的另一个选择是把关系表的分区结果导出到HDFS，后使用MapReduce的执行连接。这种测试最优与否，依赖于每个分区产生的行数，两种不同的连接算法的相对有效性，还有，更普遍的情况下，和后续的在查询计划操作和他们的输入有关。

3 PolyBase体系结构

虽然Hadapt和Polybase对结构化的关系表和非结构化的HDFS数据，都提供了可伸缩的“拆分查询处理”机制，但这两个项目采取完全不同的方法。Hadapt使用MapReduce作为并行查询处理的基础块，而Polybase则是用SQL Server PDW的功能，尤其是它基于开销的并行查询优化器和执行引擎。虽然使用的MapReduce提供了一定程度的PDW缺乏的查询级别的容错，但它受到根本限制，在执行关系操作符树时效率低下。最后，Hadapt在两个输入表中连接没分好区时，必须依赖HDFS重新分配/随机行；而PDW采用了基于流程的数据移动服务(DMS)，当向HDFS输入/输出数据时，清理计算节点的数据。

本节开始我们简要介绍了PDW架构，接下来，我们介绍Polybase是如何扩展PDW架构及如何拆分查询处理的。

3.1 SQL ServerPDW

PDW当前只作为一类独立的并行数据库销售. 正如图1中所示，它有一个管理多个计算节点的控制节点,控制节点为应用和查询要求提供外部接口。控制节点负责查询解析，优化，创建一个分布式执行计划，为计算节点发布计划步骤，跟踪计划的执行步骤，把最终结果集中的各个片段组成单个结果集，然后返回给用户。计算节点用于数据存储和查询处理。控制节点和计算节点各有一个SQL Server RDBMS实例，其中，控制节点上的SQL Server实例不仅用于元数据存储，还用于执行初始阶段查询的优化。在每个计算节点上，用户表散列或复制到每个SQL Server实例上。

图1：PDW系统架构

要执行一个查询时，运行在控制节点上的PDW引擎服务，把查询翻译成分布式执行计划（一种称为DSQL的计划），它由DSQL序列组成。PDW的查询优化，这些在第3.6节中详细描述。

3.2 Polybase使用案例

图二(a)和二（b）描述了我们要用到的Polybase的主要用例。案例（a）描述了这样的情况，Hadoop上的非结构化数据提交给PDW去执行。这可能像扫描输入的是HDFS文件，还是HDFS和PDW的结合体一样简单。在这种情况下，该输出流返回给用户或者提交查询的应用程序。图(b)除了查询的输出结果把（可能，也许不从HDFS获取数据）作为HDFS里的输出文件实现外，别的都相似。在HDFS里，这些可能由随后的PDW查询或者MapReduce工作去完成。在适当的时候，Polybase把HDFS里常驻数据操作翻译成MapReduce工作流，然后把这些工作流交由Hadoop执行，这样，可以使从HDFS读取数据最小化，而又能最大化使用Hadoop集群资源。我们设想，用Hadoop2.0支持处理多种连接技术，它涉及HDFS和的PDW常驻表，包括，例如，使用半联接技术等。

图2：基础Polybase使用案例

(a)PDW输入查询，输出结果 (b)PDW输入查询，输出结果到HDFS

3.3 Polybase环境需求

Polybase 在windows和 linux 部署的 hadoop 集群都支持，.PDW 与 Hadoop 集群可以重叠，也可以分离。支持所有标准的 HDFS 文件格式，包括文本、序列化文件、RCFiles。只要定义好对应的 Inputformat 和 outputFormat，所有定制文件格式也支持。

3.4外部表

像Greenplum，甲骨文，Asterdata和Vertica一样，Polybase对HDFS所存数据使用外部表机制。声明一个外部表的第一步是在该文件所在的Hadoop集群注册：

CREATE HADOOP_CLUSTERGSL_CLUSTER

WITH (namenode=‘hadoop-head’,namenode_port=9000, jobtracker=‘hadoop-head’,jobtracker_port=9010);

除了Hadoop名称节点指定的名称和端口外，Polybase还要求群集上的JobTracker的名和端口号被指定。后者在以MapReduce作业流的形式由Polybase查询优化器向Hadoop集群选中推入选区，预测，聚合等其他操作时使用。下一个步骤是注册HDFS文件的文件格式，如下图所示。

CREATE HADOOP_FILEFORMATTEXT_FORMAT WITH (INPUT_FORMAT=‘polybase.TextInputFormat

OUTPUT_FORMAT= ‘polybase.TextOutputFormat’,

ROW_DELIMITER='\n', COLUMN_DELIMITER = ‘|’);

这些输入、输出格式是指实现HDFS读写操作接口的类。在这种情况下，polybase文本输入格式是内部输入格式，它使用提供的参数解析文本文件，生产符合外部表架构的记录。在自定义文件格式的情况下，必须指定jar文件的位置，包括输入、输出格式。

最后，下面的例子可以声明外部表:

CREATE EXTERNAL TABLE hdfsCustomer

(c_custkey bigint not null,

c_name varchar(25)not null,

c_address varchar(40)notnull,

c_nationkey nteger not null,

c_phone char(15) not null,

c_acctbal decimal(15,2)not null,

c_mktsegment char(10)not null,

c_comment varchar(117) not null)

WITH (LOCATION='/tpch1gb/customer.tbl',

FORMAT_OPTIONS (EXTERNAL_CLUSTER= GSL_CLUSTER,

EXTERNAL_FILEFORMAT = TEXT_FORMAT));

位置中指定的路径可以是一个单一的文件或包含多个文件的目录组成的外部表。

3.5与HDFS间的通信

当我们着手Polybase项目时，设计必须支持Hadoop节点和PDW群集间转换数据，这点是关键目标。最初，我们探索添加PDW计算节点上的SQL Server实例的访问HDFS的能力，但最终意识到向DMS加入HDFS桥组件，采用了更清新的设计结构，如图3所示。DMS担当的角色，除在PDW计算节点上的SQL Server实例中重新分割表行，还在把这些记录加载到应用，变成适合SQL erver的ODBC类型的过程中，担当关键角色。当从部表从/到HDFS读/写数据时，这两种能力，被证明是非常有价值。

图3：PDW计算节点上的HDFSBridge实例

如图4所示，HDFS桥有两层。用Java编写的底层，向HDFS提供了一个简化的接口，隐藏了与Hadoop的数据节点、名称节点交互的复杂性，以向HDFS文件/目录读/写大量的字节。上面的一层桥只是简单地使用JNI包装了Java层，它向DMS其他组件和PDW引擎服务提供了管理C＃的接口。HDFS Bridge 使用和外部表相关的输入、输出格式，允许桥读写任意HDFS文件。

图4：HDFS Bridge 结构

当编译和存储在HDFS文件的外部表相关的SQL查询时，PDW引擎服务联合PDW集群上的大量DMS实例向Hadoop的Namenode询查文件信息。PDW集群，是用于计算输入文件的位置（偏移量和长度），每个DMS实例应该从HDFS中读取。这些消息以混合HDFS的DSQL（分布式SQL）计划传递给DMS，其中，还包括其他读取文件的信息，包括桥应该使用的文件路径，合适的名称节点的位置，RecordReader的名称等。

该系统尝试使每个DMS实例中读取的字节数尽量平衡。一旦DMS实例从名称节点获取拆分信息，每个节点都可以独立地读取所分配文件的部分，无需任何控制，直接和合适的数据节点通信。

一旦HDFS Bridge被DMS过程实例化，其OpenRecordReader()方法可以被调用，来创建RecordReader实例（如图5所示），OpenRecordReader()方法的参数包括：

．调用者提供的输入缓冲区的最大长度。

．输入文件的名称

．文件相对起始位置

．读取长度（读取文件的字节数）

．要读取的RecordReader的名称

．RecordReader参数（可选）

图5：HDFS Bridge和RecordReader实例

一旦RecordReader实例在HDFS Bridge内创建成功，它就能用RecordReaderRead()方法从HDFS文件（更精确的说，是从被创建的拆分的输入）读取记录，如图6所示。为了尽量减少副本的数量，调用者提供了缓冲区，留由Reader实例用文件里的记录填充。这个过程一直持续到整个文件被完全分割消耗。

这个阅读过程（技术上称为“ HDFS混淆“），是由八个HdfsReaderWorker线程，从HDFS文件，通过HDFS Bridge的RecordReaderRead()方法使用HDFSBufferReader类获得256KB的缓冲区的记录。当缓冲区接收到信息，把他们用round-robin fashion的方式分布在HDFSConverterQueues1/8中-----一个ReaderWorker线程。这样做将确保所有ReaderWorker线程可以保持同样繁忙，即使HdfsReaderWorker线程以不同的速率产生缓冲区。在PDW正常负荷情况下，当读取一个文本文件时，ReaderWorker线程任务繁重，就将每个到来的记录文本转换成相应的ODBC数据类型，然后应用哈希函数，确定每个记录的目标节点。在某些情况下，为了充分利用Hadoop集群更大的计算资源，MapReduce作业执行过程中，要提前进行类型转换。

图6：用HDFSBridge读取记录

写入数据，也很类似。调用者首先通过调用bridge 的OpenRecordWriter()创建RecordWriter实例，指定输出缓冲区的大小，它将与文件名一起使用。由于HDFS文件系统不支持并行写入到一个文件中，每个RecordWriter的实例将产生一个单独的输出文件（每一个有唯一的名字，但在相同的目录）。当Writer实例创建成功后，RecordWriterWrite()方法可用于一次性把记录写入到输出文件、一个缓冲区。

3.6查询优化和编译

涉及HDFS所存表的查询优化服从于PDW中其他查询的优化和编译[11]。第一步，运行在引擎服务节点的SQL Server实例，用于分析和优化查询。这一阶段的输出是一个替代串行计划的备注数据结构。下一阶段是并行的优化。一种典型的自底向上的Selinger-style优化器是必要时在串行计划中插入数据移动操作。例如，如果串行计划连接两个表，这既不是哈希分区加入属性，也不是每个输入表中引入的混淆操作。

由于Polybase是依赖于基于开销的查询优化器，什么时候向Hadoop集群，把HDFS所存数据推送SQL操作，获取HDFS外部表的详细统计信息是至关重要的。像PDW一样，Polybase支持表和列水平的统计。下面的例子演示了在hdfsCustomer外部表的c_custkey列如何使用CREATE STATISTICS命令，也提供了UPDATE和STATISTICS命令。

CREATESTATISTICS hdfsCustomerStats ON

hdfsCustomer(c_custkey);

这些数据用HDFS客户表里的记录的样本创建，它可能是单个HDFS文件或者是许多HDFS文件的目录。获得HDFS文件上的统计信息有两种方法。第一个是通过DMS过程或在Hadoop集群上执行Map-only工作获取块级样品，通过使用特殊的SamplingInputFormat，可以对HDFS里的任意格式的数据采样。得到的样本，导入到PDW，然后存储在计算节点上的SQL Server实例上临时表分区。在这点，每个计算节点用相同的机制计算其部分的柱状图，它将用于永久表。一旦每个分区直方图计算完成，他们共同使用PDW的现有机制，独立地计算直方图然后存储在数据库目录中。

我们考虑到了另一种方法，但是没有实施，它用MapReduce作业并行计算直方图。我们的想法是让Map任务从HDFS文件分割的记录读取样本，而不是把值返回到PDW，去计算直方图。每个Map任务去计算它所见的数据的部分直方图，reduce任务，然后结合部分直方图产生最终的直方图。

这两种方法都有其优缺点。第一种方法（不推直方图计算）是简单的实现，因为它重用现有PDW代码去计算，并行合并直方图。它也可以保证为运行在计算节点上算执行的SQL Server实例的所有SQL数据类型产生正确的结果。它的主要缺点是，它没有利用Hadoop集群的计算资源生成直方图，而且，如果不使用一个足够大的样品，直方图的质量可能是欠佳的。第二种方法（推直方图计算）避免这两个缺点，但将是难以实现，因为需要这将SQL Server的直方图运算机制移植到Java。

一旦优化计划已制定，然后翻译到一个分布式SQL（DSQL）执行计划，Polybase中，DSQL计划包括以下步骤：

．SQL操作 -------在一个或多个计算节点上的QL Server实例上，直接执行的SQL命令。

．DMS操作-------包括两个操作，一个是SQL Server实例之间行的混淆，另一个是HDFS Bridge命令，它从HDFS读/写数据。

．返回操作-------用来向客户端应用程序返回查询结果

．-Hadoop的操作------用于指定一个MapReduce作业,该作业由PDW引擎服务提交到Hadoop集群以便执行。

串行执行的查询计划，一次执行一步，然而，单步并行操作通常会涉及跨多个PDW计算节点或在Hadoop集群一个MapReduce作业并行执行。

举例如下：

SELECT count (*) from Customer

WHERE acctbal < 0

GROUP BY nationkey

设想客户是存储在HDFS中的外部表，图7描述了查询优化的第一阶段生成的两种可供选择的串行计划。

在优化的第二阶段，询优化器会在在图8（a）图9（a）详细说明图7所示的串行计划。图8（a）代表从HDFS先加载到PDW的客户表，然后可以正常执行查询。在另一方面，图9（a）对应的是MapReduce作业用来执行部分查询。

图7：两种可选的串行方案

虽然优化器实际上只选择这些方法中的一个去执行，但观察他们相应的DSQL方案（图8（b）和图9（b）所示），对弄明白这两类查询执行过程，是有用的。

图8：优化查询计划＃1与相应的DSQL计划

DSQL方案以在PDW创建临时表TEMP_1（该表将分散到PDW应用的各个节点上）开始。该方案中的第二步，HDFS Bridge把客户表从HDFS读到EMP_1。这个步骤有两个重要的点：首先，每个DMS实例处理Customer表的行，它仅保留acctbal和nationkey字段，第二，作为每个产生的行，DMS使用散列函数去确定nationkey路由到哪一行；反过来，向TEMP_1插入行。这允许SQL实例独立地执行该方案的第三步。

图9（B）的DSQL方案以Map-only 作业开始，用该过滤器acctbal<0，然后计算部分聚合，产生结果行，及表格（nationkey，PartialCount）留在HDFS目录，用于输入到第三步骤中的TEMP_1，该计划的最后一步对部分和求和，以产生最终的结果。

除了推选择，投影和部分集合体，Polybase的查询优化器也考虑推最终聚集group by子句，并且在某些情况下，加入基于开销的方式，除了外部表的统计，优化器也应该考虑其他因素，如两个群集的相对大小。

一旦DSQL查询方法产生，就交由PDW查询引擎去执行，当QE线程遇到Hadoop步骤,它向适当的JobTracker节点提交MapReduce作业，然后再执行下一步。

图9：优化查询计划＃2与相应的DSQL计划

3.7 Polybase中MapReduce连接的实现

在Polybase中，有两个方面通过MapReduce作业实现连接。一个是通过MapReduce范式本身。MapReduce作业更擅长处理单个输入，而加入二元运算符。第二个是选择执行自己加入哈希联接，排序合并算法，嵌套循环等，及所使用的参数。

Polybase中，所有连接采用分布式哈希联接算法（因此，只有相等联接作业）。选择较小的输入，作为哈希算子，这都是在HDFS完成的。无论如何，这种情况可能发生：是否算子是最终的物理移动操作数据运动的输出，否则，物化被迫的。加入本身就是做在同一个MapReduce作业（相同的阶段，map或者reduce）,因此，它经过创建，最终生成端物化。例如，该连接是MapReduce作业中Map阶段，每一个Map任务将评估联接的分区。当构建边落实，拆分成许多分区，相应的Map任务数在mapper初始化时开始连接，从HDFS读取相应的输入到哈希表。内存中的哈希表本身分割成一个小数目（4）子分区，如果所建的不适合内存，就一次性在磁盘的一个子分区建立行。在执行过程中的Map任务本身，被计算的头侧的行用于探测哈希表（如果有必要，散列到磁盘），实际上，该二进制联接操作通过隐藏map/reduce任务初始化阶段建立输入的消耗，转换为一元运算。哈希联接物理运算被封装在一个对象里，它保存着内存中的哈希表，处理元组的建立/拆分/再读，并返回结果集，如果有探针的话，也返回。该对象和优化器生成的代码相关，它在Map或Reduce阶段执行。

选中加入分区中的数目,确保存储在内存中,这是内建的基于基数估计的计算,每个Map/reduce任务都能分配到内存，而且在连接时，相同的map / reduce任务，操作所需的内存得到分配。需要注意的是优化也可能产生一项计划，即构建“复制”。也就是说，只有建立分区和所有的map / reduce执行连接，读取相同的输出。这和连接PDW类似，一张表被复制，其他的将在连接属性上，被哈希分区。

3.8实现语义兼容性

3.8.1介绍

执行关系运算符和预测Hadoop上的MapReduce任务中，有个重大的挑战是确保查询结果不发生变化。例如，无论方案采用哪种查询优化器，图8（b ）和9 （B ）应产生完全相同的结果。用户有一个合理的期望是，在所有查询执行的步骤中，保留SQL语言的语义。这是一个不平凡的任务，因为Java语言的语义在一些领域（包括类型，为空，表达的语义）和SQL语言不同。例如，考虑一个简单的表达，像“a+b”，如果操作数是NULL，SQL语义要求的结果是空的。Java中的表达式没有用这种方式去评估。两类系统的差别就添加了一系列的挑战。例如，在Java中没有类似与一些SQL类型如SQLVARIANT。因此，如果QO遇到一个谓词或类型，它在Java中不能正确处理，系统只需选择一个方案，用PDW计算节点执行查询的问题部分。用DMS类型转换机制使数据正确导入。

必须有三种操作符，为DSQL方法（该方案在Hadoop里执行），产生Java代码。

1. 标量表达式------用NET代码文档对象模型（CodeDOM）库建立模型。由于在C＃中的表达式语法和Java类似，CSharpCodeProvider类用于从CodeDOM树产生Java代码，当遇到表达语法不同或缺少一个表达式的类型，将调用CodeSnippets。

2. 关系运算符------关系运算符如过滤器和工程等的Java代码（上述方式生成）作为MapReduce 工作的一部分执行，对于更复杂的运算符，如部分或全部分组、聚合，字符串模板等用合适的代码产生该方法。

3. DMS或移动运算符------虽然不必为DMS运算符产生Java代码，但他们影响MapReduce工作的性能。例如，在Hadoop作业中，一个查询可能在Map和Reduce阶段之间随机完成。因此，当遇到一个随机移动，它调用一个Reduce阶段，以保持后续的查询在MapReduce中以Reduce阶段进行。像随机移动一样，分区移动（即从计算节点移动数据到PDW控制节点）也在Reduce阶段触发效率，这是Reduce工序中固有的约束（这是一个查询步骤在PDW中单个节点的模拟执行）。

在下面的章节中，我们提供了SQL语义的各方面的概述，当把SQL表达式翻译成Java时，SQL语义必须保存，在Polybase里也要如此。

3.8.2保留SQL语义 - 数据类型

当从实际方案树中产生Java代码，为却道SQL语义，找到SQL数据类型和Java类型之间的映射是有必要的。精确的SQL类型映射到精确的Java类型。在一般情况下，SQL类型有三类别：

1. Java原生态类型映射过来的类型----这些包括BIGINT(long),INT(int)等。常见的SQL像加法和减法是直接翻译成Java的表达，在Polybase中，我们使用这些类型的包装版本（长整型），这些代表空值。

2. 非Java原生态类型映射过来的类型----这些包括小数（BigDecimal）和日期（java.util.Date），Java类型经过映射，不在是原来的类型、方法，如compareTo方法，在Java解析是，不再是原始的操作符像<.。

3. 没有确切的映射类型----DATETIMEOFFSET是一个例子。

下面两种方式，没有确切的映射类型处

1,用Java实现的国定类型，如DATETIMEOFFSET，将Java代码生成时，这些类型才实现。

2,如SQLVARIANT和UNIQUEINDEN-TIFIER这样的变量，被标记为“Java中不支持”。用到的表达式或产生的类型总要在PDW里评估，即这些表达式将永不会翻译成MapReduce工作。请注意，这很简单，从SQL Server获得的MEMO数据结构，必须指定表达式和字表达式（必须经过评估）的类型。

Java中的排序规则, 通过使用（JNI）“sqlsort”DLL实现，PDW用它模拟SQL Server归类。同样，整理类型的操作不能正确的翻译成Java（Windows和Linux系统都不能），然后从HDFS中导入数据后，在PDW识别、执行。

3.8.3保存SQL语义 - 表达式

当把标量表达式移植到Java中，产生的Java表达式必须符合SQL以下三个方面：

1.根据上面定义的映射，所得到的表达式

2. 计算表达式的结果

3. 结果为空的（也就是说，如果一个SQL表达式的计算结果为NULL，则必须置为null。在Java中也是）。

通过创造生成的Java表达式的正确类型，来实现结果类型的通用性，使用MEMO（由SQLServer查询优化器产生）中包含的类型信息。
“NULL” 在Java中，本身具有不同的语义。Java的基本数据类型不能为空，表达式不能用空或ANSI语义赋值（实际上，这些会导致空指针异常）。因此，为保持正确的语义，我们在Polybase做了如下：

1我们使用原始类型（long, int, double）的封装版本（Long, Integer, Double），表示可为空BIGINT，INT和FLOAT类型。

2当翻译SQL表达式时，我们在必要的地方，产生“null-guarding”和“null propagation”代码，例如，表达式A+B，用SQL表示为：(a == null || b == null) ? null:(a + b).

虽然一些SQL表达式直接对应与Java（此外，等），其他的（例如LIKE）表达式可能需要Java定制实现，然后在生成的代码中调用。

SQL表达式不能在Java中赋值（如系统函数），总是在PDW部分赋值。

3.8.4错误处理

在Hadoop执行DSQL步骤时,可能发生多种错误, 如输入数据解析错误，算术溢出，或转换错误等等。在一定程度上，当在SQL Server执行查询产生错误，也就会在MapReduce里产生错误（这不是一个类别的要求，如算术溢出错误，这可能本质上依赖于选择执行路径）。在所有情况下，Hadoop发生的错误，通过PDW接口，反馈给用户。

3.8.5数据转换

在Polybase中，DMS用于把数据从HDFS中导入到PDW。DMS把ODBC数据类型作为其基础。通过使用输入格式（把一系列的Java类型转为具体的ODBC对象）数据转换是MapReduce工作的第一步（或在将数据读入DMS作业中）。这是可取的----DMS混淆操作是CPU密集型的，于是在（通常）更大的Hadoop集群，数据输入速度更大，降低查询的总执行时间。

3.8.6总结

在Java中，为了保持正确的SQL语义，先找出这些SQL结构（可以正确地翻译成Java）是必要的。不能翻译的结构，将被标注，在PDW中赋值。能翻译成Java代码的结构包括：

1．可以映射到现有的Java类型的SQL类型，或那些可以实现的Java类型，如数字和字符类型，以及大多数的日期/时间类型。

2.使用sqlsort DLL实现的字符串比较。

3. 关系运算符，包括投影，过滤，聚合（局部和全局），等值连接，和取最前元素。

4. 基本标量表达式，某些系统功能除外。

4性能分析

4.1目标

起初，我们打算像评估HadoopDB一样去评估Polybase中的拆分查询处理，但最终我们的目标和他们是不同的：具体来说，他们的目标是用Hive和商业化关系数据库管理系统及TPC-H基准测试去比较HadoopDB性能。由于我们的目标是深刻理解拆分查询处理的优势，我们总结为：我们需要一个不同的不同的评估方法，我们开始着手设计一个更合适的基准。

我们的基准目标包括：

1.优势表现有：像在Hadoop上执行MapReduce工作一样，在HDFS里的外部表执行QL操作，而不总是每次都加载那些外部表到数据库应用中，他们被一个查询引用（像Greenplum，Oracle，DB2那样）。

2.当操作运算导入到Hadoop集群时，需要做个基于开销的决策。

3.最好方案（指定表的大小和位置（HDFS或关系的）的查询）的灵敏性，任何引用的选择性因素，和在这两个群集的相对大小，及不管他们是否相邻。

我们很快得出结论，TPC-H基准测试不适合我们的目标。首先，查询的复杂性，加剧了翻译所得结果的复杂化。第二，那么多的查询表，决定哪些应该存入HDFS，及哪个表在PDW是最优的。鉴于我们想要探究我们从不同的集群大小和配置上获得的结果的精度，我们需要一个更简单的基准。

4.2硬件和软件配置

我们在实验中，用65个节点的集群。每个节点都有运行着2.13 GHz的四核处理器的双Intel Xeon L5630，32GB的主内存和10300 GB SAS磁盘驱动器（10KRPM）。8个数据驱动（HDFS文件和/或SQL Server中永久或临时表）。一个是用于空间交换，一个是用于系统运行，65
节点遍布6个机架。一个机架内，节点连接使用1 Gb /秒。通过Cisco2350交换机连接以太网，这些交换机机架之间以10 Gb/秒的速率通信。

在每个节点，WindowsServer 2012被用作裸机操作系统，PDW和Hadoop服务在单一的Windows Hypervisor的虚拟机上运作。虚拟机上的配置为：28GB RAM，SQL Server 2008, PDW V1原型版本上拓展的Polybase软件，和Windows版本的Hadoop1.0.3，为PDW和Hadoop服务预留了20 GB的内存。

对于我们的实验中，我们使用了三个群集配置：

C-16/48：一个16个节点的的PDW集群和48个节点的Hadoop集群。

C-30/30：30节点的PDW集群和30个节点的Hadoop集群。

C-60：此配置，在同一节点上，一个60节点的PDW集群和60节点的Hadoop集群，0GB内存被分配到PDW和10GB的Hadoop任务。

对于上述每种配置的一个附加节点，用于引导PDW引擎的服务流程，像Hadoop的Namenode和JobTracker的守护进程。我们本来打算使用合设64个节点的配置作为我们的第三个配置（不是C-60），但发现Windows Server 2012里的默认2PC软件被限制为最多64个节点。由于PDW软件要求在单个节点的引擎服务进程，用于计算节点，一个C-64配置（实际上需要65个节点），是不可能的。于我们的意图是挑选这三个配置，探究拆分查询处理在不同的配置上的查询效果（而不是主要比较它们的相对表现），我们得出结论，这三个配置在大小上足够接近。

重要的是要记住，下面展示的结果不能反映客户想看到的性能。首先，PDW应用的节点被配置过多的内存（256 GB），更多的磁盘驱动器（24），和SQL Server2012。此外，它们在以太网上，以40 Gb /秒速度通信的，不是1 Gb /秒。此外，虽然有初步计划让客户在Hadoop和PDW区域不相交处分区，目前还没有方法准确地在SQL Server实例和Hadoop数据节点重新定位，尽管我们已经做了与C-60配置。

4.3测试数据库

为了测试，我们使用了一个Wisconsin基准稍作修改的测试表。

CREATE TABLET

(

unique1 bigint, unique2 bigint, twotinyint,

four tinyint, ten tinyint, twenty tinyint,

onePercent tinyint, tenPercent tinyint,

twentyPercent tinyint, fiftyPercenttinyint,

unique3 bigint, evenOnePercent tinyint,

oddOnePercent tinyint, stringu1 char(52),

stringu2 char(52), string4 char(52)

)

我们用这个模式产生四个表，每个表都有500亿行（未压缩约10TB）。两个副本，T1-PDWT1和T2-PDW，和其他两个副本（T1-HDFS和T2-HDFS存储压缩），被加载到PDW。对于PDW中的表，启用页级压缩，每个表压缩后的大小，在HDFS是1-2TB，在PDW中是1-3TB。

虽然大多数字段的语义应该是明确的，理解unique1值也是唯一、随机序列、unique1用于计算所有其他行(除了unique2)，这点很重要。unique2值是唯一的，但被顺序分配到各行（即1, 2, 3, …, 50*10）。

4.4测试查询

虽然一开始，我们提供了更加丰富的查询，结果表明真正需要的只有三个基本的查询模板。

查询1：在T1表上选择

SELECT TOP 10 unique1, unique2, unique3,stringu1,

stringu2, string4 FROM T1

WHERE (unique1 % 100) < T1-SF

查询2:：“独立报”连接T1和T2

SELECT TOP 10 T1.unique1, T1.unique2,T2.unique3,

T2.stringu1, T2.stringu2

FROM T1 INNER JOIN T2 ON (T1.unique1 =T2.unique2)

WHERE T1.onePercent < T1-SF AND

T2.onePercent < T2-SF

ORDER BY T1.unique2

查询3：“相关”连接T1和T2

SELECT TOP 10 T1.unique1, T1.unique2, T2.unique3,

T2.stringu1, T2.stringu2

FROM T1 INNER JOIN T2 ON (T1.unique1 = T2.unique1)

WHERE T1.onePercent < T1-SF and

T2.onePercent< T2-SF

ORDER BY T1.unique2

查询2和查询3之间的差异是很微妙的。在查询2中，选择语义Join接语义是相互独立的，而且查询的选择性输出会是T1-SF：T2-SF。例如，两个选择语义的相关因素是10%的话，则查询的选择性输出是1%.。对于查询3，选择语义和Join接语义不是相互独立的，而且查询的选择性输出和T1-SF、T2-SF中最小的相对。这三个基本的查询，通过改变选择语义的可选因素和T1、T2的位置（PDW或者HDFS）可用来创造各种不同的查询。意识到构造这些查询（在PDW中赋值），也是很重要的，PDW - 它只是担任限制返回到客户端的数据量。

4.5查询1

图10，图11，图12，展示了在HDFS中，分别配置了C-16/48 C-30/30，C-60，选择性因素T1-SF从1%变化到100%情况下，用T1执行查询的时间。标有“S”的柱状图，对应这样的查询方案：选择术语在Hadoop集群上的Map-only工作中执行。，标有“N”的柱状图，对应这样的查询方案：查询作为正常的PDW查询，执行后，加载到临时的PDW表，以这种方式开始。每个柱状图的绿色部分表示PDW计算节点在查询处理上所花的时间，红色表示把数据从HDFS导入到PDW花费的时间，蓝色部分表示当使用拆分查询处理时，执行Map job所花费的时间。

对于C-16/48，当选择性因子小于90％时，把选择术语导入到Hadoop的速度总是很快，不亚于在5X -10X中的较低的选择性因子。由于术语变得可选性变小，Map-only job将结果元组数越来越少返回到HDFS。反过来，导入PDW，从而导致增加整体查询的执行时间。因此，全选参数后，选中一个拆分查询方案，将读取HDFS文件两次，写入一次。C-30/30配置和C-60配置的结果稍有不同。首先，两个查询处理策略之间的跨接点下降到一个约70％的选择性因子。其次，这两种配置明显更快，用C-60比C-16/48块2-3倍。有几个因素，首先，C-30/30 C-60分别都以高于DMS和SQL Server 实例的2倍，4倍地速率显著增加，这些数据可以从HDFS获取，可以从PDW计算节点产生。比如，对于C-16/48和C-30/30配置，选择性因子为80％时，对查询的响应时间进行比较，Hadoop部分的查询在C-16/48事实上更快，这是意料之中的，因为它比C-30/30有更多的Hadoop节点。然而，由于有更多的PDW节点，工作的输入部分比较快，C-30/30整体执行时间还是比较低的。这也解释了为什么交叉点C-30/30小于C-16/48---- Map jobs花费时间长，输入快，查询的'N'版本，在查询相对较低的选择性变得有竞争力。另外，在所有情况下，PDW部的查询所花费的时间和导入时间相比，是比较小的。最后，请注意，对于给定查询，不管是Hadoop集群的还是PDW集群在任何给定的时间内都是活跃的。因此，C-60的配置中的速度比C-30/30配置要快，因为所有的群集计算资源为查询的每个阶段工作。尽管如此，超过一点是相同的，因为这两种配置相对PDW和Hadoop之间的资源分配，是相同的。

这些结果清楚地表明两点。首先，拆分查询处理可以大大减少查询储在HDFS中相关数据的执行时间，其次，是否把操作符导入到Hadoop，必须要基于开销的优化器决定。除了外部表的全面数据，为了产出高质量的方案，查询优化器既需要一个准确的成本模型执行MapReduce jobs，又需要关于这两个集群的相对大小，硬件配置等信息。不管他们是共同的还是单独的，如果不位于同一位置，其带宽为两个集群之间的通信链路。

图10：查询一，在HDFS中使用C-16/48，通过T1查询

图11：查询一，在HDFS中使用C-30/30，通过T1查询

图12：查询一，在HDFS中使用C-60，通过T1查询

4.6查询2

在本节中,我们展示查询2的四个变型产生的结果，如下图13所示。对于Q2-A，T1在PDW中、T2在HDFS中，采用拆分查询处理的好处是对T2的选择赋值。对于Q2-B，Q2-c，Q2-d,T1和T2都在HDFS中。Q2-B在选择和连接查询时，都不使用拆分查询处理。Q2-C在T1和T2的选择上，采用拆分查询处理，但连接上没有。Q2-D使用它的所有操作符，伯氨喹连接操作符。

图13：四种查询2的变形

用查询一，我们评估三个群集配置的各个变形。当我们把选择性属性从1%改变到100%，由于空间限制，我们只展示了当T1的选择性因子等于30％的结果。其他选择性因素的结果是类似的。对于查询2中的每个变形，结果的选择性因素和这两个选择属性的产生的可选因素是相等的。

图14：查询2-（T1在PDW，T2在HDFS）C-16/48 T1-SF固定为30％

图15：查询2-（T1在PDW，T2在HDFS）C-30/30 T1-SF固定为30％

图16：查询2-（T1在PDW，T2在HDFS）C-60 T1-SF固定为30％

图14,15,16，展示了我们的结果。对于查询1，他们的结果非常相似，就交叉点来说，无论是基于拆分的查询处理，还是这三种配置的相对表现，速度不再那么快。

图17，图18，和19包含了查询2（b,c和d）三种变形，其中，T1和T2都在HDFS中。对于全部这三个群集配置，在T1和T2上加载选项，由于Map jobs (Q2-c)和Q2-b（它没有采用拆分查询处理，使用了C-16/48配置）比较，显著减少查询执行时间。另一方面，添加连接作为MapReduce job (Q2-d)，和Q2-c（ C-16/48配置）相比，提高了查询执行效率，不过效果不明显。对于使用Hadoop节点连接的其他两种配置，在较高的选择性的因素上，显然是非常糟糕的选择。

为了帮助理解这些结果，鉴于Q2-C的执行，其中只推入两种选项。两个选项生成的中间表都存在HDFS中（W / O复制）。由于文件中的这些行被PDW读入，DMS把连接属性用哈希函数（T1.unique1或T2.unique1）应用到计算节点的流，它存储在SQL Server的临时表中。一旦双方的中间表被读取，PDW计算节点可以并行执行连接，而无需移动任何数据。

把这个和Q2-d所发生的情况对比(见第3.7节连接算法的详细说明)。首先，map任务在T1部分执行选择，符合条件的行加入到一组当地文件（每个连接任务都通过哈希算法，在连接属性上操作，然后，相应的当地文件），结合成单个HDFS文件，用作连接的输入。T2产生一系列HDFS文件（连接任务用它作为输入探针）的过程中，该过程重复进行。随着选择性因素的增加，在连接之前多次读写每行的开销，对所有查询执行时间来说，变成显著的因素。通过比较Q2-D和Q2-C相应的执行时间，如图18和图19的柱状图所示，清晰地表明了这点。最后，对于C-30/30和C-60，PDW中的连接本身就比Hadoop快5倍左右。

还要注意的是，和C-16/48配置（图17）相比，在C-60配置（图19）中，尽管有更多的12个Hadoop节点，MR连接时间也相当长。原因在于和C-16/48相比，C-60为Hadoop Map任务分配了少很多的总内存，因为在C-60配置中，PDW和Hadoop共享内存。只有少量的可用内存，要执行多个连接或连接算法本身必须拆分成更多的行。MR连接次数和C-30/30、C-60配置相比，是差不多的，因为这些配置对Hadoop Map任务分配的总内存也是相等的。

这些结果证实了早期的研究发现。首先，对于执行关系运算符（它有两个输入，如连接高度优化的关系数据库系统，使执行更“复杂”的操作更有效，如连接），MR框架是不是一个很好的环境。其次，为导入数据去连接或聚合，使用文件系统作为传输机制，要逊色于基于网络的传输机制，如DMS，只需一次传输数据。不管数据是如何分区和在MapReduce中装入的（或是Map和Reduce阶段的立即混淆，或者是在HDFS中通过不同的工作），它仍然保持正确。虽然Hadoop2.0（YARN）通过为Hadoop建立关系查询引擎，允许我们减少这些缺陷带来的影响，不管有没有可能，我们应充分利用现有的数据库技术。

图17：查询 Q2-b,c,和d(T1和T2都在HDFS中)C-16/48. T1-SF固定为30％

图18：查询 Q2-b,c,和d(T1和T2都在HDFS中)C-30/30. T1-SF固定为30％

图19：查询 Q2-b,c,和d(T1和T2都在HDFS中)C-60. T1-SF固定为30％

4.7查询3

在本节中，我们在图20—图22探讨了Q3的两种变形的不同表现。在这些变形中，T1和T2都存储在HDFS。Q3-A对T1和T2的选项只采用了拆分查询处理，而Q3-B在对连接时采用了拆分查询处理。对于Q3，选项和连接不上独立的，查询的输出可选性和T1-SF, T2-SF最小值相等。因此，当T1-SF固定为30％时，连接的输出SF等于1%；当T2-SF的值分别为33％，66％和100％的时。

对于查询2，只有在C-6/48配置的情况下，把连接和选项推入Hadoop，只改变选项，是有利的，而且它只能达到边界程度。要观察的另一个有趣的点是这三种配置的相对表现。当T2-SF固定为33%，配置为C-30/30的Q3-b比配置为C-16/48的慢约50%，比配置为C-60的慢约25%，因为为查询提供的Hadoop集群中的节点数目下降了。再次，Hadoop和PDW节点协同工作在一定程度上保证了最佳的整体响应时间。在不久的将来，我们计划探讨当有多个查询并发执行时，协同工作是否继续提供最佳的平均响应时间。

图20：查询Q3-a和Q3-b（T1和T2都在HDFS中）C-16/48. T1-SF固定为30％

图21：查询Q3-a和Q3-b（T1和T2都在HDFS中）C-30/30. T1-SF固定为30％

图22：查询Q3-a和Q3-b（T1和T2都在HDFS中）C-60. T1-SF固定为30％

5总结

本文介绍了SQL Server PDW的第二版的一个新特性----Polybase，像Hadapt一样，采用了拆分查询处理模式执行查询工作，可以处理HDFS里的非结构化数据和PDW应用中节点里的结构化数据。除了提供一个外部表机制，通过标准的T-SQL语言接口，访问HDFS中的数据，Polybase还能利用Hadoop集群的资源执行选项，预测、聚合、确定外部表（MapReduce工作自动生成的）的连接。

我们的评估的结果清楚地表明，通过把SQL操作推入Hadoop集群作为MapReduce工作，而不是把HDFS数据导入到PDW计算节点处理，这样可以获得显着的好处。然而，获得的好处对一系列的因素敏感，包括操作符的选择性因素，Hadoop和PDW计算集群的相对大小，以及这两个集群是独立的，还是一体的。我们也怀疑（但无法核实），任何给定查询的可选方案，当他们不是一体时，也依赖于两个集群之间的网络链路的可用带宽。显然，对于任何系统，基于开销的查询优化器采用拆分查询处理模式，将需要考虑这些因素，决定什么样的操作应该推入到Hadoop去执行。

6参考

[1] http://sqoop.apache.org

[2] Bajda-Pawlikowski, et. al., “Efficient Processing of Data Warehousing Queries

In a Split Execution Environment,”Proceedings of the 2011 SIGMOD

Conference, June 2011.

[3] http://www.oracle.com/technetwork/bdc/hado

op-loader/connectors-hdfs-wp-1674035.pdf

[4] http://www.greenplum.com/sites/default/files/

EMC_Greenplum_Hadoop_DB_TB_0.pdf

[5] http://www.asterdata.com/sqlh/

[6] Yu Xu, et.al., Integrating Hadoop and ParallelDBMS, Proceedings of the 2010 SIGMOD Conference, June 2010.

[7] Yu Xu,et.al., A Hadoop Based Distributed Loading Approach to Parallel Data Warehouses", Proceedings of the 2011 SIGMOD Conference, June,2011.