張 靚 肖俊東 趙開敏

（1.海軍駐大連426廠軍事代表室 大連 116001）（2.中國艦船研究設計中心 武漢 430064）

基于Spark的艦船網(wǎng)絡數(shù)據(jù)解析存儲系統(tǒng)設計與實現(xiàn)?

張 靚1肖俊東2趙開敏2

（1.海軍駐大連426廠軍事代表室 大連 116001）（2.中國艦船研究設計中心 武漢 430064）

針對傳統(tǒng)艦船網(wǎng)絡數(shù)據(jù)處理能力不足的現(xiàn)狀，論文提出了基于Spark的數(shù)據(jù)處理解決方案。在Spark中根據(jù)XML解析二進制文件、創(chuàng)建HBase數(shù)據(jù)庫并修改其自身的數(shù)據(jù)寫入機制，開發(fā)了網(wǎng)頁客戶端。論文創(chuàng)新性的提出了Spark對二進制文件解析的一套算法，并在具體的試驗過程中得以驗證。在分布式架構下從數(shù)據(jù)處理、存儲、應用等角度，實現(xiàn)了一個自動化的、穩(wěn)定的、高性能的大規(guī)模數(shù)據(jù)處理系統(tǒng)。

數(shù)據(jù)處理；Spark；HBase；分布式架構

1 引言

隨著艦船網(wǎng)絡結構日趨復雜，艦船網(wǎng)絡數(shù)據(jù)的數(shù)量也發(fā)生顯著增加。數(shù)據(jù)量的增加對數(shù)據(jù)的捕獲、處理和存儲提出了較高的要求。傳統(tǒng)的數(shù)據(jù)處理及存儲解決方案在大數(shù)據(jù)面前已經(jīng)顯得力不從心，必須尋求更高效的艦船網(wǎng)絡數(shù)據(jù)計算模式和數(shù)據(jù)存儲模式。

本文根據(jù)Spark技術的優(yōu)勢，優(yōu)化原有海量數(shù)據(jù)處理系統(tǒng)的計算單元MapReduce，設計HBase數(shù)據(jù)庫結構，提高系統(tǒng)在各類數(shù)據(jù)場景下的數(shù)據(jù)處理能力。

2 基于Spark的海量艦船網(wǎng)絡數(shù)據(jù)處理系統(tǒng)設計

2.1 方案總體設計

本次方案設計使用Hadoop中1+N的NameNo?de和DataNode部署模式［1］。用Spark替換MapRe?duce作為數(shù)據(jù)計算單元，得到艦船網(wǎng)絡數(shù)據(jù)的各項屬性信息，Spark的解析結果上傳至HBase數(shù)據(jù)庫中［2］，Spark的解析依據(jù)采用的XML協(xié)議文件，同時優(yōu)化解析XML文件的解析方式，在HBase中數(shù)據(jù)以數(shù)據(jù)表的形式對各類數(shù)據(jù)分類存儲，方便數(shù)據(jù)的管理和訪問。在寫數(shù)據(jù)的過程中用批量寫入的方式替換HBase默認的的單條寫入方式。網(wǎng)站設計采用Tomcat+Servlet的形式，兼顧網(wǎng)站性能和系統(tǒng)整體代碼的統(tǒng)一，方便開發(fā)與后期維護，故在設計中將網(wǎng)站基于Java的架構［3～5］?？傮w設計方案如圖1所示。

2.2 軟件工作流程

軟件工作流程按照數(shù)據(jù)捕獲—數(shù)據(jù)處理—數(shù)據(jù)展示的順序進行，而在數(shù)據(jù)處理中流程又因為實際情況不同分為：單機數(shù)據(jù)處理和Hadoop集群處理。當數(shù)據(jù)捕獲卡進行數(shù)據(jù)捕獲時，系統(tǒng)對實時網(wǎng)絡流量進行監(jiān)控，當網(wǎng)絡流量較小時網(wǎng)絡數(shù)據(jù)并不上傳集群，而由本機上的解析程序進行解析，當解析完成后，各個子節(jié)點獨立寫入數(shù)據(jù)到HBase。當網(wǎng)絡流量較大時，Hadoop的守護進程被啟動，數(shù)據(jù)以文件的形式存儲到本地，當滿足上傳閾值后，文件被自動上傳至分布式文件系統(tǒng)（HDFS），與此同時Spark作為計算單元開始獲取HDFS中的文件進行解析，并將解析結果存入HBase中，以上兩個環(huán)節(jié)中數(shù)據(jù)的讀取和寫入都可能發(fā)生在不同子節(jié)點之間。無論何種情況，數(shù)據(jù)寫入HBase后，前端可以對數(shù)據(jù)的查詢、過濾等操作［6］。

2.3 關鍵技術

本文關鍵技術主要包括流量平衡算法與數(shù)據(jù)批量載入兩種。這兩種技術在數(shù)據(jù)解析和數(shù)據(jù)存儲時對系統(tǒng)的性能和穩(wěn)定度產(chǎn)生了較大的提升。

1）流量平衡算法

當前流量等于當前總包數(shù)減去上一秒總包數(shù)。結合實際情況，定一固定閾值，當數(shù)據(jù)流量大于該閾值時，視當前為大流量情況，此時啟動守護進程，將捕獲到的數(shù)據(jù)上傳至Hadoop集群；當數(shù)據(jù)流量小于該閾值時，視當前為小流量情況，捕獲的數(shù)據(jù)存儲在本機上，此時本機上的解析程序啟動，開始對文件進行解析，并寫入HBase分布式數(shù)據(jù)庫當中。

通過流量平衡算法，整個網(wǎng)路數(shù)據(jù)解析存儲系統(tǒng)可以兼顧大規(guī)模數(shù)據(jù)和小流量數(shù)據(jù)兩種情況，不會出現(xiàn)用戶長時間等待處理結果的情況。

2）數(shù)據(jù)批量載入

本文采用BulkLoad批量寫入替代逐條寫入方案。

Bulkload的工作流程主要分為以下三點：

（1）在Spark中產(chǎn)生兩個Job；

（2）第一個Job進行正常的數(shù)據(jù)解析，當數(shù)據(jù)解析完成后，先將解析結果寫到一個HDFS中臨時文件當中；

（3）第二個Job接受前一個Job的輸出結果，然后將其格式化為HFile，調(diào)用BulkLoad將生成的HFile導入到HBase中實現(xiàn)數(shù)據(jù)的批量導入［6～7］。

3 基于Spark的網(wǎng)絡數(shù)據(jù)處理系統(tǒng)的實現(xiàn)

3.1 數(shù)據(jù)捕獲模塊的設計與實現(xiàn)

數(shù)據(jù)捕獲網(wǎng)卡被布置到N臺服務器上，且由NameNode服務器控制各臺子節(jié)點的抓包起止。每個網(wǎng)卡抓取數(shù)據(jù)后存在本地文件夾中，以50M為一個文件大小，當文件夾達到500M容量時，文件一并上傳至HDFS，本地文件夾清空。若網(wǎng)絡長時間處于低流量情況則啟用單機解析程序。

3.2 基于Spark的網(wǎng)絡數(shù)據(jù)的解析策略及實現(xiàn)

網(wǎng)絡數(shù)據(jù)來自于各種運行的設備，網(wǎng)絡數(shù)據(jù)通過千兆高性能網(wǎng)卡捕獲，捕獲后數(shù)據(jù)格式化存儲。每一個報文都被數(shù)據(jù)捕獲網(wǎng)卡標記上以下信息：時間戳、數(shù)據(jù)段長度、版本號等。

針對小流量二進制文件采用服務器本地串行解析的方式。

針對大流量二進制文件采用基于Spark的處理策略，以key-value的形式存放在JavaPairRDD中，key為文件HDFS地址（字符串），value為二進制文件內(nèi)容。

提前一次性讀入所有協(xié)議XML數(shù)據(jù)，將XML完全解析，存入內(nèi)存，方便解析時調(diào)用。

XML協(xié)議名由源IP、目的IP、信息單元標識信息組合而成，存儲的數(shù)據(jù)根據(jù)各自對應的協(xié)議對網(wǎng)絡數(shù)據(jù)進行解析。

3.3 HBase非關系型存儲的優(yōu)化設計實現(xiàn)

3.3.1 HBase表的結構的優(yōu)化設計

1）Column-Family的優(yōu)化設計

數(shù)據(jù)表設計為單列族，即數(shù)據(jù)表中只存在一個cf列族，而將數(shù)據(jù)類型信息和字段信息整合形成列名。

2）RowKey的設計

在默認行鍵（單純時間戳）基礎上，首位增加隨機字符串，由于本系統(tǒng)需要處理的數(shù)據(jù)量較大，應使用較長的隨機字符串，才能使數(shù)據(jù)較為均勻地分布在所有的RegionServer上。但另一方面，由于HBase的行鍵值與其查詢效率有直接聯(lián)系，行鍵過長將會導致搜索效率降低，影響用戶體驗。經(jīng)反復對比實驗，選擇在時間戳前加上五位隨機字符串［8］。

最終設計的HBase數(shù)據(jù)表的RowKey由5位隨機數(shù)和當前數(shù)據(jù)時戳組成，每一列數(shù)據(jù)即代表一幀數(shù)據(jù)，它們的列名為源IP+目的IP+項目名，且同一列中的數(shù)據(jù)RowKey值相同。

3.3.2 HBse的性能優(yōu)化

1）負載均衡機制

HBase表負載均衡機制選擇全局計劃，在有新節(jié)點加入時啟動隨機分配計劃。全局計劃默認每隔5min執(zhí)行一次均衡操作，將所有RegionServer上的Region分配的更加均勻。隨機分配計劃則主要用于新加入的RegionServer，隨機分配Region。

2）BulkLoad機制

采用BulkLoad批量寫入替代原有的逐條寫入方案。本文采用BulkLoad機制，將解析完成的數(shù)據(jù)統(tǒng)一輸出到一個HFile文件中，當解析工作全部完成后，將整個文件一次性寫入HBase。

3.4 基于Java的Web端實現(xiàn)

本文中用戶對于數(shù)據(jù)查詢要求比較多樣，除了正常查詢以外，還需要進行聯(lián)合查詢、模糊查詢等個性化的查詢需求。本文采用基于JSP和Servlet的Web端架構。

3.4.1 Web端與HBase的交互

HBase與Java的交互包括：數(shù)據(jù)庫訪問、帶過濾條件的數(shù)據(jù)查詢、根據(jù)鍵值進行單條數(shù)據(jù)查詢、無條件的整表查詢、列名前綴查詢等。

3.4.2 Web端的實現(xiàn)

1）界面布局設計

頁面的布局分為三個部分：篩選查詢條件部分、網(wǎng)絡數(shù)據(jù)展示部分、解析數(shù)據(jù)展示部分。

2）JSON數(shù)據(jù)

網(wǎng)絡數(shù)據(jù)在Web端和Servlet之間采用JSON格式的數(shù)據(jù)傳輸［9］。

3）數(shù)據(jù)查詢條件分析及接口設計

在Web端進行數(shù)據(jù)查詢操作時，根據(jù)用戶的需求不同，后臺對HBase查詢方式也會不一樣，JSON數(shù)據(jù)的結構設計也會隨之不同。根據(jù)用戶要求，查詢場景包括：全表查詢、單數(shù)據(jù)集單條件查詢、單數(shù)據(jù)集全集查詢、單數(shù)據(jù)集多條件查詢、多數(shù)據(jù)集聯(lián)合查詢、根據(jù)RowKey單條查詢等。

4 測試結果與分析

4.1 基于Spark的分布式系統(tǒng)搭建

4.1.1 硬件網(wǎng)絡拓撲結構

本次設計的分布式網(wǎng)絡是由四臺服務器、一臺交換機、五臺普通PC組成。按照Hadoop生態(tài)系統(tǒng)的要求，結合本次設計的實際情況，將四臺服務器分配為NameNode和DataNode其數(shù)量分別為1和3。這四臺服務器直連交換機，數(shù)據(jù)捕獲網(wǎng)卡部署到每臺 DataNode上［10～11］。

由于Spark所有的計算和臨時文件的存儲都是在內(nèi)存中進行，所以整個集群對DataNode所部署的服務器內(nèi)存要求較高。

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 Spark處理二進制數(shù)據(jù)

4.2.1 不同Workers間Spark的計算效率

本節(jié)來進行論證，當Worker節(jié)點數(shù)分別為1和3時，Spark對網(wǎng)絡數(shù)據(jù)處理速度的差別。圖2（a）和圖2（b）為13G數(shù)據(jù)（小數(shù)據(jù)量）和55G數(shù)據(jù)（大數(shù)據(jù)量）在Spark中進行處理時節(jié)點數(shù)與解析時間的關系圖。

從上述實驗結果可以看出，節(jié)點個數(shù)對Spark數(shù)據(jù)處理效率的影響主要是在數(shù)據(jù)規(guī)模較大的情況下，在這種情況下，解析效率往往與節(jié)點數(shù)成倍數(shù)關系。相反，當數(shù)據(jù)規(guī)模較小時，由于Spark初始化機制的存在，使得節(jié)點數(shù)目在解析效率中并起不到什么作用，甚至節(jié)點越多耗時越長。

4.2.2 Spark與MapReduce計算效率比較

圖3表示Mapreduce和Spark兩者處理55G數(shù)據(jù)所需要的時間長度對比，由圖可知Spark的解析效率是MapReduce的22倍左右。

4.3 Web端數(shù)據(jù)查詢實現(xiàn)

當用戶數(shù)據(jù)開始寫入HBase數(shù)據(jù)庫后，Web端可以對數(shù)據(jù)庫中的數(shù)據(jù)進行查詢。針對數(shù)據(jù)庫中數(shù)據(jù)進行各種方式的查詢操作，如全表查詢、模糊查詢、聯(lián)合查詢、用戶信息查詢等。

圖4為進行模糊查詢時數(shù)據(jù)展示，左下角顯示用戶輸入的查詢條件，當用戶只根據(jù)協(xié)議類型而不設置具體查詢字段或值時，我們將這樣的查詢方式稱之為模糊查詢。查詢結果展示在劇中的列表里，同時當單擊某條數(shù)據(jù)后，屏幕右側將會把該數(shù)據(jù)的具體字段及對應的字段值顯示其中。

當用戶進行查詢時，圖5反映了從點擊“查詢”按鈕，到查詢結果展示至前端所消耗的時間，如下圖所示，消耗時間為209ms。之所以時延如此小是因為每次查詢都是以某一具體的RowKey為基準，所以可以迅速定位查詢起點。

當用戶點擊某行數(shù)據(jù)時，會再次進行查詢數(shù)據(jù)庫的操作，此次查詢可將該數(shù)據(jù)所有字段返回給前端，如圖6所示，等待響應時間為154ms。這里體現(xiàn)了HBase的行鍵優(yōu)勢，數(shù)據(jù)即為索引，用戶可以某條數(shù)據(jù)的RowKey迅速找到該數(shù)據(jù)的完整信息。

5 結語

本次設計主要是對以MapReduce為數(shù)據(jù)處理單元的Hadoop系統(tǒng)進行了計算能力上的改進，以Spark計算單元替換MapReduce；將解析協(xié)議進行提前處理，并緩存在內(nèi)存中，解析數(shù)據(jù)時從內(nèi)存中訪問解析文件，大大提高了解析效率；解析后文件批量導入，使數(shù)據(jù)存儲效率提高，對HBase數(shù)據(jù)庫的結構進行優(yōu)化使數(shù)據(jù)查詢速度更快；改變網(wǎng)站架構，采用了Tomcat+Servlet架構，使得整個系統(tǒng)更加適應Hadoop生態(tài)系統(tǒng)，數(shù)據(jù)的查詢與返還在毫秒級別完成，用戶體驗良好。

［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的云計算數(shù)據(jù)安全關鍵問題研究［D］.上海：上海師范大學，2015.

［3］李曼，于青利.Spark生態(tài)系統(tǒng)走向成熟和應用［J］.世界電信，2015（7）：66-72.

［4］夏俊鸞，劉旭暉，邵賽賽等.Spark大數(shù)據(jù)處理技術［M］.北京：電子工業(yè)出版社.2015.1-56.

［5］黎文陽.大數(shù)據(jù)處理模型Apache Spark研究［J］.現(xiàn)代計算機：普及版，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的分布式系統(tǒng)架構［J］.中國農(nóng)機化學報，2015，36（5）：255-257.

［10］陳含.基于Hadoop的海量數(shù)據(jù)存儲和計算平臺的設計與實現(xiàn)［D］.武漢：武漢理工大學，2014.

［11］高官濤，鄭小盈，宋應文，等.基于Spark MapR educ e框架的分布式渲染系統(tǒng)研究［J］.軟件導刊，2013（12）：26-29.

［12］楊志偉，鄭烇，王嵩，等.異構Spark集群下自適應任務調(diào)度策略［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日

張靚，男，碩士研究生，工程師，研究方向：艦船建造及網(wǎng)絡信息化。肖俊東，男，碩士研究生，工程師，研究方向：艦船電子與信息。趙開敏，男，碩士研究生，工程師，研究方向：艦船電子與信息。