Kontingent- und Limitfehler beheben

BigQuery hat verschiedene Kontingente und Limits, die die Rate und das Volumen verschiedener Anfragen und Vorgänge begrenzen. Sie dienen sowohl zum Schutz der Infrastruktur als auch zum Schutz vor einer unerwarteten Nutzung durch Kunden. In diesem Dokument wird beschrieben, wie Sie bestimmte Fehler aufgrund von Kontingenten und Limits diagnostizieren und abmildern können.

Wenn Ihre Fehlermeldung in diesem Dokument nicht aufgeführt ist, finden Sie in der Liste der Fehlermeldungen allgemeinere Fehlerinformationen.

Übersicht

Wenn ein BigQuery-Vorgang fehlschlägt, weil ein Kontingent überschritten wird, gibt die API den HTTP-Statuscode 403 Forbidden zurück. Der Antworttext enthält weitere Informationen zu dem erreichten Kontingent. Der Antworttext sieht etwa so aus:

{
  "code" : 403,
  "errors" : [ {
    "domain" : "global",
    "message" : "Quota exceeded: ...",
    "reason" : "quotaExceeded"
  } ],
  "message" : "Quota exceeded: ..."
}

Das Feld message in der Nutzlast beschreibt, welches Limit überschritten wurde. Das Feld message kann beispielsweise Exceeded rate limits: too many table update operations for this table enthalten.

Im Allgemeinen fallen Kontingentlimits in zwei Kategorien. Diese werden durch das Feld reason in der Antwortnutzlast angegeben.

  • rateLimitExceeded. Dieser Wert steht für ein kurzfristiges Limit. Wiederholen Sie den Vorgang nach einigen Sekunden, um diese Limitprobleme zu beheben. Verwenden Sie einen exponentiellen Backoff zwischen Wiederholungsversuchen. Erhöhen Sie also das Zeitintervall zwischen den einzelnen Wiederholungen exponentiell.

  • quotaExceeded. Dieser Wert gibt ein längerfristiges Limit an. Wenn Sie ein längerfristiges Kontingentlimit erreichen, sollten Sie mindestens 10 Minuten warten, bevor Sie den Vorgang wiederholen. Wenn Sie ständig eines dieser längerfristigen Kontingentlimits erreichen, sollten Sie Ihre Arbeitslast analysieren, um das Problem zu beheben. Sie können Arbeitslasten optimieren oder eine Erhöhung des Kontingents anfordern.

Bei Fehlern vom Typ quotaExceeded können Sie in der Fehlermeldung nachsehen, welches Kontingent überschritten wurde. Analysieren Sie dann Ihre Arbeitslast, um zu ermitteln, ob Sie ein Erreichen des Kontingents vermeiden können.

In einigen Fällen kann das Kontingent erhöht werden. Wenden Sie sich dazu an den BigQuery-Support oder an den Google Cloud-Vertrieb. Wir empfehlen jedoch, es zuerst mit den Vorschlägen in diesem Dokument zu versuchen.

Diagnose

So diagnostizieren Sie Probleme:

  • Analysieren Sie das zugrunde liegende Problem mithilfe von INFORMATION_SCHEMA-Ansichten. Diese Ansichten enthalten Metadaten zu Ihren BigQuery-Ressourcen, einschließlich Jobs, Reservierungen und Streaming-Insert-Anweisungen.

    Die folgende Abfrage verwendet beispielsweise die Ansicht INFORMATION_SCHEMA.JOBS, um alle kontingentbezogenen Fehler des letzten Tages aufzulisten:

    SELECT
 job_id,
 creation_time,
 error_result
FROM `region-us`.INFORMATION_SCHEMA.JOBS
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY) AND
      error_result.reason IN ('rateLimitExceeded', 'quotaExceeded')

  • Rufen Sie Fehler in Cloud-Audit-Logs auf.

    Mit der folgenden Abfrage im Log-Explorer werden beispielsweise Fehler mit entweder Quota exceeded oder limit im Nachrichtenstring zurückgegeben:

    resource.type = ("bigquery_project" OR "bigquery_dataset")
protoPayload.status.code ="7"
protoPayload.status.message: ("Quota exceeded" OR "limit")

    In diesem Beispiel gibt der Statuscode 7 PERMISSION_DENIED an, was dem HTTP-Statuscode 403 entspricht.

    Weitere Cloud-Audit-Logs-Abfragebeispiele finden Sie unter BigQuery-Abfragen.

Fehler in Abfragewarteschlangen

Wenn ein Projekt versucht, interaktivere oder Batchabfragen in der Warteschlange zu verwenden, als das Warteschlangenlimit zulässt, kann dieser Fehler auftreten.

Fehlermeldung

Quota exceeded: Your project and region exceeded quota for
max number of jobs that can be queued per project.

Lösung

So beheben Sie diesen Kontingentfehler:

  • Job anhalten. Wenn Sie einen Prozess oder einen Workflow ermitteln, der für eine Zunahme der Abfragen verantwortlich ist, pausieren Sie diesen Prozess oder Workflow.

  • Verwenden Sie Jobs mit Batchpriorität. Sie können mehr Batchabfragen in die Warteschlange stellen als interaktive Abfragen.

  • Abfragen verteilen. Organisieren und verteilen Sie die Last auf verschiedene Projekte, basierend auf der Art der Abfragen und Ihren Geschäftsanforderungen.

  • Laufzeiten verteilen: Verteilen Sie die Last über einen größeren Zeitraum. Wenn Ihre Berichtslösung viele Abfragen ausführen muss, versuchen Sie, eine gewisse Zufälligkeit einzuführen, wenn Abfragen gestartet werden. Starten Sie beispielsweise nicht alle Berichte gleichzeitig.

  • Verwenden Sie die BigQuery BI Engine. Wenn dieser Fehler bei der Verwendung eines BI-Tools zur Erstellung von Dashboards, die Daten in BigQuery abfragen, aufgetreten ist, empfehlen wir Ihnen die BigQuery BI Engine. Die Verwendung von BigQuery BI Engine ist für diesen Anwendungsfall optimal.

  • Optimieren Sie Abfragen und Datenmodell. Häufig kann eine Abfrage neu geschrieben werden, damit sie effizienter ausgeführt wird. Wenn Ihre Abfrage beispielsweise einen CTE (Common Table Expression)-WITH enthält, auf den an mehreren Stellen in der Abfrage verwiesen wird, wird diese Berechnung mehrmals ausgeführt. Es ist besser, von der CTE durchgeführte Berechnungen in einer temporären Tabelle beizubehalten und dann in der Abfrage darauf zu verweisen.

    Mehrere Joins können auch die Ursache mangelnder Effizienz sein. In diesem Fall sollten Sie verschachtelte und wiederkehrende Spalten verwenden. Dadurch kann die Lokalität der Daten verbessert und auf einige Joins verzichtet werden. Außerdem werden der Ressourcenverbrauch und die Abfragelaufzeit insgesamt reduziert.

    Die Optimierung von Abfragen macht sie günstiger. Wenn Sie also den kapazitätbasierten Preis verwenden, können Sie mehr Abfragen mit Ihren Slots ausführen. Weitere Informationen finden Sie unter Einführung in die Optimierung der Abfrageleistung.

  • Optimieren Sie das Abfragemodell. BigQuery ist keine relationale Datenbank. Es ist nicht für eine unbegrenzte Anzahl kleiner Abfragen optimiert. Wenn Sie eine große Anzahl kleiner Abfragen ausführen, sind Ihre Kontingente schnell aufgebraucht. Solche Abfragen werden nicht so effizient ausgeführt wie bei kleineren Datenbankprodukten. BigQuery ist ein großes Data Warehouse, was der primäre Anwendungsfall ist. Es funktioniert am besten mit analytischen Abfragen über große Datenmengen.

  • Daten dauerhaft speichern (gespeicherte Tabellen). Daten in BigQuery vorverarbeiten und in zusätzlichen Tabellen speichern. Wenn Sie beispielsweise viele ähnliche, rechenintensive Abfragen mit verschiedenen WHERE-Bedingungen ausführen, werden ihre Ergebnisse nicht im Cache gespeichert. Solche Abfragen verbrauchen auch Ressourcen, wenn sie ausgeführt werden. Sie können die Leistung solcher Abfragen verbessern und die Verarbeitungszeit reduzieren, indem Sie die Daten vorab berechnen und in einer Tabelle speichern. Diese vorausberechneten Daten in der Tabelle können von SELECT-Abfragen abgefragt werden. Dies kann häufig während der Aufnahme innerhalb des ETL-Prozesses oder mithilfe von geplanten Abfragen oder materialisierten Ansichten erfolgen.

  • Probelaufmodus verwenden. Führen Sie Abfragen im Probelaufmodus aus, der die Anzahl der gelesenen Byte schätzt, die Abfrage aber nicht verarbeitet.

  • eine Vorschau von Tabellendaten anzeigen lassen Wenn Sie mit Daten experimentieren oder experimentieren möchten, statt Abfragen auszuführen, können Sie mit der Tabellenvorschaufunktion von BigQuery eine Vorschau der Tabellendaten anzeigen lassen.

  • Verwenden Sie im Cache gespeicherte Abfrageergebnisse. Alle Abfrageergebnisse, sowohl für interaktive Abfragen als auch für Batchabfragen, werden etwa 24 Stunden lang in temporären Tabellen im Cache gespeichert. Dabei gelten einige Ausnahmen. Die Ausführung einer im Cache gespeicherten Abfrage wird zwar weiterhin auf Ihr Limit für gleichzeitige Abfragen angerechnet, doch sind Abfragen, die im Cache gespeicherte Ergebnisse verwenden, erheblich schneller als Abfragen, die keine im Cache gespeicherten Ergebnisse verwenden, da BigQuery die Ergebnismenge nicht berechnen muss.

Anzahl der Partitionsänderungen für nach Spalten partitionierte Tabellen – Kontingentfehler

BigQuery gibt diesen Fehler zurück, wenn Ihre nach Spalte partitionierte Tabelle das Kontingent für die Anzahl der zulässigen Partitionsänderungen pro Tag erreicht. Partitionsänderungen umfassen die Gesamtzahl aller Ladejobs, Kopierjobs und Abfragejobs, die eine Zielpartition anhängen oder überschreiben.

Den Wert des Limits für die Anzahl der Partitionsänderungen pro nach Spalte partitionierter Tabelle pro Tag finden Sie unter Partitionierte Tabellen.

Fehlermeldung

Quota exceeded: Your table exceeded quota for
Number of partition modifications to a column partitioned table

Lösung

Dieses Kontingent kann nicht erhöht werden. So beheben Sie diesen Kontingentfehler:

  • Ändern Sie die Partitionierung der Tabelle so, dass in jeder Partition mehr Daten enthalten sind, um die Gesamtzahl der Partitionen zu verringern. Ändern Sie beispielsweise die Einstellung Partitionierung nach Tag zu Partitionierung nach Monat oder ändern Sie die Partitionierung der Tabelle.
  • Verwenden Sie Clustering anstelle der Partitionierung.
  • Wenn Sie häufig Daten aus mehreren kleinen Dateien laden, die in Cloud Storage gespeichert sind und einen Job pro Datei verwenden, kombinieren Sie mehrere Ladejobs zu einem einzigen Job. Zum Laden aus mehreren Cloud Storage-URIs können Sie eine durch Kommas getrennte Liste (z. B. gs://my_path/file_1,gs://my_path/file_2) oder Platzhalter (z. B. gs://my_path/*) verwenden.

    Weitere Informationen finden Sie unter Daten im Batch laden.

  • Wenn Sie beispielsweise Ladejobs, Auswahl- oder Kopierjobs verwenden, um einzelne Datenzeilen an eine Tabelle anzuhängen, sollten Sie mehrere Jobs in einem Job stapeln. BigQuery funktioniert als relationale Datenbank nicht gut. Als Best Practice sollten Sie keine häufigen Anfügeaktionen für einzelne Zeilen ausführen.
  • Wenn Sie Daten mit einer hohen Rate anhängen möchten, sollten Sie die BigQuery Storage Write API verwenden. Es ist eine empfohlene Lösung für die leistungsstarke Datenaufnahme. Die BigQuery Storage Write API bietet robuste Funktionen, einschließlich der Funktion für genau einmalige Übermittlung. Weitere Informationen zu Limits und Kontingenten finden Sie unter Storage Write API. Weitere Informationen zu den Kosten für diese API finden Sie unter Preise für die BigQuery-Datenaufnahme.
  • Verwenden Sie die Ansicht INFORMATION_SCHEMA, um die Anzahl der geänderten Partitionen in einer Tabelle zu überwachen.

Fehler beim Streaming-Insert-Kontingent

Dieser Abschnitt enthält einige Tipps zur Behebung von Kontingentfehlern im Zusammenhang mit dem Streamen von Daten in BigQuery.

In bestimmten Regionen haben Streaming-Insert-Anweisungen ein höheres Kontingent, wenn Sie das Feld insertId nicht für jede Zeile ausfüllen. Weitere Informationen zu Kontingenten für Streaming-Insert-Anweisungen finden Sie unter Streaming-Insert-Anweisungen. Die kontingentbezogenen Fehler beim BigQuery-Streaming hängen davon ab, ob insertId vorhanden ist oder fehlt.

Fehlermeldung

Wenn das Feld insertId leer ist, kann der folgende Kontingentfehler auftreten:

Kontingentlimit Fehlermeldung
Bytes pro Sekunde und Projekt Die Entität mit gaia_id GAIA_ID, Projekt PROJECT_ID in Region REGION hat das Kontingent für Insert-Bytes pro Sekunde überschritten.

Wenn das Feld insertId ausgefüllt ist, können folgende Kontingentfehler auftreten:

Kontingentlimit Fehlermeldung
Zeilen pro Sekunde und Projekt Das Projekt PROJECT_ID in REGION hat das Kontingent zum Streamen von Insert-Zeilen pro Sekunde überschritten.
Zeilen pro Sekunde und Tabelle Die Tabelle TABLE_ID hat das Kontingent für das Streaming von Insert-Zeilen pro Sekunde überschritten.
Bytes pro Sekunde und Tabelle Die Tabelle TABLE_ID hat das Kontingent für das Streaming von Insert-Bytes pro Sekunde überschritten.

Der Zweck des Felds insertId besteht darin, eingefügte Zeilen zu deduplizieren. Wenn mehrere Einfügungen mit der gleichen insertId innerhalb von wenigen Minuten eingehen, schreibt BigQuery eine einzelne Version des Datensatzes. Dies ist jedoch nicht garantiert. Für einen maximalen Streamingdurchsatz empfehlen wir, insertId nicht einzufügen und stattdessen manuelle Deduplizierung zu verwenden. Weitere Informationen finden Sie unter Datenkonsistenz gewährleisten.

Wenn dieser Fehler auftritt, diagnostizieren Sie das Problem und befolgen Sie dann die empfohlenen Schritte, um es zu beheben.

Diagnose

Analysieren Sie mit den STREAMING_TIMELINE_BY_*-Ansichten den Streaming-Traffic. Diese Ansichten aggregieren Streaming-Statistiken über einminütige Intervalle, gruppiert nach Fehlercode. Kontingentfehler werden in den Ergebnissen angezeigt, wenn error_code gleich RATE_LIMIT_EXCEEDED oder QUOTA_EXCEEDED ist.

Sehen Sie sich abhängig vom spezifischen Kontingentlimit, das erreicht wurde, total_rows oder total_input_bytes an. Wenn der Fehler ein Kontingent auf Tabellenebene ist, filtern Sie nach table_id.

Die folgende Abfrage zeigt beispielsweise die Gesamtzahl der pro Minute aufgenommenen Byte und die Gesamtzahl der Kontingentfehler:

SELECT
 start_timestamp,
 error_code,
 SUM(total_input_bytes) as sum_input_bytes,
 SUM(IF(error_code IN ('QUOTA_EXCEEDED', 'RATE_LIMIT_EXCEEDED'),
     total_requests, 0)) AS quota_error
FROM
 `region-us`.INFORMATION_SCHEMA.STREAMING_TIMELINE_BY_PROJECT
WHERE
  start_timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY)
GROUP BY
 start_timestamp,
 error_code
ORDER BY 1 DESC

Lösung

So beheben Sie diesen Kontingentfehler:

  • Wenn Sie das Feld insertId zur Deduplizierung verwenden und sich Ihr Projekt in einer Region befindet, die das höhere Streamingkontingent unterstützt, empfehlen wir, das Feld insertId zu entfernen. Diese Lösung erfordert möglicherweise einige zusätzliche Schritte, um die Daten manuell zu deduplizieren. Weitere Informationen finden Sie unter Duplikate manuell entfernen.

  • Wenn Sie insertId nicht verwenden oder die ID nicht entfernt werden kann, überwachen Sie Ihren Streaming-Traffic über einen Zeitraum von 24 Stunden und analysieren Sie die Kontingentfehler:

    • Wenn Sie hauptsächlich RATE_LIMIT_EXCEEDED-Fehler anstelle von QUOTA_EXCEEDED-Fehlern sehen und Ihr gesamter Traffic unter 80 % des Kontingents liegt, sind die Fehler möglicherweise auf vorübergehende Spitzen zurückzuführen. Zur Behebung dieser Fehler können Sie den Vorgang unter Verwendung von exponentiellem Backoff zwischen Wiederholungen wiederholen.

    • Wenn Sie Daten mit einem Dataflow-Job einfügen, sollten Sie anstelle von Streaming-Insert-Anweisungen Ladejobs verwenden. Weitere Informationen finden Sie unter Einfügungsmethode festlegen. Wenn Sie Dataflow mit einem benutzerdefinierten E/A-Connector verwenden, sollten Sie stattdessen einen integrierten E/A-Connector verwenden. Weitere Informationen finden Sie unter Benutzerdefinierte E/A-Muster.

    • Wenn Sie QUOTA_EXCEEDED-Fehler erhalten oder der Traffic insgesamt 80 % des Kontingents überschreitet, senden Sie eine Anfrage zur Kontingenterhöhung. Weitere Informationen finden Sie unter Höheres Kontingentlimit anfordern.

    • Sie können auch Streaming-Insert-Anweisungen durch die neuere Storage Write API ersetzen, die einen höheren Durchsatz, einen niedrigeren Preis und viele nützliche Features bietet.

Kontingentfehler beim Laden von CSV-Dateien

Wenn Sie eine große CSV-Datei mit dem Befehl bq load mit dem Flag --allow_quoted_newlines laden, kann dieser Fehler auftreten.

Fehlermeldung

Input CSV files are not splittable and at least one of the files is larger than
the maximum allowed size. Size is: ...

Lösung

So beheben Sie diesen Kontingentfehler:

  • Legen Sie das Flag --allow_quoted_newlines auf false fest.
  • Teilen Sie die CSV-Datei in kleinere Blöcke mit jeweils weniger als 4 GB auf.

Weitere Informationen zu Limits, die beim Laden von Daten in BigQuery gelten, finden Sie unter Ladejobs.

Tabellenimporte oder Abfraganfügungen – Kontingentfehler

BigQuery gibt diese Fehlermeldung zurück, wenn Ihre Tabelle das Limit für Tabellenvorgänge pro Tag für Standardtabellen erreicht. Tabellenvorgänge umfassen die Gesamtzahl aller Ladejobs, Kopierjobs und Abfragejobs, die angefügt werden oder eine Zieltabelle überschreiben.

Den Wert des Limits für Tabellenvorgänge pro Tag finden Sie unter Standardtabellen.

Fehlermeldung

Your table exceeded quota for imports or query appends per table

Wenn dieser Fehler auftritt, diagnostizieren Sie das Problem und befolgen Sie dann die empfohlenen Schritte, um es zu beheben.

Diagnose

Wenn Sie die Quelle, von der die meisten Tabellenvorgänge stammen, nicht identifiziert haben, gehen Sie so vor:

  1. Notieren Sie sich das Projekt, das Dataset und die Tabelle, in die der fehlgeschlagene Abfrage-, Lade- oder Kopierjob schreibt.

  2. Weitere Informationen zu Jobs, die die Tabelle ändern, finden Sie unter INFORMATION_SCHEMA.JOBS_BY_*-Tabellen.

    Im folgenden Beispiel wird die stündliche Anzahl von Jobs nach Jobtyp gruppiert und für 24 Stunden mithilfe von JOBS_BY_PROJECT ermittelt. Wenn Sie davon ausgehen, dass mehrere Projekte in die Tabelle schreiben, ersetzen Sie JOBS_BY_PROJECT durch JOBS_BY_ORGANIZATION.

    SELECT
  TIMESTAMP_TRUNC(creation_time, HOUR),
  job_type,
  count(1)
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
#Adjust time
WHERE creation_time BETWEEN "2021-06-20 00:00:00" AND "2021-06-21 00:00:00"
AND destination_table.project_id = "my-project-id"
AND destination_table.dataset_id = "my_dataset"
AND destination_table.table_id = "my_table"
GROUP BY 1, 2
ORDER BY 1 DESC

Lösung

Dieses Kontingent kann nicht erhöht werden. So beheben Sie diesen Kontingentfehler:

  • Wenn Sie häufig Daten aus mehreren kleinen Dateien laden, die in Cloud Storage gespeichert sind und einen Job pro Datei verwenden, kombinieren Sie mehrere Ladejobs zu einem einzigen Job. Zum Laden aus mehreren Cloud Storage-URIs können Sie eine durch Kommas getrennte Liste (z. B. gs://my_path/file_1,gs://my_path/file_2) oder Platzhalter (z. B. gs://my_path/*) verwenden.

    Weitere Informationen finden Sie unter Daten im Batch laden.

  • Wenn Sie beispielsweise Ladejobs, Auswahl- oder Kopierjobs verwenden, um einzelne Datenzeilen an eine Tabelle anzuhängen, sollten Sie mehrere Jobs in einem Job stapeln. BigQuery funktioniert als relationale Datenbank nicht gut. Als Best Practice sollten Sie keine häufigen Anfügeaktionen für einzelne Zeilen ausführen.
  • Wenn Sie Daten mit einer hohen Rate anhängen möchten, sollten Sie die BigQuery Storage Write API verwenden. Es ist eine empfohlene Lösung für die leistungsstarke Datenaufnahme. Die BigQuery Storage Write API bietet robuste Funktionen, einschließlich der Funktion für genau einmalige Übermittlung. Weitere Informationen zu Limits und Kontingenten finden Sie unter Storage Write API. Weitere Informationen zu den Kosten für diese API finden Sie unter Preise für die BigQuery-Datenaufnahme.
  • Verwenden Sie die Ansicht INFORMATION_SCHEMA, um die Anzahl der geänderten Partitionen in einer Tabelle zu überwachen.

Maximale Aktualisierungsrate für Tabellenmetadaten pro Tabelle – Limitfehler

BigQuery gibt diesen Fehler zurück, wenn Ihre Tabelle das Limit für die maximale Aktualisierungsrate für Tabellenmetadaten pro Tabelle für Standardtabellen erreicht. Tabellenvorgänge umfassen die Summe aller Ladejobs, Kopierjobs und Abfragejobs, die Daten an eine Zieltabelle anfügen, eine Zieltabelle überschreiben oder eine der folgenden DML verwenden, um Daten in eine Tabelle zu schreiben: DELETE, INSERT, MERGE, TRUNCATE TABLE oder UPDATE.

Sie können den Wert des Limits der maximalen Aktualisierungsrate für Tabellenmetadaten pro Tabelle unter Standardtabellen aufrufen.

Fehlermeldung

Exceeded rate limits: too many table update operations for this table

Wenn dieser Fehler auftritt, diagnostizieren Sie das Problem und befolgen Sie dann die empfohlenen Schritte, um es zu beheben.

Diagnose

Aktualisierungen von Metadatentabellen können aus API-Aufrufen stammen, die die Metadaten einer Tabelle ändern, oder aus Jobs, die den Inhalt einer Tabelle ändern. Wenn Sie die Quelle, von der die meisten Aktualisierungsvorgänge in den Metadaten einer Tabelle stammen, nicht identifiziert haben, gehen Sie so vor:

API-Aufrufe identifizieren

  1. Rufen Sie das Google Cloud-Navigationsmenü auf und wählen Sie Logging > Log-Explorer aus:

    Zu „Log-Explorer“

  2. Filtern Sie die Logs, um die Tabellenvorgänge aufzurufen, indem Sie die folgende Abfrage ausführen:

    resource.type="bigquery_dataset"
protoPayload.resourceName="projects/my-project-id/datasets/my_dataset/tables/my_table"
(protoPayload.methodName="google.cloud.bigquery.v2.TableService.PatchTable" OR
protoPayload.methodName="google.cloud.bigquery.v2.TableService.UpdateTable" OR
protoPayload.methodName="google.cloud.bigquery.v2.TableService.InsertTable")
Jobs identifizieren

Die folgende Abfrage gibt eine Liste von Jobs zurück, die die betroffene Tabelle im Projekt ändern. Wenn Sie davon ausgehen, dass mehrere Projekte in einer Organisation in die Tabelle schreiben, ersetzen Sie JOBS_BY_PROJECT durch JOBS_BY_ORGANIZATION.

SELECT
 job_id,
 user_email,
 query
#Adjust region
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
#Adjust time
WHERE creation_time BETWEEN "2021-06-21 10:00:00" AND "2021-06-21 20:00:00"
AND destination_table.project_id = "my-project-id"
AND destination_table.dataset_id = "my_dataset"
AND destination_table.table_id = "my_table"

Weitere Informationen finden Sie in der Übersicht zu BigQuery-Audit-Logs.

Lösung

Dieses Kontingent kann nicht erhöht werden. So beheben Sie diesen Kontingentfehler:

  • Verringern Sie die Aktualisierungsrate für die Tabellenmetadaten.
  • Fügen Sie eine Verzögerung zwischen Jobs oder Tabellenvorgängen hinzu, um sicherzustellen, dass die Aktualisierungsrate innerhalb des Limits liegt.

  • Verwenden Sie DML-Vorgänge zum Prüfen von Dateneinfügungen oder -änderungen. DML-Vorgänge sind nicht vom Ratenlimit Maximale Aktualisierungsrate für Tabellenmetadaten pro Tabelle betroffen.

    Für DML-Vorgänge gelten andere Limits und Kontingente. Weitere Informationen finden Sie unter Datenbearbeitungssprache (DML) verwenden.

  • Wenn Sie häufig Daten aus mehreren kleinen Dateien laden, die in Cloud Storage gespeichert sind und einen Job pro Datei verwenden, kombinieren Sie mehrere Ladejobs zu einem einzigen Job. Zum Laden aus mehreren Cloud Storage-URIs können Sie eine durch Kommas getrennte Liste (z. B. gs://my_path/file_1,gs://my_path/file_2) oder Platzhalter (z. B. gs://my_path/*) verwenden.

    Weitere Informationen finden Sie unter Daten im Batch laden.

  • Wenn Sie beispielsweise Ladejobs, Auswahl- oder Kopierjobs verwenden, um einzelne Datenzeilen an eine Tabelle anzuhängen, sollten Sie mehrere Jobs in einem Job stapeln. BigQuery funktioniert als relationale Datenbank nicht gut. Als Best Practice sollten Sie keine häufigen Anfügeaktionen für einzelne Zeilen ausführen.
  • Wenn Sie Daten mit einer hohen Rate anhängen möchten, sollten Sie die BigQuery Storage Write API verwenden. Es ist eine empfohlene Lösung für die leistungsstarke Datenaufnahme. Die BigQuery Storage Write API bietet robuste Funktionen, einschließlich der Funktion für genau einmalige Übermittlung. Weitere Informationen zu Limits und Kontingenten finden Sie unter Storage Write API. Weitere Informationen zu den Kosten für diese API finden Sie unter Preise für die BigQuery-Datenaufnahme.
  • Verwenden Sie die Ansicht INFORMATION_SCHEMA, um die Anzahl der geänderten Partitionen in einer Tabelle zu überwachen.

Maximale Anzahl von API-Anfragen – Limitfehler

BigQuery gibt diesen Fehler zurück, wenn Sie das Ratenlimit für die Anzahl der API-Anfragen an eine BigQuery API pro Nutzer und Methode erreichen, z. B. die tables.get-Methodenaufrufe über ein Dienstkonto oder die jobs.insert-Methodenaufrufe über eine andere Nutzer-E-Mail. Weitere Informationen finden Sie unter Maximale Anzahl API-Anfragen pro Sekunde, Nutzer und Methode in Alle BigQuery API.

Fehlermeldung 

Quota exceeded: Your user_method exceeded quota for concurrent api requests
per user per method.

Wenn dieser Fehler auftritt, diagnostizieren Sie das Problem und befolgen Sie dann die empfohlenen Schritte, um es zu beheben.

Diagnose

Wenn Sie die Methode, die dieses Ratenlimit erreicht hat, nicht identifiziert haben, gehen Sie so vor:

Für das Dienstkonto

  1. Rufen Sie das Projekt auf, das das Dienstkonto hostet.

  2. Rufen Sie in der Google Cloud Console das API-Dashboard auf.

    Eine Anleitung zum Aufrufen der detaillierten Nutzungsinformationen einer API finden Sie unter API-Dashboard verwenden.

  3. Wählen Sie im API-Dashboard BigQuery API aus.

  4. Wählen Sie Messwerte aus, um detaillierte Nutzungsinformationen aufzurufen:

    1. Wählen Sie unter Grafiken auswählen die Option Traffic nach API-Methode aus.

    2. Filtern Sie das Diagramm nach den Anmeldedaten des Dienstkontos. Sie sehen möglicherweise Spitzen für eine Methode in dem Zeitraum, in dem Sie den Fehler festgestellt haben.

Für API-Aufrufe

Einige API-Aufrufe rufen Logfehler von BigQuery-Audit-Logs in Cloud Logging auf. So ermitteln Sie die Methode, die das Limit erreicht hat:

  1. Rufen Sie in der Google Cloud Console das Google Cloud-Navigationsmenü auf und wählen Sie dannProtokollierung > Log-Explorer für Ihr Projekt:

    Zu „Log-Explorer“

  2. Filtern Sie Logs mit der folgenden Abfrage:

     resource.type="bigquery_resource"
 protoPayload.authenticationInfo.principalEmail="<user email or service account>"
 "Too many API requests per user per method for this user_method"
 In the log entry, you can find the method name under the property protoPayload.method_name.

    Weitere Informationen finden Sie in der Übersicht zu BigQuery-Audit-Logs.

Lösung

So beheben Sie diesen Kontingentfehler:

  • Reduzieren Sie die Anzahl der API-Anfragen oder fügen Sie eine Verzögerung zwischen mehreren API-Anfragen hinzu, sodass die Anzahl der Anfragen unter diesem Limit bleibt.

  • Wenn das Limit nur gelegentlich überschritten wird, können Sie Wiederholungsversuche für diesen spezifischen Fehler mit exponentiellem Backoff implementieren.

  • Wenn Sie häufig Daten einfügen, sollten Sie die Verwendung von Streaming-Insert-Anweisungen in Betracht ziehen, da Streaming-Insert-Anweisungen nicht vom BigQuery API-Kontingent betroffen sind. Allerdings sind mit der Streaming Inserts API Kosten verbunden und es gelten eigene Limits und Kontingente.

    Weitere Informationen zu den Kosten von Streaming-Insert-Anweisungen finden Sie unter BigQuery-Preise.

  • Beim Laden von Daten in BigQuery mit Dataflow mit dem BigQuery-E/A-Connector kann dieser Fehler für die Methode tables.get auftreten. So beheben Sie das Problem:

    • Legen Sie die Erstellungsanordnung der Zieltabelle auf CREATE_NEVER fest. Weitere Informationen finden Sie unter Konfiguration erstellen.

    • Verwenden Sie das Apache Beam SDK in der Version 2.24.0 oder höher. In den vorherigen Versionen des SDK ruft die CREATE_IF_NEEDED-Anordnung die Methode tables.get auf, um zu prüfen, ob die Tabelle vorhanden ist.

  • Sie können eine Kontingenterhöhung anfordern, indem Sie sich an den Support oder den Vertrieb wenden. Weitere Informationen zu Streamingkontingenten finden Sie unter Kontingenterhöhung anfordern. Die Bearbeitung einer Kontingenterhöhung kann mehrere Tage dauern. Damit Sie weitere Informationen zu Ihrer Anfrage bereitstellen können, sollte die Anfrage die Priorität des Jobs, den Nutzer, der die Abfrage ausführt, und die betroffene Methode enthalten.

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 Limit für die Datengröße erreicht, die abgefragt werden kann. Weitere Informationen zu Abfragen (Analyse) 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.

Maximale tabledata.list-Byte pro Sekunde und Projektkontingentfehler

BigQuery gibt diesen Fehler zurück, wenn die in der Fehlermeldung erwähnte Projektnummer die maximale Größe von Daten erreicht, die über den API-Aufruf tabledata.list in einem Projekt pro Sekunde gelesen werden können. Weitere Informationen finden Sie unter Maximal tabledata.list Byte pro Minute.

Fehlermeldung

Your project:[project number] exceeded quota for tabledata.list bytes per second per project

Lösung

So beheben Sie diesen Fehler:

  • Im Allgemeinen empfehlen wir, dieses Limit nicht zu überschreiten. Sie können beispielsweise Anfragen über einen längeren Zeitraum und mit zeitlichen Verzögerungen verteilen. Tritt der Fehler nicht häufig auf, lässt sich das Problem durch Implementieren von Wiederholungsversuchen mit exponentiellem Backoff lösen.
  • Wenn der Anwendungsfall ein schnelles und häufiges Lesen großer Datenmengen aus einer Tabelle erwartet, empfehlen wir die Verwendung der BigQuery Storage Read API anstelle der tabledata.list API.

  • Wenn die vorherigen Vorschläge nicht funktionieren, können Sie über das API-Dashboard der Google Cloud Console eine Kontingenterhöhung anfordern. Gehen Sie dazu so vor:

    1. Rufen Sie das API-Dashboard der Google Cloud Console auf.
    2. Filtern Sie im Dashboard nach Kontingent: Tabledata list bytes per minute (default quota).
    3. Wählen Sie das Kontingent aus und folgen Sie der Anleitung unter Höheres Kontingentlimit anfordern.

    Es kann einige Tage dauern, bis die Anfrage geprüft und verarbeitet wird.

Zu viele DML-Anweisungen für die Tabelle ausstehend

Dieser Fehler bedeutet, dass die Anzahl der gleichzeitigen mutierenden DML-Anweisungen (UPDATE, DELETE, MERGE) für dieselbe Tabelle das Kontingentlimit für die Datenbearbeitungssprache (DML) überschritten hat. Dieses Kontingentlimit gilt pro Tabelle und gilt nur für mutierende DML-Anweisungen, die INSERT nicht enthalten.

Lösung

Folgen Sie den Best Practices für DML-Anweisungen, um die DML-Jobs stapelweise zu verarbeiten.

Maximale Anzahl von Kopierjobs pro Tag und Projektkontingentfehler

BigQuery gibt diesen Fehler zurück, wenn die Anzahl der in einem Projekt ausgeführten Kopierjobs das Tageslimit überschritten hat. Weitere Informationen zum Limit für Kopierjobs pro Tag finden Sie unter Kopierjobs.

Fehlermeldung

Your project exceeded quota for copies per project

Diagnose

Wenn Sie mehr Daten zum Ursprung der Kopierjobs erfassen möchten, können Sie Folgendes versuchen:

  • Wenn sich Ihre Kopierjobs in einer einzelnen oder nur wenigen Regionen befinden, können Sie versuchen, die Tabelle INFORMATION_SCHEMA.JOBS für diese Region(en) abzufragen. Beispiel: 
    SELECT
creation_time, job_id, user_email, destination_table.project_id, destination_table.dataset_id, destination_table.table_id
FROM `PROJECT_ID`.`REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 2 DAY) AND CURRENT_TIMESTAMP()
AND job_type = "COPY"
order by creation_time DESC
     Der REGION_NAME-Teil sollte durch den Namen der Region einschließlich des Präfixes region- ersetzt werden. Beispiel: region-us , region-asia-south1. Sie können das Zeitintervall auch je nach gewünschtem Zeitraum anpassen.
  • Mit dem folgenden Filter in Cloud Logging können Sie alle Kopierjobs in allen Regionen anzeigen lassen: 
    resource.type="bigquery_resource"
protoPayload.methodName="jobservice.insert"
protoPayload.serviceData.jobInsertRequest.resource.jobConfiguration.tableCopy:*

Lösung

  • Wenn die häufigen Kopiervorgänge das Erstellen eines Snapshots von Daten ermöglichen, sollten Sie stattdessen Tabellen-Snapshots verwenden. Tabellen-Snapshots sind eine kostengünstigere und schnellere Alternative zum Kopieren vollständiger Tabellen.
  • Sie können eine Kontingenterhöhung anfordern, indem Sie sich an den Support oder den Vertrieb wenden. Es kann mehrere Tage dauern, bis die Anfrage geprüft und verarbeitet wird. Wir empfehlen, in der Anfrage die Priorität, den Anwendungsfall und die Projekt-ID anzugeben.

Maximale Anzahl gleichzeitiger Abfragen, die Remotefunktionen enthalten

BigQuery gibt diesen Fehler zurück, wenn die Anzahl der gleichzeitigen Abfragen, die Remotefunktionen enthalten, das Limit überschreitet.

Weitere Informationen zum Limit für Remote-Funktionen finden Sie unter Remote-Funktionen.

Fehlermeldung

Exceeded rate limits: too many concurrent queries with remote functions for
this project

Diagnose

Informationen zu den Limits für gleichzeitige Abfragen, die Remote-Funktionen enthalten, finden Sie unter Limits für Remote-Funktionen.

Lösung

  • Beachten Sie bei der Verwendung von Remote-Funktionen die Best Practices für Remote-Funktionen.
  • Sie können eine Kontingenterhöhung anfordern, indem Sie sich an den Support oder den Vertrieb wenden. Es kann mehrere Tage dauern, bis die Anfrage geprüft und verarbeitet wird. Wir empfehlen, in der Anfrage die Priorität, den Anwendungsfall und die Projekt-ID anzugeben.

Fehler beim Shuffle-Größenlimit

BigQuery gibt diesen Fehler zurück, wenn Ihr Projekt das maximale Laufwerk- und Arbeitsspeichergrößenlimit überschreitet, das für Shuffle-Vorgänge verfügbar ist.

Dieses Kontingent wird pro Reservierung berechnet und auf Projekte für die Reservierungen aufgeteilt. Das Kontingent kann von Cloud Customer Care nicht geändert werden. Weitere Informationen zu Ihrer Nutzung erhalten Sie durch Abfragen der Ansicht INFORMATION_SCHEMA.JOBS_TIMELINE.

Fehlermeldung

Es wird eine der folgenden Fehlermeldungen angezeigt:

  • Quota exceeded: Your project exceeded quota for total shuffle size limit.
  • Resources exceeded: Your project or organization exceeded the maximum
disk and memory limit available for shuffle operations. Consider provisioning
more slots, reducing query concurrency, or using more efficient logic in this
job.

Lösung

So beheben Sie diesen Fehler:

Maximale Anzahl von CREATE MODEL-Anweisungen

Dieser Fehler bedeutet, dass Sie das Kontingent für CREATE MODEL-Anweisungen überschritten haben.

Fehlermeldung

Quota exceeded: Your project exceeded quota for CREATE MODEL queries per project.

Lösung

Wenn Sie das Kontingent für CREATE MODEL-Anweisungen überschreiten, fordern Sie eine Kontingenterhöhung an.