Ottimizza la scalabilità automatica orizzontale per le pipeline in modalità flusso

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, una latenza media più elevata potrebbe essere accettabile per ridurre i costi, o potresti volere che Dataflow scali aumentare più rapidamente in risposta ai picchi di traffico.

Per ottimizzare la scalabilità automatica orizzontale, puoi regolare i seguenti parametri:

Imposta l'intervallo di scalabilità automatica

Quando crei un nuovo job di flussi di dati, 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 funzionare
  • --maxNumWorkers: il numero massimo di worker disponibili per la pipeline

Python

  • --num_workers: il numero iniziale di worker disponibili quando la pipeline inizia a funzionare
  • --max_num_workers: il numero massimo di worker disponibili per il tuo pipeline

Vai

  • --num_workers: il numero iniziale di worker disponibili quando la pipeline inizia a funzionare
  • --max_num_workers: il numero massimo di worker disponibili per il tuo pipeline

Per i job di flussi che utilizzano Streaming Engine, il flag --maxNumWorkers è facoltativo. Il valore predefinito è 100. Per i job di flussi che non utilizzano Streaming Engine, Il campo --maxNumWorkers è obbligatorio se è abilitata la scalabilità automatica orizzontale.

Anche il valore iniziale di --maxNumWorkers determina il numero I dischi permanenti sono allocati per il job. Il deployment delle pipeline viene eseguito con un pool fisso di dischi permanenti, pari in numero a --maxNumWorkers. Durante la trasmissione in modalità flusso, i dischi permanenti vengono ridistribuiti in modo tale che ogni worker riceve lo stesso numero 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 Configura il Persistent Disk 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 flussi che utilizzano Streaming Engine e (maxNumWorkers/15), arrotondato per eccesso, per i job che non usano Streaming Engine.

Aggiorna l'intervallo di scalabilità automatica

Per i job che utilizzano Streaming Engine, puoi regolare il valore minimo e massimo di worker, senza interrompere o sostituire il job. Per modificare questi valori, utilizza un aggiornamento del lavoro in corso. Aggiorna le seguenti opzioni del job:

  • --min-num-workers: il numero minimo di worker.
  • --max-num-workers: il numero massimo di worker.

gcloud

Usa 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 singolarmente.

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.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 Compute Engine istanze

Puoi anche aggiornare min_num_workers e max_num_workers singolarmente. Specifica quali parametri aggiornare nel parametro di query updateMask. includi i valori aggiornati nel campo runtimeUpdatableParams del corpo della richiesta. L'esempio seguente aggiorna 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: sostituisci il job esistente con un valore aggiornato di maxNumWorkers.

Se aggiorni un job di flussi di dati che non utilizza Streaming Engine, per impostazione predefinita la scalabilità automatica orizzontale è disabilitata nel job. Per mantenere abilitata la scalabilità automatica, specificare --autoscalingAlgorithm e --maxNumWorkers per il job aggiornato.

Imposta il suggerimento per l'utilizzo del worker

Dataflow usa l'utilizzo medio della CPU come indicatore per capire quando e applicare la scalabilità automatica orizzontale. Per impostazione predefinita, Dataflow imposta un target di utilizzo della CPU pari a 0,8. Se l'utilizzo non rientra in questo intervallo, Dataflow potrebbe aggiungere o rimuovere worker.

Per un maggiore controllo sul comportamento della scalabilità automatica, puoi impostare la CPU target l'utilizzo in un valore dell'intervallo [0,1, 0,9].

  • Imposta un valore di utilizzo della CPU più basso se vuoi ottenere latenze di picco più basse. 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 maggiore margine quando la pipeline è in esecuzione a stato stabile, con un conseguente rallentamento una latenza di pochi millisecondi. (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, imposta il valore worker_utilization_hint opzione di servizio:

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 test con caricamenti 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 che Dataflow usa quando decidere se scalare i worker. Altri fattori come arretrato e disponibilità le chiavi possono prevalere sul valore del suggerimento. Inoltre, il suggerimento non è un obiettivo preciso. 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 ulteriori 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 la 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 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 del progetto Google Cloud della 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 nell'intervallo [0,1, 0,9]

Euristica di scalabilità automatica dei flussi di dati

Per le pipeline in modalità flusso, l'obiettivo della scalabilità automatica orizzontale è ridurre backlog, massimizzando l'utilizzo e la velocità effettiva del worker e di reagire rapidamente a picchi di carico.

Dataflow prende in considerazione diversi fattori per la scalabilità automatica, tra cui:

  • Backlog: Il tempo di backlog stimato viene calcolato in base alla velocità effettiva i byte di backlog ancora da elaborare dall'origine di input. Una pipeline è viene considerato 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 usati per il tuo lavoro, puoi vedere queste informazioni Scheda delle metriche di scalabilità automatica.

  • La limitazione basata su chiavi utilizza il numero di chiavi di elaborazione ricevute dal job per calcolare il limite per i worker, dato che ogni chiave può essere elaborata da un worker alla volta.

  • Smorzamento downscale. Se Dataflow rileva che è instabile di scalabilità automatica, rallenta la velocità per migliorare la stabilità.

  • L'upscaling basato su CPU utilizza un elevato utilizzo della CPU come criterio di upscaling.

  • Per i job di flussi di dati che non utilizzano Motore di flussi di dati, la scalabilità potrebbe vincolati dal numero di dischi permanenti. Per ulteriori informazioni, vedi Imposta 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 cancellare il backlog entro circa 150 secondi di scale up, data la velocità effettiva attuale 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 su timer arretrato. I dati illimitati di una pipeline in modalità flusso sono suddivisi in finestre raggruppate per i 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 un una data chiave. Streaming Engine può misurare il backlog del timer e prevederne il numero i 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 caricamento futuro stimato, Dataflow scala automaticamente 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 worker.

Per ottenere informazioni sull'utilizzo dei worker, esegui una 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 su quanto segue 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 ci sono altri fattori sostituisci il suggerimento quando questa metrica viene campionata, il valore è false.
  • job/horizontal_worker_scaling: descrive le decisioni prese dal del 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. Questi le metriche vengono visualizzate anche grafici di monitoraggio con scalabilità automatica.

Passaggi successivi