Horizontales Autoscaling für Streamingpipelines abstimmen

In Streamingpipelines mit schwankenden oder großen Eingabedatenmengen müssen Sie oft die Verarbeitungslatenz gegen die Betriebskosten abwägen. Dataflow bietet zwar Standardeinstellungen für das horizontale Autoscaling, die für viele Arbeitslasten geeignet sind, das Standardverhalten entspricht jedoch möglicherweise nicht Ihren spezifischen Anforderungen. Beispielsweise können Sie die Kosten senken, indem Sie eine höhere durchschnittliche Latenz akzeptieren, schneller hochskalieren, um Trafficspitzen zu bewältigen, oder strenge Limits für die Worker-Zuweisung erzwingen.

Durch die Optimierung des horizontalen Autoscalings können Sie anpassen, wie Dataflow die Worker-Kapazität an sich ändernde Arbeitslastanforderungen anpasst. Durch Anpassen der Autoscaling-Parameter können Sie den Pipeline-Durchsatz optimieren, die Rechenkosten kontrollieren und Ihre spezifischen Latenzziele erreichen.

Horizontales Autoscaling optimieren

Sie können die folgenden Parameter anpassen, um das horizontale Autoscaling zu optimieren:

  • Autoscaling-Bereich: Die minimale und maximale Anzahl von Workern, die zugewiesen werden sollen.
  • Worker-Auslastungshinweis: Die CPU-Zielauslastung für Worker.
  • Hinweis zur Worker-Parallelität: Die Zielanzahl der Parallelität für Worker.
  • Latenzstufe: Die Backlog-Schwellenwertstufe, um die Empfindlichkeit des Autoscalings für die Backlog-Dauer zu konfigurieren.
  • Geplantes Autoscaling: Sie können wiederkehrende Änderungen an Autoscaling-Einstellungen wie dem Worker-Bereich oder dem Nutzungshinweis für bestimmte Zeitfenster planen.

Autoscaling-Bereich festlegen

Wenn Sie einen neuen Streamingjob erstellen, können Sie die anfängliche und die maximale Anzahl von Workern festlegen. Geben Sie dazu die folgenden Pipelineoptionen an:

Java

  • --numWorkers: die anfängliche Anzahl der Worker, die verfügbar sind, wenn die Pipeline-Ausführung beginnt
  • --maxNumWorkers: die maximale Anzahl an Workern, die für Ihre Pipeline verfügbar sind

Python

  • --num_workers: die anfängliche Anzahl der Worker, die verfügbar sind, wenn die Pipeline-Ausführung beginnt
  • --max_num_workers: die maximale Anzahl an Workern, die für Ihre Pipeline verfügbar sind

Go

  • --num_workers: die anfängliche Anzahl der Worker, die verfügbar sind, wenn die Pipeline-Ausführung beginnt
  • --max_num_workers: die maximale Anzahl an Workern, die für Ihre Pipeline verfügbar sind

Für Streamingjobs mit Streaming Engine ist das Flag --maxNumWorkers optional. Der Standardwert ist 100. Für Streamingjobs ohne Streaming Engine ist --maxNumWorkers erforderlich, wenn horizontales Autoscaling aktiviert ist.

Der Startwert von --maxNumWorkers bestimmt auch, wie viele Persistent Disks dem Job zugewiesen werden. Streamingpipelines werden mit einem festen Pool nichtflüchtiger Speicher bereitgestellt, deren Anzahl --maxNumWorkers entspricht. Während des Streamings werden Persistent Disks so neu verteilt, dass jeder Worker mit der gleichen Anzahl von Laufwerken verbunden ist.

Wenn Sie --maxNumWorkers festlegen, achten Sie darauf, dass der Wert genügend Laufwerke für Ihre Pipeline bereitstellt. Berücksichtigen Sie beim Festlegen des Anfangswerts das zukünftige Wachstum. Informationen zur Leistung von Persistent Disks finden Sie unter Persistent Disk und VMs konfigurieren. Dataflow stellt die Nutzung von Persistent Disk in Rechnung und hat Compute Engine-Kontingente, einschließlich Persistent Disk-Kontingente.

Die Mindestanzahl von Workern ist standardmäßig 1 für Streamingjobs, die Streaming Engine verwenden, und (maxNumWorkers/15), aufgerundet, für Jobs ohne Streaming Engine.

Autoscaling-Bereich aktualisieren

Bei Jobs, die die Streaming Engine verwenden, können Sie die minimale und maximale Anzahl von Workern anpassen, ohne den Job zu beenden oder zu ersetzen. Wenn Sie diese Werte anpassen möchten, verwenden Sie eine Jobaktualisierung während der Ausführung. Aktualisieren Sie die folgenden Joboptionen:

  • --min-num-workers: die Mindestanzahl von Workern.

  • --max-num-workers: die maximale Anzahl von Workern.

gcloud

Führen Sie den Befehl gcloud dataflow jobs update-options aus:

gcloud dataflow jobs update-options \
  --region=REGION \
  --min-num-workers=MINIMUM_WORKERS \
  --max-num-workers=MAXIMUM_WORKERS \
  JOB_ID

Ersetzen Sie dabei Folgendes:

  • REGION: Die Regions-ID des regionalen Endpunkts des Jobs.
  • MINIMUM_WORKERS: Die Mindestanzahl von Compute Engine-Instanzen.
  • MAXIMUM_WORKERS: Die Mindestanzahl von Compute Engine-Instanzen.
  • JOB_ID: Die ID des zu aktualisierenden Jobs.

Sie können --min-num-workers und --max-num-workers auch einzeln aktualisieren.

REST

Verwenden Sie die Methode 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
  }
}

Ersetzen Sie Folgendes:

  • PROJECT_ID: Die Google Cloud Projekt-ID des Dataflow-Jobs
  • REGION: Die Regions-ID des regionalen Endpunkts des Jobs.
  • JOB_ID: Die ID des zu aktualisierenden Jobs.
  • MINIMUM_WORKERS: Die Mindestanzahl von Compute Engine-Instanzen.
  • MAXIMUM_WORKERS: Die Mindestanzahl von Compute Engine-Instanzen.

Sie können min_num_workers und max_num_workers auch einzeln aktualisieren. Geben Sie im Abfrageparameter updateMask an, welche Parameter aktualisiert werden sollen, und fügen Sie die aktualisierten Werte in das Feld runtimeUpdatableParams des Anfragetexts ein. Im folgenden Beispiel wird min_num_workers aktualisiert:

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
  }
}

Bei Jobs, die die Streaming Engine nicht verwenden, können Sie den vorhandenen Job durch einen aktualisierten Wert von maxNumWorkers ersetzen.

Wenn Sie einen Streamingjob aktualisieren, der Streaming Engine nicht verwendet, ist das horizontale Autoscaling für den aktualisierten Job standardmäßig deaktiviert. Wenn das Autoscaling aktiviert bleiben soll, geben Sie --autoscalingAlgorithm und --maxNumWorkers für den aktualisierten Job an.

Hinweis zur Worker-Auslastung festlegen

Dataflow verwendet die durchschnittliche CPU-Auslastung als Signal dafür, wann horizontales Autoscaling angewendet werden soll. Standardmäßig legt Dataflow eine Ziel-CPU-Auslastung von 0,8 fest. Wenn die Auslastung außerhalb dieses Bereichs liegt, kann Dataflow Worker hinzufügen oder entfernen.

Wenn Sie mehr Kontrolle über das Autoscaling-Verhalten haben möchten, können Sie die CPU-Zielauslastung auf einen Wert im Bereich [0,1, 0,9] festlegen.

  • Legen Sie einen niedrigeren CPU-Auslastungswert fest, wenn Sie niedrigere Spitzenlatenzen erreichen möchten. Ein niedrigerer Wert ermöglicht es Dataflow, bei steigender Worker-Auslastung aggressiver horizontal zu skalieren und konservativer herunterzuskalieren, um die Stabilität zu verbessern. Ein niedrigerer Wert bietet auch einen größeren Toleranzbereich, wenn die Pipeline im stabilen Zustand ausgeführt wird. Dies führt im Allgemeinen zu einer geringeren Extremwertlatenz. (Die Tail-Latenz misst die längsten Wartezeiten, bevor ein neuer Eintrag verarbeitet wird.)

  • Legen Sie einen höheren Wert fest, wenn Sie Ressourcen sparen und die Kosten bei Traffic-Spitzen niedrig halten möchten. Ein höherer Wert verhindert eine übermäßige Hochskalierung, auf Kosten einer höheren Latenz.

Wenn Sie den Auslastungshinweis beim Ausführen eines Jobs ohne Vorlage konfigurieren möchten, legen Sie die Dienstoption worker_utilization_hint fest. Bei einem Vorlagenjob müssen Sie stattdessen den Auslastungshinweis aktualisieren, da Dienstoptionen nicht unterstützt werden.

Das folgende Beispiel zeigt, wie worker_utilization_hint verwendet wird:

Java

--dataflowServiceOptions=worker_utilization_hint=TARGET_UTILIZATION

Ersetzen Sie TARGET_UTILIZATION durch einen Wert im Bereich [0,1, 0,9].

Python

--dataflow_service_options=worker_utilization_hint=TARGET_UTILIZATION

Ersetzen Sie TARGET_UTILIZATION durch einen Wert im Bereich [0,1, 0,9].

Go

--dataflow_service_options=worker_utilization_hint=TARGET_UTILIZATION

Ersetzen Sie TARGET_UTILIZATION durch einen Wert im Bereich [0,1, 0,9].

Für neue Pipelines empfehlen wir, die Standardeinstellung unter realistischen Lasten zu testen. Bewerten Sie dann das Autoscaling-Verhalten, wie es für Ihre Pipeline gilt, und nehmen Sie bei Bedarf Anpassungen vor.

Der Auslastungshinweis ist nur einer der Faktoren, die Dataflow bei der Entscheidung berücksichtigt, ob Worker skaliert werden sollen. Andere Faktoren wie Backlog und verfügbare Schlüssel können den Hinweiswert überschreiben. Außerdem ist der Hinweis kein striktes Ziel. Das Autoscaling versucht, die CPU-Auslastung im Bereich des Hinweiswerts zu halten, aber der aggregierte Auslastungsmesswert kann höher oder niedriger sein. Weitere Informationen finden Sie unter Streaming-Autoscaling-Heuristik.

Auslastungshinweis aktualisieren

Wenn Sie den Auslastungshinweis während der Ausführung eines Jobs aktualisieren möchten, führen Sie ein Update während der Übertragung so aus:

gcloud

Führen Sie den Befehl gcloud dataflow jobs update-options aus:

gcloud dataflow jobs update-options \
  --region=REGION \
  --worker-utilization-hint=TARGET_UTILIZATION \
  JOB_ID

Ersetzen Sie dabei Folgendes:

  • REGION: Die Regions-ID des regionalen Endpunkts des Jobs.
  • JOB_ID: Die ID des zu aktualisierenden Jobs.
  • TARGET_UTILIZATION: ein Wert im Bereich [0,1, 0,9]

Verwenden Sie den folgenden gcloud-Befehl, um den Auslastungshinweis auf den Standardwert zurückzusetzen:

gcloud dataflow jobs update-options \
  --unset-worker-utilization-hint \
  --region=REGION \
  --project=PROJECT_ID \
  JOB_ID

REST

Verwenden Sie die Methode 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
  }
}

Ersetzen Sie Folgendes:

  • PROJECT_ID: Die Google Cloud -Projekt-ID des Dataflow-Jobs.
  • REGION: Die Regions-ID des regionalen Endpunkts des Jobs.
  • JOB_ID: Die ID des zu aktualisierenden Jobs.
  • TARGET_UTILIZATION: ein Wert im Bereich [0,1, 0,9]

Hinweis zur Worker-Parallelität festlegen

Wenn Sie das Autoscaling bei langen Vorgängen, die weniger von CPUs abhängig sind, z. B. ML-intensive Arbeitslasten, verwalten möchten, können Sie den Hinweis zur Worker-Parallelität mithilfe von Apache Beam-Ressourcenhinweisen festlegen. Diese Hinweise schalten das Autoscaling in einen anderen Modus um, der für GPU-intensive Arbeitslasten oder Transformationen mit langer Verarbeitungszeit optimiert ist.

Im folgenden Beispiel wird gezeigt, wie Sie einen Parallelitätshinweis an eine Transformation anhängen:

Java

pcoll.apply(MyCompositeTransform.of(...)
  .setResourceHints(
      ResourceHints.create()
          .withMaxActiveBundlesPerWorker(TARGET_PARALLELISM_PER_WORKER)))

Ersetzen Sie TARGET_PARALLELISM_PER_WORKER durch einen Wert, der für Ihren Anwendungsfall geeignet ist. Allgemeine Informationen zur Auswahl eines guten Startwerts finden Sie in dieser Anleitung.

Python

pcoll | MyPTransform().with_resource_hints(
  max_active_bundles_per_worker="TARGET_PARALLELISM_PER_WORKER")

Ersetzen Sie TARGET_PARALLELISM_PER_WORKER durch einen Wert, der für Ihren Anwendungsfall geeignet ist. Allgemeine Informationen zur Auswahl eines guten Startwerts finden Sie in dieser Anleitung.

Wert für den Hinweis zur Worker-Parallelität auswählen

Für ML-Anwendungsfälle entspricht ein guter Startwert der Anzahl der Modelle, die parallel in jedem Worker ausgeführt werden. Dieser Wert ist durch die Kapazität der Beschleuniger auf dem Worker und die Größe des Modells begrenzt.

Bei anderen Anwendungsfällen ist die Pipeline entweder speicher- oder CPU-gebunden. Verwenden Sie bei Pipelines mit begrenztem Arbeitsspeicher das Arbeitsspeicherlimit, um die maximale parallele Verarbeitung zu berechnen. Für CPU-gebundene Pipelines wird empfohlen, die Standardrichtlinie für das Autoscaling beizubehalten, anstatt einen Parallelitätshinweis anzugeben.

Sie können den Wert optimieren, um die Verarbeitungsanforderungen anderer Phasen zu erfüllen, z. B. das Schreiben in eine Senke. Wenn Sie den Wert um 1 oder 2 erhöhen, wenn die Modellparallelität 2 beträgt, wird die schnellere Verarbeitungszeit beim Schreiben in die Senke erkannt, da mehr Spielraum für die Verarbeitung in anderen Phasen vorhanden ist. Wenn Ihre Pipeline nicht am Shuffle beteiligt ist und Transformationen in einer einzigen Phase zusammengeführt werden, müssen Sie den Wert für andere Transformationen nicht anpassen.

Dieser Wert kann auch angepasst werden, um die Auswirkungen akzeptabler Backlog-Verzögerungen zu simulieren. Wenn Sie beispielsweise eine Verzögerung von maximal 10 Minuten akzeptieren und die durchschnittliche Verarbeitungszeit Ihres Modells 1 Minute beträgt, können Sie den Wert um 1 erhöhen, vorausgesetzt, die maximale Anzahl von Workern ist auf 10 festgelegt.

GPU-intensive Autoscaling-Heuristik

In der GPU-intensiven Einstellung, die durch den Parallelitätshinweis angegeben wird, berücksichtigt Dataflow beim Autoscaling mehrere Faktoren. Diese Faktoren umfassen:

  • Verfügbare Schlüssel: Schlüssel sind die grundlegende Einheit der Parallelität in Dataflow.
  • Maximale Anzahl aktiver Bundles pro Worker. Dies ist die maximale ideale Anzahl von parallelen Verarbeitungsvorgängen innerhalb des Workers.

Die allgemeine Idee hinter Skalierungsentscheidungen besteht darin, die Worker zu berechnen, die für die aktuelle Last erforderlich sind, wie durch verfügbare Schlüssel signalisiert. Wenn beispielsweise 100 Schlüssel verarbeitet werden können und die maximale Parallelität pro Worker 10 beträgt, sollten Sie insgesamt 10 Worker haben.

Wenn Ihre Pipeline komplex ist und sowohl eine hohe GPU-intensive Arbeitslast als auch zahlreiche CPU-intensive Transformationen aufweist, empfehlen wir, die richtige Anpassung zu aktivieren. So kann der Dienst gut zwischen CPU- und GPU-intensiven Aufgaben unterscheiden und jeden Worker-Pool entsprechend skalieren.

Latenzstufe festlegen

Beim horizontalen Autoscaling von Dataflow wird die Rückstandsdauer verwendet, um zu bestimmen, wann Worker skaliert werden sollen. Standardmäßig strebt Dataflow eine Rückstandsdauer von weniger als 15 Sekunden an. Dies ist für Echtzeitarbeitslasten geeignet, kann aber zu höheren Ressourcenkosten führen.

Bei Streamingjobs, die Streaming Engine verwenden, können Sie den Backlog-Schwellenwert konfigurieren, indem Sie eine Latenzstufe auswählen. Eine Latenzstufe wird einer Ziel-Backlog-Dauer zugeordnet, sodass Sie die Empfindlichkeit des Autoscalers gegenüber der Backlog-Dauer konfigurieren können. Eine Autoscaling-Entscheidung wird nur ausgelöst, wenn die Rückstandsdauer die ausgewählte Stufe mehrere Minuten lang überschreitet.

In der folgenden Tabelle werden die verfügbaren Latenzstufen beschrieben:

Latenzstufe Zulässige geschätzte Rückstandszeit Vorgesehener Anwendungsfall
low_latency Weniger als 15 Sekunden Priorisiert schnelles Hochskalieren, um den Rückstand zu minimieren. Standardwert, der ausgewählt wird, wenn keine Stufe angegeben ist
medium_latency Weniger als 2 Minuten Ausgewogener Mittelweg zwischen Latenz und Ressourcenkosten.
high_latency Weniger als 10 Minuten Kosteneinsparungen haben Vorrang, da sich Backlogs ansammeln können. Für Arbeitslasten mit geringer Latenz konzipiert.

Wenn Sie die Latenzstufe beim Erstellen eines Jobs konfigurieren möchten, legen Sie die Pipelineoption enable_latency_tier_lightweight_update fest:

--experiments=enable_latency_tier_lightweight_update=TIER

Ersetzen Sie TIER durch eine der verfügbaren Latenzstufen (z. B. medium_latency).

Latenzstufe aktualisieren

Wenn Sie die Latenzstufe während der Ausführung eines Jobs aktualisieren möchten, führen Sie mit dem Befehl gcloud dataflow jobs update-options ein In-Flight-Update durch:

gcloud dataflow jobs update-options \
  --region=REGION \
  --latency-tier=TIER \
  JOB_ID

Ersetzen Sie Folgendes:

  • REGION: Die Regions-ID des regionalen Endpunkts des Jobs.
  • JOB_ID: Die ID des zu aktualisierenden Jobs.
  • TIER: die Ziellatenzstufe. Einer der folgenden Werte: low_latency, medium_latency oder high_latency

Verwenden Sie den folgenden Befehl, um die Latenzstufe zurückzusetzen und das Standardverhalten mit niedriger Latenz wiederherzustellen:

gcloud dataflow jobs update-options \
  --unset-latency-tier \
  --region=REGION \
  JOB_ID

Autoscaling-Änderungen planen

Für Streamingjobs, die die Streaming Engine verwenden, können Sie Autoscaling-Zeitpläne konfigurieren, um Parameterüberschreibungen während wiederkehrender Zeitfenster automatisch anzuwenden. Das ist nützlich, um vorhersehbare Schwankungen der Arbeitslast zu antizipieren, z. B. das Hochskalieren während der Hauptgeschäftszeiten oder das Herunterskalieren während der Nebenzeiten, ohne den Job jedes Mal manuell aktualisieren zu müssen. Für jeden Job können bis zu 10 Zeitpläne angegeben werden.

Ein Autoscaling-Zeitplan gibt Folgendes an:

  • Zeitplanstart: Ein Crontab-Ausdruck, der bestimmt, wann der Zeitplan ausgelöst wird.
  • Dauer: Die Zeitspanne in Sekunden, für die die Überschreibungen aktiv bleiben. Muss mindestens 5 Minuten betragen.
  • Zeitzone: Eine optionale Zeitzone aus der tz-Datenbank (z. B. America/New_York). Standardmäßig ist UTC festgelegt.
  • Priorität: Eine optionale Priorität für den Zeitplan, wobei größere Werte eine höhere Priorität angeben. Zeitpläne mit höherer Priorität werden zuerst angewendet. Wenn ein Zeitplan bereits aktiv ist, wenn ein Zeitplan mit höherer Priorität angewendet wird, überschreibt der Zeitplan mit höherer Priorität den vorhandenen Zeitplan. Wenn zwei Zeitpläne dieselbe Priorität haben, wird der zuletzt geänderte Zeitplan angewendet.
  • Parameterüberschreibungen: Die Autoscaling-Einstellungen, die während des aktiven Zeitfensters verwendet werden sollen, einschließlich der Mindestanzahl von Workern, der maximalen Anzahl von Workern und des Hinweises zur Worker-Auslastung.

Wenn das geplante Zeitfenster endet, setzt Dataflow das Autoscaling-Verhalten automatisch auf die Standardeinstellungen des Jobs zurück. Sie können mehrere Zeitpläne für einen einzelnen Job definieren.

Autoscaling-Zeitplan beim Jobstart festlegen

Wenn Sie beim Starten eines neuen Streamingjobs einen anfänglichen Autoscaling-Zeitplan festlegen möchten, geben Sie die Pipelineoption autoscaling_schedule für das Experiment an oder fügen Sie das Feld runtimeUpdatableParams.schedules ein, wenn Sie einen Job mit der REST API erstellen.

Geben Sie das Experiment autoscaling_schedule als durch Semikolons getrennten String von key:value-Paaren mit den folgenden Attributen an:

Erforderlich:

  • name: eine eindeutige Kennung für den Zeitplan
  • crontab: ein Crontab-Ausdruck, der angibt, wann der Zeitplan ausgelöst wird
  • duration: die Dauer in Sekunden, für die der Zeitplan aktiv bleibt

Optional:

  • timezone: die Zeitzone aus der tz-Datenbank (z. B. America/New_York). Standardmäßig UTC.
  • min_workers: die Mindestanzahl von Workern, die während des Zeitplans zugewiesen werden sollen
  • max_workers: die maximale Anzahl von Workern, die während des Zeitplans zugewiesen werden sollen
  • cpu_utilization_target: die CPU-Zielauslastung der Worker während des Zeitplans im Bereich [0,1, 0,9]
  • latency_tier: die Ziellatenzstufe (low_latency, medium_latency oder high_latency)

  • priority: die Priorität des Zeitplans, wobei größere Werte eine höhere Priorität angeben

Java

--experiments=autoscaling_schedule="name=SCHEDULE_NAME;crontab=CRONTAB_EXPRESSION;duration=DURATION_SECONDS;timezone=TIMEZONE;min_workers=MINIMUM_WORKERS;max_workers=MAXIMUM_WORKERS;cpu_utilization_target=TARGET_UTILIZATION;latency_tier=LATENCY_TIER;priority=PRIORITY"

Python

--experiments=autoscaling_schedule="name=SCHEDULE_NAME;crontab=CRONTAB_EXPRESSION;duration=DURATION_SECONDS;timezone=TIMEZONE;min_workers=MINIMUM_WORKERS;max_workers=MAXIMUM_WORKERS;cpu_utilization_target=TARGET_UTILIZATION;latency_tier=LATENCY_TIER;priority=PRIORITY"

Go

--experiments=autoscaling_schedule="name=SCHEDULE_NAME;crontab=CRONTAB_EXPRESSION;duration=DURATION_SECONDS;timezone=TIMEZONE;min_workers=MINIMUM_WORKERS;max_workers=MAXIMUM_WORKERS;cpu_utilization_target=TARGET_UTILIZATION;latency_tier=LATENCY_TIER;priority=PRIORITY"

REST

Verwenden Sie die Methode projects.locations.jobs.create und fügen Sie das Objekt runtimeUpdatableParams.schedules in den Anfragetext ein:

POST https://dataflow.googleapis.com/v1b3/projects/PROJECT_ID/locations/REGION/jobs
{
"name": "JOB_NAME",
"environment": { ... },
"runtimeUpdatableParams": {
  "schedules": [
    {
      "name": "SCHEDULE_NAME",
      "crontab": "CRONTAB_EXPRESSION",
      "duration": "DURATION_SECONDSs",
      "timeZone": "TIMEZONE",
      "priority": PRIORITY,
      "parameters": {
        "minWorkerCount": MINIMUM_WORKERS,
        "maxWorkerCount": MAXIMUM_WORKERS,
        "cpuUtilizationTarget": TARGET_UTILIZATION,
        "latencyTarget": LATENCY_TIER
      }
    }
  ]
}
}

Autoscaling-Zeitplan für einen laufenden Job erstellen oder aktualisieren

Wenn Sie einen Autoscaling-Zeitplan für einen laufenden Job erstellen oder aktualisieren möchten, führen Sie eine Aktualisierung während der Übertragung durch:

gcloud

Verwenden Sie den Befehl gcloud dataflow jobs update-options mit dem Flag --set-schedule:

gcloud dataflow jobs update-options \
  --region=REGION \
  --set-schedule=SCHEDULE_NAME \
  --autoscaling-schedule="CRONTAB_EXPRESSION" \
  --autoscaling-schedule-duration-seconds=DURATION_SECONDS \
  --autoscaling-schedule-timezone=TIMEZONE \
  --autoscaling-min-workers=MINIMUM_WORKERS \
  --autoscaling-max-workers=MAXIMUM_WORKERS \
  --autoscaling-worker-utilization-hint=TARGET_UTILIZATION \
  --autoscaling-latency-tier=LATENCY_TIER \
  --autoscaling-schedule-priority=PRIORITY \
  JOB_ID

Ersetzen Sie Folgendes:

  • REGION: Die Regions-ID des regionalen Endpunkts des Jobs.
  • SCHEDULE_NAME: eine eindeutige Kennung für den Zeitplan
  • CRONTAB_EXPRESSION: ein Crontab-Ausdruck, der angibt, wann der Zeitplan ausgelöst wird (z. B. "0 0 * * FRI")
  • DURATION_SECONDS: die Dauer in Sekunden, für die der Zeitplan aktiv ist (z. B. 3600)
  • TIMEZONE: die Zeitzone für den Zeitplan aus der tz-Datenbank (z. B. America/New_York). Wenn keine Angabe erfolgt, wird standardmäßig UTC verwendet.
  • MINIMUM_WORKERS: die Mindestanzahl von Workern, die während des Zeitplans zugewiesen werden sollen
  • MAXIMUM_WORKERS: die maximale Anzahl von Workern, die während des Zeitplans zugewiesen werden sollen
  • LATENCY_TIER: die Ziellatenzstufe (low_latency, medium_latency oder high_latency)
  • JOB_ID: Die ID des zu aktualisierenden Jobs.

Beim Erstellen eines neuen Zeitplans sind sowohl --autoscaling-schedule als auch --autoscaling-schedule-duration-seconds erforderlich. Wenn Sie einen vorhandenen Zeitplan ändern möchten, geben Sie --set-schedule und nur die Parameter an, die Sie aktualisieren möchten.

REST

Verwenden Sie die Methode projects.locations.jobs.update:

PUT https://dataflow.googleapis.com/v1b3/projects/PROJECT_ID/locations/REGION/jobs/JOB_ID?updateMask=runtimeUpdatableParams.schedules
{
  "runtimeUpdatableParams": {
    "schedules": [
      {
        "name": "SCHEDULE_NAME",
        "crontab": "CRONTAB_EXPRESSION",
        "duration": "DURATION_SECONDSs",
        "timeZone": "TIMEZONE",
        "priority": PRIORITY,
        "parameters": {
          "minWorkerCount": MINIMUM_WORKERS,
          "maxWorkerCount": MAXIMUM_WORKERS,
          "cpuUtilizationTarget": TARGET_UTILIZATION,
          "latencyTarget": LATENCY_TIER
        }
      }
    ]
  }
}

Ersetzen Sie Folgendes:

  • PROJECT_ID: Die Google Cloud Projekt-ID des Dataflow-Jobs
  • REGION: Die Regions-ID des regionalen Endpunkts des Jobs.
  • JOB_ID: Die ID des zu aktualisierenden Jobs.
  • SCHEDULE_NAME: eine eindeutige Kennung für den Zeitplan
  • CRONTAB_EXPRESSION: ein Crontab-Ausdruck, der angibt, wann der Zeitplan ausgelöst wird
  • DURATION_SECONDS: die Dauer in Sekunden, für die der Zeitplan aktiv ist (z. B. 3600)
  • TIMEZONE: die Zeitzone für den Zeitplan aus der tz-Datenbank (z. B. America/New_York)
  • MINIMUM_WORKERS: die Mindestanzahl von Workern, die während des Zeitplans zugewiesen werden sollen
  • MAXIMUM_WORKERS: die maximale Anzahl von Workern, die während des Zeitplans zugewiesen werden sollen
  • TARGET_UTILIZATION: ein Wert im Bereich [0,1, 0,9]

Autoscaling-Zeitplan entfernen

Wenn Sie einen bestimmten Autoscaling-Zeitplan oder alle Zeitpläne aus einem Job entfernen möchten, führen Sie ein In-Flight-Update durch:

gcloud

Wenn Sie einen einzelnen Zeitplan entfernen möchten, geben Sie das Flag --unset-schedule an:

gcloud dataflow jobs update-options \
  --region=REGION \
  --unset-schedule=SCHEDULE_NAME \
  JOB_ID

Wenn Sie alle Zeitpläne aus einem Job entfernen möchten, geben Sie das Flag --unset-schedules an:

gcloud dataflow jobs update-options \
  --region=REGION \
  --unset-schedules \
  JOB_ID

REST

Verwenden Sie die Methode projects.locations.jobs.update mit updateMask=runtimeUpdatableParams.schedules. Lassen Sie dabei den Zeitplan aus dem Array schedules weg oder geben Sie eine leere schedules-Liste an, um alle Zeitpläne zu entfernen:

PUT https://dataflow.googleapis.com/v1b3/projects/PROJECT_ID/locations/REGION/jobs/JOB_ID?updateMask=runtimeUpdatableParams.schedules
{
  "runtimeUpdatableParams": {
    "schedules": []
  }
}

Informationen zur Fehlerbehebung bei Autoscaling-Zeitplänen finden Sie unter Fehlerbehebung bei Autoscaling-Zeitplänen.

Heuristik für Streaming-Autoscaling

Bei Streamingpipelines besteht das Ziel des horizontalen Autoscalings darin, den Rückstand zu minimieren und gleichzeitig die Worker-Auslastung und den Durchsatz zu maximieren. Außerdem soll dadurch schnell auf Lastspitzen reagiert werden können.

Dataflow berücksichtigt beim Autoscaling mehrere Faktoren, darunter:

  • Rückstand. Die geschätzte Rückstandszeit wird sowohl aus dem Durchsatz als auch aus den Rückstandbyte berechnet, die noch aus der Eingabequelle verarbeitet werden müssen. Eine Pipeline gilt als „im Rückstand“, wenn die geschätzte Rückstandszeit über dem konfigurierten Schwellenwert liegt. Standardmäßig beträgt dieser Grenzwert 15 Sekunden. Weitere Informationen finden Sie unter Latenzstufe festlegen.

  • CPU-Zielauslastung. Das Standardziel für die durchschnittliche CPU-Auslastung ist 0,8. Sie können diesen Wert überschreiben.

  • Verfügbare Schlüssel: Schlüssel sind die grundlegende Einheit der Parallelität in Dataflow.

In einigen Fällen verwendet Dataflow die folgenden Faktoren für Autoscaling-Entscheidungen. Wenn diese Faktoren für Ihren Job verwendet werden, sehen Sie diese Informationen auf dem Tab Autoscaling für Messwerte.

  • Bei der schlüsselbasierten Drosselung wird die Anzahl der vom Job empfangenen Verarbeitungsschlüssel verwendet, um die Obergrenze für Nutzer-Worker zu berechnen, da jeder Schlüssel nur von einem Worker auf einmal verarbeitet werden kann.

  • Downscale-Dämpfung. Wenn Dataflow feststellt, dass instabile Autoscaling-Entscheidungen getroffen wurden, wird die Rate der Herunterskalierung verlangsamt, um die Stabilität zu verbessern.

  • CPU-basierte Skalierung verwendet eine hohe CPU-Auslastung als Hochskalierungskriterium.

  • Bei Streamingjobs ohne Streaming Engine kann die Skalierung durch die Anzahl der Persistent Disks eingeschränkt sein. Weitere Informationen finden Sie unter Autoscaling-Bereich festlegen.

  • GPU-intensives Autoscaling, wenn durch Festlegen des Worker-Parallelitätshinweises aktiviert. Weitere Informationen finden Sie unter GPU-intensive Autoscaling-Heuristik.

Hochskalieren. Wenn eine Streamingpipeline für einige Minuten Rückstände bei ausreichender Parallelität auf den Workern hat, wird Dataflow hochskaliert. Dataflow versucht, den Rückstand unter Berücksichtigung des aktuellen Durchsatzes pro Worker innerhalb von etwa 150 Sekunden nach dem Hochskalieren zu löschen. Wenn es Rückstände gibt, der Worker jedoch nicht genügend Parallelität für zusätzliche Worker hat, wird die Pipeline nicht hochskaliert. (Wenn Sie die Anzahl der Worker über die Anzahl der für die parallele Verarbeitung verfügbaren Schlüssel hinaus skalieren, wird der Rückstand nicht schneller verarbeitet.)

Herunterskalieren Wenn das Autoscaling eine Entscheidung zum Herunterskalieren trifft, ist der Rückstand der höchste Prioritätsfaktor. Das Autoscaling zielt auf einen Rückstand basierend auf der Latenzstufe ab. Wenn der Rückstand mehrere Minuten lang ausreichend unter das Ziel fällt und die durchschnittliche Worker-Auslastung unter dem CPU-Auslastungsziel liegt, wird Dataflow herunterskaliert. Solange der Rückstand akzeptabel ist, versucht das Autoscaling, die CPU-Auslastung nahe der CPU-Zielauslastung zu halten. Wenn die Auslastung jedoch bereits nahe genug am Ziel liegt, kann der Autoscaler die Anzahl der Worker unverändert lassen, da jeder Schritt zur Herunterskalierung mit Kosten verbunden ist.

Streaming Engine verwendet auch ein Verfahren für vorausschauendes Autoscaling, das auf dem Timer-Rückstand basiert. Unbegrenzte Daten in einer Streamingpipeline werden in Fenster aufgeteilt, die nach Zeitstempeln gruppiert sind. Am Ende eines Fensters werden Timer für jeden in diesem Fenster verarbeiteten Schlüssel ausgelöst. Das Auslösen eines Timers zeigt an, dass das Fenster für einen bestimmten Schlüssel abgelaufen ist. Streaming Engine kann den Timer-Rückstand messen und vorhersagen, wie viele Timer am Ende eines Fensters ausgelöst werden sollen. Unter Verwendung des Timer-Rückstands als Signal kann Dataflow die Verarbeitungsmenge schätzen, die bei zukünftigen Timern ausgeführt werden muss. Basierend auf der geschätzten zukünftigen Arbeitslast wird Dataflow automatisch im Voraus skaliert, um die erwartete Nachfrage zu erfüllen.

Messwerte

Fragen Sie die folgenden Messwerte ab, um die aktuellen Autoscaling-Limits für einen Job zu ermitteln:

  • job/max_worker_instances_limit: Maximale Anzahl von Workern.
  • job/min_worker_instances_limit: Mindestanzahl von Workern.

Fragen Sie die folgenden Messwerte ab, um Informationen zur Worker-Auslastung zu erhalten:

  • job/aggregated_worker_utilization: Die aggregierte Worker-Auslastung.
  • job/worker_utilization_hint: Der aktuelle Hinweis zur Worker-Auslastung.

Fragen Sie den folgenden Messwert ab, um Informationen zum Verhalten des Autoscalings zu erhalten:

  • job.worker_utilization_hint_is_actively_used: Gibt an, ob das Autoscaling den Hinweis zur Worker-Auslastung aktiv verwendet. Wenn andere Faktoren den Hinweis überschreiben, wenn dieser Messwert erfasst wird, ist der Wert false.
  • job/horizontal_worker_scaling: Beschreibt die vom Autoscaling getroffenen Entscheidungen. Dieser Messwert enthält die folgenden Labels:
    • direction: Gibt an, ob das Autoscaling hoch- oder herunterskaliert wurde oder keine Aktion ausgeführt hat.
    • rationale: Gibt die Begründung für die Entscheidung des Autoscalers an.

Weitere Informationen finden Sie unter Cloud Monitoring-Messwerte. Diese Messwerte werden auch in den Monitoring-Diagrammen für das Autoscaling angezeigt.

Nächste Schritte