一种资源调度方法、装置、电子设备及存储介质与流程

本申请涉及大数据处理技术领域，尤其涉及一种资源调度方法、装置、电子设备及存储介质。

背景技术：

spark是专为大规模数据处理而设计的快速通用的计算集群，采用分布式计算框架，在海量数据的处理与计算、机器学习和数据挖掘方面具有重要意义。

在spark中执行计算作业时，资源分配是非常重要的一方面。目前，无论是静态资源分配还是动态资源分配，都是在任务执行之初就已根据设定值或根据计算数据量、任务完成时间、总资源量、任务数量等指标为每个计算作业分配好资源。在计算作业执行完毕之前，其对应的资源不会发生变化。

但是，由于资源配置固定不变，无法根据计算作业的变化而自动调整，从而出现计算作业可能由于得不到足够的资源而计算缓慢，或者计算作业还存在资源空闲，造成资源浪费。

技术实现要素：

为了解决上述技术问题或者至少部分地解决上述技术问题，本申请实施例提供了一种资源调度方法、装置、电子设备及存储介质。

根据本申请实施例的一个方面，提供了一种资源调度方法，包括：

实时监测计算集群中计算作业的资源使用信息；

当根据所述资源使用信息确定所述计算作业存在资源使用异常时，确定所述计算作业对应的执行器的调度策略；

对所述执行器执行所述调度策略对应的调度操作。

可选的，所述实时监测计算集群中计算作业的资源使用信息，包括：

实时采集所述计算集群中计算作业的以下至少一项资源使用数据：cpu利用数据、内存利用数据及垃圾回收数据；

将预设时长内的所述资源使用数据汇总为所述计算作业的资源使用信息。

可选的，所述确定所述计算作业对应的执行器的调度策略，包括：

确定所述资源使用异常对应的异常类型；

当所述异常类型为内存异常时，确定所述异常类型对应的调度策略为：调整所述计算作业对应的执行器数量和/或调整所述执行器的内存分配量；

当所述异常类型为cpu异常时，确定所述异常类型对应的调度策略为：调整所述计算作业对应的执行器数量和/或调整所述执行器对应的cpu核芯数量。

可选的，所述资源使用异常包括内存不足或内存空闲，所述根据所述资源使用信息确定所述计算作业存在资源使用异常，包括：

根据所述内存利用数据确定预设时长内的内存利用率，并根据所述垃圾回收数据确定所述预设时长内的平均垃圾回收时长；

当在所述预设时长内所述内存利用率大于或等于第一内存阈值，且所述平均垃圾回收时长大于或等于第一时长阈值时，确定所述资源使用异常为内存不足；

当在所述内存利用率小于或等于第二内存阈值，且所述平均垃圾回收时长小于或等于第二时长阈值时，确定所述资源使用异常为内存空闲。

可选的，当确定所述资源使用异常为内存不足时，所述确定所述计算作业对应的执行器的调度策略，包括：

获取所述执行器对应的内存分配量及所述计算集群中单个计算节点的最大可分配内存量；

当所述内存分配量与所述最大可分配内存量之间的差值满足第一预设条件时，确定所述调度策略为增加所述执行器的内存分配量；

当所述内存分配量与所述最大可分配内存量之间的差值不满足所述第一预设条件时，确定所述调度策略为增加所述计算作业对应的执行器数量。

可选的，当确定所述计算作业存在内存空闲时，所述确定所述计算作业对应的执行器的调度策略，包括：

根据所述cpu利用数据确定所述预设时长内的cpu利用率；

当所述cpu利用率大于或等于第一cpu阈值时，确定所述调度策略为降低所述执行器的内存分配量；

当所述cpu利用率小于所述第一cpu阈值时，确定所述调度策略为减少所述计算作业对应的执行器数量。

可选的，所述调度策略还包括：调度持续时长；

所述对所述执行器执行所述调度策略对应的调度操作，包括：

在所述调度持续时长内，对所述内存分配量、所述执行器数量和/或所述cpu核芯数量进行调整。

可选的，所述根据所述垃圾回收数据确定预设时长内的平均垃圾回收时长，包括：

根据所述垃圾回收数据统计所述预设时长内所述计算作业对应的总垃圾回收时长；

获取所述计算作业对应的执行器数量；

将所述总垃圾回收时长除以所述执行器数量，得到每个所述执行器对应的所述平均垃圾回收时长。

根据本申请实施例的另一个方面，提供了一种资源调度装置，包括：

监测模块，用于实时监测计算集群中计算作业的资源使用信息；

分析模块，用于当根据所述资源使用信息确定所述计算作业存在资源使用异常时，确定所述计算作业对应的执行器的调度策略；

调度模块，用于对所述执行器执行所述调度策略对应的调度操作。

根据本申请实施例的另一个方面，提供了一种电子设备，包括：处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；

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

所述处理器，用于执行计算机程序时，实现上述方法步骤。

根据本申请实施例的另一个方面，提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述方法步骤。

本申请实施例提供的上述技术方案与现有技术相比具有如下优点：

实时根据监测到的计算作业的资源使用情况判断每个计算作业是否出现资源使用异常，当出现异常时，可实时对计算作业的每个执行器进行资源调整。这样，在计算作业执行过程中动态地对每个执行器的内存和/或cpu使用进行调整，为计算作业分配正常执行所需的资源，保证其性能和执行速度，又减少资源空闲，避免资源浪费，提高整个计算集群的资源使用率。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。

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

图1为本申请实施例提供的一种资源调度方法的流程图；

图2为本申请另一实施例提供的一种资源调度方法的流程图；

图3为本申请另一实施例提供的一种资源调度方法的流程图；

图4为本申请另一实施例提供的一种资源调度方法的流程图；

图5为本申请另一实施例提供的一种资源调度方法的流程图；

图6为本申请实施例提供的一种资源调度装置的框图；

图7为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

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

在计算集群spark中，存在分布式部署的多个计算节点，每个计算节点上可运行多个执行器(executor)。spark将提交的计算作业(job)转化为任务(task)，将task调度到各个executor，由executor执行被分配的task。

executor是一个工作进程，负责在spark作业中运行task，各个task间相互独立。spark应用启动时，executor被同时启动，并且始终伴随着整个spark应用的生命周期而存在。如果有executor发生了故障或崩溃，spark应用也可以继续执行，会将出错task上的任务调度到其他executor上继续运行。

spark根据job对应的数据量、完成时间、计算复杂度等为job分配资源。spark分配给每个job的资源包括：executor的数量、每个executor的内存分配量、每个executor的cpu核芯(core)分配数量，等等。因此，本实施例中对资源的调度主要是对executor的数量、内存分配量、cpucore分配数量进行调整。

其中，executor的数量及每个executor对应的cpucore数量，决定了能够并行执行的task的数量。例如，有6个executor，每个executor对应的2个cpucore，则可并行执行12个task，12个task执行完毕后，再换下一批12个task。如果将executor数量增加到10个，每个executor对应的cpucore数量不变，则并行执行的task为20个。若executor数量不变，每个executor对应的cpucore数量增加到5个，则并行执行的task为30个。由此可见，通过增加executor的数量或每个executor对应的cpucore数量，可以增加任务并行能力，计算性能即计算速度也相应提升。

每个executor的内存分配量决定了在计算过程中可以缓存多少数据、写磁盘的频率为多少、以及垃圾回收(garbagecollect，gc)的频率和时间。如果为每个executor分配的内存量较少，在执行task时，可能会导致频繁出现java虚拟机(javavirtualmachine，jvm)堆内存写满，频繁进行垃圾回收，计算速度减慢；另外，如果内存不足，需要将更多的数据写入磁盘，磁盘输入输出量(读写次数)较高。若每个executor的内存量提高，则可减少gc频率和时间，提高计算速度；可以在内存中缓存更多的数据，减少写入磁盘的数据量，降低磁盘输入输出量，提升计算性能。

一般来说，每个计算节点的节点内存量是固定的，且需要留有一部分内存用于操作系统和spark的守护进程。因此，每个计算节点上executor的数量与每个executor的内存分配量的乘积小于该计算节点的最大可分配内存量。如计算节点的节点内存量为64gb，其中1gb用于操作系统和spark的守护进程，则其最大可分配内存量为63gb。

本申请实施例，实时监测计算集群(spark)中各个计算作业的资源使用情况，判断计算作业是否出现资源不足或资源浪费等资源使用异常，当出现资源使用异常时，确定执行该计算作业的executor的调度策略，根据调度策略对executor进行调整。

下面首先对本发明实施例所提供的一种资源调度方法进行介绍。

图1为本申请实施例提供的一种资源调度方法的流程图。如图1所示，该方法包括以下步骤：

步骤s11，实时监测计算集群中计算作业的资源使用信息。

可选的，步骤s11包括：实时采集计算集群中计算作业的以下至少一项资源使用数据：cpu利用数据、内存利用数据及垃圾回收数据；将预设时长内的所述资源使用数据汇总为所述计算作业的资源使用信息。

其中，gc主要是清理掉内存中不再使用的对象，腾出内存空间用户创建其它新对象。每当gc发生时，都会在工作日志中打印消息。因此，通过日志分析，可以统计得到包括每个计算作业对应总gc时长。可选的，本实施例基于总gc时长确定是否存在资源异常，gc数据中除了总gc时长外，还可以包括gc频率等等。

步骤s12，当根据资源使用信息确定计算作业存在资源使用异常时，确定计算作业对应的执行器的调度策略。

资源使用异常包括资源不足或资源空闲。本实施例中的资源主要包括内存和/或cpu，即内存不足或内存空闲，cpu不足或cpu空闲。

当job存在内存不足时，调度策略可以为增加executor的数量或增加每个executor的内存分配量；反之，当job存在内存空闲时，调度策略为减少executor的数量或降低每个executor的内存分配量。

当job存在cpu不足时，调度策略可以为增加每个executor的cpucore分配数量；反之，当job存在cpu空闲时，调度策略为减少每个executor的cpucore分配数量。

步骤s13，对执行器执行调度策略对应的调度操作。

在spark中，可以调整spark-submitshell脚本中的参数，以实现对executor的资源调度操作。

例如，spark-submitshell脚本中的具体参数如下：

(1)num-executors3，配置executor的数量为3；

(2)executor-memory100m，配置每个executor的内存分配量为100mb；

(3)executor-cores3，配置每个executor对应的cpucore数量为3。

本实施例中，实时根据监测到的计算作业的资源使用情况判断每个计算作业是否出现资源使用异常，当出现异常时，可实时对计算作业的每个执行器进行资源调整。这样，在计算作业执行过程中动态地对每个执行器的内存和/或cpu使用进行调整，为计算作业分配正常执行所需的资源，保证其性能和执行速度，又减少资源空闲，避免资源浪费，提高整个计算集群的资源使用率。

在可选实施例中，根据cpu利用数据可以计算计算作业的总cpu利用率，若总cpu利用率均小于或等于一个预设的cpu阈值，如小于30％，则可减少每个executor对应的cpucore；反之，若各executor在预设时长内的cpu利用率均大于或等于另一个预设的cpu阈值，如小于90％，则可增加每个executor对应的cpucore。

spark作为一个基于内存的分布式计算引擎，且执行的作业大多是内存密集型的计算任务，集群的资源利用率和计算效率与内存使用情况是强依赖的关系，因此，对于内存资源的调度至关重要。在可选实施例中，可以根据内存使用数据和gc数据确定计算作业是否存在内存不足或内存空闲。

可选的，步骤s12中，确定计算作业对应的执行器的调度策略，包括：

确定所述资源使用异常对应的异常类型；

当所述异常类型为内存异常时，确定所述异常类型对应的调度策略为：调整所述计算作业对应的执行器数量和/或调整所述执行器的内存分配量；

当所述异常类型为cpu异常时，确定所述异常类型对应的调度策略为：调整所述计算作业对应的执行器数量和/或调整所述执行器对应的cpu核芯数量。

可选的，调度策略还包括：调度持续时长。上述步骤s13包括：在调度持续时长内，对内存分配量、执行器数量和/或cpu核芯数量进行调整。

例如，该调度持续时长为30分钟，在30分钟内，执行相应的调度操作，当到达30分钟后，可以恢复job之前的资源使用情况，或者再次根据这30分钟内的资源使用信息进行新一次的资源调度。

图2为本申请另一实施例提供的一种资源调度方法的流程图。如图2所示，资源使用异常包括内存不足或内存空闲，步骤s12中根据资源使用信息确定计算作业存在资源使用异常，包括：

步骤s21，根据内存利用数据确定预设时长内的内存利用率，并根据垃圾回收数据确定预设时长内的平均垃圾回收时长；

步骤s22，当在预设时长内内存利用率大于或等于第一内存阈值，且平均垃圾回收时长大于或等于第一时长阈值时，确定资源使用异常为内存不足；

步骤s23，当在内存利用率小于或等于第二内存阈值，且平均垃圾回收时长小于或等于第二时长阈值时，确定资源使用异常为内存空闲。

可选的，第一内存阈值和第二内存阈值可以设置为相同或不同。第一时长阈值和第二时长阈值可以设置为相同或不同。

可选的，预设时长可以与调度持续时长相等，如都是30分钟，或者预设时长也可以为于或小于调度时长。

例如，预设时长可以为30分钟。30分钟内job的内存利用率大于50％，且平均gc时长大于1分钟，确定内存不足。又例如，当30分钟内job的内存利用率大于或等于30％，且平均gc时长小于30秒，确定内存空闲。

其中，步骤s21中平均gc时长可以通过如下步骤计算得到：

步骤a1，根据垃圾回收数据统计预设时长内计算作业对应的总垃圾回收时长；

步骤a2，获取计算作业对应的执行器数量；

步骤a3，将总垃圾回收时长除以执行器数量，得到每个执行器对应的平均垃圾回收时长。

例如，统计30分钟内job对应的总gc时长为t，executor数量为n，则每个executor对应的平均垃圾回收时长

在可选实施例中，当确定资源使用异常为内存不足时，可以通过增加executor的内存分配量或增加executor数量来增加计算作业所使用的内存量。图3为本申请另一实施例提供的一种资源调度方法的流程图。如图3所示，上述步骤s12中确定计算作业对应的执行器的调度策略，包括：

步骤s31，获取执行器对应的内存分配量及计算集群中单个计算节点的最大可分配内存量。

步骤s32，当内存分配量与最大可分配内存量之间的差值满足第一预设条件时，确定调度策略为增加执行器的内存分配量。

例如，第一预设条件为内存分配量与预设倍数的乘积小于最大可分配内存量，或者第一预设条件为内存分配量与最大可分配内存量之间的差值大于或等于预设值。

步骤s33，当内存分配量与最大可分配内存量之间的差值不满足第一预设条件时，确定调度策略为增加计算作业对应的执行器数量。

例如，内存分配量与预设倍数的乘积大于或等于最大可分配内存量，或者，内存分配量与最大可分配内存量之间的差值小于或等于预设值。

例如，每个executor的内存分配量为m，最大可分配内存量为m。例如，第一预设条件为内存分配量与预设倍数的乘积小于最大可分配内存量，预设倍数可设置为1.5。

当1.5m＜m时，即在该计算节点上还存在一定可分配内存空间，则可提高executor的内存分配量。每一次对executor增加/减少的内存量可以为内存分配量的一定倍数，如每次提高0.5m的内存量；或者根据最大可分配内存量确定每次增加/减少的内存量，如每次增加0.2m；或者设定每次增加/减少固定的内存量，如增加200mb；等等。

若提高executor的内存分配量，可保持executor数量不变。

当1.5m≥m时，计算节点可分配内存空间不足，则无法再增加每个executor的内存量，可增加executor数量。例如，每次增加/减少固定的executor数量，如每次增加2个executor；或者，每一次增加/减少的executor数量可以为executor数量n的一定倍数，如当n＝1时，每次增加1个executor，当n≥2时，每次增加int(0.5n)个executor；等等。

若增加executor数量，可保持executor的内存分配量不变。

可选的，当内存分配量与预设倍数的乘积小于最大可分配内存量时，也可同时提高每个executor的内存分配量并增加executor数量。如，当1.5m＜m时，每个executor增加200mb的内存，并且增加2个executor。

本实施例中，根据内存使用数据和gc数据分析job是否存在内存不足，当存在内存不足时，通过提高每个executor的内存分配量和/或增加executor数量的方式进行内存调度。当提高executor的内存分配量时，可以减少gc频率和时间，提高计算速度，减少计算过程中写入磁盘的数据量，降低磁盘输入输出量，提升计算性能。而当增加executor数量时，可以增加并行处理的task数量，计算速度的提升使得job的完成时间减少。因此，本实施例可以通过对单个task计算性能的提升和/或对批量处理task个数的增加来提高整个job的计算性能。

在可选实施例中，当确定资源使用异常为内存空闲时，可以基于计算作业对应的cpu使用情况选择如何释放空闲的内存。

图4为本申请另一实施例提供的一种资源调度方法的流程图。如图4所示，当确定计算作业存在内存空闲时，上述步骤s12中确定计算作业对应的执行器的调度策略，包括：

步骤s41，根据cpu利用数据确定预设时长内的cpu利用率；

步骤s42，当cpu利用率大于或等于第一cpu阈值时，确定调度策略为降低执行器的内存分配量；

步骤s43，当cpu利用率小于第一cpu阈值时，确定调度策略为减少计算作业对应的执行器数量。

例如，第一cpu阈值为50％。当cpu利用率大于或等于50％，即虽然内存空闲，当cpu利用率确较高，此时如果减少executor数量，也会减少job对应的总cpucore数量，则任务并行处理能力降低，计算速度下降，cpu利用率上升，这样，对于job的计算性能也将下降。因此，此时可以降低executor的内存分配量，在保证任务并行处理能力不变的同时，释放空闲内存。

当cpu利用率小于50％时，即内存空闲，cpu利用率也不高，可以通过减少executor数量，不仅释放分配给executor的内存，还释放分配给executor的cpucore。可选的，也可同时减少executor数量且降低executor的内存分配量。

本实施例中，当出现内存空闲时，基于cpu使用情况进行空闲内存的释放，提高内存资源利用率，避免对内存资源的浪费。另外，当cpu使用情况不同时，采用不同的内存释放策略，在保证计算性能的前提下提高内存调度的精确度，避免影响对任务的正常处理。

下面以对内存资源进行调度为例，对本实施例的方法进行详细说明。图5为本申请另一实施例提供的一种资源调度方法的流程图。如图5所示，该资源调度方法包括以下步骤：

步骤s501，监测job的cpu利用数据、内存利用数据及gc数据；

步骤s502，判断距离上一次资源调度是否间隔30分钟，如果是，执行步骤s503，如果否，返回步骤s501；

步骤s503，计算内存利用率、平均gc时长及cpu利用率，获取job对应的executor数量n，每个executor对应的内存分配量m及单个计算节点的最大可分配内存量m；

步骤s504，判断内存利用率是否大于或等于50％，且平均gc时长是否大于或等于1分钟，如果是，即job对应的内存不足，执行步骤s508，如果否，则job对应的内存空闲，执行步骤s505；

步骤s505，判断cpu利用率是否大于或等于50％，如果是，执行步骤s506，如果否，执行步骤s507；

步骤s506，降低executor的内存分配量为0.5m；

步骤s507，减少为job分配的executor数量到0.5n；

步骤s508，判断1.5m是否大于或等于m，如果是，执行步骤s510，如果否，执行步骤s509；

步骤s509，提高executor的内存分配量为1.5m；

步骤s510，增加executor数量到1.5n；

步骤s511，判断job是否执行完毕，如果是，执行步骤s512，如果否，返回步骤s501；

步骤s512，释放为job分配的executor。

本实施例中，实时根据监测到job的资源使用情况判断job是否出现内存不足或内存空闲，当出现内存不足或内存空闲时，可实时根据内存利用率、平均gc时长及cpu利用率对executor数量或executor的内存分配量进行调整。当存在内存不足时，提高executor的内存分配量时，可以减少gc频率和时间，提高计算速度，减少计算过程中写入磁盘的数据量，降低磁盘输入输出量，提升计算性能。而增加executor数量，可以增加并行处理的task数量，计算速度的提升使得job的完成时间减少。从而通过对单个task计算性能的提升和/或对批量处理task个数的增加来提高整个job的计算性能。另外，当出现内存空闲时，基于cpu使用情况进行空闲内存的释放，提高内存资源利用率，避免对内存资源的浪费。另外，当cpu使用情况不同时，采用不同的内存释放策略，在保证计算性能的前提下提高内存调度的精确度，避免影响对任务的正常处理。

下述为本申请装置实施例，可以用于执行本申请方法实施例。

图6为本申请实施例提供的一种资源调度装置的框图，该装置可以通过软件、硬件或者两者的结合实现成为电子设备的部分或者全部。如图6所示，该资源调度装置包括：

监测模块61，用于实时监测计算集群中计算作业的资源使用信息；

分析模块62，用于当根据资源使用信息确定计算作业存在资源使用异常时，确定计算作业对应的执行器的调度策略；

调度模块63，用于对执行器执行调度策略对应的调度操作。

本申请实施例还提供一种电子设备，如图7所示，电子设备可以包括：处理器1501、通信接口1502、存储器1503和通信总线1504，其中，处理器1501，通信接口1502，存储器1503通过通信总线1504完成相互间的通信。

存储器1503，用于存放计算机程序；

处理器1501，用于执行存储器1503上所存放的计算机程序时，实现以下上述方法实施例的步骤。

上述电子设备提到的通信总线可以是外设部件互连标准(peripheralcomponentinterconnect，pci)总线或扩展工业标准结构(extendedindustrystandardarchitecture，eisa)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

通信接口用于上述电子设备与其他设备之间的通信。

存储器可以包括随机存取存储器(randomaccessmemory，ram)，也可以包括非易失性存储器(non-volatilememory，nvm)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。

上述的处理器可以是通用处理器，包括中央处理器(centralprocessingunit，cpu)、网络处理器(networkprocessor，np)等；还可以是数字信号处理器(digitalsignalprocessing，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现场可编程门阵列(field-programmablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

本申请还提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现以下上述方法实施例的步骤。

需要说明的是，对于上述装置、电子设备及计算机可读存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

进一步需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本发明的具体实施方式，使本领域技术人员能够理解或实现本发明。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。