基于HDF5 的煤礦地質(zhì)三維層疊網(wǎng)格模型分布式存儲(chǔ)研究

郭軍

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

0 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 基于HDF5 的分布式存儲(chǔ)

3.1 整體架構(gòu)

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

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

3.2 基于NFS 的 HDF5 文件共享

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

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

3.3 基于Rsync+Inotify 的HDF5 文件實(shí)時(shí)同步

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

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

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

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

圖8 HDF5 負(fù)載均衡Fig.8 HDF5 load balancing

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

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

4 實(shí)驗(yàn)分析

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

4.1 實(shí)驗(yàn)數(shù)據(jù)

實(shí)驗(yàn)數(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）。該實(shí)驗(yàn)網(wǎng)格數(shù)據(jù)分別采用體素模型、八叉樹模型及層疊網(wǎng)格模型進(jìn)行數(shù)據(jù)組織，存儲(chǔ)方案分別采用基于HDF5 的分布式文件存儲(chǔ)與MySQL 和MongoDB分布式數(shù)據(jù)庫(kù)存儲(chǔ)。3 種數(shù)據(jù)組織模型和3 種存儲(chǔ)方式所使用的存儲(chǔ)空間對(duì)比見表1。

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

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

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

4.2 測(cè)試環(huán)境

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

4.3 單存儲(chǔ)節(jié)點(diǎn)測(cè)試

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

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

表3 虛擬鉆孔查詢時(shí)間Table 3 Vitural drill query time

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

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

4.4 分布式存儲(chǔ)測(cè)試

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

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

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

5 結(jié)論

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

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

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

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