资源分配方法、装置以及电子设备与流程

专利2022-06-29  66


本申请涉及大数据业务技术领域,尤其涉及资源分配领域。



背景技术:

随着互联网技术持续的发展与应用,产生了海量的数据与各式各样的数据计算引擎。数据计算引擎是用来对数据做计算的组件。为了提取海量数据中有价值的数据,需要开发大量的数据etl(抽取、转换以及加载,extract-transform-load)业务,并且按照一定的周期,在线运行这些etl业务。其中,etl用来描述将数据从数据源经过抽取(extract)、转换(transform)、加载(load)至目的数据源的过程。

spark作为目前流行的大数据解决方案,有着众多优良特性。在spark中包括数据计算引擎。现有的spark业务普遍采用的资源分配方案,在启动etl业务的命令中可以配置用于运行业务的资源量,这部分资源量的配置就是业务的资源预分配方案。然而,如果定义一个相对宽松的资源预分配方案,并对所有的etl业务使用这个资源预分配方案,那么对于业务量小的etl业务,会出现资源过剩,造成集群资源利用率低的情况。对于业务量大的etl业务,会出现资源不足,造成业务运行性能低、耗时长的情况。

所以,现有的资源分配方案都无法分配适当的资源量来运行etl业务。



技术实现要素:

本申请提供了资源分配的方法、装置、电子设备及存储介质。

第一方面,本申请实施例提供一种资源分配方法,包括:

根据目标业务在历史周期的运行数据和上游业务在当前周期的运行数据,得到目标业务在当前周期的资源量,目标业务与上游业务具有数据依赖关系;

在当前周期内利用资源量运行目标业务,并监测目标业务在各执行器中的运行数据的变化;

根据目标业务在各执行器中的运行数据的变化,实时调整目标业务的资源量和/或目标业务在各执行器的数据分布。

本实施方式中,提高了集群的资源利用率,使得业务运行性能相对稳定、可配置。即使底层环境发生变化,通过自动增加或减少资源量,保持业务运行性能相对稳定。同时,还可以通过调整业务运行性能的配置参数来配置业务运行性能。

在一种实施方式中,还包括:

在目标业务运行完成的情况下,记录目标业务在当前周期的运行数据。

本实施方式中,目标业务在下一个周期运行时,读取存入日志表的目标业务在当前周期的运行数据,作为下一周期的资源预分配的参考数据,提高了资源量分配的是适应性和准确性。

在一种实施方式中,根据目标业务在历史周期的运行数据和上游业务在当前周期的运行数据,得到目标业务在当前周期的资源量,包括:

在未查找到目标业务在历史周期的运行数据的情况下,确定目标业务是新业务,得到第一资源量;

第一资源量包括:预先设置的执行器的数量、执行器的核数和单个执行器的内存量。

本实施方式中,在未查找到目标业务在历史周期的运行数据的情况下,利用预设的第一资源量来运行新业务,保证有足够的资源量来运行目标业务。

在一种实施方式中,根据目标业务在历史周期的运行数据和上游业务在当前周期的运行数据,得到目标业务在当前周期的资源量,包括:

在根据目标业务在历史周期的运行数据确定目标业务的业务逻辑发生更新的情况下,得到第一资源量;

第一资源量包括:预先设置的执行器的数量、执行器的核数和单个执行器的内存量。

本实施方式中,在查找到目标业务在历史周期的运行数据的情况下,并且确定了目标业务的业务逻辑发生更新,利用预设的第一资源量来运行业务逻辑发生更新的业务,保证有足够的资源量来运行目标业务。

在一种实施方式中,根据目标业务在历史周期的运行数据确定目标业务的业务逻辑发生更新,包括:

根据目标业务在当前周期的业务配置文件,计算第一文件检验和;

将目标业务在历史周期的运行数据中的文件检验和,作为第二文件检验和;

在第一文件检验和与第二文件检验和不相同的情况下,确定业务逻辑发生更新。

在一种实施方式中,根据目标业务在历史周期的运行数据和上游业务在当前周期的运行数据,得到目标业务在当前周期的资源量,包括:

根据目标业务的生产数据依赖关系确定上游业务;

上游业务在当前周期的运行数据和上游业务在历史周期的运行数据的差异大于第一阈值的情况下,得到第一资源量;

第一资源量包括:预先设置的执行器的数量、执行器的核数和单个执行器的内存量。

本实施方式中,如果上游业务的数据量发生显著变化,则目标业务的数据量也可能在当前周期发生显著变化,则分配预设的第一资源量来运行目标业务,保证了有足够的资源量来运行目标业务,提高了资源量分配的适应性和准确性。

在一种实施方式中,还包括:

在差异小于第一阈值的情况下,得到第二资源量。

本实施方式中,如果上游业务在当前周期的数据量没有发生显著变化,且目标业务在当前周期没有发生更新,则分配第二资源量来运行目标业务,保证了有适当的资源量来运行目标业务,提高了资源量分配的适应性和准确性。

在一种实施方式中,第二资源量的计算方式包括:

从目标业务在历史周期的运行数据中提取目标业务在多个周期的运行数据,目标业务在每个周期的运行数据包括业务运行时间、执行器的数量、最大并行任务数、最大内存使用量和最大数据量行数;

根据目标业务在多个周期的业务平均运行时间、执行器的平均数量、最大并行任务数的平均值和最大数据量行数的平均值,得到执行器的数量;

根据目标业务在多个周期的最大内存使用量的平均值和执行器的数量,计算单个执行器的内存量;

第二资源量包括:执行器的数量、执行器的核数、单个执行器的内存量;

其中,执行器的核数是预先设置的。

在一种实施方式中,根据目标业务在各执行器中的运行数据的变化,实时调整目标业务的资源量和/或目标业务在各执行器的数据分布,包括:

目标业务在当前周期的运行数据中,各执行器的总内存利用率超过第二阈值的情况下,增加运行目标业务的资源量。

本实施方式中,在目标业务运行的过程中,实时监控目标业务的执行器的运行数据的变化情况,如有需要,及时追加资源量,提供给目标业务充足的资源量,避免了业务运行过程中由于资源量紧张导致的运行中断或者速度降低的技术问题。

在一种实施方式中,根据目标业务在各执行器中的运行数据的变化,实时调整目标业务的资源量和/或目标业务在各执行器的数据分布,包括:

目标业务在当前周期的运行数据中,在至少一个执行器的实时数据量与实时总数据量的比值超过第三阈值的情况下,对各个执行器执行的任务数据重新分配。

本实施方式中,通过监控各个执行器内部的任务数据的变化,实时调控各个执行器的任务数据分布,提高了业务的运行速度,有效避免了部分执行器承担的任务数据很多,而另外部分执行器承担的任务数据很少,导致整个业务的运行进度降低的技术问题。

第二方面,本申请实施例提供了一种资源分配装置,包括:

资源量配置模块,用于根据目标业务在历史周期的运行数据和上游业务在当前周期的运行数据,得到目标业务在当前周期的资源量;

业务运行和监测模块,用于在当前周期内利用资源量运行目标业务,并监测目标业务在各执行器中的运行数据的变化;

调整模块,用于根据目标业务在各执行器中的运行数据的变化,实时调整目标业务的资源量和/或目标业务在各执行器的数据分布。

在一种实施方式中,还包括:

数据记录模块,用于在目标业务运行完成的情况下,记录目标业务在当前周期的运行数据。

在一种实施方式中,资源量配置模块包括:

第一配置子模块,用于在未查找到目标业务在历史周期的运行数据的情况下,确定目标业务是新业务,得到第一资源量,第一资源量包括:预先设置的执行器的数量、执行器的核数和单个执行器的内存量。在一种实施方式中,资源量配置模块包括:

第二配置子模块,用于在根据目标业务在历史周期的确定目标业务的业务逻辑发生更新的情况下,得到第一资源量,第一资源量包括:预先设置的执行器的数量、执行器的核数和单个执行器的内存量。

在一种实施方式中,第二配置子模块包括:

文件检验和计算单元,用于根据目标业务在当前周期的业务配置文件,计算第一文件检验和;将目标业务在历史周期的运行数据中的文件检验和,作为第二文件检验和;

文件检验和比较单元,用于在第一文件检验和与第二文件检验和不相同的情况下,确定业务逻辑发生更新。

在一种实施方式中,资源量配置模块包括:

上游业务确定子模块,用于根据目标业务的生产数据依赖关系确定上游业务;

第三配置子模块,用于上游业务在当前周期的运行数据和上游业务在历史周期的运行数据的差异大于第一阈值的情况下,得到第一资源量,第一资源量包括:预先设置的执行器的数量、执行器的核数和单个执行器的内存量。

在一种实施方式中,资源量配置模块还包括:

第四配置子模块,用于在差异小于第一阈值的情况下,得到第二资源量。

在一种实施方式中,第四配置子模块包括:

数据提取单元,用于从目标业务在历史周期的运行数据中提取目标业务在多个周期的运行数据,目标业务在每个周期的运行数据包括业务运行时间、执行器的数量、最大并行任务数、最大内存使用量和最大数据量行数;

执行器数量计算单元,用于根据目标业务在多个周期的业务平均运行时间、执行器的平均数量、最大并行任务数的平均值、最大数据量行数的平均值,得到执行器的数量;

内存量计算单元,用于根据目标业务在多个周期的最大内存使用量的平均值和执行器的数量,计算单个执行器的内存量;

第二资源量包括:执行器的数量、执行器的核数、单个执行器的内存量,其中,执行器的核数是预先设置的。

在一种实施方式中,调整模块包括:

资源量追加子模块,用于目标业务在当前周期的运行数据中,各执行器的总内存利用率超过第二阈值的情况下,增加运行目标业务的资源量。

在一种实施方式中,调整模块包括:

数据分布调整子模块,用于目标业务在当前周期的运行数据中,在至少一个执行器的实时数据量与实时总数据量的比值超过第三阈值的情况下,对各个执行器执行的任务数据重新分配。

第三方面,本申请实施例提供了一种电子设备,包括:

至少一个处理器;以及

与至少一个处理器通信连接的存储器;

其中,存储器存储有可被至少一个处理器执行的指令,指令被至少一个处理器执行,以使至少一个处理器能够执行本申请任意一项实施例所提供的方法。

第四方面,本申请实施例提供一种存储有计算机指令的非瞬时计算机可读存储介质,计算机指令用于使计算机执行本申请任意一项实施例所提供的方法。

上述申请中的一个实施例具有如下优点或有益效果:采用根据数据依赖关系确定了目标业务的上游业务,在目标业务运行之前,根据目标业务在历史周期的运行数据和上游业务在当前周期的运行数据,得到目标业务在当前周期的资源量,即预分配的资源量。在利用预分配的资源量运行目标业务的过程中,根据业务的执行器中的运行数据的变化实时调整资源量和/或目标业务在各执行器的数据分布的技术手段,所以克服了运行业务所需要的资源量无法适当分配的技术问题,达到提高了集群的资源利用率,使得业务运行性能相对稳定、可配置,即使底层环境发生变化,也会通过自动增加或减少资源量,保持业务运行性能相对稳定,同时,还可以通过业务运行性能的配置参数来配置业务运行性能的技术效果。

上述可选方式所具有的其他效果将在下文中结合具体实施例加以说明。

附图说明

附图用于更好地理解本方案,不构成对本申请的限定。其中:

图1是根据本申请实施例提供的一种资源分配方法的示意图;

图2是根据本申请实施例提供的另一种资源分配方法的示意图;

图3可以实现本申请实施例的一种资源分配方法的系统结构图;

图4可以实现本申请实施例的一种资源分配方法的流程图;

图5可以实现本申请实施例的业务运行监控模块活动图;

图6根据本申请实施例提供的一种资源分配装置的结构框图;

图7根据本申请实施例提供的另一种资源分配装置的结构框图;

图8是用来实现本申请实施例的一种资源分配方法的电子设备的框图。

具体实施方式

以下结合附图对本申请的示范性实施例做出说明,其中包括本申请实施例的各种细节以助于理解,应当将它们认为仅仅是示范性的。因此,本领域普通技术人员应当认识到,可以对这里描述的实施例做出各种改变和修改,而不会背离本申请的范围和精神。同样,为了清楚和简明,以下的描述中省略了对公知功能和结构的描述。

如图1所示,本申请实施例提供了一种资源分配方法,包括:

步骤s10:根据目标业务在历史周期的运行数据和上游业务在当前周期的运行数据,得到目标业务在当前周期的资源量,目标业务与上游业务具有数据依赖关系;

步骤s20:在当前周期内利用资源量运行目标业务,并监测目标业务在各执行器中的运行数据的变化;

步骤s30:根据目标业务在各执行器中的运行数据的变化,实时调整目标业务的资源量和/或目标业务在各执行器的数据分布。

在一种示例中,业务可以是由一个或多个etl过程组成的有明确执行任务的静态的代码模块。例如,业务可以是xml(扩展标记语言,extensiblemarkuplanguage)文件。

大数据业务中,资源量的类型可以包括存储资源、计算资源、网络资源、io资源等类型。资源量包括执行器数量、每个执行器中的内存量以及cpu核数。

每个业务内部分成多个作业(job),这些作业是串行执行,例如,a作业是读取数据,b作业是处理数据,c作业是写入数据。每个作业在执行的时候会拆分成多个阶段(stage),这些阶段是串行执行。每个阶段在执行器(executor)中产生的实例叫任务(task),多个任务是可以并行执行。执行器用于执行各个任务。例如,各执行器执行一批数据,就会产生与数据分区数相同的个数的任务。

业务的运行数据是与业务运行相关的数据,可以包括资源量、业务运行时间、最大并行任务数、最大内存使用量、最大数据量行数。

其中,业务的运行时间是从业务开始到业务运行完成经过的时间。

在读取数据的阶段(stage),可以确定任务(task)的最初的并行度,最初的并行度是由数据源特性或者读取的方式决定。当数据读入集群后,会对任务进行重分区,使得任务的并行度与业务并行度相等。在目标业务的多个任务中查找到最大的任务的并行度,就是最大并行任务数。

对每个作业(job)对应的每个阶段(stage)中所有任务(task)的数据量之和,取最大值,得到最大数据量行数。例如,目标业务有abc三个作业(job),a作业的数据量是500行,b作业的数据量是1000行,c作业的数据量是2000行,那么最大数据量行数就是2000行。

对每个作业(job)对应的每个阶段(stage)中所有任务(task)的内存使用量之和,取最大值,得到最大内存使用量。例如,目标业务有abc三个作业(job),a作业对应的阶段(stage)中任务(task)的数据量占用的内存是1g,b作业对应的阶段(stage)中任务(task)的数据量占用的内存是2g,c作业对应的阶段(stage)中任务(task)的数据量占用的内存是3g,那么,目标业务的最大内存使用量就是3g。

目标业务可以为当前待处理的业务。上游业务是与目标业务具有数据依赖关系的业务。数据依赖关系可以包括字段与字段之间、表与表之间、任务与任务之间的依赖关系。例如,上游业务的输出表是目标业务的输入表。

目标业务在历史周期的运行数据可以是过去一段时间内记录的目标业务的运行数据,例如,过去一周、一个月、一年的时间段内记录的运行数据。业务的运行是周期性的,每次运行都是一个周期。例如,历史周期可以是昨天,当前周期是今天,或者,历史周期是前一个小时,当前周期是当前小时等。

业务运行时间和执行器的数量之间构成负反馈系统。底层环境变化(例如,底层组件性能发生变化)导致某一个业务的运行性能发生变化,此时,可以通过自动调配资源量来抵消业务的运行性能的变化。例如,如果底层组件性能降低,则业务在下一运行周期时,通过自动增加资源量来弥补业务的运行性能的损失。如果底层组件性能提升,则业务在下一运行周期时,可以通过自动减少资源量来抵消业务性能的提升,节省了集群的资源。

在不考虑底层环境、上游业务、业务自身逻辑变化的情况下,执行器数量与业务运行性能的配置参数正相关。通过人工调整业务运行性能的配置参数,而上述的负反馈系统基本不被触发,业务运行性能会获得稳定的提升,业务运行性能可配置。

此外,底层环境变化对某一个具体业务带来的影响可能不够明显,但对于整个产品来说,底层环境变化会导致产品例行化运行的性能发生变化,可以自动通过产品整体的资源量调配来基本抵消产品运行性能的变化。

通过上述方案,在目标业务运行前,根据目标业务在历史周期的运行数据和上游业务在当前周期的运行数据确定预分配的资源量,即目标业务在当前周期的资源量。在利用预分配的资源量运行目标业务的过程中,又根据目标业务的执行器中的运行数据的变化实时调整资源量和/或目标业务在各执行器的数据分布。提高了集群的资源利用率,使得业务运行性能相对稳定、可配置。即使底层环境发生变化,也会通过自动增加或减少资源量,保持业务运行性能相对稳定。同时,还可以通过调整业务运行性能的配置参数来配置业务运行性能。

在一种实施方式中,如图2所示,方法还包括:

步骤s40:在目标业务运行完成的情况下,记录目标业务在当前周期的运行数据。

在目标业务运行完成之后,可以将目标业务在当前周期的运行数据写入运行日志表。写入运行日志表的运行数据可以包括:执行器的数量、单个执行器的内存量、文件检验和、业务运行时间、最大并行任务数、最大内存使用量、最大数据量行数。写入运行日志表的运行数据还可以包括:最长耗时作业(job)的编号、数据行数和耗时时长,最大数据体积作业(job)的编号、数据行数和耗时时长。在目标业务运行完成的情况下,记录业务运行时间可以作为下一周期对资源量进行调控时的参考数据。

本实施方式中,目标业务在下一个周期运行时,读取存入日志表的目标业务在当前周期的运行数据,作为下一周期的资源预分配的参考数据,提高了资源量的适应性和准确性。

在一种实施方式中,如图2所示,步骤s10包括:

步骤s101:在未查找到目标业务在历史周期的运行数据的情况下,确定目标业务是新业务,得到第一资源量,第一资源量包括:预先设置的执行器的数量、执行器的核数和单个执行器的内存量。

在一种示例中,可以在目标业务的历史运行日志中查找目标业务在历史周期的运行数据。如果未查找到目标业务的在历史周期的运行数据,则认为在目标业务为新业务。对于新业务,预先分配默认的第一资源量来运行新业务。默认的第一资源量中的执行器的数量、执行器的核数、单个执行器的内存量是预先设置的。

本实施方式中,在未查找到目标业务在历史周期的运行数据的情况下,利用预设的第一资源量来运行新业务,保证有足够的资源量来运行目标业务。

在一种实施方式中,如图2所示,步骤s10,包括:

步骤s102:在根据目标业务在历史周期的运行数据确定目标业务的业务逻辑发生更新的情况下,得到第一资源量;第一资源量包括:预先设置的执行器的数量、执行器的核数和单个执行器的内存量。业务逻辑是业务在运行时加载的业务配置文件与场景实例组合得到的。通过执行器执行业务逻辑,即可获得最终业务处理结果。例如,场景实例中包括数据抽取,在业务配置文件中包括数据抽取的对象信息(例如学生信息),抽取数据的数据源的信息(例如mysql数据源)。

本实施方式中,在查找到目标业务在历史周期的运行数据的情况下,并且确定了目标业务的业务逻辑发生更新,利用预设的第一资源量来运行业务逻辑发生更新的业务,保证有足够的资源量来运行目标业务。

在一种实施方式中,根据目标业务在历史周期的运行数据确定目标业务的业务逻辑发生更新,包括:

根据目标业务在当前周期的业务配置文件,计算第一文件检验和;

将目标业务在历史周期的运行数据中的文件检验和,作为第二文件检验和;

在第一文件检验和与第二文件检验和不相同的情况下,确定业务逻辑发生更新。

在一种示例中,业务每运行一次,都要加载一次业务配置文件,并计算一个文件校验和。可以用对比文件校验和,判断业务配置文件是否发生过修改。如果同一个业务在最近的几个运行周期,计算的文件检验和不相同,那么业务配置文件发生更新,进而确定业务逻辑发生更新。

在一种实施方式中,如图2所示,步骤s10包括:

步骤s103:根据目标业务的生产数据依赖关系确定上游业务;

步骤s104:上游业务在当前周期的运行数据和上游业务在历史周期的运行数据的差异大于第一阈值的情况下,得到第一资源量;第一资源量包括:预先设置的执行器的数量、执行器的核数和单个执行器的内存量。

在一种示例中,可以是直接或者间接通过sql(结构化查询语言,structuredquerylanguage)组件访问数据源,业务逻辑都可以用sql组件表达。在spark内置sqlparser(结构化查询语言的语法解释)模块。sqlparser模块将sql解析成抽象语法树,例如,可以借助开源的antlr4库来解析。解析得到的业务逻辑执行计划包括字段、输入表名、输出表名、过滤条件等。根据对业务的生产数据的组织,可以得到字段、表格等的生产数据依赖关系,例如,列级生产数据依赖关系、表级生产数据依赖关系。按照这个原理,可以对所有的待处理的业务做生产数据依赖分析,可以得出数据仓库里的所有字段、表格、业务的数据依赖关系。

目标业务可以由多个sql组件串联而成。将各个sql的生产数据依赖关系串联起来,即可得到目标业务的输入表的表格信息与输出表的表格信息。如果上游业务的输出表是目标业务的输入表,那么称上游业务是目标业务的依赖业务或者上游业务。

查看上游业务的历史运行日志,获取上游业务在历史周期的运行数据。如果上游业务在当前周期的运行数据和历史周期的运行数据的差异大于第一阈值的情况下,说明目标业务在当前周期可能也发生了更新,则分配第一资源量运行目标业务。

本实施方式中,如果上游业务的数据量发生显著变化,则目标业务的数据量也可能在当前周期发生显著变化,则分配预设的第一资源量来运行目标业务,保证了有足够的资源量来运行目标业务,提高了资源量分配的适应性和准确性。

一种实施方式中,方法还包括:

步骤s105:在差异小于第一阈值的情况下,得到第二资源量。

在一种示例中,如果目标业务的上游业务在当前周期的运行数据和历史周期的运行数据的差异小于第一阈值情况下,且目标业务在当前周期并未发生更新,则分配第二资源量运行目标业务。其中,第一阈值可以取大于或等于30%的取值范围。

本实施方式中,如果上游业务在当前周期的数据量没有发生显著变化,且目标业务在当前周期没有发生更新,则分配第二资源量来运行目标业务,保证了有适当的资源量来运行目标业务,提高了资源量分配的适应性和准确性。

一种实施方式中,第二资源量的计算方式,包括:

从目标业务在历史周期的运行数据中提取目标业务在多个周期的运行数据,目标业务在每个周期的运行数据包括业务运行时间、执行器的数量、最大并行任务数、最大内存使用量和最大数据量行数;

根据目标业务在多个周期的业务平均运行时间、执行器的平均数量、执行器的平均数量、最大并行任务数的平均值和最大数据量行数的平均值,得到执行器的数量;

根据目标业务在多个周期的最大内存使用量的平均值和执行器的数量,计算单个执行器的内存量;

第二资源量包括:执行器的数量、执行器的核数、单个执行器的内存量;

其中,执行器的核数是预先设置的。

在一种示例中,从目标业务在历史周期的运行数据中提取目标业务在多个周期的运行数据。

业务并行度计算公式为:

p=n*c*5

n:执行器数量,个/单位;c:单个执行器的核数,个/单位,默认为4,取值范围可以为3~5;p:业务运行并行度。

根据下述公式计算执行器的数量:

n_sum=n_base n_plus

在n_sum<7的情况下,n=n_sum

在n_sum>=7的情况下,

其中,向上取整函数;

n:执行器的数量,个/单位;

t:目标业务在多个周期的平均运行时间,秒/单位;

d:目标业务在多个周期的最大数据量行数的平均值,行/单位;

r:业务运行性能的配置参数,默认取值1.42;

p_h:目标业务在多个周期的最大并行任务数的平均值,个/单位;

n_h:目标业务在多个周期的执行器个数的平均数量(包括追加的执行器个数),个/单位。

将最大内存使用量的平均值s和计算得到的执行器的数量n代入公式m=max(2048,s/n*1.8),得到单个执行器的内存量m。

在一种示例中,底层环境变化(例如,底层组件性能发生变化)与业务运行性能变化正相关,底层环境变化与业务运行时间负相关。在下一个运行周期,按照第二资源计算公式计算执行器的数量时,执行器的数量与业务运行时间正相关,又由于业务运行时间与底层环境变化负相关,所以,底层环境变化与执行器的数量负相关。业务运行时间和执行器的数量之间构成负反馈系统。经过几个周期的调整,负反馈系统会从旧的平衡点达到新的平衡点,使得业务运行性能基本恢复到底层环境变化之前,保证了业务运行性能相对稳定。

例如,目标业务a在历史周期的运行时间a1分钟,分配的执行器为b1个。如果底层组件性能下降,导致业务运行性能下降,业务运行时间变为a2(a2>a1)。在下一运行周期运行业务时,由执行器数量n计算公式可知,执行器数量n会增加到b3(b3>b1),而执行器数量增加会带来业务运行性能的提升,业务运行时间变为a3(a1<a3<a2)。经过几个周期的调整,最终会形成新的平衡点,即,在计算第二资源时,得到b4个执行器(b4>b3>b1)运行业务,而b4的取值会使的业务运行时间变为a4(a4略大于a1)。总之,底层环境性能下降的时候,通过增加执行器数量,使得业务运行时长基本恢复到底层性能变化之前。

例如,目标业务b在历史周期的运行时间a1分钟,分配的执行器为b1个。如果底层组件性能上升,导致业务运行性能上升,业务运行时间变为a2(a2<a1)。在下一运行周期运行业务时,由执行器数量n计算公式可知,执行器数量n会减少到b3(b3<b1),而执行器数量减少会带来业务运行性能的下降,业务运行时间变为a3(a1>a3>a2)。经过几个周期的调整,最终会形成新的平衡点,即,在计算第二资源时,得到b4个执行器(b4<b3<b1)运行业务,而b4的取值会使的业务运行时间变为a4(a4略小于a1)。总之,底层环境性能上升的时候,通过减少执行器数量,使得业务运行时长基本恢复到底层性能变化之前。

在一种示例中,在不考虑底层环境、上游业务、业务自身逻辑变化的情况下,执行器数量与业务运行性能的配置参数r正相关。通过人工调整业务运行性能的配置参数r,而上述的负反馈系统基本不被触发,业务运行性能会获得一个稳定的提升,业务运行性能可配置。

此外,底层环境变化对某一个具体业务带来的影响可能不够明显,但对于整个产品来说,底层环境变化会导致产品例行化的运行性能发生变化,模块会自动通过产品整体的资源量调配来抵消产品运行性能的变化。

本实施方式中,通过自动调配资源量来抵消由于底层环境变化导致的业务运行性能的变化。同时,还可以通过调整业务运行性能的配置参数,来配置业务运行性能。

在一种实施方式中,如图2所示,步骤s30包括:

步骤s301:目标业务在当前周期的运行数据中,各执行器的总内存利用率超过第二阈值的情况下,增加运行目标业务的资源量。

在一种示例中,在目标业务运行的过程中,各执行器的总内存利用率超过80%的情况下,目标业务实时的执行器数量为基数,按照50%的比例主动追加执行器的数量,来共同承担后续任务的执行。例如,目标业务原来有5个执行器,5个各执行器的总内存利用率超过80%的情况下,追加3个执行器。

本实施方式中,在目标业务运行的过程中,实时监控目标业务的执行器的运行数据的变化情况,如有需要,及时追加资源量,提供给目标业务适当的资源量,避免了业务运行过程中由于资源量紧张导致的运行中断或者性能下降的技术问题。

在一种实施方式中,如图2所示,步骤s30包括:

步骤s302:目标业务在当前周期的运行数据中,在至少一个执行器的实时数据量与实时总数据量的比值超过第三阈值的情况下,对各个执行器执行的任务数据重新分配。

步骤s301和步骤s302并无必然的先后顺序。

在一种示例中,在目标业务运行的过程中,可能会出现数据倾斜的情况。例如,一个执行器的实时数据量和全部执行器的实时总数据量的比值超过第三阈值的情况下,触发任务数据重新分布。

第三阈值的计算公式为:

x=(x1 x2 ... xn)/n

t=s/x

x1~xn:各执行器实时持有的rdd(弹性分布式数据集,resilientdistributeddataset)数据块数,n是大于的正整数;x:各执行器实时持有的rdd数据块数的平均数;s:各执行器实时持有的rdd数据块数的标准差;t:调整任务数据分布的参考值,当t>1.0,则触发一次任务数据分布调整。

本实施方式中,通过监控各个执行器内部的任务数据的变化,实时调控各个执行器的任务数据分布,提高了业务的运行速度,有效避免了部分执行器承担的任务数据很多,而另外部分执行器承担的任务数据很少,导致整个业务的运行性能降低的技术问题。

本申请提供一种可以实现资源分配方法的系统。如图3所示,该系统包括交互层、引擎层和数据源。

在数据源中,数据抽取和数据写入的对象可以包括各种支持直接或者间接通过sql(结构化查询语言,structuredquerylanguage)组件访问的数据源。例如,mysql(关系型数据库管理系统)数据源、elasticsearch数据源、hive数据源等。

交互层用于向开发者(用户)提供交互接口。例如可以包括网络插座协议(websocket)接口、超文本传输协议(http/https)接口、传输控制协议(tcp)接口和命令行界面(cli)接口。交互层模块可以接受开发者上传的业务配置文件、资源配置文件、待处理业务的运行指令等。

在引擎层中的业务容器包括业务配置文件、资源配置文件和业务运行器。业务运行器包括资源分配模块、资源追加模块、数据分布调整模块、数据血缘模块、日志模块、监控模块、业务运行模块等。

业务配置文件可以包括开发者编写的业务的执行参数。待处理业务需要的动态信息的参数,例如获取时间的参数,获取天气的参数,或者获取用户信息的参数等。业务配置文件还可以包括待处理业务所对应的场景实例的标识信息。场景实例可以包括数据统计场景实例、信息录入场景实例、运维场景实例等。

资源配置文件包括预先设置的虚拟数据源的配置参数。利用该配置参数,可以使虚拟数据源与各实际数据源建立通信。访问虚拟数据源即可操作对应的实际数据源。

业务容器负责调用业务运行器。业务运行器是实际访问各数据源、运行业务的软件模块。业务运行器本身不存储业务逻辑。

如图4所示,利用spark系统对资源量进行分配的过程包括:

首先,业务容器接收用户的业务运行命令。对接收到的业务运行命令进行参数校验,以确定该命令的可执行性。业务运行命令中可以包括用户信息、和/或业务配置文件等。参数校验可以包括对用户权限的校验,或者对业务配置文件中的配置信息的完整性的校验等。

参数校验通过后,业务容器启动业务运行器,加载业务配置文件、资源配置文件等资源文件。

然后,业务容器中的资源分配模块根据目标业务名称,读取目标业务的历史运行日志,目标业务的历史运行日志中记载有目标业务在历史周期的运行数据。

如果资源分配模块并未读取到目标业务的历史运行日志,判定目标业务为新业务,则提供默认的第一资源量。第一资源量包括:预先设置的执行器的数量、执行器的核数和单个执行器的内存量。

如果资源分配模块读取到了目标业务的历史运行日志,且目标业务逻辑有更新,则仍然提供默认的第一资源量作为资源预分配方案。

数据血缘模块用于计算目标业务的生产数据依赖关系,并将其发送至资源分配模块。资源分配模块根据目标业务的生产数据依赖关系读取上游业务的运行日志。上游业务的运行日志中记载有上游业务在历史周期的运行数据和当前周期的运行数据。资源分配模块比较上游业务在当前周期的运行数据与历史周期中近期的运行数据的差异,如果差异小于第一阈值,则提供默认的第一资源量。

以上情况提供默认的第一资源量作为业务的预分配方案。

在上述情况下都没有使用默认的第一资源量时,则可以判定业务的当前运行数据与近期运行数据相似。利用资源预分配公式,结合目标业务在历史周期的运行数据,计算第二资源量。第二资源量包括:预先设置的执行器的核数、计算得到的执行器的数量、以及单个执行器的内存量。

上述情况提供计算得到的第二资源量作为业务的另一预分配方案。

业务运行模块根据第一资源或者第二资源运行目标业务,同时,启动一个独立线程运行监控模块。

如图5所示,监控模块用于对目标业务的各执行器的运行数据的变化进行监控。当监控到运行目标业务的资源量紧张时,各执行器的总内存利用率变化超过第二阈值,则利用资源追加模块追加资源量。例如,调用sparkcontext()的requestexecutors(请求动态分配执行器)追加指定个数的执行器。在运行目标业务的资源量不紧张的情况下,监控到目标业务的运行发生严重数据倾斜。如果任务数据在各执行器中分布不均衡,就会导致负载大的执行器计算耗时远比其他执行器多,由短板效应可知,目标业务运行性能会变差。任务数据在各执行器中分布不均衡的现象就叫数据倾斜。在至少一个执行器的实时数据量与实时总数据量的比值超过第三阈值的情况下,则利用数据分布调整模块对各个执行器执行的任务数据重新分配,使得每个执行器执行的任务数据保持均衡。例如,调用spark的repartition(重分区算子),让任务数据在各执行器之间重新分区。目标业务运行完之后,停止运行监控模块。

利用日志模块将目标业务的运行数据写入业务运行日志表。每个目标业务在运行过程中的运行数据都会在目标业务运行完成之后,以日志的形式写入运行日志表,作为当前周期的资源预分配的参考数据。

本实施例提供的资源量分配方法,能有效提高计算引擎集群的资源利用率,提高业务的运行速度。集群利用率可以提高150%,cpu密集型业务的运行性能可以提高200%~500%,对整个产品的运行性能可以提高约120%。

如图6所示,本申请实施例提供了一种资源分配装置100,包括:

资源量配置模块110,用于根据目标业务在历史周期的运行数据和上游业务在当前周期的运行数据,得到目标业务在当前周期的资源量,目标业务与上游业务具有数据依赖关系;

业务运行和监测模块120,用于在当前周期内利用资源量运行目标业务,并监测目标业务在各执行器中的运行数据的变化;

调整模块130,用于根据目标业务在各执行器中的运行数据的变化,实时调整目标业务的资源量和/或目标业务在各执行器的数据分布。

在一种实施方式中,如图7所示,本申请实施例提供了一种资源分配装置200,还包括:

数据记录模块140,用于在目标业务运行完成的情况下,记录目标业务在当前周期的运行数据。

在一种实施方式中,如图7所示,资源量配置模110包括:

第一配置子模块111,用于在未查找到目标业务在历史周期的运行数据的情况下,确定目标业务是新业务,得到第一资源量,第一资源量包括:预先设置的执行器的数量、执行器的核数和单个执行器的内存量。

在一种实施方式中,如图7所示,资源量配置模块110包括:

第二配置子模块112,用于在根据目标业务在历史周期的运行数据确定目标业务的业务逻辑发生更新的情况下,得到第一资源量,第一资源量包括:预先设置的执行器的数量、执行器的核数和单个执行器的内存量。

在一种实施方式中,第二配置子模块112包括:

文件检验和计算单元,用于根据目标业务在当前周期的业务配置文件,计算第一文件检验和;将目标业务在历史周期的运行数据中的文件检验和,作为第二文件检验和;

文件检验和比较单元,用于在第一文件检验和与第二文件检验和不相同的情况下,确定业务逻辑发生更新。

在一种实施方式中,如图7所示,资源量配置模块110包括:

上游业务确定子模块113,用于根据目标业务的生产数据依赖关系确定上游业务;

第三配置子模块114,用于上游业务在当前周期的运行数据和上游业务在历史周期的运行数据的差异大于第一阈值的情况下,得到第一资源量,第一资源量包括:预先设置的执行器的数量、执行器的核数和单个执行器的内存量。

在一种实施方式中,如图7所示,资源量配置模块110还包括:

第四配置子模块116,用于在差异小于第一阈值的情况下,得到第二资源量。

在一种实施方式中,第四配置子模块116包括:

第二数据提取单元,用于从目标业务在历史周期的运行数据中提取目标业务在多个周期的运行数据,目标业务在每个周期的运行数据包括业务运行时间、执行器的数量、最大并行任务数、最大内存使用量和最大数据量行数;

执行器数量计算单元,用于根据目标业务在多个周期的业务平均运行时间、执行器的平均数量、最大并行任务数的平均值和最大数据量行数的平均值,得到执行器的数量;

内存量计算单元,用于根据目标业务在多个周期的最大内存使用量的平均值和执行器的数量,计算单个执行器的内存量;

第二资源量包括:执行器的数量、执行器的核数、单个执行器的内存量;其中,执行器的核数是预先设置的。

在一种实施方式中,如图7所示,调整模块130包括:

资源量追加子模块131,用于目标业务在当前周期的运行数据中,各执行器的总内存利用率超过第二阈值的情况下,增加运行目标业务的资源量。

在一种实施方式中,如图7所示,调整模块130包括:

数据分布调整子模块132,用于目标业务在当前周期的运行数据中,在至少一个执行器的实时数据量与实时总数据量的比值超过第三阈值的情况下,对各个执行器执行的任务数据重新分配。

本申请实施例各装置中的各模块的功能可以参见上述方法中的对应描述,在此不再赘述。

根据本申请的实施例,本申请还提供了一种电子设备和一种可读存储介质。

如图8所示,是根据本申请实施例的一种资源配置方法的电子设备的框图。电子设备旨在表示各种形式的数字计算机,诸如,膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置,诸如,个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例,并且不意在限制本文中描述的和/或者要求的本申请的实现。

如图8所示,该电子设备包括:一个或多个处理器801、存储器802,以及用于连接各部件的接口,包括高速接口和低速接口。各个部件利用不同的总线互相连接,并且可以被安装在公共主板上或者根据需要以其它方式安装。处理器可以对在电子设备内执行的指令进行处理,包括存储在存储器中或者存储器上以在外部输入/输出装置(诸如,耦合至接口的显示设备)上显示图形用户界面(graphicaluserinterface,gui)的图形信息的指令。在其它实施方式中,若需要,可以将多个处理器和/或多条总线与多个存储器和多个存储器一起使用。同样,可以连接多个电子设备,各个设备提供部分必要的操作(例如,作为服务器阵列、一组刀片式服务器、或者多处理器系统)。图8中以一个处理器801为例。

存储器802即为本申请所提供的非瞬时计算机可读存储介质。其中,存储器存储有可由至少一个处理器执行的指令,以使至少一个处理器执行本申请所提供的资源配置的方法。本申请的非瞬时计算机可读存储介质存储计算机指令,该计算机指令用于使计算机执行本申请所提供的资源配置的方法。

存储器802作为一种非瞬时计算机可读存储介质,可用于存储非瞬时软件程序、非瞬时计算机可执行程序以及模块,如本申请实施例中的资源配置的方法对应的程序指令/模块(例如,附图6所示的资源量配置模块110、业务运行监测模块120和调整模块130)。处理器801通过运行存储在存储器802中的非瞬时软件程序、指令以及模块,从而执行服务器的各种功能应用以及数据处理,即实现上述方法实施例中的资源配置的方法。

存储器802可以包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需要的应用程序;存储数据区可存储根据资源配置方法的电子设备的使用所创建的数据等。此外,存储器802可以包括高速随机存取存储器,还可以包括非瞬时存储器,例如至少一个磁盘存储器件、闪存器件、或其他非瞬时固态存储器件。在一些实施例中,存储器802可选包括相对于处理器801远程设置的存储器,这些远程存储器可以通过网络连接至资源配置方法的电子设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

资源配置方法的电子设备还可以包括:输入装置803和输出装置804。处理器801、存储器802、输入装置803和输出装置804可以通过总线或者其他方式连接,图8中以通过总线连接为例。

输入装置803可接收输入的数字或字符信息,以及产生与资源配置方法的电子设备的用户设置以及功能控制有关的键信号输入,例如触摸屏、小键盘、鼠标、轨迹板、触摸板、指示杆、一个或者多个鼠标按钮、轨迹球、操纵杆等输入装置。输出装置804可以包括显示设备、辅助照明装置(例如,led)和触觉反馈装置(例如,振动电机)等。该显示设备可以包括但不限于,液晶显示器(liquidcrstaldispla,lcd)、发光二极管(lightemittingdiode,led)显示器和等离子体显示器。在一些实施方式中,显示设备可以是触摸屏。

此处描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、专用集成电路(applicationspecificintegratedcircuits,asic)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括:实施在一个或者多个计算机程序中,该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释,该可编程处理器可以是专用或者通用可编程处理器,可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令,并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

这些计算程序(也称作程序、软件、软件应用、或者代码)包括可编程处理器的机器指令,并且可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。如本文使用的,术语“机器可读介质”和“计算机可读介质”指的是用于将机器指令和/或数据提供给可编程处理器的任何计算机程序产品、设备、和/或装置(例如,磁盘、光盘、存储器、可编程逻辑装置(programmablelogicdevice,pld)),包括,接收作为机器可读信号的机器指令的机器可读介质。术语“机器可读信号”指的是用于将机器指令和/或数据提供给可编程处理器的任何信号。

为了提供与用户的交互,可以在计算机上实施此处描述的系统和技术,该计算机具有:用于向用户显示信息的显示装置(例如,crt(cathoderaytube,阴极射线管)或者lcd(液晶显示器)监视器);以及键盘和指向装置(例如,鼠标或者轨迹球),用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互;例如,提供给用户的反馈可以是任何形式的传感反馈(例如,视觉反馈、听觉反馈、或者触觉反馈);并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如,作为数据服务器)、或者包括中间件部件的计算系统(例如,应用服务器)、或者包括前端部件的计算系统(例如,具有图形用户界面或者网络浏览器的用户计算机,用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如,通信网络)来将系统的部件相互连接。通信网络的示例包括:局域网(localareanetwork,lan)、广域网(wideareanetwork,wan)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。

根据本申请实施例的技术方案,通过上述方案,通过上述方案,提高了集群的资源利用率,使得业务运行性能相对稳定、可配置。即使底层环境发生变化,通过自动增加或减少资源量,保持业务运行性能相对稳定。同时,还可以通过调整业务运行性能的配置参数来配置业务运行性能。

应该理解,可以使用上面所示的各种形式的流程,重新排序、增加或删除步骤。例如,本申请中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行,只要能够实现本申请公开的技术方案所期望的结果,本文在此不进行限制。

上述具体实施方式,并不构成对本申请保护范围的限制。本领域技术人员应该明白的是,根据设计要求和其他因素,可以进行各种修改、组合、子组合和替代。任何在本申请的精神和原则之内所作的修改、等同替换和改进等,均应包含在本申请保护范围之内。


技术特征:

1.一种资源分配方法,其特征在于,包括:

根据目标业务在历史周期的运行数据和上游业务在当前周期的运行数据,得到所述目标业务在当前周期的资源量,所述目标业务与所述上游业务具有数据依赖关系;

在所述当前周期内利用所述资源量运行所述目标业务,并监测所述目标业务在各执行器中的运行数据的变化;

根据所述目标业务在各执行器中的运行数据的变化,实时调整所述目标业务的资源量和/或所述目标业务在各所述执行器的数据分布。

2.根据权利要求1所述的方法,其特征在于,还包括:

在所述目标业务运行完成的情况下,记录所述目标业务在当前周期的运行数据。

3.根据权利要求1所述的方法,其特征在于,根据目标业务在历史周期的运行数据和上游业务在当前周期的运行数据,得到所述目标业务在当前周期的资源量,包括:

在未查找到所述目标业务在历史周期的运行数据的情况下,确定所述目标业务是新业务,得到第一资源量;

所述第一资源量包括:预先设置的所述执行器的数量、所述执行器的核数和单个所述执行器的内存量。

4.根据权利要求1所述的方法,其特征在于,根据目标业务在历史周期的运行数据和上游业务在当前周期的运行数据,得到所述目标业务在当前周期的资源量,包括:

在根据所述目标业务在历史周期的运行数据确定所述目标业务的业务逻辑发生更新的情况下,得到第一资源量;

所述第一资源量包括:预先设置的所述执行器的数量、所述执行器的核数和单个所述执行器的内存量。

5.根据权利要求4所述的方法,其特征在于,根据所述目标业务在历史周期的运行数据确定所述目标业务的业务逻辑发生更新,包括:

根据所述目标业务在当前周期的业务配置文件,计算第一文件检验和;

将所述目标业务在历史周期的运行数据中的文件检验和,作为第二文件检验和;

在所述第一文件检验和与所述第二文件检验和不相同的情况下,确定所述业务逻辑发生更新。

6.根据权利要求1所述的方法,其特征在于,根据目标业务在历史周期的运行数据和上游业务在当前周期的运行数据,得到所述目标业务在当前周期的资源量,包括:

根据所述目标业务的生产数据依赖关系确定所述上游业务;

所述上游业务在当前周期的运行数据和所述上游业务在历史周期的运行数据的差异大于第一阈值的情况下,得到第一资源量;

所述第一资源量包括:预先设置的所述执行器的数量、所述执行器的核数和单个所述执行器的内存量。

7.根据权利要求6所述的方法,其特征在于,还包括:

在所述差异小于所述第一阈值的情况下,得到第二资源量。

8.根据权利要求7所述的方法,其特征在于,所述第二资源量的计算方式包括:

从所述目标业务在历史周期的运行数据中提取所述目标业务在多个周期的运行数据,所述目标业务在每个周期的运行数据包括业务运行时间、所述执行器的数量、最大并行任务数、最大内存使用量和最大数据量行数;

根据所述目标业务在多个周期的业务平均运行时间、所述执行器的平均数量、最大并行任务数的平均值和最大数据量行数的平均值,得到所述执行器的数量;

根据所述目标业务在多个周期的最大内存使用量的平均值和所述执行器的数量,计算单个所述执行器的内存量;

所述第二资源量包括:所述执行器的数量、所述执行器的核数、单个所述执行器的内存量;

其中,所述执行器的核数是预先设置的。

9.根据权利要求1所述的方法,其特征在于,根据所述目标业务在各执行器中的运行数据的变化,实时调整所述目标业务的资源量和/或所述目标业务在各所述执行器的数据分布,包括:

所述目标业务在当前周期的运行数据中,各所述各执行器的总内存利用率超过第二阈值的情况下,增加运行所述目标业务的资源量。

10.根据权利要求1所述的方法,其特征在于,根据所述目标业务在各执行器中的运行数据的变化,实时调整所述目标业务的资源量和/或所述目标业务在各所述执行器的数据分布,包括:

所述目标业务在当前周期的运行数据中,在至少一个所述执行器的实时数据量与实时总数据量的比值超过第三阈值的情况下,对各个所述执行器执行的任务数据重新分配。

11.一种资源分配装置,其特征在于,包括:

资源量配置模块,用于根据目标业务在历史周期的运行数据和上游业务在当前周期的运行数据,得到所述目标业务在当前周期的资源量,所述目标业务与所述上游业务具有数据依赖关系;

业务运行和监测模块,用于在所述当前周期内利用所述资源量运行所述目标业务,并监测所述目标业务在各执行器中的运行数据的变化;

调整模块,用于根据所述目标业务在各执行器中的运行数据的变化,实时调整所述目标业务的资源量和/或所述目标业务在各所述执行器的数据分布。

12.根据权利要求11所述的装置,其特征在于,还包括:

数据记录模块,用于在所述目标业务运行完成的情况下,记录所述目标业务在当前周期的运行数据。

13.根据权利要求11所述的装置,其特征在于,所述资源量配置模块包括:

第一配置子模块,用于在未查找到所述目标业务在历史周期的运行数据的情况下,确定所述目标业务是新业务,得到第一资源量,所述第一资源量包括:预先设置的所述执行器的数量、所述执行器的核数和单个所述执行器的内存量。

14.根据权利要求11所述的装置,其特征在于,所述资源量配置模块包括:

第二配置子模块,用于在根据所述目标业务在历史周期的运行数据确定所述目标业务的业务逻辑发生更新的情况下,得到第一资源量,所述第一资源量包括:预先设置的所述执行器的数量、所述执行器的核数和单个所述执行器的内存量。

15.根据权利要求14所述的装置,其特征在于,所述第二配置子模块包括:

文件检验和计算单元,用于根据所述目标业务在当前周期的业务配置文件,计算第一文件检验和;将所述目标业务在历史周期的运行数据中的文件检验和,作为第二文件检验和;

文件检验和比较单元,用于在所述第一文件检验和与所述第二文件检验和不相同的情况下,确定所述业务逻辑发生更新。

16.根据权利要求11所述的装置,其特征在于,所述资源量配置模块包括:

上游业务确定子模块,用于根据所述目标业务的生产数据依赖关系确定所述上游业务;

第三配置子模块,用于所述上游业务在当前周期的运行数据和所述上游业务在历史周期的运行数据的差异大于第一阈值的情况下,得到第一资源量,所述第一资源量包括:预先设置的所述执行器的数量、所述执行器的核数和单个所述执行器的内存量。

17.根据权利要求16所述的装置,其特征在于,所述资源量配置模块还包括:

第四配置子模块,用于在所述差异小于所述第一阈值的情况下,得到第二资源量。

18.根据权利要求17所述的装置,其特征在于,所述第四配置子模块包括:

数据提取单元,用于从所述目标业务在历史周期的运行数据中提取所述目标业务在多个周期的运行数据,所述目标业务在每个周期的运行数据包括业务运行时间、所述执行器的数量、最大并行任务数、最大内存使用量和最大数据量行数;

执行器数量计算单元,用于根据所述目标业务在多个周期的业务平均运行时间、所述执行器的平均数量、最大并行任务数的平均值、最大数据量行数的平均值,得到所述执行器的数量;

内存量计算单元,用于根据所述目标业务在多个周期的最大内存使用量的平均值和所述执行器的数量,计算单个所述执行器的内存量;

所述第二资源量包括:所述执行器的数量、所述执行器的核数、单个所述执行器的内存量,其中,所述执行器的核数是预先设置的。

19.根据权利要求11所述的装置,其特征在于,所述调整模块包括:

资源量追加子模块,用于所述目标业务在当前周期的运行数据中,各所述各执行器的总内存利用率超过第二阈值的情况下,增加运行所述目标业务的资源量。

20.根据权利要求11所述的装置,其特征在于,所述调整模块包括:

数据分布调整子模块,用于所述目标业务在当前周期的运行数据中,在至少一个所述执行器的实时数据量与实时总数据量的比值超过第三阈值的情况下,对各个所述执行器执行的任务数据重新分配。

21.一种电子设备,其特征在于,包括:

至少一个处理器;以及

与所述至少一个处理器通信连接的存储器;

其中,所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述至少一个处理器执行,以使所述至少一个处理器能够执行权利要求1-10中任一项所述的方法。

22.一种存储有计算机指令的非瞬时计算机可读存储介质,其特征在于,所述计算机指令用于使所述计算机执行权利要求1-10中任一项所述的方法。

技术总结
本申请公开了一种资源分配方法、装置以及电子设备,涉及资源分配领域。具体实现方案为:根据目标业务在历史周期的运行数据和上游业务在当前周期的运行数据,得到目标业务在当前周期的资源量,目标业务与上游业务具有数据依赖关系;在当前周期内利用资源量运行目标业务,并监测目标业务在各执行器中的运行数据的变化;根据目标业务在各执行器中的运行数据的变化,实时调整目标业务的资源量和/或目标业务在各执行器的数据分布。提高了集群的资源利用率,使得业务运行性能相对稳定、可配置。即使底层环境发生变化,也会通过自动增加或减少资源量,保持业务运行性能相对稳定。同时,还可以通过调整业务运行性能的配置参数来配置业务运行性能。

技术研发人员:邱峰志;李辉
受保护的技术使用者:北京百度网讯科技有限公司
技术研发日:2020.01.13
技术公布日:2020.06.09

转载请注明原文地址: https://bbs.8miu.com/read-27874.html

最新回复(0)