基于Hadoop的海量氣象雷達小文件存儲研究

楊芙容， 王永麗， 王文明

(成都信息工程大學信息安全工程學院，四川成都610225)

0 引言

近年，氣象現代化業(yè)務飛速發(fā)展，為廣大用戶提供更加全面、更加精細化的氣象服務，其中，氣象雷達近年呈高速發(fā)展的態(tài)勢，受到世界多數國家和國際氣象組織的高度重視［1］。尤其是多普勒天氣雷達技術日益普遍的使用，獲得了更多的探測數據信息，提高了天氣的監(jiān)測能力，對預報強對流天氣等具有非常重要意義。同時，氣象現代化造成氣象數據的成倍增長，對系統(tǒng)的存儲和處理能力提出很高的要求。

傳統(tǒng)的關系型數據庫系統(tǒng)在存儲和管理數據上出現負載飽滿讀寫性能不理想等問題［2］，迫切需要新的海量數據處理方案，在眾多的海量數據處理平臺中，Apache Hadoop［3］已經迅速成為存儲和處理海量數據的首選平臺之一。國際上著名的互聯網門戶網站雅虎、社交網絡服務網站Face Book，以及國內淘寶、百度等眾多知名的IT企業(yè)，先后采用Hadoop開發(fā)出適合自己的數據管理平臺。Hadoop具有吞吐量大、效率高、容錯性高、可靠性高、成本低等優(yōu)點，能夠擴展到云環(huán)境，適用于氣象雷達這種有多種處理需求的應用場景。

1 Hadoop核心組成

Hadoop是Apache軟件基金會旗下的一個開源分布式計算平臺，核心組件包括 HDFS、Map Reduce、HBase等［4］，HDFS形成Hadoop的文件分布式系統(tǒng);HBase是一個面向列的分布式數據庫，可靠性高、可伸縮、提供實時讀寫;Map Reduce是Hadoop的數據處理模塊，能對存儲在HDFS和HBase中的大規(guī)模數據進行高效的分布式并行處理。

HDFS采用主從式架構設計模式(master/slaver structure)，一個名稱節(jié)點(Name Node)和若干數據節(jié)點(Data Node)構成HDFS集群。Name Node是 HDFS中的管理者，負責存儲和管理文件系統(tǒng)的命名空間(name space)，文件目錄的元數據，集群配置(cluster configuration)和存儲塊的復制情況等信息。Name space是一個分層結構的文件和目錄，記錄權限，修改和訪問時間，命名空間和磁盤空間配額等屬性。DataNode是HDFS的基本組成部分，提高文件數據的存儲服務。它將文件以分塊形式存儲到本地文件系統(tǒng)，并周期性地將所存塊的信息發(fā)送給Name Node。

HBase的設計源于Big Table的啟發(fā)，在HDFS上開發(fā)的一個分布式數據庫。數據集，主要存儲處理大規(guī)模的非結構化和半結構化的數據。Hbase使用LSM樹型結構，將需要修改的數據直接寫入內存。操作數據時直接定位到相應的HRegion server，在region上找到匹配的數據，而且引入高速緩存，使HBase能提供實時計算服務。

2 小文件問題

把海量小文件(小于16MB的文件)直接存儲在HDFS上存在的問題簡稱為小文件問題［5］。為節(jié)省內存空間和提高傳輸效率，氣象雷達文件在存儲和使用前通常先做壓縮處理，壓縮后文件大小在幾KB到幾百KB之間，屬于小文件范疇，這就可能引發(fā)小文件問題。

(1)Name Node內存溢出

Name Node直接把文件系統(tǒng)的元數據存儲在主存中，通常一個文件的元數據占250bytes內存，每個塊的3個復制文件的元數據占368bytes［6］，文件數目越大，占用的Name Node內存空間也成倍數增加。此外，DataNodes定時向Name Node發(fā)送塊報告信息，Name Node收集這些信息，作為塊映射信息存儲在內存中。當文件數目很大時，這部分信息所占內存不容忽視。由式(1)可以看出減少Name Node內存占用的主要方法是減少Name Node管理的文件個數和塊數目。

其中M是Name Node的內存占用，N文件數，β代表塊的映射信息，HBS是設定的塊大小，默認取整為64 M，Li是每個小文件的大小表示比值向上取整，a為Name Node所占內存，這部分內存很小。

(2)訪問延遲高

當讀取大量的小文件出現高訪問延遲主要有3個原因:首先，HDFS客戶端每操作一個文件都需要訪問一次Name Node元數據，引發(fā)元數據服務器的頻繁相互作用的延遲。如640 MB的大文件(10個64 MB文件)I/O吞吐量，HDFS客戶端只需要訪問Name Node 5次，而在相同大小下(如10240個64 KB文件)，客戶需要訪問Name Node 5120次，這種延遲很明顯。其次，HDFS失去塊間關系。HDFS有自己的放置策略，可以在可擴展性、讀效率、寫帶寬之間達到很好的平衡。但沒有考慮文件的連續(xù)性，連續(xù)文件不一定連續(xù)放置，甚至可能被放在不同的塊中［7］。再者，HDFS目前沒有提供預取函數降低I/O延遲，沒有為數據的放置和預取機制考慮文件的相關性，從HDFS中讀取小文件時，通常需要多次查找和在Data Node和Data Node之間反復來回跳轉。

(3)Map任務過多

在HDFS中文件按塊存儲，文件不滿64 MB(Block默認64 MB)也占用一個Block。Map任務通常一次處理一個塊輸入，這樣Block數目越多，Map任務越多，而實際上，每個map只處理很少的數據量，這就造成額外的簿記開銷，大量時間浪費在任務啟動和結束上。如處理1 GB的一個大文件需要16個64 MB的塊，而處理1 GB的1萬個左右100 KB的小文件需要1萬個64 MB的塊。這1萬個小文件的map效率要比大文件map效率低幾十到幾百倍。

3 優(yōu)化方案設計

目前，基于HDFS的海量小文件存儲和訪問效率問題的解決方法主要分為3類。

(1)利用Hadoop自身提供的方法合并小文件，如hadoop 歸檔［8］(Hadoop archive，HAR)、Sequence File［9］等，但這些方法存在很多問題，最突出的是訪問效率低下。

(2)針對具體的應用提出對應的文件合并、組合方法，通常在HDFS上添加一個小文件處理模塊［10］，由處理模塊完成數據的合并、更新、刪除、緩存等操作:Xuhui Liu等［11］將地理位置信息相鄰的多個小文件合并成一個大文件，為檢索到小文件的位置，為其建立一個全局的位置索引，減少Name Node的內存占用。但是當小文件數據量非常大時，全局的位置索引文件就變得十分龐大，每次定位一條數據耗費大量時間，文件的檢索速率低;Bo Dong等［12］提出將同一個課程 PPT的多個圖片小文件合并成大文件，在Data Node上為每個文件建立一個本地的單獨索引查詢方法，分擔Name Node的查詢負擔。但合并文件超過默認塊大小時，該方法比較復雜，需要人為干預小文件的合并和建立索引操作。

(3)改進系統(tǒng)的架構。文獻［13］提出一種增強型的HDFS，擴展單一的Name Node成分層Name Node的架構，同時擴展的HDFS架構中集成高速緩存，提高文件的讀取效率。劉小俊等［14］提出將 RDBMS和 Hadoop結合，前端RDBMS作為小文件訪問入口和合并工具，后端Hadoop存儲和處理海量數據，發(fā)揮各自的優(yōu)勢。但總的來說，改進架構非常復雜，成本高而且較難實現。

3．1 基本思想

多普勒天氣雷達通常每幾分鐘(6 min)完成一個體掃，每個體掃文件里包含N·(Z、V、W)一次產品文件、一個VOL和根據需要設定的多個二次產品文件，其中N表示每次抬高的仰角層數，一天24小時不間斷采集雷達數據。

為節(jié)省磁盤空間和網絡帶寬，把每個體掃的產品文件采用壓縮方式存儲。針對氣象雷達數據的特征，壓縮后將文件格式命名為:年月日_時分秒.掃描層號.產品Type.掃描模式.產品參數20141214-125233.00.004.000-0.47.zdb，表示20141214.12:52:33.表示:第0層.v產品.000掃描式.0.47產品參數(仰角)的一個V產品文件。

表1 壓縮文件命名格式

壓縮后體掃文件大小在幾KB到幾百KB之間，其中一次產品文件壓縮后文件大小為通常幾到幾十KB，這部分數據對系統(tǒng)的數據處理實時性要求比較高，在存儲時選擇HBase。HBase基于HDFS之上，可以將操作分散到多個節(jié)點上并行處理，執(zhí)行效率很高，能夠提供實時計算服務。其他的VOL文件和二次產品文件通常對系統(tǒng)的實時性要求不高，是由一次產品文件根據需要計算整合。對于這些文件采用Sequence File合并技術，以VOL文件和二次產品文件的文件名為key、文件內容為value的形式進行合并，減少元數據的內存占用量，節(jié)省Name Node的內存空間。全文存儲系統(tǒng)架構模型如圖1所示。

圖1 存儲系統(tǒng)架構模型

3．2 一次產品文件的存儲

HBase無模式無類型，由行和列組成。行和列的坐標交叉決定表格單元格(cell)。cell的內容是未解釋的字符數組。HBase具有很好的可伸縮性，表可以數十億個數據行“高”;表可以很“寬”(數百萬個列)。表的模式直接反映存儲形式，可以提供高效的數據結構的序列化、存儲和檢索。HBase處理幾十KB的小文件時，查詢效率很高［15］，把ZVW一次產品文件直接存儲在HBase中有利于提高文件的讀取效率。

HBase行鍵設計:HBase通過行鍵(row key)、列族(Column Family)、列和版本4個維度定位某條數據，它不能像傳統(tǒng)數據庫一樣支持where等條件查詢，只能全盤掃面或按row key檢索數據。HBase存儲模型設計時，首先需要根據業(yè)務設計行鍵，檢索記錄的主鍵，可以利用其存儲排序特性提高性能。

在天氣雷達業(yè)務中，雷達產品文件一般以時間和產品參數作為標識，這兩個維度也是常用的檢索條件，因此設計時間+產品參數的行鍵設計方案。為能將region server的負載均衡，防止出現所有新數據都在一個region server上堆積的現象，設計row key時采用隨機散列與預分區(qū)二者相結合的方法。預分區(qū)開始就預建好一部分region，這些region都維護著自已的star tend keys，由MD5方式生成隨機字符串，寫數據能均等地命中這些預建的region，解決寫熱點問題，大大地提高性能。

HBase列族設計。HBase表中列族需要提前定義，是表chema的重要組成部分。不同列族的數據是存儲在不同的HFile中，所以一般把同時訪問的數據放在一個列族中，而在氣象雷達應用中，因為業(yè)務需要訪問全要素，所以把同一類型的數據都放置在一個列族中;以首字母和產品參數作為列族和列的標識符。例如列FP∶Z、FP∶V都屬于FP(First Product)這個列族。

3．3 VOL文件和二次產品文件的存儲

由于VOL文件和二次產品文件的存儲和訪問對系統(tǒng)的實時性要求不高，而且經過壓縮后的VOL文件和二次產品文件大小通常為幾十到幾百KB，采用Hadoop提供的應用程序編程接口 API:Sequence File［16］，主要由一個Header后跟多條Record組成。Header主要包含版本、Key、value類名、壓縮方式判斷、自定義信息和同步標識等，同步標識用于快速定位到記錄的邊界。每條Record以鍵值對的方式進行存儲，表示字符數組。

Sequence File根據壓縮與否有3種存儲形式，Value壓縮、block壓縮和不壓縮存儲，通過Sequence File類的內部類Compression Type表示。采用不壓縮方式存儲 io.seqfile.compression.type=NONE。

Sequence File通過創(chuàng)建Sequence File.Write實現寫入，然后調用writer.append(key，value)打包記錄。它就像為存儲提供一個容器，將多個小文件打包統(tǒng)一存儲。在存儲氣象雷達數據時，采用Sequence File技術將文件進行合并處理，將VOL和二次產品文件的文件名作為key，文件的內容作為value序列化合并成一個大文件，合并后的文件元數據信息存儲在Name Node中，節(jié)省Name Node的內存空間。

4 實驗測試

4．1 測試環(huán)境

測試使用4臺服務器構建集群，其中1臺作為主服務器 master，3 臺從節(jié)點 node1、node2、node3;服務器配置Intel(R)Core(TM)2 Quad CPU Q8200@2.33 GHz 2.34 CHz，內存4GB硬盤500GB，操作系統(tǒng) Red Hat Enterprise Linux Sever release 6.5，Hadoop版本是1.2.3，HDFS副本數dfs.replication設置為3，HDFS最小塊設置為默認值64 MB，Second Name node配置在node1上。HBase版本是0.94.1，使用HBase自帶的zookeeper。

4．2 實現方法

實驗測試中數據是某臺多普勒氣象雷達2014年6月觀察的數據，701134條記錄，壓縮后總大小為11.2 GB，每條記錄都在1～500 KB，其中一次產品文件壓縮文件大都小于100 KB。

Name Node的內存受限問題一直是制約其對海量小文件存儲的關鍵因素，因此減少Name Node的內存占用具有重要意義。HDFS設計建立在更多地響應“一次寫入，多次讀出”任務的基礎之上，因此提高文件的讀取速率也至關重要。故從Name Node的內存占用和文件讀取時間兩個方面進行測試和評估方案。這里把提出的方法和直接存儲HDFS方案進行比較。

4．3 實驗結果

Name Node內存占用(MB/文件個數)

圖3 Name Node內存占用

圖3表示2種方案對不同數量的文件存儲時，Name Node內存使用情況，文件數量由0、5000、10 000依次遞增至25 000。綠色線表明在對小文件不做任何處理直接存儲時，隨著小文件數目的增加，內存占用量呈現線性增長趨勢。采用將VOL文件和二次產品Sequence File合并技術打包存儲極大地減少元數據的內存占用，同時一次產品文件是存儲在HBase上的，節(jié)省了Name Node的內存空間。

讀操作(s/文件個數)

圖4 讀取時間

由于氣象數據在存儲和調用時多數時間操作時間連續(xù)的那些文件，所以分別測試時間連續(xù)的50 000～250 000個文件。而在存儲方案中把一次產品和其他產品文件采用兩種不同的方式存儲，在測試讀取時間時需要分別討論。分別將HBase和sequence File訪問時間與直接HDFS讀取時間比較。測試結果表明，HBase對一次產品文件的響應時間遠小于直接從HDFS讀取氣象文件的時間。而對氣象雷達數據的操作頻繁牽涉到對一次產品文件的訪問，HBase提供實時操作服務，極大地提升文件的訪問速率，節(jié)省了文件的讀取時間。

5 結束語

針對氣象雷達數據的特征，先把每個產品文件采用壓縮方式存儲，壓縮后每個產品文件大小為幾KB到幾百KB，節(jié)省了Data Node的內存空間。由于每個體掃中的一次產品文件對數據處理的實時性要求比較高，針對這些特殊原因，在存儲時選擇HBase，它提供實時計算，處理速度非?？?。采用時間+產品參數的行主鍵設計方案，利用隨機散列與預分區(qū)保證負載均衡，最終提高一次產品文件的讀取效率。

此外，一個體掃周期除了生成ZVW一次產品文件，還生成一個VOL文件和根據需要計算生成多個二次產品，對系統(tǒng)的實時性要求不高，而且大小通常為幾十到幾百KB。對于這些文件直接存儲在HBase上加重其負擔，同時HBase更適合處理幾十KB的文件，文件過大降低其處理速度，所以利用Hadoop自身提供的Sequence File技術先小文件合并為大文件，Name Node中只需要存儲合并后的文件元數據，節(jié)省Name Node的內存空間。

HBase不支持輔助索引，但在氣象數據檢索時效性上仍需要使用輔助索引［17］，在接下來的工作中，將考慮設計適合氣象數據的輔助索引模塊;同時對 Sequence File中的VOL和二次產品文件設計索引和查找算法，以提高其查找速度。

［1］ 伍志方，曾沁，易愛民，等.短時大暴雨的多普勒雷達探測及暴雨預警信號發(fā)布［J］.災害學，2006，21(2):59-63.

［2］ 陳東輝，曾樂，梁中軍，等.基于HBase的氣象地面分鐘數據分布式存儲系統(tǒng)［J］.計算機應用，2014，34(9):2617-2621.

［3］ Shvachko K，Kuang H，Radia S，et al.The Hadoop Distributed File System［C］.In:IEEE 26th symposium on mass storage systems and technologies(MSST).IEEE;2010:1-10.

［4］ Jilan Chen，Dan Wang，Lihua Fu，et al.An Improved Small File Processing Method for HDFS［C］.International Journal of Digital Content Technology and its Applications(JDCTA).2012，(6):200-205.

［5］ Tom White.The Smal Files Problem［EB/OL］.Http://www.clouder.com/blog/2009/02/02/the small files problem/.

［6］ Tom White.The Smal Files Problem［EB/OL］.Http://issues.apache.org/jira/browse/Hadoop-1687.

［7］ Bo Dong，QinghuaZheng，FengTian，et al.An optimized approach for storing and accessing small files on cloud storage［C］.elsevier.2012，(6):1847-1862.

［8］ Chatuporn，Vorapongkitipun，Natamut，Nupairoj.Improving Performance of Small File Aceessing［C］.International Joint Conference on Computer Science and Software Engineering(JCSSE)2014(11):200-205.

［9］ 趙曉勇，楊揚，孫莉莉，等.基于Hadoop的海量MP3文件存儲架構［J］.計算機應用，2012，6(1):1724-1726.

［10］ K P Jayakar，Y B Gurav.Managing Small Size Files through Indexing in Extended Hadoop File System［C］.International Journal of Advance Research in Computer Science and Management Studies.2014，8(8):161-167.

［11］ Liu X，Han J，Zhong Y，et al.Implementing webgis on hadoop:a case study of improving small file i/o performance on hdfs.［C］In:IEEE international conference on cluster computing and workshops，2009，12，(1):1-4.

［12］ BoDong，Qiu Jie，Qinghua Zheng，et al.A novel approach to improving the efficiency of storing and accessing small files on hadoop:a case study by Power Point files［C］.Proceedings of the 7th Int ernational Conference on Services Computing.Piscataw ay，N J，USA:IEEE，2010:65-72.

［13］ Xiayu Hua，Hao Wu，Zheng Li，et al.Enhancing throughput of the Hadoop Distributed File System for interaction-intensive tasks［C］.2014:2770-2779.

［14］ 余思，桂小林，黃汝維，等.一種提高云存儲中小文件存儲效率的方案［J］.西安大學報，2011，45(6):60-63.

［15］ Ganggang Zhang，Min Zuo，Xinliang Liu，et al.Improving the efficiency of storing SNS small files in HDFS［C］.CCIS 426.2014:154-160.

［16］ 薛勝軍，刪寅.基于Hadoop的氣象信息數據倉庫建立與測試.計算機測量與控制［J］.2012，20(4):926-928.

［17］ Chen P，AN J.The key as dictionary compression method of inverted index table under the HBase database［J］.Journal of Software，2013，8(5):1086-1093.