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ê a partir do Pub/Sub e escreve no BigQuery. Consoante o seu exemplo de utilização, as seguintes sugestões podem gerar um melhor desempenho.

Soluções iniciais para atrasos no pipeline

Quando um pipeline do Pub/Sub para o BigQuery regista um aumento do backlog e não consegue acompanhar as mensagens recebidas, pode tomar os seguintes passos imediatos:

  • Aumente o prazo de confirmação do Pub/Sub: para a subscrição do Pub/Sub associada, aumente o prazo de confirmação para um valor ligeiramente superior ao tempo de processamento de mensagens máximo esperado. Isto impede que as mensagens sejam reenviadas prematuramente enquanto ainda estão a ser processadas.
  • Aumente o número de trabalhadores: se o número de mensagens não acusadas e a acumulação de tarefas da subscrição estiverem a aumentar rapidamente, é provável que a capacidade de processamento do pipeline seja insuficiente. Aumente o número de trabalhadores do Dataflow para processar o volume de mensagens.
  • Ative a retirada exponencial: ative a retirada exponencial para melhorar a forma como o pipeline processa as novas tentativas de problemas transitórios, tornando-o mais resiliente.

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

Para um desempenho e uma estabilidade sustentados, recomendamos as seguintes alterações arquitetónicas e de código:

  • Reduza as chamadas getTable para o BigQuery: as chamadas de métodos getTable excessivas podem levar a limites de taxa e gargalos de desempenho. Para mitigar esta situação:
    • Coloque em cache as informações de existência da tabela na memória do trabalhador para evitar chamadas repetidas para a mesma tabela.
    • As chamadas em lote são feitas por pacote, em vez de para cada elemento individual.getTable
    • Refatore o código do pipeline para eliminar a necessidade de verificar a existência da tabela para cada mensagem.
  • Use a API Storage Write do BigQuery: para pipelines de streaming que escrevem no BigQuery, migre das inserções de streaming padrão para a API Storage Write. A API Storage Write oferece um melhor desempenho e quotas significativamente mais elevadas.
  • Use o executor do Dataflow antigo para tarefas de elevada cardinalidade: para tarefas que processam um número muito elevado de chaves únicas (elevada cardinalidade), o executor do Dataflow antigo pode oferecer um desempenho melhor do que o executor v2, a menos que sejam necessárias transformações entre idiomas.
  • Otimize o espaço de chaves: o desempenho pode degradar-se quando os pipelines operam com milhões de chaves ativas. Ajuste a lógica do pipeline para realizar o trabalho num espaço de chaves mais pequeno e mais fácil de gerir.

Gestão de recursos, quotas e configuração

A configuração e a atribuição adequadas de recursos são fundamentais para o bom funcionamento do pipeline:

  • Gerir proativamente as quotas: monitorize as quotas e peça aumentos para quaisquer quotas que possam ser atingidas durante eventos de escalabilidade. Por exemplo, considere os seguintes eventos de dimensionamento:
    • Uma taxa elevada de chamadas para os métodos TableService.getTable ou tabledata.insertAll pode exceder o número máximo de consultas por segundo (CPS). Para mais informações sobre os limites e como pedir mais quota, consulte o artigo Quotas e limites do BigQuery.
    • As quotas do Compute Engine para endereços IP e CPUs em utilização podem exceder os limites máximos. Para mais informações sobre os limites e como pedir mais quota, consulte a vista geral da quota e dos limites do Compute Engine.
  • Otimize a configuração do trabalhador: para evitar erros de falta de memória (OOM) e melhorar a estabilidade:

O que se segue?