Dynamic Tables Snowflake : pipelines incrémentaux (vs Streams + Tasks, exemples)

Dans les 2 derniers articles, on a vu comment :

• Les streams répondent à “qu'est-ce qui a changé depuis la dernière fois ?”,
• Les tasks décident “quand on exécute le SQL qui consomme ces changements”.

Donc avec Streams + Tasks, on sait construire un pipeline incrémental, mais c'est encore à nous d'orchestrer la mécanique.

Les Dynamic Tables arrivent avec une autre approche :

“Décris-moi le résultat que tu veux (un SELECT) et je m'occupe de le garder à jour pour toi, de manière incrémentale.”

C'est quoi concrètement une Dynamic Table ?

Une Dynamic Table, c’est une table gérée par Snowflake à partir d'un SELECT.
L'idée, c'est d'écrire juste la requête qui décrit le résultat final, et Snowflake s'occupe du reste :

• Matérialise ce résultat dans une table physique,
• Et le maintient à jour automatiquement en se basant sur les changements des sources.

On ne fait pas de INSERT ou UPDATE direct sur une Dynamic Table.
Il faut le voir plutôt comme un modèle (un peu comme une vue matérialisée ++) que Snowflake alimente en continu.

La définition ressemble à :

CREATE OR REPLACE DYNAMIC TABLE members_daily
  TARGET_LAG = '5 MINUTE'
  WAREHOUSE  = COMPUTE_WH
AS
SELECT
  id,
  name,
  age,
  DATE_TRUNC('day', created_at) AS day
FROM members;

On lui donne :

• Une requête AS SELECT ... qui décrit ce qu'on veut,
• Un TARGET_LAG qui fixe l'objectif de rafraîchissement des données, en mode “je veux que cette table ait au plus X minutes de retard par rapport aux sources”,
• Et un compute (warehouse ou mode géré) pour faire tourner les refresh.

Ensuite, on peut requêter members_daily comme une table normale :

SELECT *
FROM members_daily
WHERE day >= CURRENT_DATE - 7;

Snowflake, lui, s'occupe de la garder à jour.
Et surtout, il le fait de manière incrémentale, en ne recalculant que ce qui est nécessaire.

Différence avec une vue ou une vue matérialisée

On peut se demander : “OK, mais en quoi c'est différent d'une view ou d'une materialized view ?”

• Une view classique ne stocke rien. À chaque requête, Snowflake ré-exécute tout le SELECT sur les tables sources. C'est juste une couche logique.
• Une materialized view stocke le résultat et le met à jour automatiquement, mais avec pas mal de limitations sur le SQL, et sans vraie notion de pipeline en plusieurs étapes.
• Une Dynamic Table est pensée dès le départ pour faire des pipelines de modèles : elle peut lire d'autres Dynamic Tables, exprimer un objectif de fraîcheur, et Snowflake se sert de ça pour orchestrer les rafraîchissements dans le bon ordre.

Tu peux en empiler plusieurs et Snowflake va comprendre tout seul ce qui dépend de quoi, et ce qu'il faut rafraîchir d'abord, et comment faire tout ça de manière incrémentale.

Là où une view est juste un SELECT bête et une materialized view un “cache plus ou moins intelligent”, une Dynamic Table se positionne plus comme une brique de pipeline déclarative.

Exemple d'un pipeline avec Dynamic Tables

Prenons un exemple simple.

On a des événements bruts dans une table events_raw et on veut :

1. les nettoyer en supprimant les événements qui n'ont pas de time, puis stocker ça dans la table events_clean
2. ensuite calculer le nb d'events quotidiens par utilisateur

Avec Streams + Tasks, on ferait : table → stream → table intermédiaire → task → autre table, etc...

Avec des Dynamic Tables, on peut exprimer ça comme une suite de modèles :

CREATE OR REPLACE DYNAMIC TABLE events_clean
  TARGET_LAG = '10 MINUTE'
  WAREHOUSE  = COMPUTE_WH
AS
SELECT
  event_id,
  user_id,
  TRY_TO_TIMESTAMP(event_time) AS event_time,
  event_type,
  payload
FROM events_raw
WHERE event_time IS NOT NULL;

Puis une deuxième Dynamic Table qui se base sur la première :

CREATE OR REPLACE DYNAMIC TABLE events_daily_agg
  TARGET_LAG = '15 MINUTE'
  WAREHOUSE  = COMPUTE_WH
AS
SELECT
  user_id,
  DATE_TRUNC('day', event_time) AS day,
  COUNT(*) AS nb_events
FROM events_clean
GROUP BY user_id, day;

Ce qui est intéressant ici :

• events_daily_agg dépend de events_clean,
• events_clean dépend de events_raw,
• et on ne gère aucune Task pour dire “rafraîchis d'abord ça, puis ça”.

Snowflake construit un graphe de dépendances, et se débrouille pour rafraîchir les Dynamic Tables dans le bon ordre, en respectant les TARGET_LAG que tu as définis. Et oui c'est magique.

Comment penser TARGET_LAG pour le rafraîchissement des données

Le paramètre TARGET_LAG est central dans les Dynamic Tables.
C'est lui qui fixe la fréquence de rafraîchissement des données dans les tables dynamique.

• Si tu mets un lag très court (genre '1 MINUTE'), tu demandes à Snowflake de rafraîchir très souvent et donc la table sera quasi temps réel, mais tu consommeras plus de compute et cela peut faire mal à la facture.
• Si tu mets un lag plus large ('30 MINUTE', '1 HOUR'…), tu acceptes un peu de retard, mais tu réduis la fréquence des refresh.

Parce que derrière, à chaque refresh, Snowflake lit les changements des sources, calcule ce qu'il faut, met à jour la Dynamic Table.
Donc TARGET_LAG, c'est un vrai curseur coût / rafraîchissement des données, qu'il faut bien dimensionner en fonction des besoins.

Dynamic Tables vs Streams + Tasks

La question qu'on finit toujours par se poser, et que je me suis aussi posée quand j'ai vu les Dynamic Tables, c'est:

“Bon, je fais ça avec Dynamic Tables, ou je reste avec mon combo Streams + Tasks ?”

Pour faire simple :

• Avec Streams + Tasks, on construit toute la mécanique à la main donc on déclare les streams, on écrit les MERGE, on planifie les Tasks, on gère les dépendances. Au final, on garde un contrôle très fin sur ce qui se passe à chaque étape.
• Avec les Dynamic Tables, on monte d'un niveau et on mise sur la simplicité. On décrit juste “voilà le modèle que je veux” via un SELECT, on règle le TARGET_LAG, et Snowflake se charge de l'incrémental et du scheduling pour nous.

Par défaut, si ton pipeline est 100 % Snowflake et surtout une suite de transformations SQL, les Dynamic Tables sont souvent l'option la plus simple. Sinon, ou si tu as besoin de plus de contrôle et d'intégrations externes l'option Streams + Tasks reste plus adaptée.

Limitations à connaître

Avant de tout migrer en Dynamic Tables, il faut connaître quelques contraintes :

• Pas tous les SQL supportés : certaines fonctions non déterministes comme CURRENT_TIMESTAMP(), RANDOM() ou UUID_STRING() posent problème dans le refresh incrémental. Snowflake bascule alors en mode "FULL REFRESH" qui recalcule tout, ce qui peut coûter cher.
• Les sources doivent être identifiables : Snowflake doit pouvoir tracker les changements des sources. Les vues, les external tables avec auto-refresh et les tables avec change tracking activé fonctionnent. Les UDF non déterministes peuvent forcer un FULL REFRESH.
• TARGET_LAG minimum : 1 minute, comme pour les Tasks. Pour du quasi-temps réel sous la minute, regarde du côté de Snowpipe Streaming.
• Édition Enterprise minimum : non disponible en Standard.
• Coût à anticiper : un TARGET_LAG très court (1-5 minutes) sur une grosse Dynamic Table peut consommer beaucoup de compute. Surveille la consommation via INFORMATION_SCHEMA.DYNAMIC_TABLE_REFRESH_HISTORY.

Pour vérifier qu'une Dynamic Table fait bien du refresh incrémental (et non FULL), tu peux interroger :

SELECT name, target_lag_type, refresh_mode, last_completed_refresh_state
FROM TABLE(INFORMATION_SCHEMA.DYNAMIC_TABLE_REFRESH_HISTORY(
  NAME => 'events_clean'
));

Si refresh_mode retourne FULL, ta Dynamic Table recalcule tout à chaque refresh et tu perds le bénéfice incrémental.

Aller plus loin : préparer la SnowPro Core

Les Dynamic Tables sont une feature relativement récente de Snowflake, mais déjà testée à l'examen SnowPro Core (surtout sur les notions de TARGET_LAG et le mode déclaratif). Sur DataCertification.fr, le module SnowPro Core couvre les pipelines incrémentaux dans leur ensemble (Streams, Tasks, Dynamic Tables, Snowpipe) avec 700 questions scenario-based au format de l'examen.

👉 Préparer la SnowPro Core sur DataCertification.fr

Pour aller plus loin sur Snowflake en général, j'ai regroupé tous mes articles dans un parcours complet.

👉 Accéder à la Formation Snowflake

Tu veux que je t'accompagne sur ton projet data (Snowflake, pipelines déclaratifs avec Dynamic Tables, dbt, FinOps refresh) ?

👉 Réserver un appel de 30 minutes

Questions