NetCDF ou Zarr : le chunking dépend de l’usage

Trois façons de découper le même jeu de données

Un fichier NetCDF4 peut lui aussi être écrit avec un chunking configurable, une compression et des dimensions adaptées ; dans ce benchmark, nous comparons un NetCDF monolithique à trois organisations Zarr. xarray peut charger le fichier paresseusement, mais la donnée physique sur disque n'est pas organisée pour un accès particulier. Zarr, à l'inverse, exige de choisir à l'écriture la taille des chunks selon les trois dimensions (temps, latitude, longitude). Ce choix fige la façon dont chaque lecture ultérieure va toucher le disque. Nous avons écrit le même jeu ERA5 sous trois découpages :

routing

chunks (time=1, lat=40, lon=40) — pensé pour une carte instantanée ou une extraction de corridor à un instant donné.

timeseries

chunks (time=-1, lat=1, lon=1) — pensé pour l'historique complet en un point (waypoint).

balanced

chunks (time=24, lat=20, lon=20) — un compromis qui ne favorise aucun des deux axes.

Les six scénarios mesurés reproduisent des usages réels de routage : rendu d'une carte de hauteur de houle (Hs) à un instant donné, série temporelle complète sur un waypoint, extraction d'une large bounding-box englobant une route, extraction d'un couloir étroit (±1°) le long d'une polyline Brest → Açores → Canaries → Dakar, lecture simultanée de quatre waypoints (typique d'un calcul d'isochrones), et fenêtre météo de sept jours sur un domaine restreint. Chaque mesure est la médiane de cinq lectures, dataset rouvert entre chaque essai.

Quand le chunking colle au motif d'accès : deux gains nets

Sur une carte instantanée — un seul pas de temps, tout le domaine spatial — le store routing répond en 0,011 s, contre 0,031 s pour le NetCDF monolithique. C'est cohérent avec sa géométrie : ses chunks spatiaux compacts (40×40) et son chunk temporel unitaire font qu'une seule tranche de temps ne touche qu'une fraction du store.

Sur une série temporelle à un waypoint sur dix ans, l'écart est d'un autre ordre. Le store timeseries — chunké justement pour concentrer tout l'historique d'un point unique dans un seul bloc — répond en 0,011 s au waypoint de Brest et 0,015 s à celui des Açores, contre 1,33 s et 1,47 s pour le NetCDF monolithique. Le motif se confirme et s'amplifie sur un usage voisin : la lecture simultanée de quatre waypoints (motif d'isochrones) prend 0,046 s sur le store timeseries, contre 4,91 s en NetCDF.

Dans les deux cas, le point commun est le même : le chunk correspond exactement à la forme de la requête. Une carte lit un pas de temps entier ; le store routing stocke un pas de temps par chunk. Une série temporelle lit un point sur toute la durée ; le store timeseries stocke un point par chunk. Rien de magique — un alignement géométrique.

Quand le chunking ne colle pas : Zarr plus lent que le NetCDF qu'il devait remplacer

C'est le point que les démonstrations Zarr passent le plus souvent sous silence. Un store Zarr mal chunké pour un scénario donné ne se contente pas d'être moins rapide qu'un store bien chunké — il peut être plus lent que le NetCDF monolithique de départ.

Sur la série temporelle au waypoint de Brest, le store routing — chunké time=1, soit un chunk par pas de temps sur dix ans — répond en 4,70 s, contre 1,33 s pour le NetCDF. Lire dix ans d'historique en un point revient à ouvrir des milliers de chunks d'un seul pas de temps chacun : l'overhead d'accès dépasse le gain de format. Le même effet apparaît sur la carte instantanée avec le store timeseries — chunké justement à l'opposé, un point par chunk : 2,66 s pour lire un unique pas de temps sur tout le domaine, contre 0,031 s en NetCDF. Chaque cellule spatiale distincte exige d'ouvrir son propre chunk.

L'extraction du couloir étroit de routage (bande ±1° autour de la polyline, dix ans) confirme le schéma : le store timeseries, cette fois bien assorti au motif — un accès concentré sur peu de points spatiaux, toute la durée — répond en 0,50 s, contre 1,79 s pour le NetCDF. Mais le store routing, chunké pour l'usage inverse, met 8,14 s — cinq fois la lecture du même couloir en NetCDF. Sur la bounding-box large englobant toute la route (motif de lecture en bloc, défavorable par construction à un découpage fin), le NetCDF reste compétitif à 3,59 s, le store timeseries descend légèrement à 2,00 s, mais routing et balanced grimpent respectivement à 6,82 s et 5,49 s.

Le compromis balanced, et la zone où le format ne change presque rien

Le store balanced (time=24, lat=20, lon=20) ne gagne jamais le meilleur temps d'un scénario, mais il n'y a jamais le pire non plus, à une exception près (la bounding-box large). Sur le waypoint de Brest il répond en 0,45 s — nettement moins bien que le store timeseries à 0,011 s, mais nettement mieux que le store routing à 4,70 s. Sur la carte instantanée, il répond en 0,091 s — moins bien que routing à 0,011 s, mais sans commune mesure avec les 2,66 s du store timeseries mal assorti. C'est l'intérêt d'un chunking équilibré : il ne maximise aucun scénario, il évite les échecs profonds sur les scénarios pour lesquels il n'a pas été pensé.

Un dernier scénario mérite d'être cité pour son honnêteté : la fenêtre météo de sept jours sur un domaine restreint autour des Açores. Là, NetCDF (0,028 s) et Zarr routing (0,037 s) sont dans le même ordre de grandeur, et le store balanced (0,031 s) ne fait pas mieux que le NetCDF. Sur un sous-ensemble suffisamment petit — peu de pas de temps, domaine restreint — le format de stockage cesse d'être le facteur dominant. Rechunker n'a de sens que là où le motif d'accès rend le chunking natif du NetCDF structurellement inadapté ; pour une petite extraction ponctuelle, la question ne se pose quasiment pas.

La conclusion opérationnelle tient en une phrase : ne choisissez pas Zarr contre NetCDF, choisissez un chunking pour un motif d'accès. Un store Zarr conçu pour des cartes ne doit pas servir à des séries temporelles, et inversement — dans les deux sens, l'écart avec le mauvais découpage se compte en secondes, pas en millisecondes. Si votre pipeline sert plusieurs motifs d'accès à partir du même jeu de données, il vous faudra soit plusieurs stores rechunkés en parallèle, soit un compromis assumé de type balanced, soit — pour en amont choisir la bonne donnée avant même de parler de son stockage — quelle donnée océanique pour quel besoin.

Sources et références

Les métriques, comparaisons et cartes propres à cet article sont des résultats et calculs OceanData Consulting ; les liens ci-dessous documentent les jeux de données, standards et publications mobilisés.

• Zarr — chunked, compressed, N-dimensional array storage
• xarray — N-D labelled arrays and datasets in Python
• Copernicus Climate Data Store — ERA5 access
• Unidata — NetCDF data model and libraries

Questions fréquentes

À lire également