云計算平臺上實現30年氣候資料整編的方法

作者簡介：楊潤芝（1981—），女，黑龍江哈爾濱人，工程師，碩士，研究方向：云計算、計算機在氣象領域的應用（E-mail：yangrz@cma.gov.cn）；肖衛青（1984—），男，河北保定人，助理工程師，碩士，研究方向：云計算、計算機在氣象領域的應用、編解碼。

摘要：國家氣象信息中心存儲和保存了50多年寶貴的長序列歷史資料，這些歷史資料在實時、準實時業務及科研中需要經常被使用并進行氣象科學計算。由于歷史數據量大，耗時長，如何在短時間內得到所需的計算結果提供用戶使用成為本文的主要研究目標。通過搭建云計算平臺，并以30年氣候資料統計整編研究對象，在云計算平臺上基于MapReduce分布式并行計算模型進行多種統計項目、統計方法的算法實現。通過修改云計算平臺運行環境參數配置并在不同配置下運行相同計算任務，進行計算效率對比試驗。

關鍵詞：云計算； Hadoop；MapReduce計算模型；氣候資料整編

中圖分類號：TP39文獻標識碼：A

1業務現狀

中國30年氣候整編資料作為重要氣候資料的一種，己在很多天氣、氣候、模式計算等方面使用。目前國家氣象信息中心用于30年氣候資料整編的軟件是單機單進程模式，運行在PC機上。由于整編運算要使用國家級地面站（2400多個站）、30年的數據，數據總量大，所以完成一次整編計算需要耗時10多天（不間斷運行）。并且整編結果出來后，業務工作中需要檢查計算結果，并對整編算法或算法中的參數進行多次修改和調整，每次修改后，都需要重新再次計算，所以導致整編工作耗時較長。

目前，氣象部門基于云平臺開發的科學計算還非常少，氣象業務中的大規模科學計算如模式運算等一般運行在高性能服務器集群上，模式算法本身支持并行計算和高性能環境。但是由于高性能資源和節點個數的限制，除模式運算外的大部分通用和常規計算一般均依靠單機或集群間多進程通信開發。所以，探索和開展通用計算在云平臺的實現也成為本文的研究重點和目標[1，2]。

2云計算架構

2.1Hadoop分布式框架

Hadoop起源于Apache Nutch，后者是一個開源的網絡搜索引擎，本身也是由Lucene項目的一部分[7]。Hadoop提供給組件分布式系統的工具包括數據存儲、數據分析等。Hadoop是一個分布式計算基礎架構下的相關子項目的集合。這些項目屬于Apache軟件基金會，后者為開源軟件項目社區提供支持[3，4]。

Hadoop框架中，HDFS和MapReduce分別是對Google GFS和Google MapReduce的開源實現。本文所做的研究和試驗均基于Hadoop搭建分布式的計算環境而開展，數據源存儲在HDFS文件系統中，利用MapReduce編程模型實現30年氣候資料整編算法的運算流程和任務調度。

2.2文件系統結構

HDFS 集群有兩種節點，以管理者-工作者（masterworker）的模式運行，即一個名稱節點（namenode）和多個數據節點（datanode）[8]。名稱節點管理文件系統的命名空間。它維護著這個文件系統樹及這個樹內所有的文件和索引目錄。這些信息以命名空間鏡像和編輯日志的形式將文件永久保存在本地磁盤上。名稱節點也記錄著每個文件的每個塊所在的數據節點，但它并不永久保存塊的位置。因為這些信息會在系統啟動時有數據節點重建[5，6]。

客戶端代表用戶通過與名稱節點和數據節點交互來訪問整個文件系統。客戶端提供一個類似POSIX（可移植操作系統界面）的文件系統接口，因此用戶在編程時并不需要知道名稱節點和數據節點及其功能。數據節點是文件系統的工作者。它們存儲并提供定位塊服務（被用戶或名稱節點調用時），并且定時的向名稱節點發送它們存儲的塊的列表。

客戶端通過調用FileSystem對象的open（）來讀取希望打開的文件，對于HDFS 來說，這個對象是分布式文件系統的一個實例。DistributedFileSystem通過使用RPC 來調用名稱節點，以確定文件開頭部分的位置。對于每個塊，名稱節點返回具有該塊副本的數據節點地址。客戶端對輸入流調用read（）。存儲著文件開頭部分的塊的數據節點地址DFSInputStream隨即與這些塊最近的數據節點相連接。通過在數據流中重復調用read（），數據會從數據節點返回客戶端。

330年氣候資料整編設計與實現

3.1累年日平均氣溫計算流程如圖3所示，是在云計算模式和傳統單機模式下兩種運算流程。以下分別對兩種計算流程的具體步驟進行說明：

1）單機模式：

以30年累年日平均氣溫算法為例，傳統整編軟件采用單進程順序執行策略，主要計算步驟如下：

（1）主程序依次順序讀取用戶指定的文件夾（目錄）下的每個A文件。當計算30年累年日平均值時，需要依次順序讀取360（30*12）個A文件，解析每個A文件中每日4次或24次氣溫值，并根據相應的統計算法計算日平均氣溫；

（2）將日平均氣溫值以數組或記錄方式存儲在表或文件中；每個A文件需要記錄該月中每日平均氣溫值；

（3）當所有30年所包含的A文件均處理完成后，主進程對所有記錄的數據表或文件值中含有相同月日（366個值）的氣溫值進行累加，累加結果除以日數。

通過分析可以發現，在傳統單機模型下，主程序需要單進程處理所有30年的數據文件，并且需要創建大小為10950（365*30）條的數組或記錄表。并對在計算累年日平均值的過程中，計算模塊需要通過數組或記錄表的方式保存每日的日平均氣溫，最后根據相同月日的條件進行篩選并累加。（a）傳統整編軟件計算流程

（b）云計算模式計算流程

1）云計算模式：

仍以計算累年日平均整編值為例。在云計算平臺上基于MapReduce計算模型的運算流圖如下：

（1）JobTracter啟動一個任務后，根據用戶定義的InputSplit和InputFormatClass解析HDFS上對應目錄下的數據文件，根據匹配的數據輸入源分配Map任務。

（2）每個Map將處理結果輸出為（key，value）鍵值對，Barrier將所有輸出的鍵值對進行排序，將Key值相同的結果進行合并。

（3）JobTracter根據鍵值對結果啟動reduce，最終生成用戶需要的final key 和value。

在MapReduce計算模型中，由Map函數統計出文件中每月/日的日平均氣溫，Reduce函數將所有月/日作為key值的相同值求平均值，即求出累年日平均氣溫。value由于歷史資料整編的數據源為A文件，所以本文首先按照A文件的格式重寫了Hadoop中的FileInput -Format。在任務分配時，根據FileInputFormat識別數據輸入為360個A文件并創建map任務。每個map任務讀取一個文件并進行解析，根據日平均值算法計算出歷年每日日平均氣溫，并將結果以（月.日，日平均氣溫值）的格式進行輸出。Barrier將所有key值相同的結果進行合并，即可得到30年中，每個月和日均相同的日平均氣溫值。Reduce將該月.日的所有輸入結果進行計算最終得出累年日平均氣溫值。

3.2兩種計算模式比較

與傳統的計算方法比較，基于MapReduce模型編寫整編算法的優越性主要體現在以下幾個方面：

1）MapReduce計算模型是分布式的，它充分利用了多個節點的計算能力和IO帶寬，將原本集中在一臺單機上依靠順序運行的算法改為可以并行運行，使得在較短時間內最大程度利用了現有空閑資源。

2）Map和Reduce之間的中間結果不需要程序干預。平臺本身利用Barrier層會將所有map輸出的結果進行處理，省去用戶程序中對大量中間結果的存儲和處理，簡化用戶程序邏輯。

3）MapReduce計算模型下任務運行更靈活。由于計算任務本身無需對數據源范圍進行框定，所以可以在不修改任務界面和程序的情況下，完成對不同時間段氣候資料整編值的計算。

4測試方案與性能優化分析

4.1測試方案

本文搭建了由5個節點（服務器）組成的Hadoop分布式計算平臺，均部署在局域網內。由于本文僅以小部分統計項目和整編算法為例在Hadoop平臺上進行了實現，且本文試驗環境為Linux（傳統整編軟件運行環境為Windows），所以在與傳統計算模式進行時比較測試和時效性分析時，存在難度（因為現有整編軟件在進行統計時，不能指定統計項目和統計方法，只能一次性將所有統計項目和統計方法計算完）。所以本文采用一種模糊比較方式進行了試驗和分析。

本文模擬了幾組比較典型的應用場景，分別在不同場景下進行了試驗。見表1。試驗1和試驗2、3均選用50136站1981-2010年間360個A文件作為數據源。

試驗1在Hadoop平臺中只配置了一個節點，即模擬單機環境，完成累年日平均氣溫計算需966s。試驗2在Hadoop平臺中只配置了三個節點，任務數為24，完成累年日平均氣溫計算需245s。試驗3在Hadoop平臺中只配置了五個節點，任務數為80，完成累年日平均氣溫計算需64s。

通過比較，可分析出當平臺中節點數增加、任務數增加時，總體運行時間會縮短。與執行時間相關的有節點數，任務數，任務本身消耗CPU量，文件大小等因素均有關，并非單一線性關系。例如，通過試驗4和5中，環境配置相同，區別僅在于文件個數與文件總量，試驗5的數據源是試驗4的321倍，但完成時間僅為144倍。

4.2Hadoop性能優化

根據本文所做的一系列試驗可以看出，Hadoop的性能優化是一個多維的優化問題，影響因素主要有作業的大小，機器的性能，Hadoop的屬性配置，以及調度算法的實現等等。因此每個Hadoop環境需要根據集群自身的特點來配置，以使平臺整體性能達到較優。各屬性間的關系非常復雜且相互影響，存在制約或依賴關系，設置不合理會導致資源競爭，系統的整體性能降低，所以平衡配置屬性之間的相互制約關系非常重要[7，8]。不同應用任務對執行環境的要求不同，需要對系統進行不同配置以提高整體性能。

本文在下階段工作中會重點根據每個計算任務的特點配置任務調度、運行環境、以及對數據本身進行改造，以期找到能夠量化任務運行時效與云計算平臺資源間關系的方法。

5結語

本文基于Hadoop搭建了集群模式的云計算平臺，并以30年氣候資料統計整編為例，在云計算平臺上基于MapReduce計算模型進行了多種統計項目、統計方法的算法實現并在Hadoop平臺上進行運行測試。在后續的研究與應用工作中，本文將進一步關注分析數據源、運算量、資源消耗量等特征，并在不同的應用場景下實現更多氣象資料處理算法及模塊在Hadoop平臺上的實現和移植。

參考文獻

[1]沈文海. 云計算受困于服務手段的有限和體制兩因素[EB/OL]. IT商業新聞網 http：//cio.itxinwen.com /Online/2011/1115/ 370736.html.

[2]沈文海. 從云計算看氣象部門未來的信息化趨勢[J].氣象科技進展，2012，（2）：49-56.

[3]李軍華. 云計算及若干數據挖掘算法的MapReduce化研究[J]. 電子科技大學，2010.5：19-32.

[4]萬至臻. 基于MapReduce模型的并行計算平臺的設計與實現[J]. 浙江大學，2008，（5）：17-21.

[5]朱珠. 基于Hadoop的海量數據處理模型研究和應用[J].北京郵電大學，2008，（1）：7-20.

[6]劉娜.基于MapReduce的數據挖掘算法在全國人口系統中的應用[J].首都經濟貿易大學，2011，（3）：20-43.

[7]周敏奇，王曉玲，金澈清，等. Hadoop權威指南（第2版）[M].北京：清華大學出版社：213-224.

[8]吳朱華. 云計算核心技術剖析[M].北京：人民郵電出版社. 2011.5：16-44.