Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Questa pagina descrive le best practice per l'ottimizzazione di una pipeline Dataflow che legge da Pub/Sub e scrive in BigQuery.
A seconda del tuo caso d'uso, i seguenti suggerimenti potrebbero migliorare il rendimento.
Soluzioni iniziali per i backlog delle pipeline
Quando una pipeline Pub/Sub-BigQuery registra un backlog crescente e non riesce a tenere il passo con i messaggi in arrivo, puoi eseguire i seguenti passaggi immediati:
Aumenta la scadenza di conferma di Pub/Sub:per la sottoscrizione Pub/Sub associata, aumenta la scadenza di conferma a un valore leggermente superiore al tempo massimo di elaborazione dei messaggi previsto. In questo modo, i messaggi non vengono
riconsegnati prematuramente mentre sono ancora in fase di elaborazione.
Aumenta il numero di worker: se il conteggio dei messaggi non riconosciuti e il backlog
della sottoscrizione aumentano rapidamente, è probabile che la capacità di elaborazione
della pipeline sia insufficiente. Aumenta il numero di worker Dataflow per gestire il volume di messaggi.
Attiva il backoff esponenziale:attiva il backoff esponenziale
per migliorare la gestione dei tentativi da parte della pipeline per i problemi temporanei, rendendola
più resiliente.
Ottimizzazioni a lungo termine di codice e pipeline
Per prestazioni e stabilità costanti, si consigliano le seguenti modifiche
all'architettura e al codice:
Riduci le chiamate getTable a BigQuery:un numero eccessivo di chiamate al metodo getTable
può comportare la limitazione della frequenza e colli di bottiglia delle prestazioni. Per
mitigare questo problema:
Memorizza nella cache le informazioni sull'esistenza della tabella nella memoria del worker per evitare chiamate ripetute per la stessa tabella.
Batch getTable calls on a per-bundle basis instead of for each
individual element.
Esegui il refactoring del codice della pipeline per eliminare la necessità di verificare l'esistenza della tabella per ogni messaggio.
Utilizza l'API BigQuery Storage Write:per le pipeline di streaming che scrivono in BigQuery, esegui la migrazione dagli inserimenti di streaming standard all'
API Storage Write. L'API Storage Write offre prestazioni migliori e quote significativamente più elevate.
Utilizza il runner Dataflow legacy per i job con cardinalità elevata:
Per i job che elaborano un numero molto elevato di chiavi uniche
(cardinalità elevata), il runner Dataflow legacy potrebbe offrire
prestazioni migliori rispetto a Runner v2, a meno che non siano necessarie trasformazioni cross-language.
Ottimizza lo spazio delle chiavi:il rendimento può peggiorare quando le pipeline operano
su milioni di chiavi attive. Modifica la logica della pipeline per eseguire il lavoro su uno spazio delle chiavi più piccolo e gestibile.
Gestione di risorse, quote e configurazioni
L'allocazione e la configurazione corrette delle risorse sono fondamentali per l'integrità della pipeline:
Gestisci le quote in modo proattivo:monitora le quote e richiedi aumenti per le quote che potrebbero essere raggiunte durante gli eventi di scalabilità. Ad esempio, considera
i seguenti eventi di scalabilità:
Una frequenza elevata di chiamate ai metodi TableService.getTable o
tabledata.insertAll potrebbe superare il numero massimo di query al
secondo (QPS). Per ulteriori informazioni sui limiti e su come richiedere una quota maggiore, consulta Quote e limiti di BigQuery.
Le quote di Compute Engine per gli indirizzi IP e le CPU in uso potrebbero
superare i limiti massimi. Per ulteriori informazioni sui limiti e su come richiedere
una quota maggiore, consulta la panoramica di quote e limiti di Compute Engine.
Ottimizza la configurazione dei worker:per evitare errori di esaurimento della memoria e
migliorare la stabilità:
Imposta un numero maggiore di
worker
per distribuire il carico di lavoro in modo più uniforme e ridurre l'impatto sulle prestazioni
di eventi di scalabilità automatica frequenti.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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)"]]
