Apache Iceberg et Polaris : le catalogue ouvert pour vos données

Comment structurer un lac de données interopérable avec des formats ouverts — et pourquoi c’est important pour les portails open data.

Infrastructure · Données ouvertes · Open source

Le problème des silos de données

Les organisations qui publient ou gèrent des données structurées se heurtent rapidement à la même limite : chaque outil lit ses propres formats, dans son propre dépôt. Une export CSV ici, un dump Postgres là, un entrepôt Parquet ailleurs. Résultat : les données ne peuvent pas être interrogées de façon unifiée, les métadonnées sont dispersées, et la traçabilité des versions disparaît.

C’est précisément le problème qu’Apache Iceberg cherche à résoudre. Il propose un format de table ouvert qui s’intercale entre le stockage objet (S3, MinIO, Azure Blob…) et les moteurs de requête (Spark, DuckDB, Trino, Flink…), en ajoutant une couche de catalogue et de versionnage.

Ce qu’est Apache Iceberg

Apache Iceberg est une spécification de table pour les grands ensembles de données stockés en fichiers. Il ne remplace pas votre moteur de calcul : il définit comment les données et leurs métadonnées sont organisées sur le disque ou dans un stockage objet, de façon à ce que n’importe quel moteur compatible puisse les lire correctement.

Concrètement, une table Iceberg est composée de :

Fichiers de données : au format Parquet, ORC ou Avro, stockés dans un dossier.
Fichiers de manifeste : listes des fichiers appartenant à un snapshot donné.
Fichier de métadonnées : décrit le schéma, les partitions, l’historique des snapshots.
Pointeur de catalogue : indique quel snapshot est le courant.

Cette architecture permet des fonctionnalités que les fichiers Parquet bruts n’offrent pas : time travel (lire les données à une date passée), rollback, schéma évolutif, et partition pruning efficace sans scanner tous les fichiers.

Polaris : le catalogue REST pour Iceberg

Un catalogue est le registre qui dit à un moteur « la table communes se trouve à cet emplacement, avec ce schéma ». Sans catalogue, chaque moteur doit connaître le chemin exact des fichiers.

Apache Polaris (anciennement Snowflake Open Catalog, maintenant sous Apache) est un serveur de catalogue REST conforme à la spécification Iceberg REST Catalog API. Il expose des endpoints HTTP standardisés que tout moteur compatible Iceberg peut interroger pour découvrir et gérer les tables.

Son avantage principal : il est indépendant du moteur. Que vous utilisiez DuckDB localement, Spark sur un cluster, ou Trino dans un environnement conteneurisé, tous parlent le même protocole REST et lisent les mêmes tables.

Polaris peut se déployer en Docker, se connecter à un stockage S3 ou MinIO, et être administré via une API REST. C’est une brique réaliste pour un portail open data qui veut exposer ses données de façon interopérable.

Démarrer avec Polaris en Docker

Polaris fournit une image Docker officielle. Un déploiement minimal se fait ainsi :

# Lancer Polaris avec stockage local (pour les tests)
docker run -p 8181:8181 \
  -e AWS_ACCESS_KEY_ID=minioadmin \
  -e AWS_SECRET_ACCESS_KEY=minioadmin \
  apache/polaris:latest

Le service écoute sur le port 8181 et expose l’API REST Iceberg. Pour le connecter à MinIO (équivalent S3 auto-hébergé) :

version: "3.9"
services:
  minio:
    image: minio/minio
    command: server /data --console-address ":9001"
    ports: ["9000:9000", "9001:9001"]
    environment:
      MINIO_ROOT_USER: minioadmin
      MINIO_ROOT_PASSWORD: minioadmin

  polaris:
    image: apache/polaris:latest
    ports: ["8181:8181"]
    environment:
      AWS_ACCESS_KEY_ID: minioadmin
      AWS_SECRET_ACCESS_KEY: minioadmin
      AWS_REGION: us-east-1
      POLARIS_S3_ENDPOINT: http://minio:9000

Lire une table Iceberg avec DuckDB

Une fois vos tables Iceberg enregistrées dans Polaris, DuckDB peut les interroger directement via l’extension iceberg :

-- Installation de l'extension
INSTALL iceberg;
LOAD iceberg;

-- Lecture d'une table Iceberg depuis MinIO
SELECT *
FROM iceberg_scan(
  's3://mon-bucket/tables/communes/',
  endpoint_url='http://localhost:9000',
  key_id='minioadmin',
  secret='minioadmin'
)
LIMIT 10;

Le même fichier Parquet sous-jacent peut être lu simultanément par Spark, Trino ou DuckDB — sans conflit, car Iceberg gère l’isolation des snapshots.

Iceberg et les portails open data

Pour un portail CKAN, Iceberg ouvre des perspectives intéressantes. Plutôt que de stocker des exports CSV versionnés manuellement, on peut exposer directement des tables Iceberg comme ressources. Un utilisateur pourrait ainsi interroger l’historique complet d’un jeu de données (time travel), ou recevoir automatiquement la version la plus récente via un moteur SQL.

Des projets comme CKAN + DuckDB ou CKAN + Parquet endpoints vont dans ce sens. Iceberg fournit la fondation pour aller plus loin : interopérabilité des moteurs, gouvernance des versions, et compatibilité avec des standards comme le GeoParquet pour les données géographiques.

Points de vigilance

Iceberg et Polaris sont encore en phase de maturité : la spec REST Catalog est stable, mais l’écosystème autour (sécurité, RBAC, multi-tenant) est en évolution rapide.
Le déploiement de Polaris nécessite un stockage objet fiable (MinIO en production, pas juste local).
DuckDB est idéal pour l’exploration locale ; pour des volumes importants en production, Trino ou Spark restent plus adaptés.
L’intégration native avec CKAN n’est pas encore standardisée : il faut un adaptateur custom ou une couche API intermédiaire.