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.

In einigen Fehlermeldungen werden Kontingente oder Limits angegeben, die Sie erhöhen können, während in anderen Fehlermeldungen Kontingente oder Limits angegeben werden, die Sie nicht erhöhen können. Wenn Sie ein festes Limit erreichen, müssen Sie temporäre oder dauerhafte Problemumgehungen oder Best Practices für Ihre Arbeitslast implementieren. Dies ist eine Best Practice, auch für Kontingente oder Limits, die erhöht werden können.

In diesem Dokument werden Fehlermeldungen und ihre Lösungen nach diesen Kategorien geordnet. Im Abschnitt „Übersicht“ weiter unten in diesem Dokument wird erläutert, wie Sie eine Fehlermeldung lesen und die richtige Lösung für Ihr Problem anwenden.

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.

Hinweis: Einige Kontingente werden als Tageskontingente ausgedrückt. Beispielsweise gibt es ein Tageskontingent für die Anzahl der Ladejobs pro Tabelle. Diese Kontingente werden jedoch gleichmäßig über einen Zeitraum von 24 Stunden erhöht, sodass Sie nicht ganze 24 Stunden warten müssen, wenn das Limit erreicht ist.

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 und einem Regions-Qualifier. 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-REGION_NAME`.INFORMATION_SCHEMA.JOBS
  WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY) AND
      error_result.reason IN ('rateLimitExceeded', 'quotaExceeded')

  Ersetzen Sie REGION_NAME durch die Region des Projekts. Ihm muss region- vorangestellt werden. Verwenden Sie beispielsweise für die Multiregion US den Wert region-us.

• 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.

Fehlerbehebung bei Kontingenten oder Limits, die erhöht werden können

Sie können die folgenden Kontingente und Limits erhöhen. Es empfiehlt sich jedoch, zuerst die vorgeschlagenen Problemumgehungen oder Best Practices auszuprobieren.

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.

Fehler bei Kontingent für Streaming-Insert-Anweisungen

In diesem Abschnitt finden Sie Tipps zur Fehlerbehebung bei Kontingentfehlern im Zusammenhang mit dem Streaming 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	Ihre Tabelle TABLE_ID hat das Kontingent für Streaming-Insert-Anweisungen pro Sekunde überschritten.
Bytes pro Sekunde und Tabelle	Ihre Tabelle TABLE_ID hat das Kontingent für Streaming-Insert-Anweisungen in Byte 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. In diesen Ansichten werden Streamingstatistiken über einminütige Intervalle aggregiert, gruppiert nach error_code. Kontingentfehler werden in den Ergebnissen mit error_code gleich RATE_LIMIT_EXCEEDED oder QUOTA_EXCEEDED angezeigt.

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-REGION_NAME`.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. Für diese Lösung sind möglicherweise zusätzliche Schritte erforderlich, 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 Kontingentanpassung 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.

Weitere Informationen zu Streaming-Insert-Anweisungen finden Sie unter Daten in BigQuery streamen.

Maximale Anzahl gleichzeitiger Abfragen, die Remote-Funktionen enthalten

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

Weitere Informationen zu den Limits für Remote-Funktionen finden Sie unter Remote-Funktionen.

Fehlermeldung

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

Dieses Limit kann erhöht werden. Probieren Sie zuerst die Problemumgehungen und Best Practices aus.

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.

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, senden Sie eine E-Mail an [e-mail] und fordern Sie eine Kontingenterhöhung an.

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 bestimmte Regionen 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-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

  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.

Fehler „Kontingent für extrahierte Byte pro Tag überschritten“

BigQuery gibt diesen Fehler zurück, wenn die Extraktion das standardmäßige Tageslimit von 50 TiB in einem Projekt überschreitet. Weitere Informationen zu Limits für Extraktionsjobs finden Sie unter Extraktionsjobs.

Fehlermeldung

Your usage exceeded quota for ExtractBytesPerDay

Diagnose

Wenn Sie eine Tabelle exportieren, die größer als 50 TiB ist, schlägt der Export fehl, da das Extraktionslimit überschritten wird. Wenn Sie Tabellendaten für bestimmte Tabellenpartitionen exportieren möchten, können Sie die zu exportierenden Partitionen mit einem Partitions-Decorator identifizieren.

Wenn Sie die Nutzung von Exportdaten der letzten Tage erfassen möchten, können Sie Folgendes versuchen:

• Rufen Sie die Kontingente für Ihr Projekt auf und verwenden Sie Filterkriterien wie Name: Extract bytes per day oder Metric: bigquery.googleapis.com/quota/extract/bytes sowie das Diagramm „Nutzung anzeigen“, um den Nutzungstrend über mehrere Tage hinweg zu sehen.

• Alternativ können Sie INFORMATION_SCHEMA.JOBS_BY_PROJECT abfragen, um die Gesamtzahl der extrahierten Byte über mehrere Tage hinweg zu sehen. Die folgende Abfrage gibt beispielsweise die Gesamtzahl der Byte zurück, die in den letzten sieben Tagen täglich von EXTRACT-Jobs verarbeitet wurden.

  SELECT
  TIMESTAMP_TRUNC(creation_time, DAY) AS day,
  SUM ( total_bytes_processed ) / POW(1024, 3) AS total_gibibytes_processed
  FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
  WHERE
  creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) AND CURRENT_TIMESTAMP()
  AND job_type = "EXTRACT"
  GROUP BY 1
  ORDER BY 2 DESC

• Sie können die Ergebnisse dann weiter verfeinern, indem Sie die spezifischen Jobs identifizieren, die mehr Byte als erwartet verbrauchen. Im folgenden Beispiel werden die 100 EXTRACT-Jobs zurückgegeben, die in den letzten sieben Tagen mehr als 100 GB verarbeitet haben.

  SELECT
  creation_time,
  job_id,
  total_bytes_processed/POW(1024, 3) AS total_gigabytes_processed
  FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
  WHERE
  creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) AND CURRENT_TIMESTAMP()
  AND job_type="EXTRACT"
  AND total_bytes_processed > (POW(1024, 3) * 100)
  ORDER BY
  total_bytes_processed DESC
  LIMIT 100

Alternativ können Sie den Job-Explorer mit Filtern wie Bytes processed more than verwenden, um nach Jobs mit hoher Verarbeitung für einen bestimmten Zeitraum zu filtern.

Lösung

Eine Möglichkeit, diesen Kontingentfehler zu beheben, besteht darin, eine Slot-Reservierung zu erstellen und Ihr Projekt der Reservierung mit dem Jobtyp PIPELINE zuzuweisen. Mit dieser Methode kann die Limitprüfung umgangen werden, da Ihre dedizierten Reservierungen anstelle eines kostenlosen freigegebenen Slot-Pools verwendet werden. Bei Bedarf kann die Reservierung gelöscht werden, wenn Sie später einen freigegebenen Slot-Pool verwenden möchten.

Alternative Ansätze, mit denen Sie mehr als 50 TiB exportieren können, finden Sie im Abschnitt „Hinweise“ unter Extraktionsjobs.

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 derGoogle Cloud Console eine Kontingenterhöhung anfordern. Gehen Sie dazu so vor:

  1. Öffnen Sie das Google Cloud Console API-Dashboard.
  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 Kontingentanpassung beantragen.

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

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.

Die meisten BigQuery API-Kernmethoden haben ein Limit von 100 API-Anfragen pro Nutzer und Methode. Einige dieser Kernmethoden können jedoch andere Ratenbegrenzungen haben, z. B.:

• Für die Methode jobs.get gilt ein Limit von 1.000 API-Anfragen pro Nutzer und Sekunde.
• Für die Methode projects.list und die Methode tables.insert gilt ein Limit von 10 Anfragen pro Nutzer und Sekunde.

Außerdem gelten die BigQuery API-Ratenlimits nicht für Streaming-Insert-Anweisungen.

Weitere Informationen zu einzelnen Ratenbegrenzungen finden Sie unter Maximale Anzahl API-Anfragen pro Sekunde, Nutzer und Methode.

Fehlermeldung

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

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

Wenn der Fehler die Ursache apiLimitExceeded hat, lesen Sie die Informationen unter Fehler bei der API-Rate und der Metadatenbewertung oder bei Fehlern im Zusammenhang mit Dataset-Replikaten Fehler bei der Erstellung von regionenübergreifenden Dataset-Replikaten.

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 Navigationsmenü Google Cloud auf und wählen Sie dann Logging > Log-Explorer für Ihr Projekt aus:

   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 BigQuery Storage Write API (gRPC) verwenden. Das Streamen von Daten mit dieser API ist nicht vom BigQuery API-Kontingent betroffen.

• 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.

  • 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.

API-Raten- und Metadatenbewertung – Limitfehler

BigQuery gibt den HTTP-Fehler 403 Forbidden mit dem Grund apiLimitExceeded zurück, wenn eine Anfrage die API-Ratenbegrenzungen oder die Limits für gleichzeitige Metadaten- und Zugriffsbewertungen überschreitet.

Fehlermeldungen beim Dienst zur Datenmigration

• Quota exceeded for the project...
• API limit exceeded: Quota exceeded for quota metric 'Read requests'...

Diagnose

Dieser Fehler kann in den folgenden Szenarien auftreten:

• Hohes Volumen gleichzeitiger API-Anfragen. Eine Anwendung sendet eine große Anzahl gleichzeitiger API-Aufrufe (z. B. jobs.insert, tables.get oder schnelle Abfragen des Jobstatus), die die BigQuery API-Anfragelimits überschreiten.
• BigLake Metastore-Nebenläufigkeit. Abfragen für externe Tabellen, die von BigLake Metastore unterstützt werden, generieren eine große Anzahl gleichzeitiger Metadaten-Leseanfragen.
• Komplexe IAM- oder Sicherheitsevaluierung auf Zeilenebene. Gleichzeitige Abfragen verweisen auf eine große Anzahl von Datasets, Tabellen oder Richtlinien für die Sicherheit auf Zeilenebene (Row-Level Security, RLS), wodurch die Limits für die Zugriffsbewertung im Backend ausgeschöpft werden.

Wenn die Fehlermeldung Quota exceeded: Your user_method exceeded quota for concurrent api requests per user per method lautet, lesen Sie den Abschnitt Maximale Anzahl von API-Anfragen – Limitfehler.

Lösung

So beheben Sie diesen Fehler:

• Wiederholen Sie den Vorgang mit abgeschnittenem exponentiellem Backoff. Konfigurieren Sie Ihre Clientanwendung oder Ihr Skript so, dass fehlgeschlagene Anfragen mit einem abgeschnittenen exponentiellen Backoff wiederholt werden.
• API-Vorgänge im Batchmodus ausführen und konsolidieren. Laden oder fragen Sie Daten in weniger, größeren Batches ab, anstatt API-Aufrufe mit hoher Häufigkeit für einzelne Zeilen oder pro Tabelle auszuführen, und reduzieren Sie die Häufigkeit von jobs.get-Abfrageaufrufen.
• IAM- und Sicherheitskonfigurationen vereinfachen: Bevorzugen Sie Google Groups und IAM-Rollenbindungen auf Dataset-Ebene gegenüber einer großen Anzahl von detaillierten IAM-Bindungen pro Tabelle oder sich überschneidenden Sicherheitsrichtlinien auf Zeilenebene, um den Aufwand für die Zugriffsprüfung zu reduzieren.
• Kontingentnutzung in der Google Cloud Console prüfen. Prüfen Sie auf der Seite Kontingente und Systemlimits, ob ein anpassbares BigQuery- oder BigLake API-Kontingent erreicht wird. Wenn Sie dauerhaft mehr Kapazität benötigen, fordern Sie eine Kontingentanpassung an.

Maximale Python-UDF-Image-Speicherbyte pro Projekt und Region

Die Gesamtgröße aller gespeicherten Container-Images, die von aktiven Python-UDFs verwendet werden, darf 10 GiB pro Projekt und Region nicht überschreiten. Dieses Limit wird beim Erstellen oder Aktualisieren einer Python-UDF erzwungen. Wenn die Gesamtgröße das regionale Limit überschreitet, schlägt die Anfrage sofort fehl und der folgende Fehler wird zurückgegeben.

Fehlermeldung

Resources exceeded during query execution: Quota exceeded: Your project: PROJECT_ID exceeded quota for Python UDF image storage usage per region per project.

Lösung

So beheben Sie diesen Fehler:

1. Erhöhung anfordern: Rufen Sie die Seite Kontingente und Systemlimits auf, suchen Sie nach dem Limit Python UDF image storage bytes per project per region und fordern Sie dann eine Erhöhung an.

2. Speicher optimieren: Löschen Sie nicht verwendete Python-UDFs mit der Anweisung DROP FUNCTION, um Speicherplatz freizugeben. Nachdem eine UDF gelöscht wurde, wird ihre Image-Größe nicht mehr auf das Kontingent angerechnet. Sie können die Bildgröße mit der RoutineBuildStatus der API ermitteln. Weitere Informationen zum Aufrufen des Build-Status finden Sie unter Container-Build-Status.

Maximale Anzahl gleichzeitiger Python-UDFs

Sie sind auf 10 gleichzeitige Python-UDFs pro Projekt beschränkt. Wenn Sie mehr als 10 ausführen, erhalten Sie die folgende Fehlermeldung.

Fehlermeldung

Exceeded rate limits: too many concurrent queries with Python UDFs in this project. Your project: PROJECT_ID exceeded quota for maximum concurrent Python UDFs per project.

Alle Python-UDF-Kontingente finden Sie unter Routinen in der Referenz zu Kontingenten und Limits.

Lösung

Sie können eine Kontingenterhöhung anfordern, indem Sie sich an den Support oder den Vertrieb wenden. Es kann einige 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 bei der Ratenbegrenzung oder Kapazität von Python-UDFs

Dieser Fehler tritt auf, wenn eine Abfrage, die eine Python-UDF aufruft, die Ratenbegrenzungen oder die maximale Containerskalierungskapazität für die UDF überschreitet. Dieses Problem tritt normalerweise in den folgenden Situationen auf:

• Eine Abfrage verarbeitet ein großes Datenvolumen mit hoher Parallelität.
• Jede Containerinstanz ist so konfiguriert, dass sie eine kleine Anzahl gleichzeitiger Anfragen verarbeiten kann.
• Einzelne UDF-Aufrufe dauern sehr lange.

Fehlermeldung

Resources exceeded during query execution: Python user-defined function execution exceeded rate limits or capacity. Check https://docs.cloud.google.com/bigquery/docs/troubleshoot-quotas for more details.

Lösung

Versuchen Sie Folgendes, um diesen Fehler zu beheben:

• Containerlimits optimieren: Prüfen Sie die Python-UDF-Messwerte in Cloud Monitoring, um die CPU-Auslastung, die Arbeitsspeicherauslastung und die gleichzeitigen Anfragen zu untersuchen. Wenn container_request_concurrency auf einen niedrigen Wert festgelegt ist, erhöhen Sie ihn, damit jede Containerinstanz mehr Anfragen parallel verarbeiten kann. Wenn container_cpu auf weniger als 1.0 vCPU ohne expliziten container_request_concurrency-Wert festgelegt ist, wird die Nebenläufigkeit zur Laufzeit standardmäßig auf 1 gesetzt. Weitere Informationen finden Sie unter Containerlimits für Python-UDFs konfigurieren.
• UDF-Ausführung und Abfragestruktur optimieren: Folgen Sie den Best Practices für Python-UDFs, um die Ausführungszeit und das Anfragevolumen pro Abfrage zu reduzieren. Filtern Sie beispielsweise Ihre Daten, bevor Sie die UDF aufrufen, halten Sie die Nutzlasten der Eingabezeilen klein und strukturieren Sie Ihre Abfrage so, dass Batching unterstützt wird.
• Kapazitätserhöhung anfordern: Wenn der Fehler nach der Optimierung Ihrer UDF weiterhin auftritt, wenden Sie sich an den Support oder den Vertrieb, um ein höheres Limit für die Containerskalierung anzufordern. Geben Sie in Ihrer Anfrage die Priorität, den Anwendungsfall und die Projekt-ID an.

Fehlerbehebung bei Kontingenten oder Limits, die nicht erhöht werden können

Sie können die folgenden Kontingente oder Limits nicht erhöhen, aber Sie können die vorgeschlagenen Problemumgehungen oder Best Practices anwenden, um sie zu reduzieren.

Limit für Tabellen-Snapshots überschritten

Dieser Fehler tritt auf, wenn eine BigQuery-Tabelle die maximale Anzahl von Tabellen-Snapshots überschreitet, die innerhalb von 24 Stunden zulässig sind. Dies ist ein Limit auf Tabellenebene, d. h., es gilt für jede einzelne Tabelle in Ihrem Projekt.

Weitere Informationen zu den Limits für Tabellenvorgänge pro Tag finden Sie unter Standardtabellen.

Dieses Limit kann nicht erhöht werden.

Fehlermeldung

Your table exceeded quota for SNAPSHOT operations per table

Lösung

So beheben Sie diesen Fehler:

• Reduzieren Sie die Anzahl der Snapshot-Vorgänge, die innerhalb von 24 Stunden für die betroffene Tabelle ausgeführt werden.
• Wenn es nicht möglich ist, die Snapshot-Häufigkeit zu reduzieren, wenden Sie sich an den Cloud Customer Care oder Ihren Technical Account Manager.

Maximale Anzahl von Fehlern bei ausstehenden Jobs

Dieses Limit kann nicht erhöht werden.

Fehlermeldung

Quota exceeded: concurrent number of jobs that can be in the pending state

Lösung

Dieses Kontingent kann nicht erhöht werden.

So beheben Sie diesen Fehler:

• Übermittlungsrate reduzieren: Reduzieren Sie die Rate, mit der Sie Jobs an BigQuery senden.
• Nebenläufigkeit begrenzen: Vermeiden Sie es, eine große Anzahl von Jobs parallel zu senden, die im Status „Ausstehend“ hängen bleiben könnten.

Fehler in Abfragewarteschlangen

Dieser Fehler kann auftreten, wenn ein Projekt mehr interaktive oder Batchabfragen in die Warteschlange stellt, als das Warteschlangenlimit zulässt.

Fehlermeldung

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

Lösung

Dieses Limit kann nicht erhöht werden. Informationen zur Behebung dieses Fehlers finden Sie in den folgenden allgemeinen Hinweisen. Informationen zu interaktiven Abfragen mit hohem Volumen finden Sie unter Limits für interaktive Abfragen mit hohem Volumen vermeiden.

• Job anhalten. Wenn Sie einen Prozess oder eine Pipeline ermitteln, der bzw. die für eine Zunahme der Abfragen verantwortlich ist, pausieren Sie diesen Prozess oder diese Pipeline.
• 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.

• Optimieren Sie Abfragen und das 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ätsbasierten Preis verwenden, können Sie mehr Abfragen mit Ihren Slots ausführen. Weitere Informationen finden Sie unter Einführung in die Optimierung der Abfrageleistung.

• Abfragemodell optimieren 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.

  Verwenden Sie die Empfehlungen in der folgenden Liste, um das Abfragemodell zu optimieren und zu vermeiden, dass das Limit für die Abfragewarteschlange erreicht wird.

  • Daten persistent 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.
  • 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.

• 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.

• Erhöhen Sie die Anzahl der Slots in Ihrer Reservierung. Erhöhen Sie die Anzahl der Slots oder wechseln Sie bei einer Arbeitslast mit hoher Nachfrage von On-Demand (Pay-per-Query-Modell) zu Reservierungen (kapazitätsbasiertes Modell).

Limits für interaktive Abfragen mit hohem Volumen vermeiden

Wenn Sie eine große Anzahl interaktiver Abfragen ausführen, kann es sein, dass diese Abfragen das Limit für die maximale Anzahl interaktiver Abfragen in der Warteschlange erreichen. Dieses Limit kann nicht erhöht werden.

Wenn Sie interaktive Abfragen mit hohem Volumen ausführen, insbesondere in Szenarien mit automatisierten Triggern wie Cloud Run Functions, sollten Sie zuerst das Verhalten der Cloud Run-Funktion, die den Fehler verursacht, überwachen und sie dann beenden. Verwenden Sie dann eine der folgenden empfohlenen Strategien, um dieses Limit zu vermeiden:

• Anzahl der Slots in Ihrer Reservierung erhöhen Wenn Sie eine Arbeitslast mit hoher Nachfrage haben, wechseln Sie von On-Demand (Pay-per-Query-Modell) zu Reservierungen (kapazitätsbasiertes Modell).
• Verteilen Sie die Arbeitslast auf interaktive Abfragen.
• Da Sie mehr Batchabfragen als interaktive Abfragen in die Warteschlange stellen können, sollten Sie Jobs mit Batchpriorität anstelle von interaktiven Abfragen verwenden.

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.

Wenn Sie das On-Demand-Preismodell verwenden, sind Sie auf maximal 2.000 Slots beschränkt. Wenn Sie die Anzahl der Slots erhöhen möchten, müssen Sie zu einem kapazitätsbasierten Preismodell wechseln.

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:

• Reservierung erhöhen
• Abfragen optimieren
• Reduzieren Sie die Gleichzeitigkeit von Abfragen oder die Materialisierung von Zwischenergebnissen, um die Abhängigkeit von Ressourcen zu reduzieren. Weitere Informationen finden Sie unter Abfragewarteschlangen und Materialisierte Ansichten erstellen.
• Detaillierte Schritte zur Behebung eines unzureichenden Shuffle-Kontingents ansehen.

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 Lade-, Auswahl- oder Kopierjobs verwenden, um einzelne Datenzeilen an eine Tabelle anzuhängen, sollten Sie mehrere Jobs in einem Job zusammenfassen. BigQuery funktioniert als relationale Datenbank nicht gut. Als Best Practice sollten Sie häufige, einzeilige Anfügeaktionen vermeiden.
• Wenn Sie Daten mit einer hohen Rate anhängen möchten, sollten Sie die BigQuery Storage Write API (gRPC) verwenden. Es ist eine empfohlene Lösung für die leistungsstarke Datenaufnahme. Die BigQuery Storage Write API (gRPC) 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.
• Informationen zum Optimieren von Tabellenladejobs, um das Erreichen von Kontingentlimits zu vermeiden, finden Sie unter Ladejobs optimieren.

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-Anweisungen 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
• Jobs identifizieren

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 innerhalb des letzten Tages ä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
FROM  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY)
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 Lade-, Auswahl- oder Kopierjobs verwenden, um einzelne Datenzeilen an eine Tabelle anzuhängen, sollten Sie mehrere Jobs in einem Job zusammenfassen. BigQuery funktioniert als relationale Datenbank nicht gut. Als Best Practice sollten Sie häufige, einzeilige Anfügeaktionen vermeiden.
• Wenn Sie Daten mit einer hohen Rate anhängen möchten, sollten Sie die BigQuery Storage Write API (gRPC) verwenden. Es ist eine empfohlene Lösung für die leistungsstarke Datenaufnahme. Die BigQuery Storage Write API (gRPC) 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.
• Informationen zum Optimieren von Tabellenladejobs, um das Erreichen von Kontingentlimits zu vermeiden, finden Sie unter Ladejobs optimieren.

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 die letzten 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-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
   WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY)
   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 Lade-, Auswahl- oder Kopierjobs verwenden, um einzelne Datenzeilen an eine Tabelle anzuhängen, sollten Sie mehrere Jobs in einem Job zusammenfassen. BigQuery funktioniert als relationale Datenbank nicht gut. Als Best Practice sollten Sie häufige, einzeilige Anfügeaktionen vermeiden.
• Wenn Sie Daten mit einer hohen Rate anhängen möchten, sollten Sie die BigQuery Storage Write API (gRPC) verwenden. Es ist eine empfohlene Lösung für die leistungsstarke Datenaufnahme. Die BigQuery Storage Write API (gRPC) 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.
• Informationen zum Optimieren von Tabellenladejobs, um das Erreichen von Kontingentlimits zu vermeiden, finden Sie unter Ladejobs optimieren.

Kontingent für den Kontingentmesswert „Autorisierte Ansichten pro Dataset“ und das Limit „2500“ überschritten.

Wenn die Zugriffssteuerungsliste eines Datasets das kombinierte Limit für autorisierte Ressourcen überschreitet, gibt BigQuery diese Fehlermeldung zurück.

Fehlermeldung

Quota exceeded for quota metric 'Authorized Views per dataset' and limit '2500'.

Lösung

Die Access Control List eines Datasets kann insgesamt bis zu 2.500 autorisierte Ressourcen enthalten, darunter autorisierte Ansichten, autorisierte Datasets und autorisierte Funktionen. Wenn Sie dieses Limit aufgrund einer großen Anzahl autorisierter Ansichten überschreiten, sollten Sie die Ansichten in autorisierten Datasets gruppieren. Als Best Practice sollten Sie zusammengehörige Ansichten in autorisierten Datasets gruppieren, wenn Sie neue BigQuery-Architekturen entwerfen, insbesondere mandantenfähige Architekturen.

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 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.

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.

Fehler beim Erstellen von regionsübergreifenden Dataset-Replikaten

BigQuery gibt diesen Fehler (reason: apiLimitExceeded) zurück, wenn Sie die regionenübergreifende Dataset-Replikation (ALTER SCHEMA ... ADD REPLICA) konfigurieren und die maximale Anzahl von Dataset-Replikaten überschreiten, die für eine Region innerhalb eines rollierenden Zeitfensters hinzugefügt werden können.

Fehlermeldung

API limit exceeded: Cannot add more than LIMIT replicas for a region within WINDOW day(s)

Diagnose

Dieser Fehler tritt häufig auf, wenn ein automatisiertes Script oder ein IaC-Tool (Infrastructure as Code) wiederholt Dataset-Replikate (ADD REPLICA und DROP REPLICA) in einer Schleife erstellt und löscht.

Lösung

So beheben Sie diesen Fehler:

• Automatisierung von Audits und Infrastructure-as-Code-Skripts Prüfen Sie alle Terraform-Konfigurationen, Bereitstellungsskripts oder geplanten Jobs, die Dataset-Replikate verwalten, um sicherzustellen, dass Replikate nicht bei jeder Ausführung wiederholt gelöscht und neu erstellt werden.
• Warten Sie, bis das rollierende Zeitfenster abgelaufen ist. Warten Sie, bis das in der Fehlermeldung angegebene rollierende Tagesfenster abgelaufen ist, bevor Sie ALTER SCHEMA ... ADD REPLICA für diese Region noch einmal ausführen.

Ihr Nutzer hat das Kontingent für gleichzeitige project.lists-Anfragen überschritten

Dieser Fehler tritt auf, wenn Microsoft Power BI-Jobs, die über einen Simba ODBC-Treiber oder DataHub mit BigQuery kommunizieren, fehlschlagen, weil sie das API-Limit von project.list überschreiten. Verwenden Sie die in diesem Abschnitt beschriebenen kurz- oder langfristigen Behelfslösungen, um dieses Problem zu beheben.

Fehlermeldung

Your user exceeded quota for concurrent project.lists requests

Diagnose

Dieser Fehler tritt während der Verbindungs- und Erkennungsphase für Power BI auf, wenn ein Power BI-Bericht aktualisiert wird und der Simba-Treiber eine Verbindung zu einem bestimmten BigQuery-Projekt herstellt.

Kurzfristige Lösung

Verwenden Sie die folgenden Problemumgehungen, um dieses Problem kurzfristig zu beheben. Sie sind nach ihrer Wirksamkeit geordnet. Implementieren Sie die dritte oder vierte Lösung, je nachdem, ob Sie über den Simba-Treiber oder über DataHub eine Verbindung zu BigQuery herstellen.

Informationen zu langfristigen Lösungen finden Sie unter Langfristige Lösung.

1. Berichtsaktualisierungen staffeln: Wenn Sie den DSN nicht ändern können, können Sie das Kontingentproblem beheben, indem Sie die Anzahl der gleichzeitigen Anfragen reduzieren. Anstatt alle Berichte gleichzeitig zu aktualisieren (z. B. um 9:00 Uhr), sollten Sie die Zeitpläne um einige Minuten versetzen (z. B. um 9:01 Uhr, 9:03 Uhr und 9:05 Uhr). So werden API-Aufrufe über einen längeren Zeitraum verteilt, sodass das Limit für gleichzeitige Aufrufe seltener erreicht wird.

2. Wiederholungsversuche in Power BI implementieren Diese reaktive Strategie hilft, einen Bericht nach einem vorübergehenden Fehler wiederherzustellen. Power BI verfügt über eine integrierte Wiederholungslogik für Fehler bei der Datenaktualisierung. Diese Vorgehensweise verhindert zwar nicht den Kontingentfehler, macht Ihre Pipeline aber widerstandsfähiger, da ein Bericht bei einem nachfolgenden Versuch erfolgreich erstellt werden kann, nachdem die anfängliche Spitze bei den API-Aufrufen abgeklungen ist. So implementieren Sie diese Korrektur:

   1. Rufen Sie im Power BI-Dienst die Einstellungen für Ihr Dataset auf.
   2. Maximieren Sie den Bereich Geplante Aktualisierung. Konfigurieren Sie unter Wiederholen Power BI so, dass eine fehlgeschlagene Aktualisierung automatisch wiederholt wird.

3. Geben Sie bei früheren Versionen des Simba-Treibers die Projekt-ID in der ODBC-Verbindung an. Dadurch wird verhindert, dass der Treiber den projects.list-Erkennungsaufruf ausführt. Stattdessen stellt der Treiber eine direkte Verbindung zum angegebenen Projekt her. Dadurch werden unnötige API-Aufrufe vermieden und das Kontingentproblem wird behoben.

   Neuere Treiber schlagen sofort fehl, wenn das Projekt nicht angegeben ist. Es wird eine Meldung wie Unable to establish connection with data source. Missing settings: {[Catalog]} angezeigt.

   So beheben Sie das Problem:

   1. Öffnen Sie auf dem Computer, auf dem das Power BI-Gateway oder Power BI Desktop ausgeführt wird, die Anwendung ODBC-Datenquellen (64-Bit).
   2. Geben Sie auf dem Hauptbildschirm für die Einrichtung des Simba ODBC-Treibers für BigQuery im Feld Katalog (Projekt) Ihre spezifische Google Cloud -Projekt-ID ein, z. B. my-gcp-project-id.

4. Geben Sie bei früheren Versionen von DataHub die Projekt-ID in der DataHub-Aufnahmekonfiguration an. Nehmen Sie diese Korrektur vor, wenn Sie DataHub anstelle des Simba-Treibers verwenden. Ähnlich wie bei Simba müssen Sie bei späteren Versionen von DataHub die Projekt-ID angeben, da sonst keine Verbindung zu BigQuery hergestellt wird.

   Um die DataHub-Limits nicht zu überschreiten, ändern Sie Ihre DataHub-Aufnahmekonfiguration so, dass eine explizite Liste der zu scannenden Projekt-IDs bereitgestellt wird. Dadurch wird verhindert, dass die DataHub-Konfiguration alle Projekte findet, die das Dienstkonto sehen kann.

   Verwenden Sie in der BigQuery-Quellrezeptdatei (normalerweise eine YAML-Datei) die project_ids-Konfiguration, um die Projekte aufzulisten, die Sie aufnehmen möchten. Stellen Sie dann das DataHub-Aufnahmerezept mit der neuen Konfiguration noch einmal bereit. Sehen Sie sich das folgende Beispiel und dieses längere Beispiel von DataHub an.

   Hier ein Beispiel für ein DataHub-Konfigurations-Snippet:

     source:
     type: "bigquery"
     config:
       # Instead of relying on discovery, explicitly list the projects.
       # This avoids the problematic projects.list() API call.
       project_ids:
       -  "YOUR_PRODUCTION_PROJECT_ID"
       -  "YOUR_ANALYTICS_PROJECT_ID"
       -  "ANOTHER_BQ_PROJECT"

Langfristige Lösung

Die beste langfristige Lösung für diese Fehlermeldung besteht darin, für jede Funktion separate, dedizierteGoogle Cloud -Dienstkonten zu erstellen. Erstellen Sie beispielsweise ein Dienstkonto für alle Power BI-Berichte und ein Dienstkonto für die DataHub-Aufnahme.

Mit dieser Best Practice wird die API-Nutzung in separate Kontingent-Buckets isoliert und verhindert, dass ein Job mit hoher Last in DataHub dazu führt, dass kritische Geschäftsberichte in Power BI fehlschlagen.

Verwenden Sie den Aktionsplan in den folgenden Abschnitten, um langfristige Kontingentfehler in Power BI und DataHub zu beheben.

Phase 1: Vorbereitung

1. Informieren Sie die Inhaber der Power BI-Gateways und der DataHub-Konfiguration, dass Sie koordinierte Änderungen vornehmen werden, um die laufenden Jobfehler zu beheben.
2. Erstellen Sie in der Google Cloud Console zwei neue Dienstkonten, z. B. sa-powerbi-gateway@... und sa-datahub-ingestion@....
3. Erstellen Sie Dienstkontoschlüssel für die Power BI- und DataHub-Dienstkonten.
4. Gewähren Sie jedem neuen Dienstkonto die geringsten Berechtigungen, indem Sie die folgenden IAM-Rollen zuweisen, mit denen es seine Aufgaben im relevanten IAM (Identity and Access Management) ausführen kann. Vermeiden Sie es, zu allgemeine Rollen zuzuweisen, z. B. ProjectEditor.

Erforderliche Rollen

Das Dienstkonto für Power BI führt Abfragen aus und liest Daten aus Tabellen. Weisen Sie Dienstkonten in jedem Google Cloud -Projekt, das Daten enthält, auf die Power BI zugreifen muss, die folgenden Rollen zu. Weitere Informationen zu diesen Rollen finden Sie unter BigQuery-Rollen.

• BigQuery-Datenbetrachter: bietet Lesezugriff auf Datasets, Tabellen und Ansichten.
• BigQuery-Jobnutzer: Gewährt Berechtigungen zum Ausführen von Jobs, einschließlich Abfragen, was für Power BI zum Ausführen von Anfragen erforderlich ist.

Das Dienstkonto für die DataHub-Aufnahme muss nur Metadaten wie Tabellennamen, Schemas und Beschreibungen lesen, nicht die Daten in den Tabellen. Weisen Sie die folgende Rolle auf Projektebene für jedes Projekt zu, das von DataHub gescannt wird. Weitere Informationen zu diesen Rollen finden Sie unter IAM-Rollen für BigQuery.

BigQuery-Metadatenbetrachter: Diese Rolle ist speziell für das Lesen von Metadaten vorgesehen. Sie gewährt Berechtigungen zum Auflisten von Datasets und Tabellen und zum Aufrufen ihrer Metadaten, ohne Zugriff auf die zugrunde liegenden Daten zu gewähren.

Phase 2: Koordinierte Einführung

Während eines Nutzungszeitraums mit geringer Auslastung aktualisiert der Power BI-Administrator die ODBC-DSN-Konfigurationen auf den Gateway-Maschinen. Dazu führt er die folgenden Schritte aus:

1. Ändert die Authentifizierungsmethode, um den neuen Dienstkontoschlüssel sa-powerbi-gateway@... zu verwenden, der in einem vorherigen Schritt erstellt wurde.
2. Falls noch nicht als kurzfristige Lösung geschehen, wird die Projekt-ID Google Cloudin das Feld Katalog (Projekt) des ODBC-Treibers eingegeben.
3. Der DataHub-Inhaber aktualisiert die YAML-Datei für die BigQuery-Quellkonfiguration.
4. Verweist auf den neuen sa-datahub-ingestion@...-Dienstkontoschlüssel, der in einem vorherigen Schritt erstellt wurde.
5. Wenn dies nicht bereits als kurzfristige Lösung erfolgt ist, verwenden Sie den Parameter project_ids, um die zu scannenden Projekte explizit aufzulisten.
6. Stellt das DataHub-Aufnahmerezept mit der neuen Konfiguration noch einmal bereit.

Phase 3: Verifizierung und Kontrolle

Die Power BI- und DataHub-Administratoren führen die folgenden Schritte aus, um die Auswirkungen der Korrekturen zu prüfen und zu überwachen:

1. Aktualisieren Sie manuell einige wichtige Power BI-Berichte und einen neuen Aufnahmevorgang in DataHub. Prüfen Sie, ob diese Jobs erfolgreich abgeschlossen werden, ohne dass Kontingentfehler auftreten.
2. Damit der Fehler Quota exceeded: Your user exceeded quota for concurrent project.lists requests nicht mehr auftritt, sollten Sie Ihre Anwendungsprotokolle oder den Ausführungsverlauf Ihres Business-Intelligence-Tools im Blick behalten.

3. Optional: Prüfen Sie, ob das Gesamtvolumen der projects.list-API-Aufrufe oder der zugehörigen 403-Fehler für die zugehörigen Dienstkonten abgenommen hat:

   1. Rufen Sie in der Google Cloud Console die Seite API-/Dienstdetails der BigQuery API auf.

      Zu „APIs und Dienste“

   2. Sehen Sie sich die Dashboards auf dem Tab Messwerte an, um den Rückgang des Aufrufvolumens und der zugehörigen 403-Fehler zu prüfen.

Administratoren sollten einen drastischen und dauerhaften Rückgang der Nutzung dieses spezifischen API-Aufrufs feststellen, was bestätigt, dass die Fehlerbehebung erfolgreich war.