Gestion des tables Apache Iceberg™¶

Exemple : Mettre à jour une table¶

Vous pouvez utiliser les instructions INSERT et UPDATE pour modifier les tables Iceberg gérées par Snowflake.

L’exemple suivant insère une nouvelle valeur dans une table Iceberg nommée store_sales, puis met à jour la colonne cola sur 1 si la valeur est actuellement -99.

INSERT INTO store_sales VALUES (-99);

UPDATE store_sales
  SET cola = 1
  WHERE cola = -99;

Interroger des tables¶

Snowflake prend en charge l’interrogation de tables Iceberg gérées en externe lorsque vous avez configuré les suppressions au niveau de la ligne pour les opérations de mise à jour, de suppression et de fusion.

Pour configurer les suppressions de niveau ligne, voir les propriétés d’écriture dans la documentation d’Apache Iceberg.

Écriture dans des tables via des fichiers de suppression positionnels¶

Snowflake prend en charge les suppressions de position au niveau des lignes pour l’écriture dans des tables Iceberg gérées en externe et stockées sur Amazon S3, Azure ou Google Cloud. Pour désactiver les suppressions de position, qui permettent l’exécution des opérations DML en mode copie sur écriture, définissez le paramètre ENABLE_ICEBERG_MERGE_ON_READ sur FALSE au niveau de la table, du schéma ou de la base de données.

Écriture dans des tables via des vecteurs de suppression¶

Pour optimiser les modifications des données au niveau des lignes, Snowflake prend en charge les vecteurs de suppression pour l’écriture dans des tables Iceberg gérées en externe et gérées par Snowflake stockées sur Amazon S3, Azure ou Google Cloud. Avec les vecteurs de suppression, Snowflake peut effectuer des opérations de « fusion sur lecture » (MOR), qui améliorent les performances d’écriture pour les instructions DML suivantes :

• DELETE

• UPDATE

• MERGE

Snowflake atteint cette performance en écrivant de petits fichiers vectoriels au lieu de réécrire de gros fichiers de données. Pour plus d’informations, consultez Suppression de vecteurs dans la spécification Apache Iceberg.

Copie sur écriture ou fusion sur lecture¶

Iceberg propose deux modes de configuration de la manière dont les moteurs de calcul gèrent les opérations de niveau ligne pour les tables gérées en externe. Snowflake prend en charge ces deux modes.

Le tableau suivant décrit les cas dans lesquels vous pourriez avoir besoin d’utiliser l’un ou l’autre mode :

Pour plus d’informations sur les modifications de niveau ligne pour Iceberg, voir Suppressions de niveau ligne dans la documentation d’Apache Iceberg.

Considérations et limites¶

Tenez compte des informations suivantes lorsque vous utilisez des suppressions de niveau de lignes avec des tables Iceberg :

• Snowflake prend en charge les suppressions de position uniquement pour les tables Iceberg v2, et les vecteurs de suppression pour les tables Iceberg v3.

• Snowflake ne prend en charge que les suppressions de positions avec des tables Iceberg gérées en externe.

• Pour obtenir les meilleures performances de lecture lorsque vous utilisez des suppressions de niveau ligne, procédez régulièrement au compactage et à la maintenance des tables afin de supprimer les anciens fichiers de suppression. Pour plus d’informations, voir Gestion des tables utilisant un catalogue externe.

• Des suppressions de position excessives, en particulier des suppressions de position en suspens, peuvent empêcher les opérations de création et d’actualisation des tables. Pour éviter ce problème, effectuez la maintenance des tables pour supprimer les suppressions de position supplémentaires.

  La méthode de maintenance des tables à utiliser dépend de votre moteur Iceberg externe. Par exemple, vous pouvez utiliser la méthode rewrite_data_files pour Spark avec les options delete-file-threshold ou rewrite-all. Pour plus d’informations, consultez rewrite_data_files dans la documentation Apache Iceberg™.

Clustering automatique¶

Le clustering automatique réorganise les données en fichiers ou partitions en fonction des colonnes fréquemment interrogées. La taille de fichier pour les tables Iceberg est basée sur la configuration de votre clustering, à moins que vous ne définissiez une taille de fichier cible. Si vous le faites, la taille de fichier correspond à la taille spécifique que vous avez définie. Pour plus d’informations, voir Définir une taille de fichier cible.

Pour définir le clustering automatique, spécifiez le paramètre CLUSTER BY lorsque vous créez une table Iceberg gérée par Snowflake ou que vous modifiez une table existante. Pour plus d’informations, voir :

• CREATEICEBERGTABLE (Snowflake comme catalogue Iceberg)

• ALTER ICEBERG TABLE

Pour plus d’informations sur le clustering automatique, consultez Clustering automatique.

Compactage des données¶

Le compactage des données combine de petits fichiers en fichiers plus volumineux et plus efficaces pour gérer le stockage, maintenir une taille optimale des fichiers, et améliorer les performances des requêtes.

Dans la plupart des cas, le compactage des données n’a pas d’effet significatif sur les coûts de calcul, mais si ces coûts constituent un problème, vous pouvez désactiver le compactage. Par exemple, vous pouvez souhaiter désactiver le compactage sur une table si vous l’interrogez rarement. Pour désactiver ou activer le compactage des données, consultez Définition du compactage des données.

Compactage des manifestes¶

Le compactage des manifestes optimise la couche de métadonnées en réorganisant et en combinant des fichiers manifestes plus petits. Ce compactage réduit la surcharge des métadonnées et améliore les performances des requêtes.

Cette fonctionnalité est activée automatiquement et vous ne pouvez pas la désactiver.

Expiration de l’instantané¶

L’expiration des instantanés supprime systématiquement les anciens instantanés et leurs fichiers de données et de métadonnées uniques de l’historique de la table. Cette suppression est basée sur des politiques de conservation prédéfinies.

Cette fonctionnalité est activée automatiquement et vous ne pouvez pas la désactiver.

Actualisation des métadonnées d’une table¶

L’exemple suivant actualise manuellement les métadonnées d’une table qui utilise un catalogue externe (par exemple, AWS Glue ou Delta). L’actualisation de la table permet de synchroniser la table en permanence en fonction des modifications apportées dans le catalogue distant.

Avec ce type de table Iceberg, il n’est pas nécessaire de spécifier un chemin d’accès au fichier de métadonnées dans la commande.

ALTER ICEBERG TABLE my_iceberg_table REFRESH;

Pour assurer la mise à jour automatique d’une table, vous pouvez paramétrer l”actualisation automatique. Utilisez la commande ALTER ICEBERG TABLE.

Par exemple :

ALTER ICEBERG TABLE my_iceberg_table SET AUTO_REFRESH = TRUE;

Actualisation des métadonnées d’une table créée à partir de fichiers Iceberg¶

L’exemple suivant actualise manuellement une table créée à partir de fichiers de métadonnées Iceberg dans un emplacement de stockage cloud externe, en spécifiant le chemin d’accès relatif à un fichier de métadonnées sans barre oblique (/). Le fichier de métadonnées définit les données de la table après actualisation.

ALTER ICEBERG TABLE my_iceberg_table REFRESH 'metadata/v1.metadata.json';

Exemple : Créer une table avec une valeur par défaut¶

Pour créer une table Iceberg avec des valeurs par défaut, utilisez la commande CREATE ICEBERG TABLE.

Dans l’exemple suivant, vous définissez d’abord une valeur par défaut pour une colonne lorsque vous créez une table Iceberg gérée par Snowflake. Ensuite, vous insérez un enregistrement dans la table sans spécifier de valeur pour la colonne avec la valeur par défaut.

1. Créez une table user_events, qui comprend une colonne event_version avec une valeur par défaut de 2 :

   CREATE ICEBERG TABLE user_events (
       event_id INT,
       user_id INT,
       event_type STRING,
       event_time TIMESTAMP,
       event_version INT DEFAULT 2
     )
     CATALOG = 'SNOWFLAKE'
     EXTERNAL_VOLUME = 'my_external_volume'
     BASE_LOCATION = 'database/schema/user_event'
     ICEBERG_VERSION = 3;
   

   Copy

   La définition d’une valeur par défaut dans la définition de la table définit une valeur par défaut initiale et une valeur par défaut d’écriture. Comme la colonne a une écriture par défaut, la valeur 2 sera utilisé pour les nouveaux enregistrements si la event_version n’est pas spécifiée lors des écritures.

2. Ajoutez un événement de connexion avec une event_version spécifiée :

   INSERT INTO user_events VALUES
     (1, 101, 'login', '2025-11-01 10:00:00', 1);
   

   Copy

3. Ajoutez un événement d’achat, mais sans spécifier de event_version :

   INSERT INTO user_events VALUES
   (1, 101, 'purchase', '2025-11-01 10:01:00');
   

   Copy

   Par conséquent, Snowflake entre la valeur pour event_version dans la table en tant que 2.

4. Interrogez la table :

   SELECT * FROM user_events;
   

   Copy

   Sortie :

   +-----------+----------+-------------+---------------------+----------------+
   | event_id  | user_id  | event_type  | event_time          | event_version  |
   +-----------+----------+-------------+---------------------+----------------+
   | 1         | 101      | login       | 2025-11-01 10:00:00 | 1              |
   | 1         | 101      | purchase    | 2025-11-01 10:01:00 | 2              |
   +-----------+----------+-------------+---------------------+----------------+
   

Exemple : Ajouter une colonne avec une valeur par défaut à une table existante¶

Pour ajouter une nouvelle colonne avec une valeur par défaut à une table Iceberg, utilisez la commande ALTER ICEBERG TABLE.

Dans l’exemple suivant, vous modifiez la table user_events en ajoutant une colonne event_version, qui a une valeur par défaut de 2 :

ALTER ICEBERG TABLE user_events ADD COLUMN event_version INT DEFAULT 2;

Outre la définition d’une valeur par défaut en écriture, l’ajout d’une colonne avec une valeur par défaut définit également une valeur par défaut initiale pour la colonne. Par conséquent, la valeur par défaut des enregistrements existants pour la colonne event_version est 2.

Exemple : Modifier l’écriture par défaut d’une colonne¶

L’exemple suivant modifie l’écriture par défaut pour la colonne event_version de la table user_events en 3 :

ALTER ICEBERG TABLE user_events ALTER COLUMN event_version SET WRITE DEFAULT 3;

Afficher les valeurs par défaut définies pour une table¶

Pour afficher la valeur par défaut d’une colonne de table dans une table Iceberg gérée par Snowflake ou en externe, exécutez la commande DESCRIBE ICEBERG TABLE, puis affichez la colonne DEFAULT et la colonne WRITE DEFAULT dans la sortie :

• La colonne DEFAULT mappe sur la valeur initial-default dans la spécification Apache Iceberg.

• La colonne WRITE DEFAULT mappe sur la valeur write-default dans la spécification Apache Iceberg.

Ces colonnes sont renvoyées dans la sortie, que la table soit une table v2 Iceberg ou une table v3 Iceberg.

L’exemple suivant décrit les colonnes pour la table user_events. Cette table possède une valeur initiale par défaut et une valeur d’écriture par défaut spécifiées pour la colonne event_version :

DESC ICEBERG TABLE user_events
  ->> SELECT
    "name",
    "kind",
    "default",
    "write default"
      FROM $1;

Sortie :

+-----------------+---------+---------+---------------+
| name            | kind    | default | write default |
+-----------------+---------+-------------------------+
| EVENT_ID        | COLUMN  |         |               |
| USER_ID         | COLUMN  |         |               |
| EVENT_TYPE      | COLUMN  |         |               |
| EVENT_TIME      | COLUMN  |         |               |
| EVENT_VERSION   | COLUMN  | 2       | 3             |
+-----------------+---------+---------+---------------+

Supprimer l’écriture par défaut¶

Pour supprimer l’écriture par défaut d’une colonne, utilisez les mots-clés DROP WRITE DEFAULT avec la commande ALTER ICEBERG TABLE.

L’exemple suivant supprime la valeur d’écriture par défaut pour la colonne event_version :

ALTER ICEBERG TABLE user_events ALTER COLUMN event_version DROP WRITE DEFAULT;

Considérations et limitations relatives aux valeurs par défaut¶

Tenez compte des éléments suivants lorsque vous utilisez des valeurs par défaut avec des tables Iceberg gérées par Snowflake et des tables Iceberg gérées en externe :

Considérations et limitations relatives à la lignée de lignes¶

La lignée de lignes est prise en charge dans les flux avec les considérations suivantes :

• Les flux d’ajout uniquement et les flux standard sont pris en charge sur les tables Iceberg v3 gérées par Snowflake.

• Les flux d’insertion uniquement et les flux standard sont pris en charge sur les tables Iceberg v3 gérées en externe.

  • Pour que les flux standard produisent les bons résultats, le moteur externe doit écrire dans les tables Iceberg v3 par rapport à la spécification Iceberg v3. Plus précisément, les lignes nouvellement insérées devraient avoir _row_id=NULL. Les lignes qui sont copiées pendant la copie sur écriture doivent maintenir l’_row_id.

  • MAX_DATA_EXTENSION_TIME_IN_DAYS ne fonctionne pas sur les tables Iceberg v3 gérées en externe.

• Lorsque des DMLs sont validés sur des transactions à plusieurs instructions, les flux d’ajout uniquement sur les tables Iceberg v3 ont une sémantique différente de celle des tables Iceberg v2 :

  • Sur Iceberg v2, pour les flux d’ajout uniquement, si une ligne est ajoutée puis supprimée dans une transaction à plusieurs instructions, cette ligne est considérée comme une insertion.

  • Sur Iceberg v3, pour les flux d’ajout uniquement, cette ligne n’est pas traitée comme une insertion.

Ces considérations et limitations s’appliquent à la lignée de lignes, qui est une fonctionnalité d’Iceberg v3. Pour une liste des considérations et limitations qui s’appliquent à toutes les tables Iceberg v3, consultez Considérations et limites des fonctionnalités Iceberg v3.