|
随着气象现代化建设的迅速推进，目前，苏州建设的气象监测设备类别至少 20 种，各类气象业务系统近 20 个，在对外发布手段方面，除了传统的 96121、短信、传真、网站、还增设了微博、微信、预警显示屏、移动客户端、气象公共信息传媒等新兴服务渠道。从数据流向角度讲，各系统分散孤立的数据存储，各式各样的数据处理流程，给气象数据的分析、融合应用、公共服务和数据管理带来较大不便。另外，面向同一地区的新气象探测设备种类、站点总数不断增多，数据采集频率已精密到分钟级，由此带来的气象数据量和数据相关的急速增长给气象数据的传输、存储、管理、应用、共享等方面带来极大挑战。原有气象数据的分散存储，不同程度的无规则数据管理已不能满足现实需要。同时，来自气象业务、科研以及政府、公众不断增长的气象公共服务需求，必然要求后端的气象数据库管理系统在集约化和标准化的原则下，充分利用成熟的商业数据库技术和大气科学领域的相关技术加以构建。 目前，面向地市级气象业务的数据库系统大致存在以下几个方面的问题急需解决：①数据管理分散，多种气象观测数据的存储和设计，分散在不同的物理机器和库表中，形成“信息孤岛”，没有一个完整的基础数据库系统。②数据存储不规范，需要制定面向多种观测设备的库表数据命名规则和标准，并进行数据类型划分。③数据流程不统一，多种观测设备之间缺少统一的数据采集、传输、入库、备份流程。④应用系统开发复杂，没有形成以数据为核心的应用开发模式。同时，气象业务对数据的需求具有种类多样性、时效实时性、数据可靠性。因此，面向地市级气象部门数据管理和应用所面临的诸多问题，根据气象数据库建设需要和业务需求，建立一个统一管理、存储规范、开发灵活、应用高效、可靠性的数据库系统非常必要，这也是气象业务、公共服务得以有效开展的基础性工作。 本文从苏州实际气象业务需求出发，对数据库系统进行整体架构与设计，以增强多源数据的可靠性、数据处理灵活性和数据存储应用的规范性。本文基于 MQ 消息中间件技术、元数据技术、访问接口技术设计并实现了一种面向多种气象数据的业务流程处理方法，以实现多种气象观测资料的采集、传输、入库、备份的统一处理，MQ 消息中间件和元数据的技术选择，增强了多源气象数据处理的灵活性和可扩展性。同时，气象数据逻辑层面和物理存储方面对气象数据进行层次划分、规范定义，为地市级气象部门数据库体系架构提供一个整体的解决方案。 气象数据库系统建设是气象现代化的重要组成部分，也是气象业务的基础性工作。近年来，在标准化、规范化的气象数据的有效组织、管理和气象数据库系统建设方面也取得了不少成果。 马渝勇针对四川省气象业务对气象信息管理与共享服务需求，提出一套适应省级气象业务服务需求的典型系统，建立集约化的气象数据库系统，通过中间件的支撑，提供开放式的气象信息共享服务。华建生面向海量气象数据的处理存储和检索难题，开发了一种基于Oracle数据库的存储系统，采用元数据技术对气象数据进行管理。华韵子]建立基于分布式的气象数据管理模式，采用多层系统架构，实现物理上分布、逻辑上统一的长三角区域气象数据资源组织与共享。高峰利用元数据的灵活性、可维护性，将元数据技术应用到实时气象数据库系统中，将气象资料存储系统整个业务工作流、信息流有效地管理了起来。徐海针对民航气象数据库实时性、数据量大的特点，采用分布式数据库设计，基于Oracle9i平台，利用分区技术简化数据库大表管理，明显改善了数据查询性能。牟艳彬[7]基于Oracle10g平台，采用统一的数据模型，实现了七大气象中的数据库业务系统的建设，满足了气象资料的有效存储和快速检索。 本文基于地市级气象部门气象现代化建设与公共服务需求，对于多种探测资料在存储、应用中存在的资料繁多、数据源分散、流程不统一等问题，引入MQ消息中间件技术，通过数据逻辑结构、物理存储的划分和采集过程中的消息规整等一系列操作，实现气象数据采集流程的统一，并具有一定的灵活性、可扩展性。同时，采用元数据技术进行数据的灵活配置管理。该系统已成功在苏州市气象局实际业务中部署，系统运行稳定、高效，达到气象数据统一管理、规范调用的应用效果。 1 体系架构
气象观测设备种类多样性，数据应用的广泛性和其构成的多样性，以及灵活多变的应用需求决定了气象数据库系统和应用开发架构可以采用分层架构思想。具体体系架构如图1所示。 按照分层架构思想由下到上将系统分为基础监测数据层、中间产品层、业务逻辑层、前台表现层。而除了前台表现层的开发，其他3个层次都将贯穿于气象数据库系统建设当中。基础数据层主要负责面向各类气象数据的最直接的数据采集、处理、存储。从物理存储、逻辑层次对需要存储的各类数据进行精准划分，提高数据的存储稳定性。中间产品层解决从气象数据到气象信息的转化，是统计、生成基于基础探测数据衍生出来的，更加贴近实际业务使用的中间数据或产品。业务逻辑层是根据气象业务系统开发需要，进行功能抽象所得到的各种应用接口、业务组件，是以数据为核心的应用开发模式的集中体现。前台表现层是指基于业务逻辑层开发的各种数据库层展示平台、公共服务系统和信息发布平台等，前台表现层的设计需求不断扩展着业务逻辑层、中间产品层和基础数据层的设计和开发。这种分层结构方法，各个层次各司其职，将有利于以气象数据为核心的应用开发模式的形成，开发简便、分层解耦，增强了应用开发灵活性。 2 存储模型
气象数据主要来源于各种观测设备数据采集系统，种类繁多，形式多样，且气象业务、科研、公共服务对气象数据的使用需求也复杂多样，建立标准的、规范化的、适宜于地市级气象业务需求且具有一定扩展性的气象数据存储模型是气象数据得以有效传输、管理、共享、应用的关键所在。 2.1 数据存储分类
根据分层架构中基础数据层的数据存储类型的分类，根据业务和服务需要，将气象数据存储类别分为6大类（表1）。数据库系统采用基于Linux操作系统环境的Oracle数据库，建立6个对应方案分别存储对应的数据，运用Oracle自带的对象同义词(Synonym)，通过预先编制好的存储过程，将需要使用的方案对象映射进去方案，实现数据统一管理。
2.2 存储与访问规范
气象资料和各要素的分类与编码规范，参照《江苏省地县一体化平台数据命名规范》，该规范在常规气象资料的管理和规范上采用国家已有的标准，引用《气象资料分类与编码》[11]和《气象要素分类与编码》，其中在资料种类划分、时间、地域命名等方面都参照规范执行，对规范中未涉及的非常规资料种类、要素命名等，本文参照规范制定的思想对资料进行编码存储。 (1)表结构命名。表结构的命名采用长序列字符串分隔命名方式。表结构命名遵循“T_地域属性_表类型_资料种类_要素_时间属性(可选)_后缀(可选)”[10]命名顺序，表类型、资料种类、要素等具体类型可以根据需要自行扩展。采用大写英文缩写对各命名项进行命名。部分表类型和资料种类划分如表2所示。
(2)市县装备编号命名。市县两级气象装备统一命名，对于非常规资料的装备首先对数据库存储对象即每类气象观测装备进行统一编号并制定了《苏州市气象局装备编号命名规范》。装备编号能够同时体现装备类别，所在区域及编号，命名规则采用6位中英混合的编码方式，前两位为双资料编码的前两位字母，第3位为区域编号，区域编码顺序参照“中国苏州”网站的区域划分顺序进行编码，后3位为站点顺序编号。如张家港的臭氧监测仪装备命名为OZ0001，OZ取OZONE的前两位，第3位0表示所在区域为张家港市，后三位001为装备顺序编码。装备统一编号打破了原有的以设备厂商主导的观测设备建设和数据存储方式，有利于市县两级的气象装备统一管理、数据存储和数据产品的组合应用。 (3)接口规范。在图1分层架构业务逻辑层中，定义了数据、产品封装接口、业务逻辑接口，为了规范接口访问规范，本文制定了接口命名系列规范，以增强接口功能的可靠性，接口函数命名系列为“资料类型_数据类型_接口功能_时间属性(可选)_后缀(可选)”，如空气质量PM10的统计接口命名如下： public DataTale OBSE_HAZE_PM10Statistic_TimeSpan(string BegainTime, string EndTime, string[] Stations, out int ErrorInfo) /业务逻辑代码； 在OBSE_HAZE_PM10Statistic_TimeSpan中OBSE表示观测资料，HAZE表示覆盖测类资料，PM10Statistic表示接口功能（PM10数据统计），TimeSpan为时间属性，表示接口功能是实现某一时间段的数据处理。同时，对于系统返回的错误信息out int ErrorInfo也进行了错误码的规范化定义，部分错误码定义如下：0表示输入参数有误，1表示接口执行错误，2表示数据不完整。系统实现了两类接口定义，分别为Webservice和WCF。 3 数据采集
本系统基于RabbitMQ[13]消息中间件技术实现了一种气象数据传输和采集方法，总体框架设计如图2所示。图2中，系统将消息队列分为数据队列（包括采集数据队列和应用数据队列），监控日志队列，分别负责气象采集数据和监控日志数据的信息接收、路由配置。前台开发B/S数据管理平台实现对气象监测设备管理、采集端管理、中心服务器配置等功能。在整个框架中，分为数据采集客户端、综合数据处理服务端和消息队列等，数据采集客户端负责数据的实时采集与消息发送；消息队列负责数据的接收、综合数据处理服务端负责数据解析、提取与入库。针对气象监测设备数据采集需求，实现了大气成分、风扇线、温室气体、道面监测仪等多种资料的数据统一采集、传输和入库管理。数据库系统存储环境为基于RedHat Enterprise Linux 6.4操作系统系统的Oracle 11 g R2。并实现了两台数据库系统的集群和实时热备，增强了系统可靠性。 3.1 气象数据处理流程
多源气象数据统一、通用的数据处理流程如图3所示。 步骤1：各项测数据采集客户端将最新采集数据通过消息规整发送消息DataMessage到对应的MQ队列。
步骤2：综合数据服务端负责监听MQ数据队列到达情况，并对DataMessage数据解析、要素提取、并根据消息与元数据映射关系将数据录入基础数据库中。
步骤3：根据应用需要分别录入到分钟数据表、整点数据表、不同时间数据表中。
步骤4：根据预先定义好的质量控制规则库，对基础数据进行质量控制，并填写质控字段。
步骤5：将基础数据定时统计，并发送到应用数据队列，存入统计数据库中。
步骤6：基于基础监测数据，统计数据库进行产品处理，形成产品数据、文件产品，并推送到产品库和文件服务器，供应用统一调度使用。
步骤7：在业务逻辑层对数据、产品进行业务逻辑封装，形成Webservice和WCF统一访问接口。
步骤8：对气象数据、服务产品定期数据归档，对原始采集数据进行定时备份和手动备份到市局中心服务器。 3.2 通用采集客户端
观测数据采集客户端主要实现所有观测数据报文的采集、解压、报文解析、要素解码、提取、生成指定报文格式，发送到观测数据队列。观测数据采集客户端都以 Windows 服务形式托管，客户端集成多种采集方式，主要包括：单文件采集、文件累加采集、压缩文件采集等。支持采集记忆功能，如系统可以自动完成网络异常时所丢失的数据进行再次采集和传输。 对于种类各异的非常规气象观测数据，采用配置的形式来完成观测数据的采集。配置信息主要包括：基本信息、队列服务器配置与详细配置 3 部分。基本信息包括：采集客户端编号、监听地址与端口、采集间隔设置、服务名与描述等。队列服务器配置包括：队列地址与端口、队列用户名与密码、数据交换方式、数据与日志队列名等。详细配置包括：装备站号、要素、文件夹路径、文件与文件目录格式、数据解析分隔符等。通过以配置形式完成的通用采集客户端编号，达到了一种气象观测资料在采集环节的统一处理，有益于市县一体的数据的集中存储和组合应用。 4 元数据设计
元数据是关于数据的说明性信息，是关于数据的数据或描述数据的数据。元数据除了用来描述数据外，在数据管理特别是在数据共享、资源发现、知识管理等方面作用越来越重要。面向多种气象数据在数据格式、种类方面的多样性，以及气象数据的存储需要满足可扩展性好、灵活性高等特点，本文基于元数据技术，通过海量气象数据的相关描述信息实现对多种气象数据的发现与定位。结合 MQ 消息解析的灵活性，能够将消息数据映射到数据库中某个数据表的指定字段，实现气象数据的灵活解析与入库需要。 4.1 气象元数据存储模型
根据地市级气象部门实际应用需求设计并实现了一种气象元数据存储模型。对基础数据层所涉及的数据逻辑结构的属性进行登记，并实现了通过 B/S 数据管理平台对元数据的进行浏览、查询和关键字搜索，同时实现了通过 Oracle 存储过程自动更新元数据功能。 气象元数据存储模型主要包括：表字段元数据描述表、数据类型描述表、采集客户端类型配置描述表、数据采集策略配置描述表等。其中各种配置描述表负责 MQ 消息与数据库物理存储的一一映射。部分表字段元数据描述如表 3 所示。
4.2 消息与元数据映射
采用消息中间件 RabbitMQ 技术，使得气象数据通过收发消息在不同应用程序之间流转，以达到程序解耦合的目的。每个观测数据采集客户端实时采集到的数据以消息的形式发送到对应的消息队列，而消息数据如何存储到数据库中某个表字段中，则是通过消息与元数据之间的映射关系来实现的，同时，这种数据入库方式增强了系统灵活性。综合数据服务端负责多种气象数据的解析入库，程序启动后，首先加载数据库中气象数据采集与元数据的配置关系表，并监听数据队列，当有新数据到达时，根据消息格式进行数据解码，同时验证数据有效性，然后根据消息与元数据的映射关系将数据路由到指定库中对应表和字段中。部分大气成分监测 CO 监测仪数据采集消息与元数据映射关系配置如表 4 所示。表 4 中，“索引”栏，可以看到 CO 数据采集消息数据中的第 0 列通过 B/S 数据管理平台被映射为 T_LOCAL_OBSE_HAZE_COMO 数据表中的 N_COCONC 字段，即 CO 浓度数值，第 4 列映射为 D_CREATE TIME 字段，即入库时间字段。 表4 CO数据采集消息与元数据映射关系配置(部分)
5 气象资料备份
在地市级的数据库传输环境中，由于在每一类气象观测资料采集前置机罩几乎都是由一台PC机完成，原始采集文件则存储于这台PC机上。而PC机的硬盘通常未做RAID，可靠性并不高，所以，气象原始资料存在丢失的可能性，因此，为了提高气象数据采集的可靠性，本系统实现气象资料的自动备份和手动备份两种备份方式。采用WCF中TCP通信协议，所有采集客户端均连接到一台指定的市局备份服务端。将符合条件的数据采集文件(匹配文件的最后修改时间)直接定时备份到服务器端。服务端将接收到的文件按照对应的目录结构存放，均保持原有文件名。资料备份的目录组织结构为：Bak<年份\设备类型\站号\日期\具体到月>。如太湖“金墅”浮标的资料备份目录组织结构示例为：Bak<2015\BUOS\BU4001\201503\JinShu_storage.dat> 6 数据支撑布局
系统建成前后，在气象监测、预报预警、服务等业务系统的数据支撑布局发生较大变化，应用系统开发方式由原来的以业务系统为单位逐步转向以气象数据为主线的开发模式，这样将更加有益于气象数据的融合分析、挖掘等，应用开发更加灵活，层次清晰。业务系统数据支撑布局改变情况如图4所示。 图4中，之前的业务系统和展示平台是直接面向各种分散的由各厂商提供的气象监测数据或者文件，是一种典型的用户开发架构，存在业务系统和数据的耦合性高，不灵活等问题。而系统建成后，业务系统的开发不仅直接面向基础数据库，通过基础数据库的建设和监测数据的整合，在此基础上，生成各种中间产品，封装各种业务逻辑和数据产品访问接口以支撑各种气象业务系统的开发应用。系统建成前后数据支撑对比分析如表5所示。 基础设施体系系统采用统一的数据访问优化策略，例如：数据和索引建在不同分区，按日期和站点组织数据，表字段尽量避免字符型等，同时，在硬件的性能上，较之前服务器有较大提升，使得数据检索效率较高。以多站点的PM2.5数据访问为例，经测试，数据检索效率较设备厂商的数据量提高了1.2倍以上，经分析得知，原有的数据库日期字段为字符型(有时需要全文检索)，没有建立索引，同时，每个站点分类存储，组合查询效率低，而这些弊端在新的基础数据库中都得到了避免。 系统建成后，在核心业务系统支撑方面，涉及到一个业务切换和应用切换的过程。目前，该库支持苏州气象环保数据共享平台、综合监控系统、精细化客观要素预报集成等平台，没纳入到该系统支撑范围内的，还沿用原有老数据库的支撑，在未来两年内我们将把气象监测资料展示平台、智能化预报业务综合研判平台、天气个例系统以及各种对外服务系统(如网站、手机APP客户端)等业务系统逐步纳入到该系统的支撑范围内。 7 结语
本文面向地市级气象部门气象现代化建设与公共服务对于气象数据的应用需求，对于多种观测资料在存储、应用中所存在的资料繁多、数据源分散、流程不统一等问题，以数据为核心，围绕数据库及周边应用，采用分层架构思想，提出一种面向地市级气象数据库的设计方法和整体解决方案。设计了气象数据的物理存储模型和数据统一访问规范。同时，基于RabbitMQ消息中间件和元数据技术提出一种基于多种观测资料的气象数据统一处理方法，完成了多种气象资料数据采集、传输、入库等流程统一，增强了系统灵活性和可扩展性。目前，该系统已在苏州市气象局实际应用环境中部署，实现了大气成分、浮标站、闪电定位仪等10类气象资料的统一采集、传输、存储、管理和应用。为气象数据管理和公共服务提供稳定、高效的数据支撑。 参考文献： [1]韩笑,王力,王吉滨,等.一种地市级气象数据库的设计与应用[J].气象科技,2015,43(06):1053-1059. 特别提醒：物联网专业交流群欢迎物联网行业相关的人群加入，同时群内欢迎各路社牛、大咖、前辈加入，群内除了不能发敏感内容、色情内容，以及不太建议多次发送推广内容，其他内容皆可畅聊~——交流QQ群724511126，进群的朋友请备注：姓名-单位-研究方向（无备注请恕不通过），由编辑审核后邀请入群！ | 
发表于 2025-10-5 06:02:02