Migration zwischen Google Cloud-Regionen: Daten und Batch-Arbeitslasten für die Migration zwischen Regionen vorbereiten

Last reviewed 2024-12-02 UTC

In diesem Dokument wird beschrieben, wie Sie eine Datenplattform in Google Cloud entwerfen, um die Auswirkungen einer zukünftigen Expansion in andere Regionen oder einer Migration zwischen Regionen zu minimieren. Dieses Dokument ist Teil einer Reihe, die Ihnen hilft, die Auswirkungen der Erweiterung Ihrer Datenplattform auf eine andere Region zu verstehen. Sie lernen, wie Sie Folgendes tun:

  • Daten und Datenpipelines für den Umzug vorbereiten.
  • Richten Sie während der Migrationsphasen Prüfungen ein.
  • Erstellen Sie eine flexible Migrationsstrategie, indem Sie Datenspeicher und ‑berechnung trennen.

Die Anleitung in dieser Reihe ist auch nützlich, wenn Sie keine Migration über Regionen hinweg oder keine Erweiterung auf mehrere Regionen im Voraus geplant haben. In diesem Fall müssen Sie möglicherweise zusätzlichen Aufwand betreiben, um Ihre Infrastruktur, Arbeitslasten und Daten für die Migration zwischen Regionen und die Erweiterung auf mehrere Regionen vorzubereiten.

Dieses Dokument ist Teil der folgenden Reihe:

In dieser Reihe wird davon ausgegangen, dass Sie die folgenden Dokumente gelesen haben und mit ihnen vertraut sind:

Diese Grafik veranschaulicht den Migrationsprozess:

Migrationspfad mit vier Phasen

Bei jedem Migrationsschritt folgen Sie den unter Migration zu Google Cloud: Erste Schritte definierten Phasen:

  1. Arbeitslasten bewerten und erkennen
  2. Grundlage planen und schaffen
  3. Arbeitslasten bereitstellen
  4. Umgebung optimieren

Die moderne Datenplattform in Google Cloud

In diesem Abschnitt werden die verschiedenen Teile einer modernen Datenplattform beschrieben und wie sie in Google Cloudnormalerweise aufgebaut werden. Datenplattformen als allgemeines Konzept lassen sich in zwei Bereiche unterteilen:

  • In der Datenspeicherebene werden Daten gespeichert. Die gespeicherten Daten können in Form von Dateien gespeichert werden, in denen Sie tatsächliche Byte in einem Dateisystem wie Hadoop Distributed File System (HDFS) oder Cloud Storage verwalten. Oder Sie verwenden eine Domain-spezifische Sprache (DSL) zur Verwaltung der Daten in einem Datenbank-Verwaltungssystem.
  • Die Datenberechnungsebene ist eine Datenverarbeitung, die Sie zusätzlich zum Speichersystem aktivieren können. Wie bei der Speicherschicht gibt es viele mögliche Implementierungen. Einige Datenspeichertools übernehmen auch die Datenverarbeitung. Die Aufgabe der Datenberechnungsebene in der Plattform besteht darin, Daten aus der Speicherebene zu laden, zu verarbeiten und die Ergebnisse dann in einem Zielsystem zu speichern. Das Zielsystem kann die Quellspeicherebene sein.

Einige Datenplattformen verwenden mehrere Speichersysteme für die Datenspeicherebene und mehrere Datenberechnungssysteme für die Datenverarbeitungsebene. In den meisten Fällen sind die Datenspeicherschicht und die Datenberechnungsschicht getrennt. Möglicherweise haben Sie Ihre Datenspeicherebene beispielsweise mit den folgendenGoogle Cloud -Diensten implementiert:

Möglicherweise haben Sie die Datenberechnungsschicht mit anderenGoogle Cloud -Diensten implementiert, z. B.:

Wir empfehlen Ihnen, die Daten in derselben Zone zu speichern, in der Sie die Daten verarbeiten, um die Zeit und Latenz der Kommunikation, die Kosten der ausgehenden Datenübertragung und die Anzahl der E/A-Vorgänge zwischen der Speicherebene und der Berechnungsebene zu reduzieren.

Wir empfehlen außerdem, die Datenspeicherebene von der Datenberechnungsebene getrennt zu halten. Wenn Sie diese Ebenen getrennt halten, sind Sie flexibler beim Ändern von Berechnungsebenen und Migrieren von Daten. Durch eine Trennung der Ebenen wird auch die Ressourcennutzung reduziert, da die Berechnungsebene nicht ständig ausgeführt werden muss. Daher empfehlen wir, den Datenspeicher und die Datenverarbeitung auf separaten Plattformen in derselben Zone und Region bereitzustellen. Sie können beispielsweise Ihren Datenspeicher von HDFS nach Cloud Storage verschieben und einen Dataproc-Cluster für die Berechnung verwenden.

Umgebung bewerten

In der Bewertungsphase bestimmen Sie die Anforderungen und Abhängigkeiten für die Migration der von Ihnen bereitgestellten Batch-Datenpipelines:

  1. Erstellen Sie ein umfassendes Inventar Ihrer Datenpipelines.
  2. Pipelines nach ihren Attributen und Abhängigkeiten katalogisieren.
  3. Trainieren und schulen Sie Ihre Teams in Bezug auf Google Cloud.
  4. Einen Test und einen Proof of Concept in Google Clouderstellen.
  5. Die Gesamtbetriebskosten (TCO) der Zielumgebung berechnen.
  6. Die Arbeitslasten auswählen, die als Erstes migriert werden sollen.

Weitere Informationen zur Bewertungsphase und zu diesen Aufgaben finden Sie unter Migration zu Google Cloud: Arbeitslasten bewerten und erkennen. Die folgenden Abschnitte basieren auf Informationen in jenem Dokument.

Inventar erstellen

Um den Umfang der Migration zu bestimmen, müssen Sie die Datenplattformumgebung kennen, in der Ihre Datenpipelines bereitgestellt werden:

  1. Erstellen Sie ein Inventar Ihrer Dateninfrastruktur – die verschiedenen Speicher- und Verarbeitungsschichten, die Sie für die Datenspeicherung und die Batchverarbeitung von Daten verwenden.
  2. Erstellen Sie ein Inventar der Datenpipelines, die migriert werden sollen.
  3. Erstellen Sie ein Inventar der Datensätze, die von den Datenpipelines gelesen und migriert werden müssen.

Wenn Sie ein Inventar Ihrer Datenplattform erstellen, sollten Sie für jeden Teil der Dateninfrastruktur Folgendes berücksichtigen:

  • Speicherebenen. Neben Standardspeicherplattformen wie Cloud Storage sollten Sie auch andere Speicherebenen wie Datenbanken wie Firebase, BigQuery, Bigtable und Postgres oder andere Cluster wie Apache Kafka in Betracht ziehen. Jede Speicherplattform hat eine eigene Strategie und Methode, um die Migration abzuschließen. Cloud Storage bietet beispielsweise Datenmigrationsdienste und eine Datenbank kann ein integriertes Migrationstool haben. Achten Sie darauf, dass jedes Produkt, das Sie für die Datenspeicherung verwenden, in Ihrer Zielumgebung verfügbar ist oder dass Sie einen kompatiblen Ersatz haben. Testen und prüfen Sie den technischen Datenübertragungsprozess für jede der beteiligten Speicherplattformen.
  • Komprimierungsebenen. Prüfen Sie für jede Rechenplattform den Bereitstellungsplan und alle Konfigurationsänderungen, die Sie an den verschiedenen Plattformen vorgenommen haben.
  • Netzwerklatenz. Testen und prüfen Sie die Netzwerklatenz zwischen der Quell- und Zielumgebung. Sie müssen wissen, wie lange es dauert, bis die Daten kopiert werden. Außerdem müssen Sie die Netzwerklatenz von Clients und externen Umgebungen (z. B. einer lokalen Umgebung) zur Zielumgebung im Vergleich zur Quellumgebung testen.

  • Konfigurationen und Bereitstellung. Jedes Dateninfrastrukturprodukt hat seine eigenen Einrichtungsmethoden. Ermitteln Sie Ihren Bestand an benutzerdefinierten Konfigurationen, die Sie für die einzelnen Komponenten erstellt haben, und welche Komponenten Sie in den Standardversionen der einzelnen Plattformen verwenden, z. B. welche Dataproc-Version oder welche Apache Kafka-Version Sie haben. Achten Sie darauf, dass diese Konfigurationen im Rahmen Ihres automatisierten Bereitstellungsprozesses bereitgestellt werden.

    Sie müssen wissen, wie jede Komponente konfiguriert ist, da sich die Verarbeitungsengines bei unterschiedlicher Konfiguration möglicherweise anders verhalten – insbesondere, wenn sich das Framework der Verarbeitungsschicht während der Migration ändert. Wenn in der Zielumgebung beispielsweise eine andere Version von Apache Spark ausgeführt wird, haben sich möglicherweise einige Konfigurationen des Spark-Frameworks zwischen den Versionen geändert. Diese Art von Konfigurationsänderung kann zu Änderungen bei den Ausgaben, Serializationen und Berechnungen führen.

    Wir empfehlen, während der Migration automatisierte Bereitstellungen zu verwenden, damit Versionen und Konfigurationen unverändert bleiben. Wenn Sie Versionen und Konfigurationen nicht beibehalten können, sollten Sie Tests durchführen, um die vom Framework berechneten Datenausgaben zu validieren.

  • Clustergrößen. Bei selbstverwalteten Clustern, z. B. einem langlebigen Dataproc-Cluster oder einem Apache Kafka-Cluster, der in Compute Engine ausgeführt wird, notieren Sie sich die Anzahl der Knoten und CPUs sowie den Arbeitsspeicher für jeden Knoten in den Clustern. Die Migration in eine andere Region kann zu einer Änderung des Prozessors führen, der für Ihre Bereitstellung verwendet wird. Wir empfehlen daher, Ihre Arbeitslasten zu profilieren und zu optimieren, nachdem Sie die migrierte Infrastruktur in der Produktion bereitgestellt haben. Wenn eine Komponente vollständig verwaltet oder serverlos ist (z. B. Dataflow), ist die Größe Teil jedes einzelnen Jobs und nicht Teil des Clusters selbst.

Die folgenden zu prüfenden Elemente in Ihrem Inventar beziehen sich auf die Datenpipelines:

  • Datenquellen und -senken Berücksichtigen Sie die Quellen und Senken, die jede Datenpipeline zum Lesen und Schreiben von Daten verwendet.
  • Service Level Agreements (SLAs) und Service Level Objectives (SLOs) SLAs und SLOs für Batch-Datenpipelines werden in der Regel in der Zeit bis zum Abschluss gemessen, können jedoch auch auf andere Weise gemessen werden, z. B. anhand der genutzten Rechenleistung. Diese Geschäftsmetadaten sind wichtig für die Verbesserung der Geschäftskontinuitäts- und Notfallwiederherstellungsprozesse (Disaster Recovery Plan, BCDR), z. B. für den Failover einer Teilmenge Ihrer kritischen Pipelines zu einer anderen Region bei einem zonalen oder regionalen Ausfall.
  • Abhängigkeiten von Datenpipelines. Einige Datenpipelines basieren auf Daten, die von einer anderen Datenpipeline generiert werden. Berücksichtigen Sie bei der Aufteilung von Pipelines in Migrationssprints die Datenabhängigkeiten.
  • Generierte und genutzte Datensätze Geben Sie für jede Datenpipeline an, welche Datasets sie verwendet und welche sie generiert. So können Sie Abhängigkeiten zwischen Pipelines und anderen Systemen oder Komponenten in Ihrer gesamten Architektur leichter erkennen.

Die folgenden zu prüfenden Elemente in Ihrem Inventar beziehen sich auf die zu migrierenden Datensätze:

  • Datasets. Identifizieren Sie die Datensätze, die in die Zielumgebung migriert werden müssen. Möglicherweise betrachten Sie bestimmte Verlaufsdaten als nicht erforderlich für die Migration oder sie sollen zu einem anderen Zeitpunkt migriert werden, zum Beispiel archivierte Daten, die nicht aktiv verwendet werden. Wenn Sie den Umfang des Migrationsprozesses und der Migrationssprints definieren, können Sie die Risiken bei der Migration reduzieren.
  • Datengrößen Wenn Sie Dateien vor der Übertragung komprimieren möchten, notieren Sie sich die Dateigröße vor und nach der Komprimierung. Die Größe Ihrer Daten wirkt sich auf den Zeit- und Kostenaufwand aus, der für das Kopieren der Daten von der Quelle zum Ziel erforderlich ist. Bei der Berücksichtigung dieser Faktoren können Sie zwischen Ausfallzeitstrategien wählen, wie weiter unten in diesem Dokument beschrieben.
  • Datenstruktur Klassifizieren Sie jeden zu migrierenden Datensatz und achten Sie darauf, ob die Daten strukturiert, halbstrukturiert oder unstrukturiert sind. Wenn Sie die Datenstruktur kennen, können Sie eine Strategie dazu entwickeln, wie geprüft werden kann, ob Daten korrekt und vollständig migriert wurden.

Bewertung abschließen

Nachdem Sie die Inventare erstellt haben, die sich auf Ihre Kubernetes-Cluster und -Arbeitslasten beziehen, schließen Sie die restlichen Aktivitäten der Bewertungsphase unter Migration zu Google Cloud: Arbeitslasten bewerten und erkennen ab.

Grundlage planen und aufbauen

Die Planungs- und Erstellungsphase der Migration zu Google Cloud umfasst die folgenden Aufgaben:

  1. Erstellen Sie eine Ressourcenhierarchie.
  2. Identity and Access Management (IAM) konfigurieren
  3. Richten Sie die Abrechnung ein.
  4. Richten Sie die Netzwerkverbindung ein.
  5. Erhöhen Sie die Sicherheit.
  6. Logging, Monitoring und Benachrichtigungen einrichten

Weitere Informationen zu den einzelnen Aufgaben finden Sie unter Zu Google Cloudmigrieren: Grundlage schaffen.

Daten- und Datenpipelines migrieren

In den folgenden Abschnitten werden einige Aspekte des Plans zur Migration von Daten- und Batch-Datenpipelines beschrieben. Es werden einige Konzepte zu den Eigenschaften von Datenpipelines definiert, die beim Erstellen des Migrationsplans wichtig sind. Außerdem werden einige Konzepte für Datentests erläutert, mit denen Sie die Zuverlässigkeit der Datenmigration erhöhen können.

Migrationsplan

In Ihrem Migrationsplan müssen Sie Zeit für die Datenübertragung einplanen. Ihr Plan sollte die Netzwerklatenz, die Zeit zum Testen der Datenvollständigkeit und zum Abrufen nicht migrierter Daten sowie alle Netzwerkkosten berücksichtigen. Da die Daten von einer Region in eine andere kopiert werden, sollte Ihr Plan für die Netzwerkkosten die interregionalen Netzwerkkosten enthalten.

Wir empfehlen, die verschiedenen Pipelines und Datensätze in Sprints aufzuteilen und sie separat zu migrieren. Dieser Ansatz hilft, die Risiken für jeden Migrations-Sprint zu reduzieren und ermöglicht Verbesserungen in jedem Sprint. Um Ihre Migrationsstrategie zu verbessern und Probleme frühzeitig zu erkennen, empfehlen wir, kleinere, nicht kritische Arbeitslasten zu priorisieren, bevor Sie größere, kritischere Arbeitslasten migrieren.

Ein weiterer wichtiger Teil eines Migrationsplans besteht darin, die Strategie, die Abhängigkeiten und die Art der verschiedenen Datenpipelines aus der Rechenebene zu beschreiben. Wenn Ihre Datenspeicherebene und Ihre Datenberechnungsebene auf demselben System basieren, empfehlen wir, die Leistung des Systems während der Datenübertragung zu beobachten. Das Kopieren großer Datenmengen kann in der Regel zu einem E/A-Overhead auf dem System führen und die Leistung in der Rechenschicht beeinträchtigen. Wenn Sie beispielsweise eine Arbeitslast ausführen, um Daten aus einem Kafka-Cluster in Batchform zu extrahieren, können die zusätzlichen I/O-Vorgänge zum Lesen großer Datenmengen zu einer Leistungsminderung bei allen aktiven Datenpipelines führen, die noch in der Quellumgebung ausgeführt werden. In diesem Fall sollten Sie die Leistung des Systems mithilfe von integrierten oder benutzerdefinierten Messwerten überwachen. Um eine Überlastung des Systems zu vermeiden, empfehlen wir, einige Arbeitslasten während des Datenkopiervorgangs außer Betrieb zu setzen oder die Kopierphase zu drosseln.

Da das Kopieren von Daten die Migration zu einem langwierigen Prozess macht, empfehlen wir, Notfallpläne für den Fall zu haben, dass während der Migration etwas schiefgeht. Wenn beispielsweise die Datenverschiebung länger als erwartet dauert oder die Integritätstests fehlschlagen, bevor Sie das neue System online stellen, sollten Sie überlegen, ob Sie ein Rollback durchführen möchten oder versuchen, fehlgeschlagene Vorgänge zu wiederholen. Ein Rollback kann zwar eine saubere Lösung sein, es kann jedoch zeitaufwendig und teuer sein, große Datasets mehrmals zu kopieren. Wir empfehlen Ihnen, klare und vordefinierte Tests zu haben, um zu bestimmen, welche Aktionen in welchen Bedingungen ausgeführt werden, wie viel Zeit für den Versuch, Patches zu erstellen, zulässig ist und wann ein vollständiges Rollback durchgeführt werden sollte.

Es ist wichtig, zwischen den Tools und Scripts, die Sie für die Migration verwenden, und den Daten, die Sie kopieren, zu unterscheiden. Wenn Sie die Datenübertragung rückgängig machen, müssen Sie die Daten noch einmal kopieren und bereits kopierte Daten entweder überschreiben oder löschen. Ein Rollback der Änderungen an die Tools und Skripts ist möglicherweise einfacher und kostengünstiger, aber Änderungen an den Tools können das Kopieren von Daten erzwingen. Beispielsweise müssen Sie Daten möglicherweise noch einmal kopieren, wenn Sie in einem Script einen neuen Zielpfad erstellen, der einen Cloud Storage-Speicherort dynamisch generiert. Um das erneute Kopieren von Daten zu vermeiden, sollten Sie Ihre Scripts so erstellen, dass sie fortgesetzt und idempotent ausgeführt werden können.

Merkmale von Datenpipelines

Um einen optimalen Migrationsplan zu erstellen, müssen Sie die Eigenschaften verschiedener Datenpipelines kennen. Batch-Pipelines, die Daten schreiben, unterscheiden sich von Batch-Pipelines, die Daten lesen:

  • Datenpipelines, die Daten schreiben: Da sich der Status des Quellsystems ändert, kann es schwierig sein, Daten gleichzeitig in die Quellumgebung zu schreiben und in die Zielumgebung zu kopieren. Berücksichtigen Sie die Laufzeiten von Pipelines, die Daten schreiben, und versuchen Sie, ihre Migration früher im Gesamtprozess zu priorisieren. Auf diese Weise haben Sie bereits Daten in der Zielumgebung, bevor Sie die Pipelines migrieren, die die Daten lesen.
  • Datenpipelines, die Daten lesen: Pipelines, die Daten lesen, können unterschiedliche Anforderungen an die Datenaktualität haben. Wenn die Pipelines, die Daten generieren, im Quellsystem angehalten werden, können die Pipelines, die Daten lesen, möglicherweise ausgeführt werden, während Daten in die Zielumgebung kopiert werden.

Daten haben einen Status und das Kopieren von Daten zwischen Regionen ist kein atomarer Vorgang. Daher müssen Sie während des Kopiervorgangs auf Statusänderungen achten.

Außerdem ist es wichtig, im Migrationsplan zwischen den Systemen zu unterscheiden. Ihre Systeme haben möglicherweise unterschiedliche funktionale und nicht funktionale Anforderungen, z. B. ein System für Batch und ein anderes für das Streaming. Daher sollte Ihr Plan unterschiedliche Strategien für die Migration der einzelnen Systeme enthalten. Geben Sie die Abhängigkeiten zwischen den Systemen an und legen Sie fest, wie Sie die Ausfallzeiten für jedes System in jeder Phase der Migration reduzieren.

Ein typischer Plan für einen Migrations-Sprint sollte Folgendes enthalten:

  • General Strategy. Beschreiben Sie die Strategie für die Migration in diesem Sprint. Gängige Strategien finden Sie unter Arbeitslasten bereitstellen.
  • Liste der Tools und Methoden für das Kopieren von Daten und die Bereitstellung von Ressourcen Geben Sie ein Tool an, mit dem Sie Daten kopieren oder Ressourcen in der Zielumgebung bereitstellen möchten. Diese Liste sollte benutzerdefinierte Scripts enthalten, die zum Kopieren von Cloud Storage-Assets verwendet werden, Standardtools wie die Google Cloud CLI und Google Cloud -Tools wie Migration Services.
  • Liste der Ressourcen, die in der Zielumgebung bereitgestellt werden sollen Listen Sie alle Ressourcen auf, die in der Zielumgebung bereitgestellt werden müssen. Diese Liste sollte alle Komponenten der Dateninfrastruktur enthalten, z. B. Cloud Storage-Buckets, BigQuery-Datasets und Dataproc-Cluster. In einigen Fällen umfassen erste Migrationssprints die Bereitstellung eines Clusters mit größerer Größe (z. B. eines Dataproc-Clusters) mit geringerer Kapazität, während spätere Sprints die Anpassung der Größe an neue Arbeitslasten umfassen. Achten Sie darauf, dass Ihr Plan eine mögliche Größenänderung umfasst.
  • Liste der zu kopierenden Datasets Geben Sie für jedes Dataset die folgenden Informationen an:
    • Reihenfolge beim Kopieren (falls zutreffend): Für die meisten Strategien kann die Reihenfolge des Vorgangs wichtig sein. Eine Ausnahme bildet die Strategie planmäßige Wartung, die weiter unten in diesem Dokument beschrieben wird.
    • Größe
    • Schlüsselstatistiken: Diagrammschlüsselstatistiken, z. B. die Zeilennummer, mit denen Sie prüfen können, ob das Dataset erfolgreich kopiert wurde.
    • Geschätzte Zeit zum Kopieren: Die Zeit für die Datenübertragung basierend auf dem Migrationsplan.
    • Kopiermethode: Weitere Informationen finden Sie in der Liste der Tools und Methoden, die weiter oben in diesem Dokument beschrieben wurden.
    • Verifizierungstests: Listen Sie explizit die Tests auf, die Sie durchführen möchten, um zu prüfen, ob die Daten vollständig kopiert wurden.
    • Notfallplan: Beschreiben Sie, was zu tun ist, wenn Überprüfungstests fehlschlagen. Ihr Notfallplan sollte angeben, wann Sie die Kopie wiederholen oder die Lücke schließen möchten und wann Sie ein vollständiges Rollback durchführen und das gesamte Dataset neu kopieren möchten.

Test

In diesem Abschnitt werden einige typische Testtypen beschrieben, die Sie planen können. Die Tests können Ihnen helfen, die Datenintegrität und -vollständigkeit zu gewährleisten. Sie können Ihnen auch dabei helfen, dafür zu sorgen, dass die Rechenebene wie erwartet funktioniert und bereit ist, Ihre Datenpipelines auszuführen.

  • Zusammenfassung oder Hash-Vergleich: Um die Datenintegrität nach dem Kopieren der Daten zu überprüfen, müssen Sie das ursprüngliche Dataset mit der neuen Kopie in der Zielumgebung vergleichen. Wenn die Daten in BigQuery-Tabellen strukturiert sind, können Sie die beiden Tabellen nicht in einer Abfrage zusammenführen, um zu prüfen, ob alle Daten vorhanden sind, da sich die Tabellen in verschiedenen Regionen befinden. Aufgrund der Kosten und Latenz ist es in BigQuery nicht möglich, Abfragen zu erstellen, bei denen Daten über Regionen hinweg zusammengeführt werden. Stattdessen muss die Vergleichsmethode jeden Datensatz zusammenfassen und die Ergebnisse vergleichen. Je nach Datensatzstruktur kann die Methode zur Zusammenfassung variieren. Für eine BigQuery-Tabelle kann beispielsweise eine Aggregationsanfrage verwendet werden, für eine Gruppe von Dateien in Cloud Storage jedoch eine Spark-Pipeline, um einen Hashwert für jede Datei zu berechnen und dann die Hashwerte zu aggregieren.

  • Canary-Abläufe: Canary-Abläufe aktivieren Jobs, die auf die Integrität und Vollständigkeit von Daten prüfen sollen. Bevor Sie mit Geschäftsanwendungen wie der Datenanalyse fortfahren, kann es hilfreich sein, Canary-Flow-Jobs auszuführen, um sicherzustellen, dass die Eingabedaten eine Reihe von Voraussetzungen erfüllen. Sie können Canary-Abläufe als benutzerdefinierte Datenpipelines oder als Abläufe in einem DAG auf Cloud Composer-Basis implementieren. Canary-Abläufe können Ihnen bei der Ausführung von Aufgaben helfen, z. B. um zu prüfen, ob für bestimmte Felder keine Werte fehlen, oder ob die Zeilenanzahl bestimmter Datasets mit der erwarteten Anzahl übereinstimmt.

    Sie können Canary-Flows auch verwenden, um Zusammenfassungen oder andere Aggregationen einer Spalte oder einer Teilmenge der Daten zu erstellen. Anschließend können Sie die Daten mithilfe des Canary-Flows mit einem ähnlichen Digest oder einer ähnlichen Aggregation vergleichen, die aus der Kopie der Daten stammen.

    Canary-Ablaufmethoden sind nützlich, wenn Sie die Genauigkeit der Daten bewerten müssen, die in Dateiformaten wie Avro-Dateien zusätzlich zu Cloud Storage gespeichert und kopiert werden. Canary-Flüsse generieren normalerweise keine neuen Daten, sondern schlagen fehl, wenn eine Reihe von Regeln in den Eingabedaten nicht erfüllt wird.

  • Testumgebung: Nachdem Sie Ihren Migrationsplan erstellt haben, sollten Sie ihn in einer Testumgebung testen. Die Testumgebung sollte das Kopieren von Stichprobendaten oder Staging-Daten in eine andere Region umfassen, um die Zeit zu schätzen, die zum Kopieren von Daten über das Netzwerk benötigt wird. So können Sie Probleme mit dem Migrationsplan erkennen und prüfen, ob die Daten erfolgreich migriert werden können. Die Tests sollten sowohl funktionale als auch nicht funktionale Tests umfassen. Mit Funktionstests wird überprüft, ob die Daten korrekt migriert wurden. Bei nicht funktionalen Tests wird geprüft, ob die Migration die Anforderungen an Leistung, Sicherheit und andere nicht funktionale Anforderungen erfüllt. Jeder Migrationsschritt in Ihrem Plan sollte Validierungskriterien enthalten, die angeben, wann der Schritt als abgeschlossen betrachtet werden kann.

Zur Unterstützung der Datenvalidierung können Sie das Datenvalidierungstool (DVT) verwenden. Das Tool führt mehrstufige Datenvalidierungsfunktionen von der Tabellen- bis zur Zeilenebene aus und hilft Ihnen, die Ergebnisse aus Ihren Quell- und Zielsystemen zu vergleichen.

Ihre Tests sollten die Bereitstellung der Rechenebene und die kopierten Datensätze prüfen. Eine Möglichkeit dazu besteht darin, eine Testpipeline zu erstellen, mit der einige Aggregationen der kopierten Datensätze berechnet werden können, um sicherzustellen, dass die Quell- und Zieldatensätze übereinstimmen. Eine Diskrepanz zwischen Quell- und Ziel-Datasets tritt häufiger auf, wenn die Dateien, die Sie zwischen Regionen kopieren, keine exakten Bytekopierdarstellungen zwischen dem Quell- und Zielsystem sind (z. B. wenn Sie Dateiformate ändern oder Dateikomprimierungen).

Angenommen, Sie haben einen Datensatz, der aus durch Zeilenumbruch getrennten JSON-Dateien besteht. Die Dateien werden in einem Cloud Storage-Bucket gespeichert und als externe Tabelle in BigQuery bereitgestellt. Um die Menge der über das Netzwerk übertragenen Daten zu reduzieren, können Sie im Rahmen der Migration eine Avro-Komprimierung durchführen, bevor Sie Dateien in die Zielumgebung kopieren. Diese Konvertierung hat viele Vorteile, aber auch einige Risiken, da die Dateien, die in die Zielumgebung geschrieben werden, keine Bytekopie der Dateien in der Quellumgebung sind.

Um die Risiken des Konvertierungsszenarios zu minimieren, können Sie einen Dataflow-Job erstellen oder BigQuery verwenden, um einige Aggregationen und Prüfsummen-Hashes des Datasets zu berechnen, z. B. durch Berechnen von Summen, Mittelwerten oder Quantilen für jede numerische Spalte. Bei Stringspalten können Sie Aggregationen zusätzlich zur Stringlänge oder zum Hash-Code dieses Strings berechnen. Für jede Zeile können Sie einen aggregierten Hash aus einer Kombination aller anderen Spalten berechnen, mit dem sich mit hoher Genauigkeit überprüfen lässt, ob eine Zeile mit der ursprünglichen Zeile übereinstimmt. Diese Berechnungen werden sowohl in der Quell- als auch in der Zielumgebung durchgeführt und dann verglichen. In einigen Fällen, z. B. wenn Ihr Dataset in BigQuery gespeichert ist, können Sie keine Tabellen aus der Quell- und der Zielumgebung zusammenführen, da sie sich in verschiedenen Regionen befinden. Daher müssen Sie einen Client verwenden, der mit beiden Umgebungen verbunden werden kann.

Sie können die vorherigen Testmethoden entweder in BigQuery oder als Batchjob (z. B. in Dataflow) implementieren. Anschließend können Sie die Aggregationsjobs ausführen und die für die Quell- und die Zielumgebung berechneten Ergebnisse vergleichen. So können Sie dafür sorgen, dass die Daten vollständig und korrekt sind.

Ein weiterer wichtiger Aspekt beim Testen der Rechenebene besteht darin, Pipelines auszuführen, die alle Arten von Verarbeitungs- und Rechenmethoden umfassen. Für verwaltete Rechenmaschinen wie BigQuery oder Dataflow ist das Testen der Pipeline weniger wichtig. Es ist jedoch wichtig, die Pipeline für nicht verwaltete Rechenmaschinen wie Dataproc zu testen. Wenn Sie beispielsweise einen Dataproc-Cluster haben, der verschiedene Berechnungstypen verarbeitet, z. B. Apache Spark, Apache Hive, Apache Flink oder Apache MapReduce, sollten Sie jede Laufzeit testen, um sicherzustellen, dass die verschiedenen Arbeitslasttypen übertragen werden können.

Migrationsstrategien

Nachdem Sie Ihren Migrationsplan mit entsprechenden Tests überprüft haben, können Sie die Daten migrieren. Bei der Migration von Daten können Sie für verschiedene Arbeitslasten unterschiedliche Strategien verwenden. Im Folgenden finden Sie Beispiele für Migrationsstrategien, die Sie unverändert verwenden oder an Ihre Anforderungen anpassen können:

  • Geplante Wartung: Sie planen, wann das Umstellungsfenster auftritt. Diese Strategie eignet sich gut, wenn Daten häufig geändert werden, SLOs und SLAs aber einige Ausfallzeiten verkraften können. Diese Strategie bietet eine hohe Zuverlässigkeit für die übertragenen Daten, da die Daten während des Kopierens vollständig inaktiv sind. Weitere Informationen finden Sie unter Planmäßige Wartung in „Migration zu Google Cloud: Große Datasets übertragen“.
  • Schreibgeschützte Umstellung: Eine geringfügige Variante der geplanten Wartungsstrategie, bei der die Quellsystemdatenplattform es schreibgeschützten Datenpipelines ermöglicht, weiterhin Daten zu lesen, während Daten kopiert werden. Diese Strategie ist nützlich, da einige Datenpipelines weiter funktionieren und Informationen für Endsysteme bereitstellen können. Der Nachteil dieser Strategie besteht darin, dass die erzeugten Daten während der Migration inaktiv sind und die Quelldaten nicht aktualisiert werden. Daher müssen Sie nach der Migration möglicherweise eine Aufholstrategie anwenden, um die veralteten Daten in den Endsystemen zu berücksichtigen.
  • Vollständig aktiv: Sie kopieren die Daten mit einem bestimmten Zeitstempel, während die Quellumgebung noch für Lese- und Schreib-Datenpipelines aktiv ist. Nachdem Sie die Daten kopiert und zur neuen Bereitstellung gewechselt haben, führen Sie eine Delta-Kopiephase aus, um die Daten abzurufen, die nach dem Migrationszeitstempel in der Quellumgebung generiert wurden. Dieser Ansatz erfordert im Vergleich zu anderen Strategien mehr Koordination und Überlegungen. Daher muss Ihr Migrationsplan enthalten, wie Sie die Aktualisierungs- und Löschvorgänge für die Quelldaten handhaben.
  • Doppelte Schreibvorgänge: Die Datenpipelines können sowohl in der Quell- als auch in der Zielumgebung ausgeführt werden, während Daten kopiert werden. Bei dieser Strategie wird die Deltakopiephase vermieden, die zum Backfillen von Daten erforderlich ist, wenn Sie die Strategien „Vollständig aktiv“ oder „Schreibgeschützt“ verwenden. Damit die Datenpipelines jedoch identische Ergebnisse liefern, sind vor der Migration mehr Tests erforderlich. Wenn Sie keine Vorabtests durchführen, werden Sie Probleme haben, ein Split-Brain-Szenario zu konsolidieren. Die Strategie mit doppelten Schreibvorgängen führt außerdem zu potenziellen Kosten, da dieselben Arbeitslasten zweimal in verschiedenen Regionen ausgeführt werden. Diese Strategie enthält die Möglichkeit, Ihre Plattform ohne Ausfallzeiten zu migrieren, erfordert jedoch viel mehr Koordination, um sie korrekt auszuführen.

Tests nach der Migration

Nach Abschluss der Migration sollten Sie die Datenvollständigkeit und die Gültigkeit der Datenpipelines testen. Wenn Sie die Migration in Sprints durchführen, müssen Sie diese Tests nach jedem Sprint ausführen. Die Tests, die Sie in dieser Phase durchführen, ähneln Integrationstests: Sie testen die Gültigkeit einer Datenpipeline, die Geschäftsanwendungsfälle mit vollständigen Produktionsdaten als Eingabe ausführt, und prüfen dann die Ausgabe auf Gültigkeit. Sie können die Ausgabe des Integrationstests mit der Ausgabe der Quellumgebung vergleichen, indem Sie dieselbe Datenpipeline sowohl in der Quell- als auch in der Zielumgebung ausführen. Dieser Test funktioniert nur, wenn die Datenpipeline deterministisch ist und Sie dafür sorgen können, dass die Eingabe in beiden Umgebungen identisch ist.

Sie können prüfen, ob die Daten vollständig sind, wenn sie eine Reihe von vordefinierten Kriterien erfüllen, bei denen die Daten in der Quellumgebung mit den Daten in der Zielumgebung übereinstimmen (oder ausreichend ähnlich sind). Je nachdem, welche Strategie Sie im vorherigen Abschnitt verwendet haben, stimmen die Daten möglicherweise nicht genau überein. Daher müssen Sie Kriterien vordefinieren, um die Datenvollständigkeit für Ihren Anwendungsfall zu beschreiben. Bei Zeitreihendaten können Sie beispielsweise davon ausgehen, dass die Daten vollständig sind, wenn der aktuelle Datensatz nicht älter als fünf Minuten ist.

Umstellung

Nachdem Sie die Daten und Datenpipelines in der Zielumgebung überprüft und getestet haben, können Sie mit der Umstellungsphase beginnen. Wenn diese Phase beginnt, müssen Kunden möglicherweise ihre Konfiguration ändern, um auf die neuen Systeme zu verweisen. In einigen Fällen kann die Konfiguration nicht mit der Konfiguration übereinstimmen, die auf das Quellsystem verweist. Wenn ein Dienst beispielsweise Daten aus einem Cloud Storage-Bucket lesen muss, müssen die Kunden die Konfiguration für den zu verwendenden Bucket ändern. Cloud Storage-Bucket-Namen sind global eindeutig. Der Cloud Storage-Bucket der Zielumgebung unterscheidet sich daher von dem der Quellumgebung.

Während der Umstellungsphase sollten Sie die Arbeitslasten der Quellumgebung außer Betrieb nehmen und die Planung aufheben. Wir empfehlen, die Daten der Quellumgebung noch einige Zeit aufzubewahren, für den Fall, dass Sie einen Rollback ausführen müssen.

Die Testphase vor der Migration ist nicht so vollständig wie ein Produktionslauf einer Datenpipeline. Daher müssen Sie nach Abschluss der Umstellung und Inbetriebnahme des Zielsystems die Messwerte, Laufzeiten und semantischen Ausgaben Ihrer Datenpipelines überwachen. So können Sie Fehler erkennen, die in der Testphase möglicherweise übersehen wurden, und die Migration erfolgreich abschließen.

Umgebung optimieren

Die Optimierung ist die letzte Phase Ihrer Migration. In dieser Phase machen Sie Ihre Umgebung effizienter, indem Sie mehrere Iterationen einer wiederholbaren Schleife ausführen, bis Ihre Umgebung Ihre Optimierungsanforderungen erfüllt:

  1. Bewerten Sie die aktuelle Umgebung, Teams und Optimierungsschleife.
  2. Optimierungsanforderungen und -ziele festlegen.
  3. Umgebung und Teams optimieren.
  4. Verbessern Sie die Optimierungsschleife.

Weitere Informationen zum Optimieren Ihrer Google Cloud -Umgebung finden Sie unter Migration zu Google Cloud: Umgebung optimieren.

Daten und Rechenressourcen in der Google Cloud für eine Migration zwischen Regionen vorbereiten

Dieser Abschnitt bietet einen Überblick über die Daten- und Rechenressourcen inGoogle Cloud und die Designprinzipien zur Vorbereitung auf eine migrationsübergreifende Migration.

BigQuery

Da BigQuery ein serverloses SQL-Data Warehouse ist, müssen Sie die Rechenebene nicht bereitstellen. Wenn einige Ihrer BigQuery-Clients Regionen für die Verarbeitung angeben, müssen Sie diese Clients anpassen. Ansonsten ist BigQuery in der Quell- und der Zielumgebung identisch. BigQuery-Daten werden in zwei Arten von Tabellen gespeichert:

  • BigQuery-Tabellen: Tabellen im BigQuery-Format. BigQuery verwaltet die Datendateien für Sie. Weitere Informationen zum Migrieren von Daten im BigQuery-Format finden Sie unter Datasets verwalten.
  • Externe BigQuery-Tabellen: Tabellen, für die die Daten außerhalb von BigQuery gespeichert werden. Nach dem Verschieben der Daten müssen Sie die externen Tabellen am neuen Ziel neu erstellen. Weitere Informationen zum Migrieren externer Tabellen finden Sie unter Einführung in externe Tabellen.

Cloud Storage

Cloud Storage bietet den Storage Transfer Service, mit dem Sie Ihre Daten migrieren können.

Dataflow (Batch)

Dataflow ist eine von Google verwaltete Datenverarbeitungs-Engine. Um die Dataflow-Migration zu vereinfachen und dafür zu sorgen, dass Ihre Jobs in jeder Region bereitgestellt werden können, sollten Sie alle Eingaben und Ausgaben als Parameter in Ihren Job einfügen. Anstatt die Speicherorte für Eingabe- und Ausgabedaten in Ihren Quellcode einzutragen, empfehlen wir, Cloud Storage-Pfade und Datenbankverbindungsstrings als Argumente oder Parameter zu übergeben.

Dataproc

Dataproc ist eine verwaltete Apache Hadoop-Umgebung, in der jede Arbeitslast ausgeführt werden kann, die mit dem Apache Hadoop-Framework kompatibel ist. Sie ist mit Frameworks wie Apache Spark, Apache Flink und Apache Hive kompatibel.

Sie haben folgende Möglichkeiten, Dataproc zu verwenden. Dies wirkt sich darauf aus, wie Sie Ihre Dataproc-Umgebung zwischen Regionen migrieren sollten:

  • Sitzungsspezifische Cluster mit Daten in Cloud Storage: Cluster werden zum Ausführen bestimmter Jobs erstellt und nach Abschluss der Jobs gelöscht. Das bedeutet, dass auch die HDFS-Ebene oder ein anderer Status des Clusters gelöscht wird. Wenn Ihre Konfiguration die folgenden Kriterien erfüllt, ist diese Art der Nutzung im Vergleich zu anderen Nutzungsarten einfacher zu migrieren:
    • Eingaben und Ausgaben für Ihre Jobs sind nicht im Quellcode hartcodiert. Stattdessen erhalten Ihre Jobs Eingaben und Ausgaben als Argumente.
    • Die Bereitstellung der Dataproc-Umgebung ist automatisiert, einschließlich der Konfigurationen für die einzelnen Frameworks, die in Ihrer Umgebung verwendet werden.
  • Langlebige Cluster mit externen Daten: Sie haben einen oder mehrere Cluster, die jedoch langlebige Cluster sind – auch wenn im Cluster keine Jobs ausgeführt werden, ist der Cluster aktiv und wird noch ausgeführt. Daten und Rechenleistung sind getrennt, da die Daten außerhalb des Clusters inGoogle Cloud -Lösungen wie Cloud Storage oder BigQuery gespeichert werden. Dieses Modell ist in der Regel effektiv, wenn immer Jobs auf dem Cluster ausgeführt werden. Es ist also nicht sinnvoll, Cluster wie beim sitzungsspezifischen Modell abzubauen und neu einzurichten. Da Daten und Rechenleistung getrennt sind, ähnelt die Migration der Migration des sitzungsspezifischen Modells.
  • Langlebige Cluster mit Daten im Cluster: Der Cluster ist langlebig, aber der Cluster behält den Status, die Daten oder beides im Cluster bei, meist als Daten auf HDFS. Diese Art der Nutzung erschwert die Migration, da Daten und Rechenleistung nicht getrennt sind. Wenn Sie die eine ohne die andere migrieren, besteht ein hohes Risiko, dass Inkonsistenzen entstehen. In diesem Fall sollten Sie vor der Migration Daten und Status außerhalb des Clusters verschieben, um sie voneinander zu trennen. Wenn dies nicht möglich ist, empfehlen wir die Verwendung der Strategie einer planmäßigen Wartung, um das Risiko von Inkonsistenzen in Ihren Daten zu reduzieren.

Da es viele potenzielle Frameworks und viele Versionen und Konfigurationen dieser Frameworks gibt, müssen Sie gründlich testen, bevor Sie Ihren Migrationsplan ausführen.

Cloud Composer

Cloud Composer ist die verwaltete Version von Apache Airflow für die Workflow-Orchestrierung und -Planung in Google Cloud. DAGs, Konfigurationen und Protokolle werden in einem Cloud Storage-Bucket verwaltet, der mit Ihrer Cloud Composer-Bereitstellung migriert werden sollte. Wenn Sie den Status Ihrer Cloud Composer-Bereitstellung migrieren möchten, können Sie Umgebungs-Snapshots speichern und laden.

Wenn Sie benutzerdefinierte Plug-ins in Ihrer Cloud Composer-Instanz bereitgestellt haben, empfehlen wir Ihnen, eine Infrastruktur-als-Code-Methode anzuwenden, um die Umgebung vollständig automatisch neu zu erstellen.

Cloud Composer verwaltet keine Daten, sondern aktiviert andere Frameworks und Plattformen für die Datenverarbeitung. Daher kann die Migration von Cloud Composer vollständig von den Daten getrennt erfolgen. Cloud Composer verarbeitet außerdem keine Daten. Daher muss sich Ihre Bereitstellung nicht in derselben Region wie die Daten befinden. Sie können also eine Cloud Composer-Bereitstellung in der Zielumgebung erstellen und trotzdem Pipelines in der Quellumgebung ausführen. In einigen Fällen kann es nützlich sein, verschiedene Pipelines in verschiedenen Regionen zu betreiben, während die gesamte Plattform migriert wird.

Cloud Data Fusion

Cloud Data Fusion ist ein visuelles Integrationstool, mit dem Sie Datenpipelines mithilfe eines visuellen Editors erstellen können. Cloud Data Fusion basiert auf dem Open-Source-Projekt CDAP. Ähnlich wie Cloud Composer verwaltet Cloud Data Fusion keine Daten selbst, sondern aktiviert andere Frameworks und Plattformen für die Datenverarbeitung. Ihre Cloud Data Fusion-Pipelines sollten auf eine der folgenden Arten aus der Quellumgebung exportiert und in die Zielumgebung importiert werden:

Je nachdem, wie viele Aufrufe Sie migrieren müssen, ist eine Methode möglicherweise besser geeignet als die andere. Das Erstellen eines Migrationsscripts mit der CDAP API kann schwierig sein und erfordert mehr Softwareentwicklungskenntnisse. Wenn Sie jedoch viele Workflows haben oder sich die Workflows relativ häufig ändern, ist ein automatisierter Prozess möglicherweise die beste Lösung.

Weitere Informationen

Beitragende

Autor: Eyal Ben Ivri | Cloud Solutions Architect

Weiterer Beitragender: Marco Ferrari | Cloud Solutions Architect