Tables dynamiques comparées aux flux et aux tâches, ainsi qu’aux vues matérialisées

À l’instar des flux et des tâches, les tables dynamiques offrent un moyen de transformer les données dans votre pipeline.

Les tables dynamiques comparées aux flux et aux tâches

Bien que les tables dynamiques aient un objectif similaire en comparaison des flux et des tâches, il existe des différences importantes.

Créer un flux sur une table dynamique

Les flux peuvent être créés sur les tables dynamiques de la même manière que les flux sur les tables traditionnelles, avec les limitations suivantes :

  • Mode d’actualisation : les flux ne peuvent être créés que sur des tables dynamiques qui s’actualisent de manière incrémentielle. Les tables dynamiques à actualisation complète ne sont pas prises en charge car elles réécrivent complètement la table à chaque actualisation.

  • Type de flux : les tables dynamiques ne prennent en charge que les flux standards (c’est-à-dire, delta). Pour plus d’informations, voir Types de flux.

L’exemple suivant montre comment créer un flux sur une table dynamique :

-- Create the dynamic table, for reference only
CREATE OR REPLACE DYNAMIC TABLE product ...;

-- Create the stream.
CREATE OR REPLACE STREAM deltaStream ON DYNAMIC TABLE product;
Copy

Comparaison entre les flux et les tâches et les tables dynamiques

Flux et tâches

Tables dynamiques

Les tâches utilisent une approche impérative : vous écrivez un code procédural pour transformer les données des tables de base.

Les tables dynamiques utilisent une approche déclarative : vous écrivez une requête qui spécifie le résultat que vous voulez obtenir, et les données sont extraites et transformées à partir des tables de base utilisées dans la requête. À l’exception de Fonctions non déterministes prises en charge dans le cadre d’une actualisation complète, la requête ne peut pas contenir de fonctions non déterministes.

Vous définissez un calendrier d’exécution du code qui transforme les données.

Un processus d’actualisation automatisé détermine le calendrier d’exécution des actualisations. Le processus planifie ces actualisations afin de respecter le niveau d’actualisation cible spécifié (latence).

Le code procédural peut contenir des appels à du code non déterministe, des procédures stockées et d’autres tâches. Le code procédural peut contenir des appels à des UDFs et à des fonctions externes.

Bien que l’instruction SELECT pour une table dynamique puisse contenir des jointures, des agrégations, des fonctions de fenêtre et d’autres fonctions et constructions SQL, l’instruction ne peut pas contenir d’appels à des procédures stockées et à des tâches. Actuellement, l’instruction SELECT ne peut pas non plus contenir d’appels à des fonctions externes.

Cette limitation est due à la manière dont les tables dynamiques sont actualisées. Pour actualiser les données, un processus automatisé analyse l’instruction SELECT pour la table dynamique afin de déterminer la meilleure approche pour actualiser les données. Le processus automatisé ne peut pas le déterminer pour certains types de requêtes.

Pour la liste complète des restrictions relatives à l’instruction SELECT, voir Requêtes prises en charge dans le cadre de l’actualisation incrémentielle et Limitations générales.

Les tâches peuvent utiliser des flux pour actualiser les données des tables cibles de manière incrémentielle. Vous pouvez programmer l’exécution de ces tâches à intervalles réguliers.

Un processus d’actualisation automatisé effectue régulièrement des actualisations incrémentielles des tables dynamiques. Le processus détermine le calendrier, sur la base d’un objectif de niveau d’actualisation des données que vous spécifiez.

Exemple : comparaison de la transformation des données entre les flux et les tâches et les tables dynamiques

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 une table cible (names) 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. 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.

Instructions SQL pour les flux et les tâches

Instructions SQL pour les 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);
Copy
-- 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;
Copy

Comparatif entre les tables dynamiques et les vues matérialisées

Les tables dynamiques présentent certaines similitudes avec les vues matérialisées dans la mesure où toutes deux matérialisent les résultats d’une requête. Il existe toutefois des différences importantes :

Vues matérialisées

Tables dynamiques

Les vues matérialisées sont conçues pour améliorer les performances des requêtes de manière transparente.

Par exemple, si vous interrogez la table de base, l’optimiseur de requêtes de Snowflake peut réécrire la requête automatiquement pour interroger la vue matérialisée à la place.

Les tables dynamiques sont conçus pour construire des pipelines de données à plusieurs niveaux.

Bien que les tables dynamiques puissent améliorer les performances des requêtes, l’optimiseur de requêtes de Snowflake ne réécrit pas automatiquement les requêtes pour utiliser les tables dynamiques. Une table dynamique n’est utilisée dans une requête que si vous la spécifiez dans la requête.

Une vue matérialisée ne peut utiliser qu’une seule table de base. Une vue matérialisée ne peut pas être basée sur une requête complexe (c’est-à-dire une requête avec des jointures ou des vues imbriquées).

Une table dynamique peut être basée sur une requête complexe, y compris une requête avec des jointures et des unions.

Les données auxquelles on accède par l’intermédiaire des vues matérialisées sont toujours à jour. Si une opération DML modifie les données de la table de base, Snowflake met à jour la vue matérialisée ou utilise les données mises à jour à partir de la table de base.

Les données sont actuelles jusqu’au temps de latence cible de la table dynamique.

La maintenance et l’actualisation de la table dynamique sont automatiquement gérées par un service de calcul distinct, y compris la logique d’actualisation, en même temps que le calcul des mises à jour, généralement moyennant un coût supplémentaire. Pour plus d’informations, voir Compréhension du coût des tables dynamiques.