DL文件自动提取日志的结构化数据，后续可加 载到目标数据库供后续分析。在此过程中，日志使用方(下游系统)无需理解晦涩难懂的日 志。同时，在日志格式变化或业务逻辑变化后，日志所有方只需要提供新的日志孤L文件，日 志使用方就可W依据新的日志孤L文件对日志进行解析。因此，本发明实施例所提供技术方 案能够自适应由日志格式变化或业务逻辑变化引起的字段解析规则变化，如分隔符变化、 字段增减、字段位置变化等。只要结构化数据的数据接口不变，就不会对下游系统有影响， 下游系统也就不需要做任何修改。
[0046] 下面将进一步介绍日志孤L文件。
[0047] 在本发明实施例中，上述所有实施例中的日志DDL文件可包括字段解析规则列表。
[0048] 进一步的，字段解析规则列表中可包括N个字段解析规则(N不小于1);而每一个字 段解析规则又可包括前置处理规则、提取方式、提取方法参数和解析结果字段列表。
[0049] 其中；
[0050] 前置处理规则可为空也可不为空；
[0051 ]解析结果字段列表包括至少一个解析结果字段；
[0052] 每一解析结果字段包含字段名称、字段类型和属性。字段名称、字段类型和属性用 于表征字段定义。
[0053] 并且，上述解析结果字段的排列顺序必须与字段解析规则提取的字段排列顺序一 致。
[0054] 在本发明其他实施例中，上述所有实施例中的N个字段解析规则与N个输出文件一 一对应。
[0055] 则步骤S2中的"根据上述字段解析规则从上述日志文件中提取出字段"可细化包 括：
[0056] 针对日志文件中需要处理的第i行日志，依次使用N个字段解析规则对其进行解 析，直至解析成功；i不小于0,不大于M-1(或者i不小于1不大于M);M为上述日志文件中所包 含的日志总行数。
[0057] 而上述步骤S2中的"存储至输出文件"可细化包括：
[0058] 将成功解析出的字段输出到目标文件。
[0059] 其中，目标文件具体为:与解析成功的字段解析规则相对应的输出文件。
[0060] 举例来讲，假定输出文件η~fN，分别对应字段解析规则1~N。对于第i行日志，先 使用字段解析规则1进行解析，若解析失败，则使用字段解析规则2进行解析，W此类推，直 至解析成功。
[0061] 假定使用字段解析规则2解析成功，则将成功解析出的字段输出到输出文件f2(输 出文件f 2与字段解析规则2对应）。
[0062] 在本发明其他实施例中，上述所有实施例中的任一字段解析规则还可包括字段输 出顺序，用于控制将成功解析出的字段输出到目标文件的顺序。在具体实现时，可使用 index标签来表征字段输出顺序，本文后续将做具体介绍。
[0063] 在本发明其他实施例中，上述所有实施例中的N个输出文件又与N个字段类型说明 文件一一对应。则在本发明实施例中，将生成N个建表脚本并提交给目标数据库。
[0064] 则后续目标数据库会根据运N个建表脚本创建N个空白数据库表，并加载各输出文 件中的字段至相应的空白数据库表，从而最终生成N个结构化数据数据库表。
[0065] 在本发明其他实施例中，在上述所有实施例中，若某字段解析规则的前置处理规 则不为空，则在使用该字段解析规则对上述第i行日志进行解析前还包括：
[0066] 使用上述前置处理规则对上述第i行日志进行前置处理。
[0067] 上述前置处理可为加密、解码等。
[0068] 举例来讲，在使用N个字段解析规则中的字段解析规则P(也即任一字段解析规则） 对第i行日志进行解析时，如果字段解析规则P的前置处理规则不为空，则在尝试解析前，会 使用前置处理规则对第i行日志进行前置处理。
[0069] 在本发明其他实施例中，上述所有实施例中，若上述解析成功的字段解析规则中、 解析结果字段的属性里包括针对指定字段的嵌套解析规则，上述所有实施例中的"根据字 段解析规则从日志文件中提取出字段"还可包括：
[0070] 对指定字段使用上述嵌套解析规则进行解析。
[0071] 更具体的，根据字段解析规则从日志文件中提取出字段并存储至输出文件的操 作，由化doopMapReduce计算框架的Map函数执行。
[0072] 下面将W较普遍的日志类型(N0RMAL_L0G)为例，对日志DDL文件进行更具体的介 绍。此DDL可用于后续日志结构化信息的自动提取、信息检核、日志格式变更管理等目的。
[0073] N0RMAL_L0G类型的日志文件每一行的信息相对独立或完整，即不需要依赖上下行 即可构成一条完整的记录。大部分日志属于运一类型，如apache日志。
[0074] 为了示例说明方便，使用如下简化的日志文件进行说明：
[0075] 第一行日志：10.10.201.115"GET/po;rta Vimages/zxc. gif ?pa;rm = C001 %7C%
[0076] 40%7C%E5%BC%A0%E4%B8%89"
[0077] 第二行日志:A008|@ I 456.00
[0078] 在日志文件中，第一行日志与第二行日志格式不同，第一行日志为简化版本的 apache日志，并且"pa;rm="字符之后的参数进行了urlencode编码；第二行日志为固定分割 符分隔的日志。
[0079] 与此日志文件对应的DDL文件如下所示，包含提取规则和提取字段的定义(业务含 义）。具体的，此DDL文件包含两条提取规则，第一条基于正则表达式，并且有一条嵌套解析 规则parm_rule(已用下划线标出）用于进一步提取parm字段;第二条提取规则基于固定分 隔符。
[0080]
[0081]
[0082]
[0083]
[0084] 下面将对DDL中的各部分做出解释：
[00化]1)，<?xml version = "l .0"encoding = "UTF-8"?〉：encoding指定编码格式，例如 支持UTF-8编码；
[0086] 2)，<file_name>:表示文件的名称；
[0087] 3)，<f ile_version>:表示该孤L文件的版本序号；
[0088] 4)，<index>:表示该字段在输出文件中的排序，一般而言，在每一个顶层解析规则 (非嵌套在其他解析规则里面的解析规则）中，运个值是从1开始递增的，如果后续由于日志 格式变更引起的字段位置变化，则可W通过修改此值来调整字段的输出顺序，保持数据接 口不变；
[0089] W第一条基于正则表达式的字段解析规则为例，其中的IP、parm、CUSTOMER_ID、 Customer ' S name四个字段对应的index值分别是1、2、3、4，则运四个字段在输出文件中的 排序即为1、2、3、4。
[0090] 如果后续由于日志格式变更引起的字段的排序为CUSTOMER_ID、Customer's name、IP、parm，则CUST0MER_ID字段对应的index值更变为1，Customer's name字段对应的 index值更变为2，IP字段对应的index值更变为3，Customer ' S name字段对应的index值更 变为4。
[0091] 4)，〈type〉:半结构化数据的类型；
[0092] 5)，<rule_list>:字段解析规则列表，可W包含多个分1116〉，也即字段解析规则；
[0093] 6)，<rule>:-个具体的字段解析规则，每个字段解析规则中设置了提取规则名< name〉，前置处理<pre_action〉，提取方式〈method〉，提取方法参数<method_st;r〉，W及解析 结果字段列表<field_list〉。
[0094] 其中；
[0095] ①前置处理 <pre_action>:
[0096] 前置处理表示执行字段解析规则前需要做的一些处理(如urldecode解码）；<pre_ action〉和</pre_action>是一对标签，有斜杠的表示结束标签，没有斜杠的表示开始标签。 标签之间为空，表示没有前置处理动作(前置处理规则为空）。
[0097] 由于业务或者技术需要，日志在存储的时候可能做了某种加密或编码，比如 apache日志的url部分可能就会做urlencode，对于运种情况，需要在解析之前先对日志进 行解码或解密，运只需要通过指定前置处理(pre_action)算子即可实现，用户也可W根据 需要添加前置处理算子。
[0098] ②提取方式〈method〉：
[0099] 字段解析规则至少包含两种类型，后续可W扩展。第一种是固定分隔符分割解析 (