企业官网建设流程全解析

1. 项目概述：为什么ERA5小时级数据值得花时间批量下载与处理？

做气象、气候、能源或环境建模的朋友，大概率都绕不开ERA5——这是欧洲中期天气预报中心（ECMWF）发布的全球再分析数据集，空间分辨率0.25°×0.25°，时间覆盖1940年至今，每小时一帧，变量超50个（温度、湿度、风速、辐射、降水、位势高度……）。它不是卫星原始观测，也不是模式实时预报，而是把海量地面站、探空、卫星、飞机报等异构观测数据，用四维变分同化方法“反演”进高分辨率数值模型里，生成的一致、连续、物理自洽的全球大气状态场。简单说：它是目前最权威、最完整、最易获取的“地球历史天气录像带”。

但问题来了——你真去ECMWF官网点选下载，会发现：单次请求最多只能下1个月、1个变量、1个层级的数据；想下2015–2023年全球地表气温逐小时数据？得手动点选8年×12月×24小时=2304次，还要反复填表单、等邮件确认、手动解压、重命名、拼接nc文件……这根本不是科研，是体力劳动。更糟的是，官方Web API（CDS API）虽支持脚本调用，但默认限流严格（每分钟最多3个请求）、配额有限（免费用户每月50GB）、且对并发和错误重试极不友好。我去年帮一个风电功率预测团队搭数据流水线，光调试下载逻辑就花了3天，中间因API返回空文件、token过期、服务器503、nc文件header损坏等问题反复重跑17次。

这时候，“ERA5 hourly data批量下载与cdo处理”就不是锦上添花，而是刚需。它本质是一套可复用、可监控、可回溯的数据工程闭环：从认证→参数化请求→断点续传→校验解压→格式统一→变量裁剪→时间聚合→空间插值→元数据标准化，全部用命令行+脚本驱动。而cdo（Climate Data Operators）就是这个闭环里的“瑞士军刀”——它不依赖Python环境，内存占用低，支持流式处理，单条命令就能完成nc文件的合并、筛选、计算、重采样、单位转换。比如cdo mergetime *.nc -O merged.nc5秒合并100个文件；cdo sellonlatbox,-10,30,20,50 in.nc out_subset.nc一行切出中国区域；cdo timmean -tstep,24 in.nc daily_mean.nc直接算日均值——这些操作若用xarray写Python脚本，代码量翻3倍，运行时间多2倍，还容易因dask调度失败中断。

所以这篇不是教你怎么点鼠标，而是带你亲手搭一条“ERA5小时数据自动流水线”。它不依赖任何图形界面，全程Linux终端操作；所有脚本可直接复制粘贴运行；每个参数都有物理意义解释（比如为什么time要拆成year/month，为什么grid_mapping必须保留）；所有坑我都踩过——包括CDS API返回的nc文件缺time_bnds、cdo在Ubuntu 20.04上因netCDF库版本冲突报错、Windows子系统WSL2中curl证书验证失败……这些细节，文档不会写，但实操时能让你少熬3个通宵。

适合谁看？

• 气象/水文/能源领域研究生，正为毕业论文准备长序列驱动数据；
• 环境咨询公司工程师，需定期更新城市热岛分析的历史基线；
• 风光功率预测算法工程师，要构建过去5年逐小时NWP偏差数据库；
• 地理信息系统（GIS）从业者，需将ERA5格点数据转为GeoTIFF供ArcGIS调用。
  只要你需要稳定、可重复、可审计地获取ERA5小时级数据，这篇就是你的第一份工程手册。

2. 整体架构设计：为什么选择CDS API + Bash + cdo组合而非Python全栈？

很多人第一反应是：“Python不是有cdsapi、xarray、netCDF4吗？写个for循环不就完了？”——理论上可行，但实操中会撞上三堵墙：稳定性墙、资源墙、可维护性墙。我用Python全栈方案跑过2TB ERA5数据（1979–2022全球2m气温），结果如下：

所以最终架构定为三层流水线：
第一层：认证与请求层（Bash + curl）
不用Python的cdsapi库，改用ECMWF官方推荐的curl方式调用CDS API。原因很实在：cdsapi本质是封装curl，但封装后丢失了对HTTP状态码、重试策略、响应头的精细控制。而我们用curl -X POST -H "Authorization: Bearer ${TOKEN}" --data-binary "@request.json" https://cds.climate.copernicus.eu/api/v2/resources/...，可以精确捕获HTTP 429 Too Many Requests并sleep 60秒，可以检查Content-Length是否为0（空响应），可以保存原始response body用于debug。更重要的是——所有操作都在shell里，没有Python环境污染风险。

第二层：数据质检与预处理层（Bash + md5sum + cdo）
下载完的.nc文件不是直接扔进分析流程。先做三件事：①md5sum校验（ECMWF提供每个文件的MD5哈希，下载后比对防传输损坏）；②cdo -s infov file.nc快速读取文件头，验证time维度长度是否匹配请求（比如请求30天应有720个时间步，少于718个即为残缺）；③cdo sinfov file.nc \| grep -E "lon|lat|time"提取坐标范围，确保没下错区域。这三步加起来不到0.5秒/文件，却能避免后续数小时的无效计算。

第三层：核心处理层（cdo单命令链）
这才是cdo的真正价值区。它不像Python需要写循环读写，而是把nc文件当“流”处理：输入是文件路径，输出是新文件，中间所有操作（merge、sellatlon、timmean、remapbil）都在内存buffer里完成。比如处理中国区域逐小时2m气温，典型命令链是：

cdo -O -z zip_3 merge $(ls era5_2mtemp_2020*.nc) temp_merged.nc && \ cdo -O sellonlatbox,-10,130,0,60 temp_merged.nc temp_china.nc && \ cdo -O timmean -tstep,24 temp_china.nc temp_china_daily.nc && \ cdo -O setgridfile,china_grid.txt temp_china_daily.nc temp_china_daily_regrid.nc

注意-O强制覆盖输出，-z zip_3用zlib level 3压缩节省50%空间，-tstep,24指定按24步聚合（即日平均），setgridfile用外部网格定义文件实现自定义重采样——这些参数背后都有物理约束：比如timmean必须保证输入文件时间轴严格连续（否则cdo报错），sellonlatbox的经纬度范围必须与原始网格对齐（否则插值失真），这些细节我会在后续章节展开。

选择这套组合，本质是用最简工具链解决最痛问题：下载要稳，处理要快，维护要省。Python适合做复杂统计建模，但不适合做数据搬运工；而cdo就是专为搬运设计的重型卡车——它不炫技，但拉得动、跑得稳、修得快。

3. 核心细节解析：CDS API认证、请求构造与下载脚本实操

3.1 获取并安全存储CDS API密钥

ECMWF要求所有CDS API调用必须携带Bearer Token，该Token由你的CDS账户生成，形如xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx。获取路径：登录 Climate Data Store → 右上角头像 → “User Profile” → “API key” → 点击“Show API key”。关键警告：绝对不要把Token硬编码在脚本里！我见过太多人把Token传到GitHub导致账号被盗，ECMWF会立即封禁该Token并追溯所有下载记录。

正确做法是创建凭证文件~/.cdsapirc（Linux/macOS）或%USERPROFILE%\cdsapirc（Windows），内容为：

url: https://cds.climate.copernicus.eu/api/v2 key: 12345:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

其中12345是你的UID（在API key页面URL中可见，如https://cds.climate.copernicus.eu/user/12345），冒号后是Token。然后设置权限：

chmod 600 ~/.cdsapirc # Linux/macOS icacls "%USERPROFILE%\cdsapirc" /inheritance:r /grant:r "%USERNAME%":F # Windows

这样curl就能自动读取：curl --config ~/.cdsapirc ...。如果必须用环境变量（如CI/CD场景），则用export CDSAPI_KEY="12345:xxx"，并在脚本开头加if [ -z "$CDSAPI_KEY" ]; then echo "ERROR: CDSAPI_KEY not set"; exit 1; fi。

3.2 构造符合ERA5规范的JSON请求体

ERA5小时数据分多个数据集（dataset），最常用的是reanalysis-era5-single-levels（近地面变量）和reanalysis-era5-pressure-levels（气压层变量）。请求体必须严格遵循schema，漏掉一个字段或类型错误都会返回400 Bad Request。以下载2020年全球2m气温为例，request.json内容如下：

{ "format": "netcdf", "product_type": "reanalysis", "variable": ["2m_temperature"], "year": ["2020"], "month": ["01", "02", "03", "04", "05", "06", "07", "08", "09", "10", "11", "12"], "day": ["01", "02", "03", "04", "05", "06", "07", "08", "09", "10", "11", "12", "13", "14", "15", "16", "17", "18", "19", "20", "21", "22", "23", "24", "25", "26", "27", "28", "29", "30", "31"], "time": ["00:00", "01:00", "02:00", "03:00", "04:00", "05:00", "06:00", "07:00", "08:00", "09:00", "10:00", "11:00", "12:00", "13:00", "14:00", "15:00", "16:00", "17:00", "18:00", "19:00", "20:00", "21:00", "22:00", "23:00"], "area": [90, -180, -90, 180], "grid": [0.25, 0.25] }

逐字段说明：

• "format": "netcdf"：必须小写，不能写"NetCDF"或"nc"，否则返回400；
• "area": [N, W, S, E]：北极在前，南极在后，西经为负，东经为正。[90,-180,-90,180]即全球，[50,70,15,140]即东亚（注意顺序是北纬、西经、南纬、东经）；
• "grid": [0.25, 0.25]：明确指定分辨率，否则默认0.5°，且无法与0.25°数据混用；
• "day"数组必须包含所有日期，即使某月只有30天，也要写"31"（ERA5会自动忽略不存在的日期）；
• "time"必须写24个字符串，不能写["00:00/23:00"]，否则报错。

提示："area"和"grid"看似可选，但强烈建议显式声明。因为ERA5不同变量默认网格不同（如辐射变量用0.5°，温度用0.25°），不声明会导致下载文件坐标系混乱，cdo处理时报"grid mismatch"。

3.3 批量下载脚本：断点续传与智能重试

以下是一个生产级下载脚本download_era5.sh，支持年份/变量/区域参数化，核心逻辑是：
① 检查目标目录是否存在已下载文件，跳过已存在项；
② 对每个请求生成唯一ID（基于year+var+area哈希），避免重复提交；
③ curl失败时，根据HTTP状态码采取不同策略：429（限流）sleep 60秒，503（服务忙）sleep 120秒，其他错误重试3次；
④ 下载后立即校验文件大小（ERA5每小时文件约12MB，小于10MB即为失败）。

#!/bin/bash # download_era5.sh - 支持断点续传的ERA5批量下载器 YEAR=${1:-2020} # 第一个参数：年份，默认2020 VAR=${2:-2m_temperature} # 第二个参数：变量名，默认2m_temperature AREA=${3:-"90/-180/-90/180"} # 第三个参数：区域，格式"N/W/S/E" # 创建下载目录 OUTDIR="era5_${VAR}_${YEAR}" mkdir -p "$OUTDIR" # 生成请求JSON（此处简化，实际用jq动态生成） cat > request.json <<EOF { "format": "netcdf", "product_type": "reanalysis", "variable": ["${VAR}"], "year": ["${YEAR}"], "month": ["01","02","03","04","05","06","07","08","09","10","11","12"], "day": ["01","02","03","04","05","06","07","08","09","10","11","12","13","14","15","16","17","18","19","20","21","22","23","24","25","26","27","28","29","30","31"], "time": ["00:00","01:00","02:00","03:00","04:00","05:00","06:00","07:00","08:00","09:00","10:00","11:00","12:00","13:00","14:00","15:00","16:00","17:00","18:00","19:00","20:00","21:00","22:00","23:00"], "area": [${AREA}], "grid": [0.25, 0.25] } EOF # 提交请求并获取任务ID TASK_ID=$(curl -s --config ~/.cdsapirc -X POST \ -H "Content-Type: application/json" \ --data-binary "@request.json" \ "https://cds.climate.copernicus.eu/api/v2/resources/reanalysis-era5-single-levels" | \ jq -r '.request_id') if [ "$TASK_ID" = "null" ] || [ -z "$TASK_ID" ]; then echo "ERROR: Failed to submit request" exit 1 fi echo "Task submitted: $TASK_ID" # 轮询任务状态，直到完成或失败 MAX_RETRY=60 RETRY=0 while [ $RETRY -lt $MAX_RETRY ]; do STATUS=$(curl -s --config ~/.cdsapirc \ "https://cds.climate.copernicus.eu/api/v2/resources/reanalysis-era5-single-levels/$TASK_ID" | \ jq -r '.state') case $STATUS in "completed") echo "Download completed" break ;; "failed") echo "Task failed: $(curl -s --config ~/.cdsapirc \ "https://cds.climate.copernicus.eu/api/v2/resources/reanalysis-era5-single-levels/$TASK_ID" | \ jq -r '.error.message')" exit 1 ;; "queued"|"running") echo "Status: $STATUS, waiting..." sleep 30 ;; *) echo "Unknown status: $STATUS" sleep 30 ;; esac RETRY=$((RETRY + 1)) done if [ $RETRY -eq $MAX_RETRY ]; then echo "ERROR: Task timeout after $MAX_RETRY attempts" exit 1 fi # 下载文件（CDS API返回的download_url需用curl -L重定向） DOWNLOAD_URL=$(curl -s --config ~/.cdsapirc \ "https://cds.climate.copernicus.eu/api/v2/resources/reanalysis-era5-single-levels/$TASK_ID" | \ jq -r '.location') if [ "$DOWNLOAD_URL" = "null" ]; then echo "ERROR: No download URL found" exit 1 fi # 实际下载，带进度条和校验 curl -L -# --config ~/.cdsapirc "$DOWNLOAD_URL" -o "${OUTDIR}/era5_${VAR}_${YEAR}.nc" || { echo "Download failed"; exit 1; } FILE_SIZE=$(stat -c%s "${OUTDIR}/era5_${VAR}_${YEAR}.nc" 2>/dev/null || stat -f%z "${OUTDIR}/era5_${VAR}_${YEAR}.nc" 2>/dev/null) if [ "$FILE_SIZE" -lt 10000000 ]; then # 小于10MB视为失败 echo "ERROR: Downloaded file too small ($FILE_SIZE bytes)" rm "${OUTDIR}/era5_${VAR}_${YEAR}.nc" exit 1 fi echo "Download success: ${OUTDIR}/era5_${VAR}_${YEAR}.nc"

注意：此脚本假设你已安装jq（JSON处理器）和curl。Ubuntu下sudo apt install curl jq，macOS下brew install curl jq。Windows用户请用WSL2，原生PowerShell对JSON解析支持极差。

3.4 下载后质检：三步验证法确保数据可用

下载完成不等于数据可用。我曾收到一个“成功下载”的nc文件，用cdo info看时间轴正常，但用ncks -v t2m file.nc -O test.nc抽变量时崩溃——原因是ECMWF在2021年某次更新中，悄悄把time_bnds变量的units从hours since 1900-01-01改成days since 1900-01-01，导致xarray解析失败。因此必须做三步验证：

第一步：基础结构验证

cdo -s infov "${OUTDIR}/era5_${VAR}_${YEAR}.nc" | head -20

检查输出中是否有time、latitude、longitude维度，以及time的size是否等于该年小时数（2020年闰年=366×24=8784）。若size为0或远小于8784，说明下载不全。

第二步：坐标一致性验证

cdo -s griddes "${OUTDIR}/era5_${VAR}_${YEAR}.nc"

输出应为：

gridtype = lonlat gridsize = 1440 xsize = 1440 ysize = 721 xname = longitude xlongname = longitude xunits = degrees_east yname = latitude ylongname = latitude yunits = degrees_north

关键看xsize=1440（360°/0.25°=1440）、ysize=721（180°/0.25°+1=721），若ysize=720，说明缺少赤道线（常见于旧版数据），需用cdo -P 4 setgrid,global_025deg ${file} ${out}修复。

第三步：变量完整性验证

cdo -s showvar "${OUTDIR}/era5_${VAR}_${YEAR}.nc"

确认输出包含请求的变量名（如t2m），且无missing_value异常。若出现***或NaN占比过高，说明数据质量有问题，需重新下载。

这三步加起来不到3秒，却能避免后续数小时的无效计算。记住：宁可多花3秒验证，也不愿多花3小时debug。

4. cdo核心处理：从原始nc到分析就绪数据的7个关键操作

4.1 合并分散文件：用mergetime替代cat的物理意义

ERA5小时数据默认按月分卷下载（如era5_t2m_202001.nc,era5_t2m_202002.nc…），直接cat *.nc > merged.nc会破坏netCDF结构——因为nc文件不是纯二进制流，它有全局属性、维度定义、变量属性等元数据头。cat会把第二个文件的头追加到第一个文件末尾，导致读取时维度错乱。

正确方法是cdo mergetime *.nc merged.nc。其原理是：cdo先读取所有输入文件的time维度，按时间戳升序排序，然后创建新的time维度（长度=总小时数），再将各文件对应时间步的数据块按序写入新文件。过程中自动处理：

• 时间轴单位统一（自动转换hours since或days since）；
• time_bnds变量同步更新（每个时间步的起止时间）；
• 全局属性继承（保留Conventions="CF-1.6"等关键标识）；
• 坐标变量去重（longitude、latitude只保留一份）。

实测对比：100个12MB文件（共1.2GB），cat耗时2.1秒但文件不可读；cdo mergetime耗时8.7秒但输出完美nc文件。多花6秒，换来100%可靠性。

提示：若文件时间轴不连续（如缺2020-02-29），mergetime会报错"time axis not monotonic"。此时先用cdo seltimestep,1/8784 file.nc fixed.nc强制截取有效时间步，再合并。

4.2 空间裁剪：sellonlatbox的边界陷阱与地理精度

cdo sellonlatbox,W/E/S/N in.nc out.nc是最常用的空间裁剪命令，但W/E/S/N的取值有严格地理约定：

• 经度W/E：西经为负，东经为正，且W必须小于E（如中国区域W=-10,E=130）；
• 纬度S/N：南纬为负，北纬为正，且S必须小于N（如中国区域S=0,N=60）；
• 关键陷阱：ERA5的latitude维度是从北向南递减的（90°→-90°），而sellonlatbox内部按“南纬/北纬”理解，所以S=0,N=60实际裁出的是赤道到北纬60°，完全正确；但若误写S=60,N=0，cdo会静默返回空文件。

更隐蔽的问题是网格对齐。ERA5的0.25°网格，经度从-180°开始，每步0.25°，即-180.00, -179.75, -179.50, ..., 179.75；纬度从90°开始，90.00, 89.75, 89.50, ..., -89.75。若你设W=100.1,E=120.3，cdo会自动向下取整到最近网格点（W=100.00,E=120.25），导致边界偏移0.1°–0.25°。解决方案是显式指定网格：

cdo -P 4 sellonlatbox,100.0,120.25,20.0,40.0 in.nc out.nc

-P 4启用4线程加速，100.0/120.25/20.0/40.0严格对齐原始网格。实测裁剪中国区域（73°–135°E, 3°–53°N）时，用sellonlatbox,73,135,3,53比sellonlatbox,70,140,0,60减少32%数据量，且无插值失真。

4.3 时间聚合：timmean与timselhour的物理约束

ERA5小时数据常需转为日均、月均或特定时段均值。cdo timmean是最直接命令，但有两个硬约束：

1. 时间轴必须严格连续：若缺1小时，timmean会报错"time axis has gaps"。解决方案是先用cdo setmisstoc,0 in.nc filled.nc填充缺失值（填0），或用cdo cat in.nc <(cdo seltimestep,1/1 in.nc | cdo settaxis,1900-01-01,00:00,1hour)补全时间轴；
2. 聚合步长必须整除总步长：如8784小时（2020年）可被24整除（日均），但不能被25整除。cdo timmean -tstep,25 in.nc会失败。

更灵活的是timselhour和timselmon：

• cdo timselhour,0,6,12,18 in.nc out_4times.nc抽取每天0/6/12/18时四次数据；
• cdo timselmon,1,2,3,4,5,6 in.nc out_jan_jun.nc抽取1–6月数据；
• cdo timselperiod,day,1,31 in.nc out_day1_31.nc抽取每月1–31日（自动跳过不存在日期）。

这些命令不改变时间轴连续性，适合做子集分析。例如风电预测中，只需每天13–15时风速，用timselhour,13,14,15比timmean更精准。

4.4 坐标重映射：remapbil与setgrid的精度权衡

原始ERA5是规则经纬度网格（lonlat），但很多模型（如WRF、CESM）需要高斯网格或自定义投影。cdo remapbil用双线性插值重采样，语法为：

cdo -P 4 remapbil,global_05deg in.nc out_05deg.nc

其中global_05deg是预定义网格名（cdo内置），也可用自定义网格文件china_01deg.txt：

gridtype = lonlat xsize = 1200 ysize = 600 xvals = 70 70.01 70.02 ... 130 yvals = 53 52.99 52.98 ... 3

remapbil精度高但慢；remapnn（最近邻）快但有锯齿；remaplaf（面积守恒）适合通量变量（如降水）。选择依据是：

• 温度/湿度等标量场 →remapbil；
• 风矢量（u/v）→ 必须用remapbic（双线性插值+矢量校正），否则风向失真；
• 降水/辐射等通量 →remaplaf，保证积分守恒。

实操心得：重映射前务必用cdo -s gridarea in.nc area.nc计算原始网格面积，再用cdo div area.nc out.nc归一化，否则重采样后单位错乱。这是90%新手忽略的致命细节。

4.5 单位与变量名标准化：setunit与chname的CF合规性

ERA5变量名（如t2m）和单位（如K）符合CF标准，但下游模型可能要求temperature_2m和°C。cdo提供精准修改命令：

cdo -P 4 setunit,"degC" -subc,273.15 t2m.nc temp_c.nc # K转°C cdo -P 4 chname,t2m,temperature_2m temp_c.nc final.nc # 重命名变量 cdo -P 4 setattribute,temperature_2m@long_name,"2-meter temperature" final.nc final_v2.nc

setunit修改units属性，subc,273.15对变量值减273.15，chname改变量名，setattribute加长名称。这些操作不改变数据值，只更新元数据，确保CF合规性（Climate and Forecast Metadata Conventions）。很多GIS软件（如QGIS）依赖long_name和units渲染图例，不设则显示为t2m (unknown)。

4.6 数据压缩与格式优化：-z zip_3与-f nc4的存储效率

ERA5原始nc文件未压缩，1小时全球数据约12MB。用cdo -z zip_3可压缩至3.5MB（压缩率70%），且cdo读取时自动解压，无性能损失。zip_3是zlib level 3，平衡速度与压缩率；zip_9压缩率更高但耗时翻倍，不推荐。

更进一步，转为netCDF4格式：

cdo -f nc4 -z zip_3 copy in.nc out.nc4

netCDF4支持分块（chunking）和Shuffle过滤，对大文件随机访问更快。实测10GB文件，nc4比nc3读取速度提升40%，存储节省15%。但注意：旧版GrADS或MATLAB可能不支持nc4，需确认下游工具兼容性。

4.7 批量处理管道：用find+xargs构建自动化流水线

单个命令易写，批量处理才见功力。例如将100个年份文件全部裁剪为中国区域并转°C：

find era5_t2m_* -name "*.nc" | xargs -I {} bash -c ' BASE=$(basename {} .nc) cdo -P 4 sellonlatbox,73,135,3,53 {} china_${BASE}.nc && \ cdo -P 4 setunit,"degC" -subc,273.15 china_${BASE}.nc china_${BASE}_c.nc && \ rm {} china_${BASE}.nc '

xargs -I {}将每个文件路径代入命令，bash -c启动子shell避免变量冲突。加上-P 4启用4进程并行，100个文件处理时间从32分钟降至9分钟。这是真正落地的“批量”——不是概念，是秒级响应的生产力。

5. 常见问题与排查技巧实录：那些文档不会写的实战经验

5.1 CDS API返回空文件或404：5种