CN110990154B - 一种大数据应用优化方法、装置及存储介质 - Google Patents

Abstract

本申请涉及大数据技术领域，提供一种大数据应用优化方法、装置及存储介质。其中，大数据应用优化方法应用于Hadoop集群中的主节点，包括：获取Hadoop集群中的至少一个服务节点发送的预设信息，根据预设信息对每个服务节点上的NUMA节点进行打分，其中，得分最高的至少一个NUMA节点为目标NUMA节点；向目标NUMA节点所在的目标服务节点发送绑定信息，绑定信息用于指示目标服务节点执行目标NUMA节点与大数据应用之间的绑定操作。绑定后，大数据应用能够固定在目标NUMA节点上执行，从而有利于提高大数据应用的吞吐量，实现大数据应用针对NUMA架构的性能优化。

Description

一种大数据应用优化方法、装置及存储介质

技术领域

本发明涉及大数据技术领域，具体而言，涉及一种大数据应用优化方法、装置及存储介质。

背景技术

在服务器领域，采用非一致性内存架构(Non-uniform Memory Architecture，简称NUMA架构)已成为一种趋势，在NUMA架构出现前，CPU首先重视提升频率，受限于其物理极限后，又转变为提高核数的方向发展，但逐渐CPU核在对于大内存的共享访问上出现瓶颈，而NUMA架构能够更好的解决大内存的分配与CPU的交互性能问题。

近年来，大数据技术飞速发展，特别是Hadoop生态体系中的各类分布式技术，在各行业领域中广泛应用。然而，大数据应用(包括但不限于Hadoop系统中的各类大数据组件)如何针对采用NUMA架构的服务器进行优化，当前业界尚无成熟的解决方案。

发明内容

本申请实施例的目的在于提供一种大数据应用优化方法、装置及存储介质，以改善上述技术问题。

为实现上述目的，本申请提供如下技术方案：

第一方面，本申请实施例提供一种大数据应用优化方法，应用于Hadoop集群中的主节点，所述方法包括：获取所述Hadoop集群中的至少一个服务节点发送的预设信息，根据所述预设信息对每个服务节点上的非统一内存架构NUMA节点进行打分，其中，得分最高的至少一个NUMA节点为目标NUMA节点；向所述目标NUMA节点所在的目标服务节点发送绑定信息，所述绑定信息用于指示所述目标服务节点执行所述目标NUMA节点与大数据应用之间的绑定操作，以使所述大数据应用能够在所述目标NUMA节点上执行。

上述方法通过对服务节点上的NUMA节点(在NUMA架构中也称为node)进行打分，并指示得分最高的目标NUMA节点所在的目标服务节点执行绑定操作，将目标NUMA节点与大数据应用绑定，使得大数据应用可以在Hadoop集群中固定的NUMA节点上运行，从而提高了大数据应用的数据吞吐量，实现了大数据应用在NUMA架构下的性能优化。其中，目标NUMA节点可以是得分最高的一个或多个NUMA节点，取决于大数据应用需求的资源数量。

上述所称的大数据应用既可以包括用户提交到Hadoop集群中运行的大数据业务，也可以包括Hadoop系统中的各类大数据组件(这些大数据组件通常以服务的形式存在，可以视为大数据应用)，因此方法的适用范围较广，具有较高的实用价值。此外，若对Hadoop系统中的大数据组件进行优化，对Hadoop系统的性能以及基于这些大数据组件开发的应用程序的性能亦有显著改善。

在第一方面的一种实现方式中，所述预设信息包括资源饱和度权重以及资源分配权重，所述主节点本地计算的权重包括数据本地化权重，所述主节点还针对每个服务节点计算数据本地化权重，所述根据所述预设信息对每个服务节点上的NUMA节点进行打分，包括：计算每个服务节点上的NUMA节点对应的以上三项权重的乘积，并将所述乘积作为所述NUMA节点的得分；其中，所述资源饱和度权重表征所述服务节点上的网络资源和/或磁盘I/O资源的实际使用状况；所述资源分配权重表征所述NUMA节点上的内存和/或CPU资源的逻辑使用状况；所述数据本地化权重表征所述大数据应用中使用的数据和/或服务与所述服务节点的本地化关系。

以上三项权重中，数据本地化权重和资源饱和度权重是针对服务节点的，可以视为为服务节点打分，而资源分配权重则是针对NUMA节点的，可以视为为NUMA节点打分，从而两类权重结合后获得的最终分数既考虑了服务节点的因素也考虑的NUMA节点本身的因素，也可以视为先选择服务节点然后再进一步选择NUMA节点的过程。

在第一方面的一种实现方式中，所述方法还包括：接收Hadoop集群中的服务节点发送的拒绝消息，对于发送所述拒绝消息的服务节点，不对该服务节点上的NUMA节点进行打分；其中，发送所述拒绝消息表明所述服务节点正在执行网络密集型作业。

对于服务节点处于高网络负载(即执行网络密集型作业)时，优化空间较低，这类服务节点(包括其上的所有NUMA节点)不会纳入打分范围，从而大数据应用也不会在这些服务节点上运行。

在第一方面的一种实现方式中，所述服务节点在执行I/O密集型作业时发送的所述资源饱和度权重的值小于所述服务节点未执行I/O密集型作业时发送的所述资源饱和度权重的值。

服务节点在执行I/O密集型作业时，通过NUMA绑定无法起到很好的优化效果，此时优化的重点应该是让集群资源充分利用，因此需要降低这些服务节点的打分(通过设置较小的资源饱和度权重值)，使得大数据应用尽可能被绑定到集群中的其他服务节点上去，避免出现因逻辑资源饱和，而实际CPU、内存分配不均衡，导致的伪饱和现象。

在第一方面的一种实现方式中，所述方法还包括：若所述大数据应用对内存资源的需求数量大于预设阈值，则输出提示信息，所述提示信息包括将所述大数据应用拆分成多个实例后再分别进行绑定的建议。

若大数据应用为大内存型应用，直接进行绑定可能出现进程跨NUMA节点运行的情况，导致执行效率降低，另外Java进程(大数据应用大多数采用Java语言开发)在内存超过32G时还可能会由于指针压缩问题导致执行效率降低。而进行实例拆分，即将一个进程拆分成多个功能类似的进程，使得拆分后的每个进程对资源的需求得以降低，并且拆分后的各进程可以分别进行绑定，即可以绑定到不同的NUMA节点上运行，对每个进程内部而言不存在跨NUMA节点的问题，拆分后的各进程之间可以通过跨进程通信进行有限的交互(对性能影响不大)。

在第一方面的一种实现方式中，所述服务节点上安装有用于分担CPU负载的固态硬盘。

对于大数据应用为大内存、CPU高负载的情况，此时在NUMA架构下，内存访问的性能已远小于固态硬盘的性能，采用绑定NUMA节点等方式来进行优化意义不大，采用硬件加速的方式进行优化更加合适，而硬件加速的一种方式就是在服务节点上安装固态硬盘(例如，采用一块固态硬盘加多块普通硬盘的方式，即异构存储)以分担CPU的压力。

第二方面，本申请实施例提供一种大数据应用优化方法，应用于Hadoop集群中的主节点，所述方法包括：当Hadoop系统在集群中部署完成后，执行部署在所述主节点上的优化程序包，所述优化程序包在运行时启动资源调度服务；其中，所述资源调度服务对外提供服务接口，所述服务接口在被调用时执行第一方面或第一方面的任意一种可能的实现方式提供的方法。

第一方面或第一方面的任意一种可能的实现方式提供的优化方法可以实现为一项服务(即资源调度服务)，并集成到一个优化程序包(例如，一个SDK)中，该优化程序包可以方便地部署到任意基于Hadoop系统开发的大数据平台下，通过运行该优化程序包，便可以启动资源调度服务，提供针对大数据应用的优化功能。

在第一方面的一种实现方式中，所述大数据应用为大数据业务，所述方法还包括：响应客户端发送的针对所述大数据业务的资源申请请求，调用所述服务接口。

在第一方面的一种实现方式中，所述大数据应用为所述Hadoop系统中的大数据组件，所述方法还包括：在所述大数据组件初始化时，调用所述服务接口。

在以上两种实现方式中，大数据业务可以是指使用Hadoop集群的客户想要在集群中执行的大数据应用，而大数据组件则可以视为Hadoop系统自带的大数据应用，二者采用类似的优化逻辑，只是前者需要用户提出资源申请，而后者对资源的需求可以由Hadoop系统的部署人员或者系统调优人员来指定。

在第一方面的一种实现方式中，所述优化程序包在运行时还将预设的组件程序包复制到所述大数据组件的目录下，在所述大数据组件初始化时所述组件程序包被执行，所述组件程序包在运行时执行如下操作：对所述大数据组件的资源使用进行规划；计算所述大数据组件的最高并发和最低并发；调用所述服务接口。

优化程序包运行后，预设的组件程序包(例如，jar包)被复制到大数据组件的目录下，替换掉大数据组件原生的一些用于资源调度的组件程序包，从而，大数据组件在初始化时会执行替换后的组件程序包，实现对大数据组件的优化。

在第一方面的一种实现方式中，所述优化程序包在运行时还将预设的脚本发送至所述服务节点，所述脚本在运行时执行如下操作：获取所述服务节点上的NUMA信息以及内存和CPU的绑定关系，并向所述主节点发送获取到的信息；在所述服务节点上启动心跳同步服务，用于向所述主节点定期发送所述预设信息。

主节点获得服务节点上的NUMA信息以及内存和CPU的绑定关系后，可以获知整个集群中的资源分布状况，而后续的绑定针对的也是这些资源的绑定。主节点和服务节点通信的方式可以采用心跳机制，当然也可以采用其他方式。如果一个服务节点在超时未向主节点发送心跳，对主节点来说，可以认为该服务节点不可用，也不会将其纳入打分范围。

在第一方面的一种实现方式中，所述预设信息保存在Zookeeper中，在所述主节点需要对所述NUMA节点打分时从Zookeeper中获取。

Zookeeper是分布式协调服务，其职责是保证数据在其管辖下的所有服务之间保持同步、一致。Zookeeper可以部署在主节点上，服务节点向主节点上传的预设信息可以保存在Zookeeper中，需要计算NUMA节点的得分时，可以从Zookeeper中读取这些预设信息。

第三方面，本申请实施例提供一种大数据应用优化装置，配置于Hadoop集群中的主节点，所述装置包括：打分模块，用于获取所述Hadoop集群中的至少一个服务节点发送的预设信息，根据所述预设信息对每个服务节点上的非统一内存架构NUMA节点进行打分，其中，得分最高的至少一个NUMA节点为目标NUMA节点；绑定模块，用于向所述目标NUMA节点所在的目标服务节点发送绑定信息，所述绑定信息用于指示所述目标服务节点执行所述目标NUMA节点与大数据应用之间的绑定操作，以使所述大数据应用能够在所述目标NUMA节点上执行。

第四方面，本申请实施例提供一种大数据应用优化装置，配置于Hadoop集群中的主节点，所述装置包括：资源调度模块，用于当Hadoop系统在集群中部署完成后，执行部署在所述主节点上的优化程序包，所述优化程序包在运行时启动资源调度服务；其中，所述资源调度服务对外提供服务接口，所述服务接口在被调用时执行第一方面或第一方面的任意一种可能的实现方式提供的方法。

第五方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器读取并运行时，执行第一方面或第一方面的任意一种可能的实现方式提供的方法。

第六方面，本申请实施例提供一种电子设备，包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行第一方面或第一方面的任意一种可能的实现方式提供的方法。

附图说明

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

图1示出了一种Hadoop集群的示意图；

图2示出了本申请实施例提供的一种大数据应用优化方法的流程图；

图3示出了本申请实施例提供的另一种大数据应用优化方法的流程图；

图4示出了本申请实施例提供的一种大数据应用优化装置的功能模块图；

图5示出了本申请实施例提供的另一种大数据应用优化装置的功能模块图；

图6示出了本申请实施例提供的一种电子设备的结构图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本申请实施例提供的大数据应用优化方法以NUMA绑定(即将NUMA节点和大数据应用绑定)为基础，设计一系列优化策略，实现了大数据应用在NUMA架构下的优化。此外，本申请实施例提供的大数据应用优化方法还将上述优化策略以优化程序包的方式部署到基于Hadoop系统搭建的大数据平台上运行，使得上述优化策略得以在大数据平台中落地，从而可以实现大数据组件(属于大数据应用)的优化，以及，在大数据平台上调度运行的大数据业务(属于大数据应用)的优化。

大数据应用的常见运行环境为Hadoop集群，图1示出了一种Hadoop集群的示意图。参照图1，Hadoop集群100中包括主节点110以及服务节点120，主节点110为一个(在某些实现方式中也可以是多个)，服务节点120为多个(图1中仅示出了三个)，这里所称的节点既可以是物理节点也可以是虚拟机。主节点110和服务节点120之间可以通过网络进行数据通信(图1中以连接线示出)，在一些实现方式中，各服务节点120之间也可以通过网络进行数据通信(图1中未示出)。

主节点110上可以部署资源调度平台，资源调度平台属于一种大数据平台，可以基于Hadoop系统搭建(例如，在Hadoop系统的基础上进行适当的封装)，大数据应用可以由资源调度平台统一进行资源分配并调度到服务节点120上运行，本申请实施例提供的大数据应用优化方法可以在资源调度平台中实现，但作为更一般的情况，该方法在可以主节点110上实现，并不一定属于某个大数据平台的一部分或依赖于某个大数据平台，当然，大数据应用优化方法的实现也依赖于服务节点120的某些操作，具体见后文阐述。

服务节点120的CPU采用NUMA架构，在NUMA架构中一台计算机上的资源(主要指CPU和内存)被划分成多个NUMA节点(也称为node),每个NUMA节点拥有自己的CPU和内存，NUMA节点内部使用共有的内存控制器，NUMA节点之间则通过互联模块(例如，总线)进行连接和数据交互。在同一NUMA节点内部，资源的访问效率较高，但在不同的NUMA节点之间，资源的访问效率则较低。在图1中的一个服务节点120上示出了NUMA架构的实现方式，该服务节点120上包括两个NUMA节点，第一个NUMA节点对应0号CPU以及1号、2号内存，第二个NUMA节点对应1号CPU以及3号、4号内存，两个NUMA节点之间可以通过互联模块进行连接和数据交互。

注意，本申请并不限制Hadoop集群中的所有服务节点都必须采用NUMA架构，例如，不排除某些服务节点采用对称多处理器(Symmetric Multi-Processor，简称SMP)等其他CPU架构，但本申请实施例提供的大数据应用优化方法应理解为主要针对采用NUMA架构的服务节点，因此在后文提到服务节点时，默认其采用NUMA架构，不再特别说明。

此外，还应当理解的是，图1中的Hadoop集群仅为简单示意，并不代表实际中的所有的Hadoop集群都会采用图1中的架构方式，因此图1的内容不应视为对本申请保护范围的限制。

在介绍大数据应用优化方法之前，首先介绍一些发明人在长期研究过程中发现的在NUMA架构下对大数据应用进行优化的原则，后文将要介绍的大数据应用优化方法综合考虑了其中部分或者全部的原则。

总原则：在针对大数据应用的优化中，NUMA绑定是基础，再结合大数据应用的类型和具体的应用场景等进行其他优化：

具体原则：

(1)规划大数据应用的CPU和内存时，可以先对内存进行规划，然后再选择CPU资源，与内存处于同一NUMA节点的CPU优先选择。在对内存进行规划时，可以优先选择内存资源剩余较多的NUMA节点。

(2)如果一个NUMA节点的内存资源不能满足大数据应用的需求时，可以考虑分配多个NUMA节点中的内存资源。此时，在选择CPU资源时，还需要基于CPU与内存距离就近的原则，优先选择距离较小的CPU(同一NUMA节点下的CPU和内存距离最小)。

(3)NUMA绑定的目的是要提高总体CPU利用率，不能因顾忌同NUMA节点而降低总体CPU并发程度，即使单核处理性能降低也要保证CPU不会因等待同内存分配而阻塞。

(4)在进行资源规划时，服务节点上的第一个NUMA节点(例如图1中的CPU0和内存1、内存2构成的NUMA节点)可以不参与NUMA绑定或者在参与绑定时优先级降低，因为该NUMA节点中的资源通常会被服务节点上的操作系统占用。

(5)大数据优化的重心是Java应用，因为据统计大多数大数据应用采用Java语言开发，其核心是保证JVM在高度内存访问频繁时的优化策略，如采用NUMA架构下的GC调优等，如调整JVM使用UseNUMA参数等；

(6)对于可切分内存型的大数据应用，如ElasticSearch(简写为ES)，将单个大内存型实例拆分成多个实例，通过控制应用服务中的索引分区，避免存在CPU与内存的跨NUMA节点访问，在不考虑因实例拆分带来的进程间通信开销的前提下，该优化策略使得这类大数据应用的性能得到显著提高。

图2示出了本申请实施例提供的一种大数据应用优化方法的流程图。参照图2，该方法包括：

步骤S200：主节点获取至少一个服务节点发送的预设信息，根据预设信息对每个服务节点上的非统一内存架构NUMA节点进行打分。

步骤S200中的主节点和服务节点的概念在介绍图1时已经阐述，不再重复说明。步骤S200中所称的至少一个服务节点可以是Hadoop集群中所有的服务节点，也可以是部分的服务节点，不作限定。例如，在一种实现方式中，服务节点上可以启动心跳同步服务，定期将预设信息作为心跳信息的一部分发送至主节点，心跳信息用于向主节点表明自身处于可用状态，主节点可以将按期发送了心跳信息的服务节点作为打分候选，而超时未发送心跳信息的节点则排除在打分候选之外。

对于每个服务节点(指作为打分候选的所有服务节点)上的每个NUMA节点都会参与打分(当然，也可以将服务节点上的第一个NUMA节点排除在外，或者设法降低其打分，具体见前文原则(4))，作为一种可选方案，NUMA节点的得分可以为多项权重的乘积，每项权重代表一种打分因素，该乘积表示综合考虑了多种打分因素，当然，计算NUMA节点得分的方式是比较灵活的，例如，也可以采用将多个权重相加的方式。

在一种实现方式中，打分涉及的权重包括三项，分别是资源饱和度权重、资源分配权重以及数据本地化权重。其中，资源饱和度权重和资源分配权重携带在服务节点上传至主节点的预设信息中，而数据本地化权重在主节点本地针对每个服务节点进行计算。

资源饱和度权重表征服务节点上的网络资源和/或磁盘I/O资源的实际使用状况，例如，若服务节点上的这两类资源被较多地占用，表明该服务节点不宜作为执行大数据应用的优先考虑，该权重可以取较小的值，否则可以取较大的值。

资源分配权重表征NUMA节点上的内存和/或CPU资源的逻辑使用状况。这里的逻辑使用状况区别于资源的实际使用状况，例如，可以是指通过本申请的大数据应用优化方法进行分配的资源，但在服务节点上，还存在其他资源分配途径，例如，操作系统对资源的分配，这些资源分配途径对于本申请中的大数据应用优化方法而言是未知的，因此在计算资源分配权重可以先忽略这些因素，并且，根据发明人反复实验确认，这些未知因素对权重计算影响不大。具体而言，若NUMA节点上的内存和/或CPU资源在逻辑上已经进行了较多的分配，表明该服务节点不宜作为执行大数据应用的优先考虑，该权重可以取较小的值，否则可以取较大的值。

数据本地化权重表征大数据应用中使用的数据和/或服务与服务节点的本地化关系。其中，本地化关系的含义可以通过下面两个例子来理解：例如，大数据应用要读取文件(主节点能够获知大数据应用的一些具体性质)，则对于保存文件的服务节点，该项权重可以取较大的值，其他服务节点的该项权重可以取较小的值，其他服务节点的该项权重取值还可以根据其与保存文件的服务节点之间的距离确定。又例如，大数据应用中要使用某项数据库服务，则对于部署数据库服务的服务节点，该项权重可以取较大的值，其他服务节点的该项权重可以取较小的值，其他服务节点的该项权重取值还可以根据其与部署数据库服务的服务节点之间的距离确定。即设置该项权重的目的是尽可能使得在优化后，大数据应用所要使用的数据和/或服务在大数据应用的“本地”(指和大数据应用在同一服务节点上)。

以上三项权重中，数据本地化权重和资源饱和度权重是针对服务节点的，可以视为为服务节点打分，而资源分配权重则是针对NUMA节点的，可以视为为NUMA节点打分，从而两类权重结合后获得的对NUMA节点的最终打分既考虑了服务节点的因素也考虑的NUMA节点本身的因素，或者，也可以视为先选择服务节点然后再进一步选择NUMA节点的过程。

进一步的，在某些实现方式中，资源饱和度权重以及资源分配权重也可以在主节点上进行计算，例如，服务节点将这两项权重的计算依据发送给主节点，由主节点完成计算。

可以理解的，在某些实现方式中，并不一定要同时使用以上三项权重，也可以只使用其中的一部分来进行打分，例如，只使用资源分配权重打分，只使用资源分配权重和资源饱和度权重打分，等等。并且，在另一些实现方式中，除了以上三项权重之外还可以是用其他权重进行打分，或者，并不使用以上三项权重进行打分。

打分完成后，可以将得分最高的一个或多个NUMA节点确定为绑定目标，简称目标NUMA节点。具体要确定几个NUMA节点作为目标NUMA节点取决于大数据应用对资源的需求，例如，一个NUMA节点拥有的资源就足以执行大数据应用，则只需要确定出一个NUMA节点作为目标NUMA节点就可以了，但如果一个NUMA节点拥有的资源无法执行大数据应用，则需要确定出多个NUMA节点作为目标NUMA节点。目标NUMA节点所在的服务节点称为目标服务节点。

步骤S210：主节点向目标服务节点发送绑定信息。

绑定信息用于指示目标服务节点执行目标NUMA节点与大数据应用之间的绑定操作，执行NUMA绑定后，大数据应用将固定在目标服务节点的目标NUMA节点上执行。

其中，一种常见的绑定方式是在进程(指大数据应用对应的进程)的启动脚本中添加如下前缀：

numactl-membind＝${node}-cpunodebind＝${node}

该前缀中的指令表示要启动的进程使用标识为${node}的NUMA节点上的内存以及CPU。在服务节点上启动进程时，执行该启动脚本，上述指令也被执行，从而实现了大数据应用和目标NUMA节点的绑定。

上述启动脚本既可以在主节点生成，也可以在服务节点生成。主节点在确定目标NUMA节点后，必然可以填充上述指令中的${node}，或者主节点也可以将${node}发送至服务节点，由服务节点填充到指令中。

至于运行大数据应用所需的Jar包(假如大数据应用采用Java开发)，可以由主节点部署到目标服务节点上，但不限于此种方式。

上述方法通过对服务节点上的NUMA节点进行打分，并指示得分最高的目标NUMA节点所在的目标服务节点将目标NUMA节点与大数据应用绑定，使得大数据应用可以在Hadoop集群中固定的NUMA节点上运行，从而有利于改善大数据应用的执行效率，提高大数据应用的数据吞吐量，即实现了大数据应用在NUMA架构下的性能优化。

上面所称的大数据应用既可以包括用户提交到Hadoop集群中运行的大数据业务(用户希望执行的任务，例如，计算任务)，也可以包括Hadoop系统中的各类大数据组件(这些大数据组件通常以服务的形式存在，本身也可以视为大数据应用)，因此方法的适用范围较广，具有较高的实用价值。并且，若对Hadoop系统中的大数据组件进行优化，对Hadoop系统的性能以及基于这些大数据组件开发的应用程序的性能亦有显著改善。

在大数据应用优化方法中，NUMA绑定是主要优化手段，但还可以采取一些辅助的优化策略，以下逐一进行介绍：

情况1：

若某些服务节点在执行网络密集型作业，例如Storm、SparkStreaming等流式处理作业，Kafka的接入与消费作业，消息传递作业等，服务节点将处于高网络负载状态，即系统瓶颈在网络资源上，从而这些服务节点针对大数据应用的优化空间较低。此时，服务节点可以向主节点发送拒绝消息，表明自己正在执行网络密集型作业，不适于再接收任务。主节点在接收到拒绝消息后，会将发送消息的服务节点从打分候选中排除，即这些服务节点上的所有NUMA节点都不会参与打分，从而大数据应用也不会被绑定到这些服务节点上。

情况2：

若某些服务节点在执行I/O密集型作业，例如数据接入作业，存储入库作业(包括Kafka及各类分布式数据库)，在资源有限的前提下，通过NUMA绑定无法起到很好的优化效果，此时优化的重点应该是让集群资源充分利用，因此需要降低这些服务节点的打分，使得大数据应用尽可能被绑定到集群中的其他服务节点上去，避免出现因逻辑资源饱和，而实际CPU、内存分配不均衡，导致的伪饱和现象。

为实现降低打分的目的，这些服务节点可以适当地设置权重，例如，若计算NUMA节点的得分需要使用资源饱和度权重，则这些服务节点可以将资源饱和度权重设置为一个较小的值(小于服务节点在未执行I/O密集型作业设置的资源饱和度权重的值，也可以直接置零)，从而在资源饱和度权重上传至主节点后，主节点根据该权重计算出的这些服务节点上的NUMA节点的得分将降低。

情况3：

若大数据应用为大内存型应用，例如，基于Java的无堆外内存型分布式数据服务，直接进行NUMA绑定可能出现进程跨NUMA节点运行的情况，导致执行效率降低，另外Java进程在内存超过32G时还可能会由于指针压缩问题导致执行效率降低。此时，可以采用实例拆分的方式处理，即将一个进程拆分成多个功能类似的进程，使得拆分后的每个进程对资源的需求得以降低(例如，对内存的需求不超过32G)，并且拆分后的各进程可以分别进行NUMA绑定，即可以绑定到不同的NUMA节点上运行，对每个进程内部而言不存在跨NUMA节点的问题，也可以解决Java中因指针压缩引起的性能问题，拆分后的各进程之间可以通过跨进程通信进行有限的交互(对性能影响不大)。

主节点可以对大数据应用是否为大内存型应用进行判断，例如，在大数据应用执行前，用户可能会通过客户端提交资源申请请求，其中会对大数据应用需要消耗的资源数量进行说明(如1核CPU，64G内存)，主节点可以将大数据应用对内存资源的需求数量和某个预设阈值(例如，32G)进行比较，若大于该阈值则认为是内存型应用，否则认为不是大内存型应用。

对于大内存型应用，主节点可以输出提示信息，例如，若大数据应用是用户通过客户端提交到Hadoop集群中运行的大数据业务，则主节点输出提示信息的形式可以是向用户使用的客户端返回提示信息。提示信息的内容可以包括将大数据应用拆分成多个实例后再分别进行NUMA绑定的建议。之所以只是向用户提供建议，主要是考虑到：其一，并非所有的大数据应用都可以进行实例拆分；其二，用户处于自身需求也未必愿意进行实例拆分，即拆分决定由用户而不是主节点作出是比较合适的。

情况4：

对于大数据应用为大内存型、且为CPU高负载的情况，此时在NUMA架构下，内存访问的性能已远小于固态硬盘的性能，采用绑定NUMA节点等方式来进行优化意义不大，采用硬件加速的方式进行优化更加合适，硬件加速的一种方式就是在Hadoop集群中的服务节点上安装固态硬盘(例如，采用一块固态硬盘加多块普通硬盘的方式，称为异构存储的Hadoop架构)以分担CPU的压力。

可以理解的，服务节点加装固态硬盘后，产生的优化效果并不仅仅针对大内存型、CPU高负载的大数据应用，对于其他大数据应用的执行效率亦有改善。

图3示出了本申请实施例提供的另一种大数据应用优化方法的流程图。同时图3也可以视为图1中的资源调度平台的部署过程或者对大数据组件的优化过程，左侧一列(步骤S300至步骤S340)为平台部署的步骤，右侧一列(步骤S350至步骤S380)为平台部署过程中大数据组件的初始化步骤。

参照图3，该方法包括：

步骤S300：在集群中部署Hadoop系统。

这里的Hadoop系统可以指原生的Hadoop系统，在部署Hadoop系统的同时也部署系统中的各类大数据组件，但此时大数据组件尚未初始化。

步骤S310：主节点执行优化程序包。

优化程序包可以采用，但不限于软件开发工具包(Software Development Kit，简称SDK)的形式，在部署Hadoop系统的同时也可以将优化程序包部署到主节点上。前文所述的大数据应用优化方法可以实现为一项服务(图3中的分布式资源调度服务，简称资源调度服务)，并集成到该优化程序包中，步骤S300执行完后，主节点运行该优化程序包，便可以启动资源调度服务，提供针对大数据应用的优化功能(以对外提供服务接口的形式)，例如，将对NUMA节点的打分返回给服务接口的调用者，以便调用者执行后续的NUMA绑定步骤。关于资源调度服务的使用，后文还会进一步介绍。

步骤S320：服务节点检测系统NUMA信息。

步骤S330：服务节点获取内存与CPU的绑定关系。

步骤S340：服务节点启动心跳同步服务。

对步骤S320至步骤S340一同进行介绍。优化程序包运行时，可以将步骤S320至步骤S340的内容以脚本的形式下发给集群中的服务节点，从而服务节点执行接收到的脚本，即可实现步骤S320至步骤S340中的操作。

在步骤S320中，服务节点检测系统NUMA信息(指当前服务节点上的)，关于NUMA信息的具体内容，可以参考现有技术或后文表1，此处不作具体阐述。

在步骤S330中，服务节点获取NUMA节点(指当前服务节点上的)中内存与CPU之间的绑定关系(例如，在图1中，CPU0与内存1、内存2绑定)。

在步骤S340中，服务节点启动心跳服务，用于向主节点定期发送心跳信息，心跳信息中可以包括打分用的预设信息，前文已经介绍过心跳服务的功能，不再重复。服务节点在执行步骤S320和步骤S330时获得的信息，可以单独上传给主节点，也可以作为心跳信息的一部分上传给主节点，主节点获取到这些信息后，便可以获知整个集群中的资源分布状况，而后续的NUMA绑定针对的也是这些资源的绑定。可以理解的，若Hadoop集群中的资源未发生变化，这些信息上传一次就可以了，无需重复上传。

进一步的，在一些实现方式中，主节点上可以部署分布式协调服务Zookeeper(或者也可以部署在其他地方，但主节点可以进行访问)，服务节点上传的信息都可以在Zookeeper中保存，Zookeeper的职责是保证数据在其管辖下的所有服务之间保持同步、一致。在主节点上的资源调度服务需要对NUMA节点打分时，可以从Zookeeper中获取打分用到的数据。当然，也有一些其他服务可以利用Zookeeper，包括但不限于图3中的分布式数据库服务。

在一种实现方式中，Zookeeper可以采用将服务节点的id记录至路径(指Zookeeper中的路径)中的方式产生针对不同服务节点的目录，用于存储不同服务节点上传的数据，例如，路径/numainfo/${host}中的${host}即表示某个服务节点的id。在Zookeeper中数据保存于Znode内，例如，数据可以包含表1中的信息：

表1

当然，Zookeeper中不仅可以保存服务节点上传的数据，还可以保存其他数据，例如NUMA节点和大数据应用的绑定关系(在对NUMA节点打分后即可确定)等等。

对于原生Hadoop系统中的大数据组件，并未针对NUMA架构进行任何优化，因此直接初始化大数据组件不能实现优化效果。在本申请提供的方案中，步骤S310中提到的优化程序包在运行时，还会将预设的组件程序包(例如，jar包，其中包含优化逻辑)复制到各大数据组件的目录下，替换掉大数据组件原生的一些用于资源调度的组件程序包，从而，大数据组件在初始化时会执行替换后的组件程序包，这些替换后的组件程序包在运行时会执行步骤S350至步骤S380，以实现对大数据组件的优化。

步骤S350：主节点进行存储服务资源规划。

步骤S360：主节点进行计算服务资源规划。

步骤S350和步骤S360可以统一概括为对大数据组件的资源使用进行规划，大数据组件大致可以分为两类，分别是主要提供存储服务的大数据组件以及主要提供计算服务的大数据组件，针对不同类型的大数据组件，可以在步骤S350和步骤S360中择一执行即可。

步骤S370：主节点计算大数据组件的最高并发和最低并发。

下面举例说明最高并发和最低并发可能的计算方式：常规的大数据应用中，在万兆网络或数据本地化的环境中通常可忽略网络开销。数据通过FSInputStream或FSInputReader的单核性能通常在30MB/s～200MB/s，从而最低并发可以基于硬盘瓶颈进行计算，而最高并发可以基于CPU和内存瓶颈进行计算。需要指出，并非每个大数据组件都需要计算最高并发和最低并发，对于不需要计算这两者的大数据组件，可以略过步骤S370。

步骤S380：主节点调用资源调度服务的服务接口。

根据前文的阐述，资源调度服务的服务接口在被调用时，会为集群中的NUMA节点打分，并将当前初始化的大数据组件绑定到目标NUMA节点上运行(当然，绑定操作的具体执行由服务节点执行，但绑定关系在资源调度服务中就可以确定)，从而实现通过NUMA绑定对大数据组件的优化。

步骤S350至步骤S380的执行，可能会依赖于Zookeeper中的某些数据，在图3中通过连接线体现。

应当指出，资源调度服务并非仅能用于优化Hadoop系统自带的大数据组件，在资源调度平台部署完成后，用户可以通过客户端向平台发送的针对大数据业务的资源申请请求，该请求的含义前文已经阐述过。作为对请求的响应，平台会调用资源调度服务的服务接口，以实现对用户提交的大数据业务的NUMA绑定。

可见，在本申请的方案中，无论是针对用户提交的大数据业务，还是针对Hadoop系统中的大数据组件，其采用的优化逻辑是类似的，只是前者需要用户提出资源申请，而后者对资源的需求可以由Hadoop系统的部署人员或者系统调优人员来指定。

此外，还需要指出，如果用户提交的大数据业务中用到了Hadoop系统中的大数据组件，则该平台不仅对业务本身进行了优化，还对业务中用到的大数据组件进行了优化。

表2给出了采用本申请提供的数据优化方法对Hadoop系统中不同类型的大数据组件的优化效果：

表2

其中，观察NUMA架构下的组件性能与传统架构(如SMP等)下的组件性能对比这一行的内容，可以看出，采用NUMA架构后，组件性能有一定下降。而在优化空间这一行给出了采用本申请实施例提供的大数据应用优化方法后，组件性能可以提升的幅度，最后一行则是可以采用的优化手段，在前文已经介绍。

总之，图3中的大数据优化方法实现了从大数据的部署、数据接入、存储到计算等的一体化优化流程，有效解决了目前大数据应用针对NUMA结构缺少行之有效的优化方案的问题。

图4示出了本申请实施例提供的大数据应用优化装置400的功能模块图。参照图4，大数据应用优化装置400配置于Hadoop集群中的主节点，该装置包括：

打分模块410，用于获取所述Hadoop集群中的至少一个服务节点发送的预设信息，根据所述预设信息对每个服务节点上的非统一内存架构NUMA节点进行打分，其中，得分最高的至少一个NUMA节点为目标NUMA节点；

绑定模块420，用于向所述目标NUMA节点所在的目标服务节点发送绑定信息，所述绑定信息用于指示所述目标服务节点执行所述目标NUMA节点与大数据应用之间的绑定操作，以使所述大数据应用能够在所述目标NUMA节点上执行。

在大数据应用优化装置400的一种实现方式中，所述预设信息包括资源饱和度权重以及资源分配权重，所述主节点还针对每个服务节点计算数据本地化权重，打分模块410根据所述预设信息对每个服务节点上的NUMA节点进行打分，包括：计算每个服务节点上的NUMA节点对应的以上三项权重的乘积，并将所述乘积作为所述NUMA节点的得分；其中，所述资源饱和度权重表征所述服务节点上的网络资源和/或磁盘I/O资源的实际使用状况；所述资源分配权重表征所述NUMA节点上的内存和/或CPU资源的逻辑使用状况；所述数据本地化权重表征所述大数据应用中使用的数据和/或服务与所述服务节点的本地化关系。

在大数据应用优化装置400的一种实现方式中，打分模块410还用于接收Hadoop集群中的服务节点发送的拒绝消息，对于发送所述拒绝消息的服务节点，不对该服务节点上的NUMA节点进行打分；其中，发送所述拒绝消息表明所述服务节点正在执行网络密集型作业。

在大数据应用优化装置400的一种实现方式中，所述服务节点在执行I/O密集型作业时发送的所述资源饱和度权重的值小于所述服务节点未执行I/O密集型作业时发送的所述资源饱和度权重的值。

在大数据应用优化装置400的一种实现方式中，打分模块410还用于若所述大数据应用对内存资源的需求数量大于预设阈值，则输出提示信息，所述提示信息包括将所述大数据应用拆分成多个实例后再分别进行绑定的建议。

在大数据应用优化装置400的一种实现方式中，所述服务节点上安装有用于分担CPU负载的固态硬盘。

本申请实施例提供的大数据应用优化装置400，其实现原理及产生的技术效果在前述方法实施例中已经介绍，为简要描述，装置实施例部分未提及之处，可参考方法施例中相应内容。

图5示出了本申请实施例提供的大数据应用优化装置500的功能模块图。参照图5，大数据应用优化装置500配置于Hadoop集群中的主节点，该装置包括：

资源调度模块510，用于当Hadoop系统在集群中部署完成后，执行部署在所述主节点上的优化程序包，所述优化程序包在运行时启动资源调度服务；其中，所述资源调度服务对外提供服务接口，所述服务接口在被调用时执行本申请实施例提供的大数据优化方法。

在大数据应用优化装置500的一种实现方式中，所述大数据应用为大数据业务，大数据应用优化装置500还包括：请求响应模块，用于响应客户端发送的针对所述大数据业务的资源申请请求，调用所述服务接口。

在大数据应用优化装置500的一种实现方式中，所述大数据应用为所述Hadoop系统中的大数据组件，大数据应用优化装置500还包括：组件初始化模块，用于在所述大数据组件初始化时，调用所述服务接口。

在大数据应用优化装置500的一种实现方式中，所述优化程序包在运行时还将预设的组件程序包复制到所述大数据组件的目录下，组件初始化模块在所述大数据组件初始化时，调用所述服务接口，包括：在所述大数据组件初始化时所述组件程序包被执行，所述组件程序包在运行时执行如下操作：对所述大数据组件的资源使用进行规划；计算所述大数据组件的最高并发和最低并发；调用所述服务接口。

在大数据应用优化装置500的一种实现方式中，所述优化程序包在运行时还将预设的脚本发送至所述服务节点，所述脚本在运行时执行如下操作：获取所述服务节点上的NUMA信息以及内存和CPU的绑定关系，并向所述主节点发送获取到的信息；在所述服务节点上启动心跳同步服务，用于向所述主节点定期发送所述预设信息。

在大数据应用优化装置500的一种实现方式中，所述预设信息保存在Zookeeper中，在所述主节点需要对所述NUMA节点打分时从Zookeeper中获取。

本申请实施例提供的大数据应用优化装置500，其实现原理及产生的技术效果在前述方法实施例中已经介绍，为简要描述，装置实施例部分未提及之处，可参考方法施例中相应内容。

图6示出了本申请实施例提供的电子设备600的一种可能的结构。参照图6，电子设备600包括：处理器610、存储器620以及通信接口630，这些组件通过通信总线640和/或其他形式的连接机构(未示出)互连并相互通讯。

其中，存储器620包括一个或多个(图中仅示出一个)，其可以是，但不限于，随机存取存储器(Random Access Memory，简称RAM)，只读存储器(Read Only Memory，简称ROM)，可编程只读存储器(Programmable Read-Only Memory，简称PROM)，可擦除只读存储器(Erasable Programmable Read-Only Memory，简称EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read-Only Memory，简称EEPROM)等。处理器610以及其他可能的组件可对存储器620进行访问，读和/或写其中的数据。

处理器610包括一个或多个(图中仅示出一个)，其可以是一种集成电路芯片，具有信号的处理能力。上述的处理器610可以是通用处理器，包括中央处理器(CentralProcessing Unit，简称CPU)、微控制单元(Micro Controller Unit，简称MCU)、网络处理器(Network Processor，简称NP)或者其他常规处理器；还可以是专用处理器，包括数字信号处理器(Digital Signal Processor,简称DSP)、专用集成电路(Application SpecificIntegrated Circuits，简称ASIC)、现场可编程门阵列(Field Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

通信接口630包括一个或多个(图中仅示出一个)，可以用于和其他设备进行直接或间接地通信，以便进行数据的交互。通信接口630可以是以太网接口；可以是高速网络接口(如Infiniband网络)；可以是移动通信网络接口，例如3G、4G、5G网络的接口；还是可以是具有数据收发功能的其他类型的接口。

在存储器620中可以存储一个或多个计算机程序指令，处理器610可以读取并运行这些计算机程序指令，以实现本申请实施例提供的大数据应用优化方法以及其他期望的功能。

可以理解，图6所示的结构仅为示意，电子设备600还可以包括比图6中所示更多或者更少的组件，或者具有与图6所示不同的配置。图6中所示的各组件可以采用硬件、软件或其组合实现。于本申请实施例中，电子设备600可以是Hadoop集群中的主节点或服务节点。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被计算机的处理器读取并运行时，执行本申请实施例提供的大数据应用优化方法。例如，计算机可读存储介质可以实现为图6中电子设备600中的存储器620。

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

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

再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (9)

1.一种大数据应用优化方法，其特征在于，应用于Hadoop集群中的主节点，所述方法包括：

获取所述Hadoop集群中的至少一个服务节点发送的预设信息，根据所述预设信息对每个服务节点上的非一致性内存架构NUMA节点进行打分，其中，得分最高的至少一个NUMA节点为目标NUMA节点；

向所述目标NUMA节点所在的目标服务节点发送绑定信息，所述绑定信息用于指示所述目标服务节点执行所述目标NUMA节点与大数据应用之间的绑定操作，以使所述大数据应用能够在所述目标NUMA节点上执行；

所述预设信息包括资源饱和度权重以及资源分配权重，所述主节点还针对每个服务节点计算数据本地化权重，所述根据所述预设信息对每个服务节点上的NUMA节点进行打分，包括：

计算每个服务节点上的NUMA节点对应的以上三项权重的乘积，并将所述乘积作为所述NUMA节点的得分；

其中，所述资源饱和度权重表征所述服务节点上的网络资源和/或磁盘I/O资源的实际使用状况；所述资源分配权重表征所述NUMA节点上的内存和/或CPU资源的逻辑使用状况；所述数据本地化权重表征所述大数据应用中使用的数据和/或服务与所述服务节点的本地化关系；所述逻辑使用状况包括通过所述大数据应用优化方法进行分配的资源，但在服务节点上还存在其他资源分配途径的状况；

所述大数据应用为大内存型应用；所述大内存型应用为内存资源的需求数量大于预设阈值的大数据应用；所述大数据应用的一个进程被拆分成多个进程，拆分后的各进程分别绑定到不同的NUMA节点上运行；以及所述绑定信息还用于指示所述目标服务节点执行所述目标NUMA节点与大数据应用对应的进程之间的绑定操作。

2.根据权利要求1所述的大数据应用优化方法，其特征在于，所述方法还包括：

接收Hadoop集群中的服务节点发送的拒绝消息，对于发送所述拒绝消息的服务节点，不对该服务节点上的NUMA节点进行打分；其中，发送所述拒绝消息表明所述服务节点正在执行网络密集型作业。

3.根据权利要求1所述的大数据应用优化方法，其特征在于，所述服务节点在执行I/O密集型作业时发送的所述资源饱和度权重的值小于所述服务节点未执行I/O密集型作业时发送的所述资源饱和度权重的值。

4.根据权利要求1所述的大数据应用优化方法，其特征在于，所述方法还包括：

若所述大数据应用对内存资源的需求数量大于预设阈值，则输出提示信息，所述提示信息包括将所述大数据应用拆分成多个实例后再分别进行绑定的建议。

5.一种大数据应用优化方法，其特征在于，应用于Hadoop集群中的主节点，所述方法包括：

当Hadoop系统在集群中部署完成后，执行部署在所述主节点上的优化程序包，所述优化程序包在运行时启动资源调度服务；

其中，所述资源调度服务对外提供服务接口，所述服务接口在被调用时执行如权利要求1-4中任一项所述的方法。

6.根据权利要求5所述的大数据应用优化方法，其特征在于，若所述大数据应用为大数据业务，所述方法还包括：

响应客户端发送的针对所述大数据业务的资源申请请求，调用所述服务接口；

若所述大数据应用为所述Hadoop系统中的大数据组件，所述方法还包括：

在所述大数据组件初始化时，调用所述服务接口。

7.一种大数据应用优化装置，其特征在于，配置于Hadoop集群中的主节点，所述装置包括：

打分模块，用于获取所述Hadoop集群中的至少一个服务节点发送的预设信息，根据所述预设信息对每个服务节点上的非统一内存架构NUMA节点进行打分，其中，得分最高的至少一个NUMA节点为目标NUMA节点；所述预设信息包括资源饱和度权重以及资源分配权重，所述主节点还针对每个服务节点计算数据本地化权重，所述根据所述预设信息对每个服务节点上的NUMA节点进行打分，包括：

计算每个服务节点上的NUMA节点对应的以上三项权重的乘积，并将所述乘积作为所述NUMA节点的得分；

其中，所述资源饱和度权重表征所述服务节点上的网络资源和/或磁盘I/O资源的实际使用状况；所述资源分配权重表征所述NUMA节点上的内存和/或CPU资源的逻辑使用状况；所述数据本地化权重表征所述大数据应用中使用的数据和/或服务与所述服务节点的本地化关系；所述逻辑使用状况包括通过所述大数据应用优化装置进行分配的资源，但在服务节点上还存在其他资源分配途径的状况；

绑定模块，用于向所述目标NUMA节点所在的目标服务节点发送绑定信息，所述绑定信息用于指示所述目标服务节点执行所述目标NUMA节点与大数据应用之间的绑定操作，以使所述大数据应用能够在所述目标NUMA节点上执行；所述大数据应用为大内存型应用；所述大内存型应用为内存资源的需求数量大于预设阈值的大数据应用；所述大数据应用的一个进程被拆分成多个进程，拆分后的各进程分别绑定到不同的NUMA节点上运行；以及所述绑定信息还用于指示所述目标服务节点执行所述目标NUMA节点与大数据应用对应的进程之间的绑定操作。

8.一种大数据应用优化装置，其特征在于，配置于Hadoop集群中的主节点，所述装置包括：

资源调度模块，用于当Hadoop系统在集群中部署完成后，执行部署在所述主节点上的优化程序包，所述优化程序包在运行时启动资源调度服务；

其中，所述资源调度服务对外提供服务接口，所述服务接口在被调用时执行如权利要求1-4中任一项所述的方法。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器读取并运行时，执行如权利要求1-6中任一项所述的方法。