海量氣象數據實時解析與存儲系統的設計與實現＊

王若曈，黃向東，張 博，王建民，羅 兵

（1.國家氣象中心，北京100081；2，清華大學軟件學院，北京100084）

1 引言

實時氣象數據種類繁多，并具有非常大的數量和容量，是名副其實的領域大數據。據統計，在天氣預報中，服務器每天都要新存儲約1 500 萬個500KB至10 MB大小不等的數據文件，未來則會達到每天1億個新文件，日增量50TB 以上，預報員使用這些海量數據時，通常需要達到至少每秒10個文件的連續閱讀速度以產生視覺動畫效果，方可進行高效率天氣預報。

氣象數據中很重要的一種數據稱為“模式數據”。模式數據是由高性能計算機根據當前天氣實況數據通過物理方程計算而成的，模式數據每天計算2～4次或更多次，每次生成大概1 000個物理量從當前時刻至未來240小時時效（或更長）的一系列二進制網格數據，時效通常3小時間隔，每個網格值代表經緯度網格上的一個物理量值，一個文件大小通常在1 MB～2 MB 之間。由于模式物理量多，每天多次起報，預報時效密集，模式種類多，存儲時間較長，因此在氣象數據中，無論從數據個數還是數據存儲量來說，模式數據是比重最大的“大數據”。

根據國家氣象中心（中央氣象臺）的統計，預報員常用的實時氣象數據在服務器端的快照平均約等于5千萬個，總容量大概為100TB，其中70%為模式數據。

隨著氣象數據規模的持續高速增長，全國天氣預 報 平 臺MICAPS（Meteorological Information Comprehensive Analysis Processing System）［1］3.0版自2010年起就開始面臨嚴峻的性能和存儲壓力。

（1）海量氣象數據在解析、寫入方面存在挑戰。

氣象數據對時間、可靠性非常敏感。除模式數據，氣象數據還包括衛星、雷達、地面、探空等實況數據。每一個數據對預報的準確率都具有至關重要的作用。因此，任何由于原始數據解析/寫入系統故障導致的數據丟失或延遲都是不能容忍的。

（2）海量氣象數據的存儲面臨訪問與查詢緩慢的問題。

以MICAPS 3.0 為例，目前國內外氣象數據存儲技術仍多以基于目錄樹形結構的文件系統進行組織。而傳統文件系統往往難以承受每日百萬級的文件數量增長，且文件目錄的樹形結構不能很好地滿足預報員對數據進行按序訪問的特點，比如按照時間順序瀏覽數據。據測量，在現有的基于文件系統的天氣預報系統中，當系統存儲數據文件個數達到2 000萬個時，僅服務器端文件定位時間就要耗時500ms，按序訪問時間將更長，無法很好地滿足應用需求。傳統關系型數據庫雖然具有排序和索引能力，但其固定的關系表模式使得系統設計十分復雜，其磁盤存儲結構也限制了其有序訪問的優化。因此，無論文件系統還是傳統數據庫技術的存儲和查詢方式都無法很好地滿足氣象數據的高性能查詢。

圖1為氣象數據處理流程圖，原始數據經采集、分發、解析、存儲，最終在預報員工作平臺上進行可視化，經過預報員的分析判斷，制作天氣預報結果，向公眾發布。

Figure 1 Meteorological data processing flow圖1 氣象數據處理流程

為提升海量氣象數據的實時處理能力，實現MICAPS客戶端對于氣象數據更高效的應用，中國自2013年正式啟動MICAPS第4版（簡稱MICAPS 4）的研發工作，其中海量氣象數據實時解析與存儲系統是MICAPS 4的核心系統之一。該系統必須能夠實現海量數據實時、可靠的解析與寫入，支撐上百TB 級的數據存儲，客戶端毫秒級延遲訪問以及7＊24小時的穩定運行。

目前MICAPS 4 已經投入運行，有力支撐著全國天氣預報業務。本文將針對氣象數據模型的特點以及用戶行為，詳細描述MICAPS海量氣象數據實時解析與存儲系統的設計原理、構架與實現細節。

本文第2節介紹對氣象數據解析和存儲的相關研究工作；第3節介紹海量氣象數據實時解析系統的設計與實現，詳細描述了該子系統的所有關鍵模塊及實現原理；第4節介紹基于非關系型分布式Key－Value數據庫，以及多維索引數據模型的海量氣象數據存儲系統的設計實現，該存儲系統可以滿足全體MICAPS用戶毫秒級查詢；第5 節實際測量解析系統和存儲系統的性能，并加以分析；第6節進行總結。

2 相關工作

在氣象數據存儲技術領域，當前業界仍以基于傳統文件系統的技術為主。

文獻［1］描述了針對MICAPS 3.0 客戶端進行性能優化的方案，但僅限于客戶端圖形渲染算法的改進，對于如何提升服務端數據獲取性能并沒有給出解決方案。

文獻［2］指出，由于以氣象數據為例的多維數據文件的復雜性和海量性，一般商業數據庫的適應性受到很大限制，而文件系統則成為較為經濟的存儲方法。

文獻［3］以天氣預報行業為例，提出采用傳統文件系統進行多維數據的存儲，并在上層使用Samba等協議工具提供遠程存取服務。實際應用中使用文件系統時，往往以不同維度作為目錄，構建出一個樹形結構存儲。每種維度作為目錄樹的一層內部節點，數據文件作為樹的葉子節點。為了形成樹形結構，需要人為規定數據文件維度的層次關系。這種方式簡化了系統設計，對于數據文件的存儲交由服務器的文件系統完成。然而由于文件系統本身并不考慮不同文件的邏輯順序，對于維度的有序訪問時，只能通過獲取某一目錄下所有文件，并進行手動排序，即對葉子節點進行排序。當對其他維度進行排序時，則需要過濾不同中間節點的葉子節點，并進行合并和排序。當文件數量達到百萬、千萬級時，文件定位的速度將出現顯著下降。

文獻［4］給出了基于SAN（Storage Area Network）和GPFS（General Parallel File System）的高性能氣象數據存儲集群架構，能夠很好地解決海量存儲、容災備份等特點，然而并未對數據有序獲取進行優化。

文獻［5］提出了利用NetCDF文件格式進行氣象數據的表示和存儲，這種方案可以將大量小文件打包為一個大文件，減少了小文件個數。但是，由于NetCDF文件本身并不支持索引在各個維度的按序檢索功能，無法滿足預報員快速時空翻頁的需求。此外，由于依賴傳統文件系統，采用了集中式存儲，該方案在面對大規模并發訪問時也存在性能隱患。

文獻［6］提出了針對氣象數據的多維數據空間模型，并給出采用基于Key－Value 的存儲系統Cassandra對其進行實現的方法。然而文獻［6］僅給出了多維數據到Cassandra存儲結構的轉換指導方法，并未給出確切的Cassandra存儲結構，此外，作者并未對數據的操作建立足夠的索引，導致部分查詢可能存在性能問題。并且文獻［6］中并未給出兼容傳統文件視圖的方法。

非關系型數據庫在處理海量數據方面具有較強優 勢［7］，以Hbase、Cassandra［8］為 代 表 的 基 于Key－Value的存儲系統廣泛應用于大數據場景。文獻［9］提出了基于Cassandra的大規模裝備監測數據的存儲模式設計，一些弱一致性存儲系統［10］也常常用于實現低延遲的存儲與讀取操作。

在數據的ETL 方面，現有工作往往沒有考慮分布式的實現［11，12］，并且對非結構化數據的討論不足。這也導致了現有工作無法很好應用在氣象領域。Zhu Y 等人［13］設計了非結構化數據管理系統laUD－MS，該系統對于音視頻等數據做了優化，但缺少高效的數據解析模塊。有人提出使用MapReduce對文件數據進行解析［14］，然而依賴MapReduce的方法無法滿足氣象數據的時效性。

3 海量氣象數據實時解析系統

一個實時解析系統需要具備高吞吐、高容錯、高性能、高可擴展性四個要素。本節首先從四個要素介紹解析系統的設計思想，然后詳細介紹解析系統各個模塊在氣象數據實踐中的應用。

3.1 設計思想

（1）高吞吐設計。

高吞吐是指解析系統輸入數據源數據量大，對于氣象數據，海量數據往往集中到達，需要系統解析速度與數據輸入速度基本相等。此外，隨著業務的發展，需要能夠快速地擴充系統的吞吐量。

為此我們采用了P2P 分布式架構。在解析系統中，設置多臺工作節點，每臺節點僅負責特定種類的數據。當數據到達時，不同數據會選擇不同的節點進行解析。一個節點的資源（帶寬或者CPU等）達到上限時，加入新的節點進入集群，新節點將接管資源緊張節點的部分數據解析工作。

（2）高容錯設計。

高容錯是指任意時刻，不允許系統暫停服務的故障。由于數據流式到達，系統宕機將丟失數據。

為防止單點故障，所有服務器節點均采用虛擬化技術，利用IP 地址漂移，具有冗余的物理備份，發生服務器故障時，可以熱切換到備份服務器而不影響數據接收。每臺解析服務器均采用雙網卡，連接到兩個內部交換機，從而避免交換機故障。

（3）高性能設計。

高性能設計是指盡可能充分利用系統資源，在給定硬件環境下達到盡可能好的性能。

整個解析流程劃分為數據到達、任務分發、數據解析、數據持久化四個階段，不同的階段耗時不同，例如，解碼任務耗時較久，而數據持久化耗時較短。若簡單采用多線程技術進行上述階段的執行，會由于前一階段過慢而降低整個系統的性能，或由于前一階段過快、后一階段過慢而增加緩存占用。

我們采用了SEDA （Stage Event Driven Architecture）架構，將每個階段變成異步操作。每個階段都擁有自己的資源（即線程池），通過調節不同階段的資源數，可以達到系統資源的最大利用，并使得各個階段的速度達到平衡。

此外，該架構下可以方便地重新調節各個階段的資源，使得在數據處理速度發生變化時，系統能夠動態保持平衡。

（4）高可擴展性。

由于氣象數據種類多變，現有解碼模塊無法處理新的氣象數據類型，因此系統必須在不重啟的情況下擴展對于新興數據的處理能力。

我們采用Java的反射機制，進行解碼功能的動態加載。為了降低Java反射機制導致的性能問題，我們采用交互方式進行解碼功能的擴展。通過控制程序，JVM 動態加載新的解碼實現，并映射該解碼器所能處理的數據類型到內存中，當新的數據類型到達時，新的解碼器開始工作。

3.2 海量氣象數據實時解析系統的設計

圖2為MICAPS 4海量氣象數據實時解析系統的總體設計，粗箭頭代表數據流，描述了原始氣象數據接收、解析、寫入、存儲、客戶端訪問的全過程，本節將討論實時解析系統的關鍵模塊。

數據觸發器：氣象數據國際標準采用FTP 協議傳送，但商業化FTP 服務器通常只具備數據接收功能，從而只能通過目錄輪詢來判斷數據是否到達，影響了處理效率。在MICAPS4實時解析系統中，沒有采用基于數據時間表的傳統輪詢策略，而是研制了經擴展的FTP 服務器組件，每一個數據接收完成立即發送消息，保證解析程序的實時處理。

解碼執行線程池：數據觸發器保證了數據到達即處理，為了不影響新數據接收，解析系統對于數據解析的過程是異步的，這樣同一時間內可能會有大量的解析任務并發運行。實時解析系統利用解碼執行線程池來保證該過程的穩定、高效。根據處理數據類型的不同，解碼執行線程池均被設置了不同的線程數閾值，達到這個閾值后，新任務將等待，避免過度消耗系統資源。對于模式數據，由于GRIB［15］壓縮率較高，解碼需要消耗很大的內存，因此處理模式的解析服務器線程閾值較小。而處理雷達、衛星的解析服務器，數據量密集，IO 消耗大，而CPU、內存消耗小，為盡快完成數據的寫入，在這些服務器上保持了較高的線程數閾值。

解碼任務：解碼任務對應解碼執行線程池中的一個線程，實現對于一個具體氣象數據的解析。解析過程需要用到一些算法模塊，如GRIB 解碼、網格裁剪等，這些算法的調用方式為同步調用。

臨時文件數據池：原始數據以及氣象算法加工過程中中間結果將在解析服務器上保存一段時間，由文件清除器后臺線程定期刪除。當存儲服務器發生故障時，文件恢復器將這些數據重新加載到解碼任務分發器，就可以實現數據快速恢復。

Figure 2 Design of massive data realtime parsing servers圖2 海量數據實時解析服務器設計

數據寫入：原始數據解析為客戶端數據格式后，寫入任務分發器將數據派發給寫入任務，放入寫入執行線程池中向存儲服務器寫入。寫入任務利用存儲服務器連接池以及負載均衡組件保證對于每臺存儲服務器的平衡。由于存儲服務器可能出現硬件故障，因此連接池及負載均衡器還具備修復和切換連接的功能。

日志與監控：解析系統在原始數據接收、解碼、寫入的全過程中，均記錄了不同優先級的日志信息，既便于對系統故障的人工診斷，也為監控系統提供了信息。部署在解析服務器上的監控進程定時提取解析日志，向監控服務器匯報解析系統的健康狀況。解析進程與監控進程是部署在相同服務器上的兩個獨立進程，這是為了避免監控系統影響解析系統的性能與穩定性。

4 海量實時氣象數據存儲系統

本節首先深入分析實時氣象數據的多維索引模型與用戶行為，然后介紹該模型的實現，以及針對用戶行為的模型擴展結構設計與實現，該實現可以高性能滿足用戶的各種查詢需求。

4.1 氣象數據多維索引結構與用戶行為分析

4.1.1 多維索引空間結構

氣象數據是典型的非結構化數據，并且具有多維索引結構和Key－Value特點，每類數據都可以由一個多維索引唯一確定一個數據值，這個數據值可以是一個模式網格，也可以是一個衛星數據等。各類數據的多維索引表示如下：

模式數據：模式名、物理量、層次、起報時間、預報時效，如歐洲模式8日20 點起報，24小時之后（即9日20時）的850百帕全球溫度場。

地面數據：觀測時間、觀測內容的自然語言描述字符串，如5月13日早8點，全國國家站地面觀測實況。

高空數據：觀測時間、層次、觀測內容的自然語言描述字符串，如13日晚8點，850hPa，全國高空填圖。

衛星數據：衛星名稱、觀測時間、通道、投影方式。

雷達數據：雷達ID、觀測時間、物理量、仰角、投影方式。

地面、高空、衛星、雷達統稱實況數據。

以模式數據為例進行數據模型抽象：

如表1所示，在某模式（Model）數據中，某個具體數據（File）可以通過物理量（Element）、層次（Level）、起報時間（Time）、預報時效（Period）唯一確定。因此，由五個索引可唯一確定一個文件F，即（M，E，L，T，P）→F。

Table 1 Multi－dimensional index structure of model data表1 模式數據多維索引結構

4.1.2 用戶行為抽象

預報員常用的操作包括“指定數據”“最新數據檢索”“左右翻頁”“上下翻頁”“目錄查看”等操作，占全部操作70%以上。用戶必須通過流暢的翻頁操作形成的視覺動畫效果實現對于未來天氣狀況的預測。基于氣象數據多維索引結構，我們對五種高頻率用戶行為進行抽象：

（1）“指定數據”，用于直接顯示某時間點的氣象數據。即指明需要數據的全部多維索引值，直接命中該數據。

（2）“最新數據檢索”，即用戶希望通過僅部分索引得到相關數據。比如用戶不能準確指定最新時間的前提下，希望服務器返回最新觀測時間的衛星數據。

（3）“左右翻頁”用于快速查看天氣狀況隨時間的演變情況。模式數據的“左右翻頁”操作是在保持其他維度索引固定的前提下，對于“預報時效”索引進行雙向快速連續變化。實況數據的“左右翻頁”操作是保持其他維度索引固定的前提下，對“觀測時間”索引進行雙向快速連續變化。例如，對（日本模式，相對濕度，850hPa，13日8時起報，3小時時效）右翻頁的結果為：（日本模式，相對濕度，850hPa，13日8時起報，6小時時效）。

（4）“上下翻頁”用于快速查看天氣狀況隨高度的變化狀況。模式數據、高空數據的“上下翻頁”操作是保持其他維度索引固定的前提下，對“層次”索引進行雙向快速連續變化。例如，對（日本模式，相對濕度，850hPa，13日8時起報，3小時時效）上翻頁的結果為：（日本模式，相對濕度，700hPa，13日8時起報，3小時時效）。

（5）“樹形檢索”，用戶多年來一直使用文件系統URL 來進行元數據瀏覽，查看服務器當前存儲了哪些氣象數據，該方法方便直觀，即使不采用文件系統作為存儲，新的存儲系統也應保留用戶基于目錄樹的訪問行為。

綜上所述，實時氣象數據模型具有多維度，部分維度有序，部分維度無序的特點。在這種數據上，常用操作包括：在有序維度上按序遍歷數據，在無序維度上隨機訪問數據，并且按序訪問保證高性能。

4.2 基于多維索引數據模型的實現

文獻［6］提到，Cassandra 是一個基于Key－Value的P2P分布式系統，適合作為多維數據空間結構的實現［6］，這同氣象數據多維索引鍵值結構相呼應。同時，在文獻［6］中，在海量小文件場景下，對Samba、HDFS、Cassandra等存儲方案進行了詳細的理論分析和性能對比，并分析了每種方案的應用場景。由于Cassandra在存儲具有多維空間特點的海量小數據方面具有顯著的優勢，因此我們采用Cassandra作為實時氣象數據存儲的實現方案。

4.2.1 數據表

針對實時氣象數據內容存儲，我們設計如下Column Family，見表2。

Table 2 Data table表2 數據表

這種數據存儲設計支持隨機指定數據的讀取，還可支持有序訪問。例如，在T639模式CF中，當用戶查閱WIND 的500hPa層次下15050820 時刻24小時時效的數據后，如果希望查看下一個時效的數據，由于用戶并不能確定下一個預報時效的數值，傳統文件系統只能進行文件列表獲取。而在這種設計中，由于列是按序存儲在磁盤上的，在指定了15050820.024列后，利用區間查詢，即可找到下一個列：如15050820.027，也可快速命中前一個時效的數據如15050820.021。因此，這種數據庫設計是緊密切合左右翻頁應用（即有序訪問）需求的。

4.2.2 維度索引表

針對其他維度的有序訪問，我們通過維度索引表實現，我們設計了如下Column Family，見表3。

Table 3 Dimension index table表3 維度索引表

利用維度索引表和數據表，可以實現數據的上下快速翻頁，比如用戶當前正在瀏覽850hPa的T639風場數據15050820.024，希望切換至上一層（700hPa）相同時間點的數據，則可利用T639/WIND/在列族level 中查找到上一層應為700hPa，進 而 利 用T639/WIND/700/15050820.024在數據表中直接定位所需數據。

4.2.3 最新時刻表

在實時氣象數據應用中，用戶不能確定當前系統中最新數據的完整名稱，因此無法指定確切的數據索引。因此，需要設計一個列族用于存儲該信息。Column Family設計如下，見表4。

Table 4 Latest data time table表4 最新時刻表

利用最新時刻表，即可實現最新數據的快速模糊查找，例如用戶提出請求“T639/WIND/500，＊.024”，表示希望獲得T639在500hPa風場的最近一次起報的24小時預報時效的數據，利用用戶傳入的參數，立即可以在列族latest＿data＿time中找到該數據的準確名稱為15050820.024，則用戶進一步根據完整索引WIND/500/15050820.024，即可在數據表T639中檢索到對應的網格數據。

4.2.4 虛擬文件視圖表

在實際生產系統中，新系統往往要兼容舊系統的使用方式。利用Cassandra來對傳統文件系統進行改造，極大提升了海量小文件的查詢性能，但造成了原始數據的瀏覽不如文件系統直觀，預報員無法通過資源管理器直觀看到文件系統的樹形目錄結構，這樣會造成用戶不知道服務器存儲了哪些數據，進而需要客戶端龐大復雜的配置文件才能實現對于服務器的訪問。為了解決這個問題，同時為了保留現有用戶的使用習慣，我們設計了列族treeview，基于數據庫環境，建立模擬文件系統的仿真環境，用戶可以直接利用樹形控件瀏覽全部數據，完全像同原有的Samba文件系統交互一樣。Column Family設計如下，見表5。

Table 5 View of virtual files表5 虛擬文件視圖表

用戶首先可以檢索到根元素root下全部數據的CF分類，即有幾大類氣象數據，得到T639，RADAR 等列族，通過T639，可以得到T639下的物理量列表，如溫度TMP，高度HGT 等，傳入T639/HGT 又可以得到T639高度場有哪些層次，這時可以得到100，200，300，…，850，925，1000等，通過T639/HGT/500可以得到T639 模式500hPa高度場下的全部數據名稱，如15050720.000—15050720.240，15050808.000—15050808.240，15050820.000—15050820.240，利用數據名稱的完整信息即可在對應的數據表中對該數據內容直接進行檢索。

5 海量氣象數據實時解析與存儲系統性能測量

5.1 海量氣象數據處理系統硬件環境

在MICAPS 4 數據環境中，采用機架服務器組成實時解析服務器集群以及分布式數據存儲集群，用于海量氣象數據的實時解析與存儲。各集群以及MICAPS 4客戶端均通過千兆網絡相連。除外部交換機外，解析集群、存儲集群還通過雙千兆內部交換機相連，避免集群內部網絡數據交換影響外部網絡，同時避免交換機單點失效。運行經驗表明，數據存儲副本數為3時即可獲得較優異的訪問性能。

MICAPS 4數據環境的網絡拓撲結構如圖3所示。

數據解析服務器和數據存儲服務器的硬件配置信息如表6所示。

5.2 測量結果與分析

首先，我們測量存儲集群的訪問性能。

Figure 3 MICAPS 4system topology圖3 MICAPS 4系統網絡拓撲圖

Table 6 Hardware configuration表6 硬件配置表

在真實MICAPS 4業務環境下集群的性能測量結果如表7（50并發）和表8（100并發）所示（輸出的時間為數據庫查詢時間＋網絡傳輸時間的總和）。可以看到，針對不同類型的數據，不同的并發數，最新時刻表的平均訪問時間幾乎都在1ms左右，說明隨機訪問最新數據時，查找最新數據索引值耗時代價相當小，甚至可以忽略。

從讀取數據的性能觀察，讀取時間和單個數據的字節數近似成正比，這說明大量的時間消耗在網絡傳輸上，而數據庫查找鍵值的定位時間很小。歐洲粗網格數據的最高隨機讀取時間是14.2ms，最低讀取時間為3.03ms，除去網絡傳輸時間，說明數據庫在模式數據定位過程的時間消耗為10 ms量級，甚至更少。所有數據最高讀取時間和平均讀取時間差別較大，但最低讀取時間和平均讀取時間相差較小，說明在第1次讀取數據時，由于數據沒有被緩存到服務器內存，因此需要通過磁盤讀取，速度稍慢，一旦常用數據被緩存進入內存，之后的讀取就具備了很高的性能。由于每臺服務器內存高達128GB，基本可以滿足全部用戶常用數據的緩存。

左右翻頁操作實際上是針對Cassandra的列進行有序連續讀取，從測量數據看，大部分左右翻頁時間也消耗在網絡傳輸上，只有極少量（通常是前幾次）左右翻頁的操作稍慢，平均翻頁速度很快。以FY2E 衛星數據為例，即使在最差情況下，也可以保證每秒20 幀衛星數據的讀取性能（1000/48.6＝20.6），其他數據也可以保證至少5～10幀/秒的左右翻頁性能。左右翻頁（有序訪問）的速度往往是隨機訪問的1.5倍，這個時間開銷集中在有序列的區間查找操作上。

上下翻頁（不依賴于Cassandra的有序訪問）的時間開銷近似等于隨機訪問時間加上一個很小的常量數值，這也與維度索引表＋數據表的實現機制是吻合的。事實上，我們擴充的索引表的性能比Cassandra自身的區間查詢性能更好，保證了用戶在各個維度各個方向連續讀取都具備很好的性能。同時也說明，利用索引表＋隨機訪問，可以實現任意數量有序維度數據的連續訪問。

Table 7 Query performance when concurrence number is 50表7 50并發下的查詢性能

當并發數在100時，系統并發負載量為50用戶的2倍，但是從各類數據不同操作的平均時間來看，沒有出現時間消耗翻倍增長的情況，大部分操作的平均時間只是略大于50用戶并發時的測量結果，個別操作甚至出現比50用戶并發性能更好的情況（如T639風場左右翻頁）。從單個T639風場數據大小看，100用戶的并發訪問需要的網絡傳輸總量已經超過了單臺服務器的網絡額定帶寬，但是由于存儲集群副本的存在，并發訪問的用戶將被分配到不同的協調者節點上，這樣就會分擔每臺服務器的壓力，提升用戶訪問性能，偶爾出現的并發數增加性能提升，可能因為訪問請求被分配到負載較輕的節點上，或者協調者節點恰好是數據所在節點，從而避免了集群內部的數據傳輸。

在具有2 000萬個小文件的Samba服務器上進行同樣數據的讀取和翻頁測試，歐洲細網格數據獲取最新文件名需要3.4s，隨機讀取需要0.9s，左右翻頁需要4s，上下翻頁需要1.5s。這是因為文件系統不具有按序索引的功能，在海量小文件的文件系統中獲取文件列表手動排序是非常大的開銷。

表9為實時解析系統對Cassandra的寫入性能。

Table 8 Query performance when concurrence number is 100表8 100并發下的查詢性能

Table 9 Realtime parsing system performance表9 實時解析系統性能

從表中看出，所有數據到Cassandra的寫入速度都較快。模式數據寫入速度慢于其他數據，這是因為模式數據GRIB 解壓縮耗時較長，生成MICAPS數據格式后才能進行寫入。此外，向Cassandra集群寫入的數據均為大量的小數據，這也會在一定程度上影響網絡總體傳輸性能。

表10為相同數據集對Samba服務器的寫入性能。

Table 10 MICAPS 3.0data parsing and writing performance表10 MICAPS 3.0數據解析與寫入性能

可見基于Cassandra的實時解析與存儲系統比傳統文件系統具有明顯的數據寫入優勢，而且單個數據越小，數據個數越多，優勢越明顯。這是因為數據庫系統由于內核的大量優化，更適合于小數據的寫入。

6 結束語

本文討論了海量氣象數據實時解析系統以及基于Cassandra的分布式氣象數據存儲系統。這兩大系統保證了氣象數據實時可靠的寫入，滿足了國家級MICAPS4預報平臺用戶的高性能數據訪問需求。該系統目前7＊24小時支撐著全國天氣預報業務的正常運行，具有很好的穩定性和擴展性，在實踐中得到了充分驗證。

［1］ Li Yue－an，Cao Li，Gao Song，et al.The current stage and development of MICAPS［J］.Meteorological Monthly，2010，36（7）：50－55.（in Chinese）

［2］ Wang Jing－li，Tan Xiao－guang，Zhang De－zheng，et al.Design and application of data access structure of metropolis meteorological service information system［J］.Meteorological Science and Technology，2004，31（6）：409－412.（in Chinese）

［3］ Qi Gui－bin，Zhou Er－bin，Ju Yang.Using samba service to realize information sharing［J］.Heilongjiang Meteorology，2012，28（4）：40－41.（in Chinese）

［4］ Zhao Chun－yan，Sun Ying－rui，Dong Feng，et al.Application of high performance meteorological data storage cluster and online extension［J］.Computing Technology and Automation，2013，32（3）：117－121.（in Chinese）

［5］ He Zhen－fang，Zhang Yao－nan，Zhao Guo－hui.Storing massive spatio－temporal data using parallel NetCDF［J］.E－Science Technology ＆ Application，2012，32（1）：54－61.（in Chinese）

［6］ Huang Xiang－dong，Wang Jian－min，Ge Si－han，et al.A storage model for large scale multi－dimension data files［C］∥Proc of NDBC，2014：1.（in Chinese）

［7］ Sakr S，Liu A，Batista D M.A survey of large scale data management approaches in cloud environments［J］.IEEE Communications Surveys Tutorials，2011，13（3）：311－336.

［8］ Lakshman A，Malik P.Cassandra—A decentralized structured storage system［J］.Operating Systems Review，2010，44（2）：35.

［9］ Zhong Yu，Huang Xiang－dong，Liu Dan.NoSQL storage solution for massive equipment monitoring data management［J］.Computer Integrated Manufacturing Systems，2013（12）：3008－3016.（in Chinese）

［10］ Zhu Y，Yu P S，Wang J.Recods：Replica consistency－ondemand store［C］∥Proc of 2013IEEE 29th International Conference on Data Engineering （ICDE），2013：1360－1363.

［11］ Gorawski M，Gorawska A.Research on the stream ETL process［M］∥Beyond Databases，Architectures，and Structures，2014：61－71.

［12］ Bansal S K.Towards a semantic extract－transform－load（ETL）framework for big data integration［C］∥Proc of 2014IEEE International Congress on Big Data （BigData Congress），2014：522－529.

［13］ Zhu Y，Du N，Tian H，et al.laUD－MS：An extensible system for unstructured data management［C］∥Proc of the 12th International Asia－Pacific Web Conference（APWEB），2010：435－440.

［14］ Um J H，Jeong C H，Choi S P，et al.Fast big textual data parsing in distributed and parallel computing environment［M］∥Mobile，Ubiquitous，and Intelligent Computing.2014：267－271.

［15］ Manual on Codes－International Codes，Volume I.2：Part B and Part C.［EB/OL］.［2015－05－11］.http：//library.wmo.int.

附中文參考文獻：

［1］ 李月安，曹莉，高嵩，等.MICAPS預報業務平臺現狀與發展［J］.氣象，2010，36（7）：50－55.

［2］ 王京麗，譚曉光，張德政，等.大城市氣象服務信息系統數據存儲體系框架設計與實現［J］.氣象科技，2004，31（6）：409－412.

［3］ 齊貴濱，周爾濱，鞠洋.利用samba服務實現信息共享［J］.黑龍江氣象，2012，28（4）：40－41.

［4］ 趙春燕，孫英銳，董峰，等.高性能氣象數據存儲集群及在線擴展技術應用［J］.計算技術與自動化，2013，32（3）：117－121.

［5］ 何振芳，張耀南，趙國輝.基于Parallel NetCDF的海量時空數據存儲研究［J］.科研信息化技術與應用，2012，32（1）：54－61.

［6］ 黃向東，王建民，葛斯函，等，一種海量多維文件集合的存儲模型［C］∥Proc of NDBC 2014，2014：1.

［9］ 鐘雨，黃向東，劉丹，等.大規模裝備監測數據的NoSQL存儲方案［J］.計算機集成制造系統，2013（12）：3008－3016.