In Streamingpipelines mit einem großen Volumen 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 herunterskalieren sollte.
Das Dataflow-Autoscaling hat Standardeinstellungen, die für viele Arbeitslasten geeignet sind. Es empfiehlt sich jedoch, dieses Verhalten für Ihr spezifisches Szenario gegebenenfalls anzupassen. 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 der Worker, die zugewiesen werden sollen.
- Hinweis zur Worker-Auslastung: Die CPU-Zielauslastung für die Worker.
Autoscaling-Bereich festlegen
Wenn Sie einen neuen Streamingjob erstellen, können Sie die anfängliche und die maximale Anzahl der Worker 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, 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 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, müssen Sie dafür sorgen, dass der Wert genügend Laufwerke für die Pipeline bietet. Berücksichtigen Sie beim Festlegen des Anfangswerts ein zukünftiges 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 Streaming Engine verwenden, können Sie die Mindest- und Höchstanzahl der Worker anpassen, ohne den Job anzuhalten oder zu ersetzen. Verwenden Sie zum Anpassen dieser Werte eine Jobaktualisierung im laufenden Betrieb. 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
}
}
Für Jobs ohne Streaming Engine 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, 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] setzen.
Legen Sie einen niedrigeren CPU-Auslastungswert fest, wenn Sie niedrigere Spitzenlatenzen erreichen möchten. Durch einen niedrigeren Wert kann Dataflow als Reaktion auf die steigende Worker-Auslastung aggressiver horizontal skalieren und zur Verbesserung der Stabilität konservativer herunterskalieren. 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 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 niedriger halten möchten. Ein höherer Wert verhindert eine übermäßige Hochskalierung, auf Kosten einer höheren Latenz.
Um den Auslastungshinweis beim Ausführen eines Jobs zu konfigurieren, legen Sie die Dienstoption worker_utilization_hint fest:
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].
Bei neuen Pipelines empfehlen wir Ihnen, mit der Standardeinstellung unter realistischen Lasten zu testen. Prüfen Sie dann das Autoscaling-Verhalten in Bezug auf Ihre Pipeline und nehmen Sie bei Bedarf Anpassungen vor.
Der Auslastungshinweis ist nur einer der Faktoren, die 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 eine Aktualisierung während der Übertragung durch, um den Auslastungshinweis während der Ausführung eines Jobs zu aktualisieren:
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
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 mehr als 15 Sekunden beträgt.
CPU-Zielauslastung. Das Standardziel für die durchschnittliche CPU-Auslastung beträgt 0,8. Sie können diesen Wert überschreiben.
Verfügbare Schlüssel: Schlüssel sind die grundlegende Parallelitätseinheit in Dataflow.
In einigen Fällen verwendet Dataflow bei Autoscaling-Entscheidungen die folgenden Faktoren. 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.
Dämpfung herunterskalieren. Wenn Dataflow erkennt, 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 kann die Skalierung durch die Anzahl der Persistent Disks eingeschränkt sein. 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 trägt nicht dazu bei, den Rückstand schneller zu verarbeiten.)
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 von nicht mehr als 15 Sekunden ab. Wenn der Rückstand unter 10 Sekunden 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 bereits ausreichend nah 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 Einblicke in das 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 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 wurde oder keine Aktion ausgeführt hat.rationale: Gibt die Gründe für die Entscheidung des Autoscalings an.
Weitere Informationen finden Sie unter Cloud Monitoring-Messwerte. Diese Messwerte werden auch in den Monitoring-Diagrammen für das Autoscaling angezeigt.