楊芙容， 王永麗， 王文明

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

0 引言

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

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

1 Hadoop核心組成

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

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

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

2 小文件問題

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

(1)Name Node內(nèi)存溢出

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

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

(2)訪問延遲高

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

(3)Map任務(wù)過多

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

3 優(yōu)化方案設(shè)計(jì)

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

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

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

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

3．1 基本思想

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

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

表1 壓縮文件命名格式

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

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

3．2 一次產(chǎn)品文件的存儲

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

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

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

HBase列族設(shè)計(jì)。HBase表中列族需要提前定義，是表chema的重要組成部分。不同列族的數(shù)據(jù)是存儲在不同的HFile中，所以一般把同時(shí)訪問的數(shù)據(jù)放在一個(gè)列族中，而在氣象雷達(dá)應(yīng)用中，因?yàn)闃I(yè)務(wù)需要訪問全要素，所以把同一類型的數(shù)據(jù)都放置在一個(gè)列族中;以首字母和產(chǎn)品參數(shù)作為列族和列的標(biāo)識符。例如列FP∶Z、FP∶V都屬于FP(First Product)這個(gè)列族。

3．3 VOL文件和二次產(chǎn)品文件的存儲

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

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

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

4 實(shí)驗(yàn)測試

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

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

4．2 實(shí)現(xiàn)方法

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

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

4．3 實(shí)驗(yàn)結(jié)果

Name Node內(nèi)存占用(MB/文件個(gè)數(shù))

圖3 Name Node內(nèi)存占用

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

讀操作(s/文件個(gè)數(shù))

圖4 讀取時(shí)間

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

5 結(jié)束語

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

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

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

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

［2］ 陳東輝，曾樂，梁中軍，等.基于HBase的氣象地面分鐘數(shù)據(jù)分布式存儲系統(tǒng)［J］.計(jì)算機(jī)應(yīng)用，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，F(xiàn)engTian，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］ 趙曉勇，楊揚(yáng)，孫莉莉，等.基于Hadoop的海量MP3文件存儲架構(gòu)［J］.計(jì)算機(jī)應(yīng)用，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］.西安大學(xué)報(bào)，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的氣象信息數(shù)據(jù)倉庫建立與測試.計(jì)算機(jī)測量與控制［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.