Migration von HDFS auf Objektspeicher

Die Migration von HDFS auf Objektspeicher gehört zu den häufigsten Datenplattform-Projekten der letzten Jahre. Organisationen, die vor einem Jahrzehnt Hadoop-Cluster aufgebaut haben, stehen heute vor alternder Hardware, eng gekoppelter Rechen- und Speicherleistung, komplexem Betrieb und mitunter veränderter Herstellerunterstützung. Die Verlagerung von Daten aus dem Hadoop Distributed File System auf S3-kompatiblen Objektspeicher trennt Speicher und Rechenleistung, öffnet die Tür zu modernen Engines und Tabellenformaten und vereinfacht den Betrieb. Zugleich ist es ein großes, heikles Projekt, oft mit Petabytes an Daten und Hunderten von Jobs, die HDFS-Verhalten voraussetzen.

Dieser Artikel erklärt, warum Organisationen von HDFS auf Objektspeicher wechseln, welche Unterschiede wichtig sind, welche Migrationsansätze und Tools es gibt, wie mit Tabellen, Sicherheit und Validierung umzugehen ist und wie das Projekt in Phasen gegliedert wird. Die Zielarchitektur beschreibt unsere Übersicht zum Betrieb eines Data Lakehouse auf On-Premises-Objektspeicher.

Warum weg von HDFS

Gekoppelte Rechen- und Speicherleistung: HDFS speichert Daten auf denselben Knoten, auf denen gerechnet wird. Mehr Speicher bedeutet also mehr Rechenleistung und umgekehrt.
Replikations-Overhead: HDFS hält traditionell drei Replikate der Daten und verdreifacht so die Rohkapazität. Erasure Coding in neueren HDFS-Versionen hilft, erhöht aber die Komplexität. Objektspeicher nutzt Erasure Coding in der Regel nativ.
Betriebliche Komplexität: Hochverfügbarkeit des NameNode, Balancing, Upgrades und die Versionsverwaltung des Ökosystems erfordern Spezialwissen.
Grenzen des NameNode: Die HDFS-Metadaten liegen im Arbeitsspeicher des NameNode, was die Zahl der Dateien begrenzt und kleine Dateien teuer macht.
Moderne Engines: Verteilte Query- und Processing-Engines, oft auf Container-Plattformen, arbeiten von Natur aus mit S3-kompatiblem Speicher und offenen Tabellenformaten.
Hardware-Erneuerung: Alternde Hadoop-Cluster sind eine Gelegenheit, die Architektur zu ändern, statt Gleiches durch Gleiches zu ersetzen.

Wesentliche Unterschiede zwischen HDFS und Objektspeicher

Umbenennungen

In HDFS sind Umbenennungen schnelle, atomare Metadatenoperationen, und viele Hadoop-Jobs schreiben in ein temporäres Verzeichnis und benennen es am Ende um. Objektspeicher bietet keine atomaren Verzeichnisumbenennungen; Umbenennen bedeutet Kopieren und Löschen von Objekten. Jobs müssen für Objektspeicher ausgelegte Committer verwenden, etwa die S3A-Committer in Hadoop, oder offene Tabellenformate, die Umbenennungen ganz vermeiden.

Verzeichnislisten

HDFS listet Verzeichnisse schnell. Bei Objektspeicher können Listen für sehr große Präfixe langsamer sein. Tabellenformate, die Dateien in Metadaten statt über Listen verfolgen, umgehen dieses Problem.

Berechtigungen

HDFS nutzt POSIX-ähnliche Berechtigungen und oft Ranger- oder Sentry-Richtlinien. Objektspeicher nutzt Bucket- und Objektrichtlinien und IAM-artige Identitäten. Die Zugriffsmodelle müssen abgebildet und neu gestaltet werden.

Datenlokalität

Hadoop brachte die Rechenleistung zu den Daten auf denselben Knoten. Bei Objektspeicher liest die Rechenleistung Daten über das Netzwerk, sodass die Netzwerkbandbreite zwischen Rechen- und Speicherebene entscheidend wird.

Migrationsansätze

Lift and Shift mit DistCp

Das Hadoop-Tool DistCp kopiert Daten über den S3A-Connector parallel von HDFS auf S3-kompatiblen Speicher. Es ist der Standardweg für große Volumen und lässt sich inkrementell ausführen, um Änderungen nachzuziehen. Planen Sie die Bandbreite und führen Sie Kopien in Chargen nach Datensatz aus.

Modernisierung Tabelle für Tabelle

Statt Dateien blind zu kopieren, migrieren Sie Tabellen in ein modernes Format. Verzeichnisbasierte Altbestände lassen sich in ein offenes Tabellenformat umwandeln, entweder durch Registrierung der vorhandenen Dateien an Ort und Stelle oder durch Anlegen neuer Tabellen und Kopieren der Daten. Die meisten offenen Tabellenformate bieten Verfahren, um Tabellen aus vorhandenen Datendateien zu erstellen.

Hybride Übergangsphase

Die meisten Migrationen betreiben HDFS und Objektspeicher eine Zeit lang parallel. Jobs werden Datensatz für Datensatz auf Lesen und Schreiben im Objektspeicher umgestellt, während HDFS verfügbar bleibt, bis alle Workloads umgezogen sind.

Workloads migrieren, nicht nur Daten

Die Daten sind nur die halbe Migration. Jeder Job, jede Pipeline und jede Abfrage muss angepasst werden:

Pfade: hdfs://-Pfade für jede Engine auf s3a:// oder das Äquivalent umstellen.
Committer: Objektspeicher-Committer für Processing-Jobs aktivieren, die Ausgaben schreiben.
Konfiguration: Endpunkte, Path-Style-Zugriff, Zugangsdaten und TLS für jede Engine.
Engine-Upgrades: Viele Teams wechseln gleichzeitig von älteren Batch-Engines zu modernen verteilten SQL- und Processing-Engines.
Scheduling: die Orchestrierung so anpassen, dass Jobs auf die neuen Orte zeigen.

Erstellen Sie früh ein Verzeichnis der Jobs und ihrer Abhängigkeiten; das dauert meist länger als die Datenverlagerung.

Sicherheit und Governance

Bilden Sie HDFS-Benutzer, -Gruppen und -Richtlinien auf Identitäten und Bucket-Richtlinien des Objektspeichers ab. Legen Sie das Bucket-Layout nach Domäne oder Sensibilität fest, wenden Sie Verschlüsselung und Audit-Logging an und integrieren Sie bestehende Identity Provider. Werden Ranger oder ähnliche Tools für feingranularen Zugriff genutzt, prüfen Sie deren Integration mit den neuen Engines und dem Speicher. S3-Zugriffsrichtlinien behandelt das Design von Richtlinien.

Die Migration validieren

Von HDFS berechnete Prüfsummen sind nicht direkt mit den ETags des Objektspeichers vergleichbar, insbesondere bei Multipart-Uploads. Ansätze zur Validierung sind:

Dateianzahl und -größen pro Datensatz und Partition.
Inhalts-Hashes, für kritische Datensätze unabhängig auf Quell- und Zieldateien berechnet.
Zeilenzahlen und Aggregate für Tabellen, durch Vergleich der Abfrageergebnisse auf Quelle und Ziel.
Vergleich der Job-Ausgaben während paralleler Läufe.

Dokumentieren Sie die Validierungsergebnisse für Audits, besonders in regulierten Umgebungen.

Umgang mit kleinen Dateien und kalten Daten

Hadoop-Umgebungen enthalten oft enorme Mengen kleiner Dateien aus Streaming-Jobs, Logs und schlecht konfigurierten Pipelines. Werden sie unverändert in den Objektspeicher kopiert, wandert das Problem mit – mit mehr Anfragen und langsameren Abfragen. Eine Migration ist ein guter Zeitpunkt, kleine Dateien zu größeren zusammenzufassen, entweder beim Kopieren oder bei der Umwandlung der Tabellen in ein offenes Tabellenformat. Auch kalte Daten, die seit Jahren nicht gelesen wurden, verdienen einen genauen Blick: Manche können mit Lifecycle-Regeln in eine günstigere Ebene oder einen eigenen Bucket wandern, manche lassen sich gemäß Aufbewahrungsrichtlinie löschen, statt sie zu migrieren. Weniger zu verlagern verkürzt das Projekt und senkt die Kosten der Zielplattform.

Bandbreite und Kopierzeit

Planen Sie die Kopierzeit realistisch. 5 PB bei dauerhaft 10 GB pro Sekunde zu verschieben dauert etwa sechs Tage ununterbrochener Übertragung, und die realen Raten liegen meist niedriger, sobald Produktions-Workloads, Validierung und Wiederholungen hinzukommen. Viele Teams planen Kopien über mehrere Monate für Nächte und Wochenenden und priorisieren heiße Datensätze, damit die meistgenutzten Workloads früh umziehen können. Inkrementelle DistCp-Läufe ziehen vor jeder Umstellung die Änderungen nach.

Kompetenzen und Teams

Der Wechsel von Hadoop zu einem Lakehouse verändert neben der Technik auch die Kompetenzen. Hadoop-Administratoren werden zu Platform Engineers, die Objektspeicher, Container-Plattformen und moderne Engines betreiben. Data Engineers übernehmen offene Tabellenformate und neue Tools. Planen Sie Schulungen früh und beziehen Sie das Betriebsteam in das Pilotprojekt ein, damit es die neue Plattform betreiben kann, bevor die alte abgeschaltet wird.

Das Projekt in Phasen gliedern

Bewerten: Daten, Tabellen, Jobs, Benutzer und Abhängigkeiten erfassen; kalte Daten identifizieren, die nicht umziehen müssen.
Aufbauen: Objektspeicher, Netzwerk, Engines und Katalog bereitstellen.
Pilotieren: einen nicht kritischen Datensatz samt Jobs vollständig migrieren.
In Wellen migrieren: Datensätze und Jobs nach Domäne verlagern und jede Welle validieren.
Umstellen: verbleibende Workloads umschalten und Schreibvorgänge in HDFS einfrieren.
Abschalten: HDFS nach einer festgelegten Sicherheitsfrist außer Betrieb nehmen.

Das Ziel dimensionieren

Dimensionieren Sie den Objektspeicher für die migrierten Daten zuzüglich Wachstum, mit dem Overhead von Erasure Coding statt der dreifachen HDFS-Replikation. Viele Organisationen stellen fest, dass sie nach dem Wechsel von dreifach repliziertem HDFS deutlich weniger Rohkapazität benötigen. Dimensionieren Sie die Netzwerkbandbreite für analytische Scanraten, da die Rechenleistung nicht mehr von lokalen Festplatten liest.

Regionale und regulatorische Aspekte

Viele Hadoop-Umgebungen gehören Banken, Telekommunikationsanbietern, Behörden und Versorgern mit strengen Vorgaben zum Speicherort. Eine Migration auf On-Premises-Objektspeicher hält die Daten im Land und modernisiert zugleich die Plattform – ohne die regulatorische Prüfung, die ein Umzug in eine ausländische Public Cloud auslösen könnte.

Checkliste: Migration von HDFS auf Objektspeicher

Daten, Tabellen, Jobs, Benutzer und Abhängigkeiten erfassen.
Entscheiden, welche Daten migriert, archiviert oder gelöscht werden.
Zwischen Lift and Shift und Modernisierung der Tabellen wählen – oft beides.
Objektspeicher-Committer aktivieren oder auf ein offenes Tabellenformat wechseln.
Berechtigungen auf Bucket-Richtlinien und Identitäten abbilden.
Netzwerkbandbreite zwischen Rechen- und Speicherebene dimensionieren.
Daten mit DistCp oder Tools auf Tabellenebene in Wellen kopieren.
Mit Zählungen, Hashes und Abfragevergleichen validieren.
HDFS und Objektspeicher während des Übergangs parallel betreiben.
HDFS nach einer Sicherheitsfrist abschalten.

Zusammenfassung

Die Migration von HDFS auf Objektspeicher trennt Speicher und Rechenleistung, verringert den Replikations-Overhead und ermöglicht moderne Engines und Tabellenformate. Die größte Herausforderung ist nicht das Kopieren der Bytes, sondern die Anpassung der Workloads an die Semantik des Objektspeichers, die Neugestaltung der Sicherheit und die Validierung der Ergebnisse. Erfassen Sie sorgfältig, migrieren Sie in Wellen, nutzen Sie Committer oder offene Tabellenformate gegen Probleme mit Umbenennungen, dimensionieren Sie das Netzwerk richtig und halten Sie HDFS verfügbar, bis jeder Workload umgezogen und geprüft ist.

Häufig gestellte Fragen

Warum von HDFS auf Objektspeicher migrieren?

Um Rechenleistung und Speicher zu trennen, den Replikations-Overhead zu senken, den Betrieb zu vereinfachen und moderne Engines und Tabellenformate einzuführen.

Welches Tool kopiert Daten von HDFS auf S3-kompatiblen Speicher?

Hadoop DistCp mit dem S3A-Connector ist das Standardwerkzeug, parallel und inkrementell ausgeführt.

Laufen Hadoop-Jobs unverändert auf Objektspeicher?

Oft nicht. Pfade, Committer, Konfiguration und mitunter Engines müssen sich ändern, besonders bei Jobs, die auf Umbenennungen angewiesen sind.

Wie validiert man eine HDFS-Migration?

Dateianzahl und -größen vergleichen, für kritische Daten unabhängige Inhalts-Hashes berechnen und Zeilenzahlen sowie Abfrageergebnisse von Tabellen vergleichen.

Brauche ich nach der Migration weniger Kapazität?

Oft ja, weil Objektspeicher in der Regel Erasure Coding statt der dreifachen HDFS-Replikation nutzt.

Wie migrieren Sie von Hadoop HDFS auf Objektspeicher?