CN109241161B

CN109241161B - 一种气象数据管理方法

Info

Publication number: CN109241161B
Application number: CN201810904160.7A
Authority: CN
Inventors: 张文海; 张海强; 陈林锋
Original assignee: Shenzhen Yama Technology Co ltd
Current assignee: Shenzhen Yama Technology Co ltd
Priority date: 2018-08-09
Filing date: 2018-08-09
Publication date: 2022-02-01
Anticipated expiration: 2038-08-09
Also published as: CN109241161A

Abstract

本申请涉及一种气象数据管理方法，包括：制定多源气象数据的时空分辨率标准，建立标准统一的多维网格天气数据集；基于所述多维网格天气数据集的时空分辨率标准建立数据加工及数据转换标准，对所述多源气象数据进行网格化转换；利用Cassandra技术建立分布式无中心数据库，将所述网格化转换后的多源气象数据进行聚合并分成多个节点，同时将所有节点统一组建一个集群，对所述气象数据进行统一管理。本申请气象数据管理方法通过建立标准统一、易于融合的多维网格天气数据集，并建立基于Cassandra技术的分布式无中心数据库，对气象数据进行统一管理，满足各类气象业务系统读取、处理、存储和分析、信息共享等方面的需求。

Description

一种气象数据管理方法

技术领域

本申请属于气象服务技术领域，特别涉及一种气象数据管理方法。

背景技术

随着气象事业的发展，气象大数据特征越来越明显，一方面，随着气象事业的发展，气象数据来源途径的不断增加，数据类型不断丰富，数据量呈指数地快速增长，如深圳市气象局现有上百个气象业务系统，每天产生超过500GB的数据，且以几何级数增长。传统的IT基础架构方式给管理员和未来业务的扩展带来巨大挑战，如何安全高效快速地处理、融合、解译和应用这些不同类型的海量数据对我们提出了更大的挑战。另一方面，公众对气象数据需求也越来越丰富和多样化，实现天气数据集的快速制作、标准存储、实时共享、精准监控、高效分发，实现多要素、多层次、高时空分辨率的精细化天气监测预报预警数据快速高效地为也是应对大数据和移动互联网环境下多样化和精细化的气象服务需求，对于提升服务效果意义重大。

气象灾害种类多、频率高、危害重、损失大，尤其是雷雨大风、短时强风、冰雹、龙卷风等灾害性天气具有空间尺度小、生命史短、突发性强、破坏力大等特点，在预警预报中资料的及时处理尤其重要，需要在短时间内将多要素、多层次、高时空分辨率数据的大量监测预报数据快速处理后提供给预报员分析使用，气象部门要求监测资料的提供速度由分钟级提高到秒级。为了有效应对这些挑战，满足这些需求，迫切需要引进先进的技术和方法，将这些数据从简单静态向智能动态转变管理，满足各类气象业务系统对数据进行读取、处理、存储和分析、信息共享等方面的需求，实现海量数据的归档、备份、检索和后处理等功能。

发明内容

本申请提供了一种气象数据管理方法，旨在至少在一定程度上解决现有技术中的上述技术问题之一。

为了解决上述问题，本申请提供了如下技术方案：

一种气象数据管理方法，包括以下步骤：

步骤a：制定多源气象数据的时空分辨率标准，建立标准统一的多维网格天气数据集；

步骤b：基于所述多维网格天气数据集的时空分辨率标准建立数据加工及数据转换标准，对所述多源气象数据进行网格化转换；

步骤c：利用Cassandra技术建立分布式无中心数据库，将所述网格化转换后的多源气象数据进行聚合并分成多个节点，同时将所有节点统一组建一个集群，对所述气象数据进行统一管理。

本申请实施例采取的技术方案还包括：在所述步骤a中，所述制定气象数据的时空分辨率标准具体包括：制定雷达拼图、雷达拼图外推、QPE\QPF一小时、两小时、三小时的格点数据、雷电及预报、风场的多维数据集的时空分辨率标准；制定自动站格点实况数据、卫星云图的多维数据集的时空分辨率标准；制定分区预报格点预报数据的格点实况和各3小时预报、24小时预报、10天预报的多维数据集的时空分辨率标准；制定中尺度模式产品的多维数据集的时空分辨率标准。

本申请实施例采取的技术方案还包括：在所述步骤a中，所述建立标准统一的多维网格天气数据集具体为：定义天气实况数据及预报数据的尺度，不同尺度对应不同的时空分辨率；定义4级网格数据尺度，对天气观测中卫星、雷达数据进行加密和抽稀以适应不同的空间分辨率，并对时间进行插值以适应不同的时间分辨率。

本申请实施例采取的技术方案还包括：所述步骤a还包括：利用网格计算技术，建立多维网格天气数据集应用支持系统；所述多维网格天气数据集应用支持系统用于多维网格天气数据集的快速制作、标准存储、实时共享、精准监控、高效分发。

本申请实施例采取的技术方案还包括：在所述步骤b中，所述建立数据加工及数据转换标准具体包括：建立雷达拼图、雷电、风场数据的数据加工及数据转换标准；建立自动站实况数据、卫星云图数据的数据加工及数据转换标准；建立其他站点类型数据的数据加工及数据转换标准；建立中尺度模式产品格点实况及预报数据的数据加工及数据转换标准。

本申请实施例采取的技术方案还包括：在所述步骤c中，所述利用Cassandra技术建立的分布式无中心数据库具体包括：客户端连接至节点并发出read/write请求时，该节点充当所述客户端与包含请求数据的节点之间的协调者，利用配置的partitioner和replicaplacement策略确定获取请求的节点。

本申请实施例采取的技术方案还包括：在所述步骤c中，所述利用Cassandra技术建立的分布式无中心数据库还包括：建立分布式数据存储体系，将所有存放气象数据的服务器划分成4个数据节点，再把所有数据节点随机分配到一致性哈希的圆环上；所述数据节点划分包括：

Node1：存放雷达拼图、雷达拼图外推、QPE\QPF、雷达TREC风场、雷达组合反射率、雷达径向速度、雷达回波顶高、冰雹、雷电及预报、多高度风场相关产品数据的数据节点划分；

Node2：存放自动站格点实况数据、分区预报格点预报数据的格点实况和各3小时预报、24小时预报、10天预报数据的数据节点划分；

Node3：存放QPE\QPF一小时、两小时、三小时的格点数据、雷达拼图格点数据的数据节点划分；

Node4：存放EC\JMA中尺度模式产品、卫星云图产品以及各类报文、传真文件的数据节点划分。

本申请实施例采取的技术方案还包括：在所述步骤c中，所述利用Cassandra技术建立的分布式无中心数据库具体还包括：系统数据分区和节点数据的增减管理；在系统节点间相互连通之后，采用一致性哈希的方法，用同样的哈希函数计算数据对象和节点的哈希值，用节点的哈希值作为数据集的切分点，对气象产品数据集进行切分，并存放到各个节点上。

本申请实施例采取的技术方案还包括：在所述步骤c中，所述利用Cassandra技术建立的分布式无中心数据库具体还包括：建立系统数据副本，采取Cassandra中的副本策略，复制数据副本到协调者节点的N-1个后继节点上。

相对于现有技术，本申请的有益效果在于：本申请实施例的气象数据管理方法通过建立标准统一、易于融合的多维网格天气数据集，并建立基于Cassandra技术的分布式无中心数据库，对自动站网格数据、分区预报分区预警网格数据、雷达拼图产品、QPE\QPF产品、卫星云图产品、预报文本和报文数据、各类数值预报产品等气象数据进行统一管理，满足各类气象业务系统对数据进行读取、处理、存储和分析、信息共享等方面的需求，实现海量数据的归档、备份、检索和后处理等功能，实现网格数据集安全高效智能的被使用，不再因为存储节点出故障而影响数据调用，提升了服务产品的质量和用户体验度。

附图说明

图1是本申请实施例的气象数据管理方法的流程图；

图2为Cassandra数据库数据读写请求流程示意图；

图3为Cassandra哈希环结构图；

图4为Ring环结构示意图；

图5为写流程示意图；

图6为读流程示意图；

图7为系统数据存放示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。

请参阅图1，是本申请实施例的气象数据管理方法的流程图。本申请实施例的气象数据管理方法包括以下步骤：

步骤100：制定多源气象数据的时空分辨率标准，建立标准统一、易于融合的多维网格天气数据集，并利用网格计算技术，建立多维网格天气数据集应用支持系统；

步骤100中，气象数据具有海量特征且不同气象观测手段获取的数据具有不同的时间和空间分辨率，本申请针对不同时间和空间分辨率的多源气象数据建立标准统一、易于融合的多维网格天气数据集。例如，天气雷达数据是空间分辨率1公里的格点数据，其时间分辨率为6分钟；自动气象站采集的数据是站点数据，最高时间分辨率为1分钟；卫星云图数据时间分辨率为1小时，空间分辨率为5公里；天气预报数据包括站点数据和格点数据；分区天气预报以各区指标站为基准，预报各区未来逐小时的天气；未来2小时短临预报数据以雷达数据为基础，空间分辨率为1公里，时间分辨率为6分钟的格点数据。建立天气数据集可提高多维数据的应用能力，保证各类气象数据能够安全高效被各业务系统所使用。而多维网格天气数据集标准的建立是易于融合的多维网格天气数据集的建立和应用基础。

建立多维网格天气数据的方式具体为：定义天气实况数据及预报数据的多种尺度，不同的尺度对应不同的时空分辨率，根据服务的需求定义4级网格数据尺度。天气观测中卫星、雷达数据需要进行加密和抽稀以适应不同的空间分辨率，需要对时间插值以适应不同的时间分辨率。

制定多源气象数据的时空分辨率标准主要包括以下内容：

①制定雷达拼图、雷达拼图外推、QPE\QPF一小时、两小时、三小时的格点数据、雷电及预报、风场等相关数据的多维数据集的时空分辨率标准；

②制定自动站格点实况数据、卫星云图等相关数据的多维数据集的时空分辨率标准；

③制定分区预报格点预报数据，包括各种气象要素(风、温度、降雨、闪电、能见度、湿度)的格点实况和各3小时预报、24小时预报、10天预报数据多维数据集的时空分辨率标准；

④制定中尺度模式产品，包括全国、泛华南、广东、深圳四个范围风场、温度、湿度、降雨等多维数据集的时空分辨率标准。

多维网格天气数据集应用支持系统将实现多维网格天气数据集的快速制作、标准存储、实时共享、精准监控、高效分发，实现多要素、多层次、高时空分辨率的精细化天气监测预报预警等数据快速高效地为内部和外部业务应用提供统一数据支撑，从而应对大数据和移动互联网环境下多样化和精细化的气象服务需求。网格计算源于元计算，它是利用互联网地理位置相对分散的计算机组成一个“虚拟的超级计算机”，其中每一台参与计算的计算机就是一个“节点”，而整个计算是由数以万计的“节点”组成的“一张网格”，网格计算是专门针对复杂科学计算的计算模式。网格计算模式的数据处理能力超强，使用分布式计算，而且充分利用了网络上闲置的处理能力，网格计算模式把要计算的数据分割成若干“小片”，而计算这些“小片”的软件通常是预先编制好的程序，不同节点的计算机根据自己的处理能力下载一个或多个数据片断进行计算。其实质是将分布的多台超级计算机连接成为一个可远程控制和访问的元计算系统，逐步发展为遵循开放标准、聚集网络上广泛分布的计算、存储、数据、软件、仪器设备和传感器等各种资源的分布合作计算平台，以服务的方式支撑大规模计算和数据处理等各种应用。

步骤200：根据多源气象数据的特征，基于多维网格天气数据集的时空分辨率标准建立数据加工及数据转换(data transfer)标准，对多源气象数据进行网格化转换；

步骤200中，数据转换是将数据从一种表现形式变为另一种表现形式的过程，从而使数据能够在特定场景下得到有效的使用。而建立数据转换标准是为了更好的将现有的气象数据进行统一管理，保证数据的安全高效的使用。本申请实施例中，需要建立数据转换标准的多源气象数据包括：雷达拼图数据、雷达数据、风场数据、探空数据、自动站实况数据、卫星云图数据、台风数据、灾情数据和中尺度模式产品格点实况及预报数据。其中，探空数据、自动站数据、台风数据等气象数据是站点数据，通过建立数据集标准，再对站点数据进行网格化转换。

建立数据加工及数据转换标准具体包括：

②建立雷达拼图、雷电、风场等相关数据的数据加工及数据转换标准；

②建立自动站实况数据、卫星云图等相关数据的数据加工及数据转换标准；

③建立其他站点类型数据(如台风、灾情数据)的数据加工及数据转换标准；

④建立中尺度模式产品格点实况及预报数据的数据加工及数据转换标准。

步骤300：利用Cassandra技术建立分布式的无中心数据库，对网格化转换后的多源气象数据进行聚合并分成多个节点，同时将所有节点统一组建一个集群，实现多源气象数据的统一管理；

步骤300中，Cassandra是一套开源分布式NoSQL数据库系统。Cassandra数据库是面向行，用户可连接至集群的任意节点，客户端连接到某一节点发起读或写请求时，该节点充当客户端应用与拥有相应数据的节点间的协调者，以根据集群配置确定环(ring)中的哪个节点应当获取这个请求。如图2所示，为Cassandra数据库数据读写请求流程示意图。图中协调节点10负责与客户端的交互，真正的数据在节点1、4、6上，分别表示数据的三个副本，最终只要节点1上的数据返回即可。通过无中心数据库将分散在台服务器上的自动站网格数据、分区预报分区预警网格数据、雷达拼图产品、QPE\QPF产品、卫星云图产品、预报文本和报文数据、各类数值预报产品等气象数据进行聚合并分成多个节点，同时将所有节点统一组建一个集群，实现多源气象数据的统一管理，保证各个气象数据既相互独立，但在整体上又是有机统一的；

由于Cassandra采用的是p2p(点对点通讯协议gossip)环状架构，因此动态可扩充多维网格数据集合管理引擎系统，通过一个hash算法来统一各节点。如图3所示，为Cassandra哈希环结构图。key的范围是0到2^32形成的一个环,叫做hash空间环，即hash的值空间。对集群的服务器(比如ip地址)进行hash，就能确定其在环空间上的位置。定位数据访问到相应服务器的算法：将数据key使用相同的函数H计算出哈希值h，根据h确定此数据在环空间上的位置，从此位置沿环顺时针“行走”，第一台遇到的服务器就是其应该定位到的服务器。

利用Cassandra技术建立的无中心数据库具体包括以下内容：

①节点间通信gossip

Cassandra使用点对点通讯协议gossip在集群中的节点间交换位置和状态信息。gossip进程每秒运行一次，与至多3个其他节点交换信息，这样所有节点可很快了解集群中的其他节点信息。

gossip协议的具体表现形式就是配置文件中的seeds种子节点。同一个集群的所有节点的种子节点应该一致，否则会出现集群分裂，即会出现两个集群。一般先启动种子节点，尽早发现集群中的其他节点。每个节点都和其他节点交换信息，由于随机和概率，一定会穷举出集群的所有节点。同时每个节点都会保存集群中的所有其他节点。这样随便连到哪一个节点，都能知道集群中的所有其他节点。比如cql随便连接集群的一个节点，都能获取集群所有节点的状态。也就是说任何一个节点关于集群中的节点信息状态都应该是一致的。

②Cassandra节点管理

a.启动节点

添加新的节点被称为“引导”，要引导一个节点，需要在配置文件storage-conf.xml中打开AutoBootstrap，并启动它。如果在配置文件storage-conf.xml中显式指定一个InitialToken，新的节点将引导到环上的指定位置。否则，它会选择一个Token，从磁盘空间使用最多的节点迁移一半的数据，也就是说，已经没有其他节点会引导到它的范围。

b.加入节点

只需要选择合适的InitialToken，加入到现有集群即可。

如果在配置文件storage-conf.xml中显式指定一个InitialToken，新的节点将引导到环上的指定位置。否则，它会选择一个Token，从磁盘空间使用最多的节点迁移一半的数据。符合条件的数据会自动从现有节点流入到新加入的节点。

c.删除节点

可以使用NodeProbe的decommission操作将一个活跃的节点退出当前集群，或者用NodeProbe的removetoken操作来删除一个死亡的节点。这将原节点所负责的Token范围迁移到其他节点负责，并有适当的数据复制。如果使用decommission操作，数据将从被退役节点Stream到其它节点。如果removetoken操作被使用的时候，数据将会从其余副本Stream到其它节点。

没有数据会从被退役的节点自动删除，所以如果想把被退役的节点再次投入服务，在一个不同的Token环上，应该手动删除遗留的数据。

d.移动节点

NodeProbe move：移动目标节点到一个给定Token。迁移本质上是一种较方便的退役+引导。

e.恢复节点

如果一个节点宕机之后又要恢复，通用的修复机制能够去处理任何不一致的数据。如果一个节点宕机时长超过了所配置的GCGraceSeconds(默认:10天)的时长，它可能就永久性的丢失了删除操作。除非应用没有执行删除操作，否则应该删除掉该节点的数据目录，重新启动它，并且执行removetoken来删除掉GHE环上的旧数据。

③失败检测与恢复

●gossip可检测其他节点是否正常以避免将请求路由至不可达或者性能差的节点(后者需配置为dynamic snitch方可)。

●可通过配置phi_convict_threshold来调整失败检测的敏感度。

●对于失败的节点，其他节点会通过gossip定期与之联系以查看是否恢复而非简单将之移除。若需强制添加或移除集群中节点需使用nodetool工具。

●一旦某节点被标记为失败，其错过的写操作会有其他replicas存储一段时间.(需开启hinted handoff，若节点失败的时间超过了max_hint_window_in_ms，错过的写不再被存储)。Down掉的节点经过一段时间恢复后需执行repair操作，一般在所有节点运行nodetool repair以确保数据一致。

●dynamic snitch特性:查询请求路由到某个节点，如果这个节点当掉或者响应慢，则应该能够查询其他节点上的副本。

●删除节点:节点失败后，仍然在集群中，通过removenode可以将节点从集群中下线。区别就是status如果不存在就说明下线了，DN则仍然在集群中。

●失败节点数据:数据无法正常存储到失败的节点，所以会由其他节点暂时保存，等它恢复之后，再将错过的写补充上去。

●由于一致性哈希算法在服务节点太少时，容易因为节点分部不均匀而造成数据倾斜问题，所以引入了虚拟节点：把每台server分成v个虚拟节点，再把所有虚拟节点(n*v)随机分配到一致性哈希的圆环上，这样所有的用户从自己圆环上的位置顺时针往下取到第一个vnode就是自己所属节点。当此节点存在故障时，再顺时针取下一个作为替代节点。key经过hash会定位到hash环上的一个位置,找到下一个vnode为数据的第一份存储节点。接下来的两个vnode为另外两个副本。

hash值空间&token

上面在计算key存在哪个节点上是使用往前游走的方式找到环上的第一个节点，游走是一个计算的过程。如果能够事先计算好集群中的节点(vnodes)在整个hash环的值空间，这样对key进行hash后，可以看它是落在哪个hash值空间上，而值空间和节点的关系已经知道了，所以可以直接定位到key落在哪个节点上了，这就是token的作用。

表中每行数据由primary key标识，该表为每个primarykey分配一个hash值，集群中每个节点(vnode)拥有一个或多个hash值区间。这样便可根据primary key对应的hash值将该条数据放在包含该hash值的hash值区间对应的节点(vnode)中。

④虚拟节点

在没有使用虚拟节点情况下，Ring环的tokens数量＝集群的机器数量。如图4所示，为Ring环结构示意图。图中一共有6个节点，所以token数＝6。

因为副本因子＝3，一条记录要在集群中的三个节点存在。简单地方式是计算rowkey的hash值，落在环中的哪个token上，第一份数据就在那个节点上，剩余两个副本落在这个节点在token环上的后两个节点。

图4中的A、B、C、D、E、F是key的范围，真实的值是hash环空间，例如0～2^32区间分成10份，每一段是2^32的1/10。

节点1包含A、F、E表示key范围在A、F、E的数据会存储到节点1上，以此类推。

若不使用虚拟节点则需手工为集群中每个节点计算和分配一个token。每个token决定了节点在环中的位置以及节点应当承担的一段连续的数据hash值的范围。

如图4上半部分所示，每个节点分配了一个单独的token代表环中的一个位置，每个节点存储将row key映射为hash值之后落在该节点应当承担的唯一的一段连续的hash值范围内的数据。每个节点也包含来自其他节点的row的副本。而使用虚拟节点允许每个节点拥有多个较小的不连续的hash值范围。

如图4下半部分所示，集群中的节点使用了虚拟节点，虚拟节点随机选择且不连续。数据的存放位置也由row key映射而得的hash值确定，但是落在更小的分区范围内。

使用虚拟节点的好处：

●无需为每个节点计算、分配token；

●添加移除节点后无需重新平衡集群负载；

●重建死掉的节点更快；

●改善了在同一集群使用异种机器。

⑤数据复制

当前有两种可用的复制策略：

●SimpleStrategy：仅用于单数据中心，将第一个replica(复制品)放在由partitioner确定的节点中，其余的replicas放在上述节点顺时针方向的后续节点中；

●NetworkTopologyStrategy：可用于较复杂的多数据中心，可以指定在每个数据中心分别存储多少份replicas。

复制策略在创建keyspace时指定，其中dc1、dc2这些数据中心名称要与snitch中配置的名称一致，上面的拓扑策略表示在dc1配置3个副本，在dc2配置2个副本。

⑥Partitioners

在Cassandra中，table的每行由唯一的primarykey标识，partitioner实际上为一hash函数用以计算primary key的token，Cassandra依据这个token值在集群中放置对应的行。

若使用虚拟节点(vnodes)则无需手工计算tokens，若不使用虚拟节点则必须手工计算tokens将所得的值指派给cassandra.ymal主配置文件中的initial_token参数。

⑦客户端请求

Client连接至节点并发出read/write请求时，该节点充当Client端应用与包含请求数据的节点(或replica)之间的协调者，它利用配置的partitioner和replicaplacement策略确定那个节点当获取请求。

a.写请求

●协调者(coordinator)将write请求发送到拥有对应row的所有replica节点，只要节点可用便获取并执行写请求。

●写一致性级别(write consistency level)确定要有多少个replica节点必须返回成功的确认信息，成功意味着数据被正确写入了commit log和memtable。

b.读请求

[1]直接读请求(Direct Read)；

[2]后台读修复请求(RR:Read Repair)。

●协调者首先与一致性级别确定的所有replica联系，被联系的节点返回请求的数据；

●若多个节点被联系，则来自各replica的row会在内存中作比较，若不一致，则协调者使用含最新数据的replica向client返回结果；

●协调者在后台联系和比较来自其余拥有对应row的replica的数据，若不一致，会向过时的replica发写请求用最新的数据进行更新：read repair；

●保证数据一致性：直接读请求将查询请求发送到了2个副本所在的节点。因为有两个副本，所以会比较这两个副本哪个是最新的。

●比较操作是在协调节点，因为在各个副本节点上是没办法知道其他节点的副本的。那么比较操作只需要传递时间戳就可以，因为要比较的只是哪个副本数据是最新的。

●判断两个副本的数据不一致，实际上是使用md5判断值不一样，说明两个副本的数据是不一样的。因为没有必要在比较的时候就把两个副本的全部查询结果都传送至协调节点，所以在确定哪个是最新的后，那个副本需要把查询结果传送至协调节点，再由协调节点将数据返回给客户端。

⑧读写流程

a.写流程

如图5所示，为写流程示意图。图5表示写请求分别到MemTable和CommitLog，并且MemTable的数据会刷写到磁盘上。除了写数据，还有索引也会保存到磁盘上。

先将数据写进内存中的数据结构memtable，同时追加到磁盘中的commitlog中。

memtable内容超出指定容量后会被放进将被刷入磁盘的队列(memtable_flush_queue_size配置队列长度)。

若将被刷入磁盘的数据超出了队列长度，C会锁定写，并将内存数据刷进磁盘中的SSTable，之后commit log被清空。

b.读流程

如图6所示，为读流程示意图。首先检查BloomFilter，每个SSTable都有一个Bloomfilter，用以在任何磁盘IO前检查请求PK对应的数据在SSTable中是否存在BF可能误判不会漏判：判断存在，但实际上可能不存在，判断不存在，则一定不存在，则流程不会访问这个SSTable。

若数据很可能存在，则检查PartitionKey cache(索引的缓存)，之后根据索引条目是否在cache中找到而执行不同步骤：

在索引缓存中找到：

●从compression offset map中查找拥有对应数据的压缩快。

●从磁盘取出压缩的数据，返回结果集。

没有在索引缓存中：

●搜索Partition summary(partition index的样本集)确定index条目在磁盘中的近似位置。

●从磁盘中SSTable内取出index条目。

●从compression offset map中查找拥有对应数据的压缩快。

●从磁盘取出压缩的数据，返回结果集。

由insert/update过程可知，read请求到达某一节点后，必须结合所有包含请求的row中的column的SSTable以及memtable来产生请求的数据。例如，需要更新包含用户数据的某个row中的email列，Cassandra并不重写整个row到新的数据文件，而仅仅将新的email写进新的数据文件，username等仍处于旧的数据文件中。为节省CPU和磁盘I/O，Cassandra会缓存合并后的结果，且可直接在该cache中更新row而不用重新合并。

⑧Cassandra维护数据一致性策略

1)、逆熵

Cassandra数据库在分布式的架构上借鉴了Amazon的Dynamo，而在数据的存储模型上参考了Google的Bigtable，因而在数据一致性方面与Dynamo和Bigtable有着很深的联系，逆熵机制就是这种联系的一种体现。

逆熵与gossip协议一样也是基于传染病理论的算法，它主要用来保证不同节点上的数据能够更新到最新的版本。要了解逆熵必须先来了解一下Merkle Tree，在Cassandra中每个数据项可以表示为(key,value)对，key均匀的分布在一个2^n的key空间中(比如key可以取value的SHA1hash值)。两个节点在进行数据同步时分别对数据集生成一个MerkleTree。Merkey Tree是一棵二叉数。Merkel Tree的最底层可以是16个key的异或值(xor)。每个父节点是两个子节点的xor值。这样，在比较的时候，两个节点首先传最顶层的treenode,如果相等，那么就不用继续比较了。否则，分别比较左右子树。Cassandra正是基于上述所说的比较机制来确定两个节点之间数据是否一致的，如果不一致节点将通过数据记录中的时间戳来进行更行。

2)、读修复

有两种类型的读请求，一个协调器(读代理)可以将这两种读请求发送到一个副本：直接读请求和读修理请求。读请求所要读取的副本的数量将会有用户在调用读请求自己进行设定，例如：设定为ONE时，将会只对一个副本进行读取，设定为QUORUM，则会在读取超过半数的一致性的副本后返回一份副本给客户端。读修复机制在读请求结果发送回用户之后将对所有的副本就行检测和修复，确保所有的副本保持一致。

用户在向Cassandra请求数据时已经指定了一致性的级别，读请求的协调器就根据用户的一致性界别对Cassandra数据库中的符合一致性界别的节点进行读取，并将读取出来的结果进行比较，检查他们是不是一致的，如果是一致的，那么毫无意外返回相应的值即可，如果不是一致的，则基于时间戳从这些数据中提取出最新的数据返回给用户。结果已经返回给用户了，然而为了确保数据在数据库中的一致性，Cassandra将会在后台自己进行所有相关数据的副本一致性的检测，并且对那些不满足一致性的数据进行一致性同步，这就是读修复机制的修复过程。

3)、提示移交

当一个写请求到达Cassandra时，如果此时负责这部分的Cassandra节点由于种种原因不能够达到用户指定的副本因子的要求，这个时候写入将会成为麻烦的事情，写入将会因为节点的缺失而失败。为了解决这样的问题，Cassandra和其他一些分布式的场景一样提出了提示移交机制。该机制是指当写入因为相应节点不能够满足副本因子时，将会把数据写到其他的节点上去，之后向用户返回写入成功，当相关的节点又恢复服务之后，Cassandra将写入其他节点的那部分数据在从新写入到该节点。

提示移交允许Cassandra对于写操作永远可用，降低了在写节点恢复服务之后的不一致的时间，当用户的一致性级别定为ANY时，也就是意味着即便是有一个提示被记录下来，写操作也就可以认为是成功了。例如：Key A按照规则首要写入节点为N1，然后复制到N2。假如N1宕机，如果写入N2能满足一致性级别要求，则Key A对应的Row Mutation将封装一个带hint信息的头部(包含了目标为N1的信息)，然后随机写入一个节点N3，此副本不可读。同时正常复制一份数据到N2，此副本可以提供读。如果写N2不满足写一致性要求，则写会失败。等到N1恢复后，原本应该写入N1的带hint头的信息将重新写回N1。

4)、分布式删除

很多在单机中非常简单的操作，一旦放在集中分布式的环境当中就没有那么简单了，就像删除一样，单机删除非常简单，只需要把数据直接从磁盘上去掉即可，而对于分布式，则大大不同了。分布式删除的难点在于：如果某对象的一个备份节点A当前不在线，而其他备份节点删除了该对象，那么等A再次上线时，它并不知道该数据已被删除，所以会尝试恢复其他备份节点上的这个对象，这使得删除操作无效。

分布式删除机制正是为了解决以上的所提到的分布式删除的所遇到的问题。删除一个column其实只是插入一个关于这个column的墓碑(tombstone)，并不直接删除原有的column。该墓碑被作为对该列族的一次修改，记录在Memtable和SSTable中。墓碑的内容是删除请求被执行的时间，该时间是接受客户端请求的存储节点在执行该请求时的本地时间(local delete time)，称为本地删除时间。需要注意区分本地删除时间和时间戳，每个列族修改记录都有一个时间戳，这个时间戳可以理解为该column的修改时间，是由客户端给定的，而本地删除时间只有在采用分布式删除机制时才会有。

由于被删除的column并不会立即被从磁盘中删除，所以系统占用的磁盘空间会越来越大，这就需要有一种垃圾回收的机制，定期删除被标记了墓碑的column，而在Cassandra当中垃圾回收是在压紧的过程中完成。

⑨建立分布式数据存储体系

动态可扩充多维网格数据集合管理引擎系统把所有存放气象产品数据的服务器划分成4个数据节点，再把所有数据节点随机分配到一致性哈希的圆环上，这样所有的气象业务系统从自己圆环上的位置顺时针往下取到第一个Node就是自己所属节点。当此节点服务繁忙或存在故障时，再顺时针取下一个作为替代节点。数据节点划分规划如下：

Node1：存放雷达拼图、雷达拼图外推、QPE\QPF、雷达TREC风场、雷达组合反射率、雷达径向速度、雷达回波顶高、冰雹、雷电及预报、多高度风场等相关产品数据的数据节点划分。

Node2：存放自动站格点实况数据、分区预报格点预报数据，包括各种气象要素(风、温度、降雨、闪电、能见度、湿度)的格点实况和各3小时预报、24小时预报、10天预报数据的数据节点划分。

Node3：存放QPE\QPF一小时、两小时、三小时的格点数据、雷达拼图格点数据的数据节点划分。

Node4：存放EC\JMA中尺度模式产品，包括全国、泛华南、广东、深圳四个范围地面～925hpa高度共6层的风场、温度、湿度、降雨、变温、变压等图形产品。卫星云图产品以及各类报文、传真文件等的数据节点划分。

⑩系统数据分区和节点数据的增减管理

在系统节点间相互连通之后，需将大规模的气象产品数据集合进行切分，并存放到各个节点上。系统采用一致性哈希的方法，对气象产品数据集进行切分，其基本思想是用同样的哈希函数来计算数据对象和节点的哈希值，用节点的哈希值作为数据集的切分点，这样气象产品数据集群中有多少个计算节点，数据集就被切分成多少份。

数据区间的量等于集群中节点，每一个节点负责存储环中它本身和它前面节点之间的这个数据区，如图7所示，为系统数据存放示意图。图中四种颜色的区间被放在对应ABCD四个节点上，节点负责的区域确定后每个节点都保存一个区间表，对于一个新插入的数据行到底该放在哪节点上，系统采用顺时针绕环规则，比如数据A-305在顺时针方向A到B这个区间上，即落到了A到B区间上，它就存在B节点上；数据A-226落到C到D区间，它就存储在D节点上。

一致性哈希方法的优点主要有两条：一、在确定了哈希函数和节点区间表之后，客户端自己就可以知道一个数据对象该存放在哪个物理节点上，因此不需要全局的元数据服务器；二、当节点数量改变时，不需要将所有数据对象在新的集群中进行重新分配，具体来讲，如果删除一个节点，邻近的机器就会接管删除节点的数据，如果新增一个节点，邻近的机器就会分摊掉一部数据给新节点。

系统删除节点，当前面的节点B离开后，数据对象A305就从节点B移到了节点C，而节点A和节点D所管理的数据不变，假如B节点离开了系统后，E节点加入到了系统，注意E的位置与B的位置不同，这时C负责存储的数据就摊给了E节点。

建立系统数据副本

数据副本是提高系统读性能并保证系统可靠性的重要手段。副本存储是指把数据对象重复存储在两个以上节点。全副本是指数据对象存储在所有节点上；全冗余数据库就是在每一个节点上都存储一个完整的数据库。动态可扩充多维网格数据集合管理引擎系统采取的是副本存储的方式，既保证数据的安全可靠，又不占有太多服务器资源。动态可扩充多维网格数据集合管理引擎系统采取Cassandra中的副本策略——简单策略，也就是复制数据副本到协调者节点的N-1个后继节点上。

副本可以带来很多的好处，包括可用性(包含r的某些数据节点失效，不会导致数据r完全不可用)、并行化(对于r的数据查询，可以通过多台含有r副本的节点并行获得)、减少数据的传输(数据项r被多个节点所拥有，可以在这些节点上本地获取数据r)。

本申请实施例的气象数据管理方法通过建立标准统一、易于融合的多维网格天气数据集，并建立基于Cassandra技术的分布式无中心数据库，对自动站网格数据、分区预报分区预警网格数据、雷达拼图产品、QPE\QPF产品、卫星云图产品、预报文本和报文数据、各类数值预报产品等气象数据进行统一管理，满足各类气象业务系统对数据进行读取、处理、存储和分析、信息共享等方面的需求，实现海量数据的归档、备份、检索和后处理等功能，实现网格数据集安全高效智能的被使用，不再因为存储节点出故障而影响数据调用，提升了服务产品的质量和用户体验度。本申请可以提高各类数据检索效率：获取常规观测产品等数据量在2M以下数据在200毫秒内完成，数据量较大的卫星数据应在2000毫秒内完成，较原有处理方法时间效率提升30-50倍；同时，数据的稳定性时间延长：气象业务系统一般是24*365天连续运行，因此数据的稳定对气象业务特别重要，调用处理后数据的系统平均无故障时间1000小时以上，用户端平均无故障时间2000小时以上。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本申请中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本申请所示的这些实施例，而是要符合与本申请所公开的原理和新颖特点相一致的最宽的范围。

Claims

1.一种气象数据管理方法，其特征在于，包括以下步骤：

步骤c：利用Cassandra技术建立分布式无中心数据库，将所述网格化转换后的多源气象数据进行聚合并分成多个节点，同时将所有节点统一组建一个集群，对所述气象数据进行统一管理；

在所述步骤a中，所述制定多源气象数据的时空分辨率标准具体包括：制定雷达拼图、雷达拼图外推、QPE\QPF一小时、两小时、三小时的格点数据、雷电及预报、风场的多维数据集的时空分辨率标准；制定自动站格点实况数据、卫星云图的多维数据集的时空分辨率标准；制定分区预报格点预报数据的格点实况和各3小时预报、24小时预报、10天预报的多维数据集的时空分辨率标准；制定中尺度模式产品的多维数据集的时空分辨率标准；

在所述步骤a中，所述建立标准统一的多维网格天气数据集具体为：定义天气实况数据及预报数据的尺度，不同尺度对应不同的时空分辨率；定义4级网格数据尺度，对天气观测中卫星、雷达数据进行加密和抽稀以适应不同的空间分辨率，并对时间进行插值以适应不同的时间分辨率。

2.根据权利要求1所述的气象数据管理方法，其特征在于，所述步骤a还包括：利用网格计算技术，建立多维网格天气数据集应用支持系统；所述多维网格天气数据集应用支持系统用于多维网格天气数据集的快速制作、标准存储、实时共享、精准监控、高效分发。

3.根据权利要求2所述的气象数据管理方法，其特征在于，在所述步骤b中，所述建立数据加工及数据转换标准具体包括：建立雷达拼图、雷电、风场数据的数据加工及数据转换标准；建立自动站实况数据、卫星云图数据的数据加工及数据转换标准；建立其他站点类型数据的数据加工及数据转换标准；建立中尺度模式产品格点实况及预报数据的数据加工及数据转换标准。

4.根据权利要求3所述的气象数据管理方法，其特征在于，在所述步骤c中，所述利用Cassandra技术建立分布式无中心数据库具体包括：客户端连接至节点并发出read/write请求时，该节点充当所述客户端与包含请求数据的节点之间的协调者，利用配置的partitioner和replicaplacement策略确定获取请求的节点。

5.根据权利要求4所述的气象数据管理方法，其特征在于，在所述步骤c中，所述利用Cassandra技术建立的分布式无中心数据库还包括：建立分布式数据存储体系，将所有存放气象数据的服务器划分成4个数据节点，再把所有数据节点随机分配到一致性哈希的圆环上；所述数据节点划分包括：

6.根据权利要求5所述的气象数据管理方法，其特征在于，在所述步骤c中，所述利用Cassandra技术建立的分布式无中心数据库具体还包括：系统数据分区和节点数据的增减管理；在系统节点间相互连通之后，采用一致性哈希的方法，用同样的哈希函数计算数据对象和节点的哈希值，用节点的哈希值作为数据集的切分点，对气象产品数据集进行切分，并存放到各个节点上。

7.根据权利要求6所述的气象数据管理方法，其特征在于，在所述步骤c中，所述利用Cassandra技术建立的分布式无中心数据库具体还包括：建立系统数据副本，采取Cassandra中的副本策略，复制数据副本到协调者节点的N-1个后继节点上。