Tabelle dinamiche di Snowflake spiegate: pipeline dati moderne

Le Dynamic Tables di Snowflake sono uno strumento potente nel kit di un data engineer. In sostanza, sono processi di aggiornamento automatizzati che usano query di trasformazione su tabelle di base per generare nuove tabelle. 

Le Dynamic Tables semplificano le pipeline di orchestrazione dei dati quando la freschezza è importante e servono trasformazioni complesse basate su SQL. Utilizzano una temporizzazione basata sul lag per aggiornare le tabelle in base alle modifiche delle tabelle di base.

I recenti miglioramenti ne hanno rafforzato le capacità, abilitando una propagazione dei dati quasi in tempo reale e un'integrazione più profonda nell'ecosistema di Snowflake (ripassa con questo corso introduttivo). 

Questa guida spiega come funzionano le Dynamic Tables, come implementarle in modo efficace e come monitorare e ottimizzare le prestazioni. Alla fine, sarai in grado di valutarle e testarle per capire se soddisfano le esigenze dati della tua organizzazione.

Cosa sono le Dynamic Tables di Snowflake?

Le Dynamic Tables sono una classe completamente gestita di oggetti del database Snowflake che aiutano a snellire e automatizzare le pipeline di dati. 

Invece di usare strumenti di orchestrazione esterni o provare a sincronizzare aggiornamenti manuali con gli update delle tabelle sorgente, le Dynamic Tables si aggiornano automaticamente in base ai cambiamenti nei dati sorgente e agli obiettivi di freschezza definiti. Questo consente ai professionisti dei dati di costruire trasformazioni flessibili che si aggiornano quando i dati cambiano.

A differenza delle viste, che richiedono il calcolo al momento della query, le Dynamic Tables restano materializzate, migliorando la velocità delle query. Allo stesso modo, mentre le viste materializzate offrono dati in cache, le Dynamic Tables possono utilizzare join, union e viste annidate, cosa che le viste materializzate non supportano.

Introdotte originariamente per colmare il divario tra le tradizionali pipeline ELT e le architetture event-driven, le Dynamic Tables rappresentano l'evoluzione di Snowflake verso un elaborazione dichiarativa e consapevole delle dipendenze. 

Tutto ciò che devi fare è scrivere la query SQL SELECT che definisce la tua Dynamic Table con un TARGET_LAG che ne determina la frequenza di aggiornamento. 

Per esempio, un TARGET_LAG di cinque minuti significa che la Dynamic Table è in ritardo di non più di cinque minuti rispetto alla tabella di base. La cosa migliore è che tutto questo è gestito dal motore di refresh interno di Snowflake e ci evita di progettare pipeline complesse!

Capire le Dynamic Tables di Snowflake

Per implementare efficacemente le tabelle dinamiche, analizzeremo alcune implementazioni tecniche sottostanti di Snowflake per capire punti di forza e limiti.

Architettura di base e meccaniche operative

Come le viste materializzate, le Dynamic Tables offrono un comportamento di aggiornamento persistente e automatico. Tuttavia, a differenza delle viste materializzate, consentono trasformazioni più complesse, come union e join. 

Questo permette di creare più Dynamic Tables più piccole che poi alimentano tabelle dinamiche più grandi.

Un'innovazione chiave è l'uso da parte di Snowflake di un grafo di dipendenze automatizzato. Puoi creare una tabella aggregata dinamica che si aggiorna al variare delle tabelle di base oppure costruire layer di Dynamic Tables usando grafi aciclici diretti. Funziona aggiornando una tabella di staging di base, che attiva l'aggiornamento di una tabella dinamica a valle. 

Una volta aggiornate queste tabelle dinamiche intermedie, si aggiorna la tabella dinamica aggregata finale. Tutto questo opera con i worker di refresh di Snowflake che rilevano gli aggiornamenti dei dati e garantiscono che le tabelle sorgente si aggiornino con dati aggiornati.

Dalla documentazione Snowflake sulla creazione delle Dynamic Tables

Dinamiche del meccanismo di refresh

I principali meccanismi che puoi controllare quando crei Dynamic Tables sono le modalità di refresh, il lag e i parametri del warehouse in fase di creazione. Le Dynamic Tables supportano due modalità di refresh:

• Modalità incrementale: Snowflake analizza le modifiche dall'ultimo refresh e le unisce nella tabella
• Modalità completa: Ricalcola l'intera tabella a ogni refresh e la sostituisce completamente

Puoi definire manualmente la modalità di refresh oppure usare REFRESH_MODE = AUTO nella creazione iniziale della tabella dinamica. Tieni solo presente che usando AUTO la modalità viene impostata alla creazione e non viene aggiornata. Se Snowflake determina che l'aggiornamento incrementale è inefficiente, opterà per un refresh completo.

L'impostazione WAREHOUSE determina il warehouse che verrà utilizzato per le risorse di calcolo. Assicurati di selezionare quello giusto in base alle tue esigenze di calcolo e archiviazione dati.

Forse il concetto più importante è il lag. Il modo più comune per definirlo è usare TARGET_LAG, che definisce il ritardo accettabile tra i dati sorgente e le tabelle dinamiche. Se stai lavorando con una pipeline più complessa in cui altre Dynamic Tables dipendono da tabelle dinamiche, puoi scegliere di impostare TARGET_LAG = DOWNSTREAM. 

Impostando il TARGET_LAG su DOWNSTREAM si guarda alle tabelle dinamiche a valle che dipendono dall'attuale Dynamic Table per la temporizzazione.

Tabella che riassume le differenze tra Dynamic Tables e tabelle tradizionali, viste e viste materializzate

Gestione delle dipendenze

Ogni Dynamic Table contribuisce a un DAG, permettendo a Snowflake di coordinare i refresh su più tabelle. Questo garantisce correttezza ed efficienza, soprattutto in pipeline multi-step.

Snowsight offre un'interfaccia visiva per esplorare questo DAG, mostrando dipendenze, tempi di refresh e metriche di lag. È un grande vantaggio per il debug e l'analisi d'impatto. Assicurati di leggere questo articolo sulle pipeline dati in Snowflake per maggiori informazioni su come funziona l'architettura di Snowflake.

Caratteristiche chiave e vantaggi comparativi

Vediamo alcune altre caratteristiche chiave delle Dynamic Tables e i loro vantaggi. 

Vantaggi rispetto alle architetture tradizionali

Le Dynamic Tables eliminano la necessità di orchestrazione esterna (ad es. Airflow o dbt Cloud) gestendo nativamente in Snowflake il tracciamento delle dipendenze e la logica di refresh.

Questo offre diversi vantaggi, tra cui:

• Orchestrazione semplificata: niente cron job o logiche di refresh manuali.
• Supporto CDC integrato: l'elaborazione incrementale è supportata nativamente.
• Monitoraggio unificato: stato dei refresh, lag e lineage sono visibili in Snowsight.
• Supporto al query rewrite: Snowflake può ottimizzare le query usando il lineage delle Dynamic Table.

Tutto questo permette alle Dynamic Tables di eccellere quando servono dati aggiornati e quasi in tempo reale. Pensa a dashboard real-time e workflow CDC. Inoltre, puoi concatenare più Dynamic Tables in sequenza per trasformazioni multi-stage.

Elaborazione dati in tempo reale e change data capture (CDC)

Invece di definire tempistiche manuali con job CRON, le Dynamic Tables utilizzano TARGET_LAG per confrontarsi con le tabelle sorgente. Per tabelle di dati in streaming in tempo reale, questo significa che appena la Dynamic Table va fuori sincrono oltre il lag indicato, si aggiorna automaticamente.

Anche se molto simili, le Dynamic Tables sono spesso usate come alternativa a Streams e viste materializzate. Le viste materializzate sono ottime se ti serve che i dati siano sempre aggiornati e usi una logica semplice su una singola tabella di base. 

Gli Streams sono ideali per implementare manualmente il CDC e per capire come i dati cambiano nel tempo. Le Dynamic Tables sono perfette quando vuoi un modo semplice per implementare aggiornamenti periodici su query di trasformazione complesse.

Per ulteriori considerazioni su come strutturare i dati in Snowflake, questo corso sul data modeling in Snowflake è un'ottima risorsa.

Implementare le Dynamic Tables di Snowflake

Vediamo come configurare le Dynamic Tables usando pattern di sintassi e best practice. Metterle in piedi è abbastanza semplice, ma capire bene i parametri ti permetterà di ottenere il massimo dalle tue tabelle dinamiche.

Framework di implementazione e sintassi

Ecco un esempio di come potremmo creare una Dynamic Table usando la tabella raw_sales come base. Dacci un'occhiata e poi la analizziamo.

# Your Dynamic Table parameters
CREATE OR REPLACE Dynamic Table sales_agg
  TARGET_LAG = '5 minutes'
  WAREHOUSE = 'prod_wh'
  REFRESH_MODE = auto
  INITIALIZE = on_create
  AS

# Your SQL query for the table itself
SELECT
  store_id,
  SUM(amount) AS total_sales,
  COUNT(*) AS sale_count
FROM raw_sales
GROUP BY store_id;Offerto da

La seconda parte dovrebbe essere piuttosto chiara: è la nostra istruzione SELECT, che definisce i dati nella tabella. La prima parte, prima della SELECT, contiene tutti i parametri di creazione: 

• TARGET_LAG: specifica il requisito di freschezza come spiegato sopra. Puoi impostare un intervallo temporale o scrivere “DOWNSTREAM” se un'altra Dynamic Table usa questi dati.
• WAREHOUSE: determina le risorse di calcolo. Assicurati di selezionare il warehouse Snowflake giusto per avere risorse sufficienti a generare la tabella in modo conveniente
• REFRESH_MODE: può essere impostato esplicitamente su INCREMENTAL o FULL. Io ho scelto AUTO per lasciare a Snowflake la scelta del metodo ottimale.
• INITIALIZE: determina quando la tabella viene inizializzata. ON_CREATE significa che la tabella è inizializzata immediatamente. Impostandolo su ON_SCHEDULE la tabella verrà inizializzata quando si raggiunge il primo periodo di lag.

Nota che Snowflake richiede il change tracking per supportare correttamente i refresh incrementali, quindi viene attivato automaticamente per le tabelle dinamiche incrementali! 

Se vuoi verificarlo manualmente, puoi usare il comando ALTER TABLE. Avere il change tracking attivo permette anche il time travel, nel caso sia necessario ripristinare versioni storiche delle tabelle.

CLONE e ICEBERG

Due particolarità delle Dynamic Tables sono il loro cloning e la connessione alle tabelle Snowflake Iceberg, basate su tabelle esterne Apache Iceberg. 

Per le tabelle Iceberg, nulla cambia in fase di setup. Il principale vantaggio delle Dynamic Tables costruite su tabelle Snowflake Iceberg è che consentono di continuare a elaborare dati esterni senza ingestion continua o duplicazione dei dati.

Il cloning è possibile grazie al time travel di Snowflake e possiamo copiare una versione precedente della nostra Dynamic Table usando il comando CLONE in questo modo:

CREATE Dynamic Table clone_sales_agg
CLONE sales_agg
AT (OFFSET => -24*60*60) –-24 hours ago
TARGET_LAG = DOWNSTREAM
WAREHOUSE = sales_whOfferto da

La nota qui è che le tabelle clonate potrebbero non condividere tutti i metadati della tabella sorgente e occupano spazio di archiviazione aggiuntivo. Usa il cloning con attenzione e assicurati che sia necessario.

Setup di dati di esempio

È una buona idea esercitarsi a configurare Dynamic Tables per testarne le funzionalità. Ecco una guida generale su come testarle:

• Crea una semplice tabella raw_sales con timestamp.
• Inserisci nuove righe periodicamente.
• Usa TARGET_LAG = '1 minute' per vedere gli aggiornamenti in azione.

Puoi, ad esempio, creare uno stream che guarda a un bucket S3 in cui caricare periodicamente dati. Al variare dei dati, potrai vedere come si aggiorna la tua Dynamic Table. Puoi seguire questo tutorial per impostare in modo semplice l'ingestion dei dati in Snowflake e poi questo tutorial per maggiori informazioni su come creare tabelle in Snowflake.

Monitorare e gestire le Dynamic Tables

Snowflake offre diversi strumenti per monitorare e gestire efficacemente le Dynamic Tables, come Snowsight o le query. Assicurati di avere i privilegi di monitor sul tuo account per vedere queste informazioni!

Metodi e strumenti di monitoraggio

Usare Snowsight per monitorare le Dynamic Tables è semplice:

• Vai su Data e seleziona Dabatases
• Seleziona il database e lo schema che contengono la tua Dynamic Table
• Seleziona la scheda Dynamic Tables
• Qui trovi l'elenco delle tabelle da selezionare per vedere ulteriori informazioni.

Snowsight può fornire ottime informazioni, come come è stata creata la Dynamic Table, il DAG e la cronologia e le metriche dei refresh.

Per fare lo stesso via SQL, usiamo il comando SHOW DYNAMIC TABLES. 

Per esempio, se voglio vedere tutte le mie tabelle dinamiche relative alle vendite:

SHOW Dynamic Tables LIKE ‘sales_%' IN SCHEMA mydb.myschema;Offerto da

Questo fornisce informazioni come data di creazione, dimensione, target lag e ultimo stato della tabella.

Gestione e modifica delle Dynamic Tables

Probabilmente arriverà il momento in cui vorrai modificare o sospendere la tua tabella dinamica. Per fortuna, Snowflake lo rende semplice.

Per sospendere la tabella, usiamo ALTER DYNAMIC TABLE e SUSPEND:

ALTER Dynamic Table sales_agg SUSPEND;Offerto da

Per riprenderla più tardi, facciamo lo stesso ma con RESUME:

ALTER Dynamic Table sales_agg RESUME;Offerto da

Per cambiare i parametri, possiamo anche usare ALTER DYNAMIC TABLE e SET per impostare il parametro specifico che vogliamo modificare:

ALTER Dynamic Table sales_agg SET TARGET_LAG = '10 minutes';Offerto da

Il modo migliore per gestire le dipendenze e ridurre al minimo le interruzioni operative è assicurarti di non sospendere tabelle critiche. Se prevedi di cambiare il lag, assicurati di capire come questo possa influenzare la tempistica delle tabelle a valle. 

Superare i vincoli operativi

Abbiamo visto che le Dynamic Tables sono molto utili, ma hanno comunque alcuni limiti e considerazioni.

Vincoli architetturali e limitazioni

Ci sono alcune limitazioni legate all'account e al tipo di sorgente. I vincoli attuali includono:

• Limite di 50.000 Dynamic Tables per account (a metà 2025).
• Non tutti i tipi di oggetti Snowflake sono supportati come sorgenti (ad es. streams)
• Le query delle Dynamic Table non sono tracciate nella vista di auditing ACCESS_HISTORY

Altre cose da considerare sono cloning, time travel e controllo degli accessi. Il time travel è forse il più semplice, poiché richiede un valore minimo di 1 giorno. Non puoi disattivarlo impostando DATA_RETENTION_TIME_IN_DAYS a 0. 

Quando cloni una tabella dinamica, sappi che non tutti i metadati vengono salvati. Inoltre, non è possibile clonare Dynamic Tables Iceberg. Se cloni una Dynamic Table che dipende da una Dynamic Table Iceberg, quest'ultima non viene spostata nella nuova posizione.

Creare e usare Dynamic Tables richiede i ruoli di accesso CREATE DYNAMIC TABLE, SELECT e USAGE per il database e lo schema padre. 

Ricordando questi vincoli, dovresti avere meno problemi con le tabelle dinamiche!

Tecniche di ottimizzazione delle prestazioni

Grazie alla loro semplicità di implementazione, è facile sovraccaricare il sistema. Un errore comune è trattare le Dynamic Tables come una pipeline dati in tempo reale. Non sono pensate per sostituire sorgenti dati real-time; dovremmo invece considerare timing e requisiti di recency dei dati. Ad esempio, possiamo seguire queste best practice:

• Usa REFRESH_MODE = incremental quando possibile, così da non ricreare l'intera Dynamic Table a ogni caricamento
• Ottimizza TARGET_LAG per bilanciare costi e freschezza dati richiesta dallo stakeholder.
• Scegli un WAREHOUSE di dimensioni adeguate per ottimizzare le risorse di calcolo utilizzate
• Suddividi grandi trasformazioni in tabelle intermedie più piccole.
• Scrivi SQL intelligente ed efficiente che non dipenda da join massivi e SELECT annidate.

Seguire questi semplici suggerimenti può mantenere le tue Dynamic Tables in forma. Usarle con criterio può davvero semplificare le pipeline dati critiche a costi minimi, ma usarle senza attenzione può creare più problemi in futuro!

Prezzi e considerazioni sui costi

Come accennato, ci sono costi di storage e compute associati all'uso delle Dynamic Tables. Possiamo mostrare alcune strategie per comprenderli e gestirli in Snowflake.

Componenti di costo

Ci sono due grandi componenti del costo nell'uso delle Dynamic Tables: storage e compute. Ognuna ha alcune voci, quindi vediamole nel dettaglio.

Costi di storage con le Dynamic Tables

Per lo storage, ti verrà addebitata l'archiviazione dei risultati materializzati di ogni Dynamic Table. Ci sono anche costi aggiuntivi per Time Travel, fail-safe storage e cloning. 

L'unica eccezione sono le dynamic iceberg tables, per cui non avrai costi di storage su Snowflake poiché sono archiviate esternamente. Puoi limitare questi costi rendendo la tua Dynamic Table il più snella possibile o riducendo al minimo cloning e time travel.

Costi di compute con le Dynamic Tables

I costi di compute hanno due parti principali: il virtual warehouse e il compute dei Cloud Services. I virtual warehouse sono le risorse che usi per inizializzare e aggiornare le tabelle; pensa ai costi di esecuzione della query. 

Il compute dei Cloud Services riguarda più l'automazione fornita da Snowflake. Include l'identificazione delle modifiche negli oggetti di base e il mantenimento dei DAG. Pensa a tutto il lavoro in background che Snowflake fa per mantenere operative le tue Dynamic Tables. 

Questo dipende dal lag definito per la tabella, e il costo è direttamente legato a quella frequenza.

Per un quadro completo di come si compongono questi costi, fai riferimento alla documentazione sui costi di Snowflake, che ne scompone le componenti.

Monitoraggio dei costi e risparmi

Snowflake semplifica il monitoraggio di questi costi tramite Snowsight. Vai su Monitoring, poi Dynamic Tables come al solito, e nella pagina della tabella dinamica c'è la scheda Refresh History che mostra i crediti di warehouse utilizzati.

Se vuoi vedere l'uso più ampio del tuo account, puoi anche usare la seguente query:

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.METERING_HISTORY;Offerto da

Questo restituisce i costi sostenuti dai diversi servizi sull'account e può essere collegato alle tue tabelle dinamiche. 

Inoltre, ti consiglio di testare su un warehouse dedicato così da comprendere appieno i costi di warehouse associati alla tabella dinamica. Una volta compresi i costi, puoi spostarle sui warehouse condivisi.

Se vuoi risparmiare, considera l'auto-suspension. Le Dynamic Tables sospese pagano solo lo storage e non le risorse di refresh. 

Puoi anche usare Dynamic Tables transient che non hanno costi di fail-safe storage. Inoltre, se ottimizzi il tuo TARGET_LAG alla frequenza giusta e usi il refresh incrementale quando possibile, puoi risparmiare molto sul compute. 

Come sempre, scrivere buon SQL e trasformazioni ottimizzate è anche un ottimo modo per ridurre l'uso delle risorse di calcolo.

Casi d'uso delle Dynamic Tables di Snowflake

Le Dynamic Tables possono essere usate ovunque tu voglia sostituire una pipeline ETL complicata e basata sul tempo con una pipeline più semplice, basata sul lag e autogestita.

Pattern di deployment enterprise

Ecco alcuni casi d'uso di deployment che potrebbero esserti utili a seconda del settore.

Per le organizzazioni finanziarie, può essere utile avere aggiornamenti periodici dei dati transazionali, come rilevamento frodi o chargeback. 

Dato che non servono dati al secondo, potremmo preferire un TARGET_LAG di 10 minuti per dashboard di salute del sistema. Magari hai un modello di data science che salva tutti gli alert di frode in una tabella e un sistema di monitoraggio dei chargeback di terze parti che salva in un'altra. 

Puoi unire le due in una tabella aggregata in modo semplice, senza bisogno di DAG complessi in Airflow. Questo dovrebbe semplificare e migliorare le prestazioni delle query.

Per l'analytics retail, potremmo essere interessati alle performance delle diverse regioni. È possibile che ogni regione abbia il proprio database centrale che invia dati periodicamente, ma con leggere asincronie. Invece di costruire pipeline ETL che devono adattare la loro tempistica a ciascun database, possiamo costruire una Dynamic Table che li aggrega in base ai lag di ciascuna tabella. Questo riduce la complessità della pipeline e minimizza la necessità di manutenzione costante.

Altri scenari possono includere:

• Analytics comportamentale in tempo reale: aggrega in tempo reale le informazioni sul comportamento dei clienti per riassumere trend emergenti
• Workflow CDC: mantieni dati quasi in tempo reale per i cambiamenti operativi e tenere traccia dei problemi di business
• Data vault modeling: aggiungi incrementalmente nuovi dati all'arrivo e fungi da unica fonte su come i dati sono stati ingestiti

Conclusione

Le Dynamic Tables di Snowflake sono uno strumento eccezionale per semplificare pipeline ETL complesse e basate sul tempo. Offrono un equilibrio elegante tra automazione, flessibilità e prestazioni. Ricorda alcune best practice, come testare su pipeline non critiche per comprendere il comportamento di refresh, monitorare lag e metriche di costo e usare i DAG visivi per capire le dipendenze.

Le Dynamic Tables non sostituiscono completamente Streams e Tasks in ogni scenario, ma offrono un'opzione robusta che minimizza il codice e massimizza l'efficienza. Usale con giudizio e potrai semplificarti molto la vita. Per maggiori informazioni su Snowflake e qualche ripasso di SQL, consulta le seguenti risorse:

• Cheat Sheet di base SQL
• Snowflake Foundations
• Approfondimento sull'architettura di Snowflake
• Migliori certificazioni Snowflake 2025
• Le 32 migliori domande di colloquio su Snowflake