计划优化方法、装置、系统及计算机可读存储介质与流程

本发明涉及大数据技术领域，尤其是涉及一种计划优化方法、装置、系统及计算机可读存储介质。

背景技术：

在现有的大数据生态环境中，spark(计算引擎)是使用最为广泛的计算组件，但是在超大规模集群和数据集上，sparksql(sparkstructuredquerylanguage，计算引擎结构化查询语言)仍然存在很多问题，比如：无法提前合理的分配分区个数，sql任务的执行计划确定后不可改变，以及sql任务在执行过程中，某一个分区可能存在数据倾斜问题。目前还不能较好的解决以上问题，导致集群资源利用率、sql任务的运行性能较差。

技术实现要素：

本发明的目的在于提供计划优化方法、装置、系统及计算机可读存储介质，以实现对计划的动态调整，改善各分区处理数据倾斜的问题，从而提高集群资源利用率和sql的运行性能。

本发明提供的计划优化方法，包括：根据预设的计划查询节点对本地计划的状态进行查询；当查询到准备执行所述本地计划时，基于本地计划中预设的分区参数确定按照自适应优化规则在分区中执行所述本地计划；其中，所述自适应优化规则为基于可配置的数据处理门限和计划执行过程中产生的元数据而对计划进行重新分区的规则；基于所述自适应优化规则，采集所述本地计划在各分区执行过程中的元数据，根据采集到的所述元数据和数据处理门限对所述本地计划的执行分区进行优化。

进一步的，所述根据预设的计划查询节点对本地计划的状态进行查询的步骤，包括：根据本地计划，创建数据聚合过程中查询节点的输入和spark广播的输入；基于所述查询节点的输入编写状态查询节点，基于所述spark广播的输入编写状态广播节点；根据所述状态查询节点对所述本地计划的状态进行查询，并将查询到的状态通过所述状态广播节点进行广播。

进一步的，所述基于本地计划中预设的分区参数确定按照自适应优化规则在分区中执行所述本地计划的步骤，包括：判断所述本地计划中预设的分区参数是否为启用自适应状态；如果是，按照自适应优化规则在分区中执行所述本地计划。

进一步的，所述判断所述本地计划中预设的分区参数是否为启用自适应状态的步骤，包括：当判断所述本地计划中预设的分区参数为默认状态时，按照原生spark优化规则在分区中执行所述本地计划；其中，所述原生spark优化规则为基于不可配置的已有数据处理门限和计划执行过程中产生的元数据而对计划进行重新分区的规则。

进一步的，所述数据处理门限包括数据处理条数门限和数据处理空间门限，所述方法包括：根据预先定义的数据条数的配置参数配置各分区的所述数据处理条数门限；根据预先定义的数据空间的配置参数配置各分区的所述数据处理空间门限。

进一步的，所述根据采集到的所述元数据和数据处理门限对所述本地计划的执行分区进行优化的步骤，包括：判断采集到的所述元数据是否达到所属分区的所述数据处理条数门限和所述数据处理空间门限中的至少一项；如果是，根据所述元数据以及各分区的所述数据处理条数门限和所述数据处理空间门限对所述本地计划的执行分区进行优化。

本发明提供的计划优化装置，包括：查询模块，用于根据预设的计划查询节点对本地计划的状态进行查询；规则确定模块，用于当当查询到准备执行所述本地计划时，基于本地计划中预设的分区参数确定按照自适应优化规则在分区中执行所述本地计划；其中，所述自适应优化规则为基于可配置的数据处理门限和计划执行过程中产生的元数据而对计划进行重新分区的规则；计划优化模块，用于基于所述自适应优化规则，采集所述本地计划在各分区执行过程中的元数据，根据采集到的所述元数据和数据处理门限对所述本地计划的执行分区进行优化。

进一步的，所述查询模块用于：根据本地计划，创建数据聚合过程中查询节点的输入和spark广播的输入；基于所述查询节点的输入编写状态查询节点，基于所述spark广播的输入编写状态广播节点；根据所述状态查询节点对所述本地计划的状态进行查询，并将查询到的状态通过所述状态广播节点进行广播。

本发明提供的一种计划优化系统，包括：处理器和存储装置；所述存储装置上存储有计算机程序，所述计算机程序在被所述处理器运行时执行如上任一项所述的方法。

本发明提供的一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如上任一项所述的方法的步骤。

本发明提供的一种计划优化方法、装置、系统及计算机可读存储介质，该方法包括：首先根据预设的计划查询节点对本地计划的状态进行查询；当查询到准备执行所述本地计划时，基于本地计划中预设的分区参数确定按照自适应优化规则在分区中执行所述本地计划；然后基于所述自适应优化规则，采集所述本地计划在各分区执行过程中的元数据，根据采集到的所述元数据和数据处理门限对所述本地计划的执行分区进行优化。本发明通过计划查询节点查询本地计划的状态，并根据本地计划的状态、自动设置分区参数和自适应优化规则可以实现对计划的动态调整，有效改善了各分区处理数据倾斜的问题，从而提高集群资源利用率和sql的运行性能。

附图说明

为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种计划优化方法流程图；

图2为本发明实施例提供的一种本地计划的状态查询方法流程图；

图3为本发明实施例提供的一种自适应架构示意图；

图4为本发明实施例提供的一种计划优化装置的结构框图。

具体实施方式

下面将结合实施例对本发明的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

考虑到现有sparksql存在的分区不合理、执行计划不可变和数据倾斜，并由此导致集群资源利用率、sql任务的运行性能较差等问题，发明实施例提供的一种计划优化方法、装置、系统及计算机可读存储介质，可以合理分区、实现对计划的动态调整，有效改善数据倾斜的问题，从而提高集群资源利用率和sql的运行性能。

为便于对本实施例进行理解，首先对本发明实施例所公开的一种计划优化方法进行详细介绍。

实施例一：

参照图1所示的一种计划优化方法流程图，该方法是一种基于大数据查询的计划优化方法，可包括如下步骤：

步骤s102，根据预设的计划查询节点对本地计划的状态进行查询。

在本实施例中，为了实现sparksql的自适应功能，可以预先对有向无环图中的逻辑节点(stage)进行编辑，以得到计划查询节点。该计划查询节点用于存储和执行对本地计划的状态查询功能(planquerystage)；具体的，计划查询节点对sparksql的优化器生成的本地计划进行状态查询，该状态诸如是否准备执行，并当查询到本地计划的状态为准备执行时，将本地计划和准备执行的状态广播至sparksql的执行器中。

步骤s104，当查询到准备执行本地计划时，基于本地计划中预设的分区参数确定按照自适应优化规则在分区中执行本地计划；其中，自适应优化规则为基于可配置的数据处理门限和计划执行过程中产生的元数据而对计划进行重新分区的规则。

在本实施例中，为了既不影响sparksql的原生功能，又能够将sparksql的自适应功能与原始功能进行区别，可以在sparksql的优化器生成本地计划之后，对本地计划增设分区参数(spark.sql.adaptive.enabled)，通过该分区参数使预处理函数按照自适应优化规则度本地计划进行自适应区分执行；其中，该预处理函数可以为sparksql运行的整体流程管理工具queryexecution的核心模块core中execution的预处理函数prepareforexecution。

在一种可能的具体实现方式中，可以包括：判断本地计划中预设的分区参数是否为启用自适应状态；如果是，按照自适应优化规则在分区中执行本地计划。

步骤s106，基于自适应优化规则，采集本地计划在各分区执行过程中的元数据，根据采集到的元数据和数据处理门限对本地计划的执行分区进行优化。

由于在实际应用中，数据倾斜问题是sparksql中比较常见的，诸如某一个分区(partition)的数据量远远大于其它分区数据量，导致个别计划的执行时间远远大于其它计划，从而拖累整个sql的作业时间。因此，本实施例通过采集本地计划在各分区执行过程中的元数据，对计划执行过程中对数据倾斜进行预测，也即根据采集到的元数据和用户配置的数据处理门限对执行本地计划的分区的数量进行重新配置，以使本地计划在执行过程中避免出现数据倾斜问题。

本实施例提供的一种计划优化方法包括：首先根据预设的计划查询节点对本地计划的状态进行查询；当查询到准备执行所述本地计划时，基于本地计划中预设的分区参数确定按照自适应优化规则在分区中执行所述本地计划；然后基于所述自适应优化规则，采集所述本地计划在各分区执行过程中的元数据，根据采集到的所述元数据和数据处理门限对所述本地计划的执行分区进行优化。本实施例通过计划查询节点查询本地计划的状态，并根据本地计划的状态、自动设置分区参数和自适应优化规则可以实现对计划的动态调整，有效改善了各分区处理数据倾斜的问题，从而提高集群资源利用率和sql的运行性能。

在一种可能的实施例中，参照图2，上述根据计划查询节点对本地计划的状态进行查询的实现过程可包括如下具体步骤：

步骤s202，根据本地计划，创建数据聚合shuffle过程中查询节点的输入和spark广播的输入。

在本实施例中，创建的查询节点(querystage)的输入可以为对本地计划的数据聚合shuffle重新编写的shufflequerystageinput，创建的spark广播(broadcast)的输入可以为对本地计划的广播重新编写的broadcastquerystageinput。通过创建自适应的查询节点的输入和spark广播的输入，可以更改原生sparksql的shuffle和广播在运行过程中的不可变的特点，从而实现动态调整执行计划。

步骤s204，基于查询节点的输入编写状态查询节点，基于spark广播的输入编写状态广播节点。

步骤s206，根据状态查询节点对本地计划的状态进行查询，并将查询到的状态通过状态广播节点进行广播。具体的，当查询到本地计划的状态为准备执行时，将本地计划和准备执行的状态广播至sparksql的执行器中。接下来，根据本地计划中预设的分区参数确定按照自适应优化规则或者按照原生spark优化规则在分区中执行本地计划。

为便于理解，本实施例给出一种确定按照原生spark优化规则在分区中执行本地计划的可能实现方式，包括：

当判断本地计划中预设的分区参数为默认状态时，按照原生spark优化规则在分区中执行本地计划。在本实施例中，默认状态(false)为默认自适应功能关闭的状态。上述原生spark优化规则为基于不可配置的已有数据处理门限和计划执行过程中产生的元数据而对计划进行重新分区的规则。

按照原生spark优化规则对本地计划进行优化可以解决数据倾斜问题。但是，由于计划执行过程中各分区所处理的数据量、复杂度均不相同，按照原生spark优化规则只使用同一个不可配置的已有数据处理门限对计划进行优化，会存在不同的数据对资源利用效率很低的问题，基于此，本实施例提供的自适应优化规则可以较好的改善资源利用效率低的问题。

不同于原生spark优化规则，自适应优化规则中的数据处理门限是可由用户根据实际应用进行配置的，所配置的数据处理门限可以包括数据处理条数门限和数据处理空间门限，相应的，数据处理门限的配置方法可以包括如下步骤(1)和(2)：

(1)根据预先定义的数据条数的配置参数配置各分区的数据处理条数门限。具体的，根据数据条数的配置参数spark.sql.adaptive.maxnumpostshufflepartitions配置各分区一个任务需要处理数据条数的最大限制，也即数据处理条数门限。

(2)根据预先定义的数据空间的配置参数配置各分区的数据处理空间门限。具体的，根据数据空间的配置参数spark.sql.adaptive.shuffle.targetpostshuffleinputsize配置各分区一个任务处理数据空间的最大值和最小值中的至少一项，也即数据处理空间门限。

基于上述的数据处理条数门限和数据处理空间门限，本实施例提供了一种根据采集到的元数据和数据处理门限对本地计划的执行分区进行优化的具体实现方式，包括：

首先，判断采集到的元数据是否达到所属分区的数据处理条数门限和数据处理空间门限中的至少一项。

为了解决原生的sparksql一旦确定执行计划之后，在计划执行过程中无法更改有向无环图中节点的参数和计划这一问题，本实施中可以在本地计划执行过程中采集当前节点的元数据。将元数据的数据条数与数据处理条数门限进行比较，将元数据所占数据空间与数据处理空间门限进行比较。

当有其中至少一项的比较结果为超过对应门限时，根据元数据以及各分区的数据处理条数门限和数据处理空间门限对本地计划的执行分区进行优化，诸如重新分配执行本地计划的分区，从而可以更合理的利用sparksql申请的资源。

此外，对于spark引擎框架来说，数据聚合shuffle是一个统一的框架，在基于以上内容修改了元数据存储和重新分配数据量的代码的同时，也要对其他的代码进行适配。

上述实施例提供的一种计划优化方法，通过计划查询节点查询本地计划的状态，并根据本地计划的状态、自动设置分区参数和自适应优化规则可以实现对计划的动态调整，有效改善了各分区处理数据倾斜的问题，从而提高集群资源利用率和sql的运行性能。

实施例二：

为了便于理解上述实施例一提供的计划优化方法，本实施例提供一种实现上述计划优化方法的自适应架构。参照图3所示的自适应架构示意图，每一个查询节点(querystage)都是一棵独立的子树，也是一个独立的执行单元。在加入查询节点的同时，也加入一个查询节点的输入(querystageinput)的叶子节点，该querystageinput作为父亲查询节点的输入。例如对于图3中两表join的执行计划来说，可以创建3个查询节点。最后一个查询节点中的执行计划是join本身，它有2个querystageinput代表它的输入，分别指向2个孩子的查询节点。在执行查询节点时，首先提交它的孩子节点，并且收集这些孩子节点运行时的信息。当这些孩子节点运行完毕后，可以知道它们的大小等信息(也即元数据)，以此来判断查询节点中的计划是否可以优化更新。例如当获知某一张表的大小是5m，它大于广播的大小阈值时，可以将sortmergejoin(分类归并连接)转化成broadcasthashjoin(广播散列连接)以优化当前的执行计划。也可以根据孩子节点产生的shuffle数据量，来动态地调整该节点的归约(reducer)数量。在完成一系列的优化处理后，最终为该查询阶段生成rdd(resilientdistributeddatasets，弹性分布式数据集)的有向无环图，并且提交给有向无环图的调度机来执行。

为了测试上述实施例中计划优化方法的效果，本实施例提供一种实际应用中的实验结果。

本实施例采用50台机器搭建一个集群，使用计划优化方法中的spark对100tb的数据集进行了性能测试，用于比较现有方法中spark和自适应执行的性能。实验结果显示，在自适应执行模式(也即使用计划优化方法)下，75条sql中有62条都得到了明显的性能提升，其中39条sql的性能提升超过10％，最大的性能提升达到了4.2倍，并且没有出现性能下降的情况。另外在原版spark中，有3条sql因为oom(outofmemory，内存溢出)等原因无法顺利运行，在自适应模式下可以使得75条sql在100tb数据集上全部成功运行。

可见，本实施例所提供的计划优化方法可以在很大程度上改善sparksql的易用性和性能，提高了超大集群中多租户多并发作业情况下集群的资源利用率。

实施例三：

基于上述实施例一提供的计划优化方法，参照图4，本实施例提供一种计划优化装置，该装置包括：

查询模块402，用于根据预设的计划查询节点对本地计划的状态进行查询；

规则确定模块404，用于当当查询到准备执行本地计划时，基于本地计划中预设的分区参数确定按照自适应优化规则在分区中执行本地计划；其中，自适应优化规则为基于可配置的数据处理门限和计划执行过程中产生的元数据而对计划进行重新分区的规则；

计划优化模块406，用于基于自适应优化规则，采集本地计划在各分区执行过程中的元数据，根据采集到的元数据和数据处理门限对本地计划的执行分区进行优化。

本实施例提供的一种计划优化装置包括：首先根据预设的计划查询节点对本地计划的状态进行查询；当查询到准备执行所述本地计划时，基于本地计划中预设的分区参数确定按照自适应优化规则在分区中执行所述本地计划；然后基于所述自适应优化规则，采集所述本地计划在各分区执行过程中的元数据，根据采集到的所述元数据和数据处理门限对所述本地计划的执行分区进行优化。本实施例通过计划查询节点查询本地计划的状态，并根据本地计划的状态、自动设置分区参数和自适应优化规则可以实现对计划的动态调整，有效改善了各分区处理数据倾斜的问题，从而提高集群资源利用率和sql的运行性能。

在一些可能实施例中，查询模块402用于：根据本地计划，创建数据聚合过程中查询节点的输入和spark广播的输入；基于查询节点的输入编写状态查询节点，基于spark广播的输入编写状态广播节点；根据状态查询节点对本地计划的状态进行查询，并将查询到的状态通过状态广播节点进行广播。

在一些可能实施例中，规则确定模块404还用于：判断本地计划中预设的分区参数是否为启用自适应状态；如果是，按照自适应优化规则在分区中执行本地计划。

在一些可能实施例中，规则确定模块404还用于：当判断本地计划中预设的分区参数为默认状态时，按照原生spark优化规则在分区中执行本地计划；其中，原生spark优化规则为基于不可配置的已有数据处理门限和计划执行过程中产生的元数据而对计划进行重新分区的规则。

在一些可能实施例中，数据处理门限包括数据处理条数门限和数据处理空间门限，计划优化模块406还用于：根据预先定义的数据条数的配置参数配置各分区的数据处理条数门限；根据预先定义的数据空间的配置参数配置各分区的数据处理空间门限。

在一些可能实施例中，计划优化模块406还用于：判断采集到的元数据是否达到所属分区的数据处理条数门限和数据处理空间门限中的至少一项；如果是，根据元数据以及各分区的数据处理条数门限和数据处理空间门限对本地计划的执行分区进行优化。

本发明实施例所提供的装置，其实现原理及产生的技术效果和前述方法实施例相同，为简要描述，装置实施例部分未提及之处，可参考前述方法实施例中相应内容。

本实施例还提供一种计划优化系统，包括：处理器和存储装置；存储装置上存储有计算机程序，计算机程序在被处理器运行时执行如实施例一任一项的方法。

本实施例还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器运行时执行上述实施例一任一项的方法的步骤。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。