Snowflake a annoncé en mars 2026 la préversion publique de sa prise en charge d’Apache Iceberg v3, la dernière version du format de table open-source assurant l’interopérabilité des données entre plateformes. Cette mise à jour introduit des fonctionnalités clés, notamment les row-level deletes, le clustering pour les tables gérées et un nouveau Variant data type pour les données semi-structurées, marquant une expansion significative des capacités du data lakehouse ouvert de Snowflake.
Ces nouvelles fonctionnalités arrivent alors que les organisations exigent une flexibilité croissante dans la gestion des données multi-plateformes, sans vendor lock-in. Selon l’annonce de Snowflake, la spécification v3 introduit également les stratégies Copy-on-Write (CoW) et Merge-on-Read (MoR), offrant aux utilisateurs davantage de souplesse pour la gestion des mises à jour et des suppressions de données.
Au-delà des fonctionnalités phares, la mise à jour inclut les row lineage capabilities qui permettent des cas d’usage de Change Data Capture (CDC) en traçant les modifications au niveau des lignes, fournissant aux organisations un historique clair des changements de données. Cette fonctionnalité s’avère particulièrement utile pour les exigences de conformité et d’audit dans les secteurs réglementés.
Deux modèles de gestion distincts
L’implémentation de Snowflake divise le support des tables Iceberg en deux modèles aux différences fonctionnelles importantes. Les Tables gérées par Snowflake offrent des transactions ACID complètes, la prise en charge des transactions multi-instructions et des capacités de clustering via la fonctionnalité CLUSTERING KEY pour optimiser les performances. Ces tables bénéficient d’une gestion automatisée du cycle de vie par Snowflake, incluant le compactage.
En revanche, les externally-managed tables s’intègrent à des catalogues externes comme AWS Glue ou des systèmes REST mais présentent des limitations. Ces tables ne prennent en charge l’autocommit que pour les opérations d’écriture et nécessitent des outils externes comme Spark pour l’optimisation et la maintenance. À noter que si les tables gérées en externe peuvent lire les données au format v3, le support de l’écriture reste limité à la spécification v2, selon la documentation de Snowflake.
Cette distinction devient critique pour les organisations planifiant leur architecture de données. Les tables gérées par Snowflake offrent un support complet des fonctionnalités v3 incluant les deletion vectors, tandis que les tables gérées en externe avec des row-level deletes fréquentes requièrent une maintenance externe régulière pour prévenir toute dégradation des performances.
Limitations de la préversion et perspectives d’avenir
En tant que fonctionnalité en préversion publique, le support v3 est destiné à l’évaluation et aux tests plutôt qu’à une utilisation en production. Les limitations actuelles incluent l’absence de prise en charge des row-level equality deletes et de certaines propriétés de table. Les fonctionnalités standard de Snowflake telles que Fail-safe, les tables hybrides et l’évolution native du schéma restent indisponibles pour les tables Iceberg.
Snowflake n’a pas annoncé de calendrier pour la disponibilité générale, la feuille de route dépendant probablement des retours clients pendant la période de préversion. Les futurs axes de développement incluent l’extension du support d’écriture v3 aux tables gérées en externe et la fourniture de trajectoires de migration claires de la v2 vers les tables v3.
L’annonce positionne Snowflake de manière plus compétitive sur le marché du lakehouse ouvert, où l’interopérabilité est devenue un différenciateur clé alors que les entreprises cherchent à éviter le vendor lock-in tout en maintenant de hautes performances sur des charges de travail de données diverses.
Sources
- Snowflake
