Best practice per Pub/Sub in BigQuery

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à:

Passaggi successivi