郭軍
(1.煤炭科學(xué)研究總院有限公司 礦山大數(shù)據(jù)研究院,北京 100013;2.煤炭資源高效開采與潔凈利用國(guó)家重點(diǎn)實(shí)驗(yàn)室,北京 100013)
三維地質(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á)角度來(lái)看,三維地質(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ǔ)模式,無(wú)法滿足分布式文件系統(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ǔ)管理。
三維地質(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ù)獲取等。
三維規(guī)則網(wǎng)格或者體素模型將地下空間離散為網(wǎng)格單元或者體素來(lái)描述地下空間復(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ù)量,比八叉樹模型具有更好的壓縮效果。總的來(lái)說(shuō),層疊網(wǎng)格模型是一種橫向上無(wú)需構(gòu)建網(wǎng)格間關(guān)聯(lián)及類似于游程編碼壓縮的規(guī)則網(wǎng)格模型。基于層疊網(wǎng)格模型表達(dá)的三維地質(zhì)模型如圖1 所示。層疊網(wǎng)格可形式化表達(dá)為StackGrid=
圖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)格單元大小的“厚度”。
針對(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),一般來(lái)說(shuō),數(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
在一個(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 訪問。
數(shù)據(jù)庫(kù)存儲(chǔ)的庫(kù)表結(jié)構(gòu)一般無(wú)法直接存儲(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)行說(shuō)明,查詢時(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ì)查詢性能造成一定影響。
分布式存儲(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ǔ)的持久化層,用來(lái)存儲(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
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
Rsync 的任務(wù)是遠(yuǎn)程同步和數(shù)據(jù)備份,使HDF5文件在2 臺(tái)服務(wù)器間實(shí)現(xiàn)數(shù)據(jù)快速同步鏡像和遠(yuǎn)程備份。HDF5 實(shí)時(shí)同步更新如圖7 所示,同步HDF5文件的同時(shí)可以保持原來(lái)文件的權(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
針對(duì)并發(fā)請(qǐng)求HDF5 數(shù)據(jù)帶來(lái)的服務(wù)過載問題,需要搭建服務(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)慢、連接丟失、甚至無(wú)法訪問的問題。
圖8 HDF5 負(fù)載均衡Fig.8 HDF5 load balancing
JupyterLab 作為交互式分析典型的Web 架構(gòu)應(yīng)用,可以在其中記錄代碼和運(yùn)行代碼、可視化數(shù)據(jù)、查看輸出結(jié)果。使用JupyterLab 可統(tǒng)一管理使用分布式存儲(chǔ)框架,且能以實(shí)時(shí)代碼和結(jié)果可視化集成展示的形式應(yīng)用于大數(shù)據(jù)分析[21]。
通過實(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ì)。
實(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ǔ)空間。
測(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è)試語(yǔ)言為Python。
在相同測(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)降低了查詢性能。
對(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ǔ)管理提供借鑒。
針對(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 無(wú)法實(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。