Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- bigdata:hadoop [2015/10/05 20:51] – [Hadoop Distributed File System] brueck
+++ bigdata:hadoop [2015/10/05 20:55] – [YARN] brueck
@@ Zeile 39: / Zeile 39: @@
-==== MapReduce ====
+===== MapReduce =====
 Eine der Ideen, die Hadoop zugrunde liegen, ist, dass es effektiver ist, Berechnungen zu den Daten zu bringen, anstatt Die Daten zu verschieben, dass also Applikationen, die mit einem großen Datenvolumen arbeiten auch in der Nähe dieser Daten zur Ausführung gebracht werden, um zeitintensives Verschieben der Daten durch das Netzwerk zu vermeiden. Dies geschieht nach dem Vorbild von [[bigdata:mapreduce|Googles MapReduce-Framework]], was zwei Phasen der verteilten Verarbeitung beinhaltet: eine **Map**-Phase, in der die Datenknoten ermittelt werden, die die geforderten Daten gespeichert haben und die Arbeitslast auf ebendiese Knoten verteilt wird; und eine **Reduce**-Phase, in der die Zwischenergebnisse zusammengeführt und verarbeitet werden.
@@ Zeile 46: / Zeile 46: @@
 MapReduce-Operationen laufen im Wesentlichen in drei Schritten ab:
-=== Map ===
-Zunächst wird ein Inputfile (typischerweise vom HDFS) geladen, in **FileSplits** aufgeteilt und auf unterschiedliche Knoten verteilt. Dies erlaubt eine effiziente Verarbeitung auch sehr großer Inputfiles durch die massiv verteilte, parallele Arbeit der Mapper, die auf je einem solchen Split zum Einsatz kommen. Dabei geht das Splitting nach Bytelänge vor und weiß nichts über die interne Struktur der Dateien ([[bigdata:literatur|Taggart 2011]]). Für jeden FileSplit wird dann eine **Map**-Operation gestartet. Über den **RecordReader** liest ein Map-Task dann seinen FileSplit ein und wandelt ihn in Key-Value-Paare um ([[bigdata:literatur|Yahoo o. J.]]). Diese Paare werden dann von der benutzerdefinierten Map-Funktion gelesen und ihrer Programmierung entsprechend zu neuen Key-Value-Paaren verarbeitet, die vom **OutputCollector** dann an die Reducer geleitet werden. Die Paare werden nach ihren Schlüsseln in Subsets (oder auch „**Partitionen**“) gruppiert. Jeder Reducer erhält dabei ein eigenes Subset der Schlüsselwerte, damit er nur die Werte einer einzigen Schlüsselgruppe zusammenfassen kann. Dieser Vorgang der Verteilung der Mapper-Outputs an die Reducer wird als „Shuffling“ bezeichnet.
+==== Map ====
+Zunächst wird ein Inputfile (typischerweise vom HDFS) geladen, in **FileSplits** aufgeteilt und auf unterschiedliche Knoten verteilt. Dies erlaubt eine effiziente Verarbeitung auch sehr großer Inputfiles durch die massiv verteilte, parallele Arbeit der Mapper, die auf je einem solchen Split zum Einsatz kommen. Dabei geht das Splitting nach Bytelänge vor und weiß nichts über die interne Struktur der Dateien ([[bigdata:literatur#t|Taggart 2011]]). Für jeden FileSplit wird dann eine **Map**-Operation gestartet. Über den **RecordReader** liest ein Map-Task dann seinen FileSplit ein und wandelt ihn in Key-Value-Paare um ([[bigdata:literatur#y|Yahoo o. J.]]). Diese Paare werden dann von der benutzerdefinierten Map-Funktion gelesen und ihrer Programmierung entsprechend zu neuen Key-Value-Paaren verarbeitet, die vom **OutputCollector** dann an die Reducer geleitet werden. Die Paare werden nach ihren Schlüsseln in Subsets (oder auch „**Partitionen**“) gruppiert. Jeder Reducer erhält dabei ein eigenes Subset der Schlüsselwerte, damit er nur die Werte einer einzigen Schlüsselgruppe zusammenfassen kann. Dieser Vorgang der Verteilung der Mapper-Outputs an die Reducer wird als „Shuffling“ bezeichnet.
 Es stehen einige Inputformate zur Verfügung:
@@ Zeile 55: / Zeile 56: @@
 | KeyValueInputFormat    | Parst Zeilen in Key-Value-Paare       | Alles bis zum ersten Tab-Zeichen | Rest der Zeile    |
 | SequenceFileInputFormat| Hadoop-spezifisches Binärformat       | Benutzerdefiniert                | Benutzerdefiniert |
-(Nach [[bigdata:literatur|Yahoo o. J.]])
+(Nach [[bigdata:literatur#y|Yahoo o. J.]])
-=== Combine ===
+==== Combine ====
-Die Combine-Phase ist eine optionale Phase, die zu Optimierungszwecken verwendet werden kann. Sie findet nach dem Mapper und vor dem Shuffle statt, also bevor der Output der Map-Phase vom Hauptspeicher auf Disk geschrieben wird. Der **Combiner** wird auch als „Lokaler Reducer“ bezeichnet, da er nur auf den Daten einer Maschine arbeitet. Dabei werden die Key-Value-Paare der Map-Phase nach dem Schlüssel zusammengefasst und die Werte entsprechend zusammengerechnet. Auf diese Weise kann die Datenmenge noch einmal reduziert werden. Der Output des Combiners wird dann als Input an den Reducer übergeben. (Vgl. [[bigdata:literatur|Dean/Ghemwat 2004: S. 6]]; [[bigdata:literatur|Yahoo o. J.]])
+Die Combine-Phase ist eine optionale Phase, die zu Optimierungszwecken verwendet werden kann. Sie findet nach dem Mapper und vor dem Shuffle statt, also bevor der Output der Map-Phase vom Hauptspeicher auf Disk geschrieben wird. Der **Combiner** wird auch als „Lokaler Reducer“ bezeichnet, da er nur auf den Daten einer Maschine arbeitet. Dabei werden die Key-Value-Paare der Map-Phase nach dem Schlüssel zusammengefasst und die Werte entsprechend zusammengerechnet. Auf diese Weise kann die Datenmenge noch einmal reduziert werden. Der Output des Combiners wird dann als Input an den Reducer übergeben. (Vgl. [[bigdata:literatur#d|Dean/Ghemwat 2004: S. 6]]; [[bigdata:literatur#y|Yahoo o. J.]])
-=== Reduce ===
+==== Reduce ====
-Wenn die Map-Phase abgeschlossen ist, müssen die entstandenen Zwischenergebnisse (Key-Value-Paare), die nun lokal auf ihren Knoten vorliegen, so im Cluster ausgetauscht werden, dass alle Werte mit demselben Schlüssel zu einem Reducer geleitet werden. Dieser Vorgang stellt den einzigen Kommunikationsschritt der Maschinen im MapReduce dar, da ansonsten alle Mapper und Reducer getrennt und unabhängig voneinander parallel auf ihrem eigenen Datenbestand arbeiten ([[bigdata:literatur|Yahoo o. J.]]). Nach einem Sortieren der Map-Erzeugnisse, kommt die vom Programmierer definierte Reduce-Funktion darauf zum Einsatz. Wertepaare mit demselben Schlüssel werden dabei aufsummiert. Das Ergebnis ist ein Output-File pro Reduce-Task auf der lokalen Platte oder im HDFS ([[bigdata:literatur|Yahoo o. J.]]).
+Wenn die Map-Phase abgeschlossen ist, müssen die entstandenen Zwischenergebnisse (Key-Value-Paare), die nun lokal auf ihren Knoten vorliegen, so im Cluster ausgetauscht werden, dass alle Werte mit demselben Schlüssel zu einem Reducer geleitet werden. Dieser Vorgang stellt den einzigen Kommunikationsschritt der Maschinen im MapReduce dar, da ansonsten alle Mapper und Reducer getrennt und unabhängig voneinander parallel auf ihrem eigenen Datenbestand arbeiten ([[bigdata:literatur#y|Yahoo o. J.]]). Nach einem Sortieren der Map-Erzeugnisse, kommt die vom Programmierer definierte Reduce-Funktion darauf zum Einsatz. Wertepaare mit demselben Schlüssel werden dabei aufsummiert. Das Ergebnis ist ein Output-File pro Reduce-Task auf der lokalen Platte oder im HDFS ([[bigdata:literatur#y|Yahoo o. J.]]).
 Das OutputFormat kann dabei bestimmt werden, ähnlich wie das InputFormat:
@@ Zeile 69: / Zeile 70: @@
 | SequenceFileOutputFormat | Schreibt binäre Files für das Lesen in darauffolgenden MapReduce-Jobs |
 | NullOputFormat           | Lässt seine Inputs außer Acht (erzeugt keinen MapReduce-Output)       |
-(Nach [[bigdata:literatur|Yahoo o. J.]])
+(Nach [[bigdata:literatur#y|Yahoo o. J.]])
-==== YARN ====
+===== YARN =====
 **YARN** steht für „**Y**et **A**nother **R**esource **N**egotiator“ („noch ein Ressourcen-Vermittler“) oder auch **MapReduce 2.0** (**MRv2**) und kam als wichtigste neue Komponente des Hadoop 2 Upgrades und übernimmt den Part des Ressourcen-Managements und Job-Schedulings und kommt so als Nachfolger des MapReduce-Frameworks daher. Es bildet eine neue Abstraktionsschicht, die das Cluster-Ressourcen-Management von der Datenverarbeitung durch MapReduce trennt, sodass MapReduce zwar weiterhinals Verarbeitungsmodell verwendet werden kann, aber daneben nun auch andere Alternativen verfügbar werden.
 {{ bigdata:yarn.png?650 }}
-(Bild-Quelle: [[bigdata:literatur|Sullivan 2014]])
+(Bild-Quelle: [[bigdata:literatur#s|Sullivan 2014]])
-=== Architektur ===
+==== Architektur ====
 Ein YARN-Cluster besteht aus folgenden Komponenten:
@@ Zeile 90: / Zeile 91: @@
   * **Container** (pro Applikation): Meint die Ressourcen, die einer Applikation pro Knoten zur Verfügung stehen.
-(Vgl. [[bigdata:literatur|Apache 2014]]; [[bigdata:literatur|Jones/Nelson 2013]])
+(Vgl. [[bigdata:literatur#a|Apache 2014]]; [[bigdata:literatur#j|Jones/Nelson 2013]])
 {{ bigdata:figure2.png }}
-(Bild-Quelle: [[bigdata:literatur|Jones/Nelson 2013]])
+(Bild-Quelle: [[bigdata:literatur#j|Jones/Nelson 2013]])
-Das Trennen des Ressourcenmanagements von MapReduce durch die YARN-Architektur, die nun einen ResoucreManager mit der Aufgabe betraut, können über die ApplicationMaster, die für die Ausführung eines Jobs verantwortlich sind, nun auch mehrere verschiedene Anwendungen gleichzeitig in der Hadoop-Umgebung laufen (seien sie nun MapReduce-Jobs, graphbasierte Verarbeitung, effizientere Echtzeit-Verarbeitung oder Machine Learning). YARN bleibt dabei kompatibel zu MapReduce-Anwndungen, die unter Hadoop 1 geschrieben wurden.
+Das Trennen des Ressourcenmanagements von MapReduce durch die YARN-Architektur, die nun einen ResoucreManager mit der Aufgabe betraut, können über die ApplicationMaster, die für die Ausführung eines Jobs verantwortlich sind, nun auch mehrere verschiedene Anwendungen gleichzeitig in der Hadoop-Umgebung laufen (seien sie nun MapReduce-Jobs, graphbasierte Verarbeitung, effizientere Echtzeit-Verarbeitung oder [[bigdata:machinelearning|Machine Learning]]). YARN bleibt dabei kompatibel zu MapReduce-Anwndungen, die unter Hadoop 1 geschrieben wurden.