吳凡 高健祎 謝洪路 逄勃

摘? 要：隨著海上油氣勘探行業(yè)數(shù)字化轉型的深入，需要在保證實時數(shù)據(jù)的高質(zhì)量、全面性、及時性的同時，提供高效穩(wěn)定的數(shù)據(jù)服務，為勘探開發(fā)相關各應用系統(tǒng)提供靈活的數(shù)據(jù)支撐?；趥鹘y(tǒng)架構的實時數(shù)據(jù)傳輸系統(tǒng)，在實際應用中存在著傳輸效率低、穩(wěn)定性差等問題，文章提出一種基于Hadoop技術的海上鉆完井井場實時數(shù)據(jù)庫系統(tǒng)架構，并給出了具體的實現(xiàn)方案及實施成效。

關鍵詞：油氣勘探開發(fā);海洋石油;大數(shù)據(jù);實時數(shù)據(jù)庫;Hadoop

中圖分類號：TP311? ? ? ?文獻標識碼：A文章編號：2096-4706（2021）23-0012-06

Design and Implementation of Real-time Database for Offshore Drilling and Completion Well Site Based on Hadoop

WU Fan1， GAO Jianyi1，XIE Honglu2， PANG Bo3

（1.China National Offshore Oil Corporation， Beijing? 100010， China; 2.China France Bohai Geoservices Co.， Ltd.， Tianjin? 300457， China; 3.Petro-CyberWorks Information Technology Co.， Ltd.， Beijing? 100007， China）

Abstract： With the deepening of digital transformation of offshore oil and gas exploration industry， it is necessary to provide efficient and stable data services while ensuring the high quality， comprehensiveness and timeliness of real-time data， so as to provide flexible data support for various application systems related to exploration and development. The real-time data transmission system based on traditional architecture has some problems in practical application， such as low transmission efficiency and poor stability. This paper presents a real time database system architecture of offshore drilling and completion well site based on Hadoop technology， and gives the specific implementation scheme and implementation results of this database system architecture.

Keywords： oil and gas exploration and development; offshore oil; big data; real time database; Hadoop

0? 引? 言

我國是油氣資源消費大國，但隨著消費的持續(xù)剛性增長，油氣生產(chǎn)供應保障能力不足。在此形勢下，我國油氣資源開發(fā)向深層、深水和非常規(guī)等領域拓展已成為推進油氣增儲上產(chǎn)、增強能源安全的必然選擇[1]。海洋油氣勘探開發(fā)是我國實現(xiàn)石油工業(yè)可持續(xù)發(fā)展的重要戰(zhàn)略接替區(qū)，同時也是保障國家能源安全、建設海洋強國的戰(zhàn)略需求[2]。

長期以來，由于海洋鉆井的高成本，在海上油氣勘探階段往往只有少量的探井數(shù)據(jù)來支撐油氣開發(fā)的目標評價，從而導致在海上油田開發(fā)項目實施之前，對地質(zhì)油藏的認識存在一定的不確定性。因此，在海洋石油勘探開發(fā)過程中必須實時獲取現(xiàn)場復雜的地質(zhì)情況信息。在此背景下，如何利用實時數(shù)據(jù)，提高實時決策的及時性和科學性，以提升油田的單井產(chǎn)量、最終采收率、鉆完井作業(yè)時效和油藏管理精細化水平，對增加勘探開發(fā)的經(jīng)濟效益具有重要的現(xiàn)實意義。

海上鉆完井井場實時數(shù)據(jù)[3，4]是指海上油氣勘探開發(fā)鉆完井過程中，由傳感器實時采集的工程地質(zhì)數(shù)據(jù)，包括鉆井數(shù)據(jù)、錄井數(shù)據(jù)、測井數(shù)據(jù)和測試數(shù)據(jù)。實時數(shù)據(jù)記錄的時間序列和深度序列實時信息，不僅可以用作實時監(jiān)測和決策分析，還可以用作大數(shù)據(jù)應用研究，是智能油田建設的重要數(shù)據(jù)基礎，也是實現(xiàn)智能分析、智能鉆井、隨鉆決策、生產(chǎn)運營一體化等應用場景的必要條件。

1? 架構分析

1.1? 傳統(tǒng)數(shù)據(jù)庫架構

傳統(tǒng)石油、電力工業(yè)領域對數(shù)據(jù)的實時處理是先通過OPC、Modbus等方式將數(shù)據(jù)采集上來，然后直接將數(shù)據(jù)存到關系型數(shù)據(jù)庫中。業(yè)務的實時計算是直接從關系型數(shù)據(jù)庫中取一段時間的數(shù)據(jù)或者取實時數(shù)據(jù)庫中的數(shù)據(jù)進行聚合及實時的統(tǒng)計分析。這種方式在數(shù)據(jù)傳輸、處理等任意一環(huán)出現(xiàn)問題都會導致數(shù)據(jù)丟失，同時也增大了數(shù)據(jù)庫的訪問壓力。具體來說，基于傳統(tǒng)數(shù)據(jù)庫架構的井場實時數(shù)據(jù)庫存在以下幾個方面的不足：

（1）數(shù)據(jù)傳輸方面。海上鉆井平臺通常采用wits0數(shù)據(jù)傳輸標準，傳統(tǒng)的數(shù)據(jù)傳輸系統(tǒng)在采集數(shù)據(jù)以后，需要先落盤存入數(shù)據(jù)庫，保存好以后再定時的向外循環(huán)發(fā)送，存在很大程度的延遲，實時性不足。

（2）數(shù)據(jù)安全方面。傳統(tǒng)數(shù)據(jù)庫架構通常采用單機版本的關系型數(shù)據(jù)庫SQLserver、Oracle等，在容錯方面支持得不是很好，在災備方面還需要離線的備份和恢復。

（3）數(shù)據(jù)存儲方面。傳統(tǒng)數(shù)據(jù)庫架構通常采用只能存儲近3年以內(nèi)的數(shù)據(jù)，而勘探開發(fā)大數(shù)據(jù)分析等需求往往需要10年以上歷史數(shù)據(jù)的支撐。同時，關系型數(shù)據(jù)庫只方便用來處理結構固定的表結構數(shù)據(jù)，不支持或者不擅長非結構化數(shù)據(jù)的存儲和處理。

（4）數(shù)據(jù)計算方面。傳統(tǒng)數(shù)據(jù)庫架構基于SQLserver、Oracle等關系型數(shù)據(jù)庫進行并發(fā)讀取，批量計算能力上存在不足。在數(shù)據(jù)量達到100萬以上需要開始優(yōu)化，一般會進行水平拆分，分表、分區(qū)和作業(yè)同步等操作，這樣做大大提高了邏輯的復雜性，難以維護，沒有多庫負載均衡并行計算功能。

（5）數(shù)據(jù)服務方面。傳統(tǒng)的數(shù)據(jù)庫架構往往采取單機部署發(fā)布形式，無法支撐高并發(fā)場景。

1.2? 基于Hadoop的架構

Hadoop具有高可擴展性和高容錯性等優(yōu)點[5-7]，能夠實現(xiàn)海量異構數(shù)據(jù)的低成本高效處理，可解決傳統(tǒng)實時數(shù)據(jù)庫架構的不足，主要體現(xiàn)在：

1.2.1? 實時計算和分布式存儲

海上鉆完井井場實時數(shù)據(jù)庫采取Kafka、Kudu、Hbase、Spark及Flink等組件，基于分布式架構，能夠同時支持實時計算和離線計算，主要體現(xiàn)在：

Kafka：分布式發(fā)布訂閱消息系統(tǒng)。在系統(tǒng)中用作于消息隊列，數(shù)據(jù)首先進入消息隊列，達到數(shù)據(jù)的緩沖、錯峰、解耦的功能。通過O（1）的磁盤數(shù)據(jù)結構提供消息的持久化，這種結構對于即使數(shù)以TB的消息存儲也能夠保持長時間的穩(wěn)定性能。高吞吐量的特點確保了即使是非常普通的硬件Kafka也可以支持每秒數(shù)百萬的消息。

Kudu：分布式存儲系統(tǒng)。Kudu獨立于HDFS，具有自有的管理存儲數(shù)據(jù)文件系統(tǒng)，在系統(tǒng)中主要使用是存儲結構化數(shù)據(jù)的大量數(shù)據(jù)。采用副本方式保證數(shù)據(jù)安全，通過Raft協(xié)議來保證數(shù)據(jù)一致性。配合impala進行數(shù)據(jù)查詢做到數(shù)據(jù)秒級響應。

Hbase：分布式存儲系統(tǒng)。Hadoop HDFS為HBase提供了高可靠性的底層存儲支持，Hadoop MapReduce為HBase提供了高性能的計算能力，Zookeeper為HBase提供了穩(wěn)定服務和failover機制。

Spark：分布式內(nèi)存計算框架。比傳統(tǒng)的MapReduce速度提升100倍，在系統(tǒng)中主要適用于數(shù)據(jù)清洗和數(shù)據(jù)挖掘，在高并發(fā)低延遲方面表現(xiàn)非常出色，面對海量數(shù)據(jù)配合impala對數(shù)據(jù)查詢寫入性能非常好。Spark在實時數(shù)據(jù)方面提供了對數(shù)據(jù)流的處理加工功能，在歷史數(shù)據(jù)處理方面能夠提取批量數(shù)據(jù)進行二次清洗，性能非常出色。

Flink：阿里提供的分布式開源計算框架。相對于批流一體的設計架構使用起來更加方便，在系統(tǒng)中主要的作用是實現(xiàn)對實時數(shù)據(jù)的質(zhì)量進行動態(tài)的監(jiān)控，以及實現(xiàn)單位時間數(shù)據(jù)寫入量的條數(shù)計算對比檢查等工作。

1.2.2? 高擴展性

Hadoop架構在可用的計算機集簇間分配數(shù)據(jù)并完成計算任務，這些集簇可以方便地擴展到數(shù)以千計的節(jié)點中。面對海上勘探開發(fā)數(shù)據(jù)量日益增加，磁盤的容量要求會不斷增加，因此采用具備分布式特性的Hadoop存儲架構，在增加硬盤的時候全部采用動態(tài)擴展空間，在不中斷業(yè)務的同時進行數(shù)據(jù)存儲擴容。同時，在計算能力方面，分布式架構在指標閾值出現(xiàn)需要增加計算節(jié)點的情況下，同樣也采取不中斷業(yè)務的設計架構動態(tài)橫向地對計算節(jié)點進行添加，可以瞬間滿足計算的需要。

1.2.3? 高效性

Hadoop架構能夠在節(jié)點之間動態(tài)地移動數(shù)據(jù)，并保證各個節(jié)點的動態(tài)平衡，因此處理速度非常快。Hadoop的高效性主要體現(xiàn)在：

（1）在數(shù)據(jù)存儲過程中，Hadoop系統(tǒng)架構把所有的數(shù)據(jù)根據(jù)規(guī)定隨機寫入不同的存儲節(jié)點，以達到數(shù)據(jù)寫入均衡;

（2）Hadoop系統(tǒng)架構在存儲管理中會定期檢查存儲的數(shù)據(jù)大小，進行數(shù)據(jù)均衡操作，達到歷史數(shù)據(jù)的均衡;

（3）由于Hadoop系統(tǒng)架構中全部采用萬兆網(wǎng)絡互聯(lián)技術，再加上系統(tǒng)的參數(shù)設定，數(shù)據(jù)在節(jié)點之間互相流動的效率性能非常高。因此，Hadoop架構在數(shù)據(jù)提取計算的過程中不會出現(xiàn)數(shù)據(jù)傾斜或是熱點數(shù)據(jù)節(jié)點的情況，避免資源不均衡。

（4）高容錯性。Hadoop架構能夠自動保存數(shù)據(jù)的多個副本，并且能夠自動將失敗的任務重新分配。在存儲方面，Kudu具備的副本平衡機制，能夠通過 Raft 協(xié)議來保證數(shù)據(jù)一致性，副本數(shù)量一般采用1、3、5等基數(shù)數(shù)量，當副本數(shù)量少于設定的數(shù)量的時候系統(tǒng)會自動進行副本均衡。Hbase依賴于HDFS，同樣也是通過副本形式保證數(shù)據(jù)安全性，使用均衡副本機架感知等技術進行數(shù)據(jù)平衡。此外，在Hadoop架構進行分布式計算的時候，一旦發(fā)現(xiàn)副本不可用的情況，Hadoop架構系統(tǒng)將自動切換重啟任務，獲取均衡后可用副本進行數(shù)據(jù)讀取使用。

1.3? 架構對比

海上鉆完井井場實時數(shù)據(jù)庫的高性能要求主要體現(xiàn)在數(shù)據(jù)寫入頻率高、查詢展示實時性要求高、實時數(shù)據(jù)的查詢展示要求秒級響應、對外提供數(shù)據(jù)服務的訪問并發(fā)性高和響應時間短等方面;計算能力要求高則主要體現(xiàn)在實時數(shù)據(jù)產(chǎn)生頻率高，且需要長期保存，要求數(shù)據(jù)庫具有海量數(shù)據(jù)處理能力并具有復雜SQL計算能力。

針對井場實時數(shù)據(jù)庫需求，Hadoop架構可在如下幾個方面解決傳統(tǒng)實時數(shù)據(jù)庫方案存在的不足，如表1所示。

2? 海上鉆完井井場實時數(shù)據(jù)庫設計

2.1? 總體架構

總體架構如圖1所示。

海上鉆完井井場實時數(shù)據(jù)庫全面采集4大類業(yè)務數(shù)據(jù)，通過Web Service傳輸給Kafka，實時數(shù)據(jù)進入Kafka消息隊列后緩存起來，由SparkStreaming主動地從消息隊列獲取，然后保存到Kudu/HBase中。最終利用Restful接口，對外提供滿足Wits0、WitsML傳輸協(xié)議的數(shù)據(jù)服務。

上述各環(huán)節(jié)都會產(chǎn)生很多作業(yè)，各作業(yè)之間存在依賴關系。實時數(shù)據(jù)庫系統(tǒng)需要對這些作業(yè)進行管理，因此需要具備任務調(diào)度、任務監(jiān)控和日志管理功能。

2.2? 數(shù)據(jù)采集架構

數(shù)據(jù)采集架構如圖2所示。

數(shù)據(jù)采集關鍵技術采用Kafka消息隊列技術，Kafka消息隊列本身具有高吞吐、低延遲以及彈性擴展的特點，配合Spark Streaming計算框架能夠保證數(shù)據(jù)傳輸?shù)膶崟r性。Kafka本身無狀態(tài)，實時數(shù)據(jù)進入隊列后緩存起來，由SparkStreaming主動地從隊列獲取，這樣就避免了當Spark Streaming故障導致數(shù)據(jù)丟失的問題;Kafka能夠對消息隊列進行消息分區(qū)，分區(qū)后的消息隊列能夠讓SparkStreaming用多個消費進程并行地進行數(shù)據(jù)消費，可以大大提高數(shù)據(jù)傳輸?shù)乃俾省?/p>

對于實時數(shù)據(jù)，使用Web Service接入陸上數(shù)據(jù)庫，然后再次通過Web Service傳給Kafka，由SparkStreaming主動地從Kafka消息隊列獲取數(shù)據(jù)后，最終把實時數(shù)據(jù)存入Kudu/HBase數(shù)據(jù)庫。

2.3? 數(shù)據(jù)存儲架構

數(shù)據(jù)存儲架構如圖3所示。

由于實時數(shù)據(jù)體量巨大，而且需要快速響應，因此選擇采用基于X86集群的分布式存儲架構（Kudu/ HBase），從而滿足大容量、多樣化數(shù)據(jù)的低成本存儲需求。

利用Kudu/HBase的分布式架構能夠彈性擴展，滿足海量數(shù)據(jù)的存儲，內(nèi)部三副本的機制能夠避免機器故障帶來的數(shù)據(jù)丟失。Kudu的批量寫入特性，能夠在大吞吐的情況迅速高效地將數(shù)據(jù)落地入庫;HBase的海量數(shù)據(jù)高速查詢特性能夠支撐億級數(shù)據(jù)查詢的秒級響應。同時，根據(jù)數(shù)據(jù)存儲和使用較頻繁的業(yè)務場景，設計主鍵或者RowKey，優(yōu)化各項參數(shù);并使用緩存機制，減少磁盤IO操作等。通過這些性能優(yōu)化措施，海上鉆完井井場實時數(shù)據(jù)庫完全能夠支撐對外數(shù)據(jù)服務的需求。

2.4? 數(shù)據(jù)處理架構

數(shù)據(jù)處理與計算如圖4所示。

數(shù)據(jù)處理主要是將數(shù)據(jù)輸入到處理器，通過一系列去重、轉換、校核等步驟的“處理”工作，然后以期望的格式輸出處理過的數(shù)據(jù)。它從數(shù)據(jù)的準確性、完整性、一致性、唯一性、適時性、有效性幾個方面來解決數(shù)據(jù)的丟失值、越界值、不一致代碼、重復數(shù)據(jù)等問題。

2.5? 數(shù)據(jù)服務架構

數(shù)據(jù)服務架構如圖5所示。海上鉆完井井場實時數(shù)據(jù)管理系統(tǒng)采用Restful API接口開發(fā)，滿足Wits0、WitsML井場傳輸協(xié)議對外提供數(shù)據(jù)服務。這些數(shù)據(jù)服務主要分為批量數(shù)據(jù)服務和實時數(shù)據(jù)服務。其他應用系統(tǒng)可以通過調(diào)取這些數(shù)據(jù)服務，共享海上鉆完井井場實時數(shù)據(jù)資源。

利用標準通用的Restful API和gRPC技術定制化開發(fā)實時數(shù)據(jù)的數(shù)據(jù)服務，便捷的URL訪問和gRPC服務調(diào)用，能夠實現(xiàn)一次開發(fā)，多次調(diào)用，從而支撐廣泛的業(yè)務場景;并利用公司內(nèi)部數(shù)據(jù)服務平臺，對數(shù)據(jù)服務進行申請、審核、審批、發(fā)布和監(jiān)控等全生命周期管理。

3? 海上鉆完井井場實時數(shù)據(jù)庫的實現(xiàn)與成效

海上鉆完井井場實時數(shù)據(jù)庫實施方案的總體思路是將實時數(shù)據(jù)經(jīng)海上鉆井平臺匯總后，傳輸至陸上數(shù)據(jù)庫，再利用企業(yè)端實時數(shù)據(jù)庫將其采集存儲。利用Web Service將鉆井平臺采集數(shù)據(jù)推送至陸上數(shù)據(jù)庫，然后將數(shù)據(jù)推送至Kafka工具，最終存儲至Kudu/HBase中，對外提供數(shù)據(jù)服務。其中，在鉆井平臺端，開發(fā)完善實時數(shù)據(jù)傳輸接口，采用Wits0協(xié)議，通過Web Service把實時數(shù)據(jù)傳輸?shù)疥懮蠑?shù)據(jù)庫;接著對陸上數(shù)據(jù)庫的實時數(shù)據(jù)接口進行封裝，把實時數(shù)據(jù)推送給企業(yè)端實時數(shù)據(jù)庫。主要技術是利用ETL工具開發(fā)抽取工具，抽取的實時數(shù)據(jù)并寫入Kafka消息隊列緩存，編寫Kafka消費端讀取數(shù)據(jù)，然后寫入Kudu/HBase中，最終統(tǒng)一對外提供數(shù)據(jù)服務?？傮w實施方案如圖6所示。

當前，本文提出的海上鉆完井井場實時數(shù)據(jù)庫架構已在某能源企業(yè)成功實施，并在降低數(shù)據(jù)庫故障率、提升系統(tǒng)效率、提高歷史數(shù)據(jù)存儲時限等方面取得了顯著的成效。具體體現(xiàn)在：

（1）降低數(shù)據(jù)庫故障率?；贖adoop的海上鉆完井井場實時數(shù)據(jù)庫在數(shù)據(jù)的傳輸方面提供了高可用集群方式進行架構部署的消息隊列方式，無單點故障，在傳輸過程中采用SparkStreaming方式進行流式計算，計算過程中通過數(shù)據(jù)檢查點和記錄數(shù)據(jù)的更新，保證數(shù)據(jù)容錯不會丟失數(shù)據(jù)，從而降低了停止服務的故障率;同時，利用分布式存儲采用副本策略保證數(shù)據(jù)安全，若是副本丟失，系統(tǒng)會及時地通過算法補充上丟失副本，保障數(shù)據(jù)健康狀態(tài)，在此過程中數(shù)據(jù)服務不會停滯，這種分布式存儲大大降低了故障導致的數(shù)據(jù)服務不可用的情況?；谝陨戏植际郊軜?，井場實時數(shù)據(jù)庫整體故障率較傳統(tǒng)數(shù)據(jù)庫故障率下降60%。

（2）提升運行效率。首先，在傳統(tǒng)的實時數(shù)據(jù)庫系統(tǒng)需先落盤再定期提供服務，數(shù)據(jù)寫入后再讀取進行服務會存在延遲現(xiàn)象?；贖adoop的海上鉆完井井場實時數(shù)據(jù)庫全部采用流方式進行數(shù)據(jù)服務，不考慮網(wǎng)絡因素可以做到秒級響應，整體效率提升80%。

其次，傳統(tǒng)的實時數(shù)據(jù)庫系統(tǒng)使用單臺服務器，在大數(shù)據(jù)獲取并發(fā)計算的需求時性能和計算能力明顯不足?；贖adoop的海上鉆完井井場實時數(shù)據(jù)庫采用了分布式集群架構，在數(shù)據(jù)存儲方面采用分布式架構常用的副本方式保證數(shù)據(jù)的安全可用，同時由于采用當前技術先進的存儲和計算平臺，在存儲容量，存儲時間以及讀取數(shù)據(jù)計算的功能方面達到了領先水平，在系統(tǒng)的存儲效率上得到提升，在存儲成本方面大大降低。理論上可拓展支持到PT級別數(shù)據(jù)。

（3）提升歷史數(shù)據(jù)存儲時限。傳統(tǒng)的實時數(shù)據(jù)庫架構在存儲數(shù)據(jù)的時間周期方面非常受限制，這主要是由傳統(tǒng)架構的服務器存儲硬盤大小及操作系統(tǒng)對硬盤支持大小的所導致的。企業(yè)在目前只能存儲將近3年的完整數(shù)據(jù)，如需要歷史數(shù)據(jù)可能需要離線數(shù)據(jù)進行手動回復，增加了操作難度，費時費力?；贖adoop的實時數(shù)據(jù)庫架構在數(shù)據(jù)存儲方面采用分布式存儲，把寫入的壓力分散到集群不同的存儲節(jié)點上，大大提高了存儲的并發(fā)能力，可以隨時橫向增加服務器存儲動態(tài)擴容的功能，數(shù)據(jù)可以長時間大容量的保存，實測存儲節(jié)點可以達到2 000臺服務器。在實施基于Hadoop架構的海上鉆完井井場實時數(shù)據(jù)庫之后，隸屬數(shù)據(jù)存儲將由傳統(tǒng)系統(tǒng)的短期臨時存儲提升到無限拓展的長時限存儲。

4? 結? 論

文章設計一種基于Hadoop的海上鉆完井井場實時數(shù)據(jù)庫，通過Kafka、Web Service、SparkStreaming等技術實現(xiàn)秒級的數(shù)據(jù)實時采集傳輸;通過現(xiàn)場傳輸服務器建立數(shù)據(jù)通信，接收數(shù)據(jù)后存儲于基于Hadoop環(huán)境架構的實時數(shù)據(jù)庫中;對外支持Socket和Restful API接口方式的數(shù)據(jù)服務，并支持Wits0和WitsML兩種井場傳輸協(xié)議。該系統(tǒng)的實施，能夠從全局提供涵蓋鉆、錄、測、試四大業(yè)務數(shù)據(jù)采集、存儲、管理、服務等全流程的一體化解決方案，覆蓋鉆完井作業(yè)全生命周期，確保海上鉆完井井場實時數(shù)據(jù)的高效采集、無縫流轉、統(tǒng)一管理和互聯(lián)共享。

基于Hadoop技術的海上鉆完井井場實時數(shù)據(jù)庫建設，將有利于在海上油氣勘探開發(fā)環(huán)節(jié)進行實時診斷、精準預測和高效決策，有效支撐鉆完井風險預測分析系統(tǒng)，以減少復雜井況及事故，實現(xiàn)作業(yè)風險防控，為基于大數(shù)據(jù)分析的虛擬地球物理、智能勘探、智能工程建設、智能化生產(chǎn)、智能化設備等應用領域提供強大的多模式實時數(shù)據(jù)服務能力。該架構具有良好的推廣應用前景，可廣泛應用于各類海上油氣勘探信息化應用。

參考文獻：

[1] 王陸新，潘繼平，楊麗麗.全球深水油氣勘探開發(fā)現(xiàn)狀與前景展望 [J].石油科技論壇，2020，39（2）：31-37.

[2] SINGHAL M.Issues and approaches to design of real-time database systems [J].SIGMOD Record，1988，17（1）：19-33.

[3] 陳錫榮.中國石化產(chǎn)業(yè)發(fā)展趨勢研究 [J].現(xiàn)代化工，2019，39（6）：1-5.

[4] 李陽，廉培慶，薛兆杰，等.大數(shù)據(jù)及人工智能在油氣田開發(fā)中的應用現(xiàn)狀及展望 [J].中國石油大學學報（自然科學版），2020，44（4）：1-11.

[5] DEAN J. MapReduce：Simplified Data Processing on Large Clusters [J].Symposium on Operating System Design & Implementation，2008，51（1）：107-113.

[6] GHEMAWAT S，GOBIOFF H，LEUNG S T.The Google File System [J].ACM SIGOPS Operating Systems Review ACM，2003，37（5）：29-43.

[7] CHANG F，DEAN J，GHEMAWAT S，et al. Bigtable：a distributed storage system for structured data [C]//USENIX Symposium on Operating System Design and Implementation （OSDI06）.Seattle：USENIX：2006：205-218.

作者簡介：吳凡（1988—），男，漢族，黑龍江慶安人，工程師，碩士研究生，研究方向：石油地質(zhì)、數(shù)字技術應用以及數(shù)據(jù)管理;高健祎（1992—），女，漢族，黑龍江哈爾濱人，中級工程師，碩士研究生，研究方向：數(shù)據(jù)管理及平臺建設;謝洪路（1984—），男，漢族，天津人，工程師，本科，研究方向：錄井工程及油氣勘探開發(fā)信息化;逄勃（1981—），男，漢族，遼寧東港人，高級工程師，博士研究生，研究方向：大數(shù)據(jù)、自動控制、人工智能。