Propriétés d'abonnement

Les propriétés d'abonnement Pub/Sub sont les caractéristiques d'un abonnement. Vous pouvez définir des propriétés d'abonnement lorsque vous créez ou mettez à jour un abonnement.

Ce document décrit les différentes propriétés d'abonnement que vous pouvez définir pour un abonnement.

Avant de commencer

Propriétés d'abonnement courantes

Lorsque vous créez un abonnement, vous devez spécifier un certain nombre d'options pour le configurer. Certaines de ces propriétés sont communes à tous les types d'abonnements et sont décrites dans les sections suivantes.

Durée de conservation des messages

L'option Durée de conservation des messages spécifie la durée pendant laquelle Pub/Sub conserve les messages après publication. Une fois la durée de conservation des messages écoulée, Pub/Sub peut supprimer le message, quel que soit son état de confirmation. Pour conserver les messages confirmés pendant la durée de conservation définie, consultez la page Rouvrir et supprimer définitivement des messages.

Voici les valeurs de l'option Durée de conservation des messages:

  • Valeur par défaut = 7 jours
  • Valeur minimale = 10 minutes
  • Valeur maximale = 31 jours

Les messages non confirmés peuvent résulter d'abonnements inactifs, de besoins de sauvegarde ou d'un traitement lent. Si vous parvenez à traiter les messages dans les 24 heures, les frais supplémentaires ne sont pas facturés. Pour éviter de nouvelles charges, suivez les étapes ci-dessous:

  • Abonnements inactifs Supprimez les abonnements inactifs pour éviter de payer des frais de conservation des messages d'abonnement.

  • Stockage des sauvegardes Si vous utilisez la conservation des abonnements comme stockage de sauvegarde, vous pouvez passer à une autre option de stockage, telle que la conservation des messages de sujet ou la conservation des messages confirmés. La conservation des messages par sujet ne stocke les messages qu'une seule fois au niveau du sujet. Ils restent disponibles pour tous les abonnements à utiliser si nécessaire.

  • Retards de traitement Ajoutez d'autres abonnés (si possible) pour traiter les messages dans un délai d'une journée.

Conserver les messages confirmés

Si vous spécifiez la durée de conservation des messages, vous pouvez également indiquer si vous souhaitez conserver les messages confirmés.

L'option Conserver les messages confirmés vous permet de conserver les messages confirmés pendant la durée de conservation des messages spécifiée. Cette option augmente les frais de stockage des messages. Pour en savoir plus, consultez les coûts de stockage.

Délai d'expiration

L'option Période d'expiration vous permet de prolonger la période d'expiration de votre abonnement.

Les abonnements sans activité de la part des abonnés ni modification apportée aux propriétés de l'abonnement expirent. Si Pub/Sub détecte une activité d'abonné ou si vous mettez à jour l'une des propriétés de l'abonnement, l'horloge de suppression de l'abonnement redémarre. Des exemples d'activités d'abonnés incluent les connexions ouvertes, les actions pull actives ou les push réussis.

Si vous spécifiez la période d'expiration, la valeur doit être supérieure à la durée de conservation des messages spécifiée dans l'option Durée de conservation des messages.

Voici les valeurs de l'option Période d'expiration:

  • Valeur par défaut = 31 jours
  • Valeur minimale = 1 jour

Pour empêcher l'expiration d'un abonnement, définissez le délai d'expiration sur never expire.

Délai de confirmation

L'option Délai de confirmation spécifie le délai initial au bout duquel un message non confirmé est renvoyé. Vous pouvez prolonger le délai de confirmation par message en envoyant des requêtes ModifyAckDeadline ultérieures.

Voici les valeurs de l'option Délai de réponse:

  • Valeur par défaut = 10 secondes
  • Valeur minimale = 10 secondes
  • Valeur maximale = 600 secondes

Dans certains cas, les bibliothèques clientes Pub/Sub peuvent contrôler la fréquence de distribution et modifier dynamiquement le délai de confirmation. Le message peut ainsi être renvoyé avant la date limite de confirmation que vous avez définie. Pour remplacer ce comportement, utilisez minDurationPerAckExtension et maxDurationPerAckExtension. Pour en savoir plus sur l'utilisation de ces valeurs, consultez la section Compatibilité avec la diffusion exactement une fois dans les bibliothèques clientes.

Filtre d'abonnement

Utilisez l'option Filtre d'abonnement pour spécifier une chaîne avec une expression de filtrage. Si un abonnement comporte un filtre, il diffuse uniquement les messages correspondant à ce filtre. Le service Pub/Sub reconnaît automatiquement les messages qui ne correspondent pas au filtre.

  • Vous pouvez filtrer les messages en fonction de leurs attributs, mais pas en fonction des données qu'ils contiennent.

  • Si aucun attribut n'est spécifié, l'abonnement ne filtre pas les messages, et les abonnés reçoivent tous les messages.

  • Une fois appliqués, les filtres ne peuvent pas être modifiés ni supprimés.

Lorsque vous recevez des messages d'un abonnement avec un filtre, des frais de sortie ne vous sont pas facturés pour les messages reconnus par Pub/Sub. Des frais de distribution de messages et de stockage associé à Seek vous sont facturés pour ces messages.

Pour en savoir plus, consultez Filtrer les messages d'un abonnement.

Tri des messages

Lorsque l'option Tri des messages est activée pour un abonnement, les clients abonnés reçoivent les messages publiés dans la même région avec la même clé de tri dans l'ordre dans lequel ils ont été reçus par le service.

Lorsque vous utilisez la distribution ordonnée, les accusés de réception des messages ultérieurs ne sont pas traités tant que les accusés de réception des messages précédents ne sont pas traités.

Les éditeurs doivent envoyer des messages avec une clé de tri afin que Pub/Sub puisse les distribuer dans l'ordre.

Si le tri n'est pas activé, Pub/Sub risque de ne pas distribuer les messages dans l'ordre, même s'ils disposent d'une clé de tri.

Sujet des lettres mortes

Lorsqu'un message ne peut pas être distribué après un nombre défini de tentatives d'envoi ou qu'un abonné ne peut pas en accuser réception, vous pouvez configurer un sujet de lettres mortes dans lequel ces messages peuvent être republiés.

Si vous définissez un sujet de lettres mortes, vous pouvez également spécifier le nombre maximal de tentatives de distribution. Voici les valeurs du nombre maximal de tentatives d'envoi pour le file d'attente de lettres mortes:

  • Valeur par défaut = 5 tentatives de distribution
  • Valeur minimale = 5 tentatives d'envoi
  • Valeur maximale = 100 tentatives d'envoi

Si le file d'attente de lettres mortes se trouve dans un projet différent de celui de l'abonnement, vous devez également spécifier l'ID de projet avec le file d'attente de lettres mortes.

Pour en savoir plus, consultez la section Transfert vers des sujets de lettres mortes.

Stratégie de nouvelle tentative

Si le délai de confirmation arrive à expiration ou si un abonné répond avec un accusé de réception négatif, Pub/Sub peut renvoyer le message. Cette tentative de nouvelle diffusion est appelée stratégie de nouvelle tentative de l'abonnement.

Par défaut, la stratégie de nouvelle tentative d'un abonnement est définie sur Réessayer immédiatement. Avec cette option, Pub/Sub renvoie le message lorsque le délai de confirmation arrive à expiration ou si un abonné répond avec un accusé de réception négatif.

Vous pouvez également définir la valeur sur Réessayer après l'intervalle exponentiel entre les tentatives. Dans ce cas, vous devez spécifier les valeurs maximale et minimale de l'intervalle entre les tentatives.

Voici quelques consignes pour définir les valeurs maximales et minimales entre les tentatives:

  • Si vous définissez la valeur maximale de la durée de latence, la valeur par défaut de la durée minimale de latence est de 10 secondes.

  • Si vous définissez la valeur minimale pour la durée de l'intervalle entre les tentatives, la valeur par défaut de la durée maximale de l'intervalle entre les tentatives est de 600 secondes.

  • L'intervalle maximal entre les tentatives que vous pouvez spécifier est 600 secondes.

Règle de nouvelle tentative et messages groupés

Si les messages se trouvent dans un lot, Pub/Sub démarre l'intervalle exponentiel entre les tentatives lorsque l'un des événements suivants se produit :

  • L'abonné envoie un accusé de réception négatif pour chaque message du lot.

  • Le délai de confirmation expire.

Stratégie de nouvelle tentative et abonnement push

Si vous recevez des messages provenant d'un abonnement push, Pub/Sub peut les renvoyer après l'intervalle entre les tentatives push plutôt que l'intervalle exponentiel entre les tentatives. Lorsque l'intervalle push est plus long que l'intervalle exponentiel, Pub/Sub distribue à nouveau les messages non confirmés après l'intervalle push.

Propriétés des abonnements pull

Lorsque vous configurez un abonnement pull, vous pouvez spécifier les propriétés suivantes.

Diffusion de type "exactement une fois"

Distribution de type "exactement une fois". Si cette valeur est définie, Pub/Sub garantit une distribution de type exactement une fois. Si aucun attribut n'est spécifié, l'abonnement prend en charge la distribution au moins une fois pour chaque message.

Propriétés des abonnements push

Lorsque vous configurez un abonnement push, vous pouvez spécifier les propriétés suivantes.

Points de terminaison

URL du point de terminaison (obligatoire) Une adresse HTTPS accessible au public. Le serveur associé au point de terminaison push doit disposer d'un certificat SSL valide signé par une autorité de certification. Le service Pub/Sub envoie les messages aux points de terminaison push situés dans la région Google Cloud où le service stocke les messages. Le service Pub/Sub distribue les messages provenant de la même région Google Cloud de la manière la plus optimale possible.

Pub/Sub ne nécessite plus la preuve que vous êtes propriétaire pour les domaines d'URL d'un abonnement push. Si votre domaine reçoit des requêtes POST inattendues de la part de Pub/Sub, vous pouvez signaler un abus présumé.

Authentification

Activez l'authentification. Lorsqu'elles sont activées, les messages envoyés par Pub/Sub au point de terminaison push incluent un en-tête d'autorisation permettant au point de terminaison d'authentifier la requête. Les mécanismes d'authentification et d'autorisation automatiques sont disponibles pour les points de terminaison de l'environnement standard App Engine et de Cloud Run Functions hébergés dans le même projet que l'abonnement.

La configuration d'authentification pour un abonnement push authentifié se compose d'un compte de service géré par l'utilisateur et des paramètres d'audience spécifiés dans un appel create, patch ou ModifyPushConfig. Vous devez également attribuer un rôle spécifique à un agent de service, comme indiqué dans la section suivante.

  • Compte de service géré par l'utilisateur (obligatoire) Compte de service associé à l'abonnement push. Ce compte est utilisé comme revendication email du jeton Web JSON (JWT) généré. Voici la liste des exigences concernant le compte de service:

  • Audience Chaîne unique, ne respectant pas la casse, utilisée par le webhook pour valider l'audience visée par ce jeton spécifique.

  • Agent de service (obligatoire).

    • Pub/Sub crée automatiquement un compte de service au format service-{PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com.

    • Cet agent de service doit disposer de l'autorisation iam.serviceAccounts.getOpenIdToken (inclue dans le rôle roles/iam.serviceAccountTokenCreator) pour permettre à Pub/Sub de créer des jetons JWT pour les requêtes push authentifiées.

Désencapsulation de la charge utile

L'option Enable payload unwrapping (Activer la désencapsulation de la charge utile) supprime toutes les métadonnées des messages Pub/Sub, à l'exception des données de message. Avec le déballage de la charge utile, les données du message sont transmises directement en tant que corps HTTP.

  • Écrivez des métadonnées. Ajoute les métadonnées de message précédemment supprimées à l'en-tête de requête.

Propriétés BigQuery

Lorsque vous sélectionnez Écrire dans BigQuery comme type de diffusion d'abonnement, vous pouvez spécifier les propriétés supplémentaires suivantes.

Utiliser un schéma avec sujet

Cette option permet à Pub/Sub d'utiliser le schéma du sujet Pub/Sub auquel l'abonnement est associé. De plus, Pub/Sub écrit les champs des messages dans les colonnes correspondantes de la table BigQuery.

Lorsque vous utilisez cette option, n'oubliez pas de vérifier les exigences supplémentaires suivantes:

  • Les champs du schéma du sujet et du schéma BigQuery doivent porter le même nom et leurs types doivent être compatibles.

  • Tout champ facultatif du schéma du sujet doit également être facultatif dans le schéma BigQuery.

  • Les champs obligatoires dans le schéma du sujet ne doivent pas nécessairement l'être dans le schéma BigQuery.

  • Si des champs BigQuery ne figurent pas dans le schéma du sujet, ils doivent être en mode NULLABLE.

  • Si le schéma du sujet comporte des champs supplémentaires qui ne sont pas présents dans le schéma BigQuery et que ces champs peuvent être supprimés, sélectionnez l'option Supprimer les champs inconnus.

  • Vous ne pouvez sélectionner qu'une seule des propriétés d'abonnement, Utiliser le schéma de sujet ou Utiliser le schéma de table.

Si vous ne sélectionnez pas l'option Utiliser un schéma de sujet ou Utiliser un schéma de table, assurez-vous que la table BigQuery comporte une colonne appelée data de type BYTES, STRING ou JSON. Pub/Sub écrit le message dans cette colonne BigQuery.

Les modifications apportées au schéma des sujets Pub/Sub ou au schéma de la table BigQuery peuvent ne pas prendre effet immédiatement avec les messages écrits dans la table BigQuery. Par exemple, si l'option Supprimer les champs inconnus est activée et qu'un champ est présent dans le schéma Pub/Sub, mais pas dans le schéma BigQuery, les messages écrits dans la table BigQuery peuvent toujours ne pas contenir le champ après l'avoir ajouté au schéma BigQuery. À terme, les schémas se synchronisent et les messages suivants incluent le champ.

Lorsque vous utilisez l'option Utiliser un schéma de sujet pour votre abonnement BigQuery, vous pouvez également profiter de la capture des données modifiées (CDC, Change Data Capture) de BigQuery. La capture des données modifiées met à jour vos tables BigQuery en traitant et en appliquant les modifications aux lignes existantes.

Pour en savoir plus sur cette fonctionnalité, consultez Diffuser les mises à jour des tables avec la capture des données modifiées.

Pour savoir comment utiliser cette fonctionnalité avec des abonnements BigQuery, consultez la section Capture de données modifiées BigQuery.

Utiliser un schéma de table

Cette option permet à Pub/Sub d'utiliser le schéma de la table BigQuery pour écrire les champs d'un message JSON dans les colonnes correspondantes. Lorsque vous utilisez cette option, n'oubliez pas de vérifier les exigences supplémentaires suivantes:

  • Les messages publiés doivent être au format JSON.

  • Les conversions JSON suivantes sont acceptées:

    Type JSON Type de données BigQuery
    string NUMERIC, BIGNUMERIC, DATE, TIME, DATETIME ou TIMESTAMP
    number NUMERIC, BIGNUMERIC, DATE, TIME, DATETIME ou TIMESTAMP
    • Lorsque vous utilisez des conversions number vers DATE, DATETIME, TIME ou TIMESTAMP, le nombre doit respecter les représentations acceptées.
    • Lorsque vous effectuez une conversion number vers NUMERIC ou BIGNUMERIC, la précision et la plage de valeurs sont limitées à celles acceptées par la norme IEEE 754 pour l'arithmétique à virgule flottante. Si vous avez besoin d'une précision élevée ou d'une plage de valeurs plus large, utilisez plutôt des conversions string vers NUMERIC ou BIGNUMERIC.
    • Lorsque vous effectuez des conversions string vers NUMERIC ou BIGNUMERIC, Pub/Sub suppose que la chaîne est un nombre lisible par l'humain (par exemple, "123.124"). Si le traitement de la chaîne en tant que nombre lisible par l'humain échoue, Pub/Sub traite la chaîne comme des octets encodés avec BigDecimalByteStringEncoder.

  • Si le sujet de l'abonnement est associé à un schéma, la propriété d'encodage des messages doit être définie sur JSON.

  • Si des champs BigQuery ne sont pas présents dans les messages, ils doivent être en mode NULLABLE.

  • Si les messages comportent des champs supplémentaires qui ne figurent pas dans le schéma BigQuery et que ces champs peuvent être supprimés, sélectionnez l'option Supprimer les champs inconnus.

  • Vous ne pouvez sélectionner qu'une seule des propriétés d'abonnement, Utiliser le schéma de sujet ou Utiliser le schéma de table.

Si vous ne sélectionnez pas l'option Utiliser un schéma de sujet ou Utiliser un schéma de table, assurez-vous que la table BigQuery comporte une colonne appelée data de type BYTES, STRING ou JSON. Pub/Sub écrit le message dans cette colonne BigQuery.

Les modifications apportées au schéma de la table BigQuery ne sont pas toujours appliquées immédiatement avec les messages écrits dans la table BigQuery. Par exemple, si l'option Supprimer les champs inconnus est activée et qu'un champ est présent dans les messages, mais pas dans le schéma BigQuery, les messages écrits dans la table BigQuery peuvent toujours ne pas contenir le champ après l'avoir ajouté au schéma BigQuery. À terme, le schéma se synchronise et les messages suivants incluent le champ.

Lorsque vous utilisez l'option Utiliser le schéma de table pour votre abonnement BigQuery, vous pouvez également profiter de la capture des données modifiées (CDC, Change Data Capture) de BigQuery. La capture des données modifiées met à jour vos tables BigQuery en traitant et en appliquant les modifications aux lignes existantes.

Pour en savoir plus sur cette fonctionnalité, consultez Diffuser les mises à jour des tables avec la capture des données modifiées.

Pour savoir comment utiliser cette fonctionnalité avec des abonnements BigQuery, consultez Capture de données modifiées BigQuery.

Supprimer les champs inconnus

Cette option est utilisée avec l'option Utiliser un schéma avec sujet ou Utiliser un schéma de table. Cette option permet à Pub/Sub de supprimer tous les champs présents dans le schéma ou le message du sujet, mais pas dans le schéma BigQuery. Si l'option Supprimer les champs inconnus n'est pas définie, les messages contenant des champs supplémentaires ne sont pas écrits dans BigQuery et restent dans la file d'attente des abonnements. L'abonnement se retrouve dans un état d'erreur.

Écrire des métadonnées

Cette option permet à Pub/Sub d'écrire les métadonnées de chaque message dans des colonnes supplémentaires de la table BigQuery. Sinon, les métadonnées ne sont pas écrites dans la table BigQuery.

Si vous sélectionnez l'option Écrire les métadonnées, assurez-vous que la table BigQuery comporte les champs décrits dans le tableau suivant.

Si vous ne sélectionnez pas l'option Écrire les métadonnées, la table BigQuery de destination ne nécessite que le champ data, sauf si use_topic_schema est défini sur "true". Si vous sélectionnez les options Écrire les métadonnées et Utiliser le schéma du sujet, le schéma du sujet ne doit contenir aucun champ dont le nom correspond à celui des paramètres de métadonnées. Cette limitation inclut les versions CamelCase de ces paramètres en casse snake.

Paramètres
subscription_name

STRING

Nom d'un abonnement.
message_id

STRING

ID d'un message
publish_time

TIMESTAMP

Heure de publication d'un message.
data

BYTES, STRING ou JSON

Corps du message.

Le champ data est obligatoire pour toutes les tables BigQuery de destination qui ne sélectionnent pas Utiliser un schéma avec sujet ou Utiliser un schéma de table. Si le champ est de type JSON, le corps du message doit être au format JSON valide.
attributes

STRING ou JSON

Objet JSON contenant tous les attributs du message. Il contient également des champs supplémentaires qui font partie du message Pub/Sub, y compris la clé de tri, le cas échéant.

Propriétés Cloud Storage

Lorsque vous sélectionnez Écrire dans Cloud Storage comme type de diffusion d'abonnement, vous pouvez spécifier les propriétés supplémentaires suivantes.

Nom du bucket

Un bucket Cloud Storage doit déjà exister avant de créer un abonnement Cloud Storage.

Les messages sont envoyés par lots et stockés dans le bucket Cloud Storage. Un seul lot ou fichier est stocké en tant qu'objet dans le bucket.

L'option Payé par le demandeur doit être désactivée pour le bucket Cloud Storage.

Pour créer un bucket Cloud Storage, consultez la page Créer des buckets.

Préfixe, suffixe et date/heure du nom de fichier

Les fichiers Cloud Storage de sortie générés par l'abonnement Cloud Storage sont stockés en tant qu'objets dans le bucket Cloud Storage. Le nom de l'objet stocké dans le bucket Cloud Storage est au format suivant: <file-prefix><UTC-date-time>_<uuid><file-suffix>.

La liste suivante inclut des informations sur le format de fichier et les champs que vous pouvez personnaliser:

  • <file-prefix> est le préfixe du nom de fichier personnalisé. Ce champ est facultatif.

  • <UTC-date-time> est une chaîne personnalisable générée automatiquement en fonction de l'heure de création de l'objet.

  • <uuid> est une chaîne aléatoire générée automatiquement pour l'objet.

  • <file-suffix> est le suffixe du nom de fichier personnalisé. Ce champ est facultatif. Le suffixe du nom de fichier ne doit pas se terminer par "/".

  • Vous pouvez modifier le préfixe et le suffixe du nom de fichier:

    • Par exemple, si la valeur du préfixe de nom de fichier est prod_ et que la valeur du suffixe de nom de fichier est _archive, un exemple de nom d'objet est prod_2023-09-25T04:10:00+00:00_uN1QuE_archive.

    • Si vous ne spécifiez pas le préfixe et le suffixe du nom de fichier, le nom de l'objet stocké dans le bucket Cloud Storage est au format : <UTC-date-time>_<uuid>.

    • Les exigences de dénomination des objets Cloud Storage s'appliquent également au préfixe et au suffixe du nom de fichier. Pour en savoir plus, consultez la section À propos des objets Cloud Storage.

  • Vous pouvez modifier la façon dont la date et l'heure s'affichent dans le nom de fichier:

    • Correspondances de date/heure obligatoires que vous ne pouvez utiliser qu'une seule fois: année (YYYY ou YY), mois (MM), jour (DD), heure (hh), minute (mm), seconde (ss). Par exemple, YY-YYYY ou MMM n'est pas valide.

    • Correspondances facultatives que vous ne pouvez utiliser qu'une seule fois: séparateur de date et heure (T) et décalage horaire (Z ou +00:00).

    • Éléments facultatifs que vous pouvez utiliser plusieurs fois: trait d'union (-), soulignement (_), deux-points (:) et barre oblique (/).

    • Par exemple, si la valeur du format de date et d'heure du nom de fichier est YYYY-MM-DD/hh_mm_ssZ, un exemple de nom d'objet est prod_2023-09-25/04_10_00Z_uNiQuE_archive.

    • Si le format de date et d'heure du nom de fichier se termine par un caractère qui n'est pas un opérateur de correspondance, ce caractère remplace le séparateur entre <UTC-date-time> et <uuid>. Par exemple, si la valeur du format de date et d'heure du nom de fichier est YYYY-MM-DDThh_mm_ss-, un exemple de nom d'objet est prod_2023-09-25T04_10_00-uNiQuE_archive.

Traitement des fichiers par lot

Les abonnements Cloud Storage vous permettent de décider quand créer un fichier de sortie stocké en tant qu'objet dans le bucket Cloud Storage. Pub/Sub écrit un fichier de sortie lorsqu'une des conditions de traitement par lot spécifiées est remplie. Voici les conditions de traitement par lot Cloud Storage:

  • Durée maximale des lots de stockage Ce paramètre est obligatoire. L'abonnement Cloud Storage écrit un nouveau fichier de sortie si la valeur spécifiée de la durée maximale est dépassée. Si vous ne spécifiez pas de valeur, une valeur par défaut de cinq minutes est appliquée. Voici les valeurs applicables pour la durée maximale:

    • Valeur minimale = 1 minute
    • Valeur par défaut = 5 minutes
    • Valeur maximale = 10 minutes

  • Nombre maximal d'octets par lot de stockage Ce paramètre est facultatif. L'abonnement Cloud Storage écrit un nouveau fichier de sortie si la valeur d'octets maximale spécifiée est dépassée. Voici les valeurs applicables pour les octets max:

    • Valeur minimale = 1 Ko
    • Valeur maximale = 10 Go

  • Messages de lot de stockage maximal. Ce paramètre est facultatif. L'abonnement Cloud Storage écrit un nouveau fichier de sortie si le nombre maximal de messages spécifié est dépassé. Voici les valeurs applicables pour le nombre maximal de messages:

    • Valeur minimale = 1 000

Par exemple, vous pouvez configurer la durée maximale sur 6 minutes et la taille maximale en octets sur 2 Go. Si, à la 4e minute, le fichier de sortie atteint une taille de 2 Go, Pub/Sub finalise le fichier précédent et commence à écrire dans un nouveau fichier.

Un abonnement Cloud Storage peut écrire simultanément dans plusieurs fichiers d'un bucket Cloud Storage. Si vous avez configuré votre abonnement pour créer un fichier toutes les six minutes, vous pouvez observer la création de plusieurs fichiers Cloud Storage toutes les six minutes.

Dans certains cas, Pub/Sub peut commencer à écrire dans un nouveau fichier avant l'heure configurée par les conditions de traitement par lot de fichiers. Un fichier peut également dépasser la valeur "Max. octets" si l'abonnement reçoit des messages plus volumineux que cette valeur.

Format de fichier

Lorsque vous créez un abonnement Cloud Storage, vous pouvez spécifier le format des fichiers de sortie à stocker dans un bucket Cloud Storage sous la forme Texte ou Avro.

  • Texte: les messages sont stockés en texte brut. Un caractère de nouvelle ligne sépare un message du message précédent dans le fichier. Seules les charges utiles des messages sont stockées, et non les attributs ni les autres métadonnées.

  • Avro: les messages sont stockés au format binaire Apache Avro. Lorsque vous sélectionnez Avro, vous pouvez activer les propriétés supplémentaires suivantes:

    • Écrire des métadonnées: cette option vous permet de stocker les métadonnées du message avec le message. Les métadonnées telles que les champs subscription_name, message_id, publish_time et attributes sont écrites dans les champs de niveau supérieur de l'objet Avro de sortie, tandis que toutes les autres propriétés de message autres que les données (par exemple, une clé de tri, le cas échéant) sont ajoutées en tant qu'entrées dans la mappe attributes.

      Si l'option Écrire des métadonnées est désactivée, seule la charge utile du message est écrite dans l'objet Avro de sortie. Voici le schéma Avro des messages de sortie avec l'option écrire des métadonnées désactivée:

      {
  "type": "record",
  "namespace": "com.google.pubsub",
  "name": "PubsubMessage",
  "fields": [
    { "name": "data", "type": "bytes" }
  ]
}

      Voici le schéma Avro des messages de sortie avec l'option écrire des métadonnées activée:

      {
  "type": "record",
  "namespace": "com.google.pubsub",
  "name": "PubsubMessageWithMetadata",
  "fields": [
    { "name": "subscription_name", "type": "string" },
    { "name": "message_id", "type": "string"  },
    { "name": "publish_time", "type": {
        "type": "long",
        "logicalType": "timestamp-micros"
      }
    },
    { "name": "attributes", "type": { "type": "map", "values": "string" } },
    { "name": "data", "type": "bytes" }
  ]
}

    • Utiliser un schéma avec sujet: cette option permet à Pub/Sub d'utiliser le schéma du sujet Pub/Sub auquel l'abonnement est associé lors de l'écriture de fichiers Avro.

      Lorsque vous utilisez cette option, n'oubliez pas de vérifier les exigences supplémentaires suivantes:

      • Le schéma du sujet doit être au format Apache Avro.

      • Si les options Utiliser le schéma de sujet et Écrire des métadonnées sont activées, le schéma de sujet doit comporter un objet Enregistrement à la racine. Pub/Sub développe la liste des champs de l'enregistrement pour inclure les champs de métadonnées. Par conséquent, l'enregistrement ne peut contenir aucun champ portant le même nom que les champs de métadonnées (subscription_name, message_id, publish_time ou attributes).

Étape suivante