Open-Meteo 的历史天气数据 API 详解

译者注

本文是 Open-Meteo 的一篇旧文，其原文标题（翻译后）为《60年的历史天气数据现以免费API和下载形式提供》，发表时间是2022年7月19日，比之前推送的两篇讨论相同话题的文章《Open-Meteo 可提供从1940年至今的历史天气数据》（2023年3月24日）和《Open-Meteo 整合 90TB 历史天气数据》（2023年11月）（下文将这两篇推文合并简称《1940至今/90T》）的首次发表时间要早得多。本文中关于 ERA5 的内容有相当一部分与《1940至今/90T》中的相关内容有重叠，如果读者在阅读本篇之前先阅读了《1940至今/90T》并且搞错了它们在发表时间上的先后顺序，那么可能会产生互相矛盾的感觉（例如《1940至今/90T》中声称可以提供历史80年而本文描述同样的接口却仅提供60年），因此需要读者自己捋顺它们的时间线并且甄别其前后关系。

由于本篇是 Open-Meteo 在首次发布历史数据 API 时编写的，因此对于该 API 的使用方法上的介绍更为详细，此外本篇还从技术角度介绍了如何解决 ERA5 数据量巨大的问题。虽然对于历史再分析数据和 ERA5 的话题在《1940至今/90T》中已有描述，但鉴于本篇在技术和应用实践细节上具有更高的参考价值，因此补发该篇。

Open-Meteo 现在提供可追溯至1959年的历史天气数据！打开 API 文档以使用 API，或者直接下载 CSV 或 XLSX 格式的数据。

这是一段漫长的旅程。在过去的十年里，我一直在处理环境数据集。它们有一个共同点：数据量越来越大。

拥有超过 20TB 的历史天气数据，我敢说这是一个“大数据”挑战。下载、处理、压缩和编码花费了数周时间。

最终，一个快速的历史天气 API 被构建出来，我希望它能简化许多学生、学术研究人员和记者的工作，因为长时间序列的天气数据很难找到。

这篇文章包括：

• 历史天气数据的简要概述
• 历史数据来源
• Open-Meteo 新的历史天气 API 是什么
• 如何使用以及质量限制是什么
• 数据实际是如何存储并通过API提供的

历史天气数据简述

在学术领域工作时，学生们经常面临一项挑战：获取历史天气数据来深入分析他们假设。随着气候变化和更极端的天气模式，许多记者依靠测量来客观评估当前的热浪或干旱是否创下了新的记录高点还是“仅仅是天气”。

国家气象服务（NWS）通常是获取气象数据的一个良好开端，因为它们已经运营了高质量的观测站长达数十年。一些 NWS 会在开放数据服务器上提供 CSV 或科学数据格式的数据。其他 NWS 则甚至不会根据请求共享数据。

高质量的气象站根据 WMO 标准测量天气，其他一些则是最近才使用普通硬件安装的，测量结果不太可靠，维护间隔不频繁。质量、准确性和可靠性各不相同。

即使你找到了你国家的气象站数据，也很可能没有靠近你感兴趣地点的气象站，或者时间序列数据不完整或不一致。你可以通过结合多个来源的数据、填补空白、确保一致性和使用天气模型来弥补站点之间的较大距离来解决这个问题，但这样做需要时间。

许多研究人员在过去面临这些问题，并开始研究“再分析”天气数据集。原理是：

• 收集过去十年的站点测量数据
• 将它们与卫星、雷达和飞机观测相结合
• 将数据网格化为 30x30 公里的单元
• 使用天气模型来“填补空白”

因此，再分析数据集可以提供全球一致的历史天气数据，受到物理模型的约束。再分析仍然依赖于测量数据，但空白和不一致可以更容易地被纠正。

网格化温度地图和气象站标记

最有声望的再分析数据集之一是欧洲哥白尼计划与 ECMWF 合作的 ERA5，它也用于 Open-Meteo 的历史天气 API。

ECMWF ERA5

ERA5 是欧盟公共资助的哥白尼计划的第五个再分析天气数据集，由 ECMWF 实施。ERA5 作为开放数据可用，你可以从气候数据商店（CDS）下载。

它提供全球30公里分辨率和每小时值的天气数据。有数百种天气变量可用，其中一些在达到80公里高度的137个大气层上。

数据自2019年起可用，但自2022年6月起，实时数据集现从1959年至今可用，延迟5-7天。

到目前为止，ERA5 是最受认可的历史天气数据集之一，被用于许多农业、能源和保险应用。

获取 ERA5 很简单。注册一个账户，接受开放数据的许可条款，并使用 CDS 客户端 Python 库，你就可以开始下载了。然而，有一个缺点：ERA5非常庞大！

我没有找到确切的数字，但数据大小必须超过1PB（1024TB）。即使你只对少数天气变量感兴趣，如温度、降水和风，你很快就需要下载1TB或更多。对于 Open-Meteo 来说，有23个天气变量，需要从 CDS 下载超过20TB的数据。而这些数据已经压缩过了！

处理这么大量的数据很快就变成了一个计算机科学实践，对于只需要几个地点时间序列数据的研究者来说，这是一种痛苦。

新的历史天气API

“历史天气 API”已经存在。一些商业天气提供商基于天气模型或站点测量提供历史数据。大多数只在他们最昂贵的“顶级”商业提供中提供，数据来源并不完全清楚。

为了弥补商业提供和花费数周下载 ERA5 之间的差距，Open-Meteo 现在提供一个免费的（非商业用途）ERA5 API。

新的历史天气 API 的工作方式完全像 Open-Meteo 预报 API，但你需要指定开始和结束日期。你可以直接选择从1959年1月1日到现在的完整时间间隔。

Open-Meteo历史天气API配置器

获取数据可能需要一段时间。特别是首次调用 API 获取完整60年的数据需要几秒钟。API 以 JSON 格式的响应超过 8MB。

连续调用 API 更快，因为对同一数据的多次磁盘访问被缓存（稍后会谈到性能）。

德国柏林60年气温数据

通过集成的图表，你可以快速探索数据，放大并更详细地查看数据。或者选择“下载XLSX”并在电子表格应用程序中继续你的分析。

数据在全球任何陆地表面都可用，除了南极洲和远北地区之外。这种限制是为了保持所需存储要求较低而必要的。

关于数据质量的声明

尽管这些数据基于测量并通过天气模型增强，但与本地测量仍存在显著差异。

首先，历史天气 API 使用30公里分辨率的网格化数据，因此不能表示温度、风或降水的非常小规模模式。即使相距不到100米的测量站也会测量出不同的温度。

具有对流性降水（阵雨）的雷暴非常局部，雨量在几公里内就有所不同。然而，像全国范围的干旱这样的大规模模式被相当好地捕获。极端事件如个别的热记录也可能不准确，但温度上升的总趋势非常明显。

如果你想使用这些数据进行自己的分析，请注意潜在的与实际本地测量的偏差。

数据如何存储并通过API提供

处理大量数据并非易事。尽管只使用了 ERA5 的23个天气变量，但从气候数据商店（CDS）下载的数据量超过了20TB。

为了更好地理解为什么 ERA5 需要这么多数据存储，让我们看看数字：

• ERA5 使用0.25°的规则间隔网格（大约30x30公里的盒子）。作为图像，它需要1440 x 721（大约100万）像素。
• 要存储一天的24小时为4字节浮点数，需要95MB。
• 有了23个天气变量，我们已经达到了2.1GB
• 365天=766.5GB
• 从1959年开始的62年，我们总共需要47TB

47TB 的存储容量听起来令人印象深刻，也肯定是每个商业产品宣传页面的头号数据。然而，数据压缩技术的存在使得实际情况并非如此。

幸运的是，CDS API 已经使用压缩（NetCDF 与 deflate）来减少所需空间的一半。

• 代替2.1GB，有了压缩，我们每天大约得到1GB
• 62年，大约22TB

不用说，普通电脑无法存储如此大量的数据并处理我这套临时拼凑而成的数据集。因此，我不得不在家里改进了一下我的工作站。

为了获得约 50TB 的可用存储，我使用了 ZFS 文件系统来组合几个大硬盘。此外，ZFS 还通过校验和确保数据完整性。大多数硬盘的错误率为每 12TB 一个位错误。几乎可以肯定，在下载的 ERA5 数据集中至少会有一个位错误。

ERA5 转换工作站

此时，距离一个 API 还很遥远。为了从下载的数据集中访问连续的时间序列，所有数据必须被解压缩以读取单个位置。

因为 API 每次调用只返回一个位置的数据，我们旋转维度来存储时间序列，然后单独压缩每个时间序列。如果 API 读取德国柏林的温度序列，它只需要解压缩一小部分。使用许多文件格式，如 zarr 或 NetCDF，可以轻松完成（NetCDF中的“块维度”）。

不幸的是，压缩效果并不好。使用 NetCDF，一些技巧可以提高压缩效果：

• 代替存储完整的浮点精度温度，它可以按比例因子20缩放，然后以整数形式存储。精度将降低到0.05°C，但这已经足够了。
• 由于温度缓慢上升或下降，可以仅存储与前一时间步的“差值”。结果数字变得更小，重复得更频繁，从而增加了压缩。

使用长时间序列，缩放和增量编码可以将压缩提高2倍。代替22TB，大约需要10TB。

即使是10TB，对于运行一个简单的 API 来说，由于这个大小仍然远非理想。仅将这些数据存储在 Amazon S3 上每月的成本就是250美元，而这还只是纯粹的存储。

现代压缩算法，如 Zstd、Brotli 或 lz4 的性能略好于 NetCDF 数据格式中的默认 deflate 算法，大约提高20%，但压缩后无法直接使用。

由于天气变化缓慢，增量编码保持值非常小，可以使用整数压缩算法 Patched Frame of Reference (PFOR)。它的效果惊人地好，进一步将大小减少到 6TB。

天气数据的另一个重要特性是空间连贯性。温度图显示大面积的相似值。如果你比较相邻位置，温度数据几乎相同。通常少于0.5°C。

四个相邻网格单元的温度数据

类似于时间序列数据的增量编码，可以计算 3x3（9）相邻位置的增量。使用多维增量编码进一步将存储大小推低到刚刚不到 4TB。

作为最后的手段来使其更小，可以移除不太受欢迎的使用区域。在这种情况下，所有来自海洋、南极洲和非常偏远的北方位置的 ERA5 数据都被移除。这一步相当激进，但剩下的只有 1.2TB，现在对于一个 API 来说是一个可管理的大小。如果有更大的兴趣，也可以提供一个不受限制的版本。

GEBCO 海洋地图 2019

作为最后一步，ERA5 现在被集成到与 Open-Meteo 天气预报 API 相同的源代码中，具有相同的 API 语法、格式和文档，以便于使用。

所有这些压缩、缩放、增量编码和块分割的层都对性能有相当大的影响。最终的 API 表现得相当好，主要受到硬盘速度的限制。未缓存的62年天气数据读取甚至可能需要几秒钟。连续调用通常在10毫秒以下。由于只缓存了磁盘访问而不是整个JSON结果，10毫秒是解压缩和解码数据的总时间。

将 47TB 压缩到 1.2TB 是一个不错的挑战，并且希望对寻找时间序列天气数据的数据科学家有实际用途。

未来几个月将集成更多新的天气数据集。欧盟哥白尼计划是一个很好的来源，不久将开始进行为期6个月的季节性预测和空气质量数据的工作。