Zarr hizo legibles enormes arreglos científicos fragmento a fragmento

La computación científica estaba pasando de archivos locales a almacenes de objetos, pero los arreglos gigantes en formatos monolíticos eran difíciles de segmentar de forma remota. Leer una región pequeña aún podía implicar arrastrar demasiados datos por la red.

El truco de Zarr consistía en mantener el modelo mental como un arreglo tipado N-dimensional mientras cambiaba la unidad de almacenamiento. Los datos residen en fragmentos comprimidos, cada uno con una clave determinista, y los metadatos describen la forma, el tipo, la cuadrícula de fragmentos y los códecs.

Eso hizo que el formato encajara en la computación distribuida: los trabajadores podían leer fragmentos en paralelo, y distintas implementaciones podían apuntar a Python, Rust, JavaScript, Java, C++ y otros lenguajes. Posteriormente, la OGC respaldó Zarr V2.0 como estándar comunitario para el almacenamiento de arreglos multidimensionales.

Hacer direccionable cada fragmento

Las claves de los fragmentos se asignan de forma natural a los almacenes de objetos en la nube y al almacenamiento direccionable por bytes.

Los metadatos JSON hicieron que el formato fuera inspeccionable y fácil de analizar para implementaciones independientes.

La especificación v3 formalizó puntos de extensión para que los códecs y las cuadrículas de fragmentos pudieran evolucionar sin reescrituras centrales.

Resolvió un problema real en flujos de trabajo de clima, microscopía, teledetección y simulación.

Para los datos en la nube, el formato ganador suele ser el que abarata las lecturas parciales sin hacer que los científicos abandonen su modelo de arreglos.

Zarr se convirtió en un sustrato común para datos científicos listos para análisis. El proyecto enumera implementaciones en 10 lenguajes y ocho conjuntos de datos públicos que suman unos 3,1 PB; la página del estándar de la OGC describe Zarr como una especificación de código abierto para datos y metadatos de arreglos ND.