Ladejobs optimieren

Die in diesem Dokument beschriebenen Strategien und Best Practices helfen Ihnen, das Batch-Laden oder Streamen von Daten in BigQuery zu optimieren, um das Tageslimit für die Anzahl der Ladejobs pro Tabelle nicht zu überschreiten.

Da das Limit für Ladejobs festgelegt ist und nicht erhöht werden kann, sollten Sie Ihre Ladejobs optimieren, indem Sie Ihre Tabellen mithilfe von Methoden wie Tabellenpartitionen strukturieren oder Ihre Ladevorgänge mithilfe von Methoden wie Batch-Laden oder Streaming verwalten.

Funktionsweise von Kontingenten für Tabellenvorgänge

Das BigQuery-Limit für Tabellenänderungen pro Tabelle und Tag pro Projekt ist fest, unabhängig davon, ob durch die Änderungen Daten angefügt oder aktualisiert werden oder die Tabelle gekürzt wird. Dieses Limit umfasst die Gesamtzahl aller Ladejobs, Kopierjobs und Abfragejobs, die Daten an eine Zieltabelle anfügen oder eine Zieltabelle überschreiben.

Für Ladejobs gilt eine Nachfüllrate. Wenn Sie das Limit für Tabellenvorgänge oder die Nachfüllrate überschreiten, schlagen Ladejobs mit dem Fehler quotaExceeded fehl. Das Limit für Ladejobs pro Tag auf Projektebene wird innerhalb eines rollierenden 24-Stunden-Zeitraums aufgefüllt. Wenn Ladejobs abgeschlossen sind, verringert sich Ihr verfügbares Kontingent. Das Kontingent wird dann in den nächsten 24 Stunden nach und nach wieder aufgefüllt. Fehlgeschlagene Ladejobs werden weiterhin auf Kontingente pro Tabelle und pro Projekt angerechnet. Weitere Informationen zu den Limits für Ladejobs finden Sie unter Ladejobs.

Für partitionierte Tabellen gilt ein separates Limit für Änderungen an partitionierten Tabellen, das das Standardtabellenlimit ersetzt.

Um die täglichen Limits für Tabellenvorgänge nicht zu überschreiten, sollten Sie die Vorgänge über einen Zeitraum von 24 Stunden verteilen. Wenn Sie beispielsweise 25 Aktualisierungen mit jeweils 60 Vorgängen durchführen, können Sie etwa alle 58 Minuten 60 Vorgänge ausführen. So können Sie das Tageslimit einhalten. Informationen zum Überwachen von Tabellenaktualisierungen finden Sie unter BigQuery-INFORMATION_SCHEMA-Ansichten.

Tabellenvorgänge, die nicht auf das Kontingent angerechnet werden

Das Aktualisieren von Tabelleninformationen (Metadaten) und die Verwendung von DML-Anweisungen werden nicht auf Ihr tägliches Limit für Tabellenänderungen angerechnet. Dieser Ausschluss gilt sowohl für Standardtabellen als auch für partitionierte Tabellen.

Ihr Projekt kann eine unbegrenzte Anzahl von DML-Anweisungen ausführen. DML-Anweisungen wurden bisher auf die täglichen Tabellenänderungen angerechnet und auch bei Erreichen des Limits nicht gedrosselt. Das ist jetzt nicht mehr der Fall.

Auch Streaming-Einfügungen ändern Tabellen, unterliegen aber eigenen Kontingenten.

Strategien zum Laden, um das Limit für Tabellenvorgänge zu vermeiden

Wenn Sie das tägliche Tabellenvorgangslimit von BigQuery nicht überschreiten möchten, sollten Sie die folgenden Best Practices beachten:

• Führen Sie weniger, dafür aber größere Schreibvorgänge aus, anstatt viele kleine.
• Minimieren Sie die Anzahl der separaten Schreibjobs, die täglich in Ihre endgültige Produktionstabelle geschrieben werden.

Wenn Sie diese Best Practices nutzen möchten, müssen Sie Ihre Daten in Batches oder als Stream in BigQuery laden. Die Wahl der Lademethode hängt davon ab, ob Sie große Datenmengen in Echtzeit laden müssen oder ob das Laden in Echtzeit nicht wichtig ist. In den folgenden Abschnitten werden das Batch-Laden und das Datenstreaming im Detail beschrieben, einschließlich der Tools und Dienste, die Sie für die einzelnen Methoden verwenden können.

Laden im Batch

Um das tägliche Ladegrenzwert pro Projekt für BigQuery nicht zu überschreiten, sollten Sie große Datenmengen in Batches aufteilen und mit weniger Jobs in BigQuery laden. In den folgenden Abschnitten werden verschiedene Methoden zum Batch-Laden Ihrer Daten beschrieben.

Mehr Daten für jeden Job laden

Anstatt Daten jedes Mal an BigQuery zu senden, wenn neue Informationen verfügbar sind, sollten Sie sie mit einem einzigen großen Job erfassen und in BigQuery laden.

Anstatt beispielsweise für jede Gruppe von wenigen Datenzeilen einen separaten Ladejob auszuführen, können Sie warten, bis Sie mehrere Tausend Datenzeilen in einer Datei (z. B. in einer CSV- oder JSON-Datei) gesammelt haben, und dann einen Ladejob ausführen, um alle Daten an eine Tabelle anzuhängen. Dieser Vorgang zählt als ein Tabellenvorgang, auch wenn der Job viel mehr Daten enthält. Sie können Ihre Dateien in Batches verarbeiten, indem Sie Platzhalter in Ihrem Ladejob verwenden. Mit Platzhaltern können Sie Gruppen von Dateien in einem Verzeichnis auswählen, um mehrere Dateien in einem einzigen Ladevorgang zu laden.

Im folgenden Beispiel wird gezeigt, wie Sie Platzhalter mit dem Befehl bq load oder mit SQL-Abfragen LOAD DATA verwenden.

bq

Im folgenden Beispiel wird gezeigt, wie Sie mit dem bq load-Befehl CSV-Daten aus Cloud Storage in eine BigQuery-Tabelle namens my_target_table laden. Wenn Sie mehrere Quelldateinamen auswählen möchten, verwenden Sie einen Platzhalter mit dem Befehl. Mit dem Flag AUTODETECT wird das Tabellenschema automatisch anhand der Quelldaten in Cloud Storage bestimmt. Es kann ein Platzhalter (*) verwendet werden, um mehrere Dateien, die einem bestimmten Namensmuster entsprechen, in die BigQuery-Tabelle zu laden.

bq load \
  --source_format=CSV \
  --autodetect \
  --project_id=PROJECT_ID \
  DATASET_NAME.TABLE_NAME \
  "gs://BUCKET_NAME/OBJECT_PATH_WILDCARD"

Ersetzen Sie Folgendes:

• PROJECT_ID: Die ID Ihres Projekts in Google Cloud .
• DATASET_NAME: Der Name des BigQuery-Datasets, in das Sie die Daten laden möchten.
• TABLE_NAME: Der Name der BigQuery-Tabelle, in die Sie die Daten laden möchten.
• BUCKET_NAME: Der Name des Cloud Storage-Bucket, der die Quelldateien enthält.
• OBJECT_PATH_WILDCARD: Der Pfad zu Ihren CSV-Dateien im Cloud Storage-Bucket. Fügen Sie einen Platzhalter (*) ein, um mehrere Dateien abzugleichen. Im String gs://my-bucket/path/to/data/my_prefix_*.csv wird beispielsweise das Platzhalterzeichen * verwendet, um alle Dateien in gs://my-bucket/path/to/data/ zu laden, die mit my_prefix_ beginnen und mit .csv enden.

Hier finden Sie weitere Informationen:

• Unterstützung von Platzhaltern für Cloud Storage-URIs
• Referenz zum bq-Befehlszeilentool

SQL

Im folgenden Beispiel wird gezeigt, wie Sie mit der SQL-LOAD DATA-Abfrage CSV-Daten aus einem Cloud Storage-Bucket in eine BigQuery-Tabelle laden. Wenn Sie mehrere Quelldateien auswählen möchten, verwenden Sie ein Platzhalterzeichen mit dem Befehl.

LOAD DATA INTO
DATASET_NAME.TABLE_NAME
FROM FILES (
  format = 'SOURCE_FORMAT',
  uris = ['gs://BUCKET_NAME/OBJECT_PATH_WILDCARD]
  );

Ersetzen Sie Folgendes:

• DATASET_NAME: Der Name des BigQuery-Datasets, in das Sie die Daten laden möchten.
• TABLE_NAME: Der Name der BigQuery-Tabelle, in die Sie die Daten laden möchten.
• Mit SOURCE_FORMAT wird der Typ Ihrer Quelldateien festgelegt, z. B. CSV oder JSON. Verwenden Sie in diesem Beispiel CSV.
• BUCKET_NAME: Der Name des Cloud Storage-Bucket, der die Quelldateien enthält.
• OBJECT_PATH_WILDCARD: Der Pfad zu Ihren CSV-Dateien im Cloud Storage-Bucket. Fügen Sie einen Platzhalter (*) ein, um mehrere Dateien abzugleichen. Im String gs://my-bucket/path/to/data/my_prefix_*.csv wird beispielsweise das Platzhalterzeichen * verwendet, um alle Dateien in gs://my-bucket/path/to/data/ zu laden, die mit my_prefix_ beginnen und mit .csv enden.

Weitere Informationen finden Sie unter LOAD-Anweisungen in GoogleSQL.

Batch-Laden mit der BigQuery Storage Write API

Wenn Sie Batchdaten in BigQuery laden möchten, können Sie die Storage Write API direkt aus Ihrer Anwendung mit den Google API-Clientbibliotheken verwenden.

Die Storage Write API optimiert das Laden von Daten, um die Tabellengrenzwerte einzuhalten. Verwenden Sie für Streaming in Echtzeit mit hohem Volumen einen PENDING-Stream anstelle eines COMMITTED-Streams. Wenn Sie einen PENDING-Stream verwenden, speichert die API Datensätze vorübergehend, bis Sie den Stream festschreiben.

Ein vollständiges Beispiel für das Batchladen von Daten mit der Storage Write API finden Sie unter Daten im Batch mit der Storage Write API laden.

Batch-Laden mit Dataflow

Wenn Sie Daten mithilfe von Datenpipelines streamen, transformieren und in BigQuery schreiben möchten, können Sie Dataflow verwenden. Die von Ihnen erstellten Datenpipelines lesen Daten aus unterstützten Quellen wie Pub/Sub oder Apache Kafka. Sie können auch eine Dataflow-Pipeline mit dem BigQueryIO-Connector erstellen, der die Storage Write API für leistungsstarkes Datenstreaming und „Genau einmal“-Semantik verwendet.

Informationen zum Batchladen von Daten in BigQuery mit Dataflow finden Sie unter Mit Dataflow Daten in BigQuery schreiben.

Datenstreaming

Wenn Sie große Datenmengen mit häufigen Aktualisierungen laden möchten, empfehlen wir, die Daten in BigQuery zu streamen. Beim Datenstreaming werden neue Daten kontinuierlich von Ihrer Clientanwendung in BigQuery geschrieben. So wird vermieden, dass das Limit für die Ausführung zu vieler Ladejobs erreicht wird. In den folgenden Abschnitten werden verschiedene Methoden zum Streamen von Daten in BigQuery beschrieben.

Daten mit der Storage Write API streamen

Verwenden Sie die Storage Write API, um Datensätze in Echtzeit mit minimaler Latenz in BigQuery zu streamen. Die Storage Write API bietet ein effizientes Streamingprotokoll mit erweiterten Funktionen wie der Semantik genau einer Übermittlung, der Erkennung von Schemaaktualisierungen und Streaming-CDC-Upserts (Change Data Capture). Darüber hinaus können Sie bis zu 2 TiB pro Monat kostenlos aufnehmen.

Informationen zur Verwendung der Storage Write API finden Sie unter Daten mit der Storage Write API streamen.

Daten mit Dataflow streamen

Mit Dataflow können Sie Datenpipelines erstellen, die aus unterstützten Quellen wie Pub/Sub oder Apache Kafka lesen. Diese Pipelines transformieren die Daten und schreiben sie in BigQuery als Ziel. Sie können eine Dataflow-Pipeline mit dem BigQueryIO-Connector erstellen, der die Storage Write API verwendet.

Informationen zum Streamen von Daten mit Dataflow in BigQuery finden Sie unter Aus Dataflow in BigQuery schreiben.

Best Practices für die Verwaltung von Tabellen zum Laden

Neben dem Batch-Laden oder Streamen von Daten in BigQuery können Sie Ihre Tabellen auf folgende Weise verwalten, um sie für die Datenerfassung zu optimieren.

Partitionierte Tabellen verwenden

Tabellenpartitionierung ist eine leistungsstarke Methode zum Verwalten großer Tabellen in BigQuery, insbesondere wenn Sie häufig Daten laden müssen. Sie können die Leistung und Kosteneffizienz von Tabellen erheblich verbessern, indem Sie sie anhand eines Datums, Zeitstempels oder einer Ganzzahl in kleinere, besser verwaltbare Segmente unterteilen.

Der Hauptvorteil der Partitionierung beim Laden von Daten besteht darin, dass die täglichen Kontingente für Tabellenvorgänge für BigQuery auf Partitionsebene und nicht auf Tabellenebene gelten. Für partitionierte Tabellen gilt ein separates, höheres Limit für Partitionsänderungen, das das Standardtabellenlimit ersetzt. Das Limit für partitionierte Tabellen erhöht die Anzahl der Ladejobs, die Sie pro Tag ausführen können, ohne Kontingentlimits zu erreichen, erheblich.

Eine gängige und sehr effektive Strategie ist das Batch-Laden Ihrer täglichen Daten. Sie können beispielsweise alle Daten des Tages für 2025-09-18 in einer temporären Staging-Tabelle erfassen. Am Ende des Tages führen Sie dann einen einzelnen Job aus, um diese Daten in die spezifische Partition für diesen Tag in Ihrer Hauptproduktionstabelle zu laden. Da BigQuery nur mit den Daten für eine einzelne Partition interagiert, bleiben Ihre Daten bei diesem Ansatz gut organisiert und Ihre Ladevorgänge werden schneller und kostengünstiger.

Die Partitionierung wird für große, wachsende Tabellen dringend empfohlen. Sie sollte jedoch vermieden werden, wenn Ihre Partitionen durchgehend kleiner als 10 GB sind. Weitere Informationen finden Sie unter Wann sollte die Partitionierung verwendet werden?.

Weitere Informationen zu den verschiedenen verfügbaren Partitionierungsmethoden, z. B. nach Zeiteinheit und nach Ganzzahlbereich, finden Sie unter Arten von partitionierten Tabellen.

Integrierte Funktionen für exponentiellen Backoff, Abschneiden und Jitter nutzen

Der integrierte exponentielle Backoff und die Wiederholung sind eine Methode zur Fehlerbehandlung, mit der sich Ihre Anwendung reibungslos erholen kann, wenn ein Vorgang vorübergehend fehlschlägt. Zu solchen Fehlern kann es beispielsweise aufgrund eines Ratenbegrenzungsfehlers (rateLimitExceeded) oder eines kurzen Netzwerkproblems (unavailable) kommen.

In einem zuverlässigen System verwenden Worker, die Aufgaben aus Ihrer clientseitigen Warteschlange übernehmen, auch exponentiellen Backoff und Wiederholungen. Das erfolgt beim Aufrufen von BigQuery, wodurch zwei Schutzebenen entstehen.

Die offizielle google-cloud-bigquery-storage-Bibliothek für Python enthält beispielsweise eine integrierte Wiederholungslogik mit exponentiellem Backoff. Diese Logik verarbeitet temporäre gRPC-Fehler, z. B. UNAVAILABLE. In den meisten Fällen müssen Sie diesen Wiederholungscode nicht selbst schreiben. Der client.append_rows()-Aufruf verarbeitet diese Wiederholungsversuche automatisch.

Diese integrierte Verarbeitung ist ein wichtiger Vorteil der Verwendung der offiziellen Clientbibliotheken. Sie müssen sich nur um Fehler kümmern, die nicht wiederholt werden können, z. B. INVALID_ARGUMENT, was bedeutet, dass ein Schemakonflikt vorliegt.