视界：ECMWF产品发布系统的新功能
最近部门在推动将产品后处理系统从高性能计算机迁移到气象大数据云平台，ECMWF 的这篇文章很有参考价值
声明
本文正文内容翻译自 ECMWF Newsletter Number 163 - Spring 2020 中 Matthias Zink 和 Meghan Plumridge 的文章《The new capabilities of ECMWF’s product dissemination system》，版权归原作者所有。 翻译底稿来自 Google 翻译。
正文
ECMWF 的产品分发系统每天向 ECMWF 的不同用户提供大约 240,000 个后处理文件。 分发系统的两个重要部分是“产品需求编辑器（Product Requirements Editor）”，在其中用户生成数据请求；以及“产品生成系统（Product Generation System）”，在该系统中根据这些请求定制数据。 几年前，对产品分发系统进行了一次重大审查，确定了这两个方面需要改进的关键领域，以便将来更好地为我们的会员国，合作国和其他用户提供服务。 解决这些关键问题已导致计算效率的显着提高，更可靠和强大的服务以及包括新功能在内的用户界面的改进。 它还为将产品分发系统迁移到博洛尼亚的新数据中心奠定了基础。 产品发布系统的第三个组件 ECMWF 产品数据存储（ECPDS）的改进已在较早之前实施，并在之前的 Newsletter 文章（Gougeon，2019）中进行了描述。 新产品发布系统已经实施，并得到了 ECMWF 众多员工的支持，包括用户支持，开发，产品和计算专家。
动机
促使审查的一个重要问题是可伸缩性，尤其是在查看近年来生成和分发的数据量的增长时。 图 1a 显示了过去 13 年中分发量的增长。 某些较大的增长可归因于模型分辨率的升级，例如 2013 年和 2016 年。 然而，其他一些增长只是由会员国，成员国和其他用户对数据需求的增长所驱动。 这种增长的一个原因是由于 2018 年向商业用户提供了高频产品。
High-frequency products ECMWF 的高频产品是逐小时天气预报产品，每天四次（06 UTC，12 UTC，18 UTC 00 UTC）生成前 90 小时产品。 而核心产品每天在 00 和 12 UTC 生成，每 3 小时和每 6 小时生成高分辨率预报（HRES）10天数据和集合预报（ENS）15天数据。 高频数据来自于 1991 年成立的 ECMWF 的边界条件可选计划。 该计划的主要目的是向 ECMWF 的成员国和合作国提供此类数据，以用作其有限区域模型的边界条件。 自 2018 年 10 月以来，该计划的数据已应要求提供给所有实时数据许可证持有者。
总体而言，我们可以看到 2007 年至 2019 年之间分发的数据量呈指数级增长。 这种增长预计将在未来持续：估计到 2026/27 年产生的气象数据量将达到 PB 级（图 1b ）。 分发给用户的数据量将相应增加。 如图 1b 所示，这种增长仅是基于预期模型分辨率升级的估计，而没有考虑到来自用户的数据需求可能增加或用户社区的增长。
（a）通过不同的网络（即 Internet，局域网（LAN）和区域气象数据通信网络（RMDCN）分发的数据量的发展；以及（b）由 ECMWF 的不同预报生成和分发的所有数据的预计量，假设将在 2026/27 年实施提高 ENS 预报的分辨率。
ECMWF 产品分发系统
以前的产品分发系统于 1999 年首次实施（有关详细信息，请参阅 Jokic，1999 年）。 多年来，它已经发展为向越来越多的用户提供越来越多的数值天气预报产品。 今天，它由三个主要组件构成：产品需求编辑器（Product Requirements Editor），产品生成系统（Product Generation System，pgen）和 ECMWF 的产品数据存储（Production Data Store）（图 2）。 产品需求编辑器是一个 Web 应用程序，允许用户定义其实时数据请求（product requirements）。 在每次运行“产品生成系统”之前，都必须满足这些要求。 产品生成由各个预报的进度触发，并根据产品要求定制模式输出。 然后，将根据用户需求量身定制的产品转移到 ECMWF 的产品数据存储（ECPDS），后者通过三个可用网络按照固定的时间表进行分发：区域气象数据通信网络（RMDCN），互联网和局域网（LAN） 。 目前，我们每天分发约 45 TB 的数据，其中 30 TB 推送到 ECMWF 之外，其余的存储在本地。 通过 LAN 分发的数据通常是内部对这些产品进行后处理的会员国和合作国的数据。
产品分发系统的主要任务在独立的 IT 基础架构上运行。在 ECMWF Web 服务器上启动产品需求编辑器；由工作流管理器（ecFlow 套件）和产品生成应用程序组成的产品生成系统在使用高性能文件系统的高性能计算设施上运行；ECMWF的产品数据存储（ECPDS）使用其自己的专用硬件。
产品分发系统每天运行四次（00 UTC，06 UTC，12 UTC和18 UTC）高分辨率和集合预报（HRES和ENS）；每周两次（星期一和星期四）范围更大的延伸器集合预报预报和再分析预报；每月一次进行季节性预报。 产品分发系统处于时间紧迫的路径上，以确保将产品及时交付给我们的用户。 它由 ECMWF 的运维人员密切监控，并由该系统的分析师提供 24/7 的全天候支持。 为确保弹性，该系统可在几分钟之内轻松地在 ECMWF 的两个高性能计算集群之间以及两个可操作的高性能文件系统之间进行传输（Hawkins＆Weger，2015）。 表 1 总结了 ECMWF 产品分发系统主要组件的功能以及升级原因。
表 1 产品分发系统的改进组件
| 组件 | 功能 | 升级原因 |
|---|---|---|
| 1. 产品需求编辑器 | 允许用户配置其数据需求的界面 | 开发一个全面而强大的工具来轻松配置用户需求 |
| 2. 产品生成系统软件 | 用户定制的天气预报输出后处理 | 更好的应用程序可伸缩性，更有效地使用计算资源并提高了鲁棒性 |
| 3. 产品生成系统工作流管理（ecflow 套件） | 协调 ECMWF 分发系统的组件 | 易于理解的工作流程，使 ECMWF 在时间紧迫的业务环境中尽可能快地响应 |
新的产品需求编辑器
ECMWF 实时数据的用户可以通过最近开发的产品需求编辑器（PREd）来配置和维护其产品需求，该产品需求编辑器包含 Web 界面和验证软件（图3）。 它取代了以前具有类似功能的分发需求工具。 新的产品需求编辑器已于 2020 年 2 月发布给用户。 PREd 可供 ECMWF 成员国和合作国以及国家气象水文服务（NMHS）许可证持有人和最高收费商业许可证持有人使用。
PREd 界面包括可帮助用户管理其实时数据需求的新功能，其中包括：
- 自动补全
- 产品需求模板
- 版本历史
- 当前需求和先前版本之间的比较
- 针对商业客户的发布请求
新的验证软件可确保只能将可访问的预报数据配置为实时分发，从而防止将“有缺陷的”需求反馈到产品生成系统。 验证工具根据用户类型针对多个目录检查需求。 例如，商业客户可能无法访问高频产品，而 NMHS 非商业用户可能已获得访问这些其他产品的许可。
产品需求编辑器与未来的 Web 应用程序一起，将允许用户修改其产品需求，从而简化用户和 ECMWF 数据服务团队的实时数据请求和交付流程。 这将提高在 ECMWF 的产品系统中实施修改或新产品需求的周转。
图 3，用户如何与产品需求编辑器进行交互的示意图。潜在的用户可以浏览 ECMWF 的实时产品目录。基于网络的目录展示了可分发的预报产品。用户必须先获取许可证，然后才能使用产品。约定的数据在 PREd 中配置。需求将根据可用产品进行验证，并与许可进行交叉检查。例如，并非所有用户都可以使用高频产品。产品生成系统使用产品需求来生成用户定制的数据。
新的产品生成系统
产品生成系统包含两个主要组件。 工作流程管理器（ecFlow 套件）和产品生成软件。 根据过去 20 年来使用先前系统的经验，ECMWF 从头开始重写了这两个组件。 由于产品生成系统的 I/O 密集度很高，当前的任务具有挑战性，因此需要高性能计算设备上的大量资源。 必须对产品生成系统进行彻底的重新设计以与预报交互，以便将相应的预报步骤写入 Fields Database 后立即开始生成产品（图2；有关 Fields Database 的更多详细信息，请参见 Quintino et al., 2019）。 必须在不会对预报系统的 I/O 性能产生不利影响的情况下做到这一点。
工作流管理软件的升级涉及重新设计工作流本身并重写所有脚本，这些脚本是工作流管理器和作业计划程序的一部分。 我们使用了内部新开发的基于 python 的库（PyFlow），该库可处理工作流和调度方案（ecFlow 套件）的生成以及相应任务脚本的生成。
最近几年开发了新的产品生成软件。目的是替换基于插值软件包 EMOSLIB 的上一代产品软件。 该插值库于 2019 年初在我们的生产系统中退役。其后继者是新开发的气象插值和重新网格（Meteorological Interpolation and Regridding，MIR）库（Maciel等，2017）。 新产品生成软件充分利用了这个新库的优势，并且设计得更加强大和高效。 主要性能改进通过以下方式实现：
- 在高度并行化的应用程序中引入生产者－消费者模式
- 简化了数据请求的处理，如图2所示 Maciel et al.（2017）
- 由于在专用CPU上并行执行输出文件的写入，减少了 I/O 操作的数量。
这些改进使用户量身定制的不同预报的后处理更具可扩展性和效率。 比较旧产品和新产品之间的运行时间，可以显示使用相同的计算资源来生成相同产品集所需的时间大大减少了（图4）。
核心 HRES 和 ENS 预报（00 UTC和12 UTC 预报时次）产品生成的运行时间不到旧产品生成运行时间的三分之一。 与其他所有产品（所有 HRES 和 ENS 核心产品）相比，高频 ENS 产品（00 UTC，06 UTC，12 UTC 和 18 UTC 预报时次，在图 4 中标记为 bc）在所有其他产品（所有 HRES 和 ENS 核心产品）上的改进较小。 新产品中的写入速率不同（未显示写入速率）。 ENS 高频产品的写入率大约是后者的一半。 这可能是由于对高性能文件系统的竞争需求所致：ENS 高频产品与 HRES 预报和产品生成并行生成，而核心 ENS 产品的产品生成则延迟到 HRES 预测完成。故意引入此延迟是为了避免文件系统上的负载过大，这可能会减慢所有预测和产品的生成。 但是，与旧产品生成系统相比，高频 ENS 产品的运行时间仍减半。
图 4，新旧系统之间的产品生成系统运行时间比较，显示（a）对于 00 UTC 预报的代表日（2018年12月17日）的 HRES 产品生成运行时间，（b）同一天同一时次的 ENS 产品生成运行时 ，（c）2018 年 12 月 24 天各个 HRES 预报的所有预报步骤的平均运行时间比率的分布，例如 面板 A 显示 00 时次，（d）与（c）相同，只是 ENS 预测。边界条件程序/高频数据标记为 `bc`。
图 5，从旧产品生成到新产品生成的迁移路径。
无缝迁移
新产品生成系统的重要设计准则是将用户从旧系统迁移到新系统时对用户的影响降至最低。 因此，ECMWF 在 10 个月的时间内投入了大量资源来并行运行新旧产品生成系统（图5）。 新产品生成系统已于 2018 年 7 月集成到 ECMWF 的准业务环境中，以进行内部测试和可伸缩性试验。 选定的用户将于 2018 年 11 月获得新产品的早期访问权限，以评估潜在影响。 在测试用户的积极反馈下，该系统于 2018 年 12 月全面投入运行。 通过在五个月的时间内将用户从旧系统逐步迁移到新产品生成系统，我们确保了无缝过渡到新系统。 如上所述，并行运行两个系统在技术上都具有挑战性，因为两者都占用大量 I/O。 此外，我们还通过第二个 ECPDS 实例实现了数据的并行分发，从而为用户提供了基础架构，可使用新一代产品生成系统的数据来测试其系统。 经过成功的测试和用户迁移，我们逐步淘汰了旧产品中的备份数据。 用户对新产品的顺利过渡表示赞赏。
展望
我们希望 ECMWF 升级后的分发系统将提供更可靠和强大的服务，与以前的系统相比，减少了产品发布的延迟次数。 我们将通过应用最先进的日志管理和数据分析来继续提高分发服务的质量。 这将使我们的分析师能够及早发现潜在问题并确定模式。 新工具将有助于采取积极主动的问题解决方法，并将对用户的负面影响最小化。
进一步阅读
Gougeon, L., 2019: The ECMWF Production Data Store, ECMWF Newsletter No. 159, 35–40.
Hawkins, M. & I. Weger, 2015: Supercomputing at ECMWF, ECMWF Newsletter No. 143, 32–38.
Jokić, D., 1999: ECMWF’s new data dissemination system, Seventh Workshop on Meteorological Operational Systems, ECMWF, Conference Paper.
Maciel, P., T. Quintino, U. Modigliani, P. Dando, B. Raoult, W. Deconinck, F. Rathgeber & C. Simarro, 2017: The new ECMWF interpolation package MIR, ECMWF Newsletter No. 152, 36–39.
Quintino, T., S. Smart, B. Raoult, M. Fuentes, M. Zink, S. Villaume, J. Hodkinson, A. Mueller-Quintino, A. Bonet- Cassagneau, O. Treiber & C. Weihrauch, 2019: Upgrade makes Fields Database more resilient, ECMWF Newsletter No. 160, 5.
思考
从文中看，ECMWF 仍将产品后处理系统放到 HPC 上运行，而产品分发和产品定制系统在额外的平台上实现。 我们选择另一条道路，即将产品后处理迁移到气象大数据云平台上，再将产品分发交由气象大数据云平台来实现，我们自己不再负责进行产品分发。
正如另一种趋势——即未来 HPC 不从事机器学习和人工智能等方面的任务——一样，很多时候前方的道路并不只有一条，但最终选择的方向却往往不受我们控制。
从 ECMWF Newsletter Number 163 的两篇文章看，ECMWF 未来依然会在 HPC 上进行数据处理、数据分析乃至人工智能任务，并不像我之前认为的那样。 未来数据分析会在哪里进行，可能主要取决于海量的数据存放在什么位置。
不过，这不是我应该思考的内容，从顶向下推行的集约化思想和气象大数据平台已经预示未来的数据分析任务一定不会在现有的业务平台上进行。 类似产品分发、工作流管理等可以进一步研究的组件已包含在气象大数据平台中，未来的工作方向就变得不太明朗。
可能有两种选择：
第一种是最明显的选项，研究气象大数据云平台的各项组件，并基于气象大数据云平台提供的各项功能重构产品后处理系统。 这也是目前和后续的工程项目要进行的任务。正如领导说的，我们应该拥抱变化，不能将自己局限在 HPC 上的现有业务框架。 我很赞同这句话，但却很犹豫是否投入精力研究气象大数据云平台。 定位过于细节的平台往往缺乏通用性，而开源软件的广泛流行正好说明 IT 从业人员更喜欢通用的工具。 即便从气象大数据云平台中能学到不少新东西，我们也很可能从 HPC 的坑跳到另一个坑当中。
第二种是一些尚未明确的想法，既然将产品后处理系统迁移到大数据云平台是既定路线，那么就将精力转向系统本身的核心业务逻辑。 从面向平台开发系统，转而面向业务开发系统。无论平台如何切换，核心业务逻辑基本保持不变。 如果开发的系统为了适应某个平台而变动业务逻辑，那么开发的系统就缺乏通用性，和现有的系统也没有太多的区别，只是重复劳动而已。 当然，我也在摸索当中，未来可能会有所改变。
总之，变化肯定是需要的。
参考
原文链接
