气象数据一体化平台设计专项方案.docx

项目编号：RJ0020设计方案气象数据一体化信息服务平台 设计方案1月南京助事达软件科技目 录1概述31.1背景和预期31.2建设内容42设计方案52.1系统架构52.1.1.平台总体架构图52.1.2.数据流概览62.2分布式解析引擎62.2.1.分布式解析引擎概述62.2.2.分布式解析设计架构72.3气象分布式数据库设计122.3.1.气象一体化平台分布式数据库设计概述122.3.2.分布式数据库设计架构152.4气象资料云服务引擎172.4.1.应用授权机制172.4.2.授权认证机制172.4.3.服务请求基础参数体系建立172.5服务版本管理体系建立182.5.1.版本管理设计182.5.2.建立服务API帮助文档181概述1.1 背景和预期针对以往基础数据库建设分散、标准不统一、服务能力差等问题，根据“系统集成，数据集中，资源集约，功效完善，突出特色”思绪，经过两年半努力，依靠江苏预报业务一体化平台项目建设，初步建成全省统一基础数据环境，有效提升了信息资源利用率和数据服务能力，为本省率先实现气象现代化提供了有力支撑。信息中心在全省气象信息业务建设基础上，前后出台几十项标准或规范，为一体化体系提供标准支撑，完善了本省气象信息标准规范体系；优化数据传输步骤，时效性可靠性提升显著，省内区域自动站可实现60秒内、雷达数据8分钟之内、省际共享上海市区域自动站100秒内抵达预报员桌面；经过“软CAST”同时机制，省市间数据实现了秒级流转；完成了自动站、土壤水份、精细化等50多类数据解析入库，数据解析种类和覆盖范围在不停扩充，确保了数据完整性、一致性。架设全省云平台实现硬件资源统一管理和分配，达成资源集约化、应用多样化目标。为深入提升和增强气象数据服务能力，科学正确做好数据服务工作，结合前期预报业务一体化平台使用和市县推广应用情况，在气象数据传输、数据存放和数据应用方面，提出很多改善方法和方案，意在不停提升气象数据服务能力和质量。1.2 建设内容依据江苏气象现代化发展需求，在现有工作基础上，深入完善全省基础资源配置和管理，开展智能化、个性化基础数据环境信息服务平台设计和开发，继续优化各类基础资料搜集处理步骤，做好统一数据环境在市县推广应用，着手开展适合本省实时质量控制方法研究和质控系统设计和开发工作，提升数据服务质量。经过建立团体协作机制，联合进行数据处理和信息技术应用开发，建立数据规范；完成实时/历史数据库设计、解码和入库。2设计方案22.1 系统架构1.2.2.1.2.1.1. 平台总体架构图图表 1平台总体架构图2.1.2. 数据流概览图表 2数据流概览2.2 分布式解析引擎2.2.2.2.1. 分布式解析引擎概述气象资料起源有多个，包含上百种类型气象资料报文、各个业务系统产出气象服务产品、来自于CIMISS数据资料等等。因为资料种类繁多、场地分散、解析入库方法及质量参差不齐等等多种问题存在，一样为了满足集中管理、统一标准业务目标需求，我们最终使用了气象数据分布式解析引擎来实现其多种功效。2.2.2. 分布式解析设计架构 图表 3分布式解析设计架构分布式解析云关键关键由四个部分组成：a) 解析云服务关键经过实时公布远程对象方法为各个功效域提供分进程间信息共享平台。共享远程对象关键包含：报文资源文件夹监控对象、分布式解析器运行时对象、服务全局控制对象、智能化解析配置对象、全局报文解析组件适配对象等。实质：远程对象以信道作为公布渠道，来进行用户端和服务器之间通信。信道包含用户端信道部分和服务器信道部分。公布内容以消息作为载体，消息包含远程对象信息、被调用方法名称和全部参数。 图表 4分布式用户端和服务间通信原理报文资源文件夹监控对象：每种资源文件全部存放在一个或多个文件夹中，当有新文件加入时解析云自动将待解析文件加入到解析资源池（即任务队列）。当分布式解析器中有存在空闲解析器时，此解析器则会自动向服务申请一个解析任务。以后，当一个任务被解析器处理完成后，其就会从任务队列中自动删除，同时将相对应原始数据文件自动移动到已处理文件目录下面。分布式解析器运行时对象：每个报文解析器分别布署在一个或多个服务器上，那么各个解析器运行状态管理就十分关键。为了满足全局监控，定向管理目标，云解析平台将分布式解析器运行时对象作为各功效域内部可见全局对象进行公布。即各个解析器运行后自动向云服务发送注册请求，云服务接收请求后则将此解析器加入到解析器队列中用于后期监控及管理。服务全局控制对象：关键负责服务开启、暂停、重启和重新加载配置文件等工作。智能化解析配置对象：此对象关键为分布式解析引擎提供解析知识库，为了实现解析组件可插拔我们将智能解析配置对象也作为全局对象进行公布。能够从云解析管理器中对其内容进行更改，更改后云服务自动通知各个解析器接下来解析工作使用新解析知识库进行报文识别及智能解析。全局报文解析组件适配对象：为了使报文识别实现动态化扩展，我们将解析适配器对象进行全局公布，当云解析管理器对解析适配器信息进行更改后云解析服务将自动应用新解析适配方案。全部分布式解析器全部使用云解析服务提供统一解析适配器进行解析适配工作，所以当云服务适配器方案改变后各个解析器自动使用新方案进行适配工作。b) 云解析管理器云解析管理器是云解析服务一个用户端，关键用于辅助云解析服务工作，为云解析服务提供可视化操作界面。如云解析服务提供各个实时对象管理及运行时参数维护管理等工作全部在云解析器中进行操作。如报文解析组件适配信息配置、智能化解析知识库配置、分布式用户端监控、资源池监控、解析组件配置、数据源配置、运行日志管理等。c) 分布式解析引擎分布式解析引擎是云解析服务运算关键，全部类型数据全部经过此引擎进行解析运算。报文解析引擎由三大支撑组件（数据类型识别组件、智能化解析组件和解析组件适配器）和解析组件池组成。数据类型识别组件：数据类型识别组件关键对目前申请到解析资源进行自动识别，关键经过数据文件名、数据段特殊标识和其它特征化配置方法进行识别。数据类型被识别后向解析引擎反馈此文件解析适配标识。解析组件适配器：解析组件适配器关键将数据类型识别组件反馈解析适配标识进行适配，并从解析组件工厂中结构一个适合此适配标识解析组件智能化解析组件：智能化解析组件关键将智能解析知识库中信息翻译成解析器能够识别信息结构，并将此信息结构提供给解析组件进行报文解析。解析组件池：由一系列报文解析组件组成，如关键天气报解析组件、A文件解析组件、高空资料解析组件、自动站解析组件等等。每个解析组件全部遵从解析引擎报文解析步骤，最终完成报文解析。报文解析步骤以下：图表 5报文解析步骤d) 分布式解析器分布式报文解析器关键有以下多个特征：1.分布式:即此解析器能够在多台服务器上同时运行，一样也能够在一台服务器上运行多个实例。2.可扩展性:解析器中搭载是解析组件引擎，而解析组件队列可在远程服务中直接获取，所以当云解析服务更新组件配置或加入新解析组件时各个解析器同时受益。3.并行计算:每个解析器全部在独立进程中进行运算，所以当多个解析器同时对解析任务池中任务进行解析时大大缩短了解析时间缩短，提升解析效率。4.可管理性:每个解析组件运行后首先会注册到解析云服务，同时解析云服务会将此信息反馈给解析服务管理器，管理器收到信息后将此解析组件加入到当地可视化解析组件管理列表中，对其进行实施监控。当一个解析器犯错或强行退出时，解析云自动注销其消息订阅事件，并通知解析云服务管理器，管理器从管理列表中将此解析器移除，或提醒管理员此解析器已下线。2.3 气象分布式数据库设计2.3.2.3.1. 气象一体化平台分布式数据库设计概述从现在江苏省气象信息数据结构及分布情况分析，我们数据属于异构数据库。即现有数据使用了多个DBMS，如SQL Server，Oracle等。因为多种气象资料较为繁杂，存放数据结构也不尽相同。所以我们建立分布式数据库管理架构不仅要处理分布式存放问题还需要处理异构数据库问题。本架构设计关键原理是经过分布式数据服务全局共享数据节点索引对象。并使用分布式数据库管理引擎来对各个数据节点进行高效存取操作。数据索引需要建立在一个全局共同遵守标准之上，这个标准中要求了在不一样数据分片场景下各个数据节点应共同包含或经过逻辑映射方法包含对应属性。如在水平分片场景下，各个数据节点应共同拥有日期属性，日期属性可分为（年、月、旬、候、时间）等多个分类方法。如同属于年分类场景下，则需要共同拥有年属性。如在垂直分片场景下，各个数据节点应共同拥有要素类型属性。分布式存放关键问题是对数据分片和数据分配方法，分片方法分为水平分片、垂直分片、导出分片和混合分片。水平分片：即按一定条件把全局关系全部元组划分成若干不相交子集，每个子集为关系一个片段。依据分析我们能够经过时间节点对数据进行水平分片。垂直分片：即把一个全局关系属性集分成若干子集，并在这些子集上作投影运算，每个投影称为垂直分片。如我们能够经过气象要素进行空间垂直分片。导出分片：又称为导出水平分片，即水平分片条件不是本关系属性条件，而是其它关系属性条件。我们通常在特殊数据应用场景中使用此分片方法。如对数据按站点所在城市为条件进行数据分片，因站点所在城市这个属性通常不在要素基础属性中存在，而是在站点信息关系表中存在，那么此种分片则称为导出分片。混合分片：综合了以上三种分片方法进行数据分片。数据分配方法分为：集中式、分割式、全复制式和混合式。依据气象数据特点我们提议采取分割式数据分配方法，即全部数据只有一份，它被分割成若干逻辑片段，每个逻辑片段被指派在一个特定场地上。同时服务器磁盘阵列使用冗余磁盘阵列(RAID)方法进行管理，并提议使用RAID10（即RAID 0+ 1）。虚拟化技术虚拟化是一个资源管理技术，是将计算机多种实体资源，如服务器、网络、内存及存放等，给予抽象、转换后展现出来，打破实体结构间不可切割障碍，使用户能够比原本组态愈加好方法来应用这些资源。这些资源新虚拟部份是不受现有资源架设方法，地域或物理组态所限制。通常所指虚拟化资源包含计算能力和资料存放。在实际生产环境中，虚拟化技术关键用来处理高性能物理硬件产能过剩和老旧硬件产能过低重组重用，透明化底层物理硬件，从而最大化利用物理硬件。因为我们需要将数据节点存放在多个场地上，为了节省硬件产品，并充足利用硬件计算资源和存放资源，我们能够将一台工作站虚拟成多个存放场地。2.3.2. 分布式数据库设计架构图表 6分布式数据库总体设计方案分布式数据库关键模块分为：分布式数据库通讯服务(CM)、分布式数据库管理器(DDBMS)、云存放接口(Cloud Data API)、Data Client、Data Query Standard Lib 和Data Save Standard Lib。分布式数据库通讯服务:负责在分布式数据库各场地之间传送全局对象、消息和数据，完成通信功效。图表 7分布式查询关键原理图关键全局对象是分布式数据索引对象(Data Index Struct)，每个分布式用户端上线后将自动注册到分布式数据库通讯服务，通讯服务自动将其加入到Distributed Client Stack中，同时依据用户端报送数据节点名称，服务自动为其初始化局部数据库数据索引对象，并将关键索引存放为Hash Tablekey-value模式。并为其订阅全局数据检索和数据保留事件等，当有数据检索请求时，服务经过并行化编程技术使全部分布式用户端同时处理此事件，当某个分布式用户端处剪发觉当地索引中无相关key或不满足其数据分片条件时则直接退出响应。假如相关条件全部在其索引范围内，则进行当地化数据查询操作，并将结果以Data Set形式返回至事件源。全部并行步骤实施完成后事件源将Data Set集反馈给查询者。分布式数据库管理系统(DDBMS)：分布式数据库管理系统关键用于2.4 气象资料云服务引擎2.4.2.4.1. 应用授权机制即每一个接入服务应用全部需要申请一个AppKey，此Key对应着一套数据访问授权，同时统计应用名称、开发者、软件功效等信息。2.4.2. 授权认证机制即全部服务请求全部必需提交AppKey，请求数据访问权限全部必需在此AppKey权限框架下。全部数据请求抵达服务器端后进入统一认证通道，认证经过后服务经过相关请求参数反馈对应数据，不然提醒应用请求认证失败。2.4.3. 服务请求基础参数体系建立为规范化管理，每一个服务请求应能够包含部分基础请求参数，如区域起源（如地域标识）、资料类型、返回值类型（JSON、XML、其它格式文件）、等。2.5 服务版本管理体系建立为保障服务可扩展性和服务兼容性，必需建立完善版本管理体系。2.5.2.5.1. 版本管理设计为保障后期服务功效升级不会影响前期使用，每一个服务升级全部对应一个不一样版本号。升级后服务和升级前服务全部能够独立运行。并经过统一服务管理查询界面能够查询到每一个服务各个版本间升级改变和各个版本调用参数列表。2.5.2. 建立服务API帮助文档数据服务以REST架构为关键，REST请求通常分为两种，即：GET和POST。使用GET模式请求仅需要定义完整请求参数，使用者依据参数描述建立对应请求URL即可。使用POST模式请求需要提供对应请求数据包格式，为保障外部应用调用，API帮助文档中将给出各个服务调用范式，并提供部分开发语言调用Demo。服务API帮助文档和对应服务一同纳入版本管理，即同一服务不一样版本需要提供不一样帮助文档以帮助第三方应用能够顺利使用。