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 des abonnements. Nous les aborderons 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 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 = 7 jours

Les messages non confirmés peuvent provenir d'abonnements inactifs, de besoins de sauvegarde ou un traitement lent. Si vous utilisez traiter les messages dans un délai de 24 heures, les frais supplémentaires non engagée. Vous pouvez éviter de nouveaux frais en gérant ces scénarios comme suit:

  • Abonnements inactifs. Supprimer les abonnements inactifs pour éviter que des frais d'abonnement et de conservation des messages ne vous soient facturés.

  • 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 stocke les messages une seule fois au niveau du thème. De plus, elles restent disponibles à utiliser en cas de besoin.

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

Conserver les messages confirmés

Si vous spécifiez une durée de conservation des messages, vous pouvez également préciser 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 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 étendre la confirmation pour chaque message en envoyant des ModifyAckDeadline requêtes.

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 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 Prise en charge 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 un expression de filtrage. Si un abonnement comporte un filtre, il ne distribue que les messages qui correspondent au 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 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, le paramètre 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 de réception des messages 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 des messages avec une clé de tri Pub/Sub peut fournir dans l'ordre.

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

Sujet des lettres mortes

Lorsqu'un message ne peut pas être distribué après un nombre défini de tentatives de distribution ou si un abonné ne peut pas accuser réception du message, vous pouvez configurer un sujet de lettres mortes dans lequel ces messages pourront ê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 correspondant au nombre maximal de tentatives d'envoi pour la file d'attente 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 file d'attente de lettres mortes se trouve dans un projet différent de celui de l'abonnement, vous doit également spécifier l'ID du projet avec la 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 expire ou si un abonné répond par un accusé de réception négatif, Pub/Sub peut envoyer s'affiche à nouveau. 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 utilisez l'option Réessayer immédiatement. Avec cette option, Pub/Sub renvoie le message lorsque le délai de confirmation est écoulé expire ou 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 maximale et minimale de l'intervalle entre les tentatives.

Vous trouverez ci-dessous quelques consignes pour définir les valeurs des valeurs maximales et valeurs d'intervalle minimal 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 de l'intervalle entre les tentatives, la valeur par défaut de l'intervalle maximal 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.

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 d'abonnement pull

Lorsque vous configurez un abonnement pull, vous pouvez spécifier les éléments suivants : propriétés.

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. S'il n'est pas spécifié, l'abonnement accepte distribution au moins une fois à chaque message.

Propriétés d'abonnement 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). Adresse HTTPS accessible publiquement. Le serveur utilisé pour la transmission 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 d'une preuve de propriété pour le push domaines d'URL d'abonnement. 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. L'authentification automatique et des mécanismes d'autorisation sont disponibles pour les points de terminaison de l'environnement standard App Engine et de Cloud 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é au déploiement abonnement. 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 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 du rôle Autorisation iam.serviceAccounts.getOpenIdToken (incluse dans roles/iam.serviceAccountTokenCreator ) afin d'autoriser Pub/Sub à créer des jetons JWT pour des 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.

  • Écrire 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 Write to BigQuery (Écrire dans BigQuery) comme type de distribution pour les abonnements : 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:

  • Champs du schéma du sujet et du schéma BigQuery doivent avoir les mêmes noms et leurs types doivent être compatibles entre eux.

  • 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 ne sont pas présentes dans le schéma BigQuery et 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 avec 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.

Il est possible que vous ne voyiez pas les modifications apportées au schéma des sujets Pub/Sub ou Le schéma de la table BigQuery prend effet immédiatement avec les messages dans la table BigQuery. Par exemple, si le bouton Drop champs inconnus est activée et qu'un champ est présent dans le schéma Pub/Sub, mais pas le schéma BigQuery, que les messages écrits dans la table BigQuery ne contiennent toujours pas 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 projet BigQuery vous pouvez aussi profiter des modifications apportées à BigQuery de capture de données (CDC). 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 des mises à jour de tables avec 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 vérifiez 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, ces champs BigQuery doivent être en mode NULLABLE.

  • Si les messages comportent des champs supplémentaires qui ne figurent pas dans la section schéma BigQuery et que ces champs peuvent être supprimés, sélectionnez le l'option 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 des octets encodés à l'aide de la méthode BigDecimalByteStringEncoder.

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

Il est possible que les modifications apportées au schéma de la table BigQuery ne soient pas prises en compte 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 dans les messages, mais pas dans le schéma BigQuery, que les messages écrits dans la table BigQuery ne contiennent toujours pas après l'avoir ajouté au schéma BigQuery. Finalement, le schéma est synchronisé et les messages ultérieurs incluent ce champ.

Lorsque vous utilisez l'option Utiliser un schéma de table avec votre abonnement BigQuery, vous peuvent également exploiter la capture de données modifiées (CDC, Change Data Capture) de BigQuery. La CDC met à jour vos tables BigQuery en traitant et en appliquant les modifications lignes.

Pour en savoir plus sur cette fonctionnalité, consultez Diffuser des mises à jour de tables avec 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 sujet. schéma ou un message, mais pas dans le schéma BigQuery. Sans Défaillance inconnue champs définis, les messages comportant des champs supplémentaires ne sont pas écrits dans dans BigQuery et demeurer 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 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 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 destinations les tables BigQuery sans l'option Utiliser schéma de 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 y a aussi contient des champs supplémentaires un message Pub/Sub incluant la clé de tri, le cas échéant.

Propriétés Cloud Storage

Lorsque vous sélectionnez le type de distribution d'abonnement Write to Cloud Storage (Écriture dans Cloud Storage), vous pouvez spécifier les propriétés supplémentaires suivantes.

Nom du bucket

Pour que vous puissiez créer un bucket Cloud Storage, 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 contenir 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 l'objet est créé.

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

  • <file-suffix> est le suffixe personnalisé du nom de fichier. Ce champ est facultatif. La 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 de le suffixe du 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:

    • Mise en correspondance de date et d'heure obligatoires, que vous ne pouvez utiliser qu'une seule fois: l'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 la date et de l'heure (T) et et le décalage horaire (Z ou +00:00).

    • Éléments facultatifs que vous pouvez utiliser plusieurs fois: tiret (-), un trait de soulignement (_), un deux-points (:) et une 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 date/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 nouveau fichier de sortie stocké en tant qu'objet dans le Cloud Storage bucket. 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. La L'abonnement Cloud Storage écrit un nouveau fichier de sortie si la valeur spécifiée pour la durée maximale est dépassée. Si vous ne spécifiez la 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. La L'abonnement Cloud Storage écrit un nouveau fichier de sortie si le la valeur spécifiée pour le nombre maximal d'octets est dépassée. Vous trouverez ci-dessous les 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 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 dans plusieurs fichiers d'un bucket Cloud Storage simultanément. Si vous avez configuré votre pour créer un fichier toutes les six minutes, vous pourriez constater plusieurs fichiers Cloud Storage créés toutes les 6 minutes.

Dans certains cas, Pub/Sub peut commencer à écrire dans un nouveau plus tôt que l'heure configurée par les conditions de traitement par lot des fichiers. 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 la valeur "Max bytes".

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 en tant que Text 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 les métadonnées: cette option vous permet de stocker les métadonnées du message avec celui-ci. 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, order_key, le cas échéant) sont ajoutées en tant qu'entrées dans le mappage attributes.

      Si l'option write metadata (écrire les 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 lorsque l'option write metadata (écriture de métadonnées) est désactivée:

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

      Voici le schéma Avro pour les messages de sortie avec les métadonnées d'écriture activées:

      {
  "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 conditions 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