CN114816753A

CN114816753A - 一种数据集群计算节点扩缩方法、装置、设备及介质

Info

Publication number: CN114816753A
Application number: CN202210447020.8A
Authority: CN
Inventors: 胡华林; 谢海涛; 张乐; 徐向阳
Original assignee: Kingdee Software China Co Ltd
Current assignee: Kingdee Software China Co Ltd
Priority date: 2022-04-26
Filing date: 2022-04-26
Publication date: 2022-07-29

Abstract

本申请公开了一种数据集群计算节点扩缩方法、装置、设备及介质，包括：在集群中部署多个计算节点以及用于存储数据的数据节点；获取集群当前的资源使用率、待执行任务数量以及资源调度策略；基于所述资源使用率、所述待执行任务数量以及所述资源调度策略扩容或者缩容计算节点；其中，扩容的计算节点与所述数据节点分离部署。这样，部署多个计算节点，来保障集群的正常使用，在扩容的计算节点与数据节点分离部署的基础上，根据集群当前的资源使用率、待执行任务数量以及资源调度策略动态的扩容或者缩容计算节点，以合理的应对任务高峰时期以及低峰时期资源需求，能够避免资源浪费，减少人工操作，从而降低成本。

Description

一种数据集群计算节点扩缩方法、装置、设备及介质

技术领域

本申请涉及数据集群技术领域，特别涉及一种数据集群计算节点扩缩方法、装置、设备及介质。

背景技术

现有的企业数据业务涉及到的大数据平台，要么使用云厂商的数据集群，要么就在自己本地机房建设数据集群，而使用云厂商的数据集群，以Hadoop数据集群为例，所有的Hadoop生态和相关组件都严重依赖云厂商的版本，费用高，版本固定，出问题响应速度慢，难以进行定制化二次开发以及数据迁移。而如果使用自建机房部署数据集群，需要事先根据任务高峰时期来评估资源部署数据集群，但是白天大部分机器都是空闲的，造成集群资源的巨大浪费，而且后期需要人工扩充节点，随着业务增多，人工扩充会更加频繁且维护时间较长。

发明内容

有鉴于此，本申请的目的在于提供一种数据集群计算节点扩缩方法、装置、设备及介质，能够避免资源浪费，减少人工操作，从而降低成本。其具体方案如下：

第一方面，本申请公开了一种数据集群计算节点扩缩方法，包括：

在集群中部署多个计算节点以及用于存储数据的数据节点；

获取集群当前的资源使用率、待执行任务数量以及资源调度策略；

基于所述资源使用率、所述待执行任务数量以及所述资源调度策略扩容或者缩容计算节点；其中，扩容的计算节点与所述数据节点分离部署。

可选的，所述资源调度策略包括第一资源使用率阈值和第二资源使用率阈值，相应的，所述基于所述资源使用率、所述待执行任务数量以及所述资源调度策略扩容或者缩容计算节点，包括：

若所述资源使用率大于所述第一资源使用率阈值，且所述待执行任务数量不为0，则扩容计算节点；

若所述资源使用率小于所述第二资源使用率阈值，且所述待执行任务数量为0，则缩容计算节点。

可选的，所述资源调度策略还包括扩容数量；

相应的，所述扩容计算节点，包括：

根据所述扩容数量扩容计算节点。

可选的，所述缩容计算节点，包括：

解雇计算节点，并检测该计算节点中任务是否均已处理完成；

若该计算节点中任务均已处理完成，则销毁该计算节点。

可选的，所述在集群中部署多个计算节点，包括：

在集群中部署多个agent节点，并在每个所述agent节点中启动一个计算节点，以完成多个计算节点的部署；

可选的，所述方法还包括：

获取任一所述agent节点的镜像文件；

所述镜像文件用于扩容计算节点。

可选的，还包括：

收集各用户的任务数据；其中，所述任务数据包括任务的实际耗时、任务执行时的资源使用情况以及调度时间范围；

基于所述任务数据生成所述资源调度策略。

可选的，还包括：

基于所述任务数据确定各用户的任务调度时间；

根据任务调度时间将相应用户的任务下发到集群进行任务执行。

第二方面，本申请公开了一种数据集群计算节点扩缩装置，包括：

节点部署模块，用于在集群中部署固定数量的计算节点以及用于存储数据的数据节点；

资源使用率获取模块，用于获取集群当前的资源使用率；

待执行任务数量获取模块，用于获取集群当前的待执行任务数量；

资源调度策略获取模块，用于获取集群当前的资源调度策略；

计算节点扩缩模块，用于基于所述资源使用率、所述待执行任务数量以及所述资源调度策略扩容或者缩容计算节点；其中，扩容的计算节点与所述数据节点分离部署。

第三方面，本申请公开了一种电子设备，包括处理器和存储器；其中，

所述存储器，用于保存计算机程序；

所述处理器，用于执行所述计算机程序以实现前述的数据集群计算节点扩缩方法。

第四方面，本申请公开了一种计算机可读存储介质，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现前述的数据集群计算节点扩缩方法。

第五方面，本申请公开了一种计算机程序产品，所述计算机程序产品被执行时实现前述的数据集群计算节点扩缩方法。

可见，本申请在集群中部署多个计算节点以及用于存储数据的数据节点，并获取集群当前的资源使用率、待执行任务数量以及资源调度策略，然后基于所述资源使用率、所述待执行任务数量以及所述资源调度策略扩容或者缩容计算节点；其中，扩容的计算节点与所述数据节点分离部署。也即，本申请实施例可以先部署多个计算节点，来保障集群的正常使用，在扩容的计算节点与数据节点分离部署的基础上，根据集群当前的资源使用率、待执行任务数量以及资源调度策略动态的扩容或者缩容计算节点，以合理的应对任务高峰时期以及低峰时期资源需求，能够避免资源浪费，减少人工操作，从而降低成本。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请公开的一种数据集群计算节点扩缩方案所采用的系统架构图；

图2为本申请公开的一种数据集群计算节点扩缩方法流程图；

图3为本申请公开的一种具体的数据集群示意图；

图4为本申请公开的一种具体的ambari集群管理方式下的数据集群计算节点扩容示意图；

图5为本申请公开的一种具体的资源调度策略和任务调度时间生成示意图；

图6为本申请公开的一种具体的数据集群计算节点扩缩方法流程图；

图7为本申请公开的一种具体的数据集群计算节点扩缩方法流程图

图8为本申请公开的一种数据集群计算节点扩缩装置结构示意图；

图9为本申请公开的一种电子设备结构图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

现有的企业数据业务涉及到的大数据平台，要么使用云厂商的数据集群，要么就在自己本地机房建设数据集群，而使用云厂商的数据集群，所有的Hadoop生态和相关组件都严重依赖云厂商的版本，费用高，版本固定，出问题响应速度慢，难以进行定制化二次开发以及数据迁移。而如果使用自建机房部署数据集群，需要事先根据任务高峰时期来评估资源部署数据集群，但是白天大部分机器都是空闲的，造成集群资源的巨大浪费，而且后期需要人工扩充节点，随着业务增多，人工扩充会更加频繁且维护时间较长。并且，现有方案中存储与计算混杂在一起，常常会因为了扩存储而带来额外的计算扩容，这其实就是一种浪费；同理，只为了提升计算能力，也会带来一段时期的存储浪费。为此，本申请提供了一种数据集群计算节点扩缩方案，能够避免资源浪费，减少人工操作，从而降低成本。

本申请的数据集群计算节点扩缩方案中，采用的系统框架具体可以参见图1所示，具体可以包括：电子设备101以及数据集群102，电子设备101执行的步骤包括：在数据集群102中部署多个计算节点以及用于存储数据的数据节点；获取集群当前的资源使用率、待执行任务数量以及资源调度策略；基于所述资源使用率、所述待执行任务数量以及所述资源调度策略扩容或者缩容计算节点；其中，扩容的计算节点与所述数据节点分离部署。其中，电子设备可以为终端设备或者服务器等。并且，电子设备101还用于数据集群102中各用户的任务数据，包括任务的实际耗时、任务执行时的资源使用情况以及调度时间范围，并基于所述任务数据生成所述资源调度策略，以及确定各用户的任务调度时间。

参见图2所示，本申请实施例公开了一种数据集群计算节点扩缩方法，包括：

步骤S11：在集群中部署多个计算节点以及用于存储数据的数据节点。

在具体的实施方式中，可以在集群中部署多个agent节点，并在每个所述agent节点中启动一个计算节点，以完成多个计算节点的部署；并且，获取任一所述agent节点的镜像文件；所述镜像文件用于扩容计算节点。进一步的，可以部署数据集群，保持固定数量的计算节点，比如，可以部署大数据hadoop集群，保持固定数量的master节点和slave节点，在每个slave节点中部署一个计算节点，保证集群的正常使用。并且，本申请实施例可以使用ambari集群管理方式来做集群的动态扩充，因此，本申请实施例在集群中部署固定数量的ambari agent节点，以完成固定数量的计算节点的部署。也即，每个slave节点中部署一个ambari agent节点，在每个ambari agent节点基于自动化脚本启动一个nodeManager节点，作为计算节点。并且，本申请实施例可以对任一ambari agent节点镜像化，获取任一所述ambari agent节点的镜像文件，以便基于所述镜像文件扩容计算节点。

进一步的，本申请实施例为了便于计算节点的动态扩充，数据存储在对象存储，也即，数据节点采用对象存储，并且数据存储和数据计算是分离的，计算节点根据业务需求动态的进行扩充和缩容，在一种实施方式中，扩容的计算节点与数据节点分离部署，所述多个计算节点中的每个计算节点与一个数据节点部署在同一节点中，这样，可以提升数据读取效率，例如，参见图3所示，图3为本申请实施例公开的一种具体的数据集群示意图。大数据hadoop集群，保持固定的master和slave节点，在资源需求高峰期，动态地添加和删除nodeManager计算节点，并且，在固定的slave节点中部署dn(即datanode，数据节点)，数据节点支持包括但不限于S3存储和hdfs(即Hadoop Distributed File System，分布式文件系统)存储，针对扩充的计算节点不部署数据节点，需要指出的是，现有技术中，没有采用数据存储的hdfs与计算节点不能很方便的扩充，而本申请中，数据存储和数据计算是分离的，并采用对象存储，方便根据业务需求动态的扩充和缩容计算节点。也即，扩充的计算节点从固定节点中的对象存储中读取数据进行处理。当然，在另一种实施方式中中，所述多个计算节点也可以与所述数据节点分离部署。

并且，可以使用ambari集群管理方式来做集群的动态扩充。例如，参见图4所示，图4为本申请实施例公开的一种具体的ambari集群管理方式下的数据集群计算节点扩容示意图。首先，初始化ambari和ambari server节点以及固定数量的ambari agent节点，将其中的一个ambari agent节点镜像化，作为EC2(即Elastic Compute Cloud，弹性计算云)扩充节点实例的基础镜像，调用ambari添加机器到集群的api接口，在高峰期按需将机器动态的添加到集群作为计算节点，并在节点缩容时，通过ambari接口将扩容的计算节点进行解雇，检测到解雇节点的任务均执行完成后，调用EC2的实例销毁接口，对扩充的机器进行销毁。

这样，能够最小化数据集群的部署，只需要部署基础的数据集群，减少部署成本，在数据运行高峰期，动态扩充计算节点，在数据运行低峰期，动态缩减计算节点，减少集群资源长期占用成本

步骤S12：获取集群当前的资源使用率、待执行任务数量以及资源调度策略。

在具体的实施方式中，可以定时获取集群当前的资源使用率、待执行任务数量。比如，每20秒获取一次集群当前的资源使用率、待执行任务数量。

进一步的，本申请实施例可以收集各用户的任务数据；其中，所述任务数据包括任务的实际耗时、任务执行时的资源使用情况以及调度时间范围；基于所述任务数据生成所述资源调度策略。其中，前述生成可以指更新或优化。并且，可以利用任务执行时每秒的资源使用率取平均值，得到任务执行时的资源使用情况，调度时间范围为用户要求的上传数据时间和下载数据时间对应的时间范围，比如，2点到7点，2点上传数据、7点下载数据，也即需要在该时间范围内执行完用户的任务。本申请实施例可以从集群收集各用户的任务数据，通过数据分析，使用线性规划算法以及机器学习算法推测出用户任务合理的调度时间以及资源调度策略。例如，在一种实施方式中，可以先量化每个任务的资源使用情况，对于第i个任务task(i)，其瞬时资源使用量为r(i)(平衡波动后的统计量)，其执行的实际耗时为用t(i)，定义任务task(i)的资源使用量为：Res(i)＝r(i)*t(i)。然后，在有限资源R_limit和有限时间T_limit的约束条件下，求解使Res_used＝∑_ir(i)×t(i)最小化的任务执行顺序的排列序号l，其中，Res_used表示所有任务的资源使用总量。将指定某个任务的执行顺序看成是一个阶段，并且各个阶段不是相互独立的，它们相互影响，这就是一个多阶段的决策问题，各个阶段的决策构成一个决策序列。每个阶段决策后即产生一个状态，又由于状态满足无后效性，因此每个阶段抉择时，只需要考虑当前状态而无须考虑过程的历史，那么状态转移方程为Res_used(k)＝minRes_used(k-1)+Res(k)，其中，Res_used(k)表示第k个阶段所有任务的资源使用总量，minRes_used(k-1)表示第k-1个阶段的所有任务的资源使用总量最小值，Res(k)表示第k个任务的资源使用量。可以理解的是，基于执行顺序可以确定调度时间。

并且，本申请实施例可以定期的收集各用户的任务数据，更新资源调度策略和任务调度时间。进一步的，本申请实施例还可以基于所述任务数据确定各用户的任务调度时间；根据任务调度时间将相应用户的任务下发到集群进行任务执行。具体的，为用户的任务分配资源队列，执行相应的任务。

例如，参见图5所示，本申请实施例公开了一种具体的资源调度策略和任务调度时间生成示意图。在没有足够用户的任务数据时，可以人工输入调度时间，该调度时间为根据人工经验以及用户要求的调度时间范围输入的调度时间，并配置初始的资源调度策略，进一步的，本申请实施例可以收集线上的用户的任务数据，优化资源调度策略以及用户的任务调度时间。

需要指出的是，相对于现有技术的认为协调和设置任务的调度时间，当任务过多，人力则难以进行人工编排任务和准确预估资源调度策略，而本申请实施例根据收集的任务数据，结合机器学习算法、线性规划算法给出调度时间的最优解和优化计算的资源调度策略并且进行长期的训练优化，而不是人力编排固定的调度时间，相对于传统方案大大节约了机器资源成本和人力成本。

以某数据应用平台为例，该数据应用平台提供门店销量预测、销售顶点风险预警、客户价值分析、零售关联商品推荐、智能销售预测、商品价值分析、应收坏账风险预测、采购订单风险预警等服务，该数据应用平台的后台为数据集群，用户将数据上传至该数据集群，并通过该数据集群执行相应的任务，并下载任务执行完成的数据，也即，相应服务输出数据。比如，其中，门店销量预测为针对零售行业门店商品零售场景，综合门店销售、库存等业务数据和外部相关数据，基于大数据和机器学习技术对商品的销量做预测。

步骤S13：基于所述资源使用率、所述待执行任务数量以及所述资源调度策略扩容或者缩容计算节点。

在具体的实施方式中，若所述资源使用率大于所述第一资源使用率阈值，且所述待执行任务数量不为0，则扩容计算节点，若所述资源使用率大于所述第一资源使用率阈值，且所述待执行任务数量为0，则不扩容计算节点；若所述资源使用率小于所述第二资源使用率阈值，且所述待执行任务数量为0，则缩容计算节点，若所述资源使用率小于所述第二资源使用率阈值，且所述待执行任务数量不为0，则不缩容计算节点。进一步的，所述资源调度策略还包括扩容数量；相应的，本申请实施例可以根据所述扩容数量扩容计算节点。并且，资源调度策略包括不同时段的扩容数量。比如，在0至7时的高峰时段，可以每次扩容5个计算节点，8时每次扩容1个计算节点。并且，在缩容计算节点时，本申请实施例可以解雇计算节点，并检测该计算节点中任务是否均已处理完成；若该计算节点中任务均已处理完成，则销毁该计算节点。进一步的，资源调度策略还包括缩容数量，根据所述缩容数量缩容计算节点。

进一步的，若所述资源使用率大于所述第一资源使用率阈值，且所述待执行任务数量不为0，则判断当前扩容的计算节点是否达到扩容阈值，若是，则停止扩容，并触发告警，否则扩容计算节点。

例如，参见图6所示，图6为本申请实施例公开的一种具体的数据集群计算节点扩缩方法流程图。每20s获取一次集群的资源使用率，资源使用率为资源队列的使用率。若资源使用率小于20％，且排队的待处理任务数量为0，则解雇nodeManager计算节点，等待container(容器)释放，每个任务对应一个container，等待container释放即等待任务执行结束，在container释放后，销毁nodeManager节点，并销毁机器。需要指出的是，首先将nodeManager计算节点从yarn上进行解雇，那么后续的container就不会提交到这个节点上了，如果解雇的节点上的container为0，那么就将这个nodemanager进行销毁处理。若资源使用率大于20％，且待处理任务数量为大于0，则判断当前扩容机器数量是否达到扩容阈值也即允许扩容的最大数量，可以理解的是，一个机器对应一个计算节点，若没有达到扩容阈值，则根据当前调度策略扩容一个计算节点，并等待5分钟，也即虽然每20秒读取一次资源使用率，但确定扩容一个计算节点后都需要等待5分钟，完成扩容的相关操作，即便当前读取的资源使用率满足扩容条件，在5分钟内不再进行扩容。也即，本申请实施例通过获取Yarn资源队列的使用率来动态的扩缩容NodeManager节点。

例如，参见图7所示，本申请实施例公开了一种具体的数据集群计算节点扩缩方法流程图。在进行扩容时，基于ambari agent节点的镜像文件，安装jdk、进行ambari agent安装及配置、nodeManager安装，初始化EC2，也即，在初始化阶段，jdk、ambari agent、nodeManager以镜像化的方式初始化EC2，并且，host管理可通过nfs挂载的方式进行统一管理。已初始化EC2后，基于自动化脚本进行ambari agent安装及配置以及通过ambariserver API启动nodeManager，完成扩容，之后配置资源队列，资源调度为fair schedule，完成队列配置后，任务运行开始，任务完成后，释放资源，退还EC2，完成缩容。

参见图8所示，本申请实施例公开了一种数据集群计算节点扩缩装置，包括：

节点部署模块11，用于在集群中部署固定数量的计算节点以及用于存储数据的数据节点；

资源使用率获取模块12，用于获取集群当前的资源使用率；

待执行任务数量获取模块13，用于获取集群当前的待执行任务数量；

资源调度策略获取模块14，用于获取集群当前的资源调度策略；

计算节点扩缩模块15，用于基于所述资源使用率、所述待执行任务数量以及所述资源调度策略扩容或者缩容计算节点；其中，扩容的计算节点与所述数据节点分离部署。

其中，所述资源调度策略包括第一资源使用率阈值和第二资源使用率阈值，相应的，计算节点扩缩模块15，具体用于：

若所述资源使用率大于所述第一资源使用率阈值，且所述待执行任务数量不为0，则扩容计算节点；若所述资源使用率小于所述第二资源使用率阈值，且所述待执行任务数量为0，则缩容计算节点。

进一步的，所述资源调度策略还包括扩容数量；

相应的，计算节点扩缩模块15，具体用于：根据所述扩容数量扩容计算节点。

进一步的，计算节点扩缩模块15，具体用于：解雇计算节点，并检测该计算节点中任务是否均已处理完成；若该计算节点中任务均已处理完成，则销毁该计算节点。

进一步的，计算节点部署模块11，用于在集群中部署多个agent节点，并在每个所述agent节点中启动一个计算节点，以完成多个计算节点的部署；

并且，所述装置还包括镜像文件获取模块，用于获取任一所述agent节点的镜像文件；所述镜像文件用于扩容计算节点。

另外，所述装置还包括：

任务数据收集模块，用于收集各用户的任务数据；其中，所述任务数据包括任务的实际耗时、任务执行时的资源使用情况以及调度时间范围；

资源调度策略生成模块，用于基于所述任务数据生成所述资源调度策略。

进一步的，所述装置还包括：

任务调度时间确定模块，用于基于所述任务数据确定各用户的任务调度时间；

任务下发模块，用于根据任务调度时间将相应用户的任务下发到集群进行任务执行。

参见图9所示，本申请实施例公开了一种电子设备20，包括处理器21和存储器22；其中，所述存储器22，用于保存计算机程序；所述处理器21，用于执行所述计算机程序，前述实施例公开的数据集群计算节点扩缩方法。

关于上述数据集群计算节点扩缩方法的具体过程可以参考前述实施例中公开的相应内容，在此不再进行赘述。

并且，所述存储器22作为资源存储的载体，可以是只读存储器、随机存储器、磁盘或者光盘等，存储方式可以是短暂存储或者永久存储。

另外，所述电子设备20还包括电源23、通信接口24、输入输出接口25和通信总线26；其中，所述电源23用于为所述电子设备20上的各硬件设备提供工作电压；所述通信接口24能够为所述电子设备20创建与外界设备之间的数据传输通道，其所遵循的通信协议是能够适用于本申请技术方案的任意通信协议，在此不对其进行具体限定；所述输入输出接口25，用于获取外界输入数据或向外界输出数据，其具体的接口类型可以根据具体应用需要进行选取，在此不进行具体限定。

进一步的，本申请实施例还公开了一种计算机可读存储介质，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现前述实施例公开的数据集群计算节点扩缩方法。

本申请实施例还公开了一种计算机程序产品，计算机程序产品被执行时实现前述实施例公开的数据集群计算节点扩缩方法。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上对本申请所提供的一种数据集群计算节点扩缩方法、装置、设备及介质进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims

1.一种数据集群计算节点扩缩方法，其特征在于，包括：

在集群中部署多个计算节点以及用于存储数据的数据节点；

2.根据权利要求1所述的数据集群计算节点扩缩方法，其特征在于，所述资源调度策略包括第一资源使用率阈值和第二资源使用率阈值，相应的，所述基于所述资源使用率、所述待执行任务数量以及所述资源调度策略扩容或者缩容计算节点，包括：

3.根据权利要求2所述的数据集群计算节点扩缩方法，其特征在于，所述资源调度策略还包括扩容数量；

相应的，所述扩容计算节点，包括：

根据所述扩容数量扩容计算节点。

4.根据权利要求2所述的数据集群计算节点扩缩方法，其特征在于，所述缩容计算节点，包括：

若该计算节点中任务均已处理完成，则销毁该计算节点。

5.根据权利要求1所述的数据集群计算节点扩缩方法，其特征在于，所述在集群中部署多个计算节点，包括：

所述方法还包括：

获取任一所述agent节点的镜像文件；所述镜像文件用于扩容计算节点。

6.根据权利要求1至5任一项所述的数据集群计算节点扩缩方法，其特征在于，还包括：

基于所述任务数据生成所述资源调度策略。

7.根据权利要求6所述的数据集群计算节点扩缩方法，其特征在于，还包括：

基于所述任务数据确定各用户的任务调度时间；

8.一种数据集群计算节点扩缩装置，其特征在于，包括：

节点部署模块，用于在集群中部署多个计算节点以及用于存储数据的数据节点；

资源使用率获取模块，用于获取集群当前的资源使用率；

9.一种电子设备，其特征在于，包括处理器和存储器；其中，

所述存储器，用于保存计算机程序；

所述处理器，用于执行所述计算机程序以实现如权利要求1至7任一项所述的数据集群计算节点扩缩方法。

10.一种计算机可读存储介质，其特征在于，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的数据集群计算节点扩缩方法。