CN101984421A - 基于实时数据库的气象要素数据组织录入与查询方法 - Google Patents

Abstract

本发明涉及气象数据处理技术领域，公开了一种基于实时数据库的气象要素数据组织录入和查询的方法，构建以实时数据库为核心的气象要素数据模型，所述模型以自动站站号和要素名称为基本数据单元，基本数据单元的数据以时间戳顺序存储；实现气象要素实时数据的快速录入以及历史数据的高速查询。本发明的方法解决了气象应用领域中气象要素实时数据录入和历史数据查询的性能问题，实现气象要素实时数据的快速录入，保证用户能够在较短的时间内获得其所需要的历史数据信息，提高气象综合信息处理系统的响应速度。

Description

基于实时数据库的气象要素数据组织录入与查询方法 

技术领域

本发明涉及气象综合信息服务技术领域，尤其涉及一种气象要素数据组织与查询优化方法，可以应用于气象、工业、农业、水文水利、环保、高速公路、机场和港口等的气象综合信息服务技术领域。 

背景技术

气候是自然环境的组成部分，也是人类活动最重要的环境条件。当前，气候变化和极端天气与气候事件正威胁着世界各国的社会经济发展和人民生命财产的安全，严重影响着全球可持续发展战略目标的实现。维护气候系统的均衡，统筹人与自然的关系，已成为当今世界高度关注的重大议题之一。而描述大气及其相关圈层状态和特征的气象科学数据，不仅是气候系统相关学科的研究基础，也是国家经济建设、社会发展、国防建设、环境保护、生态建设和人民生活不可或缺的重要信息。 

科学数据是人类社会科技活动所产生的基本数据、资料，以及按照不同需求而系统加工的数据产品和相关信息，具有明显的潜在开发价值，并在广泛应用过程中得以增值，是信息时代最基本、最活跃、影响面最宽的科技信息资源。开展科学数据共享不仅是当代科技创新与发展的迫切需求，也是经济与社会协调可持续发展的一项重要的基础性支撑。气象科学数据以其广泛的应用需求和较好的业务基础，被列为国家科学数据共享工程的首批试点。 

自动站的建设是气象科学数据获取的基础，是实现大气监测自动化的第一步，资料的应用是其根本所在。为了使自动站监测数据在科研工作、预报业务、服务及气象灾害监测中得到更加及时和方便的应用，需要加速自动站资料应用的业务化进程，获取及时、准确的气象资料，更好地服务于社会。同时，也可以为预报员及时监测灾害性天气的发生和开展准确及时的预报、情报服务提供重要的实时信息，最大限度的发挥了自动站建设的投资效益。 

目前，绝大部分气象综合信息服务系统都采用Oracle、SQL Server等大型关系数据库系统来存储气象科学数据，其中包括频繁更新的自动站气象要素。随着自动站建设的深入，自动站的分布越来越密集，而且气象要素更新周期也由十五分钟提高到五分钟，因此，随着时间的推移，气象要素的历史数据量也迅速膨胀。采用Oracle、SQL Server等传统商业关系数据库系统来存储自动站气象要素时，传统商业关系数据库系统对气象要素的实时数据和历史数据的处理速度较慢，尤其是随着时间推移，历史数据量越来越大时，其处理速度会越来 越慢以至于无法满足客户的最低要求。虽然，Oracle是目前性能最好的商业数据库，尤其是在处理海量数据时其性能比较好。但是，Oracle的性能也会随着数据量的增加而降低。当气象数据累积一到两年之后，其数据量会变得很大，以至于Oracle的数据录入速度及查询响应速度无法满足客户的最低要求，成为目前急需解决的重要问题。 

实时数据库系统对于处理那些频繁更新的实时数据具有较大的优势，其性能远远优于普通关系数据库系统。本发明将基于实时数据库系统，提出一种气象要素实时数据存储管理的数据模型；并在该数据模型的基础上，提出了高效的气象要素数据组织和查询优化方法，从而提高海量气象数据的处理性能。 

发明内容

为了克服现有技术中的缺点，本发明的目的之一是采用实时数据库系统替代传统商业关系数据库系统来存储自动站气象要素数据；另一目的是根据气象数据的特点和查询要求对实时数据库系统进行了优化，以保证优化后的查询速度在面对海量气象要素历史数据时，依然能够很好地满足客户的查询要求。 

为了实现本发明的第一目的，采用的技术方案如下： 

一种基于实时数据库的气象要素数据组织录入方法，其步骤包括： 

1)在实时数据库中建立气象要素实时数据存储模型，所述模型以自动站站号和要素名称为基本数据单元，基本数据单元的数据以时间戳顺序存储； 

2)从自动站采集的各气象要素数据根据其站号及要素名称检索其对应的基本数据单元，将各个自动站的每个气象要素与实时数据库系统中的一个基本数据单元对应； 

3)采用数据组包发送机制和主内存方式将采集的数据录入实时数据库。 

所述基本数据单元命名规则为：站号_要素名称。 

所述数据组包发送机制为：将采集的数据进行组包，形成大数据包再发送。 

进一步，将采集的站号及要素名称转换为基本数据单元ID，形成数据更新元组进行组包。 

主内存方式为实时数据库系统中所有数据单元的数据信息都存储于内存中。 

为了实现本发明的另一目的采用的技术方案如下： 

一种基于实时数据库的气象要素数据查询方法，对以权利要求1方法录入实时数据库的气象数据进行查询，其步骤包括： 

1)客户端提出查询请求，实时数据库完成对查询请求的解析，解析出查询要素信息、时间范围； 

2)对于条件查询，完成对条件表达式的解析； 

3)查询出气象要素名称及相应时间范围内的历史数据； 

4)对气象要素历史数据排序生成一条记录放入记录集； 

5)将记录集句柄和记录数返回客户端。 

所述步骤4)只对每个站点的第一个要素数据按照站号和时间进行排序，根据站号和第一个要素数据的时间戳来匹配同一条记录的其他要素的数据，并组合成一条记录。 

采用归并排序算法进行排序。 

所述步骤5)采用数据批量发送机制将记录集发送到客户端，具体为： 

9-1)从批量数据获取请求中解析出记录集信息、记录开始位置和所需获取的最大记录数。 

9-2)将记录集当前位置移动到请求中指定的开始位置； 

9-3)从记录集中依次记录添加到批量记录集中，直至满足终止条件； 

9-4)将批量记录集和已发送记录数返回到客户端。 

所述终止条件，即本次批量记录集记录数大于等于请求的最大记录数，或记录集读取完最后一条记录； 

与现有技术相比，本发明具有以下有益效果： 

1、本发明提出的基于实时数据库的气象要素数据组织与查询优化方法，针对气象应用中自动站气象要素数据特征，采用实时数据库系统对数据进行存储管理，减少了数据写入的一致性检查。另外，实时数据库系统数据录入过程中用点ID取代了站点名和要素名进行数据写入，数据通讯量减少、更新过程中也无需维护索引。因此，此方法能够实现比传统商业关系数据库系统快很多的实时数据录入性能。 

2、本发明提出的基于实时数据库的气象要素数据组织与查询优化方法，基于实时数据库系统的数据管理模型，实现对气象要素以不同点的形式进行存储，每个点又以时间戳的先后顺序进行索引管理，非常适合气象应用中以时间区间为条件查询多个要素的历史数据查询特点，通过对多个气象要素历史数据查询的磁盘访问优化，减少了磁盘访问次数，减少了磁头移动距离，大大提高了数据检索和磁盘数据装载到内存中的速度，从而实现更高的气象要素历史查询性能。 

3、本发明提出的基于实时数据库的气象要素数据组织与查询优化方法，结合实时数据库系统中历史数据基本以时间戳有序存储，对查询结果进行排序过程中采用了特殊而有效的排序方法，减少排序过程中不必要的数据交换，从而实现按时间戳和站点名排序的高速排序。排序速度的提升，极大地提高了气象要素历史查询性能。 

附图说明

图1为基于关系数据库的气象要素数据模型； 

图2为基于实时数据库的气象要素数据模型； 

图3为基于实时数据库的气象要素实时管理系统； 

图4为基于主内存的实时数据录入优化方法； 

图5为后台程序处理气象要素数据历史查询流程图； 

图6为后台程序批次组织查询数据处理流程图； 

图7A为为排序算法的逻辑方案； 

图7B1表示双向链表结构； 

图7B2表示逆向检索； 

图8为实时数据库系统实施体系结构； 

图9为客户端获得历史查询数据时序图； 

图10为Agilor与Oracle在不同数据量下的查询性能对比图； 

图11为Agilor与Oracle查询不同时间范围下的性能对比图。 

具体实施方式

下面结合附图和具体实施方式对本发明做进一步说明。 

本发明提出了基于实时数据库系统的气象要素数据存储查询的方法，该方法涉及的关键技术问题主要包括三个方面：1、基于实时数据库系统的自动站气象要素数据模型；2、气象要素数据的实时录入策略；3、针对气象应用特点的实时数据库系统历史数据查询处理策略。 

基于关系数据库系统的自动站气象要素数据模型基于自动站气象要素设计实现。系统需要存储管理很多自动站的数据，每个自动站都有各自的站号，也有各自检测的气象要素，每个自动站每隔一个更新周期(十五分钟、五分钟，甚至更短)就会自动上报一次数据。图1是气象要素数据在关系数据库中的数据模型，每隔一个周期每个自动站都会在关系数据库内增加一条记录，记录中包括了站号、更新时间、各气象要素数据等值。 

在实时数据库系统中，基本数据单元是数据点，对应着现实世界中的监测对象的状态，并以时间序列存储该监测对象的历史状态。为此，将各个自动站的每个气象要素与实时数据库系统中的一个点(数据点)对应。实时数据库中点的命名规则为：站号_要素名称，例如某个站点S的温度，其对应的实时数据库中的点名为“S_温度”。如图2所示，每个自动站的数据被分成多个点，分别按照时间序列进行存储。 

如图3所示，本发明的方法提出了基于实时数据库的气象要素实时管理系统的系统框架， 并基于此框架提出了气象要素数据组织及查询优化的技术解决方案。系统分为了两部分，数据采集部分将采集的数据以数据点的方式录入实时数据库，客户端对存入实时数据库的历史数据进行查询。 

在数据采集方面，实时数据库系统完全可以满足气象要素实时数据录入的要求。如图4所示，基于主内存的实时数据录入优化方法中，从自动站采集上来的各气象要素数据直接根据其站号及要素名称检索其对应的采集点，进行数据过滤，并将点名转换为点ID，形成数据更新元组；网络数据发送模块将这些数据进行组包，形成较大的数据包发送，可以有效地提高数据传输效率。由于基于实时数据库的采集录入方案采用了主内存方式(主内存方式指的是在实时数据库系统中所有站点的所有要素的数据信息都存储于内存中使得访问数据点信息时速度会很快，因此系统性能会更好)和数据组包发送机制，并且减少了关系数据库中繁琐的数据一致性验证机制，其性能远优于关系数据库系统。 

对气象要素数据进行存储的最终目的是为气象应用服务提供数据查询服务，本技术方案提出了基于实时数据库系统的历史数据查询方法。 

气象应用服务查询数据典型方式是需要查询指定时间段内指定站点中指定的几个要素的所有数据，并且用户还可能对某些要素数值增加查询条件，查询结果需要按照站点名和更新时间进行排序，每个站点的每个时间点的指定要素数据形成一条记录。首先，利用实时数据库系统的历史数据查询功能，将用户指定查询站点的所有要素对应的数据点，按照时间段要求，查询到内存中，每个数据点形成一个数组，并采用本技术方案提出的归并排序算法将数据进行排序。由于同一条记录的不同气象要素数值的时间戳是一样的，因此我们可以只对每个站点的第一个要素数据按照站号和时间进行排序。对每个站点的第一个要素数据排好序之后，就可以根据站号和第一个要素数据的时间戳来匹配同一条记录的其他要素的数据，并组合成一条记录。 

实时数据库系统接收到气象要素历史记录查询请求后，进入实时数据库气象要素历史记录查询处理流程，如图5所示，流程分以下几个步骤： 

(1)完成对查询请求的解析，解析出查询要素信息、时间范围等； 

(2)对于条件查询，完成对条件表达式的解析； 

(3)查询气象要素点名相应时间范围内的历史数据； 

(4)使用气象要素历史数据归并排序算法完成记录集的生成； 

(5)将记录集句柄和记录数返回客户端。 

为保证历史数据查询结果的及时获取与响应，实时数据库系统对记录集采用了批量数据获取技术。批量数据获取流程如图6所示，可分为以下几个步骤： 

(1)从批量数据获取请求中解析出记录集信息、记录开始位置和所需获取的最大记录数。 

(2)将记录集当前位置移动到请求中指定的开始位置； 

(3)从记录集中依次记录添加到批量记录集中，直至满足终止条件，即本次批量记录集记录数大于等于请求的最大记录数，或记录集读取完最后一条记录； 

(4)将批量记录集和已发送记录数返回到客户端。 

其中，图7A为排序算法的逻辑方案，图7B为排序算法的物理实现方案。 

图7A中，站号：S₁，S₂，S₃，…，S_m，要素名：E₁，E₂，E₃，…，E_n，S_i_E₁是各个站点的第一个气象要素的历史数据数组，p_i是每个数组下一个要进行排序的元素，所有的p进行排序，假设p₂是时间戳最小的那个元素，该元素将被记录到排好序的大数组末尾，并将p₂指向S₂_E₂下一个元素。图7B是所有p进行排序的技术方案，算法中采用图7B1所示双向链表结构对所有p进行排序，每次将头指针所指元素取出，并将下一个元素插入，插入时从双向链表的尾指针开始进行逆向检索(如图7B2所示)，直到某个时间戳小于插入元素的时间戳，然后进行插入操作。 

为使具体实施方式描述的更直观，现结合北京气象局气象信息共享平台为具体实施示例，对根据气象应用优化后的实时数据库系统的实施进行详细描述。 

1、总体需求 

北京气象局气象信息共享平台采用大型关系数据库Oracle存储各类气象科学数据，其中包括频繁更新的自动站气象要素。系统需要对所有气象要素的历史数据进行持久性存储，以供客户进行查询分析。当前，每天新增的自动站数据记录数超过6万条。虽然，Oracle是目前性能最好的商业数据库，尤其是在处理海量数据时其性能比较好。但是，Oracle的性能也会随着数据量的增加而降低，随着时间的推移，气象要素的历史数据量迅速膨胀，Oracle数据库的插入与查询性能逐渐降低，以至于Oracle的响应速度无法满足客户的最低要求。为此，亟需采取一些新的技术对气象要素数据存储管理进行优化，实现高效的数据更新、快速的历史数据检索性能。实时数据库系统对于处理那些频繁更新的实时数据具有较大的优势，其性能远远优于普通关系数据库系统。同时，实时数据库系统建立了时间相关的多级索引机制，因此海量历史数据的检索性能比较好。 

为了实现对北京气象局气象信息共享平台的性能提升，首先，需要在实时数据库系统上建立气象要素数据模型，并将气象要素数据存储到实时数据库系统中。其次，需要针对实时数据库系统中的气象数据模型，实现气象要素历史数据查询优化方法，为北京气象局气象信息共享平台提供其要求的数据视图和接口。 

2、系统体系结构 

北京气象局气象信息共享平台采用B/S方式，按照浏览器-Web服务器-数据库三层模式架构，系统体系结构如图8所示。 

以下将由下到上对系统体系结构进行详细的描述： 

(1)各个区域的气象自动观测站具有各自的气象自动观测系统，通过各类传感器获取所需的气象要素数据，包括温度、湿度、方向等等。自动站将每隔一定的时间汇总一次所有气象要素的当前数据，并将这些数据打包成文件，发送到数据采集程序所在的工作站。 

(2)数据采集程序收到自动站发送上来的数据文件之后，将自动打开并解析数据文件中每个气象要素数值以及对应的时间戳，然后通过实时数据库系统的数据采集接口将数据及时地录入到实时数据库系统中。 

(3)气象要素数据管理系统是基于实时数据库系统进行改造完善之后的数据管理系统，它支持实时数据的快速更新，同时以高效的索引机制将历史数据存储到数据文件中，并能够为气象信息共享平台提供历史数据查询服务。 

(4)气象要素数据查询接口是在实时数据库客户端访问接口之上封装的为气象信息共享平台提供数据访问的专用接口，它将按照查询条件从后台实时数据库系统中查询数据，并将查询结果转换为气象信息共享平台所要求的数据格式返回。 

(5)气象信息共享平台是一个web服务，为客户端浏览器提供远程浏览服务，当客户端浏览器进行气象要素历史数据查询分析时，气象信息共享平台将调用气象要素数据查询接口查询历史数据。当客户端浏览器访问其他方面的数据(静态数据)时将通过气象信息共享平台访问Oracle数据库。 

3、气象数据实时管理系统的作用 

气象数据实时管理系统实现对海量气象要素数据的采集和管理，并为气象信息共享平台提供数据查询服务。气象数据采集系统自动采集自动站各类数据，并通过数据采集接口实时录入气象数据实时管理系统；气象信息共享平台访问气象要素数据查询接口来获得用户需要的历史数据，而气象数据实时管理系统的主要作用是根据用户提交的数据查询请求，分析其需要查询的时间范围，解析其查询条件，从历史数据库中检索用户需要的数据，并将数据返回给客户。客户端浏览器获得历史查询数据的具体步骤如下，流程图如图9所示。 

1)浏览器想气象信息共享平台下发查询命令； 

2)气象信息共享平台解析该命令后，取出第一个气象要素，使用该要素及历史数据查询时间范围调用数据查询接口； 

3)数据查询接口向气象要素管理系统发出查询历史数据请求； 

4)气象要素管理系统对第一个气象要素指定时间范围的数据进行历史查询，并将历史查 询记录集返回给数据查询接口； 

5)数据查询接口在得到气象要素管理系统结果响应后，将记录集句柄和记录数返回给气象信息共享平台； 

6)气象信息共享平台根据一页的记录显示条数的限定，向数据查询接口请求第一页数据的起始和终止时间； 

7)气象信息共享平台根据上一步得到的起始时间和终止时间调用数据查询接口对所有气象要素进行查询； 

8)数据查询接口收到查询请求后，向气象要素管理系统下发所有气象要素第一页时间范围内的历史数据查询请求； 

9)气象要素管理系统完成查询，并向数据查询接口返回查询结果； 

10)数据查询接口收到查询结果后像气象信息共享平台返回查询结果； 

11)气象信息共享平台将第一页查询结果返回给用户浏览器； 

12)用户选择要显示的页码n，由浏览器向气象信息共享平台发出请求； 

13)气象信息共享平台使用第5步中获得记录集句柄，向数据查询接口发出请求，申请获取第n页的起始和终止时间； 

14)数据查询接口查出第n页的起始和终止时间，并将其返回给气象信息共享平台； 

15)气象信息共享平台根据上一步得到的起始时间和终止时间调用数据查询接口对所有气象要素进行查询； 

16)数据查询接口收到查询请求后，向气象要素管理系统下发所有气象要素第n页时间范围内的历史数据查询请求； 

17)气象要素管理系统完成查询，并向数据查询接口返回查询结果； 

18)数据查询接口收到查询结果后像气象信息共享平台返回查询结果。 

北京气象局气象信息共享平台采用气象数据实时数据库系统之后，系统性能得到极大的提升，以下将分析比较采用Oracle数据库与气象实时数据库的性能。测试环境如表1所示。 

表1气象要素历史数据查询效率对比测试软硬件环境 

测试一：完成Agilor实时数据库与Oracle关系数据库在不同数据总量情况下对同一时间段相同要素的历史查询性能对比。 

测试案例中，记录总数从93万条增加到220万条；每次查询的时间范围为系统随机产生的30天；查询要素为所有观测站的温度、风速、湿度、气压。每项查询运行30次，取其平均值作为该记录总数下的查询时间消耗。测试结果如图10所示。 

通过测试得出，记录总数对Oracle的查询性能影响很大，而对Agilor的查询性能影响很小。 

测试二：，完成Agilor实时数据库与Oracle关系数据库在数据总量相同的情况下对不同时间范围相同要素的查询性能对比。 

测试案例中，记录总数为220万条；查询时间范围分别为3个月、9个月、24个月；查询要素为单一观测站的温度、风速、湿度、气压。每项查询运行30次，取平均值作为该查询时间范围的查询时间消耗。如图11所示。 

通过测试得出，记录总数相同的情况下，随着查询范围的增加，Oracle的查询时间增长比Agilor的查询时间增长要快的多。 

Claims (10)

1.一种基于实时数据库的气象要素数据组织录入方法，其步骤包括：

1)在实时数据库中建立气象要素实时数据存储模型，所述模型以自动站站号和要素名称为基本数据单元，基本数据单元的数据以时间戳顺序存储；

2)从自动站采集的各气象要素数据根据其站号及要素名称检索其对应的基本数据单元，将各个自动站的每个气象要素与实时数据库系统中的一个基本数据单元对应；

3)采用数据组包发送机制和主内存方式将采集的数据录入实时数据库。

2.根据权利要求1所述的基于实时数据库的气象要素数据组织录入方法，其特征在于，所述基本数据单元命名规则为：站号_要素名称。

3.根据权利要求1所述的基于实时数据库的气象要素数据组织录入方法，其特征在于，所述数据组包发送机制为：将采集的数据进行组包，形成大数据包再发送。

4.根据权利要求3所述的基于实时数据库的气象要素数据组织录入方法，其特征在于，将采集的站号及要素名称转换为基本数据单元ID，形成数据更新元组进行组包。

5.根据权利要求1所述的基于实时数据库的气象要素数据组织录入方法，其特征在于，主内存方式为实时数据库系统中所有数据单元的数据信息都存储于内存中。

6.一种基于实时数据库的气象要素数据查询方法，对以权利要求1方法录入实时数据库的气象数据进行查询，其步骤包括：

1)客户端提出查询请求，实时数据库完成对查询请求的解析，解析出查询要素信息、时间范围；

2)对于条件查询，完成对条件表达式的解析；

3)查询出气象要素名称及相应时间范围内的历史数据；

4)对气象要素历史数据排序生成一条记录放入记录集；

5)将记录集句柄和记录数返回客户端。

7.如权利要求6所述的基于实时数据库的气象要素数据查询方法，其特征在于，所述步骤4)只对每个站点的第一个要素数据按照站号和时间进行排序，根据站号和第一个要素数据的时间戳来匹配同一条记录的其他要素的数据，并组合成一条记录。

8.如权利要求7所述的基于实时数据库的气象要素数据查询方法，其特征在于，采用归并排序算法进行排序。

9.如权利要求6所述的基于实时数据库的气象要素数据查询方法，其特征在于，所述步骤5)采用数据批量发送机制将记录集发送到客户端，具体为：

9-1)从批量数据获取请求中解析出记录集信息、记录开始位置和所需获取的最大记录数；

9-2)将记录集当前位置移动到请求中指定的开始位置；

9-3)从记录集中依次记录添加到批量记录集中，直至满足终止条件；

9-4)将批量记录集和已发送记录数返回到客户端。

10.如权利要求6所述的基于实时数据库的气象要素数据查询方法，其特征在于，所述终止条件为本次批量记录集记录数大于等于请求的最大记录数，或记录集读取完最后一条记录。

Images