Utiliser les contraintes d’immuabilité¶
Pour indiquer à Snowflake que certaines lignes ne changeront pas dans une table dynamique, utilisez la clause IMMUTABLE WHERE dans une instruction CREATE DYNAMIC TABLE ou ALTER DYNAMIC TABLE.
L’immuabilité rend les actualisations plus rapides en ignorant les lignes qui ne changent pas. Le remplissage rétroactif associé à l’immuabilité offre des avantages en termes de performances immédiats et continus :
Création initiale : Le remplissage rétroactif copie les données historiques instantanément sans frais de calcul. Cela rend les tables contenant des années de données historiques immédiatement disponibles au lieu de nécessiter des actualisations initiales coûteuses.
Actualisations en cours : Les contraintes d’immuabilité protègent les données réintégrées contre tout nouveau traitement lors des actualisations futures. Seule la région muable est actualisée, ce qui permet de conserver des temps d’actualisation rapides même lorsque le tableau s’agrandit.
Pour un arrière-plan conceptuel, voir Compréhension des contraintes d’immuabilité.
Exemples de base¶
Exemple : Empêcher le recalcul lorsqu’une table de dimension est modifiée¶
Lorsque vous mettez à jour une ligne dans une table de dimension, ne retraitez que les faits de la période muable :
Exemple : Conserver les données plus longtemps que dans la table source¶
Créez une table dynamique qui conserve les données analysées plus longtemps que la table de mise en zone de préparation, et supprimez les anciennes données de mise en zone de préparation à l’aide d’une tâche :
Exemple : Autoriser les tables en aval à utiliser l’actualisation incrémentielle à partir d’une table d’actualisation complète¶
Certaines constructions de requêtes (comme les fonctions de table définies par l’utilisateur en Python) nécessitent un mode d’actualisation complet. Les contraintes d’immuabilité permettent aux tables en aval de toujours utiliser l’actualisation incrémentielle :
Exemples de remplissage rétroactif¶
Les exemples suivants montrent comment créer de nouvelles tables dynamiques à partir de tables avec des données remplies.
La table de remplissage rétroactif doit contenir des colonnes correspondantes dont les types de données sont compatibles dans le même ordre que votre table dynamique. Snowflake ne copie pas les propriétés ou les privilèges de la table depuis la table de remplissage rétroactif.
Si vous spécifiez les paramètres Time Travel AT | BEFORE, Snowflake copie les données de la table de remplissage rétroactif à l’heure spécifiée.
Les limitations suivantes s’appliquent lorsque vous utilisez des contraintes d’immuabilité et des données réintégrées :
Actuellement, seules les tables standards et dynamiques peuvent être utilisées pour le remplissage.
Vous ne pouvez pas spécifier de politiques ni de balises dans la nouvelle table dynamique, car elles sont copiées à partir de la table de remplissage.
Les clés de clustering de la nouvelle table dynamique et de la table de remplissage doivent être identiques.
Exemple : Remplissage à partir d’une partie de la table¶
L’exemple suivant remplit la région immuable de my_dynamic_table à partir de my_backfill_table et de la région mutable de la définition de la table dynamique.
Lorsque vous réinitialisez cette table dynamique :
Mode d’actualisation incrémentielle : Snowflake supprime toutes les lignes muables et ne remplit que la région muable.
Mode d’actualisation complet : Snowflake effectue une actualisation complète avec le même effet.
Exemple : Utiliser le remplissage rétroactif pour récupérer ou modifier des données dans une table dynamique¶
Vous ne pouvez pas modifier directement les données ou la définition d’une table dynamique. Pour récupérer ou corriger des données, procédez comme suit :
Cloner la table dynamique ver une table standard.
Modifiez la table clonée selon vos besoins.
Effectuez le remplissage depuis la table modifiée vers une nouvelle table dynamique.
Dans l’exemple suivant, my_dynamic_table agrège les données de ventes quotidiennes de la tables de base sales :
Vous pouvez également archiver les anciennes données pour réduire les coûts de stockage :
Plus tard, vous trouvez une erreur de vente sur 2025-05-01, où sales_count devrait être 2. Pour corriger cela :
Clonez
my_dynamic_tablevers une table ordinaire :Mettez à jour la table clonée :
Recréez la table dynamique en utilisant le clone modifié comme source de remplissage.
Cette méthode vous permet de récupérer ou de corriger les données d’une table dynamique sans modifier la table de base :
Exemple : Modifier le schéma d’une table dynamique à l’aide du remplissage¶
Vous ne pouvez pas modifier directement le schéma d’une table dynamique. Pour mettre à jour le schéma, par exemple, ajouter une colonne, procédez comme suit :
Cloner la table dynamique ver une table standard. L’exemple suivant utilise
my_dynamic_tablecréée à partir desales(précédemment).Modifiez le schéma de la table clonée :
Si vous le souhaitez, ajoutez des données à la nouvelle colonne.
Recréez la table dynamique en utilisant le clone modifié comme source de remplissage.
Vérifiez que la nouvelle colonne apparaît dans la table dynamique :
Vérifier le statut d’immuabilité¶
Pour vérifier si une ligne est muable dans une table dynamique, interrogez la colonne METADATA$IS_IMMUTABLE :
Pour afficher la contrainte d’immuabilité sur une table dynamique, exécutez SHOW DYNAMIC TABLES et vérifiez la colonne immutable_where.