基于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]。基础观测数据的时间频次依据不同的数据分为时、日(每日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相比，该系统在气象数据的插入、检索查询及性能方面有着很大的优势，能够更加高效地处理和分析气象海量数据。本系统已应用在安徽省森林防火气象服务平台并取得良好的效果。