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 le prestazioni.

Soluzioni iniziali per i backlog delle pipeline

Quando una pipeline da Pub/Sub a BigQuery riscontra un backlog in crescita e non riesce a tenere il passo con i messaggi in entrata, puoi eseguire immediatamente i seguenti passaggi:

  • Aumenta il termine di scadenza per l'acknowledgement di Pub/Sub: per la sottoscrizione Pub/Sub associata, aumenta il termine di scadenza a un valore leggermente superiore al tempo di elaborazione massimo previsto per i messaggi. In questo modo, i messaggi non vengono inviati di nuovo prematuramente mentre sono ancora in fase di elaborazione.
  • Esegui lo scale out dei worker: se il conteggio dei messaggi non riconosciuti e il backlog delle sottoscrizioni aumentano rapidamente, è probabile che la capacità di elaborazione della pipeline sia insufficiente. Aumenta il numero di worker Dataflow per gestire il volume di messaggi.
  • Abilita il backoff esponenziale: abilita il backoff esponenziale per migliorare la gestione dei nuovi tentativi della pipeline in caso di problemi temporanei, rendendola più resiliente.

Ottimizzazioni a lungo termine del codice e delle pipeline

Per prestazioni e stabilità sostenute, sono consigliate le seguenti modifiche architetturali e del codice:

  • Riduci le chiamate getTable a BigQuery: un numero eccessivo di chiamate al getTable metodo può causare limitazioni di frequenza e colli di bottiglia delle prestazioni. Per risolvere questo problema:
    • Memorizza nella cache le informazioni sull'esistenza delle tabelle nella memoria dei worker per evitare chiamate ripetute alla stessa tabella.
    • Raggruppa le chiamate getTable in base al bundle anziché per ogni singolo elemento.
    • 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 (gRPC): per le pipeline di streaming che scrivono in BigQuery, esegui la migrazione dagli inserimenti di streaming standard all' API Storage Write (gRPC). L'API Storage Write (gRPC) offre prestazioni migliori e quote significativamente più elevate.
  • Utilizza lo Streaming Java Runner standard (precedentemente chiamato Runner v1) per i job con cardinalità elevata: per i job che elaborano un numero molto elevato di chiavi univoche (cardinalità elevata), lo Streaming Java Runner potrebbe offrire prestazioni migliori rispetto al Portable Runner, a meno che non siano necessarie trasformazioni tra lingue diverse.
  • Ottimizza lo spazio delle chiavi: le prestazioni possono 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 in modo proattivo le quote: monitora le quote e richiedi aumenti per le quote che potrebbero essere raggiunte durante gli eventi di scalabilità. Ad esempio, prendi in considerazione 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 delle quote e dei limiti di Compute Engine.
  • Ottimizza la configurazione dei worker: per evitare errori di esaurimento della memoria e migliorare la stabilità:
    • Utilizza tipi di macchine worker machine types con più memoria.
    • Riduci il numero di thread per worker.
    • Imposta un numero maggiore di worker per distribuire il carico di lavoro in modo più uniforme e ridurre l'impatto sulle prestazioni degli eventi di scalabilità automatica frequenti.

Passaggi successivi