池亞平 楊垠坦 許 萍 楊建喜(北京電子科技學(xué)院通信工程系 北京 00070)(西安電子科技大學(xué)通信工程學(xué)院 陜西 西安 7007)(中國科學(xué)院信息工程研究所中國科學(xué)院網(wǎng)絡(luò)測評技術(shù)重點(diǎn)實(shí)驗(yàn)室 北京 0009)

0 引 言

云計(jì)算是當(dāng)前IT行業(yè)研究的主流趨勢，各互聯(lián)網(wǎng)巨頭皆向云計(jì)算模式轉(zhuǎn)型，亞馬遜、谷歌、阿里巴巴、華為等都陸續(xù)推出自己的云平臺。監(jiān)控技術(shù)則是掌握云平臺運(yùn)行狀況，并根據(jù)監(jiān)控?cái)?shù)據(jù)預(yù)測分析云平臺未來態(tài)勢的有效方法[1]。云平臺的穩(wěn)定性是提升云平臺提供服務(wù)的質(zhì)量的重要保障，因此，有必要對云平臺的資源及服務(wù)狀態(tài)進(jìn)行實(shí)時(shí)監(jiān)控。但是，在實(shí)際部署中，每個(gè)云平臺有多個(gè)數(shù)據(jù)中心，每個(gè)數(shù)據(jù)中心有上千個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)又要提供多項(xiàng)服務(wù)，實(shí)時(shí)產(chǎn)生的監(jiān)控?cái)?shù)據(jù)量達(dá)千萬級。同時(shí)在運(yùn)維監(jiān)控系統(tǒng)中，采集數(shù)據(jù)非常頻繁，一般每隔幾秒或幾十秒就要遍歷所有設(shè)備進(jìn)行采集，監(jiān)控系統(tǒng)必然要面臨海量的監(jiān)控?cái)?shù)據(jù)存儲與處理問題。而且傳統(tǒng)的關(guān)系型數(shù)據(jù)庫并不適合用于存儲具有時(shí)序性、異構(gòu)性的監(jiān)控?cái)?shù)據(jù)。如何對海量監(jiān)控?cái)?shù)據(jù)進(jìn)行高效的存儲，是一個(gè)重大挑戰(zhàn)。

近年來，國內(nèi)外學(xué)者開展了關(guān)于云平臺監(jiān)控系統(tǒng)設(shè)計(jì)及云監(jiān)控?cái)?shù)據(jù)存儲的相關(guān)研究。洪斌等[2]闡述了云監(jiān)控系統(tǒng)所面臨的一些問題，但并沒有給出相應(yīng)具體的解決方案；單莘等[3]提出了基于大數(shù)據(jù)流處理的監(jiān)控方案，解決了大規(guī)模云計(jì)算平臺監(jiān)控問題，并提高了監(jiān)控的實(shí)時(shí)性，但是其監(jiān)控層次單一，只能監(jiān)控主機(jī)狀態(tài)；陳琳等[4]提出了一種多層次可擴(kuò)展的監(jiān)控框架，實(shí)現(xiàn)了應(yīng)用服務(wù)、中間件和基礎(chǔ)設(shè)施資源等不同層次的監(jiān)控。從上述研究文獻(xiàn)可以看出，隨著云監(jiān)控技術(shù)的發(fā)展，對云平臺的監(jiān)控逐步細(xì)化，這將產(chǎn)生更多監(jiān)控?cái)?shù)據(jù)，但是這些監(jiān)控方案并未提出行之有效的監(jiān)控?cái)?shù)據(jù)的存儲和處理方案。文獻(xiàn)[5-6]提出的方案降低了數(shù)據(jù)冗余，提高了對海量數(shù)據(jù)的存儲效率，但其只針對關(guān)系型數(shù)據(jù)庫，并不適用于異構(gòu)數(shù)據(jù)。相比之下，非關(guān)系型數(shù)據(jù)庫更適合監(jiān)控?cái)?shù)據(jù)的存儲。鞠瑞等[7]提出一種異構(gòu)監(jiān)控?cái)?shù)據(jù)存儲方法，以反范式化為基礎(chǔ)，采用統(tǒng)一數(shù)據(jù)表達(dá)方式兼容異構(gòu)源數(shù)據(jù)，提高了寫入效率，實(shí)現(xiàn)了云平臺監(jiān)控?cái)?shù)據(jù)更為高效的存儲，但是并沒有解決單機(jī)處理大規(guī)模數(shù)據(jù)時(shí)具有的計(jì)算瓶頸問題。

本文通過大數(shù)據(jù)平臺Hadoop搭建云計(jì)算環(huán)境，采用提升字段法改進(jìn)的寬表HBase非關(guān)系型數(shù)據(jù)庫模型存儲時(shí)序的和異構(gòu)的監(jiān)控?cái)?shù)據(jù)，針對監(jiān)控?cái)?shù)據(jù)中的流量數(shù)據(jù)利用MapReduce并行計(jì)算架構(gòu)對監(jiān)控?cái)?shù)據(jù)進(jìn)行分布式處理。經(jīng)測試提高了數(shù)據(jù)存儲和檢索速率，突破單機(jī)監(jiān)控模型計(jì)算瓶頸，提升了對監(jiān)控?cái)?shù)據(jù)的分析效率。

1 Hadoop相關(guān)技術(shù)

Hadoop是Apache最大一個(gè)開源項(xiàng)目，可編寫和運(yùn)行分布式應(yīng)用處理大規(guī)模數(shù)據(jù)。包含HDFS、MapReduce、HBase、Yarn、Zookeeper、Hive等工具。其生態(tài)系統(tǒng)如圖1所示。

圖1 Hadoop生態(tài)系統(tǒng)

1.1 HBase數(shù)據(jù)庫

監(jiān)控系統(tǒng)采集數(shù)據(jù)本質(zhì)上是一種時(shí)間序列數(shù)據(jù)。本文要研究解決的是云監(jiān)控系統(tǒng)中大規(guī)模時(shí)間序列數(shù)據(jù)的存儲與處理問題，使得監(jiān)控系統(tǒng)性能不會隨著數(shù)據(jù)規(guī)模的增大而下降，從而造成系統(tǒng)故障或延遲的問題。目前，時(shí)間序列數(shù)據(jù)存儲系統(tǒng)按照底層技術(shù)的不同主要分為三類：基于文件的簡單存儲、基于關(guān)系型數(shù)據(jù)庫和基于非關(guān)系型數(shù)據(jù)庫。而非關(guān)系型數(shù)據(jù)庫最適合云環(huán)境下的監(jiān)控?cái)?shù)據(jù)存儲需求。HBase是一個(gè)開源的、分布式的NoSQL數(shù)據(jù)庫，具有良好的線性可擴(kuò)展性、強(qiáng)一致性及出色的讀寫性能，主要用于大規(guī)模數(shù)據(jù)的存儲[8]。

圖2所示為HBase的基本組成架構(gòu)，HBase建立在Hadoop分布式文件系統(tǒng)HDFS之上，依賴于Zookeeper提供集群的同步和協(xié)調(diào)，數(shù)據(jù)以規(guī)定的格式存儲在HBase數(shù)據(jù)庫中，數(shù)據(jù)庫文件則存儲在HDFS服務(wù)中。

圖2 HBase基本架構(gòu)

1.2 MapReduce并行計(jì)算

MapReduce是一種用于大規(guī)模數(shù)據(jù)分布式處理的編程模型，提供了一個(gè)龐大的、設(shè)計(jì)精良的并行計(jì)算框架。面對大規(guī)模的數(shù)據(jù)處理，MapReduce基于對數(shù)據(jù)“分而治之”的思想來完成并行化的計(jì)算處理，如圖3所示。

圖3 MapRedue數(shù)據(jù)基本處理思想

流量監(jiān)控技術(shù)對云平臺中的網(wǎng)絡(luò)流量進(jìn)行全方位的監(jiān)控和統(tǒng)計(jì)分析，發(fā)現(xiàn)網(wǎng)絡(luò)存在的安全問題，使云平臺的安全、穩(wěn)定運(yùn)行得到有力的保障[9-10]。針對網(wǎng)絡(luò)流量數(shù)據(jù)量大的特點(diǎn)采用MapReduce對其進(jìn)行分析，提升對流量監(jiān)控?cái)?shù)據(jù)的處理效率。

2 方案設(shè)計(jì)

2.1 總體方案設(shè)計(jì)

針對云環(huán)境下監(jiān)控?cái)?shù)據(jù)的存儲和處理需求，本文利用Hadoop提供的存儲和處理框架，改進(jìn)海量時(shí)序數(shù)據(jù)下HBase數(shù)據(jù)庫的存儲結(jié)構(gòu)，并引入分布式處理思想，解決單機(jī)處理流量數(shù)據(jù)的計(jì)算瓶頸問題。方案總體框架如圖4所示。

圖4 方案總體框架

該方案可分為兩個(gè)模塊：HBase存儲模塊和MapReduce處理模塊。在HBase模塊中，先將時(shí)序監(jiān)控?cái)?shù)據(jù)的行健(row_key)離散化，然后根據(jù)新行健(new_row_key)把數(shù)據(jù)分配到不同存儲區(qū)域，最后按一定的表規(guī)則存儲于相應(yīng)服務(wù)器。在MapReduce處理模塊中，首先客戶節(jié)點(diǎn)創(chuàng)建新的作業(yè)并將流量數(shù)據(jù)復(fù)制到HBase數(shù)據(jù)庫；然后作業(yè)管理節(jié)點(diǎn)把作業(yè)分成若干不同的子任務(wù)，并放入任務(wù)池；接著處理單元在資源池中領(lǐng)取子任務(wù)，子任務(wù)在處理單元經(jīng)Map和Reduce兩個(gè)階段的處理分別向Hbase返回中間值和最終結(jié)果。

2.2 HBase存儲模塊設(shè)計(jì)

從上述研究可知HBase數(shù)據(jù)庫適合存儲時(shí)序的監(jiān)控?cái)?shù)據(jù)，但是在實(shí)際應(yīng)用中仍有兩個(gè)問題需要解決。其一是存儲海量監(jiān)控?cái)?shù)據(jù)時(shí)的“熱點(diǎn)現(xiàn)象”，其二是大數(shù)據(jù)下HBase表檢索的效率問題。為解決這兩個(gè)問題，分別用提升字段法和寬表存儲結(jié)構(gòu)改進(jìn)HBase數(shù)據(jù)庫在海量監(jiān)控?cái)?shù)據(jù)下的存儲模型。

2.2.1 提升字段法HBase存儲方案設(shè)計(jì)

一條監(jiān)控記錄包括時(shí)間、測量值及監(jiān)測指標(biāo)等信息。在時(shí)序監(jiān)控?cái)?shù)據(jù)中，行健代表事件發(fā)生的時(shí)間。HBase對所有記錄按行健進(jìn)行字典排序，相鄰記錄在存儲時(shí)亦是相鄰存放的。這也就使得時(shí)序數(shù)據(jù)會被存儲到一個(gè)具有特定起始鍵和停止鍵的區(qū)域中[8]。由于一個(gè)區(qū)域只能被一個(gè)服務(wù)器管理，所以所有的更新都會集中在一臺服務(wù)器上。這將引起 “讀寫熱點(diǎn)”現(xiàn)象，如果寫入數(shù)據(jù)過分集中將導(dǎo)致存儲性能下降。圖5展示了大量數(shù)據(jù)按順序鍵方式寫入HBase所造成的“熱點(diǎn)現(xiàn)象。

圖5 熱點(diǎn)現(xiàn)象

通過上面分析，解決上述”存儲熱點(diǎn)”問題關(guān)鍵在于行健的設(shè)計(jì)，需通過設(shè)計(jì)離散的行健將數(shù)據(jù)分散到所有存儲服務(wù)器上，而不能直接將時(shí)間戳作為行健。

為解決這一問題主要有下三種方法：

(1) 加鹽法 這種方法是通過給原來的行鍵(row_key)添加Hash前綴來保證數(shù)據(jù)的寫操作均勻地分布到各個(gè)存儲服務(wù)器上，起到負(fù)載均衡的效果，提升數(shù)據(jù)庫的寫入性能。該方法先對時(shí)間戳進(jìn)行Hash運(yùn)算，然后將得到的值對存儲服務(wù)器的個(gè)數(shù)取模。

(2) 行鍵隨機(jī)化法 這種方式是將行鍵隨機(jī)化，可以采用散列函數(shù)將行鍵分散到所有的存儲服務(wù)器上，例如：

row_key = MD5(timestamp)

這種方法生成的行鍵是隨機(jī)的，比加鹽法中的行健還要分散。

(3) 提升字段法 提升字段是指將時(shí)間戳字段移開或添加其他字段作為前綴，利用組合行鍵的思想來讓連續(xù)遞增的時(shí)間戳在行鍵中的位置后移。如果原行鍵已經(jīng)包含了多個(gè)字段，則調(diào)整空位的位置就可以。如果行鍵只包含時(shí)間戳，則需要將其他字段從列鍵或值中提取出來，然后放到行鍵的前端。使用提升字段法后，一條記錄的行鍵(row_key)如下：

row_key = Cpu.Host1-1461056400

當(dāng)監(jiān)控指標(biāo)較多時(shí)，row_key會很分散，所有的更新操作將被分散開，最后能夠得到與加鹽法類似的效果。

這三種方法各有利弊，為此本文對不同行鍵下HBase數(shù)據(jù)庫的讀寫性能進(jìn)行了測試，測試數(shù)據(jù)大約100萬行。測試結(jié)果如表1所示。

表1 不同行鍵下HBase的讀寫性能 ops/sec

從實(shí)驗(yàn)結(jié)果可以看出，提升字段法和加鹽法的綜合性能較好，兩者效果相近。但監(jiān)控系統(tǒng)一般要進(jìn)行大量的寫操作，讀操作較少，所以要求寫性能較好。同時(shí)，對監(jiān)控?cái)?shù)據(jù)來說需要根據(jù)監(jiān)控指標(biāo)名稱能夠進(jìn)行快速查詢一段時(shí)間內(nèi)監(jiān)測數(shù)據(jù)的結(jié)果，而加鹽法不利用數(shù)據(jù)檢索。因此，本文最終選擇基于字段提升的行鍵設(shè)計(jì)方法。

2.2.2 基于HBase的寬表存儲結(jié)構(gòu)設(shè)計(jì)

根據(jù)上述實(shí)驗(yàn)結(jié)果，解決了大量數(shù)據(jù)在寫入時(shí)的 “熱點(diǎn)現(xiàn)象”的同時(shí)。為了能匹配MapReduce的處理速度，還要解決HBase檢索效率的問題，這就要求對HBase中的數(shù)據(jù)進(jìn)行檢索的延時(shí)盡可能小，為了提高數(shù)據(jù)庫檢索速度，本文設(shè)計(jì)了一種寬表的存儲結(jié)構(gòu)。

HBase每張表都有一個(gè)或者多個(gè)列族，每個(gè)列族中存放多個(gè)列，HBase表每行可以擁有多達(dá)上百萬的列，這種結(jié)構(gòu)可以用來在每行存放多個(gè)數(shù)值，這就使數(shù)據(jù)可以被更高速地檢索。因?yàn)椋O(jiān)控代理每隔幾秒就采集一次數(shù)據(jù)，這樣產(chǎn)生的數(shù)據(jù)點(diǎn)規(guī)模是非常大的，如果每個(gè)數(shù)據(jù)點(diǎn)占一行，則表的行數(shù)將相當(dāng)多，而掃描數(shù)據(jù)的最大速度部分取決于需要掃描的行的數(shù)據(jù)，減少行的數(shù)量就大幅減少了一部分檢索開銷，檢索速度就會大大提升。圖6所示為監(jiān)控?cái)?shù)據(jù)存儲表結(jié)構(gòu)。

RowKeyColumnFamily：t+0+3+10…+381…+3599Cpu．Host1-14610564000．690．500．41Cpu．Host1-14610600000．440．50Mem．Host1-14610564000．230．36

圖6 基于提升字段法的寬表存儲結(jié)構(gòu)

該表結(jié)構(gòu)中，將一小時(shí)的數(shù)據(jù)存儲為一行，行鍵為監(jiān)控指標(biāo)和整點(diǎn)時(shí)間戳的組合，每一列對應(yīng)具體時(shí)間點(diǎn)的監(jiān)控?cái)?shù)據(jù)。以2016-04-19 17:06:18這個(gè)時(shí)間點(diǎn)采集的服務(wù)器host1的CPU利用率(41%)為例(圖6中的陰影部分)。

首先，將這個(gè)時(shí)間點(diǎn)轉(zhuǎn)化為時(shí)間戳1461056781，則17:00對應(yīng)的時(shí)間戳為：

TimeStamp= 1461056781-(1461056781 mod 3600)=

1461056781-381=1461056400

圖6中，行鍵為：row_key=cpu.host1-1461056400；列名為：381；測量值為：41。

如果隔1秒采集一次監(jiān)控?cái)?shù)據(jù)，則該存儲方式將使得HBase存儲表的行數(shù)縮小為原來的1/3 600，當(dāng)檢索一小時(shí)內(nèi)數(shù)據(jù)時(shí)只需掃描一行數(shù)據(jù)。而原來高表的存儲方式下每個(gè)數(shù)據(jù)點(diǎn)存儲為一行，當(dāng)檢索一小時(shí)內(nèi)的監(jiān)控?cái)?shù)據(jù)時(shí)，需要掃描3 600行。

2.3 MapReduce處理模塊設(shè)計(jì)

在MapReduce處理模塊中，利用Hadoop提供的并行處理計(jì)算的功能，設(shè)計(jì)MapReduce流量統(tǒng)計(jì)分析程序?qū)Υ笠?guī)模網(wǎng)絡(luò)流量日志進(jìn)行快速處理，統(tǒng)計(jì)分析各個(gè)主機(jī)的網(wǎng)絡(luò)流量情況。這種數(shù)據(jù)處理方式突破了傳統(tǒng)單點(diǎn)網(wǎng)絡(luò)流量分析的局限性。

圖7所示為基于MapReduce的流量統(tǒng)計(jì)分析算法流程。

圖7 基于MapReduce的流量統(tǒng)計(jì)分析算法流程

首先，進(jìn)行數(shù)據(jù)劃分得到初始鍵值對，timestamp為該報(bào)文日志的采集時(shí)間，HeaderCut為一條采集的報(bào)文，即日志文件的一行。

Map階段：調(diào)用mapper的map()函數(shù)對每個(gè)單獨(dú)的鍵值對進(jìn)行處理，提取HeaderCut中網(wǎng)絡(luò)層協(xié)議報(bào)頭的IP字段和報(bào)文長度字段，輸出新的鍵值對，所有mapper輸出形成一個(gè)list()，具有相同健值ip的鍵值對被整合形成一個(gè)新的鍵值對。

Reduce階段：Reducer分別處理每個(gè)被聚合的，然后根據(jù)流量計(jì)算公式：

(1)

得到流量統(tǒng)計(jì)結(jié)果。其中Length為list(length)中每個(gè)length(報(bào)文長度)相加的和，SampleRate為采樣率，兩者相乘得到每一行記錄的流量大小F，則在監(jiān)測時(shí)間T范圍內(nèi)，該主機(jī)的上行網(wǎng)絡(luò)流量為list()。

3 方案實(shí)現(xiàn)與測試

3.1 測試環(huán)境

為測試所提出云數(shù)據(jù)的存儲和處理方案的性能，首先要搭建相關(guān)監(jiān)控系統(tǒng)，用以產(chǎn)生監(jiān)控?cái)?shù)據(jù)，本文以O(shè)penStack搭建云平臺，/proc讀取物理機(jī)監(jiān)控信息，Libvirt API接口獲取虛擬機(jī)相關(guān)信息，sFlow流采樣技術(shù)對云平臺的網(wǎng)絡(luò)流量進(jìn)行監(jiān)控。

根據(jù)實(shí)驗(yàn)室的云平臺規(guī)模，搭建了一個(gè)3個(gè)節(jié)點(diǎn)的Hadoop的分布式監(jiān)控平臺，有一個(gè)主節(jié)點(diǎn)master和2個(gè)從節(jié)點(diǎn)slave。主節(jié)點(diǎn)作為監(jiān)控服務(wù)器，負(fù)責(zé)接收部署在OpenStack云平臺上的監(jiān)控代理采集的監(jiān)控?cái)?shù)據(jù)，然后在Hadoop上實(shí)現(xiàn)監(jiān)控?cái)?shù)據(jù)的分布式存儲與處理，最后用戶通過監(jiān)控終端管理查看監(jiān)控狀態(tài)信息。監(jiān)控系統(tǒng)的硬件配置如表2所示。

3.2 數(shù)據(jù)存儲的實(shí)現(xiàn)

將Hadoop平臺中的master節(jié)點(diǎn)作為監(jiān)控服務(wù)器，監(jiān)控服務(wù)器上的HBase客戶端(TSD)負(fù)責(zé)接收發(fā)送來的數(shù)據(jù)，并將監(jiān)控?cái)?shù)據(jù)寫入HBase數(shù)據(jù)庫中。TSD接收到數(shù)據(jù)后需要將其寫入HBase存儲表中，向HBase中寫入時(shí)序監(jiān)控?cái)?shù)據(jù)過程如下：

(1) 接收監(jiān)控代理發(fā)送來的時(shí)序監(jiān)控?cái)?shù)據(jù)，格式為“TimeStamp，metric，value”。

(2) 生成組合行鍵RowKey，RowKey=Metric-TimeStamp1，其中TimeStamp1為整點(diǎn)時(shí)間戳，其計(jì)算公式如下：

TimeStamp1=TimeStamp-(TimeStamp mod 3600)

(2)

(3) 生成列名colfam:qual，其中colfam為列簇名(只有一個(gè)列簇)，qual為列名，且qual=TimeStamp mod 3600。

(4) 根據(jù)生成的行鍵RowKey創(chuàng)建一個(gè)Put：

put=new Put(Bytes.toBytes(″RowKey″))

(5) 向該行添加列名為colfam:qual的列：

put.add(Bytes.toBytes(″colfam″)

Bytes.toBytes(″qual″),Bytes.toBytes(″value″))

(6) 將該數(shù)據(jù)存入HBase表中：table.put(put)

3.3 MapReduce處理算法實(shí)現(xiàn)

監(jiān)控?cái)?shù)據(jù)存入HBase后，使用Java編寫MapReduce流量統(tǒng)計(jì)分析算法，對流量數(shù)據(jù)進(jìn)行快速處理分析，得到云平臺的監(jiān)控信息。算法分為兩個(gè)階段實(shí)施：

(1) Map階段。Map接收到的數(shù)據(jù)是經(jīng)Hadoop處理后的鍵值對，其中TimeStamp指報(bào)文的采集時(shí)間，HeaderCut是一條報(bào)文內(nèi)容(即流量日志的一行)。經(jīng)過Map處理后，輸出中間結(jié)果為的鍵值對，形式為，Length表示報(bào)文長度。流量統(tǒng)計(jì)分析的Map過程偽代碼如下：

輸入：

輸出：

Class FlowSumMapper

{

map(String input_key, String input_value) {

String line=value.toString();

//讀取日志中的一行數(shù)據(jù)；

String[] fields=StringUtils.split(line,′ ′);

//分解成若干字段；

String IP=fields[1];

//提取主機(jī)IP字段；

long length=Long.parseLong(fields[7]);

//讀取報(bào)文長度；

context.write(“IP”, “up_flow”);

//輸出鍵值對；

}

}

(2) Reduce階段。在進(jìn)入Reduce階段前，Map-Reduce框架會將每個(gè)Map輸出的中間結(jié)果進(jìn)行整合處理形成新鍵值對，形式為，它將作為Reduce階段的輸入。在Reduce階段，先分別對每個(gè)鍵值對進(jìn)行聚合運(yùn)算，然后根據(jù)流量計(jì)算公式得到統(tǒng)計(jì)結(jié)果，輸出鍵值對。流量統(tǒng)計(jì)分析的Reduce過程偽代碼如下：

輸入：

輸出：

Class FlowSumReducer

{

reduce (String input_key, Iterator input_value) {

long length_counter=0;

for(FlowBean b: value){

length_counter +=b.getUp_flow();

//聚合

}

flow=length_counter*SamplingRate;

//計(jì)算流量

context.write(“IP”, “flow”);

//輸出結(jié)果；

}

}

圖8所示為后端MapReduce程序執(zhí)行流量統(tǒng)計(jì)分析任務(wù)的過程。

圖8 流量統(tǒng)計(jì)分析程序執(zhí)行過程

3.4 方案測試

3.4.1 與單機(jī)處理對比

將采集的流量日志數(shù)據(jù)分別由本文的分布式處理方案和傳統(tǒng)單機(jī)處理方案進(jìn)行基于IP地址的流量統(tǒng)計(jì)，測試數(shù)據(jù)選用大小分別為0.2、0.5、1、3、5 GB流量日志數(shù)據(jù)。兩種方式進(jìn)行統(tǒng)計(jì)分析的耗時(shí)結(jié)果如表3所示。

表3 單機(jī)處理與分布式處理性能對比

從表3可以看到數(shù)據(jù)量不大時(shí)，Hadoop平臺的處理速度和單機(jī)系統(tǒng)的處理速度相差不大，甚至還沒有單機(jī)的處理速度快。這是因?yàn)镠adoop在進(jìn)行計(jì)算前要做一些集群間的通信和初始化工作，在小數(shù)據(jù)集處理上并不占優(yōu)勢。當(dāng)數(shù)據(jù)量增大后，該分布式處理方案具有明顯的優(yōu)勢。

3.4.2 HBase數(shù)據(jù)庫性能測試

本文設(shè)計(jì)的是一種基于提升字段法的HBase 存儲模型來存儲時(shí)序監(jiān)控?cái)?shù)據(jù)。為了測試該存儲模型下HBase讀性能的高效性，本文分別測試了高表和寬表兩種存儲方式下，從HBase數(shù)據(jù)庫中檢索1小時(shí)、5小時(shí)、1天和1周的監(jiān)控?cái)?shù)據(jù)時(shí)系統(tǒng)延遲。如圖9所示。

圖9 HBase讀性能測試

4 結(jié) 語

本文針對云監(jiān)控系統(tǒng)中存在的實(shí)時(shí)數(shù)據(jù)量大，以及單機(jī)系統(tǒng)計(jì)算瓶頸等問題，提出了一種基于Hadoop大數(shù)據(jù)平臺的云監(jiān)控?cái)?shù)據(jù)存儲與處理方案。實(shí)驗(yàn)結(jié)果表明，用提升字段法提高了Hbase數(shù)據(jù)庫的存儲效率，寬表存儲結(jié)構(gòu)提升了檢索速度，用MapReduce對流量數(shù)據(jù)統(tǒng)計(jì)分析，有效解決了單機(jī)系統(tǒng)計(jì)算瓶頸的問題。為進(jìn)一步的研究奠定了良好的基礎(chǔ)。

[1] Aceto G,Botta A,Donato W D,et al.Cloud monitoring:A survey[J].Computer Networks,2013,57(9):2093- 2115.

[2] 洪斌,彭甫陽,鄧波,等.云資源狀態(tài)監(jiān)控研究綜述[J].計(jì)算機(jī)應(yīng)用與軟件,2016,33(6):1- 6,12.

[3] 單莘，祝智崗，張龍，等.基于流處理的云計(jì)算平臺監(jiān)控方案的設(shè)計(jì)與實(shí)現(xiàn)[J].計(jì)算機(jī)應(yīng)用與軟件,2016,33(4):88- 90,121.

[4] 陳林,應(yīng)時(shí),賈向陽.SHMA:一種云平臺的監(jiān)控框架[J].計(jì)算機(jī)科學(xué),2017,44(1):7- 12,36.

[5] 丁治明，高需．面向物聯(lián)網(wǎng)海量傳感器采樣數(shù)據(jù)管理的數(shù)據(jù)庫集群系統(tǒng)框架[J]．計(jì)算機(jī)學(xué)報(bào)，2012，35(6):1175- 1191.

[6] Cao W, Yu F, Xie J. Realization of the low cost and high performance MySQL cloud database[C]// IEEE, International Conference on Data Engineering. 2014:1468- 1471．

[7] 鞠瑞,王麗娜,余榮威,等.面向云平臺的異構(gòu)監(jiān)控?cái)?shù)據(jù)存儲方法[J].山東大學(xué)學(xué)報(bào)(理學(xué)版),2017,52(5):104- 110.

[8] George Lars.HBase權(quán)威指南[M].代志遠(yuǎn),劉佳,蔣杰,譯.人民郵電出版社,2013:344- 348.

[9] 李亮,姚熙.基于云平臺的虛擬化流量監(jiān)控方法及裝置:中國,CN104917653A[P].2015.

[10] Afaq M,Song W C.sFlow-based resource utilization monitoring in clouds[C]//Network Operations and Management Symposium(APNOMS),2016 18th Asia-Pacific.IEEE,2016:1- 3.