Bei Streamingpipelines mit einer großen Menge an Eingabedaten besteht im Allgemeinen ein Kompromiss zwischen Kosten und Latenz. Um eine niedrige Latenz zu gewährleisten, muss Dataflow Worker hinzufügen, wenn das Trafficvolumen zunimmt. Ein weiterer Faktor ist, wie schnell die Pipeline als Reaktion auf Änderungen der Eingabedatenrate hoch- oder herunterskaliert werden soll.
Das Dataflow-Autoscaling verfügt über Standardeinstellungen, die für viele Arbeitslasten geeignet sind. Sie können dieses Verhalten jedoch an Ihr spezielles Szenario anpassen. Beispielsweise kann eine höhere durchschnittliche Latenz akzeptabel sein, um Kosten zu senken, oder Sie möchten, dass Dataflow als Reaktion auf Trafficspitzen schneller hochskaliert.
Zum Optimieren des horizontalen Autoscalings können Sie die folgenden Parameter anpassen:
- Autoscaling-Bereich: Die minimale und maximale Anzahl an Workern, die zugewiesen werden sollen.
- Hinweis zur Worker-Auslastung: Die CPU-Zielauslastung für Worker.
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 ausgeführt wird--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 der für Ihre Pipeline verfügbaren Worker
Einfach loslegen (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 der für Ihre Pipeline verfügbaren Worker
Für Streamingjobs, die Streaming Engine verwenden, 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 nichtflüchtige Speicher dem Job zugewiesen werden.
Streamingpipelines werden mit einem festen Pool nichtflüchtiger Speicher bereitgestellt, deren Anzahl --maxNumWorkers entspricht. Während des Streamings werden nichtflüchtige Speicher 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 die Pipeline bereitstellt. Berücksichtigen Sie beim Festlegen des Anfangswerts das zukünftige Wachstum. Informationen zur Leistung von Persistent Disk 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.
Standardmäßig ist die Mindestanzahl von Workern 1 für Streamingjobs, die Streaming Engine verwenden, und (maxNumWorkers/15) aufgerundet für Jobs, die keine Streaming Engine verwenden.
Autoscaling-Bereich aktualisieren
Bei Jobs mit Streaming Engine können Sie die Mindest- und Höchstzahl der Worker anpassen, ohne den Job dabei zu beenden oder zu ersetzen. Verwenden Sie eine Aktualisierung des In-Flight-Jobs, um diese Werte anzupassen. 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 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 ohne Streaming Engine können Sie den vorhandenen Job durch einen aktualisierten Wert von maxNumWorkers ersetzen.
Wenn Sie einen Streamingjob aktualisieren, der keine Streaming Engine verwendet, ist das horizontale Autoscaling für den aktualisierten Job standardmäßig deaktiviert. Geben Sie --autoscalingAlgorithm und --maxNumWorkers für den aktualisierten Job an, damit Autoscaling aktiviert bleibt.
Hinweis zur Worker-Auslastung festlegen
Dataflow verwendet die durchschnittliche CPU-Auslastung als Signal für die Anwendung des horizontalen Autoscalings. Standardmäßig legt Dataflow eine Ziel-CPU-Auslastung von 0,8 fest. Wenn die Auslastung außerhalb dieses Bereichs liegt, fügt Dataflow möglicherweise Worker hinzu oder entfernt sie.
Zur besseren Kontrolle des Autoscaling-Verhaltens können Sie die Ziel-CPU-Auslastung auf einen Wert im Bereich [0,1, 0,9] festlegen.
Legen Sie einen niedrigeren Wert für die CPU-Auslastung fest, wenn Sie niedrigere Spitzenlatenzen erreichen möchten. Durch einen niedrigeren Wert kann Dataflow stärker als Reaktion auf die steigende Worker-Auslastung horizontal skalieren und konservativer herunterskalieren, um die Stabilität zu verbessern. Ein niedrigerer Wert bietet auch mehr Toleranzbereich, wenn die Pipeline in einem stabilen Zustand ausgeführt wird, was im Allgemeinen zu einer niedrigeren Extremwertlatenz führt. (Die Extremwertlatenz misst die längste Wartezeit vor der Verarbeitung eines neuen Eintrags.)
Legen Sie einen höheren Wert fest, wenn Sie Ressourcen sparen und die Kosten bei Trafficspitzen niedrig halten möchten. Ein höherer Wert verhindert eine übermäßige Hochskalierung, allerdings auf Kosten einer höheren Latenz.
Legen Sie die Dienstoption worker_utilization_hint fest, um den Auslastungshinweis beim Ausführen eines Jobs zu konfigurieren:
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].
Einfach loslegen (Go)
--dataflow_service_options=worker_utilization_hint=TARGET_UTILIZATION
Ersetzen Sie TARGET_UTILIZATION durch einen Wert im Bereich [0,1, 0,9].
Bei neuen Pipelines empfehlen wir, mit der Standardeinstellung unter realistischen Lasten zu testen. Prüfen Sie dann das Autoscaling-Verhalten, das auf Ihre Pipeline angewendet wird, und nehmen Sie bei Bedarf Anpassungen vor.
Der Auslastungshinweis ist nur ein Faktor, den Dataflow bei der Entscheidung verwendet, ob Worker skaliert werden sollen. Andere Faktoren wie Rückstand und verfügbare Schlüssel können den Hinweiswert überschreiben. Außerdem ist der Hinweis kein striktes Ziel. Das Autoscaling versucht, die CPU-Auslastung innerhalb des Bereichs des Hinweiswerts zu halten, der aggregierte Auslastungsmesswert kann jedoch höher oder niedriger sein. Weitere Informationen finden Sie unter Streaming-Autoscaling-Heuristik.
Auslastungshinweis aktualisieren
Führen Sie so ein In-Flight-Update durch, um den Auslastungshinweis zu aktualisieren, während ein Job ausgeführt wird:
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 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]
Heuristik für Streaming-Autoscaling
Horizontales Autoscaling von Streamingpipelines hat das Ziel, Rückstände zu minimieren und gleichzeitig die Worker-Auslastung und den Durchsatz zu maximieren. Außerdem sollte 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 mehr als 15 Sekunden beträgt.
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 bei 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.
Herunterskalierungsdämpfung. Wenn Dataflow feststellt, dass instabile Autoscaling-Entscheidungen getroffen wurden, verlangsamt es die Herunterskalierungsrate, um die Stabilität zu verbessern.
CPU-basierte Skalierung verwendet eine hohe CPU-Auslastung als Hochskalierungskriterium.
Bei Streamingjobs ohne Streaming Engine wird die Skalierung möglicherweise durch die Anzahl der nichtflüchtigen Speicher eingeschränkt. Weitere Informationen finden Sie unter Autoscaling-Bereich festlegen.
Hochskalieren. Wenn eine Streamingpipeline mehrere Minuten lang Rückstände bei ausreichender Parallelität auf den Workern hat, wird Dataflow hochskaliert. Dataflow versucht, den Rückstand innerhalb von etwa 150 Sekunden nach dem Hochskalieren auf der Grundlage des aktuellen Durchsatzes pro Worker zu beheben. 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. (Die Skalierung der Anzahl der Worker über die Anzahl der für die parallele Verarbeitung verfügbaren Schlüssel hinaus hilft nicht, den Rückstand schneller zu verarbeiten.)
Herunterskalierung: Wenn das Autoscaling eine Entscheidung zum Herunterskalieren trifft, ist der Rückstand der höchste Prioritätsfaktor. Das Autoscaling zielt auf einen Rückstand von nicht mehr als 15 Sekunden ab. Wenn der Rückstand unter 10 Sekunden sinkt 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 aufrechtzuerhalten. Wenn die Auslastung bereits ausreichend nahe am Ziel liegt, kann das Autoscaling die Anzahl der Worker jedoch unverändert lassen, da jeder Herunterskalierungsschritt Kosten verursacht.
Streaming Engine verwendet auch ein Verfahren für vorausschauendes Autoscaling, das auf dem Timer-Rückstand basiert. Unbegrenzte Daten in einer Streaming-Pipeline 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 zusammengefasste Worker-Auslastung.job/worker_utilization_hint: Der Hinweis zur aktuellen 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 bei der Stichprobe dieses Messwerts überschreiben, ist der Wertfalse.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 oder keine Aktion ausgeführt hat.rationale: Gibt die Begründung für die Entscheidung des Autoscalings an.
Weitere Informationen finden Sie unter Cloud Monitoring-Messwerte. Diese Messwerte werden auch in den Autoscaling-Monitoring-Diagrammen angezeigt.