張 曉,孫 超,王旻燕,陳文琴,曾 樂

（1.國家氣象信息中心，北京 100081；2.中國氣象局地球系統(tǒng)數(shù)值預報中心，北京 100081）

1 引言

氣象觀探測數(shù)據(jù)和產(chǎn)品是氣象業(yè)務、服務和科研的基礎[1]。目前國家氣象信息中心收集到的數(shù)據(jù)資源已經(jīng)超過43PB，年增量達到7PB。從20 世紀90年代開始，中國氣象局在氣象數(shù)據(jù)的科學管理及服務方面做了很多的工作，1992年開始探索建立氣象數(shù)據(jù)庫系統(tǒng)[2-3]，但功能單一且服務方式簡單，并未得到全部應用。2006年建設了國家級氣象數(shù)據(jù)存儲檢索系統(tǒng)（MDSS）[4]實現(xiàn)了對部分氣象數(shù)據(jù)的在線存儲管理。國家衛(wèi)星氣象中心建設了風云氣象衛(wèi)星數(shù)據(jù)存檔與服務系統(tǒng)[5]，對風云衛(wèi)星數(shù)據(jù)進行統(tǒng)一的管理。但上述這些研究主要解決的是氣象數(shù)據(jù)在存儲和管理方面的問題，并沒有切實解決氣象數(shù)據(jù)缺乏監(jiān)視的問題。直到2016年國家氣象信息中心建設的全國綜合氣象信息共享平臺（CIMISS）[6]開始業(yè)務化運行，才使得對于氣象數(shù)據(jù)的統(tǒng)一管理和監(jiān)視有進一步的發(fā)展，在此過程中，對于衛(wèi)星數(shù)據(jù)的存儲和服務模型進一步建立起來[7]，對衛(wèi)星數(shù)據(jù)的監(jiān)視提供了存儲和數(shù)據(jù)基礎。2017年起，為落實中國氣象局發(fā)展智慧氣象和全面推進氣象現(xiàn)代化的工作部署及“氣象綜合業(yè)務實時監(jiān)控系統(tǒng)”項目[8]推動下，氣象衛(wèi)星數(shù)據(jù)的監(jiān)視體系逐漸規(guī)范和完善起來。

衛(wèi)星遙感作為地球環(huán)境信息動態(tài)監(jiān)測的重要手段，獲取多光譜、多時相、多分辨率遙感資料，其應用領域越來越廣泛[9]。近年來，隨著衛(wèi)星遙感技術的發(fā)展以及國民經(jīng)濟的發(fā)展，不管是在防汛救災方面還是數(shù)值預報方面都對衛(wèi)星數(shù)據(jù)的需求日益增長。但由于全球氣象衛(wèi)星事業(yè)的快速發(fā)展，衛(wèi)星的種類越來越多，衛(wèi)星上所搭載的儀器種類也更加豐富。在業(yè)務需求的引領下，國家氣象信息中心作為國家級氣象數(shù)據(jù)中心和世界氣象組織全球信息系統(tǒng)中心（GISC），到目前為止正實時接收國內(nèi)外64 顆實時衛(wèi)星的資料，包括15 顆靜止衛(wèi)星以及49 顆極軌衛(wèi)星，這使得衛(wèi)星數(shù)據(jù)具有海量以及多源異構性的特點。

針對以上問題，借助于氣象綜合業(yè)務實時監(jiān)控系統(tǒng)[8]的項目支持，設計并實現(xiàn)了針對衛(wèi)星數(shù)據(jù)的監(jiān)視系統(tǒng)，利用文件名規(guī)則使得不同特性的衛(wèi)星數(shù)據(jù)能夠分開，并利用大數(shù)據(jù)技術搭建系統(tǒng)框架，實現(xiàn)衛(wèi)星數(shù)據(jù)分星、分儀器、甚至分產(chǎn)品進行監(jiān)視。

2 系統(tǒng)設計

2.1 總體設計

近些年，隨著氣象標準化、一體化的總體要求，國家氣象信息中心構建了氣象綜合業(yè)務實時監(jiān)控系統(tǒng)來監(jiān)控核心業(yè)務的狀態(tài)。氣象數(shù)據(jù)則是所有氣象業(yè)務的基礎，為了更好地保證氣象數(shù)據(jù)的準確、及時傳輸，對氣象數(shù)據(jù)的全生命周期監(jiān)控就顯得尤其重要。監(jiān)視系統(tǒng)主要是針對數(shù)據(jù)的收集、分發(fā)、處理入庫、同步等環(huán)節(jié)進行統(tǒng)一監(jiān)視，采集的指標如表1所示。

表1 數(shù)據(jù)全生命周期監(jiān)視指標

所有氣象數(shù)據(jù)按照氣象行業(yè)標準《氣象資料分類及編碼》[10]，以面向服務的維度建立了氣象數(shù)據(jù)四級分類體系（簡稱四級編碼），1 級劃分為14 大類，2 級為具有核心元數(shù)據(jù)定義的氣象數(shù)據(jù)集，3級為在2級分類下面向服務的數(shù)據(jù)子集，4級為數(shù)據(jù)流經(jīng)各業(yè)務環(huán)節(jié)的過程實體記錄[6]。通過建立數(shù)據(jù)血緣關系及衍生過程之間的實體數(shù)據(jù)的關聯(lián)關系，實現(xiàn)了數(shù)據(jù)上下游傳輸處理環(huán)節(jié)的對應流轉(zhuǎn)及處理過程的追蹤，業(yè)務監(jiān)控系統(tǒng)對重要氣象數(shù)據(jù)的收集、分發(fā)、處理入庫、同步等環(huán)節(jié)的完整性和及時性情況進行統(tǒng)計展示和自動告警。

系統(tǒng)整體架構可以分為采集層、緩沖層、處理層和存儲層，如圖1所示。

圖1 系統(tǒng)總體框架

采集層主要是采集各個業(yè)務環(huán)節(jié)的日志信息，這些日志信息是由數(shù)據(jù)傳輸?shù)牟煌h(huán)節(jié)發(fā)出并經(jīng)過處理之后的信息，存儲在ES 數(shù)據(jù)庫中，包括了數(shù)據(jù)在流轉(zhuǎn)過程中的詳細監(jiān)視信息（DI）和錯誤記錄（EI）。

由于衛(wèi)星數(shù)據(jù)的日志信息每天能夠產(chǎn)生1000 萬條，直接發(fā)送給處理層，會造成處理層的積壓，影響計算性能，因此設計了利用Kafka消息隊列的方式進行緩沖，數(shù)據(jù)先發(fā)送到Kafka消息隊列再發(fā)送到處理層進行統(tǒng)計計算。

處理層采用Spark Streaming來實現(xiàn)實時計算，進行監(jiān)視信息的預處理、監(jiān)視指標的計算以及告警計算。

存儲層負責存儲計算之后的數(shù)據(jù)：監(jiān)視指標存儲在ES庫中，告警信息存儲在MongDB 中。為了保證更好的用戶體驗以及系統(tǒng)性能，設計了redis 緩存機制，將計算結果在redis緩存中保存，前端界面讀取緩存中的數(shù)據(jù)進行展示。

2.2 模塊設計

衛(wèi)星數(shù)據(jù)監(jiān)視系統(tǒng)需要實時采集衛(wèi)星數(shù)據(jù)傳輸?shù)礁鱾€環(huán)節(jié)的監(jiān)視信息，并進行統(tǒng)計計算，將衛(wèi)星數(shù)據(jù)的到報和入庫情況簡明、清晰、直觀地展示出來。

衛(wèi)星數(shù)據(jù)監(jiān)視系統(tǒng)由配置模塊、統(tǒng)計模塊、告警模塊和展示模塊組成，各模塊功能結構及模塊劃分如圖2所示。

圖2 系統(tǒng)模塊結構圖

展示模塊面向的是用戶和運維人員，利用曲線圖和柱狀圖的方式全面展示衛(wèi)星數(shù)據(jù)從收集到處理入庫的情況，并能夠提供詳情查詢，供用戶和運維人員瀏覽詳細信息。展示界面利用手動觸發(fā)以及定時觸發(fā)的方式刷新數(shù)據(jù)，在兼顧性能的情況下，保證用戶和運維人員能夠看到最新數(shù)據(jù)的情況。

統(tǒng)計模塊在監(jiān)控庫中抽取衛(wèi)星數(shù)據(jù)收集、處理環(huán)節(jié)按照標準規(guī)范輸出的能夠反應衛(wèi)星數(shù)據(jù)完整性和及時性的詳細監(jiān)視信息（DI），根據(jù)配置模塊中定義的衛(wèi)星數(shù)據(jù)信息對DI進行統(tǒng)計分析，生成收集和入庫環(huán)節(jié)的文件數(shù)和文件大小以及及時率等關鍵性能指標。

告警模塊是對統(tǒng)計模塊計算出的關鍵性能指標進行閾值判斷，對超過閾值的關鍵性能指標按照標準規(guī)范輸出告警信息（EI），告警信息應簡單明了，可讀性強，能夠使得運維人員迅速定位問題。

配置模塊主要是實現(xiàn)衛(wèi)星數(shù)據(jù)的快速接入，此模塊依托氣象數(shù)據(jù)集核心元數(shù)據(jù)以及四級分類編碼所組成的氣象數(shù)據(jù)元[6]，利用基于消息中間件的同步技術，實現(xiàn)衛(wèi)星數(shù)據(jù)元數(shù)據(jù)的上下游各個環(huán)節(jié)的同步及統(tǒng)一管理。

3 系統(tǒng)信息處理

國外的衛(wèi)星數(shù)據(jù)由國際通信系統(tǒng)（GTS）接收，轉(zhuǎn)發(fā)給收集與分發(fā)系統(tǒng)，國內(nèi)衛(wèi)星數(shù)據(jù)由收集與分發(fā)系統(tǒng)直接接收。收集與分發(fā)系統(tǒng)在收到國內(nèi)外的衛(wèi)星數(shù)據(jù)后會對數(shù)據(jù)文件進行數(shù)據(jù)預處理（主要包括文件名和格式的檢查），將數(shù)據(jù)文件發(fā)送給處理入庫系統(tǒng)進行處理入庫（主要包括文件名轉(zhuǎn)換、解碼入庫等），文件實體放入共享文件區(qū)（NAS），為用戶提供文件服務。整個處理流程都由元數(shù)據(jù)及四級編碼貫穿始終，每個環(huán)節(jié)都會發(fā)送詳細監(jiān)視信息（DI）供監(jiān)視系統(tǒng)提取使用。衛(wèi)星數(shù)據(jù)的流轉(zhuǎn)過程如圖3所示。

圖3 氣象衛(wèi)星數(shù)據(jù)流程圖

下面詳細介紹對監(jiān)視信息的處理過程。

3.1 編碼及文件名規(guī)則匹配方法

由于目前對于衛(wèi)星數(shù)據(jù)的四級分類體系劃分的四級編碼不能滿足監(jiān)視的需求，按照氣象行業(yè)標準《氣象資料分類及編碼》[10]的規(guī)定并結合氣象行業(yè)標準《氣象衛(wèi)星數(shù)據(jù)文件名命名規(guī)范》[11]中對于衛(wèi)星數(shù)據(jù)文件名的規(guī)定對四級編碼體系進行了擴充。

為了適應數(shù)字化氣象數(shù)據(jù)的規(guī)范管理，中國氣象局發(fā)布了《氣象資料分類與編碼》行業(yè)標準，此規(guī)定氣象數(shù)據(jù)按照內(nèi)容屬性和來源屬性劃分為十四大類，各大類氣象數(shù)據(jù)按照其資料特性，選取內(nèi)容屬性、區(qū)域?qū)傩?、時間屬性、空間屬性、來源屬性、觀測屬性、格式屬性等的不同組合進行分類（二級分類）[10]。對于衛(wèi)星數(shù)據(jù)來說，第一級為K，表示衛(wèi)星數(shù)據(jù)，第二級應選取產(chǎn)品等級屬性、衛(wèi)星類別屬性、波段屬性、區(qū)域?qū)傩园聪群箜樞虻慕M合進行。在實際業(yè)務中，共定義了四級分類編碼，第三級為第二級基礎上面向服務的數(shù)據(jù)子集，第四級為流經(jīng)系統(tǒng)各個環(huán)節(jié)的實體記錄。由于這四級分類編碼無法表示所有衛(wèi)星數(shù)據(jù)特性，大部分表示的是衛(wèi)星類別屬性及產(chǎn)品類別，在前四級編碼無法修改的前提下，為了滿足監(jiān)視的需求，對四級編碼進行了擴充，定義了第五級編碼，第五級編碼為前四級編碼無法表示的其余衛(wèi)星數(shù)據(jù)特性，主要包括更詳細的衛(wèi)星數(shù)據(jù)信息，例如覆蓋范圍、儀器類型、空間分辨率等，這些更詳細的衛(wèi)星數(shù)據(jù)信息來源于通信系統(tǒng)中傳輸?shù)男l(wèi)星數(shù)據(jù)的文件名。

按照氣象行業(yè)標準《氣象衛(wèi)星數(shù)據(jù)文件名命名規(guī)范》的要求，氣象部門通信系統(tǒng)中傳輸?shù)臍庀髷?shù)據(jù)共分為三種類型的文件名：短格式文件名、基本格式文件名和完整格式文件名三種類型[11]，來適應存儲和應用的不同需求，但總體可以按照如下結構表示：Z_SATE_生產(chǎn)中心_系統(tǒng)接收時間_衛(wèi)星名稱_儀器名稱_數(shù)據(jù)區(qū)域類型_數(shù)據(jù)級別_可選信息字段標識符_[數(shù)據(jù)名稱_][儀器通道名稱_][投影方式_]觀測起始日期_觀測起始時間[_空間分辨率][_接收站名].數(shù)據(jù)格式。其中[]中為可選信息字段。在四級編碼基礎上，結合標準的文件名中的屬性信息的順序組合，就可以定義出衛(wèi)星數(shù)據(jù)的五級編碼，并保證每種衛(wèi)星數(shù)據(jù)對應唯一的五級編碼。利用此種方法就可以在不改變通信系統(tǒng)業(yè)務邏輯的基礎上，在監(jiān)視環(huán)節(jié)將衛(wèi)星數(shù)據(jù)分開監(jiān)視。

文件名規(guī)則與編碼匹配規(guī)則在配置模塊進行配置。

3.2 監(jiān)視信息預處理

數(shù)據(jù)預處理包括對詳細監(jiān)視信息（DI）的篩選和合法性檢查、時間規(guī)整、與配置信息關聯(lián)等，處理流程如圖4。

圖4 監(jiān)視信息預處理流程圖

1）監(jiān)視信息篩選及合法性檢查。檢查監(jiān)視信息是否符合業(yè)務規(guī)范，是否有效，是否能夠反映氣象數(shù)據(jù)的真實情況。提取出符合要求的監(jiān)視信息之后根據(jù)衛(wèi)星元數(shù)據(jù)信息以及四級編碼篩選出所需要監(jiān)視的衛(wèi)星數(shù)據(jù)的監(jiān)視信息。

2）時間規(guī)整。衛(wèi)星數(shù)據(jù)到報和入庫時間是不規(guī)整的，為了便于監(jiān)視，要對DI 中的時間進行規(guī)整，按照監(jiān)視的需求，當前是采用等間隔采樣法，將時間序列按照1 小時間隔進行切分，對時間序列進行規(guī)整。

3）文件名規(guī)則匹配。利用四級編碼對DI 信息進行初篩，對DI中包含的衛(wèi)星數(shù)據(jù)文件名進行分析，將衛(wèi)星特性字段進行提取組合，并關聯(lián)上第五級編碼。

4）關聯(lián)配置信息。將DI與配置信息相關聯(lián)，采用Rest API接口的方式，將配置模塊中配置的信息通過API接口進行對接。在配置模塊中配置了某一種衛(wèi)星數(shù)據(jù)的基礎信息，包括衛(wèi)星類型、儀器類型以及告警規(guī)則。

衛(wèi)星數(shù)據(jù)采集軟件從日志信息中采集到所需的監(jiān)控信息并經(jīng)過處理之后發(fā)送給Kafka集群。Kafka集群的Topic按照數(shù)據(jù)流轉(zhuǎn)環(huán)節(jié)和類型進行劃分，如收集環(huán)節(jié)詳細監(jiān)視信息的Topic、處理入庫環(huán)節(jié)詳細監(jiān)視信息的Topic 等，Consumer為數(shù)據(jù)處理環(huán)節(jié)的Spark Streaming計算環(huán)節(jié)訂閱接口。

Kafka是基于Zookeeper協(xié)調(diào)服務的分布式消息隊列系統(tǒng)，其核心功能為高吞吐量的發(fā)布-訂閱消息服務，主要應用于日志收集和消息隊列服務，可在廉價的商用機器上實現(xiàn)數(shù)據(jù)的高吞吐和高可用。Kafka消息隊列是由生產(chǎn)者Producer、消費者Consumer、代理者Broker和提供分布協(xié)調(diào)服務的Zookeeper組成。

Producer將消息推送到由若干Broker節(jié)點構成的Kafka集群，Kafka集群主要是用來存放接收的消息。Kafka中每組消息都對應一個主題（Topic），每個Topic 對應一個或多個分區(qū)（Partition），每個分區(qū)只能存在在一個Broker中。分區(qū)是由一系列消息組成，并且消息會不斷追加，為了標記消息，每條消息都會被分配一個連續(xù)的偏移量（Offset）。Consumer 訂閱消息之后會批量拉取數(shù)據(jù)，分區(qū)中消息的偏移量會隨之更新。

為了提高效率，設置了多個消費者批量拉取數(shù)據(jù)，并將Offset偏移量保存下來，來保證當系統(tǒng)出現(xiàn)故障恢復之后仍舊可以從故障前的位置繼續(xù)消費，保證了數(shù)據(jù)不會被丟失或者重復消費。

采用Rest API[12]接口的方式來進行各模塊間數(shù)據(jù)的調(diào)用，此種方式使得前后端分離，各模塊間相互獨立，數(shù)據(jù)通過URL進行傳遞。

3.3 監(jiān)視信息統(tǒng)計計算

對監(jiān)視信息進行預處理之后，就能夠得到規(guī)范化的監(jiān)視信息，通過分析衛(wèi)星數(shù)據(jù)的時效，圖5中展示了德國GNSS掩星數(shù)據(jù)時效情況，可以得知，衛(wèi)星數(shù)據(jù)由于其業(yè)務特性，會出現(xiàn)延遲到達的情況，并且數(shù)據(jù)到達的時間跨度大，因此設置程序每5 分鐘統(tǒng)計一次監(jiān)視指標，并在緩存中存儲8 個數(shù)據(jù)周期，能夠滿足大多數(shù)衛(wèi)星數(shù)據(jù)的監(jiān)視需求。

圖5 德國GNSS掩星數(shù)據(jù)時效情況

通過上述方法，既能夠保證衛(wèi)星數(shù)據(jù)的統(tǒng)計時效，又能夠保證前端能夠?qū)崟r獲取衛(wèi)星數(shù)據(jù)到報和入庫的情況。

監(jiān)視信息統(tǒng)計計算環(huán)節(jié)采用Spark Streaming 技術處理實時的監(jiān)視信息。

Spark Streaming的處理機制為：接收實時輸入的數(shù)據(jù)流，根據(jù)一定的時間間隔將數(shù)據(jù)流進行拆分，拆分后的數(shù)據(jù)會通過一個先進先出的隊列，Spark引擎會從該隊列中依次取出一個個批數(shù)據(jù)，并把批數(shù)據(jù)封裝成一個RDD，然后進行處理。

Spark Streaming 讀取Kafka 中的消息并進行解析處理，考慮到衛(wèi)星數(shù)據(jù)的時間跨度大，為了能夠獲取資料實時到報情況，會對每一種衛(wèi)星數(shù)據(jù)的同一個時次每5分鐘計算一次監(jiān)視指標，共統(tǒng)計8 個數(shù)據(jù)周期，計算得出的監(jiān)視指標會存在中間結果表中，每次計算之后的結果覆蓋歷史計算結果，通過這種方法保證遲到的衛(wèi)星數(shù)據(jù)也能夠覆蓋到。

3.4 告警生成

為了保證衛(wèi)星數(shù)據(jù)出現(xiàn)故障時能夠及時發(fā)現(xiàn)，及時處理，本監(jiān)視系統(tǒng)設計了告警模塊，利用配置模塊中配置的閾值對計算出的監(jiān)視指標進行判斷，對不符合告警閾值的監(jiān)視指標進行告警，配置模塊中配置的閾值通過Rest API 接口的方式進行傳遞，程序?qū)Ω婢撝颠M行判斷之后，生成規(guī)范的告警信息（EI），通過Rest API 接口的方式發(fā)送至統(tǒng)一的告警平臺進行告警信息的發(fā)布，告警信息（EI）需包括告警名稱、業(yè)務系統(tǒng)名稱、故障內(nèi)容、告警級別、事件類型、處理建議等內(nèi)容。

圖6 衛(wèi)星數(shù)據(jù)監(jiān)視系統(tǒng)監(jiān)視頁面簡圖

告警名稱：對告警的概要描述，應能夠清晰反映出該類告警的概況，主要格式為：〈數(shù)據(jù)流程描述〉〈每類數(shù)據(jù)流程下的具體環(huán)節(jié)業(yè)務名稱〉〈數(shù)據(jù)名稱〉〈業(yè)務時次〉〈性能指標名稱〉〈“異常”〉。例如：衛(wèi)星資料監(jiān)視入庫文件數(shù)告警，資料名稱：NOAA-18 微波探測裝置A 型AMSU-A 全球范圍45公里L1C級數(shù)據(jù)，告警時次：2022-05-28，00：00，入庫數(shù)異常。

業(yè)務系統(tǒng)名稱：發(fā)出告警的業(yè)務系統(tǒng)。例如：天鏡-衛(wèi)星數(shù)據(jù)監(jiān)視。

故障內(nèi)容：說明異常事件的細節(jié)，對異常事件中需要發(fā)布的可變內(nèi)容進行實例化描述。例如：衛(wèi)星資料監(jiān)視入庫文件數(shù)告警，告警時次：00|[-20：00，02：59)，資料編碼：K.0145.0001.S001.0004，資料名稱：NOAA-18 微波探測裝置A 型AMSU-A 全球范圍45 公里L1C 級數(shù)據(jù)，告警類型：應入庫數(shù)：3，實際入庫數(shù)：2。

告警級別：用于標識告警事件的嚴重程度，由重到輕，分為4 級（嚴重、關鍵、警告、恢復），由告警事件生產(chǎn)方按照自身業(yè)務特點以及對業(yè)務的影響程度等對告警級別進行設定。

事件類型：對納入統(tǒng)一管理的事件信息的分類與編碼，此編碼應是告警事件的唯一標識。

處理建議：針對告警事件的處理建議。一般包括具體聯(lián)系人電話，以及初步的排查建議。

由于衛(wèi)星數(shù)據(jù)是實時傳輸?shù)?，?shù)據(jù)到達時間跨度能夠到達8 小時，并且不會出現(xiàn)比觀測時間提前到達的情況，因此告警采用的是每5分鐘判斷一次指標，共判斷8個時次，并可根據(jù)實際情況對告警時間設置延后判斷時間。

通過上述策略發(fā)布告警之后，由于國外衛(wèi)星數(shù)據(jù)不穩(wěn)定等原因，業(yè)務上會出現(xiàn)告警過多的情況，為便于運維人員定位故障點，減少無效告警，對告警信息進行了合并。合并的原則是對告警名稱進行判斷，對同一時次相同環(huán)節(jié)，同一種數(shù)據(jù)的告警合并為1 條，只進行告警次數(shù)的累加和告警指標、告警時間的更新。

3.5 系統(tǒng)功能實現(xiàn)

監(jiān)控系統(tǒng)采用Spring MVC架構，Spring MVC架構提供了模型-視圖-控制的體系結構，松耦合的WEB應用程序組建使得開發(fā)更加靈活。MVC 架構使得輸入邏輯、業(yè)務邏輯以及前端UI邏輯分離，更加便于系統(tǒng)維護。

用戶通過WEB 頁面發(fā)送請求，此請求會轉(zhuǎn)交給前端控制器，前端控制器收到請求之后會根據(jù)請求信息以及配置信息找到處理該請求的具體的處理器并對這個處理器進行封裝，再利用統(tǒng)一的適配器接口調(diào)用處理器。同時，Spring MVC 會將請求信息轉(zhuǎn)換并入?yún)?，對入?yún)⒌膶ο髸M行格式化以及數(shù)據(jù)校驗等操作。在這些操作完成之后才會真正調(diào)用處理器來進行業(yè)務邏輯處理。處理器完成業(yè)務邏輯處理之后，會將邏輯視圖名和模型數(shù)據(jù)信息返回給前端控制器，再相應用戶。

展示界面利用手動觸發(fā)以及定時觸發(fā)的方式刷新數(shù)據(jù)，在兼顧性能的情況下，保證用戶和運維人員能夠看到最新數(shù)據(jù)的情況。

圖7 衛(wèi)星數(shù)據(jù)監(jiān)視系統(tǒng)配置頁面簡圖

配置模塊實現(xiàn)對不同衛(wèi)星、不同衛(wèi)星上掛載的不同儀器的定義，并根據(jù)衛(wèi)星數(shù)據(jù)的特征定義文件名規(guī)則及告警閾值等信息，使得衛(wèi)星數(shù)據(jù)能夠基于標準模板在線導入、注冊、編輯及新增修改等操作。

統(tǒng)計模塊將監(jiān)視的關鍵指標計算出來之后，告警模塊對這些關鍵指標進行閾值判斷，發(fā)出告警信息，在告警臺完成注冊之后就可以將告警發(fā)送到告警臺，實現(xiàn)集中監(jiān)視告警并可以配置微信通知等功能。表2展示的是關鍵告警項示例。

表2 關鍵告警項示例

4 結束語

本文結合業(yè)務中對衛(wèi)星數(shù)據(jù)監(jiān)視的需求以及不足設計并實現(xiàn)了衛(wèi)星數(shù)據(jù)監(jiān)視系統(tǒng)，采用Spring MVC 架構，并利用Kafka、Spark Streaming、Rest API 等大數(shù)據(jù)技術，實現(xiàn)了對衛(wèi)星數(shù)據(jù)的高效采集和處理，實現(xiàn)了衛(wèi)星數(shù)據(jù)的分星分儀器精細化監(jiān)視。目前，該系統(tǒng)已經(jīng)業(yè)務應用于中國氣象局實時監(jiān)視系統(tǒng)中，為數(shù)值預報等業(yè)務提供了快速發(fā)現(xiàn)故障的能力。未來，基于該系統(tǒng)的衛(wèi)星數(shù)據(jù)實時報表自動發(fā)布、對監(jiān)視數(shù)據(jù)的深度挖掘以及衛(wèi)星數(shù)據(jù)監(jiān)視向用戶端以及觀測端擴展將是研究重點，以此來推動對于氣象數(shù)據(jù)的全生命周期監(jiān)視能力。