基于Hadoop的監控數據存儲與處理方案設計和實現

池亞平 楊垠坦 許 萍 楊建喜(北京電子科技學院通信工程系 北京 00070)(西安電子科技大學通信工程學院 陜西 西安 7007)(中國科學院信息工程研究所中國科學院網絡測評技術重點實驗室 北京 0009)

0 引 言

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

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

本文通過大數據平臺Hadoop搭建云計算環境，采用提升字段法改進的寬表HBase非關系型數據庫模型存儲時序的和異構的監控數據，針對監控數據中的流量數據利用MapReduce并行計算架構對監控數據進行分布式處理。經測試提高了數據存儲和檢索速率，突破單機監控模型計算瓶頸，提升了對監控數據的分析效率。

1 Hadoop相關技術

Hadoop是Apache最大一個開源項目，可編寫和運行分布式應用處理大規模數據。包含HDFS、MapReduce、HBase、Yarn、Zookeeper、Hive等工具。其生態系統如圖1所示。

圖1 Hadoop生態系統

1.1 HBase數據庫

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

圖2所示為HBase的基本組成架構，HBase建立在Hadoop分布式文件系統HDFS之上，依賴于Zookeeper提供集群的同步和協調，數據以規定的格式存儲在HBase數據庫中，數據庫文件則存儲在HDFS服務中。

圖2 HBase基本架構

1.2 MapReduce并行計算

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

圖3 MapRedue數據基本處理思想

流量監控技術對云平臺中的網絡流量進行全方位的監控和統計分析，發現網絡存在的安全問題，使云平臺的安全、穩定運行得到有力的保障[9-10]。針對網絡流量數據量大的特點采用MapReduce對其進行分析，提升對流量監控數據的處理效率。

2 方案設計

2.1 總體方案設計

針對云環境下監控數據的存儲和處理需求，本文利用Hadoop提供的存儲和處理框架，改進海量時序數據下HBase數據庫的存儲結構，并引入分布式處理思想，解決單機處理流量數據的計算瓶頸問題。方案總體框架如圖4所示。

圖4 方案總體框架

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

2.2 HBase存儲模塊設計

從上述研究可知HBase數據庫適合存儲時序的監控數據，但是在實際應用中仍有兩個問題需要解決。其一是存儲海量監控數據時的“熱點現象”，其二是大數據下HBase表檢索的效率問題。為解決這兩個問題，分別用提升字段法和寬表存儲結構改進HBase數據庫在海量監控數據下的存儲模型。

2.2.1 提升字段法HBase存儲方案設計

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

圖5 熱點現象

通過上面分析，解決上述”存儲熱點”問題關鍵在于行健的設計，需通過設計離散的行健將數據分散到所有存儲服務器上，而不能直接將時間戳作為行健。

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

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

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

row_key = MD5(timestamp)

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

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

row_key = Cpu.Host1-1461056400

當監控指標較多時，row_key會很分散，所有的更新操作將被分散開，最后能夠得到與加鹽法類似的效果。

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

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

從實驗結果可以看出，提升字段法和加鹽法的綜合性能較好，兩者效果相近。但監控系統一般要進行大量的寫操作，讀操作較少，所以要求寫性能較好。同時，對監控數據來說需要根據監控指標名稱能夠進行快速查詢一段時間內監測數據的結果，而加鹽法不利用數據檢索。因此，本文最終選擇基于字段提升的行鍵設計方法。

2.2.2 基于HBase的寬表存儲結構設計

根據上述實驗結果，解決了大量數據在寫入時的 “熱點現象”的同時。為了能匹配MapReduce的處理速度，還要解決HBase檢索效率的問題，這就要求對HBase中的數據進行檢索的延時盡可能小，為了提高數據庫檢索速度，本文設計了一種寬表的存儲結構。

HBase每張表都有一個或者多個列族，每個列族中存放多個列，HBase表每行可以擁有多達上百萬的列，這種結構可以用來在每行存放多個數值，這就使數據可以被更高速地檢索。因為，監控代理每隔幾秒就采集一次數據，這樣產生的數據點規模是非常大的，如果每個數據點占一行，則表的行數將相當多，而掃描數據的最大速度部分取決于需要掃描的行的數據，減少行的數量就大幅減少了一部分檢索開銷，檢索速度就會大大提升。圖6所示為監控數據存儲表結構。

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

圖6 基于提升字段法的寬表存儲結構

該表結構中，將一小時的數據存儲為一行，行鍵為監控指標和整點時間戳的組合，每一列對應具體時間點的監控數據。以2016-04-19 17:06:18這個時間點采集的服務器host1的CPU利用率(41%)為例(圖6中的陰影部分)。

首先，將這個時間點轉化為時間戳1461056781，則17:00對應的時間戳為：

TimeStamp= 1461056781-(1461056781 mod 3600)=

1461056781-381=1461056400

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

如果隔1秒采集一次監控數據，則該存儲方式將使得HBase存儲表的行數縮小為原來的1/3 600，當檢索一小時內數據時只需掃描一行數據。而原來高表的存儲方式下每個數據點存儲為一行，當檢索一小時內的監控數據時，需要掃描3 600行。

2.3 MapReduce處理模塊設計

在MapReduce處理模塊中，利用Hadoop提供的并行處理計算的功能，設計MapReduce流量統計分析程序對大規模網絡流量日志進行快速處理，統計分析各個主機的網絡流量情況。這種數據處理方式突破了傳統單點網絡流量分析的局限性。

圖7所示為基于MapReduce的流量統計分析算法流程。

圖7 基于MapReduce的流量統計分析算法流程

首先，進行數據劃分得到初始鍵值對，timestamp為該報文日志的采集時間，HeaderCut為一條采集的報文，即日志文件的一行。

Map階段：調用mapper的map()函數對每個單獨的鍵值對進行處理，提取HeaderCut中網絡層協議報頭的IP字段和報文長度字段，輸出新的鍵值對，所有mapper輸出形成一個list()，具有相同健值ip的鍵值對被整合形成一個新的鍵值對。

Reduce階段：Reducer分別處理每個被聚合的，然后根據流量計算公式：

(1)

得到流量統計結果。其中Length為list(length)中每個length(報文長度)相加的和，SampleRate為采樣率，兩者相乘得到每一行記錄的流量大小F，則在監測時間T范圍內，該主機的上行網絡流量為list()。

3 方案實現與測試

3.1 測試環境

為測試所提出云數據的存儲和處理方案的性能，首先要搭建相關監控系統，用以產生監控數據，本文以OpenStack搭建云平臺，/proc讀取物理機監控信息，Libvirt API接口獲取虛擬機相關信息，sFlow流采樣技術對云平臺的網絡流量進行監控。

根據實驗室的云平臺規模，搭建了一個3個節點的Hadoop的分布式監控平臺，有一個主節點master和2個從節點slave。主節點作為監控服務器，負責接收部署在OpenStack云平臺上的監控代理采集的監控數據，然后在Hadoop上實現監控數據的分布式存儲與處理，最后用戶通過監控終端管理查看監控狀態信息。監控系統的硬件配置如表2所示。

3.2 數據存儲的實現

將Hadoop平臺中的master節點作為監控服務器，監控服務器上的HBase客戶端(TSD)負責接收發送來的數據，并將監控數據寫入HBase數據庫中。TSD接收到數據后需要將其寫入HBase存儲表中，向HBase中寫入時序監控數據過程如下：

(1) 接收監控代理發送來的時序監控數據，格式為“TimeStamp，metric，value”。

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

TimeStamp1=TimeStamp-(TimeStamp mod 3600)

(2)

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

(4) 根據生成的行鍵RowKey創建一個Put：

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

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

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

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

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

3.3 MapReduce處理算法實現

監控數據存入HBase后，使用Java編寫MapReduce流量統計分析算法，對流量數據進行快速處理分析，得到云平臺的監控信息。算法分為兩個階段實施：

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

輸入：

輸出：

Class FlowSumMapper

{

map(String input_key, String input_value) {

String line=value.toString();

//讀取日志中的一行數據；

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

//分解成若干字段；

String IP=fields[1];

//提取主機IP字段；

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

//讀取報文長度；

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

//輸出鍵值對；

}

}

(2) Reduce階段。在進入Reduce階段前，Map-Reduce框架會將每個Map輸出的中間結果進行整合處理形成新鍵值對，形式為，它將作為Reduce階段的輸入。在Reduce階段，先分別對每個鍵值對進行聚合運算，然后根據流量計算公式得到統計結果，輸出鍵值對。流量統計分析的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;

//計算流量

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

//輸出結果；

}

}

圖8所示為后端MapReduce程序執行流量統計分析任務的過程。

圖8 流量統計分析程序執行過程

3.4 方案測試

3.4.1 與單機處理對比

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

表3 單機處理與分布式處理性能對比

從表3可以看到數據量不大時，Hadoop平臺的處理速度和單機系統的處理速度相差不大，甚至還沒有單機的處理速度快。這是因為Hadoop在進行計算前要做一些集群間的通信和初始化工作，在小數據集處理上并不占優勢。當數據量增大后，該分布式處理方案具有明顯的優勢。

3.4.2 HBase數據庫性能測試

本文設計的是一種基于提升字段法的HBase 存儲模型來存儲時序監控數據。為了測試該存儲模型下HBase讀性能的高效性，本文分別測試了高表和寬表兩種存儲方式下，從HBase數據庫中檢索1小時、5小時、1天和1周的監控數據時系統延遲。如圖9所示。

圖9 HBase讀性能測試

4 結 語

本文針對云監控系統中存在的實時數據量大，以及單機系統計算瓶頸等問題，提出了一種基于Hadoop大數據平臺的云監控數據存儲與處理方案。實驗結果表明，用提升字段法提高了Hbase數據庫的存儲效率，寬表存儲結構提升了檢索速度，用MapReduce對流量數據統計分析，有效解決了單機系統計算瓶頸的問題。為進一步的研究奠定了良好的基礎。

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

[2] 洪斌,彭甫陽,鄧波,等.云資源狀態監控研究綜述[J].計算機應用與軟件,2016,33(6):1- 6,12.

[3] 單莘，祝智崗，張龍，等.基于流處理的云計算平臺監控方案的設計與實現[J].計算機應用與軟件,2016,33(4):88- 90,121.

[4] 陳林,應時,賈向陽.SHMA:一種云平臺的監控框架[J].計算機科學,2017,44(1):7- 12,36.

[5] 丁治明，高需．面向物聯網海量傳感器采樣數據管理的數據庫集群系統框架[J]．計算機學報，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] 鞠瑞,王麗娜,余榮威,等.面向云平臺的異構監控數據存儲方法[J].山東大學學報(理學版),2017,52(5):104- 110.

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

[9] 李亮,姚熙.基于云平臺的虛擬化流量監控方法及裝置:中國,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.