油气勘探开发数据治理与数据中台实践研究

报告编号： OGC-A-028 所属赛道： 油气 · 物探测井与数字油田 报告级别： A 级专题深度研究 编制单位： 北京经纬智汇信息咨询有限公司 报告用途： 内部参考 报告字数： 约 13000 字

摘要

油气勘探开发是典型的数据密集型业务。一口深井从钻前地质研究到废弃报废，全生命周期可产生数十 TB 的地震、测井、录井、钻井、试油试采与生产动态数据；一个成熟油气公司的历史数据资产往往以 PB 计。然而长期以来，这些数据被封锁在 Petrel、GeoEast、Landmark、Techlog、Eclipse 等专业软件的私有格式里，形成一座座"数据孤岛"；据业内多方估算，地球科学家与油藏工程师有 50%–70% 的工作时间消耗在寻找、清洗、搬运数据上，而非真正的分析与决策。这一"数据税"在低油价与降本增效的产业周期中愈发不可承受，也成为人工智能与大模型在油气行业规模化落地的最大掣肘——没有被治理好的数据，就没有可用的 AI。

本报告以"数据治理 + 数据中台"为主线，沿"过去→现在→未来"的完整时间轴，系统剖析油气勘探开发数据资产化的技术原理、标准体系、全球竞争格局与中国实践路径。核心判断是：以 OSDU（开放地下数据空间）为代表的开放数据平台标准，正在成为全球油气数据治理事实上的"操作系统层"，标志着行业从"以应用为中心"向"以数据为中心"的范式迁移；云厂商（微软、AWS、谷歌）与油服巨头（SLB、Halliburton、Baker Hughes）借势重构数据平台市场，而中国三大石油公司则通过梦想云、石化智云、智能油田等自主平台走出一条"国际标准对接 + 信创自主可控"的双轨道路。全球油气数据管理与平台市场规模 2024 年处于约 270 亿–310 亿美元区间，未来五年复合增速普遍预期在 12%–19%，AI 化与云化是最强驱动力。

报告最后面向甲方油气生产企业、油服公司、IT/咨询服务商与投资方，给出分阶段的立项、选型与投资行动建议，并提示市场口径、技术路线与地缘合规三类主要风险。

第一章 行业与技术背景：为什么油气数据治理是一道绕不开的坎

1.1 油气勘探开发数据的五大先天特征

要理解油气数据治理为何困难，必须先理解这类数据的先天禀赋。与互联网、金融等行业相对规整的结构化数据不同，油气勘探开发数据具有五个鲜明特征，它们共同构成了治理的技术难度来源。

其一，多源异构。 油气数据横跨地球物理（地震采集、处理、解释）、测井、录井、钻井工程、试油试采、油藏工程、生产动态、地面工程乃至财务与 HSE 等十余个专业域。每个专业域都有自己的数据模型、采集设备、处理软件和文件格式：地震数据是 SEG-Y 体数据，测井曲线是 LAS/DLIS，井轨迹、分层、射孔又各成体系。这种跨专业的异构性是油气数据区别于其它行业的第一性难题。

其二，海量且持续增长。 单块三维地震工区的叠前道集可达数十 TB；一口页岩气水平井的随钻与生产实时数据以毫秒级持续回传。大型国际石油公司的数据资产普遍在数 PB 到数十 PB 量级。随着"两宽一高"（宽方位、宽频带、高密度）地震、光纤 DAS/DTS 永久监测、随钻高速遥测的普及，数据体量还在指数级膨胀。

其三，时空属性极强。 几乎每一条油气数据都锚定在特定的三维空间位置（井位坐标、深度、地震道号）和时间点（采集时间、生产时刻）。这决定了油气数据治理绕不开地理空间信息与时间序列的双重索引，通用大数据平台的表结构难以直接套用。

其四，专业软件格式壁垒森严。 这是油气数据孤岛问题的核心症结。全球油气软件市场高度集中于少数厂商——SLB 的 Petrel（地质建模）、Techlog（测井）、ECLIPSE/INTERSECT（油藏数值模拟），Halliburton 的 DecisionSpace/Landmark，以及东方地球物理 GeoEast 等。这些软件多采用私有二进制格式与专有项目库，彼此之间数据互通困难，用户被牢牢锁定在特定厂商生态内，形成技术性与商业性双重壁垒。

其五，数据质量参差、历史包袱沉重。 油气公司动辄有数十年历史数据，早期资料以纸质、胶片、磁带等形式存在，命名不规范、坐标系混乱、单位不统一、元数据缺失极为普遍。一口老井的分层数据可能在不同数据库里存在三四个互相矛盾的版本。历史数据的清洗、数字化与标准化，是治理成本最高、最考验耐心的部分。

1.2 数据治理的核心概念框架

数据治理（Data Governance）并非单一技术，而是一整套围绕数据资产的管理体系。在油气语境下，它至少包含以下相互关联的支柱：

• 数据标准：统一的数据模型、字典、编码规则与命名规范，是打破孤岛的前提。
• 元数据管理（Metadata Management）：管理"描述数据的数据"，回答某份数据是什么、从哪来、什么时候采的、谁负责、精度如何等问题。
• 主数据管理（MDM，Master Data Management）：对井、井筒、区块、油气藏等跨系统共享的核心业务对象建立唯一、权威、一致的"黄金记录"。在油气领域，"一井一码"（每口井全局唯一标识）是主数据治理的基石。
• 数据质量管理：通过规则校验、清洗、比对，持续监控和提升数据的完整性、准确性、一致性、及时性。
• 数据资产目录：像图书馆索引一样，让用户能够发现、检索、理解全公司的数据资产。
• 数据血缘（Data Lineage）：追踪数据从源头经过各种加工处理到最终应用的全链路流转，用于影响分析与可信溯源。
• 数据安全与权限：分级分类、脱敏、访问控制，兼顾开放共享与合规安全。
• 数据生命周期管理：从采集、存储、使用到归档、销毁的全过程管控。

这套体系的要义在于：数据治理是"三分技术、七分管理"的系统工程，技术平台只是载体，组织、流程、标准与文化才是成败关键。

1.3 从数据仓库到数据网格：承载平台的技术演进脉络

数据治理需要技术平台承载，而这一承载平台本身经历了清晰的代际演进，理解这条脉络对判断油气行业的技术选型至关重要：

数据仓库（Data Warehouse，1990s—）：面向结构化数据的主题式集成，强调"先建模后入库"（Schema-on-Write）。优点是规整、查询性能好，缺点是难以容纳地震体、图件、文档等海量非结构化数据，扩展性受限。

数据湖（Data Lake，2010s—）：以低成本存储原始格式的海量多源数据，"先入湖后建模"（Schema-on-Read）。契合油气数据多源异构海量的特征，但缺乏治理时极易退化为"数据沼泽"（Data Swamp）——数据进得去、找不到、用不了。

湖仓一体（Lakehouse，2020—）：以 Delta Lake、Apache Iceberg、Apache Hudi 等开放表格式为代表，在数据湖的低成本存储之上叠加数据仓库的事务、Schema 管理与查询能力，兼得二者之长。这是当前油气数据平台底座的主流技术选择。

数据中台（Data Middle Platform，2015 起源于中国）：源自阿里巴巴的实践，强调将数据能力"资产化、服务化、复用化"，通过统一的数据服务层向前端业务快速供数。中台概念在中国油气行业（尤其中石油梦想云）落地深入，本质是"治理 + 平台 + 服务"的组织级能力沉淀。

数据网格（Data Mesh，2019—）：作为对中心化中台的反思，主张"数据即产品"、领域自治、去中心化的分布式数据架构，由各业务域自主负责本域数据产品的质量与服务。这一理念与油气行业按专业域（地震、测井、油藏……）天然分工的组织结构高度契合，也与 OSDU 的领域数据管理服务（DDMS）设计思想呼应，是面向未来的前沿方向。

值得强调的是，这些概念并非简单的新旧替代关系，而是层层叠加、并存互补。当下油气数据平台的典型形态是：以湖仓一体为技术底座、以数据治理为核心内功、以中台化服务或网格化领域产品为供数方式、以 OSDU 等开放标准为互通语言的复合体。下一章将深入其技术原理。

第二章 核心技术原理剖析：标准、架构与技术栈

数据治理与数据中台的技术内核，可以拆解为三个层面：标准层（用什么语言描述数据）、平台架构层（用什么架构管理数据）、技术栈层（用什么工具实现）。本章逐层剖析，重点解剖已成为全球焦点的 OSDU。

2.1 油气数据标准三大体系：PPDM、Energistics 与 OSDU

数据标准是打破孤岛的"普通话"。全球油气行业历经数十年，形成了三套主要标准体系，理解它们的分工与关系是把握整个领域的钥匙。

PPDM（Professional Petroleum Data Management，专业石油数据管理协会）：成立于 1980 年代，是历史最悠久的油气数据模型标准。其核心产出是一套覆盖井、地震、生产、土地权益等业务域的关系型数据库逻辑模型（PPDM 3.x 数据模型），以及广受认可的"What is a Well?"（一口井的严格定义）等基础语义规范。PPDM 解决的是"数据如何规范地建模和存储"的问题，是数据库层面的标准。

Energistics 系列标准：由行业联盟 Energistics（现已并入 Energy Standards，隶属 Open Group）维护，聚焦"数据如何在系统间交换传输"，是一组基于 XML/RESTful 的数据交换标准： - WITSML（Wellsite Information Transfer Standard Markup Language）——钻井与随钻实时数据交换，是钻井实时中心与远程协作的通用语言； - PRODML——生产数据交换； - RESQML——油藏建模与地震解释成果的交换； - ETP（Energistics Transfer Protocol）——底层高效传输协议，支持实时流式数据。

Energistics 标准解决的是"数据如何跨系统流动"的问题，是接口与传输层面的标准。

OSDU（Open Subsurface Data Universe，开放地下数据空间）：由 Open Group 旗下的 OSDU Forum 主导，是 2018 年以来最重要的行业变革。OSDU 不是又一个数据模型，而是一个开放的、云原生的数据平台参考架构与标准，目标是彻底解耦"数据"与"应用"，让数据以厂商中立、云中立的方式被统一存储、索引、检索和消费。OSDU 的雄心在于成为整个上游行业的"数据操作系统层"，PPDM 和 Energistics 的模型与语义被吸纳融入其中（OSDU 的 Well-known Schema 大量借鉴 PPDM 与 Energistics）。三者关系可概括为：PPDM 管建模、Energistics 管交换、OSDU 管平台，OSDU 是集大成的顶层框架。

2.2 OSDU 平台架构深度解剖

OSDU 平台被设计为一套运行在公有云上的微服务集合，其核心机理值得逐层拆解，因为它代表了油气数据平台架构的前沿范式：

（1）数据加载与摄取（Ingestion）：来自各专业软件与数据源的数据，通过标准化的摄取管线进入平台。摄取过程中完成格式解析、Schema 校验、坐标参考系统（CRS）归一化、单位换算等，把杂乱的原始数据转化为符合平台规范的记录。

（2）Schema 与 Well-known Schema（WKS）：OSDU 定义了一套开放、可扩展的数据 Schema 体系，其中最核心的是描述井、井筒、井日志、地震数据集、地质分层等通用对象的"Well-known Schema"。所有数据入平台后都映射到统一 Schema，这是实现跨源互通的语义基础。

（3）存储与索引（Storage & Indexing）：数据实体（Records）与其关联的大文件（Datasets，如 SEG-Y 体、LAS 曲线文件）分离存储——元数据记录存于文档型存储便于检索，大文件存于对象存储（如 S3、Azure Blob）便于低成本承载。系统自动为每条记录建立索引。

（4）检索与发现（Search & Discovery）：基于统一索引，用户可通过空间范围（某区块内所有井）、属性条件（某年份钻的定向井）、全文等多维方式跨全库检索数据，从根本上解决"数据找不到"的痛点。

（5）DDMS（Domain Data Management Services，领域数据管理服务）：这是 OSDU 架构的精髓之一。针对井筒（Wellbore DDMS）、地震（Seismic DDMS）、油藏等不同专业域，OSDU 提供专门的领域服务来处理该域数据的特有逻辑（如地震道集的按需切片、测井曲线的重采样）。DDMS 的设计思想与"数据网格"的领域自治高度一致，让每个专业域既遵循统一平台规范，又保留领域特性。

（6）ETP 与实时数据：OSDU 通过集成 Energistics 的 ETP 协议支持钻井等实时流式数据的接入，打通了历史数据与实时数据的边界。

这套架构的革命性在于：应用不再拥有数据，数据沉淀在开放平台上，任何合规应用都可通过标准 API 消费同一份权威数据。Petrel、Techlog、乃至新兴 AI 应用，都从"数据的囚笼"变为"数据的消费者"，厂商锁定被系统性瓦解。这正是壳牌等甲方巨头当年发起 OSDU 的根本动机。

2.3 数据湖仓与中台技术栈的油气落地

在 OSDU 参考架构之下（或在自建平台中），支撑其运转的是一套现代大数据技术栈。油气数据平台的典型技术选型如下表：

2.4 主数据、元数据与数据血缘的油气实现要点

在油气领域，主数据管理的重中之重是井（Well）与井筒（Wellbore）主数据。一口井在钻井、地质、油藏、生产、财务等系统里往往有不同的编号和名称，MDM 的任务是建立全局唯一的"井主数据黄金记录"，并将各系统的局部标识映射关联（"一井一码"）。区块、油气藏、地面站场、设备也需类似治理。

元数据管理则要回答每份数据的"前世今生"：采集参数、处理流程、精度、责任人、密级。数据血缘进一步把这些串成链——例如一张构造图，可溯源到它由哪个解释项目、基于哪版地震数据、经过哪些处理步骤生成，一旦源头地震数据更新，可自动分析受影响的所有下游成果。这种可信溯源能力，是油气数据从"能用"迈向"可信"的关键，也是 AI 训练数据可靠性的前提。

2.5 数据即服务（DaaS）与数据资产化

治理与平台的最终价值出口，是让数据像水电一样按需服务。通过将数据能力封装为标准化 API（DaaS），上层的地质建模、油藏模拟、生产优化乃至 AI 大模型应用，都能以自助、实时的方式获取所需数据，供数周期从过去的数天数周压缩到分钟级。更进一步，当数据被系统性治理、目录化、质量可控后，它便从"成本项"转变为可计量、可评估、可交易的"资产项"——这为后文将讨论的"数据资产入表"打开了想象空间。