郭軍

（1.煤炭科學研究總院有限公司 礦山大數(shù)據(jù)研究院，北京 100013；2.煤炭資源高效開采與潔凈利用國家重點實驗室，北京 100013）

0 引言

三維地質(zhì)模型在表達煤礦所轄范圍內(nèi)地下資源稟賦情況的同時，還可為礦井采掘部署、地質(zhì)保障、安全生產(chǎn)管理提供科學的輔助決策，對推進煤礦智能化建設(shè)具有非常重要的現(xiàn)實意義和戰(zhàn)略意義[1]。當前三維地質(zhì)模型的地質(zhì)結(jié)構(gòu)特征大多采用基于邊界表達的方法，利用不規(guī)則三角網(wǎng)進行數(shù)據(jù)組織和管理。三角網(wǎng)組織地質(zhì)模型的優(yōu)勢在于可視化展示方面，但對于局部空間分析和查詢則難以處理，尤其針對智能開采需要進行單點查詢和多屬性分析等高效處理時，三角網(wǎng)組織地質(zhì)模型的不足更加明顯。所以，煤礦三維地質(zhì)結(jié)構(gòu)及地質(zhì)屬性場的表達需要突破傳統(tǒng)三角網(wǎng)等表達策略，要向統(tǒng)一描述地質(zhì)結(jié)構(gòu)和屬性分布的真三維網(wǎng)格模型轉(zhuǎn)變，通過綜合探測手段及煤礦地下空間作業(yè)場景變化，不斷更新三維地質(zhì)網(wǎng)格，以提高模型的精度，適應(yīng)智能開采和安全保障的應(yīng)用要求[2]。在當前大數(shù)據(jù)背景下，利用真三維地質(zhì)網(wǎng)格模型實現(xiàn)地下環(huán)境的多分辨率表達，多源數(shù)據(jù)、多參數(shù)的融合建模，模型局部更新及實現(xiàn)煤礦地下空間任意點多源數(shù)據(jù)綜合分析，將是研發(fā)新一代煤礦地學信息系統(tǒng)的基礎(chǔ)。

然而三維地質(zhì)網(wǎng)格模型由于對地下空間進行網(wǎng)格化離散，數(shù)據(jù)量隨著離散精度或者網(wǎng)格分辨率增加而呈指數(shù)級增加，一方面影響數(shù)據(jù)訪問和調(diào)度效率，另一方面由于存在大量數(shù)據(jù)冗余，即局部網(wǎng)格的屬性值相同，影響查詢性能。因此，地質(zhì)網(wǎng)格模型的組織策略和存儲管理是當前亟需解決的主要問題。通過組織策略主要解決地質(zhì)網(wǎng)格模型的數(shù)據(jù)冗余問題，降低數(shù)據(jù)量并提升查詢性能；采用高效的數(shù)據(jù)存儲和管理解決數(shù)據(jù)查詢和調(diào)度問題。

三維地質(zhì)網(wǎng)格模型及網(wǎng)格化數(shù)據(jù)組織的研究和應(yīng)用非常豐富[3]。從空間位置和網(wǎng)格拓撲關(guān)系的顯式和隱含表達角度來看，三維地質(zhì)網(wǎng)格模型可劃分為以四面體網(wǎng)格、角點網(wǎng)格[4]、廣義三棱柱[5]等為代表的顯式表達模型和以規(guī)則網(wǎng)格、八叉樹[6]、層疊網(wǎng)格[7]等為代表的隱含表達模型。顯式表達模型主要刻畫復雜地質(zhì)構(gòu)造，網(wǎng)格生成及處理難度大，主要應(yīng)用于油氣領(lǐng)域進行數(shù)值模擬[4]。隱含表達模型生成簡單，在模型局部查詢、空間分析和可視化展示方面更加高效，在地質(zhì)各領(lǐng)域應(yīng)用廣泛[6-8]。本文的三維地質(zhì)網(wǎng)格模型主要采用隱含表達模型，適應(yīng)地學大數(shù)據(jù)簡單、易用需要。

由于煤礦沉積地層地質(zhì)結(jié)構(gòu)具有層狀疊置及橫向相對連續(xù)等特征，在實際應(yīng)用中地層（巖層）的邊界和斷層等構(gòu)造是主要查詢和分析的對象。規(guī)則網(wǎng)格或者體素模型及八叉樹模型需要對網(wǎng)格進行標記才能區(qū)分邊界特征，檢索過程需要遍歷網(wǎng)格單元，造成查詢性能降低。層疊網(wǎng)格則是在空間Z方向直接近似地質(zhì)邊界或者對規(guī)則化網(wǎng)格單元進行歸并壓縮，因此，層疊網(wǎng)格單元的頂面或底面可以精確或者近似描述地質(zhì)邊界。

在三維地質(zhì)網(wǎng)格模型的數(shù)據(jù)存儲方面，結(jié)合云計算等分布式存儲是主要研究和發(fā)展方向。分布式存儲技術(shù)利用網(wǎng)絡(luò)技術(shù)在多臺機器的磁盤空間中分散存儲地質(zhì)數(shù)據(jù)，通過分布式數(shù)據(jù)庫系統(tǒng)和分布式文件系統(tǒng)，有效解決集中式存儲技術(shù)將數(shù)據(jù)放在某個特定節(jié)點上管理和查詢效率低下的問題[9]。分布式數(shù)據(jù)庫系統(tǒng)一般能提供完整的數(shù)據(jù)庫設(shè)計和數(shù)據(jù)管理查詢接口，易于實現(xiàn)和維護，如使用關(guān)系型數(shù)據(jù)庫MySQL 和非關(guān)系型數(shù)據(jù)庫MongoDB 等[10]。分布式文件系統(tǒng)通過文件管理及分布式管理組件實現(xiàn)，如Hadoop 分布式文件系統(tǒng)（Hadoop Distributed File System,HDFS）[11]。分布式文件系統(tǒng)較靈活，適用于非結(jié)構(gòu)化數(shù)據(jù)和空間數(shù)據(jù)的分布式存儲。分布式文件系統(tǒng)中文件格式和操作的靈活性、穩(wěn)定性及通用性是空間數(shù)據(jù)存儲需要重點考慮的。針對大規(guī)模網(wǎng)格數(shù)據(jù)管理和頻繁調(diào)度需求，HDF5（Hierarchical Data Format Version5）[12]已成為一種層次化多級網(wǎng)格數(shù)據(jù)存儲的通用格式之一，在科學計算及地球科學領(lǐng)域應(yīng)用廣泛，可高效地對網(wǎng)格化和多維度化數(shù)據(jù)進行存儲、管理、獲取和分發(fā)等操作，具有簡單易用、自描述、跨平臺和讀取方式靈活等優(yōu)點。然而，HDF5 屬于單文件集中式存儲模式，無法滿足分布式文件系統(tǒng)的分布管理和數(shù)據(jù)調(diào)度要求。

通過以上分析，考慮煤礦地層特征，為解決煤礦三維地質(zhì)網(wǎng)格模型的網(wǎng)格數(shù)據(jù)冗余造成的數(shù)據(jù)規(guī)模和存儲方式對空間查詢性能影響等問題，提出了基于HDF5 的煤礦地質(zhì)三維層疊網(wǎng)格模型分布式存儲方案，采用層疊網(wǎng)格對煤礦三維地質(zhì)模型數(shù)據(jù)進行數(shù)據(jù)壓縮和分塊組織，通過數(shù)據(jù)分塊解決大規(guī)模地質(zhì)網(wǎng)格模型數(shù)據(jù)的組織問題，數(shù)據(jù)分塊同時將空間相近的數(shù)據(jù)集中在相鄰的硬盤扇區(qū)或存儲設(shè)備中，有利于提高數(shù)據(jù)調(diào)度效率。結(jié)合HDF5 文件存儲優(yōu)勢實現(xiàn)了煤礦三維地質(zhì)網(wǎng)格數(shù)據(jù)的分布式文件存儲管理。

1 基于三維層疊網(wǎng)格的煤礦地質(zhì)模型表達

三維地質(zhì)網(wǎng)格模型將煤礦地質(zhì)構(gòu)造、巖層結(jié)構(gòu)及內(nèi)部地質(zhì)屬性等多參數(shù)信息統(tǒng)一表達在一個模型中，一般采用空間均勻劃分方式表達巖層結(jié)構(gòu)和屬性分布，這樣不僅利于數(shù)據(jù)更新，而且便于煤礦基于空間位置的多屬性查詢，如巷道設(shè)計、掘進或者開采中的實時地質(zhì)數(shù)據(jù)獲取等。

1.1 三維層疊網(wǎng)格模型數(shù)據(jù)組織

三維規(guī)則網(wǎng)格或者體素模型將地下空間離散為網(wǎng)格單元或者體素來描述地下空間復雜的結(jié)構(gòu)和地質(zhì)屬性分布。網(wǎng)格化表達地質(zhì)模型的數(shù)據(jù)量會隨著模型分辨率提升呈指數(shù)級增加。一般的沉積巖層具有很好的縱向分層性，A.Graciano 等[7]利用這一特性提出了層疊網(wǎng)格模型，不僅可解決體素網(wǎng)格化造成的數(shù)據(jù)量問題，而且網(wǎng)格單元的頂?shù)字苯用枋隽说貙踊蛘邘r層的頂（底）面。層疊網(wǎng)格模型在橫向（X-Y坐標）方向保持與體素網(wǎng)格相同的劃分方法，在縱向（Z坐標）方向按巖層進行屬性歸并堆疊，實現(xiàn)了數(shù)據(jù)壓縮，從而降低了數(shù)據(jù)量，比八叉樹模型具有更好的壓縮效果?？偟膩碚f，層疊網(wǎng)格模型是一種橫向上無需構(gòu)建網(wǎng)格間關(guān)聯(lián)及類似于游程編碼壓縮的規(guī)則網(wǎng)格模型。基于層疊網(wǎng)格模型表達的三維地質(zhì)模型如圖1 所示。層疊網(wǎng)格可形式化表達為StackGrid=ColumnStrata=，其中，XY表示在橫向（XY）方向的均勻規(guī)則劃分，ColumnStrata 是XY方向規(guī)則網(wǎng)格點或者單元在Z方向的單元柱，稱為層疊柱，表現(xiàn)為垂向上一個巖層屬性單元堆疊的柱子，二元組表示一個地質(zhì)分層點，存儲真實或者近似Z值及該點下方地質(zhì)屬性StratumProperty。因此，縱向上層疊網(wǎng)格單元上下界面可以看作是地質(zhì)屬性的分界面，當分界面設(shè)定為地質(zhì)界面的真實高程，可提高層疊網(wǎng)格縱向數(shù)據(jù)精度，每個層疊柱類似一個虛擬鉆孔，這個特點是體素模型或者八叉樹模型所不具備的。

圖1 基于層疊網(wǎng)格模型表達的三維地質(zhì)模型Fig.1 3D geological model expressed by stackgrid model

對于斷層面等地質(zhì)構(gòu)造及地質(zhì)異常體，將面和體進行網(wǎng)格化嵌入到層疊網(wǎng)格或者單獨用層疊網(wǎng)格存儲。采用網(wǎng)格化表達斷層面時，斷層面會填充到網(wǎng)格單元內(nèi)，使其具有網(wǎng)格單元大小的“厚度”。

1.2 三維地質(zhì)網(wǎng)格模型分塊組織

針對三維地質(zhì)模型所表達的地質(zhì)空間范圍大及單一數(shù)據(jù)體數(shù)據(jù)量多等問題，三維地質(zhì)網(wǎng)格模型一般采用分級組織、分塊存儲的策略，將整體數(shù)據(jù)劃分成較小的數(shù)據(jù)塊，如圖2 所示。數(shù)據(jù)分塊采用規(guī)則網(wǎng)格對某一分辨率數(shù)據(jù)進行劃分并進行數(shù)據(jù)塊索引。根據(jù)目前常用的HDF5 與MySQL 和MongoDB等文件或數(shù)據(jù)庫管理存儲塊特點，一般來說，數(shù)據(jù)塊的大小應(yīng)該保持在0.5～4 MB 之間[9]，對應(yīng)32×32×32或 64×64×64 分辨率的網(wǎng)格化模型。數(shù)據(jù)分塊后，對每一個數(shù)據(jù)塊分別采用層疊網(wǎng)格、體素網(wǎng)格、線性八叉樹進行組織對比。

圖2 三維地質(zhì)網(wǎng)格模型數(shù)據(jù)組織Fig.2 Data organization of 3D geological grid model

2 三維地質(zhì)模型數(shù)據(jù)存儲設(shè)計

2.1 HDF5 數(shù)據(jù)存儲設(shè)計

在一個存儲節(jié)點上，HDF5 將三維地質(zhì)模型作為一個整體文件存儲，不同分辨率的數(shù)據(jù)塊作為一個數(shù)據(jù)集（DataSet）存儲，利用HDF5 特有的層級存儲管理格式可以實現(xiàn)網(wǎng)格模型不同分辨率及數(shù)據(jù)分塊的層級組織結(jié)構(gòu)，如圖3（a）所示。數(shù)據(jù)塊的存儲結(jié)構(gòu)由數(shù)據(jù)集DataSet 完成。層疊網(wǎng)格由于Z方向是非均勻網(wǎng)格劃分，因此，其存儲結(jié)構(gòu)對比體素模型要復雜。如圖3（b）所示，體素模型X，Y和Z三個方向均勻劃分，可以用三維數(shù)組結(jié)構(gòu)存儲，其維度（Dim）為3，存儲數(shù)據(jù)data 的類型是基本數(shù)據(jù)類型，本文默認為整型。八叉樹模型X，Y和Z三個方向都是非均勻劃分，只能是一維數(shù)組結(jié)構(gòu)存儲，采用線性八叉樹的Morton 碼進行組織，只存儲葉子節(jié)點，每個節(jié)點是一個復合數(shù)據(jù)類型（CoumpoundDataType），需要存儲索引index 和數(shù)據(jù)data。層疊網(wǎng)格模型XY方向均勻劃分，Z方向非均勻劃分或者按地質(zhì)邊界劃分，XY方向規(guī)則網(wǎng)格用二維數(shù)組結(jié)構(gòu)存儲，其維度（Dim）為2，復合數(shù)據(jù)類型（CoumpoundDataType）作為層疊柱的索引index，存儲分層個數(shù)layernum 和該層疊柱的數(shù)據(jù)位置datapos；所有層疊柱存儲在data 中，每個分層點是復合數(shù)據(jù)類型，用于存儲地質(zhì)界面的id 和z值。

圖3 HDF5 數(shù)據(jù)存儲Fig.3 HDF5 data storage

從以上存儲結(jié)構(gòu)可以看出，層疊網(wǎng)格模型相對于體素模型和八叉樹模型存儲復雜一點，主要原因在于XY方向和Z方向的劃分方式不同。對于單點查詢，層疊網(wǎng)格模型需要進行2 次數(shù)據(jù)集DataSet 訪問。

2.2 MySQL 和MongoDB 數(shù)據(jù)存儲設(shè)計

數(shù)據(jù)庫存儲的庫表結(jié)構(gòu)一般無法直接存儲網(wǎng)格單元，需要將數(shù)據(jù)塊整體作為一個字段進行處理。采用MySQL 和MongoDB 的數(shù)據(jù)庫表設(shè)計如圖4 所示。Model 表主要用于描述模型的元數(shù)據(jù)及存儲信息，LodGrid 表用于存儲分級和分塊信息。Block 表用于存儲具體數(shù)據(jù)塊，分別給出了體素網(wǎng)格（GridBlock）、線性八叉樹（OctreeBlock）及層疊網(wǎng)格（StackGridBlock）的數(shù)據(jù)塊存儲表。在數(shù)據(jù)塊Block 中，類似HDF5 中的數(shù)據(jù)集DataSet，包括ID、DATA 和LAYERID 三個字段。ID 表示數(shù)據(jù)塊在數(shù)據(jù)庫表的唯一標志碼；DATA 表示具體數(shù)據(jù)，采用Blob 二進制塊存儲；LAYERID 表示所在層級或者分辨率。體素網(wǎng)格數(shù)據(jù)塊（GridBlock）的地質(zhì)數(shù)據(jù)由一個Blob 存儲即可，八叉樹和層疊網(wǎng)格的DATA 需要2 個Blob 字段，一個是索引塊（INDEXDATA），一個是地質(zhì)數(shù)據(jù)塊（BLOCKDATA）。

圖4 MySQL，MongoDB 數(shù)據(jù)存儲結(jié)構(gòu)Fig.4 Data storage structure of MySQL and MongoDB

從圖3 和圖4 可看出，HDF5 中的數(shù)據(jù)集DataSet類似數(shù)據(jù)庫中的Blob 字段。但是，DataSet 的意義明確，維度清晰，而數(shù)據(jù)庫Blob 字段是不明確的，需要元數(shù)據(jù)進行說明，查詢時只能自行解析。同時，數(shù)據(jù)庫難以表達分級結(jié)構(gòu)。單點查詢方面，HDF5 中的數(shù)據(jù)集DataSet 可以通過文件跳轉(zhuǎn)直接定位到所查詢位置，而數(shù)據(jù)庫Blob 字段一般需要先將數(shù)據(jù)全部讀出后再進行解析，所以會對查詢性能造成一定影響。

3 基于HDF5 的分布式存儲

3.1 整體架構(gòu)

分布式存儲和管理是解決大規(guī)模海量數(shù)據(jù)調(diào)度的主要手段，可以通過負載均衡將數(shù)據(jù)訪問的壓力分散到集群中的各個節(jié)點，提高數(shù)據(jù)讀寫的性能與穩(wěn)定性[13-16]。關(guān)系型數(shù)據(jù)庫MySQL 和非關(guān)系型數(shù)據(jù)庫MongoDB 等提供了較為完整的分布式存儲管理方法，遵循使用規(guī)范即可完成數(shù)據(jù)的分布存儲和管理調(diào)度。然而，HDF5 作為單一結(jié)構(gòu)化文件格式，存儲數(shù)據(jù)多維度、多變量且結(jié)構(gòu)緊湊，如果將HDF5 采用類似HDFS[8,15]分布式存儲技術(shù)分塊存儲，勢必會破壞原生格式的緊湊型，降低I/O 性能。為此，本文重點討論基于HDF5 的分布式存儲管理架構(gòu)，提出了一種直接針對原始結(jié)構(gòu)化HDF5 文件進行分布式存儲的技術(shù)方案。HDF5 分布式數(shù)據(jù)存儲管理和查詢的整體架構(gòu)如圖5 所示。①在數(shù)據(jù)存儲方面，HDF5 作為存儲的持久化層，用來存儲所有的原始數(shù)據(jù)，采用內(nèi)存數(shù)據(jù)庫Redis 存儲熱點數(shù)據(jù)、HDF5 元數(shù)據(jù)等相關(guān)信息。② 在Web 服務(wù)方面，使用H5Serv 發(fā)送和接收HDF5 數(shù)據(jù)。③在HDF5 實現(xiàn)分布式方面，利用網(wǎng)絡(luò)文件系統(tǒng)（Network File System，NFS）實現(xiàn)HDF5 數(shù)據(jù)在不同節(jié)點服務(wù)器之間的共享；利用遠程同步（Remote Synchronize,Rsync）[17]和Inotify 實現(xiàn)HDF5 數(shù)據(jù)在不同節(jié)點服務(wù)器的數(shù)據(jù)實時同步；通過Nginx 服務(wù)器實現(xiàn)訪問時反向代理和數(shù)據(jù)服務(wù)節(jié)點的負載均衡。④ 應(yīng)用Docker[18]容器技術(shù)將數(shù)據(jù)節(jié)點服務(wù)和Nginx 服務(wù)進行統(tǒng)一部署，通過JupyterLab 交互式數(shù)據(jù)管理平臺實現(xiàn)實時數(shù)據(jù)資源的調(diào)度和管理。

圖5 基于HDF5 的分布式存儲管理系統(tǒng)架構(gòu)Fig.5 Architecture of distributed storage management system based on HDF5

3.2 基于NFS 的 HDF5 文件共享

NFS 依賴遠程過程調(diào)用（Remote Procedure Call,RPC）機制，允許網(wǎng)絡(luò)中的計算機之間通過TCP/IP 網(wǎng)絡(luò)共享資源[19]。在NFS 的應(yīng)用中，本地NFS 的客戶端應(yīng)用可以透明地讀寫位于遠端NFS 服務(wù)器上的文件，就像訪問本地文件一樣，如圖6 所示。使用NFS 實現(xiàn)HDF5 文件共享，可以減少本地存儲HDF5文件的空間，提供HDF5 透明文件訪問及文件傳輸。通過配置NFS 共享HDF5 文件，作為分布式存儲HDF5 文件統(tǒng)一訪問的入口。

圖6 HDF5 數(shù)據(jù)共享Fig.6 HDF5 data sharing

3.3 基于Rsync+Inotify 的HDF5 文件實時同步

Rsync 的任務(wù)是遠程同步和數(shù)據(jù)備份，使HDF5文件在2 臺服務(wù)器間實現(xiàn)數(shù)據(jù)快速同步鏡像和遠程備份。HDF5 實時同步更新如圖7 所示，同步HDF5文件的同時可以保持原來文件的權(quán)限、時間、軟硬鏈接等附加信息。Inotify 作為Linux 文件系統(tǒng)的變化通知機制，一臺服務(wù)器上HDF5 文件增加、刪除等事件可以立刻通知另一臺服務(wù)器，結(jié)合Rsync 實現(xiàn)HDF5 數(shù)據(jù)實時監(jiān)控和同步更新。

圖7 HDF5 實時同步更新Fig.7 HDF5 real-time synchronization update

3.4 基于Nginx 的 HDF5 訪問負載均衡實現(xiàn)

針對并發(fā)請求HDF5 數(shù)據(jù)帶來的服務(wù)過載問題，需要搭建服務(wù)器集群解決單一服務(wù)器無法實現(xiàn)的負載均衡分發(fā)。HDF5 訪問負載均衡實現(xiàn)如圖8 所示，使用Nginx 服務(wù)器內(nèi)置的負載均衡策略[20]將并發(fā)訪問轉(zhuǎn)發(fā)至不同的服務(wù)器進行處理，減少單服務(wù)器的壓力，解決數(shù)據(jù)傳輸響應(yīng)慢、連接丟失、甚至無法訪問的問題。

圖8 HDF5 負載均衡Fig.8 HDF5 load balancing

3.5 基于JupyterLab 的數(shù)據(jù)管理和調(diào)度實現(xiàn)

JupyterLab 作為交互式分析典型的Web 架構(gòu)應(yīng)用，可以在其中記錄代碼和運行代碼、可視化數(shù)據(jù)、查看輸出結(jié)果。使用JupyterLab 可統(tǒng)一管理使用分布式存儲框架，且能以實時代碼和結(jié)果可視化集成展示的形式應(yīng)用于大數(shù)據(jù)分析[21]。

4 實驗分析

通過實驗對比，驗證層疊網(wǎng)格模型對比體素模型和八叉樹模型在降低數(shù)據(jù)量及不同存儲方式下空間查詢的優(yōu)勢；驗證基于HDF5 的分布式文件存儲管理比數(shù)據(jù)庫分布式存儲具有更好的空間查詢優(yōu)勢。

4.1 實驗數(shù)據(jù)

實驗數(shù)據(jù)選用某煤礦三維地質(zhì)模型，如圖9 所示，主要構(gòu)建了煤巖巖性結(jié)構(gòu)分層。以該煤礦三維地質(zhì)模型構(gòu)建網(wǎng)格化地質(zhì)結(jié)構(gòu)模型，網(wǎng)格劃分橫向分辨率為10 m，縱向分辨率為0.5 m。網(wǎng)格規(guī)模為640×320×1 200，地質(zhì)屬性類型為整型（4 byte）。該實驗網(wǎng)格數(shù)據(jù)分別采用體素模型、八叉樹模型及層疊網(wǎng)格模型進行數(shù)據(jù)組織，存儲方案分別采用基于HDF5 的分布式文件存儲與MySQL 和MongoDB分布式數(shù)據(jù)庫存儲。3 種數(shù)據(jù)組織模型和3 種存儲方式所使用的存儲空間對比見表1。

圖9 某煤礦三維地質(zhì)模型Fig.9 3D geological model of a coal mine

表1 網(wǎng)格數(shù)據(jù)存儲空間使用量對比Table 1 Comparison of griddata storage space

從表1 可看出：體素模型需要對網(wǎng)格劃分分辨率下所有位置進行存儲，數(shù)據(jù)量與網(wǎng)格規(guī)模有關(guān)，數(shù)據(jù)量達到GB 級別；由于進行了單元合并冗余處理的數(shù)據(jù)壓縮，基于八叉樹和層疊網(wǎng)格的存儲方式可有效減少數(shù)據(jù)量，且層疊網(wǎng)格相對于八叉樹只存儲了界面位置的格子，對于層狀地質(zhì)結(jié)構(gòu)能更有效降低數(shù)據(jù)量?；贖DF5 的文件存儲明顯比MySQL 和MongoDB 數(shù)據(jù)庫存儲更加節(jié)省空間，主要原因在于HDF5 的DataSet 可直接存儲數(shù)據(jù)塊，不需要額外存儲信息，而數(shù)據(jù)庫存儲在Blob 字段存儲數(shù)據(jù)，為了查詢優(yōu)化，需要對Block 表構(gòu)建索引，而這些索引屬于數(shù)據(jù)庫性能優(yōu)化方面的額外空間。因此，對于層疊網(wǎng)格模型等有一定空間規(guī)則的數(shù)據(jù)，基于HDF5 的文件方式比數(shù)據(jù)庫方式更加節(jié)省存儲空間。

4.2 測試環(huán)境

測試環(huán)境選用阿里云Linux 系統(tǒng)Ubuntu 服務(wù)器進行測試，操作系統(tǒng)為Ubuntu16.04 64 位，CPU 為2 核，內(nèi)存為2 GB，SSD 云盤為40 GB，帶寬峰值為5 MB，測試平臺為JupyterLab 及測試語言為Python。

4.3 單存儲節(jié)點測試

在相同測試環(huán)境和相同的負載下，針對4.1 節(jié)中實驗數(shù)據(jù)，在同一個數(shù)據(jù)服務(wù)節(jié)點提取指定單網(wǎng)格空間位置、虛擬鉆孔的屬性值及提取巖層界面。檢索單網(wǎng)格位置是給定空間位置得到該位置的地質(zhì)屬性id，選擇3 個不同位置的檢索結(jié)果見表2。虛擬鉆孔是給定井口位置xy坐標，提取該位置z方向所有單元屬性，選擇3 個不同井口位置的檢索結(jié)果見表3。提取巖層界面是指提取指定巖層id，提取其頂面全部煤礦范圍內(nèi)的空間位置，由于體素模型需要逐個單元查詢，沒有檢索優(yōu)勢，只比較八叉樹模型和層疊網(wǎng)格模型，選擇3 個巖層的檢索結(jié)果見表4。

表2 單網(wǎng)格位置查詢時間Table 2 Single grid node query time

表3 虛擬鉆孔查詢時間Table 3 Vitural drill query time

表4 提取巖層頂面查詢時間Table 4 Time for extracting stratum top surface

從表2-表4 可看出：在網(wǎng)格模型的數(shù)據(jù)組織方面，在單網(wǎng)格位置查詢測試中，體素模型具有優(yōu)勢，主要原因在于數(shù)據(jù)模型和存儲結(jié)構(gòu)方面，體素模型只需要一次定位就可以得到該位置屬性，而層疊網(wǎng)格模型和八叉樹模型需要遍歷網(wǎng)格點找到相應(yīng)空間位置。但是對于虛擬鉆孔和層面提取，由于主要涉及地質(zhì)界面信息，層疊網(wǎng)格模型的查詢性能具有明顯優(yōu)勢，體素模型和八叉樹模型都需要逐一遍歷判斷地質(zhì)界面所在網(wǎng)格單元。在數(shù)據(jù)存儲方式上，基于HDF5 的查詢性能明顯高于數(shù)據(jù)庫，HDF5 可在DataSet 中直接讀取數(shù)據(jù)，而數(shù)據(jù)庫一般都需要讀取整個Blob 字段并進行解析，需要處理事務(wù)及查詢索引優(yōu)化操作，相對比文件系統(tǒng)降低了查詢性能。

4.4 分布式存儲測試

對于單網(wǎng)格點測試和虛擬鉆孔數(shù)據(jù)操作基本還是在單存儲節(jié)點進行。分布式測試主要對比地層頂面提取方法的差異。分布式測試使用6 臺服務(wù)器分別搭建分布式存儲管理集群，其測試結(jié)果見表5。

表5 提取巖層頂面的分布式查詢時間Table 5 Distributed query times of stratum top surface

從表5 可看出：HDF5 分布式查詢性能優(yōu)于MySQL 和MongoDB 等分布式數(shù)據(jù)庫，主要原因在于單節(jié)點的查詢性能HDF5 優(yōu)于數(shù)據(jù)庫，同時基于HDF5 的分布式存儲管理架構(gòu)可以彌補HDF5 不支持分布式查詢的不足，實現(xiàn)了大規(guī)模網(wǎng)格數(shù)據(jù)的分布式管理和高性能查詢處理。數(shù)據(jù)組織方面，層疊網(wǎng)格模型在巖層界面查詢方面明顯優(yōu)于八叉樹模型。因此，基于層疊網(wǎng)格和HDF5 的數(shù)據(jù)組織和存儲方案可以為煤礦三維地質(zhì)網(wǎng)格模型的有效存儲管理提供借鑒。

5 結(jié)論

針對煤礦三維地質(zhì)網(wǎng)格模型的分布式存儲和查詢性能問題，提出了基于HDF5 的煤礦地質(zhì)三維層疊網(wǎng)格模型分布式存儲方案，該方案在網(wǎng)格數(shù)據(jù)組織方面采用層疊網(wǎng)格對三維地質(zhì)模型進行分塊組織，在分布式存儲和查詢方面實現(xiàn)了基于HDF5 的分布式文件存儲管理?；趯盈B網(wǎng)格的地質(zhì)模型數(shù)據(jù)組織和基于HDF5 的分布式存儲可以實現(xiàn)煤礦三維地質(zhì)網(wǎng)格模型的有效存儲管理和空間查詢。

（1）層疊網(wǎng)格模型在XY方向上規(guī)則劃分，Z方向通過單元合并冗余處理的數(shù)據(jù)壓縮對地質(zhì)界面進行近似或者精確描述，更加適合煤系沉積地層結(jié)構(gòu)的網(wǎng)格化表達，相對于體素模型和八叉樹模型數(shù)據(jù)量更小，便于實現(xiàn)地質(zhì)界面的快速查詢。

（2）基于HDF5 文件和數(shù)據(jù)庫表的層疊網(wǎng)格模型存儲結(jié)構(gòu)相對于體素模型和八叉樹模型要復雜。單點查詢操作比體素模型次數(shù)多，性能低。

（3）設(shè)計和實現(xiàn)了基于HDF5 的分布式存儲管理框架，通過Docker 容器將HDF5 的H5ServWeb 服務(wù)、NFS 文件共享及Rsync 實時同步、Nginx 技術(shù)和負載均衡處理進行統(tǒng)一部署，基于JupyterLab 的終端實現(xiàn)，解決了單一HDF5 無法實現(xiàn)分布式存儲和查詢的問題?；贖DF5 的分布式存儲管理框架在層疊網(wǎng)格模型、體素模型和八叉樹模型3 種數(shù)據(jù)組織下空間查詢性能優(yōu)于非關(guān)系型數(shù)據(jù)庫MongoDB 和關(guān)系型數(shù)據(jù)庫MySQL。