36Kr-数字时氪
文|李怡彭
编辑|石亚琼
作为人类最重要的能量源，石油勘探开发是对计算和数据要求最高的行业之一。
六十年前的大庆，为了分析石油的地下分布，建设者们从地下11400米取出岩心，分析化验多达160万块次，地层对比超1744万次。
现在，石油勘探用上了震源车，重击大地制造人工地震，单次产生上百TB的地震波数据。采集、分析、和处理数据是“找油”的关键。
为了分析地下石油分布，原国家地质矿产部(后改组归入国土资源部)下属计算所，在二十余年前即拥有着北京前二的计算机算力，仅次于气象分析部门。
但站在2021年，相比于早已将数据作为核心资产的科技行业，石油勘探与采集领域的“大数据”才刚刚开始。
1 难采的数据
在数字化的大趋势下，数据已经成为最重要的资产，甚至有学者认为，未来一切企业都是数据公司。但在更“重”的石油勘探开发领域，数字化并不容易。
数据采集困难
油井与抽油机并不会自动产生数据，像互联网公司一样自动获得数据、为用户画像是几乎不可能的任务。在偏远难走的油田区，石油工人要花一天时间巡检负责的油井，检查设备状态、手工记录油井与抽油机的状态。
开采的超高复杂度，也为数字化带来挑战。根据中石化华北石油局2017年公布的ERP部署进展，石油开采不同环节日常上报的报表多达55份：钻井专业10类、测井专业1类、录井专业25类、井下作业8类、采油气专业3类、油气集输专业8类。
数据工具平台匮乏
手工采集之后，数据录入都因过于复杂而成了技术活儿，许多油田都设有专人负责生产数据的统计与录入。2021年夏天，天津大港油田信息中心曾专门开展数据录入竞赛，以部门比拼的形式提升录入能力。
数据分散建设，结构和标准不统一
建设时间、地质条件和地域因素不同，各个油田有着各自不同的管理方式。数据采集要求不同、统计口径各异，使得将不同油田的数据汇总分析几乎是不可能的任务。
数据分析能力薄弱，价值无法发挥
勘探数据的特殊性即使是在移动互联网开始普及的2014年，绝大部分生产数据的汇报，都停留在Word、Excel或PPT的形式提交和管理。即便使用现在习以为常的大数据分析技术，面对油田经营生产中产生的大量且繁杂的数据，也无能为力进行数据的高效汇聚、治理、共享交换等一系列的管理和应用。因此尽管有着极大的数据量，石油管理者们能看到的大多是基于财务视角的各类报表，无法为生产、勘探和石化研究提供决策支持和业务提升。
数据孤岛，数据拉通困难重重
此前，某石油集团曾邀请知名科学家协助研究，提升油田开采效率。但最初提供的油井数据只有8口，多方协调后才拿到200余口。
在开采石油的行业，数据成了更难被开采的原油。
2 十一年磨出的数据互联
尽管数据采集艰难，石油开采的信息化建设与其它行业一样在2000年后开始了快速建设。只是庞大的规模、分散的地理位置和极长的产业链条，使得信息化系统的应用也分散在了各个分公司、油田和科室。
这样的建设模式，让各业务单元能够灵活建设最适合自己的系统，实现高效的单点提升。但其带来的兼容问题，却使得全局层面上的效率很难进化。
独立建设的系统互不联通，长期以来，油田、分公司与集团间的数据交互只能以最通用的Excel进行。但这样的形式，无疑让数据的合并、纠错和分析成为工作量黑洞。各系统数据形成了孤岛，这就导致小到数据格式无法互相读取，大到数据开发管理低效复杂，更无法实现数据的自如应用。
为了解决这一问题，石油系统内外的IT人在十余年前开始了探索。2008年，江苏油田立项研发“勘探开发一体化数据中心及集成平台EDIBC”，试图将物探、地质研究、钻井、测井、录井、井下作业、采油、集输、生产调度、决策辅助等环节的数据统归入一个平台，并以符合石化行业规范的方式完成数据的采集、管理与流转。
这可能是第一个将石油勘探开发的所有领域数据联通在一起，并面向生产进行数据采集、分析和业务联动的系统。
2014年，科技部组织倪光南院士领衔的专家团对EDIBC进行了评审，给予了极高评价。次年，中石化集团就决定推广这一成果，以EDIBC为基础建设具有自主知识产权的勘探开发业务管控平台EPBP。
数十万口油井的生产数据开始有了统一的数据规范和管理平台，至2019年，EPBP完成了在中石化石油勘探开采领域的全覆盖。最“重”的石油化工上游，用11年的时间完成了数据维度上的“车同轨、书同文”。
尽管EPBP的部署花费了整整四年 ，却并不能定义为“慢”。曾为石化行业提供IT服务的软件商王一(化名)告诉36kr，一套系统能够将地质情况各异、管理方式不完全一样的不同油田在数据层面打通，已是相当了不起的成就。
“原油开采不是互联网，不管什么系统，首先一条是不能影响生产。”王一说，“新系统背后是新的工作流程，包括日常管理方式的变化，这都不是短期能够完成的。”
协同平台的部署，解决了业务现场的数据录入和存储问题。但这些数据就像“原油”，要用起来并不容易。
算力问题
传统的数据技术架构难以满足日益增长的业务需求。EPBP的数据库由Oracle数据库为内核搭建，能够满足数据的分类汇总和查询功能，但没有足够的处理和应用数据的能力。
响应时效问题
当越来越庞大的数据量源源不断地汇入时，系统缺乏敏捷的算力支撑，也难以实现数据的实时更新，当日录入的各类数据往往要延迟到次日才能查看。许多数据整合和管理操作都还依赖于人工，效率低且质量不高。
数据交换和共享成本高
各环节的数据对接也成了问题，原有的数据库没有向外对接的接口，无法向科研、业务、管理所需的各类软件直接导入数据。如果某一研究室需要特定时间段、特定类型的汇总数据，信息管理部门需要以写脚本的形式调出数据再完成转交。很长时间内，“数据管理”成了体力活。
数据安全管理问题
数据在面向各油田提供服务的同时更关键的可能是安全性，传统数据架构缺乏服务审计和统一的数据标准，导致数据权限和安全防范的难度大增。
面对以上问题，受命管理数据的中石化石油勘探开发研究院在2019年立项，希望以数据中台形式，承接前台管理生产现场数据，为后端的应用层提供统一的数据资产，实现数据汇聚、治理、管理和服务，并不断挖掘数据更多价值，充分发挥数据能力。在当时，数据中台、云服务已不是新词。但外部技术合作方的选择却让负责中台建设的团队犯了难。
多年的信息化建设，使得市面上存在不少专为石油行业服务的软件提供商。它们足够了解行业，却很难承接如此规模的大数据项目。在选型过程中重点考察以下几点：全局体系化的数据规划;构建自主的大数据能力;以及标准化的产品能力。
知名的互联网大厂们能提供已被验证的成熟技术和产品，但标准的“产品化”服务，意味着应用方既无法针对自身需求做调整，也不能由自己掌控数据安全，对于有着大量非公开数据、需求高度特化的石油开采，这一模式同样无法被接受。
京东大数据背景的科杰科技，在具备大厂的能力同时有针对个性需求调整的可能性，因此得到了机会。在耗时一年的选型之后，中石化勘探院成了“主动上门”的甲方。
按照此前的经验完成建设后的中台，在对接后端应用时往往需要供应商的部署服务。但这一次，从应用接入到日常运维，完全由甲方自己完成。经历了前期的公开招标、技术探讨、方案选型完成后，中石化勘探院的信息团队驻场在了科杰科技的办公室，自学掌握了后续应用的部署方法，还同时完成了基于脱敏数据的算力测试。整个项目过程中让于洋惊叹的是来自传统行业甲方的专业程度。
国企体系内的信息部门、硕博士为主的年轻团队、经常加班至深夜，这次合作也颠覆了于洋对国企的认知。
双方自2020年10月初次接触起，仅用不到一年时间就完成了产品上线，并在上线后的一个月内为各应用部门交付了近100个数据服务。
中台搭建完毕后，呈现在管理部门面前的就不再是以日、周、月为单位缓慢更新的汇总数据。在标准化的数据治理后，科杰团队仅用几天时间就搭建出了实时更新的大数据看板。随着一线的数据录入，总部可以在第一时间掌握每一座油井的运行状况，让管理决策能够以数据为依据。
困扰管理和科研部门的算力与数据问题也被中台解决，无需再处理杂乱无用的“脏数据”，也不用再因算力问题而拖慢效率。
更直接的效果是，统一的数据中台建设，避免了各应用方、分公司和油田的重复建设，数据共享节约了大量成本。
从目前的建设成果看，中台提供了全域化数据汇聚、数据治理、数据管理和数据服务的能力，让数据成为可被利用的资产。“通常我们认为数字化的过程是信息化、数据化和智能化。”于洋说，“现在的石油勘探开发可能还处在数据化的过程中，刚刚开始具备数据能力。”
根据规划，数据中台未来还将接入科研、实验室和勘探专业的大量地球物理数据，为石化行业上游的全流程提供支撑。
尽管遥远，石油勘探与大数据结合的智能化已走在路上。
（免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。 ）
