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

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

Info

Publication number
CN107291550A
CN107291550A CN201710481071.1A CN201710481071A CN107291550A CN 107291550 A CN107291550 A CN 107291550A CN 201710481071 A CN201710481071 A CN 201710481071A CN 107291550 A CN107291550 A CN 107291550A
Authority
CN
China
Prior art keywords
resource
calculate node
monitoring cycle
iterated application
application
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201710481071.1A
Other languages
English (en)
Other versions
CN107291550B (zh
Inventor
王芳
冯丹
李源
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huazhong University of Science and Technology
Original Assignee
Huazhong University of Science and Technology
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huazhong University of Science and Technology filed Critical Huazhong University of Science and Technology
Priority to CN201710481071.1A priority Critical patent/CN107291550B/zh
Publication of CN107291550A publication Critical patent/CN107291550A/zh
Application granted granted Critical
Publication of CN107291550B publication Critical patent/CN107291550B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5022—Mechanisms to release resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5044—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering hardware capabilities

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

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平台资源动态分配方法。
CN201710481071.1A 2017-06-22 2017-06-22 一种针对迭代应用的Spark平台资源动态分配方法及*** Active CN107291550B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710481071.1A CN107291550B (zh) 2017-06-22 2017-06-22 一种针对迭代应用的Spark平台资源动态分配方法及***

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710481071.1A CN107291550B (zh) 2017-06-22 2017-06-22 一种针对迭代应用的Spark平台资源动态分配方法及***

Publications (2)

Publication Number Publication Date
CN107291550A true CN107291550A (zh) 2017-10-24
CN107291550B CN107291550B (zh) 2019-11-12

Family

ID=60097315

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710481071.1A Active CN107291550B (zh) 2017-06-22 2017-06-22 一种针对迭代应用的Spark平台资源动态分配方法及***

Country Status (1)

Country Link
CN (1) CN107291550B (zh)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107908479A (zh) * 2017-12-11 2018-04-13 北京奇艺世纪科技有限公司 一种节点资源分配方法及装置
CN108037998A (zh) * 2017-12-01 2018-05-15 北京工业大学 一种面向Spark Streaming平台的数据接收通道动态分配方法
CN108062251A (zh) * 2018-01-09 2018-05-22 福建星瑞格软件有限公司 一种服务器资源回收方法以及计算机设备
CN108845884A (zh) * 2018-06-15 2018-11-20 中国平安人寿保险股份有限公司 物理资源分配方法、装置、计算机设备和存储介质
CN109739649A (zh) * 2018-12-28 2019-05-10 深圳前海微众银行股份有限公司 资源管理方法、装置、设备及计算机可读存储介质
CN111291990A (zh) * 2020-02-04 2020-06-16 浙江大华技术股份有限公司 一种质量监控处理方法及装置
CN112612587A (zh) * 2020-12-25 2021-04-06 江苏省未来网络创新研究院 一种针对流量分析的Spark平台动态资源调配方法
CN115061790A (zh) * 2022-06-10 2022-09-16 苏州浪潮智能科技有限公司 一种用于ARM双路服务器的Spark Kmeans核心分配方法及***

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7958509B2 (en) * 2005-12-21 2011-06-07 International Business Machines Corporation Method and system for scheduling of jobs
CN103812886A (zh) * 2012-11-09 2014-05-21 中国科学院上海高等研究院 计算机集群资源分配***和方法
CN104731595A (zh) * 2015-03-26 2015-06-24 江苏物联网研究发展中心 面向大数据分析的混合计算***
CN104951372A (zh) * 2015-06-16 2015-09-30 北京工业大学 一种基于预测的Map/Reduce数据处理平台内存资源动态分配方法
CN105468458A (zh) * 2015-11-26 2016-04-06 北京航空航天大学 计算机集群的资源调度方法及***

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7958509B2 (en) * 2005-12-21 2011-06-07 International Business Machines Corporation Method and system for scheduling of jobs
CN103812886A (zh) * 2012-11-09 2014-05-21 中国科学院上海高等研究院 计算机集群资源分配***和方法
CN104731595A (zh) * 2015-03-26 2015-06-24 江苏物联网研究发展中心 面向大数据分析的混合计算***
CN104951372A (zh) * 2015-06-16 2015-09-30 北京工业大学 一种基于预测的Map/Reduce数据处理平台内存资源动态分配方法
CN105468458A (zh) * 2015-11-26 2016-04-06 北京航空航天大学 计算机集群的资源调度方法及***

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
杨忙忙: "Spark数据处理平台中资源动态分配技术研究", 《中国优秀硕士学位论文全文数据库》 *

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108037998A (zh) * 2017-12-01 2018-05-15 北京工业大学 一种面向Spark Streaming平台的数据接收通道动态分配方法
CN107908479A (zh) * 2017-12-11 2018-04-13 北京奇艺世纪科技有限公司 一种节点资源分配方法及装置
CN107908479B (zh) * 2017-12-11 2021-03-02 北京奇艺世纪科技有限公司 一种节点资源分配方法及装置
CN108062251A (zh) * 2018-01-09 2018-05-22 福建星瑞格软件有限公司 一种服务器资源回收方法以及计算机设备
CN108845884A (zh) * 2018-06-15 2018-11-20 中国平安人寿保险股份有限公司 物理资源分配方法、装置、计算机设备和存储介质
CN108845884B (zh) * 2018-06-15 2024-04-19 中国平安人寿保险股份有限公司 物理资源分配方法、装置、计算机设备和存储介质
CN109739649A (zh) * 2018-12-28 2019-05-10 深圳前海微众银行股份有限公司 资源管理方法、装置、设备及计算机可读存储介质
CN111291990A (zh) * 2020-02-04 2020-06-16 浙江大华技术股份有限公司 一种质量监控处理方法及装置
CN111291990B (zh) * 2020-02-04 2023-11-07 浙江大华技术股份有限公司 一种质量监控处理方法及装置
CN112612587A (zh) * 2020-12-25 2021-04-06 江苏省未来网络创新研究院 一种针对流量分析的Spark平台动态资源调配方法
CN115061790A (zh) * 2022-06-10 2022-09-16 苏州浪潮智能科技有限公司 一种用于ARM双路服务器的Spark Kmeans核心分配方法及***
CN115061790B (zh) * 2022-06-10 2024-05-14 苏州浪潮智能科技有限公司 一种用于ARM双路服务器的Spark Kmeans核心分配方法及***

Also Published As

Publication number Publication date
CN107291550B (zh) 2019-11-12

Similar Documents

Publication Publication Date Title
CN107291550B (zh) 一种针对迭代应用的Spark平台资源动态分配方法及***
Venkataraman et al. The power of choice in {Data-Aware} cluster scheduling
CN102207891B (zh) 对数据划分分布式环境实现动态划分和负载均衡的方法
CN107832146A (zh) 高可用集群***中的线程池任务处理方法
CN102567080B (zh) 一种云计算环境中的面向负载均衡的虚拟机择位***
CN104902001B (zh) 基于操作***虚拟化的Web请求负载均衡方法
Lai et al. Sol: Fast distributed computation over slow networks
CN104536804A (zh) 面向关联任务请求的虚拟资源调度***及调度和分配方法
CN110727508A (zh) 一种任务调度***和调度方法
CN105404549A (zh) 基于yarn架构的虚拟机调度***
US20210390405A1 (en) Microservice-based training systems in heterogeneous graphic processor unit (gpu) cluster and operating method thereof
Zhou et al. AHPA: adaptive horizontal pod autoscaling systems on alibaba cloud container service for kubernetes
Biswas et al. A novel resource aware scheduling with multi-criteria for heterogeneous computing systems
Zhang et al. N-storm: Efficient thread-level task migration in apache storm
Fan et al. Execution time prediction using rough set theory in hybrid cloud
Xiao et al. Workload-aware Reliability Evaluation Model in Grid Computing.
Zhu et al. Formal analysis of load balancing in microservices with scenario calculus
Cao et al. Online cost-rejection rate scheduling for resource requests in hybrid clouds
Khalil et al. Survey of Apache Spark optimized job scheduling in Big Data
CN111522637B (zh) 一种基于成本效益的storm任务调度方法
CN107911484A (zh) 一种消息处理的方法及装置
Islam et al. FaCS: Toward a fault-tolerant cloud scheduler leveraging long short-term memory network
Cao et al. Novel client-cloud architecture for scalable instance-intensive workflow systems
Wang et al. Model-based scheduling for stream processing systems
Yang et al. Yun: a high-performance container management service based on openstack

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant