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 Erreichen des Limits für die Anzahl der Ladejobs pro Tabelle und Tag zu vermeiden.

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

Kontingente für Tabellenvorgänge

Das BigQuery-Limit für Tabellenänderungen pro Tabelle und Tag pro Projekt ist festgelegt, 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, Kopier- jobs und Abfragejobs, die an eine Zieltabelle angefügt werden oder diese ü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 auf Projektebene für Ladejobs pro Tag wird innerhalb eines rollierenden 24-Stunden-Zeitraums nachgefüllt. Wenn Ladejobs abgeschlossen sind, verringert sich Ihr verfügbares Kontingent. Das Kontingent wird dann in den nächsten 24 Stunden schrittweise nachgefüllt. Fehlgeschlagene Ladejobs werden sowohl auf die Kontingente pro Tabelle als auch auf die Kontingente 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, verteilen Sie die Vorgänge auf einen Zeitraum von 24 Stunden. Wenn Sie beispielsweise 25 Aktualisierungen mit jeweils 60 Vorgängen ausführen, können Sie etwa alle 58 Minuten 60 Vorgänge ausführen. Mit diesem Ansatz 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 das tägliche Limit für Tabellenänderungen angerechnet. Diese Ausnahme gilt sowohl für Standardtabellen als auch für partitionierte Tabellen.

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

Streaming-Einfügungen ändern ebenfalls Tabellen, sie unterliegen jedoch eigenen spezifischen Kontingenten.

Ladestrategien, um das Limit für Tabellenvorgänge zu vermeiden

Beachten Sie die folgenden Best Practices, um das tägliche Limit für Tabellenvorgänge in BigQuery nicht zu überschreiten:

• Führen Sie weniger, aber größere Schreibvorgänge anstelle vieler kleiner Schreibvorgänge aus.
• Minimieren Sie die Anzahl der separaten Schreibjobs für Ihre endgültige Produktionstabelle pro Tag.

Um diese Best Practices zu nutzen, laden Sie Ihre Daten im Batch oder streamen Sie sie in BigQuery. Die Wahl der Lademethode hängt davon ab, ob Sie große Datenmengen in Echtzeit laden müssen oder ob das Laden in Echtzeit keine Rolle spielt. In den folgenden Abschnitten werden das Batch-Laden und das Datenstreaming ausführlich erläutert, einschließlich der Tools und Dienste, die Sie für die einzelnen Methoden verwenden können.

Laden im Batch

Um das tägliche Limit für Ladevorgänge pro Projekt für BigQuery nicht zu überschreiten, laden Sie große Datenmengen im Batch und mit weniger Jobs in BigQuery. In den folgenden Abschnitten werden mehrere Methoden beschrieben, mit denen Sie Ihre Daten im Batch laden können.

Mehr Daten pro Job laden

Anstatt Daten jedes Mal an BigQuery zu senden, wenn neue Informationen verfügbar sind, können Sie sie erfassen und mit einem einzigen großen Job 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 gesammelt haben, z. B. in einer CSV- oder JSON-Datei. Führen Sie dann einen Ladejob aus, um alle Daten an eine Tabelle anzuhängen. Dieser Vorgang wird als ein Tabellenvorgang gezählt, obwohl der Job viel mehr Daten enthält. Sie können Ihre Dateien im Batch verarbeiten, indem Sie Platzhalter mit Ihrem Ladejob verwenden. Mit Platzhaltern können Sie Batches von Dateien in einem Verzeichnis auswählen, um mehrere Dateien in einem einzigen Ladejob zu laden.

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

bq

Im folgenden Beispiel wird ein bq load Befehl zum Laden von CSV-Daten aus Cloud Storage in eine BigQuery-Tabelle mit dem Namen my_target_table gezeigt. Wenn Sie mehr als einen Quelldateinamen auswählen möchten, verwenden Sie einen Platzhalter mit dem Befehl. Das Flag AUTODETECT bestimmt das Tabellenschema automatisch aus den Quelldaten in Cloud Storage und kann einen Platzhalter (*) unterstützen, um mehrere Dateien, die einem bestimmten Benennungsmuster 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 Google Cloud Projekts in.
• 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 Ihres 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. Die String gs://my-bucket/path/to/data/my_prefix_*.csv verwendet beispielsweise den Platzhalter *, 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 die SQL LOAD DATA Abfrage verwenden, um CSV-Daten aus einem Cloud Storage-Bucket in eine BigQuery-Tabelle zu laden. Wenn Sie mehr als einen Quelldateinamen auswählen möchten, verwenden Sie einen Platzhalter 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 der Quelldateien festgelegt, z. B. CSV oder JSON. Verwenden Sie in diesem Beispiel CSV.
• BUCKET_NAME: der Name Ihres 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. Die String gs://my-bucket/path/to/data/my_prefix_*.csv verwendet beispielsweise den Platzhalter *, 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

Eine Möglichkeit, Batch-Daten in BigQuery zu laden, besteht darin, die Storage Write API direkt aus Ihrer Anwendung mit den Google API-Clientbibliotheken zu verwenden.

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

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

Batch-Laden mit Dataflow

Wenn Sie Daten mit Datenpipelines streamen, transformieren und in BigQuery schreiben möchten, können Sie Dataflow verwenden. Die von Ihnen erstellten Datenpipelines lesen 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 Datenstreaming mit hoher Leistung und genau einmaliger Semantik verwendet.

Informationen zum Batch-Laden von Daten in BigQuery mit Dataflow finden Sie unter Daten aus Dataflow 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 zu viele Ladejobs erreicht wird. In den folgenden Abschnitten werden mehrere 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 genau einmaliger Übermittlungssemantik, Erkennung von Schemaaktualisierungen und Streaming-CDC-Upserts (Change Data Capture). Außerdem 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 dann in BigQuery. Sie können eine Dataflow-Pipeline mit dem BigQueryIO-Connector erstellen, der die Storage Write API verwendet.

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

Best Practices zum Verwalten von Tabellen für das 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 Datenaufnahme zu optimieren.

Partitionierte Tabellen verwenden

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

Der Hauptvorteil der Partitionierung für das 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 Standardtabellenlimitersetzt. Das Limit für partitionierte Tabellen erhöht die Anzahl der Ladejobs, die Sie pro Tag ausführen können, erheblich, ohne dass Sie Kontingentlimits erreichen.

Eine gängige und äußerst 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 entsprechende Partition für diesen Tag in Ihrer Hauptproduktionstabelle zu laden. Da BigQuery nur mit den Daten für eine einzelne Partition interagiert, sind Ihre Daten gut organisiert und Ihre Ladevorgänge schneller und kostengünstiger.

Die Partitionierung wird für große, wachsende Tabellen dringend empfohlen. Sie sollten sie jedoch vermeiden, wenn Ihre Partitionen immer kleiner als 10 GB sind. Weitere Informationen finden Sie unter Wann sollte partitioniert werden?.

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

Integrierte Funktionen für exponentiellen Backoff, Kürzen 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. Solche Fehler können ein Limitfehler (rateLimitExceeded) oder ein kurzes Netzwerkproblem (unavailable) sein.

In einem zuverlässigen System verwenden Worker, die Aufgaben aus der Warteschlange auf Clientseite übernehmen, ebenfalls exponentiellen Backoff und Wiederholung. Sie tun dies 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 wie UNAVAILABLE. In den meisten Fällen müssen Sie diesen Wiederholungscode nicht selbst schreiben. Der Aufruf client.append_rows() verarbeitet diese Wiederholungen automatisch.

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