CN102799622B - 基于MapReduce扩展框架的分布式SQL查询方法 - Google Patents

Abstract

本发明涉及基于MapReduce扩展框架的分布式SQL查询方法，1）客户端发送查询请求到查询服务器模块QueryServer，所述查询服务器模块包括：SQL查询接口、SLQ解析模块和动态选择模块；2）所述SQL查询接口接收到查询请求，将所述请求发送到SQL解析模块，所述解析模块解析得到查询请求的语义；3）所述动态选择模块根据查询代价模型Cost Model和语义规则对该查询语义进行计算，预测出查询结果需要的存储空间，并选择MapReduce查询方式或内存查询方式；4）当查询结束，将本地查询结果上传至HDFS或数据处理服务器模块Data Processor。本发明基于内存的拓展框架，利用内存处理的方式处理SQL查询，在内存中完成数据处理，提高查询的效率。同时查询服务器模块实现与客户端的交互和查询处理方式的动态选择。

Description

基于MapReduce扩展框架的分布式SQL查询方法

技术领域

本发明涉及一种在分布式计算的环境下进行SQL查询的方法，特别涉及一种利用MapReduce和内存处理结合的方式处理SQL查询的框架，属于信息技术领域。

背景技术

随着互联网技术和相关行业的发展，计算机行业面临着指数增长的海量数据和更多的数据处理需求。面对这种状况，一些新技术快速发展，包括并行数据库、分布式处理等。

MapReduce是一个处理海量数据的计算框架，非常适合分布式的计算系统。Hadoop是一个由Apache基金会开发的基于MapReduce框架的分布式数据处理系统，有计算能力强、容错性和数据可用性强、可扩展性强等特性。然而，这种传统的MapReduce框架和Hadoop系统也有以下缺点：

1、擅长处理批量处理的问题和非结构化的数据，不擅长处理结构化数据的处理。

2、由于其高可扩展性，对于特定问题的处理需要用户进一步编程解决。不存在针对某种问题的特定接口。

3、由于其分布式的特点，存在着启动时间长、负载不均衡、数据吞吐量大等相关问题，进一步导致处理延时较高，不能支持一些实时的查询。

针对以上问题，已经有了多种对MapReduce框架的优化和补充，使得MapReduce适用于迭代的计算模型、结构化的数据处理、SQL查询等特定应用。其中，由于SQL查询是数据库领域的重要应用，且其处理能力强大，有大量的研究和分布式环境下的SQL查询相关。Hive和Google Dremel是两个比较成功的系统。

Hive是一个建立在Hadoop上的数据仓库系统，具有数据管理、数据查询等功能。Hive定义了一个类似于SQL的查询语言——HiveQL，支持SQL可以实现的绝大多数查询，并且查询接口简单。Hive利用Hadoop的Hadoop文件系统（HadoopFile System,HDFS）存储数据，利用Hadoop的MapReduce模块进行数据处理的工作，并且有很强的数据容错性和数据恢复能力。总体来看，Hive基本支持绝大多数分布式数据库的功能，并且有更好的扩展性和规模性。然而，由于Hive的数据处理的功能仍然建立在Hadoop上，它仍然存在一些Hadoop系统的缺点，比如处理延时较高的问题。下面通过简单分析Hive和Hadoop系统来说明这个问题。

Hive的体系结构如图1。在Hive部分中，CLI、Web GUI和JDBC/ODBC模块都是向用户提供的结构，用户通过接口提供查询。Thrift Server是提供跨语言开发的服务器模块，用来支持JDBC/ODBC。MetaStore模块是用来保存数据的元数据的服务器模块，Hive是用MySQL实现的，通过MetaStore可以高效地支持对数据的管理和查询。Driver部分是Hive的核心，它包含编译、优化、执行查询三个模块，功能是将用户发出的查询语句进行转化和优化，生成MapReduce程序并将其发送给Hadoop执行。在Hive中，查询的执行交给Hadoop来完成。Driver生成的MapReduce任务将被提交给Hadoop的JobTracker，JobTracker负责建立任务、跟踪任务运行状态并将任务结果返还给Hive的Driver。Hive提交的MapReduce任务的执行和普通的Hadoop的MapReduce任务的执行基本相同。

从上面对Hive框架的分析可以看出，Hive处理了上面提到的两个问题。一方面在Hadoop的基础上提供了一些针对SQL的特定接口，使得用户可以方便地使用MapReduce框架进行SQL查询；另一方面也针对MapReduce和SQL进行了优化，通过使用MetaStore和查询优化的模块对查询任务进行优化，使得MapReduce模型可以对结构化的数据进行处理。然而，由于Hive的查询任务仍然是交给Hadoop系统完成，因而没有解决Hadoop系统延迟较高的缺陷。

图2是Hadoop系统的MapReduce框架。MapReduce任务执行的一般流程是：

1、Mapper任务从HDFS上读取数据块（split）。

2、每个Mapper任务调用map函数，对每一个数据块进行处理，处理的结果写入缓存或者磁盘。

3、Mapper执行完之后，数据在本地进行排序和合并（有可能经过本地的combine）。

4、经过Shuffle阶段，每个节点把本地数据发送给对应的Reducer所在的节点。

5、在Reducer本地进行排序和合并。

6、Reducer处理本地的数据，并将结果写入HDFS。

从上面的执行流程来看，Map和Reduce阶段中有大量的本地I/O操作，以及一些不必要的排序。以上这些流程都不是MapReduce框架必须的，而是Hadoop为了保证数据的高可用性和良好的扩展性而实现的。然而，这些操作也导致了Hadoop系统执行MapReduce任务延时较高，无法支持实时的查询。如果想要在这一点上有所改进，必须要对Hadoop系统的体系结构进行修改。

Dremel是Google开发的供内部员工使用的分布式数据查询与分析系统。根据Google的论文Dremel:InteractiveAnalysis ofWebScale Datasets.，这种系统适用于一些聚集操作的查询，查询处理的速度较快，可以用于一些实时的应用。Dremel的体系结构如图3所示。进行查询的流程如下：

1、客户端发起查询，root server接收并解析查询语句。

2、root server将查询语句分解成子查询语句，将查询发送给中间节点（intermediateserver）执行查询。例如，对于查询语句：SELECT A，COUNT(B)FROM T GROUP BY A，将被分解为新的查询语句：和一些子查询语句：再将这些子查询语句发送给中间节点。

3、中间节点执行子查询，将本地的查询结果发送给root server。

4、root server在本地执行合并结果的操作，输出结果。

Dremel的查询流程，已经脱离了普通的MapReduce框架。由于使用了这种特定的框架，加上一些针对聚集查询的优化，Dremel对针对聚集的查询效率很高。然而，Dremel的这种特定框架使得它不能处理其他的问题，甚至连其他一些SQL查询都无法处理（比如，无法处理SQL中的连接查询）。因此，可以考虑一种更加通用的高效的分布式SQL执行框架。

发明内容

本发明的目的是提供一种分布式的SQL查询处理框架，使得这种框架能够适用于分布式的系统，同时提供类似于Hive的强大的查询能力和类似Dremel的高效的处理速度。

为了适应分布式的系统，本发明建立在Hadoop的MapReduce框架的基础上，并对框架进行修改，使得其在不失去扩展性的前提下增强对SQL查询的扩展能力。本发明了提出一种基于MapReduce扩展框架的分布式SQL查询方法，其步骤为：

1）客户端发送查询请求到查询服务器模块QueryServer，所述查询服务器模块包括：SQL查询接口、SLQ解析模块和动态选择模块；

2）所述SQL查询接口接收到查询请求，将所述请求发送到SQL解析模块，所述解析模块解析得到查询请求的语义；

3）所述动态选择模块根据查询代价模型Cost Model和语义规则对该查询语义进行计算，预测出查询结果需要的存储空间，并选择使用MapReduce查询方式或内存查询方式；

3-1）查询方式为MapReduce查询时，Job Tracker启动执行Map操作和Reduce操作；

3-2）当查询方式为内存查询时，Job Tracker启动Map操作，并将查询数据保存至本地服务器的内存表中；

4）当查询结束，将本地查询结果上传至HDFS或数据处理服务器模块Data Processor。

所述扩展框架基于内存表构架，建立由查询服务器模块启动并管理的数据处理服务器模块，所述数据处理服务模块用于内存查询方式中与每一个map任务连接，收集map任务查询结果并进行处理和输出。

Map操作和数据处理服务器模块Data Processor使用Hadoop RPC接口连接，通过设置传输阈值控制每次传输的数据块大小。

所述SQL查询接口面向用户提供接口通过socket实现，用于接收和返回客户端查询请求。

所述SQL解析模块通过antlr工具实现,所述antlr根据用户提供的语法文件，生成对应的语法分析器。

更进一步，所述SQL解析模块解析得到查询请求的语义，形成语法树；所述语法树是以SQL查询中符号和操作符为节点的树。

更进一步，遍历所述语法树，并根据元组数据Meta Data的信息，得到查询语义。

更进一步，所述建立查询代价模型相关参数信息根据元组数据Meta Data、查询语句本身或者查询的历史记录中取得包括：表的模式信息、表中每列的平均数据大小、表中记录的数量、表中每一列的数据分布情况、查询条件。

更进一步，所述语义规则的动态选择方法根据查询的种类、表的数据量信息来判断查询的执行方式。

更进一步，在内存查询时可通过MapScan扫描方法对数据进行查询，将结果直接输入到内存表中。

本发明的有益效果：

1、给定SQL查询语言，针对某些操作符号，如空间相对较小的选择查询、聚集查询，引入了一种内存表的方法。内存表在QueryServer中，能够接受来自不同分布式计算节点的计算结果。

2、本发明引入了一种Map Scan的扫描方法，利用这种分布式操作，将结果直接输入到内存表。

3、本发明的SQL优化模块能够根据已有信息，选择合适的执行方式，包括Hadoop的MapReduce方式，直接文件操作方式，内存表方式。

综上所述，本发明首先提出了利用内存处理的方式处理SQL查询的方法。通过Map任务和数据处理器的连接，在内存中完成数据处理的过程，极大提高查询的效率。其次，本发明利用查询服务器模块来实现与客户端的交互和查询处理方式的动态选择。查询服务器模块提供两种查询执行的方式：利用MapReduce执行的方式和利用内存执行的方式。通过这种动态选择，能够提高查询的效率，同时保持MapReduce框架和Hadoop系统的扩展性和数据可用性。

附图说明

图1是现有技术中Hive的系统流程图。

图2是现有技术中Hadoop的MapReduce的系统架构图。

图3是现有技术中Dremel的系统架构图。

图4为本发明基于MapReduce扩展框架的分布式SQL查询方法系统架构图。

图5为本发明基于MapReduce扩展框架的分布式SQL查询方法流程图。

具体实施方式

下面详细说明本发明的实现步骤和具体方法。

本发明的实现是基于Hadoop的，主要实现内容包括在Hadoop外层包装了SQL查询的接口和SQL解析、优化的工具，以及对传统的MapReduce任务框架的修改和动态选择。下面首先给出整个分布式SQL查询框架的结构图，说明整个工作流程和主要模块的任务，最后分别描述每个模块的具体实现。

本发明的系统架构如图4所示。由于本发明的最终目的是构建一个基于MapReduce思想的SQL查询框架，因此系统架构图中一方面包含和Hive类似的SQL查询处理、优化的模块，包括查询服务器模块（Query Server）、元数据管理（Meta Data）和查询客户端（Client），另一方面也包含基于Hadoop的传统的MapReduce框架，包含Job Tracker、Map Task、ReduceTask，以及对MapReduce框架的修改部分，即修改过的Map Task和数据处理服务器模块（DataProcessor）。此处用一个例子来描述整个系统的流程。

以查询SELECT A，COUNT(B)FROM T GROUP BY A为例。当用户从客户端提交查询时，查询服务器模块（Query Server）首先接受这个查询，然后调用解析工具，将查询解析成语法树，再做进一步分析。

当语法树生成之后，查询服务器模块将调用元数据，预测查询的存储代价。查询服务器模块将根据元数据中保存的表T的信息，包括T的总的记录的数量和占用空间、T表中A列数据的分布情况等信息，建立一个代价模型，并根据这个代价模型预估查询结果需要的内存空间。

根据预测的查询的存储代价，查询服务器模块将选择一个执行方式。对于存储代价较大的查询，例如，如果上例中T表的A列是一个长文本，平均有1KB大小，而总的记录数量预测有几千万条，那么这样的查询将被认为是一个复杂查询，只能交给传统的MapReduce框架去完成。相反，对于一般的查询，存储代价不大，查询服务器模块将选择内存的执行方式。

确定执行方式之后，查询服务器模块将建立MapReduce任务，并根据查询的语句和选择的执行方式为MapReduce任务设定参数。对于内存的执行方式，查询服务器模块还将建立一个数据处理服务器模块（Data Processor），用于收集保存在内存中的中间结果。之后，查询服务器模块将把任务提交给Hadoop的JobTracker。

JobTracker接受任务之后，将启动对应的Map任务。对于MapReduce的执行方式，JobTracker还将启动Reduce任务；对于内存的执行方式，JobTracker不会启动Reduce任务。Map任务获得的中间结果将暂时地保存在内存中，并由数据处理服务器模块收集之后进行进一步处理并输出。

最后，查询服务器模块将收集数据处理服务器模块中保存的结果，或者从HDFS上收集Reduce输出的结果，返回给客户端。

以上就是基于MapReduce和内存处理的SQL查询框架。下面进一步描述各个模块的具体设计和实现。

1、查询服务器模块模块（QueryServer模块）

QueryServer模块是本发明的核心模块。它提供的功能包括SQL查询接口、SQL解析和优化、执行方式的动态选择。

SQL查询接口是QueryServer向外部提供的接口。本发明使用socket实现了这一接口。用户只需要通过客户端提交查询语句，客户端会利用socket将查询语句发送给QueryServer。另一方面，当查询处理结束时，查询接口将从数据处理服务器模块和HDFS上收集查询的结果，同样通过Socket的方式发送给客户端。

SQL解析的模块是通过antlr工具实现的。antlr是一个java的语法分析工具。根据提供的语法文件，antl会生成对应的语法分析器。当SQL查询接口接收到一个SQL语句时，语法分析器将解析SQL语句，生成对应的语法树。语法树是以SQL查询中的符号和操作符为节点的一棵树。遍历这棵树，同时根据Meta Data的信息，即可得到整个查询的语义。

在得到查询语句的语义之后，需要为查询设定查询的参数和查询的条件。这是SQL解析的目标之一。考虑到MapReduce框架中很难使用全局的变量，本发明中使用Hadoop的Configuration类来设定查询的参数。Configuration类是在Hadoop中全局维护的信息，因此每个节点或每个任务都可以读取Configuration类的内容。但是，由于Configuration类只能支持类似key-value对的name-property这样的属性对，不能支持XML格式的参数设置的方式，因此必须为不同的参数设置带有序号的属性名。具体来说，以WHERE子句的参数为例，我们首先可以在Configuration中设置一个属性SelectConditionNumber，来标识一个WHERE子句有几个逻辑判断条件，然后需要设置下标从1到SelectConditionNumber的逻辑判断条件，即从Configuration中读取SelectCondition1，SelectCondition2等，再设置逻辑判断条件的连接符（and，or），即从Configuration中读取ConditionConjunction1，ConditionConjunction2等。这样，在MapReduce任务执行过程中，只需要读取Configuration中的有关信息，即可设置WHERE子句的选择条件。其他的SQL查询中的操作和对象也都可以用类似的方式进行设置。

执行方式的动态选择是保证效率和强大的查询能力的核心部分。本发明设计的内存处理的执行方式比MapReduce的执行框架效率高，但是相应的，查询结果必须能够保持在内存中。对于大量数据的复杂查询，需要使用传统的MapReduce框架处理。因此，这种动态选择的机制就是必须的。动态选择的机制有两种：基于规则的和基于代价模型的。本发明中同时使用了两种选择机制，并对两种机制加以结合。

基于规则的动态选择机制主要是根据查询的种类、表的数据量等直观的信息，来判断查询的执行方式。表的数据量的信息一定程度上反映结果的数据量。考虑到数据的均匀分布等特点，可以估计出查询结果的数据量，从而判断出查询结果是否能够在内存中处理。如果可以在内存中处理，则可以直接使用内存处理的方式执行查询。

同时，查询种类也能一定程度上帮助选择执行方式。一般地，SQL查询可以分为两种类型：包含聚集语义的和不包含聚集语义的。此处的聚集语义不仅包含聚集函数的操作，也包括GROUP BY操作、连接操作等。而不包含聚集语义的操作则主要是SELECT操作。考虑传统的MapReduce框架。对于不包含聚集语义的查询，是不需要Reduce过程的（只需要将数据分发出来，而不需要进一步的合并数据）；对于包含聚集语义的查询，总是需要Reduce过程的。而根据前面的描述，传统的MapReduce框架和Hadoop系统的效率瓶颈主要在于Shuffle阶段和Reduce阶段。因此对于不包含聚集语义的操作，完全可以使用传统的不包含Reduce阶段的MapReduce框架，而且不会过多影响效率。另一方面，对于复杂的连接操作，查询结果一般是以乘积的方式增长。这样的查询一般无法在内存中处理。

基于代价模型的动态选择机制则是根据已有的信息，建立相关参数和存储代价的模型，通过模型来预测本次查询的存储代价。此处的相关参数包括：表的模式信息、表中每列的平均数据大小、表中记录的数量、表中每一列的数据分布情况、查询条件等。这些信息都可以从Meta Data、查询语句本身或者查询的历史记录中取得。例如，下面这个模型是一个根据数据的信息建立的对于简单的Select语句模型：

$\mathrm{resultSize}=\underset{i}{\mathrm{\Σ}}\mathrm{resultColumnSiz}{e}_i*\mathrm{tableSize}*\mathrm{querySelectivity}$

这里，可以通过对Hadoop系统的数据流和分析建立模型，例如论文Profiling,what-ifanalysis,and cost-based optimizationof MapReduce programs中建立的代价模型；也可以通过一些模型工具，把以上的相关参数作为输入参数，建立黑盒模型。建立模型之后，即可通过本次查询的信息预测本次查询的存储处理代价。

除了上述的动态选择机制，查询服务器模块还应提供回滚机制，当上面的动态选择错误而导致查询执行出错时，查询服务器模块可以回滚查询的执行过程，保证查询的正确性。

2、数据处理服务器模块（Data Processor模块）

当使用内存处理机制处理数据时，系统还需要维护一块内存区域来存储和处理内存中的数据。因此，当查询服务器模块确定使用内存处理方式执行查询时，需要建立并维护一个数据处理服务器模块。这个数据处理的服务器模块本质是一个支持多种操作的内存表。在内存处理的执行方式下，map任务的本地数据都将通过RPC连接到数据处理服务器模块，并将本地的数据保存在服务器模块的内存表中。当所有map任务结束后，数据处理服务器模块中的数据进行进一步的处理。

本发明中，内存表的实现是一个类似于MapReduce框架中的键值对。其中每一个key对应的值应该是一个链表，保存该键对应的所有值，从而可以在保存中间结果的基础上，进一步地在内存表中进行处理。以SELECT A，COUNT(B)FROM T GROUP BY A这个简单查询为例。每个map任务保存每一个A的值对应的在本地的B的个数。当map统计完本地的数据之后，将这个数据发送给数据处理服务器模块，以A_i:count(B)_i1，count(B)_i2，count(B)_i3……形式保存到数据服务器模块的内存表中，其中A_i:count(B)_ij表示在第j个map任务中，相同的A_i对应的B的个数。然后再内存表中汇总键A_i对应的所有count(B)_ij，就可以得到查询的结果。另一方面，为了保证系统的功能足够，这个内存表应该实现去重、排序、求极值等基本功能。

3、Map Task

在本发明中，Map Task的实现与传统的MapReduce任务处理SQL查询有所不同。考虑到系统需要支持两种查询的执行方式，Map Task应该以两种不同的形式，即传统的MapReduce形式和与内存处理形式。

传统的MapReduce形式的Map Task，需要首先读取Hadoop Configuration，获取查询的相关参数和查询条件，并根据这些查询条件，建立对数据的过滤器。然后根据查询的内容，从指定的路径读取数据，进行查询和过滤，并将过滤的结果写入HDFS。在任务结束后，JobTracker启动Reduce任务继续处理数据。

内存处理形式的Map Task，首先需要连接数据处理服务器模块。之后和传统的Map Task相同，读取查询的参数并对数据进行处理。处理的过程中，Map Task不能将数据写入HDFS，而应保存在本地的内存中。当本地内存满时，Map Task应将本地的数据传输给数据处理服务器模块，从而清除本地的数据继续存储。当任务结束时，JobTracker不再启动Reduce任务处理数据。另外，对于最终结果较小的查询，Map Task可以直接采用Map Scan的方式，直接从HDFS中读取数据并存储在内存表中，即可作为最终结果。

Claims (9)

1.一种基于MapReduce扩展框架的分布式SQL查询方法，其步骤为：

1)客户端发送查询请求到查询服务器模块QueryServer，所述查询服务器模块包括：SQL查询接口、SQL解析模块和动态选择模块；

2)所述SQL查询接口接收到查询请求，将所述请求发送到SQL解析模块，所述SQL解析模块解析得到查询请求的语义；

3)所述动态选择模块根据查询代价模型Cost Model和语义规则对该查询语义进行计算，预测出查询结果需要的存储空间，并选择MapReduce查询方式或内存查询方式；

3-1)查询方式为MapReduce查询时，Job Tracker启动执行Map操作和Reduce操作；

3-2)当查询方式为内存查询时，Job Tracker启动Map操作，并将查询数据保存至本地服务器的内存表中；

4)当查询结束，将本地查询结果上传至Hadoop文件系统HDFS或数据处理服务器模块DataProcessor；

所述扩展框架基于内存表构架，建立由查询服务器模块启动并管理的数据处理服务器模块，所述数据处理服务器模块用于内存查询方式中与每一个map任务连接，收集map任务查询结果并进行处理和输出。

2.如权利要求1所述的基于MapReduce扩展框架的分布式SQL查询方法，其特征在于，Map操作和数据处理服务器模块Data Processor使用Hadoop RPC接口连接，通过设置传输阈值控制每次传输的数据块大小。

3.如权利要求1所述的基于MapReduce扩展框架的分布式SQL查询方法，其特征在于，所述SQL查询接口面向用户提供接口通过socket实现，用于接收和返回客户端查询请求。

4.如权利要求1所述的基于MapReduce扩展框架的分布式SQL查询方法，其特征在于，所述SQL解析模块通过antlr工具实现,所述antlr根据用户提供的语法文件，生成对应的语法分析器。

5.如权利要求4所述的基于MapReduce扩展框架的分布式SQL查询方法，其特征在于，所述SQL解析模块解析得到查询请求的语义，形成语法树；所述语法树是以SQL查询中符号和操作符为节点的树。

6.如权利要求5所述的基于MapReduce扩展框架的分布式SQL查询方法，其特征在于，遍历所述语法树，并根据元组数据Meta Data的信息，得到查询语义。

7.如权利要求1所述的基于MapReduce扩展框架的分布式SQL查询方法，其特征在于，建立所述查询代价模型的相关参数信息根据元组数据Meta Data、查询语句本身或者查询的历史记录取得，包括：表的模式信息、表中每列的平均数据大小、表中记录的数量、表中每一列的数据分布情况、查询条件。

8.如权利要求1所述的基于MapReduce扩展框架的分布式SQL查询方法，其特征在于，所述语义规则的动态选择方法根据查询的种类、表的数据量信息来判断查询的执行方式。

9.如权利要求1所述的基于MapReduce扩展框架的分布式SQL查询方法，其特征在于，在内存查询时可通过MapScan扫描方法对数据进行查询，将结果直接输入到内存表中。