CN114064720A - 一种异构流数据处理方法及装置 - Google Patents

Abstract

本申请公开了一种异构流数据处理方法及装置，涉及数据处理技术领域，用以实现异构流数据的标准化，并且节约成本，提高工作效率。本申请提供的异构流数据处理方法包括：获取待处理的实时流数据；当预先设置的标准化配置文件中存在与所述实时流数据匹配的标准化配置时，利用与所述实时流数据匹配的标准化配置，对所述实时流数据进行处理。本申请实现了异构流数据的标准化转换处理，并且，当需要变更对流数据的标准化处理方法时，只需更新标准化配置文件即可，无需修改数据处理的底层代码，进而节约了成本，数据处理系统运维也比较简单，提高了工作效率。

Description

一种异构流数据处理方法及装置

技术领域

本申请涉及数据处理技术领域，尤其涉及一种异构流数据处理方法及装置。

背景技术

在大数据开发方面，不管是批量还是实时流处理，通常都会遇到要将多类异构流数据转换为一类目标数据或者少数几类目标数据，然后再进行进一步处理的情况，但是，每类数据都需要一个脚本或者程序来处理才能转化为目标数据，并且每个程序或者脚本都需单独的调度和管理，特别是随着时间的前进，接入的数据类型越来越多，每类数据开发人员又不一样，就会导致后面的运维越来越困难。

现有技术在将多类异构流数据转换到目标数据时，针对每类数据都有单独的脚本或者程序，而且每次只能转换成一类数据，这种方式对于具有几十甚至几百类数据需要转化时，会有比较高的开发和维护成本，因为每类数据都需要单独去开发脚本或者程序，导致维护成本较高，如果需要修改数据转换规则，则需要重新开发代码。

发明内容

本申请实施例提供了一种异构流数据处理方法及装置，用以利用预设的标准化配置文件，实现异构流数据的标准化转换，节约成本，提高工作效率。

本申请实施例提供的一种异构流数据处理方法，包括：

获取待处理的实时流数据；

当预先设置的标准化配置文件中存在与所述实时流数据匹配的标准化配置时，利用与所述实时流数据匹配的标准化配置，对所述实时流数据进行处理。

本申请实施例，通过获取待处理的实时流数据，当预先设置的标准化配置文件中存在与所述实时流数据匹配的标准化配置时，利用与所述实时流数据匹配的标准化配置，对所述实时流数据进行处理，从而实现了异构流数据的标准化转换处理，并且，当需要变更对流数据的标准化处理方法时，只需更新标准化配置文件即可，无需修改数据处理的底层代码，进而节约了成本，数据处理系统运维也比较简单，提高了工作效率。

可选地，获取待处理的实时流数据之前，该方法还包括：从预先设置的标准化配置文件中加载标准化配置到Spark广播变量中。

可选地，通过如下方式确定与所述实时流数据匹配的标准化配置：

对于所述Spark广播变量中的每一条标准化配置，判断该标准化配置是否与所述实时流数据匹配。

可选地，对于所述Spark广播变量中的每一条标准化配置，判断该标准化配置是否与所述实时流数据匹配，具体包括：

对于所述每一条标准化配置，当所述实时流数据中存在该标准化配置中的字段，并且字段的取值相同时，确定该标准化配置与所述实时流数据匹配。

可选地，该方法还包括：

监控所述标准化配置是否需要更新，当需要更新时，将标准化配置文件中的标准化配置更新到所述Spark广播变量中。

可选地，每一条标准化配置中包括：用于过滤掉无用数据的过滤条件、所有过滤条件的组合方式、数据处理方式，以及目标流数据的写入对象；所述目标流数据为对所述实时流数据进行处理后得到的数据。

可选地，利用与所述实时流数据匹配的标准化配置，对所述实时流数据进行处理，具体包括：

对于与所述实时流数据匹配的每一条标准化配置，分别判断所述实时流数据是否满足该条标准化配置中的每一过滤条件，得到每一过滤条件对应的判断结果，并根据所述组合方式组合所述判断结果，得到组合结果；

当所述组合结果满足预设条件时，按照所述数据处理方式对所述实时流数据进行处理。

可选地，从预先设置的标准化配置文件中加载标准化配置到Spark广播变量中，具体包括：

从预先设置的标准化配置文件中，逐行读取标准化配置；

对每一行标准化配置，将该行标准化配置由JSON字符串转换为JSON对象，利用所述JSON对象中的如下字段之一或组合构建Spark广播变量：

用于识别实时流数据是否与该行标准化配置相匹配的第一字段；

用于表示对所述类型的实时流数据的过滤条件的第二字段；

用于表示所述第二字段中所有过滤条件的组合方式的第三字段；

用于表示数据处理方式的第四字段；

用于表示目标流数据的写入对象的第五字段。

本申请实施例提供的一种异构流数据处理装置，包括：存储器和处理器，其中，所述存储器用于存储程序指令，所述处理器用于调用所述存储器中存储的程序指令，按照获得的程序执行上述任一种方法。

此外，根据实施例，例如提供了一种用于计算机的计算机程序产品，其包括软件代码部分，当所述产品在计算机上运行时，这些软件代码部分用于执行上述所定义的方法的步骤。该计算机程序产品可以包括在其上存储有软件代码部分的计算机可读介质。此外，该计算机程序产品可以通过上传过程、下载过程和推送过程中的至少一个经由网络直接加载到计算机的内部存储器中和/或发送。

本申请另一实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令用于使所述计算机执行上述任一种方法。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅是本申请的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的异构流数据处理原理示意图；

图2为本申请实施例提供的异构流数据处理的总体流程示意图；

图3为本申请实施例提供的异构流数据处理的主流程示意图；

图4为本申请实施例提供的标准化配置加载的子流程示意图；

图5为本申请实施例提供的数据标准化子流程示意图；

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

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

图8为本申请实施例提供的异构流数据处理装置的结构示意图。

具体实施方式

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

本申请实施例提供了一种异构流数据处理方法及装置，用以实现异构流数据的标准化，并且节约成本，提高工作效率。

其中，方法和装置是基于同一申请构思的，由于方法和装置解决问题的原理相似，因此装置和方法的实施可以相互参见，重复之处不再赘述。

下面结合说明书附图对本申请各个实施例进行详细描述。需要说明的是，本申请实施例的展示顺序仅代表实施例的先后顺序，并不代表实施例所提供的技术方案的优劣。

本申请实施例提供的技术方案，通过一个配置文件来管理接入的各类数据，每接入一类数据只需要在配置文件中增加一条记录，若数据转换的规则有变化，也只需要修改配置就可以了，删除亦然。当然配置文件只是用来管理配置，本申请实施例的另一个核心是一个通用的程序，其是用来处理数据转化的主体。

术语解释：

Spark流计算：Spark是快速、通用的大规模数据处理引擎。本申请实施例中使用Spark流计算引擎(Spark structured streaming)，实现Spark分布式准实时流计算。本申请实施例中，利用Spark最新的流计算框架Spark structured streaming来实现，得益于该框架批流一体的特性，本申请实施例可以同时应用于批量数据和流数据的计算，但在本申请实施例中主要阐述在流数据的计算中的相关使用。

Executor：Executor是Spark任务(task)的执行单元，运行在工作节点(worker)上，实际上它是一组计算资源(CPU核心、memory)的集合。一个worker上的memory、CPU由多个Executor共同分摊。

Spark广播变量：Spark中因为算子中的真正逻辑是发送到Executor中去运行的，所以当Executor中需要引用外部变量时，需要使用Spark广播变量。Spark广播变量的好处是不需要每个task带上一份变量副本，而是每个节点的Executor对应一份副本从而使得变量产生的副本大大减少，节约内存。

JSON：JSON(JavaScript Object Notation，JS对象简谱)是一种轻量级的数据交换格式，它采用完全独立于编程语言的文本格式来存储和表示数据。

Kafka：是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。

Topic：每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。

本申请实施例的目的是提供一套将多种异构JSON流数据(即不同结构的流数据)转化为一种或者多种结构的目标JSON流数据的方案，在转化过程中完成对数据的过滤、补全、数据转换等工作，之后将数据转发到Kafka指定Topic中。

数据处理的大体流程如图1所示，该图中源流数据的种类(例如源流数据1、源流数据2、源流数据3等等)和目标流数据(目标流数据1、目标流数据2、目标流数据3等等)的类型是不一的，一般情况下是将多种源数据转换为少数几张目标数据，也就是图1中所示的n可以大于m，当然也可以等于m。

为了更全面的阐述本申请实施例的实现方法，下面将从总体设计、配置文件设计和处理详细流程三方面来阐述本申请实施例的具体实现过程。

一、整体流程：

参见图2，整个标准化处理程序是基于Spark structured streaming开发，使用Spark作业监听器(Streaming Query Listener，SQL)监控标准化配置是否需要更新或加载，如果发现配置更新指令或配置加载指令到达，则该监听器会将标准化配置文件(简称配置文件)的内容更新到Spark广播变量中，当被标准化数据(例如图2中所示的实时流数据，即需要进行标准化转换的数据，也即源流数据)到达时，Spark的Executor会从Spark广播变量中获取到这个配置，并根据这个配置来对实时流数据进行标准化处理，其中，可能需要调用标准化函数库中的函数进行标准化处理，最终得到目标流数据，即标准化数据。

其中，在图2中给出的实时流数据，例如可以来源于各种应用系统，这些数据经过标准化处理后，转化为标准化数据，提供给下游处理。在标准化处理的时候可能需要用标准化函数库来支撑数据的处理，以实现对数据的每个字段的格式化、数据补全、数据转换等功能。

其中，所述的标准化函数库，例如图2所示，可以包括下列标准化函数之一或组合：SQL函数、默认值处理函数、时间戳处理函数、时间标准化函数、字符串拼接函数、日期标准化函数、替换函数等。这些列举的函数，都是现有技术中常用的函数，此处不再进行详细的解释说明，并且上述函数仅是举例说明，实际应用中可以根据需要进行添加新的函数或删除已有函数。

二、配置文件设计：

为了将数据标准化的处理工作变成对标准化配置文件的维护过程，本申请实施例中，例如可以在标准化配置文件的JSON结构中定义如下字段：

dataIdentity：该字段是用来判断源流数据(即需要被标准化转换的数据)是否与当前配置匹配。判断方法是判断dataIdentity下的identity中所有的字段是否在源流数据中存在并且值要相等。

dataIdentity下层有两种字段relation和identity。其中，identity是一个JSON数组，每个JSON数组有两个字段，分别是目标字段名(例如表示为“field”)和目标字段值(例如表示为“v1”，用于设置待处理数据中key为f1的值为v1)，被处理的JSON数组中目标字段名对应的值等于目标字段值，被处理的JSON数组中存在目标字段名对应的key，并且该key对应的值和目标字段值存在关系，关系类型由op表示，例如单比较值比较或多比较值比较，具体在下面有进一步的解释说明。dataIdentity下可以有多个identity，identity之间相互的关系由relation表示，所述relation目前只支持and(与)，表示identity之间是“与”的关系。

filters：该字段指出了dataIdentity所指示的类型的流数据对应的过滤条件。

所述过滤条件，用于过滤掉不使用的数据，例如可以包括下列内容之一或组合：过滤条件名filterNm、字段名field、值名称value和对比符号op。

其中，filters字段下可以有多组过滤条件，例如包括三组过滤条件，第一组过滤条件的filterNm为"nm1"，field为"fi1"，value为"v1"，op为"单比较值比较符号"；第二组过滤条件的filterNm为"nm2"，field为"fi2"，value为["v2","v3"，…]，op为"多比较值比较符号"；第三组过滤条件的filterNm为"nm3"，field为"fi3"，value为"v2"，op为"单比较值比较符号"。

其中，通过对当前正在处理的源流数据中field字段取得的值与value的值按照op进行比较，得到一个布尔值。

例如：对于过滤条件filterNmA，当前正在处理的JSON数据中key为field的字段对应的值为valA,过滤条件filterNmA中的value的值为valB，op的值为“＝”，则：如果valA等于valB，则返回“真”，说明条件和数据中的值相等，否者返回“假”。

这些布尔值(“真”、“假”)，后续会按照filterPattern指定的方式进行组合计算，最终组合结果返回为“真”的目标数据被保留(具体在后续数据标准化子流程中步骤503、504中有相关描述)。

filterPattern：该字段表示的是filters中所有过滤条件的组合方式，所述组合方式，例如是“与、或、非”，与括号、变量等的组合。例如：nm1&&(nm2||nm3)，表示nm1的条件必须满足，nm2和nm3的条件只要满足一个就可以，通过这种组合能表达更复杂的条件。

例如，"filterPattern":"(nm1&&nm2)||nm3"表示filterNm为nm1的过滤条件对应的布尔值，和filterNm为nm2的过滤条件对应的布尔值的组合方式是“与”，所得到的结果，和、filterNm为nm3的过滤条件对应的布尔值的组合方式是“或”。

filterPattern还有两种简化的值：一种是“&&”，表示过滤条件间的关系全都是“与”；另一种是“||”，表示过滤条件间的关系全都是“或”。

stdMap：该字段表示具体的数据处理方式，即对源流数据进行标准化处理的具体方式。

stdMap体现了源流数据与目标流数据的字段间的映射规则。

所述映射规则，例如可以是简单的一一映射，例如，标准化字段是客户号，可以直接从待处理数据中取客户号；

所述映射规则也可以是经过上述函数处理后的结果，例如，标准化字段是年龄，待处理数据中只有生日，函数就是用于计算年龄的函数，参数是生日，最终计算出年龄；

再或者，也可以直接是使用默认值，即源流数据的字段直接用预设值替换，得到目标流数据的字段。

下面具体解释说明stdMap中的每一字段：

每一组处理规则中包含三个字段stdField、srcField和default。其中，stdField表示转换后的字段名，即目标流数据的字段名；srcField表示新值的获取方法方法，具体方法是：当srcField.pType等于field表示可以直接取被处理数据中srcField.value中字段在待处理数据中的值。当srcField.pType等于func表示为新值由指定函数生成时，srcField.Value的值是一个JSON对象，有两个字段，即func和parm，func表示要使用的函数的函数名，parm是一个JSON数组，表示要使用的函数所需要使用的参数列表，比如func表示的是拼接函数connStr()，其需要的参数有三种，分别是：字符串类型(string)、字段类型(field)、函数类型(func)。其中，字符串类型直接取pValue中的值(即参数里面有两个字段，一个是pType，一个是value，取这个value的值)，而field类型则需要从待处理数据中获取对应的值，其key为pValue中的值，函数类型则和connStr()类似，同样有各种类型的参数，类似函数的嵌套。最终，将这三个参数传给拼接函数connStr()，即完成计算。

toTopic：表示目标流数据要被写入到哪个Kafka的topic，即目标流数据的写入对象。在源流数据被标准化处理后，得到需要写到多个topic中的目标流数据后，直接写入到指定Kafka的指定topic中的方法，下游需要什么数据，直接从Kafka中读取。

综上所述，所述JSON字符串就是本申请实施例中进行数据标准化转换需要用的配置文件，在整个程序运行起来后，只需要编写和/或修改这个配置文件，而不需要修改数据处理过程中需要使用的底层代码，即不需要修改图2中所示的Executor中运行的程序，仅修改前面的标准化配置文件即可。

三、标准化处理的详细流程：

为了便于描述本申请实施例提供的总体流程，以及简化流程图，本申请实施例中，先描述整体流程(主流程)，将该整体流程中的加载标准化配置文件的子流程和对数据执行标准化处理的子流程在后面分别单独描述。

如图3所示，所述主流程例如包括：

步骤S301、首先加载标准化配置文件，即执行加载标准化配置文件的子流程，具体请参见后续结合图4的详细描述。

需要说明的是，该步骤中的配置加载不仅包括初始化加载，即将初始设置的标准化配置文件到Spark广播变量中；还包含了后续的更新，即当配置更新时，需要重新加载最新的标准化配置文件到Spark广播变量中。每次更新标准化配置文件后，可以手动触发更新，也可以自动更新，更新方式例如可以是在指定目录上建一个空文件std_update，作业监听器会监测这个std_update文件是否存在，存在就会重新加载标注化配置文件中的配置到Spark广播变量中。

综上，步骤S301相当于从预先设置的标准化配置文件中加载标准化配置到Spark广播变量中；并且，进一步地，监控所述标准化配置是否需要更新，当需要更新时，将标准化配置文件中的标准化配置更新到所述Spark广播变量中。

步骤S302、从Kafka中获取一条JSON字符串数据，然后将JSON字符串转化为JSON对象data1。

data1即待处理的实时流数据。步骤S302相当于获取待处理的实时流数据，所述实时流数据为需要被执行标准化转换的数据，即源流数据。

本申请实施例中，按照预设的标准化配置文件，可以对来自不同系统的不同结构的源流数据进行处理，得到结构上符合统一标准的目标流数据，因此，将本申请实施例提供的数据处理方案，称为异构流数据的处理方案。

以下步骤具体描述如何利用预先设置的标准化配置文件，对所述实时流数据执行标准化转换：

步骤S303、从Spark广播变量中获取标准化配置allStdConf；

后续步骤中，需要从allStdConf中逐一取出每条配置数据与data1匹配；

也就是说，标准化配置allStdConf中可以有多条配置数据，本申请实施例逐一取出每条配置数据分别与data1匹配。具体地：

步骤S304、从allStdConf中获取一条记录(fields,Map(fv,List(StdConf)))，即一条配置数据，并记其中的Map(fv,List(StdConf))为stdMap；

其中，fields表示标准化配置的字段名，StdConf包括filters、filterPattern、toTopic、fieldMap实例，fv表示按照标准化配置中的fields中field对应的顺序，对fields中field的字段值进行拼接的结果。

步骤S305、从data1中获取fields中所有field对应的值，并按照fields中field对应的顺序拼接，记为fv1；例如，fields中的值依次为f1、f2、f3，从待处理数据中获取key为f1、f2、f3的值分别为a、f、b，拼接后，就是afb。

需要说明的是上述步骤S304和步骤S305可以并行执行。

步骤S306、判断stdMap中是否存在fv＝fv1，如果是，即stdMap中存在等于fv1的fv，则执行步骤S307；否则，执行步骤S309。

也就是说，本申请实施例中，从所述Spark广播变量中获取多个标准化配置，每一个标准化配置包括(fields,Map(fv,List(StdConf)))；

针对每一个标准化配置：

当所述实时流数据data1中存在该标准化配置中的fields中的所有字段时，从所述实时流数据中获取所述所有字段的字段的值，并按照所述所有字段在所述fields中的顺序进行拼接，得到拼接结果fv1；

当该标准化配置中的Map(fv,List(StdConf))中存在所述fv1时，确定该标准化配置与所述实时流数据匹配成功。

步骤S307、从stdMap中获取fv1对应的标准化配置List(StdConf)，记为stdConfs；

也就是说，本申请实施例中需要从Spark广播变量中，查找与待处理的实时流数据相匹配的标准化配置，利用匹配成功的标准化配置对该实时流数据进行标准化转换处理。

步骤S308、对data1的数据按照步骤S307中确定的标准化配置stdConfs进行标准化转换，即对数据执行标准化处理的子流程，具体请参见后续结合图5的详细描述；

步骤S309、如果在步骤S306中判断stdMap中不存在等于fv1的fv，则继续判断allStdConf中的记录是否都被遍历，如果未被全部遍历，则执行步骤S304，即继续从allStdConf中获取下一条配置数据；否则，退出匹配过程。

步骤S310、如果allStdConf中的记录都被遍历了，则收集所有标准化结果数据(因为可能有多个StdConf，所以，一条待处理数据data1可以处理成多条结果数据)，即收集完成上述步骤S307中所述的标准化转换(即执行了图5所示的数据标准化子流程)后得到的标准化数据，得到源流数据data1对应的目标流数据，并通过Kafka发出。

下面分别阐述上述总体流程中的标准化配置加载的子流程和对数据执行标准化处理的子流程。

标准化配置加载的子流程(即将预设的标准化文件中的标准化配置加载到Spark广播变量中的过程)：

如图4所示，所述加载标准化配置文件的子流程例如包括：

步骤S401、从标准化配置文件中读取一行配置，将该标准化配置由JSON字符串转换为一个JSON对象JSONObj；

本申请实施例中，预先设置的标准化配置文件，包括多行配置，在加载标准化配置文件的过程中，逐行读取标准化配置文件中的配置。每行配置包含如下字段之一或组合：

dataIdentity字段、fileters字段、filterPattern字段、stdMap字段、toTopic字段。

也就是说，本申请实施例中，对每一行标准化配置，将该行标准化配置由JSON字符串转换为JSON对象JSONObj，利用JSONObj中的字段之一或组合构建Spark广播变量。

下述步骤中提及的相应字段的处理，若读取的配置中没有该字段，则表示可以省略该字段相应的步骤。

步骤S402、将JSON对象JSONObj中的dataIdentity字段中所有字段名(即field的值)提取出来，并放到一个列表list中。

步骤S403、对列表list中的字段名按字典顺序排序，重新排序得到的列表记为list1，然后将list1的值按序拼接，将拼接结果记为key，比如list1中的值依次为cf1、cf2、cf3，拼接后就是cf1cf2cf3。将field对应的字段值(value)按照list1中field相应的顺序，进行拼接，将拼接结果记为fv。

步骤S404、从JSONObj中抽取filters的值，并以列表形式进行组装，组装得到的列表记为filters；

步骤S405、从JSONObj中抽取filterPattern的值，记为filterPattern；取toTopic的值记为toTopic；

步骤S406、从JSONObj中抽取stdMap的值，转换为目标字段stdField和源字段SrcField的映射：Map(stdField,SrcField)，记该映射为fieldMap，即fieldMap表示目标字段stdField和源字段SrcField的映射关系。

其中，stdField是目标字段字段名，其类型为字符串，SrcField给出了构成目标字段的方式，其结构为(pType,value,func,default)，其中，pType表示构建目标字段值的方式，其取值可以为：field、string、func，其中field表示SrcField中value的值为待处理数据中的字段名，目标字段直接取被处理数据中该字段的值；string表示SrcField中value的值为指定字符串，目标字段直接取该值；func表示目标字段的值是通过指定函数生成，该函数是SrcField中的func字段对应的值；当目标字段通过pType的方式获取的值为空时，使用default的值；value表示待处理数据中的字段名或者字面值；func为函数名。

需要说明的是，上述步骤S402、S404、S405、S406，可以分别单独执行，相互之间没有先后顺序的要求。本申请实施例所列的步骤顺序，仅是一种举例说明，但并不限于此，这些步骤也可以同时执行。

步骤S407、利用步骤S404、S405、S406确定的filters、filterPattern、toTopic、fieldMap，构建实例StdConf(filters,filterPattern,toTopic,fieldMap)，并且，利用从当前配置(即步骤S401中读取的配置)中提取的所有字段，以及所述StdConf，生成元组(key,fields,fv,StdConf)。

也就是说，本申请实施例中的标准化配置文件中的每一行配置，经过本申请实施例中所述的加载子流程，都会对应一元组(key,fields,fv,StdConf)。

步骤S408、判断标准化配置文件中是否所有行的配置都被进行了上述步骤的处理，若还有未被处理的配置，则继续执行步骤S401，继续读取标准化配置文件中的下一行配置；否则，若标准化配置文件中所有配置都已经进行了上述步骤的处理，则执行步骤S409；

步骤S409、利用步骤S407中获取的元组(key,fields,fv,StdConf)构成集合，每行配置对应一元组，因此，所述集合中包括多个元组。根据集合中的key、fields，聚合转化为(key,fields,List(fv,StdConf))的结构，即将key和fields值一样的数据收集到一起，并进一步根据(key,fields,List(fv,StdConf))结构中的fv，聚合转化为(fields,Map(fv,List(StdConf)))，即对于(key,fields,List(fv,StdConf)中的List(fv,StdConf)，将fv相同的StdConf收集起来形成fv与List(StdConf)的映射，使用Map来存储，即得到Map(fv,List(StdConf))，Map(fv,List(StdConf))与fields形成元组(fields,Map(fv,List(StdConf)))。最后，收集所有的标准化配置，以fields作为键，Map(fv,List(StdConf))作为值，放到Map中即Map(fields,Map(fv,List(StdConf)))结构，将该结构记为allStdConf。

步骤S410、将配置allStdConf放到Spark广播变量中，即将allStdConf作为Spark广播变量。

综上，通过上述步骤，实现了从预先设置的标准化配置文件中，逐行读取标准化配置，并且将每一行标准化配置由JSON字符串转换为JSON对象JSONObj，利用每一JSONObj中的如下字段之一或组合构建Spark广播变量(即allStdConf)：

dataIdentity字段、fileters字段、filterPattern字段、stdMap字段、toTopic字段。

如图5所示，所述对数据执行标准化处理的子流程例如包括：

步骤S501、从stdConfs(即与data1匹配成功的标准化配置，可以有一条与data1匹配成功的标准化配置，也可以有多条与data1匹配成功的标准化配置)中读取一条记录，记为stdConf，开始对data1进行匹配；

步骤S502、根据data1，计算stdConfs中filters中所有filter的结果，即stdConf的成员有(filters,filterPattern,toTopic,fieldMap)，计算方式就是根据filter中的条件来判断待处理数据data1是否满足该条件，得到判断结果，并根据filterPattern组合这些结果，并返回组合的结果给变量fs；

步骤S503、若变量fs的值为“真”，即满足预设条件，则执行步骤S505，否则执行步骤S504；

步骤S504、判断stdConfs是否遍历完成，若遍历完成，则执行步骤S514，否则执行步骤S501；

步骤S505、获取stdConf中的fieldMap，并迭代获取fieldMap中的记录。

步骤S506、记fieldMap中的任一条记录为(stdField,SrcField)。

也就是说，本申请实施例中，stdConf中的fieldMap中有多条记录，对于每一条记录(stdField,SrcField)执行如下步骤S507～步骤S512的操作：

步骤S507、判断SrcField.pType的值，即判断SrcField结构中的pType字段的值，pType表示标准化后值的计算方式，其取值可以为：field、string、func，其中field表示SrcField中value的值为待处理数据中的字段名，目标字段直接取被处理数据中该字段的值；string表示SrcField中value的值为指定字符串，目标字段直接取该值；func表示目标字段的值是通过指定函数生成，该函数是SrcField中的func字段对应的值。

若pType字段的值值等于field，则执行步骤S508；若pType字段的值值等于string，则执行步骤S509；若pType字段的值值等于func，则执行步骤S510；

步骤S508、从SrcField中取value的值记为field1，从data1的JSON对象中获取键为field1的值，作为变量stdVal的值；

步骤S509、将SrcField.value作为变量stdVal的值，即从SrcField中取value的值作为变量stdVal的值；

步骤S510、从预设的标准化函数库中查找函数名为SrcField中func的函数，并执行该函数，将函数执行结果作为变量stdVal的值；

步骤S511、若经上面步骤S508、步骤S509或步骤S510计算，stdVal仍然为无效值(空值)，则用SrcField中defaul的值作为变量stdVal的值。

步骤S512、将目标字段名stdField和目标字段值stdVal，记为元组(stdField,stdVal)。将所有的元组(stdField,stdVal)收集到一起，调用toMap函数转换为映射Map(stdField,stdVal)，该映射为最终标准化结果。也就是说，对于目标字段是一个一个处理的，需要将所有目标字段和值收集到一起就是一个元组的list，将这个元组的list通过toMap函数转换为Map。

步骤S513、判断stdConf中的fieldMap是否遍历完成，未完成则执行步骤S505，若已完成，则执行步骤S504。

步骤S514、收集所有标准化数据结果，即收集步骤S512得到的Map(stdField,stdVal)，返回给外层流程，即继续执行上述主流程中的下一步骤：判断allStdConf中的记录是否都被遍历。

综上所述，上述通过对标准化处理的主流程、标准化配置加载的子流程及数据标准化子流程的阐述，对本申请实施例提供的整个标准化过程进行了详尽的阐述。

通过本申请实施例提供的方案，可以实现一次代码开发，之后基本不用修改代码，只需要修改配置就可以了，不需要重新开发代码，这样大大节省了后期的开发成本，后期需要关注数据业务就可以了。并且，运维也比较简单，只需要维护一套代码。

参见图6，本申请实施例提供的一种异构流数据处理方法，包括：

S101、获取待处理的实时流数据；

该步骤，例如包括上述标准化处理主流程中的步骤S301和步骤S302。

S102、当预先设置的标准化配置文件中存在与所述实时流数据匹配的标准化配置时，利用与所述实时流数据匹配的标准化配置，对所述实时流数据进行处理。

该步骤，例如包括上述标准化处理主流程中的步骤S303至步骤S309。

最后，可以采用步骤S310，收集所有标准化结果数据，并通过Kafka发出。

可选地，获取待处理的实时流数据之前，该方法还包括：从预先设置的标准化配置文件中加载标准化配置到Spark广播变量中。

也就是说，获取待处理的实时流数据之前，执行上述标准化配置加载的子流程。

可选地，通过如下方式确定与所述实时流数据匹配的标准化配置：

对于所述Spark广播变量中的每一条标准化配置，判断该标准化配置是否与所述实时流数据匹配。

可选地，对于所述Spark广播变量中的每一条标准化配置，判断该标准化配置是否与所述实时流数据匹配，具体包括：

对于所述每一条标准化配置，当所述实时流数据中存在该标准化配置中的字段，并且字段的取值相同时，确定该标准化配置与所述实时流数据匹配。

也就是说，上述步骤S304中所述的标准化配置(fields,Map(fv,List(StdConf)))中的fv，需要与所述步骤S305中的所述的fv1相等，则说明该标准化配置(fields,Map(fv,List(StdConf)))与实时流数据data1匹配。

可选地，该方法还包括：

监控所述标准化配置是否需要更新，当需要更新时，将标准化配置文件中的标准化配置更新到所述Spark广播变量中。例如上述的每次更新标准化配置文件后，可以手动触发更新，更新方式是在指定目录上建一个空std_update文件，作业监听器会监测这个文件是否存在，存在就会重新加载配置文件中的配置到Spark广播变量中。

也就是说，本申请实施例中可以从所述Spark广播变量中获取多个标准化配置，将所述多个标准化配置与所述实时流数据进行逐一匹配，利用匹配成功的标准化配置对所述实时流数据执行标准化转换。

例如上述的标准化配置allStdConf中可以有多条配置数据，本申请实施例逐一取出每条配置数据分别与data1匹配。具体包括上述标准化处理主流程中的步骤S304至步骤S306。

可选地，每一条标准化配置中包括：用于过滤掉无用数据的过滤条件(例如上述的filters)、所有过滤条件的组合方式(例如上述的filterPattern)、数据处理方式(例如上述的fieldMap)，以及目标流数据的写入对象(例如上述的toTopic)；所述目标流数据为对所述实时流数据进行处理后得到的数据。

可选地，利用与所述实时流数据匹配的标准化配置，对所述实时流数据进行处理，具体包括：

对于与所述实时流数据匹配的每一条标准化配置，分别判断所述实时流数据是否满足该条标准化配置中的每一过滤条件，得到每一过滤条件对应的判断结果，并根据所述组合方式组合所述判断结果，得到组合结果(例如上述的fs)；

当所述组合结果满足预设条件(例如上述的变量fs的值为“真”)时，按照所述数据处理方式对所述实时流数据进行处理。

最后，将处理结果收集起来写入toTopic，即通过Kafka发出。

可选地，从预先设置的标准化配置文件中加载标准化配置到Spark广播变量中，具体包括：

从预先设置的标准化配置文件中，逐行读取标准化配置；

对每一行标准化配置，将该行标准化配置由JSON字符串转换为JSON对象(例如所述的JSONObj)，利用所述JSON对象中的如下字段之一或组合构建Spark广播变量：

用于识别实时流数据是否与该行标准化配置相匹配的第一字段(例如所述的dataIdentity字段)；

用于表示对所述类型的实时流数据的过滤条件的第二字段(例如所述的fileters字段)；

用于表示所述第二字段中所有过滤条件的组合方式的第三字段(例如所述的filterPattern字段)；

用于表示数据处理方式的第四字段(例如所述的stdMap字段)；

用于表示目标流数据的写入对象的第五字段(例如所述的toTopic字段)，例如第五字段用于表示目标流数据写入到的目标Kafka的主题。

例如，从预先设置的标准化配置文件中加载标准化配置到Spark广播变量中，具体包括上述标准化配置加载的子流程中所述步骤，此处不再赘述。

与上述方法相对应地(相应的解释说明或举例说明，后续不再赘述)，参见图7，本申请实施例提供的一种数据处理装置，包括：

第一单元21，用于获取待处理的实时流数据；

第二单元22，用于当预先设置的标准化配置文件中存在与所述实时流数据匹配的标准化配置时，利用与所述实时流数据匹配的标准化配置，对所述实时流数据进行处理。

可选地，获取待处理的实时流数据之前，第一单元21还用于：从预先设置的标准化配置文件中加载标准化配置到Spark广播变量中。

可选地，第二单元22通过如下方式确定与所述实时流数据匹配的标准化配置：

对于所述Spark广播变量中的每一条标准化配置，判断该标准化配置是否与所述实时流数据匹配。

可选地，对于所述Spark广播变量中的每一条标准化配置，判断该标准化配置是否与所述实时流数据匹配，具体包括：

对于所述每一条标准化配置，当所述实时流数据中存在该标准化配置中的字段，并且字段的取值相同时，确定该标准化配置与所述实时流数据匹配。

可选地，第一单元21还用于：

监控所述标准化配置是否需要更新，当需要更新时，将标准化配置文件中的标准化配置更新到所述Spark广播变量中。

可选地，每一条标准化配置中包括：用于过滤掉无用数据的过滤条件、所有过滤条件的组合方式、数据处理方式，以及目标流数据的写入对象；所述目标流数据为对所述实时流数据进行处理后得到的数据。

可选地，利用与所述实时流数据匹配的标准化配置，对所述实时流数据进行处理，具体包括：

对于与所述实时流数据匹配的每一条标准化配置，分别判断所述实时流数据是否满足该条标准化配置中的每一过滤条件，得到每一过滤条件对应的判断结果，并根据所述组合方式组合所述判断结果，得到组合结果；

当所述组合结果满足预设条件时，按照所述数据处理方式对所述实时流数据进行处理。

可选地，从预先设置的标准化配置文件中加载标准化配置到Spark广播变量中，具体包括：

从预先设置的标准化配置文件中，逐行读取标准化配置；

对每一行标准化配置，将该行标准化配置由JSON字符串转换为JSON对象，利用所述JSON对象中的如下字段之一或组合构建Spark广播变量：

用于识别实时流数据是否与该行标准化配置相匹配的第一字段；

用于表示对所述类型的实时流数据的过滤条件的第二字段；

用于表示所述第二字段中所有过滤条件的组合方式的第三字段；

用于表示数据处理方式的第四字段；

用于表示目标流数据的写入对象的第五字段。

需要说明的是，本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

本申请实施例提供了另一种异构流数据处理装置，该装置也可以称为一种计算设备，该计算设备具体可以为桌面计算机、便携式计算机、智能手机、平板电脑、个人数字助理(Personal Digital Assistant，PDA)等。例如，该计算设备可以包括中央处理器(CenterProcessing Unit，CPU)、存储器，还可以包括输入/输出设备等(图中未示出)，输入设备可以包括键盘、鼠标、触摸屏等，输出设备可以包括显示设备，如液晶显示器(Liquid CrystalDisplay，LCD)、阴极射线管(Cathode Ray Tube，CRT)等。

例如，参见图8，本申请实施例提供了另一种异构流数据处理装置包括：

处理器500，用于读取存储器520中的程序，执行下列过程：

获取待处理的实时流数据；

当预先设置的标准化配置文件中存在与所述实时流数据匹配的标准化配置时，利用与所述实时流数据匹配的标准化配置，对所述实时流数据进行处理。

可选地，获取待处理的实时流数据之前，处理器500，还用于读取存储器520中的程序，执行下列过程：从预先设置的标准化配置文件中加载标准化配置到Spark广播变量中。

可选地，处理器500通过如下方式确定与所述实时流数据匹配的标准化配置：

对于所述Spark广播变量中的每一条标准化配置，判断该标准化配置是否与所述实时流数据匹配。

可选地，对于所述Spark广播变量中的每一条标准化配置，判断该标准化配置是否与所述实时流数据匹配，具体包括：

对于所述每一条标准化配置，当所述实时流数据中存在该标准化配置中的字段，并且字段的取值相同时，确定该标准化配置与所述实时流数据匹配。

可选地，处理器500，还用于读取存储器520中的程序，执行下列过程：：

监控所述标准化配置是否需要更新，当需要更新时，将标准化配置文件中的标准化配置更新到所述Spark广播变量中。

可选地，每一条标准化配置中包括：用于过滤掉无用数据的过滤条件、所有过滤条件的组合方式、数据处理方式，以及目标流数据的写入对象；所述目标流数据为对所述实时流数据进行处理后得到的数据。

可选地，利用与所述实时流数据匹配的标准化配置，对所述实时流数据进行处理，具体包括：

对于与所述实时流数据匹配的每一条标准化配置，分别判断所述实时流数据是否满足该条标准化配置中的每一过滤条件，得到每一过滤条件对应的判断结果，并根据所述组合方式组合所述判断结果，得到组合结果；

当所述组合结果满足预设条件时，按照所述数据处理方式对所述实时流数据进行处理。

可选地，从预先设置的标准化配置文件中加载标准化配置到Spark广播变量中，具体包括：

从预先设置的标准化配置文件中，逐行读取标准化配置；

对每一行标准化配置，将该行标准化配置由JSON字符串转换为JSON对象，利用所述JSON对象中的如下字段之一或组合构建Spark广播变量：

用于识别实时流数据是否与该行标准化配置相匹配的第一字段；

用于表示对所述类型的实时流数据的过滤条件的第二字段；

用于表示所述第二字段中所有过滤条件的组合方式的第三字段；

用于表示数据处理方式的第四字段；

用于表示目标流数据的写入对象的第五字段。

收发机510，用于在处理器500的控制下接收和发送数据。

其中，在图8中，总线架构可以包括任意数量的互联的总线和桥，具体由处理器500代表的一个或多个处理器和存储器520代表的存储器的各种电路链接在一起。总线架构还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口提供接口。收发机510可以是多个元件，即包括发送机和接收机，提供用于在传输介质上与各种其他装置通信的单元。处理器500负责管理总线架构和通常的处理，存储器520可以存储处理器500在执行操作时所使用的数据。

处理器500可以是中央处埋器(CPU)、专用集成电路(Application SpecificIntegrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或复杂可编程逻辑器件(Complex Programmable Logic Device，CPLD)。

本申请实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述实施例中的任一种异构流数据处理方法。所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

本申请实施例提供了一种计算机可读存储介质，用于储存为上述本申请实施例提供的装置所用的计算机程序指令，其包含用于执行上述本申请实施例提供的任一方法的程序。所述计算机可读存储介质，可以是非暂时性计算机可读介质。

所述计算机可读存储介质可以是计算机能够存取的任何可用介质或数据存储设备，包括但不限于磁性存储器(例如软盘、硬盘、磁带、磁光盘(MO)等)、光学存储器(例如CD、DVD、BD、HVD等)、以及半导体存储器(例如ROM、EPROM、EEPROM、非易失性存储器(NANDFLASH)、固态硬盘(SSD))等。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (12)

1.一种异构流数据处理方法，其特征在于，该方法包括：

获取待处理的实时流数据；

当预先设置的标准化配置文件中存在与所述实时流数据匹配的标准化配置时，利用与所述实时流数据匹配的标准化配置，对所述实时流数据进行处理。

2.根据权利要求1所述的方法，其特征在于，获取待处理的实时流数据之前，该方法还包括：从预先设置的标准化配置文件中加载标准化配置到Spark广播变量中。

3.根据权利要求2所述的方法，其特征在于，通过如下方式确定与所述实时流数据匹配的标准化配置：

对于所述Spark广播变量中的每一条标准化配置，判断该标准化配置是否与所述实时流数据匹配。

4.根据权利要求3所述的方法，其特征在于，对于所述Spark广播变量中的每一条标准化配置，判断该标准化配置是否与所述实时流数据匹配，具体包括：

对于所述每一条标准化配置，当所述实时流数据中存在该标准化配置中的字段，并且字段的取值相同时，确定该标准化配置与所述实时流数据匹配。

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

监控所述标准化配置是否需要更新，当需要更新时，将标准化配置文件中的标准化配置更新到所述Spark广播变量中。

6.根据权利要求1所述的方法，其特征在于，每一条标准化配置中包括：用于过滤掉无用数据的过滤条件、所有过滤条件的组合方式、数据处理方式，以及目标流数据的写入对象；所述目标流数据为对所述实时流数据进行处理后得到的数据。

7.根据权利要求6所述的方法，其特征在于，利用与所述实时流数据匹配的标准化配置，对所述实时流数据进行处理，具体包括：

对于与所述实时流数据匹配的每一条标准化配置，分别判断所述实时流数据是否满足该条标准化配置中的每一过滤条件，得到每一过滤条件对应的判断结果，并根据所述组合方式组合所述判断结果，得到组合结果；

当所述组合结果满足预设条件时，按照所述数据处理方式对所述实时流数据进行处理。

8.根据权利要求2所述的方法，其特征在于，从预先设置的标准化配置文件中加载标准化配置到Spark广播变量中，具体包括：

从预先设置的标准化配置文件中，逐行读取标准化配置；

对每一行标准化配置，将该行标准化配置由JSON字符串转换为JSON对象，利用所述JSON对象中的如下字段之一或组合构建Spark广播变量：

用于识别实时流数据是否与该行标准化配置相匹配的第一字段；

用于表示对所述类型的实时流数据的过滤条件的第二字段；

用于表示所述第二字段中所有过滤条件的组合方式的第三字段；

用于表示数据处理方式的第四字段；

用于表示目标流数据的写入对象的第五字段。

9.一种异构流数据处理装置，其特征在于，包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行权利要求1至8任一项所述的方法。

10.一种用于计算机的计算机程序产品，包括：软件代码部分，当所述产品在所述计算机上运行时，所述软件代码部分用于执行根据权利要求1至8任一项所述的方法。

11.根据权利要求10的计算机程序产品，其中，

所述计算机程序产品包括在其上存储有所述软件代码部分的计算机可读介质，和/或，

所述计算机程序产品能够通过上传过程、下载过程和推送过程中的至少一个经由网络直接加载到所述计算机的内部存储器中和/或发送。

12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令用于使所述计算机执行权利要求1至8任一项所述的方法。

Images