基于专家系统的Web日志数据处理方法研究

李春生，豆立宪，张可佳，刘 涛，邹林浩

(东北石油大学 计算机与信息技术学院，黑龙江 大庆 163318)

0 引 言

通过对企业员工的web日志的数据挖掘，能够更加科学有效地监督管理员工，数据挖掘的核心工作之一就是对原始数据的预处理，它影响到数据分析结果的准确度。但当前面向web日志的数据预处理方法没有考虑到复杂web日志数据格式的问题，浪费了过多的人力与时间，缺乏智能性且不够高效。通过专家系统自动对复杂web日志数据格式的判别，将对应的web日志格式进行数据清洗，完成数据预处理。能够很大程度地节约时间与人力，相对于当下web日志数据的预处理方法更加智能高效。

由于专家系统其技术特点能应对复杂的日志格式，因此应用专家系统能很大程度地实现自动对复杂web日志数据格式的判别，弥补传统方法的不足。

1 专家系统概述

专家系统定义：经由推论引擎、知识库及接口为基础而组成的系统即是所熟知的专家系统。专家系统的职责就是对社会生活中的问题进行一定的判断解释及认知。只是在这个特别的领域中有着不同的对于认知定义的解释。虽然当下还没有明确的定义，但是只要当设计的系统在执行的信度及效度、对专业知识的需求、复杂性等能够与专家不相上下的时候，就可以把该系统称为专家系统[1]。

1.1 基于框架的专家系统

由于基于规则的专家系统衍生出的一种推广，即基于框架的专家系统，本身具有一种区别于其余专家系统的编程风格。当初提出用框架来表示数据结构的人是Minsky。很多概念的槽、知识、名称包含于框架之中，当符合这个概念的某些实例出现时，就可以把和这个实例相关的特定值输入到当前框架中。编程语言中引入框架的概念后，就形成了面向对象的编程技术。所以目前可以得出一个结论：在某种程度上面向对象的编程技术等于基于框架的专家系统。但由于当下日志的总字段长短不一，属性不同，所以基于框架的专家系统不适用于日志类型的判别。

1.2 基于案例的专家系统

采用以前存在的案例来推理解答目前问题的系统，即基于案例推理的专家系统。求解的顺序：第一步，得到问题，并开始对以往的案例进行匹配，直到找到跟目前问题最匹配的案例；第二步，基于第一步找到的当前问题最合理的匹配案例，就将之前案例所用的解决方案运用到现在，如果并没有找到合适的匹配案例，将当前的作为新的案例并加入到案例库。综上所述，基于案例推理的专家系统能够不断地学习新的经验，并不断进步。

当然，如何从过往的案例中找出最合理的案例并与当前的问题进行匹配是当前基于案例推理的专家系统比较大的一个难点。在案例寻找过程中，需要将一些过分相似的案例进行删除，因为如图案例库太大，将会影响案例匹配的效率。目前来说一些主流的匹配算法有：径向基函数网络、k-近邻法、最近邻法。但基于案例的分析相对于基于规则的推理有一定的不准确性[2]。

1.3 基于规则的专家系统

由于该类系统是在专家系统中最早被研发出来的，同样也是基本的结构被用来组成专家系统。由于使用的规则来源于产生式定义，所以，在一般的状况下，在基于规则的专家系统中就会用“if……then……”的类型来解决问题。环境与行为的关系一般会被用一种心理学术语来进行描述，即产生式。而专家系统在最开始是从其中演变而来的。斯坦福大学设计的第一个专家系统，它的主要功能是判定物质的结构。而且在产生式的系统当中，知识被分割成了两个方面，静态的系统是一方面，用事实来表示，例如事件与事物及其相互之间的联系；推理的行为及其推理过程是另一方面，用产生式的规则来实现。因为该类系统的知识库主要用来存储规则，所以该类系统又被称为基于规则专家系统[3]。

当前最常使用的方法是基于规则的专家系统，其主要原因是拥有许多成功的案例和便捷轻快的开发工具。基于规则的专家系统不仅可以用各种各样的规则来实现专家系统，而且可以用来直接对人的心理过程进行模仿。基于规则的专家系统有两种基本的推理:第一种是将已经存在的知识作为专家系统推理开始点的正向推理；第二种是将假定的结果作为专家系统推理开始点的反向推理。且对于反向推理，如果找不到匹配的规则，改变假设，重新进行推理[4]。

知识与处理的相分离。基于规则的专家系统的结构为知识库和推理引擎提供了有效的分离机制。因此，能够使用同一个专家系统框架开发不同的应用，系统本身也容易扩展。在不干扰控制结构的同时通过添加一些规则，还能使系统更聪明。

大多数基于规则的专家系统都能表达和推理不完整、不确定的知识。因此可以采用基于规则的专家系统思路来构建专家系统。

2 web日志数据预处理流程

在数据分析的过程中，如果数据没有进行过数据处理，原来的数据依然存在各种各样的异常，且存在不一致、不完整等问题，即会导致数据分析的结果不够准确。所以在数据分析之前，对原始数据进行数据预处理的步骤至关重要。

一条真实的NCSA(ECLF)日志记录为“27.19.74.143 - - [30/May/2013:17:38:20 +0800] "GET /static/image/common/swfupload.swf?preventswfcach-ing=1369906718144 HTTP/1.1" 200 13333”，这类日志主要由以下几个部分组成：

标识符(ident)：目前几乎多数的浏览器已经取消了该功能，因为涉及到了用户邮箱等隐私信息。

授权用户(authuser)：虽然目前多数的网站的该类日志项并不存在，但是该类字段对于那些需要身份验证或者访问时候个人密码保护的信息项网站来说，不能为空。

日期时间(date)：即[日期/月份/年份:小时:分钟:秒钟时区]，占用的字符位数也基本固定，一般的格式形如[22/Feb/2010:09:51:46 +0800]。

请求(request)：在网站上通过使用哪些方式获取了哪些信息在日志数据格式中也扮演着重要的角色。

请求类型(method)：目前来说，主流的请求类型主要有以下三种：POST/HEAD/GET。

请求资源(resource)：可以是css、动画、图片等资源，也可以是某网页的地址，即是请求资源的相应的UPL。

协议版本号(protocol)：通常是HTTP/1.0或者HTTP/1.1，用于版本信息及显示的协议。

状态码(status)：用于响应浏览器的请求。

传输字节数(bytes)：在一次请求过程中的资源数量。

访问主机(remotehost)：已经解析的域名或者用于显示主机的ip。

各类web日志数据的处理流程基本一致。处理流程主要分为：数据抽取、数据格式转换、数据重复值处理[5]。

2.1 web日志数据抽取

web日志分析过程中，并不是每个字段都是日志分析中所需要的。比如，DNS的IP在每行数据中都是相同的，所以没有必要分析；日志记录中也记录了两次用户请求的主机地址，实际分析中只需要一个即可；还有一些无关的符号(client、query、IN、+客户端端口号等)[6]也都需要过滤。最终，在数据表中保存了所需要的有用字段。

2.2 web日志数据格式转换

web日志数据格式的转换主要针对的是日期字段。在这里，将字符型的日期格式04．Jan．2017转换成了日期类型的数据格式2017—01—04[7]。

2.3 web日志数据重复值的处理

在海量的web日志数据行中，有大部分数据行是重复的，数据量很大，会对数据分析的准确性带来一定的影响，因此有必要对重复的数据进行去重处理[8]。

3 基于专家系统的web日志数据预处理

3.1 数据来源

本次实验的数据来源于某企业Apache服务器2013年的员工web日志数据。

3.2 专家系统设计

专家系统主要逻辑：

(1)获取web日志数据，将获取web日志数据某一行的前三列转换为已知事实。

(2)输入目前已经存在的事实—>进行推理。

(3)综合数据库db添加输入的已知事实。

(4) 规则库获取，并在之后将存在对应关系的前提与结论分别各自存储于两个列表里[9]。

(5)前提与已知知识库进行匹配：

如果有一个前提，所有这些在已知的事实中出现，那么最少也能够得出一个结论[10]。将结论添加到综合数据库中，并对推理过程进行标记。在推理列表之中存在的数字是前提和推理出来结论的下标[11]。用于展示。

如果这样的前提并不存在，就无法推理出想要的中间结论，跳转(7)。

(6)等循环完了，因为至少存在一个中间结论，所以直接输出推理过程和(中间或者最终)结论[12]。

(7)提示什么也不能推出来，询问是否进行补充，如果选择“是”就回到主页面，如果选择“否”就关闭程序。

界面设置：

框:读取并显示web日志数据的框，输入事实的框，显示推理过程的框，显示结论的框，自动显示当前规则库的框，用来添加规则库的框。

按钮：打开web日志数据的按钮，点击进行推理的按钮，点击添加规则库并更新当前窗口的按钮。

对话提示框：询问是否进行补充的框。

主界面如图1所示。

图1 主界面

点击文件，打开需要处理的web日志数据，如图2所示。

图2 打开web数据

显示读取的web日志数据，将获取的web日志数据的第一行前三列，转换为已知事实，并显示于“获取web日志”，推理输出对应的日志格式，如图3所示。

图3 推理过程及结果显示

3.3 web日志数据预处理

通过“2”得到输入的web数据格式是NCSA(ECLF)[13],针对其特定的数据格式自动进行数据预处理，NCSA(ECLF)日志格式如下所示：

3.3.1 数据抽取

企业员工的web日志中时区、方法、协议、状态码等字段对于分析没有作用。企业员工都在同一时区，所以时区这一字段对于企业分析员工行为没有意义，可以舍去；在企业分析员工web日志过程中，请求方法、协议、状态码等字段没有实际应用价值，亦可以舍去。因此将这些无意义字段都删除，只保留主机IP、请求时间、资源、发送字节量等字段[14]。

3.3.2 数据格式转换

由于数据格式的转换主要针对的是日期字段，因此需要将字符型的日期格式转换成日期类型的数据格式。

3.3.3 重复字段删除

由于数据量庞大，因此以10秒钟为间隔定义员工日志。在这里，删除的对象针对的是同一ip，访问时间相差大于10秒的数据行。将员工日志数据重新定义完成后，删除其中的重复数据行。在一定程度上能提高之后数据分析的准确性[15]。

经过处理完的ECLF web日志数据如下所示：

4 结束语

传统的日志数据清洗方式难以应对目前如此复杂的日志格式。由于专家系统其技术特点能应对复杂的日志格式，所以通过结合专家系统，推理出对应的web日志格式，从而自动进行日志数据清洗。该文通过对若干种日志数据格式建立规则库，并对其进行知识推理，基于推理得到对应日志类型，自动进行数据预处理。证明了基于专家系统的web日志数据预处理的可行性，使得当前的日志数据处理更加高效且智能，有效提高了企业的工作效率，节约了时间成本，推动了企业快速发展。