CN105550318B - 一种基于Spark大数据处理平台的查询方法 - Google Patents

Abstract

本发明公开了一种基于Spark大数据处理平台的查询方法，该查询方法是，若是排序查询时，判断当前计算任务的结果的排名序号是否是上一次输出序号的下一位，若是，则输出结果，然后按照排名序号判断紧挨其后是否有排名连续的已经存储的其它计算任务结果，有则一并输出这些结果；若不是，存储当前计算任务结果到相应的排名序号索引位置上。若是非排序查询时，每一个计算任务完成后立即输出结果。所有已经输出的结果不再存储或立即释放其占用内存。本发明的查询方法在执行常规的简单查询时，即使要处理的数据非常庞大，也能快速返回结果；执行复杂的查询时，能在原有基础上大大缩短用户响应时间，无论是执行哪种查询，没有任何延迟。

Description

一种基于Spark大数据处理平台的查询方法

技术领域

本发明涉及一种数据处理的查询方法，尤其涉及一种基于Spark大数据处理平台的查询方法。

背景技术

随着互联网的发展，数以万计的网页不断涌现，而要搜索这些网页首先要抓取存储，然后进行分析计算，google就是这么做的，但是日益庞大的数据使得存储面临着单台机器容量不够的问题，查询面临着耗时太多的问题；针对这两个问题，google提出了分布式存储和分布式并行计算的解决方案，而后来的hadoop产品是这种解决方案的源码实现；hadoop提供了分布式文件系统HDFS和分布式并行计算框架MapReduce，随着hadoop的发展，其生态系统又不断涌现新的项目产品，如Hbase、hive、pig等，但它们都是基于HDFS存储层和MapReduce计算框架，MapReduce通过在集群的多个节点上并行执行计算，因此大大加快了查询的速度，但随着数据量的日益增大，MapReduce渐渐显得力不从心，于是基于内存计算的Spark计算框架应运而生，Spark的查询速度相比hadoop提升了100倍，因此是目前最先进的分布式并行计算框架；随着Spark生态系统的发展，在其上又涌现出Spark SQL、SparkStreaming、MLlib、GraphX等，其中Spark SQL是针对SQL用户开发的可以用SQL语言对结构化数据进行分析查询的工具。

如图1所示，现有技术中，以使用Spark SQL应用程序为例，基于Spark大数据处理平台的查询方法可以分为五个步骤：

步骤1、Spark SQL应用程序接收用户的SQL语句后，进行语法解析、执行策略优化、job(查询作业)生成，最后通过调用Spark平台中的SparkContext接口进行job的提交；

步骤2、SparkContext收到job后，定义Task(计算任务)执行成功后如何存储计算结果，然后提交job给eventProcessActor，接着等待eventProcessActor告知job执行结束，结束后将计算结果返回给Spark SQL；

步骤3、eventProcessActor收到提交job的事件后，在各个节点分配多个Task开始并行计算；

步骤4、每个Task执行完毕后向eventProcessActor报告状态和结果，eventProcessActor统计job的所有Task是否全部完成，若完成，则通知SparkContext提交的job已结束，SparkContext返回计算结果给SparkSQL；

步骤5、Spark SQL得到计算结果后，先进行格式转化，然后拷贝一份给输出模块，最后由输出模块输出结果。

如图2所示，步骤1主要是解析SQL语句的语法并生成一组代表一个Job的RDD，RDD是一种分布式数据结构，它描述了要处理的分布式存储的数据以及怎样处理的算法，因此一个RDD就代表对数据的一个操作，一组RDD就是一个操作序列，按序完成了这一系列操作后即代表完成了一次查询计算；Spark采用了延迟执行策略，即每个操作不先执行，而是先生成操作的序列，然后把这个序列发送给执行器执行；这一组RDD所代表的操作因为有序且不循环，因此其组成的逻辑依赖图又称有向无环图(DAG)；在DAG中，下游的RDD是上游的RDD执行某个操作后生成的。

如图3所示，步骤2主要是将DAG提交给处于另一个线程环境的eventProcessActor，提交前，分配一块内存，并告知eventProcessActor当Task执行成功后往这块内存中存储结果，提交后，当前线程挂起，等待eventProcessActor在job完成后唤醒它，被唤醒后，此时所有Task已经执行结束，并且计算结果全部已经存储到事先分配的内存中；因此直接将这块存储了结果的内存地址返回给Spark SQL模块。由于要等到所有Task执行结束才能返回结果，因此客户响应时间过长，事实上，每个Task的结果都是最终结果的一个子集，没有必要一起输出所有的结果子集；另外，由于输出前要存储整个查询结果，结果的大小将直接受限于程序的堆栈大小。

如图4所示，步骤3主要是实现DAG阶段的划分以及每个阶段Task集合的生成。每个阶段的所有Task执行的都是相同的操作，只不过它们作用的数据不同罢了，因此它们可以完全并行执行；但是不同阶段的Task就不一定能并行了。每个深灰色填充矩形代表一个数据块，并且每个数据块都对应一个Task对其进行计算，由于RDD2的数据块是根据RDD1的多个数据块计算得来的，因此就需要等待执行RDD1的所有Task结束才能开始计算RDD2，所以RDD1和RDD2需要分属两个不同的阶段，而RDD2计算出RDD5时，每个数据块都是独立进行的，互不依赖，RDD2中计算其中一个数据块的Task不需要等待其它数据块的Task结束即可开始向RDD5生成的计算(此处是join操作)，因此RDD2和RDD5可以同属一个阶段；同理，RDD3和RDD4可以同属一个阶段，但RDD4不能和RDD5同属一个阶段；图4中，stage1和stage2互不依赖，可以并行执行，stage3同时依赖stage1和stage2，因此必须等待stage1和stage2均完成后才能执行。

如图5所示，步骤4主要是最后一个阶段的Task执行成功后，将计算结果存储到SparkContext指定的内存中；在图5中，stage1和stage2的Task执行结束后只生成中间结果，stage3的每个Task才是最终结果，而最终输出的结果是由stage3的每个Task的结果拼接而成，在拼接的过程中可能会有排序。如图6所示，如果查询语句要求对结果进行排序，则Task的结果按序存放，如果不对结果排序，则结果按照Task完成的先后顺序排序，每次查询的结果排列顺序将是随机的。对于结果排序的情况，既然每个Task知道它的结果应该排在什么位置，那么应该排在首位的Task就已经计算出了最终结果的头部，可以立即通知客户了；对于结果不排序的情况，由于客户不关心结果的排列顺序，因此不管哪个Task先计算完成，其结果就可以告知客户了，没有必要去等到其它Task，而且即使等待，最终的结果也是按照它们执行完成的先后顺序排序的。

步骤5主要是对记录行数组形式的结果格式化为字符串序列，每一行记录转换成字符串格式，并且将列分隔符替换为制表符，最后输出模块在提取格式化后的结果时，复制一份到输出模块，然后输出。事实上，对结果的格式化不是必须的，格式化可能看起来更美观，但是却消耗了大量内存和性能，在某些情况下，数据本身已经很工整了，此时就没必要去格式化。

综上所述，现有技术中基于Spark大数据处理平台的查询方法存在以下技术问题：

1、目前Spark大数据处理平台执行查询时，用户响应时间过长，尤其是分析较大规模数据时，其响应时间更是超出了用户所能忍受的程度，并且随着分析数据量的增大，这种响应延迟也将同步增加。

2、目前Spark大数据处理平台不支持大规模查询结果的输出，默认配置只允许输出1G的查询结果数据量，配置的过少，将不能充分利用内存资源，配置的过多，若结果超出实际剩余的内存空间将导致内存溢出异常；再者，对于内存配置较低的机器环境，允许输出的数据量将进一步大大缩减。

3、Spark SQL在获取Spark大数据处理平台的计算结果后，要进行一些格式转化和数据拷贝后才正式输出，将造成内存中相同或近似相同的数据有多个拷贝，浪费了内存资源，也降低了性能，也直接影响了用户响应和结果存储容量，并且这种影响会随着输出结果的增大而增大。

发明内容

本发明要解决的技术问题是提供一种基于Spark大数据处理平台的查询方法，该查询方法在执行常规的简单查询时(DAG阶段比较少)，即使要处理的数据非常庞大，也能快速返回结果；执行复杂的查询时，能在原有基础上大大缩短用户响应时间，无论是执行哪种查询，都试图实现只要有结果满足输出条件就立即输出，没有任何延迟。

为了解决上述技术问题，本发明基于Spark大数据处理平台的查询方法是，当Spark应用程序向Spark大数据处理平台提交job时，同时传递格式化结果的规则、输出结果的规则以及结果是否要排序的通知，同时在Spark平台内部根据传递的这些信息设定Task执行成功后的处理策略，所述处理策略包括：

若是排序查询时，判断当前Task结果的排名序号是否是上一次输出序号的下一位，若是，则根据Spark应用程序传递的格式化结果的规则和输出结果的规则输出结果，然后按照排名序号判断紧挨其后是否有排名连续的已经存储的其它Task结果，有则一并输出其它Task结果,已经输出的结果其占用的内存立即释放；若不是，存储当前Task结果到相应的排名序号索引位置上。这样，只要结果按照排名序号满足输出条件就立即输出，无任何延迟，最快的情况下，计算首结果的Task第一个完成，最慢的情况下，计算首结果的Task最后一个完成，因此平均下来至少缩短一半的响应时间；

若是非排序查询时，每一个Task成功后立即根据Spark应用程序传递的格式化结果的规则和输出结果的规则输出结果，结果不再累积存储。这样，只要有Task执行成功，就立即输出它的结果，随着Task集合的不断完成，结果也是连续的输出，直到输出最后一个完成的Task,在这种情况下，整个计算过程没有任何输出延迟，只要有新的计算结果就立即输出；对于大规模数据集的分析来说，任务数增加了，但每个任务处理的数据块大小没变，而无论处理的数据集多大，都是第一个完成的Task立即输出结果，因此成功实现了只要是简单查询，哪怕是超大规模数据集，也能快速输出首结果。

如果是非排序查询，Spark大数据处理平台不再申请存储Task结果的内存，相应地，DAG最后一个阶段的Task执行成功后直接输出结果；如果是排序查询且Task结果需要暂时存储，判断内存是否足够容纳该Task结果，若内存不够容纳，则立即终止当前job，并通知Spark应用程序查询结果超出系统容量，提示客户增加筛选条件。因此，非排序查询的情况下，Spark大数据处理平台能够源源不断输出海量的查询结果，支持大数据量查询返回的场景；排序查询的情况下，不会出现查询结果过大导致内存溢出异常的问题。

Spark SQL应用程序得到计算结果后，先判断结果是否为空，如果为空，不再输出，如果不为空，根据配置可以选择是否格式化，然后输出。

Spark SQL应用程序输出结果时，直接引用结果，不再重新拷贝一份到输出模块。

Spark SQL应用程序在向Spark大数据处理平台提交job前，需要预先定义格式化结果的规则、输出结果的规则、结果是否要排序的通知这三个参数，并在提交job时传递这三个参数，其中格式化结果的规则根据配置可以是空。

将Spark大数据处理平台所有跟提交job相关的接口均进行重载，重载的接口新增格式化结果的规则、输出结果的规则以及结果是否要排序的通知这三个参数，最后在正式提交job时，根据这三个参数设定Task成功后的处理策略；同时Spark SQL应用程序在提交job时，使用重载的接口。

本发明基于Spark大数据处理平台的查询方法与现有技术相比具有以下有益效果。

1、该查询方法在执行常规的简单查询时(DAG阶段比较少)，即使要处理的数据非常庞大，也能快速返回结果；执行复杂的查询时，能在原有基础上大大缩短用户响应时间，无论是执行哪种查询，都试图实现只要有结果满足输出条件就立即输出，没有任何延迟。大规模以下数据的任意查询以及超大规模数据的简单查询都能够在3s内看到首批结果，即客户响应时间始终控制在3s以内；对于超大规模数据的复杂查询，能在现有技术实现的基础上大幅加快客户响应。

2、非排序的查询可以输出海量的查询结果，甚至可以输出存储数据的总量；排序的查询确保不会因为输出结果过大导致内存溢出异常，并且在一定机率上大幅增加了允许输出的数据量。

3、Spark SQL应用程序可以输出格式化和未格式化两种结果。

4、Spark SQL应用程序的输出模块获取查询结果时直接引用job提交模块得到的结果，避免了结果复制；

5、Spark大数据处理平台拥有输出结果的功能，并且怎样格式化结果以及输出结果的规则由Spark应用程序定义，因此该功能适用所有的Spark应用程序；

6、已有的Spark应用程序在提交job时仍可以使用原始的接口，不受影响。

附图说明

下面结合附图和具体实施方式对本发明基于Spark大数据处理平台的查询方法作进一步的详细描述。

图1是现有技术中Spark SQL执行查询的架构图。

图2是现有技术中Spark SQL生成DAG的框架图。

图3是现有技术中SparkContext提交job的流程图。

图4是现有技术中RDD阶段划分的示意图。

图5是现有技术中DAG按阶段执行的过程图。

图6是现有技术中排序查询Task存储计算结果的示意图。

图7是本发明实施例提供的查询结果无延迟输出的实现流程图。

图8是本发明实施例提供的Task成功处理策略中排序查询处理的实现流程图。

图9是本发明实施例提供的Task成功处理策略中非排序查询处理的实现流程图。

图10是本发明实施例提供的非排序查询支持海量查询结果的实现流程图。

图11是本发明实施例提供的排序查询对查询结果做内存保护的实现流程图。

图12是本发明实施例提供的Spark SQL处理job查询结果的实现流程图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

实施例一：

如图7所示，本实施方式基于Spark大数据处理平台的查询方法中结果无延迟输出的具体实施方式如下：

Spark大数据处理平台的应用程序编程接口SparkContext提供新的job提交接口，新接口要求传递输出结果的规则、格式化结果的规则、结果是否要排序的通知。

新接口重新定义Task成功时的结果处理策略，供Task成功事件发生时执行，在该处理策略中，不再是单纯的只存储Task的结果，而是根据结果要排序与否，判断结果是否满足立即输出条件，若满足，则直接根据Spark应用程序定义并传递的格式化结果的规则和输出结果的规则对结果先进行格式化再输出，结果输出后不再存储；若暂时不满足输出条件，则临时存储，等到下一个Task成功时再判断输出条件是否满足，若满足立即输出并释放存储内存。

正在开发的Spark应用程序可以使用该新接口实现结果无延迟输出，已有的Spark应用程序仍可以使用原接口正常工作。

例如，对于Spark SQL应用程序，由于其处理的是结构化数据，因此结果要格式化为记录行的数组形式，又因为要将列分隔符替换为制表符，因此还要将记录行数组格式化为字符串数组，以便利用字符串的字符替换功能进行替换处理，然后格式化为列分隔符为制表符的结果形式，最后要输出时，由于Spark SQL应用程序是命令行程序，结果是直接打印到控制台上的，因此对于Spark SQL应用程序来说，输出结果即是打印结果到指定的控制台上；而Spark SQL应用程序在处理SQL语句时，根据语句中是否包含order by字句(排序字句)可判断结果是否要排序。

以上格式化结果的规则、输出结果的规则、结果是否要排序三者信息是Spark应用程序特有的，因此需要在应用提交job时传递给Spark大数据处理平台，并最终在Task成功时使用这些信息以便准确及时地输出结果。

当所有Task均成功结束后，此时整个job即成功结束，而由于所有结果已在Task成功时全部输出，因此job结束后，Spark应用程序无须再执行输出流程，可以立即进入下次查询job的提交。

当某个Task执行失败时，此时整个job宣告失败结束，Spark应用程序在得到job失败结束通知后，输出错误信息并等待下一次查询job的提交。

实施例二：

如图8所示，本实施方式基于Spark大数据处理平台的查询方法中Task成功时处理策略的排序查询处理的具体实施方式如下：

在Task成功时处理策略中，判别当前查询是否要对结果排序，若要排序，则开始应用排序查询处理过程，详述如下：

判断当前Task的结果的排名序号是否是上一次输出序号的下一位，若是，则按照Spark应用程序传递的格式化结果的规则和输出结果的规则先格式化再输出结果，然后按照排名序号判断紧挨其后是否有排名连续的已经存储的其它Task结果，有则一并输出这些结果，输出后释放这些结果占用的内存；若不是，存储当前Task结果到相应的排名序号索引位置上。

需要说明的是，Task结果的排名序号是Spark大数据处理平台在执行job的最后一个阶段前已由其它阶段事先计算好，job最后一个阶段的所有Task分别知道各自结果的排名序号，因此每个独立的Task执行完毕后，其排名顺序已确定了，无须等到所有Task执行完毕才能确定。本发明实施例提到的Task均是指job最后一个阶段的Task。

例如，对于返回结果的查询如表一所示。

表一：

Task1第一个完成，它计算的结果排第3位，而当前已输出到第0位(即还没有输出)，因此不能输出给客户，只能先存储起来，并且存储到第3个索引位置上；

Task2第二个完成，它计算的结果排第1位，因此立即输出，不存储；接着判断紧挨其后的索引位置(第2位开始)上是否有排名连续的结果，由于第2位索引位置上没有结果，不处理；最后更新当前已输出的排名序号为1；

Task3第3个完成，它计算的结果排第5位，而当前已输出到第1位，因此不能输出给客户，只能先存储起来，并且存储到第5个索引位置上；

Task4第4个完成，它计算的结果排第4位，而当前已输出到第1位，因此不能输出给客户，只能先存储起来，并且存储到第4个索引位置上；

Task5第5个完成，它计算的结果排第7位，而当前已输出到第1位，因此不能输出给客户，只能先存储起来，并且存储到第7个索引位置上；

Task6第6个完成，它计算的结果排第2位，而当前已输出到第1位，因此可以立即输出，然后判断紧挨其后的索引位置上(第3位开始)是否有排名连续的结果，由于第3、4、5位索引位置上均有结果，因此继续输出这三个排名连续的结果，而第7位虽然有结果，但第6位的结果还未返回，因此不能输出；最后释放第3、4、5位的结果占用的内存并更新当前已输出的排名序号为5；

Task7最后一个完成，它计算的结果排第6位，而当前已输出到第5位，因此可以立即输出，然后判断紧挨其后的索引位置上(第7位开始)是否有排名连续的结果，由于第7位索引位置上有结果，因此继续输出第7位的结果；最后释放第7位的结果占用的内存并更新当前已输出的排名序号为7；

至此，所有任务已全部结束，而结果也已经全部按序输出；

实施例三：

如图9所示，本实施方式基于Spark大数据处理平台的查询方法中Task成功时处理策略的非排序查询处理的具体实施方式如下：

在Task成功时处理策略中，判别当前查询是否要对结果排序，若无须排序，则开始应用非排序查询处理过程，详述如下：

先按照Spark应用程序传递的格式化结果的规则对结果进行格式化，然后按照Spark应用程序传递的输出结果的规则输出结果，至此Task成功时的处理结束。

所有Task的结果均不存储，谁先结束谁就先输出，结束一个输出一个，直到所有Task结束，例如对于如表二的查询：

表二

Task1第一个完成，因为对结果的顺序不要求，因此可以立即输出；其它Task处理过程相同，当所有Task均执行结束后，结果就已经输出完毕了。

实施例四：

如图10所示，本实施方式基于Spark大数据处理平台的查询方法对于非排序查询支持海量查询结果的具体实现如下：

用户执行的查询不要求对结果排序时，则所有Task均不存储各自的查询结果子集，因此Spark大数据处理平台没有申请索引内存用于存储Task结果，并在返回给Spark应用程序结果时，返回一个空值。

由于查询结果不再累积存储，每当有新的Task执行成功后，它的结果只临时存储在内存中，当结果输出完毕后，它占用的内存立刻自动回收，随着Task结果的不断接收，内存使用量始终固定在很小的范围，因此，Spark大数据处理平台可以源源不断的输出计算结果，支持海量的查询结果返回。

例如，每个数据文件块的大小为256M,每个文件块对应一个Task对其进行查询计算，由于Task的查询计算结果是文件块内容的一个子集，因此计算结果至多等于256M，相应地，Spark大数据处理平台处理查询的整个过程中存储Task结果消耗的内存始终在0到256M之间，因此无论有多少个文件块和Task，只要Spark大数据处理平台管理的内存中用于存储Task结果的部分多于256M，则可以接收并处理所有的Task结果。

实施例五：

如图11所示，本实施方式基于Spark大数据处理平台的查询方法对于排序查询做一些查询结果内存保护的具体实现如下：

用户执行的查询要求对结果排序时，一部分Task可能因为不满足立即输出条件需要暂时存储，为了防止结果过大，造成内存溢出，Spark大数据处理平台申请内存储存每个Task的结果时判断内存空间是否足够，若不够，终止当前job，并通知Spark应用程序job已失败结束。

最好的情况下，所有的Task恰好按照结果排名的顺序执行完毕，此时，每个Task的结果均不需要存储，可以直接输出。例如，Task1第一个执行完毕，而它的结果刚好排第一，则满足输出条件，直接输出，Task2第二个执行完毕，它的结果刚好排第二，则满足输出条件，直接输出，以此类推，所有Task按序输出结果；最坏的情况下，结果排名第一的Task最后一个执行完毕，此时除了最后一个Task的结果可以直接输出以外，其余所有的Task结果都需要临时存储。由于大多数时候是处于最好和最坏情况之间，并且临时存储的Task结果当满足输出条件的时候会在第一时间输出并释放占用的内存，因此对于排序查询，Spark大数据处理平台在一定概率上也能支持海量查询结果返回，而对于较坏的情况，即需要临时存储的Task结果量超过内存限制时，做一些内存保护即可避免因内存分配不足而造成系统内存溢出异常。

实施例六：

如图12所示，本实施方式基于Spark大数据处理平台的查询方法的Spark SQL处理job查询结果的具体实现如下：

为了使得Spark SQL应用程序能够同时兼容新老两种job提交接口，Spark SQL应用程序在得到job结束后返回的结果时，需要先判断结果是否为空(NULL),若为空，则不再走输出流程，本次查询结束；若不为空，根据新增的配置属性判断是否要格式化，若配置要格式化，则先格式化，然后走输出流程。

实施例七：

本实施方式基于Spark大数据处理平台的查询方法的Spark SQL直接引用查询结果的具体实现如下：

当把单个Task结果或整个job的结果传递给Spark SQL应用程序的输出模块时，输出模块直接访问结果的内存并打印到控制台上，无须重新申请一块内存并将结果复制到这块内存上。

由于避免了结果的重复拷贝，一方面节约了内存消耗，另一方面节省了拷贝带来的时间消耗，因此可以在一定程度上支持更多的查询结果返回以及更快的客户响应。

实施例八：

本实施方式基于Spark大数据处理平台的查询方法的Spark应用程序的输出结果的规则、格式化结果的规则、结果是否要排序的通知怎样传递给Spark大数据处理平台的具体实现如下：

1、输出结果的规则是用函数实现的，在要输出结果的地方调用该函数即可，该函数最终被传递给Task成功后的处理策略，这里的处理策略也是函数实现的，包含了一段业务逻辑处理，供Task成功后调用；

2、格式化结果的规则也是用函数实现的，这里的格式化不是必须的，由配置开关决定，若开关打开，格式化规则函数包含一段具体的格式化步骤，若开关关闭，格式化规则函数不包含任何步骤。格式化规则最终被传递给Task成功时的处理策略；

3、结果是否要排序的通知是通过变量实现的，在Spark应用程序生成执行计划后，根据执行计划的数据类型是否是Sort可动态判定当前查询是否是要排序的，然后定义一个布尔变量存储该判定值，并将它传递给Task成功后的处理策略。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

本实施方式的创新点如下。

1、查询时只要有新的结果计算出来并且满足输出条件就立即输出，不必等到所有并行任务均计算出各自的结果后再一起输出。

2、查询的每个结果子集一旦输出就立即释放内存，由于内存被及时释放，因此可以源源不断接收新的结果子集。

3、对接收Task计算结果并申请内存存储做保护，系统无法容纳更多计算结果时，终止job，并提示客户，有效避免程序异常。

4、查询结果是否要格式化为工整统一的格式是可选择的，并且格式化的过程是分批的，有效减少了大量数据在内存中有多个拷贝。

5、Spark SQL应用程序输出查询结果时直接访问结果内存，无须重新申请内存并拷贝结果。

6、Spark应用程序需要将输出结果的规则以及格式化结果的规则传递给Spark大数据处理平台，这样可以保证本发明的方案可以被其它模块复用，该模块如果要使用立即输出功能，只需要向Spark大数据处理平台传递它的输出规则和格式化规则，系统即可知道该如何输出了，因为不同的模块处理的数据格式以及输出的结果格式都可能是不一样的。

本实施方式与现有技术相比具有以下有益效果。

1、执行大数据查询时，客户响应时间大大缩短，在极短的时间内即可看到首结果。

2、对非排序查询的结果无数量和大小限制，支持海量结果连续不断输出。

3、对排序查询，对输出结果做内存保护，有效避免因输出结果过大导致Spark大数据处理平台异常崩溃。

4、Spark SQL应用程序可以根据配置选择是否对计算结果进行格式化，某些场景下，并不需要输出的数据看起来很工整，因此可以一定程度减少内存和性能消耗。

5、Spark SQL应用程序的输出模块获取查询结果时直接引用job提交模块得到的结果，避免了结果复制；

6、Spark大数据处理平台拥有输出结果的功能，并且怎样格式化结果以及输出结果的规则由Spark应用程序定义，因此该功能适用所有的Spark应用程序。

Claims (6)

1.一种基于Spark大数据处理平台的查询方法，当Spark应用程序向Spark大数据处理平台提交job时，同时传递格式化结果的规则、输出结果的规则以及结果是否要排序的通知，同时Spark内部设定Task执行成功后的处理策略，其特征在于，所述处理策略包括：

若是排序查询时，判断当前Task结果的排名序号是否是上一次输出序号的下一位，若是，则根据Spark应用程序传递的格式化结果的规则和输出结果的规则输出结果，然后按照排名序号判断紧挨其后是否有排名连续的已经存储的其它Task结果，有则一并输出其它Task结果,已经输出的结果其占用的内存立即释放；若不是，存储当前Task结果到相应的排名序号索引位置上；

若是非排序查询时，每一个Task成功后立即根据Spark应用程序传递的格式化结果的规则和输出结果的规则输出结果，结果不再存储。

2.根据权利要求1所述基于Spark大数据处理平台的查询方法，其特征在于：如果是非排序查询，Spark大数据处理平台不再申请存储Task结果的内存，相应地，job最后一个阶段的每个Task执行成功后直接输出结果；如果是排序查询且Task结果需要暂时存储，判断内存是否足够容纳该Task结果，若内存不够容纳，则立即终止当前job，并通知Spark应用程序查询结果超出系统容量，提示客户增加筛选条件。

3.根据权利要求1所述基于Spark大数据处理平台的查询方法，其特征在于：Spark大数据处理平台内部集成的SQL语言交互式查询引擎应用程序Spark SQL得到计算结果后，先判断结果是否为空，如果为空，不再输出，如果不为空，根据配置可以选择是否格式化，然后输出。

4.根据权利要求3所述基于Spark大数据处理平台的查询方法，其特征在于：Spark SQL应用程序输出结果时，直接引用结果，不再重新拷贝一份到输出模块。

5.根据权利要求1所述基于Spark大数据处理平台的查询方法，其特征在于：Spark SQL应用程序向Spark大数据处理平台提交job前，需要预先定义格式化结果的规则、输出结果的规则、结果是否要排序的通知这三个参数，并在提交job时传递这三个参数，其中格式化结果的规则根据配置可以是空。

6.根据权利要求1所述基于Spark大数据处理平台的查询方法，其特征在于：将Spark大数据处理平台所有跟提交job相关的接口均进行重载，重载的接口新增格式化结果的规则、输出结果的规则以及结果是否要排序的通知这三个参数，最后在正式提交job时，根据这三个参数设定Task成功后的处理策略；同时Spark SQL应用程序在提交job时，使用重载的接口。