CN114996080A - 数据处理方法、装置、设备及存储介质 - Google Patents

Abstract

本申请实施例提供一种数据处理方法、装置、设备及存储介质，其中：基于获取的待处理数据，监测所述待处理数据的处理过程；响应于监测到所述待处理数据的处理过程发生异常，生成所述处理过程的日志信息和所述日志信息关联的指标信息；基于所述日志信息和所述指标信息，生成并输出告警信息以提示对所述异常进行处理。

Description

数据处理方法、装置、设备及存储介质

技术领域

本申请实施例涉及数据链路分析技术领域，涉及但不限于一种数据处理方法、装置、设备及存储介质。

背景技术

在相关技术的大数据链路治理过程中，对于大数据量的数据密集型应用系统，提供服务的微服务组件非常多。对于具体业务来说，通常需要组合多个维度，进行合理的组合分析，这样，在数据处理过程中，难以准确定位发生异常的数据。

发明内容

本申请实施例提供一种数据处理技术方案。

本申请实施例的技术方案是这样实现的：

第一方面，本申请实施例提供一种数据处理方法，所述方法包括：

基于获取的待处理数据，监测所述待处理数据的处理过程；

响应于监测到所述待处理数据的处理过程发生异常，生成所述处理过程的日志信息和所述日志信息关联的指标信息；

基于所述日志信息和所述指标信息，生成并输出告警信息以提示对所述异常进行处理。

第二方面，本申请实施例提供一种数据处理方法，所述方法包括：

响应于接收到表示待处理数据的处理过程发生异常的告警信息，获取所述处理过程的指标信息；

基于所述指标信息，确定所述处理过程发生异常的异常点；

确定与所述异常点匹配的日志信息；

基于所述日志信息，对所述处理过程发生的异常进行处理。

第三方面，本申请实施例提供一种数据处理装置，所述装置包括：

第一监测模块，用于基于获取的待处理数据，监测所述待处理数据的处理过程；

第一生成模块，用于响应于监测到所述待处理数据的处理过程发生异常，生成所述处理过程的日志信息和所述日志信息关联的指标信息；

第一告警模块，用于基于所述日志信息和所述指标信息，生成并输出告警信息以提示对所述异常进行处理。

第四方面，本申请实施例提供一种数据处理装置，所述装置包括：

第一获取模块，用于响应于接收到表示待处理数据的处理过程发生异常的告警信息，获取所述处理过程的指标信息；

第四确定模块，用于基于所述指标信息，确定所述处理过程发生异常的异常点；

第五确定模块，用于在日志服务器中，确定与所述异常点匹配的目标日志信息；其中，所述日志服务器中包括多次异常对应的日志信息和指标信息；

第一处理模块，用于基于所述目标日志信息，处理所述处理过程发生的异常。

本申请实施例提供一种计算机存储介质，所述计算机存储介质上存储有计算机可执行指令，该计算机可执行指令被执行后，能够实现上述第一方面或第二方面的步骤。

本申请实施例提供一种计算机设备，所述计算机设备包括存储器和处理器，所述存储器上存储有计算机可执行指令，所述处理器运行所述存储器上的计算机可执行指令时能够实现上述第一方面或第二方面的步骤。

本申请实施例提供一种计算机程序产品，所述计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质，所述计算机程序被计算机读取并执行时，实现上述第一方面或第二方面的步骤。

本申请实施例提供一种数据处理方法、装置、设备及存储介质，对于获取到的待处理数据，首先，按照待处理数据，监测待处理数据的处理过程，这样能够及时监测数据的处理情况，从而确定待处理数据的处理过程是否异常；然后，如果监测到待处理数据的处理过程发生异常，生成处理过程的日志信息和日志信息关联的指标信息；这样，在监测到异常的情况下，写入日志信息以及关联的指标信息，能够更加精确地监测处理过程中的异常情况，并通过日志细化异常原因，以及通过将指标信息与日志信息相关联，能够通过指标信息准确查找到该指标所指示的日志信息。最后，基于日志信息和指标信息，生成并输出告警信息以提示对异常进行处理；这样，通过对异常过程写的日志信息和指标信息，能够更加快速且准确地定位发生异常的问题，进而能够及时输出告警信息，以提示对异常进行处理。

附图说明

图1为本申请实施例提供的数据处理方法的实现流程示意图；

图2为本申请实施例提供的数据处理方法的另一实现流程示意图；

图3为本申请实施例提供的数据处理方法的再一实现流程示意图；

图4A为本申请实施例提供的数据处理方法的系统架构示意图；

图4B为本申请实施例提供的数据处理的实现框架示意图；

图5为本申请实施例提供的数据处理方法的实现流程示意图；

图6为本申请实施例提供的数据处理方法的另一实现流程示意图；

图7为本申请实施例提供的数据处理方法的应用场景示意图；

图8为本申请实施例提供的数据处理装置的结构组成示意图；

图9为本申请实施例提供的数据处理装置的结构组成示意图；

图10为本申请实施例计算机设备的组成结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对发明的具体技术方案做进一步详细描述。以下实施例用于说明本申请，但不用来限制本申请的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是是区别类似的实例，不代表针对实例的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

1)分布式系统，是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件(特别是操作系统)，而不是硬件。

2)统一资源定位系统(Uniform Resource Locator，URL)，是因特网的万维网服务程序上用于指定信息位置的表示方法。在万维网(World Wide Web，WWW)上，每一信息资源都有统一的且在网上唯一的地址，该地址即为URL，是WWW的统一资源定位标志，即网络地址。

下面说明本申请实施例提供的数据处理的设备的示例性应用，本申请实施例提供的设备可以实施为具有图像采集功能的笔记本电脑，平板电脑，台式计算机，相机，移动设备(例如，个人数字助理，专用消息设备，便携式游戏设备)等各种类型的用户终端，也可以实施为服务器。下面，将说明设备实施为终端或服务器时示例性应用。

该方法可以应用于计算机设备，该方法所实现的功能可以通过计算机设备中的处理器调用程序代码来实现，当然程序代码可以保存在计算机存储介质中，可见，该计算机设备至少包括处理器和存储介质。

本申请实施例提供一种数据处理方法，该方法由数据处理系统的后台实现，如图1所示，结合如图1所示步骤进行说明：

步骤S101，基于获取的待处理数据，监测所述待处理数据的处理过程。

在一些实施例中，待处理数据可以是需要进行处理的任意类型的大数据。待处理数据的获取可以是后台采集的，还可以是后台接收到其他设备发送的。在一些可能的实现方式中，待处理数据可以是图像数据、文本数据或者音频数据等。以待处理数据为图像数据为例，获取该待处理数据可以是后台控制摄像头采集得到的，还可以是后台接收到其他设备发送的图像数据。

在一些实施例中，待处理数据可以是，通过人工智能领域的分布式系统的数据链路进行数据处理的数据。比如，待处理数据为多帧交通图像，需要采用分布式系统识别交通图像中是否包括车辆。对于获取到的待处理数据，将待处理数据输入到数据处理系统中。在该数据处理提供中包括多个数据处理组件和处理流程管线。该处理流程管线即为实现对待处理数据进行数据处理的整个流程，这样，不同处理需求的待处理数据，对应的处理流程管线也不同。

在一些可能的实现方式中，获取到待处理数据之后，将待处理数据输入数据处理系统，该系统后台可以按照一定时长间隔对待处理数据的处理过程进行监测，还可以是实时对待处理数据的处理过程进行监测。其中，该一定时长间隔可以是按照本领域技术人员的经验值设定的，比如设定时长间隔为5秒钟。待处理数据的处理过程为将待处理数据输入到数据处理系统之后的整个过程，包括：待处理数据在系统中各个组件中的处理以及待处理数据在系统中的处理流程管线等。在一个具体例子中，如果数据处理系统后台按照每间隔5秒钟对待处理数据的处理过程监测一次，那么监测到该待处理数据的处理过程是否异常，并且每间隔5秒钟可确定一次待处理数据的处理过程是否异常。如果待处理数据在一次监测时长间隔中有处理异常，那么在到达监测时长间隔时，会监测的待处理数据的处理过程发生异常。

步骤S102，响应于监测到所述待处理数据的处理过程发生异常，生成所述处理过程的日志信息和所述日志信息关联的指标信息。

在一些实施例中，待处理数据的处理过程发生异常表示，该处理过程中产生的数据与待处理数据的预设处理需求中指示的数据不同。其中，预设处理需求包括该待处理数据在处理过程中预设的最终处理结果(比如，待处理数据为人脸图像，最终的处理结果是检测图像中的人脸)、中间阶段(比如，每一组件)的预设的中间处理结果(比如，如果组件A的功能是进行图像过滤，那么组件A的预设的中间处理结果为过滤出图像质量较好的图像；如果组件B的功能是进行图像检测，那么组件B的预设的中间处理结果为输出人脸的检测框)以及处理过程中系统自身的参数(比如，系统处理速度、网络延时或系统存储失败等)。

在一些实施例中，处理过程的日志信息包括以下至少之一：设备(或组件)标识、异常的概要原因、异常的详细原因、发现异常的时间以及失败数据的存储地址等。日志信息关联的指标信息标识该指标信息与日志信息存储至少部分的重叠，从而使得能够通过指标信息查找到该指标信息所对应数据的日志信息。比如，指标信息包括以下至少之一：设备(或组件)标识、概要原因以及发现异常的时间等。

在一些可能的实现方式中，如果数据处理系统是对待处理数据的处理过程实时监测的，那么能够实时获取到发生异常的待处理数据的日志信息和指标信息。如果数据处理系统是按照一定时长间隔对待处理数据的处理过程实时监测的，那么能够获取在该时长间隔内每一次发生异常的待处理数据的日志信息和指标信息。比如，一定时长间隔为5秒，能够获取这5秒钟内发生异常的待处理数据日志信息和指标信息。

在一些可能的实现方式中，可以是监测到待处理数据的处理过程发生异常的同时，写处理过程的日志信息和日志信息关联的指标信息。还可以是监测到待处理数据的处理过程发生异常的次数达到一定次数的情况下，

步骤S103，基于所述日志信息和所述指标信息，生成并输出告警信息以提示对所述异常进行处理。

在一些实施例中，基于处理过程的至少一次异常对应的日志信息和指标信息，生成并输出告警信息以提示对异常进行处理。按照日志信息和指标信息中的内容，生成告警信息。该告警信息可以是输出在系统的界面上，还可以是输出到与系统通信的终端设备上。告警信息用于提示用户或终端设备对发生的异常进行处理。在一些可能的实现方式中，告警信息的形式可以是文本形式、语音形式或者弹出框的形式进行提示。

在一些实施例中，按照日志信息和指标信息中写入的发生异常的概要原因，生成该告警信息。比如，概要原因为系统存储失败，那么告警信息可以是“存储失败”，可以通过文本或语音等形式输出。

在一些可能的实现方式中，可以是在每次监测到异常写该日志信息和指标信息时，按照日志信息和指标信息生成告警信息；还可以是在监测到异常的次数达到预设次数时，按照这多次异常的日志信息和指标信息，生成告警信息。在实施时，预设次数可以是按照本领域技术人员的经验值设定的；比如，设定预设次数为3次，那么在监测到3次异常时，按照这3次写入的日志信息和指标信息，生成告警信息，以提示终端对异常进行处理。

在本申请实施例中，对于获取到的待处理数据，首先，按照待处理数据，监测待处理数据的处理过程，能够及时监测数据的处理情况，从而确定待处理数据的处理过程是否异常；然后，如果监测到待处理数据的处理过程发生异常，生成处理过程的日志信息和日志信息关联的指标信息；这样，在监测到异常的情况下，写入日志信息以及关联的指标信息，能够更加精确地监测处理过程中的异常情况，并通过日志细化异常原因，以及通过将指标信息与日志信息相关联，能够通过指标信息准确查找到该指标所指示的日志信息。最后，基于日志信息和指标信息，生成并输出告警信息以提示对异常进行处理；这样，通过对异常过程写的日志信息和指标信息，能够更加快速且准确地定位发生异常的问题，进而能够及时输出告警信息，以提示对异常进行处理。

在一些实施例中，按照一定时长间隔，对进行数据处理的组件和预设处理流程进行监测，上述步骤S101可以通过以下步骤S111和S112(图示未示出)实现：

步骤S111，确定用于对所述待处理数据进行处理的组件和所述待处理数据的预设处理流程。

在一些实施例中，在对待处理数据进行数据处理的系统中，确定对该待处理数据进行处理的组件。该组件包括对待处理数据进行处理的各种功能的组件。待处理数据的预设处理流程即按照待处理数据的处理需求设定的处理流程，其中，待处理数据的处理需求为设定的对待处理数据的标准处理结果，包括：识别结果的内容以及识别结果中对参数的需求(比如，对处理时间的需求、对存储空间的需求以及对存储位置的需求等)，处理流程可以为实现标准处理结果需要进行的处理步骤。

在一些可能的实现方式中，比如，如果待处理数据为交通图像，设定的标准处理结果为识别到交通图像中的车辆；那么处理流程至少包括：在交通图像中进行车辆检测、确定车辆关键点、特征提取以及按照提取的特征进行车辆识别等。

在一些可能的实现方式中，如果待处理数据为人物图像，设定的标准处理结果为检测到人物图像中的人脸；那么处理流程至少包括：检测对象、找出关键点、提取特征、提取人脸属性、人脸检测的评分等。

步骤S112，按照预设时长间隔，在所述预设处理流程中监测所述预设组件对所述待处理数据的处理过程。

在一些实施例中，预设时长间隔可以是按照待处理数据的处理需求设定的，如果处理需求中需要频繁地监测待处理数据的异常，那么预设时长间隔可以设定为较小的间隔(比如，1秒钟)；比如，待处理数据为餐厅场景下的食客图像，处理需求为在食客图像中识别有服务需求的食客，为给食客能够及时提供服务，所以需要将数据监测的时长间隔设置的较短一点。如果处理需求中不需要频繁地监测待处理数据的异常，那么可以将数据监测的时长间隔设置为较大的间隔(比如，30秒)；比如，待处理数据为交通场景下的车辆图像，处理需求为在车辆图像中识别有违章的车辆，为能够及时识别违章车辆但不会累积较多的数据，所以可以将数据监测的时长间隔设置的较长一点，比如，1分钟。

通过上述步骤S111和步骤S112，按照待处理数据的处理需求，能够确定实现该处理需求的预设处理流程以及整个预设处理流程中涉及到的组件，这样，便于后续在预设处理流程和组件中定位到发生异常的位置。在确定数据处理的组件和预设处理流程之后，通过按照预设时长间隔，周期性的在预设处理流程中监测预设组件对待处理数据的处理过程，如此既能够减少数据监测产生的非必要数据量还能够及时发现异常的处理过程。

在一些实施例中，在预设处理流程中监测预设组件对所述待处理数据的处理过程，如果处理结果或者处理过程中的处理参数不满足待处理数据的预设处理需求，那么说明处理过程发生异常，可以通过以下步骤实现：

第一步，在所述处理过程中，确定所述待处理数据的处理结果和所述处理过程的处理参数。

在一些实施例中，在待处理数据的处理过程中，确定待处理数据在每一组件中的处理结果，该处理结果与组件的功能相关，即每一组件中的处理结果为该组件的输出结果。比如，如果组件的功能为实现对象检测，那么该组件的处理结果为检测到对象或未检测到对象。如果组件的功能为属性信息提取，那么该组件的处理结果为提取的属性信息。处理过程的参数为在处理过程的系统参数，包括：系统处理速度、系统处理时间、存储时间、存储位置等。

在一些可能的实现方式中，可以是按照预设时长间隔在处理过程中，确定待处理数据的处理结果和处理过程的处理参数；还可以是实时在处理过程中，确定待处理数据的处理结果和处理过程的处理参数。

第二步，在监测到所述处理结果或所述处理参数不满足所述待处理数据的预设处理需求的情况下，确定所述处理过程发生异常。

在一些实施例中，处理数据的预设处理需求表征设定的标准处理结果，包括：每一组件的处理结果和每一组的处理参数以及系统的处理参数等。如果在预设处理流程的任一位置处检测到的处理结果与预设处理需求所表征的处理结果不同，说明在该位置的处理发生异常。

在一些可能的实现方式中，处理结果或处理参数不满足待处理数据的预设处理需求，包括：处理结果与预设处理需求中的处理结果不完全相同，或，处理参数与预设处理需求中的处理参数不完全相同；还可以包括：处理结果与预设处理需求中的处理结果之间的差别较大，或，处理参数的值与预设处理需求中的处理参数的值之间的差值较大；比如，差值大于预设差值阈值，该预设差值阈值可以是根据预设处理需求中对处理参数的精度要求来设定；这样，如果预设处理需求中对处理参数的精度要求比较高，那么差值要设定的较小；如果预设处理需求中对处理参数的精度要求比较低，那么差值要设定的较大。

通过上述第一步和第二步，在处理过程中确定处理结果和处理参数，便于及时监测到发生异常的处理过程；在确定处理结果和处理参数之后，按照预设处理需求判断处理过程中待处理数据的处理结果和处理参数，从而能够待处理数据的数据链路中，定位中间各种异常问题。

在一些实施例中，监测到处理过程发生异常，在丢弃发生异常的待处理数据的同时，写该带处理数据的日志信息，即上述步骤S102可以通过图2所示的步骤实现：

步骤S201，响应于监测到所述处理过程发生异常，确定所述处理过程对应的设备标识。

在一些实施例中，监测到处理过程发生异常，比如，监测到任一组件的输出结果异常；那么在丢弃该异常的输出结果对应的待处理数据的同时，获取该处理过程的处理结果和所述处理过程的处理参数，以及该处理过程所在设备的设备标识。设备标识用于唯一表示该设备，可以包括以下至少之一：设备的机器序列号、设备铭牌或设备标签等。

步骤S202，基于所述待处理数据的预设处理需求、所述处理过程的处理结果和所述处理过程的处理参数，确定所述处理过程发生异常的异常原因。

在一些实施例中，将发生异常的处理过程中待处理数据的处理结果与预设处理需求中该处理过程的处理结果进行比对，以及，将处理参数与预设处理需求中该处理过程的处理参数进行比对，能够得到该处理过程发生异常的处理结果，以及发生异常的处理参数；按照该发生异常的处理结果和处理参数即可得到处理过程发生异常的异常原因。

在一些可能的实现方式中，如果待处理数据为文本数据，预设处理需求包括：组件的处理结果(即对文本数据进行文本识别得到文本数据中的文本内容)、处理速度以及存储位置等；将发生异常的处理过程的处理结果与预设处理需求中组件的处理结果进行比对，将发生异常的处理过程的处理参数中的处理速度和存储位置，与预设处理需求中的处理速度和存储位置进行比对，即可确定该组件的处理结果是否异常以及处理参数中哪一参数发生异常。

步骤S203，将所述处理过程对应的设备标识和所述异常原因，作为所述日志信息，并将所述日志信息存储至日志服务器。

在一些实施例中，在监测到处理过程发生异常时会丢弃发生异常的待处理数据，同时将获取到的设备标识和异常原因作为日志条目，写入日志信息中；将记录好的日志信息存储在日志服务器中，比如，将日志信息上传至日志服务器，这样，日志服务器中包括多个处理过程发生异常的待处理数据的日志信息，从而用户能够在日志服务器中查找任一异常的待处理数据的日志信息。

在一些可能的实现方式中，在监测到处理过程发生异常的情况下，通过分析处理过程的处理结果和处理参数与预设处理需求之间的差异能够准确定位到处理过程发生异常的异常原因；而且在丢弃发生异常的待处理数据的同时，将处理过程对应的设备标识和异常原因，写为日志信息，从而能够便于后续用户可以通过日志信息精准地定位发生异常的异常点以及通过日志信息中的异常原因可以直接解决问题。

在一些实施例中，为便于用户通过日志信息能够查找到发生异常的待处理数据，可以将发生异常的待处理数据的存储地址写入日志信息，可以通过以下步骤实现：

第一步，确定所述待处理数据在预设数据库中的存储地址。

在一些实施例中，在监测到处理过程发生异常的情况下，将待处理数据按照二进制的形式写入到预设数据库中，并记录在预设数据库中的存储地址。该预设数据库可以是用于存储二进制数据的存储服务器；这样，待处理数据在预设数据库中的存储地址即为待处理数据的二进制形式在服务器中的存储地址。

第二步，将所述存储地址，写为所述日志信息。

在一些实施例中，在日志信息中写入处理过程对应的设备标识和异常原因的同时，将待处理数据在预设数据库中的存储地址也写入日志信息中，这样，日志信息中至少包括三个日志条目：处理过程对应的设备标识、异常原因和待处理数据在预设数据库中的存储地址。将至少包括这三个日志条目的日志信息存储在日志服务器。如此，日志服务器存储的不同待处理数据的日志信息均能够为用户提供待处理数据在预设数据库中的存储地址。

通过上述第一步和第二步，将待处理数据按照二进制形式存储到预设数据库中，并将待处理数据在预设数据库中的存储地址也写入日志信息中，这样日志信息中包括：处理过程对应的设备标识、异常原因和存储地址；如此，对于发生异常的处理过程，用于能够通过日志信息即可查询到发生异常的待处理数据，便于对这些待处理数据进行再次分析，以更加精确的定位异常问题。

在一些实施例中，通过将发生异常的待处理数据进行数据格式的转换，存储在预设数据库中，以便于用于查找待处理数据，即在上述第一步之前，还包括以下过程：

首先，响应于监测到所述处理过程发生异常，按照预设数据格式对所述待处理数据进行转换，得到已转换数据。

在一些实施例中，在监测到处理过程发生异常时，为使得用户能够在日志信息中获取异常的待处理数据的原始数据，那么按照预设数据格式对所述待处理数据进行转换。该预设数据格式可以是按照预设数据库对数据存储形式的要求来设定的；比如，如果预设数据库对数据存储形式的要求为二进制，那么预设数据格式为二进制；将待处理数据转换为二进制，得到二进制表示的待处理数据，即已转换数据。如果预设数据库对数据存储形式的要求为八进制，那么预设数据格式为八进制；将待处理数据转换为八进制，得到八进制表示的待处理数据，即已转换数据。

然后，将所述已转换数据，存储在所述预设数据库。

在一些实施例中，将已转换数据上传至预设数据库，并保存在预设数据库中。这样，预设数据库中即存储了处理过程发生异常的原始数据，便于用户从预设数据库中查看作为原始数据的待处理数据。

在本申请实施例中，对于处理过程发生异常的待处理数据，通过转换为二进制形式，将该待处理数据以二进制形式存储在预设数据库中，如此既能够保存原始的待处理数据，便于后续用户通过原始的待处理数据分析发生异常的问题，还能够减少数据存储量。

在一些实施例中，通过分析发生异常的处理结果和处理参数与预设处理需求之间的差异，能够确定处理过程发生异常的详细原因和概要原因，即上述步骤S202可以通过以下步骤S221至S224(图示未示出)实现：

步骤S221，分别确定所述处理结果和所述处理参数，与所述预设处理需求之间的差异信息。

在一些实施例中，将发生异常的处理过程的处理结果与预设处理需求中针对该待处理数据设定的处理结果进行比较，得到处理结果的差异信息；将发生异常的处理过程的处理参数与预设处理需求中针对该待处理数据设定的处理参数进行比较，得到处理参数的差异信息；将处理结果的差异信息与处理参数的差异信息相结合，作为最终的差异信息。

在一些可能的实现方式中，以待处理数据为待识别的人脸图像为例，预设处理需求为对人脸图像中的人脸进行身份识别，包括对整个身份识别过程中任一阶段的处理结果的设定，以及处理参数的设定。比如，身份识别过程包括：检测对象、查找关键点、提取特征、提取属性以及身份评分等。如果在检测对象的过程中发生异常，那么将发生异常的检测对象的过程中的处理结果，与，预设处理需求中检测对象的过程中设定的处理结果进行比对，得到两个处理结果之间的差异。同理，将发生异常的处理过程的处理参数(比如，检测对象的时长)与预设处理需求中检测对象的过程中设定的处理参数进行比对，得到处理参数的差异信息。

步骤S222，基于所述差异信息，生成所述异常的详细原因。

在一些实施例中，通过文本详细描述差异信息，即可得到发生异常的详细原因。在一些可能的实现方式中，将该异常信息转换为文本，得到异常的详细原因。

在一个具体例子中，如果差异信息包括：检测对象得到的结果与预设处理需求中检测对象的结果之间的差异为未检测到对象，检测时长与预设处理需求中设定的检测时长之间的差值为2秒。那么通过将该差异信息转换为文本，得到详细原因为：检测对象阶段未检测到对象且检测时长超过设定的检测时长2秒。

步骤S223，基于所述详细原因，确定所述异常的概要原因。

在一些实施例中，通过对详细原因中提取关键词，通过关键词组成异常的概要原因。比如，详细原因为：检测对象阶段未检测到对象且检测时长超过设定的检测时长2秒；该详细原因中的关键词包括：未检测到对象，检测时长过长；基于此，异常的概要原因即为未检测到对象且检测时长过长。

步骤S224，将所述详细原因和所述概要原因，作为所述异常原因。

这里，将详细原因和概要原因均作为异常原因，这样，异常原因中既包括详细原因还包括概要原因，将异常原因写入日志信息之后，日志信息中即包括详细原因和概要原因，从而用户在日志信息即可快速了解到概要原因，还可以进一步了解详细原因。

在本申请实施例中，通过分析处理结果和所述处理参数，与预设处理需求之间的差异信息，能够确定异常的具体内容从而得到该异常的详细原因；并对详细原因进行主要内容的概述得到概要原因，从而能够将详细信息和概要信息均写入日志信息，使得用户能够通过日志信息快速定位发生异常的概要原因，并通过详细原因准确定位异常问题。

在一些实施例中，为使得指标信息和日志信息之间具有关联关系，按照日志信息中的至少部分写指标信息，即上述步骤S101中“响应于监测到所述待处理数据的处理过程发生异常，生成所述日志信息关联的指标信息”，可以通过以下步骤S113和S114(图示未示出)实现：

步骤S113，基于所述日志信息中的所述处理过程对应的设备标识和所述异常原因中的至少概要原因，生成指标标签。

在一些实施例中，在监测到处理过程发生异常的情况下，将处理过程对应的设备标识和异常原因写入日志信息的通知，将设备标识和异常原因中的概要原因结合在一起，作为指标信息的指标标签。针对一个异常事件，将发生异常的待处理数据的设备标识以及概要原因对应起来，作为一个指标标签；这样，通过指标标签即可得知发生异常的设备标识，和发生异常的概要原因。

在一些可能的实现方式中，在处理过程中待处理数据的处理结果不满足预设处理需求，即处理过程中处理数据发生错误丢弃数据的情况下，写入一条指标信息，即上述步骤S113可以通过以下过程实现：

在所述日志信息中的异常原因包括所述待处理数据的处理结果不满足所述预设处理需求的情况下，基于所述日志信息中的所述设备标识和所述待处理数据的处理结果，生成所述指标标签。

这里，待处理数据的处理结果不满足预设处理需求，说明处理过程中输入的数据发生处理错误，即输入处理流程的数据，在处理过程中发生错误丢弃。在这种情况下，将日志信息中的设备标识和异常原因中关于错误丢弃数据的概要原因，作为指标信息的指标标签。这样，在发生错误丢弃数据的情况下，写日志信息的同时，将该错误丢弃数据的概要原因和设备标识生成指标信息的指标标签，从而不仅能够使得指标信息与日志信息关联起来，还能够及时生成指标信息的指标标签。

步骤S114，基于监测到发生异常的时刻和所述指标标签，生成所述指标信息。

在一些实施例中，监测到发生异常的时刻，可以理解为是在监测待处理数据的处理过程中监测发生异常的时刻。监测到的发生异常的时刻，与该处理过程发生异常的实际时刻可能相同或不同。如果对处理过程的监测是实时的，那么监测到发生异常的时间即为该处理过程发生异常的实际时刻；如果是按照一定时间间隔对处理过程的进行监测，那么监测到的发生异常的时间可能会比实际发生异常的时刻滞后。将监测到的发生异常的时间，作为一个时间戳，赋予指标标签，得到指标信息；这样，通过指标信息还能够预测发生异常的时刻。

在本申请实施例中，将日志信息中的设备标识和异常原因中的至少部分，写为指标信息的指标标签，能够便于终端通过指标信息快速定位发生异常的数据位置；并且在生成指标信息时，将监测到发生异常的时间作为时间戳携带在每一指标标签上；这样，指标信息中至少具有日志信息中的设备标识、异常原因的至少部分以及监测到发生异常的时间，能够建立日志信息和指标信息之间的关联信息，从而通过指标信息即可准确查找发生异常的数据的日志信息，进而便于终端按照日志信息解决异常问题。

在一些实施例中，为能够及时提示用户终端处理过程发生异常且不增大数据量，在检测到异常次数大于预设次数阈值的情况下，发出告警信息，即上述步骤S103可以通过以下步骤S131和S132(图示未示出)实现：

步骤S131，在所述处理过程所在的系统中，以上一次输出告警信息的时刻为起始时刻，统计所述处理过程所在的系统发生异常的次数。

在一些实施例中，在系统输出一次告警信息之后，即开始统计接下来处理过程发生异常的次数，以确定是否进行下一次告警。在该处理过程所在的系统中，从输出告警信息的时刻开始，统计在后续时间内系统进行数据处理的过程中发生异常的次数。

步骤S132，在所述次数满足预设次数阈值的情况下，基于多次异常对应的日志信息和指标信息，生成并输出所述告警信息。

在一些实施例中，预设次数阈值可以是按照系统对告警频繁度的需求设定的，如果系统对告警的次数要求不频繁，不需要严格监督发生异常的数据，那么可以将预设次数阈值设置为稍大的值，比如，设置为10次；如果系统需要严格监督处理过程是否发生异常，那么可以将预设次数阈值设置为稍小的值，比如，小于等于3次。这样，在上一次告警信息输出之后，如果统计到系统发生异常的次数达到了预设次数阈值，那么按照这多次异常的日志信息和指标信息，再次输出告警信息。

上述步骤S131和S132，通过对待处理数据在处理过程中发生异常的次数进行统计，这样能够实时统计发生异常的次数；之后，在发生异常的次数满足预设次数阈值的情况下，比如，发生异常的次数达到3次，那么按照这3次异常中写入的日志信息和指标信息，输出告警信息，进而既能够减少频繁输出告警，还能够提醒用户终端对异常数据进行处理。

本申请实施例提供一种数据处理方法，该方法由数据处理系统的前端实现，如图3所示，结合如图3所示步骤进行说明：

步骤S301，响应于接收到表示待处理数据的处理过程发生异常的告警信息，获取所述处理过程的指标信息。

在一些实施例中，数据处理系统的前端接收到后台输出的告警信息之后，从后台存储异常数据的指标信息的数据库中，获取该告警信息所对应的处理过程的指标信息。该指标信息中至少包括该处理过程所在设备的设备标识和发生异常的概要原因。通过该指标信息既能够确定该处理过程异常的大致原因。

步骤S302，基于所述指标信息，确定所述处理过程发生异常的异常点。

在一些实施例中，处理过程发生异常的异常点表示处理过程发生异常的位置。由于指标信息至少包括该处理过程所在设备的设备标识和发生异常的概要原因，那么能够通过指标信息粗略定位到发生异常位置。该发生异常的位置可能是在数据处理的组件中，还可能是组件外，比如，在两个组件之间的处理路径上。这样，处理过程发生异常的异常点可以是在数据处理的组件中，还可以是在数据处理的组件外。

步骤S303，在日志服务器中，确定与所述异常点匹配的目标日志信息。

在一些实施例中，所述日志服务器中包括多次异常对应的日志信息和指标信息。按照该异常点所表示的发生异常的位置，能够在日志服务器中查找该针对该位置发生的异常写入的日志信息和指标信息。

在一些可能的实现方式中，异常点是通过发生异常的指标信息确定的，所以通过异常点对应的指标信息中的设备标识以及概要原因，能够在日志服务器中准确查找到包括该设备标识和概要原因的日志信息，即得到目标日志信息。

步骤S304，基于所述目标日志信息，处理所述处理过程发生的异常。

在一些实施例中，在目标日志信息中至少包括设备标识、概要原因、详细原因和原始的待处理数据的存储地址等。按照目标日志信息中的详细原因或原始的待处理数据的存储地址，定位处理过程发生异常的问题，从而按照详细原因解决该问题。

在本申请实施例中，接收到告警信息后，获取针对该告警信息写入的处理过程的指标信息；这样，能够按照指标信息中写入的异常原因等信息查找发生异常的异常点；之后，在日志服务器中，查找该异常点的日志信息，即目标日志信息；这样，就能够通过目标日志信息得到异常点发生异常的详细原因，进而能够对解决处理过程发生的异常。如此，先通过指标信息发现系统中的异常点，然后通过日志信息细化异常原因，以定位并解决异常问题，通过一步步细化分析实现了对异常数据的快速处理。

在一些实施例中，通过分析发生异常的数据的指标信息，能够定位到发生异常的位置，进而便于用户在该位置处解决异常问题，即上述步骤S302可以通过以下步骤S321至S323(图示未示出)实现：

步骤S321，获取所述处理过程对应的组件和预设处理流程。

在一些实施例中，在数据处理系统中，按照待处理数据的预设处理需求，即可获取实现该处理需求的预设处理流程；将该预设处理流程中涉及到的组件作为处理过程对应的组件。

在一些可能的实现方式中，以待处理数据为人脸图像为例，待处理数据的预设处理需求为识别人脸的身份信息，这样，预设处理流程为基于人脸图像，确定人脸的身份信息的过程，包括：检测对象、找出关键点、提取特征、提取属性以及与身份信息库进行比对等。处理过程对应的组件可以是实现检测对象的组件、实现特征提取的组件、实现关键点查找的组件、实现属性提取的组件以及实现身份比对的组件等。

步骤S322，基于所述异常原因、所述处理过程对应的设备标识和指标标签的时间戳中的至少之一，在所述组件和所述预设处理流程中，确定所述处理过程发生异常的位置信息。

在一些实施例中，可以是按照异常原因中的概要原因，在处理过程对应的组件和预设处理流程中，确定发生异常的位置信息；比如，概要原因为未检测到对象，那么可确定发生异常的位置为对象检测的组件。

还可以按照处理过程对应的设备标识在所述组件和所述预设处理流程中，确定所述处理过程发生异常的位置信息；这样，按照设备标识，即可在组件中，查找具有该标识的组件，从而确定发生异常的位置信息。

还可以按照指标信息中指标标签的时间戳，按照该时间戳对应的时刻，确定这一时刻在预设处理流程中的位置，将该位置作为发生异常的位置信息。

还可以是将异常原因、处理过程对应的设备标识和指标标签的时间戳中的任意两个或者三个相结合，来确定发生异常的位置信息。

步骤S323，将所述发生异常的位置信息，确定为所述异常点。

这里，将发生异常的位置信息作为异常点，从而能够按照该位置处写入的日志信息，定位异常问题。如此，系统前端接收到告警信息之后，在发生异常的处理过程的组件和预设处理流程中，按照指标信息找到发生异常的处理过程的异常位置，从而能够精确定位到发生异常的异常点；如此，按照与日志信息管理的指标信息，定位发生异常的位置信息，进而能够按照该位置信息快速找到相关的日志信息。

在一些实施例中，通过目标日志信息中写入的数据异常的充足的详细原因，可对异常问题进行有效解决，即上述步骤S304可以通过以下步骤S341和S342(图示未示出)实现：

步骤S341，在所述目标日志信息包括的异常原因中，定位所述处理过程发生异常的异常问题。

在一些实施例中，该异常原因包括发生异常的详细原因和概要原因。通过分析概要原因或详细原因，来定位发生异常的异常问题。

在一些可能的实现方式中，由于异常原因中记载的内容充足性不可确定，所以通过异常原因不一定能够定位到准确的异常问题；如果异常原因中关于发生异常的信息记载的充足，那么能够通过日志信息中的异常原因定位到发生异常的异常问题。比如，异常原因中的详细原因为数据存储超时5秒，那么能够准确定位异常问题为存储超时。反之，如果异常原因中关于发生异常的信息记载的不充足，那么可能无法通过日志信息中的异常原因准确定位到发生异常的异常问题。比如，异常原因中的详细原因为未检测到对象(但是未说明是为什么没有检测到对象)，所以在定位异常问题时，即不能准确定位未检测到对象的具体问题。

步骤S342，响应于定位到所述异常问题，基于所述异常原因处理所述异常问题。

在一些实施例中，如果通过目标日志信息能够定位到异常问题，说明目标日志信息中的详细原因关于发生异常的信息记载的充足，那么可以通过异常原因中的详细原因有针对性对异常问题进行解决。如此，通过分析目标日志信息中的异常原因，按照异常原因中的详细原因如果能够定位到异常问题，说明该目标日志信息中的异常原因较为充足，那么能够按照异常原因中的充足信息快速且准确度的解决该异常问题。

在一些实施例中，系统前端还可以是根据日志信息中的发生异常的待处理数据的URL，对待处理数据进行再次分析以定位异常问题，即上述步骤S304可以通过以下步骤S351至S354(图示未示出)实现：

步骤S351，响应于在所述目标日志信息包括的异常原因中未定位到所述处理过程发生异常的异常问题，或接收到数据查询指令，在所述目标日志信息中确定所述待处理数据的存储地址。

在一些实施例中，如果通过异常原因未定位到处理过程发生异常的异常问题，说明目标日志信息中的详细原因关于发生异常的信息记载的不够充足。数据查询指令可以是通过系统前端输入的，用于指示查询处理过程发生异常的原始输入数据，即处理过程发生异常的待处理数据。该数据查询指令，可以是在未定位到异常问题的情况下用户发送的，还可以是在定位到异常问题的情况下，用户发送的。无论是通过异常原因未定位到异常问题，还是接收到用户输入的数据查询指令，均从目标日志信息中获取写入的待处理数据的存储地址。该存储地址为：在监测到发生异常的情况下，将作为原始数据的待处理数据转换为二进制存储在预设数据库中的地址。

步骤S352，基于所述存储地址，在预设数据库中查询所述待处理数据。

在一些实施例中，所述预设数据库用于存储处理过程发生异常的待处理数据。按照该存储地址，即可在预设数据库中查询到以二进制形式存储的待处理数据。

步骤S353，按照所述待处理数据的预设处理需求，对所述待处理数据进行分析，得到分析结果。

在一些实施例中，通过存储地址从预设数据库中获取到原始的待处理数据之后，对待处理数据进行再次分析，以实现预设处理需求，得到分析结果。比如，待处理数据为人脸图像，预设处理需求为识别人脸的身份信息，那么按照识别人脸的身份信息的实现流程，对待处理数据进行处理，得到分析结果。

步骤S354，基于所述分析结果，定位并处理所述处理过程发生异常的异常问题。

在一些实施例中，按照待处理数据的预设处理需求，对待处理数据进行再次分析，使得分析结果更加准确。在一些可能的实现方式中，分析结果中包括按照预设处理需求对待处理数据进行分析的整个处理过程的输出数据、中间数据以及处理过程中的处理参数，所以通过分析结果能够定位处理过程发生异常的异常问题，并且按照分析结果中关于异常问题出现的原因，能够解决该异常问题。

在本申请实施例中，如果目标日志信息的异常原因不足以定位到异常问题，或者是用户需要查询发生异常的原始数据即待处理数据，而输入数据查询指令，那么可以在目标日志信息中调出待处理数据的存储地址；这样，能够按照该存储地址，精准地在预设数据库中查询到待处理数据；从而系统前端能够按照待处理数据的预设处理需求对待处理数据进行再次分析；进而按照再次分析的结果，定位并处理异常问题，能够使得定位的异常问题更加可信，满足用户需求。

下面，将说明本申请实施例在一个实际的应用场景中的示例性应用，以针流式分布式处理系统的数据链路，定位该系统中的异常数据为例，进行说明。

对于大数据量的数据密集型应用系统，提供服务的微服务组件非常多，这时候如果需要了解整个系统的运行情况，就依赖于分布式系统的可观测性三大支柱：指标(metrics)、追踪(tracing)、日志(logs)。其中，每个支柱代表一种纬度，指标相当于是数据概览，展现一些对象当前的瞬时值，代表的开源产品为普罗米修斯(Prometheus)；指标相当于是事务级别的追踪，将一次事务中关联的各个组件的处理串联起来，代表开源框架为开放遥测(Open Telemetry)；日志即为事务产生的日志，打印系统的情况，收集日志用于分析数据。如此，虽然能够解决每个纬度内的问题，但是对于业务来说，需要组合多个纬度，进行合理的组合分析；基于此，本申请实施例就提出了一种根据指标并结合日志、追踪和存储系统进行数据链路治理的方法。

在一些实施例中，首先，通过指标信息记录丢失数据的原因、指标；然后，把有问题的二进制分析数据记录到一个第三方存储中，得到一个失败二进制的URL；最后，将处理失败的二进制数据URL记录到日志以及追踪路径中，并通过原因、设备ID等，让用户能较为方便的从指标信息暴露的数据异常原因中，找到失败的二进制数据、以及出现问题的详细原因。上述过程可以通过以下步骤实现：

第一步，在流式处理系统中，数据会经过一系列的处理组件。

如图4A所示，图4A为本申请实施例提供的数据处理方法的系统架构示意图，结合图4A进行以下说明：

首先，将输入数据41(对应于上述实施例中的待处理数据)输入到组件A进行数据处理，若组件A处理失败，生成组件A处理失败的日志；若组件A处理成功，将组件A处理后的中间数据42输入到组件B。

这里，组件A处理失败的日志411包括：A组件的设备、数据补丁和处理失败原因。在组件A处理失败的情况下，将输入数据存储在二进制存储服务401中，并将组件A处理失败的日志存储在日志402中。

然后，组件B对中间数据42进行再次处理，若组件B处理失败，生成组B处理失败的日志412；若组件B处理成功，将组件B处理后的中间数据43输入到组件C。

最后，组件C对中间数据进行再次处理，若组件C处理失败，生成组C处理失败的日志；若组件C处理成功，得到输出数据44。

在一些实施例中，数据在任一组件的处理流程如图4B所示，图4B为本申请实施例提供的数据处理的实现框架示意图，其中，原始数据420(对应于上述实施例中的待处理数据)输入到组件A421中进行处理数据，如果组件A 421处理成功，则输出中间数据422以及处理过程的日志423，这时日志423中包括的条目有：设备ID、追踪ID、路径ID、概要原因、垃圾数据URL、详细原因等。如果组件A421处理失败，则生成A_处理_失败426、废品库424和指标服务器425；这时日志423包括：设备ID、路径ID、详细原因、废品库URL以及失败信息等；废品库424包括：设备ID、概要原因、二进制数据等；指标存储在指标服务器425中，组件A处理过程失败的A_处理_失败426，包括：设备ID、补丁、原因等。在组件A421处理失败的情况下，将原始数据420转换为二进制数据存储在数据服务器427中。

第二步，在丢弃输入数据的同时，写入一个二进制存储服务，得到这段被丢弃数据的URL，用于后续具体分析。这些失败二进制可能数据量较大，所以会通过限制写入速度的方法，减少系统资源存储占用。

第三步，在丢弃处理失败的输入数据的同时要写日志，日志中需要包含设备ID、概要原因、详细原因、输入数据的URL等，方便定位的信息。这些日志会被定期采集到一个日志服务器中集中存储。

第四步，每个组件在遇到处理失败，需要丢弃输入数据时，均写入一条指标，这些指标会被指标服务器定时抓取存储下来。指标中的标签需要包含概要原因，设备ID等，用于和日志大致关联起来。

上述第二步至第四步，如图5所示，图5为本申请实施例提供的数据处理方法的实现流程示意图，结合图5进行以下说明：

步骤S501，按照处理流程对输入数据进行处理。

步骤S502，判断是否对输入数据处理失败。

这里，如果在该处理流程中任一组件对输入数据处理失败，那么进入步骤S503，若处理成功则直接输出处理结果，进入步骤S506，结束整个流程。

步骤S503，将输入数据存储在二进制服务中。

这里，通过抽样式存储该输入数据至二进制服务，以得到该输入数据的URL。

步骤S504，在丢弃输入数据的同时，写处理该输入数据的日志。

这里，可以采用logfmt格式写该输入数据处理失败的日志，包括：设备ID、处理失败的详细原因、概要原因等。

步骤S505，写该输入数据处理失败的指标。

这里，在指标和日志中均包括输入数据处理失败的概要原因和设备ID等，以便于日志和指标能够大致关联起来。

步骤S506，结束整个流程。

第五步，通过以上步骤准备好数据之后，可进行问题检查。

在一些实施例中，检查问题的步骤如下：

第六步，通过查看指标，确定异常点。

这里，异常点包括处理失败的输入数据和处理失败的组件。

第七步，从指标中确定概要原因、异常时间、设备ID等字段，在日志服务器中查找到该输入数据的相关日志，如果日志中的信息充足，基于该日志解决数据处理失败的问题。

第八步，如果日志中的信息不能定位出数据处理的问题，或用户认为日志不够信服，可以根据日志中的URL，找到原始的输入数据再次分析。

上述第六步至第七步可以通过如图6所示的步骤实现，图6为本申请实施例提供的数据处理方法的另一实现流程示意图，结合图6进行以下说明：

步骤S601，获取处理失败的输入数据的指标。

步骤S602，判断指标中的异常点。

这里，如果识别出指标中的异常点，进入步骤S603，如果指标中不包括异常点进入步骤S607，并结束整个流程。

步骤S603，按照该异常点，查找相关日志。

步骤S604，判断日志中的信息是否充足。

这里，如果日志中的信息充足，即日志中已经展示了数据处理失败的原因，可以用于数据修复定位，那么可无基于该日志解决数据处理失败的问题，进入步骤S607，并结束整个流程。如果日志中展示的数据处理失败的原因不足以定位问题，进入步骤S605。

步骤S605，根据日志中的URL，在二进制存储服务中查找处理失败的待处理数据。

步骤S606，基于待处理数据，分析数据处理失败的原因。

步骤S607，结束整个流程。

在一个具体例子中，在通过摄像头进行人脸图像采集的场景下，如图7所示，会接入大量的摄像头，比如，摄像头组71，包括3个摄像头。一方面，由于不同品牌的摄像头接入的协议不一样，采用格式转换模块72将各种不同的协议以及不同格式的数据转换成一种内部通用的格式。这一部分可能因为和第三方厂家沟通的原因，可能会出现转换失败的情况，这时候能通过指标和第三方厂家对账，发现有失败的数据，并通过失败图像的二进制存储数据，把解析失败的内容和第三方厂家进行沟通，而不是盲目的抓包然后分析，做大量的重复分析工作；另一方面，在内部解析数据的过程中，可能整个处理流程中有很多步骤(如图7中的处理管线73和处理管线74)，比如，监测对象、找出关键点、提取特征、提取属性、评分等，假如一张图片因为评分低丢掉，本申请实施例可以首先，根据指标观测到现象，然后再通过查看日志和原始图片，通过重新分析等方法，给客户一个合理的结果。

在本申请实施例中，在数据链路治理中，通过指标观测异常值，然后通过指标能找到日志定位具体失败原因，再通过日志能够找到处理失败的数据，从而能够对处理失败的数据进行精准分析。

本申请实施例提供一种数据处理装置，图8为本申请实施例提供的数据处理装置的结构组成示意图，如图8所示，所述数据处理装置800包括：

第一监测模块801，用于基于获取的待处理数据，监测所述待处理数据的处理过程；

第一生成模块802，用于响应于监测到所述待处理数据的处理过程发生异常，生成所述处理过程的日志信息和所述日志信息关联的指标信息；

第一告警模块803，用于基于所述日志信息和所述指标信息，生成并输出告警信息以提示对所述异常进行处理。

在一些实施例中，所述第一监测模块801，包括：

第一确定子模块，用于确定用于对所述待处理数据进行处理的组件和所述待处理数据的预设处理流程；

第一监测子模块，用于按照预设时长间隔，在所述预设处理流程中监测所述预设组件对所述待处理数据的处理过程。

在一些实施例中，所述装置还包括：

第一确定模块，用于在所述处理过程中，确定所述待处理数据的处理结果和所述处理过程的处理参数；

第二确定模块，用于在监测到所述处理结果或所述处理参数不满足所述待处理数据的预设处理需求的情况下，确定所述处理过程发生异常。

在一些实施例中，所述第一生成模块802，包括：

第二确定子模块，用于响应于监测到所述处理过程发生异常，确定所述处理过程对应的设备标识；

第三确定子模块，用于基于所述待处理数据的预设处理需求、所述处理过程的处理结果和所述处理过程的处理参数，确定所述处理过程发生异常的异常原因；

第四确定子模块，用于将所述处理过程对应的设备标识和所述异常原因，作为所述日志信息，并将所述日志信息存储至日志服务器。

在一些实施例中，所述装置还包括：

第三确定模块，用于确定所述待处理数据在预设数据库中的存储地址；

第一写入模块，用于将所述存储地址，写入所述日志信息。

在一些实施例中，所述装置还包括：

第一转换模块，用于响应于监测到所述处理过程发生异常，按照预设数据格式对所述待处理数据进行转换，得到已转换数据；

第一存储模块，用于将所述已转换数据，存储在所述预设数据库。

在一些实施例中，所述第三确定子模块，包括：

第一确定单元，用于分别确定所述处理结果和所述处理参数，与所述预设处理需求之间的差异信息；

基于所述差异信息，生成所述异常的详细原因；

第一生成单元，用于基于所述详细原因，确定所述异常的概要原因；

第二确定单元，用于将所述详细原因和所述概要原因，作为所述异常原因。

在一些实施例中，所述第一生成模块802，包括：

第一生成子模块，用于基于所述日志信息中的所述处理过程对应的设备标识和所述异常原因中的至少概要原因，生成指标标签；

第二生成子模块，用于基于监测到发生异常的时刻和所述指标标签，生成所述指标信息。

在一些实施例中，所述第一生成子模块，还用于在所述日志信息中的异常原因包括所述待处理数据的处理结果不满足所述预设处理需求的情况下，基于所述日志信息中的所述设备标识和所述待处理数据的处理结果，生成所述指标标签。

在一些实施例中，所述装置还包括：

第一统计模块，用于在所述处理过程所在的系统中，以上一次输出告警信息的时刻为起始时刻，统计所述处理过程所在的系统发生异常的次数；

所述第一告警模块，还用于：

在所述次数满足预设次数阈值的情况下，基于多次异常对应的日志信息和指标信息，生成并输出所述告警信息。

本申请实施例提供一种数据处理装置，图9为本申请实施例提供的数据处理装置的结构组成示意图，如图9所示，所述数据处理装置900包括：

第一获取模块901，用于响应于接收到表示待处理数据的处理过程发生异常的告警信息，获取所述处理过程的指标信息；

第四确定模块902，用于基于所述指标信息，确定所述处理过程发生异常的异常点；

第五确定模块903，用于在日志服务器中，确定与所述异常点匹配的目标日志信息；其中，所述日志服务器中包括多次异常对应的日志信息和指标信息；

第一处理模块904，用于基于所述目标日志信息，处理所述处理过程发生的异常。

在一些实施例中，所述指标信息中至少包括以下之一：所述处理过程发生异常的异常原因、所述处理过程对应的设备标识和指标标签的时间戳，所述装置还包括：

第二获取模块，用于获取所述处理过程对应的组件和预设处理流程；

所述第四确定模块902，包括：

第五确定子模块，用于基于所述异常原因、所述处理过程对应的设备标识和指标标签的时间戳中的至少之一，在所述组件和所述预设处理流程中，确定所述处理过程发生异常的位置信息；

第六确定子模块，用于将所述发生异常的位置信息，确定为所述异常点。

在一些实施例中，所述第一处理模块904，包括：

第一定位子模块，用于在所述目标日志信息包括的异常原因中，定位所述处理过程发生异常的异常问题；

第一处理子模块，用于响应于定位到所述异常问题，基于所述异常原因处理所述异常问题。

在一些实施例中，所述第一处理模块904，包括：

第七确定子模块，用于响应于在所述目标日志信息包括的异常原因中未定位到所述处理过程发生异常的异常问题，或接收到数据查询指令，在所述目标日志信息中确定所述待处理数据的存储地址；

第一查询子模块，用于基于所述存储地址，在预设数据库中查询所述待处理数据；其中，所述预设数据库用于存储处理过程发生异常的待处理数据；

第一分析子模块，用于按照所述待处理数据的预设处理需求，对所述待处理数据进行分析，得到分析结果；

第二定位子模块，用于基于所述分析结果，定位并处理所述处理过程发生异常的异常问题。

需要说明的是，以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述的数据处理网络的训练方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是终端、服务器等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、运动硬盘、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申请实施例不限制于任何特定的硬件和软件结合。

对应地，本申请实施例再提供一种计算机程序产品，所述计算机程序产品包括计算机可执行指令，该计算机可执行指令被执行后，能够实现本申请实施例提供的数据处理方法中的步骤。

相应的，本申请实施例再提供一种计算机存储介质，所述计算机存储介质上存储有计算机可执行指令，所述该计算机可执行指令被处理器执行时实现上述实施例提供的数据处理方法的步骤。

相应的，本申请实施例提供一种计算机设备，图10为本申请实施例计算机设备的组成结构示意图，如图10所示，所述计算机设备1000包括：一个处理器1001、至少一个通信总线、通信接口1002、至少一个外部通信接口和存储器1003。其中，通信接口1002配置为实现这些组件之间的连接通信。其中，通信接口1002可以包括显示屏，外部通信接口可以包括标准的有线接口和无线接口。其中所述处理器1001，配置为执行存储器中数据处理程序，以实现上述实施例提供的数据处理方法的步骤。

以上数据处理装置、计算机设备和存储介质实施例的描述，与上述方法实施例的描述是类似的，具有同相应方法实施例相似的技术描述和有益效果，限于篇幅，可案件上述方法实施例的记载，故在此不再赘述。对于本申请数据处理装置、计算机设备和存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列特征的过程、方法、物品或者装置不仅包括那些特征，而且还包括没有明确列出的其他特征，或者是还包括为这种过程、方法、物品或者装置所固有的特征。在没有更多限制的情况下，由语句“包括一个……”限定的特征，并不排除在包括该特征的过程、方法、物品或者装置中还存在另外的相同特征。

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

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (18)

1.一种数据处理方法，其特征在于，所述方法包括：

基于获取的待处理数据，监测所述待处理数据的处理过程；

响应于监测到所述待处理数据的处理过程发生异常，生成所述处理过程的日志信息和所述日志信息关联的指标信息；

基于所述日志信息和所述指标信息，生成并输出告警信息以提示对所述异常进行处理。

2.根据权利要求1所述的方法，其特征在于，所述基于获取的待处理数据，监测所述待处理数据的处理过程，包括：

确定用于对所述待处理数据进行处理的组件和所述待处理数据的预设处理流程；

按照预设时长间隔，在所述预设处理流程中监测所述预设组件对所述待处理数据的处理过程。

3.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：

在所述处理过程中，确定所述待处理数据的处理结果和所述处理过程的处理参数；

在监测到所述处理结果或所述处理参数不满足所述待处理数据的预设处理需求的情况下，确定所述处理过程发生异常。

4.根据权利要求1至3任一项所述的方法，其特征在于，所述响应于监测到所述待处理数据的处理过程发生异常，生成所述处理过程的日志信息，包括：

响应于监测到所述处理过程发生异常，确定所述处理过程对应的设备标识；

基于所述待处理数据的预设处理需求、所述处理过程的处理结果和所述处理过程的处理参数，确定所述处理过程发生异常的异常原因；

将所述处理过程对应的设备标识和所述异常原因，作为所述日志信息，并将所述日志信息存储至日志服务器。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

确定所述待处理数据在预设数据库中的存储地址；

将所述存储地址，写入所述日志信息。

6.根据权利要求5所述的方法，其特征在于，所述确定所述待处理数据在预设数据库中的存储地址之前，所述方法还包括：

响应于监测到所述处理过程发生异常，按照预设数据格式对所述待处理数据进行转换，得到已转换数据；

将所述已转换数据，存储在所述预设数据库。

7.根据权利要求4至6任一项所述的方法，其特征在于，所述基于所述待处理数据的预设处理需求、所述处理过程的处理结果和所述处理过程的处理参数，确定所述处理过程发生异常的异常原因，包括：

分别确定所述处理结果和所述处理参数，与所述预设处理需求之间的差异信息；

基于所述差异信息，生成所述异常的详细原因；

基于所述详细原因，确定所述异常的概要原因；

将所述详细原因和所述概要原因，作为所述异常原因。

8.根据权利要求4至7任一项所述的方法，其特征在于，所述响应于监测到所述待处理数据的处理过程发生异常，生成所述日志信息关联的指标信息，包括：

基于所述日志信息中的所述处理过程对应的设备标识和所述异常原因中的至少概要原因，生成指标标签；

基于监测到发生异常的时刻和所述指标标签，生成所述指标信息。

9.根据权利要求8所述的方法，其特征在于，所述基于所述日志信息中的所述处理过程对应的设备标识和所述异常原因中的至少概要原因，生成指标标签，包括：

在所述日志信息中的异常原因包括所述待处理数据的处理结果不满足所述预设处理需求的情况下，基于所述日志信息中的所述设备标识和所述待处理数据的处理结果，生成所述指标标签。

10.根据权利要求1至9任一项所述的方法，其特征在于，所述基于所述日志信息和所述指标信息，生成并输出告警信息以提示对所述异常进行处理之前，所述方法还包括：

在所述处理过程所在的系统中，以上一次输出告警信息的时刻为起始时刻，统计所述处理过程所在的系统发生异常的次数；

所述基于所述日志信息和所述指标信息，生成并输出告警信息以提示对所述异常进行处理，包括：

在所述次数满足预设次数阈值的情况下，基于多次异常对应的日志信息和指标信息，生成并输出所述告警信息。

11.一种数据处理方法，其特征在于，所述方法包括：

响应于接收到表示待处理数据的处理过程发生异常的告警信息，获取所述处理过程的指标信息；

基于所述指标信息，确定所述处理过程发生异常的异常点；

在日志服务器中，确定与所述异常点匹配的目标日志信息；其中，所述日志服务器中包括多次异常对应的日志信息和指标信息；

基于所述目标日志信息，处理所述处理过程发生的异常。

12.根据权利要求11所述的方法，其特征在于，所述指标信息中至少包括以下之一：所述处理过程发生异常的异常原因、所述处理过程对应的设备标识和指标标签的时间戳，所述基于所述指标信息，确定所述处理过程发生异常的异常点之前，所述方法还包括：

获取所述处理过程对应的组件和预设处理流程；

所述基于所述指标信息，确定所述处理过程发生异常的异常点，包括：

基于所述异常原因、所述处理过程对应的设备标识和指标标签的时间戳中的至少之一，在所述组件和所述预设处理流程中，确定所述处理过程发生异常的位置信息；

将所述发生异常的位置信息，确定为所述异常点。

13.根据权利要求11所述的方法，其特征在于，所述基于所述目标日志信息，处理所述处理过程发生的异常，包括：

在所述目标日志信息包括的异常原因中，定位所述处理过程发生异常的异常问题；

响应于定位到所述异常问题，基于所述异常原因处理所述异常问题。

14.根据权利要求11所述的方法，其特征在于，所述基于所述目标日志信息，处理所述处理过程发生的异常，包括：

响应于在所述目标日志信息包括的异常原因中未定位到所述处理过程发生异常的异常问题，或接收到数据查询指令，在所述目标日志信息中确定所述待处理数据的存储地址；

基于所述存储地址，在预设数据库中查询所述待处理数据；其中，所述预设数据库用于存储处理过程发生异常的待处理数据；

按照所述待处理数据的预设处理需求，对所述待处理数据进行分析，得到分析结果；

基于所述分析结果，定位并处理所述处理过程发生异常的异常问题。

15.一种数据处理装置，其特征在于，所述装置包括：

第一监测模块，用于基于获取的待处理数据，监测所述待处理数据的处理过程；

第一生成模块，用于响应于监测到所述待处理数据的处理过程发生异常，生成所述处理过程的日志信息和所述日志信息关联的指标信息；

第一告警模块，用于基于所述日志信息和所述指标信息，生成并输出告警信息以提示对所述异常进行处理。

16.一种数据处理装置，其特征在于，所述装置包括：

第一获取模块，用于响应于接收到表示待处理数据的处理过程发生异常的告警信息，获取所述处理过程的指标信息；

第四确定模块，用于基于所述指标信息，确定所述处理过程发生异常的异常点；

第五确定模块，用于在日志服务器中，确定与所述异常点匹配的目标日志信息；其中，所述日志服务器中包括多次异常对应的日志信息和指标信息；

第一处理模块，用于基于所述目标日志信息，处理所述处理过程发生的异常。

17.一种计算机存储介质，其特征在于，所述计算机存储介质上存储有计算机可执行指令，该计算机可执行指令被执行后能够实现权利要求1至10任一项所述的方法步骤，或，该计算机可执行指令被执行后能够实现权利要求11至14任一项所述的方法步骤。

18.一种电子设备，其特征在于，所述电子设备包括存储器和处理器，所述存储器上存储有计算机可执行指令，所述处理器运行所述存储器上的计算机可执行指令时能够实现权利要求1至10任一项所述的方法步骤，或，所述处理器运行所述存储器上的计算机可执行指令时能够实现权利要求11至14任一项所述的方法步骤。

Images