nccopy 故障排除：在重新分块结束时卡住

Question

我正在使用 ERA5 大气数据以最大空间和时间分辨率计算全球任何地方的风速。这会产生一个包含一年数据的未压缩 70GB 文件，我想总共分析 5 年的数据，因此它可以快速扩展。

在我的应用程序中，我想检索单个空间坐标的整个时间历史数据，一年的结果是单个 [1x8760] 数组（来自 [721x1440x8760] 的总数组）。然而，使用 xarray 读取此数据大约需要 12 秒。考虑到我想做一个让用户直接输入坐标的 API，这个时间太长了，而且我还需要 5 年时间。

这就是为什么我尝试使用

nccopy

重新分块，但效果不是很好。我首先用从 ERA5 站点直接以

.nc

格式获取的一个月数据进行了测试，重新分块的速度与将文件移出磁盘一样快，但读取速度慢了 10 倍。然而，当我尝试对之前从

.nc

文件获取的

.grib

文件（使用 cdo 的复制命令进行转换）执行相同操作时，重新分块同样快......直到两个文件被挂起时相同的尺寸。从那时起，它的尺寸慢慢增大，然后似乎就冻结了。终端中的命令行不提供任何信息：它根本没有完成该过程。

我运行的命令如下：

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

我已经尝试过每月和每年的数据，并且在这两种情况下都卡住了。唯一一次没有卡住的是当我测试了两天的数据时。在这种情况下，程序在达到最终大小后花了一点时间来关闭子进程。我想知道其他两个是否也是如此，所以我让一个运行了一整夜，但内存使用量非常低，当我回来检查它时，它是一样的。

同样，我也尝试过使用

ncrcat

，但它构建文件的速度约为 200 kB/s，可扩展性不太好。也许这与我电脑的 RAM 容量有关？它只有8GB。不过，长时间运行并不是真正的问题，只要我知道它会导致文件读取速度更快。

如果您好奇，我的

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

提前致谢！

编辑：

我对成功和失败的月份数据进行了

ncdump

。最让我惊讶的是，在不成功的版本中存在时间的“无限”属性，以及在成功的版本中存在比例和偏移因素。这会不会有什么关系呢？这是他们的数据：

成功版本：

netcdf March23 {
dimensions:
    longitude = 1440 ;
    latitude = 721 ;
    time = 744 ;
variables:
    float longitude(longitude) ;
        longitude:units = "degrees_east" ;
        longitude:long_name = "longitude" ;
    float latitude(latitude) ;
        latitude:units = "degrees_north" ;
        latitude:long_name = "latitude" ;
    int time(time) ;
        time:units = "hours since 1900-01-01 00:00:00.0" ;
        time:long_name = "time" ;
        time:calendar = "gregorian" ;
    short u(time, latitude, longitude) ;
        u:scale_factor = 0.000973234033583867 ;
        u:add_offset = 0.723214860033989 ;
        u:_FillValue = -32767s ;
        u:missing_value = -32767s ;
        u:units = "m s**-1" ;
        u:long_name = "U component of wind" ;
        u:standard_name = "eastward_wind" ;
    short v(time, latitude, longitude) ;
        v:scale_factor = 0.000975952222946717 ;
        v:add_offset = -2.73403137210757 ;
        v:_FillValue = -32767s ;
        v:missing_value = -32767s ;
        v:units = "m s**-1" ;
        v:long_name = "V component of wind" ;
        v:standard_name = "northward_wind" ;

// global attributes:
        :Conventions = "CF-1.6" ;
        :history = "2024-04-16 08:19:28 GMT by grib_to_netcdf-2.25.1: /opt/ecmwf/mars-client/bin/grib_to_netcdf.bin -S param -o /cache/data4/adaptor.mars.internal-1713255545.5304747-14711-19-427e9bce-89c5-41b9-84eb-7977830332cc.nc /cache/tmp/427e9bce-89c5-41b9-84eb-7977830332cc-adaptor.mars.internal-1713255478.0202947-14711-24-tmp.grib" ;
        :_Format = "64-bit offset" ;

不成功的版本：

netcdf Marchgrib {
dimensions:
    time = UNLIMITED ; // (744 currently)
    lon = 1440 ;
    lat = 721 ;
    plev = 1 ;
variables:
    double time(time) ;
        time:standard_name = "time" ;
        time:units = "hours since 2023-3-1 00:00:00" ;
        time:calendar = "proleptic_gregorian" ;
        time:axis = "T" ;
    float lon(lon) ;
        lon:standard_name = "longitude" ;
        lon:long_name = "longitude" ;
        lon:units = "degrees_east" ;
        lon:axis = "X" ;
    float lat(lat) ;
        lat:standard_name = "latitude" ;
        lat:long_name = "latitude" ;
        lat:units = "degrees_north" ;
        lat:axis = "Y" ;
    double plev(plev) ;
        plev:standard_name = "air_pressure" ;
        plev:positive = "down" ;
        plev:axis = "Z" ;
    float u(time, plev, lat, lon) ;
        u:standard_name = "eastward_wind" ;
        u:long_name = "U component of wind" ;
        u:units = "m s**-1" ;
        u:code = 131 ;
        u:table = 128 ;
    float v(time, plev, lat, lon) ;
        v:standard_name = "northward_wind" ;
        v:long_name = "V component of wind" ;
        v:units = "m s**-1" ;
        v:code = 132 ;
        v:table = 128 ;

// global attributes:
        :CDI = "Climate Data Interface version ?? (http://mpimet.mpg.de/cdi)" ;
        :Conventions = "CF-1.6" ;
        :history = "Thu Apr 18 16:50:17 2024: cdo -f nc copy March23.grib Marchgrib.nc" ;
        :institution = "European Centre for Medium-Range Weather Forecasts" ;
        :CDO = "Climate Data Operators version 1.9.3 (http://mpimet.mpg.de/cdo)" ;
        :_Format = "64-bit offset" ;
}

Answer 1

我通过更改将 GRIB 转换为 NETCDF4 格式的方法解决了该问题。之前，我使用的是

cdo

及其

copy

命令。这不仅导致文件大小加倍，而且无法重新分块（我不知道原因）。

相反，我使用了grib_to_netcdf

提供的功能

ecCodes。这完全解决了问题，并且可以使用

nccopy

对其进行重新分块以达到我的目的，从而将速度提高了 40 倍。