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

Last reviewed 2023-12-08 UTC

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

  • Verschieben von Daten und Datenpipelines vorbereiten.
  • Richten Sie Prüfungen während der Migrationsphasen ein.
  • Erstellen Sie eine flexible Migrationsstrategie, indem Sie Datenspeicher und Datenberechnung trennen.

Die Anleitung in dieser Reihe ist auch dann hilfreich, wenn Sie keine regionsübergreifende Migration oder im Voraus eine Erweiterung auf mehrere Regionen geplant haben. In diesem Fall fallen möglicherweise zusätzliche Kosten für die Vorbereitung Ihrer Infrastruktur, Arbeitslasten und Daten für die regionsübergreifende Migration und für die Erweiterung auf mehrere Regionen an.

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 Cloud migrieren: 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 normalerweise in Google Cloud aufgebaut sind. Datenplattformen als allgemeines Konzept können in zwei Abschnitte unterteilt werden:

  • Auf 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 Speicherebene gibt es viele mögliche Implementierungen. Einige Datenspeichertools übernehmen auch die Datenberechnung. Die Rolle der Datenberechnungsebene in der Plattform besteht darin, Daten aus der Speicherebene zu laden, die Daten zu verarbeiten und die Ergebnisse anschließend in einem Zielsystem zu speichern. Das Zielsystem kann die Quellspeicherebene sein.

Einige Datenplattformen verwenden mehrere Speichersysteme für ihre Datenspeicherebene und mehrere Datenberechnungssysteme für ihre Datenverarbeitungsebene. In den meisten Fällen sind die Datenspeicherebene und die Datenberechnungsebene getrennt. Sie haben beispielsweise Ihre Datenspeicherebene mit den folgenden Google Cloud-Diensten implementiert:

Möglicherweise haben Sie die Datenberechnungsebene mit anderen Google 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 Ihrer Datenberechnungsebene getrennt zu halten. Wenn Sie diese Ebenen getrennt halten, können Sie Berechnungsebenen und Daten flexibler ändern. Durch eine Trennung der Ebenen wird auch die Ressourcennutzung reduziert, da die Berechnungsebene nicht ständig ausgeführt werden muss. Daher empfehlen wir Ihnen, Ihre Datenspeicherung und Datenberechnung auf separaten Plattformen in derselben Zone und Region bereitzustellen. Beispielsweise können Sie 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. Ein umfassendes Inventar Ihrer Datenpipelines erstellen.
  2. Pipelines nach ihren Attributen und Abhängigkeiten katalogisieren.
  3. Die Teams auf Google Cloud vorbereiten.
  4. Einen Test und einen Proof of Concept für Google Cloud erstellen.
  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 Zu Google Cloud migrieren: Arbeitslasten bewerten und erkennen. Die folgenden Abschnitte basieren auf Informationen in jenem Dokument.

Inventar erstellen

Zum Durchführen einer Migration müssen Sie die Datenplattformumgebung verstehen, in der Ihre Datenpipelines bereitgestellt werden:

  1. Erstellen Sie ein Inventar Ihrer Dateninfrastruktur – die verschiedenen Speicherebenen und verschiedenen Berechnungsebenen, die Sie für die Datenspeicherung und Batchdatenverarbeitung verwenden.
  2. Erstellen Sie ein Inventar der Datenpipelines, die für die Migration geplant sind.
  3. Erstellen Sie ein Inventar der Datasets, die von den Datenpipelines gelesen werden und migriert werden sollen.

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 ihre eigene Strategie und Methode zur Durchführung der Migration. 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 für Sie verfügbar ist oder dass Sie einen kompatiblen Ersatz haben. Praxis und überprüfen Sie den technischen Datenübertragungsprozess für jede der beteiligten Speicherplattformen.
  • Komprimierungsebenen. Überprüfen Sie für jede Berechnungsplattform den Bereitstellungsplan und prüfen Sie alle Konfigurationsänderungen, die Sie möglicherweise 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 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 Computing-Engines bei unterschiedlicher Konfiguration unterschiedlich verhalten können, 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 der Konfigurationsänderung kann zu Änderungen an Ausgaben, Serialisierungen und Berechnungen führen.

    Während der Migration empfehlen wir die Verwendung automatisierter Bereitstellungen, damit Versionen und Konfigurationen gleich bleiben. Wenn es nicht möglich ist, Versionen und Konfigurationen gleich zu halten, sollten Sie Tests durchführen, die die vom Framework berechneten Datenausgaben 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, den Ihre Bereitstellung verwendet. Daher empfehlen wir, ein Profil für Ihre Arbeitslasten zu erstellen und zu optimieren, nachdem Sie die migrierte Infrastruktur für die 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 beim Aufteilen von Pipelines in Migrationssprints die Datenabhängigkeiten.
  • Generierte und verwendete Datasets. Identifizieren Sie für jede Datenpipeline, welche Datasets die Pipeline nutzt und welche Datasets sie generiert. Auf diese Weise können Sie Abhängigkeiten zwischen Pipelines und zwischen anderen Systemen oder Komponenten in Ihrer gesamten Architektur identifizieren.

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

  • Datasets. Ermitteln Sie die Datasets, die in die Zielumgebung migriert werden sollen. 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 Risiken der Migration reduzieren.
  • Datengrößen. Wenn Sie Dateien vor der Übertragung komprimieren möchten, notieren Sie die Dateigröße vor und nach der Komprimierung. Die Größe der Daten wirkt sich auf den Zeitaufwand und die Kosten aus, die zum Kopieren der Daten von der Quelle an das 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 achten Sie darauf, dass Sie nachvollziehen können, ob die Daten strukturiert, semistrukturiert 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 ab, die unter Migration zu Google Cloud: Arbeitslasten bewerten und erkennen beschrieben sind.

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 Migrate to Google Cloud: Planen und erstellen Sie Ihre Grundlage.

Daten- und Datenpipelines migrieren

In den folgenden Abschnitten werden einige Aspekte des Plans für die 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 Datentestkonzepte erläutert, mit denen Sie das Vertrauen in die Datenmigration erhöhen können.

Migrationsplan

Geben Sie in Ihrem Migrationsplan Zeit für die Datenübertragung an. In Ihrem Plan sollten die Netzwerklatenz, die Zeit zum Testen der Vollständigkeit der Daten und die Abruf von Daten, die nicht migriert werden konnten, sowie Netzwerkkosten berücksichtigt werden. 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 diese separat zu migrieren. Dieser Ansatz hilft, die Risiken für jeden Migrationssprint 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 ist die Beschreibung der Strategie, von Abhängigkeiten und der Art der verschiedenen Datenpipelines aus der Berechnungsebene. Wenn die Datenspeicher- und Datenberechnungsebene auf demselben System basieren, empfehlen wir, die Leistung des Systems zu überwachen, während Daten kopiert werden. In der Regel kann das Kopieren großer Datenmengen zu einem E/A-Overhead auf dem System führen und die Leistung in der Berechnungsebene beeinträchtigen. Wenn Sie beispielsweise eine Arbeitslast ausführen, um Daten aus einem Kafka-Cluster im Batch zu extrahieren, können die zusätzlichen E/A-Vorgänge zum Lesen großer Datenmengen zu einer Beeinträchtigung der Leistung aller aktiven Datenpipelines führen, werden noch in der Quell-Umgebung ausgeführt. In einem solchen Szenario sollten Sie die Leistung des Systems mithilfe von integrierten oder benutzerdefinierten Messwerten überwachen. Damit das System nicht überlastet wird, empfehlen wir Ihnen, einige Arbeitslasten während des Datenkopiervorgangs außer Betrieb zu nehmen oder die Kopierphase zu drosseln.

Da das Kopieren von Daten die Migration zu einem lang andauernden Prozess macht, empfehlen wir Ihnen, Notfallpläne zu haben, um alle Fehler zu beheben, die während der Migration möglicherweise fehlschlagen. 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 zu unterscheiden, die Sie kopieren. Ein Rollback der Datenverschiebung bedeutet, dass Sie Daten neu kopieren und bereits kopierte Daten überschreiben oder löschen müssen. 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 möglicherweise Daten neu kopieren, wenn Sie einen neuen Zielpfad in einem Skript erstellen, das einen Cloud Storage-Speicherort dynamisch generiert. Erstellen Sie Ihre Skripts so, dass die Wiederaufnahme und Idempotenz ermöglicht wird, um das erneute Kopieren von Daten zu vermeiden.

Eigenschaften der Datenpipeline

Für die Erstellung eines optimalen Migrationsplans müssen Sie die Eigenschaften verschiedener Datenpipelines verstehen. Beachten Sie, dass sich Batchpipelines, die Daten schreiben, von Batchpipelines, die Daten lesen, unterscheiden:

  • 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 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 Statusänderungen beim Kopieren von Daten berücksichtigen.

Außerdem ist es im Migrationsplan wichtig, 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. Daher sollte Ihr Plan unterschiedliche Strategien für die Migration der einzelnen Systeme enthalten. Achten Sie darauf, dass Sie die Abhängigkeiten zwischen den Systemen angeben und angeben, 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. Gängige Strategien finden Sie unter Arbeitslasten bereitstellen.
  • Liste der Tools und Methoden für das Kopieren 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 Dateninfrastrukturkomponenten wie Cloud Storage-Buckets, BigQuery-Datasets und Dataproc-Cluster enthalten. 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 mögliche Größenanpassungen enthält.
  • 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.
    • Zu kopierende Methoden: Sehen Sie sich die Liste der Tools und Methoden an, 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 dabei helfen, die Integrität und Vollständigkeit der Daten zu gewährleisten. Sie können auch dafür sorgen, dass die Rechenebene wie erwartet funktioniert und für die Ausführung Ihrer Datenpipelines bereit ist.

  • Zusammenfassung oder Hash-Vergleich: Um die Vollständigkeit der Daten nach dem Kopieren von Daten 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 in einer Abfrage nicht zusammenführen, um festzustellen, ob alle Daten vorhanden sind, da sich die Tabellen in verschiedenen Regionen befinden. Aufgrund der Kosten und der Latenz lässt BigQuery nicht zu, dass Abfragen Daten über Regionen hinweg zusammenführen. Stattdessen muss die Vergleichsmethode jedes Dataset zusammenfassen und die Ergebnisse vergleichen. Je nach Dataset-Struktur kann die Methode zur Zusammenfassung unterschiedlich sein. Beispielsweise kann eine BigQuery-Tabelle eine Aggregationsabfrage verwenden, aber eine Reihe von Dateien in Cloud Storage könnte eine Spark-Pipeline verwenden, um einen Hash jeder Datei zu berechnen und die Hashes dann zusammenzufassen.

  • 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 Datenanalysen 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-Abläufe als benutzerdefinierte Datenpipelines oder als Abläufe in einem DAG auf Basis von 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-Abläufe verwenden, um Digests oder andere Aggregationen einer Spalte oder einer Teilmenge der Daten zu erstellen. Anschließend können Sie den Canary-Ablauf verwenden, um die Daten mit einem ähnlichen Digest oder einer ähnlichen Aggregation zu vergleichen, der 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. Canary-Abläufe generieren normalerweise keine neuen Daten, sondern schlagen fehl, wenn eine Reihe von Regeln in den Eingabedaten nicht erfüllt ist.

  • Testumgebung: Nachdem Sie Ihren Migrationsplan abgeschlossen 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. Mit diesen Tests können Sie Probleme mit dem Migrationsplan ermitteln und prüfen, ob die Daten erfolgreich migriert werden können. Die Tests sollten sowohl Funktions- als auch nicht funktionale Tests umfassen. Funktionstests prüfen, ob die Daten ordnungsgemäß migriert wurden. Mit nicht funktionalen Tests wird geprüft, ob die Migration die Leistungs-, Sicherheits- und andere nicht funktionale Anforderungen erfüllt. Jeder Migrationsschritt in Ihrem Plan sollte ein Validierungskriterien enthalten, das angibt, wann der Schritt als abgeschlossen betrachtet werden kann.

Sie können das Data Validation Tool (DVT) verwenden, um die Datenvalidierung zu erleichtern. Das Tool führt mehrstufige Datenvalidierungsfunktionen von der Tabellen- bis zur Zeilenebene aus und hilft Ihnen, die Ergebnisse Ihrer Quell- und Zielsysteme zu vergleichen.

Die Tests sollten die Bereitstellung der Berechnungsebene und die kopierten Datasets testen. Ein Ansatz hierfür besteht darin, eine Testpipeline zu erstellen, die einige Aggregationen der kopierten Datasets berechnen und dafür sorgen kann, dass die Quell-Datasets und die Ziel-Datasets ü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).

Betrachten Sie beispielsweise ein Dataset, das 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 verschobenen Daten zu reduzieren, können Sie eine Avro-Komprimierung im Rahmen der Migration durchführen, bevor Sie Dateien in die Zielumgebung kopieren. Diese Konvertierung hat viele Vorteile, birgt jedoch auch einige Risiken, da die Dateien, die in die Zielumgebung geschrieben werden, keine Bytekopie-Darstellung 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 Hashcode dieses Strings berechnen. Für jede Zeile können Sie einen aggregierten Hash aus einer Kombination aller anderen Spalten berechnen. Dadurch lässt sich mit hoher Genauigkeit überprüfen, ob eine Zeile mit ihrem Ursprung identisch ist. 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 Ergebnisse vergleichen. Auf diese Weise können Sie dafür sorgen, dass die Daten vollständig und genau sind.

Ein weiterer wichtiger Aspekt beim Testen der Rechenebene ist die Ausführung von Pipelines, die alle Arten von Verarbeitungs-Engines und Berechnungsmethoden enthalten. Das Testen der Pipeline ist für verwaltete Computing-Engines wie BigQuery oder Dataflow weniger wichtig. Es ist jedoch wichtig, die Pipeline für nicht verwaltete Rechen-Engines 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 ordnungsgemäßen Tests geprüft haben, können Sie Daten migrieren. Bei der Migration von Daten können Sie für verschiedene Arbeitslasten verschiedene Strategien verwenden. Die folgenden Beispiele zeigen 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, aber SLOs und SLAs einer gewissen Ausfallzeit standhalten 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 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 verwenden, 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-Phase durch, 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 angeben, wie Sie die Aktualisierungs- und Löschvorgänge für die Quelldaten behandeln.
  • Doppelte Schreibvorgänge: Die Datenpipelines können sowohl in der Quell- als auch in der Zielumgebung ausgeführt werden, während Daten kopiert werden. Diese Strategie verhindert die Deltakopie-Phase, die für einen Daten-Backfill erforderlich ist, wenn Sie die vollständig aktiven oder schreibgeschützten Strategien verwenden. Damit Datenpipelines jedoch identische Ergebnisse liefern, erfordert eine Strategie mit doppelten Schreibvorgängen vor der Migration weitere Tests. Wenn Sie keine erweiterten Tests durchführen, treten Probleme auf, wenn Sie ein Split-Brain-Szenario konsolidieren. Die Strategie mit doppelten Schreibvorgängen führt auch zu potenziellen Kosten für die zweimalige Ausführung derselben Arbeitslasten 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 testen und die Datenpipelines auf Gültigkeit testen. Wenn Sie die Migration in Sprints abschließen, müssen Sie diese Tests nach jedem Sprint durchführen. Die Tests, die Sie in dieser Phase durchführen, ähneln Integrationstests: Sie testen die Gültigkeit einer Datenpipeline, die geschäftliche Anwendungsfälle ausführt, mit vollständigen produktionstauglichen Daten als Eingabe. Anschließend prüfen Sie die Ausgabe für Gültigkeit. Sie können die Ausgabe des Integrationstests mit der Ausgabe der Quellumgebung vergleichen. Führen Sie dazu dieselbe Datenpipeline sowohl in der Quellumgebung als auch in der Zielumgebung aus. Diese Art von Test funktioniert nur, wenn die Datenpipeline deterministisch ist und Sie sicherstellen können, dass die Eingabe in 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 gleich den Daten in der Zielumgebung sind oder ähnlich genug sind. Je nach Strategie, die Sie im vorherigen Abschnitt verwendet haben, stimmen die Daten möglicherweise nicht eins zu eins überein. Daher müssen Sie Kriterien vordefiniert, um die Vollständigkeit der Daten für Ihren Anwendungsfall zu beschreiben. Bei Zeitachsendaten sollten 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 geprüft und getestet haben, können Sie mit der Umstellungsphase beginnen. Der Beginn dieser Phase bedeutet, dass Clients möglicherweise ihre Konfiguration ändern müssen, 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 ändern, für den der Bucket verwendet werden soll. Da Cloud Storage-Bucket-Namen global eindeutig sind, unterscheidet sich der Cloud Storage-Bucket der Zielumgebung von 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 für einige Zeit beizubehalten, falls Sie ein Rollback durchführen müssen.

Die Testphase vor der Migration ist nicht so abgeschlossen wie die Produktionsausführung einer Datenpipeline. Nachdem die Umstellung abgeschlossen ist und das Zielsystem betriebsbereit ist, müssen Sie die Messwerte, Laufzeiten und semantischen Ausgaben Ihrer Datenpipelines überwachen. Durch dieses Monitoring können Sie Fehler erkennen, die in Ihrer Testphase möglicherweise übersehen wurden, und die Migration gewährleisten.

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 eine regionsübergreifende Migration vorbereiten

Dieser Abschnitt bietet einen Überblick über die Daten- und Rechenressourcen in Google Cloud und die Designprinzipien für die Vorbereitung einer regionenübergreifenden Migration.

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 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 Ziel neu erstellen. Weitere Informationen zum Migrieren externer Tabellen finden Sie unter Einführung in externe Tabellen.

Cloud Storage

Cloud Storage bietet einen Storage Transfer Service, der Sie bei der Migration Ihrer Daten unterstützt.

Dataflow (Batch)

Dataflow ist eine von Google verwaltete Datenverarbeitungs-Engine. Sie sollten alle Ein- und Ausgaben als Parameter in Ihren Job einfügen, um die Dataflow-Migration zu vereinfachen und dafür zu sorgen, dass Ihre Jobs problemlos in jeder Region bereitgestellt werden können. Anstatt Speicherorte für Eingabe- und Ausgabedaten in Ihren Quellcode zu schreiben, empfehlen wir Ihnen, 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. Es ist mit Frameworks wie Apache Spark, Apache Flink und Apache Hive kompatibel.

Sie können Dataproc auf folgende Arten verwenden, die Einfluss darauf haben, 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. Dies bedeutet, dass auch die HDFS-Ebene oder ein anderer Zustand 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:
    • Ein- und Ausgaben für Ihre Jobs sind im Quellcode nicht hartcodiert. 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 Ihre Umgebung verwendet.
  • 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 Computing sind getrennt, da die Daten außerhalb des Clusters in Google 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. Daher ist es nicht sinnvoll, Cluster wie im sitzungsspezifischen Modell zu löschen und einzurichten. Da Daten und Computing 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 Verwendung erschwert die Migration, da Daten und Computing nicht getrennt sind. Wenn Sie eines ohne das andere migrieren, besteht ein hohes Risiko von Inkonsistenzen. In diesem Szenario sollten Sie Daten und Zustände vor der Migration aus dem Cluster heraus verschieben, um beide 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 sowie 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 von Google Cloud zur Orchestrierung und Planung von Abläufen. DAGs, Konfigurationen und Logs werden in einem Cloud Storage-Bucket verwaltet, der mit Ihrer Cloud Composer-Bereitstellung migriert werden soll. Um den Status Ihrer Cloud Composer-Bereitstellung zu migrieren, können Sie Umgebungs-Snapshots speichern und laden.

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

Cloud Composer verwaltet keine Daten, aktiviert jedoch andere Datenverarbeitungs-Frameworks und -Plattformen. Daher kann die Migration von Cloud Composer 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. Daher können Sie eine Cloud Composer-Bereitstellung in der Zielumgebung erstellen und weiterhin Pipelines in der Quellumgebung ausführen. In einigen Fällen kann dies hilfreich sein, um 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 mit einem visuellen Editor 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 Datenverarbeitungs-Frameworks und -Plattformen. Ihre Cloud Data Fusion-Pipelines sollten aus der Quellumgebung exportiert und auf eine der folgenden Arten in die Zielumgebung importiert werden:

Je nach Anzahl der zu migrierenden Abläufe bevorzugen Sie möglicherweise eine bestimmte Methode gegenüber der anderen. Die CDAP API zum Erstellen eines Migrationsskripts kann schwierig sein und erfordert mehr Kenntnisse im Softwareengineering. Wenn Sie jedoch viele Abläufe haben oder sich die Abläufe relativ häufig ändern, ist ein automatisierter Prozess möglicherweise der beste Ansatz.

Weitere Informationen

Beitragende

Autor: Eyal Ben Ivri | Cloud Solutions Architect

Weiterer Beitragender: Marco Ferrari | Cloud Solutions Architect