Solução de problemas de assinaturas do BigQuery

Nesta página, você verá algumas dicas de solução de problemas comuns para assinaturas do BigQuery.

Verificar o estado de uma assinatura do BigQuery

Para verificar o estado de uma assinatura, siga estas etapas:

  1. No console do Google Cloud, acesse a página de assinatura do Pub/Sub.

    Acessar "Assinaturas"

  2. Marque o ícone Estado da sua assinatura do BigQuery.

    Se o ícone for uma marca de seleção verde, a assinatura está íntegra.

    Se aparecer um ponto de exclamação vermelho, a assinatura está em estado de erro.

  3. Clique na assinatura do BigQuery.

    A página de detalhes da assinatura é aberta.

  4. Verifique se a mensagem de erro aparece no Estado da assinatura.

  5. Dependendo da mensagem de erro, consulte a seção relevante nesta página para solucionar o problema.

Depois que o problema é resolvido, a assinatura retorna a um estado íntegro.

Não foi possível criar ou atualizar a assinatura

Estes são alguns dos problemas comuns que você pode enfrentar se tiver dificuldade para criar ou atualizar uma assinatura do BigQuery.

Erro de tabela não encontrada

Se a tabela especificada no fluxo de trabalho de criação ou atualização de assinaturas não existir, o fluxo de trabalho retornará um erro de tabela não encontrada. No console do Google Cloud, a mensagem é semelhante a esta:

The BigQuery table or dataset specified cannot be found.

Para resolver o problema, crie a tabela e verifique o state antes de usá-la com uma assinatura do BigQuery.

Erro de incompatibilidade de esquema

Se os esquemas da tabela e do tópico não forem compatíveis, o fluxo de trabalho de criação ou atualização da assinatura retornará um erro de incompatibilidade de esquema. No console do Google Cloud, a mensagem é semelhante a esta:

Incompatible schema type for field project_ids: expected INT64, got STRING

A mensagem de erro especificada é para incompatibilidade de esquema para um campo chamado project_ids. Dependendo do tipo de incompatibilidade de esquema, talvez você veja uma variação diferente da mensagem de erro.

Para resolver o problema, verifique se os mapeamentos de esquema são compatíveis.

Erro na conta de serviço

Se você não tiver configurado a conta de serviço do Pub/Sub com as permissões corretas, o fluxo de trabalho de criação ou atualização da assinatura retornará um erro. No console do Google Cloud, a mensagem é semelhante a esta:

Service account service-1234234234@gcp-sa-pubsub.iam.gserviceaccount.com
is missing permissions required to write to the BigQuery table:
bigquery.tables.get, bigquery.tables.updateData.

Para resolver o problema, verifique se a conta de serviço tem as permissões corretas.

O estado da assinatura mostra uma exclamação em vermelho

Editar a tabela depois de criar uma assinatura pode afetar a maneira como o Pub/Sub grava mensagens na tabela. Se uma mudança resultar em um problema, o campo de estado da assinatura será definido como um estado de erro.

Na página de detalhes da assinatura, verifique o estado do campo Subscription state. O campo Subscription state fornece um erro mais específico, que pode ser um dos seguintes:

  • table not found: a tabela foi excluída. Crie uma tabela e verifique o estado dela. Consulte Receber informações da tabela.

  • Tabela de permissão negada: a conta de serviço do Pub/Sub não tem mais permissão para gravar na tabela. Verifique se a conta de serviço tem as permissões corretas.

  • Incompatibilidade de esquema da tabela: o esquema da tabela não é mais compatível com as configurações de assinatura do BigQuery. Verifique se os mapeamentos de esquema são compatíveis.

Enquanto uma assinatura do Pub/Sub está em estado de erro, as mensagens não são gravadas na tabela do BigQuery e permanecem no backlog da assinatura. As mensagens não são entregues a um tópico de mensagens inativas anexado, se configurado. As mensagens não confirmadas são retidas pelo período definido em message_retention_duration(7d, por padrão).

Uma lista de pendências está se acumulando

Se você vir um backlog de mensagens acumulando na assinatura ou mensagens direcionadas a um tópico de mensagens inativas de uma assinatura, analise as possíveis causas a seguir.

Mensagem de erro INVALID_ARGUMENT

Esse erro acontece quando a mensagem fornecida está em um formato que o Pub/Sub considera válido, mas o esquema da tabela de destino do BigQuery não. Isso significa que um ou mais campos na mensagem têm valores que não são permitidos pelo esquema da tabela do BigQuery. Revise a compatibilidade de esquema para verificar se os tipos e formatos de dados estão corretos. Alguns dos erros mais comuns incluem:

  • Uma string vazia ("") não é um JSON válido. Ao enviar dados para uma coluna de tabela JSON anulável do BigQuery, forneça um objeto JSON vazio ({}), null ou uma string JSON vazia ("\"\"") para representar valores ausentes. O envio de uma string vazia resulta em erro.

  • Se o valor de um campo de mensagem exceder o tamanho máximo do campo do BigQuery, a mensagem falhará devido a limitações de tamanho.

Para resolver erros INVALID_ARGUMENT, adicione um tópico de mensagens inativas à assinatura de interesse. O tópico de mensagens inativas captura mensagens que não foram gravadas no BigQuery, com um atributo chamado CloudPubSubDeadLetterSourceDeliveryErrorMessage que explica o motivo da falha.

Essas falhas de entrega também podem ser vistas no Metrics Explorer. Selecione a métrica pubsub.googleapis.com/subscription/push_request_count e filtre por response_code=invalid_argument.

Mensagem de erro "RESOURCE_EXHAUSTED"

Se as mensagens estiverem sendo gravadas no BigQuery lentamente, talvez seja necessário aumentar a cota de push do Pub/Sub do seu projeto ou a cota de capacidade de gravação do armazenamento do BigQuery. Para verificar se você está encontrando limitações de cota, examine a métrica de solicitações de push (subscription/push_request_count) para encontrar erros resource_exhausted.

Outra maneira de diagnosticar problemas de cota é verificar a cota do projeto. Acesse IAM e administrador > Cotas no projeto que contém o recurso do Pub/Sub ou a instância do BigQuery. Pesquise a cota relevante, pubsub.googleapis.com/regionalpushsubscriber ou bigquerystorage.googleapis.com/write/append_bytes. Solicite uma cota maior se alguma das cotas precisar ser aumentada.

Tabela particionada por hora mostrando __UNPARTITIONED__ na coluna de ID da partição

Quando uma tabela de destino do BigQuery é particionada por hora, as linhas inicialmente chegam a uma partição especial chamada __UNPARTITIONED__ na visualização INFORMATION_SCHEMA.PARTITIONS. Esse é o comportamento esperado para tabelas que usam o particionamento por tempo de ingestão.

O BigQuery emprega um buffer de streaming para otimizar o processo de gravação. Os dados podem residir na partição __UNPARTITIONED__ até que um volume suficiente acumule ou até que tenha se passado pelo menos uma hora. Depois que essas condições são atendidas, o BigQuery particiona novamente os dados na partição por hora apropriada.

É possível monitorar dados na partição __UNPARTITIONED__ usando a visualização INFORMATION_SCHEMA.PARTITIONS.

A seguir