氣象大數據分布式存儲設計與實現

雷 鳴

(天津市氣象信息中心，天津 300074)

0 引 言

隨著信息技術的進步，以及互聯網和科學數據分析等領域的快速發展，每年數據量近乎在成倍增長，人類社會已進入大數據的時代[1-2]。而隨著氣象數據種類、數量日益繁多，范圍尺度越來越大，在海量氣象數據場景下，無論傳統數據庫還是文件系統技術的查詢和存儲方式都不能很好地滿足氣象數據的高性能查詢要求。因為氣象數據不僅要在高并發情況下高速存儲，同時還需要在毫秒級的時間內提供數據產品服務，而傳統關系類數據庫因為一致性約束不能提供大數據要求的高強度采集和存儲需求，且維護比較困難、查詢效率低下[3-4]。同時，現有支撐省級業務的CIMISS系統的數據處理能力不足，尤其是數據的存儲能力和響應速度，已不能滿足現有的數據服務要求[5]。

隨著大數據時代的到來，低成本、高效率的數據存儲方式逐漸受到關注，將分布式文件系統作為大數據存儲載體，是當前大數據存儲領域相關技術的重點關注方向[6-10]。

基于以上原因，參照大數據技術在各行業中的成功應用[11-14]，利用分布式技術、按照集約化原則，構建天津省級氣象大數據服務中心。

1 系統架構

1.1 系統總體架構

考慮到利舊和核心業務數據難以動遷的實際問題，擬采用關系型數據存儲、分布式NoSQL數據庫存儲、網格存儲系統和分布式NAS存儲相結合的混合云存儲架構。整體系統架構如圖1所示。

系統涵蓋了數據采集、數據存儲到數據發布的整個流程。其中，公有云和私有云構成了混合云的架構。因為氣象數據涉及安全性，目前，公有云上更多的是利用強大的計算資源，進行AI氣象智能產品的研發和計算。更多的數據存儲和核心功能都集中在私有云當中。

圖1 系統總體架構

1.2 系統物理架構

目前，天津省級氣象大數據服務中心的私有云存儲主要由兩部分組成：虛擬機與物理機，共計25臺服務器，物理機7臺，其余則為虛擬機(不涵蓋CIMISS數據庫的14臺服務器集群和4臺虛擬機集群)。整個系統架構如圖2所示。

圖2 系統物理架構設計

2 系統數據存儲架構

全國綜合氣象信息共享系統(CIMISS)是由國家氣象信息中心于2009年組織建設，集數據收集、分發、處理、存儲和共享于一體。2013年，該系統在全國各省級氣象數據中心進行推廣和部署，為氣象系統各省級部門提供了較好的業務支撐和數據服務[15-17]。雖然它已經無法更好地提供現代化氣象服務，但卻無法由省級進行替換。為了能夠與CIMISS系統進行良好的無縫對接，擬通過全國氣象數據統一服務接口(meteorological unified service interface community，MUSIC)[18]將CIMISS數據源與本地數據服務中心進行整合，提供全國統一、標準、豐富的數據訪問服務和應用編程接口(API)。整個數據存儲架構設計如圖3所示。

圖3 系統數據架構設計

數據采集層：負責從互聯網、共享目錄、FTP服務器采集各類探測數據、預報服務產品、行業共享數據和互聯網數據；

數據處理層：主要負責采集后的數據按照業務特性進行解析、清洗，存儲模型構建等功能；

數據存儲層：負責對解析后的數據按照預先分類的結果存儲到對應的存儲組件中，格點數據存儲到HBase中，站點數據存儲到GBase中。而為了提高對格點數據的查詢效率，通過將RowKey存儲Elasticsearch(簡稱ES，下同)中實現快速尋址，快速獲取得到需要查詢的數據。

數據服務層：負責對數據進行封裝，結合MUSIC數據接口體系，封裝成站點數據接口，格點數據接口使用開源swagger數據接口進行封裝。從而通過接口(API)，實現應用與數據解耦、數據管理與應用分離，接口保持穩定不變，保障前端應用系統穩定，不受后端異構數據環境、實現技術變化無影響。

3 氣象數據存儲策略設計

天津省級氣象大數據服務中心的數據可以分為兩大類：結構化數據和半/非結構化數據。針對前者，采用HBase+GBase分布式數據庫存儲；針對后者，采用HBase分布式數據庫存儲和氣象數據分塊壓縮技術，進行氣象數據存儲和處理。

3.1 結構化數據

站點數據、基準設備觀測數據等數據結構化程度高，數據結構固定，采用關系數據庫形式對此類數據進行存儲，簡化了數據存儲邏輯，有利于提高數據存取效率以及分析速度。

考慮到數據中心需要存儲海量數據，故結構化數據需要在存儲集群內進行分庫分表存儲，以保障數據庫的并發性能。關系數據庫以數據來源(如雷達站、基準設備)進行分庫存儲，各個數據存儲節點采用Gbase 8a(分析型數據庫)、Gbase 8t(關系型數據庫)等高性能數據庫，保證在大數據場景下能夠實現數據的高效存取。

同時根據數據的使用需要，為關系數據庫額外建立多種索引形式，以提升數據索引效率。除數據來源、時間外，數據索引主要采用要素、行政區劃等字段。

3.2 半/非結構化數據

對于泛氣象數據、各類服務產品等數據，其結構化程度低，數據參數一致性低，數據大小不定。對于此類非結構化數據，如果采用通用的結構化存儲方式，必然導致其在數據存取方面出現問題，無法滿足業務的需求。故此采用HBase非結構化數據庫進行存儲。

HBase的數據表由行和列組成。邏輯上，數據存儲在表里，而表由行和列組成，每行由一個可排序的主鍵和任意多的列構成，列又歸屬于不同列族。HBase是面向列的稀疏存儲，列族是固定不變的，在創建表時被定義，相當于表結構。HBase將同一個列族下的數據存儲在同一個目錄下。而列族中的列成員不必在表定義時聲明，可以在表實時運行中動態定義。

圖4 基于Hadoop的HBase分布式存儲架構

在實際實現中，預先根據非結構化數據類型定義所需列族，并預留若干冗余列族用于后期擴展補充。各非結構化數據在存儲時僅需將數據存入自身對應的列族中。在數據讀取時，也可根據列族索引快速檢索所需數據。整個系統架構如圖4所示。

整個系統的存儲策略設計如表1所示。

表1 數據存儲方式

其中，為了獲得更高的訪問速度，NAS作為HBase的數據源，提供輸入數據，以獲得毫秒級的數據響應服務。

4 系統性能測試

4.1 數據響應速度測試

針對以上數據存儲環境進行性能測試，測試系統硬件配置為：CPU：i5-3470 3.20 GHz，內存：4G，瀏覽器：支持谷歌內核的主流瀏覽器，如chrome，則基于WEBGIS的數據渲染顯示指標如表2所示。

針對頁面的響應速度進行測試，實際的各項數據查詢響應時間如表3所示。

表2 WEBGIS數據渲染顯示指標

表3 數據查詢響應時間

4.2 性能對比測試

為了進一步測試系統性能，將文中系統GBase數據庫與CIMISS系統中的Oracle傳統數據庫進行速度響應測試對比，庫中共有155 281 334 700條記錄，為1951年至今的70年全部自動站數據。測試對比如圖5所示。

可以看到基于大數據環境下的存儲查詢性能比傳統查詢具有明顯的優勢，且性能提升的倍數，隨著時間維度的延長而不斷擴大，由最初的提升7.6倍增加到21.5倍，而且還有不斷擴大的趨勢。

圖5 查詢性能測試對比

針對格點數據，為了進一步提升系統查詢性能，特別使用ES進行數據檢索，從而發揮查詢聚合的性能，并利用HBase作為點位數據存儲，更大程度地發揮IO性能。同時，為了盡量減少傳輸時間，將json結果集數組化為相應的經緯度矩陣，并將矩陣寫入csv文件，然后壓縮成tgz文件返回給前端，從而大大降低傳輸數據量的大小，提升傳輸效率。

性能對比：采用歷史6個月總計4萬天津1 km網格數據。在進行系統測試中，數據的響應速度能夠在0.3 s內到用戶頁面訪問終端，與天津省局舊有一體化平臺中格點數據的訪問速度相比，平均速度提升了5倍多。

5 結束語

利用大數據存儲技術，以關系型數據存儲、分布式NoSQL數據庫存儲、網格存儲系統和分布式NAS存儲相結合的混合云存儲架構為基礎，搭建了統一數據集、處理和服務的數據中心，并提供了統一的數據服務接口。整個系統具有良好的擴展性，可以與傳統數據庫通過服務接口進行無縫銜接。同時，數據服務性能得到較大程度的提升，有效保證了現代化氣象服務的建設需求。

但也應當清醒地看到，雖然天津省級氣象大數據的建設已經初具規模，但是仍然有很多不足之處需要去彌補和提升。