Iceberg Tables Snowflake : Apache Iceberg, format ouvert et data lakehouse

Si tu suis ma formation depuis le début, tu sais que Snowflake stocke les données dans ses propres micro-partitions, dans un format propriétaire sur le cloud storage. C'est puissant, c'est optimisé, et pour la majorité des cas, c'est exactement ce qu'il faut.

Mais il y a un scénario où :

"Tu veux garder les données dans ton propre stockage, dans un format ouvert et non propriétaire, tout en profitant du moteur Snowflake pour les requêter ?"

C'est précisément là qu'interviennent les Iceberg Tables.

C'est quoi Apache Iceberg ?

Avant de parler de Snowflake, il faut comprendre d'abord c'est quoi Iceberg.

Apache Iceberg, c'est un format de table ouvert, créé à l'origine par Netflix, puis donné à la fondation Apache. L'idée derrière Iceberg, c'est de combler les points faibles des data lakes classiques. (voir l'article sur le data lake)

Si tu n'as pas le temps de lire l'article sur les data lake, un data lake classique, c'est pas cher et flexible, mais ça manque de garanties car il ne dispose pas de transactions ACID, pas de gestion propre des schémas, pas de time travel, pas de partitionnement intelligent....

Iceberg ajoute une couche de métadonnées par dessus tes fichiers Parquet pour te donner :

• Des transactions ACID (comme dans une vraie base de données),
• L'évolution de schéma (ajouter/supprimer/renommer des colonnes sans tout casser),
• Le hidden partitioning (le partitionnement est géré automatiquement, sans que tu crées des sous-dossiers à la main),
• Les snapshots (chaque écriture crée un snapshot, ce qui permet le time travel).

Pour faire simple, Iceberg transforme ton data lake en quelque chose qui ressemble beaucoup plus à un data warehouse, mais en gardant tes données dans un format ouvert et interopérable. Et ça, ça a un nom : c'est le data lakehouse.

Pourquoi Snowflake s'intéresse à Iceberg ?

Si tu as lu l'article sur l'architecture Snowflake, tu sais que Snowflake stocke tout dans ses micro-partitions, dans un format propriétaire. Ça fonctionne très bien tant que tu restes dans l'écosystème Snowflake.

Mais dans la vraie vie, tu as souvent des données qui vivent en dehors de Snowflake :

• Un data lake existant sur S3 avec des fichiers Parquet que d'autres équipes alimentent via Spark ou talend ou un autre outil.
• Des cas où tu veux garder le contrôle total sur ton stockage (compliance, coûts, stratégie multi-cloud....).

C'est pour répondre à ces besoins que Snowflake a intégré le support natif des Iceberg Tables en juin 2024. Et depuis, ça n'arrête pas d'évoluer car le mois dernier (mars 2026), Snowflake a même annoncé le support de la spécification Iceberg v3 en preview. (voir l'annonce)

Comment ça marche concrètement ?

Concrètement en utilisant une Table Iceberg dans Snowflake, les données restent dans ton propre stockage cloud (S3, GCS ou Azure Blob), au format Parquet. Snowflake ne les copie pas en interne. Il se contente de lire (et éventuellement écrire) tes fichiers en s'appuyant sur les métadonnées Iceberg.

Pour que ça fonctionne, tu as besoin de deux objets côté Snowflake :

1. L'External Volume

C'est un objet Snowflake qui fait le lien entre ton compte Snowflake et ton bucket cloud. Il contient les infos d'authentification (IAM role sur AWS par exemple) pour que Snowflake puisse accéder à tes fichiers.

CREATE OR REPLACE EXTERNAL VOLUME my_iceberg_volume
  STORAGE_LOCATIONS = (
    (
      NAME = 'my-s3-location'
      STORAGE_BASE_URL = 's3://mon-bucket/iceberg/'
      STORAGE_PROVIDER = 'S3'
      STORAGE_AWS_ROLE_ARN = 'arn:aws:iam::123456789:role/my-snowflake-role'
    )
  );

2. Le Catalog (catalogue)

Le catalogue, c'est ce qui gère les métadonnées Iceberg et donc où se trouvent les fichiers, quel est le schéma actuel, quels sont les snapshots disponibles, etc.. etc..

Et c'est là que Snowflake te donne le choix entre deux modes (Snowflake-managed et external Catalog)

Snowflake-managed vs External Catalog

C'est un point clé à bien comprendre, parce que ça change complètement ce que tu peux faire avec ta table.

Mode 1 : Snowflake comme catalogue (Snowflake-managed)

Dans ce mode, c'est Snowflake qui gère le catalogue Iceberg. Tes données sont dans ton storage, au format Parquet/Iceberg, mais c'est Snowflake qui pilote les métadonnées, la compréssion, les snapshots, etc..

CREATE OR REPLACE ICEBERG TABLE orders_iceberg (
    order_id INT,
    customer_id INT,
    order_date DATE,
    total_amount DECIMAL(10,2)
)
    CATALOG = 'SNOWFLAKE'
    EXTERNAL_VOLUME = 'my_iceberg_volume'
    BASE_LOCATION = 'orders/';

Avec ce mode, tu as le full support Snowflake :

• Lecture et écriture (INSERT, UPDATE, DELETE, MERGE),
• Time Travel (via les snapshots Iceberg),
• Compression automatique des fichiers,
• Replication cross-region,
• et tu peux même synchroniser ta table avec Snowflake Open Catalog pour que d'autres moteurs puissent la lire.

Mode 2 : Catalogue externe (AWS Glue, Polaris, Unity Catalog…)

Dans ce mode, un système externe gère les métadonnées Iceberg. Snowflake vient lire (et dans certains cas écrire) les tables via une catalog integration.

CREATE OR REPLACE CATALOG INTEGRATION glue_catalog_int
    CATALOG_SOURCE = GLUE
    CATALOG_NAMESPACE = 'my_database'
    TABLE_FORMAT = ICEBERG
    GLUE_AWS_ROLE_ARN = 'arn:aws:iam::123456789:role/my-glue-role'
    GLUE_CATALOG_ID = '123456789'
    GLUE_REGION = 'eu-west-1'
    ENABLED = TRUE;

Ce mode est utile quand :

• Tu as déjà un data lake géré par Spark/Databricks et tu veux juste le requêter depuis Snowflake,
• Tu veux un setup multi-moteur où par exemple Spark écrit et Snowflake lit (ou l'inverse),
• Tu utilises un catalogue centralisé type Polaris ou Unity Catalog de databricks.

Iceberg Tables vs tables Snowflake classiques

La question que pas mal de gens se posent : est-ce qu'on doit migrer toutes les tables en Iceberg ?

La réponse est non.

Les tables Snowflake classiques (avec les micro-partitions propriétaires) restent plus performantes et plus simples pour la majorité des cas. Snowflake gère tout : stockage, compression, pruning, Time Travel, Fail-safe, Zero-Copy Clone.. Tu n'as rien à configurer côté infra.

Les Iceberg Tables, c'est pour des cas spécifiques :

Si toutes tes données vivent dans Snowflake et que tu n'as pas besoin de les lire depuis un autre moteur, les tables classiques restent le meilleur choix. Les Iceberg Tables, c'est quand tu as besoin d'ouverture et d'interopérabilité.

Facturation : qu'est-ce que tu paies ?

Snowflake ne te facture pas le stockage des Iceberg Tables. Les données sont dans ton bucket, c'est ton cloud provider qui te facture le stockage (S3, GCS, Azure Blob).

Ce que Snowflake te facture :

• Le compute (les crédits de virtual warehouse quand tu requêtes tes Iceberg Tables)
• Les Cloud Services (parsing, optimisation, gestion des métadonnées)
• Le refresh automatique des métadonnées si tu l'actives
• Les éventuels coûts de transfert cross-region si ton bucket est dans une région différente de ton compte Snowflake.

Dynamic Iceberg Tables

Un ajout récent qui mérite d'être mentionné et c'est les Dynamic Iceberg Tables. C'est le même concept que les Dynamic Tables classiques (des tables qui se rafraîchissent automatiquement à partir d'une requête source), mais avec une sortie au format Iceberg.

CREATE OR REPLACE DYNAMIC ICEBERG TABLE orders_daily
    TARGET_LAG = '1 hour'
    WAREHOUSE = transform_wh
    CATALOG = 'SNOWFLAKE'
    EXTERNAL_VOLUME = 'my_iceberg_volume'
    BASE_LOCATION = 'orders_daily/'
AS
    SELECT
        order_date,
        COUNT(*) as nb_orders,
        SUM(total_amount) as revenue
    FROM orders_iceberg
    GROUP BY order_date;

Tu définis ta transformation, Snowflake la rafraîchit automatiquement selon le TARGET_LAG, et le résultat est stocké en format Iceberg dans ton propre stockage. Le tout sans orchestrateur externe.

Iceberg Tables dans SnowPro Core COF-C03

Les Iceberg Tables font partie des nouveautés introduites par la COF-C03 (l'examen actuel depuis février 2026), au même titre que Snowflake Cortex AI et les Snowflake Notebooks. Les sujets les plus testés sont :

• External Volume : configuration, IAM role, mode lecture seule vs lecture/écriture
• Snowflake-managed vs External Catalog : différences en termes de fonctionnalités (lecture seule, écriture, Time Travel)
• Facturation : qui paie quoi (Snowflake compute + Cloud Services, ton cloud pour le stockage)
• Différences vs tables classiques : ce qui marche (lecture, écriture, transactions ACID) et ce qui ne marche pas (Fail-safe, Zero-Copy Clone classique)
• Dynamic Iceberg Tables : usage et différences avec les Dynamic Tables classiques

Pour t'entraîner sur ces sujets dans les conditions de l'examen COF-C03, le module SnowPro Core de DataCertification.fr propose 700 questions scenario-based, dont une partie dédiée aux nouveautés COF-C03 (Iceberg, Cortex AI, Notebooks).

👉 Préparer la SnowPro Core sur DataCertification.fr

Pour comprendre toutes les différences entre COF-C02 et COF-C03, voir aussi SnowPro Core COF-C03 : ce qui change et comment s'y préparer.

Aller plus loin : Formation Snowflake

J'ai regroupé tous mes articles Snowflake dans un parcours complet.

👉 Accéder à la Formation Snowflake

Vous voulez que je vous accompagne sur votre projet data (Snowflake, ingestion, modélisation, performance, coûts, gouvernance) ?

👉 Réserver un appel de 30 minutes

Questions