梁寶龍,崔學林,謝寒生,賀永興,李晉峰
(1.海南省氣象信息中心,海南 海口 5702032.海南省南海氣象防災減災重點實驗室,海南 海口 5702033.海南省氣象信息化科技團隊,海南 海口 570203)
隨著氣象服務的廣泛傳播,氣象天氣預報、災害預警等服務也越來越受到廣大民眾的關注。特別是在臺風、特大暴雨等重大天氣過程中,氣象部門的預報預警信息及時傳播與公眾的防災減災息息相關。如何讓公眾快速地了解當前的天氣情況和未來天氣的預報,除了常規的電視播報、手機短信和市、縣、村等室外廣播大喇叭等方式外,實時地將氣象數據傳輸到海南省防汛防風防旱總指揮部辦公室(簡稱省三防辦)等政府門戶網站實時展示,也為公眾了解氣象服務提供了更廣泛的途徑。通過氣象數據的實時推送與更新,民眾可以通過權威的政府部門提供的平臺(如網站或者手機客戶端等)了解實時的天氣情況,同時也為管理部門的防災減災決策提供氣象實況依據。
數據的傳輸有很多方式,近年來也有很多有指導性的工作[1-5]。分別對遠程文件同步進行了相關的研究工作[6-8],有的針對遠程文件同步[9-10],有的基于RSYNC[11-13]算法的同步系統,均是對文件的同步與同步算法優化的研究,但這些研究僅僅針對的是文件的同步,沒有結合文件數據與數據庫表同步。
在上述研究的基礎上,根據氣象行業常用實時觀測數據的共享及同步情況,將文件同步和數據庫表的同步相結合,設計并實現了基于多源氣象數據的快速推送系統。該系統整合不同數據源的氣象數據到一個統一平臺,其中將多源氣象數據分為結構化氣象數據和非結構化數據并快速推送,實現對不同數據源的氣象數據的實時推送。該系統的主要功能是氣象部門為省三防辦等政府部門提供實時的氣象數據推送,實時地將氣象觀測數據實況、氣象預報服務產品等數據推送到政府部門的業務應用服務器中,為當地的政府部門防災減災決策提供氣象數據基礎支撐。
(1)時效性。
氣象數據的數據傳輸涉及到業務考核,時效性要求很高,要求各類考核的氣象觀測數據在考核時間內傳輸完畢。推送的時效需要在滿足業務要求的前提下,盡快完成推送任務。各類數據的推送,必須在采集完畢之后在規定的時間內完成推送工作。
(2)可擴展性。
系統推送的設計方面,盡可能考慮到將來業務的變化情況,保證將來有新的資料推送需求時,在滿足現有推送任務的前提下,能靈活配置推送策略滿足推送需求變更。
(3)安全性。
系統建立在安全可靠的網絡安全措施之上,確保系統軟硬件及系統中的數據受到保護,不因偶然的或者惡意的原因而遭受到破壞、更改、泄露,實現系統連續可靠正常的運行,網絡服務不中斷,推送系統和接收端之間的通信安全可靠。
(4)易用性。
推送的策略可以通過圖形界面進行推送策略配置,操作步驟可視化,操作方法簡單易學。
各類氣象數據收集分布在不同的業務系統中,為了更好地進行控制推送的集中管理,文中對各業務系統中的數據服務器進行訪問權限配置,推送服務器的訪問權限可以讀取所有業務服務器的數據存儲目錄和文件,便于訪問獲取數據。同樣地,對于實時觀測要素數據庫的服務器,推送服務器對數據庫有讀寫訪問權限。依據氣象數據推送業務的需求,將推送系統功能規劃為三個子模塊,分別為數據收集存儲模塊、數據推送服務器模塊、數據接收服務器模塊,如圖1所示。

圖1 推送系統結構
推送系統設計主要分為數據收集存儲、數據推送服務、數據接收存儲三個模塊的設計。
(1)數據收集存儲模塊。
該模塊功能是數據源整合的部分,包括常規觀測報文收集服務器,預報文件服務器,雷達圖片、云圖圖片服務器等中心站業務服務器。各業務中心站負責一種業務的運行,并保障數據的及時收集和存儲。收集存儲的各服務器并行執行各自的收集及存儲任務,業務之間相互不干涉,極個別業務的暫時中斷不影響其他業務數據收集存儲的獨立運轉。該模塊的主要功能是對報文要素解析入庫,文件數據加工處理,預報產品文件存儲,雷達云圖產品的加工并處理成JPG圖片文件格式存儲。
(2)數據推送服務器模塊。
數據推送服務器模塊的設計,通過開發一個多任務平臺,實時地將數據收集模塊的各類數據同步到接收服務器的指定存儲目錄中。推送服務器作為數據推送系統的關鍵模塊,對內聯系局域網數據收集模塊中的各節點服務器,對外負責實時將各類數據推送到省三防辦的接收前置機中。分別對推送數據的各類中心站數據服務器進行配置,使得資料推送服務器可以獲取需要推送的各類數據的讀寫訪問權限,獲取推送的數據的存放目錄及文件讀取訪問權限。
(3)數據接收服務器模塊。
數據接收服務器模塊,其存儲目錄和數據庫表結構與推送服務器的存儲結構一一對應,并且推送服務器對接收服務器的各推送目錄均有讀寫訪問權限。接收服務器及時處理推送服務器推送過來的數據,并定時清理過時數據文件。
在系統推送設計中,數據接收服務器模塊是氣象業務外網物理隔離的節點。基于網絡安全的考慮,通過網絡防火墻等安全設備的設置,氣象局域網的推送服務器是唯一能跟省三防辦對端接收前置機通信的服務器,它們之間的通信是點對點的。氣象內網的數據收集服務器均與接收前置機服務器物理隔離,相互之間網絡訪問不可達。同樣,接收前置機也不能訪問氣象內網的其他業務中心站服務器。
對于氣象數據的推送,文中分別針對非結構化和結構化數據的特點,分為兩種方式實現。對于非結構化的氣象數據,例如雷達產品、氣象云圖的以文件形式存在的數據,是以共享目錄拷貝的方式實現數據的實時同步,同步的策略是根據觀測數據的生成規則,以及數據的觀測時效和數據文件生成結束的時間來判定。例如雷達產品,推送策略是在雷達產品的生成之后立即將雷達數據推送至接受服務器的對應目錄中,并將已推送數據的文件名入庫,避免再次拷貝時的重復推送。
多源氣象數據推送系統分別對不同的來源數據做不同的推送響應,有的數據可直接推送,有的數據需要經過加工成產品后再推送,有的數據需要臨時處理、轉存等步驟之后推送。數據推送系統的推送過程如圖2所示,分別包括數據收集、收集處理、數據臨時存檔、推送處理、數據推送、推送控制策略等。

圖2 系統推送過程
數據的收集,是對各類氣象數據的收集整合,包括即將推送的結構化和非結構化氣象數據。收集處理,是指需要對原始資料加工成產品之后再推送的數據,例如雷達圖和衛星云圖等數據。數據臨時存檔,是指推送時需要本地臨時存儲數據,以便推送中出現異常后,恢復時繼續之前的推送任務。推送處理,是指對收集處理之后的數據和臨時存檔的數據進行處理,確保每一類數據的順利推送。數據推送,是指直接將多源的各類氣象數據實時推送到接收前置機中。推送控制策略,是指對每一類數據的推送方式和推送時效的觸發控制,達到對每一類數據推送指令的配置目的,實現對每一類數據推送策略的配置與管理。
可推送的非結構化常規氣象數據有:單站雷達回波圖、降雨預報分布圖、衛星云圖、氣溫分布圖、旱情分布圖、預報信息、決策氣象服務、氣候分析、生活氣象等。其中,以JPG圖片等文件格式推送的氣象數據有雷達回波圖、降雨預報圖、衛星云圖、氣溫分布圖;以WORD或者PDF格式文件形式推送的有決策氣象服務稿件、氣候分析和生活氣象等。
非結構化數據對的推送是以文件形式推送到指定的服務器的指定目錄中,具體的推送策略符合《全國氣象數據傳輸質量考核辦法》的要求,以氣象觀測數據的傳輸考核時效和觀測數據生成時間為依據。對于觀測時效比較規律的數據,設置好推送主機和接收服務器的同步時間,計算并判斷好觀測數據生成的時間,一旦當前觀測過程結束并生成觀測數據,立即觸發推送策略響應,將當前生成的最新觀測數據推送到接收服務器指定的目錄中,實現數據的實時推送。
對于結構化氣象數據的推送,文中選擇的是數據庫表要素的實時同步。筆者認為對數據庫表的實時同步,是對結構化氣象數據實時展示的時效要求和數據出口一致性的,比較符合氣象要素實時展示的常用方法。結構化的數據推送,在省三防辦等部門網站的實時顯示是通過讀取數據庫表要素實時更新展示的,文中方法是將氣象實時收集數據入庫的數據庫表要素直接同步到對端的數據庫表中。根據每一類數據的觀測時效來定義數據庫表同步的策略,按類型劃分數據時效實現結構化數據的實時同步。這些同步方式可以通過增量的方式同步,也可使用外部的數據庫管理工具實現。在數據寫入過程中,同時遵循數據庫事務的ACID[14-15]四個特性,確保數據庫寫入的表要素一一對應和表結構要素的完整性,確保氣象數據要素展示的結果唯一。
開發平臺:eclipse;數據庫:Oracle 11g;Web應用服務器:apache-tomcat-7.0.57;數據庫中間件:JPA(Java persistence API);實現Web層:Web2.0、Struts2、jQuery;推送服務器的操作系統:Windows Server 2012 R2。
多源氣象數據的推送系統,針對每一類數據配置相對應的策略,實現每一類數據的推送獨立運行且互不干涉。非結構化的數據推送將本地文件數據直接推送到接收服務器的對應目錄。結構化數據的推送,選擇數據庫同步的常用數據庫中間件實現。推送系統策略配置如圖3所示。每一類推送策略都可以通過Web配置修改,一般可選的推送策略根據氣象數據的采集時次分別定義“全部”、“整點”、“非整點”等配置選項。“全部”選項表示所有數據均推送,“整點”選項表示只推送每個小時整點的數據,“非整點”選項表示只推送可選非整點的數據。推送策略可根據觀測數據的時效自行定義和實現。
為了實時監控推送記錄和配置推送策略,將每一數據的推送記錄存入數據庫,記錄推送IP地址、推送文件名、推送的時間、推送目的主機地址和推送數據記錄等詳細信息,推送策略可通過Web監控平臺配置,從而實現推送數據的實時監控。推送日志查詢見圖4,實現推送的全流程監控。

圖3 系統推送策略配置

圖4 系統推送日志
較以往三防辦等部門通過氣象內網獲取氣象數據的方式,多源氣象數據實時推送系統正式上線以后,數據推送到省三防辦等部門的時效性也明顯提高。筆者對比了幾類氣象數據,即自動站、雨量站、雷達資料、國家級站、土壤水分,其資料推送時效分析如圖5所示。
在該實時推送系統中,自動站、雨量站、雷達資料、國家級站、土壤水分等數據推送時效均在資料到達后三分鐘以內推送到對端接收前置服務器中,較短的時間是自動站和國家級站,分別是資料到達后128 s內推送到接收前置機的數據庫表中。傳統的傳輸方式使得數據獲取時效比較慢,原因可能是氣象數據源分布在不同的觀測系統中,數據分別分散地存儲在不同服務器中,獲取數據前沒有對數據進行有效的整合和預處理困難等等。

圖5 傳輸時效對比
推送系統實現后,通過預先整合各類氣象數據源到一個統一的平臺,對數據進行推送預處理并按需定制策略推送,這樣優化了數據推送環節,有效保障了數據的推送時效。同時也可根據業務擴展實現推送資料的種類定制推送,對每一類數據的推送方式和推送時效的觸發控制,達到對每一類數據推送指令的配置目的,實現對每一類數據推送策略的配置與管理,提高了傳輸時效。
從氣象數據共享的方式,設計并實現了氣象數據的快速推送系統,并在海南省氣象局的內網中實現了對省三防辦所需的氣象數據的實時推送,為海南當地的氣象服務提供了便捷高效的氣象資料推送服務。該系統上線以來,在強臺風、暴雨等重大天氣過程中,發揮了積極的作用。下一步,將開發多策略預訂等推送服務,不斷完善系統功能,提供更高時效性的氣象數據推送服務,為海南的經濟發展和海南氣象服務貢獻一份綿薄之力。