Comprendre la latence cible des tables dynamiques¶

L’actualisation des tables dynamiques est déclenchée par la latence cible des données, qui détermine son degré d’obsolescence. Vous pouvez définir une latence cible fixe ou définir la table dynamique sur DOWNSTREAM, de sorte que son délai d’actualisation dépende des tables dynamiques qui en dépendent.

La latence cible d’une table dynamique est mesurée par rapport aux tables dynamiques situées à la racine du graphique, et non par rapport aux tables dynamiques situées directement en amont. Pour voir le graphique des tables liées à votre table dynamique, voir Voir le graphique des tables connectées à vos tables dynamiques.

Snowflake planifie les actualisations de manière à ce que la latence réelle de vos tables dynamiques reste inférieure à la latence cible. La durée de chaque actualisation dépend de la requête, du modèle de données et de la taille de l’entrepôt. Lorsque vous choisissez une latence cible, tenez compte du temps nécessaire pour actualiser chaque table dynamique dans une chaîne jusqu’à la racine. Si vous ne le faites pas, certaines actualisations risquent d’être ignorées, ce qui entraînera une latence plus importante.

Types de latence cible¶

Vous spécifiez la latence cible de l’une des manières suivantes. La latence cible est inversement proportionnelle à la fréquence d’actualisation des tables dynamiques : des actualisations fréquentes impliquent une latence plus faible.

Mesure du niveau d’actualisation : spécifie le délai maximum pendant lequel le contenu de la table dynamique doit être décalé par rapport aux mises à jour des tables de base.
L’exemple suivant paramètre my_dynamic_table pour une actualisation et un maintien du niveau d’actualisation toutes les heures :
ALTER DYNAMIC TABLE my_dynamic_table SET TARGET_LAG = '1 hour';
Copy
Aval : Spécifie que la table dynamique doit être actualisée à la demande lorsque les tables en aval (tables qui dépendent de cette table) sont actualisées. Cette actualisation peut être déclenchée par l’initialisation à la création, l’actualisation manuelle, ou l’actualisation planifiée d’une table en aval.

Lorsque refresh_mode est défini sur downstream, la planification d’actualisation d’une table dynamique est déterminée par la latence la plus exigeante (la plus courte) de ses dépendances en aval. Par exemple, si une table dépendante en aval nécessite des données ne datant pas de plus de 10 minutes et qu’une autre table dépendante en aval nécessite des données ne datant pas de plus d’une heure, la planification d’actualisation de cette table dynamique sera toutes les 10 minutes, car il s’agit du décalage le plus court de ses dépendances en aval.

Dans l’exemple suivant, la my_dynamic_table est définie pour se rafraîchir en fonction de la latence cible de ses tables dynamiques en aval. Si my_dynamic_table n’a pas de tables dynamiques qui en dépendent, elle ne sera pas actualisée.
```
ALTER DYNAMIC TABLE my_dynamic_table SET TARGET_LAG = DOWNSTREAM;
```
Copy
Pour d’autres exemples de latence cible en aval, consultez Exemple : latence cible pour les chaînes de tables dynamiques.

Comment Snowflake planifie les actualisations¶

Snowflake planifie les actualisations légèrement plus tôt que la latence cible pour permettre à l’actualisation de se terminer. Par exemple, si vous définissez la latence cible à 5 minutes, la table risque d’être actualisée plus fréquemment que toutes les cinq minutes. Les intervalles d’actualisation réels sont souvent plus courts que la latence spécifiée.

Note

La latence cible est une cible, et non une garantie. Snowflake tente de conserver les données dans la latence cible, mais la latence réelle peut dépasser la cible en raison de facteurs tels que la taille de l’entrepôt, le volume de données et la complexité de la requête.

Pour obtenir des conseils sur l’ajustement de la latence cible pour votre charge de travail, consultez Modifier l’entrepôt ou la latence cible pour les tables dynamiques. Pour plus d’informations sur l’optimisation de votre latence cible, consultez Identifier la latence cible appropriée.

Comment les relations en amont et en aval affectent la latence cible¶

Le diagramme suivant illustre les opérations de suspension, de reprise et d’actualisation manuelle dans le contexte des relations en amont et en aval avec d’autres tables dynamiques.

Relation entre les tables dynamiques. Utilisé pour expliquer les notions de suspension, de reprise et d'actualisation manuelle.

Le diagramme représente un pipeline de données déclaratif simple construit avec des tables dynamiques :

DT2 est décrite comme en aval de DT1 parce qu’elle dépend de cette table dynamique, et en amont de DT3, qui en dépend.
DT3 est en aval de DT2 et DT1, car elle dépend directement de DT2 et indirectement de DT1.
DT1 est directement ou indirectement en amont des autres tables dynamiques.

Exemple : latence cible pour les chaînes de tables dynamiques¶

Prenons l’exemple suivant : une table dynamique (DT2) lit les données d’une autre table dynamique (DT1) pour matérialiser son contenu. Dans ce scénario, un rapport consomme les données de DT2 via une requête.

Exemple simple de deux tables dynamiques : DT2, étant définie en fonction de DT1.

Les résultats suivants sont possibles, en fonction de la manière dont chaque table dynamique spécifie sa latence :

`DT1`	`DT2`	Actualiser les résultats
`TARGET_LAG = DOWNSTREAM`	`TARGET_LAG = 10minutes`	`DT2` est mise à jour au moins toutes les 10 minutes. `DT1` déduit sa latence de `DT2`, elle est mise à jour chaque fois que `DT2` requiert des mises à jour.
`TARGET_LAG = 10minutes`	`TARGET_LAG = DOWNSTREAM`	Ce scénario doit être évité. La requête de rapport ne recevra aucune donnée. DT1 est fréquemment actualisée et `DT2` ne l’est pas car il n’y a pas de table dynamique basée sur `DT2`.
`TARGET_LAG = 5minutes`	`TARGET_LAG = 10minutes`	`DT2` est mis à jour environ toutes les 10 minutes avec des données provenant de `DT1` et datant d’au plus 5 minutes.
`TARGET_LAG = DOWNSTREAM`	`TARGET_LAG = DOWNSTREAM`	Ni `DT1`, ni `DT2` ne sont actualisées périodiquement parce qu’elles ont tous deux un décalage en aval et qu’aucun n’a de consommateur en aval avec une latence définie.