TL;DR
L'ottimizzazione dei costi di Databricks si riduce a cinque abitudini: sapere da dove arrivano davvero i costi (la tariffa DBU più una fattura separata per l'infrastruttura cloud), eliminare il compute inattivo con auto-termination e timeout, fare right-sizing del compute adottando il serverless come default e riservando il compute classico ai workloads più costosi, ripensare i workflow in funzione della frequenza di esecuzione e dell'elaborazione incrementale, e blindare le impostazioni di storage e governance perché i risultati non si erodano nel tempo. Numeri reali dal webinar: un cluster GPU non monitorato ha aggiunto 4.000 dollari a una fattura mensile di 20.000 prima che qualcuno se ne accorgesse, e ridurre la frequenza di esecuzione di un job da 472 volte al giorno a una volta all'ora ha fatto risparmiare il 95% del suo costo, circa 19.000 dollari l'anno.
Perché i costi di Databricks sono difficili da controllare
Databricks offre ai team dati una libertà fuori dal comune. È possibile eseguire la stessa pipeline come cluster interattivo, job pianificato o job serverless, su compute classico o serverless, passando per una dozzina di tipi di nodo e configurazioni di scaling diverse. Proprio questa flessibilità rende difficile il controllo dei costi. Più opzioni significano più modi di configurare male qualcosa, e le fatture di Databricks non rendono sempre evidente quando è successo.
Questo è stato il punto di partenza di un recente webinar condotto da Ian Whitestone, co-fondatore di SELECT, e Olivier Soucy, consulente Databricks che ha passato anni a costruire piattaforme dati da zero, compreso un periodo come head of data presso un exchange di criptovalute, dove ha realizzato un ambiente Databricks partendo da zero. Oggi Soucy gestisce una propria attività di consulenza focalizzata su costi e performance di Databricks, e durante la sessione ha illustrato cinque strategie concrete per tenere sotto controllo la spesa Databricks, ciascuna supportata da numeri reali provenienti da progetti con i clienti.
Ecco un riepilogo di quanto ha trattato.
Prima di tutto, capire dove finiscono davvero i soldi
Prima di ottimizzare qualsiasi cosa, bisogna sapere per cosa si sta pagando, e Databricks lo rende più difficile del dovuto. I costi arrivano da due fonti separate: la tariffa per Databricks Unit (DBU) addebitata da Databricks stessa e il compute cloud sottostante addebitato da AWS, Azure o GCP per le istanze di cui Databricks effettua il provisioning.
La sola tariffa DBU può trarre in inganno. Soucy ha mostrato una stessa pipeline ETL con tre costi diversi a seconda della modalità di esecuzione: come cluster interattivo costa 55 centesimi per DBU; come job su compute classico, 30 centesimi per DBU; come job su serverless, 45 centesimi per DBU. Guardando solo il prezzo per DBU, il serverless sembra l'opzione costosa. Ma il compute classico comporta anche una fattura separata per l'infrastruttura cloud che il serverless non ha, quindi il quadro completo appare spesso molto diverso una volta sommati entrambi i costi.
La maggior parte dei team non li somma mai. Soucy lo ha detto senza giri di parole quando Whitestone gli ha chiesto se i clienti tracciano insieme il costo DBU e quello dell'infrastruttura cloud a livello di singolo job: in genere no, perché i due versanti appartengono a team diversi. Un team Databricks monitora system tables e workflow; un team cloud guarda la fattura AWS o Azure e tratta Databricks come un'unica voce di spesa. Unire le due fonti di dati con i tag giusti richiede uno sforzo tale che la maggior parte delle organizzazioni ci rinuncia, anche sapendo che è importante.
Databricks espone comunque system tables con dati di utilizzo e pricing, sufficienti per costruire un modello di costo ragionevolmente accurato della spesa DBU. Per il compute classico (non serverless), la regola empirica di Soucy è assumere che il costo dell'infrastruttura cloud sottostante sia più o meno pari al costo DBU: una fattura DBU da 50.000 dollari si avvicina quindi spesso ai 100.000 dollari una volta aggiunto il compute cloud. È una stima grossolana, e per i workloads GPU può variare parecchio, ma è un punto di partenza ragionevole se non si dispone ancora di un modello migliore. Per un'analisi più approfondita di come funziona davvero il pricing di Databricks, SELECT ha esaminato in dettaglio le tre leve che contano di più.
Eliminare gli sprechi prima di ottimizzare qualsiasi altra cosa
Il compute inattivo è, nelle parole di Soucy, l'errore più costoso in assoluto che un team possa commettere, perché si pagano risorse che non producono alcun valore mentre girano. Ha condiviso due esempi dal suo lavoro con i clienti. In un caso, un nuovo stagista ha avviato un cluster GPU senza auto-termination e senza alcun guardrail. È rimasto in esecuzione per settimane, aggiungendo circa 4.000 dollari a una fattura mensile di 20.000, prima che qualcuno se ne accorgesse. In un altro, un job che in QA girava tranquillamente in circa 20 minuti ha incontrato dati diversi in produzione ed è rimasto in esecuzione per 47 ore prima che qualcuno lo intercettasse.
Le soluzioni sono semplici e vale la pena adottarle a prescindere da tutto il resto di questa lista:
- Impostare l'auto-termination su ogni cluster e warehouse. Soucy ha suggerito come default ragionevoli circa 30 minuti di inattività per i cluster e 10 minuti per i warehouse, anche se il valore esatto conta meno del fatto stesso di averne uno.
- Attivare l'auto-scaling, così il compute cresce e si riduce in base alla domanda effettiva invece di restare completamente provisionato 24 ore su 24.
- Impostare timeout per job e query. Il timeout predefinito di Databricks per le istruzioni SQL è di due giorni, un valore che entrambi i relatori hanno giudicato decisamente eccessivo. Whitestone è stato diretto: se una query è in esecuzione da più di un giorno, probabilmente non dovrebbe essere ancora in esecuzione, e vale la pena abbassare quel default a livello di account.
- Usare le cluster policy per renderlo obbligatorio. Invece di affidarsi alla memoria dei singoli per l'auto-termination, le cluster policy possono imporla a livello di account.
Fare right-sizing del compute in base al workload
Una volta messi sotto controllo gli sprechi, l'errore più comune successivo è l'over-provisioning: assegnare più compute di quanto un workload richieda. La raccomandazione di default di Soucy, che lui stesso riconosce essere un po' controversa, è usare il serverless come impostazione predefinita, a meno che non ci sia un motivo specifico per non farlo.
L'ha dimostrato con l'esempio della pipeline ETL oraria di un cliente. Su compute classico, il job consumava circa 44 DBU al giorno a 30 centesimi per DBU (circa 13 dollari al giorno di costo DBU), più altri 10 dollari al giorno di infrastruttura cloud, per un totale vicino ai 23 dollari al giorno. Spostato su serverless, lo stesso job consumava 38 DBU a una tariffa per DBU più alta, ma il costo totale è risultato simile, in questo caso leggermente inferiore, soprattutto perché il serverless elimina i due-quattro minuti di avvio del cluster che il compute classico paga a ogni esecuzione. L'eliminazione del tempo di avvio ha anche ridotto il runtime totale del job da 20 a 12 minuti.
Il consiglio pratico di Soucy: chi è alle prime armi con Databricks o non ha ancora ottimizzato i propri workflow dovrebbe adottare il serverless ovunque come default, per poi identificare i cinque-dieci workloads che generano la maggior parte della fattura e valutare di riportare solo quelli sul compute classico, dove ci sono più leve su cui agire in termini di costo e performance. Per tutto il resto, di solito, non vale la pena dedicare tempo al tuning. Il fattore discriminante tende a essere la durata del workload: i job che girano per ore di fila hanno più probabilità di trarre vantaggio dal compute classico, dove si possono regolare direttamente tipo di nodo, autoscaling e numero di worker.
Per il compute classico, Soucy consiglia di partire dalla dimensione di istanza più piccola disponibile e scalare solo quando si incontrano colli di bottiglia reali, usando le metriche della Spark UI come l'utilizzo di CPU e nodi per guidare la decisione. Partire troppo in grande tende a produrre quella che ha definito una "fattura silenziosa": nessun errore, nessun job fallito, solo un costo costantemente più alto del necessario. Vale anche la pena abbinare il tipo di compute al workload: il lavoro esclusivamente SQL va sui SQL warehouse, la logica generica dei job sul job compute, e i cluster interattivi o all-purpose vanno riservati al lavoro davvero interattivo. Whitestone ha osservato che questo è uno degli errori più comuni che SELECT riscontra: eseguire un job pianificato su un cluster interattivo invece che su un job cluster dedicato può quasi raddoppiare il costo Databricks di quel job senza alcun beneficio.
Ripensare il workflow stesso
Oltre al dimensionamento del compute, alcune modifiche al modo in cui le pipeline vengono costruite si sono rivelate tra le ottimizzazioni a più alto impatto disponibili.
La frequenza di esecuzione conta più di quanto la maggior parte dei team pensi. Prendendo come riferimento un aggiornamento giornaliero, passare a esecuzioni orarie fa aumentare il costo di circa cinque volte, e gli aggiornamenti quasi in tempo reale costano circa 60 volte tanto. Il consiglio di Soucy è mettere in discussione i requisiti di tempo reale o quasi tempo reale avanzati dagli stakeholder di business, dato che la maggior parte delle richieste di dashboard "in tempo reale" significa in realtà che il report deve riflettere un momento specifico, non un flusso continuo.
Usare le viste invece di duplicare le tabelle. Per semplici filtri o selezioni di colonne, creare una vista invece di una nuova tabella fisica evita di copiare i dati e il costo continuativo di mantenere quella copia, senza veri svantaggi per chi la interroga.
Elaborare in modo incrementale invece di rielaborare tutto. L'Auto Loader di Databricks è in grado di identificare automaticamente i file nuovi o modificati sullo storage cloud e, combinato con lo structured streaming, consente a una pipeline di elaborare solo ciò che è cambiato invece dell'intero dataset a ogni esecuzione. Soucy l'ha definita una soluzione più complessa da configurare, ma essenziale per qualsiasi workload ad alto volume.
Profilare e riscrivere le query costose. La vista del query profile di Databricks mostra come Spark ha effettivamente eseguito una trasformazione, inclusi shuffle e spill che è facile lasciarsi sfuggire. Soucy ha osservato che fornire quelle informazioni di profilazione, insieme al codice della trasformazione sottostante, a un assistente di coding basato sull'AI ha prodotto riscritture reali e utilizzabili nel suo stesso lavoro, trasformando un'attività che un tempo richiedeva una profonda competenza Spark in qualcosa di molto più accessibile.
Non trascurare lo storage e far durare i risultati
Sul fronte storage, il consiglio di Soucy è evitare il tuning manuale di partizionamento e Z-ordering e affidarsi invece alle managed table di Unity Catalog, che supportano la predictive optimization. La predictive optimization esegue automaticamente e in modo pianificato le operazioni di vacuum, optimize e analyze, ripulendo i file obsoleti, compattando i file piccoli in file più grandi e aggiornando i metadati, così le query possono saltare i file che non hanno bisogno di leggere. Ha un costo di esecuzione, ma l'effetto netto è di solito una fattura più bassa rispetto a quella che produrrebbe la manutenzione manuale. Il liquid clustering, che ha in gran parte sostituito lo Z-ordering manuale, offre un vantaggio simile: non richiede di riscrivere i dati esistenti quando le colonne di clustering devono cambiare.
Niente di tutto questo regge nel tempo senza governance. La raccomandazione di Soucy è gestire tutto come codice, con strumenti come Terraform o i Databricks Asset Bundles, distribuiti tramite CI/CD, in modo che le configurazioni restino coerenti tra gli ambienti e non cambino silenziosamente nel tempo. Le cluster policy sono la leva principale: impostare default sensati per la maggior parte degli utenti, imporre auto-termination e limiti sui tipi di nodo, e lasciare ai power user che hanno davvero bisogno di più flessibilità la possibilità di richiederla. Anche i cluster pool possono aiutare, mantenendo un insieme di istanze "calde" lato cloud provider, così i job non devono attendere l'avvio del cluster; quella capacità inattiva, però, si continua a pagare al cloud provider, anche se Databricks non la addebita.
Soucy ha segnalato anche una categoria di costi facile da trascurare: le funzionalità più recenti di Databricks come app, endpoint di model serving, vector search e quality monitor. Ha raccontato di aver lui stesso configurato male un quality monitor su una tabella di grandi dimensioni, aumentando del 50% il costo giornaliero di quella tabella prima di accorgersene. Whitestone ha aggiunto che le funzionalità legate all'AI diventeranno probabilmente una voce di spesa in crescita sulle fatture Databricks in generale, citando la recente decisione di Databricks di iniziare a far pagare strumenti prima gratuiti come Genie. La conclusione condivisa da entrambi: impostare gli avvisi di costo prima di attivare qualcosa di nuovo, non dopo.
Il filo conduttore
In tutte e cinque le strategie emerge lo stesso schema: sul piano dei costi, Databricks raramente fa rumore quando qualcosa va storto. I cluster inattivi girano in silenzio, i job pianificati troppo spesso girano in silenzio, il compute sovradimensionato gira in silenzio, e le nuove funzionalità vengono attivate senza che nessuno verifichi quanto costeranno finché non arriva la fattura. Nessuna delle soluzioni descritte qui è esotica: auto-termination, timeout sensati, il giusto tipo di compute per ogni workload e la configurazione gestita come codice coprono la maggior parte della spesa evitabile per la maggior parte dei team.
Per i team che preferiscono gestire tutto questo in automatico invece che manualmente, SELECT per Databricks fa emergere direttamente questo tipo di spreco, segnalando auto-termination mancanti, job pianificati troppo di frequente (in un esempio reale condiviso durante la sessione, passare un job da 472 esecuzioni al giorno a una all'ora ha fatto risparmiare il 95% del suo costo, circa 19.000 dollari l'anno) e i warehouse o job responsabili di una quota sproporzionata della spesa, fino alla singola query. È possibile vedere come funziona su select.dev.
FAQ
Qual è il principale fattore di costi Databricks inutili? Il compute inattivo. Cluster e warehouse lasciati in esecuzione senza auto-termination, o job che restano bloccati senza un timeout, generano addebiti senza restituire alcun valore. Risolvere questo problema prima di tutto il resto tende ad avere il ritorno più rapido.
Meglio il serverless o il compute classico come default su Databricks? Il serverless è un default ragionevole per la maggior parte dei workloads, perché elimina il tempo di avvio del cluster e porta la maggior parte dei team nella fascia di costo corretta senza tuning manuale. L'eccezione sono i cinque-dieci workloads più costosi in termini di spesa, che di solito beneficiano del maggiore controllo che il compute classico offre su tipo di nodo, autoscaling e numero di worker.
Qual è la differenza tra costo DBU e costo dell'infrastruttura cloud? La tariffa DBU (Databricks Unit) è ciò che Databricks stessa addebita per il compute, e varia in base al tipo di compute. Il compute classico comporta anche una fattura separata per l'infrastruttura cloud da parte di AWS, Azure o GCP per le istanze sottostanti, che il compute serverless non ha. Come regola empirica, per il compute classico si può assumere che il costo dell'infrastruttura cloud sia quasi pari al costo DBU.
Quanto fa risparmiare davvero l'auto-termination? Varia in base al workload, ma il rischio di ignorarla può essere notevole. In un esempio reale, un cluster GPU mal configurato senza auto-termination ha aggiunto circa 4.000 dollari alla fattura di un singolo mese prima che qualcuno se ne accorgesse.
In che modo la frequenza di esecuzione dei job incide sui costi di Databricks? In modo significativo. Prendendo come riferimento un aggiornamento giornaliero, eseguire lo stesso job ogni ora costa circa cinque volte tanto, e gli aggiornamenti quasi in tempo reale costano circa 60 volte tanto. Mettere in discussione se un workload abbia davvero bisogno di girare così spesso è spesso la singola leva di risparmio più efficace a disposizione.
Databricks fa pagare le funzionalità AI come Genie? Databricks ha iniziato a far pagare strumenti che prima erano gratuiti, incluso Genie, e si prevede che le funzionalità legate all'AI diventeranno una voce di spesa in crescita sulle fatture Databricks. Impostare avvisi di costo prima di abilitare nuove funzionalità è la miglior difesa contro le sorprese.