Snowflake non si guasta. Diventa costoso. 

Questa osservazione ha un peso diverso a seconda del ruolo che ricoprite. Per un data engineer, la pipeline è verde e nessuno si lamenta. Per un CDO o un Head of Data Platform, significa che un warehouse ha silenziosamente raddoppiato il proprio consumo mensile di crediti senza alcun alert, senza alcun ticket di incidente e senza alcuna spiegazione visibile, finché il reparto finanza non ha inoltrato la fattura. Secondo la documentazione sui prezzi di Snowflake, i costi di calcolo dei virtual warehouse rappresentano in genere l'80% della fattura di un cliente Snowflake, e le organizzazioni enterprise possono spendere da 10.000 a oltre 50.000 dollari al mese. A questa scala, un utilizzo non monitorato non è un inconveniente operativo. È un rischio finanziario. 

Un monitoraggio efficace di Snowflake non consiste nel sapere che le query sono in esecuzione. Consiste nel capire come utilizzo, costi e prestazioni evolvono nel tempo, e nel rilevare le inefficienze che si accumulano silenziosamente prima che compaiano in un report sui costi. 

Le metriche chiave che ogni programma di monitoraggio di Snowflake deve tracciare 

Il monitoraggio di Snowflake copre tre dimensioni distinte, ciascuna con i propri segnali e le proprie modalità di guasto. 

• La prima è il consumo di crediti. I crediti Snowflake sono la valuta del calcolo. I warehouse consumano crediti al secondo mentre sono in esecuzione, con fatturazione minima di un minuto, e il consumo raddoppia a ogni aumento di dimensione. Le funzionalità serverless, tra cui Snowpipe, automatic clustering e search optimization, compaiono come voci separate. Secondo la documentazione di Snowflake sul controllo dei costi, sia i resource monitor sia gli account budget sono disponibili nativamente, ma misurano soglie, non trend. Vi dicono quando un limite viene superato, non perché il consumo stia aumentando da tre settimane. 

  
  

• La seconda sono le prestazioni delle query. Snowflake registra ogni query in ACCOUNT_USAGE.QUERY_HISTORY, inclusi tempo di esecuzione, byte scansionati e crediti cloud services consumati. Le metriche più importanti sono i byte scansionati per riga restituita, che segnalano le query che leggono molti più dati di quanti ne producano; il tempo totale trascorso tra le varie esecuzioni, che fa emergere le regressioni; e il tempo di attesa in coda delle query, che indica un sottodimensionamento del warehouse o problemi di concorrenza. 

  
  

• La terza è il comportamento dei warehouse. È la dimensione meno monitorata e quella con le maggiori conseguenze sui costi. Con quale frequenza un warehouse si riattiva e si sospende automaticamente? Il consumo di crediti dello stesso warehouse è stabile nelle settimane o tende ad aumentare? Questi schemi comportamentali rivelano inefficienze strutturali che le metriche puntuali non possono mostrare. 

I veri fattori di costo negli ambienti Snowflake 

La maggior parte delle discussioni sui costi di Snowflake si concentra sulla dimensione dei warehouse. I fattori di costo più significativi sono comportamentali e visibili solo attraverso un monitoraggio continuo. 

• Tempo di inattività dei warehouse: I warehouse vengono fatturati al secondo mentre sono in esecuzione, compreso il tempo di inattività tra una query e l'altra. Impostazioni di auto-suspend troppo lunghe, frequenti sui warehouse configurati per una latenza minima, accumulano costi considerevoli. Un warehouse che si sospende dopo dieci minuti ed elabora query di trenta secondi paga 9,5 minuti di calcolo inattivo a ogni ciclo. 

  
  

• Query fuori controllo: Per impostazione predefinita, Snowflake consente alle query di essere eseguite fino a 48 ore. Un join dimenticato, una scansione senza filtri o una CTE ricorsiva senza condizione di terminazione possono consumare centinaia di crediti prima che qualcuno se ne accorga. I parametri di timeout delle istruzioni esistono a livello di warehouse e di account, ma richiedono una configurazione deliberata. 

  
  

• Costi delle funzionalità serverless. Snowpipe, automatic clustering e search optimization vengono eseguiti su risorse di calcolo gestite da Snowflake con tariffe specifiche per ciascuna funzionalità, e compaiono come voci separate spesso trascurate nelle revisioni dei costi incentrate sui warehouse. 

  
  

• Warehouse sottodimensionati o sovradimensionati. Un warehouse troppo piccolo esegue le query lentamente e può generare code. Un warehouse troppo grande spreca risorse di calcolo per ogni query. Poiché a ogni aumento di dimensione capacità e costo dei warehouse raddoppiano, la scelta del dimensionamento ha un impatto significativo sul costo per query. 

Problemi di prestazioni comuni in Snowflake e le loro cause 

Il degrado delle prestazioni in Snowflake è di solito riconducibile a uno di quattro schemi, ciascuno con una firma di monitoraggio distinta. 

• Il primo sono le scansioni complete delle tabelle. Snowflake utilizza il pruning a livello di metadati per evitare di scansionare partizioni che non possono contenere i dati richiesti. Le query senza filtri adeguati, o eseguite su tabelle con un clustering poco allineato agli schemi di interrogazione, impongono scansioni complete delle tabelle. La metrica dei byte scansionati nella cronologia delle query lo segnala direttamente. 

• Il secondo è lo spill dei dati su disco. Quando una query richiede più memoria di quella che il warehouse può fornire, Snowflake riversa i dati intermedi sul disco locale e, se questo non basta, sullo storage remoto. Lo spill sullo storage remoto è particolarmente costoso sia in termini di tempo di esecuzione sia di crediti, ed è un candidato all'ottimizzazione della query o al ridimensionamento del warehouse. 

• Il terzo è l'accodamento nei warehouse. Quando arrivano più query di quante un warehouse possa elaborarne contemporaneamente, quelle in eccesso vengono messe in coda. Il tempo di attesa in coda gonfia il tempo totale trascorso senza che avvenga alcuna esecuzione. Un accodamento persistente indica un problema di concorrenza, di dimensionamento o di pianificazione dei carichi di lavoro, che richiede la suddivisione su più warehouse. 

  
  

• Il quarto è l'overhead di compilazione delle query. Le query complesse generate da strumenti di BI o da livelli ORM possono comportare costi cloud services considerevoli per la compilazione. Questo compare nella colonna dei crediti cloud services della cronologia delle query ed è una fonte comune di costi imprevisti negli ambienti con un uso intenso di BI. 

Rilevare le inefficienze di Snowflake prima che compaiano nei report sui costi 

Il divario tra gli strumenti di monitoraggio nativi di Snowflake e ciò di cui hanno bisogno i team dati in produzione è il divario tra monitoraggio basato su soglie e monitoraggio comportamentale. I resource monitor scattano quando viene raggiunto un limite di crediti. Il monitoraggio comportamentale fa emergere la traiettoria prima che venga raggiunto qualsiasi limite. 

Come afferma l'analisi sull'osservabilità di Snowflake di Manoj Patil: non si può ottimizzare ciò che non si vede, e l'osservabilità viene sempre prima. Un warehouse il cui consumo di crediti è aumentato del 15% al mese per quattro mesi rappresenta una situazione sostanzialmente diversa da un warehouse che ha avuto un picco isolato e si è poi ripreso. Il primo caso rappresenta una deriva strutturale. Il secondo è un'anomalia recuperabile. Entrambi appaiono identici su una dashboard basata su soglie, finché non arriva la fattura mensile. 

I segnali specifici che vale la pena monitorare in modo continuo sono: il consumo di crediti per warehouse a settimana, la varianza del tempo di esecuzione delle query, i trend di frequenza dello spill e di durata dell'accodamento, e il rapporto tra crediti cloud services e crediti dei warehouse per ciascun carico di lavoro. 

È qui che digna Data Anomalies si applica direttamente agli ambienti Snowflake. digna si connette a Snowflake tramite il suo connettore nativo e apprende automaticamente la baseline comportamentale di ogni metrica monitorata. Le deviazioni da queste baseline, che si tratti di un picco improvviso o di una deriva graduale su più settimane, vengono segnalate come anomalie prima che emergano nei report sui costi o come violazioni degli SLA. Per i team che hanno bisogno di analisi dei trend oltre all'anomaly detection, digna Data Analytics fornisce lo storico di osservabilità: valutazione delle serie temporali sulle metriche monitorate, identificazione degli schemi in rapida evoluzione e analisi statistica dei trend che rende visibile la differenza tra un'anomalia isolata e un cambiamento strutturale. La configurazione è documentata nella guida al connettore Snowflake di digna. 

Considerazioni finali: è il monitoraggio a mantenere Snowflake conveniente 

Le organizzazioni che gestiscono Snowflake in modo economicamente efficiente non sono quelle con i team di engineering più numerosi. Sono quelle che hanno costruito una visibilità continua sul comportamento dei propri ambienti nel tempo e che fanno emergere le inefficienze prima che si accumulino fino a diventare voci di spesa in un report finanziario. 

Gli strumenti nativi di Snowflake, ovvero resource monitor, account budget e viste della cronologia delle query, forniscono la materia prima per il monitoraggio. Non forniscono però l'intelligenza comportamentale necessaria per distinguere un problema strutturale da un evento transitorio, o per identificare quale carico di lavoro sia responsabile di un trend di costo in corso da sei settimane. 

È questa intelligenza comportamentale a distinguere un programma di monitoraggio di Snowflake da una semplice configurazione di alerting. Il primo vi dice che cosa sta cambiando e perché. La seconda vi dice quando un limite è stato superato. Su scala di produzione, è il primo ciò che il lavoro richiede. 

Scoprite quali carichi di lavoro Snowflake stanno andando alla deriva prima che lo faccia il vostro report sui costi. 

digna si connette al vostro ambiente Snowflake e apprende la baseline comportamentale di ogni warehouse e carico di lavoro monitorato. Derive nel consumo di crediti, varianza del tempo di esecuzione delle query e anomalie di utilizzo vengono segnalate automaticamente, senza configurazione manuale delle soglie e senza che i dati lascino il vostro ambiente. 

Prenotate una demo personalizzata  → Leggete la guida all'integrazione con Snowflake   

Domande frequenti

Quale percentuale della fattura di Snowflake deriva dal calcolo dei warehouse?

Secondo la documentazione sui prezzi di Snowflake, il calcolo dei virtual warehouse rappresenta in genere circa l'80% della fattura di un cliente Snowflake. Le organizzazioni enterprise possono spendere da 10.000 a oltre 50.000 dollari al mese: per questo un utilizzo non monitorato dei warehouse diventa un rischio finanziario anziché un inconveniente operativo.

Perché i resource monitor di Snowflake non bastano per il controllo dei costi?

I resource monitor e gli account budget misurano soglie, non trend. Scattano quando viene superato un limite di crediti, ma non possono spiegare perché il consumo stia aumentando da tre settimane. Su una dashboard basata su soglie, un warehouse che cresce del 15% al mese per quattro mesi appare identico a un picco isolato, finché non arriva la fattura.

Quali metriche delle query di Snowflake conviene monitorare in QUERY_HISTORY?

Partite da ACCOUNT_USAGE.QUERY_HISTORY, che registra tempo di esecuzione, byte scansionati e crediti cloud services per ogni query. Contano soprattutto tre metriche: i byte scansionati per riga restituita, il tempo totale trascorso tra le varie esecuzioni per far emergere le regressioni e il tempo di attesa in coda delle query, che indica un sottodimensionamento del warehouse o problemi di concorrenza.

In che modo un'impostazione di auto-suspend lunga aumenta i costi di Snowflake?

I warehouse vengono fatturati al secondo mentre sono in esecuzione, compreso il tempo di inattività tra una query e l'altra, quindi con una finestra di auto-suspend lunga si paga un calcolo che non produce nulla. Ad esempio, un warehouse che si sospende dopo dieci minuti ma elabora query di trenta secondi paga 9,5 minuti di calcolo inattivo a ogni ciclo.

Che cosa causa lo spill dei dati su disco in Snowflake?

Lo spill si verifica quando una query richiede più memoria di quella che il warehouse può fornire, per cui Snowflake scrive i dati intermedi sul disco locale e, se questo non basta, sullo storage remoto. Lo spill remoto è particolarmente costoso in termini di tempo di esecuzione e di crediti, ed è quindi un candidato all'ottimizzazione della query o al ridimensionamento del warehouse.