引言

世界气象组织信息系统 (WMO Information System, WIS) 是世界气象组织 (WMO) 正在组织开发的综合、通用的信息服务平台，用以支撑WMO各项计划以及相关国际组织和计划的数据交换和共享^[1]。全球信息系统中心 (GISC) 是WIS的核心功能中心^[2]，承担全球交换资料的收集和分发，提供对WIS全部数据的发现和访问服务。中国气象局国家气象信息中心 (NMIC) 目前是全球电信系统 (GTS) 主干通信网的亚洲区域通信枢纽 (RTH)，建成北京GISC是中国气象局的既定目标，也是巩固和提升中国气象局在WMO通信网络及信息系统中的地位和影响力的重要举措^[3]。

北京GISC是全球首批业务运行的GISC之一，其服务系统可收集责任区内提供全球交换的数据和产品，与其他GISC交换全球数据，提供责任区内的数据收集或产品中心 (DCPC) 和国家中心 (NC) 对WIS全部数据的发现和访问服务。包括国家气象中心、国家卫星气象中心、国家气候中心在内的中国气象局内部DCPC于2012年获得第64届WMO执行理事会批准投入业务试运行，所有提供的数据和产品都可以通过北京GISC进行发现、访问和检索服务。

按照WIS/GISC要求，每个GISC须至少缓存24 h内的全球交换数据，若授权用户通过元数据浏览或者检索发现到某些关心的数据条目，可以链接形式显示出这些缓存的本地数据。此外，所有这些数据资料均需要进行文件名和传输格式的规范化处理。

1.   GISC数据缓存服务

1.1   数据发现、访问和检索服务

当前，WIS分两部分并行实施^[4]：一部分将继续发展GTS，基于实时推送机制，进一步改进高时效和关键业务的资料、产品的服务提供，包括警报；另一部分则是通过Internet提供数据发现、访问和检索 (DAR) 服务，并基于请求/应答的拉取机制提供灵活及时的数据获取。GISC中的缓存数据下载是DAR服务的一部分内容，它是DAR服务对于24 h全球交换数据访问的具体实施。

每个GISC需要维护包括全球交换资料在内的WIS服务数据的元数据目录并提供访问，以支持DAR功能, 包括上传、修改和删除元数据，用户发现和访问元数据，元数据同步^[5]等功能。

1.2   DAR元数据

参考国际所公认的空间信息元数据标准^[6]引入气象元数据^[7-8]，使用元数据来描述气象数据是解决气象数据共享的理想办法^[9]。目前WMO各GISC发布的气象元数据均须遵循WMO核心元数据标准，但由于不同WMO成员对元数据描述内容的需求和利用元数据提供应用服务方面存在差异，各成员各自创建满足自身需求的气象元数据，但所有在WIS中注明来源的资料均将根据ISO标准由相关元数据定义。北京GISC系统中的元数据采用XML格式记录元数据，目前已遵循WMO最新的核心元数据标准 (1.2版本)，主要由文件标识、语言、字符集等15个主要元素组成，可以描述产品和数据的名称、时间、地理位置等属性以及数据格式和数据获取方式、地址等数据服务信息，是北京GISC系统提供数据发现和访问服务的基础。对于WMO全球交换数据的元数据描述中，使用固定的文件标识“urn:x-wmo:md:int.wmo.wis:T1T2A1A2iiCC CC”，其中，T1T2A1A2iiCCCC是简式报头项，其余部分为固定字符串。通过文件标识中简式报头项可以匹配到一个时间序列的某类WMO全球交换数据。

根据不同使用目的，北京GISC中元数据以3种形式进行存储：① 将GISC数据应用相关的元数据抽取其中部分信息存储在关系型数据库中，为GISC数据应用提供便利，如缓存数据是否存在对应元数据的检查；② 为支持元数据文件的访问，提供元数据的XML文件存储；③ 为支持GISC全文检索功能，以BLOB (二进制大对象) 数据类型将元数据存储于数据库中。

1.3   数据缓存

北京GISC缓存数据有两部分数据来源：一是直接通过GTS接收到的全球交换数据，二是通过网页数据收集收集的数据^[10]。二者虽然数据来源不同，但通过统一的文件名格式保证数据缓存功能可以进行统一处理。对于GTS接收到的全球交换数据，为了保证用户下载缓存数据的效率，由GTS直接将WMO全球交换数据送至北京GISC系统指定目录结构进行缓存，当用户请求这些数据下载时，系统可直接将数据文件返回给用户，减少因通过从中国气象局本地实时数据库进行数据检索的耗时。

根据WIS/GISC的要求，对于进入GISC数据缓存中但不存在元数据文件的数据文件，系统能够进行识别和告警提示，并允许120 s的非法校验时间延迟^[11-12]。如果120 s内收到数据文件的元数据文件，系统将在GISC数据缓存中提供该数据文件的访问服务, 否则标识其为非法文件不提供服务。由于检查缓存数据合法性是通过判定系统中是否存在与之对应的元数据，需要进行数据库检索操作。

GISC数据缓存的物理存储结构设计如图 1所示。所有缓存数据根据处理逻辑结果的不同被存储在不同目录中，如未知格式文件 (unknown)、重复文件 (repeat)、非法文件 (error)、过期文件 (outdate)、120 s时间延迟待校验文件 (wait) 等。所有通过检查的合法数据将根据文件名中简式报头T1T2A1-A2iiCCCC项存储在指定的子目录 (entry) 中，子目录分为CCCC (指WMO成员) 和TT (指资料类型) 两级。

图  1  数据缓存的物理存储结构

Figure  1.  Physical storage structure of data cache

下载: 全尺寸图片 幻灯片

2.   基于数据库检索的数据缓存处理现状

2.1   处理性能低

为了满足缓存数据检查需求，必须循环扫描缓存入口文件目录，在处理掉重复文件和非法格式文件后，提取正确文件名中简式报头信息进行元数据匹配检索操作，如果判定数据合法则将数据拷贝到entry的指定子目录，否则进入wait目录等待120 s的时间延迟校验。随着北京GISC系统投入业务试运行，系统中以关系型数据库表形式存储的元数据记录已超过100000条，并且不断增多，而每天WMO全球交换数据文件总数超过50000个。图 2记录了2012年2月29日00:00—05:59(世界时，下同) 时间段内缓存数据入口目录每秒接收文件数统计趋势图，可以明显看出数据进入目录时间分布不均匀，如在00：36：20，有504个文件进入入口目录；大约在02：40—03：50，国外数值预报产品资料会非常密集地进入入口目录。由于GTS每日例行进行数据交换，特定某日某时段的数据接收情况具备普遍性，在其他时间段里，也存在时间分布不均的情况。

图  2  2012年2月29日00：00—05：59缓存入口目录文件接收个数统计

Figure  2.  The number of receiving files from data cache entry directory from 0000 UTC to 0559 UTC on 29 Feb 2012

下载: 全尺寸图片 幻灯片

系统为了判断该条数据是否有效，现有的技术方案要求每条数据都需要进行数据库表查找操作，选择2012年2月29日00：25—00：35 10 min内59个文件的通过数据库进行查找的时间延迟统计，如图 3所示。为提高效率，系统开启5个多线程并行处理，元数据信息表也添加索引进行优化，但处理性能仍然不理想，并且性能也可能随时因系统负载增大而降低。尽管不在数据密集到达时间段，但检索耗时平均时间大约是500 ms。通过在多个其他不同时间段的反复测试结果显示，检索耗时平均超过500 ms。在同时开启5个处理线程情况下, 500份文件仅数据检索操作就需要50 s，这对于120 s时间延迟校验会导致较大误差，若遇到数据密集到达时甚至会出现1条数据等待120 s还未进行校验就已标记为非法的情况。

图  3  2012年2月29日00:25—00:35原有技术方案中元数据文件检索耗时

Figure  3.  The metadata files retrieval consuming time in the original technical solutions from 0025 UTC to 0035 UTC on 29 Feb 2012

下载: 全尺寸图片 幻灯片

2.2   扩展能力弱

除数据缓存服务外，GISC系统还有其他功能需要依托缓存处理实现，例如：① 数据缓存日志信息记录，为了提供缓存数据监视功能，所有数据缓存的处理结果需要实时记录；② 缓存数据订阅处理，在判断缓存数据合法后检查是否有用户进行订阅，一旦是用户订阅的数据则将数据链接到订阅用户分发目录。由于原有缓存处理性能低，为了尽可能保证效率，系统不能在该功能上进行扩展以支持相关功能的实现，否则会因为额外的处理逻辑加剧缓存处理效率下降。

3.   基于内存对象缓存应用的优化处理方案

3.1   问题分析

传统的建立数据库索引，启用多线程方法能一定程度提高处理效率，但无法从根本上避免频繁读写操作带来的耗时，而其中大量读写操作来自对数据库的访问，因此需要对处理方式进行优化，减少数据库访问。

近年来，内存容量不断提高，价格不断下跌，操作系统已经可以支持更大的地址空间，充分利用内存技术提升系统性能成为一个热点^[13-14]。较为普遍的做法是使用内存数据库技术 (也叫主存数据库技术)，对查询处理、并发控制和恢复的算法和数据结构进行重新设计，以便更有效地使用内存。相对于磁盘访问，内存数据读写速度要高出几个数量级。这种做法实现复杂度较高，即使利用已有的中间件产品，由于不了解其中的实现算法，其运行稳定性和可靠性存在风险。常见的开源内存数据库产品包括Memcached和Redis^[15]。

Memcached是一款基于事件处理的分布式内存数据库产品。Memcached没有过多考虑数据的持久化问题，一旦重新启动操作系统会导致全部数据消失，如果使用Memcached来解决数据缓存的校验功能，需要通过二次开发解决处理日志信息的持久化问题。Memcached按照固定的块大小分割内存来解决内存碎片问题，若存储长度不一的元数据信息表时无法充分利用内存。

Redis在很多方面与Memcached具有相同的特征，不同在于Redis增加了持久化的功能，Redis定期通过异步操作将数据库内容拷贝到硬盘。但Redis需要通过额外的数据裁剪功能来保证合理的内存使用空间，使得应用复杂度增加。

数据缓存处理功能仅针对独立的元数据数据表进行操作，考虑一种简单方案是使用内存对象缓存技术^[16-17]，将某些量小、使用次数多的数据以键 (key)/值 (value) 对的方式保存在内存对象缓存系统中，合理增大内存缓冲，优化数据结构，改进查询访问的命中率，提升整体效率。这种方法实现复杂度小，通过自主开发相应的程序，有针对性地解决GISC缓存处理的业务逻辑。

3.2   技术实现

如图 4所示，基于内存缓存技术的应用定期更新抽取元数据信息表中的信息，封装成元数据信息对象后载入内存，进行数据的合法性检查、延迟处理以及订阅等业务逻辑。

图  4  数据缓存功能处理流程图

Figure  4.  Workflow of data cache functionality

下载: 全尺寸图片 幻灯片

由于元数据列表不是链表或者树形结构的序列，不能直接使用任何排序方法来提高查找效率。采用哈希表存储这种离散的对象数据^[18]后，可通过建立哈希索引来提高检索效率。哈希表 (Hash Map) 是将键通过固定的哈希函数转换成一个整型数字，然后将该数字对数组长度进行哈希散列运算，运算的结果被当作数组的下标，然后将值存储在以该数字为下标的数组空间里。当使用哈希表进行查询的时候，再次使用哈希函数将键 (key) 转换为对应的数组下标，并定位到该空间获取值 (value)。

如图 5所示，元数据通过简式报头哈希索引来管理：抽取元数据标识中简式报头T1T2A1A2iiC-CCC项作为哈希表的key项，对应的元数据信息作为value项，每个对象包含元数据校验、更新必须的属性信息。

图  5  基于哈希表的内存对象组织

Figure  5.  Structure of the memory objects based on Hash Map

下载: 全尺寸图片 幻灯片

为了满足数据订阅、延迟处理等功能，采用多线程机制，封装其他的功能对象进行并发处理 (如图 6所示)。

图  6  多线程缓存处理类图

Figure  6.  Class diagram of multi-threaded cache processing

下载: 全尺寸图片 幻灯片

① 守护进程对象：监视和控制各个线程的运行状态。

② 入口文件检查对象：当检测到缓存入口目录数据到达时，通过查找内存对象缓存是否有对应的报头T1T2A1A2iiCCCC来检查入口数据有效性，未找到匹配信息的数据放入延迟检查目录。

③ 等待文件检查对象：等待120 s非法校验延迟目录中的数据文件的元数据文件是否存在，仍然没有则判定该数据非法。

④ 元数据更新对象：初始运行时元数据库中元数据列表一次性导入内存，此后内存对象缓存将定期增量更新，同步频率可以进行配置。

⑤ 订单更新对象：判断合法的缓存数据是否为用户订阅的数据，如果是，则将数据文件链接到用户订阅分发目录^[19]。

⑥ 日志记录对象：为提供缓存日志信息功能，系统采取日志信息异步更新方法，当内存中保存的日志信息超过配置限额时，一次性将日志持久化写入磁盘，减少磁盘操作。

4.   优化效果

优化的数据缓存应用处理效率高，还可以扩展进行订阅处理操作，使得数据处理耗时平均小于5 ms，能保证缓存数据高效率的处理需求，并提供缓存日志记录以及订阅数据处理等扩展功能。图 7是通过内存对象缓存应用进行缓存数据检查的优化效果，选择2012年2月29日13：00—13：40缓存数据文件处理延迟情况。

图  7  2012年2月29日13：00—13：40优化后缓存数据文件处理时间延迟

Figure  7.  The data cache file processing delay in optimized technical solution from 1300 UTC to 1340 UTC on 29 Feb 2012

下载: 全尺寸图片 幻灯片

5.   小结

分析现有数据缓存处理的性能瓶颈主要在于频繁访问数据库的磁盘读写耗时，通过建立一个内存对象缓存应用优化传统数据库检索处理方式，将需要使用的数据一次性组织在内存中，有效减少了数据库查询访问带来的性能下降。该方案也为其他海量数据处理应用提供了一种新的解决思路，特别是针对数据具备动态变化特性以及高时效要求的场景。传统的关系型数据库在应对高时效的数据处理时受制于磁盘读写性能，而广泛采用的内存数据库中间件产品则复杂度太高，很难满足特殊的气象资料复杂的处理逻辑。因此，采用内存对象缓存应用是介于二者的一种方案，既能与关系性数据库较好衔接，又能减少关键的核心处理的磁盘读写操作，可以有效降低数据库的负载，提高处理性能。

随着WIS进一步发展，GISC缓存数据的范围可能不限于WMO全球交换数据，为了保证7×24 h业务的高效、可靠运行，提供分布式的缓存应用，需要研究多机内存缓存机制并构建一种分布式的缓存应用。