CN108595254A - 一种查询调度方法 - Google Patents

Abstract

本发明涉及一种查询调度方法，包括步骤：接收查询任务；针对查询任务进行执行代价估计；并根据执行代价估计的结果，将查询任务调度到相应优先级的执行队列中。其中，针对查询任务进行执行代价的估计，进一步包括：判断数据来源于数据库还是数据集市；以及根据判断结果执行相应的执行代价估计逻辑。本发明根据查询任务的执行代价估计，将不同的执行代价的查询任务调度到相应的队列中，解决了在高并发的数据库查询和数据集市查询并存的混合环境下，由于各类查询调度不合理，导致系统响应缓慢、用户体验差的问题。

Description

一种查询调度方法

技术领域

本发明涉及商业智能平台中资源调度技术领域，尤其涉及一种查询调度方法。

背景技术

在一个高并发商业智能(BI)系统中，通常并发的数据查询可到达数百至数千个同时的会话。而其中每个会话所需查询的数据量级和计算复杂度是完全不同的。有的只是对数百行数据进行简单的汇总计算，并期望计算结果能够秒级返回。有的复杂计算可能需要访问上亿条数据，并可能进行多个亿级表的join运算，需要耗费海量的CPU和内存资源，而其用户也许并不要求返回实时计算结果，只需要数分钟甚至数十分钟返回结果就能接受。目前数据库的实现中，较多的采用基于代价的任务调度。形象的说，就是把数据访问分成快车道和慢车道，对于小数据量简单计算，并期望秒级返回的查询，放到快车道上，快速返回结果。而对于那些大数据量，实时性要求不高的访问，全部放到慢车道上，这样尽管它们互相挤占资源，但是并不会影响快车道上的数据访问。

对于一个典型的商业智能系统，通常既支持数据库的访问，也同时支持私有的或者基于开源框架的数据集市，以加速数据分析响应的速度。而不同用户的查询，可能是基于数据库的，也可能是基于集市数据的，当然也有混合查询的需求，这进一步增加了并发查询资源调度的复杂性。

因此，有必要提供一种调度方法，用以解决现有商业智能系统中，在高并发的数据库查询和数据集市查询并存的混合环境下，由于各类查询调度不合理，导致系统响应缓慢、用户体验差的问题。

发明内容

鉴于上述的分析，本发明旨在提供一种查询调度方法，用以解决现有商业智能系统中，在高并发的数据库查询和数据集市查询并存的混合环境下，由于各类查询调度不合理导致的系统响应慢、用户体验差的问题。

本发明的目的主要是通过以下技术方案实现的：

提供一种查询调度方法，具体包括以下步骤：

接收查询任务；

针对查询任务进行执行代价估计；

根据执行代价估计的结果，将查询任务调度到相应优先级的执行队列中。

其中，所述针对查询任务进行执行代价的估计，包括步骤：

判断查询任务中的数据来源于数据库还是数据集市；根据判断结果，针对数据库查询或数据集市查询进行执行代价的估计。

a.针对数据库中的查询任务，执行代价的估计，进一步包括：在判断数据来源于数据库时，并在数据库具有执行代价估计的功能时，直接获取数据库的估计结果；在数据库不提供执行代价估计的功能时，采用历史查询记录对查询任务进行估计。

进一步的，在数据库不提供执行代价估计的功能时，具体利用历史查询记录、采用指数平滑算法进行执行代价估计。

优选的，在数据库具有执行代价估计的功能时，还包括对数据库的估计结果进行修正的步骤，包括：

判断查询任务是否有历史代价记录；

在有历史代价记录的情况下，计算基于历史代价记录的估计值，利用基于历史代价记录的估计值结合权重修正数据库的估计结果；

在没有历史代价记录的情况下，采用缺省值修正数据库的估计结果。

b.当查询任务所涉及的数据来自数据集市时，查询任务的执行代价估计包括：

将查询任务分解为基本查询任务，再基于预先定义的基本运算函数及其对应的计算代价，估计各个基本查询任务的执行代价，通过汇总计算获得涉及数据集市的查询任务的总体执行代价。

进一步的，当查询任务所涉及的数据分布在不同的节点上，则取各节点上估计结果的最大值。

优选的，在估计出查询任务的执行代价后，还包括利用历史代价记录对估计结果进行修正的步骤：

判断查询任务是否有历史代价记录；

在有历史代价记录的情况下，计算基于历史代价记录的估计值，利用上述估计值结合权重修正估计结果；

在没有历史代价记录的情况下，则采用缺省值修正估计结果。

根据上述估计逻辑，获取查询任务的执行代价估计结果后，根据预先设置的阈值，将查询任务调度到相应优先级的队列中。

进一步的，系统根据查询任务的数量和系统压力，动态分配不同优先级执行队列的系统资源；和/或根据系统时间，动态调整不同优先级执行队列的系统资源。

本发明有益效果如下：

实现本发明的商业智能(BI)系统，在接入复杂的数据系统(包括多种数据库，数据集市)，并建立各种不同量级的查询后，能够极大优化系统资源的调度。在多用户、高并发的场合实现：

有效的隔离用户：通过将查询调度到相应优先级的队列中，使得高代价查询的用户不会影响使用低代价查询的用户，实现了轻查询依然很快，高代价查询之间由于互相影响而可能变得更慢，进而能促使用户不断优化查询，提升响应速度。

提升用户体验。在用户没有进行高代价查询时，其报表响应速度会很快，用户体验会很好；而如果用户提交多个查询，其中既有低代价查询，也有中等或高代价的查询，由于将低代价的查询放入了较快、较高优先级的队列中，因此查询响应较快；而将中级或高代价的查询放入较慢、或优先级较低的队列中，查询响应较慢，但用户在等待全部结果之前，可以提前看到查询响应较快的查询结果，如此使得查询体验得到了提升。

最大限度的利用系统资源。当查询出现堵塞时，可以动态扩充线程池的大小让排队的查询跑起来；同时根据白天和夜晚集市的使用特点，动态智能的调整不同线程池资源的分配，可以在晚间分配更多的系统资源给查询代价较高的查询任务，实现在晚间加快查询任务的效果；而白天恢复初始资源分配，如此保证白天不影响用户使用。

本发明的其他特征和优点将在随后的说明书中阐述，并且，部分的从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

附图仅用于示出具体实施例的目的，而并不认为是对本发明的限制，在整个附图中，相同的参考符号表示相同的部件。

图1为本发明查询调度方法的具体使用环境—商业智能BI系统实例；

图2为针对数据库返回的执行时间进行修正的流程图；

图3为针对数据集市的估计结果进行修正的流程图。

具体实施方式

下面结合附图来具体描述本发明的优选实施例，其中，附图构成本申请一部分，并与本发明的实施例一起用于阐释本发明的原理。

本发明的一个具体实施例，公开了一种查询调度方法，具体运行在图1所示的商业智能BI系统。其中，查询的数据既可能来自于数据集市，也可能来自于数据库。数据集市通常都是基于Hadoop或类Hadoop框架的分布式集群。在这个系统中，用户可以通过浏览器或者通过移动端的APP去访问报表。每次报表的访问可能衍生出一个或者多个数据库或数据集市的查询。为简化描述，我们可以认为每次查询都通过一个线程完成。查询也是本发明中调度任务的最小单元。下图中的C表示Client节点即客户端节点(是用户访问的入口，也是进行数据可视化展示的节点)。N表示Naming节点，生成执行计划并管理元数据。M和R则分别表示Map和Reduce节点。

本实施例具体以上述商业智能系统中的查询调度方法为例进行说明，查询调度方法包括以下步骤：

步骤S1.接收查询任务。所述查询任务包括对数行数据进行汇总计算的简单查询任务，也包括需要访问上亿条数据，进行多个亿级表的join运算等需要耗费不同计算代价的多种查询任务。

步骤S2.针对查询任务进行执行代价估计。

对于商业智能(BI)系统的用户来说，用户最直观的感受就是报表打开的速度。因此，本实施例中采用执行时间作为查询任务执行代价的表征。但实际上，执行代价还包括查询任务消耗的内存资源，IO资源，网络资源等。本发明并不局限于采用执行时间作为唯一的执行代价表征，选取执行时间、内存资源，IO资源，网络资源等因素中的几个或全部进行加权运算，得到综合的代价估计结果，也在本发明的保护范围内。

本实施例中，考虑到执行时间中包含了其他影响因素带来的代价。例如，一个查询任务的内存消耗较大，而系统资源不足，那么其所占用的内存将被交换到磁盘中，使得计算变慢，导致计算代价增大，进而相应的增加了执行时间。因此，执行时间在一定程度上能体现内存资源，IO资源，网络资源等因素在查询任务执行代价上的影响。为了进一步简化运算，减少系统运算负荷，本实施例中具体采用执行时间作为查询任务执行代价的体现。针对查询任务执行代价估计的方式如下：

步骤S21.判断查询任务中的数据来源于数据库还是数据集市。

本实施例中所述数据集市是基于Hadoop或类Hadoop框架的分布式集群，所述数据库可以是Oracle、或SQL Server等。但本发明并不局限于以上数据集市和数据库。

步骤S22.当查询任务所涉及的数据来自数据库时，获取针对该查询任务的估计执行时间。

针对普通的SQL查询，数据库中一般提供了估算执行代价的功能，如果数据库没有提供相关方法和数据，就只能依赖历史代价记录信息来估计这次查询的代价。常用的数据库，如Oracle，DB2，SQLServer等都可以直接返回估计的执行时间；但也有数据库像MySQL无法返回执行时间，此时根据这个查询的历史代价记录来估计该查询可能的代价。针对无法利用历史代价记录的第一次查询，该第一次记查询的历史代价记录是不存在的，则将该查询划分到“未知代价类”，统一进行处理，具体可以采用分配一个缺省的FIFO队列的方式。

在数据库不提供估计执行时间的情况下，系统根据相似查询任务的历史查询记录中的执行代价，进行本次查询任务的代价估计，估计结果也是时间值。

具体的，上述根据历史代价记录进行查询代价估计方法为：

为进一步清楚的说明，定义每个查询为一个Query。优选的，对每个Query，系统会保存该Query的估计代价和实际执行代价，作为历史代价记录。优选的，系统可以保存最近二十次Query执行的记录。优选的，上述二十次执行代价记录，各自有一个权重，时间点越近的执行，其对应的权重可以越高。估计方法优选采用指数平滑算法：

T_P(n+1)＝λT_A(n)+(1-λ)T_p(n) (1)

在以上公式中，T_P(n+1)表示对下一次查询的代价估计；T_A(n)表示最近一次查询的实际代价；T_p(n)表示之前对最近一次查询的代价估计；λ表示衰减系数(权重)，范围在(0,1]之间可配置，缺省值使用0.9。初始值T_p(1)＝T_A(1)。

优选的，针对数据库可以估算出执行代价这一情况来说，历史代价记录也可以作为参考来修正数据库自身估计的偏差。

针对一个查询，数据库返回的估计执行时间为t，对该执行时间进行如下修正(图2)：

判断该查询是否有历史记录；

当系统中有历史代价记录，则计算该查询基于历史记录的估计值T_P(n+1)，计算具体采用公式(1)，根据计算结果修正估计时间，计算公式为：t*α+(1-α)*T_P(n+1)；

当系统中没有历史代价记录，则直接采用估计值，或者采用缺省值α_df修正估计值。

其中，α_df是缺省修正因子，对于不同的数据库，该值可能不同，需要通过测试进行修正。缺省值是1(即不修正)。α是根据历史查询代价记录时间对估计值进行的修正，取值范围(0,1]，缺省值是0.9。

步骤S23.当查询任务所涉及的数据来自数据集市时，由于数据集市与商用数据库不同，数据集市通常不提供查询任务的执行时间估计，故采用历史代价记录估计查询任务的执行代价。

数据集市一般使用开源软件搭建，也有一些是公司独立开发的私有软件，因此可以通过独立逻辑算法进行执行代价的估计。本实施例，针对类Hadoop(包含Map运算和Reduce运算)数据集市的查询代价进行估计。数据集市中的查询操作一般可以简单分为过滤运算和聚合运算两类。过滤运算在聚合运算之前执行，聚合运算的代价会受到过滤运算的影响，因此需要估算经过过滤之后的数据总量。对于数据均匀分布的列来说，过滤运算执行结果的大小是比较容易估算的，但是大部分情况下，列数据都不能算是均匀的，这种情况下系统中没有相关的信息来估算过滤结果大小；这需要在数据入集市的过程中保存下每一列的数据分布信息；通过数据分布信息，能够大致估算出经过过滤运算之后的结果集大小。根据过滤运算执行后结果大小可以估算出参与聚合运算的数据量大小，并得到集市查询中每个Map任务的代价。

数据集市中的查询任务是由Client节点生成Map任务和Reduce任务。目前在大多数客户环境中，Reduce任务的代价并不高，并不是系统的瓶颈。通过本实施例中所述的商业智能BI系统中的评估，认为可以只考虑Map任务的计算代价是可行的。每个Map任务主要是执行过滤运算和分组聚合运算。数据在Map任务中一般都是按列存储的多行数据构成的Grid块。在N(naming)节点，存有文件列统计信息，包括行数大小，包含的列数，以及每列的数据类型等。根据上述原理、查询需要执行的计算、以及文件列统计信息可以获取过滤运算和聚合运算的代价；根据这个估计代价，可以给Map任务一个优先级，Map上的查询线程池则根据该优先级进行相应的任务调度。

对查询任务执行代价的估计，具体可以采用下述方法：

首先定义查询任务中的基本运算及基本运算对应的计算代价。

具体的，本实施例中定义如下基本运算和函数：

数据分为数值型和字符串行两种类型(type)，数值类型不细分；

两个值比较大小的代价为compCpuCost(type)；

两个数值类型相乘的代价为productCpuCost；

两个数值类型相加的代价为addCpuCost；

维度列所形成的分组个数为grpCnt；

集市数据的总列数为n。

基于上述基本运算，估计过滤运算的执行代价为：针对比较操作：>、>＝、<、<＝、＝，这5种类型的运算是相同的计算代价，计算代价表示为n*compCpuCost(type)。

将聚合运算分为原子聚合运算和组合聚合运算。

基于上述基本运算，聚合运算表示为：

SumSQTotal(平方和)：只针对数值类型，cpu代价为n*productCpuCost；

CountAllTotal(计数器)：计算数据量，cpu代价为n*1；

SumTotal(总和)：cpu代价为(n-grpCnt)*addCpuCost(type)；

组合聚合运算示例：

VarianceTotal(方差)：SumSQTotal+CountAllTotal+SumTotal；

AvgTotal(平均值)：SumTotal+CountAllTotal。

以上基本运算的定义、过滤运算、聚合运算的类型均是本实施例的设计。在基础运算的基础上，定义过滤计算，以及之后的聚合运算是本发明的技术方案。具体基础运算的定义，过滤运算、聚合运算的具体类型的定义及相应的函数定义，则是依据商业智能BI系统的应用领域、计算需求等决定的。

对每一个集市查询，首先将其分解成如上所示的基本查询(过滤运算、聚合运算)，通过预先定义的基本运算及其代价计算函数估计出每一基本查询的执行代价，然后将所有代价汇总计算出该集市查询的总体代价。因为集市的数据分布在不同的Map节点，所以在计算代价的时候需要考虑这个因素，要取相关Map节点的代价的最大值。

进一步的，在以上数据集市查询任务的代价估计结果上，根据历史代价记录对代价估计结果进行修正(图3)。

在根据上述计算方法计算出集市查询任务的代价估计结果后，判断判断该查询是否有历史记录，如果有则可以利用公式(1)计算出本次查询基于历史记录的估计值T_P(n+1)。在有历史记录的情况下，基于历史代价估计本次查询代价T_P(n+1)，再采用公式t*α+(1-α)*T_P(n+1)修正代价估计结果；在没有历史代价记录的情况下，则直接采用估计结果，或者采用缺省值修正估计结果，计算公式为t*α_df。经过以上数据修正逻辑运算，返回该查询任务的经过修正的代价估计结果。以上公式中，α_df是缺省集市查询修正因子，可以通过测试确定，缺省值是1.5。α是根据历史记录对计算的集市查询时间进行修正的权重系数，取值范围(0,1]，缺省值是0.3。根据与数据库中缺省值的取值比较，通过多次试验和验证，将集市查询历史记录的代价权重设置的更高，更有利于代价估计的准确性。本实施例中，以查询时间作为数据集市的代价估计计算的对象。

步骤S3.根据执行代价估计的结果，将不同的查询调度到对应的优先级队列。

本实施例中，商业智能BI系统中预先配置了3条查询处理队列，3条查询处理队列均为FIFO队列，每一队列对应的处理优先级不同，根据查询任务的执行代价估计结果，将查询任务调度到对应的FIFO队列中，调度策略如下：

FIFO1：t_adjust<＝10s，快车道

FIFO2:10<t_adjust<＝300s，中速车道

FIFO3:t_adjust>300s，慢车道

上述调度方式策略中的划分阈值可以是系统预先设置的，也可以根据系统吞吐、主要查询任务、系统环境等进行相应更改。

在步骤1和2后，已经为所有的查询任务都进行了执行代价估计，执行代价以执行时间为表征，具体以秒为单位，取整后根据时间大小和阈值的关系，分别放入上述3个FIFO队列中。上述3个FIFO队列的优先级逐渐降低。

在放入队列的同时，记录下当时队列的长度，记录形式为：Query01：[FIFO1,130]，表示Query01放入FIFO1队列中，当时队列排队长度为130个查询。

对于“未知代价类”类型的查询，缺省是放入到队列FIFO3中。这样处理可能导致的一个问题就是当系统任务很重的时候，新查询都会比较慢相应。解决办法是当一个查询第一次被保存的时候，触发一次查询，由此获得历史代价记录信息。当有新的查询进来的时候，也会根据其估计时间插入相应队列的尾部。

进一步的，系统计算资源可以根据情况进行动态调整

假设系统中可用的CPU核数(受限于硬件资源以及license)为Ncore，对应的最大查询线程个数为2*Ncore(假设扩张系数为2)，系统中查询线程池的个数为3，分别对应如上三个FIFO队列。将线程分配到这3个查询队列中缺省分配比例为2:2:1，即FIFO1占4/5*Ncore总线程，FIFO2占4/5*Ncore，FIFO3占2/5*Ncore个线程。该分配比例根据实际情况是可以更改的。队列中每个查询分配一个线程并开始执行，一旦开始执行，该查询将被移除等待队列，放入执行队列中。若查询失败，将重新移回等待队列中。一旦一个查询获得了执行机会，将持续执行到结束。

在典型的客户场景中，通常是晚上把数据导入到数据集市中，白天业务和IT人员进行报表的查询。通常来说导数的查询都是比较重的，大多都在慢车道上运行。而白天的查询则更多的期望实时结果，较少的、在慢车道运行。为最大限度的利用系统资源，本发明实现了根据系统时间动态调整各车道资源的算法。

FIFO1：F(t)*2/5*N_core,F(t)＝2when in 8am to 8pm,F(t)＝1in other time

FIFO2：M(t)*2/5*N_core,M(t)＝2when in 8am to 8pm,M(t)＝1in other time

FIFO3：S(t)*2/5*N_core,S(t)＝1when in 8am to 8pm,S(t)＝3in other time

上面公式中的F(t)，M(t)和S(t)都是可配置的，并且时间范围也是可以配置的。

在实际的环境中，有可能数据库在持续的吐数，导致相应查询的线程处在等待中，而该线程池中所有的线程都被占用，但是因为在等待而没有运行，排队的查询也没有获得执行的机会，导致系统资源的浪费。为避免这种情况，本发明支持动态扩张线程池。扩张的原则是当线程池中有线程处于block或者wait状态，并且FIFO队列中有任务在等待的时候，执行线程池的扩张。扩张最大不超过线程池线程数量的两倍。

综上所述，本发明实施例提供了一种查询调度方法，实现了在数据库和数据集市混合的环境里，将各类查询的代价进行归一化处理，并根据代价的大小，将查询分配到不同的优先级队列中。通过限制各个队列中对应的线程池的大小，对各个队列本身进行了较好的隔离，所以相互影响较小。实现本发明的算法，可以有效隔离低代价和高代价查询，实现低代价查询快速响应，而较重的高代价查询排队进行，避免了慢车驶上了快车道，从而导致了快车道被堵塞的问题，有效提升商业智能(BI)系统查询的用户体验。

本领域技术人员可以理解，实现上述实施例方法的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于计算机可读存储介质中。其中，所述计算机可读存储介质为磁盘、光盘、只读存储记忆体或随机存储记忆体等。

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

Claims (10)

1.一种查询调度方法，其特征在于，包括以下步骤：

接收查询任务；

针对查询任务进行执行代价估计；

根据执行代价估计的结果，将查询任务调度到相应优先级的执行队列中。

2.根据权利要求1所述的查询调度方法，其特征在于，所述针对查询任务进行执行代价的估计，包括步骤：

判断查询任务中的数据来源于数据库还是数据集市；根据判断结果，针对数据库查询或数据集市查询进行执行代价的估计。

3.根据权利要求2所述的查询调度方法，其特征在于，所述执行代价的估计，进一步包括：在判断数据来源于数据库时，并在数据库具有执行代价估计的功能时，直接获取数据库的估计结果；在数据库不提供执行代价估计的功能时，采用历史查询记录对查询任务进行估计。

4.根据权利要求3所述的查询调度方法，其特征在于，在数据库不提供执行代价估计的功能时，所述采用历史查询记录对查询任务进行执行代价估计，具体是采用指数平滑算法进行估计。

5.根据权利要求3所述的查询调度方法，其特征在于，在数据库具有执行代价估计的功能时，还包括对数据库的估计结果进行修正的步骤：

判断查询任务是否有历史记录；

在有历史记录的情况下，计算基于历史记录的估计值，利用基于历史记录的估计值结合权重修正数据库的估计结果；

在没有历史记录的情况下，采用缺省值修正数据库的估计结果。

6.根据权利要求2所述的查询调度方法，其特征在于，当查询任务所涉及的数据来自数据集市时，查询任务的执行代价估计包括：

将查询任务分解为基本查询任务，再基于预先定义的基本运算函数及其对应的计算代价，估计各个基本查询任务的执行代价，通过汇总计算获得涉及数据集市的查询任务的总体执行代价。

7.根据权利要求6所述的查询调度方法，其特征在于，当查询任务所涉及的数据分布在不同的节点上，则取各节点上估计结果的最大值。

8.根据权利要求6所述的查询调度方法，其特征在于，在估计出查询任务的执行代价后，还包括利用历史记录对估计结果进行修正的步骤：

判断查询任务是否有历史记录；

在有历史记录的情况下，计算基于历史记录的估计值，利用上述估计值结合权重修正估计结果；

在没有历史记录的情况下，则采用缺省值修正估计结果。

9.根据权利要求1～8中任一所述的查询调度方法，其特征在于，根据预先设置的阈值，将查询任务调度到相应优先级的队列中。

10.根据权利要求1～9中任一所述的查询调度方法，其特征在于，根据查询任务的数量和系统压力，动态分配不同优先级执行队列的系统资源；和/或根据系统时间，动态调整不同优先级执行队列的系统资源。