一种大数据任务资源利用检测方法及装置
技术领域
本申请涉及大数据平台技术领域,尤其涉及一种大数据任务资源利用检测方法及装置。
背景技术
近年来,随着互联网的普及和Web(网络)技术的飞速发展,全球数据呈现爆炸式增长,使得大数据处理成为一个新的研究热点。Hadoop是由Apache基金会所开发的一个基于MapReduce编程模型的开源框架,在web搜索、数据挖掘以及科学计算等大规模数据处理方面得到广泛的应用。
目前,很多公司都在使用Hadoop进行大规模数据处理。基于Hadoop的大数据平台提供了任务运行的客户端日志记录,包含任务执行进度、任务执行异常信息。但是并没有计算任务本身的资源消耗量、资源浪费量,从而也无法控制大数据平台的资源合理高效使用,会造成很大平台资源成本浪费。
发明内容
为了解决上述技术问题或者至少部分地解决上述技术问题,本申请实施例提供了一种大数据任务资源利用检测方法及装置。
根据本申请实施例的一个方面,提供了一种大数据任务资源利用检测方法,包括:
确定大数据平台的应用作业对应的计算任务及所述计算任务包括的子任务;
获取所述子任务对应的计算资源利用数据;
根据所述计算资源利用数据计算所述计算任务对应的任务资源利用数据和/或所述应用作业对应的作业资源利用数据;
执行所述任务资源利用数据和/或所述作业资源利用数据对应的资源优化操作。
可选的,所述计算资源利用数据包括所述子任务对应的资源申请量、最大资源使用量及运行时间,所述根据所述计算资源利用数据计算所述计算任务对应的任务资源利用数据,包括:
根据所述资源申请量、最大资源使用量及运行时间计算所述子任务对应的资源异常量;
根据所述计算任务下所有子任务的资源异常量得到所述计算任务对应的任务资源异常量。
可选的,所述根据所述计算资源利用数据计算所述应用作业对应的作业资源利用数据,包括:
根据所述资源申请量、最大资源使用量及运行时间计算所述子任务对应的资源异常量;
根据所述计算任务下所有子任务的资源异常量得到所述计算任务对应的任务资源异常量;
根据所述应用作业对应的所有计算任务的任务资源异常量得到所述应用作业对应的作业资源异常量。
可选的,所述执行所述任务资源利用数据和/或所述作业资源利用数据对应的资源优化操作,包括:
当根据所述任务资源利用数据确定所述计算任务满足第一预设条件时,对所述计算任务执行预警操作;
和/或,
当根据所述作业资源利用数据确定所述应用作业满足第二预设条件时,对所述应用作业执行预警操作。
可选的,当根据所述任务资源利用数据确定所述计算任务满足第一预设条件和/或根据所述作业资源利用数据确定所述应用作业满足第二预设条件时,所述执行所述任务资源利用数据和/或所述作业资源利用数据对应的资源优化操作,还包括:
确定所述第一预设条件和/或第二预设条件对应的资源优化参数;
根据所述资源优化参数确定所述大数据平台的资源参数。
可选的,所述确定所述第一预设条件和/或第二预设条件对应的资源优化参数,包括:
确定所述第一预设条件和/或第二预设条件对应的资源优化等级;
获取所述资源优化等级对应的所述资源优化参数。
可选的,所述方法还包括:
获取所述大数据平台的历史资源利用数据;
根据所述历史资源利用数据确定所述子任务对应的目标计算资源量;
根据所述目标计算资源量确定所述资源优化参数。
可选的,所述确定大数据平台的应用作业对应的计算任务及所述计算任务包括的子任务,包括:
采集所述应用作业对应的实时作业数据;
根据所述实时作业数据确定所述应用作业对应的计算任务;
采集所述计算任务对应的实时计算任务数据;
根据所述实时计算任务数据确定所述计算任务包括的子任务。
根据本申请实施例的另一个方面,提供了一种大数据任务资源利用检测装置,包括:
确定模块,用于确定大数据平台的应用作业对应的计算任务及所述计算任务包括的子任务;
获取模块,用于获取所述子任务对应的计算资源利用数据;
计算模块,用于根据所述计算资源利用数据计算所述计算任务对应的任务资源利用数据和/或所述应用作业对应的作业资源利用数据;
执行模块,用于执行所述任务资源利用数据和/或所述作业资源利用数据对应的资源优化操作。
根据本申请实施例的另一方面,还提供了一种存储介质,该存储介质包括存储的程序,程序运行时执行上述的步骤。
根据本申请实施例的另一个方面,提供了一种电子设备,包括:处理器、通信接口、存储器和通信总线,其中,处理器,通信接口,存储器通过通信总线完成相互间的通信;
所述存储器,用于存放计算机程序;
所述处理器,用于执行计算机程序时,实现上述方法步骤。
根据本申请实施例的另一个方面,提供了一种计算机可读存储介质,其上存储有计算机程序,该计算机程序被处理器执行时实现上述方法步骤。
本申请实施例提供的上述技术方案与现有技术相比具有如下优点:
通过对大数据平台上子任务的资源利用数据进行实时采集,基于子任务追溯到其所属的计算任务以及相应的应用作业,准确地分析计算任务及应用作业的资源利用情况,从而可以更加精确地根据各任务、作业的资源利用情况进行资源优化。在保证应用作业正常运行的情况下,使得应用作业使用的资源量最小,节约大数据平台的计算资源,在保证作业运行效率的同时,提高平台上应用作业的资源使用率,避免出现资源浪费或争夺。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本发明的实施例,并与说明书一起用于解释本发明的原理。
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,对于本领域普通技术人员而言,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的一种大数据任务资源利用检测方法的流程图;
图2为本申请另一实施例提供的一种大数据任务资源利用检测方法的流程图;
图3为本申请另一实施例提供的一种大数据任务资源利用检测方法的流程图;
图4为本申请另一实施例提供的一种大数据任务资源利用检测方法的流程图;
图5为本申请另一实施例提供的一种大数据任务资源利用检测方法的流程图;
图6为本申请另一实施例提供的一种大数据任务资源利用检测方法的流程图;
图7为本申请实施例提供的一种大数据任务资源利用检测装置的框图;
图8为本申请实施例提供的一种电子设备的结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请的一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本申请保护的范围。
在大数据平台上,应用作业(prdtask)为一个用户请求的业务作业,如查询该用户一段时间内的历史交易数据;每个应用作业在处理过程中,可能会被拆分为一个或多个计算任务(Job),而每个Job中可以有一个或多个子任务(Task)。
对于Hadoop来说,一个Job即为一个Mapreduce程序,而一个Job里面可以有一个或多个Task,Task又可以区分为Map Task和Reduce Task。
本申请实施例,根据应用作业下每个Task的资源利用情况来分析Job的资源利用情况,进一步得到该应用作业的资源利用情况,从而确定该应用作业是否存在资源浪费或资源不足,以及是否需要对该应用作业进行资源优化。
下面首先对本发明实施例所提供的一种大数据任务资源利用检测方法进行介绍。
图1为本申请实施例提供的一种大数据任务资源利用检测方法的流程图。如图1所示,该方法包括以下步骤:
步骤S11,确定大数据平台的应用作业对应的计算任务及计算任务包括的子任务。
每个prdtask都有其对应的作业ID,基于作业ID可以查询到其对应的JobID。
由JobTracker为应用作业的每个Job生成一个唯一的JobID,JobID包含JobTracker的ID及Job号。JobID的字符串表示为:job_<jobtrackerID>_<jobNumber>。例如,job_200707121733_0003表明这是Jobtracker200707121733的第3号作业。
每个Task的TaskID包含其所属Job的JobID、Map或Reduce任务、Task号。TaskID的字符串表示为:
task_<jobtrackerID>_<jobNumber>_[m|r]_<taskNumber>。例如,task_200707121733_0003_m_000005表示Job200707121733_0003的000005号任务,该任务是一个Map任务。
该步骤中,基于ID之间的关联关系,可以确定prdtask对应Job及Job所包含的Task。
步骤S12,获取子任务对应的计算资源利用数据。
其中,计算资源利用数据可以包括内存利用数据和/或CPU利用数据。实际中,容易出现资源浪费或资源不足的为内存,因此,本实施例中可以基于任务的内存利用数据进行后续分析。
步骤S13,根据计算资源利用数据计算计算任务对应的任务资源利用数据和/或应用作业对应的作业资源利用数据。
该步骤中,Job的任务资源利用数据可以基于其包括的所有Task的计算资源利用数据获得。应用作业的作业资源利用数据可以基于其对应的所有Job的任务资源利用数据得到。
步骤S14,执行任务资源利用数据和/或作业资源利用数据对应的资源优化操作。
当基于任务资源利用数据和/或作业资源利用数据确定存在资源浪费时,可以缩减Task、Job或prdtask对资源的申请量,而存在资源不足时,可以增加Task、Job或prdtask对资源的申请量。
本实施例中,通过对大数据平台上子任务的资源利用数据进行实时采集,基于子任务追溯到其所属的计算任务以及相应的应用作业,准确地分析计算任务及应用作业的资源利用情况,从而可以更加精确地根据各任务、作业的资源利用情况进行资源优化。在保证应用作业正常运行的情况下,使得应用作业使用的资源量最小,节约大数据平台的计算资源,在保证作业运行效率的同时,提高平台上应用作业的资源使用率,避免出现资源浪费或争夺。
图2为本申请另一实施例提供的一种大数据任务资源利用检测方法的流程图。如图2所示,在可选实施例中,上述步骤S11包括:
步骤S21,采集应用作业对应的实时作业数据;
步骤S22,根据实时作业数据确定应用作业对应的计算任务;
步骤S23,采集计算任务对应的实时计算任务数据;
步骤S24,根据实时计算任务数据确定计算任务包括的子任务。
其中,实时作业数据中包括该应用作业prdtask对应的作业ID,基于作业ID可以查询到其对应的所有计算任务Job的JobID,实时计算任务数据包括计算任务Job的JobID以及其下所有子任务Task的TaskID。根据实时计算任务数据可以确定计算任务Job包括的所有Task。
本实施例,在应用作业的运行过程中实时采集数据进行资源计算和优化,在保证应用作业正常运行的情况下,使得应用作业使用的资源量最小,节约大数据平台的计算资源。
在可选实施例中,计算资源利用数据包括子任务对应的资源申请量、最大资源使用量及运行时间。当资源申请量大于最大资源使用量时,存在计算资源浪费,而当资源申请量小于最大资源使用量时,存在计算资源不足,计算资源浪费或不足均可认为是计算资源异常。
图3为本申请另一实施例提供的一种大数据任务资源利用检测方法的流程图。如图3所示,步骤S13包括:
步骤S31,根据资源申请量、最大资源使用量及运行时间计算子任务对应的资源异常量。
步骤S32,根据计算任务下所有子任务的资源异常量得到计算任务对应的任务资源异常量。
步骤S33,根据应用作业对应的所有计算任务的任务资源异常量得到应用作业对应的作业资源异常量。
其中,计算Job的任务资源利用数据包括上述步骤S31和S32;计算应用作业的作业资源异常量包括上述步骤S31至S33。
具体地,计算资源利用数据中的内存利用数据,包括:每个Task的内存申请量及最大内存使用量。
下面以计算内存浪费量为例对步骤S13进行详细说明。
Task的内存申请量Container_size大于最大内存使用量peak_memory_used。
内存申请量Container_size为每个Task申请的Yarn(Yet Another ResourceNegotiator,另一种资源协调器)容器的大小。
最大内存使用量peak_memory_used可以基于每个Task的最大物理内存使用量max_physical_memory及虚拟内存使用量virtual_memory计算得到:
其中,2.1为虚拟内存率yarn.nodemanager.vmem-pmem-ratio的默认值。
每个Task的内存浪费量wasted_resource可通过如下公式计算:
wasted_resource=(Container_size-1.5×peak_memory_used)×runtime,其中,runtime为该Task的运行时间。
Job的任务内存浪费量wasted_resourceJob为其下所有Task资源浪费量的总和:
其中,该Job下有n+1个Task,i=0,1,2……n,wasted_resource
i为该Job下第i个Task的内存浪费量。
应用作业的作业内存浪费量wasted_resourceprdtask为其对应的所有Job资源浪费量的总和:
其中,该应用作业prdtask下有m+1个Job,j=0,1,2……m,wasted_resource
Jobj wasted_resource
j为该应用作业prdtask下第j个Job的任务内存浪费量。
本实施例中,也可能存在资源不足的情况,即资源申请量小于最大资源使用量,此时,可以基于每个Task的资源不足量计算每个Job的任务资源不足量和/或应用作业的作业资源不足量。
上述步骤S13,可以采用Storm(开源的分布式实时大数据处理框架)实现对各个步骤资源异常量的计算。
可选的,步骤S14包括:当根据任务资源利用数据确定计算任务满足第一预设条件时,对计算任务执行预警操作;和/或,当根据作业资源利用数据确定应用作业满足第二预设条件时,对应用作业执行预警操作。
本实施例中,可以采用Siddhi,一个轻量级的,简单的开源的复杂事件流程引擎(Complex Event Processing,CEP)来实现对是否发生资源浪费或不足的判断,实时根据判断结果对Job/应用作业的预警。Siddhi使用类SQL的语言描述事件流任务,可以很好的支撑开发一个可扩展的,可配置的流式任务执行引擎。相关设计之中,为了支持不同的预警规则类型,需要编写不同的业务逻辑代码,但是使用了Siddhi之后,只需要配置不同的流任务Siddhiql,即可以支持不同的规则任务和预警业务。通过业务规则抽象出类SQL事件任务,实现业务流程,并根据业务计算结果触发后续其他事件任务,如外部系统API(预警、通知)调用流程、数据存储、数据消费。
图4为本申请另一实施例提供的一种大数据任务资源利用检测方法的流程图。如图4所示,在可选实施例中,当出现资源异常时,上述步骤S14还包括:
步骤S41,确定第一预设条件和/或第二预设条件对应的资源优化参数;
步骤S42,根据资源优化参数确定大数据平台的资源参数。
可选的,步骤S41中的资源优化参数可以通过大数据平台的历史资源利用数据分析得到,图5为本申请另一实施例提供的一种大数据任务资源利用检测方法的流程图。如图5所示,该方法还包括以下步骤:
步骤S51,获取大数据平台的历史资源利用数据;
步骤S52,根据历史资源利用数据确定子任务对应的目标计算资源量;
步骤S53,根据目标计算资源量确定资源优化参数。
本实施例中,对应用作业进行资源优化所采用的资源优化参数,可以基于离线存储的历史数据确定计算任务和应用作业的历史资源利用数据,进而得到子任务的目标资源计算量,基于历史数据分析出资源优化参数,已实时对任务作业进行资源优化。
可选的,当存在资源浪费或不足时,资源优化参数可以基于预先训练得到的资源优化模型计算得到。该资源优化模型在保证Job/应用作业正常执行情况下,分析其所使用的最小资源量,根据该最小资源量,得到大数据平台的资源优化参数。
其中,该资源优化模型可以基于大数据平台的历史资源利用数据训练得到。历史资源利用数据中包括Job/应用作业的内存使用情况、CPU使用情况、是否执行成功、运行时间等等数据,基于这些数据,可训练得到资源优化算法。
例如,通过资源优化模型,根据内存消耗的分布情况,对浪费内存量过大或申请资源不足的应用作业,按照每次降低500MB内存或增加500MB内存申请量来进行资源优化。
图6为本申请另一实施例提供的一种大数据任务资源利用检测方法的流程图。如图6所示,可选的,步骤S41包括:
步骤S61,确定第一预设条件和/或第二预设条件对应的资源优化等级;
步骤S62,获取资源优化等级对应的资源优化参数。
例如,以MapReduce内存相关参数的设置为例,资源优化等级及对应的资源优化参数如下表1所示,
表1
资源优化参数 |
资源优化等级 |
RM内存参数(容器级内存) |
1 |
AM内存参数(task级内存) |
2 |
AM JVM内存参数 |
3 |
其中,RM表示资源管理器(ResourceManager),AM表示应用控制器(ApplicationMaster),AM JVM表示应用控制器Java虚拟机(ApplicationMasterJavaVirtual Machine)。
下面对各个优化等级的资源优化参数进行详细说明:
(1)RM内存参数包括:
RM1:yarn.scheduler.minimum-allocation-mb,分配给单个容器(Container)可申请的最小内存,即每个Task的最小内存申请量;
RM2:yarn.scheduler.maximum-allocation-mb,分配给单个容器可申请的最大内存,即每个Task的最大内存申请量。
(2)AM内存参数
AM1:mapreduce.map.memory.mb,分配给Map Container的内存大小,即每个MapTask的内存申请量;
AM2:mapreduce.reduce.memory.mb,分配给Reduce Container的内存大小,即每个ReduceTask的内存申请量。
yarn.app.mapreduce.am.resource.mb,MR AppMaster占用的内存量,其中MRAppMaster是MapReduce的ApplicationMaster实现,它使得MapReduce计算框架可以运行于YARN之上。
其中,RM1≤AM1≤RM2,RM1≤AM2≤RM2,且一般AM2为AM1的2倍。
(3)AMJVM内存参数
mapreduce.map.java.opts指示配置Map端的参数;
mapreduce.reduce.java.opts指示配置Reduce端的参数。
mapreduce.map.java.opts和mapreduce.reduce.java.opts均为启动JVM虚拟机时,传递给虚拟机的启动参数。与内存有关的是-Xmx,-Xms等选项,表示JVM程序(java、scala等)可以使用的最大内存数,一旦超过这个大小,JVM就会抛出Out of Memory异常,并终止进程。
本实施例中,资源优化模型自动实时获取每次MapReduce运行时的内存参数,以及应用作业的资源利用情况,并推荐出该应用作业历史运行过程中资源消耗最小情况下的内存参数值和推荐的调整参数和调整资源量。
下述为本申请装置实施例,可以用于执行本申请方法实施例。
图7为本申请实施例提供的一种大数据任务资源利用检测装置的框图,该装置可以通过软件、硬件或者两者的结合实现成为电子设备的部分或者全部。如图7所示,该大数据任务资源利用检测装置包括:
确定模块71,用于确定大数据平台的应用作业对应的计算任务及计算任务包括的子任务;
获取模块72,用于获取子任务对应的计算资源利用数据;
计算模块73,用于根据计算资源利用数据计算计算任务对应的任务资源利用数据和/或应用作业对应的作业资源利用数据;
执行模块74,用于执行任务资源利用数据和/或作业资源利用数据对应的资源优化操作。
本申请实施例中,针对基于Hadoop构建的大数据平台,通过Kafka进行实时数据的采集,通过Hive进行离线历史数据的存储。
其中,Kafka是一种高吞吐量的分布式发布订阅消息系统,它可以处理消费者在大数据平台上的所有动作流数据。Hive是基于Hadoop的一个数据仓库工具,用来进行数据提取、转化、加载,是一种可以存储、查询和分析存储在Hadoop中的大规模数据的机制。
将存储于Hive中的离线历史数据同步到关系型数据库MySQL,Kafka从MySQL加载该离线历史数据及实时数据到资源使用预警引擎。该资源使用预警引擎通过Eagle(开源的分布式实时安全监控方案)进行任务作业的资源使用监控。通过Storm计算资源使用的异常情况,Storm可根据资源利用异常情况出发预警操作或资源优化操作。Storm根据预先训练的资源优化模型计算在该异常情况下的资源优化参数,使用该优化参数对计算任务或应用作业的资源参数进行优化。
本申请实施例还提供一种电子设备,如图8所示,电子设备可以包括:处理器1501、通信接口1502、存储器1503和通信总线1504,其中,处理器1501,通信接口1502,存储器1503通过通信总线1504完成相互间的通信。
存储器1503,用于存放计算机程序;
处理器1501,用于执行存储器1503上所存放的计算机程序时,实现以下上述方法实施例的步骤。
上述电子设备提到的通信总线可以是外设部件互连标准(PeripheralComponentInterconnect,P C I)总线或扩展工业标准结构(Extended IndustryStandardArchitecture,EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示,图中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
通信接口用于上述电子设备与其他设备之间的通信。
存储器可以包括随机存取存储器(Random Access Memory,RAM),也可以包括非易失性存储器(Non-Volatile Memory,NVM),例如至少一个磁盘存储器。可选的,存储器还可以是至少一个位于远离前述处理器的存储装置。
上述的处理器可以是通用处理器,包括中央处理器(Central Processing Unit,CPU)、网络处理器(Network Processor,NP)等;还可以是数字信号处理器(DigitalSignalProcessing,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
本申请还提供一种计算机可读存储介质,其上存储有计算机程序,该计算机程序被处理器执行时实现以下上述方法实施例的步骤。
需要说明的是,对于上述装置、电子设备及计算机可读存储介质实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
进一步需要说明的是,在本文中,诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上所述仅是本发明的具体实施方式,使本领域技术人员能够理解或实现本发明。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的,本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下,在其它实施例中实现。因此,本发明将不会被限制于本文所示的这些实施例,而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。