Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Risolvere i problemi relativi ai job di streaming lenti o bloccati

Questa pagina spiega come risolvere le cause comuni dei job di flussi di dati Dataflow lenti o bloccati.

Se noti i seguenti sintomi, il job di flussi di dati Dataflow potrebbe essere lento o bloccato:

La pipeline non legge i dati dall'origine. Ad esempio, Pub/Sub ha un backlog in crescita.
La pipeline non scrive i dati nel sink.
La metrica di aggiornamento dei dati è in aumento.
La metrica di latenza del sistema è in aumento.

Utilizza le informazioni nelle sezioni seguenti per identificare e diagnosticare il problema.

Identifica la causa principale

Controlla le metriche di aggiornamento dei dati e dei byte di backlog.
- Se entrambe le metriche aumentano in modo monotono, significa che la pipeline è bloccata e non sta progredendo.
- Se l'aggiornamento dei dati è in aumento, ma i byte di backlog rimangono normali, significa che uno o più elementi di lavoro sono bloccati nella pipeline.
Cerca le fasi in cui queste metriche sono in aumento per identificare eventuali fasi con problemi e le operazioni eseguite in quella fase.
Controlla il grafico di elaborazione parallela per verificare se una fase è bloccata a causa di un parallelismo eccessivo o insufficiente. Consulta Risolvere i problemi di parallelismo.
Controlla i log dei job per verificare la presenza di problemi come limiti di quota, problemi di esaurimento delle scorte o esaurimento degli indirizzi IP.
Controlla i log dei worker per verificare la presenza di avvisi ed errori.
- Se i log dei worker contengono errori, visualizza l'analisi dello stack. Verifica se l'errore è causato da un bug nel codice.
- Cerca gli errori di Dataflow. Consulta Risolvere i problemi relativi agli errori di Dataflow.
- Cerca gli errori che indicano che il job ha superato un limite, ad esempio la dimensione massima dei messaggi Pub/Sub.
- Cerca gli errori di memoria insufficiente, che possono causare il blocco di una pipeline. Se visualizzi errori di memoria insufficiente, segui i passaggi descritti in Risolvere i problemi relativi agli errori di memoria insufficiente di Dataflow.
- Per identificare un passaggio lento o bloccato, controlla i log dei worker per verificare la presenza di messaggi Operation ongoing. Visualizza l'analisi dello stack per vedere dove il passaggio sta impiegando tempo. Per saperne di più, consulta Elaborazione bloccata o operazione in corso.
Se un elemento di lavoro è bloccato su un worker specifico, riavvia la VM worker.
Se non utilizzi Streaming Engine, controlla i log di shuffler per verificare la presenza di avvisi e errori. Se visualizzi un errore di timeout RPC sulla porta 12345 o 12346, è possibile che al job manchi una regola firewall. Consulta Regole firewall per Dataflow.
Verifica la presenza di chiavi utilizzate di frequente.
Se il runner portatile è abilitato, controlla i log dell'harness per verificare la presenza di errori. Per saperne di più, consulta Risolvere i problemi relativi al runner portatile.

Esamina gli errori ripetuti

In un job di flussi di dati, alcuni errori vengono ritentati indefinitamente. Questi tentativi impediscono l'avanzamento della pipeline. Per identificare gli errori ripetuti, controlla i log dei worker per verificare la presenza di eccezioni.

Se l'eccezione riguarda il codice utente, esegui il debug e correggi il problema nel codice o nei dati.
Per evitare che errori imprevisti blocchino la pipeline, implementa una coda di messaggi non recapitabili. Per un'implementazione di esempio, consulta Pattern di BigQuery nella documentazione di Apache Beam.
Se l'eccezione è un errore di out of memory (OOM), consulta Risolvere i problemi relativi agli errori di out of memory di Dataflow.
Per altre eccezioni, consulta Risolvere i problemi relativi agli errori di Dataflow.

Identifica i worker non integri

Se i worker che elaborano il job di flussi di dati non sono integri, il job potrebbe essere lento o sembrare bloccato. Per identificare i worker non integri:

Verifica la presenza di pressione sulla memoria utilizzando le metriche di utilizzo della memoria e cercando errori di out of memory nei log dei worker. Per saperne di più, consulta Risolvere i problemi relativi agli errori di memoria insufficiente di Dataflow.
Se utilizzi Streaming Engine, utilizza le metriche di persistenza per identificare i colli di bottiglia con le operazioni di input/output del disco (IOPS).
Controlla i log dei worker per verificare la presenza di altri errori. Per saperne di più, consulta Utilizzare i log delle pipeline e Risolvere i problemi relativi agli errori di Dataflow.

Identifica gli elementi in ritardo

Un elemento in ritardo è un elemento di lavoro lento rispetto ad altri elementi di lavoro nella fase. Per informazioni su come identificare e correggere gli elementi in ritardo, consulta Risolvere i problemi relativi agli elementi in ritardo nei job di flussi di dati.

Risolvi i problemi di parallelismo

Per scalabilità ed efficienza, Dataflow esegue le fasi della pipeline in parallelo su più worker. L'unità più piccola di elaborazione parallela in Dataflow è una chiave. I messaggi in entrata per ogni fase unita sono associati a una chiave. La chiave è definita in uno dei seguenti modi:

La chiave è definita implicitamente dalle proprietà dell'origine, ad esempio le partizioni Kafka.
La chiave è definita esplicitamente dalla logica di aggregazione nella pipeline, ad esempio GroupByKey.

In Dataflow, i thread worker sono responsabili della gestione dell'elaborazione dei bundle di lavoro (messaggi) per una chiave. Il numero di thread disponibili per elaborare le chiavi del job è uguale a num_of_workers * threads_per_worker. Il conteggio dei thread per worker viene determinato in base all'SDK (Java, Python o Go) e al tipo di prestazione (batch o flussi di dati).

Se la pipeline non ha un numero sufficiente di chiavi per una determinata fase, limita l'elaborazione parallela. Questa fase potrebbe diventare un collo di bottiglia.

Se la pipeline utilizza un numero molto elevato di chiavi per una determinata fase, può limitare la velocità effettiva della fase e accumulare backlog nelle fasi a monte, perché è presente un overhead per chiave. L'overhead potrebbe includere la comunicazione del backend con i worker, le RPC esterne a un sink come BigQuery e altre elaborazioni. Ad esempio, se l'elaborazione di una chiave con un messaggio richiede 100 ms, potrebbe essere necessario anche circa 100 ms per elaborare 1000 messaggi nel bundle di chiavi.

Identifica le fasi con parallelismo basso

Per verificare se la lentezza della pipeline è causata da un parallelismo basso, visualizza le metriche di utilizzo della CPU. Se la CPU è bassa ma distribuita uniformemente tra i worker, è possibile che il job abbia un parallelismo insufficiente. Se il job utilizza Streaming Engine, per verificare se una fase ha un parallelismo basso, nella scheda Metriche job visualizza le metriche di parallelismo. Per risolvere questo problema:

Nella Google Cloud console, nella pagina Informazioni job, utilizza la scheda Scalabilità automatica per verificare se il job ha problemi di scalabilità orizzontale. Se il problema è la scalabilità automatica, consulta Risolvere i problemi relativi alla scalabilità automatica di Dataflow.
Utilizza il grafico dei job per controllare i passaggi in fase. Se la fase legge da un'origine o scrive in un sink, consulta la documentazione del servizio dell'origine o del sink. Utilizza la documentazione per determinare se il servizio è configurato per una scalabilità sufficiente.
- Per raccogliere ulteriori informazioni, utilizza le metriche di input e output fornite da Dataflow.
- Se utilizzi Kafka, controlla il numero di partizioni Kafka. Per saperne di più, consulta la documentazione di Apache Kafka.
- Se utilizzi un sink BigQuery, attiva lo sharding automatico per migliorare il parallelismo. Per saperne di più, consulta Velocità effettiva di Dataflow 3 volte superiore con lo sharding automatico per BigQuery.

Identifica le fasi con parallelismo elevato

Una combinazione di bassa latenza del sistema, aumento dell'aggiornamento dei dati e aumento del backlog e delle CPU worker sottoutilizzate suggerisce che la pipeline è soggetta a limitazione a causa di un numero elevato di chiavi. Controlla il grafico di elaborazione parallela per identificare le fasi con un numero elevato di chiavi.

Le trasformazioni come Reshuffle possono generare milioni di chiavi se non specifichi esplicitamente withNumBuckets. Un numero elevato di chiavi può portare alla creazione di numerosi bundle di lavoro più piccoli, ognuno dei quali richiede un thread di lavoro dedicato per l'elaborazione. Poiché i thread worker disponibili sono limitati, può verificarsi un backlog significativo di chiavi di elaborazione, causando ritardi durante l'attesa delle risorse. Di conseguenza, i thread worker non vengono utilizzati in modo efficiente.

Ti consigliamo di limitare il numero di chiavi impostando l'opzione withNumBuckets nella trasformazione Reshuffle. Il valore non deve superare il numero totale di thread in tutti i worker. Il targeting di (threads_per_worker * max_workers) chiavi nella pipeline potrebbe non essere ottimale. A volte sono possibili meno chiavi e bundle più grandi, che vengono elaborati in modo più efficiente da Dataflow grazie all'utilizzo di un numero inferiore di worker. Un numero inferiore di chiavi crea bundle di lavoro più grandi, che utilizzano in modo efficiente i thread worker e aumentano la velocità effettiva della fase.

Se nella pipeline sono presenti più passaggi Reshuffle, dividi il numero totale di thread per il conteggio dei passaggi Reshuffle per calcolare withNumBuckets.

Verifica la presenza di chiavi utilizzate di frequente

Se le attività non sono distribuite uniformemente tra i worker e l'utilizzo dei worker è molto irregolare, è possibile che la pipeline abbia una chiave utilizzata di frequente. Una chiave utilizzata di frequente è una chiave sovra rappresentata nei dati.

Controlla se la pipeline ha chiavi utilizzate di frequente esaminando lo stato del collo di bottiglia per il passaggio lento. Potresti avere chiavi utilizzate di frequente se il motivo del collo di bottiglia è "Chiavi utilizzate di frequente o parallelismo insufficiente delle chiavi". Per informazioni generali sui colli di bottiglia, consulta Risolvere i problemi relativi ai colli di bottiglia.

Per impostazione predefinita, Dataflow registra solo la presenza di una chiave utilizzata di frequente, non il valore della chiave specifica. Per stampare la chiave leggibile nei log quando viene rilevata una chiave utilizzata di frequente, imposta la seguente opzione della pipeline di debug quando esegui la pipeline:

Java

--hotKeyLoggingEnabled=true

Python

--dataflow_service_options=enable_hot_key_logging

Se esegui un job del modello flessibile, consulta Specificare le opzioni della pipeline per saperne di più sull'utilizzo di --additional-pipeline-options per passare l'opzione.

Quindi, controlla la presenza di chiavi utilizzate di frequente utilizzando il seguente filtro dei log:

  resource.type="dataflow_step"
  resource.labels.job_id=JOB_ID
  jsonPayload.logger="org.apache.beam.runners.dataflow.worker.HotKeyLogger"

Sostituisci JOB_ID con l'ID del job.

Puoi anche configurare gli avvisi basati su log per ricevere una notifica quando vengono rilevate chiavi utilizzate di frequente nella pipeline. Utilizza il filtro di esempio come punto di partenza.

Per risolvere il problema, segui uno o più dei seguenti passaggi:

Esegui una nuova chiave dei dati. Per generare nuove coppie chiave-valore, applica una trasformazione ParDo. Per saperne di più, consulta la pagina della trasformazione Java ParDo o la pagina della trasformazione Python ParDo nella documentazione di Apache Beam.
Utilizza .withFanout nelle trasformazioni di combinazione. Per saperne di più, consulta la Combine.PerKey classe nell'SDK Java o l' with_hot_key_fanout operazione nell'SDK Python.
Se hai una pipeline Java che elabora PCollections illimitate di volumi elevati, ti consigliamo di:
- Utilizza Combine.Globally.withFanout anziché Combine.Globally.
- Utilizza Combine.PerKey.withHotKeyFanout anziché Count.PerKey.

Verifica la presenza di una quota insufficiente

Assicurati di avere una quota sufficiente per l'origine e il sink. Ad esempio, se la pipeline legge l'input da Pub/Sub o BigQuery, il tuo Google Cloud progetto potrebbe avere una quota insufficiente. Per saperne di più sui limiti di quota per questi servizi, consulta Quota Pub/Sub o Quota BigQuery.

Se il job genera un numero elevato di errori 429 (Rate Limit Exceeded), è possibile che la quota sia insufficiente. Per verificare la presenza di errori, prova a seguire questi passaggi:

Vai alla Google Cloud console.
Nel riquadro di navigazione, fai clic su API e servizi.
Nel menu, fai clic su Raccolta.
Utilizza la casella di ricerca per cercare Pub/Sub.
Fai clic su API Cloud Pub/Sub.
Fai clic su Gestisci.
Nel grafico Traffico per codice di risposta, cerca i codici di errore client (4xx).

Puoi anche utilizzare Esplora metriche per controllare l'utilizzo della quota. Se la pipeline utilizza un'origine o un sink BigQuery, per risolvere i problemi relativi alla quota, utilizza le metriche dell'API BigQuery Storage. Ad esempio, per creare un grafico che mostra il conteggio delle connessioni simultanee di BigQuery, segui questi passaggi:

Nella Google Cloud console, seleziona Monitoraggio:

Vai a Monitoraggio
Nel riquadro di navigazione, seleziona Metrics Explorer.
Nel riquadro Seleziona una metrica, per Metrica, filtra per Progetto BigQuery > Scrivi > conteggio connessioni simultanee.

Per istruzioni sulla visualizzazione delle metriche Pub/Sub, consulta Monitorare l'utilizzo della quota in "Monitorare Pub/Sub in Cloud Monitoring." Per istruzioni sulla visualizzazione delle metriche BigQuery, consulta Visualizzare l'utilizzo e i limiti della quota in "Creare dashboard, grafici e avvisi".

Strumenti per il debug

Quando hai una pipeline lenta o bloccata, i seguenti strumenti possono aiutarti a diagnosticare il problema.

Per correlare gli incidenti e identificare i colli di bottiglia, utilizza Cloud Monitoring per Dataflow.
Per monitorare il rendimento della pipeline, utilizza Cloud Profiler.
Alcune trasformazioni sono più adatte alle pipeline di volumi elevati rispetto ad altre. I messaggi di log possono identificare una trasformazione utente bloccata nelle pipeline batch o di flussi di dati.
Per saperne di più su un job bloccato, utilizza le metriche dei job Dataflow. Il seguente elenco include metriche utili:
- La metrica Byte di backlog (backlog_bytes) misura la quantità di input non elaborato in byte per fase. Utilizza questa metrica per trovare un passaggio unito che non ha velocità effettiva. Allo stesso modo, la metrica Elementi di backlog (backlog_elements) misura il numero di elementi di input non elaborati per una fase.
- La metrica Chiavi di parallelismo di elaborazione (processing_parallelism_keys) misura il numero di chiavi di elaborazione parallela per una determinata fase della pipeline negli ultimi cinque minuti. Utilizza questa metrica per esaminare i seguenti aspetti:
  - Limita il problema a fasi specifiche e conferma gli avvisi relativi alle chiavi utilizzate di frequente, ad esempio A hot key ... was detected.
  - Trova i colli di bottiglia della velocità effettiva causati da un parallelismo insufficiente. Questi colli di bottiglia possono causare pipeline lente o bloccate.
- La metrica Ritardo sistema (system_lag) e la metrica di ritardo del sistema per fase (per_stage_system_lag) misurano la quantità massima di tempo in cui un elemento di dati è stato elaborato o è in attesa di elaborazione. Utilizza queste metriche per identificare le fasi inefficienti e i colli di bottiglia delle origini dati.

Per altre metriche non incluse nell'interfaccia web di monitoraggio di Dataflow, consulta l'elenco completo delle metriche di Dataflow in Google Cloud metriche.

Risolvere i problemi relativi ai job di streaming lenti o bloccati Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.