董 晉
(中晉環(huán)境科技有限公司,太原 030000)
隨著地質(zhì)測繪工作的開展和深入,對于如何提升測繪工作中的檢索效率和對產(chǎn)生的大量數(shù)據(jù)進行管理,是測繪工作中需要解決的問題。我國常用依托關(guān)系型數(shù)據(jù)庫對測繪工作中產(chǎn)生的數(shù)據(jù)進行管理,再對數(shù)據(jù)檢索系統(tǒng)和管理模塊進行構(gòu)建,進而提高數(shù)據(jù)的存儲。在地質(zhì)測繪工作中,包括了關(guān)系型數(shù)據(jù)和各類異構(gòu)數(shù)據(jù)。對此,傳統(tǒng)的測繪數(shù)據(jù)管理方法在如今的測繪界已不適用。在云計算技術(shù)興起的當(dāng)下,Hadoop框架不僅能夠存儲大量數(shù)據(jù),也能儲存種類不同的數(shù)據(jù),因此成為了當(dāng)前的應(yīng)用熱點。例如潘云(2020)和王永才(2020)會將Hadoop 框架運用與系統(tǒng)構(gòu)建以及數(shù)據(jù)挖掘工作中,以此來提升挖掘數(shù)據(jù)的效率和系統(tǒng)的運行效率。不難看出,Hadoop 技術(shù)逐漸受到了人們的關(guān)注,因此本文以Hadoop 為前提,提出了基于大數(shù)據(jù)對地質(zhì)測繪產(chǎn)生大量數(shù)據(jù)的存儲及管理方案,在該方案的基礎(chǔ)上對該系統(tǒng)進行了設(shè)計。
由于地質(zhì)條件的差異性,造成了地質(zhì)測繪數(shù)據(jù)的多樣性、異構(gòu)性、隨機性、非線性、相關(guān)性等特點。因為地質(zhì)測繪的數(shù)據(jù)具有多樣性,例如地質(zhì)元素、構(gòu)造和地質(zhì)形成等。因此,從以上分析來看,地質(zhì)測繪管理系統(tǒng)應(yīng)當(dāng)兼具多維度、結(jié)構(gòu)化與非結(jié)構(gòu)化并用等特性。HDFS文件管理系統(tǒng)采用分布式架構(gòu)設(shè)計,能夠順序訪問機構(gòu)化、非結(jié)構(gòu)化數(shù)據(jù),對于硬件條件的要求較低;HBase數(shù)據(jù)庫對于硬件條件的要求較高,能夠快速隨機訪問數(shù)據(jù)。顯然,將HDFS 系統(tǒng)與HBase數(shù)據(jù)庫進行結(jié)合,則能夠更好地實現(xiàn)海量地質(zhì)測繪數(shù)據(jù)的存儲、訪問及管理。對此,本文利用HDFS系統(tǒng)來存儲地質(zhì)測繪數(shù)據(jù)。其中,當(dāng)?shù)刭|(zhì)數(shù)據(jù)量過多時可直接存儲到HDFS系統(tǒng),體量較小的地質(zhì)數(shù)據(jù)直接經(jīng)過文件合并再存儲到HDFS 系統(tǒng)。利用HBase 數(shù)據(jù)庫來存儲地質(zhì)數(shù)據(jù)條目的索引信息,從而實現(xiàn)兩類文件管理系統(tǒng)的結(jié)合。當(dāng)一個HDFS文件發(fā)生變化,與之相對應(yīng)的HBase索引數(shù)據(jù)也會同步更新,從而提升數(shù)據(jù)檢索效率。具體架構(gòu)示意圖如圖1所示。
圖1 Hadoop系統(tǒng)架構(gòu)Fig.1 Hadoop system architecture
Hadoop架構(gòu)的特點有以下3點:
1)分布式文件管理系統(tǒng)HDFS:該系統(tǒng)可部署在普通PC 服務(wù)器集群中,內(nèi)置流式訪問接口,嵌入“一次寫入、多次讀取”的文件訪問模型,不僅能夠?qū)崿F(xiàn)可靠的數(shù)據(jù)存儲功能,而且其數(shù)據(jù)訪問速率優(yōu)于集中式文件管理系統(tǒng)。此外,HDFS 系統(tǒng)的容錯能力強,且支持跨平臺移植。
2)分布式處理模型MapReduce:該模型集中了Map與Reduce機制,能夠?qū)?fù)雜問題簡化分解為多個彼此獨立的子任務(wù),然后引用計算處理節(jié)點對各子任務(wù)進行高效處理,整體上保證了對于海量數(shù)據(jù)的處理功能。此外,MapReduce模型利用數(shù)據(jù)/代碼互定位技術(shù)切斷了各節(jié)點間的聯(lián)系,從而為單項任務(wù)的處理創(chuàng)造了條件;MapReduce模型還為系統(tǒng)開發(fā)中的系統(tǒng)層設(shè)計提供了技術(shù)支持。
3)非關(guān)系型數(shù)據(jù)庫HBase:作為一種新型的分布式數(shù)據(jù)庫,HBase可用于存儲半結(jié)構(gòu)化、非結(jié)構(gòu)化的松散數(shù)據(jù),并且通過主鍵range實現(xiàn)了快速檢索功能,在應(yīng)用中表現(xiàn)出性能優(yōu)越、實時讀寫等優(yōu)勢特征。
針對Hadoop 特點和測繪管理系統(tǒng)的業(yè)務(wù)進行分析,把系統(tǒng)整體架構(gòu)分成存儲層、物理層和數(shù)據(jù)層等,架構(gòu)示意圖如圖2所示。
圖2 本系統(tǒng)的Hadoop架構(gòu)Fig.2 Hadoop architecture of the system
1)物理層。物理層是系統(tǒng)架構(gòu)的底層硬件資源,除了實現(xiàn)通信、數(shù)據(jù)傳輸?shù)裙δ芡?,還為上層提供存儲、運算資源。
2)存儲層及數(shù)據(jù)層。基于HDFS系統(tǒng)和HBase數(shù)據(jù)庫的數(shù)據(jù)存儲層負責(zé)地質(zhì)測繪數(shù)據(jù)的存儲管理、查詢檢索,在系統(tǒng)架構(gòu)下實現(xiàn)了數(shù)據(jù)輸入、云存儲、日志記錄、數(shù)據(jù)遷移、安全管理、索引等服務(wù)。
3)邏輯層?;贛apReduce模型的邏輯層是Ha-doop系統(tǒng)框架的核心層,在系統(tǒng)框架內(nèi)充當(dāng)著數(shù)據(jù)預(yù)處理器、接口分析機、查詢引擎等角色,對于系統(tǒng)運行發(fā)揮著重要作用。
4)網(wǎng)絡(luò)及接口層。網(wǎng)絡(luò)及接口層利用路由選擇算法對子網(wǎng)之間的通信進行控制,包括信息傳輸、數(shù)據(jù)維護、連接切斷等,在系統(tǒng)架構(gòu)內(nèi)實現(xiàn)了查詢檢索、算法接口、空間分析等功能。
5)應(yīng)用層。應(yīng)用層位于Hadoop架構(gòu)的頂端,它直接面向用戶,為用戶提供數(shù)據(jù)挖掘、數(shù)據(jù)分析、數(shù)據(jù)操作、資源調(diào)控等服務(wù),并且對各項服務(wù)進行統(tǒng)籌協(xié)調(diào),在系統(tǒng)架構(gòu)內(nèi)實現(xiàn)了網(wǎng)絡(luò)、應(yīng)用程序與用戶之間的聯(lián)結(jié)功能。
因為地質(zhì)測繪數(shù)據(jù)具有體量大、種類多的特點,本文采用HDFS文件管理系統(tǒng)對數(shù)據(jù)進行存儲。與集中式數(shù)據(jù)庫Oracle作對比,本文選用的HDFS系統(tǒng)將地質(zhì)數(shù)據(jù)分散存儲于Hadoop集群中,這種獨特的存儲管理方式有效保障了地質(zhì)測繪數(shù)據(jù)的高效處理和安全存儲。由于地質(zhì)測繪文件是由許多個子文件構(gòu)成的,每一個子文件的體量并不大,若是將這些子文件進行單獨存儲,必然會大幅度降低數(shù)據(jù)處理效率,因而需要利用其它方法對小文件進行預(yù)處理。對此,本文設(shè)計了小文件合并算法,首先對多個小文件進行合并,然后再存儲于HDFS中,在MapReduce模型的配合下,能夠?qū)崿F(xiàn)高效的數(shù)據(jù)處理功能。具體實現(xiàn)如下圖所示。
圖3 基于HDFS的地質(zhì)數(shù)據(jù)云存儲Fig.3 Cloud storage of geological data based on HDFS
根據(jù)HDFS 的存儲特征,結(jié)合地質(zhì)測繪數(shù)據(jù)的特點,需要對地質(zhì)測繪小文件進行合并處理,從而更加安全、高效地存儲于HDFS 中。HDFS 采用數(shù)據(jù)塊(Block)管理方式,一個Block的體量介于64~128MB之間。如若不對小文件進行合并處理,則一個小文件就會占用一個Block,導(dǎo)致Block數(shù)量激增,繼而使得Name Node在運算過程中占用大量內(nèi)存,并且嚴重拉低Hadoop處理速率。對此,在清理冗余小文件的同時,還需對小文件進行合并處理,從而保持Hadoop集群的高效運行。
MapReduce 并行編程模型按照Key 對海量地質(zhì)測繪數(shù)據(jù)進行排序,并從中提取出有價信息,在此基礎(chǔ)上對原始數(shù)據(jù)進行打包處理,并以打包后的SequenceFile 作為基礎(chǔ)單位進行并行運算,整體上提升了系統(tǒng)運算效率。具體實現(xiàn)流程如圖4所示。
圖4 MapReduce模型的工作流程Fig.4 Workflow of MapReduce model
在Hadoop集群的運行過程中,總是會持續(xù)不斷地進行著新建、檢索、讀取、分析、清除等操作,這使得集群內(nèi)部不同DataNode上的磁盤空間使用率存在顯著差別。在Hadoop集群內(nèi)部DataNode上的磁盤空間已趨近于飽和的情況下,若是管理員繼續(xù)增加一批DataNode,這一操作不會影響原有DataNode磁盤使用率,但卻會出現(xiàn)新增DataNode 磁盤使用率偏低的問題,從而破壞DataNode吞吐量的負載平衡,并且影響數(shù)據(jù)I/O的并發(fā)運算。因此,有必要引用某種機制來維持集群中DataNode數(shù)據(jù)的均衡態(tài),避免出現(xiàn)少數(shù)DataNode密集承載數(shù)據(jù)請求的情況,這不僅能夠提高用戶響應(yīng)速率,而且能夠防范因某一DataNode失效而造成系統(tǒng)宕機的風(fēng)險,從而有效改善了Hadoop集群性能。
對此,在Hadoop系統(tǒng)中內(nèi)置了一套基于數(shù)據(jù)均衡算法的平衡(Balancer)機制,其命令符是Hadoop balanc-er [-threshold<threshold>],據(jù)此對各個DataNode進行評估,并且維持DataNode數(shù)據(jù)處于均衡狀態(tài)。在以上命令符中,“threshold”指的是平衡閾值,其取值范圍是0~100%。在執(zhí)行Balancer機制時,若設(shè)定的threshold值過小,則需要投用更多資源和時間來實現(xiàn)DataNode數(shù)據(jù)的均衡分布。Balancer機制的實現(xiàn)步驟為:
1) Rebalancing Server 調(diào) 用 NameNode 對DataNode數(shù)據(jù)的分布情況進行評估,并根據(jù)評估結(jié)果計算出Hadoop 集群的整體空間利用率以及各個DataNode節(jié)點上的磁盤利用率。
2)Rebalancing Server 確定待遷移的DataNode 數(shù)據(jù),結(jié)合threshold值對DataNode進行分類,規(guī)劃出最佳的Block遷移路線。
3)在遍歷各DataNode 結(jié)點以后,找尋到適宜進行Block遷移的目標(biāo)結(jié)點,然后開啟Block遷移過程。
4)Proxy Source Data Node 復(fù)制一塊待遷移的Block,然后粘貼至目標(biāo)DataNode節(jié)點。
5)將原始Block清除,避免數(shù)據(jù)庫冗余。
6)目標(biāo)DataNode節(jié)點向Proxy Source Data Node發(fā)出遷移任務(wù)完結(jié)信號。
7)Proxy Source Data Node向Rebalancing Server發(fā)出遷移任務(wù)完結(jié)信號。在完成一輪DataNode數(shù)據(jù)遷移過程以后,若Hadoop集群仍未達到負載均衡標(biāo)準(zhǔn),則需要再次執(zhí)行Balancer機制。根據(jù)經(jīng)驗,在進行5輪迭代以后,Hadoop集群通常即可實現(xiàn)負載均衡。
在評價各DataNode節(jié)點的負載時,本文選用了帶寬利用率NUi、內(nèi)存利用率MUi、CPU利用率CUi等三個參量,并根據(jù)主觀經(jīng)驗賦予各項參量以特定的權(quán)值,在此基礎(chǔ)上求解出Hadoop集群的總負載:X1×CUi+X2×MUi+X3×NUi。需要說明的是,根據(jù)主觀經(jīng)驗對參量NUi、MUi、CUi進行賦權(quán),這一方法雖然簡易但不夠嚴謹,由此所得評估結(jié)果也難免與實際情況存在偏差。
針對于此,本文利用信息熵算法來確定各DataNode節(jié)點的負載值,該算法以實際負載值作為基礎(chǔ),通過衡量一個隨機變量出現(xiàn)的期望值,同時兼顧指標(biāo)的變異性,最終客觀確定權(quán)重大小,以上過程擺脫了主觀經(jīng)驗的干擾。依據(jù)信息熵算法,指標(biāo)值的變異程度越小,指標(biāo)信息熵越大,則該指標(biāo)的作用越小,其所對應(yīng)的權(quán)重越小;反則反之。
設(shè)定DataNode 節(jié)點i 的虛擬機數(shù)量為ni,那么,該節(jié)點所對應(yīng)的三項分量依次是
套用信息熵算法,執(zhí)行以下運算過程:
1)假定存在n個屬性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對于方案的區(qū)分度:Fj=1-Ej,并利用式,j=1,2,3,...,n求解出屬性Xj的權(quán)值。
6)最后計算節(jié)點i的負載:
通過以上流程計算出各個節(jié)點的負載值,將負載值最大的節(jié)點設(shè)定為遷移虛擬機。
根據(jù)VMware 虛擬機的運行要求,用戶需要在Windows 10 及以上版本的操作系統(tǒng)中進行安裝,然后啟用虛擬機workstation,嵌入VMware ESXi,最后在ESXi中部署Linux操作系統(tǒng)虛擬機。根據(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。
為對系統(tǒng)性能進行測試,在eclipse 中編寫代碼,并對平臺上傳和下載對應(yīng)函數(shù)的執(zhí)行時間進行計算。通過前端頁面對事件進行上傳、下載和記錄操作時的起止時間。由此,得到表1 的結(jié)果。根據(jù)結(jié)果看出,當(dāng)文件大小100M 時,上傳速度達到毫秒級;當(dāng)文件大于500M 時,上傳速度在10s 之內(nèi);當(dāng)文件大于1G時,上傳時間約60s。當(dāng)文件大?。?G 時,上傳的速度會更慢。由此看出,當(dāng)文件大小不斷增大時,上傳文件的速度也會增加。
表1 上傳與下載文件的耗時Tab.1 Time consumption of uploading and downloading files
在文件下載方面,當(dāng)文件大小為30M時,下載所需時間為284μs;在文件大小為2.4GB時,下載所需時間為24s659μs。從該測試結(jié)果來看,即便是大于2GB的數(shù)據(jù),下載所需時間仍可控制在秒級。因此,單個文件的下載所需時間能夠滿足地質(zhì)測繪數(shù)據(jù)下載要求。
通過以上研究看出,在Hadoop 集群下,能大量存儲海量的地質(zhì)測繪數(shù)據(jù)。同時通過Balancer 機制實現(xiàn)了集群負載的平衡,很好的實現(xiàn)了地質(zhì)測繪系統(tǒng)服務(wù)器的均衡。而測試結(jié)果也表明,在本服務(wù)集群下,本系統(tǒng)下載文件的耗時時間明顯較短,由此驗證了本系統(tǒng)構(gòu)建的可行性。而通過以上構(gòu)建,也為地質(zhì)測繪數(shù)據(jù)的存儲等提供了新的方式。