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 lavoratori inattivi e a un aumento della latenza.

Se Dataflow rileva un collo di bottiglia, nel grafico del job viene visualizzato un avviso e nel pannello Informazioni passaggio viene elencato 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 una serie temporale. In questo modo puoi visualizzare i colli di bottiglia nel tempo o in passato.

Informazioni sui colli di bottiglia

Quando Dataflow esegue una pipeline di streaming, il job è costituito da una serie di componenti, come shuffling di streaming, thread di elaborazione funzione definita dall'utente'utente (DoFn) e checkpointing dello stato permanente. 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 velocità effettiva complessiva è limitata da un singolo componente, creando un collo di bottiglia nella pipeline. La velocità con cui i dati possono attraversare 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 di DoFn avviene a valle di un rimescolamento in streaming. Una coda tra loro memorizza i dati mischiati ma non elaborati. Se l'elaborazione DoFn non riesce a utilizzare i dati alla stessa velocità con cui vengono prodotti dallo shuffle in streaming, la coda aumenta. Un collo di bottiglia prolungato può causare il raggiungimento della capacità massima della coda. A questo punto, l'ulteriore rimescolamento viene messo in pausa e il backlog si propaga a monte. Anche le code più a monte accumulano backlog, causando infine 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 non integra, anche se è un singolo punto della pipeline a causare l'arretrato. 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 da parte tua e dipende dal tuo caso d'uso. Una pipeline può funzionare normalmente con ritardi temporanei superiori a 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 completamente interrotto in questo passaggio.
L'elaborazione è in corso, ma è in ritardo.
La pipeline non riesce a elaborare i dati in arrivo alla stessa velocità con cui arrivano. Di conseguenza, la coda è in aumento.
L'elaborazione è in corso, ma il backlog è stabile
La pipeline sta facendo progressi 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 diminuisce 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 l'avanzamento per vedere se il backlog continua a diminuire.

Cause dei colli di bottiglia

Questa sezione elenca le cause dei colli di bottiglia che possono essere rilevate. Utilizza queste informazioni per risolvere il problema. In alcuni casi, potrebbero essere presenti più cause e potrebbero essere correlate. Ad esempio, se i worker sono sottoprovvigionati, 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 in questo calcolo hanno un tempo di elaborazione lungo. Ciò si verifica ogni volta che un bundle di input viene inviato al worker che esegue DoFn e dopo un periodo di tempo significativo senza che siano disponibili risultati.

Il più delle volte, questo è 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 riprovati all'interno di DoFn, i nuovi tentativi per lunghi periodi di tempo o gli arresti anomali del worker harness dovuti a fattori quali gli errori di memoria 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 le operazioni bloccate per più di 5 minuti.

Key commit troppo grande

Consulta Eccezione relativa al commit della chiave troppo grande.

Autorizzazione sink BigQuery negata

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

Per convalidare il problema utilizzando i log dei worker:

  1. Nella console Google Cloud , apri la pagina Dettagli job di Dataflow.
  2. Nel riquadro inferiore, fai clic sulla scheda Log e seleziona Log worker.
  3. Cerca messaggi di errore che suggeriscono che le autorizzazioni o l'accesso sono 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 specifica mancante (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) per la tabella e il set di dati di destinazione.
  • Se scrivi tra progetti diversi, assicurati che le autorizzazioni siano 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 e autorizzazioni predefiniti di BigQuery per identificare e concedere le autorizzazioni granulari mancanti richieste 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 il problema utilizzando i log dei worker:

  1. Nella console Google Cloud , apri la pagina Dettagli job di Dataflow.
  2. Nel riquadro inferiore, fai clic sulla scheda Log e seleziona Log worker.
  3. Cerca messaggi di errore che suggeriscano 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 limite di quota è stato superato (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 utilizza la tua pipeline (ad esempio l'API Storage Write o gli inserimenti in streaming).
  • Esamina l'utilizzo della quota 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 la sezione Risolvere gli errori relativi a quote e limiti per ulteriori accertamenti.

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 delle richieste non validi, mancata corrispondenza dello schema o errori di timeout e scadenza superati.

Per convalidare il problema utilizzando i log dei worker:

  1. Nella console Google Cloud , apri la pagina Dettagli job di Dataflow.
  2. Nel riquadro inferiore, fai clic sulla scheda Log e seleziona Log worker.
  3. Cerca messaggi di errore o eccezioni relativi alle operazioni di scrittura 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 per la risoluzione dei problemi specifiche per l'errore.
  • Se la pipeline utilizza l'API Storage Write, consulta la sezione Gestione degli errori nella documentazione dell'API BigQuery Storage Write per informazioni sulla gestione di errori di scrittura e flusso specifici.
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 questa 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 se le operazioni sono intrinsecamente a esecuzione prolungata per progettazione (ad esempio chiamate API esterne lente o I/O a latenza elevata), valuta la possibilità di utilizzare un Async DoFn. Questa funzionalità può migliorare la velocità effettiva impedendo il blocco dell'elaborazione di queste attività a esecuzione prolungata.

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 il risultato di uno stato persistente eccessivamente grande o di 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 opportuno. Potrebbe anche trattarsi di un problema temporaneo dovuto alla lentezza dello stato persistente sottostante.

Scrittura lenta dello stato persistente

Il calcolo richiede una quantità significativa di tempo per scrivere lo stato persistente durante il commit dei risultati dell'elaborazione. Ciò potrebbe essere il risultato di 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

L'elaborazione dei dati non può essere eseguita in modo permanente perché non è valida. Ciò è dovuto in genere al superamento di uno dei limiti operativi. Controlla i log per ulteriori dettagli o contatta l'assistenza.

Numero insufficiente di partizioni dell'origine Apache Kafka

Il calcolo dell'origine Apache Kafka ha partizioni insufficienti. 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 efficienza tramite il 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 deve essere mantenuta nell'ambito del data shuffling, fornendo comunque l'elaborazione esattamente una volta.

Per saperne di più, consulta la sezione Parallelismo nella pagina Leggere 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 è necessario l'elaborazione esatta per la pipeline, 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 deve essere mantenuta nell'ambito del data shuffling, fornendo comunque l'elaborazione esattamente una volta.
  • Se l'elaborazione almeno una volta è sufficiente per la pipeline, è possibile attivare la configurazione Consenti duplicati.

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

Parallelismo origine insufficiente

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

Chiavi utilizzate di frequente o parallelismo insufficiente delle chiavi

Il job ha tasti di scelta rapida o parallelismo insufficiente delle chiavi.

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 in parallelo un numero sufficiente di chiavi distinte, può causare un collo di bottiglia. Ad esempio, i dati potrebbero avere un numero insufficiente di chiavi distinte o alcune chiavi potrebbero essere sovra rappresentate nei dati ("hot keys"). Per risolvere questo problema, modifica la logica della pipeline per ridistribuire i dati. Ad esempio, aggiungi un suffisso casuale alle chiavi di raggruppamento per separare i tasti di scelta rapida e aggregare i risultati in un passaggio successivo. Per maggiori dettagli, consulta la sezione Risolvere i problemi relativi alle scorciatoie da tastiera.

Provisioning insufficiente delle vCPU

Il job non ha un numero sufficiente di vCPU worker. Questa situazione si verifica quando il job è già scalato al massimo, l'utilizzo della vCPU è elevato e c'è ancora un arretrato. Potresti dover aumentare il numero massimo di worker di cui è stato eseguito il provisioning per questo job. Ad esempio, potresti 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. Questa condizione è probabilmente transitoria finché non è possibile eseguire l'upscaling. Puoi monitorare la scalabilità automatica per visualizzare le decisioni di scalabilità automatica. Se questa condizione persiste a lungo o si verifica di frequente, potrebbe essere necessario modificare la configurazione della scalabilità automatica impostando un diverso suggerimento sull'utilizzo dei worker per consentire al job di aumentare le risorse 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 delle vCPU. Ciò è spesso causato da una distribuzione del lavoro non uniforme. Le potenziali cause includono partizioni di origine caricate in modo non uniforme o tasti di scelta rapida.

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 la correzione del carico non uniforme non è fattibile, 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 Dataflow.
Problema di comunicazione con i worker

Dataflow non riesce a 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 durante l'esecuzione del job.
  • Problemi di Networking.
L'origine Pub/Sub ha errori di pull.

Si sono verificati errori durante il pull dall'origine Pub/Sub. Controlla che esistano l'argomento e gli abbonamenti richiesti e verifica la quota e la configurazione. Puoi anche controllare i log per individuare eventuali 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 viene limitato durante la lettura da Pub/Sub per un motivo sconosciuto. Questo problema potrebbe essere temporaneo. Controlla 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à di lavoro idonea più vecchia è elevata a causa del numero elevato di chiavi e della velocità con cui vengono elaborate. In questa situazione, ogni operazione potrebbe non essere anormalmente 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 soluzioni:

  • Aumenta il numero di worker. Vedi Scalabilità automatica dello streaming.
  • Aumenta il numero di thread worker harness. Imposta l'opzione pipeline numberOfWorkerHarnessThreads / number_of_worker_harness_threads.
  • Diminuisci il numero di chiavi.
  • Ridurre la latenza dell'operazione.
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 di collo di bottiglia

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

Passaggi successivi