Begriff

Hadoop

Big Data Infrastructure S3

2 Quellen 0 Lernpfade 0 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Früher war eine Festplatte 1 TB groß. Wenn du 10 TB Daten hattest, musstest du eine riesige, teure Spezial-Festplatte kaufen. Hadoop sagte: "Unsinn. Wir nehmen einfach 10 billige PCs vom Aldi, stöpseln sie zusammen, und tun so, als wären sie ein riesiger Computer." Das Herzstück ist HDFS (Hadoop Distributed File System). Wenn du eine Datei speicherst, zerhackt Hadoop sie in Blöcke und verteilt sie auf die PCs. Wenn ein PC kaputt geht (passiert bei Aldi-PCs oft), ist das egal. Die Daten liegen noch doppelt auf den anderen.

Merksatz: Ein Open-Source-Framework, das es ermöglicht, riesige Datenmengen auf Clustern von Standard-Hardware zu speichern (HDFS) und zu verarbeiten (MapReduce).

1. The HDFS Data Replication Pipeline & Rack Awareness

Die Brillianz von Hadoop ist nicht Storage, sondern Topologie-Intelligenz. Wenn HDFS einen 128 MB Block speichert (Replication Factor 3), schreibt es ihn nicht dumpf dreimal weg. Die NameNode erzwingt Rack Awareness: Replika 1 geht in das lokale Server-Rack (Speed). Replika 2 geht in ein physisch anderes Rack (Disaster Recovery für Fall eines lokalen Switch- oder Strom-Ausfalls). Replika 3 landet in demselben Remote-Rack, um Off-Rack Bandbreite nicht unnötig zu killen. Das System nutzt den Dijkstra-Algorithmus auf dem internen Cluster-Graphen, um diese Distribution mathematisch auf Latenz und Ausfallsicherheit zu optimieren.

2. MapReduce und Data Locality

Der Heilige Gral der Data-Science der 2000er: "Bringe den Code zu den Daten, nicht die Daten zum Code." In klassischen SQL-DBs lädt die CPU die Daten vom SAN in den RAM (Netzwerk-Bottleneck). Hadoop schickt die kompilierten Java-Jobs (.jar) aktiv an die Server im Clusternetzwerk, auf deren drehenden Platten die exakten HDFS-Partitionen liegen. Die Node verarbeitet strikt nur lokale Daten (Map-Phase). Nur the finale Ergebnis-Meta (Reduce) geht ans Netzwerk (Shuffle & Sort Phase). Diese radikale Müll-Reduktion beim RAM-Transport brach alle Enterprise-Performance-Monopolien von Oracle Big Data Rigs.

3. YARN Container und cgroups

Als Hadoop wuchs, blockierten fehlerhafte Jobs der Analysten den Cluster (OOM Kills). Hadoop 2.0 spaltete Architektur in YARN (Resource Manager) auf. YARN orchestriert keine Prozesse, sondern Linux cgroups Containers (Prä-Docker-Ära). Ein Spark-Job reserviert via ResourceManager streng "4 vCores, 8 GB RAM" auf der NodeManager Ebene. YARN isoliert dies physisch im Kernel. Wenn der Spark Executor Amok läuft und 9 GB will, wird nur dieser CGroup Container vom Linux Out-Of-Memory Manager erschossen – ohne den vitalen benachbarten HDFS-DataNode-Prozess auf selbiger Hardware in den Tod zu reißen.

Quick-Check

Was ist der Elefant?
Das Logo. Der Erfinder (Doug Cutting) benannte das Projekt nach dem gelben Stoff-Elefanten seines Sohnes.
Ist Hadoop tot?
Der Hype ist vorbei. Viele wechseln zu S3 (Cloud Object Storage) statt HDFS. Aber in großen On-Premise-Firmen (Banken) ist es immer noch der Standard für Data Lakes.
Ist es schnell?
Nein. Es ist für Durchsatz (Terabytes pro Stunde) optimiert, nicht für Latenz (Millisekunden). Wer Speed will, nimmt Spark.