Ladejobs optimieren

Sie können die Limits für Ladejobs pro Tabelle in BigQuery einhalten, indem Sie Schreibvorgänge im Batch ausführen, häufige Aktualisierungen streamen und Zieltabellen partitionieren. Die täglichen Kontingente für Änderungen sind fest und können nicht erhöht werden. Wenn Sie weniger und größere Schreibvorgänge mit integrierten Client-Wiederholungen verwenden, können Sie quotaExceeded-Fehler vermeiden.

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, Daten aktualisiert 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 Auffüllrate. Wenn Sie das Limit für Tabellenvorgänge oder die Auffüllrate überschreiten, schlagen Ladejobs mit dem Fehler quotaExceeded fehl. Das Limit für Ladejobs pro Tag auf Projektebene wird innerhalb eines rollierenden Zeitraums von 24 Stunden wieder aufgefüllt. Wenn Ladejobs abgeschlossen sind, verringert sich Ihr verfügbares Kontingent. Das Kontingent wird dann in den nächsten 24 Stunden schrittweise wieder aufgefüllt. Fehlgeschlagene Ladejobs werden weiterhin auf die Kontingente pro Tabelle und pro Projekt angerechnet. Weitere Informationen zu Limits für Ladejobs finden Sie unter Ladejobs.

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

Damit Sie die Limits für tägliche Tabellenvorgänge nicht überschreiten, sollten Sie die Vorgänge über einen Zeitraum von 24 Stunden verteilen. Wenn Sie beispielsweise 25 Aktualisierungen mit jeweils 60 Vorgängen ausfü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.

Vom Kontingent ausgeschlossene Tabellenvorgänge

Das Aktualisieren von Tabelleninformationen (Metadaten) und die Verwendung von DML-Anweisungen werden nicht auf das tägliche Limit für Tabellenänderungen angerechnet. Dieser Ausschluss gilt sowohl für Standard- 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.

Streaming-Insert-Anweisungen ändern ebenfalls Tabellen, unterliegen jedoch ihren eigenen spezifischen Kontingenten.

Ladestrategien zur Vermeidung des Limits für Tabellenvorgänge

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

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

Wenn Sie diese Best Practices anwenden möchten, müssen Sie Ihre Daten im Batch oder 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 keine Rolle spielt. In den folgenden Abschnitten werden das Batchladen und das Datenstreaming im Detail erläutert, einschließlich der Tools und Dienste, die Sie für die jeweilige Methode verwenden können.

Laden im Batch

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

Mehr Daten für jeden Job laden

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

Anstatt beispielsweise für jeweils ein paar 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) angesammelt haben, und dann einen Ladejob ausführen, um alle Daten an eine Tabelle anzuhängen. Diese Aktion zählt als ein Tabellenvorgang, obwohl der Job viel mehr Daten enthält. Sie können Ihre Dateien mithilfe von Platzhaltern in Ihrem Ladejob zusammenfassen. Mit Platzhaltern können Sie mehrere Dateien in einem Verzeichnis auswählen, um sie in einem einzigen Ladejob zu laden.

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

bq

Das folgende Beispiel zeigt einen bq load-Befehl zum Laden von CSV-Daten aus Cloud Storage in eine BigQuery-Tabelle mit dem Namen my_target_table. Wenn Sie mehr als einen Quelldateinamen auswählen möchten, verwenden Sie einen Platzhalter mit dem Befehl. Mit dem Flag AUTODETECT wird das Tabellenschema automatisch aus den Quelldaten in Cloud Storage ermittelt. Außerdem 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 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. Der String gs://my-bucket/path/to/data/my_prefix_*.csv verwendet beispielsweise das Platzhalterzeichen *, 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-Abfrage LOAD DATA CSV-Daten aus einem Cloud Storage-Bucket in eine BigQuery-Tabelle 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 Ihrer 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. Der String gs://my-bucket/path/to/data/my_prefix_*.csv verwendet beispielsweise das Platzhalterzeichen *, 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-Ladevorgang mit der BigQuery Storage Write API (gRPC)

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

Die Storage Write API (gRPC) optimiert das Laden von Daten, um die Tabellenlimits einzuhalten. Verwenden Sie für Echtzeit-Streaming 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 per Commit bestätigen.

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

Batch-Ladevorgang mit Dataflow

Wenn Sie Daten mithilfe von Datenpipelines in BigQuery streamen, transformieren und 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 (gRPC) für leistungsstarkes Datenstreaming und „Genau einmal“-Semantik verwendet.

Informationen zum Batch-Laden von Daten in BigQuery mit Dataflow finden Sie unter 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. Mit dieser Strategie wird vermieden, dass das Limit für die Ausführung zu vieler Ladejobs erreicht wird. In den folgenden Abschnitten werden mehrere Methoden zum Streamen von Daten in BigQuery beschrieben.

Daten mit der Storage Write API (gRPC) streamen

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

Informationen zur Verwendung der Storage Write API (gRPC) 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 (gRPC) verwendet.

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

Best Practices zum Verwalten von Tabellen für das Laden

Zusätzlich zum 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 Datenladevorgänge ausführen müssen. Sie können die Leistung und Kosteneffizienz von Tabellen erheblich verbessern, indem Sie eine Tabelle anhand eines Datums, eines 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 Standardlimit für Tabellen ersetzt. Das Limit für partitionierte Tabellen erhöht die Anzahl der Ladejobs, die Sie pro Tag ausführen können, ohne die 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 einer einzelnen Partition interagiert, bleiben Ihre Daten mit 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 sollten sie jedoch vermeiden, wenn Ihre Partitionen durchgängig kleiner als 10 GB sind. Weitere Informationen finden Sie unter Wann Partitionierung verwendet werden sollte.

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

Integrierte Funktionen für exponentiellen Backoff, Kürzung und Jitter nutzen

Der integrierte exponentielle Backoff mit Wiederholung ist eine Methode zur Fehlerbehandlung, mit der Ihre Anwendung nach einem vorübergehenden Fehler reibungslos wiederhergestellt werden kann. Solche Fehler können ein Ratenbegrenzungsfehler (rateLimitExceeded) oder ein kurzes Netzwerkproblem (unavailable) sein.

In einem zuverlässigen System verwenden Worker, die Aufgaben aus der clientseitigen Warteschlange übernehmen, ebenfalls exponentielles Backoff und Wiederholungsversuche. Dies geschieht 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 Aufruf client.append_rows() verarbeitet diese Wiederholungsversuche automatisch.

Diese integrierte Verarbeitung ist ein wesentlicher 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.