《2022年气象数据一体化平台设计方案.docx》由会员分享，可在线阅读，更多相关《2022年气象数据一体化平台设计方案.docx（20页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、精品学习资源项目编号： RJ20210020设计方案气象数据一体化信息服务平台设计方案2021 年 1 月南京助事达软件科技欢迎下载精品学习资源气象数据一体化平台-设计方案目录1 概述3背景与预期3建设内容42 设计方案5系统架构52.1.1. 平台总体架构图52.1.2. 数据流概览6分布式解析引擎62.2.1. 分布式解析引擎概述62.2.2. 分布式解析设计架构7气象分布式数据库设计122.3.1. 气象一体化平台分布式数据库设计概述122.3.2. 分布式数据库设计架构15气象资料云服务引擎172.4.1. 应用授权机制172.4.2. 授权认证机制172.4.3. 服务恳求基础参数体
2、系建立17服务版本治理体系建立182.5.1. 版本治理设计182.5.2. 建立服务 API 帮忙文档182 / 19欢迎下载精品学习资源1概述1.1 背景与预期针对以往基础数据库建设分散、 标准不统一、服务才能差等问题， 依据“系统集成，数据集中，资源集约，功能完善，突出特色”的思 路，经过两年半的努力，依靠江苏预报业务一体化平台项目建设，初 步建成全省统一的基础数据环境， 有效提高了信息资源的利用率和数据服务才能，为本省领先实现气象现代化供应了有力支撑；信息中心在全省气象信息业务建设的基础上， 先后出台几十项标准或标准， 为一体化体系供应标准支撑， 完善了我省气象信息的标准标准体系；优化
3、数据传输流程，时效性牢靠性提升显著，省内区域自 动站可实现 60 秒内、雷达数据 8 分钟之内、省际共享上海市区域自动站 100 秒内到达预报员桌面；通过“软CAST”同步机制，省市间数据实现了秒级流转；完成了自动站、土壤水份、精细化等50 多类数据的解析入库， 数据解析的种类和掩盖范畴在不断扩充， 确保了数据的完整性、 一样性；架设全省云平台实现硬件资源的统一治理与安排，到达资源集约化、应用多样化的目标；为进一步提高和增强气象数据服务才能， 科学精确的做好数据服务工作， 结合前期预报业务一体化平台使用和市县推广应用情形， 在气象数据 传输 、数据储备和数据 应用方面，提出诸多改良措施和方案，
4、 旨在不断的提高气象数据服务才能和质量；欢迎下载精品学习资源1.2 建设内容依据江苏气象现代化进展的需求， 在现有工作基础上， 进一步完善全省基础资源配置和治理， 开展智能化、 个性化的基础数据环境信息服务平台的设计和开发，连续优化各类基础资料的收集处理流程， 做好统一数据环境在市县的推广应用， 着手开展适合本省的实时质量掌握方法讨论和质控系统的设计和开发工作，提高数据服务质量 ；通过建立团队协作机制， 联合进行数据处理和信息技术应用开发， 建立数据标准；完成实时 / 历史数据库设计、解码和入库；欢迎下载精品学习资源2 设计方案2.1 系统架构2.1.1. 平台总体架构图图表 1 平台总体架构
5、图欢迎下载精品学习资源2.1.2. 数据流概览图表 2 数据流概览2.2 分布式解析引擎2.2.1. 分布式解析引擎概述气象资料的来源有多种， 包括上百种类型的气象资料报文、 各个业务系统产出的气象服务产品、来自于CIMISS 的数据资料等等；由于资料种类繁多、 场地分散、 解析入库方式及质量参差不齐等等各种问题的存在，同样为了满意集中治理、统一标准的业务目标需求，我 们最终使用了 气象数据分布式解析引擎 来实现其各种功能；欢迎下载精品学习资源2.2.2. 分布式解析设计架构图表 3 分布式解析设计架构分布式解析云 的核心主要由四个部分组成：a) 解析云服务主要通过 实时发布远程对象 的方式为
6、各个功能域供应分进程间信息共享平台；共享的远程对象主要包括：报文资源文件夹监控对象、分布式解析器运行时对象、服务全局掌握对象、智能化解析配置对象、全局报文解析组件适配对象 等；欢迎下载精品学习资源实质： 远程对象以信道作为发布渠道，来进行客户端和服务器之间的通信；信道包括客户端的信道部分和服务器的信道部分；发布的内容以消息作为载体，消息包含远程对象的信息、被调用方法的名称以及全部的参数；图表 4 分布式客户端与服务间通信原理报文资源文件夹监控对象 ：每种资源文件都储备在一个或多个文件夹中，当有新的文件加入时解析云自动将待解析的文件加入到 解析资源池 即任务队列；当分布式解析器中有存在闲暇的解析
7、器时， 此解析器就会自动向服务申请一个解析任务；之后，当一个任务被解析器处理完毕后，其就会从任务队列中自动删除 ，同时将相对应的原始数据文件自动移动到已处理文件目录下面；欢迎下载精品学习资源分布式解析器运行时对象：每个报文解析器分别部署在一个或多个服务器上，那么各个解析器运行状态的治理就非常的重要； 为了满意 全局监控 ，定向治理 的目标，云解析平台将分布式解析器运行时对象作为各功能域内部可见的全局对象进行发布； 即各个解析器运行后 自动向云服务 发送注册恳求，云服务接受恳求后就将此解析器加入到解析器队列中用于后期的监控及治理；服务全局掌握对象：主要负责服务的 启动、暂停、重启以及重新加载 配
8、置文件等工作；智能化解析配置对象：此对象主要为分布式解析引擎供应解析学问库，为了实现解析组件的可插拔我们将 智能解析配置对象 也作为全局对象进行发布； 可以从云解析治理器中对其内容进行更换， 更换后云服务自动通知各个解析器接下来的解析工作使用 新的解析学问库 进行报文识别及智能解析；全局报文解析组件适配对象 ：为了使报文的识别实现 动态化扩展，我们将解析适配器对象进行全局发布，当云解析治理器对解析适配器信息进行更换后云解析服务 将自动应用新的解析适配方案； 全部的分布式解析器都使用云解析服务供应的统一解析适配器进行解析适配工作， 所以当云服务的适配器方案转变后各个解析器 自动使用新的 方案进行
9、适配工作；欢迎下载精品学习资源b) 云解析治理器云解析治理器是云解析服务的一个客户端，主要用于帮助云解析 服务工作， 为云解析服务供应可视化操作界面； 如云解析服务供应的各个实时对象的 治理及运行时参数的 保护治理等工作都在云解析器中进行操作；如报文解析组件适配信息配置、智能化解析学问库配置、分布式客户端监控、资源池监控、解析组件配置、数据源配置、运行日志治理等；c) 分布式解析引擎分布式解析引擎是云解析服务的运算核心，全部类型的数据都通过此引擎进行解析运算； 报文解析引擎由三大支撑组件 数据类型识别组件、智能化解析组件和解析组件适配器 和解析组件池组成；数据类型识别组件：数据类型识别组件主要
10、对当前申请到的解析资源进行自动识别， 主要通过数据文件名、 数据段特别标记以及其他 特性化配置 方式进行识别；数据类型被识别后向解析引擎反馈此文件的解析适配标识；解析组件适配器：解析组件适配器主要将数据类型识别组件反馈的解析适配标识 进行适配，并从解析组件工厂中构造一个适合此适配标记的解析组件智能化解析组件：智能化解析组件主要将智能解析学问库中的信息翻译成解析器能欢迎下载精品学习资源够识别的信息结构，并将此信息结构供应应解析组件进行报文解析；解析组件池：由一系列报文解析组件组成，如重要天气报解析组件、A文件解析组件、高空资料解析组件、自动站解析组件等等；每个解析组件都遵从解析引擎的报文解析流程
11、， 最终完成报文的解析； 报文解析流程如下：欢迎下载精品学习资源d) 分布式解析器图表 5 报文解析流程欢迎下载精品学习资源分布式报文解析器主要有如下几个特性：1. 分布式: 即此解析器可以在多台服务器上同时运行，同样也可以在一台服务器上运行多个实例；2. 可扩展性 : 解析器中搭载的是 解析组件引擎 ，而解析组件队列可欢迎下载精品学习资源在远程服务中直接猎取， 所以当云解析服务更新组件配置或加入新的解析组件时各个解析器同时受益；3. 并行运算 : 每个解析器的都在独立的进程中进行运算， 所以当多个解析器同时对解析任务池中的任务进行解析时大大缩短明白析的时间缩短，提高解析 效率；4. 可治理性
12、 : 每个解析组件运行后第一会注册到解析云服务， 同时解析云服务会将此信息反馈给解析服务治理器， 治理器收到信息后将此解析组件加入到本地的可视化解析组件治理列表中， 对其进行实施监控；当一个解析器出错或强行退出时， 解析云自动 注销其消息订阅大事，并通知解析云服务治理器， 治理器从治理列表中将此解析器 移除，或提示治理员此解析器已下线；2.3 气象分布式数据库设计2.3.1. 气象一体化平台分布式数据库设计概述从目前江苏省气象信息的数据结构及分布情形分析，我们的数据属于异构数据库；即现有的数据使用了多个DBM，S 如 SQL Server，Oracle等；由于各种气象资料较为纷杂，储备的数据结
13、构也不尽相同；所以我们建立的分布式数据库治理架构不但要解决分布式储备的问题仍需要解决异构数据库的问题；本架构设计的核心原理是通过分布式数据服务全局共享数据节点索引对象；并使用分布式数据库治理引擎来对各个数据节点进行高欢迎下载精品学习资源效的存取操作；数据索引需要建立在一个全局共同遵守的标准之上，这个标准中规定了在不同数据分片场景下各个数据节点应共同包含或通过规律映射的方式包含相应的属性； 如在水平分片场景下， 各个数据节点应共同拥有日期属性，日期属性可分为年、月、旬、候、时间等多 个分类方式；犹如属于年分类的场景下，就需要共同拥有年属性；如在垂直分片场景下，各个数据节点应共同拥有要素类型属性；
14、 分布式储备的核心问题是对数据分片和数据安排方式，分片的方式分为水平分片 、垂直分片、导出分片和混合分片 ；水平分片：即按肯定的条件把全局关系的全部元组划分成假设干不相交的子集， 每个子集为关系的一个片段； 依据分析我们可以通过时间节点对数据进行水平分片；垂直分片：即把一个全局关系的属性集分成假设干子集， 并在这些子集上作投影运算， 每个投影称为垂直分片； 如我们可以通过气象要素进行空间的垂直分片；导出分片： 又称为导出水平分片， 即水平分片的条件不是本关系属性的条件， 而是其他关系属性的条件； 我们一般在特别的数据应用场景中使用此分片方式； 如对数据按站点所在的城市为条件进行数据分片，因站点
15、所在的城市这个属性一般不在要素基本属性中存在，而是在站点信息关系表中存在，那么此种分片就称为导出分片；混合分片： 综合了以上三种分片方式进行数据分片；数据安排方式分为：集中式、分割式、全复制式和混合式；欢迎下载精品学习资源依据气象数据的特点我们建议采纳分割式的数据安排方式，即全部数据只有一份， 它被分割成假设干规律片段， 每个规律片段被指派在一个特定的场地上；同时服务器的磁盘阵列使用冗余磁盘阵列 RAID 的方式进行治理，并建议使用 RAID10即 RAID 0+ 1 ；虚拟化技术虚拟化是一种资源治理技术， 是将电脑的各种实体资源， 如服务器、网络、内存及储备等，予以抽象、转换后出现出来，打破
16、实体结 构间的不行切割的障碍， 使用户可以比原本的组态更好的方式来应用这些资源； 这些资源的新虚拟部份是不受现有资源的架设方式，地域或物理组态所限制； 一般所指的虚拟化资源包括运算才能和资料储备；在实际的生产环境中， 虚拟化技术主要用来解决高性能的物理硬件产能过剩和老的旧的硬件产能过低的重组重用， 透亮化底层物理硬件，从而 最大化的利用物理硬件；由于我们需要将数据节点储备在多个场地上， 为了节省硬件产品， 并充分利用硬件的运算资源以及储备资源，我们可以将一台工作站 虚拟成多个储备场地；欢迎下载精品学习资源2.3.2. 分布式数据库设计架构图表 6 分布式数据库总体设计方案分布式数据库 的核心模
17、块分为： 分布式数据库通讯服务 CM 、分布式数据库治理器 DDBMS、云储备接口 Cloud Data API 、Data欢迎下载精品学习资源Client 、Data Query Standard Lib和 Data Save Standard Lib；分布式数据库通讯服务 :负责在分布式数据库的各场地之间传送全局对象、消息和数据，完成通信功能；图表 7 分布式查询核心原理图核心的全局对象是 分布式数据索引对象 Data Index Struct ，每个分布式客户端上线后将自动注册到分布式数据库通讯服务，通讯服务自动将其加入到 Distributed Client Stack 中，同时依据客
18、户端报送的数据节点名称， 服务自动为其初始化局部数据库数据索引对象，并将关键索引储备为 Hash Table 的 key-value 模式；并为其订阅全局数据检索和数据储存大事等， 当有数据检索恳求时， 服务通过并行化编欢迎下载精品学习资源程技术使全部分布式客户端同时处理此大事， 当某个分布式客户端处理发觉本地索引中无相关key 或不满意其数据分片条件时就直接退出响应；假如相关条件都在其索引范畴内， 就进行本地化数据查询操作，并将结果以 Data Set的形式返回至大事源； 全部并行流程执行完成后大事源将 Data Set集反馈给查询者；分布式数据库治理系统 DDBMS：分布式数据库治理系统主
19、要用于2.4 气象资料云服务引擎2.4.1. 应用授权机制即每一个接入服务的应用都需要申请一个AppKey，此 Key 对应着一套数据拜访授权， 同时记录应用名称、 开发者、软件功能等信息；2.4.2. 授权认证机制即全部服务恳求都必需提交AppKey，恳求的数据拜访权限都必需在此 AppKey的权限框架下；全部数据恳求到达服务器端后进入统一的认证通道，认证通过后服务通过相关的恳求参数反馈相应的数据， 否就提示应用恳求认证失败；2.4.3. 服务恳求基础参数体系建立为标准化治理，每一个服务恳求应能够包含部分基础恳求参数，欢迎下载精品学习资源如区域来源如地区标记 、资料类型、返回值类型 JSON
20、、XML、其他格式文件、等；2.5 服务版本治理体系建立为保证服务的可扩展性以及服务的兼容性，必需建立完善的版本治理体系；2.5.1. 版本治理设计为保证后期服务功能的升级不会影响前期的使用， 每一个服务的升级都对应一个不同的版本号； 升级后的服务和升级前的服务都可以独立运行；并通过统一服务治理查询界面可以查询到每一个服务各个 版本间升级的变化以及各个版本调用的参数列表；2.5.2. 建立服务 API 帮忙文档数据服务以 REST架构为核心， REST的恳求一般分为两种，即： GET和 POST；使用 GET模式的恳求仅需要定义完整的恳求参数， 使用者依据参数的描述建立相应的恳求 URL即可；使用 POST模式的恳求需要供应相应的恳求数据包格式，为保证外部应用的调用， API 帮忙文档中将给出各个服务的调用范式，并供应部分开发语言的调用 Demo；服务 API 帮忙文档和对应的服务一同纳入版本治理，即同一服务的不同版本需要供应不同的帮忙文档以帮忙第三方应用能够顺当的欢迎下载精品学习资源使用；欢迎下载