Può ridurre i costi del Databricks Serverless SQL Warehouse abbinando ogni problema del workload al controllo giusto. L'auto-stop riduce il tempo di attività inutilizzato, la dimensione del warehouse incide sulle prestazioni delle singole query e max clusters determina quanta concorrenza il warehouse può assorbire.
La difficoltà è che questi segnali spesso si mescolano. Un warehouse che resta attivo tra job brevi non ha bisogno di più potenza di calcolo. I workloads in attesa di capacità potrebbero richiedere più cluster, non un warehouse più grande. Power BI DirectQuery, inoltre, può continuare a generare attività SQL su Databricks anche quando il codice SQL è già ben ottimizzato.
Questo articolo Le mostra come distinguere questi casi, confrontare Serverless con Pro e Classic in base al costo totale anziché al solo prezzo per DBU e scegliere l'impostazione che corrisponde al comportamento effettivamente osservato. Queste decisioni a livello di warehouse si inseriscono nel framework completo di ottimizzazione dei costi Databricks, in cui dimensionamento, utilizzo, attribuzione e automazione lavorano insieme.
In sintesi
- L'auto-stop riduce le finestre di inattività tra i picchi di lavoro SQL.
- La dimensione del warehouse controlla il compute disponibile per le singole query.
- Max clusters controlla quanta domanda concorrente il warehouse può servire.
- Serverless, Pro e Classic vanno confrontati sul costo totale del workload, non sul solo prezzo per DBU.
- La modalità di connessione di Power BI può cambiare sensibilmente l'attività del SQL Warehouse quando
DirectQueryviene usato per una freschezza dei dati di cui il business non ha bisogno.
Perché avvii e tempi di inattività determinano i costi del SQL Warehouse di Databricks
La Sua fattura per il SQL Warehouse può crescere più rapidamente di quanto suggerisca il tempo di esecuzione delle query, perché anche i job brevi generano avvii e finestre di attività. Gli alert pianificati rendono il problema facile da trascurare: diverse query da meno di un minuto su pianificazioni separate possono mantenere attivo un Databricks Serverless SQL Warehouse molto più a lungo dell'esecuzione effettiva del codice SQL. La configurazione può aggravare il divario. Un deployment di bundle documentato ometteva auto_stop_mins e si è ritrovato con un valore di 120 minuti, nonostante l'attuale documentazione dei Databricks Declarative Automation Bundles indichi un default Serverless di 10 minuti.
A nostro avviso, un errore di configurazione nascosto può fare più danni di una singola query lenta, perché si ripete a ogni esecuzione. Quanta parte della Sua fattura SQL Warehouse deriva da query costose, e quanta da impostazioni che nessuno ha più rivisto? Lo stesso schema emerge nelle cinque abitudini che incidono su una fattura Databricks e nel framework completo di ottimizzazione dei costi.
Tipi di SQL warehouse in Databricks: Serverless vs. Pro vs. Classic
Tra i principali tipi di SQL warehouse, Serverless ha la tariffa Databricks Unit (DBU) visibile più alta perché il suo prezzo include l'infrastruttura sottostante. Un Pro SQL warehouse ha una tariffa DBU più bassa, e Classic la più bassa in assoluto, ma entrambi fatturano separatamente l'infrastruttura cloud. Con il compute serverless, Databricks gestisce l'infrastruttura sottostante invece di esporre una voce di costo infrastrutturale separata da amministrare.
Ad esempio, le tariffe di listino AWS Premium pubblicate per US East indicano, nel 2026, circa $0,70 per DBU per Serverless, $0,55 per un Pro SQL warehouse e $0,22 per Classic. Le tariffe effettive possono variare in base a cloud, regione, edizione e contratto. Si tratta di un singolo esempio di pricing regionale, ma mostra perché la tariffa DBU da sola non dice quale opzione costi meno nel complesso.
| Tipo | Tariffa DBU relativa | Fatturazione infrastruttura | Avvio a freddo | Caso d'uso ideale |
|---|---|---|---|---|
| Serverless | La più alta | Inclusa | Tipicamente secondi | Workloads di BI interattiva e DirectQuery con domanda a picchi |
| Pro | Intermedia | Fatturata separatamente | Tipicamente minuti | Workloads di BI prevedibili che richiedono le funzionalità Pro |
| Classic | La più bassa | Fatturata separatamente | Tipicamente minuti | Workloads pianificati e prevedibili |
I SQL warehouse Serverless sono più adatti a una domanda a picchi perché possono avviarsi in pochi secondi e rispondere rapidamente alle variazioni della domanda. Databricks SQL Serverless utilizza inoltre l'Intelligent Workload Management (IWM) per prevedere le esigenze di risorse delle query e gestire la capacità al variare della domanda. Questo riduce la necessità di mantenere il compute attivo solo per evitare lunghi ritardi di avvio.
I Pro SQL warehouse e i Classic SQL warehouse sono più indicati quando la domanda è prevedibile. Databricks consiglia questi SQL warehouse per job pianificati Import o Extract, dove la domanda è più facile da pianificare e l'avvio rapido conta meno. Un Pro SQL warehouse aggiunge funzionalità rispetto a Classic SQL, che resta l'opzione a DBU più basso per i casi d'uso più semplici.
Il confronto utile è il costo totale di esecuzione del workload, inclusi infrastruttura, comportamento all'avvio e tempo per cui il warehouse deve restare attivo. Guardare solo la tariffa DBU riproduce lo stesso errore della "mezza fattura" e può far sembrare Serverless più costoso di quanto sia davvero.
Se desidera confrontare questi costi a livello di warehouse, SELECT for Databricks La aiuta a capire da dove provengono spesa, dimensionamento e utilizzo del SQL Warehouse prima di modificare la configurazione.
Auto-stop del SQL warehouse: i minimi di UI e API sono diversi
I SQL warehouse Serverless offrono più margine per ridurre l'auto-stop rispetto ai SQL warehouse Pro o Classic. Nella UI di Databricks il minimo per Serverless è di cinque minuti, mentre l'API e i Declarative Automation Bundles possono portare auto_stop_mins fino a un minuto. Pro e Classic hanno un minimo di 10 minuti.
L'impostazione più breve non è sempre quella giusta. Un auto-stop di un minuto può essere adatto a job pianificati isolati, mentre i workloads interattivi DirectQuery possono trarre vantaggio dal restare attivi più a lungo. La nostra guida all'auto-stop del SQL Warehouse consiglia circa 10 minuti per l'uso SQL generale.
Può impostare un warehouse Serverless su un auto-stop di un minuto con la CLI di Databricks:
databricks warehouses edit <WAREHOUSE_ID> \ --auto-stop-mins 1Anche i valori predefiniti dipendono da come vengono creati i SQL warehouse. La UI di Databricks imposta per default Serverless a 10 minuti e Pro o Classic a 45 minuti, mentre i Declarative Automation Bundles usano 10 minuti per Serverless e 120 minuti per Pro o Classic. Imposti auto_stop_mins in modo esplicito, così il deployment non dipenderà dal default di quel percorso di configurazione.
Dimensionare un SQL warehouse: dimensione vs. cluster
In Databricks SQL, la dimensione del warehouse e max clusters risolvono problemi di prestazioni diversi. La dimensione controlla il compute disponibile per le singole query, mentre max clusters controlla quanta domanda concorrente il warehouse può servire. Serverless utilizza inoltre l'Intelligent Workload Management per gestire automaticamente parte dell'allocazione delle risorse.
Usi i segnali di query e di coda per decidere quale controllo regolare:
| Sintomo | Leva da regolare |
|---|---|
| Una singola query è lenta o genera molto spill su disco | Aumentare la dimensione del warehouse |
| Le query trascorrono molto tempo in attesa di capacità | Aumentare max clusters |
| Peak Queued Queries resta sopra lo zero | Verificare sia la dimensione del warehouse sia max clusters |
| Lunghe pause di inattività tra le query | Ridurre l'auto-stop |
Peak Queued Queries da solo non identifica la soluzione esatta. Un valore elevato di waiting_at_capacity_duration_ms indica pressione sulla capacità, mentre query lente o con molto spill puntano più verso la dimensione del warehouse. La nostra preferenza è verificare se la pressione è a livello di query o di concorrenza prima di aggiungere altro compute.
Il tempo di inattività segnala un problema diverso. Quando la capacità è sufficiente durante l'esecuzione delle query ma il warehouse resta attivo tra un job e l'altro, l'impostazione da esaminare è l'auto-stop.
Quando Power BI DirectQuery cambia l'equazione dei costi serverless
Power BI DirectQuery può generare molta più attività sul warehouse di quanto la dashboard stessa sembri giustificare, perché ogni interazione può inviare un'altra query a Databricks. Databricks consiglia i Serverless SQL Warehouse per DirectQuery e LiveQuery, con una finestra di auto-stop da 15 a 30 minuti per i workloads interattivi.
Quando al business bastano aggiornamenti ogni pochi minuti, i modelli Import o Hybrid possono ridurre l'attività su Databricks SQL servendo più interazioni dei report direttamente da Power BI. Anche le viste materializzate possono precalcolare il lavoro SQL ripetuto, sebbene i loro refresh utilizzino comunque compute serverless separato.
A nostro avviso, DirectQuery dovrebbe essere uno dei primi aspetti da indagare quando il costo di Serverless sembra scollegato dalla complessità della dashboard. Prima di incolpare il pricing di Serverless, verifichi se la modalità di connessione BI sta generando più attività di quanto il requisito di freschezza dei dati richieda davvero.
Trasformare queste leve in una prassi operativa
Tenere sotto controllo i costi del SQL Warehouse richiede visibilità continua su dimensionamento, tempi di inattività e pressione sulla capacità. La nostra vista dei costi SQL Warehouse riunisce questi segnali, così può vedere dove la configurazione merita una nuova verifica.
I nostri Automated Savings possono regolare le impostazioni supportate di numero di worker e di autoscaling dei SQL Warehouse al variare della domanda. L'auto-stop resta un controllo separato, quindi conviene comunque rivedere auto_stop_mins dopo i deployment e verificare le modalità di connessione BI quando l'attività non corrisponde più al requisito di freschezza del business.
Il livello successivo di risparmio consiste nel trasformare questi controlli in un'abitudine operativa. La domanda è se rivedere manualmente dimensione, max clusters, auto-stop e modalità BI sia ancora un compromesso sostenibile, o se quel lavoro ricorrente stia iniziando ad accumularsi.
Costi del Databricks Serverless SQL Warehouse: cosa regolare per primo
Abbini l'impostazione al segnale che sta osservando: le finestre di inattività indicano l'auto-stop, la pressione in coda la capacità, le singole query lente la dimensione del warehouse e un'attività BI inattesa la modalità di connessione. Confronti Serverless, Pro e Classic sul costo totale, non sul solo prezzo per DBU.
Esamini le evidenze prima di modificare la configurazione. La nostra vista dei costi Databricks riunisce costi, dimensionamento, compute inattivo e utilizzo del SQL Warehouse, così può vedere quale impostazione merita attenzione per prima.