Cloud Data Management

Transkript

1 Cloud Data Management Kapitel 6: Optimierungs- Dr. Anika Groß Sommersemester 2015 techniken für MapReduce Universität Leipzig Institut für Informatik

2 Optimierungstechniken (MR-Job-Parametrisierung) Anzahl der Map- und Reduce-Tasks (z.b. fünffache Knotenzahl) Datenkomprimierung Combiner zur Voraggregation des Map-Outputs Fehlerbehandlung Vermeiden der vollständigen Neuberechnung fehlgeschlagener Tasks Indexierung Indexierung der Eingabedaten eines Tasks und Ausnutzen während Anfrageverarbeitung, um komplettes Scannen der Eingabedaten zu vermeiden Lastbalancierung Beschleunigung von MapReduce-Programmen durch gleichmäßige Auslastung der verfügbaren Ressourcen

3 Hadoop: Ausführungsmodell Beispiel Map Reduce Prozesse Tasks (m) part group Prozesse Tasks (r)

4 Hadoop: Ausführungsmodell Tasktracker (TT) startet beim Hochfahren eine statisch konfigurierte Anzahl an Map- bzw. Reduce-Prozessen ( Slots ) Jeder Map/Reduce-Prozess kann zu einem Zeitpunkt einen Map-Task (=Eingabepartition) bzw. Reduce-Task (=Key-Gruppe) bearbeiten Pro MR-Job ist Anzahl an Reduce-Tasks vorgegeben (r) JT wählt TT zur Bearbeitung ausstehender Tasks eines MR-Jobs Map-Task Anwenden von map auf jedes Eingabe-Key-Value-Paar Ausgabepaare werden mittels part(key) partitioniert und mittels sort(key) sortiert (Sortierte) Partitionen werden im lokalen Dateisystem des TTs gespeichert Reduce-Task (Index i [0, r-1]) Zuständiger TT kopiert die Partition i der Zwischenergebnisse von allen TT Mischen der eingehenden (sortierten) Key-Value-Paare mit sort(key) Gruppieren der sortierten Key-Value-Paare Aufruf von reduce je Gruppe (Ergebnis HDFS)

5 Inhaltsverzeichnis Fehlerbehandlung Realisierung in Hadoop Optimierung nach [RAFT] Indexierung Hadoop++: Trojan Index & Trojan Join HAIL Lastbalancierung SkewTune Entity Resolution

6 Hadoop: Fehlerbehandlung Task Failure z.b. fehlerhafter Datensatz, Task-Timeout wegen konkurrierenden Zugriffen auf gemeinsame Ressourcen, Laufzeitfehler durch fehlerhaften MR-Code Tasktracker meldet failed Task wird an anderen Tasktracker vergeben Task schlägt 2x fehl, Speicherung des fehlerhaften Datensatzes im 3. Versuch 3. Versuch überspringt fehlerhaften Datensatz, bei Fehlschlag Job failed Tasktracker Crash/Shutdown Erkannt durch Ausbleiben von Heartbeat-Nachrichten JT entfernt TT aus Pool und weist ihm keine neuen Tasks mehr zu Neustarten aller laufenden Tasks des TTs Fertige Map-Tasks des TTs laufender Jobs werden neu vergeben, da Ergebnisse im lok. FS des Tasktrackers nicht mehr erreichbar sind Fertige Reduce-Tasks müssen i. Allg. nicht neugestartet werden (HDFS-Replikation) Tasktracker Slowdown - ausstehende Tasks mehrfach vergeben Speculative execution Jobtracker - Single Point of Failure

7 RAFT-Fehlerbehandlung: Überblick Ausgabe der Map-/Reduce-Funktion wird in HS-Puffer geschrieben Asynchrones Leeren und Materialisierung Ausschreiben eines Map-Puffers erzeugt r sortierte Partitionen (r=#reduce-tasks) Pull-Prinzip: TT für Reduce-Task i kopiert die Partition i von allen TT Behandlung von Task-Fehlern Vermeidung der Neuberechnung fehlgeschlagener Map-/Reduce-Tasks Ausnutzen, dass periodisch Ausgabedaten persistiert werden ( Checkpointing ) Fortsetzen ab dem letzten Checkpoint Behandlung von TT-Fehlern Vermeidung der Neuberechnung erfolgreicher Map-Tasks des gecrashten TTs Push -Prinzip: Nach Ausschreiben des Map-Puffers werden sortierte Partitionen sofort zu den entsprechenden TT kopiert Quelle für diese und die nächsten Folien: [RAFT]

8 map Fehlerbehandlung: Task-Fehler Beim Ausschreiben des Puffers wird zusätzlich ein Checkpoint geschrieben Identifier für Task, Identifier für spill (lokaler Pfad zu erfolgreich geschriebenen Daten) Offset des zuletzt vor Ausschreiben des Puffers gelesenen Bytes in Eingabedatenmenge JT weist fehlgeschlagenen Task demselben TT erneut zu TT prüft nach Zuweisung eines zuvor fehlgeschlagenen Tasks, ob ein konsistenter Checkpoint vorliegt Nein: Neuberechnung Ja: Seek zu Offset und Anwenden der map-funktion auf nächsten Datensatz Key Value 0 A 10 B 18 C 29 D 36 E Key v w x y z Value v,x 0 w 1 Ausschreiben des Puffers (r=2) + (task1, spilldirectory/file.txt, 18) Bei erneuter Ausführung: Fortsetzen ab Input-Key 29

9 Fehlerbehandlung: TT-Crash JT weist beim Start eines MR-Jobs jeden der r Reduce-Tasks statisch einem TT zu (z.b. TT auf node.domain.com bearbeitet reduce task 3 ) Nach Ausschreiben des Map-Puffers wird jede Partition 0 i<r zusätzlich zum TT kopiert, der den Reduce-Task i bearbeitet ( Push ) Lokale Partitionen Partitionen, deren entsprechende Reduce-Tasks demselben TT zugeordnet sind kein Kopieren erforderlich Zusätzlich loggt jeder Map-Task für jede Partition 0 i<r welche Input-Keys (z.b. File-Offset) dazu beitragen Bei Beendigung Replikation an andere Knoten Bsp.: r=3 part(key tmp )=key % 3 Key in Key tmp part(key tmp ) Reduce-Task 0 1 Key in Logfile

10 Fehlerbehandlung: TT-Crash (2) Crash TT a.domain.com:port Neuberechnung aller fehlgeschlagenen Map-Tasks des TTs a Teilweise Neuberechnung aller erfolgreichen Map-Tasks des TTs a Anwenden der Map-Funktion nur auf Eingabedaten, die zu lokalen Partitionen beitragen (nicht-lokale Partitionen sind bereits gepusht, lokale sind verloren) failed_red = { 0 i<r Reduce-Task i war TT a zugeordnet, aber nicht erfolgreich } Eingabedaten dieser reduce-tasks liegen zum Großteil noch im lokalen FS der übrigen TT vor Ausnahme: lokale Partitionen failed_red teilweise Neuberechnung der erfolgreichen Map-Task des TTs a Anwenden der Map-Funktion nur auf Eingabedaten, die zu einer Partition p failed_red beitragen Neuzuordnung der fehlgeschlagenen Reduce-Tasks zu TT durch JT Kopieren der Eingabedaten ( Pull ) und Neuberechnung der fehlgeschlagenen Reduce-Tasks

11 Fehlerbehandlung: TT-Crash (3) Bsp. failed_red= { 1 } Für alle von a erfolgreich bearbeiteten Map-Tasks Lese Logfiles aller Pufferleerungen (sind an anderen Knoten repliziert) Reduce-Task Key in , Anwenden der map-funktion auf Tupel mit Offset 0, 19 Anschließend sind verlorene lokale Partitionen wiederhergestellt Reduce-Task 1 kann von anderem TT neuberechnet werden Pull der nicht-lokalen Eingabepartitionen aus FS der anderen TT Pull der wiederhergestellten lokalen Partitionen

12 RAFT: Evaluation Ranking(pageURL, pagerank, avgduaration) 50GB UserVisits(sourceIP, visitedurl, visitdate) 1TB Q1: SELECT pageurl, pagerank FROM Rankings Q2: SELECT sourceip, SUM(adRevenue) FROM UserVisits GROUP BY sourceip Q3: SELECT sourceip, SUM(adRevenue) FROM UserVisits WHERE visitdate > GROUP BY sourceip (Q1) Einschränkung Nur anwendbar, wenn Ausgabe von map/ reduce ausschließlich von Eingabedaten abhängt (und nicht von zuvor gelesen Daten) Zustandslosigkeit Manueller Shutdown einer bestimmten Anzahl von TT (Mitte der Reduce-Phase)

13 Inhaltsverzeichnis Fehlerbehandlung Realisierung in Hadoop Optimierung nach [RAFT] Indexierung Hadoop++: Trojan Index & Trojan Join HAIL Lastbalancierung SkewTune Entity Resolution

14 Motivation Parallele DBS bei Anfragebearbeitung signifikant schneller als MapReduce, aber Skalierbarkeit nur für 100te von Knoten Aufwändige Administration und Konfiguration Hohe Lizenzgebühren Quelle: [MRDBS] Ziel: Beschleunigung von MapReduce-Programmen durch Portieren von DBS-Technologien auf Hadoop MapReduce-Programme, die relationale Operationen auf großen Datenmengen ausführen, führen stets Table-Scan durch Kein Index zur Anfragebeschleunigung Ansätze Hadoop++: Trojan Index und Trojan Join HAIL: Erzeugung mehrerer Indizes beim HDFS-Upload unter Ausnutzung der HDFS-Replikation

15 Trojan Index: Grundidee Eingabe für MapReduce-Programme wird in Input-Splits geteilt z.b: TextInputFormat erzeugt FileSplits: (hdfs://namenode:port/file.txt, offset, length) entsprechen HDFS-Blöcken Jeder Map-Task bearbeitet einen Split Schema der Daten und zu erwartende Anfragen bekannt Laden der Daten in HDFS Anreicherung jedes Splits um Index (bzgl. eines Attributes) zur Beschreibung der enthaltenen Daten Einschränken der zu lesenden Daten eines Splits während Anfrageverarbeitung Indexierter Split SData T: Nutzdaten des Splits (z.b. Zeilen eines CSV-Files) Header: #records, Größe der Daten und des Indexes, kleinster u. größter Key im Split Footer: Gesamtgröße des Splits ( + Split-Trennzeichen) Quelle für diese und die nächsten Folien: [Hadoop++]

16 Trojan Index: Generierung map(offset, record)=(split_id.a, record) Zusammengesetzter Schlüssel split_id: z.b. Filename+Start-Offset a: Indexattribut Record: alle Attribute des Datensatzes part(key) = hash(key.first) mod r Alle Datensätze eines Splits werden demselben Reduce-Task zugewiesen Sortierung ORDER By key.first, key.second group(key)= key.first Alle Datensätze eines Splits werden reduce (sortiert nach Indexattr.) übergeben reduce(unused, Iterator<Record>) Iterieren über alle Datensätze und unverändertes Ausschreiben in HDFS Parallel dazu Indexgenerierung Abschließendes Ausschreiben von Index, Header und Footer

17 Trojan Index: Bereichsanfrage auf Indexattribut Keine Änderungen am Hadoop-Framework Verwendung eigener UDFs Infect Hadoop from inside 1) Split-Generierung Zerlegung der Eingabedatenmenge in Map-Eingabesplits Für MR job über alle Files iterieren und InputStream abrufen Ende des Files bestimmen (kein vollst.scan) Footer vom File-Ende Lesen und Split- Größe bestimmen; offset auf Split-Anfang setzen Block Locations holen; logischen Split erzeugen und zur Liste der log. Splits hinzufügen

18 Trojan Index: Bereichsanfrage auf Indexattribut (2) 2) RecordReader (Initialisierung) Positionierung d. RecordReaders im Split in Abh. des Selektionsprädikates Bereichsanfrage mit (LowKey,HighKey) auf indexiertem Attribut Anfang, Ende von aktuellem Split bestimmen Index-Header lesen; Overlap-Typ bestimmen (=liegt LowKey or LowKey&HighKey or LowKey=HighKey im aktuellen Split?) Index lesen, offset setzen; offset = Position 1. Auftreten LowKey Split enthält HighKey oder umfasst gesamten Bereich offset auf Split-Anfang setzen Weder LowKey noch HighKey enthalten Split überspringen; 3) RecordReader (next) Offset innerhalb Split? Wenn ja, sequentiell Records einlesen bis HighKey erreicht Übergeben der Key-Value Paare an Mapper mit modifiziertem RecordReader (Anwendung Trojan Index) while(recordreader.next(key, value)){ map(key, value) }

19 Trojan Join: Grundidee Datenquellen T, S R = T (T.a=S.b) S Co-partitioning von T und S durch MapReduce-Job nach HDFS-Upload Anwenden derselben Partitionierungsfunktion auf beide Datenquellen Ziel: Kapselung zusammengehöriger Partitionen beider Datenquellen in einem Split (auf einem Datanode) Join der Partitionen kann durch TT lokal durchgeführt werden Map-only Job (keine Umverteilung, keine Reduce-Phase) Co-partitioned Split SData T k, Sdata S k : Partitionen von T/S mit demselben Join-Attributwert Ht, Hs: Header zur Trennung von Partitionen verschiedener Datenquellen Footer: Gesamtgröße des Splits ( + Split-Trennzeichen)

20 Trojan Join: Co-partitioning map(offset, record)= (a.0, record), wenn record T (b.1, record), wenn record S part(key) = hash(key.first) mod r Alle Datensätze beider Quellen mit demselben Join-Attributwert werden demselben Reduce-Task zugewiesen Sortierung ORDER By key.first, key.second group(key)= key.first Alle Datensätze mit demselben Join-Attributwert werden (sortiert nach Quelle) werden demselben Reduce-Task zugewiesen reduce(unused, Iterator<Record>) Reduce-Task erzeugt eine Co-group je Aufruf der reduce-funktion

21 Trojan Join Berechnung T (T.a=S.b) S Generierung der Splits für Eingabedaten durch Identifizieren der Footer (ähnlich Bereichsanfrage Trojan-Index) Record-Reader durchläuft den Split Überspringen der Trenn-Header Iteratives Aufrufen von map(joinkey, record) Map-Task speichert Datensätze von T im HS Wechsel des Join-Keys (joinkey lastkey) Leeren der Liste Keine Reduce-Phase Kombination von Co-partitioning und Trojan Index möglich

22 Hadoop++: Evaluation SELECT pageurl, pagerank FROM Rankings WHERE pagerank>10; -- (Rankings: 18Mio/1GB) SELECT sourceip, COUNT(pageRank), SUM(pageRank), SUM(adRevenue) FROM Rankings AS r, UserVisits AS v WHERE r.pageurl=v.desturl AND v.visitdate BETWEEN AND GROUP BY v.sourceip; -- (UserVists: 155Mio/20GB) HDFS-Upload & Indexgenerierung Aufwändig Einmalig Kann beliebig oft verwendet werden