CN105447099B

CN105447099B - 日志结构化信息提取方法及装置

Info

Publication number: CN105447099B
Application number: CN201510766904.XA
Authority: CN
Inventors: 沈丽忠; 朱志; 魏和; 唐景峰; 吴勇; 洪毅清
Original assignee: China Construction Bank Corp
Current assignee: China Construction Bank Corp
Priority date: 2015-11-11
Filing date: 2015-11-11
Publication date: 2018-12-14
Anticipated expiration: 2035-11-11
Also published as: CN105447099A

Abstract

本发明公开日志结构化信息提取方法及装置，以实现自适应自动提取日志结构化数据的目的。在本发明实施例中，上游系统可向下游系统提供日志和日志DDL文件(日志DDL文件中包含日志中结构化信息的字段解析规则和字段定义)，这样下游系统可根据日志DDL文件自动提取日志的结构化数据，后续可加载到目标数据库供后续分析。在此过程中，下游系统无需理解晦涩难懂的日志。同时，在日志格式变化或业务逻辑变化后，上游系统只需要提供新的日志DDL文件，下游系统就可以依据新的日志DDL文件对日志进行解析。因此，本发明实施例所提供技术方案能够自适应由日志格式变化或业务逻辑变化引起的字段解析规则变化。

Description

日志结构化信息提取方法及装置

技术领域

本发明涉及计算机领域，特别是涉及日志结构化信息提取方法及装置。

背景技术

日志数据是大数据的重要组成部分。日志数据的分析在网站用户行为分析、系统运维统计等方面都是必不可少的。把日志的结构化信息提取出来，再基于提取后的结构化数据进行分析的方法被普遍接受。

目前日志结构化信息的提取方法不够灵活，基本都是针对某种具体的日志需要进行编码提取结构化信息。不同的日志格式需要进行不同的编码工作，对于同一日志，由日志格式或业务变化引起的变更也需要修改相应的代码，无法自适应其变化。

发明内容

本发明实施例的目的是提供日志结构化信息提取方法及装置，以实现自适应自动提取日志结构化数据的目的。

为实现上述目的，本发明提供了如下方案：

一种日志结构化信息提取方法，包括：

获取日志文件和与之相应的日志DDL文件，所述日志DDL文件中包含所述日志文件中结构化信息的字段解析规则和字段定义；

根据所述字段解析规则从所述日志文件中提取出字段并存储至输出文件；

生成与所述输出文件对应的字段类型说明文件。

一种日志结构化信息提取装置，包括：

获取单元，获取日志文件和与之相应的日志DDL文件，所述日志DDL文件中包含所述日志文件中结构化信息的字段解析规则和字段定义；

任务单元，用于根据所述字段解析规则从所述日志文件中提取出字段并存储至输出文件；

第一生成单元，用于生成与所述输出文件对应的字段类型说明文件。

在本发明实施例中，上游系统可向下游系统提供日志DDL文件，这样下游系统可根据日志DDL文件自动提取日志的结构化数据，后续可加载到目标数据库供后续分析。在此过程中，下游系统无需理解晦涩难懂的日志。同时，在日志格式变化或业务逻辑变化后，上游系统只需要提供新的日志DDL文件，下游系统就可以依据新的日志DDL文件对日志进行解析。因此，本发明实施例所提供技术方案能够自适应由日志格式变化或业务逻辑变化引起的字段解析规则变化，如分隔符变化、字段增减、字段位置变化等。只要结构化数据的数据接口不变，就不会对下游系统有影响，下游系统也就不需要做任何修改。此方案，对于分隔符变化和字段位置变化的情况，完全可以保持结构化数据的数据接口不变，也就是说这些变化对下游系统而言是透明的。对于字段增减的情况，其实数据接口已经发生改变，但是此方案仍然能够自适应地提取结构化数据，如果下游系统没有使用到受影响的字段，也不需要做任何修改。

附图说明

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

图1-4为本发明实施例提供的日志结构化信息提取方法示例性流程图；

图5、6为本发明实施例提供日志结构化信息提取装置结构示意图。

具体实施方式

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

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

关系数据库存储的数据是结构化的数据，导出成文本就是固定分割符分割的数据。与之对应的是半结构化数据，比如xml，json，html格式等；非结构化数据指的是图片，音频和视频文件等。

与传统的结构化数据(如数据库表)相比，日志由于其灵活多变的格式，不管对人的理解还是对计算机的处理都不是很友好。

目前日志结构化信息的提取方法不够灵活，基本都是针对某种具体的日志需要进行编码提取结构化信息。

例如，基于固定分隔符提取日志的提取方法，这种提取方式适合日志格式比较固定的日志，如以单分割符‘|’或多分隔符‘|@|’分割的日志。

但是，基于固定分隔符提取日志的提取方法只适用于格式固定的日志，无法处理其他格式的日志。

还有基于正则表达式的提取方式。正规表达式又称正规表示法、常规表示法(Regular Expression，在代码中常简写为regex、regexp或RE)。正则表达式使用单个字符串来描述、匹配一系列符合某个句法规则的字符串。在很多文本编辑器里，正则表达式通常被用来检索、替换那些符合某个模式的文本。许多程序设计语言都支持利用正则表达式进行字符串操作。例如，在Perl中就内建了一个功能强大的正则表达式引擎(引用自百度百科：http://baike.baidu.com/link？url＝BCPBnr3ePyeoGzyQBSqnDN8xCnfLfpCNSQEIIHTB3lYN7IMCxL-LLv1ZgR4vNVda0ijM5icMh46nNzMgqJBl9q)。基于正则表达式的日志提取方法能够处理各种格式的日志，也是目前业界普遍的一种做法。

但是在程序中硬编码正则表达式的方法不够灵活，只能处理单一格式的日志，而且无法自适应由业务需求或日志格式变化引起的变更。同时，提取的数据没有与其直接关联的元数据信息，无法自动导入目标数据库进行分析。另一方面，对于固定分隔符分割的日志，正则表达式提取方法效率较差。

传统的日志提取方法需要日志使用方开发人员先理解日志的内容，然后根据应用的需求提取需要的信息。这种方法存在若干弊端：

一方面，在很多机构中，特别是一些大型企业，日志的所有方和日志的使用方往往不在同一个团队，甚至不在同一部门。另一方面，日志格式灵活多变，有的日志极其复杂，对日志使用方而言如同天书，很难理解，而且目前没有一种规范来准确地描述日志的格式和业务含义。由于以上原因，为了提取日志的结构化信息，使用方往往要花费大量的时间和精力在沟通和理解所需的各种日志的格式。

为了支持业务的发展，IT系统往往要做相应的变更。由此导致的日志格式变更很容易导致下游依赖相应日志的应用不能正确地解析变更后的日志，从而影响相应的业务系统。即使从管理角度可以解决变更问题，但是成本却很高。可能一个很小的日志格式变更，就要修改下游的若干系统，每个系统都需要测试和上线。

为实现自适应自动提取日志结构化数据，本发明提出了日志结构化信息提取方法及日志结构化信息提取装置。

日志结构化信息提取装置可为日志处理引擎。

图1-图3示出了日志处理引擎所执行的日志结构化信息提取方法的示例性流程图，其至少可包括如下步骤：

S1：获取日志文件和与之相应的日志DDL文件。

更具体的是，是从日志所有方(上游系统)获取上述日志文件和日志DDL(DataDefinition Language)文件。

该日志DDL文件是用来描述日志格式的XML文件，内容包含了日志文件中结构化信息的字段解析规则和字段定义。

日志DDL文件需要和日志同时提供给日志处理引擎。

S2：根据日志DDL文件中的字段解析规则，从上述日志文件中提取出字段并存储至输出文件。

提取出的字段可称为解析结果字段或结构化数据。

S3、生成与上述输出文件对应的字段类型说明文件。

字段类型说明文件的内容主要包含字段字义。字段类型说明文件可称为结构化数据DDL。

在本发明其他实施例中，上述方法还可包括如下步骤：

S4、根据上述字段类型说明文件生成建表脚本并提交给目标数据库。

目标数据库的RDBMS(关系数据库管理系统，Relational Database ManagementSystem)，可将数据组织为相关的行和列。

上述建表脚本可用于目标数据库(RDBMS)创建空白数据库表，并加载(加载工具自动加载)输出文件中的字段至上述空白数据库表。

可见，在本发明实施例中，日志所有方(上游系统)可向日志使用方提供日志DDL文件，这样日志使用方(下游系统)可根据日志DDL文件自动提取日志的结构化数据，后续可加载到目标数据库供后续分析。在此过程中，日志使用方(下游系统)无需理解晦涩难懂的日志。同时，在日志格式变化或业务逻辑变化后，日志所有方只需要提供新的日志DDL文件，日志使用方就可以依据新的日志DDL文件对日志进行解析。因此，本发明实施例所提供技术方案能够自适应由日志格式变化或业务逻辑变化引起的字段解析规则变化，如分隔符变化、字段增减、字段位置变化等。只要结构化数据的数据接口不变，就不会对下游系统有影响，下游系统也就不需要做任何修改。

下面将进一步介绍日志DDL文件。

在本发明实施例中，上述所有实施例中的日志DDL文件可包括字段解析规则列表。

进一步的，字段解析规则列表中可包括N个字段解析规则(N不小于1)；而每一个字段解析规则又可包括前置处理规则、提取方式、提取方法参数和解析结果字段列表。

其中：

前置处理规则可为空也可不为空；

解析结果字段列表包括至少一个解析结果字段；

每一解析结果字段包含字段名称、字段类型和属性。字段名称、字段类型和属性用于表征字段定义。

并且，上述解析结果字段的排列顺序必须与字段解析规则提取的字段排列顺序一致。

在本发明其他实施例中，上述所有实施例中的N个字段解析规则与N个输出文件一一对应。

则步骤S2中的“根据上述字段解析规则从上述日志文件中提取出字段”可细化包括：

针对日志文件中需要处理的第i行日志，依次使用N个字段解析规则对其进行解析，直至解析成功；i不小于0，不大于M-1(或者i不小于1不大于M)；M为上述日志文件中所包含的日志总行数。

而上述步骤S2中的“存储至输出文件”可细化包括：

将成功解析出的字段输出到目标文件。

其中，目标文件具体为：与解析成功的字段解析规则相对应的输出文件。

举例来讲，假定输出文件f1～fN，分别对应字段解析规则1～N。对于第i行日志，先使用字段解析规则1进行解析，若解析失败，则使用字段解析规则2 进行解析，以此类推，直至解析成功。

假定使用字段解析规则2解析成功，则将成功解析出的字段输出到输出文件f2(输出文件f2与字段解析规则2对应)。

在本发明其他实施例中，上述所有实施例中的任一字段解析规则还可包括字段输出顺序，用于控制将成功解析出的字段输出到目标文件的顺序。在具体实现时，可使用index标签来表征字段输出顺序，本文后续将做具体介绍。

在本发明其他实施例中，上述所有实施例中的N个输出文件又与N个字段类型说明文件一一对应。则在本发明实施例中，将生成N个建表脚本并提交给目标数据库。

则后续目标数据库会根据这N个建表脚本创建N个空白数据库表，并加载各输出文件中的字段至相应的空白数据库表，从而最终生成N个结构化数据数据库表。

在本发明其他实施例中，在上述所有实施例中，若某字段解析规则的前置处理规则不为空，则在使用该字段解析规则对上述第i行日志进行解析前还包括：

使用上述前置处理规则对上述第i行日志进行前置处理。

上述前置处理可为加密、解码等。

举例来讲，在使用N个字段解析规则中的字段解析规则P(也即任一字段解析规则)对第i行日志进行解析时，如果字段解析规则P的前置处理规则不为空，则在尝试解析前，会使用前置处理规则对第i行日志进行前置处理。

在本发明其他实施例中，上述所有实施例中，若上述解析成功的字段解析规则中、解析结果字段的属性里包括针对指定字段的嵌套解析规则，上述所有实施例中的“根据字段解析规则从日志文件中提取出字段”还可包括：

对指定字段使用上述嵌套解析规则进行解析。

更具体的，根据字段解析规则从日志文件中提取出字段并存储至输出文件的操作，由HadoopMapReduce计算框架的Map函数执行。

下面将以较普遍的日志类型(NORMAL_LOG)为例，对日志DDL文件进行更具体的介绍。此DDL可用于后续日志结构化信息的自动提取、信息检核、日志格式变更管理等目的。

NORMAL_LOG类型的日志文件每一行的信息相对独立或完整，即不需要依赖上下行即可构成一条完整的记录。大部分日志属于这一类型，如apache日志。

为了示例说明方便，使用如下简化的日志文件进行说明：

第一行日志：10.10.201.115"GET/portal/images/zxc.gif？parm＝C001％7C％

40％7C％E5％BC％A0％E4％B8％89"

第二行日志：A008|@|456.00

在日志文件中，第一行日志与第二行日志格式不同，第一行日志为简化版本的apache日志，并且“parm＝”字符之后的参数进行了urlencode编码；第二行日志为固定分割符分隔的日志。

与此日志文件对应的DDL文件如下所示，包含提取规则和提取字段的定义(业务含义)。具体的，此DDL文件包含两条提取规则，第一条基于正则表达式，并且有一条嵌套解析规则parm_rule(已用下划线标出)用于进一步提取parm字段；第二条提取规则基于固定分隔符。

下面将对DDL中的各部分做出解释：

1)，<？xml version＝"1.0"encoding＝"UTF-8"？>：encoding指定编码格式，例如支持UTF-8编码；

2)，<file_name>：表示文件的名称；

3)，<file_version>：表示该DDL文件的版本序号；

4),<index>：表示该字段在输出文件中的排序，一般而言，在每一个顶层解析规则(非嵌套在其他解析规则里面的解析规则)中，这个值是从1开始递增的，如果后续由于日志格式变更引起的字段位置变化，则可以通过修改此值来调整字段的输出顺序，保持数据接口不变；

以第一条基于正则表达式的字段解析规则为例，其中的IP、parm、CUSTOMER_ID、Customer's name四个字段对应的index值分别是1、2、3、4，则这四个字段在输出文件中的排序即为1、2、3、4。

如果后续由于日志格式变更引起的字段的排序为CUSTOMER_ID、Customer'sname、IP、parm，则CUSTOMER_ID字段对应的index值更变为1， Customer's name字段对应的index值更变为2，IP字段对应的index值更变为3，Customer's name字段对应的index值更变为4。

4)，<type>：半结构化数据的类型；

5)，<rule_list>：字段解析规则列表，可以包含多个<rule>，也即字段解析规则；

6)，<rule>：一个具体的字段解析规则，每个字段解析规则中设置了提取规则名<name>，前置处理<pre_action>，提取方式<method>，提取方法参数<method_str>，以及解析结果字段列表<field_list>。

其中：

①前置处理<pre_action>：

前置处理表示执行字段解析规则前需要做的一些处理(如urldecode解码)；<pre_action>和</pre_action>是一对标签，有斜杠的表示结束标签，没有斜杠的表示开始标签。标签之间为空，表示没有前置处理动作(前置处理规则为空)。

由于业务或者技术需要，日志在存储的时候可能做了某种加密或编码，比如apache日志的url部分可能就会做urlencode，对于这种情况，需要在解析之前先对日志进行解码或解密，这只需要通过指定前置处理(pre_action)算子即可实现，用户也可以根据需要添加前置处理算子。

②提取方式<method>：

字段解析规则至少包含两种类型，后续可以扩展。第一种是固定分隔符分割解析(split)，第二种是正则表达式解析(regular_expression)。对于由固定分隔符(可以支持多个分隔符)分割的日志，可以直接使用第一种解析规则，性能较好。对于其他类型的日志，可使用第二种解析规则，虽然性能上会比第一种差一些，但是正则表达式极其灵活，能满足绝大多数的日志解析需求。

因此，提取方式可支持正则表达式(regular_expression)和分隔符切分(split)两种方式。

当提取方式为正则表达式，则通过指定提取方法参数<method_str>中的规则参数提取字段内容，如上述DDL文件中的^(\S+)"(POST|GET)(\S+)\？parm＝(\S+)"$。其中，“()”内的内容即为提取的内容。

当<method>为split方法时，则要根据<method_str>中的参数(分隔符)进行字段提取，如：<method_str>|@|</method_str>表示按照分隔符|@|切分数据。

7)，<field_list>：解析结果字段列表。解析结果字段列表中包含了多个<field>字段，每个<field>中包含了字段名称<name>、数据类型<type>、描述<desc>.属性。

通过提取规则提取的字段按照<field_list>中指定的字段顺序匹配。

字段名和字段类型组合构成对字段的描述，字段名顺序应与字段解析规则提取的字段顺序一致。

其中，字段类型用于标识字段的数据类型，此处的数据类型采用通用数据类型，以便目标数据库能够自动解析、识别输出文件中的数据，完成数据的自动加载，具体参见附录通用数据类型说明。

如果<field>字段还需要解析，需要指定<rule>嵌套解析规则。

字段解析规则支持嵌套，大大提高解析的灵活性。对于比较复杂的日志行，单条解析规则往往无法解析出所有有价值的字段。即使可以，解析规则往往也会变的异常复杂，影响解析性能。

嵌套解析规则就可以避免此问题，比如有些日志，大部分字段是用固定分隔符分割，小部分只能用正则表达式来解析，如果没有嵌套解析规则，就只能全部使用正则表达式来解析，不仅解析规则很复杂，而且性能也不理想。有了此嵌套解析的能力，DDL中可以先使用正则表达式解析，把固定分隔符分割的部分当作单一字段，然后针对此字段再设置固定分隔符分割解析，反之亦然。

图4示出了日志处理引擎的另一流程图，其中虚线方框内的逻辑运行在HadoopMapReduce计算框架的Map函数中。一个Map函数处理大概64M～512M大小的日志块(依赖于HDFS的block大小设置)。

现对其流程介绍如下：

在Map函数的初始阶段获取日志DDL文件，并解析此DDL文件，获取字段解析规则列表和对应的字段定义。日志解析规则可以只有一条，也可以有多条。如果整个日志文件所有有价值的日志都是同一格式，则只需要一条解析规则即可。对于很多日志，往往存在不同格式的日志行，如果这些日志行对后续分析都有价值，就需要多条不同的解析规则来解析，并存储到不同的输出文件。

以前述日志文件和对应的日志DDL文件为例，对日志解析过程进行说明如下：

对于第一行日志，先应用第一条提取规则RULE_01中<method_str></method_str>定义的正则表达式进行匹配，匹配成功，提取出两个字段：

IP(10.10.201.115)

parm(C001％7C％40％7C％E5％BC％A0％E4％B8％89)。

在属性定义，需要使用嵌套解析规则parm_rule进一步提取parm字段，首先需要对parm字段进行前置处理，即<pre_action>定义的urldecode解码(解码后的值为：C001|@|张三)，然后再运用嵌套解析规则parm_rule定义的固定分隔符“|@|”分割提取字段，得到两个字段：CUSTOMER_ID(C001)和CUSTOMER_NAME(张三)。第一行日志提取完成。

对于第二行日志，也是先应用第一条提取规则RULE_01中<method_str></method_str>定义的正则表达式进行匹配，匹配失败。再用第二条提取规则RULE_02定义的固定分隔符进行分割，提取成功，得到两个字段：ACCOUNT_NO(A008)和ACCOUNT_BALANCE(456.00)，第二行日志提取完成。

处理完日志后，日志处理引擎输出结构化数据(输出文件)和对应的字段类型说明文件。

仍以前面的日志文件和日志DDL文件为例，每个字段解析规则分别输出一份输出文件和一份对应的字段类型说明文件。

例如，RULE_01对应的输出文件的内容如下(以|％|分割，可指定)为：

10.10.201.115|％|C001|％|张三

对应的字段类型说明文件内容为：

<？xml version＝"1.0"encoding＝"UTF-8"？>

<transmit-content>

<file>

<file_name>EXAMPLE_LOG</file_name>

<rule_name>RULE_01</rule_name>

<file_version>1.0</file_version>

<field_list>

<field>

<type>VARCHAR(15)</type>

<desc>Visitor's IP address</desc>

</field>

<field>

<name>CUSTOMER_ID</name>

<type>VARCHAR(20)</type>

<desc>Customer's ID</desc>

</field>

<field>

<name>CUSTOMER_NAME</name>

<type>VARCHAR(50)</type>

<desc>Customer's name</desc>

</field>

</field_list>

</file>

</transmit-content>

RULE_02对应的输出文件内容(以|％|分割，可指定)为：

A008|％|456.00

对应的字段类型说明文件内容为：

<？xml version＝"1.0"encoding＝"UTF-8"？>

<transmit-content>

<file>

<file_name>EXAMPLE_LOG</file_name>

<rule_name>RULE_02</rule_name>

<file_version>1.0</file_version>

<field_list>

<field>

<name>ACCOUNT_NO</name>

<type>VARCHAR(15)</type>

<desc>Account number</desc>

</field>

<field>

<name>ACCOUNT_BALANCE</name>

<type>FLOAT(2)</type>

<desc>Account balance</desc>

</field>

</field_list>

</file>

</transmit-content>

可见，字段类型说明文件根据日志DDL文件中的解析结果字段生成。

需要说明的是，字段类型说明文件中的字段定义的顺序，与日志DDL文件中index标签的取值是对应一致的。

这样，根据DDL中的字段定义，可以方便地自动生成目标数据库的建表脚本并提交给目标数据库创建目标数据库表，然后利用相应的数据库加载工具进行加载。

上面介绍了提取方法，本文后续将介绍日志结构化信息提取装置，也即日志处理引擎。

请参见图5，上述日志处理引擎500可包括：

获取单元1，用于获取日志文件和与之相应的日志DDL文件。

其中，日志DDL文件中包含上述日志文件中结构化信息的字段解析规则和字段定义。

任务单元2，用于根据字段解析规则从日志文件中提取出字段并存储至输出文件；

第一生成单元3，用于生成与上述输出文件对应的字段类型说明文件。

在本发明其他实施例中，上述日志处理引擎500还可包括：

第二生成单元4，用于根据上述字段类型说明文件生成建表脚本并提交给目标数据库。其中，上述建表脚本用于上述目标数据库创建空白数据库表，并加载上述输出文件中的字段至上述空白数据库表。

在本发明其他实施例中，上述日志DDL文件包括：字段解析规则列表；上述字段解析规则列表中包括N个字段解析规则；上述N不小于1。

每一字段解析规则包括前置处理规则、提取方式、提取方法参数和解析结果字段列表；其中：

上述前置处理规则可为空；

上述解析结果字段列表包括至少一个解析结果字段；

上述至少一个解析结果字段的排列顺序与上述字段解析规则提取的字段排列顺序一致；

每一上述解析结果字段包含字段名称、字段类型和属性；上述字段名称、字段类型和属性用于表征上述字段定义。

具体内容请参见本文前述记载，在此不作赘述。

进一步的，上述N个字段解析规则与N个输出文件一一对应。

而在根据上述字段解析规则从上述日志文件中提取出字段的方面，任务单元2具体用于：

针对上述日志文件中需要处理的第i行日志，依次使用上述N个字段解析规则对其进行解析，直至解析成功；i不小于0，不大于M-1；M为上述日志文件中所包含的日志总行数。

在存储至输出文件的方面，任务单元2则具体用于：

将成功解析出的字段输出到目标文件；

上述目标文件为，与解析成功的字段解析规则相对应的输出文件。

具体内容请参见本文前述记载，在此不作赘述。

在本发明其他实施例中，若字段解析规则的前置处理规则不为空，则在使用该字段解析规则对上述第i行日志进行解析前，上述所有实施例中的任务单元2还具体用于：使用上述前置处理规则对上述第i行日志进行前置处理。

在本发明其他实施例中，若上述解析成功的字段解析规则中、解析结果字段的属性里包括针对指定字段的嵌套解析规则，在根据上述字段解析规则从上述日志文件中提取出字段的方面，上述所有实施例中的任务单元2还具体用于：

对上述指定字段使用上述嵌套解析规则进行解析。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的系统而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本发明的限制。

Claims

1.一种日志结构化信息提取方法，其特征在于，包括：

生成与所述输出文件对应的字段类型说明文件；

其中，所述日志DDL文件包括：字段解析规则列表；所述字段解析规则列表中包括N个字段解析规则；所述N不小于1；每一字段解析规则包括前置处理规则、提取方式、提取方法参数和解析结果字段列表；其中：所述前置处理规则可为空；所述解析结果字段列表包括至少一个解析结果字段；所述至少一个解析结果字段的排列顺序与所述字段解析规则提取的字段排列顺序一致；每一所述解析结果字段包含字段名称、字段类型和属性；所述字段名称、字段类型和属性用于表征所述字段定义；

所述N个字段解析规则与N个输出文件一一对应；

则所述根据所述字段解析规则从所述日志文件中提取出字段包括：针对所述日志文件中需要处理的第i行日志，依次使用所述N个字段解析规则对其进行解析，直至解析成功；i不小于0，不大于M-1；M为所述日志文件中所包含的日志总行数；

则所述存储至输出文件包括：将成功解析出的字段输出到目标文件；所述目标文件为，与解析成功的字段解析规则相对应的输出文件。

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

根据所述字段类型说明文件生成建表脚本并提交给目标数据库；所述建表脚本用于所述目标数据库创建空白数据库表，并加载所述输出文件中的字段至所述空白数据库表。

3.如权利要求1所述的方法，其特征在于，所述根据所述字段解析规则从所述日志文件中提取出字段并存储至输出文件的操作，由HadoopMapReduce计算框架的Map函数执行。

4.如权利要求1所述的方法，其特征在于，若字段解析规则的前置处理规则不为空，则在使用该字段解析规则对所述第i行日志进行解析前还包括：

使用所述前置处理规则对所述第i行日志进行前置处理。

5.如权利要求1所述的方法，其特征在于，若所述解析成功的字段解析规则中、解析结果字段的属性里包括针对指定字段的嵌套解析规则，所述根据所述字段解析规则从所述日志文件中提取出字段还包括：

对所述指定字段使用所述嵌套解析规则进行解析。

6.一种日志结构化信息提取装置，其特征在于，包括：

第一生成单元，用于生成与所述输出文件对应的字段类型说明文件；

所述N个字段解析规则与N个输出文件一一对应；

7.如权利要求6所述的装置，其特征在于，还包括：

第二生成单元，用于根据所述字段类型说明文件生成建表脚本并提交给目标数据库；所述建表脚本用于所述目标数据库创建空白数据库表，并加载所述输出文件中的字段至所述空白数据库表。