基于MongoDB的氣象數據存儲檢索系統

陳 浩，張 亞，羅希昌，張亞力，劉文靜

(安徽省公共氣象服務中心,安徽 合肥 230031)

0 引 言

近年來氣象現代化水平不斷提高，為公眾提供了更豐富、更高質量、更精細化的氣象服務。氣象服務產品從傳統的城鎮預報向任意時刻、任意位置的精細化預報轉變，從簡單的天氣及氣候預測向密切貼合行業用戶需求的個性化氣象服務轉變。這種轉變的背后需要各類精細化預報產品和實況數據作支撐，如數值預報、國家局智能網格預報、雷達衛星數據等[1-3]。氣象數據是氣象服務和氣象科學研究的基礎。氣象數據已經進入大數據時代，有如下特征：

1)海量性。氣象數據中大量的數據是時空數據，記錄了空間和時間范圍內各個空間點的各個物理量的觀測數據或者模擬數據，每天產生的數據量常在幾十TB到上百TB的規模，呈指數級增長。以全國天氣預報數據為例，服務器日新增約1500萬個500 kB至10 MB大小不等的數據文件，未來則會達到每天1億個新文件，日增量50 TB以上[4-6]。

2)多源異構性。氣象數據的來源包括衛星廣播系統、雷達衛星、高空探測設施、地面自動觀測站等[7-9]。數據格式包括文件(文本、壓縮包)、XML、JSON、圖片(PNG、JPEG)、格點、HDF、HSD、NetCDF、TLE、PDS等格式，種類繁多、結構復雜。

3)實時性。氣象數據均為全天不間斷觀測實時產品。靜止衛星每15 min～30 min進行高頻次的觀測[10-12]?；A觀測數據的時間頻次依據不同的數據分為時、日(每日N次和每日1次)、旬、月、季、年產品等[13]。隨著氣象服務的進一步發展，社會對各類氣象衛星資料的處理和分發速度要求越來越高。例如，自動氣象站中雷達衛星數據6 min/次，加密觀測為5 min/次[14-15]。

面對海量性、多源異構性、實時性的氣象數據特點，傳統的關系型數據庫難以滿足氣象大數據的需求。當前安徽省公共氣象服務中心所使用的MySQL關系型數據庫，在單表超過1億行數據、5個并發的條件下，單次訪問的延時超過40 s，已經無法提供較好的用戶體驗(未計算數據入庫所帶來的性能損耗)?；诖?，本文提出一種基于MongoDB的氣象數據存儲檢索系統，結合氣象數據海量性、多源異構性、實時性等特點，能夠支持氣象數據的快速檢索和分析。

1 MongoDB數據庫介紹

MongoDB數據庫是一個高性能、開源、無模式的非結構化數據庫[16-18]。MongoDB數據庫不像關系型數據庫需要預先定義數據表結構，同時數據庫中的每條數據擁有不同數量的屬性和結構，模式自由靈活。MongoDB數據庫中的表不使用固定模式存儲數據，提供了非常強的讀寫能力。MongoDB數據庫中數據采用BSON格式存儲和交換，BSON是一種類似于JSON的存儲格式，具有輕量級、可遍歷、可拓展、高效性的特點，可以高效地存儲多源異構的空間數據[19-20]。

1.1 基于MongoDB數據庫的氣象數據存儲

數據庫在存儲氣象數據過程中需要滿足數據多源異構性、多樣性、動態實時更新等特點，關系型數據庫難以滿足這樣的需求。MongoDB數據庫中的數據是以集合的形式存儲，在創建新集合時無需在數據庫中預定義，如數據庫中未查到對應集合，則自動創建集合并插入新的文檔對象。針對氣象數據的空間數據形式，MongoDB采用GeoJSON形式(BSON形式的一種)進行二進制組織。圖1所示為一條數值預報在MongoDB中的存儲形式。氣象數據信息以鍵值對的格式存儲，“_id”鍵對應自動生成的ObjectId對象，確保集合里面每個文檔能被唯一標識；“geometry”對象

圖1 數值預報存儲結構

包含一個“coordinates”對象和一個“type”屬性，分別對應經緯度信息和經緯度類型；“time”表示數值預報采集的時間；“temp”表示溫度；“rh”表示濕度；“pre”表示氣壓；“wd”表示風向；“ws”表示風速。

1.2 基于MongoDB數據庫的氣象數據索引構建

支持地理空間索引是MongoDB數據庫的重要特性之一，是專門用來處理地理空間相關問題而存在的。氣象數據保存到MongoDB數據庫中時，以經緯度作為索引，轉化為地理空間問題，進而實現海量氣象數據的快速檢索與分析。MongoDB的空間索引是將地理空間對不同層級的空間區域由四叉樹轉為哈希編碼GeoHash值,用一維地理編碼GeoHash值表示二維地理空間[21-22]。針對氣象數據建立空間索引，在MongoDB中是以四叉樹形式建立索引，如圖2所示。

圖2 數值預報索引結構圖

氣象數據根據地理空間遞歸劃分成不同層次的四叉樹結構。氣象數據對象都存儲在葉子節點上，中間節點以及根節點不存儲氣象數據對象。地理空間的經緯度無法直接建立索引，MongoDB會通過Geohash算法將四叉樹索引轉為一串字符串。已知地球緯度區間是[-90°，90°]，對緯度區間[-90°,90°]進行二劃分為[-90°,0°)和[0°,90°]這2個區間，稱為左右區間，系統規定中間值屬于右區間，即右區間為全閉區間，左區間為左閉右開。目標經緯度落在左區間取值為0，落在右區間取值為1。以安徽省氣象局的經緯度坐標(31.852°，117.280°)為例，下面舉例GeoHash編碼具體實現過程：

1)將緯度區間[-90°,90°]二化分為[-90°,0°)和[0°,90°]這2個區間，緯度31.852屬于區間[0°,90°]，得到該區間索引值為1，二進制串序列為1。

2)將區間[0°,90]二劃分為[0°,45°)和[45°,90°]這2個區間，緯度31.852°屬于區間[0°,45°)，得到該區間索引值為0，二進制串序列為10。

重復執行上述二劃分過程，隨著劃分區間[x,y]的縮小，區間會越來越逼近31.852，產生一個二進制序列為：101011010100，如表1所示。序列的長度與給定的區間劃分次數有關，二次劃分次數越多，二進制編碼序列就越長[23]。

表1 緯度轉二進制編碼

同理，對經度117.280°進行GeoHash編碼的過程也類似。如表2所示，經度坐標117.280°產生的二進制序列為：1101001101。

表2 經度轉二進制編碼

接下來將緯度和經度的二進制序列合并，緯度在奇數位，經度在偶數位，得到二進制序列為11011001101001110011，每5個二進制字符為一組轉化成十進制數為27、6、19、19，最后，用0～9、b～z(去掉a、i、l、o)這32個字符對十進制數進行base32編碼，base32編碼形成的GeoHash字符串為v6mm。

通過以上方法將一個二維的經緯度坐標轉化為可排序與比較的字符串，關系型數據庫的檢索是由一個需要多個表的連接操作符來執行的，而MongoDB的檢索只需要通過讀取一個包含所有必要信息的文檔表來執行。MongoDB數據庫建立空間索引非常適合氣象海量數據的檢索系統。

2 基于MongoDB的氣象數據存儲檢索系統

基于MongoDB的氣象存儲檢索系統的架構如圖3所示，包括數據層、業務層和和應用層。

1) 數據層。數據層是對外提供服務的原始數據，MongoDB數據庫存儲著數值預報數據、雷達衛星數據等各種結構化多樣化的海量氣象數據。

2) 業務層。業務層是系統的核心內容，負責業務功能的實現和業務流程的邏輯處理。系統各層通過業務層無縫地整合在一起，實現了各模塊和各層次的解耦，提高了系統的可維護性和可移植性。

3) 應用層。應用層是整個系統的功能體現，包括氣象數據的插入、刪除、檢索等功能。應用層也對外提供REST接口，供其他業務平臺調用，例如：氣象數據檢索接口、氣象數據插入接口等。

圖3 系統結構圖

采用JavaScript等技術提供簡潔、友好的界面訪問，如圖4所示。圖中給出了經緯度的值、選擇數值預報類型，返回了數值預報的檢索結果。

圖4 數值預報檢索結果

3 實驗與分析

為了驗證MongoDB數據庫在氣象海量數據的優勢，本文進行了MongoDB數據庫和關系型數據庫MySQL對比實驗。MongoDB數據庫和關系型數據庫MySQL這2個數據庫運行在相同的軟硬件環境。實驗采用2臺型號相同的新計算機作為服務器，分別安裝MongoDB 4.2、MySQL 8.0，測試PC工作站1臺。性能測試分2組進行，分別測試2類數據庫的插入存儲速度和海量氣象數據檢索的速度。

3.1 氣象數據插入

實驗數據來自數值預報數據和雷達衛星數據的氣象數據，共包含1億多條數據，數據總量接近16 GB。MongoDB和MySQL插入數據耗費時間如圖5所示。

圖5 插入時間對比圖

通過圖5可知，在插入大量氣象數據時，MongoDB的效率更高。當氣象數據少于1萬條時，MySQL的處理時間更短，MySQL可以很好地處理少量數據，但面對目前海量氣象數據時，MongoDB明顯是更好的選擇。

3.2 氣象數據檢索

以數值預報集合為測試對象，包含500萬條數據，安徽省氣象局的經緯度坐標為(31.852°，117.280°)，檢索9 km之內的數值預報信息。圖6表示MongoDB和MySQL檢索時間的對比。MongoDB的檢索查詢時間明顯優于MySQL。

圖6 檢索時間對比圖

通過圖6可以看出，當檢索半徑為1 km時，MySQL的檢索時間為0.2 s，而MongoDB的檢索時間不到0.01 s；當檢索半徑為9 km時，MySQL的檢索時間快到1 s，而MongoDB的檢索時間大約為0.05 s，MySQL檢索耗費的時間大約是MongoDB檢索耗費時間的20倍。隨著檢索半徑的擴大，數據量迅速增長，MySQL數據庫的檢索時間急劇上升，而MongoDB的檢索時間變化緩慢，受數據量增長變化不大，MySQL數據檢索耗費時間遠遠大于MongoDB。

3.3 性能測試

采用Jmeter工具對MongoDB數據庫服務器和MySQL數據庫服務器進行監控測試，MongoDB數據庫進行50個并發查詢，對MySQL數據庫進行5個并發查詢，如圖7所示。

圖7 性能對比圖

MySQL數據庫CPU占用率保持在40%～60%之間，而MongoDB數據庫的CPU占用率在5%以下。MySQL的磁盤開銷壓力非常大，幾乎都在100%，而MongoDB的磁盤開銷也會出現在100%的現象，但大部分磁盤開銷的均值很小，幾乎為0。出現這樣的原因是MongoDB內部采用合并操作的方式，采用數據先存放到內存中，然后再Flush到磁盤上的方式，進行查詢操作的過程中，每當數據庫中的數據達到一定量級后就會自動進行，因此每隔一段時間就會有一個明顯的毛刺?？傊?，MongoDB數據庫的性能遠遠高于MySQL數據庫的性能。

4 結束語

本文基于MongoDB的氣象數據存儲檢索系統實現了對海量氣象數據的快速存儲，并根據氣象數據的特征建立空間索引。與傳統的關系型數據庫MySQL相比，該系統在氣象數據的插入、檢索查詢及性能方面有著很大的優勢，能夠更加高效地處理和分析氣象海量數據。本系統已應用在安徽省森林防火氣象服務平臺并取得良好的效果。