Comprendre l’initialisation et l’actualisation des tables dynamiques¶
Le contenu d’une table dynamique est défini par une requête et se met automatiquement à jour, on appelle cela une actualisation : les données sous-jacentes changent. Ce processus analyse la requête pour maintenir la table à jour.
Les sections suivantes expliquent plus en détail l’actualisation des tables dynamiques :
Section |
Description |
|---|---|
Introduit l’initialisation, ou en d’autres termes, la population initiale de données lorsque vous créez une table dynamique. Vous pouvez spécifier le moment de l’actualisation initiale. |
|
Comprendre les options d’actualisation manuelle et planifiée |
Aperçu de l’actualisation des tables dynamiques. Les tables dynamiques sont actualisées selon une planification, à moins qu’elles ne soient actualisées manuellement. |
Les tables dynamiques prennent en charge différents modes d’actualisation : incrémentielle, complète et AUTO. |
|
Découvrez comment les tables dynamiques s’actualisent en fonction de leurs dépendances. |
|
Présentation des effets des modifications apportées aux colonnes des tables de base |
Compréhension de l’initialisation des tables dynamiques¶
Lorsque vous créez une table dynamique, son actualisation initiale a lieu soit de manière synchrone lors de la création, soit à un moment planifié. Le renseignement initial des données, ou initialisation, dépend du moment où cette actualisation initiale a lieu.
Les tableaux dynamiques sont actualisés en fonction de la latence cible spécifiée, qui définit le délai maximal autorisé entre les mises à jour des tables de base et le contenu du tableau dynamique. Si vous définissez INITIALIZE = ON_CREATE (valeur par défaut), la table est initialisée immédiatement. Si vous avez choisi INITIALIZE = ON_SCHEDULE, l’initialisation a lieu dans le délai de latence cible spécifié.
Prenons l’exemple d’une table dynamique, DT1, dont la latence cible est de 30 minutes. Le renseignement initial des données de DT1 peut se produire comme suit :
Si
DT1est définie pour s’actualiser de manière synchrone à la création (ON_CREATE), elle s’initialise à la création.Si la table
DT1est définie pour être actualisée à une heure planifiée (ON_SCHEDULE), elle s’initialise dans les 30 minutes qui suivent.
Dans les scénarios comportant des dépendances en aval, le comportement d’actualisation dépend des dépendances. Par exemple, si la table dynamique DT1 a une latence cible en aval et que DT2, qui dépend de la table DT1, a une latence cible de 30 minutes, la table DT1 ne s’actualise que lorsque la table DT2 s’actualise.
Pour DT1 :
Si celle-ci est définie pour une actualisation synchrone à la création, elle s’initialise immédiatement. En cas d’échec de l’initialisation, le processus de création s’arrête, fournissant un retour d’information immédiat sur les erreurs éventuelles.
Si elle est définie pour s’actualiser à une heure planifiée, l’initialisation dépend de l’heure d’actualisation de la table
DT2.
L’initialisation peut prendre un certain temps, suivant la quantité de données analysées. Pour suivre les progrès réalisés, voir Dépannage de la création de tables dynamiques.
Comprendre les options d’actualisation manuelle et planifiée¶
Les tables dynamiques sont actualisées selon une planification déterminée par la latence cible. Chaque fois qu’une table dynamique est lue, l’actualisation des données se fait dans la période définie par la latence cible.
Vous pouvez actualiser manuellement vos tables dynamiques pour obtenir les données les plus récentes à l’aide de la commande ALTER DYNAMIC TABLE … REFRESH ou Snowsight. Pour plus d’informations, voir Actualiser manuellement les tables dynamiques.
Les délais d’expiration de l’actualisation des tables dynamiques sont contrôlés par le paramètre STATEMENT_TIMEOUT_IN_SECONDS, qui définit la durée maximale autorisée au niveau du compte ou de l’entrepôt avant qu’une actualisation ne soit automatiquement annulée.
Comment la latence cible affecte-t-elle les actualisations planifiés ?¶
La latence cible contrôle la fréquence des actualisations planifiés. Pour gérer manuellement les actualisations, définissez la latence cible de votre table dynamique sur DOWNSTREAM et assurez-vous que toutes les tables dynamiques en aval sont également définies sur DOWNSTREAM.
Le fait de définir la latence cible du graphe orienté acyclique (DAG) sur DOWNSTREAM désactive essentiellement les actualisations planifiées, car la table dynamique finale contrôle la planification de l’actualisation. Si aucune table dynamique n’a de latence cible basée sur le temps, le pipeline est suspendu pour les actualisations planifiés. Dans ce cas, l’actualisation manuelle de la table la plus en aval actualise automatiquement toutes les dépendances en amont.
Le fait de paramétrer la latence cible à DOWNSTREAM ne permet pas de préciser les heures exactes. Au lieu de cela, Snowflake choisit une cadence d’actualisation pour tenter de maintenir la latence sous la valeur cible. Par exemple, une table dynamique avec une latence cible de 4 heures peut être actualisée toutes les 3,5 heures.
Pour spécifier des heures exactes, vous pouvez utiliser une tâche avec une planification CRON. Pour plus d’informations, voir. Actualiser manuellement les tables dynamiques.
Modes d’actualisation des tables dynamiques¶
Dynamic tables support three refresh modes: auto, incremental, and full. You can either set the refresh mode to AUTO or set it explicitly:
AUTO refresh mode: When using the
AUTOparameter, Snowflake automatically selects the most cost- and time-effective refresh mode based on query complexity, supported constructs, operators, functions, and expected performance. This decision is made only once at the time of table creation. If incremental refresh is unsupported or inefficient, Snowflake chooses full refresh instead.Par exemple, si une table dynamique fait référence à une vue et que la définition de la vue change de manière asynchrone, le mode d’actualisation reste inchangé. Si la décision d’origine était incrémentielle mais n’est plus prise en charge (par exemple, en raison d’un changement de vue en amont), l’actualisation échouera avec une erreur du type
Dynamic table can no longer be refreshed incrementally because an upstream view changed.Pour modifier le mode d’actualisation, recréez la table dynamique à l’aide de la commande CREATEORREPLACEDYNAMICTABLE.
Mode d’actualisation incrémentielle : ce mode analyse la requête de la table dynamique et calcule les changements depuis la dernière actualisation. Il fusionne ensuite ces modifications dans la table.
Mode d’actualisation complète : ce mode exécute la requête de la table dynamique et remplace complètement les résultats précédemment matérialisés.
For guidance on when to use incremental refresh versus full refresh, see Sélectionner un mode d’actualisation. To check which refresh mode an existing dynamic table uses, see Actualiser le mode.
Important
Les tables dynamiques en mode d’actualisation incrémentielle ne peuvent pas être placées en aval des tables dynamiques en mode d’actualisation complète. En effet, le mode d’actualisation incrémentielle est incompatible avec les changements de lignes complets qui se produisent lors de chaque actualisation d’une table d’actualisation complète en amont.
Comment les données sont-elles actualisées lorsqu’une table dynamique dépend d’autres tables dynamiques ?¶
Lorsque le décalage d’une table dynamique est défini comme une mesure de temps, le processus d’actualisation automatisé planifie les actualisations de manière à respecter au mieux les temps de latence cibles.
Afin de préserver la cohérence des données dans les cas où une table dynamique dépend d’une autre, le processus actualise toutes les tables dynamiques d’un compte à des moments compatibles. Le délai des actualisations moins fréquentes coïncide avec celui des actualisations plus fréquentes. Si les actualisations prennent trop de temps, le planificateur peut sauter des actualisations pour essayer de rester à jour. Toutefois, l’isolation des instantanés est préservée.
Par exemple, supposons que la table dynamique DT1 ait un latence cible de deux minutes et qu’elle interroge la table dynamique DT2, dont le latence cible est d’une minute. Le processus peut déterminer que la table DT1 doit être actualisé toutes les 96 secondes et la table DT2 toutes les 48 secondes. En conséquence, le processus peut se dérouler selon le calendrier suivant :
Point précis dans le temps |
Tables dynamiques actualisées |
|---|---|
2022-12-01 00:00:00 |
DT1, DT2 |
2022-12-01 00:00:48 |
DT2 |
2022-12-01 00:01:36 |
DT1, DT2 |
2022-12-01 00:02:24 |
DT2 |
The target lag of a dynamic table can’t be shorter than the target lag of the dynamic tables it depends on. For example, suppose that:
La table
DT1interroge les tables dynamiquesDT2etDT3.La table
DT2a une latence cible de cinq minutes.La table
DT3a une latence cible d’une minute.
Cela signifie que le temps de latence cible pour DT1 ne doit pas être inférieur à cinq minutes (c’est-à-dire qu’il ne doit pas être inférieur au plus long des temps de latence pour les tables DT2 et DT3).
Si vous avez fixé le délai de DT1 à cinq minutes, le processus établit une planification d’actualisation en fonction de ces objectifs :
Actualisez suffisamment
DT3pour que son délai d’attente soit inférieur à une minute.Actualisez
DT1etDT2en même temps et suffisamment souvent pour que les délais soient inférieurs à cinq minutes.Veillez à ce que le rafraîchissement de
DT1etDT2coïncide avec une actualisation deDT3afin de garantir l’isolation des instantanés.
Important
Les tables dynamiques en mode d’actualisation incrémentielle ne peuvent pas être placées en aval des tables dynamiques en mode d’actualisation complète. En effet, le mode d’actualisation incrémentielle est incompatible avec les changements de lignes complets qui se produisent lors de chaque actualisation d’une table d’actualisation complète en amont.
Isolation des instantanés¶
Lorsqu’une table dynamique est actualisée, elle garantit un état cohérent en utilisant Time Travel vers le même horodatage de données dans toutes les dépendances en amont.
Pour les tables de base non dynamiques, Time Travel fonctionne comme d’habitude, en tenant compte du temps de validation « de l’horloge murale ». Cela signifie que le contenu d’une table dynamique est toujours cohérent avec un « instantané » des données des tables de base.
Pour les tables dynamiques en amont, Snowflake recherche la version spécifique de la table étiquetée avec cet horodatage des données. Cela garantit que les tables en aval sont toujours cohérentes avec leurs ancêtres. Vous n’avez pas besoin de coordonner les planifications d’actualisation ou de vous soucier des différentes latences ; Snowflake aligne automatiquement les instantanés pour garantir l’intégrité des données dans l’ensemble du pipeline.
L’isolation des instantanés n’est pas garantie lorsque vous joignez plusieurs tables dynamiques à l’aide d’une instruction manuelle SELECT, car les requêtes ad hoc utilisent la version actuelle de chaque table. Étant donné que chaque table dynamique valide son actualisation indépendamment, une jointure manuelle peut capturer différents états d’actualisation, même si les tables dynamiques partagent la même latence cible ou si une actualisation en amont est retardée. Cela signifie que les résultats peuvent ne pas refléter un instantané unique et cohérent des données de base.
Présentation des effets des modifications apportées aux colonnes des tables de base¶
Lorsque les objets sous-jacents associés à une table dynamique changent, les comportements suivants s’appliquent :
Changement |
Impact |
|---|---|
|
Aucune. Si une nouvelle colonne est ajoutée à la table de base ou si une colonne inutilisée est supprimée, aucune action ne se produit et les actualisations se poursuivent comme auparavant. |
|
Réinitialisation : la première actualisation après la recréation est l’initialisation. |
|
La table dynamique ne s’actualise pas et doit être recréée pour tenir compte de la modification. |
|
Aucun impact sur la table dynamique. |