Fehler bei der BigQuery Storage API beheben

In diesem Dokument wird beschrieben, wie Sie Probleme beheben, wenn Sie Daten in BigQuery mit der BigQuery Storage Read API, der BigQuery Storage Write API (gRPC) oder Streaming-Einfügungen mit der BigQuery Storage Write API (REST) (tabledata.insertAll-Methode) lesen oder streamen.

Streamingtelemetrie mit INFORMATION_SCHEMA-Ansichten analysieren

Sie können INFORMATION_SCHEMA-Ansichten abfragen, um den Zustand der Streamingaufnahme zu überwachen, Engpässe beim Durchsatz zu ermitteln und Fehlercodes in Intervallen von einer Minute zu prüfen:

Im folgenden Beispiel wird INFORMATION_SCHEMA.WRITE_API_TIMELINE_BY_PROJECT abgefragt, um die Anzahl der Fehler und die aufgenommenen Byte für die Storage Write API (gRPC) in den letzten 24 Stunden abzurufen:

SELECT
  start_timestamp,
  error_code,
  SUM(total_requests) AS request_count,
  SUM(total_input_bytes) AS input_bytes
FROM
  `region-REGION`.INFORMATION_SCHEMA.WRITE_API_TIMELINE_BY_PROJECT
WHERE
  start_timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  AND error_code IS NOT NULL
GROUP BY
  start_timestamp,
  error_code
ORDER BY
  start_timestamp DESC;

Ersetzen Sie REGION durch den Namen der Dataset-Region, z. B. us oder europe-west1.

Fehler bei der Storage Read API beheben

Die folgenden Fehler treten häufig auf, wenn Sie die Storage Read API verwenden:

Fehler: Stream removed
Lösung:Wiederholen Sie die Storage Read API-Anfrage. Dies ist wahrscheinlich ein vorübergehender Fehler, den Sie durch Wiederholen der Anfrage beheben können. Wenn das Problem weiterhin besteht, wenden Sie sich an Cloud Customer Care.
Fehler: Stream expired

Ursache:Dieser Fehler tritt auf, wenn die Storage Read API-Sitzung das 6-Stunden-Zeitlimit erreicht.

Lösung:

  1. Erhöhen Sie die Parallelität des Jobs.
  2. Wenn die CPU-Auslastung der Worker-Knoten relativ konstant ist und 85 % nicht überschreitet, sollten Sie den Job auf einem größeren Maschinentyp ausführen.
  3. Teilen Sie den Job in mehrere Jobs oder kleinere Abfragen auf.

Weitere Informationen zur Sitzungsverwaltung und zum Lesen von Daten finden Sie in der Übersicht über die Storage Read API.

Fehler bei Streaming-Insert-Anweisungen beheben

In den folgenden Abschnitten wird die Fehlerbehebung beim Streamen von Daten in BigQuery mit der Storage Write API (REST) erörtert. Weitere Informationen zum Beheben von Kontingentfehlern für Streaming-Insert-Anweisungen finden Sie unter Kontingentfehler für Streaming-Insert-Anweisungen.

HTTP-Fehlerantwortcodes

Wenn Sie einen HTTP-Antwortcode erhalten, z. B. bezüglich eines Netzwerkfehlers, lässt sich nicht feststellen, ob die Streaming-Insert-Anweisung erfolgreich war. Wenn Sie die Anfrage noch einmal senden, könnte eine Tabellenzeile doppelt auftreten. Um eine Duplizierung in Ihrer Tabelle zu verhindern, legen Sie beim Senden der Anfrage das Attribut insertId fest. BigQuery verwendet das Attribut insertId für die Deduplizierung.

Wenn Sie einen Berechtigungsfehler, einen Fehler aufgrund eines ungültigen Tabellennamens oder einen Fehler aufgrund eines überschrittenen Kontingents erhalten, werden keine Zeilen eingefügt und die gesamte Anfrage schlägt fehl.

HTTP-Erfolgsantwortcodes

Selbst wenn Sie einen HTTP-Erfolgsantwortcode erhalten, müssen Sie anhand des Attributs insertErrors der Antwort prüfen, ob die Zeileneinfügungen durch BigQuery erfolgreich waren. Es kann nämlich sein, dass sie nur teilweise gelungen sind. Es kann eine der folgenden Situationen eintreten:

  • Alle Zeilen wurden erfolgreich eingefügt:Wenn das Attribut insertErrors eine leere Liste ist, wurden alle Zeilen erfolgreich eingefügt.
  • Einige Zeilen wurden erfolgreich eingefügt:Außer in Fällen, in denen in einer der Zeilen ein Schema nicht übereinstimmt, werden die im Attribut insertErrors angegebenen Zeilen nicht eingefügt und alle anderen Zeilen wurden erfolgreich eingefügt. Das Attribut errors enthält detaillierte Informationen dazu, warum die entsprechenden Zeilen nicht eingefügt werden konnten. Das Attribut index gibt den 0-basierten Zeilenindex der Anfrage an, auf die sich der Fehler bezieht.
  • Keine Zeilen erfolgreich eingefügt:Wenn BigQuery bei einzelnen Zeilen der Anfrage auf einen Schemakonflikt stößt, wird keine der Zeilen eingefügt und für jede Zeile wird ein insertErrors-Eintrag zurückgegeben, selbst für Zeilen ohne Schemakonflikt. Für Zeilen ohne Schemakonflikt wird ein Fehler angegeben, bei dem das Attribut reason auf stopped gesetzt ist. Diese Zeilen können unverändert noch einmal gesendet werden. Fehlgeschlagene Zeilen enthalten detaillierte Informationen zum Schemakonflikt. Weitere Informationen zu den unterstützten Protokollpuffertypen für jeden BigQuery-Datentyp finden Sie unter Unterstützte Protokollpuffer- und Arrow-Datentypen.

Metadatenfehler bei Streaming-Insert-Anweisungen

Da die BigQuery Streaming API für hohe Einfügeraten konzipiert ist, sind Änderungen an den zugrunde liegenden Tabellenmetadaten bei der Interaktion mit dem Streamingsystem letztendlich konsistent. In den meisten Fällen werden Metadatenänderungen innerhalb von Minuten übernommen. Während dieser Zeit spiegeln API-Antworten jedoch möglicherweise den inkonsistenten Status der Tabelle wider.

Einige Szenarien:

  • Schemaänderungen:Wenn Sie das Schema einer Tabelle ändern, in die vor Kurzem Streaming-Insert-Anweisungen eingefügt wurden, kann dies zu Antworten mit Schemaabweichungsfehlern führen, da das Streamingsystem die Schemaänderung möglicherweise nicht sofort erkennt.
  • Erstellen oder Löschen von Tabellen:Beim Streamen in eine nicht vorhandene Tabelle wird eine Variante der Antwort notFound zurückgegeben. Wenn Sie daraufhin die Tabelle erstellen, wird diese von nachfolgenden Streaming-Insert-Anweisungen unter Umständen nicht sofort erkannt. Wenn Sie eine Tabelle löschen oder neu erstellen, kann es vorkommen, dass Streaming-Einfügungen an die alte Tabelle gesendet werden. Die Streaming-Einfügungen sind möglicherweise nicht in der neuen Tabelle vorhanden.
  • Tabellentruncation:Wenn die Daten einer Tabelle durch einen Abfragejob mit dem writeDisposition-Wert WRITE_TRUNCATE gekürzt werden, können nachfolgende Einfügungen während des Konsistenzzeitraums ebenfalls verloren gehen.

Fehlende oder nicht verfügbare Daten

Streaming-Insert-Anweisungen werden vorübergehend im schreiboptimierten Speicher abgelegt, der andere Verfügbarkeitsmerkmale als ein verwalteter Speicher aufweist. Bestimmte Vorgänge in BigQuery interagieren nicht mit dem schreiboptimierten Speicher, z. B. Tabellenkopierjobs und API-Methoden wie tabledata.list. Aktuelle Streamingdaten sind nicht in der Zieltabelle oder -ausgabe enthalten.

Fehler bei Kontingent für Streaming-Insert-Anweisungen

In diesem Abschnitt finden Sie Tipps zur Fehlerbehebung bei Kontingentfehlern, die beim Streamen von Daten in BigQuery auftreten.

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 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 einzuschließen und stattdessen die 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 1-Minuten-Intervalle hinweg aggregiert und nach error_code gruppiert. 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.