CN114936223A - 数据处理方法、装置、设备和存储介质 - Google Patents

Abstract

本申请公开了一种数据处理方法、装置、设备和存储介质。该数据处理方法基于计算节点的执行资源，执行第一任务和第二任务，并构建与计算节点对应的运行数据过滤器，第一任务为多个阶段中第一阶段的任务，第二任务为多个阶段中第二阶段的至少部分任务；在第一阶段执行结束且运行数据过滤器构建完成的情况下，获取第二任务的执行状态；在执行状态表征第二任务未执行结束的情况下，执行第三任务，得到第二阶段中与第二任务对应的执行结果，第三任务为通过运行数据过滤器过滤第二任务后的任务。根据本申请实施例提供的数据处理方法，能够优化Join的查询性能，缩短查询整体的运行时间。

Description

数据处理方法、装置、设备和存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种数据处理方法、装置、设备和存储介质。

背景技术

在数据库的数据查询过程中，连接操作(Join)是根据两个或多个表之间的关系，将这些表连接起来以从这些表中查询数据的过程。其中，可以通过运行数据过滤器(Runtime Filter)在探测端提前过滤掉不会命中Join的输入数据，以减少数据传输和计算，从而缩短查询整体的运行时间。

然而，在通过整体同步并行计算模型(Bulk Synchronous Parallel ComputingModel，BSP)实现Runtime Filter的过程中，往往使用复制子查询的方式去解决调度上存在数据库可用性组(Database Availability Group，DAG)依赖的问题，使得大量待计算的资源在等待Runtime Filter的构建，延长了数据查询的运行时间以及降低了资源利用率。

发明内容

本申请实施例提供一种基于数据处理方法、装置、设备和存储介质，能够优化Join的查询性能，缩短数据查询的运行时间，以提升数据库的资源利用率。

根据本申请实施例的第一方面，提供一种数据处理方法，包括：

基于计算节点的执行资源，执行第一任务和第二任务，并构建与计算节点对应的运行数据过滤器，第一任务为多个阶段中第一阶段的任务，第二任务为多个阶段中第二阶段的至少部分任务；

在第一阶段执行结束且运行数据过滤器构建完成的情况下，获取第二任务的执行状态；

在执行状态表征第二任务未执行结束的情况下，执行第三任务，得到第二阶段中与第二任务对应的执行结果，第三任务为通过运行数据过滤器过滤第二任务后的任务。

根据本申请实施例的第二方面，提供一种数据处理装置，包括：

处理模块，用于基于计算节点的执行资源，执行第一任务和第二任务，并构建与计算节点对应的运行数据过滤器，第一任务为多个阶段中第一阶段的任务，第二任务为多个阶段中第二阶段的至少部分任务；

获取模块，用于在第一阶段执行结束且运行数据过滤器构建完成的情况下，获取第二任务的执行状态；

执行模块，用于在执行状态表征第二任务未执行完毕的情况下，执行第三任务，得到第二阶段中与第二任务对应的执行结果，第三任务为通过运行数据过滤器过滤第二任务后的任务。

根据本申请实施例的第三方面，提供一种计算机设备，包括：存储器和处理器；

存储器，用于存储有计算机程序；

处理器，用于执行存储器中存储的计算机程序，计算机程序运行时使得处理器执行如第一方面所示的数据处理方法的步骤。

根据本申请实施例的第四方面，提供一种计算机可读存储介质，计算机可读存储介质上存储程序或指令，在程序或指令被计算机设备执行的情况下，使得计算机设备执行如第一方面所示的数据处理方法的步骤。

根据本申请实施例的第五方面，提供一种计算机程序产品，包括计算机程序，在计算机程序被计算机设备执行的情况下，使得计算机设备执行如第一方面所示的数据处理方法的步骤。

根据本申请实施例中数据处理方法、装置、设备和存储介质，通过计算节点的执行资源，在执行不同阶段、数量的第一任务和第二任务的同时，构建与计算节点对应的运行数据过滤器，这样，将Join资源调度粒度从阶段级别细化到任务级别，使得在执行不同阶段的任务的同时，避免因等待运行数据过滤器构建而造成的Join查询运行时间变大的问题。然后，在第一阶段执行结束且运行数据过滤器构建完成的情况下，获取第二任务的执行状态，在执行状态表征第二任务未执行结束的情况下，执行通过运行数据过滤器过滤第二任务后的第三任务，得到第二阶段中与第二任务对应的执行结果，由此，本申请实施例提供的数据处理方法，通过细化资源调度粒度级别，使得在运行数据过滤器没有构建完成时，也可以执行不同阶段的任务，从而减少等待运行数据过滤器构建的时间，以及，如果运行数据过滤器构建完成，这些第二阶段的第二任务还没有执行完，那么第二任务还可以使用运行数据过滤器进行过滤，这种方式很好的避免了查询串行执行，导致的运行数据过滤器性能回退问题，缩短了查询整体的运行时间，优化了Join数据查询性能。另外，基于上述过程使得数据查询的运行时间相比较没有使用运行数据过滤器也不会有性能下降，在不影响运行数据过滤器效果的情况下，缩短数据查询的运行时间，提升了数据库的资源使用率，从而减少了用户等待数据查询的时间，改善用户体验。

附图说明

从下面结合附图对本申请的具体实施方式的描述中可以更好地理解本申请其中，相同或相似的附图标记表示相同或相似的特征。

图1是示出相关技术中的一种数据查询流程示意图；

图2是示出相关技术中的另一种数据查询流程示意图；

图3是示出根据一个实施例的一种数据处理架构示意图；

图4是示出根据一个实施例的一种数据处理流程示意图；

图5是示出根据一个实施例的一种数据处理方法的流程图；

图6是示出根据一个实施例的一种数据处理装置的结构示意图；

图7是示出根据一个实施例的计算机设备的硬件结构示意图。

具体实施方式

下面将详细描述本申请的各个方面的特征和示例性实施例，为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细描述。应理解，此处所描述的具体实施例仅被配置为解释本申请，并不被配置为限定本申请。对于本领域技术人员来说，本申请可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本申请的示例来提供对本申请更好的理解。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。

在相关技术中，如图1所示，对于一个Join可以分为两个阶段完成，即构造(build)阶段和探测(probe)阶段。其中，Join可以由Join算子执行，build阶段可以由构造端的build算子执行，同理，probe阶段可以由探测端的probe算子执行。具体地，build算子用于构建哈希表，即从纬度表(items)中读取每一行数据，将该行数据关联字段的值使用哈希函数生成哈希值，这个哈希值对应到哈希表中的哈希表目，如果一个哈希值对应到多个哈希表目，则这些哈希表目使用链表数据结构连接起来，使得纬度表中的所有记录都被哈希表中的哈希表目引用或者关联。Probe算子可以从事实表(sales)中读取每一行记录，并基于该行记录关联字段的值，使用build算子中相同的哈希函数生成哈希值，从build算子构造的哈希表中搜索对应的哈希表目，从而进行数据查找。此时，在查找时，可以通过scan算子来定位查找的大概范围，其数据查找顺序为先执行读取items表和读取sales表，再通过Join算子进行数据计算。

这里，为了减少读取sales的数据量，可以通过build算子收集数据，以构建Runtime Filter，并将Runtime Filter作为一个过滤器(Filter)从build算子传递至probe算子，使得probe算子提前过滤那些不会命中Join算子的具体的值，以减少Join算子的数据计算以及多个Join算子之间的数据传输，从而减少整体的运行时间(Run time，RT)。这样，probe算子可以使得从probe算子传输至Join算子的数据从事实表中的全量数据(Allsales rows)变为事实表中的少量数据(Few sales rows)。由于使用了Runtime Filter，使得构建Runtime Filter的过程也成为了一个数据依赖阶段，即上述的执行方式需要先读取items表，再读取sales表，最后执行Join。

基于此，假设a为读取全量sales表的RT，b为读取Runtime Filter后sales RT，c为读取items表的RT，d为Join算子计算的RT。那么在不使用Runtime Filter时，针对一个Join算子整体计算的RT＝max(a,c)+d，或者，有假设sales表数量较多时，一个Join算子整体计算的RT＝max(a,c)+d等价于RT＝a+d。同理，在使用Runtime Filter时，RT＝b+c+d，由此可知，如果b+c需要的RT比a大那么就会增加了等待Runtime Filter构建的时间，延长了数据查询的运行时间，导致Runtime Filter的性能回退。示例性地，如图2所示，在BSP模型中，可以将一个工作(job)拆分成多个阶段(Stage)，每个Stage由一个Join算子执行，由底向上逐个执行stage，在右深树场景下，也需要一个Stage一个Stage的执行，对于每一个Join算子对应的Runtime Filter都需要等待其构建的时间，也使得大量待计算的资源在等待Runtime Filter的构建。因此，上述方式使得BSP计算模型中增加了等待每个Join算子对应的Runtime Filter构建的时间，延长了数据查询的整体运行时间，另外，由于大量待计算的资源需要等待Runtime Filter的构建才能执行查询步骤，从而降低数据库的整体资源使用率。

面对上述问题，本申请实施例提供了一种数据处理方法，通过计算节点的执行资源，在执行不同阶段、数量的第一任务和第二任务的同时，构建与计算节点对应的运行数据过滤器，这样，将Join资源调度粒度从阶段级别细化到任务级别，使得在执行不同阶段的任务的同时，避免因等待运行数据过滤器构建而造成的单个Join查询运行时间变大的问题。然后，在第一阶段执行结束且运行数据过滤器构建完成的情况下，获取第二任务的执行状态，在执行状态表征第二任务未执行结束的情况下，执行通过运行数据过滤器过滤第二任务后的第三任务，得到第二阶段中与第二任务对应的执行结果。

由此，本申请实施例提供的数据处理方法，通过细化资源调度粒度级别，使得在运行数据过滤器没有构建完成时，也可以执行不同阶段的任务，从而减少等待运行数据过滤器构建的时间，以及，如果运行数据过滤器构建完成，这些第二阶段的第二任务还没有执行完，那么第二任务还可以使用运行数据过滤器进行过滤，这种方式很好的避免了查询串行执行，导致的运行数据过滤器性能回退问题，缩短了查询整体的运行时间，优化了Join的数据查询性能。另外，基于上述过程使得数据查询的运行时间相比较没有使用运行数据过滤器也不会有性能下降，在不影响运行数据过滤器效果的情况下，缩短数据查询的运行时间，提升了数据库的资源使用率，从而减少了用户等待数据查询的时间，改善用户体验。

下面结合图3，对本申请实施例提供的数据处理架构进行详细地说明。

在一种或者多种可能的实施例中，如图3所示，本申请实施例提出的数据处理架构包括计算节点301和运行在计算节点301中的多个算子。其中，计算节点301可以为实体的计算器件或者计算算子。计算节点301可以包括执行资源，该执行资源用于确定每次并行执行任务的总数量，以提供计算服务。在本申请实施例中，计算节点301可以包括运行在计算节点301中连接操作(Join)算子3011、构造端的第一算子3012和运行数据过滤器构建算子(Runtime Filter builder)3013、以及探测端的第二算子3014和第三算子3015。

下面分别对运行在计算节点301上多个算子进行详细说明。

Join算子3011，用于与构造端和探测端的各算子(如第一算子3012、运行数据过滤器构建算子3013、第二算子3014和第三算子3015)进行交互，将不同端中的表关联起来，以完成数据库的查询。在一个示例中，分别接收构造端和探测端的各算子发送的数据，并对这些数据进行Join运算(如运算哈希值、比较运算等)。

构造端的第一算子3012，用于读取纬度表的任务，得到与任务对应的执行结果如纬度表中的查询数据。运行数据过滤器构建算子3013，用于构建与计算节点(或者Join算子)对应的运行数据过滤器，进一步地，运行数据过滤器构建算子3013具体可以用于，在第一算子3012读取纬度表中数据的过程中，基于纬度表中数据，在构造端构建运行数据过滤器。在另一个示例中，运行数据过滤器构建算子3013，用于将生成的运行数据过滤器发送到探测端，以便探测端的算子如第二算子3014和第三算子3015基于运行数据过滤器过滤数据，以减少数据的传输和计算的开销。

探测端的第二算子3014，用于在未接收到构造端发送的运行数据过滤器的情况下，读取事实表的任务，得到与任务对应的执行结果如事实表中的查询数据；以及，用于在接收到构造端发送的运行数据过滤器的情况下，通过运行数据过滤器过滤任务，并读取过滤后的事实表的任务。

第三算子3015，用于在接收到构造端发送的运行数据过滤器的情况下，通过第三算子3014中的运行数据过滤器过滤副本任务，并执行过滤后的副本任务，得到与副本任务对应的执行结果如事实表中的查询数据。

基于如图3所示的数据处理架构，下面结合附图4以第一算子为scan1、第二算子为scan2、第三算子为scan3和运行数据过滤器构建算子为Runtime Filter Builder为例，对本申请实施例提供的数据处理方法进行详细地说明。

如图3所示的数据处理架构10可以应用于BSP计算模型，且该数据处理方法可以包括如下两个阶段，即资源调度阶段和推测执行阶段，具体结合图4进行详细说明。

如图4所示，资源调度阶段，是指在BSP计算模型中，每一个stage在执行前，需要进行资源申请，以决定在哪些Join算子上运行。此时，可以将每个stage划分为多个任务(task)，每个stage可以分到不同的scan执行，如第一stage由Scan1执行，第二stage由Scan2执行。这样，在BSP计算模型下，Runtime Filter的数据父子依赖不作为阻塞点，并且将Join算子的资源调度粒度从Stage级别细化到task级别，结合资源调度阶段，避免了Runtime Filter导致的资源利用率下降，从而RT上升的问题。

在一个示例中，一个Scan2(sales)需要100个task并行执行，一个Scan1(items)需要20个task并行执行，假设Join算子的执行资源可以并行执行30个task。首先，基于Join算子的执行资源，通过Scan1读取items的20个第一task，以及通过Scan2读取sales的10个第二task，并基于Runtime Filter Builder构建与Join算子对应的运行数据过滤器。

接着，在第一阶段执行结束即Scan1读取items的20个第一task结束、且运行数据过滤器构建完成的情况下，获取Scan2读取sales的10个第二task的执行状态，此时，执行状态可以包括两种可能的状态：

1)Scan2读取sales的10个第二task执行结束，那么这一批的性能和没使用运行数据过滤器相同；

2)Scan2读取sales的10个第二task未执行结束，可以触发推测执行阶段，即在一个阶段如第二阶段的执行过程中，检测部分task如Scan2读取sales的10个第二task执行速度较慢，可以将未执行结束的任务如Scan2读取sales的10个第二task的副本任务传输至scan3，此时，由于运行数据过滤器已构建完成，所以，也将运行数据过滤器传输至scan3，这样，scan3可以通过运行数据过滤器过滤sales的10个第二task，得到第三task并执行第三任务，这样，只需确定Scan2和Scan3哪一个先执行完就使用哪一个的执行结果，由此，可以避免因等待运行数据过滤器的构建而造成的单个查询RT变长，导致的每个stage之间查询运行时间变大的问题，提升了这10个task的执行速率，缩短了数据查询的运行时间，这种方式很好的避免了查询串行执行，导致的运行数据过滤器性能回退问题，缩短了查询整体的运行时间，优化了Join的数据查询性能。另外，剩下的90个Scan2(sales)的第四task，因为items的运行数据过滤器构建完成，则Scan2可以使用运行数据过滤器，进一步地缩短数据查询的运行时间，优化了Join的数据查询性能。

然后，将Scan2或者Scan3中输出的执行结果和第四task对应的执行结果作为Join算子的输入数据，以便Join算子进行Join运算。

综上，在传统的BSP计算模型中是采用通过复制子查询的方式进行Join计算，使得父子stage依赖(即需要一个stage一个stage执行)，从而导致在构建Runtime Filter时资源利用不起来的问题。而本申请实施例提供的数据处理方法可以在BSP模型下，在不改动DAG调度层的同时，通过资源调度和推测执行，可以找到一个更小的RT，从而提高资源利用率，在不减少Runtime Filter效果的情况下，避免RT增加和资源使用率下降的问题，从而提升用户查询速度，提升用户体验。另外，通过Join算子的执行资源，在执行不同阶段、数量的第一task和第二task的同时，构建与Join算子对应的运行数据过滤器，这样，将Join算子的资源调度粒度从阶段级别细化到任务级别，使得在执行不同阶段的任务的同时，避免因等待运行数据过滤器构建而造成的单个Join算子查询运行时间变大的问题。然后，在第一stage执行结束且运行数据过滤器构建完成的情况下，获取第二task的执行状态，在执行状态表征第二task未执行结束的情况下，执行通过运行数据过滤器过滤第二task后的第三task，得到第二stage中与第二task对应的执行结果，进一步地缩短数据查询的运行时间，优化了Join的数据查询性能。

需要说明的是，本申请实施例提供的数据处理方法是以一个Join算子为例进行说明，也可以应用于整个查询的执行为串行执行的场景即右深树场景，相比于相关技术的右深树场景中Runtime Filter作为强依赖，一直等待完成Runtime Filter的构建，查询的执行将会变成完全的串行执行，使得整个查询RT上涨的情况，本申请实施例提供的数据处理方法细化了调度的粒度是Task的级别，当资源充足时，即使没有得到Runtime Filter的信息，Task也开始执行。

如果当Runtime Filter构建完成后，这些Task还没有执行完，那么这些Task还可以在中间状态使用Runtime Filter进行过滤，这种方式很好的避免了查询串行执行的问题，并且查询的RT相比较没有使用Runtime Filter也不会有性能下降。进一步地，可以对右深树场景中每个Join算子都执行本申请实施例提供的数据处理方法，从而使RuntimeFilter可以在线上发挥更大的作用，使得在优化每个Join算子的查询性能，缩短逐个Join算子的数据查询的运行时间的同时，缩短基于多个Join的数据查询的运行时间，从而进一步提升了数据库的资源利用率。

根据上述架构以及应用场景，下面分别结合图5对本申请实施例提供的数据处理方法进行详细说明。

图5是示出根据一个实施例的一种数据处理方法的流程图。

如图5所示，数据处理方法可以应用于如图3所示的数据处理架构，具体可以包括：

步骤510，基于计算节点的执行资源，执行第一任务和第二任务，并构建与计算节点对应的运行数据过滤器；步骤520，在第一阶段执行结束且运行数据过滤器构建完成的情况下，获取第二任务的执行状态；步骤530，在执行状态表征第二任务未执行结束的情况下，执行第三任务，得到第二阶段中与第二任务对应的执行结果，第三任务为通过运行数据过滤器过滤第二任务后的任务。

下面对上述步骤进行详细说明，具体如下所示。

涉及步骤510，第一任务为多个阶段中第一阶段的任务，第二任务为多个阶段中第二阶段的至少部分任务。

在一种或者多种可能的示例中，该步骤510具体可以包括：

获取多个阶段中每个阶段的任务数量；

基于执行资源和每个阶段的任务数量，生成资源调度信息，资源调度信息用于指示每次并行执行任务的总数量，以及每次执行两个阶段的任务的数量，两个阶段包括第一阶段和第二计算；

按照资源调度信息，执行第一任务和第二任务。

示例性地，仍参照图4中的例子，若Join算子的执行资源可以一次并行执行30个task，则每次执行两个阶段的任务的数量为第一阶段的20个第一任务，以及第二阶段的10个第二任务。

进一步地，在计算节点对应构造端的第一算子和探测端的第二算子的情况下，该步骤510具体可以包括：

通过第一算子读取纬度表的第一任务，以及通过第二算子读取事实表的第二任务；并在第一算子读取纬度表中数据的过程中，基于纬度表中数据，在构造端构建运行数据过滤器。

涉及步骤520，获取第二任务的执行状态。这里，执行状态可以包括两种可能的状态，即执行状态表征第二任务未执行结束的情况，或者执行状态表征第二任务执行结束的情况。

此时，若执行状态表征第二任务未执行结束，则可以执行步骤530。

反之，若执行状态表征第二任务执行结束，则执行如下步骤5201至步骤5202，具体如下所示。

步骤5201，获取第二阶段中的第四任务，并将运行数据过滤器从构造端传输至第二算子；基于执行资源，执行通过第二算子中的运行数据过滤器过滤第四任务后的第五任务，得到第二阶段中与第四任务对应的执行结果。

涉及步骤530，在一种或者多种可能的示例中，基于步骤510中的计算节点对应构造端探测端的第三算子，该步骤530具体可以包括：

将运行数据过滤器从构造端传输至第三算子，以及将第二任务的副本任务传输至第三算子；

通过第三算子中的运行数据过滤器过滤第二任务的副本任务，得到第三任务；

执行第三任务，得到第二阶段中与第二任务对应的执行结果。

示例性地，仍参照图4中的例子，如果一个Runtime Filter是可以下推存储的，那么可能在存储的过滤效率会优于在计算层通过布隆过滤器(Bloom Filter)，散列集合(hash set)等的过滤，并且可以减少磁盘I/O的资源开销，但是，对于已经执行的Scan2读取sales的10个第二task，因为已经开始从存储读数据了，所以不能在将Runtime Filter再下推存储，所以，可以借助推测执行的能力，在向其他算子如scan3发送相同的10个第二task，新增的10个task是下推存储的，新增的先执行完就采用新增task的执行结果。

由此，在BSP计算模型下，Runtime Filter的数据父子依赖不作为阻塞点，并且将资源调度粒度从Stage级别细化到task级别，结合资源调度阶段，避免了Runtime Filter导致的资源利用率下降，从而RT上升的问题。结合推测执行阶段，避免了部分Task的RuntimeFilter不能下推存储，从而导致Runtime Filter效果下降的问题。基于此，在步骤530之后，本申请实施例提供的数据处理方法还可以包括：

步骤540，在第二算子和第三算子中，确定目标算子，目标算子为最早输出与第二任务对应的执行结果的算子；

步骤550，将目标算子的输出的执行结果作为计算节点中连接操作算子的输入数据。

此外，第二阶段还包括第四任务(即第二阶段剩余的任务)的情况下，上述步骤550具体可以包括：

将目标算子的输出的执行结果和第四任务对应的执行结果作为计算节点中连接操作算子的输入数据。

需要说明的是，可以通过如下步骤确定第四任务对应的执行结果，即在上述涉及的将目标算子的输出的执行结果和第四任务对应的执行结果作为计算节点的输入数据的步骤前之前，本申请实施例提供的数据处理方法还可以包括：

获取第四任务，并将运行数据过滤器从构造端传输至第二算子；

基于执行资源，执行通过第二算子中的运行数据过滤器过滤第四任务后的第五任务，得到第二阶段中与第四任务对应的执行结果。

综上，通过计算节点的执行资源，在执行不同阶段、数量的第一任务和第二任务的同时，构建与计算节点对应的运行数据过滤器，这样，将Join的资源调度粒度从阶段级别细化到任务级别，使得在执行不同阶段的任务的同时，避免因等待运行数据过滤器构建而造成的单个Join查询运行时间变大的问题。然后，在第一阶段执行结束且运行数据过滤器构建完成的情况下，获取第二任务的执行状态，在执行状态表征第二任务未执行结束的情况下，执行通过运行数据过滤器过滤第二任务后的第三任务，得到第二阶段中与第二任务对应的执行结果，由此，本申请实施例提供的数据处理方法，通过细化资源调度粒度级别，使得在运行数据过滤器没有构建完成时，也可以执行不同阶段的任务，从而减少等待运行数据过滤器构建的时间，以及，如果运行数据过滤器构建完成，这些第二阶段的第二任务还没有执行完，那么第二任务还可以使用运行数据过滤器进行过滤，这种方式很好的避免了查询串行执行，导致的运行数据过滤器性能回退问题，缩短了查询整体的运行时间，优化了Join的数据查询性能。

另外，基于上述过程使得数据查询的运行时间相比较没有使用运行数据过滤器也不会有性能下降，在不影响运行数据过滤器效果的情况下，缩短数据查询的运行时间，提升了数据库的资源使用率，从而减少了用户等待数据查询的时间，改善用户体验。

需要明确的是，本申请并不局限于上文实施例中所描述并在图中示出的特定配置和处理。为了描述的方便和简洁，这里省略了对已知方法的详细描述，并且上述描述的系统、模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

基于相同的发明构思，本申请实施例提供了与上述涉及的数据处理方法对应的数据处理装置。具体结合图6进行详细说明。

图6是示出根据一个实施例的一种数据处理装置的结构示意图。

如图6所示，数据处理装置60应用于如图3所示的数据处理架构，数据处理装置60具体可以包括：

处理模块601，用于基于计算节点的执行资源，执行第一任务和第二任务，并构建与计算节点对应的运行数据过滤器，第一任务为多个阶段中第一阶段的任务，第二任务为多个阶段中第二阶段的至少部分任务；

获取模块602，用于在第一阶段执行结束且运行数据过滤器构建完成的情况下，获取第二任务的执行状态；

执行模块603，用于在执行状态表征第二任务未执行完毕的情况下，执行第三任务，得到第二阶段中与第二任务对应的执行结果，第三任务为通过运行数据过滤器过滤第二任务后的任务。

基于此，下面对本申请实施例提供的数据处理装置60进行详细说明。

在一种或者多种可能的实施例中，本申请实施例提供的数据处理装置60还可以包括生成模块；其中，

获取模块602还用于，获取多个阶段中每个阶段的任务数量；

生成模块，用于基于执行资源和每个阶段的任务数量，生成资源调度信息，资源调度信息用于指示每次并行执行任务的总数量，以及每次执行两个阶段的任务的数量，两个阶段包括第一阶段和第二计算；

处理模块601还可以用于，按照资源调度信息，执行第一任务和第二任务。

在另一种或者多种可能的实施例中，处理模块601具体可以用于，在计算节点对应构造端的第一算子和探测端的第二算子的情况下，通过第一算子读取纬度表的第一任务，以及通过第二算子读取事实表的第二任务。

在又一种或者多种可能的实施例中，处理模块601具体可以用于，在第一算子读取纬度表中数据的过程中，基于纬度表中数据，在构造端构建运行数据过滤器。

在再一种或者多种可能的实施例中，本申请实施例提供的数据处理装置60还可以包括传输模块和过滤模块；其中，

传输模块，用于在计算节点对应构造端探测端的第三算子的情况下，将运行数据过滤器从构造端传输至第三算子，以及将第二任务的副本任务传输至第三算子；

过滤模块，用于通过第三算子中的运行数据过滤器过滤第二任务的副本任务，得到第三任务；

执行模块603具体可以用于，执行第三任务，得到第二阶段中与第二任务对应的执行结果。

在再一种或者多种可能的实施例中，本申请实施例提供的数据处理装置60还可以包括确定模块，用于在第二算子和第三算子中，确定目标算子，目标算子为最早输出与第二任务对应的执行结果的算子；

将目标算子的输出的执行结果作为计算节点中连接操作算子的输入数据。

进一步地，确定模块具体可以用于，在第二阶段还包括第四任务的情况下，将目标算子的输出的执行结果和第四任务对应的执行结果作为计算节点中连接操作算子的输入数据。

在再一种或者多种可能的实施例中，获取模块602还可以用于，获取第四任务，以及传输模块还可以用于，将运行数据过滤器从构造端传输至第二算子；

执行模块603还可以用于，基于执行资源，执行通过第二算子中的运行数据过滤器过滤第四任务后的第五任务，得到第二阶段中与第四任务对应的执行结果。

由此，通过计算节点的执行资源，在执行不同阶段、数量的第一任务和第二任务的同时，构建与计算节点对应的运行数据过滤器，这样，将Join的资源调度粒度从阶段级别细化到任务级别，使得在执行不同阶段的任务的同时，避免因等待运行数据过滤器构建而造成的单个Join查询运行时间变大的问题。然后，在第一阶段执行结束且运行数据过滤器构建完成的情况下，获取第二任务的执行状态，在执行状态表征第二任务未执行结束的情况下，执行通过运行数据过滤器过滤第二任务后的第三任务，得到第二阶段中与第二任务对应的执行结果，由此，本申请实施例提供的数据处理方法，通过细化资源调度粒度级别，使得在运行数据过滤器没有构建完成时，也可以执行不同阶段的任务，从而减少等待运行数据过滤器构建的时间，以及，如果运行数据过滤器构建完成，这些第二阶段的第二任务还没有执行完，那么第二任务还可以使用运行数据过滤器进行过滤，这种方式很好的避免了查询串行执行，导致的运行数据过滤器性能回退问题，缩短了查询整体的运行时间，优化了Join的数据查询性能。另外，基于上述过程使得数据查询的运行时间相比较没有使用运行数据过滤器也不会有性能下降，在不影响运行数据过滤器效果的情况下，缩短数据查询的运行时间，提升了数据库的资源使用率，从而减少了用户等待数据查询的时间，改善用户体验。

图7是示出根据一个实施例的计算机设备的硬件结构示意图。

如图7所示，计算机设备700包括输入设备701、输入接口702、处理器703、存储器704、输出接口705、以及输出设备706。

输入接口702、处理器703、存储器704、以及输出接口705通过总线710相互连接，输入设备701和输出设备706分别通过输入接口702和输出接口705与总线710连接，进而与计算机设备700的其他组件连接。具体地，输入设备701接收来自外部的输入信息，并通过输入接口702将输入信息传送到处理器703；处理器703基于存储器704中存储的计算机可执行指令对输入信息进行处理以生成输出信息，将输出信息临时或者永久地存储在存储器704中，然后通过输出接口705将输出信息传送到输出设备706；输出设备706将输出信息输出到计算机设备700的外部供用户使用。

在一个实施例中，图7所示的计算机设备700可以被实现为一种数据处理设备，该数据处理设备可以包括：存储器，被配置为存储程序；处理器，被配置为运行存储器中存储的程序，以执行上述实施例描述的数据处理方法。

在一个实施例中，该存储器还可以用于存储执行资源、第一任务、第二任务以及结合上述图3至图5描述的数据处理过程中每个步骤的计算结果。

根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机可读存储介质。例如，本申请的实施例包括一种计算机可读存储介质，其包括在计算机可读存储介质上存储程序或指令，在程序或指令被计算机设备执行的情况下，使得计算机设备执行上述方法的步骤。

根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括有形地包含在机器可读介质上的计算机程序，计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以从网络上被下载和安装，和/或从可拆卸存储介质被安装。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令，当其在计算机上运行时，使得计算机执行上述各个实施例中描述的方法。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘)等。

以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

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

Claims (12)

1.一种数据处理方法，包括：

基于计算节点的执行资源，执行第一任务和第二任务，并构建与所述计算节点对应的运行数据过滤器，所述第一任务为多个阶段中第一阶段的任务，所述第二任务为所述多个阶段中第二阶段的至少部分任务；

在所述第一阶段执行结束且所述运行数据过滤器构建完成的情况下，获取所述第二任务的执行状态；

在所述执行状态表征所述第二任务未执行结束的情况下，执行第三任务，得到所述第二阶段中与所述第二任务对应的执行结果，所述第三任务为通过所述运行数据过滤器过滤所述第二任务后的任务。

2.根据权利要求1所述的方法，其中，所述基于计算节点的执行资源，执行第一任务和第二任务，包括：

获取所述多个阶段中每个阶段的任务数量；

基于所述执行资源和所述每个阶段的任务数量，生成资源调度信息，所述资源调度信息用于指示每次并行执行任务的总数量，以及每次执行两个阶段的任务的数量，所述两个阶段包括所述第一阶段和所述第二计算；

按照所述资源调度信息，执行第一任务和第二任务。

3.根据权利要求1或2所述的方法，其中，所述计算节点对应构造端的第一算子和探测端的第二算子；所述执行第一任务和第二任务，包括：

通过所述第一算子读取纬度表的第一任务，以及通过所述第二算子读取事实表的第二任务。

4.根据权利要求3所述的方法，其中，所述构建与所述计算节点对应的运行数据过滤器，包括：

在所述第一算子读取所述纬度表中数据的过程中，基于所述纬度表中数据，在所述构造端构建所述运行数据过滤器。

5.根据权利要求3所述的方法，其中，所述计算节点对应所述构造端探测端的第三算子；所述执行第三任务，得到所述第二阶段中与所述第二任务对应的执行结果，包括：

将所述运行数据过滤器从所述构造端传输至所述第三算子，以及将所述第二任务的副本任务传输至所述第三算子；

通过所述第三算子中的运行数据过滤器过滤所述第二任务的副本任务，得到第三任务；

执行所述第三任务，得到所述第二阶段中与所述第二任务对应的执行结果。

6.根据权利要求5所述的方法，其中，所述方法还包括：

在所述第二算子和所述第三算子中，确定目标算子，所述目标算子为最早输出与所述第二任务对应的执行结果的算子；

将所述目标算子的输出的执行结果作为所述计算节点中连接操作算子的输入数据。

7.根据权利要求6所述的方法，其中，所述第二阶段还包括第四任务；所述将所述目标算子的输出的执行结果作为所述计算节点中连接操作算子的输入数据，包括：

将所述目标算子的输出的执行结果和所述第四任务对应的执行结果作为所述连接操作算子的输入数据。

8.根据权利要求7所述的方法，其中，所述方法还包括：

获取所述第四任务，并将所述运行数据过滤器从所述构造端传输至所述第二算子；

基于所述执行资源，执行通过所述第二算子中的运行数据过滤器过滤所述第四任务后的第五任务，得到所述第二阶段中与所述第四任务对应的执行结果。

9.一种数据处理装置，包括：

处理模块，用于基于计算节点的执行资源，执行第一任务和第二任务，并构建与所述计算节点对应的运行数据过滤器，所述第一任务为多个阶段中第一阶段的任务，所述第二任务为所述多个阶段中第二阶段的至少部分任务；

获取模块，用于在所述第一阶段执行结束且所述运行数据过滤器构建完成的情况下，获取所述第二任务的执行状态；

执行模块，用于在所述执行状态表征所述第二任务未执行完毕的情况下，执行第三任务，得到所述第二阶段中与所述第二任务对应的执行结果，所述第三任务为通过所述运行数据过滤器过滤所述第二任务后的任务。

10.一种计算机设备，包括：存储器和处理器，

所述存储器，用于存储有计算机程序；

所述处理器，用于执行所述存储器中存储的计算机程序，所述计算机程序运行时使得所述处理器执行权利要求1至8中任意一项所述的数据处理方法的步骤。

11.一种计算机可读存储介质，所述计算机可读存储介质上存储程序或指令，在所述程序或指令被计算机设备执行的情况下，使得所述计算机设备执行如权利要求1至8中任意一项所述的数据处理方法的步骤。

12.一种计算机程序产品，包括计算机程序，在所述计算机程序被计算机设备执行的情况下，使得所述计算机设备执行如权利要求1至8中任意一项所述的数据处理方法的步骤。

Images