CN111435344B

CN111435344B - 一种基于大数据的钻井提速影响因素分析模型

Info

Publication number: CN111435344B
Application number: CN201910037016.2A
Authority: CN
Inventors: 苏兴华; 刘胜娃; 詹胜; 王建胜; 康芳玲; 王亚琼
Original assignee: Changqing Drilling Co of CNPC Chuanqing Drilling Engineering Co Ltd
Current assignee: Changqing Drilling Co of CNPC Chuanqing Drilling Engineering Co Ltd
Priority date: 2019-01-15
Filing date: 2019-01-15
Publication date: 2023-03-21
Anticipated expiration: 2039-01-15
Also published as: CN111435344A

Abstract

本发明公开了一种基于大数据的钻井提速影响因素分析模型，包括：基于主题的数据仓库系统，基于Kettle实现了分布式多源异构数据源的数据集成；基于规则引擎的数据清洗架构，从大量原始数据中使用一系列的逻辑检测出脏数据并修复或丢弃，从而实现大数据的数据质量保证；基于SOA的业务智能云服务平台，在不改变各部门原业务逻辑前提下，对各分布式异构数据中心构建检索服务，以实现企业内单个职能部门一站式获取所有部门所提供的共享信息；智能推送服务，基于用户的注册信息和主动地收集用户日常行为模式，智能推断出用户需求，将最新数据与信息分门别类地传送给相应用户。本发明有利于实现数据共享，进而实现推广先进经验，改进现有技术。

Description

一种基于大数据的钻井提速影响因素分析模型

技术领域

本发明涉及大数据技术领域，尤其涉及一种基于大数据的钻井提速影响因素分析模型。

背景技术

近年来，钻井行业对钻井数据的采集、存储、处理和传播的数量与日俱增，目前已经积累了数万口井的钻井数据，这其中蕴藏着大量的知识有待我们去挖掘，进而实现推广先进经验，改进现有技术。实现数据共享，可以使更多的人更充分地使用已有数据资源，减少资料收集、数据采集等重复劳动和相应费用。但是，在实施数据共享的过程当中，由于不同用户提供的数据可能来自不同的途径，其数据内容、数据格式和数据质量千差万别，有时甚至会遇到数据格式不能转换或数据转换格式后丢失信息等棘手问题，严重阻碍了数据在各部门和各软件系统中的流动与共享。因此，如何对数据进行有效的集成管理已成为增强企业竞争力的必然选择。

经调查发现，当前企业的数据分属于不同数据源，具有分散性，异构性，不确定性和频繁变动的特点。如何集成分布式异构数据源，使其适合不断发展的复杂需求；如何有效扩展应用领域、分离实现技术和应用需求；如何充分描述各种数据源格式以及如何发布和进行数据交换等都是亟待解决的问题。

发明内容

针对上述现有技术中存在的问题，本发明提供一种基于大数据的钻井提速影响因素分析模型，其包括：

基于主题的数据仓库系统，基于Kettle实现了分布式多源异构数据源的数据集成，将历史数据业务系统所生成的历史数据库数据转换为可供决策的分析性数据；对历史数据库数据进行抽取，采用事实表-维度表的多维模型构建了星型数据仓库，实现对各主题域维度数据和事实数据的装换与加载，最终形成面向石油钻井企业的数据仓库；

基于规则引擎的数据清洗架构，利用规则来描述数据清洗逻辑，使用规则引擎来执行清洗逻辑，从大量原始数据中使用一系列的逻辑检测出脏数据并修复或丢弃，从而实现大数据的数据质量保证；其中的规则引擎将提交给它的数据对象与加载在引擎中的业务规则进行测试和比对，激活符合当前数据状态的业务规则并根据其声明的执行逻辑，触发相应操作；

基于SOA的业务智能云服务平台，通过构建基于SOA的联邦式信息检索平台，在不改变各部门原业务逻辑前提下，对各分布式异构数据中心构建检索服务，以实现企业内单个职能部门一站式获取所有部门所提供的共享信息；

智能推送服务，基于用户的注册信息和主动地收集用户日常行为模式，智能地归纳出用户的专业和兴趣点，建立起用户行为轮廓，推断出用户需求，并根据推断出的用户需求将最新数据与信息分门别类地传送给相应的用户。

进一步地，所述基于主题的数据仓库系统包括系统数据资源层、数据访问层、ETL数据集成层以及决策支持层；其中，

系统数据资源层是数据仓库系统基础，其通常包含企业内外部信息；完成的石油钻井项目，各业务系统分散在无线传输库和RTX数据库源系统中；数据访问层，数据抽取成功的关键是能够访问各异构数据源，Kettle对数据库的连接基于JDBC数据连接规范；ETL数据集成层，在主题的指导下完成数据源到数据仓库和数据集市的ETL处理；所述ETL数据集成层是整个数据仓库系统的核心层，是将企业基础数据转换成分析型数据的关键。

进一步地，所述基于规则引擎的数据清洗架构包括规则定义界面、规则库、规则模板库、规则引擎以及数据清洗插件类；其中，

所述规则定义界面以可视化方式为数据源表定义各种数据清洗规则；其可从规则模板库中提取规则模板，用户进行修改后形成规则；用户也可手工定义新的规则模板或将规则定义界面中定义的规则保存为规则模板；所述规则库集中保存规则定义界面所定义的规则，以便规则管理和重用；所述规则引擎是规则的运行环境，负责编译和执行规则；所述数据清洗插件类定义了一套机制，使得外部软件能够集成数据清洗功能；即，它负责接收原始数据并为之调用规则引擎来执行规则，并将处理结果返回给调用者。

进一步地，所述基于规则引擎的数据清洗架构采用Java开发规则定义界面，使用XML文件构建规则库和规则模板库，使用Drools规则引擎作为规则的运行环境，使用Java类来实现数据清洗插件类。

进一步地，所述基于SOA的业务智能云服务平台包括数据收集模块、索引构建模块以及检索服务发布模块；其中，

所述数据收集模块，将录入的数据暂时保存在临时的共享数据管理中心，只有管理员审核通过的记录才能成为共享数据；所述索引构建模块，对于常规检索，使用数据库的结构化查询语言SQL完成，对于其他检索，使用倒排索引完成；所述检索服务发布模块，把单个数据系统的信息检索功能进行服务的封装，并发布在服务管理中心。

进一步地，所述检索服务发布模块发布服务采用的是Apache组织关于实现SOA的开源框架Tuscany，Tuscany采用的是服务组件框架，其核心组件提供了一整套基于Java语言的API，通过其提供的API便可以把本地的功能函数发布成能异地调用的服务。

进一步地，所述基于SOA的业务智能云服务平台分为七个层次，从下往上依次为网络基础设施层、云平台虚拟层、数据访问层、对外服务层、安全链路层、业务功能层、系统表示层；其中，

所述系统表示层设计统一标准的信息检索前端界面和统一格式的检索结果显示页面，从而为用户提供统一检索入口，所述对外服务层的访问，使用的是安全链路层的简单对象访问协议，分布式的检索Web服务通过数据访问层完成对本地索引文档的检索，云平台虚拟层提供了整个平台开发所需要的虚拟机，网络基础设施位于最底层，为平台的构建提供基础硬件设施的支撑。

进一步地，所述基于SOA的业务智能云服务平台为用户提供的业务功能包括信息上传、联邦式信息检索、资源获取以及资源下载。

进一步地，所述基于SOA的业务智能云服务平台的数据中心由单个的实体服务器实现，为了保证数据安全、服务的质量、企业软硬件资源的利用率，其利用了VMware企业级私有云平台；并且，平台在VMware云环境中加入了负载均衡机制，以提高系统在高负载环境下的稳定性；基于此种构思，所述基于SOA的业务智能云服务平台实现了主服务器计算与数据存储的分离，使用了两个虚拟计算节点和一个虚拟存储节点，其中两个虚拟计算节点类似于Master与Slave的关系，用户对平台的访问默认分流到Master计算节点，Master计算节点会依据特定的分流策略判断是否将用户的访问分流到Slave计算节点或直接在本机响应处理。

进一步地，所述负载均衡机制采用的分流策略是负载监听，其采用内存的使用率作为判断Master计算节点负载大小的指标，当内存使用率超过设定的阈值时就将用户请求分流到Slave计算节点；其中，内存使用率同时考虑了计算节点内存使用率和其所在服务器的内存使用率，只要其中的任意一项超过了设定的阀值，便可以将新的用户访问请求分流到Slave计算节点。

本发明通过建立基于主题的数据仓库系统，实现了分布式多源异构数据源的数据集成；并利用基于规则引擎的数据清洗架构对数据进行清洗，保证了数据质量；进而构建了基于SOA的业务智能云服务平台，从而在不改变各部门原业务逻辑前提下，对各分布式异构数据中心构建检索服务，以实现企业内单个职能部门一站式获取所有部门所提供的共享信息，并加入了智能推送服务。有利于实现数据共享，进而实现推广先进经验，改进现有技术。

附图说明

图1为kettle的ETL工作流程图；

图2为石油钻井项目星型模式图；

图3为数据仓库模型层；

图4为ETL总作业流程图；

图5为单井起钻趟数信息数据集成作业流程；

图6为单井统计信息数据集成作业流程；

图7为钻井趟数转换流程；

图8为单井统计ETL转换流程；

图9为日期转换ETL流程；

图10为数据清洗架构及工作流程；

图11为SNM滑动窗口示意图；

图12为SOA基本架构；

图13为基本的SOA云服务架构；

图14为基于SOA的云体系框架；

图15为基于SOA的云计算框架模型的实现过程；

图16为联邦式信息检索平台的总体层次架构；

图17为联邦式信息检索平台的网络拓扑图；

图18为基于Agent的信息推送结构；

图19为协同过滤工作流程图；

图20为RSS信息推送技术模型。

具体实施方式

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

本实施例提供一种基于大数据的钻井提速影响因素分析模型，其包括：

一、基于主题的数据仓库系统，实现分布式多源异构数据源的数据集成；

为了实现对钻井业务系统基础数据按需地高性能集成，优化数据质量，对数据进行抽取、转换、加载，形成分析型数据。根据数据的异构性、半结构以及非结构性等特点，本实施例选择Kettle作为数据集成的工具，相对于其他开发工具，Kettle使用简便，轻载而且查询效率高，具备显著的优势。

1.1基于Kettle构建ETL过程模型

从多数据源抽取、增量数据捕获等方面分析了ETL关键技术，制定了面向钻井石油的数据集成解决方案。根据石油钻井的井史管理系统的特点，针对钻井领域数据量大、关系复杂、分布、异构、自治等当前存在的问题，利用Kettle的ETL数据处理技术，快速、高效地实现数据集成，为企业的商业智能分析奠定了数据基础，提升企业决策水平。

1.1.1基于Kettle的ETL

如图1所示，Kettle的ETL活动中主要包含Spoon、Kitchen、Pan以及Carte四大组件。Spoon创建Job和Transformation的数据成环境，制定整个ETL解决方案；Kitchen调用作业流程；Pan调用转换流程；Carte实现ETL集群处理。制定的作业与转换流程以资源库和本地文件两种方式存储，通过加载作业与转换流程文件，可以方便地实现对作业、转换流程的优化与重新定制，提升ETL处理效率，改善数据质量。

ETL最后一个环节是将转换数据加载至目标数据仓库中。数据仓库是一个面向主题的、集成的、非易失的且随时间变化的数据集合。依据企业基础数据，分析数据主题，采用星型或者雪花型多维模式进行数据存储，实际处理过程中KETTLE将星型、雪花型结构映射为事实表和维度表，如此利于构建数据立方体，实现对数据的多维查询。在本实施例中，数据源表所形成的星型模式如下图2所示。

1.2石油钻井企业数据仓库模型

1.2.1数据仓库模型

在深入分析了各主题的基础上，结合传统的数据仓库技术，设计了一个基于主题的数据仓库模型，该模型分为四个层次：系统数据资源层、数据访问层、ETL数据集成层、决策支持层，如图3所示。

系统数据资源层为数据仓库系统基础，通常包含企业内外部信息；所完成的石油钻井项目，其各业务系统分散在无线传输库和RTX数据库中。

数据访问层，Kettle对数据库的连接基于JDBC数据连接规范。

ETL数据集成层,该层的主要功能是在主题指导下完成数据源到数据仓库和数据集市的ETL处理。该层是整个数据仓库模型的核心层，是将企业基础数据转换成分析型数据的关键。

1.3大数据项目数据集成的实现

本实施例基于KETTLE为石油钻井项目制定了数据集成解决方案，将其历史数据业务系统所生成的历史数据库数据转换为可供决策的分析性数据。根据企业实际需求规划，对钻井基本数据表、钻头数据表、钻具组合表等进行数据的抽取，采用事实表-维度表的多维模型构建了星型数据仓库，实现对各主题域维度数据和事实数据的装换与加载，最终形成面向石油钻井企业的数据仓库。下面将各主题域数据为例，描述其ETL处理过程。

1.3.1 ETL总作业流程

根据数据仓库各主题，设计与主题相对应的作业(Job)流程，该作业流程制定了整个ETL执行的顺序，宏观上协调了每一步的执行任务，是成功构建石油钻井项目数据仓库的关键，该作业流程图如图4所示。

ETL总作业流程图整合各业务系统数据库资源，进行了异构数据源的数据库参数设置，保证了ETL在执行过程中能够访问到各系统数据库资源。Kettle将结构化、半结构数据转化为Kettle可识别的数据流。在ETL总作业流程中，每个主题数据的ETL处理均由一个作业组成，每个子作业再经由各自主题ETL的详细转换流程，实现对数据清洗、转换、源表与目标表的属性映射等。

1.3.1.1作业实现

Kettle通过作业来控制整个处理流程。它包含一个或多个作业项。这些作业项以某种逻辑顺序执行。根据钻井趟数数据集成的实际需求，将钻井趟数的处理流程分为两个作业，分别是：

单井起钻趟数信息数据集成

根据石油钻井的业务需求，起钻趟数主题可以按照单井、区块等条件进行选择。而井段的判断依据是根据井段划分，于定向井而言，划分为一开、二开钻。对于水平井而言，划分为一开、直井段、斜井段、水平段。对于N趟钻而言，是按照钻头使用个数进行判断。因此，在单井起钻趟数数据集成的主题下，涉及多个库的多张表的关联。而在此工作流中，通过触发的方式将井段、钻井趟数等信息进行获取。作业流程如图5所示。

单井统计信息数据集成

在单井起钻趟数相应需求字段生成以后，根据石油钻井大数据业务需求，需要显示该区块单井使用的钻头信息、钻具组合信息、泥浆性能信息、钻井参数信息。而对于这些展示的数据信息而言，并非源数据中本身存在的，为了便于后期的决策分析，需要对这些信息进行聚合统计。如统计某型号钻头数量最多的信息、某钻具组合使用频次多的单井详细井史信息以及参数数据中的泥浆性能、平均位移、平均钻井周期、机械钻速最高等条件下是那种型号的钻头信息，这些信息需要ETL执行处理。作业流程如图6所示。

1.3.1.2转换实现

转换是由步骤组成的流程。它按照预先制定的工作步骤对数据流进行特定转换操作，实现数据的抽取、转换和加载。使用Kettle实现单井钻井趟数信息的ETL有两个关键的转换，分别是单井起钻趟数转换和单井统计转换。

单井起钻趟数转换，其具体的转换流程如图7所示；

单井统计转换，其转换流程如图8所示；在表输入中，筛选特定井型(定向井)，剔除未完钻单井，映射完钻日期(wzrq)、区块(qk)、井号(jh)、井型(jx)、井别(jb)、队号(dh)等字段，从而确定转换规则。

石油钻井ETL转换过程中日期处理，在该石油钻井项目中，针对效率分析，涉及到钻井周期、建井周期、开钻日期、完钻日期等日期格式。需要对日期格式统一处理，便于数据集成的展开。其转换流程如图9所示；

二、基于规则引擎的数据清洗架构，实现大数据的数据质量保证；

钻井大数据信息化平台项目中涉及的数据源非常广泛，由于业务的多样化和分离化，在整个项目牵涉到了许多现有存在的异构系统，其数据的组织和存储结构也不尽相同，进而导致了信息多元化，多样化，数据的一致性、准确性和完备性都难以保证，从而难以保证大数据项目中所包含的数据质量。低质量的数据给钻井业务带来了很大的不便，甚至会造成很大的损失。针对当前这样的问题，本实施例通过把各种异构源的数据有效的集成到一起，实现统一的管理。在建立数据仓库和数据集成的过程中，数据清洗是一项不可或缺的任务，它可以保证提供准确、唯一的企业数据视图，为用户提供高质量的数据服务，也为将来的数据挖掘和知识发现提供了坚实的基础。

2.1数据质量的问题分类

数据清洗可被描述为从大量原始数据中使用一系列的逻辑检测出脏数据并修复或丢弃之。在项目施行过程中，主要出现以下四种数据质量问题：

1、属性(字段)层面。这类错误仅局限于单个属性的值。

2、记录层面。这类错误表现在一条记录不同属性值之间出现的不一致性。

3、记录类型。表现为同一数据源中不同的记录类型之间的不一致性。

4、数据源层面。表现为数据源中的某些属性值或记录与其他数据源中的相关值的不一致性。

针对以往的数据清洗的灵活性差的硬编码和和低效的人工判断的缺陷，和在项目实际中发现的数据质量问题，我们建立了基于规则引擎的数据清洗架构，利用规则来描述数据清洗逻辑，使用规则引擎来执行清洗逻辑。

2.2基于规则的数据清洗技术

数据清洗规则由两部分组成：用于检测脏数据的逻辑规则和对脏数据采取的动作(修复或丢弃)的描述。可以用大量的商业规则和约束来描述数据清洗的全过程，即审计、筛选和修复。基于规则的数据清洗技术能够处理各种数据质量问题。

2.2.1基于规则的数据清洗技术实现

数据清洗规则最终表现为复杂的逻辑。如何提炼、表达、组织和高效地判断这些逻辑是基于规则的数据清洗技术的关键所在。需注意，数据质量问题的定义和业务领域是强相关的。对某个业务部门是干净的数据，对同一企业的另一业务部门却可能是脏的。而且，业务是随时间变化的，因此数据质量问题的定义也随时间变化。数据清洗规则会经常发生变化。这要求基于规则的数据清洗技术的实现必须能灵活地定义规则，必须能灵活地在线调整规则。本实施例使用规则引擎技术解决这一问题。

规则引擎将提交给它的数据对象与加载在引擎中的业务规则进行测试和比对，激活符合当前数据状态的业务规则并根据其声明的执行逻辑，触发相应操作。可见，规则引擎技术将硬编码的复杂的if...else...结构转化为了软编码的规则集，从而能做到灵活地定义规则和在线调整规则。

2.2.2基于规则引擎的数据清洗框架的设计，如图10所示；

基于规则引擎的数据清洗框架由5个部分组成

(1)规则定义界面：以可视化方式为数据源表定义各种数据清洗规则。

(2)规则库：集中保存规则定义界面所定义的规则，以便规则管理和重用。

(3)规则模板库：规则定义界面可从规则模板库中提取规则模板，用户进行修改后形成规则。用户可以手工定义新的规则模板或将规则定义界面中定义的规则保存为规则模板。

(4)规则引擎：是规则的运行环境，负责编译和执行规则。

(5)数据清洗插件类：定义了一套机制，使得外部软件(如ETL软件或数据质量工具)能够集成数据清洗功能。即，它负责接收原始数据并为之调用规则引擎来执行规则，并将处理结果返回给调用者。

可见，在基于规则引擎的数据清洗框架中，规则就是持久化了的领域知识。数据清洗的覆盖率和正确率仅和规则定义的覆盖度和正确率相关。由于使用了规则定义界面来定义数据清洗过程，因此用户能够快速实施数据清洗系统。规则被保存在集中的规则库中，相同的规则有可能被用于多个数据源，从而加强了规则的可重用性。

这个基于规则引擎的数据清洗框架采用Java技术开发规则定义界面，使用XML文件构建规则库和规则模板库。使用Drools规则引擎作为规则的运行环境，使用Java类来实现数据清洗插件类。

Drools实现了一种新颖的面向对象的Rete算法(Rete-OO)，允许用更自然的方式描述领域规则。Drools能够在规则描述文件中直接嵌入Java等多种编程语言来进行逻辑规则的描述。然后，Drools将从规则描述文件中解析出来的编程语言代码交给特定语言的脚本执行模块来执行。该实现基于Java或XML技术，具有平台无关性。

2.3数据清洗引擎

2.3.1 Rete算法

为了解决产生式推理引擎效率低下的问题，Forgy在1979年提出Rete算法作为产生式系统的高效的模式匹配算法。Rete算法的初衷是：利用规则之间各个域的公用部分减少规则存储，同时保存匹配过程的临时结果以加快匹配速度。为了达到这种效果，算法将规则拆分，其中每个条件单元作为基本单位(节点)连接成一个数据辨别网络，然后将事实经过网络筛选并传播，最终所有条件都有事实匹配的规则被激活。

网络共有5类节点：Root节点、Type节点、α节点(也称单输入节点)、β节点(也称双输入节点)、Terminal节点等，根节点(RootNode)代表整个Rete网络的入口，它可以让所有的事实通过，并传递给ObjectType节点。作为根节点的后继，ObjectType节点用于选择事实的类型，将符合本节点类型的事实向后继的α节点传播。α节点主要进行同对象类型内属性的约束(intra－conditions)或常量测试(LiteralRestriction)，比如“name＝＝zhang”,“age>15”等等。β节点主要根据不同对象之间的约束(inter-conditions)如“p.tools＝＝c.zuanju”,”p.age>c.age”等进行连接操作。β节点又分为Join节点、Not节点等。Join节点包括两种输入，左部输入事实列表，称为元组(tuple)，右部输入一个事实对象，对象与元组在Join节点按照类型间约束进行Join操作，将符合的事实加入元组中继续传入下一个β节点。Terminal节点对应的规则被激活。

2.3.2算法步骤

Rete算法的步骤主要分为两个部分：规则网络的建立和事实的匹配。其中，网络建立过程算法如下：

(1)创建根。

(2)取出一个规则r。

a.取出一个模式p，检查参数类型，若是新类型，则加入一个类型节点；

b.检查模式p的条件约束，对于单类型约束，检查对应的α节点是否已存在，如果存在则记录下节点位置，否则将该约束作为一个α节点加入链的后继，所有α处理完后连接α内存；

c.检查模式p的域，若为多类型约束，则创建相应β节点，其左输入为前一β节点(第一个β节点左部输入为空)，右输入为当前链的α内存；

d.重复b-c，直到模式p的所有约束处理完毕；

e.重复a-d，直到所有的模式处理完毕，创建Terminal节点，每个模式链的末尾连到Terminal节点；

f.将动作(Then部分)封装成叶节点(Action节点)作为输出节点。

3)重复(2)直到所有规则处理完毕。

运行时的匹配过程如下：

(1)从工作内存中取一WME放入根节点进行匹配。

(2)遍历各α节点(含ObjectType节点)，如果α节点约束条件与该WME一致，则将该WME存在该α节点匹配内存中，并向其后继节点传播。

(3)对α节点的后继结点继续(2)的过程，直到α内存所有通过匹配的事实保存在α内存中。

(4)对各β节点进行匹配，如果单个事实进入β节点左部，则转换成一个元素的元组存在节点左侧内存中。如果是一个元组进入左部，则将其存在左内存中。若一个事实进入右侧，则将其与左内存中的元组按照节点约束进行匹配，符合条件则将该事实对象与左部元组合并，并传递到下一节点。

(5)重复(4)直到所有β处理完毕，元组对象进入到Terminal节点。对应的规则被触活，将规则后件加入议程。(Agendar)

(6)对Agendar里的规则进行冲突消解，选择合适的规则执行。

2.3.3 Drools引擎

Drools是基于Rete算法的一个增强的Java语言实现。Rete算法是CharlesForgy在1979年发明的,是目前用于生产系统的效率最高的算法(除了私有的ReteII)。Rete是唯一的效率与执行规则数目无关的决策支持算法。其核心思想是将分离的匹配项根据内容动态构造匹配树,以达到显著降低计算量的效果。

Drools把Rete算法封装成Rete-OO,放在一个核心模块中,然后又添加了一系列外围模块扩展它的功能。除了Drools-core模块实现了Rete核心算法外,Drools-smf(语义模块框架)和Drools-io模块用于从当前文件系统中创建规则集。Drools-base模块是一个基于XML语言的基础语义理解模块。在XML语言的基础上支持python、groovy、java三种语言进行规则的定义。此外,Drools支持jsr-94规范,提供了相应的drools-jsr94兼容模块。可选择以jsr94方式开发,便于以后的移植,也可选择基于drools-base的开发方式,更为简便高效。

Drools项目的规则文件为自定义格式。由一个XML语言定义的基本的语义模块加上java(groovy或python)语义模块。开发者也可以根据需要定制自己专用的语义模块。每一个规则文件包括一个唯一的规则集,规则集包括一个或多个规则。每个规则包括一个或多个参数。这些参数用于在规则的条件中进行判断和执行相应的操作,参数对应的是一个java类,drools会在创建工作内存的时候把它自动实例化。每个规则包括一个或多个条件以及一个最后的操作。

2.4数据清洗算法

2.4.1基本近邻排序算法SNM

基本近邻排序算法ThebasicSorted一NeighborhoodMethod,SNM算法)，它的基本步骤如下:

1)创建排序关键字。抽取记录属性的一个子集序列或属性值的子串,根据这些子集序列或属性值的子串,计算数据集中每一条记录键值。

2)排序。根据排序关键字对整个数据集进行排序,尽量把潜在的、可能的重复记录调整到邻近的区域内,便于进行记录匹配。

3)合并。在排序后的数据集上滑动一个固定大小的窗口,窗.口可容纳w条记录,则每条新进入窗口的记录都要与先前进入窗口的w一1条记录进行比较,如检测到重复记录,则进行合并,否则最先进入窗口内的记录滑出窗口,最后一条记录的下一条记录移入窗口,再进行下一轮比较,直到数据集的最后记录移入窗口后比较完毕。

如图11所示，SNM算法采用滑动窗口的方法,每趟只比较窗口中的w条记录,比较次数小于w*N次,并且,w比N小的多,极大地提高了比较速度。

2.4.2多越近邻排序算法MPN

针对SNM算法可能会漏查的缺陷,Hemandez等人提出了多趟近邻排序算法(Multi-PassSortedNeighborhood,MPN,该算法的基本思想:独立地执行多趟SNM算法,每趟创建不同的排序关键字和使用相对较小的滑动窗口。然后采用基于规则的知识库来生成一个等价原理,作为合并记录的判别标准,将每趟扫描识别出的重复记录合并为一组,在合并时假定记录的重复是具有传递性,即计算其传递闭包(transitiveclosure),所谓传递闭包,是指若记录R1与R2:互为重复记录,R2与R3互为重复记录,则Rl与R3互为重复记录。通过计算每趟扫描识别出的重复记录的传递闭包,可以得到较完全的重复记录集合能部分解决重复记录漏查问题。

2.4.3优先权队列算法

优先权队列算法,优先队列策略借用邻近排序算法的思想,具体策略:先抽取一个或多个字段构成关键字,根据关键字,对数据集进行排序,然后在一个长度固定的子集队列中检测匹配记录,采用类似LRu算法(最近最少使用算法)来控制队列的长度。通过匹配操作找出需要合井的子集,计算其传递闭包,然后合并它们,最后得到若干个近似重复记录集。基于这样一个观察:一个简单的关键字在排序后不能完全将重复记录聚集在一起,因此一趟优先队列算法可能遗漏一些重复记录,为避免这种情况,提出多趟优先队列算法厂-每次采用不同的关键字进行排序。

2.5数据清洗策略

脏数据最多的表现形式就是记录的属性值异常。其清洗策略主要有:

(l)空值的清洗策略，空值问题是数据清洗经常遇到的问题。一般的空值问题可分为两种:①是缺失值；②是空值。缺失值是指字段的值实际存在,但它的值是空的,如成年人都有居民身份证,如果某个成年人身份证号的值为空,就属于缺失值。空值指字段的值实际上并不存在而空值。空值处理策略是把字段值直接替换成空；缺失值处理策略有:①某些缺失值可以从本数据源或其他数据源推导出来。可用平均值、中间值、最大值、最小值或更为复杂的概率统计函数值代替缺失的值,但准确性比较低；②人工输入一个可接受的值。

(2)错误值清洗策略有:①用统计分析的方法修正错误值或异常值；②使用简单规则库(常识性规则,业务特定规则等)修正错误值或异常值；③使用不同属性间的约束修正错误值或异常值；④使用外部数据修正错误值或异常值。

(3)不一致数据的清洗策略，不一致数据主要是由于系统和应用造成的,比如不同的数据类型、格式、粒度和编码方式等,另外由于错误的输入、硬件或软件故障,不及时更新等。解决的策略,主要是在分析不一致性数据产生原因的基础上,应用多种变换函数、格式函数、汇总分解函数和标准库函数去实现清洗。第二类情况,消除数据集中的近似重复记录策略有：(l)保留字段项比较全的记录。(2)保留无错误的数据记录。(3)保留最新记录。

三、基于SOA的业务智能云服务平台

3.1基于SOA的云服务架构

SOA是一个组件模型，它将应用程序的不同功能单元通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。SOA具有高内聚(封装性)、低耦合、粗粒度、重用性、自治性、互操作性等特性，服务与服务通过接口实现服务操作，准确地说更是一种架构理念，强调了不同层次的服务理念，满足网络环境下业务集成的需要，通过连接能完成特定任务、独立功能的实体来实现的一种软件系统架构。服务重用性、自治性、松耦合、抽象性、规范化的契约是SOA架构的基本原则。

SOA包括服务提供者、服务用户、服务中心三个实体。服务用户是发起服务请求的实体.向服务中心查找需要的服务，然后绑定相应服务提供者获得需要的服务功能；服务中心为服务提供者提供注册服务，为服务用户提供服务查询，并将选择的服务提供者的服务授权给服务用户；服务提供者将服务注册到服务中心，并根据服务用户请求执行相应的服务功能。SOA的基本服务架构如图12所示。实现了三者之问的绑定/执行、发布、授权/查找等5个基本操作。经过分析可知，SOA是一种特别适合分布式计算环境中动态地描述、发布、发现和调用的一种架构，可以借助现有的应用来组合产生新服务，为用户提供更好、更灵活的应用程序和业务流程。

云计算在架构上正好是SOA的一种扩展和深入应用，基于SOA作为比较完美的架构，可以满足在分布式网络环境下业务集成的需要，通过连接能完成特定任务、独立功能的实体构建云服务平台的架构。基本的SOA云服务架构如图13所示。用户通过浏览器访问云，云服务平台中心相当于云服务代理和控制中心，根据用户请求选择相应的云服务，通过若干用户云服务接口调用相应的云服务完成操作，并返回云服务结果给云端用户，云服务提供者是云服务后台分布式计算机服务资源，提供各种云服务。

3.2基于SOA的云体系框架

接下来.在基本的SOA云服务架构基础上，进行云体系框架的设计，如图14所示；针对SOA的服务中心、服务提供者和服务用户三类实体设计为云体系框架中的服务消费者、服务提供者、服务控制中心。其中：

(1)服务消费者指云端用户。主要在云服务平台查找合适的云服务，发起云服务请求，它是网络上的终端节点，它与服务提供者的云服务接口进行了绑定，并且通过使用相应的服务实现业务操作。

(2)服务控制中心是云服务平台中心，将云服务提供者发布的各种服务信息存储起来，它可以被用来查找各种服务所处的位置(云服务接口层)，云端用户通过云服务平台中心查询它所需要的服务及通过服务接口使用所要的服务，云服务平台中心也是网络上的节点。

(3)服务提供者是网络上分布式节点资源集合，为网上若干的云端用户提供网络服务。服务提供者节点提供了对业务系统、子系统和组件的访问服务。它具有强大的计算能力，云结构下的服务提供者共分为四层：云服务接口层、云服务调度管理层、云计算服务层、云物理服务层。

①云服务接口层为云端用户提供统一规范的绑定接口，是调用云服务的专用通道。终端用户通过专用入口通道进入云计算服务中心，订制和消费其所需的服务。

②云服务调度管理层负责进行服务资源凋度管理过程操作服务，云服务调度管理层检测和响应云服务接口层提交过来的云服务请求，检测服务请求合法性，判断和管理是否具有所需的服务，在合法和有相应云服务的情况下，去调度云计算服务层的服务资源；

③云计算服务层提供了分布式的云处理程序、虚拟处理功能、存储管理服务，它是云服务的功能中心和服务执行中心，是网上节点集合，还可以提供虚拟机服务；

④云物理服务层是云服务的基础层，它包括了云团内的服务器资源(CPU、存储器等)，为云计算服务层提供存储和CPU等硬件资源服务，具有大型计算中心功能和无限存储功能，为云团的服务功能拓展提供了资源智能分配服务。

根据上文提出的基于SOA的云计算框架的基础结构，这里给出一种切实可行的基于SOA的云计算框架模型的实现过程。如图15所示。

消费者首先向服务代理提交服务请求，服务代理在自己的服务范围内查找是否存在该项服务，如果不存在，直接拒绝此项服务申请，如果存在，回复消息通知消费者1具体的访问位置。消费者1访问该位置上的服务接口程序，并通过接口调用云服务管理层。云服务管理层接到调用后，查找云资源服务器中的虚拟机，根据消费者1提出的消费资源请求，分配具体的服务器资源(CPU、内存、存储器、带宽)给消费者，从而消费者1可以使用该云中的服务器资源。消费者2、消费者3……消费者n的服务过程类似。

3.3基于SOA的数据联邦式信息检索统计平台的实现

通过构建基于SOA的联邦式信息检索平台，在不改变各个部门原有业务逻辑的前提下，对各个分布式的异构数据中心构建检索服务，以实现企业内单个职能部门一站式获取所有部门所提供的共享信息。

3.3.1联邦式信息检索平台模块

数据收集模块

一般通用的搜索引擎都会有一个数据收集器，即网络爬虫，但本平台中数据都是来源于各分布式数据信息系统的信息录入和采集，从整个企业来看本平台一个封闭的系统，因此不存在外网数据的抓取。录入的数据暂时保存在临时的共享数据管理中心，只有管理员审核通过的记录才能成为共享数据。

索引构建模块

常规的检索可以使用数据库的结构化查询语言SQL完成，主要是“Select”操作，SQL的通配符提供了多样化的查询功能，数据库索引技术也在某种程度上提高了检索速度。但是SQL查询的缺点在于其不仅不能计算查询关键词与检索文档之间相关度大小，其最大的缺陷就是在面对海量数据时检索速度慢。倒排索引是目前搜索引擎使用最广泛的检索技术，它不同于SQL“正向索引”的检索模式，正向索引一般将检索文档作为索引，选中某条文档，直接判断此文档是否包含检索关键词。倒排索引是一种“反向索引”的检索模式，以检索关键词分词后的词片为检索入口，直接得到所有包含检索关键词词片的文档集合，甚至可以得到词片在文档中确切位置。

检索服务发布模块

本平台使用的是Web Service技术实现SOA的概念，所以需要把单个数据系统的信息检索功能进行服务的封装，并发布在服务管理中心(UDDI)。这里服务发布采用的是Apache组织关于实现SOA的开源框架Tuscany，Tuscany采用的是服务组件框架(ServiceComponent Architecture)，其核心组件提供了一整套基于Java语言的API，通过其提供的API便可以把本地的功能函数发布成能异地调用的服务。

3.3.2联邦式信息检索平台总体架构

本平台的总体架构分为七个层次，从下往上依次为网络基础设施层、云平台虚拟层、数据访问层、对外服务层、安全链路层、业务功能层、系统表示层，如图16所示。

系统表示层为用户提供统一的检索入口，为此需要设计统一标准的信息检索前端界面和统一格式的检索结果显示页面。平台为用户提供的业务功能主要有信息上传、联邦式信息检索、资源获取、资源下载等。对服务层的访问，使用的是安全链路层的简单对象访问协议(SOAP)，分布式的检索Web服务通过数据访问层完成对本地索引文档的检索，云平台虚拟层提供了整个平台开发所需要的虚拟机，网络基础设施位于最底层，为平台的构建提供基础硬件设施的支撑。

3.4联邦式信息检索云平台的性能配置优化

本平台异构的数据中心由单个的实体服务器实现，为了保证数据安全、服务的质量、企业软硬件资源的利用率等因素，本实施例利用了钻井公司现有的VMware企业级私有云平台，私有云平台各种优点更好的满足了本平台企业级的信息共享，可以对数据、安全性、服务质量进行更好的控制。

由于云平台一般可以对服务器及服务器上虚拟机资源的使用情况进行实时监控，本平台在VMware云环境加入了负载均衡机制，以提高系统在高负载环境下的稳定性。基于此种构思，本平台实现了主服务器计算与数据存储的分离，使用了两个虚拟计算节点和一个虚拟存储节点。其中两个虚拟计算节点类似于Master与Slave的关系，用户对联邦式检索系统的访问默认分流到计算节点一，计算节点一会依据特定的分流策略判断是否将用户的访问(Session)进行分流或直接在本机响应处理，所以说计算节点二是一个辅助作用，图17是整个联邦式信息检索平台的网络拓扑图。

一般的分流策略有两种，第一种是基于在线用户数的统计，即在线用户数超过某一阀值Master计算节点则进行分流；第二种是负载监听，主要是监听Master计算节点的CPU和内存利用率大小，达到某一百分比值就将用户请求分流到Slave虚拟机。基于云环境的特点，本平台选择了第二种分流策略，又由于在实验过程中发现CPU的使用率很不稳定，特别是在有新的进程启动时，CPU的使用率会出现短暂高峰，而内存的使用率在某一段持续的时间内比较稳定。主要是因为CPU是尽最大努力去进行计算，直到等待队列没有任务时，CPU的使用率才降低，CPU绝大部分时间的使用率基本上在30％以内，而内存的高使用率确实也能有效的反应当前机器的负载情况，所以本平台在具体的实现过程中采用内存的使用率作为判断Master计算节点负载大小的指标，具体内存使用率同时考虑了虚拟机内存使用率和虚拟机所在服务器的内存使用率，只要其中的任意一项超过了某一阀值，便可以将新的用户访问请求分流到Slave虚拟机。

负载均衡的设计不仅仅提高了平台在高负载时的稳定性，VMware云平台自带的警报功能也提高了数据和系统的安全系数，即通过设置触发器，当系统发生或者达到了触发器定义的条件或事件时，便会给管理员发出一个警报。警报所定义的对象同时包含的了服务器和服务器上的虚拟机，对服务器触发器设定主要在于是否满足特定的条件或状态，例如CPU的使用情况和电源状况，对虚拟机的触发器的设定主要在于是否发生特定事件，比如虚拟机已打开电源。管理员在得到这些警报信息后，可以直接通过vSphere对负载较高的服器上的一个或多个虚拟机进行迁移，将虚拟机迁到其他负载较小的服务器上。这简化了系统的维护和管理，平衡了系统的负载比例，增强了系统的容错能力和优化了系统电源管理。

四、智能推送服务大数据信息平台的智能推送技术

本实施例的大数据信息平台基于用户的注册信息和主动地收集用户日常的行为模式，可以智能的归纳出用户的专业和兴趣点，建立起用户行为轮廓，并根据推断出的用户需求，将最新的数据与信息分门别类地传送到相应的用户桌面或智能设备中。

4.1信息推送的意义

信息推送是通过一定的技术标准或协议，在网络平台或云平台上通过定期传送用户需要的信息来减少信息过载的一项新技术。准确的说，它属于第三代浏览器的核心技术，其关键是能够主动地收集用户日常行为模式，和用户注册信息等归纳出用户专业和兴趣点，根据推断出用户需求，将最新数据与信息分门别类地传送到相应的用户桌面或智能设备中。有效改变用户获取信息的方式，因而较大幅度地提高了大数据平台中的信息和数据的使用效率。

4.2信息推送方式

常用的信息推送技术包括自动拉取技术和事件驱动技术。自动拉取技术是指用户要求信息发送方按照预先约定的时间自动提交其指定的新信息，它实际上是信息检索中的定题检索服务在网络信息时代更深层次的发展；事件驱动技术则是以规则为基础，信息发送方判断预先设置的规则是否发生，如发生则将相关信息或内容提交给用户。目前，Push技术主要有三种实现方式：

1)消息方式，根据用户提交的信息需求，利用电子邮件或其它消息系统将有关信息发送给用户。该方式并不具备很强的交互性和强制性，对资源和信息流量的要求不高，可以看出这是最弱意义上的推送，但容易实现。

2)代理(Agent)方式，通过使用代理服务器定期或根据用户指定的时间间隔在大数据信息平台中搜索用户感兴趣的信息内容，然后将结果推送给用户。这种方式在于对信息的请求和推送都是通过代理来实现的，因此对用户来说是透明的。优点是因为始终保持连接，效率高，缺点是必须借助于某一端口，在病毒泛滥的今天，端口的开放会带来一些麻烦。

3)频道方式(Channel Definition Format,简写为CDF)提供完整的Push服务器、客户端部件及相关开发工具等一整套集成应用环境，它将某些数据源服务定义为浏览器中的频道，Push服务器负责收集信息，形成频道内容后推送给用户。应该说,频道式推送技术是目前普遍采用的一种模式,它将某些页面定义为浏览器中的频道,用户可像选择电视频道那样接收有兴趣的网播信息。

4.3信息推送的分类

信息推送系统的核心问题是用户对待推送项喜好程度的效用函数f仅在部分待推送项与系统用户空间中有定义，即信息推送系统需计算出效用函数在未定义空间的函数值。计算未定义空间效用函数f的函数值的方法有许多种。本实施例按使用方法来对信息推送进行以下分类。

1)基于内容的推送(content-based recommendation)其起源于信息检索(Information Retrieval)和信息过滤(Information Filtering)技术。它的基本方法是基于用户先前已有的评分项作为用户对新的项进行评分，向用户推送与其过去喜欢信息的相似信息。通常推送的是包含数据，文本内容较多的信息。

2)协同过滤推送(collaborative filtering recommendation)向用户推送与其有相同喜好的用户所喜欢的信息。协同过滤信息推送系统首先寻找与用户有相似喜好的用户,然后将这些用户偏好的信息推送给用户。

3)混合推送(Hybrid approaches)由于基于内容的信息推送与协同过滤推送都存在一定的局限性,目前许多信息推送技术都尝试将这两种方法进行整合,提出一些混合型的信息推送策略。

4.4信息推送技术

4.4.1 Agent推送技术

Agent是人工智能领域发展起来的一个概念。随着计算机网络以及基于网络的分布式计算技术和云计算技术的发展，有关Agent的研究逐步成为人工智能领域的一个新的研究热点。如今，Agent技术己经逐渐渗透到专业领域计算的方方面面，为解决各类问题提供了一个崭新的角度，被广泛应用于信息检索、信息过滤、网络管理、协同办公等诸多领域。

Agent模型

基于Agent的信息推送系统的体系结构模型在逻辑上可分为三层：信息表示层主要是为用户与个性化信息推送系统的交互提供一个接口，即用户通过该接口进行注册、登陆、查看系统推送给用户的信息资源以及反馈相关信息；信息选择层主要是对信息搜索层的搜索结果进行再加工和过滤，通过从信息表示层反馈过来的信息不断调整用户兴趣模型，实现智能化的推送服务；信息搜索层是在数据源中查找用户感兴趣的相关信息，得到一系列数据集。每一层都有相应的Agent为用户服务。

Agent工作流程

当用户使用系统时,会产生对应于这个用户的五个Agent:用户Agent、过滤Agent、学习Agent、信息检索Agent和监测Agent。其工作流程如图18所示。

用户Agent根据用户的基本信息和行为，对用户进行建模；过滤Agent根据用户的兴趣以及个性化信息采用向量空间法进行信息过滤，从而使系统具有一定的针对性与个性化；学习Agent通过基于观察记忆的学习机制、基于用户反馈的学习机制和基于ID3归纳的学习机制来自主学习用户的兴趣，使系统具有一定的智能性。信息检索Agent利用现有的搜索引擎技术，采用有限深度、广度优先的搜索算法在信息源中查找用户感兴趣的相关信息，从而使系统具有一定的完备性；监测Agent通过个性化的无监督机制，保证信息的可靠性与可用性。

4.4.2协同过滤(Collaborative Filtering,CF)推送技术

协同过滤推送是当前最成功的推送技术。它是一个基于存储推理的变形，能够发现内容上完全不相似的资源，用户对推荐的内容可能事先是预料不到的，却是用户潜在的兴趣，它特别适合于提供个性化推荐方面的应用。在协同过滤中，用户通过相互协作来选择信息，它依据其他用户对信息做出的评价来挑选信息。协同过滤方法对用户的行为进行分析，并不关心信息的实际内容。因此可以完成对文档、图表、图像、图形等的推荐。协同过滤工作流程如图19：

协同过滤有以下4个特点：

(1)推送对象没有特殊要求,能处理非结构化的复杂对象,不需要分析对象的特征属性；

(2)共享其他人的经验。避免了内容分析的不完全和不精确,并且能够对一些复杂的难以表述的概念(如信息质量、品味)进行过滤；

(3)可以有效地使用其他相似用户的反馈信息,减少用户的反馈量,加快个性化学习的速度；

(4)具有推送新信息的能力。

协同过滤也存在以下缺陷：

(1)第一评价问题。当一个新用户进入到推荐系统时，他没有对任何项目做出评价，推存系统也就无法找到他的相似邻居，也就无法获知他的兴趣点，也就无法对他进行推荐。

(2)基于用户的协同过滤算法普遍存在数据稀疏性问题。在许多采用这种技术的推送系统中，每个用户涉及的信息量相当有限，例如亚马逊网站中，用户最多不过就评估了上百万本书的1％-2％，造成评分矩阵数据相当稀疏。如果两个用户没有对相同的项目进行打分,即使这两个用户的兴趣爱好都相同,系统也无法得出他们之间的相似度，从而难以找到相似用户集，导致推送效果大大降低。

(3)精确性问题。既忽略了对推荐质量的要求,导致推荐的项目经常不符合用户的要求，用户很容易会对此推荐系统失去信心。

(4)自动化程度问题。目前多数的协同过滤推荐算法所需要的项目评分都是需要采用显式的评分输入方式，也就是用户必须显式的输入对项目的数值评分。这种方式虽然最能直接了解用户的兴趣点,却使得用户在使用上很不方便。

4.4.3 RSS推送技术

RSS是Really Simple Syndication的缩写,中文称作“简易信息聚合”,是基于XML技术的互联网内容发布和集成技术。号称“网络信息拯救者”的RSS有强大的信息聚合和推送功能,它能够用于共享各种各样的信息，包括新闻、简讯、Web站点更新、事件日历、软件更新、特色内容集合和基于Web进行拍卖的商品等。目前，越来越多的博客网站、新闻网站、政府网站以及许多个人和商业网站都支持RSS，相信不久的将来，RSS将有飞速地发展，并为互联网的发展提供重要的技术支持。

RSS有以下5方面的特点：

(1)聚合性:RSS是一种被广泛使用的内容包装定义格式，任何内容都可以采用这种格式来发布信息，而在用户端,RSS阅读器软件的作用就是按照用户的需要,有选择性地将用户感兴趣的内容聚合到该软件的界面中,为用户提供多来源信息的“一站式”服务。

(2)实时性:RSS搭建了信息迅速传播的一个技术平台，发布一个RSSFeed后,这个RSSFeed中包含的信息就能直接被其它站点调用。

(3)即时性：RSS使用了规范的XML文本格式,信息的传递、接收处理都非常方便。RSS桌面聚合工具也提供了将RSS信息转化成HTML信息,直接在页面上点击媒体链接,就可以获得最新信息的HTML的页面显示。

(4)服务器端内容的RSS包装在技术上实现极为简单，而且是一次性的工作，使用长期的信息发布边际成本几乎为零，是传统的电子邮件、卫星传输、网络浏览等发布方式所无法比拟的。

(5)无垃圾信息：RSS用户端阅读软件的特点，是完全由用户以频道的形式订阅值得信任的内容来源，同时RSS信息本身具有很好的分类特性。

利用RSS信息推送技术，信息提供者在发布信息的同时以XML文件的形式向用户提供信息内容聚合种子(RSS Feed)。该文件主要用于描述信息的主要内容，并附加详细信息的网络链接。用户在接收到所订阅的RSS Feed后，根据Feed中提供的有关信息内容的描述，确定是否符合个人需要。如果符合，则通过RSS Feed中提供的链接进入，查看具体内容。

RSS种子以XML格式文件为载体，所以可供提取的数据来源有3种：XML文件；关系型数据库；纯XML数据库即Native-XML数据库。网站提供的信息内容可以划分为不同的频道，为每个频道制定单独的RSS文件链接，并将其发布到网站上提供给用户访问。网站允许用户根据需要自选定制并保存RSS频道信息。对于可提供RSS服务的网站提供的信息，用户只需通过RSS订阅系统即可直接获取。而对于不可提供RSS服务的站点及数据库中提供的信息，则需要通过对网页及数据库中的数据进行抽取RSS Feed的操作。通过抽取RSS Feed，为用户提供较为详细的内容信息，以便用户获取自己需要的信息。其技术模型如图20所示。

以上仅为本发明优选实施例而已，并不用于限制本发明，对于本领域技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

1.一种基于大数据的钻井提速影响因素分析模型，其特征在于，包括：

智能推送服务，基于用户的注册信息和主动地收集用户日常行为模式，智能地归纳出用户的专业和兴趣点，建立起用户行为轮廓，推断出用户需求，并根据推断出的用户需求将最新数据与信息分门别类地传送给相应的用户；

1.1基于Kettle构建ETL过程模型

1.1.1基于Kettle的ETL

Kettle的ETL活动中主要包含Spoon、Kitchen、Pan以及Carte四大组件；Spoon创建Job和Transformation的数据成环境，制定整个ETL解决方案；Kitchen调用作业流程；Pan调用转换流程；Carte实现ETL集群处理；制定的作业与转换流程以资源库和本地文件两种方式存储，通过加载作业与转换流程文件，可以方便地实现对作业、转换流程的优化与重新定制，提升ETL处理效率，改善数据质量；

ETL最后一个环节是将转换数据加载至目标数据仓库中；数据仓库是一个面向主题的、集成的、非易失的且随时间变化的数据集合；依据企业基础数据，分析数据主题，采用星型或者雪花型多维模式进行数据存储，实际处理过程中KETTLE将星型、雪花型结构映射为事实表和维度表，如此利于构建数据立方体，实现对数据的多维查询；

1.2石油钻井企业数据仓库模型

1.2.1数据仓库模型

在深入分析了各主题的基础上，结合传统的数据仓库技术，设计了一个基于主题的数据仓库模型，该模型分为四个层次：系统数据资源层、数据访问层、ETL数据集成层、决策支持层；

系统数据资源层为数据仓库系统基础，通常包含企业内外部信息；所完成的石油钻井项目，其各业务系统分散在无线传输库和RTX数据库中；

数据访问层，Kettle对数据库的连接基于JDBC数据连接规范；

ETL数据集成层，该层的主要功能是在主题指导下完成数据源到数据仓库和数据集市的ETL处理；该层是整个数据仓库模型的核心层，是将企业基础数据转换成分析型数据的关键；

1.3大数据项目数据集成的实现

本实施例基于KETTLE为石油钻井项目制定了数据集成解决方案，将其历史数据业务系统所生成的历史数据库数据转换为可供决策的分析性数据；根据企业实际需求规划，对钻井基本数据表、钻头数据表、钻具组合表进行数据的抽取，采用事实表-维度表的多维模型构建了星型数据仓库，实现对各主题域维度数据和事实数据的装换与加载，最终形成面向石油钻井企业的数据仓库；

1.3.1 ETL总作业流程

根据数据仓库各主题，设计与主题相对应的作业流程，该作业流程制定了整个ETL执行的顺序，宏观上协调了每一步的执行任务，是成功构建石油钻井项目数据仓库的关键；

ETL总作业流程图整合各业务系统数据库资源，进行了异构数据源的数据库参数设置，保证了ETL在执行过程中能够访问到各系统数据库资源；Kettle将结构化、半结构数据转化为Kettle可识别的数据流；在ETL总作业流程中，每个主题数据的ETL处理均由一个作业组成，每个子作业再经由各自主题ETL的详细转换流程，实现对数据清洗、转换、源表与目标表的属性映射；

1.3.1.1作业实现

Kettle通过作业来控制整个处理流程；它包含一个或多个作业项；这些作业项以某种逻辑顺序执行；根据钻井趟数数据集成的实际需求，将钻井趟数的处理流程分为两个作业，分别是：

单井起钻趟数信息数据集成：根据石油钻井的业务需求，起钻趟数主题可以按照单井、区块条件进行选择；而井段的判断依据是根据井段划分，于定向井而言，划分为一开、二开钻；对于水平井而言，划分为一开、直井段、斜井段、水平段；对于N趟钻而言，是按照钻头使用个数进行判断；因此，在单井起钻趟数数据集成的主题下，涉及多个库的多张表的关联；而在此工作流中，通过触发的方式将井段、钻井趟数信息进行获取；

单井统计信息数据集成：在单井起钻趟数相应需求字段生成以后，根据石油钻井大数据业务需求，需要显示该区块单井使用的钻头信息、钻具组合信息、泥浆性能信息、钻井参数信息；而对于这些展示的数据信息而言，并非源数据中本身存在的，为了便于后期的决策分析，需要对这些信息进行聚合统计；如统计某型号钻头数量最多的信息、某钻具组合使用频次多的单井详细井史信息以及参数数据中的泥浆性能、平均位移、平均钻井周期、机械钻速最高条件下是那种型号的钻头信息，这些信息需要ETL执行处理；

1.3.1.2转换实现

转换是由步骤组成的流程；它按照预先制定的工作步骤对数据流进行特定转换操作，实现数据的抽取、转换和加载；使用Kettle实现单井钻井趟数信息的ETL有两个关键的转换，分别是单井起钻趟数转换和单井统计转换；

在表输入中，筛选特定井型，剔除未完钻单井，映射完钻日期、区块、井号、井型、井别、队号字段，从而确定转换规则；

石油钻井ETL转换过程中日期处理，在该石油钻井项目中，针对效率分析，涉及到钻井周期、建井周期、开钻日期、完钻日期日期格式；需要对日期格式统一处理，便于数据集成的展开；

钻井大数据信息化平台项目中涉及的数据源非常广泛，由于业务的多样化和分离化，在整个项目牵涉到了许多现有存在的异构系统，其数据的组织和存储结构也不尽相同，进而导致了信息多元化，多样化，数据的一致性、准确性和完备性都难以保证，从而难以保证大数据项目中所包含的数据质量；低质量的数据给钻井业务带来了很大的不便，甚至会造成很大的损失；针对当前这样的问题，本实施例通过把各种异构源的数据有效的集成到一起，实现统一的管理；在建立数据仓库和数据集成的过程中，数据清洗是一项不可或缺的任务，它可以保证提供准确、唯一的企业数据视图，为用户提供高质量的数据服务，也为将来的数据挖掘和知识发现提供了坚实的基础；

2.1数据质量的问题分类

数据清洗可被描述为从大量原始数据中使用一系列的逻辑检测出脏数据并修复或丢弃之；在项目施行过程中，主要出现以下四种数据质量问题：

1、属性层面；这类错误仅局限于单个属性的值；

2、记录层面；这类错误表现在一条记录不同属性值之间出现的不一致性；

3、记录类型；表现为同一数据源中不同的记录类型之间的不一致性；

4、数据源层面；表现为数据源中的某些属性值或记录与其他数据源中的相关值的不一致性；

针对以往的数据清洗的灵活性差的硬编码和和低效的人工判断的缺陷，和在项目实际中发现的数据质量问题，我们建立了基于规则引擎的数据清洗架构，利用规则来描述数据清洗逻辑，使用规则引擎来执行清洗逻辑；

2.2基于规则的数据清洗技术

数据清洗规则由两部分组成：用于检测脏数据的逻辑规则和对脏数据采取的动作的描述；可以用大量的商业规则和约束来描述数据清洗的全过程，即审计、筛选和修复；基于规则的数据清洗技术能够处理各种数据质量问题；

2.2.1基于规则的数据清洗技术实现

数据清洗规则最终表现为复杂的逻辑；如何提炼、表达、组织和高效地判断这些逻辑是基于规则的数据清洗技术的关键所在；需注意，数据质量问题的定义和业务领域是强相关的；对某个业务部门是干净的数据，对同一企业的另一业务部门却可能是脏的；而且，业务是随时间变化的，因此数据质量问题的定义也随时间变化；数据清洗规则会经常发生变化；这要求基于规则的数据清洗技术的实现必须能灵活地定义规则，必须能灵活地在线调整规则；本实施例使用规则引擎技术解决这一问题；规则引擎将提交给它的数据对象与加载在引擎中的业务规则进行测试和比对，激活符合当前数据状态的业务规则并根据其声明的执行逻辑，触发相应操作；可见，规则引擎技术将硬编码的复杂的if...else...结构转化为了软编码的规则集，从而能做到灵活地定义规则和在线调整规则；

2.2.2基于规则引擎的数据清洗框架的设计

基于规则引擎的数据清洗框架由5个部分组成

(1)规则定义界面：以可视化方式为数据源表定义各种数据清洗规则；

(2)规则库：集中保存规则定义界面所定义的规则，以便规则管理和重用；

(3)规则模板库：规则定义界面可从规则模板库中提取规则模板，用户进行修改后形成规则；用户可以手工定义新的规则模板或将规则定义界面中定义的规则保存为规则模板；

(4)规则引擎：是规则的运行环境，负责编译和执行规则；

(5)数据清洗插件类：定义了一套机制，使得外部软件(如ETL软件或数据质量工具)能够集成数据清洗功能；即，它负责接收原始数据并为之调用规则引擎来执行规则，并将处理结果返回给调用者；

在基于规则引擎的数据清洗框架中，规则就是持久化了的领域知识；数据清洗的覆盖率和正确率仅和规则定义的覆盖度和正确率相关；由于使用了规则定义界面来定义数据清洗过程，因此用户能够快速实施数据清洗系统；规则被保存在集中的规则库中，相同的规则有可能被用于多个数据源，从而加强了规则的可重用性；

这个基于规则引擎的数据清洗框架采用Java技术开发规则定义界面，使用XML文件构建规则库和规则模板库；使用Drools规则引擎作为规则的运行环境，使用Java类来实现数据清洗插件类；

Drools实现了一种新颖的面向对象的Rete算法(Rete-OO)，允许用更自然的方式描述领域规则；Drools能够在规则描述文件中直接嵌入Java多种编程语言来进行逻辑规则的描述；然后，Drools将从规则描述文件中解析出来的编程语言代码交给特定语言的脚本执行模块来执行；该实现基于Java或XML技术，具有平台无关性；2.3数据清洗引擎

2.3.1 Rete算法

网络共有5类节点：Root节点、Type节点、α节点、β节点、Terminal节点，根节点(RootNode)代表整个Rete网络的入口，它可以让所有的事实通过，并传递给ObjectType节点；作为根节点的后继，ObjectType节点用于选择事实的类型，将符合本节点类型的事实向后继的α节点传播；α节点主要进行同对象类型内属性的约束或常量测试；β节点主要根据不同对象之间的约束β节点又分为Join节点、Not节点；Join节点包括两种输入，左部输入事实列表，称为元组，右部输入一个事实对象，对象与元组在Join节点按照类型间约束进行Join操作，将符合的事实加入元组中继续传入下一个β节点；Terminal节点对应的规则被激活；

2.3.2算法步骤

Rete算法的步骤主要分为两个部分：规则网络的建立和事实的匹配；其中，网络建立过程算法如下：

(1)创建根；

(2)取出一个规则r；

c.检查模式p的域，若为多类型约束，则创建相应β节点，其左输入为前一β节点，右输入为当前链的α内存；

d.重复b-c，直到模式p的所有约束处理完毕；

f.将动作(Then部分)封装成叶节点作为输出节点；

3)重复(2)直到所有规则处理完毕；

运行时的匹配过程如下：

(1)从工作内存中取一WME放入根节点进行匹配；

(2)遍历各α节点，如果α节点约束条件与该WME一致，则将该WME存在该α节点匹配内存中，并向其后继节点传播；

(3)对α节点的后继结点继续(2)的过程，直到α内存所有通过匹配的事实保存在α内存中；

(4)对各β节点进行匹配，如果单个事实进入β节点左部，则转换成一个元素的元组存在节点左侧内存中；如果是一个元组进入左部，则将其存在左内存中；若一个事实进入右侧，则将其与左内存中的元组按照节点约束进行匹配，符合条件则将该事实对象与左部元组合并，并传递到下一节点；

(5)重复(4)直到所有β处理完毕，元组对象进入到Terminal节点；对应的规则被触活，将规则后件加入议程；

(6)对Agendar里的规则进行冲突消解，选择合适的规则执行；

2.3.3 Drools引擎

Drools把Rete算法封装成Rete-OO，放在一个核心模块中，然后又添加了一系列外围模块扩展它的功能；除了Drools-core模块实现了Rete核心算法外，Drools-smf(语义模块框架)和Drools-io模块用于从当前文件系统中创建规则集；Drools-base模块是一个基于XML语言的基础语义理解模块；在XML语言的基础上支持python、groovy、java三种语言进行规则的定义；此外，Drools支持jsr-94规范，提供了相应的drools-jsr94兼容模块；可选择以jsr94方式开发，便于以后的移植，也可选择基于drools-base的开发方式，更为简便高效；

Drools项目的规则文件为自定义格式；由一个XML语言定义的基本的语义模块加上java语义模块；开发者也可以根据需要定制自己专用的语义模块；每一个规则文件包括一个唯一的规则集，规则集包括一个或多个规则；每个规则包括一个或多个参数；这些参数用于在规则的条件中进行判断和执行相应的操作，参数对应的是一个java类，drools会在创建工作内存的时候把它自动实例化；每个规则包括一个或多个条件以及一个最后的操作；

2.4数据清洗算法

2.4.1基本近邻排序算法SNM

基本近邻排序算法，它的基本步骤如下:

1)创建排序关键字；抽取记录属性的一个子集序列或属性值的子串，根据这些子集序列或属性值的子串，计算数据集中每一条记录键值；

2)排序；根据排序关键字对整个数据集进行排序，尽量把潜在的、可能的重复记录调整到邻近的区域内，便于进行记录匹配；

3)合并；在排序后的数据集上滑动一个固定大小的窗口，窗.口可容纳w条记录，则每条新进入窗口的记录都要与先前进入窗口的w一1条记录进行比较，如检测到重复记录，则进行合并，否则最先进入窗口内的记录滑出窗口，最后一条记录的下一条记录移入窗口，再进行下一轮比较，直到数据集的最后记录移入窗口后比较完毕；

SNM算法采用滑动窗口的方法，每趟只比较窗口中的w条记录，比较次数小于w*N次，并且，w比N小的多，极大地提高了比较速度；

2.4.2多越近邻排序算法MPN

独立地执行多趟SNM算法，每趟创建不同的排序关键字和使用相对较小的滑动窗口；然后采用基于规则的知识库来生成一个价原理，作为合并记录的判别标准，将每趟扫描识别出的重复记录合并为一组，在合并时假定记录的重复是具有传递性，即计算其传递闭)，所谓传递闭包，是指若记录R1与R2:互为重复记录，R2与R3互为重复记录，则Rl与R3互为重复记录；通过计算每趟扫描识别出的重复记录的传递闭包，可以得到较完全的重复记录集合能部分解决重复记录漏查问题；

2.4.3优先权队列算法

优先权队列算法，优先队列策略借用邻近排序算法的思想，具体策略:先抽取一个或多个字段构成关键字，根据关键字，对数据集进行排序，然后在一个长度固定的子集队列中检测匹配记录，采用类似LRu算法(最近最少使用算法)来控制队列的长度；通过匹配操作找出需要合井的子集，计算其传递闭包，然后合并它们，最后得到若干个近似重复记录集；基于这样一个观察:一个简单的关键字在排序后不能完全将重复记录聚集在一起，因此一趟优先队列算法可能遗漏一些重复记录，为避免这种情况，提出多趟优先队列算法厂-每次采用不同的关键字进行排序；

2.5数据清洗策略

脏数据最多的表现形式就是记录的属性值异常；其清洗策略主要有:

(l)空值的清洗策略，空值问题是数据清洗经常遇到的问题；一般的空值问题可分为两种:①是缺失值；②是空值；缺失值是指字段的值实际存在，但它的值是空的，如成年人都有居民身份证，如果某个成年人身份证号的值为空，就属于缺失值；空值指字段的值实际上并不存在而空值；空值处理策略是把字段值直接替换成空；缺失值处理策略有:①某些缺失值可以从本数据源或其他数据源推导出来；可用平均值、中间值、最大值、最小值或更为复杂的概率统计函数值代替缺失的值，但准确性比较低；②人工输入一个可接受的值；

(2)错误值清洗策略有:①用统计分析的方法修正错误值或异常值；②使用简单规则库修正错误值或异常值；③使用不同属性间的约束修正错误值或异常值；④使用外部数据修正错误值或异常值；

3)不一致数据的清洗策略，不一致数据主要是由于系统和应用造成的，比如不同的数据类型、格式、粒度和编码方式，另外由于错误的输入、硬件或软件故障，不及时更新；解决的策略，主要是在分析不一致性数据产生原因的基础上，应用多种变换函数、格式函数、汇总分解函数和标准库函数去实现清洗；第二类情况，消除数据集中的近似重复记录策略有：(l)保留字段项比较全的记录；(2)保留无错误的数据记录；(3)保留最新记录；

三、基于SOA的业务智能云服务平台

3.1基于SOA的云服务架构

SOA是一个组件模型，它将应用程序的不同功能单元通过这些服务之间定义良好的接口和契约联系起来；接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言；这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互；SOA具有高内聚、低耦合、粗粒度、重用性、自治性、互操作性特性，服务与服务通过接口实现服务操作，准确地说更是一种架构理念，强调了不同层次的服务理念，满足网络环境下业务集成的需要，通过连接能完成特定任务、独立功能的实体来实现的一种软件系统架构；服务重用性、自治性、松耦合、抽象性、规范化的契约是SOA架构的基本原则；

SOA包括服务提供者、服务用户、服务中心三个实体；服务用户是发起服务请求的实体.向服务中心查找需要的服务，然后绑定相应服务提供者获得需要的服务功能；服务中心为服务提供者提供注册服务，为服务用户提供服务查询，并将选择的服务提供者的服务授权给服务用户；服务提供者将服务注册到服务中心，并根据服务用户请求执行相应的服务功能；云计算在架构上正好是SOA的一种扩展和深入应用，基于SOA作为比较完美的架构，可以满足在分布式网络环境下业务集成的需要，通过连接能完成特定任务、独立功能的实体构建云服务平台的架构；用户通过浏览器访问云，云服务平台中心相当于云服务代理和控制中心，根据用户请求选择相应的云服务，通过若干用户云服务接口调用相应的云服务完成操作，并返回云服务结果给云端用户，云服务提供者是云服务后台分布式计算机服务资源，提供各种云服务；

3.2基于SOA的云体系框架

接下来.在基本的SOA云服务架构基础上，进行云体系框架的设计；针对SOA的服务中心、服务提供者和服务用户三类实体设计为云体系框架中的服务消费者、服务提供者、服务控制中心；其中：

(1)服务消费者指云端用户；主要在云服务平台查找合适的云服务，发起云服务请求，它是网络上的终端节点，它与服务提供者的云服务接口进行了绑定，并且通过使用相应的服务实现业务操作；

(2)服务控制中心是云服务平台中心，将云服务提供者发布的各种服务信息存储起来，它可以被用来查找各种服务所处的位置，云端用户通过云服务平台中心查询它所需要的服务及通过服务接口使用所要的服务，云服务平台中心也是网络上的节点；

(3)服务提供者是网络上分布式节点资源集合，为网上若干的云端用户提供网络服务；服务提供者节点提供了对业务系统、子系统和组件的访问服务；它具有强大的计算能力，云结构下的服务提供者共分为四层：云服务接口层、云服务调度管理层、云计算服务层、云物理服务层；

①云服务接口层为云端用户提供统一规范的绑定接口，是调用云服务的专用通道；终端用户通过专用入口通道进入云计算服务中心，订制和消费其所需的服务；

④云物理服务层是云服务的基础层，它包括了云团内的服务器资源，为云计算服务层提供存储和CPU硬件资源服务，具有大型计算中心功能和无限存储功能，为云团的服务功能拓展提供了资源智能分配服务；

根据上文提出的基于SOA的云计算框架的基础结构，这里给出一种切实可行的基于SOA的云计算框架模型的实现过程；

消费者首先向服务代理提交服务请求，服务代理在自己的服务范围内查找是否存在该项服务，如果不存在，直接拒绝此项服务申请，如果存在，回复消息通知消费者1具体的访问位置；消费者1访问该位置上的服务接口程序，并通过接口调用云服务管理层；云服务管理层接到调用后，查找云资源服务器中的虚拟机，根据消费者1提出的消费资源请求，分配具体的服务器资源给消费者，从而消费者1可以使用该云中的服务器资源；消费者2、消费者3……消费者n的服务过程类似；

3.3基于SOA的数据联邦式信息检索统计平台的实现

通过构建基于SOA的联邦式信息检索平台，在不改变各个部门原有业务逻辑的前提下，对各个分布式的异构数据中心构建检索服务，以实现企业内单个职能部门一站式获取所有部门所提供的共享信息；

3.3.1联邦式信息检索平台模块

数据收集模块

一般通用的搜索引擎都会有一个数据收集器，即网络爬虫，但本平台中数据都是来源于各分布式数据信息系统的信息录入和采集，从整个企业来看本平台一个封闭的系统，因此不存在外网数据的抓取；录入的数据暂时保存在临时的共享数据管理中心，只有管理员审核通过的记录才能成为共享数据；

索引构建模块

常规的检索可以使用数据库的结构化查询语言SQL完成，主要是“Select”操作，SQL的通配符提供了多样化的查询功能，数据库索引技术也在某种程度上提高了检索速度；但是SQL查询的缺点在于其不仅不能计算查询关键词与检索文档之间相关度大小，其最大的缺陷就是在面对海量数据时检索速度慢；倒排索引是目前搜索引擎使用最广泛的检索技术，它不同于SQL“正向索引”的检索模式，正向索引一般将检索文档作为索引，选中某条文档，直接判断此文档是否包含检索关键词；倒排索引是一种“反向索引”的检索模式，以检索关键词分词后的词片为检索入口，直接得到所有包含检索关键词词片的文档集合，甚至可以得到词片在文档中确切位置；

检索服务发布模块

本平台使用的是Web Service技术实现SOA的概念，所以需要把单个数据系统的信息检索功能进行服务的封装，并发布在服务管理中心；这里服务发布采用的是Apache组织关于实现SOA的开源框架Tuscany，Tuscany采用的是服务组件框架，其核心组件提供了一整套基于Java语言的API，通过其提供的API便可以把本地的功能函数发布成能异地调用的服务；

3.3.2联邦式信息检索平台总体架构

本平台的总体架构分为七个层次，从下往上依次为网络基础设施层、云平台虚拟层、数据访问层、对外服务层、安全链路层、业务功能层、系统表示层；

系统表示层为用户提供统一的检索入口，为此需要设计统一标准的信息检索前端界面和统一格式的检索结果显示页面；平台为用户提供的业务功能主要有信息上传、联邦式信息检索、资源获取、资源下载；对服务层的访问，使用的是安全链路层的简单对象访问协议，分布式的检索Web服务通过数据访问层完成对本地索引文档的检索，云平台虚拟层提供了整个平台开发所需要的虚拟机，网络基础设施位于最底层，为平台的构建提供基础硬件设施的支撑；

3.4联邦式信息检索云平台的性能配置优化

本平台异构的数据中心由单个的实体服务器实现，为了保证数据安全、服务的质量、企业软硬件资源的利用率因素，本实施例利用了钻井公司现有的VMware企业级私有云平台，私有云平台各种优点更好的满足了本平台企业级的信息共享，可以对数据、安全性、服务质量进行更好的控制；

由于云平台一般可以对服务器及服务器上虚拟机资源的使用情况进行实时监控，本平台在VMware云环境加入了负载均衡机制，以提高系统在高负载环境下的稳定性；基于此种构思，本平台实现了主服务器计算与数据存储的分离，使用了两个虚拟计算节点和一个虚拟存储节点；其中两个虚拟计算节点类似于Master与Slave的关系，用户对联邦式检索系统的访问默认分流到计算节点一，计算节点一会依据特定的分流策略判断是否将用户的访问进行分流或直接在本机响应处理，所以说计算节点二是一个辅助作用；

四、智能推送服务大数据信息平台的智能推送技术

Agent模型

基于Agent的信息推送系统的体系结构模型在逻辑上可分为三层：信息表示层主要是为用户与个性化信息推送系统的交互提供一个接口，即用户通过该接口进行注册、登陆、查看系统推送给用户的信息资源以及反馈相关信息；信息选择层主要是对信息搜索层的搜索结果进行再加工和过滤，通过从信息表示层反馈过来的信息不断调整用户兴趣模型，实现智能化的推送服务；信息搜索层是在数据源中查找用户感兴趣的相关信息，得到一系列数据集；每一层都有相应的Agent为用户服务；

Agent工作流程

当用户使用系统时，会产生对应于这个用户的五个Agent:用户Agent、过滤Agent、学习Agent、信息检索Agent和监测Agent；

用户Agent根据用户的基本信息和行为，对用户进行建模；过滤Agent根据用户的兴趣以及个性化信息采用向量空间法进行信息过滤，从而使系统具有一定的针对性与个性化；学习Agent通过基于观察记忆的学习机制、基于用户反馈的学习机制和基于ID3归纳的学习机制来自主学习用户的兴趣，使系统具有一定的智能性；信息检索Agent利用现有的搜索引擎技术，采用有限深度、广度优先的搜索算法在信息源中查找用户感兴趣的相关信息，从而使系统具有一定的完备性；监测Agent通过个性化的无监督机制，保证信息的可靠性与可用性。

2.如权利要求1所述的基于大数据的钻井提速影响因素分析模型，其特征在于，所述基于主题的数据仓库系统包括系统数据资源层、数据访问层、ETL数据集成层以及决策支持层；其中，

系统数据资源层是数据仓库系统基础，其通常包含企业内外部信息；完成的石油钻井项目，各业务系统分散在无线传输库和RTX数据库源系统中；

数据访问层，数据抽取成功的关键是能够访问各异构数据源，Kettle对数据库的连接基于JDBC数据连接规范；

ETL数据集成层，在主题的指导下完成数据源到数据仓库和数据集市的ETL处理；所述ETL数据集成层是整个数据仓库系统的核心层，是将企业基础数据转换成分析型数据的关键。

3.如权利要求1所述的基于大数据的钻井提速影响因素分析模型，其特征在于，所述基于规则引擎的数据清洗架构包括规则定义界面、规则库、规则模板库、规则引擎以及数据清洗插件类；其中，

所述规则定义界面以可视化方式为数据源表定义各种数据清洗规则；其可从规则模板库中提取规则模板，用户进行修改后形成规则；用户也可手工定义新的规则模板或将规则定义界面中定义的规则保存为规则模板；

所述规则库集中保存规则定义界面所定义的规则，以便规则管理和重用；

所述规则引擎是规则的运行环境，负责编译和执行规则；

所述数据清洗插件类定义了一套机制，使得外部软件能够集成数据清洗功能；即，它负责接收原始数据并为之调用规则引擎来执行规则，并将处理结果返回给调用者。

4.如权利要求3所述的基于大数据的钻井提速影响因素分析模型，其特征在于，所述基于规则引擎的数据清洗架构采用Java开发规则定义界面，使用XML文件构建规则库和规则模板库，使用Drools规则引擎作为规则的运行环境，使用Java类来实现数据清洗插件类。

5.如权利要求1所述的基于大数据的钻井提速影响因素分析模型，其特征在于，所述基于SOA的业务智能云服务平台包括数据收集模块、索引构建模块以及检索服务发布模块；其中，

所述数据收集模块，将录入的数据暂时保存在临时的共享数据管理中心，只有管理员审核通过的记录才能成为共享数据；

所述索引构建模块，对于常规检索，使用数据库的结构化查询语言SQL完成，对于其他检索，使用倒排索引完成；

所述检索服务发布模块，把单个数据系统的信息检索功能进行服务的封装，并发布在服务管理中心。

6.如权利要求5所述的基于大数据的钻井提速影响因素分析模型，其特征在于，所述检索服务发布模块发布服务采用的是Apache组织关于实现SOA的开源框架Tuscany，Tuscany采用的是服务组件框架，其核心组件提供了一整套基于Java语言的API，通过其提供的API便可以把本地的功能函数发布成能异地调用的服务。

7.如权利要求6所述的基于大数据的钻井提速影响因素分析模型，其特征在于，所述基于SOA的业务智能云服务平台分为七个层次，从下往上依次为网络基础设施层、云平台虚拟层、数据访问层、对外服务层、安全链路层、业务功能层、系统表示层；其中，

8.如权利要求7所述的基于大数据的钻井提速影响因素分析模型，其特征在于，所述基于SOA的业务智能云服务平台为用户提供的业务功能包括信息上传、联邦式信息检索、资源获取以及资源下载。

9.如权利要求7所述的基于大数据的钻井提速影响因素分析模型，其特征在于，所述基于SOA的业务智能云服务平台的数据中心由单个的实体服务器实现，为了保证数据安全、服务的质量、企业软硬件资源的利用率，其利用了VMware企业级私有云平台；

并且，平台在VMware云环境中加入了负载均衡机制，以提高系统在高负载环境下的稳定性；基于此种构思，所述基于SOA的业务智能云服务平台实现了主服务器计算与数据存储的分离，使用了两个虚拟计算节点和一个虚拟存储节点，其中两个虚拟计算节点类似于Master与Slave的关系，用户对平台的访问默认分流到Master计算节点，Master计算节点会依据特定的分流策略判断是否将用户的访问分流到Slave计算节点或直接在本机响应处理。

10.如权利要求9所述的基于大数据的钻井提速影响因素分析模型，其特征在于，所述负载均衡机制采用的分流策略是负载监听，其采用内存的使用率作为判断Master计算节点负载大小的指标，当内存使用率超过设定的阈值时就将用户请求分流到Slave计算节点；其中，内存使用率同时考虑了计算节点内存使用率和其所在服务器的内存使用率，只要其中的任意一项超过了设定的阀值，便可以将新的用户访问请求分流到Slave计算节点。