油井里的「大数据」，如何成为真正的资产

作为人类最重要的能量源，石油勘探开发是对计算和数据要求最高的行业之一。

六十年前的大庆，为了分析石油的地下分布，建设者们从地下11400米取出岩心，分析化验多达160万块次，地层对比超1744万次。

现在，石油勘探用上了震源车，重击大地制造人工地震，单次产生上百TB的地震波数据。采集、分析、和处理数据是“找油”的关键。

为了分析地下石油分布，原国家地质矿产部（后改组归入国土资源部）下属计算所，在二十余年前即拥有着北京前二的计算机算力，仅次于气象分析部门。

但站在2022年，相比于早已将数据作为核心资产的科技行业，石油勘探与采集领域的“大数据”才刚刚开始。

难采的数据

在数字化的大趋势下，数据已经成为最重要的资产，甚至有学者认为，未来一切企业都是数据公司。但在更“重”的石油勘探开发领域，数字化并不容易。

数据采集困难

油井与抽油机并不会自动产生数据，像互联网公司一样自动获得数据、为用户画像是几乎不可能的任务。在偏远难走的油田区，石油工人要花一天时间巡检负责的油井，检查设备状态、手工记录油井与抽油机的状态。

开采的超高复杂度，也为数字化带来挑战。根据中石化华北石油局2017年公布的ERP部署进展，石油开采不同环节日常上报的报表多达55份：钻井专业10类、测井专业1类、录井专业25类、井下作业8类、采油气专业3类、油气集输专业8类。

数据工具平台匮乏

手工采集之后，数据录入都因过于复杂而成了技术活儿，许多油田都设有专人负责生产数据的统计与录入。2021年夏天，天津大港油田信息中心曾专门开展数据录入竞赛，以部门比拼的形式提升录入能力。

数据分散建设，结构和标准不统一

建设时间、地质条件和地域因素不同，各个油田有着各自不同的管理方式。数据采集要求不同、统计口径各异，使得将不同油田的数据汇总分析几乎是不可能的任务。

数据分析能力薄弱，价值无法发挥

勘探数据的特殊性即使是在移动互联网开始普及的2014年，绝大部分生产数据的汇报，都停留在Word、Excel或PPT的形式提交和管理。即便使用现在习以为常的大数据分析技术，面对油田经营生产中产生的大量且繁杂的数据，也无能为力进行数据的高效汇聚、治理、共享交换等一系列的管理和应用。因此尽管有着极大的数据量，石油管理者们能看到的大多是基于财务视角的各类报表，无法为生产、勘探和石化研究提供决策支持和业务提升。

数据孤岛，数据拉通困难重重

此前，某石油集团曾邀请知名科学家协助研究，提升油田开采效率。但最初提供的油井数据只有8口，多方协调后才拿到200余口。

在开采石油的行业，数据成了更难被开采的原油。

十一年磨出的数据互联

尽管数据采集艰难，石油开采的信息化建设与其它行业一样在2000年后开始了快速建设。只是庞大的规模、分散的地理位置和极长的产业链条，使得信息化系统的应用也分散在了各个分公司、油田和科室。

这样的建设模式，让各业务单元能够灵活建设最适合自己的系统，实现高效的单点提升。但其带来的兼容问题，却使得全局层面上的效率很难进化。

独立建设的系统互不联通，长期以来，油田、分公司与集团间的数据交互只能以最通用的Excel进行。但这样的形式，无疑让数据的合并、纠错和分析成为工作量黑洞。各系统数据形成了孤岛，这就导致小到数据格式无法互相读取，大到数据开发管理低效复杂，更无法实现数据的自如应用。

为了解决这一问题，石油系统内外的IT人在十余年前开始了探索。2008年，江苏油田立项研发“勘探开发一体化数据中心及集成平台EDIBC”，试图将物探、地质研究、钻井、测井、录井、井下作业、采油、集输、生产调度、决策辅助等环节的数据统归入一个平台，并以符合石化行业规范的方式完成数据的采集、管理与流转。

这可能是*个将石油勘探开发的所有领域数据联通在一起，并面向生产进行数据采集、分析和业务联动的系统。

2014年，科技部组织倪光南院士领衔的专家团对EDIBC进行了评审，给予了极高评价。次年，中石化集团就决定推广这一成果，以EDIBC为基础建设具有自主知识产权的勘探开发业务管控平台EPBP。

数十万口油井的生产数据开始有了统一的数据规范和管理平台，至2019年，EPBP完成了在中石化石油勘探开采领域的全覆盖。最“重”的石油化工上游，用11年的时间完成了数据维度上的“车同轨、书同文”。

尽管EPBP的部署花费了整整四年 ，却并不能定义为“慢”。曾为石化行业提供IT服务的软件商王一（化名）告诉36kr，一套系统能够将地质情况各异、管理方式不完全一样的不同油田在数据层面打通，已是相当了不起的成就。

“原油开采不是互联网，不管什么系统，首先一条是不能影响生产。”王一说，“新系统背后是新的工作流程，包括日常管理方式的变化，这都不是短期能够完成的。”

协同平台的部署，解决了业务现场的数据录入和存储问题。但这些数据就像“原油”，要用起来并不容易。

算力问题

传统的数据技术架构难以满足日益增长的业务需求。EPBP的数据库由Oracle数据库为内核搭建，能够满足数据的分类汇总和查询功能，但没有足够的处理和应用数据的能力。

响应时效问题

当越来越庞大的数据量源源不断地汇入时，系统缺乏敏捷的算力支撑，也难以实现数据的实时更新，当日录入的各类数据往往要延迟到次日才能查看。许多数据整合和管理操作都还依赖于人工，效率低且质量不高。

数据交换和共享成本高

各环节的数据对接也成了问题，原有的数据库没有向外对接的接口，无法向科研、业务、管理所需的各类软件直接导入数据。如果某一研究室需要特定时间段、特定类型的汇总数据，信息管理部门需要以写脚本的形式调出数据再完成转交。很长时间内，“数据管理”成了体力活。

数据安全管理问题

数据在面向各油田提供服务的同时更关键的可能是安全性，传统数据架构缺乏服务审计和统一的数据标准，导致数据权限和安全防范的难度大增。

面对以上问题，受命管理数据的中石化石油勘探开发研究院在2019年立项，希望以数据中台形式，承接前台管理生产现场数据，为后端的应用层提供统一的数据资产，实现数据汇聚、治理、管理和服务，并不断挖掘数据更多价值，充分发挥数据能力。在当时，数据中台、云服务已不是新词。但外部技术合作方的选择却让负责中台建设的团队犯了难。

多年的信息化建设，使得市面上存在不少专为石油行业服务的软件提供商。它们足够了解行业，却很难承接如此规模的大数据项目。在选型过程中重点考察以下几点：全局体系化的数据规划；构建自主的大数据能力；以及标准化的产品能力。

知名的互联网大厂们能提供已被验证的成熟技术和产品，但标准的“产品化”服务，意味着应用方既无法针对自身需求做调整，也不能由自己掌控数据安全，对于有着大量非公开数据、需求高度特化的石油开采，这一模式同样无法被接受。

京东大数据背景的科杰科技，在具备大厂的能力同时有针对个性需求调整的可能性，因此得到了机会。在耗时一年的选型之后，中石化勘探院成了“主动上门”的甲方。

按照此前的经验完成建设后的中台，在对接后端应用时往往需要供应商的部署服务。但这一次，从应用接入到日常运维，完全由甲方自己完成。经历了前期的公开招标、技术探讨、方案选型完成后，中石化勘探院的信息团队驻场在了科杰科技的办公室，自学掌握了后续应用的部署方法，还同时完成了基于脱敏数据的算力测试。整个项目过程中让于洋惊叹的是来自传统行业甲方的专业程度。

国企体系内的信息部门、硕博士为主的年轻团队、经常加班至深夜，这次合作也颠覆了于洋对国企的认知。

双方自2020年10月初次接触起，仅用不到一年时间就完成了产品上线，并在上线后的一个月内为各应用部门交付了近100个数据服务。

中台搭建完毕后，呈现在管理部门面前的就不再是以日、周、月为单位缓慢更新的汇总数据。在标准化的数据治理后，科杰团队仅用几天时间就搭建出了实时更新的大数据看板。随着一线的数据录入，总部可以在*时间掌握每一座油井的运行状况，让管理决策能够以数据为依据。

困扰管理和科研部门的算力与数据问题也被中台解决，无需再处理杂乱无用的“脏数据”，也不用再因算力问题而拖慢效率。

更直接的效果是，统一的数据中台建设，避免了各应用方、分公司和油田的重复建设，数据共享节约了大量成本。

从目前的建设成果看，中台提供了全域化数据汇聚、数据治理、数据管理和数据服务的能力，让数据成为可被利用的资产。“通常我们认为数字化的过程是信息化、数据化和智能化。”于洋说，“现在的石油勘探开发可能还处在数据化的过程中，刚刚开始具备数据能力。”

根据规划，数据中台未来还将接入科研、实验室和勘探专业的大量地球物理数据，为石化行业上游的全流程提供支撑。

尽管遥远，石油勘探与大数据结合的智能化已走在路上。