基于混合分布架构的计算资源分配方法、装置和存储介质与流程

本发明涉及大数据处理技术领域，尤其涉及一种基于混合分布架构的计算资源分配方法、装置和存储介质。

背景技术：

大数据技术的兴起，再一次激发了人工智能的生命力。2016年的围棋大战又一次引爆了人工智能的热潮，正是因为有着成熟稳定的大数据技术支撑，才能完成alphago背后海量的计算任务。apachespark是专为大规模数据处理而设计的快速通用的计算引擎，拥有hadoopmapreduce所具有的优点,但不同于mapreduce的是，job中间输出结果可以保存在内存中，从而不再需要读写hdfs(分布式文件系统)，因此spark能更好地适用于数据挖掘与机器学习等需要迭代的的算法。近些年来很多构建于spark之上的深度学习框架被提出，虽然它们均是架设在spark上的，但配置过程与使用接口均不相同，多个框架同时使用时亦会发生资源抢占的情况。另一方面，传统的计算机运算处理核心资源一般是指中央处理器(cpu)，但是，随着人工智能等技术的发展，计算需求也呈现多样性，单纯的cpu已然无法满足计算任务的实时性要求。

技术实现要素：

本发明要解决的技术问题是，提供一种基于混合分布架构的计算资源分配方法、装置和存储介质计算，用以合理分配资源，满足计算任务多样性的需求。

本发明采用的技术方案是，提供一种基于混合计算资源的分布式计算系统，包括计算引擎层、混合计算封装层和资源调度层，其中：

所述计算引擎层由多个构建在同一个spark计算引擎上的深度学习框架组成；

所述混合计算封装层，用于针对所述计算引擎层统一封装各个深度学习框架的访问接口；

所述资源调度层包括多种异构计算资源，所述异构计算资源包括以下至少一项：中央处理单元cpu、图形处理单元gpu和现场可编程门阵列fpga；在所述资源调度层，根据待处理任务的任务类型划分不同的任务队列，根据不同物理机搭载的计算资源类型划分不同的逻辑集群中，根据待处理任务的任务类，将任务队列中的任务分配到对应的逻辑集群中执行。

所述资源调度层，具体用于根据为物理机标注机器标签，将物理机划分不同的逻辑集群，所述机器标签为根据物理机搭载的计算资源类型标注的；根据处理的任务类型，为不同的任务队列添加队列标签；针对任一任务队列，根据该任务队列对应的队列标签，将该任务队列中的任务调度到具有与所述队列标签相同标签的物理机上执行。

所述资源调度层包括节点管理器和资源管理器，所述节点管理器部署于每一物理机上，所述资源管理器部署于其中一台物理机上，其中：

所述节点管理器，用于向所述资源管理器发送注册请求，所述注册请求中携带有自身所在物理机的可用资源信息，所述可用资源信息包括以下至少一项：cpu总量，内存总量，gpu虚拟数量和fpga虚拟数量。

所述节点管理器，还用于在系统运行过程中，向所述资源管理器上报自身所在物理机的资源状态信息，所述资源状态信息包括空闲资源信息和已分配资源信息；

所述资源管理器，还用于根据各个节点管理器上报的资源状态信息，为任务队列中的任务调度资源。

所述资源管理器，具体用于针对每一任务队列，分别确定每一任务队列对应的资源占用份额；根据确定出的资源占用份额，按照由小到大的顺序为任务队列调度资源。

所述计算引擎层，还用于通过所述访问接口接收用户请求，根据所述用户请求中携带的请求参数，为所述用户请求启动相应的深度学习框架。

所述深度学习框架，还用于根据所述用户请求，向所述资源管理器发送资源调度请求，所述资源调度请求中携带有资源需求信息；

所述资源管理器，还用于根据各个节点管理器的资源状态信息和所述资源需求信息，针对所述资源调度请求分配对应的节点管理器；向分配的节点管理器发送容器启动命令；

所述节点管理器，具体用于如果根据所述资源需求信息，判断出所述容器启动需要加速资源，则从空闲加速资源列表中查找空闲加速资源启动容器。

所述节点管理器，还用于减少维护的空闲加速资源数量，并在已分配加速资源列表中记录容器标识和为其分配的加速资源数量之间的对应关系。

所述节点管理器，还用于在检测到所述容器运行结束时，如果判断出所述容器中含有加速资源，则根据容器标识，从已分配加速资源列表中查找为所述容器分类的加速资源数量，根据查找到的加速资源数量，在空闲加速资源列表中增加相应数量的加速资源。

所述节点管理器，还用于从所述已分配加速资源列表中删除记录的容器标识和为其分配的加速资源数量之间的对应关系。

采用上述技术方案，本发明至少具有下列优点：

本发明所述基于混合计算资源的分布式计算系统，将多个深度学习框架构建在同一个spark计算引擎上，并提供统一的访问接口，从而可以屏蔽各框架件不同的调用接口，为用户提供了统一且精简的访问方式；在底层，通过根据待处理任务的任务类型划分不同的任务队列，根据不同物理机搭载的计算资源类型划分不同的逻辑集群中，根据待处理任务的任务类，将任务队列中的任务分配到对应的逻辑集群中执行，实现了资源的合理分配，从而完成了异构资源高效灵活的调度，满足了计算任务多样性的需求。

附图说明

图1为本发明实施例的基于混合计算资源的分布式计算系统结构图；

图2为本发明实施例的队列与集群划分结构示意图；

图3为本发明实施例的资源调度过程示意图；

图4为本发明实施例的yarn树形层级队列示意图。

具体实施方式

为更进一步阐述本发明为达成预定目的所采取的技术手段及功效，以下结合附图及较佳实施例，对本发明进行详细说明如后。

如图1所示，其为本发明实施例提供的基于混合计算资源的分布式计算系统，包括计算引擎层11、混合计算封装层13和资源调度层12，其中：

所述计算引擎层11由多个构建在同一个spark计算引擎上的深度学习框架组成；

所述混合计算封装层13，用于针对所述计算引擎层11统一封装各个深度学习框架的访问接口；

所述资源调度层12包括多种异构计算资源，所述异构计算资源包括以下至少一项：中央处理单元cpu、图形处理单元gpu和现场可编程门阵列fpga；在所述资源调度层12，根据待处理任务的任务类型划分不同的任务队列，根据不同物理机搭载的计算资源类型划分不同的逻辑集群中，根据待处理任务的任务类，将任务队列中的任务分配到对应的逻辑集群中执行。

具体实施时，在计算引擎层11部署的深度学习框架可以包括angelonspark和tensorflowonspark等。

其中，angelonspark框架整体结构可以分为参数服务器层，worker层与model层，分别负责提供参数服务器服务，完成模型训练任务以和逻辑控制的功能。为了完成angelonspark的部署，在完成spark的部署后需要进行以下操作：

(1)解压angel-2.0-bin.zip；

(2)配置angel-2.0-bin/bin/spark-on-angel-env.sh下的spark_home，angel_home，angel_hdfs_home三个环境变量；

(3)将解压后的angel-2.0-bin目录上传到hdfs路径；

(4)导入环境脚本：source./spark-on-angel-env.sh；

(5)完成好jar包配置。

tensorflowonspark框架的架构较为简单，sparkdriver程序并不会参与tensorflow内部相关的计算和处理。其设计思路像是将一个tensorflow集群运行在了spark上，其在每个sparkexecutor中启动tensorflow应用程序，然后通过grpc(远程过程调用)或rdma(远程直接数据存取)方式进行数据传递与交互。在完成spark环境以及python的安装后，执行pipinstalltensorflowtensorflowonspark即可完成部署。

本发明实施例提供的基于混合计算资源的分布式计算系统可以构建于linux操作系统上，其面临着各框架接口不统一且较复杂的问题，为了解决这个问题，本发明实施例中，选择使用shell脚本语言进行解决。shell脚本与windows/dos下的批处理相似，也就是用各类命令预先放入到一个文件中，方便一次性执行的一个程序文件，主要是方便管理员进行设置或者管理用的。但是它比windows下的批处理更强大，比用其他编程程序编辑的程序效率更高。通过借助shell语言中的流程控制语句，可以使用一个shell脚本作为整个系统的使用入口，根据用户输入的不同参数来选择应当启动哪个框架、执行哪些功能以及设定哪些参数。这样可以屏蔽各框架间不同的调用接口，向用户提供了一个统一且经过精简的访问方式，极大地方便了用户的学习和使用。基于此，计算引擎层，可以用于通过所述访问接口接收用户请求，根据用户请求中携带的请求参数，为所述用户请求启动相应的深度学习框架。

在资源调度层12，本发明实施例中，在扩展了底层硬件计算资源的基础上，采用按任务类型划分队列、按资源划分逻辑集群的方式进行计算资源的管理调度：将待处理任务按照任务类型划分到不同的任务队列，将物理机按照搭载不同的计算资源划分到不同的逻辑集群，将任务队列中的任务分配到对应的逻辑集群中进行计算。如图2所示，其为本发明实施例中，队列与集群划分结构示意图。

具体实施时，资源调度层，具体用于根据为物理机标注机器标签，将物理机划分不同的逻辑集群，所述机器标签为根据物理机搭载的计算资源类型标注的；根据处理的任务类型，为不同的任务队列添加队列标签；针对任一任务队列，根据该任务队列对应的队列标签，将该任务队列中的任务调度到具有与所述队列标签相同标签的物理机上执行。

具体地，使用物理标注的方法，为挂载不同计算资源的物理机打上不同的机器标签，并依据机器标签将物理机划分成为几个不同的逻辑集群。物理机的标注方法举例如下：node1(节点1)上不包含任何计算加速资源，则为node1打上normal标签，标识该节点只能负责运行无需加速的普通批处理与实时计算任务；如果node2上挂载了gpu(图形处理器)和/或fpga(现场可编程门阵列)加速资源，则可以为该节点打上normal、分布式机器学习和分布式深度学习标签，表示该节点可以负责运行批处理计算任务、实时计算任务、机器学习任务和深度学习任务等。

设定了机器标签之后，整个集群中的物理机根据能够处理的任务被划分成了几个逻辑集群。每个节点(物理机)可以同时隶属于多个逻辑集群，每个逻辑集群用于处理一类计算任务。

具体实施时，通过在资源调度层部署节点管理器(nm，nodemanager)和资源管理器(rm，resourcemanager)来实现资源的调度。节点管理器部署于每一物理机上，资源管理器可以部署于其中一台物理机上。

在resourcemanager内部使用队列来抽象表示整个集群的资源。为了让需要加速的任务被提交到具有相应加速资源的逻辑集群中，可以按照任务类型，在resourcemanager上将整个集群资源组织到几个队列中，并为每个队列设置队列标签。利用基于标签的调度算法，提交到某个队列中的任务只能被调度到具有与队列标签相同标签的节点(物理机)上运行。资源队列的划分即是逻辑集群的划分，resourcemanager根据nodemanager标签将其归入到逻辑集群中。

具体实施时，nodemanager负责分配回收本机资源并负责资源的虚拟化，nodemanager可以使用虚拟个数的方式来表示本机的加速资源，并维护虚拟个数到实际加速资源文件路径的映射。

nodemanager在启动时向所述资源管理器发送注册请求，所述注册请求中携带有自身所在物理机的可用资源信息，所述可用资源信息包括以下至少一项：cpu总量，内存总量，gpu虚拟数量和fpga虚拟数量。

具体地，yarn(yetanotherresourcenegotiator，另一种资源协调者)框架支持cpu和内存两种资源的管理和分配，nodemanager在启动时会向resourcemanager注册，注册时携带的信息包括cpu总量和内存总量，集群资源标识模型为<cpu,内存>。gpu与fpga的使用首先需要在机器上完成两者驱动程序的装载。为了使yarn可以识别与调度gpu与fpga，本发明实施例中需要对yarn的配置文件进行额外的配置：配置resource-types.xml文件，为yarn.resource-types属性增加yarn.io/gpu和yarn.io/fpga值；配置yarn-site.xml文件，为yarn.nodemanager.resource-plugins属性增加yarn-io/gpu和yarn-io/fpga值，使得yarn可以发现并使用gpu和fpga。在对现有的yarn框架进行资源扩展时，按照yarn平台中继承的计算框架的种类来确定扩展yarn平台中的资源表示。

由于整个集群中运行的计算框架的数目有限，并且在实际应用中多阶段计算框架需要的gpu和fpga有限，可以事先确定整个集群中的资源表示维度。需要说明的是资源表示仅仅用于表示节点具有资源加速处理的能力，并没有限定该节点中的加速器能够英语该框架下的哪种具体作业的加速。指明节点能够加速哪种具体作业，是通过节点资源标签完成的。扩展资源模型中资源向量的维度只和计算框架的种类以及包含的处理步骤个数相关，和集群上运行的具体算法的种类无关。

在使用虚拟化资源过程中，需要同时使用同一个物理设备上的虚拟设备的计算进程的发送数据将在设备驱动程序的缓冲区中排队，等待物理设备空闲后处理。物理设备的处理结果将根据发送数据进程的id返回到每个进程中。每个物理设备能够虚拟出多少个虚拟设备，需要根据设备的处理能力在后续实际搭建中调整。

具体实施时，节点管理器，还用于在系统运行过程中，向所述资源管理器上报自身所在物理机的资源状态信息，所述资源状态信息包括空闲资源信息和已分配资源信息；所述资源管理器，还用于根据各个节点管理器上报的资源状态信息，为任务队列中的任务调度资源。

此外，nodemanager提供配置文件接口共用户调整计算节点上的gpu和fpga虚拟个数，cpu虚拟核数以及虚拟内存大小。

具体实施时，可以按照以下流程完成资源分配：深度学习框架，可以用于根据接收到的用户请求，向资源管理器发送资源调度请求，资源调度请求中携带有资源需求信息；资源管理器，可以用于根据各个节点管理器的资源状态信息和所述资源需求信息，针对资源调度请求分配对应的节点管理器；向分配的节点管理器发送容器启动命令；节点管理器，可以用于如果根据资源需求信息，判断出所述容器启动需要加速资源，则从空闲加速资源列表中查找空闲加速资源启动容器，并减少维护的空闲加速资源数量，并在已分配加速资源列表中记录容器标识和为其分配的加速资源数量之间的对应关系。在检测到所述容器运行结束时，如果节点管理器判断出该容器中含有加速资源，则根据容器标识，从已分配加速资源列表中查找为所述容器分类的加速资源数量，根据查找到的加速资源数量，在空闲加速资源列表中增加相应数量的加速资源，并从已分配加速资源列表中删除记录的容器标识和为其分配的加速资源数量之间的对应关系

例如，nm实例在启动时，除了向resourcemanager报告虚拟的cpu核数，内存容量之外，还需要按照集群资源表维度报告虚拟运算加速资源的数量，在收到来自applicationmaster(am，应用控制器)的启动带有加速资源的计算容器的请求之后，nodemanager根据本地数据结构，完成虚拟加速资源向物理机位置的映射，并登记正在使用加速部资源的计算容器id。计算容器运行结束之后回收虚拟资源，修改虚拟设备管理相关数据结构，并向resourcemanager报告虚拟资源余量。

原生yarn采用双层资源调度模型：在第一层中，resourcemanager的scheduler(调度器)将资源分配给各个applicationmaster(am，应用控制器)；在第二层中，am再进一步把申请到的资源分配给内部子任务。第二层的调度策略由am设计者根据应用来进行设计，在此主要关注第一层资源的调度。

针对资源的调度算法，yarn中自带了三种常用的scheduler，分别是fifo(先进先出调度器)，capacityscheduler(计算能力调度器)和fairscheduler(公平调度器)。其中fairscheduler内部使用的是drf(dominantresourcefairness)多维资源调度算法，十分适用于异构复杂资源环境中。

因此，本发明实施例中，对yarn中现有的fairscheduler中的drf算法进行改进，使其能够适用于多维度资源模型。基于此，资源管理器，可以用于针对每一任务队列，分别确定每一任务队列对应的资源占用份额；根据确定出的资源占用份额，按照由小到大的顺序为任务队列调度资源。

具体地，drf在yarn中被设计成一个可热插拔的排序比较器，提供比较两个队列主资源占用份额大小的功能，scheduler使用此比较器对队列主资源份额从小到大排序，主资源占用份额较小的队列具有分配资源的优先权。此外，drf还可对用户的主占用率进行比较，优先为主占用率较小的用户分配资源。该比较器能够在不影响集群正常运行的情况下被动地加载并应用于不同的队列。fairscheduler中的drf只考虑了cpu和内存两种资源，不具有多维资源的扩展性。我们对该算法进行重写，在保持接口不变的情况下重新实现了drfcomparator，使其能够对多维资源进行比较。

针对yarn资源维度扩展的情况，本发明实施例中，对原有yarn的资源分配过程进行了修改和优化，采用了更加严格的资源合法性检查，其过程如图3所示，包括以下步骤：

步骤1：节点的nodemanager通过周期性心跳向resourcemanager汇报本节点信息；

步骤2：resourcemanager向nodemanager返回一个心跳应答；

步骤3：nodemanager的心跳信息发出scheduler的node_update事件；

步骤4：scheduler根据设定的策略在此节点上分配一个container给最合适的应用程序。

步骤5：scheduler把分配完成的container添加至资源分配列表；

步骤6：应用程序的applicationmaster向resourcemanager发送心跳信息；

步骤7：rm接收心跳信息后，更新资源申请列表，并把资源分配列表中属于该应用程序的container以心跳应答的方式返回给applicationmaster；

步骤8：applicationmaster对获得的container执行第二层资源分配。

其中，在步骤4中，yarn的资源管理器scheduler使用树形层级队列管理机制，树的每个节点表示一个队列，树根是名称为“root”的根队列，子队列的名称以父队列的名称为前缀，所有正在运行的应用程序分布在树的叶子上，如图4所示。

本发明实施例中，将多个深度学习框架构建在同一个spark计算引擎上，并提供统一的访问接口，从而可以屏蔽各框架件不同的调用接口，为用户提供了统一且精简的访问方式；在底层，通过根据待处理任务的任务类型划分不同的任务队列，根据不同物理机搭载的计算资源类型划分不同的逻辑集群中，根据待处理任务的任务类，将任务队列中的任务分配到对应的逻辑集群中执行，实现了资源的合理分配，从而完成了异构资源高效灵活的调度，满足了计算任务多样性的需求。

通过具体实施方式的说明，应当可对本发明为达成预定目的所采取的技术手段及功效得以更加深入且具体的了解，然而所附图示仅是提供参考与说明之用，并非用来对本发明加以限制。