Propiedades de suscripción

Las propiedades de suscripción de Pub/Sub son las características de una suscripción. Puedes establecer propiedades de suscripción cuando creas o actualizas una.

En este documento, se describen las diferentes propiedades de suscripción. que puedes configurar para una suscripción.

Antes de comenzar

  • Obtén más información sobre las suscripciones.

  • Comprender el flujo de trabajo de la suscripción a la que te diriges create: Pull, Push o BigQuery.

Propiedades de suscripción comunes

Cuando creas una suscripción, debes especificar varias opciones para configura la suscripción. Algunas de estas propiedades son comunes a todos los tipos de suscripciones y se analizan en las siguientes secciones.

Tiempo de retención de mensajes

La opción Duración de retención de mensajes especifica por cuánto tiempo Pub/Sub retiene los mensajes después de la publicación. Después de que transcurra el período de retención de mensajes, Es posible que Pub/Sub descarte el mensaje, independientemente del de confirmación de recepción del mensaje. Para retener los mensajes confirmados por y la duración de retención de mensajes; consulta Cómo volver a reproducir y descartar mensajes.

Los siguientes son los valores de la opción Duración de la retención de mensajes:

  • Valor predeterminado = 7 días
  • Valor mínimo = 10 minutos
  • Valor máximo = 7 días

Los mensajes no confirmados pueden ser el resultado de suscripciones inactivas, necesidades de copia de seguridad o y un procesamiento lento. Si eres procesar los mensajes en un plazo de 24 horas, los cargos adicionales se que no se generaron. Puedes evitar cargos nuevos administrando estas situaciones de la siguiente manera:

  • Suscripciones inactivas. Cómo borrar suscripciones inactivas para evitar que se apliquen cargos por la retención de mensajes de la suscripción.

  • Almacenamiento de copia de seguridad Si usas la retención de suscripciones como almacenamiento alternativo, puedes cambiar a otra opción de almacenamiento, retención de mensajes por temas o retener mensajes confirmados. La retención de mensajes por tema almacena mensajes solo una vez a nivel del tema y permanecen disponibles para todas las y suscripciones para consumir cuando sea necesario.

  • Demoras en el procesamiento. Agrega más suscriptores (si es posible) para procesar el mensajes en un día.

Retener mensajes confirmados

Si especificas la Duración de retención de mensajes, también puedes especificar si quieres conservar los mensajes confirmados.

La opción Retener mensajes confirmados te permite retener mensajes durante el período de retención de mensajes especificado. Esta opción aumenta las tarifas de almacenamiento de mensajes. Para obtener más información, consulta costos de almacenamiento.

Período de vencimiento

La opción Período de vencimiento te permite extender el período de vencimiento de tu suscripción.

Suscripciones sin cambios ni actividad de los suscriptores realizadas a las propiedades de suscripción. Si Pub/Sub detecta la actividad de los suscriptores o si actualizas alguna de las propiedades de suscripción. se reiniciará el reloj de eliminación de suscripciones. Ejemplos de actividades de los suscriptores incluyen conexiones abiertas, extracciones activas o envíos exitosos.

Si especificas el período de vencimiento, el valor debe ser superior a el período de retención de mensajes especificado en el Duración de la retención de mensajes.

Los siguientes son los valores de la opción Período de vencimiento:

  • Valor predeterminado = 31 días
  • Valor mínimo = 1 día

Para evitar que una suscripción venza, establece el período de vencimiento en never expire.

Plazo límite de confirmación

La opción Plazo de confirmación especifica el plazo inicial tras el cual se el mensaje no confirmado se vuelve a enviar. Puedes extender la confirmación fecha límite por mensaje mediante el envío ModifyAckDeadline solicitudes.

Los siguientes son los valores de la opción Plazo de confirmación:

  • Valor predeterminado = 10 segundos
  • Valor mínimo = 10 segundos
  • Valor máximo = 600 segundos

En algunos casos, las bibliotecas cliente de Pub/Sub pueden controlar la frecuencia de entrega y modificar dinámicamente el plazo de confirmación. Si lo haces, es posible que el mensaje se vuelva a entregar antes de la confirmación. la fecha límite que establezcas. Para anular este comportamiento, usa minDurationPerAckExtension. y maxDurationPerAckExtension. Para obtener más información sobre el uso de estos valores, consulta Asistencia para la entrega “exactamente una vez” en las bibliotecas cliente.

Filtro de suscripción

Usa la opción Filtro de suscripción para especificar una cadena con un expresión de filtrado. Si una suscripción tiene un filtro, solo entrega los mensajes. que coinciden con el filtro. El servicio de Pub/Sub automáticamente reconoce los mensajes que no coinciden con el filtro.

  • Puedes filtrar los mensajes por sus atributos, pero no por los datos que contengan.

  • Si no se especifica, la suscripción no filtra mensajes y los suscriptores reciben todos los mensajes.

  • Los filtros no se pueden cambiar ni quitar después de aplicarlos.

Cuando recibes mensajes de una suscripción con un filtro, no generas tarifas de salida para los mensajes que Pub/Sub confirma de forma automática. Se cobran tarifas por la entrega de mensajes y el almacenamiento relacionado con las búsquedas para estos mensajes.

Para obtener más información, consulta Cómo filtrar mensajes de una suscripción.

Ordenamiento de mensajes

Cuando una suscripción tiene habilitado el Orden de mensajes, el los clientes suscriptores reciben mensajes publicados en la misma región con el misma clave de ordenamiento en el orden en que el servicio recibió los mensajes.

Cuando se usa la entrega ordenada, se no se procesan hasta que se procesan las confirmaciones de mensajes anteriores.

Los publicadores deben enviar mensajes con una clave de ordenamiento para que Pub/Sub puede entregar los los mensajes en orden.

Si no la estableces, es posible que Pub/Sub no entregar los mensajes en orden, incluso si tienen una clave de ordenamiento.

Tema de mensajes no entregados

Cuando un mensaje no se puede entregar después de un número establecido intentos de entrega o un suscriptor no puede confirmar el mensaje. puedes configurar un tema de mensajes no entregados en el que se puedan volver a publicar estos mensajes.

Si estableces un tema de mensajes no entregados, también puedes especificar la cantidad máxima de intentos de entrega. Los siguientes son los valores para la cantidad máxima de intentos de entrega del tema de mensajes no entregados:

  • Valor predeterminado = 5 intentos de entrega
  • Valor mínimo = 5 intentos de entrega
  • Valor máximo = 100 intentos de entrega

Si el tema de mensajes no entregados está en un proyecto diferente al de la suscripción, también debes especificar el ID del proyecto con el tema de mensajes no entregados.

Para obtener más información, consulte Cómo reenviar a temas de mensajes no entregados.

Política de reintentos

Si vence el plazo de confirmación de recepción o un suscriptor responde con una confirmación negativa, Pub/Sub puede enviar el mensaje de nuevo. Este intento de reintento de entrega se conoce como la política de reintentos de la suscripción.

De forma predeterminada, la política de reintentos de una suscripción se establece en Usa Reintentar de inmediato. Con esta opción, Pub/Sub vuelve a enviar el mensaje cuando finaliza el plazo de confirmación vence o un suscriptor responde con una confirmación negativa.

También puedes configurar el valor en Retry tras un retraso de retirada exponencial. En este caso, debes especificar los valores de retirada máximo y mínimo.

Estas son algunas pautas para establecer los valores de valores mínimos de retirada:

  • Si se establece el valor máximo para la duración de retirada, el valor predeterminado para la duración la duración de la retirada es de 10 segundos.

  • Si estableces el valor mínimo para la duración de retirada, el valor predeterminado para La duración máxima de la retirada es de 600 segundos.

  • La duración de retirada más larga que puedes especificar es de 600 segundos.

Política de reintentos y mensajes en lotes

Si los mensajes están en un lote, Pub/Sub inicia la retirada exponencial cuando ocurre una de las siguientes situaciones:

  • El suscriptor envía una confirmación negativa por cada mensaje del lote.

  • Vence el plazo límite de confirmación.

Política de reintentos y suscripción de envío

Si recibes mensajes de una suscripción de envío, Pub/Sub podría volver a entregar mensajes después de la retirada de envío en lugar de la duración de retirada exponencial. Cuando la retirada de envío es más larga que la duración de la retirada exponencial, Pub/Sub vuelve a entregar los mensajes no confirmados después de la retirada de envío.

Propiedades de suscripción de extracción

Cuando configuras una suscripción de extracción, puedes especificar lo siguiente propiedades.

Entrega “exactamente una vez”

Entrega “exactamente una vez”. Si se configura, Pub/Sub entrega garantías de entrega exactamente una vez. Si no se especifica, la suscripción admite al menos una vez para cada mensaje.

Propiedades de suscripción de envío

Cuando configuras una suscripción de envío, puedes especificar los siguientes elementos: propiedades.

Extremos

URL del extremo (obligatoria). Una dirección HTTPS de acceso público. El servidor para el envío debe tener un certificado SSL válido firmado por una autoridad certificadora. El servicio Pub/Sub entrega mensajes a los extremos de envío desde la misma región de Google Cloud en la que el servicio de Pub/Sub almacena los mensajes. El servicio Pub/Sub entrega mensajes de la misma región de Google Cloud según el criterio del mejor esfuerzo.

Pub/Sub ya no requiere una prueba de propiedad para el envío dominios de URL de suscripción. Si tu dominio recibe solicitudes POST inesperadas de Pub/Sub, puedes denunciar sospechas de abuso.

Autenticación

Habilita la autenticación. Cuando se habilita, los mensajes entregados por Pub/Sub al extremo de envío incluyen un encabezado de autorización al permitir que el extremo autentique la solicitud. La autenticación automática y Hay mecanismos de autorización disponibles para los extremos del entorno estándar de App Engine y Cloud Functions alojados en el mismo proyecto que la suscripción.

La configuración de autenticación de una suscripción de envío autenticada consta de una cuenta de servicio administrada por el usuario, y los parámetros del público se especifican en un create, parche o ModifyPushConfig llamada. También debes otorgar un rol específico a un agente de servicio, como se explica en la siguiente sección.

  • Cuenta de servicio administrada por el usuario (obligatorio). La cuenta de servicio asociada con el servidor suscripción. Esta cuenta se usa como la reclamación email del token web JSON (JWT) generado. La siguiente es una lista de requisitos para la cuenta de servicio:

  • Público. Una única cadena que no distingue mayúsculas de minúsculas que usa para validar el público objetivo de este token en particular.

  • Agente de servicio (obligatorio).

    • Pub/Sub crea automáticamente una cuenta de servicio para ti con el formato service-{PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com.

    • A este agente de servicio se le debe otorgar el iam.serviceAccounts.getOpenIdToken (incluido en las roles/iam.serviceAccountTokenCreator para permitir que Pub/Sub cree tokens JWT para solicitudes push autenticadas.

Separación de la carga útil

La opción Habilitar la separación de la carga útil quita Pub/Sub mensajes de todos los metadatos de mensajes, excepto los datos de mensajes. Con carga útil la separación, los datos del mensaje se entregan directamente como el cuerpo HTTP.

  • Escribe metadatos. Vuelve a agregar los metadatos de los mensajes que se quitaron anteriormente al encabezado de la solicitud.

Propiedades de BigQuery

Cuando seleccionas un tipo de entrega de suscripciones como Write to BigQuery, puedes especificar las siguientes propiedades adicionales.

Usar el esquema de tema

Esta opción permite que Pub/Sub use el esquema del tema de Pub/Sub al que suscripción está adjunta. Además, Pub/Sub escribe los campos de los mensajes en las direcciones columnas en la tabla de BigQuery.

Cuando uses esta opción, recuerda verificar los siguientes requisitos adicionales:

  • Los campos en el esquema del tema y el esquema de BigQuery deben tener los mismos nombres y sus tipos deben ser compatibles entre sí.

  • Cualquier campo opcional en el esquema del tema también debe estar opcional en el esquema de BigQuery.

  • No es necesario que los campos obligatorios del esquema de tema necesarios en el esquema de BigQuery.

  • Si hay campos de BigQuery que no están presentes en el esquema del tema, estos campos de BigQuery debe estar en el modo NULLABLE.

  • Si el esquema de tema tiene campos adicionales no están presentes en el esquema de BigQuery se pueden descartar, selecciona la opción Descartar campos desconocidos.

  • Puedes seleccionar solo una de las propiedades de suscripción, Usar el esquema de tema. o Usar un esquema de tabla.

Si no seleccionas las opciones Use topic schema o Use table schema, asegúrate de que la tabla de BigQuery tenga una columna llamada data de escribe BYTES, STRING o JSON. Pub/Sub escribe el mensaje en esta columna de BigQuery.

Es posible que no veas cambios en el esquema de temas de Pub/Sub o El esquema de la tabla de BigQuery se aplica de inmediato con mensajes se escribe en la tabla de BigQuery. Por ejemplo, si la columna Drop campo desconocidos está habilitada y hay un campo presente en la el esquema de Pub/Sub, pero no el esquema de BigQuery, mensajes escritos en la tabla de BigQuery podrían no contener el campo después de agregarlo al esquema de BigQuery. Con el tiempo, se sincronizan los esquemas y los mensajes posteriores incluyen el campo.

Cuando usas la opción Usar el esquema de tema de BigQuery puedes aprovechar los cambios de BigQuery la captura de datos (CDC). La CDC actualiza tus tablas de BigQuery procesar y aplicar cambios a las filas existentes.

Si deseas obtener más información sobre esta función, consulta Cómo transmitir actualizaciones de tablas con la captura de datos modificados.

Para aprender a usar esta función con suscripciones a BigQuery, consulta Captura de datos modificados de BigQuery.

Usar el esquema de tabla

Esta opción permite que Pub/Sub use el esquema de la tabla de BigQuery para escribir los campos de un JSON mensaje a las columnas correspondientes. Cuando uses esta opción, recuerda consulta los siguientes requisitos adicionales:

  • Los mensajes publicados deben estar en formato JSON.

  • Si el tema de la suscripción tiene un esquema asociado y, luego, la propiedad de codificación de mensajes debe establecerse en JSON.

  • Si hay campos de BigQuery que no están presentes en los mensajes, estos campos de BigQuery deben estar en modo NULLABLE.

  • Si los mensajes tienen campos adicionales que no están presentes en el el esquema de BigQuery y estos campos se pueden descartar, la opción Descartar campos desconocidos.

  • En el mensaje JSON, los valores DATE, DATETIME, TIME y TIMESTAMP deben ser números enteros que cumplan con las representaciones admitidas.

  • En el mensaje JSON, los valores NUMERIC y BIGNUMERIC deben ser bytes codificados con el BigDecimalByteStringEncoder.

  • Puedes seleccionar solo una de las propiedades de suscripción, Usar el esquema de tema. o Usar un esquema de tabla.

Si no seleccionas las opciones Use topic schema o Use table schema, asegúrate de que la tabla de BigQuery tenga una columna llamada data de escribe BYTES, STRING o JSON. Pub/Sub escribe el mensaje en esta columna de BigQuery.

Es posible que no veas los cambios en el esquema de la tabla de BigQuery efecto de inmediato con mensajes escritos en la tabla de BigQuery. Por ejemplo, si la opción Descartar campos desconocidos está habilitada y un campo está presentes en los mensajes, pero no en el esquema de BigQuery, mensajes escritos en la tabla de BigQuery podrían no contener el campo después de agregarlo al esquema de BigQuery. Con el tiempo, las sincronizaciones de esquema y los mensajes posteriores incluyen el campo.

Cuando usas la opción Usar el esquema de tabla para tu suscripción a BigQuery, también puede aprovechar la captura de datos modificados (CDC) de BigQuery. La CDC actualiza las tablas de BigQuery procesando y aplicando los cambios en las tablas existentes filas.

Si deseas obtener más información sobre esta función, consulta Cómo transmitir actualizaciones de tablas con la captura de datos modificados.

Para obtener información sobre cómo utilizar esta función con suscripciones a BigQuery, consulta Captura de datos modificados de BigQuery.

Quitar campos desconocidos

Esta opción se utiliza con las opciones Usar esquema de tema o Usar esquema de tabla de 12 a 1 con la nueva opción de compresión. Esta opción permite que Pub/Sub descarte cualquier campo que esté presente en el tema. en el esquema o el mensaje, pero no en el esquema de BigQuery. Sin Drop desconocida campos configurados, los mensajes con campos adicionales no se escriben en BigQuery y permanecen en las tareas pendientes de la suscripción. El suscripción termina en un estado de error.

Escribir metadatos

Esta opción permite que Pub/Sub escribir los metadatos de cada mensaje en columnas adicionales del en la tabla de BigQuery. De lo contrario, los metadatos no se escribe en la tabla de BigQuery.

Si seleccionas la opción Escribir metadatos, asegúrate de que el La tabla de BigQuery tiene los campos que se describen en la siguiente tabla.

Si no seleccionas la opción Escribir metadatos, la tabla de BigQuery de destino solo requiere el campo data, a menos que use_topic_schema es verdadero. Si seleccionas Escribir metadatos y Usa las opciones de esquema de tema, luego, el esquema del tema debe No contienen ningún campo con nombres que coincidan con los de los parámetros de metadatos. Esta limitación incluye versiones en mayúsculas y minúsculas de estos parámetros de Snake case.

Parámetros
subscription_name

STRING

Es el nombre de una suscripción.

message_id

STRING

ID de un mensaje

publish_time

TIMESTAMP

Indica la hora de publicación de un mensaje.

data

BYTES, STRING o JSON

El cuerpo del mensaje.

El campo data es obligatorio para todos los destinos las tablas de BigQuery que no seleccionan Usar el esquema de tema o Usar el esquema de tabla. Si el botón es de tipo JSON, el cuerpo del mensaje debe ser JSON válido.

attributes

STRING o JSON

Un objeto JSON que contiene todos los atributos del mensaje. También contiene campos adicionales que forman parte del Un mensaje de Pub/Sub que incluye la clave de ordenamiento, si están presentes.

Propiedades de Cloud Storage

Cuando seleccionas un tipo de entrega de suscripciones como Write to Cloud Storage, puedes especificar las siguientes propiedades adicionales.

Nombre del bucket

Ya debe existir un bucket de Cloud Storage antes de crear un suscripción a Cloud Storage.

Los mensajes se envían como lotes y se almacenan en el bucket de Cloud Storage. Un solo lote o archivo se almacena como un objeto. en el bucket.

El bucket de Cloud Storage debe tener Se inhabilitaron los pagos del solicitante.

Para crear un bucket de Cloud Storage, consulta Crea buckets.

Prefijo, sufijo y fecha y hora del nombre de archivo

Los archivos de salida de Cloud Storage generados por la Cloud Storage se almacenan como objetos en el bucket de Cloud Storage. El nombre del objeto almacenado en el bucket de Cloud Storage es de los siguientes: formato: <file-prefix><UTC-date-time>_<uuid><file-suffix>.

La siguiente lista incluye detalles del formato de archivo y los campos que personalizar:

  • <file-prefix> es el prefijo del nombre de archivo personalizado. Este paso es opcional,

  • <UTC-date-time> es una cadena personalizable generada automáticamente en función de la hora se crea el objeto.

  • <uuid> es una cadena aleatoria generada automáticamente para el objeto.

  • <file-suffix> es el sufijo del nombre de archivo personalizado. Este paso es opcional, El el sufijo del nombre de archivo no puede terminar en “/”.

  • Puedes cambiar el prefijo y el sufijo del nombre de archivo:

    • Por ejemplo, si el valor del prefijo del nombre de archivo es prod_ y el valor de el sufijo del nombre de archivo es _archive, se muestra prod_2023-09-25T04:10:00+00:00_uN1QuE_archive.

    • Si no especificas el prefijo y el sufijo del nombre de archivo, se almacenará en el bucket de Cloud Storage tiene el siguiente formato: <UTC-date-time>_<uuid>.

    • Los requisitos para nombrar objetos de Cloud Storage también se aplican al nombre de archivo. el prefijo y el sufijo. Para obtener más información, consulta Acerca de los objetos de Cloud Storage.

  • Puedes cambiar la forma en que se muestran la fecha y la hora en el nombre del archivo:

    • Comparadores de fecha y hora obligatorios que puedes usar solo una vez: año (YYYY o YY), mes (MM), día (DD), hora (hh), minuto (mm) y segundo (ss). Por ejemplo, YY-YYYY o MMM no es válido.

    • Comparadores opcionales que puedes usar solo una vez: separador de fecha y hora (T) y y el desplazamiento de zona horaria (Z o +00:00).

    • Elementos opcionales que puedes usar varias veces: guion (-), guion bajo (_), dos puntos (:) y barra diagonal (/).

    • Por ejemplo, si el valor del formato de fecha y hora del nombre de archivo es YYYY-MM-DD/hh_mm_ssZ, un nombre de objeto de muestra es prod_2023-09-25/04_10_00Z_uNiQuE_archive

    • Si el formato de fecha y hora del nombre de archivo termina en un carácter que no es un comparador, ese carácter reemplazará el separador entre <UTC-date-time> y <uuid> Por ejemplo, si el valor del formato de fecha y hora del nombre de archivo es YYYY-MM-DDThh_mm_ss-, un nombre de objeto de muestra es prod_2023-09-25T04_10_00-uNiQuE_archive

Agrupación en lotes de archivos

Las suscripciones a Cloud Storage te permiten decidir cuándo crear un nuevo archivo de salida que se almacena como un objeto en Cloud Storage bucket. Pub/Sub escribe un archivo de salida cuando uno de los se cumplan las condiciones de lotes especificadas. Los siguientes son los Condiciones de procesamiento por lotes de Cloud Storage:

  • Duración máxima del lote de almacenamiento. Este es un parámetro de configuración obligatorio. El La suscripción a Cloud Storage escribe un nuevo archivo de salida si se excede el valor especificado de la duración máxima. Si no se especifica el valor, se aplica un valor predeterminado de 5 minutos. Los siguientes son los valores aplicables para la duración máxima:

    • Valor mínimo: 1 minuto
    • Valor predeterminado = 5 minutos
    • Valor máximo = 10 minutos
  • Cantidad máxima de bytes de almacenamiento. Este es un parámetro de configuración opcional. El La suscripción a Cloud Storage escribe un nuevo archivo de salida si la se excede el valor especificado de la cantidad máxima de bytes. Las siguientes son las aplicables valores para la cantidad máxima de bytes:

    • Valor mínimo = 1 KB
    • Valor máximo = 10 GiB

Por ejemplo, puedes configurar la duración máxima en 6 minutos y máximos de 2 GB. Si en el minuto 4, el archivo de salida alcanza un tamaño de archivo de 2 GB, Pub/Sub finaliza el archivo anterior y comienza escribiendo a un nuevo archivo.

Una suscripción a Cloud Storage puede escribir en varios archivos de una de bucket de Cloud Storage al mismo tiempo. Si configuraste tu para crear un archivo nuevo cada 6 minutos, podrías observar se crean varios archivos de Cloud Storage cada 6 minutos.

En algunos casos, Pub/Sub puede empezar a escribir en un nuevo archivo anterior a la hora configurada por las condiciones de lotes. Un archivo también puede superar el valor máximo de bytes si la suscripción recibe mensajes superiores al valor máximo de bytes.

Formato de archivo

Cuando creas una suscripción a Cloud Storage, puedes especificar el formato de los archivos de salida que se almacenarán en un bucket de Cloud Storage como Text o Avro.

  • Texto: Los mensajes se almacenan como texto sin formato. Un carácter de línea nueva separa un mensaje del mensaje anterior en el archivo. Solo mensaje no se almacenan atributos ni otros metadatos.

  • Avro: Los mensajes se almacenan en Formato binario de Apache Avro. Cuando seleccionas Avro, puedes habilitar las siguientes propiedades adicionales:

    • Escribir metadatos: Esta opción te permite almacenar los metadatos del mensaje junto con el mensaje. Los metadatos como los campos subscription_name, message_id, publish_time y attributes se escriben en campos de nivel superior en el objeto Avro de salida, mientras que todas las demás propiedades de mensaje que no son datos (por ejemplo, order_key, si está presente) se agregan como entradas en el mapa attributes.

      Si la escritura de metadatos está inhabilitada, solo la carga útil del mensaje se escribe en el objeto Avro de salida. Este es el esquema de Avro para los mensajes de salida con la opción write metadata inhabilitada:

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

      Este es el esquema de Avro para los mensajes de salida con los metadatos de escritura habilitados:

      {
        "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" }
        ]
      }
      
    • Usar el esquema de tema: Esta opción permite que Pub/Sub use el esquema del tema de Pub/Sub al que se adjunta la suscripción cuando se escriben archivos de Avro.

      Cuando uses esta opción, recuerda verificar los siguientes requisitos adicionales:

      • El esquema del tema debe estar en formato Apache Avro.

      • Si usar esquema de tema y escribir metadatos están habilitados, el esquema de tema debe tener un objeto Record en la raíz. Pub/Sub expandirá la lista de campos del registro para incluir los campos de metadatos. Como resultado, el registro no puede contener ningún campo con el mismo nombre que los campos de metadatos (subscription_name, message_id, publish_time o attributes).

¿Qué sigue?