Risolvere i problemi di scalabilità automatica di Dataflow

Questa pagina mostra come risolvere i problemi relativi alle 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 sugli scenari che potrebbero impedire ai worker di aumentare o diminuire lo scale down.

Il job di streaming non fa lo scale up

Quando la pipeline in modalità flusso ha un backlog, lo scale up dei worker non viene eseguito.

Questo problema si verifica quando il backlog dura meno di pochi minuti o quando i worker utilizzano meno del 20% delle CPU.

A volte, il backlog è elevato, ma l'utilizzo della CPU è basso. Poiché alcune attività non richiedono un utilizzo elevato della CPU, l'aggiunta di worker non migliora le prestazioni. In questi casi, Dataflow non esegue lo scale up. Per ulteriori informazioni, consulta Scalabilità automatica dei flussi di dati. Questo scenario può 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 dispone di chiavi sufficienti.

I job batch e flusso non fanno lo scale up

Il job batch o flusso viene eseguito come previsto, ma quando sono necessari più worker, il job non viene fatto lo scale up.

Questo problema potrebbe verificarsi per uno dei seguenti motivi:

• I file temporanei o di gestione temporanea 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 nel bucket. Gli oggetti eliminati includono cartelle e file di gestione temporanea e 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 di backlog si basano sul valore restituito del metodo getProgress() dell'origine personalizzata per iniziare a raccogliere dati. L'implementazione predefinita per getProgress() restituisce un valore NULL. Per risolvere il problema, assicurati che l'origine personalizzata esegua l'override del metodo getProgress() predefinito per restituire un valore non NULL.
• Un aggiornamento attivato dalla scalabilità automatica verticale disattiva temporaneamente la scalabilità automatica orizzontale. Per maggiori informazioni, consulta Effetti sulla scalabilità automatica orizzontale.
• Se utilizzi un'operazione map in una pipeline Python e il job non fa lo scale up, potresti dover aggiungere una trasformazione Reshuffle al codice della pipeline. Per ulteriori informazioni, consulta la sezione relativa al rishuffling nella documentazione di Apache Beam.

Il job di streaming non fa fare lo scale down

Quando il job di inserimento di flussi ha un backlog basso e un basso utilizzo di CPU, i worker non vengono fare lo scale down. Questo problema può verificarsi per vari motivi.

• Quando i job non utilizzano Streaming Engine, Dataflow bilancia il numero di dischi permanenti tra i worker. Di conseguenza, ogni worker deve avere lo stesso numero di dischi permanenti. Ad esempio, se sono presenti 100 dischi e 100 worker, ogni worker avrà un disco. Quando viene fatto lo scale down del job, può includere 50 worker con due dischi permanenti per worker. Il job non esegue nuovamente fare lo scale down fino a quando non può avere 25 worker con quattro dischi permanenti per worker. Inoltre, il numero minimo di worker è il valore assegnato a maxNumWorkers diviso per 15. Per saperne di più, consulta Intervallo di scalabilità per le pipeline con 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 questo utilizzo della CPU, il downgrade è disabilitato.

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

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

Aumento delle tappe

Il job batch o streaming avvia 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 alla quota di Compute Engine del progetto. Se sono in esecuzione più job, il progetto potrebbe aver raggiunto il limite della quota di Compute Engine. In questo caso, Dataflow non può aumentare il numero di worker.
• Quote per le CPU: i job Dataflow sono anche soggetti alla quota CPU del progetto. Se il tipo di worker utilizza più di una CPU, il progetto potrebbe aver raggiunto il limite della quota di CPU.
• Quote per gli indirizzi IP esterni: quando il job utilizza indirizzi IP esterni per comunicare con le risorse, hai bisogno di un numero di indirizzi IP esterni pari a quello dei worker. Con lo scale up del numero di worker, aumenta anche il numero di indirizzi IP esterni. Quando viene raggiunto il limite di indirizzi IP, i worker interrompono lo scale up.

Inoltre, se la regione che scegli non è più una risorsa, non puoi creare nuove risorse di quel tipo, anche se hai ancora a disposizione la quota nella tua regione o nel tuo progetto. Ad esempio, potresti avere ancora a disposizione una quota per creare indirizzi IP esterni in us-central1, ma quella regione potrebbe non avere indirizzi IP disponibili. Per saperne di più, 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 sull'utilizzo dei worker non ha alcun effetto

Hai impostato il suggerimento per l'utilizzo dei worker, ma il comportamento della scalabilità automatica non cambia.

Per comprendere il problema, vai al grafico sull'utilizzo della CPU dei worker e controlla se il suggerimento sull'utilizzo dei worker viene utilizzato attivamente. Se viene utilizzato il suggerimento, il grafico mostra CPU utilization hint (actively used by autoscaler). In caso contrario, mostrerà CPU utilization hint (not actively used by autoscaler).

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

Comportamento di scalabilità osservato	Cause	Metriche da verificare
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. L'aggiustamento del downscaling è troppo ridotto o Dataflow sta attenuando il downscaling. Per maggiori informazioni, consulta Euristica con scalabilità automatica dei flussi di dati.	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 del worker
Scale up	L'obiettivo di latenza o backlog elevato sostituisce il suggerimento. Il numero minimo di worker è stato aggiornato a un valore più elevato rispetto al 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 rispetto al numero attuale di worker.	job/aggregated_worker_utilization job/max_worker_instances_limit

Per maggiori informazioni, consulta Euristica con scalabilità automatica dei flussi di dati.

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 l'integrità del job di inserimento di flussi.

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 più elevato, una latenza di sistema o un aggiornamento dei dati maggiore rispetto ad altri.

Questo problema può verificarsi se i dati contengono un tasto di scelta rapida. Un tasto di scelta rapida è una chiave con elementi sufficienti a influire negativamente sulle prestazioni della pipeline. Ogni chiave deve essere elaborata da un singolo worker, quindi il lavoro non può essere suddiviso tra worker.

Per ulteriori informazioni, consulta le indicazioni sugli errori dei tasti di scelta rapida.

L'elemento di lavoro che richiede la lettura dello stato non è più valido nel backend

Durante la comunicazione tra le istanze VM worker e le attività di Streaming Engine in una pipeline in modalità 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 la scalabilità automatica, le istanze VM worker comunicano con più attività di Streaming Engine e ogni attività gestisce più istanze VM worker. Le chiavi degli elementi vengono utilizzate per distribuire il lavoro. Ogni attività e istanza VM worker dispone di una raccolta di intervalli di chiavi e la distribuzione di questi intervalli può cambiare in modo dinamico. Ad esempio, durante la scalabilità automatica, il ridimensionamento del job può causare la modifica della distribuzione dell'intervallo di chiavi. Questo errore può verificarsi quando un intervallo di chiavi cambia. L'errore è previsto e, a meno che non rilevi una correlazione tra questi messaggi e una pipeline con prestazioni inadeguate, puoi ignorarlo.

Risorse Streaming Engine insufficienti

Se Streaming Engine non può allocare il numero minimo di worker richiesti, 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 con scalabilità automatica in modalità flusso

Questa sezione fornisce dettagli sull'intervallo di scalabilità per i flussi di pipeline con scalabilità automatica.

Java

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

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

Dataflow bilancia il numero di dischi permanenti tra i worker. Ad esempio, se la tua pipeline ha bisogno di tre o quattro worker in stato stabile, puoi impostare --maxNumWorkers=15. La pipeline scala automaticamente da 1 a 15 worker, utilizzando rispettivamente 1, 2, 3, 4, 5, 8 o 15 worker, corrispondenti a 15, 8, 5, 4, 3, 2 o 1 dischi permanenti per worker.

Il valore di --maxNumWorkers può essere al massimo 1000.

Python

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

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

Dataflow bilancia il numero di dischi permanenti tra i worker. Ad esempio, se la tua pipeline ha bisogno di tre o quattro worker in stato stabile, puoi impostare --max_num_workers=15. La pipeline scala automaticamente da 1 a 15 worker, utilizzando rispettivamente 1, 2, 3, 4, 5, 8 o 15 worker, corrispondenti a 15, 8, 5, 4, 3, 2 o 1 dischi permanenti per worker.

Il valore di --max_num_workers può essere al massimo 1000.

Go

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

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

Dataflow bilancia il numero di dischi permanenti tra i worker. Ad esempio, se la tua pipeline ha bisogno di tre o quattro worker in stato stabile, puoi impostare --max_num_workers=15. La pipeline scala automaticamente da 1 a 15 worker, utilizzando rispettivamente 1, 2, 3, 4, 5, 8 o 15 worker, corrispondenti a 15, 8, 5, 4, 3, 2 o 1 dischi permanenti per worker.

Il valore di --max_num_workers può essere al massimo 1000.

Numero massimo di worker per la scalabilità automatica dei flussi di dati che è possibile utilizzare

Java

Dataflow opera entro i limiti della quota di conteggio delle istanze di Compute Engine del progetto o di maxNumWorkers, a seconda di quale delle due opzioni è inferiore.

Python

Dataflow opera entro i limiti della quota di conteggio delle istanze di Compute Engine del progetto o di max_num_workers, a seconda di quale delle due opzioni è inferiore.

Go

Dataflow opera entro i limiti della quota di conteggio delle istanze di Compute Engine del progetto o di max_num_workers, a seconda di quale delle due opzioni è inferiore.

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

Se non vuoi che la scalabilità automatica aumenti i costi della fattura, puoi limitare il numero massimo di worker che il job di inserimento di flussi può utilizzare.

Java

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

Python

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

Go

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

Modifica l'intervallo di scalabilità

Per informazioni su come modificare l'intervallo di scalabilità su una pipeline in modalità flusso, consulta Impostare l'intervallo di scalabilità automatica.

Disattiva la scalabilità automatica sulle pipeline in modalità flusso

Per disattivare la scalabilità automatica sulla pipeline in modalità flusso, segui questi passaggi.

Java

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

Python

Imposta --autoscaling_algorithm=NONE. Per maggiori informazioni, consulta Disattivare la scalabilità automatica orizzontale.

Go

Imposta --autoscaling_algorithm=NONE. Per maggiori informazioni, consulta Disattivare la scalabilità automatica orizzontale.

Utilizza un numero fisso di worker

Per i job di elaborazione in modalità flusso che non utilizzano Streaming Engine, il comportamento predefinito prevede l'utilizzo di un numero fisso di worker. Per utilizzare la scalabilità automatica dei flussi di dati con queste pipeline, devi attivarla esplicitamente in quanto non è attiva per impostazione predefinita.