基于云架構(gòu)的地質(zhì)測(cè)繪管理系統(tǒng)構(gòu)建

董 晉

（中晉環(huán)境科技有限公司，太原 030000）

隨著地質(zhì)測(cè)繪工作的開展和深入，對(duì)于如何提升測(cè)繪工作中的檢索效率和對(duì)產(chǎn)生的大量數(shù)據(jù)進(jìn)行管理，是測(cè)繪工作中需要解決的問題。我國常用依托關(guān)系型數(shù)據(jù)庫對(duì)測(cè)繪工作中產(chǎn)生的數(shù)據(jù)進(jìn)行管理，再對(duì)數(shù)據(jù)檢索系統(tǒng)和管理模塊進(jìn)行構(gòu)建，進(jìn)而提高數(shù)據(jù)的存儲(chǔ)。在地質(zhì)測(cè)繪工作中，包括了關(guān)系型數(shù)據(jù)和各類異構(gòu)數(shù)據(jù)。對(duì)此，傳統(tǒng)的測(cè)繪數(shù)據(jù)管理方法在如今的測(cè)繪界已不適用。在云計(jì)算技術(shù)興起的當(dāng)下，Hadoop框架不僅能夠存儲(chǔ)大量數(shù)據(jù)，也能儲(chǔ)存種類不同的數(shù)據(jù)，因此成為了當(dāng)前的應(yīng)用熱點(diǎn)。例如潘云（2020）和王永才（2020）會(huì)將Hadoop 框架運(yùn)用與系統(tǒng)構(gòu)建以及數(shù)據(jù)挖掘工作中，以此來提升挖掘數(shù)據(jù)的效率和系統(tǒng)的運(yùn)行效率。不難看出，Hadoop 技術(shù)逐漸受到了人們的關(guān)注，因此本文以Hadoop 為前提，提出了基于大數(shù)據(jù)對(duì)地質(zhì)測(cè)繪產(chǎn)生大量數(shù)據(jù)的存儲(chǔ)及管理方案，在該方案的基礎(chǔ)上對(duì)該系統(tǒng)進(jìn)行了設(shè)計(jì)。

1 Hadoop框架

由于地質(zhì)條件的差異性，造成了地質(zhì)測(cè)繪數(shù)據(jù)的多樣性、異構(gòu)性、隨機(jī)性、非線性、相關(guān)性等特點(diǎn)。因?yàn)榈刭|(zhì)測(cè)繪的數(shù)據(jù)具有多樣性，例如地質(zhì)元素、構(gòu)造和地質(zhì)形成等。因此，從以上分析來看，地質(zhì)測(cè)繪管理系統(tǒng)應(yīng)當(dāng)兼具多維度、結(jié)構(gòu)化與非結(jié)構(gòu)化并用等特性。HDFS文件管理系統(tǒng)采用分布式架構(gòu)設(shè)計(jì)，能夠順序訪問機(jī)構(gòu)化、非結(jié)構(gòu)化數(shù)據(jù)，對(duì)于硬件條件的要求較低；HBase數(shù)據(jù)庫對(duì)于硬件條件的要求較高，能夠快速隨機(jī)訪問數(shù)據(jù)。顯然，將HDFS 系統(tǒng)與HBase數(shù)據(jù)庫進(jìn)行結(jié)合，則能夠更好地實(shí)現(xiàn)海量地質(zhì)測(cè)繪數(shù)據(jù)的存儲(chǔ)、訪問及管理。對(duì)此，本文利用HDFS系統(tǒng)來存儲(chǔ)地質(zhì)測(cè)繪數(shù)據(jù)。其中，當(dāng)?shù)刭|(zhì)數(shù)據(jù)量過多時(shí)可直接存儲(chǔ)到HDFS系統(tǒng)，體量較小的地質(zhì)數(shù)據(jù)直接經(jīng)過文件合并再存儲(chǔ)到HDFS 系統(tǒng)。利用HBase 數(shù)據(jù)庫來存儲(chǔ)地質(zhì)數(shù)據(jù)條目的索引信息，從而實(shí)現(xiàn)兩類文件管理系統(tǒng)的結(jié)合。當(dāng)一個(gè)HDFS文件發(fā)生變化，與之相對(duì)應(yīng)的HBase索引數(shù)據(jù)也會(huì)同步更新，從而提升數(shù)據(jù)檢索效率。具體架構(gòu)示意圖如圖1所示。

圖1 Hadoop系統(tǒng)架構(gòu)Fig.1 Hadoop system architecture

Hadoop架構(gòu)的特點(diǎn)有以下3點(diǎn)：

1）分布式文件管理系統(tǒng)HDFS：該系統(tǒng)可部署在普通PC 服務(wù)器集群中，內(nèi)置流式訪問接口，嵌入“一次寫入、多次讀取”的文件訪問模型，不僅能夠?qū)崿F(xiàn)可靠的數(shù)據(jù)存儲(chǔ)功能，而且其數(shù)據(jù)訪問速率優(yōu)于集中式文件管理系統(tǒng)。此外，HDFS 系統(tǒng)的容錯(cuò)能力強(qiáng)，且支持跨平臺(tái)移植。

2）分布式處理模型MapReduce：該模型集中了Map與Reduce機(jī)制，能夠?qū)?fù)雜問題簡(jiǎn)化分解為多個(gè)彼此獨(dú)立的子任務(wù)，然后引用計(jì)算處理節(jié)點(diǎn)對(duì)各子任務(wù)進(jìn)行高效處理，整體上保證了對(duì)于海量數(shù)據(jù)的處理功能。此外，MapReduce模型利用數(shù)據(jù)/代碼互定位技術(shù)切斷了各節(jié)點(diǎn)間的聯(lián)系，從而為單項(xiàng)任務(wù)的處理創(chuàng)造了條件；MapReduce模型還為系統(tǒng)開發(fā)中的系統(tǒng)層設(shè)計(jì)提供了技術(shù)支持。

3）非關(guān)系型數(shù)據(jù)庫HBase：作為一種新型的分布式數(shù)據(jù)庫，HBase可用于存儲(chǔ)半結(jié)構(gòu)化、非結(jié)構(gòu)化的松散數(shù)據(jù)，并且通過主鍵range實(shí)現(xiàn)了快速檢索功能，在應(yīng)用中表現(xiàn)出性能優(yōu)越、實(shí)時(shí)讀寫等優(yōu)勢(shì)特征。

2 地質(zhì)云計(jì)算平臺(tái)技術(shù)框架

針對(duì)Hadoop 特點(diǎn)和測(cè)繪管理系統(tǒng)的業(yè)務(wù)進(jìn)行分析，把系統(tǒng)整體架構(gòu)分成存儲(chǔ)層、物理層和數(shù)據(jù)層等，架構(gòu)示意圖如圖2所示。

圖2 本系統(tǒng)的Hadoop架構(gòu)Fig.2 Hadoop architecture of the system

1）物理層。物理層是系統(tǒng)架構(gòu)的底層硬件資源，除了實(shí)現(xiàn)通信、數(shù)據(jù)傳輸?shù)裙δ芡?，還為上層提供存儲(chǔ)、運(yùn)算資源。

2）存儲(chǔ)層及數(shù)據(jù)層?；贖DFS系統(tǒng)和HBase數(shù)據(jù)庫的數(shù)據(jù)存儲(chǔ)層負(fù)責(zé)地質(zhì)測(cè)繪數(shù)據(jù)的存儲(chǔ)管理、查詢檢索，在系統(tǒng)架構(gòu)下實(shí)現(xiàn)了數(shù)據(jù)輸入、云存儲(chǔ)、日志記錄、數(shù)據(jù)遷移、安全管理、索引等服務(wù)。

3）邏輯層?；贛apReduce模型的邏輯層是Ha-doop系統(tǒng)框架的核心層，在系統(tǒng)框架內(nèi)充當(dāng)著數(shù)據(jù)預(yù)處理器、接口分析機(jī)、查詢引擎等角色，對(duì)于系統(tǒng)運(yùn)行發(fā)揮著重要作用。

4）網(wǎng)絡(luò)及接口層。網(wǎng)絡(luò)及接口層利用路由選擇算法對(duì)子網(wǎng)之間的通信進(jìn)行控制，包括信息傳輸、數(shù)據(jù)維護(hù)、連接切斷等，在系統(tǒng)架構(gòu)內(nèi)實(shí)現(xiàn)了查詢檢索、算法接口、空間分析等功能。

5）應(yīng)用層。應(yīng)用層位于Hadoop架構(gòu)的頂端，它直接面向用戶，為用戶提供數(shù)據(jù)挖掘、數(shù)據(jù)分析、數(shù)據(jù)操作、資源調(diào)控等服務(wù)，并且對(duì)各項(xiàng)服務(wù)進(jìn)行統(tǒng)籌協(xié)調(diào)，在系統(tǒng)架構(gòu)內(nèi)實(shí)現(xiàn)了網(wǎng)絡(luò)、應(yīng)用程序與用戶之間的聯(lián)結(jié)功能。

3 系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

3.1 地質(zhì)數(shù)據(jù)云存儲(chǔ)設(shè)計(jì)與實(shí)現(xiàn)

因?yàn)榈刭|(zhì)測(cè)繪數(shù)據(jù)具有體量大、種類多的特點(diǎn)，本文采用HDFS文件管理系統(tǒng)對(duì)數(shù)據(jù)進(jìn)行存儲(chǔ)。與集中式數(shù)據(jù)庫Oracle作對(duì)比，本文選用的HDFS系統(tǒng)將地質(zhì)數(shù)據(jù)分散存儲(chǔ)于Hadoop集群中，這種獨(dú)特的存儲(chǔ)管理方式有效保障了地質(zhì)測(cè)繪數(shù)據(jù)的高效處理和安全存儲(chǔ)。由于地質(zhì)測(cè)繪文件是由許多個(gè)子文件構(gòu)成的，每一個(gè)子文件的體量并不大，若是將這些子文件進(jìn)行單獨(dú)存儲(chǔ)，必然會(huì)大幅度降低數(shù)據(jù)處理效率，因而需要利用其它方法對(duì)小文件進(jìn)行預(yù)處理。對(duì)此，本文設(shè)計(jì)了小文件合并算法，首先對(duì)多個(gè)小文件進(jìn)行合并，然后再存儲(chǔ)于HDFS中，在MapReduce模型的配合下，能夠?qū)崿F(xiàn)高效的數(shù)據(jù)處理功能。具體實(shí)現(xiàn)如下圖所示。

圖3 基于HDFS的地質(zhì)數(shù)據(jù)云存儲(chǔ)Fig.3 Cloud storage of geological data based on HDFS

根據(jù)HDFS 的存儲(chǔ)特征，結(jié)合地質(zhì)測(cè)繪數(shù)據(jù)的特點(diǎn)，需要對(duì)地質(zhì)測(cè)繪小文件進(jìn)行合并處理，從而更加安全、高效地存儲(chǔ)于HDFS 中。HDFS 采用數(shù)據(jù)塊（Block）管理方式，一個(gè)Block的體量介于64~128MB之間。如若不對(duì)小文件進(jìn)行合并處理，則一個(gè)小文件就會(huì)占用一個(gè)Block，導(dǎo)致Block數(shù)量激增，繼而使得Name Node在運(yùn)算過程中占用大量?jī)?nèi)存，并且嚴(yán)重拉低Hadoop處理速率。對(duì)此，在清理冗余小文件的同時(shí)，還需對(duì)小文件進(jìn)行合并處理，從而保持Hadoop集群的高效運(yùn)行。

3.2 地質(zhì)數(shù)據(jù)MapReduce的計(jì)算模型設(shè)計(jì)與實(shí)現(xiàn)

MapReduce 并行編程模型按照Key 對(duì)海量地質(zhì)測(cè)繪數(shù)據(jù)進(jìn)行排序，并從中提取出有價(jià)信息，在此基礎(chǔ)上對(duì)原始數(shù)據(jù)進(jìn)行打包處理，并以打包后的SequenceFile 作為基礎(chǔ)單位進(jìn)行并行運(yùn)算，整體上提升了系統(tǒng)運(yùn)算效率。具體實(shí)現(xiàn)流程如圖4所示。

圖4 MapReduce模型的工作流程Fig.4 Workflow of MapReduce model

3.3 系統(tǒng)負(fù)載平衡設(shè)計(jì)與實(shí)現(xiàn)

在Hadoop集群的運(yùn)行過程中，總是會(huì)持續(xù)不斷地進(jìn)行著新建、檢索、讀取、分析、清除等操作，這使得集群內(nèi)部不同DataNode上的磁盤空間使用率存在顯著差別。在Hadoop集群內(nèi)部DataNode上的磁盤空間已趨近于飽和的情況下，若是管理員繼續(xù)增加一批DataNode，這一操作不會(huì)影響原有DataNode磁盤使用率，但卻會(huì)出現(xiàn)新增DataNode 磁盤使用率偏低的問題，從而破壞DataNode吞吐量的負(fù)載平衡，并且影響數(shù)據(jù)I/O的并發(fā)運(yùn)算。因此，有必要引用某種機(jī)制來維持集群中DataNode數(shù)據(jù)的均衡態(tài)，避免出現(xiàn)少數(shù)DataNode密集承載數(shù)據(jù)請(qǐng)求的情況，這不僅能夠提高用戶響應(yīng)速率，而且能夠防范因某一DataNode失效而造成系統(tǒng)宕機(jī)的風(fēng)險(xiǎn)，從而有效改善了Hadoop集群性能。

對(duì)此，在Hadoop系統(tǒng)中內(nèi)置了一套基于數(shù)據(jù)均衡算法的平衡（Balancer）機(jī)制，其命令符是Hadoop balanc-er ［-threshold＜threshold＞］，據(jù)此對(duì)各個(gè)DataNode進(jìn)行評(píng)估，并且維持DataNode數(shù)據(jù)處于均衡狀態(tài)。在以上命令符中，“threshold”指的是平衡閾值，其取值范圍是0~100%。在執(zhí)行Balancer機(jī)制時(shí)，若設(shè)定的threshold值過小，則需要投用更多資源和時(shí)間來實(shí)現(xiàn)DataNode數(shù)據(jù)的均衡分布。Balancer機(jī)制的實(shí)現(xiàn)步驟為：

1） Rebalancing Server 調(diào) 用 NameNode 對(duì)DataNode數(shù)據(jù)的分布情況進(jìn)行評(píng)估，并根據(jù)評(píng)估結(jié)果計(jì)算出Hadoop 集群的整體空間利用率以及各個(gè)DataNode節(jié)點(diǎn)上的磁盤利用率。

2）Rebalancing Server 確定待遷移的DataNode 數(shù)據(jù)，結(jié)合threshold值對(duì)DataNode進(jìn)行分類，規(guī)劃出最佳的Block遷移路線。

3）在遍歷各DataNode 結(jié)點(diǎn)以后，找尋到適宜進(jìn)行Block遷移的目標(biāo)結(jié)點(diǎn)，然后開啟Block遷移過程。

4）Proxy Source Data Node 復(fù)制一塊待遷移的Block，然后粘貼至目標(biāo)DataNode節(jié)點(diǎn)。

5）將原始Block清除，避免數(shù)據(jù)庫冗余。

6）目標(biāo)DataNode節(jié)點(diǎn)向Proxy Source Data Node發(fā)出遷移任務(wù)完結(jié)信號(hào)。

7）Proxy Source Data Node向Rebalancing Server發(fā)出遷移任務(wù)完結(jié)信號(hào)。在完成一輪DataNode數(shù)據(jù)遷移過程以后，若Hadoop集群仍未達(dá)到負(fù)載均衡標(biāo)準(zhǔn)，則需要再次執(zhí)行Balancer機(jī)制。根據(jù)經(jīng)驗(yàn)，在進(jìn)行5輪迭代以后，Hadoop集群通常即可實(shí)現(xiàn)負(fù)載均衡。

在評(píng)價(jià)各DataNode節(jié)點(diǎn)的負(fù)載時(shí)，本文選用了帶寬利用率NUi、內(nèi)存利用率MUi、CPU利用率CUi等三個(gè)參量，并根據(jù)主觀經(jīng)驗(yàn)賦予各項(xiàng)參量以特定的權(quán)值，在此基礎(chǔ)上求解出Hadoop集群的總負(fù)載：X1×CUi+X2×MUi+X3×NUi。需要說明的是，根據(jù)主觀經(jīng)驗(yàn)對(duì)參量NUi、MUi、CUi進(jìn)行賦權(quán)，這一方法雖然簡(jiǎn)易但不夠嚴(yán)謹(jǐn)，由此所得評(píng)估結(jié)果也難免與實(shí)際情況存在偏差。

針對(duì)于此，本文利用信息熵算法來確定各DataNode節(jié)點(diǎn)的負(fù)載值，該算法以實(shí)際負(fù)載值作為基礎(chǔ)，通過衡量一個(gè)隨機(jī)變量出現(xiàn)的期望值，同時(shí)兼顧指標(biāo)的變異性，最終客觀確定權(quán)重大小，以上過程擺脫了主觀經(jīng)驗(yàn)的干擾。依據(jù)信息熵算法，指標(biāo)值的變異程度越小，指標(biāo)信息熵越大，則該指標(biāo)的作用越小，其所對(duì)應(yīng)的權(quán)重越?。环磩t反之。

設(shè)定DataNode 節(jié)點(diǎn)i 的虛擬機(jī)數(shù)量為ni，那么，該節(jié)點(diǎn)所對(duì)應(yīng)的三項(xiàng)分量依次是

套用信息熵算法，執(zhí)行以下運(yùn)算過程：

1）假定存在n個(gè)屬性X1、X2……、Xn，構(gòu)建由它們的屬性值構(gòu)成的決策矩陣P。

4） 如果(r1j,…rmj)=(1/m,…1/m)，那 么Ej=1 ；如果(r1j,…rmj)=( 0,…0,1,0,…)，那么Ej=0；

5） 求解出屬性Xj對(duì)于方案的區(qū)分度：Fj=1-Ej，并利用式，j=1，2，3，...，n求解出屬性Xj的權(quán)值。

6）最后計(jì)算節(jié)點(diǎn)i的負(fù)載：

通過以上流程計(jì)算出各個(gè)節(jié)點(diǎn)的負(fù)載值，將負(fù)載值最大的節(jié)點(diǎn)設(shè)定為遷移虛擬機(jī)。

4 系統(tǒng)測(cè)試

4.1 虛擬機(jī)的安裝設(shè)置

根據(jù)VMware 虛擬機(jī)的運(yùn)行要求，用戶需要在Windows 10 及以上版本的操作系統(tǒng)中進(jìn)行安裝，然后啟用虛擬機(jī)workstation，嵌入VMware ESXi，最后在ESXi中部署Linux操作系統(tǒng)虛擬機(jī)。根據(jù)Hadoop架構(gòu)的配置要求，Linux 操作系統(tǒng)的版本及配置條件是： Red Hat Linux 2.6.32- 573.el6.x86- 64， Ja-va1.7.0-91，Hadoop2.7.2。

4.2 地質(zhì)測(cè)繪系統(tǒng)測(cè)試

為對(duì)系統(tǒng)性能進(jìn)行測(cè)試，在eclipse 中編寫代碼，并對(duì)平臺(tái)上傳和下載對(duì)應(yīng)函數(shù)的執(zhí)行時(shí)間進(jìn)行計(jì)算。通過前端頁面對(duì)事件進(jìn)行上傳、下載和記錄操作時(shí)的起止時(shí)間。由此，得到表1 的結(jié)果。根據(jù)結(jié)果看出，當(dāng)文件大小100M 時(shí)，上傳速度達(dá)到毫秒級(jí)；當(dāng)文件大于500M 時(shí)，上傳速度在10s 之內(nèi)；當(dāng)文件大于1G時(shí)，上傳時(shí)間約60s。當(dāng)文件大?。?G 時(shí)，上傳的速度會(huì)更慢。由此看出，當(dāng)文件大小不斷增大時(shí)，上傳文件的速度也會(huì)增加。

表1 上傳與下載文件的耗時(shí)Tab.1 Time consumption of uploading and downloading files

在文件下載方面，當(dāng)文件大小為30M時(shí)，下載所需時(shí)間為284μs；在文件大小為2.4GB時(shí)，下載所需時(shí)間為24s659μs。從該測(cè)試結(jié)果來看，即便是大于2GB的數(shù)據(jù)，下載所需時(shí)間仍可控制在秒級(jí)。因此，單個(gè)文件的下載所需時(shí)間能夠滿足地質(zhì)測(cè)繪數(shù)據(jù)下載要求。

5 結(jié)語

通過以上研究看出，在Hadoop 集群下，能大量存儲(chǔ)海量的地質(zhì)測(cè)繪數(shù)據(jù)。同時(shí)通過Balancer 機(jī)制實(shí)現(xiàn)了集群負(fù)載的平衡，很好的實(shí)現(xiàn)了地質(zhì)測(cè)繪系統(tǒng)服務(wù)器的均衡。而測(cè)試結(jié)果也表明，在本服務(wù)集群下，本系統(tǒng)下載文件的耗時(shí)時(shí)間明顯較短，由此驗(yàn)證了本系統(tǒng)構(gòu)建的可行性。而通過以上構(gòu)建，也為地質(zhì)測(cè)繪數(shù)據(jù)的存儲(chǔ)等提供了新的方式。