Risolvere i problemi relativi ai colli di bottiglia in Dataflow

Un collo di bottiglia si verifica quando un passaggio, una fase o un worker rallenta il job complessivo. I colli di bottiglia possono portare a worker inattivi e a una maggiore latenza.

Se Dataflow rileva un collo di bottiglia, il grafico del job mostra un avviso e il riquadro Informazioni passaggio elenca il tipo di collo di bottiglia e la causa, se nota. Dataflow esporta anche le informazioni sul rilevamento dei colli di bottiglia in una metrica di Monitoring, che presenta i dati come serie temporale. In questo modo puoi visualizzare i colli di bottiglia nel tempo o nel passato.

Comprendi i colli di bottiglia

Quando Dataflow esegue una pipeline di streaming, il job è costituito da una serie di componenti, come shuffling in streaming, thread di elaborazione funzione definita dall'utente (DoFn) e checkpoint dello stato persistente. Per facilitare il flusso di dati, Dataflow utilizza le code per connettere questi componenti. I dati vengono inviati dall'upstream al downstream.

In molte pipeline, la capacità di throughput complessiva è limitata da un singolo componente, creando un collo di bottiglia nella pipeline. La velocità con cui i dati possono passare attraverso un collo di bottiglia limita la velocità con cui la pipeline può accettare ed elaborare i dati di input.

Ad esempio, considera una pipeline in cui l'elaborazione DoFn avviene a valle di uno shuffle in modalità flusso. Una coda tra di loro memorizza nel buffer i dati mescolati, ma non elaborati. Se l'elaborazione di DoFn non riesce a consumare i dati con la stessa rapidità con cui lo shuffle in modalità flusso li produce, la coda cresce. Un collo di bottiglia prolungato può far sì che la coda raggiunga la sua capacità massima. A quel punto, l'ulteriore shuffling viene messo in pausa e il backlog si propaga a monte. Anche le code più a monte accumulano backlog, causando un rallentamento che si estende all'origine dati, il che significa che l'intera pipeline non riesce a tenere il passo con l'input.

Quando si verifica un collo di bottiglia, una parte sostanziale della pipeline potrebbe sembrare in stato non integro, anche se il backlog è causato da un singolo punto della pipeline. Questo comportamento può rendere difficile il debug dei colli di bottiglia. L'obiettivo del rilevamento dei colli di bottiglia è identificare la posizione e la causa esatte, eliminando le congetture, in modo da poter risolvere la causa principale.

Dataflow rileva un collo di bottiglia quando un ritardo supera la soglia di cinque minuti. Se il ritardo non supera questa soglia, Dataflow non rileva un collo di bottiglia.

Il rilevamento dei colli di bottiglia non richiede sempre un intervento e dipende dal caso d'uso. Una pipeline può funzionare normalmente con ritardi temporanei di oltre cinque minuti. Se questo è accettabile per il tuo caso d'uso, potresti non dover risolvere i colli di bottiglia indicati.

Tipi di colli di bottiglia

Quando Dataflow rileva un collo di bottiglia, l'interfaccia di monitoraggio indica la gravità del problema. I colli di bottiglia rientrano nelle seguenti categorie:

L'elaborazione è bloccata e non procede
L'avanzamento della pipeline viene interrotto completamente in questo passaggio.
L'elaborazione è in corso, ma è in ritardo.
La pipeline non riesce a elaborare i dati in entrata con la stessa rapidità con cui arrivano. Di conseguenza, il backlog sta crescendo.
L'elaborazione è in corso, ma il backlog è stabile
La pipeline sta procedendo e la velocità di elaborazione è paragonabile alla velocità di input. L'elaborazione è abbastanza veloce da impedire la crescita del backlog, ma il backlog accumulato non sta diminuendo in modo significativo.
L'elaborazione è in corso e sta recuperando da un backlog
Il backlog sta diminuendo, ma l'attuale collo di bottiglia impedisce alla pipeline di recuperare più velocemente. Se avvii una pipeline con un backlog, questo stato potrebbe essere normale e non richiedere alcun intervento. Monitora i progressi per vedere se il backlog continua a diminuire.

Cause dei colli di bottiglia

In questa sezione sono elencate le cause dei colli di bottiglia che possono essere rilevati. Utilizza queste informazioni per risolvere il problema. In alcuni casi, potrebbero essere presenti più cause, che potrebbero essere correlate. Ad esempio, se i worker sono sottoprovisionati, l'utilizzo della vCPU potrebbe essere elevato. Un utilizzo elevato della vCPU può rallentare le operazioni, il che a sua volta può creare un ritardo elevato nella coda. L'analisi delle cause probabili potrebbe mostrare tutte queste cause del collo di bottiglia.

Operazioni con tempi di elaborazione lunghi

Alcune operazioni di questo calcolo hanno un tempo di elaborazione lungo. Questo accade ogni volta che un bundle di input viene inviato al worker che esegue DoFn e trascorre un periodo di tempo significativo senza che siano disponibili risultati.

Questo è spesso il risultato di una singola operazione a lunga esecuzione nel codice utente. Altri problemi possono manifestarsi come operazioni con tempi di elaborazione lunghi. Ad esempio, gli errori generati e ripetuti all'interno di DoFn, i nuovi tentativi per lunghi periodi di tempo o gli arresti anomali del worker harness dovuti a fattori come gli errori di memoria esaurita possono causare questi lunghi tempi di elaborazione.

Se il calcolo interessato si trova nel codice utente, cerca modi per ottimizzare il codice o limitare il tempo di esecuzione. Per facilitare il debug, i log dei worker mostrano le analisi dello stack per tutte le operazioni bloccate per più di 5 minuti.

Commit della chiave troppo grande

Consulta Eccezione di commit della chiave troppo grande.

Autorizzazione negata per il sink BigQuery

Questo errore indica che il account di servizio che esegue la pipeline non dispone delle autorizzazioni necessarie per scrivere nella risorsa BigQuery.

Per convalidare questo problema utilizzando i log dei worker:

  1. Nella console Google Cloud , apri la pagina Dettagli job di Dataflow.
  2. Nel riquadro in basso, fai clic sulla scheda Log e seleziona Log worker.
  3. Cerca messaggi di errore che indicano che le autorizzazioni o l'accesso sono stati negati (ad esempio PERMISSION_DENIED, 403 Forbidden, Access Denied o actuallyForbidden).
  4. Esamina il messaggio di log per identificare il set di dati o la tabella di destinazione e l'autorizzazione mancante specifica (ad esempio bigquery.tables.updateData).

Per risolvere il problema:

  • Verifica che al account di servizio sia stato concesso il ruolo BigQuery Data Editor (roles/bigquery.dataEditor) nel set di dati e nella tabella di destinazione.
  • Se la scrittura avviene tra progetti, assicurati che le autorizzazioni vengano concesse al account di servizio direttamente nel progetto di destinazione che ospita il set di dati BigQuery e che i Controlli di servizio VPC (se abilitati) consentano la comunicazione tra entrambi i progetti.

Se questi passaggi non risolvono il problema, consulta Ruoli predefiniti e autorizzazioni di BigQuery per identificare e concedere eventuali autorizzazioni granulari mancanti necessarie per la tua configurazione specifica.

Risorsa sink BigQuery esaurita

Questo errore indica che la pipeline ha superato un limite di quota di BigQuery. La causa più probabile è una quota insufficiente nel progetto BigQuery di destinazione per gestire il volume di dati scritti.

Per convalidare questo problema utilizzando i log dei worker:

  1. Nella console Google Cloud , apri la pagina Dettagli job di Dataflow.
  2. Nel riquadro in basso, fai clic sulla scheda Log e seleziona Log worker.
  3. Cerca messaggi di errore che indicano che le risorse o le quote sono esaurite o che i limiti di frequenza sono stati superati (ad esempio RESOURCE_EXHAUSTED, 429 Too Many Requests, quotaExceeded o rateLimitExceeded).
  4. Esamina il messaggio di log per verificare quale operazione e quale limite di quota sono stati superati (ad esempio, i limiti di velocità effettiva o di connessione dell'API Storage Write AppendRows o i limiti di frequenza di inserimento di flussi di dati).

Per risolvere il problema:

  • Determina quale implementazione del sink BigQuery sta utilizzando la tua pipeline (ad esempio, l'API Storage Write o gli inserimenti di flussi di dati).
  • Esamina l'utilizzo della quota di BigQuery nella console Google Cloud . Cerca in particolare le quote relative al tipo di sink, ad esempio connessioni simultanee, throughput o righe di inserimento di flussi di dati al secondo.
  • Se ti avvicini o superi costantemente questi limiti, valuta la possibilità di richiedere un aumento della quota.

Se questi passaggi non identificano il limite specifico superato, consulta Risolvi gli errori relativi a quote e limiti per ulteriori indagini.

Errore RPC del sink BigQuery

Questo errore indica che le richieste RPC dalla pipeline a BigQuery non vanno a buon fine. Le potenziali cause includono problemi di rete o di servizio temporanei, payload di richiesta non validi, mancate corrispondenze dello schema o errori di timeout e scadenza superata.

Per convalidare questo problema utilizzando i log dei worker:

  1. Nella console Google Cloud , apri la pagina Dettagli job di Dataflow.
  2. Nel riquadro in basso, fai clic sulla scheda Log e seleziona Log worker.
  3. Cerca messaggi di errore o eccezioni relativi alle operazioni di scrittura di BigQuery (ad esempio DEADLINE_EXCEEDED, UNAVAILABLE, INVALID_ARGUMENT o errori di convalida dello schema).
  4. Esamina l'analisi dello stack e il messaggio di errore per determinare la modalità di errore specifica restituita dall'API BigQuery.

Per risolvere il problema:

  • Una volta identificato il messaggio di errore o il codice di stato specifico nei log dei worker, consulta il riferimento ai messaggi di errore di BigQuery per indicazioni sulla risoluzione dei problemi specifiche per l'errore.
  • Se la pipeline utilizza l'API Storage Write, consulta Gestione degli errori nella documentazione dell'API BigQuery Storage Write per informazioni sulla gestione di errori di scrittura e stream specifici.
Sink BigQuery limitato

Questa causa indica che le richieste di scrittura dalla pipeline a BigQuery vengono eseguite correttamente, ma presentano una latenza elevata o una limitazione. Questo problema si verifica quando la pipeline si avvicina alle quote di throughput o di byte in transito di BigQuery e BigQuery rallenta le richieste di scrittura per regolare il traffico oppure quando BigQuery riscontra una latenza di backend elevata.

Per convalidare questo problema:

  1. Nella console Google Cloud , apri la pagina Dettagli job di Dataflow.
  2. Fai clic sulla scheda Metriche job o Informazioni passaggio per verificare che il passaggio del sink BigQuery stia riscontrando un tempo di elaborazione elevato.
  3. Nella console Google Cloud , apri la pagina Quote e limiti di sistema per il progetto BigQuery di destinazione e controlla se l'utilizzo si sta avvicinando alle quote di scrittura di BigQuery.

Per risolvere il problema:

  • Determina quale implementazione del sink BigQuery utilizza la tua pipeline, ad esempio l'API Storage Write o gli inserimenti di flussi di dati.
  • Esamina l'utilizzo della quota di BigQuery nella console Google Cloud . Cerca in particolare le quote relative al tipo di sink, ad esempio la velocità effettiva di aggiunta dell'API Storage Write, le connessioni simultanee o le righe di inserimento di flussi di dati al secondo. Anche se le richieste non vanno a buon fine con errori di quota espliciti, BigQuery può limitarle quando l'utilizzo si avvicina ai limiti di quota.
  • Se ti avvicini costantemente a questi limiti, valuta la possibilità di richiedere un aumento della quota.

Se questi passaggi non identificano il limite specifico che si sta per raggiungere, consulta Risolvi gli errori relativi a quote e limiti per ulteriori indagini.

Tempi di elaborazione lunghi per tutte le operazioni

Le operazioni in questo calcolo richiedono costantemente molto tempo, il che suggerisce un problema all'interno di DoFn fornito dall'utente.

Questa causa è diversa da Operazioni con tempi di elaborazione lunghi; mentre quella causa influisce su alcune operazioni, questa causa indica che tutte le operazioni in questo calcolo sono interessate.

Controlla i log dei worker per individuare errori, eccezioni o analisi dello stack che indicano thread lenti o bloccati. Se utilizzi l'SDK Apache Beam per Python e le operazioni sono intrinsecamente a lunga esecuzione per progettazione (ad esempio, chiamate API esterne lente o I/O ad alta latenza), valuta la possibilità di utilizzare un DoFn asincrono. Questa funzionalità può migliorare la velocità effettiva impedendo il blocco dell'elaborazione di queste attività a lunga esecuzione.

Lettura lenta dello stato persistente

Il calcolo impiega una quantità significativa di tempo per leggere lo stato persistente nell'ambito dell'esecuzione di DoFn. Ciò potrebbe essere dovuto a uno stato persistente eccessivamente grande o a troppe letture. Valuta la possibilità di ridurre le dimensioni dello stato persistente o la frequenza delle letture. Ottimizza i pattern di accesso allo stato combinando più operazioni di lettura dello stato o utilizzando lo stato della mappa anziché lo stato del valore, se appropriato. Potrebbe anche trattarsi di un problema temporaneo dovuto alla lentezza dello stato persistente sottostante.

Scrittura lenta dello stato persistente

Il calcolo impiega una quantità significativa di tempo per scrivere lo stato persistente durante il commit dei risultati dell'elaborazione. Ciò potrebbe essere dovuto a uno stato persistente eccessivamente grande. Valuta la possibilità di ridurre le dimensioni dello stato persistente. Ottimizza i pattern di accesso allo stato combinando più operazioni di scrittura dello stato, se opportuno. Potrebbe anche trattarsi di un problema temporaneo dovuto alla lentezza dello stato persistente sottostante.

Commit rifiutato

Impossibile eseguire il commit del trattamento dati in uno stato persistente perché non è valido. In genere, questo è dovuto al superamento di uno dei limiti operativi. Per ulteriori dettagli, controlla i log o contatta l'assistenza.

Numero insufficiente di partizioni dell'origine Apache Kafka

Il calcolo dell'origine Apache Kafka non dispone di partizioni sufficienti. Per risolvere il problema, prova quanto segue:

  • Aumenta il numero di partizioni Kafka.
  • Includi la ridistribuzione utilizzando .withRedistribute() durante la configurazione della lettura di Kafka IO per parallelizzare i dati in modo più efficiente. Includi .withRedistributeNumKeys(N) dove N > partitions per fornire un limite superiore al numero totale di chiavi. Un numero limitato di chiavi garantisce l'efficienza grazie al raggruppamento dei record.
  • Per ridurre al minimo il costo dello shuffling di ridistribuzione, utilizza .withOffsetDeduplication(). Questa modalità riduce al minimo la quantità di dati che devono essere resi persistenti nell'ambito dello shuffle, pur fornendo un'elaborazione exactly-once.

Per saperne di più, consulta Parallelismo nella pagina Leggi da Apache Kafka a Dataflow.

Origine Apache Kafka con un volume elevato di stato persistente

Il calcolo dell'origine Apache Kafka sta ridistribuendo un volume elevato di dati che potrebbe comportare latenza e costi elevati. Per risolvere il problema, prova quanto segue:

  • Se per la pipeline è richiesta l'elaborazione exactly-once, riduci al minimo il costo dello shuffling di ridistribuzione utilizzando la modalità di deduplicazione dell'offset. Questa modalità riduce al minimo la quantità di dati che devono essere resi persistenti nell'ambito dello shuffle, pur fornendo un'elaborazione exactly-once.
  • Se l'elaborazione at-least-once è sufficiente per la pipeline, è possibile attivare la configurazione Consenti duplicati.

Per saperne di più, consulta Leggi da Apache Kafka a Dataflow.

Parallelismo origine insufficiente

Un calcolo dell'origine ha un parallelismo insufficiente. Se possibile, aumenta il caricamento in contemporanea all'interno dell'origine. Se non riesci ad aumentare la parallelizzazione e il job utilizza la modalità at-least-once, prova ad aggiungere una trasformazione Redistribute alla pipeline.

Hot key o parallelismo insufficiente delle chiavi

Il job ha hot key o un parallelismo delle chiavi insufficiente.

Per ogni chiave di sharding, Dataflow elabora i messaggi in serie. Mentre Dataflow elabora un batch di messaggi per una determinata chiave, gli altri messaggi in arrivo per quella chiave vengono messi in coda fino al completamento del batch corrente.

Se Dataflow non riesce a elaborare un numero sufficiente di chiavi distinte in parallelo, può verificarsi un collo di bottiglia. Ad esempio, i dati potrebbero avere un numero troppo ridotto di chiavi distinte o alcune chiavi potrebbero essere sovrarappresentate nei dati ("hot key"). Per risolvere il problema, modifica la logica della pipeline per ridistribuire i dati. Ad esempio, aggiungi un suffisso casuale alle chiavi di raggruppamento per suddividere le hot key e aggregare i risultati in un passaggio successivo. Per maggiori dettagli, consulta Risolvi i problemi relativi alle hot key.

Provisioning insufficiente delle vCPU

Il job non dispone di vCPU worker sufficienti. Questa situazione si verifica quando il job è già scalato al massimo, l'utilizzo della vCPU è elevato e c'è ancora un backlog. Potresti dover aumentare il numero massimo di worker di cui è stato eseguito il provisioning per questo job. Ad esempio, puoi aumentare questo numero con un aggiornamento dell'intervallo di scalabilità automatica. In alternativa, cerca modi per ridurre l'utilizzo delle vCPU modificando il codice della pipeline o il workload. Puoi utilizzare Cloud Profiler per cercare opportunità di ottimizzazione.

Utilizzo elevato della vCPU, in attesa di scale up

Il job ha un utilizzo elevato della vCPU, ma c'è spazio per lo scale up. È probabile che questa condizione sia temporanea fino a quando non sarà possibile eseguire lo scale up. Puoi monitorare la scalabilità automatica per visualizzare le relative decisioni. Se questa condizione persiste per molto tempo o si verifica di frequente, potrebbe essere necessario modificare la configurazione della scalabilità automatica impostando un suggerimento per l'utilizzo dei worker diverso per consentire al job di fare lo scale up in modo più proattivo.

Carico vCPU sbilanciato che crea colli di bottiglia su alcuni worker outlier

Il job ha un numero sufficiente di vCPU worker, ma alcuni worker mostrano un utilizzo molto elevato della vCPU. Questo è spesso causato da una distribuzione non uniforme del lavoro. Le possibili cause includono partizioni di origine caricate in modo non uniforme o hot key.

Per risolvere il problema, prova quanto segue:

  • Determina la causa del caricamento non uniforme e prova a correggerla. Ad esempio, assicurati che le partizioni di origine siano distribuite in modo uniforme.
  • Se non è possibile correggere il carico non uniforme, valuta la possibilità di modificare la forma della VM worker per aumentare le vCPU per worker e ridurre l'utilizzo di picco. Per saperne di più sulla configurazione delle vCPU per worker, consulta Configura le VM worker di Dataflow.
Problema di comunicazione con i worker

Dataflow non può comunicare con tutte le VM worker. Controlla lo stato delle VM worker del job. Le possibili cause includono:

  • Si è verificato un problema durante il provisioning delle VM worker.
  • Il pool di VM worker viene eliminato mentre il job è in esecuzione.
  • Problemi di Networking.
L'origine Pub/Sub ha errori di pull.

Si sono verificati errori durante il pull dall'origine Pub/Sub. Controlla che l'argomento e le sottoscrizioni richiesti esistano e verifica la quota e la configurazione. Puoi anche controllare i log per verificare la presenza di errori.

Origine Pub/Sub con parallelismo insufficiente

Il calcolo dell'origine Pub/Sub ha un numero insufficiente di chiavi Pub/Sub. Per aumentare il numero di chiavi, imposta l'opzione di servizio num_pubsub_keys. Per saperne di più, consulta Parallelismo dell'origine Pub/Sub.

Origine Pub/Sub limitata per motivi sconosciuti

Il calcolo dell'origine Pub/Sub è limitato durante la lettura da Pub/Sub per un motivo sconosciuto. Questo problema potrebbe essere temporaneo. Verifica la presenza di problemi di configurazione di Pub/Sub, autorizzazioni IAM mancanti o limiti di quota. Tuttavia, se nessuna delle aree precedenti è la causa principale e il problema persiste, contatta l'assistenza.

Pubblicazione del sink Pub/Sub lenta o bloccata

Il calcolo del sink Pub/Sub è lento o bloccato. Questo problema potrebbe essere causato da un problema di configurazione o da un limite di quota.

Tempo di coda di lavoro elevato

L'età del lavoro idoneo più vecchio è elevata a causa di un numero elevato di chiavi e della velocità con cui vengono elaborate. In questa situazione, ogni operazione potrebbe non essere eccessivamente lunga, ma il ritardo complessivo della coda è elevato.

Dataflow utilizza un singolo thread di elaborazione per chiave di sharding e il numero di thread di elaborazione è limitato. Il ritardo di accodamento è approssimativamente uguale al rapporto tra chiavi e thread, moltiplicato per la latenza on-thread per ogni bundle di elaborazione per una chiave:

(key count / total harness threads) * latency per bundle

Prova le seguenti correzioni:

Un problema temporaneo con il backend di Streaming Engine

Si è verificato un problema di configurazione o operativo con il backend di Streaming Engine. Questo problema potrebbe essere temporaneo. Se il problema persiste, contatta l'assistenza.

Impossibile determinare la causa

La causa del backlog non può essere determinata con certezza. Questo problema potrebbe essere temporaneo. Se il problema persiste, contatta l'assistenza.

Metriche dei colli di bottiglia

Le seguenti metriche dei job forniscono informazioni sui colli di bottiglia:

Passaggi successivi