基于Map Reduce計(jì)算模型的氣象資料處理調(diào)優(yōu)試驗(yàn)

楊潤芝沈文海肖衛(wèi)青胡開喜楊 昕王 穎田 偉

1）（國家氣象信息中心，北京100081）2）（南京信息工程大學(xué)，南京210044）

基于Map Reduce計(jì)算模型的氣象資料處理調(diào)優(yōu)試驗(yàn)

楊潤芝1）*沈文海1）肖衛(wèi)青1）胡開喜1）楊 昕1）王 穎1）田 偉2）

1）（國家氣象信息中心，北京100081）2）（南京信息工程大學(xué)，南京210044）

云計(jì)算技術(shù)使用分布式的計(jì)算技術(shù)實(shí)現(xiàn)了并行計(jì)算的計(jì)算能力和計(jì)算效率，解決了單機(jī)服務(wù)器計(jì)算能力低的問題?；陂L序列歷史資料所計(jì)算得出的氣候標(biāo)準(zhǔn)值對于氣象領(lǐng)域?qū)崟r(shí)業(yè)務(wù)、準(zhǔn)實(shí)時(shí)業(yè)務(wù)及科學(xué)研究中均具有重要的意義。由于長序列歷史資料數(shù)據(jù)量大、運(yùn)算邏輯較復(fù)雜，在傳統(tǒng)單節(jié)點(diǎn)計(jì)算平臺上進(jìn)行整編計(jì)算耗時(shí)非常長。該文基于Hadoop分布式計(jì)算框架搭建了集群模式的云計(jì)算平臺，以長序列歷史資料作為源數(shù)據(jù)，基于Map Reduce計(jì)算模型實(shí)現(xiàn)了部分整編算法，提高計(jì)算時(shí)效。同時(shí)，由于數(shù)據(jù)源本身具有文件個(gè)數(shù)多、單個(gè)文件小等特點(diǎn)，對數(shù)據(jù)源存儲形式及數(shù)據(jù)文件大小進(jìn)行改造，分別利用SequenceFile方式及文本文件合并方式對同一種場景進(jìn)行計(jì)算時(shí)效對比測試，分別測試了10個(gè)文件合并、100個(gè)文件合并兩種情況，使時(shí)效性得到了更大程度的提升。

MapReduce；云計(jì)算；Hadoop；歷史資料整編

引 言

近年來，隨著云計(jì)算產(chǎn)業(yè)生態(tài)環(huán)境日益完善［1］，云平臺、云服務(wù)和云應(yīng)用不斷發(fā)展。云計(jì)算的核心思想、技術(shù)及其應(yīng)用得到了很多領(lǐng)域和研究機(jī)構(gòu)的重視。我國也迫切需要掌握和發(fā)展云計(jì)算的核心技術(shù)，推動云計(jì)算的應(yīng)用［2］，其靈活性、易用性、穩(wěn)定性等已經(jīng)逐漸被人們所肯定。氣象業(yè)務(wù)具有專業(yè)化程度高，分支機(jī)構(gòu)覆蓋分布廣、影響范圍大、數(shù)據(jù)種類多、數(shù)據(jù)總量大、實(shí)時(shí)性要求強(qiáng)等特點(diǎn)。多年來，氣象部門已經(jīng)形成了一套相對比較完善和獨(dú)立的業(yè)務(wù)體系。在氣象領(lǐng)域現(xiàn)有的計(jì)算模型中，運(yùn)算量大的模式運(yùn)算多借助高性能服務(wù)器完成，而運(yùn)算量較小或者實(shí)時(shí)性要求不高的業(yè)務(wù)或科研運(yùn)算仍在單機(jī)上完成。基于云平臺或Map Reduce計(jì)算模型開發(fā)的科學(xué)計(jì)算比較少，但隨著云計(jì)算的日臻成熟，氣象部門已經(jīng)逐漸意識到依靠云計(jì)算平臺和Map Reduce分布式計(jì)算模型解決目前業(yè)務(wù)和科研中的一些時(shí)效問題，并進(jìn)行了一些嘗試性的探索試驗(yàn)。Nebula項(xiàng)目是NASA的一個(gè)開源的云計(jì)算項(xiàng)目［3］，Nebula可以隨時(shí)為NASA科學(xué)家和工程師提供所需的數(shù)據(jù)處理計(jì)算資源，從而替代了需要額外建造數(shù)據(jù)中心所帶來的昂貴代價(jià)。同時(shí)Nebula還為NASA的科學(xué)家和研究人員提供了一條簡化的向外部合作伙伴和公眾共享大而復(fù)雜的數(shù)據(jù)集的途徑。中國氣象局熱帶海洋氣象研究所通過與深圳云計(jì)算中心的合作，可以進(jìn)行高分辨模式實(shí)時(shí)運(yùn)行，實(shí)現(xiàn)我國華南區(qū)域公里級模式快速滾動且高頻次運(yùn)行，生成精細(xì)預(yù)報(bào)產(chǎn)品，為華南地區(qū)精細(xì)預(yù)報(bào)、風(fēng)能預(yù)報(bào)和強(qiáng)對流預(yù)報(bào)等提供支撐，并且有望更好地捕捉到颮線、雷雨大風(fēng)等天氣尺度小于6 km的強(qiáng)對流過程，對提高數(shù)值預(yù)報(bào)水平將帶來很大幫助［4］。據(jù)不完全統(tǒng)計(jì)，以目前中國氣象局各直屬業(yè)務(wù)單位在國家氣象信息中心托管的各業(yè)務(wù)系統(tǒng)為例，其基礎(chǔ)設(shè)施中的服務(wù)器（包括CPU、內(nèi)存等）的平均使用率低于30%［5］。以先進(jìn)的設(shè)計(jì)理念、有效的組織形式和技術(shù)手段，盡可能提高氣象部門工作效率和效益，在當(dāng)前具有很好的研究意義［6］。

1 業(yè)務(wù)現(xiàn)狀

1.1 氣候資料整編

長序列歷史資料在氣象預(yù)報(bào)預(yù)測、氣候研究、歷史資料分析統(tǒng)計(jì)、模式預(yù)報(bào)中的使用越來越廣泛。地面氣候30年整編資料作為重要?dú)夂蛸Y料的一種，已在很多天氣、氣候、模式計(jì)算等方面使用［7-10］。我國到目前為止已完成了4次大規(guī)模氣候資料整編工作，分別為1951—1980年、1961—1990年、1971—2000年、1981—2010年。

按照1981—2010年氣候資料統(tǒng)計(jì)整編工作要求，所有統(tǒng)計(jì)項(xiàng)目及統(tǒng)計(jì)方法應(yīng)支持任意年段（含建站—指定年）的統(tǒng)計(jì)處理，從而為各級氣象部門提供日常氣候資料服務(wù)、氣候可行性論證等所需要的任意年氣候資料統(tǒng)計(jì)加工產(chǎn)品。這對長序列氣候資料整編工作所依托系統(tǒng)的可擴(kuò)展性、靈活性、時(shí)效性提出了更高的要求。目前氣候資料整編軟件運(yùn)行于Windows環(huán)境，由于運(yùn)算數(shù)據(jù)總量大、算法邏輯較復(fù)雜，所以完成一次整編運(yùn)算耗時(shí)較長。當(dāng)運(yùn)算過程中發(fā)現(xiàn)疑誤數(shù)據(jù)時(shí)，需人工對疑誤數(shù)據(jù)進(jìn)行修改或參數(shù)調(diào)整，然后重新計(jì)算，因此總體累計(jì)計(jì)算耗時(shí)甚長，導(dǎo)致整編工作往往因計(jì)算耗時(shí)而時(shí)間延宕。傳統(tǒng)的串行計(jì)算方法難以從根本上解決運(yùn)算時(shí)效問題，經(jīng)過詳細(xì)分析，決定采用云計(jì)算技術(shù)Map Reduce，Hadoop等方法，對整編統(tǒng)計(jì)算法進(jìn)行并行化處理，以提高運(yùn)算時(shí)效。

1.2 云計(jì)算架構(gòu)

1.2.1 任務(wù)調(diào)度模式

Map Reduce是Google云計(jì)算平臺中的編程模型，是實(shí)現(xiàn)云計(jì)算的核心技術(shù)之一。Map Reduce計(jì)算框架是一個(gè)主-從模型的架構(gòu)。它包括一個(gè)主節(jié)點(diǎn)（Job Tracker）和若干從節(jié)點(diǎn)（Task Tracker）。在集群模式下，集群中每個(gè)節(jié)點(diǎn)都有一個(gè)Task Tracker［11-12］。

圖1是云平臺任務(wù)調(diào)度模式。用戶將計(jì)算任務(wù)提交到Job Tracker，然后由Job Tracker負(fù)責(zé)將任務(wù)添加到待執(zhí)行任務(wù)隊(duì)列中，任務(wù)執(zhí)行順序遵從先到先服務(wù)原則。Job Tracker負(fù)責(zé)將Map和Reduce的任務(wù)分配到不同的Ttask Tracker上，Task Tracker按照J(rèn)ob-Tracker的指令執(zhí)行任務(wù)并處理Map階段到Reduce階段的數(shù)據(jù)轉(zhuǎn)移［13］。

圖1 云平臺任務(wù)調(diào)度模式Fig.1 Task scheduling model on cloud computing platform

1.2.2 Map Reduce特點(diǎn)和運(yùn)算流程

Map Reduce模型本身源自于函數(shù)式語言［14］，主要通過Map-映射和Reduce-化簡這兩個(gè)步驟并行處理大規(guī)模的數(shù)據(jù)集?；贛ap Reduce分布式處理框架，不僅能用于處理大規(guī)模數(shù)據(jù)，而且能將很多繁瑣的細(xì)節(jié)隱藏起來，如自動并行化、負(fù)載均衡和災(zāi)備管理等，這樣將在很大程度上簡化代碼開發(fā)工作；同時(shí)，Map Reduce具有較好的伸縮性，可以很好地適應(yīng)平臺中節(jié)點(diǎn)的變化。Map Reduce的不足則在于，它對于適應(yīng)實(shí)時(shí)應(yīng)用的需求方面，還不是十分完善，所以在Google最新的實(shí)時(shí)性很強(qiáng)的Caffeine搜索引擎中，己經(jīng)采用實(shí)時(shí)處理Percolator系統(tǒng)所代替?zhèn)鹘y(tǒng)的 Map Reduce［15］。

在User program中實(shí)現(xiàn)了Map phase和Reduce phase。Map Reduce運(yùn)算流程一般分為以下幾個(gè)過 程［16］：① Map Reduce 首 先 根據(jù) 用 戶 對 Inputsplit的定義將輸入數(shù)據(jù)進(jìn)行劃分，然后使用fork將用戶進(jìn)程拷貝到集群內(nèi)其他機(jī)器上。②Master根據(jù)每個(gè)Worker的空閑程度及配置的Worker個(gè)數(shù)將任務(wù)進(jìn)行分配。③被分配到任務(wù)的Worker開始讀取對應(yīng)分片的輸入數(shù)據(jù)，Map作業(yè)從輸入數(shù)據(jù)中抽取出鍵值對，每一個(gè)鍵值對都作為參數(shù)傳遞給Map函數(shù)。④Map根據(jù)用戶定義的進(jìn)程進(jìn)行運(yùn)算，并將運(yùn)算結(jié)果存儲到Intermediate file中，同時(shí)告知Master。⑤Reduce Worker讀取所有中間鍵值對，對其進(jìn)行排序，將相同鍵的鍵值對聚集在一起，并完成Reduce函數(shù)運(yùn)算，輸出最終計(jì)算結(jié)果。

圖2 Map Reduce運(yùn)算流程Fig.2 Map Reduce computation processes

1.2.3 Hadoop分布式計(jì)算框架

Hadoop是Apache開源組織開發(fā)的一個(gè)分布式計(jì)算框架，其中HDFS（Hadoop Distributed File System）和Map Reduce分別是對Google File System（GFS）和Google Map Reduce的開源實(shí)現(xiàn)。Yahooo，F(xiàn)acebook，Amazon大型社交與商務(wù)類網(wǎng)站等均部署在Hadoop上，以管理基于大數(shù)據(jù)量的應(yīng)用。作為一個(gè)分布式系統(tǒng)平臺，Hadoop具有以下一些優(yōu)勢［17］：①可擴(kuò)展，Hadoop可以可靠地存儲和處理PB級別的數(shù)據(jù)。②經(jīng)濟(jì)，Hadoop將數(shù)據(jù)分布到由廉價(jià)PC機(jī)組成的集群中進(jìn)行處理，這些集群可以由成千上萬個(gè)節(jié)點(diǎn)組成。③有效，通過數(shù)據(jù)分發(fā)，Hadoop可以在不同的節(jié)點(diǎn)并行處理數(shù)據(jù)。這使得數(shù)據(jù)處理過程大大提速。④可靠，Hadoop自動維護(hù)一份數(shù)據(jù)的多個(gè)拷貝并自動將失敗的計(jì)算任務(wù)進(jìn)行重新部署。

本文所做的研究和試驗(yàn)均基于Hadoop搭建分布式的計(jì)算環(huán)境而開展。

2 歷史資料整編設(shè)計(jì)架構(gòu)

2.1 傳統(tǒng)統(tǒng)計(jì)項(xiàng)目計(jì)算流程

傳統(tǒng)整編軟件中計(jì)算統(tǒng)計(jì)項(xiàng)目的基本流程如圖3所示。以30年累年日平均氣溫算法為例，采用單進(jìn)程順序執(zhí)行策略，主要步驟如下：①主程序依次順序讀取用戶指定的文件夾（目錄）下的每個(gè)A文件。當(dāng)計(jì)算30年累年日平均氣溫時(shí)，需要依次順序讀取360（30×12）個(gè)A文件，解析每個(gè)A文件中每日4次或24次氣溫值，并根據(jù)相應(yīng)的統(tǒng)計(jì)算法計(jì)算日平均氣溫。②將日平均氣溫值以數(shù)組或記錄方式存儲在表或文件中；每個(gè)A文件需要記錄該月中每日平均氣溫值。③當(dāng)所有30年所包含的A文件均處理完成后，主進(jìn)程對所有記錄的數(shù)據(jù)表或文件值中含有相同月日（366個(gè)值）的氣溫值進(jìn)行累加，累加結(jié)果除以日數(shù)。

通過分析可以發(fā)現(xiàn)，主程序需要單進(jìn)程處理所有30年的數(shù)據(jù)文件，并且需要創(chuàng)建大小為10950（365×30）的數(shù)組或記錄表，并對數(shù)組或記錄表按照相同月日的條件進(jìn)行累加。

圖3 傳統(tǒng)整編軟件計(jì)算流程Fig.3 Calculation flow chart of traditional software

2.2 云平臺軟件架構(gòu)

Map Reduce計(jì)算模型的數(shù)據(jù)流圖如圖4所示，Job Tracter啟動一個(gè)任務(wù)后，根據(jù)用戶定義的InputSplit和Input FormatClass解析HDFS上對應(yīng)目錄下的數(shù)據(jù)文件，根據(jù)匹配的數(shù)據(jù)輸入源分配Map任務(wù)。

每個(gè) Map將處理結(jié)果輸出為（Key，Value）鍵值對，Barrier將所有輸出的鍵值對進(jìn)行排序，將Key值相同的結(jié)果進(jìn)行合并。Job Trackter根據(jù)鍵值對結(jié)果啟動Reduce，最終生成用戶需要的Final Key和Value。

歷史資料整編的數(shù)據(jù)源為A文件，所以本文首先按照A文件的格式重寫Hadoop中的FileInput-Format；以計(jì)算日平均氣溫為例，在任務(wù)分配時(shí)，根據(jù)FileInputFormat識別數(shù)據(jù)輸入為360個(gè)A文件并創(chuàng)建Map任務(wù)。每個(gè)Map任務(wù)讀取一個(gè)文件并進(jìn)行解析，根據(jù)日平均值算法計(jì)算出歷年逐日日平均氣溫，并將結(jié)果以（月.日，日平均氣溫）的格式進(jìn)行輸出。Barrier將所有Key值相同的結(jié)果進(jìn)行合并，即可得到30年中每個(gè)月和日均相同的日平均氣溫。Reduce將該月、日的所有輸入結(jié)果進(jìn)行計(jì)算，最終得出日平均氣溫（圖5）。

圖4 MapReduce計(jì)算模型數(shù)據(jù)流Fig.4 Data flow diagram of MapReduce computation model

圖5 云平臺上整編計(jì)算流程Fig.5 Reorganization flowchart on cloud computing platforms

2.3 方法優(yōu)化前后對比

與傳統(tǒng)的計(jì)算方法相比，基于Map Reduce模型編寫整編算法的優(yōu)越性主要體現(xiàn)在以下幾個(gè)方面：①M(fèi)ap Reduce計(jì)算模型是分布式的，它充分利用了多個(gè)節(jié)點(diǎn)的計(jì)算能力和I／O帶寬，將原本集中在一臺單機(jī)上依靠順序運(yùn)行的算法改為可以并行運(yùn)行，使得在較短時(shí)間內(nèi)最大程度利用了現(xiàn)有空閑資源。②Map和Reduce之間的中間結(jié)果不需要程序干預(yù)。平臺本身利用Barrier層會將所有Map輸出的結(jié)果進(jìn)行處理，省去用戶程序中對大量中間結(jié)果的存儲和處理，簡化用戶程序邏輯。③Map Reduce計(jì)算模型下任務(wù)運(yùn)行更靈活。由于計(jì)算任務(wù)本身無需對數(shù)據(jù)源范圍進(jìn)行框定，所以可在不修改任務(wù)界面和程序的情況下，完成對不同時(shí)間段歷史資料整編值的計(jì)算。

3 測試方案與性能優(yōu)化

3.1 測試目的、環(huán)境、數(shù)據(jù)與方案

3.1.1 測試目的

為驗(yàn)證分析Map Reduce計(jì)算模型在處理較大規(guī)模氣象數(shù)據(jù)計(jì)算中對計(jì)算時(shí)效提升的特點(diǎn)，本文以氣象領(lǐng)域長序列歷史資料整編過程的統(tǒng)計(jì)運(yùn)算為測試本體，設(shè)計(jì)了一整套測試方案，包括云平臺集群構(gòu)成、系統(tǒng)環(huán)境參數(shù)、并行任務(wù)、數(shù)據(jù)自身存儲結(jié)構(gòu)等。期望通過測試，可與傳統(tǒng)計(jì)算模式的計(jì)算時(shí)效進(jìn)行對比，同時(shí)通過修改平臺本身各項(xiàng)參數(shù)配置以及測試數(shù)據(jù)存儲形式，分析云計(jì)算平臺中影響Map Reduce計(jì)算模型運(yùn)算時(shí)效的各種因子，從而更好地理解Map Reduce計(jì)算模型與氣象數(shù)據(jù)科學(xué)計(jì)算的特點(diǎn)，為后續(xù)的通用常規(guī)科學(xué)計(jì)算向云平臺上的轉(zhuǎn)化提供參考。

3.1.2 測試環(huán)境

因當(dāng)時(shí)尚無成型的云計(jì)算平臺，筆者利用閑散資源，搭建了一個(gè)由5臺服務(wù)器組成的實(shí)體機(jī)云平臺；同時(shí)為了測試Map Reduce計(jì)算模型在虛擬機(jī)上的運(yùn)行效果，筆者在VMware虛擬環(huán)境中申請了10臺虛擬主機(jī)。下文所述的所有試驗(yàn)和測試，均基于這兩個(gè)小型云計(jì)算機(jī)平臺上展開，5臺實(shí)體機(jī)配置見表1。

10個(gè)虛擬主機(jī)均部署在同一臺實(shí)體主機(jī)上，共享計(jì)算和存儲I／O，每個(gè)虛擬主機(jī)配置相同，操作系統(tǒng)為SUSE11（x86_64），CPU 核數(shù)為1，內(nèi)存為4 GB。

表1 實(shí)體機(jī)云平臺中各主機(jī)配置表Table 1 Configuration of host machine on physical cloud platform

3.1.3 試驗(yàn)數(shù)據(jù)與測試方案

所有試驗(yàn)數(shù)據(jù)均來自1951—2010年245個(gè)氣象觀測站A文件，試驗(yàn)數(shù)據(jù)文件總數(shù)為152758個(gè)，數(shù)據(jù)總量為3350 MB，單個(gè)文件大小為5～200 KB，平均每個(gè)文件大小為22 KB。

每組試驗(yàn)進(jìn)行兩次，取兩次試驗(yàn)結(jié)果的平均值作為該組試驗(yàn)的最終結(jié)果。試驗(yàn)從以下幾個(gè)方面分別進(jìn)行：①在其他配置不變的情況下，測試云平臺隨節(jié)點(diǎn)數(shù)變化對計(jì)算時(shí)效的影響；②在其他配置不變的情況下，測試云平臺環(huán)境參數(shù)變化對計(jì)算時(shí)效的影響；③在其他配置不變的情況下，測試云平臺隨總體并行任務(wù)數(shù)變化對計(jì)算時(shí)效的影響；④在其他配置不變的情況下，測試數(shù)據(jù)本身存儲結(jié)構(gòu)及數(shù)據(jù)大小等方面對計(jì)算時(shí)效的影響；⑤比較和分析傳統(tǒng)計(jì)算模型與Map Reduce模型的計(jì)算時(shí)效量級。

因?yàn)閭鹘y(tǒng)整編軟件只能在Windows系統(tǒng)環(huán)境下運(yùn)行，而Map Reduce運(yùn)行在Linux系統(tǒng)環(huán)境下，所以很難在相同的系統(tǒng)環(huán)境下與傳統(tǒng)計(jì)算模式進(jìn)行時(shí)效性比較。為此采用變通方案，由于當(dāng)實(shí)體機(jī)云平臺中只配置1個(gè)計(jì)算節(jié)點(diǎn)時(shí)，所有計(jì)算都由該計(jì)算節(jié)點(diǎn)完成，因此設(shè)定1個(gè)計(jì)算節(jié)點(diǎn)的計(jì)算效果為傳統(tǒng)整編軟件單機(jī)環(huán)境的模擬效果。

3.2 試驗(yàn)結(jié)果

3.2.1 時(shí)效隨計(jì)算節(jié)點(diǎn)變化測試

測試主要考察在數(shù)據(jù)量、計(jì)算量以及其他系統(tǒng)配置不變的情況下，通過改變平臺計(jì)算節(jié)點(diǎn)數(shù)而引起的計(jì)算時(shí)效的變化。

計(jì)算全過程為1個(gè)臺站日平均氣溫的計(jì)算，過程中需要順序讀取該站30年中每月的A文件并進(jìn)行讀取、計(jì)算、中間結(jié)果存儲、合并匯總等。

單節(jié)點(diǎn)總耗時(shí)為966 s。此后，分別在云平臺配置了3，4，5個(gè)計(jì)算節(jié)點(diǎn)，并進(jìn)行同樣的計(jì)算過程，3個(gè)計(jì)算節(jié)點(diǎn)總耗時(shí)為245 s，5個(gè)計(jì)算節(jié)點(diǎn)總耗時(shí)為124 s。結(jié)果見圖6。

圖6 時(shí)間隨計(jì)算節(jié)點(diǎn)數(shù)變化的測試Fig.6 Experiment on time change with node numbers

由圖6可看出，隨著平臺中計(jì)算節(jié)點(diǎn)數(shù)的增加，同一任務(wù)的完成墻鐘時(shí)間隨之降低。但隨著節(jié)點(diǎn)數(shù)的增加，墻鐘時(shí)間與節(jié)點(diǎn)的的斜率絕對值呈逐漸降低態(tài)勢，這說明在計(jì)算節(jié)點(diǎn)數(shù)增加的同時(shí)，節(jié)點(diǎn)間通信、數(shù)據(jù)傳輸?shù)臅r(shí)間成本也會相應(yīng)增加，并抵消由于Map計(jì)算所節(jié)省的時(shí)間成本。

在配置5個(gè)計(jì)算節(jié)點(diǎn)的情況下，計(jì)算245個(gè)站日平均氣溫，總耗時(shí)25380 s。

3.2.2 時(shí)效隨云平臺系統(tǒng)參數(shù)變化測試

測試主要考察在數(shù)據(jù)量、計(jì)算量及其他系統(tǒng)配置不變的情況下，通過改變每個(gè)計(jì)算節(jié)點(diǎn)的Map Slot而引起的計(jì)算時(shí)效的變化。

在虛擬云平臺中，共進(jìn)行了3組試驗(yàn)，每組試驗(yàn)選取的節(jié)點(diǎn)數(shù)分別為6個(gè)、8個(gè)和10個(gè)。在每組測試中，通過調(diào)整 MAPRED.TASKTRACKER.MAP.TASKS.MAXIMUM參數(shù)來修改平臺中最大并行任務(wù)數(shù)。試驗(yàn)數(shù)據(jù)選取10個(gè)臺站整編數(shù)據(jù)，共計(jì)6476個(gè)文件，數(shù)據(jù)總大小為155 MB。

試驗(yàn)中，Map Slot從2逐漸增大到20。由圖7可知，無論多少節(jié)點(diǎn)，3條曲線所對應(yīng)的計(jì)算時(shí)間都會隨Map Slot的增加呈先逐漸減少后逐漸增大的趨勢；在計(jì)算節(jié)點(diǎn)數(shù)不變的情況下，計(jì)算時(shí)間與Map Slot之間并不是單一線性關(guān)系；當(dāng)Map Slot配置固定時(shí)，計(jì)算時(shí)間隨節(jié)點(diǎn)數(shù)的增加而降低；Map Slot為16時(shí)，10節(jié)點(diǎn)和8節(jié)點(diǎn)的兩種配置下的計(jì)算時(shí)效達(dá)到整個(gè)平臺的最優(yōu)，Map Slot為18時(shí)，6節(jié)點(diǎn)下的計(jì)算時(shí)效達(dá)到整個(gè)平臺的最優(yōu)；Map Slot從16～18增加到18～20時(shí)，整個(gè)平臺的計(jì)算時(shí)間反而升高。

圖7 時(shí)間隨云平臺系統(tǒng)參數(shù)變化的測試Fig.7 Experiment on time change with system parameters of cloud computing platform

3.2.3 時(shí)效隨數(shù)據(jù)存儲結(jié)構(gòu)和數(shù)據(jù)大小變化測試

測試主要考察當(dāng)數(shù)據(jù)總量、統(tǒng)計(jì)方案（計(jì)算量）以及其他配置不變的情況下，通過改變整編數(shù)據(jù)本身的存儲結(jié)構(gòu)以及數(shù)據(jù)文件大小而引起的計(jì)算時(shí)效的變化。

在虛擬云平臺中，共進(jìn)行了4組試驗(yàn)，除第1組試驗(yàn)使用原始整編文件外，其余3組試驗(yàn)都對整編文件進(jìn)行了改造。在第2組試驗(yàn)中，將原始的整編文件通過純文本合并方式將每10個(gè)文件合并為1個(gè)大文件；在第3組試驗(yàn)中，將原始的整編文件通過純文本合并方式將每100個(gè)文件合并為1個(gè)大文件；在第4組試驗(yàn)中，將全部152758個(gè)文件采用SequenceFile方式合并為1個(gè)文件（SequenceFile方式是Hadoop用來存儲二進(jìn)制形式的Key-Value對而設(shè)計(jì)的一種平面文件格式）。本文將245個(gè)站（152758個(gè)文件）以SequenceFile方式合并，合并后文件總量3454.6 MB。

表2中，在平臺計(jì)算節(jié)點(diǎn)數(shù)相同的情況下，10個(gè)文件合并方式的計(jì)算時(shí)間大概縮短為原始文件方式的1／10左右；100個(gè)文件合并方式的計(jì)算時(shí)間縮短為原始文件方式的1／70左右，而所有文件合并成1個(gè)SequenceFile方式的計(jì)算時(shí)間則平均約為原始文件方式的1／200左右。Hadoop任務(wù)在運(yùn)行時(shí)間主要由幾個(gè)部分組成，即任務(wù)初始化時(shí)間和尋址時(shí)間、數(shù)據(jù)拷貝時(shí)間、程序執(zhí)行時(shí)間、結(jié)果合并和輸出時(shí)間等。如果分配的任務(wù)數(shù)量多，每個(gè)任務(wù)本身計(jì)算量不大，造成任務(wù)初始化時(shí)間和尋址時(shí)間占整體運(yùn)行時(shí)間的比例過大，就會降低整體任務(wù)的運(yùn)行效率；通過將大量的小任務(wù)合并為較大的任務(wù)后，減少了任務(wù)數(shù)，降低了任務(wù)初始化時(shí)間和尋址時(shí)間的比例，大大提高任務(wù)執(zhí)行的效率。

在每組試驗(yàn)中，云平臺節(jié)點(diǎn)分別從5逐漸增大到10。由表2和圖8可以看出，3種方式在相同的環(huán)境下，計(jì)算時(shí)效均有了很大的提升；當(dāng)節(jié)點(diǎn)數(shù)配置不變時(shí)，計(jì)算時(shí)間從高到低的分別為原始文件、10個(gè)文件合并、100個(gè)文件合并、SequenceFile方式。

圖8a縱坐標(biāo)是等間距的時(shí)間軸，可以看出，當(dāng)存儲結(jié)構(gòu)變化后對處理性能的提升是非常明顯的；圖8b縱坐標(biāo)為指數(shù)坐標(biāo)，可以較清楚地看到每種存儲結(jié)構(gòu)下，隨著節(jié)點(diǎn)數(shù)不同，運(yùn)行時(shí)間也發(fā)生變化。

表2 不同存儲結(jié)構(gòu)及數(shù)據(jù)文件大小試驗(yàn)結(jié)果（單位：s）Table 2 Experiment results of different storage structures and data file size（unit：s）

圖8 時(shí)間隨云平臺最大并行任務(wù)數(shù)變化的測試（a）均勻縱坐標(biāo)，（b）指數(shù)縱坐標(biāo)Fig.8 Experiment on time change with max parallel tasks of cloud computing platform（a）uniform ordinate，（b）index ordinate

3.2.4 文件上傳到HDFS文件系統(tǒng)的時(shí)效測試

在以上幾組試驗(yàn)中，假設(shè)和前提條件是數(shù)據(jù)文件已存儲在HDFS系統(tǒng)中，所進(jìn)行分析和測試的只包括Map Reduce計(jì)算模型和任務(wù)的計(jì)算時(shí)間。除上述3組測試之外，本研究在數(shù)據(jù)總量不變的情況下，文件個(gè)數(shù)和體積大小對上傳到HDFS分布式文件系統(tǒng)的時(shí)間影響情況進(jìn)行了1組測試。

試驗(yàn)文件在未做任務(wù)合并的情況下，文件總量為152758，上傳時(shí)間為19840 s；當(dāng)文件采用10個(gè)文件合并策略合并后，文件減少為15401個(gè)，上傳時(shí)間減少為3218 s；當(dāng)文件減少為21個(gè)時(shí)，上傳時(shí)間減少為945 s（圖9）。

由圖9可以看出，在文件容量不變的情況下，當(dāng)文件拆分得越小，上傳文件到HDFS系統(tǒng)上的總體時(shí)間越長。

此外，隨著文件數(shù)量的逐漸減少，文件上傳到HDFS系統(tǒng)的時(shí)間優(yōu)化趨勢也逐漸減弱，趨于平緩。

圖9 文件上傳到HDFS文件系統(tǒng)的時(shí)效測試Fig.9 Experiment on time change with upload files to HDFS

3.3 結(jié)果分析

綜合以上所進(jìn)行的多組試驗(yàn)可以看出，云計(jì)算平臺的計(jì)算能力和運(yùn)行時(shí)效與云平臺集群構(gòu)成、系統(tǒng)環(huán)境參數(shù)、并行任務(wù)、數(shù)據(jù)自身存儲結(jié)構(gòu)以及服務(wù)器性能、最大并行任務(wù)數(shù)、單個(gè)任務(wù)計(jì)算量、平臺穩(wěn)定性等諸多因素有關(guān)，在其他參數(shù)不變的情況下，任意兩參數(shù)之間也并不是簡單的線性關(guān)系。

Hadoop在任務(wù)調(diào)度時(shí)，任務(wù)初始化時(shí)間和尋址時(shí)間在任務(wù)整體運(yùn)行時(shí)間的比例是決定任務(wù)時(shí)效能否提高的重要標(biāo)準(zhǔn)。由于基于傳統(tǒng)小文件方式運(yùn)行的任務(wù)初始化時(shí)間和尋址時(shí)間占總體任務(wù)的很大一部分，所以可優(yōu)化空間較大。

由于單個(gè)A文件大小均在200 KB以下，且整編統(tǒng)計(jì)算法計(jì)算量相對較小，導(dǎo)致實(shí)際計(jì)算時(shí)間占整個(gè)任務(wù)執(zhí)行時(shí)間比例很小，所以將大量A文件以文本方式進(jìn)行合并，在文件總量不變的前提下，測試合并前與合并后的運(yùn)算時(shí)效差別非常明顯。采用SequenceFile方式大大減少了任務(wù)數(shù)量，使任務(wù)初始化時(shí)間和尋址時(shí)間占總體任務(wù)的比例大幅降低，任務(wù)整體運(yùn)行時(shí)效得到了很大的提升。

當(dāng)實(shí)體機(jī)和虛擬機(jī)個(gè)數(shù)均為5臺時(shí)，在計(jì)算245個(gè)臺站30年日平均氣溫，實(shí)體機(jī)需要25380 s，而虛擬機(jī)在最高配置下需要36720 s，計(jì)算時(shí)間為實(shí)體機(jī)環(huán)境的147%。試驗(yàn)結(jié)果說明在計(jì)算任務(wù)相同時(shí)，實(shí)體機(jī)環(huán)境的效率優(yōu)于虛擬機(jī)環(huán)境。

4 小 結(jié)

本文基于Hadoop搭建了集群模式的云計(jì)算平臺，并以長序列歷史資料統(tǒng)計(jì)整編為例，在云計(jì)算平臺上基于Map Reduce計(jì)算模型進(jìn)行了多種統(tǒng)計(jì)項(xiàng)目、統(tǒng)計(jì)方法的算法實(shí)現(xiàn)，并在Hadoop平臺上進(jìn)行運(yùn)行測試。制定了較完備的測試計(jì)劃和測試方案，通過修改Hadoop集群環(huán)境的節(jié)點(diǎn)數(shù)、任務(wù)數(shù)等參數(shù)，分組進(jìn)行運(yùn)行效率的對比測試。根據(jù)測試結(jié)果以及對數(shù)據(jù)源特征的分析，對數(shù)據(jù)源存儲格式進(jìn)行多種方式修改和處理，一方面利用SequenceFile將＜Key，Value＞對序列化到文件中，將大量小容量的源文件合并為1個(gè)相對較大的文件，在同一場景的測試計(jì)算中處理效率得到了顯著提升；另一方面試驗(yàn)了多種不同的粒度將大量小文件進(jìn)行純文本合并的方式，將合并后文件作為處理對象，對同一種場景進(jìn)行計(jì)算時(shí)效對比測試，且分別在不同節(jié)點(diǎn)的環(huán)境下測試了10個(gè)文件合并、100個(gè)文件合并兩種情況，使時(shí)效性得到了較大程度的提升。

氣象領(lǐng)域的很多科學(xué)計(jì)算都具有數(shù)據(jù)量龐大、計(jì)算復(fù)雜、時(shí)效性要求高等特點(diǎn)，因此對計(jì)算資源的需求較高［18-19］。云平臺的適當(dāng)應(yīng)用能解決現(xiàn)有氣象業(yè)務(wù)中一部分科學(xué)計(jì)算任務(wù)面臨的問題，所以探索和開展基于云計(jì)算平臺的通用大數(shù)據(jù)量科學(xué)計(jì)算的適用性和可行性是有意義的。

在后續(xù)的研究與應(yīng)用工作中，將進(jìn)一步關(guān)注根據(jù)NP理論分析數(shù)據(jù)源、運(yùn)算量、資源消耗量等特征，分析各種物理量和參數(shù)對云平臺計(jì)算時(shí)效的影響因子，得到量化指標(biāo)，繼續(xù)開展不同的應(yīng)用場景下更多氣象資料處理算法及模塊在Hadoop平臺上的實(shí)現(xiàn)和移植試驗(yàn)。

致 謝：本項(xiàng)工作在分析、構(gòu)思、設(shè)計(jì)、實(shí)施及總結(jié)等各階段得到了國家氣象信息中心趙立成、熊安元、肖文名、林潤生、馬強(qiáng)等專家的指點(diǎn)，在此深表謝意。

［1］ 郎為民，楊德鵬，李虎生.中國云計(jì)算發(fā)展現(xiàn)狀研究.電信快報(bào)，2011，10：1-6.

［2］ 李德毅.2011云計(jì)算技術(shù)發(fā)展報(bào)告.北京：科學(xué)出版社，2011，5：1-10.

［3］ Ray O’Brien.［2011-12-11］.http：∥nebula.nasa.gov／blog／2012／05／29／nasa-and-openstack-2012／.

［4］ 張誠忠.廣東借助云計(jì)算破預(yù)報(bào)瓶頸天氣分辨率升至3公里.［2011-12-11］.http：∥news.xinhuanet.com／2011-12／11／c_111234079.htm.

［5］ 沈文海.從云計(jì)算看氣象部門未來的信息化趨勢.氣象科技進(jìn)展，2012，1（2）：49-56.

［6］ 沈文海.云計(jì)算受困于服務(wù)手段的有限和體制兩因素.［2012-12-15］.http：∥cio.itxinwen.com／Online／2011／1115／370736.html.

［7］ 劉小寧，張洪政，李慶祥.不同方法計(jì)算的氣溫平均值差異分析.應(yīng)用氣象學(xué)報(bào)，2005，16（3）：345-356.

［8］ 王炳忠，申彥波.我國上空的水汽含量及其氣候?qū)W估算.應(yīng)用氣象學(xué)報(bào)，2012，23（6）：763-768.

［9］ 張強(qiáng)，熊安元，張金艷，等.晴雨（雪）和氣溫預(yù)報(bào)評分方法的初步研究.應(yīng)用氣象學(xué)報(bào)，2009，20（6）：692-698.

［10］ 張順謙，馬振峰，張玉芳.四川省潛在蒸散量估算模型.應(yīng)用氣象學(xué)報(bào)，2009，20（6）：729-736.

［11］ 劉娜.基于MapReduce的數(shù)據(jù)挖掘算法在全國人口系統(tǒng)中的應(yīng)用.北京：首都經(jīng)濟(jì)貿(mào)易大學(xué)，2011：20-43.

［12］ 李軍華.云計(jì)算及若干數(shù)據(jù)挖掘算法的 MapReduce化研究.成都：電子科技大學(xué)，2010：19-32.

［13］ 賈雄.數(shù)值天氣預(yù)報(bào)云計(jì)算環(huán)境關(guān)鍵技術(shù)研究與實(shí)現(xiàn).長沙：國防科學(xué)技術(shù)大學(xué)，2011：2-33.

［14］ 萬至臻.基于 MapReduce模型的并行計(jì)算平臺的設(shè)計(jì)與實(shí)現(xiàn).杭州：浙江大學(xué)，2008：17-21.

［15］ 朱珠.基于Hadoop的海量數(shù)據(jù)處理模型研究和應(yīng)用.北京：北京郵電大學(xué)，2008：7-20.

［16］ 吳朱華.云計(jì)算核心技術(shù)剖析.北京：人民郵電出版社，2011：16-44.

［17］ 周敏奇，王曉玲，金澈清，等.Hadoop權(quán)威指南（第2版）.北京：清華大學(xué)出版社，2011：213-224.

［18］ 金之雁，顏宏.數(shù)值天氣預(yù)報(bào)并行計(jì)算模式的設(shè)計(jì)與可行性討論.應(yīng)用氣象學(xué)報(bào)，1993，4（1）：117-121.

［19］ 牟道楠，王宗皓.層次分解并行計(jì)算法在TOVS資料中尺度分析中的應(yīng)用.應(yīng)用氣象學(xué)報(bào)，1994，5（1）：77-81.

A Set of Map Reduce Tuning Experiments Based on Meteorological Operations

Yang Runzhi1）Shen Wenhai1）Xiao Weiqing1）Hu Kaixi1）Yang Xin1）Wang Ying1）Tian Wei2）

1）（National Meteorological Information Center，Beijing100081）
2）（Nanjing University of Information Science&Technology，Nanjing210044）

Cloud computing technologies，which solves the problem of low computing power of a standalone server，uses distributed computing technology to achieve the computing power of parallel computing and computational efficiency.Cloud computing is a new application model for decentralized computing which can provide reliable，customized and maximum number of users with minimum resource，and it is also an important way to carry out cloud computing theory research and practical application combining with other theory and good techniques.In many industries and fields，cloud computing has a wider range of applications，and its flexibility，ease of use，stability is gradually affirmed.In meteorological department，cloudbased platform for the development of scientific computing is still very limited，but some attempts are implemented with the maturation of cloud computing.

In meteorological operations，such as large-scale scientific computing and other general computing model are run on high-performance server clusters.Due to limitations of resources and the number of HPC nodes，scientific computing still relies on traditional standalone or clustered mode.Therefore，an internal exploration and conventional general-purpose computing and cloud computing platform is very meaningful for the meteorological department.60-year valuable and precious long sequence of historical data are stored in National Meteorological Information Center for the use of real-time，near-real-time business and research.Processing these historical data is time-consuming，therefore some new methods are implemented.Based on Hadoop cloud computing platform，a cluster mode is built and a variety of statistical methods areadopted using Map Reduce computation model.The storage format of the source data is adjusted with SequenceFile which is composed of＜Key，Value＞serialization，by this mean multiple files of Format-A are merged to a large SequenceFile to test computational efficiency changes.Meanwhile，many small files are merged to a larger file.Configurations are modified experimentally for the Hadoop cluster environment，and different number of task nodes are used to record different computational efficiency.

Map Reduce；cloud computing；Hadoop；meteorological data processing

楊潤芝，沈文海，肖衛(wèi)青，等.基于 MapReduce計(jì)算模型的氣象資料處理調(diào)優(yōu)試驗(yàn).應(yīng)用氣象學(xué)報(bào)，2014，25（5）：618-628.

2013-10-08收到，2014-06-03收到再改稿。

*email：yangrz＠cma.gov.cn