Présentation de l’actualisation des tables dynamiques¶

Modes d’actualisation des tables dynamiques¶

Le processus d’actualisation d’une table dynamique se déroule de deux manières :

1. Actualisation incrémentielle : ce processus automatisé analyse la requête de la table dynamique et calcule les changements survenus depuis la dernière actualisation. Il fusionne ensuite ces modifications dans la table. Voir Requêtes prises en charge dans le cadre de l’actualisation incrémentielle pour plus de détails sur les requêtes prises en charge.

2. Actualisation complète : Lorsque le processus automatisé ne peut pas effectuer une actualisation incrémentielle, il effectue une actualisation complète. Cela implique l’exécution de la requête pour la table dynamique et le remplacement complet des résultats matérialisés précédents.

Les constructions utilisées dans la requête déterminent si une actualisation incrémentielle peut être utilisée. 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.

Comprendre la latence cible¶

L’actualisation des tables dynamiques est déclenchée en fonction du degré d’obsolescence des données, ce que l’on appelle communément latence cible. La latence cible d’une table dynamique est mesurée par rapport aux tables de base situées à la racine du graphique et non par rapport aux tables dynamiques situées directement en amont. 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.

Pour voir le graphique des tables liées à votre table dynamique, voir Utiliser Snowsight pour examiner le graphique des tables dynamiques.

La latence cible est spécifiée de l’une des manières suivantes :

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 configure la table dynamique product pour qu’elle soit actualisée et conserve son niveau d’actualisation toutes les heures :

   ALTER DYNAMIC TABLE product SET TARGET_LAG = '1 hour';
   

   Copy

2. En aval : spécifie que la table dynamique doit être actualisée à la demande lorsque d’autres tables dynamiques dépendantes sont actualisées. Cette actualisation peut être déclenchée par une actualisation manuelle ou planifiée d’une table dynamique en aval.

   Dans l’exemple suivant, product est basé sur d’autres tables dynamiques et est défini pour être actualisé en fonction de la latence cible de ses tables dynamiques en aval :

   ALTER DYNAMIC TABLE product SET TARGET_LAG = DOWNSTREAM;
   

   Copy

La latence cible est inversement proportionnelle à la fréquence d’actualisation des tables dynamiques : des actualisations fréquentes impliquent une latence plus faible.

Prenons l’exemple suivant, dans lequel la table dynamique 2 (DT2) est définie sur la base de la table dynamique 1 (DT1). DT2 doit lire dans DT1 pour matérialiser son contenu. En outre, un rapport consomme des données DT2 par le biais d’une requête.

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

Requêtes prises en charge dans le cadre de l’actualisation incrémentielle¶

La table suivante décrit les expressions, les mots-clés et les clauses qui prennent actuellement en charge l’actualisation incrémentielle. Pour une liste des requêtes qui ne prennent pas en charge l’actualisation incrémentielle, voir Limitations de la prise en charge de l’actualisation incrémentielle.

Actuellement, les jointures latérales ne sont pas prises en charge dans le cadre d’une actualisation incrémentielle. Cependant, vous pouvez utiliser LATERAL avec FLATTEN() en définissant le mode d’actualisation sur INCREMENTAL.

Par exemple :

CREATE TABLE persons
  AS
    SELECT column1 AS id, parse_json(column2) AS entity
    FROM values
      (12712555,
      '{ name:  { first: "John", last: "Smith"},
        contact: [
        { business:[
          { type: "phone", content:"555-1234" },
          { type: "email", content:"j.smith@company.com" } ] } ] }'),
      (98127771,
      '{ name:  { first: "Jane", last: "Doe"},
        contact: [
        { business:[
          { type: "phone", content:"555-1236" },
          { type: "email", content:"j.doe@company.com" } ] } ] }') v;

CREATE DYNAMIC TABLE example
  TARGET_LAG = DOWNSTREAM
  WAREHOUSE = mywh
  REFRESH_MODE = INCREMENTAL
  AS
    SELECT p.id, f.value, f.path
    FROM persons p,
    LATERAL FLATTEN(input => p.entity) f;

Actualisation incrémentielle par les opérateurs¶

Le tableau suivant indique comment chaque opérateur est incrémenté (c’est-à-dire comment il est transformé en un nouveau fragment de requête qui génère des modifications au lieu de résultats complets), ainsi que ses performances et d’autres facteurs importants à prendre en compte.

CREATE DYNAMIC TABLE sums
  AS
    SELECT date_trunc(minute, ts), sum(c1) FROM table
    GROUP BY 1;

CREATE DYNAMIC TABLE intermediate
  AS
    SELECT date_trunc(minute, ts) ts_min, c1 FROM table;

CREATE DYNAMIC TABLE sums
  AS
    SELECT ts_min, sum(c1) FROM intermediate
    GROUP BY 1;

Fonctions non déterministes prises en charge dans le cadre d’une actualisation complète¶

Les fonctions non déterministes suivantes sont prises en charge dans les tables dynamiques. Notez que ces fonctions ne sont prises en charge que pour les actualisations complètes. Pour une liste des éléments non pris en charge pour l’actualisation incrémentielle, voir Limitations de la prise en charge de l’actualisation incrémentielle.

• Fonctions définies par l’utilisateur VOLATILE

• Fonctions séquentielles (par exemple SEQ1, SEQ2)

• Les fonctions contextuelles suivantes :

  • CURRENT_ROLE

  • CURRENT_WAREHOUSE

  • CURRENT_ACCOUNT

  • CURRENT_REGION

• Les fonctions de date et d’heure suivantes (ainsi que leurs alias respectifs) :

  • CURRENT_DATE

  • CURRENT_TIME

  • CURRENT_TIMESTAMP

Comment les données sont-elles actualisées lorsque des tables dynamiques dépendent d’autres tables dynamiques ?¶

Lorsqu’une latence de table dynamique est spécifiée en tant que mesure de temps, le processus d’actualisation automatisé détermine le calendrier des actualisations, sur la base des temps de latence cibles des tables dynamiques. Le processus choisit un calendrier qui respecte au mieux les temps de latence cibles des tables.

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.

Par exemple, supposons qu’une table dynamique A ait un temps de latence cible de 2 minutes et qu’elle interroge une table dynamique B dont le temps de latence cible est d’une minute. Le processus peut déterminer que A doit être actualisée toutes les 96 secondes et B toutes les 48 secondes. En conséquence, le processus peut se dérouler selon le calendrier suivant :

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 :

• Une table dynamique A interroge les tables dynamiques B et C.

• La table dynamique B a une latence cible de cinq minutes.

• La table dynamique C a une latence cible d’une minute.

Cela signifie que le temps de latence cible pour A 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 B et C).

Si vous définissez la latence pour A à cinq minutes, le processus établit un calendrier d’actualisation avec ces objectifs :

• Actualisez C suffisamment souvent pour que sa latence soit inférieure à une minute.

• Actualisez A et B en même temps et suffisamment souvent pour que leur latence soit inférieure à cinq minutes.

• Assurez-vous que l’actualisation de A et B coïncide avec l’actualisation de C pour garantir l’isolation des instantanés.

Remarque : si les actualisations prennent trop de temps, le programmateur peut ignorer des actualisations pour essayer de rester à jour. Toutefois, l’isolation des instantanés est préservée.