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

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

0 引 言

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

但是近年來，隨著氣象業(yè)務(wù)的不斷拓展以及數(shù)據(jù)量的不斷增加，現(xiàn)有省級(jí)CIMISS的數(shù)據(jù)處理能力已經(jīng)顯得不足，特別是數(shù)據(jù)的響應(yīng)速度和存儲(chǔ)能力，已無法滿足現(xiàn)有的數(shù)據(jù)服務(wù)要求。截至2019年，CIMISS系統(tǒng)存儲(chǔ)的氣象數(shù)據(jù)已經(jīng)超過31億條，存儲(chǔ)的數(shù)據(jù)量已達(dá)46.5 TB，且仍以每天40.1萬條、62.2萬個(gè)文件、118.3 GB的數(shù)據(jù)量不斷增長(zhǎng)。CIMISS的數(shù)據(jù)存儲(chǔ)能力已經(jīng)無法滿足業(yè)務(wù)要求。

1 現(xiàn)狀與需求

目前，CIMISS業(yè)務(wù)應(yīng)用系統(tǒng)間的數(shù)據(jù)交換和文件存儲(chǔ)，都是基于共享文件系統(tǒng)GPFS(General Parallel File System)實(shí)現(xiàn)，從而達(dá)到所有節(jié)點(diǎn)(在資源組內(nèi)的)均能并行訪問整個(gè)文件系統(tǒng)。

支撐CIMISS系統(tǒng)運(yùn)行的后臺(tái)則使用的是Oracle RAC數(shù)據(jù)庫、TonglinkQ消息中間件和MapGIS DCServer服務(wù)管理器，而其核心則是Oracle數(shù)據(jù)庫。對(duì)于地面、高空等結(jié)構(gòu)化的氣象數(shù)據(jù)，Oracle透過數(shù)據(jù)表存儲(chǔ)其要素值[4-5]；對(duì)于數(shù)值模式產(chǎn)品、雷達(dá)資料等非結(jié)構(gòu)化數(shù)據(jù)，Oracle則僅存儲(chǔ)文件對(duì)應(yīng)的元數(shù)據(jù)和索引，再透過GPFS系統(tǒng)實(shí)現(xiàn)文件的存儲(chǔ)管理[6-8]。

現(xiàn)有氣象服務(wù)對(duì)數(shù)據(jù)的快速響應(yīng)要求越來越高，而由于GPFS動(dòng)態(tài)擴(kuò)展能力較弱、Oracle RAC數(shù)據(jù)庫節(jié)點(diǎn)較少(省級(jí)僅2個(gè))、硬件設(shè)備陳舊等諸多原因，導(dǎo)致現(xiàn)有CIMISS無法較好滿足氣象服務(wù)對(duì)數(shù)據(jù)的敏捷性要求，特別是在長(zhǎng)序列歷史資料的影響上面。因此，對(duì)氣象業(yè)務(wù)，諸如天氣過程回溯分析、氣候預(yù)測(cè)等支撐能力不足[9-11]。

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

2 系統(tǒng)設(shè)計(jì)

隨著科學(xué)技術(shù)的發(fā)展，特別是大數(shù)據(jù)存儲(chǔ)技術(shù)的長(zhǎng)足進(jìn)步，涌現(xiàn)很多分布式技術(shù)的解決方案，并在相關(guān)行業(yè)取得了較好的效果[12-16]。

因此，考慮利用可靠成熟的分布式存儲(chǔ)技術(shù)，進(jìn)行天津市氣象局氣象數(shù)據(jù)共享服務(wù)系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)，如圖1所示。即通過分布式文件系統(tǒng)和分布式數(shù)據(jù)庫來分別提升氣象數(shù)據(jù)的儲(chǔ)存管理能力與數(shù)據(jù)的服務(wù)和支撐能力，并與CIMISS系統(tǒng)實(shí)現(xiàn)無縫對(duì)接。

圖1 天津市氣象局大數(shù)據(jù)中心物理架構(gòu)

2.1 分布式文件系統(tǒng)

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

因此分布式文件系統(tǒng)可以有效解決數(shù)據(jù)存儲(chǔ)和管理的難題，將整個(gè)分布于不同網(wǎng)絡(luò)節(jié)點(diǎn)的數(shù)據(jù)資源統(tǒng)合成為一個(gè)高度集約化的數(shù)據(jù)中心[17-18]。從而極大便利業(yè)務(wù)應(yīng)用系統(tǒng)的使用，而無須關(guān)心數(shù)據(jù)存儲(chǔ)在何處。

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

2.2 分布式數(shù)據(jù)庫系統(tǒng)

分布式數(shù)據(jù)庫系統(tǒng)(DDBS)包含分布式數(shù)據(jù)庫管理系統(tǒng)(DDBMS)和分布式數(shù)據(jù)庫(DDB)。它將分布于不同的局部數(shù)據(jù)庫中存儲(chǔ)、由不同的DBMS進(jìn)行管理、在不同的機(jī)器上運(yùn)行、由不同的操作系統(tǒng)支持、被不同的通信網(wǎng)絡(luò)連接在一起的數(shù)據(jù)進(jìn)行統(tǒng)合，形成一個(gè)邏輯上統(tǒng)一的數(shù)據(jù)庫。這與Oracle RAC共享緩存和磁盤機(jī)理不同，分布式數(shù)據(jù)庫將所有花銷分?jǐn)傆诰W(wǎng)絡(luò)上多個(gè)節(jié)點(diǎn)，從而獲得更大的數(shù)據(jù)服務(wù)和存儲(chǔ)能力。而且分布式數(shù)據(jù)庫系統(tǒng)能方便地把一個(gè)新的節(jié)點(diǎn)納入系統(tǒng)，不影響現(xiàn)有系統(tǒng)的結(jié)構(gòu)和系統(tǒng)的正常運(yùn)行，提供了逐漸擴(kuò)展系統(tǒng)能力的較好途徑，有時(shí)甚至是唯一的途徑[19-20]。

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

氣象數(shù)據(jù)大致可以分為結(jié)構(gòu)化和半/非結(jié)構(gòu)化數(shù)據(jù)。前者數(shù)據(jù)結(jié)構(gòu)化程度高，數(shù)據(jù)結(jié)構(gòu)固定，如站點(diǎn)數(shù)據(jù)，故采用關(guān)系數(shù)據(jù)庫形式對(duì)此類數(shù)據(jù)進(jìn)行存儲(chǔ)，簡(jiǎn)化了數(shù)據(jù)存儲(chǔ)邏輯，有利于提高數(shù)據(jù)存取效率以及分析速度?？紤]到數(shù)據(jù)中心需要存儲(chǔ)海量數(shù)據(jù)，故結(jié)構(gòu)化數(shù)據(jù)需要在存儲(chǔ)集群內(nèi)進(jìn)行分庫分表存儲(chǔ)，以保障數(shù)據(jù)庫的并發(fā)性能。關(guān)系數(shù)據(jù)庫以數(shù)據(jù)來源(如雷達(dá)站、基準(zhǔn)設(shè)備)進(jìn)行分庫存儲(chǔ)，各個(gè)數(shù)據(jù)存儲(chǔ)節(jié)點(diǎn)采用GBase 8a、GBase 8t等高性能數(shù)據(jù)庫，保證在大數(shù)據(jù)場(chǎng)景下能夠?qū)崿F(xiàn)數(shù)據(jù)的高效存取。

針對(duì)半/非結(jié)構(gòu)化氣象數(shù)據(jù)，采用HBase分布式數(shù)據(jù)庫存儲(chǔ)和氣象數(shù)據(jù)分塊壓縮技術(shù)，進(jìn)行氣象數(shù)據(jù)存儲(chǔ)和處理。數(shù)據(jù)分塊壓縮技術(shù)路線如圖2所示。

圖2 數(shù)據(jù)分塊壓縮技術(shù)路線

所涉及的各個(gè)數(shù)據(jù)庫和任務(wù)分工，如表1所示。

表1 天津市氣象局?jǐn)?shù)據(jù)存儲(chǔ)分類表

2.3 數(shù)據(jù)架構(gòu)設(shè)計(jì)

系統(tǒng)的數(shù)據(jù)架構(gòu)設(shè)為四層結(jié)構(gòu)，如圖3所示，分別為數(shù)據(jù)采集層、數(shù)據(jù)處理層、數(shù)據(jù)存儲(chǔ)層和數(shù)據(jù)服務(wù)層。

圖3 整體數(shù)據(jù)架構(gòu)設(shè)計(jì)圖

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

(2) 數(shù)據(jù)處理層。數(shù)據(jù)采集層負(fù)責(zé)進(jìn)行數(shù)據(jù)入庫前的站點(diǎn)數(shù)據(jù)以及格點(diǎn)數(shù)據(jù)標(biāo)準(zhǔn)化處理，同時(shí)按照存儲(chǔ)設(shè)計(jì)規(guī)范進(jìn)行入庫。數(shù)據(jù)在數(shù)據(jù)采集層按照氣象業(yè)務(wù)分為結(jié)構(gòu)化數(shù)據(jù)、文件數(shù)據(jù)、在線消息和日志及其他非標(biāo)準(zhǔn)數(shù)據(jù)四類，通過消息隊(duì)列緩存機(jī)制及多機(jī)集群配置進(jìn)行統(tǒng)一數(shù)據(jù)分布式處理。數(shù)據(jù)經(jīng)過清洗和解析按照基礎(chǔ)數(shù)據(jù)清洗規(guī)則、站點(diǎn)數(shù)據(jù)解析協(xié)議、格點(diǎn)數(shù)據(jù)解析協(xié)議、非結(jié)構(gòu)化數(shù)據(jù)解析協(xié)議形成可入庫管理的數(shù)據(jù)流，通過數(shù)據(jù)存儲(chǔ)適配后，進(jìn)入相應(yīng)的數(shù)據(jù)存儲(chǔ)組件匯總，如圖4所示。

圖4 數(shù)據(jù)處理層數(shù)據(jù)流向

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

站點(diǎn)數(shù)據(jù)處理流程：通過實(shí)時(shí)解析到MySQL庫后，利用日志同步機(jī)制實(shí)時(shí)同步到GBase數(shù)據(jù)庫中。

格點(diǎn)數(shù)據(jù)處理流程：通過實(shí)時(shí)解析到HBase數(shù)據(jù)庫，通過將RowKey存儲(chǔ)Elasticsearch(ES)中實(shí)現(xiàn)快速尋址，快速獲取得到需要查詢的數(shù)據(jù)，提高對(duì)格點(diǎn)數(shù)據(jù)的查詢效率。

ES是一個(gè)實(shí)時(shí)的分布式搜索和分析引擎，可以快速處理大規(guī)模數(shù)據(jù)。常用于全文搜索、結(jié)構(gòu)化搜索及分析，主要被用來存儲(chǔ)有聚合及篩選的熱數(shù)據(jù)，如：存儲(chǔ)近幾年的站點(diǎn)數(shù)據(jù)和格點(diǎn)數(shù)據(jù)索引，方便搜索及聚合查詢。

HDFS主要用作數(shù)據(jù)倉庫，存放格點(diǎn)數(shù)據(jù)文件的冷數(shù)據(jù)，即超過一年或不常用的數(shù)據(jù)。HDFS是分布式文件系統(tǒng)，應(yīng)用它一次寫入、多次讀出的場(chǎng)景特性，當(dāng)數(shù)據(jù)服務(wù)需要使用這部分冷數(shù)據(jù)時(shí)，可直接通過ES快速獲取文件找到對(duì)應(yīng)數(shù)據(jù)解析后返回結(jié)果并存儲(chǔ)到HBase組件中。

Kafka主要用來實(shí)現(xiàn)熱數(shù)據(jù)的緩存，以減少數(shù)據(jù)處理過程中的緩存壓力。

為了有效應(yīng)對(duì)氣象數(shù)據(jù)種類多、增長(zhǎng)迅速的特點(diǎn)，將熱數(shù)據(jù)存儲(chǔ)層設(shè)為第一級(jí)，冷數(shù)據(jù)存儲(chǔ)設(shè)為第二級(jí)。同時(shí)，將超過1年的數(shù)據(jù)存儲(chǔ)在H3C中，設(shè)為第三級(jí)。利用H3C優(yōu)秀的存儲(chǔ)性能進(jìn)行存儲(chǔ)管理。

(4) 數(shù)據(jù)服務(wù)層。在數(shù)據(jù)服務(wù)層與MUSIC接口服務(wù)系統(tǒng)融合，通過統(tǒng)一的MUSIC接口提供對(duì)格點(diǎn)和站點(diǎn)數(shù)據(jù)的查詢、更新服務(wù)及實(shí)時(shí)數(shù)據(jù)的訂閱服務(wù)。

MUSIC是跨平臺(tái)、多語言、多協(xié)議，為應(yīng)用系統(tǒng)提供直接支撐服務(wù)。它將多源的數(shù)據(jù)組合在一起，形成一個(gè)統(tǒng)一、規(guī)范的出口，提供服務(wù)。

通過接口(API)，實(shí)現(xiàn)應(yīng)用與數(shù)據(jù)解耦，保障前端應(yīng)用系統(tǒng)穩(wěn)定，不受后端異構(gòu)數(shù)據(jù)環(huán)境干擾、實(shí)現(xiàn)技術(shù)變化無影響。從而實(shí)現(xiàn)數(shù)據(jù)管理與應(yīng)用分離，接口保持穩(wěn)定不變。其結(jié)構(gòu)示意圖如圖5所示。

圖5 MUSIC接口服務(wù)支撐架構(gòu)

3 實(shí)踐與測(cè)試

目前，GBase數(shù)據(jù)庫中入庫了所有建站以來的數(shù)據(jù)，庫中共有155 281 334 700條記錄。為了檢驗(yàn)系統(tǒng)性能，特針對(duì)站點(diǎn)結(jié)構(gòu)化數(shù)據(jù)進(jìn)行數(shù)據(jù)查詢的性能測(cè)試：發(fā)揮查詢聚合的性能，利用MPP并行數(shù)據(jù)庫優(yōu)勢(shì)，使用分片分布式的特長(zhǎng)，采用分治法計(jì)算長(zhǎng)時(shí)間的數(shù)據(jù)聚合請(qǐng)求。分別統(tǒng)計(jì)天津各站點(diǎn)一定時(shí)間內(nèi)的小時(shí)平均氣溫與累計(jì)降雨。各項(xiàng)性能如表2所示。

表2 站點(diǎn)數(shù)據(jù)查詢性能測(cè)試表

目前，CIMISS統(tǒng)計(jì)天津所有站點(diǎn)過去1年內(nèi)的平均氣溫需要8.7 s，而通過GBase數(shù)據(jù)庫建設(shè)，統(tǒng)計(jì)過去1年平均氣溫大概需要1.1 s，性能比現(xiàn)有CIMISS提升7倍左右，而隨著數(shù)量的進(jìn)一步增大，性能提升的優(yōu)勢(shì)更加明顯，甚至高達(dá)22倍以上。

針對(duì)格點(diǎn)數(shù)據(jù)，為了提升查詢性能，特別使用ES作為數(shù)據(jù)檢索，發(fā)揮查詢聚合的性能；使用HBase作為點(diǎn)位數(shù)據(jù)存儲(chǔ)，發(fā)揮IO的性能；為了減少傳輸?shù)臅r(shí)間，將JSON結(jié)果集數(shù)組化為相應(yīng)的經(jīng)緯度矩陣，將矩陣寫入.csv文件后壓縮成.tgz文件返回給前端。

通過模擬過去2個(gè)月歐洲中心全部數(shù)據(jù)，數(shù)據(jù)環(huán)境總大小約7 409 247 350個(gè)格點(diǎn)數(shù)，獲得如表3所示測(cè)試結(jié)果。

表3 格點(diǎn)數(shù)據(jù)查詢性能測(cè)試表

續(xù)表3

現(xiàn)狀對(duì)比：采用天津1 km網(wǎng)格6個(gè)月歷史數(shù)據(jù)進(jìn)行性能測(cè)試，結(jié)果表明查詢數(shù)據(jù)可在0.3 s內(nèi)到達(dá)應(yīng)用終端，與格點(diǎn)數(shù)據(jù)在天津省局一體化平臺(tái)中的應(yīng)用相比，性能提升了5倍左右。針對(duì)溫度和陣風(fēng)的詳細(xì)查詢測(cè)試情況如圖6和圖7所示。

圖6 天津網(wǎng)格預(yù)報(bào)整點(diǎn)溫度查詢顯示

圖7 天津網(wǎng)格預(yù)報(bào)整點(diǎn)陣風(fēng)查詢顯示

4 結(jié) 語

結(jié)合氣象業(yè)務(wù)需求，本文在不改變現(xiàn)有業(yè)務(wù)系統(tǒng)和系統(tǒng)架構(gòu)的基礎(chǔ)上，實(shí)現(xiàn)與省級(jí)CIMISS系統(tǒng)的無縫對(duì)接，并通過原有CIMISS傳統(tǒng)氣象數(shù)據(jù)服務(wù)性能與現(xiàn)有分布式技術(shù)架構(gòu)下的氣象數(shù)據(jù)服務(wù)性能的對(duì)比分析，可以明顯看到，基于分布式技術(shù)的氣象數(shù)據(jù)共享服務(wù)系統(tǒng)具有更卓越的優(yōu)勢(shì)：數(shù)據(jù)聚合能力強(qiáng)，其并發(fā)性、安全性和可靠性更高。而且分布式存儲(chǔ)技術(shù)具有良好的橫向擴(kuò)展能力，非常適合應(yīng)用于數(shù)據(jù)范圍和數(shù)據(jù)維度隨著時(shí)間不斷增長(zhǎng)的行業(yè)需求。

目前，作為有效支撐天津市省局CIMISS氣象數(shù)據(jù)服務(wù)系統(tǒng)的關(guān)鍵功能組件，分布式數(shù)據(jù)庫系統(tǒng)與分布式文件系統(tǒng)已經(jīng)通過性能測(cè)試和功能測(cè)試，為數(shù)據(jù)服務(wù)實(shí)時(shí)性要求較高的氣象業(yè)務(wù)提供了有力保障，并隨著氣象業(yè)務(wù)的發(fā)展不斷完善和優(yōu)化。