本申请涉及数据处理
技术领域:
:,具体而言,涉及一种任务监测方法、装置、电子设备和可读存储介质。
背景技术:
::在大数据时代,数据处理量越来越大,在执行处理任务以进行例如数据统计、分析等过程中,需要确定处理任务在执行之后,是否成功获得执行结果数据并保存。为了解决这个问题,目前行业内常用的方式是通过sql语句来查询数据库表,以确定数据库表中是否存放有处理任务的执行结果数据,从而确定处理任务是否成功被执行。实际应用场景中,由于数据处理量大、处理任务众多,针对每个处理任务均有对应的数据库表,导致在数量众多的处理任务的情况下,若均需要从数据库中去读取数据库表,再根据数据库表有无数据以判定处理任务是否成功执行,将存在查询速度缓慢、耗时较长的问题。技术实现要素:本申请的目的包括,例如,提供了一种任务监测方法、装置、电子设备和可读存储介质,其能够避免从数据库中读取数据,从而提高监测查询的速度。本申请的实施例可以这样实现:第一方面,实施例提供一种任务监测方法,所述方法包括:获取针对待监测任务的监测请求;根据所述监测请求获得待查询数据表的表信息,所述待查询数据表用于存放所述待监测任务的执行结果数据;获得预先生成的所述待查询数据表的表信息对应的文件目录;获取所述文件目录中包含的文件大小,并根据所述文件大小判断所述待监测任务是否成功执行。在可选的实施方式中,所述方法还包括:根据所述文件目录的最新修改时间,确定所述待监测任务的执行结束时间。在可选的实施方式中,所述获取针对待监测任务的监测请求的步骤之前,所述方法还包括:针对每个执行任务,为所述执行任务创建对应的数据表以用于存放所述执行任务的执行结果数据;获取所述数据表的表名称;基于所述表名称生成所述数据表的文件目录;将所述文件目录存入结果文件中。在可选的实施方式中,所述获得预先生成的所述待查询数据表的表信息对应的文件目录的步骤,包括:根据所述待查询数据表的表名称,从所述结果文件中查找到所述待查询数据表对应的文件目录。在可选的实施方式中,所述根据所述待查询数据表的表名称,从所述结果文件中查找到所述待查询数据表对应的文件目录的步骤,包括:获取所述待监测任务的执行日期;从所述结果文件中筛选出包含的表名称与所述待查询数据表的表名称一致的文件目录;从筛选出的文件目录中查找到包含的日期信息与所述执行日期一致的文件目录。在可选的实施方式中,所述根据所述文件目录的最新修改时间,确定所述待监测任务的执行结束时间的步骤,包括:获取所述文件目录中包含的日期信息;确定所述文件目录在所述日期信息内的最新一次的修改时间点,将所述日期信息以及所述修改时间点作为所述待监测任务的执行结束时间。在可选的实施方式中,所述根据所述文件目录中包含的文件大小,判断所述待监测任务是否成功执行的步骤,包括:检测所述文件目录中包含的文件大小是否大于0,若所述文件大小大于0,则确定所述待查询数据表中存放有所述待监测任务的执行结果数据,并判定所述待监测任务成功执行;若所述文件大小等于0,则确定所述待查询数据表中未存放所述待监测任务的执行结果数据,并判定所述待监测任务执行失败。在可选的实施方式中,所述方法还包括:将所述文件目录中包含的文件大小以及所述待监测任务的执行结束时间存入监测文件;将所述监测文件中的信息备份至监测数据表中。第二方面,实施例提供一种任务监测装置,所述装置包括:请求获取模块,用于获取针对待监测任务的监测请求;信息获取模块,用于根据所述监测请求获得待查询数据表的表信息,所述待查询数据表用于存放所述待监测任务的执行结果数据;目录获得模块,用于获得预先生成的所述待查询数据表的表信息对应的文件目录;判断模块,用于获取所述文件目录中包含的文件大小,并根据所述文件大小判断所述待监测任务是否成功执行。第三方面,实施例提供一种电子设备,包括:存储器,用于存储计算机程序;与所述存储器连接的处理器,用于执行所述计算机程序,以实现前述实施方式任意一项所述的任务监测方法。第四方面,实施例提供一种计算机可读存储介质,其上存储有计算机程序,该程序被执行时实现前述实施方式任意一项所述的任务监测方法。本申请实施例的有益效果包括,例如:本申请实施例提供的任务监测方法、装置、电子设备和可读存储介质,在获取针对待监测任务的监测请求后,根据监测请求获得待查询数据表的表信息,该待查询数据表用于存放待监测任务的执行结果数据。进而获得预先生成的待查询数据表的表信息对应的文件目录,并获取文件目录中包含的文件大小。从而根据该文件大小判断待监测任务是否成功执行。该方案采用直接读取待查询数据表的文件目录,根据文件目录的文件大小判断数据表中数据的有无,进而判定待监测任务的执行情况。避免了从数据库中读取数据表以判断数据的有无所存在的数据库执行耗时长的缺陷,提高了监测查询的速度。附图说明为了更清楚地说明本申请实施例的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,应当理解,以下附图仅示出了本申请的某些实施例,因此不应被看作是对范围的限定,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他相关的附图。图1为本申请实施例提供的电子设备的示意性结构框图;图2为本申请实施例提供的任务监测方法的流程示意图;图3为本申请实施例提供的任务监测方法包含的判断待监测任务是否成功执行的具体方法的流程示意图;图4为本申请实施例提供的任务监测方法包含的生成文件目录的方法的流程示意图;图5为本申请实施例提供的任务监测方法包含的文件目录获取方法的流程示意图;图6为本申请实施例提供的任务监测方法包含的执行结束时间确定方法的流程示意图;图7为本申请实施例提供的任务监测装置的功能模块框图。图标:10-电子设备;100-处理器;200-存储器;300-任务监测装置;310-请求获取模块;320-信息获取模块;330-目录获得模块;340-判断模块;350-时间确定模块。具体实施方式结构化查询语言(structuredquerylanguage,sql)是一种特殊目的的编程语言,是一种数据库查询和程序设计语言,用于存取数据以及查询、更新和管理数据库系统。hive是基于hadoop的一个数据仓库工具,可以将结构化的数据文件映射为一张数据库表,并提供简单的sql查询功能,可以将sql语句转换为mapreduce任务进行运行。其优点是学习成本低,可以通过类sql语句快速实现简单的mapreduce统计,不必开发专门的mapreduce应用,十分适合数据仓库的报表统计分析。而hadoop是一款支持数据密集型分布式应用程序并以apache2.0许可协议发布的开源软件框架,整个apachehadoop“平台”包括hadoop内核、mapreduce、hadoop分布式文件系统(hdfs)以及一些相关项目。在大数据时代,数据量巨大,基于hive进行离线数据开发的方案越来越广泛地被业内所使用。在数据处理的过程中,数据何时处理完成,以及处理结束之后是否能正常产生结果数据的问题是用户所关注的。为了解决用户所关注的问题,目前通常的实现方案是通过sql查询来实现获取数据处理完成时间和是否产生结果数据的判断。具体地,目前常用的方式包括两种,一种是通过监控处理数据的任务是否执行完成,若执行完成则记录任务完成的时间作为数据处理完成的时间,再通过sql查询数据库表,以检测数据库表中是否具有数据,从而确定数据处理的任务是否正常产生结果数据。另一种是通过在处理任务中把完成时间戳和处理产生的数据一起写入至数据库表中,直接通过sql去查询数据库表中是否存在结果数据,以及完成时间戳,从而确定数据处理任务的执行完成时间以及是否正常产生结果数据。目前所采用的上述两种方式,均需要从数据库中进行数据库表查询的方式以判断数据的有无进而确定处理任务是否成功被执行,数据库查询的方式耗时长,导致监测查询速度慢。基于上述研究发现,本申请提供一种任务监测方法,在针对待监测任务时,可获得用于存放待监测任务的执行结果数据的待查询数据表的表信息,进而获得预先生成的该待查询数据表对应的文件目录。并且,获得该文件目录中包含的文件大小,进而根据文件大小判断待监测任务是否成功执行。该方案无需从数据库中进行数据查询,仅需根据数据表的文件目录的信息,通过文件目录信息判断数据表中的数据情况,进而判断待监测任务的执行情况。避免从数据库中进行数据查询存在的耗时长的问题。为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此,以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围,而是仅仅表示本申请的选定实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。需要说明的是,在不冲突的情况下,本申请的实施例中的特征可以相互结合。如图1所示,本申请实施例提供了一种电子设备10,可以包括存储器200和处理器100,该存储器200内可以设置有机器可执行指令,该机器可执行指令包括任务监测装置300。其中,所述存储器200和处理器100之间直接或间接地电性连接,以实现数据的传输或交互。例如,相互之间可通过一条或多条通讯总线或信号线实现电性连接。所述任务监测装置300包括至少一个可以软件或固件(firmware)的形式存储于所述存储器200中的软件功能模块。所述处理器100用于执行所述存储器200中存储的可执行的计算机程序,例如,所述任务监测装置300所包括的软件功能模块及计算机程序等,以实现本申请实施例提供的任务监测方法。可选地,所述存储器200可以是,但不限于,随机存取存储器(randomaccessmemory,ram),只读存储器(readonlymemory,rom),可编程只读存储器(programmableread-onlymemory,prom),可擦除只读存储器(erasableprogrammableread-onlymemory,eprom),电可擦除只读存储器(electricerasableprogrammableread-onlymemory,eeprom)等。所述处理器100可以是一种通用处理器,包括中央处理器(centralprocessingunit,cpu)、网络处理器(networkprocessor,np)、片上系统(systemonchip,soc)等;还可以是数字信号处理器(dsp)、专用集成电路(asic)、现场可编程门阵列(fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以理解,图1所示的结构仅为示意,所述电子设备10还可包括比图1中所示更多或者更少的组件,或者具有与图1所示不同的配置,例如,还可以包括用于与其它设备进行信息交互的通信单元。其中,所述电子设备10的具体类型不受限制,可以根据实际应用需求进行选择,只要具有一定的数据处理能力即可,例如,在一种可以替代的示例中,所述电子设备10包括电脑、个人计算机、服务器等。结合图2,本申请实施例还提供一种可应用于上述电子设备10的任务监测方法。其中,该任务监测方法有关的流程所定义的方法步骤可以由所述电子设备10实现。下面将对图2所示的具体流程进行详细阐述。步骤s210,获取针对待监测任务的监测请求。步骤s220,根据所述监测请求获得待查询数据表的表信息,所述待查询数据表用于存放所述待监测任务的执行结果数据。步骤s230,获得预先生成的所述待查询数据表的表信息对应的文件目录。步骤s240,获取所述文件目录中包含的文件大小,并根据所述文件大小判断所述待监测任务是否成功执行。在大数据时代,常常涉及到对大量数据的统计、分析处理的任务,例如,对于网络交易数据进行大数据分析,以获知用户购物习惯等特征、对于网络直播数据进行大数据分析,以获知用户直播爱好等特征。这些处理任务需要基于运营产生的数据,再通过一定的统计、分析等策略处理后,最终将得到的结果数据写入至数据表中,以供查看或后续使用。一般是采用写入至数据库表的方式进行保存,例如关系型数据库表,以便于后续的数据查询、维护等工作。本实施例中所涉及到的任务可以是,如网络交易场景下的,统计每天某类客户的交易数据、统计每天某项业务的交易数据,或者是网络直播场景下的,统计每天观众用户的情况、统计每天直播类型情况等。当然,所涉及到的任务还可以是其他的相关任务类型,具体地可以根据实际的需求情况进行设置,在此不作限制。本实施例中,待监测任务可以是一个或多个等不限,在实际情况下,往往是存在多个执行任务并行执行,待监测的任务也往往是多个。故而,如何提高监测、查询的速度显得尤为重要。待监测任务的执行结果数据将存入数据库表中,即待查询数据表。例如,在待监测任务为统计某天某类客户的交易数据时,则该待监测任务的执行结果数据应当是该天内该类客户的交易商品的商品信息、交易量、交易时间等等数据。这些数据将存入数据库中为该待监测任务所创建的数据库表中。需要说明的是,本实施例中,并不关注于待监测任务对应的待查询数据表中存储的数据的具体信息,而只关注于该待查询数据表中是否存放有待监测任务的执行结果数据。本实施例中,预先生成有数据表对应的文件目录,文件目录为一种计算机系统中建立的文件的索引,即文件名和文件物理位置之间的映射关系。而本实施例中的文件目录包含有文件大小,该文件大小由数据表中存入的数据量决定。基于上述监测策略,本实施例中,将绕过进入数据库进行数据表查询的方式以检测数据库表中数据的有无,而是通过获取待查询数据表的表信息对应的文件目录,进而根据该文件目录中的文件大小来判断待查询数据表中的数据的有无,进而判断待监测任务是否成功执行。如此,由于无需进入数据库查询,因此,可避免数据库查询耗时长、速度慢等缺陷,提高监测、查询的速度。由上述可知,本实施例中是通过判断待查询数据表中是否存入待监测任务的执行结果数据,进而判断待监测任务是否成功执行。而待查询数据表对应的文件目录中包含的文件大小,即为待查询数据表的大小。请参阅图3,在根据该文件大小判断待监测任务是否成功执行时,可通过以下方式实现:步骤s241,检测所述文件目录中包含的文件大小是否大于0,若所述文件大小大于0,则执行以下步骤s242,若所述文件大小等于0,则执行以下步骤s243。步骤s242,确定所述待查询数据表中存放有所述待监测任务的执行结果数据,并判定所述待监测任务成功执行。步骤s243,确定所述待查询数据表中未存放所述待监测任务的执行结果数据,并判定所述待监测任务执行失败。本实施例中,在待查询数据表中存有待监测任务的执行结果数据时,则该待查询数据表的表大小应当大于0,反之,若未存入待监测任务的执行结果数据,则该待查询数据表的表大小应当等于0。因此,只需获得文件目录中的文件大小,并监测文件大小是否等于0,即可判定待查询数据表中是否有执行结果数据,进而判断待监测任务是否执行成功。本实施例中,文件目录为数据表创建时所生成,并且,在数据表中的数据有所更新时,文件目录中的相关信息将随之发生相应更改。请参阅图4,以下将对文件目录的产生过程进行介绍:步骤s110,针对每个执行任务,为所述执行任务创建对应的数据表以用于存放所述执行任务的执行结果数据。步骤s120,获取所述数据表的表名称。步骤s130,基于所述表名称生成所述数据表的文件目录。步骤s140,将所述文件目录存入结果文件中。本实施例中,在任务执行时,或者任务执行之前,则相应地为该任务确定用于存放执行结果数据的数据表。根据用户需要监控的数据表的表清单,即用户需要监控的执行任务,获取到其中的数据表的表名称。通过运行信息获取指令,例如descformatted命令,根据数据表的表名称获取到数据表的详细信息,包括数据表的存储位置、数据表的类型、数据表的建立时间等。根据所获得的数据表的详细信息生成数据表的文件目录,例如可通过grep处理得到数据表的文件目录。该文件目录中即包含数据表的上述详细信息。为了便于后续查找到各个数据表的文件目录,则将生成的文件目录存入创建的用于存放文件目录的结果文件中。文件目录中包含数据表的文件大小信息,即在数据表中存入数据时,该数据表中数据的大小将体现在文件目录信息中。本实施例中,在任务执行时,创建用于存放任务的执行结果数据的数据表,并生成数据表的文件目录。在需要监测某个任务是否成功执行时,则根据预先生成的该任务的数据表的文件目录中包含的文件大小,即可确定该数据表中是否存放有该任务的执行结果数据,进而判断任务是否成功执行。由上述可知,各个执行任务的数据表的文件目录将预先存入结果文件中,因此,针对上述的待查询数据表,则可根据待查询数据表的表名称,从该结果文件中查找到待查询数据表对应的文件目录。本实施例中,在任务执行时,用户除了关注任务是否成功执行外,即是否成功产生执行结果数据外,还希望能够确定任务执行结束时间。而数据表对应的文件目录,将根据数据表中数据的更新情况进行相应更改。因此,请再次参阅图2,本实施例中,任务监测方法还包括以下步骤:步骤s250,根据所述文件目录的最新修改时间,确定所述待监测任务的执行结束时间。数据表中包含不同的时间分区,可以每天进行分区,当然也可以是其他时间间隔进行分区。在以每天进行分区时,即数据表中存放的数据区分为每天所产生的数据。具体地,在任务执行时,获取任务执行的日期信息,例如2019年12月26日,相应地,将该日期下该任务产生的执行结果数据存入数据表中相应的时间分区内,表明该时间分区内的数据为该日期下产生的数据。而该数据表对应的文件目录也相应地分为每天所生成的文件目录,即具体对应于该数据表中每个时间分区内的数据的文件目录。针对某个数据表,该数据表每天所对应的文件目录的形式可如表1中所示。在表1中,其中,如hdfs://huyamlcluster/user/hive/warehouse/gamelive.db/dwd_huya_event/表示一条文件目录,该文件目录为数据表dwd_huya_event所对应的文件目录。而其中如2019-12-16表示该文件目录为该日期下生成的文件目录,该文件目录包含的文件大小为数据表中时间分区为2019-12-16的执行结果数据对应的大小。前面的如2.2t即为该条文件目录中包含的文件大小,表示在该日期下,该数据表中存入的执行结果数据为2.2t。表1请参阅图5,在获得待查询数据表对应的文件目录时,则可通过以下方式获得:步骤s231,获取所述待监测任务的执行日期。步骤s232,从所述结果文件中筛选出包含的表名称与所述待查询数据表的表名称一致的文件目录。步骤s233,从筛选出的文件目录中查找到包含的日期信息与所述执行日期一致的文件目录。针对待监测任务,在查询待监测任务是否成功执行、执行结束时间的时间点与待监测任务的执行时间点可能并不相同,例如,待监测任务的执行日期可能是2019年12月26日,进行待监测任务查询的日期可能是2019年12月29日。在2019年12月26日所执行的待监测任务,其产生的执行结果数据将存入其对应的待查询数据表的时间分区对应为2019年12月26日的分区内,且该分区内的信息对应的文件目录为该执行日期下所产生的文件目录。而结果文件中可能存放有多个具有待查询数据表的表名称的文件目录,即多个日期下分别产生的待查询数据表的文件目录。本实施例中,将根据待监测任务的执行日期,从该多个文件目录中查找到包含的表名称与待查询数据表的表名称一致、且包含的日期信息与待监测任务的执行日期一致的文件目录。该文件目录中包含的文件大小,才是待查询数据表中对应于待监测任务的执行日期下所产生的执行结果数据的大小。而在确定待监测任务的执行结束时间时,该执行结束时间应该为具体日期下的具体时间点。请参阅图6,在通过以上步骤获得待查询数据表对应的文件目录后,在确定待监测任务的执行结束时间时,可通过以下步骤获得:步骤s251,获取所述文件目录中包含的日期信息。步骤s252,确定所述文件目录在所述日期信息内的最新一次的修改时间点,将所述日期信息以及所述修改时间点作为所述待监测任务的执行结束时间。以上述为例,获取到的文件目录中包含的日期信息即为待监测任务的执行日期,如2019年12月26日。而在该日期内,数据表每一次进行更新时,则文件目录相应地修改一次,该修改可以是体现在文件大小信息的修改上,也可以是通过相关的记录修改信息的字段上,具体地不做限制,只要能够体现修改动作,并记录修改时间点即可。以执行日期所包含的24小时内,文件目录的最新一次的修改时间点,再结合该执行日期,则可确定出具体的待监测任务的执行结束时间。例如,执行结束时间可以是2019年12月26日,23:00。本实施例中,通过以上过程,针对待监测任务,根据用于存放待监测任务的执行结果数据的待查询数据表所对应的文件目录,即可判断待监测任务是否成功执行,即是否成功产生执行结果数据。并且,可确定待监测任务具体的执行结束时间。此外,可将获得的待监测任务的文件目录中所包含的文件大小以及待监测任务的执行结束时间存入创建的一监测文件中,并且可将监测文件中的信息备份至一创建的监测数据表中。如此,通过数据备份可保障数据的安全性,后续可以通过查找该监测文件或者监测数据表的方式,获取到待监测任务的相关信息。以下示意性示出根据监测需求信息得到存放文件目录的结果文件,以及基于结果文件中的信息,查询文件大小以及读取文件目录修改时间的代码实现形式:(1)在任务执行阶段,首先,记录任务执行的时间信息:check_report_table.sh#!/bin/shdata_hour=$(date" %y%m%d%h0000")data_dt=$(date" %y-%m-%d"-d"-1day")创建一用于存放数据表的文件目录的结果文件:file=$(:>/home/hive/script/config/table_location.cfg)通过监测需求给定的表清单,获取待监测的数据表,并生成数据表的文件目录,将文件目录写入至上述创建的结果文件中:(2)在查询待监测任务的相关信息阶段,首先,记录下执行监测代码时的时间信息:check_report_table_location.sh#!/bin/shdata_hour=$(date" %y%m%d%h0000")data_dt=$(date" %y-%m-%d"-d"-1day")创建一用于存放文件大小以及任务执行结束时间的监测文件:file=$(:>/home/hive/script/shell/table_location_result.txt)读取上述的结果文件获取文件目录中的文件大小,并获得文件目录的修改时间,并将文件大小和修改时间存入上述创建的监测文件中:将监测文件中的信息备份到一创建的监测数据表中,以供后续查询:loadfile=$(/data/apps/hive/bin/hive-e"usegamelive;loaddatalocalinpath'/home/hive/script/shell/table_location_result.txt'overwriteintotablereport_table_location_checkpartition(dt='$data_dt');")本实施例中,通过上述的执行语句shcheck_report_table.sh以及shcheck_report_table_location.sh,可实现执行任务的结束时间以及执行结果数据有无的确定,相比现有的需要进入数据库进行数据库表查询的方式,本实施例中的方案可大大缩短监测、查询时间。结合图7,本申请实施例还提供一种可应用于上述电子设备10的任务监测装置300。其中,所述任务监测装置300可以包括请求获取模块310、信息获取模块320、目录获得模块330以及判断模块340。请求获取模块310,用于获取针对待监测任务的监测请求。在本实施例中,所述请求获取模块310可用于执行图2所示的步骤s210,关于所述请求获取模块310的相关内容可以参照前文对步骤s210的描述。信息获取模块320,用于根据所述监测请求获得待查询数据表的表信息,所述待查询数据表用于存放所述待监测任务的执行结果数据。在本实施例中,所述信息获取模块320可用于执行图2所示的步骤s220,关于所述信息获取模块320的相关内容可以参照前文对步骤s220的描述。目录获得模块330,用于获得预先生成的所述待查询数据表的表信息对应的文件目录。在本实施例中,所述目录获得模块330可用于执行图2所示的步骤s230,关于所述目录获得模块330的相关内容可以参照前文对步骤s230的描述。判断模块340,用于获取所述文件目录中包含的文件大小,并根据所述文件大小判断所述待监测任务是否成功执行。在本实施例中,所述判断模块340可用于执行图2所示的步骤s240,关于所述判断模块340的相关内容可以参照前文对步骤s240的描述。在一种可能的实施方式中,所述任务监测装置300还包括时间确定模块350,该时间确定模块350可以用于:根据所述文件目录的最新修改时间,确定所述待监测任务的执行结束时间。在一种可能的实施方式中,所述任务监测装置300还包括文件获取模块,该文件获取模块可以用于:针对每个执行任务,为所述执行任务创建对应的数据表以用于存放所述执行任务的执行结果数据;获取所述数据表的表名称;基于所述表名称生成所述数据表的文件目录;将所述文件目录存入结果文件中。在一种可能的实施方式中,上述目录获得模块330可以用于通过以下方式获得文件目录:根据所述待查询数据表的表名称,从所述结果文件中查找到所述待查询数据表对应的文件目录。在一种可能的实施方式中,目录获得模块330可以用于通过以下方式从结果文件中获得文件目录:获取所述待监测任务的执行日期;从所述结果文件中筛选出包含的表名称与所述待查询数据表的表名称一致的文件目录;从筛选出的文件目录中查找到包含的日期信息与所述执行日期一致的文件目录。在一种可能的实施方式中,上述时间确定模块350可以用于通过以下方式获得执行结束时间:获取所述文件目录中包含的日期信息;确定所述文件目录在所述日期信息内的最新一次的修改时间点,将所述日期信息以及所述修改时间点作为所述待监测任务的执行结束时间。在一种可能的实施方式中,上述判断模块340可以用于通过以下方式判断待监测任务是否成功执行:检测所述文件目录中包含的文件大小是否大于0,若所述文件大小大于0,则确定所述待查询数据表中存放有所述待监测任务的执行结果数据,并判定所述待监测任务成功执行;若所述文件大小等于0,则确定所述待查询数据表中未存放所述待监测任务的执行结果数据,并判定所述待监测任务执行失败。在一种可能的实施方式中,所述任务监测方法还包括备份模块,该备份模块用于:将所述文件目录中包含的文件大小以及所述待监测任务的执行结束时间存入监测文件;将所述监测文件中的信息备份至监测数据表中。在本申请实施例中,对应于上述的任务监测方法,还提供了一种计算机可读存储介质,该计算机可读存储介质中存储有计算机程序,该计算机程序运行时执行上述任务监测方法的各个步骤。其中,前述计算机程序运行时执行的各步骤,在此不再一一赘述,可参考前文对所述任务监测方法的解释说明。综上所述,本申请实施例提供的任务监测方法、装置、电子设备10和可读存储介质,在获取针对待监测任务的监测请求后,根据监测请求获得待查询数据表的表信息,该待查询数据表用于存放待监测任务的执行结果数据。进而获得预先生成的待查询数据表的表信息对应的文件目录,并获取文件目录中包含的文件大小。从而根据该文件大小判断待监测任务是否成功执行。该方案采用直接读取待查询数据表的文件目录,根据文件目录的文件大小判断数据表中数据的有无,进而判定待监测任务的执行情况。避免了从数据库中读取数据表以判断数据的有无所存在的数据库执行耗时长的缺陷,提高了监测查询的速度。在本申请实施例所提供的几个实施例中,应该理解到,所揭露的装置和方法,也可以通过其它的方式实现。以上所描述的装置和方法实施例仅仅是示意性的,例如,附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分,所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现方式中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个连续的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或动作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。另外,在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分,也可以是各个模块单独存在,也可以两个或两个以上模块集成形成一个独立的部分。所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,电子设备,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:u盘、移动硬盘、只读存储器(rom,read-onlymemory)、随机存取存储器(ram,randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。需要说明的是,在本文中,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。以上所述仅为本申请的优选实施例而已,并不用于限制本申请,对于本领域的技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。当前第1页1 2 3 当前第1页1 2 3 
技术特征:1.一种任务监测方法,其特征在于,所述方法包括:
获取针对待监测任务的监测请求;
根据所述监测请求获得待查询数据表的表信息,所述待查询数据表用于存放所述待监测任务的执行结果数据;
获得预先生成的所述待查询数据表的表信息对应的文件目录;
获取所述文件目录中包含的文件大小,并根据所述文件大小判断所述待监测任务是否成功执行。
2.根据权利要求1所述的任务监测方法,其特征在于,所述方法还包括:
根据所述文件目录的最新修改时间,确定所述待监测任务的执行结束时间。
3.根据权利要求1所述的任务监测方法,其特征在于,所述获取针对待监测任务的监测请求的步骤之前,所述方法还包括:
针对每个执行任务,为所述执行任务创建对应的数据表以用于存放所述执行任务的执行结果数据;
获取所述数据表的表名称;
基于所述表名称生成所述数据表的文件目录;
将所述文件目录存入结果文件中。
4.根据权利要求3所述的任务监测方法,其特征在于,所述获得预先生成的所述待查询数据表的表信息对应的文件目录的步骤,包括:
根据所述待查询数据表的表名称,从所述结果文件中查找到所述待查询数据表对应的文件目录。
5.根据权利要求4所述的任务监测方法,其特征在于,所述根据所述待查询数据表的表名称,从所述结果文件中查找到所述待查询数据表对应的文件目录的步骤,包括:
获取所述待监测任务的执行日期;
从所述结果文件中筛选出包含的表名称与所述待查询数据表的表名称一致的文件目录;
从筛选出的文件目录中查找到包含的日期信息与所述执行日期一致的文件目录。
6.根据权利要求2所述的任务监测方法,其特征在于,所述根据所述文件目录的最新修改时间,确定所述待监测任务的执行结束时间的步骤,包括:
获取所述文件目录中包含的日期信息;
确定所述文件目录在所述日期信息内的最新一次的修改时间点,将所述日期信息以及所述修改时间点作为所述待监测任务的执行结束时间。
7.根据权利要求1所述的任务监测方法,其特征在于,所述根据所述文件目录中包含的文件大小,判断所述待监测任务是否成功执行的步骤,包括:
检测所述文件目录中包含的文件大小是否大于0,若所述文件大小大于0,则确定所述待查询数据表中存放有所述待监测任务的执行结果数据,并判定所述待监测任务成功执行;
若所述文件大小等于0,则确定所述待查询数据表中未存放所述待监测任务的执行结果数据,并判定所述待监测任务执行失败。
8.根据权利要求2所述的任务监测方法,其特征在于,所述方法还包括:
将所述文件目录中包含的文件大小以及所述待监测任务的执行结束时间存入监测文件;
将所述监测文件中的信息备份至监测数据表中。
9.一种任务监测装置,其特征在于,所述装置包括:
请求获取模块,用于获取针对待监测任务的监测请求;
信息获取模块,用于根据所述监测请求获得待查询数据表的表信息,所述待查询数据表用于存放所述待监测任务的执行结果数据;
目录获得模块,用于获得预先生成的所述待查询数据表的表信息对应的文件目录;
判断模块,用于获取所述文件目录中包含的文件大小,并根据所述文件大小判断所述待监测任务是否成功执行。
10.一种电子设备,其特征在于,包括:
存储器,用于存储计算机程序;
与所述存储器连接的处理器,用于执行所述计算机程序,以实现权利要求1-8任意一项所述的任务监测方法。
11.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,该程序被执行时实现权利要求1-8任意一项所述的任务监测方法。
技术总结本申请实施例提供一种任务监测方法、装置、电子设备和可读存储介质,在获取针对待监测任务的监测请求后,根据监测请求获得待查询数据表的表信息,该待查询数据表用于存放待监测任务的执行结果数据。进而获得预先生成的待查询数据表的表信息对应的文件目录,并获取文件目录中包含的文件大小。从而根据该文件大小判断待监测任务是否成功执行。该方案采用直接读取待查询数据表的文件目录,根据文件目录的文件大小判断数据表中数据的有无,进而判定待监测任务的执行情况。避免了从数据库中读取数据表以判断数据的有无所存在的数据库执行耗时长的缺陷,提高了监测查询的速度。
技术研发人员:余东波;仇贲
受保护的技术使用者:广州虎牙科技有限公司
技术研发日:2020.01.07
技术公布日:2020.06.05