鈾礦勘查數據湖分布式存儲和計算系統構建＊

孫遠強 蔡煜琦 李曉翠 孫雨鑫 金鑫裕

1.核工業北京地質研究院；2.中國地質大學（北京）

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

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

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

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

1 數據湖架構

以處理大型數據集，包括結構化、半結構化或非結構化數據，為主的一組軟件組件構成了分布式大數據平臺。這類平臺隨時間推移演進了以Hadoop 為代表的第一代離線數據平臺、Lambda 架構的第二代平臺、Kappa架構的第三代平臺和最新一代的數據湖大數據技術平臺。目前最主流的三大開源數據湖方案分別為：Databricks公司的Delta 數據湖架構、Uber 公司的Hudi 數據湖架構和Netflix 公司的Iceberg 數據湖架構。基于鈾礦勘查的數據特征和勘查業務發展的需求，搭建以PostgreSQL+MongoDB+Ceph+Kafka+Spark 為組件的鈾礦勘查數據湖大數據技術平臺。

1.1 數據湖概念模型

鈾礦勘查數據湖從硬件、軟件和網絡環境的需求分析，它需要支撐的軟件平臺包括存儲組件、計算組件、數據治理組件以及作為數據來源的數據庫組件等。在此基礎上可以開展鈾礦勘查業務應用，諸如鉆孔數據分析應用、地球化學數據集成應用、重磁電震數據提取應用、成果可視化表達應用等。確保該類業務應用順利開展的兩條主線是質量控制和安全審計。實現數據實體存儲和流轉的服務器和網絡通信設備。基于對數據湖平臺構建邏輯的梳理，本文提出鈾礦勘查數據湖概念模型（如圖1所示），為搭建鈾礦勘查數據湖大數據技術平臺提供概念和邏輯支撐。

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

1.2 數據湖技術架構

數據湖大數據平臺的技術實現包括數據交互、質量檢查、數據存儲、數據分析與發現、元數據管理等環節（如圖2 所示）。

圖2 鈾礦勘查數據湖技術架構Fig.2 Technical architecture of uranium exploration data lake

1.2.1 數據交互（Data Ingesting）

凡數據入湖對象，均以元數據標準化模型為依據，啟用相應的校驗規則和質量驗證，可深度影響或者關聯原始數據的形態，同時打上明確的標簽和版本。

在數據治理的整體體系中，能夠依據元數據管理模型，及主數據的規則文件，快速的洞察數據的質量，識別其數據風險，并在必要節點（按預定義的自動化流程）觸發數據的治理流程。

能夠對于接入的數據質量進行實時管控?？商峁祿侄涡ｒ灐祿暾苑治龅裙δ?；同時，可監控數據處理任務，避免未執行完成任務生成不完備的數據。

1.2.2 原始數據（數據存儲）

基于原始數據，會依照元數據標準模型，通過數據湖里的既定工作流引擎對其進行有針對性的數據清洗、轉換、并回寫數據目錄。

1.2.3 數據聚合（數據發現與分析）

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

使其數據的脈絡（血緣）、層次，關系更加的清晰，為進一步的可視化展示及智能化應用方面的實現，提供切實、可靠的依據。同時，兼具對最終學術科研成果等隱性知識的顯化功能。

1.2.4 元數據管理

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

1.3 數據湖數據架構

鈾礦勘查數據湖的數據架構由數據計算、數據存儲、數據源等3 個獨立而又相互聯系的功能組件組成。數據架構可以實現對數據源的統一抽取與遷移、數據集中存儲與分析、數據質量的統一治理，同時支持數據智能分析及數據內容的共享應用（如圖3 所示）。

圖3 鈾礦勘查數據湖數據架構Fig.3 Data architecture of uranium exploration data lake

2 基礎組件

2.1 存儲組件

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

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

（1）Ceph OSD 作為對象存儲設備（Object Storage Device），其主要功能是存儲數據、平衡數據、復制數據、恢復數據等，同時負責響應客戶端請求返回具體數據的進程。多個OSD 可以耦合到一個Ceph 集群，實現數據的海量規模存儲。

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

（3）Ceph Monitor 作為Ceph 的監視器，負責管理Ceph 集群相關系統的健康狀態，集群內的成員及其屬性和關系以及數據的分發都屬于監視器的管理范疇。

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

圖5 Ceph 系統分層關系圖Fig.5 Hierarchical diagram of the Ceph system

2.2 計算組件

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

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

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

（1）Spark Core 作為Spark 計算組件的核心，主要負責任務調度等管理功能。Spark Core 依賴彈性分布式數據集（Resilient Distributed Datasets,RDDs）實現分布式計算。

（2）Spark SQL 是處理結構化數據的模塊，其支持SQL、HiveQL 等數據庫查詢及復雜算法的分析；還支持JDBC 和ODBC 連接，能夠直接連接現有的數據庫。

（3）Spark Streaming 支持流數據的可伸縮和容錯處理，集成了Kafka 和Flume 平臺，前者提供消息隊列功能，后者實現日志數據優化處理。該集成平臺使其為流數據的處理能夠更靈活，也更容易實現。

（4）MLlib 主要應用于機器學習領域，實現了分類、回歸、聚類、主成分分析等相關算法。

（5）GraphX 可支持數據圖的分析和計算，包含了許多被廣泛理解的圖形算法，并支持圖形處理的Pregel API 版本。

Spark 集群分為Master 節點和Worker 節點。Master節點管理其系統下的所有Worker 節點。Worker 節點負責與Master 節點信息通信并管理Executors。Driver 是用戶編寫的Spark 應用程序的進程，其可以在Master 和Worker 節點上同時運行（如圖7 所示）。

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

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

2.3 數據源組件

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

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

3 結論

當前構建的鈾礦勘查數據湖是一個集中式存儲庫，可以存儲結構化和非結構化數據?？蓪崿F原樣存儲，并運行不同類型的分析，可以做出更好的決策。

（1）靈活的底層存儲功能且可存儲原始數據。具有大規模數據存儲能力和多種存儲平臺，多種數據存儲格式（結構化、非結構化、非結構化）并存，實現數據緩存加速。

（2）豐富的計算引擎。本文構建的鈾礦勘查數據湖可實現批量數據計算、實時數據計算和交互式數據查詢。

（3）完善的數據管理。通過元數據可實現數據生命周期的全管理；滿足數據的遷移、質量控制、數據治理和數據發布的需求。

引用

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

[2] 馬馳.民機運行支持數據湖設計與實現[J].計算機測量與控制,2021,29(7):175-179.

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

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

[5] 趙志遠.AWS的“數據湖”觀[J].網絡安全和信息化,2020(5): 8-9.

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

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

[8] 黃家凱.地質數據湖構建方法淺析[J].數字技術與應用,2020,38 (11):135-138.