CDO selyear命令使用疑问：输出文件体积为何远超输入？

这问题我之前帮朋友排查过类似的，大概率是NetCDF文件的压缩设置或数据格式被意外改变导致的，咱们一步步来分析解决：

最常见的原因：原始文件有压缩，输出没保留 #

很多逐日NetCDF数据会默认开启压缩（比如deflate压缩）来减小体积，但CDO的默认输出设置是不开启压缩的——也就是说你提取后的文件是无压缩的原始数据，体积自然会暴涨好几倍。

验证方法 #

用ncdump -h in.nc查看原始文件的变量属性，找有没有类似deflate_level = 6;这样的压缩配置；再对比ncdump -h out.nc，如果输出文件没有这个属性，那就是压缩的锅。

解决命令 #

执行提取时强制开启最高压缩率：

cdo -z zip_9 selyear,2101/2227 in.nc out.nc

zip_9是deflate压缩的最高级别，也可以根据需求换成zstd（更快的现代压缩）或者zip_5（平衡速度和压缩率）。

另一个可能：数据类型被自动转换 #

有时候CDO会把原始的整型数据（比如int16/int32，每个数值占2/4字节）转换成浮点型（float64，占8字节），直接让单变量体积翻倍。

验证方法 #

用cdo infon in.nc和cdo infon out.nc对比变量的数据类型，比如原始是short（int16），输出变成了double（float64），那就是类型转换导致的。

解决命令 #

强制保留原始数据类型，比如原始是int16就用-b s参数：

cdo -b s -z zip_9 selyear,2101/2227 in.nc out.nc

参数对应关系：-b s=int16，-b i=int32，-b f=float32，-b d=float64。

小众情况：时间轴编码格式变化 #

极少数情况下，原始文件的时间变量用了紧凑的数值编码（比如相对于某个基准日的天数），CDO处理后可能转换成了更占空间的格式。可以用ncdump -v time in.nc和ncdump -v time out.nc对比时间变量的存储方式，如果差异很大，就加上日历参数：

cdo -setcalendar,standard -z zip_9 selyear,2101/2227 in.nc out.nc

（这里的standard要换成你原始文件的日历类型，比如360_day等）

最后验证 #

处理完后用ls -lh对比文件体积，再用cdo diff in.nc out.nc检查数据是否一致——确保体积减小的同时，提取的数据没有出错。

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