基于HDF5 的煤礦地質三維層疊網格模型分布式存儲研究

郭軍

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

0 引言

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

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

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

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

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

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

1 基于三維層疊網格的煤礦地質模型表達

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

1.1 三維層疊網格模型數據組織

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

圖1 基于層疊網格模型表達的三維地質模型Fig.1 3D geological model expressed by stackgrid model

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

1.2 三維地質網格模型分塊組織

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

圖2 三維地質網格模型數據組織Fig.2 Data organization of 3D geological grid model

2 三維地質模型數據存儲設計

2.1 HDF5 數據存儲設計

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

圖3 HDF5 數據存儲Fig.3 HDF5 data storage

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

2.2 MySQL 和MongoDB 數據存儲設計

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

圖4 MySQL，MongoDB 數據存儲結構Fig.4 Data storage structure of MySQL and MongoDB

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

3 基于HDF5 的分布式存儲

3.1 整體架構

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

圖5 基于HDF5 的分布式存儲管理系統架構Fig.5 Architecture of distributed storage management system based on HDF5

3.2 基于NFS 的 HDF5 文件共享

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

圖6 HDF5 數據共享Fig.6 HDF5 data sharing

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

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

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

3.4 基于Nginx 的 HDF5 訪問負載均衡實現

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

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

3.5 基于JupyterLab 的數據管理和調度實現

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

4 實驗分析

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

4.1 實驗數據

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

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

表1 網格數據存儲空間使用量對比Table 1 Comparison of griddata storage space

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

4.2 測試環境

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

4.3 單存儲節點測試

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

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

4.4 分布式存儲測試

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

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

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

5 結論

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

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

（2）基于HDF5 文件和數據庫表的層疊網格模型存儲結構相對于體素模型和八叉樹模型要復雜。單點查詢操作比體素模型次數多，性能低。

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