Die Pipelineentwicklung umfasst verschiedene Phasen und Aufgaben wie die Codeentwicklung, Tests und die Bereitstellung in der Produktion. In diesem Dokument wird Folgendes erläutert:
- Hinweise zu Continuous Integration und Continuous Delivery (CI/CD) zur Unterstützung der automatisierten Build-, Test- und Pipeline-Bereitstellung in verschiedenen Umgebungen.
- Dataflow-Features zur Optimierung der Leistung und Ressourcennutzung in der Produktion
- Ansätze und Watchpoints zum Aktualisieren von Streamingpipelines in der Produktion
- Best Practices zur Verbesserung der Pipeline-Zuverlässigkeit in der Produktion
Continuous Integration
Für Continuous Integration (CI) müssen Entwickler Code häufig in einem gemeinsam genutzten Repository zusammenführen. Dies ist für Anwendungen nützlich, die vielen Änderungen unterliegen, beispielsweise Websites, die häufig aktualisiert werden. Obwohl sich Datenpipelines in der Regel nicht so stark ändern wie andere Arten von Anwendungen, bieten CI-Praktiken zahlreiche Vorteile bei der Pipelineentwicklung. Die Testautomatisierung liefert beispielsweise schnelles Feedback, wenn Fehler auftreten, und verringert die Wahrscheinlichkeit, dass Regressionen in die Codebasis gelangen.
Die Testautomatisierung ist ein wichtiger Bestandteil von CI. In Kombination mit einer entsprechenden Testabdeckung wird die Testautomatisierung bei jedem Code-Commit Ihre Testsuite ausgeführt. Sie können Ihren CI-Server in Verbindung mit einem Build-Automatisierungstool wie Maven verwenden, um Ihre Testsuite als einen oder mehrere Schritte der CI-Pipeline auszuführen. Sie können Code verpacken, der Unittests und Integrationstests erfolgreich in Bereitstellungsartefakte übergibt, von denen Pipelines gestartet werden. Dieser Build wird als bestandener Build bezeichnet.
Die Anzahl und Arten der Bereitstellungsartefakte, die aus einem bestandenen Build erstellt werden, hängen davon ab, wie Pipelines gestartet werden. Mit dem Apache Beam Java SDK können Sie Ihren Pipeline-Code in eine selbstausführende JAR-Datei packen. Sie können die JAR-Datei dann in einem Bucket speichern, der im Projekt für eine Bereitstellungsumgebung gehostet wird, z. B. für das Google Cloud-Projekt für die Vorproduktion oder die Produktion. Wenn Sie klassische Vorlagen verwenden (einer Art vonvorlagenbasierte Ausführung) enthalten die Bereitstellungsartefakte eineJSON-Vorlagendatei, die JAR-Datei für Ihre Pipeline und eineoptionale Metadatenvorlage. Sie können die Artefakte dann mithilfe von Continuous Delivery in verschiedenen Bereitstellungsumgebungen bereitstellen, wie im folgenden Abschnitt erläutert.
Continuous Delivery und kontinuierliche Bereitstellung
Bei Continuous Delivery (CD) werden Bereitstellungsartefakte in eine oder mehrere Bereitstellungsumgebungen kopiert, die dann manuell gestartet werden können. In der Regel werden die vom CI-Server erstellten Artefakte in einer oder mehreren Vorproduktionsumgebungen zum Ausführen von End-to-End-Tests bereitgestellt. Die Produktionsumgebung wird aktualisiert, wenn alle End-to-End-Tests erfolgreich bestanden wurden.
Bei Batchpipelines kann die kontinuierliche Bereitstellung die Pipeline direkt als neuen Dataflow-Job starten. Alternativ können andere Systeme die Artefakte verwenden, um bei Bedarf Batchjobs zu starten. Sie haben beispielsweise die Möglichkeit, mit Cloud Composer Batchjobs innerhalb eines Workflows auszuführen, oder mithilfe von Cloud Scheduler Batchjobs zu planen.
Die Bereitstellung von Streamingpipelines kann komplexer sein als die von Batchpipelines und daher ist es eventuell schwieriger, sie mit Continuous Deployment zu automatisieren. Beispielsweise kann es sein, dass Sie bestimmen müssen, wie eine vorhandene Streamingpipeline ersetzt oder aktualisiert wird. Wenn Sie eine Pipeline nicht aktualisieren können oder sich dagegen entscheiden, können Sie andere Methoden wie das Koordinieren mehrerer Dataflow-Jobs verwenden, um Unterbrechungen der Geschäftsabläufe zu minimieren oder zu verhindern.
Für CI/CD erforderliche Identitäten und Rollen
Ihre CI/CD-Pipeline interagiert mit verschiedenen Systemen, um Pipelines zu erstellen, zu testen und bereitzustellen. Beispielsweise benötigt Ihre Pipeline Zugriff auf Ihr Quellcode-Repository. Achten Sie darauf, dass Ihre Pipeline die richtigen Identitäten und Rollen hat, um diese Interaktionen zu ermöglichen. Die folgenden Pipelineaktivitäten erfordern möglicherweise auch, dass Ihre Pipeline bestimmte Identitäten und Rollen hat.
Integrationstests mit externen Diensten, einschließlich Google Cloud
Wenn Sie den Direct Runner zum Ausführen von Ad-hoc-Tests oder Integrationstests verwenden, nutzt Ihre Pipeline entweder die Google Cloud CLI-Anmeldedaten, um Google Cloud-Datenquellen und -Senken zu nutzen, oder sie verwendet die von der GOOGLE_APPLICATION_CREDENTIALS-Umgebungsvariablen bereitgestellten Anmeldedaten. Achten Sie darauf, dass das Dienstkonto, mit dem Anmeldedaten für Google Cloud-Ressourcen von der Pipeline abgerufen werden, über ausreichende Rollen und Berechtigungen verfügt.
Artefakte in verschiedenen Bereitstellungsumgebungen bereitstellen
Verwenden Sie nach Möglichkeit eindeutige Anmeldedaten für jede Umgebung (sprich für jedes Projekt), um den Zugriff auf Ressourcen entsprechend zu beschränken.
Verwenden Sie eindeutige Dienstkonten für jedes Projekt, um Bereitstellungsartefakte in Storage-Buckets zu lesen und zu schreiben. Je nachdem, ob die Pipeline eine Vorlage verwendet, müssen während des Bereitstellungsprozesses auf mehrere Artefakte möglicherweise Staging angewendet werden. Wenn Sie eine Dataflow-Vorlage erstellen und zum Staging führen möchten, benötigen Sie beispielsweise Berechtigungen für das Schreiben von Bereitstellungsartefakten in einen Cloud Storage-Bucket, die zum Starten der Pipeline erforderlich sind, z. B. die Vorlagendatei der Pipeline.
Pipelines in verschiedenen Bereitstellungsumgebungen bereitstellen
Verwenden Sie nach Möglichkeit eindeutige Dienstkonten für jedes Projekt, um auf Google Cloud-Ressourcen innerhalb des Projekts zuzugreifen und diese zu verwalten, einschließlich des Zugriffs auf Dataflow selbst.
Das Dienstkonto, das Sie zum Erstellen und Verwalten von Dataflow-Jobs verwenden, benötigt ausreichende IAM-Berechtigungen für die Jobverwaltung. Weitere Informationen finden Sie auf der Dataflow-Seite "Sicherheit und Berechtigungen" im Abschnitt Dataflow-Dienstkonto.
Das Worker-Dienstkonto, mit dem Sie Dataflow-Jobs ausführen, benötigt die Berechtigung zum Verwalten von Compute Engine-Ressourcen, während der Job ausgeführt wird, sowie zum Verwalten der Interaktion zwischen der Apache Beam-Pipeline und dem Dataflow-Dienst. Weitere Informationen finden Sie auf der Dataflow-Seite "Sicherheit und Berechtigungen" im Abschnitt Worker-Dienstkonto.
Verwenden Sie die Pipelineoption --serviceAccount, um ein vom Nutzer verwaltetes Worker-Dienstkonto für einen Job anzugeben.
Wenn Sie beim Erstellen eines Jobs kein Worker-Dienstkonto angeben, versucht Dataflow, das standardmäßige Dienstkonto von Compute Engine zu verwenden.
Wir empfehlen stattdessen, ein nutzerverwaltetes Worker-Dienstkonto für Produktionsumgebungen anzugeben, da das Compute Engine-Standarddienstkonto in der Regel mehr Berechtigungen hat als die Berechtigungen, die für Ihre Dataflow-Jobs erforderlich sind.
In Produktionsszenarien empfehlen wir die Verwendung separater Dienstkonten für die Dataflow-Jobverwaltung und das Worker-Dienstkonto, da hierdurch die Sicherheit im Vergleich zur Verwendung eines einzelnen Dienstkontos erhöht wird. Beispielsweise muss das Dienstkonto, mit dem Dataflow-Jobs erstellt werden, möglicherweise nicht auf Datenquellen und -senken zugreifen oder andere Ressourcen verwenden, die von der Pipeline genutzt werden. In diesem Szenario erhält das Worker-Dienstkonto, mit dem Dataflow-Jobs ausgeführt werden, die Berechtigungen zur Verwendung von Pipeline-Ressourcen. Ein anderes Dienstkonto für die Joberstellung gewährt Berechtigungen zum Verwalten (einschließlich Erstellen) von Dataflow-Jobs.
CI/CD-Beispielpipeline
Das folgende Diagramm bietet eine allgemeine und toolunabhängige Ansicht von CI/CD für Datenpipelines. Darüber hinaus zeigt das Diagramm die Beziehung zwischen Entwicklungsaufgaben, Bereitstellungsumgebungen und den Pipeline-Runnern.
Das Diagramm zeigt die folgenden Phasen:
Codeentwicklung: Bei der Codeentwicklung führt ein Entwickler Pipeline-Code lokal mit dem Direct Runner aus. Darüber hinaus verwenden Entwickler eine Sandbox-Umgebung für die Ad-hoc-Pipeline-Ausführung mit dem Dataflow-Runner.
In typischen CI/CD-Pipelines wird der Prozess der Continuous Integration ausgelöst, wenn ein Entwickler eine Änderung am Versionsverwaltungssystem vornimmt, z. B. durch das Übertragen von neuem Code in ein Repository.
Builds und Tests: Der CI-Prozess kompiliert den Pipelinecode und führt dann Unittests sowie Transformationsintegrationstests mit dem Direct Runner aus. Optionale Systemintegrationstests, die Integrationstests mit externen Quellen und Senken mithilfe von kleinen Test-Datasets umfassen, können auch ausgeführt werden.
Wenn die Tests erfolgreich sind, speichert der CI-Prozess die Bereitstellungsartefakte (z. B. JAR-Dateien, Docker-Images und Vorlagenmetadaten), die zum Starten der Pipeline an Speicherorten benötigt werden, die für den CD-Prozess zugänglich sind. Je nach Typ der generierten Bereitstellungsartefakte können Sie die verschiedenen Artefakttypen mit Cloud Storage und Artifact Registry speichern.
Liefern und bereitstellen: Im Rahmen des CD-Prozesses werden die Bereitstellungsartefakte in eine Vorproduktionsumgebung kopiert oder für die Verwendung in dieser Umgebung verfügbar gemacht. Entwickler können End-to-End-Tests mit dem Dataflow-Runner manuell ausführen. Alternativ können sie die kontinuierliche Bereitstellung verwenden, um den Test automatisch zu initiieren. In der Regel ist der Ansatz einer kontinuierlichen Bereitstellung für Batchpipelines einfacher zu aktivieren als für Streamingpipelines. Da Batchpipelines nicht kontinuierlich ausgeführt werden, ist es einfacher, sie durch einen neuen Release zu ersetzen.
Der Aktualisierungsprozess von Streamingpipelines kann einfach bis komplex sein. Sie sollten daher Aktualisierungen in der Vorproduktionsumgebung testen. Die Aktualisierungsverfahren sind zwischen den Releases möglicherweise nicht immer konsistent. Beispielsweise kann sich eine Pipeline so ändern, dass direkte Aktualisierungen nicht möglich sind. Aus diesem Grund ist es manchmal schwierig, Pipelineaktualisierungen mithilfe der kontinuierlichen Bereitstellung zu automatisieren.
Wenn alle End-to-End-Tests bestanden werden, können Sie die Bereitstellungsartefakte kopieren oder im Rahmen des CD-Prozesses für die Produktionsumgebung verfügbar machen. Wenn die neue Pipeline eine vorhandene Streamingpipeline aktualisiert oder ersetzt, verwenden Sie die in der Vorproduktionsumgebung getesteten Verfahren für die Bereitstellung der neuen Pipeline.
Nichtvorlagen- und vorlagenbasierte Jobausführung im Vergleich
Sie können einen Dataflow-Job erstellen, indem Sie das Apache Beam SDK direkt aus einer Entwicklungsumgebung verwenden. Dieser Jobtyp wird als Job ohne Vorlage bezeichnet. Dieser Ansatz ist zwar für Entwickler praktisch, doch bevorzugen Sie möglicherweise eine Trennung der Aufgaben bei der Entwicklung und Ausführung von Pipelines. Für diese Trennung können Sie Dataflow-Vorlagen verwenden, mit denen Sie Ihre Pipelines als unabhängige Aufgaben bereitstellen und ausführen können. Nach der Bereitstellung einer Vorlage können andere Nutzer, einschließlich Nicht-Entwickler, die Jobs über die Vorlage mit der Google Cloud CLI, der Google Cloud Console oder der Dataflow REST API ausführen.
Dataflow bietet folgende Arten von Jobvorlagen:
- Klassische Vorlagen: Entwickler verwenden das Apache Beam SDK, um den Pipelinecode auszuführen und die serialisierte JSON-Ausführungsgrafik als Vorlage zu speichern. Das Apache Beam SDK stellt die Vorlagendatei zusammen mit allen Abhängigkeiten bereit, die für den Pipelinecode erforderlich sind.
- Flexible Vorlagen: Entwickler verwenden die Google Cloud CLI, um die Pipeline als Docker-Image zu verpacken, das dann in Artifact Registry gespeichert wird. Eine Datei mit der Flex-Vorlagenspezifikation wird ebenfalls automatisch generiert und an einem benutzerdefinierten Cloud Storage-Speicherort gespeichert. Die Datei mit der Flex-Vorlagenspezifikation enthält Metadaten zur Ausführung der Vorlage, z. B. Pipelineparameter.
Flexible Vorlagen bieten zusätzlich zu den in der verlinkten Dokumentation erläuterten Funktionen Vorteile zum Verwalten von Vorlagen gegenüber klassischen Vorlagen.
- Bei klassischen Vorlagen können mehrere Artefakte (z. B. JAR-Dateien) an einem Cloud Storage-Staging-Speicherort gespeichert werden, allerdings ohne Funktionen zur Verwaltung mehrerer Artefakte. Im Gegensatz dazu ist eine Flex-Vorlage in einem Docker-Image eingebunden. Das Image verpackt alle Abhängigkeiten (mit Ausnahme der Spezifikation für flexible Vorlagen), die für Ihre Pipeline erforderlich sind, in einem Bereitstellungsartefakt, das von Artifact Registry verwaltet wird.
- Sie können die Docker-Image-Verwaltungsfunktionen für Ihre Flex-Vorlagen verwenden. Sie können flexible Vorlagen beispielsweise sicher freigeben, indem Sie Pull- und optional Push-Berechtigungen für Artifact Registry erteilen und Docker-Image-Tags für verschiedene Versionen Ihrer flexiblen Vorlagen verwenden.
Entwickler können klassische Vorlagen und flexible Vorlagen zum Starten von Jobs in einem Projekt verwenden, das sich von dem Projekt unterscheidet, zu dem die Registry und der Storage-Bucket gehören, in dem die Vorlagen-Assets gehostet werden (oder nur den Storage-Bucket, wenn Sie klassische Vorlagen verwenden). Dieses Feature ist nützlich, wenn Sie die Datenverarbeitung für mehrere Kunden in verschiedenen Projekten und Pipelinejobs isolieren müssen. Mit Flex Templates können Sie beim Starten einer Pipeline weitere Versionen eines Docker-Images angeben. Dieses Feature vereinfacht das Ersetzen von Batch-Pipelines oder Streaming-Pipelines über mehrere Projekte, wenn Sie Vorlagen später aktualisieren.
Dataflow-Features zur Optimierung der Ressourcennutzung
Dataflow bietet folgende Runner-spezifische Features zum Optimieren der Ressourcennutzung, wodurch die Leistung verbessert sowie die Kosten gesenkt werden können:
- Streaming Engine: Streaming Engine verschiebt die Ausführung von Streamingpipelines von VM-Workern zu einem dedizierten Dienst. Zu den Vorteilen gehören eine verbesserte Reaktionsfähigkeit beim Autoscaling, eine Reduzierung der verbrauchten Worker-VM-Ressourcen und automatische Service-Updates ohne erneute Bereitstellung. Für Streamingpipelines wird die Aktivierung von Streaming Engine empfohlen. Dieses Feature ist standardmäßig aktiviert, wenn Sie die neuesten Versionen des Apache Beam Java SDK oder des Python SDK verwenden.
- Dataflow Shuffle: Damit werden Shuffle-Vorgänge für Batchpipelines von VM-Workern zu einem dedizierten Dienst verschoben. Zu den Vorteilen gehören eine schnellere Ausführung der meisten Batchpipelines, ein reduzierter Ressourcenverbrauch durch Worker-VMs, eine verbesserte Reaktionsfähigkeit beim Autoscaling und eine verbesserte Fehlertoleranz. Für Batchpipelines wird die Aktivierung von Dataflow Shuffle empfohlen. Das Feature ist bei Verwendung des Apache Beam Java SDK und des neuesten Python SDK standardmäßig aktiviert.
- Flexible Ressourcenplanung (FlexRS): FlexRS reduziert die Kosten für die Batchverarbeitung mithilfe von erweiterten Planungstechniken, dem Dataflow Shuffle-Dienst und einer Kombination aus VM-Instanzen auf Abruf und regulären VMs.
Streamingpipelines in der Produktion aktualisieren
Siehe Streamingpipeline aktualisieren.
Lebensdauer eines Dataflow-Jobs
Ein Dataflow-Job durchläuft einen Lebenszyklus, der durch verschiedene Jobstatus dargestellt wird.
Zum Ausführen eines Dataflow-Jobs senden Sie ihn an eine Region.
Der Job wird dann an ein verfügbares Dataflow-Backend in einer der Zonen innerhalb der Region weitergeleitet. Bevor Dataflow ein Backend zuweist, wird geprüft, ob Sie ausreichende Kontingente und Berechtigungen zum Ausführen des Jobs haben. Wenn diese Preflight-Prüfungen abgeschlossen sind und ein Backend zugewiesen wurde, wird der Job in den Status JOB_STATE_PENDING versetzt. Bei FlexRS-Jobs kann die Backend-Zuweisung auf einen späteren Zeitpunkt verzögert werden und diese Jobs wechseln dann in den Status JOB_STATE_QUEUED.
Das zugewiesene Backend ruft den Job zur Ausführung auf und versucht, Dataflow-Worker in Ihrem Google Cloud-Projekt zu starten. Die für die Worker-VMs ausgewählte Zone hängt von mehreren Faktoren ab. Bei Batchjobs mit Dataflow Shuffle versucht der Dienst auch sicherzustellen, dass sich das Dataflow-Backend und die Worker-VMs in derselben Zone befinden, um zonenübergreifenden Traffic zu vermeiden.
Nachdem die Dataflow-Worker gestartet wurden, fordern sie Arbeit vom Dataflow-Backend an. Das Backend ist für die Aufteilung der Arbeit in parallelisierbare Blöcke (Bundles) verantwortlich, die auf die Worker verteilt werden. Wenn die Worker die vorhandene Arbeit nicht verarbeiten können und Autoscaling aktiviert ist, startet das Backend mehr Worker, um die Arbeit zu erledigen. Ebenso werden, wenn mehr Worker gestartet als benötigt werden, einige der Worker heruntergefahren.
Nachdem die Dataflow-Worker gestartet wurden, fungiert das Dataflow-Backend als Steuerungsebene für die Orchestrierung der Jobausführung. Während der Verarbeitung führt die Datenebene des Jobs Shuffle-Vorgänge wie GroupByKey, CoGroupByKey und Combine aus.
Bei Jobs werden für Shuffle-Vorgänge eine der folgenden Implementierungen von Datenebenen verwendet:
- Die Datenebene wird auf den Dataflow-Workern ausgeführt und die Shuffle-Daten werden auf nichtflüchtigen Speichern gespeichert.
- Die Datenebene wird als Dienst ausgeführt, der von den Worker-VMs ausgelagert ist. Diese Implementierung hat zwei Varianten, die Sie beim Erstellen des Jobs angeben: Dataflow Shuffle für Batchpipelines und Streaming Engine für Streamingpipelines. Das dienstbasierte Shuffle verbessert die Leistung und Skalierbarkeit von Vorgängen mit Daten nach dem Zufallsprinzip im Vergleich zum Worker-basierten Shuffle erheblich.
Streamingjobs, die in den Status JOB_STATE_RUNNING übergehen, können unbegrenzt weiter ausgeführt werden, bis sie abgebrochen oder geleert werden, es sei denn, es kommt zu einem Jobfehler. Batchjobs werden automatisch beendet, wenn die gesamte Verarbeitung abgeschlossen ist oder ein nicht behebbarer Fehler auftritt. Je nachdem, wie der Job angehalten wird, legt Dataflow den Status des Jobs auf einen von mehreren Terminalstatus fest, darunter JOB_STATE_CANCELLED, JOB_STATE_DRAINED oder JOB_STATE_DONE.
Best Practices für die Pipeline-Zuverlässigkeit
In diesem Abschnitt werden Fehler beschrieben, die bei der Arbeit mit Dataflow auftreten können, sowie Best Practices für Dataflow-Jobs.
Grundsätze für Isolation einhalten
Eine allgemeine Empfehlung zur Verbesserung der Pipeline-Zuverlässigkeit insgesamt besteht darin, den Isolierungsprinzipien hinter Regionen und Zonen zu folgen. Achten Sie darauf, dass Ihre Pipelines keine kritischen regionenübergreifenden Abhängigkeiten haben. Wenn eine Pipeline eine kritische Abhängigkeit von Diensten aus mehreren Regionen aufweist, kann sich ein Fehler in einer dieser Regionen auf Ihre Pipeline auswirken. Damit dieses Problem vermieden wird, stellen Sie es zum Zwecke der Redundanz und Sicherung in mehreren Regionen bereit.
Dataflow-Snapshots erstellen
Dataflow bietet eine Snapshot-Funktion, die eine Sicherung des Status einer Pipeline bereitstellt. Sie können den Pipeline-Snapshot in einer neuen Streaming-Dataflow-Pipeline in einer anderen Zone oder Region wiederherstellen. Sie können dann die erneute Verarbeitung von Nachrichten in den Pub/Sub- oder Kafka-Themen beginnen, die mit dem Snapshot-Zeitstempel beginnen. Wenn Sie regelmäßige Snapshots Ihrer Pipelines einrichten, können Sie die RTO-Zeit (Recovery Time Objective) minimieren.
Weitere Informationen zu Dataflow-Snapshots finden Sie unter Dataflow-Snapshots verwenden.
Fehler beim Senden von Jobs beheben
Sie senden Dataflow-Jobs, die ohne Vorlage sind, mit dem Apache Beam SDK. Den Job übergeben Sie dadurch, dass Sie die Pipeline ausführen und dabei den Dataflow-Runner verwenden, der in den Optionen für die Pipeline definiert ist. Das Apache Beam-SDK stellt Dateien in Cloud Storage bereit, erstellt eine Jobanfragedatei und sendet die Datei an Dataflow.
Alternativ können Jobs, die aus Dataflow-Vorlagen erstellt werden, unterschiedliche Übermittlungsmethoden verwenden, die in der Regel auf der Templates API basieren.
Möglicherweise werden von Dataflow verschiedene Fehler zurückgegeben, die auf einen Jobfehler für Vorlagen- und Nicht-Vorlagen-Jobs hinweisen. In diesem Abschnitt werden verschiedene Arten von Fehlern beim Senden von Jobs sowie Best Practices erläutert, um diese Fehler zu behandeln oder zu verringern.
Senden von Jobs nach vorübergehenden Fehlern wiederholen
Wenn ein Job aufgrund eines Dataflow-Dienstproblems nicht gestartet wird, wiederholen Sie den Job mehrmals. Wiederholen Sie den Vorgang, um vorübergehende Dienstprobleme zu beheben.
Zonale Fehler durch Angabe einer Worker-Region vermeiden
Dataflow bietet regionale Verfügbarkeit und ist in mehreren Regionen verfügbar. Wenn ein Nutzer einen Job an einen region sendet, ohne explizit eine Zone anzugeben, leitet Dataflow den Job anhand der Ressourcenverfügbarkeit an eine Zone in der angegebenen Region weiter.
Die empfohlene Option für die Jobplatzierung besteht darin, eine Worker-Region mit dem Flag --region anstelle des Flags --zone anzugeben, wann immer dies möglich ist. So kann Dataflow eine zusätzliche Fehlertoleranz für Ihre Pipelines bereitstellen, da automatisch die bestmögliche Zone für diesen Job ausgewählt wird. Jobs, die eine explizite Zone angeben, haben diesen Vorteil nicht und schlagen fehl, wenn Probleme innerhalb der Zone auftreten. Wenn das Senden eines Jobs aufgrund eines zonalen Problems fehlschlägt, können Sie das Problem häufig dadurch beheben, dass Sie den Job wiederholen, ohne explizit eine Zone anzugeben.
Regionale Fehler durch Datenspeicherung in mehreren Regionen vermeiden
Wenn eine ganze Region nicht verfügbar ist, versuchen Sie den Job in einer anderen Region. Es ist wichtig, die Verfügbarkeit Ihrer Daten zu berücksichtigen, wenn Jobs in verschiedenen Regionen fehlschlagen. Zum Schutz vor Ausfällen einzelner Regionen, ohne Daten manuell in mehrere Regionen zu kopieren, verwenden Sie Google Cloud-Ressourcen, die Daten automatisch in mehreren Regionen speichern. Verwenden Sie beispielsweise multiregionale BigQuery-Standorte für Datasets oder Dual-Region- und Multi-Region-Buckets von Cloud Storage. Wenn eine Region nicht verfügbar ist, können Sie die Pipeline in einer anderen Region noch einmal ausführen, in der die Daten verfügbar sind.
Ein Beispiel für die Verwendung multiregionaler Dienste mit Dataflow finden Sie unter Hochverfügbarkeit und geografische Redundanz.
Fehler bei der Ausführung von Pipelines verarbeiten
Nachdem ein Job gesendet und angenommen wurde, sind die einzigen gültigen Vorgänge für den Auftrag folgende:
- Abbrechen von Batchjobs
- Aktualisieren, Löschen oder Abbrechen von Streamingjobs
Sie können den Standort laufender Jobs nicht mehr ändern, nachdem Sie den Job gesendet haben. Wenn Sie FlexRS nicht verwenden, fangen Jobs in der Regel innerhalb weniger Minuten nach dem Senden damit an, Daten zu verarbeiten. Bei FlexRS-Jobs kann es bis zu sechs Stunden dauern, bis die Datenverarbeitung beginnt.
In diesem Abschnitt werden Fehler beim Ausführen von Jobs und Best Practices erläutert, mit ihnen umzugehen.
Jobs zur Identifizierung und Lösung von Problemen aufgrund von vorübergehenden Fehlern beobachten
Bei Batchjobs werden Bundles mit einem fehlerhaften Element viermal wiederholt. Dataflow beendet den Job, wenn ein einzelnes Bundle viermal fehlgeschlagen ist. Bei diesem Prozess werden viele vorübergehende Probleme behoben. Wenn jedoch ein länger andauernder Fehler auftritt, wird das maximale Wiederholungslimit in der Regel schnell erreicht, sodass der Job schnell fehlschlagen kann.
Konfigurieren Sie für das Monitoring und das Vorfallmanagement Benachrichtigungsregeln, um fehlgeschlagene Jobs zu erkennen. Wenn ein Job fehlschlägt, prüfen Sie die Joblogs, um Jobfehler zu identifizieren, die durch fehlgeschlagene Arbeitselemente ausgelöst werden, die das Wiederholungslimit überschreiten.
Für Streamingjobs wiederholt Dataflow fehlgeschlagene Arbeitsaufgaben unbegrenzt. Der Job wird nicht beendet. Der Job kann jedoch verzögert werden, bis das Problem behoben ist. Erstellen Sie Monitoring-Richtlinien, um Anzeichen für eine blockierte Pipeline zu erkennen, z. B. eine Erhöhung der Systemlatenz und eine Verringerung der Datenaktualität. Implementieren Sie die Fehlerprotokollierung in Ihrem Pipelinecode, um Pipeline-Blockierungen zu identifizieren, die durch wiederholt fehlgeschlagene Arbeitselemente verursacht werden.
Jobs bei einem Zonenausfall in einer anderen Zone neu starten
Nach dem Start eines Jobs sind die Dataflow-Worker, die Nutzercode ausführen, auf eine einzelne Zone beschränkt. Wenn ein Zonenausfall auftritt, sind Dataflow-Jobs abhängig vom Ausmaß des Ausfalls häufig betroffen.
Bei Ausfällen, die nur Dataflow-Back-Ends betreffen, werden die Back-Ends vom verwalteten Dienst automatisch in eine andere Zone migriert, damit sie den Job fortsetzen können. Wenn der Job Dataflow Shuffle verwendet, kann das Backend nicht zonenübergreifend verschoben werden. Wenn eine Dataflow-Backend-Migration auftritt, können Jobs vorübergehend angehalten werden.
Wenn ein Zonenausfall auftritt, werden ausgeführte Jobs wahrscheinlich fehlschlagen oder angehalten, bis die Zonenverfügbarkeit wiederhergestellt ist. Wenn eine Zone für einen längeren Zeitraum nicht verfügbar ist, sollten Sie Jobs beenden (Abbrechen für Batchjobs und Leeren für Streamingjobs). Anschließend starten Sie diese neu, damit Dataflow eine neue, fehlerfreie Zone auswählen kann.
Batchjobs bei einem regionalen Ausfall in einer anderen Region neu starten
Wenn ein regionaler Ausfall in einer Region auftritt, in der Ihre Dataflow-Jobs ausgeführt werden, können die Jobs fehlschlagen oder angehalten werden. Starten Sie den Job bei Batchjobs nach Möglichkeit in einer anderen Region neu. Es ist wichtig, dass Ihre Daten in verschiedenen Regionen verfügbar sind.
Regionale Ausfälle durch hohe Verfügbarkeit oder Failover reduzieren
Bei Streamingjobs haben Sie je nach Fehlertoleranz und Budget für Ihre Anwendung verschiedene Optionen, um Fehler zu minimieren. Bei einem regionalen Ausfall ist die einfachste und kostengünstigste Option zu warten, bis der Ausfall endet. Wenn Ihre Anwendung jedoch latenzempfindlich ist oder die Datenverarbeitung entweder nicht unterbrochen werden darf oder mit minimaler Verzögerung fortgesetzt werden sollte, werden in den folgenden Abschnitten Optionen erläutert.
Hochverfügbarkeit: latenzempfindlich ohne Datenverlust
Wenn Ihre Anwendung einen Datenverlust nicht tolerieren kann, führen Sie doppelte Pipelines parallel in zwei verschiedenen Regionen aus und lassen Sie die Pipelines dieselben Daten nutzen. In beiden Regionen müssen dieselben Datenquellen verfügbar sein. Die nachgelagerten Anwendungen, die von der Ausgabe dieser Pipelines abhängig sind, müssen zwischen den Ausgaben dieser beiden Regionen wechseln können. Aufgrund der Verdoppelung der Ressourcen ist diese Option im Vergleich zu anderen Optionen mit den höchsten Kosten verbunden. Ein Beispiel für eine Bereitstellung finden Sie im nächsten Abschnitt Hochverfügbarkeit und geografische Redundanz.
Failover: latenzempfindlich mit potenziellem Datenverlust
Wenn Ihre Anwendung einen möglichen Datenverlust tolerieren kann, stellen Sie die Streaming-Datenquelle in mehreren Regionen zur Verfügung. Verwalten Sie beispielsweise mithilfe von Pub/Sub zwei unabhängige Abos für dasselbe Thema, eines für jede Region. Wenn ein regionaler Ausfall auftritt, können Sie eine Ersatzpipeline in einer anderen Region starten und die Pipelinedaten aus dem Sicherungsabo nutzen.
Sie sollten das Sicherungsabo zu einem angemessenen Zeitpunkt wiederholen, um den Datenverlust auf ein Minimum zu reduzieren, ohne die Latenz zu beeinträchtigen. Downstream-Anwendungen müssen wissen, wie sie zur Ausgabe der ausgeführten Pipeline wechseln (ähnlich der Option für Hochverfügbarkeit). Diese Option verbraucht weniger Ressourcen als die Ausführung doppelter Pipelines, da nur die Daten dupliziert werden.
Hochverfügbarkeit und geografische Redundanz
Sie können mehrere Streamingpipelines parallel ausführen, um Daten mit Hochverfügbarkeit zu verarbeiten. Sie können beispielsweise zwei parallele Streamingjobs in verschiedenen Regionen ausführen, wodurch geografische Redundanz und Fehlertoleranz für die Datenverarbeitung geboten sind.
Unter Berücksichtigung der geografischen Verfügbarkeit von Datenquellen und -senken können Sie End-to-End-Pipelines in einer hochverfügbaren, multiregionalen Konfiguration betreiben. Das folgende Diagramm zeigt ein Beispiel für eine Bereitstellung.
Das Diagramm zeigt den folgenden Ablauf:
Pub/Sub wird in den meisten Regionen der Welt ausgeführt. Dadurch bietet der Dienst einen schnellen, globalen Datenzugriff. Gleichzeitig können Sie steuern, wo Nachrichten gespeichert werden. Pub/Sub kann veröffentlichte Nachrichten automatisch in der Google Cloud-Region speichern, die Abonnenten am nächsten ist, oder Sie können sie so konfigurieren, dass eine bestimmte Region oder eine Regionengruppe mithilfe von Richtlinien zur Nachrichtenspeicherung verwendet wird.
Pub/Sub liefert die Nachrichten dann an Abonnenten auf der ganzen Welt, unabhängig davon, wo die Nachrichten gespeichert sind. Pub/Sub-Clients müssen die Serverstandorte nicht kennen, zu denen sie eine Verbindung herstellen, da globale Load-Balancing-Mechanismen den Traffic an das nächstgelegene Google Cloud-Rechenzentrum weiterleiten, in dem die Nachrichten gespeichert sind.
Dataflow wird in bestimmten Google Cloud-Regionen ausgeführt. Wenn Sie parallele Pipelines in separaten Google Cloud-Regionen ausführen, können Sie Ihre Jobs von Fehlern isolieren, die eine einzelne Region betreffen. Das Diagramm zeigt zwei Instanzen derselben Pipeline, die jeweils in einer separaten Google Cloud-Region ausgeführt werden.
BigQuery bietet regionale und multiregionale Dataset-Standorte. Wenn Sie einen multiregionalen Standort auswählen, befindet sich Ihr Dataset in mindestens zwei geografischen Regionen. Das Diagramm zeigt zwei separate Pipelines, die jeweils in ein separates multiregionales Dataset schreiben.