鈾礦勘查數(shù)據(jù)湖分布式存儲和計(jì)算系統(tǒng)構(gòu)建＊

孫遠(yuǎn)強(qiáng) 蔡煜琦 李曉翠 孫雨鑫 金鑫裕

1.核工業(yè)北京地質(zhì)研究院；2.中國地質(zhì)大學(xué)（北京）

本文在梳理和分析當(dāng)前主流數(shù)據(jù)湖大數(shù)據(jù)平臺技術(shù)體系構(gòu)成的基礎(chǔ)上，根據(jù)鈾礦勘查數(shù)據(jù)來源、數(shù)據(jù)類型、數(shù)據(jù)結(jié)構(gòu)等特征，選擇PostgreSQL（關(guān)系型數(shù)據(jù)庫）+MongoDB（非結(jié)構(gòu)化數(shù)據(jù)庫）+Ceph（存儲組件）+Kafka（消息隊(duì)列）+Spark（計(jì)算組件）等搭建鈾礦勘查數(shù)據(jù)湖大數(shù)據(jù)技術(shù)平臺。該平臺即適用于地震、電磁、重力等體量巨大，又適用于地質(zhì)圖件、鉆孔數(shù)據(jù)、化驗(yàn)分析測試等多源異構(gòu)數(shù)據(jù)的存儲；Spark 計(jì)算引擎即可以處理離線數(shù)據(jù)又可以處理實(shí)時(shí)流數(shù)據(jù)的分析，滿足鉆孔數(shù)據(jù)分析，物化探數(shù)據(jù)反演，遙感蝕變提取，成礦預(yù)測分析及鉆探進(jìn)尺統(tǒng)計(jì)等勘查業(yè)務(wù)的應(yīng)用。

我國鈾礦資源經(jīng)過近幾十年的勘查和研究工作，積累了大量數(shù)據(jù)資料，這些資料多源異構(gòu)、格式多樣。從來源來看，不同勘查手段獲得的數(shù)據(jù)源不同，如地質(zhì)觀察、測量、鉆探、槽探、物化探、遙感等數(shù)據(jù)；從存儲形式看，有紙質(zhì)格式（成果報(bào)告、圖紙、附表）和電子表格，后者又可分為Word、Excel、TXT、MapGIS、AutoCAD 等；從數(shù)據(jù)的空間分布看，來自不同的鈾成礦帶、鈾礦床、鈾礦化點(diǎn)、成礦遠(yuǎn)景區(qū)等；從勘查主體看，來自不同的研究院、勘查大隊(duì)、研究所和檔案館等；部分鈾礦數(shù)據(jù)來自不同行業(yè)，如煤炭、石油、有色等行業(yè)。如何開展這些數(shù)據(jù)的轉(zhuǎn)換集成，完成多源異構(gòu)數(shù)據(jù)的融合，實(shí)現(xiàn)應(yīng)用預(yù)測是當(dāng)前鈾礦領(lǐng)域最重要的需求之一。鑒于此，急需開展勘查領(lǐng)域數(shù)據(jù)湖的建設(shè)。

數(shù)據(jù)湖（DataLake）的概念是Pentaho 公司（開源商業(yè)智能軟件公司）的創(chuàng)始人兼首席技術(shù)官詹姆斯·狄克遜(James Dixon)在2010 年首次提出，2011 年丹·伍茲（Dan Woods）在福布斯發(fā)表“大數(shù)據(jù)需要更大的新架 構(gòu) ”（Big Data Requires a Big New Architecture）的文章，數(shù)據(jù)湖技術(shù)開始在各類企業(yè)公司廣泛應(yīng)用。它可以存儲結(jié)構(gòu)化數(shù)據(jù)、半結(jié)構(gòu)化數(shù)據(jù)、非結(jié)構(gòu)化數(shù)據(jù)和二進(jìn)制數(shù)據(jù)等多種數(shù)據(jù)類型，并且能夠?qū)崿F(xiàn)原始數(shù)據(jù)與轉(zhuǎn)換后的數(shù)據(jù)統(tǒng)一存儲，如用于數(shù)據(jù)可視化、數(shù)據(jù)分析和機(jī)器學(xué)習(xí)的數(shù)據(jù)。隨著信息技術(shù)、大數(shù)據(jù)、云計(jì)算、軟件算法的高速發(fā)展，為適應(yīng)日益復(fù)雜的數(shù)據(jù)結(jié)構(gòu)和業(yè)務(wù)應(yīng)用環(huán)境，加快數(shù)據(jù)應(yīng)用的部署速度，數(shù)據(jù)湖技術(shù)的應(yīng)用逐漸成為各類企業(yè)大數(shù)據(jù)運(yùn)營管理的重要手段和趨勢。杜金虎（2020）在中國石油上游業(yè)務(wù)信息化建設(shè)總體藍(lán)圖中提出主數(shù)據(jù)湖和區(qū)域數(shù)據(jù)湖應(yīng)用，通過連環(huán)湖架構(gòu)，建立分級的數(shù)據(jù)存儲與服務(wù)架構(gòu)，實(shí)現(xiàn)數(shù)據(jù)邏輯統(tǒng)一、分布存儲、互聯(lián)互通、就近訪問的開放數(shù)據(jù)生態(tài)系統(tǒng)[1]。馬馳（2022）設(shè)計(jì)實(shí)現(xiàn)了一種基于Lambda 的飛機(jī)運(yùn)行支持?jǐn)?shù)據(jù)湖系統(tǒng)，解決了傳統(tǒng)數(shù)據(jù)庫、數(shù)據(jù)倉庫無法滿足航空數(shù)據(jù)指數(shù)級增長、豪秒級攝取、多維度應(yīng)用的問題，為主制造商開展數(shù)據(jù)集中式數(shù)據(jù)管理，實(shí)現(xiàn)數(shù)字化轉(zhuǎn)型提供支撐[2]。張蕓（2021）闡述了石油勘探行業(yè)數(shù)據(jù)湖建設(shè)中的數(shù)據(jù)治理問題，解決了不同數(shù)據(jù)源在數(shù)據(jù)湖中的集成問題、非結(jié)構(gòu)化和結(jié)構(gòu)化數(shù)據(jù)管理問題、數(shù)據(jù)系統(tǒng)切換問題和數(shù)據(jù)同步原ID 記錄機(jī)制[3]。劉志勇（2021）在“新基建”基礎(chǔ)上對中國電信統(tǒng)一數(shù)據(jù)湖做了有益探索和實(shí)踐，為31 省市大數(shù)據(jù)平臺/數(shù)據(jù)倉庫/ODS 建立了包括IaaS、PaaS、DaaS 能力的扎實(shí)“底座”[4]。數(shù)據(jù)湖平臺在商業(yè)貿(mào)易、交通運(yùn)輸、信息通信、油氣勘查與開發(fā)等領(lǐng)域?qū)嵤┝藨?yīng)用[5-7]，在鈾礦地質(zhì)行業(yè)僅有少量科研項(xiàng)目開展示范性研究和探索性應(yīng)用[8]。

針對鈾礦勘查領(lǐng)域的地物化遙等不同勘查手段產(chǎn)生的數(shù)據(jù)結(jié)構(gòu)特征，為解決該類多源異構(gòu)數(shù)據(jù)的存儲需求，本文提出鈾礦勘查數(shù)據(jù)湖環(huán)境搭建所需要的基礎(chǔ)構(gòu)件和技術(shù)平臺：（1）存儲管理組件；（2）數(shù)據(jù)計(jì)算組件；（3）作為數(shù)據(jù)來源的數(shù)據(jù)庫組件。經(jīng)過對比分析和適用性研究，精心選擇PostgreSQL（關(guān)系型數(shù)據(jù)）+MongoDB（非結(jié)構(gòu)化數(shù)據(jù)庫）+Ceph（存儲組件）+Kafka（消息隊(duì)列）+Spark（計(jì)算組件）等不同組件集成適用于鈾礦勘查數(shù)據(jù)湖的大數(shù)據(jù)平臺。

1 數(shù)據(jù)湖架構(gòu)

以處理大型數(shù)據(jù)集，包括結(jié)構(gòu)化、半結(jié)構(gòu)化或非結(jié)構(gòu)化數(shù)據(jù)，為主的一組軟件組件構(gòu)成了分布式大數(shù)據(jù)平臺。這類平臺隨時(shí)間推移演進(jìn)了以Hadoop 為代表的第一代離線數(shù)據(jù)平臺、Lambda 架構(gòu)的第二代平臺、Kappa架構(gòu)的第三代平臺和最新一代的數(shù)據(jù)湖大數(shù)據(jù)技術(shù)平臺。目前最主流的三大開源數(shù)據(jù)湖方案分別為：Databricks公司的Delta 數(shù)據(jù)湖架構(gòu)、Uber 公司的Hudi 數(shù)據(jù)湖架構(gòu)和Netflix 公司的Iceberg 數(shù)據(jù)湖架構(gòu)?；阝櫟V勘查的數(shù)據(jù)特征和勘查業(yè)務(wù)發(fā)展的需求，搭建以PostgreSQL+MongoDB+Ceph+Kafka+Spark 為組件的鈾礦勘查數(shù)據(jù)湖大數(shù)據(jù)技術(shù)平臺。

1.1 數(shù)據(jù)湖概念模型

鈾礦勘查數(shù)據(jù)湖從硬件、軟件和網(wǎng)絡(luò)環(huán)境的需求分析，它需要支撐的軟件平臺包括存儲組件、計(jì)算組件、數(shù)據(jù)治理組件以及作為數(shù)據(jù)來源的數(shù)據(jù)庫組件等。在此基礎(chǔ)上可以開展鈾礦勘查業(yè)務(wù)應(yīng)用，諸如鉆孔數(shù)據(jù)分析應(yīng)用、地球化學(xué)數(shù)據(jù)集成應(yīng)用、重磁電震數(shù)據(jù)提取應(yīng)用、成果可視化表達(dá)應(yīng)用等。確保該類業(yè)務(wù)應(yīng)用順利開展的兩條主線是質(zhì)量控制和安全審計(jì)。實(shí)現(xiàn)數(shù)據(jù)實(shí)體存儲和流轉(zhuǎn)的服務(wù)器和網(wǎng)絡(luò)通信設(shè)備?；趯?shù)據(jù)湖平臺構(gòu)建邏輯的梳理，本文提出鈾礦勘查數(shù)據(jù)湖概念模型（如圖1所示），為搭建鈾礦勘查數(shù)據(jù)湖大數(shù)據(jù)技術(shù)平臺提供概念和邏輯支撐。

圖1 鈾礦勘查數(shù)據(jù)湖概念模型圖Fig.1 Conceptual model of uranium exploration data Lake

1.2 數(shù)據(jù)湖技術(shù)架構(gòu)

數(shù)據(jù)湖大數(shù)據(jù)平臺的技術(shù)實(shí)現(xiàn)包括數(shù)據(jù)交互、質(zhì)量檢查、數(shù)據(jù)存儲、數(shù)據(jù)分析與發(fā)現(xiàn)、元數(shù)據(jù)管理等環(huán)節(jié)（如圖2 所示）。

圖2 鈾礦勘查數(shù)據(jù)湖技術(shù)架構(gòu)Fig.2 Technical architecture of uranium exploration data lake

1.2.1 數(shù)據(jù)交互（Data Ingesting）

凡數(shù)據(jù)入湖對象，均以元數(shù)據(jù)標(biāo)準(zhǔn)化模型為依據(jù)，啟用相應(yīng)的校驗(yàn)規(guī)則和質(zhì)量驗(yàn)證，可深度影響或者關(guān)聯(lián)原始數(shù)據(jù)的形態(tài)，同時(shí)打上明確的標(biāo)簽和版本。

在數(shù)據(jù)治理的整體體系中，能夠依據(jù)元數(shù)據(jù)管理模型，及主數(shù)據(jù)的規(guī)則文件，快速的洞察數(shù)據(jù)的質(zhì)量，識別其數(shù)據(jù)風(fēng)險(xiǎn)，并在必要節(jié)點(diǎn)（按預(yù)定義的自動(dòng)化流程）觸發(fā)數(shù)據(jù)的治理流程。

能夠?qū)τ诮尤氲臄?shù)據(jù)質(zhì)量進(jìn)行實(shí)時(shí)管控?？商峁?shù)據(jù)字段校驗(yàn)、數(shù)據(jù)完整性分析等功能；同時(shí)，可監(jiān)控?cái)?shù)據(jù)處理任務(wù)，避免未執(zhí)行完成任務(wù)生成不完備的數(shù)據(jù)。

1.2.2 原始數(shù)據(jù)（數(shù)據(jù)存儲）

基于原始數(shù)據(jù)，會依照元數(shù)據(jù)標(biāo)準(zhǔn)模型，通過數(shù)據(jù)湖里的既定工作流引擎對其進(jìn)行有針對性的數(shù)據(jù)清洗、轉(zhuǎn)換、并回寫數(shù)據(jù)目錄。

1.2.3 數(shù)據(jù)聚合（數(shù)據(jù)發(fā)現(xiàn)與分析）

針對文本、視頻、音頻、圖片、文字及其他一些固定格式文件，通過預(yù)定義模型所進(jìn)行的數(shù)據(jù)挖掘（Data Mining）和分析，且可將其分析或發(fā)覺的成果，或回寫，或更新數(shù)據(jù)目錄。

使其數(shù)據(jù)的脈絡(luò)（血緣）、層次，關(guān)系更加的清晰，為進(jìn)一步的可視化展示及智能化應(yīng)用方面的實(shí)現(xiàn)，提供切實(shí)、可靠的依據(jù)。同時(shí)，兼具對最終學(xué)術(shù)科研成果等隱性知識的顯化功能。

1.2.4 元數(shù)據(jù)管理

通過對元數(shù)據(jù)所采取的管理措施，對于數(shù)據(jù)的入湖動(dòng)作，盡可能的采取智能化入湖操作，即可按照預(yù)先定義模式，將極少的人為干預(yù)或者完全不需要人為干預(yù)進(jìn)行數(shù)據(jù)入湖工作。

1.3 數(shù)據(jù)湖數(shù)據(jù)架構(gòu)

鈾礦勘查數(shù)據(jù)湖的數(shù)據(jù)架構(gòu)由數(shù)據(jù)計(jì)算、數(shù)據(jù)存儲、數(shù)據(jù)源等3 個(gè)獨(dú)立而又相互聯(lián)系的功能組件組成。數(shù)據(jù)架構(gòu)可以實(shí)現(xiàn)對數(shù)據(jù)源的統(tǒng)一抽取與遷移、數(shù)據(jù)集中存儲與分析、數(shù)據(jù)質(zhì)量的統(tǒng)一治理，同時(shí)支持?jǐn)?shù)據(jù)智能分析及數(shù)據(jù)內(nèi)容的共享應(yīng)用（如圖3 所示）。

圖3 鈾礦勘查數(shù)據(jù)湖數(shù)據(jù)架構(gòu)Fig.3 Data architecture of uranium exploration data lake

2 基礎(chǔ)組件

2.1 存儲組件

近幾十年來，數(shù)據(jù)存儲由直連存儲、中心化存儲，發(fā)展到分布式存儲的階段。直連存儲是存儲和數(shù)據(jù)直接連通，表現(xiàn)為拓展性和靈活性較差；中心化存儲是通過IP/FC 網(wǎng)絡(luò)互通互連，存儲設(shè)備類型多樣化，具有一定的擴(kuò)展性和拓展性，但數(shù)據(jù)遷移成本較高；分布式存儲是基于標(biāo)準(zhǔn)分布式架構(gòu)系統(tǒng)和標(biāo)準(zhǔn)硬件設(shè)備，實(shí)現(xiàn)千節(jié)點(diǎn)級別的擴(kuò)展，同時(shí)可以統(tǒng)一管理塊類型、對象類型和文件類型的存儲。目前，分布式存儲框架包括Hadoop Distributed File System（HDFS）、OpenStack Object Storage（Swift）、Ceph 等。每一種分布式存儲技術(shù)都有各自的特點(diǎn)和應(yīng)用場景，由于鈾礦勘查數(shù)據(jù)多為數(shù)量巨多的小文件，且結(jié)構(gòu)化和非結(jié)構(gòu)化并存，因此選擇Ceph式分布存儲框架。其可以實(shí)現(xiàn)塊存儲、文件存儲和對象存儲。Ceph 的核心組件有Ceph Monitor、Ceph MDS和Ceph OSD，它們架構(gòu)分布如圖4 所示。

圖4 Ceph 分布式框架的主要組件Fig.4 The main components of the Ceph distributed framework

（1）Ceph OSD 作為對象存儲設(shè)備（Object Storage Device），其主要功能是存儲數(shù)據(jù)、平衡數(shù)據(jù)、復(fù)制數(shù)據(jù)、恢復(fù)數(shù)據(jù)等，同時(shí)負(fù)責(zé)響應(yīng)客戶端請求返回具體數(shù)據(jù)的進(jìn)程。多個(gè)OSD 可以耦合到一個(gè)Ceph 集群，實(shí)現(xiàn)數(shù)據(jù)的海量規(guī)模存儲。

（2）Ceph MDS 作為元數(shù)據(jù)服務(wù)器（Ceph Meta Data Server），其主要保存文件系統(tǒng)服務(wù)的元數(shù)據(jù)，但對象存儲和塊存儲設(shè)備是不需要使用該服務(wù)的。

（3）Ceph Monitor 作為Ceph 的監(jiān)視器，負(fù)責(zé)管理Ceph 集群相關(guān)系統(tǒng)的健康狀態(tài)，集群內(nèi)的成員及其屬性和關(guān)系以及數(shù)據(jù)的分發(fā)都屬于監(jiān)視器的管理范疇。

Ceph 系統(tǒng)為了對OSD、Monitor、MDS 的管理和應(yīng)用協(xié)調(diào)，引入Reliable Autonomic Distributed Object Store(RADOS)系統(tǒng)，該系統(tǒng)又由5 部分組成（如圖5 所示），基于RADOS 層的是LIBRADOS，在LIBRADOS 之上又分為RADOSGW、RBD 和CEPH FS。LIBRADOS 作為一個(gè)內(nèi)置庫，外部應(yīng)用程序訪問該庫實(shí)現(xiàn)與RADOS系統(tǒng)交互通信；RADOSGW 是基于RESTFUL 協(xié)議的網(wǎng)關(guān)，與亞馬遜的S3 和Spark 的Swift 兼容，該層實(shí)現(xiàn)對象存儲；RBD 利用Linux 內(nèi)核客戶端和QEMU/KVM驅(qū)動(dòng)實(shí)現(xiàn)分布式的塊存儲；CEPH FS 利用Linux 內(nèi)核客戶端和FUSE 提供文件系統(tǒng)的功能。至此Ceph 實(shí)現(xiàn)了對象存儲、塊存儲和文件存儲。

圖5 Ceph 系統(tǒng)分層關(guān)系圖Fig.5 Hierarchical diagram of the Ceph system

2.2 計(jì)算組件

基于分布式框架的計(jì)算引擎主要有MapReduce、Spark、Storm、Flink 等。MapReduce 是Hadoop 分布式計(jì)算的核心組件，谷歌引入MapReduce 作為一種編程模型來促進(jìn)其搜索過程。Spark 于2009 年誕生于加州大學(xué)伯克利分校的AMP 實(shí)驗(yàn)室，并于2013 年捐獻(xiàn)給阿帕奇軟件基金會（Apache Software Foundation）作為開源代碼。Storm 是由Twitter 公司提出的處理實(shí)時(shí)大數(shù)據(jù)的流式計(jì)算的分布式框架。Flink 于2010 年起源于柏林大學(xué)的Stratosphere 項(xiàng)目，后期被阿里巴巴公司收購，它成為雙十一商業(yè)活動(dòng)大規(guī)模數(shù)據(jù)實(shí)時(shí)處理的利器。

基于鈾礦勘查數(shù)據(jù)分析與挖掘應(yīng)用實(shí)際情況，多以離線數(shù)據(jù)計(jì)算為主，對實(shí)時(shí)數(shù)據(jù)流的處理要求不高，因此選擇Spark 引擎作為鈾礦勘查數(shù)據(jù)湖的計(jì)算組件（如圖6 所示）。

圖6 Spark 分布式計(jì)算引擎主要組件Fig.6 The main components of the Spark distributed computing engine

（1）Spark Core 作為Spark 計(jì)算組件的核心，主要負(fù)責(zé)任務(wù)調(diào)度等管理功能。Spark Core 依賴彈性分布式數(shù)據(jù)集（Resilient Distributed Datasets,RDDs）實(shí)現(xiàn)分布式計(jì)算。

（2）Spark SQL 是處理結(jié)構(gòu)化數(shù)據(jù)的模塊，其支持SQL、HiveQL 等數(shù)據(jù)庫查詢及復(fù)雜算法的分析；還支持JDBC 和ODBC 連接，能夠直接連接現(xiàn)有的數(shù)據(jù)庫。

（3）Spark Streaming 支持流數(shù)據(jù)的可伸縮和容錯(cuò)處理，集成了Kafka 和Flume 平臺，前者提供消息隊(duì)列功能，后者實(shí)現(xiàn)日志數(shù)據(jù)優(yōu)化處理。該集成平臺使其為流數(shù)據(jù)的處理能夠更靈活，也更容易實(shí)現(xiàn)。

（4）MLlib 主要應(yīng)用于機(jī)器學(xué)習(xí)領(lǐng)域，實(shí)現(xiàn)了分類、回歸、聚類、主成分分析等相關(guān)算法。

（5）GraphX 可支持?jǐn)?shù)據(jù)圖的分析和計(jì)算，包含了許多被廣泛理解的圖形算法，并支持圖形處理的Pregel API 版本。

Spark 集群分為Master 節(jié)點(diǎn)和Worker 節(jié)點(diǎn)。Master節(jié)點(diǎn)管理其系統(tǒng)下的所有Worker 節(jié)點(diǎn)。Worker 節(jié)點(diǎn)負(fù)責(zé)與Master 節(jié)點(diǎn)信息通信并管理Executors。Driver 是用戶編寫的Spark 應(yīng)用程序的進(jìn)程，其可以在Master 和Worker 節(jié)點(diǎn)上同時(shí)運(yùn)行（如圖7 所示）。

圖7 Spark 分布式計(jì)算引擎工作原理（據(jù)spark.apache.org 修改）Fig.7 Working principle diagram of the spark distributed computing engine (after spark.apache.org)

Spark 在一個(gè)節(jié)點(diǎn)上計(jì)算的流程：Master 定時(shí)檢查與接收任意Worker 節(jié)點(diǎn)的發(fā)送消息，然后將消息保存起來，并向Worker 返回一個(gè)注冊成功的消息；Worker接收到Master 注冊成功的消息后，啟用定時(shí)器，定時(shí)向Master 發(fā)送下一次響應(yīng)，更新Worker 上一次的響應(yīng)時(shí)間。RDD 將信息集通過一系列轉(zhuǎn)換，生成有向無環(huán)圖（Directed Acyclic Graph，DAG），DAG 將多個(gè)Task任務(wù)進(jìn)行封裝到Executor 實(shí)施執(zhí)行，所有Task 運(yùn)行結(jié)束之后，Executor 向Worker 注銷自身，釋放資源。多個(gè)Worker 節(jié)點(diǎn)可以并行計(jì)算，從而實(shí)現(xiàn)了分布式高效計(jì)算。

2.3 數(shù)據(jù)源組件

鈾礦勘查數(shù)據(jù)湖平臺可支持的數(shù)據(jù)庫類型包括PostgreSQL、MongoDB 等不同類型數(shù)據(jù)庫。支持的文件類型包括文本文件（TXT、CSV 等）、Excel 文件、JSON 文件、XML 文件等、MapGIS 格式、ArcGIS 格式、AutoCAD 格式、柵格數(shù)據(jù)JPG、BMP 等圖片。支持WebService、RestFul等接口類型，接口格式支持JSON、XML 等。

基于對當(dāng)前主流的大數(shù)據(jù)存儲組件、計(jì)算組件、數(shù)據(jù)源組件的工作原理及技術(shù)參數(shù)的分析，認(rèn)為Ceph 分布式存儲平臺適合鈾礦勘查數(shù)據(jù)的存儲。地震、重力、電磁等勘查數(shù)據(jù)體量大且結(jié)構(gòu)多樣，適合塊存儲；地質(zhì)圖件、鉆孔勘查數(shù)據(jù)等多為體量小且分散的數(shù)據(jù)，適合文件存儲；鈾礦勘查數(shù)據(jù)中的音視頻文件可以保存成對象存儲。鈾礦勘查業(yè)務(wù)應(yīng)用方面主要集中在鉆孔數(shù)據(jù)分析，如砂體厚度、泥巖埋深、蝕變規(guī)模、斷裂類型、物化探數(shù)據(jù)反演、遙感蝕變提取、成礦預(yù)測分析等離線數(shù)據(jù)計(jì)算；鈾礦勘探鉆孔進(jìn)尺統(tǒng)計(jì)等實(shí)時(shí)數(shù)據(jù)計(jì)算；Spark計(jì)算引擎可完全滿足鈾礦勘查數(shù)據(jù)的離線和實(shí)時(shí)計(jì)算需求。Spark 的MLlib 模塊和GraphX 算法為鈾礦勘查數(shù)據(jù)的知識圖譜構(gòu)建和智能分析提供強(qiáng)有力的支撐。

3 結(jié)論

當(dāng)前構(gòu)建的鈾礦勘查數(shù)據(jù)湖是一個(gè)集中式存儲庫，可以存儲結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)?？蓪?shí)現(xiàn)原樣存儲，并運(yùn)行不同類型的分析，可以做出更好的決策。

（1）靈活的底層存儲功能且可存儲原始數(shù)據(jù)。具有大規(guī)模數(shù)據(jù)存儲能力和多種存儲平臺，多種數(shù)據(jù)存儲格式（結(jié)構(gòu)化、非結(jié)構(gòu)化、非結(jié)構(gòu)化）并存，實(shí)現(xiàn)數(shù)據(jù)緩存加速。

（2）豐富的計(jì)算引擎。本文構(gòu)建的鈾礦勘查數(shù)據(jù)湖可實(shí)現(xiàn)批量數(shù)據(jù)計(jì)算、實(shí)時(shí)數(shù)據(jù)計(jì)算和交互式數(shù)據(jù)查詢。

（3）完善的數(shù)據(jù)管理。通過元數(shù)據(jù)可實(shí)現(xiàn)數(shù)據(jù)生命周期的全管理；滿足數(shù)據(jù)的遷移、質(zhì)量控制、數(shù)據(jù)治理和數(shù)據(jù)發(fā)布的需求。

引用

[1] 杜金虎,時(shí)付更,楊劍鋒,等.中國石油上游業(yè)務(wù)信息化建設(shè)總體藍(lán)圖[J].中國石油勘探,2020,25(5):1-8.

[2] 馬馳.民機(jī)運(yùn)行支持?jǐn)?shù)據(jù)湖設(shè)計(jì)與實(shí)現(xiàn)[J].計(jì)算機(jī)測量與控制,2021,29(7):175-179.

[3] 張蕓.淺談石油勘探行業(yè)數(shù)據(jù)湖建設(shè)中的數(shù)據(jù)治理問題[J].中國管理信息化,2021,24(9):122-124.

[4] 劉志勇,何忠江,劉敬龍,等.統(tǒng)一數(shù)據(jù)湖技術(shù)研究和建設(shè)方案[J].電信科學(xué),2021,37(1):121-128.

[5] 趙志遠(yuǎn).AWS的“數(shù)據(jù)湖”觀[J].網(wǎng)絡(luò)安全和信息化,2020(5): 8-9.

[6] 胡軍軍,謝曉軍,石彥彬,等.電信運(yùn)營商數(shù)據(jù)湖技術(shù)實(shí)施策略[J].電信科學(xué),2019,35(2):84-94.

[7] 時(shí)付更,王洪亮,孫瑤,等.夢想云在油氣精益生產(chǎn)管理中的應(yīng)用[J].中國石油勘探,2020,25(5):9-14.

[8] 黃家凱.地質(zhì)數(shù)據(jù)湖構(gòu)建方法淺析[J].數(shù)字技術(shù)與應(yīng)用,2020,38 (11):135-138.