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 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 de configuration. 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 indique la durée pendant laquelle Pub/Sub conserve les messages après leur publication. Une fois la durée de conservation des messages écoulée, Pub/Sub peut supprimer le message indépendamment de son état de confirmation. Pour conserver les messages confirmés pendant toute la durée de conservation des messages, consultez la section Rouvrir et supprimer des messages.

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

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

Les messages non confirmés peuvent résulter d'abonnements inactifs, de besoins de sauvegarde ou d'un traitement lent. Si vous pouvez traiter les messages dans un délai de 24 heures, les frais supplémentaires ne sont pas facturés. Pour éviter ces frais, procédez comme suit:

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

  • Stockage de sauvegarde. 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. Ceux-ci restent disponibles pour tous les abonnements, qui peuvent les utiliser en cas de besoin.

  • Retards de traitement. Ajoutez des abonnés (si possible) pour traiter les messages dans la journée.

Conserver les messages confirmés

Si vous spécifiez une 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 la section Coûts de stockage.

Délai d'expiration

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

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

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 pour l'option Délai d'expiration:

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

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 d'accusé de réception spécifie le délai initial après lequel un message non confirmé est à nouveau envoyé. Vous pouvez prolonger le délai de confirmation pour chaque message en envoyant des requêtes ModifyAckDeadline par la suite.

Voici les valeurs pour l'option Délai de confirmation:

  • 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 le taux de distribution et modifier de manière dynamique le délai de confirmation. Ce faisant, le message pourrait être redistribué avant l'expiration du délai de confirmation 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é de la distribution de type "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 ne distribue que les messages correspondant à ce filtre. Le service Pub/Sub accuse automatiquement réception des 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 le classement des messages est activé 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.

Dans le cas d'une 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 antérieurs ne sont pas traités.

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

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

File d'attente de lettres mortes

Lorsqu'un message ne peut pas être distribué après un nombre défini de tentatives de distribution ou qu'un abonné ne peut pas accuser réception du message, vous pouvez configurer un sujet de lettre morte 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 d'envoi
  • Valeur minimale = 5 tentatives de livraison
  • 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 du projet avec le file d'attente de lettres mortes.

Pour en savoir plus, consultez la section Effectuer le transfert vers des sujets de lettres mortes.

Stratégie de nouvelle tentative

Si le délai d'accusé de réception expire ou si un abonné répond avec un accusé de réception négatif, Pub/Sub peut renvoyer le message. Cette tentative de renvoi est connue sous le nom de Règle de nouvelle tentative d'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 d'accusé de réception expire ou lorsqu'un abonné répond par un accusé de réception négatif.

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

Voici quelques consignes pour définir les valeurs d'intervalle maximal entre les tentatives:

  • Si vous définissez la valeur maximale de l'intervalle entre les tentatives, la valeur par défaut est de 10 secondes.

  • Si vous définissez la valeur minimale de l'intervalle entre les tentatives, la valeur par défaut 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.

Règle 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 de l'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 cette option est définie, Pub/Sub garantit une distribution exactement une fois. S'il n'est pas spécifié, l'abonnement accepte la distribution au moins une fois pour chaque message.

Propriétés d'abonnement 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). Adresse HTTPS accessible publiquement. Le serveur du 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 n'a plus besoin de preuve de propriété pour les domaines d'URL d'abonnement push. Si votre domaine reçoit des requêtes POST inattendues de la part de Pub/Sub, vous pouvez signaler un abus potentiel.

Ratio d'économie d'énergie (EER)

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 permettre au point de terminaison d'authentifier la requête. Des mécanismes d'authentification et d'autorisation automatiques sont disponibles pour les points de terminaison App Engine standards et Cloud Functions hébergés dans le même projet que l'abonnement.

La configuration d'authentification d'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 compte de service spécial géré par Google, 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 utilisée par le webhook pour valider l'audience visée par ce jeton particulier.

  • Compte de service géré par Google (obligatoire) :

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

    • Ce compte de service doit disposer de l'autorisation iam.serviceAccounts.getOpenIdToken (incluse 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) permet de supprimer les messages Pub/Sub de toutes les métadonnées des messages, à l'exception de leurs données. Avec la désencapsulation de la charge utile, les données du message sont transmises directement sous forme de corps HTTP.

  • Écrire des métadonnées Il ajoute des métadonnées de message précédemment supprimées dans l'en-tête de requête.

Propriétés BigQuery

Lorsque vous sélectionnez un type de diffusion pour les abonnements comme Write to BigQuery (Écrire dans BigQuery), 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é. En outre, 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 conditions supplémentaires suivantes:

  • Les champs du schéma du sujet et du schéma BigQuery doivent avoir les mêmes noms, et leurs types doivent être compatibles les uns avec les autres.

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

  • Les champs obligatoires du schéma du sujet n'ont pas besoin de l'être dans le schéma BigQuery.

  • Si des champs BigQuery ne sont pas présents 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 ignorés, sélectionnez l'option Supprimer les champs inconnus.

  • Vous ne pouvez sélectionner qu'une seule propriété d'abonnement : Utiliser un schéma du 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, 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.

Il est possible que les modifications apportées au schéma des sujets Pub/Sub ou au schéma de la table BigQuery ne prennent pas effet immédiatement avec les messages écrits dans la table BigQuery. Par exemple, si l'option Drop unknown rows (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, il est possible que les messages écrits dans la table BigQuery ne contiennent toujours pas ce 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 tirer parti de la capture des données modifiées (CDC, Change Data Capture) de BigQuery. La CDC 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 de table 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 BigQuery.

Utiliser le schéma de la 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.

  • 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 sont pas présents dans le schéma BigQuery et qu'ils peuvent être supprimés, sélectionnez l'option Drop unknownfields (Supprimer les champs inconnus).

  • Dans le message JSON, les valeurs DATE, DATETIME, TIME et TIMESTAMP doivent être des entiers conformes aux représentations acceptées.

  • Dans le message JSON, les valeurs NUMERIC et BIGNUMERIC doivent être encodées à l'aide de BigDecimalByteStringEncoder.

  • Vous ne pouvez sélectionner qu'une seule propriété d'abonnement : Utiliser un schéma du 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, 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.

Il est possible que les modifications apportées au schéma de la table BigQuery ne prennent pas effet immédiatement avec les messages écrits dans la table BigQuery. Par exemple, si l'option Abandonner les champs inconnus est activée et qu'un champ est présent dans les messages, mais pas dans le schéma BigQuery, il est possible que les messages écrits dans la table BigQuery ne contiennent toujours pas ce 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 un schéma de table pour votre abonnement BigQuery, vous pouvez également tirer parti de la capture des données modifiées (CDC, Change Data Capture) de BigQuery. La CDC 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 de table avec la capture des données modifiées.

Pour découvrir comment utiliser cette fonctionnalité avec les 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 tout champ présent dans le schéma du sujet ou le message, mais pas dans le schéma BigQuery. Si l'option Abandonner les champs inconnus n'est pas définie, les messages comportant des champs supplémentaires ne sont pas écrits dans BigQuery et restent en attente dans les tâches d'abonnement. L'abonnement se termine par 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 requiert que le champ data, sauf si use_topic_schema est défini sur "true". Si vous sélectionnez à la fois 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 les noms correspondent à 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 pour lesquelles l'option Utiliser un schéma du sujet n'est pas sélectionnée. Si le champ est de type JSON, le corps du message doit être un fichier 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 un type de distribution pour les abonnements, par exemple Write to Cloud Storage (Écrire dans Cloud Storage), vous pouvez spécifier les propriétés supplémentaires suivantes.

Nom du bucket

Un bucket Cloud Storage doit déjà exister pour que vous puissiez 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 Paiements du demandeur doit être désactivée sur 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 indique le format du fichier et les champs 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 de nom de fichier personnalisé. Ce champ est facultatif. Le suffixe du nom de fichier ne peut 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 du nom de fichier est prod_ et que la valeur du suffixe du nom de fichier est _archive, voici un exemple de nom d'objet : 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 de l'objet stocké dans le bucket Cloud Storage est au format suivant : <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 page À propos des objets Cloud Storage.

  • Vous pouvez modifier l'affichage de la date et de l'heure dans le nom du fichier:

    • Outils de mise en correspondance de la date et de l'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.

    • Outils de mise en correspondance facultatifs que vous ne pouvez utiliser qu'une seule fois: séparateur de date/heure (T) et décalage de fuseau horaire (Z ou +00:00).

    • Éléments facultatifs que vous pouvez utiliser plusieurs fois: trait d'union (-), trait de 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, prod_2023-09-25/04_10_00Z_uNiQuE_archive est un exemple de nom d'objet.

    • Si le format de date et d'heure du nom de fichier se termine par un caractère qui n'est pas un outil de mise en 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-, prod_2023-09-25T04_10_00-uNiQuE_archive est un exemple de nom d'objet.

Traitement des fichiers par lot

Les abonnements Cloud Storage vous permettent de décider quand vous souhaitez 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'une des conditions de traitement par lot spécifiées est remplie. Les conditions de traitement par lot Cloud Storage sont les suivantes:

  • 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 de durée maximale spécifiée est dépassée. Si vous ne spécifiez pas cette valeur, une valeur par défaut de 5 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 pour le stockage. Ce paramètre est facultatif. L'abonnement Cloud Storage écrit un nouveau fichier de sortie si la valeur spécifiée du nombre maximal d'octets est dépassée. Voici les valeurs applicables pour le nombre maximal d'octets:

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

Par exemple, vous pouvez configurer la durée maximale sur 6 minutes et le nombre maximal d'octets sur 2 Go. Si, à la quatrième minute, le fichier de sortie atteint une taille de fichier 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 de sorte qu'un fichier soit créé toutes les six minutes, plusieurs fichiers Cloud Storage peuvent être créés 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 des fichiers par lot. Un fichier peut également dépasser la valeur "Max bytes" (Nombre maximal d'octets) si l'abonnement reçoit des messages dont la taille dépasse cette valeur.

Format de fichier

Lorsque vous créez un abonnement Cloud Storage, vous pouvez spécifier le format des fichiers de sortie devant être stockés dans un bucket Cloud Storage : Text ou Avro.

  • Texte: les messages sont stockés en texte brut. Un caractère de retour à la ligne permet de séparer un message du message précédent dans le fichier. Seules les charges utiles des messages sont stockées, pas les attributs ou d'autres métadonnées.

  • Avro: les messages sont stockés au format binaire Apache Avro.

    Lorsque vous sélectionnez Avro, vous pouvez également activer l'option d'écriture des métadonnées. Cette option vous permet de stocker les métadonnées du message avec celui-ci.

    Les métadonnées telles que subscription_name, message_id, publish_time et les champs d'attributs sont écrites dans les champs de premier niveau 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é order_key, le cas échéant) sont ajoutées en tant qu'entrées dans le mappage des attributs.

    Si l'option writemetadata (é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 pour les messages de sortie pour lesquels l'écriture des métadonnées n'est pas activée:

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

    Voici le schéma Avro pour les messages de sortie pour lesquels l'option writemetadata (écriture des métadonnées) est 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" }
  ]
}

Étapes suivantes