Snowflake Gen2 Warehouses: i guadagni di velocità valgono davvero il costo?

I warehouse Gen2 sfruttano hardware più veloce reso disponibile dai cloud provider sottostanti (AWS, GCP). Inoltre, il team di Snowflake ha investito in ottimizzazioni software specifiche per i Gen2, che si traducono in ulteriori miglioramenti di performance e costo. Quasi tutte le query trarranno vantaggio dalle migliorie hardware, ma alcuni workloads specifici beneficeranno anche delle ottimizzazioni software.

Al momento i Gen2 Warehouses hanno disponibilità limitata, ma è ragionevole attendersi un'estensione rapida ad altre region. Consulta questa pagina per verificare se Gen2 è disponibile nella tua region.

Miglioramenti hardware

I virtual warehouse Gen2 di Snowflake girano sull'infrastruttura di calcolo del cloud provider, ad esempio istanze EC2 o macchine virtuali. Con il tempo, questi provider aggiornano le proprie istanze con hardware più recente: AWS, per esempio, ha introdotto da poco i processori Graviton4 basati su architettura ARM. Sebbene Snowflake non dichiari quale hardware utilizzi nello specifico, è plausibile che stia sfruttando le offerte più recenti di ciascun provider. Tra le novità troviamo letture più rapide da disco locale, prestazioni CPU potenziate e maggiore throughput di rete: tutti fattori che si traducono in performance migliori delle query, fin da subito.

Miglioramenti software

Snowflake ha inoltre dichiarato di aver introdotto diverse ottimizzazioni software pensate per accelerare i workloads DML (cioè i job che fanno merge o update dei dati nelle tabelle) e alcune query complesse.

Come vedremo dai risultati della nostra analisi, queste migliorie software sono probabilmente all'origine dei guadagni prestazionali più marcati.

Dato che i warehouse Gen2 girano su hardware più nuovo e performante, costano di più. Come si vede dalla tabella dei prezzi qui sotto (fonte), i warehouse Gen2 costano il 35% in più su AWS e GCP, e il 25% in più su Azure.

Si tratta di un dato con implicazioni rilevanti, che ogni professionista dovrebbe valutare prima del passaggio. Anche se le query risultano più rapide, occorre verificare che la riduzione del tempo di calcolo compensi davvero l'aumento del costo. A complicare il quadro, la maggior parte dei professionisti configura i warehouse per sospendersi dopo 60 secondi di inattività: questo significa pagare la tariffa maggiorata anche durante il tempo di idle, e conviene tenerne conto nell'analisi.

Calcolo del break-even

Poiché su Gen2 le query girano più rapidamente ma vengono fatturate a una tariffa più alta per un tempo minore, la formula del break-even è:

Riduzione di tempo richiesta (%) = 1 - (1 / Fattore di aumento del prezzo)

Su Azure serve una riduzione del 20% del tempo di attività del warehouse per raggiungere il break-even.

• 1 - (1 / 1.25) = 0.20

Su AWS serve una riduzione del 25,9% del tempo di attività del warehouse per raggiungere il break-even.

• 1 - (1 / 1.35) = 0.259

Il benchmark l'ho effettuato su AWS. Di conseguenza, per restare cost neutral le performance devono migliorare almeno del 25,9%.

Attenzione al periodo minimo di fatturazione di 1 minuto

Ricorda che ogni volta che un warehouse riparte vengono fatturati 60 secondi. Quindi, se una query passa da 30 secondi su Gen1 a 15 secondi su Gen2, non stai risparmiando: stai pagando di più. Sta a te decidere se i guadagni di performance valgono i costi aggiuntivi.

Lo scenario di risparmio ideale: workloads che durano più di 1 minuto E generano un risparmio superiore alla percentuale di break-even indicata sopra.

La tabella qui sotto riassume il concetto.

Creare un nuovo warehouse Gen2, o convertirne uno esistente in Gen2, è molto semplice: basta passare il parametro resource_constraint nell'istruzione create o alter. Ecco un esempio per entrambi i casi:

-- create new
CREATE OR REPLACE WAREHOUSE my_wh
WAREHOUSE_SIZE = MEDIUM
RESOURCE_CONSTRAINT = STANDARD_GEN_2;

-- alter existing
ALTER WAREHOUSE legacy_wh
SET RESOURCE_CONSTRAINT = STANDARD_GEN_2;

Snowflake include un database di esempio che contiene il dataset TCP-H, definito dal Transaction Processing Performance Council come standard per il benchmarking di workloads analitici.

In Snowflake questi schemi si trovano nel database snowflake_sample_data:

• TPCH_SF1
• TPCH_SF10
• TPCH_SF100
• TPCH_SF1000

SF sta per Scale Factor: SF10 è 10 volte più grande di SF1, e così via. Abbiamo testato vari tipi di workloads su SF10, SF100 e SF1000.

Abbiamo coperto tre scenari principali:

1. dbt: costruzione di un progetto dbt composto interamente da modelli Table e test. L'obiettivo è capire se i progetti dbt, ampiamente diffusi su Snowflake, siano buoni candidati per i warehouse Gen2.
2. Query di select: qui simuliamo quello che succede in uno strumento di BI o in altre applicazioni rivolte agli utenti finali.
3. Workloads DML: l'update e il merge di nuovi dati su Snowflake è un workload tipico dei team di data engineering. Abbiamo testato diversi scenari DML (update, merge, ecc.) per capire come vengono impattati.

dbt

Setup

Abbiamo effettuato il fork di un progetto dbt esistente che lavora con i dataset Snowflake TCPH e lo abbiamo aggiornato. Il nostro repository è disponibile qui.

Abbiamo eseguito il progetto dbt a piena potenza su ciascun dataset, con warehouse di dimensioni diverse, confrontando Gen1 e Gen2. Per simulare uno scenario realistico, abbiamo usato warehouse più piccoli sui dataset più piccoli e warehouse più grandi su quelli più grandi.

Ogni iterazione è stata costruita in uno schema nuovo per evitare il caching e per conservare separatamente i risultati di ciascun test. Ogni build esegue 16 modelli di tabella e 43 data test (dbt build --exclude tag:merge-test).

Risultati

Ecco i risultati:

Il lavoro svolto in questo progetto dbt corrisponde a circa il 97% di query CTAS (modelli di tabella) e al 3% di test dbt (semplici query di select).

Su questa base, per i modelli di tabella di dbt in questo specifico progetto, il guadagno prestazionale non è sempre sufficiente a giustificare il 35% di costo in più.

Vale anche la pena notare che il warehouse 4XL Gen2 ha avuto un tempo di cold start molto lungo, oltre 5 minuti, mentre il 4XL Gen1 si è avviato immediatamente. Poiché il tempo di resume del warehouse non viene fatturato, lo abbiamo escluso dai risultati avviando il warehouse in anticipo prima di lanciare dbt. I tempi di provisioning di solito non rappresentano un problema per i job ETL notturni, ma è bene segnalarlo.

Semplici istruzioni di select

Abbiamo eseguito un campione di query di select sui dataset TPCH per simulare quello che succede in uno strumento di BI o in altre applicazioni rivolte agli utenti finali. Le query effettivamente eseguite sono linkate nella tabella. Ecco i risultati:

La query "Select, Aggregate" si trova qui.

La query "Select, join, aggregate" si trova qui.

Queste istruzioni di select mostrano ottimi guadagni di performance e tutte fanno risparmiare su Gen2 al secondo. Va però ricordato che, dato che queste query rivolte agli utenti finali devono essere rapide, ci scontriamo con la peculiarità del periodo minimo di fatturazione di Snowflake. Se le query durano meno di 60 secondi e/o il warehouse rimane in idle per periodi prolungati (cosa frequente negli strumenti di BI), Gen1 resta la scelta consigliata, a meno che tu non voglia ottimizzare specificamente per la velocità e sia disposto ad assorbire i costi aggiuntivi.

Vale la pena ricordare anche che i warehouse Gen2 aprono la strada a un ridimensionamento verso il basso. Per esempio, se con Gen2 dimezzi i tempi di esecuzione ma i costi salgono perché il tempo di idle diventa più caro, puoi tranquillamente dimezzare la taglia del warehouse, ottenere le stesse performance a un costo inferiore e generare un risparmio significativo.

DML: update su tabelle di grandi dimensioni

Gli update di questa sezione sono tutti update semplici del tipo update table <tbl> set column <col> = value. Da notare che, anche aggiornando una sola colonna, Snowflake deve comunque riscrivere l'intera micro-partition per quella riga. Quindi, di fatto, questi due comandi richiedono la stessa quantità di "lavoro" da parte di Snowflake:

update orders_table set customer_id=5 where order_id=1;
update orders_table set customer_id=5, amount=22.05, order_date='2025-05-01',
<many columns>
where order_id=1;

Abbiamo eseguito tre scenari:

• Un update senza clausola where su 6 miliardi di righe.
• Un update selettivo sulla stessa tabella, in cui vengono aggiornate solo 2,4 milioni di righe (lo 0,04% della tabella).
• Update di una singola riga.
• Le istruzioni SQL si trovano qui.

I risultati mi sembrano piuttosto eloquenti: i warehouse Gen2 sono molto efficaci sugli update filtrati, probabilmente grazie alle specifiche ottimizzazioni software rilasciate da Snowflake.

Analizziamo più nel dettaglio la query con un -79% di delta di costo, per capire da dove arrivi un miglioramento così marcato.

Lo screenshot mostra una riduzione del 99% dei byte scritti!

(0,16 GB – 16,56 GB) / 16,56 GB = -99%

DML: query di merge

Setup

A differenza dei semplici update visti sopra, le query di merge aggiornano i record nella tabella di destinazione sulla base dei record di una sorgente. In questo caso si usa una join per aggiornare i record corrispondenti e inserire quelli nuovi.

Le query di merge con n% di righe aggiornate sono modelli incrementali dbt. Si eseguono con dbt run -s pre_merge+, modificando il filtro sul limite di righe alla riga 22. Simulano uno scenario incrementale reale, in cui solo una frazione dei dati è nuova o aggiornata. Per cambiare la percentuale di dati aggiornati basta modificare questa riga ed eseguire il modello e il modello incrementale a valle.

I task "Merge, all rows updated" provengono da questa query, che aggiorna tutte le righe dei dati.

Tieni presente che il dataset SF10 contiene circa 60 milioni di righe e SF100 circa 600 milioni.

Risultati

I risultati mostrano in modo chiaro che le query di merge che aggiornano un numero ridotto di record beneficiano di un miglioramento prestazionale maggiore rispetto ai merge a tappeto.

La prova è nel query profile, che rivela diversi dettagli interessanti. Anzitutto, la comunicazione di rete è scesa drasticamente, dal 41% al 13%. Il cambiamento è probabilmente legato al crollo dei byte scritti—da 1,6 GB a soli 4,65 MB. Ciò suggerisce che Snowflake potrebbe aver migliorato la compressione o ottimizzato il modo in cui i dati transitano sulla rete. Dato che entrambe le query aggiornano solo 100 righe, l'ipotesi che Gen2 includa ottimizzazioni specifiche per scrivere i dati in modo più efficiente trova ulteriore conferma.

Un'anomalia

L'unica anomalia (nella penultima riga, dove il risparmio è solo dell'1%) è davvero interessante, perché Snowflake indica che i byte scritti si sono ridotti del 99,5%. Le spiegazioni possibili sono diverse: tra queste, il throttling di S3 e la velocità di rete.

Tutti i risultati visti sopra sono espressi al secondo. Ma come accennato, anche il tempo di idle successivo all'esecuzione delle query va considerato. Proviamo a costruire uno scenario semplice. Nella tabella sottostante assumiamo che Gen2 esegua una query nel 50% in meno di tempo rispetto a Gen1: un'ipotesi molto generosa, ma manteniamoci sul semplice. Ipotizziamo anche un auto-suspend configurato a 60 secondi. Otteniamo:

Ovviamente, più lungo è il workload, minore è l'impatto. La tabella qui sotto dà un'idea di come questo impatto si riduca al crescere della durata della query:

Il fenomeno si può esprimere con una funzione:

% tempo idle = [secondi di auto-suspend] / ([tempo query] + [secondi di auto-suspend])

Per i clienti Snowflake che puntano a ottimizzare le performance, l'impatto del tempo di idle è trascurabile rispetto al costo di tenere un data engineer impegnato a fare il tuning delle query, consumando ulteriori credit nel farlo! Ma il tempo di idle va comunque tenuto in considerazione.

Lettura dei risultati aggregati

Leggere i risultati aggregati può essere fuorviante, perché sono fortemente influenzati dal numero di query eseguite in ciascuna categoria e dalla taglia del warehouse. Inoltre, nascondono il fatto che singole query all'interno di una categoria possano avere risultati molto diversi rispetto all'aggregato.

Nonostante questo limite, è comunque utile osservare i dati aggregati, perché ci permettono di capire che la variazione di costo e di performance non è uniforme.

Qui sotto trovi i risultati dei test sopra descritti, consolidati per una lettura più agevole.

La lezione, secondo me, è una: sperimenta sempre con il tuo dataset per vedere come si comporta Gen2 sui tuoi casi d'uso specifici. Come per quasi tutto nel cloud, è davvero difficile dire quale tecnologia sia universalmente più economica o migliore: dipende sempre dal caso d'uso.

Detto questo, alcuni punti chiave emergono con chiarezza:

• Ora abbiamo una leva a costo zero che permette di velocizzare le query e, di solito, ridurre i costi.
• Le semplici query di select sono tra le migliori in assoluto nei nostri test, con un risparmio del 26%.
  • Possono però risultare più costose se eseguite su warehouse non saturi per periodi inferiori al minimo di fatturazione.
  • Tieni presente che potrebbe essere del tutto accettabile pagare il 10% in più (per esempio, 10.000 $ in più all'anno) per ottenere un miglioramento del 20% a costo zero per tutti gli utenti business. Valuta il trade-off pensando a quanto tempo ti servirebbe per implementare tu stesso queste ottimizzazioni.
• Su update mirati e semplici query di select con full table scan, Gen2 è nettamente superiore a Gen1.
• Gen2 non è necessariamente più economico sui tipici modelli di tabella dbt. Il motivo è probabilmente la riscrittura di tutte le partition tramite "create or replace table as". Potrebbe invece risultare più economico e veloce sui modelli incrementali che coinvolgono istruzioni di merge.

Un ottimo caso d'uso per i warehouse Gen2, a mio avviso, è quando il warehouse attuale è sotto pressione e si sta valutando un upgrade, ad esempio da Medium a Large. Invece di passare a Large, dove i credit costano il 100% in più, prova a passare a Gen2 Medium e pagherai solo il 35% in più per ciascun credit. Personalmente, sto iniziando a considerare Gen2 come un mezzo gradino tra una taglia di warehouse e l'altra.

• Il risparmio totale è stato del 2%, ma il dato è fortemente influenzato dai due workloads più grandi.
• Escludendo i due maggiori consumatori di credit, il risparmio totale sale al 7%.

Discutendo i nostri risultati con una persona di Snowflake, ci è stata detta una frase che ci ha colpiti: "L'unica cosa che un benchmark ti dice è quanto è stato veloce quel benchmark". Sono molti i fattori da considerare per capire come questo impatterà sui tuoi workloads di produzione.

• Assenza di concorrenza: nella maggior parte dei casi i benchmark vengono eseguiti su warehouse non saturi, dove la concorrenza non è un problema.
• Rumore transitorio: la stessa query, eseguita nelle stesse condizioni in un altro momento, può variare di circa il 10% in più o in meno per via della naturale variabilità dell'infrastruttura cloud sottostante (problemi transitori, throttling del servizio AWS S3, ecc.).

Il nostro consiglio è di eseguire Gen2 su workloads mirati per un periodo di tempo, magari una settimana, per osservare l'impatto reale sui costi nel proprio ambiente.

In SELECT vogliamo costruire un approccio al benchmarking più solido e scientifico. Immaginiamo uno scenario in cui Python esegue la stessa query più volte sullo stesso dataset utilizzando warehouse diversi. Questo ci permetterà di ottenere un campione più ampio, in cui ogni singolo risultato pesa meno sulla media. Restate sintonizzati!

Ci farebbe piacere conoscere la vostra esperienza con i warehouse Gen2! Contattateci e raccontateci eventuali scoperte interessanti o casi di risparmio sui costi!

Jeff è un Data and Analytics Consultant con oltre 15 anni di esperienza nell'automazione degli insight e nell'uso dei dati per il controllo dei processi di business. Sul piano tecnologico è specializzato in Snowflake + dbt + Tableau. Sul piano settoriale ha esperienza in Public Utility, Clinical Trials, Publishing, CPG e Manufacturing. Lo si può contattare in qualsiasi momento: [email protected].

Ian Whitestone·Co-founder & CEO di SELECT

Ian è Co-founder e CEO di SELECT, una piattaforma SaaS per la gestione e l'ottimizzazione dei costi su Snowflake. Prima di fondare SELECT, Ian ha trascorso 6 anni alla guida di team full stack di data science e engineering presso Shopify e Capital One. In Shopify ha guidato il lavoro di ottimizzazione del data warehouse e di sviluppo dell'osservabilità sui costi.