如何最好地将NetCDF文件集重新集中到Zarr数据集

时间:2018-04-20 03:09:44

标签: python python-xarray netcdf4 dask-distributed zarr

我正在尝试重新安装NetCDF文件集并在AWS S3上创建Zarr数据集。我有168个原始的NetCDF4经典文件,其中维time: 1, y: 3840, x: 4608的数组被归为chunks={'time':1, 'y':768, 'x':922}

我想将此输出写入Zarr,我想优化时间序列提取,因此在我的块中包含更多时间记录。我想我会使用xarray帮助完成工作,因为我有很多处理器可以利用Dask,而xarray同时有xr.open_mfdatasetds.to_zarr

我首先尝试重新设置chunks={'time':24, 'y':768, 'x':922}以匹配xy中的输入NetCDF4分块,但是当我尝试写入Zarr时,它抱怨因为它需要统一的块大小xy,只允许time维度上的最后一个块中的非统一大小(不幸的是x维度中的总大小4608不是多个块大小922。

然后我尝试了chunks={'time':168, 'y':384, 'x':288}并开始工作,并且快速地进行了几分钟,然后变得越来越慢。最终在50分钟后,群集死于:

4072 distributed.core - INFO - Event loop was unresponsive in Worker for 1.41s.  This is often caused by long-running GIL-holding functions or moving large chunks of data. This can cause timeouts and instability.
4073 slurmstepd: error: Step 3294889.0 exceeded memory limit (25346188 > 25165824), being killed

这是我正在使用的代码:

from dask.distributed import Client

import pandas as pd
import xarray as xr
import s3fs
import zarr

client = Client(scheduler_file='/home/rsignell/scheduler.json')
client

enter image description here

root = '/lustre/projects/hazards/cmgp/woodshole/rsignell/nwm/forcing_short_range/' 

bucket_endpoint='https://s3.us-west-1.amazonaws.com/'

f_zarr = 'rsignell/nwm/test_week4'

dates = pd.date_range(start='2018-04-01T00:00', end='2018-04-07T23:00', freq='H')

urls = ['{}{}/nwm.t{}z.short_range.forcing.f001.conus.nc'.format(root,a.strftime('%Y%m%d'),a.strftime('%H')) for a in dates]

ds = xr.open_mfdataset(urls, concat_dim='time', chunks={'time':1, 'y':768, 'x':922})
ds = ds.drop(['ProjectionCoordinateSystem','time_bounds'])
ds = ds.chunk(chunks={'time':168, 'y':384, 'x':288}).persist()
ds
制造

<xarray.Dataset>
Dimensions:         (reference_time: 168, time: 168, x: 4608, y: 3840)
Coordinates:
  * reference_time  (reference_time) datetime64[ns] 2018-04-01 ...
  * x               (x) float64 -2.304e+06 -2.303e+06 -2.302e+06 -2.301e+06 ...
  * y               (y) float64 -1.92e+06 -1.919e+06 -1.918e+06 -1.917e+06 ...
  * time            (time) datetime64[ns] 2018-04-01T01:00:00 ...
Data variables:
    T2D             (time, y, x) float64 dask.array<shape=(168, 3840, 4608), chunksize=(168, 384, 288)>
    LWDOWN          (time, y, x) float64 dask.array<shape=(168, 3840, 4608), chunksize=(168, 384, 288)>
    Q2D             (time, y, x) float64 dask.array<shape=(168, 3840, 4608), chunksize=(168, 384, 288)>
    U2D             (time, y, x) float64 dask.array<shape=(168, 3840, 4608), chunksize=(168, 384, 288)>
    V2D             (time, y, x) float64 dask.array<shape=(168, 3840, 4608), chunksize=(168, 384, 288)>
    PSFC            (time, y, x) float64 dask.array<shape=(168, 3840, 4608), chunksize=(168, 384, 288)>
    RAINRATE        (time, y, x) float32 dask.array<shape=(168, 3840, 4608), chunksize=(168, 384, 288)>
    SWDOWN          (time, y, x) float64 dask.array<shape=(168, 3840, 4608), chunksize=(168, 384, 288)>

然后我打电话给

fs = s3fs.S3FileSystem(anon=False, client_kwargs=dict(endpoint_url=bucket_endpoint))
d = s3fs.S3Map(f_zarr, s3=fs)

compressor = zarr.Blosc(cname='zstd', clevel=3, shuffle=2)
encoding = {vname: {'compressor': compressor} for vname in ds.data_vars}

delayed_store = ds.to_zarr(store=d, mode='w', encoding=encoding, compute=False)
persist_store = delayed_store.persist(retries=100)

就在它死之前,Dask Daskboard看起来像这样:

enter image description here enter image description here

NetCDF4文件的总大小是20GB,所以看起来有点疯狂,我在Dask Dashboard中显示超过500GB,并且每个具有60GB RAM的30个处理器不足以完成这项工作。

我做错了什么,或者什么是更好的解决方案?

1 个答案:

答案 0 :(得分:0)

我注意到您说您想增加时间维度中的块数。也许我误会了。

从指定为chunks={'time':1, 'y':768, 'x':922}的块开始,然后尝试chunks={'time':168, 'y':384, 'x':288},发现第二个块使用了大量的内存。

问题是chunks关键字指定了块的 size ,而不是块的 number

在第一种情况下,每个块的大小为1*768*922 ~ 7e5,而在第二种情况下,每个块的大小为168*384*288 ~ 2e7

chunks={'time': 1}实现了最大时间块数。