Institut für Informatik Wissensmanagement in der Bioinformatik. SE Geospatial Information Retrieval WS 2008/2009 Betreuer: Prof. Dr.

Transkript

1 Institut für Informatik Wissensmanagement in der Bioinformatik SE Geospatial Information Retrieval WS 2008/2009 Betreuer: Prof. Dr. Ulf Leser MapReduce Stefan Bethge (508219) Astrid Rheinländer (195327)

2 Selbständigkeitserklärung Hiermit erklären wir, dass wir die vorliegende Arbeit selbständig und nur unter Zuhilfenahme der angegebenen Quellen und Hilfsmittel verfasst haben. Berlin, 31. März 2009 Stefan Bethge Astrid Rheinländer

3 Inhaltsverzeichnis 1 Einleitung Googles MapReduce Cluster-Architektur Programmiermodell Ausführung im Map-Reduce-Framework Fehlerbehandlung Performance Anwendungen und Implementationen MapReduceMerge Kritik Fazit Literatur

4 1 Einleitung Im November 2008 meldete Google Inc. im rmeneigenen Weblog, dass mit einem MapReduce-basierten, parallelen Sortierverfahren der TB-Sort-Benchmark 1 auf 68 Sekunden eingestellt werden konnte. [Cza08] Google verbesserte die bis dato beste Laufzeit einer ebenfalls parallelen Implementierung auf dem quelloenen MapReduce-Framework Hadoop 2 um den Faktor 3 bei einer vergleichbaren Gröÿe des Rechnerverbunds (Cluster). Der Eintrag im Weblog berichtete weiterhin, dass mit der MapReduce-Implementierung ein Petabyte (10 15 Datensätze à 100 Byte) innerhalb von 6 Stunden sortiert werden konnten. Das Datenvolumen entspricht ungefähr dem 12-fachen aller durch die U.S. Library of Congress archivierten Webseiten. Die Sortierung groÿer Datenmengen ist nur ein Beispiel für den Einsatz von MapReduce, weitere Anwendungsfelder liegen in der Datenextraktion, dem Machine Learning oder im Bereich statistischer Analysen. Interessante Fragestellungen sind z.b. Wie häug wird eine bestimmte URL im Web angefragt? Welche Worte werden besonders häug auf Web-Seiten erwähnt? Welche Begrie werden in Suchanfragen häug benutzt? MapReduce ist also weniger eine geschickte Implementierung eines verteilten Sortieralgorithmus', sondern vielmehr ein Programmiermodell, das die parallele Verarbeitung datenintensiver Aufgaben auf Clusternetzwerken erleichtert. Die Stärke von MapReduce liegt in der Einführung einer neuen Abstraktionsebene, die die technisch komplexen Aspekte der parallelen Programmierung wie Lastund Datenverteilung oder Fehlertoleranz innerhalb eines Frameworks vor dem Benutzer verbirgt. Ein Benutzer, der gegen die Schnittstellen des Frameworks programmiert, muss sich nur noch mit der Frage Was soll berechnet werden? und nicht mehr mit Wie erfolgt die Parallelverarbeitung? befassen. Diese Seminararbeit soll das Konzept von MapReduce erläutern. Kapitel 2 stellt das Programmiermodell und Google's MapReduce-Framework [DG04] vor. Es wird gezeigt, wie MapReduce-Programme innerhalb Googles Cluster-Architektur verarbeitet werden, darüber hinaus werden ausgewählte Aspekte zur Fehlerbehandlung und Performance-Steigerung näher betrachtet. In Kapitel 3 werden Einsatzbereiche und MapReduce-Implementierungen abseits von Google vorgestellt. Kapitel 4 behandelt die Weiterentwicklung Map-Reduce-Merge [YDHP07], die die Verarbeitung heterogener Datenmengen ermöglicht. Kapitel 5 geht auf kritische Stimmen zu MapReduce ein, in Kapitel 6 wird diese Kritik eingeordnet und um ein eigenes Fazit erweitert. 1 Der Terabyte-Sort-Benchmark wurde 1998 von Jim Gray entwickelt und zielt auf die vollständige Sortierung von Datensätzen à 100 Byte. Das erste, schnellste Sortierverfahren benötigte 1998 für diese Aufgabe 2,5 Stunden. Ab April 2009 wird der TB-Sort-Benchmark von einen 100-TB-Sort-Benchmark abgelöst [NS99]. 2 freie MapReduce-Implementation, 3

5 2 Googles MapReduce 2.1 Cluster-Architektur Googles Clusterarchitektur ist ein Vertreter von Shared-Nothing-Architekturen 3. Am treendsten lässt sich ein Google-Cluster mit Masse statt Klasse beschreiben statt aus wenigen, teuren Hochleistungsservern besteht ein Cluster aus mehreren tausend Standard-PCs. Jeder Knoten verfügt über zwei x86 Prozessoren, 4-8 GB Hauptspeicher und zwei 160 GB IDE-Festplatten. Die Knoten sind untereinander über ein Gigabit-Ethernet vernetzt, als Betriebssystem dient Linux. Das Dateisystem Google File System (GFS) ist eine Eigenentwicklung, das für die charakteristischen Information-Retrieval-Aufgaben und die Arbeit in einer Clusterarchitektur abgestimmt wurde [GGL03]. Im GFS werden die Daten verteilt in groÿen, teilweise im Gigabyte-Bereich liegenden Dateien gespeichert, die häugsten Dateioperationen sind Lesen (Read) und Anhängen (Append), eher selten nden Lösch- oder Überschreibeoperationen (Delete, Rewrite) statt. Die Dateien werden durch logische Abbildungen in MB groÿe Teile (Chunks) zerlegt und physisch verteilt auf verschiedenen Servern im Cluster gespeichert. Für jeden Chunk existieren innerhalb eines Clusters mindestens 3 Kopien, damit der Ausfall von Knoten schnell kompensiert werden kann. Darüber hinaus verfügt jeder GFS-Cluster über einen ausgezeichneten Knoten, der ausschlieÿlich Metadaten zu den Dateien (Name, Gröÿe Speicherorte und Anzahl der Chunks, aktuell zugreifende Prozesse... ) speichert und den Dateizugri koordiniert. Googles Clusterarchitektur hat im Vergleich zu Hochleistungsservern einen sehr guten Rechenleistung-pro-Dollar-Schlüssel. Sie ist leicht skalierbar und bei Ausfällen können Knoten sehr leicht ausgetauscht werden. Nachteilig ist, dass Knotenausfälle häug aus verschiedensten Gründen (Netzwerkpartitionierung, Festplattendefekte, allgemeiner Verschleiÿ) auftreten und die Bandbreite des Netzwerks einen potentiellen Bottleneck darstellen. Strategien, um mit diesen Problemen innerhalb von MapReduce umzugehen, werden in den Abschnitten 2.5 und 2.6 dargestellt. 2.2 Programmiermodell Ein MapReduce-Framework bietet dem Benutzer eine Implementationsschnittstelle mit genau zwei selbst zu denierenden Phasen, map und reduce. Map und 3 Mit Shared Nothing wird eine Architektur für verteilte Systeme bezeichnet, in der jeder Knoten zugewiesene Aufgaben autonom mittels eigener Systemkomponenten wie Prozessoren, Hauptspeicher und Festplatten bearbeiten kann. Jeder Knoten verfügt über eine eigene Kopie des auszuführenden Programms und kann Aufgaben an nicht ausgelastete, im Netzwerk erreichbare Knoten abgeben. Neben Shared Nothing unterscheidet man zwischen Shared Memory bzw. Shared Disk und Shared Everything [OV99]. 4

6 reduce stammen ursprünglich aus der funktionalen Programmierung, sie erfüllen dort folgende Aufgaben: Map wendet eine benutzerdenierte, unäre Funktion auf jedes Element der Eingabesequenz an, das Resultat ist widerum eine Sequenz. Reduce verarbeitet eine Eingabesequenz mit einer benutzerdenierten, binären Funktion zu einem einzelnen Ausgabewert. Innerhalb des MapReduce-Programmiermodells haben map und reduce eine generischere Semantik. Die Map-Phase verarbeitet eine Menge von Schlüssel-Wert- Paaren durch eine benutzerdenierte map-methode, in der die konkrete Verarbeitung eines Schlüssel-Wert-Paares speziziert wird. Das Resultat ist eine Sammlung von Schlüssel-Wert-Paaren. Daran schlieÿt die Reduce-Phase an, die auf Basis der Schlüssel durch eine benutzerdenierte reduce-methode aggregierte Endergebnisse produziert. In der Regel produziert die Reduce-Phase ein Ergebnis pro Schlüssel. Beispiel 1: (Word Count) Für eine gegebene Dokumentmenge soll die Anzahl der Vorkommen aller Wörter mit MapReduce gezählt werden. Dazu speziziert der Benutzer die map- und reduce-phasen wie folgt (Pseudocode): map(string document-id, String document){ for each word w in document do { output(w, 1); } } reduce(string word, List values) { int result = 0; for each v in values do { result = result + v; } output (word, result); } Für Word Count wird der Map-Phase eine Menge von Schlüssel-Wert-Paaren, jeweils bestehend aus einer Dokument-ID als Schlüssel und einem Dokument als Wert übergeben. map wird auf jedes Paar angewandt, d.h. ein Dokument wird sequentiell geparst und für jedes gesehene Wort wird ein Paar (Wort, 1) ausgegeben. In der Reduce-Phase werden alle (Wort, 1)-Paare anhand des Wortes gruppiert weiterverarbeitet. reduce summiert für jedes Wort die Menge der Einsen auf und gibt jeweils ein Schlüssel-Wert-Paar der Form (Wort, Anzahl) aus. Abbildung 1 zeigt die Abarbeitung des Word Count-Progamms für zwei Dokumente aus Benutzersicht. Die Details der Ausführung und Parallelisierung 5

7 bleiben transparent, das MapReduce-Framework übernimmt u. a. die Schlüsselgenerierung, die Partitionierung und Verteilung der Eingabedaten auf Mapund Reduce-Prozesse sowie die Gruppierung der Zwischenergebnisse anhand des Schlüssels. Abbildung 1. WordCount für zwei Dokumente aus Sicht des Benutzers 2.3 Ausführung im Map-Reduce-Framework In diesem Abschnitt wird die Ausführung einer MapReduce-Aufgabe am Beispiel des Word Counts erläutert. Innerhalb des Benutzerprogramms wurden map und reduce wie in Beispiel 1 speziziert, es erfolgt ein Aufruf der MapReduce-Bibliothek mit den entsprechenden Eingabedaten. Ab diesem Zeitpunkt ist das Benutzerprogramm blockiert, das Map-Reduce-Framework übernimmt die Kontrolle und arbeitet folgende Schritte sukzessive ab. Abbildung 2 liefert einen Überblick über die Ausführung innerhalb des Frameworks. 1. Das Framework partitioniert die Eingabedaten, die Dokumentmenge, in M Chunks zu je 16 bis 64 MB und generiert für jeden Chunk einen Schlüssel. Sofern die Eingabedaten im GFS vorliegen, wird die Partitionierung übersprungen, da die Chunkgröÿen des GFS mit den von MapReduce benötigten Gröÿen kompatibel sind. Zur Wahl der Chunkgröÿen s. a. Abschnitt 2.5. Alle verfügbaren Knoten im Cluster werden nun für die Ausführung der folgenden MapReduce-Aufgabe vorbereitet, der Programmcode zur Ausführung von map und reduce wird auf die entsprechenden Knoten kopiert und geladen. 2. Das Framework wählt einen Knoten zur Koordinierung von MapReduce (Master), dies ist i. d. R. der Knoten, auf dem das Programm des Benutzers gestartet wurde. Alle weiteren Knoten (Worker) werden konkrete Map- oder 6

8 Abbildung 2. Überblick über die Ausführung eines MapReduce-Programms Reduce-Berechnungen (Jobs) ausführen. Der Master verwaltet alle Jobs und verteilt diese zusammen mit Schlüssel-Chunk-Paaren auf die Worker. Die Verteilung erfolgt kostenbasiert anhand der aktuellen Auslastung eines Workers und nach der physischen Nähe der zu bearbeitenden Chunks (siehe Abschnitt 2.5). Zudem speichert der Master für jeden Job den aktuellen Status (wartend, wird ausgeführt, fertig) und Identität des zugeordneten Workers. 3. Ein Map-Worker führt nun auf jedem Schlüssel-Chunk-Paar die benutzerdenierte map-methode aus und puert die Ergebnisse zunächst im eigenen Hauptspeicher. In unserem Beispiel wird für jedes Wort ein Paar (Wort, 1) als Zwischenergebnis gepuert. 4. In regelmäÿigen Abständen werden die gepuerten Schlüssel-Wert-Paare partitioniert auf die lokalen Festplatten der Worker geschrieben. Die Partitionierung erfolgt mit einer beliebigen Partitionierungsfunktion in R Partitionen, wobei R der Anzahl der folgenden Reduce-Jobs entspricht (siehe Abschnitt 2.5). Die Partitionierung garantiert, dass innerhalb eines Reduce-Jobs alle vorliegenden Daten für einen Schlüssel verarbeitet werden. Terminiert ein Map-Job, so werden die Informationen zur lokalen Speicherung (Speicherort, Dateiname, -gröÿe) an den Masterknoten gemeldet. 7

9 5. Jedem Reduce-Worker wird pro Reduce-Job eine Partition r R zugewiesen, Informationen zu den lokalen Speicherorten von r werden durch den Master inkrementell an die Reduce-Worker gesendet. Mit Hilfe von RPCs 4 wird r von den entsprechenden Map-Workern gelesen und anschlieÿend anhand des temporären Schlüssels sortiert 5. Im Fall des Word Counts erfolgt die Sortierung auf Basis der Worte. 6. Der Reduce-Worker iteriert über die sortierten Eingabepaare und wendet reduce auf jedes Eingabepaar an, für den Word Count wird für jeden Term die Liste der Einsen aufsummiert. Pro Partition legt der Reduce-Worker im GFS eine Ausgabedatei an und die Paare (Term, Summe) werden jeweils an diese Datei angehängt. 7. Nachdem alle Map- und Reduce-Jobs terminiert haben, weckt der Master das aufrufende Programm wieder auf. Der Benutzer hat nun Zugri auf die Ausgabe und kann diese weiter verarbeiten. 2.4 Fehlerbehandlung Sowohl [Cza08] als auch [DG08] erwähnen, dass Fehler oder Knotenausfälle bei MapReduce sehr häug auftreten, so ist z.b. während des Petabyte-Sortierexperiments in jedem Durchlauf mindestens ein Knoten ausgefallen. An dieser Stelle werden die wichtigsten Fehlerfälle und deren Behandlung innerhalb des MapReduce-Frameworks vorgestellt. Ausfall des Masterknotens: Der Master ist innerhalb von MapReduce der Single Point of Failure, da bei dessen Ausfall die Jobs zwischen den Map- und Reduce-Workern nicht mehr koordiniert werden können. In diesem Fall bricht die Abarbeitung ab und der Benutzer muss MapReduce erneut starten. Ein alternativer Ausführungsmodus des Frameworks sieht vor, dass der Master regelmäÿig Sicherungspunkte seiner Datenstrukturen in das globale GFS schreibt. Die Berechnung kann im Fehlerfall dann ab dem letzten Sicherungspunkt fortgesetzt werden. Master-Fehler sind i. A. unkritisch, da MapReduce meist im Rahmen analytischer Aufgaben eingesetzt wird. Ausfall eines Workers: Der Ausfall von Workern wird vom Master regelmäÿig durch eine ping-basierte 6 4 RPC (Remote Procedure Call) bezeichnet eine Technik zur Realisierung von Interprozesskommunikation, die den Aufruf von Funktionen in anderen Adressräumen ermöglicht. Die Semantik für den Empfang von Nachrichten in MapReduce entspricht At Most Once [BN97]. 5 Eine Sortierung ist immer dann notwendig, wenn pro Reduce-Job mehrere Schlüssel verarbeitet werden. 6 Ping überprüft die Erreichbarkeit von Hosts im Netzwerk. Dazu wird ein ICMP- Echo-Request-Paket an die Adresse des Zielhost gesendet, der Host antwortet mit 8

10 Routine überprüft. Falls ein Worker A nicht innerhalb einer denierten Zeitbeschränkung antwortet, erhält er den Status nicht verfügbar. Alle zu A zugewiesenen Jobs mit Status wartend oder ausführend werden erneut in die Warteschlange der Jobs eingereiht und auf andere Worker verteilt. Gleiches gilt für Map-Jobs, die A bereits abgeschlossen hat, da die Zwischenergebnisse nur auf den lokalen Festplatten von A und nicht im GFS verfügbar sind. Abgeschlossene Reduce-Jobs müssen dagegen nicht erneut ausgeführt werden, da deren Ergebnisse bereits im GFS vorliegen. Fehler im Programmcode des Benutzers: Die Fehlerlokalisierung und dessen Beseitigung kann in verteilten Umgebungen recht aufwendig und kostenintensiv werden. Für diesen Zweck existiert ein optionaler Ausführungsmodus, in dem die Map- und Reduce-Phasen sequentiell auf einer einzelnen Maschine ausführt werden können. Bei Fehlern in Fremdbibliotheken oder bei problematischen Datensätzen, die einen Programmabbruch provozieren, werden diese Teile der Eingabe registriert und beim nächsten Bearbeitungsversuch in MapReduce übersprungen. 2.5 Performance Backup-Tasks: Wie bereits erwähnt kommt es häuger zu Problemen bei einigen der benutzten Knoten. So werden Festplatten fehlerhaft und es werden automatische Fehlerkorrekturen nötig oder es müssen fehlerhafte Sektoren übersprungen werden und der Zugri wird stark verlangsamt. Andere Prozesse oder MapReduce-Tasks können parallel auf einer Maschine laufen und so die verfügbaren Resourcen einschränken. Daher benötigen Tasks auf diesen Knoten wesentlich länger als vergleichbare Tasks auf anderen Knoten. Um diesem natürlichen Problem entgegen zu wirken, werden Backup-Tasks benutzt: Nachdem ein überwiegender Teil der normalen Tasks abgeschlossen ist, betrachtet der Masterknoten die verbleibenden Knoten als Stragglers, also Nachzügler, die den gesamten MapReduce-Lauf aufhalten. Die auf diesen Maschinen bearbeiteten Tasks werden weiteren, bereits fertigen Knoten ein weiteres Mal zugeordnet und die Ausgabe des jeweils zuerst fertigen Tasks wird weitergeleitet, der andere Task abgebrochen. Dadurch lässt sich der Zeitaufwand um etwa 30% verringern [DG08]. Locality: Um Netzwerkbandbreite einzusparen, lässt sich ausnutzen, dass das GFS alle Daten über die lokalen Festplatten der Worker verteilt, üblicherweise drei Kopien auf verschiedene Maschinen. Der Master versucht nun, die Tasks auf genau die Worker zu verteilen, auf deren Festplatten die jeweils benötigten Eingabedaten vorliegen. Ist dies nicht möglich, wird versucht, zumindest einen Worker in der Nähe, also im selben Rack bzw. am selben Switch, auszuwählen. So ist es einem ICMP-Echo-Reply-Paket. Falls das Ziel nicht erreichbar ist, antwortet der zuständige Router mit Host unerreichbar. 9

11 in vielen Fällen nicht nötig, Eingabedaten erneut über das Netzwerk zu übertragen. In Abbildung 3 ist ein Beispielfall dargestellt. Task a, b und c werden jeweils auf Worker 1, 2 bzw. 3 verteilt, so dass die notwendigen Daten jeweils lokal vorliegen. Es gibt jedoch einen weiteren Task, der auf den Daten c operieren soll. Im Beispiel sind keine weiteren Worker vorhanden, die die Daten c lokal gespeichert haben, daher wird der Task einem freiem Worker in der Nähe der Daten zugeordnet, Worker 3. Dieser bezieht die nötigen Daten über eine Netzwerkverbindung. Abbildung 3. Beispiel für eine Locality-Optimierung Anzahl der Map- und Reduce-Jobs: Die Anzahl der Map- und Reduce-Jobs sollte in jedem Fall gröÿer sein als die Anzahl der involvierten Worker. Jeder Worker bearbeitet dann viele kleine anstelle weniger groÿer Aufgaben. Dies erweist sich als vorteilhaft bei der dynamischen Lastbalancierung und bei Worker-Ausfällen. Fällt ein Worker aus, so erzeugen die vielen kleinen anhängigen Jobs auf den Ersatzworkern wenig zusätzliche Last. Die Anzahl der Map-Jobs M hängt von der Gröÿe der Eingabedaten und der Größe der Eingabedaten Chunkgröÿe ab und ergibt sich aus M = Chunkgröße. Die Anzahl der Reduce-Jobs R beträgt ein kleines Vielfaches der Anzahl der involvierten Worker. Dean und Ghemawat beschreiben M = und R = bei Workern als typische Gröÿenordnungen für MapReduce-Aufgaben [DG04]. 10

12 3 Anwendungen und Implementationen MapReduce ist insbesondere für Datamining, lexikalische Analysen, maschinelles Übersetzen und Lernen und für Tokenerstellung und Indexierung entwickelt worden. Neben diesen Anwendungen, wie sie insbesondere bei der Verarbeitung von riesigen Datenmengen bei Google, Yahoo oder Anderen aufkommen, wird MapReduce auch verstärkt in weniger pragmatischen Bereichen eingesetzt. Darunter benden sich wissenschaftliche Anwendungen in der Teilchenphysik (HEP, k-means Clustering) und Astronomie [EP08]. Sehr ähnlich der Implementation von Google ist Hadoop aufgebaut, welches, anders als Googles Implementation, unter einer Open-Source-Lizenz verfügbar ist. Es wird als Top-Level-Projekt bei der Apache Software Foundation entwickelt und wird maÿgeblich von Yahoo für sehr ähnliche Aufgaben wie MapReduce bei Google eingesetzt. Google selbst hat bereits bemerkt, dass es unvorteilhaft ist, map- und reduce-funktionen direkt anzugeben und forscht daher daran, parallele Analyseprobleme mit einer höhen Programmiersprache zu lösen, welche unter dem Namen Sawzall entwickelt wird. 7 Auch für für Hadoop wird ein ähnliches Projekt unter dem Namen Pig 8 entwickelt. Weiterhin werden verschiedene Datenbanksysteme um MapReduce zur parallelen Datenverarbeitung ergänzt oder auch neue, teils relationale, Systeme auf MapReduce aufgebaut. CouchDB 9 ist ein noch sehr junges Projekt, das ein dokumentbasiertes Datenbanksystem implementiert, welches für parallele Berechnung automatisch MapReduce benutzt. Die beiden kommerziellen, parallelen Datenbanksysteme Greenplum 10 und Aster Data ncluster 11 wurden erst kürzlich um eine jeweils proprietäre MapReduce-Implementation ergänzt. Anders als bei CouchDB müssen diese bei beiden direkt durch Angeben der Map- und Reduce-Funktionen benutzt werden. Andere Open-Source-Projekte sind Hive 12, welches Hadoop um eine SQL-ähnliche Sprache erweitert und Cloudbase 13, welches Hadoop um ANSI-kompatibles SQL erweitert, so dass es kompatibel zu bestehenden Werkzeugen z.b. für Datamining bleibt. 4 MapReduceMerge Mit dem von Google vorgestellten MapReduce lassen sich viele Probleme ezient und einfach parallel implementieren. Insbesondere die Verarbeitung von in

13 Beziehung stehenden, heterogenen Datensätzen, wie sie z.b. bei Algorithmen für die relationalen Algebra vorkommen, werden jedoch durch die Beschränkung auf Map- und Reduce-Funktionen sehr erschwert. Ein Paar von Map- und Reduce- Funktionen ist jeweils immer nur auf ein bestimmtes Datenformat angepasst, erwartet also bestimmt Eingabedaten und berechnet bestimmte Ausgabedaten in einer Art Schema. MapReduceMerge ist eine Erweiterung von MapReduce, die genau aus diesem Grund eine weitere Merge-Phase einführt [YDHP07]. Dabei werden die nach Schlüsseln gruppierten Wert-Paare zweier unabhängiger Paare von Map- und Reduce-Funktionen einer ebenfalls vom Benutzer spezizierten Merge-Funktion übergeben und zusammen verarbeitet. normales MapReduce: map : (k 1, v 1 ) [(k 2, v 2 )] reduce : (k 2, [v 2 ]) [v 3 ] MapReduceMerge: 2 Sets von map und reduce: map 1 : (k 1, v 1 ) α [(k 2, v 2 )] α reduce 1 : (k 2, [v 2 ]) α (k 2, [v3]) α map 2 : (k 4, v 4 ) β [(k 5, v 5 )] β reduce 2 : (k 5, [v 5 ]) β (k 5, [v 6 ]) β merge der Ausgaben: merge : ((k 2, [v 3 ]) α, (k 5, [v 6 ]) β ) [(k 6, v 7 )] γ α, β und γ bezeichnen das Format der jeweiligen Zwischenwerte. Die beiden Stränge α und β werden beim Mergen in das Format γ überführt. In Abbildung 4 ist als typisches Beispiel ein Sort-Merge-Join dargestellt, der allein mit MapReduce schwierig umzusetzen ist. Angestellte und Abteilungen werden zuerst einzeln verarbeitet um jeweils Boni zu berechnen. Die linke Seite wird aufsummiert und Bonusanpassungen für die Abteilung bestimmt. Die Datensätze haben dabei zwei unterschiedliche Formate. Das Framework sortiert die Reduce-Ausgaben anhand ihrer Schlüsselnamen. Der im Normalfall verwendete Hash-Partitionierungsalgorithmus von MapReduceMerge ist für die Sortierung ungeeignet und wird durch eine einfachen Bereichspartitionierung ersetzt. Im Merge-Schritt ndet auch der Merge-Schritt des Algorithmus statt. Die Merge- Funktion erhält Reduce-Ausgaben über den gleichen Schlüsselbereich, iteriert über diese verschränkt und berechnet dabei die endgültigen Boni. Für die Umsetzung relationalen Algebra sind neben einem Join-Algorithmus weitere Operatoren umzusetzen: Projektion: eine einfache Map-Funktion, die jedes Tupel auf ein Schema projiziert 12

14 Abbildung 4. Sort-Merge Join mit MapReduceMerge[YDHP07] Selektion: lternde Map-, Reduce- oder Merge-Funktion, je nach Selektionsbedingung Kartesisches Produkt: die Merge-Funktion bekommt eine Partition des ersten Reducers und alle Partitionen des zweiten Reducers und iteriert dann verschachtelt über beide Vereinigung: beide Mapper haben die gleiche Bereichs-Partitionierung, die Merge-Funktion erhält von beiden Reducern Schlüssel über den gleichen Wertebereich um darin Duplikate zu entfernen Dierenz: ähnlich wie Vereinigung, die Merge-Funktion iteriert über sortierte Eingaben und entfernt gleiche Werten 5 Kritik David J. DeWitt und Michael Stonebreaker veröentlichten einen Blogeintrag [DS08] über MapReduce und die Ansichten der Autoren. MapReduce wird darin vor allem im Vergleich mit relationalen Datenbankmanagementsystemen betrachtet und dahingehend als a giant step backwards 13

15 bezeichnet. Ein MapReduce-Programmierer schreibe ähnlich wie in den 1970ern ein Codasyl-Programmierer Algorithmen für die direkte Datenmanipulation, was ähnlich wie das Benutzen von Assembler statt einer Hochsprache sei. MapReduce besitze im Gegensatz zu vielen relationalen Datenbanksystemen keine Schema- Unterstützung und damit auch keine Optimierungen wie B-Trees oder Indizes. MapReduce sollte zumindest ursprünglich jedoch nicht zur Datenspeicherung oder Archivierung genutzt werden sondern möglichst schnell sehr groÿe Datenmengen verarbeiten und dabei sehr hohe Ausfallwahrscheinlichkeiten tolerieren. Andererseits arbeitet MapReduce anders als eine benutzerdenierte Funktion (User Dened Function, UDF ) in einem Datenbanksystem in der Tat ohne Indizes, es werden immer alle Daten verarbeitet. Eine UDF kann auch einen kleineren relevanten Teil der Daten verarbeiten. Bei einem MapReduce-System muss also von Hand dafür gesorgt werden, dass die Eingabedaten relevant sind. Die Neuartigkeit der Verfahrensweise wird angezeifelt. Neben einigen wissenschaftlichen Veröentlichungen, u. a. auch von DeWitt selbst, wird Teradata als kommerzielles System genannt, das alle Prinzipien von MapReduce bereits seit 20 Jahren implementiert. Dabei beachten die Autoren jedoch nicht, dass MapReduce hauptsächlich wegen der zu geringen Fehlertoleranz bestehender paralleler Systeme entwickelt wurde, heben die gute Fehlertoleranz an anderer Stelle jedoch hervor. Zudem bemängeln DeWitt und Stonebreaker das Fehlen grundlegender relationaler Datenbankkonzepte wie Transaktionen, referentielle Integrität und Sichten. Diese sind jedoch für ein ausschlieÿlich verarbeitendes System gänzlich unerheblich bzw. nicht anwendbar. Insbesondere bei der Analyse von Daten werden diese meist sequentiell gelesen und es müssen alle Eingabedaten verarbeitet werden. Ein Groÿteil der Kritikpunkte ist so möglicherweise viel mehr als Wegweiser für Projekte geeignet, die auf MapReduce aufbauen und damit parallele Datenbankmanagementsysteme implementieren. 6 Fazit MapReduce ist kein paralleles DBMS, ist aber zur Datenverarbeitung in einigen Bereichen aufgrund von hoher Performanz und Skalierbarkeit besser geeignet. Zudem ist es durch die hohe Fehlertoleranz möglich, sehr viel günstigere Knoten in einem Rechnerverbund zu nutzen und dadurch Kosten zu sparen. Im Gegensatz zu existierenden parallelen Systemen ist die Installation und Wartung vereinfacht. Für Firmen wie Google und Yahoo hat sich MapReduce oenbar bewährt. In Zukunft werden bereits begonnene auf MapReduce aufbauende Entwicklungen wie Pig, Sawzall, Cloudbase und andere in der Praxis eingesetzt werden und es muss sich herausstellen, welche Stärken sie gegenüber herkömmlichen parallelen System behaupten können. 14

16 7 Literatur [BN97] Philip A. Bernstein and Eric Newcomer. Principles of transaction processing. Morgan Kaufmann, 5 edition, [Cza08] Grzegorz Czajkowski. Sorting 1PB with MapReduce, November [DG04] Jerey Dean and Sanjay Ghemawat. MapReduce: simplied data processing on large clusters. In Proceedings of the 6th conference on Symposium on Opearting Systems Design & Implementation - Volume 6, San Francisco, [DG08] CA, USENIX Association. Jerey Dean and Sanjay Ghemawat. MapReduce: simplied data processing on large clusters. Communications of the ACM, 51(1):107113, [DS08] David DeWitt and Michael Stonebreaker. MapReduce: a major step backwards - the database column [EP08] Jaliya Ekanayake and Shrideep Pallickara. Mapreduce for data intensive scientic analysis, [GGL03] Sanjay Ghemawat, Howard Gobio, and Shun-Tak Leung. The google le system. SIGOPS Operating Systems Review, 37(5):2943, [NS99] Chris Nyberg and Mehul Shah. Sort benchmark home page [OV99] M. Tamer Özsu and Patrick Valduriez. Principles of distributed database systems. Prentice Hall, [YDHP07] Hung-Chih Yang, Ali Dasdan, Ruey-Lung Hsiao, and D. Scott Parker. Mapreduce-merge: simplied relational data processing on large clusters. In Proceedings of the 2007 ACM SIGMOD international conference on Management of data, pages , Beijing, China, ACM. 15