Flexibilität und Effizienz in Dataflow

In diesem Dokument wird „Design for Flexibility and Efficiency“ (DFE) beschrieben, eine Reihe von Best Practices für die Architektur, mit denen sich robuste Dataflow-Pipelines erstellen lassen.

Der Übergang von starren Infrastrukturbeschränkungen zu flexiblen Ressourcendefinitionen bietet folgende Vorteile:

  • Verfügbarkeit von Compute-Ressourcen maximieren
  • Sorgen Sie für eine nahtlose automatische Skalierung bei hoher regionaler Nachfrage.
  • Verzögerungen beim Start von Pipelines verhindern und Kapazitätsengpässe beseitigen

Anstatt Ihre Pipeline beispielsweise auf einen bestimmten Maschinentyp in einer Zone zu beschränken, z. B. n1-standard-4-Worker in us-central1-a, können Sie Mindestressourcenanforderungen festlegen (z. B. 4 vCPUs und 16 GB RAM). Wenn es bei us-central1-a oder der N1-Maschinenreihe zu vorübergehenden Kapazitätsbeschränkungen kommt, kann Dataflow automatisch kompatible Worker-VMs in anderen Zonen und Maschinenfamilien (z. B. E2, N2 oder N2D) bereitstellen. So kann Ihre Pipeline gestartet und skaliert werden, ohne dass Sie auf einen einzelnen eingeschränkten Hardwarepool warten müssen.

Dieses Dokument richtet sich an Data Engineers, Cloud-Architekten und Plattformadministratoren, die Dataflow-Arbeitslasten verwalten und die Zuverlässigkeit, den Durchsatz und die Infrastrukturverfügbarkeit von Pipelines optimieren möchten.

Übersicht über DFE

Dataflow ist ein vollständig verwalteter, serverloser Datenverarbeitungsdienst, der dynamisch Compute Engine-VM-Instanzen (virtuelle Maschinen) zur Ausführung von Apache Beam-Pipelines bereitstellt. Bei Batchverarbeitungs- und Streaming-Pipelines im großen Maßstab werden Worker-Pools häufig auf Dutzende oder Hunderte von VM-Instanzen skaliert.

Bei Pipelines, die mit starren Infrastrukturbeschränkungen konfiguriert sind, kann es bei hoher Nachfrage zu Bereitstellungsverzögerungen kommen. Beispiele für starre Einschränkungen:

  • Ein einzelner Maschinentyp wie n1-standard-4 wird fest codiert.
  • Die Pipeline wird an eine bestimmte Compute Engine-Zone angepinnt.

Wenn für diesen Maschinentyp oder diese Zone vorübergehend eine hohe Nachfrage besteht, kann Dataflow keine Rechenressourcen zuweisen. Dies kann zu Verzögerungen bei der Bereitstellung oder zu Fehlern wie ZONE_RESOURCE_POOL_EXHAUSTED oder RESOURCE_POOL_EXHAUSTED führen.

Wenn Sie die DFE-Prinzipien anwenden, können Sie Ihre Pipelinearchitektur von starren, statischen Infrastrukturdeklarationen zu flexiblen, anforderungsbasierten Ressourcendefinitionen umstellen. Dank dieser Flexibilität kann Dataflow die Rechenleistung dynamisch auf verschiedene verfügbare Hardwarepools in Google Cloudverteilen. So können Sie die Verfügbarkeit von Rechenleistung maximieren und gleichzeitig den Betriebsaufwand minimieren.

Best Practices für DFE

Wenn Sie die folgenden Best Practices anwenden, können Sie die Verfügbarkeit von Rechenressourcen maximieren, die Reaktionsfähigkeit der automatischen Skalierung verbessern und robuste Pipelines erstellen.

Automatische VM-Auswahl aktivieren

Anstatt einen statischen Maschinentyp mit der Pipelineoption worker machine type fest zu codieren, verwenden Sie Auto VM selection (Automatische VM-Auswahl) mit Apache Beam-Ressourcenhinweisen. Wenn Sie Mindestanforderungen an Ressourcen (min_ram oder cpu_count) angeben, aktiviert Dataflow automatisch die Instanzflexibilität und stellt Worker aus einer Liste kompatibler Maschinentypen bereit.

Unterstützung von Arbeitslasten:

  • Batch-Pipelines:Die richtige Anpassung und die automatische VM-Auswahl werden automatisch aktiviert, wenn Sie Ressourcenhinweise angeben.
  • Streamingpipelines:Für die richtige Dimensionierung muss die Pipelineoption --experiments=enable_streaming_rightfitting zusammen mit dem horizontalen Autoscaling (standardmäßig aktiviert) und Streaming Engine (--enable_streaming_engine) festgelegt werden.

Wenn Sie die automatische VM-Auswahl konfigurieren möchten, geben Sie die Mindestanforderungen an Ressourcen (min_ram oder cpu_count) auf Pipelineebene an. Verwenden Sie dazu Befehlszeilenoptionen, SDK-Pipelineoptionen oder Ausführungsparameter für flexible Vorlagen. Eine ausführliche Anleitung und Codebeispiele für Java und Python finden Sie unter Ressourcenhinweise verwenden.

Regionale Worker-Platzierung verwenden (zonales Pinning vermeiden)

Konfigurieren Sie Dataflow so, dass Worker-VMs dynamisch in jeder fehlerfreien Zone in der ausgewählten Region geplant werden.

Geben Sie die Pipeline-Option --region an und lassen Sie --zone und --worker_zone weg. Beispiel:

--region=us-central1

Status und Shuffle mit verwalteten Diensten entkoppeln

Bei Pipelines, in denen keine verwalteten Backend-Dienste verwendet werden, werden Shuffle-Datenvorgänge und die Speicherung des Streamingstatus direkt auf den Festplatten und im Arbeitsspeicher der Worker-VM ausgeführt. Diese enge Kopplung erfordert größere Worker-Laufwerke und bindet das Überleben von Arbeitslasten an bestimmte VM-Instanzen, was den Worker-Ersatz bei Kapazitätsbeschränkungen erschwert.

  • Für Batchjobs: Dataflow Shuffle verwenden: Dataflow Shuffle ist standardmäßig für Batchpipelines aktiviert, die auf unterstützten Worker-Maschinentypen ausgeführt werden. Shuffle-Vorgänge werden von Worker-VMs an einen dedizierten, von Google verwalteten Backend-Dienst ausgelagert.
  • Für Streamingjobs: Streaming Engine verwenden: Die Streaming Engine lagert die Speicherung des Fensterstatus und die Timerverwaltung von Worker-VMs auf eine spezielle, hochreaktionsfähige Backend-Infrastruktur aus. Für Pipelines, die das Apache Beam SDK 2.30.0 oder höher verwenden, ist Streaming Engine standardmäßig aktiviert. Um sie explizit zu aktivieren, übergeben Sie die Pipelineoption --enable_streaming_engine.

Flexible Ressourcenplanung (FlexRS) für Batchpipelines verwenden

Verwenden Sie für nicht zeitkritische Batcharbeitslasten wie nächtliche ETL-Prozesse, Data Lake-Aufnahmen oder tägliche Zusammenfassungen die flexible Ressourcenplanung (FlexRS).

Legen Sie die Pipelineoption „flexRS-Ziel“ fest, um FlexRS zu aktivieren:

  • Für Python-Pipelines: --flexrs_goal=COST_OPTIMIZED
  • Für Java-Pipelines: --flexRSGoal=COST_OPTIMIZED

Flexible Launcher-VM-Typen für Flex-Vorlagen konfigurieren

Beim Starten von Pipelines mit Flex-Vorlagen wird für die Pipeline-Launcher-VM standardmäßig e2-standard-2 verwendet. Die Standard-VM funktioniert in den meisten Fällen. Wenn Sie jedoch Kapazitätsbeschränkungen feststellen, können Sie die Konfiguration anpassen, indem Sie die Option --launcher-machine-type beim Ausführen des Befehls gcloud dataflow flex-template run verwenden:

gcloud dataflow flex-template run my-job \
    --template-file-gcs-location="gs://my-bucket/template.json" \
    --region="us-central1" \
    --launcher-machine-type="n2-standard-2"

Operative Aspekte und Kompromisse

Durch die Übernahme von Best Practices für DFE werden die Verfügbarkeit von Rechenressourcen, die Reaktionsfähigkeit der automatischen Skalierung und die betriebliche Zuverlässigkeit erheblich verbessert. Berücksichtigen Sie jedoch die folgenden betrieblichen Faktoren und Kompromisse beim Entwerfen Ihrer Architektur:

Überlegungen zur automatischen VM-Auswahl

  • Zuverlässigkeit im Vergleich zu Spitzenleistung:Bei der automatischen VM-Auswahl wird die Zuverlässigkeit des Jobstarts und die Verfügbarkeit von Rechenressourcen gegenüber der Spitzenleistung bei der Ausführung priorisiert. Da Dataflow aus mehreren Kandidaten-Maschinenfamilien (z. B. E2, N2, N4 und N2D) bereitgestellt wird, können die Laufzeitleistung und der Durchsatz je nach bereitgestellter Maschinenfamilie leicht variieren. Bei rechenintensiven Arbeitslasten mit strengen SLAs für die Ausführung sollten Sie Ihre Pipeline mit der automatischen VM-Auswahl testen, um eine Leistungsbaseline zu erstellen, bevor Sie sie allgemein bereitstellen. Wenn für eine Arbeitslast eine bestimmte Hardwareplattform oder Taktgeschwindigkeit erforderlich ist und Sie Kapazitätsbeschränkungen in Kauf nehmen können, können Sie weiterhin einen bestimmten Maschinentyp festlegen.
  • Compute Engine-Kontingent für Kandidatenfamilien:Da bei der automatischen VM-Auswahl Worker aus mehreren Kandidatenmaschinenfamilien bereitgestellt werden können, muss Ihr Google Cloud Projekt über ein ausreichendes Compute Engine-Kontingent für vCPUs und Arbeitsspeicher für jede Kandidatenfamilie in Ihrer Zielregion verfügen. Wenn in der primären Familie ein Kapazitätsmangel auftritt und Ihrem Projekt das Kontingent für die Fallback-Familie fehlt, schlägt die Worker-Bereitstellung mit dem Fehler QUOTA_EXCEEDED fehl.
  • Voraussetzung für Streamingpipelines:Für Streamingpipelines sind die Funktionen „Right-Fitting“ und „Auto VM Selection“ nicht standardmäßig aktiviert. Sie müssen --experiments=enable_streaming_rightfitting explizit angeben und darauf achten, dass sowohl Streaming Engine (--enable_streaming_engine) als auch horizontales Autoscaling aktiv sind.

  • Konfigurationsausschlüsse:Die automatische VM-Auswahl wird automatisch umgangen oder nicht unterstützt, wenn Sie eine der Funktionen oder Optionen in der folgenden Tabelle konfigurieren:

    Funktion Flag oder Konfigurationsoption Hinweise
    Explizite Maschinentypen --worker_machine_type oder --machine_type (Python)
    --workerMachineType (Java)    		 Die automatische VM-Auswahl wird zugunsten des angegebenen Maschinentyps umgangen.
    Benutzerdefinierte Laufwerkstypen, bereitgestellte IOPS oder Durchsatz --disk_type, --disk_provisioned_iops oder --disk_provisioned_throughput_mibps Die automatische VM-Auswahl wird umgangen. Das Festlegen einer benutzerdefinierten Laufwerksgröße mit --disk_size_gb wird unterstützt.
    Mindest-CPU-Plattformen --min_cpu_platform (Python)
    --minCpuPlatform (Java)    		 Wenn Sie eine Mindest-CPU-Plattform festlegen, wird die automatische VM-Auswahl umgangen.
    Confidential VM --experiments=enable_confidential_compute Confidential VM-Instanzen werden bei der automatischen VM-Auswahl nicht unterstützt.
    GPU- oder TPU-Beschleuniger Ressourcenhinweis --dataflow_service_options=worker_accelerator=... oder accelerator Die automatische VM-Auswahl gilt nur für Arbeitslasten ohne Beschleuniger.
    Dataflow Prime --dataflow_service_options=enable_prime Dataflow Prime verwendet vertikales Autoscaling und dynamische Anpassung an die richtige Größe anstelle der automatischen VM-Auswahl.
    Flexible Resource Scheduling (FlexRS) --flexrs_goal=COST_OPTIMIZED (Python)
    --flexRSGoal=COST_OPTIMIZED (Java)    		 FlexRS verwaltet einen eigenen Worker-Pool und einen eigenen Planungsbuffer.

Abwägungen bei Flexible Resource Scheduling (FlexRS)

  • Zeitfenster für die Planung: Bei FlexRS kann es bis zu 6 Stunden dauern, bis die Jobausführung beginnt. Verwenden Sie FlexRS nicht für Pipelines mit strengen SLAs für die Fertigstellungszeit oder engen Downstream-Abhängigkeiten.

Regionale Platzierung und Datenlokalität

  • Voraussetzung für verwalteten Dienst:Die regionale Worker-Platzierung wird nur für Jobs unterstützt, die Dataflow Shuffle für Batch- oder Streaming Engine für Streaming verwenden. Bei Jobs, die diese verwalteten Backend-Dienste nicht verwenden, wird die automatische Zonenauswahl verwendet, bei der eine einzelne beste Zone innerhalb der Region ausgewählt wird.
  • Datenlokalität und regionsübergreifender Egress: Durch die regionale Platzierung werden Worker auf die verfügbaren Zonen in der ausgewählten Region verteilt. Um die Netzwerklatenz zu minimieren und Gebühren für zonenübergreifenden Netzwerk-Egress zu vermeiden, müssen sich alle Datenquellen und ‑senken (z. B. Cloud Storage-Buckets, BigQuery-Datasets und Pub/Sub-Themen) in derselben Region wie Ihr Dataflow-Job befinden.

Compute Engine-Reservierungen

  • Reservierungsaffinität:On-Demand-Dataflow-Jobs nutzen automatisch passende Compute Engine-Reservierungen, die die Reservierungsaffinität ANY verwenden. Die automatische VM-Auswahl unterstützt jedoch nicht die Verwendung von Instanzen aus bestimmten benannten Reservierungen.
  • Eignung für vorübergehende Arbeitslasten:Compute Engine-Reservierungen werden im Allgemeinen nicht für Arbeitslasten empfohlen, die zu Spitzenzeiten, Autoscaling oder kurzlebigen Batches neigen. Außerdem schlägt das Erstellen neuer Reservierungen während eines aktiven zonalen Engpasses mit denselben Kapazitätsbeschränkungen wie die On-Demand-VM-Erstellung fehl.

Nächste Schritte