Zarr(云原生多维栅格数据存储格式)
2026年06月29日 09:06

GISBox是一站式三维 GIS 数据编辑、转换、发布平台,支持 OSGB/GEOTIFF/RVT 等多种 GIS 格式编辑,转换为 3DTiles/Terrain 等并发布。

简介

Zarr是一种专为云原生和高性能计算设计的分块、压缩N维数组存储格式,它将大型多维数据(如气象、遥感、基因组等科学数据)切分为独立的小块并分别存储,支持多种压缩算法(如zstd、Blosc),可直接存放在本地文件系统、ZIP包或AWS S3等云对象存储上,天然支持并行读写和按需加载,与NetCDF/HDF5相比更适合云环境下的大规模数据协作与分布式处理,已成为xarray、Dask等科学计算工具链的主流后端之一。

文件结构

Zarr 的文件结构本质上是一个‌目录(或对象存储前缀)‌,其内部文件可按功能分为以下几类:

  1. .zarray(数组元数据文件):JSON格式,记录该数组的核心"说明书":Zarr版本、数组总形状(shape)、分块大小(chunks)、数据类型(dtype)、压缩器(compressor)、填充值(fill_value)、内存布局(order=C/F)等。每个数组(Array/Dataset)都有自己的 .zarray。
  2. .zattrs(数组属性文件):JSON格式,存储用户自定义的键值对属性,如单位(units)、描述(description)、坐标参考信息等,类似NetCDF的全局/变量属性。
  3. .zgroup(组元数据文件):JSON格式,出现在Zarr ‌Group(组)‌ 的根目录下,标记这是一个组而非数组,包含组的元信息(如Zarr版本)。当一个Zarr存储中有多个变量时,通常用Group来统一管理,每个变量作为组内的子数组。
  4. 数据块文件:这是Zarr的核心数据载体。大数组按分块方案被切成许多小块,每一块独立压缩后存为一个二进制文件。
  5. 子组/子数组目录:Zarr支持层级嵌套结构(Group套Group),每个子组下可以有自己的.zgroup、.zarray、.zattrs和数据块目录,从而实现多变量的组织。

优点

  1. 云原生友好‌:每个分块就是一个独立的对象(Object),天然适配AWS S3、GCS、Azure Blob等对象存储,无需POSIX文件系统,多人可同时并发读写互不锁死。
  2. 按需读取(Lazy Loading)‌:只读取需要的分块,不必像NetCDF/HDF5那样整文件打开,超大数据集(TB级)也能快速切片访问。
  3. 压缩灵活且高效‌:每个分块可独立使用zstd、Blosc、gzip等压缩算法,压缩比高且支持分块级别随机访问(不必解压整个文件)。
  4. 分块可并行I/O‌:不同分块可由不同进程/线程同时读写,天然适配Dask、Spark等分布式计算框架,I/O吞吐量远超传统单文件格式。
  5. 层级组织(Group)‌:支持嵌套组结构,一个存储里可容纳多个数组(变量)、多个坐标、多组属性,组织方式接近NetCDF-4/HDF5但更轻量。
  6. 无单点故障‌:数据分散为大量小文件/对象,损坏一个分块只影响局部,不像HDF5 那样元数据损坏可能导致整文件不可用。
  7. 写一次读多次(WORM)兼容‌:分块一旦写入不可变,天然适合版本化数据集(如用 DVC、Kerchunk做版本管理)。
  8. 跨语言生态成熟‌:Python(zarr、xarray)、Julia(Zarr.jl)、R、Java、Go等均有成熟实现,且与xarray/Dask深度集成。

缺点

  1. 小文件问题(File System Overhead)‌:在本地文件系统上,每个分块都是一个独立文件,百万级分块会导致inode耗尽、目录扫描极慢(ls卡死),所以‌不建议直接放在本地FS,应放对象存储或打包为ZIP。
  2. 元数据性能瓶颈‌:.zarray/.zattrs是JSON文本,元数据操作(如获取整个数组形状)需要读取这些小文件;海量分块时元数据本身也会膨胀。
  3. 不支持增量写入(Append)的原生操作有限‌:虽然可以修改已有分块,但向数组末尾"追加"新数据(如时间维度扩展)需要重新规划分块布局,不如NetCDF-4的unlimited dimension方便(ZarrV3正在改进)。
  4. 无内置索引/查询能力‌:Zarr只是存储格式,不像Parquet那样自带列统计、行组索引,空间/时间子集查询依赖上层工具(如Kerchunk虚拟数据集、TileDB等)。
  5. 分块策略需提前规划‌:chunk大小一旦写死就很难高效修改,选太小则元数据开销大,选太大则并行度和按需读取粒度差,需要根据访问模式权衡。
  6. 工具链仍在演进中‌:相比NetCDF(40+年历史)和 HDF5(30+年),Zarr生态较年轻,部分GIS软件(如QGIS、GDAL)支持度仍在追赶中(GDAL 3.x+ 已支持)。
  7. 一致性模型较弱‌:在对象存储上并发写入时需要额外机制(如S3的 conditional write、DynamoDB锁表)来保证元数据与数据块的一致性,不像HDF5有内置锁机制。

应用场景

Zarr最核心的应用场景是‌气象与气候科学‌,如CMIP6等全球气候模式产出的PB级多维数据几乎全部采用Zarr格式存储在公有云上,方便全球研究人员并行读取。在‌遥感与地理空间‌领域,Sentinel、Landsat等卫星影像的海量时间序列也越来越多地以Zarr发布,结合STAC目录实现按时间/空间快速切片访问。‌生物信息学‌中的基因组、单细胞测序等TB 级矩阵数据同样依赖Zarr的分块压缩和按需加载能力。此外在‌机器学习‌场景下,大模型训练数据集(如图像、视频、医学影像)用Zarr存储可实现高效的数据流水线读取,配合Dask/PyTorch DataLoader实现分布式训练;‌海洋科学、水文模拟、地球物理反演‌等领域的大规模数值模拟输出也在快速迁移到Zarr生态上。

示例图

1. 基于Ganos栅格引擎开展区域面雨量分析。

Snipaste_2026-06-29_09-38-23.jpg

2. 跨空间和时间、深度或高度收集的多维栅格数据。

Snipaste_2026-06-29_09-42-44.jpg

文件打开方式

1. 读取Zarr文件。

Snipaste_2026-06-29_09-33-27.jpg

相关 GIS 文件

MID

IMDF

STYLX

OpenDRIVE (.xodr)

参考资料

  1. https://blog.csdn.net/gitblog_00812/article/details/151780732
  2. https://zhuanlan.zhihu.com/p/64159537、
  3. https://help.aliyun.com/zh/polardb/polardb-for-postgresql/ganos-based-raster-engine-to-carry-out-area-rainfall-analysis
  4. https://blog.csdn.net/JData_Engineer/article/details/131044735