本申请涉及计算机技术领域，特别是涉及一种物理资源分配方法、装置、计算机设备和存储介质。
背景技术：
Spark(一种用于大规模数据处理的计算引擎)任务在开发完成后提交至任务调度平台。任务调度平台可以对多个Spark任务调度执行。任务调度平台需要为每个Spark任务分配合适的物理资源，如CPU(Central Processing Unit，中央处理器)、内存等。资源分配不合理会导致Spark任务运行效率低下，甚至根本无法运行。然而，传统方式Spark任务的资源分配策略是一种静态的方法。即使存在资源分配不合理的情况也需要等到Spark任务进行版本更新后才能重新进行物理资源分配，由此对Spark任务运行效率造成较大影响。
技术实现要素：
基于此，有必要针对上述技术问题，提供一种能够不依赖Spark任务版本更新及时对Spark任务进行资源动态分配，进而提高Spark任务运行效率的物理资源分配方法、装置、计算机设备和存储介质。
一种物理资源分配方法，所述方法包括：接收终端提交的Spark任务及对应的配置文件；从所述配置文件中读取所述Spark任务的资源分配参数，根据所述资源分配参数进行物理资源分配；基于分配的物理资源执行所述Spark任务；在所述Spark任务执行期间，监测所述Spark任务的执行效率；当监测到所述执行效率低于阈值时，对所述配置文件中的资源分配参数进行调整；将所述Spark任务从已分配的物理资源调度至与调整后的资源分配参数相适应的物理资源上继续执行。
在其中一个实施例中，所述接收终端提交的Spark任务及对应的配置文件之前，还包括：接收终端发送的Spark任务开发请求；所述开发请求包含入口函数标识；识别所述入口函数标识对应的函数队列；所述函数队列包括多个业务函数；将多个所述业务函数分别转换为对应的多个基础任务；调用所述入口函数标识对应的群组装饰器将多个基础任务封装为多个任务组；配置多个任务组的调度顺序，基于所述调度顺序对多个任务组进行封装，得到所述Spark任务。
在其中一个实施例中，所述Spark任务包括Shell脚本；所述Shell脚本预置了对所述配置文件的回调函数；所述从所述配置文件中读取所述Spark任务的资源分配参数，包括：通过执行Shell脚本启动所述Spark任务；基于所述回调函数，生成对所述配置文件的回调指令；根据所述回调指令拉取对应的配置文件；从拉取到的配置文件中读取所述资源分配参数。
在其中一个实施例中，所述基于分配的物理资源执行所述Spark任务，包括：将所述Spark任务拆分为多个任务组；每个任务组具有对应的任务组标识；将所述任务组拆分为多个基础任务；每个基础任务具有对应的日志装饰器；基于分配的物理资源执行多个基础任务，生成每个基础任务的执行日志；利用所述日志装饰器，在相应基础任务的执行日志中添加所述基础任务对应的任务组标识；当所述Spark任务执行完毕时，对记录有相同任务组标识的多个执行日志进行收集，生成每个任务组标识对应的任务日志。
在其中一个实施例中，所述监测所述Spark任务的执行效率，包括：计算所述Spark任务的任务总量；根据所述任务总量测算所述Spark任务的任务时长；按照预设时间频率调用任务运行监控组件采集所述Spark任务的运行信息；根据所述运行信息计算所述Spark任务在多个时间节点的任务执行量；根据所述任务执行量及所述任务时长，计算所述Spark任务在多个时间节点的执行效率。
在其中一个实施例中，所述当监测到所述执行效率低于阈值时，对所述配置文件中的资源分配参数进行调整，包括：比较所述执行效率是否低于阈值；若是，根据所述任务总量及任务执行量计算剩余任务量；根据所述任务时长及当前的时间节点计算剩余时长；根据所述剩余任务量及剩余时长测算需要新增的物理资源；否则，根据所述运行信息记录的相邻两个时间节点的资源使用信息，计算资源利用率；根据所述资源利用率测算需要释放的物理资源；根据测算结果调整所述资源分配参数。
在其中一个实施例中，所述当监测到所述执行效率低于阈值时，对所述配置文件中的资源分配参数进行调整，包括：比较所述执行效率是否低于阈值；若是，标记所述Spark任务执行异常，获取所述Spark任务的任务日志；根据所述任务日志进行异常原因定位；若所述异常原因包括物理资源不足，根据所述配置文件记录的资源分配参数生成资源调整提示页面，将所述资源调整提示页面发送至所述终端；使所述终端在所述资源调整提示页面对所述资源分配参数进行调整。
一种物理资源分配装置，所述装置包括：资源分配模块，用于接收终端提交的Spark任务及对应的配置文件；从所述配置文件中读取所述Spark任务的资源分配参数，根据所述资源分配参数进行物理资源分配；效率监测模块，用于基于分配的物理资源执行所述Spark任务；在所述Spark任务执行期间，监测所述Spark任务的执行效率；资源调整模块，用于当监测到所述执行效率低于阈值时，对所述配置文件中的资源分配参数进行调整；将所述Spark任务从已分配的物理资源调度至与调整后的资源分配参数相适应的物理资源上继续执行。
一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现以下步骤：接收终端提交的Spark任务及对应的配置文件；从所述配置文件中读取所述Spark任务的资源分配参数，根据所述资源分配参数进行物理资源分配；基于分配的物理资源执行所述Spark任务；在所述Spark任务执行期间，监测所述Spark任务的执行效率；当监测到所述执行效率低于阈值时，对所述配置文件中的资源分配参数进行调整；将所述Spark任务从已分配的物理资源调度至与调整后的资源分配参数相适应的物理资源上继续执行。
一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：接收终端提交的Spark任务及对应的配置文件；从所述配置文件中读取所述Spark任务的资源分配参数，根据所述资源分配参数进行物理资源分配；基于分配的物理资源执行所述Spark任务；在所述Spark任务执行期间，监测所述Spark任务的执行效率；当监测到所述执行效率低于阈值时，对所述配置文件中的资源分配参数进行调整；将所述Spark任务从已分配的物理资源调度至与调整后的资源分配参数相适应的物理资源上继续执行。
上述物理资源分配方法、装置、计算机设备和存储介质，根据终端提交的配置文件中记录的Spark任务的资源分配参数，可以为终端提交的Spark任务分配物理资源；基于分配的物理资源，可以执行Spark任务；通过监测所述Spark任务的执行效率，可以根据监测结果对所述配置文件中的资源分配参数进行调整；将所述Spark任务调度至与调整后的资源分配参数相适应的物理资源执行。由于将资源分配参数以配置文件的方式进行单独存储，独立于Spark任务本身，从而可以摆脱Spark任务版本更新的限制灵活自由修改资源分配参数；实时监测Spark任务执行效率，并根据执行效率动态调整分配的物理资源，可以适应Spark任务对物理资源的实际需求，进而可以提高Spark任务执行效率。
附图说明
图1为一个实施例中物理资源分配方法的应用场景图；
图2为一个实施例中物理资源分配方法的流程示意图；
图3为一个实施例中物理资源分配装置的结构框图；
图4为一个实施例中计算机设备的内部结构图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
本申请提供的物理资源分配方法，可以应用于如图1所示的应用环境中。其中，终端102与服务器104通过网络进行通信。其中，终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备，服务器104可以用多个服务器组成的服务器集群来实现。终端102将Spark任务及对应的配置文件提交至服务器104。服务器104上部署了任务调度平台，对Spark任务调度执行。任务调度平台基于配置文件记录的资源分配参数为Spark任务分配相应的物理资源。任务调度平台将Spark任务调度至分配的物理资源上执行，并按照预设时间频率对Spark任务的执行效率监测。任务调度平台比较执行效率是否低于阈值。若执行效率低于阈值，根据任务总量及任务执行量计算剩余任务量；根据任务时长及当前的时间节点计算剩余时长；根据剩余任务量及剩余时长测算需要新增的物理资源。若执行效率大于或等于阈值，根据运行信息记录的相邻两个时间节点的资源使用信息，计算资源利用率；根据资源利用率测算需要释放的物理资源。任务调度平台停止执行Spark任务，根据测算结果调整资源分配参数，将Spark任务调度至与调整后的资源分配参数相适应的物理资源执行。上述物理资源分配过程，由于将资源分配参数以配置文件的方式进行单独存储，独立于Spark任务本身，从而可以摆脱Spark任务版本更新的限制灵活自由修改资源分配参数；实时监测Spark任务执行效率，并根据执行效率动态调整分配的物理资源，可以适应Spark任务对物理资源的实际需求，进而可以提高Spark任务执行效率。
在一个实施例中，如图2所示，提供了一种物理资源分配方法，以该方法应用于图1中的服务器为例进行说明，包括以下步骤：
步骤202，接收终端提交的Spark任务及对应的配置文件。
Spark任务对应的业务逻辑脚本包括Shell脚本。任务调度人员将spark任务的资源分配参数记录在配置文件中，并在Shell脚本中预置对配置文件的回调函数。资源分配参数可以是任务调度人员根据Spark任务的任务量预先估算的。
多个服务器组成的服务器集群，包括主节点Master和多个工作节点Worker。任务调度人员在终端通过spark-submit命令将Spark任务及对应的配置文件提交至主节点。主节点上部署了任务调度平台，用于对多个终端提交的多个Spark任务进行调度执行。任务调度平台将配置文件独立于Spark任务进行单独存储，并为每个Spark任务启动一个对应的Driver进程。根据预设的部署模式(deploy-mode)，Driver进程在本地启动该Spark任务或者在集群中某工作节点启动Spark任务。
步骤204，从配置文件中读取Spark任务的资源分配参数，根据资源分配参数进行物理资源分配。
任务调度平台基于Driver进程启动Spark任务，并为Spark任务分配物理资源。具体的，Driver进程调用Spark任务对应的Shell脚本，产生一个对配置文件的回调指令，根据回调指令读取配置文件中的资源分配参数。Driver进程根据读取到的资源分配参数，向集群管理器申请运行Spark任务需要使用的物理资源。集群管理器可以是Spark Standalone集群或YARN资源管理集群等。物理资源是指内存和CPU等。集群管理器根据资源分配参数在集群各工作节点上启动一定数量的Executor进程。容易理解，Driver进程及每个Executor进程本身也会占用一定物理资源。
步骤206，基于分配的物理资源执行Spark任务。
在申请到Spark任务执行所需的物理资源之后，任务调度平台基于Driver进程开始调度执行Spark任务。具体的，Driver进程将Spark任务拆分为多个异步执行的任务组stage，每个任务组stage包括多个异步执行和/或并发执行的基础任务task。Driver进程将一个任务组stage的多个基础任务task分配到多个Executor进程中执行。基础任务task是最小的执行单元。每个基础任务task的执行结果存储至Executor进程对应的内存或所在工作节点的磁盘文件中。在当前任务组stage所有基础任务task都执行完毕时，Driver进程在各个工作节点本地的磁盘文件中写入中间结果，并调度运行下一个任务组stage。如此循环往复，直到将Spark任务全部执行完为止。
步骤208，在Spark任务执行期间，监测Spark任务的执行效率。
在Spark任务执行期间，任务调度平台基于Driver进程监测Spark任务的执行效率，即计算基础任务task的执行速度。容易理解，基础任务task的执行速度与相应Executor进程的CPU核数等物理资源直接相关。通常，一个CPU同一时间执行一个线程。物理资源足够的情况下，当Executor进程上分配到的多个基础任务task时，可以调用多线程并发执行多个基础任务task，从而提高Spark任务的执行效率。
步骤210，当监测到执行效率低于阈值时，对配置文件中的资源分配参数进行调整。
任务调度平台基于Driver进程比较执行效率是否低于阈值。阈值可以根据实际需求自由设置，也可以动态变化，对此不做限制。若执行效率低于阈值，表示当前Spark任务存在物理资源不足的风险，任务调度平台生成停止执行指令，将停止执行指令发送至相应工作节点，从而结束相应Driver进程及Executor进程。任务调度平台测算需要新增的物理资源，根据测算结果对Spark任务对应配置文件记录的资源分配参数进行调整。若执行效率大于或等于阈值，表示当前Spark任务不存在物理资源不足的风险，或风险比较低。任务调度平台判断Spark任务已分配的物理资源是否具有空闲资源，测算需要释放的物理资源，根据测算结果对Spark任务对应配置文件记录的资源分配参数进行调整。
步骤212，将Spark任务从已分配的物理资源调度至与调整后的资源分配参数相适应的物理资源上继续执行。
任务调度平台基于调整后的资源分配参数，重新为Spark任务启动一个Driver进程，调用该新启动的Driver进程按照上述方式重新为Spark任务分配物理资源，即在集群多个工作节点重新启动一定数量的Executor进程。Driver进程将Spark任务调度至与调整后的资源分配参数相适应的物理资源执行，即Spark任务拆分得到的多个基础任务task发送至重新分配的多个Executor进程执行。任务调度平台基于Driver进程继续监测Spark任务的执行效率，并按照执行效率进行资源分配参数的调整，直至Spark任务执行完毕。
传统的资源分配参数固定配置在Spark任务的Shell脚本中，使得只有在等到Spark任务进行版本更新时才能进行资源分配参数变更，使得资源分配参数修改不便，进而影响Spark任务运行效率和运行结果。
本实施例中，根据终端提交的配置文件中记录的Spark任务的资源分配参数，可以为终端提交的Spark任务分配物理资源；基于分配的物理资源，可以执行Spark任务；通过监测Spark任务的执行效率，可以根据监测结果对配置文件中的资源分配参数进行调整；将Spark任务调度至与调整后的资源分配参数相适应的物理资源执行。由于将资源分配参数以配置文件的方式进行单独存储，独立于Spark任务本身，从而可以摆脱Spark任务版本更新的限制灵活自由修改资源分配参数；实时监测Spark任务执行效率，并根据执行效率动态调整分配的物理资源，可以适应Spark任务对物理资源的实际需求，进而可以提高Spark任务执行效率。
在一个实施例中，接收终端提交的Spark任务及对应的配置文件之前，还包括：接收终端发送的Spark任务开发请求；开发请求包含入口函数标识；识别入口函数标识对应的函数队列；函数队列包括多个业务函数；将多个业务函数分别转换为对应的多个基础任务；调用入口函数标识对应的群组装饰器将多个基础任务封装为多个任务组；配置多个任务组的调度顺序，基于调度顺序对多个任务组进行封装，得到Spark任务。
Spark任务基于多个业务函数实现某种业务功能。为了描述方便，将共同实现一种业务功能的多个业务函数称为函数队列。Spark任务具有对应的业务逻辑脚本。业务逻辑脚本包括多个函数队列。不同函数队列实现不同的业务功能。容易理解，对于业务功能的划分维度，Spark任务开发人员可以自由定义。当Spark任务的业务逻辑发生变更时，其中部分或全部业务功能对应的函数队列相应发生变更。函数队列中多个业务函数按照调度顺序排列，将其中第一调度顺序的业务函数称为入口函数。
上述Spark任务可以是基于本实施例提供的一种分布式并行计算框架开发而成。该框架包括任务装饰器、群组装饰器和群组容器。任务装饰器用于将业务函数转换为对应的基础任务task。群组装饰器用于将一个任务队列中多个基础任务task封装为对应的任务组Stage。群组容器用于将多个任务组封装为对应的任务群Job。
当开发人员调用本申请提供的分布式并行计算框架进行Spark任务开发时，可以通过终端向服务器发送开发请求。服务器根据开发请求获取分布式并行计算框架。服务器基于终端发送的第一调用请求，向终端返回任务装饰器。终端在业务逻辑脚本的每个入口函数处添加一个任务装饰器。具体的，在入口函数中添加一个任务装饰器对应的回调函数，并将回调函数的回调对象设置为任务装饰器，将回调函数的回调条件设置为入口函数被触发执行。在该入口函数被触发执行时，通过回调函数产生一个对相应任务装饰器的回调指令，服务器可以根据回调指令调用相应的任务装饰器，利用任务装饰器将入口函数对应函数队列中每个业务函数封装为对应的基础任务。
服务器基于终端发送的第二调用请求，向终端返回群组装饰器。群组装饰器包括多个组成要素，如状态检查器、前置检查器和垃圾清理器等。其中，状态检查器用于对封装生成的任务组的执行状态进行检查。前置检查器用于检测当前任务组是否满足执行条件。垃圾清理器用于对取消执行当前任务组时进行垃圾清理。群组装饰器中还记录了多项功能参数，如任务组的任务组标识Stage_id等。终端在业务逻辑脚本的每个入口函数处添加一个群组装饰器。具体的，终端在入口函数中添加一个群组装饰器对应的回调函数，并将回调函数的回调对象设置为群组装饰器，将回调函数的回调条件设置为生成入口函数对应的任务队列，对每个入口函数对应的群组装饰器中多个组成要素及各项参数进行配置。在入口函数被触发执行时，通过回调函数产生一个对相应群组装饰器的回调指令，服务器可以根据回调指令调用相应的群组装饰器，群组装饰器识别该入口函数对应的任务队列，将该任务队列中多个基础任务task封装为对应的任务组Stage。
服务器基于终端发送的第三调用请求，向终端返回群组容器。开发人员在终端将群组容器添加至业务逻辑脚本，并配置该群组容器对应的任务群标识。群组容器用于将多个任务组封装为任务群。换言之，群组容器用于容纳多个任务组，而这多个任务组作为相应群组容器的封装对象。如上述群组封装器的实现脚本所示，开发人员在终端将任务群标识Job_id添加至每个封装对象对应的群组装饰器，以建立任务组之间的封装关系。业务逻辑脚本中可以添加多个群组容器。根据群组封装器中的任务群标识，可判断将任务组封装至哪一任务群。容易理解，封装得到的一个或多个任务群Job即为上述Spark任务。
分布式并行计算框架中群组容器本身提供了异步执行函数。在将群组容器添加至业务逻辑脚本后，开发人员可以利用异步执行函数，在群组容器中预先定义多个任务组之间调度顺序的编排规则。编排规则包括多个任务组标识，以及多个任务组标识之间异步执行的先后调度顺序。
传统的多数分布式并行计算框架只能基于单个任务进行控制调度，缺乏业务层级的并发控制机制。如果开发人员期望基于多个任务实现业务层级的任务调度，则需要在开发过程额外维护一张甚至多张用于记录任务间调度顺序的数据表，给开发人员带来诸多不便。
本实施例中，由于Spark任务中预先集成了群组装饰器，而群组装饰器本身提供任务封装以及调度顺序编排能力，根据业务逻辑将多个零散的基础任务封装为能够实现某种业务功能的任务组或任务群，进而能够无需额外维护数据表即可从业务层级实现任务调度，相比传统的将多个零散的基础任务的调度顺序逐个填写在数据表中的方式，可以大大简化Spark任务开发。
在一个实施例中，Spark任务包括Shell脚本；Shell脚本预置了对配置文件的回调函数；从配置文件中读取Spark任务的资源分配参数，包括：通过执行Shell脚本启动Spark任务；基于Shell脚本预置的回调函数，生成对配置文件的回调指令；根据回调指令拉取对应的配置文件；从拉取到的配置文件中读取资源分配参数。
Spark任务对应的业务逻辑脚本包括Shell脚本、Submit脚本和Class脚本等。任务调度平台通过加载Shell脚本启动Spark任务。Shell脚本用于记录执行Spark任务需要的数据参数，如Submit脚本或Class脚本的执行入参。传统的将Spark任务的资源分配参数也记录至Shell脚本，而Shell脚本固定封装在Spark任务，只能随Spark任务的版本更新进行相应数据参数的变更。本实施例将资源分配参数记录至独立于Spark任务的配置文件，并在Shell脚本中预置对配置文件的回调函数。当Shell脚本被调度执行时，基于回调函数生成回调指令。Driver进程根据回调指令携带的文件标识拉取对应的配置文件从拉取到的配置文件中读取资源分配参数。
本实施例中，由于将资源分配参数以配置文件的方式进行单独存储，独立于Spark任务本身，从而可以摆脱Spark任务版本更新的限制灵活自由修改资源分配参数。
在一个实施例中，基于分配的物理资源执行Spark任务，包括：将Spark任务拆分为多个任务组；每个任务组具有对应的任务组标识；将任务组拆分为多个基础任务；每个基础任务具有对应的日志装饰器；基于分配的物理资源执行多个基础任务，生成每个基础任务的执行日志；利用日志装饰器，在相应基础任务的执行日志中添加基础任务对应的任务组标识；当Spark任务执行完毕时，对记录有相同任务组标识的多个执行日志进行收集，生成每个任务组标识对应的任务日志。
服务器可以按照宽依赖窄依赖的逻辑或者上述封装过程的逆向逻辑将Spark任务拆分为多个任务组，将每个任务组拆分为多个基础任务。服务器按照任务群内预先编排的多个任务组的调度顺序，对任务群内多个任务组进行调度执行。换言之，服务器将第一调度顺序任务组的多个基础任务分配至多个工作节点执行，待第一调度顺序任务组的多个基础任务全部执行完毕执行下一调度顺序任务组的多个基础任务。当基础任务被执行时，生成对应的执行日志。
由于服务器主节点将多个基础任务分配至集群内多个工作节点进行执行，使得执行不同基础任务生成的执行日志分散在多个服务器或多个虚拟机，进而使开发人员只能看到零散黑盒的任务层级的调度情况。但开发人员通常只关心业务层级的任务调度，这给开发人员查阅日志带来极大不便。
为了解决上述问题，本实施例提供的分布式并行计算框架还包括日志装饰器。日志装饰器使Spark任务能够从业务维度进行日志生成，即控制实现同一种业务功能的多个基础任务的执行日志集中展示。
当开发人员调用本申请提供的分布式并行计算框架进行Spark任务开发时，服务器基于终端发送的第四调用请求，向终端返回日志装饰器。开发人员通过终端在业务逻辑脚本的每个入口函数处添加一个日志装饰器。同一入口函数对应函数队列中多个业务函数对应同一日志装饰器。开发人员通过终端在部署的日志装饰器中指定日志处理方式。日志装饰器具有多种不同的日志处理方式，如生成每个任务组对应的日志，或生成每个任务群对应的日志等。根据指定的日志处理方式，在日志装饰器中添加对应的任务组标识或任务群标识。
当基础任务被执行时，生成对应的执行日志，调用相应日志装饰器，日志装饰器按照指定的日志处理方式在任务日志中插入对应的任务组标识或任务群标识等。在某种业务执行完毕时，日志装饰器在执行该项业务的多个服务器或多个虚拟机中采集具有相同任务组标识或任务群标识的多个执行日志，对采集到的多个执行日志进行整合，生成每个任务组标识或任务群标识对应的任务日志，将任务日志返回终端进行展示。
本实施例中，Spark任务中预置了每个入口函数对应的日志装饰器。日志装饰器本身提供从业务层级进行日志采集的能力，在多个服务器执行基础任务生成零散的执行日志后，自动从业务层级进行日志收集和整合，解决了因日志分散造成的日志查阅不便的问题。
在一个实施例中，监测Spark任务的执行效率，包括：计算Spark任务的任务总量；根据任务总量测算Spark任务的任务时长；按照预设时间频率调用任务运行监控组件采集Spark任务的运行信息；根据运行信息计算Spark任务在多个时间节点的任务执行量；根据任务执行量及任务时长，计算Spark任务在多个时间节点的执行效率。
在Spark任务执行期间，Driver进程实时监测Spark任务的执行效率。Spark任务的执行效率是指单位时间的任务执行量。具体的，Driver进程计算Spark任务的任务总量，并根据任务总量测算Spark任务的任务时长。任务调度平台可以按照预设时间频率调用预设的任务运行监控组件采集Spark任务的运行信息。任务运行监控组件可以是REST接口(Representational State Transfer，表述性状态传递)等。Spark任务的运行信息包括当前时刻多个任务组的执行状态，以及执行状态为已执行的任务组的任务量，执行状态为执行中的任务组中已执行的基础任务的任务量等。
Driver进程根据执行状态为已执行的任务组的任务量，执行状态为执行中的任务组中已执行的基础任务的任务量，计算Spark任务在当前时刻的任务执行量。Driver进程根据记录的开始执行Spark任务的初始时刻和当前时刻计算执行时长。Driver进程根据任务执行量及执行时长测算Spark任务在当前时间节点的执行效率。
本实施例中，根据实时监测得到的Spark任务的任务执行量，及预先测算的执行Spark任务需要的任务时长，计算Spark任务在不同监测时间节点的执行效率，可以使测算得到的执行效率更加贴合Spark任务实际运行情况，进而提高执行效率的计算准确率。
在一个实施例中，当监测到执行效率低于阈值时，对配置文件中的资源分配参数进行调整，包括：比较执行效率是否低于阈值；若是，根据任务总量及任务执行量计算剩余任务量；根据任务时长及当前的时间节点计算剩余时长；根据剩余任务量及剩余时长测算需要新增的物理资源；否则，根据运行信息记录的相邻两个时间节点的资源使用信息，计算资源利用率；根据资源利用率测算需要释放的物理资源；根据测算结果调整资源分配参数。
任务调度平台基于Driver进程可以根据对Spark任务执行效率的监测结果自动对资源分配参数进行调整。具体的，Driver进程比较执行效率是否低于阈值。若是，Driver进程根据测算的Spark任务的任务总量及任务执行量，计算剩余任务量，并根据测算的执行Spark任务需要的任务时长及当前的时间节点，计算剩余时长。Driver进程根据剩余任务量及剩余时长，计算Spark任务的的目标执行效率。Driver进程读取配置文件记录的资源分配参数，根据监测得到的Spark任务在当前时刻实际的执行效率和对应分配的物理资源，确定达到目标执行效率需要的目标物理资源。容易理解，目标物理资源与已分配的物理资源的差异即为需要新增的物理资源。Driver进程根据目标物理资源对配置文件记录的资源分配参数进行调整。
基于预设的任务运行监控组件采集的Spark任务的运行信息还包括Spark任务的资源使用信息，如CPU使用率，内存剩余空间容量等。若执行效率大于或等于阈值，Driver进程根据采集的相邻两个时间节点的资源使用信息，计算物理资源的资源利用率，根据资源利用率判断已分配的物理资源是否存在空闲物理资源。Driver进程读取配置文件记录的资源分配参数，根据资源分配参数以及资源利用率，确定需要释放的空闲物理资源。Driver进程根据空闲物理资源对配置文件记录的资源分配参数进行调整。
本实施例中，根据对Spark任务执行效率的监测结果自动对资源分配参数进行调整，在执行效率低于阈值时及时进行物理资源新增，以保证Spark任务的执行效率和执行成功率；在执行效率大于或等于阈值时即使进行物理资源释放，可以提高物理资源利用率，减少对物理资源的浪费。
在一个实施例中，当监测到执行效率低于阈值时，对配置文件中的资源分配参数进行调整，包括：比较执行效率是否低于阈值；若是，标记Spark任务执行异常，获取Spark任务的任务日志；根据任务日志进行异常原因定位；若异常原因包括物理资源不足，根据配置文件记录的资源分配参数生成资源调整提示页面，将资源调整提示页面发送至终端；使终端在资源调整提示页面对资源分配参数进行调整。
当需要对资源分配参数进行调整时，Driver进程向终端发送资源调整提示。具体的，Driver进程比较执行效率是否低于阈值。若是，表示Spark任务可能发生执行异常，Driver进程获取Spark任务的任务日志，对任务日志中多条执行记录进行遍历，筛选执行异常的执行记录，根据执行异常的执行记录在Spark任务对应的业务逻辑脚本中进行异常原因定位。如果异常原因包括物理资源不足，则停止执行Spark任务，根据配置文件记录的资源分配参数生成资源调整提示页面，将资源调整提示页面发送至终端。任务调度人员可以通过终端在资源调整提示页面对资源分配参数进行调整。在另一个实施例中，任务调度人员随时可以停止运行的Spark任务，在配置文件中对相应资源分配参数进行修改后重启相应Spark任务，不再受Spark版本限制。
任务调度平台基于调整后的资源分配参数，重新为Spark任务启动一个Driver进程，调用该新启动的Driver进程按照调整后的资源分配参数重新为Spark任务分配物理资源，基于重新分配的物理资源重启执行异常的Spark任务。
本实施例中，根据对Spark任务执行效率的监测结果自动判断是否需要对资源分配参数进行调整，若需要对资源分配参数进行调整，及时向终端发送资源调整提示，并在资源调整提示页面展示原始设置的物理资源参数，方便用户参照修改。
应该理解的是，虽然图2的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
在一个实施例中，如图3所示，提供了一种物理资源分配装置，包括：资源分配模块302、效率监测模块304和资源调整模块306，其中：
资源分配模块302，用于接收终端提交的Spark任务及对应的配置文件；从配置文件中读取Spark任务的资源分配参数，根据资源分配参数进行物理资源分配。
效率监测模块304，用于基于分配的物理资源执行Spark任务；在Spark任务执行期间，监测Spark任务的执行效率。
资源调整模块306，用于当监测到执行效率低于阈值时，对配置文件中的资源分配参数进行调整；将Spark任务从已分配的物理资源调度至与调整后的资源分配参数相适应的物理资源上继续执行。
在一个实施例中，该装置还包括任务封装模块308，用于接收终端发送的Spark任务开发请求；开发请求包含入口函数标识；识别入口函数标识对应的函数队列；函数队列包括多个业务函数；将多个业务函数分别转换为对应的多个基础任务；调用入口函数标识对应的群组装饰器将多个基础任务封装为多个任务组；配置多个任务组的调度顺序，基于调度顺序对多个任务组进行封装，得到Spark任务。
在一个实施例中，Spark任务包括Shell脚本；Shell脚本预置了对配置文件的回调函数；资源分配模块302还用于通过执行Shell脚本启动Spark任务；基于Shell脚本预置的回调函数，生成对配置文件的回调指令；根据回调指令拉取对应的配置文件；从拉取到的配置文件中读取资源分配参数。
在一个实施例中，效率监测模块304还用于将Spark任务拆分为多个任务组；每个任务组具有对应的任务组标识；将任务组拆分为多个基础任务；每个基础任务具有对应的日志装饰器；基于分配的物理资源执行多个基础任务，生成每个基础任务的执行日志；利用日志装饰器，在相应基础任务的执行日志中添加基础任务对应的任务组标识；当Spark任务执行完毕时，对记录有相同任务组标识的多个执行日志进行收集，生成每个任务组标识对应的任务日志。
在一个实施例中，效率监测模块304还用于计算Spark任务的任务总量；根据任务总量测算Spark任务的任务时长；按照预设时间频率调用任务运行监控组件采集Spark任务的运行信息；根据运行信息计算Spark任务在多个时间节点的任务执行量；根据任务执行量及任务时长，计算Spark任务在多个时间节点的执行效率。
在一个实施例中，资源调整模块306还用于比较执行效率是否低于阈值；若是，根据任务总量及任务执行量计算剩余任务量；根据任务时长及当前的时间节点计算剩余时长；根据剩余任务量及剩余时长测算需要新增的物理资源；否则，根据运行信息记录的相邻两个时间节点的资源使用信息，计算资源利用率；根据资源利用率测算需要释放的物理资源；根据测算结果调整资源分配参数。
在一个实施例中，资源调整模块306还用于比较执行效率是否低于阈值；若是，标记Spark任务执行异常，获取Spark任务的任务日志；根据任务日志进行异常原因定位；若异常原因包括物理资源不足，根据配置文件记录的资源分配参数生成资源调整提示页面，将资源调整提示页面发送至终端；使终端在资源调整提示页面对资源分配参数进行调整。
关于物理资源分配装置的具体限定可以参见上文中对于物理资源分配方法的限定，在此不再赘述。上述物理资源分配装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图4所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储配置文件。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种物理资源分配方法。
本领域技术人员可以理解，图4中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
在一个实施例中，提供了一种计算机设备，包括存储器和处理器，该存储器存储有计算机程序，该处理器执行计算机程序时实现以下步骤：接收终端提交的Spark任务及对应的配置文件；从配置文件中读取Spark任务的资源分配参数，根据资源分配参数进行物理资源分配；基于分配的物理资源执行Spark任务；在Spark任务执行期间，监测Spark任务的执行效率；当监测到执行效率低于阈值时，对配置文件中的资源分配参数进行调整；将Spark任务从已分配的物理资源调度至与调整后的资源分配参数相适应的物理资源上继续执行。
在一个实施例中，处理器执行计算机程序时还实现以下步骤：接收终端发送的Spark任务开发请求；开发请求包含入口函数标识；识别入口函数标识对应的函数队列；函数队列包括多个业务函数；将多个业务函数分别转换为对应的多个基础任务；调用入口函数标识对应的群组装饰器将多个基础任务封装为多个任务组；配置多个任务组的调度顺序，基于调度顺序对多个任务组进行封装，得到Spark任务。
在一个实施例中，Spark任务包括Shell脚本；Shell脚本预置了对配置文件的回调函数；处理器执行计算机程序时还实现以下步骤：通过执行Shell脚本启动Spark任务；基于Shell脚本预置的回调函数，生成对配置文件的回调指令；根据回调指令拉取对应的配置文件；从拉取到的配置文件中读取资源分配参数。
在一个实施例中，处理器执行计算机程序时还实现以下步骤：将Spark任务拆分为多个任务组；每个任务组具有对应的任务组标识；将任务组拆分为多个基础任务；每个基础任务具有对应的日志装饰器；基于分配的物理资源执行多个基础任务，生成每个基础任务的执行日志；利用日志装饰器，在相应基础任务的执行日志中添加基础任务对应的任务组标识；当Spark任务执行完毕时，对记录有相同任务组标识的多个执行日志进行收集，生成每个任务组标识对应的任务日志。
在一个实施例中，处理器执行计算机程序时还实现以下步骤：计算Spark任务的任务总量；根据任务总量测算Spark任务的任务时长；按照预设时间频率调用任务运行监控组件采集Spark任务的运行信息；根据运行信息计算Spark任务在多个时间节点的任务执行量；根据任务执行量及任务时长，计算Spark任务在多个时间节点的执行效率。
在一个实施例中，处理器执行计算机程序时还实现以下步骤：比较执行效率是否低于阈值；若是，根据任务总量及任务执行量计算剩余任务量；根据任务时长及当前的时间节点计算剩余时长；根据剩余任务量及剩余时长测算需要新增的物理资源；否则，根据运行信息记录的相邻两个时间节点的资源使用信息，计算资源利用率；根据资源利用率测算需要释放的物理资源；根据测算结果调整资源分配参数。
在一个实施例中，处理器执行计算机程序时还实现以下步骤：比较执行效率是否低于阈值；若是，标记Spark任务执行异常，获取Spark任务的任务日志；根据任务日志进行异常原因定位；若异常原因包括物理资源不足，根据配置文件记录的资源分配参数生成资源调整提示页面，将资源调整提示页面发送至终端；使终端在资源调整提示页面对资源分配参数进行调整。
在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：接收终端提交的Spark任务及对应的配置文件；从配置文件中读取Spark任务的资源分配参数，根据资源分配参数进行物理资源分配；基于分配的物理资源执行Spark任务；在Spark任务执行期间，监测Spark任务的执行效率；当监测到执行效率低于阈值时，对配置文件中的资源分配参数进行调整；将Spark任务从已分配的物理资源调度至与调整后的资源分配参数相适应的物理资源上继续执行。
在一个实施例中，计算机程序被处理器执行时还实现以下步骤：接收终端发送的Spark任务开发请求；开发请求包含入口函数标识；识别入口函数标识对应的函数队列；函数队列包括多个业务函数；将多个业务函数分别转换为对应的多个基础任务；调用入口函数标识对应的群组装饰器将多个基础任务封装为多个任务组；配置多个任务组的调度顺序，基于调度顺序对多个任务组进行封装，得到Spark任务。
在一个实施例中，Spark任务包括Shell脚本；Shell脚本预置了对配置文件的回调函数；计算机程序被处理器执行时还实现以下步骤：通过执行Shell脚本启动Spark任务；基于Shell脚本预置的回调函数，生成对配置文件的回调指令；根据回调指令拉取对应的配置文件；从拉取到的配置文件中读取资源分配参数。
在一个实施例中，计算机程序被处理器执行时还实现以下步骤：将Spark任务拆分为多个任务组；每个任务组具有对应的任务组标识；将任务组拆分为多个基础任务；每个基础任务具有对应的日志装饰器；基于分配的物理资源执行多个基础任务，生成每个基础任务的执行日志；利用日志装饰器，在相应基础任务的执行日志中添加基础任务对应的任务组标识；当Spark任务执行完毕时，对记录有相同任务组标识的多个执行日志进行收集，生成每个任务组标识对应的任务日志。
在一个实施例中，计算机程序被处理器执行时还实现以下步骤：计算Spark任务的任务总量；根据任务总量测算Spark任务的任务时长；按照预设时间频率调用任务运行监控组件采集Spark任务的运行信息；根据运行信息计算Spark任务在多个时间节点的任务执行量；根据任务执行量及任务时长，计算Spark任务在多个时间节点的执行效率。
在一个实施例中，计算机程序被处理器执行时还实现以下步骤：比较执行效率是否低于阈值；若是，根据任务总量及任务执行量计算剩余任务量；根据任务时长及当前的时间节点计算剩余时长；根据剩余任务量及剩余时长测算需要新增的物理资源；否则，根据运行信息记录的相邻两个时间节点的资源使用信息，计算资源利用率；根据资源利用率测算需要释放的物理资源；根据测算结果调整资源分配参数。
在一个实施例中，计算机程序被处理器执行时还实现以下步骤：比较执行效率是否低于阈值；若是，标记Spark任务执行异常，获取Spark任务的任务日志；根据任务日志进行异常原因定位；若异常原因包括物理资源不足，根据配置文件记录的资源分配参数生成资源调整提示页面，将资源调整提示页面发送至终端；使终端在资源调整提示页面对资源分配参数进行调整。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。
以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
以上实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。