MapReduce - Konzept - Abteilung Datenbanken Leipzig
Werbung
Universität Leipzig Institut für Informatik Abteilung Datenbanken Seminararbeit MapReduce - Konzept Autor: Studiengang: Thomas König (Mat.-Nr. 1740853) Master Informatik (3. Semester) Betreuer: Gutachter: Lars Kolb Lars Kolb Eingereicht am: 31.03.2010 MapReduce - Konzept Inhaltsverzeichnis 1 Einleitung..................................................................................................................3 1.1 Motivation.............................................................................................................3 1.2 Zielstellung der Arbeit..........................................................................................4 1.3 Aufbau der Arbeit.................................................................................................4 2 MapReduce-Konzept................................................................................................5 2.1 Allgemein.............................................................................................................5 2.2 Funktionsweise....................................................................................................5 2.3 Beispiel.................................................................................................................8 2.3.1 Schritt 1: unstrukturierte Wetterdaten einlesen.............................................8 2.3.2 Schritt 2: Zuordnung von Datei-Inhalt zu Position........................................8 2.3.3 Schritt 3: Erzeugen von Zwischenschlüssel-/-wertepaaren..........................9 2.3.4 Schritt 4: Erzeugen von gruppierten Schlüssel-/Wertepaaren...................10 2.3.5 Schritt 5: Reduce-Task zur Berechnung der Endergebnisse.....................10 2.3.6 Schritt 6: Ausgabe der Daten......................................................................11 3 MapReduce im Vergleich.......................................................................................12 3.1 Vergleich mit relationalen Datenbanken............................................................12 3.2 Vergleich mit parallelen Datenbanken...............................................................13 3.3 Vergleich mit Grid Computing............................................................................16 3.4 Vergleich mit Volunteer-Computing...................................................................17 4 Praktische Anwendungen.....................................................................................19 4.1 Hadoop..............................................................................................................19 4.2 Google's Rechenzentren...................................................................................19 5 Zusammenfassung.................................................................................................21 6 Literaturverzeichnis...............................................................................................22 6.1 Web....................................................................................................................22 6.2 Bücher................................................................................................................23 6.3 Artikel.................................................................................................................23 7 Abbildungsverzeichnis..........................................................................................24 8 Tabellenverzeichnis...............................................................................................25 Seite 2 MapReduce - Konzept 1 Einleitung 1.1 Motivation Cloud Computing beschreibt die Verwendung einer Technologie, bei der abzuarbeitende Berechnungen nicht auf einem einzigen Computer ausgeführt werden, sondern auf mehrere Computer in einem Netzwerk aufgeteilt werden. Dabei werden verschiedene Kapazitäten, wie zum Beispiel Rechenkapazität, dynamisch über das Netzwerk zur Verfügung gestellt. Die Anwendungen und Daten befinden sich in der Cloud und werden zum Beispiel über einen Webbrowser gestartet und verwaltet. [URL 005, URL 006] Bei der Verwendung von Cloud Computing-Anwendungen kann eine hohe Rechenkapazität erreicht werden, die die Zeitdauer von Berechnungen je nach Anzahl der beteiligten Computer bzw. Server beeinflusst. Doch um auch große Datenmengen verarbeiten zu können, reicht die CPU-Leistung allein nicht aus. Das Einlesen der Daten hängt vielmehr von den verwendeten Festplatten ab. Zwar sind in den letzten Jahren die Kapazitäten der Festplatten stark gestiegen, sodass die Datenmenge an sich kein Problem mehr darstellt, die Zugriffs- und Transferzeiten haben sich im Vergleich jedoch wenig verbessert. Zum Beispiel benötigt eine 40 GBFestplatte aus dem Jahr 2000 insgesamt 21 Minuten für das Lesen der kompletten Festplatte (bei 32 MB/s), während eine 1.000 GB-Festplatte von 2009 schon 136 Minuten benötigt (bei 125 MB/s). [WHITE 09, Seite 24] [URL 007] Da die zu verarbeitenden Daten tendenziell immer größer werden, ist eine Lösung nötig, die neben der CPU-Leistung auch für eine Beschleunigung der Datenoperationen vorsieht. Die Voraussetzung ist auch hier das Verbinden von mehreren Computern zu einem Cluster. Das MapReduce-Konzept sorgt für eine verteilte Speicherung der Daten auf den unterschiedlichen Computern im Cluster und parallelisiert zudem Datenoperationen, indem nicht nur eine Recheneinheit alle Daten einliest, sondern jede Recheneinheit liest jeweils unterschiedliche Daten ein. Dadurch entsteht eine deutliche Zeitreduzierung bei Zugriffsoperationen, was besonders bei sehr großen und un- bzw. semistrukturierten Datenmengen von Vorteil ist. [WHITE 09] Seite 3 MapReduce - Konzept 1.2 Zielstellung der Arbeit Zielstellung dieser Arbeit ist es, die Funktionen des MapReduce-Verfahrens zu betrachten und deren Arbeitsweise zu klären. Weiterhin wird kurz auf das OpenSource-Java-Framework Hadoop als Referenzimplementierung eingegangen, sowie deren Einsatz an einem eigenem Beispiel untersucht. 1.3 Aufbau der Arbeit Diese Seminararbeit gliedert sich in zwei Bereiche auf, den theoretischen und den praktischen Teil. Der theoretische Teil wird das MapReduce-Konzept untersucht und einen kurzen Blick auf das Hadoop-Framework werfen. Eine detaillierte Betrachtung von Hadoop erfolgt in einer separaten Seminararbeit. Weiterhin soll ein Praxis-Beispiel mit der Verwendung von Hadoop vorgestellt und somit die Anwendung des MapReduceKonzepts demonstriert werden. Die Seminararbeit endet mit einer Zusammenfassung des untersuchten Themas. Seite 4 MapReduce - Konzept 2 MapReduce-Konzept 2.1 Allgemein Bei MapReduce handelt es sich um ein Programmiermodell, welches speziell zur Verarbeitung von großen Datensätzen eingesetzt wird. Damit eine große Menge an gesammelten Daten verarbeitet werden kann, muss der Aufwand der dafür benötigen Berechnungen auf mehrere Recheneinheiten verteilt werden. Mit Hilfe des MapReduce-Frameworks können solche Berechnungen auf vielen Rechnern parallel ausgeführt werden. Außerdem ist MapReduce auch dafür zuständig, die Ergebnisse im Anschluss wieder zu aggregieren. Die eigentliche Aufgabe von MapReduce liegt hierbei in der Bereitstellung und dem Management der Berechnungsinfrastruktur. Ein Entwickler, der eine verteilte Anwendung implementiert, muss sich also nicht mit der Parallelisierung beschäftigen und kann für diese Zwecke ohne viel Aufwand auf die Mechanismen des MapReduce-Frameworks zurückgreifen. Auf Basis dessen können verteilte Anwendungen problemlos auch auf eine hohe Anzahl an Clients hochskalieren, ohne dass Codeänderungen nötig werden. Ein großer Vorteil des MapReduce-Ansatzes ist die Möglichkeit, handelsübliche Standard-Hardware statt kostenintensiven High-End-Servern zu verwenden. Ein Cluster kann somit auch ohne spezielle Server aufgebaut und betrieben werden. [OSDI 04] 2.2 Funktionsweise Die MapReduce-Konzept beruht auf zwei separaten Abläufen: Map und Reduce. Die Map-Vorgänge starten mit dem Einlesen der Daten. Es erfolgt eine Transformation der Eingabedaten, die ungeordnet vorliegen, in Schlüssel-/Werte-Paare. Das Auslesen der Daten wird in mehreren Map-Tasks auf mehreren Recheneinheiten ausgeführt, was bedeutet, dass die Daten parallel eingelesen werden, wobei jede Recheneinheit in der Regel unterschiedliche Blöcke der Dateien einliest. Nach dem ersten Schritt, dem Extrahieren der benötigten Informationen aus dem unsortierten Datenstrom, erhält man als Ergebnis Schlüssel-/Wertepaare mit dem Byte-Offset des Seite 5 MapReduce - Konzept Datenstroms (als Schlüssel) sowie die zugehörige Datenzeile (als Wert), was mit der Signatur der Map-Funkion ausgedrückt werden kann: map: k1, v1 → list(k2, v2) Im Anschluss daran verarbeitet der Map-Task jeden Eintrag dieses Schlüssel-/Wertepaares und extrahiert die benötigten Informationen. Es wird ein neues Zwischenschlüssel-/-wertepaar erzeugt und einem Schlüssel ein Wert zugeordnet. Nach einer Gruppierung dieser Paare liegen zu jedem Schlüssel mehrere Werte vor, wobei jeder Schlüssel genau ein Mal existiert. [k2, list(v2)] Jeder ablaufende Reduce-Task verarbeitet nun eine oder mehrere gruppierte Schlüssel-/Wertepaare und ordnet einem Schlüssel die benötigte Eigenschaft zu, etwa die Summe der Werteliste oder das Maximum aller gesammelten Werte einer Gruppe. Es entstehen Schlüssel-/Wertepaare, bei denen jedem Schlüssel nur ein Wert zugeordnet wird. reduce: k2, list(v2) → list(k3, v3) Für die Aufteilung der Reduce-Tasks ist die Partitionierungsfunktion zuständig, die auf Basis der intermediaten Schlüssel-/Wertepaare arbeitet und den Partitionierungsindex an die Reducer übergibt, wobei die festgelegte Anzahl an Reducern als Parameter an die Funktion übergeben wird. Als Partitionierungsindex dient der Schlüssel, zugehörige Werte werden ignoriert. partition: (k2, v2) → integer Die nachstehende Grafik verdeutlicht den Ablauf noch einmal. Kapitel nach [WHITE 09, OSDI 04, URL 001] Seite 6 MapReduce - Konzept Abbildung 2.1: Ablauf von Map und Reduce [WHITE 09, Seite 163] Seite 7 MapReduce - Konzept 2.3 Beispiel Im folgenden Beispiel sollen Temperaturdaten aus einem unstrukturierten Datenstrom im Form von Textdateien gelesen werden. Es ist bekannt, wie lang ein Datensatz ist und an welchen String-Positionen sich die benötigten Daten befinden. Ziel des Beispiels ist die Ermittlung der maximalen Temperatur eines Jahres. Die einzelnen Schritte lassen sich anhand der nachstehenden Grafik überblicken. Abbildung 2.2: Beispielablauf für die Verarbeitung von Wetterdaten 2.3.1 Schritt 1: unstrukturierte Wetterdaten einlesen Ein Datensatz, der in den Textdateien durch eine einzige Zeile repräsentiert wird, hat die folgende Struktur: 0029029070999991901010113004+64333+023450FM-12+000599999V02029 01N008219999999N0000001N9-00721+99999102001ADDGF10499199999999 9999999999 In einem Datensatz sind unter anderem das Datum und die Uhrzeit der Erstellung sowie die Temperatur zu diesem Zeitpunkt hinterlegt. Der Beispiel-Datensatz wurde am 01. Januar 1901 um 13:00 Uhr aufgezeichnet, die Temperatur betrug -7,2 °C (s. rote Markierung). Im ersten Schritt werden sämtliche Daten parallel eingelesen. 2.3.2 Schritt 2: Zuordnung von Datei-Inhalt zu Position Da bekannt ist, wie lang ein Datensatz ist, kann aus der unstrukturierten Datenmenge eine Liste von Schlüssel-/Wertepaaren erzeugt werden, wobei als Seite 8 MapReduce - Konzept Schlüssel der Byte-Offset des Zeilenanfangs dient und als Wert die Zeile, also der Datensatz, selbst. Die Erzeugung der Schlüssel-/Wertepaare kann mit (k1, v1) = (long, String) gleichgesetzt werden. Byte-Offset Datensatz 0 0029029070999991901010113004+6... 106 0029029070999991901010114004+6... 212 0029029070999991901010115004+6... 318 0029029070999991902010104004+6... 424 0029029070999991903081223004+6... Tabelle 2.1: Ausgangslage: ungeordnete Schlüssel-/Wertepaare 2.3.3 Schritt 3: Erzeugen von Zwischenschlüssel-/-wertepaaren Nach dem Zuordnen der Datensätze zu Byte-Offsets werden im dritten Schritt die benötigten Daten aus jedem Datensatz extrahiert, was als Map-Task geschieht. Ergebnis der Extraktion sind Zwischenschlüssel-/Wertepaare. Als Zwischenschlüssel dient in diesem Beispiel die Jahreszahl, der zugeordnete Wert ist die Temperatur des zugehörigen Datensatzes multipliziert mit 10. Es entstehen zahlreiche Key/ValuePaare mit identischen Schlüsseln, die in der Form k1, v1, k2, v2 = int vorliegen. Jahr Temperatur 1950 0 1950 22 1950 -11 1949 111 1949 78 Tabelle 2.2: Zwischenschlüssel-/Wertepaare Seite 9 MapReduce - Konzept 2.3.4 Schritt 4: Erzeugen von gruppierten Schlüssel-/Wertepaaren Im weiteren Verlauf des Map-Vorgangs erfolgt eine Gruppierung der Key/ValuePaare. Dazu werden zunächst alle vorhandenen Schlüssel sortiert und im Anschluss daran zu jedem Schlüssel alle vorhandenen Werte gesucht und diesem zugeordnet, sodass am Ende des Map-Vorgangs ein Bestand aus gruppierten Zwischenschlüssel-/Wertepaaren vorliegt. Jeder Zwischenschlüssel existiert nun genau ein Mal und enthält einen oder mehrere Werte, die ihm während des MapVorgangs zugeordnet wurden. Die entstandenen Schlüssel und Werte liegen hier ebenfalls als integer-Wert vor. Jahr Temperatur 1949 111 78 1950 0 22 -11 Tabelle 2.3: Ergebnis des Map-Vorgangs Da mehrere Map-Tasks parallel auf mehreren Recheneinheiten ausgeführt werden, ist es nötig, dass jeder Mapper seinen sortierten Output ins Dateisystem schreibt. Die Partitionierungsfunktion erstellt auf Basis der intermediaten Schlüssel die Partitionierungsindizes und ermöglicht so ein Zuordnen der Schlüssel zu einer zuvor bestimmten Anzahl an Reducern. 2.3.5 Schritt 5: Reduce-Task zur Berechnung der Endergebnisse Nach dem erfolgreichen Abarbeiten des Map-Vorgangs erfolgt der Ablauf der Reduce-Funktion, die als Eingabedaten die zuvor gruppierten Zwischenschlüssel-/ Wertepaare erhält. In diesem Beispiel wird pro Jahr ein eigener Reducer auf einem Rechner im Cluster gestartet. Dabei holen sich die Reducer die ihnen zugeordneten Partitionen von den einzelnen Mappern ab, führen den sortierten Eingabestrom zusammen (merge) und übergeben die nun erzeugten list(k2, list(v2)) an die Reduce-Funktion. Seite 10 MapReduce - Konzept Je nach gewünschtem Ergebnis werden nun die Werte in jeder Gruppe weiterverarbeitet. Pro Jahr soll die Maximaltemperatur ermittelt werden, sodass nach dem Reduce-Schritt eine neue Liste von Schlüssel-/Wertepaaren vorhanden ist, wobei jedem (einzigartigem) Schlüssel nur noch ein Wert zugeordnet wird. Diese Schlüssel und Werte werden, wie zuvor auch, als integer-Werte zurückgegeben. Jahr Temperatur 1949 111 1950 22 Tabelle 2.4: Endergebnis nach dem Reduce-Vorgang 2.3.6 Schritt 6: Ausgabe der Daten Der letzte Schritt besteht nur noch in der Ausgabe der Key/Value-Paare in eine Datei, in der zum Beispiel die Schlüssel und Werte durch ein Komma getrennt eingetragen werden und jedes Paar durch einen Zeilenumbruch getrennt wird. Kapitel nach [WHITE 09, OSDI 04, URL 001] Seite 11 MapReduce - Konzept 3 MapReduce im Vergleich 3.1 Vergleich mit relationalen Datenbanken Bei der Verwendung von MapReduce stellt sich die Frage, ob es nicht doch einfacher wäre, sämtliche zu verarbeitende Daten in einer relationalen Datenbank zu speichern und von dort auszulesen anstatt ein MapReduce-Framework zu verwenden. Um darauf eine Antwort geben zu können, muss man die Ziele und Anwendungsmöglichkeiten der jeweiligen Techniken näher betrachten. Liegen strukturierte Daten vor und ist darüber hinaus auch das Schema bekannt, so liegt der Vorteil bei den relationalen Datenbanken. Das gezielte Abfragen von bestimmten Spalten einer Tabelle eignet sich besonders bei „wenigen“ abzufragenden Datensätzen aufgrund des bekannten Schemas und der verfügbaren Indexe. Somit kann ein effizienter Zugriff auf einzelne Datensätze und Attribute gewährleistet werden. Änderungsmöglichkeiten der Daten sind bei relationalen Datenbanken ebenfalls vorhanden und leicht durchführbar, im Gegensatz zu den unstrukturierten Daten, die beim MapReduce-Framework zum Einsatz kommen. Hier kommt das Zugriffsmuster „Write once, read many times“ zum Einsatz, was bedeutet, dass effiziente Lese- und Schreibzugriffe nicht möglich sind. Für das MapReduce und dessen unstrukturierte Datenmengen spricht jedoch die enorme Datenmenge an sich und die Skalierbarkeit. Mehrere Recheneinheiten im Cluster lesen parallel ein und können somit ein Vielfaches der Datenmenge im Vergleich zu relationalen Datenbanken handhaben. Je mehr Recheneinheiten, umso schneller kann das Einlesen erfolgen. Während MapReduce also für das sequentielle (parallele) Einlesen von großen Datenmengen geeignet ist, spielen die relationalen Datenbanksysteme ihre Stärken bei bekannten Strukturen, Punktanfragen und Änderungsoperationen aus. Seite 12 MapReduce - Konzept Traditional RDMBS MapReduce Data size Gigabytes Petabytes Access Interactive and Batch Batch Updates Read and write many times Write once read many times Structure Static schema Dynamic schema Integrity High Low Scaling Nonlinear Linear Tabelle 3.1: Vergleich von RDBMS und MapReduce [WHITE 09, Seite 5] 3.2 Vergleich mit parallelen Datenbanken Bei parallelen Datenbanken handelt es sich ebenfalls um mehrere Recheneinheiten, die über ein Netzwerk verbunden sind. „Unter der Bezeichnung "Mehrrechner-Datenbanksysteme" sollen sämtliche Architekturen zusammengefaßt werden, bei denen mehrere Prozessoren oder DBVS-Instanzen an der Verarbeitung von DBOperationen beteiligt sind. Dabei ist natürlich eine Kooperation der Prozessoren bzw. DBVS bezüglich der DB-Verarbeitung bestimmter Anwendungen vorzusehen, um den Fall voneinander isoliert arbeitender DBVS oder Prozessoren auszuschließen.“ [RAHM 01] Hierbei können insgesamt drei verschiedene Architekturen unterschieden werden. • Shared-Everything: Alle Recheneinheiten teilen sich einen gemeinsamen Speicher für die Lese- und Schreibvorgänge. „Die DB-Verarbeitung erfolgt durch ein DBVS1 auf einem Multiprozessor“. [RAHM 01] • Shared-Nothing: Sämtliche Recheneinheiten verfügen über ihren eigenen Multiprozessor. Der gemeinsame Speicher wird unter den Recheneinheiten partitioniert, sodass jede Recheneinheit seinen eigenen lokalen Speicherbereich hat und nur auf diesen zugreifen kann. [RAHM 01] • Shared-Disk: Es handelt sich um eine ähnliche Anordnung wie SharedNothing, allerdings existiert hier ein gemeinsamer Speicherbereich, der nicht aufgeteilt wird. Lese- und Schreibzugriffe 1 Datenverwaltungssystem Seite 13 erfolgen somit auf den MapReduce - Konzept gemeinsamen Speicherbereich, der allen Recheneinheiten zugänglich ist. [RAHM 01] Bei parallelen Datenbanksystemen werden, wie bei relationalen Daten- banksystemen, Tabellen mit Zeilen und Spalten eingesetzt, die ebenfalls bei SQL abgefragt werden können. Das Abfragen der bekannten Struktur per SQL kann aufgrund der Parallelverarbeitung jedoch deutlich schneller geschehen als es bei relationalen Datenbanken der Fall ist, da, je nach Partitionierung der Speicherbereiche, eine Tabelle auf mehrere Recheneinheiten verteilt werden kann. Das dahinter liegende Verfahren wird als horizontale Partitionierung bezeichnet. [STONE 10] „The idea behind horizontal partitioning is to distribute the rows of a relational table across the nodes of the cluster so they can be processed in parallel. For example, partitioning a 10-million-row table across a cluster of 50 nodes, each with four disks, would place 50,000 rows on each of the 200 disks.“ [STONE 10] Somit können also größere Datenmengen in der selben Zeitdauer gelesen, geändert oder gelöscht werden, was bei (mehreren) hundert Gigabyte pro Tabelle eine deutliche Zeitreduktion ergibt. Der Nachteil der Parallelisierung liegt in den Kosten. Für den Betrieb von parallelen Datenbanksystemen kommen ausschließlich HighEnd-Server zum Einsatz, die hohe Kosten verursachen. Darüber hinaus verursacht auch das Datenbankverwaltungssystem hohe Kosten, sofern mehrere Recheneinheiten im Cluster vorhanden sind. Für Single-Node-Systeme existieren dagegen diverse Open Source-Implementierungen, die zur freien Verfügung stehen. [STONE 10] In der Literatur existieren einige vergleichende Aussagen bezüglich MapReduce und parallelen Datenbanksystemen, die im Folgenden kurz vorgestellt werden sollen. Sobald sämtliche Daten vom Speicher eingelesen wurden, haben parallele Datenbanksysteme demnach Geschwindigkeitsvorteile beim Abfragen der benötigten Daten, wohingegen MapReduce Geschwindigkeitsvorteile während des parallelen Einlesens der Daten aufweisen kann, da Datenbanksysteme beim Einlesen langsamer sind. [STONE 10] MapReduce profitiert bei den Berechnungen und der CPU-Leistung ebenso von der Anzahl der Recheneinheiten im Cluster wie die parallelen Datenbanksysteme, diese Seite 14 MapReduce - Konzept bieten jedoch zusätzlich den Vorteil der Abfragesprache SQL. [STONE 10] Für die Open Source-Implementierung Hadoop, die das MapReduce-Konzept umsetzt, existieren die Erweiterungen HadoopDB und Hive, die das MapReduce-Konzept um eine SQL-ähnliche Abfragesprache erweitern (Hive) oder PostegreSQL und Hadoop verbinden (HadoopDB). HadoopDB kann somit eine ähnliche Geschwindigkeit wie die parallelen DBS erreichen. [URL 008, URL 009, URL 010, RASIN 09] Die Vorteile von MapReduce liegen bei den semistrukturierten Daten, deren Einlesezeit von der Anzahl der Recheneinheiten im Cluster bestimmt wird, was besonders bei komplexen Datenanalysen (wie etwa Data Mining) und dem damit verbundenen komplexen Datenfluss einen Vorteil gegenüber den parallelen DBS ergibt, da hier keine SQL-Queries verwendet werden können. [STONE 10] Ein weiterer Vorteil von MapReduce liegt bei der Fehlertoleranz. Da die Eingabedaten blockweise auf den Recheneinheiten im Cluster gespeichert werden und als Folge davon redundant vorhanden sind, kann bei einem fehlerhaften MapTask einfach eine andere Recheneinheit diesen einen Task wiederholen. Parallele Datenbanksysteme müssen mit Transaktionen umgehen können, was bedeutet, dass eine fehlgeschlagene Query komplett wiederholt werden muss. [PAVLO 09] Weitere Vergleiche werden in [STONE 10, PAVLO 09 und RASIN 09] durchgeführt und sollen an dieser Stelle nicht näher vertieft werden. Parallele DBS MapReduce Datengröße Gigabytes - Petabytes Petabytes Struktur Statisches Schema Semistrukturierte Daten Partitionierung Horizontal Blöcke in DFS (Byteweise) Anfrage Deklarativ (SQL) MapReduce-Programme Zugriff Punkt/Bereich via Indexes Batch Updates Read and write many times Write once read many times Scheduling Compile-time Runtime Verarbeitung Effizienter Zugriff auf Attribute Parsen jeden Tupels zur möglich (Storage Manager) Laufzeit Datenfluss Push – Pipelining von Tupeln zwischen Operationen Pull – Materialisierung von Zwischenergebnissen Fehlertoleranz Query-Restart (z.T. Operator- Neustart des Map-/Reduce- Seite 15 MapReduce - Konzept Parallele DBS MapReduce Restart) Tasks Skalierbarkeit Linear (existierende Setups) Linear Umgebung Homogen (High-EndHardware) Heterogen (StandardHardware) Kosten Sehr teuer Open Source Tabelle 3.2: Vergleich von parallelen DBS und MapReduce [nach Lars Kolb] 3.3 Vergleich mit Grid Computing Neben MapReduce existiert eine weitere Anordnung, bei Recheneinheiten zu einem Cluster verbunden werden: Grid Computing. Allerdings gibt es auch hier Unterschiede, die sich vor allem im Anwendungszweck und in der Datenverarbeitung äußern. Grid Computing wird größtenteils für rechenintensive Jobs verwendet, wie zum Beispiel bei der Pharmaforschung oder um andere wissenschaftliche Probleme zu lösen. Dabei werden normale Computer über ein Netzwerk zu einem Supercomputer mit enormer Rechenkraft verbunden. [URL 004] Was für die Berechnungen von Vorteil ist, stellt sich bei den Datenzugriffen als Nachteil heraus. Benötigte Daten müssen über das Netzwerk gestreamt werden, die Netzwerkanbindung ist hierbei der Flaschenhals, da die einzelnen Rechner eines Grids standortunabhängig aufgebaut werden können. Während des Datenaustauschs erfolgt eine Unterbrechung der Berechnungen. Im Gegensatz dazu hat jeder Rechner des MapReduce-Clusters (mindestens) eine Kopie der Daten lokal verfügbar und kann aufgrund der parallelen Datenzugriffsoperationen schneller arbeiten. Ein fehlerhaftes Einlesen kann problemlos wiederholt werden. Für Grid Computing existiert eine API, die unter dem Namen „Message Passing Interface“ (MPI) bekannt ist. Die API bietet dem Programmierer Freiheiten bei der Gestaltung der Prozesse, verlangt im Gegenzug aber auch das eigenhändige Implementieren der Datenoperationen auf Low Level Ebene (C Routinen und Konstrukte, z.B. Sockets), die Berechnungen können als High Level Algorithmus implementiert werden. MapReduce arbeitet ausschließlich auf High Level Ebene und Seite 16 MapReduce - Konzept übernimmt ohne Zutun des Programmierers sämtliche Dateioperationen. Die Berechnungen können jedoch nur über Key/Value-Paare erfolgen und sind dahingehend eingeschränkt. Es gibt eine Vielzahl von Aufgaben, die sich dennoch mit MapReduce erledigen lassen, wie Bildanalysen oder „machine learning algorithms“. [WHITE 09, Seite 8] Ein weiterer Unterschied ist die Fehlerbehandlung. Der Grid-Programmierer muss selbst für eine geeignete Implementation sorgen, was ihm zwar mehr Kontrolle gibt, aber auch einen höheren Aufwand nach sich zieht. Fehlerbehandlungen bei MapReduce werden vom Framework automatisch durchgeführt, fehlerhafte Map- und Reduce-Tasks werden automatisch neu gestartet, falls ein Fehler entstanden ist. [WHITE 09, Seite 6ff] Datengröße Grid Computing MapReduce Gigabytes - Petabytes Petabytes Datenspeicherung Streaming der Daten über das Lokale Kopie auf jedem Netzwerk Rechner Fehlertoleranz Muss vom Programmierer implementiert werden Neustart des Map-/ReduceTasks Skalierbarkeit Linear Linear Umgebung Heterogen (StandardHardware) Heterogen (StandardHardware) Anwendungsziel CPU-intensive Berechnungen Datenverarbeitung Tabelle 3.3: Vergleich von Grid Computing und MapReduce [nach WHITE 09, S. 6ff] 3.4 Vergleich mit Volunteer-Computing Zu Volunteer-Computing zählt beispielsweise SETI@home („Search for ExtraTerrestrial Intelligence“). Bei diesem Projekt werden Daten von Radioteleskopen im Bezug auf Anzeichen von intelligentem Leben im Weltall ausgewertet. Die Berechnungen werden auf den Computern von Privatanwendern ausgeführt. Bei wenig anliegender CPU-Last übernehmen diese die Auswertung der SETI-Daten, wobei jeder Teilnehmer nur ein kleines Datenpaket (ca. 0,35 MB) erhält uns dieses dann auswertet. Trotz dieser geringen Datenmenge dauert die Berechnung mehrere Seite 17 MapReduce - Konzept Stunden oder gar Tage. Die Anwendungsbereiche liegen beim Volunteer-Computing also eindeutig auf der Bereitstellung von Prozessorleistung und nicht auf dem zügigen Einlesen von riesigen Datenmengen, obwohl auch bei MapReduce die gesamte Datenmenge in kleinere Blöcke geteilt wird. Betrugsversuche und falsche Berechnungen werden mit bestimmten Maßnahmen automatisch abgesichert. Ein weiterer Unterschied besteht im Aufbau der jeweiligen Cluster. MapReduce-Tasks werden in einem Cluster ausgeführt, deren einzelne Recheneinheiten in der Regel über ein schnelles Netzwerk verbunden sind, während beim Volunteer-Computing der Netzwerkverkehr durch die Internetanbindung des Teilnehmers bestimmt wird. [WHITE 09, Seite 8] Volunteer Computing MapReduce Datengröße Kilobytes - Megabytes Petabytes Datenhaltung Streaming der Daten über das Lokale Kopie auf jedem Netzwerk Rechner Fehlertoleranz Wird vom Projekt bzw. vom Server geregelt Neustart des Map-/ReduceTasks Umgebung Heterogen (StandardHardware) Heterogen (StandardHardware) Netzwerkanbindung Beschränkt auf die Internetverbindung der Teilnehmer Hochgeschwindigkeitsnetzwerk Anwendungsziel CPU-intensive Berechnungen Datenverarbeitung Tabelle 3.4: Vergleich von Volunteer Computing und MapReduce [nach WHITE 09, Seite 8] Seite 18 MapReduce - Konzept 4 Praktische Anwendungen 4.1 Hadoop Hadoop ist die OpenSource-Implementierung des MapReduce-Konzepts. Es handelt sich um ein Open Source Projekt der Apache Software Foundation, das offen für freiwillige Teilnehmer ist. Das von ihnen bereitgestellte Framework dient der Programmierung von MapReduce-Tasks und ist, wie es das MapReduce-Konzept vorsieht, auf große Datenmengen spezialisiert, die parallel auf mehreren Computern abgearbeitet werden, die zu einem Cluster verbunden wurden. Das Framework steht für Unix/Linux zum Download bereit und setzt eine installierte Java Virtual Machine 1.6 voraus, sofern man das Framework in Java-Applikationen verwenden möchte. Sämtliche Daten, die im Cluster zur Verfügung stehen sollen, müssen zunächst von der eigenen Festplatte auf das verteilte Dateisystem übertragen werden. Nach dem Kopiervorgang ist das Framework in der Lage, einen MapReduce-Task durchzuführen. An dieser Stelle soll nicht näher auf die Ausführung eingegangen werden. Mit Hive und HadoopDB erhält der Anwender zwei interessante Erweiterungen. Hive erweitert das Hadoop-Framework um die auf SQL basierende Anfragesprache QL und ermöglicht so „die Verwendung einer SQL-ähnlichen Syntax“. [URL 008] Bei HadoopDB handelt es sich um eine Kombination aus Hadoop und der freien Datenbank PostegreSQL. HadoopDB bietet damit die Skalierbarkeit von Hadoop und die Geschwindigkeit von parallelen Datenbanken. [URL 008, URL 009, URL 010, RASIN 09] 4.2 Google's Rechenzentren Die Verwendung der Suchmaschine Google erfolgt durch das einfache Benutzen der Weboberfläche. Welche Hardwarebasis bei einer Suchabfrage zum Einsatz kommt, ist nicht ersichtlich. Zur Erstellung der enormen Datenmengen werden zahlreiche Suchindexe und Page-Rank-Tabellen benötigt, die in Rechenzentren verwaltet werden. Laut Informationen von Google soll ein Rechenzentrum aus 45 Containern Seite 19 MapReduce - Konzept bestehen, in denen insgesamt 45.000 Server untergebracht werden. Mit einem solchen Cluster wird das Crawlen und Aufbereiten der Suchergebnisse durchgeführt. Aufgrund der ständig steigenden Datenmengen setzt Google seit 2005 solche Rechenzentren ein. Abbildung 4.1: Google Rechenzentrum Der Energieverbrauch einer solchen Serverfarm beläuft sich auf 10 Megawatt, was einige Kühltürme, die mit Wasser betrieben werden, sowie ein eigenes Kraftwerk notwendig macht. Bei der Stromerzeugung sollen hocheffiziente Transformatoren zum Einsatz kommen. [URL 002] Der Großteil der Rechenzentren befinden sich in Nordamerika und Europa, nur wenige Rechenzentren wurden in Südamerika und Asien errichtet. Abbildung 4.2: Standorte der Google Rechenzentren [URL 003] Seite 20 MapReduce - Konzept 5 Zusammenfassung Für die verteilte Abarbeitung von Aufgaben bietet sich ein Cluster an, das aus mehreren Recheneinheiten besteht. Während es für CPU-intensive Aufgaben oder das schnelle und gezielte Abfragen von Datenbanken diverse Techniken zur Verfügung stehen, bietet sich das MapReduce-Konzept vor allem für die schnelle Verarbeitung von semistrukturierter riesigen Form Datenmengen vorliegen. Der an, die in unstrukturierter Geschwindigkeitsvorteil entsteht oder bei MapReduce in Einlesevorgängen, die parallel auf den vorhandenen Recheneinheiten durchgeführt werden. Jeder Rechner im Cluster liest einen anderen Block der Daten ein. Je mehr Rechner im Cluster vorhanden sind, umso schneller kann das Einlesen erfolgen. Das MapReduce-Konzept sieht außerdem vor, dass sämtliche Fehlerbehandlungen vom Framework übernommen werden und dem Anwender diesen Aufwand ersparen. Auch regelt das Framework selbstständig, welche Recheneinheit welche Daten einliest und verarbeitet und wie die Aufteilung der Berechnungen erfolgt. Das MapReduce-Framework untergliedert die Aufgaben in Map- und Reduce-Tasks. Grundlage der Verarbeitung sind Key/Value-Paare, die bis zur Beendigung der Reduce-Tasks einige Zwischenschritte, wie zum Beispiel das Sortieren und Gruppieren, erfahren. Das von Google entwickelte MapReduce-Konzept kann als Open SourceImplementierung Hadoop auf jedem beliebigen Rechner frei verwendet werden. Die behandelten Vergleiche haben verdeutlicht, dass das Einsatzgebiet von MapReduce in den parallelen Datenzugriffsoperationen von riesigen Datenmengen, wie zum Beispiel dem Einlesen von Page-Rank-Tabellen, zu suchen ist und weniger bei der komplexen und CPU-intensiven Berechnung von Ergebnissen. Vielmehr sollen die eingelesenen Daten auf vergleichsweise einfache Art und Weise weiterverarbeitet werden. Seite 21 MapReduce - Konzept 6 Literaturverzeichnis 6.1 Web URL 001 http://www.slideshare.net/Wombert/an-introduction-to-mapreduce aufgerufen am 26.11.2009 URL 002 http://blogoscoped.com/archive/2009-04-08-n39.html aufgerufen am 26.11.2009 URL 003 http://royal.pingdom.com/2008/04/11/map-of-all-google-data-centerlocations/ aufgerufen am 26.11.2009 URL 004 http://de.wikipedia.org/wiki/Grid-Computing aufgerufen 10.02.2010 URL 005 http://en.wikipedia.org/wiki/Cloud_computing aufgerufen 27.02.2010 URL 006 http://de.wikipedia.org/wiki/Cloud_Computing aufgerufen 27.02.2010 URL 007 http://de.wikipedia.org/wiki/Festplatte aufgerufen 27.02.2010 URL 008 http://de.wikipedia.org/wiki/Hadoop aufgerufen 28.02.2010 URL 009 http://www.heise.de/newsticker/meldung/HadoopDB-versoehnt-SQLmit-Map-Reduce-6689.html aufgerufen 28.02.2010 URL 010 http://www.golem.de/0907/68643.html aufgerufen 28.02.2010 Seite 22 MapReduce - Konzept 6.2 Bücher WHITE 09 Tom White: Hadoop – The Definite Guide O'Reilly Media, 2009 RAHM 01 Erhard Rahm: Mehrrechner-Datenbanksysteme Springer, 2001 6.3 Artikel OSDI 04 Jeffrey Dean and Sanjay Ghemawat MapReduce: Simplifed Data Processing on Large Clusters STONE 10 Michael Stonebraker, Daniel Abadi, David J. Dewitt, Sam Madden, Erik Paulson, Andrew Pavlo, Alexander Rasin: MapReduce and Parallel DBMSs: Friends or Foes? Communications of the ACM, Januar 2010 RASIN 09 Azza Abouzeid, Kamil Bajda-Pawlikowski, Daniel Abadi, Avi Silberschatz, Alexander Rasin: HadoopDB: An Architectural Hybrid of MapReduce and DBMS Technologies for Analytical Workloads 2009 PAVLO 09 Andrew Pavlo, Erik Paulson, Alexander Rasin, Daniel J. Abadi, David J. DeWitt, Samuel Madden, Michael Stonebraker: A Comparison of Approaches to Large-Scale Data Analysis 2009 Seite 23 MapReduce - Konzept 7 Abbildungsverzeichnis Abbildung 2.1: Ablauf von Map und Reduce [WHITE 09, Seite 163]............................7 Abbildung 2.2: Beispielablauf für die Verarbeitung von Wetterdaten...........................8 Abbildung 4.1: Google Rechenzentrum......................................................................20 Abbildung 4.2: Standorte der Google Rechenzentren [URL 003]...............................20 Seite 24 MapReduce - Konzept 8 Tabellenverzeichnis Tabelle 2.1: Ausgangslage: ungeordnete Schlüssel-/Wertepaare................................9 Tabelle 2.2: Zwischenschlüssel-/Wertepaare...............................................................9 Tabelle 2.3: Ergebnis des Map-Vorgangs...................................................................10 Tabelle 2.4: Endergebnis nach dem Reduce-Vorgang...............................................11 Tabelle 3.1: Vergleich von RDBMS und MapReduce [WHITE 09, Seite 5]................13 Tabelle 3.2: Vergleich von parallelen DBS und MapReduce [nach Lars Kolb]...........16 Tabelle 3.3: Vergleich von Grid Computing und MapReduce [nach WHITE 09, S. 6ff] .....................................................................................................................................17 Tabelle 3.4: Vergleich von Volunteer Computing und MapReduce [nach WHITE 09, Seite 8].........................................................................................................................18 Seite 25
