Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Nesta página, descrevemos 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 melhorar a performance.
Soluções iniciais para pendências de pipeline
Quando um pipeline do Pub/Sub para o BigQuery tem um backlog crescente e não consegue acompanhar as mensagens recebidas, siga estas etapas imediatas:
Aumente o prazo de confirmação do Pub/Sub:para a assinatura associada do Pub/Sub, 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.
Escalonar horizontalmente os 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.
Ative a espera exponencial:ative a espera exponencial
para melhorar a forma como o pipeline lida com novas tentativas em problemas temporários, tornando-o
mais resiliente.
Otimizações de código e pipeline de longo prazo
Para ter desempenho e estabilidade consistentes, recomendamos as seguintes mudanças arquitetônicas e de código:
Reduza as chamadas getTable para o BigQuery:o excesso de chamadas de método getTable
pode levar à limitação de taxa e gargalos de desempenho. Para
atenuar isso:
Armazena 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 em todas as mensagens.
Use a API BigQuery Storage Write:para pipelines de streaming que gravam no BigQuery, migre das inserções de streaming padrão para a
API Storage Write. A
API Storage Write oferece melhor desempenho e cotas significativamente
mais altas.
Use o runner do Dataflow legada para jobs de alta cardinalidade:para jobs que processam um número muito grande de chaves exclusivas
(alta cardinalidade), o runner do Dataflow legada pode oferecer
melhor desempenho do que o Runner v2, a menos que transformações entre linguagens sejam
necessárias.
Otimize o espaço de chaves:o desempenho pode diminuir quando os pipelines operam com milhões de chaves ativas. Ajuste a lógica do pipeline para trabalhar em um espaço de chave menor e mais gerenciável.
Gerenciamento de recursos, cotas e configurações
A alocação e a 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 qualquer cota que possa ser atingida 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.
Otimize a configuração do worker:para evitar erros de memória insuficiente (OOM) e
melhorar a estabilidade:
Defina um número maior de
workers
para distribuir a carga de trabalho de maneira mais uniforme e reduzir o impacto no desempenho
de eventos frequentes de escalonamento automático.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-04 UTC."],[],[],null,["# Pub/Sub to BigQuery best practices\n\nThis page outlines best practices for optimizing a Dataflow\npipeline that [reads from\nPub/Sub](/dataflow/docs/concepts/streaming-with-cloud-pubsub) and\n[writes to BigQuery](/dataflow/docs/guides/write-to-bigquery).\nDepending on your use case, the following suggestions might lead to better\nperformance.\n\nInitial solutions for pipeline backlogs\n---------------------------------------\n\nWhen a Pub/Sub to BigQuery pipeline experiences a\ngrowing backlog and can't keep up with incoming messages, you can take the\nfollowing immediate steps:\n\n- **Increase Pub/Sub acknowledgment deadline:** For the associated Pub/Sub subscription, [increase the acknowledgment\n deadline](/pubsub/docs/lease-management) to a value slightly longer than the maximum expected message processing time. This prevents messages from being redelivered prematurely while they are still being processed.\n- **Scale out workers:** If the unacknowledged message count and subscription backlog are growing rapidly, the pipeline's processing capacity is likely insufficient. Increase the [number of Dataflow\n workers](/dataflow/docs/reference/pipeline-options) to handle the message volume.\n- **Enable exponential backoff:** Enable [exponential backoff](/pubsub/docs/handling-failures#exponential_backoff) to improve how the pipeline handles retries for transient issues, making it more resilient.\n\nLong-term code and pipeline optimizations\n-----------------------------------------\n\nFor sustained performance and stability, the following architectural and code\nchanges are recommended:\n\n- **Reduce `getTable` calls to BigQuery:** Excessive `getTable` method calls can lead to rate-limiting and performance bottlenecks. To mitigate this:\n - Cache table existence information in worker memory to avoid repeated calls for the same table.\n - Batch `getTable` calls on a per-bundle basis instead of for each individual element.\n - Refactor the pipeline code to eliminate the need to check for table existence for every message.\n- **Use the BigQuery Storage Write API:** For streaming pipelines writing to BigQuery, migrate from standard streaming inserts to the [Storage Write API](/bigquery/docs/write-api). The Storage Write API offers better performance and significantly higher quotas.\n- **Use the legacy Dataflow runner for high-cardinality jobs:** For jobs that process a very large number of unique keys (*high-cardinality*), the legacy Dataflow runner might offer better performance than Runner v2, unless cross-language transforms are required.\n- **Optimize the key space:** Performance can degrade when pipelines operate on millions of active keys. Adjust the pipeline's logic to perform work on a smaller, more manageable key space.\n\nResource, quota, and configuration management\n---------------------------------------------\n\nProper resource allocation and configuration are critical for pipeline health:\n\n- **Proactively manage quotas:** Monitor quotas and request increases for any quotas that might be reached during scaling events. For example, consider the following scaling events:\n - A high rate of calls to the `TableService.getTable` or `tabledata.insertAll` methods might exceed the maximum queries per second (QPS). For more information on limits and how to request more quota, see [BigQuery quotas and\n limits](/bigquery/quotas).\n - Compute Engine quotas for in-use IP addresses and CPUs might exceed maximum limits. For more information on limits and how to request more quota, see the [Compute Engine quota and limits\n overview](/compute/quotas-limits).\n- **Optimize worker configuration:** To prevent out-of-memory (OOM) errors and improve stability:\n - Use worker [machine\n types](/dataflow/docs/guides/configure-worker-vm#machine-type) with more memory.\n - Reduce the [number of\n threads](/dataflow/docs/reference/pipeline-options#resource_utilization) per worker.\n - Set a higher [number of\n workers](/dataflow/docs/reference/pipeline-options#resource_utilization) to distribute the workload more evenly and reduce the performance impact of frequent autoscaling events.\n\nWhat's next\n-----------\n\n- [Develop and test Dataflow pipelines](/dataflow/docs/guides/develop-and-test-pipelines)\n- [Dataflow pipeline best practices](/dataflow/docs/guides/pipeline-best-practices)\n- [Dataflow job metrics](/dataflow/docs/guides/using-monitoring-intf)"]]
