Propriedades de assinatura

As propriedades de assinatura do Pub/Sub são as características de uma assinatura. Você pode definir as propriedades da assinatura ao criar ou atualizar uma assinatura.

Este documento descreve as diferentes propriedades de assinatura que podem ser definidas.

Antes de começar

• Saiba mais sobre assinaturas.

• Entenda o fluxo de trabalho da assinatura que você vai criar: pull, push ou BigQuery.

Propriedades comuns de assinatura

Ao criar uma assinatura, você precisa especificar várias opções para configurá-la. Algumas dessas propriedades são comuns a todos os tipos de assinaturas e são discutidas nas próximas seções.

Duração da retenção da mensagem

A opção Duração da retenção de mensagens especifica por quanto tempo o Pub/Sub retém as mensagens após a publicação. Após a duração da retenção da mensagem, o Pub/Sub pode descartar a mensagem independente do estado de confirmação dela. Para reter mensagens confirmadas durante a duração da retenção de mensagens, consulte Como reproduzir e descartar mensagens.

Confira a seguir os valores da opção Duração da retenção de mensagens:

• Valor padrão = 7 dias
• Valor mínimo = 10 minutos
• Valor máximo = 31 dias

Observação: se você reter mensagens não confirmadas em uma assinatura por mais de 24 horas, vai receber cobranças adicionais. Para mais informações, consulte Custos de armazenamento.

As mensagens não confirmadas podem resultar de assinaturas inativas, necessidades de backup ou processamento lento. Se você conseguir processar as mensagens em até 24 horas, as cobranças adicionais não serão geradas. Para evitar novas cobranças, gerencie estes cenários da seguinte forma:

• Assinaturas inativas. Exclua assinaturas inativas para evitar cobranças de retenção de mensagens de assinatura.

• Armazenamento de backup. Se você estiver usando a retenção de assinatura como armazenamento de backup, mude para outra opção de armazenamento, como a retenção de mensagens de tópicos ou a retenção de mensagens confirmadas. A retenção de mensagens de tópico armazena mensagens apenas uma vez no nível do tópico, e elas permanecem disponíveis para todas as assinaturas consumirem quando necessário.

• Atrasos no processamento. Adicione mais assinantes (se possível) para processar as mensagens em um dia.

Reter mensagens reconhecidas

Se você especificar a Duração da retenção de mensagens, também poderá especificar se quer reter as mensagens confirmadas.

A opção Reter mensagens confirmadas permite reter mensagens confirmadas pelo período de retenção especificado. Essa opção aumenta as taxas de armazenamento de mensagens. Para mais informações, consulte custos de armazenamento.

Período de expiração

A opção Período de validade permite estender o período de validade da assinatura.

As assinaturas sem atividade do assinante ou mudanças feitas nas propriedades da assinatura expiram. Se o Pub/Sub detectar atividade do assinante ou se você atualizar qualquer uma das propriedades da assinatura, o relógio de exclusão de assinatura será reiniciado. Exemplos de atividades do assinante incluem conexões abertas, pulls ativos ou pushes bem-sucedidos.

Se você especificar o período de expiração, o valor precisará ser maior que a duração da retenção de mensagens especificada na opção Duração da retenção de mensagens.

Confira a seguir os valores da opção Período de validade:

• Valor padrão = 31 dias
• Valor mínimo = 1 dia

Para evitar que uma assinatura expire, defina o período de expiração como never expire.

Prazo de confirmação

A opção Prazo de confirmação especifica o prazo inicial após o qual uma mensagem não confirmada é enviada novamente. É possível estender o prazo de confirmação por mensagem enviando solicitações ModifyAckDeadline posteriores.

Confira a seguir os valores da opção Prazo de confirmação:

• Valor padrão = 10 segundos
• Valor mínimo = 10 segundos
• Valor máximo = 600 segundos

Em alguns casos, as bibliotecas de cliente do Pub/Sub podem controlar a taxa de entrega e modificar dinamicamente o prazo de confirmação. Ao fazer isso, a mensagem pode ser entregue novamente antes do prazo de confirmação definido. Para modificar esse comportamento, use minDurationPerAckExtension e maxDurationPerAckExtension. Para mais informações sobre o uso desses valores, consulte Suporte ao envio exatamente uma vez nas bibliotecas de cliente.

Filtro de assinatura

Use a opção Filtro de assinatura para especificar uma string com uma expressão de filtragem. Se uma assinatura tiver um filtro, ela só vai entregar as mensagens que correspondem ao filtro. O serviço Pub/Sub reconhece automaticamente as mensagens que não correspondem ao filtro.

• É possível filtrar mensagens pelos atributos, mas não pelos dados delas.

• Se não for especificada, a assinatura não filtrará as mensagens, e os inscritos vão receber todas as mensagens.

• Não é possível mudar ou remover os filtros depois de aplicá-los.

Quando você recebe mensagens de uma assinatura com um filtro, não há taxas de saída para as mensagens que o Pub/Sub confirma automaticamente. Sujeito a taxas de entrega de mensagens e taxas de armazenamento relacionadas à busca para essas mensagens.

Para mais informações, consulte Filtrar mensagens de uma assinatura.

Ordenação das mensagens

Quando a Ordem de mensagens de uma assinatura está ativada, os clientes assinantes recebem mensagens publicadas na mesma região com a mesma chave de ordenação na ordem em que as mensagens foram recebidas pelo serviço.

Ao usar a entrega ordenada, os avisos de confirmação de mensagens posteriores não são processados até que os avisos de mensagens anteriores sejam processados.

Os editores precisam enviar mensagens com uma chave de ordenação para que o Pub/Sub possa entregar as mensagens na ordem.

Se não for definido, o Pub/Sub pode não entregar as mensagens em ordem, mesmo que elas tenham uma chave de ordenação.

Tópico de mensagens inativas

Quando uma mensagem não pode ser entregue após um número definido de tentativas de entrega ou um assinante não pode confirmar a mensagem, é possível configurar um tópico de mensagens inativas para que essas mensagens sejam republicadas.

Se você definir um tópico de mensagem inativa, também será possível especificar o número máximo de tentativas de entrega. Confira a seguir os valores do número máximo de tentativas de entrega para o tópico de mensagens inativas:

• Valor padrão = 5 tentativas de entrega
• Valor mínimo = 5 tentativas de entrega
• Valor máximo = 100 tentativas de entrega

Se o tópico de mensagens inativas estiver em um projeto diferente da assinatura, também será necessário especificar o ID do projeto com o tópico de mensagens inativas.

Para mais informações, consulte Como encaminhar para tópicos de mensagens inativas.

Política de repetição

Se o prazo de confirmação expirar ou um assinante responder com uma confirmação negativa, o Pub/Sub poderá enviar a mensagem novamente. Essa tentativa de reenvio é conhecida como política de nova tentativa da assinatura.

Por padrão, a política de nova tentativa para uma assinatura é definida para Tentar de novo imediatamente. Com essa opção, o Pub/Sub reenvia a mensagem quando o prazo de confirmação expira ou um assinante responde com uma confirmação negativa.

Também é possível definir o valor como Repetir após atraso de espera exponencial. Nesse caso, é necessário especificar os valores de espera máximos e mínimos.

Confira algumas diretrizes para definir os valores de espera máxima e mínima:

• Se você definir o valor máximo para a duração da espera, o valor padrão para a duração mínima de espera será de 10 segundos.

• Se você definir o valor mínimo para a duração da espera, o valor padrão para a duração máxima da espera será de 600 segundos.

• A duração de espera mais longa que você pode especificar é de 600 segundos.

Política de repetição e mensagens em lote

Se as mensagens estiverem em lote, o Pub/Sub iniciará a espera exponencial quando uma das seguintes situações ocorrer:

• O assinante envia uma confirmação negativa para cada mensagem no lote.

• O prazo de confirmação expira.

Política de nova tentativa e assinatura push

Se você receber mensagens de uma assinatura de push, o Pub/Sub pode reenviá-las após a espera em push em vez da duração da espera exponencial. Quando a espera em push é mais longa do que a duração da espera exponencial, o Pub/Sub reenvia mensagens não confirmadas após a espera em push.

Observação: quando você modifica a duração da retenção de mensagens ou a política de expiração da assinatura, o período de expiração precisa ser um valor maior que a duração da retenção de mensagens. A duração padrão da retenção de mensagens é de 7 dias, e o período de expiração padrão é de 31 dias.

Propriedades de assinatura de pull

Ao configurar uma assinatura de pull, é possível especificar as seguintes propriedades.

Entrega exatamente uma vez

Entrega exatamente uma vez. Se definido, o Pub/Sub cumpre as garantias de envio exatamente uma vez. Se não for especificado, a assinatura vai oferecer suporte ao envio pelo menos uma vez para cada mensagem.

Propriedades de assinatura por push

Ao configurar uma assinatura de push, é possível especificar as seguintes propriedades.

Endpoints

URL do endpoint (obrigatório). Um endereço HTTPS acessível publicamente. O servidor do endpoint de push precisa ter um certificado SSL válido assinado por uma autoridade de certificação. O serviço do Pub/Sub entrega mensagens para enviar endpoints da mesma região do Google Cloud em que o serviço do Pub/Sub armazena as mensagens. O serviço Pub/Sub entrega mensagens da mesma região do Google Cloud com base no melhor esforço.

O Pub/Sub não exige mais prova de propriedade para domínios de URL de assinatura por push. Se o domínio receber solicitações POST inesperadas do Pub/Sub, relate suspeita de abuso.

Autenticação

Ative a autenticação. Quando ativada, as mensagens enviadas pelo Pub/Sub para o endpoint de push incluem um cabeçalho de autorização para permitir que o endpoint autentique a solicitação. Os mecanismos de autenticação e autorização automáticos estão disponíveis para os endpoints do Cloud Run Functions e do ambiente padrão do App Engine hospedados no mesmo projeto da assinatura.

A configuração de autenticação de uma assinatura de push autenticada consiste em uma conta de serviço gerenciado pelo usuário e os parâmetros de público-alvo que são especificados em uma chamada create, patch ou ModifyPushConfig. Você também precisa conceder um papel específico a um agente de serviço, conforme discutido na próxima seção.

• Conta de serviço gerenciado pelo usuário (obrigatória). A conta de serviço associada à assinatura de push. Essa conta é usada como a declaração email do JSON Web Token (JWT) gerado. Confira a seguir uma lista de requisitos para a conta de serviço:

  • Essa conta de serviço precisa estar no mesmo projeto que a assinatura push.

  • O principal que está criando ou modificando a assinatura push precisa ter a permissão iam.serviceAccounts.actAs na conta de serviço. É possível conceder um papel com essa permissão no projeto, na pasta ou na organização para permitir que o autor da chamada represente várias contas de serviço ou conceder um papel com essa permissão na conta de serviço para permitir que o autor da chamada represente apenas essa conta de serviço.

• Público-alvo. Uma única string, indiferente a maiúsculas, que o webhook usa para validar o público-alvo desse token.

• Agente de serviço (obrigatório).

  • O Pub/Sub cria automaticamente uma conta de serviço para você com o formato service-{PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com.

  • Esse agente de serviço precisa receber a permissão iam.serviceAccounts.getOpenIdToken (incluída no papel roles/iam.serviceAccountTokenCreator) para permitir que o Pub/Sub crie tokens JWT para solicitações de push autenticadas.

Desencapsulamento de payload

A opção Ativar desencapsulamento de payload remove todos os metadados das mensagens do Pub/Sub, exceto os dados da mensagem. Com a abertura de payload, os dados da mensagem são entregues diretamente como o corpo HTTP.

• Gravar metadados. Adiciona os metadados removidos das mensagens de volta ao cabeçalho da solicitação.

Propriedades do BigQuery

Quando você seleciona um tipo de entrega de assinatura como Gravar no BigQuery, é possível especificar as propriedades adicionais a seguir.

Usar esquema de tópicos

Essa opção permite que o Pub/Sub use o esquema do tópico do Pub/Sub ao qual a assinatura está anexada. Além disso, o Pub/Sub grava os campos em mensagens nas colunas correspondentes da tabela do BigQuery.

Cuidado: a exclusão de um esquema ou de uma revisão de esquema é permanente. As mensagens que foram validadas em relação a uma revisão de esquema excluída no momento da publicação não podem ser gravadas no BigQuery usando uma assinatura do BigQuery com Usar esquema de tópicos ativado. Em vez de excluir um esquema ou uma revisão, considere reverter um esquema.

Ao usar essa opção, verifique os seguintes requisitos:

• Os campos no esquema do tópico e no BigQuery precisam ter os mesmos nomes, e os tipos precisam ser compatíveis entre si.

• Qualquer campo opcional no esquema do tópico também precisa ser opcional no esquema do BigQuery.

• Os campos obrigatórios no esquema do tópico não precisam ser obrigatórios no esquema do BigQuery.

• Se houver campos do BigQuery que não estão presentes no esquema do tópico, eles precisam estar no modo NULLABLE.

• Se o esquema do tópico tiver campos adicionais que não estão presentes no esquema do BigQuery e que podem ser descartados, selecione a opção Drop unknown fields.

• Você pode selecionar apenas uma das propriedades de assinatura, Usar esquema de tópico ou Usar esquema de tabela.

Se você não selecionar a opção Usar esquema de tópicos ou Usar esquema de tabela, verifique se a tabela do BigQuery tem uma coluna chamada data de tipo BYTES, STRING ou JSON. O Pub/Sub grava a mensagem nessa coluna do BigQuery.

Talvez as mudanças no esquema de tópicos do Pub/Sub ou no esquema de tabela do BigQuery não entrem em vigor imediatamente com as mensagens gravadas na tabela do BigQuery. Por exemplo, se a opção Drop unknown fields estiver ativada e um campo estiver presente no esquema do Pub/Sub, mas não no BigQuery, as mensagens gravadas na tabela do BigQuery ainda poderão não conter o campo depois de adicioná-lo ao esquema do BigQuery. Eventualmente, os esquemas são sincronizados e as mensagens seguintes incluem o campo.

Ao usar a opção Usar esquema de tópico na sua assinatura do BigQuery, você também pode aproveitar a captura de dados de mudança (CDC) do BigQuery. A CDC atualiza as tabelas do BigQuery processando e aplicando as mudanças às linhas atuais.

Para saber mais sobre esse recurso, consulte Fazer streaming de atualizações da tabela com captura de dados alterados.

Para saber como usar esse recurso com as assinaturas do BigQuery, consulte Captura de dados de alterações do BigQuery.

Usar esquema de tabela

Essa opção permite que o Pub/Sub use o esquema da tabela do BigQuery para gravar os campos de uma mensagem JSON nas colunas correspondentes. Ao usar essa opção, verifique os seguintes requisitos adicionais:

• As mensagens publicadas precisam estar no formato JSON.

• As seguintes conversões JSON são compatíveis:

  Tipo de JSON	Tipo de dados do BigQuery
  string	NUMERIC, BIGNUMERIC, DATE, TIME, DATETIME ou TIMESTAMP
  number	NUMERIC, BIGNUMERIC, DATE, TIME, DATETIME ou TIMESTAMP

  • Ao usar number para conversões DATE, DATETIME, TIME ou TIMESTAMP, o número precisa obedecer às representações compatíveis.
  • Ao usar a conversão de number para NUMERIC ou BIGNUMERIC, a precisão e o intervalo de valores são limitados aos aceitos pelo padrão IEEE 754 para aritmética de ponto flutuante. Se você precisar de alta precisão ou um intervalo maior de valores, use as conversões de string para NUMERIC ou BIGNUMERIC.
  • Ao usar conversões de string para NUMERIC ou BIGNUMERIC, o Pub/Sub presume que a string é um número legível por humanos (por exemplo, "123.124"). Se o processamento da string como um número legível por humanos falhar, o Pub/Sub vai tratar a string como bytes codificados com o BigDecimalByteStringEncoder.

• Se o tópico da assinatura tiver um esquema associado, a propriedade de codificação da mensagem precisará ser definida como JSON.

• Se houver campos do BigQuery que não estão presentes nas mensagens, eles precisam estar no modo NULLABLE.

• Se as mensagens tiverem campos adicionais que não estão presentes no esquema do BigQuery e esses campos puderem ser descartados, selecione a opção Drop unknown fields.

• Você pode selecionar apenas uma das propriedades de assinatura, Usar esquema de tópico ou Usar esquema de tabela.

Se você não selecionar a opção Usar esquema de tópicos ou Usar esquema de tabela, verifique se a tabela do BigQuery tem uma coluna chamada data de tipo BYTES, STRING ou JSON. O Pub/Sub grava a mensagem nessa coluna do BigQuery.

Talvez as mudanças no esquema da tabela do BigQuery não entrem em vigor imediatamente com as mensagens gravadas na tabela do BigQuery. Por exemplo, se a opção Drop unknown fields estiver ativada e um campo estiver presente nas mensagens, mas não no esquema do BigQuery, as mensagens gravadas na tabela do BigQuery ainda poderão não conter o campo depois de adicioná-lo ao esquema do BigQuery. Eventualmente, o esquema é sincronizado e as mensagens seguintes incluem o campo.

Ao usar a opção Usar esquema de tabela na sua assinatura do BigQuery, você também pode aproveitar a captura de dados alterados (CDC) do BigQuery. A CDC atualiza as tabelas do BigQuery processando e aplicando mudanças às linhas existentes.

Para saber mais sobre esse recurso, consulte Fazer streaming de atualizações da tabela com captura de dados alterados.

Para saber como usar esse recurso com as assinaturas do BigQuery, consulte Captura de dados de alterações do BigQuery.

Remover campos desconhecidos

Essa opção é usada com a opção Usar esquema de tópicos ou Usar esquema de tabela. Essa opção permite que o Pub/Sub exclua qualquer campo presente no esquema do tópico ou da mensagem, mas não no esquema do BigQuery. Sem a opção Drop unknown fields definida, as mensagens com campos extras não são gravadas no BigQuery e permanecem no backlog de assinatura. A assinatura acaba em um estado de erro.

Gravar metadados

Essa opção permite que o Pub/Sub grave os metadados de cada mensagem em outras colunas na tabela do BigQuery. Caso contrário, os metadados não serão gravados na tabela do BigQuery.

Se você selecionar a opção Gravar metadados, verifique se a tabela do BigQuery tem os campos descritos na tabela a seguir.

Se você não selecionar a opção Gravar metadados, a tabela de destino do BigQuery só vai exigir o campo data, a menos que use_topic_schema seja verdadeiro. Se você selecionar as opções Gravar metadados e Usar esquema de tópicos, o esquema do tópico não poderá conter campos com nomes que correspondam aos dos parâmetros de metadados. Essa limitação inclui versões em CamelCase desses parâmetros de caixa baixa.

Parâmetros
subscription_name	STRING Nome de uma assinatura.
message_id	STRING ID de uma mensagem
publish_time	TIMESTAMP O horário de publicação de uma mensagem.
data	BYTES, STRING ou JSON O corpo da mensagem. O campo data é obrigatório para todas as tabelas de destino do BigQuery que não selecionam Usar esquema de tópicos ou Usar esquema de tabela. Se o campo for do tipo JSON, o corpo da mensagem precisa ser um JSON válido.
attributes	STRING ou JSON Um objeto JSON que contém todos os atributos da mensagem. Ele também contém outros campos que fazem parte da mensagem do Pub/Sub, incluindo a chave de ordenação, se presente.

Propriedades do Cloud Storage

Ao selecionar um tipo de entrega de assinatura como Gravar no Cloud Storage, é possível especificar as propriedades adicionais a seguir.

Nome do bucket

Um bucket do Cloud Storage precisa existir antes de você criar uma assinatura do Cloud Storage.

As mensagens são enviadas em lotes e armazenadas no bucket do Cloud Storage. Um único lote ou arquivo é armazenado como um objeto no bucket.

O bucket do Cloud Storage precisa ter o recurso Pagamento do solicitante desativado.

Para criar um bucket do Cloud Storage, consulte Criar buckets.

Prefixo, sufixo e data/hora do nome do arquivo

Os arquivos de saída do Cloud Storage gerados pela assinatura do Cloud Storage são armazenados como objetos no bucket do Cloud Storage. O nome do objeto armazenado no bucket do Cloud Storage tem o seguinte formato: <file-prefix><UTC-date-time>_<uuid><file-suffix>.

A lista a seguir inclui detalhes do formato de arquivo e os campos que podem ser personalizados:

• <file-prefix> é o prefixo do nome de arquivo personalizado. Esse campo é opcional.

• <UTC-date-time> é uma string gerada automaticamente e personalizável com base no momento em que o objeto é criado.

• <uuid> é uma string aleatória gerada automaticamente para o objeto.

• <file-suffix> é o sufixo do nome de arquivo personalizado. Esse campo é opcional. O sufixo do nome do arquivo não pode terminar em "/".

• É possível mudar o prefixo e o sufixo do nome do arquivo:

  • Por exemplo, se o valor do prefixo do nome do arquivo for prod_ e o valor do sufixo do nome do arquivo for _archive, um exemplo de nome de objeto será prod_2023-09-25T04:10:00+00:00_uN1QuE_archive.

  • Se você não especificar o prefixo e o sufixo do nome do arquivo, o nome do objeto armazenado no bucket do Cloud Storage terá o formato: <UTC-date-time>_<uuid>.

  • Os requisitos de nomenclatura de objetos do Cloud Storage também se aplicam ao prefixo e ao sufixo do nome do arquivo. Para mais informações, consulte Sobre os objetos do Cloud Storage.

• É possível mudar a forma como a data e a hora aparecem no nome do arquivo:

  • Os comparadores de data/hora obrigatórios que podem ser usados apenas uma vez: ano (YYYY ou YY), mês (MM), dia (DD), hora (hh), minuto (mm) e segundo (ss). Por exemplo, YY-YYYY ou MMM são inválidos.

  • Combinadores opcionais que podem ser usados apenas uma vez: separador de data e hora (T) e deslocamento de fuso horário (Z ou +00:00).

  • Elementos opcionais que podem ser usados várias vezes: hífen (-), sublinhado (_), dois-pontos (:) e barra (/).

  • Por exemplo, se o valor do formato de data e hora do nome do arquivo for YYYY-MM-DD/hh_mm_ssZ, um nome de objeto de exemplo será prod_2023-09-25/04_10_00Z_uNiQuE_archive.

  • Se o formato de data e hora do nome do arquivo terminar com um caractere que não é um correspondente, esse caractere vai substituir o separador entre <UTC-date-time> e <uuid>. Por exemplo, se o valor do formato de data e hora do nome do arquivo for YYYY-MM-DDThh_mm_ss-, um nome de objeto de exemplo será prod_2023-09-25T04_10_00-uNiQuE_archive.

Lote de arquivos

Com as assinaturas do Cloud Storage, você decide quando quer criar um novo arquivo de saída armazenado como um objeto no bucket do Cloud Storage. O Pub/Sub grava um arquivo de saída quando uma das condições de lote especificadas é atendida. Confira a seguir as condições de lote do Cloud Storage:

• Duração máxima do lote de armazenamento. Essa é uma configuração obrigatória. A assinatura do Cloud Storage grava um novo arquivo de saída se o valor especificado de duração máxima for excedido. Se você não especificar o valor, um valor padrão de 5 minutos será aplicado. Confira a seguir os valores aplicáveis para a duração máxima:

  • Valor mínimo = 1 minuto
  • Valor padrão = 5 minutos
  • Valor máximo = 10 minutos

• Bytes máximos de lote de armazenamento. Essa configuração é opcional. A assinatura do Cloud Storage grava um novo arquivo de saída se o valor especificado de bytes máximos for excedido. Confira a seguir os valores aplicáveis para bytes máximos:

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

• Mensagens máximas de lote de armazenamento. Essa configuração é opcional. A assinatura do Cloud Storage grava um novo arquivo de saída se o número especificado de mensagens máximas for excedido. Confira a seguir os valores aplicáveis para mensagens máximas:

  • Valor mínimo = 1.000

Por exemplo, é possível configurar a duração máxima como 6 minutos e os bytes máximos como 2 GB. Se, no quarto minuto, o arquivo de saída atingir um tamanho de 2 GB, o Pub/Sub vai finalizar o arquivo anterior e começar a gravar em um novo arquivo.

Uma assinatura do Cloud Storage pode gravar em vários arquivos em um bucket do Cloud Storage simultaneamente. Se você configurou sua assinatura para criar um novo arquivo a cada seis minutos, talvez observe vários arquivos do Cloud Storage sendo criados a cada seis minutos.

Em algumas situações, o Pub/Sub pode começar a gravar em um novo arquivo antes do tempo configurado pelas condições de agrupamento de arquivos. Um arquivo também pode exceder o valor de bytes máximo se a assinatura receber mensagens maiores que o valor de bytes máximo.

Formato do arquivo

Ao criar uma assinatura do Cloud Storage, você pode especificar o formato dos arquivos de saída que serão armazenados em um bucket do Cloud Storage como Texto ou Avro.

• Texto: as mensagens são armazenadas como texto simples. Um caractere de nova linha separa uma mensagem da anterior no arquivo. Somente os payloads de mensagens são armazenados, não atributos ou outros metadados.

• Avro: as mensagens são armazenadas no formato binário do Apache Avro. Ao selecionar Avro, você pode ativar as seguintes propriedades:

  • Gravar metadados: essa opção permite armazenar os metadados da mensagem junto com ela. Metadados como os campos subscription_name, message_id, publish_time e attributes são gravados em campos de nível superior no objeto Avro de saída, enquanto todas as outras propriedades de mensagem, exceto dados (por exemplo, uma chave de ordenação, se presente) são adicionadas como entradas no mapa attributes.

    Se a opção write metadata estiver desativada, apenas o payload da mensagem será gravado no objeto Avro de saída. Confira o esquema do Avro para as mensagens de saída com metadados de gravação desativados:

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

    Confira o esquema do Avro para as mensagens de saída com metadados de gravação ativados:

    {
      "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 o esquema do tópico: essa opção permite que o Pub/Sub use o esquema do tópico do Pub/Sub ao qual a assinatura está anexada ao gravar arquivos Avro.

    Ao usar essa opção, verifique os seguintes requisitos adicionais:

    • O esquema do tópico precisa estar no formato Apache Avro.

    • Se a opção Usar esquema de tópico e Gravar metadados estiverem ativadas, o esquema de tópico precisará ter um objeto Record na raiz. O Pub/Sub vai expandir a lista de campos do registro para incluir os campos de metadados. Como resultado, o registro não pode conter campos com o mesmo nome dos campos de metadados (subscription_name, message_id, publish_time ou attributes).

A seguir

• Crie uma assinatura de pull.
• Crie uma assinatura de push.
• Crie uma assinatura do BigQuery.
• Crie uma assinatura do Cloud Storage.