Se usó la API de Cloud Translation para traducir esta página.

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 que puedes configurar para una suscripción.

Antes de comenzar

Obtén más información sobre las suscripciones
Comprende el flujo de trabajo de la suscripción que crearás: Extracción, Envío o BigQuery.

Propiedades comunes de suscripción

Cuando creas una suscripción, debes especificar una cantidad de opciones para configurarla. Algunas de estas propiedades son comunes a todos los tipos de suscripciones y se analizarán 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 pase la duración de la retención de mensajes, es posible que Pub/Sub descarte el mensaje independientemente del estado de confirmación del mensaje. Para conservar los mensajes confirmados durante la retención de mensajes, consulta Repite y descarta mensajes.

Estos son los valores de la opción Duración de 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 deberse a suscripciones inactivas, necesidades de copia de seguridad o procesamiento lento. Si puedes procesar los mensajes en un plazo de 24 horas, no se generarán cargos adicionales. Para evitar cargos nuevos, administra estas situaciones de la siguiente manera:

Suscripciones inactivas. Borra suscripciones inactivas para evitar incurrir en cargos de retención de mensajes de suscripción.
Almacenamiento de copia de seguridad. Si usas la retención de suscripciones como almacenamiento de copia de seguridad, puedes cambiar a otra opción de almacenamiento, como la retención de mensajes por temas o la retención de mensajes confirmados. La retención de mensajes por tema almacena los mensajes solo una vez a nivel del tema y permanecen disponibles para que todas las suscripciones los consuman cuando sea necesario.
Demoras en el procesamiento. Agrega más suscriptores (si es posible) para procesar los mensajes en un día.

Retener mensajes confirmados

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

La opción Conservar mensajes confirmados te permite retener los mensajes confirmados durante el período de retención 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.

Las suscripciones sin actividades de suscriptores ni cambios realizados en las propiedades de suscripción vencen. Si Pub/Sub detecta actividad de suscriptores o si actualizas cualquiera de las propiedades de la suscripción, el reloj de eliminación de la suscripción se reiniciará. Algunos ejemplos de actividades del suscriptor incluyen conexiones abiertas, extracciones activas o inserciones exitosas.

Si especificas el período de vencimiento, el valor debe ser mayor que la duración de retención de mensajes especificada en la opción Duración de la retención de mensajes.

Los siguientes son los valores de la opción Período de vencimiento (Expiration period):

Valor predeterminado = 31 días
Valor mínimo = 1 día
El valor máximo es de 365 días.

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

Fecha límite de confirmación

La opción Fecha límite de confirmación especifica el plazo inicial después del cual se vuelve a enviar un mensaje no confirmado. Puedes extender el plazo de confirmación por mensaje mediante el envío de solicitudes ModifyAckDeadline posteriores.

Los siguientes son los valores de la opción Acknowledgement deadline:

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 de forma dinámica el plazo de confirmación de recepción. Si lo haces, es posible que el mensaje se vuelva a entregar antes del plazo de confirmación que estableciste. Para anular este comportamiento, usa minDurationPerAckExtension y maxDurationPerAckExtension. Para obtener más información sobre el uso de estos valores, consulta Asistencia de entrega “exactamente una vez” en bibliotecas cliente.

Filtro de suscripción

Usa la opción Filtro de suscripción para especificar una string con una 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 confirma automáticamente los mensajes que no coinciden con el filtro.

Puedes filtrar los mensajes por sus atributos, pero no por los datos que contienen.
Si no se especifica, la suscripción no filtra los mensajes y los suscriptores los reciben todos.
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, los clientes suscriptores reciben mensajes publicados en la misma región con la misma clave de ordenamiento en el orden en que el servicio recibió los mensajes.

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

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

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

Tema de mensajes no entregados

Cuando un mensaje no se puede entregar después de una cantidad determinada de intentos de entrega o un suscriptor no puede confirmar la recepción del 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. A continuación, se muestran 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, consulta Reenvío a temas de mensajes no entregados.

Política de reintentos

Si la fecha límite de confirmación vence o un suscriptor responde con una confirmación negativa, Pub/Sub puede volver a enviar el mensaje. Este intento de reintento de entrega se conoce como la política de reintento de la suscripción.

De forma predeterminada, la política de reintento de una suscripción usa Reintentar de inmediato. Con esta opción, Pub/Sub vuelve a enviar el mensaje cuando vence la fecha límite de confirmación o un suscriptor responde con una confirmación negativa.

También puedes configurar el valor como Reintentar después de un retraso de retirada exponencial. En este caso, debes especificar los valores de retirada máximo y mínimo.

A continuación, se incluyen algunos lineamientos para establecer los valores de los valores de retirada máximos y mínimos:

Si estableces el valor máximo de la duración de la retirada, el valor predeterminado de la duración mínima de la retirada es de 10 segundos.
Si estableces el valor mínimo para la duración de la retirada, el valor predeterminado de 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 la fecha límite de confirmación de recepció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 la suscripción de extracción

Cuando configuras una suscripción de extracción, puedes especificar las siguientes 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 la entrega al menos una vez para cada mensaje.

Propiedades de la suscripción de envío

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

Extremos

URL del extremo (obligatoria). Una dirección HTTPS de acceso público El servidor para el extremo de 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 un comprobante de propiedad para los dominios de URL de suscripción de envío. Si tu dominio recibe solicitudes POST inesperadas de Pub/Sub, puedes denunciar sospechas de abuso.

Proporción de eficiencia energética (EER)

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

La configuración de autenticación para una suscripción de envío autenticada consiste en una cuenta de servicio administrada por el usuario y los parámetros de público que se especifican en una llamada create, patch o ModifyPushConfig. También debes otorgar una función específica a una cuenta de servicio especial administrada por Google, como se explica en la siguiente sección.

Cuenta de servicio administrada por el usuario (obligatoria). La cuenta de servicio asociada con la suscripción de envío. Esta cuenta se utiliza como la reclamación email del token web JSON (JWT) generado. La siguiente es una lista de requisitos para la cuenta de servicio:
- Esta cuenta de servicio debe estar en el mismo proyecto que la suscripción de envío.
- La principal que crea o modifica la suscripción de envío debe tener el permiso iam.serviceAccounts.actAs en la cuenta de servicio. Puedes otorgar una función con este permiso en el proyecto, la carpeta o la organización para permitir que el llamador actúe en nombre de varias cuentas de servicio, o bien otorgar una función con este permiso en la cuenta de servicio para permitir que el emisor suplante solo la identidad de esta cuenta de servicio.
Público. Es una string única que no distingue entre mayúsculas y minúsculas y que el webhook usa para validar el público objetivo de este token en particular.
Cuenta de servicio administrada por Google (obligatoria).
- Pub/Sub crea de forma automática una cuenta de servicio con el formato service-{PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com.
- A esta cuenta de servicio se le debe otorgar el permiso iam.serviceAccounts.getOpenIdToken (incluido en la función roles/iam.serviceAccountTokenCreator) a fin de permitir que Pub/Sub cree tokens JWT para las solicitudes de envío autenticadas.

Desenvolvimiento de la carga útil

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

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

Propiedades de BigQuery

Cuando seleccionas un tipo de entrega de suscripción como Escribir en 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 se adjunta la suscripción. Además, Pub/Sub escribe los campos de los mensajes en las columnas correspondientes de la tabla de BigQuery.

Cuando utilice esta opción, recuerde verificar los siguientes requisitos adicionales:

Los campos del esquema de 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 de tema también debe ser opcional en el esquema de BigQuery.
No es necesario que los campos obligatorios en el esquema de tema sean obligatorios en el esquema de BigQuery.
Si hay campos de BigQuery que no están presentes en el esquema del tema, estos campos de BigQuery deben estar en modo NULLABLE.
Si el esquema de tema tiene campos adicionales que no están presentes en el esquema de BigQuery y estos campos se pueden descartar, selecciona la opción Descartar campos desconocidos.
Puedes seleccionar solo una de las propiedades de suscripción, Use topic schema o Use table schema.

Si no seleccionas la opción Usar el esquema de tema o Usar el esquema de la tabla, asegúrate de que la tabla de BigQuery tenga una columna llamada data de tipo BYTES, STRING o JSON. Pub/Sub escribe el mensaje en esta columna de BigQuery.

Es posible que no veas que los cambios en el esquema de temas de Pub/Sub o en el esquema de la tabla de BigQuery se apliquen de inmediato con los mensajes escritos en la tabla de BigQuery. Por ejemplo, si la opción Descartar campos desconocidos está habilitada y un campo está presente en el esquema de Pub/Sub, pero no en el esquema de BigQuery, es posible que los mensajes escritos en la tabla de BigQuery aún no contengan el campo después de agregarlo al esquema de BigQuery. Finalmente, los esquemas se sincronizan y los mensajes posteriores incluyen el campo.

Cuando usas la opción Usar el esquema de tema para tu suscripción a BigQuery, también puedes aprovechar la captura de datos modificados (CDC) de BigQuery. La CDC actualiza las tablas de BigQuery a través del procesamiento y la aplicación de cambios en 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 las 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 mensaje JSON en las columnas correspondientes. Cuando uses esta opción, recuerda verificar los siguientes requisitos adicionales:

Los mensajes publicados deben estar en formato JSON.
Si el tema de la suscripción tiene un esquema asociado, 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 esquema de BigQuery y estos campos se pueden descartar, selecciona 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 BigDecimalByteStringEncoder.
Puedes seleccionar solo una de las propiedades de suscripción, Use topic schema o Use table schema.

Es posible que no veas que los cambios en el esquema de la tabla de BigQuery se apliquen de inmediato con los mensajes escritos en la tabla de BigQuery. Por ejemplo, si la opción Descartar campos desconocidos está habilitada y un campo está presente en los mensajes, pero no en el esquema de BigQuery, es posible que los mensajes escritos en la tabla de BigQuery aún no contengan el campo después de agregarlo al esquema de BigQuery. Finalmente, el esquema se sincroniza, 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 puedes aprovechar la captura de datos modificados (CDC) de BigQuery. La CDC actualiza las tablas de BigQuery a través del procesamiento y la aplicación de cambios en 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 obtener información sobre cómo usar esta función con las suscripciones a BigQuery, consulta Captura de datos modificados de BigQuery.

Quitar campos desconocidos

Esta opción se usa con las opciones Usar el esquema de tema o Usar el esquema de la tabla. Esta opción permite que Pub/Sub descarte cualquier campo que esté presente en el esquema del tema o el mensaje, pero no en el esquema de BigQuery. Si la opción Descartar campos desconocidos está configurada, los mensajes con campos adicionales no se escriben en BigQuery y permanecen en las tareas pendientes de la suscripción. La suscripción termina en un estado de error.

Escribir metadatos

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

Si seleccionas la opción Escribir metadatos, asegúrate de que la tabla de BigQuery tenga los campos descritos en la siguiente tabla.

Si no seleccionas la opción Escribir metadatos, la tabla de destino de BigQuery solo requiere el campo data, a menos que use_topic_schema sea verdadero. Si seleccionas las opciones Escribir metadatos y Usar esquema de tema, el esquema del tema no debe contener ningún campo con nombres que coincidan con los de los parámetros de metadatos. Esta limitación incluye versiones de estos parámetros en formato camelCase.

Parámetros
`subscription_name`	STRING Es el nombre de una suscripción.
`message_id`	STRING ID de un mensaje
`publish_time`	TIMESTAMP Es la hora de publicación de un mensaje.
`data`	BYTES, STRING o JSON El cuerpo del mensaje. El campo `data` es obligatorio para todas las tablas de destino de BigQuery que no seleccionan Usar el esquema de tema. Si el campo 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 de mensaje. También contiene campos adicionales que forman parte del mensaje de Pub/Sub, incluida la clave de ordenamiento, si está presente.

Propiedades de Cloud Storage

Cuando seleccionas un tipo de entrega de suscripción como Escribir en Cloud Storage, puedes especificar las siguientes propiedades adicionales.

Nombre del bucket

Ya debe existir un bucket de Cloud Storage antes de crear una 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 inhabilitados 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 que genera la suscripción a Cloud Storage se almacenan como objetos en el bucket de Cloud Storage. El nombre del objeto almacenado en el bucket de Cloud Storage tiene el siguiente formato: <file-prefix><UTC-date-time>_<uuid><file-suffix>.

En la siguiente lista, se incluyen detalles del formato de archivo y los campos que puedes 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 del momento en que se creó 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 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 del sufijo del nombre de archivo es _archive, un nombre de objeto de muestra es prod_2023-09-25T04:10:00+00:00_uN1QuE_archive.
- Si no especificas el prefijo y el sufijo del nombre de archivo, el nombre del objeto almacenado en el bucket de Cloud Storage tendrá el siguiente formato: <UTC-date-time>_<uuid>.
- Los requisitos para nombrar objetos de Cloud Storage también se aplican al prefijo y al sufijo del nombre de archivo. Para obtener más información, consulta Acerca de los objetos de Cloud Storage.
Puedes cambiar cómo se muestran la fecha y la hora en el nombre de archivo:
- Comparadores de fecha y hora obligatorios que solo puedes usar 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 son válidos.
- Comparadores opcionales que puedes usar solo una vez: separador de fecha y hora (T) y 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 con 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.

Procesamiento de archivos por lotes

Las suscripciones a Cloud Storage te permiten decidir cuándo quieres crear un archivo de salida nuevo que se almacena como un objeto en el bucket de Cloud Storage. Pub/Sub escribe un archivo de salida cuando se cumple una de las condiciones de procesamiento por lotes especificadas. A continuación, se detallan las 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. La suscripción a Cloud Storage escribe un nuevo archivo de salida si se supera el valor especificado de duración máxima. Si no especificas el valor, se aplicará 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. La suscripción a Cloud Storage escribe un nuevo archivo de salida si se supera el valor especificado de cantidad máxima de bytes. Los siguientes son los valores aplicables 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 la cantidad máxima de bytes en 2 GB. Si al 4o minuto el archivo de salida alcanza un tamaño de archivo de 2 GB, Pub/Sub finaliza el archivo anterior y comienza a escribir en un archivo nuevo.

Una suscripción a Cloud Storage puede escribir en varios archivos de un bucket de Cloud Storage de forma simultánea. Si configuraste tu suscripción para crear un archivo nuevo cada 6 minutos, es posible que observes que se crean varios archivos de Cloud Storage cada 6 minutos.

En algunas situaciones, Pub/Sub podría comenzar a escribir en un archivo nuevo antes de la hora configurada por las condiciones de procesamiento por lotes de archivos. Un archivo también puede superar el valor máximo de bytes si la suscripción recibe mensajes con ese valor.

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 se almacenan las cargas útiles de mensajes, no los atributos ni otros metadatos.
Avro: Los mensajes se almacenan en formato binario de Apache Avro.

Cuando seleccionas Avro, también puedes habilitar la opción de escritura de metadatos. Esta opción te permite almacenar los metadatos del mensaje junto con el mensaje.

Los metadatos, como subscription_name, message_id, publish_time y los campos de atributos, se escriben en campos de nivel superior en el objeto Avro de salida, mientras que todas las demás propiedades del mensaje, excepto los datos (por ejemplo, order_key, si están presentes), se agregan como entradas en el mapa de atributos.

Si los metadatos de escritura están inhabilitados, 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 sin los metadatos de escritura habilitados:
```
{
  "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 write metadata 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" }
  ]
}
```