Stima e controllo dei costi

Questa pagina descrive le best practice per stimare e controllare i costi in BigQuery.

I costi principali in BigQuery sono quelli di calcolo, utilizzati per l'elaborazione delle query, e di archiviazione, per i dati archiviati in BigQuery. BigQuery offre due tipi di modelli di prezzo per l'elaborazione delle query: prezzi on demand e basati sulla capacità. Ogni modello offre best practice diverse per il controllo dei costi. Per i dati archiviati in BigQuery, i costi dipendono dal modello di fatturazione dell'archiviazione configurato per ogni set di dati.

Informazioni sui prezzi di calcolo per BigQuery

Esistono sottili differenze nei prezzi di calcolo per BigQuery che influenzano la pianificazione della capacità e il controllo dei costi.

Modelli di prezzo

Per il computing on demand in BigQuery, vengono addebitati costi per TiB per le query BigQuery.

In alternativa, per il computing della capacità in BigQuery, vengono addebitati i costi per le risorse di calcolo (slot) utilizzate per elaborare la query. Per utilizzare questo modello, configura le prenotazioni per gli slot.

Le prenotazioni hanno le seguenti caratteristiche:

• Vengono allocati in pool di slot e ti consentono di gestire la capacità e isolare i carichi di lavoro in modi adatti alla tua organizzazione.
• Devono risiedere in un progetto di amministrazione e sono soggetti a quote e limiti.

Il modello di prezzi basato sulla capacità offre diverse versioni, che offrono tutte un'opzione pay-as-you-go addebitata in ore di slot. Le versioni Enterprise ed Enterprise Plus offrono anche impegni facoltativi di uno o tre anni per gli slot, che possono farti risparmiare rispetto alla tariffa pay-as-you-go.

Puoi anche impostare prenotazioni con scalabilità automatica utilizzando l'opzione pay-as-you-go. Per maggiori informazioni, consulta le seguenti risorse:

• Per confrontare i modelli di prezzo, vedi Scegliere un modello.
• Per i dettagli sui prezzi, consulta Prezzi di calcolo on demand e Prezzi di calcolo della capacità.

Limitare i costi per ogni modello

Quando utilizzi il modello di prezzi on demand, l'unico modo per limitare i costi è configurare quote giornaliere a livello di progetto o utente. Tuttavia, queste quote impongono un limite rigido che impedisce agli utenti di eseguire query oltre il limite della quota. Per impostare le quote, vedi Creare quote di query personalizzate.

Quando utilizzi il modello di prezzi per capacità con le prenotazioni di slot, specifichi il numero massimo di slot disponibili per una prenotazione. Puoi anche acquistare impegni di slot che offrono prezzi scontati per un periodo di tempo prestabilito.

Puoi utilizzare le versioni completamente on demand impostando la baseline della prenotazione su 0 e il massimo su un'impostazione che soddisfi le esigenze del tuo workload. BigQuery esegue automaticamente lo scale up fino al numero di slot necessari per il carico di lavoro, senza mai superare il valore massimo impostato. Per ulteriori informazioni, consulta Gestione dei carichi di lavoro utilizzando le prenotazioni.

Controllare i costi delle query

Per controllare i costi delle singole query, ti consigliamo di seguire prima le best practice per l'ottimizzazione del calcolo delle query e l'ottimizzazione dell'archiviazione.

Le sezioni seguenti descrivono best practice aggiuntive che puoi utilizzare per controllare ulteriormente i costi delle query.

Creare quote per query personalizzate

Best practice:utilizza quote di query giornaliere personalizzate per limitare la quantità di dati elaborati al giorno.

Puoi gestire i costi impostando una quota personalizzata che specifica un limite alla quantità di dati elaborati al giorno per progetto o per utente. Gli utenti non possono eseguire query una volta raggiunta la quota.

Per impostare una quota personalizzata, devi disporre di ruoli o autorizzazioni specifici. Per le quote da impostare, consulta Quote e limiti.

Per maggiori informazioni, consulta Limitare i costi per ogni modello di prezzo.

Controlla il costo stimato prima di eseguire una query

Best practice:prima di eseguire le query, visualizzane l'anteprima per stimare i costi.

Quando utilizzi il modello di prezzo on demand, le query vengono fatturate in base al numero di byte letti. Per stimare i costi prima di eseguire una query:

• Utilizza lo strumento di convalida delle query nella console Google Cloud .
• Esegui una prova per le query.

Utilizzare lo strumento di convalida delle query

Quando inserisci una query nella console Google Cloud , lo strumento di convalida delle query verifica la sintassi della query e fornisce una stima del numero di byte letti. Puoi utilizzare questa stima per calcolare il costo delle query nel Calcolatore prezzi.

• Se la query non è valida, lo strumento di convalida delle query visualizza un messaggio di errore. Ad esempio:

  Not found: Table myProject:myDataset.myTable was not found in location US

• Se la query è valida, lo strumento di convalida delle query fornisce una stima del numero di byte necessari per elaborare la query. Ad esempio:

  This query will process 623.1 KiB when run.

Eseguire una prova

Per eseguire una prova generale:

bq query \
--use_legacy_sql=false \
--dry_run \
'SELECT
   COUNTRY,
   AIRPORT,
   IATA
 FROM
   `project_id`.dataset.airports
 LIMIT
   1000'
 

Query successfully validated. Assuming the tables are not modified,
running this query will process 10918 bytes of data.

import (
	"context"
	"fmt"
	"io"

	"cloud.google.com/go/bigquery"
)

// queryDryRun demonstrates issuing a dry run query to validate query structure and
// provide an estimate of the bytes scanned.
func queryDryRun(w io.Writer, projectID string) error {
	// projectID := "my-project-id"
	ctx := context.Background()
	client, err := bigquery.NewClient(ctx, projectID)
	if err != nil {
		return fmt.Errorf("bigquery.NewClient: %v", err)
	}
	defer client.Close()

	q := client.Query(`
	SELECT
		name,
		COUNT(*) as name_count
	FROM ` + "`bigquery-public-data.usa_names.usa_1910_2013`" + `
	WHERE state = 'WA'
	GROUP BY name`)
	q.DryRun = true
	// Location must match that of the dataset(s) referenced in the query.
	q.Location = "US"

	job, err := q.Run(ctx)
	if err != nil {
		return err
	}
	// Dry run is not asynchronous, so get the latest status and statistics.
	status := job.LastStatus()
	if err := status.Err(); err != nil {
		return err
	}
	fmt.Fprintf(w, "This query will process %d bytes\n", status.Statistics.TotalBytesProcessed)
	return nil
}

import com.google.cloud.bigquery.BigQuery;
import com.google.cloud.bigquery.BigQueryException;
import com.google.cloud.bigquery.BigQueryOptions;
import com.google.cloud.bigquery.Job;
import com.google.cloud.bigquery.JobInfo;
import com.google.cloud.bigquery.JobStatistics;
import com.google.cloud.bigquery.QueryJobConfiguration;

// Sample to run dry query on the table
public class QueryDryRun {

  public static void runQueryDryRun() {
    String query =
        "SELECT name, COUNT(*) as name_count "
            + "FROM `bigquery-public-data.usa_names.usa_1910_2013` "
            + "WHERE state = 'WA' "
            + "GROUP BY name";
    queryDryRun(query);
  }

  public static void queryDryRun(String query) {
    try {
      // Initialize client that will be used to send requests. This client only needs to be created
      // once, and can be reused for multiple requests.
      BigQuery bigquery = BigQueryOptions.getDefaultInstance().getService();

      QueryJobConfiguration queryConfig =
          QueryJobConfiguration.newBuilder(query).setDryRun(true).setUseQueryCache(false).build();

      Job job = bigquery.create(JobInfo.of(queryConfig));
      JobStatistics.QueryStatistics statistics = job.getStatistics();

      System.out.println(
          "Query dry run performed successfully." + statistics.getTotalBytesProcessed());
    } catch (BigQueryException e) {
      System.out.println("Query not performed \n" + e.toString());
    }
  }
}

// Import the Google Cloud client library
const {BigQuery} = require('@google-cloud/bigquery');
const bigquery = new BigQuery();

async function queryDryRun() {
  // Runs a dry query of the U.S. given names dataset for the state of Texas.

  const query = `SELECT name
    FROM \`bigquery-public-data.usa_names.usa_1910_2013\`
    WHERE state = 'TX'
    LIMIT 100`;

  // For all options, see https://cloud.google.com/bigquery/docs/reference/rest/v2/jobs/query
  const options = {
    query: query,
    // Location must match that of the dataset(s) referenced in the query.
    location: 'US',
    dryRun: true,
  };

  // Run the query as a job
  const [job] = await bigquery.createQueryJob(options);

  // Print the status and statistics
  console.log('Status:');
  console.log(job.metadata.status);
  console.log('\nJob Statistics:');
  console.log(job.metadata.statistics);
}

use Google\Cloud\BigQuery\BigQueryClient;

/** Uncomment and populate these variables in your code */
// $projectId = 'The Google project ID';
// $query = 'SELECT id, view_count FROM `bigquery-public-data.stackoverflow.posts_questions`';

// Construct a BigQuery client object.
$bigQuery = new BigQueryClient([
    'projectId' => $projectId,
]);

// Set job configs
$jobConfig = $bigQuery->query($query);
$jobConfig->useQueryCache(false);
$jobConfig->dryRun(true);

// Extract query results
$queryJob = $bigQuery->startJob($jobConfig);
$info = $queryJob->info();

printf('This query will process %s bytes' . PHP_EOL, $info['statistics']['totalBytesProcessed']);

from google.cloud import bigquery

# Construct a BigQuery client object.
client = bigquery.Client()

job_config = bigquery.QueryJobConfig(dry_run=True, use_query_cache=False)

# Start the query, passing in the extra configuration.
query_job = client.query(
    (
        "SELECT name, COUNT(*) as name_count "
        "FROM `bigquery-public-data.usa_names.usa_1910_2013` "
        "WHERE state = 'WA' "
        "GROUP BY name"
    ),
    job_config=job_config,
)  # Make an API request.

# A dry run query completes immediately.
print("This query will process {} bytes.".format(query_job.total_bytes_processed))

Stima i costi delle query

Quando utilizzi il modello di prezzi on demand, puoi stimare il costo di esecuzione di una query calcolando il numero di byte elaborati.

Calcolo delle dimensioni delle query on demand

Per calcolare il numero di byte elaborati dai vari tipi di query, consulta le seguenti sezioni:

• Istruzioni DML
• Istruzioni DDL
• Tabelle in cluster

Evita di eseguire query per esplorare i dati delle tabelle

Best practice:non eseguire query per esplorare o visualizzare in anteprima i dati delle tabelle.

Se stai sperimentando o esplorando i tuoi dati, puoi utilizzare le opzioni di anteprima della tabella per visualizzare i dati senza costi e senza influire sulle quote.

BigQuery supporta le seguenti opzioni di anteprima dei dati:

• Nella Google Cloud console, nella pagina dei dettagli della tabella, fai clic sulla scheda Anteprima per campionare i dati.
• Nello strumento a riga di comando bq, utilizza il comando bq head e specifica il numero di righe da visualizzare in anteprima.
• Nell'API, utilizza tabledata.list per recuperare i dati della tabella da un insieme specificato di righe.
• Evita di utilizzare LIMIT nelle tabelle non in cluster. Per le tabelle non in cluster, una clausola LIMIT non riduce i costi di calcolo.

Limitare il numero di byte fatturati per query

Best practice: utilizza l'impostazione del numero massimo di byte fatturati per limitare i costi delle query quando utilizzi il modello di prezzo on demand.

Puoi limitare il numero di byte fatturati per una query utilizzando l'impostazione Byte massimi fatturati. Quando imposti il numero massimo di byte fatturati, il numero di byte letti dalla query viene stimato prima dell'esecuzione della query. Se il numero di byte stimati supera il limite, la query non riesce senza comportare addebiti.

Per le tabelle in cluster, la stima del numero di byte fatturati per una query è un limite superiore e può essere superiore al numero effettivo di byte fatturati dopo l'esecuzione della query. Pertanto, in alcuni casi, se imposti il numero massimo di byte fatturati, una query su una tabella in cluster può non riuscire, anche se i byte fatturati effettivi non supererebbero l'impostazione del numero massimo di byte fatturati.

Se una query non va a buon fine a causa dell'impostazione del numero massimo di byte fatturati, viene restituito un errore simile al seguente:

Error: Query exceeded limit for bytes billed: 1000000. 10485760 or higher required.

Per impostare il numero massimo di byte fatturati:

  bq query --maximum_bytes_billed=1000000 \
  --use_legacy_sql=false \
  'SELECT
     word
   FROM
     `bigquery-public-data`.samples.shakespeare'

Evita di utilizzare LIMIT nelle tabelle non in cluster

Best practice: per le tabelle non in cluster, non utilizzare una clausola LIMIT come metodo di controllo dei costi.

Per le tabelle non in cluster, l'applicazione di una clausola LIMIT a una query non influisce sulla quantità di dati letti. Ti viene addebitato il costo della lettura di tutti i byte dell'intera tabella, come indicato dalla query, anche se la query restituisce solo un sottoinsieme. Con una tabella in cluster, una clausola LIMIT può ridurre il numero di byte analizzati, perché l'analisi si interrompe quando vengono analizzati blocchi sufficienti per ottenere il risultato. Ti vengono addebitati solo i byte scansionati.

Materializzare i risultati della query in fasi

Best practice: se possibile, materializza i risultati della query in più fasi.

Se crei una query di grandi dimensioni in più fasi, ogni volta che la esegui, BigQuery legge tutti i dati richiesti dalla query. Ti viene addebitato l'intero volume di dati letti ogni volta che viene eseguita la query.

Suddividi invece la query in fasi, in cui ogni fase materializza i risultati della query scrivendoli in una tabella di destinazione. L'esecuzione di query sulla tabella di destinazione più piccola riduce la quantità di dati letti e abbassa i costi. Il costo di archiviazione dei risultati materializzati è molto inferiore al costo di elaborazione di grandi quantità di dati.

Controllare i costi dei workload

Questa sezione descrive le best practice per controllare i costi all'interno di un workload. Un carico di lavoro è un insieme di query correlate. Ad esempio, un carico di lavoro può essere una pipeline di trasformazione dei dati eseguita quotidianamente, un insieme di dashboard gestite da un gruppo di analisti aziendali o diverse query ad hoc eseguite da un gruppo di data scientist.

Utilizza il Google Cloud Calcolatore prezzi

Best practice: utilizza il Google Cloud Calcolatore prezzi per creare una stima dei costi mensili complessivi per BigQuery in base all'utilizzo previsto. Puoi quindi confrontare questa stima con i costi effettivi per identificare le aree di ottimizzazione.

Utilizzare prenotazioni e impegni

Best practice: utilizza le prenotazioni e gli impegni di BigQuery per controllare i costi.

Per maggiori informazioni, consulta Limitare i costi per ogni modello di prezzo.

Utilizzare lo strumento di stima degli slot

Best practice:utilizza lo strumento per la stima degli slot per stimare il numero di slot necessari per i tuoi carichi di lavoro.

Lo strumento di stima degli slot BigQuery ti aiuta a gestire la capacità degli slot in base alle metriche delle prestazioni storiche.

Inoltre, i clienti che utilizzano il modello di prezzi on demand possono visualizzare consigli sul dimensionamento per impegni e prenotazioni di scalabilità automatica con prestazioni simili quando passano ai prezzi basati sulla capacità.

Annullare i job a esecuzione prolungata non necessari

Per liberare capacità, controlla i job a esecuzione prolungata per assicurarti che debbano continuare a essere eseguiti. In caso contrario, annullali.

Visualizzare i costi utilizzando una dashboard

Best practice:crea un dashboard per analizzare i dati di fatturazione Cloud in modo da poter monitorare e apportare modifiche all'utilizzo di BigQuery.

Puoi esportare i dati di fatturazione in BigQuery e visualizzarli in uno strumento come Looker Studio. Per un tutorial sulla creazione di una dashboard di fatturazione, consulta Visualizzare Google Cloud la fatturazione utilizzando BigQuery e Looker Studio.

Utilizzare budget e avvisi di fatturazione

Best practice:utilizza i budget di fatturazione Cloud per monitorare gli addebiti di BigQuery in un unico posto.

I budget del fatturazione Cloud ti consentono di monitorare i costi effettivi rispetto a quelli pianificati. Dopo aver impostato un importo del budget, definisci delle regole di soglia di avviso per il budget, in modo che attivino le notifiche email. Le email di avviso del budget ti aiutano a rimanere informato su come la spesa per BigQuery viene tracciata rispetto al budget.

Controllare i costi di archiviazione

Utilizza queste best practice per ottimizzare il costo dello spazio di archiviazione BigQuery. Puoi anche ottimizzare l'archiviazione per il rendimento delle query.

Utilizzare l'archiviazione a lungo termine

Best practice: utilizza i prezzi dell'archiviazione a lungo termine per ridurre i costi dei dati meno recenti.

Quando carichi i dati nell'archiviazione BigQuery, questi sono soggetti ai prezzi di archiviazione di BigQuery. Per i dati meno recenti, puoi usufruire automaticamente dei prezzi di archiviazione a lungo termine di BigQuery.

Se hai una tabella che non viene modificata per 90 giorni consecutivi, il prezzo di archiviazione per quella tabella si riduce automaticamente del 50%. Se hai una tabella partizionata, ogni partizione viene considerata separatamente per l'idoneità al prezzo a lungo termine, in base alle stesse regole delle tabelle non partizionate.

Configura il modello di fatturazione dello spazio di archiviazione

Best practice:ottimizza il modello di fatturazione dell'archiviazione in base ai tuoi pattern di utilizzo.

BigQuery supporta la fatturazione dello spazio di archiviazione utilizzando byte logici (non compressi) o fisici (compressi) oppure una combinazione di entrambi. Il modello di fatturazione dell'archiviazione configurato per ogni set di dati determina il prezzo dell'archiviazione, ma non influisce sul rendimento delle query.

Puoi utilizzare le visualizzazioni INFORMATION_SCHEMA per determinare il modello di fatturazione dell'archiviazione più adatto in base ai tuoi pattern di utilizzo.

Evitare di sovrascrivere le tabelle

Best practice: quando utilizzi il modello di fatturazione dello spazio di archiviazione fisico, evita di sovrascrivere ripetutamente le tabelle.

Quando sovrascrivi una tabella, ad esempio utilizzando il parametro --replace nei job di caricamento batch o utilizzando l'istruzione SQL TRUNCATE TABLE, i dati sostituiti vengono conservati per la durata delle finestre di time travel e di sicurezza. Se sovrascrivi spesso una tabella, ti verranno addebitati costi di archiviazione aggiuntivi.

Puoi invece caricare i dati in modo incrementale in una tabella utilizzando il parametro WRITE_APPEND nei job di caricamento, l'istruzione SQL MERGE o l'API Storage Write.

Ridurre la finestra spostamento cronologico

Best practice:in base ai tuoi requisiti, puoi ridurre la finestra di spostamento nel tempo.

La riduzione della finestra di spostamento nel tempo dal valore predefinito di sette giorni riduce il periodo di conservazione dei dati eliminati o modificati in una tabella. Lo spazio di archiviazione Time-Travel ti viene addebitato solo quando utilizzi il modello di fatturazione dello spazio di archiviazione fisico (compresso).

La finestra di spostamento cronologico è impostata a livello di set di dati. Puoi anche impostare la finestra di spostamento cronologico predefinita per i nuovi set di dati utilizzando le impostazioni di configurazione.

Utilizzare la scadenza della tabella per le tabelle di destinazione

Best practice: se stai scrivendo risultati di query di grandi dimensioni in una tabella di destinazione, utilizza il tempo di scadenza predefinito della tabella per rimuovere i dati quando non sono più necessari.

La conservazione di set di risultati di grandi dimensioni nello spazio di archiviazione BigQuery ha un costo. Se non hai bisogno di un accesso permanente ai risultati, utilizza la scadenza predefinita della tabella per eliminare automaticamente i dati.

Archivia i dati in Cloud Storage

Best practice: valuta la possibilità di archiviare i dati in Cloud Storage.

Puoi spostare i dati da BigQuery a Cloud Storage in base alle esigenze aziendali di archiviazione. Come best practice, considera i prezzi per l'archiviazione a lungo termine e il modello di fatturazione dell'archiviazione fisica prima di esportare i dati da BigQuery.

Passaggi successivi

• Scopri di più sui prezzi di BigQuery.
• Scopri come ottimizzare le query.
• Scopri come ottimizzare lo spazio di archiviazione.

• Per informazioni su fatturazione, avvisi e visualizzazione dei dati, consulta i seguenti argomenti:

  • Creare, modificare o eliminare i budget e gli avvisi relativi ai budget
  • Esportare i dati di fatturazione Cloud in BigQuery
  • Visualizzazione dei costi con Looker Studio