Imposta budget e avvisi per i costi del data warehouse cloud

Ogni team di analytics si è trovato in questa situazione: arriva la fattura di fine mese e un singolo SQL warehouse ha sforato il budget, forse a causa di una risorsa di calcolo rimasta attiva tutta la notte o di una ad hoc che si è scalata automaticamente per servire 80 utenti Tableau durante una revisione trimestrale. Il costo è reale, ma la frustrazione è ancora più profonda: nessuno lo sapeva finché non è stato troppo tardi.

La gestione proattiva dei costi ribalta questo modello. Invece di un'analisi forense delle fatture a posteriori, imposti dei guardrail prima ancora di spendere un solo dollaro: i budget sono legati a warehouse, team o carichi di lavoro BI. Avvisi che si attivano alle soglie scelte da te e dashboard che mostrano le tendenze di utilizzo in tempo reale, il tutto sulla Databricks Data & AI Platform. Se ti trovi a metà della migrazione da un sistema on-premises o da un altro cloud data warehouse, questo è il momento giusto per implementare tale governance.

Perché la gestione reattiva dei costi fallisce?

I carichi di lavoro di data warehousing presentano sfide di costo uniche. I SQL warehouse servono carichi di lavoro interattivi e guidati dall'uomo (dashboard BI, analisi ad hoc, analytics integrate) in cui la domanda è imprevedibile e soggetta a picchi. Una singola riunione plenaria aziendale che attiva 200 aggiornamenti simultanei delle dashboard può far impennare i costi in pochi minuti. La maggior parte delle organizzazioni inizia il proprio percorso di FinOps nello stesso modo: qualcuno scarica il CSV di utilizzo del mese precedente, apre una tabella pivot e inizia a farsi domande. Questo approccio fallisce per quattro motivi:

• Non puoi vedere chi sta spendendo. L'utilizzo viene aggregato a livello di piattaforma, non del team o della query che lo ha generato, quindi nessuno può essere ritenuto responsabile di una cifra.
• Nessuno è responsabile di un budget. Senza obiettivi di spesa legati a un warehouse o a un team, l'analista che esegue SELECT * su una tabella da 2 TB non percepisce mai il costo. Il team della piattaforma lo assorbe silenziosamente.
• Lo scopri troppo tardi. Quando i report Excel del mese precedente evidenziano la spesa eccessiva, sono già passati due cicli di fatturazione e la decisione che l'ha causata è ormai invisibile.
• La revisione manuale non è scalabile. Cinque warehouse possono superare una revisione mensile tramite tabella pivot. Tuttavia, una volta passati a dozzine, supportare centinaia di analisti su Tableau, Power BI e Looker diventa ingestibile.

La gestione proattiva dei costi — attribuzione, budget, avvisi, dashboard e ottimizzazione — risponde a tutte e cinque le sfide.

Inizia con il serverless: la prima decisione sui costi.

Prima di impostare i budget, scegli il tipo di warehouse corretto. I SQL warehouse serverless sono l'opzione consigliata da Databricks per la maggior parte dei carichi di lavoro. Si avviano in pochi secondi, si ridimensionano non appena terminano le query e consentono a Intelligent Workload Management di allocare le risorse di calcolo per te, così paghi solo per l'esecuzione effettiva delle query e non per il tempo di inattività.

Se stai migrando da un cloud data warehouse legacy, questo è un cambiamento importante. La maggior parte delle piattaforme legacy addebita i costi per risorse di calcolo sempre attive o richiede decisioni di scalabilità manuali. Il serverless elimina interamente questa categoria di errori di costo.

Lumen Technologies lo ha verificato in prima persona: la migrazione di due sistemi di telecomunicazione essenziali da un data warehouse on-premises a SQL Serverless ha ridotto i costi di calcolo del 30-40% e aumentato la velocità delle query del 90%. Ora il sistema si scala automaticamente per gestire circa 7 GB ogni 10 minuti, con il serverless che elimina la "tassa del sempre attivo" tipicamente associata a carichi di lavoro discontinui e in tempo reale.

I cinque pilastri della gestione proattiva dei costi

Il framework si compone di cinque pilastri. I primi quattro rendono visibile la spesa; il quinto è quello che la riduce concretamente:

• Attribuzione dei costi. Tagga tutto per sapere chi ha speso cosa e su quale warehouse.
• Budget. Definisci gli obiettivi di spesa mensili a livello di account, workspace o team.
• Avvisi. Ricevi una notifica nel momento in cui la spesa si avvicina o supera una soglia.
• Dashboard. Visualizza le tendenze dei warehouse e rendi il costo una metrica operativa di prim'ordine.
• Ottimizzazioni. Riduci innanzitutto il costo effettivo del lavoro.

Pilastro 1: Attribuzione dei costi a due livelli

Non puoi gestire ciò che non puoi attribuire, e con i warehouse questo significa due livelli: il warehouse stesso e la singola query. Uno ti dice quale warehouse ha speso il denaro; l'altro ti dice chi al suo interno lo ha fatto.

Livello 1: Tagging del warehouse

I SQL warehouse supportano tag personalizzati come coppie key:value che si propagano a system.billing.usage, collegando ogni DBU consumata a un team, progetto o centro di costo. Il tagging funziona allo stesso modo per ogni tipo di warehouse: Classic, Pro e Serverless sono tutti taggati a livello di warehouse, quindi impari un unico modello e lo applici ovunque.

Imposta i tag nell'interfaccia utente (UI) in SQL Warehouses > il tuo warehouse > Modifica > Tag, oppure crea il warehouse tramite l'API REST:

Tagging tramite l'API REST

Applica almeno tre dimensioni: team (chi lo possiede), centro di costo (chi paga) e caso d'uso (servizio BI, ad hoc, aggiornamento pianificato).

Oggi non esiste una policy nativa che imponga i tag dei warehouse, quindi chiunque può crearne uno senza tag. Integra invece l'applicazione dei tag nel tuo processo di provisioning: crea i warehouse con Terraform, Declarative Automation Bundles o l'API REST con i tag nella definizione, e considera l'interfaccia utente (UI) come l'eccezione. La query sul divario di attribuzione più avanti in questo post rileverà tutto ciò che sfugge.

Livello 2: Tagging della query

I tag del warehouse ti dicono che un warehouse è costato 4.000 $ il mese scorso. Non ti dicono però che il 60% di quel costo proviene da una singola dashboard Power BI che si aggiorna ogni 15 minuti. Questo divario è importante perché i warehouse sono condivisi: un singolo warehouse BI serve decine di dashboard, diversi modelli dbt e un flusso di query ad hoc.

I tag di query (Public Preview) colmano questo divario associando il contesto aziendale a singole istruzioni SQL:

I tag vengono inseriti nella colonna query_tags di system.query.history (Public Preview), insieme a executed_by e statement_id, consentendoti di raggruppare la spesa per dashboard, modello o centro di costo anziché per warehouse. Alcuni strumenti li impostano automaticamente: a partire da dbt-databricks 1.11.0, le query dei modelli vengono taggate automaticamente con il nome del modello dbt, e Power BI passa gli identificatori del workspace e del dataset tramite il driver ADBC.

Due avvertenze: i tag di query si applicano solo alle query dei SQL warehouse e, poiché risiedono nella cronologia delle query anziché nei dati di fatturazione, dovrai unire i due elementi autonomamente per ottenere il costo per query.

Prima di scrivere qualsiasi codice SQL, controlla la pagina Costi in Governance Hub (Beta): una vista a livello di account delle spese, dei fattori di costo, dei budget e della copertura dei tag, nonché il modo più rapido per vedere quanta parte del tuo utilizzo sia effettivamente attribuibile. Un amministratore dell'account può abilitarla dalla pagina Anteprime della console dell'account.

Pilastro 2: Impostazione dei budget nella console dell'account

Creazione di un budget

Nella console dell'account, vai su Utilizzo > Budget, fai clic su Aggiungi budget e configura:

• Nome: Descrittivo (ad es. "SQL warehouse di analytics, mensile")
• Importo: Obiettivo mensile in USD
• Ambito: Filtra per workspace e/o tag (ad es. Team:Analytics)
• Notifiche e-mail: Destinatari che riceveranno una notifica quando la spesa raggiunge l'importo del budget

Esempi di configurazione del budget

Il modello chiave è basato su budget stratificati: budget a livello di team per la responsabilizzazione, più un budget a livello di account come rete di sicurezza per rilevare eventuali anomalie sfuggite ai controlli. 

Tieni presente che i budget sono uno strumento di monitoraggio, non un limite rigido. Ne' bloccano l'utilizzo né impediscono gli addebiti, quindi la fattura può comunque superare l'importo stabilito. L'obiettivo è la consapevolezza e la rapidità di risposta, non interruzioni che potrebbero compromettere una dashboard di produzione durante l'aggiornamento.

GetYourGuide ha testato direttamente questo approccio: il consolidamento di tutti i carichi di lavoro Looker su SQL Serverless ha ridotto i costi di BI serving di circa il 20% e velocizzato le query del 35%, anche se il team si aspettava che i cluster Classic fossero più economici. La scelta della tipologia di warehouse è una decisione di budget che vale la pena rivalutare periodicamente, non una scelta da fare una volta per tutte.

Come leggere il burn rate

Fai clic su qualsiasi budget per visualizzare la spesa corrente rispetto all'obiettivo, il budget rimanente e una visualizzazione giornaliera del burn rate. Per il data warehousing, questo grafico è particolarmente rivelatore:

• Un consumo giornaliero lineare indica costi di BI serving stabili.
• Un andamento a dente di sega con picchi il lunedì e il venerdì indica che l'esplorazione ad hoc si concentra nei giorni lavorativi.
• Un improvviso aumento a metà mese significa che è stata distribuita una nuova dashboard senza una revisione dei costi.
• Una crescita graduale verso l'alto significa che l'adozione organica sta superando le tue previsioni di budget.

Pilastro 3: Avvisi, il sistema nervoso della governance dei costi

I budget ti dicono a che punto sei. Gli avvisi ti dicono quando agire.

Avvisi e-mail sul budget

Quando crei un budget, aggiungi i destinatari e-mail che riceveranno una notifica quando la spesa supera l'importo stabilito. Non è richiesto alcun codice.

Per gli avvisi basati su soglie, crea degli avvisi di Databricks SQL che interrogano direttamente `system.billing.usage`. Ecco i modelli più importanti:

Avviso quando la spesa giornaliera del SQL warehouse supera una soglia

Avviso di andamento: la spesa prevista per la fine del mese supererà il budget

Questo è il modello da cui i team traggono il massimo valore. Invece di inviare un avviso dopo il superamento del limite, proietta la spesa di fine mese e si attiva prima che tale proiezione superi il budget, quando hai ancora tempo per agire:

Pianifica questo controllo ogni quattro ore e invialo a Slack o via e-mail. Offre ai team diversi giorni per reagire (ridimensionare un warehouse, ottimizzare una query costosa, posticipare un batch) prima che il budget venga superato.

Rilevare i costi nascosti derivanti dagli aggiornamenti delle viste materializzate

I costi di aggiornamento delle viste materializzate sono quelli che i team trascurano più spesso, poiché vengono fatturati come utilizzo di pipeline serverless anziché come utilizzo del warehouse. Una vista impostata per aggiornarsi ogni 15 minuti a fronte di una sorgente che si aggiorna due volte al giorno comporta una spesa inutile per la differenza. Allinea la pianificazione dell'aggiornamento alla frequenza con cui cambiano effettivamente i dati sottostanti, quindi monitora direttamente la spesa della pipeline:

Pilastro 4: Dashboard e monitoraggio continuo

Gli avvisi sono trigger puntuali. Le dashboard forniscono un contesto continuo. Databricks offre dashboard di utilizzo predefinite che gli amministratori dell'account possono importare in qualsiasi area di lavoro abilitata per Unity Catalog. Queste coprono i trend di spesa, l'analisi top-N, il filtraggio dei tag e i dettagli per singolo warehouse. Per il monitoraggio personalizzato, due query sono particolarmente utili:

Costo del SQL warehouse per team

Utilizzo SQL non attribuito (gap di attribuzione)

L'utilizzo SQL senza tag rappresenta il tuo gap di attribuzione, ovvero una spesa del warehouse che non può essere ricondotta a nessun team. Riduci questa cifra a zero.

Raiffeisen Bank International ha creato la propria piattaforma di monitoraggio e previsione dei costi direttamente sulle tabelle di sistema di Databricks, con visibilità per singolo warehouse, utente e workload. Il vantaggio è stato tanto culturale quanto tecnico: workload da 3 a 4 volte più veloci e, cosa ancora più importante, quando i team possono vedere la propria spesa e sono tenuti a giustificarla, i comportamenti cambiano senza bisogno di imposizioni.

Pilastro 5: Ottimizzazione, il pilastro che cambia concretamente la fattura

I primi quattro pilastri servono a visualizzare la spesa. Questo serve a ridurla, ed è quello che la maggior parte dei team tralascia. Inizia con le due modifiche che migliorano contemporaneamente i costi e le prestazioni.

Attiva l'ottimizzazione predittiva per le tabelle gestite da Unity Catalog. Databricks esegue OPTIMIZE, VACUUM e ANALYZE al posto tuo in base a come ogni tabella viene effettivamente interrogata e, con CLUSTER BY AUTO, adatta le chiavi di clustering al variare dei pattern di query. Meno dati scansionati significano query più veloci e meno DBUs, senza alcuna pianificazione di manutenzione da gestire. È attiva per impostazione predefinita per gli account creati a partire dall'11 novembre 2024 e verrà estesa agli account più datati entro il 2026.

Scegli come opzione predefinita i warehouse serverless per sfruttare i vantaggi economici legati all'avvio e al tempo di inattività descritti in precedenza: per la maggior parte dei team, questo rappresenta la fetta più grande dei risparmi, senza alcuno sforzo continuo.

A partire da qui, vale la pena ottimizzare alcune impostazioni:

• Riduci il tempo di auto-stop. Le versioni Pro e Classic prevedono per impostazione predefinita 45 minuti di inattività prima dell'arresto; serverless prevede 10 minuti, ma puoi scendere a 5 nell'UI o a 1 tramite API. Ogni minuto di inattività su un warehouse BI dopo la chiusura dell'ultima dashboard è uno spreco.
• Imposta un timeout per le istruzioni (Beta — abilita l'anteprima, quindi impostalo per singolo warehouse tramite API). Una query fuori controllo non dovrebbe consumare un intero weekend di calcolo; mantieni tempi brevi sui warehouse BI e più lunghi su quelli ETL.
• Definisci un warehouse predefinito (Impostazioni amministratore > Calcolo) in modo che una rapida occhiata a dieci righe non attivi un cluster di dimensioni adatte all'ETL, e inizia con dimensioni Small o Medium anziché sovradimensionare le risorse.
• Scegli intenzionalmente se scalare verticalmente o orizzontalmente. Lo scaling verticale (dimensioni maggiori, ora fino a 5X-Large in Public Preview) velocizza una singola query pesante; lo scaling orizzontale (un numero massimo di cluster più elevato) serve più utenti simultanei. Scegliere l'opzione sbagliata è un errore comune e costoso.

Anche il livello dati è importante: OPTIMIZE, VACUUM e liquid clustering riducono singolarmente le risorse di calcolo necessarie per una query, con un effetto cumulativo su migliaia di query BI al giorno.

Alla base di tutto, la maggior parte dei problemi di costo è legata alle query. Una chiave di join mancante o una SELECT * su una tabella di grandi dimensioni hanno lo stesso costo indipendentemente da come è ottimizzato il warehouse; ed è proprio l'attribuzione del Pilastro 1 a indicarti quali query e dashboard correggere.

Punti chiave

1. Integra serverless e attribuzione nella piattaforma fin dal primo giorno. Scegli come opzione predefinita i warehouse SQL Serverless per un avvio istantaneo, la scalabilità automatica e l'assenza di costi per i tempi di inattività, e imponi l'uso di tag personalizzati fin dall'inizio, perché l'utilizzo non attribuito è invisibile, e l'utilizzo invisibile cresce sempre.

2. Definisci budget e avvisi in modo proattivo, a più livelli. Associa i budget per team per responsabilizzare gli utenti a un budget a livello di account per rilevare le anomalie, e imposta avvisi sul ritmo di spesa, non solo sulle soglie, in modo da ricevere notifiche su un superamento dei costi in tempo utile per agire, anziché a violazione già avvenuta.

3. Rendi la spesa visibile e trasformala in un fattore culturale.  I risparmi più duraturi derivano dalla trasparenza, non dalle restrizioni, quindi inserisci le dashboard dei costi direttamente dove lavorano i team. Come ha riscontrato RBI, quando i team possono vedere la propria spesa, i comportamenti cambiano senza bisogno di imposizioni.

Inizia subito

Questo è il percorso più rapido per iniziare e tenere sotto controllo i costi prima che lievitino:

• Crea il tuo primo budget nella console dell'account. 
• Attribuisci l'utilizzo aggiungendo tag al tuo SQL warehouse e alle query
• Monitora i costi con le tabelle di sistema, interroga system.billing.usage per ottenere informazioni specifiche sul warehouse
• Dimensionamento del SQL warehouse e comportamento di scaling, comprendi i vantaggi economici di IWM e serverless
• Best practice per l'ottimizzazione dei costi, dimensionamento del warehouse, Photon e ottimizzazione di Delta Lake
• Dal caos al controllo: un percorso di maturità dei costi con Databricks, il framework "crawl-walk-run" per la maturità FinOps

Vuoi assumere il controllo dei costi del tuo data warehouse cloud? Crea un account di prova gratuito di Databricks, crea il tuo primo warehouse SQL Serverless e configura un budget con avvisi via e-mail nella console dell'account. Richiede solo cinque minuti ed è gratuito.

Per approfondire l'osservabilità dei costi, esplora la documentazione sulle tabelle di sistema per la fatturazione e importa la dashboard di utilizzo predefinita per iniziare a monitorare la spesa fin dal primo giorno.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale