Apache Iceberg : vers un lakehouse pour les données ouvertes
Les portails de données ouvertes reposent encore largement sur des formats statiques — CSV, JSON, GeoJSON — distribués fichier par fichier. Cette approche, héritée des débuts de l’open data, montre ses limites face à l’explosion des volumes, aux besoins de versioning et à l’exigence croissante de requêtes analytiques performantes. Apache Iceberg, format de table ouvert conçu pour le lakehouse, apporte une réponse structurante à ces problématiques.
Qu’est-ce qu’Apache Iceberg ?
Apache Iceberg est un format de table open source, initialement développé par Netflix, qui fonctionne au-dessus de systèmes de stockage objet (S3, MinIO, HDFS). Contrairement aux formats plats, Iceberg gère nativement le schéma, le partitionnement, le versioning des données et les transactions ACID. Il sépare clairement les métadonnées de la donnée elle-même, ce qui permet des opérations comme le time travel (interroger les données à un instant T passé) ou l’évolution de schéma sans réécriture complète.
Pourquoi c’est pertinent pour l’open data
Dans un contexte de portail de données ouvertes — typiquement CKAN couplé à un datastore — les jeux de données volumineux posent des problèmes récurrents : temps de chargement via xloader, absence de versioning exploitable, impossibilité de requêtes analytiques complexes sans ETL préalable. Iceberg répond à plusieurs de ces irritants :
- Versioning natif : chaque modification d’un jeu de données produit un snapshot immutable. Les consommateurs peuvent accéder à n’importe quelle version sans duplication de fichiers.
- Requêtes performantes : grâce au partitionnement caché (hidden partitioning) et aux statistiques de colonnes intégrées aux métadonnées, les moteurs de requête (Trino, Spark, DuckDB) peuvent élaguer efficacement les données sans scanner l’intégralité du dataset.
- Évolution de schéma : ajouter ou renommer une colonne ne casse pas les consommateurs existants. Le format gère la compatibilité ascendante de manière transparente.
- Interopérabilité : Iceberg est supporté par un écosystème large — Trino, Spark, Flink, DuckDB, Polaris (catalogue REST) — ce qui évite le verrouillage technologique.
Architecture type avec CKAN et Iceberg
Une architecture réaliste pour un portail open data moderne pourrait combiner CKAN comme interface de catalogage et de publication, MinIO ou S3 comme stockage objet, Apache Iceberg comme format de table pour les jeux de données volumineux, et Polaris comme catalogue REST pour exposer les tables Iceberg. Le flux serait le suivant : les producteurs de données publient via CKAN, un pipeline d’ingestion (via Airflow, dagster ou un simple script Python avec PyIceberg) convertit les données en tables Iceberg sur le stockage objet, et les consommateurs interrogent directement via Trino ou DuckDB sans passer par l’API CKAN pour les requêtes analytiques.
Limites et points d’attention
Iceberg n’est pas une solution universelle. Pour des jeux de données légers (quelques milliers de lignes), le surcoût en métadonnées et en infrastructure n’est pas justifié. Le format suppose également une compétence data engineering minimale pour la mise en place du catalogue et des pipelines d’ingestion. Enfin, l’intégration avec CKAN n’est pas native et nécessite un développement spécifique — extension CKAN, connecteur ou middleware dédié.
En pratique : premiers pas
Pour expérimenter, le chemin le plus court consiste à utiliser PyIceberg avec un catalogue SQLite local et un stockage fichier. En quelques lignes de Python, on peut créer une table, y insérer des données, faire évoluer le schéma et interroger des snapshots passés. DuckDB permet ensuite de requêter ces tables Iceberg sans infrastructure lourde, ce qui en fait un excellent outil de prototypage avant un déploiement sur Trino ou Spark.
Conclusion
Apache Iceberg représente une brique technique clé pour faire évoluer les portails de données ouvertes au-delà du simple dépôt de fichiers. En combinant versioning, performance analytique et interopérabilité, il offre un socle solide pour construire un véritable lakehouse de données publiques. Pour les équipes qui gèrent des portails CKAN avec des jeux de données volumineux, c’est une piste d’architecture à explorer sérieusement.
