熊聰聰，吉蘇杰，王蘭婷

(天津科技大學(xué)計(jì)算機(jī)科學(xué)與信息工程學(xué)院，天津 300222)

基于Hadoop的校園物聯(lián)網(wǎng)數(shù)據(jù)處理系統(tǒng)研究

熊聰聰，吉蘇杰，王蘭婷

(天津科技大學(xué)計(jì)算機(jī)科學(xué)與信息工程學(xué)院，天津 300222)

針對(duì)校園各物聯(lián)網(wǎng)應(yīng)用系統(tǒng)處理海量數(shù)據(jù)的性能差、數(shù)據(jù)的存儲(chǔ)和運(yùn)維成本高以及設(shè)備擴(kuò)容升級(jí)困難等問題，設(shè)計(jì)了一種基于Hadoop的數(shù)據(jù)處理系統(tǒng)，為構(gòu)建校園云數(shù)據(jù)中心、實(shí)現(xiàn)校園的智慧化服務(wù)提供有益的參考方案．文件處理模塊針對(duì)海量結(jié)構(gòu)化小文件的處理需求提出改進(jìn)方案，對(duì)比實(shí)驗(yàn)表明該方案在降低集群主節(jié)點(diǎn)的內(nèi)存消耗和提高小文件訪問效率方面優(yōu)于現(xiàn)有方案．

校園物聯(lián)網(wǎng)；Hadoop；數(shù)據(jù)處理；結(jié)構(gòu)化小文件

物聯(lián)網(wǎng)在高校中的應(yīng)用現(xiàn)狀是根據(jù)不同的應(yīng)用場(chǎng)景構(gòu)建局部物聯(lián)網(wǎng)絡(luò)實(shí)現(xiàn)服務(wù)，而真正意義上的校園物聯(lián)網(wǎng)[1]是在校園內(nèi)部，利用成熟的射頻識(shí)別(radio frequency identification，RFID)、紅外感應(yīng)、激光掃描等傳感技術(shù)構(gòu)造一個(gè)覆蓋整個(gè)校園的物體互聯(lián)網(wǎng)絡(luò)，實(shí)現(xiàn)不同應(yīng)用需求下的一體化智能管理．基于并行計(jì)算和分布式存儲(chǔ)的云計(jì)算[1]最適合這一應(yīng)用需求．

目前，云計(jì)算在校園物聯(lián)網(wǎng)中的應(yīng)用研究都處于通用應(yīng)用需求和構(gòu)建方案的探討階段，并未對(duì)核心功能模塊的實(shí)現(xiàn)機(jī)制進(jìn)行深入研究．例如：文獻(xiàn)[2]提出基于物聯(lián)網(wǎng)和云計(jì)算構(gòu)建智慧校園的整體服務(wù)方案，論述了實(shí)現(xiàn)這一方案需要關(guān)注的技術(shù)問題和功能需求；文獻(xiàn)[3]設(shè)計(jì)了校園物聯(lián)網(wǎng)云平臺(tái)的總體架構(gòu)，但均未對(duì)數(shù)據(jù)處理的核心工作機(jī)制進(jìn)行研究討論．

本文在現(xiàn)有研究基礎(chǔ)上設(shè)計(jì)并實(shí)現(xiàn)了一種基于Hadoop的面向校園物聯(lián)網(wǎng)服務(wù)的數(shù)據(jù)處理系統(tǒng)，旨在提升系統(tǒng)的運(yùn)算處理性能，進(jìn)而提高校園物聯(lián)網(wǎng)智慧化服務(wù)質(zhì)量．

1 現(xiàn)有校園物聯(lián)網(wǎng)應(yīng)用系統(tǒng)的問題分析

校園物聯(lián)網(wǎng)中的典型應(yīng)用有校園一卡通、圖書管理、實(shí)驗(yàn)設(shè)備管理等．當(dāng)前的實(shí)際狀況是不同的應(yīng)用系統(tǒng)各自形成一個(gè)局部網(wǎng)絡(luò)，搭設(shè)專門的Web服務(wù)器和數(shù)據(jù)庫服務(wù)器，同時(shí)開發(fā)配套的后臺(tái)管理系統(tǒng)，安排技術(shù)人員進(jìn)行管理、維護(hù)和升級(jí)．這種模式存在以下問題：

(1)數(shù)據(jù)存儲(chǔ)和管理的運(yùn)維成本高，硬件升級(jí)復(fù)雜．在購買存儲(chǔ)設(shè)備和軟件定制的模式下，往往需一次性投入大量資金，一旦完成則無法后續(xù)動(dòng)態(tài)調(diào)整，隨著設(shè)備的更新?lián)Q代，落后的硬件平臺(tái)很難重復(fù)利用，而配套的管理軟件亦需要不斷升級(jí)來與之相適應(yīng)，有時(shí)甚至需要重構(gòu)，這可能導(dǎo)致不可控的局面．

(2)隨著數(shù)據(jù)量的增長，數(shù)據(jù)的處理和分析任務(wù)隨之增加，單個(gè)服務(wù)器的CPU運(yùn)算速度和內(nèi)存容量都是十分有限的，在面對(duì)大規(guī)模數(shù)據(jù)集的計(jì)算任務(wù)時(shí)，系統(tǒng)很快會(huì)出現(xiàn)性能瓶頸，容易導(dǎo)致任務(wù)堆積，運(yùn)行速度緩慢．

(3)存儲(chǔ)空間擴(kuò)容不便．在擴(kuò)容時(shí)，傳統(tǒng)服務(wù)器往往要停止應(yīng)用服務(wù)，先將數(shù)據(jù)拷貝至別處，待換上大容量設(shè)備后，再將數(shù)據(jù)遷移回來，這種方法既繁瑣，又給用戶帶來不便．

基于Hadoop的數(shù)據(jù)處理系統(tǒng)設(shè)計(jì)和部署則不存在以上問題，其降低了數(shù)據(jù)存儲(chǔ)的運(yùn)維成本，將垂直式擴(kuò)容轉(zhuǎn)變?yōu)殪`活的水平式，可以有效解決單一服務(wù)器面對(duì)海量計(jì)算任務(wù)的性能瓶頸問題．

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

Hadoop是一個(gè)開源的分布式計(jì)算框架，通常在大量廉價(jià)的硬件設(shè)備上部署集群，其顯著優(yōu)勢(shì)為低成本、高可用性、擴(kuò)容靈活以及良好的移植性．Hadoop由許多子項(xiàng)目構(gòu)成，其中兩大核心構(gòu)件為Map Reduce編程模型和分布式文件系統(tǒng)(HDFS)[4]．

系統(tǒng)內(nèi)部架構(gòu)分為訪問層、應(yīng)用服務(wù)層、基礎(chǔ)管理層和存儲(chǔ)層，其架構(gòu)如圖1所示．訪問層是平臺(tái)的入口，通過接口的方式封裝了下層的各類服務(wù)，接收各種通信協(xié)議下的數(shù)據(jù)請(qǐng)求和響應(yīng)．應(yīng)用服務(wù)層是系統(tǒng)的核心實(shí)現(xiàn)部分，既是業(yè)務(wù)處理的關(guān)鍵層，也是與基礎(chǔ)管理層通信的橋梁．主要業(yè)務(wù)包括：數(shù)據(jù)統(tǒng)計(jì)與分析、ECA規(guī)則響應(yīng)、文件處理等．另外，系統(tǒng)內(nèi)置預(yù)留的應(yīng)用服務(wù)API，以便業(yè)務(wù)拓展．基礎(chǔ)管理層是平臺(tái)的骨架層，除了MapReduce和HDFS以外，Hadoop框架還具有多個(gè)子項(xiàng)目，它們協(xié)同工作，提供了一套全面的數(shù)據(jù)管理和存儲(chǔ)機(jī)制．存儲(chǔ)層是數(shù)據(jù)平臺(tái)的資源池，由HDFS統(tǒng)一分配和管理，所有數(shù)據(jù)分散持久化存儲(chǔ)在集群的各個(gè)數(shù)據(jù)節(jié)點(diǎn)上．

圖1 系統(tǒng)架構(gòu)Fig.1 System architecture

3 核心模塊設(shè)計(jì)

3.1 數(shù)據(jù)統(tǒng)計(jì)與分析模塊

傳統(tǒng)單節(jié)點(diǎn)服務(wù)器在進(jìn)行信息統(tǒng)計(jì)、日志分析或數(shù)據(jù)挖掘等工作時(shí)，將任務(wù)推送至堆棧中，串行執(zhí)行，當(dāng)任務(wù)量較多時(shí)，排隊(duì)等候時(shí)間較長．而基于MapReduce并行計(jì)算模型編寫的Map和Reduce處理函數(shù)則不存在此問題．從并行計(jì)算的角度，集群的Master主控節(jié)點(diǎn)充當(dāng)JobTracker角色，其中JobTracker和NameNode通常在同一節(jié)點(diǎn)上，負(fù)責(zé)各種計(jì)算任務(wù)的調(diào)度與分配．集群的Master主控節(jié)點(diǎn)接到任務(wù)請(qǐng)求后，與HDFS的NameNode節(jié)點(diǎn)通信，獲取所需文件的所有塊位置信息，同時(shí)，將Map任務(wù)發(fā)送給各個(gè)任務(wù)子節(jié)點(diǎn)并行執(zhí)行．TaskTracker根據(jù)任務(wù)要求對(duì)分配到本地的數(shù)據(jù)進(jìn)行組合、排序和合并等處理，然后將狀態(tài)和完成信息報(bào)告給JobTracker，由JobTracker產(chǎn)生最終的結(jié)果文件．這種并行工作模式的效率明顯提高．MapReduce模塊的工作機(jī)制見圖2．

3.2 ECA規(guī)則模塊

事件控制行為(event control action，ECA)規(guī)則模塊是實(shí)現(xiàn)數(shù)據(jù)平臺(tái)事件監(jiān)測(cè)功能的核心，物聯(lián)網(wǎng)中的事件監(jiān)測(cè)過程是：感知設(shè)備端向數(shù)據(jù)平臺(tái)發(fā)送實(shí)時(shí)狀態(tài)數(shù)據(jù)，平臺(tái)通過ECA規(guī)則模塊對(duì)數(shù)據(jù)進(jìn)行事件描述、條件判斷、邏輯處理，然后回發(fā)響應(yīng)結(jié)果，達(dá)到監(jiān)控感知設(shè)備狀態(tài)、及時(shí)通知或預(yù)警的目的．例如：在一卡通應(yīng)用中，用戶在頁面中設(shè)置各種ECA規(guī)則后保存，如余額不足提示、掛失報(bào)警、賬單定期通知等，系統(tǒng)會(huì)為用戶建立單獨(dú)的ECA規(guī)則庫，當(dāng)該用戶的一卡通被感知設(shè)備掃描時(shí)，感知數(shù)據(jù)將發(fā)送給系統(tǒng)，系統(tǒng)調(diào)用該用戶的ECA規(guī)則庫進(jìn)行查詢和合法性判斷，最后返回結(jié)果并執(zhí)行響應(yīng)動(dòng)作．

圖2 MapRedcue模塊的工作機(jī)制Fig.2 Working mechanism of MapReduce module

ECA規(guī)則實(shí)現(xiàn)了業(yè)務(wù)邏輯與動(dòng)作執(zhí)行的動(dòng)態(tài)分離，滿足多變環(huán)境下的松耦合需求．通過ECA規(guī)則模塊，數(shù)據(jù)平臺(tái)能夠?qū)μ囟l件下的事件進(jìn)行主動(dòng)式響應(yīng)服務(wù)[5]，在整個(gè)業(yè)務(wù)生命過程中無需用戶操作或外部應(yīng)用的干預(yù)．其工作原理如圖3．

圖3 ECA模塊工作原理Fig.3 The working principle of ECA module

3.3 文件處理模塊

當(dāng)前主流的分布式文件系統(tǒng)都是針對(duì)優(yōu)先考慮流式訪問的大文件而設(shè)計(jì)的，忽略了小文件的存儲(chǔ)和訪問[6]．因此，系統(tǒng)的文件處理模塊是影響系統(tǒng)性能的關(guān)鍵之一．

3.3.1 現(xiàn)有小文件處理方案分析

Har方案的主要思想是通過構(gòu)建一個(gè)層次化的文件系統(tǒng)將大量小文件合并打包成*.har格式的特殊文件，并在NameNode上建立二級(jí)索引．這種方案明顯改善了NameNode內(nèi)存消耗問題，但存在以下不足之處：(1)小文件歸檔后，源文件仍在磁盤上，而且不能自動(dòng)刪除，造成了存儲(chǔ)資源的重疊以及增加了管理員的額外工作量；(2)合并耗時(shí)長，在對(duì)小文件進(jìn)行隨機(jī)訪問時(shí)，需要與NameNode上的二級(jí)索引文件通信，需要占用較多的時(shí)間資源．

Sequence File方案的原理是通過鍵值對(duì)(keyvalue)這種數(shù)據(jù)結(jié)構(gòu)將小文件序列化后，統(tǒng)一合并起來進(jìn)行存儲(chǔ)．這種方式除了解決了內(nèi)存消耗問題外，同時(shí)還可與MapReduce很好的契合．最大的不足是，它沒有建立小文件到Sequence File的索引，不支持內(nèi)部小文件的隨機(jī)訪問，所以每次讀取都必須遍歷整個(gè)Sequence File，導(dǎo)致查找文件的時(shí)間比Har方案的二級(jí)索引還要慢．

針對(duì)以上不足，出現(xiàn)了Map File[7]方案，它是帶有部分索引的Sequence File升級(jí)版，但這種方式仍然需要在索引間隔區(qū)域內(nèi)部進(jìn)行一次遍歷，隨機(jī)讀取的性能還達(dá)不到最理想．

此外，余思等[8]從負(fù)載均衡和小文件合并規(guī)模的角度考慮，設(shè)計(jì)了一種基于層次分析的預(yù)測(cè)算法來進(jìn)行負(fù)載均衡優(yōu)化，但并未解決小文件的查找效率問題．王濤等[9]從用戶訪問行為出發(fā)，通過改進(jìn)概率淺語義分析模型，提出了一種改進(jìn)方案，但該方案僅適合于文件之間關(guān)聯(lián)性較強(qiáng)的云存儲(chǔ)系統(tǒng)．

3.3.2 改進(jìn)方案設(shè)計(jì)

針對(duì)校園物聯(lián)網(wǎng)的各個(gè)子應(yīng)用系統(tǒng)中存在海量結(jié)構(gòu)化小文件的實(shí)際情況，基于小文件合并的思想設(shè)計(jì)了更適用的解決方案，從而進(jìn)一步降低NameNode內(nèi)存消耗和提高文件的隨機(jī)訪問效率．改進(jìn)方案的主要原理是在客戶端和系統(tǒng)集群的HDFS之間增加一個(gè)處理層，該層首先對(duì)結(jié)構(gòu)化的小文件進(jìn)行數(shù)據(jù)交換，統(tǒng)一格式后，記錄下每個(gè)小文件的元信息和位置信息，保存在臨時(shí)文件中，然后建立小文件到合并文件的索引文件，與Har方案不同的是，索引文件并不放置在NameNode中，而是與該合并文件進(jìn)行綁定，存儲(chǔ)到DataNode中，在客戶端要求訪問合并文件內(nèi)部的小文件時(shí)，系統(tǒng)在獲取數(shù)據(jù)塊位置后，將綁定的索引文件發(fā)送至客戶端本地進(jìn)行索引，這樣既不占用NameNode內(nèi)存，又將文件的索引任務(wù)從系統(tǒng)集群轉(zhuǎn)移到了客戶端上，訪問效率明顯提高．該方案的工作原理見圖4．

圖4 改進(jìn)方案的工作原理Fig.4 Working principle of the improved scheme

XML是目前通用的具有國際統(tǒng)一標(biāo)準(zhǔn)的結(jié)構(gòu)化文件格式，可根據(jù)實(shí)際需求靈活建立索引機(jī)制[10]．對(duì)于校園一卡通、圖書管理、教學(xué)設(shè)備管理等應(yīng)用場(chǎng)景，結(jié)構(gòu)化的感知數(shù)據(jù)文件都支持與XML文件的數(shù)據(jù)交換．因此，系統(tǒng)改進(jìn)方案的具體實(shí)現(xiàn)過程可描述如下：

(1)文件識(shí)別．對(duì)于客戶端傳來的文件，首先判斷文件類型，若為小文本文件，則判斷該文件是否支持XML數(shù)據(jù)交換，若支持則轉(zhuǎn)(2)，若不支持則警告用戶文件特殊，詢問是否繼續(xù)，若繼續(xù)則跳轉(zhuǎn)至(5)，否則結(jié)束本次操作；若為非結(jié)構(gòu)化小文件或大文件，則跳轉(zhuǎn)至(5)．

(2)文件處理．先將文件轉(zhuǎn)換為XML格式，然后查詢NameNode內(nèi)存中是否有等待狀態(tài)的XML文件，若無則新建XML文件，通知NameNode建立元數(shù)據(jù)信息，并分配DataNode塊位置，建立狀態(tài)標(biāo)識(shí)符，值為“0”，表示等待狀態(tài)，然后跳轉(zhuǎn)至(3)；若已有等待狀態(tài)的XML文件，則直接跳轉(zhuǎn)(3)．

(3)建立索引信息．詢問等待狀態(tài)的XML文件所在的DataNode是否存在狀態(tài)標(biāo)識(shí)符為“0”的索引文件，若不存在則新建1個(gè)XML索引文件，同樣建立數(shù)值為“0”的等待狀態(tài)標(biāo)識(shí)符，將文件發(fā)送給處理程序，而后進(jìn)行信息統(tǒng)計(jì)；若已存在則直接調(diào)取，然后統(tǒng)計(jì)文件信息，包括文件編號(hào)(用以唯一標(biāo)識(shí)文件)和文件大?。?/p>

(4)文件合并．計(jì)算并判斷待寫入的小文件與待合并的XML文件總計(jì)是否已達(dá)到64,MB，若已達(dá)到則將XML文件與其所屬的索引文件的狀態(tài)標(biāo)識(shí)符均改為“1”，表示已滿，然后跳轉(zhuǎn)到(2)；若小于或等于64,MB，則標(biāo)識(shí)符不變，順序地將小文件的內(nèi)容寫入待合并的XML文件中，以“＜FileNumber＞…＜/FileNumber＞”標(biāo)簽為一個(gè)小文件的存儲(chǔ)區(qū)域，記錄下該小文件的起始位置偏移量和文件長度，并發(fā)送給其索引文件．

(5)上傳至HDFS．若為一般大文件，通知NameNode建立元數(shù)據(jù)并分配數(shù)據(jù)塊，將文件寫入到DataNode；若為合并文檔，則將合并文檔與索引文件一起發(fā)送給DataNode進(jìn)行管理維護(hù)．

4 系統(tǒng)實(shí)驗(yàn)與分析

實(shí)驗(yàn)在系統(tǒng)集群上進(jìn)行，Hadoop版本為0.20.1，JDK版本為1.6.0_24，操作系統(tǒng)為Ubuntu 12.04．HDFS集群由4臺(tái)服務(wù)器組成，為保證單節(jié)點(diǎn)性能平衡，每臺(tái)服務(wù)器的硬件配置均相同，雙核Intel Xeon E5,506 2.13,GHz處理器，2,GB內(nèi)存，200,GB SATA硬盤．其中1臺(tái)作為客戶端服務(wù)器和NameNode節(jié)點(diǎn)，其余3臺(tái)為DataNode節(jié)點(diǎn)，數(shù)據(jù)塊為默認(rèn)設(shè)置的64,MB，副本數(shù)為3．

4.1 統(tǒng)計(jì)測(cè)試與分析

為了驗(yàn)證在執(zhí)行適合于MapReduce模型的任務(wù)時(shí)，Hadoop集群相對(duì)于單服務(wù)器的性能優(yōu)勢(shì)，分別在不同節(jié)點(diǎn)數(shù)量的集群和單服務(wù)器上對(duì)不同數(shù)據(jù)量的系統(tǒng)日志文件進(jìn)行關(guān)鍵詞匯(例如：Error、Warning等)統(tǒng)計(jì)測(cè)試，實(shí)驗(yàn)結(jié)果見表1．

表1 關(guān)鍵詞匯統(tǒng)計(jì)測(cè)試結(jié)果Tab.1 Key words statistical test results

從表1結(jié)果可以看出：當(dāng)文件較小時(shí)，在節(jié)點(diǎn)多的集群上反而沒有在節(jié)點(diǎn)少的集群上運(yùn)行快，因?yàn)槠湓贛apReduce操作上耗費(fèi)了較多時(shí)間；然而隨著文件大小的增加，MapReduce的性能就充分體現(xiàn)了出來，集群的節(jié)點(diǎn)數(shù)量增加后處理速度明顯提高．可以推斷，MapReduce在處理更大規(guī)模的數(shù)據(jù)時(shí)，效率提高的更顯著．

4.2 改進(jìn)方案的性能分析

實(shí)驗(yàn)所用海量結(jié)構(gòu)化小文本文件由程序模擬生成，文件數(shù)據(jù)結(jié)構(gòu)是一卡通應(yīng)用系統(tǒng)的數(shù)據(jù)報(bào)表及高校圖書館館藏資源的檢索信息，共模擬生成了106個(gè)消費(fèi)信息和館藏信息小文件，單個(gè)小文件的大小約為32,KB，數(shù)據(jù)量共計(jì)為30.52,GB．

以NameNode內(nèi)存使用情況和對(duì)小文本文件隨機(jī)讀取的時(shí)間效率為指標(biāo)，考察了改進(jìn)方案的性能，并與其他方案進(jìn)行對(duì)比分析．其中，以文件數(shù)量為變化因子，對(duì)比在HDFS原方案、Har方案和改進(jìn)方案下NameNode的內(nèi)存使用情況，結(jié)果見圖5．對(duì)于文本類型的小文件，Har方案的小文件合并機(jī)制比SequenceFile或Map File方案更有優(yōu)勢(shì)，因此選取Har方案進(jìn)行對(duì)比．使用bin/hadoop jar hadoop-0.20.2-test.jar nnbench測(cè)試命令，可以獲得NameNode的內(nèi)存使用情況．

圖5 NameNode內(nèi)存使用情況Fig.5 Memory usage of NameNode

由圖5可知：不處理而直接存儲(chǔ)小文件的HDFS原方案占用內(nèi)存最多，這是因?yàn)镹ameNode中為每個(gè)小文件都建立了元數(shù)據(jù)信息；Har方案對(duì)NameNode的內(nèi)存消耗問題有明顯改進(jìn)，在存儲(chǔ)106個(gè)小文件時(shí)的內(nèi)存消耗僅為原方案的42.6%,；而改進(jìn)方案存儲(chǔ)106個(gè)小文件的內(nèi)存消耗僅為HDFS原方案的28.7%,，為Har方案的67.4%,，這是因?yàn)槌撕喜⒋罅啃∥募?，還將索引文件轉(zhuǎn)移到了DataNode上，由DataNode開銷內(nèi)存去管理，從而降低了NameNode內(nèi)存使用率．

在客戶端的檢索程序中，隨機(jī)訪問集群中某合并文件上的小文件，分別比較HDFS原方案、MapFile方案以及本文優(yōu)化方案下的檢索時(shí)間，實(shí)驗(yàn)結(jié)果見圖6．MapFile方案的檢索效率比Har和SequenceFile高，因此選取MapFile方案進(jìn)行對(duì)比．在不同文件數(shù)量下，分別選取10個(gè)時(shí)間段內(nèi)的小文件，每個(gè)時(shí)間段隨機(jī)輸入10個(gè)編號(hào)值，則每種方案下隨機(jī)檢索共100個(gè)小文件，為減小偶然誤差影響，去除各時(shí)段內(nèi)檢索用時(shí)最少和最多的各兩個(gè)值，然后計(jì)算平均檢索時(shí)間．

圖6 平均檢索時(shí)間曲線Fig.6 Diagram of average search time

由圖6可知：當(dāng)數(shù)據(jù)量為106個(gè)小文件時(shí)，改進(jìn)方案的檢索時(shí)間比HDFS原方案減少了約1.3,s，比Map File方案減少了約0.15,s，在不同數(shù)據(jù)量下，改進(jìn)方案的檢索時(shí)間均有明顯提升，而且隨著文件數(shù)量的繼續(xù)增加，檢索時(shí)間的優(yōu)化效果會(huì)更加明顯．

從兩組實(shí)驗(yàn)結(jié)果可知，改進(jìn)優(yōu)化方案對(duì)小文件大量消耗NameNode內(nèi)存和內(nèi)部小文件的隨機(jī)訪問效率這兩個(gè)性能指標(biāo)均有明顯的改善和提高．

5 結(jié) 語

對(duì)海量多源異構(gòu)的物聯(lián)網(wǎng)感知數(shù)據(jù)的處理是實(shí)現(xiàn)智慧化校園服務(wù)的關(guān)鍵部分，核心模塊主要面向3個(gè)方面的處理需求：日志分析、數(shù)據(jù)統(tǒng)計(jì)等高并行需求的計(jì)算任務(wù)；面向用戶的智能化事件監(jiān)控；海量結(jié)構(gòu)化小文件的存儲(chǔ)與訪問服務(wù)．這些需求既是本文的研究意義所在，也是構(gòu)建校園物聯(lián)網(wǎng)云數(shù)據(jù)中心必須關(guān)注和解決的重要問題．本文設(shè)計(jì)并實(shí)現(xiàn)了一種基于Hadoop的面向校園物聯(lián)網(wǎng)服務(wù)的數(shù)據(jù)處理系統(tǒng)，針對(duì)處理海量結(jié)構(gòu)化小文件的需求對(duì)文件處理進(jìn)行了改進(jìn)．不足之處是，本文并未對(duì)并行計(jì)算任務(wù)的負(fù)載均衡和ECA規(guī)則響應(yīng)的實(shí)時(shí)性進(jìn)行探討，有待進(jìn)一步研究．

［1］ 李開復(fù).云計(jì)算[J].中國教育網(wǎng)絡(luò)，2008(6)：34.

［2］ 馮志杰.云計(jì)算在校園物聯(lián)網(wǎng)中的應(yīng)用研究[J].青島大學(xué)學(xué)報(bào)：工程技術(shù)版，2014(3)：44–48.

［3］ 呂倩.基于云計(jì)算及物聯(lián)網(wǎng)構(gòu)建智慧校園[J].計(jì)算機(jī)科學(xué)，2011(S1)：18–21，40.

［4］ Brock Noland.Mounting HDFS[EB/OL].[2012–01–20].http://wiki.apache.org/hadoop/MountableHDFS.

［5］ 朱達(dá).基于事件的服務(wù)協(xié)同及通信服務(wù)提供技術(shù)研究[D].北京：北京郵電大學(xué)，2011.

［6］ 周國安，李強(qiáng)，陳新，等.云環(huán)境下海量小文件存儲(chǔ)技術(shù)研究綜述[J].信息網(wǎng)絡(luò)安全，2014(6)：11–17.

［7］ Visser W，Havelund K，Brat G，et al.Model checking programs[J].Automated Software Engineering，2003， 10(2)：203–232.

［8］ 余思，桂小林，黃汝維，等.一種提高云存儲(chǔ)中小文件存儲(chǔ)效率的方案[J].西安交通大學(xué)學(xué)報(bào)，2011，45(6)：59–63.

［9］ 王濤，姚世紅，徐正全，等.云存儲(chǔ)中面向訪問任務(wù)的小文件合并于預(yù)取策略[J].武漢大學(xué)學(xué)報(bào)，2013，38(12)：1504–1508.

［10］ 孔令波，唐世渭，楊冬青，等.XML數(shù)據(jù)索引技術(shù)[J].軟件學(xué)報(bào)，2005，16(12)：2063–2079.

責(zé)任編輯：常濤

Campus Network Data Processing System Based on Hadoop

XIONG Congcong，JI Sujie，WANG Lanting
(College of Computer Science and Information Engineering，Tianjin University of Science & Technology，Tianjin 300222，China)

According to the problems of poor performance of massive data processing，high cost for storage，operation and maintenance，difficult expansion and upgrading of equipment existing in the single campus application system，a data processing system was designed based on Hadoop，which can provide a useful scheme for building campus cloud data center and realizing campus wisdom service.A feasible improvement program of the system file processing module was proposed in order to meet the processing needs of massive structured small files.Experiments show that the improved program is more efficient than the existing solutions to reducing the memory consumption of the primary node and can improve the accessing efficiency of small files.

campus network；Hadoop；data processing；structure small file

TP399

A

1672-6510(2015)05-0072-06

10.13364/j.issn.1672-6510.20140163

2014–12–17；

2015–03–04

天津市科技型中小企業(yè)創(chuàng)新資金資助項(xiàng)目(12ZXCXGX33500)；國家自然科學(xué)基金資助項(xiàng)目(61272509)

熊聰聰（1961—），女，四川人，教授，xiongcc@tust.edu.cn.