熊聰聰，吉蘇杰，王蘭婷

(天津科技大學計算機科學與信息工程學院，天津 300222)

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

熊聰聰，吉蘇杰，王蘭婷

(天津科技大學計算機科學與信息工程學院，天津 300222)

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

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

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

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

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

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

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

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

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

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

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

2 系統(tǒng)架構設計

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

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

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

3 核心模塊設計

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

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

3.2 ECA規(guī)則模塊

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

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

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

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

3.3 文件處理模塊

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

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

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

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

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

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

3.3.2 改進方案設計

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

圖4 改進方案的工作原理Fig.4 Working principle of the improved scheme

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

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

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

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

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

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

4 系統(tǒng)實驗與分析

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

4.1 統(tǒng)計測試與分析

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

表1 關鍵詞匯統(tǒng)計測試結果Tab.1 Key words statistical test results

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

4.2 改進方案的性能分析

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

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

圖5 NameNode內存使用情況Fig.5 Memory usage of NameNode

由圖5可知：不處理而直接存儲小文件的HDFS原方案占用內存最多，這是因為NameNode中為每個小文件都建立了元數(shù)據(jù)信息；Har方案對NameNode的內存消耗問題有明顯改進，在存儲106個小文件時的內存消耗僅為原方案的42.6%,；而改進方案存儲106個小文件的內存消耗僅為HDFS原方案的28.7%,，為Har方案的67.4%,，這是因為除了合并大量小文件外，還將索引文件轉移到了DataNode上，由DataNode開銷內存去管理，從而降低了NameNode內存使用率．

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

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

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

從兩組實驗結果可知，改進優(yōu)化方案對小文件大量消耗NameNode內存和內部小文件的隨機訪問效率這兩個性能指標均有明顯的改善和提高．

5 結 語

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

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

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

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

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

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

［6］ 周國安，李強，陳新，等.云環(huán)境下海量小文件存儲技術研究綜述[J].信息網(wǎng)絡安全，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］ 余思，桂小林，黃汝維，等.一種提高云存儲中小文件存儲效率的方案[J].西安交通大學學報，2011，45(6)：59–63.

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

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

責任編輯：常濤

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)新資金資助項目(12ZXCXGX33500)；國家自然科學基金資助項目(61272509)

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