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

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

1 引言

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

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

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

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

（1）海量氣象數(shù)據(jù)在解析、寫入方面存在挑戰(zhàn)。

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

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

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

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

Figure 1 Meteorological data processing flow圖1 氣象數(shù)據(jù)處理流程

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

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

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

2 相關工作

在氣象數(shù)據(jù)存儲技術領域，當前業(yè)界仍以基于傳統(tǒng)文件系統(tǒng)的技術為主。

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

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

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

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

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

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

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

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

3 海量氣象數(shù)據(jù)實時解析系統(tǒng)

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

3.1 設計思想

（1）高吞吐設計。

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

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

（2）高容錯設計。

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

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

（3）高性能設計。

高性能設計是指盡可能充分利用系統(tǒng)資源，在給定硬件環(huán)境下達到盡可能好的性能。

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

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

此外，該架構下可以方便地重新調(diào)節(jié)各個階段的資源，使得在數(shù)據(jù)處理速度發(fā)生變化時，系統(tǒng)能夠動態(tài)保持平衡。

（4）高可擴展性。

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

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

3.2 海量氣象數(shù)據(jù)實時解析系統(tǒng)的設計

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

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

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

解碼任務：解碼任務對應解碼執(zhí)行線程池中的一個線程，實現(xiàn)對于一個具體氣象數(shù)據(jù)的解析。解析過程需要用到一些算法模塊，如GRIB 解碼、網(wǎng)格裁剪等，這些算法的調(diào)用方式為同步調(diào)用。

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

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

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

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

4 海量實時氣象數(shù)據(jù)存儲系統(tǒng)

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

4.1 氣象數(shù)據(jù)多維索引結構與用戶行為分析

4.1.1 多維索引空間結構

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

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

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

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

衛(wèi)星數(shù)據(jù)：衛(wèi)星名稱、觀測時間、通道、投影方式。

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

地面、高空、衛(wèi)星、雷達統(tǒng)稱實況數(shù)據(jù)。

以模式數(shù)據(jù)為例進行數(shù)據(jù)模型抽象：

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

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

4.1.2 用戶行為抽象

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

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

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

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

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

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

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

4.2 基于多維索引數(shù)據(jù)模型的實現(xiàn)

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

4.2.1 數(shù)據(jù)表

針對實時氣象數(shù)據(jù)內(nèi)容存儲，我們設計如下Column Family，見表2。

Table 2 Data table表2 數(shù)據(jù)表

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

4.2.2 維度索引表

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

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

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

4.2.3 最新時刻表

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

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

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

4.2.4 虛擬文件視圖表

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

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

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

5 海量氣象數(shù)據(jù)實時解析與存儲系統(tǒng)性能測量

5.1 海量氣象數(shù)據(jù)處理系統(tǒng)硬件環(huán)境

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

MICAPS 4數(shù)據(jù)環(huán)境的網(wǎng)絡拓撲結構如圖3所示。

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

5.2 測量結果與分析

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

Figure 3 MICAPS 4system topology圖3 MICAPS 4系統(tǒng)網(wǎng)絡拓撲圖

Table 6 Hardware configuration表6 硬件配置表

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

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

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

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

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

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

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

表9為實時解析系統(tǒng)對Cassandra的寫入性能。

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

Table 9 Realtime parsing system performance表9 實時解析系統(tǒng)性能

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

表10為相同數(shù)據(jù)集對Samba服務器的寫入性能。

Table 10 MICAPS 3.0data parsing and writing performance表10 MICAPS 3.0數(shù)據(jù)解析與寫入性能

可見基于Cassandra的實時解析與存儲系統(tǒng)比傳統(tǒng)文件系統(tǒng)具有明顯的數(shù)據(jù)寫入優(yōu)勢，而且單個數(shù)據(jù)越小，數(shù)據(jù)個數(shù)越多，優(yōu)勢越明顯。這是因為數(shù)據(jù)庫系統(tǒng)由于內(nèi)核的大量優(yōu)化，更適合于小數(shù)據(jù)的寫入。

6 結束語

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

［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－h(huán)ui.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－h(huán)an，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預報業(yè)務平臺現(xiàn)狀與發(fā)展［J］.氣象，2010，36（7）：50－55.

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

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

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

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

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

［9］ 鐘雨，黃向東，劉丹，等.大規(guī)模裝備監(jiān)測數(shù)據(jù)的NoSQL存儲方案［J］.計算機集成制造系統(tǒng)，2013（12）：3008－3016.