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

In diesem Dokument wird beschrieben, wie Sie eine Datenplattform auf Google Cloud entwerfen, um die Auswirkungen einer zukünftigen Ausweitung 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 erfahren darin, wie Sie Folgendes tun können:

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

Die Hinweise in dieser Reihe sind auch nützlich, wenn Sie keine Migration über Regionen hinweg oder eine Erweiterung auf mehrere Regionen im Voraus geplant haben. In diesem Fall müssen Sie möglicherweise zusätzlichen Aufwand für die Vorbereitung der Infrastruktur, Arbeitslasten und Daten für die regionsübergreifende Migration und die Ausweitung auf mehrere Regionen aufwenden.

Dieses Dokument ist Teil der folgenden Reihe:

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

Diese Grafik veranschaulicht den Migrationsprozess:

Migrationspfad mit vier Phasen

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

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

Die moderne Datenplattform auf Google Cloud

In diesem Abschnitt werden die verschiedenen Teile einer modernen Datenplattform und deren normalerweise in Google Cloudbeschrieben. Datenplattformen als allgemeines Konzept lassen sich in zwei Abschnitte unterteilen:

  • In der Datenspeicherebene werden Daten gespeichert. Die gespeicherten Daten können in Form von Dateien gespeichert werden, in denen Sie tatsächliche Byte in einem Dateisystem wie Hadoop Distributed File System (HDFS) oder Cloud Storage verwalten. Oder Sie verwenden eine Domain-spezifische Sprache (DSL) zur Verwaltung der Daten in einem Datenbank-Verwaltungssystem.
  • Die Datenberechnungsebene ist eine Datenverarbeitung, die Sie zusätzlich zum Speichersystem aktivieren können. Wie bei der Speicherschicht gibt es viele mögliche Implementierungen. Einige Datenspeichertools übernehmen auch die Datenberechnung. Die Datenberechnungsschicht in der Plattform besteht darin, Daten aus der Speicherschicht zu laden, zu verarbeiten und dann die Ergebnisse 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 Datenspeicher- und die Datenverarbeitungsschicht voneinander getrennt. Beispielsweise haben Sie Ihre Datenspeicherebene möglicherweise mit diesenGoogle Cloud -Diensten implementiert:

Möglicherweise haben Sie die Datenberechnungsebene mithilfe andererGoogle Cloud -Dienste 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 sollten Sie die Datenspeicherebene von der Datenberechnungsebene getrennt halten. Durch die Trennung dieser Ebenen sind Sie beim Ändern von Berechnungsebenen und Migrieren von Daten flexibler. Durch eine Trennung der Ebenen wird auch die Ressourcennutzung reduziert, da die Berechnungsebene nicht ständig ausgeführt werden muss. Daher empfehlen wir, den Datenspeicher und die Datenberechnung auf separaten Plattformen in derselben Zone und Region bereitzustellen. Sie können beispielsweise Ihren Datenspeicher von HDFS nach Cloud Storage verschieben und einen Dataproc-Cluster für die Berechnung verwenden.

Umgebung bewerten

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

  1. Erstellen Sie eine umfassende Bestandsaufnahme Ihrer Datenpipelines.
  2. Pipelines nach ihren Attributen und Abhängigkeiten katalogisieren.
  3. Schulen und schulen Sie Ihre Teams zu Google Cloud.
  4. Erstelle ein Experiment und einen Proof of Concept für Google Cloud.
  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

Für die Migration müssen Sie die Datenplattformumgebung kennen, in der Ihre Datenpipelines bereitgestellt werden:

  1. Erstellen Sie ein Inventar Ihrer Dateninfrastruktur – die verschiedenen Speicher- und 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 müssen.

Berücksichtigen Sie beim Erstellen eines Bestands Ihrer Datenplattform für jeden Teil der Dateninfrastruktur Folgendes:

  • 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 hat möglicherweise ein integriertes Migrationstool. Achten Sie darauf, dass jedes Produkt, das Sie zur Datenspeicherung verwenden, in Ihrer Zielumgebung für Sie verfügbar ist oder ob Sie einen kompatiblen Ersatz haben. Üben und überprüfen Sie den technischen Datenübertragungsprozess für jede der beteiligten Speicherplattformen.
  • Komprimierungsebenen. Überprüfen Sie für jede Rechenplattform den Bereitstellungsplan und 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 seine eigenen Einrichtungsmethoden. Ermitteln Sie Ihren Bestand an benutzerdefinierten Konfigurationen, die Sie für die einzelnen Komponenten erstellt haben, und welche Komponenten Sie in den Standardversionen der einzelnen Plattformen verwenden, z. B. welche Dataproc-Version oder welche Apache Kafka-Version Sie haben. Achten Sie darauf, dass diese Konfigurationen im Rahmen Ihres automatisierten Bereitstellungsprozesses bereitgestellt werden.

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

    Während der Migration empfehlen wir die Verwendung automatisierter Bereitstellungen, damit Versionen und Konfigurationen gleich bleiben. Wenn Versionen und Konfigurationen nicht gleich bleiben können, sollten Sie Tests verwenden, um die vom Framework berechneten Datenausgaben zu überprüfen.

  • 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 zu einer anderen Region kann zu einer Änderung des Prozessors führen, den Ihre Bereitstellung verwendet. Daher empfehlen wir, nach der Bereitstellung der migrierten Infrastruktur für die Produktion ein Profil für Ihre Arbeitslasten zu erstellen und diese zu optimieren. 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 Elemente, die Sie in Ihrem Inventar bewerten, beziehen sich auf die Datenpipelines:

  • Datenquellen und -senken: Berücksichtigen Sie dabei 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. Wenn Sie Pipelines in Migrationssprints aufteilen, müssen Sie Datenabhängigkeiten berücksichtigen.
  • Generierte und genutzte Datasets. Ermitteln Sie für jede Datenpipeline die Datasets, die von der Pipeline genutzt werden, und ermitteln Sie, welche Datasets sie generiert. Auf diese Weise können Sie Abhängigkeiten zwischen Pipelines und zwischen anderen Systemen oder Komponenten in Ihrer Gesamtarchitektur ermitteln.

Die folgenden Elemente, die Sie in Ihrem Inventar bewerten, konzentrieren 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. Durch die Definition des Umfangs für den Migrationsprozess und die Migrationssprints können Sie die Risiken der Migration reduzieren.
  • Datengrößen: Wenn Sie Dateien vor der Übertragung komprimieren möchten, achten Sie darauf, die Dateigröße vor und nach der Komprimierung anzugeben. Die Größe Ihrer Daten wirkt sich auf den Zeit- und Kostenaufwand für das Kopieren der Daten von der Quelle zum Ziel aus. 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 vergewissern Sie sich, dass Sie wissen, 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 zu Ihren Kubernetes-Clustern und -Arbeitslasten gehörenden Inventare erstellt haben, 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 Build-Phase der Migration zu Google Cloud besteht aus den 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 Migration zu Google Cloud: Grundlagen planen und aufbauen.

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 Ihr Vertrauen in die Datenmigration erhöhen können.

Migrationsplan

In Ihrem Migrationsplan müssen Sie Zeit für die Datenübertragung einbeziehen. Ihr Plan sollte die Netzwerklatenz, die Zeit zum Testen der Vollständigkeit der Daten und das Abrufen von Daten, die nicht migriert werden konnten, sowie etwaige 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 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, der Abhängigkeiten und der Art der verschiedenen Datenpipelines aus der Berechnungsebene. Wenn die Datenspeicher- und die Datenberechnungsschicht auf demselben System basieren, empfehlen wir Ihnen, 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 und Leistungseinbußen in der Rechenschicht führen. Wenn Sie beispielsweise eine Arbeitslast ausführen, um Daten im Batch-Modus aus einem Kafka-Cluster zu extrahieren, können die zusätzlichen E/A-Vorgänge zum Lesen großer Datenmengen zu einer Leistungsbeeinträchtigung aller aktiven Datenpipelines führen, die noch in der Quellumgebung ausgeführt werden. In diesem Szenario sollten Sie die Leistung des Systems mithilfe von integrierten oder benutzerdefinierten Messwerten überwachen. Damit das System nicht überlastet wird, empfiehlt es sich, 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, Notfallpläne zu haben, um alles zu beheben, was während der Migration schiefgehen 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, die Sie für die Migration verwenden, und den Daten, die Sie kopieren, zu unterscheiden. Das Rollback der Datenverschiebung bedeutet, dass Sie Daten neu kopieren und bereits kopierte Daten entweder ü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. Um das erneute Kopieren von Daten zu vermeiden, sollten Sie Ihre Skripts so erstellen, dass Wiederaufnahme und Idempotenz möglich sind.

Eigenschaften der Datenpipeline

Um einen optimalen Migrationsplan zu erstellen, müssen Sie die Eigenschaften verschiedener Datenpipelines kennen. 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, 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, können unterschiedliche Anforderungen an die Datenaktualität haben. Wenn die Pipelines, die Daten generieren, auf dem Quellsystem angehalten werden, können die Pipelines, die Daten lesen, möglicherweise ausgeführt werden, während Daten in die Zielumgebung kopiert werden.

Daten haben einen Status und das Kopieren von Daten zwischen Regionen ist kein atomarer Vorgang. Daher müssen Sie Statusänderungen während des Kopierens von Daten im Auge behalten.

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. Ihr Plan sollte daher unterschiedliche Strategien für die Migration jedes Systems enthalten. Achten Sie darauf, die Abhängigkeiten zwischen den Systemen anzugeben und anzugeben, wie Sie die Ausfallzeit 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. Gängige Strategien finden Sie unter Arbeitslasten bereitstellen.
  • Liste der Tools und Methoden zum 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 zum Kopieren von Cloud Storage-Assets, Standardtools wie die Google Cloud CLI und Google Cloud Tools wie Migration Services enthalten.
  • Liste der Ressourcen, die in der Zielumgebung bereitgestellt werden sollen Listen Sie alle Ressourcen auf, die in der Zielumgebung bereitgestellt werden müssen. Die Liste sollte alle Komponenten der Dateninfrastruktur 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. Stellen Sie sicher, dass Ihr Plan potenzielle 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 Methode: Sehen Sie sich die zuvor in diesem Dokument beschriebene Liste der Tools und Methoden an.
    • 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 einplanen können. Die Tests können Ihnen helfen, die Integrität und Vollständigkeit der Daten sicherzustellen. Sie können damit auch dafür sorgen, dass die Computing-Ebene wie erwartet funktioniert und zum Ausführen Ihrer Datenpipelines bereit ist.

  • Zusammenfassungs- oder Hash-Vergleich: Um nach dem Kopieren der Daten die Vollständigkeit der Daten zu validieren, müssen Sie das ursprüngliche Dataset mit der neuen Kopie in der Zielumgebung vergleichen. Wenn die Daten in BigQuery-Tabellen strukturiert sind, können Sie die beiden Tabellen nicht in einer Abfrage zusammenführen, um zu prüfen, ob alle Daten vorhanden sind, da sich die Tabellen in verschiedenen Regionen befinden. Aufgrund der Kosten und Latenz erlaubt BigQuery es Abfragen nicht, Daten regionsübergreifend zusammenzuführen. Stattdessen muss die Vergleichsmethode jedes Dataset zusammenfassen und die Ergebnisse vergleichen. Je nach Dataset-Struktur kann die Methode für die Zusammenfassung unterschiedlich sein. Eine BigQuery-Tabelle kann beispielsweise eine Aggregationsabfrage verwenden, aber eine Reihe von Dateien in Cloud Storage könnte eine Spark-Pipeline verwenden, um einen Hash-Wert jeder Datei zu berechnen und dann die Hashes 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 Datenanalysen fortfahren, kann es hilfreich sein, Canary-Ablaufjobs auszuführen, um dafür zu sorgen, dass die Eingabedaten eine Reihe von Voraussetzungen erfüllen. Canary-Abläufe lassen sich 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 Aggregation aus der Kopie der Daten zu vergleichen.

    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 ein Regelsatz 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 beinhalten, um die Zeit zu schätzen, die für das 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 funktionale als auch nicht funktionale Tests umfassen. Funktionstests prüfen, ob die Daten korrekt migriert wurden. Nicht funktionale Tests prüfen, ob die Migration die Anforderungen an Leistung, Sicherheit und andere nicht funktionale Anforderungen erfüllt. Jeder Migrationsschritt in Ihrem Plan sollte Validierungskriterien enthalten, die angeben, wann der Schritt als abgeschlossen betrachtet werden kann.

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

Mit Ihren Tests sollten Sie die Bereitstellung der Computing-Ebene prüfen und die kopierten Datasets testen. Ein Ansatz hierfür besteht darin, eine Testpipeline zu erstellen, die einige Aggregationen der kopierten Datasets berechnen kann und dafür sorgt, 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).

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 im Rahmen der Migration eine Avro-Komprimierung durchführen, bevor Sie Dateien in die Zielumgebung kopieren. Diese Konvertierung hat viele Vorteile, birgt aber auch 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 auf Basis der Stringlänge oder des Hash-Codes dieses Strings berechnen. Für jede Zeile können Sie einen aggregierten Hash aus einer Kombination aller anderen Spalten berechnen, um mit hoher Genauigkeit zu prü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 Ergebnissen vergleichen. Dieser Ansatz kann Ihnen helfen, sicherzustellen, dass die Daten vollständig und genau sind.

Ein weiterer wichtiger Aspekt beim Testen der Computing-Ebene ist die Ausführung von Pipelines, die alle Varianten von Verarbeitungs-Engines und Berechnungsmethoden umfassen. Für verwaltete Computing-Engines wie BigQuery oder Dataflow ist das Testen der Pipeline 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 den richtigen Tests überprüft haben, können Sie Daten migrieren. Wenn Sie Daten migrieren, können Sie verschiedene Strategien für unterschiedliche Arbeitslasten verwenden. Im Folgenden finden Sie Beispiele für Migrationsstrategien, die Sie unverändert verwenden oder an Ihre Anforderungen anpassen können:

  • Geplante Wartung: Sie planen, wann das Umstellungsfenster auftritt. Diese Strategie eignet sich gut, wenn Daten häufig geändert werden, aber SLOs und SLAs können 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 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 Endsystemen Informationen liefern 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 Nachholstrategie 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-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 Überlegung. Daher muss Ihr Migrationsplan vorgeben, wie Sie die Aktualisierungs- und Löschvorgänge der Quelldaten handhaben werden.
  • Doppelte Schreibvorgänge: Die Datenpipelines können sowohl in der Quell- als auch in der Zielumgebung ausgeführt werden, während Daten kopiert werden. Mit dieser Strategie wird die Phase des Deltakopiervorgangs vermieden, die für das Backfill von Daten erforderlich ist, wenn Sie die vollständig aktive oder schreibgeschützte Strategie verwenden. Damit jedoch sichergestellt wird, dass Datenpipelines identische Ergebnisse liefern, erfordert eine Strategie mit doppelten Schreibvorgängen vor der Migration weitere Tests. Wenn Sie keine erweiterten Tests durchführen, werden Sie auf Probleme stoßen, die versuchen, ein Split-Brain-Szenario zu konsolidieren. Die Strategie mit doppelten Schreibvorgängen bringt auch potenzielle Kosten mit sich, wenn dieselben Arbeitslasten zweimal in verschiedenen Regionen ausgeführt werden. Diese Strategie enthält die Möglichkeit, Ihre Plattform ohne Ausfallzeiten zu migrieren, erfordert jedoch viel mehr Koordination, um sie korrekt auszuführen.

Tests nach der Migration

Nach Abschluss der Migration sollten Sie die Vollständigkeit der Daten 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 und prüfen Sie dann die Ausgabe auf Gültigkeit. Sie können die Ausgabe des Integrationstests mit der Ausgabe der Quellumgebung vergleichen, indem Sie dieselbe Datenpipeline sowohl in der Quell- als auch in der Zielumgebung ausführen. Diese Art von Test funktioniert nur, wenn die Datenpipeline deterministisch ist und Sie dafür sorgen können, dass die Eingabe in beiden Umgebungen identisch ist.

Sie können 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 identisch oder ähnlich genug sind. Je nach Strategie, die Sie im vorherigen Abschnitt verwendet haben, stimmen die Daten möglicherweise nicht direkt überein. Daher müssen Sie Kriterien zur Beschreibung der Vollständigkeit der Daten für Ihren Anwendungsfall vordefinieren. Bei Zeitachsendaten könnten Sie beispielsweise davon ausgehen, dass die Daten vollständig sind, wenn der aktuelle 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. Das Starten 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 der Konfiguration entsprechen, die auf das Quellsystem verweist. Wenn ein Dienst beispielsweise Daten aus einem Cloud Storage-Bucket lesen muss, müssen Clients die Konfiguration des Buckets ändern, der 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 ihre Planung aufheben. Wir empfehlen, die Daten der Quellumgebung über einen längeren Zeitraum beizubehalten, falls ein Rollback erforderlich ist.

Die Testphase vor der Migration ist nicht so abgeschlossen wie die Produktionsausführung einer Datenpipeline. Daher müssen Sie, nachdem die Umstellung abgeschlossen ist und das Zielsystem betriebsbereit ist, die Messwerte, Laufzeiten und semantischen Ausgaben Ihrer Datenpipelines überwachen. Dieses Monitoring hilft Ihnen, Fehler zu erkennen, die in der Testphase möglicherweise übersehen wurden, und trägt zu einer erfolgreichen Migration bei.

Umgebung optimieren

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

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

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

Daten und Rechenressourcen Google Cloud für eine regionsübergreifende Migration vorbereiten

Dieser Abschnitt bietet einen Überblick über die Daten- und Rechenressourcen aufGoogle Cloud und die Designprinzipien zur Vorbereitung auf eine regionsübergreifende 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 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 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. 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 Eingabe- und Ausgabespeicherorte in den 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 jede mit dem Apache Hadoop-Framework kompatible Arbeitslast ausgeführt werden kann. Es 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. Dies bedeutet, dass auch die HDFS-Ebene oder ein anderer Status des Clusters gelöscht wird. Wenn Ihre Konfiguration die folgenden Kriterien erfüllt, ist diese Art der Nutzung im Vergleich zu anderen Nutzungsarten einfacher zu migrieren:
    • 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. Die Daten und die Berechnung sind getrennt, da die Daten inGoogle Cloud -Lösungen wie Cloud Storage oder BigQuery außerhalb des Clusters gespeichert werden. Dieses Modell ist in der Regel 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 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 Rechenleistung nicht getrennt sind. Wenn Sie bei einer Migration ohne die andere Daten migrieren, besteht ein hohes Risiko für Inkonsistenzen. In diesem Szenario sollten Sie die Daten und den 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 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 Cloudzur 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 sollte. Sie können Umgebungs-Snapshots speichern und laden, um den Status Ihrer Cloud Composer-Bereitstellung zu migrieren.

Wenn Sie benutzerdefinierte Plug-ins auf Ihrer Cloud Composer-Instanz bereitgestellt haben, empfehlen wir Ihnen, 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. Da Cloud Composer auch keine Daten verarbeitet, muss sich die Bereitstellung nicht in derselben Region wie die Daten befinden. Daher können Sie eine Cloud Composer-Bereitstellung in der Zielumgebung erstellen und trotzdem Pipelines in der Quellumgebung ausführen. In einigen Fällen kann dies beim Betrieb verschiedener Pipelines in verschiedenen Regionen nützlich sein, 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 die Daten nicht selbst, aktiviert jedoch 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 Abläufe, die migriert werden müssen, ist unter Umständen eine Methode der anderen vorzuziehen. Die Verwendung der CDAP API zum Erstellen eines Migrationsskripts kann schwierig sein und erfordert mehr Softwareentwicklungskenntnisse. 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