美国下一代天气雷达NEXRAD业务化布网后, 持续开展了大量的系统升级和改造计划, 包括建立开放型软硬件体系结构^[1-3], 大幅提升NEXRAD的技术水平和应用能力. 与此同时, 我国建设的新一代天气雷达CINRAD, 布网雷达已超210部, 探测数据被广泛应用于气象、空管、水文、地质等领域^[4], 是全球最大的新一代天气雷达网之一. 但当前CINRAD的产品生成系统与国际先进水平相比, 在系统的可扩展性、易升级性等方面尚存在一定差距^{[5, 6]}.

近年来, 随着相控阵技术和雷达组网技术在气象探测领域的研究与应用^[7-10], 传统单一整体式架构的雷达产品生成系统已不能较好地满足新体制天气雷达系统高实时、强融合的数据处理需求. 此外, 不同地区各异的灾害性天气特点, 使得产品系统的气象算法也存在较大差异. 当前雷达产品生成系统紧耦合、封闭式的框架结构无法灵活应对各类区域性气象监测的应用要求^[6].

为较好地适应气象服务和科技发展的新需求, 构建适用于新体制天气雷达系统的产品生成系统成为气象科技人员迫切需要解决的问题. 本文应用消息中间件、分布式存储、异构并行、可扩展标记语言等新兴技术, 进行分布式雷达产品生成系统的设计, 进一步提高了产品生成系统的实时性和伸缩性. 通过接入业务化试运行的福州市气象局S波段相控阵双偏振天气雷达系统, 验证了系统的高效性和稳定性, 为下一代天气雷达系统的探索提供了很好的技术支撑.

1 相关技术 1.1 ActiveMQ消息中间件

消息中间件常用于解决系统的松耦合性、异步消息和流量削峰等问题^[11]. ActiveMQ是一款由Apache软件基金会推出的企业级开源消息中间件, 具有高可靠、高性能、易伸缩等特点, 在大型系统和分布式系统中应用广泛.

ActiveMQ支持两种消息传递模式: 点对点传递模式和发布订阅传递模式. 在点对点模式下, 消息由生产者发送到队列, 并由连接队列的其中一个消费者通过拉取或轮询的方式请求消费. 在发布订阅模式下, 消息由生产者发送到主题, 并由订阅主题的所有消费者通过推送的方式接收消费^[12]. ActiveMQ消息中间件提供的与底层平台无关的消息传递机制, 是实现分布式应用在异构系统之间进行高效可靠数据交互的重要途径.

1.2 Ceph分布式存储

Ceph是一种去中心化的、高度统一的开源分布式存储系统, 能够同时支持兼容POSIX标准的文件存储、块存储以及对象存储3种接口, 具有高可用、高可靠和高可扩展的特点^[13].

Ceph分布式存储系统主要包括4大组件: 对象存储设备OSD、监视器Monitor、元数据服务器MDS和客户端节点. 基于CRUSH算法的数据平衡策略, 摒弃传统集中式存储元数据寻址方式, 进一步提高了系统的并行度, 消除了系统对单一中心节点的依赖^[14]. 通过Ceph分布式存储系统可以为海量气象数据提供高效的存取和管理服务.

1.3 CUDA并行计算

统一设备计算架构(CUDA)是一种由显卡芯片厂商NVIDIA推出的高性能通用并行计算架构, 该架构能够充分发挥GPU硬件强劲的计算能力和巨大的显存带宽^[15]. CUDA的体系结构由以下3部分组成: 应用开发库、运行时环境和设备驱动接口. 应用开发库为编程人员提供了一系列操作GPU的核函数和库函数. 运行时环境为应用开发提供了基础的开发接口和运行时组件, 如基本数据类型定义、内存管理、调度执行等接口. 设备驱动提供了GPU硬件设备的抽象层访问接口. 与CPU相比, GPU数以千计的计算单元和大量的高速内存, 可以显著提高气象算法数据处理的并行效率.

2 系统设计 2.1 系统需求分析

完整的S波段相控阵双偏振天气雷达系统由3部分组成: 雷达数据采集系统(RDAS)、雷达产品生成系统(RPGS)以及产品显示分析系统(PDAS). 具体的天气雷达系统组成结构图如图1所示.

雷达产品生成系统作为新一代天气雷达系统资料应用的核心处理部件主要负责接收雷达基数据, 调用一系列气象算法, 将基数据转换为多种图像格式/类型的气象产品, 并推送给用户使用. 在对雷达产品生成系统进行具体的分析梳理之后, 确定了系统的主要业务功能模块, 包括产品管理模块、雷达数据获取模块、数据处理模块、数据管理模块以及状态监测模块. 详细的系统功能模块图如图2所示.

(1) 产品管理模块: 主要包括算法模块配置、任务配置和参数配置等功能. 满足气象产品的模块弹性可伸缩, 任务动态可调整, 参数灵活可配置的要求.

(2) 雷达数据获取模块: 实时感知由单部或多部雷达生成的基数据, 同时支持接入本地存储、网络存储以及分布式存储等多来源的历史基数据.

(3) 数据处理模块: 负责产品任务的分配调度与并行处理. 气象产品加工过程包括标准化、质量控制、格式转换和产品生成, 经过执行一系列气象算法之后, 可以生成包括基本数据产品平面位置显示(PPI)、物理量产品径向散度显示(RVD)、风场反演产品速度方位显示(VAD)以及自动识别产品风切变识别(SHEAR)在内的各类气象产品.

(4) 数据管理模块: 雷达数据主要分为基数据、产品数据、标准化数据和格式转换数据4类. 该模块的主要功能包括数据查询, 根据雷达站号、数据类型、数据时间、数据级别等要素进行雷达资料的检索; 数据分发, 提供基于FTP文件传输协议的气象产品共享服务; 数据分级, 用于表征数据的重要级别, 按照重要程度分为普通、重要和核心3个等级; 数据清理, 支持基于查询结果的手动清理和基于清理阈值的自动清理两种方式, 可以有效避免因低重要性数据占用过多导致的存储空间不足问题.

(5) 状态监测模块: 实时监测系统各处理节点的CPU占用率、内存占用率、磁盘读写速率、网络收发速率及分布式存储的使用率等资源状态, 实时统计产品任务的处理进度、执行耗时等运行状况, 并提供系统日志查看功能, 方便开发人员对算法调试过程中发生的问题进行回溯分析.

2.2 系统架构

基于消息调度的分布式雷达产品生成系统, 其架构主要分为4层, 自底向上依次为数据层、通信层、服务层和应用层, 系统整体架构图如图3所示.

(1) 数据层: 分布式存储为整个天气雷达系统提供全系统可访问的高性能、高可靠数据存取服务, 同时系统支持本地磁盘、NFS网络存储等多途径的数据接入方式.

(2) 通信层: 消息中间件是分布式雷达产品生成系统之间通过消息传递进行通信和协调的重要组件. 采用JSON格式的数据交互模型, 大大简化了消息封装与解析的过程. 利用FTP文件传输协议实现了雷达资料的文件级共享, 并通过HTTP超文本传输协议为Web交互提供简单的请求响应范式.

(3) 服务层: 包含了系统中主要的业务功能, 包括产品管理、数据获取、数据处理、数据管理以及状态监测等.

(4) 应用层: B/S前端主要用于网站服务请求和数据可视化交互, 是一个Linux环境下Web前端应用程序.

3 系统实现 3.1 产品管理模块实现

针对我国不同地区各异的灾害性天气特点, 雷达产品生成系统需具备灵活调整气象算法和产品任务的能力. 气象算法以动态库的模块形式集成在雷达产品生成系统之中, 通过制定统一的接口规范标准, 形成通用的产品加工模板, 切实保证系统的开放性和通用性. 接口规范标准分别定义了标准化、质量控制、格式转换、位图产品和矢量产品等接口类型. 运用可扩展标记语言(XML)技术构建开放性高、扩展性强的算法模块和产品任务的结构化配置文件, 大大提升了对算法和任务的管理能力, 降低了用户的使用难度. 气象算法XML脚本格式如代码1.

代码1. 气象算法XML脚本格式

<modules>

　<module>

　　<name-en>VIL</name-en>

　　<name-cn>垂直液态水含量</name-cn>

　　<position>./lib/lib_VIL.so.1.0.0</position>

　　<type>3</type>

　　<activation>1</activation>

　　<params>

　　　<param>

　　　　<name-en>Type</name-en>

　　　　<name-cn>类型</name-cn>

　　　　<type>1</type>

　　　　<valueMin>3</value-min>

　　　　<valueMax>3</value-max>

　　　　<valueDefault>3</value-default>

　　　　<valueStep>1</value-step>

　　　　<unit>null</unit>

　　　　<show>0</show>

　　　　<numberInput/>

　　　</param>

　　　<param>

　　　…

　　　</param>

　　</params>

　</module>

　<module>

　…

　</module>

</modules>

每个<module>标签对应一个算法模块信息, 其中<name-en>和<name-cn>标签分别对应模块的英文名称和中文名称, <position>标签对应动态库文件路径, <type>标签对应接口类型, <activation>标签对应启用状态, <params>标签对应参数信息. XML脚本中的这些模块信息是产品生成系统允许调用访问的气象算法模块, 由用户按需配置生成.

应用前端根据配置文件内容, 实现了模块列表和任务列表的动态加载. 模块、任务配置页面如图4所示.

3.2 数据获取模块实现

雷达探测数据经一系列数字化处理之后, 输出的原始基数据以文件形式持久化保存在Ceph兼容POSIX标准的分布式文件系统或FTP、NFS等网络文件系统之上. 分布式雷达产品生成系统基于Linux内核的文件监视机制实现了对各类存储系统上雷达基数据的实时感知与获取. 通过Inotify机制监视目录的更改事件, 当发生对应监视事件时, 系统检测目录中的文件, 并根据命名规则、修改时间筛选出符合条件的数据, 送入任务执行队列, 等待系统调度处理. 该方式大大降低了系统间的耦合度, 减少了不必要的通信交互, 易于实现接入数据从单部雷达到多部雷达的扩展, 是一种高效的数据获取方案.

3.3 数据处理模块实现

数据处理模块采用基于CPU多线程、GPU并行加速以及机间协同的多级混合并行处理策略, 通过将数据加工过程合理地划分为单元级、产品级和组合级的多粒度并行任务, 由众核GPU负责细粒度的单元级并行任务, 多核CPU和多机协同负责粗粒度的产品级和组合级并行任务. 混合GPU并行计算、单机多线程和多机协同的数据处理方式, 能够充分利用硬件平台的计算资源, 显著提高系统的实时性.

高效的任务调度策略也是分布式集群降低通信开销, 提高处理效率的重要手段. 基于资源状态的异构集群任务分配算法, 采用无中心化的架构设计思想, 根据各节点发布的资源状态在集群中均匀地分配待处理任务. 该方法不依赖于中心节点的集中调度, 有效地避免了繁杂的通信交互, 实现了高效的负载均衡.

3.4 数据管理模块实现

数据管理的基础是Ceph兼容POSIX协议的文件系统接口, CephFS良好的数据强一致性和抗故障能力, 为海量气象数据的存储管理提供了有力支撑. 通过建立雷达站号、数据类型、数据时间、数据级别等目录的分层存储结构以及制定标准的文件命名规范, 设计了一种基于信息匹配的文件检索机制. 利用该机制能够根据查询要素快速定位符合条件的数据存储目录, 结合文件命名规范进一步得到数据时间精确到秒级的查询结果. 数据分级功能可以及时标注出具备典型天气特征的气象数据, 并基于FTP文件上传接口实现气象数据的分发共享. 数据自动清理功能通过定期检测数据占用空间大小, 当占用超过预设的阈值时向用户推送消息提示, 并根据数据重要级别完成自动清理, 大大简化了用户的日常运维工作.

3.5 状态监测模块实现

为方便用户直观的掌握系统资源利用状况、及时发现故障, 设计系统的状态监测模块, 通过调用Linux资源监控指令和Ceph管理指令, 可以实时获取系统的CPU占用率、内存占用率、硬盘占用率、网络收发速率和分布式存储的集群状态等信息. 不同资源监控指令见表1所示.

产品加工过程包括等待执行、标准化、质量控制、产品生成、产品保存等阶段. 进度监视功能采用WebSocket技术实时反馈产品处理的不同阶段, 同时利用高精度计时器精确统计算法模块的调用耗时, 方便设计人员对算法执行效率进行有效评估. 资源状态、进度监视页面如图5所示.

此外, 系统日志是记录系统运行状况的主要信息载体, 提供了丰富的运行信息, 包括用户操作、处理过程、故障警告等, 为系统异常分析提供了重要依据.

4 系统测试 4.1 测试环境

测试服务器配置ActiveMQ 5.16.1、Ceph 15.2.12和CUDA 11.6, 操作系统Ubuntu 20.04, 网络10 Gb/s, 硬盘容量6 TB, 内存128 GB, CPU为32核, GPU为GeForce RTX 2080 SUPER.

4.2 功能测试

本文以产品管理模块的算法模块配置为例, 对模块新增、修改、删除、应用等功能进行测试. 算法模块新增如图6所示, 系统管理员填写新增算法模块名称、路径、类型、参数等信息.

算法模块修改如图7所示, 管理员可从已配置列表里选择对应算法模块进行修改操作. 模块删除操作如图8所示.

算法模块启用开关用于控制模块在任务配置时的可用状态. 当开关打开时, 相应算法模块可在任务创建页面的产品列表中显示以供用户加载使用, 如图9所示.

4.3 性能测试

性能测试选择平面位置显示(PPI)、速度方位显示(VAD)、垂直风廓线(VWP)、风切变识别(SHEAR)4类气象产品和由此构成的产品组合进行测试, 通过同时接入来自雷达站点、网络存储以及本地存储3路雷达基数据, 对其平均处理时间进行测试, 测试结果如表2所示, 系统具有较好的并行计算能力.

5 结语

我国天气雷达技术已进入全新的发展阶段, 相控阵雷达技术逐渐成为行业热点, 如何更好地发挥新体制天气雷达的效益和作用成为迫切需要解决的问题. 本文设计研制了一种基于消息调度的分布式雷达产品生成系统, 利用ActiveMQ消息组件、Ceph分布式存储和CUDA并行计算等关键技术, 实现了产品模块的弹性管理和多源数据的并行处理. 系统运行高效稳定、功能完善、界面友好, 对天气雷达系统业务能力的提升具有一定的推动作用.