雷 鳴 姜罕盛 武國良 趙玉娟
(天津市氣象信息中心 天津 300074)
隨著大數據技術的興起,以及分布式技術的不斷發展,當前數據服務的水平也水漲船高,服務能力獲得了極大的提升,但目前氣象系統的數據服務能力卻仍然處于較為落后的局面[1~3]。這主要集中體現在:業務系統集成度不夠、服務產品質量不高,而且服務渠道相對比較分散,IT 資源重復建設,集約化程度處于一個較低的水平,缺乏統一的業務數據和產品共享平臺,導致服務效率低下,產品和數據存在不一致,甚至是彼此矛盾沖突的情況,“信息孤島”現象依然存在[4]。此外,目前氣象系統由于缺乏頂層設計和規劃而導致各系統功能全、規模小、安全防衛力不足,難以完成規模化、集約化運維,從而導致重復高、人力多等高成本、低水平的IT系統運維。
基于以上原因,利用大數據相關技術[5~6],按照集約化發展思路建設天津氣象大數據共享網,構架天津省級氣象數據服務中心。整合各部門相關業務系統,升級完善數據存儲環境,提供一個能夠在線實時瀏覽、查詢和集預報預警、實時監測、歷史氣候資料與信息管理等于一體的、綜合顯示業務信息共享平臺,有效幫助業務人員能夠敏捷快速有效地獲取各類業務信息,助力業務服務。形成氣象系統內部統一的氣象業務集約化信息綜合顯示平臺,滿足市、區兩級業務和管理用戶服務支撐,實現市、區兩級用戶信息共享和一站式在線訪問[7]。同時,透過全國氣象數據統一服務接口(Meteorological Unified Service Interface Community,MUSIC)[8~10],整合本地數據中心與省級CIMISS 數據源,對外提供標準的全國統一數據訪問服務和應用編程接口(API),構建無縫連接的數據服務中心。
基本軟硬件平臺基于氣象專有云平臺建設,包含基本軟硬件平臺(服務器、存儲、網絡、操作系統、數據庫軟件)和應用軟件部分兩部分,部署在氣象基礎設施集約化平臺。
應用軟件由前端共享服務應用系統和后端數據處理與存儲管理系統組成。前端共享服務應用,可供市、區兩級用戶訪問,前端、后端應用系統均基于氣象專有云平臺,由若干虛擬機組成服務器群。
前端的共享服務應用系統,部署在虛擬服務器上,包括FTP 服務、WEB 應用、API 應用,為了有效解決高并發下的數據分流,特別在前端部署負載均衡設備,以便于進行相關任務調度。
天津氣象大數據共享網的硬件主要由兩部分構成:物理機和虛擬機,共計25 臺機器,物理機7臺。而物理機包括:Gbase 數據庫服務器4 臺,Hbase 數據庫服務器3 臺。其余則全部都是虛擬機:數據處理服務器3 臺,頁面服務器1 臺,Hbase數據接口服務器1 臺,Hbase 數據采集服務器2 臺,圖形產品接口服務器1 臺,Gbase 數據庫服務器集群6 臺,APP 數據推送服務器2 臺,測試服務器1臺,綜合數據庫服務器1 臺,共享網BBS 服務器1臺。整體的系統架構設計如圖1所示。

圖1 系統物理架構設計圖
天津氣象大數據共享網采用“關系型數據庫+表格系統+文件”的混合型模式管理業務產品,其中結構化數據(如自動站數據)采用分布式關系型MySQL數據庫管理,大部分業務產品為非結構化的文檔、圖像或者格點場數據,適用于不同格式的文件存儲,在文件名或者文件頭部嵌入要素、時空等屬性,為了便于檢索,相關屬性信息入MySQL 庫。氣象臺、氣候中心、海洋臺、環境氣象中心、信息中心、探測中心、災害防御中心、科研所、人影辦、服務中心、預警發布中心制作的業務產品在各自內部產品庫中存儲管理,通過FTP 或SFTP 推送至氣象大數據共享網的產品收集服務器,進而存儲在磁盤陣列,通過天津集約化數據環境進行統一存儲管理,供應用服務器進行共享。詳細存儲系統設計圖如圖2所示。

圖2 系統存儲架構設計圖
圖2 中的箭頭表示數據的流向或者消息同步,如GBase8a 物理機與虛擬機之間直接是消息同步機制,當物理機出現故障時,系統會利用kafka數據總線(消費者模式)自動遷移副本至虛擬機數據庫中,數據服務自動切換至GBase8a 虛擬機服務模式,有效保證數據服務的可靠性。
數據質量直接決定了數據服務的優劣。因此,數據服務中心特別針對氣象數據進行質量控制。限于篇幅,下面僅給出兩類關鍵的氣象數據質控算法。
針對氣象風廓線觀測產品,按算法要求對數據實施格式檢查、缺測率統計、缺測值訂正、界限值檢查、垂直風切變檢查、中值檢查、降水干擾檢查,完成實時觀測數據產品的質量控制,通過一致性平均算法計算0.5h和1h風廓線數據產品。
4.1.1 水平風速界限值

表1 水平風速界限值表
4.1.2 垂直風速界限值
垂直風切變檢查:在高度軸上,利用相鄰高度層的風切變大小判斷數據正確與否。垂直風切變計算公式如下所示:

上式中,Mj為風切變值,V1、V2為上、下相鄰兩層的風速,Zj+1、Zj為上、下相鄰兩層的高度。
計算兩高度層的垂直風切變值Mj,將Mj≤6.0 m·s-1/30 m(閾值可以根據質控結果調整)的數據標記為“有效”數據。
中值檢查:中值判斷只對垂直風切變判斷中被標記為“可疑”的高度層進行。目的是檢查風速在時間和空間上的連續性。
降水干擾檢查:對降水天氣時不同高度層觀測數據進行檢查。
一致性平均:通過一致性平均算法計算0.5h和1h風廓線數據產品。
對地面觀測的小時數據文件進行入庫后實時質量控制,質量控制結果綜合判定為正確或錯誤,對錯誤數據進行訂正處理。質控對象主要包括氣溫、氣壓、降水、風向、風速、濕度、淺層地溫、能見度等觀測要素,一般按下列流程進行:格式檢查、空間一致性檢查、內部一致性檢查、時間一致性檢查。具體要求如下:
1)格式檢查:檢查地面觀測小時數據文件是否符合格式要求,符合即入庫進行后面的檢查。
2)空間一致性檢查:空間一致性檢查是被檢站與周圍測站的觀測值進行比較。氣溫的空間一致性檢查采用Madsen-Allerupt 方法,具體如下:將相同時刻某一自動站i周圍相關若干個臨近站點的觀測值記錄下來,然后根據其大小進行排序,并取其中相關數據的中值和75%、25%分位值,計算統計量,對應計算公式如下所示:

其中,X0表示被檢氣溫,q表示臨近站氣溫中值和75%、25%分位值。 ||T0>X的測值被判定錯誤。
降水和風速的空間一致性檢查采用測站值與同時刻鄰近站點極值數據進行比較,采用以下公式:

上式中,a2<1 <a1。
3)內部一致性檢查:是指某些氣象觀測要素之間關系密切,其規律變化具有對應的一致性。所以,可透過判斷對應數據是否存在這種對應規律,來檢驗數據是否存在異常,從而檢驗數據質量。
4)時間一致性檢查:在某段時間,例如:一天,絕大多數氣象要素具有隨著時空變化而呈現相應波動的特性。若某要素的觀測數值出現無變化或者變化非常大的情況,則說明可能是傳輸設備或觀測儀器出現故障所導致的,而時間一致性檢查能夠有效檢查此類疑誤數據。
數據服務是系統數據信息顯示、查詢和下載的關鍵。
數據服務包括面向氣象業務用戶提供的基礎氣象資料及產品、氣象預報預測產品和氣象服務產品的發現和定位功能。數據發現服務以Web 交互方式向用戶提供數據發現、數據(目錄)導航、數據展示、數據檢索等服務功能。天津氣象大數據共享網根據實況觀測、天氣預報、氣候預測等實際業務數據服務需要,應用元數據技術和目錄服務技術[11~13],為用戶提供多維度的數據導航目錄和多視角的數據訪問入口,用戶通過數據發現服務,可快速定位并通過元數據概覽各種氣象基礎資料和產品。數據服務中所涉及到的查詢核心代碼如下所示:


圖3 系統數據服務展示界面
數據文件下載主要提供基于三種協議的數據下載服務分別為HTTP 方式、FTP 方式以及TDS 方式。
1)HTTP方式
通過HTTP方式提供數據下載
2)FTP方式
通過開源FTP 軟件,搭建FTP 服務器,基于FTP 協議實現數據的下載服務,同時能夠實時監控統計數據下載情況包括下載數據量、連接時間等。
3)TDS方式
THREDDS(Thematic Realtime Environmental Distributed Data Services)是由Uniadata 機構開發的一套分布式實時數據服務系統,主要用來簡化發現和使用氣象空間數據的過程。它能夠簡便高效的實現地球空間數據的供給、發布、和查詢操作。尤其針對HDF、NETCDF 等自描述型數據,TDS 可以自動顯示獲得的數據集元數據并進行發布。TDS支持數據集的遠程訪問,即用戶通過OPENDAP 遠程數據訪問協議,不需進行數據下載,即可使用NCL,GRADS 等通用氣象分析可視化工具在本地進行可視化數據服務。
數據訪問接口為氣象業務用戶的業務應用系統或專業軟件提供定制的氣象數據支持,數據訪問接口服務屏蔽底層異構、分布式的數據存儲和資源,采用通用的互聯網協議,基于統一的服務標準,面向業務用戶應用提供統一的訪問接口和服務,通過數據訪問接口服務,用戶應用系統可以自動快速獲取定制的各種氣象數據。利用數據訪問接口進行數據訪問的核心代碼如下所示:

目前,針對天津站點全部數據都入庫到Gbase中,共有155,281,334,700 條記錄。為了測試系統性能,分別統計天津各站點一定時間內的小時平均氣溫與累計降雨。測試的性能統計表如表2所示。

表2 站點數據查詢性能測試表
可以明顯看到,現有Gbase 數據庫的查詢性能比CIMISS系統中的Oracle提升了至少5倍多,而隨著時間延長,甚至提升至22 倍以上。限于篇幅,HBase(毫秒級)、MySQL(秒級)等其他數據庫的測試不再贅述。圖4 展示了利用可視化技術[14~16],基于HBase,溫度預報頁面數據服務的測試效果。

圖4 智能預報數據服務速度測試
本文利用大數據相關技術,搭建了以MySQL、GBase、HBase 和分布式NAS 為基礎的統一數據存儲環境,使數據的收集、處理和服務能夠高效化、集約化和便捷化。
根據數據特性施行不同的分類存儲策略,結構化數據采用分布式關系型數據庫管理,非結構化數據采用分布式NAS存儲,并將其元數據信息存入關系型數據庫中,極大提升了數據的聚合和檢索能力。打通了部門之間的數據壁壘,有效清除了“數據孤島”現象,構建了統一的天津大數據收集、處理和服務數據中心,并提供了統一的數據服務接口,使數據的唯一性、可靠性得到較大增強。
但是也要看到,天津省級氣象大數據服務相關工作只是剛剛開始,仍然存在著不少問題需要繼續去完善和升級。