Risoluzione dei problemi di scalabilità automatica di Dataflow

Questa pagina mostra come risolvere i problemi relativi all' Funzionalità di scalabilità automatica di Dataflow e fornisce informazioni su come gestire la scalabilità automatica.

Il job non fa lo scale up o lo scale down

Questa sezione fornisce informazioni su scenari che potrebbero impedire ai lavoratori di eseguire il ridimensionamento.

Il job di flusso non fa lo scale up

Quando la pipeline in modalità flusso ha un backlog, i worker non fanno lo scale up.

Questo problema si verifica quando la coda dura meno di qualche minuto o quando i worker utilizzano meno del 20% delle CPU.

A volte, la coda è elevata, ma l'utilizzo della CPU è basso. Poiché alcune attività non richiedono un elevato utilizzo della CPU, l'aggiunta di worker non migliora le prestazioni. In questi casi, Dataflow non fa lo scale up. Per ulteriori informazioni, consulta la sezione Scalabilità automatica di streaming. Questo scenario potrebbe verificarsi per i seguenti motivi:

• La pipeline è ad alta intensità di I/O.
• La pipeline è in attesa di chiamate RPC esterne.
• I tasti di scelta rapida causano un utilizzo non uniforme della CPU del worker.
• La pipeline non ha chiavi sufficienti.

Lo scale up dei job batch e in flussi non viene fatto

Il job batch o in streaming viene eseguito come previsto, ma quando sono necessari più worker, il job non viene scalato.

Questo problema potrebbe verificarsi per uno dei seguenti motivi:

• I file di staging o temporanei non sono accessibili. Se il job utilizza un bucket Cloud Storage, il bucket potrebbe avere una configurazione del ciclo di vita che elimina gli oggetti al suo interno. Gli oggetti eliminati includono cartelle e file temporanei e di gestione temporanea. Per verificare se i file sono stati eliminati, controlla la configurazione del ciclo di vita del bucket. Se le cartelle o i file temporanei o di gestione temporanea sono stati eliminati dopo l'avvio del job, i pacchetti necessari per creare nuovi worker potrebbero non esistere. Per risolvere il problema, ricrea le cartelle e i file nel bucket.
• Le regole firewall impediscono ai worker di inviare e ricevere traffico sulle porte TCP necessarie. Le regole firewall potrebbero impedire l'avvio dei worker. I worker Dataflow devono essere in grado di inviare e ricevere traffico sulle porte TCP 12345 e 12346. Per ulteriori informazioni, inclusi i passaggi per risolvere il problema, consulta Regole firewall per Dataflow.
• Un'origine personalizzata ha un metodo getProgress() che restituisce un valore NULL. Quando utilizzi un'origine personalizzata, le metriche del backlog si basano su Il valore restituito del metodo getProgress() dell'origine personalizzata per iniziare a raccogliere i dati. Il valore predefinito l'implementazione di getProgress() restituisce un valore NULL. Per risolvere il problema, assicurati che l'origine personalizzata sostituisca il metodo getProgress() predefinito per restituire un valore non NULL.
• Un aggiornamento attivato dalla scalabilità automatica verticale disattiva temporaneamente la scalabilità automatica orizzontale. Per ulteriori informazioni, vedi Effetto sulla scalabilità automatica orizzontale.
• Se utilizzi un'operazione map in una pipeline Python e il job non fare lo scale up, potresti dover aggiungere trasformazione Reshuffle al codice della pipeline. Per ulteriori informazioni, consulta Riordina nella documentazione di Apache Beam.

Il job di streaming non esegue lo scale down

Se il job di flussi di dati ha un backlog basso e un basso utilizzo di CPU, dei worker non fanno fare lo scale down. Il problema può verificarsi per vari motivi.

• Quando i job non utilizzano Streaming Engine, Dataflow bilancia il numero di istanze tra i worker. Di conseguenza, ogni worker deve avere un numero uguale di dischi permanenti. Ad esempio, se ci sono 100 dischi e 100 worker, ogni worker ha un disco. Quando il job viene ridotto, può avere 50 worker con due dischi permanenti per worker. Il job non farà di nuovo fare lo scale down fino a quando non potrà avere 25 worker con quattro dischi permanenti per worker. Inoltre, il numero minimo di worker è il valore assegnato a maxNumWorkers diviso per 15. Per maggiori informazioni, consulta Intervallo di scalabilità per le pipeline di scalabilità automatica in modalità flusso.

• Quando i job utilizzano Streaming Engine, il target del downgrade si basa su un utilizzo target della CPU del 75%. Quando non è possibile ottenere l'utilizzo della CPU, il downscaling è disabilitato.

• La stima del tempo di backlog deve rimanere al di sotto dei dieci secondi per almeno due minuti prima che i worker vengano fare lo scale down. Le fluttuazioni nel tempo di backlog potrebbero disabilitare lo scale down. Inoltre, una bassa velocità effettiva può alterare la stima del tempo.

• Quando la pipeline utilizza PeriodicImpulse, I worker Dataflow non eseguono lo fare lo scale down come previsto. L'utilizzo di PeriodicImpulse non è supportato con la scalabilità automatica dello streaming.

Aumentare il numero di fermate

Il job batch o flusso inizia a eseguire lo scale up, ma i worker interrompono lo scale up anche se rimane un backlog.

Questo problema si verifica quando vengono raggiunti i limiti di quota.

• Quote di Compute Engine: i job Dataflow sono soggetti a la quota di Compute Engine del progetto. Se sono in esecuzione più job, il progetto potrebbe essere al limite della quota Compute Engine. In questo caso, Dataflow non può aumentare il numero di worker.
• Quote CPU: anche i job Dataflow sono soggetti a alla quota CPU del progetto. Se il tipo di worker utilizza più di una CPU, il progetto potrebbe essere al limite della quota CPU.
• Quote di indirizzi IP esterni: quando il job utilizza indirizzi IP esterni per comunicare con le risorse, hai bisogno di tanti indirizzi IP esterni quanti sono i worker. Con lo scale up del numero di worker, aumenta anche il numero di indirizzi IP esterni. Quando raggiungi il limite di indirizzi IP, i worker smettono di fare lo scale up.

Inoltre, se la regione che scegli non contiene più una risorsa, non potrai creare nuove risorse di quel tipo, anche se disponi di quota rimanente nella regione o nel progetto. Ad esempio, potresti disporre di una quota sufficiente per creare indirizzi IP esterni in us-central1, ma questa regione potrebbe non dispongono di indirizzi IP. Per ulteriori informazioni, consulta Quote e disponibilità delle risorse.

Per risolvere il problema, richiedi un aumento della quota o esegui il job in un'altra regione.

Il suggerimento per l'utilizzo del worker non ha effetto

Hai impostato suggerimento utilizzo worker ma il comportamento della scalabilità automatica non cambia.

Per comprendere il problema, vai al Grafico sull'utilizzo della CPU dei worker e controllare se l'hint per l'utilizzo del worker è in uso. Se il suggerimento viene utilizzato, il grafico mostra CPU utilization hint (actively used by autoscaler). In caso contrario, viene visualizzato CPU utilization hint (not actively used by autoscaler).

Il suggerimento sull'utilizzo è solo uno dei fattori che influisce sulla scalabilità automatica. Le seguenti nella tabella sono elencati alcuni motivi per cui il gestore della scalabilità automatica potrebbe non utilizzare attivamente il suggerimento:

Comportamento di scalabilità osservato	Cause	Metriche da controllare
Nessuna modifica	Hai raggiunto il numero minimo o massimo di worker. Il numero di worker è limitato dal numero di chiavi elaborate in parallelo. I job sono limitati da RPC esterne. La regolazione del downscaling è troppo piccola o Dataflow sta riducendo il ridimensionamento. Per ulteriori informazioni, consulta Algoritmi di euristica per la scalabilità automatica di streaming.	job/aggregated_worker_utilization job/max_worker_instances_limit job/min_worker_instances_limit job/processing_parallelism_keys Errori RPC segnalati nei log degli errori del worker Arresti anomali segnalati nei log dei worker
Scale up	L'obiettivo di backlog o latenza elevato ha sostituito il suggerimento. Il numero minimo di worker è stato aggiornato a un valore superiore a il numero attuale di worker.	job/aggregated_worker_utilization job/backlog_bytes job/backlog_elements job/estimated_timer_backlog_processing_time job/min_worker_instances_limit
Scalabilità verso il basso	Il numero massimo di worker è stato aggiornato a un valore inferiore a il numero attuale di worker.	job/aggregated_worker_utilization job/max_worker_instances_limit

Per ulteriori informazioni, consulta Euristiche di scalabilità automatica in streaming.

Lacune nelle metriche di scalabilità automatica

Esistono brevi lacune temporanee nelle metriche di scalabilità automatica.

Questo problema può verificarsi se le attività di backend vengono riavviate. Queste lacune nelle metriche non indicano un problema con la scalabilità automatica o con lo stato del job in streaming.

La CPU è distribuita in modo non uniforme

Con la scalabilità automatica del job, l'utilizzo della CPU è distribuito in modo non uniforme tra i worker. Alcuni worker hanno un utilizzo della CPU, una latenza del sistema o una frequenza di aggiornamento dei dati più elevati rispetto ad altri.

Questo problema può verificarsi se i dati contengono una hot key. Una hot key è una chiave con elementi sufficienti per influire negativamente sul rendimento della pipeline. Ogni chiave deve essere elaborato da un singolo worker, quindi il lavoro non può essere suddiviso tra worker.

Per ulteriori informazioni, consulta le linee guida relative agli errori delle hot key.

La lettura dello stato della richiesta dell'elemento di lavoro non è più valida nel backend

Durante la comunicazione tra istanze VM worker e attività di Streaming Engine in un pipeline di flusso, si verifica il seguente errore:

The work item requesting state read is no longer valid on the backend.
The work has already completed or will be retried.
This is expected during autoscaling events.

Durante l'autoscaling, le istanze VM worker comunicano con più attività Streaming Engine e ogni attività serve più istanze VM worker. Le chiavi elemento vengono utilizzate per distribuire il lavoro. Ogni istanza VM di attività e worker ha una raccolta di intervalli di chiavi e la distribuzione di questi intervalli può cambiare dinamicamente. Ad esempio, durante la scalabilità automatica, il ridimensionamento dei job può causare la variazione della distribuzione dell'intervallo di chiavi. Questo errore può verificarsi quando un intervallo di chiavi viene modificato. L'errore è previsto e, a meno che non riscontri una correlazione tra questi messaggi e una pipeline con prestazioni inferiori al previsto, puoi ignorarlo.

Risorse Streaming Engine insufficienti

Se Streaming Engine non può allocare il numero minimo di worker che viene restituito il seguente errore:

Streaming Engine does not currently have enough resources available to fulfill
the request.

Per risolvere il problema, prova a impostare un numero minimo di worker inferiore. Consulta Impostare l'intervallo di scalabilità automatica.

Intervallo di scalabilità per le pipeline di scalabilità automatica in modalità flusso

Questa sezione fornisce dettagli sull'intervallo di scalabilità per le pipeline di scalabilità automatica streaming.

Java

Per i job di scalabilità automatica dei flussi di dati che non utilizzano Streaming Engine, Il servizio Dataflow alloca da 1 a 15 dischi permanenti a per ciascun worker. Questa allocazione significa che il numero minimo i worker utilizzati per una pipeline di scalabilità automatica in modalità flusso è N/15, dove N è il valore di --maxNumWorkers.

Per i job di scalabilità automatica dei flussi di dati che utilizzano Motore di flussi di dati il numero minimo di worker è 1.

Dataflow bilancia il numero di dischi permanenti tra worker. Ad esempio, se la pipeline richiede tre o quattro worker in stato steady, puoi impostare --maxNumWorkers=15. La pipeline scala automaticamente tra 1 e 15 worker, utilizzando 1, 2, 3, 4, 5, 8 o 15 worker, che corrispondono rispettivamente a 15, 8, 5, 4, 3, 2 o 1 dischi rigidi permanenti per worker.

--maxNumWorkers può essere al massimo 1000.

Python

Per i job di scalabilità automatica dei flussi di dati che non utilizzano Streaming Engine, Il servizio Dataflow alloca da 1 a 15 dischi permanenti a per ciascun worker. Questa allocazione significa che il numero minimo di worker utilizzati per una pipeline di scalabilità automatica in streaming è N/15, dove N è il valore di --max_num_workers.

Per i job di scalabilità automatica in streaming che utilizzano Streaming Engine, il numero minimo di worker è 1.

Dataflow bilancia il numero di dischi permanenti tra i worker. Ad esempio, se la pipeline ha bisogno di tre o quattro worker in stato uno stato, potresti impostare --max_num_workers=15. La pipeline esegue automaticamente è scalabile da 1 a 15 worker, utilizzando 1, 2, 3, 4, 5, 8 o 15 worker, corrispondono a 15, 8, 5, 4, 3, 2 o 1 dischi permanenti per worker, rispettivamente.

--max_num_workers può essere al massimo 1000.

Vai

Per i job di scalabilità automatica in streaming che non utilizzano Streaming Engine, il servizio Dataflow alloca da 1 a 15 dischi permanenti a ogni worker. Questa allocazione significa che il numero minimo di worker utilizzati per una pipeline di scalabilità automatica in streaming è N/15, dove N è il valore di --max_num_workers.

Per i job di scalabilità automatica dei flussi di dati che utilizzano Motore di flussi di dati il numero minimo di worker è 1.

Dataflow bilancia il numero di dischi permanenti tra i worker. Ad esempio, se la pipeline ha bisogno di tre o quattro worker in stato uno stato, potresti impostare --max_num_workers=15. La pipeline scala automaticamente tra 1 e 15 worker, utilizzando 1, 2, 3, 4, 5, 8 o 15 worker, che corrispondono rispettivamente a 15, 8, 5, 4, 3, 2 o 1 dischi rigidi permanenti per worker.

--max_num_workers può essere al massimo 1000.

Numero massimo di worker che la scalabilità automatica dello streaming potrebbe utilizzare

Java

Dataflow opera entro i limiti Quota di conteggio delle istanze Compute Engine del tuo progetto o maxNumWorkers, a seconda di quale delle due opzioni corrisponde in basso.

Python

Dataflow opera entro i limiti della quota di conteggi di istanze Compute Engine del progetto o di max_num_workers, a seconda del valore più basso.

Vai

Dataflow opera entro i limiti Quota di conteggio delle istanze Compute Engine del tuo progetto o max_num_workers, a seconda di quale delle due opzioni corrisponde in basso.

Limitare la scalabilità automatica per ridurre l'impatto sulla fatturazione

Se non vuoi che la scalabilità automatica aumenti la tua fattura, puoi limitare il numero massimo di worker che il tuo job di streaming può utilizzare.

Java

Se specifichi --maxNumWorkers, limiti l'intervallo di scalabilità utilizzato nell'elaborazione il tuo lavoro.

Python

Se specifichi --max_num_workers, limiti l'intervallo di scalabilità utilizzato per elaborare il tuo job.

Vai

Se specifichi --max_num_workers, limiti l'intervallo di scalabilità utilizzato per elaborare il tuo job.

Modificare l'intervallo di scalabilità

Per informazioni sulla modifica dell'intervallo di scalabilità su una pipeline in modalità flusso, consulta Imposta l'intervallo di scalabilità automatica.

Disattiva la scalabilità automatica nelle pipeline in modalità flusso

Per disattivare la scalabilità automatica nella pipeline di flusso, segui questi passaggi.

Java

Imposta --autoscalingAlgorithm=NONE. Per ulteriori informazioni, consulta Disattivare la scalabilità automatica orizzontale.

Python

Imposta --autoscaling_algorithm=NONE. Per ulteriori informazioni, vedi Disabilita la scalabilità automatica orizzontale.

Vai

Imposta --autoscaling_algorithm=NONE. Per ulteriori informazioni, vedi Disabilita la scalabilità automatica orizzontale.

Utilizza un numero fisso di worker

Per i job in streaming che non utilizzano Streaming Engine, il comportamento predefinito è utilizzare un numero fisso di worker. Per utilizzare la scalabilità automatica per lo streaming con queste pipeline, devi attivarla esplicitamente perché non è attiva per impostazione predefinita.