Fehlerbehebung bei BigQuery-Abos

Auf dieser Seite finden Sie einige Tipps zur Fehlerbehebung bei BigQuery-Abos.

Status eines BigQuery-Abos prüfen

So prüfen Sie den Status eines Abos:

  1. Rufen Sie in der Google Cloud Console die Seite „Pub/Sub-Abos“ auf.

    Zu den Abos

  2. Prüfen Sie das Symbol für den Status Ihres BigQuery-Abos.

    Wenn das Symbol ein grünes Häkchen ist, ist das Abo in Ordnung.

    Wenn das Symbol ein rotes Ausrufezeichen ist, befindet sich das Abo in einem Fehlerstatus.

  3. Klicken Sie auf das BigQuery-Abo.

    Die Seite mit den Abodetails wird geöffnet.

  4. Prüfen Sie unter Abostatus, ob eine Fehlermeldung angezeigt wird.

  5. Je nach Fehlermeldung rufen Sie den entsprechenden Abschnitt auf dieser Seite auf, um das Problem zu beheben.

Nachdem das Problem behoben wurde, kehrt das Abo in den normalen Status zurück.

Abo kann nicht erstellt oder aktualisiert werden

Im Folgenden finden Sie einige der häufigsten Probleme, die beim Erstellen oder Aktualisieren eines BigQuery-Abos auftreten können.

Fehler „Tabelle nicht gefunden“

Wenn die im Workflow zum Erstellen oder Aktualisieren von Abos angegebene Tabelle nicht vorhanden ist, gibt der Workflow den Fehler „Tabelle nicht gefunden“ zurück. In der Google Cloud Console sieht die Meldung in etwa so aus:

The BigQuery table or dataset specified cannot be found.

Um das Problem zu beheben, erstellen Sie die Tabelle und prüfen Sie den Status, bevor Sie sie mit einem BigQuery-Abo verwenden.

Fehler: Schema stimmt nicht überein

Wenn die Schemas der Tabelle und des Themas nicht kompatibel sind, gibt der Workflow zum Erstellen oder Aktualisieren von Abos einen Fehler aufgrund von Schemaabweichungen zurück. In der Google Cloud Console sieht die Meldung in etwa so aus:

Incompatible schema type for field project_ids: expected INT64, got STRING

Die angegebene Fehlermeldung bezieht sich auf eine Schemaabweichung für ein Feld namens project_ids. Je nach Art der Schemadiskrepanz wird möglicherweise eine andere Variante der Fehlermeldung angezeigt.

Prüfen Sie, ob die Schemazuordnungen kompatibel sind, um das Problem zu beheben.

Fehler bei Dienstkontoverwendung

Wenn Sie das Pub/Sub-Dienstkonto nicht mit den richtigen Berechtigungen konfiguriert haben, gibt der Workflow zum Erstellen oder Aktualisieren von Abos einen Fehler zurück. In der Google Cloud Console sieht die Meldung in etwa so aus:

Service account service-1234234234@gcp-sa-pubsub.iam.gserviceaccount.com
is missing permissions required to write to the BigQuery table:
bigquery.tables.get, bigquery.tables.updateData.

Prüfen Sie, ob das Dienstkonto die richtigen Berechtigungen hat, um das Problem zu beheben.

Der Abostatus zeigt ein rotes Ausrufezeichen an

Wenn Sie die Tabelle bearbeiten, nachdem Sie ein Abo erstellt haben, kann sich das darauf auswirken, wie Pub/Sub Nachrichten in die Tabelle schreibt. Wenn eine Änderung zu einem Problem führt, wird das Statusfeld des Abos auf einen Fehlerstatus gesetzt.

Prüfe auf der Seite mit den Abodetails den Status des Felds Subscription state. Das Feld Subscription state enthält einen genaueren Fehler, der einer der folgenden sein kann:

  • table not found: Die Tabelle wurde gelöscht. Erstellen Sie eine Tabelle und prüfen Sie den Status der Tabelle. Weitere Informationen finden Sie unter Tabelleninformationen abrufen.

  • Tabellenberechtigung verweigert: Das Pub/Sub-Dienstkonto hat keine Berechtigung mehr zum Schreiben in die Tabelle. Prüfen Sie, ob das Dienstkonto die richtigen Berechtigungen hat.

  • Nicht übereinstimmendes Tabellenschema: Das Tabellenschema ist nicht mehr mit den BigQuery-Aboeinstellungen kompatibel. Prüfen Sie, ob die Schemaabgleiche kompatibel sind.

Solange sich ein Pub/Sub-Abo im Fehlerstatus befindet, werden keine Nachrichten in die BigQuery-Tabelle geschrieben. Sie verbleiben im Abobacklog. Hinweis: Nachrichten werden nicht an ein angehängtes Thema für unzustellbare Nachrichten zugestellt, sofern konfiguriert. Nicht bestätigte Nachrichten werden für den in message_retention_duration festgelegten Zeitraum aufbewahrt(standardmäßig 7 Tage).

Es baut sich ein Backlog auf

Wenn sich im Abo ein Rückstau von Nachrichten ansammelt oder Nachrichten an das Thema für unzustellbare Nachrichten eines Abos weitergeleitet werden, sehen Sie sich die folgenden möglichen Ursachen an.

Fehlermeldung INVALID_ARGUMENT

Dieser Fehler tritt auf, wenn die Nachricht in einem Format vorliegt, das von Pub/Sub als gültig, vom BigQuery-Zieltabellenschema jedoch nicht als gültig erachtet wird. Das bedeutet, dass mindestens ein Feld in der Nachricht Werte enthält, die vom BigQuery-Tabellenschema nicht zulässig sind. Prüfen Sie die Schemakompatibilität, um sicherzustellen, dass die Datentypen und Formate korrekt sind. Zu den häufigsten Fehlern gehören:

  • Ein leerer String ("") ist kein gültiges JSON-Format. Wenn Sie Daten an eine nullable JSON-BigQuery-Tabellenspalte senden, geben Sie entweder ein leeres JSON-Objekt ({}), null oder einen leeren JSON-String ("\"\"") für fehlende Werte an. Das Senden eines leeren Strings führt zu einem Fehler.

  • Wenn der Wert eines Nachrichtenfelds die maximale Länge des BigQuery-Felds überschreitet, schlägt die Nachricht aufgrund von Größenbeschränkungen fehl.

Wenn Sie INVALID_ARGUMENT-Fehler beheben möchten, fügen Sie dem betreffenden Abo ein Thema für unzustellbare Nachrichten hinzu. Das Thema für unzustellbare Nachrichten enthält Nachrichten, die nicht in BigQuery geschrieben werden konnten, sowie das Attribut CloudPubSubDeadLetterSourceDeliveryErrorMessage, das den Grund für den Fehler angibt.

Diese Übermittlungsfehler sind auch im Metrics Explorer zu sehen. Wählen Sie den Messwert pubsub.googleapis.com/subscription/push_request_count aus und filtern Sie nach response_code=invalid_argument.

Fehlermeldung RESOURCE_EXHAUSTED

Wenn Nachrichten nur langsam in BigQuery geschrieben werden, müssen Sie möglicherweise das Pub/Sub-Push-Kontingent oder das BigQuery-Speicherkontingent für den Schreibdurchsatz Ihres Projekts erhöhen. Prüfen Sie, ob Kontingentlimits erreicht wurden, indem Sie den Messwert „Pushanfragen“ (subscription/push_request_count) auf resource_exhausted-Fehler prüfen.

Eine weitere Möglichkeit, Kontingentprobleme zu diagnostizieren, besteht darin, das Kontingent des Projekts zu prüfen. Gehen Sie im Projekt mit Ihrer Pub/Sub-Ressource oder BigQuery-Instanz zu IAM und Verwaltung > Kontingente. Suchen Sie nach dem entsprechenden Kontingent, entweder pubsub.googleapis.com/regionalpushsubscriber oder bigquerystorage.googleapis.com/write/append_bytes. Wenn eines der Kontingente erhöht werden muss, können Sie ein höheres Kontingent anfordern.

Stündlich partitionierte Tabelle mit __UNPARTITIONED__ in der Partitions-ID-Spalte

Wenn eine BigQuery-Zieltabelle nach Stunde partitioniert ist, landen Zeilen zuerst in einer speziellen Partition mit der Bezeichnung __UNPARTITIONED__ in der INFORMATION_SCHEMA.PARTITIONS-Ansicht. Das ist bei Tabellen mit Partitionierung nach Aufnahmezeit normal.

BigQuery verwendet einen Streaming-Puffer, um den Schreibvorgang zu optimieren. Daten können sich in der __UNPARTITIONED__-Partition befinden, bis ein ausreichendes Volumen erreicht ist oder mindestens eine Stunde vergangen ist. Sobald diese Bedingungen erfüllt sind, partitioniert BigQuery die Daten neu in die entsprechende stündliche Partition.

Sie können Daten in der Partition __UNPARTITIONED__ über die Ansicht INFORMATION_SCHEMA.PARTITIONS überwachen.

Nächste Schritte

  • Wenn weiterhin Probleme mit Ihrem BigQuery-Abo auftreten, lesen Sie den Hilfeartikel Support erhalten.