2. 安捷伦科技公司, 北京 100102
2. Agilent Technologies, Beijing 100102
正在规划设计的WMO信息系统 (WIS) 提出建立一个通用、综合、高效的信息服务平台,用于支撑WMO各项计划及其相关中心、国际组织和计划的数据交换和共享,并为各国气象和水文部门的用户提供服务.WIS系统将满足WMO各项计划提出的总体需求,其中有两项需求是:提供在线的元数据、数据目录服务;提高元数据的定义、收集、归档和交换的标准化水平.这两项需求对气象元数据的交换、同步提出了很高要求.目前,SIMDAT (ECMWF),JCOMM GISC-E2EDM (俄罗斯),CAgMWAMIS (韩国) 等项目都在为实现WIS总体目标开展大量的研发工作[1].
在我国,为提高对灾害性天气的监测预警能力和服务水平,全国需建设158部新一代多普勒天气雷达系统,雷达数据量将成几何级数增长;再者,对天气雷达进行组网观测使得区域、流域之间的信息共享十分必要;同时,雷达信息的共享时效要求高,最好能达到秒级;此外,各种业务系统对雷达资料的深层次应用开发迫切要求建立海量雷达数据、产品的规范存储与快速分发共享系统.因此,为实现气象数据、产品资料在全国范围内共享,建立天气雷达信息和其他气象数据的共享平台迫在眉睫[2].
正在建设的新一代天气雷达信息共享平台 (以下简称共享平台) 是一个分布式存储和共享服务系统,需要在国家级和省级中心分别建立元数据与目录管理系统,并完成国家级中心、各省中心的元数据同步与交换,以实现包括雷达数据在内的各类气象数据的分布式管理和元数据目录服务等功能.可以看出共享平台的建立将能够部分满足WIS系统的总体需求.本文将对共享平台的分布式气象元数据同步系统的关键技术和整体架构进行探索和研究.
1 气象元数据气象领域的元数据标准由世界气象组织 (WMO) 负责制定,历经多次修订、扩展于2006年9月正式签署发布了WMO核心元数据标准1.0版,该标准在ISO 19115系列地理元数据标准基础上针对气象数据特点进行了多项扩展,主要包括:引用日期、受约束的词汇表、层次化的分类关键词、标识数值分析时间、有效期约束等[3].这一版元数据标准作为WIS系统实现的基础,对气象数据集的描述较为完备,但仍不足以解决所有气象数据的发现、获取和展现等问题[4].首先,对数据发现的支持较为简单,不能满足用户更灵活复杂的数据发现需求;其次,数据获取方式的属性仅有联系方式等传统方法,不能用于计算机自动处理;再者,该标准侧重气象数据集的描述,而对数据如何表示则支持较弱,远没有表驱码强大;另外,该标准定义复杂,存在很多冗余信息,特别是在元数据的起始部分,这些冗余的描述信息甚至可能超过实际数据信息的几倍乃至几十倍.如果元数据同步的时候每次都传输这些冗余信息将会给网络带宽带来繁重且不必要的负担,同时也会提高对元数据存储空间的需求,最终降低元数据同步的效率.
为弥补现有WMO元数据标准的上述缺陷,在系统设计时必须针对该标准开展以下工作:①增强元数据的数据发现能力,挖掘现有标准中可利用的内部机制,如features, coverages[5],或者根据各资料特点增加新的描述元素;②充实数据获取方式,加强服务型元数据,例如增加数据检索条件、检索方式、存储、下载方式、访问控制等元素,以方便程序自动处理并提交数据给用户;③增加数据展现方式的支持,借鉴表驱码的思想,适当引入表驱码的码表、模板机制,提高元数据对数据本身的描述能力;④降低元数据传输和存储的冗余度,可以考虑采用面向对象思想的继承概念.
2 同步机制 2.1 基本概念元数据的同步本质上也就是数据同步,它们本质上都是将数据副本分散到分布式系统的各处,其目的有两个:一是提高数据访问性能;二是提高数据冗余度以增强容错能力.按照同步方向的不同,同步机制可以分为单向同步和双向同步.为应对企业应用的日益网络化,人们已对数据同步技术进行大量研究,并总结出几种常用的方法:人工方法、自动脚本方法、数据库复制方法和基于XML的消息同步方法等[6-7].其中,XML语言很适合异构分布系统的数据交换,随着XML标准和相关技术与应用的发展成熟,基于XML的消息同步机制也日臻完善,Sy ncML,Z39.50和OA I-PMH等就是从中涌现的几个比较成功的基于XML的同步机制.这种方法定义了一个同步协议,使用XML消息来添加、删除和修改数据单元,从而实现分布异构数据源之间的数据同步,有的甚至能够支持跨异构平台的信息检索.
分布网络环境下的元数据的同步依赖于合理有效的同步协议机制,下面将对两种在数字图书馆领域应用比较广泛的元数据互操作协议进行介绍,并着重对OA I-PMH协议进行讨论,从中提炼出适合分布式环境下全网元数据同步的方法.
2.2 数据一致性无论是数据同步还是元数据同步,保持数据的一致性是所有系统都不能回避的问题.在保持数据一致性上采取何种策略将从很大意义上决定气象元数据全网同步系统的效率、效果和实现难度.数据一致性模型可以分为以下两类.
2.2.1 以数据为中心的一致性模型以数据为中心的一致性模型包括:严格一致性、线性化和顺序一致性、因果一致性、FIFO一致性、弱一致性、释放一致性和入口一致性.其中前4种一致性模型没有使用同步变量操作,而后3种模型则使用了同步变量操作,并且需要额外的程序结构参与,与应用的具体需求有关,因此后3种模型的应用具有很大复杂性.前4种模型中FIFO一致性要求的条件最宽松,图 1描述了FIFO一致性模型的一个实例.
![]() |
|
图 1. FIFO数据一致性模型的实例 Fig 1. Instance of the FIFO model of data consistency |
首先A节点先后执行x=a,x=b写操作,接下来B节点写x=c,之后在C节点和D节点执行对x的读操作看到的结果分别是a,b,c和a,c,b,C和D节点读到的结果顺序 (a,b) 与在A节点执行写操作的结果顺序 (a,b) 一致,而且B节点的写操作结果c则与A节点的写操作顺序无关.上述结果可以大致归纳为:如果两个写操作由同一进程提出,则必须保证其他进程看到的这两个写操作顺序与前者保持一致;反之,则无需保证看到的顺序与写的顺序保持一致.
2.2.2 以用户为中心的一致性模型以用户为中心的一致性模型有下列4种:单调读一致性、单调写一致性、写后读一致性和读后写一致性.其中的单调读一致性的条件是:一个进程读到的数据项x的值总是与先前所做读操作读到的x值一致或比之更新.单调写一致性必须满足下面的条件:如果一个进程对数据项x进行写操作,那么该进程必须在此之前完成对x执行的任何先发出的写操作.由此可见,单调读一致性反映的是只读用户的直接感受,也就是说用户读到的某一个数据项只会保持不变或越来越新.单调写一致性与前面说的FIFO一致性相似,只不过单调写一致性强调为一个进程维持数据一致性,而FIFO一致性则考虑了并发进程的情况[8].
2.2.3 业务分析根据实际业务的需要,在数据一致性方面,气象元数据全网同步系统的基本设计原则为:①每个元数据项仅对应唯一的属主,只有属主可以对其所管辖的元数据项进行创建、修改、删除;②在某一个节点进行的先后两个对同一元数据项的写操作必须按照相同顺序传播出去,而且携带写操作的时戳信息;③用户可以容忍较短时间的元数据同步延时,即不要求元数据项的写操作立即就能在所有节点被读到.其中,①是整个同步系统设计的基础,这可以很好地避免写-写操作冲突,而②保证了同一节点对其所属元数据发出的写操作序列的顺序在其他节点读到的顺序保持不变,即满足FIFO一致性和单调写一致性,③则说明同步系统没有保持单调读一致性的需要.由此可见,从数据的角度,元数据同步系统将符合FIFO数据一致性;而从用户角度,元数据同步系统符合单调写一致性.
2.3 元数据同步协议OAI-PMH 2.3.1 协议概述OAI-PMH (Open Archives Initiative-Protocol for Metadata Harvesting) 最初是为解决电子出版物的预印本 (preprint) 的互操作和元数据采集 (metadataharvesting) 问题.目前已经扩展到数字图书馆等领域,目的是实现分布异构系统平台之间的元数据交换和共享,提高系统的互操作能力,从而推动内容的有效分发.
OAI技术中有两个关键的逻辑角色:“数据提供者 (data provider)”和“服务提供者 (service providprovider)”.数据提供者处理存储和发布仓库中的资源,并为元数据的采集“暴露”仓库中的资源,它们是元数据以及资源仓库的创建者和维护者;而服务提供者则负责从一个或多个数据提供者中采集元数据,并将这些采集来的元数据用来提供对所有相关数据的服务.这一结构的最大特点是它不仅对用户提供接口服务,也对机器提供接口服务.基于OAI的元数据互操作框架OAI-PMH协议是建立在H TTP协议基础上的应用协议,其数据提供者对来自服务提供者的请求做出响应,以OAI要求的格式 (XML) 向服务提供者提供元数据,服务提供者“采集”(harvest) 元数据,并基于元数据提供增值服务[9-12].
2.3.2 技术架构OAI-PMH协议是一个在分布式网络化环境中获取元数据信息的标准协议,它通过定义一个标准化的接口,使网络服务器能够将存储其中的元数据有选择地提供给需要这些数据的外部应用程序或其他服务器.该协议并不是想替代已有的其他协议,而只是在已有的解决策略之外再多提供一种易于实现的方法而已.OAI-PMH协议的核心主要是在HTTP协议上传输XML文件的协议,其基本功能可以用图 2来说明.
![]() |
|
图 2. OAI-PMH的基本功能 Fig 2. Basic functions of OAI-PMH |
通过图 2可以看出,OAI-PMH协议由服务提供者和数据提供者这两个角色来参与,服务提供者中的元数据采集器向数据提供者发出HTTP GET或POST采集请求,数据提供者从自己的元数据仓库中提取元数据记录并以XML的形式返回给服务提供者,最后由服务提供者根据这些采集的元数据对外提供增值服务.
2.3.3 协议动词OA I-PMH协议中提供6个基本动词元素,OA I-PMH系统中的两个实体:数据提供者和服务提供者就是通过这6个基本的动词进行“对话”来完成元数据消息的采集.6个动词中前3个用于获取元数据仓库的描述信息,后3个参与实际的元数据采集.这些动词的功能及参数见表 1.
![]() |
表 1 OAI-PMH协议动词 Table 1 The protocol verbs of OAI-PMH |
2.3.4 流量控制
流量控制 (以下简称流控) 是一个数据通信协议必须具备的特性,OAI-PMH也不例外.该协议的流控由resumption Token标识来完成[12].OAIPMH列表 (List) 请求的返回结果可能是很长的列表,需要分割成若干个协议响应消息.分割的消息所含列表长度为预设的最大值L.分割之后返回一个L长的列表和一个resumption Token标识.请求方为了得到完整的列表,需要连续发送一个或多个带resumption Token标识的请求,从而得到一个完整的列表[13-15].在气象元数据全网同步系统中应保留这一特性.
2.3.5 协议特点OAI-PMH协议属于轻量级的元数据交换同步协议,结构清晰简单 (仅由6个动词构成),实现的功能也简练实用.其底层通信协议选择的是通用的应用层协议HTTP,HTTP协议很容易穿透防火墙,适合分布式系统应用;OAI-PMH协议选择DublinCore元数据集作为承载内容的核心元数据集标准,Dublin Core格式简练,仅由15种可选元素构成,因此更容易为用户所理解和接受.综合以上各因素,气象元数据同步系统中可以考虑采用OAI-PMH作为其同步协议.
3 系统总体设计思路 3.1 布局设计未来的共享平台将在国家级气象信息中心和所有省级气象信息中心安装部署气象资料海量存储系统,为使各个中心都能就近对本辖区范围的用户提供气象数据服务,如Web检索下载等服务,国家级气象信息中心和所有省级气象信息中心也都将安装和部署功能基本一致的元数据目录服务门户.作为门户的支撑,气象元数据必须位于该门户的本地,否则在广域网环境下很难保证对数据服务门户提供响应及时的元数据目录服务.另外,共享平台将构建在MPLS/VPN的网络平台之上,理论上这种网络平台支持全网范围内点到点通信,即网上任意两节点可以直接通信,但由于考虑到成本问题,该网络平台的带宽不可能满足点到点通信都是对称高速的,目前条件只能保证省级中心到国家级中心的网络带宽足够宽.
在这种网络拓扑结构和带宽的条件下,使得有可能在共享平台中对关键的元数据信息进行分布式的收集/采集、存储和同步/共享,但是如果按照完全网状拓扑结构来进行点对点对等同步操作显然不太现实,实际的物理网络带宽无法保障,另外复杂的同步逻辑关系也不易管理.因此经过权衡考虑,宜将元数据同步拓扑设计成以国家级气象信息为中心的星型结构,这种拓扑结构简单,易于管理维护,而且符合共享平台的实际物理网络拓扑结构特点和带宽特点.各省级气象信息中心只与国家级气象信息中心进行气象元数据同步,即元数据的双向采集,国家级气象信息中心既负责将自身气象元数据与各省级气象信息中心气象元数据同步,同时还担负着在各省级气象信息中心之间存储转发气象元数据的职责.显然国家级气象信息中心起着气象元数据同步枢纽的作用,责任重大,因此在国家级气象信息中心的机器和网络配置上必须兼顾性能、吞吐能力和可靠性,在这里不作详细讨论.
3.2 概念模型设计从3.1节可知气象元数据同步系统将由1个国家级节点和多个省级节点构成.除了国家级节点和省级节点在网络拓扑中所处位置和面向的其他节点数量不同之外,这些节点在功能上没有任何区别.图 3显示了同步系统的概念模型.
![]() |
|
图 3. 气象元数据同步系统概念模型 Fig 3. Concept model of the meteo rological metadata synch ronization system |
从图 3可见气象元数据全网同步系统的每个节点都包括下面4个功能组件[16] :
① 元数据文件.元数据文件 (这些元数据文件由一个元数据编辑器负责生成和管理) 指的是最原始的元数据记录,这些元数据记录以XML文件的形式存放在文件系统中供数据提供者的仓库组件存取,仓库组件根据这些文件的时戳值判断其是否更新.
② 元数据库.该元数据库有3个作用:存储管理服务提供者从本节点数据提供者采集来的元数据记录;存储管理服务提供者从其他节点采集来的元数据记录;对元数据记录的不同类型元素生成索引,以提高检索性能.
③ 数据提供者.数据提供者接收并处理本节点服务提供者发起的OAI-PMH无更新的记录,如果有则返回XM L格式的元数据记录,没有则返回消息内容为空.数据提供者对服务提供者提供Web Services接口.各节点的数据提供者可能有多个,每个数据提供者各自独立的响应本节点服务提供者发出的采集请求.
④ 服务提供者.每个节点的服务提供者都有下列5个职能:定时向本节点所辖的数据提供者发出元数据采集请求,并接收处理从数据提供者返回的更新元数据记录,如果有新增元数据记录,则通过JDBC (Java database connectivity) 将其插入至元数据库;如果有修改的元数据记录,则修改元数据库中的记录;如果有删除的元数据记录,则从元数据库中删除相应的记录.维护1个路由信息表,这个表存放所有临近节点的路由信息,为元数据采集提供网络连接服务.定时向路由信息表里面的每个邻近节点发出的元数据采集请求,并接收处理从其他节点返回的更新元数据记录.作为本节点对外的数据提供者接收从临近节点发出的元数据采集请求,并从本节点元数据库中检索更新元数据记录返回给对方.对外提供增值服务,如:发现、检索等.
3.3 数据流程设计数据流程在本系统中主要指的是元数据流程,大致可以分成两种流程:节点内元数据流程和节点间元数据流程.
节点内元数据流程 (图 4):在节点内部,服务提供者向数据提供者发出OAI-PMH元数据采集请求,数据提供者扫描本地的元数据文件,看有无更新,如有变化则取得更新元数据列表,并向服务提供者以OA I-PMH协议响应的形式返回更新结果,服务提供者收到响应消息后将更新记录写入元数据库中,并返回执行结果.
![]() |
|
图 4. 节点内元数据流程 Fig 4. Metadata flow in a node |
节点间元数据流程 (图 5):在节点之间的元数据流程与节点内元数据流程基本类似,只不过交互对象由服务提供者-数据提供者变换为服务提供者-服务提供者,并且元数据源均为元数据库.图 5中仅描述了节点A向节点B单向采集气象元数据的过程,节点B向节点A的反向采集过程与其一致.
![]() |
|
图 5. 节点间元数据流程 Fig 5. Me tadata flow between two nodes |
3.4 技术体系结构
从图 3中可以看出气象元数据同步系统是一个松散耦合的分布式系统,系统的信息 (元数据) 完全依靠基于XML的消息协议在数据提供者和服务提供者两个组件之间进行传递,各个节点都是对等的关系,组件可以很容易在整体系统复用和部署,该系统的概念模型也符合面向服务架构 (SOA) 的一些架构特点,如:可从企业外部访问、随时可用、粗粒度的服务接口、松散耦合、可重用的服务、标准化的服务接口等等,因此采用SOA思想设计该系统是可行和适用的.
SOA是传统的面向对象模型的替代模型.面向对象的模型是紧耦合的,已经存在多年.虽然基于SOA的系统并不排除使用面向对象的设计来构建单个服务,但是其整体设计却是面向服务的.由于它考虑到了系统内的对象,所以虽然SOA是基于对象的,但是作为一个整体,它却不是面向对象的,不同之处在于接口本身.SOA架构模型可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用.服务层是SOA的基础,可以直接被应用所调用,同步系统的服务提供者组件相当于服务层的角色,它通过Web Services构建的服务总线对外提供粗粒度的元数据同步服务[17-18].
为确保气象元数据同步系统的开放性、互操作性、安全性、可伸缩性等需求,该系统建立在以Java/J2EE (Java 2 Enterpri se Edition) 为运行环境,以H TTP,OAI-PMH为消息传输和同步协议的基础之上,对跨节点的通信进行安全认证和授权,异地节点通过基于Servlet (服务小程序) 的元数据采集Web服务进行元数据XML的交换同步,而在节点内部则通过POJO (Plain Old Java Object, 简单的Jav a对象) 或EJB (Enterprise Java Bean, 企业Java组件) 业务逻辑组件将需交换同步的元数据对象经ORM (Object Relational Mapping, 对象关系映射) 后,由通用的JDBC接口从元数据库读出或写入元数据库.整个技术体系结构见图 6.
![]() |
|
图 6. 气象元数据同步系统技术体系结构 Fig 6. The technical architecture of meteo rologicalme tadata synchronization system |
4 试验分析
根据上面阐述的设计模型,开发部署了相应的试验原型,并对该原型展开了有关功能和性能测试.试验环境为硬件平台IBM x3650 Xeon服务器,操作系统SLES9,JDK1.5,测试工具Apache JMeter2.3,测试数据FY-2C气象卫星元数据.
在功能方面,试验通过日志系统采集了有关日志,系统日志记录了同步的两个主要角色:服务提供者和数据提供者之间的消息交换过程.
在性能方面,针对响应时间和吞吐量两项重要性能指标进行了测试.为体现在收割不同数量元数据记录情况下的性能指标变化,测试了该系统分别在采集1,5,20,50,100条和200条元数据记录情况下的这两项指标.图 7a显示了该系统进行元数据采集时的平均响应时间变化情况,可以看出当采集的元数据记录低于100条时,系统的响应时间变化比较平缓,基本保持在100 ms以内,而当采集元数据记录超过100条时,响应时间大于100 ms, 并且迅速上升.图 7b显示的是系统进行元数据采集的吞吐量变化情况,采集的元数据记录低于20条时的吞吐量较大,每秒大约能处理100~260个请求,而当采集的元数据记录大于20且小于200时,吞吐量减少到2位数,采集超过200条元数据记录后,吞吐量减少到个位数.
![]() |
|
图 7. 元数据采集的平均响应时间 (a) 和吞吐量 (b) Fig 7. The average response time (a) and the throughput (b) of harvesting metadata |
由上述数据可见,该原型在试验环境下能够完成基本的元数据交换同步操作,而且在一次采集低于200条元数据记录的情况下系统响应时间和吞吐量两项性能指标比较理想.
5 结束语本文对气象元数据同步系统的有关原理和概念进行研究和讨论,并以研究结果为依据,给出一个较为详细的设计模型和技术架构.气象元数据同步系统作为一个分布式数据交换平台,将综合运用元数据、元数据采集、数据同步、面向服务架构 (SOA)、Web Services及J2EE等技术.本文根据实际业务需求设想了底层元数据标准的扩展、数据一致性模型的建立和元数据同步协议OAI-PMH的采用等环节,并对未来系统的布局、概念模型、数据流程和技术体系结构进行了构想.目前该构想已经通过试验原型的开发得到实现,基本上能够在分布环境下完成气象元数据同步.
[1] | WMO Informati on System.http:∥www.wmo.int/pages/prog/www/WIS-Web/home.html. |
[2] | 国家气象信息中心. 新一代天气雷达信息共享平台建设可行性研究报告. 北京: 中国气象局, 2006 : 7-32. |
[3] | 李集明, 沈文海, 王国复. 气象信息共享平台及其关键技术研究. 应用气象学报, 2006, 17, (5): 621–628. |
[4] | 王国复, 徐枫, 吴增祥. 气象元数据标准与信息发布技术研究. 应用气象学报, 2005, 16, (1): 114–121. |
[5] | Foreman S J.WMO Core Prof ile of the ISO 19115 Met adat aSt andard.C BS, Teco-WIS, 2006. |
[6] | 崔伟, 汪诗林. 分布式系统中数据同步机制的研究与实现. 计算机工程与设计, 2007, 28, (10): 2259–2261. |
[7] | LiuM L. 分布式计算原理与应用 (影印版). 北京: 清华大学出版社, 2004: 361-401. |
[8] | Andrew S Tanenbaum, Maarten Van Steen. 分布式系统: 原理与范型. 杨剑峰, 常晓波, 李敏, 译. 北京: 清华大学出版社, 2002 : 229-254. |
[9] | Open Archives Initiative.http:∥www.openarchives.org/. |
[10] | 陈红亮, 程文青, 吴砥. 基于Web服务的数据同步机制的研究与应用. 计算机技术与发展, 2006, 16, (9): 160–162. |
[11] | 陈敏. 基于MDC数据网格信息服务系统元数据管理的研究. 武汉: 武汉理工大学, 2006. |
[12] | 宋江旺. 基于元数据的下一代网络环境自适应业务提供技术研究. 南京: 南京邮电大学, 2006. |
[13] | 郑志蕴, 徐玮, 宋瀚涛, 等. 网格环境下基于OAI的数字图书馆互操作机制. 计算机工程, 2006, 32, (10): 37–39. |
[14] | Van de Sompel H, Nelson M L, Lagoze C, et al.Resource Harvesting within the OAI-PMH. Framework.D-Lib Magaz ine, 2004, 10(12), doi:10.1045/december2004-vandesompel. |
[15] | 袁丽莉. 分布式异构数据融合技术及其在旅游中的应用. 杭州: 浙江大学, 2006. |
[16] | SIMDAT Meteorology Activity.http:∥www.ecmwf.int/services/grid/simdat/. |
[17] | Eric Newcomer, Greg Lomow.Understanding SOA with web Services, New Jersey:Addison Wesley Professional, 2005. |
[18] | Eric Pulier, Hugh Taylor, Understanding Enterprise SOA, Connectieut:Manning Publications Co, 2006 :58-158. |