CN114168334A

CN114168334A - 一种基于Spark框架的Executor分配方法、装置、设备及存储介质

Info

Publication number: CN114168334A
Application number: CN202111497024.9A
Authority: CN
Inventors: 付仲明; 何梦思; 罗凌云; 丁平尖; 朱涛; 万亚平
Original assignee: University of South China
Current assignee: University of South China
Priority date: 2021-12-09
Filing date: 2021-12-09
Publication date: 2022-03-11

Abstract

本申请公开了一种基于Spark框架的Executor分配方法、装置、设备及存储介质，包括：确定Map阶段全部Map任务分别在Spark框架中每个第一空闲节点获取相应数据块的通信代价，以得到每个所述第一空闲节点对应的第一通信代价；按照所述第一通信代价的大小顺序对全部所述第一空闲节点进行排序，并依次在排序后的所述第一空闲节点上分配所述第一空闲节点的最大可用Executor数量个第一Executor；当分配的所述第一Executor总数量为第一所需Executor数量时，停止分配所述第一Executor得到所述Map阶段执行所述Map任务的包含当前已分配的所述第一Executor的第一Executor集合。可见，本申请将Executor分配在靠近输入数据块所在的节点上，能够改善Spark任务调度中的数据本地性，有效降低任务的网络流量和数据访问延迟。

Description

一种基于Spark框架的Executor分配方法、装置、设备及存储介质

技术领域

本发明涉及计算机技术领域，特别涉及一种基于Spark框架的Executor分配方法、装置、设备及存储介质。

背景技术

随着大数据时代应用的响应要求越来越高，新兴的Spark分布式计算框架以优异的特性引起了极大关注并得到广泛使用，例如Goggle、Yahoo！、百度、腾讯等。与Hadoop和其他分布式计算框架相比，Spark引入弹性分布式数据集(RDD)的概念，它可以利用内存计算高效地执行作业，特别是对于迭代计算。Spark应用程序在执行计算逻辑的过程中产生的大量数据传输会延长任务运行时间，导致集群网络拥塞，从而影响系统的性能。

因此，如何解决Spark应用程序的网络通信瓶颈是本领域技术人员亟待解决的技术问题。

发明内容

有鉴于此，本发明的目的在于提供一种基于Spark框架的Executor分配方法、装置、设备及存储介质，能够改善Spark任务调度中的数据本地性，有效降低任务的网络流量和数据访问延迟。其具体方案如下：

本申请的第一方面提供了一种基于Spark框架的Executor分配方法，包括：

确定Map阶段全部Map任务分别在Spark框架中每个第一空闲节点获取相应数据块的通信代价，以得到每个所述第一空闲节点对应的第一通信代价；

按照所述第一通信代价的大小顺序对全部所述第一空闲节点进行排序，并依次在排序后的所述第一空闲节点上分配所述第一空闲节点的最大可用Executor数量个第一Executor；

当分配的所述第一Executor总数量为第一所需Executor数量时，停止分配所述第一Executor得到所述Map阶段执行所述Map任务的包含当前已分配的所述第一Executor的第一Executor集合。

可选的，所述确定Map阶段全部Map任务分别在Spark框架中每个第一空闲节点获取相应数据块的通信代价，以得到每个所述第一空闲节点对应的第一通信代价，包括：

确定所述Map阶段每个所述Map任务分别在Spark框架中每个所述第一空闲节点获取相应数据块的第二通信代价；

将每个所述第一空闲节点上的所述第二通信代价进行求和运算以得到每个所述第一空闲节点对应的所述第一通信代价。

可选的，所述第二通信代价与所述数据块大小及所述Map任务所在第一空闲节点至所述数据块所在节点之间的网络距离呈正相关关系。

可选的，所述确定所述Map阶段每个所述Map任务分别在Spark框架中每个所述第一空闲节点获取相应数据块的第二通信代价，包括：

分别确定所述Map阶段每个所述Map任务所在第一空闲节点至所述数据块的多个副本所在节点的所述网络距离；其中，所述数据块以多个副本的形式进行存储；

将所述Map任务在所述第一空闲节点获取所述网络距离最小的节点上的副本的通信代价确定为所述第二通信代价。

可选的，所述当分配的所述第一Executor总数量为所需Executor数量时，停止分配Executor得到所述Map阶段执行所述Map任务的包含当前已分配的所述第一Executor的第一Executor集合之后，还包括：

确定Reduce阶段全部Reduce任务分别在Spark框架中每个第二空闲节点获取相应分区数据的通信代价，以得到每个所述第二空闲节点对应的第三通信代价；所述分区数据为将所述Map阶段中每个所述Map任务输出的中间数据按照bucket类型划分为与Reduce任务数量一致的区域后得到的分区中的数据；

按照所述第三通信代价的大小顺序对全部所述第二空闲节点进行排序，并依次在排序后的所述第二空闲节点上分配所述第二空闲节点的最大可用Executor数量个第二Executor；

当分配的所述第二Executor总数量为第二所需Executor数量时，停止分配所述第二Executor得到所述Reduce阶段执行所述Reduce任务的包含当前已分配的所述第二Executor的第二Executor集合。

可选的，所述确定Reduce阶段全部Reduce任务分别在Spark框架中每个第二空闲节点获取相应分区数据的通信代价，以得到每个所述第二空闲节点对应的第三通信代价，包括：

确定所述Reduce阶段每个所述Reduce任务分别在Spark框架中每个所述第二空闲节点获取相应所述分区数据的第四通信代价；

将每个所述第二空闲节点上的所述第四通信代价进行求和运算以得到每个所述第二空闲节点对应的所述第三通信代价。

可选的，所述第四通信代价与每个分区中的所述中间数据的数据大小及所述Reduce任务所在第二空闲节点至每个分区中的所述中间数据所在节点之间的网络距离呈正相关关系。

本申请的第二方面提供了一种基于Spark框架的Executor分配装置，包括：

第一确定模块，用于确定Map阶段全部Map任务分别在Spark框架中每个第一空闲节点获取相应数据块的通信代价，以得到每个所述第一空闲节点对应的第一通信代价；

第一分配模块，用于按照所述第一通信代价的大小顺序对全部所述第一空闲节点进行排序，并依次在排序后的所述第一空闲节点上分配所述第一空闲节点的最大可用Executor数量个第一Executor；

第一生成模块，用于当分配的所述第一Executor总数量为第一所需Executor数量时，停止分配所述第一Executor得到所述Map阶段执行所述Map任务的包含当前已分配的所述第一Executor的第一Executor集合。

本申请的第三方面提供了一种电子设备，所述电子设备包括处理器和存储器；其中所述存储器用于存储计算机程序，所述计算机程序由所述处理器加载并执行以实现前述基于Spark框架的Executor分配方法。

本申请的第四方面提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机可执行指令，所述计算机可执行指令被处理器加载并执行时，实现前述基于Spark框架的Executor分配方法。

本申请中，先确定Map阶段全部Map任务分别在Spark框架中每个第一空闲节点获取相应数据块的通信代价，以得到每个所述第一空闲节点对应的第一通信代价；然后按照所述第一通信代价的大小顺序对全部所述第一空闲节点进行排序，并依次在排序后的所述第一空闲节点上分配所述第一空闲节点的最大可用Executor数量个第一Executor；最后当分配的所述第一Executor总数量为第一所需Executor数量时，停止分配所述第一Executor得到所述Map阶段执行所述Map任务的包含当前已分配的所述第一Executor的第一Executor集合。可见，本申请将Executor分配在靠近输入数据块所在的节点上，能够改善Spark任务调度中的数据本地性，有效降低任务的网络流量和数据访问延迟。

附图说明

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

图1为本申请提供的一种基于Spark框架的Executor分配方法流程图；

图2为本申请提供的一种Spark运行程序的有向无环图；

图3为本申请提供的一种基于Spark框架的Executor分配装置结构示意图；

图4为本申请提供的一种基于Spark框架的Executor分配电子设备结构图。

具体实施方式

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

现有技术中Spark提供spreadOut和noSpreadOut两种Executor分配算法来决定Executor在哪些节点上启动。然而不同于Hadoop框架，Spark中的任务以多线程的方式并行运行在Executor中。作为任务的执行容器，Executor的位置会直接影响任务的本地性获取，spreadOut和noSpreadOut都没有充分考虑数据本地性因素，使得网络通信效率较低。针对上述技术缺陷，本申请提供一种基于Spark框架的Executor分配方案，将将Executor分配在靠近输入数据块所在的节点上，能够改善Spark任务调度中的数据本地性，有效降低任务的网络流量和数据访问延迟。

图1为本申请实施例提供的一种基于Spark框架的Executor分配方法流程图。参见图1所示，该基于Spark框架的Executor分配方法包括：

S11：确定Map阶段全部Map任务分别在Spark框架中每个第一空闲节点获取相应数据块的通信代价，以得到每个所述第一空闲节点对应的第一通信代价。

Spark应用程序在计算逻辑上形成一个有向无环图(DAG)，其根据RDD的血缘关系由许多个阶段组成。从MapReduce编程模型角度来看，可以将这些阶段分为两种类型，即Map阶段和Reduce阶段。如图2所示，在Map阶段，一个RDD的分区对应其父RDD的一个分区，即Stage1和Stage3。在Reduce阶段，一个RDD的分区对应其父RDD的多个分区，即Stage2和Stage4。一个Map任务和一个Reduce任务负责计算RDD的一个分区，它们在获取输入数据时都可能导致大量的数据传输。在Map阶段，如果任务和数据块在不同节点上，那么任务就会跨节点/机架读取数据。在Reduce阶段，任务从前一阶段的所有任务输出中拉取其所属的部分中间数据，称为Shuffle，这是一种多对多的通信模式。以上两个阶段产生的大量数据传输会延长任务运行时间，导致集群网络拥塞，从而影响系统的性能。为了解决以上网络通信瓶颈，Spark在Map和Reduce两种阶段任务调度中将数据本地性作为主要考虑因素。数据本地性是指让计算/任务靠近数据，从而减少传输延迟和网络I/O开销。

不难理解，如果Executor启动在远离输入输入数据块所在的节点上，那么Map任务将很难从本地访问数据。本实施例中，任务调度器在Map阶段使用经典的延迟调度算法，它尽量将Map任务分配到数据块所在的节点上，以避免远程数据拷贝。因此，确定Map阶段全部Map任务分别在Spark框架中每个第一空闲节点获取相应数据块的通信代价，以得到每个所述第一空闲节点对应的第一通信代价。具体来说，首先确定所述Map阶段每个所述Map任务分别在Spark框架中每个所述第一空闲节点获取相应数据块的第二通信代价；然后将每个所述第一空闲节点上的所述第二通信代价进行求和运算以得到每个所述第一空闲节点对应的所述第一通信代价。

其中，所述第二通信代价与所述数据块大小及所述Map任务所在第一空闲节点至所述数据块所在节点之间的网络距离呈正相关关系。所述数据块一般以多个副本的形式存在，在Spark框架中，任务会获取离它网络距离最近的数据块，也即，分别确定所述Map阶段每个所述Map任务所在第一空闲节点至所述数据块的多个副本所在节点的所述网络距离。在此基础上将所述Map任务在所述第一空闲节点获取所述网络距离最小的节点上的副本的通信代价确定为所述第二通信代价。

为了便于理解，结合数据模型对本实施例方案进行说明，表1中为一些重要变量声明。

表1变量声明

在Map阶段，每个Map任务负责处理一个数据块并输出中间数据到本地磁盘。首先，Spark分布式计算集群的网络拓扑可以形式化为节点集合NS＝{N₀,N₁,…,N_α-1}和机架集合RS＝{R₀,R₁,…,R_β-1}，1≤β≤α。对于任意节点N_l，N_l位于机架R_r，r∈{0,1,…,β-1}。。在Map阶段分配Executor的初始状态时，将一些特定的数据结构形式化如下：

NS_map为包含n_1个允许启动Executor的空闲节点，是NS的一个子集合。其元素N_i表示第i个空闲节点，它的剩余CPU和内存容量分别表示为free_cpu_i和free_memory_i。因此，每个节点上允许启动的Executor数量可以计算为：

其中，

是节点N_i上允许启动的Executor的数量，cpu_conf和memory_conf是每个Executor配置的CPU数量和内存容量。例如，节点N_i的剩余资源量是5个CPU和16GB的内存，每个Executor要求配置2个CPU和4GB内存，则该节点上允许启动的Executor数量计算为：

BK是长度为m₁的向量，其元素b_j表示第j个数据块。HDFS中数据集被划分为许多个数据块，并且每个块被复制多次，可以将其表示为b_j＝{b_j0,b_j1,…,b_j(λ-1)}，通常复制因子λ＝3。MT为一组Map任务的集合，其元素t_j表示处理相应数据块b_j的第j个任务。因为每个Map任务负责一个数据块，所以任务的数量等于m₁。在任务调度时，每个Map任务都有可能被调度到任意节点的一个Executor中运行。为了感知数据本地性，我们定义当每个Map任务从不同节点获取数据块时的通信代价，表示为一个n₁×m₁的矩阵CM：

其中，c_i,j表示当分配任务t_j到节点N_i时获取数据块b_j的通信代价。

对于网络数据传输，通信代价取决于两个因素：数据传输量和网络距离，即数据量越少，网络距离越短，通信开销越小，反之亦然。因此，通信代价c_i,j可以计算为：

c_i,j＝d(i,j)×|b_j|

其中，d(i,j)是数据块b_j和节点N_i之间的网络距离，|b_j|是数据块的大小。根据HDFS的分割策略，每个数据块的大小默认为128MB，除了切割剩下的最后一块。但是在一些特殊情况下，还是需要考虑数据块大小的不一致，因为一些不可分割的大记录。

每个数据块b_j都存在λ个副本存储在不同节点，Map任务t_j被分配到N_i上会获取离它最近的副本。因此，距离d(i,j)可以计算为N_i到b_i的最近副本的距离：

d(i,j)＝min{d(i,j0),d(i,j1),…,d(i,j(λ-1))}

其中，d(i,jk)是节点N_i和副本b_jk所在节点之间的网络距离。

此外，可以提前获知数据块在集群节点间的分布，并根据集群的网络拓扑可以预先定义节点之间的网络距离，表示为α×α矩阵D：

D＝[DV₀,DV₁,…,DV_l,…,DV_α-1]^T

并且

DV_l＝[dis_l,0,dis_l,1,…,dis_l,p,…,dis_l,(α-1)]

其中向量DV_l是节点N_l与其他节点之间的网络距离，dis_l,p是节点N_l与N_p之间的网络距离，通常在同一节点上的网络距离为0。

S12：按照所述第一通信代价的大小顺序对全部所述第一空闲节点进行排序，并依次在排序后的所述第一空闲节点上分配所述第一空闲节点的最大可用Executor数量个第一Executor。

S13：当分配的所述第一Executor总数量为第一所需Executor数量时，停止分配所述第一Executor得到所述Map阶段执行所述Map任务的包含当前已分配的所述第一Executor的第一Executor集合。

本实施例中，先按照所述第一通信代价的大小顺序对全部所述第一空闲节点进行排序，然后依次在排序后的所述第一空闲节点上分配所述第一空闲节点的最大可用Executor数量个第一Executor。其中，当分配的所述第一Executor总数量为第一所需Executor数量时，停止分配所述第一Executor得到所述Map阶段执行所述Map任务的包含当前已分配的所述第一Executor的第一Executor集合。

对于单个Map任务t_j，最好的执行位置当该任务运行在节点N_i的一个Executor中时，它可以得到最小的通信代价c_ij。然而对于节点N_i，因为任何一个任务都可以运行在其Executor中，我们应该考虑所有任务的数据本地性，而不是特定的一个任务。基于以上的理论分析，我们定义一个节点N_i所能提供的整体数据本地性等级，表示为data_locality(i)，将NS_map中的空闲节点根据data_localiy的值升序排序，它可以计算为每个任务运行在该节点的Executor中时的通信代价的总和：

其中，m₁是Map任务的数量，n₁是空闲节点的数量。显然，data_locality(i)的值越大通信代价就越大，所以节点N_i所能提供的整体数据本地性越差，反之亦然。具体地在Map阶段，data_locality(i)可以进一步计算为：

在以上模型基础，为了给任务提供更好的数据本地性，一个Executor启动在某个节点上需要靠近输入数据，也就是说，所有任务运行在该Executor上时都可以获得较低的通信代价。假设需要的Executor数量为u，所选择启动的Executor集合为SE＝{e₀,e₁,…,e_u-1}，那么最优的Executor分配方案可以形式化为：

其中，cost(e_k)表示所有Map任务运行在Executore_k中的通信代价总和，它可以进一步计算为：

其中，

是当任务t_j运行在Executore_k中时，获取数据块b_j的通信代价。假设e_k启动在节点N_i上，记为

则有：

本实施例中，在Reduce阶段，它调度任务到存储有大部分中间数据所在的节点上，以减少远程数据传输量。由Map阶段产生的中间数据被分区器(例如Hash和Range)划分，然后在Reduce阶段，每个Reduce任务从前一个阶段的所有Map任务输出中拉取其所属的部分中间数据。这是一种网络间的多对多的通信模式。

确定Reduce阶段全部Reduce任务分别在Spark框架中每个第二空闲节点获取相应分区数据的通信代价，以得到每个所述第二空闲节点对应的第三通信代价；所述分区数据为将所述Map阶段中每个所述Map任务输出的中间数据按照bucket类型划分为与Reduce任务数量一致的区域后得到的分区中的数据。相应的，先确定Reduce阶段全部Reduce任务分别在Spark框架中每个第二空闲节点获取相应分区数据的通信代价，以得到每个所述第二空闲节点对应的第三通信代价；所述分区数据为将所述Map阶段中每个所述Map任务输出的中间数据按照bucket类型划分为与Reduce任务数量一致的区域后得到的分区中的数据。然后按照所述第三通信代价的大小顺序对全部所述第二空闲节点进行排序，并依次在排序后的所述第二空闲节点上分配所述第二空闲节点的最大可用Executor数量个第二Executor。当分配的所述第二Executor总数量为第二所需Executor数量时，停止分配所述第二Executor得到所述Reduce阶段执行所述Reduce任务的包含当前已分配的所述第二Executor的第二Executor集合。关于所述第三通信代价的确定过程具体为：先确定所述Reduce阶段每个所述Reduce任务分别在Spark框架中每个所述第二空闲节点获取相应所述分区数据的第四通信代价，然后将每个所述第二空闲节点上的所述第四通信代价进行求和运算以得到每个所述第二空闲节点对应的所述第三通信代价。其中，所述第四通信代价与每个分区中的所述中间数据的数据大小及所述Reduce任务所在第二空闲节点至每个分区中的所述中间数据所在节点之间的网络距离呈正相关关系。

同样结合数据模型对本实施例方案进行说明，表2中为一些重要变量声明。

表2变量声明

Spark中作业的阶段按顺序执行，也就是说Reduce任务的启动需要等到前一个阶段的所有任务结束后才开始。在Redcue阶段分配Executor初始状态时，将一些特定的数据结构定义如下：

NS_reduce为包含n₂个允许启动Executor的空闲节点，是NS的一个子集合。其元素N_i表示第i个空闲节点，它被要求有最少剩余量的计算资源。类似地，可以提前计算每个节点上允许启动的Executor的数量，表示为EN_reduce：

其中，

是节点N_i上允许启动的Executor的个数。

BT为长度为m₁×m₂的矩阵，表示前一阶段Map任务输出的中间数据分区后的分布。其元素b_kj表示第j个bucket，其数据来自Map任务t_k。m₁为Map任务的个数，m₂为分区数。PN为长度为m₂的向量，其元素p_j表示第j个分区。在Shuffle过程中，每个Map任务的第j个bucket的中间数据构成分区p_j，可以形式化为：

RT为一组Reduce任务的集合。其元素t_j表示处理分区p_j的第j个任务。由于每个Reduce任务计算一个分区，Reduce任务的数量与分区的数量相同。

对于Reduce任务的调度，每个任务都可以运行在任意节点的Executor中。我们定义每个Redcue任务在不同节点上获取分区时的通信代价，表示为一个n₂×m₂的矩阵CR：

其中，c_i,j表示当分配任务t_j到节点N_i时获取分区p_j的通信代价。

如上分析，分区p_j由所有Map任务输出的第j个bucket组成，所以Redcue任务t_j需要到每个Map任务所在的节点上拉取数据。因此c_i,j是任务t_j获取每个bucket的通信代价之和，可以计算为：

其中，d(i,kj)是bucketb_kj和节点N_i之间的网络距离，|b_kj|是bucketb_kj的数据大小。d(i,kj)具体计算为节点N_i和Map任务t_k所在节点之间的网络距离。

对于单个Reduce任务t_j，我们定义一个节点N_i所能提供的整体数据本地性等级，表示为data_locality(i)，将nS_map中的空闲节点根据data_localiy的值升序排序，它可以计算为每个任务运行在该节点的Executor中时的通信代价的总和：

其中，m₂是Reduce任务的数量，n₂是空闲节点的数量。显然，tata_locality(i)的值越大通信代价就越大，所以节点N_i所能提供的整体数据本地性越差，反之亦然。具体地在Reduce阶段，data_locality(i)可以进一步计算为：

可见，本申请实施例先确定Map阶段全部Map任务分别在Spark框架中每个第一空闲节点获取相应数据块的通信代价，以得到每个所述第一空闲节点对应的第一通信代价；然后按照所述第一通信代价的大小顺序对全部所述第一空闲节点进行排序，并依次在排序后的所述第一空闲节点上分配所述第一空闲节点的最大可用Executor数量个第一Executor；最后当分配的所述第一Executor总数量为第一所需Executor数量时，停止分配所述第一Executor得到所述Map阶段执行所述Map任务的包含当前已分配的所述第一Executor的第一Executor集合。本申请实施例将Executor分配在靠近输入数据块所在的节点上，能够改善Spark任务调度中的数据本地性，有效降低任务的网络流量和数据访问延迟。

参见图3所示，本申请实施例还相应公开了一种基于Spark框架的Executor分配装置，包括：

第一确定模块11，用于确定Map阶段全部Map任务分别在Spark框架中每个第一空闲节点获取相应数据块的通信代价，以得到每个所述第一空闲节点对应的第一通信代价；

第一分配模块12，用于按照所述第一通信代价的大小顺序对全部所述第一空闲节点进行排序，并依次在排序后的所述第一空闲节点上分配所述第一空闲节点的最大可用Executor数量个第一Executor；

第一生成模块13，用于当分配的所述第一Executor总数量为第一所需Executor数量时，停止分配所述第一Executor得到所述Map阶段执行所述Map任务的包含当前已分配的所述第一Executor的第一Executor集合。

在一些具体实施例中，所述第一确定模块11，具体包括：

第一确定子模块，用于确定所述Map阶段每个所述Map任务分别在Spark框架中每个所述第一空闲节点获取相应数据块的第二通信代价；

第二确定子模块，用于将每个所述第一空闲节点上的所述第二通信代价进行求和运算以得到每个所述第一空闲节点对应的所述第一通信代价。

在一些具体实施例中，所述第一确定子模块，具体包括：

第一确定单元，用于分别确定所述Map阶段每个所述Map任务所在第一空闲节点至所述数据块的多个副本所在节点的所述网络距离；其中，所述数据块以多个副本的形式进行存储；

第二确定单元，用于将所述Map任务在所述第一空闲节点获取所述网络距离最小的节点上的副本的通信代价确定为所述第二通信代价。

在一些具体实施例中，所述基于Spark框架的Executor分配装置还包括：

第二确定模块，用于确定Reduce阶段全部Reduce任务分别在Spark框架中每个第二空闲节点获取相应分区数据的通信代价，以得到每个所述第二空闲节点对应的第三通信代价；所述分区数据为将所述Map阶段中每个所述Map任务输出的中间数据按照bucket类型划分为与Reduce任务数量一致的区域后得到的分区中的数据；

第二分配模块，用于按照所述第三通信代价的大小顺序对全部所述第二空闲节点进行排序，并依次在排序后的所述第二空闲节点上分配所述第二空闲节点的最大可用Executor数量个第二Executor；

第二生成模块，用于当分配的所述第二Executor总数量为第二所需Executor数量时，停止分配所述第二Executor得到所述Reduce阶段执行所述Reduce任务的包含当前已分配的所述第二Executor的第二Executor集合。

在一些具体实施例中，所述第二确定模块，具体包括：

第三确定子模块，用于确定所述Reduce阶段每个所述Reduce任务分别在Spark框架中每个所述第二空闲节点获取相应所述分区数据的第四通信代价；

第四确定子模块，用于将每个所述第二空闲节点上的所述第四通信代价进行求和运算以得到每个所述第二空闲节点对应的所述第三通信代价。

进一步的，本申请实施例还提供了一种电子设备。图4是根据一示例性实施例示出的电子设备20结构图，图中的内容不能认为是对本申请的使用范围的任何限制。

图4为本申请实施例提供的一种电子设备20的结构示意图。该电子设备20，具体可以包括：至少一个处理器21、至少一个存储器22、电源23、通信接口24、输入输出接口25和通信总线26。其中，所述存储器22用于存储计算机程序，所述计算机程序由所述处理器21加载并执行，以实现前述任一实施例公开的基于Spark框架的Executor分配方法中的相关步骤。

本实施例中，电源23用于为电子设备20上的各硬件设备提供工作电压；通信接口24能够为电子设备20创建与外界设备之间的数据传输通道，其所遵循的通信协议是能够适用于本申请技术方案的任意通信协议，在此不对其进行具体限定；输入输出接口25，用于获取外界输入数据或向外界输出数据，其具体的接口类型可以根据具体应用需要进行选取，在此不进行具体限定。

另外，存储器22作为资源存储的载体，可以是只读存储器、随机存储器、磁盘或者光盘等，其上所存储的资源可以包括操作系统221、计算机程序222及数据223等，存储方式可以是短暂存储或者永久存储。

其中，操作系统221用于管理与控制电子设备20上的各硬件设备以及计算机程序222，以实现处理器21对存储器22中海量数据223的运算与处理，其可以是Windows Server、Netware、Unix、Linux等。计算机程序222除了包括能够用于完成前述任一实施例公开的由电子设备20执行的基于Spark框架的Executor分配方法的计算机程序之外，还可以进一步包括能够用于完成其他特定工作的计算机程序。数据223可以包括电子设备20收集到的任务数据。

进一步的，本申请实施例还公开了一种存储介质，所述存储介质中存储有计算机程序，所述计算机程序被处理器加载并执行时，实现前述任一实施例公开的基于Spark框架的Executor分配方法步骤。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

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

以上对本发明所提供的基于Spark框架的Executor分配方法、装置、设备及存储介质进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims

1.一种基于Spark框架的Executor分配方法，其特征在于，包括：

2.根据权利要求1所述的基于Spark框架的Executor分配方法，其特征在于，所述确定Map阶段全部Map任务分别在Spark框架中每个第一空闲节点获取相应数据块的通信代价，以得到每个所述第一空闲节点对应的第一通信代价，包括：

3.根据权利要求2所述的基于Spark框架的Executor分配方法，其特征在于，所述第二通信代价与所述数据块大小及所述Map任务所在第一空闲节点至所述数据块所在节点之间的网络距离呈正相关关系。

4.根据权利要求3所述的基于Spark框架的Executor分配方法，其特征在于，所述确定所述Map阶段每个所述Map任务分别在Spark框架中每个所述第一空闲节点获取相应数据块的第二通信代价，包括：

5.根据权利要求1至4任一项所述的基于Spark框架的Executor分配方法，其特征在于，所述当分配的所述第一Executor总数量为所需Executor数量时，停止分配Executor得到所述Map阶段执行所述Map任务的包含当前已分配的所述第一Executor的第一Executor集合之后，还包括：

6.根据权利要求5所述的基于Spark框架的Executor分配方法，其特征在于，所述确定Reduce阶段全部Reduce任务分别在Spark框架中每个第二空闲节点获取相应分区数据的通信代价，以得到每个所述第二空闲节点对应的第三通信代价，包括：

7.根据权利要求6所述的基于Spark框架的Executor分配方法，其特征在于，所述第四通信代价与每个分区中的所述中间数据的数据大小及所述Reduce任务所在第二空闲节点至每个分区中的所述中间数据所在节点之间的网络距离呈正相关关系。

8.一种基于Spark框架的Executor分配装置，其特征在于，包括：

9.一种电子设备，其特征在于，所述电子设备包括处理器和存储器；其中所述存储器用于存储计算机程序，所述计算机程序由所述处理器加载并执行以实现如权利要求1至7任一项所述的基于Spark框架的Executor分配方法。

10.一种计算机可读存储介质，其特征在于，用于存储计算机可执行指令，所述计算机可执行指令被处理器加载并执行时，实现如权利要求1至7任一项所述的基于Spark框架的Executor分配方法。