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 deux modes d’actualisation : incrémentielle et complète. Vous pouvez soit paramétrer le mode d’actualisation sur AUTO, soit le définir explicitement. Découvrez les meilleures pratiques pour choisir le mode d’actualisation et comment voir le mode d’actualisation utilisé. |
|
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 |
Découvrez l’impact des modifications apportées aux tables de base. |
Meilleures pratiques pour l’actualisation des tables dynamiques |
Une liste des meilleures pratiques pour l’actualisation des tables dynamiques. |
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
DT1
est définie pour s’actualiser de manière synchrone à la création (ON_CREATE
), elle s’initialise à la création.Si la table
DT1
est 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.
Comme solution de contournement, vous pouvez utiliser une tâche avec une planification CRON. Par exemple :
CREATE TASK my_task
SCHEDULE = 'USING CRON <expr> <time_zone>'
AS
ALTER DYNAMIC TABLE my_dynamic_table REFRESH;
Modes d’actualisation des tables dynamiques¶
Les tables dynamiques prennent en charge deux modes d’actualisation : incrémentielle et complète. Vous pouvez soit paramétrer le mode d’actualisation sur AUTO, soit le définir explicitement :
Mode d’actualisation AUTO : lorsque vous utilisez le paramètre
AUTO
, Snowflake sélectionne automatiquement le mode d’actualisation le plus rentable et le plus rapide en fonction de la complexité de la requête, des constructions, des opérateurs et des fonctions pris en charge, ainsi que des performances attendues. Si l’actualisation incrémentielle n’est pas prise en charge ou si elle risque d’être peu performante, Snowflake choisit automatiquement l’actualisation complète.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.
Après avoir créé une table dynamique, vous pouvez surveiller la table pour déterminer si des actualisations incrémentielles ou complètes sont utilisées pour mettre à jour cette table.
Bonnes pratiques pour le choix des modes d’actualisation des tables dynamiques¶
Le mode le plus adapté pour les performances de vos tables dynamiques dépend du volume de modification des données et de la complexité de la requête. De plus, tester différents modes d’actualisation avec un entrepôt dédié permet d’isoler les coûts et d’améliorer le réglage des performances en fonction des charges de travail réelles.
Mode d’actualisationAUTO : le système tente d’appliquer une actualisation incrémentielle par défaut. Lorsque l”actualisation incrémentielle n’est pas prise en charge ou ne fonctionne pas correctement, la table dynamique sélectionne automatiquement l’actualisation complète à la place.
Nous recommandons fortement l’utilisation de
AUTO
pour la plupart des cas d’utilisation, car cela permet à Snowflake d’optimiser le comportement d’actualisation sans réglage manuel. Pour un comportement cohérent, définissez explicitement le mode d’actualisation sur toutes les tables de production. Le comportementAUTO
peut changer entre les versions de Snowflake, ce qui peut entraîner des changements inattendus dans les performances si elles sont utilisées dans les pipelines de production.
Actualisation incrémentielle : met à jour la table dynamique avec uniquement les modifications depuis la dernière actualisation, ce qui la rend idéale pour les grands ensembles de données avec de petites mises à jour fréquentes.
Adapté pour les requêtes compatibles avec l’actualisation incrémentielle (par exemple, les fonctions déterministes, les jointures simples et les expressions de base dans
SELECT
,WHERE
etGROUP BY
). Si des fonctionnalités non prises en charge sont présentes et que le mode d’actualisation est défini sur incrémentiel, Snowflake ne parviendra pas à créer la table dynamique.Une pratique fondamentale pour optimiser les performances avec une actualisation incrémentielle consiste à limiter le volume de modification à environ 5 % des données source, et à regrouper vos données par clés de regroupement pour réduire la surcharge de traitement.
Tenez compte du fait que certaines combinaisons d’opérations, comme les agrégations au-dessus de plusieurs jointures, peuvent ne pas fonctionner efficacement.
Actualisation complète : retraite l’intégralité du jeu de données et met à jour la table dynamique avec le résultat complet de la requête. À utiliser pour les requêtes complexes ou lorsque des modifications de données importantes nécessitent une mise à jour complète.
Utile lorsque l’actualisation incrémentielle n’est pas prise en charge en raison de requêtes complexes, de fonctions non déterministes ou de modifications majeures dans les données.
Pour déterminer le mode le mieux adapté à votre cas d’utilisation, expérimentez les recommandations automatiques et les modes d’actualisation concrets (actualisations complètes et incrémentielles).
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.
Pour vérifier le mode d’actualisation de vos tables dynamiques, consultez Afficher le mode d’actualisation de tables dynamiques.
Afficher le mode d’actualisation de tables dynamiques¶
Vous définissez le mode d’actualisation lorsque vous créez une table dynamique. Après la création, vous pouvez vérifier si votre table dynamique utilise des actualisations incrémentielles ou complètes à l’aide de l’une des méthodes suivantes, avec un rôle disposant des privilèges nécessaires :
Exécutez la commande SHOW DYNAMIC TABLES :
SHOW DYNAMIC TABLES;
Dans la sortie :
La colonne
text
indique le mode d’actualisation spécifié par l’utilisateur.La colonne
refresh_mode
indique le mode d’actualisation actuel.Le site
refresh_mode_reason
explique pourquoi le mode d’actualisation actuel a été choisi.
Dans le menu de navigation, sélectionnez Monitoring » Dynamic Tables, puis sélectionnez votre table dynamique.
Vous pouvez voir le mode d’actualisation de la table dynamique dans l’en-tête de l’objet en haut de la page. Pour les actualisations complètes, le motif du mode d’actualisation est visible lorsque vous survolez le mode avec le curseur de la souris.
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 |
Cela signifie qu’à tout moment, lorsque vous interrogez un ensemble de tables dynamiques qui dépendent les unes des autres, vous interrogez le même « instantané » des données de ces tables.
Notez que la latence cible d’une table dynamique ne peut être plus courte que la latence cible des tables dynamiques dont elle dépend. Par exemple, supposons ceci :
La table
DT1
interroge les tables dynamiquesDT2
etDT3
.La table
DT2
a une latence cible de cinq minutes.La table
DT3
a 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
DT3
pour que son délai d’attente soit inférieur à une minute.Actualisez
DT1
etDT2
en même temps et suffisamment souvent pour que les délais soient inférieurs à cinq minutes.Veillez à ce que le rafraîchissement de
DT1
etDT2
coïncide avec une actualisation deDT3
afin 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.
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. |
|
Les actualisations ultérieures de la table dynamique échoueront. La table dynamique doit être recréée pour tenir compte de la modification. |
Meilleures pratiques pour l’actualisation des tables dynamiques¶
Utiliser des entrepôts dédiés pour les actualisations¶
Les tables dynamiques nécessitent un entrepôt virtuel pour effectuer les actualisations. Pour bien comprendre les coûts liés à vos pipelines de tables dynamiques, vous devriez tester vos tables dynamiques à l’aide d’entrepôts dédiés, de sorte que la consommation de l’entrepôt virtuel attribuée aux tables dynamiques puisse être isolée.
Pour plus d’informations, voir Compréhension du coût des tables dynamiques.
Utiliser la latence en aval¶
La latence en aval indique que la table dynamique doit être actualisée lorsque d’autres tables dynamiques dépendantes doivent l’être. Vous devriez utiliser la latence en aval comme meilleure pratique en raison de sa facilité d’utilisation et de sa rentabilité. Sans latence en aval, la gestion d’une chaîne de tables dynamiques complexes nécessiterait d’assigner individuellement à chaque table sa propre latence cible et de gérer les contraintes associées, au lieu de surveiller uniquement le niveau d’actualisation des données de la table finale.
Pour plus d’informations, voir Comprendre la latence cible des tables dynamiques.