视界：扩大ECMWF数据的使用范围
Widening the reach of ECMWF’s data
17 January 2022
https://www.ecmwf.int/en/about/media-centre/news/2022/widening-reach-ecmwfs-data
原文发表于 ECMWF 网站新闻《Widening the reach of ECMWF’s data》，介绍 Web 开发团队负责人 Sylvie Lamy-Thépaut 在 ECMWF 的工作。
以下正文章节是对该新闻的翻译，并根据笔者个人理解有所删改，如有偏差敬请谅解。
正文
ECMWF 的使命是将数据提供给更多人。
Sylvie Lamy-Thépaut 将气象专业知识与计算机专业知识相结合来实现这一目标。
个人经历
在 1980 年代学习气象学后，她担任了一年的预报员。 但她对通过图形计算机上的可视化技术让预报员访问预报数据更感兴趣，这是一种当时刚刚兴起的技术。
她在 Météo-France 工作期间获得了计算机科学硕士学位，并在 ECMWF 工作了一段时间，帮助为其研究人员开发第一个版本的交互式工作站，称为 Metview。
自 2002 年以来，Sylvie 直接为 ECMWF 工作，包括 Metview 和气象绘图软件 Magics。 作为 Web 开发团队的负责人，自 2012 年以来，她逐渐将 ECMWF 的数据开放给更广泛的受众，并在此过程中对 ECMWF 的 Web 基础设施进行了现代化改造。
她说：“我们目前正在向任何对我们数据感兴趣的人提供实时和固定分辨率的数据子集。这一原则与我们正在努力解决的一些技术挑战有关。”
在她职业生涯的初期，Sylvie 为 Météo-France 开发了一个可视化系统。这些图显示了位于巴黎西南 Trappes 的雷达所观测到的降水量（单位为毫米/小时）
ecCharts
Sylvie 作为 Web 开发团队负责人的首要任务之一是为 ECMWF 的成员和合作国以及其他客户开发一个交互式网络应用程序，显示预报图形。 此应用程序称为 ecCharts，并使用 Magics。
“一项关键任务是让 Magics 足够快，以可靠地生成用户选择的预报图形”，Sylvie 解释说。 “挑战在于 ecCharts 每 12 小时更新一次，以原始分辨率提供最新的预报信息。这意味着需要在短时间内处理 1 TB 的数据。”
ecCharts 图像显示了预报 2022.01.11 12 UTC 的 2 m 温度和 30 m 风，这是从 2022.01.07 00 UTC 开始的预报
ecCharts 支持用户
- 查看 250 多种变量
- 缩放和平移任何感兴趣的区域
- 进行计算，例如降雪概率或阵风超过某个阈值的概率
虽然预报员通常会选择 ecCharts，但研发人员更有可能在 数据门户 中以原始格式查阅数据。 然后，他们可以将数据输入到自己的模型中，或者根据需要对其进行计算。
ecCharts 和对 ECMWF 数据库的完全访问权仅适用于成员国和合作国以及其他客户。 最近开始向开放数据迈进。
迈向开发数据
今天，ECMWF 提供了两套预报和数据：
- 面向专业用户的完整的当前预报和对归档的完全访问权限
- 面向公众的开放图表和数据
- 2020 年 10 月起提供 12 小时更新，2021 年 11 月起 6 小时更新，提供更多种类
- 内容：对 ECMWF 当前预报的访问，仅有图片形式
- 使用方式：用户可以选择全球 30 个预定义区域之一进行查看，并行查看多个产品并与之交互 (ChartSet)
- 限制：无法缩放和平移
- 目标：提高应用性能和用户体验
可用作开放图表的众多预报图表之一是降水类型预报，此处显示的是欧洲地区 1 月 6 日 09 UTC 提前 9 小时的预报
来自开放图表选择页面，现在可以并排查看相同区域和预测时间的不同预测。
开放数据：从 1 月 25 日起，更多数据将向公众开放，以固定的分辨率及时提供。
“我必须应对的挑战之一是让用户可以找到数据。我们拥有如此多的数据，用户可能很难发现我们拥有什么。”
实现上述目标的一种方法是在图表中提供 Jupyter 笔记本 的链接，笔记本包括：
- 如何访问 ECMWF 数据
- 应用了哪些处理过程
- 如何轻松地对其进行可视化
迁移到 Bologna
Sylvie 参与的另一项任务是将所有计算工作从英国雷丁迁移到 ECMWF 在意大利博洛尼亚的新高性能计算设施。
核心部分是将 Web 应用迁移到 Kubernetes 技术栈，这使得将它们部署在云基础设施上成为可能，提供所需的扩展灵活性。
“我必须问自己的关键问题是：用户可能对我们的预报有什么期望，以及我如何向他们提供所需的信息以帮助他们？答案决定了需要做些什么来改善所有用户的体验。”
讨论
读完这篇新闻稿，除了敬佩科学家持之以恒的专业精神，也联想到了目前正在讨论中的两个方向：数据门户和绘图门户。 我在之前翻译的很多新闻稿和论文中多次提到，缺少基础平台与多方面因素有关。 其中之一就是发展方向，最核心的任务是发展数值预报模式系统本身，而不是对外提供产品服务或支撑技术。 下面就简要讨论下数据和绘图平台，最后谈下与平台相关的基础设施。
数据门户
去年年终总结中同事提出要对数据进行梳理，编写数据字典，也就是进行 数据治理 工作。 数据字典也包含文档管理这个非常值得讨论的问题，这里仅关心数据门户问题。
即便是目前整理最规范的业务模式 GRIB 2 产品数据，也缺乏容易访问、详细易用的文件说明。 其他格式数据几乎找不到文档说明，仅能从文件本身推测内容或者直接咨询专业人士。 而 NCEP 和 ECMWF 的 GRIB 2 文件说明都可以在网站上公开访问到：
内部数据缺乏有效的整合，不仅是没有明确数据管理职责落实的问题，也更多与合作开发的模式有关系。 当工作边界有明确的划分时，虽然能降低管理成本，但很容易形成环绕在边界上的高墙，提高跨界的难度。 数据门户需要打破领域界限，克服诸多阻力，集众智形成单一成果。 CMA 已通过 CMADaaS 进行数据治理工作，而单位内部也应该开展类似的工作。 即便当前无法直接对外提供服务，数据门户也能为内部的研发工作提供支撑。
梳理数据仅是数据门户的起点，构建完整的数据平台还需要硬件环境和软件环境的支持。 单位缺少存储设备，数据管理的技术储备还不够深厚，但这些都可以在发展过程中逐步克服，关键是在于应该坚定信念向某个目标一直前进。
今年退休的一位专家老师做报告时在“数值预报系统的健全”方面提到场库和要素库等数据库的缺失。 这里的场库指的是观测资料数据库，要素库指的是格点资料数据库。 单位在这两方面都已开展多年的研究工作，但问题在于研究成果经历多次推倒重来，没有实现推广应用，没有应用到业务系统中，也没有为模式研发工作提供有力支撑。 在制定下一步计划前首先要分析为什么会形成当前的局面，之前的方式是否存在改进空间。 只有找到问题所在，然后才能拟定合理的开发路线图，以渐进的方式逐步完善整个平台。
绘图门户
数据门户的衍生平台就是绘图门户，即数据可视化平台，而这部分是我参加工作以来非常遗憾的一部分。 我在入职前 6 年时间都在开发桌面版的诊断绘图工具，经历多种波折，在 2019 年底自行选择退出该领域，于 2020 年中项目验收后彻底退出。 在 2019 年底的博文《关于交互诊断软件开发任务的一些想法》中我已进行详细分析，认为至少我本人不适合做桌面版的诊断工具，但我仍然对可视化领域抱有一定的兴趣，期望能做出一些成果。 本节仅关注在线版本的绘图门户。
目前业务模式数据可用的绘图门户包括：
- 外网两个，均为 NMC 开发，仅使用业务系统的图片产品：
- 内网三个，均为 NMC 开发，同时使用业务系统的图片和数据产品：
其中最后一个平台正是支持动态交互的绘图门户，单位通过工程项目支持该平台的开发工作，在去年总结时着重提到。 内网最后两个在线应用均使用 NMC 开发的 MOAP 平台开发，底层使用同样的技术，仅在表现层根据不同的需求开发不同的前端界面。 这种底层使用通用框架的方式非常值得借鉴，是技术开发人员实现可持续发展、工程项目避免重复建设的有效途径。
NMC 规定三种架构的项目必须集成到三个平台中：
- 客户端-服务端架构：MICPAS
- WEB 架构：MOAP
- 微服务架构：MESIS
单位进行研发支撑工作的最大问题在于没有形成类似的集成统一开发平台，各个工程项目都使用自己的技术框架，缺乏统一规划和持续改进，导致工程项目的产出成果往往都存在各种需要通过迭代才能解决的问题，很少能得到实际应用。 虽然部分同事（包括我在内）已通过不同方式提到单位需要统一技术框架的问题，但工程项目牵涉太多领域，目前还没有统一规划的迹象。 不过我相信未来总会更好的，总会在意识到这个问题后克服重重阻力推动工程项目执行方式的变革。
Kubernetes 技术栈
K8S 技术栈非常流行，这里我不是要强调该项技术的重要程度，而是将其作为潮流技术的代表，来说明将新技术应用到工作流程中存在的困难。
前面两小节都提到单位缺乏基础支撑平台，基础平台需要拥抱潮流技术，潮流技术需要基础设施的支持。 而单位现在能使用到的基础设施几乎由 NMIC 管理，无法自行选择技术栈：
- HPC：NMIC 管理，没有管理员权限，不支持容器技术，软件环境更新受限
- 虚拟资源池：NMIC 管理，仅延续历史申请虚拟机，最近没听说单位有新申请
- 气象大数据云平台：NMIC 管理，仅作为普通用户，技术已定型，缺乏开发空间
- 物理机：已无法单独购买，单位缺乏机房，无法自建
现有数值预报业务系统的流程全部基于 HPC 平台实现，未来一定会有改变。 可行的潮流技术研发方向有两个：
- 全面拥抱气象大数据云平台：之前博文中多次提到我对该方向持保留态度，学习使用小范围内的专有技术不利于个人成长。与其研究 CMADaaS 专用技术，不如研究高性能计算技术
- 等待新一代 HPC 提供容器运行环境：无法保证新一代 HPC 提供哪些工具，如果提供容器运行时，则应该大力推进容器技术研发
总之，要从长远发展的角度出发来规划个人的技术路线，尤其要考虑到职业生涯中未来可能会出现的变化，时刻了解领域内最新的发展趋势，不能将自己绑死在内部使用的专有技术上。
