Comprendre la latence cible des tables dynamiques¶

Types de latence cible¶

La latence cible est spécifiée 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.

1. 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

2. En aval : spécifie que la table dynamique doit s’actualiser sur demande lorsque d’autres tables dynamiques dépendantes s’actualisent. Cette actualisation peut être déclenchée par l’initialisation à la création, l’actualisation manuelle ou l’actualisation planifiée d’une table dynamique 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

Déterminer la latence cible optimale pour une table dynamique¶

La latence cible que vous avez définie affecte la fréquence des actualisations planifiées de votre table dynamique.

Snowflake planifie les actualisations un peu plus tôt afin de laisser le temps à l’actualisation de se terminer. Par exemple, si vous avez défini la latence cible à 5 minutes, cela ne signifie pas que la table sera actualisée exactement toutes les 5 minutes. Les intervalles d’actualisation réels peuvent être plus courts que le délai spécifié. Si vous souhaitez des actualisations de 5 minutes plus réguliers, envisagez d’augmenter légèrement la latence cible.

Vous pouvez utiliser la fonction de table DYNAMIC_TABLE_REFRESH_HISTORY dans INFORMATION_SCHEMA ou Snowsight pour déterminer le temps de latence cible optimal en fonction de vos exigences. Par exemple, l’analyse des détails de l’actualisation, y compris la durée et les actualisations sautées, pour prendre une décision éclairée.

Pour plus d’informations sur la surveillance des actualisations des tables dynamiques et le dépannage, voir Surveiller les tables dynamiques et Diagnostic des problèmes courants liés à l’actualisation des tables dynamiques.

SELECT
    name
FROM
  TABLE (
    INFORMATION_SCHEMA.DYNAMIC_TABLE_REFRESH_HISTORY (
      NAME_PREFIX => 'MYDB.MYSCHEMA.', ERROR_ONLY => TRUE
    )
  );

Modifier la latence cible¶

Vous pouvez vouloir ajuster la latence cible d’une table dynamique pour l’une des raisons suivantes :

• Vous avez besoin de données plus récentes. La réduction de la latence cible permet de rafraîchir la table dynamique plus fréquemment, ce qui fournit des données plus fraîches et plus proches du temps réel.

• Vous voulez optimiser les ressources. L’augmentation de la latence cible peut réduire la fréquence des actualisations, ce qui permet d’économiser des ressources calcul, ceci est utile pour les charges de travail qui ne nécessitent pas de mises à jour constantes ou dont les données changent peu souvent. Par exemple, si une table dynamique est actualisée toutes les 20 minutes, mais qu’elle ne doit se trouver qu’à une heure des tables sources, le fait de paramétrer une latence cible d’une heure peut permettre de réduire les coûts.

• Vous souhaitez que la latence cible s’aligne sur le pipeline de données. Si votre table dynamique dépend d’autres tables dont les intervalles d’actualisation sont plus longs, l’ajustement de la latence cible permet de s’aligner sur les dépendances.

Pour modifier la latence cible, utilisez la commande ALTER DYNAMIC TABLE. Pour plus d’informations, voir Modifier l’entrepôt ou la latence cible pour les tables dynamiques.

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.

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.

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