Práticas recomendadas do Pub/Sub para o BigQuery

Esta página descreve as práticas recomendadas para otimizar um pipeline do Dataflow que lê do Pub/Sub e grava no BigQuery. Dependendo do seu caso de uso, as sugestões a seguir podem levar a um melhor desempenho.

Soluções iniciais para backlogs de pipeline

Quando um pipeline do Pub/Sub para o BigQuery tem um backlog crescente e não consegue acompanhar as mensagens recebidas, você pode seguir estas etapas imediatas:

  • Aumentar o prazo de confirmação do Pub/Sub:para a assinatura do Pub/Sub associada, aumente o prazo de confirmação para um valor um pouco maior que o tempo máximo esperado de processamento de mensagens. Isso impede que as mensagens sejam reenviadas prematuramente enquanto ainda estão sendo processadas.
  • Fazer o escalonamento horizontal de workers:se a contagem de mensagens não confirmadas e o backlog de assinaturas estiverem crescendo rapidamente, a capacidade de processamento do pipeline provavelmente será insuficiente. Aumente o número de workers do Dataflow para lidar com o volume de mensagens .
  • Ativar a espera exponencial: Ative a espera exponencial para melhorar a forma como o pipeline lida com novas tentativas de problemas temporários, tornando-o mais resiliente.

Otimizações de código e pipeline de longo prazo

Para desempenho e estabilidade sustentados, as seguintes mudanças arquitetônicas e de código são recomendadas:

  • Reduzir as chamadas getTable para o BigQuery: chamadas excessivas de método getTable podem levar a limitações de taxa e gargalos de desempenho. Para atenuar isso:
    • Armazene em cache as informações de existência da tabela na memória do worker para evitar chamadas repetidas para a mesma tabela.
    • Agrupe as chamadas getTable por pacote, em vez de cada elemento individual.
    • Refatore o código do pipeline para eliminar a necessidade de verificar a existência da tabela para cada mensagem.
  • Usar a API BigQuery Storage Write: para pipelines de streaming que gravam no BigQuery, migre de inserções de streaming padrão para a API Storage Write. A API Storage Write oferece melhor desempenho e cotas significativamente mais altas.
  • Usar o Streaming Java Runner padrão (anteriormente chamado de Runner v1) para jobs de alta cardinalidade:para jobs que processam um número muito grande de chaves exclusivas (alta cardinalidade), o Streaming Java Runner pode oferecer melhor desempenho do que o Portable Runner, a menos que transformações entre idiomas sejam necessárias.
  • Otimizar o espaço de chaves:o desempenho pode ser degradado quando os pipelines operam em milhões de chaves ativas. Ajuste a lógica do pipeline para trabalhar em um espaço de chaves menor e mais gerenciável.

Gerenciamento de recursos, cotas e configuração

A alocação e configuração adequadas de recursos são essenciais para a integridade do pipeline:

  • Gerenciar cotas de forma proativa:monitore as cotas e solicite aumentos para todas as cotas que possam ser atingidas durante eventos de escalonamento. Por exemplo, considere os seguintes eventos de escalonamento:
    • Uma alta taxa de chamadas para os métodos TableService.getTable ou tabledata.insertAll pode exceder o máximo de consultas por segundo (QPS). Para mais informações sobre limites e como solicitar mais cota, consulte Cotas e limites do BigQuery.
    • As cotas do Compute Engine para endereços IP e CPUs em uso podem exceder os limites máximos. Para mais informações sobre limites e como solicitar mais cota, consulte a visão geral de cotas e limites do Compute Engine.
  • Otimizar a configuração do worker:para evitar erros de memória insuficiente (OOM) e melhorar a estabilidade:

A seguir