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 à la page d'abonnement Pub/Sub.

    Accéder aux abonnements

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

    Si l'icône est une coche verte, l'abonnement est en bon état.

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

  3. Cliquez sur l'abonnement BigQuery.

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

  4. Consultez l'état de l'abonnement pour obtenir le message d'erreur.

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

Une fois le problème résolu, l'abonnement finit par revenir à un état normal.

Impossible de créer ou de modifier l'abonnement

Voici quelques-uns des problèmes courants que vous pouvez rencontrer si vous ne parvenez pas à créer ni à modifier 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 indiquant que la table est 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 d'incompatibilité du schéma

Si les schémas de la table et du thème ne sont pas compatibles, le workflow de création ou de mise à jour de l'abonnement renvoie une erreur d'incompatibilité 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 de schéma pour un champ appelé project_ids. Selon le type d'incompatibilité de schéma que vous rencontrez, vous pouvez voir une variante différente du message d'erreur.

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

Erreur de compte de service

Si vous n'avez pas configuré le compte de service Pub/Sub avec les autorisations appropriées, le workflow de création ou de mise à jour de l'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 ce problème, vérifiez que le compte de service dispose des autorisations appropriées.

Un point d'exclamation rouge s'affiche à côté de l'état de l'abonnement

Si vous modifiez la table après avoir créé un abonnement, cela peut affecter la façon dont Pub/Sub écrit les messages dans la table. Si une modification entraîne un problème, le champ d'état de l'abonnement est défini 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, qui peut être l'une des suivantes :

  • table not found (table introuvable) : la table est supprimée. Créez une table et vérifiez son état. Consultez Obtenir des informations sur les tables.

  • Autorisation refusée pour la table : le compte de service Pub/Sub n'est plus autorisé à écrire dans la table. Vérifiez si le compte de service dispose des autorisations appropriées.

  • Schéma de table incompatible : le schéma de table n'est plus compatible avec les paramètres d'abonnement BigQuery. Vérifiez si les mappages de schéma sont compatibles.

Lorsqu'un abonnement Pub/Sub est en état d'erreur, les messages ne sont pas écrits dans la table BigQuery et restent dans le backlog de l'abonnement. Notez que les messages ne sont pas distribués à une file d'attente de lettres mortes associée, si elle est configurée. Les messages non confirmés sont conservés pendant la période définie dans message_retention_duration(sept jours par défaut).

Un backlog est en train de se constituer

Si vous constatez une accumulation de messages en attente dans l'abonnement ou des messages envoyés vers la file d'file d'attente de lettres mortes d'un abonnement, examinez les causes possibles suivantes.

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 contiennent des valeurs non autorisées par le schéma de la table BigQuery. Consultez la compatibilité du schéma pour vérifier que les types et formats de données sont corrects. Voici quelques-unes des erreurs les plus courantes :

  • Une chaîne vide ("") n'est pas un fichier JSON valide. Lorsque vous envoyez des données à une colonne de table BigQuery JSON pouvant accepter la valeur "null", fournissez un objet JSON vide ({}), null ou une chaîne JSON vide ("\"\"") pour représenter les valeurs manquantes. L'envoi d'une chaîne vide génère 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 problèmes liés aux erreurs INVALID_ARGUMENT, ajoutez un sujet de lettres mortes à l'abonnement qui vous intéresse. La file d'attente de lettres mortes capture les messages qui n'ont pas pu être écrits dans BigQuery, ainsi qu'un attribut appelé CloudPubSubDeadLetterSourceDeliveryErrorMessage qui explique la raison de l'échec.

Vous pouvez également consulter ces échecs de remise dans l'explorateur de métriques. Sélectionnez la métrique pubsub.googleapis.com/subscription/push_request_count et filtrez par response_code=invalid_argument.

Message d'erreur RESOURCE_EXHAUSTED

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

Une autre façon de diagnostiquer les problèmes de quota consiste à vérifier le quota du projet. Accédez à IAM et administration > Quotas dans le projet contenant votre ressource Pub/Sub ou votre instance BigQuery. Recherchez le quota concerné, pubsub.googleapis.com/regionalpushsubscriber ou bigquerystorage.googleapis.com/write/append_bytes. Si vous avez besoin d'augmenter l'un ou l'autre de ces quotas, vous pouvez demander un ajustement de quota.

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 sont d'abord placées dans une partition spéciale intitulée __UNPARTITIONED__ dans la vue INFORMATION_SCHEMA.PARTITIONS. Ce comportement est normal pour les tables utilisant le partitionnement par date d'ingestion.

BigQuery utilise un tampon de flux pour optimiser le processus d'écriture. Les données peuvent résider dans la partition __UNPARTITIONED__ jusqu'à ce qu'un volume suffisant soit accumulé ou qu'au moins une heure se soit é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 vue INFORMATION_SCHEMA.PARTITIONS.

Étapes suivantes

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