サービス
Zarr
2026年08月26日 09:59
GISBoxは、OSGB/GEOTIFF/RVTなどの複数のGISフォーマットでの編集をサポートし、3DTiles/Terrainへの変換や公開が可能なワンストップ3DGIS データ編集、変換、公開プラットフォームです。
概要
Zarrは、クラウドネイティブなワークフローとハイパフォーマンスコンピューティング向けに設計された、チャンク分割および圧縮対応のN次元配列ストレージフォーマットです。気象データ、リモートセンシングデータ、ゲノムデータなどの大規模な多次元科学データセットを、小さく独立したチャンクに分割して個別に保存します。ZarrはzstdやBloscなど複数の圧縮アルゴリズムに対応しており、ローカルファイルシステム、ZIPアーカイブ、AWS S3などのクラウドオブジェクトストレージに直接保存できます。また、並列読み書きや遅延読み込みをネイティブでサポートしています。NetCDFやHDF5と比較すると、Zarrはクラウド環境における大規模なデータ共有や分散処理に適しており、xarrayやDaskなどの科学計算ツールの主要なバックエンド形式の一つとなっています。
データフォーマットの概要
Zarrのファイル構造は基本的にディレクトリ、またはオブジェクトストレージのプレフィックスであり、その内部ファイルは以下のカテゴリに分類できます：
- .zarray（配列メタデータファイル）：配列の中核仕様として機能するJSONファイルです。Zarrのバージョン、配列全体の形状、チャンクサイズ、データ型（dtype）、圧縮方式、フィル値、メモリレイアウト（C/Fオーダー）などの設定を記録します。各配列またはデータセットには、それぞれ独自の.zarrayファイルがあります。
- .zattrs（配列属性ファイル）：単位、説明、座標参照情報など、ユーザー定義のキーと値の属性を保存するJSONファイルです。NetCDFにおけるグローバル属性や変数属性に類似しています。
- .zgroup（グループメタデータファイル）：Zarrグループのルートディレクトリに配置されるJSONファイルです。このディレクトリが配列ではなくグループであることを示し、Zarrのバージョンなど、グループレベルのメタデータを含みます。Zarrストアに複数の変数が含まれる場合、通常はグループを使用して管理し、各変数を子配列として保存します。
- チャンクデータファイル：実際のデータを格納する中核ファイルです。大規模な配列はチャンク分割方式に従って多数の小さなチャンクに分割され、各チャンクが個別に圧縮され、バイナリファイルとして保存されます。
- サブグループ／サブ配列ディレクトリ：Zarrは、グループが他のグループを含む階層型のネスト構造をサポートしています。各サブグループは独自の.zgroup、.zarray、.zattrs、およびチャンクディレクトリを持つことができ、複数の変数を構造化して整理できます。
長所
- クラウドネイティブとの親和性：各チャンクが独立したオブジェクトであるため、AWS S3、GCS、Azure Blobなどのオブジェクトストレージに自然に適合します。POSIXファイルシステムを必要とせず、データセット全体をロックすることなく、複数のユーザーが同時に読み書きできます。
- 遅延読み込み：NetCDFやHDF5のようにファイル全体を開くのではなく、必要なチャンクだけを読み込みます。そのため、テラバイト規模のデータセットでも高速なスライス処理とアクセスが可能になります。
- 柔軟で効率的な圧縮：各チャンクでzstd、Blosc、gzipなどの圧縮アルゴリズムを個別に使用できます。データセット全体を展開することなく、チャンク単位でランダムアクセスできるため、高い圧縮率と効率性を両立できます。
- チャンクベースの並列I/O：異なるチャンクを複数のスレッドやプロセスで同時に読み書きできます。そのため、ZarrはDaskやSparkなどの分散コンピューティングフレームワークに適しています。
- グループによる階層的な整理：単一のZarrストアに、NetCDF-4やHDF5に類似した軽量な構造で、複数の配列、座標、属性セットを格納できます。
- 単一障害点がない：データが多数の小さなファイルやオブジェクトに分散されているため、1つのチャンクが破損してもデータセットの局所的な部分だけに影響します。HDF5ではメタデータが破損すると、ファイル全体が使用できなくなる場合があります。
- Write-Once-Read-Manyワークフローとの互換性：一度書き込まれたチャンクは、DVCやKerchunkなどを利用した不変かつバージョン管理されたデータセットの管理に適しています。
- 成熟した多言語エコシステム：ZarrにはPython、Julia、R、Java、Goなどの安定した実装があり、特にxarrayやDaskとの統合が強力です。
短所
- 小さなファイルが大量に発生する問題：ローカルファイルシステムでは、各チャンクが個別のファイルとして保存されます。数百万のチャンクがあると、iノードを使い果たしたり、ディレクトリのスキャンが非常に遅くなったりする可能性があります。そのため、Zarrはローカルファイルシステムに直接保存するよりも、オブジェクトストレージやパッケージ化された形式で保存する方が一般的に適しています。
- メタデータのパフォーマンスボトルネック：.zarrayや.zattrsなどのファイルはJSONテキストファイルであるため、メタデータ操作では多数の小さなファイルを読み込む必要があります。非常に大規模なチャンク分割データセットでは、メタデータ自体が膨大になる可能性があります。
- ネイティブな追加書き込みのサポートが限定的：既存のチャンクは変更できますが、時間などの次元に沿って新しいデータを追加する場合、チャンクレイアウトを慎重に計画する必要があります。また、NetCDF-4の無制限次元よりも使い勝手が劣ります。Zarr v3ではこの点が改善されています。
- 組み込みのインデックスやクエリエンジンがない：Zarrはストレージフォーマットにすぎません。Parquetとは異なり、クエリを高速化するための統計情報やインデックスを組み込みで提供していないため、空間的または時間的なサブセット処理にはKerchunkやTileDBなどの上位ツールが必要です。
- チャンク分割戦略を事前に計画する必要がある：チャンクサイズを設定した後に、効率的に変更することは困難です。小さなチャンクはメタデータのオーバーヘッドを増加させ、大きなチャンクは並列性を低下させ、遅延読み込みの粒度を粗くします。
- ツール群は現在も発展途上：NetCDFやHDF5と比較すると、Zarrのエコシステムはまだ新しいものです。QGISやGDALなど一部のGISソフトウェアにおけるサポートは追いついている段階ですが、GDAL 3.x以降ではすでにサポートされています。
- 一貫性モデルが弱い：オブジェクトストレージ上での同時書き込みでは、メタデータとチャンクデータの整合性を維持するために、条件付き書き込みやロックテーブルなどの追加メカニズムが必要になる場合があります。
応用シーン
Zarrの最も重要な応用分野は、気象学および気候科学です。例えば、CMIP6などの全球気候モデルによって生成されたペタバイト規模の多次元データセットの多くが、現在ではZarr形式でパブリッククラウドプラットフォーム上に配布され、世界中の研究者が並列アクセスできるようになっています。リモートセンシングや地理空間分析では、SentinelやLandsatなどの衛星ミッションによる大規模な衛星画像の時系列が、効率的な時間・空間アクセスを可能にするSTACカタログと組み合わせて、Zarrデータセットとして公開されるケースが増えています。バイオインフォマティクスでは、大規模なゲノムデータや単一細胞シーケンシングの行列データも、Zarrのチャンク圧縮と遅延読み込みモデルの恩恵を受けます。機械学習では、画像、動画、医用画像などのトレーニングデータセットをZarrに保存することで、DaskやPyTorch DataLoaderを利用した効率的な分散データパイプラインを構築できます。海洋科学、水文学、地球物理モデリングにおける大規模なシミュレーション出力も、急速にZarrエコシステムへ移行しています。
例
1. Ganosラスタエンジンに基づく地域降雨量分析。
2. 空間および時間、さらに深度または高度にわたって収集された多次元ラスタデータ。
ファイルの開き方
1. Zarrファイルの読み込み。
