create mobile friendly website
bigdata

Big Data: Information neu gelebt (Teil III)

Apache Hadoop - auf die elefantöse Art

Apache Hadoop hat sich bereits seit einigen Jahren als zentrale Komponente in vielen Big-Data- Systemen etabliert. Um Apache Hadoop herum hat sich ein ganzes Ökosystem von Technologien entwickelt. Daher bringen wir Ihnen in diesem Artikel unserer Reihe zum Thema Big Data Apache Hadoop näher.

Apache Hadoop im Überblick

Apache Hadoop ist das bekannteste Framework für batch-orientierte Big-Data-Anwendungen und basiert auf dem 2004 von Google vorgestellten MapReduce-Programmiermodell. Apache Hadoop ermöglicht die verteilte Verar­beitung von großen Datenmengen auf einem Cluster. Hierzu werden aus handelsüblicher Hardware bestehende Rechner (Knoten) verwendet.

Hadoop wurde entwickelt, um von wenigen Knoten auf tausende nahezu linear skalieren zu können. Hierbei stellt jeder Knoten sowohl Rechenleistung als auch Speicherplatz zur Verfügung. Hadoop besteht dabei im Kern aus zwei Komponenten: MapReduce für die Berechnungen und das Hadoop Distributed File System (HDFS) für die Speicherung von großen Datenmengen.

Mit der Einführung von Hadoop 2.0 im Jahr 2012 wurde mit YARN (Yet Another Resource Negotiator) eine weitere Komponente hinzugefügt. YARN ermöglicht neben MapReduce die Ausführung weiterer Programmiermodelle wie TEZ oder Spark.

Hauptvorteil von Hadoop ist, neben der nahezu linearen Skalierbarkeit, der vereinfachte Umgang mit großen Daten­mengen. Das Hadoop Framework steuert die Daten und Berechnungen im Cluster. Wenn man all dies selbst programmieren wollte, müsste man sich unter anderem um die folgenden Dinge kümmern:

  • Koordination der Berechnungen der einzelnen Knoten
  • Koordination der Datenverteilung über die Knoten im Cluster
  • Erkennung von Fehlern
  • Neustart fehlerhafter Berechnungen
  • Sammlung und Zusammenführung
  • der Zwischenergebnisse

Hadoop bietet eine praxiserprobte, robuste Lösung für all diese Probleme. Der Aufwand der Entwicklung wird auf zwei Aufgaben reduziert: Erstens muss das Problem auf kleine Teile herunter gebrochen werden, damit es parallel in einem Cluster bearbeitet werden kann. Zweitens muss der Programmcode für diese Berechnung bereitgestellt werden.

HDFS als Dateisystem von Hadoop bietet theoretisch unbegrenzten Speicherplatz. Daher hat sich um Hadoop ein ganzes Ökosystem von Technologien gebildet, um den Umgang mit großen Datenmengen weiter zu vereinfachen. Einige Technologien aus diesem Ökosystem werden wir in einem kommenden Artikel dieser Reihe näher betrachten.

MapReduce

MapReduce wurde von Google entwickelt und in einem Artikel 2004 erstmals öffentlich vorgestellt [Q1]. Zweck der Aufteilung in drei Phasen ist die Verteilung der Berechnung auf mehrere Rechner für eine parallele Verarbeitung.

Während der Map-Phase werden die Eingabedaten auf mehrere Map-Tasks aufgeteilt. Die Map-Tasks verwenden den vom Entwickler bereitgestellten Programmcode und laufen parallel ab. Die Map-Funktion verarbeitet eine Menge von Key/Value-Paaren und erzeugt hieraus eine Reihe der Paare. Diese Paare stellen ein Zwischen­ergebnis dar.

Die Zwischenergebnisse werden in der Shuffle-Phase je nach Zweck der Aufgabe in einem gemeinsamen oder in mehreren Zwischenspeichern abgelegt. Alle Key/Value-Paare mit gleichem Schlüsselwert werden immer in demselben Zwischenspeicher abgelegt. Die Anzahl der Zwischenspeicher ist durch die Zahl der im nachfolgenden Schritt zu startenden Reduce-Prozesse begrenzt. Für jeden zu startenden Reduce-Prozess wird ein Zwischenspeicher angelegt.

Während der Reduce-Phase wird für jeden Zwischenspeicher ein Reduce-Task gestartet. Jeder Reduce-Task berechnet aus den Zwischenergebnissen eine Liste von Endergebniswerten, die in der Ausgabeliste als Key/Value-Paare gesammelt werden.

In letzter Zeit ist der Ansatz von MapReduce deutlich in die Kritik geraten, da er einige wesentliche Nachteile hat. Zum einen ist MapReduce durch seinen Aufbau in eine Map- und eine Reduce-Funktion nicht sehr flexibel. Zum anderen ist der MapReduce-Ansatz batch-orientiert und eignet sich nicht für Anwendungen, zu deren Anforde­rungen kurze Antwortzeiten gehören. Ein Flaschenhals ist zudem der Übergang von der Map- in die Reduce-Phase. Hier werden die Zwischenergebnisse der Map-Prozesse in Dateien gespeichert und über das Netzwerk an den Knoten, der die Reduce-Prozesse ausführt, gesendet. Neuere Ansätze verzichten auf die Zwischenspeicherung in Dateien und erledigen möglichst alle Verarbeitungen im Hauptspeicher. Dennoch bildet MapReduce immer noch den Einstieg in die Big-Data-Welt. Zudem können MapReduce-Jobs in der Regel problemlos auf neuere Ansätze, wie z. B. Apache Spark, portiert werden.

YARN – Yet Another Resource Negotiator

YARN ist ein Ressourcenmanagementsystem für Hadoop. Eingeführt wurde es mit Hadoop 2.0, um die MapReduce-Implementierung in Hadoop zu verbessern. YARN ist aber nicht auf MapReduce beschränkt, sondern unterstützt auch andere Modelle zur verteilten Berechnung. YARN stellt eine API zur Verfügung, welche es ermöglicht, Ressourcen (Rechenkapazität und Speicherplatz) aus dem Hadoop Cluster anzufordern um damit zu arbeiten. Die API wird vom Benutzercode in der Regel nicht verwendet.

Benutzer schreiben Programmcode für higher-level APIs. Diese werden von Frameworks zur verteilten Berechnung, wie z. B. MapReduce, bereitgestellt. Die Frameworks wiederum nutzen dann die YARN-API.

Dies führt zu dem drei­schichtigen Modell: Die unterste Ebene ist für die Speicherung zuständig und wird durch HDFS realisiert. Die nächste Ebene ist die Berechnungsebene. Auf der dritten Ebene sind die Frameworks für verteilte Berechnungen, wie MapReduce, Spark oder TEZ. Applikationen wie Hive oder Pig, setzen auf MapReduce, Spark oder TEZ auf und wären in einem solchen Modell auf der vierten Ebene zu finden.

YARN stellt zwei Arten von Diensten zur Verfügung: Resource- und Node-Manager. Der Resource Manager verwaltet die Ressourcen des Cluster. Node Manager laufen auf jedem Knoten des Cluster und starten und überwachen die Container. Ein Container gewährt einer Anwendung Rechte, um eine bestimmte Menge an Ressourcen (Speicher, CPU etc.) auf einem bestimmten Knoten zu verwenden. Ein Container ist somit eine Art virtuelle Maschine für die Ausführung einer Aufgabe auf einem Cluster-Knoten. Für jeden im Cluster laufenden Job wird ein Application Master Container gestartet. Dieser führt den applikationsspezifischen Code entweder selbst aus oder er fordert vom Resource Manager weitere Application Container auf anderen Knoten an. Die Application Container führen dann den Code auf einem Teil der zu verarbeitenden Daten aus und werden dabei vom Application Master überwacht.

Die Vorteile von YARN

Durch die Einführung von YARN ist die Skalierbarkeit verbessert worden. YARN kann auf größeren Clustern laufen als MapReduce 1, da bei MapReduce 1 der Job Tracker einen auf die Skalierbarkeit begrenzenden Flaschenhals darstellt. Durch den Job Tracker ist die Cluster-Größe in MapReduce 1 auf ca. 4.000 Knoten begrenzt. Bei YARN verwaltet ein Resource Manger die Jobs. Die einzelnen Tasks werden von jeweils einem Application Master pro Job verwaltet.

Eine bessere Benutzbarkeit wurde durch die flexiblere Ressourcenanforderung erreicht. Der Client kann zum einen die benötigten Ressourcen genauer spezifizieren. Zum anderen musste in MapReduce 1 die Zahl der be­nötig­ten Knoten des Cluster für einen MapReduce Job vor Jobstart angegeben werden. Mit YARN können nun weitere Container zur Laufzeit nachgefordert werden.

Größter Vorteil von YARN ist aber die nun vorhandene Offenheit von Hadoop gegenüber anderen Frameworks zur verteilten Berechnung. In MapReduce 1 wurde nur MapReduce als Framework unterstützt. Andere Frameworks wie z. B. Spark oder TEZ werden nun ebenfalls unterstützt. Vor der Einführung von YARN nutzten diese Frameworks nur HDFS als persistenten Speicher. Nun können sie auch Hadoop zur Ausführung ihres Programmcodes nutzen.

HDFS - Hadoop Distributed File System

HDFS ist das primäre Dateisystem von Hadoop. Es basiert auf dem Konzept des 2003 von Google vorgestellten Google File System. Als verteiltes Dateisystem erstreckt es sich über mehrere Rechner, ist netzwerkbasiert und ermöglicht die Speicherung von Dateien, die auf einem einzelnen Rechner aufgrund ihrer Größe nicht mehr gespeichert werden können.

HDFS besteht im Kern aus Knoten mit zwei unterschiedlichen Rollen: Dem Name Node und den Data Nodes. Diese orientieren sich an dem Master/Slave-Prinzip: Die Data Nodes sind die „Arbeitspferde“: Sie speichern die Daten und führen den MapReduce-Algorithmus aus. Die Name Nodes hingegen speichern die Metadaten der Dateien und Informationen, auf welchem Data Node diese zu finden sind.

Dateien werden in HDFS in Blöcke aufgeteilt. Diese Blöcke werden dann auf mehrere Data Nodes verteilt und gespeichert. In einem Dateisystem bilden Blöcke üblicherweise die kleinste Speichereinheit. Während in „General Purpose“-Dateisystemen die Blockgrößen üblicherweise im niedrigen Kilobyte-Bereich liegen, ist in HDFS die Blockgröße von 128 Megabyte der aktuelle Standard. Durch diese großen Blöcke werden der Verwaltungsaufwand und die Suchzeit in HDFS für den einzelnen Block reduziert. Durch die Aufgabenverteilung zwischen dem Name Node und den Data Nodes wird zudem eine, in verteilten Dateisystemen vorteilhafte, Blockabstraktion erreicht. Zum einen kann eine einzelne Datei größer werden als die größte Festplatte des Dateisystems. Zum anderen wird eine Vereinfachung des Speicher-Sub­systems erreicht: Das Subsystem wird aufgrund seiner geringeren Komplexität weniger fehleranfällig. Es müssen keine Berechtigungsinformationen (Metadaten) auf Block­ebene gespeichert werden. Diese können zentral im Data Node verwaltet werden. Die Blockabstraktion vereinfacht zudem die Replikation. Einfache Blockkopien werden verteilt, um einen Datenverlust durch Hardwarefehler zu vermeiden. Standardmäßig wird jeder Block auf drei verschiedenen Data Nodes gespeichert.


Die auf dem Name Node persistent gespeicherten Daten (Zuordnung zwischen Block-ID und Dateiname sowie die Metadaten wie z. B. der Eigentümer der Datei) müssen gesichert werden. Gehen diese verloren, gibt es keine Möglichkeit der Wiederherstellung. Zudem stellt der Name Node des HDFS-Cluster einen Single Point of Failure dar. Um den Verfügbarkeitsgrad zu erhöhen, kann z. B. ein Secondary Name Node verwendet werden.

Fazit

Apache Hadoop ist quasi der Standard für batch-orientierte Big-Data-Anwendungen. In diesem Artikel konnte nur ein Überblick über dessen grundlegende Eigen­schaften gegeben werden. Sollten Sie an einer tiefergehenden Einarbeitung in dieses Thema interessiert sein empfiehlt sich besonders das Buch von Tom White [Q2] oder der Besuch unseres dreitägigen Seminars Big Data: Apache Hadoop Grundlagen (siehe unten).

Philipp Loer
()

Kostenloses Kundenmagazin

Abbildungen


Die vollständigen Artikel mit allen Abbildungen finden Sie im blätterbaren PDF.
Eine Übersicht über alle Artikel sowie das PDF zum Download finden Sie im Inhaltsverzeichnis.

Impressum


Impressum der ORDIX® news 3/2015

Links


[1] ORDIX® news Artikel 1/2015 –
„Big Data – Informationen neu gelebt (Teil I) - Wie big ist Big Data?“
[2] ORDIX® news Artikel 2/2015 –
„Big Data – Informationen neu gelebt (Teil II) -Apache Cassandra“
[3] Welcome to Apache™ Hadoop®!

Quellen


[Q1] Dean, Jeffrey und Sanjay Ghemawat (2004), „MapReduce: Simplifed
Data Processing on Large Clusters "
[Q2] White, Tom „Hadoop: The Definitive Guide“ 4. Aufl. Sebastopol, California:
O’Reilly Media, 2015

Bildnachweis


© pixabay.com | Etosha Elephant | Martin Fuchs
© enchantedwhispersart.deviantart.com | Premade-Winter