视界:ECMWF 产品数据存储(ECPDS)

目录

声明

本文正文内容翻译自 ECMWF Newsletter Number 159 - Sprint 2019 中的文章《The ECMWF Production Data Store》,版权归ECMWF所有。翻译底稿来自Google翻译。

正文

为了确保将 ECMWF 的预报及时交付给成员国,合作国和其他用户,必须迅速收集来自全球的观测结果,并且必须可靠且在有限的时间内将预报结果交付给用户。 这些收集和分发过程曾经由单独的软件应用程序处理。 但是,这两项活动对数据服务(例如存储,传输,调度,安全性和监视)有相似的要求。 经过仔细考虑,ECMWF 在 2016 年决定将这两个应用程序合并为一个,即 ECMWF Production Data Store(ECPDS)。

从那时起,ECMWF 内部开发了 ECPDS 软件,以支持 ECMWF 战略目标,同时牢记以下目标:

  • 确保满足模式系统对更大数量(更高分辨率)和更多观测结果的不断发展的需求
  • 支持向我们的预报用户提供越来越多的变量
  • 加快我们的预报产品的分发速度
  • 使 ECMWF Data Services function 能够在世界气象组织(WMO)的框架内向世界各地的国家提供气象和水文服务产品,并向不断增长的商业客户提供产品
  • 向云计算基础架构过渡,以提高可扩展性和可靠性

本文介绍使 ECPDS 满足这些目标的解决方案,并说明其主要功能。

图1 ECPDS 主要组件的示意图。

基本功能

ECPDS 被设计为多用途存储库,以下称为数据存储(Data Store),可提供与数据相关的三种不同策略的服务(图1):

  • 数据采集:自动发现和检索来自数据提供者的观测数据
  • 数据分发:将气象产品自动分发给我们的成员国和合作国以及其他预报用户
  • 数据门户:提取气象产品并推送由远程站点获取的观测数据。

数据采集和数据分发是由 ECPDS 启动的主动服务,而数据门户是由远程站点的传入请求而触发的被动服务。 换句话说,数据门户服务提供对数据分发和数据采集服务的交互式访问。

与传统的数据存储不同,ECPDS 不必将数据物理存储在持久存储库中,而是通过对数据提供者的元数据进行抓取和索引来像搜索引擎一样工作。 当然,ECPDS 可以在其数据存储中缓存数据。 这对于确保 ECPDS 中的数据可用性非常有用,不需要依赖于数据提供者的即时访问。 可以通过不同的机制将数据归档到数据存储中:

  • 数据采集服务发现并从数据提供者获取数据
  • 数据提供商通过数据门户积极推送数据
  • 数据提供者使用 ECPDS API 来注册元数据:ECPDS 检索调度程序将从数据提供者异步获取数据,或者在需要时即时检索数据。

可以通过名称或元数据在 ECPDS 中在线搜索数据产品,数据的内容可以由数据分发服务推送,也可以由用户从数据门户中拉到指定的位置。 只要需要数据,ECPDS 就会从数据提供者即时流式传输,或者直接从其数据存储中发送,前提是该数据先前已由 ECPDS 检索调度程序获取过。

ECPDS 的一个关键特点是,它可以轻松地与各种环境进行交互,而不会给数据提供者或用户带来支持一种或多种协议的负担:

  • 由数据采集和分发服务启动的传出连接,使用最常见的协议,例如 ftp,sftp,ftps,GlobusFtp,http/s 和 AmazonS3
  • 可以使用各种协议(例如 ftp,sftp,scp 和 https)建立与 Data Portal 服务的传入连接。

后续选项根据所选的协议和身份验证方法而有所不同(例如,基于密码的身份验证与基于密钥的身份验证,明文与密文连接,连接池与直连,并行连接与串行连接等)。

ECPDS 软件是模块化的,每个协议都已部署为系统的扩展。 所有扩展都使用通用 API,向用户隐藏复杂性,并提供数据存储的统一视图。 当新协议可用或某些用户需要时,会定期地添加新协议。 随着云计算的出现,最近添加了 AmazonS3 协议,并且正在支持 Microsoft Azure。 这些新协议已引入到 ECPDS 中,使气象产品直接分发到云对象存储成为可能。

ECPDS 的另一个关键特点是其能够通过使用多种网络,对接广泛的数据提供者(因为预报技能取决于来自世界各地各种来源的观测结果的可用性),成员国和合作国中的用户以及其他用户:

  • 高速连接的互联网
  • 区域气象数据通信网(RMDCN)
  • ECaccess 网络,在全球范围内部署了许多 ECaccess 网关
  • 具有专用租用线路的超高速带宽网络

对象存储

ECPDS 将数据存储为“对象”,即具有关联的元数据和全局唯一标识符的数据。 对象存储系统已构建在基于文件系统的解决方案之上,并具有有效的复制机制,该机制允许跨 ECMWF 和云平台提供数据的持续可用性。 为此,ECPDS 在地理分隔的存储位置(例如美国或加拿大)中复制数据。 这也使 ECMWF 产品更接近于预报用户,从而增强了数据传输性能,使用户可以在计划发布时间更直接地访问预报产品。 ECPDS 数据持久层及其底层原始存储也可以与其他对象存储系统进行接口:将来,ECPDS 可以使用云对象存储扩展其数据存储容量,这将有助于提高可伸缩性和可靠性。

与任何对象存储系统一样,在 ECPDS 中使用的对象是无层次结构的,并且没有嵌套的树结构来存储其数据。 但是,ECPDS 可以在需要时模拟目录结构。 例如,数据提供者在将数据传输到数据门户时可以创建目录,而 ECPDS 会将这些信息作为元数据与数据一起存储。 稍后,当请求数据时,ECPDS 将能够重用此信息来构建具有目录树的虚拟文件系统。 使用元数据可使 ECPDS 根据配置显示相同数据的不同视图。 例如,一个用户可能会看到按日期组织的数据,而另一个用户可能会看到通过类型组织的数据,具体取决于用户的喜好,这些偏好是通过用户的 ECPDS 配置文件进行管理的。

ECPDS 数据存储的其他特性是:

  • 数据压缩:数据分发服务可以压缩数据。 压缩既可以在将数据传输到远程站点时动态执行,也可以在传输之前将数据放在队列中时进行。 支持最常用的压缩算法,包括 zip,gzip,bzip 或 lzma。 这很重要,因为压缩可以减少分发时间,因此可以更快地访问预报产品。

  • 数据校验和:可以预先生成或动态生成 MD5,CRC32,SHA-1 或 SHA-256 单向哈希,以保持数据完整性以防损坏。 数据分发和数据门户服务可以提供加密散列以及数据,以进行验证。 该功能通常用于识别远程站点上的损坏文件。

  • 垃圾收集:记录在 ECPDS 中的每条数据都有有效期限。 通过“垃圾收集器”,可以自动删除不再需要存储的数据。 必要时,垃圾收集器还可以在数据提供者侧进行清理。 值得一提的是,到期日没有限制,这意味着,如果需要,数据可以永远保留在数据存储中。

  • 数据备份:这使得将 ECPDS 中的整个数据集映射到各种各样的归档系统(例如 ECFS)成为可能。

监控与管理

ECPDS 为采集和分发活动提供不间断的 24/7 服务和支持。 它的监视界面对于 ECPDS 的平稳运行至关重要。 该软件与 Nagios 服务器连接,以便 ECMWF 操作员可以监视其内部操作,但是该系统还有自己的监视界面,该界面有专用工具来跟踪和调试特定于 ECPDS 服务的问题。

还可以使用管理界面来管理 ECPDS 的各个组件:

  • 数据存储:管理元数据,数据内容,传输组和数据移动器(激活或停用服务器)
  • 传输:管理目的地,传输主机(远程站点设置)和传输请求
  • 访问控制:管理执行监视任务的用户和有权访问数据门户的用户
  • 监视:用于分发和采集服务的监视显示。

这些功能可通过网站或 REST API 获得,以便与其他系统轻松集成。

面向用户的 ECPDS 概念

了解 ECPDS 的一些关键概念将帮助用户从该工具的功能中充分受益:

  • 数据文件(data files)
  • 数据传输(data transfers)
  • 目的地(destinations)
  • 分发和获取主机(dissemination and acquisition hosts)

连接到 ECPDS Web 界面的用户将遇到所有这些概念实体,它们通过不同的服务彼此关联。

数据文件是存储在 ECPDS 数据存储中的产品记录,数据文件与产品之间具有一对一的映射关系。 数据文件包含有关产品物理规格的信息,例如数据存储中产品的大小,类型,压缩和实体标签(ETag),以及数据提供者与之关联的元数据(例如气象参数,名称或有关产品的评论)。

数据传输链接到唯一的数据文件,并代表其内容的传输请求以及任何相关信息(例如调度,优先级,进度,状态,速率,错误,历史记录)。 单个数据文件可以链接到多个数据传输,因为许多远程站点都可能有兴趣从数据存储中获取相同的产品。

目的地应理解为数据排队和处理的地方,以便将数据传送到唯一的远程位置,因此名称为“目的地”。 它指定数据分发服务将数据文件的内容分发到特定远程站点所需的信息(图2)。

图2 内部和外部用户的 ECPDS 界面。顶部的导航栏显示了用户当前在工具中的位置。在这个示例中,用户创建了一个名为 EC1 的目的地。具有正确凭据的用户可以查看此目的地的状态,并可以查看数据传输的进度。他们可以管理目的地,例如请求数据传输,更改优先级以及停止或开始数据传输。

每个目的地都使用自己的配置参数实现传输调度,可以对其进行微调以满足远程站点的需求。 这些设置可以控制各种事情,例如如何通过使用数据传输优先级和并行传输来组织数据传输,或者如何使用完全可定制的重试机制来处理传输错误。

此外,目标可以与分发主机列表相关联,主要主机指示将数据传递到的主要目标系统,以及如果出于某种原因主要主机不可用时切换到的备用主机列表。

分发主机用于连接并将数据文件的内容传输到目标系统。 它使用户可以配置数据传输的各个方面,包括要使用的网络和传输协议,要放置数据的目标目录,要用于连接到远程系统的密码,密钥或证书等。

如果远程用户通过数据门户服务检索了目的地内的数据传输,那么没有分发主机附加到该目的地。 在这种特殊情况下,目的地可以看作是“存储桶”(按 Amazon S3 术语)或“ blob容器”(按 Microsoft Azure 术语)。 传输调度程序将被停用,数据传输将在队列中保持空闲状态,等待通过数据门户获取。

目的地也可以与获取主机列表相关联,以指示源系统在哪里从远程站点发现和检索文件。 像分发主机一样,获取主机包含连接到远程站点所需的所有信息,包括用于连接的网络,传输协议,源目录和凭据。 此外,获取主机还包含在源中选择文件所需的信息。 可以为每个源目录,类型,名称,时间戳和协议定义复杂的规则。

目的地可以是分发目的地,获取目的地或两者都是。 只要定义了至少一个分发主机,它将成为分发目的地,并且只要定义了至少一个获取主机,它将成为获取目的地。 定义了两者后,根据目的地配置,可以使用目的地从一个地方自动发现和检索数据并将其传输到另一地方,无论是否将数据存储在数据存储中。 这是使用 ECPDS 的常用方法。 例如,该机制为中心实施的欧盟资助的哥白尼大气监测服务提供的由 ECMWF 生成的一些区域近实时整体空气质量预报。

还有目的地别名的概念,它使将两个或多个目的地链接在一起成为可能,因此,排队到一个目的地的任何数据传输也将排队到另一个目的地。 该机制能够使用以目的地为基础定义的不同时间表和/或传输机制来处理到不同站点的同一组数据传输。 为了仅对数据传输的子集设置别名,也可以使用条件别名。

开发所有这些功能使 ECMWF 可以满足我们的主要用户群体和利益相关者的要求:

  • 成员国和合作国
  • WMO 社区
  • 商业客户

这也意味着 ECMWF 可以灵活地与中心所依赖的全球所有观测提供者进行交互。

物理架构

ECPDS是具有三个主要软件组件的分布式应用程序(图3):

  • ECPDS Master 实现应用程序的业务逻辑
  • MySQL 数据库可为配置,元数据和历史记录提供持久存储
  • 数据移动器使存储对象以及执行传入和传出数据传输成为可能

图3 ECPDS物理架构。关键组件是 ECPDS Master,MySQL数据库和数据移动器。

ECPDS Master 和 MySQL Database 都在高度弹性的环境中运行。 Internet,RMDCN 和 LAN 数据移动器当前在部署在它们自己的安全环境中的物理服务器上运行。 当前共有 37 种数据移动器可用,总容量为 1.2 PB。

为了防止停机和数据丢失,这是 ECMWF 成员和合作国的关键要求,也是 ECMWF 预报系统实时运行所必需的,已实施以下机制:

  • ECPDS Master 和 MySQL 数据库分别以主动/被动模式复制到三台服务器上:一个主动实例处理请求,两个被动实例处于待机状态。当主动实例发生故障或需要维护时,其中一个被动实例将接管工作,并且服务将正常恢复。
  • 每个数据移动器组都包含多个服务器。为了保证组中文件的可用性,运行复制过程以跨数据移动器复制文件(每个文件被复制3次)。如果相关,还可以在 ECMWF 数据移动器和其他大陆的云中的数据移动器之间执行复制。

负载平衡器配置为将传入请求分发到数据移动器中的 ECPDS 数据门户。 使用多个数据移动器和负载平衡可通过冗余提高可用性。

ECMWF 会定期升级其预报系统,并且这种升级通常伴随分发数据量的大量增加。 在这种情况下扩展 ECPDS 的方法是添加更多的数据移动器。 每个数据移动器都增加 CPU 和 I/O 功能以及磁盘空间资源。 更多的数据移动器可以处理更大的工作负载和更多的数据。

图4 ECPDS 用户界面中的交互式地图显示了全球主机的位置,在本示例中,在欧洲仅有获取主机。分发主机也可以使用类似的地图。不同的颜色指示数据传输请求的状态。红色主机集中可能表明该区域存在网络问题。(版权所有 OpenStreetMap www.openstreetmap.org/copyright)

未来挑战

为了支持他们向社会提供预预报服务,ECMWF 越来越多的预报用户需要快速且可靠地访问 ECMWF 预报。 结果,ECPDS 处理的平均数据传输量每月接近 1 PB,互联网流量呈指数增长。 ECMWF 预报产品已在 78 个国家/地区的 547 个地方分发,并从 34 个国家/地区的 557 个地方检索观测数据。 图4 显示了在欧洲检索数据的位置图。 近年来观察到的流量巨大增长已成功证明了 ECPDS 的可靠性,可用性和可扩展性。 但是,在不久的将来还需要解决其他挑战:

  • ECMWF在博洛尼亚的新数据中心:将有两个独立的数据大厅,新的网络拓扑和新的高性能计算设施。ECPDS 必须在流量增加的基础上同时适应不断变化的基础架构和不断变化的技术。
  • ECPDS 正在转向云计算以扩大其潜力:ECPDS 已经在云中运行数据移动器,但这只是一个开始,我们作为欧洲天气云以及 HiDALGO 和 LEXIS 欧盟资助项目的一部分与更广泛的社区进行了接触,应该有助于我们巩固 ECPDS 在这一领域的地位。

总体而言,ECPDS现在已经是一个成熟的解决方案,它通过使用可靠的创新技术,大大提高了我们数据服务的效率和生产力。 借助 ECPDS,ECMWF 提供了可移植且适应性强的应用程序,可以适应各种环境,并提供用户友好的工具来运行与数据相关的服务。 敬请关注!

思考

今年中国气象局气象大数据云平台即将投入业务化运行,将业务系统迁移到气象大数据云平台已是大势所趋。 部门现有业务系统全部基于高性能计算机,迁移到大数据云平台将是一个渐进的过程。 最先被迁移的将会是产品分发与制作。 即便类似 ECPDS 的数据采集和分发系统不属于部门的业务范围,我们也可以从 ECPDS 系统中借鉴优秀的设计思想。

气象大数据云平台会提供基础功能,但我们在设计系统的时候也应该注意将核心的业务逻辑与云平台接口相隔离。 云平台提供的各项功能应该被当成一个插件,系统的核心逻辑不应该绑定到具体的平台中。 一旦面向特定的平台开发系统,就容易失去的灵活性和可扩展性,也不利于后续对核心业务逻辑进行持续改进。

ECPDS 的数据获取机制也适用于我们正在建设的数据平台。 因为我们不负责数据的存储和管理,所以目前通过索引的方式提供数据访问接口。 ECPDS 支持多种接入方式,同时也开发了自己的缓存机制,这些方面都可以在数据平台中进行尝试。

从目前的发展趋势来看,核心业务逻辑,即算法,才是最适合研究的方向,还是不要过多涉及底层架构等方面。只要系统够灵活,就可以部署在各种各样的环境中。

参考

查看原文请访问:

https://www.ecmwf.int/en/newsletter/159/computing/ecmwf-production-data-store

ECMWF 产品分发时间表:

https://www.ecmwf.int/en/forecasts/documentation-and-support/data-delivery/dissemination-schedule