十三五期间, 我国气象观测和预报预测能力稳步提升, 2017年中国气象局天气预报业务由原来的站点预报升级为智能网格预报, 一系列多源数据融合天气实况网格产品(包括气温、降水、湿度、风、总云量、能见度等)在业务中得到应用, 但在气象服务方面供给不平衡不充分问题依然突出^[1].

公众气象服务和交通、旅游等行业气象服务对精细化天气实况产品的需求十分旺盛, 服务中主要利用6万多个站点数据或5 km的网格数据向用户提供天气实况数据服务, 由于分辨率不高, 数据服务精度与实际情况存在较大差异. 为满足气象服务的需求, 各级气象部门普遍采用多源资料融合技术等方法, 生成高分辨率的实况网格数据(包括气温、降水、湿度、风、总云量、能见度等)^[2-4]. 由于各单位获取数据的时效和融合技术差异较大, 在面向用户服务时, 存在不同单位发布的同一时刻、同一地点的实况数据不一致的问题.

依据我国行政边界、主要城市和人口分布, 天气实况要素数据的区域覆盖范围为北纬0–60°, 东经70°–140°, 根据目前气象数据站网分布以及融合技术的发展现状, 实况服务精度确定为1 km (对应地理坐标系大约0.01°), 服务时根据用户位置提取最新时刻的实况. 对于非连续的气象要素比如降水和基于降水、气温等要素反演的天气现象, 采用每5 min整体更新一次网格数据, 连续性气象要素比如气温、相对湿度等每小时更新一次. 现有的气象实况要素数据存储与查询定位时通常采用关系型数据库或内存数据库, 存在并发支撑能力不足或数据入库、更新延时高等的问题, 极大降低了数据服务的时效性.

阿里云是我国最大的云计算平台, 具备较为成熟的弹性计算能力, 多样的数据库和存储服务, 以及域名和安全等方面的中间件服务, 有利于云上应用的部署和降低运维成本^[5].

针对上述存在的问题, 按照气象信息系统安全要求^[6], 天气实况数据的制作和加工在气象专有云内部完成, 生成的服务产品通过数据交换系统快速推送到阿里云, 在阿里云上进行天气实况数据存储和提供基于用户位置的数据服务. 为平衡数据入库和查询的高时效性, 提出了一种分块存储和查询定位的方法, 将该方法应用于面向位置服务的天气实况数据服务接口系统中.

1 系统总体架构 1.1 系统架构

基于用户位置的天气实况数据服务接口系统利用阿里云进行构建, 系统由资源层、业务层和用户层组成, 架构见图1.

资源层选择租用阿里云提供的弹性基础设施服务, 包含云服务器ECS、表格存储Tablestore 、云数据库MySQL、消息服务Kafka、负载均衡SLB、专用网络VPC、云解析DNS等. 业务层包含天气实况数据服务相关的数据和应用服务程序, 数据包含用户信息、天气实况数据和用户行为信息以及相关配置文件, 采用表格存储和云数据库进行存储, 应用服务程序采用Spring Boot进行微服务开发, 包含接口用户注册与认证服务、天气实况数据服务接口、数据接收服务、数据解析与处理和运行监控. 业务层由资源层提供部署和运行支撑, 并向用户层提供应用服务. 用户层为第三方应用, 包含手机APP, 小程序或网页等, 通过RESTful方式获取业务层发布的服务, 开展天气实况数据服务接口账户的申请和数据调用.

1.2 业务流程

数据在专有云加工生成站点观测数据和天气实况网格数据两种类型的数据. 生产后快速推送到阿里云, 通过数据处理服务对站点、网格文件进行融合处理后写入到数据库, 利用服务接口的方式提供外部应用数据访问, 流程见图2.

天气实况数据服务的气象要素主要包含公众关注的常用要素, 比如降水量(含滚动1 h、3 h、6 h、12 h、24 h累计降水)、气温、风速、风向等, 具体见表1所示.

其中站点观测数据气象部门有超过6万个观测站, 降水要素逐分钟观测并实时上传, 其他要素5–10 min台站上传一次, 解析后存入气象大数据云平台分布式数据库^[7]. 根据气象数据共享的要求, 实时站点数据按照服务策略在专有云内部处理成位置精度为0.01°的站点数据产品, 每分钟生成一个文件, 用于专有云与阿里云进行交换. 文件组织为每行存储一个站的一个要素信息, 不同信息间用英文逗号分隔, 包含站号、观测时间、经度、纬度、气象要素、观测值. 比如2021年12月31日12点05分北京南郊站(编号54511)气温的观测值为2.2°, 表示为“54511, 20211231120500, 116.47, 39.81, TEM, 2.2”.

天气实况网格数据由地面、卫星、雷达、DEM等多源数据融合制作, 空间分辨率为0.01°, 区域覆盖范围为北纬0–60°, 东经70°–140°, 一个网格数据文件大约120 MB. 基于气象要素的特性, 结合气象观测的频次、加工计算能力以及公众对天气(晴、雨)的敏感度, 对于非连续的气象要素比如降水和基于降水、气温等要素反演的天气现象, 采用每5 min整体更新一次网格数据, 连续性气象要素比如气温、相对湿度等每小时更新一次, 见图3.

天气实况网格数据采用自定义的二进制网格数据存储模式, 字节顺序采用大尾, 每个要素作为一个网格文件进行数据交换, 结构说明见表2.

2 系统关键技术 2.1 数据分块存储与查询设计

按照天气实况网格数据的覆盖范围和分辨率, 1个时刻1个天气要素包含4200万个点, 面向用户位置服务, 查询服务最快的方式是一个0.01°的网格点存储一个记录. 按照MySQL数据库每秒入库10万记录, 需要420 s (即7 min)才能完成数据入库, 严重影响数据的实时性. 为平衡数据入库和查询的高时效性, 将气象服务要素进行分块存储和查询, 提高数据库查询的效率.

综合分析当前主流数据存储技术, 按照业务需求和数据特性, 通过对比分析选择阿里的表格存储(产品为Tablestore), 实现对天气实况网格数据的存储和服务^{[8, 9]}. 阿里的表格存储支持多种数据模型, 本文采用宽列模型, 数据存储表主要由主键(第1个为分区键)和属性列组成, 每个数据都具备生命周期, 见表3.

根据表格存储白皮书说明, 表格存储限制单个属性列值不超过2 MB, 可以将超过2 MB的单个值拆分成多个列存储; 一次请求写入的属性列的个数不超过1024个, 批量写入一次操作请求写入行数不超过200行; 对于行数据无属性列个数的限制, 单行数据量大小也无限制.

(1)数据分块设计

数据存储时将天气实况网格数据设计为一个三维模型, X, Y组成某个要素的网格数据(其中X为经度, Y为纬度), Z为表1中的气象要素. 为提升数据入库或更新时效, 方便数据查询定位和数据聚合, 按照0.01°分辨率, 将天气实况气象服务要素采用X方向(经度)进行1°分块数据整合, 每个分块中包含100个位置点对应的数组值. 为方便多要素组合查询, 在数据库表中将多个气象要素存储在一张数据表中, 将纬度作为主键分区列, 行数据按纬度进行hash分区到多个数据存储节点. 气象要素(气温、降水、湿度、风、总云量、能见度等)作为第2主键, 类型为字符型. 属性为分块数据标识, 1个分块设计为1个属性列, 按照天气实况网格数据的区域覆盖范围(经度70°–140°, 中国区域边界)共定义70个属性列, 属性列数据采用二进制数值存储(1个float占4个字节, 100个值为400字节), 分块数据表存储设计示例如表4.

(2)分块数据写入设计

基于上述的数据分块设计, 将天气实况网格数据按照分块方式拆分为每行数据为70×400的字节数组, 然后结合分块表结构, 形成一个数据插入SQL, 将数据写入到数据表中. 在数据写入程序中, 可采用多线程并发技术, 将数据文件按照纬度方向分为N份, 每个线程负责其中的一份, 按每行的写入方式对网格文件逐行读取和写入.

(3)数据查询定位设计

在数据查询访问时, 先根据用户的位置信息计算其位于0.01°网格中最临近的经纬度值, 利用纬度值和经度整数位的值, 得到用户所处位置对应天气实况网格数据存储最近数据点位的数据块(100个点值), 然后通过经度小数点位值, 采用字节位移方式从二进制数据块中取出对应的4个字节, 并转换为具体数值, 该值即为用户位置的天气实况数据要素值. 比如获取用户位置点A (71.5932, 0.0342)经度为71.5932°纬度为0.0342°的天气现象, 首先计算其位于0.01°网格中最近位置为B (71.59, 0.03), 然后通过查询主键定位到纬度为0.03°数据所在行, 再找到经度71.59°所在属性列lon71的数据块, 然后采用字节位移从二进制数据块中找到0.59°对应的具体数值, 如图4所示.

(4)站点观测数据更新设计

在数据更新时, 根据站点观测数据经纬度信息, 先定位和查找该点对应数据分块的值(100个值), 然后替换对应位置点的值, 最后整体更新该数据块在数据表中对应的值.

2.2 Spring Boot微服务架构

微服务是由单一应用程序构成的小服务, 拥有自己的进程与轻量化处理. 微服务架构是一项在云中部署应用和服务的技术, 是将复杂臃肿的单体应用进行细粒度的服务化拆分, 每个拆分出来的服务各自独立打包部署. 采用微服务架构可以使部署、管理和服务功能交付变得更加简单^[9].

Spring Boot基于Spring 4.0设计, 继承了Spring框架原有的优秀特性, 并简化了Spring应用的整个搭建和开发过程. Spring Boot框架中还有两个非常重要的策略: 开箱即用和约定优于配置. 使得开发人员摆脱了复杂的配置工作以及依赖的管理工作, 更加专注于业务逻辑, 同时在结构中添加信息的软件设计范式, 减少了大量的XML配置, 并且可以将代码编译、测试和打包等工作自动化^[10-12].

本系统中利用微服务的理念对用户认证, 服务接口, 用户注册等模块进行微服务设计和部署, 采用Spring Boot进行开发, 以便应对系统功能按需升级优化以及高并发时服务动态扩容.

2.3 数据服务安全认证设计

为解决实况数据接口服务时面临的账户信息泄露和API请求恶意攻击等问题, 采用非对称加密的方法来进行签名认证^[13], 用于加固用户数据传输安全和提升天气实况数据服务接口抵御攻击的能力. AccessKeyId (AK)用于标识用户, SecretAccessKey (SK)是用户用于加密认证字符串和服务端用来验证认证字符串的密钥. AK/SK签名认证使用机制为后端服务接收到用户的请求后, 将使用AK对应的SK采用应用端相同的认证机制生成认证字符串(sign), 并与用户请求中包含的认证字符串进行比对. 如果认证字符串相同, 系统认为用户拥有权限并执行相关操作; 如果认证字符串不同, 系统返回错误码, 实现流程见图5.

在实况服务接口中, AK/SK签名认证的参数签名由请求身份、时间戳和随机数、签名方式等3部分组成. 请求身份为用户申请账户时创建的唯一用户ID (AK)和密钥(SK); 时间戳为用户提交请求时刻相对于基准时间的毫秒值, 时间戳有效期设置为15 min, 若请求超出该时间范围则拒绝, 随机数为用户提交请求时生成的随机字符串, 防止身份伪造和恶意攻击; 签名方式采用业务请求参数、请求身份ID, 以及时间戳和随机数拼接的认证字符串, 并进行MD5加密生成签名值.

另外为增强服务安全, 在服务端还增加了用户IP白名单, 请求流量控制等认证安全设计, 在数据传输过程中采用安全传输HTTPS协议.

2.4 Apache Camel规则引擎技术

Apache Camel是一个非常强大的基于规则的路由以及媒介引擎, 该引擎提供了一个基于简单Java对象 (plain ordinary Java object, POJO)的企业应用模式 (enterprise integration patterns, EIP)的实现, 具有强大且易用的API, 用来配置路由或中介的规则^[14].

Apache Camel针对应用集成场景的抽象出了一套消息交互模型, 通过组件的方式进行第三方系统的接入, 目前Apache Camel已经提供了300多种组件能够接入HTTP, File, JMS, TCP, WebSocket等多种传输协议, 结合企业应用集成模式(EIP)的特点提供了消息路由, 消息转换等领域特定语言, 极大降低了集成应用的开发难度. Apache Camel通过URI的方式来定义需要集成的应用节点信息, 用户可以按照业务需求快速编写消息路由规则, 而无需关注集成协议的细节问题. 与传统的企业集成服务总线ESB (enterprise service bus)相比, Apache Camel的核心库非常小巧, 可以方便地与其他系统进行集成. Camel由端点(endpoint)、路由(route)、企业集成模式(EIP)、运行上下文(Camel context)组成, 其中路由至少包含3个要素, 输入源、处理器(processor)和输出目标.

项目中利用Apache Camel框架作为数据处理集成框架, 利用文件协议获取天气实况数据文件上云消息, 并对数据快速处理写入到阿里云的表格存储中, 为后续应用提供数据. 项目中规则引擎技术使用有利于降低服务间的耦合性, 并可提升处理时效性.

3 功能设计与实现 3.1 数据处理与存储

数据处理主要实现专有云推送到阿里云上的站点数据文件和实况网格文件的解析、处理和数据存储. 数据处理采用Apache Camel集成框架, 利用文件协议定制两个RouteBuilder类, 见表5. 其中SurfProcessRouteBuilder用于配置从站点数据文件目录/data/SURF解析文件写入数据库, GridProcessRouteBuilder用于配置从网格文件目录/data/GRID解析文件写入数据库, 处理后的文件放在/data/Trush目录, 一定时间后进行清除. 处理功能通过CamelContext的start()方法进行启动, 利用addRoutes函数将定制的RouteBuilder加入路由.

站点数据文件处理时, 读取文件中所有的站点, 将经度值按整数位的值进行分组排序, 便于批量进行网格点的替换操作. 网格文件处理时采用多线程批量提交模式, 将网格数据按照纬度方向划分为10等份, 每个线程处理一块数据, 从而提高数据入库效率, 处理流程见图6.

3.2 基于位置服务接口

按照业务需求, 提供两种接口应用场景: 按位置“点”获取数据的应用场景和按“轨迹线”获取数据的应用场景. 根据点或线的经纬度信息, 获取气温、相对湿度、风速、风向、天气现象、能见度、总云量、海表温度以及降水等气象要素数据. 线由多点组成, 在接口实现时采取一次性列出线上关键点提供服务.

位置服务接口的核心是根据用户请求的位置点快速从表格存储库中获取天气实况要素信息. 采用分块数据查询定位方法, 从数据库中快速查询数据值.

位置服务接口采用RESTful风格发布, 使用时利用手机定位功能获取当前位置的经纬度信息作为服务接口的请求参数之一. 依据气象数据服务接口的标准, 基于用户位置的天气实况数据服务接口请求参数设计见表6. 数据返回结果采用JSON格式封装, 包含调用状态信息和天气实况数据组成, 调用状态包含服务返回码、运行时间、检索要素信息和要素单位, 天气实况数据包含经纬度信息、数据更新时间、天气要素对应的值等.

3.3 用户认证与行为记录

为提升数据服务的质量, 天气实况数据需要进行认证后才能获取, 对于用户的每次请求的信息进行记录用于后续分析和系统改进.

用户认证的信息包含用户账户、口令、运行的服务器IP以及所属的单位和联系人等信息. 服务接收用户请求后, 解析请求参数和服务来源IP, 加载用户权限配置信息, 验证用户账户和客户端IP地址, 若匹配成功, 则对请求的认证签名值进行比对, 验证通过后方可访问数据.

行为日志主要记录用户请求的账户、发起时间、服务执行耗时、用户获取的天气实况要素和返回的结果状态等. 对于每次接收的请求, 处理后将处理的结果状态放在Kafka消息队列中, 专门的线程对队列中的信息进行整合, 将结果写入到MySQL数据库中.

3.4 系统运行监视

由于天气实况数据服务涉及的环节比较多, 包含专有云内部的数据加工, 以及阿里云上数据的处理、存储和服务接口等, 为方便系统运维和故障点排查处理, 基于气象业务综合监控系统(简称天镜)集成运行监视, 包含阿里云上资源监视、应用服务监视、数据流程监视等方面. 运行监视界面见图7.

4 系统运行效果 4.1 运行环境说明

系统基于阿里云进行开发、部署和运行. 按照业务需求上线后峰值需要支持每秒20万次的访问量, 根据TPS (每秒事务数量)=并发数/平均响应时间的计算公式, 上线前采用JMeter工具进行系统性能测试^[15]. 评估后采用5台云服务器ECS (配置: 8C, 16 GB内存, 本地盘60 GB), 其中天气实况数据服务接口部署(含用户注册服务、用户认证服务)在3台ECS上, 数据处理程序部署使用2台ECS, 并形成高可用. 其他中间件租用云服务, 比如使用负载均衡SLB产品进行应用负载, 使用云解析DNS方式提供用户域名访问等.

4.2 并发量与高可用测试

在实况数据更新和入库方面, 单个实况网格数据文件(包含4200万个点), 采用10线程并发入库平均耗时在4 s, 单个站点数据实时更新平均时效在0.015 s.

天气实况数据服务接口并发性能测试主要模拟用户基于地理位置获取常用天气要素, 利用JMeter工具制作测试脚本, 脚本中用户地理位置为中国区域的随机点位. TPS公式表明高时效和高并发是相互限制, 在测试时需要找到服务接口的最优时效.

测试结果表明, 单节点在模拟1000并发时可响应事务数达到峰值每秒7.1万, 平均响应时效为14 ms. 增加为3节点时, 模拟并发达到3000时可响应事务数达到峰值每秒21.4万, 平均响应时效在14 ms. 另外, 随着节点数增加, 支持的访问量数呈准线性增长, 后续业务访问量增加可通过增加服务接口节点进行扩展. 并发事务响应测试结果见图8.

对外服务时采用域名方式访问, 并利用负载均衡对提供服务的3个节点进行路由设置, 配置故障检测功能, 当节点故障时自动剔除异常节点, 并将请求转移到正常节点. 测试时随机停掉3节点中的任一节点的天气实况数据服务接口的进程, 结果表明用户可正常获取天气实况数据, 具备高可用特性.

4.3 数据服务情况

系统上线后, 用户通过中国气象数据网申请使用, 截至2021年底已为全国54个气象业务单位开发的应用(含APP和小程序)提供天气实况数据服务, 其中国家级8个、省级12个、市县34个, 实现了不同应用在同一位置、同一时刻天气实况数据的统一. 在时效方面, 当1 km范围内有观测站时数据延时在2 min以内, 无站点的区域数据延时在5 min以内. 比如中国气象、中国天气接入天气实况数据服务接口后, 2022年3月2日用户在中国气象局大院(1 km范围内有观测站)获取的实况数据延时在2 min (16点17分的数据为16点15分更新), 并且常用气象要素(气温、湿度、风等)保持了统一, 应用效果见图9, 图10. 随着用户的增长, 系统支撑的访问量每月呈现线性增长, 2021年8月单月访问量超过5000万, 12月单月访问量超过1亿, 见图11.

5 结论与展望

面向人民美好生活, 围绕“衣食住行游购娱学康”等多元化需求, 公众气象服务和专业气象服务在智能化层面水平不断提升, 对天气实况精细化程度的需求不断升级, 在快速、便捷获取权威准确的天气实况数据方面提出了更高要求. 本文基于用户位置的天气实况数据服务的应用场景, 依托阿里云设计了天气实况数据分块存储和查询模型, 采用了微服务和规则引擎, 实现了天气实况网格数据云上存储、处理和服务接口的功能开发. 数据服务时, 每秒可支持20万访问请求, 平均请求响应时效低于20 ms. 并针对公众关注的降水和天气现象等气象要素实现了分钟级更新, 当用户周边1 km范围内有观测站时, 最新数据更新在2 min以内, 周边无观测站时更新在5 min以内. 系统经过多年的业务运行, 时效性、可靠性、高效性得到验证. 具备为全国气象服务应用提供基于用户地理位置信息的天气实况数据服务的支撑能力, 可有效解决同一时刻同一位置不同应用发布的天气实况数据不一致的问题.

接下来将扩展数据服务的范畴, 研究基于智能网格业务的精细化天气预报数据服务方式, 为用户提供精准的实况、预报一体化天气数据服务.