nccopy重分块卡顿排查：ERA5数据rechunking异常求助

问题背景 #

处理最高时空分辨率的ERA5大气数据，需提取全球任意位置的完整风速时间序列（单年对应[1x8760]数组，原数据为[721x1440x8760]）。当前用xarray读取单坐标时间序列需12秒，API场景下耗时过长，计划扩展到5年数据，因此需要通过重分块优化读取性能。

已遇问题 #

直接从ERA5官网下载的月尺度NC文件重分块正常，但用cdo copy从GRIB转换而来的NC文件，执行重分块时出现卡顿甚至冻结：

• nccopy命令：

nccopy -k 'enhanced' -c 'time/8760,lat/7,lon/14' 2023Data.nc 2023ch.nc

月/年尺度数据均卡顿，仅两天尺度数据能完成，但达到目标文件大小后仍需长时间收尾；年尺度任务过夜无进展，内存占用极低。

• ncrcat命令：

ncrcat -4 -L 1 --cnk_csh=3000000000 --cnk_plc=g3d --cnk_dmn=time,8760 --cnk_dmn=lat,7 --cnk_dmn=lon,14 2023Data.nc 2023Data_chunk.nc

文件构建速度仅200 kB/s，扩展性极差。

关键差异分析 #

对比成功（官网NC）和失败（cdo转换NC）的ncdump结果，发现三个核心差异：

1. 时间维度属性：失败版本的time是UNLIMITED维度，成功版本是固定长度的int型维度；
2. 变量存储格式：成功版本的u/v是带scale_factor和add_offset的short型（压缩存储），失败版本是无压缩的float型；
3. 多余维度：失败版本多了长度为1的plev维度，成功版本无此维度。

分步解决方案 #

1. 移除多余的plev维度 #

由于plev维度仅1层，可先用CDO的squeeze命令去除长度为1的维度：

cdo squeeze March23.grib Marchgrib_squeezed.nc

或用NCO的ncks命令直接删除该维度：

ncks -x -v plev -d plev,0 Marchgrib.nc Marchgrib_noplev.nc

2. 修复UNLIMITED时间维度 #

将UNLIMITED的time转换为固定长度维度，用NCO的nccopy：

nccopy -d time Marchgrib_noplev.nc Marchgrib_fixed.nc

-d time参数会把time维度从UNLIMITED转为固定长度。

3. 转换变量为压缩的short型 #

参考ERA5官网NC的格式，将u/v转换为带scale/offset的short型，可直接用CDO在转换GRIB时指定格式：

cdo -f nc -b short copy March23.grib Marchgrib_short.nc

CDO会自动计算合适的scale_factor和add_offset，实现无损压缩；若已转换为NC文件，用NCO的ncap2手动处理：

ncap2 -O -s 'u=short(u); u@scale_factor=0.000973; u@add_offset=0.723; u@_FillValue=-32767' \
-s 'v=short(v); v@scale_factor=0.000976; v@add_offset=-2.734; v@_FillValue=-32767' \
Marchgrib_fixed.nc Marchgrib_compressed.nc

（注：scale/offset值可参考成功版本的参数，或通过ncdump读取原float变量的极值自动计算）

4. 执行重分块 #

处理完上述步骤后，再用nccopy执行重分块：

nccopy -k 'enhanced' -c 'time/8760,lat/7,lon/14' Marchgrib_processed.nc Marchgrib_chunked.nc

额外优化建议 #

• 若内存不足（8GB RAM），建议分月处理再合并：先对每个月的NC文件完成上述处理，再用ncrcat合并成年尺度文件，避免一次性加载大文件；
• 重分块时可添加-d 4参数启用Deflate压缩，减少最终文件体积：

nccopy -k 'enhanced' -d 4 -c 'time/8760,lat/7,lon/14' input.nc output.nc

内容的提问来源于stack exchange，提问作者Mikel Dominguez