Tables dynamiques¶

Un exemple¶

L’exemple présenté dans Transformation des données JSON chargées dans une planification utilise des flux et des tâches pour transformer et insérer de nouvelles données dans deux tables cibles (name et visits) pendant que les données sont diffusées dans une table d’arrivée (raw).

Les exemples suivants montrent comment effectuer la même transformation à l’aide de tables dynamiques.

-- Create a landing table to store
-- raw JSON data.
CREATE OR REPLACE TABLE raw
  (var VARIANT);

-- Create a stream to capture inserts
-- to the landing table.
CREATE OR REPLACE STREAM rawstream1
  ON TABLE raw;

-- Create a table that stores the names
-- of office visitors from the raw data.
CREATE OR REPLACE TABLE names
  (id INT,
   first_name STRING,
   last_name STRING);

-- Create a task that inserts new name
-- records from the rawstream1 stream
-- into the names table.
-- Execute the task every minute when
-- the stream contains records.
CREATE OR REPLACE TASK raw_to_names
  WAREHOUSE = mywh
  SCHEDULE = '1 minute'
  WHEN
    SYSTEM$STREAM_HAS_DATA('rawstream1')
  AS
    MERGE INTO names n
      USING (
        SELECT var:id id, var:fname fname,
        var:lname lname FROM rawstream1
      ) r1 ON n.id = TO_NUMBER(r1.id)
      WHEN MATCHED AND metadata$action = 'DELETE' THEN
        DELETE
      WHEN MATCHED AND metadata$action = 'INSERT' THEN
        UPDATE SET n.first_name = r1.fname, n.last_name = r1.lname
      WHEN NOT MATCHED AND metadata$action = 'INSERT' THEN
        INSERT (id, first_name, last_name)
          VALUES (r1.id, r1.fname, r1.lname);

-- Create a landing table to store
-- raw JSON data.
CREATE OR REPLACE TABLE raw
  (var VARIANT);

-- Create a dynamic table containing the
-- names of office visitors from
-- the raw data.
-- Try to keep the data up to date within
-- 1 minute of real time.
CREATE OR REPLACE DYNAMIC TABLE names
  TARGET_LAG = '1 minute'
  WAREHOUSE = mywh
  AS
    SELECT var:id::int id, var:fname::string first_name,
    var:lname::string last_name FROM raw;

Comme le montre cet exemple, lors de la création d’une table dynamique, vous spécifiez la requête pour les résultats que vous souhaitez voir. Pour l’actualisation incrémentielle des données, vous n’avez pas besoin de créer un flux pour suivre les modifications ni d’écrire une tâche pour examiner ces modifications et les appliquer à la table cible. Le processus d’actualisation automatisé le fait pour vous, sur la base de la requête que vous avez spécifiée.

Quand utiliser les tables dynamiques¶

Il existe plusieurs méthodes pour transformer les données dans votre pipeline (par exemple, les flux et les tâches, CTAS, votre propre solution personnalisée). Les tables dynamiques sont une option pour transformer vos données.

Les tables dynamiques sont utilisés de préférence dans les cas suivants :

• Vous ne voulez pas écrire de code pour suivre les dépendances des données et gérer l’actualisation des données.

• Vous souhaitez éviter la complexité relative aux flux et aux tâches, ou vous n’en avez pas besoin.

• Vous devez matérialiser les résultats d’une requête portant sur plusieurs tables de base.

• Vous devez construire plusieurs tables pour transformer les données via un pipeline ETL.

• Vous n’avez pas besoin d’un contrôle précis de la programmation des actualisations et vous souhaitez simplement spécifier le niveau d’actualisation des données cible pour vos pipelines.

• Vous n’avez pas besoin d’utiliser des constructions de requêtes dynamiques non prises en charge, telles que les procédures stockées, les fonctions non déterministes non répertoriées dans Fonctions non déterministes prises en charge dans le cadre d’une actualisation complète, ou les fonctions externes, ni d’utiliser des sources pour les tables dynamiques qui sont des tables externes, des flux ou des vues matérialisées.

Fonctionnement des tables dynamiques¶

Lors de la création d’une table dynamique, vous indiquez la requête qui utilisée pour transformer les données d’un ou plusieurs objets de base ou d’une ou plusieurs tables dynamiques. Un processus d’actualisation automatisé exécute régulièrement cette requête et met à jour la table dynamique en fonction des modifications apportées aux objets de base.

Ce processus automatisé calcule les modifications apportées aux objets de base et les fusionne dans la table dynamique. Pour effectuer ce travail, le processus utilise les ressources de calcul que vous associez à la table dynamique. Pour de plus amples informations sur les ressources, reportez-vous à Présentation des coûts associés aux tables dynamiques.

Lors de la création d’une table dynamique, vous spécifiez une cible de niveau d’actualisation pour les données (une latence cible). Par exemple, vous pouvez spécifier que les données doivent avoir un retard maximum de 5 minutes par rapport aux mises à jour de la table de base. Sur la base de ce niveau d’actualisation cible, le processus automatisé met en place des actualisations afin que les données de la table dynamique soient mises à jour dans les limites de cette cible (par exemple, dans les 5 minutes suivant les mises à jour de la table de base).

Si les données n’ont pas besoin d’être aussi actuelles, vous pouvez spécifier un niveau d’actualisation cible plus long afin de réduire les coûts. Par exemple, si les données de la table cible doivent avoir au maximum une heure de retard sur les mises à jour des tables de base, vous pouvez spécifier un niveau d’actualisation cible d’une heure (au lieu de 5 minutes) pour réduire les coûts.

À propos du chaînage des pipelines de tables dynamiques¶

Vous pouvez configurer une table dynamique pour interroger d’autres tables dynamiques.

Par exemple, supposons que votre pipeline de données récupère des données d’une table de mise en zone de préparation pour mettre à jour des tables de dimension distinctes pour les données relatives aux consommateurs, aux produits et à la date et à l’heure. Votre pipeline mette également à jour une table contenant des données de vente agrégées, basées sur ces tables de dimension.

Vous pouvez configurer les tables de dimension comme des tables dynamiques qui interrogent la table de mise en zone de préparation. Vous pouvez ensuite configurer la table des ventes agrégées comme une table dynamique qui interroge les tables de dimensions.

Cette procédure est similaire à la définition d’un graphique de tâches. Dans un graphique de tâches, la tâche de mise à jour de la table des ventes agrégées ne s’exécute que si les tâches de mise à jour des tables de dimensions ont été exécutées sans erreur.

Si une table dynamique interroge une autre table dynamique, le processus d’actualisation automatisé met à jour toutes les tables dynamiques dépendantes au moment opportun afin de garantir que leurs objectifs de latence soient atteints et que les données soient cohérentes.

Tables dynamiques et Time Travel¶

La fonction « Time Travel » de Snowflake permet d’accéder aux données historiques (c.-à-d. les données qui ont été modifiées ou supprimées) à tout moment au cours d’une période définie. Time Travel se comporte de la même manière pour les tables dynamiques que pour les tables traditionnelles.

Pour plus d’informations, reportez-vous à Time Travel et Fail-safe de Snowflake.

Tables dynamiques et réplication¶

La prise en charge de la réplication des tables dynamiques vous permet de copier les données d’une base de données principale vers une base de données secondaire pour la reprise après sinistre ou le partage de données. Cela peut servir de stratégie de préparation au basculement pour la reprise après sinistre ou de moyen de partage des données entre les déploiements à des fins de lecture seule.

Les tables dynamiques répliquées se comportent différemment selon que la base de données principale qui contient la table dynamique est répliquée dans un groupe de réplication ou un groupe de basculement. Pour plus d’informations, consultez Réplication et tables dynamiques.