Esta página se ha traducido con Cloud Translation API.

Propiedades de la suscripción

Las propiedades de suscripción de Pub/Sub son las características de una suscripción. Puede definir las propiedades de la suscripción al crearla o actualizarla.

En este documento se describen las diferentes propiedades de suscripción que puede definir para una suscripción.

Antes de empezar

Consulta información sobre las suscripciones.
Familiarízate con el flujo de trabajo de la suscripción que vas a crear: pull, push o BigQuery.

Propiedades comunes de las suscripciones

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

Periodo de retención del mensaje

La opción Duración de conservación de mensajes especifica cuánto tiempo conserva Pub/Sub los mensajes después de publicarlos. Una vez que haya transcurrido el periodo de conservación de los mensajes, Pub/Sub puede descartar el mensaje independientemente del estado de confirmación del mensaje. Para conservar los mensajes confirmados durante el periodo de retención de los mensajes, consulta Reproducir y descartar mensajes.

Estos son los valores de la opción Duración de conservación de mensajes:

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

Los mensajes no confirmados pueden deberse a suscripciones inactivas, necesidades de copias de seguridad o procesamiento lento. Si procesas los mensajes en un plazo de 24 horas, no se aplicarán cargos adicionales. Para evitar que se te apliquen nuevos cargos, gestiona estas situaciones de la siguiente manera:

Suscripciones inactivas. Eliminar suscripciones inactivas para evitar que se te cobren cargos por retención de mensajes de suscripción.
Almacenamiento de copias de seguridad. Si estás usando la conservación de suscripciones como almacenamiento de copias de seguridad, puedes cambiar a otra opción de almacenamiento, como la conservación de mensajes de temas o la conservación de mensajes confirmados. La conservación de mensajes de temas almacena los mensajes solo una vez a nivel del tema y permanecen disponibles para que todas las suscripciones los consuman cuando sea necesario.
Retrasos en el procesamiento. Añade más suscriptores (si es posible) para procesar los mensajes en un día.

Conservar mensajes confirmados

Si especificas el Periodo de retención del mensaje, también puedes indicar si quieres conservar los mensajes confirmados.

La opción Conservar mensajes confirmados te permite conservar los mensajes confirmados durante el periodo de retención de mensajes especificado. Esto conlleva un aumento de las tarifas de almacenamiento de mensajes. Para obtener más información, consulta los costes de almacenamiento.

Periodo de caducidad

La opción Periodo de vencimiento te permite ampliar el periodo de vencimiento de tu suscripción.

Las suscripciones que no tengan actividad del suscriptor ni cambios en las propiedades de la suscripción caducan. Si Pub/Sub detecta actividad de suscriptores o si actualizas alguna de las propiedades de la suscripción, el reloj de eliminación de la suscripción se reiniciará. Algunos ejemplos de actividades de los suscriptores son las conexiones abiertas, las extracciones activas o las inserciones correctas.

Si especifica el periodo de caducidad, el valor debe ser al menos igual que la duración de retención del mensaje especificada en la opción Duración de retención del mensaje.

Estos son los valores de la opción Periodo de vencimiento:

Valor predeterminado: 31 días
Valor mínimo: 1 día

Para evitar que caduque una suscripción, establece el periodo de vencimiento en never expire.

Fecha límite de confirmación

La opción Plazo de confirmación especifica el plazo inicial tras el cual se vuelve a enviar un mensaje no confirmado. Puedes ampliar el plazo de confirmación de lectura de cada mensaje enviando solicitudes posteriores de ModifyAckDeadline.

Estos son los valores de la opción Fecha límite 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 velocidad de entrega y modificar dinámicamente el plazo de confirmación. Si lo haces, es posible que el mensaje se vuelva a enviar antes de la fecha límite de confirmación que hayas establecido. Para anular este comportamiento, usa minDurationPerAckExtension y maxDurationPerAckExtension. Para obtener más información sobre el uso de estos valores, consulta Compatibilidad con la entrega exactamente una vez en las bibliotecas de cliente.

Transformaciones de un solo mensaje (SMTs)

Las SMTs permiten hacer modificaciones ligeras en los atributos y los datos de los mensajes directamente en Pub/Sub. Esta función permite limpiar, filtrar o convertir el formato de los datos antes de que se envíen los mensajes a un cliente suscriptor.

Para obtener más información, consulta Descripción general de los SMTs y Crear una suscripción con SMTs.

Filtro de suscripciones

Usa la opción Filtro de suscripción para especificar una cadena con una expresión de filtro. Si una suscripción tiene un filtro, solo se enviarán los mensajes que coincidan con él. El servicio 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 contengan.
Si no se especifica, la suscripción no filtra los mensajes y los suscriptores reciben todos los mensajes.
Los filtros no se pueden cambiar ni eliminar después de aplicarlos.

Cuando recibes mensajes de una suscripción con un filtro, no se te aplican tarifas de salida por los mensajes que Pub/Sub confirma automáticamente. Se te cobrarán tarifas por la entrega de mensajes y por el almacenamiento relacionado con la función de búsqueda (seek) de estos mensajes.

Para obtener más información, consulta Filtrar mensajes de una suscripción.

Ordenación de mensajes

Si una suscripción tiene habilitada la opción Ordenación de los mensajes, los clientes suscriptores reciben los mensajes publicados en la misma región con la misma clave de ordenación en el orden en el que el servicio los ha recibido.

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 editores deben enviar mensajes con una clave de ordenación para que Pub/Sub pueda entregar los mensajes en orden.

Si no se define, es posible que Pub/Sub no entregue los mensajes en orden, aunque tengan una clave de ordenación.

Tema de mensajes fallidos

Cuando no se pueda entregar un mensaje después de un número determinado de intentos de entrega o un suscriptor no pueda confirmar la recepción del mensaje, puedes configurar un tema de mensajes fallidos en el que se puedan volver a publicar estos mensajes.

Si configura un tema de mensajes fallidos, también puede especificar el número máximo de intentos de entrega. Estos son los valores del número máximo de intentos de entrega del tema de mensajes fallidos:

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 fallidos está en un proyecto distinto al de la suscripción, también debes especificar el ID del proyecto con el tema de mensajes fallidos.

Para obtener más información, consulta Reenvío a temas de mensajes fallidos.

Política de reintentos

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

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

También puedes definir el valor como Reintentar después de un retraso del tiempo de espera exponencial. En ese caso, debe especificar los valores máximo y mínimo del tiempo de espera.

A continuación, se indican algunas directrices para definir los valores de retroceso máximo y mínimo:

Si define el valor máximo de la duración del tiempo de espera, el valor predeterminado de la duración mínima del tiempo de espera es de 10 segundos.
Si defines el valor mínimo de la duración del tiempo de espera, el valor predeterminado de la duración máxima del tiempo de espera será de 600 segundos.
La duración máxima del tiempo de espera que puedes especificar es de 600 segundos.

Política de reintentos y mensajes por 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.
El plazo de confirmación finaliza.

Política de reintentos y suscripción push

Si recibes mensajes de una suscripción de inserción, es posible que Pub/Sub vuelva a enviar los mensajes después del tiempo de espera de inserción en lugar de la duración del tiempo de espera exponencial. Si el tiempo de espera de inserción es mayor que la duración del tiempo de espera exponencial, Pub/Sub vuelve a enviar los mensajes no confirmados después del tiempo de espera de inserción.

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 define, Pub/Sub cumple las garantías de entrega exactamente una vez. Si no se especifica, la suscripción admite la entrega al menos una vez de cada mensaje.

Propiedades de suscripción de inserción

Cuando configuras una suscripción push, puedes especificar las siguientes propiedades.

Endpoints

URL del endpoint (obligatoria). Una dirección HTTPS de acceso público. El servidor del endpoint de envío debe tener un certificado SSL válido firmado por una autoridad de certificación. El servicio Pub/Sub envía mensajes a los endpoints de inserción desde la misma región en la que el servicio Pub/Sub almacena los mensajes. Google Cloud El servicio Pub/Sub entrega mensajes de la misma región en la medida de lo posible. Google Cloud

Si los suscriptores usan un cortafuegos, no podrán recibir solicitudes push. Para recibir solicitudes push, debes desactivar el cortafuegos y verificar el JSON Web Token (JWT) utilizado en la solicitud. Si un suscriptor tiene un cortafuegos, es posible que recibas un 403 permission deniederror.
Pub/Sub ya no requiere una prueba de propiedad para los dominios de URL de suscripción push. Si tu dominio recibe solicitudes POST inesperadas de Pub/Sub, puedes denunciar un posible abuso.

Autenticación

Habilita la autenticación. Cuando está habilitada, los mensajes que Pub/Sub envía al endpoint push incluyen un encabezado de autorización para permitir que el endpoint autentique la solicitud. Los mecanismos de autenticación y autorización automáticos están disponibles para los endpoints de funciones de App Engine Standard y Cloud Run alojados en el mismo proyecto que la suscripción.

La configuración de autenticación de una suscripción push autenticada consta de una cuenta de servicio gestionada por el usuario y los parámetros de audiencia que se especifican en una llamada create, patch o ModifyPushConfig. También debes conceder un rol específico a una cuenta de servicio, como se explica en la siguiente sección.

Audiencia. Una cadena única que no distingue entre mayúsculas y minúsculas que el webhook usa para validar la audiencia a la que va dirigido este token concreto.
Cuenta de servicio. Pub/Sub crea automáticamente una cuenta de servicio con el formato service-{PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com.

Requisitos previos para habilitar la autenticación

La cuenta de servicio gestionada por el usuario es la cuenta de servicio asociada a la suscripción push. Esta cuenta se usa como la reclamación email del JSON Web Token (JWT) generado. A continuación, se muestra una lista de los requisitos de la cuenta de servicio:

Esta cuenta de servicio gestionada por el usuario debe estar en el mismo proyecto que la suscripción push.
La entidad de seguridad que cree o modifique la suscripción push debe tener el permiso iam.serviceAccounts.actAs en la cuenta de servicio gestionada por el usuario para adjuntar la cuenta de servicio a la suscripción push. Para obtener más información, consulta el artículo sobre cómo asociar cuentas de servicio a recursos.
Permisos necesarios: se debe conceder a esta cuenta de servicio el permiso iam.serviceAccounts.getOpenIdToken (incluido en el rol roles/iam.serviceAccountTokenCreator) para permitir que Pub/Sub cree tokens JWT para que la cuenta de servicio especificada autentique las solicitudes push.

Retirada de envoltorio de la carga útil

La opción Habilitar el desempaquetado de la carga útil elimina de los mensajes de Pub/Sub todos los metadatos de los mensajes, excepto los datos de los mensajes. Con el desempaquetado de la carga útil, los datos del mensaje se envían directamente como cuerpo HTTP.

También puede habilitar la opción Escribir metadatos. La opción Escribir metadatos vuelve a añadir los metadatos del mensaje que se habían eliminado anteriormente al encabezado de la solicitud.

Propiedades de BigQuery

Si selecciona Escribir en BigQuery como tipo de entrega de la suscripción, puede especificar las siguientes propiedades adicionales.

Usar el esquema de temas

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

Si utilizas esta opción, recuerda que debes cumplir los siguientes requisitos adicionales:

Los campos del esquema del tema y del esquema de BigQuery deben tener los mismos nombres y sus tipos deben ser compatibles entre sí.
Cualquier campo opcional del esquema del tema también debe ser opcional en el esquema de BigQuery.
No es necesario que los campos obligatorios del esquema del 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 deben estar en el modo NULLABLE.
Si el esquema del tema tiene campos adicionales que no están presentes en el esquema de BigQuery y estos campos se pueden eliminar, seleccione la opción Eliminar campos desconocidos.
Solo puede seleccionar una de las propiedades de suscripción: Usar esquema de tema o Usar esquema de tabla.

Si no seleccionas la opción Usar esquema de tema o Usar esquema de 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 los cambios en el esquema de los temas de Pub/Sub o en el esquema de la tabla de BigQuery no se apliquen inmediatamente a los mensajes escritos en la tabla de BigQuery. Por ejemplo, si la opción Eliminar campos desconocidos está habilitada y hay un campo en el esquema de Pub/Sub, pero no en el de BigQuery, es posible que los mensajes escritos en la tabla de BigQuery sigan sin contener el campo después de añadirlo al esquema de BigQuery. Finalmente, los esquemas se sincronizan y los mensajes posteriores incluyen el campo.

Si utiliza la opción Usar esquema de tema en su suscripción de BigQuery, también puede aprovechar la captura de datos de cambios (CDC) de BigQuery. La CDC actualiza tus tablas de BigQuery procesando y aplicando los cambios a las filas.

Para obtener más información sobre esta función, consulta el artículo Transmitir actualizaciones de tablas con la captura de datos de cambios.

Para saber cómo usar esta función con las suscripciones de BigQuery, consulta el artículo Captura de datos modificados de BigQuery.

Usar el esquema de una 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. Si utiliza esta opción, recuerde que debe cumplir los siguientes requisitos adicionales:

Los nombres de cada columna de la tabla de BigQuery solo pueden contener letras (a-z, A-Z), números (0-9) o guiones bajos (_).
Los mensajes publicados deben estar en formato JSON.

Se admiten las siguientes conversiones JSON:

Tipo JSON	Tipo de datos de BigQuery
`string`	`NUMERIC`, `BIGNUMERIC`, `DATE`, `TIME`, `DATETIME` o `TIMESTAMP`
`number`	`NUMERIC`, `BIGNUMERIC`, `DATE`, `TIME`, `DATETIME` o `TIMESTAMP`

Cuando se usan conversiones de number a DATE, DATETIME, TIME o TIMESTAMP, el número debe cumplir las representaciones admitidas.
Cuando se usa la conversión de number a NUMERIC o BIGNUMERIC, la precisión y el intervalo de valores se limitan a los aceptados por el estándar IEEE 754 para la aritmética de coma flotante. Si necesitas una alta precisión o un intervalo de valores más amplio, usa las conversiones de string a NUMERIC o BIGNUMERIC.
Cuando se usan conversiones de string a NUMERIC o BIGNUMERIC, Pub/Sub asume que la cadena es un número legible (por ejemplo, "123.124"). Si no se puede procesar la cadena como un número legible, Pub/Sub la trata como bytes codificados con BigDecimalByteStringEncoder.

Si el tema de la suscripción tiene un esquema asociado, la propiedad de codificación de mensajes debe tener el valor JSON.
Si hay campos de BigQuery que no están presentes en los mensajes, estos campos deben estar en el modo NULLABLE.
Si los mensajes tienen campos adicionales que no están presentes en el esquema de BigQuery y estos campos se pueden eliminar, selecciona la opción Eliminar campos desconocidos.
Solo puede seleccionar una de las propiedades de suscripción: Usar esquema de tema o Usar esquema de tabla.

Es posible que los cambios en el esquema de la tabla de BigQuery no se apliquen inmediatamente a los mensajes escritos en la tabla de BigQuery. Por ejemplo, si la opción Eliminar campos desconocidos está habilitada y hay un campo en los mensajes, pero no en el esquema de BigQuery, es posible que los mensajes escritos en la tabla de BigQuery sigan sin contener el campo después de añadirlo al esquema de BigQuery. Finalmente, el esquema se sincroniza y los mensajes posteriores incluyen el campo.

Si utiliza la opción Usar esquema de tabla en su suscripción de BigQuery, también puede aprovechar la captura de datos de cambios (CDC) de BigQuery. La CDC actualiza tus tablas de BigQuery procesando y aplicando los cambios a las filas.

Para obtener más información sobre esta función, consulta el artículo Transmitir actualizaciones de tablas con la captura de datos de cambios.

Para saber cómo usar esta función con las suscripciones de BigQuery, consulta el artículo Captura de datos modificados de BigQuery.

Eliminar campos desconocidos

Esta opción se usa con las opciones Usar esquema de tema o Usar esquema de tabla. Cuando está habilitada, esta opción permite que Pub/Sub elimine cualquier campo que esté presente en el esquema del tema o del mensaje, pero no en el esquema de BigQuery. Los campos que no forman parte del esquema de BigQuery se eliminan al escribir el mensaje en la tabla de BigQuery.

Si no se ha definido la opción Eliminar campos desconocidos, los mensajes con campos adicionales no se escriben en BigQuery y permanecen en la acumulación de la suscripción, a menos que configure un tema de mensajes fallidos.

El ajuste Eliminar campos desconocidos no afecta a los campos que no se definen en el esquema del tema de Pub/Sub ni en el esquema de la tabla de BigQuery. En este caso, se envía un mensaje de Pub/Sub válido a la suscripción. Sin embargo, como BigQuery no tiene columnas definidas para estos campos adicionales, se eliminan durante el proceso de escritura de BigQuery. Para evitar este comportamiento, asegúrate de que todos los campos incluidos en el mensaje de Pub/Sub también estén incluidos en el esquema de la tabla de BigQuery.

El comportamiento en relación con los campos adicionales también puede depender del tipo de esquema específico (Avro o Protocol Buffer) y de la codificación (JSON o binaria) que se utilicen. Para obtener información sobre cómo afectan estos factores a la gestión de campos adicionales, consulta la documentación de tu tipo de esquema y codificación específicos.

Escribir metadatos

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

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

Si no selecciona la opción Escribir metadatos, la tabla de BigQuery de destino solo requerirá el campo data, a menos que use_topic_schema sea true. Si selecciona 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 las versiones en camel case de estos parámetros en snake case.

Parámetros
`subscription_name`	STRING Nombre de una suscripción.
`message_id`	STRING ID de un mensaje
`publish_time`	TIMESTAMP 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 BigQuery de destino que no seleccionen Usar esquema de tema o Usar esquema de tabla. Si el campo es de tipo JSON, el cuerpo del mensaje debe ser un 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 mensaje de Pub/Sub, incluida la clave de ordenación, si está presente.

Propiedades de Cloud Storage

Si seleccionas el tipo de entrega de suscripción Escribir en Cloud Storage, puedes especificar las siguientes propiedades adicionales.

Nombre del segmento

Debes crear un segmento de Cloud Storage antes de crear una suscripción de Cloud Storage.

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

La función Pagos del solicitante debe estar inhabilitada en el segmento de Cloud Storage.

Para crear un segmento de Cloud Storage, consulta Crear segmentos.

Prefijo, sufijo y fecha y hora del nombre de archivo

Los archivos de Cloud Storage de salida que genera la suscripción a Cloud Storage se almacenan como objetos en el segmento de Cloud Storage. El nombre del objeto almacenado en el segmento de Cloud Storage tiene el siguiente formato: <file-prefix><UTC-date-time>_<uuid><file-suffix>.

En la siguiente lista se incluyen detalles sobre el formato de archivo y los campos que puede personalizar:

<file-prefix> es el prefijo de nombre de archivo personalizado. Este campo es opcional.
<UTC-date-time> es una cadena generada automáticamente y personalizable que se basa en la hora en la que se crea el objeto.
<uuid> es una cadena aleatoria generada automáticamente para el objeto.
<file-suffix> es el sufijo de nombre de archivo personalizado. Este campo 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 ejemplo es prod_2023-09-25T04:10:00+00:00_uN1QuE_archive.
- Si no especifica el prefijo ni el sufijo del nombre de archivo, el nombre del objeto almacenado en el segmento de Cloud Storage tendrá el siguiente formato: <UTC-date-time>_<uuid>.
- Los requisitos de nomenclatura de los objetos de Cloud Storage también se aplican al prefijo y al sufijo del nombre de archivo. Para obtener más información, consulta el artículo 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:
- Matchers 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.
- Matchers opcionales que solo puedes usar una vez: separador de fecha y hora (T) y diferencia horaria (Z o +00:00).
- Elementos opcionales que puede usar varias veces: guion (-), guion bajo (_), dos puntos (:) y barra (/).
- 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 ejemplo 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 elemento de coincidencia, ese carácter sustituirá al 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 ejemplo es prod_2023-09-25T04_10_00-uNiQuE_archive.

Procesamiento por lotes de archivos

Las suscripciones de Cloud Storage te permiten decidir cuándo quieres crear un archivo de salida que se almacene como objeto en el segmento de Cloud Storage. Pub/Sub escribe un archivo de salida cuando se cumple una de las condiciones de procesamiento por lotes especificadas. Estas son las condiciones de procesamiento por lotes de Cloud Storage:

Duración máxima del lote de almacenamiento. Este ajuste es 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á el valor predeterminado de 5 minutos. Estos son los valores aplicables a la duración máxima:
- Valor mínimo: 1 minuto
- Valor predeterminado: 5 minutos
- Valor máximo: 10 minutos
Máximo de bytes por lote de almacenamiento. Este ajuste es opcional. La suscripción a Cloud Storage escribe un nuevo archivo de salida si se supera el valor especificado de bytes máximos. Estos son los valores aplicables para el número máximo de bytes:
- Valor mínimo: 1 KB
- Valor máximo: 10 GiB
Número máximo de mensajes por lote de almacenamiento. Este ajuste es opcional. La suscripción a Cloud Storage escribe un nuevo archivo de salida si se supera el número máximo de mensajes especificado. Estos son los valores aplicables para el número máximo de mensajes:
- Valor mínimo = 1000

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

Una suscripción de Cloud Storage puede escribir en varios archivos de un segmento de Cloud Storage simultáneamente. Si has configurado tu suscripción para que cree 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 puede empezar 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 de Max bytes si la suscripción recibe mensajes de mayor tamaño que el valor de Max bytes.

Formato de archivo

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

Texto: los mensajes se almacenan como texto sin formato. Un carácter de salto de línea separa un mensaje del anterior en el archivo. Solo se almacenan las cargas útiles de los mensajes, no los atributos ni otros metadatos.
Avro los mensajes se almacenan en formato binario de Apache Avro. Si selecciona Avro, puede 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 del objeto Avro de salida, mientras que todas las demás propiedades del mensaje que no sean datos (por ejemplo, una clave de ordenación, si está presente) se añaden como entradas en el mapa attributes.
  
  Si la opción Escribir metadatos está inhabilitada, solo se escribirá la carga útil del mensaje en el objeto Avro de salida. Este es el esquema Avro de los mensajes de salida con la opción Escribir metadatos inhabilitada:
```
{
  "type": "record",
  "namespace": "com.google.pubsub",
  "name": "PubsubMessage",
  "fields": [
    { "name": "data", "type": "bytes" }
  ]
}
```
  Este es el esquema Avro de los mensajes de salida con la opción Escribir metadatos habilitada:
```
{
  "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 esquema de tema: esta opción permite que Pub/Sub use el esquema del tema de Pub/Sub al que está vinculada la suscripción al escribir archivos Avro.
  
  Si utilizas esta opción, recuerda que debes cumplir los siguientes requisitos adicionales:
  - El esquema del tema debe estar en formato Apache Avro.
  - Si las opciones Usar esquema de tema y Escribir metadatos están habilitadas, el esquema de tema debe tener un objeto Record en su raíz. Pub/Sub ampliará la lista de campos de Record para incluir los campos de metadatos. Por lo tanto, 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).

Cuenta de servicio

Tienes las siguientes opciones para escribir mensajes en una tabla de BigQuery o en un segmento de Cloud Storage:

Configura una cuenta de servicio personalizada para que solo los usuarios que tengan el permiso iam.serviceAccounts.actAs en la cuenta de servicio puedan crear una suscripción que escriba en la tabla o el segmento. Un ejemplo de rol que incluye el permiso iam.serviceAccounts.actAs es el rol Usuario de cuenta de servicio (roles/iam.serviceAccountUser).
Usa el agente de servicio de Pub/Sub predeterminado, que permite a cualquier usuario con la capacidad de crear suscripciones en el proyecto crear una suscripción que escriba en la tabla o el segmento. El agente de servicio de Pub/Sub es el ajuste predeterminado cuando no se especifica una cuenta de servicio personalizada.