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 auf Google Cloud entwerfen, um die Auswirkungen einer zukünftigen Erweiterung auf andere Regionen oder einer Migration von Region zu Region 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:

  • Vorbereitung der Migration von Daten und Datenpipelines
  • Richten Sie während der Migrationsphasen Prüfungen ein.
  • Erstellen Sie eine flexible Migrationsstrategie, indem Sie Datenspeicher und Datenverarbeitung 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 Zu Google Cloudmigrieren: Erste Schritte definierten Phasen:

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

Die moderne Datenplattform auf Google Cloud

In diesem Abschnitt werden die verschiedenen Teile einer modernen Datenplattform und ihre übliche Struktur in Google Cloudbeschrieben. Datenplattformen lassen sich allgemein 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 Tools zur Datenspeicherung übernehmen auch die Datenberechnung. Die Datenberechnungsebene in der Plattform dient dazu, Daten aus der Speicherebene zu laden, die Daten zu verarbeiten und die Ergebnisse dann in einem Zielsystem zu speichern. Das Zielsystem kann die Quellspeicherebene sein.

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

Möglicherweise haben Sie die Datenschicht für die Berechnung mit anderenGoogle Cloud -Diensten wie den folgenden implementiert:

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.

Außerdem empfehlen wir, die Datenspeicherebene von der Datenberechnungsebene zu trennen. Wenn Sie diese Ebenen trennen, sind Sie flexibler beim Ändern von Berechnungsebenen und beim 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, Datenspeicher und 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 Verarbeitung verwenden.

Umgebung bewerten

In der Bewertungsphase bestimmen Sie die Anforderungen und Abhängigkeiten für die Migration der bereitgestellten Batchdatenpipelines:

  1. Ein umfassendes Inventar Ihrer Datenpipelines erstellen.
  2. Pipelines nach ihren Attributen und Abhängigkeiten katalogisieren.
  3. Die Teams auf Google Cloudvorbereiten.
  4. Einen Test und einen Proof of Concept für 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 eine Bestandsaufnahme Ihrer Dateninfrastruktur – der verschiedenen Speicherebenen und verschiedenen Rechenebenen, die Sie für die Datenspeicherung und Batch-Datenverarbeitung verwenden.
  2. Erstellen Sie eine Liste der Datenpipelines, die migriert werden sollen.
  3. Erstellen Sie eine Liste der Datasets, die von den Datenpipelines gelesen werden und migriert werden müssen.

Beim Erstellen eines Inventars Ihrer Datenplattform 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 ihre eigene Strategie und Methode für die Migration. Cloud Storage bietet beispielsweise Datenmigrationsdienste und eine Datenbank hat möglicherweise ein integriertes Migrationstool. 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. Üben und überprüfen Sie den technischen Datenübertragungsprozess für jede der beteiligten Speicherplattformen.
  • Komprimierungsebenen. Prüfen Sie für jede Berechnungsplattform 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. Für jedes Dateninfrastrukturprodukt gibt es eigene 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 die einzelnen Komponenten konfiguriert sind, da sich die Rechen-Engines bei unterschiedlicher Konfiguration unterschiedlich verhalten können. Das gilt insbesondere, wenn sich das Framework der Verarbeitungsebene 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 Ausgaben, Serialisierungen und Berechnungen führen.

    Während der Migration empfehlen wir, automatische Bereitstellungen zu verwenden, damit Versionen und Konfigurationen gleich bleiben. Wenn Sie Versionen und Konfigurationen nicht gleich halten können, sollten Sie Tests durchführen, mit denen die vom Framework berechneten Datenausgaben validiert werden.

  • 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. Bei der Migration in eine andere Region kann sich der Prozessor ändern, der für Ihre Bereitstellung verwendet wird. Daher empfehlen wir, Ihre Arbeitslasten zu analysieren 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 von den einzelnen Datenpipelines zum Lesen und Schreiben von Daten verwendet werden.
  • 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 sind auf Daten angewiesen, die von einer anderen Datenpipeline generiert werden. Wenn Sie Pipelines in Migrationssprints aufteilen, müssen Sie Datenabhängigkeiten berücksichtigen.
  • Generierte und verwendete Datasets: Ermitteln Sie für jede Datenpipeline die Datasets, die von der Pipeline verwendet werden, und die Datasets, die von der Pipeline generiert werden. So können Sie Abhängigkeiten zwischen Pipelines und zwischen anderen Systemen oder Komponenten in Ihrer Gesamtarchitektur erkennen.

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

  • Datasets. Ermitteln Sie die Datasets, 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 für den Migrationsprozess und die Migrationssprints definieren, können Sie 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 die Zeit und die Kosten aus, die für das Kopieren der Daten von der Quelle zum Ziel erforderlich sind. Bei der Berücksichtigung dieser Faktoren können Sie zwischen Ausfallzeitstrategien wählen, wie weiter unten in diesem Dokument beschrieben.
  • Datenstruktur Klassifizieren Sie jedes zu migrierende Dataset und stellen Sie fest, 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 planen und erstellen.

Daten- und Datenpipelines migrieren

In den folgenden Abschnitten werden einige Aspekte des Plans für die Migration von Daten und Batchdatenpipelines beschrieben. Es werden einige Konzepte zu den Eigenschaften von Datenpipelines definiert, die beim Erstellen des Migrationsplans wichtig sind. Außerdem werden einige Konzepte zum Testen von Daten behandelt, die Ihnen helfen können, das Vertrauen in die Datenmigration zu stärken.

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 aller Daten, die nicht migriert wurden, 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 Datasets in Sprints aufzuteilen und separat zu migrieren. Dieser Ansatz trägt dazu bei, die Risiken für jeden Migrationssprint zu verringern, 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 ist die Beschreibung der Strategie, der Abhängigkeiten und der Art der verschiedenen Datenpipelines aus der Berechnungsebene. Wenn Ihre Datenspeicherebene und Ihre Datenberechnungsebene auf demselben System basieren, empfehlen wir, die Leistung des Systems während des Kopierens der Daten zu beobachten. Das Kopieren großer Datenmengen kann in der Regel zu E/A-Overhead im System und zu Leistungseinbußen in der Berechnungsebene führen. Wenn Sie beispielsweise eine Arbeitslast ausführen, um Daten aus einem Kafka-Cluster im Batchverfahren zu extrahieren, können die zusätzlichen E/A-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 anhand von integrierten oder benutzerdefinierten Messwerten überwachen. Um das System nicht zu überlasten, empfehlen wir, einige Arbeitslasten während des Datenkopiervorgangs zu deaktivieren oder die Kopierphase zu drosseln.

Da das Kopieren von Daten die Migration zu einem langwierigen Prozess macht, empfehlen wir, dass Sie Notfallpläne für alle Eventualitäten haben, die während der Migration auftreten können. 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 Skripts, 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 ü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 Skript, das dynamisch einen Cloud Storage-Speicherort generiert, einen neuen Zielpfad erstellen. Um das erneute Kopieren von Daten zu vermeiden, sollten Sie Ihre Skripts so erstellen, dass sie fortgesetzt und idempotent sind.

Merkmale von Datenpipelines

Um einen optimalen Migrationsplan zu erstellen, müssen Sie die Eigenschaften der verschiedenen Datenpipelines kennen. Es ist wichtig, den Unterschied zwischen Batchpipelines, die Daten schreiben, und Batchpipelines, die Daten lesen, zu kennen:

  • 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 priorisieren Sie deren Migration möglichst früh im Gesamtprozess. 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 beendet 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 sich der Statusänderungen bewusst sein, während Daten kopiert werden.

Es ist auch wichtig, im Migrationsplan zwischen 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. Ihr Plan sollte daher verschiedene 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 Migrationssprint sollte Folgendes umfassen:

  • General Strategy. Beschreiben Sie die Strategie für die Migration in diesem Sprint. Häufige Strategien finden Sie unter Arbeitslasten bereitstellen.
  • Liste der Tools und Methoden zum Kopieren von Daten und Bereitstellen von Ressourcen. Geben Sie ein Tool an, mit dem Sie Daten kopieren oder Ressourcen in der Zielumgebung bereitstellen möchten. Diese Liste sollte benutzerdefinierte Skripts 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 auch eine mögliche Größenanpassung berücksichtigt.
  • 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.
    • Methode zum Kopieren: Siehe die Liste der Tools und Methoden, die weiter oben in diesem Dokument beschrieben werden.
    • 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 Arten von Tests 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, sicherzustellen, dass die Berechnungsebene wie erwartet funktioniert und bereit ist, Ihre Datenpipelines auszuführen.

  • Vergleich von Zusammenfassung oder Hashing: Um die Vollständigkeit der Daten nach dem Kopieren zu prü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. Aus Kosten- und Latenzgründen sind in BigQuery keine Abfragen möglich, mit denen Daten aus verschiedenen Regionen zusammengeführt werden. Stattdessen muss bei der Vergleichsmethode jedes Dataset zusammengefasst und die Ergebnisse verglichen werden. Je nach Struktur des Datasets kann sich die Methode zum Zusammenfassen unterscheiden. Für eine BigQuery-Tabelle kann beispielsweise eine Aggregationsabfrage verwendet werden, für eine Reihe von Dateien in Cloud Storage kann eine Spark-Pipeline verwendet werden, um einen Hash jeder Datei zu berechnen und die Hashes dann 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äftlichen Anwendungsfällen wie der Datenanalyse fortfahren, kann es sinnvoll sein, Canary-Flow-Jobs auszuführen, um sicherzustellen, dass die Eingabedaten eine Reihe von Voraussetzungen erfüllen. Sie können Canary-Flows als benutzerdefinierte Datenpipelines oder als Flows in einem DAG basierend auf Cloud Composer 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 auch Canary-Flows verwenden, um Zusammenfassungen oder andere Aggregationen einer Spalte oder einer Teilmenge der Daten zu erstellen. Anschließend können Sie den Canary-Flow verwenden, um die Daten mit einem ähnlichen Digest oder einer ähnlichen Aggregation zu vergleichen, die aus der Kopie der Daten stammt.

    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. Bei Canary-Flows werden normalerweise keine neuen Daten generiert. Stattdessen schlagen sie fehl, wenn eine Reihe von Regeln in den Eingabedaten nicht erfüllt wird.

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

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

Ihre Tests sollten die Bereitstellung der Rechenebene und die kopierten Datasets überprüfen. Eine Möglichkeit hierfür ist, eine Testpipeline zu erstellen, mit der einige Aggregationen der kopierten Datasets berechnet werden können. So lässt sich prüfen, ob die Quelldatasets und die Zieldatasets ü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).

Stellen Sie sich beispielsweise ein Dataset vor, das aus durch Zeilenumbruch getrennten JSON-Dateien besteht. Die Dateien werden in einem Cloud Storage-Bucket gespeichert und als externe Tabelle in BigQuery eingebunden. 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, birgt aber auch einige Risiken, da die Dateien, die in die Zielumgebung geschrieben werden, keine Byte-Kopie 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 auf Grundlage der Stringlänge oder des Hashcodes des Strings berechnen. Für jede Zeile kann ein aggregierter Hash aus einer Kombination aller anderen Spalten berechnet werden. Damit lässt sich mit hoher Genauigkeit überprüfen, ob eine Zeile mit ihrem Ursprung ü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 Quellumgebung berechneten Ergebnisse mit den für die Zielumgebung berechneten Ergebnissen vergleichen. So können Sie sicherstellen, dass die Daten vollständig und korrekt sind.

Ein weiterer wichtiger Aspekt beim Testen der Berechnungsebene ist das Ausführen von Pipelines, die alle Arten von Verarbeitungs-Engines und Berechnungsmethoden umfassen. Das Testen der Pipeline ist bei verwalteten Rechen-Engines wie BigQuery oder Dataflow 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 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 direkt 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 jedoch einige Ausfallzeiten tolerieren 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 weiterhin funktionieren und Endsysteme mit Informationen versorgen 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 Deltakopie durch, um die Daten abzurufen, die nach dem Migrationszeitstempel in der Quellumgebung generiert wurden. Dieser Ansatz erfordert mehr Koordination und Überlegungen als andere Strategien. Daher muss Ihr Migrationsplan enthalten, wie Sie die Aktualisierungs- und Löschvorgänge für die Quelldaten verarbeiten.
  • 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 Phase des Deltakopierens vermieden, die zum Auffüllen von Daten erforderlich ist, wenn Sie die Strategien „Vollständig aktiv“ oder „Schreibgeschützt“ verwenden. Damit Datenpipelines identische Ergebnisse liefern, sind bei einer Strategie mit doppelten Schreibvorgängen jedoch mehr Tests vor der Migration erforderlich. Wenn Sie keine Vorabtests durchführen, treten Probleme beim Konsolidieren eines Split-Brain-Szenarios auf. Die Strategie des doppelten Schreibens birgt auch potenzielle Kosten für die Ausführung derselben Arbeitslasten zweimal in verschiedenen Regionen. 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 Vollständigkeit der Daten und die Datenpipelines auf Gültigkeit prüfen. 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äftliche Anwendungsfä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 Quellumgebung als auch in der Zielumgebung ausführen. Diese Art von Test funktioniert nur, wenn die Datenpipeline deterministisch ist und Sie dafür sorgen können, dass die Eingabe für beide Umgebungen identisch ist.

Sie können bestätigen, dass die Daten vollständig sind, wenn sie eine Reihe vordefinierter Kriterien erfüllen, bei denen die Daten in der Quellumgebung mit den Daten in der Zielumgebung übereinstimmen (oder ähnlich genug sind). Je nach der Strategie, die Sie im vorherigen Abschnitt verwendet haben, stimmen die Daten möglicherweise nicht genau überein. Daher müssen Sie Kriterien für die Datenvollständigkeit für Ihren Anwendungsfall vordefinieren. Bei Zeitreihendaten könnten Sie die Daten beispielsweise als vollständig betrachten, wenn der aktuellste Datensatz nicht mehr als fünf Minuten hinter dem aktuellen Zeitstempel liegt.

Umstellung

Nachdem Sie die Daten und Datenpipelines in der Zielumgebung überprüft und getestet haben, können Sie mit der Umstellungsphase beginnen. Mit dem Beginn dieser Phase 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 Clients die Konfiguration für den zu verwendenden Bucket ändern. Cloud Storage-Bucket-Namen sind global eindeutig. Der Cloud Storage-Bucket in Ihrer Zielumgebung unterscheidet sich also von dem in der Quellumgebung.

Während der Umstellungsphase sollten Sie die Arbeitslasten der Quellumgebung außer Betrieb nehmen und die Zeitplanung aufheben. Wir empfehlen, die Daten der Quellumgebung für einige Zeit aufzubewahren, falls Sie ein Rollback durchführen müssen.

Die Testphase vor der Migration ist nicht so umfassend wie ein Produktionslauf einer Datenpipeline. Nach Abschluss der Umstellung und Inbetriebnahme des Zielsystems müssen Sie daher die Messwerte, Laufzeiten und semantischen Ausgaben Ihrer Datenpipelines im Blick behalten. 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.

Google Cloud Daten und Rechenressourcen für die Migration zwischen Regionen vorbereiten

In diesem Abschnitt finden Sie einen Überblick über die Daten- und Computeressourcen aufGoogle Cloud sowie über die Designprinzipien zur Vorbereitung auf eine Migration zwischen Regionen.

BigQuery

Da BigQuery ein serverloses SQL-Data Warehouse ist, müssen Sie die Berechnungsebene nicht bereitstellen. Wenn einige Ihrer BigQuery-Clients Regionen für die Verarbeitung angeben, müssen Sie diese Clients anpassen. Andernfalls 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. Nachdem die Daten verschoben wurden, müssen Sie die externen Tabellen am neuen Zielort 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, der Sie bei der Migration Ihrer Daten unterstützen kann.

Dataflow (Batch)

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

Dataproc

Dataproc ist eine verwaltete Apache Hadoop-Umgebung, in der alle Arbeitslasten ausgeführt werden können, die mit dem Apache Hadoop-Framework kompatibel sind. Sie ist mit Frameworks wie Apache Spark, Apache Flink und Apache Hive kompatibel.

Sie können Dataproc auf folgende Arten verwenden, die sich darauf auswirken, wie Sie Ihre Dataproc-Umgebung regionsübergreifend 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 zerstört wird. Wenn Ihre Konfiguration die folgenden Kriterien erfüllt, ist diese Art der Nutzung einfacher zu migrieren als andere Arten der Nutzung:
    • Ein- und Ausgaben für Ihre Jobs sind nicht im Quellcode fest codiert. Stattdessen erhalten Ihre Jobs Ein- 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 im Cluster ausgeführt werden. Es ist also nicht sinnvoll, Cluster wie im kurzlebigen Modell abzubauen und einzurichten. Da Daten und Rechenleistung getrennt sind, ähnelt die Migration der Migration des kurzlebigen 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 eines ohne das andere migrieren, besteht ein hohes Risiko, dass Inkonsistenzen entstehen. In diesem Fall sollten Sie Daten und Status vor der Migration aus dem Cluster verschieben, um die beiden 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 Orchestrierung und Planung von Abläufen. Google CloudDAGs, Konfigurationen und Logs 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, eine Infrastruktur-als-Code-Methode anzuwenden, um die Umgebung vollständig automatisiert neu zu erstellen.

Cloud Composer verwaltet keine Daten, sondern aktiviert andere Frameworks und Plattformen für die Datenverarbeitung. Die Migration von Cloud Composer kann daher vollständig von den Daten isoliert werden. Cloud Composer verarbeitet auch keine Daten, sodass sich Ihre Bereitstellung nicht in derselben Region wie die Daten befinden muss. Sie können also eine Cloud Composer-Bereitstellung in der Zielumgebung erstellen und Pipelines weiterhin in der Quellumgebung ausführen. In einigen Fällen kann dies nützlich sein, um verschiedene Pipelines in verschiedenen Regionen auszuführen, 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. Wie Cloud Composer verwaltet Cloud Data Fusion keine Daten selbst, sondern aktiviert andere Datenverarbeitungsframeworks und -plattformen. Ihre Cloud Data Fusion-Pipelines sollten aus der Quellumgebung exportiert und auf eine der folgenden Arten in die Zielumgebung importiert werden:

Je nachdem, wie viele Abläufe Sie migrieren müssen, bevorzugen Sie möglicherweise die eine oder die andere Methode. Die CDAP API zum Erstellen eines Migrationsskripts zu verwenden, kann schwierig sein und erfordert mehr Software-Engineering-Kenntnisse. Wenn Sie jedoch viele Abläufe haben oder sich die Abläufe 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