信息速览
MSWEP 是少数把雨量站、卫星、再分析三类降水估计塞进同一张网格，并且从 1979 年一路做到两小时前的产品。0.1°、逐小时、全球、含海洋——这五个限定词同时成立的降水数据集，用一只手数得过来。
它的名字里带着「Weighted-Ensemble」，那是 V1 时代的遗产：2016 年那一版确实是给每个来源配一张权重图。十年之后，V3 换成了十八组机器学习模型，权重这个角色被替换成「哪组模型可用就用哪组」。名称没改，机制换了两代。
下面要讲的是这张图上的三种刻度——小时、日、月——各自由什么证据决定，以及当上游产品换代时，四十六年的序列会在哪一年拐弯。
| 项目 | 数值 | 来源 |
|---|---|---|
| 官方全名 | Multi-Source Weighted-Ensemble Precipitation（MSWEP） | 官网首页标题 |
| 当前版本 | V3.16，2026-02-01 发布（文档封面标 2026-02-06） | 文档版本史、封面 |
| 制作方 | GloH2O LLC，美国新泽西州普林斯顿 | 站点页脚 |
| 时间覆盖 | 历史 1979–2024；近实时 2025 至约两小时前 | 文档 §6 |
| 时间分辨率 | 逐小时、3 小时、逐日、逐月，四种并出 | 文档 §6 |
| 空间分辨率 | 0.1°，赤道约 11 公里 | 文档 §6 |
| 网格 | 1800 × 3600，含海洋 | 文档 §6 |
| 字段 | precipitation；近实时另加 model_id | 文档 §6 |
| 格式 | netCDF-4，自描述 | 文档 §6 |
| 目录 | Past / Past_nogauge / NRT / Gauge_metadata | 文档 §4–§7 |
| 延迟 | 约 2 小时（官网 FAQ 另处写约 3 小时） | 官网正文与 FAQ |
| 许可 | CC BY-NC 4.0，商业用途需另签 | 官网 Data access、文档 §2 |
| 访问 | 提交申请，邮件回 rclone 拉取说明 | 官网 Data access |
| 推荐引用 | Wang et al. (2026)，arXiv:2602.01436 | 文档 §3 |
§1 速览：一份降水产品，为什么值得单独写
§1.1 一句话定义
MSWEP 把三类互相不替代的降水证据——地面雨量站的直接观测、卫星对云顶与微波辐射的遥感反演、数值模式对水汽输送的再分析——合成为一张从 1979 年延续到此刻的全球格点降水场，逐小时、0.1°、含海洋。
它不是"最好的那个降水数据"。它是把三种各自的失败模式互相抵消的那个：站点在小时间尺度上最准但分布极不均匀，卫星覆盖均匀但在冷季与山地失真，再分析时空连续但强度被模式平滑。融合的全部技术难度，就集中在"什么时候信谁"这一件事上。
§1.2 为什么它不是「又一个降水栅格」
降水数据集很多，分级大致是三层。第一层是纯观测拼图，例如以站点为唯一来源的逐日网格；第二层是纯遥感，例如以被动微波与红外为主的卫星产品；第三层是融合产品，把前两层加再分析一起调。MSWEP 属于第三层，但它在这一层里有两个不常见的选择。
一是从 1979 年做起，而不是从卫星时代做起。 IMERG 与 GSMaP 都是 2000 年之后才有，TRMM 之前没有可靠的星载降水雷达。MSWEP 的解法是：2000 年前用 PERSIANN-CCS-CDR 这条长序列红外产品顶上，再让机器学习模型学会在"只有红外"的条件下还能输出什么量级的降水。代价是 1979–1999 段的误差结构与被卫星覆盖的时段不同——这一点在 §4 与 §7 都会回来。
二是日尺度订正做得比同类更重。 论文自己承认，做日尺度订正的融合产品不止一家——PERSIANN-CCSA、GSMaP_Gauge、MERRA-2 都做。区别在方法：MSWEP 用最优插值，把站点邻近性、降水相关长度、站间相关、报告时刻对齐四件事一起放进权重，而不是给一个区域乘一个比值。文档 §1 把"计入报告时刻"写成独特之处，这句话有分量：它决定了日尺度上产品与站点能不能对得上。
§1.3 三十秒决策卡：你的处境，它能帮你什么
| 你的处境 | 它能帮你什么 |
|---|---|
| 要驱动一个流域水文模型，需要 1979 年以来连续的日降水 | 四十六年无断档，日尺度已用五万余站订正，是它的主战场 |
| 要做逐小时的暴雨事件识别或城市内涝模拟 | 有逐小时场，但要知道 0.1° 一格约 11 公里，对流单体的落区对不上 |
| 要给流行病学或农业模型配一份降水协变量 | 全球含海洋、时序连续、单位统一，接经纬度即可，比站点插值省事 |
| 要算某地 1980–2020 的降水趋势 | 可以算，但必须避开 §1.5 的版本陷阱，否则会算出一个不存在的干化期 |
| 要做近实时洪涝预警 | 有两小时延迟的流，但最近十天文件会被重写，必须按 model_id 判断是否定稿 |
| 要给商业产品供数 | 不能直接用。CC BY-NC 4.0，公司内部研究也算商业用途，需另签 |
| 要研究单个山谷、单个城市的降水 | 给不了。0.1° 是它的物理下限，再细只能靠降尺度或地形订正 |
§1.4 不适合谁
如果你的需求是"给一个没有雨量站的流域从零建立降水基准"，MSWEP 不适合单独承担。它没有做雨量站接水量校正，山地与积雪区的系统性低估被保留了下来——官方的理由是使用者更希望数据与站点读数一致，而不是与真实落水量一致。需要后者，得再叠一层偏差校正，官方自己推荐的是 PBCOR。
如果你的需求是"可匿名、可脚本化、可放进 CI 的取数"，它也不适合。数据要人工提交申请，回信里给共享云盘链接，再用 rclone 同步。没有公开的对象存储地址，没有稳定的下载 API（API 只对商业许可方开放）。
如果你的需求是"复现某篇 2024 年论文里的图"，同样不适合直接照抄。2025 年 7 月 V3.15 上线，算法从权重图换成机器学习，同一条曲线会变；2026 年 2 月 V3.16 又改了日尺度订正的实现。论文里没写版本号的，图就对不回去。
§1.5 贯穿本文的案例：一张 1980–2020 年的降水趋势图，在 2000 年拐了一下
设想一个做中亚水文的团队。2026 年 3 月，他们要回答一个很普通的问题：某内陆流域过去四十年是变湿还是变干。手上只有 MSWEP，于是拉下 V3.16 的 Past 目录，逐年求区域平均，画一条 1980–2020 的折线。
图上出现了两段平台：1980–1999 年在一个水平，2000–2015 年低下去一截，2016 年之后又抬回来。看起来像"本世纪前十五年持续干化，近年恢复"。这是一个会写进摘要的结论。
官方文档在 V3.16 版本说明的第一段就否掉了它，原文写得很直白：IMERG 与 GSMaP 自 2015 年起呈现系统性降水增加（很可能与转向 GPM 有关），因此 V3.15/V3.16 在 2000–2015 段相对于其前后时段显示出人为偏低的降水；需要可靠趋势估计的使用者，在问题解决前建议使用 V2.80（覆盖 1979–2021）。
拆开看这件事：
| 要素 | 内容 |
|---|---|
| 判定 | 2000–2015 的低谷不是气候信号，是上游输入换代的台阶 |
| 机制 | 2000 年前主力是红外产品，2000 年后换成 IMERG 与 GSMaP；这两条序列自身在 2015 年前后有一次量级抬升，模型把这个抬升学成了"以前少、以后多" |
| 波及 | 未订正版（Past_nogauge）与订正版（Past）同时受影响，站点订正压不住区域尺度的系统性偏移 |
| 处置 | 三种：换 V2.80 做趋势；只用 2016 年之后做事件分析；或自己做分段偏差校正并在文中声明 |
这个案例的价值不在于它多离奇，而在于它揭示了一类通病：融合产品的误差不是均匀铺在时间轴上的，而是集中在输入源换代的那几个年份。后面讲目录结构（§3）、讲模型栈（§4）、讲取数时怎么锁版本（§5）、讲局限（§7）时，都会回到这张图。
§2 数据构成：一张 1800×3600 的场，四种时间步长
§2.1 规模：哪些数字是官方的，哪些是算出来的
官方给出的规模数字只有四个：0.1°、1800×3600、1979 年至今、四种时间步长。其余都要自己推。推的时候要把"格点数"“时刻数”“文件数”"字节数"分开，混在一起就会出现数量级错误。
| 口径 | 数值 | 来源 |
|---|---|---|
| 空间格点数 | 1800 × 3600 = 6,480,000 | 文档 §6 给定维度 |
| 每小时时刻数 | 1 | 逐小时产品定义 |
| 平年逐小时值数 | 6,480,000 × 8,760 ≈ 5.68×10¹⁰ | 按维度推算 |
| 单年逐小时未压缩体积 | 约 227 GB（float32，4 字节/值） | 按维度推算 |
| 历史时段年数 | 46 年（1979–2024，含 12 个闰年） | 文档 §6 覆盖范围 |
| 历史逐小时文件数 | 16,802 天 × 24 = 403,248 个文件 | 按命名规则推算 |
| 历史 3 小时文件数 | 同上天数 × 8 = 134,416 个文件 | 同上 |
| 历史逐日文件数 | 每天一个，与天数相同 | 同上 |
| 历史逐月文件数 | 46 × 12 = 552 个文件 | 同上 |
| 历史全分辨率文件总数 | 约 55 万个 | 上四项相加 |
| 历史未压缩总量 | 约 10 TB 量级 | 227 GB × 46 |
这张表里最反直觉的是文件数。4 万多个格点 × 4 千多个时刻如果切成一个文件，谁也用不了；切成逐小时一文件，就变成 40 万个文件。40 万个小文件对同步工具是一场灾难——瓶颈不在带宽，在元数据往返。§5 会讲怎么绕开。
体积也要说清口径：227 GB/年 是 float32 未压缩的算术值。netCDF-4 默认带 deflate 压缩，降水场又有大量零值，实际落地体积会小一个可观的比例。官方文档没有公布单文件大小，所以任何"精确总量"的说法都是估的。
§2.2 一条记录逐项解剖
一个格点值不是一个孤立数字，它至少有五层身份。取错任何一层，数就废了。
| 层 | 取值示例 | 错了会怎样 |
|---|---|---|
| 目录 | Past / Past_nogauge / NRT |
拿未订正版当成品用，区域偏差可达数十个百分点 |
| 版本 | MSWEP_V315 / MSWEP_V316 |
跨版本拼序列，接缝处出现台阶 |
| 步长 | Hourly / 3hourly / Daily / Monthly |
小时值当日值用，量级差 24 倍 |
| 文件 | 2020116.18.nc |
把 DOY 当年月读，时间轴整体错位 |
| 字段 | precipitation（另有 model_id） |
忽略 model_id，把未定稿的近实时值当终值 |
文件名 2020116.18.nc 的含义是：2020 年、第 116 天（4 月 25 日）、18 时起的一小时。文档给的完整路径是 MSWEP_V315/Past/Hourly/2020116.18.nc，并注明它存的是 2020 年 4 月 25 日 18:00–19:00 UTC 的降水。注意"起"这个字：文件名标的是区间起点，不是区间终点。这一条在物候、日循环、暴雨峰值时刻的研究里能直接决定结论。
§2.3 三个数据目录，三种用途
| 目录 | 内容 | 时间范围 | 站点订正 | 适用 |
|---|---|---|---|---|
Past |
卫星与再分析融合后再经站点订正 | 1979–2024 | 有（日 + 月） | 绝大多数用途：水文建模、气候分析、模型训练 |
Past_nogauge |
同一条融合基线，不做站点订正 | 1979–2024 | 无 | 两件事：评估基线本身；算近实时异常（如重现期） |
NRT |
近实时延伸，滚动重写 | 2025 至约两小时前 | 视 model_id 而定 | 预警、监测、业务看板 |
Past_nogauge 的存在容易被忽略，但它是理解整个产品的钥匙。官方把它限定在两个用途上，措辞很明确：一是拿独立站点去评估基线，二是计算近实时的异常量（例如事件重现期）。为什么第二件事需要它？因为算重现期要用一条"同质"的长序列做参照，而订正版与近实时版在站点覆盖上的差异会污染分位数。用订正版算基准、用近实时版算当前值，两者不同质，重现期就偏了。
§2.4 四种步长，四种单位，一个坑
| 步长 | 单位 | 数值语义 | 直接相加会怎样 |
|---|---|---|---|
| 逐小时 | mm/hour | 强度（该小时内平均每小时毫米数） | 加 24 个得到 24 倍日量 |
| 3 小时 | mm/3-hour | 该 3 小时的累积 | 加 8 个得到日量，正确 |
| 逐日 | mm/day | 该日累积 | 加 30 个近似月量，但有月末误差 |
| 逐月 | mm/month | 该月累积 | — |
这张表值一整节。四个文件的字段名一模一样都叫 precipitation，维度都是 1800×3600，只有单位属性不同。任何一段"把小时文件循环读进来求和"的代码，如果不乘 1 小时，就会把日雨量算成小时雨量的 24 倍。
三种步长之间也不是独立生成的：文档说逐小时、3 小时、逐日、逐月是同一套流程的不同输出，近实时部分的小时文件更新后，3 小时、日、月文件随之更新。这意味着同一天的小时文件之和与日文件在数值上应当接近，但不必逐位相等——它们各自经过了自己的舍入与重采样。
§2.5 与同类产品的定位差异
| 产品 | 来源构成 | 步长 / 分辨率 | 起点 | 许可 | 差异 |
|---|---|---|---|---|---|
| MSWEP V3 | 站点 + 卫星 + 再分析，机器学习融合 | 逐小时 / 0.1° | 1979 | CC BY-NC 4.0 | 唯一同时做到 1979 起、逐小时、含海洋的融合产品；非商业 |
| ERA5 | 再分析（同化观测） | 逐小时 / 0.25° | 1940 | CC BY 4.0 | 时间更长、许可更宽，但降水是模式量，峰值被平滑 |
| IMERG Final | 卫星为主，含月尺度站点订正 | 半小时 / 0.1° | 2000 | 开放 | 卫星时代精度高，2000 年前没有 |
| GHCNd | 纯站点逐日观测 | 逐日 / 站点 | 更早 | 开放 | 是"真值"来源之一，但空间极不均匀 |
| CHIRPS | 气候学 + 红外 + 站点 | 逐日 / 0.05° | 1981 | 开放 | 分辨率更细，日尺度精度弱于融合产品 |
判断规则可以压成一句：要长序列加高时间分辨率，选 MSWEP；要许可宽松可商用，选 ERA5 或 IMERG；要站点真值做验证，选 GHCNd。三者不是替代关系，是链条上的不同环节。
§3 身份层：先确认你要的是哪一份 MSWEP
§3.1 一个名字，八种东西
"MSWEP"这三个字母在文献里指向至少八样不同的东西。把它们排开，问题就清楚一半。
| 组合 | 时间范围 | 算法代际 | 步长 | 状态 |
|---|---|---|---|---|
V2.80 Past |
1979–2021 | 权重图（随机森林） | 3 小时 / 0.1° | 冻结，官方在 V3.16 说明中推荐用于趋势 |
V3.15 Past |
1979–2024 | 机器学习栈 | 逐小时 / 0.1° | 有已知缺陷，官方建议改用 V2.80 |
V3.16 Past |
1979–2024 | 机器学习栈 | 逐小时 / 0.1° | 当前主推，仍带 2000–2015 偏低问题 |
V3.16 Past_nogauge |
1979–2024 | 机器学习栈 | 逐小时 / 0.1° | 当前主推，无站点订正 |
V3.16 NRT |
2025 至两小时前 | 18 组栈滚动 | 逐小时 / 0.1° | 滚动重写 |
V3.16 Gauge_metadata |
— | — | — | 站点位置、时段、报告时刻 |
同一篇论文里写"MSWEP"，可能指的是其中任何一个。判断方法是看三件事：覆盖到哪一年、是 3 小时还是逐小时、有没有站点订正。三件事对上了，才是同一样东西。
§3.2 版本号怎么读，以及一处写法不一致
版本号是"主版本.次版本"。V3 是第三次算法重构，V3.15 与 V3.16 是两次发布。文档的写法在大小版本之间是平铺的：版本史里既有 2.0、2.1、2.2、2.8，也有 2.01、3.15、3.16，编号位数不固定。
一个可以直接观察到的不一致：文档正文一处写"V2.80"，另一处写"Version 2.8"，指的是同一版。这不影响使用，但如果你要在参考文献里写版本号，最好抄官方文档的"Version 2.8 (February 14, 2021)"那一行，而不是抄正文里的简称。
另一处不一致在日期上：文档封面写"February 6, 2026"，版本史里写"Version 3.16 (February 1, 2026)"。发布日与文档定稿日大概不是同一天。做可复现记录时，写"V3.16"比写日期可靠。
§3.3 目录名与文件名是耦合的
文档给的示例路径是 MSWEP_V315/Past/Hourly/2020116.18.nc。注意第一段：目录名里带着版本号。也就是说，换版本不是覆盖文件，而是换一个同级目录。
这个设计对使用者是好消息（旧版还在，可回溯），对脚本是坏消息（路径写死就会在换版时静默失败或读到旧数据）。官网 FAQ 里的 rclone 示例写的目标是 MSWEP_V315_test，说明这套命名在 V3.15 时期成型，之后按版本递增。
一个稳妥的习惯：把版本段做成变量，从环境变量或配置读取，不要出现在命令行中间。
#版本段只在一处定义，其余全部引用它
MSWEP_VER="MSWEP_V316"
REMOTE="GoogleDrive"
BASE="${MSWEP_VER}"
rclone lsd --drive-shared-with-me "${REMOTE}:${BASE}"
§3.4 Past_nogauge 不是"残缺版"
初次接触的人容易把 Past_nogauge 当成"没有订正、所以更差的版本"，然后跳过。官方的定位不同：它是基线，是两个合法用途的必需品。
| 用途 | 为什么必须用未订正版 |
|---|---|
| 评估基线本身 | 拿独立站点评估时，若产品已经用了这些站点订正，评估就是循环论证 |
| 计算近实时异常（重现期） | 历史基准与当前值必须同质；订正版与近实时版站点覆盖不同，分位数不可比 |
第二条尤其值得展开。算"这场雨是五十年一遇"，做法是拿当前值去比历史分位数。如果历史分位数来自订正版（有站点参与），当前值来自近实时版（站点还没进来），两条序列的分布形状不同，比出来的重现期就带系统性偏差。用未订正版做基准，两边都"没有站点"，反而可比。
§3.5 近实时的十天重写窗口
NRT 目录的文件不是写完就定。文档说得很清楚：由于各数据源延迟不同、且可能出现中断，过去十天的近实时文件会随新数据到位被逐步更新，建议使用者重新下载升级后的文件。
这条更新是分阶段的，每个阶段的输入不同：
| 时间 | 可用输入 | 相对精度 | 高纬覆盖 |
|---|---|---|---|
| 初始（约 2 小时） | 仅 PDIR-Now | 最低 | 无（>50/60°N/S） |
| 约 4 小时后 | + GSMaP-NRT、IMERG-Early、GDAS | 中 | 部分 |
| 约 1 天后 | + GSMaP-Standard、IMERG-Late | 较高 | 较好 |
| 约 5 天后 | + ERA5（替换 GDAS） | 与历史产品一致 | 完整 |
对应的判断依据写在文件里：model_id。低中纬 model_id = 1、高纬 model_id = 5 时，该格该时才算与历史产品一致的定稿值；其余编号都是过渡态。这是这份数据少见的、把"内部状态"直接暴露给使用者的设计——它让你能在一张图上标出"哪些格还没定稿"。
§3.6 锁版本的三行清单
做任何要写进论文或报告的分析之前，把这三件事记下来：
| 项 | 记什么 | 为什么 |
|---|---|---|
| 版本 | V3.16 或 V2.80，不要只写 V3 |
次版本之间算法可以换 |
| 目录 | Past / Past_nogauge / NRT |
决定有没有站点订正 |
| 取数日 | YYYY-MM-DD |
近实时文件会重写，历史文件也可能因重发而变 |
官方文档自己就建议引用时注明版本号，理由是"确保可复现"。这句话在一份近实时产品上是认真的：不写版本，两年后没人能重建你的图。
§4 质量层：权重不是常数，是十八组模型的分工
§4.1 三个来源，三种坏法
融合之所以必要，不是因为三种来源互相印证，而是因为它们在不同的条件下坏得不一样。把失败模式列清楚，"什么时候信谁"才有依据。
| 来源 | 强在哪 | 坏在哪 | 典型失效场景 |
|---|---|---|---|
| 雨量站 | 点尺度强度准，日、月累积可靠 | 空间极不均匀，海上没有，山区稀疏，报告时刻各异 | 高原、沙漠、雨林、整个海洋 |
| 卫星（微波 / 红外） | 空间连续，热带对流好 | 冷季固态降水失真，暖云与薄云漏判，山地地形混叠 | 高纬冬季、安第斯与青藏高原、地形陡变带 |
| 再分析 | 时空连续，物理自洽，无缺测 | 强度被模式平滑，峰值低估，日循环偏差 | 强对流、地形强迫降水 |
三种坏法几乎不重叠——这才是融合能赢的物理基础。站点缺的是空间，卫星缺的是冷季与地形，再分析缺的是强度动态范围。三者互补，而不是互相备份。
§4.2 十八组模型栈：权重的替代物
V1 的做法是给每个来源算一张权重图，权重随格点变、随时间尺度变。V3 换了做法：不再有"权重"，而是训练十八组完整的模型栈，每组对应一种"输入可得性组合"，逐格逐时挑一组来用。
每组栈里有四个子模型，分工按尺度排：
| 顺序 | 模型 | 做什么 | 训练标签 |
|---|---|---|---|
| 1 | XGB | 估计日尺度降水 | 全球日观测池化 |
| 2 | XGB | 把日估计解集到 3 小时 | 小时观测聚合到 3 小时 |
| 3 | RF | 修正方差低估（分位数匹配，平方根变换） | 3 小时观测 |
| 4 | XGB | 把 3 小时解集到小时 | 小时观测 |
第三个子模型是关键的一步。机器学习回归天然趋向条件均值，输出会被"压扁"——雨日太多、小雨太多、峰值太低。RF 那一步用分位数匹配专门把方差拉回来，且只吃静态预测因子，不吃动态输入。文档解释了这个设计：动态输入在训练与推理时的分布差异会污染方差修正，所以干脆不让它参与。
十八组栈的差别，就是"哪几个动态输入在场"：
| 栈 | ERA5 | GDAS | IMERG-L | GSMaP-MVK | P-CCS-CDR | PDIR-Now | 典型使用场景 |
|---|---|---|---|---|---|---|---|
| 01 | ✓ | — | ✓ | ✓ | — | — | 参考栈，2000 年后有卫星的中低纬 |
| 05 | ✓ | — | — | — | — | — | 高纬参考栈，无卫星或卫星不可靠处 |
| 06 | ✓ | ✓ | ✓ | ✓ | — | — | 近实时一天后，GDAS 已到位 |
| 12 | — | — | ✓ | ✓ | — | — | 再分析暂缺时的过渡 |
| 15 | — | ✓ | — | — | — | ✓ | GDAS 加 PDIR 的短窗口 |
| 18 | — | — | — | — | — | ✓ | 最初两小时，只有 PDIR-Now |
选取规则不是加权平均，是硬选择：文档原文的意思是，对每个 0.1° 格点与每个小时，生产流程找出所有可用的模型栈，然后采用编号最低的那个。编号大致按"输入质量从高到低"排序，所以这条规则等价于"用当前能用的最好一组"。
读表须知：官方文档里的这张表用数字 3 与 7 标记可用与不可用，没有给图例。判断方法是看 model_18——它只有 PDIR-Now 一格是 3，而文档明说最初的文件只靠 PDIR-Now，所以 3 表示使用、7 表示不使用。论文版同一张表用的是勾与叉，清楚得多。
§4.3 尺度阶梯：为什么"权重随尺度变"这句话仍成立
V1 的论文把设计哲学写成一句话：按时间尺度与地点，最优地合并可得的高质量来源。那句话在 V3 里的实现方式变了，但结论没变——不同尺度上，不同证据的分量确实不同。
| 尺度 | 主导证据 | 机制 | 理由 |
|---|---|---|---|
| 小时 | 卫星微波 + 再分析 | 第 4 个子模型从 3 小时解集，动态输入为主 | 站点在小时尺度几乎不可能有全球连续覆盖，只有卫星能给出落区与时段 |
| 3 小时 | 卫星 + 再分析 | 第 2 子模型解集，第 3 子模型拉方差 | 同上，且 3 小时是多数卫星产品的原生节拍 |
| 日 | 站点订正介入 | 最优插值乘性订正 | 日累积是站点的强项，且报告时刻可以对齐 |
| 月 | 站点订正为主 | GPCC 月网格做最优插值加长期偏差调整 | 月尺度上站点最密，插值误差被平均掉 |
一句话概括：越往短尺度走，越依赖天上的东西；越往长尺度走，越依赖地上的东西。 这不是一句修辞，是四个子模型加两级订正的架构决定的。
这条阶梯在 V1 里就已经存在，只是位置不同。V1 的合并分四步，第三步的原话是：对月、日、3 小时三个尺度分别做加权平均，得到每个尺度上的一个降水异常估计；第四步再把长期均值逐级降尺度——先到月、再到日、最后到 3 小时。也就是说，V1 的阶梯是"定均值 → 月 → 日 → 3 小时"，V3 的阶梯是"日 → 3 小时 → 小时"，起点与终点各自向下挪了一格。
V1 还有一处设计上的不对称，值得记住：卫星与再分析的权重按各数据集在周边站点的表现取，站点的权重却按密度算——一个不含任何站点观测值的几何函数，公式里最近的 25 公里做衰减尺度、1000 公里半径内求和，典型值从无站区的 0、孤立单站的 1 到密集区的约 2.5。换句话说，站点在 V1 里"有多少话语权"取决于它周围站有多密，而不取决于它准不准。这个不对称在 V3 里被换掉了：站点不再有话语权，只有订正量。
顺带解释一个常见困惑：既然月尺度最依赖站点，为什么还有 2000–2015 的区域性偏差（§1.5 的案例）？因为站点订正是相对的——它把格点值拉到与站点一致的水平，但如果整个区域的格点基线被抬高了，站点会把这条抬高的曲线一起认下来。插值订正能修局部偏差，修不了"输入源换代造成的全域台阶"。
§4.4 两级站点订正：日修形态，月修水平
日尺度订正用的是最优插值（OI），不是简单的比值平均。文档给出的参数很具体：
| 参数 | 取值 | 作用 |
|---|---|---|
| 参与站数 | 每格最多 4 个 | 控制局部性 |
| 搜索半径 | 500 公里 | 保证稀疏区也有站可用 |
| 权重 | OI 权重，含相关长度、站间相关、距离 | 避免近站重复计权 |
| 订正方式 | 乘性订正施加到小时序列上 | 保留日内形态 |
| 最终值 | 订正值与未订正值按 OI 权重的加权组合 | 无站处平滑退回基线 |
两个细节值得记住。第一，订正是乘性的，而且施加在小时数据上——也就是说日尺度的站点信息被"摊"回 24 个小时，形状不变、总量改变。第二，最终值是订正与未订正的加权组合，权重由 OI 给出；离站越远，越退回基线。这意味着同一张图上，站点密集区与空白区的数据来源实际上是不同的两支。
月尺度订正另起一层，用的是 GPCC 月网格。这里有个少见的取舍：官方只保留真正含站点的 GPCC 格点，把插值出来的格点排除掉。文档给的理由是降低不确定性——插值格点看着连续，其实是模型猜的，用它做订正等于用一个估计去修另一个估计。同层还有一个独立的长期偏差调整，用最近四个站的月值修正均值偏移。
§4.5 小时尺度上，站点从「成员」退成「标签」
这是 V1 与 V3 之间最容易被忽略的一次身份变化。
V1 里，两个纯站点产品（CPC Unified、GPCC）是集合的成员，各有一张权重图，权重由站点密度算出。也就是说，站点数据本身作为一个场，参与逐格加权。
V3 里，站点不再是场。它出现在三个位置：训练标签（小时与日观测，训练四个子模型）、日尺度订正的输入（乘性因子）、月尺度订正的输入（GPCC 网格）。没有一处是"把站点插值成场再参与平均"。
这个变化改变了一件事：站点的作用从"提供数值"变成"提供约束"。前者会在无站处留下插值痕迹，后者不会——无站处完全交给模型，模型由静态因子（气候、地形、经纬度）外推。这解释了为什么 V3 在稀疏区不再有明显的插值斑块，也解释了为什么它在稀疏区的表现更依赖训练样本的代表性。
§4.6 两个被忽略的旋钮：报告时刻与相关长度
报告时刻。 全球雨量站的日观测不是在同一个时刻截断的。东亚多在 08 时（当地），美国多在 07 时或 08 时，有的站在 00 时 UTC。如果不处理，把一个"昨日 08 时至今日 08 时"的站点日量与一个"00 至 24 时 UTC"的格点日量相比，会凭空产生几个小时的错位——在降水日循环强的地区，这个错位足以让相关系数掉一截。
MSWEP 的解法是推断而不是索取：把逐小时基线数据按 1 小时步长在 ±36 小时窗口内平移，重算日累积，找与站点日量 Spearman 相关最高的那个平移量，其反向即为报告时刻。推断结果作为一张附表发布（daily_station_reporting_times.csv），以相对 00 UTC 的整数偏移表示：-5 表示该站日量约在 19:00 UTC 截止，0 表示与 UTC 日界对齐，+3 表示次日 03:00 UTC。
相关长度。 这是 OI 的核参数：两个相距 30 公里的站，降水相关性有多高？答案随降水类型与聚合尺度变——对流性降水几十公里就掉到零，锋面降水几百公里还相关。MSWEP 的做法是逐格估计：在目标格周围 500 公里内随机取 20 个邻格，算 Spearman 相关，拟合高斯衰减模型，得到该格的相关长度。这一步是 V3.15 相对 V2 的改进项之一（文档版本史第 5 条）。
§4.7 案例在这一层的落点
回到 §1.5 的案例。现在可以解释那张图上 2000 年的台阶是怎么来的了。
2000 年前后，可用输入换了一茬：IMERG 与 GSMaP 从这一年起才有，此前主力是 PERSIANN-CCS-CDR 这条红外序列。模型栈也随之换组——2000 年前用含 P-CCS-CDR 的栈，2000 年后用含 IMERG 与 GSMaP 的栈（模型 01 一类）。
不同栈的输出要拼成一条序列，就必须协调。文档给的协调方法是三步：去趋势、CDF 匹配、趋势还原。CDF 匹配把新栈的分布对齐到参考栈，趋势还原再把长趋势放回去。这套方法能消除"接缝处的跳跃"，但消除不了"上游序列自身在 2015 年有一次量级抬升"这件事——因为抬升发生在参考系内部，是被当作真实信号保留下来的。
换句话说：协调机制假定"参考栈是对的"，而这次出问题的恰恰是参考栈所依赖的 IMERG 与 GSMaP 自身带了一个台阶。这解释了为什么官方建议趋势分析退回 V2.80：V2.80 用的是 ERA5 加 IMERG，没有引入 GSMaP 这一路，台阶的来源不同。
§4.8 V3 到底比 V2 强在哪：把表横着读是错的
论文表 3 给了各模型栈与主流产品的独立站点检验。最容易被误用的是横着比——因为每一行的检验样本数不同。
| 对象 | 日 KGE | 日相关 | 峰值偏差 | 雨日偏差（天/年） |
|---|---|---|---|---|
| model_06（ERA5+GDAS+IMERG+GSMaP） | 0.78 | 0.84 | +1.7% | −9.7 |
| model_01（参考栈，ERA5+IMERG+GSMaP） | 0.69 | 0.76 | +2.1% | −6.7 |
| model_05（高纬参考栈，仅 ERA5） | 0.60 | 0.67 | +8.7% | −13.0 |
| MSWEP V2.8 | 0.67 | 0.76 | −20.6% | +24.0 |
| ERA5 | 0.61 | 0.70 | −17.5% | +25.6 |
| IMERG-Final V7 | 0.62 | 0.71 | +2.5% | +2.9 |
读法：只看同一行内部的指标，跨行只看方向，不看小数点。 论文表 3 每一行都标注了检验站数，六行从 9,370 到一万四千余站不等，样本不同，0.78 与 0.69 之间有 0.09 的差，其中有多少是模型差异、多少是样本差异，表里没有拆开。论文自己写明"因为各产品覆盖时段不同，评估数据也随之不同"。
真正稳的结论是两条，它们在样本不同的情况下仍然成立：
第一，相关没变，两端的量级被纠回来了。V2.8 的日相关也是 0.76，与 model_01 相同。变化发生在峰值偏差（−20.6% → +2.1%）与雨日偏差（+24 天 → −6.7 天）。也就是说，V3 的提升不在"雨落在哪个小时"的相关性上，而在强度与频率的标定：把峰值从低估两成拉回接近零偏差，把每年多报的二十几天雨日压到少报七天。对水文模型来说峰值最要紧，对事件识别来说雨日频率最要紧。
第二，高纬是短板，而且短板有明确来源。model_05 的峰值偏差 +8.7%、雨日偏少 13 天，明显差于中低纬栈。原因是高纬没有可用的卫星微波，只能用 ERA5 加静态因子。这不是算法问题，是观测可得性问题；它把"MSWEP 在全球均质"这个印象直接证伪。
§5 工具层：从申请到读进内存
§5.1 申请这一步，有两个硬门槛
官网的 Data access 段落写的流程很短：提交申请，回信给下载说明。表单里有五项填写（名、姓、机构、用途说明、学术邮箱）加两项勾选。
| 门槛 | 具体要求 | 后果 |
|---|---|---|
| 邮箱 | 必须是学术或工作邮箱，明确排除 Gmail、Yahoo 一类 | 个人邮箱申请会被拒 |
| 声明 | 勾选"与任何商业实体无关联"，并知悉虚假陈述可能构成违约 | 公司邮箱申请等于自证商业用途 |
还有一条使用上的小技巧写在页面里：如果之前申请过、想拿最新版本，用一个带 +标签 的别名重新提交（例如 name+abc123@domain.com）。系统按邮箱去重，别名可以绕过。
这一步没有 API，没有 token，没有可脚本化的路径。官网 FAQ 把话说明白了：非商业用户只能通过 rclone 取数，FTP 与 API 只对商业许可方开放。
§5.2 rclone 走的是共享云盘，不是对象存储
回信里给的是一个共享云盘链接。配置 rclone 时，remote 类型选 drive，认证走浏览器，不用 Shared Drive。
#1) 安装（以 Linux 为例，也可以用发行版包管理器）
curl -fsSL https://rclone.org/install.sh | sudo bash
#2) 交互式配置：n 新建 → 名称 GoogleDrive → 类型 drive → 其余回车默认
rclone config
#3) 确认能看到共享目录
rclone lsd --drive-shared-with-me GoogleDrive:
--drive-shared-with-me 这个参数不能省。共享云盘的内容不在你自己的盘里，不加这个参数，lsd 会返回空，很容易被当成权限问题，实际是路径问题。
§5.3 先算体积和文件数，再动手
§2.1 算过：历史逐小时约 40 万个文件、未压缩约 10 TB 量级。这两个数字决定了策略。
| 想要什么 | 拉哪些目录 | 文件数量级 | 说明 |
|---|---|---|---|
| 只要日尺度 | Daily |
1.7 万 | 最省，多数区域研究够用 |
| 日 + 月 | Daily + Monthly |
1.7 万 | 加 552 个月文件，几乎不增负担 |
| 要小时尺度 | Hourly |
40 万 | 必须按年、按月分批 |
| 三小时也留 | 3hourly |
13 万 | 除非要省空间，否则小时与 3 小时留一套即可 |
官网 FAQ 给的示例命令用的是排除法，一次同步日与月、跳过小时与 3 小时：
rclone sync -v \
--exclude 3hourly/ --exclude Hourly/ \
--drive-shared-with-me \
GoogleDrive:/MSWEP_V316 \
/data/mswep/V316
要取某个十年段的小时数据，用 --include 按文件名前缀过滤。文件名以 DOY 编码，所以只能按年过滤，不能按月：
#只同步 2010-2019 年的小时文件：文件名形如 2010DDD.HH.nc
rclone copy -v \
--include "201[0-9][0-3][0-9][0-9].*.nc" \
--drive-shared-with-me \
--transfers 8 --checkers 16 \
GoogleDrive:/MSWEP_V316/Past/Hourly \
/data/mswep/V316/Past/Hourly
--transfers 与 --checkers 要调高。40 万个小文件的瓶颈在请求往返，默认 4 并发会把同步拖成几小时；调到 8–16 是常规做法，但要注意云盘的日配额。
§5.4 目录树长什么样
同步下来是一棵按"版本 / 目录 / 步长 / 文件"四层排的树，另有一个元数据分支：
MSWEP_V316/
├── Past/
│ ├── Hourly/ 2020116.18.nc ...
│ ├── 3hourly/ 2020116.18.nc ...
│ ├── Daily/ 2020116.nc ...
│ └── Monthly/ 202004.nc ...
├── Past_nogauge/
│ └── (同上四层)
├── NRT/
│ └── (同上四层，另含 model_id)
└── Gauge_metadata/
├── daily_station_locations.csv
├── daily_station_date_ranges.csv
├── daily_station_reporting_times.csv
├── monthly_station_locations.csv
└── monthly_station_date_ranges.csv
Gauge_metadata 值得单独看。monthly_station_locations.csv 里的站点标识不是站号，而是 gridcell_00042230 这种形式——它指的是 0.25° GPCC 网格中的某个格，数字是该格在 720×1440 全局网格里按行主序展平的序号。也就是说，月尺度订正的"站点"实际是格点化的站点集合，不是单站坐标。想做独立验证的话，这一点必须知道：你不能拿这个文件去当"GPCC 用了哪些站"的清单。
§5.5 读进内存
netCDF-4 加 xarray 是标准搭配。下面是逐小时单文件的读法，以及把单位从"强度"转成"累积"的关键一行。
import xarray as xr
ds = xr.open_dataset("/data/mswep/V316/Past/Hourly/2020116.18.nc")
print(ds) # 维度应为 (time, lat, lon) = (1, 1800, 3600)
p = ds["precipitation"] # 单位 mm/hour
print(p.attrs.get("units")) # 确认单位，不要假设
print(float(p.max()), float(p.mean()))
#强度 -> 该小时累积：乘以 1 小时
p_mm = p * 1.0 # 数值不变，语义变为 mm
ds.close()
逐日文件读法相同，但单位是 mm/day，不需要换算。真正要小心的是不要跨步长混用：
import xarray as xr
import numpy as np
def daily_total_from_hourly(files):
"""把 24 个逐小时文件相加，得到与日文件可比的日累积（mm）。"""
tot = None
for f in files:
with xr.open_dataset(f) as ds:
v = ds["precipitation"].isel(time=0).load() # mm/hour
tot = v if tot is None else tot + v
return tot # 24 个 mm/hour 相加 = 当日 mm
这个函数之所以成立，是因为每小时的值是"该小时的平均强度"，单位为 mm/hour，数值上等于"该小时的毫米数"。如果单位是别的（例如 mm/s），就必须先换算。这就是为什么上一段代码里要打印 units 而不是假设。
§5.6 时间语义：文件名是起点，不是终点
import xarray as xr, pandas as pd
ds = xr.open_dataset("/data/mswep/V316/Past/Hourly/2020116.18.nc")
t = pd.Timestamp(ds["time"].values[0])
print(t) # 2020-04-25 18:00:00
print("该文件覆盖:", t, "至", t + pd.Timedelta(hours=1))
逐小时与 3 小时文件的时间坐标是区间起点。做日循环分析时，把 18 时文件当成"18 时观测值"和当成"17–18 时的累积"，结论会差一个小时。做暴雨峰值时刻统计时，这一个小时足以改变"峰值出现在午后还是傍晚"的判断。
§5.7 三个最小自检
拿到数据先跑三个检查，能在十分钟内发现绝大部分读错。
import xarray as xr
import numpy as np
#自检 1：全球平均日雨量应在 2.5–3.2 mm/day 量级
ds = xr.open_dataset("/data/mswep/V316/Past/Daily/2020116.nc")
p = ds["precipitation"].isel(time=0)
area_w = np.cos(np.deg2rad(ds["lat"]))
gm = float((p * area_w).sum() / area_w.sum())
print("面积加权全球均值 mm/day:", round(gm, 2))
#自检 2：先看经度约定，再抽远洋格点（0–360 与 −180–180 两种都常见）
print("lon 首尾:", float(ds["lon"][0]), float(ds["lon"][-1]))
print("lat 首尾:", float(ds["lat"][0]), float(ds["lat"][-1]))
#自检 3：不应有负值
print("最小值:", float(p.min()))
三条各自对应一类典型错误：均值在 100 上下说明单位没换算；经度从 0 排到 359.9 还是从 −179.9 排到 180，决定了切片该怎么写——按 lon=slice(180,220) 去切一个 −180–180 的数组会得到空集；出现负值说明读的不是降水字段，或者文件损坏。
要确认"含海洋"，抽一个远离大陆的格点看年累积即可：北太平洋中部与南印度洋的年雨量都在数百毫米到一千余毫米之间，若读到 0，说明拿到的是只含陆地的旧版本或读错了字段。
§5.8 把取数过程固化成一条记录
可复现的难点不在代码，在"当时拉的是哪一份"。建议每次取数落一条这样的记录：
dataset: MSWEP
version: V3.16
folder: Past
resolution: hourly
period: 2010-01-01/2019-12-31
retrieved: 2026-03-04
remote: GoogleDrive:/MSWEP_V316
excluded: [Past_nogauge, NRT]
notes: 未使用 NRT；未做站点订正外的任何后处理
六个字段里，version 与 retrieved 是不可省的。前者决定算法代际，后者决定近实时文件有没有被重写过。§1.5 的案例正是缺了这两个字段的后果：一条 1980–2020 的曲线，只要当时多记一行版本号，看到台阶的当天就能查到官方说明，而不必等到投稿被问起。
§6 它在库里的位置
§6.1 三件地学底子
库内的地学条目目前有三件：ERA5 单层再分析、GHCNd 全球逐日气候观测、以及这一条。三者不是竞争关系，而是一条链上的三个环节。
| 条目 | 角色 | 与 MSWEP 的关系 |
|---|---|---|
| ERA5 单层再分析 | 大气状态的连续场 | MSWEP 的输入之一（降水与气温），也是它的对照基准 |
| GHCNd | 站点真值 | MSWEP 的订正与验证来源之一，也是独立评估的对照 |
| MSWEP | 降水专项融合产品 | 把前两者的长处合起来，代价是时间分辨率之外的误差结构更复杂 |
§6.2 与 ERA5 的分工，容易被说反
常见说法是"MSWEP 比 ERA5 准，所以用 MSWEP 替掉 ERA5"。这句话在降水这一项上大致成立，在别的项上一句都不成立。
分工的实际边界是：
| 需求 | 用哪个 | 理由 |
|---|---|---|
| 降水强度与极端值 | MSWEP | 峰值偏差 +2.1% 对 −17.5%，量级差一档 |
| 气温、风、湿度、辐射 | ERA5 | MSWEP 只有降水一个字段 |
| 1950 年代的降水 | ERA5 | MSWEP 从 1979 年起 |
| 商业产品供数 | ERA5 | CC BY 4.0，无 NC 限制 |
| 海洋降水 | MSWEP | 站点无法覆盖，ERA5 降水在海上更依赖模式 |
一句话：降水这专项，MSWEP 更好；但只要项目里出现降水和气温同时用，两套数据都在，就要处理网格与时间轴的两次对齐。
§6.3 与 GHCNd 的互补
GHCNd 是站点库，MSWEP 是格点库。做验证时的正确姿势是：用 GHCNd 的站去比 MSWEP 的格，而不是用 GHCNd 去替 MSWEP。两者的差别是代表性问题——一个站在一个点上，一个格是 11 公里见方的平均。
还有一层更细的关系：MSWEP 的订正用到了 GHCN-D（文档列的站点来源里有它）。如果拿 GHCN-D 的站去评估 MSWEP 的订正版，就是循环论证。要评估，就得用未订正的 Past_nogauge，或者用被排除在订正之外的站。这一条与 §3.4 讲的是同一件事，只是换了个方向看。
§7 质量评估与局限：它不该按什么尺子量
§7.0 阅读本节前需要知道的一件事
用"观测数据集"的尺子量它，会得出"没有一个数是真测的、全是模型输出"的结论；用"AI 基准"的尺子量它，会得出"没有划分、没有标签、没有排行榜"的结论。两种结论都对，都没有回答它为什么被用。
它被用的理由只有一个：在 1979 年至今、全球、逐小时这三个条件同时成立的前提下，它在多数地方比任何单一来源都更接近站点读数。 这是一句有条件的判断，条件里每一项都不能省。去掉"1979 年至今"，IMERG 更好；去掉"全球"，区域产品更好；去掉"逐小时"，一堆日尺度产品更好。
所以评价它该用的尺子是：这个"多源融合"的收益，在哪些尺度、哪些地区、哪些年份上成立，在哪些地方不成立。 本节就按这个尺子走。
§7.1 三种常见的评价框架错位
| 错位 | 表现 | 该怎么想 |
|---|---|---|
| 把它当纯观测 | 抱怨"没有一个格点值是雨量计读数" | 融合产品的价值在于误差结构，不在于单点溯源；单点溯源要看 Past_nogauge 与站点 |
| 把它当基准答案 | 直接拿它做机器学习的标签，再报验证集精度 | 标签本身带误差，且误差在训练区与验证区不同；至少要报"标签误差的量级" |
| 把它当全球均质 | 用一个全球中位 KGE 概括全部 | 官方自己的表里，高纬栈的峰值偏差是中低纬栈的四倍（+8.7% 对 +2.1%） |
第三种错位最普遍。一个 0.69 的中位 KGE 看似"还不错"，但它是一个中位数——一半的格点比它好，一半比它差，而差的那一半往往集中在山区、高纬、荒漠。区域研究若不查本地的分层结果，就等于用一个平均数替自己的研究区做了决定。
§7.2 DAIMS 二十四项逐条对照
DAIMS 原本是社会科学调查数据的质量框架，这里借它的二十四项检查点，把这份数据在元数据与可追溯性上的成熟度摊开。
| # | 检查项 | 状态 | 说明 |
|---|---|---|---|
| 1 | 宽格式 | ⚠️ | 网格场不是表格，要先降维或切片 |
| 2 | 标准记录层级 | ✅ | 格 × 时，无嵌套歧义 |
| 3 | 变量名与定义 | ✅ | 只有一个 precipitation，定义清楚 |
| 4 | 变量与问题匹配 | ✅ | 降水是水文、农业、健康共同需要的变量 |
| 5 | 分类与编码 | ✅ | 不涉及 |
| 6 | 数据源 | ✅ | 六路动态输入、六个静态预测因子逐项列明 |
| 7 | 采集方式与工具 | ✅ | 算法有同行评议长文，四子模型结构公开 |
| 8 | 采集时间 | ✅ | 区间起点语义明确 |
| 9 | 代理变量 | ⚠️ | 卫星反演本身是代理量，冷季与地形处偏差大 |
| 10 | 权重 | ⚠️ | V3 无显式权重，替代物是模型栈编号；无法从数据反推权重 |
| 11 | 缺失值编码 | ⚠️ | 无显式缺测标记；model_id 部分承担了"状态"角色 |
| 12 | 数据质量声明 | ⚠️ | 有版本级说明，无逐格质量标记 |
| 13 | 元数据完整性 | ✅ | netCDF-4 自描述，站点附表齐全 |
| 14 | 时间覆盖 | ✅ | 1979 至今，连续 |
| 15 | 空间覆盖 | ✅ | 全球含海洋 |
| 16 | 地理参照 | ✅ | 固定 0.1° 网格 |
| 17 | 记录完整性 | ⚠️ | 同质性随输入换代而变，非均匀 |
| 18 | 计数 | ✅ | 格数、时刻数、文件数皆可精确计算 |
| 19 | 文件大小 | ⚠️ | 文档未公布单文件体积，只能按维度估 |
| 20 | 数据存储 | ⚠️ | 共享云盘分发，非长期存档库；无 DOI |
| 21 | 数据处理 | ✅ | 四级步长、两级订正均有文档 |
| 22 | 数据访问 | ❌ | 人工审批，无匿名与脚本化通道 |
| 23 | 许可与使用限制 | ✅ | CC BY-NC 4.0，原文可读，商用路径明确 |
| 24 | 引用与致谢 | ⚠️ | 有 arXiv DOI，但无数据集级 DOI |
标❌与⚠️的十项，集中区很清楚：访问、存档、逐格质量。这三项恰好是"运营型产品"与"存档型数据集"的分野——它按服务的方式活着，不按档案的方式活着。
§7.3 逐条局限
长序列有台阶。 见 §1.5 的案例与 §4.7。这不是缺陷报告，是官方自己写在版本说明第一段的内容，且给出了替代方案。
高纬明显更弱。 卫星微波在高纬失效，只剩 ERA5 一条腿。高纬研究若报一个全球统一精度，等于把一个已知的系统性差异藏起来。
山地与积雪区系统性偏低。 官方不做接水量校正，理由写在 FAQ 里：使用者更希望数据与站点读数一致。这句话的意思是——站点本身也偏低（风损、未修正的固态降水），MSWEP 选择跟随站点，而不是追随"真实落水量"。需要后者，用 PBCOR。
日尺度订正的改进幅度有限。 论文用留一交叉验证给出：日尺度站点订正把日中位相关提高了 0.09。0.09 不算小，但它是在一个已经不低的基线上加的——基线本身已经把大部分信号抓住了。
近实时不可复现。 十天窗口内的文件会被重写，model_id 会变。用今天的 NRT 数据做的实验，一周后重跑可以不一致。
无数据集级 DOI。 引用指向论文，而不是数据。这对"引用即定位"的规范是个缺口：论文不区分 V3.15 与 V3.16。
许可与访问是两套规则。 见 §8.5。
0.1° 是硬下限。 11 公里在赤道，在 60°N 东西向只有约 5.5 公里，但仍是公里级。城市内涝、山坡地形雨、对流单体落区，都不在这个尺度上。
§7.4 该追问什么，不该追问什么
该追问的：某个版本在你的研究区、你的时间尺度上的分层误差；输入源换代的年份；订正站点的空间覆盖；model_id 的定稿比例。
不该追问的：为什么没有逐格误差条、为什么没有训练测试划分、为什么单格值与单站读数不完全相等。这三件事不在它的设计目标里——它是原料，不是考卷。
§7.5 外部验证：三条路径各自回答什么
| 路径 | 回答什么 | 需要的对照 | 注意 |
|---|---|---|---|
| 对独立站点 | 格点值与该地点仪器差多少 | 未参与订正的站（或用 Past_nogauge） |
必须按报告时刻对齐，否则误差被人为放大 |
| 对水文模型 | 作为强迫，能不能复现流量 | 流域出口的流量序列 | 这是"用途相关"的验证，比逐点相关更贴近实际价值 |
| 对其他融合产品 | 大尺度形势是否一致 | IMERG、ERA5、CHIRPS | 一致不代表对，只代表误差同源 |
第一条最常用，也最容易做错。正确做法不是"逐点算均方根然后报一个数"，而是分气候区、分季节、分时段报偏差结构。论文自己就是这么做的：留一交叉验证、分位数偏差、雨日频率、CSI 一起报，而不是一个 KGE 了事。
第二条在文献里有现成做法：把不同降水产品分别驱动同一个水文模型，比校准后的 NSE。这条路的价值在于它衡量的是"作为输入的可用性"，而不是"作为数值的准确性"。一份在站点上偏差不大、但在时间上错位一小时的产品，逐点相关可能不错，驱动水文模型却会明显变差。
§8 版本与生态：它为什么能一直跑下去
§8.1 版本时间线
| 版本 | 日期 | 关键变化 |
|---|---|---|
| 1.0 | 2016-05-30 | 首发，3 小时 / 0.25°，七源加权 |
| 1.1 | 2016-08-02 | 变量顺序改为 time-lat-lon；修正日数据时间偏移 |
| 1.2 | 2016-11-28 | 试验性海洋降水；卫星阈值提到 5℃ |
| 2.0 | 2017-07-23 | 0.25° → 0.1°；纳入海洋；GridSat 红外补 2000 年前 |
| 2.1 | 2017-11-20 | 移除 NCEP-CFSR；恢复 GPCC 月订正 |
| 2.2 | 2018-03-02 | 修正 CDF 校正放大趋势的问题 |
| 2.8 | 2021-02-14 | 五源精简为 ERA5 + IMERG；权重图改用随机森林；四气温带 |
| 3.15 | 2025-07-29 | 机器学习算法；P-CCS-CDR 替 GridSat；PDIR-Now 接入；延迟降到 2 小时 |
| 3.16 | 2026-02-01 | 修复 V3.15 的日订正被月订正覆盖、OI 负权重导致异常大值 |
这张表里能看出一条规律：每次大版本都在换输入源，每次换输入源都会留下接缝。 2.0 换分辨率与海洋，2.8 把五源砍成两源，3.15 引入机器学习与新的红外源。接缝的处理方式也在进步——2.2 修的是 CDF 校正放大趋势，3.16 修的是订正顺序被覆盖。这些都不是"精度又高了"式的宣传，是具体的实现错误被逐个找出来。
§8.2 生态位：一家小机构的产品线
GloH2O 是一家公司，不是政府机构，也不是大学实验室。站点页脚写着注册地与美国地址，产品线八条：
| 产品 | 是什么 | 与 MSWEP 的关系 |
|---|---|---|
| MSWEP | 降水融合 | 本篇 |
| MSWX | 气象要素集 | 用 MSWEP 作参考 CDF，两者一致 |
| PBCOR | 偏差校正降水 | 补 MSWEP 不做接水量校正的缺口 |
| GSCD | 全球次日尺度气候数据 | 同源方法 |
| HBV | 水文模型 | 下游应用 |
| Köppen-Geiger | 气候分类 | 下游派生 |
| PPDIST | 降水分布 | 下游派生 |
| GloH2O API | 商业接口 | 商业许可方的取数通道 |
这张表说明了它为什么能持续：它不是一份孤立的开源数据，是一条产品线的入口。 降水是上游，气象、偏差校正、水文模型、气候分类是下游。上游免费给学术用，下游卖服务——这个结构决定了两件事：非商业许可可以一直免下去，而近实时系统必须一直跑。
§8.3 谁在依赖它
官网页面上有一节专门列出使用机构，以机构标识的形式呈现，没有逐一点名。可核实的外围证据在论文里：MSWEP 被多个独立评估研究用作对照产品，其中一项覆盖 23 个格点降水产品、16,295 个流域。被当成"对照组"这件事本身说明了它的地位——它已经是这个领域里的默认参照之一。
依赖的强度可以从一个细节看出来：多个下游产品（MSWX 的参考 CDF、PBCOR 的基底）在方法上直接绑定了 MSWEP 的分布。这种绑定意味着换版本会连带影响下游，所以版本冻结对它是刚需，不是选项。
§8.4 为什么能持续：三件支撑
第一，运维被显式设计。 站点有一个 system status 页，实时显示近一周的 MSWEP-NRT 与四路输入（ERA5、GDAS、GSMaP、IMERG）的到位情况，以及近两个月的逐日在线率。把运维状态公开到"哪一天掉了多少"的粒度，是一件需要长期投入的事，也是一份数据能被当成基础设施用的前提。
第二，商业许可反哺免费层。 非商业用户走人工申请加 rclone，商业用户走 API 与 FTP。后者的收入支撑前者的服务器与人力。这个模式在学术数据里不常见，但它解释了为什么一份 CC BY-NC 的产品能从 2016 年一路更新到今天。
第三，作者团队与用户群重叠。 方法学论文的作者里，既有做全球水文评估的，也有做业务预报的。这意味着需求不是猜的，是自己要用的。
§8.5 许可的两层结构，值得单独说
官方有两处许可文本，指向不完全一致。
文档 §2 的原文是：MSWEP 以知识共享 署名—非商业性使用 4.0（CC BY-NC 4.0）分发，允许为非商业目的使用、共享与改编，条件是按要求引用；商业用途须另行联系取得许可。随后逐条列出四类非商业（学术研究、非营利科研、个人使用、政府与非政府组织的非创收项目）与四类商业（营利公司内的任何使用、咨询与合同研究、嵌入商业产品、付费墙服务）。
站点条款第 5.2 条则写：授予一项有限的、非独占的、不可转让的、可撤销的许可，用于个人、教育或非商业目的。
两处并置会看到一处张力：CC BY-NC 4.0 的授权一旦给出即不可撤销，而站点条款保留了撤销权。实践上的含义是——引用与使用时以文档的 CC 条款为准，但访问资格受站点条款约束。换句话说，你的使用权来自 CC，你的下载权来自那份可撤销的账号式许可。
还有一条容易踩的边界：公司内部研究也算商业。 文档把"营利公司内的任何使用，即使仅限内部研究"明确列入商业类。这与很多人的直觉相反——不是"没对外发布就不算商用"。
§9 使用指引：三类角色，三条路
§9.1 三种角色
| 角色 | 典型任务 | 建议路径 |
|---|---|---|
| 水文/气候研究者 | 长序列驱动模型、算趋势 | V2.80 做趋势，V3.16 做事件；两者不要混在一条曲线上 |
| 机器学习工程师 | 造样本、做时空预测 | Past 逐小时，按年份分片；标签误差要单独报 |
| 业务/预警开发者 | 近实时监测 | NRT，按 model_id 过滤，接受十天重写 |
第一类角色的忌讳最具体：V2.80 是 3 小时步长，V3.16 是逐小时，两条序列在日尺度上可以合并，在小时间尺度上不能。
§9.2 在 AI 流水线中的位置
MSWEP 在流水线里通常占三个位置之一：输入协变量（给别的模型提供降水背景）、监督标签（训练降水降尺度或预报模型）、评估基准（检验别的产品）。
第三个位置有一个反直觉的陷阱：如果被评估的模型是用 MSWEP 训练的，再用 MSWEP 评估它，得到的是自洽性，不是精度。这在近年大量"降水降尺度"论文里是常见问题——训练标签与评估真值同源，模型学到的是 MSWEP 的纹理，不是降水的物理。
正确做法是至少留一层独立：训练用 MSWEP，评估用站点；或者训练用 Past_nogauge，评估用 Past。
§9.3 一份最小可跑的组装
下面的脚本把"版本 + 目录 + 年份"三个变量显式化，避免路径写死。
from pathlib import Path
import xarray as xr
VER = "MSWEP_V316"
FOLDER = "Past" # 或 Past_nogauge
YEAR = 2019
ROOT = Path("/data/mswep")
files = sorted((ROOT / VER / FOLDER / "Daily").glob(f"{YEAR}*.nc"))
print("文件数:", len(files)) # 平年 365，闰年 366
ds = xr.open_mfdataset(
[str(f) for f in files],
combine="by_coords",
chunks={"time": 30},
)
p = ds["precipitation"] # mm/day
print(p.shape, p.attrs.get("units"))
print("年降水面积加权均值:", float(
(p.mean("time") * __import__("numpy").cos(
__import__("numpy").deg2rad(ds["lat"]))).sum()
/ __import__("numpy").cos(__import__("numpy").deg2rad(ds["lat"])).sum()
))
open_mfdataset 的 combine="by_coords" 依赖每个文件自带正确的时间坐标。如果从别处拷来的文件时间属性被改过，这一步会静默错序——所以更稳的写法是先 open_dataset 单个文件、确认 time 再批量。
§9.4 评估时最少要报三件事
| 要报的 | 为什么 | 不报会怎样 |
|---|---|---|
| 版本号与目录 | 决定算法与订正 | 别人无法复现 |
| 分层结果（气候区 / 季节 / 时段） | 误差不是均匀的 | 一个中位数掩盖了山区与高纬的失效 |
| 与站点的报告时刻对齐方式 | 不对齐会人为压低相关 | 结论偏向"产品更差"，且偏差量不可知 |
第三项最容易被跳过，也最容易补救：拿到站点日量后，先查 daily_station_reporting_times.csv，按偏移把格点序列平移再比。没有这张表，就自己按 §4.6 的方法推断。
§10 AI 使用声明
| 栏目 | 内容 |
|---|---|
| 性质 | 多源融合的格点降水估计，含卫星反演与模式输出分量，非纯观测 |
| 用途 | 水文与农业模型强迫、环境协变量、降水降尺度与预报模型的标签、产品间对照 |
| 不建议用途 | 商业产品供数（未另签）、单城市或单坡面事件判定、跨 2000/2015 直接比趋势、把近实时值当定稿值 |
| 伦理 | 无个人数据；若下游连到健康或粮食安全结局，注意区域均值与个体暴露之间的生态谬误 |
| 引用 | Wang et al. (2026), arXiv:2602.01436，并注明所用版本号 |
| 许可 | CC BY-NC 4.0；商业用途（含公司内部研究）须另签 |
| 版本 | 版本号 + 目录 + 取数日三项齐备 |
| 状态 | 在线，逐小时更新，历史部分按版本冻结 |
§11 常见误读与避坑清单
| 常见说法 | 实际情况 | 证据 |
|---|---|---|
| 「MSWEP 是雨量站插值」 | 站点只是三个来源之一，且 V3 里它以训练标签与订正因子的身份出现，不以"场"的身份参与 | 文档 §4 列出 ERA5、三路卫星与多源站点 |
| 「有 CC 许可就能随便用」 | 许可是非商业的，公司内部研究也算商业 | 文档 §2 商业用途四条，第一条即"营利公司内的任何使用" |
| 「官网说 70,000 个站，所以订正用了 7 万站」 | 日订正 57,666 站，月订正背后约 86,000 站，训练用 31,917 站；70,000 是合并口径 | 论文 §2.2 与官网 Gauge-corrected 段 |
| 「逐小时和逐日是同一份数据的不同抽样」 | 单位不同：前者 mm/hour，后者 mm/day，同名同形 | 文档 §6 单位列表 |
| 「V3 比 V2 全面更强」 | 日相关没变（都是 0.76），改进集中在峰值偏差与雨日频率 | 论文表 3 两行对照 |
| 「MSWEP 全球均质，一个 KGE 能用」 | 高纬栈峰值偏差 +8.7%，是中低纬栈的四倍 | 论文表 3 |
| 「近实时两小时延迟，所以两小时后就定了」 | 十天内的文件持续重写，model_id 会变 |
文档 §5、§6 |
| 「文件名里的 116 是月份日期」 | 是年积日（DOY），2020116 即 4 月 25 日 | 文档 §6 命名规则与示例 |
| 「月度订正用的是单站坐标」 | GPCC 格点化，标识是 0.25° 网格展平序号 | 文档 §7 |
| 「数据有 DOI，可以按 DOI 引用」 | 无数据集级 DOI，只有论文 DOI，不区分次版本 | 文档 §3 引用要求，鼓励注明版本 |
附录 A 速查卡
| 键 | 值 |
|---|---|
| 产品 | MSWEP V3.16 |
| 维护方 | GloH2O LLC |
| 覆盖 | 1979-01-01 至约两小时前 |
| 步长 | 逐小时 / 3 小时 / 逐日 / 逐月 |
| 空间 | 0.1°，1800×3600，含海洋 |
| 字段 | precipitation（单位随步长）；NRT 另有 model_id |
| 格式 | netCDF-4 |
| 目录 | Past / Past_nogauge / NRT / Gauge_metadata |
| 访问 | 申请 → 邮件 → rclone（共享云盘） |
| 许可 | CC BY-NC 4.0 |
| 引用 | Wang et al. (2026), arXiv:2602.01436 |
附录 B 文件命名与规模对照
| 步长 | 文件名式样 | 时间语义 | 历史文件数 | 单位 |
|---|---|---|---|---|
| 逐小时 | 2020116.18.nc |
18:00–19:00 UTC | 403,248 | mm/hour |
| 3 小时 | 2020116.18.nc |
18:00–20:59 UTC | 134,416 | mm/3-hour |
| 逐日 | 2020116.nc |
当日 00–24 UTC | 16,802 | mm/day |
| 逐月 | 202004.nc |
当月 | 552 | mm/month |
附录 C 术语表
| 术语 | 含义 |
|---|---|
| 融合产品 | 把两类以上来源的估计按某种规则合成的数据产品 |
| 模型栈 | 一组按尺度串联的子模型；本产品中一个栈含四个子模型 |
| 参考栈 | 用于对齐其他栈输出的基准组，本产品中低中纬为 01、高纬为 05 |
| CDF 匹配 | 把一列数的分布强行映射到另一列数的分布，保持秩不变 |
| 最优插值 | 按距离与相关结构给观测分配权重的方法，能处理观测间相关 |
| 相关长度 | 降水在空间上还能算"相关"的距离尺度，随降水类型变 |
| 报告时刻 | 一个站点的日累积在哪个时刻截止，全球并不统一 |
| 年积日 | 一年中的第几天，1–366，文件名用它而非月日 |
| 接水量校正 | 修正雨量计因风、蒸发、固态降水造成的系统性偏少 |
| 解集 | 把粗时间分辨率估计拆到细分辨率的过程 |
| 峰值偏差 | 高分位估计值相对观测的百分比偏差 |
| 雨日偏差 | 一年中有降水日数的差，反映毛毛雨虚假频率 |
| 留一交叉验证 | 每次留一个站做验证、其余做订正，用于评估订正增益 |
| 定稿值 | 近实时流中与历史产品一致的值，由 model_id 标记 |
| 数据同化 | 把观测与模式背景场结合成分析场的方法 |
| 再分析 | 用固定模式版本把历史观测重处理成连续场 |
| 生态谬误 | 用区域平均关系推断个体层面关系的错误 |
| 可复现性 | 同一份输入在另一时间另一个人手上能得到同一结果 |
附录 D 常见问题
Q1：MSWEP 和 IMERG 该选哪个？ 要 2000 年之前，只能 MSWEP。要 2000 年之后且许可宽松，IMERG 足够。要长序列且能接受非商业限制，MSWEP 的日尺度更稳。
Q2：为什么官网上 MSWEP-NRT 的分数比 Past 高？ 网页柱状图给的是 0.77 与 0.69，但两列的评估样本不同，页面没有说明。论文表 3 里同一组模型的分数分布在 0.58–0.78，各行检验站数从 9,370 到一万四千余站不等。跨列比较不成立。
Q3：能不能只用一天的文件做一个城市的图？ 能画，但那一格是 11 公里见方，城市内部的差异被平均掉了。做城市尺度结论需要降尺度。
Q4：为什么我算的全球平均是 100 多？ 单位没换算。逐小时是 mm/hour，乘 24 或改用日文件。
Q5：Past_nogauge 能不能直接当成品用？ 官方限定两个用途：评估基线、算近实时异常。做水文建模应当用 Past。
Q6：拿到的是 V3.15 怎么办？ 官方在 V3.16 说明里建议：V3.15 的日订正被月订正覆盖，日间变率在站点密集区不可靠；要最高精度历史数据，改用 V2.80 或 V3.16。
Q7：能不能商用？ 不能直接用。文档明确列出四类商业用途，含公司内部研究；需联系取得单独许可。
Q8：为什么没有逐格误差？ 它不是存档型数据集，没有做逐格不确定度传播。误差信息只到"分模型栈、分区域"的层级。
编辑说明
核验时间 2026-10-29。方法：读取官网 MSWEP 页全文（含 Data access、Frequently asked questions、Performance comparison 三段），取其覆盖、延迟、站点数、许可与申请流程口径；下载并通读官方文档 GloH2O_MSWEP_Documentation.pdf（V3.16，封面 2026-02-06，共 11 页），取目录结构、文件命名、单位、model_id 语义、站点附表说明与完整版本史；下载 arXiv 2602.01436 全文 HTML，取模型栈结构、静态/动态预测因子、站点数量分项、表 3 的独立检验数值与留一交叉验证结论；读取站点条款页第 5 条，取"可撤销许可"原文。未提交数据申请，未登录共享云盘，未下载任何数据文件，因此正文中的体积、文件数均为按官方维度与命名规则的算术推算，文中已逐处标注"推算"；未做任何格点级分布统计。
三处已知的官方口径不一致，均在正文原位标注：文档封面日期（2026-02-06）与版本史日期（2026-02-01）；官网正文延迟（2 小时）与 FAQ 延迟（约 3 小时）；文档正文的 V2.80 与版本史的 Version 2.8。另有一处文档可读性问题：其模型栈表用 3/7 标记可用性而无图例，正文按 model_18 与 §5 叙述反推并已说明推断依据。
未覆盖内容：Past 目录的实际文件清单与单文件体积（需登录）、model_id 各值在全球的实际占比、各气候区的分层误差（论文未按区给出）。
相关数据集导航
以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集，按相关度降序排列：
- wpp — 共享标签：公共卫生与流行病学 / 时序数据 / 全球健康 / 公共卫生统计
- usgs-comcat — 共享标签：公共卫生与流行病学 / 时序数据 / 全球健康 / 公共卫生统计
- who-gho — 共享标签：公共卫生与流行病学 / 时序数据 / 全球健康 / 公共卫生统计
- our-world-in-data — 共享标签：公共卫生与流行病学 / 时序数据 / 全球健康
- human-mortality-database — 共享标签：公共卫生与流行病学 / 全球健康 / 公共卫生统计
- ghcn-daily — 共享标签：公共卫生与流行病学 / 时序数据 / 全球健康
- cmip6-esgf — 共享标签：公共卫生与流行病学 / 时序数据 / 全球健康
- hfa-europe — 共享标签：公共卫生与流行病学 / 时序数据 / 公共卫生统计
- ghdx — 共享标签：公共卫生与流行病学 / 全球健康 / 公共卫生统计
- gbd-results — 共享标签：公共卫生与流行病学 / 全球健康 / 公共卫生统计
导航说明：本章节由全站统一标签体系自动计算生成（标签重合度算法），双向可达；点击链接可跳转至对应数据集词条。
