Propriedades da assinatura

As propriedades da 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ê criará: Pull, Push ou BigQuery.

Propriedades de assinatura comuns

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 assinatura e serã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 o término da retenção de mensagens, o Pub/Sub pode descartar a mensagem independentemente do estado de confirmação dela. Para reter mensagens confirmadas durante o período da retenção, consulte Como reproduzir e descartar mensagens.

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

• 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 se reter 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 for possível processar as mensagens em até 24 horas, não haverá cobranças adicionais. Para evitar novas cobranças, gerencie estes cenários da seguinte maneira:

• 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 assinaturas como armazenamento de backup, poderá mudar para outra opção de armazenamento, como retenção de mensagens de tópicos ou de mensagens confirmadas. A retenção de mensagens de tópico armazena mensagens apenas uma vez no nível do tópico e permanecem disponíveis para todas as assinaturas consumirem quando necessário.

• Atrasos no processamento. Se possível, adicione mais assinantes para processar as mensagens em um dia.

Reter mensagens confirmadas

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 pela duração especificada da retenção de mensagens. 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.

Assinaturas sem qualquer atividade do assinante ou alterações feitas nas propriedades de inscrição 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 envios bem-sucedidos.

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

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

• Valor padrão = 31 dias
• Valor mínimo = 1 dia
• O valor máximo é 365 dias.

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

Prazo para a confirmação

A opção Prazo de confirmação especifica o prazo inicial para reenvio de uma mensagem não confirmada. É possível estender o prazo de confirmação por mensagem enviando solicitações ModifyAckDeadline subsequentes.

Confira a seguir os valores para a opção Confirmação Prazo:

• 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 só entregará as mensagens que correspondem a ele. O serviço Pub/Sub confirma automaticamente as mensagens que não correspondem ao filtro.

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

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

• Não é possível alterar nem 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 uma assinatura tem a ordenação de mensagens ativada, os clientes assinantes recebem mensagens publicadas na mesma região com a mesma chave de ordem na ordem em que as mensagens 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 das 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 não for definido, o Pub/Sub pode não entregar mensagens em ordem, mesmo que elas tenham uma chave de ordem.

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 consegue confirmá-la, é possível configurar um tópico de mensagens inativas em que essas mensagens podem ser 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. Veja a seguir os valores para o número máximo de tentativas de entrega do 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 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 repetição da assinatura.

Por padrão, a política de nova tentativa de uma assinatura é configurada para usar Tentar novamente 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 Tentar novamente após o atraso de espera exponencial. Nesse caso, você precisa especificar os valores máximo e mínimo de espera.

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

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

• Se você definir o valor mínimo para a duração de espera, o padrão para a duração máxima 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 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 única. Se definido, o Pub/Sub atende a garantias de entrega exatamente uma. Se não for especificada, a assinatura permitirá 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 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 de push. Se o domínio recebe solicitações POST inesperadas do Pub/Sub, é possível denunciar suspeita de abuso.

Proporção de Eficiência Energética (EER)

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

A configuração de autenticação de uma assinatura de push autenticada consiste em uma conta serviço gerenciado pelo usuário e nos parâmetros de público que são especificados em uma chamada create, patch ou ModifyPushConfig. Também é preciso conceder a uma conta de serviço especial gerenciada pelo Google um papel específico, 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. Esta 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-alvo. Uma única string indiferente a maiúsculas que o webhook usa para validar o público-alvo desse token específico.

• Conta de serviço gerenciado pelo Google (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.

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

• Gravar metadados. Adiciona novamente os metadados removidos das mensagens 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 ao qual 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 de um esquema ou uma revisão de esquema é permanente. As mensagens validadas em 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 seus tipos 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 do tópico não precisam ser obrigatórios no esquema do BigQuery.

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

• Se o esquema de tópicos tiver campos adicionais que não estão presentes no esquema do BigQuery e esses campos puderem ser descartados, 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.

Talvez você não veja as alterações no esquema de tópicos do Pub/Sub ou no esquema da tabela do BigQuery entrarem em vigor imediatamente com as mensagens gravadas na tabela do BigQuery. Por exemplo, se a opção Descartar campos desconhecidos estiver ativada e um campo estiver 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 após adicioná-lo ao esquema do BigQuery. Com o tempo, os esquemas são sincronizados e as mensagens subsequentes incluem o campo.

Quando você usa a opção Usar esquema de tópicos na assinatura do BigQuery, também pode aproveitar a captura de dados alterados (CDC) do BigQuery. O CDC atualiza suas tabelas do BigQuery processando e aplicando alterações às linhas existentes.

Para saber mais sobre esse recurso, consulte Atualizações da tabela de streaming 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 adicionais:

• As mensagens publicadas precisam estar no formato JSON.

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

• Se houver campos do BigQuery que não estejam presentes nas mensagens, eles precisarão 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 Descartar campos desconhecidos.

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

• Na mensagem JSON, os valores NUMERIC e BIGNUMERIC precisam ser codificados em bytes usando o BigDecimalByteStringEncoder (em inglês).

• É 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.

Talvez as alterações 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 Remover 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 ainda poderão não conter o campo após adicioná-lo ao esquema do BigQuery. Com o tempo, o esquema é sincronizado, e as mensagens subsequentes incluem o campo.

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

Para saber mais sobre esse recurso, consulte Atualizações da tabela de streaming 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 descarte qualquer campo presente no esquema ou na mensagem do tópico, mas não no esquema do BigQuery. Se a opção Remover campos desconhecidos não estiver definida, as mensagens com campos extras não serão gravadas no BigQuery e permanecerão no backlog da 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 colunas adicionais 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 campos com nomes que correspondam aos parâmetros de metadados. Essa limitação inclui versões camelcase desses parâmetros 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. Se o campo for do tipo JSON, o corpo da mensagem precisará ser um JSON válido.
attributes	STRING ou JSON Um objeto JSON com todos os atributos da mensagem. Ela 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 outras propriedades a seguir.

Nome do bucket

É preciso que um bucket do Cloud Storage já exista 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 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 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 alterar o prefixo e o sufixo do nome do arquivo:

  • Por exemplo, se o valor do prefixo do nome de arquivo for prod_ e o valor do sufixo do nome de 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 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) e segundo (ss). Por exemplo, YY-YYYY ou MMM são inválidos.

  • 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 você pode usar várias vezes: hífen (-), sublinhado (_), dois-pontos (:) e barra (/).

  • Por exemplo, se o valor do formato de data e hora do nome de arquivo for YYYY-MM-DD/hh_mm_ssZ, um exemplo de nome de objeto 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 seja 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 de arquivo for YYYY-MM-DDThh_mm_ss-, um exemplo de nome de objeto será prod_2023-09-25T04_10_00-uNiQuE_archive.

Enviar arquivos em lote

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. Veja a seguir 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 de duração máxima for excedido. Se você não especificar o valor, será aplicado um valor padrão de 5 minutos. Veja a seguir os valores aplicáveis para 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 de máximo de bytes for excedido. Veja a seguir os valores aplicáveis ao 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 quarto 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 simultaneamente vários arquivos em um bucket do Cloud Storage. Se você configurou sua assinatura para criar um novo arquivo a cada seis 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 lote do arquivo. Um arquivo também pode 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, é possível especificar 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.

  Quando você seleciona Avro, também é possível ativar a opção write metadata. Esta opção permite armazenar os metadados da mensagem com a mensagem.

  Metadados como subscription_name, message_id, publish_time e campos de atributos 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 de atributos.

  Se a opção de gravação de metadados estiver desativada, somente o payload da mensagem será gravado no objeto Avro de saída.

  Este é o esquema Avro das mensagens de saída sem metadados de gravação ativados:

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

  Este é o esquema Avro das 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" }
    ]
  }
  

A seguir

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