Depuis plusieurs années, les volumes de données manipulés par les SIG ne cessent d'augmenter. Observation de la Terre, données de mobilité, réseaux de capteurs, référentiels nationaux, jumeaux numériques… Les SIG doivent désormais composer avec des jeux de données qui peuvent atteindre plusieurs dizaines, voire plusieurs centaines de millions d'enregistrements.

Cette évolution pose une question assez simple : comment stocker, transporter et exploiter efficacement ces données sans systématiquement les importer dans une base de données géographique traditionnelle ?

Dans le monde de la donnée, un format s'est progressivement imposé comme une réponse particulièrement intéressante à cette problématique : Apache Parquet.

Initialement développé pour les environnements de traitement distribués et l'analyse de grands volumes de données, ce format de stockage par colonne trouve aujourd'hui sa place dans les architectures analytiques modernes. Et avec GeoParquet, il devient également particulièrement intéressant pour les données géographiques.

Mais qu'est-ce qui distingue réellement Parquet d'un fichier CSV ou d'un fichier Shapefile ? Pourquoi son organisation par colonne est-elle si intéressante ? Et comment peut-on lui ajouter une dimension géographique ?

Prenons l'exemple d'une collectivité qui souhaite exploiter les déplacements de plusieurs milliers de véhicules. Chaque véhicule transmet régulièrement sa position, sa vitesse, son horodatage et différentes informations relatives à son fonctionnement.

Sur une journée, ce dispositif peut produire plusieurs millions d'observations. Sur une année, le volume devient considérable.

Traditionnellement, ces données pourraient être stockées dans une base de données relationnelle, éventuellement enrichie d'une extension spatiale, ou dans des fichiers CSV avant d'être importées dans un environnement SIG.

Ces approches restent parfaitement pertinentes dans de nombreux contextes. Mais elles ne sont pas toujours optimales lorsque l'objectif consiste essentiellement à analyser de très grands volumes de données, à lire quelques attributs parmi de nombreux autres ou à transférer des informations entre différentes plateformes.

C'est dans cet environnement que les formats de stockage analytiques ont pris de l'importance.

Parmi eux, Apache Parquet occupe une place particulière.

Apache Parquet est un format de fichier ouvert, développé au sein de l'écosystème Apache. Sa principale caractéristique est son organisation par colonne (column-oriented storage).

Pour comprendre son intérêt, il faut le comparer à une organisation classique de données par lignes.

Imaginons une table contenant un million d'observations de circulation avec les champs suivants :

Dans une organisation par lignes, les valeurs correspondant à chaque observation sont regroupées ensemble. Chaque enregistrement contient donc l'ensemble de ses attributs. Dans une organisation par colonne, les valeurs d'un même attribut sont regroupées.

La différence est importante lorsqu'une application ne souhaite consulter qu'une partie des informations.

Imaginons que notre objectif soit de calculer la vitesse moyenne par tronçon routier. Il n'est pas nécessaire de lire systématiquement l'ensemble des attributs de chaque observation. Le moteur peut accéder directement aux colonnes qui l'intéressent.

Cette organisation réduit les lectures inutiles et peut considérablement améliorer les performances des traitements analytiques.

C'est précisément l'un des grands avantages de Parquet.

Parquet ne se contente pas de ranger les valeurs par colonnes. Le format organise également les données en plusieurs niveaux. Un fichier Parquet est notamment constitué de Row Groups. Chaque groupe contient plusieurs colonnes, elles-mêmes organisées en pages. Cette structure permet de lire sélectivement les portions de données nécessaires à une requête.

Le fichier contient également des métadonnées décrivant son schéma, les types des colonnes et différentes statistiques. On peut notamment retrouver les valeurs minimales et maximales de certaines colonnes. Ces informations sont particulièrement utiles lorsqu'une requête comporte un filtre.

Par exemple, si l'on recherche les observations dont la date est comprise entre deux valeurs, un moteur de lecture peut examiner les statistiques des différents groupes et ignorer ceux qui ne contiennent manifestement aucune observation correspondant à cette période.

Ce mécanisme est notamment associé au predicate pushdown et au data skipping.

L'intérêt est évident : éviter de lire des données qui ne contribueront pas au résultat final.

L'organisation par colonne présente un autre avantage : elle facilite la compression.

Les valeurs d'une même colonne ont souvent des caractéristiques similaires. Les dates, les identifiants, les catégories ou les valeurs numériques peuvent ainsi être encodés et compressés efficacement.

Parquet prend en charge plusieurs mécanismes d'encodage et de compression, notamment Snappy, GZIP et Zstandard.

La réduction de taille dépend naturellement de la nature des données, de leur répétitivité et des paramètres utilisés lors de la production du fichier.

Mais cette caractéristique présente un intérêt particulier dans les architectures Cloud.

Moins de données stockées signifie potentiellement moins d'espace consommé. Moins de données transférées signifie également moins de trafic réseau et une lecture plus efficace des fichiers.

L'autre grand intérêt de Parquet est son adoption dans de nombreux environnements informatiques. On le retrouve notamment dans les écosystèmes suivants :

Cette adoption permet de construire des chaînes de traitement dans lesquelles un même fichier peut être exploité par plusieurs applications.

Un jeu de données produit dans un environnement analytique peut ainsi être transmis à un autre outil sans devoir être systématiquement converti dans un format propriétaire.

Pour les organisations qui disposent déjà d'une plateforme Data Lake ou Data Lakehouse, cette interopérabilité est particulièrement intéressante.

Mais Parquet présente une limite pour les utilisateurs SIG : le format standard ne définit pas, à lui seul, la manière dont une géométrie doit être interprétée. C'est précisément là qu'intervient GeoParquet.

GeoParquet est une spécification qui définit comment stocker des données géographiques dans un fichier Apache Parquet.

L'objectif est de conserver les avantages du format colonnaire tout en ajoutant les informations nécessaires à l'exploitation des géométries.

Ces informations sont notamment décrites dans des métadonnées géospatiales intégrées au fichier.

Elles permettent d'identifier :

Les géométries peuvent notamment être encodées en WKB (Well-Known Binary), un format binaire largement utilisé dans les bases de données et les logiciels SIG.

La spécification GeoParquet 1.1.0 prévoit également des possibilités d'encodage fondées sur GeoArrow.

L'intérêt est de pouvoir conserver les géométries et leurs attributs dans un même fichier, tout en disposant d'une description suffisamment normalisée pour permettre leur exploitation dans différents environnements.

Imaginons un fichier contenant les limites administratives de plusieurs milliers de communes. Il pourrait être organisé de la manière suivante :

Dans un fichier GeoParquet, les informations descriptives sont stockées dans des colonnes, tandis que les géométries sont conservées dans une colonne spatiale accompagnée de métadonnées.

Le fichier peut alors être exploité par un outil capable de lire la spécification GeoParquet.

Cette possibilité évite certaines conversions intermédiaires et facilite les échanges entre les plateformes analytiques et les logiciels géographiques.

GeoParquet bénéficie aujourd'hui d'une adoption croissante dans l'univers des données géographiques. On peut notamment citer ces plateformes ou librairies :

Cette convergence est intéressante : les données géographiques peuvent progressivement être intégrées aux mêmes infrastructures que les données analytiques classiques.

Il ne s'agit donc plus nécessairement de disposer d'une chaîne de production spécifique pour chaque logiciel SIG.

Il faut néanmoins éviter une confusion, Apache Parquet et GeoParquet sont avant tout des formats de stockage et d'échange. Ils ne proposent pas, à eux seuls, l'ensemble des fonctionnalités d'une Géodatabase ou d'un service d'entités.

Ils ne constituent pas un environnement transactionnel permettant de gérer directement des mises à jour concurrentes, des règles topologiques, des relations complexes ou des workflows de versionnement ou de synchronisation de données.

Leur vocation est différente Alors qu'une géodatabase est conçue pour gérer le cycle de vie complet des données géographiques (création, modification, édition multi-utilisateurs, gestion des règles topologiques, relations entre tables, transactions, etc.), Apache Parquet est avant tout un format de stockage optimisé pour la lecture et l'analyse de grands volumes de données. Parquet ne propose pas nativement les mécanismes de gestion et d'administration d'une base de données. Il ne remplace donc pas une Géodatabase, mais répond à un besoin complémentaire : stocker efficacement des données, faciliter leur échange entre différentes plateformes et permettre leur exploitation analytique sans multiplier les copies et les conversions.

Parquet apporte 3 avantages particulièrement intéressantes pour les architectures de données modernes :

Avec GeoParquet, ces avantages s'étendent aux données géographiques grâce à une description normalisée des géométries et des systèmes de coordonnées.

Pour les utilisateurs SIG, cela ouvre une perspective intéressante : pouvoir exploiter des données géographiques directement issues d'environnements analytiques, sans devoir systématiquement les transformer dans un format traditionnel.

Et c'est précisément cette évolution qu'Esri commence à intégrer dans l'écosystème ArcGIS.

Dans le prochain article, nous verrons comment ArcGIS Pro et ArcGIS Data Pipelines permettent désormais d'exploiter ces fichiers dans les workflows SIG.