浅谈石油行业开发生产数据集成架构设计

2022-11-13李婧璇

中国管理信息化 2022年10期

李婧璇

（中国石油大港油田信息中心，天津 300280）

1 数据集成架构研究背景

随着专业研究不断深入和信息技术快速发展，石油领域的企业往往存在多个涉及开发生产的业务系统。这些系统建设于企业发展的不同阶段，针对不同的业务侧重点进行开发，其中沉淀的大量数据足够为主营业务的辅助决策提供可靠而丰富的数据支撑。然而，这些系统的底层数据存在如下问题。

（1）数据存储问题：业务系统大多相互独立，导致数据的存储位置分散，难以实现数据集成。

（2）数据质量问题：缺乏有效的数据管理规划和规范的标准流程，出现业务对象定义不一致、编码格式不同、数据冗余或数据缺失、管理责任主体不明确等情况。此外，跨系统数据口径不一致，使得数据关联性无法保障。

（3）数据应用问题：从用户提出需求一直到交付成果的过程中，存在数据源头取数难，跨部门数据共享性差、时效性低等缺点，需要花费大量时间来打破壁垒。

这些问题都导致数据资源无法及时满足业务人员的个性化分析需求，阻碍了企业智能化发展的进程。因此，如何对数据进行集中化、统一化、标准化的管理，并借助快速构建主题分析模型的手段，形成系统化的协同应用成为研究的方向。

2 生产数据集成架构开发

企业的发展除带来规模的扩张，还必然伴随着业务数据量的激增。为了管理好这些数据“金矿”，更好地针对用户需求提供服务，企业就需要设计一套完善的数据集成架构，作为指导数据集成管理的基础。数据集成架构的思路是：首先，根据实际业务场景需要进行数据集成，然后依托维度建模技术建立数据模型和数据仓库，最后通过统一的数据服务管理支撑数据应用。文章以石油行业的开发生产数据为例进行说明，架构由底至顶依次包括5 个层级。

2.1 数据源层

在数据源层，企业需要基于现有的开发生产应用系统开展数据体系建设，这是为业务提供全面、稳定、高效的数据支撑的基础。这个环节的主要工作是明确业务指标的数据来源，确保每个指标源头的唯一性，同时尽可能全面覆盖现有数据资源，将在用系统，尤其是高频使用的系统数据都纳入管理。

数据源层的构建主要考虑两方面的因素：一是数据标准的相对独立性，二是现有数据资源的集成性。目前，中石油的统建系统经过多年推广和应用，已经具备相当丰富的数据资源，尤其是数据量大、采集频度高的生产数据。因为基于这部分数据的日常应用较多，数据质量和及时性都有保障，所以几乎不需要开展数据质量检验和数据整理方面的工作，就可以对其直接使用。另外，还存在部分企业自建的数据，如生产运行数据库、工程基础数据库等，应用时也会涉及这些系统的部分数据，因此要纳入数据源层的组织中。

2.2 数据集成层

数据集成层主要承担数据ETL任务，负责从数据源层读取数据，将数据本地化，并定期将相关数据加载到数据仓库中。这个环节的主要工作是，基于用户制定的规则，实现各类数据资源的数据识别、数据抽取、数据清洗、映射转换、定时迁移及版本控制，从而达到整合来源于多个系统的业务数据的目的。其中涉及的几个方面如下所述。

①数据识别是从数据源中获取结构化、非结构化数据的组织方式的过程。②数据抽取是从数据源中抽取数据的过程，具体来说，就是全局搜索数据源，挑选其中符合标准的数据，并把这些数据传送到目的文件中。③数据清洗需要针对“脏数据”的产生原因和存在形式进行分析，利用现有技术手段和方法来清洗“脏数据”，从而将原本不符合要求的数据转化为满足数据质量或应用要求的数据，达到提升数据质量的目的。数据清洗是数据集成层必不可少的一个环节，能够防止无用数据占用存储空间，进而优化数据架构。数据清洗通常由格式内容清洗、逻辑错误清洗、非需求数据清洗及关联性验证几方面内容组成。④映射转换主要指从一个数据库将字段匹配到另一个数据库，或将数据从源格式转换为目标格式的过程。映射转换中的一个错误可能引发连锁反应，并且因重复的错误和不准确的分析造成企业损失。⑤定时迁移是指对系统之间批量移动数据的行为制订时间计划，按照周期自动执行数据迁移任务。⑥版本控制是指对ETL 过程中各种元数据、配置文件、说明文档等文件变更的管理。ETL 环节的每一部分都要确定一个主版本号，以便当某天执行的版本有严重错误时，可以快速恢复到之前的一个正确版本。

2.3 数据仓库层

数据仓库的定义是，在企业管理和决策中面向主题的、集成的、与时间相关的、不可修改的数据集合。这里的数据仓库层主要用于将开发生产指标按照不同业务主题进行划分，通过维度与事实建模，快速搭建主题分析模型，从而建立起若干数据集市。具体地说，这个过程主要分为以下5 个步骤。

①明确数据分析主题。主题能够体现出分析角度和统计数据之间的关系。它通常来源于相应的数据集市，如生产动态分析就是一个主题。②确定量度。根据分析主题选择的统计指标即量度，通常取数值型数据。③确定最小数据粒度。由于量度在不同维度下的聚合程度不同，因此需采用“最小粒度原则”，将量度的数据粒度设置到最小，以便向上聚合汇总。④确定维度。维度是指不同的分析角度。基于不同的维度，可以考察各量度的汇总情况，也可以基于维度的组合进行交叉分析。对开发生产数据分析而言，常见的维度包括时间维度、井维度、单元维度、单位维度等。⑤创建事实表。将原始表与维度表相关联，原始表包含量度数据，维度表包含维度代理键，根据主题建立事实表。事实表作为数据仓库的核心，需要精心维护。当事实表的记录数比较多时，可以为其设置复合主键和索引，以实现优化数据的完整性和基于数据仓库的查询性。

事实表与维度表共同存放于数据仓库中，通过分析维度和指标量度的多种组合，就能满足用户多层次、多角度的数据分析需求。

2.4 数据处理层

数据处理层主要承担数据计算任务，负责定时执行数据加工处理任务，完成相关数据处理和计算。如果前端提出连接数据仓库的要求，还可以在该层建立一些中间汇总表或物化视图，以便查询。经过数据处理层的数据既能面向用户、贴近业务，也能快速响应分析需求，直接用来进行服务开发。

2.5 数据应用层

基于数据处理层的输出结果，数据应用层可以形成数据服务和应用服务，从而实现数据的综合应用分析。数据应用层直接面向用户需求，可以结合业务数据多角度、个性化、精细化的分析特点，自由选取分析维度和关注指标，迅速完成分主题图表定制与数据分析；也可以利用商业智能（Business Intelligence，BI）自助分析工具来开发支持业务和分析场景的应用。常见应用包括管理驾驶舱、多维分析、数据挖掘、图表协同等。

对开发生产数据集成架构进行管理，能够提升企业数据的共享性、一致性及完整性，实现数据互融互通，满足业务人员多角度、个性化的应用需求，最终形成需求完善数据模型、模型引导数据集市、集市支撑业务分析、分析引导业务需求的良性循环。

3 数据集成架构策略

3.1 避免数据主体对象的重复建设

①油田生产中的业务对象主体应与其他系统的描述对等。例如，井号在任何一个系统中，无论以何种形式来描述，实际上指代的都是同一业务对象主体。因此，业务对象的主体数据和之间的关系描述不能重复建设。②必要的数据需在本系统内进行采集。通常情况下，避免数据重复建设，不仅指现有数据资源不能重复录入，还要考虑到今后其他系统扩大应用范围后，数据建设内容的完善性。一般来说，某项业务内容的扩展，需要尽量在原有系统中进行，但由于架构等方面的历史问题，必然会建设新的、更先进的应用系统替代旧的应用模式。

3.2 最大限度协调数据交换

针对部分已经在现有系统中完成建设的数据，需要充分协调，避免数据形成“孤岛”，实现信息共享。

3.3 把握数据对象主体，科学设计以应对环境数据变化

环境数据变化的最理想应对状态，就是在原应用系统甚至原属性界面上增加几个字段，显然这是过于理想化的情况。当环境数据范围或结构发生变化，如原来需要录入的数据在其他或本系统中已经存在，或者原来引用于某系统的数据项在该系统中的命名或存储表发生了变化，都可能涉及算法调整和引用关系的调整。

①充分把握业务对象主体。不同的应用系统对业务对象主体的描述存在差别，这种差别只是形式上的不同，本质上指的是同一个业务对象。对于地质单元、组织机构、井等主务对象主体的描述要科学准确，与主流系统保持绝对一致。②准备数据录入界面。对于引用的属性数据，除建立可维护的数据交换接口程序，还要有相应的录入界面。在数据交换不能正常进行时，启动录入界面进行数据录入，以备应对。

3.4 及时更新优化数据模型

随着业务研究逐渐深入，数据模型体量增大，需要对其进行定期维护和观察，以便能与开发生产数据集成架构相匹配。因此，有必要按照下面的数据模型优化流程进行规范，以最大限度保证数据变化、版本更新不至于对系统的正常运行造成不利影响。

3.4.1 梳理数据字典

开发生产数据集成系统的数据字典设计一定要有前瞻性，要为系统的拓展留有余地。对于已上线的系统，可以从4 个方面进行优化：①明确数据字典。信息系统在建设时应该编写完整的数据字典，用以详细说明数据库现有的用户和对象。当新版本发布时，需要同步更新数据字典资料。②梳理无用索引、无用表及无用存储过程。如有必要，可以对系统的索引使用情况进行监控。③清理无用对象。由系统维护人员确认无用数据库对象并清理，确保库中不存在业务系统不需要的对象。另外，可以从版本发布定时审阅、数据字典发布版本定期更新、及时存档系统数据字典等管理角度来保持系统的优化效果和架构的合理性。④梳理、整合系统常用业务数据，使系统架构清晰明了。

3.4.2 优化物理模型

数据量激增、运行系统的增删改等操作都会导致数据的碎片化程度加剧，并产生大量的垃圾数据，从而威胁开发生产数据系统的正常运行。建议采取以下措施应对：①历史数据分离。通过合理规划系统架构，建立一套历史数据迁移机制，及时将历史数据从运行数据库迁移到历史数据库，使业务表中所存放的有效期内的数据量不至于太庞大，不会随时间推移而使系统性能大幅下降。②根据数据表的业务特性，按照时限要求，定期进行数据清理。③表和索引的碎片化会占用大量存储空间，增加I/O 访问量，影响系统性能。因此，企业需要定期进行碎片整理，避免碎片化程度过高。

3.4.3 加强系统架构变更管理

在版本发布前，企业需要确保数据结构的变更不会破坏系统整体架构。此外，为了确保系统的稳定性，还要加强对新增或变更结构化查询语言（Structured Query Language，SQL）语句的审核，如有必要，应对SQL 语句的执行效率和上线之后的性能进行跟踪评估。

3.4.4 开展日常性能监控

一是通过自动工作负载信息库（Automatic Workload Repository，AWR）、自动数据库性能监视器(Automatic Database Diagnostic Monitor AWR，ADDM)对数据库进行性能监控，保证系统持续健康运行。二是定期检查消耗资源过多的SQL 语句并及时优化。三是根据业务需求，定期分析特殊业务表的定时任务。数据库中经常使用定时任务来按周期自动执行存储过程，当涉及同一个表的多个定时任务同时执行时，有可能会造成死锁。如何避免资源冲突，合理分配这些定时任务，是优化数据模型的一个方面。