Résoudre les problèmes liés aux abonnements BigQuery

Cette page fournit quelques conseils de dépannage courants pour les abonnements BigQuery.

Vérifier l'état d'un abonnement BigQuery

Pour vérifier l'état d'un abonnement, procédez comme suit:

  1. Dans la console Google Cloud, accédez à Pub/Sub page d'abonnement.

    Accéder aux abonnements

  2. Vérifiez l'icône d'état de votre abonnement BigQuery.

    Si l'icône est une coche verte, cela signifie que l'abonnement est opérationnel.

    Si l'icône est un point d'exclamation rouge, cela signifie que l'abonnement est en état d'erreur.

  3. Cliquez sur l'abonnement BigQuery.

    La page des détails de l'abonnement s'ouvre.

  4. Vérifiez si le message d'erreur s'affiche dans l'état de l'abonnement.

  5. En fonction du message d'erreur, accédez à la section correspondante pour résoudre le problème.

Une fois le problème résolu, l'abonnement revient à est opérationnel.

Impossible de créer ou de mettre à jour l'abonnement

Voici quelques-uns des problèmes courants que vous pourriez rencontrer si vous rencontrez des difficultés pour créer ou mettre à jour un abonnement BigQuery.

Erreur "Table introuvable"

Si la table que vous spécifiez dans le workflow de création ou de mise à jour d'un abonnement n'existe pas, le workflow renvoie une erreur de table introuvable. Dans la console Google Cloud, le message ressemble à ce qui suit:

The BigQuery table or dataset specified cannot be found.

Pour résoudre le problème, créez la table et assurez-vous de pouvoir vérifier son état ; avant de l'utiliser avec un abonnement BigQuery.

Erreur de correspondance du schéma

Si les schémas de la table et du sujet ne sont pas compatibles, le workflow de création ou de mise à jour d'un abonnement renvoie une erreur d'incohérence de schéma. Dans la console Google Cloud, le message ressemble à ce qui suit:

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

Le message d'erreur spécifié concerne une incohérence au niveau du schéma d'un champ nommé project_ids. Selon le type de non-concordance des schémas, vous pouvez une variante différente du message d'erreur.

Pour résoudre le problème, vérifiez si les mappages de schémas sont compatibles.

Erreur de compte de service

Si vous n'avez pas configuré le compte de service Pub/Sub avec le les bonnes autorisations, puis le workflow de création ou de mise à jour d'un abonnement renvoie une erreur. Dans la console Google Cloud, le message ressemble à ce qui suit:

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.

Pour résoudre le problème, vérifiez si le compte de service les autorisations appropriées.

L'état de l'abonnement affiche un point d'exclamation rouge.

Si vous modifiez le tableau après avoir créé un abonnement, cela peut affecter comment Pub/Sub écrit les messages dans la table. Si une modification entraîne un numéro, le champ "state" de l'abonnement définies sur un état d'erreur ;

Sur la page d'informations de l'abonnement, vérifiez l'état du champ Subscription state. Le champ Subscription state fournit une erreur plus spécifique, Il peut s'agir de l'un des éléments suivants:

  • table not found: la table est supprimée. Créer une table et vérifier son état. Consultez la section Obtenir des informations sur une table.

  • autorisation table refusée: le compte de service Pub/Sub n'a plus l'autorisation d'écrire dans la table. Vérifiez si le compte de service les autorisations appropriées.

  • Différence de schéma de table: le schéma de la table n'est plus compatible avec le Paramètres d'abonnement BigQuery. Vérifier si le schéma les mappages sont compatibles.

Lorsqu'un abonnement Pub/Sub est en état d'erreur, les messages ne sont pas écrits dans la table BigQuery les tâches d'abonnement en attente. Notez que les messages ne sont pas distribués à un a joint une lettre morte, si elle est configurée. Les messages non confirmés sont conservés pour la période définie dans message_retention_duration(7 jours, par défaut).

Un backlog s'accumule

Si vous constatez une accumulation de messages en attente dans l'abonnement ou les messages à la file d'attente des lettres mortes d'un abonnement, examinez causes.

Message d'erreur INVALID_ARGUMENT

Cette erreur se produit lorsque le message fourni est dans un format que Pub/Sub considère comme valide, mais pas le schéma de la table de destination BigQuery. Cela signifie qu'un ou plusieurs champs du message comportent des valeurs qui ne sont pas autorisé par le schéma de la table BigQuery. Consultez les compatibilité du schéma pour vérifier que les types et les formats de données sont corrects. Voici quelques-unes des erreurs les plus courantes incluent:

  • Une chaîne vide ("") n'est pas un fichier JSON valide. Lors de l'envoi de données à une instance nullable Colonne de table BigQuery JSON, fournissez un objet JSON ({}) vide, null ou une chaîne JSON vide ("\"\"") pour représenter les valeurs manquantes. Envoi en cours une chaîne vide entraîne une erreur.

  • Si la valeur d'un champ de message dépasse la longueur maximale du champ BigQuery, le message échoue en raison de limitations de taille.

Pour résoudre les erreurs liées à INVALID_ARGUMENT, ajoutez un de lettres mortes au qui vous intéresse. Le sujet des lettres mortes capture les messages qui n'ont pas pu être écrites dans BigQuery, avec un attribut appelé CloudPubSubDeadLetterSourceDeliveryErrorMessage qui explique la raison de l'échec.

Ces échecs de distribution sont également visibles dans l'Explorateur de métriques. Sélectionnez la métrique pubsub.googleapis.com/subscription/push_request_count, puis filtrer par response_code=invalid_argument.

Message d'erreur RESOURCE_EXHAUSTED

Si les messages sont écrits lentement dans BigQuery, vous devrez peut-être augmentez le quota d'envoi Pub/Sub ou l'espace de stockage BigQuery de votre projet quota de débit en écriture. Pour vérifier si vous rencontrez des limites de quota, Examiner la métrique des requêtes push (subscription/push_request_count) pour les erreurs resource_exhausted.

Un autre moyen de diagnostiquer les problèmes de quota consiste à vérifier le quota du projet. Itinéraire à IAM et Admin > Quotas au sein du projet contenant vos données Pub/Sub ressource ou à l'instance BigQuery. Recherchez le quota concerné : pubsub.googleapis.com/regionalpushsubscriber ou bigquerystorage.googleapis.com/write/append_bytes Si l'un des quotas nécessite vous pouvez demander un quota plus élevé.

Table partitionnée par heure affichant __UNPARTITIONED__ dans la colonne "ID de partition"

Lorsqu'une table de destination BigQuery est partitionnée par heure, les lignes atterrit initialement sur une partition spéciale nommée __UNPARTITIONED__ dans le Vue INFORMATION_SCHEMA.PARTITIONS. Il s'agit d'un comportement attendu pour les tables utilisant le partitionnement par date d'ingestion.

BigQuery utilise un tampon de flux de données pour optimiser le processus d'écriture. Les données peuvent résider dans la partition __UNPARTITIONED__ jusqu'à ce que le volume soit suffisant ou au moins une heure s'est écoulée. Une fois ces conditions remplies, BigQuery repartitionne les données dans la partition horaire appropriée.

Vous pouvez surveiller les données de la partition __UNPARTITIONED__ à l'aide de la méthode Vue INFORMATION_SCHEMA.PARTITIONS.

Étape suivante

  • Si vous rencontrez toujours des problèmes avec votre consultez l'article Obtenir de l'aide.