Snowflake nel 2026: architettura, SQL e domande di colloquio per data engineer

Le domande dei colloqui su Snowflake verificano se un data engineer comprende l'architettura disaccoppiata della piattaforma, non solo la sua sintassi SQL. Il design multi-cluster shared-data introdotto da Snowflake separa storage, compute e servizi in tre livelli indipendenti, e questa separazione spiega quasi ogni decisione di performance e di costo che un team prende sulla piattaforma. Questa guida illustra l'architettura di Snowflake, i pattern SQL che mantengono le query veloci ed economiche nel 2026 e le domande dei colloqui che rivelano una reale esperienza in produzione.

Architettura di Snowflake: storage, compute e cloud services

Il tratto distintivo dell'architettura di Snowflake è che storage e compute sono fisicamente separati. I dati risiedono una sola volta in un livello di storage centralizzato, appoggiato a object store cloud come Amazon S3 o Azure Blob Storage. Un numero qualsiasi di cluster di compute può leggere gli stessi dati in modo concorrente senza copiarli, un approccio che il team di ingegneria originario ha chiamato multi-cluster shared data nel paper SIGMOD del 2016 che ha presentato questo design.

Il livello di storage conserva i dati in file immutabili, compressi e in formato colonnare chiamati micro-partition. L'utente non gestisce mai direttamente questi file. Snowflake li scrive, ne traccia i metadati e li recupera. Il livello di compute è costituito dai virtual warehouse, ciascuno un cluster di server che Snowflake provisiona on demand. Il cloud services layer sta al di sopra di entrambi e coordina ogni cosa: analizza l'SQL, pianifica le query, applica il controllo degli accessi, gestisce le transazioni e conserva i metadati che rendono possibili funzionalità come Time Travel e zero-copy cloning.

Poiché questi livelli sono indipendenti, un warehouse può essere ridimensionato o eliminato senza toccare un solo byte di dati, e lo storage può crescere fino ai petabyte senza provisionare alcun compute.

-- setup_warehouse.sql
-- Create an isolated compute cluster and a database.
CREATE WAREHOUSE analytics_wh
  WAREHOUSE_SIZE = 'MEDIUM'      -- 4 credits/hour, doubles each size step
  AUTO_SUSPEND = 60             -- suspend after 60s idle to stop billing
  AUTO_RESUME = TRUE            -- resume automatically on the next query
  INITIALLY_SUSPENDED = TRUE;

CREATE DATABASE sales_analytics;
USE WAREHOUSE analytics_wh;
USE DATABASE sales_analytics;

-- Storage and compute are independent: dropping the warehouse
-- leaves every table in sales_analytics untouched.

Eliminare analytics_wh dopo l'esecuzione di questo script interromperebbe tutta la fatturazione del compute, mentre ogni tabella resterebbe interrogabile nel momento stesso in cui viene creato un nuovo warehouse. Questo disaccoppiamento è l'idea più importante da saper esprimere in un colloquio.

Come i virtual warehouse scalano il compute di Snowflake

Un virtual warehouse è un cluster di compute con un nome, dimensionato in unità stile taglie di magliette: X-Small, Small, Medium, Large e oltre. Ogni gradino raddoppia sia il numero di server sia il consumo di credit all'ora, quindi un warehouse Large costa quattro volte uno Small ma completa anche una query scan-heavy circa quattro volte più rapidamente. Questo compromesso lineare tra prezzo e prestazioni significa che l'opzione più economica è spesso un warehouse più grande che gira per un tempo più breve.

Esistono due dimensioni di scaling, e confonderle è una tipica trappola dei colloqui. Lo scaling verticale ridimensiona un singolo warehouse per rendere più veloce una query. Lo scaling orizzontale aggiunge cluster a un warehouse multi-cluster per servire più query concorrenti. Una dashboard colpita da 200 analisti alle 9 del mattino ha bisogno di più cluster, non di uno più grande; un backfill notturno di mille miliardi di righe ha bisogno di uno più grande, non di più cluster.

-- scale_compute.sql
-- Multi-cluster warehouse: add clusters when concurrency rises and
-- remove them when demand falls. Each cluster is a separate MEDIUM engine.
ALTER WAREHOUSE analytics_wh SET
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 4          -- up to 4 clusters during peak load
  SCALING_POLICY = 'STANDARD';   -- favor performance over credit savings

-- Resize vertically for one heavy job, then shrink back afterward.
ALTER WAREHOUSE analytics_wh SET WAREHOUSE_SIZE = 'XLARGE';
-- ... run the heavy backfill ...
ALTER WAREHOUSE analytics_wh SET WAREHOUSE_SIZE = 'MEDIUM';

AUTO_SUSPEND e AUTO_RESUME sono ciò che rende tutto questo economico. Un warehouse sospeso non costa nulla, e Snowflake fattura al secondo con un minimo di 60 secondi. Impostare un auto-suspend breve sui warehouse interattivi impedisce ai cluster inattivi di bruciare credit tra una query e l'altra.

Micro-partition e clustering key per un SQL veloce

Snowflake memorizza ogni tabella come un insieme di micro-partition, ciascuna contenente da 50 a 500 MB di dati non compressi in formato colonnare. Per ogni micro-partition, Snowflake registra nei suoi metadati il valore minimo e massimo di ciascuna colonna. Quando una query filtra su una colonna, l'optimizer legge quei metadati e salta qualsiasi partition il cui intervallo di valori non può corrispondere, un processo chiamato partition pruning. Ecco perché Snowflake non ha bisogno di indici manuali: il pruning avviene automaticamente su ogni colonna.

Il pruning funziona al meglio quando la colonna del filtro è correlata all'ordine in cui i dati sono stati caricati. Una tabella ingerita per data effettua un pruning efficiente sulle query per intervallo di date. Quando una tabella di grandi dimensioni viene frequentemente filtrata su una colonna non correlata all'ordine di caricamento, una clustering key co-localizza le righe correlate tra le micro-partition, così che il pruning resti efficace man mano che la tabella cresce.

-- clustering.sql
-- Filters on naturally ordered columns prune partitions with no index.
SELECT order_date, SUM(amount_usd) AS revenue
FROM orders
WHERE order_date BETWEEN '2026-01-01' AND '2026-03-31'
GROUP BY order_date;

-- For a multi-terabyte table queried by a non-load-order column,
-- a clustering key co-locates related rows to keep pruning effective.
ALTER TABLE orders CLUSTER BY (customer_region, order_date);

-- Inspect clustering depth before committing to a key.
SELECT SYSTEM$CLUSTERING_INFORMATION('orders', '(customer_region, order_date)');

Le clustering key non sono gratuite: Snowflake esegue un servizio automatico in background per mantenerle, e quel servizio consuma credit. La regola pratica è aggiungere una clustering key solo alle tabelle nell'ordine dei terabyte in cui i query profile mostrano un pruning scadente. Le tabelle più piccole effettuano già un buon pruning da sole, e una clustering key prematura fa sprecare denaro. Spiegare questo compromesso è spesso ciò che distingue una risposta junior da una senior.

Caricare e trasformare i dati: Snowpipe, Streams e Dynamic Tables

Tre pattern di ingestion coprono la maggior parte dei carichi di lavoro. Il COPY INTO bulk carica i file in staging con un singolo comando ed è adatto ai job batch pianificati. Snowpipe carica i file in modo continuo in micro-batch serverless, attivati dagli eventi dello storage cloud, per un arrivo dei dati quasi in tempo reale. Snowpipe Streaming spinge le singole righe attraverso un'API a bassa latenza quando conta una freschezza inferiore al secondo. Sceglierli in base ai requisiti di latenza e di dimensione dei file è una domanda frequente nei colloqui, e la risposta corretta parte da "dipende dalla freschezza che il consumatore a valle richiede realmente".

La trasformazione all'interno del warehouse si è storicamente basata su Streams e Task. Uno Stream cattura le modifiche a livello di riga su una tabella (change data capture), e un Task esegue SQL secondo una pianificazione per consumare quelle modifiche e fonderle a valle.

-- incremental_pipeline.sql
-- A stream tracks row-level changes (CDC) on the raw landing table.
CREATE STREAM orders_stream ON TABLE raw_orders;

-- A task consumes the stream on a schedule and merges changes downstream.
CREATE TASK refresh_orders
  WAREHOUSE = analytics_wh
  SCHEDULE = '5 MINUTE'
  WHEN SYSTEM$STREAM_HAS_DATA('orders_stream')
AS
  MERGE INTO orders t
  USING orders_stream s ON t.order_id = s.order_id
  WHEN MATCHED THEN UPDATE SET t.amount_usd = s.amount_usd
  WHEN NOT MATCHED THEN INSERT (order_id, amount_usd)
    VALUES (s.order_id, s.amount_usd);

Nel 2026, le Dynamic Tables sono diventate il modo preferito per esprimere le trasformazioni incrementali. Invece di collegare uno Stream a un Task e scrivere il merge a mano, una Dynamic Table dichiara un target lag e una query, e Snowflake calcola automaticamente il refresh incrementale. Elimina gran parte del boilerplate di orchestrazione mantenendo al tempo stesso i risultati aggiornati.

-- dynamic_table.sql
-- Dynamic Tables replace the stream + task pattern with a declarative
-- target lag. Snowflake computes the incremental refresh automatically.
CREATE DYNAMIC TABLE daily_revenue
  TARGET_LAG = '5 minutes'
  WAREHOUSE = analytics_wh
AS
  SELECT order_date, SUM(amount_usd) AS revenue
  FROM orders
  GROUP BY order_date;

Per i team che costruiscono su formati aperti, le tabelle Iceberg di Snowflake consentono al warehouse di leggere e scrivere dati Apache Iceberg memorizzati nel bucket cloud del cliente, evitando il lock-in pur mantenendo il motore di query e la governance di Snowflake. Molti team abbinano Snowflake a dbt per trasformazioni versionate e testate, un flusso di lavoro trattato nella guida alle trasformazioni dei dati e ai test con dbt.

Domande dei colloqui su Snowflake per data engineer

Le domande che seguono ricorrono di continuo nei colloqui di data engineering su Snowflake. Le risposte solide collegano una funzionalità alla separazione tra storage e compute, invece di recitare la sintassi.

Quale problema risolve la separazione tra storage e compute? Elimina la contesa. Analisti che eseguono dashboard, un team di data science che addestra feature e un job ELT che carica dati possono girare ciascuno sul proprio warehouse sulle stesse tabelle, senza competere per le risorse né copiare i dati. Il compute scala verso l'alto per un job pesante e si sospende quando è inattivo, mentre il costo dello storage resta costante indipendentemente da quanto compute vi sia collegato.

Come funzionano Time Travel e zero-copy cloning? Entrambi si basano sull'immutabilità delle micro-partition. Poiché Snowflake non sovrascrive mai una micro-partition, le versioni più vecchie restano su disco per la finestra di retention (fino a 90 giorni su Enterprise). Time Travel interroga una tabella a un timestamp passato puntando a quelle partition più vecchie, e CLONE crea una nuova tabella che referenzia le stesse partition senza duplicare lo storage finché un lato non viene modificato. Il copy-on-write è ciò che rende istantaneo e quasi gratuito il clone di una tabella da un petabyte.

Quando definire una clustering key? Solo su tabelle di grandi dimensioni (all'incirca un terabyte o più) che vengono frequentemente filtrate o joinate su una colonna non correlata al loro ordine di caricamento, e solo dopo che un query profile ha confermato un pruning scadente. Il clustering comporta un costo continuo in credit di manutenzione, quindi è un'ottimizzazione deliberata, non un'impostazione predefinita.

Come si controlla il costo di Snowflake? Attraverso il dimensionamento dei warehouse, un auto-suspend aggressivo, l'allineamento del numero di cluster alla concorrenza reale e i resource monitor che limitano la spesa in credit. Un resource monitor può notificare o sospendere automaticamente i warehouse una volta raggiunta una quota.

-- cost_control.sql
-- A resource monitor caps credit spend and suspends warehouses
-- automatically when the monthly quota is reached.
CREATE RESOURCE MONITOR monthly_cap
  WITH CREDIT_QUOTA = 1000
  FREQUENCY = MONTHLY
  START_TIMESTAMP = IMMEDIATELY
  TRIGGERS
    ON 80 PERCENT DO NOTIFY
    ON 100 PERCENT DO SUSPEND;

ALTER WAREHOUSE analytics_wh SET RESOURCE_MONITOR = monthly_cap;

Streams e Task oppure Dynamic Tables? Le Dynamic Tables sono adatte alle pipeline dichiarative in cui il requisito è una freschezza obiettivo e Snowflake può gestire il refresh. Streams e Task restano lo strumento giusto quando la trasformazione necessita di controllo imperativo, side effect o logica che una singola query non può esprimere. Sapere dove si colloca ciascuno, invece di ripiegare sempre su uno solo, segnala esperienza in produzione.

In cosa differisce l'ELT su Snowflake dal tradizionale ETL? Lo storage economico e il compute elastico di Snowflake rendono pratico caricare prima i dati grezzi e trasformarli sul posto, il pattern approfondito nella guida all'architettura ETL vs ELT. I candidati che si preparano per il ciclo completo possono esercitarsi con il modulo sui pattern ETL ed ELT insieme al più ampio percorso di data engineering.

Conclusione

• L'architettura di Snowflake separa storage, compute e cloud services in tre livelli indipendenti, e quasi ogni risposta di design riconduce a quella separazione
• I virtual warehouse scalano verticalmente per query singole più pesanti e orizzontalmente per una maggiore concorrenza; auto-suspend e fatturazione al secondo mantengono gratuito il compute inattivo
• Le micro-partition con metadati min/max per colonna forniscono un partition pruning automatico, ed è per questo che Snowflake non ha bisogno di indici manuali
• Aggiungere clustering key solo alle tabelle su scala terabyte con un pruning comprovatamente scadente, poiché la manutenzione consuma credit
• Allineare il pattern di ingestion alla freschezza richiesta: COPY bulk per il batch, Snowpipe per micro-batch continui, Snowpipe Streaming per latenza inferiore al secondo
• Preferire le Dynamic Tables per le trasformazioni incrementali dichiarative nel 2026 e riservare Streams e Task alla logica imperativa
• Time Travel e zero-copy cloning sfruttano entrambi l'immutabilità delle micro-partition e il copy-on-write, rendendo economiche le query point-in-time e i clone istantanei
• Controllare il costo con warehouse dimensionati correttamente, auto-suspend aggressivo, cluster allineati alla concorrenza e resource monitor