劉驥超，葉 釩，謝寒生

(1.海南省氣象信息中心，海南 ?？?570203；2.海南省南海氣象防災(zāi)減災(zāi)重點(diǎn)實(shí)驗(yàn)室，海南 ?？?570203)

0 引 言

計(jì)算機(jī)技術(shù)的飛速發(fā)展帶來(lái)了數(shù)據(jù)量的指數(shù)級(jí)增長(zhǎng)，互聯(lián)網(wǎng)傳統(tǒng)的客戶(hù)端-服務(wù)器架構(gòu)也面臨著數(shù)據(jù)爆炸的挑戰(zhàn)。2006年8月9日，由Google首席執(zhí)行官Eric Schmidt在SES San Jose 2006首次提出云計(jì)算[1]技術(shù)，對(duì)海量數(shù)據(jù)處理方式的改變是革命性的。Google云計(jì)算眾多開(kāi)源實(shí)現(xiàn)中最著名的是Apache Hadoop[2]，自發(fā)布后多數(shù)互聯(lián)網(wǎng)公司和數(shù)據(jù)庫(kù)廠(chǎng)商已支持使用，其中多家公司進(jìn)行了更高效率的改進(jìn)和研發(fā)[3]。

在氣象這樣的特殊行業(yè)，必須按要求安全、實(shí)時(shí)、高效地處理各類(lèi)獲得的數(shù)據(jù)。隨著觀(guān)測(cè)技術(shù)的快速發(fā)展，各類(lèi)觀(guān)測(cè)數(shù)據(jù)逐漸增加，已經(jīng)達(dá)到了海量數(shù)據(jù)的量級(jí)，利用傳統(tǒng)技術(shù)處理這些海量數(shù)據(jù)的效率已無(wú)法滿(mǎn)足現(xiàn)行業(yè)務(wù)需求。因此，研究人員嘗試?yán)迷朴?jì)算技術(shù)尋求解決之法[4]。

在氣象現(xiàn)代化推進(jìn)的過(guò)程中，氣象觀(guān)測(cè)、預(yù)報(bào)、科研等活動(dòng)中收集并積累了大量氣象資料[5]，其中氣象業(yè)務(wù)數(shù)據(jù)包括地面、高空、雷達(dá)、數(shù)值、衛(wèi)星等十幾種，如國(guó)家氣象衛(wèi)星中心每天通過(guò)CMACast收到的資料高達(dá)TB數(shù)量級(jí)，目前在用的全國(guó)綜合氣象信息共享平臺(tái)CIMISS(省級(jí))中每天在省內(nèi)收集以及接收國(guó)家級(jí)下發(fā)的氣象資料也有幾百甚至上千MB[6]，從這些海量數(shù)據(jù)中挖掘出的有用信息對(duì)提高天氣預(yù)報(bào)和災(zāi)害天氣預(yù)警準(zhǔn)確率具有相當(dāng)關(guān)鍵的作用[7]。在當(dāng)前氣象觀(guān)測(cè)技術(shù)快速發(fā)展的前提下，已經(jīng)能夠獲取到豐富的氣象資源，對(duì)這些海量的氣象數(shù)據(jù)進(jìn)行處理需要進(jìn)行大量的科學(xué)計(jì)算，而云計(jì)算恰好滿(mǎn)足這些需求[8]。

1 相關(guān)技術(shù)簡(jiǎn)介

1.1 Hadoop

Apache Hadoop是基于Google云計(jì)算技術(shù)的開(kāi)源實(shí)現(xiàn)，它的框架可以使計(jì)算能力通過(guò)互聯(lián)網(wǎng)傳輸，并且具有高可靠性、高擴(kuò)展性、高效性、高容錯(cuò)性、低成本的優(yōu)點(diǎn)[9]。Hadoop的核心組件包括Google GFS、BigTable、MapReduce。其中Google GFS是一個(gè)可擴(kuò)展的分布式文件系統(tǒng)，用于分布式的、大型的、對(duì)大量數(shù)據(jù)進(jìn)行訪(fǎng)問(wèn)的應(yīng)用，能夠在廉價(jià)的普通硬件上運(yùn)行，同時(shí)提供容錯(cuò)功能[10]，其開(kāi)源實(shí)現(xiàn)就是分布式存儲(chǔ)模型HDFS[11]Hadoop distributed file system)。BigTable顧名思義就是大型數(shù)據(jù)庫(kù)，區(qū)別僅在于這個(gè)數(shù)據(jù)庫(kù)是分布式的。MapReduce是一種分布式的計(jì)算模型，它的運(yùn)行原理是將需要執(zhí)行的任務(wù)進(jìn)行分割并分配至各個(gè)節(jié)點(diǎn)，分配的任務(wù)由各個(gè)節(jié)點(diǎn)分別執(zhí)行，最后將執(zhí)行結(jié)果合并形成總體計(jì)算結(jié)果，這樣的模式能夠解決單機(jī)計(jì)算能力不足的問(wèn)題。下面主要介紹HDFS和MapReduce兩個(gè)組件。

1.2 分布式文件系統(tǒng)(HDFS)

HDFS分布式存儲(chǔ)模型是GFS(Google file system)的開(kāi)源實(shí)現(xiàn)[12]。作為最底層的組件，HDFS的體系結(jié)構(gòu)是一個(gè)主從結(jié)構(gòu)[13]，主節(jié)點(diǎn)Namenode只有一個(gè)，從節(jié)點(diǎn)Datanode有很多個(gè)。主節(jié)點(diǎn)Namenode與從節(jié)點(diǎn)Datanode實(shí)際上指的是不同的物理機(jī)器，即有一個(gè)機(jī)器跑的進(jìn)程是Namenode，很多機(jī)器上跑的進(jìn)程是Datanode。NameNode是作為一個(gè)管理的主服務(wù)器，系統(tǒng)中文件的命名空間由其來(lái)管理，同時(shí)各終端對(duì)文件的訪(fǎng)問(wèn)協(xié)調(diào)工作也由它負(fù)責(zé)。對(duì)外部使用的客戶(hù)機(jī)來(lái)說(shuō)，內(nèi)部各項(xiàng)管理及協(xié)調(diào)都是透明的，HDFS就像一個(gè)傳統(tǒng)的支持增刪改查等操作的分級(jí)文件系統(tǒng)。

在HDFS內(nèi)部，要存儲(chǔ)的文件被分成塊并將這些塊復(fù)制到多個(gè)Datanode數(shù)據(jù)節(jié)點(diǎn)。需要分割的塊的大小以及塊的復(fù)制數(shù)量是在創(chuàng)建文件時(shí)由客戶(hù)機(jī)決定，最終由Namenode主節(jié)點(diǎn)來(lái)控制所有文件操作。在HDFS系統(tǒng)中，主節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)均可以部署在配置普通的硬件上，在各個(gè)節(jié)點(diǎn)上通常部署為L(zhǎng)inux操作系統(tǒng)。Hadoop是基于Java語(yǔ)言開(kāi)發(fā)的，而且HDFS內(nèi)部的所有通信都基于標(biāo)準(zhǔn)的TCP/IP協(xié)議，因而很容易將HDFS在大規(guī)模集群上部署。

1.3 分布式計(jì)算模型(MapReduce)

MapReduce[14]是目前為止最為成功、最廣為接受和最易于使用的大數(shù)據(jù)并行處理技術(shù)。MapReduce模型就是一種簡(jiǎn)化并行計(jì)算的編程模型，將應(yīng)用切分為多個(gè)小任務(wù)，分配至各個(gè)節(jié)點(diǎn)并行執(zhí)行，用集群服務(wù)器超強(qiáng)的并行計(jì)算能力解決單機(jī)并行能力不足的缺點(diǎn)[15]。

MapReduce的根源是函數(shù)性編程中的map和reduce函數(shù)，map函數(shù)轉(zhuǎn)換一組數(shù)據(jù)為key/value列表，輸入域的每個(gè)元素都與一個(gè)key/value對(duì)應(yīng)。而reduce函數(shù)則根據(jù)map函數(shù)產(chǎn)生列表的key值來(lái)縮減這個(gè)列表。對(duì)于每個(gè)輸入域執(zhí)行map和reduce函數(shù)，再將生成的列表應(yīng)用于另一個(gè)reduce函數(shù)，能夠得到相同的結(jié)果。這保證了MapReduce可以在輸入域并行使用相同的操作。簡(jiǎn)單說(shuō)來(lái)，一個(gè)映射函數(shù)就是對(duì)一些獨(dú)立元素組成的概念上的列表的每一個(gè)元素進(jìn)行指定操作。因而每個(gè)元素都是被獨(dú)立操作的，且原始列表沒(méi)有被更改，之后再創(chuàng)建一個(gè)新的列表來(lái)保存新的答案?；谝陨显?，map操作是可以高度并行的，這對(duì)高性能要求的應(yīng)用以及并行計(jì)算領(lǐng)域的需求非常有用。而化簡(jiǎn)操作指的是對(duì)一個(gè)列表的元素進(jìn)行適當(dāng)合并。雖然化簡(jiǎn)不如映射函數(shù)那么并行，但是因?yàn)榛?jiǎn)總是有一個(gè)簡(jiǎn)單的答案，大規(guī)模的運(yùn)算相對(duì)獨(dú)立，所以化簡(jiǎn)函數(shù)在高度并行環(huán)境下也很有用。這就是MapReduce的強(qiáng)大之處，它可以在任意數(shù)量的系統(tǒng)上并行使用。

2 氣象數(shù)據(jù)的處理

由于氣象行業(yè)的特殊性，氣象數(shù)據(jù)是實(shí)時(shí)收集傳輸?shù)?，除了一些非結(jié)構(gòu)化數(shù)據(jù)外，大多都是文本型數(shù)據(jù)，而且這些數(shù)據(jù)文件也都是有特點(diǎn)的，如數(shù)據(jù)類(lèi)型多、數(shù)據(jù)文件名遵循氣象數(shù)據(jù)命名規(guī)范、單個(gè)文本數(shù)據(jù)小但數(shù)據(jù)量大、數(shù)據(jù)訪(fǎng)問(wèn)主要是讀取等等。

Hadoop中理論上可以存儲(chǔ)各種大小的數(shù)據(jù)，但過(guò)小的數(shù)據(jù)會(huì)產(chǎn)生大量數(shù)據(jù)索引，這樣在數(shù)據(jù)處理中會(huì)增加極大的任務(wù)量，這對(duì)于數(shù)據(jù)處理是災(zāi)難性的。Hadoop的單個(gè)文件塊大小默認(rèn)是64 MB，而氣象數(shù)據(jù)單個(gè)數(shù)據(jù)文件大小大都只有幾十KB，將大量的氣象數(shù)據(jù)文件存儲(chǔ)于HDFS中，對(duì)HDFS的處理性能帶來(lái)挑戰(zhàn)。文中涉及到的數(shù)據(jù)是數(shù)量龐大的小文件數(shù)據(jù)，必須在部署Hadoop時(shí)進(jìn)行特別的配置及優(yōu)化。

文中采用HDFS自帶的方法Sequence File[16]對(duì)大量文本文件進(jìn)行合并存儲(chǔ)，Sequence File是一個(gè)由二進(jìn)制序列化過(guò)的key/value字節(jié)流組成的文本存儲(chǔ)文件。在使用中，Sequence File就像一個(gè)容器，可以把一堆小文件打包到Sequence File類(lèi)中，從而實(shí)現(xiàn)對(duì)小文件的高效存儲(chǔ)和處理。同時(shí)，Sequence File文件格式支持壓縮且操作難度低，這樣就可以較好地解決小文件處理問(wèn)題。壓縮分為記錄壓縮類(lèi)型和塊壓縮類(lèi)型，塊壓縮一次壓縮多個(gè)記錄，因此比記錄壓縮更緊湊，一般優(yōu)先選擇。文件布局如圖1所示。

圖1 Sequence File文件布局

如果單個(gè)Sequence File存儲(chǔ)大量的小文件，在處理過(guò)程中會(huì)出現(xiàn)效率低、速度慢等問(wèn)題，因而采用一次性并行地創(chuàng)建大量的Sequence File。在處理過(guò)程中，直接利用Sequence File本身提供的讀寫(xiě)等操作，將Sequence File作為Map處理文件的臨時(shí)輸出。

3 基于MapReduce的氣象大數(shù)據(jù)檢索及參數(shù)調(diào)優(yōu)

基于氣象數(shù)據(jù)主要操作為讀取的特點(diǎn)，在本節(jié)使用MapReduce算法對(duì)基于HDFS的小文件存儲(chǔ)進(jìn)行檢索實(shí)驗(yàn)，同時(shí)在實(shí)驗(yàn)過(guò)程中根據(jù)實(shí)驗(yàn)結(jié)果對(duì)MapReduce的參數(shù)配置進(jìn)行調(diào)優(yōu)。

實(shí)驗(yàn)軟件環(huán)境及集群節(jié)點(diǎn)配置如表1和表2所示。

表1 實(shí)驗(yàn)軟件環(huán)境

本次測(cè)試采用類(lèi)似TPC-H標(biāo)準(zhǔn)化查詢(xún)中的多重復(fù)雜查詢(xún)，查詢(xún)中包含分組、排序、聚集、子查詢(xún)等操作，通過(guò)Map-Side Join、調(diào)整reducer任務(wù)大小、中間壓縮、JVM重用、調(diào)整map和reduce數(shù)進(jìn)行檢索優(yōu)化。

表2 集群節(jié)點(diǎn)配置

3.1 Map-Side Join

執(zhí)行Map-Side Join可以把足夠小的表載入到內(nèi)存中，使Hadoop可以減少reduce進(jìn)程，能夠比將不太大的表分發(fā)到每個(gè)map task中會(huì)帶來(lái)更多的好處。實(shí)驗(yàn)結(jié)果如圖2所示。

圖2 Map-Side Join優(yōu)化結(jié)果對(duì)比

在多次執(zhí)行查詢(xún)結(jié)果分析中得出，Map-Side Join在本次查詢(xún)時(shí)優(yōu)化效果不明顯。效果不明顯的原因可能是由于氣象數(shù)據(jù)本身的數(shù)據(jù)集較小的緣故，即使在map時(shí)將小的表載入內(nèi)存，在reduce時(shí)也減少不了進(jìn)程，因而效果不明顯。

3.2 調(diào)整每一個(gè)reducer任務(wù)大小

通過(guò)設(shè)置reducer參數(shù)的大小來(lái)控制一個(gè)job會(huì)有多少個(gè)reducer來(lái)處理，依據(jù)的是輸入文件的總大小，默認(rèn)大小為256 MB。為尋找最佳值，分別設(shè)置不同值來(lái)統(tǒng)計(jì)各自執(zhí)行時(shí)間，結(jié)果如圖3所示。

圖3 調(diào)整reducer任務(wù)大小優(yōu)化結(jié)果對(duì)比

由圖3可知，每個(gè)reducer大小為2 GB左右時(shí)，執(zhí)行時(shí)間最少。經(jīng)多次實(shí)驗(yàn)得出，調(diào)整合適的reducer大小對(duì)查詢(xún)優(yōu)化較為明顯。

3.3 中間壓縮

更改參數(shù)對(duì)Hadoop輸出結(jié)果和中間結(jié)果進(jìn)行壓縮優(yōu)化，壓縮后與初始執(zhí)行時(shí)間對(duì)比如圖4所示。

由實(shí)驗(yàn)結(jié)果可以看出，啟用中間壓縮對(duì)執(zhí)行時(shí)間的影響不大。

圖4 中間壓縮優(yōu)化結(jié)果對(duì)比

3.4 JVM重用

Hadoop的默認(rèn)配置通常使用派生JVM來(lái)執(zhí)行map和reduce任務(wù)。此時(shí)JVM的啟動(dòng)過(guò)程可能會(huì)產(chǎn)生相當(dāng)大的開(kāi)銷(xiāo)，尤其是執(zhí)行的job包含有成百上千個(gè)task任務(wù)的情況。JVM重用可以使得JVM實(shí)例在同一個(gè)job中重新使用N次，設(shè)置JVM可重新使用10次之后，查詢(xún)執(zhí)行時(shí)間與初始執(zhí)行時(shí)間的對(duì)比時(shí)間如圖5所示。

圖5 JVM重用優(yōu)化結(jié)果對(duì)比

由實(shí)驗(yàn)結(jié)果可以看出，設(shè)置JVM重用對(duì)執(zhí)行時(shí)間的影響不大。

3.5 調(diào)整map和reduce數(shù)

在執(zhí)行查詢(xún)時(shí)，通常會(huì)將查詢(xún)劃分成一個(gè)或多個(gè)MapReduce任務(wù)達(dá)到并行的目的。每個(gè)任務(wù)都可能具有多個(gè)mapper或reducer任務(wù)。確定最佳的mapper和reducer個(gè)數(shù)取決于多個(gè)變量，例如輸入數(shù)據(jù)量大小以及對(duì)這些數(shù)據(jù)執(zhí)行的操作。其中map和reduce任務(wù)個(gè)數(shù)都是根據(jù)經(jīng)驗(yàn)值得來(lái)的，通過(guò)多次設(shè)置優(yōu)化后的執(zhí)行時(shí)間對(duì)比如圖6所示。

圖6 調(diào)整map和reduce個(gè)數(shù)的優(yōu)化對(duì)比

由實(shí)驗(yàn)結(jié)果可以看出，通過(guò)調(diào)整map和reduce個(gè)數(shù)可以將執(zhí)行效率提高15%左右。

4 結(jié)束語(yǔ)

將大數(shù)據(jù)處理技術(shù)應(yīng)用于氣象數(shù)據(jù)的處理會(huì)改變傳統(tǒng)處理氣象數(shù)據(jù)的方式和方法，對(duì)進(jìn)一步提高預(yù)報(bào)準(zhǔn)確率及改善氣象服務(wù)等都有著重要意義，也是國(guó)家信息化進(jìn)程中的一個(gè)重要組成部分。文中對(duì)云計(jì)算環(huán)境下氣象數(shù)據(jù)的應(yīng)用進(jìn)行了初步探索，在將來(lái)更具體的應(yīng)用中需要更多的嘗試以及調(diào)優(yōu)工作，以期更高效地運(yùn)用云計(jì)算技術(shù)對(duì)氣象大數(shù)據(jù)進(jìn)行處理，使氣象數(shù)據(jù)能夠更好地服務(wù)社會(huì)。