Propriétés de l'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 configurer l'abonnement. 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 indépendamment de confirmation du message. Pour conserver les messages confirmés pendant la durée de conservation des messages, consultez Rouvrir et supprimer 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 provenir d'abonnements inactifs, de besoins de sauvegarde ou un traitement lent. Si vous parvenez à traiter les messages dans les 24 heures, les frais supplémentaires ne sont pas facturés. Vous pouvez éviter de nouveaux frais en gérant ces scénarios comme suit:

  • Abonnements inactifs. Supprimer les abonnements inactifs afin d'éviter des frais d'abonnement pour la conservation des messages.

  • Stockage des sauvegardes. Si vous utilisez la conservation de votre abonnement comme espace de stockage de sauvegarde, vous pouvez choisir une autre option de stockage, rétention des messages par 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 messages pendant la durée de conservation 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 Délai d'expiration vous permet de prolonger la période d'expiration des votre abonnement.

Abonnements sans activité d'abonné ni modification apportées aux propriétés d'abonnement expirent. Si Pub/Sub détecte l'activité des abonnés ou si vous modifiez l'une des propriétés d'abonnement, l'horloge de suppression d'abonnement redémarre. Exemples d'activités d'abonnés inclure des connexions ouvertes, des actions pull actives ou push réussies.

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 le champ l'option Durée de conservation des messages.

Les valeurs de l'option Délai d'expiration sont les suivantes:

  • 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 d'accusé de réception

L'option Délai d'accusé de réception spécifie le délai initial à l'issue duquel une le message non confirmé est renvoyé. Vous pouvez prolonger le délai de confirmation par message en envoyant des requêtes ModifyAckDeadline ultérieures.

Les valeurs de l'option Délai de confirmation sont les suivantes:

  • 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. Ainsi, le message peut être à nouveau distribué avant que l'accusé de réception que vous avez défini. Pour ignorer 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 un expression de filtrage. Si un abonnement comporte un filtre, il diffuse uniquement les messages correspondant à ce filtre. Le service Pub/Sub s'exécute automatiquement reconnaît 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.

  • S'il n'est pas 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 sont pas traités tant que les accusés de réception des messages antérieurs n'ont pas été traités.

Les éditeurs doivent envoyer les messages avec une clé de tri Pub/Sub peut fournir 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 sujet de lettres mortes :

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

Si le sujet des 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 sujet des 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 distribution est connue sous le nom de règle 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 l'intervalle entre les tentatives, la valeur par défaut de l'intervalle minimal l'intervalle entre les tentatives 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 par lot

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 d'abonnement 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 ce champ est défini, Pub/Sub traite de distribution 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 éléments suivants : propriétés.

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 depuis Pub/Sub, vous pouvez signaler un abus suspect.

Authentification

Activez l'authentification. Lorsque cette option est activée, les messages distribués par Pub/Sub au point de terminaison push incluent un en-tête d'autorisation pour pour autoriser le point de terminaison à 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 de l'authentification d'un abonnement push authentifié se compose d'un compte de service géré par l'utilisateur, et les paramètres d'audience sont spécifiés dans une commande 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 conditions requises pour le compte de service:

  • Audience : Chaîne unique, non sensible à la casse, que le webhook utilise pour valider l’audience visée de ce jeton particulier.

  • 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 Activer la désencapsulation de la charge utile supprime Pub/Sub. messages de toutes les métadonnées des messages, à l'exception de leurs données. Avec charge utile désencapsulation, les données du message sont livrées directement en tant que corps HTTP.

  • Écrivez des métadonnées. Réajoute les métadonnées de message précédemment supprimées dans la section 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 le est associé à un abonnement. De plus, Pub/Sub écrit les champs des messages dans l'espace de noms dans la table BigQuery.

Lorsque vous utilisez cette option, n'oubliez pas de vérifier les conditions 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 est facultative dans le schéma BigQuery.

  • Il n'est pas nécessaire que les champs obligatoires du schéma requises dans le schéma BigQuery.

  • Si des champs BigQuery ne sont pas présents dans le schéma du sujet, ces champs BigQuery doit ê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 un schéma de sujet. ou Utiliser un schéma de table.

Si vous ne sélectionnez pas l'option Utiliser un schéma avec sujet ou Utiliser un schéma de table, vérifiez que la table BigQuery comporte une colonne appelée data saisissez BYTES, STRING ou JSON. Pub/Sub écrit le message 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. Finalement, les schémas synchronisés et les messages suivants incluent ce 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 CDC met à jour vos tables BigQuery de le traitement et l'application des 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 découvrir comment utiliser cette fonctionnalité avec les abonnements BigQuery, consultez la page Capture de données modifiées dans BigQuery.

Utiliser un schéma de table

Cette option permet à Pub/Sub d'utiliser le schéma du Table BigQuery pour écrire les champs d'un fichier 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 avec 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 les conversions string à NUMERIC ou BIGNUMERIC.
    • Lorsque vous utilisez des conversions string vers NUMERIC ou BIGNUMERIC, Pub/Sub suppose que la chaîne est un nombre lisible (par exemple, "123.124"). Si le traitement de la chaîne en tant que nombre lisible par l'humain échoue, Pub/Sub la traite comme des octets encodés avec BigDecimalByteStringEncoder.

  • Si le sujet de l'abonnement est associée à 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 avec sujet ou Utiliser un schéma de table, vérifiez que la table BigQuery comporte une colonne appelée data saisissez BYTES, STRING ou JSON. Pub/Sub écrit le message cette colonne BigQuery.

Il est possible que vous ne voyiez pas les modifications apportées au schéma de la table BigQuery 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. Finalement, le schéma est synchronisé et les messages suivants incluent ce 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 découvrir comment utiliser cette fonctionnalité avec des abonnements BigQuery, consultez Capture de données modifiées dans BigQuery.

Supprimer les champs inconnus

Cette option est utilisée avec les options 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. Sans Lacage inconnu "fields" définis, les messages comportant des champs supplémentaires ne sont pas écrits dans vers BigQuery et rester dans les tâches d'abonnement en attente. La l'abonnement se retrouve à l'état d'erreur.

Écrire des métadonnées

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

Si vous sélectionnez l'option Écrire les métadonnées, assurez-vous que le 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 requiert que le champ data, sauf si use_topic_schema est vrai. Si vous sélectionnez à la fois Écrire les métadonnées et Utiliser un schéma de sujet, le schéma du sujet doit ne contenir aucun champ dont le nom correspond à ceux des paramètres de métadonnées. Cette limitation inclut les versions camelcase de ces paramètres Snake Case.

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 est de type JSON, le corps du message doit être 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 sous forme de lots et stockés dans le bucket Cloud Storage. Un seul lot ou fichier est stocké en tant qu'objet. dans le bucket.

Le bucket Cloud Storage doit comporter L'option Paiements du demandeur est désactivée.

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

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

Les fichiers Cloud Storage de sortie générés par l'API 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 format: <file-prefix><UTC-date-time>_<uuid><file-suffix>.

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

  • <file-prefix> est le préfixe de 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 ni le suffixe du nom de fichier, le nom d'objet est stocké dans le bucket Cloud Storage est au format suivant: <UTC-date-time>_<uuid>

    • Les règles de dénomination des objets Cloud Storage s'appliquent également au nom de fichier un préfixe et un suffixe. Pour en savoir plus, consultez À propos des objets Cloud Storage

  • Vous pouvez modifier l'affichage de la date et de l'heure dans le nom du 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: tiret (-), Trait de soulignement (_), deux-points (:) et barre oblique (/).

    • Par exemple, si la valeur du format date/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 date/heure du nom de fichier se termine par un caractère qui n'est pas une correspondance, ce caractère remplacera 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 lorsque l'un des les conditions de traitement par lot spécifiées sont remplies. 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. Vous trouverez ci-dessous les pour le nombre maximal d'octets:

    • 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é. Vous trouverez ci-dessous les valeurs pour le nombre maximal de messages:

    • Valeur minimale = 1 000

Par exemple, vous pouvez configurer la durée maximale sur 6 minutes et 2 Go au maximum. Si à la 4e minute, le fichier de sortie atteint une de 2 Go, Pub/Sub finalise le fichier précédent et démarre é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 pour créer un fichier toutes les six minutes, vous pourriez constater de plusieurs fichiers Cloud Storage créés toutes les 6 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. Message uniquement les charges utiles sont stockées, pas des attributs ou d’autres métadonnées.

  • Avro: les messages sont stockés 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 l'option Utiliser le schéma du sujet et l'écriture des métadonnées sont activées, le schéma du sujet doit comporter un objet Record à sa 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