基于分布式技術的氣象大數據共享服務系統設計與實現

雷 鳴 陳凱華 武國良 李慶博 李寶桐 姜罕盛

1(天津市氣象信息中心 天津 300074) 2(南京恩瑞特實業有限公司 江蘇 南京 210000)

0 引 言

全國綜合氣象信息共享系統(CIMISS)是由國家氣象信息中心于2009年組織建設，集數據收集、分發、處理、存儲和共享于一體。2013年，該系統推廣部署在全國各省級氣象數據中心，為各省級部門提供了良好的氣象數據服務和業務支撐[1-3]。

但是近年來，隨著氣象業務的不斷拓展以及數據量的不斷增加，現有省級CIMISS的數據處理能力已經顯得不足，特別是數據的響應速度和存儲能力，已無法滿足現有的數據服務要求。截至2019年，CIMISS系統存儲的氣象數據已經超過31億條，存儲的數據量已達46.5 TB，且仍以每天40.1萬條、62.2萬個文件、118.3 GB的數據量不斷增長。CIMISS的數據存儲能力已經無法滿足業務要求。

1 現狀與需求

目前，CIMISS業務應用系統間的數據交換和文件存儲，都是基于共享文件系統GPFS(General Parallel File System)實現，從而達到所有節點(在資源組內的)均能并行訪問整個文件系統。

支撐CIMISS系統運行的后臺則使用的是Oracle RAC數據庫、TonglinkQ消息中間件和MapGIS DCServer服務管理器，而其核心則是Oracle數據庫。對于地面、高空等結構化的氣象數據，Oracle透過數據表存儲其要素值[4-5]；對于數值模式產品、雷達資料等非結構化數據，Oracle則僅存儲文件對應的元數據和索引，再透過GPFS系統實現文件的存儲管理[6-8]。

現有氣象服務對數據的快速響應要求越來越高，而由于GPFS動態擴展能力較弱、Oracle RAC數據庫節點較少(省級僅2個)、硬件設備陳舊等諸多原因，導致現有CIMISS無法較好滿足氣象服務對數據的敏捷性要求，特別是在長序列歷史資料的影響上面。因此，對氣象業務，諸如天氣過程回溯分析、氣候預測等支撐能力不足[9-11]。

在今天的數字化時代，云計算、互聯網、社交媒體、大數據的發展使得數據量呈現爆炸式增長。傳統存儲在應對這些海量數據需求時，面臨著諸多挑戰，已經很難滿足不斷增長的數據需求，包括超大規模的橫向擴展、越來越高的性能要求、數據長期存儲的可靠性、統一資源池的管理、更低的TCO總體擁有成本等，而且傳統存儲的軟硬件緊耦合方式，也限制了硬件迭代的速度、選型的靈活性。

2 系統設計

隨著科學技術的發展，特別是大數據存儲技術的長足進步，涌現很多分布式技術的解決方案，并在相關行業取得了較好的效果[12-16]。

因此，考慮利用可靠成熟的分布式存儲技術，進行天津市氣象局氣象數據共享服務系統的設計與實現，如圖1所示。即通過分布式文件系統和分布式數據庫來分別提升氣象數據的儲存管理能力與數據的服務和支撐能力，并與CIMISS系統實現無縫對接。

圖1 天津市氣象局大數據中心物理架構

2.1 分布式文件系統

分布式文件系統(Hadoop Distributed File System，HDFS)被設計成適合運行在通用硬件上的文件系統。它與現有的分布式文件系統有很多共同點。但同時，它與其他分布式文件系統的區別也比較明顯。HDFS是一個高度容錯性的系統，適合部署在廉價的機器上。同時，因為HDFS放寬了一部分POSIX約束來實現流式讀取文件系統數據的目的，從而獲取數據訪問的高吞吐量，非常適合大規模數據集上的應用。它所具有的高容錯、高可靠性、高可擴展性、高獲得性、高吞吐率等特征為海量數據提供了不怕故障的存儲，為超大數據集的應用處理帶來了很多便利。

因此分布式文件系統可以有效解決數據存儲和管理的難題，將整個分布于不同網絡節點的數據資源統合成為一個高度集約化的數據中心[17-18]。從而極大便利業務應用系統的使用，而無須關心數據存儲在何處。

同時，透過網絡附屬存儲(Network Attached Storage，NAS)技術，提供數據共享服務。在NAS存儲結構中，存儲系統不再通過I/O總線附屬于某個特定的服務器或客戶機，而是直接通過網絡接口與網絡相連，便于用戶訪問或管理數據。NAS實際上是一個帶有瘦服務的存儲設備，能夠大大降低存儲設備的成本，并有效地保護數據。

2.2 分布式數據庫系統

分布式數據庫系統(DDBS)包含分布式數據庫管理系統(DDBMS)和分布式數據庫(DDB)。它將分布于不同的局部數據庫中存儲、由不同的DBMS進行管理、在不同的機器上運行、由不同的操作系統支持、被不同的通信網絡連接在一起的數據進行統合，形成一個邏輯上統一的數據庫。這與Oracle RAC共享緩存和磁盤機理不同，分布式數據庫將所有花銷分攤于網絡上多個節點，從而獲得更大的數據服務和存儲能力。而且分布式數據庫系統能方便地把一個新的節點納入系統，不影響現有系統的結構和系統的正常運行，提供了逐漸擴展系統能力的較好途徑，有時甚至是唯一的途徑[19-20]。

同時，所有數據的出入均通過CIMISS的氣象數據統一服務MUSIC接口(Meteorological Unified Service Interface Community)提供數據共享服務。因此，無論對于氣象數據用戶還是業務應用而言，均是無影響、無感知的。

氣象數據大致可以分為結構化和半/非結構化數據。前者數據結構化程度高，數據結構固定，如站點數據，故采用關系數據庫形式對此類數據進行存儲，簡化了數據存儲邏輯，有利于提高數據存取效率以及分析速度。考慮到數據中心需要存儲海量數據，故結構化數據需要在存儲集群內進行分庫分表存儲，以保障數據庫的并發性能。關系數據庫以數據來源(如雷達站、基準設備)進行分庫存儲，各個數據存儲節點采用GBase 8a、GBase 8t等高性能數據庫，保證在大數據場景下能夠實現數據的高效存取。

針對半/非結構化氣象數據，采用HBase分布式數據庫存儲和氣象數據分塊壓縮技術，進行氣象數據存儲和處理。數據分塊壓縮技術路線如圖2所示。

圖2 數據分塊壓縮技術路線

所涉及的各個數據庫和任務分工，如表1所示。

表1 天津市氣象局數據存儲分類表

2.3 數據架構設計

系統的數據架構設為四層結構，如圖3所示，分別為數據采集層、數據處理層、數據存儲層和數據服務層。

圖3 整體數據架構設計圖

(1) 數據采集層。在最底層的數據源層將數據主要分為站點數據、格點數據和產品數據三大類，依靠數據傳輸系統分別將數據傳輸至數據采集層，數據傳輸系統分別支持FTP、SFTP、HTTP、FILE四種數據通信協議，在傳輸過程中支持對數據的重命名、解壓縮處理等基本數據預處理功能。

(2) 數據處理層。數據采集層負責進行數據入庫前的站點數據以及格點數據標準化處理，同時按照存儲設計規范進行入庫。數據在數據采集層按照氣象業務分為結構化數據、文件數據、在線消息和日志及其他非標準數據四類，通過消息隊列緩存機制及多機集群配置進行統一數據分布式處理。數據經過清洗和解析按照基礎數據清洗規則、站點數據解析協議、格點數據解析協議、非結構化數據解析協議形成可入庫管理的數據流，通過數據存儲適配后，進入相應的數據存儲組件匯總，如圖4所示。

圖4 數據處理層數據流向

(3) 數據存儲層。在數據存儲層根據數據存取的頻繁度將數據分為冷數據和熱數據。

站點數據處理流程：通過實時解析到MySQL庫后，利用日志同步機制實時同步到GBase數據庫中。

格點數據處理流程：通過實時解析到HBase數據庫，通過將RowKey存儲Elasticsearch(ES)中實現快速尋址，快速獲取得到需要查詢的數據，提高對格點數據的查詢效率。

ES是一個實時的分布式搜索和分析引擎，可以快速處理大規模數據。常用于全文搜索、結構化搜索及分析，主要被用來存儲有聚合及篩選的熱數據，如：存儲近幾年的站點數據和格點數據索引，方便搜索及聚合查詢。

HDFS主要用作數據倉庫，存放格點數據文件的冷數據，即超過一年或不常用的數據。HDFS是分布式文件系統，應用它一次寫入、多次讀出的場景特性，當數據服務需要使用這部分冷數據時，可直接通過ES快速獲取文件找到對應數據解析后返回結果并存儲到HBase組件中。

Kafka主要用來實現熱數據的緩存，以減少數據處理過程中的緩存壓力。

為了有效應對氣象數據種類多、增長迅速的特點，將熱數據存儲層設為第一級，冷數據存儲設為第二級。同時，將超過1年的數據存儲在H3C中，設為第三級。利用H3C優秀的存儲性能進行存儲管理。

(4) 數據服務層。在數據服務層與MUSIC接口服務系統融合，通過統一的MUSIC接口提供對格點和站點數據的查詢、更新服務及實時數據的訂閱服務。

MUSIC是跨平臺、多語言、多協議，為應用系統提供直接支撐服務。它將多源的數據組合在一起，形成一個統一、規范的出口，提供服務。

通過接口(API)，實現應用與數據解耦，保障前端應用系統穩定，不受后端異構數據環境干擾、實現技術變化無影響。從而實現數據管理與應用分離，接口保持穩定不變。其結構示意圖如圖5所示。

圖5 MUSIC接口服務支撐架構

3 實踐與測試

目前，GBase數據庫中入庫了所有建站以來的數據，庫中共有155 281 334 700條記錄。為了檢驗系統性能，特針對站點結構化數據進行數據查詢的性能測試：發揮查詢聚合的性能，利用MPP并行數據庫優勢，使用分片分布式的特長，采用分治法計算長時間的數據聚合請求。分別統計天津各站點一定時間內的小時平均氣溫與累計降雨。各項性能如表2所示。

表2 站點數據查詢性能測試表

目前，CIMISS統計天津所有站點過去1年內的平均氣溫需要8.7 s，而通過GBase數據庫建設，統計過去1年平均氣溫大概需要1.1 s，性能比現有CIMISS提升7倍左右，而隨著數量的進一步增大，性能提升的優勢更加明顯，甚至高達22倍以上。

針對格點數據，為了提升查詢性能，特別使用ES作為數據檢索，發揮查詢聚合的性能；使用HBase作為點位數據存儲，發揮IO的性能；為了減少傳輸的時間，將JSON結果集數組化為相應的經緯度矩陣，將矩陣寫入.csv文件后壓縮成.tgz文件返回給前端。

通過模擬過去2個月歐洲中心全部數據，數據環境總大小約7 409 247 350個格點數，獲得如表3所示測試結果。

表3 格點數據查詢性能測試表

續表3

現狀對比：采用天津1 km網格6個月歷史數據進行性能測試，結果表明查詢數據可在0.3 s內到達應用終端，與格點數據在天津省局一體化平臺中的應用相比，性能提升了5倍左右。針對溫度和陣風的詳細查詢測試情況如圖6和圖7所示。

圖6 天津網格預報整點溫度查詢顯示

圖7 天津網格預報整點陣風查詢顯示

4 結 語

結合氣象業務需求，本文在不改變現有業務系統和系統架構的基礎上，實現與省級CIMISS系統的無縫對接，并通過原有CIMISS傳統氣象數據服務性能與現有分布式技術架構下的氣象數據服務性能的對比分析，可以明顯看到，基于分布式技術的氣象數據共享服務系統具有更卓越的優勢：數據聚合能力強，其并發性、安全性和可靠性更高。而且分布式存儲技術具有良好的橫向擴展能力，非常適合應用于數據范圍和數據維度隨著時間不斷增長的行業需求。

目前，作為有效支撐天津市省局CIMISS氣象數據服務系統的關鍵功能組件，分布式數據庫系統與分布式文件系統已經通過性能測試和功能測試，為數據服務實時性要求較高的氣象業務提供了有力保障，并隨著氣象業務的發展不斷完善和優化。