楊素素

(首都師范大學(xué) 信息工程學(xué)院,北京 100048)

基于Storm的城市消防聯(lián)網(wǎng)遠(yuǎn)程監(jiān)控系統(tǒng)的實(shí)時(shí)數(shù)據(jù)處理應(yīng)用

楊素素

(首都師范大學(xué) 信息工程學(xué)院,北京 100048)

針對城市消防聯(lián)網(wǎng)遠(yuǎn)程監(jiān)控系統(tǒng)中實(shí)時(shí)信息數(shù)據(jù)逐漸增長而引出的大數(shù)據(jù)問題，傳統(tǒng)的消防系統(tǒng)無法實(shí)時(shí)、高效地處理消防實(shí)時(shí)數(shù)據(jù)的問題，提出了一種基于云計(jì)算和Storm實(shí)時(shí)數(shù)據(jù)處理系統(tǒng)的解決方案;對于開源的Storm框架進(jìn)行需求和性能分析，實(shí)現(xiàn)對其技術(shù)架構(gòu)上的改進(jìn)，并結(jié)合消防系統(tǒng)的特點(diǎn)，提出一套高實(shí)時(shí)性、高可擴(kuò)展性的消防聯(lián)網(wǎng)監(jiān)控中心的數(shù)據(jù)實(shí)時(shí)處理的體系架構(gòu)，同時(shí)也進(jìn)行了云計(jì)算平臺的搭建，利用心跳檢測機(jī)制保證各個(gè)監(jiān)控單位的實(shí)時(shí)性連接;研究表明，基于云計(jì)算和Storm平臺架構(gòu)完全適用于消防聯(lián)網(wǎng)監(jiān)控中心的實(shí)時(shí)消防數(shù)據(jù)的處理，具有高效性、高可靠性、性能顯著等特性。

Storm;消防預(yù)警;大數(shù)據(jù)實(shí)時(shí)處理;云計(jì)算

0 引言

近年來，各種火災(zāi)事故頻發(fā)，有交通工具火災(zāi)事故、生產(chǎn)生活中的火災(zāi)事故、工業(yè)生產(chǎn)中的火災(zāi)事故。80%以上的這些火災(zāi)事故給人們帶來很慘重的損失。據(jù)分析調(diào)查發(fā)現(xiàn)，很多我們生活中常見的火災(zāi)事故都是可以預(yù)先發(fā)現(xiàn)，并及時(shí)處理和疏散來減少損失的。這就對于火災(zāi)危險(xiǎn)性進(jìn)行預(yù)警分析和評價(jià)是十分重要的。

為了解決火災(zāi)及時(shí)報(bào)警、設(shè)備故障及時(shí)發(fā)現(xiàn)及時(shí)巡檢，提高城市的消防減災(zāi)能力，各個(gè)城市都在努力建設(shè)消防聯(lián)網(wǎng)平臺。消防聯(lián)網(wǎng)覆蓋的范圍越來越廣，消防檢測設(shè)備的監(jiān)控探頭和煙霧感應(yīng)、溫度感應(yīng)檢測等相關(guān)設(shè)備的檢測數(shù)據(jù)量也逐漸增大，尤其是消防聯(lián)網(wǎng)傳感設(shè)備中的采集的數(shù)據(jù)對于火災(zāi)的預(yù)判和分析來說越來越重要，各個(gè)地區(qū)的上百萬臺設(shè)備傳輸過來的海量數(shù)據(jù)的處理也越來越迫切，大數(shù)據(jù)的實(shí)時(shí)處理問題也越來越突出。

現(xiàn)有的城市消防聯(lián)網(wǎng)遠(yuǎn)程監(jiān)控系統(tǒng)主要研究的是對消防數(shù)據(jù)的采集、以及采用更先進(jìn)的傳輸設(shè)備和更可靠的傳輸協(xié)議對數(shù)據(jù)進(jìn)行傳輸以保證數(shù)據(jù)的可靠傳輸。然而系統(tǒng)地解決消防預(yù)警困難，不僅僅需要數(shù)據(jù)的實(shí)時(shí)可靠傳輸，我們還需要對這些實(shí)時(shí)傳感數(shù)據(jù)進(jìn)行實(shí)時(shí)地分析和預(yù)測，實(shí)時(shí)監(jiān)控、遠(yuǎn)程查看和遠(yuǎn)程控制，以達(dá)到火災(zāi)的及時(shí)預(yù)警、及時(shí)指揮、消防設(shè)備故障及時(shí)發(fā)現(xiàn)和整修。

現(xiàn)有的大數(shù)據(jù)處理方式分為流處理[1-3]和批處理兩種，數(shù)據(jù)批處理主要是針對靜態(tài)數(shù)據(jù)和變化比較慢的一些數(shù)據(jù)集的處理。對于高實(shí)時(shí)性要求的系統(tǒng)，特別是為了應(yīng)對不斷增長的數(shù)據(jù)，如消防的檢測設(shè)備中實(shí)時(shí)檢測到異常數(shù)據(jù)、設(shè)備每時(shí)每刻的工作狀態(tài)的判斷等都要求我們更多地關(guān)注流數(shù)據(jù)的實(shí)時(shí)處理。然而，現(xiàn)如今，現(xiàn)有的顯著的流處理計(jì)算系統(tǒng)有Linkedin的Kalka[4]系統(tǒng)、Twitter的Storm[5]系統(tǒng)、Yahoo的S4[6](simple scalable streaming system)系統(tǒng)、Facebook的Data Freeway and Puma[7]系統(tǒng)、MillWheel[8]、Spark Streaming[9]和Photon[10]等，流處理技術(shù)已經(jīng)作為傳統(tǒng)數(shù)據(jù)庫成品輸送管道中很重要的一部分[11-13]。本文主要在消防監(jiān)控中心采用基于云計(jì)算平臺和Storm實(shí)時(shí)數(shù)據(jù)處理的系統(tǒng)設(shè)計(jì)，并對系統(tǒng)整體性能進(jìn)行測試。

1 適用于城市消防聯(lián)網(wǎng)遠(yuǎn)程監(jiān)控系統(tǒng)的云計(jì)算平臺

目前消防行業(yè)里，隨著科技技術(shù)的迅猛發(fā)展，各種各樣具備先進(jìn)性能的探測器和消防設(shè)備層出不窮，消防單位內(nèi)所安裝設(shè)備的種類大大豐富，所產(chǎn)生的信息量也是爆發(fā)式的增長，一個(gè)普通中等城市的數(shù)據(jù)量已經(jīng)達(dá)到了很大的規(guī)模，而且隨著城市建設(shè)的推進(jìn)，數(shù)據(jù)量必然會(huì)達(dá)到大數(shù)據(jù)級別。城市消防遠(yuǎn)程監(jiān)控系統(tǒng)是將監(jiān)控中心與各個(gè)消防單位之間建立網(wǎng)絡(luò)通訊，并結(jié)合運(yùn)用地理信息系統(tǒng)、數(shù)字視頻監(jiān)控等現(xiàn)代網(wǎng)絡(luò)信息技術(shù)，在監(jiān)控中心內(nèi)對所有在此聯(lián)網(wǎng)內(nèi)的建筑物的火災(zāi)報(bào)警情況進(jìn)行實(shí)時(shí)監(jiān)控、監(jiān)測、對設(shè)備的運(yùn)行情況進(jìn)行集中監(jiān)督和管理。同時(shí)國標(biāo)要求：地級市以上城市(含地級,全國共286個(gè))，應(yīng)設(shè)立城市消防遠(yuǎn)程監(jiān)控系統(tǒng)；縣級城市宜設(shè)立城市消防遠(yuǎn)程監(jiān)控系統(tǒng)。

1.1 目前城市消防聯(lián)網(wǎng)遠(yuǎn)程監(jiān)控系統(tǒng)所受到的限制

目前我國的城市消防聯(lián)網(wǎng)遠(yuǎn)程監(jiān)控系統(tǒng)還處于廠家各自建設(shè)階段。通常消防單位中消防監(jiān)控系統(tǒng)的信息數(shù)據(jù)存儲在各自的數(shù)據(jù)庫中，城市消防控制中心對各個(gè)監(jiān)控單位的數(shù)據(jù)庫進(jìn)行輪詢，然后對查詢到的數(shù)據(jù)進(jìn)行處理，最后顯示在頁面上。這種方式在面對海量大數(shù)據(jù)的時(shí)候就顯得力不從心，而且存在諸多問題：

(1)效率低：當(dāng)前大多數(shù)的城市消防聯(lián)網(wǎng)遠(yuǎn)程監(jiān)控系統(tǒng)，都是消防單位將各自的數(shù)據(jù)存儲在自己的數(shù)據(jù)庫中，城市消防監(jiān)控中心通過不斷的查詢各個(gè)監(jiān)控單位的數(shù)據(jù)庫來獲取數(shù)據(jù)，然后對數(shù)據(jù)進(jìn)行處理，最后顯示在頁面上。隨著監(jiān)控單位數(shù)據(jù)庫數(shù)據(jù)量的不斷增加，數(shù)據(jù)庫的檢索效率也會(huì)不斷降低，系統(tǒng)效率很難確保。

(2)實(shí)時(shí)性差：由于當(dāng)前的城市消防聯(lián)網(wǎng)遠(yuǎn)程監(jiān)控系統(tǒng)的效率低，消防中心得到數(shù)據(jù)的實(shí)時(shí)性就無法確保，至少會(huì)有幾十秒左右的延遲，這幾十秒的時(shí)間對于火災(zāi)預(yù)警來說至關(guān)重要，甚至關(guān)乎人的生命。對于消防監(jiān)控中心來說數(shù)據(jù)的實(shí)時(shí)性是需要解決的最大的問題。

(3)維護(hù)難度大：當(dāng)前的城市消防聯(lián)網(wǎng)遠(yuǎn)程監(jiān)控系統(tǒng)需要消防監(jiān)控中心去不斷的查詢消防單位的數(shù)據(jù)庫，從而給各個(gè)節(jié)點(diǎn)上的服務(wù)器都帶來很大的壓力，容易導(dǎo)致宕機(jī)。同時(shí)，系統(tǒng)的容錯(cuò)能力也較差，實(shí)際使用中系統(tǒng)的維護(hù)難度較大。

因此，高實(shí)時(shí)性、高效率、高性能的云計(jì)算集群架構(gòu)的搭建是解決以上問題的最好方式，適用于城市消防聯(lián)網(wǎng)遠(yuǎn)程監(jiān)控系統(tǒng)的云計(jì)算平臺的搭建是刻不容緩的。

1.2 城市消防聯(lián)網(wǎng)遠(yuǎn)程監(jiān)控系統(tǒng)的云計(jì)算平臺的構(gòu)建

本系統(tǒng)采用如圖1所示的系統(tǒng)框架，根據(jù)消防行業(yè)的實(shí)際情況，消防單位之間沒有必要建立數(shù)據(jù)連接，每個(gè)消防單位都直接和城市消防監(jiān)控中心建立連接。采用心跳檢測機(jī)制來保障中心實(shí)時(shí)地監(jiān)控消防單位的消防系統(tǒng)中主要服務(wù)器的運(yùn)行狀況，消防監(jiān)控中心實(shí)時(shí)采集數(shù)據(jù)并通過服務(wù)器集群進(jìn)行高效分析和計(jì)算，最后顯示在可視化界面上。

圖1 系統(tǒng)架構(gòu)圖

1.3 城市消防聯(lián)網(wǎng)遠(yuǎn)程監(jiān)控系統(tǒng)的云計(jì)算平臺高實(shí)時(shí)性的體現(xiàn)

城市消防聯(lián)網(wǎng)遠(yuǎn)程監(jiān)控系統(tǒng)是一個(gè)需要實(shí)時(shí)反饋各個(gè)消防單位狀態(tài)信息的系統(tǒng)，需要不斷的獲取消防單位數(shù)據(jù)服務(wù)器上的最新數(shù)據(jù)。因此數(shù)據(jù)采集的速度也直接影響系統(tǒng)能否做到高實(shí)時(shí)性，各消防單位采用規(guī)定好數(shù)據(jù)格式的log文件存儲實(shí)時(shí)數(shù)據(jù)，并存儲在數(shù)據(jù)服務(wù)器中，消防中心只讀消防單位log文件上的新增數(shù)據(jù)，大大減小數(shù)據(jù)傳輸量。消防單位中的log文件按照按天存放，有效控制單個(gè)log文件的大小。這樣，相較于傳統(tǒng)數(shù)據(jù)庫檢索方式，數(shù)據(jù)采集做到了高效穩(wěn)定。

1.4 城市消防聯(lián)網(wǎng)遠(yuǎn)程監(jiān)控系統(tǒng)的云計(jì)算平臺高可靠性的體現(xiàn)

消防中心的服務(wù)器集群通過一個(gè)主服務(wù)器master服務(wù)器控制，集群中的服務(wù)器每隔一段時(shí)間就會(huì)發(fā)送一條狀態(tài)信息給master服務(wù)器，一旦服務(wù)器集群中的某個(gè)服務(wù)器出現(xiàn)故障，master服務(wù)器收不到該服務(wù)器的心跳信息，會(huì)將該服務(wù)器所處理的工作及時(shí)分配給別的服務(wù)器處理。并且master節(jié)點(diǎn)也有一個(gè)備用服務(wù)器，一旦master服務(wù)器宕機(jī)，備用服務(wù)器會(huì)立即投入使用。同時(shí)消防監(jiān)控中心和消防單位之間也有一套心跳檢測機(jī)制，消防單位中的服務(wù)器設(shè)備每隔一段時(shí)間就會(huì)發(fā)送一條狀態(tài)信息給消防中心，如果狀態(tài)信息接收不正常，則通知相應(yīng)的監(jiān)控單位對相關(guān)服務(wù)器設(shè)備進(jìn)行及時(shí)地檢修，保證平臺的穩(wěn)定運(yùn)行。這種機(jī)制也保證了消防監(jiān)控中心和消防單位之間保持可靠接連。

1.5 城市消防聯(lián)網(wǎng)遠(yuǎn)程監(jiān)控系統(tǒng)的云計(jì)算平臺高可擴(kuò)展性的體現(xiàn)

系統(tǒng)中的消防單位的識別信息都存在消防中心的master服務(wù)器的配置表中，對消防單位的編輯，只需修改配置表消防單位的信息。同時(shí)，如果發(fā)現(xiàn)集群中服務(wù)器的平均負(fù)載率過高(超過80%)，那么可以很方便的向集群中添加新的服務(wù)器，同樣是在master服務(wù)器的配置表中添加新并入服務(wù)器的信息。

本文的系統(tǒng)平臺進(jìn)過實(shí)驗(yàn)，為城市消防聯(lián)網(wǎng)遠(yuǎn)程監(jiān)控系統(tǒng)提供了經(jīng)濟(jì)，穩(wěn)定，高效，可靠，和方便擴(kuò)展的云計(jì)算平臺。

2 城市消防聯(lián)網(wǎng)遠(yuǎn)程監(jiān)控系統(tǒng)系統(tǒng)中數(shù)據(jù)的實(shí)時(shí)處理

本文針對消防系統(tǒng)中海量數(shù)據(jù)的實(shí)時(shí)采集和處理需求提出基于flume、kafka、Strom集群的城市消防聯(lián)網(wǎng)實(shí)時(shí)監(jiān)控系統(tǒng)。采用模塊設(shè)計(jì)，每個(gè)組件完成自己特定的業(yè)務(wù)功能。本章主要介紹消防監(jiān)控系統(tǒng)的組成部分、體系架構(gòu)設(shè)計(jì)、和系統(tǒng)客戶端結(jié)果展示等內(nèi)容。

2.1 系統(tǒng)的組成部分

Flume是一個(gè)高可用的，高可靠的，分布式的海量日志采集、聚合和傳輸?shù)南到y(tǒng)。本系統(tǒng)通過部署在消防單位上數(shù)據(jù)服務(wù)器上的flume_agent，實(shí)時(shí)的采集log文件中新增的信息數(shù)據(jù)。

kafka是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)。因?yàn)樾枰趂lume采集信息數(shù)據(jù)和storm處理數(shù)據(jù)之間建立緩沖中間件，所以使用kafka接受flume采集的數(shù)據(jù)，同時(shí)將數(shù)據(jù)以消息隊(duì)列的形式輸送給storm。

Storm 是一個(gè)開源的、大數(shù)據(jù)處理系統(tǒng)，旨在用于分布式實(shí)時(shí)處理且與語言無關(guān)。其使用核心在于拓?fù)浣Y(jié)構(gòu)的設(shè)計(jì)，我們需要把kafka中的消息數(shù)據(jù)傳到到storm里，再照著設(shè)計(jì)好的拓?fù)浣Y(jié)構(gòu)給消防中心服務(wù)器集群中的機(jī)器分發(fā)數(shù)據(jù)進(jìn)行處理，因此根據(jù)實(shí)際需求確定好機(jī)器數(shù)量是整個(gè)系統(tǒng)處理效率的關(guān)鍵。 Storm運(yùn)行在一個(gè)分布式的集群架構(gòu)上，Storm集群由一個(gè)主節(jié)點(diǎn)和多個(gè)工作節(jié)點(diǎn)組成。

2.2 系統(tǒng)體系架構(gòu)設(shè)計(jì)

城市消防聯(lián)網(wǎng)遠(yuǎn)程監(jiān)控系統(tǒng)采用四層架構(gòu)：數(shù)據(jù)采集層、數(shù)據(jù)接入層、數(shù)據(jù)處理層和數(shù)據(jù)輸出層。如圖2所示。

圖2 Storm下的體系架構(gòu)示意圖

2.2.1 數(shù)據(jù)采集層

使用Flume實(shí)現(xiàn)分布式日志收集系統(tǒng)進(jìn)行日志采集：log文件中海量數(shù)據(jù)的高效收集是本系統(tǒng)的基石，本系統(tǒng)使用的Flume來進(jìn)行日志采集。Flume本身采用了分層架構(gòu)：分別為agent，collector和storage，Agent負(fù)責(zé)日志收集工作，Collector層負(fù)責(zé)接收Agent層發(fā)送的日志，并且將日志根據(jù)路由規(guī)則寫到相應(yīng)的Store層中，Store層負(fù)責(zé)提供永久或者臨時(shí)的日志存儲服務(wù)，或者將日志流導(dǎo)向其它服務(wù)器。

Flume具有的:(1)高可靠性; (2)易擴(kuò)展及管理性 等優(yōu)點(diǎn)是本系統(tǒng)采用其作為日志采集工具的主要原因。

其中(1)高可靠性體現(xiàn)在：當(dāng)系統(tǒng)中消防單位服務(wù)器節(jié)點(diǎn)出現(xiàn)故障時(shí)(例如agentA出現(xiàn)了故障)，其數(shù)據(jù)服務(wù)器上的日志文件能夠被傳送到備用數(shù)據(jù)服務(wù)器節(jié)點(diǎn)上(BackAgent1)而不會(huì)丟失。同時(shí)，F(xiàn)lume提供了3種級別的可靠性保障，從強(qiáng)到弱依次分別為：end-to-end(收到數(shù)據(jù)agent首先將event寫到磁盤上，當(dāng)數(shù)據(jù)傳送成功后，再刪除；如果數(shù)據(jù)發(fā)送失敗，可以重新發(fā)送。)，Store on failure(這也是本系統(tǒng)采用的策略，當(dāng)數(shù)據(jù)接收方服務(wù)器發(fā)生崩潰時(shí)，將數(shù)據(jù)寫到本地，待恢復(fù)后，繼續(xù)發(fā)送)，Best effort(數(shù)據(jù)發(fā)送到接收方后，不會(huì)進(jìn)行確認(rèn))。

(2)易擴(kuò)展及管理性：Flume采用了三層架構(gòu)，分別為agent，collector和storage，每一層均可以水平擴(kuò)展。其中Agent層中，每個(gè)監(jiān)控單位的日志服務(wù)器部署一個(gè)進(jìn)程，負(fù)責(zé)對監(jiān)控單位的日志收集工作；Collector層部署在消防中心服務(wù)器上，負(fù)責(zé)接收Agent層發(fā)送的日志，并且將日志根據(jù)路由規(guī)則寫到相應(yīng)的Store層中；Store層負(fù)責(zé)將日志存儲在本系統(tǒng)的下一個(gè)模塊：kafka。

此外，本系統(tǒng)在Agent層向Collector層放送數(shù)據(jù)的時(shí)候使用負(fù)載均衡策略，將所有的日志均衡地發(fā)到所有的Collector上，達(dá)到負(fù)載均衡的目標(biāo)，避免了單點(diǎn)故障的問題。

圖3 flume系統(tǒng)架構(gòu)圖

2.2.2 數(shù)據(jù)接入層

由于flume采集日志數(shù)據(jù)的速度和storm處理數(shù)據(jù)的速度是不同的，所以本系統(tǒng)使用kafka作為中間的一個(gè)緩沖模塊。kafka能夠?qū)崟r(shí)的收集反饋信息，并能夠支撐較大的數(shù)據(jù)量，通過磁盤數(shù)據(jù)結(jié)構(gòu)提供消息的持久化，這種結(jié)構(gòu)對于即使數(shù)據(jù)達(dá)到TB+級別的消息，存儲也能夠保持長時(shí)間的穩(wěn)定，且具備良好的容錯(cuò)能力。本系統(tǒng)使用kafka統(tǒng)一接收flume采集的數(shù)據(jù)，將消息提交給系統(tǒng)的下一個(gè)模塊，storm集群進(jìn)行數(shù)據(jù)的處理。

2.2.3 數(shù)據(jù)處理層

storm架構(gòu)組成如圖4所示。其中有3種重要節(jié)點(diǎn)：Nimbus節(jié)點(diǎn)、Supervisor節(jié)點(diǎn)和數(shù)據(jù)庫節(jié)點(diǎn)。Nimbus就相當(dāng)于Hadoop中的“JobTracker”，是用戶和Storm系統(tǒng)溝通的關(guān)鍵點(diǎn)，Nimbus主要負(fù)責(zé)發(fā)布和協(xié)調(diào)拓?fù)渲械娜蝿?wù)執(zhí)行。Nimbus是無狀態(tài)的，如果Nimbus服務(wù)失敗了，工作節(jié)點(diǎn)仍然可以持續(xù)地進(jìn)一步工作，只是無法進(jìn)行任務(wù)調(diào)度，直到Nimbus重新復(fù)活。Supervisor運(yùn)行在各個(gè)Storm節(jié)點(diǎn)上，它接受Nimbus分配的任務(wù)并根據(jù)任務(wù)啟動(dòng)和停止屬于自己管理的工作進(jìn)程。Supervisor也是快速失敗的，Nimbus和Supervisor所有的狀態(tài)都存儲在Zookeeper中，這樣設(shè)計(jì)是Storm具有恢復(fù)能力的關(guān)鍵。對分析后的結(jié)果持久化，可以用MySQL存儲，同時(shí)MySQL采用主從復(fù)制架構(gòu)，來避免數(shù)據(jù)的丟失。

圖4 消防預(yù)警系統(tǒng)Storm架構(gòu)組成示意圖

Storm數(shù)據(jù)處理架構(gòu)由流元組組成的拓?fù)?，有著明確的分層架構(gòu)：Spout和Bolt，Spout是拓?fù)渲袛?shù)據(jù)的來源，它會(huì)從外部數(shù)據(jù)源中讀取數(shù)據(jù)，并發(fā)送給處理元組的Bolt，并通過拓?fù)渲械南到y(tǒng)及組件Acker追蹤從Spout中流出的元組的處理路徑，如果在用戶設(shè)置的最大超時(shí)時(shí)間內(nèi)這些元組沒有被完全處理，那么Acker就會(huì)告知Spout該消息處理失敗了，相反會(huì)告知Spout消息處理成功了。這個(gè)Spout代表著整個(gè)元組的完全處理，如圖5所示。因此可以說Storm記錄容錯(cuò)原理保障了消息的可靠處理。

表1 數(shù)據(jù)處理量和處理時(shí)間表

從一個(gè)提供數(shù)據(jù)源的Spout或Bolt流到處理元組的Bolt有很多種方式，由流分組機(jī)制所定義，主要有：隨機(jī)分組、字段分組、直接分組、全局分組等。本系統(tǒng)根據(jù)實(shí)際需求采用先字段分組后隨機(jī)分組策略。把數(shù)據(jù)流先按照消息類型字段(消息類型分為火警，故障，聯(lián)動(dòng)，反饋等)分組，發(fā)送到不同的Bolt中，該Bolt再把接收到的某類型的數(shù)據(jù)流按照隨機(jī)分組方式分發(fā)元組到其它的Bolt任務(wù)中，對該數(shù)據(jù)進(jìn)行計(jì)數(shù)等其他操作。最后再由整合Bolt計(jì)算統(tǒng)計(jì)結(jié)果。

消防單位中的各類探測設(shè)備和其他電子設(shè)備，遇到設(shè)定情況時(shí)會(huì)發(fā)送自己的警報(bào)數(shù)據(jù)，同時(shí)，每時(shí)每刻也在發(fā)送自己自檢數(shù)據(jù)，對這些數(shù)據(jù)的處理實(shí)時(shí)性要求比較高，而數(shù)據(jù)處理組件Bolt主要按字段分組過濾掉海量數(shù)據(jù)中正常的狀態(tài)數(shù)據(jù)，處理實(shí)時(shí)性要求比較高的報(bào)警數(shù)據(jù)，例如火警，故障，聯(lián)動(dòng)等信息，然后將報(bào)警數(shù)據(jù)發(fā)送到web客戶端顯示以及批量插入數(shù)據(jù)庫中。插入完成后，追蹤組件Acker通知storm框架任務(wù)已經(jīng)執(zhí)行完成。

圖5 Bolt組件處理過程

2.2.4 數(shù)據(jù)輸出層

對于storm處理后的數(shù)據(jù)則需要顯示在web客戶端頁面上以及將數(shù)據(jù)存儲到數(shù)據(jù)庫中，用于后期的對這些數(shù)據(jù)的統(tǒng)計(jì)查詢。這里可以使用mysql分布式數(shù)據(jù)庫系統(tǒng)來存儲這些數(shù)據(jù)。這里不再詳述。

3 客戶端結(jié)果顯示

使用express+socket.io技術(shù)實(shí)現(xiàn)web客戶端更新數(shù)據(jù)：Storm處理完成數(shù)據(jù)處理后，通過express+socket.io技術(shù)實(shí)現(xiàn)更新客戶端信息界面，這里對于這個(gè)技術(shù)細(xì)節(jié)不再詳細(xì)贅述。消防監(jiān)控中心對頁面上顯示的問題進(jìn)行處理。有效的監(jiān)管各個(gè)消防中心的運(yùn)行。

4 性能測試

本系統(tǒng)主要提升了城市消防聯(lián)網(wǎng)遠(yuǎn)程監(jiān)控系統(tǒng)在大數(shù)據(jù)處理過程中的實(shí)時(shí)性和可靠性，下面分別從這兩個(gè)方面驗(yàn)證系統(tǒng)性能。

4.1 實(shí)時(shí)性性能評估

測試系統(tǒng)采用4臺主機(jī)組建storm集群，CPU 4×3.3 G,4G內(nèi)存，千兆以太網(wǎng)卡，系統(tǒng)環(huán)境：Java1.6+Kafka+storm-0.9.1+flume1.5+MySQL5.1.69，集群中1個(gè)為master服務(wù)器，測試情況下采用10不同大小的log文件，分別包含為5萬到50萬行數(shù)據(jù)來模擬不同的數(shù)據(jù)量。系統(tǒng)每次處理一個(gè)文件。測試過程中實(shí)時(shí)記錄集群中master服務(wù)器的CPU 、 I/O 和 內(nèi)存占用情況以及其它3個(gè)節(jié)點(diǎn)服務(wù)器的硬件資源使用情況以及完成處理過程所用的時(shí)間。

圖6 數(shù)據(jù)處理量

如表1和圖6所示，從5 W到50 W行的數(shù)據(jù)，數(shù)據(jù)量線性增加，系統(tǒng)處理數(shù)據(jù)的所用時(shí)間呈緩慢增加。說明系統(tǒng)在處理大數(shù)據(jù)量時(shí)所用時(shí)間是可控的，實(shí)時(shí)性可以得到保證。同時(shí)我們看到無論是master服務(wù)器還是其它節(jié)點(diǎn)服務(wù)器的資源占用率都維持在正常水平。從這次實(shí)驗(yàn)我們看到數(shù)據(jù)處理時(shí)間還是不夠理想，這跟實(shí)驗(yàn)中服務(wù)器的硬件水平和數(shù)量有很大關(guān)系。實(shí)際使用中，根據(jù)需要增加服務(wù)器的數(shù)量和提高硬件水平可以有效縮短處理時(shí)間，提高實(shí)時(shí)性。

4.2 可靠性性能評估

在這個(gè)實(shí)驗(yàn)中，我們預(yù)分配8臺主機(jī)。在拓?fù)渲忻總€(gè)組件的初始數(shù)目如下表2。

表2 組件的初始數(shù)目

工作進(jìn)程的數(shù)據(jù)設(shè)置為30，并且一直保持在30。我們在8臺機(jī)器上同時(shí)運(yùn)行拓?fù)淙蝿?wù)。然后，我們等待了15分鐘之后，關(guān)掉了其中的1臺機(jī)器，之后每隔15分鐘就關(guān)掉其中1臺機(jī)器。實(shí)驗(yàn)的設(shè)置如表3所示。

表3 實(shí)驗(yàn)實(shí)時(shí)配置展示表

最后，我們監(jiān)視每分鐘處理的元組的數(shù)目來表示整個(gè)架構(gòu)的吞吐量，同時(shí)也監(jiān)視著一個(gè)元組的平均處理延遲。吞吐量時(shí)根據(jù)每分鐘被追蹤的元組的數(shù)據(jù)來衡量的。實(shí)驗(yàn)的結(jié)果如表4所示。

表4 實(shí)驗(yàn)吞吐量和延遲響應(yīng)數(shù)據(jù)表

正如圖7所示，每當(dāng)我們移除一組機(jī)器時(shí)，都會(huì)有一個(gè)臨時(shí)的下降尖峰，但是隨后很快地又恢復(fù)回來。同時(shí)，我們主要到，吞吐量每十五分鐘下降一次，這意味著同樣的拓?fù)浔桓俚臋C(jī)器處理。也正如圖所示，吞吐量也很快地穩(wěn)定回來。

圖7 吞吐量測量圖

如圖8所示實(shí)驗(yàn)的延遲圖，每關(guān)掉一組機(jī)器后，平均的響應(yīng)延遲也增加了。但是我們同時(shí)也注意到了，在前幾個(gè)15分鐘內(nèi)，延遲的時(shí)間是很短的，但是在最后兩個(gè)15分鐘內(nèi)，延遲就相對來說有點(diǎn)大，但是，系統(tǒng)也都能夠很快地穩(wěn)定處理任務(wù)。

圖8 延遲測量圖

總得來說，正如在這個(gè)實(shí)驗(yàn)中所示，Storm對于機(jī)器故障具有很好的恢復(fù)能力。并且當(dāng)面對機(jī)器故障時(shí)，也能夠有效地穩(wěn)定系統(tǒng)的性能。

5 結(jié)言

論文主要是研究消防監(jiān)控中心對各個(gè)消防單位的數(shù)據(jù)進(jìn)行實(shí)時(shí)采集和處理，對各個(gè)消防單位進(jìn)行實(shí)時(shí)監(jiān)控、警情及時(shí)發(fā)現(xiàn)、故障及時(shí)反饋。通過分析消防單位和消防主管部門的相應(yīng)的需求和實(shí)際狀況，我們發(fā)現(xiàn)利用基于云計(jì)算平臺的storm集群系統(tǒng)能夠有效地解決消防數(shù)據(jù)處理延遲以及系統(tǒng)可靠性問題。同時(shí)針對消防單位服務(wù)器或者是網(wǎng)絡(luò)出現(xiàn)故障時(shí)能夠及時(shí)發(fā)現(xiàn)，我們采用了心跳檢測機(jī)制來保障監(jiān)控中心實(shí)時(shí)地了解消防消防單位的狀況，也保證了消防數(shù)據(jù)的準(zhǔn)確無誤。同時(shí)這套系統(tǒng)也有很高的經(jīng)濟(jì)性，消防單位的系統(tǒng)只需做少量修改，同時(shí)消防監(jiān)控中心根據(jù)實(shí)際需求靈活配置服務(wù)器數(shù)量，

storm架構(gòu)在解決大量數(shù)據(jù)流的實(shí)時(shí)處理方面具有很好的性能，也是以后未來工作的研究重點(diǎn)，在之后的工作中，我們會(huì)更多地改進(jìn)可視化的方法，提升相關(guān)部分的可靠性，也會(huì)更多地考慮實(shí)時(shí)處理和批處理的相結(jié)合等問題。

[1] Arvind Arasu, Brian Babcock, Shivnath Babu, Mayur Datar, Keith Ito, Rajeev Motwani, Itaru Nishizawa, Utkarsh Srivastava, Dilys Thomas, Rohit Varma, Jennifer Widom: STREAM: The Stanford Stream Data Manager[J]. IEEE Data Eng. Bull. 2003, 26(1): 19-26.

[2] Minos N. Garofalakis, Johannes Gehrke: Querying and Mining Data Streams: You Only Get One Look[J]. VLDB 2002.

[3] Daniel J. Abadi, Yanif Ahmad, Magdalena Balazinska, Ugur Cetintemel, Mitch Cherniack, Jeong-Hyon Hwang, Wolfgang Lindner, Anurag Maskey, Alex Rasin, Esther Ryvkina, Nesime Tatbul, Ying Xing, Stanley B. Zdonik: The Design of the Borealis Stream Processing Engine[J]. CIDR 2005: 277-289.

[4] Apache Kafka, A high-throughput distributed messaging system. 2013[EB/OL]. http://kafka.apache.org/design.html.

[5] Storm. 2013[EB/OL]. http://storm.project.net/.

[6] S4 Distributed stream computing platform[EB/OL]. http://incubator.apache.org/s4/.

[7] Borthakur D, Sarma JS, Gray J, Muthukkaruppan K, Spigeglberg N, Kuang HR, Ranganathan K, Molkov D, Mennon A, Rash S, Schmidt R, Aiyer A Apache Hadoop goes realtime at Facebook[A]. Proc. Of the ACM SIGMOD Int”1 Conf. on management of Data(SIGMOD 2011 and PODS 2011)[C]. Athens: ACMPress,2011. 1071-1080.[doi:10.1145/1989323.1989438].

[8] Tyler Akidau, Alex Balikov, Kaya Bekiroglu, Slava Chernyak, Josh Haberman, Reuven Lax, Sam McVeety, Daniel Mills, Paul Nordstrom, Sam Whittle: MillWheel: Fault-Tolerant Stream Processing at Internet Scale[J]. PVLDB, 2013, 6(11): 1033-1044.

[9] Spark Streaming[EB/OL]. http://spark.incubator.apache.org/docs/latest/streaming-programming-guide.html.

[10] Rajagopal Ananthanarayanan, Venkatesh Basker, Sumit Das, Ashish Gupta, Haifeng Jiang, Tianhao Qiu, Alexey Reznichenko, Deomid Ryabkov, Manpreet Singh, Shivakumar Venkataraman: Photon: fault-tolerant and scalable joining of continuous data streams[A]. SIGMOD Conference 2013[C]. 577-588.

[11] Mohamed H. Ali, Badrish Chandramouli, Jonathan Goldstein, Roman Schindlauer: The extensibility framework in Microsoft StreamInsight[J]. ICDE 2011: 1242-1253.

[12] Sankar Subramanian, Srikanth Bellamkonda, Hua-Gang Li, Vince Liang, Lei Sheng, Wayne Smith, James Terry, TsaeFeng Yu, Andrew Witkowski: Continuous Queries in Oracle[J].VLDB 2007: 1173-1184.

[13] IBM Infosphere Streams[EB/OL]. http://www03.ibm.com/software/products/en/infosphere-streams/.

City Fire Remote Minitor Network System Based on Storm for Real-time Data Processing Application

Yang Susu

(College of Information Engineering, Capital Normal University, Beijing 100048, China)

In the city fire control network system, the data of real-time information has become larger and larger. The traditional fire control system cannot deal with the problem of real time data with high efficiency. We analyze the requirements and performance of the open source Storm framework, and implement the improvement on the technical architecture and the characteristics of the fire system. We put forward a set of system architecture for real-time processing of data in high real-time and high scalability of the fire control network monitoring center. At the same time, the construction of the cloud computing platform, using the heartbeat detection mechanism to ensure the real-time performance of the monitoring unit. The research shows that, based on cloud computing and Storm platform, the architecture is fully applicable to the fire control system, which has the characteristics of high efficiency, high reliability, high performance and so on.

Storm; fire protection pre-warning; big data real-time processing; cloud computing

2016-01-12；

2016-02-24。

國家科技支撐計(jì)劃項(xiàng)目(2013BAH19F01)。

楊素素(1990-)，女，碩士研究生，主要從事云計(jì)算與數(shù)據(jù)實(shí)時(shí)處理系統(tǒng)及應(yīng)用方向的研究。

1671-4598(2017)03-0055-05

10.16526/j.cnki.11-4762/tp.2017.03.016

TP399

A