CN107493205B - 一种设备集群扩容性能预测方法及装置 - Google Patents
一种设备集群扩容性能预测方法及装置 Download PDFInfo
- Publication number
- CN107493205B CN107493205B CN201710572207.XA CN201710572207A CN107493205B CN 107493205 B CN107493205 B CN 107493205B CN 201710572207 A CN201710572207 A CN 201710572207A CN 107493205 B CN107493205 B CN 107493205B
- Authority
- CN
- China
- Prior art keywords
- different
- stage
- cluster
- equipment
- tasks
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/50—Testing arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Environmental & Geological Engineering (AREA)
- Debugging And Monitoring (AREA)
Abstract
一种设备集群扩容性能预测方法及装置,用于提高预测设备集群扩容性能的精准度。包括:预测设备获取预测参考信息集,预测参考信息集为预先对第一设备集群中包括的至少一个设备处理数据的过程进行测试得到的,预测参考信息集包括一个设备处理数据不同阶段中,每个阶段的不同轮分别包含不同任务数量时所对应需要的运行资源参数;预测设备基于所述预测参考信息集,预测第二设备集群中每个设备处理数据过程中执行不同阶段分别被分配到的任务时所需消耗的实际资源参数;预测设备基于所述每个设备的实际资源参数,预测第二设备集群处理数据所需消耗的资源情况;其中,第二设备集群为基于第一设备集群进行扩容得到的虚拟仿真集群。
Description
技术领域
本申请涉及计算机领域,尤其涉及一种设备集群扩容性能预测方法及装置。
背景技术
随着科学技术和互联网的发展,现代社会的信息量迅速增长,这些信息积累着大规模的数据,这些数据中将会有部分数据存储在云平台中或借助云平台进行处理。借助海杜普Hadoop,用户在不了解分布式底层细节的情况下,通过编写分布式并行程序,并将其运行在由多个设备组成的设备集群上,以高效地存储、管理和分析这些存储在云平台中的数据。
Hadoop是一个能够对大量数据进行分布式处理的软件框架,其最底部是分布式文件系统(Hadoop Distributed File System,HDFS),通过采用分布式存储方式来进行海量数据存储,以提高数据的读写速率,并扩大存储容量,HDFS的上一层是映射简化(MapReduce)引擎,是通过Map和Reduce两个步骤对HDFS中国的海量数据进行并行处理,以保证分析和处理数据的高效性。正是由于Hadoop突出的优势,Hadoop在许多领域中被广泛应用,但是在应用的过程中,一些问题也随之产生,例如,为方便客户做投资决策,降低投资风险误差,或为方便地对计算机集群的相关参数进行优化,在对小规模的设备集群进行扩容得到大规模的设备集群之前,需要对待搭建的大规模设备集群的性能指标进行预测。
而目前,一般基于算法和架构原型验证对设备集群的扩容性能进行预测,仅能实现功能仿真或定性预测扩容性能趋势,无法做到定量预测。所以,现有技术中对设备集群的扩容性能的预测的精准度较低。
发明内容
本申请实施例提供一种设备集群的扩容性能预测方法,用于提高预测设备集群的扩容性能的精准度。
第一方面,本申请实施例提供了一种设备集群的扩容性能预测方法。在该方法包括:预测设备获取预测参考信息集,所述预测参考信息集为预先对第一设备集群中包括的至少一个设备处理数据的过程进行测试得到的,所述预测参考信息集包括一个设备处理数据不同阶段中,每个阶段的不同轮分别包含不同任务数量时所对应需要的运行资源参数;所述预测设备基于所述预测参考信息集,预测第二设备集群中每个设备处理数据过程中执行所述不同阶段分别被分配到的任务时所需消耗的实际资源参数;所述预测设备基于所述每个设备的实际资源参数,预测所述第二设备集群处理数据所需消耗的资源情况;其中,所述第二设备集群为基于所述第一设备集群进行扩容得到的虚拟仿真集群。
本申请实施例中,首先获取第一设备集群中一个设备在处理数据的不同阶段中,每个阶段的不同轮分别包含不同任务数量时所需要的运行资源参数,然后基于获取的运行资源参数来预测第二设备集群中每个设备处理数据过程中执行不同阶段分别被分配到的任务时所需消耗的实际资源参数,实现对第二设备集群的性能的定量预测,从而提高预测第二设备集群的性能的精准度。
在一个可能的设计中,所述不同阶段包括:设备执行数据映射操作的第一阶段;设备执行数据洗牌操作和合并操作的第二阶段;设备执行数据化简操作的第三阶段。
在本申请实施例中,不同阶段的划分可能有不同的形式,且以上几种只是举例,在本申请实施例中对不同阶段中具体包括哪几个阶段不作限制。
在一个可能的设计中,所述不同轮包括:设备在所述不同阶段被分配的任务的任务数量大于所述设备在所述不同阶段能够处理的任务的最大任务数量时,所述设备按照时间顺序处理所述任务时得到的各轮。
在本申请实施例中,在不同阶段被分配的任务数量大于设备在不同阶段能够处理的最大任务数量时,设备将被分配的任务按照多轮执行,从而测试得到第一设备集群中的设备在不同阶段的不同轮包含不同任务数量时的执行时长,细化了测试粒度,进而能够更精确的预测第二设备集群包括的每个设备的性能指标。
相应的,在本申请实施例中,在不同阶段被分配的任务数量小于不同阶段能够处理的最大任务数量时,则一轮就能够执行完,该轮可以被称为尾轮。
在一个可能的设计中,所述预测设备基于所述预测参考信息集,预测第二设备集群中每个设备在处理数据过程中执行不同阶段分别被分配到的任务时所需消耗的实际资源参数,包括:所述预测设备基于所述每个阶段的不同轮分别包含不同任务数量时所对应需要的执行时长,调用不同的触发事件;其中,所述不同的触发事件用于触发所述每个设备在所述不同阶段之间跳转;所述预测设备基于所述不同的触发事件,运行所述每个设备在所述不同阶段对应的仿真程序,预测所述每个设备在处理数据过程中执行不同阶段的不同轮分别被分配到的任务时所需的执行时长。
在本申请实施例中,通过对第一设备集群中包括的设备进行基准测试,可以对第二设备集群的设备在不同阶段的不同轮的执行时长进行真实黑盒刻画;通过不同阶段的划分,可以对第二设备集群设备间事件驱动流程进行白盒刻画,然后通过事件驱动和时间推进机制将二者结合并推广到整个第二设备集群分布式调度执行情况,所以能够较为真实地刻画出第二设备集群各阶段的执行时长。
在一个可能的设计中,所述预测设备基于所述每个阶段包含不同任务数量时所对应需要的执行时长,调用不同的触发事件,包括:所述预测设备基于所述第二设备集群的配置参数,获取所述每个设备在所述第一阶段能够处理的任务的第一最大任务数量及在所述第三阶段能够处理的任务的第二最大任务数量,以及所述每个设备在所述第一阶段能够处理的任务的第一最大任务数量的第一任务数量总和及所述每个设备在所述第三阶段能够处理的任务的第二最大任务数量的第二任务数量总和;所述预测设备从所述每个阶段包含不同任务数量时所对应需要的执行时长中,确定出与所述第一最大任务数量和所述第二最大任务数量对应的所述第一阶段的不同轮的执行时长和所述第三阶段的不同轮的执行时长,以及确定出与所述第一任务数量总和和所述第二最大任务数量总和对应的所述第二阶段的不同轮的执行时长;所述预测设备根据所述第一阶段的不同轮的执行时长、所述第二阶段的不同轮的执行时长,以及所述第三阶段的不同轮的执行时长,调用所述不同的触发事件。
在本申请实施例中,在调用触发事件时,对于不同阶段调用的原则不相同,例如,在第一阶段和第三阶段,基于每个设备在所述第一阶段能够处理的任务的第一最大任务数量及在所述第三阶段能够处理的任务的第二最大任务数量进行调度;在第二阶段,基于每个设备在所述第一阶段能够处理的任务的第一最大任务数量的第一任务数量总和及每个设备在第三阶段能够处理的任务的第二最大任务数量的第二任务数量总和。细化了调度粒度,能够更精确的预测出第二设备集群中每个设备在不同阶段的执行时长。
在一个可能的设计中,所述资源参数包括硬件资源利用率。
在本申请实施例中,资源参数还可以包括硬件资源利用率,例如CPU利用率、内存利用率、磁盘读速率,或是磁盘写速率等,在本申请实施例中不作限制。
第二方面,本申请实施例提供一种设备集群扩容性能预测装置。该装置包括获取模块、第一预测模块和第二预测模块。获取模块、第一预测模块和第二预测模块可执行上述第一方面或第一方面的任意一种可能的设计所提供的方法中的相应功能。
第三方面,本申请实施例提供一种设备集群扩容性能预测装置。该装置包括:存储器,存储有计算机程序和预测参考信息集。处理器,与存储器耦合。其中存储器所存储的计算机程序代码包括指令,当处理器执行所述指令时,所述指令使装置执行上述第一方面或第一方面的任意一种可能的设计中所提供的方法。
第四方面,本申请实施例还提供一种计算机可读存储介质,存储有为执行上述第一方面、第一方面的任意一种设计的功能所用的计算机软件指令,其包含用于执行上述第一方面、第一方面的任意一种设计的方法所设计的程序。
本申请实施例中提供的设备集群的扩容性能预测方法,首先获取第一设备集群中一个设备在处理数据的不同阶段中,每个阶段的不同轮分别包含不同任务数量时所需要的运行资源参数,然后基于获取的运行资源参数来预测第二设备集群中每个设备处理数据过程中执行不同阶段分别被分配到的任务时所需消耗的实际资源参数,实现对第二设备集群的性能的定量预测,从而提高预测第二设备集群的性能的精准度。
附图说明
图1为本申请实施例提供的一种应用架构的示意图;
图2为本申请实施例提供的一种设备集群的扩容性能预测方法的流程图;
图3为本申请实施例提供的一种设备集群的扩容性能预测方法中对设备A进行基准测试的示意图;
图4A-图4D为本申请实施例提供的对设备A进行基准测试的测试用例;
图5为本申请实施例提供的对设备A进行基准测试过程中生成的日志进行分析的示意图;
图6为本申请实施例提供的一种设备集群的扩容性能预测方法的完整示意图;
图7为本申请实施例提供的第二设备集群的仿真模型的示意图;
图8为本申请实施例提供的MapReduce的模型的状态与触发事件之间的对应关系示意图;
图9为本申请实施例提供的一种设备集群的扩容性能预测装置的结构示意图;
图10为本申请实施例提供的另一种设备集群的扩容性能预测装置的结构示意图。
具体实施方式
为了使本申请实施例的目的、技术方案和优点更加清楚,下面将结合附图对本申请实施例作进一步地详细描述。
请参见图1,为本申请实施例的一种应用架构。图1中包括终端设备及服务器机架集群,下面分别介绍。
终端设备可以是笔记本、台式计算机、或者服务器等。
服务器机架集群包括多个机架,及与多个机架中每个机架配套的网络设备。每个机架包括多个服务器及架顶式交换机,每个机架中的多个服务器之间通过网线连接,连接至架顶式交换机。其中,服务器机架集群包括的每个服务器均安装有中央处理器(CentralProcessing Unit,CPU)、内存、网卡及本地存储器等通用基础器件。服务器机架集群包括的每个服务器运行有大数据平台计算引擎,例如Hadoop,或者是spak。在本申请实施例中,则是以Hadoop为例,其中,Hadoop的版本可以是Hadoop1.0版本,也可以是Hadoop2.0版本。下面以Hadoop的版本是Hadoop2.0版本为例,介绍Hadoop的硬件结构,包括:
(1)名称节点(Namenode,NN),用于对整个HDFS进行总控制。名称节点运行在服务器机架集群包括的服务器中的一个服务器上。
(2)辅助名称节点(Secondary Namenode,SecondaryNN),用于控制HDFS状态的辅助后台程序,可以保存名称节点的副本。辅助名称节点运行在服务器机架集群包括的服务器中的一个服务器上。
(3)数据节点(Datanode,DN),用于将HDFS数据块读、写到本地文件系统。数据节点运行在服务器机架集群中除运行有NN、SecondaryNN服务器外的其它每个服务器上。
在具体实现过程中,可以基于Hadoop中的MapReduce运行,也可以基于Hadoop中的Hive运行。下面则以MapReduce为例,介绍Hadoop2.0版本中MapReduce的架构,包括:客户端(Client)、Hadoop中心资源管理器(Resource Manager,RM)、Hadoop HDFS中心管理节点(Node Manager,NM),其中:
(1)、Client,每一个Job都会在用户端通过Client类将应用程序以及配置参数打包成Java归档文件(Java Archive File,JAR)存储在HDFS,并把存储路径提交到RM所在的服务器上。
(2)、RM,用于统一管理和分配服务器机架集群中所有资源,RM接收NM发送的汇报。其中,RM可以与NN位于同一服务器上,也可以与NN位于不同服务器上。
(3)、NM,用于管理资源容器(Container),Container上封装了每个服务器上的一定量的资源。所以,NM用于监控每个Container的资源使用情况,例如,CPU、内存、磁盘、或是网络,并将监控的结果汇报给RM。其中,NM运行在DN所在的服务器上。
下面以一个服务器为例,基于Mapreduce的架构介绍Mapreduce的内部逻辑,Mapreduce的运行过程包括:
Map阶段:HDFS是以固定大小的块(block)为基本单位存储数据,MapReduce处理数据是以片(Split)为单位,一个Split可以对应一个block,也可以对应多个block,在本申请实施例中,以一个Split对应一个block为例。在Client向RM提交一个Job,在HDFS中对应存储4个block,则对应有4个Split,分别为Split0、Split1、Split2和Split3,然后通过InputFormat函数来读取每个Split中的数据,把数据解析成(键、值)((key,value)),发送给Mapper函数进行处理。每个Mapper将输入(key,value)数据解析成对应的单词和词汇,例如第一个Mapper输出(a,1)、(b,1);第二个Mapper输出(c,1)、(c,1);第三个Mapper输出(a,1)、(c,1)等,进一步对每个Mapper输出的数据进行合并、分区。
Shuffle+Merge阶段:将每个Mapper输出的数据中值相同的数据复制到同一个Reducer中。
Reduce阶段:对获取的数据进行化简,例如一个Reducer读取两个(c,1)键值对数据,然后进行统计得出结果(c,2)。
Hadoop因高可靠性、高扩展性、高效性等突出优势得到广泛应用,但是在得广泛应用的同时,也存在一些问题,例如为方便客户做投资决策,降低投资风险误差,或为方便地对计算机集群的相关参数进行优化,在对小设备集群进行扩容得到大设备集群之前,需要对待搭建的大设备集群的性能指标进行预测。
在具体实现过程中,待搭建大设备集群往往包括数百甚至上千个服务器,导致难以找到一个可供预测的大设备集群。而目前,对待搭建的大设备集群的性能预测,主要有以下三种途径:途径1、依靠专家经验进行灰盒人工估计;途径2、搭建全量真实环境;途径3、单一的仿真或机器学习。虽然上述三种途径都能够在一定程度上对大设备集群的性能进行预测,但也都存在一些缺陷,例如途径1的自动化程度较低,针对不同的应用的可复制性较差;途径2对于概念验证(Proof of Concept,POC)局点、公有云租借场景,在实验室搭建全量真实环境,往往难以满足项目的预测需求;途径3是实现功能仿真,机器学习仅能解决相同规模集群的性能回归预测或定性预测扩容趋势。
鉴于此,本申请实施例提供一种设备集群扩容性能预测方法,在该设备集群扩容性能预测方法中,首先获取第一设备集群中一个设备在处理数据的不同阶段中,每个阶段的不同轮分别包含不同任务数量时所需要的运行资源参数,然后基于获取的运行资源参数来预测第二设备集群中每个设备处理数据过程中执行不同阶段分别被分配到的任务时所需消耗的实际资源参数,实现对第二设备集群的性能的定量预测,从而能够提高预测第二设备集群的性能的精准度。
请参见图2,本申请实施例提供一种设备集群扩容性能预测方法,该方法的流程描述大致如下:
S201:预测设备获取预测参考信息集,所述预测参考信息集为预先对第一设备集群中包括的至少一个设备处理数据的过程进行测试得到的,所述预测参考信息集包括一个设备处理数据不同阶段中,每个阶段的不同轮分别包含不同任务数量时所对应需要的运行资源参数。
具体的,在需要对第二设备集群进行性能预测时,首先要构建第一设备集群,第一设备集群为真实搭建的集群,第二设备集群就是基于第一设备集群扩容得到的虚拟仿真集群。在本申请实施例中,组成第一设备集群的每个设备相同,组成第一设备集群的设备与组成第二设备集群的设备的配置参数相同,其中,配置参数指的是软件配置,例如操作系统版本、Hadoop版本、Hadoop配置参数等。
在本申请实施例中,预测设备的实现方式包括但不限于以下两种方式,下面分别介绍。
作为一个示例,预测设备为图1所示的终端设备。在该示例中,预测设备获取预测参考信息集的实现方式,可以是从第一设备集群获取第一设备集群中包括的至少一个设备处理数据的过程中生成的日志,然后基于获取的日志分析得到,也可以直接从第一设备集群获得,也就是说预测参考信息集是由第一设备集群基于第一设备集群中包括的至少一个设备处理数据的过程中生成的日志分析得到的。
作为另一个示例,预测设备包括图1中所示的终端设备以及后台服务器机架集群,后台服务器机架集群为真实搭建的集群。在该示例中,由终端设备从第一设备集群获取第一设备集群中包括的至少一个设备处理数据的过程中生成的日志,终端设备将获取的日志转发给台服务器机架集群,由后台服务器机架集群对日志进行分析得到预测参考信息集。
在本申请实施例中,资源参数包括但不限于:执行时长和硬件资源利用率,其中,硬件资源利用率包括:CPU利用率、内存利用率、磁盘读速率、磁盘写速率或者是网络吞吐率等。
下面以资源参数是执行时长,预测设备是图1所述的终端设备为例,介绍预测设备获取第一设备集群中的一个设备处理任务时不同阶段中,每个阶段包括不同任务量时所需消耗的执行时长的过程。
在具体实现过程中,若要获取执行时长的信息集,则需要事先对第一设备集群进行基准性能测试。在本申请实施例中,由于第一设备集群中除运行NN、SecondaryNN的设备外,其它每个设备均相同,所以,获取其它每个设备中任意一个设备在处理数据过程中在不同阶段中,每个阶段的不同轮分别包括不同任务数量时所需消耗的执行时长即可,在下面介绍中,将任意一个设备称为A。
在本申请实施例中,基于上述对MapReduce的运行过程的介绍可知,对设备A的测试包括三个阶段,分别为:执行映射操作的第一阶段,指的就是Map阶段;执行洗牌操作和合并操作的第二阶段,指的就是Shuffle+Merge阶段;执行化简操作的第三阶段,指的就是Redcue阶段。
在本申请实施例中,不同阶段中的每个阶段还包括不同的子阶段,例如第一阶段包括:max Container Capability子阶段、Got allocated containers子阶段及fromSCHEDULED to RUNNING子阶段、jvm.xxxx.xxxx.m.xxxxxxxx giving task子阶段、Numcompleted Tasks子阶段;第二阶段包括:Got allocated containers子阶段、shuffle@子阶段、EventFetcher子阶段及skiprecords子阶段;第三阶段包括:from SCHEDULED toRUNNING子阶段、jvm.xxxx.xxxx.m.xxxxxxx given task子阶段、done acknowledgement子阶段、Num completed Task子阶段及Moved tmp to done子阶段。虽然每个阶段中包括不同的子阶段,但是在本申请实施例的介绍过程中,仍以上述第一阶段、第二阶段及第三阶段为主。
在本申请实施例中,设备A在不同阶段中每个阶段被分配的任务数大于设备A能够处理的任务的最大任务数量时,设备A则需要按照时间顺序处理被分配的任务,也就是分为多轮处理被分配的任务,因此,在本申请实施例中,请参见图3,对设备A进行的基准测试包括三部分,分别为首轮测试、中间轮测试及尾轮测试下面分别介绍。
第一阶段:以设备A能够并发执行的map数是n=25为例,当Client向RM提交的一个作业为4480M,HDFS存储的块单位为64M时,4480M的数据则以70个块分别存储在HDFS上,70个块对应70个Split,70个Split也就对应70个map,70个map任务大于设备A能够并发执行的map数,这种情况下,则要通过多轮处理设备A被分配的任务。由此设备A处理完在Map阶段被分配的70个map任务,则需要执行2.8轮,也就是需要执行三轮,分别为首轮、中间轮及尾轮。相应的,在首轮执行25个map任务,在中间轮执行25个map任务,在尾轮执行20个map任务。在具体实现过程中,当设备A被分配的map任务数为70个时,在尾轮测试中,需要执行的map任务为20个;当设备A被分配的map任务数为65个时,在尾轮测试中,需要执行的map任务为15个;当设备A被分配的map任务数为60个时,在尾轮测试中,需要执行的map任务为10个;当设备A被分配的map任务数为55个时,在尾轮测试中,需要执行的map任务数为5个;当设备A被分配的map任务数为51个时,在尾轮测试中,需要执行的map任务数为1个。在本申请实施例中,针对多种情况对设备A进行测试,得到设备A在第一阶段包括不同任务数量时的执行时长,设备A在第一阶段的测试用例请参见图4A。
第二阶段:在该阶段中,由于是利用线程读取从第一设备集群包括的所有设备在Map阶段输出的任务。以第一设备集群中包括4个设备,4个设备中的每个设备能够并发执行map数是40,每个线程能够读取的任务数为70为例,在这种情况下,要读取完160个任务,则需要执行2.65轮,也就是需要执行三轮,分别为首轮、中间轮及尾轮。相应的,就是在首轮中读取70个map任务、在中间轮中读取70个map任务、在尾轮中读取20个map任务,由于在首轮和中间轮测试中,一次读取的任务数超出设备A能够并行执行的map数,所以,对应首轮和中间轮的测试用例,请参考图4B。在尾轮中,获取map任务少于设备A能够并行执行的map数,所以,对应尾轮的测试用例,请参考图4C。
第三阶段:以设备A能够并发执行的reduce数k=4,设备A在第三阶段被分配的reduce任务数是11,大于设备A能够并发执行的reduce数,在这种情况下,则要通过多轮处理设备A在第三阶段被分配的任务。由此设备A处理完被分配的10个reduce任务,则需要执行2.75轮,也就是需要执行三轮,分别是首轮、中间轮及尾轮。相应的,在首轮执行4个reduce任务,在中间轮执行4个reduce任务,在尾轮执行3个reduce任务。在具体实现过程中,当设备A被分配的reduce任务为11个时,在尾轮测试中,执行的reduce任务为3个;当设备A被分配的reduce任务为10个时,在尾轮测试中,执行的reduce任务为2个;当设备A被分配的reduce任务为9个时,在尾轮测试中,执行的reduce任务为1个。在本申请实施例中,针对多种情况对设备A进行测试,得到设备A在第三阶段包括不同任务数量时的执行时长,设备A在第三阶段的测试用例请参见图4D。
在本申请实施例中,通过设置图4A-图4D的基准测试用例,并在第一设备机群上运行基准测试用例,能够准确测试得到第二设备集群中一个设备处理被分配作业时,执行不同阶段中,每个阶段的不同轮包括不同任务数量时的执行参数,进而能够准确预测第二设备机群在处理被分配作业时,每个设备的性能指标。
具体实现过程中,通过上述图4A-图4D的测试用例在对设备A进行测试,设备A在不同阶段中,每个阶段的不同轮生成的日志被存储在HDFS上。若要对测试过程中生成的日志进行分析,则需要将日志拷贝到操作系统,例如Linux本地。下面介绍根据测试过程中生成的日志获取预测参考执行时长的过程,请参见图5,包括如下步骤:
获取对第一设备集群中的设备进行基准性能测试过程中生成的日志;
从日志中提取包括预设关键字的日志内容,生成样本数据;
对样本数据进行拟合,得到预测参考执行时长。
在本申请实施例中,能够获取不同预设关键字出现在日志中的时间,而两个关键字出现的时间相减即可得到该两个关键字之间的时间段,从而也就能够得到设备A在执行被分配的任务时在各阶段的执行时长。下面分别对第一阶段、第二阶段、第三阶段的预设关键字进行介绍。
第一阶段的测试生成的日志中包括的预设关键字:容器最大容量(max ContainerCapability)、Got allocated containers、from SCHEDULED to RUNNING、jvm.xxxx.xxxx.m.xxxxxxx given task、Num completed Task,其中,预设关键字Gotallocated containers出现在日志的时间点-预设关键字Num completed Task出现在日志的时间点即为设备A在第一阶段执行单个map任务的执行时长。
第二阶段的测试生成的日志中包括的预设关键字:Got allocated containers、shuffle@、EventFetcher、skiprecords,其中,预设关键字Got allocated containers出现在日志的时间点-预设关键字EventFetcher出现在日志的时间点为设备A在执行单个reduce任务的shuffle阶段的执行时长,预设关键字EventFetcher出现在日志的时间点-预设关键字skiprecords出现在日志的时间点为设备A执行单个reduce任务的Merge阶段的执行时长。
第三阶段的尾轮测试生成的日志中包括的预设关键字:from SCHEDULED toRUNNING、jvm.xxxx.xxxx.m.xxxxxxx given task、skiprecords、done acknowledgement、Num completed Task、Moved tmp to done;在第三阶段的首轮和中间轮测试生成的日志中包括的预设关键字包括:Elapsed Time shuffle、Elapsed Time merge、Elapsed Timereduce、Elapsed Time,其中,预设关键字skiprecords出现在日志的时间-预设关键字Moved tmp to done出现在日志的时间为单个reduce的reduce计算时间。
在按关键字提取日志内容后,对提取的日志内容进行统计分析,将得到的不同阶段中,每一阶段的不同轮的执行时长。将不同阶段中,每一阶段的不同轮的执行时长填入到图4A-图4D中对应的位置处,进而得到不同阶段的关于执行时长的二维表格,然后对每一张二维表格进行拟合,并存储为timei=fi(map-num,red-num)。
在本申请实施例中,为了预测第二设备集群中每个设备处理数据过程中执行不同阶段分别被分配到的任务时所需消耗的实际资源参数,除了对第一设备集群包括的设备进行基准性能测试,还要对第一设备集群的网络延时进行测试,以对第二设备群集的仿真模型的网络延时进行修正。
在具体实现方式中,可以通过多种方式获得第一设备集群的网络延时,在本申请实施例中给出一种测试方式。以10T数据作为输入数据,分别测试并发执行reduce数为450、1000、2000、3000和4500下,在第二阶段执行单个reduce任务的平均执行时长。具体的,在测试结束后从作业日志记录服务jobhistory中统计出各个reduce任务在第二阶段的执行时长,从而得到单个reduce任务在第二阶段的平均执行时长。将设备A在并发执行reduce数为450时,第二阶段执行单个reduce任务的平均执行时长作为基准值,将设备A在并发执行reduce数为1000,第二阶段执行单个reduce任务的平均执行时长与基准值相减,得到第一差值,将设备A在并发执行reduce数为2000,第二阶段执行单个reduce任务的平均执行时长与基准值相减,得到第二差值,将设备A在并发执行reduce数为3000,第二阶段执行单个reduce任务的平均执行时长与基准值相减,得到第三差值,将设备A在并发执行reduce数为4500,第二阶段执行单个任务的平均执行时长与基准值相减,得到第四差值,将获取的四个差值中最接最大的一个值作为第一设备集群的网络时延,用于对第二设备集群的仿真模型的网络时延进行修正。
S202:所述预测设备基于所述预测参考信息集,预测第二设备集群中每个设备处理数据过程中执行所述不同阶段分别被分配到的任务时所需消耗的实际资源参数。
请参见图6,为本申请实施例提供的一种预测设备集群的扩容性能的整体流程示意图,图6中包括:
第一设备集群的测试装置,用于对第一设备集群中的设备A进行基准测试以及对第一设备集群进行网络性能测试;
大数据分析装置,用于从对设备A进行基准测试及对第一设备集群进行网络性能测试过程中生成的日志中提取包括预设关键字日志内容,生成样本数据,以及对样本数据进行分析,输出性能特征库;
第二设备集群预测装置,包括第二设备集群的性能预测模型,请参见图7,该性能预测模型包括三部分,下面分别介绍。
第一部分:数据流时序,也就是上述部分所介绍的第一设备集群包括的设备A在处理数据过程中,执行不同阶段中,每个阶段的不同轮包括不同任务量时所需消耗的执行时长,在此不再赘述。
第二部分:工作流模型,包括基础工作流层和应用工作流层。其中,基础工作流程包括HDFS模型、网络磁盘等通用硬件模型及调度管理节点模型;应用工作流层MapReduce模型、HiveHBase模型以及调度管理节点的源码封装模型等。
在具体实现过程中,每个模型包括的不同的状态和事件,这里的“状态”指的是对象在生命周期中的一个状态,处于某个特定状态中的对象必然会满足某些条件、执行某些动作或者等待某些事件,这里的“事件”指的是在时间和空间上占有一定位置,事件通常会引起状态的变迁,促使模型从一种状态转换到另一种状态。在本申请实施例中,每个模型所对应的状态也就是每个模型的不同阶段,例如MapReduce的第一阶段、第二阶段及第三阶段。
在本申请实施例中,以MapReduce模型为例,介绍MapReduce的包括的状态和事件。具体的,MapReduce的运行过程中包括第一阶段、第二阶段和第三阶段,分别对应三个状态,S1、S2和S3,3个状态之间的变迁又需要触发事件触发,从S1变迁到S2对应的触发事件为E1,从S2变迁到S3对应的触发事件为E2,从S3变迁到S1的触发事件为E3,用于触发状态变迁的事件按照一定顺序组成事件队列,等待事件调度器的调用,具体请参考图8。
在具体实现过程中,仿真系统中的模型在某一状态所针对的是模型的阶段,需要处理大量数据,需要花费较长时间,因此需要考虑模型在某一状态下的时长,也就是仿真模型中的第一部分的内容,而事件发生针对的是非大量数据的处理,例如信令、控制等,因此在模型中不考虑事件的时长。
第三部分:离散事件仿真(Discrete event similation,DES),即通过调用第二部分中的不同的触发事件,触发仿真模型中不同模型的状态的改变。
在本申请实施例中,通过对第一设备集群的基准测试对第二设备集群包括的每个设备的内部性能进行真实黑盒刻画,通过有限状态机模型对第二设备集群的事件驱动流程进行精确的白盒刻画,而离散事件仿真引擎通过事件驱动和时间推进机制将黑盒刻画和白盒刻画结合并推广到整个第二设备集群分布式调度执行的情况,能够较为真实的刻画出第二设备集群整体各阶段的执行时长的性能指标。
下面对上述仿真模型的具体运行原理进行介绍。
在本申请实施例中,要对第二设备集群的性能进行预测,则需要获取第二设备集群的配置参数,包括第二设备集群需要处理的数据量,第二设备集群中每个设备的并发执行map数和并发执行reduce数、map总数及reduce总数。其中,map总数和reduce总数为根据第二设备集群需要处理的数据量得到的,例如第二设备集群需要处理的数据量为0.5TB,HDFS以块存储,块的大小为64M。因此,0.5TB数据将以8192块分别存储在HDFS上,8192个块则分别对应8192个Split,8192个Split对应着8192个map任务。
在对第二设备集群的性能预测过程中,首先根据第二设备的配置参数,也就是第二设备集群中每个设备并发执行map数、并发执行reduce数,确定第一阶段和第三阶段的每一轮的执行时长,根据每个设备并发执行map数、并发执行reduce数、map总数及reduce总数,确定第二阶段的每一轮的执行时长,然后根据不同阶段中,每一阶段的不同轮的执行时长调用触发事件。
下面以第二设备集群中每个设备并发执行map数是25、并发执行reduce数是10、map总数是1000、reduce总数是100为例,介绍调用触发事件的具体过程。
在第一阶段,可以默认运行于第一阶段对应的仿真程序。
在第二阶段,根据并发执行map数、并发执行reduce数,从图4A所示的表中确定与并发执行map数、并发执行reduce数对应的第一阶段的尾轮的执行时长,在第一阶段的尾轮执行完时,调用E1触发事件,触发第二设备集群中的设备从第一状态变迁到第二状态,也就是触发设备从第一阶段变迁到第二阶段,执行与第二阶段对应的仿真程序,具体的,在第二设备集群中的设备在第二阶段中执行完第一轮时,会停留在第二状态,继续执行第二轮,直至到尾轮结束,等待触发事件的发生。
在第三阶段,根据并发执行map数、并发执行reduce数、map总数、reduce总数,从图4B及图4C所示的表中,确定第二阶段的每一轮的执行时长。在第二阶段的尾轮结束时,调用E2触发事件,用于触发第二设备集群中的设备从第二状态变迁到第三状态,也就是触发设备从第二阶段变迁到第三阶段,执行与第三阶段对应的仿真程序,具体的,第二设备机群中的设备在第三阶段中执行完第一轮时,会停留在第三状态,继续执行第二轮,直至尾轮结束。
在本申请实施例中,通过记录不同阶段中,每个阶段的不同轮的仿真时长,便可得到第二设备集群中每个设备在执行被分配任务时,在每个阶段的不同轮的执行时长,根据每个设备在每个阶段的不同轮的执行时长获得,第一阶段中,在首轮中并发执行map任务的总执行时长;第二阶段中,首轮执行单个任务的平均执行时长和方差,在中间轮执行单个任务的平均执行时长和方差,在尾轮执行单个任务的平均执行时长和方差;第三阶段中,首轮执行单个任务的平均执行时长和方差,在中间轮执行单个任务的平均执行时长和方差,在尾轮执行单个任务的平均执行时长和方差。
S203:所述预测设备基于所述每个设备的实际资源参数,预测所述第二设备集群处理数据所需消耗的资源情况;
在预测获得第二设备集群中每个设备的实际资源参数,便能够得到第二设备集群处理数据所需消耗的资源情况。
本申请实施例中提供的设备集群的扩容性能预测方法,首先获取第一设备集群中一个设备在处理数据的不同阶段中,每个阶段的不同轮分别包含不同任务数量时所需要的运行资源参数,然后基于获取的运行资源参数来预测第二设备集群中每个设备处理数据过程中执行不同阶段分别被分配到的任务时所需消耗的实际资源参数,实现对第二设备集群的性能的定量预测,从而能够提高预测第二设备集群的性能的精准度。
请参见图9,本申请实施例提供一种设备集群的扩容性能预测装置,该设备集群的扩容性能预测装置包括连接到同一总线900的处理器901、存储器902。
其中,处理器901可以是中央处理器,或特定应用集成电路(ApplicationSpecific Integrated Circuit,ASIC),可以是一个或多个用于控制程序执行的集成电路,可以是基带芯片,等等。
存储器902的数量可以是一个或多个,存储器可以是只读存储器(Read onlyMemory,ROM)、随机存储存储器(Random Access Memory,RAM)或磁盘存储器,等等。
通过对处理器901进行设计编程,将前述的设备集群的扩容性能预测方法所对应的代码固化到芯片内,从而使芯片在运行时能够执行前述图2所示的实施例提供的设备集群的扩容性能预测方法,如何对处理器901进行设计编程为本领域技术人员公知的技术,这里不再赘述。
请参见图10,本申请实施例提供一种设备集群的扩容性能预测装置,该设备集群的扩容性能预测装置包括获取模块1001、第一预测模块1002、及第二预测模块1003。
在实际应用中,获取模块1001、第一预测模块1002、第二预测模块1003对应的实体装置可以集成在图9中的处理器901中。
本申请实施例中的设备集群的扩容性能预测装置可以用于执行上述图2所示的实施例提供的方法,对于该设备集群的扩容性能预测装置中的各模块所实现的功能等,可参考如前方法部分的描述,在此不多赘述。
本申请实施例还提供了一种计算机可读存储介质,用于存储为执行上述处理器所需执行的计算机软件指令,其包含用于执行上述处理器所需执行的程序。
在上述申请实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时,全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如,DVD)、或者半导体介质(例如,固态硬盘Solid State Disk(SSD))等。
显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。
Claims (15)
1.一种设备集群扩容性能预测方法,其特征在于,包括:
预测设备获取预测参考信息集,所述预测参考信息集为预先对第一设备集群中包括的至少一个设备处理数据的测试过程中生成的日志分析得到的,所述预测参考信息集包括一个设备处理数据不同阶段中,每个阶段的不同轮分别包含不同任务数量时所对应需要的运行资源参数;
所述预测设备基于所述预测参考信息集,预测第二设备集群中每个设备处理数据过程中执行所述不同阶段分别被分配到的任务时所需消耗的实际资源参数;
所述预测设备基于所述每个设备的实际资源参数,预测所述第二设备集群处理数据所需消耗的资源情况;
其中,所述第二设备集群为基于所述第一设备集群进行扩容得到的虚拟仿真集群。
2.根据权利要求1所述的方法,其特征在于,所述不同阶段包括:
设备执行数据映射操作的第一阶段;
设备执行数据洗牌操作和合并操作的第二阶段;
设备执行数据化简操作的第三阶段。
3.根据权利要求1所述的方法,其特征在于,所述不同轮包括:
设备在所述不同阶段被分配的任务的任务数量大于所述设备在所述不同阶段能够处理的任务的最大任务数量时,所述设备按照时间顺序处理所述任务时得到的各轮。
4.根据权利要求2或3所述的方法,其特征在于,所述资源参数包括执行时长;
所述预测设备基于所述预测参考信息集,预测第二设备集群中每个设备在处理数据过程中执行不同阶段分别被分配到的任务时所需消耗的实际资源参数,包括:
所述预测设备基于所述每个阶段的不同轮分别包含不同任务数量时所对应需要的执行时长,调用不同的触发事件;其中,所述不同的触发事件用于触发所述每个设备在所述不同阶段之间跳转;
所述预测设备基于所述不同的触发事件,运行所述每个设备在所述不同阶段对应的仿真程序,预测所述每个设备在处理数据过程中执行不同阶段的不同轮分别被分配到的任务时所需的执行时长。
5.根据权利要求4所述的方法,其特征在于,所述预测设备基于所述每个阶段包含不同任务数量时所对应需要的执行时长,调用不同的触发事件,包括:
所述预测设备基于所述第二设备集群的配置参数,获取所述每个设备在第一阶段能够处理的任务的第一最大任务数量及在第三阶段能够处理的任务的第二最大任务数量,以及所述每个设备在所述第一阶段能够处理的任务的第一最大任务数量的第一任务数量总和及所述每个设备在所述第三阶段能够处理的任务的第二最大任务数量的第二任务数量总和;所述第一阶段为设备执行数据映射操作的阶段,所述第三阶段为设备执行数据化简操作的阶段;
所述预测设备从所述每个阶段包含不同任务数量时所对应需要的执行时长中,确定出与所述第一最大任务数量和所述第二最大任务数量对应的所述第一阶段的不同轮的执行时长和所述第三阶段的不同轮的执行时长,以及确定出与所述第一任务数量总和和所述第二最大任务数量总和对应的第二阶段的不同轮的执行时长;所述第二阶段为设备执行数据洗牌操作和合并操作的阶段;
所述预测设备根据所述第一阶段的不同轮的执行时长、所述第二阶段的不同轮的执行时长,以及所述第三阶段的不同轮的执行时长,调用所述不同的触发事件。
6.根据权利要求1或2或3或5所述的方法,其特征在于,所述资源参数包括硬件资源利用率。
7.根据权利要求4所述的方法,其特征在于,所述资源参数包括硬件资源利用率。
8.一种设备集群扩容性能预测装置,其特征在于,包括存储器和处理器,其中:
所述存储器,存储有计算机程序和预测参考信息集,所述预测参考信息集为预先对第一设备集群中包括的至少一个设备处理数据的测试过程中生成的日志分析得到的,所述预测参考信息集包括一个设备处理数据不同阶段中,每个阶段的不同轮分别包含不同任务数量时所对应需要的运行资源参数;
所述处理器,用于调用存储器中存储的计算机程序和所述预测参考信息集,执行:基于所述预测参考信息集,预测第二设备集群中每个设备处理数据过程中执行所述不同阶段分别被分配到的任务时所需消耗的实际资源参数;以及基于所述每个设备的实际资源参数,预测所述第二设备集群处理数据所需消耗的资源情况;
其中,所述第二设备集群为基于所述第一设备集群进行扩容得到的虚拟仿真集群。
9.根据权利要求8所述的装置,其特征在于,所述不同阶段包括:
设备执行数据映射操作的第一阶段;
设备执行数据洗牌操作和合并操作的第二阶段;
设备执行数据化简操作的第三阶段。
10.根据权利要求8所述的装置,其特征在于,所述不同轮包括:
设备在所述不同阶段被分配的任务的任务数量大于所述设备在所述不同阶段能够处理的任务的最大任务数量时,所述设备按照时间顺序处理所述任务时得到的各轮。
11.根据权利要求9或10所述的装置,其特征在于,所述资源参数包括执行时长;
在所述处理器基于所述预测参考信息集,预测第二设备集群中每个设备在处理数据过程中执行不同阶段分别被分配到的任务时所需消耗的实际资源参数时,具体用于:
基于所述每个阶段的不同轮分别包含不同任务数量时所对应需要的执行时长,调用不同的触发事件;其中,所述不同的触发事件用于触发所述每个设备在所述不同阶段之间跳转;
基于所述不同的触发事件,运行所述每个设备在所述不同阶段对应的仿真程序,预测所述每个设备在处理数据过程中执行不同阶段的不同轮分别被分配到的任务时所需的执行时长。
12.根据权利要求11所述的装置,其特征在于,在所述处理器基于所述每个阶段包含不同任务数量时所对应需要的执行时长,调用不同的触发事件时,具体用于:
基于所述第二设备集群的配置参数,获取所述每个设备在第一阶段能够处理的任务的第一最大任务数量及在第三阶段能够处理的任务的第二最大任务数量,以及所述每个设备在所述第一阶段能够处理的任务的第一最大任务数量的第一任务数量总和及所述每个设备在所述第三阶段能够处理的任务的第二最大任务数量的第二任务数量总和;所述第一阶段为设备执行数据映射操作的阶段,所述第三阶段为设备执行数据化简操作的阶段
从所述每个阶段包含不同任务数量时所对应需要的执行时长中,确定出与所述第一最大任务数量和所述第二最大任务数量对应的所述第一阶段的不同轮的执行时长和所述第三阶段的不同轮的执行时长,以及确定出与所述第一任务数量总和和所述第二最大任务数量总和对应的第二阶段的不同轮的执行时长;所述第二阶段为设备执行数据洗牌操作和合并操作的阶段;
根据所述第一阶段的不同轮的执行时长、所述第二阶段的不同轮的执行时长,以及所述第三阶段的不同轮的执行时长,调用所述不同的触发事件。
13.根据权利要求8或9或10或12所述的装置,其特征在于,所述资源参数包括硬件资源利用率。
14.根据权利要求11所述的装置,其特征在于,所述资源参数包括硬件资源利用率。
15.一种计算机存储介质,其特征在于,所述计算机存储介质中存储有计算机程序,当所述计算机程序在计算机上运行时,使得所述计算机执行如权利要求1-7任一权利要求所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710572207.XA CN107493205B (zh) | 2017-07-13 | 2017-07-13 | 一种设备集群扩容性能预测方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710572207.XA CN107493205B (zh) | 2017-07-13 | 2017-07-13 | 一种设备集群扩容性能预测方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN107493205A CN107493205A (zh) | 2017-12-19 |
CN107493205B true CN107493205B (zh) | 2020-08-14 |
Family
ID=60643524
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201710572207.XA Active CN107493205B (zh) | 2017-07-13 | 2017-07-13 | 一种设备集群扩容性能预测方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN107493205B (zh) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109039691B (zh) * | 2018-06-01 | 2021-05-18 | 平安科技(深圳)有限公司 | 服务器、预测系统调用量的方法及存储介质 |
CN110825526B (zh) * | 2019-11-08 | 2020-10-30 | 欧冶云商股份有限公司 | 基于er关系的分布式调度方法及装置、设备以及存储介质 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103713935A (zh) * | 2013-12-04 | 2014-04-09 | 中国科学院深圳先进技术研究院 | 一种在线管理Hadoop集群资源的方法和装置 |
CN104270416A (zh) * | 2014-09-12 | 2015-01-07 | 杭州华为数字技术有限公司 | 负载均衡控制方法及管理节点 |
CN104536829A (zh) * | 2014-12-30 | 2015-04-22 | 深圳先进技术研究院 | 一种云计算系统中虚拟机的性能预测方法及系统 |
CN105095230A (zh) * | 2014-04-29 | 2015-11-25 | 国际商业机器公司 | 确定目标数据分析应用的性能预测模型的方法及装置 |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10079830B2 (en) * | 2014-04-17 | 2018-09-18 | Viavi Solutions Inc. | Lockable network testing device |
US10721161B2 (en) * | 2015-08-28 | 2020-07-21 | Vmware, Inc. | Data center WAN aggregation to optimize hybrid cloud connectivity |
-
2017
- 2017-07-13 CN CN201710572207.XA patent/CN107493205B/zh active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103713935A (zh) * | 2013-12-04 | 2014-04-09 | 中国科学院深圳先进技术研究院 | 一种在线管理Hadoop集群资源的方法和装置 |
CN105095230A (zh) * | 2014-04-29 | 2015-11-25 | 国际商业机器公司 | 确定目标数据分析应用的性能预测模型的方法及装置 |
CN104270416A (zh) * | 2014-09-12 | 2015-01-07 | 杭州华为数字技术有限公司 | 负载均衡控制方法及管理节点 |
CN104536829A (zh) * | 2014-12-30 | 2015-04-22 | 深圳先进技术研究院 | 一种云计算系统中虚拟机的性能预测方法及系统 |
Also Published As
Publication number | Publication date |
---|---|
CN107493205A (zh) | 2017-12-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20210342193A1 (en) | Multi-cluster container orchestration | |
JP2022008497A (ja) | 出現した関係におけるスタックセグメント強度の相関 | |
US20210279241A1 (en) | Splitting a time-range query into multiple sub-queries for serial execution | |
CN107562532B (zh) | 一种预测设备集群的硬件资源利用率的方法及装置 | |
US11100420B2 (en) | Input processing for machine learning | |
US9679029B2 (en) | Optimizing storage cloud environments through adaptive statistical modeling | |
US11016971B2 (en) | Splitting a time-range query into multiple sub-queries for parallel execution | |
US20150379425A1 (en) | Consistent filtering of machine learning data | |
CN111176818B (zh) | 分布式预测的方法、装置、系统、电子设备及存储介质 | |
US9501313B2 (en) | Resource management and allocation using history information stored in application's commit signature log | |
Han et al. | Refining microservices placement employing workload profiling over multiple kubernetes clusters | |
Clemente-Castelló et al. | Performance model of mapreduce iterative applications for hybrid cloud bursting | |
US9853866B2 (en) | Efficient parallel processing of a network with conflict constraints between nodes | |
JP2012530976A (ja) | 仮想化超並列プログラマブルハードウェアによる正規表現の検索 | |
Kroß et al. | Model-based performance evaluation of batch and stream applications for big data | |
CN107493205B (zh) | 一种设备集群扩容性能预测方法及装置 | |
US10565202B2 (en) | Data write/import performance in a database through distributed memory | |
US20160283522A1 (en) | Matching untagged data sources to untagged data analysis applications | |
Sewal et al. | A machine learning approach for predicting execution statistics of spark application | |
US20240143414A1 (en) | Load testing and performance benchmarking for large language models using a cloud computing platform | |
US11243764B1 (en) | Code deployment | |
WO2024139538A1 (zh) | 脚本生成方法、装置、计算设备、系统及可读存储介质 | |
US11243832B2 (en) | Dynamically analyzing diagnostic operations data via machine learning techniques | |
WO2024125251A1 (zh) | 资源分配的方法及装置 | |
Alipour et al. | Model driven performance simulation of cloud provisioned Hadoop MapReduce applications |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |