Nelle pipeline in modalità flusso con un volume elevato di dati di input, c'è generalmente un compromesso tra costo e latenza. Per mantenere una bassa latenza, Dataflow deve aggiungere worker man mano che il volume di traffico aumenta. Un altro fattore è la velocità con cui la pipeline dovrebbe fare lo scale up o lo scale down in risposta alle variazioni della velocità dei dati di input.
Il gestore della scalabilità automatica di Dataflow ha impostazioni predefinite adatte per molti carichi di lavoro. Tuttavia, ti consigliamo di ottimizzare questo comportamento per uno specifico scenario. Ad esempio, potrebbe essere accettabile una latenza media più elevata per ridurre i costi oppure potresti volere che Dataflow aumenti più rapidamente in risposta ai picchi di traffico.
Per ottimizzare la scalabilità automatica orizzontale, puoi regolare i seguenti parametri:
- Intervallo di scalabilità automatica: il numero minimo e massimo di worker da allocare.
- Suggerimento per utilizzo worker: l'utilizzo target della CPU per worker.
Impostare l'intervallo di scalabilità automatica
Quando crei un nuovo job di streaming, puoi impostare il numero iniziale di worker e il numero massimo di worker. Per farlo, specifica quanto segue: opzioni pipeline:
Java
--numWorkers
: il numero iniziale di worker disponibili quando la pipeline inizia a essere eseguita--maxNumWorkers
: il numero massimo di worker disponibili per la pipeline
Python
--num_workers
: il numero iniziale di worker disponibili quando la pipeline inizia a essere eseguita--max_num_workers
: il numero massimo di worker disponibili per la pipeline
Vai
--num_workers
: il numero iniziale di worker disponibili quando la pipeline inizia a essere eseguita--max_num_workers
: il numero massimo di worker disponibili per la pipeline
Per i job di flussi che utilizzano Streaming Engine, il flag --maxNumWorkers
è
facoltativo. Il valore predefinito è 100
. Per i job di streaming che non utilizzano Streaming Engine,--maxNumWorkers
è obbligatorio quando la scalabilità automatica orizzontale è abilitata.
Il valore iniziale --maxNumWorkers
determina anche il numero di
dischi permanenti allocati per il job.
Il deployment delle pipeline viene eseguito con un pool fisso di dischi permanenti, pari in numero a
--maxNumWorkers
. Durante lo streaming, i dischi permanenti vengono ridistribuiti in modo che ogni worker riceva un numero uguale di dischi collegati.
Se imposti --maxNumWorkers
, assicurati che il valore fornisca dischi sufficienti per
una pipeline o un blocco note personalizzato. Quando definisci il valore iniziale, tieni conto della crescita futura. Per informazioni sulle prestazioni di Persistent Disk, consulta Configurare i dischi permanenti e le VM.
Dataflow fattura l'utilizzo di Persistent Disk e ha
Quote di Compute Engine, incluse le quote di Persistent Disk.
Per impostazione predefinita, il numero minimo di worker è 1 per i job di streaming che utilizzano Streaming Engine e (maxNumWorkers
/15), arrotondato per eccesso, per i job che non utilizzano Streaming Engine.
Aggiorna l'intervallo di scalabilità automatica
Per i job che utilizzano Streaming Engine, puoi modificare il numero minimo e massimo di worker, senza arrestare o sostituire il job. Per modificare questi valori, utilizza un aggiornamento dei job in esecuzione. Aggiorna le seguenti opzioni di job:
--min-num-workers
: il numero minimo di lavoratori.--max-num-workers
: il numero massimo di worker.
gcloud
Utilizza il comando gcloud dataflow jobs update-options
:
gcloud dataflow jobs update-options \ --region=REGION \ --min-num-workers=MINIMUM_WORKERS \ --max-num-workers=MAXIMUM_WORKERS \ JOB_ID
Sostituisci quanto segue:
- REGION: l'ID regione dell'endpoint a livello di regione del job
- MINIMUM_WORKERS: il numero minimo di Compute Engine istanze
- MAXIMUM_WORKERS: il numero massimo di Compute Engine istanze
- JOB_ID: l'ID del job da aggiornare
Puoi anche aggiornare --min-num-workers
e --max-num-workers
individualmente.
REST
Utilizza il metodo
projects.locations.jobs.update
:
PUT https://dataflow.googleapis.com/v1b3/projects/PROJECT_ID/locations/REGION/jobs/JOB_ID?updateMask=runtime_updatable_params.max_num_workers,runtime_updatable_params.min_num_workers { "runtime_updatable_params": { "min_num_workers": MINIMUM_WORKERS, "max_num_workers": MAXIMUM_WORKERS } }
Sostituisci quanto segue:
- PROJECT_ID: l'ID del progetto Google Cloud della Job Dataflow
- REGION: l'ID regione dell'endpoint a livello di regione del job
- JOB_ID: l'ID del job da aggiornare
- MINIMUM_WORKERS: il numero minimo di Compute Engine istanze
- MAXIMUM_WORKERS: il numero massimo di istanze Compute Engine
Puoi anche aggiornare min_num_workers
e max_num_workers
singolarmente.
Specifica i parametri da aggiornare nel parametro di query updateMask
e includi i valori aggiornati nel campo runtimeUpdatableParams
del corpo della richiesta. Nell'esempio seguente viene aggiornato min_num_workers
:
PUT https://dataflow.googleapis.com/v1b3/projects/my_project/locations/us-central1/jobs/job1?updateMask=runtime_updatable_params.min_num_workers { "runtime_updatable_params": { "min_num_workers": 5 } }
Per i job che non utilizzano Streaming Engine, puoi:
sostituire il job esistente
con un valore aggiornato di maxNumWorkers
.
Se aggiorni un job di streaming che non utilizza Streaming Engine, la scalabilità automatica orizzontale del job aggiornato è disattivata per impostazione predefinita. Per mantenere abilitata la scalabilità automatica,
specificare --autoscalingAlgorithm
e --maxNumWorkers
per il job aggiornato.
Imposta il suggerimento per l'utilizzo del worker
Dataflow utilizza l'utilizzo medio della CPU come indicatore per sapere quando applicare la scalabilità automatica orizzontale. Per impostazione predefinita, Dataflow imposta un utilizzo della CPU di destinazione pari a 0,8. Quando l'utilizzo non rientra in questo intervallo, Dataflow potrebbe aggiungere o rimuovere worker.
Per un maggiore controllo sul comportamento della scalabilità automatica, puoi impostare l'utilizzo della CPU target su un valore compreso nell'intervallo [0,1, 0,9].
Imposta un valore di utilizzo della CPU inferiore se vuoi ottenere latenze di picco inferiori. Un valore più basso consente a Dataflow di fare lo scale out più aggressivo in in risposta al crescente utilizzo dei worker e a ridurre la scalabilità in modo più conservativo per migliorare la stabilità. Un valore più basso offre anche più spazio di manovra quando la pipeline è in esecuzione in stato stabile, in genere con una latenza coda inferiore. (La latenza di coda misura i tempi di attesa più lunghi prima che un nuovo record venga processed.)
Imposta un valore più alto se vuoi risparmiare risorse e mantenere i costi più bassi quando di picchi di traffico. Un valore più alto impedisce un aumento eccessivo delle dimensioni, a scapito del con una latenza maggiore.
Per configurare il suggerimento di utilizzo quando esegui un job non basato su modello, imposta l'worker_utilization_hint
opzione di servizio. Per un job modello,
aggiornare il suggerimento sull'utilizzo, poiché le opzioni di servizio non sono
supportati.
L'esempio seguente mostra come utilizzare worker_utilization_hint
:
Java
--dataflowServiceOptions=worker_utilization_hint=TARGET_UTILIZATION
Sostituisci TARGET_UTILIZATION con un valore compreso nell'intervallo [0,1, 0,9].
Python
--dataflow_service_options=worker_utilization_hint=TARGET_UTILIZATION
Sostituisci TARGET_UTILIZATION con un valore compreso nell'intervallo [0,1, 0,9].
Vai
--dataflow_service_options=worker_utilization_hint=TARGET_UTILIZATION
Sostituisci TARGET_UTILIZATION con un valore compreso nell'intervallo [0,1, 0,9].
Per le nuove pipeline, ti consigliamo di eseguire il test con carichi realistici utilizzando l'impostazione predefinita. Quindi valuta il comportamento della scalabilità automatica in base al tuo e apporta le modifiche necessarie.
Il suggerimento sull'utilizzo è solo uno dei fattori usati da Dataflow quando decidere se scalare i worker. Altri fattori come arretrato e disponibilità le chiavi possono prevalere sul valore del suggerimento. Inoltre, l'indicazione non è un target rigoroso. La il gestore della scalabilità automatica tenta di mantenere l'utilizzo della CPU entro l'intervallo del valore hint, ma la metrica di utilizzo aggregato potrebbe essere superiore o inferiore. Per maggiori informazioni informazioni, consulta Euristica di scalabilità automatica dei flussi di dati.
Aggiorna il suggerimento sull'utilizzo
Per aggiornare il suggerimento di utilizzo durante l'esecuzione di un job, esegui una aggiornamento in corso come segue:
gcloud
Utilizza il comando
gcloud dataflow jobs update-options
:
gcloud dataflow jobs update-options \ --region=REGION \ --worker-utilization-hint=TARGET_UTILIZATION \ JOB_ID
Sostituisci quanto segue:
- REGION: l'ID regione dell'endpoint a livello di regione del job
- JOB_ID: l'ID del job da aggiornare
- TARGET_UTILIZATION: un valore compreso nell'intervallo [0,1, 0,9]
Per reimpostare il valore predefinito del suggerimento sull'utilizzo, usa quanto segue Comando gcloud:
gcloud dataflow jobs update-options \ --unset-worker-utilization-hint \ --region=REGION \ --project=PROJECT_ID \ JOB_ID
REST
Utilizza la
projects.locations.jobs.update
:
PUT https://dataflow.googleapis.com/v1b3/projects/PROJECT_ID/locations/REGION/jobs/JOB_ID?updateMask=runtime_updatable_params.worker_utilization_hint { "runtime_updatable_params": { "worker_utilization_hint": TARGET_UTILIZATION } }
Sostituisci quanto segue:
- PROJECT_ID: l'ID progetto Google Cloud del job Dataflow.
- REGION: l'ID regione dell'endpoint a livello di regione del job.
- JOB_ID: l'ID del job da aggiornare.
- TARGET_UTILIZATION: un valore compreso nell'intervallo [0,1, 0,9]
Algoritmi di euristica per la scalabilità automatica di Streaming
Per le pipeline in modalità flusso, l'obiettivo della scalabilità automatica orizzontale è ridurre al minimo backlog, massimizzando l'utilizzo e la velocità effettiva del worker e di reagire rapidamente a picchi di carico.
Dataflow prende in considerazione diversi fattori durante la scalabilità automatica, tra cui:
Backlog. Il tempo di coda stimato viene calcolato in base alla velocità in bit e ai byte in coda ancora da elaborare dall'origine di input. Una pipeline è considerata in backlog quando il tempo di backlog stimato rimane superiore a 15 secondi.
Utilizzo CPU target. Il target predefinito per l'utilizzo medio della CPU è 0,8. Puoi sostituire questo valore.
Chiavi disponibili. Le chiavi sono l'unità fondamentale del parallelismo e Dataflow.
In alcuni casi, Dataflow utilizza i seguenti fattori in di scalabilità automatica. Se questi fattori vengono utilizzati per il tuo job, puoi visualizzare queste informazioni nella scheda delle metriche Autoscaling.
La limitazione basata su chiavi utilizza il numero di chiavi di elaborazione ricevute dal job per calcolare il limite per i worker dell'utente, poiché ogni chiave può essere elaborata da un solo worker alla volta.
Attenuazione del ridimensionamento. Se Dataflow rileva che è instabile di scalabilità automatica, rallenta la velocità per migliorare la stabilità.
L'upscaling basato sulla CPU utilizza un utilizzo elevato della CPU come criterio di upscaling.
Per i job di streaming che non utilizzano Streaming Engine, la scalabilità potrebbe essere limitata dal numero di dischi permanenti. Per ulteriori informazioni, consulta Impostare l'intervallo di scalabilità automatica.
Upscaling. Se una pipeline in modalità flusso rimane in backlog il parallelismo dei worker per diversi minuti, Dataflow scala verso l'alto. Dataflow tenta di eliminare la coda entro circa 150 secondi dall'aumento di scala, in base al throughput corrente per worker. Se c'è ma il worker non ha un parallelismo sufficiente per i worker aggiuntivi, non fa lo scale up della pipeline. (Aumenta il numero di worker oltre il numero di chiavi disponibili per l'elaborazione parallela non aiuta a elaborare il backlog faster.)
Scalabilità: quando il gestore della scalabilità automatica prende una decisione di downscaling, il backlog è la fattore di priorità più alta. Il gestore della scalabilità automatica punta a un backlog non superiore a 15 secondi. Se il backlog scende al di sotto dei 10 secondi e l'utilizzo medio del worker è inferiore al target di utilizzo della CPU, quindi Dataflow fa lo scale down. Come purché il backlog sia accettabile, il gestore della scalabilità automatica tenta di mantenere vicino all'utilizzo target della CPU. Se l'utilizzo è già sufficientemente vicino al target, ma il gestore della scalabilità automatica potrebbe mantenere il numero di worker invariati perché ogni passaggio di downscaling ha un costo.
Streaming Engine utilizza anche una tecnica di scalabilità automatica predittiva basata sul backlog del timer. I dati illimitati in una pipeline in streaming sono suddivisi in windows raggruppati in base ai timestamp. Al termine di una finestra, i timer si attivano per ogni chiave in fase di elaborazione. quella finestra. L'attivazione di un timer indica che la finestra è scaduta per una determinata chiave. Streaming Engine può misurare il backlog dei timer e prevedere quanti timer verranno attivati alla fine di una finestra. Utilizzando il backlog del timer come indicatore, Dataflow può stimare la quantità di elaborazione che deve avvenire quando verranno attivati timer futuri. In base al carico futuro stimato, Dataflow esegue la scalabilità automatica in anticipo per soddisfare la domanda prevista.
Metriche
Per trovare i limiti attuali con scalabilità automatica per un job, esegui una query sulle seguenti metriche:
job/max_worker_instances_limit
: numero massimo di worker.job/min_worker_instances_limit
: numero minimo di lavoratori.
Per informazioni sull'utilizzo dei worker, esegui query sulle seguenti metriche:
job/aggregated_worker_utilization
: l'utilizzo aggregato dei worker.job/worker_utilization_hint
: suggerimento per l'utilizzo attuale del worker.
Per ottenere informazioni sul comportamento del gestore della scalabilità automatica, esegui una query sulla seguente metrica:
job.worker_utilization_hint_is_actively_used
: indica se le il gestore della scalabilità automatica sta usando attivamente il suggerimento per l'utilizzo del worker. Se altri fattori superano il suggerimento quando viene campionato questa metrica, il valore èfalse
.job/horizontal_worker_scaling
: descrive le decisioni prese dal gestore della scalabilità automatica. Questa metrica contiene le seguenti etichette:direction
: specifica se il gestore della scalabilità automatica ha fatto lo scale up, lo scale down o non ha eseguito alcuna azione.rationale
: specifica il motivo della decisione del gestore della scalabilità automatica.
Per ulteriori informazioni, vedi Metriche di Cloud Monitoring. Queste metriche vengono visualizzate anche nei grafici di monitoraggio dell'autoscaling.
Passaggi successivi
- Monitorare la scalabilità automatica di Dataflow
- Risolvere i problemi di scalabilità automatica di Dataflow