Kosten schätzen und kontrollieren

Auf dieser Seite werden Best Practices für die Schätzung und Kontrolle von Kosten in BigQuery beschrieben.

Die primären Kosten in BigQuery sind die Kosten für die Verarbeitung von Abfragen und die Speicherung von Daten in BigQuery. BigQuery bietet zwei Arten von Preismodellen für die Abfrageverarbeitung: On-Demand- und kapazitätsbasierte Preise. Für jedes Modell gibt es unterschiedliche Best Practices zur Kostenkontrolle. Für in BigQuery gespeicherte Daten hängen die Kosten vom Abrechnungsmodell für den Speicher ab, das für jedes Dataset konfiguriert ist.

Preise für BigQuery-Computing

Es gibt geringfügige Unterschiede bei den Compute-Preisen für BigQuery, die sich auf die Kapazitätsplanung und Kostenkontrolle auswirken.

Preismodelle

Für On-Demand-Computing in BigQuery fallen Gebühren pro TiB für BigQuery-Abfragen an.

Alternativ dazu fallen für die Kapazitätsberechnung in BigQuery Gebühren für die Rechenressourcen (Slots) an, die zum Verarbeiten der Abfrage verwendet werden. Wenn Sie dieses Modell verwenden möchten, konfigurieren Sie Reservierungen für Slots.

Reservierungen haben die folgenden Funktionen:

• Sie werden in Slot-Pools zugewiesen und ermöglichen es Ihnen, die Kapazität zu verwalten und Arbeitslasten auf eine für Ihre Organisation sinnvolle Weise zu isolieren.
• Sie müssen sich in einem Administrationsprojekt befinden und unterliegen Kontingenten und Limits.

Das Kapazitätsabrechnungsmodell bietet mehrere Versionen, die alle eine Pay-as-you-go-Option enthalten, die in Slot-Stunden abgerechnet wird. In den Enterprise- und Enterprise Plus-Versionen sind auch optionale ein- oder dreijährige Slot-Zusicherungen verfügbar, mit denen Sie im Vergleich zum Pay-as-you-go-Tarif Geld sparen können.

Sie können auch Autoscaling-Reservierungen mit der Option „Pay as you go“ festlegen. Weitere Informationen nachstehend:

• Preismodelle vergleichen
• Weitere Informationen zu den Preisen finden Sie unter On-Demand-Preise für Compute und Preise für die Kapazitätsberechnung.

Kosten für jedes Modell begrenzen

Wenn Sie das On-Demand-Preismodell verwenden, können Sie Kosten nur durch die Konfiguration von Tageskontingenten auf Projekt- oder Nutzerebene begrenzen. Diese Kontingente legen jedoch eine harte Obergrenze fest, die verhindert, dass Nutzer Abfragen über das Kontingentlimit hinaus ausführen. Informationen zum Festlegen von Kontingenten finden Sie unter Benutzerdefinierte Abfragekontingente erstellen.

Wenn Sie das kapazitätsbasierte Preismodell mit Slot-Reservierungen verwenden, geben Sie die maximale Anzahl von Slots an, die für eine Reservierung verfügbar sind. Sie können auch Slot-Zusicherungen erwerben, die für einen bestimmten Zeitraum ermäßigte Preise bieten.

Sie können Versionen vollständig on demand verwenden, indem Sie die Baseline der Reservierung auf 0 und das Maximum auf eine Einstellung festlegen, die Ihren Arbeitslastanforderungen entspricht. BigQuery wird automatisch auf die Anzahl der Slots skaliert, die für Ihre Arbeitslast erforderlich sind, wobei das von Ihnen festgelegte Maximum nie überschritten wird. Weitere Informationen finden Sie unter Arbeitslastverwaltung mit Reservierungen.

Abfragekosten kontrollieren

Wenn Sie die Kosten einzelner Abfragen kontrollieren möchten, empfehlen wir, zuerst die Best Practices für die Optimierung der Abfrageberechnung und die Optimierung des Speichers zu befolgen.

In den folgenden Abschnitten werden zusätzliche Best Practices beschrieben, mit denen Sie Ihre Abfragekosten weiter kontrollieren können.

Benutzerdefinierte Kontingente für Abfragen erstellen

Best Practice:Verwenden Sie benutzerdefinierte tägliche Abfragekontingente, um die täglich verarbeitete Datenmenge zu begrenzen.

Sie können die Kosten verwalten, indem Sie ein benutzerdefiniertes Kontingent festlegen, das die Menge der pro Tag und Projekt oder pro Tag und Nutzer verarbeiteten Daten begrenzt. Nutzer können keine Abfragen ausführen, sobald das Kontingent erreicht ist.

Zum Festlegen eines benutzerdefinierten Kontingents benötigen Sie bestimmte Rollen oder Berechtigungen. Informationen zu Kontingenten, die festgelegt werden können, finden Sie unter Kontingente und Limits.

Weitere Informationen finden Sie unter Kosten für jedes Preismodell begrenzen.

Geschätzte Kosten vor dem Ausführen einer Abfrage prüfen

Best Practice: Erstellen Sie vor dem Ausführen von Abfragen eine Vorschau, um die Kosten abzuschätzen.

Bei Verwendung des On-Demand-Preismodells werden Abfragen nach der Anzahl der gelesenen Byte abgerechnet. So schätzen Sie die Kosten einer Abfrage vorab:

• Verwenden Sie die Abfragevalidierung in der Google Cloud Console.
• Führen Sie einen Probelauf für Abfragen aus.

Abfragevalidierung verwenden

Wenn Sie eine Abfrage in der Google Cloud Console eingeben, überprüft die Abfragevalidierung die Abfragesyntax und liefert die geschätzte Anzahl der gelesenen Byte. Mit dieser Information können Sie im Preisrechner die Abfragekosten einschätzen.

• Wenn die Abfrage ungültig ist, wird bei der Abfragevalidierung eine Fehlermeldung angezeigt. Beispiel:

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

• Wenn Ihre Abfrage gültig ist, gibt die Abfragevalidierung eine Schätzung der Anzahl an Byte an, die zum Verarbeiten der Abfrage erforderlich ist. Beispiel:

  This query will process 623.1 KiB when run.

Probelauf durchführen

So führen Sie einen Probelauf aus:

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))

Abfragekosten schätzen

Wenn Sie das On-Demand-Preismodell verwenden, können Sie die Kosten für die Ausführung einer Abfrage schätzen, indem Sie die Anzahl der verarbeiteten Byte berechnen.

Berechnung der On-Demand-Abfragegröße

In den folgenden Abschnitten erfahren Sie, wie die Anzahl der Byte berechnet wird, die von den verschiedenen Abfragetypen verarbeitet werden:

• DML-Anweisungen
• DDL-Anweisungen
• Geclusterte Tabellen

Keine Abfragen ausführen, um Tabellendaten zu untersuchen

Best Practice: Führen Sie keine Abfragen aus, um Tabellendaten zu entdecken oder eine Vorschau zu erstellen.

Wenn Sie mit Daten experimentieren oder diese erkunden, können Sie sie mit Tabellenvorschauoptionen kostenlos ansehen, ohne Ihr Kontingent zu nutzen.

In BigQuery stehen Ihnen die folgenden Optionen für eine Datenvorschau zur Verfügung:

• Klicken Sie in der Google Cloud Console auf der Seite mit den Tabellendetails auf den Tab Vorschau, um die Daten abzufragen.
• Verwenden Sie im bq-Befehlszeilentool den Befehl bq head und geben Sie die Anzahl der Zeilen für die Vorschau an.
• Verwenden Sie in der API tabledata.list zum Abrufen von Tabellendaten aus einer bestimmten Gruppe von Zeilen.
• Verwenden Sie LIMIT nicht in nicht geclusterten Tabellen. Bei nicht geclusterten Tabellen werden die Rechenkosten durch eine LIMIT-Klausel nicht gesenkt.

Anzahl der pro Abfrage berechneten Byte einschränken

Best Practice:Verwenden Sie die Einstellung für maximal berechnete Bytes, um die Abfragekosten zu begrenzen, wenn Sie das On-Demand-Preismodell verwenden.

Sie können die Anzahl der berechneten Bytes für eine Abfrage mit der Einstellung für maximal berechnete Bytes begrenzen. Wenn Sie einen maximalen Wert für die berechneten Byte festlegen, wird die Anzahl der Byte, die von der Abfrage gelesen werden, vor der Abfrageausführung geschätzt. Wenn die Anzahl der geschätzten Byte die Grenze überschreitet, schlägt die Abfrage fehl, ohne dass eine Gebühr anfällt.

Bei geclusterten Tabellen liegt die Schätzung der Anzahl der Byte, die für eine Abfrage in Rechnung gestellt werden, über eine Obergrenze und kann höher sein als die tatsächliche Anzahl von Byte, die nach Ausführen der Abfrage in Rechnung gestellt werden. Wenn Sie eine Höchstmenge für abgerechnete Byte festlegen, kann die Abfrage einer geclusterten Tabelle fehlschlagen, selbst wenn die tatsächlich abgerechneten Byte die festgelegte Höchstmenge nicht überschreiten würden.

Wenn eine Abfrage aufgrund der Einstellung für maximal abgerechnete Byte fehlschlägt, wird ein Fehler wie der folgende zurückgegeben:

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

So legen Sie die maximal berechneten Byte fest:

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

LIMIT nicht in nicht geclusterten Tabellen verwenden

Best Practice: Verwenden Sie für nicht geclusterte Tabellen nicht die LIMIT-Klausel zur Kostenkontrolle.

Bei nicht geclusterten Tabellen hat die Anwendung einer LIMIT-Klausel auf eine Abfrage keine Auswirkungen auf die Menge der gelesenen Daten. Ihnen werden damit also alle von der Abfrage in der kompletten Tabelle gelesenen Byte in Rechnung gestellt, auch wenn die Abfrage nur eine Teilmenge zurückgibt. Bei einer geclusterten Tabelle kann eine LIMIT-Klausel die Anzahl der gescannten Byte reduzieren, da der Scan beendet wird, wenn genügend Blöcke gescannt wurden, um das Ergebnis zu erhalten. Ihnen werden nur die gescannten Byte in Rechnung gestellt.

Abfrageergebnisse in Phasen erfassen

Best Practice: Erfassen Sie Abfrageergebnisse nach Möglichkeit in separaten Phasen.

Wenn Sie eine große Abfrage mit mehreren Phasen erstellen, liest BigQuery jedes Mal, wenn Sie diese ausführen, alle Daten, auf die sich die Abfrage bezieht. Bei jeder Ausführung der Abfrage werden Ihnen alle gelesenen Daten in Rechnung gestellt.

Teilen Sie stattdessen Ihre Abfrage in Phasen auf, wobei jede Phase ihre Abfrageergebnisse in eine Zieltabelle schreibt. Durch das Abfragen der kleineren Zieltabelle verringert sich die Menge der gelesenen Daten und die Kosten sinken. Der finanzielle Aufwand für die Speicherung der erfassten Ergebnisse ist deutlich geringer als der für die Verarbeitung großer Datenmengen.

Arbeitslastkosten kontrollieren

In diesem Abschnitt werden Best Practices zur Kostenkontrolle innerhalb einer Arbeitslast beschrieben. Eine Arbeitslast ist eine Gruppe zusammengehöriger Abfragen. Eine Arbeitslast kann beispielsweise eine Datenumwandlungspipeline sein, die täglich ausgeführt wird, eine Reihe von Dashboards, die von einer Gruppe von Business-Analysten ausgeführt werden, oder mehrere Ad-hoc-Abfragen, die von einer Gruppe von Data Scientists ausgeführt werden.

Google Cloud Preisrechner verwenden

Best Practice:Mit dem Google Cloud Preisrechner können Sie die monatlichen Gesamtkosten für BigQuery anhand der voraussichtlichen Nutzung schätzen. Anschließend können Sie diese Schätzung mit Ihren tatsächlichen Kosten vergleichen, um Optimierungsmöglichkeiten zu ermitteln.

Reservierungen und Zusicherungen verwenden

Best Practice:Verwenden Sie BigQuery-Reservierungen und -Zusicherungen, um die Kosten zu kontrollieren.

Weitere Informationen finden Sie unter Kosten für jedes Preismodell begrenzen.

Slot-Schätzer verwenden

Best Practice:Verwenden Sie den Slot-Estimator, um die Anzahl der für Ihre Arbeitslasten erforderlichen Slots zu schätzen.

Mit dem BigQuery-Slot-Schätzer können Sie die Slotkapazität auf der Grundlage historischer Leistungsmesswerte verwalten.

Außerdem können Kunden, die das On-Demand-Preismodell verwenden, bei einem Wechsel zur kapazitätsbasierten Abrechnung Größenempfehlungen für Zusicherungen und Autoscaling-Reservierungen mit ähnlicher Leistung aufrufen.

Unnötige lange laufende Jobs abbrechen

Prüfen Sie, ob Jobs mit langer Ausführungszeit weiterhin ausgeführt werden sollen, um Kapazität freizugeben. Falls nicht, kündigen Sie sie.

Kosten in einem Dashboard ansehen

Best Practice:Erstellen Sie ein Dashboard, um Ihre Cloud Billing-Daten zu analysieren und die Nutzung von BigQuery zu überwachen und anzupassen.

Sie können Ihre Abrechnungsdaten nach BigQuery exportieren und sie in einem Tool wie Looker Studio visualisieren. Eine Anleitung zum Erstellen eines Abrechnungs-Dashboards finden Sie unter Google Cloud -Abrechnung mit BigQuery und Looker Studio visualisieren.

Budgets und Benachrichtigungen verwenden

Best Practice:Verwenden Sie Cloud Billing-Budgets, um Ihre BigQuery-Gebühren zentral zu überwachen.

Mit Cloud Billing-Budgets können Sie Ihre tatsächlichen Kosten mit Ihren geplanten Kosten vergleichen. Nachdem Sie einen Budgetbetrag festgelegt haben, legen Sie Schwellenwertregelungen für die Budgetbenachrichtigungen fest, die zum Auslösen von E-Mail-Benachrichtigungen verwendet werden. Mit E-Mail-Benachrichtigungen zu Budgets können Sie sich informieren, wie sich Ihre BigQuery-Ausgaben im Verhältnis zum Budget entwickeln.

Speicherkosten kontrollieren

Mit diesen Best Practices können Sie die Kosten für BigQuery-Speicher optimieren. Sie können den Speicher auch für die Abfrageleistung optimieren.

Langfristige Speicherung verwenden

Best Practice:Verwenden Sie die Preise für die langfristige Speicherung, um die Kosten für ältere Daten zu senken.

Wenn Sie Daten in den BigQuery-Speicher laden, unterliegen die Daten den Speicherpreisen von BigQuery. Für ältere Daten können Sie automatisch die günstigen Kosten der Langzeitspeicherung von BigQuery nutzen.

Wenn Sie eine Tabelle haben, die 90 Tage lang nicht bearbeitet wurde, sinkt der Speicherpreis für diese Tabelle automatisch um 50 %. Bei einer partitionierten Tabelle wird jede Partition separat betrachtet, um für die Langzeitpreise in Frage zu kommen, und zwar nach den gleichen Regeln wie bei nicht partitionierten Tabellen.

Speicherabrechnungsmodell konfigurieren

Best Practice:Optimieren Sie das Abrechnungsmodell für den Speicher basierend auf Ihren Nutzungsmustern.

BigQuery unterstützt die Abrechnung der Speicherung mit logischen (unkomprimierten) oder physischen (komprimierten) Byte oder einer Kombination aus beidem. Das für jedes Dataset konfigurierte Speicherabrechnungsmodell bestimmt Ihre Speicherpreise, hat aber keine Auswirkungen auf die Abfrageleistung.

Mithilfe der INFORMATION_SCHEMA-Ansichten können Sie das Speicherabrechnungsmodell ermitteln, das basierend auf Ihren Nutzungsmustern am besten geeignet ist.

Tabellen nicht überschreiben

Best Practice:Wenn Sie das Abrechnungsmodell für physischen Speicher verwenden, sollten Sie Tabellen nicht wiederholt überschreiben.

Wenn Sie eine Tabelle überschreiben, z. B. mit dem Parameter --replace in Batch-Ladejobs oder mit der SQL-Anweisung TRUNCATE TABLE, werden die ersetzten Daten für die Dauer des Time Travel- und Failsafe-Zeitraums aufbewahrt. Wenn Sie eine Tabelle häufig überschreiben, fallen zusätzliche Speichergebühren an.

Stattdessen können Sie Daten inkrementell in eine Tabelle laden. Verwenden Sie dazu den Parameter WRITE_APPEND in Ladejobs, die SQL-Anweisung MERGE oder die Storage Write API.

Zeitreisefenster verkürzen

Best Practice:Je nach Anforderung können Sie das Zeitreisefenster verkleinern.

Wenn Sie das Zeitreisefenster vom Standardwert von sieben Tagen verringern, wird der Aufbewahrungszeitraum für Daten verkürzt, die aus einer Tabelle gelöscht oder in einer Tabelle geändert wurden. Die Speicherung von Zeitreisen wird Ihnen nur in Rechnung gestellt, wenn Sie das physische (komprimierte) Speicherabrechnungsmodell verwenden.

Das Zeitreisefenster wird auf Dataset-Ebene festgelegt. Sie können das Standardzeitreisefenster für neue Datasets auch mit Konfigurationseinstellungen festlegen.

Tabellenablauf für Zieltabellen verwenden

Best Practice: Wenn Sie große Abfrageergebnisse in eine Zieltabelle schreiben, verwenden Sie am besten die Standardablaufzeit von Tabellen, um die Daten zu löschen, sobald sie nicht mehr benötigt werden.

Das Aufbewahren großer Ergebnissets im BigQuery-Speicher ist teuer. Wenn Sie die Ergebnisse nicht dauerhaft benötigen, sollten Sie die Daten durch Festlegen der Standardablaufzeit von Tabellen automatisch löschen lassen.

Daten in Cloud Storage archivieren

Best Practice: Archivieren Sie Daten eventuell in Cloud Storage.

Sie können Daten basierend auf den geschäftlichen Anforderungen für die Archivierung von BigQuery zu Cloud Storage verschieben. Als Best Practice sollten Sie die Preise für die langfristige Speicherung und das Abrechnungsmodell für physischen Speicher in Betracht ziehen, bevor Sie Daten aus BigQuery exportieren.

Nächste Schritte

• Informationen zu BigQuery-Preisen
• Abfragen optimieren
• Speicher optimieren

• Informationen zu Abrechnung, zu Benachrichtigungen und zur Visualisierung von Daten finden Sie in den folgenden Themen:

  • Budgets und Budgetbenachrichtigungen erstellen, bearbeiten oder löschen
  • Cloud Billing-Daten nach BigQuery exportieren
  • Kosten mit Looker Studio visualisieren