內蒙古自治區氣象大數據云平臺數據庫設計與實現

楊 鵬

（內蒙古自治區氣象信息中心 內蒙古 呼和浩特 010051）

0 引言

經過多年發展，自治區氣象信息化能力不斷提高，氣象數據存儲與服務能力不斷增強，天氣預報、氣候預測和數值預報業務以及科研系統的基礎資源環境大幅改善，但面向大數據服務的現實需求，存儲、共享數據種類不完整，數據供應不足，自治區特色生態氣象觀測、人工影響天氣觀測及多部門行業共享數據沒有實現快速采集并納入統一規范化管理，難以發揮應用價值。

2016年氣象部門構建了基于全國氣象綜合信息共享平臺（以下簡稱“CIMISS”）的集約化數據環境，標準、統一地支撐氣象核心業務系統的氣象數據生態已初步形成，但數據采集形式單一，不能滿足行業、部門數據采集匯聚需求；無法支持分布式計算、流式計算、挖掘分析、機器學習等新型技術框架，不能快速響應內部、行業和決策用戶的數據加工、處理需求；無法滿足長序列歷史數據及分鐘級數據檢索的性能需求，亟須實現歷史、實時資料一體化在線訪問[1]。因此，內蒙古自治區氣象大數據綜合用平臺應運而生，它將負責解決數據集約、業務集約問題，有效支撐氣象業務系統和各類數據應用，全面支撐“云+端”生態運行。

1 數據分析

從數據形態來講，氣象數據主要分為結構化數據和非結構化數據。結構化數據包括氣象臺站的各類觀測要素資料，如地面、高空、輻射、農業氣象、大氣成分等；非結構化數據包括數值預報、氣象災害、雷達、衛星等[2]。

1.1 數據量分析

（1）業務數據：基于CIMISS統一數據環境，自治區每日實時收集來自國內外氣象觀測數據、加工處理后產品數據以及部門間交換數據等多種數據。數據種類包括：地面、高空、輻射、農業氣象和生態氣象、大氣成分、衛星、雷達、氣象災害、數值預報產品、氣象服務產品和其他資料等共11大類[3]?，F有數據見表1。

表1 數據增量及存儲期限詳情信息表

其中結構化數據包含地面、高空、海洋、輻射、農業氣象、大氣成分等種類的數據，6種數據現存數據量為8.8 TB。非結構化數據包含數值預報、氣象災害、雷達、衛星、服務產品等種類的數據，存數據量為141.7 TB。

未來5年的數據增量：考慮各個存儲庫的年增長量，未來5年平均年增長率按照20%計算，按照計算公式：S=a1×（1+q）5∑=a1×（1+q）5（a1為第1年數據存儲量，q為年增長率）進行計算：結構化數據未來5年數據存儲量為8.8TB×（1+20%）5=22(TB)；非結構化數據未來5年數據存儲量為141.7TB×（1+20%）5=352.59(TB)。

（2）其他數據：通過歷史資料拯救及數字化工作，收集整理了全區各類紙質氣象記錄檔案資料、各類氣象記錄檔案數字化圖像文件、臺站歸檔電子資料、錄入的歷史資料數據集、國家氣象局下發數據集、整編數據等文本文件；通過定期制作和各臺站匯交的地面、高空、輻射月報和年報資料。累積長序列數據集總量約20 TB。

未來5年的數據增量：考慮各個存儲庫的年增長量，未來5年平均年增長率按照20%計算，按照計算公式：S=a1×（1+q）5∑=a1×（1+q）5（a1為第一年數據存儲量，q為年增長率）進行計算：非結構化數據未來5年數據存儲量為18.04TB×（1+20%）5=44.88(TB)。

1.2 存儲策略分析

對于結構化數據可根據數據的交互需求采用關系型數據庫與NOSQL數據庫相結合的存儲設計，以滿足數據實時查詢檢索和統計計算分析的需求。針對非結構化數據，根據數據檢索維度設計其分布式索引信息實時訪問，采用分布式NAS文件類型存儲，用以滿足此類數據的各種業務訪問需求。同時針對非結構化數據的實時共享訪問需求，提供分布式KV數據庫存儲形式，將雷達、數值預報、衛星數據進行分片打散，從而提供更為高效的基于時空維度的數據實時訪問及可視化顯示能力[3-4]。

2 數據庫設計

2.1 數據庫架構設計

2.1.1 數據分庫分表設計

單表數據量限制在500萬，表之間數據無傾斜，盡量均勻分布，因此應盡量選好分庫分表鍵。元數據信息表，以廣播表的形式，在各分庫里均有副本，保證JOIN操作的高效檢索。數據的分庫分表數量按照數據的實際存儲時限來確定，并根據總數據容量進行分布式數據庫資源規模的確定。進行數據檢索時，加入分庫分表鍵條件，這樣數據將直接定位到分庫，極大縮短查詢時間。

2.1.2 讀寫分離設計

數據的解碼入庫，與數據的讀取，在數據庫IO層面會產生沖突，從而導致兩者的性能降低，采用分布式數據庫產品提供數據的讀寫分離能力，并保證讀庫與主庫主鍵具有很小的數據延時。

2.1.3 數據索引設計

分布式關系型數據庫，支持傳統的數據索引，從而為高頻訪問數據的查詢進行快速定位和緩沖，在針對各類匯交數據的訪問，根據高頻檢索條件進行索引設計，從而保證大部分查詢可以命中索引，實現數據的快速檢索。

2.1.4 提高數據庫運行效率的辦法

在數據庫物理設計時，降低范式，增加冗余，少用觸發器，多用存儲過程。當計算非常復雜，而且記錄條數非常巨大時，復雜計算要先在數據庫外面，以文件系統方式用C++語言計算處理完成之后，最后才入庫追加到表中去。對數據庫管理系統DBMS進行系統優化，即優化各種系統參數，如緩沖區個數。使用面向數據的SQL語言進行程序設計時，盡量采取優化算法[5]。

2.2 數據庫技術選型

分布式關系型數據庫hbase，用于結構化數據的實時查詢、檢索。分布式表格系統設計采用Cassandra數據庫集群存儲監視指標數據，支持高吞吐量的大量寫入、低延遲頁面刷新。采用數據庫集群存儲日志事件類數據，支持持續大量的寫入、關鍵字查詢、查詢統計等。分布式文件系統采用分布式NAS[6-7]。

2.3 數據存儲結構及策略設計

2.3.1 氣象結構化數據存儲系統

根據結構化數據存儲規范，利用關系型數據庫技術建設氣象結構化數據分布式存儲系統，包括自動站數據庫、其他站點數據庫、結構化數據分析庫、非結構化數據索引庫等物理隔離的數據庫，用以存儲氣象觀測站點數據、文件產品的索引信息、新匯交數據。

2.3.2 非結構化數據存儲系統

根據非結構化數據存儲規范，利用分布式文件存儲系統和文件目錄結構規范建設非結構化數據實時庫和非結構化數據歷史庫。非結構化數據實時庫，主要滿足氣象核心業務系統對數據服務的需求。非結構化數據實時庫具有實時性高、周期性短、訪問速度快、數據量不超過5PB等特點，提供應用系統的直接訪問。非結構化數據歷史庫，主要滿足科研用戶以及業務試驗系統對數據在線訪問的需求，保障歷史數據在線服務。非結構化數據歷史庫具有全序列、歷史性、數據量大等特點，為應用系統對歷史資料的分析提供數據資源。結構化實時庫與歷史庫共同組成氣象結構化的數據存儲全集，提供直接數據訪問[8-9]。

2.4 數據庫表設計

氣象大數據管理云平臺根據氣象應用對數據訪問的需求，分為結構化數據庫、非結構化文件索引庫、緩沖庫、歷史分析庫、實時應用庫。在進行分布式數據庫分庫分表設計時，主要結合了各類數據庫的分庫分表特點，如針對hbase數據庫，主要按觀測時間進行分庫分表設計，針對分析型數據庫，主要根據站點編號進行hash分布鍵的設計。針對鍵表和要素表，則根據訪問特點，對要素表按外鍵id進行hash分布鍵的設計。

數據索引需要建立在一個全局共同遵守的標準之上，這個標準中規定了在不同數據分片場景下各個數據節點應共同包含或通過邏輯映射的方式包含相應的屬性，如在水平分片場景下，各個數據節點應共同擁有日期屬性，日期屬性可分為年、月、旬等多個分類方式。如同屬于年分類的場景下，則需要共同擁有年屬性；如在垂直分片場景下，各個數據節點應共同擁有要素類型屬性。分布式存儲的核心問題是對數據分片和數據分配方式，分片的方式分為水平分片、垂直分片、導出分片和混合分片。

除對氣象數據進行長序列、分布式、分級在線存儲外，還針對天氣分析、決策服務、氣候預測等應用設計多副本數據庫和數據表。比如，針對天氣分析，基于分布式表格系統建立氣象數據實時應用庫；針對決策服務和氣候預測，基于分布式分析型數據庫對長序列地面數據冗余存儲；針對應用頻度和重要性不同，對地面分鐘和小時數據按國家站/區域站、常用要素/全要素的分表存儲，在接口層面進行封裝，保障訪問的高效。設計存儲緩沖區，暫存入庫后的數據，基于SSD構建小型關系型數據庫；所有用于服務的數據庫都從該緩沖區獲取數據，基于數據庫提供的記錄變更信息開展數據同步。該同步方式實現了讀寫分離，除了高效、穩定，還能適應可能新增的副本需求[10-11]。見圖1。

3 數據訪問接口

數據訪問接口模塊實現數據訪問的接口封裝，包括數據庫數據訪問接口、文件訪問接口、安全認證和請求監聽功能，由于接口讀寫的高并發性，需要考慮接口封裝的多線程特性，包括端口監聽、連接的建立以及數據傳輸的控制能力。數據訪問接口遵循氣象數據統一服務接口標準規范進行設計，通過符合氣象標準的開放接口，并在其基礎上進行定制開發，保證各業務系統與大數據平臺的無縫對接，全面提升數據服務性能。

3.1 數據庫數據訪問接口

數據庫接口服務面向對象為專業和非專業的數據使用人員，專業地為數據庫管理員提供數據庫接口，非專業在系統界面提供查詢、導出功能。數據庫數據訪問功能是當系統對外提供結構化數據訪問服務時，數據訪問請求首先通過數據訪問安全控制功能實現安全認證，然后通過統一的數據獲取服務獲得數據的存儲位置信息以及數據結構信息，然后根據數據存儲位置，訪問物理存儲的數據庫表，通過結構信息可動態給出訪問形式化參數結構，通過給定參數動態拼裝查詢檢索和寫入信息對應的SQL語句然后進行真正的數據訪問，最后將數據結果以用戶定義的形式化結構參數形態返回給用戶[12]。

3.2 文件訪問接口

文件訪問接口功能就是給外部系統提供文件類氣象數據的調用服務接口，接口封裝了文件的數據操作API，對外提供統一的服務接口供外部調用。文件訪問接口模塊主要完成的功能包括各類氣象專業化文件讀取，文件寫入功能。

（1）接收服務請求功能單元負責接收來自外部系統的服務請求，包括調用的API信息、調用者信息及調用參數信息。

（2）啟動服務進程功能單元根據服務請求信息自動啟動服務進程，這些服務進程會根據請求信息自動匹配相關進程。進程啟動之后，交與其他模塊進行處理。

（3）提交處理結果功能單元是經存儲管理控制中心動態調度數據處理（融合、包處理等）和數據讀取服務（副本生成、壓縮、打包等）等操作后，將結果或結果集返回給請求服務的外部系統。文件訪問接口模塊主要由接收服務請求、啟動服務進程和提交處理結果等功能組成。

4 結語

氣象大數據綜合應用平臺對氣象大數據資源進行全流程規范化管理，對氣象及相關領域數據進行快速匯聚、交換、質控和入庫；基于算法庫和加工流水線，對數據進行加工處理，生產豐富和高質量的統計類、網格化、組網拼圖、天氣氣候分析等產品；完成200余種數據產品服務，目前用戶數據達300個，預計同時支持動態用戶數達1 500人，最大支持同時檢索和下載資料并發數達1 500次/min，實現部門內外用戶亞秒級數據響應。對氣象大數據進行規范、實現實時歷史一體化的在線存儲，提供統一、便捷、豐富的數據服務接口。開放內部的數據管理能力，包括數據交換、產品加工、存儲服務等，平臺建成后每小時收集、解碼、存儲、共享數據量約14 GB，資料全流程管理均通過氣象大數據管理云平臺自動化實現。

氣象大數據綜合應用平臺推動氣象數據開放共享，使氣象深度滲透、融入其他行業中，實現功能的互補和延伸。匯聚氣象數據、社會數據、行業數據等數據資源，實現氣象與其他產業間功能的互補和延伸，向政府、行業部門、軍隊和公眾用戶提供6大類160子類數據產品共享服務，數據產品日服務量由原來的200 GB提升到500 G，支持1 000用戶并發訪問，充分發揮氣象信息蘊含的經濟價值、社會價值。