Share_Nothing...据存储处理系统的设计与实现_陈利娟.pdf

收稿日期:2022-02-11基金项目:中国气象局中央山洪项目资金资助项目(17A4 277)作者简介:陈利娟(1986),女,重庆人,工程师,研究生,主要研究方向为气象信息技术。Share Nothing 分布式气象数据存储处理系统的设计与实现陈利娟1,唐婕2,薛帅宁1,赵思亮1,钟 美1,何 奇1(1.重庆市气象信息与技术保障中心,重庆 410047;2.长寿区气象局,重庆 410047)摘 要:随着气象观测、预报和服务业务的快速发展,气象资料的种类和数据量日益增多,数据写入频率越来越高,对气象数据存储处理系统提出极大挑战,进一步提升 CIMISS 数据管理和服务能力的需求变得日益迫切。为解决存储处理系统动态扩展能力不足、吞吐与并行计算效率低下的问题,采用一系列 Share Nothing 分布式集群设计,包括Share Nothing 分布式架构、分布式数据库、NAS 存储技术等搭建可动态扩展的 Share Nothing 分布式气象数据存储处理系统。实践证明,该方案设计能够满足当今气象结构化数据和非结构化数据对存储能力、并发响应能力的需求,通过动态扩展可便捷适应未来气象业务发展对数据存储和应用等服务能力不断增加的需求,具备气象现代发展进程中气象数据存储处理系统高吞吐量、可动态横向扩展、高稳定性、高可靠性的特性。关键词:分布式架构;分布式数据库;扩展性;可靠性;吞吐量 中图分类号:TP302 文献标识码:A DOI 编码:10.14016/ki.1001-9227.2023.01.198The Design and Implementation of Share Nothing Distributeds ystem of Meteorological Data Storage and ProcessingCHEN Lijuan1,TANG Jie2,XUE Shuaining1,ZHAO Siliang1,ZHONG Mei1,HE Qi1(1.The Metrological Information and Technology Support Center of Chongqing,Chongqing 410047,China;2.Changshou Meteorological Bureau,Chongqing 410047,China)Abstract:As the rapid development of meteorological observation,forecasting and service business,the types and the a-mount of meteorological data are increasing and the frequency of data writing is higher and higher which will challenge the me-teorological data storage and processing system greatly.the needs to improve the data management and service capacity of CIMISS has become increasingly urgent.This system has some problems,such as insufficient dynamic expansion ability,low data throughput and poor parallel computing.To solve these problems,a dynamically extensible share nothing distributed mete-orological data storage and processing system is established using a group of share nothing distributed cluster designs including share nothing distributed architecture,distributed database combining with NAS(Network Attached Storage),etc.The practice has proved that the proposed scheme can meet the needs of todays meteorological structured data and unstructured data for storage capacity and concurrent response capacity.With the development of meteorological business in the future,it can adapt to the increasing demand of service capabilities,such as data storage,application,etc,and has the characteristics of high throughput,dynamic horizontal expansion,high stability and high reliability.Key words:distributed architecture;distributed database;expansibility;reliability;throughput0 引言全国综合气象信息共享平台(CIMISS)是依托天气雷达数据共享平台工程项目建成的国省统一数据环境1,2,统一管理气象数据3,集气象数据收集、加工处理、存储管理和共享服务于一体,2013 年推广部署到全国各省级气象数据中心4-6,存储了气象资料分类体系中规定6的 14 大类气象数据7,业务化以来,经测试,较国家级气象资料存储检索系统8,其入库时效有效缩短 20%1,为气象业务和科研用户提供快捷、便利的数据应用环境,但随着气象观测、预报和服务业务的快速发展,重庆 CIMISS 存储能力已不能充分满足海量气象数据存储的需求,如:多种基础气象观测数据无法长时间在线保存,如地面每五分钟的观测数据只能保存 3 个月左右,高空资料只能保存 6 个月左右。并且随着气象资料的种类和数据量日益增多,数据写入频率也越来越高,根据重庆 CIMISS 气象数据统一服务接口(MUSIC)的使用情况统计结果,每天以近 40 万条记录、50 万个文件、100GB 数据量的速度不断增长,大于 1 秒的接口调用超过总调用量的 10%,CIMISS 存储系统数据吞吐能力日益不能满足气象数据服务的效率需求。因此,亟需采用新型可靠信息技术对 CIMISS 的存储系统进行升级改造,以达到大幅提升数据存储和服务能力的目标,重庆891Share Nothing 分布式气象数据存储处理系统的设计与实现 陈利娟,等CIMISS 采用共享存储的 Oracle RAC11.2 关系数据库和GPFS,在不影响业务应用系统 724 小时正常运行前提下,继续再沿用原技术路线扩充存储资源的可行性很低9,再加之重庆数据支撑平台除 CIMISS 数据收发子系统来源的数据,还有一部分重庆本地特有格式的气象数据(如水利局雨量站水位信息、农业站等)需要高效率解析存储,因此,利用目前最流行的 Share Nothing 分布式技术10-12,实现对 CTS、MDOS、消息服务器等多源气象数据的统一接收、解析、存储,以满足面对气象现代化发展对气象数据存储处理提出的高吞吐量、可动态横向扩展、高稳定性、高可靠性的要求日益迫切。1 方案设计在 CIMISS 系统中结构化数据存储在 Oracle 关系数据库中,采用二维数据表存储气象数据要素值13-14,并存储非结构化数据文件的元数据和索引信息,联合GPFS 实现气象数据文件的存储功能15-16,这种方式动态扩展能力不足,相比之下,分布式技术可以有效地解决数据存储和管理的难题,将固定于某个地点的某个文件系统,扩展到由计算机网络连接的众多存储资源组成的 1 个大型的、集中化管理的数据中心17-18,具有一定扩展性的气象信息存储模型是气象信息存储、管理、共享的核心和关键19-20。考虑到气象数据是按照分钟、小时、日、候、旬、月、年等时间划分的,气象业务应用也基本是按照时间来存取数据及统计处理等,本设计通过时间字段进行分区,从气象数据分区特性和重庆数据支撑平台系统中重庆本地特有格式气象数据存储在 MySQL数据库中的实际情况出发,采用 Share Nothing 分布式架构、MySQL 企业级分布式关系数据库集群和 NAS 存储技术等设计易动态扩展的 Share Nothing 分布式气象数据存储处理系统,通过负载均衡、任务的分拆与运算结果的组合等方法21,对大型任务进行分解并充分地利用每个节点理资源以达到整体资源最优化22-23,有效避免I/O 瓶颈,并且为消除各环节单点故障,每个处理环节均采用集群,使系统具备高可用性、横向扩展能力和抗灾难性24-25,系统架构见图 1 所示。图 1 系统总体架构该系统硬件支撑架构设计见图 2 所示,CTS、MDOS、消息服务等多源数据通过负载均衡设备将数据发送给接收节点,数据接收由多个节点构成分布式架构,将接收到的数据保存至分布式 NAS 存储上用作应急备份,同时将数据以消息形式路由给数据处理节点,消息中间件为分布式 Kafka 集群,数据处理节点识别不同资料类型进行相应解析,解析后的数据组成批量 SQL 写到后端MySQL 分布式数据库中,集群协调器负责监控管理各节点运行状态,并提供 Web 管理界面观察集群整体运行情况,若随着气象业务的发展,需提升处理能力,只需要简单增加节点就可以实现,气象数据通过该系统存储和处理的数据流向图见图 3 所示。图 2 硬件支撑架构图 3 数据流向图2 数据接收解码入库实现数据解码入库设计见图 4 所示,该设计采用 Kafka作为中间件,利用 Zookeeper 作为分布式调度 Kafka 中间件,kafka 将气象数据入库过程的预处理阶段和解码入库阶段逻辑上隔离开,使整个架构具备高柔韧性和扩展性,保证预处理高效、及时,不会积压数据,使解码入库平均地分布到集群各个节点,同时采用扩展类机制,使预处理和解码入库二个阶段中的处理逻辑可以自由定制扩展,使气象数据入库过程更灵活。在预处理阶段中,利用 Kafka 将不同编码、不同传输渠道、不同频率气象数据统一处理为统一标准气象消息(其定义见表 1 所示),随后发送到 kafka 队列中,再将数据归档到 NAS 共享存储,不仅保障数据格式统一性,还提高数据读取效率和可靠性。在第二阶段中,服务从 Kafka 队列(其名称定义见表 2 所示)中收到消息(UniformMessage),根据消息中的数据编码特性调用不同解码库类进行解码处理,并将解码后数据根据各自入库逻辑生成相应入库 SQL,再将 SQL 回放到目标数据库,完成解码入库过程。991自动化与仪器仪表2023 年第 1 期(总第 279 期)图 4 数据解码入库设计表 1 预处理标准格式定义代码注释 Protocal UniformMessageProtocol/统一气象消息 各种渠道接收的气象资料预处理成统一的气象消息/record UniformMessage string receiverId;/接收 ID string receiverFile;/接收文件 timestanp_ms receiveTime;/接收时间 long receiveSpendTimeMS;/接收预处理耗时(毫秒)string receiveNode;/动故节点号 int channelType;/信道类型:1