数据处理方法、装置、电子设备和存储介质

技术领域

本申请涉及数据处理技术领域，尤其涉及一种数据处理方法、装置、电子设备和存储介质。

背景技术

手机转账、支付，柜台存取款等，是用户生活中常见的交易。相应的，服务器中可以存储用户每笔转账、支付、存取款对应的表单，表单上可以记录用户交易的时间、账号等。服务器需要对其中存储的海量的交易数据进行分析和管控，以及时管控异常数据。

目前，针对一种类型的交易数据，工作人员需要开发和编写针对该类型的交易数据的异常检测流程，异常检测流程中包括多个处理算子，每个处理算子部署在不同的设备中。在处理该类型的交易数据时，需要按照处理算子的顺序依次在不同的设备中，采用对应的处理算子处理该交易数据，最后得到该交易数据是否异常的结果。

目前交易数据处理方法的开发周期长，且数据处理的效率低。

发明内容

本申请提供一种数据处理方法、装置、电子设备和存储介质，可以提高数据的处理效率。

本申请的第一方面提供一种数据处理方法，应用于服务器集群中的目标服务器，该方法包括：获取目标数据，所述目标数据来自于所述服务器集群的中心服务器或终端设备；根据所述目标数据的业务类型，在所述目标数据中获取与所述业务类型相关的待处理数据；采用所述业务类型对应的数据异常处理流程，处理所述待处理数据，得到所述目标数据是否异常的结果；输出所述结果。

在一种可能的实现方式中，业务类型与待处理数据的属性具有第一映射关系，所述根据所述目标数据的业务类型，在所述目标数据中获取与所述业务类型相关的待处理数据，包括：根据所述目标数据的业务类型，以及所述第一映射关系，获取目标属性；在所述目标数据中，将所述目标属性对应的数据作为所述待处理数据。

在一种可能的实现方式中，所述业务类型对应的数据异常处理流程包括：获取所述目标数据之前的预设时间段内与所述目标数据关联的历史数据，所述目标数据和所述历史数据关联同一用户；结合所述历史数据的业务类型，识别所述待处理数据是否落入异常数据的范围。

在一种可能的实现方式中，所述目标服务器中包括：至少一个业务类型的标识和数据异常处理流程的标识的第二映射关系，所述方法还包括：根据所述目标数据的业务类型，以及所述第二映射关系，获取所述业务类型对应的数据异常处理流程。

在一种可能的实现方式中，若所述目标数据来自预设设备，所述目标数据包括至少一个表单，所述获取目标数据之后，还包括：根据每个表单的业务类型，删除业务类型为预设业务类型的表单。

在一种可能的实现方式中，所述业务类型对应的数据异常处理流程为处理函数，所述目标服务器中包括：第一容器，所述第一容器中设置有第二容器，所述第二容器中包含所述处理函数；所述获取目标数据之后，还包括：将所述目标数据加载至任务队列。

所述根据所述目标数据的业务类型，以及所述第一映射关系，获取目标属性之前，包括：在第一容器中，读取所述任务队列中的所述目标数据；在数据库中读取所述第一映射关系。

所述采用所述业务类型对应的数据异常处理流程，处理所述待处理数据之前，包括：在所述第二容器中调用所述处理函数。

所述采用所述业务类型对应的数据异常处理流程，处理所述待处理数据，包括：在所述第二容器中，运行所述处理函数，以处理所述待处理数据。

在一种可能的实现方式中，所述第一容器为flink容器，所述第二容器为springboot容器，所述数据库为redis数据库，所述处理函数为bean函数；所述在数据库中读取所述第一映射关系，包括：通过所述flink容器访问所述数据库的访问端口，以读取所述第一映射关系。

在一种可能的实现方式中，所述方法还包括：在所述flink容器中加载所述springboot容器；调用所述flink容器中flink函数的方法，加载所述bean函数至所述springboot容器。

本申请的第二方面提供一种数据处理装置，包括：

数据解析模块，用于获取目标数据，所述目标数据来自于所述服务器集群的中心服务器或终端设备。

规则分析模块，用于根据目标数据的业务类型，在目标数据中获取与业务类型相关的待处理数据；采用业务类型对应的数据异常处理流程，处理待处理数据，得到目标数据是否异常的结果；输出结果。

在一种可能的实现方式中，业务类型与待处理数据的属性具有第一映射关系。规则分析模块，具体用于根据目标数据的业务类型，以及第一映射关系，获取目标属性；在目标数据中，将目标属性对应的数据作为待处理数据。

在一种可能的实现方式中，业务类型对应的数据异常处理流程包括：获取目标数据之前的预设时间段内与目标数据关联的历史数据，目标数据和历史数据关联同一用户；结合历史数据的业务类型，识别待处理数据是否落入异常数据的范围。

在一种可能的实现方式中，目标服务器中包括：至少一个业务类型的标识和数据异常处理流程的标识的第二映射关系。规则分析模块，还用于根据目标数据的业务类型，以及第二映射关系，获取业务类型对应的数据异常处理流程。

在一种可能的实现方式中，若目标数据来自预设设备，目标数据包括至少一个表单。规则分析模块，还用于根据每个表单的业务类型，删除业务类型为预设业务类型的表单。

在一种可能的实现方式中，业务类型对应的数据异常处理流程为处理函数，目标服务器中包括：第一容器，第一容器中设置有第二容器，第二容器中包含处理函数。规则分析模块，还用于将目标数据加载至任务队列；在第一容器中，读取任务队列中的目标数据；在数据库中读取第一映射关系；在第二容器中调用处理函数。

规则分析模块，具体用于在第二容器中，运行处理函数，以处理待处理数据。

在一种可能的实现方式中，第一容器为flink容器，第二容器为springboot容器，数据库为redis数据库，处理函数为bean函数。规则分析模块，具体用于通过所述flink容器访问数据库的访问端口，以读取第一映射关系。

在一种可能的实现方式中，规则分析模块，还用于在flink容器中加载springboot容器，以及调用flink容器中flink函数的方法，加载bean函数至springboot容器。

本申请的第三方面提供一种电子设备，包括：至少一个处理器和存储器；所述存储器存储计算机执行指令；所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述电子设备执行上述数据处理方法。

本申请的第四方面提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机执行指令，当所述计算机执行指令被处理器执行时，实现上述数据处理方法。

本申请的第五方面提供一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面或第一方面的各种可能的实现方式中的方法。

本申请提供一种数据处理方法、装置、电子设备和存储介质，目标服务器中可以预先设置有不同业务类型对应的数据异常处理流程，进而在目标服务器接收到来自服务器集群的中心服务器或终端设备的目标数据时，可以基于目标数据的业务类型，采用对应的数据异常处理流程处理待处理数据，以得到该目标数据是否异常的结果。一方面，无需在多个设备中部署多个处理算子，节约了设备资源，提高了数据处理效率，另一方面，服务器中预先部署数据异常处理流程，可以针对不同业务类型的数据进行异常识别，进一步可以提高数据处理效率。另外，在对目标数据进行处理时，可以先在目标数据中获取与该目标数据的业务类型相关的待处理数据，进而基于该待处理数据，得到目标数据是否异常的结果，可以减少目标服务器处理的数据量，同样也可以提高处理处理效率。

附图说明

图1为已有的数据处理适用的一种系统架构示意图；

图2A为本申请实施例提供的数据处理适用的一种系统架构示意图；

图2B为本申请实施例提供的数据处理适用的另一种系统架构示意图；

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

图4为本申请实施例提供的目标服务器的一种结构示意图；

图5为本申请实施例提供的目标服务器的另一种结构示意图；

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

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

图7为本申请提供的数据处理装置的结构示意图；

图8为本申请提供的电子设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请的实施例，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的术语释义：

海量数据：vast data或者large-scale data，规模很大、数量很大的数据。

实时分析：指对数据进行实时监控分析。

规则引擎：规则引擎由推理引擎发展而来，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。

spring boot框架：其实就是一个整合很多可插拔的组件的框架，内嵌了使用工具(比如内嵌了Tomcat、Jetty等)，方便开发人员快速搭建和开发框架。

flink框架：Apache Flink是由Apache软件基金会开发的开源流处理框架，其核心是用Java和Scala编写的分布式流数据流引擎。flink以数据并行和流水线方式执行任意流数据程序，flink的流水线运行时系统可以执行批处理和流处理程序。

xml：可扩展语音标记(extensible markup language)，是一种用于标记电子文件使其具有结构性的标记语言。

json：全称为Javascript object notation，是一种轻量级的数据交换格式，其采用完全独立于编程语言的文本格式来存储和表示数据。

用户使用终端设备(如手机)转账时，终端设备可以将转账对应的表单上传至服务器，转账对应的表单上可以记录有转账时间、转账账号、转账金额、收款人的账号等。用户在银行柜台存款，银行的工作人员可以通过终端设备(如台式计算机)将存款对应的表单上传至服务器，存款的表单中可以记录有存款时间、存款金额、存款账户等。如此，服务器中可以存储有用户每笔转账、支付、存取款对应的表单，服务器需要对其中存储的海量交易数据进行分析和管控，以及时管控异常数据。示例性的，如用户转账超过预设金额，则该笔转账可能存在风险异常，则可以及时提醒工作人员对该笔转账的账号进行监控，以避免风险。

图1为已有的数据处理适用的一种系统架构示意图。目前，针对一种业务类型的交易数据，工作人员需要开发和编写针对该业务类型的交易数据的异常检测流程，异常检测流程中包括多个处理算子，每个处理算子部署在不同的设备中。在处理该业务类型的交易数据时，需要按照处理算子的顺序依次在不同的设备中，采用对应的处理算子处理该交易数据，最后得到该交易数据是否异常的结果。

示例性的，针对转账业务类型的交易数据，参照图1，该系统架构中包括2个处理设备，每个处理设备中包括一个处理算子。应理解，处理算子可以理解为对交易数据的一个处理流程，如2个设备中的设备A对交易数据中的金额与预设金额进行差值计算，得到差值，设备A向设备B发送该差值和交易数据的标识。设备B基于该差值，以及差值与异常因子的映射关系，得到差值的异常值，若该异常值大于阈值，则设备B输出交易数据异常的结果。

目前的数据处理方法中，设备A和设备B只能针对转账业务类型的交易数据进行处理，若针对存款业务类型的交易数据，工作人员还需开发另外一套异常检测流程，且将该异常检测流程的处理算子部署在不同的设备(如设备C和设备D)中。开发周期长，进而造成数据处理的效率低。应理解，图1中并未示出设备C和设备D的处理算子。

因为目前对交易数据的处理，需要在多个设备中部署处理算子，因此为了减少设备资源的浪费，以及提高数据的处理效率，本申请在一个服务器中部署交易类型的数据异常处理流程。另外，目前的多个设备只能处理一种类型的交易数据，为了进一步提高数据的处理效率，本申请在该一个服务器中部署针对不同业务类型的数据的数据异常处理流程，进而服务器可以对进入服务器中的不同业务类型的数据进行异常识别。

在介绍本申请提供的数据处理方法之前，先对本申请适用的系统架构进行说明。在一种实施例中，执行数据处理的方法的服务器可以为单独部署的服务器，也可以为服务器集群中的一个服务器。以执行数据处理的方法的服务器为服务器集群中的一个服务器为例进行说明。参照图2A，该系统架构中可以包括服务器集群，该服务器集群中包括多个服务器，图2A中以服务器集群中包括3个服务器为例进行说明。

在一种实施例中，服务器集群中可以包括一中心服务器，如服务器1，该中心服务器用于接收来自终端设备上传的数据，且根据服务器集群中其他服务器(服务器2和服务器3)的负载和可用资源，向负载小或可用资源多的服务器(如服务器2)发送数据，使得该服务器2处理该数据。应理解，执行数据处理的方法的服务器可以为服务器2和服务器3。在一种实施例中，服务器1接收到来自终端设备的数据时，服务器1也可以处理数据。

参照图2B，在一种实施例中，终端设备可以向服务器集群中的任一个服务器发送数据，接收到来自终端设备的数据的服务器可以处理数据。

在一种实施例中，可以基于hadoop架构构建服务器集群。在每个服务器中部署flink流计算框架，该flink流计算框架用于实现海量数据复杂分析时所需的资源的平衡和横向扩展。示例性的，中心服务器可以采用该flink流计算框架向负载小或可用资源多的服务器发送数据，服务器集群中的其他服务器可以基于该flink流计算框架，调度服务器中可用的资源。

其中，本申请实施例中可以在flink流计算框架中可以集成springboot框架，在springboot框架中固化规则引擎。规则引擎，用于对不同业务类型的数据进行异常识别。在一种实施例中，规则引擎可以称为数据异常处理流程或处理函数(如bean函数)，可以参照下述实施例的相关描述。在一种实施例中，flink流计算框架可以替换为其他类型的流计算架构(比如storm)，springboot框架可以替换为其他的开源规则引擎，如drools。

其中，在flink流计算框架中可以集成springboot框架，可以理解为：在服务器的flink容器中加载springboot容器，达到使用spring框架提供的各个组件的目的。应注意的是，当在flink容器中加载springboot容器时，可以在flink的算子函数的open()方法中实现spring框架的初始化，spring框架的初始化可以理解为：加载数据库，以及加载数据库的访问密码和访问端口，加载规则引擎至springboot容器中。应理解，数据库中存储有不同数据的业务类型对应的规则，可以参照下述实施例的相关描述。在一种实施例中，规则引擎可以以处理函数(如bean函数)的形式存在，上述加载规则引擎至springboot容器中可以理解为：加载bean函数至所述springboot容器。在一种实施例中，flink容器可以称为第一容器，springboot容器可以称为第二容器。在一种实施例中，数据库可以但不限于为redis数据库。在一种实施例中，服务器可以通过flink容器访问数据库的访问端口，以读取数据库中的不同数据的业务类型对应的规则。

在一种实施例中，服务器中还可以包括：类决策树，该类决策树可以理解为使用规则模型的主体，即调用bean函数的执行主体。类决策树的流程一部分存在于规则组件的java语言实现的逻辑判断中，更多的部分定义在数据库的表中，类决策树执行时可以去数据库中读取不同数据的业务类型对应的规则，然后去springboot容器中动态调用实现实体类，即各种实例化的bean函数来完成规则引擎的执行。下述实施例中以调用bean函数的执行主体为服务器(或者服务器中的第一规则分析模块或第二规则分析模块或规则分析模块)为例进行说明，可以参照下述实施例的相关说明。

其中，一个业务类型的数据的对应的数据异常处理流程，对应一个bean函数，服务器可以基于数据的业务类型，调用与该业务类型对应的bean函数处理数据，即采用与该类型对应的数据异常处理流程，处理所述待处理数据。

本申请实施例中，一方面，基于hadoop框架的flink流计算框架，可以实时对服务器中海量的数据进行分析，提高数据处理的及时性和可靠性，且还可以基于待处理的数据量，动态调配服务器集群的资源。另一方面，本申请实施例在springboot框架中固化规则引擎可以对不同业务类型的数据进行异常识别。再一方面，本申请实施例中的处理方法是基于springboot框架，和现有业务的java开发体系兼容，所以原来的数据持久化的业务对象可以拷贝代码或者引用java依赖的方式直接复用。

应理解的是，如上采用用户的交易数据为例进行说明，本申请提供的数据处理方法可以应用在不同的技术领域中，数据可以但不限于为：交易数据、人口数据、年龄数据、收入数据等。在一种实施例中，目标服务器处理的数据均为结构化数据。

下面结合具体的实施例对本申请实施例提供的数据处理方法进行说明。下面这几个实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。图3为本申请实施例提供的数据处理方法的一种实施例的流程示意图。参照图3，本申请实施例提供的数据处理方法包括：

S301，获取目标数据，目标数据来自服务器集群的中心服务器或终端设备。

终端设备上传目标数据至服务器集群时，终端设备可以向中心服务器上传目标数据，或者服务器集群中除了中心服务器之外的其他服务器上传数据。其中，当中心服务器接收来自终端设备的数据时，中心服务器可以自己处理数据，或者将数据发送给其他服务器进行处理。终端设备可以但不限于包括：用户的手机、银行柜台的计算机设备、自动取款机(automated teller machine，ATM)等。

下述以中心服务器将来自终端设备的数据发送给其他服务器处理为例进行说明。中心服务器可以基于服务器集群中服务器的负载和可用资源等，确定目标服务器，目标服务器为即将处理终端设备上传的目标数据的服务器。示例性的，中心服务器可以将负载小于预设负载，且可用资源大于预设资源的服务器作为目标服务器。在一种实施例中，因为服务器集群中每个服务器中集成flink流计算框架，中心服务器可以基于flink流计算框架，来平衡服务器集群中的服务器的资源，flink流计算框架平衡资源的具体方式可以参照现有技术中的相关描述。中心服务器可以向目标服务器发送来自终端设备的目标数据，相应的，目标服务器可以接收来自服务器集群的中心服务器的目标数据。

在一种实施例中，数据可以但不限于为表单、文本等，下述实施例中以数据为表单为例进行说明。在一种实施例中，目标数据中可以包括至少一个表单，每个表单的业务类型(即目标数据的业务类型)可以相同或不同。示例性的，目标数据可以为两个表单，一个表单为用户转账的表单，另一个表单为用户存款的表单，应理解，该两个表单可以来自用户的手机。或者，目标数据为批量的表单，该批量的表单为不同的用户转账的表单，即该批量的表单的业务类型相同。应理解，该批量的表单可以来自银行柜台的终端设备。

S302，根据目标数据的业务类型，在目标数据中获取与业务类型相关的待处理数据。

以交易数据为例，业务类型可以包括但不限于为：转账、支付、存款、取款、修改密码等。在一种实施例中，目标数据可以有对应的业务类型的标识。示例性的，如目标数据为表单，表单的编号(也可以为表单流水号)可以依据业务的类型进行编号。如表单为A1x，该表单以A开头，表征该表单为转账业务类型的表单，如表单为B1x，该表单以B开头，表征该表单为支付业务类型的表单。示例性的，如表单中可以包括业务类型的标识，如用户在手机上填写转账表单时，可以勾选对应的业务类型(转账)。如此，表单的标识(如表单的编号)或者表单中的内容均可以指示表单的业务类型。可以想到的，目标服务器接收到目标数据后，可以基于目标数据指示的业务类型，确定目标数据的业务类型。

不同业务类型的目标数据，用于判断目标数据是否异常的数据也不同。示例性的，对于转账业务来说，转账金额、转账的账号，以及收款人的账号可以为判断目标数据是否异常所需的数据。示例性的，对于取款业务来说，取款金额可以为判断目标数据是否异常所需的数据。

目标服务器中预先可以存储有每个业务类型对应的判断目标数据是否异常的数据。据此，目标服务器可以基于来自目标数据的业务类型，以及每个业务类型对应的判断目标数据是否异常的数据，在目标数据中获取待处理数据。示例性的，目标数据为转账业务的数据，则可以在目标数据中将转账金额、转账的账号，以及收款人的账号作为待处理数据。

在一种实施例中，目标数据中包括不同业务类型的表单时，服务器可以基于每个表单的业务类型，在表单中获取待处理数据。示例性的，如目标数据中包括转账业务的表单，以及取款业务的表单，目标服务器可以在转账业务的表单中将转账金额、转账的账号，以及收款人的账号作为待处理数据，在取款业务的表单将取款金额作为待处理数据。在一种实施例中，目标数据中包括批量的相同业务类型的表单时，服务器可以基于该相同的业务类型，在每个表单中获取待处理数据。如该批量的表单的业务类型为转账业务，则目标服务器可以将每个表单中的转账金额、转账的账号，以及收款人的账号作为每个表单的待处理数据。

S303，采用业务类型对应的数据异常处理流程，处理待处理数据，得到目标数据是否异常的结果。

业务类型不同，数据异常处理流程不同。在一种实施例中，目标服务器中预先可以存储有每个业务类型对应的数据异常处理流程。据此，目标服务器可以基于目标数据的业务类型，以及每个业务类型对应的数据异常处理流程，处理待处理数据，得到目标数据是否异常的结果。

示例性的，对于转账业务来说，转账业务对应的数据异常处理流程包括：判断转账金额是否大于预设金额，且判断收款人的账号是否为转账的账号常用的收款人的账号。若转账金额大于预设金额，且判断收款人的账号不为转账的账号常用的收款人的账号，则可以确定该目标数据异常。若转账金额小于或等于预设金额，或者判断收款人的账号为转账的账号常用的收款人的账号，则可以确定该目标数据正常。

示例性的，目标服务器中可以存储每笔交易的数据。目标服务器可以采用文字识别技术，识别表单中的转账金额、收款人的账号，以及转账的账号，且在目标服务器中查询与该转账的账号进行交易的收款人的账号，进而判断转账金额是否大于预设金额，且判断收款人的账号是否为转账的账号常用的收款人的账号。应理解，转账的账号常用的收款人的账号可以理解为：转账的账号与收款人的账号之间的交易次数大于预设次数，如预设次数可以为2。

如预设金额为100w，目标数据为表单，若目标服务器基于转账业务对应的数据异常处理流程，检测到表单中的转账金额为200w，大于该预设金额，且收款人的账号是与该转账的账号第一次进行交易的账号，目标服务器可以确定该目标数据异常。

S304，输出结果。

在一种实施例中，服务器上集成有显示模块，服务器可以显示目标数据是否异常的结果。其中，为了便于提示工作人员有异常的数据存在，当目标数据异常时，可以显示异常的目标数据的标识。示例性的，如服务器可以显示数据异常的表单的编号。

在一种实施例中，当目标数据为批量的业务类型相同的表单时，目标服务器在获取每个表单是否异常的结果后，可以统计异常表单在该批量表单中的概率，进而也在输出异常表单的编号的同时，输出该概率，可以使得工作人员及时了解该批量表单中的异常概率。

在一种实施例中，目标服务器可以向显示设备(如银行柜台的计算机或用户的终端设备)发送该目标数据是否异常的结果，以使显示设备显示该目标数据是否异常的结果。在一种实施例中，当目标数据异常时，目标服务器可以向可以显示设备发送目标数据的标识，使得显示设备显示异常的目标数据的标识。

在一种实施例中，目标服务器可以输出xml格式或json格式的结果，本申请实施例中对结果的输出格式不做限制。

本申请实施例提供一种数据处理方法包括：接收来自服务器集群的中心服务器或终端设备的目标数据；根据目标数据的业务类型，在目标数据中获取与业务类型相关的待处理数据；采用业务类型对应的数据异常处理流程，处理待处理数据，得到目标数据是否异常的结果；输出结果。本申请实施例中，目标服务器中可以预先设置有不同业务类型对应的数据异常处理流程，进而在目标服务器接收到目标数据时，可以基于目标数据的业务类型，采用对应的数据异常处理流程处理待处理数据，以得到该目标数据是否异常的结果。一方面，无需在多个设备中部署多个处理算子，节约了设备资源，提高了数据处理效率，另一方面，服务器中预先部署数据异常处理流程，可以针对不同业务类型的数据进行异常识别，进一步可以提高数据处理效率。另外，在对目标数据进行处理时，可以先在目标数据中获取与该目标数据的业务类型相关的待处理数据，进而基于该待处理数据，得到目标数据是否异常的结果，可以减少目标服务器处理的数据量，同样也可以提高处理处理效率。

在一种实施例中，目标服务器中存储有不同的业务类型对应的数据异常处理流程，数据异常处理流程为处理函数，即数据异常处理流程以处理函数的形式存在。目标服务器中包括：第一容器，第一容器中设置有第二容器，第二容器中包含处理函数。

图4为本申请实施例提供的目标服务器的一种结构示意图。参照图4，目标服务器中可以包括：数据解析模块和第一规则分析模块。

数据解析模块，用于获取目标数据，即可以理解为数据解析模块用于执行如下步骤：1、kafka读取；2、byte转string；3、交易筛选；4、json总线生成；5、交易转发；6、kafka写入。

在一种实施例中，目标数据可以为不同业务类型的多个表单，若该多个表单来自预设设备(如用户的终端设备发送的)，则目标服务器可以将该多个表单加载至boeing交易队列里。

1、kafka读取：即数据解析模块可以采用kafka的方式在boeing交易队列中读取该多个表单。

2、byte转string：即数据解析模块可以将该byte格式的多个表单转换成第一规则分析模块可以识别的string格式。

3、交易筛选：因为目标数据来自预设设备，数据解析模块在转换该多个表单的格式后，可以根据每个表单的业务类型，删除业务类型为预设业务类型的表单。应理解，预设业务类型为不具备异常数据的业务类型，示例性的，如业务类型为用户查询账号中的剩余金额，该业务类型本身不具备交易风险，即不具备异常数据，则目标服务器(数据解析模块)可以删除该业务类型的目标数据，以减少第一规则分析模块的计算量，提高数据处理的速度。

4、json总线生成：数据解析模块在对表单进行删除处理后，可以基于剩余的表单生成json总线。生成json总线可以理解为：将剩余表单按照表单的编号进行排序，得到串行的表单。

5、交易转发和6、kafka写入可以理解为：数据解析模块可以将json总线(即剩余的表单)采用kafka的方式写入kafka队列中，也可以说，数据解析模块将剩余的表单加载至kafka队列中，kafka队列可以称为任务队列。换句话说，数据解析模块可以将剩余的表单转发至第一规则分析模块。

第一规则分析模块，用于根据目标数据的业务类型，在目标数据中获取与业务类型相关的待处理数据，以及采用业务类型对应的数据异常处理流程，处理待处理数据，得到目标数据是否异常的结果，且输出结果。如上，第一规则分析模块可以用于执行如下步骤：1、kafka读取；2、规则算子；3、窗口统计；4、数据输出。

应理解的是，第一容器中包含有数据库，数据库中存储有第一映射关系，该第一映射关系为业务类型和待处理数据的属性的映射关系。其中，待处理数据的属性可以为：金额、转账的账号、收款人的账号、身份证号等。应理解，第一规则分析模块中存储有数据库的访问端口。

1、kafka读取：第一规则分析模块，用于在第一容器中，读取kafka队列中的表单，进而通过第一容器访问数据库的访问端口，以在数据库中读取第一映射关系。

2、规则算子：第一规则分析模块，可以用于根据目标数据的业务类型，以及从数据库中读取的第一映射关系，获取目标属性，且在目标数据中，将目标属性对应的数据作为待处理数据。

示例性的，第一映射关系中，转账业务对应的待处理数据的属性为转账金额、转账的账号，以及收款人的账号。第一规则分析模块可以根据表单的业务类型(如转账业务类型)，以及该第一映射关系，获取表单的目标属性为转账金额、转账的账号，以及收款人的账号。进而在该表单中，将转账金额、转账的账号，以及收款人的账号对应的数据作为待处理数据，如待处理数据可以为“转账金额200w，转账的账号610xx，收款人的账号620xx”。

在一种实施例中，第一规则分析模块中可以存储至少一个业务类型的标识和数据异常处理流程的标识的第二映射关系。第一规则分析模块在得到待处理数据后，可以根据目标数据的业务类型，以及第二映射关系，获取业务类型对应的数据异常处理流程。

示例性的，如第二映射关系中，转账业务类型对应的数据异常处理流程为“判断转账金额是否大于预设金额，且判断收款人的账号是否为转账的账号常用的收款人的账号”，若目标数据的业务类型为转账业务类型，第一规则分析模块可以基于目标数据的业务类型，以及第二映射关系，确定数据异常处理流程为“判断转账金额是否大于预设金额，且判断收款人的账号是否为转账的账号常用的收款人的账号”。

其中，第一规则分析模块可以采用业务类型对应的数据异常处理流程，处理待处理数据，得到目标数据是否异常的结果。如上示例所示，若表单中的转账金额为200w，大于该预设金额，且收款人的账号是与该转账的账号第一次进行交易的账号，则第一规则分析模块可以基于数据异常处理流程，确定该表单异常。

在一种实施例中，目标数据为交易数据时，业务类型的标识可以为交易码，数据异常处理流程的标识可以为规则名。因为数据异常处理流程可以以处理函数形式存在，因此规则名可以理解为处理函数的标识。因为处理函数位于第二容器中，因此，第一规则分析模块可以在第二容器中调用处理函数，进而在第二容器中，运行处理函数，以处理待处理数据，以得到目标数据是否异常的结果。

在一种实施例中，第一容器为flink容器，第二容器为springboot容器，数据库为redis数据库，处理函数为bean函数。第一规则分析模块可以通过flink容器访问数据库的访问端口，以在数据库中读取第一映射关系。

在一种实施例中，为了提高数据库中的数据安全性，访问端口设置有访问密码，第一规则分析模块中可以存储访问密码，或者该访问密码为第一规则分析模块和数据库预先约定的，进而第一规则分析模块可以采用该访问密码通过flink容器访问数据库的访问端口，以在数据库中读取第一映射关系。

如上示例性的说明了转账业务类型对应的数据异常处理流程为“判断转账金额是否大于预设金额，且判断收款人的账号是否为转账的账号常用的收款人的账号”，在一种实施例中，本申请实施例中的业务类型对应的数据异常处理流程包括：获取目标数据之前的预设时间段内与目标数据关联的历史数据，目标数据和历史数据关联同一用户；结合历史数据的业务类型，识别待处理数据是否落入异常数据的范围。

示例性的，以目标数据的业务类型为转账业务类型，预设时间段为1天为例，第一规则分析模块获取目标数据的时间为5月3日，则第一规则分析模块可以获取5月3日前1天内与该目标数据关联的历史数据。示例性的，如第一规则分析模块可以查询与该目标数据具有相同的转账的账号的历史数据，将该历史数据作为与目标数据关联的历史数据。应理解，目标数据和历史数据关联同一用户，可以理解为：目标数据和历史数据的转账的账号相同，或者电号码，或者用户的名字相同等。

第一规则分析模块可以获取历史数据的业务类型，且结合历史数据的业务类型，识别待处理数据是否落入异常数据的范围。示例性的，异常数据的范围可以为：转账金额大于预设金额，其中，若历史数据的业务类型为修改交易密码，且待处理数据中的转账金额大于预设金额，则第一规则分析模块可以确定该目标数据存在风险，即该目标数据异常，即得到该目标数据异常的结果。

示例性的，以目标数据的业务类型为支付业务类型，预设时间段为1天为例，第一规则分析模块获取目标数据的时间为5月3日，则第一规则分析模块可以获取5月3日前1天内与该目标数据关联的历史数据。示例性的，如第一规则分析模块可以查询与该目标数据具有相同的支付的账号的历史数据，将该历史数据作为与目标数据关联的历史数据。应理解，目标数据和历史数据关联同一用户，可以理解为：目标数据和历史数据的支付的账号相同等。

第一规则分析模块可以获取历史数据的业务类型，且结合历史数据的业务类型，识别待处理数据是否落入异常数据的范围。示例性的，异常数据的范围可以为：转账金额大于预设金额，其中，若历史数据的业务类型为借款，且待处理数据中的支付金额大于预设金额，则第一规则分析模块可以确定该目标数据存在风险，即该目标数据异常。

如上，本申请实施例不仅可以基于目标数据，识别该目标数据是否异常，还可以结合与目标数据关联的历史数据，来识别目标数据是否异常，可以提高识别准确度。

4、数据输出：在第一规则分析模块得到目标数据是否异常的结果后，可以输出该目标数据是否异常的结果，具体可以参照上述实施例的相关描述。

在一种实施例中，第一规则分析模块可以将目标数据是否异常的结果存入存储数据库中，示例性的，该存储数据库可以为oracle数据库。

3、窗口统计：在一种实施例中，第一规则分析模块，还用于进行窗口统计，进而得到统计结果，在输出目标数据是否异常的结果时，输出该统计结果。示例性的，第一规则分析模块可以对不同区域内的银行专柜的终端设备上报的目标数据的异常率进行统计，进而得到每个区域内的银行专柜的交易数据的异常率。相应的，第一规则分析模块在输出目标数据是否异常的结果时，可以输出每个区域内的银行专柜的交易数据的异常率(即统计结果)。

如上，基于第一规则分析模块和数据解析模块，目标服务器可以对目标数据进行解析、筛选，以及针对不同业务类型的目标数据，获取不同的待处理数据，且采用业务类型对应的数据异常处理流程，处理待处理数据，得到目标数据是否异常的结果，可以提高出数据处理效率。

图5为本申请实施例提供的目标服务器的另一种结构示意图。参照图5，目标服务器中可以包括：数据解析模块，第一规则分析模块以及第二规则分析模块。数据解析模块和第一规则分析模块可以参照上述实施例的相关描述。

在一种实施例中，来自目标服务器的数据多种多样，不仅包括上述的“不同业务类型的多个表单”，还可以包括批量具有相同业务类型的表单。针对批量具有相同业务类型的表单，可以由第二规则分析模块进行处理，以得到批量具有相同业务类型的表单是否异常的结果，且输出结果。在一种实施例中，目标数据为批量具有相同业务类型的表单，目标服务器可以将该多个表单加载至其他类型的队列里。

相应的，第二规则分析模块可以用于执行如下步骤：1、kafka读取；2、数据转换；3、队列汇聚；4、规则算子；5、窗口统计；6、数据输出。其中，步骤4-5可以参照上述第一规则分析模块中的步骤的相关说明，下述对步骤1-3进行介绍：

1、kafka读取：即第二规则分析模块可以采用kafka的方式在其他类型的队列中读取该批量具有相同业务类型的表单。

2、数据转换：第二规则分析模块可以将批量具有相同业务类型的表单的格式转换成第二规则分析模块能够识别的格式(如string格式)。

3、队列汇聚：第二规则分析模块可以将该批量具有相同业务类型的加载至一个队列中。

在一种实施例中，第二规则分析模块可以将目标数据是否异常的结果存入存储数据库中，示例性的，该存储数据库可以为hbase数据库。

应理解的是，针对“批量具有相同业务类型的表单”，以及“不同业务类型的多个表单”的处理方式不同，主要在于“批量具有相同业务类型的表单”的数量大，容易产生风险(异常)，因此无需对其进行交易筛选，且业务类型相同，其本身就是串行的表单，无需对其进行json总线的生成。

综上，无论针对何种类型的数据(“批量具有相同业务类型的表单”或以及“不同业务类型的多个表单”)，目标服务器可以基于不同类型的数据，采用不同的处理流程进行处理，也可以提高数据处理效率。

在一种实施例中，第一规则分析模块和第二规则分析模块可以集成在一起，以规则分析模块表征，该规则分析模块可以执行上述第一规则分析模块和第二规则分析模块执行的步骤，且规则分析模块可以基于队列的标识(boeing队列还是其他类型的队列)，确定按照如上第一规则分析模块的步骤处理数据，还是按照如上第二规则分析模块的步骤处理数据。

如上，数据解析模块，第一规则分析模块和第二规则分析模块均集成在目标服务器中，因此，目标服务器可以执行上述数据解析模块，第一规则分析模块和第二规则分析模块执行的步骤，可以参照上述实施例的相关描述。参照图6A，如上图3实施例中的S302可以替换为S302A-S303A，在S303之前可以包括S303B。

S302A，根据目标数据的业务类型，以及第一映射关系，获取目标属性。

S303A，在目标数据中，将目标属性对应的数据作为待处理数据。

S303B，根据目标数据的业务类型，以及第二映射关系，获取业务类型对应的数据异常处理流程。

如上S302A-S303A，以及S303B的实施方式可以参照上述第一规则分析模块中的相关描述。

在一种实施例中，在S302A之前还可以包括S304A：服务器将目标数据加载至任务队列，且在第一容器中，读取任务队列中的目标数据，以及在数据库中读取第一映射关系。

在该实施例中，相应的，上述S302B可以替换为：在第二容器中调用处理函数，以及在第二容器中，运行处理函数，以处理待处理数据。

如上S304A以及服务器在第二容器中调用处理函数，且在第二容器中运行处理函数的过程可以参照上述的相关描述。

本申请实施例具有与上述实施例相同的技术效果，可以参照上述的相关描述，在此不做赘述。

基于上述实施例中的数据处理方法，下面结合一具体的场景介绍本申请实施例提供的数据处理方法。参照图6B，目标服务器可以接收来自中心服务器或终端设备的多个表单，目标服务器可以基于表单的来源(即图6B中的渠道)将该多个表单分为柜面、自动取款机(automated teller machine，ATM)和电子。应理解，柜面指的是：表单来源于银行柜面的终端设备，可以为银行的工作人员录入终端设备，上报至服务器(中心服务器或目标服务器)的。ATM指的是：用户在ATM上自主操作，ATM将表单上报至服务器(中心服务器或目标服务器)。电子指的是：用户通过自己的终端设备进行交易，终端设备将表单上报至服务器(中心服务器或目标服务器)。

针对柜面的表单，目标服务器可以基于表单中指示的卡种，基于表单的业务类型，对表单进行处理。卡种可以理解为：卡的种类，如存单、存折、银行卡等。本申请实施例中示例性的以卡种为存单为例进行说明，应理解，不同的卡种，也可以基于表单的业务类型，对表单进行处理，处理方式可以与存单相同。其中，针对表单为存款业务类型(即图6B中的存入)，可以获取表单中的待处理数据，如存款金额。进而目标服务器可以基于存款业务类型对应的数据异常处理流程，识别该存款的表单是否异常。

针对电子的表单，若表单指示的卡种为银行卡，且该表单的业务类型为转账业务类型，在一种实施例中，目标服务器可以在该表单中获取待处理数据为转账金额，进而目标服务器可以基于转账业务类型对应的数据异常处理流程，识别该转账的表单是否异常，如该转账金额大于100w，则该表单可能存在风险，将该表单识别为异常表单。

应理解的是，针对存款业务类型，还可以采用与转账业务类型相同的数据异常处理流程，识别该存款的表单是否异常。示例性的，如存款的表单中的存款金额大于100w，则该表单可能存在风险，将该表单识别为异常表单。

应注意，上述实施例中，针对转账业务类型、存款业务类型的目标数据中的目标属性，以及数据异常处理流程为示例说明。

应理解，本申请未示出目标服务器对ATM的表单的处理流程，ATM的各业务类型的表单的数据异常处理流程，可以与上述柜面的表单、电子的表单的对应的业务的表单的数据异常处理流程相同，在此不做赘述。

图7为本申请提供的数据处理装置的结构示意图。应理解，该数据处理装置可以为上述实施例中的目标服务器，或者目标服务器中的芯片。如图7所示，该数据处理装置700包括：数据解析模块701和规则分析模块702。在一种实施例中，规则分析模块702可以包括第一规则分析模块和第二规则分析模块，可以参照如上实施例的相关描述。

数据解析模块701，用于获取目标数据，目标数据来自于服务器集群的中心服务器或终端设备。

规则分析模块702，用于根据目标数据的业务类型，在目标数据中获取与业务类型相关的待处理数据；采用业务类型对应的数据异常处理流程，处理待处理数据，得到目标数据是否异常的结果；输出结果。

在一种可能的实现方式中，业务类型与待处理数据的属性具有第一映射关系。规则分析模块702，具体用于根据目标数据的业务类型，以及第一映射关系，获取目标属性；在目标数据中，将目标属性对应的数据作为待处理数据。

在一种可能的实现方式中，业务类型对应的数据异常处理流程包括：获取目标数据之前的预设时间段内与目标数据关联的历史数据，目标数据和历史数据关联同一用户；结合历史数据的业务类型，识别待处理数据是否落入异常数据的范围。

在一种可能的实现方式中，目标服务器中包括：至少一个业务类型的标识和数据异常处理流程的标识的第二映射关系。规则分析模块702，还用于根据目标数据的业务类型，以及第二映射关系，获取业务类型对应的数据异常处理流程。

在一种可能的实现方式中，若目标数据来自预设设备，目标数据包括至少一个表单。规则分析模块702，还用于根据每个表单的业务类型，删除业务类型为预设业务类型的表单。

在一种可能的实现方式中，业务类型对应的数据异常处理流程为处理函数，目标服务器中包括：第一容器，第一容器中设置有第二容器，第二容器中包含处理函数。规则分析模块702，还用于将目标数据加载至任务队列；在第一容器中，读取任务队列中的目标数据；在数据库中读取第一映射关系；在第二容器中调用处理函数。

规则分析模块702，具体用于在第二容器中，运行处理函数，以处理待处理数据。

在一种可能的实现方式中，第一容器为flink容器，第二容器为springboot容器，数据库为redis数据库，处理函数为bean函数。规则分析模块702，具体用于通过flink容器访问数据库的访问端口，以读取第一映射关系。

在一种可能的实现方式中，规则分析模块702，还用于在flink容器中加载springboot容器，以及调用flink容器中flink函数的方法，加载bean函数至springboot容器。

本实施例提供的数据处理装置与上述数据处理方法实现的原理和技术效果类似，在此不作赘述。

图8为本申请提供的电子设备的结构示意图。该电子设备可以为上述实施例中的服务器。如图8所示，该电子设备800包括：存储器801和至少一个处理器802。

存储器801，用于存储程序指令。

处理器802，用于在程序指令被执行时实现本实施例中的数据处理方法，具体实现原理可参见上述实施例，本实施例此处不再赘述。

该电子设备800还可以包括及输入/输出接口803。

输入/输出接口803可以包括独立的输出接口和输入接口，也可以为集成输入和输出的集成接口。其中，输出接口用于输出数据，输入接口用于获取输入的数据，上述输出的数据为上述方法实施例中输出的统称，输入的数据为上述方法实施例中输入的统称。

本申请还提供一种可读存储介质，可读存储介质中存储有执行指令，当电子设备的至少一个处理器执行该执行指令时，当计算机执行指令被处理器执行时，实现上述实施例中的数据处理方法。

本申请还提供一种程序产品，该程序产品包括执行指令，该执行指令存储在可读存储介质中。电子设备的至少一个处理器可以从可读存储介质读取该执行指令，至少一个处理器执行该执行指令使得电子设备实施上述的各种实施方式提供的数据处理方法。

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

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

另外，在本申请各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用硬件加软件功能模块的形式实现。

上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(英文：Read-Only Memory，简称：ROM)、随机存取存储器(英文：Random Access Memory，简称：RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

在上述网络设备或者终端设备的实施例中，应理解，处理模块可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：ApplicationSpecific Integrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。