CN113360554A - 一种数据抽取、转换和加载etl的方法和设备 - Google Patents

Abstract

本申请适用于数据处理技术领域，提供了一种数据抽取、转换和加载ETL方法及设备。方法包括获取待处理日志文件；获取业务处理规则，并对所述业务处理规则进行解析处理生成对应的流式处理链；在消费所述待处理日志文件的日志记录时，执行所述流式处理链，生成所述日志记录的以上下文树存储的运算结果；提取所述上下文树中各节点路径上的所有变量，生成所述日志记录的处理结果；将所述处理结果加载至目标数据库。本申请实施例提供的ETL方法通过流式处理链与树状上下文实现了配置代替开发，极大的减少了ETL数据处理过程中的代码开发工作量，提高了数据处理效率。

Description

一种数据抽取、转换和加载ETL的方法和设备

技术领域

本申请属于数据处理技术领域，尤其涉及一种数据抽取、转换和加载ETL的方法和设备。

背景技术

随着企业应用复杂性的上升和微服务架构的流行，数据正变得越来越以应用为中心，在进行跨应用的数据实时分析处理时，需要将分布的、异构的数据源中的数据，抽取到临时数据库后进行清洗、转换和集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础，此过程被称为ETL，即数据的抽取(Extract)、转换(Transform)和加载(Load)。

目前的ETL的数据处理系统中，通常是采集数据后基于Flink或Spark等实时处理框架进行后续的数据计算和转换。

其中，Flink和Spark通常通过DAG(有向无环图)组织业务规则，以实现灵活的业务需求，但这需要人工编写大量的代码去实现业务规则，业务规则一旦改变，就需要修改代码，尤其是业务规则中具备大量相同的处理逻辑的时候，带来了大量的工作冗余，导致基于ETL的数据处理过程效率低下。

发明内容

有鉴于此，本申请实施例提供了一种数据抽取、转换和加载ETL方法和设备，以解决现有技术中ETL处理效率低的技术问题。

第一方面，本申请实施例提供了一种数据抽取、转换和加载ETL方法，包括：

获取待处理日志文件；其中，待处理日志文件包含至少一条日志记录；

获取业务处理规则，并对业务处理规则进行解析处理生成对应的流式处理链；其中，流式处理链包含业务处理规则中预设转换算子的逻辑表达式；

在消费待处理日志文件的日志记录时，执行流式处理链，生成日志记录的以上下文树存储的运算结果；其中，上下文树至少包含一个根节点，上下文树的节点用于保存描述所述运算结果的变量；

提取上下文树中各节点路径上的所有变量，生成日志记录的处理结果；

将处理结果加载至目标数据库。

在第一方面的一种可能的实现方式中，获取待处理日志文件，包括：

将采集到的日志数据按照日志主题进行分类，得到多个日志文件；

从预设配置文件中查找各所述日志主题的数据连接规则；

针对每个日志文件，根据该日志文件对应的数据连接规则对所述日志文件中的日志数据进行解析处理，生成多条日志记录，并将所述多条日志记录组合生成待处理日志文件。

在第一方面的一种可能的实现方式中，获取业务处理规则，并对业务处理规则进行解析处理生成对应的流式处理链，包括：

从预设配置文件中查找各日志主题的业务处理规则；

基于规则引擎对各业务处理规则进行解析处理，生成对应的流式处理链。

在第一方面的一种可能的实现方式中，在消费待处理日志文件的日志记录时，执行流式处理链，生成日志记录的以上下文树存储的运算结果，包括：

接收消费者发送的日志订阅请求；其中，日志订阅请求包含目标日志主题；

从预设配置文件中查找目标日志主题对应的第一待处理日志文件和对应的第一流式处理链；

针对第一待处理日志文件中的每条日志记录，基于第一流式处理链对日志记录进行逻辑运算，将日志记录分裂为变量群组来产生上下文树，并将上下文树保存为所述日志记录的运算结果。

在第一方面的一种可能的实现方式中，提取运算结果中各节点路径上包含的数据，生成对应的处理结果，包括：

在上下文树包含叶节点的情况下，遍历上下文树中所有的叶节点，提取每个叶节点至根节点路径上的变量，生成变量集；

根据预设规则识别所述变量集中的元数据，生成对应日志记录的处理结果；其中，元数据根据预设配置文件中数据存储要求确定。

在第一方面的一种可能的实现方式中，提取运算结果中各节点路径上包含的数据，生成对应的处理结果，包括：

在上下文树包含叶节点的情况下，遍历上下文树中所有的叶节点，提取每个叶节点至所述根节点路径上的变量，生成变量集；

识别变量集中的元数据，生成对应所述日志记录的处理结果。

在第一方面的一种可能的实现方式中，将处理结果加载至目标数据库，包括：

根据所述目标日志主题确定目标数据库；

从预设配置文件中查找所述目标数据库的元数据类型；

根据元数据类型对处理结果进行格式转换，并将转换后的数据加载至目标数据库。

在第一方面的一种可能的实现方式中，预设转换算子包括下述至少一种：

过滤filter算子、map算子、flatmap算子以及选择select算子。

第二方面，本申请实施例提供了一种数据抽取、转换和加载ETL装置，包括：

数据获取模块，用于获取待处理日志文件；其中，待处理日志文件包含至少一条日志记录；

规则获取模块，用于获取业务处理规则，并对业务处理规则进行解析处理生成对应的流式处理链；其中，流式处理链包含业务处理规则中预设转换算子的逻辑表达式；

数据运算模块，用于在消费待处理日志文件的日志记录时，执行流式处理链，生成日志记录的以上下文树存储的运算结果；其中，上下文树至少包含一个根节点，上下文树的节点用于保存描述所述运算结果的变量；

数据生成模块，用于提取上下文树中各节点路径上的所有变量，生成日志记录的处理结果；

数据加载模块，用于将处理结果加载至目标数据库。

第三方面，本申请实施例提供了一种数据抽取、转换和加载ETL设备，包括存储器、处理器以及存储在存储器中并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述第一方面任一项方法的步骤。

第四方面，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器执行时实现上述第一方面任一项方法的步骤。

第五方面，本申请实施例提供了一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行上述第一方面中任一项的方法。

本申请实施例提供的数据抽取、转换和加载ETL方法，将业务规则解析为流式处理链，流式处理链包含了业务处理规则中预设转换算子的逻辑表达式，可以根据该流式处理链中对待处理日志文件中的日志记录进行运算，运算过程中基于上下文树的不同路径实现信息分裂，达到与DAG(有向无环图)相同的处理效果。该ETL方法通过将业务规则解析为流式处理链，用户仅需要配置规则即可获得业务规则中包含的预设转换算子的处理逻辑，通过流式处理链与树状上下文实现了配置代替开发，极大的减少了ETL数据处理过程中的代码开发工作量，提高了数据处理效率。

可以理解的是，上述第二方面至第五方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

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

图1是本申请一实施例提供的ETL系统架构示意图；

图2是本申请一实施例提供的ETL系统的硬件组成示意图；

图3是本申请一实施例提供的ETL方法的流程示意图；

图4是本申请一实施例提供的获得待处理日志文件的流程示意图；

图5是本申请一实施例提供的生成日志记录处理结果的流程示意图；

图6是本申请一实施例提供的生成日志记录处理结果的流程示意图；

图7是本申请一实施例提供的将处理结果加载至目标数据库的流程示意图；

图8是本申请一实施例提供的数据抽取、转换和加载ETL装置的结构示意图；

图9是本申请一实施例提供的数据抽取、转换和加载ETL设备的结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

随着企业应用复杂性的上升和微服务架构的流行，数据正变得越来越以应用为中心，以应用为中心的数据持久化架构，在带来可伸缩性好处的同时，也给数据的实时分析计算带来了障碍。

由于数据散落在不同的数据库、消息队列、文件系统中，如果直接访问这些数据，会遇到可访问性和数据传输延迟等问题。因此，在进行跨应用的数据实时分析处理时，需要将分布的、异构的数据源中的数据，抽取到临时数据库后进行清洗、转换和集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础，此过程被称为ETL，即数据的抽取(Extract)、转换(Transform)和加载(Load)。

当各类数据从源端抽取后，首先应当被写入一个临时数据库，临时数据库的作用主要有两点：首先，临时数据库将异构的数据源数据存储为统一的格式，并且为后继的处理提供一致的访问接口。这就将处理逻辑和数据源解耦开来，同时屏蔽了数据抽取过程中可能发生的异常对后继作业的影响。其次，临时数据库独立于数据源，可被多次访问，亦可根据业务需要缓存全部或一定期限的原始数据，这为转换分析提供了更高的灵活度。当业务需求或规则发生变化时，无需重复读取源端数据，直接基于临时数据库就可以开发新的模型和应用。

临时数据库可基于任意支持海量/高可用的文件系统、数据仓库或者消息队列构建，常见的方案包括Flume、HDFS、Kafka等。

当数据被写入临时数据库后，典型的后继处理场景为数据流服务，即基于流式计算引擎，对从临时数据库读取的数据进一步加工计算，并将结果实时输出给下游应用系统或目标数据库。可用的流式计算流式计算引擎包括Spark或Flink等。

请一并参阅图1和图2，图1为本申请实施例提供的ETL系统架构示意图,图2为本申请实施例提供的ETL系统的硬件组成示意图。

如图1所示，ETL系统包括数据采集模块、Kafka处理模块、数据处理模块、数据存储模块以及配置中心，分别对应于图2中的ETL服务器中的数据采集模块、Kafka集群、Flink集群、HDFS集群以及ETL服务器中的配置中心。

数据采集模块用于从异构数据源中采集文件数据，并将不同数据源得到的文件数据加载为多条计算引擎所需日记记录，并推送至Kafka处理模块。数据采集模块可以基于实时数据采集架构实现，例如Flume日志采集系统，Flume采用分布式、高可靠和高可用的海量日志采集和传输系统对多源数据进行实时接收。实际应用时，可以将Flume系统部署在ETL服务器上，以实现数据采集模块的相关功能。

Kafka处理模块为一个分布式消息队列处理模块，通过消息的生产者和消费者实现消息的扭转，具体可以通过Kafka集群实现。

数据处理模块用于进行数据的转化，具体体现根据业务需求对数据进行计算处理，并将结果实时输出给下游应用系统或目标数据库。本功能模块可以基于Flink集群实现，其中Flink是一个分布式流数据处理框架。

数据存储模块用于进行数据的缓存以及将数据处理模块的处理结果以标准的接口提供给第三方数据库。本功能模块可以通过部署了HDFS的集群实现，其中HDFS是基于Hadoop的分布式文件系统，能够提供高吞吐量的数据访问，非常适合大规模数据集上的应用。

配置中心用于进行数据抽取、转换以及加载的相关配置，具体通过配置文件预先设置。示例性的，配置文件可以包括规则配置要求、目标配置要求以及通用配置要求，其中规则配置要求用于描述数据转换的业务规则、校验规则等，目标配置用于描述数据处理完毕后的存储位置以及存储方式等；通用配置用于描述通用的数据存储框架要求，例如Kafka中的主题设置要求。

目前基于ETL的数据处理方法，通常基于Flink或Spark作为数据流服务的实时计算引擎，其中，Flink和Spark通常通过DAG(有向无环图)组织业务规则，以实现灵活的业务需求，但这需要人工的编写大量的代码去实现业务规则，规则一旦改变，就需要改变代码，带来大量的工作冗余，尤其是业务规则中具备大量相同的处理逻辑的时候，导致整个ETL的数据处理过程效率低下。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行示例性说明。值得说明的是，下文中列举的具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

图3为本申请一实施例提供的数据抽取、转换和加载ETL方法的流程示意图，如图3所示，该数据抽取、转换和加载ETL方法包括：

S10、获取待处理日志文件；其中待处理日志文件包含至少一条日志记录。

本实施例中，图2中的ETL服务器可以从不同的客户端(如客户端1、客户端2、……、客户端n)采集日志数据，具体可以体现为接收不同客户端发送的多个日志文件，并对获得到的日志文件进行数据预处理，获得待处理日志文件。

其中，数据预处理可以包括脏数据的处理、数据格式的转化、日志数据的初步过滤等一种或多种。

例如，日志统计文件中的日志数据中可能会包含脏数据，需要对数据进行基本的校验，清除脏数据。

例如，如仅需对统计日志进行后端的业务处理时，则可以通过数据预处理中的过滤功能去除除统计日志以外的其他日志文件。

本实施例中，可以基于Flume日志采集工具日志统计文件，Flume日志采集工具实时的采集日志数据，并根据采集到的日志数据进行相应的预处理。其中，Flume日志采集工具部署在ETL服务器上。

本实施例中，可以进一步对预处理后的日志文件按照日志主题进行分类，例如根据统计对象进行分类，得到以统计对象分类的多个待处理日志文本，以便后续对不同的统计对象采取不同的业务处理规则。

本实施例中ETL服务器根据预设配置文件中指定的日志主题对采集的日志文件进行过滤。

S20、获取业务处理规则，并对业务处理规则进行解析处理生成对应的流式处理链，该流式处理链包含业务处理规则中预设转换算子的逻辑表达式；

本实施例中，业务处理规则可以预先存储在ETL服务器的配置文件中。待处理日志文件中的每条记录通过对应的业务规则转换为实际的行为，每一条业务处理规则可以包括统计指标、实体关系以及序列。

其中，统计指标是指对某个或某几个字段在特定窗口内做聚合，例如一小时内的某用户的登录次数或者某个时间段内连续登录失败的次数。实体关系关注的是两个实体之间的关联关系；实体可以是用户，部门，设备，邮件，地理位置等。那么某个用户使用了某台设备就是一个实体关系；某封邮件发给了某个用户也是一个实体关系。

本实施例中，获取业务处理规则可以为针对不同主题的日志文件读取其对应的业务处理规则，然后通过规则引擎对各业务处理规则进行解析处理，生成对应的流式处理链。

其中，规则引擎可以为Aviator表达式执行引擎，Aviator规则引擎可以有多个，均部署在ETL服务器上。不同的规则引擎用于读取对应的业务处理规则，并对该业务处理规则进行解析处理，生成各业务处理规则的流式处理链。

示例性的，规则引擎个数可以与根据日志主题划分得到的待处理日志文件个数一一对应，各规则引擎分别从预设配置文件中查找与各日志主题的业务处理规则。

本实施例中，流式处理链是以链表形式连接的处理逻辑，包含了业务处理规则中预设转换算子的逻辑表达式。预设转换算子可以包括下述至少一种：过滤filter算子、map算子、flatmap算子以及选择select算子。

filter过滤算子对每个元素进行过滤，过滤的过程使用一个filter函数进行逻辑判断。对于输入的每个元素，如果filter函数返回True，则保留该元素，如果filter函数返回False，则丢弃该元素。

map算子用于对一个数据流中的每个元素使用用户自定义的map函数进行处理，每个输入元素对应一个输出元素，最终整个数据流被转换成一个新的数据流。其中，输出的数据流类型可能和输入的数据流不同。

flatMap算子和map算子类似，输入都是数据流中的每个元素，flatMap算子的输出可以是零个、一个或多个元素，当输出元素是一个列表时，flatMap会将列表展平。例如，flatMap输入是包含圆形或正方形的列表，flatMap过滤掉圆形，正方形列表被展平，以单个元素的形式输出。通过flatMap可以实现元素的分裂，例如将一个散列表分类为多个散列表。

S30、在消费待处理日志文件的日志记录时，执行流式处理链，生成日志记录的以上下文树存储的运算结果；其中，上下文树至少包含一个根节点，上下文树的节点用于保存描述所述运算结果的变量。

本实施例中，在消费待处理日志文件的日志记录时，具体可以指Kafka中的消费者Consumer发送日志订阅请求的时刻，此时消费者Consumer拉取目标主题的日志记录，并发送至图2中的Flink集群中。

Kafka是一个分布式集群，Kafka的生成者Producer和消费者Consumer可以看做是Kafka集群的客户端，Producer和Consumer通过TCP协议与Kafka集群通信。

本实施例中，ETL服务器将待处理日志中的日志记录发送至Kafka集群，并根据待处理日志文件的日志主题写入Kafka集群的对应主题中，然后订阅主题的消费者Consumer以拉取(pull)的方式进行消费。其中，消费具体可以指生成数据报表、数据挖掘、数据应用以及仪表盘显示等。

本实施例中，针对待处理日志文件中的每条日志记录，Flink集群执行流式处理链，生成该日志记录的以上下文树存储的运算结果。

Flink集群执行流式处理链，可以是指将日志记录中的数据以流式的方式通过该流式处理链，生成运算结果，由于流式处理链包含了至少一个预设转换算子的逻辑表达式，故在运算过程中，根据该预设转换算子的函数对日志记录的数据进行转换，生成运算结果。

输入的日志记录为原始根节点，若预设转换算子仅包括过滤filter算子、map算子、选择select算子中的一个或多个，则运算完成后每个输入元素对应一个输出元素，具体体现为日志记录以散列表的形式输入，输出还是仅为一个散列表，此时运算结果的上下文树还是仅包含根节点。

若预设转换算子包含flatMap算子，flatMap算子的单个输入元素的输出可以多个元素，具体体现为日志记录以散列表的形式输入，输出还是可以为多个散列表，则每个分裂后的散列表构成上下文树的枝节点或叶节点，未分裂的散列表仍然保留在根节点上。

S40、提取上下文树中各节点路径上的所有变量，生成日志记录的处理结果。

上下文树中的每一个叶节点代表一条待发送到后端的记录，而上下文树的叶节点到根节点形成的路径上包含组织该条待发送记录的变量。若上下文树仅包括根节点，则表示仅包含一条待发送的记录，根节点中包含的变量用于组织该记录。

本实施例中，提取上下文树中各节点路径上的所有变量，生成日志记录的处理结果，具体可以指遍历上下文树的叶节点，提取每个叶节点至根节点路径上的所有变量，生成上下文树对应的日志记录的处理结果。

若上下文树中仅包含的根节点，则根据根节点中包含的变量生成处理结果。

S50、将处理结果加载至目标数据库。

为了实现处理结果的共享，需要将处理结果以标准的接口提供给目标数据库。目标数据库可以有配置文件进行预先设置。

可选地，将处理结果加载至目标数据库后将该条日志记录的处理结果销毁，释放内存空间。

本申请实施例提供的数据抽取、转换和加载ETL方法，将业务规则解析为流式处理链，流式处理链包含了业务处理规则中预设转换算子的逻辑表达式，可以根据该流式处理链中对待处理日志文件中的日志记录进行运算，运算过程中基于上下文树的不同路径实现信息分裂，达到与DAG(有向无环图)相同的处理效果。该ETL方法通过将业务规则解析为流式处理链，用户仅需要配置规则即可获得业务规则中包含的预设转换算子的处理逻辑，通过流式处理链与树状上下文实现了配置代替开发，极大的减少了ETL数据处理过程中的代码开发工作量，提高了数据处理效率。

图4是本申请一实施例提供的获得待处理日志文件的流程示意图；描述了图3实施例中步骤10中获得待处理日志文件的一种可能性实施方式，如图4所示，获得待处理日志文件，包括：

S101、将采集到的日志数据按照日志主题进行分类，得到多个日志文件。

本实施例中，基于Flume日志采集工具实时的采集日志数据，根据采集到的日志数据进行相应的计算和处理。

Flume日志采集工具部署在ETL服务器上，Flume在采集到原始日志数据后，首先会对原始日志文件进行实时切片，切片策略包括按时间切片、按照日志主题切片等。本实施例中，Flume按照日志主题对采集到的原始数据进行切片(分类)，得到多个日志文件。

日志文件中通常记录有日期、时间、统计对象以及动作等相关操作的描述信息，示例性的，可以将统计对象作为日志主题，将原始的日志数据划分以统计对象进行区分的多个日志文件，不同统计对象的日志文件的业务转换规则可能不同。

本实施例，在获得多个日志文件后，可以通过自定义Flume插件实时读取，日志文件中的日志数据逐行的写入Kafka集群。

S102、从预设配置文件中查找各日志主题的数据连接规则。

本实施例中，预设配置文件为图2所示实施例中配置中心中存储的配置文件。具体地，从配置文件的通用配置中查找各日志主题的数据连接规则。

S103、针对每个日志文件，根据该日志文件对应的数据连接规则对日志文件中的日志数据进行解析处理，生成多条日志记录，并将多条日志记录组合生成待处理日志文件。

本实施例中，根据日志文件对应的数据连接规则对日志文件中的日志数据进行解析处理，生成多条日志记录，是指将异常多事跨多行的日志数据组织为一条日志记录。

本实施例提供的获取待处理日志文件的方法，基于日志主题对采集到的日志数据进行分类，得到多个日志文件，以使得每个日志文件可以基于相同的业务转换规则进行处理，降低了的每个日志文件的处理难度，也便于对业务转换规则进行开发。

图5是本申请一实施例提供的生成日志记录运算结果的流程示意图；描述了图3实施例中步骤30中生成日志记录的以上下文树存储的运算结果一种可能性实施方式，如图5所示，在消费待处理日志文件的日志记录时，执行流式处理链，生成日志记录的以上下文树存储的运算结果，包括：

S301、接收消费者发送的日志订阅请求；其中，日志订阅请求包含目标日志主题。

获取日志并对日志进行分析处理的终端可以被称为消费者。目标日志主题即消费者所管线的日志所属的主题。

本实施例中，消费者可以通过Redis的订阅命令发送日志订阅请求。Redis(RemoteDictionary Server)是一种高性能的键(key)-值(value)数据库，Redis可以通过Publish(发布)、Subscribe(订阅)和Psubscribe(模式订阅)等命令实现发布和订阅功能。

S302、从预设配置文件中查找目标日志主题对应的第一待处理日志文件和对应的第一流式处理链。

本步骤的目的在于通过日志主题实现待处理文件和流式处理链的对应关系。

S303、针对第一待处理日志文件中的每条日志记录，基于第一流式处理链对日志记录进行逻辑运算，将日志记录分裂为变量群组来产生上下文树，并将上下文树保存为日志记录的运算结果。

本实施例中，基于Flink实现待处理日志文件中日志记录的单条处理。

本实施例中，将日志记录中原始的采集信息作为根节点，生成初始上下文树；然后将日志记录中的数据以流式的方式通过第一流式处理链，将日志记录分裂为变量群组以动态的修改初始上下文树，生成最终的表征运算结果的上下文树。

其中，上下文树中可以包括叶节点、枝节点和根节点，其中一根枝节点上的所有叶节点共享枝节点上的变量，所述的枝节点可以共享根节点上的变量。

本实施例通过上下文树叶节点的不同路径达到日志记录数据分裂的目的，同时通过上下文树的节点保存记录文件的原始采集信息和过程变量。

图6是本申请一实施例提供的生成日志记录运算结果的流程示意图；描述了图3实施例中步骤40中生成处理结果一种可能性实施方式，如图6所示，提取运算结果中各节点路径上包含的数据，生成对应的处理结果，包括：

S401、在上下文树包含叶节点的情况下，遍历上下文树中所有的叶节点，提取每个叶节点至根节点路径上的变量，生成变量集。

当流式处理链中包括flatMap算子的时候，基于该流式处理链对日志记录进行运算生成的上下文树中可以包括叶节点。

上下文树中的每一个叶节点代表一条待发送到后端的记录，而上下文树的叶节点到根节点形成的路径上包含表示组织该条待发送的记录的变量。遍历上下文树中所有的叶节点，提取每个叶节点至根节点路径上的变量，生成变量集。

S402、识别变量集中的元数据，生成对应日志记录的处理结果；其中，元数据根据预设配置文件中数据存储要求确定。

本步骤中，元数据(Metadata)，又称中介数据、中继数据，是描述数据的数据。主要是描述数据属性的信息，用于支持如指示存储位置、历史数据等功能。同时，元数据也是一种用于提供某种资源的有关信息的结构数据。例如元数据可以用于描述不同数据库中的数据结构。

本实施例中，通过元数据定义数据结构，不同数据库需要的元数据类型不同，每种数据库需要的元数据类型也由配置文件预先设置。例如，HDFS集群需要分区键数据，而Kafka需要数据具有分发键和时间戳。

本步骤的目的是识别变量集中的所有的元数据，生成元数据集，然后将日志记录的处理结果以元数据集和域两种形式保存。其中元数据的类型可以在配置文件查询获得。

图7是本申请一实施例提供的将处理结果加载至目标数据库的流程示意图；描述了图3实施例中步骤50中生成处理结果一种可能性实施方式，如图7所示，将处理结果加载至目标数据库，包括：

S501、根据目标日志主题确定目标数据库。

不同主题的日志文件可以存储到不同的第三方数据库。日志主题与数据库的对应关系预先存储在配置文件中，可以由用户预先设置。

可以理解的是，本步骤中，根据目标日志主题确定目标数据库具体是指，根据当前处理的日志记录所属的待处理日志文件对应的日志主题确定目标数据库。

S502、从预设配置文件中查找目标数据库的元数据类型。

用于描述不同数据库数据结构的元数据类型不同。例如，HDFS集群需要分区键数据，而Kafka需要数据具有分发分发键和时间戳。

S503、根据元数据类型对处理结果进行格式转换，并将转换后的数据加载至目标数据库。

本实施例中，根据元数据类型对处理结果进行格式转换，具体是指从图6实施例中获得元数据集中确定上述元数据类型，例如分区键数据的具体“值”，然后将该值与图6实施例中获得域数据结合，生成满足目标数据库格式要求的待加载数据，然后将该数据加载至目标数据库。

本实施例提供的待处理结果发送方法，通过元数据实现了处理数据中域数据的共享，不需要为多个发送目标重复处理结果中所有数据的转换，实现了高效处理。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

基于上述实施例所提供的数据抽取、转换和加载ETL方法，本发明实施例进一步给出实现上述方法实施例的装置实施例。

图8为本申请一实施例提供的数据抽取、转换和加载ETL装置的结构示意图。如图8所示，数据抽取、转换和加载ETL装置包括数据获取模块801，规则获取模块802、数据运算模块803、数据生成模块804以及数据加载模块805。

数据获取模块801，用于获取待处理日志文件；其中待处理日志文件包含至少一条日志记录。

规则获取模块802，用于获取业务处理规则，并对业务处理规则进行解析处理生成对应的流式处理链；其中，流式处理链包含业务处理规则中预设转换算子的逻辑表达式；

数据运算模块803，用于在消费待处理日志文件的日志记录时，执行流式处理链，生成日志记录的以上下文树存储的运算结果；其中，上下文树至少包含一个根节点，上下文树的节点用于保存描述所述运算结果的变量。

数据生成模块804，用于提取上下文树中各节点路径上的所有变量，生成日志记录的处理结果。

数据加载模块805，用于将处理结果加载至目标数据库。

本申请实施例提供的数据抽取、转换和加载ETL装置，将业务规则解析为流式处理链，流式处理链包含了业务处理规则中预设转换算子的逻辑表达式，可以根据该流式处理链中对待处理日志文件中的日志记录进行运算，运算过程中基于上下文树的不同路径实现信息分裂，达到与DAG(有向无环图)相同的处理效果。该ETL装置通过将业务规则解析为流式处理链，用户仅需要配置规则即可获得业务规则中包含的预设转换算子的处理逻辑，通过流式处理链与树状上下文实现了配置代替开发，极大的减少了ETL数据处理过程中的代码开发工作量，提高了数据处理效率。

可选地，数据获取模块801，获取待处理日志文件，包括：

将采集到的日志数据按照日志主题进行分类，得到多个日志文件；

从预设配置文件中查找各所述日志主题的数据连接规则；

针对每个日志文件，根据该日志文件对应的数据连接规则对所述日志文件中的日志数据进行解析处理，生成多条日志记录，并将所述多条日志记录组合生成待处理日志文件。

可选地，规则获取模块802获取业务处理规则，并对业务处理规则进行解析处理生成对应的流式处理链，包括：

从预设配置文件中查找各日志主题的业务处理规则；

基于规则引擎对各业务处理规则进行解析处理，生成对应的流式处理链。

可选地，预设转换算子包括下述至少一种：

过滤filter算子、map算子、flatmap算子以及选择select算子。

可选地，数据运算模块803，在消费待处理日志文件的日志记录时，执行流式处理链，生成日志记录的以上下文树存储的运算结果，包括：

接收消费者发送的日志订阅请求；其中，日志订阅请求包含目标日志主题；

从预设配置文件中查找目标日志主题对应的第一待处理日志文件和对应的第一流式处理链；

针对第一待处理日志文件中的每条日志记录，基于第一流式处理链对日志记录进行逻辑运算，将日志记录分裂为变量群组来产生上下文树，并将上下文树保存为所述日志记录的运算结果。

可选地，数据生成模块804，提取运算结果中各节点路径上包含的数据，生成对应的处理结果，包括：

在上下文树包含叶节点的情况下，遍历上下文树中所有的叶节点，提取每个叶节点至根节点路径上的变量，生成变量集；

根据预设规则识别所述变量集中的元数据，生成对应日志记录的处理结果。

可选地，数据加载模块805，将所述处理结果加载至目标数据库，包括：

根据目标日志主题确定目标数据库；

从预设配置文件中查找目标数据库的元数据类型；

根据元数据类型对处理结果进行格式转换，并将转换后的数据加载至目标数据库

图8所示实施例提供的数据抽取、转换和加载ETL装置，可用于执行上述方法实施例中的技术方案，其实现原理和技术效果类似，本实施例此处不再赘述。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

图9是本申请一实施例提供的数据抽取、转换和加载ETL设备的示意图。如图9所示，该实施例的数据抽取、转换和加载ETL设备90包括：至少一个处理器901、存储器902以及存储在所述存储器902中并可在所述处理器901上运行的计算机程序。数据抽取、转换和加载ETL设备还包括通信部件903，其中，处理器901、存储器902以及通信部件903通过总线904连接。

处理器901执行所述计算机程序时实现上述各个数据抽取、转换和加载ETL方法实施例中的步骤，例如图3所示实施例中的步骤S10至步骤S50。或者，处理器901执行计算机程序时实现上述各装置实施例中各模块/单元的功能，例如图8所示模块801至805的功能。

示例性的，计算机程序可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器902中，并由处理器901执行，以完成本申请。一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述计算机程序在所述数据抽取、转换和加载ETL设备90中的执行过程。

本领域技术人员可以理解，图9仅仅是数据抽取、转换和加载ETL设备的示例，并不构成对数据抽取、转换和加载ETL设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如输入输出设备、网络接入设备、总线等。

所称处理器901可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器902可以是数据抽取、转换和加载ETL设备的内部存储单元，也可以是数据抽取、转换和加载ETL设备的外部存储设备，例如插接式硬盘，智能存储卡(Smart MediaCard，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。所述存储器902用于存储所述计算机程序以及数据抽取、转换和加载ETL设备所需的其他程序和数据。存储器902还可以用于暂时地存储已经输出或者将要输出的数据。

总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral Component，PCI)总线或扩展工业标准体系结构(ExtendedIndustry Standard Architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。

本申请实施例提供了一种计算机程序产品，当计算机程序产品在移动终端上运行时，使得移动终端执行时实现可实现上述各个方法实施例中的步骤。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，计算机程序包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读介质至少可以包括：能够将计算机程序代码携带到拍照装置/终端设备的任何实体或装置、记录介质、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质。例如U盘、移动硬盘、磁碟或者光盘等。在某些司法管辖区，根据立法和专利实践，计算机可读介质不可以是电载波信号和电信信号。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

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

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

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

Claims (10)

1.一种数据抽取、转换和加载ETL方法，其特征在于，包括：

获取待处理日志文件；其中，所述待处理日志文件包含至少一条日志记录；

获取业务处理规则，并对所述业务处理规则进行解析处理生成对应的流式处理链；其中，所述流式处理链包含所述业务处理规则中预设转换算子的逻辑表达式；

在消费所述待处理日志文件的日志记录时，执行所述流式处理链，生成所述日志记录的以上下文树存储的运算结果；其中，所述上下文树至少包含一个根节点，所述上下文树的节点用于保存描述所述运算结果的变量；

提取所述上下文树中各节点路径上的所有变量，生成所述日志记录的处理结果；

将所述处理结果加载至目标数据库。

2.如权利要求1所述的数据抽取、转换和加载ETL方法，其特征在于，所述获取待处理日志文件，包括：

将采集到的日志数据按照日志主题进行分类，得到多个日志文件；

从预设配置文件中查找各所述日志主题的数据连接规则；

针对每个日志文件，根据该日志文件对应的数据连接规则对所述日志文件中的日志数据进行解析处理，生成多条日志记录，并将所述多条日志记录组合生成待处理日志文件。

3.如权利要求2所述的数据抽取、转换和加载ETL方法，其特征在于，所述获取业务处理规则，并对所述业务处理规则进行解析处理生成对应的流式处理链，包括：

从所述预设配置文件中查找各所述日志主题的业务处理规则；

基于规则引擎对各所述业务处理规则进行解析处理，生成对应的流式处理链。

4.如权利要求2所述的数据抽取、转换和加载ETL方法，其特征在于，在消费所述待处理日志文件的日志记录时，执行所述流式处理链，生成所述日志记录的以上下文树存储的运算结果，包括：

接收消费者发送的日志订阅请求；其中，所述日志订阅请求包含目标日志主题；

从所述预设配置文件中查找所述目标日志主题对应的第一待处理日志文件和对应的第一流式处理链；

针对所述第一待处理日志文件中的每条日志记录，基于所述第一流式处理链对所述日志记录进行逻辑运算，将所述日志记录分裂为变量群组来产生上下文树，并将所述上下文树保存为所述日志记录的运算结果。

5.如权利要求4所述的数据抽取、转换和加载ETL方法，其特征在于，所述提取所述运算结果中各节点路径上包含的数据，生成对应的处理结果，包括：

在所述上下文树包含叶节点的情况下，遍历所述上下文树中所有的叶节点，提取每个叶节点至所述根节点路径上的变量，生成变量集；

识别所述变量集中的元数据，生成对应所述日志记录的处理结果。

6.如权利要求4所述的数据抽取、转换和加载ETL方法，所述将所述处理结果加载至目标数据库，包括：

根据所述目标日志主题确定目标数据库；

从预设配置文件中查找所述目标数据库的元数据类型；

根据元数据类型对处理结果进行格式转换，并将转换后的数据加载至目标数据库。

7.如权利要求1至6任一项所述的数据抽取、转换和加载ETL方法，其特征在于，所述预设转换算子包括下述至少一种：

过滤filter算子、map算子、flatmap算子以及选择select算子。

8.一种数据抽取、转换和加载ETL装置，其特征在于，包括：

数据获取模块，用于获取待处理日志文件；其中所述待处理日志文件包含至少一条日志记录；

规则获取模块，用于获取业务处理规则，并对所述业务处理规则进行解析处理生成对应的流式处理链；其中，所述流式处理链包含所述业务处理规则中预设转换算子的逻辑表达式；

数据运算模块，用于在消费所述待处理日志文件的日志记录时，执行所述流式处理链，生成所述日志记录的以上下文树存储的运算结果；其中，所述上下文树至少包含一个根节点，所述上下文树的节点用于保存描述所述运算结果的变量；

数据生成模块，用于提取所述上下文树中各节点路径上的所有变量，生成所述日志记录的处理结果；

数据加载模块，用于将所述处理结果加载至目标数据库。

9.一种数据抽取、转换和加载ETL设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至7任一项所述方法的步骤。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述方法的步骤。

Images