Dataflow-Pipeline planen

Auf dieser Seite werden wichtige Überlegungen zur Planung Ihrer Datenpipeline erläutert, bevor Sie mit der Codeentwicklung beginnen. Datenpipelines verschieben Daten von einem System in ein anderes. Sie sind oft wichtige Komponenten von Systemen für Informationen zum Unternehmen. Die Leistung und Zuverlässigkeit der Datenpipeline kann sich auf diese breiteren Systeme auswirken und darauf, wie effektiv Ihre Geschäftsanforderungen erfüllt werden.

Wenn Sie die Datenpipelines vor der Entwicklung planen, können Sie deren Leistung und Zuverlässigkeit verbessern. Auf dieser Seite werden verschiedene Planungsaspekte für Dataflow-Pipelines erläutert, darunter:

• Leistungserwartungen für Ihre Pipelines, einschließlich Standards für die Messbarkeit
• Einbindung von Pipelines in Datenquellen, Senken und andere verbundene Systeme
• Pipelines, Quellen und Senken regionalisieren
• Sicherheit wie Datenverschlüsselung und private Netzwerke

SLOs definieren und messen

Ein wichtiges Maß für die Leistung ist die Frage, wie gut Ihre Pipeline Ihren geschäftlichen Anforderungen entspricht. Service Level Objectives (SLOs) bieten konkrete Definitionen für die Leistung, die Sie mit akzeptablen Grenzwerten vergleichen können. Beispielsweise können Sie die folgenden Beispiel-SLOs für Ihr System definieren:

• Datenaktualität: Generieren Sie 90 % der Produktempfehlungen aus Nutzeraktivitäten auf Websites, die nicht älter sind als drei Minuten.

• Datengenauigkeit: Innerhalb eines Kalendermonats sollten weniger als 0,5 % der Kundenrechnungen Fehler enthalten.

• Datenisolation/Load-Balancing: Innerhalb eines Arbeitstages sollten alle Zahlungen mit hoher Priorität innerhalb von 10 Minuten nach dem Eingang verarbeitet werden. Zahlungen mit Standardpriorität sollten bis zum nächsten Geschäftstag abgeschlossen sein.

Sie können Service Level Indicators (SLIs) verwenden, um die SLO-Compliance zu messen. SLIs sind quantifizierbare Messwerte, die angeben, wie gut Ihr System ein bestimmtes SLO erfüllt. Beispielsweise können Sie das SLO der Datenaktualität messen, indem Sie das Alter der zuletzt verarbeiteten Nutzeraktivität als SLI verwenden. Wenn Ihre Pipeline Empfehlungen aus Nutzeraktivitätsereignissen generiert und Ihr SLI eine 4-Minuten-Verzögerung zwischen dem Ereignis und der Verarbeitung meldet, wird in den Empfehlungen keine Nutzeraktivität berücksichtigt, die älter als 4 Minuten ist. Wenn eine Streamingdaten verarbeitende Pipeline eine Systemlatenz von 4 Minuten überschreitet, wissen Sie, dass das SLO nicht erreicht wurde.

Da Systemkomponenten außerhalb der Pipeline Ihr SLO beeinflussen können, ist es wichtig, eine Reihe von SLIs zu erfassen, die die Gesamtleistung des Systems über die Leistung der Pipeline hinaus beschreiben, darunter Messwerte, die den End-to-End-Status Ihres Systems beschreiben. Beispielsweise könnte die Dataflow-Pipeline Ergebnisse mit akzeptabler Verzögerung zurückgeben. Es kann aber ein Leistungsproblem mit einem nachgelagerten System auftreten, das sich auf breitere SLOs auswirken kann.

Weitere Informationen zu wichtigen SLOs finden Sie im Buch Site Reliability Engineering.

Datenaktualität

Datenaktualität bezieht sich auf die Nutzbarkeit von Daten in Bezug auf ihr Alter. Die folgenden SLOs für die Datenaktualität sind im Buch "Site Reliability Engineering" als gängige SLO-Formate für Pipeline-Datenaktualität aufgeführt:

• X% der in Y [Sekunden, Tagen, Minuten] verarbeiteten Daten. Dieses SLO bezieht sich auf den Prozentsatz der Daten, die in einem bestimmten Zeitraum verarbeitet werden. Es wird häufig für Batch-Pipelines verwendet, die begrenzte Datenquellen verarbeiten. Die Messwerte für diese Art von SLO sind die Größen der Eingabe- und Ausgabedaten bei wichtigen Verarbeitungsschritten in Bezug auf die verstrichene Laufzeit der Pipeline. Sie können einen Schritt auswählen, der ein Eingabe-Dataset liest, und einen weiteren Schritt, der jedes Element der Eingabe verarbeitet. Ein Beispiel-SLO lautet: "Für das Spiel 'Shave the Yak' sollten 99 % der Nutzeraktivitäten, die sich auf die Punktzahlen der Spieler auswirken, innerhalb von 30 Minuten nach Abschluss des Spiels erfasst werden."

• Die ältesten Daten sind nicht älter als X [Sekunden, Tage, Minuten]. Dieses SLO bezieht sich auf das Alter der von der Pipeline generierten Daten. Es wird häufig für Streaming-Pipelines verwendet, die Daten aus unbegrenzten Quellen verarbeiten. Bei dieser Art von SLO verwenden Sie Messwerte, die angeben, wie lange Ihre Pipeline zum Verarbeiten von Daten benötigt. Zwei mögliche Messwerte sind entweder das Alter des ältesten nicht verarbeiteten Elements (wie lange ein nicht verarbeitetes Element in der Warteschlange vorhanden ist) oder das Alter des zuletzt verarbeiteten Elements. Ein Beispiel-SLO lautet: "Produktempfehlungen werden aus Nutzeraktivitäten generiert, die nicht älter als fünf Minuten sind".

• Der Pipelinejob wird innerhalb von X [Sekunden, Tagen, Minuten] erfolgreich abgeschlossen. Dieses SLO legt eine Frist für den erfolgreichen Abschluss fest und wird häufig für Batch-Pipelines verwendet, die Daten aus begrenzten Datenquellen verarbeiten. Für dieses SLO sind zusätzlich zu anderen Signalen, die Aufschluss über den Erfolg des Jobs geben (z. B. der Prozentsatz der verarbeiteten Elemente, die zu Fehlern führen) die insgesamt verstrichene Zeit der Pipeline und der Abschlussstatus des Jobs erforderlich. Ein Beispiel-SLO lautet: "Kundenbestellungen vom aktuellen Werktag sollten bis zum nächsten Tag um 9 Uhr verarbeitet sein."

Informationen zur Verwendung von Cloud Monitoring zum Messen der Datenaktualität finden Sie unter Dataflow-Jobmesswerte.

Richtigkeit der Daten

Die Richtigkeit der Daten bezieht sich auf Daten, die fehlerfrei sind. Sie können die Richtigkeit der Daten auf verschiedene Weise ermitteln. Darunter:

• Einheitentests und Integrationstests, die Sie mit Continuous Integration automatisieren können.

• End-to-End-Pipelinetests, die Sie in einer Vorproduktionsumgebung ausführen können, nachdem die Pipeline Einheiten- und Integrationstests erfolgreich bestanden hat. Sie können End-to-End-Pipelinetests mit Continuous Delivery automatisieren.

• Pipelines, die in der Produktion ausgeführt werden, wenn Sie Messwerte zur Datengenauigkeit mit Monitoring beobachten.

Zum Ausführen von Pipelines erfordert die Definition eines Ziels für die Datengenauigkeit in der Regel die Messung der Genauigkeit über einen bestimmten Zeitraum. Beispiele:

• Pro Job sind in weniger als X % der Eingabeelemente Datenfehler enthalten. Mit diesem SLO kann die Genauigkeit der Daten bei Batch-Pipelines gemessen werden. Ein Beispiel-SLO lautet: "Für jeden täglichen Batch-Job zur Verarbeitung von Stromzählermesswerten enthalten weniger als 3 % der Messwerte Dateneingabefehler."
• In einem gleitenden X-Minuten-Fenster enthalten weniger als Y % der Eingabeelemente Datenfehler. Mit diesem SLO kann die Genauigkeit der Daten bei Streaming-Pipelines gemessen werden. Ein Beispiel-SLO lautet: "Weniger als 2 % der Stromzählermesswerte der letzten Stunde enthalten negative Werte."

Für die Messung dieser SLOs können Sie Messwerte über einen geeigneten Zeitraum nutzen, um die Anzahl der Fehler nach Typ zu messen. Beispielsweise können die Daten aufgrund eines fehlerhaften Schemas falsch sein oder die Daten liegen außerhalb eines gültigen Bereichs.

Informationen zur Verwendung von Cloud Monitoring zum Messen der Datenrichtigkeit finden Sie unter Dataflow-Jobmesswerte.

Datenisolation und Load-Balancing

Bei der Datenisolation werden Daten nach Attributen segmentiert, was das Load-Balancing erleichtern kann. Bei einem Online-Zahlungsabwickler können Sie beispielsweise Daten so segmentieren, dass einzelne Zahlungen entweder Standardpriorität oder hohe Priorität haben. Ihre Pipeline kann dann mithilfe von Load-Balancing Zahlungen mit hoher Priorität vor Zahlungen mit Standardpriorität verarbeiten.

Angenommen, Sie definieren die folgenden SLOs für die Zahlungsabwicklung:

• Zahlungen mit hoher Priorität werden innerhalb von 10 Minuten verarbeitet.
• Zahlungen mit Standardpriorität werden bis 9:00 Uhr des nächsten Werktags bearbeitet.

Wenn die Zahlungsplattform diesen SLOs entspricht, können Kunden abgeschlossene Zahlungen mit hoher Priorität auf einem Berichts-Dashboard sehen, sobald sie abgeschlossen sind. Hingegen sind Standardzahlungen möglicherweise erst am nächsten Tag auf dem Dashboard sichtbar.

In diesem Beispielszenario haben Sie folgende Optionen:

• Verwenden Sie eine Pipeline, um sowohl Zahlungen mit Standard- als auch mit hoher Priorität zu verarbeiten.
• Verwenden Sie mehrere Pipelines für Datenisolation und Load-Balancing basierend auf Prioritäten.

Die folgenden Abschnitte beschreiben ausführlich jede dieser Optionen.

Eine einzelne Pipeline zur Erfüllung gemischter SLOs verwenden

Das folgende Diagramm zeigt eine einzelne Pipeline, die zur Verarbeitung von Zahlungen mit hoher Priorität und mit Standardpriorität verwendet wird. Die Pipeline erhält Benachrichtigungen über neue Zahlungen von einer Streaming-Datenquelle, z. B. einem Pub/Sub-Thema oder einem Apache Kafka-Thema. Anschließend werden sofort Zahlungen verarbeitet und mithilfe von Streaming-Insert-Anweisungen Ereignisse in BigQuery geschrieben.

Der Vorteil einer einzelnen Pipeline besteht darin, dass die betrieblichen Anforderungen vereinfacht werden, da Sie nur eine einzige Datenquelle und Pipeline verwalten müssen. Dataflow verwendet automatische Abstimmungsfeatures, um den Job möglichst schnell und effizient auszuführen.

Der Nachteil einer einzelnen Pipeline besteht darin, dass die gemeinsam genutzte Pipeline Zahlungen mit hoher Priorität nicht gegenüber Zahlungen mit Standardpriorität priorisieren kann, und Pipeline-Ressourcen über beide Zahlungsarten gemeinsam genutzt werden. Im zuvor beschriebenen Geschäftsszenario muss Ihre Pipeline die strengere der beiden SLOs beibehalten. Das heißt, in der Pipeline muss das SLO für Zahlungen mit hoher Priorität verwendet werden, unabhängig von der tatsächlichen Priorität der verarbeiteten Zahlungen. Ein weiterer Nachteil besteht darin, dass im Falle eines Arbeitsrückstands die Streaming-Pipeline auch nicht in der Lage ist, die Bearbeitung des Rückstands entsprechend der Dringlichkeit der Arbeit zu priorisieren.

Mehrere Pipelines verwenden, die auf bestimmte SLOs zugeschnitten sind

Sie können zwei Pipelines verwenden, um Ressourcen zu isolieren und für bestimmte SLOs zu liefern. Das folgende Diagramm veranschaulicht diesen Ansatz.

Zahlungen mit hoher Priorität sind in einer Streaming-Pipeline für eine priorisierte Verarbeitung isoliert. Zahlungen mit Standardpriorität werden von einer Batch-Pipeline verarbeitet, die täglich ausgeführt wird und BigQuery-Ladejobs zum Schreiben verarbeiteter Ergebnisse verwendet.

Das Isolieren von Daten in verschiedenen Pipelines hat Vorteile. Für Zahlungen mit hoher Priorität für engere SLOs können Sie die Verarbeitungszeiten verkürzen. Weisen Sie dazu der Pipeline, die für Zahlungen mit hoher Priorität vorgesehen ist, mehr Ressourcen zu. Zu den Ressourcenkonfigurationen gehören das Hinzufügen von Dataflow-Workern, die Verwendung größerer Maschinen und das Aktivieren des Autoscalings. Durch das Isolieren von Elementen mit hoher Priorität in einer separaten Verarbeitungswarteschlange können sich auch Verarbeitungsverzögerungen bei einem plötzlichen Anstieg von Zahlungen mit Standardpriorität verringern.

Wenn Sie mehrere Pipelines verwenden, um die Daten aus Batch- und Streamingquellen zu isolieren und ein Load-Balancing vorzunehmen, ermöglicht das Apache Beam-Programmiermodell, dass Pipelines mit hoher Priorität (Streaming) und Standardpriorität (Batch) denselben Code verwenden. Die einzige Ausnahme ist die erste Lesetransformation, die aus einer begrenzten Quelle für die Batch-Pipeline liest. Weitere Informationen finden Sie unter Bibliotheken mit wiederverwendbaren Transformationen erstellen.

Datenquellen und -senken planen

Damit Daten verarbeitet werden können, muss eine Datenpipeline in andere Systeme eingebunden werden. Diese Systeme werden als Quellen und Senken bezeichnet. Datenpipelines lesen Daten aus Quellen und schreiben Daten in Senken. Neben Quellen und Senken interagieren die Datenpipelines möglicherweise mit externen Systemen für die Datenanreicherung, Filterung oder den Aufruf externer Geschäftslogik innerhalb eines Verarbeitungsschritts.

Aus Gründen der Skalierbarkeit führt Dataflow die Phasen Ihrer Pipeline parallel auf mehreren Workern aus. Faktoren, die sich außerhalb Ihres Pipelinecodes und des Dataflow-Dienstes befinden, wirken sich auch auf die Skalierbarkeit Ihrer Pipeline aus. Beispiele für solche Faktoren:

• Skalierbarkeit externer Systeme: Externe Systeme, mit denen Ihre Pipeline interagiert, können eine Leistungsbeschränkung darstellen und die Obergrenze der Skalierbarkeit bilden. Ein Apache Kafka-Thema, das für eine unzureichende Anzahl von Partitionen für den benötigten Lesedurchsatz konfiguriert ist, kann beispielsweise die Leistung Ihrer Pipeline beeinträchtigen. Informationen dazu, wie die Pipeline und ihre Komponenten Ihre Leistungsziele erreichen, finden Sie in der Dokumentation mit den Best Practices für die von Ihnen verwendeten externen Systeme. Sie können die Planung der Infrastrukturkapazität auch mithilfe von Google Cloud-Diensten mit integrierter Skalierbarkeit vereinfachen. Weitere Informationen finden Sie unter Von Google Cloud verwaltete Quellen und Senken verwenden auf dieser Seite.

• Auswahl von Datenformaten: Bestimmte Datenformate sind möglicherweise schneller zu lesen als andere. Beispielsweise sind Datenformate, die parallelisierbare Lesevorgänge unterstützen, wie Avro, in der Regel schneller als CSV-Dateien mit eingebetteten Zeilenumbrüchen in Feldern und schneller als komprimierte Dateien.

• Speicherort der Daten und Netzwerktopologie: Die geografische Nähe und die Netzwerkeigenschaften von Datenquellen und -senken in Bezug auf die Datenpipeline können sich auf die Leistung auswirken. Weitere Informationen finden Sie unter Regionale Einschränkungen auf dieser Seite.

Aufrufe externer Dienste

Der Aufruf von externen Diensten von Ihrer Pipeline aus verursacht einen Mehraufwand pro Aufruf, der die Leistung und Effizienz Ihrer Pipeline beeinträchtigen kann. Wenn Ihre Datenpipeline externe Dienste aufruft, fassen Sie nach Möglichkeit mehrere Datenelemente in einer einzigen Anfrage zusammen, um den Aufwand zu reduzieren. Viele native Apache Beam-E/A-Transformationen führen diese Aufgabe automatisch aus, darunter BigQueryIO und Streaming-Insert-Vorgänge. Abgesehen von den Kapazitätslimits können einige externe Dienste auch Kontingente erzwingen, die die Gesamtzahl der Aufrufe über einen bestimmten Zeitraum hinweg (z. B. ein Tageskontingent) oder die Raten von Aufrufen begrenzen (z. B. die Anzahl der Anfragen pro Sekunde).

Da Dataflow die Arbeit auf mehreren Worker-Instanzen parallelisiert, kann zu viel Traffic einen externen Dienst überlasten oder die verfügbaren Kontingente erschöpfen. Bei Verwendung von Autoscaling versucht Dataflow möglicherweise, Worker hinzuzufügen, um einen langsamen Schritt wie einen externen Aufruf auszuführen. Durch das Hinzufügen von Workern kann der Druck auf externe Systeme weiter erhöht werden. Sorgen Sie dafür, dass externe Systeme Ihre erwarteten Lastanforderungen erfüllen, oder beschränken Sie den Traffic von Ihrer Pipeline auf nachhaltige Werte. Weitere Informationen finden Sie unter Batchgrößen und gleichzeitige Aufrufe von externen Diensten beschränken.

Von Google Cloud verwaltete Quellen und Senken verwenden

Die Verwendung von verwalteten Google Cloud-Diensten mit Ihrer Dataflow-Pipeline vereinfacht die Kapazitätsverwaltung, indem sie integrierte Skalierbarkeit, konsistente Leistung sowie Kontingente und Limits für die meisten Anforderungen bieten. Außerdem müssen Sie die unterschiedlichen Kontingente und Limits für Pipelinevorgänge berücksichtigen. Dataflow selbst hat Kontingente und Limits. Einige dieser Werte können Sie über den Google Cloud-Support erhöhen.

Dataflow verwendet Compute Engine-VM-Instanzen zum Ausführen Ihrer Jobs. Daher benötigen Sie ein ausreichendes Compute Engine-Kontingent. Ein unzureichendes Compute Engine-Kontingent kann das Autoscaling von Pipelines verhindern oder dazu führen, dass Jobs nicht gestartet werden.

In den verbleibenden Abschnitten dieses Abschnitts wird erläutert, wie sich verschiedene Google Cloud-Kontingente und -Limits auf den Entwurf, die Entwicklung und die Überwachung Ihrer Pipeline auswirken können. Pub/Sub und BigQuery werden als Beispiele für Pipelinequellen und -senken verwendet.

Beispiel 1: Pub/Sub

Wenn Sie Pub/Sub mit Dataflow verwenden, bietet Pub/Sub einen skalierbaren und langlebigen Ereignisaufnahmedienst für die Übermittlung von Nachrichten an und von Ihren Streaming-Datenpipelines. Mit der Google Cloud Console können Sie die Nutzung von Pub/Sub-Kontingenten einsehen und Kontingentlimits erhöhen. Sie sollten eine Kontingenterhöhung anfordern, wenn Sie eine einzelne Pipeline haben, die die Kontingente und Limits pro Projekt überschreitet.

Pub/Sub-Kontingente und -Limits sind auf die Nutzung auf Projektebene ausgelegt. Insbesondere erhalten Publisher und Abonnenten in verschiedenen Projekten unabhängige Datendurchsatzkontingente. Wenn mehrere Pipelines in ein einzelnes Thema veröffentlichen oder es abonnieren, können Sie einen maximalen zulässigen Durchsatz für dieses Thema erzielen, indem Sie jede Pipeline in einem eigenen Projekt bereitstellen. In dieser Konfiguration verwendet jede Pipeline ein anderes projektbasiertes Dienstkonto, um Nachrichten zu verarbeiten und zu veröffentlichen.

Im folgenden Diagramm haben Pipeline 1 und Pipeline 2 das gleiche Durchsatzkontingent für Abonnenten und Publisher, das auch für Projekt A verfügbar ist. Im Gegensatz dazu kann Pipeline 3 das gesamte Durchsatzkontingent für Abonnenten und Publisher verwenden, das Projekt B zugewiesen ist.

Mehrere Pipelines können mithilfe eines separaten Abos für das Thema aus einem einzelnen Pub/Sub-Thema lesen. Daher können Dataflow-Pipelines Nachrichten unabhängig von anderen Abonnenten, z. B. anderen Pipelines, abrufen und bestätigen. Durch dieses Feature wird das Klonen von Pipelines durch die Erstellung zusätzlicher Pub/Sub-Abos erleichtert. Zusätzliche Abos sind hilfreich, um Replikatpipelines für Hochverfügbarkeit (normalerweise für Streaming-Anwendungsfälle) zur Ausführung zusätzlicher Testpipelines für dieselben Daten und zur Aktivierung von Pipeline-Updates zu erstellen.

Beispiel 2: BigQuery

Das Lesen und Schreiben von BigQuery-Daten wird vom Apache Beam SDK für mehrere Sprachen unterstützt, einschließlich Java, Python und Go. Wenn Sie Java verwenden, bietet die BigQueryIO-Klasse diese Funktion. BigQueryIO unterstützt zwei Methoden zum Lesen von Daten: EXPORT (Tabellenexport) und DIRECT_READ. Die verschiedenen Lesemethoden verbrauchen unterschiedliche BigQuery-Kontingente.

Der Tabellenexport ist die standardmäßige Lesemethode. Sie funktioniert wie in der folgenden Abbildung dargestellt:

Das Diagramm zeigt den folgenden Ablauf:

1. BigQueryIO ruft eine BigQuery-Exportanfrage auf, um Tabellendaten zu exportieren. Die exportierten Tabellendaten werden in einen temporären Cloud Storage-Speicherort geschrieben.
2. BigQueryIO liest die Tabellendaten aus dem temporären Cloud Storage-Speicherort.

BigQuery-Exportanfragen sind durch Exportkontingente begrenzt. Die Exportanfrage muss ebenfalls abgeschlossen sein, bevor die Pipeline mit der Verarbeitung von Daten beginnen kann. Dadurch wird die Ausführungszeit des Jobs verlängert.

Im Gegensatz dazu wird für den direkten Lesevorgang die BigQuery Storage API verwendet, um Tabellendaten direkt aus BigQuery zu lesen. Die BigQuery Storage API bietet mit gRPC eine hohe Durchsatzleistung für das Lesen von Tabellenzeilendaten. Bei Verwendung der BigQuery Storage API ist der Exportschritt nicht erforderlich. Dadurch werden Kontingentbeschränkungen für den Export vermieden und die Joblaufzeit verkürzt.

Das folgende Diagramm zeigt den Ablauf bei Verwendung der BigQuery Storage API. Im Gegensatz zum Ablauf, der eine BigQuery-Exportanfrage verwendet, ist dieser Ablauf einfacher, da er nur einen einzigen Schritt zum direkten Lesen hat, um die Daten aus der Tabelle in die Pipeline zu übertragen.

Das Schreiben von Daten in BigQuery-Tabellen hat auch eigene Kontingentauswirkungen. Beispielsweise nutzen Batch-Pipelines mit BigQuery-Ladejobs andere BigQuery-Ladejobkontingente als solche, die auf Tabellen- und Projektebene angewandt werden. Streaming-Pipelines mit BigQuery-Streaming-Insert-Anweisungen verbrauchen außerdem BigQuery-Streaming-Insert-Kontingente.

Betrachten Sie Ihren Anwendungsfall, um die am besten geeigneten Methoden zum Lesen und Schreiben von Daten zu ermitteln. Vermeiden Sie es beispielsweise, mit BigQuery-Ladejobs tausende Male täglich Daten an eine Tabelle anzuhängen. Verwenden Sie eine Streamingpipeline, um echtzeitnahe Daten in BigQuery zu schreiben. Die Streaming-Pipeline sollte zu diesem Zweck entweder Streaming-Insert-Anweisungen oder die Storage Write API verwenden.

Regionale Einschränkungen

Dataflow wird als verwalteter Dienst in mehreren Google Cloud-Regionen angeboten. Berücksichtigen Sie bei der Auswahl einer Region für die Ausführung Ihrer Jobs die folgenden Faktoren:

• Speicherort von Datenquellen und -senken
• Einstellungen oder Einschränkungen für Standorte der Datenverarbeitung
• Dataflow-Funktionen, die nur in bestimmten Regionen angeboten werden
• Die Region, die zum Verwalten der Ausführung eines bestimmten Jobs verwendet wird
• Die Zone, die für die Worker des Jobs verwendet wird

Für einen Job kann sich die Regionseinstellung, die Sie für den Job und die Worker verwenden, unterscheiden. Weitere Informationen, einschließlich wann Sie angeben Regionen und Zonen, finden Sie in der Dokumentation zu Dataflow-Regionen.

Wenn Sie Regionen zum Ausführen Ihrer Dataflow-Jobs angeben, können Sie regionale Einschränkungen bzgl. Hochverfügbarkeit und Notfallwiederherstellung berücksichtigen. Weitere Informationen finden Sie unter Hochverfügbarkeit und geografische Redundanz.

Regionen

Dataflow-Regionen speichern und verarbeiten Metadaten Ihres Jobs, z. B. Informationen zur Apache Beam-Grafik selbst, wie Transformationsnamen. Sie steuern auch das Verhalten von Workern, z. B. Autoscaling. Durch die Angabe einer Region können Sie Ihre Anforderungen an Sicherheit und Compliance, die Datenlokalität und die regionale Platzierung eines Jobs erfüllen. Verwenden Sie nach Möglichkeit dieselbe Region für den Job und die Worker, um eine Leistungsbeeinträchtigung durch regionsübergreifende Netzwerkaufrufe zu vermeiden.

Dataflow-Worker

Dataflow-Jobs verwenden Compute Engine-VM-Instanzen (sogenannte Dataflow-Worker) zum Ausführen Ihrer Pipeline. Dataflow-Jobs können jede Compute Engine-Zone für Worker verwenden, einschließlich Regionen, in denen keine Dataflow-Standorte vorhanden sind. Durch Angabe einer Worker-Region für einen Job können Sie die regionale Platzierung Ihrer Worker steuern. So geben Sie eine Worker-Region oder -Zone an:

• Wenn Sie die gcloud CLI verwenden, um einen Job aus einer Dataflow-Vorlage zu erstellen, überschreiben Sie mit dem Flag --worker-region die Worker-Region und mit dem Flag --worker-zone die Worker-Zone.
• Wenn Sie den Job mit dem Apache Beam Java SDK erstellen, legen Sie Regionen und Zonen für Worker mithilfe von Pipeline-Optionen fest. Überschreiben Sie mit workerRegion die Worker-Region und mit workerZone die Worker-Zone.

Um die Netzwerklatenz und den Durchsatz zu verbessern, empfehlen wir, dass Sie Worker in einer Region erstellen, die sich geografisch in der Nähe Ihrer Datenquellen und -senken befindet. Wenn Sie beim Erstellen eines Jobs keine Region oder Zone für Worker angeben, wird von Dataflow automatisch eine Zone festgelegt, die sich in der Region des Job befindet.

Wenn Sie den Dataflow Shuffle-Dienst oder Streaming Engine nicht verwenden, befinden sich die Daten, die vom Job verarbeitet werden (d. h. Daten, die in einem PCollection-Objekt gespeichert sind), auf den Workern des Jobs, wobei davon ausgegangen wird, dass kein Nutzercode Daten außerhalb der Worker überträgt. Wenn entweder der Dataflow Shuffle-Dienst oder Streaming Engine aktiviert ist, kann das verteilte Dataset, das durch ein PCollection-Objekt dargestellt wird, zwischen den Workern und diesen Diensten übertragen werden.

Überlegungen zur Datenverschlüsselung

Als vollständig verwalteter Dienst verschlüsselt Dataflow automatisch Daten, die sich durch Ihre Datenpipeline bewegen, wobei sowohl für In-Flight-Daten als auch für inaktive Daten Google-eigene und von Google verwaltete Schlüssel verwendet werden. Statt Google-eigene und von Google verwaltete Schlüssel zu verwenden, kann es sinnvoll sein, Ihre eigenen Verschlüsselungsschlüssel selbst zu verwalten. In diesem Fall unterstützt Dataflow vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) mit dem Cloud Key Management Service (KMS). Sie können auch Cloud HSM verwenden, ein in der Cloud gehosteter HSM-Dienst (Hardwaresicherheitsmodul), mit dem Sie in einem Cluster von nach FIPS 140-2 Level 3 zertifizierten HSM Verschlüsselungsschlüssel hosten und kryptografische Vorgänge durchführen können.

Wenn Sie CMEK verwenden, verschlüsselt Dataflow die Daten mit Ihrem Cloud KMS-Schlüssel, mit Ausnahme von auf Datenschlüsseln basierenden Vorgängen wie Windowing, Gruppierung und Join. Wenn Datenschlüssel vertrauliche Daten enthalten, wie etwa personenidentifizierbare Informationen, müssen Sie die Schlüssel hashen oder anderweitig transformieren, bevor sie in die Dataflow-Pipeline gelangen.

Überlegungen zu privaten Netzwerken

Ihre Netzwerk- und Sicherheitsanforderungen schreiben unter Umständen vor, dass VM-basierte Arbeitslasten wie Dataflow-Jobs nur private IP-Adressen verwenden. Mit Dataflow können Sie festlegen, dass Worker für die gesamte Netzwerkkommunikation private IP-Adressen verwenden. Wenn öffentliche IP-Adressen deaktiviert sind, müssen Sie im Subnetzwerk den privaten Google-Zugriff aktivieren, damit Dataflow-Worker auf Google-APIs und -Dienste zugreifen können.

Wir empfehlen, öffentliche IP-Adressen für Dataflow-Worker zu deaktivieren, es sei denn, Ihre Dataflow-Jobs erfordern öffentliche IP-Adressen für den Zugriff auf Netzwerkressourcen außerhalb von Google Cloud. Durch das Deaktivieren öffentlicher IP-Adressen wird verhindert, dass Dataflow-Worker auf Ressourcen außerhalb des Subnetzwerks oder auf Peer-VPC-Netzwerke zugreifen. Ebenso wird der Netzwerkzugriff auf VM-Worker von außerhalb des Subnetzwerks oder der Peering-VPC-Netzwerke verhindert.

Weitere Informationen zur Verwendung der Pipeline-Option --usePublicIps zum Angeben, ob Worker nur private IP-Adressen haben sollen, finden Sie unter Pipeline-Optionen.

Nächste Schritte

• Eigene Pipeline entwickeln und testen
• Vollständige Pipeline-Workflows entwerfen
• Weitere Informationen zu den SRE-Verfahren (Site Relability Engineering) für Datenverarbeitungspipelines von Google