论文阅读：ECMWF软件战略和路线图2023-2027

Software Strategy and Roadmap 2023–2027

Tiago Quintino, Umberto Modigliani, Florian Pappenberger, Sylvie Lamy-Thépaut, Simon Smart, James Hawkes, Iain Russell, Laurent Gougeon, Cristiano Zanna, Baudouin Raoult, 2023. Software Strategy and Roadmap 2023-2027[R/OL]//Technical Memorandum. ECMWF. DOI:10.21957/c6d7df0322.

https://www.ecmwf.int/en/elibrary/81334-software-strategy-and-roadmap-2023-2027

本文是 ECMWF 技术文档 904，发表于 2023 年 1 月。

注：以下内容使用 ChatGPT 和文心一言翻译自论文，并根据笔者个人理解有所删改整合。 经笔者试用，ChatGPT 倾向于按照英文原始表述翻译中文，文心一言更倾向于按照中文习惯调整语序，风格迥异，可以结合使用。

以下名为“译注”的章节均为笔者添加，阐述笔者对某章节的个人理解。

摘要

ECMWF开发了多个软件包以支持其主要目标，即发展中期天气预报能力，向成员国提供中期天气预报，以及与此目标一致的其他目标。 这一战略支持《ECMWF Strategy 2021-2030》，尤其是旨在开发并应用尖端科学和技术的科学技术目标，以及旨在为 ECMWF 成员国提供卓越的性价比的影响目标。 因此，许多软件包也被成员国、合作国以及其他用户用于处理和分析 ECMWF 归档或分发数据。 这些软件包经过多年甚至几十年的开发，持续为 ECMWF 业务提供可靠服务。

作为我们不断追求效率和改进的一部分，ECMWF 正在审查其软件包的战略和路线图。 支撑 ECMWF 软件战略的一般原则如下：

• 高效使用开发资源 (Efficeint use of development resources)。 我们的目标是在现有的开发资源基础上，继续支持当前服务，并在广度和深度上提供持续增长的能力。 为了实现这一目标，我们需要合理化和高效化所有开发活动，并尽量减少软件维护工作。 这将通过现代化、降低技术债务以及整合功能来实现，从而降低维护成本。

• 软件可重用性 (Software resuability)。 为了整合开发工作，我们将常见功能合并为具有明确定义接口的可重用组件，鼓励在从高性能计算负载到交互式终端用户会话的各种环境中使用。

• 软件组件化和集成 (Software componentisation and integration)。 为了增强可重用性，现有的软件将被重构为更小的功能单元。 我们的目标是使这些组件更小、更容易复用，并更容易相互集成。 我们还意识到，我们的一些软件与 Python 集成不良，而 Python 是用户和整个社区常用的环境。 我们希望将这些组件更好地与 Python 集成。

• 进一步使用外部软件 (Future use of external software)。 我们的目标是平衡我们自己开发对实现 ECMWF 核心任务至关重要的领域特定软件与使用维护良好且得到支持的社区软件之间的关系。 这将借助社区互动来进一步加强我们的开发，同时使我们能够专注于核心任务。

• 采用开放式开发 (Adoption of open development)。 我们认为，通过与社区的互动和反馈进行公开开发的软件会带来更高的质量。 我们的经验表明成本效益非常有利，可以加强与成员国和合作国的互动。

• 数据可扩展性 (Data scalability)。 这一软件战略的驱动因素之一是在处理数据的可扩展性方面所需的改进，因为随着分辨率和新科学变量的增加，预报数据集的增长呈现超过四次方的趋势。 我们的目标是重构我们的软件栈，以改进其在工作流特定阶段中对数据的使用，从而最小化昂贵的数据访问操作，如网络或 I/O 操作； 并在可能的情况下提供软件工具和服务，以支持在数据所在的地方进行操作，即更加以数据为中心的工作流 (data-centric workflow)。

• 现代化对接新标准以实现更高互操作性 (Modernisation to new standards for higher interoperability)。 多年来，一些新的标准已经出现，特别是在 Web 技术领域，这些标准在我们数据中心内部和外部系统之间带来了更高水平的互操作性。 增强的互操作性改善了访问 ECMWF 数据的方式，并与诸如转向开放数据和采用 FAIR 原则的努力密切相关。

简明摘要

本文概述了 ECMWF 在软件方面的组织方法 (软件战略)，以及实现这一方法的短期和长期解决方案 (软件路线图)。 我们计划改进 ECMWF 独立软件组件集合的一部分，这些组件共同支持 ECMWF 的预报系统，特别是数据处理、后处理和向用户提供服务。 我们提出了支撑软件战略的一般原则，以及一个涵盖十个干预领域的路线图，其中包括四个影响许多业务系统的横向领域。 与 IFS 开发、检验和诊断相关的软件不在本文的讨论范围内，尽管它们确实使用了本文中所描述的软件。

1. 软件战略

译注：省略与摘要相同部分

1.1 资源

我们软件战略的一般原则旨在通过寻求组件重用的协同效应、使用开源软件以及与成员国和合作国增强合作，以提高资源的有效利用。

在过去十年里，ECMWF 的软件开发受益于与战略相关交付物的外部资金支持。 如今，只有三分之一的开发资源由成员国和合作国的资金支持，而三分之二来自各种外部资金来源，如哥白尼计划 (Copernicus)、Destination Earth、其他欧盟研究项目和其他国家资金来源。 无论资金来源如何，本文件提供了一个统一的软件战略，因为这些计划推动了对 ECMWF 核心任务做出直接贡献并受益的开发。

ECMWF 将继续以类似的方式寻求资源，同时加强与成员国和合作国的合作，或与依靠 Atos HPC 合同创建的卓越中心合作；同时在经济和技术可行的情况下依靠外包活动。

译注：请访问《译注 1.1》

1.2 创新

通过前述渠道 (如哥白尼计划、Destination Earth或欧盟研究计划) 寻求合作的一个关键动机是推动我们软件的创新。 这些合作与 ECMWF 的核心任务相协调，帮助我们为更高分辨率预报、利用新技术或探索新发展途径做好准备。 这些项目还使我们能够与欧洲各地的各种合作伙伴密切合作，使我们了解前沿研究的最新动态。

欧盟的研究计划为我们提供了与最先进的 I/O 硬件合作的机会和为 FDB (Fields Data Base) 开发新型数据存储后端的机会，提高了我们对新硬件的准备就绪程度。 其他研究计划使我们得以开发数据立方体 (data-cube) 特征提取的新算法 (Polytope)，这将改善我们的数据访问，尤其是随着预报分辨率的增加。

本文所涵盖的重要开发领域与这些计划具有强烈的协同效应，例如从 CADS 到 ecCharts 的 Web 框架组件的重复使用，或在 IFS 中重复使用为 DestinE Digital Twins 开发的 MultIO。

ECMWF 的创新平台 (ECMWF’s Innovation Platform) 是我们创新战略的另一个关键组成部分，其目标是提供一个平台，以促进合作和知识共享，并提供必要的数据、软件和计算基础设施来尝试新的创意。 目前，创新平台专注于创建工具，以便在中心的数据上开发人工智能/机器学习模型。

此外，ECMWF 还开展了 Code for Earth 创新计划。 每年夏季，最多有十个外部开发团队与 ECMWF 和 Copernicus 的经验丰富的导师一起合作，开展与软件开发、Web 开发、机器学习或应用数据科学相关的开源项目。

Code for Earth 的目标是推动地球科学社区的创新和开源开发。 ECMWF 还主办以特定主题为目标的编程马拉松，比如 “Hackathon 2022: Visualising Meteorological Data”，这些活动从更广泛的社区中带来了新鲜的想法，不仅限于开发人员。

我们提高软件可重用性和软件组件化的策略使我们能够更灵活地探索新的发展途径，并将新颖的解决方案集成到我们的软件栈中。

1.3 开放开发

多年来，ECMWF 一直对所有非 IFS 软件采取开源政策，并且还将其许多开源软件放在 GitHub 上供大家使用。 然而，在大多数情况下，我们的开发人员主要与内部 BitBucket 服务器上的代码进行交互，GitHub 上的副本供外部用户使用和贡献。 在大部分情况下，持续集成 (CI) 和持续部署 (CD)、问题处理和文档都是使用我们内部的 Atlassian 系统来处理的。

尽管我们意识到管理与外部贡献者的互动可能会带来额外的负担，但近年来经验表明，成本效益非常有利，社区往往会改进代码，而且还会加强与成员国和合作国的互动 (例如，在 odc 和 eckit 中与英国气象局以及在 Atlas 库中与法国气象局的合作)。

我们的目标是在已取得的进展基础上，进一步采用 GitHub 和其他开放平台，包括用于 CI/CD 和软件文档。 这将使 ECMWF 的软件实践与科学软件社区的大部分实践保持一致，并促进更大的合作。

译注：请访问《译注 1.3》

1.4. 安全性

软件安全性在整个开发过程中得到持续关注，并作为稳健的软件开发生命周期（software development life cycle, SDLC）的一部分来实施，其中包括针对安全性的阶段和活动。 ECMWF 遵循并采用了来自 NIST 和 OWASP 等组织的最佳实践和指南，将其纳入开发过程中，以确保软件安全性得到一贯的考虑。 在此软件战略中，我们特别关注以下几个领域：

• 代码仓库安全。 所有软件开发都版本化，并可以在我们自己的数据中心内部托管的 Git 仓库中追溯到个人作者。 随着开放开发的采用，其中一些将被迁移到基于云的企业服务，例如 GitHub，我们将实施与我们的身份验证和授权系统集成的高级安全功能，如双因素身份验证。 这提供了软件工件的完全可追溯性 (full traceability)、不可变性 (immutability) 和可重现性 (reproducibility)。

• 数据安全。 大多数进入和离开数据中心的外部数据都使用标准行业协议进行安全处理。 然而，重要的是要强调数据安全性还涵盖了在开发软件和服务过程中使用的数据，这可能是静态辅助数据（掩码、国家 shapefiles 等）或测试数据（例如，参考结果）。 这些数据的存储和提供需要得到安全保护，并确保其可追溯性。 随着数据集的增长和当前方法的过时，这个领域需要进行有计划的演进。

• 外部服务安全。 多个服务面向数据中心外部开放。 尽管我们过去在通过聘用专门第三方承包商积极扫描这些服务的安全漏洞方面进行了投资，但我们认为需要采取更多的测试和保障措施，以确保高水平的安全性。 这不仅涉及为我们的用户提供交互服务，还包括我们自动化系统的 API 端点。 这些测试最好涵盖多种技术，从渗透测试和代码扫描到社会工程学方法。

• 代码安全。 最后，安全性也归结为开发出具备安全设计的代码。 为了确保这一点，我们采用了多种方法。

  • 提交的代码总是在达到业务状态之前进行审查，要么由同行审查，要么由团队领导审查。
  • 对于开放式开发，这意味着对于外部贡献，只有在内部软件维护人员（称为门卫 Gatekeepers）进行仔细的代码审查后，才会在我们的基础设施上运行 CI/CD 工作流程。
  • 我们还将继续使用自动代码质量工具和清理程序，以确保常见的错误不太可能发生，如缓冲区溢出。
  • 我们还将定期由专门的第三方承包商进行代码扫描，以寻找可疑或标记为不安全的代码，或侵犯许可证或专利权的代码。
  • 最后，我们将投资培训开发人员，以确保在设计和实现软件和服务时，安全性是一个特别关注的问题。

译注：请访问《译注 1.4》

1.5. 软件开发原则与实践

考虑到我们以有限的资源维护着复杂和众多的系统、服务和软件包，开发人员的生产力是一个主要关注点。

ECMWF 长期以来采用派生自敏捷方法的多种技术来提高生产力。 我们意识到很少有一种方法适用于所有情况，因此我们根据每个服务和软件栈调整这些方法。 根据情况，我们使用多种敏捷技术，如代码审查、迭代 (sprints)、黑客马拉松、SCRUM 风格会议、代码重构、结对编程等。

举例来说，开发人员生产力的主要障碍之一是代码的可读性和可维护性。 行业研究表明，代码的阅读次数比编写次数多，比例从 7/1 到 200/1 不等。 我们通过将代码可读性作为代码验收的主要标准，以及鼓励团队开发，避免信息孤岛和单一作者的代码库，来提高代码的可读性。 我们通过代码审查、结对编程和展示演示会议来实现这一点。

我们的主要原则之一是高质量、面向领域开发。 这意味着我们依赖于专注我们的领域，开发出针对 ECMWF 任务和支持成员国的高度优化的软件。

最终，我们的方法可能最好地可以用 精益软件开发 (Lean software development) 原则5来描述开发过程，通过一个适应的 DevOps 方法与生产环境相结合。

译注：请访问《译注 1.5》

2. 软件路线图

在本节中，我们提供了未来五年的软件路线图，详细说明了采取何种行动计划来调整我们的软件栈，以应对未来的挑战，符合软件战略。

ECMWF 运行着涉及多个软件包的多个工作流。 其中一些工作流是业务和时间关键 (time-critical) 的；另一些是业务但不是时间关键的；有些是研究导向的；还有一些是与外部实体（如国家气象服务 NMS）共享的。 为了便于描述和界定路线图，我们将以业务时间关键的工作流作为示例，但该路线图适用于所有这些工作流中的软件。 图 1 说明了 ECMWF 的时间关键工作流，从将观测数据采集到数据中心，一直到分发预报产品。 观测数据由 ecPDS 服务从全球多个数据源采集，然后传递给 SAPP 系统进行处理和准备，最终转换为可供模式使用的 ODB 格式。 在这里，IFS 指的是构成地球系统模式和数据同化系统的所有组件的总体，它将同化这些观测并生成预报输出，将输出的处理委托给 MultIO 组件。 MultIO 可能会进行进一步处理，最终将数据编码为 GRIB 格式，然后将其存储在 FDB 中。 从 FDB 那里，在生成要素场后的几分钟内，PGen 系统将获取这些要素场，为成员国和合作国的 NMS 以及其他有许可的用户生成用户自定义产品。 在 PGen 同时，Post-Processing 也会从模型输出中计算派生产品，并将其存储在 FDB 中。

图 1 用于生成业务天气预报的通用 ECMWF 工作流和数据流。根据原图重新绘制

所有产品都由 ecPDS 分发给 NMS 和其他有许可的用户。 预报输出还将被归档到 MARS 系统中，一些非结构化数据被归档到 ECFS 系统中。 这两个系统随后由我们的用户和研究人员使用，以访问最终变为离线的数据。 Web 服务（例如 ecCharts、WebMars 等）也用于为预报员和用户提供方便、交互式的方式从数据中心内部或外部来访问我们的预报产品。

在第 11 节描述的策略将被应用于整个软件栈，将影响 ECMWF 的许多系统和服务。 以一个例子来说明，像 GRIB 数据编码/解码器（ecCodes）这样的单个组件，被用在 IFS 模式中（通过 Fortran 接口），在 MARS 归档中（C/C++），在 Web 栈中，被用在欧洲天气云上的 Notebook 中（Python），最终被提供给我们的 NMS 务用于处理分发的数据（作为库和命令行工具）。 我们软件栈中的这个组件将在未来几年内经历一系列计划中的演进，因此这些优势应该在各个方面都能感受到。

译注：请访问《译注 2》

2.1 干预领域

我们通过描述多个干预领域来呈现路线图，其中一些涉及特定应用的纵向领域，一些涉及跨越多个应用和服务的横向领域以支持它们。

下面概述了未来五年内预期的干预领域：

• 软件栈重构 (refactoring of the software statck) 是一个横向的交叉领域，与多个应用和服务互动。

• 数据编码和解码库 (data encoding and decoding libraries) 在整个软件栈中提供底层功能，用于编码和解码 ECMWF 的观测和预报数据。 这些库构成了所有 ECMWF 服务的横向支持层。

• 可视化软件 (visulisation software) 用于多个应用和服务，以熟悉的形式向用户和成员国预报员展示观测和预报数据。 这被视为支持性的横向干预领域。

• IO 服务器和即时处理管道 (IO-server and on-the-fly processing pipelines) 是一个横向领域，提供支持库，使地球系统模式能够异步处理和输出其模式输出数据，通过隐藏 I/O 并允许执行计算，从而最小化时间关键任务的运行时间。

• 数据分发和获取 (data dissemination and acquisition) 是一个纵向领域，提供位于 ECMWF 数据中心边缘的服务，管理传入观测数据的获取以及向 NMS 和用户分发预报产品。

• 观测数据预处理 (observational data pre-processsing) 是一个纵向领域，提供处理传入观测数据的服务，对其进行过滤，并在输入到数据同化系统之前确保它们具有共同的格式。

• 核心数据存储软件 (core data storage software) 是一个纵向领域，提供 ECMWF 数据资产的存储、服务和管理服务。 包括 DHS 系统中的托管和非结构化归档，以及在 HPC 设施存储中的归档。

• 后处理框架 (post-processing framework) 是一个纵向领域，提供从 ECMWF 预报中创建派生产品的时间关键应用程序，使其可用于其他服务，最终供用户使用。

• Metview 环境 (Metview environment) 为用户提供了一个交互式和批处理执行环境，用于探索、处理和可视化 ECMWF 数据。 这被视为一个纵向领域。

• Web 框架 (Web framework) 是一个纵向领域，支持 ECMWF 为多种目的服务的众多 Web 应用程序，包括数据发现和下载。

2.2 软件栈重构

现状

多年来，ECMWF 已经建立了一个深层的软件栈，其中包含多个层次，用于组织构成我们的预报产品工作流和支持用户处理预报数据的所有服务和应用程序。 如图 2 所示，该软件栈主要基于编译软件 (compiled software)，通常旨在提高性能和可扩展性，其中大部分都是我们系统的支柱。

为了确保在数据处理的前沿地位，我们引入了新的软件组件，例如 Atlas、MIR、ODC、PGen 或 FDB5，以适应更大、更密集的数据集。 其他软件包已得到积极维护，例如 Metview、Magics 和 ecFlow，以支持新功能并确保最佳用户体验。 随着软件栈的增长，正在寻求协同效应以降低软件维护成本并整合功能。 与该 编译 软件栈相关的策略分布在多个干预领域中，主要在后面的章节中描述。

与此编译栈并行生长的是基于 Python 语言的另一个软件栈。 最初主要局限于为现有 C/C++ API 提供语言绑定。 这导致了一系列与 Python 社区其他软件包很难集成的接口。 随着越来越多的系统依赖于 Python 栈，ECMWF 意识到需要更全面的方法来处理 Python 开发，即同时开发编译 C/C++ 栈 (compiled C/C++ stack) 和 Python 栈 (Python stack)，选择适合每个任务的正确语言和接口。

图 2 ECMWF 当前的编译软件栈。不包括 Python 组件、Web 服务和 ECPDS（它们的软件栈不是编译的）。一些具有多个组件的复杂系统（例如 MARS、ECFS）为了简单起见已经被合并为单个组件。(根据原图重新绘制)

动机

为了使软件栈在不同执行环境下更具有可重用性，从大规模并行 HPC 工作流到 Web 服务，从交互式用户 Jupyter 类会话到批处理数据分析，我们已经启动了一个名为 SPICE 的项目。 该项目将以全面的方式重构软件栈，使其更兼容 Python，同时寻求功能的合理化，通常这些功能被复制到专用包中以实现可重用性。 这个项目与 Metview 和新 MARS 客户端的未来组件化密切相关。 目标是创建一组具有明确定义接口的组件，可重用和可组合，可以用于构建 ECMWF 维护的更复杂的高级应用程序和服务。

在图 3 中，我们展示了未来的软件栈可能是什么样子。 这个视图以将支持 Python 语言的软件包为中心，补充了图 2 中呈现的编译栈。 这些组件中的许多将与编译软件栈进行接口，该功能通过委托到更低级别、高性能的 C/C++ 实现而获益。 这适用于 mir-python、pyfdb、pyodc、eccodes-python 等组件，它们是编译库的浅层接口。 在未来的五年里，我们计划同时重构这两个软件栈，以满足 ECMWF 应用程序和服务的需求。 诸如 CADS（以前称为 CDS）的新设计和 IFS Hub 开发等大型项目正在推动这些发展。

图 3 正在 SPICE 项目中重构的 Python 软件栈。这是一个正在进行中的工作，远未完成，未来几年可能会有所改动。绿色组件是新的。蓝色组件已经存在，由 ECMWF 开发，并将成为重构工作的一部分。橙色组件是开源的，由社区提供。根据原图重新绘制

行动计划

该行动计划的主要指导原则是开发更符合 “Pythonic” 风格的接口，以便与现有组件实现无缝集成，与现有社区软件兼容。 这些接口通常是对低级编译库的包装（例如 pybufr、pyfdb 或 mir-python）。

我们计划在软件栈中使用得到良好支持的软件包，这些软件包可以作为其他更高级气象特定功能的基础构建块。 这些软件包与其他包一起，将作为纯数值库的支持层，实现简单结构（例如 Numpy 数组或 Pandas 数据帧）上的算法。 在图 3 中由较低层次来表示。 这些软件包将是数据格式无关的，希望能够在不同的执行上下文中最大程度地重用它们。 中间层将提供结构化数据处理功能，允许与不同的数据格式集成，并利用多个社区软件包。 在这两个层次中，我们计划开发一些新组件，应用程序和服务可以依赖这些组件来实现特定功能：

• Grid Iterator（暂定名称）：一种新的底层、高效的编译库，将用作地球系统模式中使用网格的定义。 将有助于整合多年来在多个软件包中重复的代码，以及一些由此产生的不一致性。

• Data Sources（暂定名称）：一组新的库，抽象对数据的访问，独立于所需来源的位置。 目标是同时服务于访问快速存储（例如 FDB ）的 HPC 批处理型工作负载以及可能在云系统上运行的交互用户，例如在线 Jupyter 笔记本。

• FieldSet：这是对 Metview 当前存在功能的提取，用于处理要素场 (Field) 集，使用科学元数据进行操作，并提供对 ECMWF 数据用户熟悉的抽象级别。 与 Data Sources 一起使用时，许多关于数据位置和文件格式的技术细节将被透明处理。 Fieldset 旨在与 Python 社区软件很好地集成。

在图 3 的顶层，我们可以看到将使用底层插件的应用程序和服务，它们以独特的方式组合这些插件来提供服务，从水文后处理（Danu）到机器学习数据管理（CliMetLab），以及 ECMWF 软件的可靠标志，如 Metview 和 ecCharts。

里程碑

2023年：Grid Iterator、Data Sources 和 FieldSet 库首个版本发布。

2024年：所有 Python 软件包开源，并与社区开发实践集成 (采用开放式开发原则)。

2025年：广泛采用新概念，如 Data Sources 和 FieldSet，并被纳入到 Metview 和 Danu 等系统中。

相互作用

作为一项横向干预领域，这项工作支持许多其他项目，横跨所有开发活动。 它与 Web 框架重构、后处理项目开发以及稍后描述的 Metview 环境发展密切相关。

一旦这些组件具有最小可用功能，我们计划将其开源以与社区进行互动，希望最终形成一系列可以在 ECMWF 服务之外的环境中重复使用的组件。

译注：请访问《译注 2.2》

2.3 数据编解码库

提供预报数据是 ECMWF 使命的核心。 ECMWF 至关重要的任务之一是提供一种编码和解码数据的方式，以符合该数据的特性，比如 WMO 规定的格式。 在这一部分，我们将讨论提供所有关键任务数据的编码和解码的低级软件的战略。 分为两项主要工作，与两个独立的软件包相一致：

• 第一个处理网格点预报数据和 BUFR 格式观测数据的编码
• 第二个处理以 IFS 模式处理的格式（ODB格式）对观测数据进行编码

使用 ecCodes 处理 WMO GRIB/BUFR

现状

ecCodes 软件包以提供一致接口的方式处理 GRIB 和 BUFR 数据，无论使用哪种版本的 GRIB 或 BUFR。 它使用用 C 语言编写，并提供一个直接映射到其 C 接口的 Python 接口。 对于 BUFR 解码，我们还有传统的 BUFRDC 软件包，仅接受必要的维护。

动机

作为用 C 语言编写的库，ecCodes 需要大量的代码来实现基本的数据结构和操作。 由于它的代码无法在 ECMWF 的 C++ 软件包中重复使用，因此无法从这些软件包的发展中受益。 这种情况导致了软件包之间的重复代码问题，并积累了技术债务。 此外，它的 Python 接口与 C 接口紧密耦合，未充分利用 Python 带来的语言元素。

资源压力将强调淘汰难以维护的设施。 Python 2 已经两年没有更新，而像 32 位平台这样的小众架构在成本效益分析中难以证明其合理性。 减少对这些平台的支持将减少技术债务，并使开发时间更好地集中在对大多数用户最有利的主要平台上。 在原生 Windows 平台上支持 ecCodes 会产生额外的负担，需要仔细考虑和明确定义。

遗留的 BUFRDC 软件包在维护方面增加了额外的负担，我们没有足够的资源来修复其中的任何主要问题，从而使用户容易受到该软件包中任何缺陷的影响。 必须努力消除阻碍最后的用户将其 BUFR 处理迁移到 ecCodes 的任何剩余障碍。

行动计划

我们认为 ecCodes 的未来仍然会提供现有的 C 接口，但内部实现为 C++。 这将有助于删除大量代码，转而使用 C++ STL（标准模板库）提供和优化的功能。 这也将有助于更多地共享代码，并有可能更多地参与软件重构项目（SPICE），使用建议的 Grid Iterator 库而不是自己的代码。 第一步，即测试使用 C++ 编译器构建的可行性，已经完成并取得了良好的结果。

将取消对 Python 2 和 i686 等 32 位架构的支持，以删除遗留代码，并减少在难以支持的平台上花费的时间。 对原生 Windows 平台的支持将在与用户协商进行需求收集工作之后再确定。

我们将与 BUFRDC 的用户合作，确保 ecCodes 在处理 BUFR 时的功能和性能足以实现迁移。 我们还将在完全取消对 BUFRDC 的支持之前指定合理的时间表，以使 ECMWF 的业务作业要么得以迁移，要么在遗留数据源的情况下到期。

ecCodes 的 Python 接口将获得一个新的、更高层次的接口，使用户更轻松地处理磁盘和内存中的 GRIB 和 BUFR 消息。

里程碑

2023年：发布 ecCodes 的新版高层 Python 接口。

2023年：开始将 ecCodes 构建为 C++ 包，并停止对特定平台的支持。

2024年：用 SPICE 项目新的 Grid Iterator 库的调用替换 ecCodes 自己的迭代器代码。

2025年：停止对 BUFRDC 的所有支持。

相互作用

由于ecCodes是我们软件栈的基础组件，对其进行的变更将需要在整个 ECMWF 组织内进行广泛的协作。 我们还将与成员国和合作国的用户以及代表进行联系。 在将 ECMWF 的所有数据转移到 GRIB2 的项目中，ecCodes 也将发挥重要作用，涉及与 ECMWF 数据治理流程的密切互动，并与 WMO 的标准化活动相关。

使用 ODC 处理 ODB 观测

现状

ECMWF 已经用名为 odc 的新软件包替换了旧的 ODB-API 软件，以支持 ODB-2。 这带来一些显著改进，包括：

• 支持长度超过8个字符的字符串，从而支持 WIGOS 标识符
• 新的 C 和 Fortran 接口，并具有一致的错误处理
• 将数据解码到自定义内存布局中，以及从自定义内存布局编码数据

ODB-API 已经被弃用，目前不再受支持。为过渡期保留了旧的 ODB-API 接口的一个子集。

除了 odc，ECMWF 还发布了一个用于处理 ODB-2 数据的 Python 库，并与 pandas 和 numpy 进行了优雅的集成。 这有两个版本；一个是纯 Python 库 pyodc，另一个是封装库 codc，它提供完全相同的接口，但将工作下推给已编译的 odc 库以提高性能。 这些库提供了相对简洁的 API，仅支持对数据进行编码和解码，以及对 ODB-2 数据流结构的查询。

动机

我们鼓励研究人员在调查和试验观测数据集时使用 Python 接口。 用户反馈表明，odc 命令行工具和通过 MARS 接口提供的类似 SQL 的过滤功能非常有用，其缺失阻碍了人们采用 Python 接口。 尽管初衷是构建一个轻量级的编码器/解码器，但缺乏这种过滤功能阻碍了 Python 接口的进一步采用。

我们希望利用 pyodc 和 codc 来支持与外部合作伙伴进行的观测工作。 这将帮助他们开发干净而现代的软件工具，并促进新型观测数据的使用。

行动计划

我们将在 codc 模块中实现 SQL 过滤功能，同时在 ODC C API 中提供任何必要的支持代码。 我们注意到这将导致 pyodc 和 codc 呈现功能之间的分歧，因为在纯 Python 模块中实现 SQL 过滤功能并不可行。 接口将保持相同，但将鼓励 pyodc 的用户与 Numpy 和 Pandas 社区软件进行交互以进行过滤。

一旦业务管道稳定使用来自 Observation Store 的数据，我们将努力删除从 ODB-API 中保留的旧式已弃用接口。

此外，我们将构建一个基于 Python 的基础设施，用于高频非常规观测数据的摄取、质量控制和编码。

里程碑

2023年：支持 Observation Store 第一个版本的实施

2023年：通过 odc API 实现类似 SQL 的过滤功能

2025年：高频非常规观测数据的摄取、过滤、质量控制和编码的基础设施

2026年：移除已弃用的旧式 ODB-API 接口

相互作用

尽管 Observation Store 软件使用 odc，但它主要建立在 FDB 软件栈上。 配置该软件将涉及与 ECMWF 数据治理流程的密切互动。 将 Observation Store 集成到预报业务管道中，以直接将观测数据摄取到模型中，将涉及与 COPE 项目的密切互动。

iChange 和 TRIGGER European 项目将涉及到新颖非常规观测数据的获取、数据治理、编码、过滤和质量控制。 Destination Earth 计划还包括将更高分辨率的数据引入模型的工作，这将对观测数据的编码产生影响。

译注：请访问《译注 2.3》

2.4 可视化软件

现状

Magics 是 ECMWF 面向气象的可视化软件，已经开发和维护了 40 年。 它提供了一种简单而快速的方式来可视化 GRIB、BUFR 和 NetCDF 格式的数据。 它是 Metview 和 ecCharts 的图形核心，并且在 ECMWF 以及一些成员国和合作国得到广泛使用。 其 API 为用户提供了一长串参数，使他们能够定制自己的图表，但对于习惯于使用诸如matplotlib 等包的新一代 Python 科学家来说，学习起来可能有一定难度。 为了解决数据分辨率提高的挑战，需要进一步进行维护和开发。

动机

我们坚信，我们仍然需要为用户提供一个面向气象的软件包，以隐藏处理气象数据的一些复杂性，但是现在是时候审查我们提供的内容，看看它是否仍然适合目的并准备好迎接下一个挑战 - 并设想 SPICE 项目的可视化组件。

Magpye 和 bluejay 是创建这些轻量级 Python 模块的初步尝试，可以从 Pypi 轻松安装，从第一天起就提供开放文档和一系列 Jupyter 笔记本。 它们的最终目标是提供面向气象的功能，帮助用户快速查看其数据。 由于其 Pythonic/matplotlib 的方法，这两个软件包对于新用户来说学习曲线较小，只要数据实现了特定可视化所需的一些功能，就能够显示任何类型的数据。 这些机制将确保与其他 SPICE 组件之间良好且轻量级的互操作性。

在第一阶段，我们计划将所有图形功能委托给 plotly 和 matplotlib (bluejay) ，并将所有地理可视化委托给 Magics (magpye)，借助 Magics 多年来在检测显示数据的最适合样式方面所做的所有努力。 这种方法将使我们有自由来审查这一决定，并在将来使用被证明更合适的新软件包，并确保平稳过渡。

行动计划

首先，需要审查 Magics 等图形软件的需求，并准备合理化多年来积累的需求。 接下来，我们需要客观地评估进一步开发和维护 Magics 的利弊，调查使用 MIR 加速高分辨率数据可视化的可能性以及使用图形 Python 包的可能性。

与此同时，应对 magpye/bluejay 进行全面分析，确保所提供的解决方案不仅适用于下一代 CADS Toolbox，也适用于 ECMWF 的其他用户，并确保它们与其他 SPICE 组件的互操作性。 同时，我们还将重构诸如 SkinnyWMS 或 CliMetlab 等应用程序以利用它们，最大限度减少迁移和维护工作。

里程碑

2023年：设计 magpye 和 bluejay 的高级接口

2023年：评估放弃 Magics 的影响，并指定 Magics 的过渡计划

2024年：开始实施 Magics 的过渡计划

相互作用

由于 Magics 被大量用户和业务系统 (如 Metview 和 ecCharts) 使用，任何改变都应该经过慎重考虑：与用户和开发人员的互动至关重要。 为了成功，对其未来的任何决定都将与 Metview 和 ecCharts 的开发人员密切合作，并仔细规划过渡阶段。 过度阶段将具有一些具有挑战性但积极的方面，因为一些历史图形需要进行完全重写，从而减少我们的技术债务。

Magpye 和 bluejay 将是 SPICE 的两个重要组件，应该以用户为中心进行仔细设计，同时易于维护。 我们应该准备好与 matplotlib 社区的互动和贡献。

2.5 IO 服务器和即时处理管道

现状

目前，IFS 采用由法国气象局（Météo-France）实现并由 ECMWF 进一步扩展的 IO-server。 该 IO-server 使用 Fortran 编写，需要大量工作来支持 Wave 模式的输出。 由欧盟资助的 NEXTGenIO 项目为进行 Wave 模式迁移和扩展 IO-server 以支持集合预报提供了机会。 这对于 CY45R1 中集合预报的可伸缩性至关重要。 尽管当前的 IFS IO-server 性能很好，但它相当不灵活，扩展起来很费力。

ECMWF 目前使用的海洋模型（NEMO v3）采用另一种 IO-server 技术 (XIOS)，它具有用于计算时间统计和累积参数的即时处理功能。 然而，XIOS 仅支持 NetCDF 和严格基于文件的输出。 需要一种新的解决方案，以支持面向消息的协议和 GRIB 格式，以便在 FDB 和 MARS 中正确存储海洋场，实现与其余 ECMWF 工作流的协同作用，并在非常高的分辨率下实现可扩展性。

图4 新的MultIO sever 的设计应该展示不同要素场的各种即时后处理管道，并具有灵活输出到不同类型的数据存储的功能 (图片根据原文重新绘制)

动机

ECMWF 正在通过增加 IO-server 功能来扩展现有的 MultIO 软件，该功能深受当前 IFS IO-server 的高效聚合机制和 XIOS 中灵活的后处理管道的启发（参见图4）。 新的 MultIO IO-server 使用灵活的传输协议 (例如 MPI、TCP) 处理来自分布式计算节点的要素场聚合，并允许直接写入不同类型的数据存储 (包括 FDB/MARS)。 此外，MultIO IO-server 支持用户可编程的即时后处理管道，允许生成额外的要素场和产品，如时间统计，而无需从 IO 系统写回和读回 (write-and-read-back)。 这是实现处理即将到来的超高分辨率数据集的关键技术。

行动计划

MultIO IO 服务器最初将从版本 4 开始由 NEMO 海洋模式使用，目前计划在 CY49 使用。 新的 IO-server 还将用于 ECMWF 正在开发的新的 FVM 动力框架模式。 在展示其性能和灵活性后，MultIO IO-server 将被用于大气和海浪模式的输出。 这预计将是 DestinE 项目的一项贡献。

可编程管道将允许对不同类型的要素场应用不同的后处理，我们打算使用这种机制即时执行更多的后处理。 Infero 是一个专为机器学习推断模型的统一执行而开发的新软件包，目前在 IFS 中运行，并在 IFS 的内存数据上执行。 我们期望在可编程的 MultIO server 后处理管道中运行 Infero，因此可以在不影响 I/O 系统的情况下，非常有效地对全球要素场执行 ML 模型。

此外，ECMWF 将评估在 MultIO 处理管道内执行产品生成 (PGen) 工作负载的可行性，以大规模提高 I/O 效率，并有可能更早地创建产品。 在由欧盟资助的 MAESTRO 项目中已经部分展示了这一点，并取得了非常有希望的结果。 需要进一步的工作来将这个原型投入运行并进行大规模演示。

MultIO 模型还将被开发以支持多线程异步数据编码，以进一步最小化模型运行时间对输出的影响。 这将支持更好地配置 HPC 作业几何结构，以最大程度地利用现代系统上的可用物理核心和超线程。

里程碑

2023年：在 CY49 中使用 MultIO 处理 NEMO v4 输出

2025年：在 IFS 大气和海洋模式输出中使用 MultIO

2027年：部分 PGen 作为 MultIO 可编程管道的一部分即时执行

相互作用

MultIO server 活动与 IFS 和 NEMO 开发有密切的交互，特别是 MultIO 与 Atlas 库进行交互。 后处理管道将影响 PGen 软件。 还有与 ECMWF 的机器学习工作和数据压缩开发的互动机会。 通过 Destination Earth，将与其他合作伙伴和外部社群进行合作，因为 MultIO 及其即时后处理功能是数字孪生引擎 (Digital Twin Engine) 的核心部分。 MultIO 是开源的，将鼓励与所有感兴趣的各方合作，包括成员国和合作国。

2.6 数据分发和获取

现状

ECMWF 的数据分发和获取由 ECMWF Production Data Store (ECPDS) 处理。 这是一个非常成熟的软件，已经投入业务应用多年。 然而，业务环境正在发生变化。 由于 ECPDS 扩展到 Scalable Acquisition and Pre-Processing (SAPP) 系统可选计划，各个成员 国和合作伙伴打算使用 ECPDS 进行数据获取、分发和站内数据传输。 为支持成员国在该可选计划中的需求而开展的工作将推动更多的未来工作。

动机

作为与外部数据源和用户进行交互的组件，ECPDS 具有相对高水平的常规业务开发。 支持新的网络传输协议和数据端点类型是一项不断进行的工作。 这在当前云服务提供商的产品中尤为明显，因为它们的接口会定期变化。

SAPP 可选计划要求开发和部署独立的 ECPDS 发行版 - 也就是说，不需要 ECMWF 的业务基础设施即可运行。 将 ECPDS 与 ECMWF 的基础设施解耦，并使其适应成果国的需求是即将到来的大部分工作的驱动力。

ECPDS 的长期目标一直是以可伸缩的方式支持数据传输到各种位置。 随着我们的数据量不断增加，以及目的地范围扩大，我们需要提高数据传输能力和性能。

行动计划

需要进行开发工作以支持将ECPDS集成到成员现有的 IT 基础设施中。 这尤其包括监控、身份验证和计费功能。 此外，由于 ECPDS 是由一个紧密合作的开发和运行团队开发和部署的，面向外部的文档不足以支持外部运行团队，将需要大量工作。 与此同时，ECPDS 将会开源，以使外部访问和部署更加简单。

SAPP 可选计划中的成员国希望使用 ECPDS 支持多个站点之间的同步。 目前 ECPDS 不支持这一功能，但与其功能非常契合，通过连接 ECMWF 数据中心和 EuroHPC 数据中心，它也可能是支持 Destination Earth 计划的潜在有用功能。 一旦完成独立 ECPDS 与成员国基础设施的初始集成，就需要开发这一功能。

WMO 正致力于用 WMO Information System (WIS) 2.0 取代替代 Global Telecommunication System (GTS)。 这将为观测数据的获取和分发提供发布-订阅 (pub/sub) 接口。 ECMWF 已经支持由 WMO 运营的 Malawi 原型，该原型提供了来自一些非洲国家的观测数据。 但需要扩展此支持，以支持这项技术的更广泛应用。

里程碑

2023年：为成员成员国提供 ECPDS 的用户和管理员文档

2024年：ECPDS 完全集成到至少一个成员国的数据中心

2024年：ECPDS 开源

2024年：全面使用 WIS 2.0

2025年：支持数据中心之间的同步

相互作用

ECPDS 开发与其他团队有着几个正在进行的常规业务互动。 特别是，与由 Forecast Delivery Team 运行的业务之间存在紧密联系，还与涉及获取和产品生成的业务团队有关。 Copernicus Atomosphere Monitoring Service (CAMS) 还利用 ECPDS 进行观测检索，并通过数据门户向其用户分发数据。

在外部开发方面，ECPDS 开发与参与 SAPP 可选计划的成员国有着密切联系，尤其是爱尔兰和 UWC West 贡献团队的成员。

ECPDS 可能会在 iChange 和 TRIGGER 项目中用于获取新型非常规观测数据。 Destination Earth 项目涉及对新型卫星观测数据的关注，可能会使用 ECPDS 在 ECMWF 数据中心和EuroHPC 计算设施之间同步数据。

ECPDS 将受到向提供开放数据转变的影响，并参与其中。

译注

CMA 走的是另一种路线，即通过“天擎”气象大数据云平台将基础设施统一，保证软件在 CMA 内部可以无缝部署。 解决了不同项目之间的兼容性和被供应商绑架的问题，更有利于保护知识产权，但也带来了软件无法在外部推广使用的问题。 CMA 内部读者可以参考《气象软科学》2104 期的一篇文章。

2.7 观测数据预处理

现状

ECMWF 的 Scalable Acquisition and Pre-processing system (SAPP) 是数值天气预报处理链的关键和基础组件，为 IFS 业务同化提供及时的观测 BUFR 数据。

目前，大部分日常业务活动集中在将新观测引入业务中； 这包括配置数据获取 (通过 ECPDS 服务) 以及开发由 SAPP 协调的解码和处理工作流。

SAPP 可选计划 (SAPP Optional Programme, SAPP OP) 于 2019 年启动，允许多个参与的 NMS 在其本地基础设施中运行定制的 SAPP 虚拟实例。 在系统可用性和增加同化观测数量方面，以及因此而提高的预报质量方面，都报告了良好的结果。

动机

在过去几年中，BOND 迁移和 SAPP 可选计划出现了新的技术和业务要求。 已经确定了以下维护和发展的关键领域：

• 通过停用或迁移传统代码和工作流来解决技术债务，并继续对软件进行重构和与 ECMWF 基础设施的解耦，以实现更高的本地定制 (与SAPP OP相关)。
• 扩展和改进系统的虚拟/云平台配置，以实现和促进可扩展性、自动化测试以及持续开发和集成。
• 支持 WMO 驱动的发展 (迁移到 WIGOS 标识符，WIS 2.0)。
• 支持 IFS 数据处理开发 (例如，COPE) 并扩展处理的数据格式和观测范围，包括新型和更高空间/时间分辨率的数据 (DestinE)。

行动计划

多项迁移和移植活动正在计划或已经在进行中，旨在解决和减少技术债务：Python 2 到 Python 3 以及PGI 到 GNU Fortran 的代码迁移将在博洛尼亚的业务实施之前完成。

用等效的 ecCodes Fortran/Python 程序替换遗留 BUFRDC Fortran 软件的工作也正在进行中，同时正在重构用于 BUFR 处理的内部 Python 模块，以简化解码器的定制，并引入更高级别的抽象来进行解码/编码和过滤步骤。

在系统配置方面，SAPP OP 范围内开发的 SAPP docker 系统正在被整合，并将在 BOND 迁移后完成。 预计容器化解决方案以及虚拟实例配置的自动化将大大简化系统在 ECMWF 和成员国基础设施上的部署和集成。

随着 WMO Information System (WIS) 2.0 逐步取代 Global Telecommunication System (GTS)，还需要一些工作来调整 SAPP 采集阶段，以使用 WIS 目录和主题元数据代替 GTS 公告头，用于解码器路由逻辑。 还将加强监控工具，以提高对不同观测类型的 WIGOS 站点标识符采纳情况的跟踪，并在业务交换数据中报告 BUFR 模板的使用情况。

SAPP 提取阶段，用于向 IFS 资料同化 (IFS Data Assimilation) 提供数据，也将进行审查以满足 Continuous Observation Processing Environment (COPE) 项目的需求； 当前计划是在 IFS Cycle 49r1 中启用 hourly/sub-hourly 的 BUFR 提取。

最后，还将扩展接收数据的格式处理，适应更多 JSON/CSV/NetCDF 到 BUFR 工作流，以支持高分辨率数据和在不同演进项目 (例如 SAPP OP, DestinE) 的框架内要求的新型/非常规观测处理。

里程碑

2023年：SAPP docker 系统可用；在云/虚拟基础设施上进行配置

2024年：COPE extractions 投入业务运行

2024年：完成 WIS 2.0 数据采集 (通过 ECPDS-ACQ)

2025年：完成 SAPP 解码器从 BUFRDC 的迁移

相互作用

SAPP 的 BUFR 解码/编码层严重依赖于 ecCodes，并从 ECPDS 系统获取所有传入的观测数据； 因此，与新的数据格式和获取开发 (EUMETcast，WIS 2.0，观测数据治理) 保持紧密合作。 同样，与 WMO 在数据治理活动方面的互动，以及与参与观测验证和同化的内部团队和系统的互动，可以推动实现新的处理和监控功能 (COPE 项目、WIGOS 标识符处理和监控)。

译注

参见另一篇译文，ECMWF 正在使用 Matplotlib 和 Cartopy 开发地理可视化 Python 包。 无论是 NCEP 还是 ECMWF 都在逐渐放弃对编译型绘图工具包的维护，转而开发 Python 绘图工具库。

2.8 核心数据存储软件

现状

ECMWF 的一项强大之处在于其基于元数据的工作流。 数据以自描述的数据格式存储，并可以根据全局唯一标识的元数据在我们工作流的所有部分进行处理。 例如，不仅气象数据的存储和检索是由元数据驱动的，而且后处理和许多类别的自定义计算以及向用户分发产品的工作也是如此。

这方面的大部分功能由 MARS 生态系统驱动，包括 MARS 服务器 (保存 ECMWF 的长期气象归档)，FDB (一个在 HPC 中的高性能对象存储) 和 MARS 客户端。 此外，ECFS 为不是自描述的气象数据或其他位于元数据驱动工作流之外的数据提供了一个非结构化的归档。

经过长时间的开发，FDB 的第 5 版于 2019 年在 ECMWF 投入运行。

图 根据原图重新绘制

这将 FDB 与 MARS 生态系统的其余部分带来了实质性的一致性，以及对并行文件系统的性能和语义改进。 但是，FDB 还带来了很多前瞻性的灵活性，可以以不同的方式进行配置，并支持不同的后端技术。

最近的发展还集中在将 MARS 和 ECFS 软件及业务环境进行融合。 在 2019 年，这两项服务之间没有任何共同之处，现在它们共享部署和管理环境以及大部分代码库。

动机

数据处理是 ECMWF 业务系统的基石，为我们在 HPC 上提供领先的性能和可扩展性 (通过FDB)，在整个工作流中提供了一致和语义化的数据访问，并将我们的长期气象存档 (MARS) 集成到与当前数据相同的数据生态系统中。 但是数据和存储环境不断变化，我们需要解决以下几个驱动因素以支持 ECMWF 的战略：

1. 分辨率和数据多样性的增加不断推动数据量的增加
2. 存储环境变得更加异构，我们希望能够利用市场上的新技术
3. HPC 和云系统逐渐融合，我们希望能够支持并在云端使用我们的数据
4. 开放数据变得越来越重要，伴随着更高的数据访问量以及不同的访问模式和语义

除了这些推动因素之外，我们希望增加 FDB 支持的配置的灵活性，这将促使对 FDB 软件新后端的开发。 我们还希望支持更广泛的数据访问范式，特别是跨不同轴和子集模式提取数据，以及使用相同的访问技术来支持存储新型数据。

最后，在看到迄今为止的工作成果所带来的好处后，我们希望继续和扩展 MARS 和 ECFS 领域之间的融合，并继续使用更现代的组件删除并替换遗留软件组件。 这将减少长期维护和开发所需的工作量，并减少负责7x24管理和运行这些服务的运行团队的开销。

行动计划

更大的数据量将需要使用新型存储技术，包括即将推向市场的固态存储和存储级内存，以及构建在其上的高性能对象存储技术，也包括云存储范例。 我们将付出大量努力构建后端以支持和评估各种硬件后端。 这将为我们未来的采购提供显著的灵活性。 我们还将重构 FDB 的索引和配置，以允许同时使用多个数据后端，并支持数据在后端之间的迁移。

随着数据量的增加，使用 HPC 和其他资源在数据系统组件之间移动数据的影响变得更加显著。 我们将引入直接从 FDB 到 MARS 以及在 FDB 内部存储层和系统之间移动数据的用法。 我们还将实施一个 Volume FDB，用于在 HPC 之外的非磁带存储上存储大量研发数据，并避免不必要的研发数据传输和归档，尤其是对于寿命较短的研发数据。

目前，ECMWF 的工作流主要由单个用户驱动，并且权限和访问模型被委托给 POSIX 文件系统。 为了支持非 POSIX 后端以及在云和更多样化的用户环境中使用 FDB，FDB 将需要支持显式用户身份验证和授权。 这可能涉及重新设计远程 FDB 协议，并可能涉及用于索引和数据存储的轻量 FDB 微服务层。

由模式分辨率增加带来的大规模增长的数据量将推动以低分辨率提供更多数据的需求。 开放数据战略结合来自 European Weather Cloud 的访问将带来非常不同的访问模式，即在不同轴上切割数据。 我们将扩展 FDB 生态系统，使其能够存储低分辨率或重新网格化 (re-gridded) 的数据副本，以支持资源高效访问。 借助于 EU 研究项目（Polytope）中的开发，我们还将构建对数据的切片和几何定义子集的直接访问支持。

我们的目标是利用所需的性能改进和新功能提供的机会，减少软件栈中的重复，同时删除遗留代码。 MARS、FDB 和 ECFS 最初是完全独立的代码库，正在进行持续的融合。 我们预计将在我们的软件栈中标准化 MARS 语言处理，并用 MARS 中的服务器机制替换 ECFS 中的大部分机制。 新的 Observation Store (请参见上面的 Observation Handling) 使用了 FDB 技术。

MARS 和 ECFS 客户端现在是老旧的软件。 我们将通过使用现代语言和范例 (重新) 实现 MARS 和 ECFS 客户端来，减少我们的长期维护开销。 这将提供一种基于 Python 的编程接口，以改进它们与我们工作流的集成。 通过在 FDB、MARS 服务和新客户端之间重复使用经过测试的软件组件，将提高稳健性并降低开发开销。 替换客户端-服务器通信协议 (目前基于 FTP 协议) 为 MARS 中使用的协议还将在 ECFS 处理大数据传输时带来显著的性能和语义改进。

里程碑

2023年: 实施Volume FDB，以及用于研究模式的 Observation Store

2023年: 为 FDB 开发 DAOS 和 MOTR 后端

2024年: 每个数据库支持多个后端，FDB 中实现显式用户和权限管理

2024年: 新 MARS 和 ECFS 客户端的第一个版本

2025年: 在 FDB 中支持特征提取

2025年: 直接传输 (FDB 到 FDB，MARS 到 MARS 和 FDB 到 MARS)

相互作用

核心数据存储软件构建了连接 ECMWF 许多团队和活动的管道。 这些软件包的开发工作涉及与这些不同团队的的合作和和平衡他们的需求。

我们核心数据存储软件的发展支撑着 ECMWF 对外项目的许多目标和进展。 ACROSS 和 IO-SEA 项目直接涉及 FDB 的工作，以支持新型存储后端和数据流。 Destination Earth 项目将 FDB 软件的重大开发工作，并将 FDB 和 Observation Store 部署到新的上下文中，存储新型数据。 我们还预计与 German Climate Computing Cener (DKRZ)、瑞士气象局（MeteoSuisse）和 CSCS 等合作伙伴进行合作，以支持 FDB 和基于元数据的工作流。

2.9 后处理框架

现状

ECMWF 内部有多项活动依赖于在 IFS 下游运行的时间关键 (time-critical) 后处理套件。 这些套件通常与 PGen (Production Generation software) 不兼容，因为它们不是将一个要素场生成多个产品 (1-field-to-many-products)，而是在许多要素场上执行统计或气候学计算 (例如，产品聚类、尾部偏移 (shift-of-tails)、极端预报指数)。 这些套件是中心内部独立开发的，许多套件存在可扩展性问题，这将阻碍按计划计划拓展到 9 公里分辨率集合预报。

动机

我们的目标是开发一个后处理套件的框架，将后处理功能整合到一个单一的环境中，将现代和可扩展的计算机科学技术与最佳科学实践相结合。 这将带来更高的性能、更大的可扩展性和改进的 I/O 效率。 一旦建立了这个框架，我们预计该框架的维护性和可移植性将大大提高。 例如，将能够在后处理业务模式输出和研发试验输出之间重复使用相同的整合程序 (而今天只能通过费力的特定程序来实现)。

行动计划

第一个目标是将用于这些套件的各种工具移植到先前引入的重构软件栈中，即由 SPICE 项目开发的协调一致的 Python 生态系统。 这将提高工具的稳健性，确保在整个过程中使用相同的方法和算法，并提高它们的可维护性。 在许多情况下，这已经可以改善这些工具的性能和可扩展性。

第二个目标是通过在共同的 Pyflow 框架下对这些套件进行重构，协调这些套件的执行。 这将提高这些套件的业务管理效率，同时还可以在研发试验中简单执行 (包括通过 IFSHub)。 它还将为关键套件引入并行性，使其准备好在 CY48R1 扩展到 9 公里集合预报。

有了这个后处理框架，我们将处于一个强有力的位置去探索更有效地执行这些套件，无论是通过优化 I/O 还是通过利用分布式并行计算框架。 这将使这些套件能够扩展到超过 PiB 规模的预报。

里程碑

2023年：使用后处理框架为 9 公里集合预报移植时间关键、不可扩展的后处理套件，展示其有效性

2025年：在整个中心推动并标准化后处理套件的开发

2025年：通过引入稳健且可扩展的并行执行框架增强后处理框架

相互作用

将会在 ECMWF 内展开强有力的合作，多个团队将向该框架贡献科学功能。 套件重构将依赖并有助于开发 SPICE 项目的 Python 组件。 这项工作还将补充 IFSHub，允许在研发试验中执行套件。

2.10 Metview 环境

现状

Metview 是 ECMWF 面向用户的软件包，为访问、处理和可视化数据提供了一个单一的环境。 它包括图形用户界面 (GUI)、Python 接口和自己的宏编程语言。 在其 30 年的发展过程中，Metview 积累了大量用于处理模式和观测数据的代码。 虽然其最初的设计充分利用了当时可用的库 (例如，具有要素场集处理和面向服务架构的 MARS 客户端)，但随后许多新库逐渐发展，有时需要复制 Metview 的一些功能，同时保持独立。 这种代码的重复导致技术债务，不同的实现可能会导致软件包在相同计算的情况下产生略有不同的结果。 Metview 目前依赖的大多数当前软件栈都是硬编码为使用双精度浮点数组，这使得对高分辨率数据 (例如 1km) 的处理在内存使用方面非常昂贵。 Metview 的可视化功能来自 Magics 库，二者的代码耦合度很高。

动机

随着我们重构软件栈，有机会对 Metview 的情况进行合理化处理，通过将 Metview 的代码和算法贡献给新的软件组件，以供 Metview 和其他软件包使用。 例如，许多热力学函数已经被贡献给 meteokit，一旦软件重构项目开始，可以删除 Metview 用于这些计算的代码，而 Metview (和其他软件包) 可以依赖于贡献给 meteokit 的函数。 对于即将推出的软件栈中的其他组件，情况也是如此。 Metview 将继续为用户提供与数据交互的高级方式，包括其 GUI 和在 Jupyter 笔记本中改进的工作方式。

随着即将推出的新 MARS 客户端，必须对 Metview 的大部分代码进行重构以采用它，同时保留其现有功能。 这将是减少 Metview 代码量并增加一致性的机会。

随着数据量的增加，Metview 处理这些数据的能力也必须提高。 我们已经看到来自研发的 1 公里网格，甚至集合预报的分辨率增加也可能对数据处理产生影响。 Metview 必须能够继续在现有硬件上有效地处理和可视化这些要素场。

Metview 目前与 Magics 的紧密耦合对两个软件包的打包方式施加了一些限制，导致额外的维护工作。 更松散的耦合将减少总体维护工作，使两个软件包能够更独立地发展。

随着 Metview 的 Python 接口由于其更强的表达能力和灵活性而变得越来越广泛使用，原始的 Macro 语言将变得过时，同时支持两者将造成工作重复。 Python 生态系统将是未来的方向，特别是在 SPICE 项目组件可以提供的功能背景下。 我们将首先冻结 Macro 语言的开发，随后逐步停用。 Metview 越来越多地被使用的一个相对较新的环境是 Jupyter 笔记本。 在这个环境中，通常无法使用 Metview 的 GUI，因此需要新的组件来允许在笔记本内部查看数据。

行动计划

我们将利用 SPICE 项目提供的机会，(i) 将 Metview 的代码和算法贡献给可以在其他地方使用的新软件组件，以及 (ii) 在这个更现代的软件栈上重新构建 Metview。

另一项重构将涉及用新的基于 C++ 的客户端替换现有基于 C 的 MARS 客户端，作为 Metview 与 MARS 归档和基于 GRIB 基本计算的 C++ 接口。 这将使 Metview 的二进制组件成为一个经过充分测试的软件栈的一部分。

进一步的工作将致力于提高 Metview 在 Jupyter 笔记本环境中的可用性，特别是交互式数据查看和绘图部件。

Magics 绘图库包含了大量仅在 Metview 的交互式绘图窗口中使用的代码。 通过从 Magics 中提取这些代码并将其作为 Metview 的一部分，将减轻 Magics 的维护和打包工作，并将使 Metview 在实现上变得更加灵活。

在未来几年的分阶段过程中，我们将逐步淘汰并最终删除 Metview 中的 Macro 语言，首先冻结新功能的开发。 我们将探索可能帮助用户将其脚本迁移到 Python 的选项。

我们将通过识别和解决瓶颈问题来确保 Metview 及其所有组件能够处理未来模式升级中设想的大数据量。 其中一个组成部分是确保所有软件包可以按要求使用单精度浮点数组，从而将内存使用量减半。

里程碑

2023年：冻结 Metview 的 Macro 语言的开发

2024年：重构 Metview 以使用新的 MARS 客户端代码

2024年：增强 Metview 小部件，以提高与笔记本环境的互操作性

2024年：开发 Metview 所需的 SPICE 组件

2025年：重构 Metview 以使用新的 SPICE 组件并减少对 Magics 的强依赖

2027年：从 Metview 安装中移除 Macro 语言

相互作用

这些计划中的重要利益相关者包括所有 Metview 的用户，其中包括成员国和合作国的用户。 减少内存消耗的工作将需要与 DestinE 项目进行互动。

译注

Python 生态环境更多使用基于 Jupyter Notebook 的交互式分析。 相对于桌面客户端软件，Jupyter 类环境更容易部署和使用。

译者所在团队也正在申请内部课题开展类似研发工作，尝试利用 JupyterHub 为模式研发用户提供对研发试验的在线数据分析环境。

2.11 Web 框架

现状

ECMWF 和 Copernicus 为其用户提供许多 Web 应用程序，例如 Opencharts/ecCharts、WebMARS (用于ECMWF) 以及 Copernicus 的 EFAS、CDS 和 ADS。 目前，尽管它们大多数都共享相同的一般原则和技术，但它们仍然各自独立地进行维护和开发。 这种情况在最近几年中逐渐演变，因为 Web 成为与 ECMWF 服务进行交互的更自然方式。 现在是时候在应用程序之间寻找协同作用，并在可重用的组件中整合通用功能。

动机

我们计划充分利用 Web 团队在开发这些业务应用程序方面积累的经验，开始致力于组件的可重用性、服务的互操作性和共享技术。

我们将确定可重用的组件，以便更有效地应对未来挑战，如提高集合预报分辨率。

我们将高度重视互操作性，因为这将在项目 (例如 IFSHub 或 CADS) 中发挥重要作用。 在写着项目中，用户能够从一个友好的环境中交互并连接他们日常工作所需的多个服务。 与 WEkEO 等外部系统的改进互操作性将促进交互和交流。

最后，通过共享基于共享技术构建的组件，我们将受益于一个巩固的基础设施和软件。 这将通过提高可见性来简化业务监控和问题解决，并扩展我们的知识库。

图5 Web框架架构图：4 类网络服务，使用大量文档齐全的 API，这些服务依赖于一个重新设计的核心基础设施，以使用和促进 SPICE。根据原图重新绘制

行动计划

第一步是审查我们已经提供的网络服务 (面向用户和内部服务)，并使用 OpenAPI 标准明确记录它们的 API。 我们应该充分利用现有的标准工具：它们提供方便的方法来通过 OpenAPI 呈现 API 文档和功能。 完成后，我们将能够根据需要逐个重构它们，并利用其中一些创建更复杂的应用程序，例如 IFSHub。

在这个阶段，我们还将借此机会审查代码和 Git 存储库，以识别可重用的组件，这些组件可以很好地打包并成为集成到 SPICE 项目中的候选组件。

这项工作以及充分文档化并被社区接受的广泛使用的开源解决方案将帮助我们在不同的活动领域之间实现更好的互操作性。

另一个需要尽早考虑的重要方面是提高集合预报分辨率对我们按需服务 (ecCharts/opencharts) 的影响，以及在长期内进一步提高数据分辨率的影响。

网络服务面临许多挑战；重要的是找到一种共同的方法来解决复杂的问题，如缓存、存储和身份验证，并通过迁移到 GitHub Enterprise 和 GitHub Actions 来改进我们对 CI/CD 的使用。

我们有一些新的项目正在进行中：提高 ECMWF 数据的可发现性，开发下一代 CADS 工具箱，创建研发人员实现日常工作的下一代环境。 如果我们希望为用户提供愉悦而一致的 Web 体验，那么利用以往的经验和设计是十分重要的。

里程碑

2023年：审查 Web 组件，重构 WebMars 和 Data Layers

2023年：将 IFSHub 设计为一个灵活的平台，支持将研发人员在日常工作中所需的组件作为插件接入

2024年：启动 CADS (由 Copernicus 资助)

2024年：IFSHub 的第一个版本

2025年：IFSHub 业务运行

2026年：支持高分辨率数据的新版 ecCharts

相互作用

Web 应用程序的成功在于与潜在用户密切合作，以满足其期望。 接下来的 5 年将推出几个全新的系统：CADS，IFSHub 和 SPICE，这些系统将需要强有力的互动和沟通。

CADS 作为 CDS 的新一代将需要满足一个成熟社区的要求。

IFSHub 将需要一个坚实的设计，其挑战是为研发人员创建一个直观的平台，该平台应足够通用和灵活，以便轻松集成新组件并实现它们之间的互操作性。

3 总结

这个软件战略和随后的实施路线图在整体上相辅相成。 每个干预领域的工作可能独立存在，但当所有领域都得到发展时，它们会产生协同效应。 软件栈重构 (refactoring of software stack) 领域将为软件栈提供新的组件和更新的灵活性，以支持其他领域。 Web 框架 (Web framework) 的发展将使用更多可重用组件为用户界面服务提高灵活性。 这些服务将由使用新的后处理 (post-processing) 框架创建的产品提供，该框架将从 Metview 环境 (Metview environment) 中重构的组件中提取，现在可以在 CADS 和 HPCF 等替代执行上下文中运行。 Metview 环境还将从可视化软件 (visualisation software) 即将到来的结构性变化中获益，我们肯定会新版本 CDS (CADS) 找到多个协同作用。 数据分发和获取软件 (data dissemination and acquisition software) 的发展将支持使用此系统的国家气象局 (NMS)，但也期待与核心数据存储软件 (core data storage software) 更紧密集成，涉及 IoT 观测数据获取项目。 最后，新的 IO 服务器和即时处理管道 (IO-server and on-the-fly processing pipelines) 的发展与地球系统模式紧密关联，在数据处理和编码方面与整体工作流的其余部分紧密相连，以确保整体工作流程能够应为即将到来的数据处理挑战。

该软件战略和路线图将使 ECMWF 能够更高效地支持我们的服务，同时为更大数据集带来的挑战做好准备。 这也将使 ECMWF 能够调整其软件基础设施以应对 ECMWF 2021-2030 战略要求的更广泛挑战。

3.1 里程碑汇总

由于每个干预领域都定义了自己的里程碑，为了提供这些领域如何整合的整体视图，因此在这里收集了这些里程碑：

4 词汇表

译注：以上为原文翻译，以下内容为译者添加

参考

技术报告：Software Strategy and Roadmap 2023-2027

新闻：ECMWF publishes new Software Strategy，2023.01.31

网站：The ECMWF Software Strategy