周维琴，赵文博，李 峰，李录兵，宁 莹

（中国石油长庆油田分公司第三采油厂，宁夏银川 750006）

1 信息系统应用现状

截至2017年，长庆油田采油三厂与生产管理有关的系统共有20套，其中统建8套，自建12套，经营管理类共7套系统，统建6套，自建1套，这些系统都为独立运行的系统，应用程序之间不能共享数据，相互之间都没有提供一套标准及统一的接口获取该系统数据的方法。目前该厂使用的系统除了SCADA系统使用实时数据库外，其余系统都是基于关系数据库开发的，主要有mysql、sqlserver、oracle。关系型数据库要建立索引，支持对数据的筛选和排序等操作，主要是发现和整理数据之间的关系，通过对数据关系的分析得到一个统计意义的结论。那么关系型数据库的特点决定了它不可能在读写性能上要求很高。

油田企业随着数字化的全覆盖，信息化水平的提升，生产业务系统越来越多，同时随着SCADA系统的应用，生产现场近90%的生产过程数据实现了在线监控以及历史存储，与此同时也导致数据的几何倍数的增长，数据在急剧膨胀的过程中，数据库的优缺点就会体现出来。

2 系统架构与应用问题分析

采油三厂目前数字化油井5900口，水井2230口，站点330座，油井数据采集频率是10分钟，其他数据都是1秒，一天共采集大概316800000条记录。生产现场数据采集存储都是基于SCADA系统实时数据库技术，整个系统架构主要包括采集层、存储层、应用层（见图1）。

目前一天3.1亿条数据，一个月可产生200 G的数据量，一年可产生2 T的数据量，如果要存储历史数据就需要提供存储空间更大的设备。随着历史数据的增多、数字化深度应用需求的增加，需面对三大问题：（1）海量数据高效；（2）海量数据快速检索；（3）海量数据挖掘应用。

图1 SCADA系统架构

2.1 油井采集数据处理流程及存在问题分析

油井采集数据流转至最终用户可视经过7个环节（见图2），每个环节的不稳定都会影响整体系统功能，随着数据采集存储量的增加，数据存储环节的问题逐渐凸显，出现数据库卡死，软件卡死，数据实时分析处理速度变慢等情况，特别是ECHOMS_CQ数据库，当数据量增多的时候，容易引起KH2SQL软件卡死，功图分析客户端程序分析数据速度慢，卡死等情况。

本架构使用数据库管理系统是关系数据库MS Sqlserver2005，针对油井数据转存库ECHOMS_CQ进行分析，本数据库中只有一张表2071表，主要用于存储功图数据，电参数据，表功能只用于读写而非计算统计等，数据表现形式跟文档相似，而且该库不存在表间任何关系，同时关系数据库随着数据量的增加，频繁写入数据就会导致数据的逻辑存储分页越多，则会大大提升数据库IO消耗，造成性能下降。因此该数据不适合用关系数据库管理，而适合用文档数据库管理——MongoDB数据库。MongoDB是一个基于分布式文件存储的数据库。主要解决的是海量数据的访问效率问题，为WEB应用提供可扩展的高性能数据存储解决方案。当数据量达到50 GB以上的时候，MongoDB的数据库访问速度是MySQL的10倍以上，每秒可以处理0.5万～1.5万次读写请求，并且MongoDB非常适合实时的插入，更新与查询，并具备实时数据存储所需的复制及高度伸缩性，可以支持海量的数据存储。

2.2 站点采集数据处理流程及存在问题分析

SCADA数据采集流程主要是从前端现场设备采集数据由SCADA IO Server进行采集，然后实时转存到SCADA工业库中，然后通过SCADA脚本程序生成报警记录数据，报表计算数据，系统操作日志数据存入关系数据库MySQL数据库中，整个流程（见图3）。

图2 油井数据处理流程

图3 站点采集数据处理流程

当站点报警数据存储比较多，报表处理功能比较复杂时SCADA站控平台反应就会变慢，目前为了确保SCADA站控平台运行的高效稳定，站控管理人员定期从MySQL数据库中删除报警数据并重新建立索引，报表只是部分数据的简单统计显示，整个数据处理过程比较简单，对于应用需求的满足还有一定的差距，特别是报警准确率及报表功能还不能达标，主要由于整个SCADA架构对于实时数据计算分析处理功能比较薄弱。

随着数字化技术的深度应用，对于实时、历史数据的分析挖掘必然成为趋势，包括管线运行情况的监控、预警分析，油水井生产运行情况分析，上下游相关数据级联分析调控站点平稳运行，生产运行趋势分析、异常分析，报表统计分析等，依据目前的系统架构满足不了这些应用需求，借助大数据技术架构平台可以很好的解决上述问题，实现采集数据的大容量存储和实时分析处理，针对实时数据流的分析可以采用Storm计算技术完成所需功能。使用Storm技术实现实时大数据分析，Storm是个实时的、分布式以及具备高容错的计算系统。同Hadoop一样Storm也可以处理大批量的数据，然而Storm在保证高可靠性的前提下还可以让处理进行的更加实时。Storm业务主线是信息流处理，连续计算，分布式程序远程调用。大数据处理架构（见图4）。数据源除了实时数据库外，引入消息队列，可以把数据临时存储在消息队列中，后端处理速度就不会影响前端业务数据的产生。

3 基于大数据技术系统架构探讨

大数据指的是海量无法通过传统方式管理的数据。互联网范围的数据正在推动能够处理这类新数据的新架构和应用程序的创建。这些架构高度可扩展，且能够跨无限多的服务器并行、高效地处理数据。目前应用比较广泛的大数据架构平台有三个：Hadoop架构平台，Spark架构平台，Storm架构平台。Hadoop是一个开源+分布式存储+分布式计算平台，实现了MapReduce的思想，将数据切片计算来处理大量的离线数据，处理的数据必须是已经存放在HDFS上或者类似Hbase的数据库中，适用于海量数据的离线分析处理。Spark是在Hadoop的基础上进行了一些架构的改良，Hadoop使用硬盘来存储数据，Spark使用内存来存储数据，可以提供超过Hadoop100倍的运算速度，由于内存断电后会丢失数据，因此不能处理需要长期保存的数据。Storm在Hadoop的基础上提供了实时运算的特性，可以实时的处理大数据流，它不进行数据的收集和存储工作，直接通过网络实时的接受数据并且实时的处理数据，然后直接通过网络实时的传回结果。

3.1 大数据架构平台技术分析

大数据架构主要是针对一个集群而言，通过集群才能体现出大数据架构应用的优势，一个大数据架构平台是多项新技术应用的组合，技术比较全面的架构平台（见图5）。底层主要是HDFS（分布式文件系统）的应用，统一管理分布在集群上的文件系统，提供了一个高度容错性和高吞吐量的海量数据存储解决方案。YARN（Yet Another Resource Negotiator另一种资源协调者，也就是群集资源管理系统），可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。

图4 大数据处理架构

MapReduce分布式离线计算框架：MapReduce采用“分而治之”的思想，把对大规模数据集的操作，分发给一个主节点管理下的各个分节点共同完成，然后通过整合各个节点的中间结果，得到最终结果[1]。Tez DAG计算框架：是基于Hadoop Yarn之上的DAG（有向无环图，Directed Acyclic Graph）计算框架，它把MapReduce过程拆分成若干个子过程，同时可以把多个Map-Reduce任务组合成一个较大的DAG任务，减少了MapReduce之间的文件存储，同时合理组合其子过程，也可以减少任务的运行时间[2]。Storm（流式计算框架）：是一个免费开源、分布式、高容错的实时计算系统。Storm令持续不断的流计算变得容易，弥补了Hadoop批处理所不能满足的实时要求。

Flume（日志收集工具）：是一个分布式、可靠和高可用的海量日志聚合的系统，支持在系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力[3]。Sqoop（数据库ETL工具）：Sqoop是一个用来将Hadoop和关系型数据库中的数据相互转移的工具，可以将一个关系型数据库（例如：MySQL、Oracle、Postgres等）中的数据导进到Hadoop的HDFS中，也可以将HDFS的数据导进到关系型数据库中[4]。

Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的SQL查询功能，可以将SQL语句转换为Map-Reduce任务进行运行。其优点是学习成本低，可以通过类SQL语句快速实现简单的MapReduce统计，不必开发专门的MapReduce应用，十分适合数据仓库的统计分析。Pig（数据流处理）：Hadoop上的数据流执行引擎，利用HDFS存储数据，利用MapReduce处理数据。Mahout（数据挖掘库）：是Apache基金支持的顶级项目，其目标在于建立可伸缩的用于机器学习算法库。Mahout支持数据挖掘的三个领域：（1）Recommendation mining，推荐引擎（协同过滤）；（2）Clustering，聚类；（3）Classification，分类。HBase（实时分布式数据库）：是建立在HDFS之上，提供高可靠性、高性能、列存储、可伸缩、实时读写的分布式列存储的开源数据库系统。HBase中每张表的记录数（行数）可多达几十亿条，甚至更多，每条记录可以拥有多达上百万的字段。而这样的存储能力却不需要特别的硬件，普通的服务器集群就可以胜任。

Zookeeper（分布式协作服务）：是一个用于分布式应用程序的分布式开源协调服务。它使用一组简单的操作原语，使得分布式应用可以实现更高层次的服务—如同步、配置维护、群组和命名管理等。它以易于编程为基本设计理念，并使用了一个类似于文件系统目录结构风格的数据模型[5]。

3.2 基于大数据应用的数据标准化建设

目前应用系统多而杂，每套系统数据相互独立，存在数据格式不统一，数据建设不规范、数据字典不标准等问题，严重阻碍了数据在各部门和各软件系统中的流动和共享，导致重复投资建设和信息资源浪费，降低采集、处理数据的成本、增加数据录入的工作量。以大数据应用为方向，建立数据仓库，最终实现信息的全面性和数据的规范性、数据字典的统一性、数据建设的标准化。在统一数据源的过程中，主要包括三个步骤，第一数据抽取，把不同数据源的数据统一采集到一个平台；第二数据转化，当要实现某类业务需求时，将从原数据源获取的数据按照业务需求，转换成目的数据源要求的形式；第三数据清洗，清洗不符合质量要求的数据，避免脏数据参与后续数据计算。

图5 大数据技术应用架构

4 认识与结论

大数据应用技术是未来企业竞争力的关键，油田企业随着数字化建设应用的深度扩展和发展战略的改变，大数据技术应用是发展必然趋势，但是目前面对大数据技术的应用还有诸多难题：首先目前使用的大多数系统为统推系统，底层数据库复杂度较高，而且不开放，在利用数据上存在数据提取难度高，整合困难等问题。其次目前应用的业务系统架构已经成型，如果要升级改变架构，或更换数据库等，需要对业务系统的逻辑层编写代码进行修改实现其功能，由于技术的更新，原参与开发技术人员的流动等问题造成升级的困难。再次大数据的架构反映出它的复杂性，大数据不是一个单独的产品或技术，而是众多技术的整合，传统企业几乎不可能独立进行大数据项目的建设，这不仅仅是资金投入的问题，主要是专业技术人员的缺失。作为厂级企业今后在数据、信息化系统建设方面必须要做到以下几点：架构设计不能以实现当前需求功能为目标，要充分考虑系统架构的后续可扩展性和可伸缩性，同时要考虑系统的处理能力在一定的时间内能够满足业务增长带来的处理能力增长的需要。数据库设计一定要遵从标准化和规范化设计原则，同时根据数据类型、事务类型、数据读写频率等选用最适合的数据库。大数据技术是数据应用的趋势，但目前情况距应用此技术仍有距离，应该选一专业化比较强的技术团队进行探讨，以需求结合实际应用为原则，探讨构建大数据分析平台的适宜性和必要性。