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

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

《气象数据一体化平台设计方案.docx》由会员分享，可在线阅读，更多相关《气象数据一体化平台设计方案.docx（11页珍藏版）》请在冰豆网上搜索。

气象数据一体化平台设计方案

项目编号：

RJ20150020

设计方案

气象数据一体化信息服务平台

设计方案

2016年1月

南京助事达软件科技有限公司

1概述

1.1背景与预期

针对以往基础数据库建设分散、标准不统一、服务能力差等问题，按照“系统集成，数据集中，资源集约，功能完善，突出特色”的思路，经过两年半的努力，依托江苏预报业务一体化平台项目建设，初步建成全省统一的基础数据环境，有效提高了信息资源的利用率和数据服务能力，为本省率先实现气象现代化提供了有力支撑。

信息中心在全省气象信息业务建设的基础上，先后出台几十项标准或规范，为一体化体系提供标准支撑，完善了我省气象信息的标准规范体系；优化数据传输流程，时效性可靠性提升显著，省内区域自动站可实现60秒内、雷达数据8分钟之内、省际共享上海市区域自动站100秒内到达预报员桌面；通过“软CAST”同步机制，省市间数据实现了秒级流转；完成了自动站、土壤水份、精细化等50多类数据的解析入库，数据解析的种类和覆盖范围在不断扩充，确保了数据的完整性、一致性。

架设全省云平台实现硬件资源的统一管理与分配，达到资源集约化、应用多样化的目标。

为进一步提高和增强气象数据服务能力，科学准确的做好数据服务工作，结合前期预报业务一体化平台使用和市县推广应用情况，在气象数据传输、数据存储和数据应用方面，提出诸多改进措施和方案，旨在不断的提高气象数据服务能力和质量。

1.2建设内容

根据江苏气象现代化发展的需求，在现有工作基础上，进一步完善全省基础资源配置和管理，开展智能化、个性化的基础数据环境信息服务平台的设计和开发，继续优化各类基础资料的收集处理流程，做好统一数据环境在市县的推广应用，着手开展适合本省的实时质量控制方法研究和质控系统的设计和开发工作，提高数据服务质量。

通过建立团队协作机制，联合进行数据处理和信息技术应用开发，建立数据规范；完成实时/历史数据库设计、解码和入库。

2设计方案

2

2.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，如SQLServer，Oracle等。

由于各种气象资料较为繁杂，存储的数据结构也不尽相同。

所以我们建立的分布式数据库管理架构不但要解决分布式存储的问题还需要解决异构数据库的问题。

本架构设计的核心原理是通过分布式数据服务全局共享数据节点索引对象。

并使用分布式数据库管理引擎来对各个数据节点进行高效的存取操作。

数据索引需要建立在一个全局共同遵守的标准之上，这个标准中规定了在不同数据分片场景下各个数据节点应共同包含或通过逻辑映射的方式包含相应的属性。

如在水平分片场景下，各个数据节点应共同拥有日期属性，日期属性可分为（年、月、旬、候、时间）等多个分类方式。

如同属于年分类的场景下，则需要共同拥有年属性。

如在垂直分片场景下，各个数据节点应共同拥有要素类型属性。

分布式存储的核心问题是对数据分片和数据分配方式，分片的方式分为水平分片、垂直分片、导出分片和混合分片。

水平分片：

即按一定的条件把全局关系的所有元组划分成若干不相交的子集，每个子集为关系的一个片段。

根据分析我们可以通过时间节点对数据进行水平分片。

垂直分片：

即把一个全局关系的属性集分成若干子集，并在这些子集上作投影运算，每个投影称为垂直分片。

如我们可以通过气象要素进行空间的垂直分片。

导出分片：

又称为导出水平分片，即水平分片的条件不是本关系属性的条件，而是其他关系属性的条件。

我们一般在特殊的数据应用场景中使用此分片方式。

如对数据按站点所在的城市为条件进行数据分片，因站点所在的城市这个属性一般不在要素基本属性中存在，而是在站点信息关系表中存在，那么此种分片则称为导出分片。

混合分片：

综合了以上三种分片方式进行数据分片。

数据分配方式分为：

集中式、分割式、全复制式和混合式。

根据气象数据的特点我们建议采用分割式的数据分配方式，即所有数据只有一份，它被分割成若干逻辑片段，每个逻辑片段被指派在一个特定的场地上。

同时服务器的磁盘阵列使用冗余磁盘阵列（RAID）的方式进行管理，并建议使用RAID10（即RAID0+1）。

虚拟化技术

虚拟化是一种资源管理技术，是将计算机的各种实体资源，如服务器、网络、内存及存储等，予以抽象、转换后呈现出来，打破实体结构间的不可切割的障碍，使用户可以比原本的组态更好的方式来应用这些资源。

这些资源的新虚拟部份是不受现有资源的架设方式，地域或物理组态所限制。

一般所指的虚拟化资源包括计算能力和资料存储。

在实际的生产环境中，虚拟化技术主要用来解决高性能的物理硬件产能过剩和老的旧的硬件产能过低的重组重用，透明化底层物理硬件，从而最大化的利用物理硬件。

因为我们需要将数据节点存储在多个场地上，为了节约硬件产品，并充分利用硬件的计算资源以及存储资源，我们可以将一台工作站虚拟成多个存储场地。

2.3.2.分布式数据库设计架构

图表6分布式数据库总体设计方案

分布式数据库的核心模块分为：

分布式数据库通讯服务（CM）、分布式数据库管理器（DDBMS）、云存储接口（CloudDataAPI）、DataClient、DataQueryStandardLib和DataSaveStandardLib。

分布式数据库通讯服务:

负责在分布式数据库的各场地之间传送全局对象、消息和数据，完成通信功能。

图表7分布式查询核心原理图

核心的全局对象是分布式数据索引对象（DataIndexStruct），每个分布式客户端上线后将自动注册到分布式数据库通讯服务，通讯服务自动将其加入到DistributedClientStack中，同时根据客户端报送的数据节点名称，服务自动为其初始化局部数据库数据索引对象，并将关键索引存储为HashTable的key-value模式。

并为其订阅全局数据检索和数据保存事件等，当有数据检索请求时，服务通过并行化编程技术使所有分布式客户端同时处理此事件，当某个分布式客户端处理发现本地索引中无相关key或不满足其数据分片条件时则直接退出响应。

如果相关条件都在其索引范围内，则进行本地化数据查询操作，并将结果以DataSet的形式返回至事件源。

所有并行流程执行完成后事件源将DataSet集反馈给查询者。

分布式数据库管理系统（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帮助文档和对应的服务一同纳入版本管理，即同一服务的不同版本需要提供不同的帮助文档以帮助第三方应用能够顺利的使用。