張 靚 肖俊東 趙開敏
(1.海軍駐大連426廠軍事代表室 大連 116001)(2.中國艦船研究設計中心 武漢 430064)
基于Spark的艦船網絡數據解析存儲系統設計與實現?
張 靚1肖俊東2趙開敏2
(1.海軍駐大連426廠軍事代表室 大連 116001)(2.中國艦船研究設計中心 武漢 430064)
針對傳統艦船網絡數據處理能力不足的現狀,論文提出了基于Spark的數據處理解決方案。在Spark中根據XML解析二進制文件、創建HBase數據庫并修改其自身的數據寫入機制,開發了網頁客戶端。論文創新性的提出了Spark對二進制文件解析的一套算法,并在具體的試驗過程中得以驗證。在分布式架構下從數據處理、存儲、應用等角度,實現了一個自動化的、穩定的、高性能的大規模數據處理系統。
數據處理;Spark;HBase;分布式架構
隨著艦船網絡結構日趨復雜,艦船網絡數據的數量也發生顯著增加。數據量的增加對數據的捕獲、處理和存儲提出了較高的要求。傳統的數據處理及存儲解決方案在大數據面前已經顯得力不從心,必須尋求更高效的艦船網絡數據計算模式和數據存儲模式。
本文根據Spark技術的優勢,優化原有海量數據處理系統的計算單元MapReduce,設計HBase數據庫結構,提高系統在各類數據場景下的數據處理能力。
本次方案設計使用Hadoop中1+N的NameNo?de和DataNode部署模式[1]。用Spark替換MapRe?duce作為數據計算單元,得到艦船網絡數據的各項屬性信息,Spark的解析結果上傳至HBase數據庫中[2],Spark的解析依據采用的XML協議文件,同時優化解析XML文件的解析方式,在HBase中數據以數據表的形式對各類數據分類存儲,方便數據的管理和訪問。在寫數據的過程中用批量寫入的方式替換HBase默認的的單條寫入方式。網站設計采用Tomcat+Servlet的形式,兼顧網站性能和系統整體代碼的統一,方便開發與后期維護,故在設計中將網站基于Java的架構[3~5]??傮w設計方案如圖1所示。
軟件工作流程按照數據捕獲—數據處理—數據展示的順序進行,而在數據處理中流程又因為實際情況不同分為:單機數據處理和Hadoop集群處理。當數據捕獲卡進行數據捕獲時,系統對實時網絡流量進行監控,當網絡流量較小時網絡數據并不上傳集群,而由本機上的解析程序進行解析,當解析完成后,各個子節點獨立寫入數據到HBase。當網絡流量較大時,Hadoop的守護進程被啟動,數據以文件的形式存儲到本地,當滿足上傳閾值后,文件被自動上傳至分布式文件系統(HDFS),與此同時Spark作為計算單元開始獲取HDFS中的文件進行解析,并將解析結果存入HBase中,以上兩個環節中數據的讀取和寫入都可能發生在不同子節點之間。無論何種情況,數據寫入HBase后,前端可以對數據的查詢、過濾等操作[6]。
本文關鍵技術主要包括流量平衡算法與數據批量載入兩種。這兩種技術在數據解析和數據存儲時對系統的性能和穩定度產生了較大的提升。
1)流量平衡算法
當前流量等于當前總包數減去上一秒總包數。結合實際情況,定一固定閾值,當數據流量大于該閾值時,視當前為大流量情況,此時啟動守護進程,將捕獲到的數據上傳至Hadoop集群;當數據流量小于該閾值時,視當前為小流量情況,捕獲的數據存儲在本機上,此時本機上的解析程序啟動,開始對文件進行解析,并寫入HBase分布式數據庫當中。
通過流量平衡算法,整個網路數據解析存儲系統可以兼顧大規模數據和小流量數據兩種情況,不會出現用戶長時間等待處理結果的情況。
2)數據批量載入
本文采用BulkLoad批量寫入替代逐條寫入方案。
Bulkload的工作流程主要分為以下三點:
(1)在Spark中產生兩個Job;
(2)第一個Job進行正常的數據解析,當數據解析完成后,先將解析結果寫到一個HDFS中臨時文件當中;
(3)第二個Job接受前一個Job的輸出結果,然后將其格式化為HFile,調用BulkLoad將生成的HFile導入到HBase中實現數據的批量導入[6~7]。
數據捕獲網卡被布置到N臺服務器上,且由NameNode服務器控制各臺子節點的抓包起止。每個網卡抓取數據后存在本地文件夾中,以50M為一個文件大小,當文件夾達到500M容量時,文件一并上傳至HDFS,本地文件夾清空。若網絡長時間處于低流量情況則啟用單機解析程序。
網絡數據來自于各種運行的設備,網絡數據通過千兆高性能網卡捕獲,捕獲后數據格式化存儲。每一個報文都被數據捕獲網卡標記上以下信息:時間戳、數據段長度、版本號等。
針對小流量二進制文件采用服務器本地串行解析的方式。
針對大流量二進制文件采用基于Spark的處理策略,以key-value的形式存放在JavaPairRDD中,key為文件HDFS地址(字符串),value為二進制文件內容。
提前一次性讀入所有協議XML數據,將XML完全解析,存入內存,方便解析時調用。
XML協議名由源IP、目的IP、信息單元標識信息組合而成,存儲的數據根據各自對應的協議對網絡數據進行解析。
3.3.1 HBase表的結構的優化設計
1)Column-Family的優化設計
數據表設計為單列族,即數據表中只存在一個cf列族,而將數據類型信息和字段信息整合形成列名。
2)RowKey的設計
在默認行鍵(單純時間戳)基礎上,首位增加隨機字符串,由于本系統需要處理的數據量較大,應使用較長的隨機字符串,才能使數據較為均勻地分布在所有的RegionServer上。但另一方面,由于HBase的行鍵值與其查詢效率有直接聯系,行鍵過長將會導致搜索效率降低,影響用戶體驗。經反復對比實驗,選擇在時間戳前加上五位隨機字符串[8]。
最終設計的HBase數據表的RowKey由5位隨機數和當前數據時戳組成,每一列數據即代表一幀數據,它們的列名為源IP+目的IP+項目名,且同一列中的數據RowKey值相同。
3.3.2 HBse的性能優化
1)負載均衡機制
HBase表負載均衡機制選擇全局計劃,在有新節點加入時啟動隨機分配計劃。全局計劃默認每隔5min執行一次均衡操作,將所有RegionServer上的Region分配的更加均勻。隨機分配計劃則主要用于新加入的RegionServer,隨機分配Region。
2)BulkLoad機制
采用BulkLoad批量寫入替代原有的逐條寫入方案。本文采用BulkLoad機制,將解析完成的數據統一輸出到一個HFile文件中,當解析工作全部完成后,將整個文件一次性寫入HBase。
本文中用戶對于數據查詢要求比較多樣,除了正常查詢以外,還需要進行聯合查詢、模糊查詢等個性化的查詢需求。本文采用基于JSP和Servlet的Web端架構。
3.4.1 Web端與HBase的交互
HBase與Java的交互包括:數據庫訪問、帶過濾條件的數據查詢、根據鍵值進行單條數據查詢、無條件的整表查詢、列名前綴查詢等。
3.4.2 Web端的實現
1)界面布局設計
頁面的布局分為三個部分:篩選查詢條件部分、網絡數據展示部分、解析數據展示部分。
2)JSON數據
網絡數據在Web端和Servlet之間采用JSON格式的數據傳輸[9]。
3)數據查詢條件分析及接口設計
在Web端進行數據查詢操作時,根據用戶的需求不同,后臺對HBase查詢方式也會不一樣,JSON數據的結構設計也會隨之不同。根據用戶要求,查詢場景包括:全表查詢、單數據集單條件查詢、單數據集全集查詢、單數據集多條件查詢、多數據集聯合查詢、根據RowKey單條查詢等。
4.1.1 硬件網絡拓撲結構
本次設計的分布式網絡是由四臺服務器、一臺交換機、五臺普通PC組成。按照Hadoop生態系統的要求,結合本次設計的實際情況,將四臺服務器分配為NameNode和DataNode其數量分別為1和3。這四臺服務器直連交換機,數據捕獲網卡部署到每臺 DataNode上[10~11]。
由于Spark所有的計算和臨時文件的存儲都是在內存中進行,所以整個集群對DataNode所部署的服務器內存要求較高。
4.1.2 軟件版本
本次設計的Hadoop版本為Hadoop-2.2.0,Spark的版本為Spark1.2.1,HBase版本為HBase-0.98.11,jdk版本為jdk1.7,Scala版本為sca?la2.9.3[12]。
4.2.1 不同Workers間Spark的計算效率
本節來進行論證,當Worker節點數分別為1和3時,Spark對網絡數據處理速度的差別。圖2(a)和圖2(b)為13G數據(小數據量)和55G數據(大數據量)在Spark中進行處理時節點數與解析時間的關系圖。
從上述實驗結果可以看出,節點個數對Spark數據處理效率的影響主要是在數據規模較大的情況下,在這種情況下,解析效率往往與節點數成倍數關系。相反,當數據規模較小時,由于Spark初始化機制的存在,使得節點數目在解析效率中并起不到什么作用,甚至節點越多耗時越長。
4.2.2 Spark與MapReduce計算效率比較
圖3表示Mapreduce和Spark兩者處理55G數據所需要的時間長度對比,由圖可知Spark的解析效率是MapReduce的22倍左右。
當用戶數據開始寫入HBase數據庫后,Web端可以對數據庫中的數據進行查詢。針對數據庫中數據進行各種方式的查詢操作,如全表查詢、模糊查詢、聯合查詢、用戶信息查詢等。
圖4為進行模糊查詢時數據展示,左下角顯示用戶輸入的查詢條件,當用戶只根據協議類型而不設置具體查詢字段或值時,我們將這樣的查詢方式稱之為模糊查詢。查詢結果展示在劇中的列表里,同時當單擊某條數據后,屏幕右側將會把該數據的具體字段及對應的字段值顯示其中。
當用戶進行查詢時,圖5反映了從點擊“查詢”按鈕,到查詢結果展示至前端所消耗的時間,如下圖所示,消耗時間為209ms。之所以時延如此小是因為每次查詢都是以某一具體的RowKey為基準,所以可以迅速定位查詢起點。
當用戶點擊某行數據時,會再次進行查詢數據庫的操作,此次查詢可將該數據所有字段返回給前端,如圖6所示,等待響應時間為154ms。這里體現了HBase的行鍵優勢,數據即為索引,用戶可以某條數據的RowKey迅速找到該數據的完整信息。
本次設計主要是對以MapReduce為數據處理單元的Hadoop系統進行了計算能力上的改進,以Spark計算單元替換MapReduce;將解析協議進行提前處理,并緩存在內存中,解析數據時從內存中訪問解析文件,大大提高了解析效率;解析后文件批量導入,使數據存儲效率提高,對HBase數據庫的結構進行優化使數據查詢速度更快;改變網站架構,采用了Tomcat+Servlet架構,使得整個系統更加適應Hadoop生態系統,數據的查詢與返還在毫秒級別完成,用戶體驗良好。
[1]Wang Y,Ma C,Wang W,et al.An approach of fast datamanipulation in HDFS with supplementary mechanisms[J].Journal of Supercomputing,2015,71(5):1736-1753.
[2]李浩.基于Hadoop的云計算數據安全關鍵問題研究[D].上海:上海師范大學,2015.
[3]李曼,于青利.Spark生態系統走向成熟和應用[J].世界電信,2015(7):66-72.
[4]夏俊鸞,劉旭暉,邵賽賽等.Spark大數據處理技術[M].北京:電子工業出版社.2015.1-56.
[5]黎文陽.大數據處理模型Apache Spark研究[J].現代計算機:普及版,2015(3):55-60.
[6]董西成.Tez:運行在YARN上的DAG計算框架[J].程序員,2013(8):98-102.
[7]Xu J W,Liang J L.Research on a Distributed Storage Ap?plication with HBase[J].Advanced Materials Research,2013:631-632,1265-1269.
[8]Carstoiu D,Cernian A,Olteanu A.Hadoop Hbase-0.20.2 performance evaluation[C]//International Conference on New Trends in Information Science and Service Science.2010:84-87.
[9]張耘凡,柳平增,馬鴻健,等.一種基于JSON的分布式系統架構[J].中國農機化學報,2015,36(5):255-257.
[10]陳含.基于Hadoop的海量數據存儲和計算平臺的設計與實現[D].武漢:武漢理工大學,2014.
[11]高官濤,鄭小盈,宋應文,等.基于Spark MapR educ e框架的分布式渲染系統研究[J].軟件導刊,2013(12):26-29.
[12]楊志偉,鄭烇,王嵩,等.異構Spark集群下自適應任務調度策略[J].計算機工程,2016,42(1):31-35.
Design and Implementation of Ship Network Data Analysis and Storage System Based on Spark
ZHANG Liang1XIAO Jundong2ZHAO Kaimin2
(1.Naval Representative Office in Dalian 426 Factory,Dalian 116001)(2.China Ship Development and Design Center,Wuhan 430064)
Aiming at the shortage of data processing capability of traditional ship network,this paper proposes asolution of Spark-based data processing.It parses binary files according to XML in the Spark,creates the HBase database and modifies its own data writing mechanism,anddevelops the web client.This paper proposes a set of algorithms for Spark's analysis of binary files,which is validated in the concrete experiment.An automated,stable and high performance large-scale data processing system is real?izedfrom the aspects of data processing,storage and application under the distributed architecture。
data processing,Spark,HBase,distributed architecture
TP393
10.3969/j.issn.1672-9730.2017.11.023
Class Number TP393
2017年5月5日,
2017年6月17日
張靚,男,碩士研究生,工程師,研究方向:艦船建造及網絡信息化。肖俊東,男,碩士研究生,工程師,研究方向:艦船電子與信息。趙開敏,男,碩士研究生,工程師,研究方向:艦船電子與信息。