Kosten schätzen und kontrollieren

Auf dieser Seite werden Best Practices zur Schätzung und Kontrolle der Kosten in BigQuery beschrieben.

Die Hauptkosten in BigQuery sind die Rechenleistung, die für die Abfrageverarbeitung verwendet wird, und der Speicher für Daten, die in BigQuery gespeichert werden. BigQuery bietet zwei Arten von Preismodellen für die Abfrageverarbeitung: On-Demand- und kapazitätsbasierte Preise. Für jedes Modell gelten andere Best Practices zur Kostenkontrolle. Bei in BigQuery gespeicherten Daten hängen die Kosten vom Abrechnungsmodell für Speicher ab, das für jedes Dataset konfiguriert ist.

Computing-Preise für BigQuery

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

Preismodelle

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

Alternativ fallen für die BigQuery-Kapazitätsberechnung Gebühren für die Rechenressourcen (Slots) an, die zur Verarbeitung 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 so zu isolieren, wie es für Ihre Organisation sinnvoll ist.
  • Sie müssen sich in einem Administrationsprojekt befinden und unterliegen Kontingenten und Limits.

Das Kapazitätspreismodell bietet mehrere Versionen, die alle eine „Pay as you go“-Option bieten, die in Slot-Stunden abgerechnet wird. Die Enterprise- und Enterprise Plus-Versionen bieten auch optionale Slot-Zusicherungen für ein oder drei Jahre, 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:

Kosten für jedes Modell einschränken

Wenn Sie das On-Demand-Preismodell verwenden, können Sie die Kosten nur durch die Konfiguration von täglichen Kontingenten auf Projektebene oder Nutzerebene begrenzen. Diese Kontingente erzwingen jedoch eine feste Obergrenze, 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 Slotzusicherungen erwerben, die für einen bestimmten Zeitraum Rabatte 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 skaliert automatisch bis zur Anzahl der Slots, die für Ihre Arbeitslast erforderlich sind, und überschreitet dabei nie das von Ihnen festgelegte Maximum. 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 weitere Best Practices beschrieben, mit denen Sie Ihre Abfragekosten weiter kontrollieren können.

Benutzerdefinierte Abfragekontingente erstellen

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

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

Zum Festlegen eines benutzerdefinierten Kontingents benötigen Sie bestimmte Rollen oder Berechtigungen. Informationen zu den festzulegenden Kontingenten finden Sie unter Kontingente und Limits.

Weitere Informationen finden Sie unter Kosten für jedes Preismodell einschränken.

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.

Beim On-Demand-Preismodell werden Abfragen abhängig von der Anzahl der gelesenen Byte in Rechnung gestellt. Mit einer der folgenden Möglichkeiten können Sie die Kosten einer Abfrage vorab schätzen:

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:

Console

  1. Wechseln Sie zur BigQuery-Seite.

    BigQuery aufrufen

  2. Geben Sie Ihre Abfrage in den Abfrageeditor ein.

    Wenn die Abfrage gültig ist, wird automatisch ein Häkchen zusammen mit der Datenmenge angezeigt, die durch die Abfrage verarbeitet wird. Wenn die Abfrage ungültig ist, wird ein Ausrufezeichen mit einer Fehlermeldung angezeigt.

bq

Geben Sie eine Abfrage wie die folgende zusammen mit dem Flag --dry_run ein:

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

Bei einer gültigen Abfrage gibt der Befehl die folgende Antwort zurück:

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

API

Für einen Probelauf über die API übergeben Sie einen Abfragejob, bei dem im JobConfiguration-Typ dryRun auf true gesetzt ist.

Go

Bevor Sie dieses Beispiel anwenden, folgen Sie den Schritten zur Einrichtung von Go in der BigQuery-Kurzanleitung zur Verwendung von Clientbibliotheken. Weitere Angaben finden Sie in der Referenzdokumentation zur BigQuery Go API.

Richten Sie zur Authentifizierung bei BigQuery die Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für Clientbibliotheken einrichten. 

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
}

Java

Bevor Sie dieses Beispiel anwenden, folgen Sie den Schritten zur Einrichtung von Java in der BigQuery-Kurzanleitung zur Verwendung von Clientbibliotheken. Weitere Angaben finden Sie in der Referenzdokumentation zur BigQuery Java API.

Richten Sie zur Authentifizierung bei BigQuery die Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für Clientbibliotheken einrichten. 

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());
    }
  }
}

Node.js

Bevor Sie dieses Beispiel anwenden, folgen Sie den Schritten zur Einrichtung von Node.js in der BigQuery-Kurzanleitung zur Verwendung von Clientbibliotheken. Weitere Angaben finden Sie in der Referenzdokumentation zur BigQuery Node.js API.

Richten Sie zur Authentifizierung bei BigQuery die Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für Clientbibliotheken einrichten. 

// 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);
}

PHP

Bevor Sie dieses Beispiel anwenden, folgen Sie den Schritten zur Einrichtung von PHP in der BigQuery-Kurzanleitung zur Verwendung von Clientbibliotheken. Weitere Angaben finden Sie in der Referenzdokumentation zur BigQuery PHP API.

Richten Sie zur Authentifizierung bei BigQuery die Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für Clientbibliotheken einrichten. 

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']);

Python

Setzen Sie das Attribut QueryJobConfig.dry_run auf True. Client.query() gibt immer einen abgeschlossenen QueryJob zurück, wenn die Abfrage für einen Probelauf konfiguriert ist.

Bevor Sie dieses Beispiel ausprobieren, folgen Sie der Python-Einrichtungsanleitung in der BigQuery-Kurzanleitung zur Verwendung von Clientbibliotheken. Weitere Angaben finden Sie in der Referenzdokumentation zur BigQuery Python API.

Richten Sie zur Authentifizierung bei BigQuery die Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für Clientbibliotheken einrichten. 

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

Je nach Preismodell für die Rechenleistung unterscheidet sich die Methode zur Schätzung der Abfragekosten.

Kostenschätzung für On-Demand-Abfragen

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.

Kapazitätsbasierte Schätzung der Abfragekosten

Wenn Sie kapazitätsbasierte Preise verwenden, ist es nicht möglich, die genauen Kosten einer einzelnen Abfrage vor der Ausführung genau zu schätzen. Kapazitätsbasierte Kosten werden anhand der gesamten Reservierungs-Slot-Kapazität berechnet, die im Laufe der Zeit bereitgestellt oder automatisch skaliert wird, und nicht anhand der Datenmenge, die von einer bestimmten Abfrage gescannt wird.

Die Schätzung der Kosten einzelner Abfragen vor der Ausführung ist aufgrund dynamischer Laufzeitfaktoren schwierig, darunter:

  • Dynamische Slotzuweisung: Die Anzahl der Slots, die einer Abfrage zugewiesen werden, hängt von der Komplexität der Abfrage, der Laufzeitoptimierung und der Ressourcenverfügbarkeit ab.
  • Nebenläufigkeit: Mehrere Abfragen teilen sich dynamisch die in der Reservierung verfügbaren Slots.
  • Autoscaling-Verhalten: Wenn Slot-Autoscaling aktiviert ist, wird die Reservierung basierend auf der aggregierten Arbeitslastanforderung und nicht auf der Ausführung einzelner Abfragen hoch- und herunterskaliert.

Nach der Abfrageausführung können Sie die tatsächlichen Rechenressourcen, die von der Abfrage in Slot-Millisekunden (total_slot_ms) verbraucht wurden, in den Details zur Abfrageausführung oder durch Abfragen der Ansicht INFORMATION_SCHEMA.JOBS einsehen.

Kapazitätsbasierte Kostenzuordnung

Bei der Kostenzuordnung werden die Computing-Kosten für Reservierungen nach der Ausführung von Arbeitslasten auf Projekte, Teams oder Abfragen aufgeteilt und zugeordnet.

Wenn Sie Ihre Gesamtkosten nachvollziehen und zuordnen möchten, können Sie Reservierungsgebühren mithilfe der Zuordnung von Reservierungskosten in Cloud Billing-Daten bestimmten Abfragen und Projekten zuordnen. Suchen Sie in Ihren Cloud Billing-Daten und -Berichten nach der Werbebuchung Analyse-Slots-Attribution, in der die pro Projekt verwendeten Slot-Stunden erfasst werden, ohne dass zusätzliche Kosten anfallen oder sich die Rechnungssumme ändert.

Weitere Informationen finden Sie unter Kostenzuordnung für Reservierungen.

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:

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 Tabellen-Detailseite 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 reduziert.

Anzahl der pro Abfrage abgerechneten 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:

Console

  1. Klicken Sie im Abfrageeditor auf Bearbeiten > Abfrageeinstellungen > Erweiterte Optionen.
  2. Geben Sie im Feld Maximale Menge abgerechneter Byte eine Ganzzahl ein.
  3. Klicken Sie auf Speichern.

bq

Führen Sie den Befehl bq query mit dem Flag --maximum_bytes_billed aus.

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

API

Legen Sie das Attribut maximumBytesBilled in JobConfigurationQuery oder QueryRequest fest.

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.

Rapid Cache zum Abfragen von Cloud Storage mit externen Tabellen verwenden

Best Practice: Aktivieren Sie Rapid Cache, wenn Sie Cloud Storage-Daten mit externen Tabellen abfragen.

Rapid Cache bietet einen SSD-gestützten zonalen Lesecache für Ihre Cloud Storage-Buckets, der die Abfrageleistung verbessern und die Abfragekosten beim Abfragen externer Tabellen senken kann. Weitere Informationen finden Sie unter Abfragen für externe Cloud Storage-Tabellen optimieren.

Arbeitslastkosten kontrollieren

In diesem Abschnitt werden Best Practices zur Kostenkontrolle innerhalb einer Arbeitslast beschrieben. Eine Arbeitslast ist eine Reihe zusammengehöriger Abfragen. Eine Arbeitslast kann beispielsweise eine täglich ausgeführte Datentransformationspipeline, eine Reihe von Dashboards, die von einer Gruppe von Geschäftsanalysten ausgeführt werden, oder mehrere Ad-hoc-Abfragen sein, 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 Bereiche mit Optimierungspotenzial zu identifizieren.

On demand

So schätzen Sie die Kosten im Google Cloud -Preisrechner, wenn Sie das On-Demand-Preismodell verwenden:

  1. Öffnen Sie den Google Cloud -Preisrechner.
  2. Klicken Sie auf Der Schätzung hinzufügen.
  3. Wählen Sie „BigQuery“ aus.
  4. Wählen Sie für Diensttyp die Option „On-Demand“ aus.
  5. Wählen Sie den Standort aus, an dem Ihre Abfragen ausgeführt werden sollen.
  6. Geben Sie bei Abgefragte Datenmenge die geschätzten Byte ein, die beim Probelauf oder bei der Abfragevalidierung gelesen werden.
  7. Geben Sie Ihre geschätzten Speichernutzung für Aktiver Speicher, Langfristiger Speicher, Streaming-Insert-Anweisungen und Streaming-Lesevorgänge ein. Sie müssen je nach Abrechnungsmodell für die Dataset-Speicherung nur den physischen Speicher oder nur den logischen Speicher schätzen.
  8. Die Schätzung wird im Bereich Kostendetails angezeigt. Wenn Sie weitere Informationen zu den geschätzten Kosten erhalten möchten, klicken Sie auf Detailansicht öffnen. Sie können die Kostenschätzung auch herunterladen und freigeben.

Weitere Informationen finden Sie unter On-Demand-Preise.

Versionen

Führen Sie die folgenden Schritte aus, um die Kosten im Google Cloud -Preisrechner zu schätzen, wenn Sie das kapazitätsbasierte Preismodell mit BigQuery-Versionen verwenden:

  1. Öffnen Sie den Google Cloud -Preisrechner.
  2. Klicken Sie auf Der Schätzung hinzufügen.
  3. Wählen Sie „BigQuery“ aus.
  4. Wählen Sie für Diensttyp die Option „Versionen“ aus.
  5. Wählen Sie den Standort aus, an dem die Slots verwendet werden.
  6. Gewünschte Version auswählen
  7. Wählen Sie die Maximale Anzahl von Slots, Referenz-Slots, optional Zusicherung und Geschätzte Auslastung des Autoscalings aus.
  8. Wählen Sie den Speicherort für die Daten aus.
  9. Geben Sie Ihre geschätzten Speichernutzung für Aktiver Speicher, Langfristiger Speicher, Streaming-Insert-Anweisungen und Streaming-Lesevorgänge ein. Sie müssen je nach Abrechnungsmodell für die Dataset-Speicherung nur den physischen Speicher oder nur den logischen Speicher schätzen.
  10. Die Schätzung wird im Bereich Kostendetails angezeigt. Wenn Sie weitere Informationen zu den geschätzten Kosten erhalten möchten, klicken Sie auf Detailansicht öffnen. Sie können die Kostenschätzung auch herunterladen und freigeben.

Weitere Informationen finden Sie unter Kapazitätsbasierte Preise.

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 einschränken.

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 bisheriger Leistungsmesswerte verwalten.

Darüber hinaus können Kunden, die das On-Demand-Preismodell verwenden, Größenempfehlungen für Zusicherungen und Autoscaling-Reservierungen mit ähnlicher Leistung aufrufen, wenn sie zu kapazitätsbasierten Preisen wechseln.

Nicht benötigte Jobs mit langer Ausführungszeit abbrechen

Prüfen Sie Jobs mit langer Ausführungszeit, um sicherzustellen, dass sie weiterhin ausgeführt werden sollen, und schaffen Sie Kapazität. Falls nicht, brechen Sie sie ab.

Kosten in einem Dashboard einsehen

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 Data Studio visualisieren. Eine Anleitung zum Erstellen eines Abrechnungs-Dashboards finden Sie unter Google Cloud -Abrechnung mit BigQuery und Data Studio visualisieren.

Abrechnungsbudgets 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

Verwenden Sie diese Best Practices, um die Kosten für BigQuery-Speicher zu optimieren. Sie können auch den Speicher für die Abfrageleistung optimieren.

Langzeitspeicher verwenden

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

Wenn Sie Daten in den BigQuery-Speicher laden, unterliegen die Daten den BigQuery-Speicherpreisen. 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.

Beachten Sie, dass Tabellen und Tabellenpartitionen, die sich im Langzeitspeicher befinden, durch Änderungen an Daten, Metadaten oder Partitionierung wieder in den aktiven BigQuery-Speicher verschoben werden können. Im Folgenden finden Sie Beispiele für Aktionen, die zu dieser Verschiebung führen können:

  • Anweisungen zum Einfügen, Aktualisieren, Kürzen, Zusammenführen oder Löschen, die Tabellendaten ändern

  • Daten in die Tabelle laden, streamen oder an sie anhängen

  • ALTER-Anweisungen, die das Tabellenschema ändern

  • Tabellenattribute wie Beschreibung, Labels oder Ablauf hinzufügen oder ändern

  • Tabellenmetadaten ändern

Speicherabrechnungsmodell konfigurieren

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

BigQuery unterstützt die Abrechnung von Speicherplatz 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.

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

Überschreiben von Tabellen vermeiden

Best Practice: Wenn Sie das Abrechnungsmodell für physischen Speicher verwenden, sollten Sie das wiederholte Überschreiben von Tabellen vermeiden.

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 der Zeitreise- und Fail-Safe-Fenster aufbewahrt. Wenn Sie eine Tabelle häufig überschreiben, fallen zusätzliche Speicherkosten 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 sieben Tage verringern, wird die Aufbewahrungsdauer für Daten, die aus einer Tabelle gelöscht oder in einer Tabelle geändert wurden, reduziert. Die Speicherung mit Zeitreise wird Ihnen nur in Rechnung gestellt, wenn Sie das Abrechnungsmodell für physischen (komprimierten) Speicher verwenden.

Das Zeitreisefenster wird auf Dataset-Ebene festgelegt. Sie können das Standard-Zeitreisefenster für neue Datasets auch über die 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 Langzeitspeicherung und das Abrechnungsmodell für physischen Speicher berücksichtigen, bevor Sie Daten aus BigQuery exportieren.

Fehlerbehebung bei BigQuery-Kostenabweichungen und unerwarteten Gebühren

So beheben Sie Probleme mit unerwarteten BigQuery-Gebühren oder Kostendiskrepanzen:

  1. Wenn Sie im Cloud-Abrechnungsbericht nachvollziehen möchten, woher die Kosten für BigQuery stammen, sollten Sie die Kosten nach SKU gruppieren. So können Sie die Nutzung und die Kosten für die entsprechenden BigQuery-Dienste leichter nachvollziehen.

  2. Sehen Sie sich danach die Preise für die entsprechenden SKUs auf der SKU-Dokumentationsseite oder auf der Seite Pricing in der Cloud Billing-Benutzeroberfläche an, um zu erfahren, um welches Feature es sich handelt, z. B. BigQuery Storage Read API, Langzeitspeicherung, On-Demand-Preise, Standard-Edition.

  3. Nachdem Sie die entsprechenden SKUs identifiziert haben, können Sie die INFORMATION_SCHEMA-Ansichten verwenden, um die spezifischen Ressourcen zu identifizieren, die mit diesen Gebühren verbunden sind. Beispiel:

Wichtige Hinweise zur Fehlerbehebung:

  • Beachten Sie, dass ein täglicher Zeitraum im Cloud Billing-Bericht um Mitternacht Pacific Time (UTC-8; USA und Kanada) beginnt und dem Sommerzeitwechsel der USA folgt. Passen Sie Ihre Berechnungen und Datenaggregationen an dieselben Zeiträume an.

  • Wenn Sie die Cloud Billing-Benutzeroberfläche mit dem Cloud Billing-Datenexport nach BigQuery vergleichen, achten Sie darauf, dass Sie die Aggregation anhand von usage_start_time und usage_end_time und nicht anhand von export_time vornehmen.

  • Filtern Sie nach Projekt, wenn mehrere Projekte mit dem Rechnungskonto verknüpft sind und Sie die Kosten für ein bestimmtes Projekt prüfen möchten.

  • Achten Sie darauf, bei Prüfungen die richtige Region auszuwählen.

Ihr Projekt hat das Kontingent für kostenlose Abfragebyte überschritten

BigQuery gibt diesen Fehler zurück, wenn Sie eine Abfrage in der kostenlosen Nutzungsstufe ausführen und das Konto das monatliche Abfragelimit erreicht. Weitere Informationen zu den Preisen für Abfragen finden Sie unter Kostenlose Nutzungsstufe.

Fehlermeldung 

Your project exceeded quota for free query bytes scanned

Lösung

Sie müssen das Konto auf ein kostenpflichtiges Cloud-Rechnungskonto aktualisieren, um BigQuery weiterhin verwenden zu können.

Die Fehlerbehebung bei unerwarteten Gebühren im Zusammenhang mit der Jobausführung hängt von der Ursache dieser Gebühren ab:

  • Wenn Sie einen Anstieg der On-Demand-Analysekosten feststellen, kann dies mit einer Zunahme der Anzahl der gestarteten Jobs oder mit einer Änderung der Datenmenge zusammenhängen, die von Jobs verarbeitet werden muss. Untersuchen Sie dies mit der Ansicht INFORMATION_SCHEMA.JOBS.
  • Wenn die Gebühren für zugesicherte Slots steigen, können Sie INFORMATION_SCHEMA.CAPACITY_COMMITMENT_CHANGES abfragen, um festzustellen, ob neue Zusicherungen erworben oder geändert wurden.
  • Wenn die Gebühren für die Reservierungsnutzung steigen, prüfen Sie die Änderungen an Reservierungen, die in INFORMATION_SCHEMA.RESERVATION_CHANGES aufgezeichnet sind. Wenn Sie die Nutzung von Autoscaling-Reservierungen mit Abrechnungsdaten abgleichen möchten, folgen Sie dem Autoscaling-Beispiel.

Abgerechnete Slot-Stunden sind größer als die in der Ansicht INFORMATION_SCHEMA.JOBS berechneten Slot-Stunden

Wenn Sie eine Autoscaling-Reservierung verwenden, wird die Abrechnung anhand der Anzahl der skalierten Slots berechnet, nicht anhand der Anzahl der verwendeten Slots. BigQuery skaliert automatisch in Vielfachen von 50 Slots. Dies führt dazu, dass das nächste Vielfache in Rechnung gestellt wird, auch wenn weniger als die automatisch skalierte Menge tatsächlich verwendet wird. Das Autoscaling hat standardmäßig einen Mindestzeitraum von einer Minute vor dem Herunterskalieren. Das bedeutet, dass mindestens eine Minute in Rechnung gestellt wird, auch wenn die Slots für die Abfrage weniger lang verwendet wurden, z. B. nur 10 Sekunden der Minute. Wenn Sie diese Gebühren vermeiden möchten, können Sie die fluide Skalierung von BigQuery auf Reservierungsebene aktivieren. Dadurch wird die Abrechnung pro Sekunde ohne Mindestdauer ermöglicht. Die richtige Methode zum Schätzen der Kosten für eine Autoscaling-Reservierung ist auf der Seite „Slot-Autoscaling“ dokumentiert. Weitere Informationen zur effizienten Verwendung von Autoscaling finden Sie unter Best Practices für Autoscaling.

Ein ähnliches Szenario wird bei Reservierungen ohne Autoscaling beobachtet: Die Abrechnung erfolgt nach der Anzahl der bereitgestellten Slots, nicht nach der Anzahl der verwendeten Slots. Wenn Sie die Kosten für eine Reservierung ohne Autoscaling schätzen möchten, können Sie die Ansicht RESERVATIONS_TIMELINE direkt abfragen.

Die Abrechnung ist geringer als die Gesamtzahl der abgerechneten Byte, die über INFORMATION_SCHEMA.JOBS für ein Projekt berechnet wurden, in dem On-Demand-Abfragen ausgeführt werden.

Es kann mehrere Gründe dafür geben, dass die tatsächliche Abrechnung geringer ist als die berechneten verarbeiteten Byte:

  • Für jedes Projekt ist pro Monat 1 TB an Abfragen im Rahmen der kostenlosen Stufe ohne Aufpreis verfügbar.
  • Jobs vom Typ SCRIPT wurden nicht von der Berechnung ausgeschlossen, was dazu führen kann, dass einige Werte zweimal gezählt werden.
  • Verschiedene Arten von Einsparungen, die auf Ihr Cloud-Rechnungskonto angewendet werden, z. B. ausgehandelte Rabatte, Startguthaben und andere. Sehen Sie sich den Abschnitt „Einsparungen“ im Cloud-Abrechnungsbericht an. Die kostenlose Stufe von 1 TB Abfragen pro Monat ist hier ebenfalls enthalten.

Die Abrechnung ist höher als die verarbeiteten Byte, die über INFORMATION_SCHEMA.JOBS für ein Projekt berechnet wurden, in dem On-Demand-Abfragen ausgeführt werden.

Wenn der Abrechnungsbetrag höher ist als der Wert, den Sie durch Abfragen der Ansicht INFORMATION_SCHEMA.JOBS berechnet haben, kann das folgende Ursachen haben:

  • Abfragen von Tabellen mit Sicherheit auf Zeilenebene

    • Abfragen für Tabellen mit Sicherheit auf Zeilenebene erzeugen keinen Wert für total_bytes_billed in der Ansicht INFORMATION_SCHEMA.JOBS. Daher ist die Abrechnung, die mit total_bytes_billed aus der Ansicht INFORMATION_SCHEMA.JOBS berechnet wird, niedriger als der abgerechnete Wert. Weitere Informationen dazu, warum diese Informationen nicht sichtbar sind, finden Sie auf der Seite Best Practices für die Sicherheit auf Zeilenebene.

  • ML-Vorgänge in BigQuery ausführen

    • Die BigQuery ML-Preise für On-Demand-Abfragen hängen vom Typ des erstellten Modells ab. Einige dieser Modellvorgänge werden zu einem höheren Preis als Nicht-ML-Abfragen berechnet. Wenn Sie also einfach alle total_billed_bytes für das Projekt addieren und den standardmäßigen On-Demand-Preis pro TB verwenden, ist dies keine korrekte Preisaggregation. Sie müssen den Preisunterschied pro TB berücksichtigen.

  • Falsche Preisangaben

    • Prüfen Sie, ob die richtigen Preise pro TB in den Berechnungen verwendet werden. Achten Sie darauf, die richtige Region auszuwählen, da die Preise standortabhängig sind. Weitere Informationen finden Sie in der Dokumentation zu Preisen.

Wir empfehlen, die On-Demand-Jobnutzung für die Abrechnung gemäß der Anleitung in unserer öffentlichen Dokumentation zu berechnen.

Abrechnung für die Nutzung der BigQuery Reservations API, obwohl die API deaktiviert ist und keine Reservierungen oder Zusicherungen verwendet werden

Prüfen Sie die SKU, um besser zu verstehen, welche Dienste in Rechnung gestellt werden. Wenn die abgerechnete SKU BigQuery Governance SKU ist, handelt es sich um Gebühren von Knowledge Catalog. Einige Knowledge Catalog-Funktionen lösen Jobausführungen über BigQuery aus. Diese Gebühren werden jetzt unter der entsprechenden BigQuery Reservations API-SKU verarbeitet. Weitere Informationen finden Sie in der Dokumentation zu den Knowledge Catalog-Preisen.

Das Projekt ist einer Reservierung zugewiesen, aber es fallen weiterhin On-Demand-Kosten für die BigQuery-Analyse an

Lesen Sie den Abschnitt Probleme mit Reservierungen beheben, um herauszufinden, woher die Analysis-Gebühren stammen könnten.

Unerwartete Gebühren für Pay-as-you-go-Slots (PAYG) für die BigQuery Standard-Version

Wenden Sie im Cloud Billing-Abrechnungsbericht einen Filter mit dem Label goog-bq-feature-type und dem Wert BQ_STUDIO_NOTEBOOK an. Die Nutzung wird als Pay-as-you-go-Slots im Rahmen der BigQuery Standard-Version gemessen. Dies sind Gebühren für die Nutzung des BigQuery Studio-Notebooks. Weitere Informationen zu den Preisen für BigQuery Studio-Notebooks

Unerwartete Gebühren für Pay-as-you-go-Slots (PAYG) für die BigQuery Enterprise-Version

Wenden Sie im Cloud Billing-Abrechnungsbericht einen Filter mit dem Label goog-bq-feature-type und dem Wert SPARK_PROCEDURE an. Die Nutzung wird als Pay as you go-Slots unter der BigQuery Enterprise-Version gemessen. Dies sind Gebühren für die Verwendung der BigQuery Apache Spark-Prozeduren, die unabhängig vom im Projekt verwendeten Rechenmodell auf diese Weise abgerechnet werden.

Gebühren für die BigQuery Reservation API, die nach der Deaktivierung der Reservation API anfallen

Wenn Sie BigQuery deaktivieren, werden die Zusicherungsgebühren nicht gestoppt. Wenn Sie die Gebühren für Zusicherungen beenden möchten, müssen Sie eine Zusicherung löschen. Legen Sie den Verlängerungstarif auf NONE fest. Die Zusicherung wird dann automatisch gelöscht, wenn sie abläuft.

Die Abfrage sehr kleiner Tabellen führt zu unverhältnismäßig hohen Kosten für On-Demand-Abfragen.

Die Mindestmenge an „verarbeiteten Daten pro referenzierter Tabelle“, die für eine BigQuery-Abfrage in Rechnung gestellt wird, beträgt 10 MiB, unabhängig von der tatsächlichen Größe der Tabelle. Ebenso beträgt die Mindestmenge an abgerechneten „verarbeiteten Daten pro Abfrage“ 10 MiB. Wenn Sie kleine Tabellen abfragen, auch Tabellen mit einer Größe von nur wenigen KB, werden Ihnen für jede Abfrage mindestens 10 MiB in Rechnung gestellt. Dies kann zu viel höheren Gebühren als Ihren On-Demand-Abrechnungsschätzungen führen und ist besonders teuer für On-Demand-Computing-Preise.

Unerwartete Speichergebühren

Szenarien, die zu einer Erhöhung der Speichergebühren führen können:

Das Löschen von Tabellen oder Datasets hat zu höheren BigQuery-Speicherkosten geführt

Mit der BigQuery-Zeitreisefunktion werden gelöschte Daten für die Dauer des konfigurierten Zeitreisefensters und weitere 7 Tage für die Fail-Safe-Wiederherstellung aufbewahrt. Während dieses Aufbewahrungszeitraums tragen die gelöschten Daten in Datasets mit dem Abrechnungsmodell für physischen Speicher zu den Kosten für den aktiven physischen Speicher bei, obwohl die Tabellen nicht mehr in INFORMATION_SCHEMA.TABLE_STORAGE oder in der Console angezeigt werden. Wenn sich die Tabellendaten im Langzeitspeicher befanden, werden sie durch das Löschen in den aktiven physischen Speicher verschoben. Dadurch steigen die entsprechenden Kosten, da aktive physische Byte gemäß der Seite mit BigQuery-Speicherpreisen etwa doppelt so teuer sind wie langfristige physische Byte. Um die Kosten für das Löschen von Daten bei Datasets mit dem Abrechnungsmodell für physischen Speicher zu minimieren, wird empfohlen, das Zeitreisefenster auf 2 Tage zu reduzieren.

Speicherkosten ohne Änderungen an den Daten reduziert

In BigQuery zahlen Nutzer für aktiven und langfristigen Speicher. Gebühren für aktiven Speicher fallen für alle Tabellen oder Tabellenpartitionen an, die in den letzten 90 Tagen geändert wurden. Gebühren für langfristigen Speicher fallen für Tabellen und Partitionen an, die in den letzten 90 Tagen nicht geändert wurden. Eine Reduzierung der Gesamtspeicherkosten ist zu beobachten, wenn Daten in den Langzeitspeicher verschoben werden, der etwa 50% günstiger ist als der aktive Speicher. Weitere Informationen finden Sie unter Speicherpreise.

Speicherkosten sind gestiegen, ohne dass die Datenmenge nennenswert zugenommen hat

Die Speicherkosten können steigen, wenn Daten im Langzeitspeicher aufgrund bestimmter Aktionen für Tabellendaten, Metadaten oder Partitionen in den aktiven BigQuery-Speicher verschoben werden. Weitere Informationen finden Sie unter Langzeitspeicher verwenden.

INFORMATION_SCHEMA-Speicherberechnungen stimmen nicht mit der Abrechnung überein

  • Verwenden Sie die Ansicht INFORMATION_SCHEMA.TABLE_STORAGE_USAGE_TIMELINE anstelle von INFORMATION_SCHEMA.TABLE_STORAGE. TABLE_STORAGE_USAGE_TIMELINE liefert genauere und detailliertere Daten, um die Speicherkosten korrekt zu berechnen.
  • Die Abfragen, die für INFORMATION_SCHEMA-Ansichten ausgeführt werden, enthalten keine Steuern, Korrekturen und Rundungsfehler. Berücksichtigen Sie dies beim Vergleichen der Daten. Weitere Informationen zu Berichten in Cloud Billing finden Sie auf dieser Seite.
  • Die in den INFORMATION_SCHEMA-Ansichten dargestellten Daten sind in UTC angegeben, während die Berichtsdaten im Abrechnungsbericht in der Pacific Time (UTC-8; USA und Kanada) angegeben sind.

Nächste Schritte