Über Google Cloud-Regionen hinweg migrieren: Daten- und Batcharbeitslasten 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 eine Region-zu-Region-Migration zu minimieren. Dieses Dokument ist Teil einer Reihe, in der Sie die Auswirkungen der Erweiterung Ihrer Datenplattform auf eine andere Region verstehen. Sie erhalten Informationen zu folgenden Themen:

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

Die Anleitung in dieser Reihe ist auch nützlich, wenn Sie keine Migration in mehrere Regionen oder eine 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 für 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 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 Bereiche einer modernen Datenplattform beschrieben und wie sie in der Regel in Google Cloud erstellt werden. Datenplattformen im Allgemeinen können in zwei Abschnitte unterteilt werden:

  • Auf der Datenspeicherebene werden die 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 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 werden die Datenspeicherebene und die Datenberechnungsebene getrennt. Sie haben beispielsweise die Datenspeicherebene mithilfe der folgenden Google Cloud-Dienste implementiert:

Sie haben die Datenberechnungsebene eventuell 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 wird empfohlen, die Datenspeicherebene von der Datenrechenebene zu trennen. Wenn Sie diese Ebenen getrennt halten, verbessern Sie die Flexibilität, Rechenebenen zu ändern und Daten zu migrieren. Wenn Sie die Ebenen getrennt halten, reduzieren Sie auch Ihre Ressourcennutzung, da Sie die Berechnungsebene nicht ständig ausführen müssen. Daher empfehlen wir, dass Sie Ihre Datenspeicherung und Datenberechnung auf separaten Plattformen in derselben Zone und Region bereitstellen. Sie können beispielsweise Ihren Datenspeicher von HDFS nach Cloud Storage verschieben und einen Dataproc-Cluster zur 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. 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 – der verschiedenen Speicherebenen und verschiedenen Berechnungsebenen, die Sie für die Datenspeicherung und Batchverarbeitung von Daten verwenden.
  2. Erstellen Sie ein Inventar der Datenpipelines, die migriert werden sollen.
  3. Erstellen Sie ein Inventar der Datasets, die von den Datenpipelines gelesen werden und die migriert werden müssen.

Wenn Sie ein Inventar Ihrer Datenplattform erstellen möchten, 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 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. Übung und Überprüfung des technischen Datenübertragungsprozesses für jede beteiligte Speicherplattform.
  • Komprimierungsebenen. Prüfen Sie für jede Computing-Plattform den Bereitstellungsplan und prüfen Sie 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) in der 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 Rechenmodule anders verhalten, wenn sie unterschiedlich konfiguriert sind, 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 Änderungen an Ausgaben, Serialisierungen und Berechnungen verursachen.

    Während der Migration empfehlen wir die Verwendung automatisierter Bereitstellungen, damit Versionen und Konfigurationen gleich bleiben. Wenn Sie Versionen und Konfigurationen nicht identisch halten können, benötigen Sie Tests, 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. Die Migration in eine andere Region kann zu einer Änderung des Prozessors führen, der von Ihrer Bereitstellung verwendet wird. Daher empfehlen wir Ihnen, ein Profil für Ihre Arbeitslasten zu erstellen und diese zu optimieren, nachdem Sie die migrierte Infrastruktur für die Produktion bereitgestellt haben. Bei einer vollständig verwalteten oder serverlosen Komponente (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 Achten Sie darauf, die Quellen und Senken zu berücksichtigen, die jede Datenpipeline zum Lesen und Schreiben von Daten verwendet.
  • Service Level Agreements (SLAs) und Service Level Objectives (SLOs). SLAs und SLOs für Batchdaten werden normalerweise bis zum Abschluss gemessen. Sie können jedoch auch auf andere Weise gemessen werden, z. B. in Bezug auf die verwendete 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. Achten Sie beim Aufteilen von Pipelines in Migrationssprints auf Datenabhängigkeiten.
  • Generierte und verbrauchte Datasets. Identifizieren Sie für jede Datenpipeline die von der Pipeline genutzten Datasets und die generierten Datasets. Auf diese Weise können Sie Abhängigkeiten zwischen Pipelines und zwischen anderen Systemen oder Komponenten in Ihrer Gesamtarchitektur ermitteln.

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

  • Datasets. Identifizieren 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 Bereich für den Migrationsprozess und die Migrationssprints definieren, können Sie die Risiken in 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 der Daten wirkt sich auf die Zeit und die Kosten aus, die zum 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 machen Sie sich klar, 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 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 Zu Google Cloud migrieren: Grundlage erstellen.

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 den Datentest beschrieben, mit denen Sie die Zuverlässigkeit der Datenmigration erhöhen können.

Migrationsplan

Sie müssen Zeit in den Migrationsplan aufnehmen, um die Datenübertragung abzuschließen. Ihr Plan sollte die Netzwerklatenz, die Zeit zum Testen der Vollständigkeit der Daten und das Abrufen aller Daten, die nicht migriert werden konnten, 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 zu unterteilen und sie separat zu migrieren. Dieser Ansatz reduziert die Risiken für jeden Migrationssprint und sorgt für Verbesserungen in jedem Sprint. Damit Sie Ihre Migrationsstrategie verbessern und Probleme frühzeitig erkennen können, sollten Sie kleinere, nicht kritische Arbeitslasten 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 Berechnungsschicht. Wenn Ihre Datenspeicherebene und Datenberechnungsebene auf demselben System basieren, empfehlen wir, die Leistung des Systems während des Kopierens der Daten zu überwachen. In der Regel kann das Kopieren großer Datenmengen zu E/A-Overhead im System führen und die Leistung auf der Berechnungsebene beeinträchtigen. Wenn Sie beispielsweise eine Arbeitslast zum Extrahieren von Daten aus einem Kafka-Cluster im Batch ausführen, kann der zusätzliche E/A-Vorgang zum Lesen großer Datenmengen zu einer Beeinträchtigung der Leistung aller aktiven Datenpipelines führen, die weiterhin in der Quellumgebung ausgeführt werden. In dieser Art von Szenario sollten Sie die Leistung des Systems mithilfe integrierter oder benutzerdefinierter Messwerte überwachen. Damit Sie das System nicht überlasten, sollten Sie planen, 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 erstellen, um alles zu beheben, was während der Migration fehlerhaft sein könnte. 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 zu unterscheiden, die Sie für die Migration verwenden, und den Daten, die Sie kopieren. Bei einem Rollback der Datenverschiebung müssen Sie die Daten neu kopieren und die bereits kopierten 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 neu kopieren, wenn Sie einen neuen Zielpfad in einem Skript erstellen, das einen Cloud Storage-Speicherort dynamisch generiert. Erstellen Sie Ihre Skripts so, dass eine Wiederaufnahme und Idempotenz möglich ist, um ein erneutes Kopieren von Daten zu vermeiden.

Merkmale der Datenpipeline

Zum Erstellen eines optimalen Migrationsplans müssen Sie die Eigenschaften verschiedener Datenpipelines verstehen. Beachten Sie, dass sich Batchpipelines, die Daten schreiben, von Batchpipelines unterscheiden, 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, deren 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, haben möglicherweise unterschiedliche Anforderungen an die Datenaktualität. 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 berücksichtigen, während Daten kopiert werden.

Außerdem ist es im Migrationsplan wichtig, 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 Streaming). Daher sollte Ihr Plan verschiedene Strategien zur Migration der einzelnen Systeme enthalten. Achten Sie darauf, dass Sie die Abhängigkeiten zwischen den Systemen angeben und wie Sie die Ausfallzeiten für jedes System in jeder Phase der Migration reduzieren.

Ein typischer Plan für einen Migrationssprint sollte Folgendes enthalten:

  • General Strategy. Beschreiben Sie die Strategie für die Migration in diesem Sprint. Allgemeine Strategien finden Sie unter Arbeitslasten bereitstellen.
  • Liste der Tools und Methoden für das Kopieren von Ressourcen und das Bereitstellen von Ressourcen Geben Sie alle Tools an, die Sie zum Kopieren von Daten oder zum Bereitstellen von Ressourcen in die Zielumgebung verwenden möchten. Diese Liste sollte benutzerdefinierte Skripts enthalten, mit denen Cloud Storage-Assets, Standardtools wie gsutil und Google Cloud-Tools wie Migration Services kopiert werden.
  • 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 frühe Migrationssprints die Bereitstellung eines Clusters mit hoher Größe (z. B. ein Dataproc-Cluster) mit einer kleineren Kapazität, während spätere Sprints die Größenanpassung für neue Arbeitslasten umfassen. Achten Sie darauf, dass Ihr Plan eine potenzielle Größenanpassung umfasst.
  • Liste der zu kopierenden Datasets. Geben Sie für jedes Dataset die folgenden Informationen an:
    • Reihenfolge beim Kopieren (falls zutreffend): Bei den 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: Erstellen Sie Diagrammstatistiken wie 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 Methode: Informationen dazu finden Sie in der Liste der Tools und Methoden, die weiter oben in diesem Dokument beschrieben wurde.
    • Überprüfungstests: Geben Sie explizit die Tests an, die Sie abschließen möchten, um zu prüfen, ob die Daten vollständig kopiert wurden.
    • Notfallplan: Beschreiben Sie, was zu tun ist, wenn Verifizierungstests 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.

Testen

In diesem Abschnitt werden einige typische Testtypen beschrieben, die Sie planen können. Mit den Tests können Sie die Integrität und Vollständigkeit der Daten gewährleisten. Sie können auch prüfen, ob die Rechenebene wie erwartet funktioniert und Ihre Datenpipelines ausführen kann.

  • Zusammenfassung oder Hashing-Vergleich: Zur Validierung der Vollständigkeit von Daten nach dem Kopieren von Daten 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 unterschiedlichen Regionen befinden. Aufgrund der Kosten und der Latenz erlaubt BigQuery keine Abfragen regionenübergreifend. Stattdessen muss die Vergleichsmethode jedes Dataset zusammenfassen und die Ergebnisse vergleichen. Je nach Dataset-Struktur kann die Methode für die Zusammenfassung unterschiedlich sein. BigQuery-Tabellen können beispielsweise eine Aggregationsabfrage verwenden, aber eine Reihe von Dateien in Cloud Storage kann eine Spark-Pipeline verwenden, um einen Hash jeder Datei zu berechnen und dann die Hashes zusammenzufassen.

  • Canary-Flows: Canary-Flows aktivieren Jobs, die zur Validierung der Datenintegrität und -vollständigkeit erstellt werden. Bevor Sie geschäftliche Anwendungsfälle wie Datenanalysen fortsetzen, kann es hilfreich sein, Canary-Ablaufjobs auszuführen, um sicherzustellen, dass die Eingabedaten eine Reihe von Voraussetzungen erfüllen. Sie können Canary-Datenflüsse als benutzerdefinierte Datenpipelines oder als Abläufe in einem DAG basierend auf Cloud Composer implementieren. Mit Canary-Abläufen können Sie Aufgaben wie das Prüfen, ob für bestimmte Felder keine Werte fehlen, oder das Prüfen, ob die Zeilenanzahl bestimmter Datasets mit der erwarteten Anzahl übereinstimmt.

    Sie können auch Canary-Flows verwenden, um Digests oder andere Aggregationen einer Spalte oder einer Teilmenge der Daten zu erstellen. Anschließend können Sie die Daten im Canary-Ablauf mit einem ähnlichen Digest oder einer ähnlichen Aggregation vergleichen, die aus der Kopie der Daten übernommen wurde.

    Canary-Ablaufmethoden sind nützlich, wenn Sie die Genauigkeit der in Cloud-Dateiformaten gespeicherten und kopierten Dateien wie Avro-Dateien zusätzlich zu Cloud Storage auswerten müssen. Canary-Abläufe generieren in der Regel keine neuen Daten. Sie schlagen jedoch fehl, wenn eine Reihe von Regeln in den Eingabedaten nicht erfüllt ist.

  • Testumgebung: Nachdem Sie den Migrationsplan abgeschlossen haben, sollten Sie den Plan in einer Testumgebung testen. Die Testumgebung sollte das Kopieren von Stichprobendaten oder Staging-Daten in eine andere Region umfassen, um den Zeitaufwand für das Kopieren von Daten über das Netzwerk zu schätzen. Mithilfe dieser Tests können Sie Probleme mit dem Migrationsplan ermitteln und überprüfen, ob die Daten erfolgreich migriert werden können. Die Tests sollten sowohl funktionale als auch nicht funktionale Tests umfassen. Funktionstests prüfen, ob die Daten ordnungsgemäß migriert werden. Nicht funktionale Tests prüfen, ob die Migration die Leistungs-, Sicherheits- und anderen 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 Datenvalidierungstool (DVT) verwenden, um die Datenvalidierung zu unterstützen. Das Tool führt mehrstufige Datenvalidierungsfunktionen aus, von der Tabellen- bis zur Zeilenebene. Außerdem können Sie die Ergebnisse der Quell- und Zielsysteme vergleichen.

Ihre Tests sollten die Bereitstellung der Rechenebene prüfen und die kopierten Datasets testen. Ein Ansatz 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 Abweichung zwischen Quell- und Ziel-Dataset ist häufiger, wenn die Dateien, die Sie zwischen Regionen kopieren, keine exakten Bytekopiendarstellungen zwischen den Quell- und Zielsystemen sind, z. B. wenn Sie die Dateiformate ändern oder Dateikomprimierungen.

Nehmen wir als Beispiel 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 über das Netzwerk verschobene Datenmenge zu reduzieren, können Sie eine Avro-Komprimierung als Teil der Migration ausführen, bevor Sie Dateien in die Zielumgebung kopieren. Diese Konvertierung hat viele Vorteile, verursacht jedoch auch einige Risiken, da die Dateien, die in die Zielumgebung geschrieben werden, keine Bytekopiendarstellung 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 für den Hashcode dieses Strings berechnen. Für jede Zeile können Sie einen aggregierten Hash aus einer Kombination aller anderen Spalten berechnen. Dadurch wird mit hoher Genauigkeit bestätigt, dass 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 Tabellen aus der Quell- und der Zielumgebung nicht zusammenführen, da sie sich in verschiedenen Regionen befinden. Daher müssen Sie einen Client verwenden. der sich mit beiden Umgebungen verbinden lässt.

Sie können die vorherigen Testmethoden entweder in BigQuery oder als Batchjob (z. B. in Dataflow) implementieren. Sie können dann die Aggregationsjobs ausführen und die für die Quellumgebung berechneten Ergebnisse mit den für die Zielumgebung berechneten Ergebnissen vergleichen. Mit diesem Ansatz können Sie dafür sorgen, dass die Daten vollständig und korrekt sind.

Ein weiterer wichtiger Aspekt beim Testen der Berechnungsschicht ist die Ausführung von Pipelines, die alle verschiedenen Verarbeitungsengines und Berechnungsmethoden enthalten. Das Testen der Pipeline ist für verwaltete Computer-Engines wie BigQuery oder Dataflow weniger wichtig. Es ist jedoch wichtig, die Pipeline für nicht verwaltete Berechnungsengines 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 den richtigen Tests geprüft haben, können Sie die Daten migrieren. Bei der Migration von Daten können Sie für unterschiedliche 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 den Zeitpunkt der Umstellung. Diese Strategie ist gut, wenn die Daten häufig geändert werden, SLOs und SLAs können jedoch einer gewissen Ausfallzeit standhalten. 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 Geplante Wartung unter "Migration zu Google Cloud: Große Datasets übertragen".
  • Schreibgeschützte Umstellung: Eine geringfügige Variation der Strategie für die geplante Wartung, bei der die Datenpipelines des Quellsystems schreibgeschützte Datenpipelines weiterhin lesen, während die Daten kopiert werden. Diese Strategie ist nützlich, da einige Datenpipelines weiterhin funktionieren und Informationen an Endsysteme liefern. 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 Catchup-Strategie anwenden, um die veralteten Daten in den Endsystemen zu berücksichtigen.
  • Vollständig aktiv: Sie kopieren die Daten zu einem bestimmten Zeitstempel, während die Quellumgebung sowohl für Lese- als auch für 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 enthalten, wie Sie die Aktualisierungs- und Löschvorgänge für die Quelldaten handhaben.
  • Double-Writes: Die Datenpipelines können sowohl in der Quell- als auch in der Zielumgebung ausgeführt werden, während Daten kopiert werden. Diese Strategie vermeidet die Deltakopie-Phase, die zum Auffüllen von Daten erforderlich ist, wenn Sie die vollständig aktiven oder schreibgeschützten Strategien verwenden. Um jedoch sicherzustellen, dass Datenpipelines identische Ergebnisse liefern, erfordert eine Double-Write-Strategie vor der Migration mehr Tests. Wenn Sie keine Vorabtests durchführen, treten Probleme auf, die versuchen, ein Split-Brain-Szenario zu konsolidieren. Die Double-Write-Strategie führt außerdem zu potenziellen Kosten für die 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.

Nach der Migration testen

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 ausführen, müssen Sie diese Tests nach jedem Sprint ausführen. Die Tests in dieser Phase ähneln den Integrationstests: Sie testen die Gültigkeit einer Datenpipeline, auf der geschäftliche Anwendungsfälle mit vollständigen Produktionsdaten als Eingabe ausgeführt werden. Anschließend prüfen Sie die Daten Ausgabe auf Gültigkeit. Sie können die Ausgabe des Integrationstests mit der Ausgabe der Quellumgebung vergleichen, indem Sie in der Quell- und Zielumgebung dieselbe Datenpipeline ausführen. Diese Art von Test funktioniert nur, wenn die Datenpipeline deterministisch ist und Sie dafür sorgen können, dass die Eingabe in beide Umgebungen identisch ist.

Sie können prüfen, ob die Daten vollständig sind, wenn sie eine Reihe vordefinierter Kriterien erfüllen, wobei die Daten in der Quellumgebung mit den Daten in der Zielumgebung identisch (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 vordefinieren, um die Vollständigkeit der Daten für Ihren Anwendungsfall zu beschreiben. Bei Zeitachsendaten können Sie beispielsweise festlegen, dass die Daten vollständig sind, 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 die Umstellungsphase starten. In dieser Phase müssen Clients möglicherweise ihre Konfiguration ändern, damit sie auf die neuen Systeme verweisen können. In einigen Fällen kann die Konfiguration nicht mit der Konfiguration identisch sein, die auf das Quellsystem verweist. Wenn ein Dienst beispielsweise Daten aus einem Cloud Storage-Bucket lesen muss, müssen Clients die Konfiguration ändern, welcher Bucket verwendet werden soll. Da die Namen der Cloud Storage-Buckets 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 einige Zeit aufzubewahren, falls Sie ein Rollback durchführen müssen.

Die Testphase vor der Migration ist nicht so vollständig wie bei einer Produktionsausführung einer Datenpipeline. Daher müssen Sie nach Abschluss der Umstellung und der Ausführung des Zielsystems die Messwerte, Laufzeiten und semantischen Ausgaben Ihrer Datenpipelines beobachten. So können Sie Fehler erkennen, die in der Testphase möglicherweise verpasst wurden, und den Erfolg der Migration gewährleisten.

Umgebung optimieren

Die Optimierung ist die letzte Phase Ihrer Migration. In dieser Phase machen Sie Ihre Umgebung effizienter. Dazu führen Sie mehrere Iterationen einer wiederholbaren Schleife aus, 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 -Computing-Ressourcen für eine regionsübergreifende Migration vorbereiten

Dieser Abschnitt bietet einen Überblick über die Daten- und Rechenressourcen in Google Cloud und die Designprinzipien, um eine regionsübergreifende Migration vorzubereiten.

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

Cloud Storage

Cloud Storage bietet einen 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 sicherzustellen, dass Ihre Jobs einfach in jeder Region bereitgestellt werden können, sollten Sie alle Ein- und Ausgaben als Parameter in den Job einfügen. Anstatt Eingabe- und Ausgabedatenspeicherorte in Ihrem 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 alle Arbeitslasten ausgeführt werden können, die mit dem Apache Hadoop-Framework kompatibel sind. Es ist mit Frameworks wie Apache Spark, Apache Flink und Apache Hive kompatibel.

Sie können Dataproc auf folgende Weise verwenden, was sich darauf auswirkt, wie Sie Ihre Dataproc-Umgebung regionenübergreifend migrieren:

  • 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 die HDFS-Ebene oder ein anderer Status des Clusters ebenfalls 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 werden im Quellcode nicht 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 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 normalerweise effektiv, wenn immer Jobs im Cluster ausgeführt werden. Daher ist es nicht sinnvoll, Cluster wie im sitzungsspezifischen Modell zu löschen und einzurichten. Da die 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 auch den Status, die Daten oder beides im Cluster bei, meist als Daten auf HDFS. Diese Art der Verwendung erschwert die Migrationsbemühungen, da Daten und Computing nicht getrennt sind. Wenn Sie eine ohne die andere migrieren, besteht ein hohes Risiko der Inkonsistenz. In diesem Szenario können Sie Daten und den Zustand vor der Migration aus dem Cluster verschieben, um die beiden zu trennen. Wenn dies nicht möglich ist, empfehlen wir die Verwendung der Strategie Planmäßige Wartung, um das Risiko von Inkonsistenzen in den Daten zu reduzieren.

Da es viele potenzielle Frameworks sowie viele Versionen und Konfigurationen dieser Frameworks gibt, müssen Sie vor der Ausführung Ihres Migrationsplans gründlich testen.

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. Wenn Sie den Status Ihrer Cloud Composer-Bereitstellung migrieren möchten, können Sie Umgebungs-Snapshots speichern und laden.

Wenn Sie benutzerdefinierte Plug-ins für Ihre Cloud Composer-Instanz bereitgestellt haben, empfehlen wir Ihnen, eine Infrastruktur-als-Code-Methode anzuwenden, um die Umgebung vollautomatisch neu zu erstellen.

Cloud Composer verwaltet keine Daten, aktiviert jedoch andere Frameworks zur Datenverarbeitung und Plattformen. Daher kann die Migration von Cloud Composer vollständig von den Daten isoliert werden. Cloud Composer verarbeitet außerdem keine Daten. Daher muss sich Ihre Bereitstellung nicht in derselben Region wie die Daten befinden. Daher können Sie eine Cloud Composer-Bereitstellung in der Zielumgebung erstellen und Pipelines weiterhin in der Quellumgebung ausführen. In einigen Fällen kann dies für den Betrieb verschiedener Pipelines in verschiedenen Regionen nützlich sein, während die gesamte Plattform migriert wird.

Cloud Data Fusion

Cloud Data Fusion ist ein Tool zur visuellen Integration, mit dem Sie Datenpipelines mit einem visuellen Editor erstellen können. Cloud Data Fusion basiert auf dem Open-Source-Projekt CDAP. Wie bei Cloud Composer verwaltet Cloud Data Fusion die Daten nicht selbst, sondern aktiviert andere Frameworks zur Datenverarbeitung und Plattformen. Ihre Cloud Data Fusion-Pipelines sollten auf eine der folgenden Arten aus der Quellumgebung exportiert und in die Zielumgebung importiert werden:

Je nach Umfang der zu migrierenden Abläufe können Sie eine Methode gegenüber der anderen bevorzugen. Die Verwendung der CDAP API zum Erstellen eines Migrationsskripts kann schwierig sein und erfordert mehr Softwareentwicklungskenntnisse. Wenn Sie jedoch viele Abläufe haben oder die Abläufe relativ häufig ändern, ist ein automatisierter Prozess möglicherweise die beste Lösung.

Weitere Informationen

Beitragende

Autoren:

Weitere Beitragende:

Melden Sie sich auf LinkedIn an, um nicht öffentliche LinkedIn-Profile zu sehen.