气象大数据

气象数据的版本管理与可复现性：再分析重处理带来的坑

· 南京运梦科技算法团队 · 评审 算法负责人

气象数据的版本管理与可复现性：再分析重处理带来的坑 封面

做新能源的人对再分析数据有一种默认的信任：ERA5 是「历史」，历史按理说是确定的、不变的——同一个点、同一个时刻、同一个变量，今天拉和明年拉应该一字不差。正是基于这个假设，我们才敢把它当成功率预测的训练底座、电量回测的真值、P50/P90 评估的资源基准。但这个假设并不完全成立。再分析数据是被「生产」出来的，而生产系统会有准实时流与最终流的差别、会发布修正版本、会做重处理（reprocessing）、会在平台迁移时换掉数据集编号和 DOI。结果就是：同一个「ERA5 2003 年 3 月某点 2m 气温」，在不同时间、不同版本下拿到的数值可能真的不一样。 这不是 bug，是再分析数据的固有属性。如果你的 pipeline 没有把「用的是哪一版数据」记录下来，你的实验就是不可复现的——别人复现不出你的精度，你自己半年后也复现不出。本文把再分析重处理带来的坑摊开讲，并给出版本管理与可复现性的工程纪律。

关键要点

  • 再分析数据不是不可变的：同名数据集会因为准实时流改写、修正版本发布、整段重处理、平台迁移而改变数值——「历史是确定的」这个直觉在工程上不成立。
  • ERA5 有两条流：准实时的 ERA5T（约滞后 5 天）和经过验证的最终流（约滞后 2–3 个月），最近几个月的数据后续会被最终流覆盖改写；只看时间戳不看版本，回测真值会悄悄变。
  • 重处理是真实发生的：ERA5.1 就是为修正 2000–2006 年平流层（近对流层顶）冷偏差专门重处理发布的版本；CDS 向新平台迁移时数据集入口与 DOI 也发生过更替——这些都会让「同一段历史」对应到不同的数值。
  • 可复现性的工程底线是把数据当代码管：钉死版本/DOI、记录拉取时间窗、对落盘数据做内容寻址（哈希）、维护数据血缘（lineage），让每个模型都能回答「我吃的是哪一版气象数据」。
  • 缺了版本管理，最隐蔽的事故是「训练/回测用了 A 版、上线推理对齐 B 版」，模型在悄悄的分布漂移里掉精度，等「两个细则」考核扣分才发现，根因却追不回来。

一、为什么「历史」会变：再分析的生产视角

要理解版本问题，先要换一个视角：再分析不是「记录」，而是「重建」。它用一个固定版本的数值天气预报模式，把几十年的历史观测（探空、地面站、卫星、船舶、飞机报）通过数据同化（4D-Var）反复融合，生成时空连续、物理一致的网格场。ERA5 由 ECMWF 在哥白尼气候变化服务（C3S）框架下生产，数据集本身覆盖 1940 年至今。这套生产流程意味着几件对工程很关键的事。

它有「准实时」和「最终」两条流。 为了让用户尽快拿到接近当下的数据，ERA5 提供一条准实时流，通常称为 ERA5T，滞后真实时间约 5 天发布；而经过完整质量验证的最终流（consolidated/validated）滞后约 2–3 个月。两条流在重叠时段并不保证逐字节相同——ERA5T 是「初稿」，最终流是「定稿」，定稿会回填覆盖初稿。也就是说，你今天拉的「最近一个月」，几个月后再拉，数值可能已经被悄悄改写了。 对只做长历史回测的人这通常不致命，但对「滚动接最新数据、月度重训」的功率预测系统，这意味着你的近端样本是会变的。

它会发布修正版本。 生产系统跑久了会发现系统性问题，于是针对特定时段重新跑一遍、单独发布一个修正版本。最有名的例子是 ERA5.1：原始 ERA5 在 2000–2006 年的低平流层（近对流层顶）存在一个冷偏差，根因是这段时期的数据同化背景误差协方差设定不当（与 2006 年前缺少足够的 GNSS 无线电掩星观测约束有关），ECMWF 用 1979–1999 年的协方差设定专门重处理了这一时段并发布为 ERA5.1。对地面风、地面辐射这些新能源最关心的量影响相对有限，但这件事本身说明了问题：「同一段历史」在不同版本下有不同的官方数值，而且哪一版是「对」的取决于你引用哪一版。

它会随平台迁移换入口。 再分析数据的分发平台本身也在演进。哥白尼气候数据存储（CDS）向新一代平台迁移时，数据集的标识、入口乃至 DOI 都发生过更替，部分旧入口被冻结或下线。对自动化 pipeline 来说，平台迁移不是「换个 URL」那么简单——它可能意味着同名数据集背后的版本边界、字段编码、甚至默认精度都发生了变化。

把这三件事合起来看，结论很硬：再分析数据是带版本的、可变的、会被重处理的。 把它当成「一成不变的历史」来用，就是在不可复现的地基上盖楼。

二、重处理与版本漂移如何破坏可复现性

可复现性（reproducibility）在科学上的定义很朴素：同样的输入、同样的方法，得到同样的结果。气象数据版本问题恰好攻击了「同样的输入」这一前提。具体到新能源业务，它从几个地方下手。

2.1 回测真值在悄悄变

电量回测、功率预测精度评估，本质都是拿「再分析当真值」去比模型/历史出力。如果你 2024 年用某版 ERA5 做的回测，2026 年因为重新拉数（拉到了被最终流覆盖、或换了平台后的新版本）真值变了，那么两次回测的精度差异里，有一部分根本不是模型变好/变坏，而是真值漂移。你以为在比模型，其实在比数据版本。不锁版本，回测就失去了可比性。

2.2 训练流与推理流对不齐

这是最隐蔽、也最伤精度的一类。一个典型剧本：模型训练用的是某次性下载的、几年前的 ERA5 全量（姑且叫 A 版）；上线后推理阶段为了接最新数据，走的是准实时流或迁移后的新平台（B 版）。A 与 B 在统计分布上有细微差异——可能是平流层修正、可能是准实时 vs 最终、可能是平台默认精度变了。模型在 A 版分布上学到的映射，喂进 B 版分布的输入，就会有一层说不清来源的系统性偏差。它不大，但足以让你在国家「两个细则」的月度考核里悄悄掉几分，而且因为没人记录「训练吃的是哪版、推理吃的是哪版」，根因几乎追不回来。

2.3 跨团队、跨时间的协作失真

同一个公司里，A 同事 2025 年初下的 ERA5、B 同事 2026 年下的 ERA5，文件名都叫 era5，谁也没标版本。两人各自训出的模型精度对不上，排查半天才发现底层数据就不是同一批。「同名不同值」是协作里最贵的坑，因为大家默认同名即同物，没人会第一时间怀疑数据本身。

2.4 论文/报告的不可复现

对外发技术报告、给投资方做尽调、向评审说明方法，如果只写「我们用了 ERA5」而不写版本、不写下载时间窗、不写平台，严格说这个结果是不可复现的。审稿人或尽调方拿最新版 ERA5 复现，数值对不上是大概率事件。规范的引用应当带上数据集版本与访问日期——这不是形式主义，是可复现性的最低成本保险。

三、把数据当代码管：版本管理与可复现性的工程纪律

软件工程早就有一套对付「东西会变」的成熟方法论——版本管理。气象数据工程要做的，就是把这套方法论搬过来：把数据当代码一样钉死、追溯、留痕。 落地上有几条硬纪律。

纪律一：钉死版本与来源，写进元数据。 任何进入特征库的再分析数据，都必须显式记录三件事：数据集标识与版本（如「ERA5 单层」+ 具体版本/修正标记，遇到 2000–2006 段要标清是否用 ERA5.1）、获取平台与入口、获取的时间窗（哪天拉的）。把它写进随数据走的元数据（sidecar JSON 或表头），而不是塞在某个人的脑子里。一句话原则：任何模型都要能回答「我吃的是哪一版气象数据」。

纪律二：区分准实时流与最终流，别混用。 如果业务必须接近端数据，就显式承认你用的是准实时流，并制定一条规则：近端样本在最终流定稿后是否回填重训。最忌讳的是「不知不觉地」把准实时和最终拼在一条时间轴上——拼接缝处的统计跳变会污染模型。

纪律三：对落盘数据做内容寻址（哈希）。 给每一份下载落盘的数据算一个内容哈希（如 SHA-256），用「哈希 = 唯一身份」而不是「文件名 = 身份」。这样「同名不同值」立刻暴露：文件名一样但哈希不同，pipeline 就能告警，而不是默默当成同一批用。这其实就是 Git 用 commit 哈希、容器用 image digest 的同一套思想，搬到数据上叫内容寻址存储。

纪律四：维护数据血缘（lineage）。 记录每个训练样本、每个模型从哪批原始数据、经过哪些处理步骤（换名、单位换算、时区对齐、缺测插补、版本选择）得来。血缘让你在数据版本变化时能快速回答「哪些模型受影响、需要重训」，而不是全量盲重训。配合数据版本管理工具（DVC、lakeFS、或自建的版本目录）可以把这件事自动化。

纪律五：训练与推理对齐同一口径。 上线前显式校验：推理阶段拿到的气象数据，其版本/流/平台口径与训练数据是否一致。不一致时要么对齐口径，要么在特征层做偏差订正（参考分位数映射等方法），而不是装作没差别。

纪律六：版本变更要有 changelog 和回归测试。 当你主动升级数据版本（如从某版 ERA5 切到含 ERA5.1 修正的版本），把它当成一次「依赖升级」：记录变更、跑一遍回归（对关键场站、关键指标比对新旧版本的差异量级），评估是否需要重训，而不是悄悄替换。

这六条没有一条是高深算法，全是工程纪律。但正是这些纪律，决定了你的实验半年后还能不能复现、你的精度退化能不能定位、你的对外结果能不能被信任。

四、与运梦气象 API 的关系

运梦气象 API 在数据接入层替你挡掉了一部分版本管理的复杂度，但理解底层版本语义仍然必要，二者并不矛盾。

历史回测固定走 ERA5（dataSourceId="era5"，运梦产品对外提供的历史范围为 1950 年至今），预报走德国气象局（dataSourceId="ger"，覆盖未来约 7 天）。API 在命名、单位、时区上做了统一归一（CF 命名、tas 返回 ℃、rsds 返回 W·m⁻²、timezone 必填），让你不必每次接入都重写一层换名换单位的胶水代码——这本身就消除了一类「不同人处理口径不一致」的可复现性隐患。但版本管理这件事，责任仍在你这一侧的纪律上：

  • 回测要可比，就固定时间窗、留存样本。 同一组对比实验，尽量用同一次拉取的数据；要复现历史结论，就把当时的样本（或其内容哈希）留档，而不是每次重拉。
  • 训练/推理对齐，就统一走同一个数据源口径。 历史用 era5、预报用 ger，两者在 CF 命名和单位上同口径，可以在一条管线里衔接；但要清楚历史与预报是两类不同来源，拼接处该做的偏差订正不能省。
  • 对外报告，就写清口径。 注明用的是运梦 API 的 era5 历史源、字段、时区与拉取时间，让结果可被复现。

更具体的字段、单位、数组对齐这一层的避坑，可以接着读气象数据工程化最容易踩的五个坑；ERA5 作为历史底座的产品规格见 ERA5 产品页。

收尾

气象数据的版本问题，根子上是一个被低估的事实：再分析的「历史」是被生产出来的，而生产系统会改写、会修正、会重处理、会迁移。 准实时流会被最终流覆盖、ERA5.1 这样的重处理会改掉特定时段的数值、平台迁移会换掉版本与 DOI——这些都让「同名不同值」成为常态。对付它没有银弹，只有把软件工程那套版本管理纪律老实搬过来：钉死版本、内容寻址、维护血缘、对齐训练与推理、变更走回归。守住这几道关，你的功率预测才有一个真正可复现、可追溯、可信任的数据地基；守不住，再好的模型也是盖在流沙上。

参考与延伸阅读