Propriedades da 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.

Neste documento, descrevemos as diferentes propriedades que podem ser definidas para uma assinatura.

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 assinaturas

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 serão abordadas nas próximas seções.

Duração da retenção da mensagem

A opção Duração da retenção de mensagem 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. Para reter mensagens confirmadas durante a retenção da mensagem, consulte Como repetir e descartar mensagens.

Veja 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 = 7 dias

Observação: a partir de 30 de junho de 2024, você vai receber cobranças pela retenção de mensagens não confirmadas com assinaturas por mais de 24 horas.

Mensagens não confirmadas podem resultar de assinaturas inativas, necessidades de backup ou processamento lento. Se você processar as mensagens em até 24 horas, não haverá cobranças extras. Para evitar novas cobranças, gerencie essas situações 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 retenção de assinatura como armazenamento de backup, poderá mudar para outra opção de armazenamento, como a retenção de mensagens de tópico ou reter mensagens confirmadas. A retenção de mensagens de tópicos armazena mensagens apenas uma vez no nível do tópico e elas permanecem disponíveis para que todas as assinaturas consumam 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á definir se quer reter as mensagens confirmadas.

A opção Reter mensagens confirmadas permite reter mensagens confirmadas pelo período especificado de retenção de mensagens. Essa opção aumenta as taxas de armazenamento de mensagens. Para mais informações, consulte os 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 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 da 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 do que a duração da retenção de mensagens especificada na opção Duração da retenção de mensagens.

A seguir estão os valores da opção Período de expiração:

• 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 da confirmação

A opção Prazo de confirmação especifica o prazo inicial para que uma mensagem não confirmada seja enviada novamente. Você pode estender o prazo de confirmação por mensagem enviando solicitações ModifyAckDeadline subsequentes.

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 substituir esse comportamento, use minDurationPerAckExtension e maxDurationPerAckExtension. Para mais informações sobre como usar esses valores, consulte Suporte à entrega exatamente uma vez em 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 entrega apenas as mensagens que correspondem a ele. 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 da mensagem.

• Se não for especificada, a assinatura não vai filtrar as mensagens, e os assinantes vão receber todas elas.

• Os filtros não podem ser alterados nem removidos depois da aplicação.

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.

Saiba mais em Filtrar mensagens de uma assinatura.

Ordenação das mensagens

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

Ao usar a entrega ordenada, as confirmações de mensagens posteriores não são processadas até que as confirmações de mensagens anteriores sejam processadas.

Os editores precisam enviar mensagens com uma chave de ordem para que o Pub/Sub possa entregá-las em ordem.

Se ela não for definida, o Pub/Sub poderá não entregar mensagens em ordem, mesmo que tenha uma chave de ordem.

Tópico de mensagens inativas

Quando não é possível entregar uma mensagem após um número definido de tentativas de entrega ou quando um assinante não a confirma, é possível configurar um tópico de mensagens inativas em que essas mensagens podem ser publicadas novamente.

Se você definir um tópico de mensagem inativa, também será possível especificar o número máximo de tentativas de entrega. Veja 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, especifique também 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 a Política de nova tentativa da assinatura.

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

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

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

• Se você definir o valor máximo para a duração de 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 de espera, o valor padrão para a duração máxima de espera será de 600 segundos.

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

Política de nova tentativa 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 repetição e assinatura de 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 da assinatura de pull

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

Entrega "exatamente uma vez"

Entrega exatamente uma vez. Se definido, o Pub/Sub cumpre garantias de entrega exatamente uma vez. Se não for especificada, a assinatura será compatível com a entrega pelo menos uma vez para cada mensagem.

Propriedades da assinatura de push

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

Endpoints

URL do endpoint (obrigatório). Um endereço HTTPS de acesso público. 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 push. Caso seu domínio receba solicitações POST inesperadas do Pub/Sub, denuncie a suspeita de abuso.

Autenticação

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

A configuração de autenticação para uma assinatura de push autenticada consiste em uma conta serviço gerenciado pelo usuário e os parâmetros de público 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ório). A conta de serviço associada à assinatura de push. Essa conta é usada como a declaração email do JSON Web Token (JWT) gerado. Esta é uma lista de requisitos para a conta de serviço:

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

  • O principal que está criando ou modificando a assinatura de 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. Uma única string que não diferencia maiúsculas de minúsculas que o webhook usa para validar o público-alvo desse token específico.

• 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 as mensagens do Pub/Sub de todos os metadados delas, exceto os dados da mensagem. Com o desencapsulamento de payload, os dados da mensagem são entregues diretamente como o corpo HTTP.

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

Propriedades do BigQuery

Ao selecionar 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 a que a assinatura está anexada. Além disso, o Pub/Sub grava os campos em mensagens nas colunas correspondentes na tabela do BigQuery.

Cuidado: a exclusão ou a revisão de um esquema é permanente. As mensagens 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 a opção Usar esquema de tópicos ativada. Em vez de excluir um esquema ou uma revisão, considere reverter um esquema.

Ao usar essa opção, lembre-se de verificar os seguintes requisitos adicionais:

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

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

• Os campos obrigatórios no esquema de tópicos 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 precisarão estar no modo NULLABLE.

• Se o esquema do tópico tiver outros campos que não estejam presentes no esquema do BigQuery e for possível descartá-los, selecione a opção Descartar campos desconhecidos.

• É possível selecionar apenas uma das propriedades de assinatura: Usar esquema de tópicos 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 do tipo BYTES, STRING ou JSON. O Pub/Sub grava a mensagem nessa coluna do BigQuery.

É possível que as alterações no esquema de tópicos do Pub/Sub ou no esquema da tabela do BigQuery não entrem em vigor imediatamente com mensagens gravadas na tabela do BigQuery. Por exemplo, se a opção Descartar campos desconhecidos estiver ativada e houver um campo presente no esquema do Pub/Sub, 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, os esquemas serão sincronizados, e as mensagens subsequentes incluirão o campo.

Ao usar a opção Usar esquema de tópicos para sua assinatura do BigQuery, você também pode aproveitar a captura de dados alterados (CDC) do BigQuery. O CDC atualiza as tabelas do BigQuery processando e aplicando alterações às linhas atuais.

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

Para saber como usar esse recurso com assinaturas do BigQuery, consulte Captura de dados alterados 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, lembre-se de verificar os seguintes requisitos extras:

• As mensagens publicadas precisam estar no formato JSON.

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

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

• Se as mensagens tiverem outros campos que não estejam presentes no esquema do BigQuery e for possível descartá-los, selecione a opção Descartar campos desconhecidos.

• Na mensagem JSON, os valores DATE, DATETIME, TIME e TIMESTAMP precisam ser números inteiros que aderem às representações compatíveis.

• Na mensagem JSON, os valores NUMERIC e BIGNUMERIC precisam ser bytes codificados usando o BigDecimalByteStringEncoder.

• É possível selecionar apenas uma das propriedades de assinatura: Usar esquema de tópicos 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 do tipo BYTES, STRING ou JSON. O Pub/Sub grava a mensagem nessa coluna do BigQuery.

É possível que as alterações no esquema da tabela do BigQuery não entrem em vigor imediatamente com as mensagens gravadas nela. Por exemplo, se a opção Descartar campos desconhecidos estiver ativada e um campo estiver presente nas mensagens, mas não no esquema do BigQuery, as mensagens gravadas na tabela do BigQuery talvez ainda não contenham o campo depois de adicioná-lo ao esquema do BigQuery. Eventualmente, o esquema será sincronizado, e as mensagens subsequentes incluirão o campo.

Ao usar a opção Usar esquema de tabela para sua assinatura do BigQuery, também é possível aproveitar a captura de dados alterados (CDC) do BigQuery. O CDC atualiza as tabelas do BigQuery processando e aplicando alterações às linhas atuais.

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

Para saber como usar esse recurso com assinaturas do BigQuery, consulte Captura de dados alterados do BigQuery.

Remover campos desconhecidos

Essa opção é usada com as opções Usar esquema de tópicos ou Usar esquema de tabela. Essa opção permite que o Pub/Sub remova qualquer campo que esteja presente no esquema ou na mensagem do tópico, mas não no esquema do BigQuery. Sem a opção Descartar campos desconhecidos definida, as mensagens com campos extras não serão gravadas no BigQuery e permanecerão no backlog das assinaturas. A assinatura termina 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 exigirá apenas 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 nenhum campo com nomes correspondentes aos dos parâmetros de metadados. Essa limitação inclui versões camelcase desses parâmetros de snake case.

Parâmetros
subscription_name	STRING Nome de uma assinatura.
message_id	STRING ID de uma mensagem
publish_time	TIMESTAMP O horário da 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 precisará ser um JSON válido.
attributes	STRING ou JSON Um objeto JSON que contém todos os atributos de mensagem. Ele também contém outros campos que fazem parte da mensagem do Pub/Sub, incluindo a chave de ordem, se houver.

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 da criação de uma assinatura do Cloud Storage.

As mensagens são enviadas como 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 a opção Pagamentos do solicitante desativada.

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

Prefixo, sufixo e data/hora do nome de 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 do arquivo e os campos que podem ser personalizados:

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

• <UTC-date-time> é uma string personalizável gerada automaticamente com base no horário de criação do objeto.

• <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 alterar o prefixo e o sufixo do nome de arquivo:

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

  • Se você não especificar o prefixo e o sufixo do nome de 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.

• Você pode alterar como a data e a hora são exibidas no nome do arquivo:

  • Correspondências de data e hora obrigatórias que podem ser usadas apenas uma vez: ano (YYYY ou YY), mês (MM), dia (DD), hora (hh), minuto (mm), segundo (ss). Por exemplo, YY-YYYY ou MMM é inválido.

  • Correspondências opcionais que podem ser usadas apenas uma vez: separador de data e hora (T) e compensação 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 amostra será prod_2023-09-25/04_10_00Z_uNiQuE_archive.

  • Se o formato de data e hora do nome do arquivo terminar em um caractere que não é um correspondente, esse caractere 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 amostra será prod_2023-09-25T04_10_00-uNiQuE_archive.

Lote de arquivos

As assinaturas do Cloud Storage permitem decidir quando 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. Estas são as condições de lote do Cloud Storage:

• Duração máxima do lote de armazenamento. Essa configuração é obrigatória. A assinatura do Cloud Storage gravará um novo arquivo de saída se o valor especificado da duração máxima for excedido. Se você não especificar o valor, o valor padrão de 5 minutos será aplicado. Veja 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 gravará um novo arquivo de saída se o valor especificado do máximo de bytes for excedido. Veja a seguir os valores aplicáveis para o máximo de bytes:

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

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

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 6 minutos, poderá observar 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 loteamento de arquivos. Um arquivo também poderá exceder o valor máximo de bytes se a assinatura receber mensagens maiores que esse valor.

Formato do arquivo

Ao criar uma assinatura do Cloud Storage, especifique o formato dos arquivos de saída que serão armazenados em um bucket do Cloud Storage como Text ou Avro.

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

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

  • Gravar metadados: permite armazenar os metadados da mensagem com a mensagem. 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 da 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. Este é o esquema 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" }
      ]
    }
    

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

    Ao usar essa opção, lembre-se de verificar os seguintes requisitos adicionais:

    • O esquema do tópico precisa estar no formato Apache Avro (link em inglês).

    • Se usar esquema de tópicos e gravar metadados estiverem ativados, o esquema de tópicos 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 nenhum campo com o mesmo nome que os 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.