Best practice per Pub/Sub in BigQuery

Questa pagina descrive le best practice per ottimizzare una pipeline Dataflow che legge da Pub/Sub e scrive in BigQuery. A seconda del tuo caso d'uso, i seguenti suggerimenti potrebbero portare a un rendimento migliore.

Soluzioni iniziali per i backlog delle pipeline

Quando una pipeline Pub/Sub-BigQuery registra un backlog in crescita 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 numero di 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 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 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 uniche (cardinalità elevata), Streaming Java Runner potrebbe offrire prestazioni migliori rispetto a Portable Runner, 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 saperne di più 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 saperne di più 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à:
    • Utilizza tipi di macchine worker con più memoria.
    • Riduci il numero di thread per worker.
    • Imposta un numero di worker più elevato per distribuire il carico di lavoro in modo più uniforme e ridurre l'impatto sulle prestazioni di frequenti eventi di scalabilità automatica.

Passaggi successivi