从数字油田的关键问题说开去

昨天在“智能数字油田开放论坛”上忍不住说了一句“数据元、元数据不是解决数字油田的关键问题”就干活去了，后来发现被袁教授追问了一句“那什么才是数字油田的关键问题？”，经这么一追问，我还真一下子说不出哪些算是关键问题，这两天就根据自己从事的一些工作所掌握的情况来扯上几句。

1、数字油田的关键技术？

虽然以前承担了《数字油气田关键技术研究》863项目中的一个课题工作，但惭愧的是被赶鸭子上架，并没有理清哪些算是关键技术，也没有弄出什么高级理论，几个人整天忙着写材料、汇报、开会、验收、审计，干活的时候找不到几杆枪，终于验收了这个项目，也让我大大地舒了一口气，从此也就明白了为什么中国出不了诺贝尔奖了，哈哈，扯远了。

把以前的总结报告拿出来，看看研究的几项内容，油气田信息资源集成服务平台、基于元数据的多源异构信息集成技术、油气田公用组件可复用技术、三维地质体的多尺度组织及建模、三维可视化与交互、 勘探开发本体知识模型、系统集成与辅助决策，是关键技术吗？实际上我也不认可，数字油田的概念都不统一，只要你为油田做了一点信息化的工作，肯定都是数字油田其中的一项技术，但是否关键就不是谁说了算的。但是立项指南写了那几项，就硬着头皮做吧。记得以前高老师的数字油田研究所整理过一张图，技术点很全，但哪些算是关键技术？估计足够让大家来一场热烈的讨论。

2、我感觉当前数字油田建设时缺失的地方

由于工作的地方只限于胜利油田这样的小地方，了解一点其它油田情况，又只弄过勘探信息化，所以我的观点肯定有局限性。

我感觉油田信息化的问题在于重数据轻应用。油田的整体规划一直是先弄数据，再弄一套采集程序，再搞相关应用，结果数据模型弄了好几版，数据中心弄了好几期，应用一直跟不上，录入的数据让用户查不到，应用没有跟上造成数据质量问题多多，用户就不喜欢用，数据质量就会更糟，从而限入恶性循环。

所以我感觉数字油田是否能建成，不在于是不是有一个多么牛X的数据模型，而是要用信息化实现某个业务的完整体系，一个数据库、一个应用软件、一套管理体系，并把管理体系纳入到生产体系中，有数据管理人员能够让数据采上来、维护其及时性和准确性，应用软件能够解决其生产实际的问题，让他真正感受到带来的便利，用户就会反映数据方面发现的问题，数据就会慢慢好起来，一个业务一个业务的把数据、应用、管理跑顺了，这才是良性循环之道。应用跑顺了，说明数据模型就符合要求了，这个才可以考虑成为数据标准。

现在是所有的数据一起弄，都想弄一个大而全的，但任何事情都有一个不断迭代的过程，你花了三年弄了一套数据模型，数据好的坏的都进来，开发软件时发现问题一大堆，写程序的不让改数据模型，那就只能自己建立其它的数据库，原有的数据模型就明显地脱离实际情况了。数据中心又建了源头、中心、应用三级，改个数据都不容易，改数据模型？谈何容易。

3、油田软件开发的问题

油田的软件主要产生于这样几个方面：购买引进、外协研发、自主研发。

购买直接引进的当然是勘探开发的专业软件，这类软件是为综合研究人员用的，或是某类的工具软件，他们的数据库都自成体系，与油田数据中心中的数据基本无关。

外协研发：每年拿出大量资金外协，这个就不便说了。

自主研发里又分为科研项目和信息项目，由于科研项目主要是研究，能编出一份厚厚的成果报告就行了，如果有个软件，那就搞个测试证明，所以最后能运行的软件少之又少。信息建设项目要求能实际应用的软件，主要是几大院里为数不多的人在写，我就是这其中一员。像我们这种国企里还在自己弄软件开发的队伍真是越来越少见了，我们的软件开发成员基本上都40岁左右了，微薄的工资如何留住年轻人？如何让他们写出好的代码？

另外就是自主研发的软件没有维护资金，造成大量的1.0版本，这个1.0版本经常还是没有几个人用过的版本。因为中石化没有给软件的维护升级持续投入，硬件投入后当某个部件坏了后会影响生产，所以一定要有维护费用，而软件就没有这么幸运了，大多数信息软件都不在生产环节中占主要地位，只是辅助研究生产之用，所以只要能够运转就凑合着用，有BUG引起崩溃就重启接着用，网上查不到数据那就手工借。每年你要挖空心思地去想新课题、新项目，才能把你辛辛苦苦写的软件维护起来，否则也只能是1.0版本了。

4、数据库的设计不是独立存在的，也不是第一步工作

数据库不是独立存在的，是为应用服务的，是为用户服务的，服务的用户不同则数据库自然就不同。最近又接到一个三无项目，不能算项目，只能算任务，无合同、无资金、无固定人员，要把以前写的地震管理系统给其它油田用上，正好就谈到数据库设计的问题了。

搞信息化的领导在接到这样的项目时，首先就让我把数据库设计好，然后再找人把采集软件写好，再把一些查询和可视化方面的应用配上，但是问题就来了。软件是给勘探综合研究人员使用，还是为处理人员所用，还是给数据中心的管理人员使用，数据库中的内容差别巨大。

给勘探综合研究人员使用，他们就关心某个地方有多少块三维，多少块二维，处理年度，工区范围有多大，资料的品质如何，典型剖面如何，如果有哪个研究人员有耐心，也足够细心，他还可以翻翻处理报告。

处理人员关心这个地区的有没有旧数据体、以前的设计报告、处理流程、采用的处理方法，实际上最关心的还是100多页的处理报告中的内容，还有以前汇报用的PPT，拿到这些材料他就可以开始他的处理设计，设计他的处理流程，制作他的汇报材料了。

如果是管理处理项目的领导，他关心的是项目长是谁、处理进度如何、参加人员、各阶段检查的纪要、处理方法等等。

如果是物探公司的人员，他更关心地震采集方面的一系列问题，哪个施工队，施工进度如何等等。

数据中心的管理人员关心的数据项就是大而全了，他关心的是要把所有的东西保存了，谁录入了？谁修改了？谁用了？谁下载了？

负责数据加载的人员更关心要有好用的工具，方便他进行数据体检查、加载、维护。

所以说，如果软件是一个大而全的软件，并且一直在生产上应用了几年，那么把这些数据表统一起来就是一个有关地震方面的大而全的数据表，到这时你才谈得上可以纳入数据中心的数据模型标准。然而实际情况中我们只是完成其中的某一个局部，所以只用到几个表中的一些字段就够了。当你没有写过实际的应用程序，你如何让其他人来把你的数据模型视为标准？

来看看“设计数据库—>写采集程序—>写相关应用”这样的流程存在什么问题？数据表凭感觉可以弄一个大而全的，有些表是设计了，也建立了，但数据怎么进来呢，那就弄一个采集软件，数据是进来了，但对不对？因为没有相关的应用，所以没人知道。以后写相关应用的时候，可以再把这些模型推倒重来。

而从应用出发的数据库就不是这样的，通过需求分析，知道用户是谁，软件的功能范围，有了用户原型，就可以设计出它的数据表（如果以前有类似系统，那就要参考以前的数据模型），这个数据库不太全，但符合应用的需要，在写应用程序时，会考虑到数据查询和数据管理的功能，根本不需要单独再弄一个什么采集程序。

油田规划和可行性报告中的8字方针或16字方针中经常会看见“以用促建”四个字，但数字油田中软件应用一直没有跟上，从而可以不断地折腾数据模型、数据标准，当数据还不行的时候，用元数据还是数据元只会增加麻烦，而每折腾一遍这些东西，对软件又是一次致命打击，原有的应用也可能就慢慢完蛋了。

5、数据模型该如何做？

数据中心源头数据库既然已经存在，就不要来回大改了，基于该数据模型到底有多少应用软件？哪些还在生产过程中运行着？

谁的应用软件强大，谁的数据模型就是事实的标准。有了成熟的大型应用，才谈得上数据标准，POSC当时也是这样诞生的，几个国外公司都有应用软件，还想数据交换，就成立了POSC搞数据模型。

胜利的测井数据模型搞得就相当复杂，测井公司与几个公司都有自己的标准，还都有不同的软件，如果你想统一标准？谈何容易，没有钱，哪个公司会去改数据模型？他们还在其它油田推广了无数套软件呢。不能统一标准，那就还是弄数据交换标准吧，国外有WITSML之类的，国内有类似的吗？我就不清楚了。

所以数据模型还是沿用原有标准吧，而可以弄一个数据交换标准，可能需要一个中立的机构去弄，但这种机构在国内的石油行业中没听说过。谁会出钱？我出了钱，你还要中立？

 

6、软件平台之争

好消息是油田的信息规划终于开始弄软件应用了，但坏消息是他们要弄软件平台。

几年前弄的勘探决策支持软件平台，几个月前在弄西南的信息项目方案，再想这些软件平台主要想解决的问题是什么？

是统一用户认证吗？这个有独立的解决方案，油田从AD域到LDAP再到AD域折腾好几遍了，已经统一了好几个应用系统，与软件平台无关。

是数据服务吗？也不是，这个是数据中心项目中的建设内容，你建了数据中心，不提供多种数据服务吗？

消息通讯吗？这个确实是应用平台的主要责任之一，在同一个平台下的模块或插件，需要经常互相发消息，来更新一些状态。底图中把测线位置发消息到剖面，剖面发出当前鼠标点的位置给底图，底图发消息到井筒程序来显示某口井的综合录井图，底图发井号消息到数据查询模块，这些事情都需要消息通讯。但需要一个庞大的应用平台吗？是不是可以直接放到URL中？是不是可以自定义一种协议来实现？应该不需要太高深的技术。

统一记录日志？是用不着，如果日志较多，谁写的软件谁负责记，把信息管理部门想了解的信息写到统一的数据库就行了。

统一插件的技术体系？如果是一个WEB插件，应该就是一个HTML页面，需要复杂的应用平台？不管你用WebLogic、SharePoint还是Confluence，哪个平台中都可以嵌入一个WEB页面吧？集成多个C/S程序？好像信息化软件大都是Windows程序，用ClickOnce或自定义协议都可以启动这些模块。

应用商店，把所有的组件都注册管理起来？好像也不用软件平台吧？元数据这时还真有用，如果是一个客户端插件，那么一个DLL中的元数据信息写全了，就知道是谁开发的，什么时间发布的，版本号等等关键信息了，如果是一个WEB程序，那就写一个服务把config.xml等信息返回回来就够了。

统一桌面？你为什么在我的windows桌面上再盖上一个顶层窗口？为什么不让我直接用我的浏览器？点击勘探信息网中的某个链接就直接打开我关心的应用？为什么不让我直接输入一个URL链接就打开我关心的数据和应用？

反而浏览器的支持倒是一个关键问题，现在的浏览器太多了，版本也太多了，所以出来一个应用平台直接嵌入一个自己的浏览器内核就没问题了。

 

 

现在想想，应用集成倒是一个数字油田现实情况中的一个主要问题，但这个集成不是新建一套系统，不是把软件的应用统一在一个窗口程序中，而是一种松散式的集成，而是要允许不同的应用系统并存，但应用系统要使用统一的用户认证，要能够互相消息通讯，要支持规定好的某几个版本某几种浏览器，要有统一的启动方式和界面布局风格，从任意一个应用程序中都可以方便地链接到其它模块中。

用应用集成的技术把所有应用跑起来、串起来，让用户真正感觉到便利，他就会关心数据问题，你再修改数据服务、修改数据交换标准，但要保证应用一直可用，持续贴进用户的生产实际，真正提高他们的工作效率，为他们减轻一些工作量和负担，而不是做一个只给领导们看的系统。油田的业务纷繁多样，随便一个业务都得弄上N年，到什么程度才算是建成数字油田了？

最近也参与了一点智能油田、智慧油田、大数据之类的立项，但我们的数据基础真的可以开始这些工作了？开展前沿研究没有错，但总得扛着这杆大旗，先把以前的事情理顺吧？

纯属个人观点，欢迎拍砖！