基于大数据技术的实时卫星数据监视系统的设计与实现＊

张 晓,孙 超,王旻燕,陈文琴,曾 乐

（1.国家气象信息中心，北京 100081；2.中国气象局地球系统数值预报中心，北京 100081）

1 引言

气象观探测数据和产品是气象业务、服务和科研的基础[1]。目前国家气象信息中心收集到的数据资源已经超过43PB，年增量达到7PB。从20 世纪90年代开始，中国气象局在气象数据的科学管理及服务方面做了很多的工作，1992年开始探索建立气象数据库系统[2-3]，但功能单一且服务方式简单，并未得到全部应用。2006年建设了国家级气象数据存储检索系统（MDSS）[4]实现了对部分气象数据的在线存储管理。国家卫星气象中心建设了风云气象卫星数据存档与服务系统[5]，对风云卫星数据进行统一的管理。但上述这些研究主要解决的是气象数据在存储和管理方面的问题，并没有切实解决气象数据缺乏监视的问题。直到2016年国家气象信息中心建设的全国综合气象信息共享平台（CIMISS）[6]开始业务化运行，才使得对于气象数据的统一管理和监视有进一步的发展，在此过程中，对于卫星数据的存储和服务模型进一步建立起来[7]，对卫星数据的监视提供了存储和数据基础。2017年起，为落实中国气象局发展智慧气象和全面推进气象现代化的工作部署及“气象综合业务实时监控系统”项目[8]推动下，气象卫星数据的监视体系逐渐规范和完善起来。

卫星遥感作为地球环境信息动态监测的重要手段，获取多光谱、多时相、多分辨率遥感资料，其应用领域越来越广泛[9]。近年来，随着卫星遥感技术的发展以及国民经济的发展，不管是在防汛救灾方面还是数值预报方面都对卫星数据的需求日益增长。但由于全球气象卫星事业的快速发展，卫星的种类越来越多，卫星上所搭载的仪器种类也更加丰富。在业务需求的引领下，国家气象信息中心作为国家级气象数据中心和世界气象组织全球信息系统中心（GISC），到目前为止正实时接收国内外64 颗实时卫星的资料，包括15 颗静止卫星以及49 颗极轨卫星，这使得卫星数据具有海量以及多源异构性的特点。

针对以上问题，借助于气象综合业务实时监控系统[8]的项目支持，设计并实现了针对卫星数据的监视系统，利用文件名规则使得不同特性的卫星数据能够分开，并利用大数据技术搭建系统框架，实现卫星数据分星、分仪器、甚至分产品进行监视。

2 系统设计

2.1 总体设计

近些年，随着气象标准化、一体化的总体要求，国家气象信息中心构建了气象综合业务实时监控系统来监控核心业务的状态。气象数据则是所有气象业务的基础，为了更好地保证气象数据的准确、及时传输，对气象数据的全生命周期监控就显得尤其重要。监视系统主要是针对数据的收集、分发、处理入库、同步等环节进行统一监视，采集的指标如表1所示。

表1 数据全生命周期监视指标

所有气象数据按照气象行业标准《气象资料分类及编码》[10]，以面向服务的维度建立了气象数据四级分类体系（简称四级编码），1 级划分为14 大类，2 级为具有核心元数据定义的气象数据集，3级为在2级分类下面向服务的数据子集，4级为数据流经各业务环节的过程实体记录[6]。通过建立数据血缘关系及衍生过程之间的实体数据的关联关系，实现了数据上下游传输处理环节的对应流转及处理过程的追踪，业务监控系统对重要气象数据的收集、分发、处理入库、同步等环节的完整性和及时性情况进行统计展示和自动告警。

系统整体架构可以分为采集层、缓冲层、处理层和存储层，如图1所示。

图1 系统总体框架

采集层主要是采集各个业务环节的日志信息，这些日志信息是由数据传输的不同环节发出并经过处理之后的信息，存储在ES 数据库中，包括了数据在流转过程中的详细监视信息（DI）和错误记录（EI）。

由于卫星数据的日志信息每天能够产生1000 万条，直接发送给处理层，会造成处理层的积压，影响计算性能，因此设计了利用Kafka消息队列的方式进行缓冲，数据先发送到Kafka消息队列再发送到处理层进行统计计算。

处理层采用Spark Streaming来实现实时计算，进行监视信息的预处理、监视指标的计算以及告警计算。

存储层负责存储计算之后的数据：监视指标存储在ES库中，告警信息存储在MongDB 中。为了保证更好的用户体验以及系统性能，设计了redis 缓存机制，将计算结果在redis缓存中保存，前端界面读取缓存中的数据进行展示。

2.2 模块设计

卫星数据监视系统需要实时采集卫星数据传输到各个环节的监视信息，并进行统计计算，将卫星数据的到报和入库情况简明、清晰、直观地展示出来。

卫星数据监视系统由配置模块、统计模块、告警模块和展示模块组成，各模块功能结构及模块划分如图2所示。

图2 系统模块结构图

展示模块面向的是用户和运维人员，利用曲线图和柱状图的方式全面展示卫星数据从收集到处理入库的情况，并能够提供详情查询，供用户和运维人员浏览详细信息。展示界面利用手动触发以及定时触发的方式刷新数据，在兼顾性能的情况下，保证用户和运维人员能够看到最新数据的情况。

统计模块在监控库中抽取卫星数据收集、处理环节按照标准规范输出的能够反应卫星数据完整性和及时性的详细监视信息（DI），根据配置模块中定义的卫星数据信息对DI进行统计分析，生成收集和入库环节的文件数和文件大小以及及时率等关键性能指标。

告警模块是对统计模块计算出的关键性能指标进行阈值判断，对超过阈值的关键性能指标按照标准规范输出告警信息（EI），告警信息应简单明了，可读性强，能够使得运维人员迅速定位问题。

配置模块主要是实现卫星数据的快速接入，此模块依托气象数据集核心元数据以及四级分类编码所组成的气象数据元[6]，利用基于消息中间件的同步技术，实现卫星数据元数据的上下游各个环节的同步及统一管理。

3 系统信息处理

国外的卫星数据由国际通信系统（GTS）接收，转发给收集与分发系统，国内卫星数据由收集与分发系统直接接收。收集与分发系统在收到国内外的卫星数据后会对数据文件进行数据预处理（主要包括文件名和格式的检查），将数据文件发送给处理入库系统进行处理入库（主要包括文件名转换、解码入库等），文件实体放入共享文件区（NAS），为用户提供文件服务。整个处理流程都由元数据及四级编码贯穿始终，每个环节都会发送详细监视信息（DI）供监视系统提取使用。卫星数据的流转过程如图3所示。

图3 气象卫星数据流程图

下面详细介绍对监视信息的处理过程。

3.1 编码及文件名规则匹配方法

由于目前对于卫星数据的四级分类体系划分的四级编码不能满足监视的需求，按照气象行业标准《气象资料分类及编码》[10]的规定并结合气象行业标准《气象卫星数据文件名命名规范》[11]中对于卫星数据文件名的规定对四级编码体系进行了扩充。

为了适应数字化气象数据的规范管理，中国气象局发布了《气象资料分类与编码》行业标准，此规定气象数据按照内容属性和来源属性划分为十四大类，各大类气象数据按照其资料特性，选取内容属性、区域属性、时间属性、空间属性、来源属性、观测属性、格式属性等的不同组合进行分类（二级分类）[10]。对于卫星数据来说，第一级为K，表示卫星数据，第二级应选取产品等级属性、卫星类别属性、波段属性、区域属性按先后顺序的组合进行。在实际业务中，共定义了四级分类编码，第三级为第二级基础上面向服务的数据子集，第四级为流经系统各个环节的实体记录。由于这四级分类编码无法表示所有卫星数据特性，大部分表示的是卫星类别属性及产品类别，在前四级编码无法修改的前提下，为了满足监视的需求，对四级编码进行了扩充，定义了第五级编码，第五级编码为前四级编码无法表示的其余卫星数据特性，主要包括更详细的卫星数据信息，例如覆盖范围、仪器类型、空间分辨率等，这些更详细的卫星数据信息来源于通信系统中传输的卫星数据的文件名。

按照气象行业标准《气象卫星数据文件名命名规范》的要求，气象部门通信系统中传输的气象数据共分为三种类型的文件名：短格式文件名、基本格式文件名和完整格式文件名三种类型[11]，来适应存储和应用的不同需求，但总体可以按照如下结构表示：Z_SATE_生产中心_系统接收时间_卫星名称_仪器名称_数据区域类型_数据级别_可选信息字段标识符_[数据名称_][仪器通道名称_][投影方式_]观测起始日期_观测起始时间[_空间分辨率][_接收站名].数据格式。其中[]中为可选信息字段。在四级编码基础上，结合标准的文件名中的属性信息的顺序组合，就可以定义出卫星数据的五级编码，并保证每种卫星数据对应唯一的五级编码。利用此种方法就可以在不改变通信系统业务逻辑的基础上，在监视环节将卫星数据分开监视。

文件名规则与编码匹配规则在配置模块进行配置。

3.2 监视信息预处理

数据预处理包括对详细监视信息（DI）的筛选和合法性检查、时间规整、与配置信息关联等，处理流程如图4。

图4 监视信息预处理流程图

1）监视信息筛选及合法性检查。检查监视信息是否符合业务规范，是否有效，是否能够反映气象数据的真实情况。提取出符合要求的监视信息之后根据卫星元数据信息以及四级编码筛选出所需要监视的卫星数据的监视信息。

2）时间规整。卫星数据到报和入库时间是不规整的，为了便于监视，要对DI 中的时间进行规整，按照监视的需求，当前是采用等间隔采样法，将时间序列按照1 小时间隔进行切分，对时间序列进行规整。

3）文件名规则匹配。利用四级编码对DI 信息进行初筛，对DI中包含的卫星数据文件名进行分析，将卫星特性字段进行提取组合，并关联上第五级编码。

4）关联配置信息。将DI与配置信息相关联，采用Rest API接口的方式，将配置模块中配置的信息通过API接口进行对接。在配置模块中配置了某一种卫星数据的基础信息，包括卫星类型、仪器类型以及告警规则。

卫星数据采集软件从日志信息中采集到所需的监控信息并经过处理之后发送给Kafka集群。Kafka集群的Topic按照数据流转环节和类型进行划分，如收集环节详细监视信息的Topic、处理入库环节详细监视信息的Topic 等，Consumer为数据处理环节的Spark Streaming计算环节订阅接口。

Kafka是基于Zookeeper协调服务的分布式消息队列系统，其核心功能为高吞吐量的发布-订阅消息服务，主要应用于日志收集和消息队列服务，可在廉价的商用机器上实现数据的高吞吐和高可用。Kafka消息队列是由生产者Producer、消费者Consumer、代理者Broker和提供分布协调服务的Zookeeper组成。

Producer将消息推送到由若干Broker节点构成的Kafka集群，Kafka集群主要是用来存放接收的消息。Kafka中每组消息都对应一个主题（Topic），每个Topic 对应一个或多个分区（Partition），每个分区只能存在在一个Broker中。分区是由一系列消息组成，并且消息会不断追加，为了标记消息，每条消息都会被分配一个连续的偏移量（Offset）。Consumer 订阅消息之后会批量拉取数据，分区中消息的偏移量会随之更新。

为了提高效率，设置了多个消费者批量拉取数据，并将Offset偏移量保存下来，来保证当系统出现故障恢复之后仍旧可以从故障前的位置继续消费，保证了数据不会被丢失或者重复消费。

采用Rest API[12]接口的方式来进行各模块间数据的调用，此种方式使得前后端分离，各模块间相互独立，数据通过URL进行传递。

3.3 监视信息统计计算

对监视信息进行预处理之后，就能够得到规范化的监视信息，通过分析卫星数据的时效，图5中展示了德国GNSS掩星数据时效情况，可以得知，卫星数据由于其业务特性，会出现延迟到达的情况，并且数据到达的时间跨度大，因此设置程序每5 分钟统计一次监视指标，并在缓存中存储8 个数据周期，能够满足大多数卫星数据的监视需求。

图5 德国GNSS掩星数据时效情况

通过上述方法，既能够保证卫星数据的统计时效，又能够保证前端能够实时获取卫星数据到报和入库的情况。

监视信息统计计算环节采用Spark Streaming 技术处理实时的监视信息。

Spark Streaming的处理机制为：接收实时输入的数据流，根据一定的时间间隔将数据流进行拆分，拆分后的数据会通过一个先进先出的队列，Spark引擎会从该队列中依次取出一个个批数据，并把批数据封装成一个RDD，然后进行处理。

Spark Streaming 读取Kafka 中的消息并进行解析处理，考虑到卫星数据的时间跨度大，为了能够获取资料实时到报情况，会对每一种卫星数据的同一个时次每5分钟计算一次监视指标，共统计8 个数据周期，计算得出的监视指标会存在中间结果表中，每次计算之后的结果覆盖历史计算结果，通过这种方法保证迟到的卫星数据也能够覆盖到。

3.4 告警生成

为了保证卫星数据出现故障时能够及时发现，及时处理，本监视系统设计了告警模块，利用配置模块中配置的阈值对计算出的监视指标进行判断，对不符合告警阈值的监视指标进行告警，配置模块中配置的阈值通过Rest API 接口的方式进行传递，程序对告警阈值进行判断之后，生成规范的告警信息（EI），通过Rest API 接口的方式发送至统一的告警平台进行告警信息的发布，告警信息（EI）需包括告警名称、业务系统名称、故障内容、告警级别、事件类型、处理建议等内容。

图6 卫星数据监视系统监视页面简图

告警名称：对告警的概要描述，应能够清晰反映出该类告警的概况，主要格式为：〈数据流程描述〉〈每类数据流程下的具体环节业务名称〉〈数据名称〉〈业务时次〉〈性能指标名称〉〈“异常”〉。例如：卫星资料监视入库文件数告警，资料名称：NOAA-18 微波探测装置A 型AMSU-A 全球范围45公里L1C级数据，告警时次：2022-05-28，00：00，入库数异常。

业务系统名称：发出告警的业务系统。例如：天镜-卫星数据监视。

故障内容：说明异常事件的细节，对异常事件中需要发布的可变内容进行实例化描述。例如：卫星资料监视入库文件数告警，告警时次：00|[-20：00，02：59)，资料编码：K.0145.0001.S001.0004，资料名称：NOAA-18 微波探测装置A 型AMSU-A 全球范围45 公里L1C 级数据，告警类型：应入库数：3，实际入库数：2。

告警级别：用于标识告警事件的严重程度，由重到轻，分为4 级（严重、关键、警告、恢复），由告警事件生产方按照自身业务特点以及对业务的影响程度等对告警级别进行设定。

事件类型：对纳入统一管理的事件信息的分类与编码，此编码应是告警事件的唯一标识。

处理建议：针对告警事件的处理建议。一般包括具体联系人电话，以及初步的排查建议。

由于卫星数据是实时传输的，数据到达时间跨度能够到达8 小时，并且不会出现比观测时间提前到达的情况，因此告警采用的是每5分钟判断一次指标，共判断8个时次，并可根据实际情况对告警时间设置延后判断时间。

通过上述策略发布告警之后，由于国外卫星数据不稳定等原因，业务上会出现告警过多的情况，为便于运维人员定位故障点，减少无效告警，对告警信息进行了合并。合并的原则是对告警名称进行判断，对同一时次相同环节，同一种数据的告警合并为1 条，只进行告警次数的累加和告警指标、告警时间的更新。

3.5 系统功能实现

监控系统采用Spring MVC架构，Spring MVC架构提供了模型-视图-控制的体系结构，松耦合的WEB应用程序组建使得开发更加灵活。MVC 架构使得输入逻辑、业务逻辑以及前端UI逻辑分离，更加便于系统维护。

用户通过WEB 页面发送请求，此请求会转交给前端控制器，前端控制器收到请求之后会根据请求信息以及配置信息找到处理该请求的具体的处理器并对这个处理器进行封装，再利用统一的适配器接口调用处理器。同时，Spring MVC 会将请求信息转换并入参，对入参的对象会进行格式化以及数据校验等操作。在这些操作完成之后才会真正调用处理器来进行业务逻辑处理。处理器完成业务逻辑处理之后，会将逻辑视图名和模型数据信息返回给前端控制器，再相应用户。

展示界面利用手动触发以及定时触发的方式刷新数据，在兼顾性能的情况下，保证用户和运维人员能够看到最新数据的情况。

图7 卫星数据监视系统配置页面简图

配置模块实现对不同卫星、不同卫星上挂载的不同仪器的定义，并根据卫星数据的特征定义文件名规则及告警阈值等信息，使得卫星数据能够基于标准模板在线导入、注册、编辑及新增修改等操作。

统计模块将监视的关键指标计算出来之后，告警模块对这些关键指标进行阈值判断，发出告警信息，在告警台完成注册之后就可以将告警发送到告警台，实现集中监视告警并可以配置微信通知等功能。表2展示的是关键告警项示例。

表2 关键告警项示例

4 结束语

本文结合业务中对卫星数据监视的需求以及不足设计并实现了卫星数据监视系统，采用Spring MVC 架构，并利用Kafka、Spark Streaming、Rest API 等大数据技术，实现了对卫星数据的高效采集和处理，实现了卫星数据的分星分仪器精细化监视。目前，该系统已经业务应用于中国气象局实时监视系统中，为数值预报等业务提供了快速发现故障的能力。未来，基于该系统的卫星数据实时报表自动发布、对监视数据的深度挖掘以及卫星数据监视向用户端以及观测端扩展将是研究重点，以此来推动对于气象数据的全生命周期监视能力。