Lokale Hadoop-Infrastruktur zu Google Cloud migrieren

Last reviewed 2024-08-15 UTC

Diese Anleitung bietet einen Überblick darüber, wie Sie Ihr lokales Apache Hadoop-System zu Google Cloud verschieben. Bei dem beschriebenen Migrationsvorgang verschieben Sie nicht nur Ihre Hadoop-Arbeitsprozesse zu Google Cloud. Sie können diese Prozesse auch noch so anpassen, dass sie von den Vorteilen eines für Cloud-Computing optimierten Hadoop-Systems profitieren. Darüber hinaus werden einige grundlegende Konzepte erläutert, die Sie für die Übertragung Ihrer Hadoop-Konfiguration zu Google Cloud kennen sollten.

Dies ist der erste von mehreren Leitfäden, in denen die Migration von lokalem Hadoop erläutert wird:

Die Vorteile der Migration zu Google Cloud

Die Nutzung von Google Cloud spart Ihnen im Vergleich mit einer lokalen Hadoop-Lösung in vielerlei Hinsicht Zeit, Geld und Aufwand. In vielen Fällen entsteht durch einen cloudbasierten Ansatz eine Gesamtlösung, die weniger komplex und leichter zu verwalten ist.

Integrierte Unterstützung für Hadoop

Google Cloud umfasst Dataproc, eine verwaltete Hadoop- und Spark-Umgebung. Mit Dataproc können Sie die meisten Ihrer vorhandenen Jobs mit minimalen Änderungen verwenden, sodass Sie nicht auf alle Hadoop-Tools, die Sie bereits kennen, verzichten müssen.

Verwaltete Hardware und Konfiguration

Wenn Sie Hadoop in Google Cloud ausführen, müssen Sie sich keine Gedanken über die physische Hardware machen. Sie geben die Konfiguration Ihres Clusters an, und Dataproc weist die entsprechenden Ressourcen zu. Sie können den Cluster jederzeit skalieren.

Einfachere Versionsverwaltung

Bei der Verwaltung eines Hadoop-Clusters besteht eine der komplexesten Aufgaben darin, Open-Source-Tools auf dem neuesten Stand zu halten und für ihre Interoperabilität zu sorgen. Wenn Sie Dataproc nutzen, wird Ihnen ein großer Teil dieser Arbeit von der Dataproc-Versionsverwaltung abgenommen.

Flexible Jobkonfiguration

Bei einem typischen lokalen Hadoop-Setup kommt ein einzelner Cluster zum Einsatz, der zahlreichen Zwecken dient. Nach der Migration zu Google Cloud können Sie sich auf einzelne Aufgaben konzentrieren und so viele Cluster erstellen, wie Sie benötigen. Da die Verwaltung eines einzelnen Clusters aufgrund zunehmender Abhängigkeiten und unterschiedlicher Softwarekonfigurationen äußerst komplex ist, wird Ihnen dadurch die Arbeit erleichtert.

Migration planen

Für die Migration einer lokalen Hadoop-Lösung zu Google Cloud ist ein neuer Ansatz erforderlich. Ein typisches lokales Hadoop-System besteht aus einem monolithischen Cluster, der zahlreiche Arbeitslasten, häufig aus unterschiedlichen Aufgabenbereichen, unterstützt. Dies hat zur Folge, dass das System im Lauf der Zeit immer komplexer wird und Administratoren manchmal Kompromisse eingehen müssen, damit in dem monolithischen Cluster alles funktioniert. Wenn Sie Ihr Hadoop-System auf Google Cloud verlagern, können Sie die Verwaltung vereinfachen. Allerdings müssen Sie die Struktur Ihrer Daten und Jobs überdenken, damit Sie diese Vereinfachung und möglichst effiziente Prozesse bei minimalen Kosten in Google Cloud erreichen.

Hadoop wird von Dataproc in Google Cloud ausgeführt, daher scheint ein nichtflüchtiger Dataproc-Cluster als Replikation Ihres lokalen Setups die einfachste Lösung zu sein. Bei diesem Ansatz gibt es jedoch einige Einschränkungen:

  • Die Speicherung Ihrer Daten in einem nichtflüchtigen HDFS-Cluster unter Verwendung von Dataproc ist teurer als das Speichern Ihrer Daten in Cloud Storage. Daher empfehlen wir die Nutzung von Cloud Storage, die wir später noch erörtern. Bei der Speicherung von Daten in einem HDFS-Cluster ist außerdem die Nutzung von Daten mit anderen Google Cloud-Produkten eingeschränkt.
  • Für bestimmte Anwendungsfälle ist es effizienter oder wirtschaftlicher, einige Ihrer Open-Source-Tools durch andere entsprechende Google Cloud-Dienste zu ergänzen oder zu ersetzen.
  • Wenn Sie für Ihre Jobs einen einzelnen nichtflüchtigen Dataproc-Cluster verwenden, ist die Verwaltung schwieriger als beim Umstieg auf spezialisierte Cluster, die für einzelne Jobs oder Jobbereiche bestimmt sind.

Die kostengünstigste und flexibelste Methode für die Migration Ihres Hadoop-Systems zu Google Cloud besteht darin, das Konzept der großen nichtflüchtigen Vielzweckcluster aufzugeben und stattdessen kleine, kurzlebige Cluster zur Ausführung spezieller Jobs einzusetzen. Die Daten werden dabei in Cloud Storage gespeichert, damit zahlreiche temporäre Verarbeitungscluster unterstützt werden können. Dieses Modell wird häufig als sitzungsspezifisches Modell bezeichnet, da die Cluster, die Sie für die Verarbeitung von Jobs verwenden, nach Bedarf zugewiesen und nach Beendigung der Jobs wieder freigegeben werden.

Im folgenden Diagramm ist ein Beispiel für die Migration von einem lokalen System zu einem sitzungsspezifischen Modell in Google Cloud dargestellt.

Diagramm zur Veranschaulichung, wie lokale Cluster bei der Migration zu Google Cloud neu angeordnet werden können

In diesem Beispiel werden vier Jobs, die auf zwei lokalen Clustern ausgeführt werden, zu Dataproc verschoben. Die sitzungsspezifischen Cluster, die zur Ausführung von Jobs in Google Cloud verwendet werden, sind so definiert, dass die Effizienz der einzelnen Jobs optimiert wird. Für die ersten beiden Jobs wird derselbe Cluster genutzt, während der dritte und vierte Job jeweils auf eigenen Clustern ausgeführt werden. Wenn Sie Ihre eigenen Jobs migrieren, können Sie die Cluster für einzelne Jobs oder Gruppen von Jobs so anpassen und optimieren, wie es für die spezielle Aufgabe erforderlich ist. Dataproc hilft Ihnen dabei, schnell mehrere Cluster zu definieren, sie online verfügbar zu machen und nach Ihren Bedürfnissen zu skalieren.

In dem Beispiel werden die Daten aus zwei lokalen HDFS-Clustern in Cloud Storage-Buckets verschoben. Die Daten in dem ersten Cluster werden auf mehrere Buckets aufgeteilt und der zweite Cluster wird in einen einzigen Bucket verschoben. Sie können die Struktur Ihrer Daten in Cloud Storage an den Bedarf Ihrer Anwendungen und Ihres Unternehmens anpassen.

In dieser Beispielmigration sind die Anfangs- und Endzustände einer vollständigen Migration zu Google Cloud dargestellt. Dadurch entsteht der Eindruck eines einzigen Schrittes, doch erzielen Sie die besten Ergebnisse, wenn Sie den Wechsel zu Google Cloud nicht als einmalige, vollständige Migration betrachten. Betrachten Sie das Ganze eher als Refaktorierung Ihrer Lösungen mit dem Ziel, neue Tools auf eine Weise einzusetzen, wie es lokal nicht möglich wäre. Für eine erfolgreiche Refaktorierung empfehlen wir eine schrittweise Migration.

Die folgenden Schritte werden für die Migration Ihrer Workflows zu Google Cloud empfohlen:

  1. Daten verschieben

    • Verschieben Sie Ihre Daten in Cloud Storage-Buckets.
    • Fangen Sie klein an. Verwenden Sie gesicherte oder archivierte Daten, um die Auswirkungen auf Ihr vorhandenes Hadoop-System zu minimieren.

  2. Testen

    • Verwenden Sie zum Testen und Experimentieren nicht alle Daten. Erstellen Sie für jeden Job in kleinem Umfang einen Proof of Concept.
    • Probieren Sie neue Ansätze für die Arbeit mit Ihren Daten aus.
    • Nehmen Sie Anpassungen für die Google Cloud- und Cloud-Computing-Modelle vor.

  3. Konzept auf spezialisierte, sitzungsspezifische Cluster abstimmen

    • Verwenden Sie möglichst kleine Cluster. Stimmen Sie deren Umfang auf einzelne Jobs oder kleine Gruppen eng verwandter Jobs ab.
    • Erstellen Sie Cluster, wenn Sie sie für einen Job benötigen, und löschen Sie sie nach Abschluss des Jobs.

  4. Verwenden Sie Google Cloud-Tools, wann immer dies angebracht ist

Auf ein sitzungsspezifisches Modell umsteigen

Die größte Änderung des Ansatzes zwischen der Ausführung eines lokalen Hadoop-Workflows und der Ausführung desselben Workflows in Google Cloud besteht im Umstieg von monolithischen, nichtflüchtigen Clustern auf spezialisierte, sitzungsspezifische Cluster. Sobald Sie einen Job ausführen müssen, erstellen Sie schnell einen Cluster und löschen ihn dann wieder, wenn der Job abgeschlossen ist. Die von Ihren Jobs benötigten Ressourcen sind nur aktiv, wenn sie verwendet werden, sodass Sie nur für die tatsächliche Nutzung zahlen. Dank dieses Ansatzes haben Sie die Möglichkeit, Cluster-Konfigurationen maßgeschneidert auf einzelne Jobs abzustimmen. Da Sie keinen nichtflüchtigen Cluster verwalten und konfigurieren, senken Sie so die Kosten für die Ressourcennutzung und Cluster-Administration.

In diesem Abschnitt wird beschrieben, wie Sie Ihre vorhandene Hadoop-Infrastruktur auf ein sitzungsspezifisches Modell umstellen.

Daten von den Verarbeitungsressourcen trennen

Die Verwendung von Cloud Storage als nichtflüchtigem Speicher für Ihre Workflows bietet diese Vorteile:

  • Es ist einfacher, Zugriffsberechtigungen zu verwalten.
  • Es arbeitet mit einem Hadoop-kompatiblen Dateisystem (Hadoop Compatible File System, HCFS), sodass Sie es problemlos mit Ihren vorhandenen Jobs verwenden können.
  • Es ist in den meisten Fällen schneller als das HDFS.
  • Es erfordert geringeren Verwaltungsaufwand als HDFS.
  • Die Migration von Daten ist einfacher als bei HDFS.
  • Es bietet Ihnen die Möglichkeit, Daten mit einem breiten Angebot von Google Cloud-Produkten zu verwenden.
  • Es ist weitaus kostengünstiger als die Speicherung von Daten in HDFS in einem nichtflüchtigen Dataproc-Cluster.

Wenn Sie Ihre Daten dauerhaft in Cloud Storage speichern, können Sie Ihre Jobs auf sitzungsspezifischen Hadoop-Clustern ausführen, die von Dataproc verwaltet werden.

In manchen Fällen kann es sinnvoller sein, die Daten in eine andere Google Cloud-Technologie wie BigQuery oder Bigtable zu verschieben. Die meisten allgemeinen Daten sollten jedoch in Cloud Storage abgelegt werden. Weitere Informationen zu diesen alternativen Speichermöglichkeiten finden Sie weiter unten in diesem Leitfaden.

Jobs in sitzungsspezifischen Clustern ausführen

Mit Dataproc ist das Erstellen und Löschen von Clustern einfach, sodass Sie nicht mehr auf einen monolithischen Cluster angewiesen sind, sondern zahlreiche sitzungsspezifische Cluster nutzen können. Dieser Ansatz bietet verschiedene Vorteile:

  • So können Sie Single Points of Failure vermeiden und die Zuverlässigkeit Ihrer Datenpipeline erhöhen. Wenn bei einem freigegebenen, lang laufenden Cluster ein Fehler auftritt, kann die gesamte Datenpipeline blockiert werden. Die Reparatur eines zustandsorientierten, lang laufenden Clusters kann sehr lange dauern und zu Verstößen gegen das Service Level Objective (SLO) führen. Ein zustandsloser Sitzungscluster mit Problemen kann dagegen ganz einfach gelöscht und dann mit Jobwiederholungen neu erstellt werden.
  • Sie können die Jobleistung besser vorhersagen und SLO-Verstöße vermeiden, indem Sie Ressourcenkonflikte zwischen Jobs beseitigen.
  • Sie können Clusterkonfigurationen und Autoscaling-Richtlinien für einzelne Jobs optimieren.
  • Sie erhalten die neuesten Sicherheitspatches, Fehlerkorrekturen und Optimierungen, wenn Sie einen sitzungsspezifischen Cluster für einen Job erstellen.
  • Sie können häufige Probleme mit Clustern mit langer Laufzeit vermeiden, z. B., wenn Laufwerke mit Logs und temporären Dateien gefüllt werden oder der Cluster aufgrund eines Lagerbestands in der Zone nicht hochskaliert werden kann.
  • Sie müssen Cluster nicht kontinuierlich betreuen, da sitzungsspezifische Cluster bei jeder Verwendung neu konfiguriert werden. Da keine Cluster mehr verwaltet werden müssen, entfällt der Verwaltungsaufwand für die Verwaltung von Tools für alle Jobs.
  • Sie müssen keine separate Infrastruktur für Entwicklung, Testen und Produktion vorhalten. Sie können mit denselben Definitionen so viele verschiedene Cluster erstellen, wie Sie benötigen.
  • Mit dem isolierten Cluster mit einem einzelnen Job können Sie Probleme schneller beheben.
  • Sie zahlen nur dann für Ressourcen, wenn diese von Ihren Jobs verwendet werden.

Sie können die Initialisierungsaktionen von Dataproc verwenden, um die Konfiguration der Knoten in einem Cluster festzulegen. Dies vereinfacht die Verwaltung der unterschiedlichen Clusterkonfigurationen, die Sie benötigen, um einzelne Jobs und verwandte Gruppen von Jobs optimal unterstützen zu können. Für den Einstieg können Sie die bereitgestellten Beispiel-Initialisierungsaktionen nutzen. Mit diesen Beispielen wird veranschaulicht, wie Sie Ihre eigenen Initialisierungsaktionen erstellen.

Lebensdauer von sitzungsspezifischen Clustern minimieren

Sitzungsspezifische Cluster zeichnen sich dadurch aus, dass sie nur während der Lebensdauer des Jobs verwendet werden. Gehen Sie folgendermaßen vor, wenn Sie einen Job ausführen müssen:

  1. Erstellen Sie einen zweckmäßig konfigurierten Cluster.

  2. Führen Sie den Job aus und senden Sie die Ausgabe an Cloud Storage oder einen anderen nichtflüchtigen Speicherort.

  3. Löschen Sie den Cluster.

  4. Verwenden Sie die Jobausgabe nach Bedarf.

  5. Sehen Sie sich die Logs in Cloud Logging oder Cloud Storage an.

Dieser Ablauf wird im folgenden Diagramm veranschaulicht:

Ablaufdiagramm eines sitzungsspezifischen Jobs in der Cloud

Kleine nichtflüchtige Cluster ausschließlich bei zwingender Notwendigkeit verwenden

Wenn Sie für die Arbeit einen nichtflüchtigen Cluster benötigen, können Sie einen erstellen. Diese Option kann kostenintensiv sein und wird nicht empfohlen, solange die Möglichkeit besteht, den Job auf sitzungsspezifischen Clustern zu erledigen.

Mit folgenden Maßnahmen können Sie die Kosten für einen nichtflüchtigen Cluster minimieren:

  • Erstellen Sie einen möglichst kleinen Cluster.
  • Beschränken Sie die Arbeit auf diesem Cluster auf die kleinstmögliche Anzahl von Jobs.
  • Skalieren Sie den Cluster für die minimal praktikable Anzahl von Knoten, zu der je nach Bedarf weitere dynamisch hinzugefügt werden.

Schrittweise Migration

Eine schrittweise Migration bietet zahlreiche Vorteile. Sie haben folgende Möglichkeiten:

  • Einzelne Jobs in Ihrer vorhandenen Hadoop-Infrastruktur von der mit einer lange bestehenden Systemumgebung verbundenen Komplexität isolieren
  • Jeden isolierten Jobs zur Ermittlung der jeweiligen Anforderungen und der besten Methode für die Migration untersuchen
  • Unerwartete Probleme unmittelbar bei Auftreten ohne Verzögerung abhängiger Aufgaben beheben
  • Proof-of-Concept für jeden komplexen Prozess ohne Beeinträchtigung Ihrer Produktionsumgebung erstellen
  • Arbeitslasten auf das sitzungsspezifische Modell umstellen – wohl durchdacht und effektiv

Die Art und Weise der Migration ist abhängig von der jeweiligen Hadoop-Umgebung, es gibt also keinen universellen Plan, der auf alle Migrationsszenarien anwendbar wäre. Stellen Sie einen eigenen Plan für die Migration auf, der Ihnen die Freiheit lässt, die einzelnen Bestandteile nach und nach auf ein Cloud-Computing-Modell zu übertragen.

Mit dieser Abfolge lässt sich eine typische schrittweise Migration beschreiben:

  1. Verschieben Sie einen Teil Ihrer Daten zu Google Cloud.

  2. Experimentieren Sie mit diesen Daten:

    1. Replizieren Sie Ihre vorhandenen Jobs, die diese Daten nutzen.

    2. Erstellen Sie neue Prototypen, die diese Daten nutzen.

  3. Wiederholen Sie diesen Vorgang mit weiteren Daten.

Starten Sie mit den am wenigsten kritischen Daten. Am Anfang empfiehlt es sich, Sicherungsdaten und Archive zu verwenden.

Jobs mit geringerem Risiko, die sich gut für erste Tests eignen, sind beispielsweise Backfills unter Ausführung von Burst-Verarbeitungen mit Archivdaten. Sie können Jobs einrichten, mit denen Verarbeitungslücken für Daten, die vor dem Bestehen Ihrer aktuellen Jobs vorhanden waren, geschlossen werden. Wenn mit Burst-Jobs begonnen wird, lässt sich früh im Migrationsplan Erfahrung mit der Skalierung in Google Cloud sammeln. Dies kann sich als hilfreich erweisen, wenn Sie anfangen, kritischere Jobs zu migrieren.

Im folgenden Diagramm sehen Sie ein Beispiel für eine typische hybride Backfill-Architektur.

Diagramm einer typischen Architektur für Backfill in der Cloud

In diesem Beispiel gibt es zwei Hauptkomponenten. Die erste sind die geplanten Jobs, die auf dem lokalen Cluster ausgeführt werden und Daten über ein Internetgateway an Cloud Storage weiterleiten. Die zweite sind Backfill-Jobs, die auf sitzungsspezifischen Dataproc-Clustern ausgeführt werden. Außer für Backfills können sitzungsspezifische Cluster in Google Cloud zum Experimentieren und zum Erstellen von Proofs of Concept für künftige Arbeiten verwendet werden.

Im Hinblick auf die abgeschlossene Migration planen

Bisher wurde in diesem Leitfaden vorausgesetzt, dass das Ziel darin besteht, Ihr gesamtes lokales Hadoop-System in Google Cloud zu verschieben. Ein Hadoop-System, das vollständig in der Google Cloud ausgeführt wird, ist einfacher zu verwalten als eines, das sowohl in der Cloud als auch lokal arbeitet. Häufig ist allerdings ein hybrider Ansatz notwendig, damit Ihre geschäftlichen und technologischen Anforderungen erfüllt werden können.

Hybridlösung entwerfen

Hier einige Gründe, warum Sie eine Hybridlösung benötigen könnten:

  • Sie sind dabei, cloudnative Systeme zu entwickeln, sodass vorhandene Systeme, die von diesen abhängig sind, weiterhin lokal ausgeführt werden müssen, bis die Arbeiten abgeschlossen sind.
  • Es bestehen geschäftliche Anforderungen dafür, Ihre Daten lokal aufzubewahren.
  • Sie müssen Daten mit anderen, lokal ausgeführten Systemen gemeinsam nutzen, die aufgrund von technischen oder geschäftlichen Einschränkungen nicht mit Google Cloud interagieren können.

Eine typische Hybridlösung besteht aus vier Hauptteilen:

  1. Lokaler Hadoop-Cluster

  2. Verbindung vom lokalen Cluster zu Google Cloud

  3. Zentraler Datenspeicher in Google Cloud.

  4. Cloudnative Komponenten, die mit den Daten in Google Cloud arbeiten

Ein Thema, mit dem Sie sich bei einer hybriden Cloud-Lösung befassen müssen, ist die Synchronisierung Ihrer Systeme. Wie können Sie dafür sorgen, dass Änderungen, die Sie in einem System an den Daten vornehmen, im anderen ebenfalls umgesetzt werden? Sie können die Synchronisierung vereinfachen, wenn Sie klar festlegen, wie die Daten in den verschiedenen Umgebungen verwendet werden können.

Nehmen wir z. B. an, Sie haben eine hybride Lösung, in der nur Ihre archivierten Daten in Google Cloud gespeichert sind. In diesem Fall können Sie geplante Jobs einrichten, mit denen Ihre Daten von den lokalen Clustern zu Google Cloud verschoben werden, wenn die Daten ein festgelegtes Alter erreicht haben. Anschließend können Sie alle Ihre Jobs, die mit den archivierten Daten in Google Cloud arbeiten, so einrichten, dass Änderungen nicht zu Ihren lokalen Clustern synchronisiert werden müssen.

Eine weitere Möglichkeit zur Aufteilung Ihres Systems besteht im Verschieben aller Daten und Arbeiten für bestimmte Projekte oder Arbeitsgruppen zu Google Cloud, während andere Arbeiten lokal verbleiben. So können Sie sich auf Ihre Jobs konzentrieren, anstatt komplexe Systeme zur Datensynchronisierung zu erstellen.

Möglicherweise haben Sie Bedenken hinsichtlich der Sicherheit oder Logistik beim Verbinden des lokalen Clusters mit Google Cloud. Eine Lösung hierfür ist die Nutzung einer Virtual Private Cloud, die über Cloud VPN mit Ihrem lokalen Netzwerk verbunden ist.

Im folgenden Diagramm ist ein Beispiel für eine Hybrid-Cloud dargestellt:

Diagramm einer typischen hybriden Hadoop-Cloudarchitektur

In dieser Beispiel-Setup wird Cloud VPN für die Verbindung einer VPC in Google Cloud mit einem lokalen Cluster verwendet. Bei diesem System wird in der VPC Dataproc zur Verwaltung nichtflüchtiger Cluster verwendet, mit denen Daten verarbeitet werden, die aus dem lokalen System eingehen. Dies kann auch die Synchronisierung von Daten zwischen den Systemen umfassen. Über diese nichtflüchtigen Dataproc-Cluster werden außerdem die Daten, die aus dem lokalen System eingehen, an die entsprechenden Speicherdienste in Google Cloud übertragen. Zur Veranschaulichung werden in diesem Beispiel Cloud Storage, BigQuery und Bigtable zum Speichern verwendet, da es sich hierbei um die häufigsten Ziele für Daten handelt, die von Hadoop-Arbeitslasten in Google Cloud verarbeitet werden.

Auf der linken Seite der Beispiellösung sehen Sie mehrere sitzungsspezifische Cluster, die nach Bedarf in der öffentlichen Cloud erstellt werden. Diese Cluster können für zahlreiche Aufgaben verwendet werden, einschließlich Aufgaben, mit denen neue Daten erfasst und umgewandelt werden. Die Ergebnisse dieses Jobs werden in denselben Speicherdiensten abgelegt, die auch von den in der VPC ausgeführten Clustern verwendet werden.

Cloudnative Lösung entwerfen

Im Gegensatz dazu ist eine cloudnative Lösung unkomplizierter. Da Sie alle Ihre Jobs in Google Cloud unter Verwendung der in Cloud Storage gespeicherten Daten ausführen, vermeiden Sie die aufwendige Datensynchronisierung komplett. Allerdings müssen Sie weiterhin darauf achten, wie dieselben Daten von Ihren unterschiedlichen Jobs verwendet werden.

Im folgenden Diagramm ist ein Beispiel für ein cloudnatives System dargestellt:

Diagramm einer typischen cloudnativen Hadoop-Architektur.

Dieses Beispielsystem verfügt über einige nichtflüchtige und einige sitzungsspezifische Cluster. Beide Arten von Clustern nutzen Cloudtools und -ressourcen gemeinsam, einschließlich Speicher und Monitoring. Dataproc nutzt zum Definieren von Softwarekonfigurationen auf VMs in Clustern standardisierte Maschinen-Images. Diese vordefinierten Images können Sie als Grundlage für die benötigte VM-Konfiguration verwenden. In dem Beispiel werden die meisten der nichtflüchtigen Cluster mit Version 1.1 ausgeführt, auf einem Cluster läuft Version 1.2. Sie können neue Cluster mit angepassten VM-Instanzen erstellen, wann immer Sie diese benötigen. Dadurch können Sie Test- und Entwicklungsumgebungen von kritischen Produktionsdaten und -jobs isolieren.

Auf den sitzungsspezifischen Clustern in diesem Beispiel werden verschiedenste Jobs ausgeführt. Die Arbeit mit den sitzungsspezifischen Clustern wird hier mit dem Tool Apache Airflow geplant, das auf Compute Engine ausgeführt wird.

Mit Google Cloud-Diensten arbeiten

In diesem Abschnitt werden einige weitere Überlegungen für die Migration von Hadoop zu Google Cloud behandelt.

Open-Source-Tools durch Google Cloud-Dienste ersetzen

Google Cloud bietet viele Produkte, die Sie mit Ihrem Hadoop-System verwenden können. Ein Google Cloud-Produkt kann gegenüber entsprechenden Open-Source-Produkten in Google Cloud oft Vorteile haben. Informieren Sie sich über die Google Cloud-Produkte und -Dienste, um die von der Plattform gebotene Bandbreite kennenzulernen.

Regionen und Zonen verwenden

Vor dem Konfigurieren Ihrer Daten und Jobs sollten Sie die Auswirkungen von Geografie und Regionen kennen. Bei zahlreichen Google Cloud-Diensten müssen Sie die Regionen oder Zonen angeben, in denen Ressourcen zugewiesen werden sollen. Die Latenz von Anfragen kann ansteigen, wenn diese von einer anderen Region aus erfolgen als derjenigen, in der die Ressourcen gespeichert sind. Wenn sich die Ressourcen des Dienstes und Ihre nichtflüchtigen Daten außerdem in verschiedenen Regionen befinden, kann es bei manchen Aufrufen an Google Cloud-Dienste vorkommen, dass vor der Verarbeitung alle erforderlichen Daten von einer Zone in eine andere kopiert werden. Dies kann erhebliche Auswirkungen auf die Leistung haben.

Authentifizierung und Berechtigungen konfigurieren

In Google Cloud-Diensten können Sie Berechtigungen wahrscheinlich weniger detailliert steuern, als Sie es aus Ihrer lokalen Hadoop-Umgebung gewohnt sind. Informieren Sie sich über die Funktionsweise der Zugriffsverwaltung in Google Cloud, bevor Sie mit der Migration beginnen.

Der Zugriff auf Cloud-Ressourcen wird von Identity and Access Management (IAM) gesteuert. Dies funktioniert auf Grundlage von Konten und Rollen. Mit Konten werden Nutzer oder Anfragen identifiziert (Authentifizierung). Mit Rollen, die einem Konto gewährt werden, wird der Umfang des Zugriffs bestimmt (Autorisierung). Die meisten Google Cloud-Dienste haben eigene Rollen, mit denen Berechtigungen exakt zugewiesen werden können. Im Rahmen des Planungsverfahrens für die Migration sollten Sie sich darüber informieren, wie IAM mit Cloud Storage und Dataproc interagiert. Machen Sie sich mit den Berechtigungsmodellen jedes weiteren Google Cloud-Dienstes vertraut, wenn Sie Ihr System damit erweitern. Denken Sie auch darüber nach, wie Sie Rollen festlegen, die für alle von Ihnen verwendeten Dienste geeignet sind.

Jobs mit Cloud Logging überwachen

Ihre Google Cloud-Jobs senden ihre Logs an Cloud Logging, wo sie leicht zugänglich sind. Sie haben folgende Möglichkeiten zum Abrufen von Logs:

Edge-Knoten mit Compute Engine verwalten

Mit Compute Engine können Sie auf einen Edge-Knoten in einem Dataproc-Hadoop-Cluster zugreifen. Wie bei den meisten Google Cloud-Produkten haben Sie hier für die Verwaltung mehrere Optionen: über die webbasierte Konsole, über die Befehlszeile und über webbasierte APIs.

Big Data-Dienste von Google Cloud verwenden

Cloud Storage ist die erste Wahl zum Speichern von unstrukturierten Daten in Google Cloud, es handelt sich allerdings nicht um die einzige Speicheroption. Manche Ihrer Daten eignen sich vielleicht besser zum Speichern in Produkten, die speziell auf Big Data ausgelegt sind.

Mit Bigtable können Sie große Mengen von Sparse-Daten speichern. Bigtable ist eine HBase-kompatible API, die niedrige Latenz sowie hohe Skalierbarkeit zur Anpassung an Ihre Jobs bietet.

Für Data-Warehouse-Prozesse können Sie BigQuery nutzen.

Weitere Informationen