In sintesi: a luglio 2023 il modello di pricing di BigQuery è cambiato in modo radicale. La tariffa flat-rate è stata eliminata e sostituita da tre livelli Editions con slot in autoscaling. Significa che gran parte delle guide ai costi scritte prima del 2023 è ormai superata e che molti progetti di ottimizzazione pensati come interventi una tantum risultano sottodimensionati per il 2026. Questo articolo spiega come funziona oggi davvero il pricing di BigQuery, quali tattiche incidono sulla fattura e come intercettare i problemi di costo prima che si traducano in addebiti.
La maggior parte dei problemi di costo su BigQuery emerge nel modo sbagliato: una voce a sorpresa nella fattura del mese precedente, il responsabile del data team che inoltra lo screenshot di un picco, una domanda del reparto finance a cui nessuno sa rispondere in fretta. Quando parte la conversazione, la query che ha generato il problema è stata eseguita due settimane prima.
Questo divario non è un problema di tooling: è strutturale. BigQuery fattura a posteriori, l'ottimizzazione compete con il lavoro sulla roadmap e il modello di pricing è cambiato a tal punto, rispetto a quando sono state scritte la maggior parte delle guide ai costi, che molti consigli standard non sono più applicabili. Gli engineer che seguono indicazioni basate su slot flat-rate o su incrementi di autoscaling da 50 slot stanno ottimizzando rispetto a un modello che non esiste più.
Questa guida mostra come si presenta davvero l'ottimizzazione dei costi di BigQuery nel 2026: il modello di pricing attuale, le tattiche che riducono la spesa senza degradare le performance e il livello di observability che rende possibile il miglioramento continuo.
Perché nel 2026 l'ottimizzazione dei costi di BigQuery è diversa
La cosa più importante da sapere sul pricing di BigQuery nel 2026 è che la tariffa flat-rate non esiste più. Il 5 luglio 2023 Google ha ritirato gli acquisti di slot flat-rate e i Flex Slots, sostituendoli con un modello a tre livelli chiamato Editions: Standard, Enterprise ed Enterprise Plus. Il pricing on-demand resta disponibile, ma il lato capacità di BigQuery oggi funziona in modo diverso da quanto descrive gran parte della documentazione.
Gli slot in autoscaling sono il modello di capacità predefinito di Editions. Invece di acquistare un blocco fisso di slot al mese, si configurano un baseline (il livello minimo sempre disponibile) e un massimo (il tetto che l'autoscaler può raggiungere). BigQuery scala entro questi limiti in base alla domanda delle query, fatturando per slot-ora anziché su un blocco committed. La conseguenza pratica: l'esposizione ai costi scala con l'utilizzo, non con un acquisto predeterminato, e questo rende l'ottimizzazione un'attività continua, non una decisione di provisioning una tantum.
È un cambiamento che incide sul modo in cui i team di engineering devono affrontare il lavoro sui costi e amplia anche il perimetro di ciò che va monitorato. Ottimizzare i costi di BigQuery nel 2026 significa considerare anche i servizi ausiliari accanto al compute principale: Cloud Composer v3 (proprio la versione 3, che ha introdotto un nuovo modello di fatturazione) e Dataplex generano entrambi addebiti che compaiono sotto SKU adiacenti a BigQuery e si sommano al costo totale di una data platform. I team che avviano un'iniziativa sui costi dovrebbero estrarre fin dall'inizio i dati di billing di questi servizi insieme a quelli del compute di BigQuery, senza trattarli come un'attività di pulizia a parte.
Il partizionamento di una tabella aiuta ancora, ma il calcolo dei risparmi cambia con gli slot in autoscaling rispetto al flat-rate. Distribuire i workloads per restare sotto una soglia di slot commitment era la mossa giusta nel 2022; nel 2026 l'obiettivo è ridurre a monte le slot-ore consumate dai workloads e dimensionare baseline e tetto sui pattern reali. L'ottimizzazione è un tuning continuo, non un progetto da chiudere.
Come funziona davvero il pricing di BigQuery
BigQuery addebita due voci in modo indipendente: compute e storage. Il compute è dove va concentrata gran parte dell'attenzione di ottimizzazione, perché è lì che i costi scalano in modo imprevedibile.
Pricing on-demand
L'on-demand fattura per tebibyte scansionato a 6,25 $ per TiB, con il primo TiB al mese gratuito per progetto. Non si acquistano slot direttamente: Google alloca in background fino a 2.000 slot condivisi per progetto. L'on-demand funziona bene per team con volumi di query irregolari o ridotti, ambienti di sviluppo e test e workloads di analisi ad hoc con pattern di query imprevedibili. Il rischio è il costo di scan: una query scritta male su una tabella grande e non partizionata può generare un addebito significativo da un singolo job.
Pricing slot-based di Editions
Editions fattura per slot-ora: il numero di slot resi disponibili dalla prenotazione moltiplicato per la durata di utilizzo. Nella region US le tariffe pay-as-you-go sono 0,04 $ per slot-ora per Standard, 0,06 $ per Enterprise e 0,10 $ per Enterprise Plus. Enterprise ed Enterprise Plus offrono anche slot commitments a 1 e 3 anni con tariffe scontate. Separatamente da questi capacity commitments, Google propone anche Committed Use Discounts (CUDs) basati sulla spesa, che applicano uno sconto del 10% per un impegno di spesa di 1 anno e del 20% per un impegno di 3 anni su tutto l'utilizzo BigQuery PAYG idoneo in una region.
L'autoscaling in Editions scala in incrementi da 50 slot (non da 100, come riportato nella documentazione più datata) con una finestra minima di fatturazione predefinita di 60 secondi per evento di autoscaling. Quel limite di 60 secondi è la finestra di scale-down dell'autoscaler, non una regola per query. Una query breve in burst che attiva l'autoscaling comporta comunque, per impostazione predefinita, almeno un minuto di addebiti su quegli slot aggiuntivi. Google ha introdotto una funzionalità opt-in chiamata fluid scaling, ora in general availability, che sostituisce il minimo di 60 secondi con una vera fatturazione al secondo a livello di prenotazione. I team con query brevi, ad alta frequenza o variabili dovrebbero valutare se abilitare il fluid scaling riduca il costo effettivo per slot-ora.
Il calcolo del break-even tra on-demand ed Editions è più utile se ancorato a Enterprise Edition, il confronto più rilevante per la maggior parte dei team in produzione: Standard Edition ha un tetto di 1.600 slot per prenotazione e non include CMEK, BI Engine e commitments pluriennali, spesso requisiti irrinunciabili quando si spostano workloads prevedibili fuori dall'on-demand. A 0,06 $ per slot-ora, 100 slot Enterprise Edition in esecuzione continua per un mese costano circa 4.380 $, equivalenti alla scansione di circa 700 TiB on-demand a 6,25 $ per TiB. Se il team scansiona costantemente meno di quel volume con tempistiche imprevedibili, l'on-demand è probabilmente più conveniente. Se la scansione è superiore, oppure se i workloads si concentrano in finestre prevedibili, il pricing slot di Editions ha probabilmente la meglio. L'unico modo affidabile per calcolare il break-even reale è interrogare INFORMATION_SCHEMA.JOBS per ottenere il totale degli slot-millisecondi negli ultimi 30-90 giorni e convertirlo in slot-ore.
Pricing dello storage
BigQuery offre due modelli di fatturazione dello storage a livello di dataset: logico e fisico. Lo storage logico, quello predefinito, fattura sui byte non compressi. Lo storage fisico fattura sui byte compressi e, poiché BigQuery comprime i dati prima della fatturazione, la tariffa lorda per GiB è inferiore. Il compromesso è che lo storage fisico richiede ora di pagare il time travel e sette giorni di fail-safe storage alla tariffa fisica attiva, costi che non si applicano nella fatturazione logica. Per i dataset con elevati rapporti di compressione il modello fisico resta vincente sul costo totale; per altri, l'overhead di time travel e fail-safe può ribaltare il calcolo. Utilizzi la query di confronto della fatturazione dello storage nella libreria di query di ottimizzazione BigQuery di DoiT (github.com/doitintl/bigquery-optimization-queries) per calcolare la raccomandazione netta per ciascun dataset prima del passaggio. Lo storage attivo e lo storage a lungo termine (tabelle o partizioni non modificate da 90 giorni) hanno tariffe diverse in entrambi i modelli, con lo storage a lungo termine che costa circa la metà di quello attivo. Tabelle inutilizzate e vecchie partizioni che non passano mai allo stato a lungo termine a causa di scritture occasionali sono un costo nascosto ricorrente.
Assegnazione del modello di pricing
Un dettaglio facile da trascurare: il modello di pricing si sceglie per assegnazione di prenotazione, non per organizzazione. Progetti o folder diversi all'interno della stessa organizzazione Google Cloud possono funzionare contemporaneamente su modelli diversi. Un progetto di sviluppo può restare in on-demand mentre i workloads di produzione girano su slot Enterprise Edition. Questa flessibilità per progetto significa che non occorre prendere un'unica decisione tutto-o-niente per l'intera organizzazione.
ModelloUnità di fatturazioneTariffa pay-as-you-go USIdeale perOn-demandTiB scansionati6,25 $ / TiBWorkloads irregolari, leggeri o imprevedibiliStandard EditionSlot-ora0,04 $ / slot-oraTeam di analytics con volumi costanti e moderati; nessun commitment richiestoEnterprise EditionSlot-ora0,06 $ / slot-oraWorkloads di produzione che richiedono sicurezza, governance o BI EngineEnterprise PlusSlot-ora0,10 $ / slot-oraWorkloads mission-critical con DR cross-region o requisiti di compliance
Tattiche di ottimizzazione dei costi di BigQuery che incidono sulla fattura
Le tattiche qui sotto riducono ciò che BigQuery addebita, sia in on-demand sia in Editions. In on-demand, meno byte scansionati significano direttamente una fattura più bassa. In Editions, un'esecuzione più efficiente delle query si traduce in meno slot-ore consumate, riducendo il costo del tetto di autoscaling e del commitment di baseline.
Scegliere il modello di fatturazione dello storage giusto
La fatturazione dello storage fisico è una delle leve di costo a maggior impatto in BigQuery, e una delle più spesso trascurate. BigQuery offre due modelli di fatturazione dello storage a livello di dataset: logico (il default legacy, fatturato sui byte non compressi) e fisico (fatturato sui byte compressi). Lo storage fisico costa circa il doppio del logico per GiB, ma, poiché BigQuery comprime i dati prima della fatturazione, il costo effettivo è inferiore per la maggior parte dei workloads.
I risparmi dipendono interamente dal rapporto di compressione. BigQuery utilizza un algoritmo di compressione generico anziché un algoritmo per colonna ottimizzato per specifici tipi di dati. I workloads con dati ad alta entropia, come log, event stream o record ricchi di testo, raggiungono spesso rapporti di compressione di 10:1 o superiori con quell'algoritmo, rendendo lo storage fisico nettamente più economico. I workloads dominati da tipi numerici a larghezza fissa come interi, double e float hanno poca ridondanza strutturale sfruttabile da un algoritmo generico: si comprimono male e la fatturazione fisica può finire per costare più di quella logica. Esegua la query di confronto della fatturazione dello storage sul suo progetto prima di convertire qualsiasi dataset: le mostrerà il costo attuale, quello previsto con l'altro modello e una raccomandazione per ciascun dataset. Il modello si imposta a livello di dataset, non di progetto, quindi può convertire singolarmente i dataset ad alto valore senza toccare il resto.
Per i dati che è tenuto a conservare per legge ma che interroga raramente o mai, valuti l'export su Google Cloud Storage Coldline o Archive. Un dataset di retention HIPAA di sette anni mantenuto in BigQuery genera indefinitamente addebiti di storage attivo o a lungo termine. Gli stessi dati in un bucket GCS Archive costano una frazione, restano interrogabili tramite tabelle esterne di BigQuery quando serve e vengono eliminati automaticamente allo scadere della finestra di retention se si configurano le regole di lifecycle.
Partizionare le tabelle per scansionare meno dati
Il partizionamento divide una tabella di grandi dimensioni in segmenti più piccoli, di solito per data o per una colonna ad alta cardinalità, in modo che le query possano saltare le partizioni non necessarie. La tecnica è efficace solo quando le query includono un filtro qualificante sulla colonna di partizione. Una query su una tabella partizionata che non filtra sulla chiave di partizione scansiona l'intera tabella, esattamente come se il partizionamento non esistesse.
La priorità pratica: partizionare le tabelle che hanno una dimensione temporale e che i suoi dashboard o job pianificati interrogano per intervalli di date. Interrogando INFORMATION_SCHEMA.JOBS_BY_PROJECT filtrato per total_bytes_processed emergono le tabelle con job ricorrenti privi di filtri sulla partizione. Sono la via più rapida per ridurre lo scan.
Clusterizzare le tabelle per un pruning più granulare
Il clustering organizza i dati di una tabella in blocchi in base ai valori di una o più colonne. Le query che filtrano su quelle colonne saltano i blocchi non corrispondenti, riducendo i byte scansionati oltre a quanto consente il solo partizionamento. Il clustering funziona meglio su colonne ad alta cardinalità che compaiono spesso nelle clausole WHERE o nelle condizioni JOIN, e l'ordine delle colonne nella definizione del cluster dovrebbe rispecchiare l'ordine dei filtri delle query.
Partizionamento e clustering si possono combinare. La combinazione ha senso per tabelle grandi interrogate sia per una dimensione temporale sia per una colonna filtro secondaria, come un tenant ID o un tipo di evento. Il compromesso: le strategie combinate aumentano l'overhead dei metadati della tabella e i benefici del clustering diminuiscono se le query non filtrano in modo coerente sulle stesse colonne nell'ordine definito.
Filtrare presto e selezionare in modo mirato
BigQuery fattura sui byte scansionati prima dell'applicazione dei filtri, quindi una SELECT * su una tabella larga addebita tutte le colonne indipendentemente da quali servano effettivamente nell'output. Selezionare solo le colonne necessarie e applicare i filtri di partizione e cluster nella parte iniziale della query riduce direttamente il volume scansionato. Le subquery che fanno riferimento a tabelle larghe, anche quando la query esterna proietta solo poche colonne, trascinano in fattura l'intero costo di scan.
L'impostazione maximum_bytes_billed consente di porre un tetto rigido al volume scansionato da una singola query. Qualsiasi query che supererebbe il limite fallisce subito invece di completarsi e generare un addebito elevato. Questa impostazione funziona sia come guardrail sui costi in fase di sviluppo sia come rete di sicurezza in produzione per job in cui una query fuori controllo si rivelerebbe costosa.
Calibrare baseline e tetti dell'autoscaling degli slot
In Editions controlla due parametri di slot per prenotazione: il baseline (slot sempre disponibili) e il massimo (il tetto che l'autoscaler può raggiungere). L'autoscaling aggiunge capacità in incrementi da 50 slot quando la domanda supera il baseline, con una finestra di scale-down di 60 secondi prima del rilascio degli slot per impostazione predefinita. Un job che attiva l'autoscaling anche solo per un secondo comporta un intero minuto di fatturazione su quei 50 slot aggiuntivi nell'autoscaling standard. Se attiva il fluid scaling a livello di prenotazione, BigQuery passa a una vera fatturazione al secondo senza durata minima, che secondo Google può ridurre i costi fino al 34% per workloads con pattern di query brevi o variabili. La dimensione dell'incremento da 50 slot non cambia con il fluid scaling.
Impostare il massimo troppo alto significa che brevi job in burst possono spingere la spesa inutilmente in territorio costoso. Impostare il baseline troppo basso significa che la maggior parte dei workloads gira su capacità in autoscaling, che costa di più per slot-ora rispetto agli slot di baseline committed quando sono in gioco commitments Enterprise o Enterprise Plus. L'obiettivo di ottimizzazione è un baseline che copra il livello minimo dei workloads stabili e un tetto massimo dimensionato per gestire picchi legittimi senza lasciare margine a job fuori controllo.
Interroghi INFORMATION_SCHEMA.JOBS sugli ultimi 60 giorni per mappare l'effettivo utilizzo concorrente di slot ora per ora. Quella distribuzione le indica dove fissare il baseline e dove deve attestarsi il massimo. Per una guida dettagliata al percorso di migrazione dall'on-demand, la guida in cinque passaggi di DoiT copre per intero la configurazione della prenotazione.
Un pattern operativo che riduce i costi sui workloads prevedibili: ridimensionare dinamicamente la prenotazione attorno a finestre ETL note. Alzare il baseline prima di un pesante job di trasformazione notturno e abbassarlo a job concluso. In questo modo si evita di tenere slot costosi nelle ore di inattività ai lati del job. Lo stesso approccio funziona al contrario per i team che necessitano di margine durante l'orario lavorativo ma eseguono workloads minimi di notte.
Affiancare CUDs basati sulla spesa al modello di pricing scelto
Una volta scelto Editions per un progetto, c'è un secondo meccanismo di sconto da valutare: i Committed Use Discounts basati sulla spesa. Sono distinti dai commitments di capacità di slot. Invece di impegnarsi su un numero fisso di slot, ci si impegna su un importo orario minimo in dollari di spesa BigQuery in una specifica region, e Google applica uno sconto a tutto l'utilizzo PAYG idoneo coperto da quel commitment.
Tariffe di sconto attuali: 10% per un termine di 1 anno, 20% per un termine di 3 anni. Lo sconto si applica automaticamente a tutti i tipi di compute BigQuery PAYG nella region oggetto del commitment, senza richiedere alcuna allocazione manuale di slot. L'utilizzo oltre l'importo orario committed viene addebitato alla tariffa PAYG standard; l'utilizzo inferiore comporta comunque l'addebito dell'importo committed. Il commitment è non cancellabile, quindi va dimensionato sulla spesa oraria minima attesa, non sulla media, per evitare di pagare capacità impegnata che resta inutilizzata nei periodi più lenti.
Un rischio operativo: gli slot commitments in Editions si rinnovano automaticamente per impostazione predefinita. Un commitment impostato per il rinnovo di un ulteriore termine triennale lo farà in modo silenzioso, a meno che non verifichi e aggiorni l'impostazione di rinnovo prima della finestra di scadenza. Google in genere consente cancellazioni entro sette giorni dal rinnovo, ma non oltre. Includa la revisione delle impostazioni di rinnovo dei commitments in qualsiasi audit di billing di routine.
Decidere tra on-demand ed Editions progetto per progetto
Poiché l'assegnazione del modello di pricing avviene per progetto, l'approccio corretto è verificare i progetti singolarmente anziché cercare una risposta unica per tutta l'organizzazione. Progetti di sviluppo, test e analisi ad hoc si adattano spesso all'on-demand; pipeline ETL notturne, back-end di dashboard e data product ricorrenti con consumo di slot prevedibile in genere preferiscono Editions.
Il segnale da cercare: un progetto in cui il consumo medio di slot supera costantemente i 50 slot merita di essere valutato per Editions. Un progetto in cui l'utilizzo di slot al picco si concentra in una finestra giornaliera prevedibile, come un job di trasformazione notturno, è un forte candidato per un commitment di baseline. I progetti con utilizzo volatile o sporadico dovrebbero restare in on-demand, dove il pool di slot condivisi non costa nulla nei periodi di inattività. Per un'analisi completa su come valutare il passaggio, consulti la guida BigQuery Editions di DoiT e l'approfondimento sull'autoscaling.
Mettere in cache le query ripetute di dashboard e BI tool con BI Engine
Looker e dbt sono costantemente i due principali driver di costo del compute BigQuery negli ambienti dei clienti. Il pattern è lo stesso in entrambi i casi: un BI tool o un livello di trasformazione colpisce le stesse tabelle centinaia o migliaia di volte al giorno, e ogni query scansiona gli stessi dati con la relativa fatturazione. Il costo di scan si accumula sia in on-demand sia in Editions.
BI Engine è il livello di caching in-memory di BigQuery. Si pone davanti allo storage di BigQuery e intercetta le query che può servire dalla cache, restituendo i risultati senza innescare una scansione completa. Lei riserva una quantità fissa di memoria (fatturata per GB-ora), specifica le tabelle preferite da mantenere calde e BI Engine gestisce automaticamente popolamento e invalidazione della cache. Le query che colpiscono la cache vengono eseguite più velocemente e non costano nulla oltre alla tariffa della prenotazione.
Il calcolo del ROI è semplice: identifichi quale service account utilizza il suo BI tool, misuri quanti dati scansiona al giorno e su quali tabelle, poi confronti quel costo di scan con una prenotazione BI Engine dimensionata per tenere in memoria quelle tabelle. Per workloads che colpiscono ripetutamente le stesse grandi tabelle con piccole variazioni di intervallo di date, la tariffa della prenotazione è in genere una frazione del costo di scan che sostituisce. Le prenotazioni BI Engine possono essere ridimensionate o eliminate on demand, quindi non si è vincolati a un commitment fisso.
Le materialized view completano BI Engine per le query ricche di aggregazioni. Se una dashboard calcola ripetutamente la stessa somma, media o conteggio su un grande dataset, una materialized view precalcola quell'aggregato e ne memorizza il risultato. Le query a valle leggono il valore precalcolato invece di ricalcolarlo a ogni esecuzione. Combinati con il caching di BI Engine, i due approcci eliminano gran parte del compute ridondante che rende costosi i BI tool negli ambienti BigQuery.
Ridurre la frequenza dei job pianificati e ricorrenti
Le query pianificate eseguite più spesso di quanto i consumatori abbiano davvero bisogno dell'output sono uno spreco diretto in entrambi i modelli di pricing. Una dashboard che si aggiorna ogni ora ma viene consultata due volte al giorno comporta sei volte il costo di compute necessario. Un report eseguito ogni notte ma che alimenta una revisione settimanale può tranquillamente girare con cadenza settimanale.
La questione è organizzativa tanto quanto tecnica. Interrogare INFORMATION_SCHEMA.JOBS filtrato per frequenza di job e byte elaborati offre ai team di engineering i dati per argomentare la riduzione della cadenza senza dover stimare l'impatto a occhio. I job eseguiti ad alta frequenza che scansionano grandi volumi e servono consumatori che controllano i risultati di rado sono i target a maggior leva. Per un contesto più ampio sull'ottimizzazione dei costi CloudOps, il framework di DoiT illustra come i team strutturano questo tipo di lavoro continuativo di governance.
Eseguire backup ed eliminare tabelle e partizioni inutilizzate
Le tabelle non interrogate da mesi generano comunque addebiti di storage attivo se ricevono scritture, anche occasionali, che resettano il contatore dei 90 giorni dello storage a lungo termine. Le partizioni interne a tabelle attive che cadono al di fuori degli intervalli utili di query generano costi di scan se le query non filtrano correttamente. Entrambi i problemi si affrontano con policy di scadenza delle partizioni e audit periodici delle tabelle.
La view INFORMATION_SCHEMA.TABLE_STORAGE di BigQuery mostra dimensione della tabella, ultima modifica e conteggio righe a livello di progetto. Tabelle grandi, vecchie e mai interrogate sono candidate ad archiviazione o eliminazione. Impostare la scadenza delle partizioni in fase di creazione tabella previene l'accumulo nel tempo di dati obsoleti senza richiedere pulizie manuali continue.
Come far emergere i problemi di costo di BigQuery prima che si traducano in addebiti
La sfida strutturale dell'observability dei costi di BigQuery è che gli strumenti standard offrono storico, non alert. Cloud Monitoring e INFORMATION_SCHEMA le dicono cosa è successo; non interrompono lavori costosi in corso né segnalano le anomalie nel momento in cui si sviluppano.
Diversi controlli nativi avvicinano a un rilevamento proattivo. Il parametro maximum_bytes_billed a livello di query impedisce alle singole query fuori controllo di completarsi. Gli alert di utilizzo slot in Cloud Monitoring scattano quando il consumo di slot di una prenotazione supera una soglia, facendo emergere carichi inattesi anche quando la query in sé appare normale. Cloud Functions o Cloud Workflows consentono di implementare logiche di alert più sofisticate, come l'invio di una notifica quando il consumo di slot di un progetto specifico supera la sua media mobile di un margine configurabile.
Tenere d'occhio l'egress cross-region tra compute e storage
Google ha recentemente dismesso l'etichetta "multi-region" in BigQuery, da tempo un termine fuorviante. Quella che si chiamava multi-region US è fisicamente ospitata in us-central-1 nella stragrande maggioranza dei casi; quella che si chiamava multi-region EU si trova tipicamente in europe-west-4. Se il suo dataset risiede in una singola region come us-east-1 e il compute gira sulla region US, o viceversa, Google le fattura egress cross-region a ogni lettura. Quegli addebiti compaiono come voci separate nella console di billing sotto SKU che la maggior parte degli engineer non riconosce immediatamente come egress.
Il metodo di rilevamento: cerchi nell'export di billing gli SKU che corrispondono al pattern "General Data Transfer Networking Traffic for Google Cloud Cross Region/Inter Region". La presenza di quello SKU nell'export conferma che si sta verificando egress cross-region. Per risalire alla fonte, cerchi SKU di compute Analysis o Editions accanto a SKU di Storage legati a region diverse nello stesso periodo di fatturazione. La combinazione le indica quale region di compute sta leggendo da quale region di storage. La soluzione è semplice: collochi storage e compute nella stessa region.
Verificare la presenza di addebiti imprevisti di Dataplex e Data Lineage API
Dataplex e la Data Lineage API generano addebiti che compaiono sotto SKU Dataplex nella console di billing, e molti team li sostengono senza accorgersi che i servizi sono attivi. Dataplex può essere abilitato automaticamente tramite integrazioni, configurazioni di dataset o funzionalità trial e continua a scansionare e catalogare i dati in background, indipendentemente dal fatto che qualcuno usi attivamente il catalogo. La Data Lineage API, anche quando abilitata in modo indipendente da Dataplex, può attivare la fatturazione di Dataplex in determinate configurazioni.
Se nota addebiti di Dataplex Premium Processing Unit nell'export di billing e il suo team non sta usando attivamente Dataplex per data discovery, lineage o governance, verifichi quali API sono abilitate e se qualche integrazione le ha attivate. Disabilitare sia la Dataplex API sia la Data Lineage API nei progetti in cui non servono elimina del tutto gli addebiti in background. Diversi strumenti gratuiti e open source coprono il data lineage senza far scattare la fatturazione di Dataplex.
Rilevare le anomalie a livello di job, non solo di prenotazione
La lacuna degli strumenti nativi è il rilevamento delle anomalie a livello di job. Cloud Monitoring opera a livello di prenotazione: può dirle che l'uso degli slot è schizzato, ma non quale job ha causato il picco, a quale progetto appartiene o se il pattern è un evento isolato o una regressione ricorrente. Passare da un picco di slot al job responsabile richiede di incrociare manualmente i dati con INFORMATION_SCHEMA.JOBS, e ciò richiede un tempo che di solito il team in quel momento non ha.
Colmare quella lacuna significa interrogare INFORMATION_SCHEMA.JOBS su base pianificata, confrontare slot-millisecondi e byte elaborati di ciascun job con la sua media mobile storica e generare alert quando un job devia oltre una soglia configurabile. Il team di field data engineering di DoiT può implementare questo livello di rilevamento per i team che ne hanno bisogno, senza l'onere di costruire e mantenere la pipeline internamente. Per approfondire come intercettare i picchi di costo prima che si traducano in addebiti, consulti il post di DoiT sul rilevamento dei picchi di costo di BigQuery.
Quando automatizzare l'ottimizzazione dei costi di BigQuery
L'ottimizzazione manuale scala fino a un certo punto. Un team di engineering che gestisce una manciata di progetti BigQuery può partizionare le tabelle chiave, calibrare le impostazioni delle prenotazioni e verificare i job pianificati con una cadenza ragionevole. Lo stesso team che gestisce 40 progetti su più business unit non riesce a tenere il passo del lavoro di ottimizzazione insieme allo sviluppo di nuove feature. Il backlog cresce più in fretta di quanto venga smaltito.
La motivazione dell'automazione non è sostituire il giudizio degli engineer. È assicurarsi che quel giudizio agisca su dati attuali anziché su audit obsoleti. Il rilevamento automatico fa emergere le anomalie in tempo reale; gli engineer decidono cosa farne. Le raccomandazioni automatiche riducono l'onere diagnostico; gli engineer validano e implementano. La combinazione produce tempi di risposta più rapidi rispetto a entrambi gli approcci presi singolarmente.
Il team di field data engineering di DoiT supporta i livelli di rilevamento e raccomandazione di questo workflow, integrando il monitoraggio dei costi direttamente nelle pipeline esistenti e facendo emergere risultati a livello di job con contesto sufficiente per agire senza ulteriori indagini. Quel lavoro si integra con il framework FinOps per Google Cloud di DoiT, così i risultati sui costi non restano in un dashboard ad attendere che qualcuno li controlli.
I team che vogliono fare un benchmark dello stato attuale prima di automatizzare troveranno utili la guida ai KPI FinOps e la panoramica sugli strumenti di cloud cost analytics di DoiT per stabilire baseline e scegliere la strumentazione giusta.
Mettere l'ottimizzazione dei costi di BigQuery su basi sostenibili
L'ottimizzazione dei costi di BigQuery nel 2026 non è un progetto con una data di completamento. Il modello di pricing premia l'attenzione continua: baseline di slot che restano sopra l'utilizzo effettivo gonfiano silenziosamente la fattura; nuove tabelle aggiunte senza policy di partizionamento accumulano costi di scan nel tempo; job pianificati creati per un caso d'uso che non esiste più continuano a girare perché nessuno ha pensato a disattivarli. Il costo della trascuratezza si accumula lentamente e si manifesta all'improvviso.
I team che mantengono sotto controllo la spesa BigQuery trattano l'ottimizzazione come una pratica continua, non come un'iniziativa periodica. Hanno visibilità sull'attribuzione dei costi a livello di job. Rispondono alle anomalie nella finestra temporale in cui sono ancora indirizzabili. Prendono le decisioni di partizionamento e clustering in fase di creazione delle tabelle, non durante i retrospettivi degli incidenti. E hanno un meccanismo per trasformare i risultati in azioni senza creare un backlog separato di ticket di ottimizzazione che compete con il lavoro sulle feature.
Le capacità di field data engineering di DoiT sono progettate per supportare il percorso dall'insight all'esecuzione, in modo continuo, senza l'onere di audit manuali o il ritardo delle fatture a posteriori. Parli con un engineer DoiT di partizionamento, clustering, tuning degli slot e monitoraggio continuo dei costi sull'intera sua presenza BigQuery.
Domande frequenti
Quando conviene passare da on-demand a BigQuery Editions?
Il segnale più chiaro è un consumo di slot costantemente superiore a 50 slot. A 0,06 $ per slot-ora su Enterprise Edition, 100 slot in esecuzione continua per un mese costano circa 4.380 $, all'incirca equivalenti alla scansione di 700 TiB on-demand a 6,25 $ per TiB. Se il suo volume di scansione mensile si avvicina a quella soglia con tempistiche prevedibili, Editions le farà probabilmente risparmiare. Interroghi INFORMATION_SCHEMA.JOBS per ottenere il totale degli slot-millisecondi negli ultimi 30-90 giorni e calcolare il break-even effettivo prima di impegnarsi.
Quali sono le tre BigQuery Editions e in cosa differiscono?
Standard Edition si adatta a team di analytics con workloads moderati e costanti. Supporta l'autoscaling con pricing pay-as-you-go a 0,04 $ per slot-ora (region US) ma non offre commitments pluriennali né condivisione di slot inattivi. Enterprise Edition aggiunge cifratura CMEK, capacità BI Engine, snapshot di tabelle e sconti su commitments a 1 o 3 anni, risultando la scelta giusta per workloads di produzione con requisiti di sicurezza o governance. Enterprise Plus aggiunge disaster recovery cross-region, backup gestito e uno SLA del 99,999%, ed è pensata per deployment mission-critical in cui il downtime comporta conseguenze normative o contrattuali.
Come posso evitare che una singola query generi una fattura BigQuery enorme?
Imposti il parametro maximum_bytes_billed a livello di query o job. Qualsiasi query che scansionerebbe più byte del limite configurato fallisce immediatamente, senza completarsi e generare l'addebito. Per i progetti on-demand questa impostazione funge da tetto rigido di spesa per query. Per i progetti Editions limita il consumo di slot ponendo un tetto al volume di scansione che determina la complessità della query. Può impostare questo parametro nell'API BigQuery, nella console e nelle client library, e applicarlo come policy organizzativa tramite i controlli sulle impostazioni delle query di Google Cloud.