La funzionalità di ribilanciamento dinamico del lavoro del servizio Dataflow consente al servizio di ripartire dinamicamente il lavoro in base alle condizioni di runtime. Queste condizioni possono includere quanto segue:
- Squilibri nei compiti
- I lavoratori impiegano più tempo del previsto per completare il lavoro
- I lavoratori terminano il lavoro più velocemente del previsto
Il servizio Dataflow rileva automaticamente queste condizioni e può assegnare dinamicamente il lavoro a worker inutilizzati o sottoutilizzati per ridurre il tempo di elaborazione complessivo del job.
Limitazioni
Il ribilanciamento dinamico del lavoro si verifica solo quando il servizio Dataflow elabora alcuni dati di input in parallelo: quando legge i dati da un'origine di input esterna, quando lavora con un PCollection intermedio materializzato o quando lavora con il risultato di un'aggregazione come GroupByKey. Se un numero elevato di passaggi del job è fuso, il job ha meno PCollection intermedi e il riequilibrio dinamico del lavoro è limitato al numero di elementi nell'PCollection materializzato di origine. Se
vuoi assicurarti che il riequilibrio dinamico del lavoro possa essere applicato a un determinato
PCollection nella pipeline, puoi
impedire la fusione in diversi modi per garantire il parallelismo dinamico.
Il ribilanciamento dinamico del lavoro non può eseguire la riparallelizzazione dei dati con una granularità inferiore a un singolo record. Se i dati contengono singoli record che causano notevoli ritardi nel tempo di elaborazione, potrebbero comunque ritardare il job. Dataflow non può suddividere e ridistribuire un singolo record "hot" a più worker.
Java
Se imposti un numero fisso di shard per l'output finale della pipeline (ad esempio scrivendo i dati utilizzando TextIO.Write.withNumShards), Dataflow limita la parallelizzazione in base al numero di shard che scegli.
Python
Se imposti un numero fisso di shard per l'output finale della pipeline (ad esempio scrivendo i dati utilizzando beam.io.WriteToText(..., num_shards=...)), Dataflow limita la parallelizzazione in base al numero di shard che scegli.
Vai
Se imposti un numero fisso di shard per l'output finale della pipeline, Dataflow limita la parallelizzazione in base al numero di shard che scegli.
Utilizzo di origini dati personalizzate
Java
Se la pipeline utilizza un'origine dati personalizzata che fornisci, devi implementare il metodo splitAtFraction per consentire all'origine di funzionare con la funzionalità di riequilibrio dinamico del lavoro.
Se implementi splitAtFraction in modo errato, i record della tua origine potrebbero sembrare duplicati o eliminati. Consulta le informazioni di riferimento dell'API su RangeTracker per ricevere assistenza e suggerimenti sull'implementazione di splitAtFraction.
Python
Se la pipeline utilizza un'origine dati personalizzata fornita da te, il tuo RangeTracker deve implementare try_claim, try_split, position_at_fraction e fraction_consumed per consentire all'origine di funzionare con la funzionalità di riequilibrio dinamico del lavoro.
Per ulteriori informazioni, consulta le informazioni di riferimento dell'API su RangeTracker.
Vai
Se la pipeline utilizza un'origine dati personalizzata che fornisci, devi implementare un RTracker valido per consentire all'origine di funzionare con la funzionalità di riequilibrio dinamico del lavoro.
Per ulteriori informazioni, consulta le informazioni di riferimento dell'API RTracker.
Il ribilanciamento dinamico del lavoro utilizza il valore restituito del metodo getProgress()
della tua origine personalizzata per l'attivazione. L'implementazione predefinita per getProgress() restituisce
null. Per assicurarti che la scalabilità automatica venga attivata, assicurati che l'origine personalizzata sostituisca
getProgress() per restituire un valore appropriato.