CN109586970A - 资源分配方法、装置及系统 - Google Patents

Abstract

本公开提出一种资源分配方法、装置及系统，涉及大数据技术领域。该方法应用于大数据集群，大数据集群包括一个主节点和多个从节点，包括：主节点获取至少一个资源配置组信息，资源配置组信息包括：大数据集群中部署的每个服务占用的资源的比重和资源配置信息的触发条件；主节点解析资源配置组信息生成资源配置消息并发送给每个从节点；资源配置消息包括每个服务占用的资源的配置数据；从节点接收资源配置消息，在满足触发条件时，根据资源配置消息中服务占用的资源的配置数据生成服务占用的资源的配置文件；从节点根据配置文件对服务进行资源的分配。本公开能够减少大数据集群的资源浪费、提高服务运行的稳定性和可靠性。

Description

资源分配方法、装置及系统

技术领域

本公开涉及大数据技术领域，具体而言，涉及一种资源分配方法、装置及系统。

背景技术

随着互联网的发展以及对大数据处理需求的不断增长，大数据集群的应用也日益广泛。大数据集群可以部署有多个服务，且该多个服务可以运行在该大数据集群包括的节点中。由于服务运行时需要占用大数据集群中的资源，因此，需要对服务进行资源分配。

现有技术中，大数据集群包括多个节点，其中包括一个主节点和多个从节点。当服务启动时，主节点控制各节点可以向该服务分配固定的资源。

但由于服务在运行过程中所占用的资源并不是固定的，因此，通过现有技术来向服务分配资源时，可能会导致资源浪费或者难以满足服务运行的需求的问题，从而提高成本、降低服务运行的稳定性和可靠性。

发明内容

本公开的目的在于提供一种资源分配方法、装置及系统，以减少大数据集群的资源浪费、提高服务运行的稳定性和可靠性。

为了实现上述目的，本公开采用的技术方案如下：

第一方面，本公开提出一种应用于大数据集群，所述大数据集群包括一个主节点和多个从节点，所述方法包括：

所述主节点获取至少一个资源配置组信息，所述资源配置组信息包括：所述大数据集群中部署的每个服务占用的资源的比重和所述资源配置组信息的触发条件；

所述主节点解析所述资源配置组信息生成资源配置消息并发送给每个所述从节点；所述资源配置消息包括所述每个服务占用的资源的配置数据，任一服务占用的资源的配置数据包括：服务名、所述触发条件和所述服务占用的各资源的比重；

所述从节点接收所述资源配置消息，在满足所述触发条件时，根据所述资源配置消息中服务占用的资源的配置数据生成服务占用的资源的配置文件；所述配置文件包括服务占用的各资源对应的预设参数的参数值；

所述从节点根据所述配置文件对服务进行资源的分配。

第二方面，本公开还提出一种资源分配装置，所述装置应用于大数据集群中的主节点，所述装置包括：

获取模块，用于获取至少一个资源配置组信息，所述资源配置组信息包括：所述大数据集群中部署的每个服务占用的资源的比重和所述资源配置组信息的触发条件；

解析模块，用于解析所述资源配置组信息生成资源配置消息并发送给所述大数据集群中的每个从节点，以使所述从节点进行资源的分配；所述资源配置消息包括所述每个服务占用的资源的配置数据，任一服务占用的资源的配置数据包括：服务名、所述触发条件和所述服务占用的各资源的比重。

第三方面，本公开还提出一种资源分配装置，所述装置应用于大数据集群中的任一从节点，所述装置包括：

接收模块，用于接收大数据集群中的主节点发送的至少一个资源配置消息；所述资源配置消息包括大数据集群中部署的每个服务占用的资源的配置数据，任一服务占用的资源的配置数据包括：服务名、触发条件和服务占用的各资源的比重；

分析模块，用于在满足所述触发条件时，根据所述资源配置消息中服务占用的资源的配置数据生成服务占用的资源的配置文件；所述配置文件包括服务占用的各资源对应的预设参数的参数值；

分配模块，用于根据所述配置文件对服务进行资源的分配。

第四方面，本公开还提出一种资源分配系统，应用于大数据集群，所述大数据集群包括第二方面所述的主节点以及多个第三方面所述的从节点。

第五方面，本公开还提出一种计算设备，包括存储有计算机程序的计算机可读存储介质和处理器，所述计算机程序被所述处理器读取并运行时，实现上述第一方面所述的方法。

第六方面，本公开还提出一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器读取并运行时，实现上述第一方面所述的方法。

相对现有技术，本公开具有以下有益效果：

在本公开实施例中，大数据集群中的主节点能够获取至少一个资源配置组信息，而该资源配置组信息包括大数据集群中部署的每个服务占用的资源的比重和资源配置组信息的触发条件。因此，对该资源配置组信息解析即可生成资源配置消息，该资源配置消息中包括服务名、触发条件和服务占用的各资源的比重等各服务占用资源的配置数据，所以将该资源配置消息发送给从节点，各从节点即能够在触发条件被触发时，根据该资源配置消息生成针对各服务占用资源的配置文件，从而向各服务分配资源，确保了向各服务所分配的资源与该服务的实际需求相匹配，即使分配资源的方式更加合理，减少了资源浪费的可能并降低了成本，也减少了所分配的资源难以支撑服务运行的问题，提高服务运行的稳定性和可靠性。

本公开的其他特征和优点将在随后的说明书阐述，并且，部分地从说明书中变得显而易见，或者通过实施本公开了解。本公开的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

为了更清楚地说明本公开的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本公开的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本公开所提供的一种大数据集群的架构示意图；

图2示出了本公开所提供的一种资源分配方法的流程示意图；

图3示出了本公开所提供的一种资源分配装置的功能模块示意图；

图4示出了本公开所提供的另一种资源分配装置的功能模块示意图；

图5示出了本公开所提供的另一种资源分配装置的功能模块示意图；

图6示出了本公开所提供的一种计算设备的功能模块示意图。

具体实施方式

下面将结合本公开中附图，对本公开中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本公开的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本公开的详细描述并非旨在限制要求保护的本公开的范围，而是仅仅表示本公开的选定实施例。基于本公开的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本公开保护的范围。

在对本公开进行详细的解释说明之前，先对本公开的应用场景予以介绍。

请参照图1，大数据集群可以包括一个主节101和多个从节点102，主节点101可以对各从节点102进行管理。其中，各节点(包括主节点101和各从节点102)可以包括实体或虚拟的计算设备，且能够提供相应的资源，比如，输入/输出设备、处理器、内存等。该大数据集群上可以部署多个服务，且各服务运行需要占用资源。因此，可以通过主节点101，控制大数据集群所包括的各节点，针对该大数据集群所部署的服务，进行资源分配。

服务能够运行于大数据集群，并进行数据处理。该服务例如Flume、Hbase、HDFS、Solr、Hive、Yarn和Elastaticsearch。

其中，Flume是一种高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统，用于收集以及处理数据；HBase(Hadoop Database)是一种高可靠性、高性能、面向列、可伸缩的分布式存储系统；HDFS(Hadoop Distributed File System，分布式文件系统)是一种高容错性、高吞吐量的分布式文件系统；Solr是一种企业级搜索引擎，具有高效和灵活的缓存功能以及垂直搜索功能；Hive是一种基于Hadoop的数据仓库工具，可以将结构化的数据文件映射为数据库表，并提供查询功能；Yarn是一种基于Hadoop的资源管理器；Elastaticsearch是一种基于Lucene的搜索引擎，可以用于分布式全文搜索。

以下将对本公开所提供的资源分配方法进行具体说明。

请参照图2，为本公开所提供的一种资源分配方法的流程示意图。该方法可以应用于前述中的大数据集群。需要说明的是，本公开所述的资源分配方法并不以图2以及以下所述的具体顺序为限制，应当理解，在其它实施例中，本公开所述的资源分配方法其中部分步骤的顺序可以根据实际需要相互交换，或者其中的部分步骤也可以省略或删除。下面将对图2所示的流程进行详细阐述。

步骤201，主节点获取至少一个资源配置组信息，该资源配置组信息包括：大数据集群中部署的每个服务占用的资源的比重和该资源配置组信息的触发条件。

由于服务的运行需要占用大数据集群中的资源，且该服务在不同环境中所需的资源也会相应不同，比如，在该服务繁忙时，可能会需要更多的资源，而在空闲时可能仅需要少量的资源，因此，为了确保向服务所分配的资源与该服务的实际需求相匹配，即使分配资源的方式更加合理，减少资源浪费的可能并降低成本，也减少所分配的资源难以支撑服务运行的问题，提高服务运行的稳定性和可靠性，可以通过主节点获取至少一个针对不同场景、不需求的资源配置组信息，从而便于在某个资源配置组信息的触发条件被触发时，按照该资源配置组信息相应的资源分配方式，向服务分配资源。

后续将对于该资源配置组信息如何生效进行详细的说明。

资源配置组信息为指示对大数据集群所包括的资源进行分配的信息，即能够说明一种资源分配方式。

其中，用户可以针对大数据集群中服务运行的各种情况对应的资源分配需求，确定不同的动态资源分配方式，相应地，主节点可以通过接收用户针对不同的动态资源分配方式提交的触发条件、每个服务占用的资源的比重以及生效信息等信息，从而生成得到至少一个资源配置组信息，并将至少一个资源配置组信息存储至数据库中或文件中。

由于大数据集群可以包括一种以上的资源(例如处理器资源、输入输出设备资源、内存资源等等)，也可能包括一个以上的服务，因此，可以在资源配置组信息中配置每个服务占用的每种资源的信息，如此，能够精准地针对不同的服务，对不同的资源进行分配，充分满足服务运行的需求，即提高资源分配的准确性以及服务的可靠性。

可选地，当资源配置组信息的数目大于两个时，可以包括一个默认资源配置组信息，且该默认资源组配置信息的触发条件为其它任一资源配置组信息均未被触发。

由前述可知，用户可以基于不同的应用场景生成各资源配置组信息，而用户可能不容易穷举分别适用于各种应用场景的资源配置组信息，所以，为了避免至少一种资源配置组信息可能难以覆盖服务运行在各种情况下对资源的分配需求的问题，进一步提高资源分配以及服务的稳定性和可靠性，当资源配置组信息的数目大于两个时，可以包括一个默认资源配置组信息。

资源配置组信息中需要至少明确以下三种信息：

服务信息：可以为服务标识(用于对服务进行标识)。该服务标识可以包括名称或者ID(Identification，身份证)。例如，前述中的Flume、Hbase、HDFS、Solr、Hive、Yarn和Elastaticsearch，即为服务的名称。

每个服务占用的资源信息：可以为占用资源的比重，例如：

处理器个数占比(cpuLimit)，服务占用的处理器个数与节点所具有的处理总个数的比值。该处理器个数可以通过百分比表示。

处理器时间占比(cpuShare)，服务占用处理器的时长比例，该处理器时间占比可以通过百分比表示。

输入/输出设备访问占比(blkio)，服务对输出/输出设备访问的占比。该输入/输出设备访问占比可以通过百分比表示。

需要说明的是，在实际应用中，各组资源配置组信息中还可以包括更多或更少的资源的比重，比如，还可以包括内存使用占比。

触发条件：即资源配置组信息生效的条件。其中，触发条件可以包括基于时间的触发条件，比如起始时间、结束时间或持续时间等。

由于对于某些服务，其繁忙程度可能与时间段相关较为密切，比如，Hbase在白天的业务较多，Hive在晚上的业务较多，因此，当触发条件可以包括基于时间的触发条件时，能够确保在服务较为繁忙的时段向该服务分配较多的资源，以使该服务可靠运行，而在该服务较为空闲的时段向该服务分配较少的资源，从而节省资源，降低成本，触发条件可以包括开始时间和结束时间。

例如，针对Hbase在白天的业务较多，Hive在晚上的业务较多的情况，可以设置两个资源配置组信息。其中一个资源配置组信息的触发条件为早上8点至晚上12点，从而在早上8点至晚上12点之间，向Hbase分配较多的资源，并向Hive分配较少的资源。另一种资源配置组信息的触发条件为晚上12点至早上8点，从而在晚上12点至早上8点之间向Hbase分配较少的资源，并向Hive分配较多的资源。

需要说明的是，在本公开实施例中，若某一资源配置组信息的触发条件包括开始时间和结束时间，则在开始时间该资源配置组信息生效，同时旧的资源配置组信息失效；在结束时间时，该资源配置组信息失效，同时，一个新的资源配置组信息生效。针对相同的服务在同一时间内只能生效一个资源配置。当然，资源配置组信息的触发条件也可以仅包括开始时间，在该开始时间该资源配置组信息生效，如果没有新的资源配置组信息生效，则该资源配置组信息一直生效，一旦有新的资源配置组信息生效，则该资源配置组信息失效。

还需要说明的是，在实际应用中，该触发条件还可以包括基于其它因素的触发条件。比如，在本公开的另一可选实施例中，触发条件可以包括预设数据服务个数，从而在大数据平台部署的数据服务的个数大于、等于或小于该预设数据服务个数时，分别按照不同的资源分配方式进行资源分配，或者，触发条件可以预设资源占用率，从而在大数据平台中的资源占用率大于、小于或等于该预设资源占用率时，分别按照不同的资源分配方式进行资源分配。

步骤202，主节点解析资源配置组信息生成资源配置消息并发送给每个从节点，该资源配置消息包括每个服务占用的资源的配置数据，任一服务占用的资源的配置数据包括：服务名、触发条件和服务占用的各资源的比重。

由于大数据集群中可能包括一个以上的服务，因此，为了便于后续准确地向各服务分配资源，即提高分配资源的准确性和可靠性，主节点可以对资源配置组信息进行解析，从而生成得到资源配置消息并发送给从节点，以向从节点指示该资源配置组信息的触发条件以及各服务占用的各资源的比重。

资源配置消息可以包括节点能够执行的任务或指令。

服务占用的资源的配置数据用于说明触发条件以及向各服务分配的各资源的比重。

资源配置消息的格式可以为：“触发条件+服务名+服务占用的各资源的比重；触发条件+服务名+服务占用的各资源的比重”。当然，在实际应用中，资源配置消息可以通过其它格式来表示。

例如，资源配置组信息1包括触发条件：开始时间为15:52，结束时间为24:00，还包括每个服务占用的资源的比重：HDFS，处理器个数占比为10％，处理器时间占比为20％，输入/输出设备访问占比为30％；Hive，处理器个数占比为20％，处理器时间占比为20％，输入/输出设备访问占比为20％。因此，基于资源配置信息1生成资源配置消息1：“52 15***sh/opt/cgroup_config/:config_cgroup.sh HDFS 10 20 30；52 15***sh/opt/cgroup_config/:config_cgroup.sh Hive 20 20 20”，将资源配置消息1发送至从节点。当然，若还获取到资源配置组信息2，且该资源配置组信息2包括触发条件：开始时间为24:00，结束时间为15:52，还包括每个服务占用的资源的比重：HDFS，处理器个数占比为30％，处理器时间占比为20％，输入/输出设备访问占比为10％；Hive，处理器个数占比为30％，处理器时间占比为30％，输入/输出设备访问占比为30％，则基于上述相似的方式，生成资源配置消息2：“00 24***sh/opt/cgroup_config/:config_cgroup.sh HDFS 30 20 10”；00 24***sh/opt/cgroup_config/:config_cgroup.sh Hive 30 30 30，存储资源配置消息2，并将资源配置消息2发送至各从节点。

步骤203，从节点接收资源配置消息，在满足触发条件时，根据资源配置消息中服务占用的资源的配置数据生成服务占用的资源的配置文件，该配置文件包括服务占用的各资源对应的预设参数的参数值。

当某个资源配置组信息的触发条件被触发时，可能当前分配资源的方式，已经难以满足该大数据集群中至少一个服务的运行需求，因此，为了使分配资源的方式更加合理，从节点可以根据资源配置消息中服务占用的资源的配置数据，生成服务占用的资源的配置文件。

配置文件用于指示节点针对服务分配各资源的方式。该配置文件归属于一个服务，并与一个资源对应。

其中，预设参数为对资源进行控制的参数，该预设参数可以通过事先确定得到。

可选地，在满足触发条件时，从节点解析资源配置消息，得到各服务占用的各资源的比重，从节点确定本节点已安装的服务，对于任一已安装的服务：从节点查找已安装的服务占用的各资源比重，从节点将已安装的服务占用的各资源比重转换为已安装的服务占用的各资源对应的预设参数的参数值，并将参数值写入相应资源对应的配置文件。

由于节点中可能包括多种资源，且节点中可能安装并运行有多个服务，因此，为了准确地向各服务分配该多种资源，可以针对已安装的各服务，将该服务占用的各资源的比重转换为相应的参数值，从而生成得到配置文件，以通过该配置文件说明向该服务分配的各资源。

其中，从节点可以通过预先存储的各资源的比重与预设参数的参数值之间的对应关系，对服务占用的各资源的比重进行转换，从而得到该服务占用各资源对应的预设参数的参数值。

例如，可以将处理器个数占比转换为处理器编号，将处理器时间占比转换为占用处理器时长，将输入/输出设备访问占比转换为占用输入/输出设备权重。

需要说明的是，从节点可以事先确定服务占用各资源的比重以及该比重所对应的预设参数的参数值，并将各资源的比重和对应的预设参数的参数值，存储至各资源的比重与预设参数的参数值之间的对应关系。

例如，资源配置消息1：“52 15***sh/opt/cgroup_config/:config_cgroup.shHDFS 10 20 30；52 15***sh/opt/cgroup_config/:config_cgroup.sh Hive 20 20 20”。对于HDFS，可以将处理器个数占比10％转换为处理器1、处理器2和处理器3，并将处理器1、处理器2和处理器3写入归属于HDFS的处理器个数配置文件；将处理器时间占比20％转换为时长1，将时长1写入归属于HDFS的占用处理器时长配置文件；将输入/输出设备访问占比30％转换为权重1，并将权重1写入归属于HDFS的输入/输出设备访问权重配置文件。对于Hive，将处理器个数占比20％转换为处理器1和处理器2，并将处理器1和处理器2写入归属于Hive的处理器个数配置文件；将处理器时间占比为20％转换为时长2，将时长2写入归属于Hive的占用处理器时长配置文件；将输入/输出设备访问占比为20％转换为权重2，并将权重2写入归属于Hive的输入/输出设备访问权重配置文件。

步骤204，从节点根据配置文件对服务进行资源的分配。

从节点可以根据针对各服务的配置文件向该服务分配相应的资源，从而使各服务使用新分配资源运行。

可选地，对于任一已安装的服务，从节点确定已安装的服务下占用各资源的进程，并将确定出的进程的信息写入相应资源对应的配置文件。

由于服务可能包括多个进程，所以将服务对应的进程的信息添加至相应的配置文件，从而使后续按照该配置文件，向该服务包括的各进程分配资源，实现对该服务占用的各资源的准确控制。

其中，进程的信息可以包括进程ID(Identification，身份证)。

另外，主节点也可以按照与从节点类似的方式，对服务进行资源的分配。

在本公开实施例中，大数据集群中的主节点能够获取至少一个资源配置组信息，而该资源配置组信息包括大数据集群中部署的每个服务占用的资源的比重和资源配置组信息的触发条件。因此，对该资源配置组信息解析即可生成资源配置消息，该资源配置消息中包括服务名、触发条件和服务占用的各资源的比重等各服务占用资源的配置数据，所以将该资源配置消息发送给从节点，各从节点即能够在触发条件被触发时，根据该资源配置消息生成针对各服务占用资源的配置文件，从而向各服务分配资源，确保了向各服务所分配的资源与该服务的实际需求相匹配，即使分配资源的方式更加合理，减少了资源浪费的可能并降低了成本，也减少了所分配的资源难以支撑服务运行的问题，提高服务运行的稳定性和可靠性。

可选地，从节点在接收资源配置消息之后，可以将本节点已保存的资源配置消息更新为接收到的至少一个资源配置消息。

由于从节点可能已经存储的资源配置消息，因此为了避免该资源配置信息对向各服务里进行资源分配的过程造成干扰，进一步提高资源分配的准确性，可以本节点已包括的资源配置消息进行更新。

其中，从节点可以将本节点已保存的资源配置消息替换为接收到的至少一个资源配置消息。

另外，在本公开的另一可选实施例中，从节点也可能在接收到至少一个资源配置消息之前，并未存储资源配置消息，因此，也可以不对已保存的资源配置消息更新，而是直接将接收到的至少一个资源配置消息进行存储。

需要说明的是，主节点也可以按照类似的方式，将本节点已保存的资源配置消息更新为该至少一个资源配置消息。

请参照图3，为本公开所提供的一种资源分配装置的功能模块示意图。需要说明的是，本实施例所提供的资源分配装置，其基本原理及产生的技术效果与前述对应的方法实施例相同，为简要描述，本实施例中未提及部分，可参考方法实施例中的相应内容。该装置应用于大数据集群中的主节点，该装置包括获取模块301和解析模块302。

获取模块301，用于获取至少一个资源配置组信息，该资源配置组信息包括：该大数据集群中部署的每个服务占用的资源的比重和该资源配置组信息的触发条件；

解析模块302，用于解析资源配置组信息生成资源配置消息并发送给大数据集群中的每个从节点，以使该从节点进行资源的分配；该资源配置消息包括每个服务占用的资源的配置数据，任一服务占用的资源的配置数据包括：服务名、触发条件和服务占用的各资源的比重。

上述装置用于执行前述实施例提供的方法，其实现原理和技术效果类似，在此不再赘述。

请参照图4，为本公开所提供的一种资源分配装置的功能模块示意图。需要说明的是，本实施例所提供的资源分配装置，其基本原理及产生的技术效果与前述对应的方法实施例相同，为简要描述，本实施例中未提及部分，可参考方法实施例中的相应内容。该装置应用于大数据集群中的任一从节点，该装置包括接收模块401、分析模块402和分配模块403。

接收模块401，用于接收大数据集群中的主节点发送的至少一个资源配置消息；资源配置消息包括大数据集群中部署的每个服务占用的资源的配置数据，任一服务占用的资源的配置数据包括：服务名、触发条件和服务占用的各资源的比重；

分析模块402，用于在满足触发条件时，根据资源配置消息中服务占用的资源的配置数据生成服务占用的资源的配置文件；该配置文件包括服务占用的各资源对应的预设参数的参数值；

分配模块403，用于根据配置文件对服务进行资源的分配。

可选地，请参照图5，还包括：

更新模块404，用于将本节点已保存的资源配置消息更新为接收到的至少一个资源配置消息。

可选地，分析模块402，还用于在满足触发条件时：

解析资源配置消息，得到各服务占用的各资源的比重；

确定本节点已安装的服务，对于任一已安装的服务：

查找已安装的服务占用的各资源比重；

将已安装的服务占用的各资源比重转换为已安装的服务占用的各资源对应的预设参数的参数值，并将参数值写入相应资源对应的配置文件。

可选地，分析模块402，还用于对于任一已安装的服务，确定已安装的服务下占用各资源的进程，并将确定出的进程的信息写入相应资源对应的配置文件。

上述装置用于执行前述实施例提供的方法，其实现原理和技术效果类似，在此不再赘述。

以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个特定集成电路(Application Specific Integrated Circuit，简称ASIC)，或，一个或多个微处理器(digital singnal processor，简称DSP)，或，一个或者多个现场可编程门阵列(Field Programmable Gate Array，简称FPGA)等。再如，当以上某个模块通过处理元件调度程序代码的形式实现时，该处理元件可以是通用处理器，例如中央处理器(CentralProcessing Unit，简称CPU)或其它可以调用程序代码的处理器。再如，这些模块可以集成在一起，以片上系统(system-on-a-chip，简称SOC)的形式实现。

本公开还提供了一种资源分配系统，该系统可以包括前述应用于主节点的资源分配装置和多个应用与从节点的资源分配装置。需要说明的是，本实施例所提供的资源分配系统，其基本原理及产生的技术效果与前述对应的方法实施例相同，为简要描述，本实施例中未提及部分，可参考方法实施例中的相应内容。

请参照图6，为本公开所提供的一种计算设备的功能模块示意图。该计算设备可以作为前述中的主节点或从节点。该计算设备可以包括存储有计算机程序的计算机可读存储介质601和处理器602，处理器602可以调用计算机可读存储介质601存储的计算机程序。当该计算机程序被处理器602读取并运行，可以实现上述方法实施例。具体实现方式和技术效果类似，这里不再赘述。

可选地，本公开还提供一计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器读取并运行时，可以实现上述方法实施例。

在本公开所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本公开各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(英文：Read-Only Memory，简称：ROM)、随机存取存储器(英文：Random Access Memory，简称：RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅为本公开的优选实施例而已，并不用于限制本公开，对于本领域的技术人员来说，本公开可以有各种更改和变化。凡在本公开的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本公开的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

Claims (10)

1.一种资源分配方法，其特征在于，应用于大数据集群，所述大数据集群包括一个主节点和多个从节点，所述方法包括：

所述主节点获取至少一个资源配置组信息，所述资源配置组信息包括：所述大数据集群中部署的每个服务占用的资源的比重和所述资源配置组信息的触发条件；

所述主节点解析所述资源配置组信息生成资源配置消息并发送给每个所述从节点；所述资源配置消息包括所述每个服务占用的资源的配置数据，任一服务占用的资源的配置数据包括：服务名、所述触发条件和所述服务占用的各资源的比重；

所述从节点接收所述资源配置消息，在满足所述触发条件时，根据所述资源配置消息中服务占用的资源的配置数据生成服务占用的资源的配置文件；所述配置文件包括服务占用的各资源对应的预设参数的参数值；

所述从节点根据所述配置文件对服务进行资源的分配。

2.根据权利要求1所述资源分配方法，其特征在于，在所述从节点接收所述资源配置消息之后，所述方法还包括：

所述从节点将本节点已保存的资源配置消息更新为接收到的至少一个资源配置消息。

3.根据权利要求2所述资源分配方法，其特征在于，所述在满足所述触发条件时，根据所述资源配置消息中服务占用的资源的配置数据生成服务占用的资源的配置文件，包括：

在满足所述触发条件时，所述从节点解析所述资源配置消息，得到各服务占用的各资源的比重；

所述从节点确定本节点已安装的服务，对于任一已安装的服务：

所述从节点查找所述已安装的服务占用的各资源比重；

所述从节点将所述已安装的服务占用的各资源比重转换为所述已安装的服务占用的各资源对应的预设参数的参数值，并将所述参数值写入相应资源对应的配置文件。

4.根据权利要求3所述资源分配方法，其特征在于，所述方法还包括：

对于任一所述已安装的服务，所述从节点确定所述已安装的服务下占用各资源的进程，并将确定出的进程的信息写入相应资源对应的配置文件。

5.一种资源分配装置，其特征在于，所述装置应用于大数据集群中的主节点，所述装置包括：

获取模块，用于获取至少一个资源配置组信息，所述资源配置组信息包括：所述大数据集群中部署的每个服务占用的资源的比重和所述资源配置组信息的触发条件；

解析模块，用于解析所述资源配置组信息生成资源配置消息并发送给所述大数据集群中的每个从节点，以使所述从节点进行资源的分配；所述资源配置消息包括所述每个服务占用的资源的配置数据，任一服务占用的资源的配置数据包括：服务名、所述触发条件和所述服务占用的各资源的比重。

6.一种资源分配装置，其特征在于，所述装置应用于大数据集群中的任一从节点，所述装置包括：

接收模块，用于接收大数据集群中的主节点发送的至少一个资源配置消息；所述资源配置消息包括大数据集群中部署的每个服务占用的资源的配置数据，任一服务占用的资源的配置数据包括：服务名、触发条件和服务占用的各资源的比重；

分析模块，用于在满足所述触发条件时，根据所述资源配置消息中服务占用的资源的配置数据生成服务占用的资源的配置文件；所述配置文件包括服务占用的各资源对应的预设参数的参数值；

分配模块，用于根据所述配置文件对服务进行资源的分配。

7.根据权利要求6所述的资源分配装置，其特征在于，还包括：

更新模块，用于将本节点已保存的资源配置消息更新为接收到的至少一个资源配置消息。

8.根据权利要求6所述的资源分配装置，其特征在于，

所述分析模块，还用于在满足所述触发条件时：

解析所述资源配置消息，得到各服务占用的各资源的比重；

确定本节点已安装的服务，对于任一已安装的服务：

查找所述已安装的服务占用的各资源比重；

将所述已安装的服务占用的各资源比重转换为所述已安装的服务占用的各资源对应的预设参数的参数值，并将所述参数值写入相应资源对应的配置文件。

9.根据权利要求6所述的资源分配装置，其特征在于，

所述分析模块，还用于对于任一已安装的服务，确定所述已安装的服务下占用各资源的进程，并将确定出的进程的信息写入相应资源对应的配置文件。

10.一种资源分配系统，其特征在于，应用于大数据集群中，所述系统包括如权利要求5所述的应用于主节点的资源分配装置以及如权利要求6-9任一所述的应用于从节点的资源分配装置。