基于Hadoop的海上鉆完井井場實(shí)時(shí)數(shù)據(jù)庫設(shè)計(jì)與實(shí)現(xiàn)

吳凡 高健祎 謝洪路 逄勃

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

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

中圖分類號：TP311? ? ? ?文獻(xiàn)標(biāo)識碼：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? 引? 言

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

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

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

1? 架構(gòu)分析

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

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

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

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

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

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

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

1.2? 基于Hadoop的架構(gòu)

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

1.2.1? 實(shí)時(shí)計(jì)算和分布式存儲

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

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

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

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

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

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

1.2.2? 高擴(kuò)展性

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

1.2.3? 高效性

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

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

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

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

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

1.3? 架構(gòu)對比

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

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

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

2.1? 總體架構(gòu)

總體架構(gòu)如圖1所示。

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5? 數(shù)據(jù)服務(wù)架構(gòu)

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

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

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

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

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

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

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

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

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

4? 結(jié)? 論

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

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

參考文獻(xiàn)：

[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ā)中的應(yīng)用現(xiàn)狀及展望 [J].中國石油大學(xué)學(xué)報(bào)（自然科學(xué)版），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ù)應(yīng)用以及數(shù)據(jù)管理;高健祎（1992—），女，漢族，黑龍江哈爾濱人，中級工程師，碩士研究生，研究方向：數(shù)據(jù)管理及平臺建設(shè);謝洪路（1984—），男，漢族，天津人，工程師，本科，研究方向：錄井工程及油氣勘探開發(fā)信息化;逄勃（1981—），男，漢族，遼寧東港人，高級工程師，博士研究生，研究方向：大數(shù)據(jù)、自動控制、人工智能。