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.

Este documento descreve as diferentes propriedades da assinatura que você pode definir para uma assinatura.

Antes de começar

• Saiba mais sobre assinaturas.

• Entenda o fluxo de trabalho da assinatura que você vai create: Pull, Push ou BigQuery.

Propriedades comuns de assinaturas

Ao criar uma assinatura, você precisa especificar várias opções para configure a assinatura. Algumas dessas propriedades são comuns a todos os tipos de assinaturas. Eles serão abordados 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 mensagens após a publicação. Após esse período, O Pub/Sub pode descartar a mensagem independentemente da de confirmação da mensagem. Para reter mensagens confirmadas por e a duração da 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: se você reter mensagens não confirmadas em uma assinatura por mais mais de 24 horas, haverá cobranças adicionais. Para mais informações, consulte Custos de armazenamento.

Mensagens não confirmadas podem resultar de assinaturas inativas, necessidades de backup ou processamento lento. Se você for processar as mensagens em 24 horas, as cobranças adicionais serão incorridas. Para evitar novas cobranças, gerencie essas situações da seguinte forma:

• Assinaturas inativas. Excluir 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, é possível mudar para outra opção de armazenamento, como retenção de mensagens de tópico ou reter mensagens confirmadas. A retenção de mensagens de tópicos armazena mensagens por tema e permanecem disponíveis para todos os assinaturas para consumir quando necessário.

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

Reter mensagens reconhecidas

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

A opção Reter mensagens confirmadas permite reter mensagens confirmadas mensagens pela duração especificada da retenção de mensagens. Essa opção aumenta as taxas de armazenamento de mensagens. Para mais informações, consulte de armazenamento.

Período de expiração

A opção Período de expiração permite estender o período de expiração do sua assinatura.

Inscrições sem atividade ou mudanças do assinante 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 de inscritos 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 no 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 após o qual uma não confirmada é enviada novamente. Você pode estender a confirmação prazo por mensagem, enviando posteriormente ModifyAckDeadline solicitações.

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 controlar a taxa de entrega e modificar dinamicamente o prazo de confirmação. Ao fazer isso, a mensagem pode ser entregue novamente antes da confirmação prazo que você definiu. Para substituir esse comportamento, use minDurationPerAckExtension e maxDurationPerAckExtension. Para mais informações sobre como usar esses valores, consulte Suporte de entrega única em bibliotecas de cliente.

Filtro de assinatura

Use a opção Filtro de assinatura para especificar uma string com um expressão de filtragem. Se uma assinatura tiver um filtro, ela só entregará as mensagens que correspondem ao filtro. O serviço Pub/Sub automaticamente confirma 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 filtra mensagens e os assinantes recebem todas as mensagens.

• 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 opção Ordem de mensagens ativada, o os clientes assinantes recebem mensagens publicadas na mesma região com o mesma chave de ordem na ordem em que as mensagens foram recebidas pelo serviço.

Ao usar a entrega ordenada, as confirmações das mensagens posteriores são 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 pode entregar as mensagens em ordem.

Se ela não for definida, talvez o Pub/Sub 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 depois de um número definido de tentativas de entrega ou um assinante não confirmar a mensagem, você pode 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, também precisa 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 pode enviar 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 como use a opção Tentar novamente imediatamente. Com essa opção, O Pub/Sub reenvia a mensagem quando o prazo de confirmação 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, é necessário especificar os valores de espera máximo e mínimo.

Aqui estão algumas diretrizes para definir os valores para máximo valores mínimos de espera:

• Se você definir o valor máximo para a duração de espera, o valor padrão para o mínimo de espera seja 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 é 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 o seguinte propriedades.

Entrega "exatamente uma vez"

Entrega exatamente uma vez. Se definido, o Pub/Sub é atendido garante a entrega exatamente uma vez. Se não for especificada, a assinatura terá suporte entrega pelo menos uma vez para cada mensagem.

Propriedades da assinatura de push

Ao configurar uma assinatura de push, é possível especificar o seguinte propriedades.

Endpoints

URL do endpoint (obrigatório). Um endereço HTTPS de acesso público. O servidor do envio endpoint precisa ter um certificado SSL válido assinado por uma autoridade certificadora. 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 envio domínios de URL de assinatura. Se seu domínio recebe solicitações POST inesperadas no 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 para permitir que o endpoint autentique a solicitação. Autenticação automática e Há mecanismos de autorizaçã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 de uma assinatura de push autenticada consiste em uma conta serviço gerenciado pelo usuário, e os parâmetros de público-alvo que são especificados em uma criação, patch ou ModifyPushConfig a chamada. Você também precisa conceder um papel específico a um agente de serviço, conforme discutido em na próxima seção.

• Conta de serviço gerenciado pelo usuário (obrigatório). A conta de serviço associada ao push assinatura. 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 organização para permitir que para representar várias contas de serviço ou conceder um papel com este no serviço conta para permitir que o autor da chamada representem apenas essa conta de serviço.

• Público. Uma única string que não diferencia maiúsculas de minúsculas 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 o Permissão iam.serviceAccounts.getOpenIdToken (incluída no roles/iam.serviceAccountTokenCreator papel) 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 o Pub/Sub mensagens de todos os metadados da mensagem, exceto os dados da mensagem. Com payload desencapsulamento, os dados da mensagem serão entregues diretamente como o corpo HTTP.

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

Propriedades do BigQuery

Ao selecionar um tipo de entrega de assinatura como Gravar no BigQuery, especifique 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 o em anexo. Além disso, o Pub/Sub grava os campos nas mensagens para a colunas na tabela do BigQuery.

Cuidado: a exclusão ou a revisão de um esquema é permanente. Todas as mensagens que validado em relação a uma revisão de esquema excluída no momento da publicação não pode ser gravado no BigQuery usando uma assinatura do BigQuery Ative a opção Usar esquema de tópicos. 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 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 necessários no esquema do BigQuery.

• Se houver campos do BigQuery que não estão presentes no esquema de tópicos, esses campos do BigQuery precisa estar no modo NULLABLE.

• Se o esquema de tópicos tiver campos adicionais que não estão presentes no esquema do BigQuery, campos podem 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 de digite BYTES, STRING ou JSON. O Pub/Sub grava a mensagem essa coluna do BigQuery.

Talvez você não veja alterações no esquema de tópicos do Pub/Sub ou O esquema da tabela do BigQuery entra em vigor imediatamente com mensagens gravados na tabela do BigQuery. Por exemplo, se Drop a opção de campos desconhecidos está ativada e há um campo presente na o esquema do Pub/Sub, mas não o do BigQuery, mensagens gravadas na tabela do BigQuery podem não conter depois de adicioná-lo ao esquema do BigQuery. Em algum momento, os esquemas serão sincronizados, e as mensagens subsequentes incluirão o campo.

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

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

Para aprender a 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 do tabela do BigQuery para gravar os campos de uma às colunas correspondentes. Ao usar essa opção, lembre-se de verifique os seguintes requisitos adicionais:

• As mensagens publicadas precisam estar no formato JSON.

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

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

• Se as mensagens tiverem campos adicionais que não estejam presentes no esquema do BigQuery e esses campos possam ser descartados, selecione o opção Descartar campos desconhecidos.

• Na mensagem JSON, os valores DATE, DATETIME, TIME e TIMESTAMP precisam ser números inteiros que estejam de acordo com as 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 de digite BYTES, STRING ou JSON. O Pub/Sub grava a mensagem essa coluna do BigQuery.

Talvez você não note que as alterações no esquema da tabela do BigQuery imediatamente com mensagens gravadas na tabela do BigQuery. Por exemplo, se a opção Descartar campos desconhecidos estiver ativada e um campo for presentes nas mensagens, mas não no esquema do BigQuery, mensagens gravadas na tabela do BigQuery podem não conter depois de adicioná-lo ao esquema do BigQuery. Em algum momento, 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, 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 a tabelas linhas

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 é utilizada com as opções Usar esquema de tópicos ou Usar esquema de tabela. é a melhor opção. Essa opção permite que o Pub/Sub remova qualquer campo presente no tópico ou mensagem, mas não no esquema do BigQuery. Sem Drop desconhecido campos definidos, as mensagens com campos extras não são gravadas ao BigQuery e permanecer no backlog das assinaturas. O assinatura acaba em estado de erro.

Gravar metadados

Essa opção permite que o Pub/Sub gravar os metadados de cada mensagem em colunas adicionais na Tabela do BigQuery. Caso contrário, os metadados não é gravado na tabela do BigQuery.

Se você selecionar a opção Gravar metadados, verifique se o 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 é verdadeiro. Se você selecionar os campos Metadados de gravação e Use as opções de esquema de tópicos, o esquema do tópico deverá não conter campos com nomes que correspondam 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 todos os destinos Tabelas do BigQuery que não selecionam Usar esquema de tópicos ou Usar esquema de tabela. Se o campo é do tipo JSON, o corpo da mensagem deve ser JSON válido.
attributes	STRING ou JSON Um objeto JSON que contém todos os atributos de mensagem. Ela também contém campos adicionais que fazem parte Mensagem do Pub/Sub, incluindo a chave de ordem, se estiver presente.

Propriedades do Cloud Storage

Ao selecionar um tipo de entrega de assinatura como Gravar no Cloud Storage, especifique as propriedades adicionais a seguir.

Nome do bucket

É necessário que já exista um bucket do Cloud Storage antes da criação de um 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. que estão nele.

O bucket do Cloud Storage precisa ter Pagamentos do solicitante desativado.

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

Prefixo, sufixo e data/hora do nome de arquivo

Os arquivos de saída gerados pelo Cloud Storage são armazenadas 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 você podem personalizar:

• <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. 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 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 do arquivo for prod_ e o valor do 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 do arquivo, o nome do objeto armazenado no bucket do Cloud Storage tem o formato: <UTC-date-time>_<uuid>:

  • Os requisitos de nomenclatura de objetos do Cloud Storage também se aplicam ao nome de arquivo e sufixo. 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 e deslocamento de fuso horário (Z ou +00:00).

  • Elementos opcionais que você pode usar várias vezes: hífen (-), underline (_), 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 é 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 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 é prod_2023-09-25T04_10_00-uNiQuE_archive.

Lote de arquivos

As assinaturas do Cloud Storage permitem que você decida quando criar um novo arquivo de saída armazenado como um objeto no Cloud Storage do Google Cloud. O Pub/Sub grava um arquivo de saída quando as condições de lote especificadas sejam atendidas. A seguir estão os Condições de lote do Cloud Storage:

• Duração máxima do lote de armazenamento. Essa configuração é obrigatória. O 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, será aplicado um valor padrão de 5 minutos. 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. O A assinatura do Cloud Storage grava um novo arquivo de saída se o o valor especificado do máximo de bytes for excedido. Os itens a seguir são os valores para o máximo de bytes:

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

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

  • Valor mínimo = 1.000

Por exemplo, você pode configurar a duração máxima como 6 minutos e como 2 GB. Se, no 4o minuto, o arquivo de saída atingir uma tamanho de arquivo de 2 GB, o Pub/Sub finaliza o arquivo anterior e começa gravar em um novo arquivo.

Uma assinatura do Cloud Storage pode gravar em vários arquivos de um ao mesmo bucket do Cloud Storage. Se você configurou seu para criar um novo arquivo a cada 6 minutos, poderá observar a criação de vários arquivos do Cloud Storage a cada 6 minutos.

Em algumas situações, o Pub/Sub pode começar a gravar em um novo do arquivo anterior ao horário configurado pelas condições de lote do arquivo. Um arquivo também poderá exceder o valor máximo de bytes se a assinatura recebe mensagens maiores que o valor máximo de bytes.

Formato do arquivo

Ao criar uma assinatura do Cloud Storage, 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. Apenas mensagem payloads são armazenados, não atributos ou outros metadados.

• Avro: as mensagens são armazenadas em Formato do binário Apache Avro (link em inglês). 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" }
      ]
    }
    

  • Use topic schema: essa opção permite que o Pub/Sub use o esquema do tópico do Pub/Sub ao qual a assinatura é 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.

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