CN107291550A - 一种针对迭代应用的Spark平台资源动态分配方法及系统 - Google Patents

Abstract

本发明公开了一种针对迭代应用的Spark平台资源动态分配方法及系统，包括：根据Spark集群的硬件信息为Spark集群的任务执行单元分配第一资源以用于任务执行单元执行迭代应用；确定每个监控周期下每个计算节点在执行所述迭代应用时的软件信息；根据每个计算节点在第m个监控周期下和第m+1个监控周期下执行迭代应用时的软件信息确定所述迭代应用对所述第一资源的使用量达到收敛；根据第1至第m+1个监控周期下每个计算节点在执行所述迭代应用时的软件信息为Spark集群的任务执行单元分配第二资源，以用于任务执行单元重新执行所述迭代应用。本发明在保证迭代应用正常而高效运行的同时，可以自动释放其占用的冗余系统资源，提高系统的整体资源利用率与应用的并发度。

Description

一种针对迭代应用的Spark平台资源动态分配方法及系统

技术领域

本发明属于大数据技术领域，更具体地，涉及一种针对迭代应用的Spark平台资源动态分配方法及系统。

背景技术

随着“互联网+”时代的来临，大数据日趋成为现今各行各业的热门话题。如何对海量的数据进行计算处理，使其价值最大化，是人类面临一个非常重大的挑战。AMP实验室提出了一种分布式内存抽象，称为弹性分布式数据集(RDD，Resilient DistributedDatasets)，RDD允许用户显式地把工作集缓存在内存中，因此在未来重用时能够极大地提升速度。

AMP实验室在Spark系统中实现了RDD，并使用Spark来开发各种并行应用。Spark有诸多优异的特性：Spark最大的优点是能够将中间结果保存在内存中，计算速度比HadoopMapReduce快100倍以上；Spark便于使用，如用户能够用Java、Scala、Python和R语言快速地编写应用程序；Spark具有通用性，能够在其上运行SQL查询、流计算以及机器学习和图计算等复杂的计算分析，同时Spark能够以多种模式运行，并能够从HDFS、Cassandra、HBase等多种数据流或文件系统中读取数据。

应用程序提交到Spark集群后，会根据其中的action算子，将应用程序划分为多个Job，每个Job根据RDD的依赖关系划分为多个Stage，每个stage就是一个任务集，再分配到集群各个计算节点进行执行。Spark系统往往会有一个主节点(Master)以及一个或多个计算节点(Worker)，应用运行时，会在Worker节点上启动一个或多个任务执行单元(Executor)，Executor是Spark系统的任务执行单元。在Spark系统上启动一个应用程序后，默认的资源分配策略，会在每个Worker上启动一个Executor，并为每个Executor分配1GB内存以及全部的CPU资源。

但是，默认的Spark资源分配策略是一种静态的方法，一方面，当应用需要的内存较大，超出Executor的内存容量时，应用执行效率极低，甚至无法执行；另一方面，为每个Executor分配的全部CPU资源不一定能够充分利用，可能导致CPU利用率低下，且无法在运行时释放系统CPU资源，系统中其他应用提交以后，只能等待当前应用执行完毕，释放占用的资源后才能继续执行。另外，用户可以手动配置为Executor分配的内存以及CPU资源，但是不同应用的特点不同，其对于资源的需求情况也有极大差异。同种应用当负载数据量不同时，对于资源的需求情况也不尽相同。因此，如何为Executor分配合适的资源，可能会对Spark用户带来极大的困扰。用户往往需要靠经验积累，甚至多次枚举各种配置参数组合运行应用程序，来获取针对特定应用程序的合适的资源分配量，而这种方法成本高、效率低。

综上，Spark现有的资源分配策略是一种静态的方法，一方面可能导致应用执行效率低甚至无法执行，另一方面可能导致系统的资源利用率低下，同时如何为应用程序分配合适的资源并非易事，往往会给用户带来极大的困扰。

发明内容

针对现有技术的缺陷，本发明的目的在于解决现有Spark资源分配策略是静态方法，可能导致应用执行效率低甚至无法执行或者系统的资源利用率低下，以及用户以手动配置Spark资源不能针对不同应用的特点分配合适资源的技术问题。

为实现上述目的，第一方面，本发明实施例提供了一种针对迭代应用的Spark平台资源动态分配方法，包括：根据Spark集群的硬件信息为Spark集群的任务执行单元分配第一资源以用于任务执行单元执行迭代应用，所述Spark集群包括至少一个计算节点，每个计算节点上启动至少一个任务执行单元，所述硬件信息包括每个计算节点的内存总量、可用内存量以及CPU核数，所述第一资源包括的内存量和CPU核数分别小于或等于每个计算节点的可用内存量以及CPU核数；确定每个监控周期下每个计算节点在执行所述迭代应用时的软件信息，所述软件信息包括所述迭代应用对所述第一资源的内存使用量和CPU利用率；根据每个计算节点在第m个监控周期下和第m+1个监控周期下执行所述迭代应用时的软件信息确定所述迭代应用对所述第一资源的使用量达到收敛，m为正整数；根据第1至第m+1个监控周期下每个计算节点在执行所述迭代应用时的软件信息为Spark集群的任务执行单元分配第二资源，以用于所述任务执行单元重新执行所述迭代应用，所述第二资源包括的内存量和CPU核数分别小于或等于第一资源包括的内存量和CPU核数。

本发明实施例提供的方法，在为Spark集群分配第一资源后，其迭代应用可能对第一资源的需求趋于稳定，且迭代应用仅需要第一资源中的一部分资源，则可通过自动监控对第一资源的使用情况，在对第一资源的使用收敛时，调整为Spark集群分配迭代应用实际需要的第二资源，以释放第一资源中冗余的资源，使得这些资源能够为集群上的其他应用程序利用，进而有效提高系统的整体资源利用率与应用的并发度。

可选地，根据每个计算节点在第m个监控周期下和第m+1个监控周期下执行所述迭代应用时的软件信息确定所述迭代应用对所述第一资源的使用量达到收敛，包括：若每个计算节点从第m个监控周期到第m+1个监控周期执行所述迭代应用时对所述第一资源所包括内存的使用量趋于稳定，则所述迭代应用对所述第一资源的使用量达到收敛。

可选地，每个计算节点从第m个监控周期到第m+1个监控周期执行所述迭代应用时对所述第一资源的内存使用量趋于稳定，包括：若每个计算节点从第m个监控周期到第m+1个监控周期的内存使用量变化率满足如下公式，则每个计算节点对所述第一资源的内存使用量趋于稳定：δi<α，其中，δi表示计算节点i从第m到第m+1个监控周期下执行所述迭代应用时的内存使用量变化率，i表示计算节点的编号，α表示预设变化率阈值；δi通过以下公式确定：

δi＝(MEMi(m+1)-MEMim)/MEMim

其中，MEMim和MEMi(m+1)分别表示计算节点i在第m个监控周期下和第m+1个监控周期下执行所述迭代应用时的内存使用量。

可选地，根据第m+1个监控周期下每个计算节点在执行所述迭代应用时的软件信息为Spark集群的任务执行单元分配第二资源，通过以下公式确定：

其中，MEMsug表示第二资源包括的内存量，CPUsug表示第二资源包括的CPU核数，β1和β2分别为内存量和CPU核数的资源需求浮动因子，MEMmax表示第m+1个监控周期下所有计算节点在执行所述迭代应用时内存使用量中的最大值，CPUmax表示从第1个监控周期到第m+1个监控周期中所有计算节点在执行所述迭代应用时的CPU利用率中的最大值，CPU_Core_NUM表示每个计算节点的CPU核数。

可选地，MEMim和MEMi(m+1)分别通过以下公式确定：

MEMim＝(MEM_USED′im-MEM_USEDi)

MEMi(m+1)＝(MEM_USED′i(m+1)-MEM_USEDi)

其中，MEM_USEDi表示计算节点i无应用执行时的内存使用量，MEM_USED′im与MEM_USED′i(m+1)分别表示计算节点i在第m和第m+1个监控周期的内存总使用量，MEMim和MEMi(m+1)分别表示计算节点i在第m和第m+1个监控周期执行迭代应用时的内存使用量。

第二方面，本发明实施例提供了一种针对迭代应用的Spark平台资源动态分配系统，包括：

第一资源分配单元，用于根据Spark集群的硬件信息为Spark集群的任务执行单元分配第一资源以用于任务执行单元执行迭代应用，所述Spark集群包括至少一个计算节点，每个计算节点上启动至少一个任务执行单元，所述硬件信息包括每个计算节点的内存总量、可用内存量以及CPU核数，所述第一资源包括的内存量和CPU核数分别小于或等于每个计算节点的可用内存量以及CPU核数。

软件信息确定单元，用于确定每个监控周期下每个计算节点在执行所述迭代应用时的软件信息，所述软件信息包括所述迭代应用对所述第一资源的内存使用量和CPU利用率。

需求收敛确定单元，用于根据每个计算节点在第m个监控周期下和第m+1个监控周期下执行所述迭代应用时的软件信息确定所述迭代应用对所述第一资源的使用量达到收敛。

第二资源分配单元，用于根据第1至第m+1个监控周期下每个计算节点在执行所述迭代应用时的软件信息为Spark集群的任务执行单元分配第二资源，以用于所述任务执行单元重新执行所述迭代应用，所述第二资源包括的内存量和CPU核数分别小于或等于第一资源包括的内存量和CPU核数。

可选地，需求收敛确定单元，用于若每个计算节点从第m个监控周期到第m+1个监控周期执行所述迭代应用时对所述第一资源所包括内存使用量趋于稳定，则确定所述迭代应用对所述第一资源的使用量达到收敛。

可选地，需求收敛确定单元，用于若每个计算节点从第m个监控周期到第m+1个监控周期的内存使用量变化率满足如下公式，则确定每个计算节点对所述第一资源的内存使用量趋于稳定：

δi<α

其中，δi表示计算节点i从第m到第m+1个监控周期下执行所述迭代应用时的内存使用量变化率，i表示计算节点的编号，α表示预设变化率阈值；

δi通过以下公式确定：

δi＝(MEMi(m+1)-MEMim)/MEMim

其中，MEMim和MEMi(m+1)分别表示计算节点i在第m个监控周期下和第m+1个监控周期下执行所述迭代应用时的内存使用量。

可选地，第二资源分配单元，用于通过以下公式确定第二资源：

其中，MEMsug表示第二资源包括的内存量，CPUsug表示第二资源包括的CPU核数，β1和β2分别为内存量和CPU核数的资源需求浮动因子，MEMmax表示第m+1个监控周期下所有计算节点执行所述迭代应用时内存使用量中的最大值，CPUmax表示从第1个监控周期到第m+1个监控周期中所有计算节点执行所述迭代应用时的CPU利用率中的最大值，

CPU_Core_NUM表示每个计算节点的CPU核数。

第三方面，本发明实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述第一方面所述的Spark平台资源动态分配方法。

总体而言，通过本发明所构思的以上技术方案与现有技术相比，具有以下有益效果：

(1)本发明提供的Spark资源动态分配方法是一个完全自动化过程，对于用户执行应用程序来说完全是透明的，用户无需了解底层设计，无需与任何界面或接口进行交互，大大降低了用户的使用门槛。

(2)本发明解决了对于Spark集群上典型的迭代应用，无法动态分配系统资源的问题。对于整个Spark集群系统而言，本发明在保证该迭代应用正常而高效运行的同时，可以释放其占用的冗余系统资源，使得这些资源能够为集群上的其他应用程序利用，进而有效提高系统的整体资源利用率与应用的并发度。

(3)本发明不仅仅只适用于迭代应用，大部分对于系统资源的需求量有上限值或者会逐渐收敛的应用，本发明均可对其实行资源的动态分配方法，进而提高系统的资源利用率与应用的并发度。

附图说明

图1为本发明实施例提供的针对迭代应用的Spark平台资源动态分配方法流程示意图；

图2为本发明实施例提供的针对迭代应用的Spark平台资源动态分配系统的架构图；

图3为本发明实施例提供的针对迭代应用的Spark平台资源动态分配系统工作流程图；

图4为本发明实施例提供的节点状态监测及建模评估模块的工作流程图；

图5为本发明实施例提供的资源动态分配模块的工作流程图；

图6为本发明实施例提供的针对迭代应用的Spark平台资源动态分配系统结构示意图。

具体实施方式

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

图1为本发明实施例提供的针对迭代应用的Spark平台资源动态分配方法流程示意图；如图1所示，包括步骤S101至步骤S104。

S101，根据Spark集群的硬件信息为Spark集群的任务执行单元分配第一资源以用于任务执行单元执行迭代应用，所述Spark集群包括至少一个计算节点，每个计算节点上启动至少一个任务执行单元，所述硬件信息包括每个计算节点的内存总量、可用内存量以及CPU核数，所述第一资源包括的内存量和CPU核数分别小于或等于每个计算节点的可用内存量以及CPU核数。

S102，确定每个监控周期下每个计算节点在执行所述迭代应用时的软件信息，所述软件信息包括所述迭代应用对所述第一资源的内存使用量和CPU利用率。

S103，根据每个计算节点在第m个监控周期下和第m+1个监控周期下执行所述迭代应用时的软件信息确定所述迭代应用对所述第一资源的使用量达到收敛，m为正整数。

可选地，若每个计算节点从第m个监控周期到第m+1个监控周期执行所述迭代应用时对所述第一资源的内存使用量趋于稳定，则所述迭代应用对所述第一资源的使用量达到收敛。

可选地，若每个计算节点从第m个监控周期到第m+1个监控周期执行所述迭代应用时内存使用量变化率满足如下公式，则每个计算节点对所述第一资源的内存使用量趋于稳定：δi<α。

其中，δi表示计算节点i从第m到第m+1个监控周期下执行所述迭代应用时的内存使用量变化率，i表示计算节点的编号，α表示预设变化率阈值。

δi通过以下公式确定：

δi＝(MEMi(m+1)-MEMim)/MEMim

其中，MEMim和MEMi(m+1)分别表示计算节点i在第m个监控周期下和第m+1个监控周期下执行所述迭代应用时的内存使用量。

其中，预设变化率阈值可设为α，α取经验值0.05。

S104，根据第1至第m+1个监控周期下每个计算节点在执行所述迭代应用时的软件信息为Spark集群的任务执行单元分配第二资源，以用于所述任务执行单元重新执行所述迭代应用，所述第二资源包括的内存量和CPU核数分别小于或等于第一资源包括的内存量和CPU核数。

具体地，为Spark集群分配第一资源后，其迭代应用可能对第一资源的需求趋于稳定，且仅需要第一资源中的一部分资源，则可通过调整为Spark集群分配迭代应用实际需要的第二资源，以释放第一资源中冗余的资源，使得这些资源能够为集群上的其他应用程序利用，进而有效提高系统的整体资源利用率与应用的并发度。

可选地，根据第m+1个监控周期下每个计算节点在执行所述迭代应用时的软件信息为Spark集群的任务执行单元分配第二资源，通过以下公式确定：

其中，MEMsug表示第二资源包括的内存量，CPUsug表示第二资源包括的CPU核数，β1和β2分别为内存量和CPU核数的资源需求浮动因子，MEMmax表示第m+1个监控周期下所有计算节点在执行迭代应用时中内存使用量中的最大值，CPUmax表示从第1个监控周期到第m+1个监控周期中所有计算节点在执行迭代应用时CPU利用率中的最大值，CPU_Core_NUM表示每个计算节点的CPU核数。

本发明实施例对于整个Spark集群系统而言，在保证该迭代应用正常而高效运行的同时，可以释放其占用的冗余系统资源，使得这些资源能够为集群上的其他应用程序利用，进而有效提高系统的整体资源利用率与应用的并发度。

如图2所示，本发明实施例提供的针对迭代应用的Spark平台资源动态分配系统架构为三方架构包括：客户端、Spark集群和监控服务器。其中用户在客户端提交Spark迭代应用程序，Spark集群包括一个主节点(Master)和一个或多个计算节点(Worker)，主节点接受建模反馈信息以及任务的执行状态信息，负责任务调度与资源分配；计算节点接受调度信息，并在任务执行单元(Executor)中运行任务；监控服务器监控计算节点的状态信息，并反馈给主节点。

如图3所示，本发明中，针对迭代应用的Spark平台资源动态分配系统的工作流程如下：

步骤301，启动Spark集群，采集集群的硬件信息，监控服务器在特定端口接受、汇总集群的硬件信息，每一条硬件信息记录表示为：

Record_Hardware＝(Hostname，MEM_Total，MEM_USED，MEM_AVA，CPU_Core_NUM)

其中，Hostname表示该计算节点主机名，MEM_Total表示该计算节点的总内存大小，MEM_USED表示该计算节点无应用执行时的内存使用量，MEM_AVA表示该计算节点无应用执行时的可用内存大小，CPU_Core_NUM表示该计算节点的逻辑CPU核数。其中，MEM_Total＝MEM_USED+MEM_AVA。

步骤302，为Spark的任务执行单元Executor分配足够的系统资源执行迭代应用，其中足够的系统资源即为图1步骤所提及的第一资源，第一资源可以为全部的可用内存大小，即MEM_AVA，以及全部的逻辑CPU核数，即CPU_Core_NUM。第一资源也可以为MEM_AVA和CPU_Core_NUM中的部分资源。

步骤303，主节点实时监控集群各计算节点上的迭代应用执行情况信息，即应用当前所处的迭代轮数以及当前轮次的迭代计算是否结束。其中，Spark源码中主节点的CoarseGrainedSchedulerBackend类通过调用receive函数，接收从计算节点的CoarseGrainedExecutorBackend类传回的任务执行信息，然后调用TaskSchedulerImpl类中statusUpdate方法，判断当前迭代计算任务是否执行完毕从做出相应处理，对此过程进行监控，即可获取当前轮次的节点迭代计算状态信息。

步骤304，同时监控服务器启动节点状态监控，在特定端口定期(每隔30s)接收、汇总各个计算节点在运行迭代应用时产生的软件信息，每一条软件信息记录表示为：

Record_Software＝(Hostname，Mointor_ID，MEM_USED′，CPU_UTI)

其中，Hostname同样表示该计算节点主机名，Mointor_ID表示该计算节点当前所处监控周期的序列号，MEM_USED′表示当前时刻该计算节点的内存使用量，CPU_UTI表示当前时刻计算节点的CPU利用率，其中，当前时刻即为当前监控周期。

如图4所示，本发明实施例提供的节点状态监测及建模评估模块的工作流程如下：

步骤401，监控服务器汇总、解析采集到的硬件、软件信息，计算相邻监控周期中各计算节点的内存使用量变化率，假设有n个计算节点，第m个和第m+1个监控周期的内存使用量变化率计算公式如下：

MEMim＝(MEM_USED′im-MEM_USEDi)

MEMi(m+1)＝(MEM_USED′i(m+1)-MEM_USEDi)

δi＝(MEMi(m+1)-MEMim)/MEMim

其中，i＝1，2，...n，MEM_USEDi表示计算节点i无应用执行时的内存使用量，MEM_USED′im与MEM_USED′i(m+1)分别表示计算节点i在第m和第m+1个监控周期的内存总使用量，则MEMim和MEMi(m+1)分别表示计算节点i在第m和第m+1个监控周期的迭代应用的内存使用量，δi表示计算节点i在第m到第m+1个监控周期的内存使用量变化率。

步骤402，判断该迭代应用对于系统资源(第一资源)的需求是否收敛，收敛的条件是n个计算节点的内存使用量变化率都满足以下公式：

δi<α

其中，i＝1，2，...n，α为收敛因子，收敛条件是所有节点在相邻两个监控周期的内存使用量变化率均小于α，α取经验值0.05，如不满足收敛条件，执行步骤401。若收敛，执行步骤403，其中对第一资源的需求收敛指迭代应用对第一资源的使用量趋于稳定。

步骤403，满足收敛条件，则计算系统资源的建议分配值，采用以下公式：

MEMmax＝MAX{MEMi(m+1)}

CPUmax＝MAX{CPU_UTIik}

其中i＝1，2，...n，k＝1，2，...m+1，β1和β2分别为内存和CPU的资源需求浮动因子，MEMi(m+1)表示计算节点i在第m+1个监控周期执行迭代应用时的内存使用量，CPU_UTIik表示计算节点i在第k个周期的CPU利用率，MEMmax表示第m+1个监控周期中各计算节点的迭代应用的内存使用量最大值，CPUmax表示从第1个监控周期到第m+1个监控周期中各计算节点的CPU利用率的最大值，MEMsug表示系统内存资源的建议分配值,CPUsug表示系统逻辑CPU核数的建议分配值，β1取经验值0.1，β2取经验值0.1。

如图5所示，本发明实施例提供的资源的动态分配模块工作流程如下：

步骤501，若迭代应用对系统资源的需求达到收敛，主节点读取各计算节点上的迭代应用执行情况信息，判断当前轮次的迭代信息是否结束，即步骤303中提到的主节点根据计算节点传回的任务执行信息，调用TaskSchedulerImpl类中的statusUpdate方法，判断当前迭代计算任务是否执行完毕，同时获取应用当前所处的迭代轮数，并等待当前轮次的迭代计算结束；

步骤502，若当前轮次的迭代计算结束，调用Spark源码中主节点Master类的killExecutor方法，结束当前执行进程，根据步骤303中得到的系统内存资源和CPU资源的建议分配值，为Spark集群的任务执行单元重新分配系统资源，格式为<”Memory:MEMsug”,”core:CPUsug”>。具体的步骤为，首先调用Master类的startExecutorsOnWorkers方法，然后在方法allocateWorkerResourceToExecutors中，Master向Worker发送启动Executor的消息，Worker在接收到LauchExecutor消息之后，创建ExecutorRunner对象并最终在方法fetchAndRunExecutor中启动Executor进程。通过此步骤，在新的迭代周期中启用重新分配系统资源的任务执行单元，继续执行后续迭代计算。

对于用户运行的该迭代应用而言，可能会由于执行单元的一次终止与重新分配系统资源并启动，以及部分缓存的中间数据结果的重计算而带来一些开销，但是对于多轮迭代而言，这些开销并不算大，且随着迭代轮数的增大，这些开销基本可以忽略不计。

图6为本发明实施例提供的针对迭代应用的Spark平台资源动态分配系统结构示意图。如图6所示，包括：第一资源分配单元、软件信息确定单元、需求收敛确定单元以及第二资源分配单元。

第一资源分配单元，用于根据Spark集群的硬件信息为Spark集群的任务执行单元分配第一资源以用于任务执行单元执行迭代应用，所述Spark集群包括至少一个计算节点，每个计算节点上启动至少一个任务执行单元，所述硬件信息包括每个计算节点的内存总量、可用内存量以及CPU核数，所述第一资源包括的内存量和CPU核数分别小于或等于每个计算节点的可用内存量以及CPU核数。

软件信息确定单元，用于确定每个监控周期下每个计算节点在执行所述迭代应用时的软件信息，所述软件信息包括所述迭代应用对所述第一资源的内存使用量和CPU利用率。

需求收敛确定单元，用于根据每个计算节点在第m个监控周期下和第m+1个监控周期下执行所述迭代应用时的软件信息确定所述迭代应用对所述第一资源的使用量达到收敛。

第二资源分配单元，用于根据第1至第m+1个监控周期下每个计算节点在执行所述迭代应用时的软件信息为Spark集群的任务执行单元分配第二资源，以用于所述任务执行单元重新执行所述迭代应用，所述第二资源包括的内存量和CPU核数分别小于或等于第一资源包括的内存量和CPU核数。

图6所示的系统还可包括更多或更少的部件，各部件的功能参见上述图1至图5所示的方法实施例，在此不做赘述。

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

Claims (10)

1.一种针对迭代应用的Spark平台资源动态分配方法，其特征在于，包括：

根据Spark集群的硬件信息为Spark集群的任务执行单元分配第一资源以用于任务执行单元执行迭代应用，所述Spark集群包括至少一个计算节点，每个计算节点上启动至少一个任务执行单元，所述硬件信息包括每个计算节点的内存总量、可用内存量以及CPU核数，所述第一资源包括的内存量和CPU核数分别小于或等于每个计算节点的可用内存量和CPU核数；

确定每个监控周期下每个计算节点在执行所述迭代应用时的软件信息，所述软件信息包括所述迭代应用对所述第一资源的内存使用量和CPU利用率；

根据每个计算节点在第m个监控周期下和第m+1个监控周期下执行所述迭代应用时的软件信息确定所述迭代应用对所述第一资源的使用量达到收敛，m为正整数；

根据第1至第m+1个监控周期下每个计算节点在执行所述迭代应用时的软件信息为Spark集群的任务执行单元分配第二资源，以用于所述任务执行单元重新执行所述迭代应用，所述第二资源包括的内存量和CPU核数分别小于或等于第一资源包括的内存量和CPU核数。

2.根据权利要求1所述的Spark平台资源动态分配方法，其特征在于，根据每个计算节点在第m个监控周期下和第m+1个监控周期下执行所述迭代应用时的软件信息确定所述迭代应用对所述第一资源的使用量达到收敛，包括：

若每个计算节点从第m个监控周期到第m+1个监控周期执行所述迭代应用时对所述第一资源所包括内存的使用量趋于稳定，则所述迭代应用对所述第一资源的使用量达到收敛。

3.根据权利要求2所述的Spark平台资源动态分配方法，其特征在于，每个计算节点从第m个监控周期到第m+1监控周期执行所述迭代应用时对所述第一资源的内存使用量趋于稳定，包括：

若每个计算节点从第m个监控周期到第m+1个监控周期执行所述迭代应用时内存使用量变化率满足如下公式，则每个计算节点对所述第一资源的内存使用量趋于稳定：

δi<α

其中，δi表示计算节点i从第m到第m+1个监控周期下执行所述迭代应用时的内存使用量变化率，i表示计算节点的编号，α表示预设变化率阈值；

δi通过以下公式确定：

δi＝(MEMi(m+1)-MEMim)/MEMim

其中，MEMim和MEMi(m+1)分别表示计算节点i在第m个监控周期下和第m+1个监控周期下执行所述迭代应用时的内存使用量。

4.根据权利要求2所述的Spark平台资源动态分配方法，其特征在于，根据第1至第m+1个监控周期下每个计算节点在执行所述迭代应用时的软件信息为Spark集群的任务执行单元分配第二资源，通过以下公式确定：

其中，MEMsug表示第二资源包括的内存量，CPUsug表示第二资源包括的CPU核数，β1和β2分别为内存量和CPU核数的资源需求浮动因子，MEMmax表示第m+1个监控周期下所有计算节点在执行所述迭代应用时内存使用量中的最大值，CPUmax表示从第1个监控周期到第m+1个监控周期中所有计算节点在执行所述迭代应用时CPU利用率中的最大值，CPU_Core_NUM表示每个计算节点的CPU核数。

5.根据权利要求3所述的Spark平台资源动态分配方法，其特征在于，MEMim和MEMi(m+1)分别通过以下公式确定：

MEMim＝(MEM_USED′im-MEM_USEDi)

MEMi(m+1)＝(MEM_USED′i(m+1)-MEM_USEDi)

其中，MEM_USEDi表示计算节点i无应用执行时的内存使用量，MEM_USED′im与MEM_USED′i(m+1)分别表示计算节点i在第m和第m+1个监控周期的内存总使用量，MEMim和MEMi(m+1)分别表示计算节点i在第m和第m+1个监控周期执行迭代应用时的内存使用量。

6.一种针对迭代应用的Spark平台资源动态分配系统，其特征在于，包括：

第一资源分配单元，用于根据Spark集群的硬件信息为Spark集群的任务执行单元分配第一资源以用于任务执行单元执行迭代应用，所述Spark集群包括至少一个计算节点，每个计算节点上启动至少一个任务执行单元，所述硬件信息包括每个计算节点的内存总量、可用内存量以及CPU核数，所述第一资源包括的内存量和CPU核数分别小于或等于每个计算节点的可用内存量以及CPU核数；

软件信息确定单元，用于确定每个监控周期下每个计算节点在执行所述迭代应用时的软件信息，所述软件信息包括所述迭代应用对所述第一资源的内存使用量和CPU利用率；

需求收敛确定单元，用于根据每个计算节点在第m个监控周期下和第m+1个监控周期下执行所述迭代应用时的软件信息确定所述迭代应用对所述第一资源的使用量达到收敛；

第二资源分配单元，用于根据第1至第m+1个监控周期下每个计算节点在执行所述迭代应用时的软件信息为Spark集群的任务执行单元分配第二资源，以用于所述任务执行单元重新执行所述迭代应用，所述第二资源包括的内存量和CPU核数分别小于或等于第一资源包括的内存量和CPU核数。

7.根据权利要求6所述的Spark平台资源动态分配系统，其特征在于，需求收敛确定单元，用于若每个计算节点从第m个监控周期到第m+1个监控周期执行所述迭代应用时对所述第一资源所包括内存的使用量趋于稳定，则确定所述迭代应用对所述第一资源的使用量达到收敛。

8.根据权利要求7所述的Spark平台资源动态分配系统，其特征在于，需求收敛确定单元，用于若每个计算节点从第m个监控周期到第m+1个监控周期的内存使用量变化率满足如下公式，则确定每个计算节点对所述第一资源的内存使用量趋于稳定：

δi<α

其中，δi表示计算节点i从第m到第m+1个监控周期下执行所述迭代应用时的内存使用量变化率，i表示计算节点的编号，α表示预设变化率阈值；

δi通过以下公式确定：

δi＝(MEMi(m+1)-MEMim)/MEMim

其中，MEMim和MEMi(m+1)分别表示计算节点i在第m个监控周期下和第m+1个监控周期下执行所述迭代应用时的内存使用量。

9.根据权利要求7或8所述的Spark平台资源动态分配系统，其特征在于，第二资源分配单元，用于通过以下公式确定第二资源：

其中，MEMsug表示第二资源包括的内存量，CPUsug表示第二资源包括的CPU核数，β1和β2分别为内存量和CPU核数的资源需求浮动因子，MEMmax表示第m+1个监控周期下所有计算节点在执行所述迭代应用时内存使用量中的最大值，CPUmax表示从第1个监控周期到第m+1个监控周期中所有计算节点在执行所述迭代应用时CPU利用率中的最大值，CPU_Core_NUM表示每个节点的CPU核数。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至5任一项所述的Spark平台资源动态分配方法。