Fernuniversität in Hagen

Größe: px
Ab Seite anzeigen:

Download "Fernuniversität in Hagen"

Transkript

1 Fernuniversität in Hagen Sommersemster 2011 Seminar MapReduce und Datenbanken Prof. Dr. Ralf Hartmut Güting Simone Jandt c Fernuniversität in Hagen, Juni 2011

2 Inhaltsverzeichnis 1 Allgemeines 2 2 Themen Klassische Parallele Datenbanken Thema 1: Parallele Datenbanken Thema 2: Parallele Anfrageauswertung in Volcano Thema 3: MapReduce und Hadoop Thema 4: Parallele Datenbanken vs. MapReduce Datenbanken und MapReduce Thema 5: HadoopDB Thema 6: Dryad Thema 7: DryadLINQ Thema 8: PigLatin Thema 9: SCOPE Thema 10: Osprey Joins Thema 11: Map-Reduce-Merge Thema 12: Optimierung von Joins Thema 13: Spatial Join Thema 14: MapReduce für Multicore Rechner Thema 15: Strom- bzw. Onlineverarbeitung mit MapReduce Anwendungen Thema 16: Ähnlichkeitssuche auf Mengen Thema 17: Clustern von dynamischen Datenmengen Thema 18: Mustererkennung in Netzwerken Thema 19: Effiziente Graphanalyse Thema 20: Spezielle Anwendungen Weitere mögliche Themen Thema 21: Performance in gemischten Umgebungen Thema 22: Sicherheit verteilter Datenbanken Ausarbeitungen Parallele Anfrageauswertung mit Volcano MapReduce und Hadoop HadoopDB Dryad DryadLINQ PigLatin SCOPE Osprey Map-Reduce-Merge Optimierung von Joins Spatial Join with MapReduce MapReduce für Multicore Rechner Stromverarbeitung mit MapReduce Ähnlichkeitssuche auf Mengen

3 1 Allgemeines Im Jahr 2004 wurde von Entwicklern der Firma Google ein einfaches Modell für die parallele Programmierung und Verarbeitung sehr großer Datenmengen namens MapReduce vorgestellt. Ein Programmierer implementiert dabei eine map-methode, die ein Paar der Form (Schlüssel, Wert) in eine Menge von (Schlüssel, Wert)-Paaren transformiert, sowie eine reduce-methode, die eine Menge von Werten zu einem gegebenen Schlüssel zu einem einzigen Wert reduziert. Das MapReduce-Ausführungssystem sorgt dafür, dass die vom Programmierer definierten mapund reduce-methoden parallel auf beliebig vielen Rechnern ausgeführt werden und dass eine reduce- Methode alle Werte zu einem gegebenen Schlüssel erhält, die ja von vielen map-methoden auf anderen Rechnern erzeugt wurden. Gleichzeitig garantiert es Fehlertoleranz, d.h., Ausfälle einzelner Rechner werden vom Gesamtsystem abgefangen und führen nicht einmal zu nennenswerten Verzögerungen. Das Gleiche gilt für einzelne Rechner, die nur sehr langsam arbeiten; ihre Aufgaben werden automatisch auf andere Rechner verlagert. Solche Eigenschaften sind essentiell für hoch skalierbare Anwendungen, bei denen Tausende von Rechnern Terabytes von Daten verarbeiten. Gleichzeitig ermöglicht das Modell Programmierern, ohne Vorkenntnisse der Parallelverarbeitung mit einfachen Programmen enorme Datenmengen effizient zu verarbeiten. Das Modell hat Furore gemacht, unter anderem dadurch, dass eine Open-Source-Implementierung unter dem Namen Hadoop frei verfügbar ist. Die Datenbankwelt geriet zunächst in eine Defensivposition und versuchte zu zeigen, dass die in jahrzehntelanger Forschung entwickelten hochoptimierten parallelen Datenbanksysteme doch noch Performanzvorteile haben. Es ließ sich aber nicht leugnen, dass parallele Datenbanksysteme höchstens für einige Dutzend Computer konzipiert waren und deshalb nicht die gleichen Fehlertoleranzqualitäten besitzen. Außerdem sind Lizenzen für solche Systeme sehr teuer. Seit einigen Jahren sind Versuche der Kopplung von MapReduce-Techniken bzw. Hadoop mit Datenbanken ein heißes Thema in der Datenbankforschung. Solche Ansätze und die Bearbeitung von Datenbankaufgaben mit MapReduce-Techniken sind Thema des Seminars. Im Abschnitt 2 stellen wir Ihnen die für das Seminar vorgesehen Themen kurz vor. Bevor wir die Ausarbeitungen der Studenten zu den erfolgreich bearbeiteten Themen in Abschnitt 3 präsentieren. 2 Themen 2.1 Klassische Parallele Datenbanken Der erste Vortragsblock bietet einen Überblick über die vor MapReduce existierenden Mechanismen für parallele Datenbanken und Datenverarbeitung Thema 1: Parallele Datenbanken [DG92] beschreibt die grundlegenden Ziele und Techniken der parallelen Datenverarbeitung Thema 2: Parallele Anfrageauswertung in Volcano Volcano [Gra90, GD93] beschreibt eine Schnittstelle, die die eigentliche Hardware-Architektur kapselt und sich um die Details der parallelen Ausführung von Datenbankoperationen kümmert. So können Operatoren, die diese Schnittstelle bedienen und die ursprünglich für Ein-Prozessor- Systeme konzipiert und optimiert wurden auch in parallelen Datenbankumfeld eingesetzt werden. 2

4 2.2 Thema 3: MapReduce und Hadoop Das von Google entwickelte MapReduce Framework [DG04] basiert auf dem Google File System [GGL03]. Seine Open-Source-Implementierung Hadoop [Had11] bringt mit HDFS ein eigenes verteiltes Filesystem mit. 1 Die Grundidee des MapReduce ist in allen weiteren Vorträgen enthalten, deshalb soll es hier mehr um die technischen Hintergründe des MapReduce-Verfahrens und die Sicherstellung seiner Zusicherungen der Fehlertoleranz und der Korrektheit gehen. 2.3 Thema 4: Parallele Datenbanken vs. MapReduce Wie in der Seminarankündigung erwähnt, war der Einsatz von MapReduce im Datenbankumfeld nicht unumstritten. Während die eine Seite die Vorteile der MapReduce-Techniken feierte und alles über MapReduce lösen wollte, beriefen sich die Verfechter herkömmlicher paralleler Datenbanksysteme auf die Vorteile des Einsatzes von Indexen und andere Stärken, paralleler Datenbanksysteme, die von MapReduce nicht unterstützt werden. Eine Diskussion der Stärken und Schwächen beider Systeme bei der Verarbeitung großer Datenmengen findet sich u.a. in [PPR + 09, SAD + 10, DS08a] und [DS08b]. 2.4 Datenbanken und MapReduce In diesem Vortragsblock werden verschiedene auf dem MapReduce Ansatz basierende bzw. von ihm beeinflusste Datenbanksysteme und ihre Anfragesprachen vorgestellt Thema 5: HadoopDB Hadoop selbst ist keine Datenbank, sondern nur eine Open-Source-Implementierung des MapReduce-Frameworks. [ABPA + 09] beschreibt die Verknüpfung von PostgreSQL und Hadoop mittels Hive [TSJ + 09] zu einer kompletten Open-Source-Lösung für die verteilte Speicherung und parallele Auswertung großer Datenmengen mittels MapReduce-Techniken in Rechnerclustern Thema 6: Dryad Microsoft entwickelte mit Dryad [IBY + 07] ein mit MapReduce vergleichbares System zur verteilten parallelen Abwicklung von Datenbankabfragen in Clustern. Neben der Vorstellung des Dryad- Systems soll es hier auch um die Gemeinsamkeiten und Unterschiede der beiden Systeme gehen Thema 7: DryadLINQ DryadLINQ [YIF + 08, IY09] stellt auf der Basis von.net-objekten eine Menge von Spracherweiterungen zur Verfügung, die ein neues Programmiermodell für verteilte Anwendungen bilden Thema 8: PigLatin Grundlage für den sinnvollen Einsatz von MapReduce im Datenbankumfeld ist die Schaffung entsprechender Schnittstellen zwischen der Datenbankanfragesprache und dem prozeduralen Map- Reduce-Framework. PigLatin von Yahoo! [ORS + 08] ist ein Ansatz die Lücke zwischen SQL und MapReduce zu schließen. 1 Wer für die Ausarbeitung seines Themas vorab tiefere Informationen zu MapReduce benötigt, als in seinem Originaltext vorhanden sind, kann eine Kurzbeschreibung des MapReduce Frameworks in [DG08] finden. 3

5 2.4.5 Thema 9: SCOPE SCOPE von Microsoft [CJL + 08] versucht analog zu PigLatin die Lücke zwischen SQL und MapReduce zu schließen Thema 10: Osprey [YYTM10] ist ein von der MapReduce Idee beeinflusstes System, das in verteilten Datenbanken die fehlertolerante Ausführung von Anfragen, wie Sie bei MapReduce gegeben ist, sicherstellen soll. 2.5 Joins Ein großes Thema in der Datenbankwelt ist der Verbund (Join) mehrerer Eingangsrelationen zu einer Ausgangsrelation. In den letzten Jahren wurden diverse Ansätze veröffentlicht, die den Verbund von Datenmengen mittels MapReduce ermöglichen sollen Thema 11: Map-Reduce-Merge [YDHP07] erweitert das MapReduce-Framework um eine Merge-Komponente, die die parallele Ausführung relationaler Operationen, insbesondere auch von Joins, ermöglicht Thema 12: Optimierung von Joins Die Optimierung der Ausführung von Operationen ist im Datenbankumfeld immer ein heißes Thema gewesen. So beschäftigt sich [AU10] mit der Optimierung von Join-Operationen im MapReduce- Umfeld Thema 13: Spatial Join Insbesondere im Umfeld geographischer Datenbanken ist die Zusammenführung von Daten nach räumlicher Nähe ein Thema. [ZHL + 09] beschreibt den Einsatz von MapReduce-Techniken für die effiziente parallele Durchführung von Spatial-Join-Operationen. 2.6 Thema 14: MapReduce für Multicore Rechner [CCZ10] verfeinert die MapReduce-Techniken, um die Datenanalyse auf Rechnern mit vielen Prozessorkernen, die über eine gemeinsame Datenbasis verfügen, zu optimieren. 2.7 Thema 15: Strom- bzw. Onlineverarbeitung mit MapReduce Das Grundkonzept von MapReduce ermöglicht zunächst keine Strom- bzw. laufende Online-Verarbeitung von Daten. [CCA + 10,KAGW10] und [BAH10] sind drei Erweiterungen des MapReduce Frameworks, die eine Strom- bzw. Online-Verabeitung auf der Basis von MapReduce-Techniken ermöglichen. Hier reicht es, ein Modell ausführlich darzustellen und mit den anderen kurz zu vergleichen. 2.8 Anwendungen Inzwischen finden MapReduce-Techniken vielfältige Anwendungen im Datenbankumfeld. Ein paar davon sollen im Folgenden vorgestellt werden. 4

6 2.8.1 Thema 16: Ähnlichkeitssuche auf Mengen [VCL10] ermöglicht die Ermittlung und Gruppierung ähnlicher Datensätze mittels erweiterter MapReduce-Techniken Thema 17: Clustern von dynamischen Datenmengen Bei Google News [DDGR07] werden MapReduce-Verfahren eingesetzt, um ständig die aktuellen Nachrichten verschiedener Quellen zu gleichen Themenkomplexen für Newsportale zusammenzuführen Thema 18: Mustererkennung in Netzwerken Bei der Analyse großer Netzwerke treten wiederkehrende Muster auf. Diese können laut [LJC + 09] auch mit MapReduce-Techniken ermittelt werden Thema 19: Effiziente Graphanalyse [LS10] beschäftigt sich mit der Optimierung der Analyse komplexer Graphen mit MapReduce- Techniken Thema 20: Spezielle Anwendungen Zum Schluß beschäftigen wir uns mit drei konkreten auf MapReduce basierenden Anwendungen, die zum Teil auch über graphische Benutzerschnittstellen verfügen. Eins der Systeme sollte ausführlich dargestellt werden, bei den anderen reicht eine kurze Beschreibung. [WPR + 08] stellt eine einfach zu bedienende Benutzerschnittstelle zur Verfügung, die es einfachen Anwendern ermöglicht große in einem Web Archiv abgelegte Dokumentmengen zu analysieren. [Haz10] beschreibt den Einsatz von MapReduce-Techniken im Zusammenhang mit der Abfrage von Protein Datenbanken. [JVB09] beschreibt die Parallelisierung Genetischer Algorithmen mit MapReduce-Techniken. 2.9 Weitere mögliche Themen Thema 21: Performance in gemischten Umgebungen Die Fehlertoleranz von Hadoop ist auf Cluster mit identischer Hard- und Software ausgelegt. In der Realität gibt es aber vielfach unterschiedliche Plattformen, die gemischt verwendet werden. [ZKJ + 08] beschreibt, wie Hadoop verbessert werden kann, um auch in solchen gemischten Rechnerumgebungen die Fehlertoleranz zu gewährleisten Thema 22: Sicherheit verteilter Datenbanken MapReduce wird nicht zuletzt auch auf großen teilweise öffentlichen Clustern eingesetzt. Mit der Frage, wie in diesen öffentlichen Umgebungen der Schutz der Daten und der Privatsphäre sichergestellt werden kann beschäftigt sich [RSK + 10]. 5

7 Literatur [ABPA + 09] Abouzeid, A. ; Bajda-Pawlikowski, K. ; Abadi, D. ; Silberschatz, A. ; Rasin, A.: HadoopDB: An architectural hybrid of MapReduce and DBMS technologies for analytical workloads. In: Proceedings of the VLDB Endowment 2 (2009), Nr. 1, S ISSN [AU10] [BAH10] Afrati, F.N. ; Ullman, J.D.: Optimizing Joins in a Map-Reduce Environment. In: Proceedings of the 13th International Conference on Extending Database Technology ACM, 2010, S Böse, J.H. ; Andrzejak, A. ; Högqvist, M.: Beyond Online Aggregation: Parallel and Incremental Data Mining With Online Map-Reduce. In: Proceedings of the 2010 Workshop on Massive Data Analytics on the Cloud ACM, 2010, S. 1 6 [CCA + 10] Condie, T. ; Conway, N. ; Alvaro, P. ; Hellerstein, J.M. ; Elmeleegy, K. ; Sears, R.: MapReduce Online. In: Proceedings of the 7th USENIX Conference on Networked Systems Design and Implementation USENIX Association, 2010, S. 21 [CCZ10] [CJL + 08] [DDGR07] [DG92] [DG04] [DG08] Chen, R. ; Chen, H. ; Zang, B.: Tiled-MapReduce: Optimizing Resource Usages of Data-Parallel Applications on Multicore with Tiling. In: Proceedings of the 19th international conference on Parallel architectures and compilation techniques ACM, 2010, S Chaiken, R. ; Jenkins, B. ; Larson, P.Å. ; Ramsey, B. ; Shakib, D. ; Weaver, S. ; Zhou, J.: SCOPE: Easy and efficient parallel processing of massive data sets. In: Proceedings of the VLDB Endowment 1 (2008), Nr. 2, S ISSN Das, A.S. ; Datar, M. ; Garg, A. ; Rajaram, S.: Google News Personalization: Scalable Online Collaborative Filtering. In: Proceedings of the 16th international conference on World Wide Web ACM, 2007, S DeWitt, D. ; Gray, J.: Parallel Database Systems: The Future of High Performance Database Systems. In: Communications of the ACM 35 (1992), Nr. 6, S ISSN Dean, J. ; Ghemawat, S.: MapReduce: Simplified Data Processing on Large Clusters. In: Proceedings of Operating Systems Design and Implementation (OSDI). San Francisco, CA, 2004, S Dean, J. ; Ghemawat, S.: MapReduce: Simplified Data Processing on Large Clusters. In: Communications of the ACM 51 (2008), January, Nr. 1, S [DS08a] DeWitt, J. ; Stonebraker, M.: MapReduce A Major Step Backwards. Web Blog. mapreduce-a-major-step-backwards/. Version: 2008 [DS08b] DeWitt, J. ; Stonebraker, M.: MapReduce II. Web Blog. http: //databasecolumn.vertica.com/database-innovation/mapreduce-ii/. Version: 2008 [GD93] Graefe, G. ; Davison, DL: Encapsulation of Parallelism and Architecture- Independence in Extensible Database Query Execution. In: IEEE Transactions on Software Engineering 19 (1993), Nr. 8, S ISSN

8 [GGL03] [Gra90] Ghemawat, S. ; Gobioff, H. ; Leung, S.-T.: The Google File System. In: 19th Symposium on Operating Systems Principles. Lake George, New York, 2003, S Graefe, Goetz: Encapsulation of parallelism in the Volcano Query Processing System. In: Proceedings of the 1990 ACM SIGMOD international conference on Management of data. New York, NY, USA : ACM, 1990 (SIGMOD 90). ISBN , [Had11] Hadoop. Web Page. Version: 2011 [Haz10] [IBY + 07] [IY09] [JVB09] Hazelhurst, S.: PH2: An Hadoop-Based Framework for Mining Structural Properties from the PDB Database. In: Proceedings of the 2010 Annual Research Conference of the South African Institute of Computer Scientists and Information Technologists ACM, 2010, S Isard, M. ; Budiu, M. ; Yu, Y. ; Birrell, A. ; Fetterly, D.: Dryad: distributed data-parallel programs from sequential building blocks. In: ACM SIGOPS Operating Systems Review 41 (2007), Nr. 3, S ISSN Isard, M. ; Yu, Y.: Distributed data-parallel computing using a high-level programming language. In: Proceedings of the 35th SIGMOD international conference on Management of data ACM, 2009, S Jin, C. ; Vecchiola, C. ; Buyya, R.: MRPGA: An Extension of MapReduce for Parallelizing Genetic Algorithms. In: escience, escience 08. IEEE Fourth International Conference on IEEE, 2009, S [KAGW10] Kumar, V. ; Andrade, H. ; Gedik, B. ; Wu, K.L.: DEDUCE: At the Intersection of MapReduce and Stream Processing. In: Proceedings of the 13th International Conference on Extending Database Technology ACM, 2010, S [LJC + 09] Liu, Y. ; Jiang, X. ; Chen, H. ; Ma, J. ; Zhang, X.: Mapreduce-based pattern finding algorithm applied in motif detection for prescription compatibility network. In: Advanced Parallel Processing Technologies (2009), S [LS10] [ORS + 08] Lin, J. ; Schatz, M.: Design Patterns for Efficient Graph Algorithms in MapReduce. In: Proceedings of the Eighth Workshop on Mining and Learning with Graphs ACM, 2010, S Olston, C. ; Reed, B. ; Srivastava, U. ; Kumar, R. ; Tomkins, A.: Pig latin: a notso-foreign language for data processing. In: Proceedings of the 2008 ACM SIGMOD International Conference on Management of Data ACM, 2008, S [PPR + 09] Pavlo, A. ; Paulson, E. ; Rasin, A. ; Abadi, D.J. ; DeWitt, D.J. ; Madden, S. ; Stonebraker, M.: A Comparison of Approaches to Large-Scale Data Analysis. In: Proceedings of the 35th SIGMOD International Conference on Management of Data ACM, 2009, S [RSK + 10] Roy, I. ; Setty, S.T.V. ; Kilzer, A. ; Shmatikov, V. ; Witchel, E.: Airavat: Security and Privacy for MapReduce. In: Proceedings of the 7th USENIX Conference on Networked Systems Design and Implementation USENIX Association, 2010, S. 20 7

9 [SAD + 10] [TSJ + 09] Stonebraker, M. ; Abadi, D. ; DeWitt, D.J. ; S.Madden ; Paulson, E. ; Pavlo, A. ; Rasin, A.: MapReduce and Parallel DBMSs: Friends or Foes? In: Communications of the ACM 53 (2010), January, Nr. 1, S DOI / Thusoo, A. ; Sarma, J.S. ; Jain, N. ; Shao, Z. ; Chakka, P. ; Anthony, S. ; Liu, H. ; Wyckoff, P. ; Murthy, R.: Hive: a warehousing solution over a map-reduce framework. In: Proceedings of the VLDB Endowment 2 (2009), Nr. 2, S ISSN [VCL10] Vernica, R. ; Carey, M.J. ; Li, C.: Efficient parallel set-similarity joins using MapReduce. In: Proceedings of the 2010 international conference on Management of data ACM, 2010, S [WPR + 08] [YDHP07] [YIF + 08] [YYTM10] Weigel, F. ; Panda, B. ; Riedewald, M. ; Gehrke, J. ; Calimlim, M.: Largescale collaborative analysis and extraction of web data. In: Proceedings of the VLDB Endowment 1 (2008), Nr. 2, S ISSN Yang, H. ; Dasdan, A. ; Hsiao, R.L. ; Parker, D.S.: Map-reduce-merge: simplified relational data processing on large clusters. In: Proceedings of the 2007 ACM SIGMOD international conference on Management of data ACM, 2007, S Yu, Y. ; Isard, M. ; Fetterly, D. ; Budiu, M. ; Erlingsson, Ú. ; Gunda, P.K. ; Currey, J.: DryadLINQ: A System for General-Purpose Distributed Data-Parallel Computing Using a High-Level Language. In: Proceedings of the 8th USENIX conference on Operating systems design and implementation USENIX Association, 2008, S Yang, C. ; Yen, C. ; Tan, C. ; Madden, S.R.: Osprey: Implementing MapReduce- Style Fault Tolerance in a Shared-Nothing Distributed Database. In: Data Engineering (ICDE), 2010 IEEE 26th International Conference on IEEE, 2010, S [ZHL + 09] Zhang, S. ; Han, J. ; Liu, Z. ; Wang, K. ; Xu, Z.: SJMR: Parallelizing Spatial Join with MapReduce on Clusters. In: Cluster Computing and Workshops, CLUSTER 09. IEEE International Conference on IEEE, ISSN , S. 1 8 [ZKJ + 08] Zaharia, M. ; Konwinski, A. ; Joseph, A.D. ; Katz, R. ; Stoica, I.: Improving MapReduce Performance in Heterogeneous Environments. In: Proceedings of the 8th USENIX conference on Operating systems design and implementation USENIX Association, 2008, S

10 3 Ausarbeitungen 9

11 Fern-Universität in Hagen - Seminar im Sommersemester 2011 MapReduce und Datenbanken Thema 2 Parallele Anfrageauswertung in Volcano Referent: Simon Geisbüsch

12 Gliederung zum Thema 2: Parallele Anfrageauswertung in Volcano 1 Einführung 2 Designziele 2.1 Erweiterbarkeit 2.2 Parallelität 2.3 Unabhängigkeit 3 Grundlegendes Systemdesign 3.1 Dateisystem und Support-Funktionen 3.2 Operatoraufbau und der Operatorbaum 4 Inter-Operator-Parallelität 4.1 Der Exchange-Operator 4.2 Pipelining/Streaming 4.3 Teilbaum-Parallelität im Operatorbaum 4.4 Verwaltungsaufwand 5 Intra-Operator-Parallelität 5.1 Datenpartitionierung 6 Der erweiterte Exchange-Operator 6.1 Verarbeitungsknoten 6.2 Vektorbasierte Verarbeitung 6.3 Verwaltungsaufwand 7 Leistungsmerkmale und -fähigkeiten 7.1 Erweiterbarkeit, Parallelität, Unabhängigkeit, Skalierbarkeit 7.2 Verwaltungsaufwand

13 1 Einführung Einzelne Datenbankanfragen in mehreren Prozessen parallel zu verarbeiten kann große Leistungssteigerungen in einem Datenbanksystem erzeugen. Unterschiedliche Hardwaredesigns von Verarbeitungsknoten (shared vs. distributed memory) 1 und der Netzwerkübertragung führten zu der Idee, die Hardwarekomponente so weit wie möglich von den Abläufen der parallelen Anfrageauswertung zu kapseln. Ebenso wie die Hardwarebegebenheiten kann auch die Datenverarbeitung in der Anfrageauswertung vollständig vom Verarbeitungsmechanismus zur Erzeugung paralleler Prozesse in einer Anfrageauswertung gekapselt werden. Das Modul Volcano wurde mit der Intention, genau diese weitreichende Flexibilität herzustellen, entworfen und soll im Folgenden vorgestellt werden. 2 Kapitel 2 beschreibt die Designziele und Überlegungen zu den Themenschwerpunkten Erweiterbarkeit, Parallelität und Unabhängigkeit im Bezug zum Systemaufbau der Anfrageauswertung. Kapitel 3 stellt die Grundlagen des Dateisystems und der Datenverarbeitung sowie den Operatoraufbau und die Generierung eines Operatorbaums aus einer Datenbankanfrage vor. Kapitel 4 beschäftigt sich ausführlich mit den Abläufen zu parallelen Ausführung verschiedener Operatoren (Inter-Operator-Parallelität), während Kapitel 5 die Möglichkeiten zur parallelen Ausführung innerhalb eines einzelnen Operators beleuchtet (Intra-Operator-Parallelität). Kapitel 6 betrachtet die Verarbeitung einer Anfrage im Falle auf mehrere Netzwerkknoten verteilter Prozesse. Kapitel 7 fasst die Ergebnisse bezogen auf die Zielerreichung der Designideen in Volcano zusammen und schließt mit einer Bewertung der Leistungsfähigkeit des Systems auch im Hinblick auf moderne Hardwaredesigns und Netzwerkübertragungsgeschwindigkeiten ab. 2 Designziele 2.1 Erweiterbarkeit Erweiterbarkeit kann in diesem Zusammenhang auf mehrere verschiedene Arten interpretiert werden. Zum einen kann sich die Erweiterbarkeit auf die Datentypen beziehen, die in einer Datenbank hinterlegt werden. Eine Anfrageauswertung sollte problemlos verschiedenste Datentypen verarbeiten können, um flexibel eingesetzt werden zu können. Vor allem mit dem Aufkommen objektorientierter Programmiersprachen und der Forderung nach persistenter Speicherung verschiedenster Objekte und damit Datentypen ist diese Form der Erweiterbarkeit ein wichtiges Merkmal geworden. Volcano wurde auch für die Möglichkeit geschaffen auch im 1 Im Falle von shared-memory teilen sich Prozesse einen gemeinsamen Pufferspeicher, bei distributed-memory ist eine gemeinsame Adressierung und damit die Übergabe von Zeigern nicht möglich. 2 Grundlage der Erläuterungen sind [1] (Graefe 1990) und [2] (Graefe, Davidson 1993) 1

14 objektorientierten Umfeld eingesetzt zu werden. 3 Daraus ergibt sich sofort die Forderung auch Operatoren, die für verschiedene Datentypen nötig werden können, einfach in das System zu integrieren. Ist diese Forderung bei einfacher sequenzieller Ausführung noch recht einfach erfüllbar, ergeben sich durch eine parallele Auswertung unter Umständen erhebliche Schwierigkeiten bei der Erstellung neuer Operatoren. Schließlich sollte auch das Hardwareumfeld der Datenbank erweiterbar und veränderbar sein. Die schnelle Entwicklung im Hardwarebereich, sowohl bezüglich der Speicher und Prozessoren als auch der Netzwerktechnologie, macht eine einfache Anpassung unabdingbar. 2.2 Parallelität Gerade durch die parallele Verarbeitung innerhalb einer einzelnen Anfrage lassen sich enorme Leistungsverbesserungen erzielen. Unterstützt wird diese Entwicklung auch durch die schnelle Entwicklung der Hardware. War ein Verarbeitungsnetz mit shared-memory und mehreren Prozessoren bei der Entwicklung von Volcano noch ein komplizierter Aufbau mehrerer einzelner Rechner, findet sich dieses Hardwaredesign mittlerweile in einem handelsüblichen PC wieder. Parallelität kann dabei sehr verschiedene Formen annehmen. Die einfachste Form der parallelen Auswertung ist das Streaming. Ein Operator beginnt dabei bereits mit Teilen des Ergebnisses eines vorher aktiven Operators zu arbeiten, ohne dass dessen gesamtes Ergebnis bereits erstellt und vollständig gespeichert wurde. Findet Streaming in einem einzigen Prozess statt, beschreibt Pipelining die parallele Verarbeitung über Prozessgrenzen hinweg. Pipelining und Streaming werden auch als vertikale Parallelität bezeichnet. Eine andere Form ist die Teilbaum-Parallelität, also die Auswertung von verschiedenen unabhängigen Teilbäumen eines Operatorbaums. Streaming und die Teilbaum-Parallelität gehören damit zu den Inter-Operator- Parallelitäten. Eine weitere Form ist die parallele Auswertung innerhalb eines Operators, die z.b. durch Datenpartitionierung erreicht werden kann. Verschiedene Partitionen werden gleichzeitig von verschiedenen identischen Operatoren in verschiedenen Prozessen verarbeitet und das Ergebnis zusammengetragen. Diese Form gehört damit zur Intra-Operator-Parallelität. Teilbaumund Intra-Operator-Parallelität werden auch als horizontale Parallelität bezeichnet. In Volcano werden alle für die Erstellung dieser Arten von Parallelität nötigen Elemente bereitgestellt, unter der Vorgabe, möglichst wenig Verwaltungsaufwand zu erzeugen. 2.3 Unabhängigkeit Erweiterbarkeit und Parallelität werden in Volcano durch Kapselung, d.h. durch die 3 [3](Graefe 1994, III.B Seite 124) 2

15 Unabhängigkeit der verschiedenen Instrumente erreicht. [3] Graefe beschreibt diese Kapselung von Parallelität des Verarbeitungsmechanismus zur Datenverarbeitung als orthogonal zueinander. 4 So werden die Datentypen in Volcano nicht definiert, sondern eine datentypenunabhängige Verarbeitungsmethode geschaffen, die den Zugriff auf die Datensätze ermöglicht, jedoch keine Annahmen über deren Aufbau oder Inhalt macht. Diese Linie verfolgt auch der Operatoraufbau, der die Funktionsweise und die Verarbeitung regelt, die Datenmanipulation aber gesonderten Konstrukten, den Support-Funktionen, überlässt. So kann ein Operator auf beliebige Datentypen angepasst werden, während die interne Verarbeitung des Operators in der Anfrageauswertung davon unabhängig bleibt. Parallelität wird in Volcano durch einen eigens dafür entworfenen Operator erreicht, der sich nahtlos in einen Operatorbaum integrieren lässt und der alle nötigen Anpassungen an die Parallelität vor allen datenverarbeitenden Operatoren kapselt. Neue Operatoren können also frei von Überlegungen zur Parallelität für eine sequenzielle Ausführung entworfen werden. Parallelität erschafft Volcano unabhängig davon. Schließlich lassen sich das zugrundeliegende Dateisystem und die Parallelität in Volcano auf die Hardwareumgebungen flexible anpassen, so dass Volcano nicht auf ein Hardwaredesign festgelegt und damit unabhängig ist. Die Kapselung der Verarbeitungsmechanik und der parallelen Anfrageauswertung sind also das beherrschende Designprinzip in Volcano. Die Folgenden Abschnitte vertiefen die genauen Arbeitsweisen und Techniken. 3 Grundlegendes Systemdesign 3.1 Dateisystem und Support-Funktionen Einzelne Datensätze sind über RID (record-identifier) direkt aufrufbar. Datensätze sind zu Speicherseiten gruppiert. Eine oder mehrere Speicherseiten können flexibel zu einem Cluster zusammengefasst werden. Die Clustergrößen werden in der Speicherdatei festgelegt, können aber von Datei zu Datei variieren. Diese Clustergrößen können damit an die Hardwarebegebenheiten, also z.b. die Größe des Lese/Schreib-Puffers und im Falle verteilter Datenbanken auch an die Paketgrößen des vorhandenen Netzwerkprotokolls angepasst werden. Der Speichermanager stellt nur die wichtigsten Funktionen zur Verfügung wie das Sperren von Datensätzen, das Überschreiben von Speicherseiten sowie Lese- und Schreibvorgänge. Eigene Regeln sind nicht im Speichermanager implementiert. Die Steuerung dieser Funktionen wird vollständig höheren Datenbankebenen anvertraut. Dateien werden immer in fortlaufend zusammenhängendem Festspeicher abgelegt um iterativen Zugriff auf die Datensätze zu erleichtern. Sie bieten auf der Ebene der Datei die 4 [3] (Graefe 1994, I) 3

16 Möglichkeit eines iterativen Durchlaufs (scan), also die Basisoperatoren open und close zur Verwaltung des Zugangs zur Datei, next und rewind zur Iteration über die Datensätze, sowie append zur Erstellung neuer Datensätze. Next liefert dabei die RID des nächsten Datensatzes. Scans können darüber hinaus bereits auf der Dateiebene mit optionalen Prädikaten versehen werden und ermöglichen eine Filterfunktion (selective scan). Da die Verarbeitungsmechanik unabhängig von Datentypen sein soll, ist zunächst nicht klar, auf welche Daten sich ein solches Prädikat überhaupt beziehen soll. Dazu wird die Prädikatfunktion über einen Zeiger dem Operator übergeben. Diese Prädikatfunktion, die für die Prüfung des Prädikats zuständig ist, wird als Support-Funktion bezeichnet und übernimmt hier die eigentliche Verarbeitung. Der Filteroperator bleibt von der Ausgestaltung dieser Support-Funktion unberührt. Neben dem iterativen Zugriff gestattet Volcano auch das Anlegen von Indices in Form von B+-Bäumen. Einträge bestehen aus einem Schlüsselattribut und einem Datenattribut. Beide sind nicht an Datentypen gebunden. Volcano gestattet die Suche über die Schlüsselattribute und unterstützt dabei auch Bereichsabfragen. Support-Funktionen werden hier wie im Falle der selective scans genutzt. Um Zwischenergebnisse zu speichern, verwendet Volcano virtuelle Laufwerke, die im Pufferspeicher angelegt werden. Dabei ist die interne Verarbeitung dieses temporären Speichers identisch mit der des Plattenspeichers. Wird ein Datensatz allerdings hier freigegeben, geht er verloren. Durch das variable Dateisystem kann die Verarbeitungsmechanik also an Lese/Schreib- Puffergrößen sowie an die Größe der transferierbaren Netzwerkpakete optimal angepasst werden. Die Dateien erlauben iterativen Zugriff und das Anlegen von Indices. Die implementierte Filterfunktion ist durch den Gebrauch von Support-Funktionen unabhängig von den Datentypen. Die Verarbeitungsmechanik ist unabhängig von den Datenspezifikationen geblieben Operatoraufbau und der Operatorbaum Anfragen werden in Volcano als algebraische Ausdrücke dargestellt. Dabei sind die Operatoren dieser Algebra alle direkt ausführbare Algorithmen. Greafe spricht daher von einer ausführbaren Algebra und unterscheidet diese von der logischen Algebra relationaler Art. 6 Ausgehend von der untersten Verwaltungsebene im Dateisystem werden diese ausführbaren Operatoren darauf definiert. Alle Operatoren fungieren als Iteratoren über Clustern von Datensätzen und besitzen daher ebenfalls die Basisoperatoren open, next und close. Hinter dem Operator open verbergen sich dabei alle Anweisungen, die die Funktionsweise des Operators unterstützen. Das sind z.b. das Anlegen von Speicherstrukturen (z.b. Hash-Tabellen) oder 5 Beschreibungen des Dateisystems gehen auf [3] (Greafe 1994) zurück. 6 [3] (Greafe 1994, III.B, Seite 124) 4

17 Zwischenspeicherdateien im virtuellen Laufwerk, aber auch der Aufruf weiterer Operatoren, die den Input, also die zu verarbeitenden Datensätze liefern. Jeder open-aufruf endet mit dem Aufruf von next, der an die Inputoperatoren den Befehl zur Übergabe des nächsten Datensatzes richtet. Der anfordernde Operator tritt dabei also als Konsument von Datensätzen auf, der übergebende als Produzent eines Outputs. Close wird nur ausgeführt, wenn vom konsumierenden Operator die ausdrückliche Aufforderung zum Schließen des Operator ergeht bzw. von dem Wurzeloperator eines Operatorbaums, der allein den Abschluss feststellen kann. einer Anfrageauswertung Diese Basisoperatoren dienen also genau wie im Dateisystem ausschließlich der Verwaltung des Datenflusses im Operator. Die eigentliche Datenverarbeitung wird wieder durch das Konstrukt der bereits erwähnten Support-Funktionen injiziert. Dies gewährt jedem Operator Datentypunabhängigkeit, da es die Verwaltung, also den Mechanismus von der Typendefinition trennt. Ohne diese Support-Funktionen ist also keine Datenmanipulation oder Interpretation möglich. Die passenden Support-Funktionen werden dem Operator samt ihrer Ausführungsparamater als typlose Zeiger auf die Einstiegsstelle der Funktionsdefinition zur OPERATOR MODUL Kap-3.2-Abb.1 - Operatorenaufbau open;next;close; Support-Funktionen; Argumente; open;next;close; Status-record; Bindings; Verfügung gestellt. Gespeichert sind diese Zeiger im Status- Datensatz (state-record), der zusätzlich in jedem Operator vorhanden ist. In diesem staterecord sind alle Elemente hinterlegt, die für die Ausführung wichtig sind. Neben den übergebenen Zeigern auf die Support- Funktionen und den Zeigern auf die open, next und close Basisoperatoren der Inputoperatoren oder -dateien sind dies auch der verbleibend zu erstellende Operatorbaum und die grundlegenden Hardwarebegebenheiten, die für die konkrete Anfragebearbeitung konstant bleiben und in den sogenannten bindings gespeichert werden. Die Übergabe dieser Informationen erfolgt ebenfalls über typlose Zeiger. Das heißt aber auch, dass die bindings nicht fest in den Operatoren definiert sind. Hier wird die Trennung von Hardwarebegebenheiten und der Verarbeitungsmechanik als Designziel verfolgt. State-records sind nur lokal definiert, d.h. werden für jeden Operator speziell erstellt. Der grundlegende Operatoralgorithmus ist damit vielfach in einem Operatorbaum aufrufbar, da er erst durch den passenden lokalen state-record und die Support- Funktionen sinnvoll definiert wird. Das Verfahren ähnelt dem Instanziieren eines Objektes in der objektorientierten Programmierung. So können z.b. join, semi-join, outer-join, anti-join, 5

18 itersection, union, difference, anti-difference, aggregate und duplicate-elemination alle mit einem einzigen Operatormodul umgesetzt werden, denn sie alle beruhen auf dem Vergleich zweier Datenattribute aus zwei Listen (Dateien) von vergleichbaren Datensätzen (one-to-onematch). Sie unterscheiden sich lediglich in der Entscheidung, wie mit einer gefundenen Übereinstimmung oder einem Unterschied umzugehen ist. 7 Diese Entscheidung obliegt aber einer Support-Funktion und wird dem Operator als Ausführungsargument mit übergeben. PRINT Aufrufweg Datensatztransfer JOIN SCAN SCAN Kap-3.2.Abb-2 Operatorbaum mit Streaming Im folgenden Beispiel ist der Ablauf einer Anfrageverarbeitung unter den bisher betrachteten Rahmenbedingungen nachvollzogen. (Abbildung Abb-2) Start der Anfrageverarbeitung ist der Aufruf des print- Operators. In Volcano ist dies ein einfacher Filter-Operator. Dieser bekommt bindings übergeben sowie den Zeiger auf den Verwendungszweck des Operator, also ein Zeiger auf die Support-Funktion print. Ebenso wird der noch zu erstellende restliche Anfrageplan übergeben. All diese Informationen werden im status-record abgelegt. Der Aufruf erfolgt über den Aufruf des (print)open-basisoperators, der wiederum z.b. das Erstellen einer Liste im Pufferspeicher veranlasst. Ebenfalls veranlasst (print)open die Erstellung des Inputoperators, also eines Produzenten. In diesem Falle sollen der Output eines join gedruckt werden. Daher ruft (print)open direkt einen (join)open-basisoperator auf und übergibt wieder die bindings sowie die Informationen über den noch aufzubauenden Operatorbaum. Danach ist der print-operator vollständig aufgebaut. Da nun im join-operator der Basisoperator open aufgerufen worden ist, beginnt dieser ebenfalls seine Verarbeitungsstrukturen im Speicher zu erstellen. In Volcano wird ein join über einen One-to-one-match-Operatormodul erzeugt und dieser Operator mit einem konkreten lokalen status-record aufgerufen. Soll z.b. als Join- Verfahren ein Hash-Join verwendet werden, so wird die entsprechende Support-Funktion bzw. ein Zeiger auf die Einstiegsstelle mit übergeben, die einen solchen Join verwirklicht. Da der join-operator zwei Inputoperatoren benötigt, wird dieser Operator nun also entsprechend den Anweisungen im verbleibenden Operatorbaum zwei Produzenten über den Aufruf der open- Basisoperatoren aufrufen. In diesem Fall sind dies selective-scan-operatoren. Diese können, da nach ihnen keine weiteren Operatoren mehr aufgerufen werden, es sich also um eine 7 [3] (Graefe 1994, III.B2) ) 6

19 gespeicherte Datei handelt, direkt über die Möglichkeit eines selective-scans auf Dateiebene verwirklicht werden, wie in Kapitel 3.1 vorgestellt. Tatsächlich ist auch ein eigener Operator für den selective-scan verfügbar, wenn z.b. über Zwischenergebnisse selektiert werden soll, die nicht in einer Datei gespeichert sind. Da aber beide Strukturen dieselben Support-Funktionen aufrufen können sind sie quasi identisch. Hier wird nochmals die eindeutige Trennung von Verarbeitungsmechanik und Datenmanipulation deutlich. Der Aufruf des selective-scan auf der Dateiebene verläuft dabei exakt nach dem selben Muster wie bei Operatoren, da auch die Dateien über die Basisoperatoren open, next, und close verfügen. Daher kann der join-operator schlicht den open-basisoperator aufrufen und die Datei wird entsprechend reagieren, ebenso wie ein beliebiger anderer Operator. In diesem Fall damit, dass die Datei beginnt, ein erstes Cluster, also eine gewisse Anzahl Speicherseiten, in den Speicher zu übertragen. Beim selective-scan wird nun noch die Support-Funktion für das Auswahlprädikat ausgewertet. Dabei lässt Volcano als Argument sowohl direkte Vergleiche in kompilierter Form (compiled) zu oder auch komplexe Funktionen, deren Prädikate erst ausgewertet werden müssen (interpreted). 8 Man sieht deutlich den rekursiven Verlauf, in dem der Operatorbaum von Operator zu Operator aufgebaut wird. Wichtig ist dabei, zu beachten, dass es keinen kontrollierenden Prozess gibt, der den Aufruf steuert, sondern das dies ausschließlich durch die open-aufrufe der konsumierenden an die produzierenden Operatoren geschieht. Das bedeutet auch, das jeder Operator nur den gerade aktuellen Teil des Operatorbaums, der ihn selbst betrifft, interpretieren muss. Oder anders gesagt, kein Operator kennt wirklich den ganzen Operatorbaum, im Gegenteil, für die Operatoren ist es vollständig unerheblich, wofür ihr Output verwendet wird und auch kennen sie nur den Zeiger auf den oder die aufgerufenen eigenen Inputoperatoren. Dabei ist für sie der Aufbau und die Verfahrensweise ihrer Inputoperatoren ebenfalls völlig unerheblich. Alle open-aufrufe enden mit dem Aufruf der next-basisoperatoren auf den Input- Operatoren. Da aber der Baum rekursiv erstellt wurde ist der erste next-aufruf hier der auf einer Datei, genauer der eines join-operators auf einer Datei. Diese liefert nach Auswertung der Bedingung als Antwort auf diesen next-aufruf den Zeiger auf den RID des ersten Ergebnisdatensatzes an den join-operator. Ebenso bei der zweiten Datei. Dem join-operator liegt als Abschluss des open-aufrufs des print-operator ebenfalls ein next-aufruf vor. Sobald also der join-operator ein Ergebnis weitergeben kann, wird dieser Aufruf bedient. 9 Sobald ein Operator einen Datensatz verarbeitet hat, ruft er erneut auf seinem Inputoperator den next- 8 [3] (Graefe 1994, III.A Seite 123) 9 Dabei wird ein join-operator eine Datei im virtuellen Speicher anlegen und erst ein Cluster an Ergebnisdatensätzen erstellen und dieses Cluster übergeben. 7

20 Basisoperator auf und fordert so den nächsten Datensatz an. Dies geschieht so lange, bis kein Datensatz mehr vorhanden ist, der weitergegeben werden könnte und stattdessen ein End-of- Stream vom Produzenten übergeben wird. Der Datensatzaufruf folgt also on-demand dann, wenn weitere Daten im konsumierenden Operator verarbeitet werden können. Die Anfrageverarbeitung endet schließlich, wenn alle Operatoren bis hin zum Wurzeloperator gemeldet haben, dass keine weiteren Daten vorliegen. Dann ruft der Wurzeloperator, in diesem Falle der print-operator, den close-basisoperator auf dem join-operator auf. Auch dieser Aufruf wird rekursiv verarbeitet, so dass sich zuerst die Dateien per close-basisoperator schließen und die Speicher, bis hinauf zum Wurzeloperator, freigeben. Mit seiner Terminierung endet mittels close auch die Anfrageverarbeitung. Prinzipiell unterstützt das Iteratordesign in Volcano bis hinunter in das Dateisystem also eine Datenverarbeitung in Streams, die mit sehr geringem Verwaltungsaufwand möglich ist und eine schnelle Verarbeitung unterstützt. 4 Inter-Operator Parallelität 4.1 Der Exchange-Operator Streng genommen haben wir es bei der Streamverarbeitung bereits mit einer Form von Inter-Operator Parallelität zu tun, denn die Operatoren arbeiten gleichzeitig in dem Sinne, das noch kein vollständiges Ergebnis eines Operator vorliegt, wenn ein anderer bereits die Arbeit aufnimmt. Allerdings findet diese Parallelität in einem einzigen Prozess statt, so dass die Ausführung allein von den Möglichkeiten der Hardware zur Streamverarbeitung abhängt, also außerhalb des Einflussbereichs von Volcano selbst ist. Im Folgenden wird dann auch Parallelität als Prozessparallelität verstanden, die von der Verarbeitungsmechanik selbst erzeugt wird und durch mehrere Ausführungsprozesse gekennzeichnet ist. Bei der Einführung von Prozessparallelität soll nach Möglichkeit die Struktur der Verarbeitungsmechanik, also die Selbstorganisation der Operatoren durch den rekursiven Aufruf nicht angetastet und auch auf die Prozessorganisation übertragen werden. Eine übergeordnete Struktur zu Verwaltung und Überwachung der Prozesse ist daher ungeeignet. Naheliegend ist dann der in Volcano gewählte Ansatz, die Prozessverwaltung vollständig in einen neuen Operator zu verlagern. Auf diese Weise fügt sich der Aufruf neuer Prozesse nahtlos in den Operatorbaum ein und alle anderen Operatoren bleiben unabhängig von Einflüssen, die durch die parallelen Prozesse entstehen. Sie können weiterhin ohne Rücksicht auf Parallelität entwickelt und dennoch parallel ausgeführt werden. Genau das leistet der Exchange-Operator in Volcano. Der Exchange-Operator beinhaltet keinerlei Anweisung zu Datenmanipulation oder Interpretation. Seine Aufgabe ist es, neue Prozesse zur Verfügung zu stellen und zu schließen 8

21 sowie den Datentransfer zwischen den Prozessen zu gewährleisten. Dabei können dem Exchange-Operator Argumente, wie z.b. der Grad der Parallelität, d.h. wie viele parallele Prozesse eröffnet werden sollen, übergeben werden. Er ist auch als Iterator definiert, unterstützt also ebenso die Basisoperatoren open, next und close und ist damit an einer beliebigen Stelle im Operatorbaum einsetzbar. 4.2 Pipelining Abbildung Abb-3 zeigt das Beispiel aus Kapitel 3 nachdem ein Exchange-Operator eingefügt wurde. SCAN PRINT Port EX-CH JOIN Aufrufweg Datensatztransfer Kap-4.2.Abb-3 Operatorbaum mit zwei vertikal parallelen Prozessen (Pipelining) Der Exchange-Operator wird vom print-operator als Produzent über den (exchange)open- Basisoperator aufgerufen. Darauf hin stellt er einen neuen Prozess zur Verfügung und richtet zum Datenaustausch eine Datenstruktur im Speicher ein, den Port. Als Produzent ruft nun der Exchange-Operator im neuen Prozess seinerseits den join-operator wieder über (join)open auf und führt den rekursiven Aufruf so fort. Im neuen Prozess werden also nun alle im Operatorbaum tieferliegenden Operatoren aufgerufen. Um die Interaktion zwischen den Prozessen zu verringern werden Datensätze, die als Output vom join-operator übergeben werden, im Port in Paketen gespeichert und übergeben. Die Paketgröße ist dabei aber flexibel wählbar ( Datensätze) und wird ebenfalls als Argument an den Exchange-Operator übergeben. Der Exchange-Operator ist damit Bestandteil beider nun arbeitenden Prozesse. Zu beachten ist, dass dies eine Verfahrensänderung der normalen Weitergabe von Daten ist, die innerhalb eines Prozesses normalerweise über die Nachfrage (demand-driven) geregelt ist und hier über die Verfügbarkeit der Daten (data-driven). 10 Sollte der produzierende Prozess 10 Man beachte hier, dass die Weitergabe eines Pakets mit nur einem Datensatz dem aufrecht Erhalten des direkten Streamings entspricht. 9 SCAN

22 wesentlich schneller Datensätze zur Verfügung stellen als der konsumierende Prozess diese anfragt, muss der Exchange-Operator immer mehr Pakete im Port hinterlegen. Das kann unter Umständen den Speicher massiv belegen und die Systemleistung senken. Die Anzahl der im Port hinterlegbaren Cluster ist daher ein weiteres Argument, das dem Exchange-Operator bei seiner Erstellung übergeben wird. Da dieses Argument nur den lokalen Status eines Operators definiert, sind innerhalb eines Operatorbaums beliebige Parametersetzungen für die verschiedenen Exchange-Operatoren möglich. Die Verarbeitungsmechanik kann also erneut variabel von höheren Softwareebenen angepasst werden. Die Kapselung bleibt erhalten. 11 Diese einfache vertikale Parallelität wird auch Pipelining genannt und bezieht sich dabei auf den Datentransfer zwischen Prozessen, der über die Übergabe von Clustern im Port durchgeführt wird. Begrifflich zu trennen ist davon das Streaming, das ja innerhalb eines Prozesses stattfindet. 4.3 Teilbaum-Parallelität im Operatorbaum Bei genauer Betrachtung fällt auf, das mit dieser Methode aber nicht nur vertikale Parallelität sondern auch bereits horizontale Parallelität im Operatorbaum, die sog. Teilbaum- Parallelität (bushy-parallelität), ohne weitere Anpassungen möglich ist. Abbildung Abb-4 zeigt das Beispiel erweitert um zwei weitere Exchange-Operatoren, die jetzt parallel die selectivescans in einzelne Prozesse verlagern. PRINT Aufrufweg Datensatztransfer Port EX-CH JOIN Port EX-CH Port EX-CH SCAN SCAN Kap-4.3. Abb-4 Operatorbaum mit vertikal und horizontal parallelen Prozessen Da sich die Operatoren eines Operatorbaums selbst verwaltend rekursiv aufrufen und der Exchange-Operator diese Struktur vollständig mitträgt, ist horizontale Parallelität in Volcano sehr leicht zu erreichen. 11 [2] (Greafe und Davidson 1993, VI, Seite775 ff.) 10

23 4.4 Verwaltungsaufwand Der Exchange-Operator ist allein für alle Belange der Parallelität zuständig. Er regelt den Datenaustausch zwischen den Prozessen, ist dabei aber durch seine Iteratorstruktur zu allen anderen Operatoren kompatibel. Übergeordnete steuernde Prozesse sind nicht nötig. Auch müssen die anderen Operatoren in keiner Weise für die parallele Ausführung vorbereitet werden. Die parallele Ausführung ist hier sehr effizient gewährleistet. Über die Wahl der Paketgröße kann eine Verzögerung durch den Wechsel von nachfrageorientiertem zu datengetriebenem Datenfluss gering gehalten werden. 5 Intra-Operator Parallelität 5.1 Datenpartitionierung Intra-Operator Parallelität bedeutet zunächst, dass ein einziger Operator im Operatorbaum durch mehrere Prozesse verarbeitet wird. Wie in Kapitel 4 beschrieben, können Prozesse in Volcano aber nur durch den Exchange-Operator bereit gestellt werden. Wie im bisher betrachteten Beispiel können auch hier mehrere Operatoren innerhalb eines Prozesses verarbeitet werden. Die Parallelität muss sich in diesem Falle also auf einen ganzen Teilbaum des Operatorbaums beziehen, der für die Bearbeitung in einem Prozess vorgesehen war. Dabei ist auch ein einzelner Operator parallel genau dann ausführbar, wenn sich der Operator in einem PRINT P(0) P1 P2 J(0) JOIN P1 S2(0) SCAN JOIN J(1) P2 S2(1) SCAN P1 P2 P3 Aufrufweg Datensatztransfer S1(0) S1(1) S1(2) SCAN SCAN SCAN Kap-5.1. Abb-5 Operatorbaum mit vertikal und horizontal parallelen Prozessen Blatt des Operatorbaums befindet oder von zwei Exchange-Operatoren eingeschlossen wird. 11

24 Streng genommen müsste hier also von einer Intra-Teilbaum-Parallelität gesprochen werden. 12 Der bisher beschriebene Exchange-Operator ist mit geringen Erweiterungen bereits in der Lage, Intra-Teilbaum-Parallelität zu ermöglichen. Abbildung Abb-5 zeigt das bisherige Beispiel, wobei die join-operatoren auf partitionierten Dateien nun in parallelen Prozessen bearbeitet werden sollen. Der Exchange-Operator bekommt als Argument den Grad der Parallelität mit z.b. 2 übergeben und wird den join-operator in zwei getrennten Prozessen verarbeiten. Zu beachten ist, dass der Exchange-Operator nicht einfach zwei Prozesse eröffnen kann, in denen der Operatorbaum jeweils wie gewohnt weiter geöffnet wird, denn in diesem Falle würde der Operatorbaum verändert. So würden die beiden Prozesse jeweils zwei Exchange-Operatoren öffnen und darin die selective-scans ausführen. Um das zu vermeiden, eröffnet der Exchange- Operator zunächst nur einen einzigen neuen Prozess, z.b. J(0). Dieser wiederum eröffnet die weiteren, zu sich selbst identischen, Prozesse als Unterprozesse zu sich selbst, hier z.b. J(1). Damit fungiert J(0) als Master-Prozess in dieser Gruppe von intra-teilbaum-parallelen Prozessen und ist allein für den Aufruf der Produzentenprozesse zuständig. So bleibt der Operatorbaum unverändert. Dennoch werden alle intra-teilbaum-parallelen Unterprozesse mit dem übergeordneten Exchange-Operator verbunden, denn sie alle liefern gleichermaßen den Input für den Exchange-Operator, der seinerseits keinerlei Datenmanipulation vornimmt und seinen Port in die Partitionen P1 und P2 teilt, um die Daten aufzunehmen. Das bedeutet auch, das beide Prozesse ein End-of-Stream Signal setzten müssen, bis der Exchange-Operator seinerseits dieses Signal setzten darf. Die Anzahl der abzuwartenden Signale bestimmt dabei der Grad der Parallelität. Noch etwas komplizierter wird die Situation, falls, wie in diesem Beispiel, auch die selective-scans auf partitionierten Daten aufgerufen und in mehreren Prozessen verarbeitet werden. Nimmt man an, der nächste Exchange-Operator wird von dem Master-Join-Prozess, d.h. dem Master-Prozess in der Gruppe der parallelen Join-Prozesse, der einen join-operator ausführt, mit einem Grad der Parallelität von 3 aufgerufen. Dann eröffnet dieser Exchange- Operator wiederum einen Prozess und darin den selective-scan, wobei er als Datei eine Partition angibt. Dieser Selective-Scan-Prozess S1(0) übernimmt wiederum die Rolle des Master- Prozesses und öffnet wieder intra-teilbaum-parallele Unterprozesse S1(1) und S1(2), die ihrerseits einen selective-scan über einer jeweils anderen Dateipartition ausführen. 13 Würden nun alle Prozesse mit dem selben Port im Exchange-Operator verbunden, um ihren Output weiterzureichen, würde ein beträchtlicher Teil des Vorteils der parallelen Ausführung vergeudet, 12 [1] (Graefe 1990, 4.3 Seite 106) zeigt einen BC -Prozess, also einen Prozess aus den Operatoren B und C. 13 Der Index 1 bei den Prozessen S1(0)-S1(2) unterscheidet diese Scans von den anderen die ja über anderen Daten ausgeführt werden nicht nur über verschiedenen Partitionen. 12

25 weil so sehr viele Zugriffe auf den selben Speicherbereich erfolgen müssten. Der Exchange- Operator ist daher in der Lage, für jeden Prozess eine Partition im Port anzulegen. Da in diesem Falle auch mehrere parallele Prozesse die Daten verarbeiten können, wird dem next- Basisoperator, der von den übergeordneten Prozessen aufgerufen wird, ein Argument mit einer Partitionsangabe mitgegeben. So können die übergeordneten Prozesse direkt mit einer Partition des Port im Exchange-Operator verbunden werden. Anzumerken ist, das hier insgesamt 10 End- Of-Stream Signale gesetzt werden, denn jeder Prozess muss nun jeder Portpartition und damit jedem übergeordneten Prozess mitteilen, dass keine Datensätze mehr vorliegen. Andernfalls könnten Datensätze verloren gehen Der erweiterte Exchange-Operator 6.1 Datenpartitionierung Alle bisherigen Darstellung bezogen sich auf eine shared-memory Hardwarekonfiguration. Daher war zu jedem Zeitpunkt die Übergabe von Speicheradressen ausreichend, um Informationen von einem Operator zum nächsten und von einem Prozess zum nächsten zu übergeben. Um größtmögliche Flexibilität bezüglich der Hardwarebegebenheiten zu erreichen, soll Volcano aber auch in verteilt bzw. hierarchisch organisierten Speicherkonfigurationen einzusetzen sein. Dies macht eine Erweiterung des Exchange-Operator notwendig. Im Folgenden sei nun ein hierarchisches System beschrieben, bei dem in jedem Knoten ein shared-memory System vorliegt und diese Knoten über ein Netzwerk verbunden sind. Abbildung Abb-6 zeigt das bekannte Beispiel in einem solchen Umfeld, wobei einige Prozesse auf andere Knoten verteilt wurden. 15 Um den Datenaustausch zwischen den Knoten zu organisieren und dennoch die bisher erreichte Unabhängigkeit zu erhalten ist eine Erweiterung des Exchange-Operators nötig. Bisher konnten Daten von einem zum anderen Operator durch die Übergabe von Speicheradressen verwirklicht werden. Zwischen Knoten funktioniert dies nicht. Daten müssen vollständig übertragen werden. Für Datenpakete erzeugt der erweiterte Exchange-Operator auf dem Knoten des produzierenden und des konsumierenden Prozesses jeweils einen Port zwischen denen der Datentransfer innerhalb des Exchange-Operators stattfindet. 14 Der Übersicht halber sind die Portpartitionen in der Abbildung festen Operatoren und Prozessen zugeordnet. Da aber die Wahl einer Portpartition ein Argument im next-aufruf ist, ist nicht ausgeschlossen, das verschiedene Konsumentenprozesse und -operatoren wahrend der Datenverarbeitung aus verschiedenen Partitionen Daten beziehen können. Vgl. [1] (Graefe 1990, 4.3, Seite 106) 15 Die erste Ziffer in den Prozesskürzeln beschreibt den Knoten, auf dem der Prozess verarbeitet wird, z.b. J(1,0) auf Knoten 1 als Master-Join-Prozess.. 13

26 PRINT P(0,0) P1 P1 J(1,0) JOIN P1 P1 S2(2,0) SCAN Knoten 0 Aufrufw eg Datensatztransfer Netzw erkverbindung Bindings Transfer J(1,1) JOIN P2 P2 S2(2,1) SCAN Knoten 1 P1 P2 P3 Knoten 2 P1 P2 P3 S1(3,0) S1(3,1) S1(3,2) SCAN SCAN SCAN Knoten 3 Kap-6.1. Abb-6 Operatorbaum mit vertikal und horizontal parallelen Prozessen auf verteilten Knoten Neben den Daten gilt dies insbesondere auch für die Operatoren selbst, die bindings, die Support-Funktionen und den verbleibenden Operatorbaum. Letztlich wird auf einem neuen Knoten so eine autarke Anfrageauswertung gestartet, die über den erweiterten Exchange- Operator mit dem übergeordneten Operatorbaum verbunden wird. D.h. in jedem Knoten wird durch den Exchange-Operator ein Prozess erstellt und in diesem alle notwendigen Daten wie z.b. Operatoren, bindings und benötigte Support-Funktionen im tiefer liegenden Operatorbaum übertragen. Dazu werden die Operatoren um drei Basisoperatoren erweitert, pack, unpack und size. Dieser Prozess im entfernten Knoten dient dann als lokaler Master-Prozess für diesen Operator auf dem entsprechenden Knoten. Der Vereinfachung wegen sei hier von einem Operator die Rede. Wie in Kapitel 5 dargelegt handelt es sich hierbei strenggenommen um Teilbäume des Operatorbaums, die auch aus mehr als einem Operator bestehen können, die in einem solchen Master-Prozess ausgeführt werden. Über ihn werden Kontrolldaten über das Netzwerk ausgetauscht. Zu beachten ist, dass diese Netzwerkverwaltung von der tatsächlichen Datenübergabe von einem produzierenden zu einem beliebigen konsumierenden Prozess, wie sie der Operatorbaum vorgibt, unabhängig ist. 14

27 P2 J(2,0) JOIN PRINT Knoten 0 P(0,0) P2 P1 P1 J(1,0) JOIN P1 P2 P1 P2 Knoten 2 S2(2,0) SCAN S2(2,1) SCAN Knoten 1 P1 P2 P3 P1 P2 P3 Aufrufweg Datensatztransfer Netzwerkverbindung Bindings Transfer S1(3,0) SCAN S1(3,1) SCAN S1(3,2) SCAN Knoten 3 Kap-6.1. Abb-7 Operatorbaum mit vertikal und horizontal parallelen Prozessen auf verteilten Knoten Komplexer wird die Situation, falls ein Operator parallel auf verschiedenen Knoten ausgeführt wird. Dann gilt, dass jede Prozessgruppe neben einem globalen Master-Prozess auf jedem Knoten einen lokalen Master-Prozess besitzt, die untereinander Kommunikationsnachrichten austauschen müssen. Allerdings gilt wieder, das jeder produzierende Prozess jedem ihm im Operatorbaum direkt nachgestellten konsumierenden Prozess Daten senden kann. Abbildung Abb-7 zeigt diese Situation. 6.2 Vektorbasierte Verarbeitung Zur Verringerung der Datentransfers, vor allem zwischen einzelnen Knoten, kann es vorteilhaft sein, Berechnungsergebnisse eines Teilbaums anderen Operatoren zur Verfügung zu stellen, indem Ergebnis- oder Kontrollvektoren übergeben werden, z.b. beim bit-vektor-filtern. 16 Durch den iterativen Aufruf des Operatorbaums ist dies zunächst unmöglich, da die Ergebnisse eines Teilbaums erst im verbindenden Operator mit denen eines anderen Teilbaums zusammengebracht werden können. Durch einige kleine Veränderungen im Exchange-Operator und dem Hinzufügen einer besonderen Support-Funktion ist auch diese Funktionalität 16 Ausführungen folgen [3] (Greafe und Davidson 1993, VII.C, Seite 759ff.) 15

28 herzustellen. Zunächst können Daten, wie z.b. ein Bit-Vektor nur über die Weitergabe in den bindings baumabwärts transportiert werden. Da eine direkte Verbindung zwischen Teilbäumen des Operatorbaums nicht herstellbar ist, muss ein solcher Vektor den Baum in Richtung Wurzel weitergegeben werden, um an der Stelle der Verzweigung dann über die bindings in den anderen Teilbaum übergeben werden zu können. Dabei fallen zwei Dinge sofort ins Auge. Erstens müssen die bindings, die ja bisher als unveränderlich galten, verändert werden. Dazu ist eine Support-Funktion nötig, die in Operator mit aufgerufen wird, der den bit-vektor erstellt. Da die bindings zwar innerhalb eines Knotens durch Zeiger übergeben werden, der Operator selbst aber keinen Information darüber hat, ob nicht noch andere Knoten, die ja mit Kopien arbeiten würden, im Operatorbaum beteiligt sind, müssen die bindings rekursiv baumaufwärts geändert werden. Die einzige Möglichkeit, dies zu erreichen ist, die Übergabe als Parameter als Reaktion auf den close-aufruf zu übergeben. Dadurch ist zweitens klar, dass der entsprechende Teilbaum vollständig bearbeitet werden muss, bevor die anderen Teilbäume überhaupt rekursiv aufgerufen werden können. Der Exchange-Operator, der die Teilbäume also in verschiedene Prozesse leitet, muss also einen veränderten open-basisoperator haben, der erst den zweiten Teilbaum weiter erstellt, wenn die Antwort des close-aufrufs aus dem anderen Teilbaum mit den veränderten bindings zurückerhalten wird. Graefe nennt dies einen synchronisierten-open-operator. 17 Es ist klar, dass dies die Verarbeitung in Teilbaum-Parallelität unmöglich macht. 6.2 Verwaltungsaufwand Da die grundsätzliche Struktur des rekursiven Operatoraufrufs erhalten geblieben ist, entsteht weiterhin kein zusätzlicher Aufwand durch einen übergeordneten Kontrollprozess, wenn verteilte Verarbeitungsknoten verwendet werden. Auch ist der Verwaltungsaufwand nicht abhängig von der Menge der Datensätze, die zwischen Operatoren ausgetauscht werden sollen, sondern nur von der Menge der beteiligten Verarbeitungsknoten und vom verwendeten Netzwerkaufbau und -protokoll. Die grundsätzliche Verarbeitungsmechanik kommt damit weiterhin mit geringem Verwaltungsaufwand aus. 7 Leistungsmerkmale und -fähigkeiten 7.1 Erweiterbarkeit, Parallelität, Unabhängigkeit, Skalierbarkeit Volcano ist in hohem Maße erweiterbar. Neue Operatoren können im Umfeld sequentieller Anfrageauswertung erstellt werden und problemlos in das Volcano aufgenommen werden, solange das Iteratorprotokoll aus open, next und close eingehalten wird. Durch die 17 [3] (Greafe und Davidson 1993, VII.C, Seite 760ff.) 16

29 Kapselung der Datenmanipulation von der Verarbeitungsmechanik mittels der Support- Funktionen können problemlos neue Datentypen eingearbeitet werden, da dies nur einer neuen Support-Funktion bedarf. Der Exchange-Operator ist in der Lage eine Vielzahl von Parallelitäten in der Anfrageauswertung flexibel zu erzeugen und zu verwalten. Dateisystem und Operatorbaum können ebenso flexibel auf verschiedene Hardwarekonfigurationen angepasst werden. Dabei ist auch ein hohes Maß an Skalierbarkeit erreichbar. Ebenso sind die Operatoren leicht auf besondere Bedingungen anzupassen, wie das Beispiel der bit-vektor-übertragung in Kapitel 6.2 gezeigt hat. 7.2 Verwaltungsaufwand Generell ist der Verwaltungsaufwand sehr gering, da Volcano ohne einen koordinierenden Prozess und entsprechende Kommunikation auskommt. Das gilt besonders für einfache Anfragen, die ohne Parallelisierung auskommen. Der Exchange-Operator hingegen bildet als nicht datenverarbeitender Operator zunächst einen reinen Mehraufwand. Verglichen mit anderen Systemen, die aber strikt jedem Operator einen eigenen Prozess zuordnen und diese Prozesse dann koordinieren müssen, ist Volcano ebenfalls sehr effizient, da nicht jeder parallele Operator in einem eigenen Prozess gestartet werden muss, sondern auch ganze Teilbäume des Operatorbaum parallelisiert werden können. Auch der zusätzliche Aufwand für die Netzwerkkommunikation bleibt überschaubar, da er nur von der Anzahl der involvierten Knotenübergänge abhängt, also von der Anzahl der lokalen Master-Prozesse. Die große Flexibilität in Volcano kann dabei allerdings auch zur Bremse werden, denn es sind durchaus Operatorbäume denkbar, die ausgehend von der aufgezeigten Systematik, extrem viele Exchange-Operator benötigen und so einen hohen Verwaltungsaufwand provozieren. Ein gut informierter Anfrageoptimierer mit genauen Kosteninformationen über die Prozesserstellung und die Netzwerkkommunikation ist daher essentiell, um eine effiziente Operatorbäume zu generieren. 17

30 Literaturliste [1] G.Graefe, Encapsulation of Parallelism in the Volcano Query Processing System in Proceedings of the 1990 ACM SIGMOD international conference on Management of data, Seite [2] G.Graefe, D.L. Davidson Encapsulation of Parallelism and Architecture-Independence in Extensible Database Query Execution in Journal IEEE Transactions on Software Engineering Volume 19 Issue 8, August 1993, Seite [3] G.Graefe, Volcano - An Extensible and Parallel Query Evaluation System in IEEE Transactions on Knowledge an Data Engeneering, Vol 6. No.1, 1994: Seiten

31 FernUniversität in Hagen Seminar im Sommersemester 2011 MapReduce und Datenbanken Thema 3 MapReduce und Hadoop Referentin: Noria Bellouch

32 Inhaltsverzeichnis 1 Einführung MapReduce Map-Phase Reduce-Phase Ablaufübersicht Fehlertoleranz Ausfall einer Worker-Instanz Ausfall des Masters Google File System Architektur Funktionsweise Lesezugriffe Schreibzugriffe Metadaten und Masteroperationen Fehlertoleranz Konsistenzmodell Überblick Unterschied Hadoop Google MapReduce...16 Literaturverzeichnis...17 Abbildungsverzeichnis...18

33 1 Einführung Immer mehr Anwendungen verarbeiten immer größer werdende Datenmengen. Dieses Phänomen kann das Unternehmen Google besonders gut beobachten. Um die Verarbeitung großer Datenmengen effizienter zu gestalten, hat Google unterschiedliche Verfahren entwickelt. Eines dieser Verfahren ist MapReduce. Das Verfahren sieht vor, dass Daten parallel auf tausenden von Rechnern verarbeitet werden können. Hierbei stellen sich Herausforderungen bezüglich Parallelisierung, Load Balancing und Fehlertoleranz. Das MapReduce Framework bietet hierzu Lösungsansätze, so dass diese Probleme dem Entwickler weitestgehend verborgen bleiben. Im Rahmen dieser Arbeit soll MapReduce mit dem Fokus auf dem Thema Fehlertoleranz vorgestellt werden. MapReduce MapReduce ist ein von Google entwickeltes und patentiertes Verfahren zur Verarbeitung von sehr großen Datenbeständen in verteilten Umgebungen. Das Verfahren wurde in Anlehnung an die Funktionen map() und reduce() aus der Welt funktionaler Programmiersprachen (z.b Lisp) konzipiert [GOO11]. Dabei werden die Daten über zwei separate Phasen hinweg bearbeitet: Der Map-Phase und der Reduce-Phase. In der Map-Phase werden die Ausgangsdaten auf mehreren Rechnerinstanzen parallel eingelesen und verarbeitet. Die Zwischenergebnisse aus der Map-Phase fließen als Inputdaten in die Reduce Phase ein. Das Framework liefert die Infrastruktur und übernimmt die Kontrolle über die Prozesse. Google File System Analog zum MapReduce Konzept von Google wurde das Google File System (GFS) entwickelt, um den wachsenden Anforderung der Google Anwendungen bezüglich Datenverarbeitung Rechnung zu tragen. Google setzt beim Aufbau der eigenen Cluster auf Standard Hardware. Aus Erfahrung wurde bei der Entwicklung des GFS der Ausfall einzelner Clusterknoten als Regelfall und nicht als Ausnahme angenommen. Fehlertoleranz gegenüber Ausfällen wurde damit eines der wichtigsten Designziele für GFS. Ein weiteres Designziel war die Skalierbarkeit des Systems. Knoten sollten schnell und unkompliziert dem Cluster hinzugefügt werden können [FIS10]. 1

34 Hadoop Bei Hadoop handelt es sich um eine OpenSource Java-Implementierung des von Google entwickelten MapReduce-Paradigmas. Mittlerweile ist Hadoop ein Top-Level Apache Software Foundation Projekt. Hadoop besteht dabei aus zwei Kernkomponenten: ein verlässlicher Datenspeicher auf der Basis von Hadoop Distributed File System (HDFS) und dem MapReduce Konzept [CLO11] Auf Unterschiede zwischen Hadoop und Google MapReduce wird in Kapitel 4 näher eingegangen. Hadoop Distributed Filesystem Das Hadoop Distributed Filesystem (HDFS) ist ein verteiltes Dateisystem und Bestandteil des Apache Hadoop Core Projekt. HDFS ist stark fehlertolerant und wurde für den Einsatz auf Standard Hardware entwickelt. Fehleridentifizierung und schnelle Behebung dieser gehörte zu den wichtigsten Designzielen. Das HDFS wurde in Anlehnung an das Google File System (GFS) entwickelt. In den wichtigsten Eigenschaften stimmt es mit den Ausführungen im von Google veröffentlichen Paper "The Google Filesystem [GGL03]" überein [FIS10]. Aus diesem Grund gehen wir im Rahmen dieser Arbeit vor allem auf das Google File System ein. 2

35 2 MapReduce Map-Phase Bei der Map-Funktion handelt es sich um vom Anwender individuell implementierte Tasks zur Umwandlung von Inputdaten in intermediäre Daten. Das Framework gibt dabei lediglich die Signatur der Funktion vor: map (k1, v1) list(k2, v2) Die Map-Funktion nimmt als Inputdaten ein Schlüsselwertpaar entgegen und erzeugt hieraus eine Liste von Schlüsselwertpaaren (key/value). Aus einem Inputpaar können 0...n Outputpaare generiert werden. Der Typ der Inputdaten muss nicht dem Typ der Outputdaten entsprechen. [HAD11]. Die Outputdaten stellen Zwischenergebnisse dar, die wiederum als Inputdaten in die Reduce-Phase einfließen. Abbildung 1: Map-Phase [Eigene Darstellung] Reduce-Phase Der Anwender muss unter Berücksichtigung der Vorgaben des Frameworks eine Reduce-Funktion implementieren. reduce (k2, list(v2)) list(v2) Als Input-Daten (Liste der Key-Value Paare) muss die die Reduce-Funktion die Outputdaten der Map-Funktion verarbeiten. In der Reduce-Phase ruft das Framework die vom Anwender implementierte Reduce-Funktion für jedes Zwischenergebnis aus der Map Phase auf [DG04, Seite 2]. 3

36 Dabei wird der Reduce Funktion ein Key und ein Set an Werten zu diesem Key übergeben. Ziel der Funktion ist die Reduzierung (deshalb reduce ) der Anzahl dieser Werte zu erreichen. Typischerweise erzeugt die Reduce-Funktion keinen oder einen Wert [DG04, Seite 2]. 2.2 Ablaufübersicht Im Rahmen der Map-Phase werden die zu verarbeitenden Daten in M Blöcke mit einer Größe von MB unterteilt und zur parallelen Verarbeitung auf unterschiedlichen Instanzen des Rechner-Clusters den Map-Funktionen als Inputdaten übergeben. Auf den unterschiedlichen Map-Instanzen wird jeweils die Map-Funktion ausgeführt. Anschließend ruft das Framework die Reduce-Funktion zur weiteren Verarbeitung der Zwischenergebnisse aus der Map-Phase auf. Folgende Abbildung beschreibt diesen Ablauf ausführlicher: Abbildung 2: Ablaufübersicht MapReduce [DG04, Seite 4] 4

37 Eine Instanz des Clusters ist der Master. Alle anderen fungieren als Worker. Der Master koordiniert den Ablauf sowie die teilnehmenden Worker-Instanzen. 1. Das Framework startet mehrere MapReduce Instanzen auf dem Rechnercluster. 2. Map-Tasks werden freien verfügbaren Worker-Instanzen zugewiesen. Es gibt entsprechend der Splittung der Inputdaten M Map-Tasks. 3. Erhält ein Worker einen Map-Task, so liest er die erhaltenen Inputdaten ein und übergibt diese der vom Anwender implementierten Map-Funktion. 4. Die Ergebnisse der Map-Funktion werden im lokalen Hauptspeicher gehalten und regelmäßig lokal auf Platte geschrieben. Dabei werden die Daten so partitioniert, dass es R Partitionen gibt und in jeder Partition die Werte für einen Key vorliegen. Dementsprechend gibt es R Reduce-Tasks, die jeweils die Daten einer Partition als Input für die Reduce-Funktion erhalten. Der Master erhält regelmäßig Informationen über den Speicherort der Zwischenergebnisse der Map-Tasks. Anschliessend werden Reduce-Tasks an verfügbare Worker-Instanzen vergeben. Hierzu übermittelt der Master den Speicherort der Map-Zwischenergebnisse. 5. Der Reduce Worker greift über einen remote procedure call auf die lokale Festplatte des Map-Workers und lädt die dort gespeicherten Map-Zwischenergebnisse herunter. 6. Der Reduce-Worker iteriert über alle Zwischenergebnisse und weisst alle Werte eines eindeutigen Keys der Reduce-Funktion als Inputdaten zu. Für jede Partition wird eine Ausgabedatei angelegt, in die die Ergebnisse der einzelnen Reduce-Funktion eingetragen werden. 7. Nach Abschluss aller Map- und Reduce-Tasks weckt das Framework die aufrufende Useranwendung auf. Die Anwendung erhält Zugriff auf die Ergebnisse und kann diese in ihrem Programm verarbeiten [DG04, Seite 4]. Beispiel eines MapReduce Ablaufs Eines der gängigsten Beispiele zur Illustration des MapReduce Ansatzes ist das Zählen von Worthäufigkeiten innerhalb einer großen Datenmenge. In einem ersten Schritt muss die Daten- 5

38 menge in kleinere Einheiten gesplittet werden. Diese Dateneinheiten werden dann verteilt auf die unterschiedlichen Worker-Instanzen und gehen dort als Inputdaten in die Map-Funktionen ein. Entsprechend der Spezifikation des Frameworks sehen die Map-Funktion folgendermaßen aus: Instanz 1: map(input1, ein Satz mit Worten, Worten die ein ) Instanz 2: map(input2, ein anderer Satz mit noch mehr Worten ) Instanz 3: map(input3, alles hat ein Ende nur die ) Auf allen Instanzen liegt die gleiche Implementierung der Map-Funktion vor. Es liegt in der Verantwortung des Anwenders die Daten innerhalb der Funktion zu verarbeiten. Unsere Beispielfunktion zählt die Häufigkeit eines Wortes und gibt als Ergebnis eine Liste mit Zwischenergebnissen aus, die entsprechend der Vorgaben des Frameworks folgende Outputdaten generiert: Instanz1: [(ein,1), (Satz,1), (mit,1),(worten,1), (Worten,1), (die,1), (ein, 1)] Instanz2: [(ein,1),(anderer, 1),(Satz,1),(mit, 1)...] Instanz3: [(alles, 1), (hat,1), (ein, 1),(Ende, 1), (nur, 1), (die, 1)] Diese Outputdaten werden zu Zwischenergebnissen zusammengefasst, die als Inputdaten in die Reduce-Phase eingehen. In der Reduce-Funktion wird dann die Häufigkeit eines Wortes über den gesamten Datenbestand ermittelt. reduce(ein, [(1,1),(1),(1)]) 4 reduce(satz, [(1),(1)]) Fehlertoleranz Der MapReduce Ansatz wird herangezogen, um die Verarbeitung von grossen Datenmengen effizienter zu gestalten. Dabei werden Prozesse parallelisiert und auf eine Vielzahl (tausende) von Rechnern verteilt. Mit wachsender Anzahl der involvierten Maschinen steigt die Anzahl der geplanten und ungeplanten Ausfälle. Der Ausfall wird damit zur Regel und dementsprechend im MapReduce Ansatz von Google behandelt Ausfall einer Worker-Instanz Der Master hat die Aufgabe Ausfälle von Worker-Instanzen zu identifizieren und Ausweichstrategien umzusetzen. Um ausgefallene Worker zu identifizieren, pingt der Master sämtliche Wor- 6

39 ker an. Antwortet der Worker nicht innerhalb einer bestimmten Zeit, gilt er als ausgefallen. Die Ausweichstrategie des Masters sieht dann folgendes Vorgehen vor: von ausgefallenen Workern abgeschlossene Map-Tasks werden zurückgesetzt Die Ergebnisse der Map-Tasks werden lokal abgelegt und sind nach dem Ausfall nicht mehr verfügbar. Die Ergebnisse abgeschlossener Reduce Tasks liegen im globalen File System und müssen daher nicht wiederholt werden. von ausgefallenen Workern begonnen Map- oder Reduce-Tasks werden zurückgesetzt Diese können nun analog zu abgeschlossenen Map-Tasks von anderen Workern übernommen werden [DG04, Seite 4] Ausfall des Masters Der Ausfall des Masters bedeutet den Ausfall des ganzen Systems, da die Prozesse zwischen Map- und Reduce-Workern nicht mehr koordiniert werden. Damit ist der Master ein Single Point of Failure. Im MapReduce Ansatz von Google wird der Ausfall des Masters als eher unwahrscheinlich betrachtet, da es es sich im Gegensatz zu den Worker Maschinen lediglich um eine einzige Maschine handelt. Allerdings sieht das Framework die Möglichkeit vor, bei der Sicherungspunkte regelmäßig protokolliert werden. Bei einem Ausfall könnte eine neue Master-Instanz anhand der protokollierten Sicherungspunkte neu gestartet werden [DG04, Seite 5]. 3 Google File System 3.1 Architektur Ein Google Filesystem Cluster besteht aus einem Master, vielen Chunkservern (Datenserver) und wird in der Regel von vielen unterschiedlichen Clients genutzt. In der Regel werden für den Aufbau des Clusters Linux-Rechner eingesetzt. Daten sind unterteilt in Chunks fester Grösse (64 MB). Jeder Chunk (Datenblock) verfügt über 7

40 eine 64 bit Chunk-Referenz (handle), über die der Chunk eindeutig identifiziert werden kann. Die Chunkserver speichern Chunks als Linux Files auf der lokalen Festplatte. Jeder Chunk ist zur Sicherheit auf mehreren (default = 3) Chunkservern repliziert. Der Master hält u.a Metadaten über den aktuellen Ort der Chunks und über das Mapping von Files zu Chunks. Dabei setzt der Master regelmäßig Heartbeat-Nachrichten an die Chunkserver ab, um deren Status abzufragen und Anweisungen zu erteilen. Abbildung 3: GFS Architektur [GGL03, Seite 3] Clients, die das GFS nutzen kommunizieren mit dem Master und den Cunkservern, um Datenschreib- und Leseoperationen durchzuführen. Dabei werden mit dem Master lediglich Metadaten (filename, chunk location etc.) ausgetauscht. Der tatsächliche Datenfluss (chunk data) erfolgt ausschließlich direkt mit den Chunkservern [GGL03, Seite 30]. 3.2 Funktionsweise Lesezugriffe Clients die das GFS nutzen greifen über die GFS API auf ihre Daten zu. Beim Lesezugriff durch den Client sendet das Filesystem einen Request an den Master. Der Request enthält den Dateinamen und Informationen über den angeforderten Abschnitt innerhalb der Datei. Der Master ermittelt die Handle der betroffenen Chunks sowie sämtliche Chunkserver, auf denen die Chunks 8

41 repliziert sind. Der Client erhält vom Master die ermittelten Metadaten (Chunk-Handle, Liste aller betroffenen Chunkserver). Der Client wählt unter Berücksichtigung der eigenen Entfernung zu den Chunkservern einen geeigneten Server aus und fordert bei diesem die Daten an. Ergeben sich Probleme (korrupte Daten, Verfügbarkeit des Chunkservers) berichtet dies der Client dem Master und fragt die Daten bei einem der anderen Chunkserver aus der Liste an. Abbildung 4: Leseoperation GFS [PAS07, Seite 5] Schreibzugriffe Beim Schreibzugriff durch den Client sendet die API einen Request an den Master. Der Request enthält den Dateinamen und Informationen über den betroffenen Abschnitt innerhalb der Datei. Da beim Schreibzugriff Daten verändert werden, muss der Master den Vorgang mit anderen Modifikationen auf dem gleichen Chunk synchronisieren. Hierzu ernennt der Master einen Chunkserver zum primären Replikationsserver. Der primäre Replikationsserver erhält einen chunk lease. Dabei handelt es sich um das Recht, die Reihenfolge der Änderungen auf einem Chunk zu bestimmen und diese Reihenfolge den anderen Chunkservern vorzugeben. Dieser Mechanismus dient der Konsistenzsicherung der Daten. Der Master übermittelt an den Client den Handle des Chunks, die Adresse des primären Replikationsservers sowie die aller weiteren Chunksever, auf denen der Chunk repliziert ist. Im nächsten Schritt propagiert der Client die Daten an einen der betroffenen Chunkserver. Diese werden von einem Chunkserver zum anderen übertragen. 9

42 Bisher ist noch keine Modifikation der Daten erfolgt. Erst wenn alle Chunkserver den Erhalt der Daten bestätigen, setzt der Client einen Request mit einer Schreibaufforderung an den primären Replikationsserver ab. Es kann mehrere simultane Modifikationsanfragen von Clients zum gleichen Chunk geben. Der primäre Chunkserver erstellt hierzu einen Ausführungsplan. Der Ausführungsplan wird dann auf die erhaltenen Daten angewendet. Anschließend übermittelt der primäre Replikationsserver den Request mit der Schreibanweisung sowie dem Ausführungsplan an alle weiteren betroffenen Chunkserver. Diese führen dann ebenfalls die Modifikationen entsprechend des Ausführungsplans durch. Bei jeder Modifikation eines Chunks erhöht sich seine Versionsnummer. Anhand der Versionsnummer kann der Master veraltete Chunks identifizieren und ggf. eine Neureplikation veranlassen. Nach Abschuss der Modifikation auf allen Chunkservern wird dem Client der Erfolg kommuniziert. Abbildung 5: Schreiboperation GFS [PAS07, Seite 6] Metadaten und Masteroperationen Metadaten Der Master administriert drei Typen von Metadaten, die alle im Arbeitsspeicher des Masters gehalten werden: Namespace des Files und des Chunks 10

43 File-to-Chunk Mappings (Verknüpfung zwischen Files und Chunks) Adresse jeder Replikation eines Chunks Metadaten über Namespaces und File-to-Chunk Mappings werden im Operation Log lokal persistiert und auf andere Rechner repliziert. Im Operation Log werden kritische Metadaten-Änderungen historisiert. Hierbei handelt es sich um eine zentrale Komponente des Google File Systems. Im Operation Log erfolgt die einzige Persistierung der Metadaten. Darüber hinaus fungiert der Operation Log als logische Zeitachse, anhand derer die Abfolge konkurrierender Modifikationen nachvollzogen werden kann. Dies gilt für Files und Chunks sowie deren Versionierung. Master Operationen Ein Google File System Cluster besteht in der Regel aus hunderten von Chunkservern. Verteilt über mehrere Maschinen und Server-Racks. Die Chunkserver werden wiederum von hunderten von Clients rackübergreifend aufgerufen. Diese Art der Multi-Level Verteilung stellt eine große Herausforderung bezüglich Zuverlässigkeit und Verfügbarkeit. Verteilungsstrategie bei Replikation Es reicht nicht die Daten über mehrere physische Rechner zu replizieren. Diese Strategie würde lediglich vor dem Ausfall einer Festplatte oder eines Rechners schützen. Bei einem Stromausfall oder Netzwerkproblem ist die Verfügbarkeit eines Chunks, der zwar auf mehreren Rechnern aber auf nur einem vom Ausfall betroffenen Rack repliziert ist, nicht mehr gegeben. Aus diesem Grund werden Chunks über mehrere Racks hinweg repliziert. Chunk Replikation Der Master repliziert einen Chunk immer dann, wenn die Anzahl der vorhandenen Replikas eines Chunks unterhalb einer vorgegeben Grenze fällt. Hierfür kann es unterschiedliche Gründe geben: Ein Chunkserver ist nicht länger verfügbar Ein Chunkserver meldet korrupte Daten für den angeforderten Chunk Eine Festplatte des Chunkservers ist aufgrund von Problemen deaktiviert 11

44 Die vorgegebene Grenze für die Anzahl der vorhandenen Chunkserver wurde erhöht Muss ein neues Replikat eines Chunks erzeugt werden, wird diese Aufgabe vom Master priorisiert. Je grösser die Anzahl der fehlenden Replikas eines Chunks ist, desto höher ist die zugewiesene Priorität. Chunks von aktiven Files werden gegenüber denen von gelöschten Files höher priorisiert. Die Priorität von Chunks, die Client Prozesse blockieren wird ebenfalls sehr hoch einstuft [GGL03, Seite 36]. 3.3 Fehlertoleranz Google setzt beim Aufbau großer Rechnercluster auf günstige Standard Hardware, so dass mit wachsendem Cluster, der Ausfall einzelner Komponenten nicht die Ausnahme sondern die Regel darstellt. Fehlertoleranz war damit einer der wichtigsten Herausforderung bei der Gestaltung des Google File Systems. Folgende Ausfallursachen können unterschieden werden: Ausfall einer Festplatte Ausfall einer Maschine Ausfall von Ressourcen (Strom, Netzwerk) Missglückte Kommunikation (z.b. ein Chunkserver erhält Updatenachricht nicht) Ausfälle von Komponenten führen dazu, dass Daten nicht verfügbar sind oder schlimmer korrupt werden. Das Google File System berücksichtigt die Unvermeidbarkeit von Ausfällen und hat unterschiedliche Mechanismen zur Gewährleistung von Hochverfügbarkeit und Datenintegrität umgesetzt. Heartbeat Jeder Chunkserver setzt in definierten Abständen Hearbeat-Nachrichten an den Master ab. Die Heartbeat Nachrichten dienen dazu, einen regelmäßigen Nachrichtenaustausch zwischen Master und Chunkserver aufrecht zu erhalten. Der Chunkserver informiert den Master über die von ihm gehaltenen Chunks. Als Antwort sendet der Master eine Liste der Chunks, die nicht länger in seinen Metadaten repräsentiert sind. Der Chunkserver kann diese Chunks daraufhin löschen. Vor dem Hintergrund der Häufigkeit von Hardwareausfällen in grossen Clustern, nutzt der Master die 12

45 Heartbeat-Funktion zur Prüfung der Verfügbarkeit von einzelnen Chunkservern. Bleibt die Heartbeat-Nachricht eines Chunkservers für einen vorgegeben Zeitraum aus, wird dieser als tot deklariert. Der Master setzt eine Nachricht an die anderen Chunkserver, die über Replikate des betroffenen Chunks verfügen, ab. Inhalt der Nachricht ist die Anweisung sich zu replizieren [GGL03, Seite 37]. Chunk Replikation Der Master erstellt Klone von jedem Chunk, die auf unterschiedlichen Chunkservern und Racks verteilt werden. Die Standardkonfiguration sieht vor, jeden Chunk dreifach zu replizieren und entsprechend der Verteilungsstrategie auf unterschiedlichen Chunkservern zu platzieren. Bei einem Ausfall eines Chunkservers geht nicht eine ganze Datei verloren, sondern lediglich die Chunks der Datei, die sich auf dem betroffenen Chunkserver befunden haben. Zur Rekonstruktion der Datei greift der Master auf die Replikate des Chunks auf anderen Servern zu. Die Verteilungsstrategie gibt vor, dass die einzelnen Chunks rackübergreifend repliziert werden. Dadurch ist sichergestellt, dass selbst beim Ausfall eines kompletten Racks ein Replikat immer auf einem anderen Rack noch verfügbar ist [GGL03, Seite 37]. Verfügbarkeit des Masters Bei dem Thema Verfügbarkeit ist der Master als Single Point of Failure ein wichtiger Faktor. Sämtliche Anwendungen (z.b MapReduce oder Hadoop), die direkt das Verteilte Filesystem (GFS oder HDFS) nutzen, sind durch die Verfügbarkeit des Masters limitiert [COL11]. Im folgenden werden die wichtigsten Mechanismen zur Verfügbarkeit des Masters beschrieben: Replikation des Operation Logs Der Master wird nicht repliziert. Im ganzen System gibt es nur eine einzige Master-Instanz. Dies macht den Master zu einem Single Point of Failure. Der Master speichert die Metadaten in seinem lokalen Filesystem. Beim Start des Masters werden sämtliche Metadaten in den Arbeitsspeicher geladen. Sämtliche Modifikationen der Metadaten werden zum einen lokal persistiert und zum anderen in den Operation Log geschrieben. Dieser wird auf viele Rechner repliziert. Eine Änderung gilt erst dann als abgeschlossen, wenn die Änderung auf sämtlichen Operation Log Instanzen ausgeführt wurde. Bei einem Ausfall des Masters kann dieser unverzüglich wieder gest- 13

46 artet werden und den Zustand vor dem Ausfall mittels des Operation Logs wieder herstellen. Fällt der Master komplett aus, wird eine neue Master-Instanz erzeugt. Diese kann anhand einer Replikation des Operation Logs den aktuellen Stand des Systems erlangen. Die Clients kennen lediglich den DNS-Alias Namen des Masters, so dass der Umzug des Masters für die Clients transparent erfolgt. Schadow Masters Ein weiterer Mechanismus, der bei einem Ausfall greift, sind die sogenannten shadow master. Shadow Master ermöglichen den Clients Leseoperationen auf das Filesystem, selbst wenn der primäre Master ausgefallen ist. Dabei wird ein Replikat des Operation Logs vom Shadow Master eingelesen und auf den eigenen Meta Daten die gleichen Operationen ausgeführt wie der primäre Master zuvor. Dies erfolgt mit einer kleinen Zeitverzögerung. Bei einem Ausfall können dem Shadow Master die letzten Änderungen fehlen. Für viele Applikationen ist das unkritisch. Vor allem, da sich die eigentlichen Daten auf den Chunkservern befinden. D.h unter Umständen sind zwar die Metadaten, die dem Shadow Server vorliegen veraltet, die Daten, die den Applikationen für Leseoperationen bereit gestellt werden aber nicht unbedingt [GGL03, Seite 37]. Datenintegrität Jeder Chunkserver generiert Checksummen, um Datenkorruption der von ihm gespeicherten Daten identifizieren zu können. Die Spezifikation des Google File Systems garantiert nicht, dass sämtliche Instanzen eines Chunks ständig identisch sind. Das Vergleichen sämtlicher Chunks, um sicherzustellen, dass ein Chunk nicht korrupt ist, ist daher nicht möglich. Darüber hinaus kann der Fall eintreten, dass mehrere Instanzen zu einem Zeitpunkt korrupt sind. Das Google File System sieht daher vor, dass jeder Chunkserver selbst verantwortlich ist, auf Datenkorruption zu prüfen. Jeder Chunk ist ist in 64 KB Blöcke unterteilt. Jeder Datenblock verfügt über eine 32 bit Checksumme. Die Checksumme wird als Meta Datum im Arbeitsspeicher gehalten und mit dem Logging persistiert. Bei Lesezugriffen prüft der Chunkserver die Checksumme. Korrupte Daten werden nicht an Clients oder andere Chunkserver propagiert. Der Master erhält eine Nachricht über den Fehler, stößt eine Rereplikation (Chunk mit korrekten Daten wird an Chunkserver übermittelt) an und fordert den betroffenen Chunkserver auf, den korrupten Chunk zu entfernen [GGL03, Seite 38] 14

47 3.4 Konsistenzmodell Das Konsistenzmodell des Google File Systems wird als einfach und effizient beschrieben und ist auf Anforderungen stark verteilter und zu Ausfällen neigender Cluster ausgelegt. Im folgenden werden die Zusagen beschrieben, die das Google File System bezüglich Konsistenz macht. Änderungen an Namespaces (Erzeugung neuer Chunks) sind atomar und werden ausschließlich durch den Master durchgeführt. Der Zustand einer Dateiregion nach einer Mutation hängt von der Art und dem Erfolg der Mutation ab: Eine Dateiregion ist konsistent, wenn alle Clients nach einer Mutation auf allen Kopien dieselben Daten sehen. Eine Dateiregion gilt als defined, wenn sie konsistent ist und die Clients das Ergebnis einer einzelnen Datenmutation in Gänze sehen können (d.h. es liegt keine konkurrierende Mutation vor, bei der dem Client lediglich das Ergebnis aus allen Mutation ersichtlich ist) Tritt bei einer Mutation ein Fehlerfall ein, ist die Dateiregion inkonsistent. Unterschiedliche Clients können unterschiedliche Daten erhalten. Veraltete Replikate (Versionsnummer nicht aktuell) werden bei Mutationen nicht berücksichtigt. Der Master gibt deren Adresse nie an Clients weiter. Veraltete Replikate werden von der Garbage Collection beim nächst möglichen Zeitpunkt entfernt. Da Clients die Adresse von Chunks jedoch cachen, ist es durchaus möglich, dass Clients die Daten von veralteten Replika anfragen, bevor diese entfernt werden konnten. Das Zeitfenster, in dem der Client veraltete Daten erhält ist beschränkt durch den Time out des Cache Eintrags und durch das Öffnen des betroffenen Files (Cache ist gezwungen sämtliche Chunk-Informationen des Files zu löschen). 15

48 4 Überblick Unterschied Hadoop Google MapReduce Zunächst gilt es zu unterscheiden zwischen dem MapReduce Konzept, das von Google entwickelt und veröffentlicht wurde, und Googles eigener Implementierung des Konzepts Google MapReduce. Hadoop und Google MapReduce implementieren beide das MapReduce Konzept. Der wichtigste Unterschied zwischen Google MapReduce und Hadoop ist, dass es sich bei Hadoop um ein Open Source Projekt handelt, das von jedem sowohl genutzt als auch modifiziert werden kann. Weitere Unterschiede sind: Die MapReduce Implementierung von Google wurde für den internen Gebrauch in C++ geschrieben Hadoop ist in Java implementiert Hadoop umfasst sowohl die MapReduce-Implementierung als auch das Hadoop Distributed Filesystem Weitere Unterschiede finden sich in den verteilten Dateisystemen HDFS und GFS Architektur Die Architektur von HDFS und GFS ist vom Aufbau nahezu gleich. Unterschiede finden sich in den Bezeichnungen der einzelnen Komponenten: Hadoop Filesystem NameNode DataNode Block Appending-writes Operationen Google Filesystem Master Chunkserver Chunk Bei der Entwicklung von HDFS setzt man auf den Ansatz write-once-read-many. Dabei wird davon ausgegangen, dass Dateien, die einmal erstellt und beschrieben werden, nicht mehr verändert werden müssen. Dies gilt vor allem für MapReduce Applikationen oder bspw. web crawler Applikationen. Appending-writes Operationen, wie sie das Google Filesystem anbietet, werden von HDFS noch nicht unterstützt [BOR11, Seite 3]. 16

49 Literaturverzeichnis [BOR11] Borthakur, Dhruba: HDFS Architecture. Web Publikation. Stand [CLO11] Cloudera: What is Hadoop. Web Publikation. Stand [COL11] Collins, Eli: Hadoop Availability. Web Publikation. Stand [DG04] Dean,J.; Ghemawat,S.: MapReduce: Simplified Data Processing on Large Clusters. In: Proceedings of Operating Systems Design and Implementation (OSDI). San Francisco, CA, 2004, S [FIS10] Fischer, Oliver: Verarbeiten großer verteilter Datenmengen mit Hadoop. Web Publikation Stand [GGL03] Ghemawat, S.; Gobioff, H.; Leung, S.-T.: The GoogleFileSystem. In: 19 th Symposium on Operating Systems Principles. LakeGeorge, NewYork, 2003, S [GOO11] Google. Web Publikation. Stand [HAD11] Hadoop. Web Publikation. Stand [PAS07] Passing, Johannes: The Google File System and its application in MapReduce. Web Publication. Stand

50 Abbildungsverzeichnis Abbildung 1: Map-Phase [Eigene Darstellung]...3 Abbildung 2: Ablaufübersicht MapReduce [DG04, Seite 4]...4 Abbildung 3: GFS Architektur [GGL03, Seite 3]...8 Abbildung 4: Leseoperation GFS [PAS07, Seite 5]...9 Abbildung 5: Schreiboperation GFS [PAS07, Seite 6]...10

51 HadoopDB a major step towards a dead end Thema 5 Seminar Sommersemester 2011 Referent: Thomas Koch June 23,

52 Contents 1 HadoopDB Scope and Motivation Architecture Benchmarks Data Sets Grep Task Selection Task Aggregation Tasks Join Task UDF Aggregation Task Fault tolerance and heterogeneous environment Summary and Discussion Hive Data Model Query Language Architecture

53 This paper presents and discusses two texts about HadoopDB[ABPA + 09] and the Apache Hive[TSJ + 09] project which is used by the former. 1 HadoopDB 1.1 Scope and Motivation The HadoopDB project aims to combine the scalability advantages of MapReduce with the performance and efficiency advantages of parallel databases. Parallel databases in this context are defined as analytical DBMS systems [sic] that deploy on a shared-nothing architecture. Current parallel databases are usually scaled only into the tens of nodes. It may be impossible to scale them into hundreds or thousand nodes like MapReduce for at least three reasons: 1. Failures become frequent at this scale but the systems don t handle them well. 2. A homogeneous cluster of machines is assumed which is impossible to provide at higher scale. 3. The systems has not yet been tested at this scale. MapReduce on the other hand is known to scale well into thousands of nodes. However, according to work done by Stonebraker and others, MapReduce would neither be suitable for analytical work[dd08] nor perform well[ppr + 09]. A further advantage of HadoopDB should be low cost. This could be achieved by building on existing open source solutions: The MapReduce implementation Apache Hadoop, Apache Hive and the RDBMS PostgreSQL. It may however be argued whether these components could be used without cost as claimed. The production use of software like Hadoop and PostgreSQL still requires highly qualified and payed personal. Desired Properties The following list presents the desired properties of the HadoopDB project together with first comments. It is argued that neither MapReduce nor parallel databases would provide all of these properties. Performance: It is claimed, that performance differences could make a big difference in the amount, quality, and depth of analysis a system can do. Also performance could significantly reduce the cost of an analysis if fewer hardware ressources were used. However Stonebraker and Abadi concluded already in 2007 that the primary factor for costs has shifted from hardware to personal.[sma + 07, 2.5 No Knobs] It should also be considered that the costs for licenses of proprietary database systems often outrun hardware costs by orders of magnitude. Finally it is not at all certain, that in practice performance differences are a limitation factor for the range of possible computations. The paper suggests that current practice in analytical systems would be to load data in a specialized database and to make calculations while an operator is waiting for the results. In MapReduce systems however calculations are directly done on the original data and could therefor run continuously during the normal operation of the system. The performance of calculations may therefor not be a practical problem at all. Fault Tolerance: The probability, that at least one cluster node fails during a computation may be negligible for less then 100 nodes. With growing data size however the cluster needs to grow. Therefor the probability of a single node failure grows as well 3

54 as the duration of algorithms. This continues until it s not possible anymore to finish calculations without a single node failing. A system that restarts the whole computation on a single node failure, as typical in RDBMSs, may never be able to complete on large enough data sizes. Ability to run in a heterogeneous environment: Most users of a large cluster would not be able to provide a large number of totally identical computer nodes and to keep there configuration in sync. But even then the performance of components would degrade at different pace and the cluster would become heterogeneous over time. In such an environment work must be distributed dynamically and take node capacity into account. Otherwise the performance could become limited by the slowest nodes. Flexible query interface: The system should support SQL to integrate with existing (business intelligence) tools. Ideally it also supports user defined functions (UDF) and manages their parallel execution. The above list does not include energy efficiency as a desired property although it is one of the most important subjects in recent discussions about data centers. 1 It has also been argued, that standard performance benchmarks should be enhanced to measure the performance relative to energy consumption.[fhh09] Section 4 describes the parallel databases and MapReduce in further detail. From the desired properties the former would score well on performance and the flexible interface and the later on scalability and the ability to run in a heterogeneous environment. A paper of Stonebraker, Abadi and others[ppr + 09] is cited for the claim of MapReduces lack of performance. This paper is cited over twenty times in the full HadoopDB text and is also the source for the benchmarks later discussed. Other evidence for a lack of performance of MapReduce is not provided. It is also recognized that MapReduce indeed has a flexible query interface in that its default usage requires the user to provide map and reduce functions. Furthermore the Hive project provides a SQL like interface to Hadoop. Thus although it isn t explicitly said it could be concluded that MapReduce also provides a flexible query interface. It can be summed up at this point, that MapReduce is excellent in two of four desired properties, provides a third one and only lacks in some degree in performance. Hadoop is still a very young project and will certainly improve its performance in the future. It may be asked, whether a project like HadoopDB is still necessary, if Hadoop itself already provides nearly all desired properties. It is interesting, how the great benefit of not requiring a schema up-front is turned into a disadvantage against MapReduce:[ABPA + 09, 4.2] By not requiring the user to first model and load data before processing, many of the performance enhancing tools listed above that are used by database systems are not possible. Traditional business data analytical processing, that have standard reports and many repeated queries, is particularly, poorly suited for the one-time query processing model of MapReduce. Not requiring to first model and load data provides a lot of flexibility and saves a lot of valuable engineering time. This benefit should be carefully evaluated and not just traded against performance. The quote also reveals another possible strategy to scale analytical processing: Instead of blaming MapReduce for its favor of one-time query processing, the analytical software could be rewritten to not repeat queries. It ll be explained later that Hive provides facilities to do exactly that by allowing the reuse of SELECT statements. 1 see Googles Efficient Data Center Summits html ( ) and Facebooks open compute project ( ) 4

55 Figure 1: The Architecture of HadoopDB[ABPA + 09] 1.2 Architecture Hive is a tool that provides a SQL interface to MapReduce. It translates SQL queries into apropriate combinations of map and reduce jobs and runs those over tabular data stored in HDFS. HadoopDB extends Hive in that HDFS is replaced by node local relational databases. Data Loader HadoopDB comes with two executable java classes and a python script 2 necessary to partition and load the data into HadoopDB. The data loading is a cumbersome process with several manual steps. Most of the steps must be executed in parallel on all nodes by some means of parallel ssh execution. This leaves a lot of room for failures. It is also necessary to specify the number of nodes in advance. A later change in the number of nodes requires to restart the data load process from scratch. It is also not possible to incrementally add data. The following list describes the necessary steps to load data into HadoopDB. At each step it is indicated how often the full data set is read (r) and written (w). It is assumed, that the data already exists in tabular format in HDFS and that HDFS is used for this process with a replication factor of 1. This means that in case of a hard drive failure during the import process the process would need to be started again from the beginning. A higher replication factor would lead to even higher read and write numbers in the following list. 1. Global Hasher: Partition the data set into as many parts as there are nodes in the cluster. (2r, 2w + 1 network copy) 3 2 ( ) 3 The result of the map phase is written to disk and from there picked up by the reduce phase. 5

56 2. Export the data from HDFS into each nodes local file system. (1r, 1w) 4 3. Local Hasher: Partition the data into smaller chunks. (1r, 1w) 4. Import into local databases. (1r, 1w + secondary indices writes) We can see, that before any practical work has been done, HadoopDB implies five full table scans and writes. In the same time at least 2.5 map and 2.5 reduce jobs could have completed. If we assume that the results of typical map and reduce jobs are usually much smaller then the input, even more work could have been done. There are indications that it may be possible to optimize the data loading process to lower the number of necessary reads and writes. It will be discussed in the benchmark section, why this doesn t seem to be of high priority for the HadoopDB authors. Neither the HadoopDB paper nor the guide on sourceforge make it totally clear what the purpose of the Local Hasher is. It is suggested that a partitioning in chunks of 1GB is necessary to account for practical limitations of PostgreSQL when dealing with larger files. 5 SQL to MapReduce to SQL (SMS) Planner The heart of HadoopDB is the SMS planner. Hive translates SQL like queries into directed-acyclic graphs (DAGs) of relational operators (such as filter, select (project), join, aggregation). These operator DAGs (the query plan) are then translated to a collection of Map and Reduce jobs and sent to Hadoop for execution. In general before each JOIN or GROUP BY operation data must be shared between nodes. The HadoopDB project hooks into Hive just before the operations DAG gets sent to Hadoop MapReduce.(Figure 1) The planner walks up the DAG and transforms all operators until the first repartitioning operator with a partitioning key different from the database s key back into SQL queries for the underlying relational database. For those SQL queries where HadoopDB can push parts of the query into the database one could expect a performance gain from secondary indices and query optimization. For other SQL queries one should expect the same performance as with plain Hive. In contrast to Hive HadoopDB can and does take advantage of tables that are repartitioned by a join key and pushes joins over these keys in the database layer. Auxiliary Components HadoopDB includes code to connect to the local databases and a catalog that stores database connection parameters and metadata such as data sets contained in the cluster, replica locations, and data partitioning properties. The catalog must also be generated manually from two input files which adds to the work necessary to setup the data. 1.3 Benchmarks Five different tasks are provided to benchmark two parallel databases (Vertica, DBMS-X), Hadoop and HadoopDB on three different number of nodes (10, 50, 100). The tasks are executed under the assumption of no node failures. Thus the replication factor of HDFS respectively the number of replicas in HadoopDB is set to 1 and the task run is not counted in case of a node failure. In a later task run node failures are also taken into account. The tasks are borrowed from the already mentioned Stonebraker paper[ppr + 09]. It is therefor necessary to refer to Stonebrakers work for their description at some points. 6

57 CREATE TABLE Documents ( url VARCHAR(100) PRIMARY KEY, contents TEXT ); CREATE TABLE Rankings ( pageurl VARCHAR(100) PRIMARY KEY, pagerank INT, avgduration INT ); CREATE TABLE UserVisits ( sourceip VARCHAR(16), desturl VARCHAR(100), visitdate DATE, adrevenue FLOAT, useragent VARCHAR(64), countrycode VARCHAR(3), languagecode VARCHAR(6), searchword VARCHAR(32), duration INT ); Figure 2: Tables used for the analytical benchmark tasks Data Sets The first task (Grep) uses a simple schema of a 10 bytes key and a random 90 bytes value field. The next three analytical tasks work on a more elaborate schema of three tables. (Figure 2) This schema was originally developed by Stonebraker and others to argue that parallel databases could also be used in areas where MapReduce recently became popular.[ppr + 09, 1.] The Documents table should resemble the data a web crawler might find while the UserVisits table should model log files of HTTP server traffic. The Rankings table is not further described.[ppr + 09, 4.3] It seems that Stonebraker has a very naive idea of the inner workings of a typical web crawler and the information typically logged by a HTTP server. The BigTable paper from 2006 explains, that Google stores multiple versions of crawled data while a garbage collector automatically removes the oldest versions.[cdg + 06] This requirement alone would be very complicate to model on top of a relational data store. Furthermore a web crawler would certainly store a lot more data, for example the HTTP headers sent and received, which may be several pairs due to HTTP redirects or a history when the page was last loaded successfully along with the last failed loading attempts and the reasons for those failures. Subsequental processes enrich the data for example with data extracted from HTML or the HTTP headers and with a list of web sites pointing to this site (inlinks) together with the anchor text and the page rank of the inlinks. The pagerank column from the Rankings table would surely be inlined into the Documents table. The UserVisits table is likely unrealistic. A HTTP server usually has no knowledge of any adrevenue related to a web site just served, nor is anything known about a searchword. Web sites that highlight search words previously entered in a search engine to find that page do so by parsing the HTTP referrer header. A HTTP server is usually not capable to extract this information. The same is valid for the HTTP accept language header which provides a languagecode. A countrycode can usually only be obtained by looking up the users IP address in a so called geoip database. The most important flaw in the data sets however is the assumption of a separated, off line data analytics setting. Todays search engines need to reflect changes in crawled pages as soon as possible. It is therefor typical to run the whole process of crawling, processing and indexing on the same database continuously and in parallel.[pd10] It is understandable that Abadi choose to reuse the benchmarks to enable comparison. However he wants to demonstrate the applicability of HadoopDB for Analytical Workloads. 4 It is not clear, why this step is necessary. The reduce output from the previous step could have been written directly to the local file systems of the nodes running the reduce jobs. 5 We recommend chunks of 1GB, because typically they can be efficiently processed by a database server. 7

58 One should therefore expect benchmarks that use schemes related to financial, customer, production or marketing data. Data Loading It has already been described how complicated the data loading procedure is. The benchmark measured a duration of over 8.3 hours for the whole process. Not accounted for is the manual work done by the operator during the individual steps to start each individual step, let alone the provisioning and preparation of virtual machines. Since the process is not (yet) automatized and may even need to be restarted from scratch in case of failures, it can in practice take two working days. The HadoopDB authors however do not consider this to be a problem[abpa + 09, 6.3]: While HadoopDB s load time is about 10 times longer than Hadoop s, this cost is amortized across the higher performance of all queries that process this data. For certain tasks, such as the Join task, the factor of 10 load cost is immediately translated into a factor of 10 performance benefit. This statement however ignores that data is often already stored on Hadoop in the first place and that Hadoop wouldn t require a load phase at all. Instead Hadoop could run analytical tasks incrementally or nightly and provide updated results while HadoopDB still struggles to load the data Grep Task The Grep Task executes a very simple statement over the already described key value data set: SELECT * FROM Data WHERE field LIKE %XYZ% ; Hadoop performs in the same area as HadoopDB and the parallel databases require less then half the time. It is argued that this difference in performance in such a simple query is mainly due to the use of data compression which results in faster scan times. Although Hadoop supports compression and could therefore share the same benefits, it isn t used. An explanation is found in the Stonebraker paper. They did some experiments with and without compression and in their experience Hadoop did not benefit from compression but even get slower. However it seems that there could be mistakes in their usage of Hadoop. Instead of using the Hadoop SequenceFile format to write compressed data, they split the original files in smaller files and used a separate gzip tool to compress them. There is no explanation why they did the splitting nor do they provide the compression level used with gzip. It is very likely that the raise in the number of files caused by the splits led to a higher number of necessary disk seeks. They also tried record-level compression. This is however pointless since the values in the Grep Task only have a length of 90 bytes and may even get larger from the compression header Selection Task The selection task executes the following query: SELECT pageurl, pagerank FROM Rankings WHERE pagerank > 10; The description and result diagram for this task is a bit confusing. The text says that HadoopDB would outperform Hadoop while the diagram on first sight reports comparable 8

59 execution times for both. The solution is that there is a second bar for HadoopDB reporting the duration for a data repartitioning that has been optimized for this task. It is questionable whether the long and complicated data loading is still tolerable, if it even has to be optimized for different queries. One would expect that the upfront investment of data modeling and loading would be rewarded by a great variety of possible queries that could be executed afterward with high performance Aggregation Tasks These two tasks differ only in their grouping on either the full sourceip or only a prefix of it. SELECT SUBSTR(sourceIP, 1, 7), SUM(adRevenue) FROM UserVisits GROUP BY SUBSTR(sourceIP, 1, 7); SELECT sourceip, SUM(adRevenue) FROM UserVisits GROUP BY sourceip; Hadoop and HadoopDB differ only in around 20% of their execution time while the parallel databases are again significantly faster. It is once again argued that this would be mainly caused by compression and therefor the same arguments apply as with the Grep Task. Furthermore this tasks points out the advantage of a high level access language. Hive (and thereby HadoopDB) benefited from automatically selecting hash- or sort-based aggregation depending on the number of groups per rows. A hand coded MapReduce job will most likely have only one of these strategies hard coded and not choose optimal strategies Join Task The join task needed to be hand coded for HadoopDB too due to an implementation bug in Hive. The equivalent SQL is: SELECT sourceip, COUNT(pageRank), SUM(pageRank), SUM(adRevenue) FROM Rankings AS R, UserVisits AS UV WHERE R.pageURL = UV.destURL AND UV.visitDate BETWEEN AND GROUP BY UV.sourceIP; In this task HadoopDB performs ten times faster then Hadoop but still significantly slower then the parallel databases. The databases (including HadoopDB) are said to benefit from a secondary index 6 on visitdate, the selection predicate. There are however at least three questions to be asked about this task. First, why would anybody want to run this query only for the specified weeks and not for all weeks? If this query would be run for all weeks then the databases would also need to scan all data and maybe approach the duration of Hadoop. Hadoop on the other hand would typically run a nightly run over its data to produce small daily statistics which in turn could be easily imported into a traditional relational database. Second, as already noted, the UserVisits table hardly resembles a typical server log. A typical server log would be ordered by visitdate. If the visitdate would be the primary key, then Hadoop should be able to execute the query much faster. Third, since the UserVisits table already contains data from other sources (adrevenue, countrycode, languagecode, searchword), why isn t there also a column for page rank? 6 Hive has also implemented support for secondary indices in the meanwhile. 9

60 This would of course duplicate data and break traditional database design but better match real world scenarios. In this case the join wouldn t be needed and the task would be mostly the same as the selection task already discussed UDF Aggregation Task This task represents the prime example of MapReduce. The data set consists of a large corpus of HTML documents. Those are parsed and the occurrence frequency of every url gets counted. Not only was it difficult to implement this task with the parallel databases, they also performed significantly worse then Hadoop. HadoopDB wasn t used with it s SQL layer but also queried by MapReduce Fault tolerance and heterogeneous environment All discussed tasks so far have been executed optimistically without any precautions for single node failures. To test the different performance of the systems in the presence of failures and in a heterogeneous environment the aggregation task with grouping on the prefixed sourceip has been repeated. This time the replication factor was set to 2 and for the fault tolerance test one random node was killed when half of the query was executed. The heterogeneous environment was tested in another round by slowing done one node by running an I/O intensive background job and frequent clears of the OS caches. The performance loss is reported in relation to the normal performance. Vertica suffers a dramatic slowdown of more then 100% in both cases since it restarts queries from the beginning on failure and does not move straggling tasks to other nodes. HadoopDB and Hadoop both profit from Hadoops inherent design for frequent failures. First Hadoop does not restart the whole query from scratch when one node fails but only that part of the query that the failed node performed. Second Hadoop runs second instances of straggling tasks on already finished nodes. This is called speculative execution. The later started tasks may finish earlier then tasks that run on faulty nodes with degraded performance. HadoopDB slightly outperforms Hadoop in the case of failing nodes. Hadoop is slowed down in this case because it is eager to create additional copies of the replicated data to provide the replication factor again as soon as possible. HadoopDB on the other hand does not copy data and would therefore suffer a data loss in case that two nodes containing the same data would fail. 1.4 Summary and Discussion The HadoopDB authors conclude that HadoopDB would outperform Hadoop in all but the last tasks and that it would therefore be a useful tool for large scale analytics workloads. The comments and discussions in the preceding subsections however challenge this conclusion. The long time to load data may be a problem. Some of the provided benchmarks are rather unrealistic. The number of nodes tested is still a lower limit for typical MapReduce installations. The usage of Hadoop may not have been optimal as seen in the discussion about compression. An experienced Hadoop engineer may be able to achieve better results with the given tasks. The fault tolerance of HadoopDB lacks the self healing mechanism of HDFS. And HadoopDB is designed to be a read only database parallel to the production databases. This seems to be a contradiction to the authors own remark that it would be a requirement to perform data analysis inside of the DBMS, rather than pushing data to external systems for analysis. [ABPA + 09, 7.1] If HadoopDB would be a useful contribution then it should probably have raised discussions, comments or recommendations on the internet. From this perspective however, 10

61 HadoopDB seems to have failed. Google reports 7 less then ten independent mentions of HadoopDB not counting the HadoopDB authors own publications. Since HadoopDB uses PostgreSQL and provides a solution to cluster this DBMS, one should expect some interest from the PostgreSQL community. There are however only a total of 15 mails in the projects list archive mentioning HadoopDB from which only 4 are from last year. 8 The public subversion repository of HadoopDB on SourceForge has only 22 revisions. 9 Although Hadoop is one of the most discussed award winning free software projects right now, HadoopDB did not manage to profit from this and raise any significant interest at all outside of academic circles. This may be one indicator for the correctness of critiques presented in this paper. An additional critique from a practical perspective may be the combination of two highly complicate systems, Hadoop and PostgreSQL. Both require advanced skills from the administrator. It is hard enough to find personal that can administrate one of these systems. It may be practically impossible to find personal competent in both. Both systems come with their own complexities that add up for little or no benefit. As already mentioned, Stonebraker already concluded that new databases must be easy to use because hardware is cheaper then personal. The HadoopDB guide however expects sophisticated manual work: 10 2 Hive a careful analysis of data and expected queries results in a significant performance boost at the expense of a longer loading. Two important things to consider are data partitioning and DB tuning (e.g. creating indices). Again, details of those techniques are covered in textbooks. For some queries, hash-partitioning and clustered indices improve HadoopDB s performance 10 times Hive has been developed by Facebook as a petabyte scale data warehouse on top of Hadoop. [TSJ + 09] A typical use case for Hive is to store and analyze incrementally (daily) inserted log data. It provides user interfaces and APIs that allow the submission of queries in a SQL like language called HiveQL. The application then parses the queries to a directed-acyclic graph (DAG) of Map Reduce jobs and executes them using Hadoop. 2.1 Data Model Data in Hive is organized and stored in a three level hierarchy: The first level consists of tables analogous to those in relational databases. Each table has a corresponding HDFS directory where it stores its data. Inside tables the data is further split into one or more partitions. Partitioning is done by the different values of the partitioning columns which each gets their own directory inside the table directory. Each subsequent partitioning level leads to an additional sub directory level inside its parent partition. Data can be further split in so called buckets. The target bucket is choosen by a hash function over a column modulo the desired number of buckets. 11 Buckets are 7 as of April 7th, searching for the term HadoopDB 8 as of April 8th 9 as of June 14th 10 ( ) 11 ( ) 11

62 representes as files in HDFS either in the table directory if there are no partitions or in the deepest partition directory. The following is an example path of a bucket in the table daily status with partitions on the columns ds and ctry. The hive workspace is in the wh directory: /wh/ daily status / ds = /ctry = US / 0001 } {{ } } {{ } }{{} table name nested partitions bucket Buckets are mostly useful to prototype and test queries on only a sample of the full data. This gives the user a meaningful preview whether a query is correct and could provide the desired information in a small fraction of the time it would take to run the query over the full data set. For this purpose Hive provides a SAMPLE clause that lets the user specify the number of buckets that should be used for the query. Although no reference has been found for this thesis, buckets may also be useful to distribute the write and read load to multiple HDFS data nodes. Assuming that partitions are defined on date and country as in the path example above and the daily traffic data of web servers in the US should be imported into Hive. In the absence of buckets this import would sequentially write one file after the other to HDFS. Only one HDFS data node would be written to 12 at any given time while the other nodes remaining idle. If the bucketing function is choosen so that nearby data rows are likely to end up in different buckets then the write load gets distributed to multiply data nodes. Columns in Hive can have the usual primitive scalar types including dates. Additionally Hive also provides nestable collection types like arrays and maps. Furthermore it is possible to program user defined types. 2.2 Query Language HiveQL looks very much like SQL. 13 Recent versions of Hive even support Views 14 and Indices 15. A design goal of Hive was to allow users to leverage their existing knowledge of SQL to query data stored in Hadoop. However Hive can not modify already stored data. This was a design decision to avoid complexity overhead. Thus there are no UPDATE or DELETE statements in HiveQL. [TSJ + 10] Regular INSERTs can only write to new tables or new partitions inside a table. Otherwise a INSERT OVERWRITE must be used that will overwrite already existing data. However since a typical use case adds data to hive once a day and starts a new partition for the current date there is no practical limitation caused by this. For extensibility Hive provides the ability for user defined (aggregation) functions. One example provided is a Python function used to extract memes from status updates. A noteworthy optimization and addition to regular SQL is the ability to use one SELECT statement as input for multiple INSERT statements. This allows to minimize the number of table scans: FROM (SELECT...) subq1 INSERT TABLE a SELECT subq1.xy, subq1.xz INSERT TABLE b SELECT subq1.ab, subq1.xy 12 plus the few replica nodes for the current data block 13 This ticket tracks tracks the work to minimize the difference between HiveQL and SQL: https://issues. apache.org/jira/browse/hive-1386 ( ) 14 since October 2010, 2BAC8-Drop_View ( ) 15 since March 2011, Index ( ) 12

63 Figure 3: Hive architecture 2.3 Architecture Hive consists of several components to interact with the user, external systems or programming languages, a metastore and a driver controlling a compiler, optimizer and executor. (Figure 3) The metastore contains the schema information for tables and information how data in this tables should be serialized and deserialized (SerDe information). This information can be overridden for individual partitions. This allows schemes and serialization formats to evolve without the necessity to rewrite older data. It is also planned to store statistics for query optimization in the metastore. 16 The compiler transforms a query in multiple steps to an execution plan. For SELECT queries these steps are: 1. Parse the query string into a parse tree. 2. Build an internal query representation, verify the query against schemes from the metastore, expand SELECT * and check types or add implicit type conversions. 3. Build a tree of logical operators (logical plan). 4. Optimize the logical plan Create a DAG of MapReduce jobs. 16 The hive paper suggests in its introduction, that the metastore would already store statistics which is later contradicted in section 3.1 Metastore. More information about the ongoing work for statistics is available from the Hive wiki and in the jira issue HIVE-33: ( ) https://issues.apache.org/jira/browse/hive-33 ( ) 17 The optimizer currently supports only rule but not cost based optimizations. The user can however provide several kinds of hints to the optimizer. 13

64 References [ABPA + 09] Abouzeid, Azza ; Bajda-Pawlikowski, Kamil ; Abadi, Daniel J. ; Rasin, Alexander ; Silberschatz, Avi: HadoopDB: An Architectural Hybrid of MapReduce and DBMS Technologies for Analytical Workloads. In: PVLDB 2 (2009), Nr. 1, [CDG + 06] Chang, Fay ; Dean, Jeffrey ; Ghemawat, Sanjay ; Hsieh, Wilson C. ; Wallach, Deborah A. ; Burrows, Mike ; Chandra, Tushar ; Fikes, Andrew ; Gruber, Robert E.: Bigtable: a distributed storage system for structured data. In: Proceedings of the 7th USENIX Symposium on Operating Systems Design and Implementation - Volume 7. Berkeley, CA, USA : USENIX Association, 2006 (OSDI 06), [DD08] D. DeWitt, M. S.: MapReduce: A major step backwards. mapreduce-a-major-step-backwards, accessed 11-April-2011 [FHH09] [PD10] Fanara, Andrew ; Haines, Evan ; Howard, Arthur: The State of Energy and Performance Benchmarking for Enterprise Servers. In: Nambiar, Raghunath (Hrsg.) ; Poess, Meikel (Hrsg.): Performance Evaluation and Benchmarking. Berlin, Heidelberg : Springer-Verlag, ISBN , Kapitel Performance Evaluation and Benchmarking, S Peng, Daniel ; Dabek, Frank: Large-scale incremental processing using distributed transactions and notifications. In: Proceedings of the 9th USENIX conference on Operating systems design and implementation. Berkeley, CA, USA : USENIX Association, 2010 (OSDI 10), 1-15 [PPR + 09] Pavlo, A. ; Paulson, E. ; Rasin, A. ; Abadi, D. J. ; DeWitt, D. J. ; Madden, S. ; Stonebraker, M.: A comparison of approaches to large-scale data analysis. In: SIGMOD 09 (2009) [SMA + 07] Stonebraker, Michael ; Madden, Samuel ; Abadi, Daniel J. ; Harizopoulos, Stavros ; Hachem, Nabil ; Helland, Pat: The End of an Architectural Era (It s Time for a Complete Rewrite). In: Koch, Christoph (Hrsg.) ; Gehrke, Johannes (Hrsg.) ; Garofalakis, Minos N. (Hrsg.) ; Srivastava, Divesh (Hrsg.) ; Aberer, Karl (Hrsg.) ; Deshpande, Anand (Hrsg.) ; Florescu, Daniela (Hrsg.) ; Chan, Chee Y. (Hrsg.) ; Ganti, Venkatesh (Hrsg.) ; Kanne, Carl-Christian (Hrsg.) ; Klas, Wolfgang (Hrsg.) ; Neuhold, Erich J. (Hrsg.): 33rd International Conference on Very Large Data Bases. Vienna, Austria : ACM Press, sep ISBN , S [TSJ + 09] Thusoo, Ashish ; Sarma, Joydeep S. ; Jain, Namit ; Shao, Zheng ; Chakka, Prasad ; Anthony, Suresh ; Liu, Hao ; Wyckoff, Pete ; Murthy, Raghotham: Hive- A Warehousing Solution Over a Map-Reduce Framework. In: Proceedings of the VLDB Endowment 2, Nr. 2, 2009, S [TSJ + 10] Thusoo, Ashish ; Sarma, Joydeep S. ; Jain, Namit ; Shao, Zheng ; Chakka, Prasad ; 0002, Ning Z. ; Anthony, Suresh ; Liu, Hao ; Murthy, Raghotham: Hive - a petabyte scale data warehouse using Hadoop. In: Li, Feifei (Hrsg.) ; Moro, Mirella M. (Hrsg.) ; Ghandeharizadeh, Shahram (Hrsg.) ; Haritsa, Jayant R. (Hrsg.) ; Weikum, Gerhard (Hrsg.) ; Carey, Michael J. (Hrsg.) ; Casati, Fabio (Hrsg.) ; Chang, Edward Y. (Hrsg.) ; Manolescu, Ioana 14

65 (Hrsg.) ; Mehrotra, Sharad (Hrsg.) ; Dayal, Umeshwar (Hrsg.) ; Tsotras, Vassilis J. (Hrsg.): ICDE, IEEE, (Proceedings of the 26th International Conference on Data Engineering, ICDE 2010, March 1-6, 2010, Long Beach, California, USA). ISBN , S

66 FernUniversität in Hagen Seminar im Sommersemester 2011 MapReduce und Datenbanken Thema 6 Dryad Referent: Björn Draschoff

67 INHALTSVERZEICHNIS 1 Einführung ins Thema Problemdefinition Lösungsansatz Charakteristikum von Dryad Systemarchitektur Beispiel SQL-Abfrage Beschreibung eines Dryad-Graphen Generierung neuer Knoten Hinzufügen neuer Kanten Zusammenführung zweier Graphen Channel Typen Job Inputs und Outputs Job-Stadien Erstellung eines Vertex-Programms Ausführung des Jobs Fehlertoleranzstrategie Optimierung zur Laufzeit Experimentelle Beurteilung verwendete Hardware SQL-Abfrage Experiment Data Mining Experiment Zusammenfassung des Optimierungsprozesses Auf Dryad basierend Die Skriptsprache Nebula Integration mit SQL Server Integration Services (SSIS) Verteilte SQL-Abfragen Dryad vs. MapReduce Literaturverzeichnis... 18

68 Einführung ins Thema 1 1 EINFÜHRUNG INS THEMA Das Thema Cloud Computing ist heutzutage in aller Munde. Es beschreibt die Verwendung einer Technologie, welche große Berechnungen auf mehreren Computern in einem Netzwerk verteilt. Der Begriff Cloud beschreibt demnach eine Farm von Computern, die sich zu einem Cluster verbinden, was vergleichbar mit einer Wolke ist. Die verschiedenen Komponenten wie Rechenoder Speicherkapazitäten werden dynamisch im Netzwerk zur Verfügung gestellt. Ein wesentlicher Aspekt des Cloud Computing ist die parallele Berechnung auf mehreren Computern in der Cloud, woraus ein enormer Geschwindigkeitsvorteil entsteht. 1.1 PROBLEMDEFINITION Heutzutage werden Daten vermehrt automatisiert erhoben. Als Beispiel seien hier Log-Dateien, Social Networks, Wetterdaten oder auch Aktienkurse genannt. Da sich immer größere Datenmengen anhäufen, wird es fortwährend schwerer diese auch in vertretbarer Zeit zu verarbeiten oder Analysen darüber zu erstellen. Zwar sind in den letzten Jahren die Speicherkapazitäten von Festplatten enorm angestiegen, jedoch die Zugriffszeiten nicht im gleichen Maße. So betrug das durchschnittliche Volumen von Festplatten im Destkopbereich im Jahr 2000 ca. 40 GB mit Zugriffzeiten von rund 32 MB/s. Für das Auslesen einer solchen Platte wurden demnach knapp 21 Minuten benötigt betrug die Speicherkapazität GB, schon das 25-fache im Vergleich zum Jahr Die Zugriffszeiten betrugen dabei 125 MB/s, was nur ein 4-faches im Vergleich zum Jahr 2000 ist. Für das Auslesen einer solchen Platte würden demnach 135 Minuten benötigt [WIKI]. 1.2 LÖSUNGSANSATZ Um diesem Flaschenhals entgegen zu wirken setzen große Unternehmen wie z.b. Microsoft, Google oder Apache, auf die verteilte parallele Berechnung großer Datenmengen in Clustern. Bei dieser Technologie werden mehrere Recheneinheiten mit eigenen Festplatten zu einem Cluster verbunden. Die Daten werden in kleine Stücke aufgeteilt und verteilt auf dem Computer gespeichert, der die Daten verarbeitet. Durch dieses Verfahren wird eine deutliche Zeiteinsparung bei der Datenverarbeitung und der Zugriffsoperationen erzielt. Da immer mehr parallele Architekturen Verwendung finden, müssen auch parallele Programme geschrieben werden, die mit der Architektur effizient arbeiten können. Das Programmieren solcher Anwendungen ist sehr aufwändig und muss angepasst werden, wenn sich die Laufzeitumgebung ändert. Um diesen Aufwand zu vereinfachen sind zwei Komponenten nötig: ein vereinfachtes Programmiermodell, in dem es möglich ist auf einem hohen Level zu arbeiten (sowie Nebenläufigkeiten und deren Ort zu spezifizieren) und eine effiziente Laufzeitumgebung. Diese muss Low Level Mapping unterstützen, Ressourcen managen und sollte unabhängig vom System und dessen Größe bzw. Größenänderung sein. Diese beiden Komponenten sind dabei eng miteinander verknüpft. Aufgrund dieser Tatsachen und der Komplexität der Parallelprogrammierung kam die Idee auf, eine einfachere Grundlage zu bilden, in der die Organisation der Parallelisierung automatisch vorgenommen wird. In diesem Zusammenhang entwickelte Microsoft das Parallel-Computing-Projekt Dryad. Bill Gates hatte Dryad im Jahr 2006 erstmals gegenüber der New York Times erwähnt. Sonst blieb es still um das Projekt, das sich mit Konzepten für parallele und verteilte Programme beschäftigt,

69 2 Einführung ins Thema die sowohl in kleinen Clustern als auch in riesigen Rechenzentren mit optimaler Leistung ausgeführt werden können [ZDNet]. 1.3 CHARAKTERISTIKUM VON DRYAD Dryad ist Microsofts Antwort auf Techniken wie Google MapReduce oder Apache Hadoop. Am Anfang war Dryad ein Microsoft-Research-Projekt. Die Forscher wollten Methoden entwickeln, um Programme für verteiltes Rechnen zu entwickeln, die sich von kleinen Computerclustern bis zu riesigen Rechenzentren skalieren lassen. Dryad ist eine universelle, verteilte Ausführungsengine für parallele Datenverarbeitungen. Eine Dryad-Anwendung kombiniert Auslastungsspitzen mit Kommunikationskanälen zu einem Datenflussdiagramm. Dryad verteilt die Auslastungsspitzen auf verfügbare Computer, unter Verwendung von Dateien, TCP-Pipes und Shared Memory FiFo s. Der Anwendungsentwickler erstellt normalerweise sequentielle Programme ohne Threads oder Locks. Parallelität ergibt sich bei Dryad durch Verteilung auf mehrere PCs oder mehrere CPU- Kerne innerhalb eines Computers. Die Anwendung kann die Größe und die Platzierung von Daten während der Laufzeit ermitteln, und ändert danach den Graph um alle Ressourcen effizient zu nutzen. Dryad wurde für Multi-Core Einzelplatzrechner, kleine Cluster von Computern und Rechenzentren mit tausenden von Computern entwickelt. Die Dryad-Engine behandelt alle Probleme die bei der Verarbeitung großer, verteilter paralleler Anwendungen auftreten: Scheduling der verfügbaren PCs und deren CPUs, wiederherstellen von Verbindungen oder Computerausfälle und Transport der Daten zwischen den Knoten. Die ersten Versionen der Software wurden im Sommer 2009 an Universitäten für nicht kommerzielle Anwendungen ausgegeben. Erst 2010 hat man Dryad von der Forschungsabteilung in die Technical Computing Group verlegt. Laut einer im August 2010 veröffentlichten Präsentation sollte die Community Technology Preview (CTP) bereits im November erscheinen. Die finale Version für Windows HPC Server wird 2011 auf den Markt kommen. Die aktuelle CTP wendet sich laut Microsoft an Entwickler, die sich mit datenintensiven Anwendungen befassen. Die Systemvoraussetzung für Dryad ist ein Computercluster mit Windows HPC Server 2008 R2 und installiertem Service Pack 1. Zu dem Dryad-Projekt gehören eine Reihe von Komponenten, unter anderem der DryadLINQ- Compiler und die Laufzeitumgebung, sowie ein verteiltes Dateisystem mit dem Codenamen "TidyFS", eine Reihe von Tools zur Datenverwaltung (Codename "Nectar") und ein Steuerprogramm für verteilte Cluster (Codename "Quincy").

70 Systemarchitektur 3 2 SYSTEMARCHITEKTUR Die Gesamtstruktur eines Dryad-Jobs wird durch den Kommunikationsfluss festgelegt. Ein Job ist ein gelenkter azyklischer Graph, wobei jeder Knoten ein Programm und jede Kante einen Datenkanal darstellt. Es ist ein logisches Berechnungsdiagramm, das automatisch auf den physischen Ressourcen abgebildet wird. Im Einzelfall können mehr Knoten im Graph vorhanden sein als CPUs im Cluster. Zur Laufzeit wird ein Kanal benutzt, um eine definierte Sequenz von strukturierten Elementen zu transportieren. Die Implementierung der Kanalabstraktion basiert auf Shared Memory, TCP-Pipes oder temporären Dateien im Filesystem. Ein Vertex-Programm liest und schreibt seine Daten ebenso unabhängig davon, ob ein Kanal seine Daten über einen Puffer auf Disk, TCP-Stream oder direkt in den Shared Memory überträgt. Das Dryad-System verwendet kein primäres Datenmodell für die Abbildung von Objekten. Der Typ eines Elementes wird durch die Anwendung festgelegt, so dass diese ihre eigene Abbildung des Objektes je nach Programm unterstützen kann. Diese Entscheidung erlaubt es Anwendungen zu unterstützen, die direkt auf vorhandenen Daten, einschließlich SQL-Exporttabellen und Textprotokolldateien, funktionieren. In der Praxis verwenden die meisten Anwendungen einen Typ aus einem kleinen Satz Libary-Elementen, die Microsoft als newline-terminated Textstrings und Tupel von Basistypen anbietet. Der Workflow in Abbildung 1 zeigt die Struktur des Dryad Systems. Ein Dryad-Job wird durch einen Jobmanager-Prozess (JM) koordiniert, welcher im Cluster oder auf einem Arbeitsplatz mit Netzwerkzugang ausgeführt wird. Der Jobmanager enthält den anwendungsspezifischen Code, um den Kommunikationsgraph zusammen mit dem Libary-Code zu konstruieren. Er plant, verteilt und überwacht die Aufträge über die verfügbaren Ressourcen. Alle Daten werden direkt zwischen Knoten gesendet, so dass folglich der Jobmanager nur für Steuerentscheidungen verantwortlich ist und somit nicht zum Engpass für Datenübertragungen wird. Abbildung 1 - Struktur des Dryad Systems [IB07 S. 61] Das Cluster hat einen Name-Server (NS) der benutzt werden kann, um alle verfügbaren Computer zu spezifizieren. Der Name-Server registriert auch die Position jedes Computers innerhalb der Netztopologie und berücksichtigt diese bei der Aufgabenverteilung. Auf jedem Computer im Cluster läuft ein Dämon (D), welcher für die Prozesserstellung im Namen des Jobmanagers verantwortlich ist. Wird das erste Mal ein Vertex (V) auf dem Computer

71 4 Systemarchitektur ausgeführt, erhält der Dämon die Anweisung vom Jobmanager geschickt und nachfolgende Prozesse werden aus dem Cache aufgerufen. Der Dämon tritt als ein Proxy auf, so dass es dem Jobmanager möglich ist mit den Prozessen zu kommunizieren und die Prozesse, sowie die gelesenen und geschriebenen Daten zu monitoren. Es ist unkompliziert einen Nameserver und Dämon auf einer Workstation laufen zu lassen, um somit ein Cluster zu simulieren und dadurch die gesamten Jobs von einem Punkt zu aktivieren und zu prüfen. Ein Taskmanager steuert die Batchjobs. Durch ein verteiltes Speichersystem, ähnlich dem Google Filesystem, werden große Dateien in kleinere Elemente geteilt, welche repliziert und verteilt werden. Dryad unterstützt auch die Verwendung von NTFS für das direkte zugreifen auf Dateien am lokalen PC, welches für kleinere Blöcke mit niedrigen Verwaltungskosten von Vorteil sein kann. 2.1 BEISPIEL SQL-ABFRAGE In diesem Abschnitt wird ein konkretes Beispiel für eine Dryad-Anwendung beschrieben, auf die im weiteren Verlauf immer wieder eingegangen wird. Die vom Microsoft Autorenteam gewählte Aufgabenstellung ist repräsentativ für eine Gruppe von escience-anwendungen, bei denen im Rahmen wissenschaftlicher Untersuchungen große Mengen digital vorliegender Daten verarbeitet werden. Die benutzte Datenbank ist abgeleitet aus den Daten von Sloan Digital Sky Survey (SDSS), einem Projekt das eine Karte von einem großen Teil des Universums erstellt. [SDSS] Aus einer Studie wurde einer der zeitintensivsten Fragestellung (Q18) gewählt. Die Aufgabe ist einen Gravitationslinseneffekt zu identifizieren. Es sollen alle Objekte in der Datenbank ermittelt werden, bei denen mindestens eines der benachbarten Objekte im Umkreis von 30 Bogensekunden eine ähnliche Farbe wie das Primärobjekt hat. Die Abfrage kann in SQL wie folgt gestellt werden: select distinct p.objid from photoobjall p join neighbors n - call this join X on p.objid = n.objid and n.objid < n.neighborobjid and p.mode = 1 join photoobjall l - call this join Y on l.objid = n.neighborobjid and l.mode = 1 and abs((p.u-p.g)-(l.u-l.g))<0.05 and abs((p.g-p.r)-(l.g-l.r))<0.05 and abs((p.r-p.i)-(l.r-l.i))<0.05 and abs((p.i-p.z)-(l.i-l.z))<0.05 Durch diese Abfrage wird auf zwei Tabellen zugegriffen. Die erste Tabelle photoobjall hat Einträge, für jedes identifizierte astronomische Objekt einen, gekennzeichnet durch einen eindeutigen Bezeichner objid. Diese Datensätze umfassen auch die Objektfarben als Magnitude (logarithmische Helligkeit) in fünf Bändern: u, g, r, i und z. Die zweite Tabelle neighbors hat Datensätze, einen für jedes Objekt welches innerhalb von 30 Bogensekunden eines anderen Objektes gelegen ist. Die mode Eigenschaften wählen nur Primärobjekte aus. Das < Prädikat eliminiert Verdopplungen, die durch das symmetrische Nachbarschaftsverhältnis verursacht werden. Die Ergebnisse der Joins X und Y sind beziehungsweise Datensätze, und das letztendliche Ergebnis umfasst Datensätze. Die Abfrage greift nur auf einige Spalte der Tabellen zu. Die komplette Tabelle photoobjall besitzt eine Größe von 2 KBytes pro Datensatz. Bei der Ausführung durch den SQL-Server, verwendet die Abfrage einen Index auf den photoobjall Key objid, mit zusätzlichen Spalten

72 Systemarchitektur 5 für mode, u, g, r, i und z, und einen Index auf den neighbors Key objid, mit einer zusätzlichen Spalte neighborobjid. Der SQL-Server liest diese Indexe und lässt den Rest der Daten auf der Disk. In der Microsoft Testdatenbank wurden die nicht benötigten Spalten der Tabellen weg gelassen, um unnötigen Datentransfer im Bereich von Multi-Terrabyte zu vermeiden. Für die gleichwertige Dryad-Berechnung wurden die Indizes in zwei Binärdateien ugriz.bin und neighbors.bin extrahiert, wobei beide mit der gleichen Reihenfolge der Indizes sortiert wurden. Die ugriz.bin -Datei hat 36-Byte Records und somit eine ungefähre Größe von 11,8 GBytes. Die Datei neighbors.bin hat 16-Byte Records, wodurch ihre Größe 41,8 GByte entspricht. Der Output von Join X beträgt 31,3 GBytes, von Join Y 655 KByte und der finale Output umfasst 649 KBytes. Abbildung 2 stellt den Kommunikationsgraph der Abfrage für die Dryad-Berechnung dar. Die beiden Dateien wurden anhand der objid-ranges in ungefähr n-gleichgroße Teile aufgeteilt (welche mit U 1 bis U n und N 1 bis N n benannt sind). Des Weiteren wurden benutzerdefinierte C++ Objekte für jeden Datensatz im Diagramm benutzt. Die Vertexe X i (1 i n) implementieren den Join X, indem die verteilten U i - und N i -Inputs (basierend auf der objid und gefiltert durch den Ausdruck < und p.mode=1) zu Records, welche objid, neighborobjid und die Farbspalten entsprechend der ObjID enthalten, vermischt. Die D Knoten verteilen ihre Output- Datensätze, viermal feiner als die verwendeten Eingangsdateien, auf die M Knoten, über die neighborobjid unter Verwendung einer Range Aufteilungsfunktion. Die Zahl vier wurde gewählt, da jeder Computer über je vier Prozessoren verfügt und somit vier Pipelines parallel ausgeführt werden können. Die M Knoten führen ein nicht-deterministisches Mischen der Inputs durch und die S Knoten sortieren auf Basis der neighborobjid, unter Verwendung eines in-memory Quicksort. Die Ausgabedatensätze von S 4i-3 S 4i (i=1 bis n) werden in Y i zusammengezogen, in dem sie mit den anderen vermischt werden, die von U i gelesen werden, um sie im Join Y zu implementieren. Dieser Join basiert auf der objid von U = neighborobjid von S, wird durch den Rest des Prädikats gefiltert und bringt so die Farben zusammen. Die Outputs der Y Knoten werden in einer Hash- Tabelle am H Knoten vermengt, um das eindeutige Schlüsselwort der Abfrage zu implementieren. Schließlich liefert die Auflistung der Hash-Tabelle das Resultat. Im Verlauf werden weitere Abbildung 2 - Kommunikationsgraph der SQL- Query [IB07 S.62] Einzelheiten über die Implementierung dieses Dryad-Programmes ausgeführt.

73 6 Beschreibung eines Dryad-Graphen 3 BESCHREIBUNG EINES DRYAD-GRAPHEN Dryad wurde entwickelt, um auf möglichst einfache Weise Kommunikationsidiome zu spezifizieren. Es ist aktuell in C++ als Libary eingebettet und verwendet eine Mischung von Methodenaufrufen und Operatoren-Überladung. Die Erstellung von Graphen erfolgt indem einfachere Sub-Graphen, unter Verwendung weniger Operationen miteinander kombiniert werden. Alle Operationen basieren darauf, dass der Ergebnisgraph azyklisch ist. Das Basisobjekt der Sprache ist der Graph: G = V G, E G, I G, O G. G enthält eine Sequenz von Knoten (Vertex) V G, einen Satz direkter Kanten E G und zwei Sätzen I G V G und O G V G ; welche die In- und Outputs darstellen. Die Input- und Output-Kanten eines Knoten werden so geordnet, dass diese einen speziellen Port aus Knoten ergeben und somit ein vorgegebenes Paar von Knoten an mehrere Ränder angeschlossen werden kann. 3.1 GENERIERUNG NEUER KNOTEN Die Dryad-Libary definiert eine C++ Basisklasse, auf welcher alle Programmknoten basieren. Jedes Programm ist durch einen uniquen Namen gekennzeichnet und besitzt eine statische Factory in der die Basis des Programms hinterlegt ist. Durch den Aufruf der passenden statischen Programmfactory wird ein neuer Knoten erstellt. Alle erforderlichen knotenspezifischen Parameter können beim Aufruf der Methode an das Programmobjekt übergeben werden. Diese Parameter werden dann dem uniquen Knotennamen zugeordnet, welche zu einem einfachen Komplex zusammengefasst werden und an den Remoteprozess zur Ausführung gesendet werden. Ein einfacher Graph G wird durch einen Knoten v generiert G= (v), 0, {v}, {v}. Ein Graph kann durch Verwendung des Operators in einen anderen Graphen mit k Kopien geklont werden, wobei C = G k wie folgt definiert ist: Hierbei ist ein Klon von G, welcher Kopien aller Knoten und Kanten enthält ( kennzeichnet die Verkettung). Jeder geklonte Knoten übernimmt die Typen und Parameter des entsprechenden Knotens in G. 3.2 HINZUFÜGEN NEUER KANTEN Neue Kanten werden erstellt, indem man eine Verkettungsoperation auf zwei existierende Graphen anwendet. Alle Teile der Verkettung müssen auf der gleichen Struktur basieren und kreieren durch C=A B einen neuen Graph: C= V A V B, E A E B E new, I A, O B, wobei C die Vereinigung aller Kanten und Knoten von A und B beinhaltet (mit A s Inputs und B s Outputs). Zusätzlich entstehen Ränder von E new aus den Knoten in O A und I B. V A und V B werden zur Laufzeit disjunkt und da A und B beide azyklisch sind, ist es auch C. Beim Erstellen der Kanten E new die zu einem Graph hinzukommen, werden zwei Standards unterschieden. A >= B bildet einen punktweisen Aufbau wie in der nachfolgenden Abbildung 3 im Abschnitt (c) dargestellt ist. Wenn O A I B wird eine einzelne abgehende Kante von

74 Beschreibung eines Dryad-Graphen 7 jedem Output A s erstellt. Die Kanten werden mittels des Round-Robin zu B s Input zugeordnet. Einige der Knoten in I B können mit mehr als einem ankommenden Rand enden. Wenn I B > O A wird eine eingehende Kante zu jedem Input B s erstellt, welche wiederum mittels Round-Robin von A s Output zugewiesen werden. A >> B erstellt einen vollständigen zweiteiligen Graphen zwischen O A und I B (vgl. Abbildung 3, Abschnitt d). Abbildung 3 Operatoren [IB07 S. 63] 3.3 ZUSAMMENFÜHRUNG ZWEIER GRAPHEN Die finale Operation der Sprache ist, wodurch zwei Graphen zusammengeführt werden. C = A B erstellt einen neuen Graphen: C = V A * V B, E A E B, I A * I B, O A * O B, wobei es im Gegensatz zur Komposition nicht erforderlich ist, dass A und B disjunkt sind. V A * V B ist die Zusammenführung von V A und V B, wobei die Duplikate der zweiten Sequenz entfernt werden. I A * I B beschreibt die Vereinigung der Eingänge von A und B. Wenn in einem Knoten V A V B Inputs beinhaltet sind, werden die ausgehenden Kanten so verkettet, dass die Kanten in E A zuerst entstehen (mit niedriger Portnummer). Diese Vereinfachung verhindert Graphen mit Crossover -Kanten. Die Merge-Operation ist extrem leistungsfähig und ermöglicht einfache typische Muster zur Kommunikation zu erstellen (vgl. Abbildung 3, Teil (f)-(h)). Ebenso werden Möglichkeiten geboten, durch eine Kollektion von Knoten und Kanten, einen Graphen selbst zu erstellen. Zum Beispiel kann ein Baum mit vier Knoten a, b, c und d zu G = (a>=b) (b>=c) (b>=d) zusammengestellt werden.

75 8 Beschreibung eines Dryad-Graphen Das Graph-Builder-Programm zur Erstellung des Graphen aus Abbildung 2, ist in der nachfolgenden Abbildung 4 dargestellt. GraphBuilder XSet = modulex^n; GraphBuilder DSet = moduled^n; GraphBuilder MSet = modulem^(n*4); GraphBuilder SSet = modules^(n*4); GraphBuilder YSet = moduley^n; GraphBuilder HSet = moduleh^1; GraphBuilder XInputs = (ugriz1 >= XSet) (neighbor >= XSet); GraphBuilder YInputs = ugriz2 >= YSet; GraphBuilder XToY = XSet >= DSet >> MSet >= SSet; for (i = 0; i < N*4; ++i) { XToY = XToY (SSet.GetVertex(i) >= YSet.GetVertex(i/4)); } GraphBuilder YToH = YSet >= HSet; GraphBuilder HOutputs = HSet >= output; GraphBuilder final = XInputs YInputs XToY YToH HOutputs; Abbildung 4 Beispiel Graph-Builder-Programm [IB07 S. 64] 3.4 CHANNEL TYPEN Standardmäßig wird jeder Kanal so implementiert, dass eine temporäre Datei genutzt wird. Der Producer schreibt typischer Weise auf die lokale Disk und der Consumer liest diese Datei aus. In der Regel schreiben mehrere Knoten auf die lokalen Ressourcen eines Rechners, weshalb es sinnvoll ist, diese innerhalb des gleichen Prozesses auszuführen. Die Sprache verfügt über einen Verkapselungs-Befehl, welcher einen Graph G nimmt und diesen an einen neuen Knoten v G zurückgibt. Wenn v G als Vertex-Programm läuft, bewertet der Jobmanager dies als periodische Ausführung von G mit Anforderungsparametern, und es lässt alle Vertexe von G gleichzeitig innerhalb des gleichen Prozesses verbundenen durch Kanten und unter Verwendung des sharedmemory FIFOs laufen. Da es immer möglich ist, ein eigenes Vertex-Programm mit der gleicher Semantik wie G zu erstellen, ermöglicht die Verkapselung ein effizientes kombinieren einfacher Libary-Knoten auf der Diagrammschicht. Bei der Erstellung der Kanten kann der Entwickler optional spezifizieren welches Transportprotokoll benutzt werden soll. Die unterstützten Protokolle sind File (Standard), TCP- Pipe oder Shared-memory FIFO. Weil der Graph azyklisch ist, ist ein Deadlock unmöglich wenn alle Kanäle entweder in temporäre Dateien schreiben oder den shared-memory FIFO verdeckt und innerhalb der eingekapselten Subgraphen verwenden. Wenn es dem Entwickler möglich ist sichtbare FIFOs zu verwenden, kann dies Deadlocks verursachen.

76 Erstellung eines Vertex-Programms JOB INPUTS UND OUTPUTS Große Datenmengen werden normalerweise geteilt und über die Rechner im Cluster verteilt. Folglich müssen die logischen Eingänge in einem Graph G = V P,,, V P gruppiert werden, wobei V P ein Sequenz virtueller Knoten entsprechend der Partitionen des Inputs darstellt. Analog können zum Jobende die Outputs zu einer logisch verteilten Datei verkettet werden. Im Normalfall wird zur Laufzeit die Anzahl der Teile ermittelt und dazu passend automatisiert der Graph repliziert. 3.6 JOB-STADIEN Bei der Erstellung eines Graphen wird jeder Knoten mit einem definierten Stadium initialisiert, um das Jobmanagement zu vereinfachen. Die Topologie der Stadien kann als Grundgerüst oder Zusammenfassung des Gesamtjobs gesehen werden. Die Topologie der Skyserver-Query- Applikation aus dem Beispiel wird in Abbildung 5 gezeigt. Jeder eindeutige Typ eines Knoten ist in einer separaten Gruppe zusammengefasst. Die meisten Stadien werden durch Verwendung des >= Operators verbunden, während D an M unter Verwendung des >> Operators angeschlossen ist. Bei der Überwachung des Jobs wird dieses Grundgerüst als Guide für die Erzeugung von Zusammenfassungen genutzt. Ebenso kann es für automatisierte Optimierungen genutzt werden, wie sie im Abschnitt 5.2 beschrieben werden. 4 ERSTELLUNG EINES VERTEX-PROGRAMMS Die grundlegenden API s für die Erstellung eines Dryad-Vertex-Programms werden als C++ Basisklassen und Objekte bereitgestellt. Eine Grundanforderung an Dryad war, dass es sich in den allgemeinen Code bzw. Bibliotheken eingliedert und somit dryadspezifische Konstrukte oder Sandboxen vermieden werden. Die meisten existierenden Codebestandteile die in Dryad integriert wurden sind in C++ erstellt. Es ist jedoch unkompliziert API-Wrapper zu implementieren, so dass auch Entwicklungen aus anderen Sprachen eingebunden werden können (z.b. C#). Ebenso kann es erforderlich sein, Programme direkt auszuführen zu können, was ebenfalls unterstützt wird (vgl, Abschnitt 4.2). Dryad verfügt über eine Laufzeitbibliothek, welche für die Ausführung der Knoten während der verteilten Berechnung verantwortlich ist. Wie in Abschnitt 3.1 beschrieben, empfängt die Runtime eine Jobbeschreibung vom Jobmanager, wie der Knoten auszuführen ist. URLs beschreiben die In- und Output-Kanäle, wobei aktuell keine Typprüfung für die Kanäle vorgenommen wird, so dass der Knoten in der Lage sein muss, mittels entsprechender Routinen festzustellen (statisch oder über Anforderungsparameter), welche Typen zum Lesen und Schreiben auf dem Kanal übertragen werden. Der Body des Knoten wird über die Standard-Main-Methode Abbildung 5 - Stadien der Dryad- Berechnung aus Abbildung 2 [IB07 S. 64] aufgerufen, in welcher Channel-Reader und Writer in der Argumentliste enthalten sind. Der Knoten berichtet an den Jobmanager über Status und Fehler. Durch die Prozess-Wrapper-Libary wird die Ausführung mit Parametern unterstützt. Der Wrapper-Vertex ist in der Lage willkürliche Arten von Datentypen zu verarbeiten. Somit sind die Elemente einfache feste Puffer, die unverändert zum Prozess (unter Verwendung einer Pipe)

77 10 Ausführung des Jobs im Dateisystem übertragen werden. Dies ermöglicht es bereits bestehende Binaries als Dryad- Vertex-Programm laufen zu lassen. So ist es zum Beispiel möglich Perlskripte oder Grep im Knoten eines Dryad-Jobs aufzurufen. Die meisten Dryad Knoten enthalten einen sequentiellen Code. Es wird jedoch auch ein ereignisbasierter Programmierstil, durch Verwendung eines geteilten Threadpools unterstützt. Zur Laufzeit wird automatisch unterschieden, welche Knoten den Threadpool nutzen können, und welche einen separaten Thread und folglich einen gekapselten Graphen benötigen. Die Implementierung der Kanäle ermöglicht Lesen, Schreiben, Serialisierung und Deserialisierung der Tasks auf einem geteilten Threadpool. Durch die Abstraktion von Lese- und Schreibphasen wird zur Laufzeit versucht, dem Entwickler leistungsfähige Kanäle bereitzustellen. Die Experimente in Abschnitt 6.2 bestätigen die Leistungsfähigkeit dieser Abstraktion. Sogar einzelne Dryad-Knoten-Applikationen haben Durchsätze vergleichbar mit kommerziellen Datenbanksystemen. 5 AUSFÜHRUNG DES JOBS Der Scheduler des Jobmanager überwacht alle aktuellen und vergangenen Zustände eines jeden Vertex im Graph. Durch Checkpoints oder Reproduktion können Ausfälle von Computern kompensiert werden. Ein Vertex kann mehrmals über die Laufzeit des Jobs ausgeführt werden. Jede Ausführung eines Vertex hat eine Versionsnummer und einen entsprechenden Ausführungsdatensatz, welcher den Zustand der Ausführung und die Version des Vorgängerknoten enthält. Jede Ausführung benennt seine dateibasierten Outputkanäle eindeutig durch Benutzung der Versionsnummer und vermeidet somit Konflikte unter den Versionen. Wenn der gesamte Job erfolgreich abgeschlossen ist, wählt jeder Vertex eine erfolgreiche Ausführung und benennt diesen Output in den korrekten Dateinamen um. Wenn alle Vertex-Inputkanäle den Status bereit haben, wird ein neuer Ausführungsdatensatz für den Vertex erstellt und in die Queue gelegt. Ein plattenbasierter Kanal wird als bereit angesehen, wenn die gesamte Datei gelesen wurde. Ein Kanal welcher eine TCP-Pipe oder shared-memory FIFO ist wird als bereit angesehen, wenn der vorhergehende Vertex mindestens einen laufenden Ausführungsdatensatz hat. Ein Vertex und jeder seiner Kanäle können jeweils eine Liste von Computern spezifizieren, auf welchen sie laufen möchten. Die Begrenzungen werden kombiniert und an den Ausführungsdatensatz angefügt, wenn dieser zur Scheduler-Queue hinzugefügt wird. Somit sind dem Programmierer hiermit auch Steuerungsmöglichkeiten gegeben. Die Planung des Jobmanagers basiert aktuell auf der Annahme, dass es der einzige Job im Cluster ist. Wenn ein Ausführungsdatensatz mit dem verfügbaren Rechner verbunden wird, weist der Remotedämon den spezifizierten Vertex an und während der Ausführung empfängt der Jobmanager periodisch Statusupdates vom Vertex. Wenn jeder Vertex abgeschlossen ist, gilt auch der Job als erfolgreich abgeschlossen. Wurde ein Vertex öfter angestoßen, als per Definition vorgegeben, gilt die Jobausführung als fehlgeschlagen.

78 Ausführung des Jobs 11 Dateien die temporäre Kanäle darstellen werden in Verzeichnissen gespeichert, die vom Dämon gemanagt und aufgeräumt werden, wenn der Job abgeschlossen ist. Ebenso werden Vertices durch den Dämon gekillt, wenn der Parent -Jobmanager abstürzt. Mittels einer einfachen Graph-Visualisierer-Suite für kleine Jobs kann der Status jedes Vertex und die Menge der Daten dargestellt werden, während die Berechnung weiter läuft. Eine webbasierte Schnittstelle zeigt regelmäßig aktualisierte zusammenfassende Statistiken eines laufenden Jobs an und kann dazu benutzt werden um große Berechnungen zu überwachen. Die Statistik beinhaltet die Anzahl der Knoten, welche beendet oder neu ausgeführt wurden, die Anzahl des Datentransfers über die Kanäle und die Fehler-Codes. Über Links ist es dem Programmierer möglich von einer Übersichtsseite aus, die Log-Dateien zu lesen oder einen Crash Dump zur Fehlerdiagnose herunterzuladen. Dieser ist mit einem Index gekennzeichnet, der es erlaubt den Vertex neu und isoliert auf dem lokalen Rechner auszuführen. 5.1 FEHLERTOLERANZSTRATEGIE Fehler können während der Ausführung der verteilten Anwendung zu jedem Zeitpunkt auftreten. Die Ausfallstrategie ist darauf ausgelegt, dass alle Vertex-Programme deterministisch sind. Da der Kommunikationsgraph azyklisch ist, kann man davon ausgehen, dass jede terminierende Ausführung eines Jobs das gleiche Resultat liefert, unabhängig der Reihenfolge der Computeroder Disk-Fehlern. Schlägt die Ausführung eines Vertex fehl, leitet der Dämon dies an den Jobmanager weiter. Für den Fall, dass ein Dämon fehlschlägt, bemerkt der Jobmanager dies über den Heartbeat Timeout. Sollte der Fehler auf einen Lesefehler eines Inputkanals basieren, wird der Datensatz mit der Version des Kanals entsprechend als ausgefallen markiert und der Prozess beendet. Dadurch wird der Vertex der den Fehler erzeugt hat, neu ausgeführt und dann im Anschluss an den beschädigten Kanal übergeben, welcher neu erstellt wurde. Somit hat ein fehlerhafter Ausführungsdatensatz keine nicht-fehlerhaften Nachfolgedatensätze, so dass Fehler nicht weiter propagiert werden müssen. Wie im Abschnitt 3.6 beschrieben, wird jedem Vertex einem Stadium zugeordnet. Jedes Stadium hat ein Managerobjekt, welches Rückinformationen (Callback) wie zum Beispiel Zustandsübergänge eines Vertex in diesem Stadium oder einen Timer-Interrupt empfängt. Innerhalb dieser Callback s hält der Stage-Manager einen globalen Lock auf dem Jobmanager und kann dadurch Reaktionen implementieren. Zum Beispiel kann der Stage-Manager anhand einer Heuristik Knoten identifizieren, die langsamer laufen als andere und im Scheduler die Ausführungen verdoppeln. Dies verhindert, dass ein einzelner langsamer Computer zur Verzögerung des gesamten Jobs führt. 5.2 OPTIMIERUNG ZUR LAUFZEIT Wie im vorhergehenden Abschnitt beschrieben wird der Stage-Manager Callback-Mechanismus benutzt um Laufzeitoptimierungsmaßnahmen zu implementieren. In Abbildung 6 wird ein logischer Graph mit einen Satz von Inputs zu einem Downstream- Vertex zusammengefasst. In der Optimierung wurde dies weiter entwickelt, indem eine neue Schicht interner Knoten eingesetzt wurde. Jeder interne Knoten liest vom Subset, die geschlossen im Netzwerk vorliegen (z. B. auf dem gleichen Computer oder im gleichen Rack). Durch die Abbildung 6 Optimierung (1) [IB07 S. 66]

79 12 Experimentelle Beurteilung Datenreduktion welche die internen Vertices durchführen, kann der Gesamt-Traffic im Netzwerk reduziert werden. Die Implementierung in Dryad erfolgt über einen benutzerspezifischen Stage- Manager. Wenn dieser Manager die Callback Mitteilungen erhält, dass die aufwärts gerichteten Vertices abgeschlossen sind, schreibt er dies in den Graph mit passenden Verfeinerungen. Die Operation in Abbildung 6 kann rekursiv durchgeführt werden. Analog hierzu gibt es eine Operation zur teilweisen Aggregation (vgl. Abbildung 7). Hier wurden die Inputs in k-sets gruppiert. Durch die k-malige Replikation der Knoten wurde es ermöglicht alle Sätze parallel zu verarbeiten. Ein Beispiel für die Anwendung dieser Technik ist im Data-Mining-Experiment in Abschnitt 6.3 beschrieben. Abbildung 7 Optimierung (2) [IB07 S. 66] Ein spezieller Fall der Optimierung kann zum Start durchgeführt werden, um die Größe der Initialschicht eines Graphen festzulegen, so dass z.b. jeder Vertex mehrfache Inputs, jedoch maximal so viele, dass alle auf dem gleichen Computer liegen, erhält. Weil die Inputdaten auf mehrere Computer im Cluster verteilt werden können, ist der Computer, auf welchem der Vertex geplant wurde, generell nicht deterministisch. Außerdem ist die Menge der Daten, die in den Zwischenstadien geschrieben werden, gewöhnlich nicht bekannt, bevor eine Berechnung beginnt. Folglich ist die dynamische Verfeinerung häufig leistungsfähiger als der Versuch einer statischen Gruppierung. Dynamische Verfeinerungen dieser Art betonen die Stärke der Überlagerung eines physischen Graphen mit seinem Skelett. Für viele Anwendungen gibt es äquivalente Klasse von Graphen, mit dem gleichen Aufbau, die das gleiche Ergebnis liefern. 6 EXPERIMENTELLE BEURTEILUNG Dryad kann für eine Vielzahl von Anwendungen wie zum Beispiel relationale Abfragen, largescale Matrixberechnungen oder eine Vielzahl von Textverarbeitungs-Tasks benutzt werden. Im Artikel von Isard (2009, Seite 67) wird die Effizienz von Dryad durch die Verarbeitung von zwei Experimenten überprüft. Das erste Experiment überträgt eine SQL-Abfrage, wie im Abschnitt 2.1 beschrieben, in eine Dryad-Anwendung. Verglichen werden die Performance von Dryad und einem herkömmlichen SQL-Server und die Leistung von Dryad bei der Verteilung des Jobs über verschiedene Anzahlen von Computern. Das zweite Experiment ist eine einfache MapReduce Datamining-Operation, welche in Dryad geschrieben und auf 10,2 TBytes Daten, unter Verwendung eines Clusters von circa Computern, ausgeführt wurde. Es wurden die bekannten Kommunikationsflussgraphen adoptiert, partitionierbare Datensätze hinzugefügt, die geleiteten parallelen Pipelines innerhalb der Prozesse genutzt und Austauschoperationen zur Kommunikation von Teilergebnissen zwischen den Partitionen angewendet. 6.1 VERWENDETE HARDWARE Die SQL-Abfrageexperimente wurden auf einem Cluster von 10 Computern im Labor von Microsoft Research ausgeführt. Die Datamining-Tests liefen auf einem Cluster von rund Computern in einem angeschlossenen Rechenzentrum. Die Laborrechner verfügen über zwei Dual-Core 2 GHz-Opteronprozessoren, 8 GB DRAM (jeweils 2 GB/CPU) und vier Festplatten. Die 400 GByte Western Digital Festplatten (WD40 00 YR-01PLB0 SATA), sind mit einem

80 Experimentelle Beurteilung 13 Silicon Image 3114 PCI SATA Controller (66 MHz, 32-bit) verbunden. Die Netzwerkanbindung ist 1 GBit/s, welche über einen non-blocking Switch erfolgt ist. Einer der Laborrechner wurde zum SQL-Server und seine Daten wurden auf vier separaten 350 GB NTFS Volumes verteilt. Jedes Laufwerk wurde mit dem SQL-Server für eigenes Datenstriping und temporäre Tabellen konfiguriert. Alle anderen Laborcomputer wurden mit je einem 1,4 TByte NTFS-Volumes, durch Softwarestriping über die 4 Laufwerke eingerichtet. Die Computer im Rechenzentrum haben verschiedene Konfigurationen, sind aber ungefähr vergleichbar mit der Ausstattung der Laborrechner. Alle Computer liefen unter Windows Server 2003 Enterprise x64 Edition mit SP SQL-ABFRAGE EXPERIMENT Die Abfrage für dieses Experiment ist in Abschnitt 2.1 beschrieben und benutzt den Dryad Kommunikationsgraph aus Abbildung 2. Die Ausführungsmethode für den SQL-Server 2005 war ähnlich der Dryad-Berechnung, außer das ein externer Hash-Join für Y, anstatt des Sort- Merge, welches für Dryad benutzt wurde, verwendet worden ist. Der SQL-Server benötigte geringfügig länger, als wenn für den Abfragetyp der Sort-Merge-Join erzwungen worden wäre. Für das Experiment wurden zwei Varianten des Dryad-Graphen benutzt: in-memory und twopass. In beiden Varianten ist die Kommunikation von M i zu dem dazugehörigen S i nach Y durch einen shared-memory FIFO erfolgt. Dieser zog vier Sorter in den gleichen Prozess, um diese parallel auf den vier CPUs in jedem Computer auszuführen. Nur in der in-memory - Variante erfolgte die Kommunikation von D i zu den vier korrespondieren M j Vertices, auch durch einen shared-memory FIFO und für die anderen Kanten von D i M k wurden TCP Pipes benutzt. Die gesamte weitere Kommunikation erfolgte in beiden Varianten durch temporäre NTFS-Dateien. Die gute räumliche Lokalität in der Abfrage verbessert die Anzahl der Partitionen (n) entscheidend. Für n=40 ergibt sich ein Durchschnitt von 80% von D i Ausgaben, was einhergeht mit M i, dies erhöht sich auf 88% für n=6. In anderen Varianten musste n groß genug sein, dass jede Sort-Ausführung durch einen Vertex S i in den 8 GB DRAM des Computers passte. Mit den gegenwärtigen Daten ist die Schwelle bei n=6. Zu beachten ist, dass ein nicht-deterministisches Merge in M, zufällige Vertauschungen der Ausgänge erzeugen kann, abhängig von der Reihenfolge der Eingänge auf dem Inputkanal. Dies verletzt die Anforderung, dass alle Knoten deterministisch sind. Dadurch ergeben sich jedoch keine Probleme für das Modell der Fehlertoleranz, weil Sort S i diese Veränderung undoes und da die Kante von M i zu S i ein shared-memory FIFO in einem einzelnen Prozess ist, fallen die zwei Vertex (wenn überhaupt) gleichzeitig aus und der Nicht-determinismus wird niemals escapen. Die in-memory Variante erfordert mindestens n Computer, weil andernfalls die S-Vertices auf die Daten vom X-Vertex warten und es zum Deadlock kommt. Die two-pass -Variante läuft auf einer beliebigen Anzahl von Computern. Ein Möglichkeit um diesen Zielkonflikt zu vermeiden ist das Hinzufügen der Dateipufferung in der two-pass -Variante. Dadurch verwandelt sich die Anwendung in eine Art zweiten Durchlauf. Zu beachten ist, dass die Umwandlung der inmemory - in die two-pass -Variante, einfach zwei Linien im Graph Konstruktionscode ändert, ohne Änderungen in den Vertex Programmen. Die two-pass -Variante wurde unter Verwendung von n=40 ausgeführt und die Anzahl der Computer wurde zwischen eins bis neun variiert. Bei der in-memory -Variante wurde n=6 bis einschließlich n=9 auf n Computern verwendet. Zum Vergleich wurde die Abfrage auf einem gut optimierten SQL-Server laufen gelassen. Computer SQL-Server 3780 Two-pass In-memory Tabelle 1: Zeit in Sekunden zur Verarbeitung der SQL-Abfrage, bei Verwendung von n Computern [IB07 S. 67]

81 14 Experimentelle Beurteilung Die Tabelle zeigt die benötigte Zeit in Sekunden für jedes Experiment. Bei den wiederholten Durchläufen waren die durchschnittlichen Abweichungen bei 3,4%, ausgenommen der Einzelcomputer bei dem die two-pass -Variante bei 9,4% war. Abbildung 8 stellt diese Zeiten invers grafisch dar, normalisiert um den Beschleunigungsfaktor im Verhältnis zum two-pass -Einzelrechnerfall. Der two-pass -Dryadjob arbeitet auf allen Clustergrößen, mit einer linearen Beschleunigung. Die in-memory Variante arbeitet wie erwartet für n=6 und mehr, ebenfalls mit einer linearen Beschleunigung, aber ungefähr doppelt so schnell wie die two-pass - Variante. Der SQL-Server bestätigt die Erwartungen. Das spezialisierte Dryad Programm läuft signifikant schneller als die SQL-Server-Queryengine. Zu beachten ist, das Dryad eine einfache Ausführungsmaschine liefert, wohingegen die Datenbank viel mehr Funktionen (Logging, Transaktionen und mutierbare Relationen) liefert. 6.3 DATA MINING EXPERIMENT Das Datenerhebungsexperiment lehnt sich an das Muster von Map und Reduce an. Der Zweck dieses Experimentes ist zu prüfen, ob Dryad bei großen Datenmengen leistungsstark gut genug arbeitet. Dieses Experiment liest die Logdateien, die durch den MSN Suchservice erstellt werden ein, extrahiert den Abfragestring und errichtet ein Histogramm der Abfragesequenz. Der allgemeine Berechnungsgraph ist in Abbildung 9 dargestellt. Die Logdateien sind repliziert über die Festplatten verteilt. Jeder der P Graphen liest seinen Part der Logdateien ein und analysiert diesen, um den Abfragestring zu extrahieren. Daraus folgende Einzelteile sind Libary-Tupel, welche den Abfragestring, einen Count und einen Hash des Strings enthalten. Jeder D-Vertex verteilt auf k, basierend auf dem Abfragestring-Hash, Outputs. S führt ein inmemory Sort durch. C fasst die Counts für jede Query zusammen und MS führt ein streaming merge-sort durch. S und MS kommen von einer Abbildung 8 Beschleunigungsfaktoren [IB07 S. 68] Abbildung 9 Graph Data Mining Experiment [IB07 S. 69] Vertex-Bibliothek und nehmen eine Vergleichsfunktion als Parameter. In diesem Fall sortieren sie, basiert auf dem Abfrage-Hash. Einfache Knoten wurden in Subgraphen gekapselt (in der Abbildung 9 durch Rechtecke dargestellt) und damit die Gesamtzahl der Knoten im Job reduziert. Wie der Graph in Abbildung 9 zeigt, ist dieser nicht gut für große Datenmengen skalierbar. Es ist kostspielig einen eigenen Q-Vertex für jeden Input durchzuführen. Jeder Teil umfasst nur ca. 100 MBytes, und der P Vertex führt eine erhebliche Datenverdichtung durch, so dass die Menge der Daten, welche durch die S Vertices sortiert werden müssen erheblich geringer ist, als RAM auf dem Computer. Auch hat jeder Sub-Graph R n Inputs und wenn n auf 100 oder ansteigt, wird es schwierig in so vielen Kanälen gleichzeitig zu lesen. Nachdem Microsoft einige unterschiedliche Verkapselungen und dynamische Verfeinerungsentwürfe versucht hatte, kam man zum Kommunikationsgraph wie er in Abbildung 10 dargestellt ist. Jeder Sub-Graph hat jetzt in der ersten Phase mehrfache Eingänge, welche automatisch durch die Verfeinerung in Abbildung 7 gruppiert werden um sicherzustellen, dass alle auf dem gleichen Computer liegen. Die Eingänge werden über den Parser P zu einem

82 Experimentelle Beurteilung 15 nicht-deterministischen Merge-Vertex M geschickt. Die Verteilung (Vertex D) ist aus der ersten Phase herausgenommen worden, um einer anderen Schicht die Gruppierung und Anhäufung zu erlauben (wieder unter Verwendung der Verfeinerung in Abbildung 7), bevor die Anzahl der Output-Kanäle explodiert. Dieses Experiment wurde in einem Rechenzentrum auf Cluster mit Computern und mit Bytes Inputdaten durchgeführt. Der Input wurde in Elemente unterteilt und über die Computer verteilt. Es wurde spezifiziert, dass die Applikation 450 R Sub-Graphen benutzen soll. In der ersten Phase wurden Gruppen von max. 1 GB Inputs erstellt, die alle auf dem gleichen Computer liegen, was im Ergebnis zu Q' Sub-Graphen führt, die insgesamt Bytes schreiben. Die Ausgänge der Q' Sub-Graphen wurden in höchstens 600 MB große Elemente auf dem gleichen Switch gruppiert, was zu 217 T Subgraphen führte. Jedes T war mit jedem R Subgraph verbunden und diese schrieben Byte. Die gesamte Ausgabe der R Subgraphen war Bytes und die Gesamtlaufzeit betrug 11 Minuten und 30 Sekunden. Für dieses Experiment wurden nur Vertices benutzt. Vergleichbare Experimente mit anderen Diagramm-Topologien bestätigten, dass Dryad erfolgreich Jobs mit mehreren tausend Knoten ausführen kann ZUSAMMENFASSUNG DES OPTIMIERUNGSPROZESSES An keinem Punkt während der Optimierung wurde der Code, der innerhalb der Vertices läuft, abgeändert. Modifiziert wurde nur der Kommunikationsflussgraph des Jobs. Der Kommunikationsgraph ist zu jeder möglichen Map-Reduce Berechnung mit ähnlichen Eigenschaften angepasst: z.b. dass die Map-Phase (P-Vertex) erhebliche Datenverdichtung durchführt und die Reduce-Phase (C Vertex) führt zusätzlich eine etwas kleinere Datenverdichtung durch. Eine andere Topologie könnte bessere Leistung für den Map-Reduce-Task mit anderem Verhalten geben; zum Beispiel wenn die Reduce- Phase durchgeführt ist, kann durch die erhebliche Datenverdichtung ein dynamischer Baum wie in Abbildung 6 idealer sein. Eine Erweiterung der Skalierung oder eine Änderung der Topologie (z.b. indem mehr Schichten zwischen T und R eingeführt werden), ist durch Restrukturierung einfach umzusetzen. Eine gute Performance für große Datenverarbeitungsberechnungen zu erzielen ist nicht einfach. Viele neue Eigenschaften im Dryad-System, einschließlich der Subgraph- Kapselung und der dynamischen Verfeinerung wurden dazu benutzt. Diese machen es einfach mit verschiedenen Optimierungsschemen zu experimentieren. Unter Verwendungen eines einfachen Systems wäre die Verwendung schwierig bzw. unmöglich gewesen. Abbildung 10 Optimierungsprozess [IB07 S. 69]

83 16 Auf Dryad basierend 7 AUF DRYAD BASIEREND Wie in der Einleitung ausgeführt, ist Dryad auf Entwickler, die Erfahrung im Umgang mit höheren Programmiersprachen besitzen, ausgerichtet. In einigen Bereichen ist es von Vorteil, wenn man große Datenverarbeitungsaufgaben einfacher abbildet, da dies auch den Nicht- Entwicklern erlaubt den Datenspeicher direkt abzufragen. Microsoft hat mit Dryad eine Plattform geschaffen, auf welcher es sehr viele Einschränkungen gibt, gleichzeitig aber einfache Schnittstellen und zum anderen wurden innerhalb von Microsoft bereits Systeme entwickelt. 7.1 DIE SKRIPTSPRACHE NEBULA NEBULA ist ein Skriptinterface, welches Dryad überlagert. Es erlaubt dem Anwender eine Berechnung als Serie von Stadien zu spezifizieren (analog zu den Dryad-Stadien), wobei jedes Stadium einen oder mehrere Inputs des vorherigen Stadiums aufnimmt. Mittels des Nebula- Frontends ist es dem User möglich einen Job zu beschreiben. Diese Jobbeschreibung wird in ein Nebula-Skript umgewandelt und unter Verwendung von Dryad ausgeführt. Nebula wandelt Dryad in einen verallgemeinerten Unix Pipelinemechanismus und erlaubt dem Programmierer riesige azyklische Graphen über mehrere Computer zu spannen. Der Nebula-Layer in Kombination mit einer Perl-Wrapper-Funktion ist sehr effektiv für die Verarbeitung großer Textmengen. Die Skripte laufen gewöhnlich auf tausenden von Computern und enthalten 5-15 Stadien, einschließlich mehrfacher Projektionen, Aggregationen und Joins. Nebula verbirgt die meisten Details des Dryad-Programms vor dem Entwickler. Die Stadien werden mit den vorhergehenden Stadien durch Operatoren verbunden, die implizit die Anzahl der erforderlichen Knoten bestimmen. Bei der Implementierung der Nebula-Operatoren werden dynamische Optimierungen benutzt, wie sie im Abschnitt 5.2 beschrieben sind. Durch die Abstraktion der Operatoren, ist es nicht notwendig, dass der Entwickler Details dieser Optimierungen kennt. Alle Nebula-Knoten führen einen Prozess-Wrapper aus, wie er in Abschnitt 4 beschrieben ist. 7.2 INTEGRATION MIT SQL SERVER INTEGRATION SERVICES (SSIS) SSIS ist der Nachfolger der Data Transformation Services (DTS) und unterstützt die Workflowbasierte Anwendungsprogrammierung auf einem Single-Instanz SQL-Server. Das AdCenter-Team in MSN hat ein System entwickelt, welches mit Unterstützung von Dryad lokale SSIS-Berechnungen in größere verteilte Kommunikationsgraphen, Scheduling und Fehlertoleranz einbettet. Der SSIS Eingangsgraph kann auf einem Einzelplatzrechner, unter Verwendung der vollständigen Verfügbarkeit der SQL-Entwicklerwerkzeuge erstellt und getestet werden. Dies schließt einen graphischen Editor zur Erstellung der Jobtopologie und einem integrierten Debugger ein. Wenn der Graph bereit ist, um auf einem größeren Cluster zu laufen, verteilt ihn das System automatisch unter Verwendung einer Heuristik und errichtet ein Dryad- Diagramm, das dann in verteilter Form ausgeführt wird. Jeder Dryad Vertex ist eine Instanz des SQL-Servers, der als SSIS Subgraph des kompletten Jobs läuft. Dieses System wird aktuell in einem Produktivsystem als ein Teil von AdCenters Log-Verarbeitungspipelines entwickelt. 7.3 VERTEILTE SQL-ABFRAGEN Eine zusätzliche Möglichkeit ist den Abfrageoptimierer für SQL oder LINQ anzupassen, damit Pläne direkt in das Dryad-Flussdiagramm, unter Verwendung der passenden parametrisierten Vertices für relationale Operationen, kompiliert werden könnten. Da das Fehlertoleranzmodell nur erfordert, dass Inputs über die Dauer der Abfrage unabänderlich sein müssen, würde jedes

84 Dryad vs. MapReduce 17 darunterliegende Speichersystem, welches Snapshots anbietet, erlauben gleichbleibende Abfrageergebnisse zu liefern. Dieses Themengebiet wird von Microsoft in der Zukunft weiter betrachtet. 8 DRYAD VS. MAPREDUCE Dryad wurde hauptsächlich für große Datenerhebungen und Auswertungen über Cluster von tausenden Computern entworfen. Infolgedessen, teilt es sehr viele Ähnlichkeiten mit Google s MapReduce, welches ein vergleichbares Problemgebiet adressiert. Der grundlegende Unterschied zwischen den beiden Systemen ist, dass Dryad die DAG-Kommunikation (directed acyclic graph) eher spezifizieren kann, als die erforderliche Reihenfolge der Sequenz Map Verteilen Sort Reduce Operationen. Insbesondere können Knoten mehrfache Eingänge von verschiedenen Typen besitzen und auch mehrfache Ausgänge von verschiedenen Typen erzeugen. Für viele Anwendungen vereinfacht dies das Mapping vom Algorithmus zur Implementierung. Dadurch lassen sich größere Bibliotheken der zugrundeliegenden Subroutinen erstellen und zusammen mit der Möglichkeit TCP Pipes und shared-memory für Kanten ausnutzen. Dadurch kann man erhebliche Leistungsgewinne erzielen. Gleichzeitig ist die Implementierung allgemein genug, um alle Eigenschaften zu unterstützen die MapReduce ermöglicht.

85 18 Literaturverzeichnis LITERATURVERZEICHNIS [IB07] [WIKI] ISARD, M.; BUDIU M.: Dryad: Distributed Data-Parallel Programs from Sequential Building Blocks. In EuroSys 07, März 2007, Lissabon, Portugal, S Wikipedia: Festplattenlaufwerk, Abrufdatum: [ZDNet] ZDNet.de: Microsofts Parallel-Computing-Plattform Dryad erscheint 2011, mputing_plattform_dryad_erscheint_2011_story htm, Abrufdatum: [SDSS] Sloan Digital Sky Survey / SkyServer, Abrufdatum:

86 Oliver Kring, Thema 7: DryadLINQ 1/25 FernUniversität in Hagen Seminar im Sommersemenster 2011 MapReduce und Datenbanken Thema 7 DryadLINQ Referent: Oliver Kring

87 Oliver Kring, Thema 7: DryadLINQ 2/25 Inhaltsverzeichnis 1 Überblick und Motivation Einführung in LINQ Was ist LINQ? Ein einfaches Beispiel Delegaten und Lambda-Ausdrücke Die Schnittstelle IEnumerable Die Schnittstelle IQueryable Weitere Beispiele Einführung in DryadLINQ Was ist DryadLINQ? Aufgaben von DryadLINQ Abarbeitung von Queries Datenpartitionierung Die DryadLINQ-API Die Klasse PartitionedTable LINQ-Operatoren DryadLINQ-Operatoren DryadLINQ-Attribute Einschränkungen unter DryadLINQ Weitere Beispiele in DryadLINQ MapReduce Aggregatfunktionen Joins Optimierung von Anfragen durch DryadLINQ Statische Optimierungen Dynamische Optimierungen Optimierungen für OrderBy Optimierungen für MapReduce Zusammenfassung und Ausblick Abbildungsverzeichnis Literaturverzeichnis...25

88 Oliver Kring, Thema 7: DryadLINQ 3/25 1 Überblick und Motivation Die Antwort des Branchenriesen Microsoft auf Googles MapReduce -Framework [1] lautet Dryad. Wie bereits im vorangegangenen Vortrag berichtet, stellt Dryad eine Laufzeitumgebung bereit, welche komplexe Datenbankabfragen in Clustern effizient ausführen kann. Steht eine solche Laufzeitumgebung erst einmal zur Verfügung stellt sich jedoch noch die Frage, wie Abfragen formuliert werden können, so dass die Laufzeitumgebung diese Abfragen versteht und effektiv in der verteilten Dryad -Umgebung abwickeln kann. Eine von Microsofts Antworten auf diese Frage lautet DryadLINQ. Diese Abfragesprache ermöglicht Applikationsentwicklern basierend auf der im.net-framework integrierten LINQ - Syntax, Abfragen in einer beliebigen.net-sprache zu erstellen und wie gewohnt auszuführen. Kenntnisse über die zugrundeliegende Laufzeitumgebung werden dabei zunächst nicht benötigt. Im Folgenden soll die Abfragesprache DryadLINQ vorgestellt und die zugrundeliegenden Konzepte genauer beleuchtet werden. Dazu jedoch müssen zunächst die notwendigen Grundlagen von LINQ erarbeitet werden, einer in die.net-sprachen eingebettete Abfragesprache mit eigener Syntax zur Formulierung allgemeiner Abfrageprobleme.

89 Oliver Kring, Thema 7: DryadLINQ 4/25 2 Einführung in LINQ 2.1 Was ist LINQ? Die imperativen Programmiersprachen stellen keine besonderen Konstrukte zur Verfügung, um Abfragen auf Datensätzen zu formulieren. Solche Abfragen werden in den objektorientierten Sprachen im Allgemeinen dadurch realisiert, dass z.b. über Collections iteriert wird und dabei die Elemente mit den gewünschten Eigenschaften herausgefiltert werden. Möchte man Abfragen auf relationalen Datenbanken durchführen, so werden häufig SQL-Anweisungen in Form von Strings im Programm codiert oder in Konfigurationsdateien hinterlegt und dann während der Laufzeit ausgeführt. Liegen die Informationen in Dateiform vor, so müssen diese Dateien zunächst geparst und die Informationen in geeigneter Weise weiterverarbeitet werden. Die Nachteile dieser Verfahren liegen auf der Hand: Erweiterbarkeit und Wartbarkeit (z.b. bei Änderung der Datenquelle), mangelhafte Typsicherheit, Überprüfung des Abfrage-Codes häufig erst zur Laufzeit möglich, keine Compiler-Optimierungen, Abfragen werden häufig unübersichtlich oder sind nicht intuitiv formuliert. Um diese Probleme zu vermeiden, hat Microsoft ab dem.net-framework 3.5 die LINQ-Syntax eingebettet. Die Abkürzung LINQ steht dabei für Language Integrated Query. LINQ hat dabei folgende Eigenschaften: Der Code ist stark typisiert, der Code wird vom Compiler geprüft, nicht erst zur Laufzeit, die Syntax ist vergleichsweise intuitiv und dabei an SQL angelehnt, ein Providermodell erlaubt die Anbindung verschiedener Datenquellen (z.b. Collections, SQL-Datenbanken, XML-Dateien), der anbietende Provider kann den Abfragecode optimieren. In Folgenden sollen die Grundzüge von LINQ an einigen Beispielen erarbeitet werden. Die Beispiele stammen von [4], [6] und [7].

90 Oliver Kring, Thema 7: DryadLINQ 5/ Ein einfaches Beispiel Im folgenden LINQ-Beispiel werden alle Produkte aufgelistet, deren Name mit einem A beginnt und nach ihrer ID sortiert: var query = from p in products where p.name.startswith("a") orderby p.id select p; Die hier vorgestellte LINQ Query-Syntax ist stark an SQL angelehnt. Obwohl sie in der Literatur für gewöhnlich zuerst vorgestellt wird, bietet sie nicht den vollen Funktionsumfang von LINQ. Dieser kommt erst durch die Verwendung von Erweiterungsmethoden mit Lambda- Ausdrücken voll zur Geltung. Das obige Beispiel kann unter Verwendung von Erweiterungsmethoden wie folgt umgeschrieben werden: var query = products.where(p => p.name.startswith("a")).orderby(p => p.id); Zu nennen ist im Zusammenhang mit LINQ das Konzept der späten Ausführung. Eine LINQ- Abfrage wird nicht ausgeführt, wenn sie formuliert wird, sondern erst dann, wenn im darauf folgenden Code (z.b. in einer for -Schleife) auf die Ergebnisse der Abfrage zugegriffen wird. 2.3 Delegaten und Lambda-Ausdrücke Ähnlich wie in C lässt sich auch in.net eine Funktion referenzieren. Ein Delegat ist dabei ein Objekt, welches eine Referenz auf eine Funktion enthält [5][6]. Zusätzlich besitzt der Delegat in Form seines (generischen) Typs Informationen über die Signatur der Funktion, so dass die Typprüfung des Compilers erhalten werden kann. Mittels eines Delegaten lassen sich also Referenzen auf Funktionen typsicher zwischen verschiedenen Objekten übergeben.

91 Oliver Kring, Thema 7: DryadLINQ 6/25 Beispiel: public static void Main() { // Instantiate delegate to reference ExtractWords method Func<string, int, string[]> extractmethod = ExtractWords; string title = "The Scarlet Letter"; } // Display result foreach (string word in extractmethod(title, 5)) Console.WriteLine(word); private static string[] ExtractWords(string phrase, int limit) {... } Die Variable extractmethod enthält also den Delegaten der Methode ExtractWords vom Typ Func<string, int, string[]>. Der Delegat repräsentiert damit die Methode ExtractWords mit 2 Eingabe-Parametern (vom Typ string und int ) und dem Ausgabe-Parameter (vom Typ string[] ). Bei einem Lambda-Ausdruck handelt es sich um eine anonyme Funktion, die Ausdrücke und Anweisungen enthalten und für die Erstellung von Delegaten oder Ausdrucksbaumstrukturen verwendet werden kann. [6]. Ein Lambda-Ausdruck wird dabei durch die Verwendung des Lambda-Operators => gekennzeichnet. Im Beispiel aus Kapitel 2.2 werden an zwei Stellen Lambda-Ausdrücke verwendet: p => p.name.startswith("a") : Ein Produkt p wird abgebildet auf einen bool'schen Ausdruck p => p.id : Ein Produkt p wird abgebildet auf seine ID In beiden Fällen wird durch den Lambda-Ausdruck eine anonyme Funktion definiert, die auch einem Delegaten zugewiesen werden kann: Func<int, bool> myfunc = x => x == 5; bool result = myfunc(4); // returns false of course Lambda-Ausdrücke unterliegen ebenfalls einer starken Typprüfung durch den Compiler.

92 Oliver Kring, Thema 7: DryadLINQ 7/ Die Schnittstelle IEnumerable Die Abfragesprache LINQ wird in der Schnittstelle IEnumerable bereitgestellt. Sie stellt eine Iterator-Schnittstelle dar, durch die z.b. die Elemente einer Collection durchlaufen werden können. IEnumerable wird von allen.net-collections implementiert, aber auch von Datencontainern, die aus anderen Datenquellen stammen (so z.b Table<T>, welches eine SQL-Datenbanktabelle repräsentiert). Die folgende Übersicht gibt einen Überblick über den bereitgestellten Funktionsumfang (vgl. [6],[9]): c l a s s L I N Q I n t e r f a c e s «i n t e r f a c e» I E n u m b e r a b l e < T > + A g g r e g a t e ( ) + A l l ( ) + A n y ( ) + A v e r a g e ( ) + C o n t a i n s ( ) + C o u n t ( ) + D i s t i n c t ( ) + E x c e p t ( ) + F i r s t ( ) + F i r s t O r D e f a u l t ( ) + G r o u p B y ( ) + G r o u p J o i n ( ) + I n t e r s e c t ( ) + J o i n ( ) + L a s t ( ) + L a s t O r D e f a u l t ( ) + L o n g C o u n t ( ) + M a x ( ) + M i n ( ) + O r d e r B y ( ) + O r d e r B y D e s c e n d i n g ( ) + R e v e r s e ( ) + S e l e c t ( ) + S e l e c t M a n y ( ) + S e q u e n c e E q u a l ( ) + S i n g l e ( ) + S i n g l e O r D e f a u l t ( ) + S k i p ( ) + S k i p W h i l e ( ) + S u m ( ) + T a k e ( ) + T a k e W h i l e ( ) + U n i o n ( ) + W h e r e ( ) «i n t e r f a c e» I Q u e r y a b l e < T > Abb. 1: Die Schnittstellen IEnumerable<T> und IQueryable<T>

93 Oliver Kring, Thema 7: DryadLINQ 8/25 Auffallend ist die Ähnlichkeit zur Abfragesprache SQL. Da aber die LINQ-Syntax der starken Typprüfung durch den Compiler unterliegt, soll im Folgenden eine Auswahl an Funktionen, die es auch unter SQL in ähnlicher (aber untypisierter) Form gibt, kurz erläutert werden: Where<TSource>(Func<TSource, Boolean>) - filtert die Elemente des Iterators. Die Elemente des Iterators sind vom Typ TSource. Das Filterkriterium wird durch einen Delegaten von Typ Func<TSource, Boolean> definiert. Select<TSource, TResult>(Func<TSource, TResult>) - Projektion von Daten des Typs TSource auf Daten des Typs TResult. Die Projektionsvorschrift wird durch einen Delegaten von Typ Func<TSource, TResult> definiert. OrderBy<TSource, TKey>(Func<TSource, TKey>) - sortiert die Elemente des Iterators mit Elementen des Typs TSource. Der Sortierschlüssel ist von Typ TKey. Das Sortierkriterium wird durch einen Delegaten von Typ Func<TSource, TKey> definiert. Min<TSource>() - Aggregatfunktionen über einen Iterator vom Typ TSource. Join<TOuter, TInner, TKey, TResult> (IEnumerable <TInner>, Func<TOuter, TKey>, Func<TInner, TKey>, Func<TOuter, TInner, TResult>) - "Join" zwischen zwei Iteratoren. 2.5 Die Schnittstelle IQueryable Im Gegensatz zu IEnumerable, welches einen Iterator repräsentiert, stellt die Schnittstelle IQueryable eine Abfrage dar, die z.b. serialisiert und damit auch an nahezu beliebige Empfänger übergeben werden kann. IQueryable verwendet selbst keine Delegaten, sondern serialisierbare Expressions zur Definition der Abfrage. IQueryable ist aber von IEnumerable abgeleitet und konvertiert Delegaten implizit in Expressions, so dass der Anwender von diesen Konvertierungen nichts bemerkt und wie gewohnt mit LINQ arbeiten kann.

94 Oliver Kring, Thema 7: DryadLINQ 9/ Weitere Beispiele Im Folgenden werden weitere Beispiele dargestellt, wie Abfragen in LINQ formuliert werden können. Diese und viele andere Beispiele finden sich unter [7]. Auswählen der ersten drei Elemente eines Iterators: int[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 }; var first3numbers = numbers.take(3); Überprüft, ob eine Zahl im Array an seiner natürlichen Position steht (Verwendung des indizierten Selects ): int[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 }; var numsinplace = numbers.select((num, index) => new { Num = num, InPlace = (num == index) }); Bestimmung der Anzahl unterschiedlicher Faktoren der Zahl 300 (man beachte die Anlehnung an SQL): int[] factorsof300 = { 2, 2, 3, 5, 5 } int uniquefactors = factorsof300.distinct().count();

95 Oliver Kring, Thema 7: DryadLINQ 10/25 3 Einführung in DryadLINQ LINQ stellt Sprachelemente zur Verfügung, mit deren Hilfe effizient und in relativ intuitiver Form Abfragen auf Datencontainern durchgeführt werden können. Im Zusammenhang mit DryadLINQ stellt sich die Frage, was DryadLINQ überhaupt ist, welche Funktionen es übernimmt und wie es diese ausführt. Diese Fragen sollen in den folgenden Abschnitten beantwortet werden. Die Ausführungen, Beispiele und Abbildungen basieren im Wesentlichen auf den Abhandlungen [2], [3], [8], [9] und [10]. 3.1 Was ist DryadLINQ? DryadLINQ ist ein Compiler, welcher LINQ-Code so übersetzt, dass dieser verteilt auf einem Dryad-CLuster ausgeführt werden kann. DryadLINQ kapselt dabei sämtliche Details der Dryad-Plattform. Der Anwendungsprogrammierer wird dadurch von genauen Kenntnissen über Dryad befreit und somit entlastet. Sein Code bleibt somit transparent für andere Entwickler. DryadLINQ ist ein LINQ-Provider, der Query-Objekte in LINQ-Syntax entgegennimmt, übersetzt, optimiert und verteilt im Dryad-Cluster ausführt. 3.2 Aufgaben von DryadLINQ Für die Ausführung einer Anfrage (Query) in einem Dryad-Cluster muss DryadLINQ die folgenden Aufgaben durchführen: Entgegennahme der Query (IQueryable), Zerlegung der Query in Sub-Queries und Erstellen eines Query-Plans, Generierung des Query-Codes und Compilierung in.net-assembys, die auf dem Cluster verteilt werden können, Erstellen eines Job-Managers, der den Dryad-Graphen erzeugt und die Ausführung des Jobs im Cluster steuert, Rückgabe der Query-Ergebnisse.

96 Oliver Kring, Thema 7: DryadLINQ 11/ Abarbeitung von Queries Die folgende Abbildung verdeutlicht die Abarbeitung von Abfragen durch DryadLINQ: Abb. 2: Architektur von DryadLINQ (Quelle: Microsoft [8]) (1) Eine.NET-Anwendung läuft und erstellt eine LINQ-Abfrage auf einem DryadLINQ- Objekt. (2) Bei Zugriff auf das Ergebnis der Abfrage wird der LINQ-Ausdruck an den DryadLINQ- Compiler übergeben. (3) Der DryadLINQ-Compiler compiliert den LINQ-Audrucksbaum in einen verteilten Ausführungsgraphen. (4) DryadLINQ erstellt einen speziellen Job-Manager auf dem Cluster. (5) Der Job-Manager erzeugt den Dryad-Job. (6) Der Dryad-Job wird im Cluster verteilt ausgeführt. (7) Die Ausgabe-Daten werden geschrieben. (8) Die Kontrolle wird an DryadLINQ zurückgegeben. DryadLINQ liest die Ausgabedaten ein. (9) Die Resultate werden in Form von.net-objekten an die Anwendung zurückgegeben, die diese dann weiter verarbeiten kann.

97 Oliver Kring, Thema 7: DryadLINQ 12/ Datenpartitionierung Eine grundlegende Eigenschaft großer Cluster ist, dass die Daten nicht auf jedem Rechner vorliegen, sondern der Datenbestand in partitionierter Form auf den Rechnern vorzufinden ist. Das folgende Beispiel soll dies verdeutlichen: Gegeben sei folgende Konfiguration: 4 Maschinen - eine Datei, die in 5 Teilen auf die 4 Maschinen aufgeteilt wird. Abb. 3: Partitionierung von Dateien (Quelle: Microsoft [8]) Eine Maschine m0 enthält Metadaten, also Informationen darüber, wie und wo Partitionen des gesamten Datenbestands im Cluster gespeichert sind. Die Maschinen m1 bis m4 enthalten jeweils einen Teil des Datenbestands, z.t. auch redundant zu anderen Maschinen. Auf der vorgenannten Konfiguration wird nun folgende Query erstellt: public static IQueryable<string> Match(string directory, string filename, string tosearch) { string uri = "file://" + directory + "/" + filename); PartitionedTable<LineRecord> table = PartitionedTable.Get<LineRecord>(uri); } return table.select(s => s.line).where(s => s.indexof(tosearch) >= 0);

98 Oliver Kring, Thema 7: DryadLINQ 13/25 Dieser Job wird dann auf vier Maschinen gleichzeitig ausgeführt (Abb. 4). Dank der Klasse PartitionedTable sowie des dahinter liegenden DryadLINQ-Providers merkt das C#- Programm nichts von den partitionierten Daten und arbeitet wie gewohnt auf einem "IEnumerable"-Iterator. Abb. 4: Ausführungsplan (Quelle: Microsoft [8]) Mit DryadLINQ können Daten neu partitioniert werden, d.h. neu auf den Knoten verteilt werden. DryadLINQ untertützt dabei folgende Verfahren: Hash-Partitionierung: Gleichmäßige Aufteilung der Daten auf Partitionen auf Basis der Hash-Werte in einer oder mehrerer Spalten Range-Partitionierung: Gleichmäßige Aufteilung der Daten auf Partitionen auf Basis des Wertebereichs einer oder mehrerer Spalten

99 Oliver Kring, Thema 7: DryadLINQ 14/25 4 Die DryadLINQ-API DryadLINQ erweitert LINQ um Klassen und Datentypen zur Unterstützung der parallelen Ausführung von Abfragen auf Basis der Dryad-Platform. Im Folgenden soll ein kurzer Überblick über diese Klassen und Datentypen gegeben werden. Die Angaben basieren auf den Texten [9] und [10]. 4.1 Die Klasse PartitionedTable Über die Klasse PartitionedTable kann auf persistente Daten, welche verteilt vorliegen, zugegriffen werden. PartitionedTable leitet von IQueryable ab. Somit können Abfragen auf verteilten Daten in der gleichen Weise vorgenommen werden, wie in bekannter Weise unter LINQ auf zusammenhängenden Daten. Im Beispiel in Kapitel 3.4 wurde bereits mit Hilfe dieser Klasse eine Abfrage erstellt. c l a s s D r y a d L I N Q C l a s s e s P a r t i t i o n e d T a b l e < T > «i n t e r f a c e» I E n u m b e r a b l e < T > «i n t e r f a c e» I Q u e r y a b l e < T > + A g g r e g a t e A s Q u e r y ( ) + A l l A s Q u e r y ( ) + A n y A s Q u e r y ( ) + A p p l y ( ) + A v e r a g e A s Q u e r y ( ) + C o n t a i n s A s Q u e r y ( ) + C o u n t A s Q u e r y ( ) + F i r s t A s Q u e r y ( ) + F i r s t O r D e f a u l t A s Q u e r y ( ) + F o r k ( ) + H a s h P a r t i t i o n ( ) + L a s t A s Q u e r y ( ) + L a s t O r D e f a u l t A s Q u e r y ( ) + L o n g C o u n t A s Q u e r y ( ) + M a x A s Q u e r y ( ) + M i n A s Q u e r y ( ) + R a n g e P a r t i t i o n ( ) + S e q u e n c e E q u a l A s Q u e r y ( ) + S i n g l e A s Q u e r y ( ) + S i n g l e O r D e f a u l t A s Q u e r y ( ) + S u m A s Q u e r y ( ) Abb. 5: Die Klasse PartitionedTable<T>

100 Oliver Kring, Thema 7: DryadLINQ 15/ LINQ-Operatoren Die meisten LINQ-Operatoren können unter DryadLINQ in genau derselben Weise weiterverwendet werden, ohne dass Änderungen im Programm vorgenommen werden müssen. Trotzdem gibt es unter DryadLINQ für viele Operatoren eine Alternativimplementierung mit dem Suffix AsQuery (der Max -Operator hat zum Beispiel die Alternativimplementierung MaxAsQuery ). Diese ermöglicht es dem Compiler, Code der erzeugen, welcher effektiver in der verteilten Dryad-Umgebung ausgeführt wird. Dies führt zu zum Teil deutlichen Performanz- Steigerungen. 4.3 DryadLINQ-Operatoren Bestimmte Abfragen können in LINQ nur sehr umständlich formuliert werden, da LINQ die Elemente einer Aufzählung isoliert betrachtet. Des Weiteren werden Operatoren benötigt, die nur in verteilten Umgebungen Sinn ergeben und dort dann zu erheblichen Leistungssteigerungen führen können. DryadLINQ führt daher die folgenden neuen Operatoren ein: Apply : Dieser Operator ähnelt stark dem Select -Operator unter LINQ (Projektion). Anstelle auf einzelne Elemente einer einzigen Collection kann Apply jedoch auf beliebig viele Elemente mehrerer Collections gleichzeitig zugreifen. Dies ermöglicht in effizienter Weise die Programmierung z.b. des Moving-Average über ein Werte- Fenster. Fork : Fork stellt gewissermassen die Umkehrung von Apply dar. Es transformiert eine Eingabe-Collection in mehrere Ausgabe-Collections. Dabei besteht ebenfalls Zugriff auf beliebige Werte der Collections gleichzeitig. Partitionier-Operatoren: Normalerweise kümmert sich DryadLINQ selbständig um die Datenpartitionierung. Möchte der Entwickler aber explizit eine Datenpartitionierung vorschreiben, so stehen die Partitionier-Operatoren HashPartition<T, K> und RangePartition<T, K> zur Verfügung. 4.4 DryadLINQ-Attribute DryadLINQ erzeugt im Allgemeinen sehr effizienten Code. Im manchen Fällen kann DryadLINQ jedoch besseren Code erzeugen, wenn es über bestimmte Zusatzinformationen verfügt. Diese Zusatzinformationen können vom Entwickler in Form von Attributen dem Code mitgegeben werden. DryadLINQ bietet die folgenden neuen Attribute an: Associative : Der so bezeichnete Delegat einer Aggregatfunktion erfüllt das Assoziativgesetz. Homomorphic : Der so bezeichnete Delegat kommutiert über Partitionen hinweg, die Operation kann also über Partitionen hinweg parallel ausgeführt werden. Resource : Der so bezeichnete Delegat kann mit anderen Operationen zusammengefasst werden (Pipelining). Nullable : Das so bezeichnete Feld kann Null -Werte enthalten. FieldMapping : Ermöglicht effizientere Typumwandlung durch DryadLINQ.

101 Oliver Kring, Thema 7: DryadLINQ 16/ Einschränkungen unter DryadLINQ DryadLINQ ist fast vollständig kompatibel zu LINQ, aber mit folgenden Einschränkungen: DryadLINQ wurde von Microsoft überwiegend in C# getestet. Operatoren dürfen keine Seiteneffekte haben, wenn sie als Knoten in einem Cluster ausgeführt werden. Das betrifft insbesondere, wenn Objekte, auf die von mehreren Stellen aus zugegriffen wird, modifiziert werden. Die LINQ-Operatoren Then und ThenByDescending werden nicht unterstützt. Ein PartitionedTable<T> darf keine anonymen Typen enthalten. Über IEnumerable<T> -Objekte kann in einem Knoten nur einmal iteriert werden (Apply/Fork). Zu tief verschachtelte Queries können in DryadLINQ zu einem Stack Overflow führen. Wenn die PLINQ Option verwendet wird, kann es zu einer Umsortierung der Elemente kommen.

102 Oliver Kring, Thema 7: DryadLINQ 17/25 5 Weitere Beispiele in DryadLINQ 5.1 MapReduce DryadLINQ ist ein Compiler, in dem im Prinzip beliebige Algorithmen realisiert werden können. Daher lässt sich im Vergleich zwischen DryadLINQ und MapReduce sagen: DryadLINQ ist flexibler als MapReduce, es gibt keine starre Zuordnung von Knoten zu Programm (Mapper/Reducer), Joins sind problemlos möglich, kein repliziertes Schreiben der Ausgebe-Dateien, sondern Neugenerierung von Daten ausgefallener Knoten. MapReduce lässt sich durch DryadLINQ leicht nachbilden (vgl. [3]): public static IQueryable<S> MapReduce<T,M,K,S>( IQueryable<T> input, // Eingabemenge mit Objekten vom Typ T Expression<Func<T, IEnumerable<M>>> mapper, // Map-Funktion T->Ms Expression<Func<M,K>> keyselector, // Schlüssel-Funktion M->K Expression<Func<IGrouping<K,M>,IEnumerable<S>>> reducer) // Reducer-Funktion (K, Ms)-> Rs { var map = input.selectmany(mapper); var group = map.groupby(keyselector); var result = group.selectmany(reducer); return result; }

103 Oliver Kring, Thema 7: DryadLINQ 18/ Aggregatfunktionen DryadLINQ enthält bereits viele eingebaute optimierte Aggregatfunktionen (vgl. Kapitel 4.3). Das folgende Beispiel zeigt, wie mit DryadLINQ leicht neue Aggregatfunktionen definiert werden können [8]: [Associative] static double Add(double x, double y) { return x + y; } double total = numbers.aggregate((x, y) => Add(x, y)); Das Associative -Attribut sorgt für eine weitere Optimierung durch den Compiler. Die folgenden Abbildungen zeigen den Effekt des Associative -Attributs: Abb. 6: Ausführungsgraph ohne Associative -Attribut: Addition erfolgt nur auf einem Knoten (Quelle: Microsoft [8]) Abb. 7: Ausführungsgraph mit Associative -Attribut: Addition erfolgt auf mehreren Knoten (Quelle: Microsoft [8])

104 Oliver Kring, Thema 7: DryadLINQ 19/ Joins Joins sind bereits in LINQ standardmäßig vorhanden. Die Definition eines Join in der Schnittstelle IQueryable lautet wie folgt: public static IQueryable<TResult> Join<TOuter, TInner, TKey, TResult>( this IQueryable<TOuter> outer, IEnumerable<TInner> inner, Expression<Func<TOuter, TKey>> outerkeyselector, Expression<Func<TInner, TKey>> innerkeyselector, Expression<Func<TOuter, TInner, TResult>> resultselector); TOuter: Der Typ der ersten Sequenz TInner: Der Typ der zweiten Sequenz TKey: Der Schlüssel-Typ TResult: Der Typ der Ergebniselemente Im folgenden Beispiel werden Zeilen in einer Datei gesucht, die mit bestimmten Schlüsselworten beginnen: PartitionedTable<LineRecord> table = PartitionedTable.Get<LineRecord>(metadata); // Daten PartitionedTable<LineRecord> keywords = PartitionedTable.Get<LineRecord>(keys); // Schlüsselworte IQueryable<LineRecord> matches = table.join(keywords, l1 => l1.line.split(' ').First(), /* first key */ l2 => l2.line, /* second key */ (l1, l2) => l1); /* keep first line */ DryadLINQ generiert dann folgenden Ausführungsplan: Abb. 8: Ausführungsgraph für einen Join (Quelle: Microsoft [8]) Die Daten liegen in vier Partitionen vor. Die Daten müssen zunächst umpartitioniert werden (nach ihrem Schlüssel). Die Schlüsselwortdatei muss in gleicher Weise wie die Daten repartitioniert und auf die vier Knoten verteilt werden. Jeder Knoten erhält also nur einen Teil von Daten und Schlüsselworten. Der Join kann jetzt verteilt durchgeführt werden.

105 Oliver Kring, Thema 7: DryadLINQ 20/25 6 Optimierung von Anfragen durch DryadLINQ DryadLINQ ermöglicht die Entwicklung von verteilten Abfragen durch den Anwendungsprogrammierer, ohne dass dieser detaillierte Kenntnisse und Erfahrungen in der Erstellung verteilter Anwendungen benötigt. Dabei übernimmt DryadLINQ auch die Erstellung eines optimierten Ausführungsplans, sprich DryadLINQ sorgt dafür, dass die Anfrage optimal auf möglichst vielen Knoten gleichzeitig und unter Verwendung von möglichst geringer Netzwerkund Festplatten-Bandbreite ausgeführt werden kann. Im Folgenden sollen die Optimierungsmöglichkeiten von DryadLINQ aufgezeigt und an Beispielen erläutert werden (vgl. [3]). 6.1 Statische Optimierungen Wie bereits erwähnt dienen Optimierungen vor allem der Reduktion von I/O-Bandbreite, da diese bei den allermeisten Systemen nur sehr begrenzt zur Verfügung steht. Statische Optimierungen werden von DryadLINQ zur Compilierungszeit durchgeführt. Dabei werden die vom Anwendungsprogrammierer geschriebenen LINQ-Anweisungen analysiert und in einen Ausführungsgraphen übersetzt. Danach wird ein Regelwerk hinzugezogen, welches dazu dient, den Ausführungsgraphen so umzuschreiben, dass der resultierende Graph optimal im Cluster verteilt ausgeführt werden kann. DryadLINQ setzt zur Optimierung folgende Verfahren ein: Pipelining: Verkettete LINQ-Operatoren können u.u. direkt hintereinander auf demselben Knoten ausgeführt werden. Redundanzvermeidung: DryadLINQ entfernt automatisch nicht benötigte Partitionierungsschritte. Datenverdichtung zum frühestmöglichen Zeitpunkt wenn möglich werden Aggregatfunktionen vor Partitionierungsschritte verschoben. Vermeidung von Datenpersistenz: Zwischenergebnisse werden nicht abgespeichert die Daten ausgefallener Knoten werden neu generiert. 6.2 Dynamische Optimierungen Statische Optimierungen analysieren und optimieren den Ausführungsgraphen zur Übersetzungszeit ohne Betrachtung der Daten bzw. der Cluster-Topologie. Kennt man diese aber, so lassen sich weitere Optimierungen durchführen indem z.b. Aggregatfunktionen zunächst auf Prozessor-Ebene, dann auf Rack-Ebene und dann erst auf Cluster-Ebene durchgeführt werden. Ferner kann erst durch Analyse der Daten die optimale Anzahl der Knoten für jeden Berechnungsschritt des Ausführungsgraphen ermittelt werden, sowie die jeweils optimalen Grenzen für jede Datenpartition. DryadLINQ verwendet zur Laufzeit die Dryad API, um solche Optimierungen durchzuführen und den Ausführungsgraphen dynamisch umzuschreiben.

106 Oliver Kring, Thema 7: DryadLINQ 21/ Optimierungen für OrderBy Wie zuvor beschrieben, führt DryadLINQ sowohl statische Optimierungen zur Übersetzungszeit als auch dynamische Optimierungen zur Laufzeit durch. Anhand der Operation OrderBy, also eines einfachen Sortiervorgangs, soll das Verfahren erläutert werden. Abb. 9 zeigt dabei die Entwicklung des Ausführungsgraphen für einen Sortier-Knoten O durch die einzelnen Optimierungsschritte für den allgemeinen Fall, dass nämlich die Daten in unsortierter Form Vorliegen: Abb. 9: Optimierungsschritte für OrderBy (Quelle: [3]) In Optimierungsschritt (1) wird dabei die Sortier-Aufgabe O in ihre Einzel-Aufgaben zerlegt. Wichtigster Schritt ist dabei zunächst die Umpartitionierung der Daten. Dabei wird zunächst die Datenbasis stichprobenartig analysiert (DS = Data Sampling) und ein Histogramm errechnet (H), aus dem dann später eine optimale Partitionierung errechnet werden kann. Der Schritt (D) stellt dann den eigentlichen Partitionierungsschritt dar. Der folgende Merge-Schritt (M) fügt die Datensätze von den einzelnen Knoten zusammen und der Sortier-Schritt (S) führt die eigentliche Sortierung durch. Die Optimierungsschritte (2) und (3) sind dynamischer Natur. Im Schritt (2) wird zunächst die optimale Anzahl der Knoten bestimmt, auf denen die Datenpartitionierung DS + H + D durchgeführt wird. Diese wird im Wesentlichen bestimmt durch die Anzahl der Partitionen, in denen die Eingabemenge vorliegt. Schritt (3) berechnet dann die optimale Anzahl der Sortier-Knoten basierend auf dem Datenvolumen.

107 Oliver Kring, Thema 7: DryadLINQ 22/ Optimierungen für MapReduce In Kap. 5.1 wurde bereits gezeigt, wie der MapReduce -Algorithmus durch DryadLINQ umgesetzt werden kann. Die folgende Abbildung zeigt die Optimierung des MapReduce - Algorithmus durch DryadLINQ: Abb. 10: Optimierungsschritte für MapReduce (Quelle: [3]) MapReduce lässt sich durch drei LINQ-Anweisungen darstellen: Einer Map-Phase, realisiert durch den SelectMany -Operator (SM), einer (globalen) Umgruppierung des so erhaltenen Zwischenergebnisses (G) und der (globalen) Reduktion (R). Die nachfolgende Verarbeitung sei durch (X) dargestellt. Ferner sei angenommen, dass die Daten unsortiert vorliegen und die Reduktions-Funktion assoziativ und kommutativ ist. In Optimierungsschritt (1) wird der Ausführungsplan statisch in eine Map und eine Reduce- Phase umgewandelt. In der Map-Phase wird zunächst die Mapping-Funktion ausgeführt (SM), dann werden die Daten (lokal) sortiert (S) und gruppiert (G) und danach wird eine lokale Reduktion durchgeführt (R) (wohlgemerkt, die Reduktions-Funktion sei assoziativ und kommutativ). Das Einschieben einer lokalen Reduktion entspricht der Combine -Phase beim klassischen MapReduce, nur mit dem Unterschied, das DryadLINQ diese selbständig generiert. Anschließend erfolgt das Umpartitionieren der Daten (D). All diese Operationen erfolgen auf jeweils einem Knoten und beanspruchen daher kaum I/O-Bandbreite. In der sich anschließenden Reduce-Phase werden die Datenpartitionen zusammengeführt, sortiert (MS=MergeSort) und neu gruppiert (G). Am Schluss erfolgt dann die globale Reduktion (R), sowie die Nachverarbeitung (X). In Optimierungschritt (2) wird dann zur Laufzeit die optimale Anzahl der Knoten bestimmt und zwar für die Map-Phase in Abhängigkeit von den vorliegende Eingabe-Partitionen und für die Reduce-Phase abhängig vom Datenvolumen. In Schritt (3) der Optimierung wird dann die Cluster-Tolopogie ausgenutzt und z.b. auf Rack- Ebene bereits Teil-Reduktionen ( partial Aggregations ) durchgeführt, um die Datenmenge zu reduzieren, die über das Netzwerk übertragen werden muss.

108 Oliver Kring, Thema 7: DryadLINQ 23/25 7 Zusammenfassung und Ausblick DryadLINQ ist ein Compiler welcher es dem Anwendungsprogrammierer die transparente Entwicklung von verteilten Anfragen ermöglicht. DryadLINQ bietet: Stark typisierten Code in einer beliebigen.net-sprache, einfache LINQ-Syntax und sehr kompakter, aber gut lesbarer Code, Anbindung verschiedener Datenquellen via Provider-Modell, Optimierung des Anfrage-Codes und der Anfrage-Ausführung, Entwicklung des Anfrage-Codes ohne Kenntnisse über die Cluster-Architektur. DryadLINQ bietet aber nicht nur Vorteile: Die Vorgaben an das Betriebssystem (Microsoft Windows Server 2008 R2 HPC für den Master) machen den Einsatz von DryadLINQ oft unattraktiv für kleine Cluster. Bei großen Clustern fällt das aber nicht so stark ins Gewicht, da die Knoten (mit Ausnahme des Masters) bereits mit dem Betriebssystem Microsoft Windows 7 auskommen. Der Startvorgang von DryadLINQ ist aufwändig DryadLINQ ist daher ineffizient bei kleinen Abfragen. DryadLINQ arbeitet von Hause aus auf Dateien und ist daher gut geeignet für Daten, die als Datei vorliegen und als Strom verarbeitet werden können. Ist ein zufälliger Zugriff auf die Daten von Nöten, ist DryadLINQ weniger gut geeignet. Der Optimizer kann nicht alle Probleme gänzlich zur völligen Zufriedenheit optimieren. Daher ist manchmal eine Handoptimierung erforderlich. Diese erfordert jedoch genaue Kenntnisse über die DryadLINQ Optimierungsstrategien, die aber oft nur schwer zu durchleuchten sind. Der Einsatz des Apply -Operators verringert die Fähigkeit von DryadLINQ zur Optimierung der Abfragen. DryadLINQ ist etwas langsamer als handoptimierter Dryad-Code. Insgesamt sieht es aber so aus, als sei Microsoft mit dieser Entwicklung ein guter Wurf gelungen. Die Entwicklung von verteilter Software für große Cluster dürfte sich damit drastisch vereinfachen, bei gleichzeitig recht guter Performanz ohne aufwändige Optimierung. Ist dann auch noch das Personal vorhanden, um ein professionelles Server-Betriebssystem zu administrieren, ist sicherlich DryadLINQ eine Plattform, die auf jeden Fall mit in die engere Wahl kommen sollte.

109 Oliver Kring, Thema 7: DryadLINQ 24/25 8 Abbildungsverzeichnis Abb. 1: Die Schnittstellen IEnumerable<T> und IQueryable<T> Abb. 2: Architektur von DryadLINQ (Quelle: Microsoft [8]) Abb. 3: Partitionierung von Dateien (Quelle: Microsoft [8]) Abb. 4: Ausführungsplan (Quelle: Microsoft [8]) Abb. 5: Die Klasse PartitionedTable<T> Abb. 6: Ausführungsgraph ohne Associative -Attribut: Addition erfolgt nur auf einem Knoten (Quelle: Microsoft [8]) Abb. 7: Ausführungsgraph mit Associative -Attribut: Addition erfolgt auf mehreren Knoten (Quelle: Microsoft [8]) Abb. 8: Ausführungsgraph für einen Join (Quelle: Microsoft [8]) Abb. 9: Optimierungsschritte für OrderBy (Quelle: [3]) Abb. 10: Optimierungsschritte für MapReduce (Quelle: [3])

110 Oliver Kring, Thema 7: DryadLINQ 25/25 9 Literaturverzeichnis [1] Dean, J.; Ghemawat, S.: MapReduce: Simplified Data Processing on Large Clusters. In: Communications of the ACM 51 (2008), January, Nr. 1, S [2] Isard, M.; Yu, Y.: Distributed data-parallel computing using a high-level programming language. In: Proceedings of the 35 th SIGMOID international conference on Management of data ACM, 2009, S [3] Yu, Y.; Isard, M.; Fetterly, D.; Budiu, M.; Erlingsson, Ú.; Gunda, P.K.; Currey, J.: DryadLINQ: A System for General-Purpose Distributed Data-Parallel Computing Using a High-Level Language. In: Proceedings of the 8 th USENIX conference on Operating systems design and implementation USENIX Association, 2008, S [4] Wikipedia: LINQ. Weblink: Stand: 05/2011 [5] Wikipedia: Delegat (.NET). Weblink: Stand: 05/2011 [6] Microsoft: MSDN Library. Weblink: [7] Microsoft MSDN: 101 LINQ Samples. Weblink: [8] Yu, Y.; Isard, M.; Fetterly, D.; Budiu, M.; Erlingsson, Ú.; Gunda, P.K.; Currey, J.; McSherry, F.; Achan, K.: Some sample programs written in DryadLINQ. In: Microsoft Research Technical Report, MSR-TR , May 2008, 37 Seiten [9] Microsoft Research: DryadLINQ: An Introduction. Weblink: [10] Microsoft Research: Dryad LINQ Tutorial. Weblink:

111 FernUniversität in Hagen - Seminar im Sommersemester 2011 MapReduce und Datenbanken Thema 8 PigLatin Referent: Jürgen Koflerdes

112 Inhalt 1 Übersicht Einführung Geschichte und Hintergründe Installation und Start Erstes Beispiel Datenschema Pig eats everything Ein explizites Datenschema definieren Atomare Typen Tupel Bag Map UDF User Defined Functions Filter Funktionen Eval Funktionen Aggregat-Funktionen Funktionen für das Laden und Speichern Eigene Funktionen verwenden Die wichtigsten Operationen Laden und Definieren des Datenschemas Verarbeiten von Tupeln Filtern Kombinieren und Splitten Gruppieren und Joinen Sortieren Speichern Übersetzen in MapReduce Logischer und physischer Plan MapReduce Plan Entwicklungsumgebung Grunt PigPen Eclipse Plugin Generieren von Beispiel-Daten Debugging Bewertung und Vergleich mit anderen Konzepten Anwendungsszenarien Vergleich mit SQL Vergleich mit Hive Bewertung Referenzen...20

113 Seminar MapReduce: Pig Latin 3/21 Jürgen Kofer 1 Übersicht Bei der vorliegenden Seminararbeit über die Pig Latin 1 möchte ich vor allem auf das praktische Arbeiten mit der Sprache eingehen, und den Leser dazu einladen, die Beispiele auf dem eigenen Rechner auszuprobieren. Dazu ist ein Rechner oder eine virtuelle Maschine mit Linux notwendig. Die minimalen Voraussetzungen für das Verständnis dieses Texts sind Grundkenntnisse in SQL und Java. Außerdem Kenntnis des MapReduce Algorithmus [WikiMR]. Zuerst werden wir auf die Geschichte und Hintergründe eingehen, dann wenden wir uns schon der Installation zu und gehen ein erstes einfaches Beispiel durch. Im Detail beleuchten wir dann Datenschemas in Pig Latin und das Erstellen von User Defined Functions. Kapitel 5 stellt dann eine kleine Referenz für die existierenden relationalen Operationen dar. Dann schauen wir uns an, wie aus Pig Latin Skripten MapReduce Jobs werden. Und die verschiedenen Entwicklungsumgebungen und Tools für das Arbeiten mit Pig Latin. Ein Vergleich mit ähnlichen Konzepten und eine Bewertung schließt dann die Arbeit ab. 2 Einführung 2.1 Geschichte und Hintergründe Das von Google 2 eingeführte Programmiermodell MapReduce [DG04], für die Verarbeitung großer Datenmengen, besticht durch seine Einfachheit und Parallelisierbarkeit, hat aber auch einige Schwächen 3 : Die meisten Analytiker sind es gewohnt das deklarative SQL zur Verarbeitung von Daten zu verwenden Abfragen können nur von Entwicklern vorgenommen werden, die mit imperativen Sprachen wie Java vertraut sind. Es gibt nur zwei Abstraktionen: map() und reduce(). Das lässt dem Entwickler zwar maximalen Freiraum, gibt dem Anfänger aber keinerlei Unterstützung. Das führt zu einer sehr steilen Lernkurve. Selbstverständlichkeiten, wie das Filtern von Daten oder Projektionen, müssen manuell implementiert werden. Der Entwicklungszyklus mit Entwickeln, Testen und Produktivstellung ist relativ lange. Adhoc Analysen sind kaum möglich. Das MapReduce Framework weiß nichts über die Semantik der implementierten map() und reduce() Funktionen, kann also auch keine Optimierungen vornehmen, etwa um bei einer mehrstufigen Verarbeitung die Schritte vorzuziehen, die die Datenmenge am stärksten reduzieren. 1 Der englische Begriff Pig Latin beschreibt eigentlich ein beliebtes Kinderspiel, bei dem durch verdrehen und anhängen von Silben eine Art Geheimsprache entsteht Vgl. [ORU+08], Kapitel Introduction

114 Seminar MapReduce: Pig Latin 4/21 Jürgen Kofer Als Lösung für diese Schwächen wurde von Yahoo 4 die neue Sprache Pig Latin entwickelt. Sie soll die Kluft zwischen dem deklarativen Zugang mit SQL und dem prozeduralen, massiv parallelisierbaren, mit MapReduce überbrücken. Um so die Vorteile beider Welten zu nutzen. Pig Latin wurde als Datenfluss-Sprache 5 realisiert. Das bedeutet, ein Script besteht aus mehreren Schritten und jeder Schritt beschreibt eine Datentransformation. Pig Latin ähnelt dabei dem prozeduralen Zugriffsplan (Query Execution Plan), den eine relationale Datenbank aus einer SQL Abfrage generiert. Das ist ideal für große Datenmengen, da der Entwickler der Abfrage sein Wissen über die Struktur der zu verarbeitenden Daten nutzen kann, um das Skript zu optimieren. Bei SQL muss man sich darauf verlassen, dass die Datenbank einen optimalen Zugriffsplan erstellt. Beispiel: Der Teil WHERE query is not null eines SQL Statements würde in Pig Latin zu einem Schritt von vielen: filtered = FILTER rows BY query is not null Der Entwickler muss nun selber entscheiden, in welchem Schritt diese spezifische Transformation am besten stattfindet. Pig Latin unterstützt optional Datenschemas. Das heißt, die Spalten eingelesener Daten 6 können mit Namen und Typ versehen werden. Das Datenschema kann sich bei jedem Verarbeitungsschritt verändern, bis hin zu verschachtelten Strukturen, bei denen etwa ein Schlüssel auf mehrere untergeordnete Relationen verweist. Neben den eingebauten Funktionen wie COUNT und MAX können eigene definiert werden, so genannte UDFs (User Defined Functions). Für die Ausführung wird ein Script in MapReduce Jobs übersetzt. Die können dann lokal (ohne Parallelisierung) oder auf einem Hadoop [Hadoop] Cluster laufen. Das Laufzeitsystem wird übrigens einfach Pig genannt. Pig Latin ist also die formale Sprache mit der Pig gefüttert wird. Pig wurde 2007 der Apache Foundation übergeben [PigToAp] und wird dort als Open Source Projekt weitergeführt [Pig]. 2.2 Installation und Start Voraussetzungen: 1. Unix System (Linux, BSD, etc) 2. Java installiert und JAVA_HOME gesetzt 3. * Hadoop 0.20.x installiert [Hadoop] Pig ist nach folgenden, wenigen Schritten installiert: 1. Download eines Releases [Pig] 4 5 Vgl. [ORU+08], Kapitel Dataflow Language 6 Im folgenden werden wird anstatt von Daten immer von Relationen sprechen. Eine Relation bezeichnet eine ungeordnete Menge von n-tupeln. * Nur notwendig für einen Betrieb mit Hadoop

115 Seminar MapReduce: Pig Latin 5/21 Jürgen Kofer 2. Das Archiv in einem beliebigen Verzeichnis entpacken 3. * Die Hadoop Konfigurationsdateien müssen zum Classpath hinzugefügt werden. Dazu in der Datei <pig_installation>/bin/pig am Beginn hinzufügen: export PIG_CLASSPATH=<hadoop_installation>/conf Jetzt müsste sich nach dem Aufruf von <pig_installation>/bin/pig -x local die grunt 7 Konsole öffnen, die ein interaktives Erstellen von Pig Latin Skripten erlaubt. Der Parameter -x local bedeutet hier, dass ein Pseudo-MapReduce Modus verwendet werden soll und die Dateien aus dem lokalen Dateisystem kommen. Das ist nur für die Entwicklung gedacht, der Standard ist -x mapreduce und die Ausführung auf einem Hadoop Cluster. Ein Script kann mit bin/pig script.pig gestartet werden. Außerdem ist es Möglich Pig Skripen aus Java Programmen heraus zu starten 8. Weitere Details über die Installation und Inbetriebnahme finden Sie hier: [PigSetup]. 2.3 Erstes Beispiel Mit Pig wird ein im Unterverzeichnis tutorial/data ein Logfile der Suchmaschine Excite 9 mitgeliefert. Ein Tupel der Relation besteht aus drei Feldern: User ID, Zeitstempel im Format YYMMDDHHMMSS, die Suchanfrage (Query) als Textstring. Die einzelnen Felder sind durch einen Tabulator getrennt, das ist das Standardtrennzeichen von Pig. Wir wechseln ins Pig Verzeichnis und starten im local Mode: cd <pig_installation> bin/pig -x local grunt> Laden der Datensätze und Angabe eines Datenschemas: grunt> logs = LOAD 'tutorial/data/excite-small.log' AS (user, time, query); grunt> DESCRIBE logs; rows: {user: bytearray,time: bytearray,query: bytearray} DESCRIBE zeigt das Datenschema. Als Typ wird standardmäßig bytearray angenommen, wenn wir explizit einen chararray (String) als Typ wollen schreiben wir: grunt> logs = LOAD 'tutorial/data/excite-small.log' AS (user:chararray, time:chararray, query:chararray); Als nächstes Filtern wir Log-Einträge heraus die eine leere Suchanfrage (Query) haben: grunt> filtered = FILTER logs BY query is not null; Es fällt vielleicht auf, dass die eingegebenen Befehle bis jetzt nicht ausgeführt wurden: Bei der Eingabe eines Transformationsschritts in der grunt Konsole wird zwar die syntaktische Korrektheit geprüft, aber ausgeführt wird das ganze erst bei der Eingabe eines DUMP oder STORE Befehls. * Nur notwendig für einen Betrieb mit Hadoop 7 Grunt bedeutet übersetzt Grunzen. Die ganze Nomenklatur in Pig hat irgendwas mit Schweinen zu tun. 8 Siehe [PigSetup], der Abschnitt über Embedded Programs und Sample Code 9

116 Seminar MapReduce: Pig Latin 6/21 Jürgen Kofer Nun wollen wir herausfinden, welche Suchbegriffe in diesem Zeitraum am populärsten waren. Dazu gruppieren wir zunächst nach den Suchbegriffen: grunt> grouped = GROUP filtered BY query; grunt> DESCRIBE grouped; grouped: {group: chararray,filtered: {user: chararray,time: chararray,query: chararray}} DESCRIBE zeigt, dass wir nun ein verschachteltes Datenschema bekommen haben: Pro Suchbegriff (group) kann es 1..n der ursprünglichen Tupel geben (filtered). Wir zählen nun mit COUNT die Anzahl der zusammen gruppierten Relationen: grunt> counts = FOREACH grouped GENERATE group, COUNT(filtered) AS count; Als letztes sortieren wird noch die Anzahl der Sucheingaben absteigend: grunt> ordered = ORDER counts BY count DESC; grunt> DESCRIBE ordered; ordered: {group: chararray,count: long} Wir sind fertig und geben die ersten Zeilen der transformierten Relation auf der Konsole aus: grunt> first = LIMIT ordered 6; grunt> DUMP first; (maytag,41) (vanderheiden,27) (change bowel habits,24) (en vogue,23) (running shoes,22) (pregnant,20) Die SQL Abfrage die wir mit diesem Beispiel realisiert haben ist: SELECT query, COUNT(*) FROM logdata WHERE query is not null GROUP BY query ORDER BY COUNT(*) DESC LIMIT 6; 3 Datenschema 3.1 Pig eats everything Ein Datenschema ist in Pig Latin optional. Selbst wenn eines angegeben wurde, treten beim Laden von unpassenden Daten keine Fehler auf. Steht etwa ein Buchstabe in einer Spalte, die mit long definiert wurde, wird der Wert des entsprechenden Feldes einfach zu NULL. Deshalb ist Pig eats everything einer von drei Punkten der Pig Philosophie [PigPhil].

117 Seminar MapReduce: Pig Latin 7/21 Jürgen Kofer 3.2 Ein explizites Datenschema definieren Wie im Beispiel bereits gezeigt, wird das Datenschema mit einem AS Schlüsselwort definiert. Dabei können die Ausgangsdaten auch ihn verschachtelte Strukturen geladen werden: Nehmen wir an, die Ausgangsdaten liegen in folgender Form vor: (3,8,9) (4,5,6) (1,4,7) (3,7,5) Dann könnte das Datenschema so definiert werden: A = LOAD 'data' AS (t1:tuple(t1a:int, t1b:int,t1c:int),t2:tuple(t2a:int,t2b:int,t2c:int)); Für die weitere Verarbeitung kann auf die einzelnen Felder mit <tupel_name>.<feld_name> zugegriffen werden: X = FOREACH A GENERATE t1.t1a,t2.$0; $x kann verwendet werden um x'te Feld zuzugreifen. So können Felder referenziert werden, wenn kein Datenschema definiert wurde. Weitere Details über Datenschemas in Pig finden sich bei [White11], ab Seite 336 und [PigLatin] im Abschnitt Date Types and More Atomare Typen Folgende Datentypen für einzelne Felder werden unterstützt: int, long, float, double, chararray (String) und bytearray Tupel Ein Tupel ist eine geordnete Menge von Feldern. Jede Zeile der Eingangsdaten entspricht genau einem Tupel. Der Unterschied zu einer Zeile einer relationalen Tabelle ist, dass ein Feld eines Tupels nicht atomar sein muss, sondern selbst wieder ein Tupel oder ein Bag oder eine Map sein kann. Hier ein Tupel, dessen erstes Feld einen atomaren Typ (String) hat, dessen zweites ein Bag ist, das zwei Tupel enthält, und dessen drittes Feld eine Map mit einem einzelnen Eintrag ist: Bag Abbildung 1: Beispieltupel. Quelle: [ORU+08] Ein Bag ist eine ungeordnete Menge von Tupeln. Innerhalb eines Bag können die Tupel eine verschiedene Anzahl von Feldern haben, außerdem sind Duplikate erlaubt. Die ganze Relation entspricht einem sogenannten Outer Bag. Bags die als Felder von Tupeln

118 Seminar MapReduce: Pig Latin 8/21 Jürgen Kofer auftreten, werden Inner Bags genannt Map Eine Map ist eine Menge von Schlüssel/Wert Paaren. Genau wie eine Map Collection in Java. Also zum Beispiel: [name 'Karl',age 23]. Ein einzelnes Feld würde angesprochen mit map#key. Hier zum Beispiel map#'name' 'Karl'. Maps können nur aus Dateien erzeugt werden oder durch User Defined Functions. Es gibt keine Möglichkeit sie aus den Standard-Transformationen zu gewinnen. 4 UDF User Defined Functions In Pig Latin gibt es nur eine kleine Zahl von eingebauten Funktionen, wie die Aggregat-Funktionen COUNT, MAX, MIN, AVG und mathematische Funktionen wie ABS, SIN, COS. Es können aber relative leicht neue Funktionen in Java geschrieben und in Statements eingesetzt werden. Diese werden User Definied Functions genannt und es existieren verschiedene Typen von ihnen. Weitere Einzelheiten zu UDFs finden sich auch hier: [PigUDF] und bei [White11], ab Seite 343. Um die nachfolgenden Java-Beispiele kompilieren zu können, muss die Bibliothek pig-<pigversion>-core.jar in den Classpath aufgenommen werden. In Eclipse kann das im Projekt über Properties Java Build Path Libraries gemacht werden. 4.1 Filter Funktionen Eine Filterfunktion nimmt einen Wert oder einen Tupel von Werten entgegen und gibt einen boolean Wert (aussagelogisches ja oder nein) zurück. Wird nein zurückgegeben, kommt der Tupel in der Ergebnisrelation nicht mehr vor. Wir wollen das an einer Funktion isempty demonstrieren, die prüft, ob ein atomarer Wert null oder leer ist. Das Selbe könnte natürlich auch mit is null erreicht werden, unsere Funktion ist also also nicht wirklich sehr nützlich. Wir schreiben dazu eine Java Klasse IsEmpty die org.apache.pig.filterfunc erweitert. In der Methode exec() holen wir uns den Wert aus dem Eingangstupel und geben entsprechend true oder false zurück: package de.fernunihagen.seminar1912.piglatin; import java.io.ioexception; import org.apache.pig.filterfunc; import org.apache.pig.data.tuple; public class IsEmpty extends FilterFunc { public Boolean exec(tuple input) throws IOException { String query = (String) input.get(0); if (query == null query.trim().isempty()) { return true;

119 Seminar MapReduce: Pig Latin 9/21 Jürgen Kofer } } } return false; Die Methode exec() hat als formalen Parameter immer einen Tupel, selbst wenn die Funktion eigentlich einfache Felder verarbeitet. Pig erzeugt in dem Fall einen künstlichen Tupel und steckt das Feld da hinein. Wir bekommen also das tatsächlich übergebene Feld mit input.get(0). 4.2 Eval Funktionen Eval Functions (Evaluate) sind die üblichsten und allgemeinsten Funktionen. Sie erwarten einen beliebigen Datentyp als Input und geben einen beliebigen Datentyp zurück. Der Typ des Rückgabewertes wird dabei über den Java Generics [WJavaGen] Mechanismus festgelegt. Als Beispiel wollen wir eine Funktion realisieren, die einen String aus mehreren Wörtern entgegen nimmt und daraus ein Bag mit einzelnen Wörtern erzeugt. Wir wollen damit die Suchanfrage aus dem Excite Log in einzelne Wörter zerlegen, um herauszufinden welche Wörter am häufigsten in den Anfragen vorkommen. Der Grund dafür, dass wir einen Bag mit Tupeln erzeugen und nicht einfach einen einzelnen Tupel mit den Wörtern als Felder, liegt darin, dass sonst die FLATTEN Operation nicht so funktionieren würde wir wir uns das erwarten. Wir möchten nämlich eine Relation erzeugen, in der jeder enthaltene Tupel nur noch ein einzelnes Wort enthält, damit wir diese durch Gruppierung und Aggregierung zählen können. Wir schreiben eine Klasse SplitWords die org.apache.pig.evalfunc erweitert. Dann splitten wir den Eingangsstring und befüllen in einer Schleife den Ausgangs-Bag: package de.fernunihagen.seminar1912.piglatin; import java.io.ioexception; import org.apache.pig.evalfunc; import org.apache.pig.data.bagfactory; import org.apache.pig.data.databag; import org.apache.pig.data.tuple; import org.apache.pig.data.tuplefactory; public class SplitWords extends EvalFunc<DataBag> { public DataBag exec(tuple input) throws IOException { String query = (String) input.get(0); String[] words = query.split(" "); DataBag output = BagFactory.getInstance().newDefaultBag(); for (String word : words) { if (word.startswith("+") word.startswith("-")) { word = word.substring(1); } if (word.length() > 2) { Tuple t = TupleFactory.getInstance().newTuple(); t.append(word); output.add(t); } } } return output;

120 Seminar MapReduce: Pig Latin 10/21 Jürgen Kofer } Für das Erzeugen von Bags und Tupeln liefert Pig zwei Factory Klassen mit: BagFactory und TupelFactory. 4.3 Aggregat-Funktionen Aggregat-Funktionen, wie die eingebauten COUNT und MAX, sind zwar auch Eval Funktionen, allerdings werden sie immer auf eine Gruppe von Tupeln angewendet. Das erste Feld des Input- Tupels ist daher ein DataBag, über den iteriert werden muss, um z.b. irgendwelche Werte aufzusummieren. Für viele Aggregat-Funktionen ist es möglich, dass jede Map-Instanz für sich vorreduziert, damit die Daten, die zu den Reducer-Instanzen transferiert werden müssen, geringer werden. Zum Beispiel könnte jede Map-Instanz für sich schon das lokale Maximum bestimmen und die entsprechende Reducer-Instanz bestimmt dann das globale Maximum. Pig bietet dazu ein spezielles Interface Algebraic mit drei Methoden, die die Namen von drei verschiedenen Funktionen zurückgeben, die implementiert werden müssen, um solche Aggregationen dreistufig mit einem Combiner 10 auszuführen: getinitial(): Erwartet den Namen einer Eval Function, die für jede Map-Instanz genau einmal zu Beginn ausgeführt wird getintermed(): Erwartet den Namen einer Eval Function, die beliebig oft während der Combine-Stufe ausgeführt werden kann. Sie generiert Zwischendaten. getfinal(): Erwartet den Namen einer Eval Function, die am Schluss für jede Reduce- Instanz genau ausgeführt werden soll. Sie bekommt alle Zwischendaten und berechnet den endgültigen Wert. 4.4 Funktionen für das Laden und Speichern Es können die zwei abstrakten Klassen LoadFunc und StoreFunc erweitert werden, um Funktionen zu schreiben, die Daten aus speziellen Quellen oder in speziellen Formaten laden und speichern können. 4.5 Eigene Funktionen verwenden Die obigen Java Klassen müssen als JAR gebündelt und am besten in das Installationsverzeichnis von Pig Latin kopiert werden. In grunt können die Funktion dann so registriert werden: grunt> REGISTER pig-seminar.jar Jetzt könnten die Funktionen schon mit de.fernunihagen.seminar1912.piglatin.isempty() verwendet werden, wir wollen das aber kürzer haben: grunt> DEFINE isempty de.fernunihagen.seminar1912.piglatin.isempty(); grunt> DEFINE splitwords de.fernunihagen.seminar1912.piglatin.splitwords(); Nun versuchen wir herauszufinden, nach welchen einzelnen Wörtern am meisten gesucht wurde: 10 Sie [MapReduce] der Abschnitt über Combine

121 Seminar MapReduce: Pig Latin 11/21 Jürgen Kofer grunt> logs = LOAD 'tutorial/data/excite-small.log' AS(user:chararray, time:chararray, query:chararray); grunt> filtered = FILTER logs BY not isempty(query); grunt> splitted = FOREACH filtered GENERATE user, splitwords(lower(query)); grunt> DUMP splitted; (C5D01E05FF9CA265,{(mary),(lou),(allgood)}) (DB38E7AF26F3AD9A,{(microsoft),(excel)})... Was wir allerdings wollen ist, dass drei Tupel entstehen, wenn die Suchanfrage aus drei Wörtern besteht, sonst können wir die Worte nicht zählen. Wir benutzen dazu das Schlüsselwort FLATTEN: grunt> splitted = FOREACH filtered GENERATE user, FLATTEN(splitWords(LOWER(query)) )AS word; grunt> DUMP splitted; (C5D01E05FF9CA265,mary) (C5D01E05FF9CA265,lou) (C5D01E05FF9CA265,allgood) (DB38E7AF26F3AD9A,microsoft) (DB38E7AF26F3AD9A,excel) Nun können wir nach den Worten gruppieren und sie zählen: grunt> grouped = GROUP splitted BY (chararray) word; grunt> counts = FOREACH grouped GENERATE group, COUNT(splitted) AS count; grunt> ordered = ORDER counts BY count DESC; grunt> first = LIMIT ordered 6; grunt> DUMP first; (and,188) (the,95) (free,68) (pics,50) (maytag,41) (pictures,36) Beim Gruppieren war es hier notwendig die Spalte word mit (chararray) zu casten, das hat mit einem offenen Bug zu tun: [PigBug919]. Vor dem Splitten wurde die eingebaute String-Funktion LOWER benutzt, um die eingegebene Suchanfrage in Kleinbuchstaben zu verwandeln. Sonst würden z.b. die Worte pig und Pig als verschieden behandelt werden. 5 Die wichtigsten Operationen Im folgenden die wichtigsten relationalen Operationen im Überblick, mit denen Daten eingelesen und verarbeitet werden können. Eine vollständige Referenz bietet [PigLatin] im Abschnitt Relational Operators. 5.1 Laden und Definieren des Datenschemas

122 Seminar MapReduce: Pig Latin 12/21 Jürgen Kofer Syntax für den Ladebefehl: alias = LOAD 'data' [USING function] [AS schema] function ist hier eine Load UDF. Wenn nichts angegeben wird, wird PigStorage mit Tabulator als Trennzeichen angenommen. PigStorage liest Tupel von Textdateien ein. Es könnte ein anderes Trennzeichen gewählt werden mit: [ ] USING PigStorage(",") AS [...] 5.2 Verarbeiten von Tupeln Der Befehl FOREACH GENERATE iteriert über alle Tupel und generiert neue. Das entspricht dem SELECT bei relationalen Datenbanken. Syntax: alias = FOREACH alias GENERATE expression [AS schema] [expression [AS schema].] Eine expression ist hier typischerweise ein Feld der Ausgangsrelation, eine mathematische Funktion wie ABS(x), COS(x), eine String Funktion wie LOWER(str) oder eine beliebige Eval UDF. Wie bei LOAD kann mit AS das Datenschema für das Ergebnis eines Ausdrucks angegeben werden. 5.3 Filtern Die Operation FILTER entspricht einer WHERE Klausel bei SQL. Syntax: alias = FILTER alias BY expression expression ist hier ein bool'scher Ausdruck, also z.b: [ ] BY temperature > 20 and temperature < 25 or temperature > 30 Die expression könnte natürlich auch eine Filter UDF beinhalten. 5.4 Kombinieren und Splitten Die Operation SPLIT ermöglicht es, eine Relation in mehrere Relationen aufzuspalten. Ein Tupel kann dabei in mehreren Ergebnisrelationen landen oder auch in gar keiner. Syntax: SPLIT alias INTO alias IF expression, alias IF expression [, alias IF expression ] So würden zum Beispiel die Log-Daten der Excite Suchmaschine auf zwei Relationen aufgeteilt, je nachdem, ob die Suchanfrage leer war oder nicht: grunt> rows = LOAD 'tutorial/data/excite-small.log' AS (user, time, query); grunt> SPLIT rows INTO empty IF query is null, notempty IF query is not null; UNION ist das Gegenstück zu SPLIT und vereinigt mehrere Relationen zu einer. Syntax: alias = UNION alias, alias [, alias ] Um die gesplittete Relation im Beispiel wieder zu vereinen:

123 Seminar MapReduce: Pig Latin 13/21 Jürgen Kofer grunt> rows = UNION empty, notempty; 5.5 Gruppieren und Joinen GROUP und JOIN verhalten sich bei Pig Latin beinahe gleich. Beide gruppieren Relationen nach dem Inhalt von einem oder mehreren Feldern. Die Unterschiede sind: GROUP kann auch auf einer einzelnen Relation arbeiten (siehe Einführungsbeispiel) JOIN filtert Tupel heraus, bei denen das Feld, über das gruppiert werden soll, den Wert NULL enthält. Verhält sich also wie ein INNER JOIN in SQL. Das Verhalten kann geändert werden, durch die Verwendung des Schlüsselwortes OUTER: JOIN a BY $0 LEFT OUTER, b BY $0 Es werden andere Ausgangsdaten erzeugt: GROUP erzeugt eine Menge von verschachtelten Tupeln, JOIN eine Menge von flachen Tupeln. Beispiel: Wir erzeugen zwei kleine Textdateien die folgendes enthalten (Spalten durch Tabulator getrennt): test1.txt: 1 A test2.txt 3 y 2 B 2 x 3 C 1 w 4 D 1 v grunt> test1 = LOAD 'test1.txt'; grunt> test2 = LOAD 'test2.txt'; grunt> groupsingle = GROUP test2 BY $0; grunt> DUMP groupsingle; (1,{(1,w),(1,v)}) (2,{(2,x)}) (3,{(3,y)}) grunt> grouped = GROUP test1 BY $0, test2 BY $0; grunt> DUMP grouped: (1,{(1,A)},{(1,w),(1,v)}) (2,{(2,B)},{(2,x)}) (3,{(3,C)},{(3,y)}) (4,{(4,D)},{}) grunt> joined = JOIN test1 BY $0, test2 BY $0; (1,A,1,w) (1,A,1,v) (2,B,2,x) (3,C,3,y) Hier sieht man gut die wesentlichen Unterschiede: Bei GROUP werden die Tupel, die zusammengehören (das angegebene Feld hat den selben Wert), in ein Bag gesteckt. Dabei wird pro Ausgangsrelation ein Bag erzeugt (bei der Ausgabe mit DUMP wird ein Bag übrigens mit geschwungenen Klammer gekennzeichnet). Die Ausgangsrelation hat bei GROUP also immer 1 + n Felder, wenn n die Anzahl der Eingangsrelationen ist. Bei JOIN werden die passenden Tupel einfach verschmolzen. Die Ausgangsrelation hat genau so viele Felder wie alle Eingangsrelationen zusammen. Das Verhalten ist ähnlich dem JOIN in SQL. 5.6 Sortieren

124 Seminar MapReduce: Pig Latin 14/21 Jürgen Kofer Die Operation ORDER BY entspricht genau der gleichnamigen Operation in SQL. Syntax: alias = ORDER alias BY { * [ASC DESC] field_alias [ASC DESC] [, field_alias [ASC DESC] ] } [PARALLEL n] Interessant ist hier die optionale Angabe PARALLEL, die angibt, auf wie viele MapReduce Jobs die Aufgabe parallel verteilt werden soll. 5.7 Speichern STORE ist das Gegenstück zum LOAD. Syntax: STORE alias INTO 'directory' [USING function] 6 Übersetzen in MapReduce Wir schauen uns nun an wie das Einführungsbeispiel in MapReduce Jobs umgewandelt würde. Wir reduzieren das Beispiel dazu auf vier Schritte: 1. Laden (LOAD) 2. Filtern der leeren Abfragen (FILTER) 3. Gruppieren nach Abfragen (GROUP) 4. Zählen der Häufigkeit der Abfragen (COUNT) Pig Latin hat einen speziellen Operator um sich die drei verschiedenen Ausführungspläne anzeigen zu lassen: EXPLAIN. Für unser Beispiel würden wir eingeben: grunt> EXPLAIN counts; 6.1 Logischer und physischer Plan Pig prüft die semantische und syntaktische Korrektheit des Skripts und erstellt als erstes einen logischen Plan. Der logische Plan stellt die vorhandenen Operationen in die richtige Reihenfolge und wird so zur Basis für die Verarbeitungs-Pipeline. Der physische Plan hat grundsätzlich die selbe Struktur, allerdings werden nicht mehr logische Namen von Operationen und Feldern verwendet, sondern physische. Also der interne Name einer Funktion und die Nummer der Spalte eines Feldes, statt des Alias. Der physische Plan kann also relativ leicht in Java Code umgewandelt werden. 6.2 MapReduce Plan Der dritte und letzte Plan ist der MapReduce Plan und beschreibt das Umwandeln des physischen Planes in MapReduce Jobs. Aus ihnen werden schlussendlich Java Klassen, die kompiliert und in den Hadoop Cluster eingespielt werden. Wenn man sich vor Augen führt, dass der MapReduce Algorithmus genau einem Gruppieren von

125 Seminar MapReduce: Pig Latin 15/21 Jürgen Kofer Daten nach Schlüsseln (map) und dem anschließenden Verarbeiten dieser Gruppen (reduce) entspricht, ist es nicht verwunderlich wie Pig vorgeht: Als erstes werden die GROUP und JOIN Operationen herausgesucht und für jede von ihnen ein MapReduce Job erstellt. Im Map-Teil werden die Daten gruppiert, im Reduce-Teil geschieht beim GROUP vorerst gar nichts, beim JOIN werden die gruppierten Daten flachgedrückt zu Tupeln. Fast immer ist GROUP gefolgt von einer Aggregierung mit FOREACH GENERATE, diese Verarbeitung landet dann im Reduce-Teil. Wenn vor einem GROUP/JOIN ein LOAD oder FILTER ist, kommt das zum Map-Teil dazu. Das STORE kommt zum letzten Reduce-Schritt dazu. SPLIT funktioniert für die einzelnen Ergebnisrelationen wie FILTER und wird Teil der Map-Stufe. Ebenso UNION, das einfach mehrere Ausgangsrelationen durch die restliche Verarbeitung im Map- Teil schickt. ORDER wird zu zwei verschiedenen MapReduce Jobs. Im ersten Job wird die statistische Verteilung der Sortierungsschlüssel bestimmt. Im zweiten Schritt werden die Daten entsprechend der Verteilung partitioniert, um sie dann lokal sortieren zu können. Das alles ist notwendig, da wir ja global sortierte Daten haben wollen. Wie bereits bei den Aggregat-Funktionen erwähnt: Bei Algebraic-UDFs wird ein Combiner der Map-Stufe nach geschalten, um die Daten bereits in der Map-Stufe zu reduzieren. Zum genauen Ablauf der Kompilation gibt es leider recht wenige Referenzen. Eine kurze Übersicht findet sich bei [PigLatin] unter dem Abschnitt Map-Reduce Plan Compilation. Schauen wir uns nun in unserem Beispiel an, welche Jobs erzeugt werden: Pig beginnt mit dem dritten Schritt und erzeugt einen Job für die Gruppierung über die Suchanfrage (Query). Die Gruppierung landet dabei in der Map-Stufe. Ebenfalls in der Map-Stufe, noch vor der Gruppierung, landet das Laden und das Filtern. Im Reduce-Schritt werden die Gruppierten Relationen gezählt. Allerdings ist COUNT eine Algebraic Function, d.h. in einem Combiner-Schritt werden gleiche Suchanfragen bereits gezählt und die Reducer erreichen Tupel aus (Suchanfrage, Anzahl), die einfach noch weiter aufsummiert werden müssen. Es gibt also insgesamt nur einen einzelnen Job. Map Load Filter Goup Count.Initial Load Filter Goup Count.Initial Load Filter Goup Count.Initial ('super bowl', {('F1...', ' ', 'super bowl'), ('F2...', ' ', 'super bowl'),...}) Combine Count.Intermediate Count.Intermediate Count.Intermediate ('super bowl', 112) Reduce Count.Final Store Count.Final Store Count.Final Store ('super bowl', 5422) Abbildung 2: Zählen gleicher Suchabfragen ohne ORDER übersetzt in MapReduce Jobs In dem Beispiel wäre also 5422 mal der Begriff super bowl gesucht worden. Auf jeder Map/Combine-Instanz werden die lokalen Daten verarbeitet, d.h. jeder Combiner zählt für sich wie

126 Seminar MapReduce: Pig Latin 16/21 Jürgen Kofer oft super bowl gesucht wurde. Aber nur eine einzige Reduce-Instanz zählt alle super bowl Zwischenergebnisse zusammen. 7 Entwicklungsumgebung 7.1 Grunt Grunt ist eine interaktive Entwicklungsumgebung, die den inkrementelle Aufbau von Skripten erlaubt und eine einfache Textkonsole bietet. Die grunt Konsole hat außerdem einige Befehle für das Dateisystem und kann direkt das Hadoop Filesystem ansprechen, wenn Pig im MapReduce-Modus gestartet wurde: Beispiel: help: Zeigt alle verfügbaren Kommandos und Erläuterungen an ls: Listet den Inhalt des derzeitigen Verzeichnisses auf cd: Wechselt das Verzeichnis fs: Hadoop-Dateisystem Shell [HadoopFsShell]. Entspricht dem Aufruf von hadoop fs auf der Kommandozeile. quit: Beenden von grunt grunt> cd tutorial/data grunt> ls file:/opt/pig-0.8.1/tutorial/data/excite.log.bz2<r 1> file:/opt/pig-0.8.1/tutorial/data/excite-small.log<r 1> Mehr dazu bei [White11], Seite und bei [PigLatin] der Abschnitt Shell Commands. 7.2 PigPen Eclipse Plugin PigPen [PigPen] ist ein Eclipse 11 Plugin, dass einen eigenen Editor mitbringt für Pig Skripten und das Starten von diesen aus Eclipse heraus erlaubt. Das JAR wird einfach in das /plugins Verzeichnis von Eclipse kopiert. Allerdings scheint das Plugin nicht mit der derzeit aktuellen Pig/Hadoop Kombination 0.8.1/ zu funktionieren. Zumindest das Starten von Skripten ist nicht möglich. Und auch der Operator Graph funktioniert nicht, der die Transformationen graphisch darstellen sollte. Außerdem ist die derzeitige Versionsnummer von PigPen, nämlich 0.0.1, nicht gerade vertrauenerweckend. 11

127 Seminar MapReduce: Pig Latin 17/21 Jürgen Kofer 7.3 Generieren von Beispiel-Daten Abbildung 3: Screenshot PigPen Plugin Ein wirklich interessantes Feature von Pig ist die Möglichkeit Beispieldaten für ein gegebenes Skript zu generieren. In der Praxis ist es nämlich gar nicht so einfach, aussagekräftige Beispieldaten aus Milliarden von Datensätzen zu gewinnen. Der Datengenerator [PigDGen] läuft dabei als Hadoop Job und versucht ein möglichst aussagekräftiges, und gleichzeitig möglichst kleines Set, aus den realen Daten zu extrahieren. 7.4 Debugging Die sehr nützlichen Operatoren DESCRIBE, DUMP und EXPLAIN haben wir ja bereits kennengelernt. Außerdem gibt es für das Debugging die Operation ILLUSTRATE, die den Beispieldaten-Generator benutzt, um ein kleines Datensample zu erzeugen, mit dem die Ausführung eines Skripts Schritt für Schritt illustriert wird. Leider wird dieses Feature im Moment nicht mehr gewartet oder weiterentwickelt. Es könnte also in zukünftigen Versionen entfallen 12. Ein kleines Beispiel: grunt> test2 = LOAD 'test2.txt' AS (key:long,value:chararray); grunt> grouped = GROUP test2 BY key; grunt> ILLUSTRATE grouped; test2 key: long value: chararray w 1 v 12 Laut [PigLatin], Abschnitt über ILLUSTRATE.

128 Seminar MapReduce: Pig Latin 18/21 Jürgen Kofer _ grouped group: long test2: bag({key: long,value: chararray}) {(1, w), (1, v)} Zu beachten ist: ILLUSTRATE benötigt unbedingt ein Datenschema und die Operationen LIMIT und SPLIT dürfen im Skript nicht vorkommen! 8 Bewertung und Vergleich mit anderen Konzepten 8.1 Anwendungsszenarien Da Pig im Hintergrund MapReduce Jobs ausführt, liegt es in der Natur der Sache, dass Pig überall da Vorteile gegenüber einem relationalen Datenbanksystem hat, wo riesige Datenmengen anfallen. Im speziellen da, wo täglich neue Daten anfallen und einfach hinten dazu gehängt werden, wie etwa bei Log-Daten von Web-Diensten. Wo also nie etwas gelöscht oder aktualisiert wird. Das gilt aber eben ganz allgemein für Hadoop und ähnliche Systeme. Hier ein paar Szenarien, bei denen der Einsatz von Pig Latin Vorteile birgt gegenüber prozedural implementierten MapReduce Jobs: Wenn laufend verschiedene Aggregationen über riesige Datenmengen gefahren werden müssen. Pig Latin bietet mit den eingebauten Aggregationsfunktionen, wie COUNT, MAX und MIN, eine flexible Lösung. Ein Beispiel wäre das Analysieren von Log-Daten um die durchschnittliche Antwortzeit eines Servers zu ermitteln. Oder Besucherstatistiken. Wenn es darum geht verschiedene Daten zu vergleichen. Die JOIN und GROUP Operationen erleichtern solche Aufgaben ungemein. Das wird zum Beispiel oft bei temporalen Analysen benötigt, wenn verschiedene Zeitbereiche miteinander verglichen werden sollen. Etwa Besucherstatistiken nach Tagen aufgeschlüsselt. Wenn Daten in einem Hadoop Cluster liegen und Ad Hoc Auswertungen notwendig sind. Zum Beispiel wenn Kunden kurzfristig Statistiken darüber benötigen, wie oft ihre Werbung gesehen wurde. Wenn Hadoop die adäquate Lösung wäre, aber keine Entwickler da sind um die MapReduce Jobs prozedural zu implementieren. Oder wenn viele Analytiker da, sind die sich mit SQL auskennen, aber nicht Java programmieren können und wollen. Wo riesige Mengen von Daten verarbeitet werden müssen, die korrupt oder unvollständig sind. Pig ist sehr tolerant und robust beim Umgang mit den Eingangsdaten und kann auch noch Datenschemas anwenden, wo Daten fehler- und lückenhaft sind. Eine ausführliche Übersicht über Usage Scenarios bei Yahoo, wo Pig entwickelt wurde und entsprechend intensiv genutzt wird, findet sich bei [ORU+08]. 8.2 Vergleich mit SQL Der größte Unterschied zu SQL ist sicher der, dass SQL rein deklarativ beschreibt was man als Ergebnisrelation haben will, während man bei Pig Latin Schritt für Schritt die Ausgangsrelationen

129 Seminar MapReduce: Pig Latin 19/21 Jürgen Kofer transformieren und überführen muss in die gewünschte Ergebnisrelation. Wie bereits erwähnt ist Pig Latin eine Datenfluss-Sprache, irgendwo zwischen prozeduraler Programmierung und SQL angesiedelt. Ein weiterer Unterschied betrifft das Datenschema: Bei relationalen Datenbanken wird das Schema beim Schreiben von Daten validiert und angewendet. Diese Vorgehensweise wird auch schema on write 13 genannt. Schemas die in Pig Latin definiert wurden, werden allerdings erst beim Lesen angewendet. Das wird schema on read genannt und erlaubt das Verarbeiten von beliebig strukturierten Ausgangsdaten. Allerdings ist schema on read deutlich rechenintensiver, was aber kaum etwas ausmacht, da Abfragen in den typischen Anwendungsfällen nicht zeitkritisch sind. Noch ein wichtiger Unterschied: Pig Latin hat keine Befehle zur Manipulation von Daten (DML, Data Manipulation Language), wie INSERT oder UPDATE. Updates sind prinzipiell nicht möglich, weil das Hadoop File-System HDFS [HDFS] ein write-once-read-many Modell verwendet und nur in ganzen Blöcken arbeitet, die einmal geschrieben nicht mehr verändert werden können. Siehe dazu auch den Vergleich mit SQL bei [White11], Seite Vergleich mit Hive Hive [Hive] wurde von Facebook 14 aus ähnlichen Gründen ins Leben gerufen, wie Pig von Yahoo. Es sollte Analytikern mit viel SQL Erfahrung ermöglicht werden, die gigantischen Log-Daten, die täglich bei Facebook anfallen und in einem Hadoop Cluster liegen, zu durchsuchen. Hive ist allerdings sehr viel näher bei SQL angesiedelt als Pig Latin. HiveQL [HiveQL], die Abfragesprache von Hive, ist sogar ein Subset des SQL-Standards SQL-92 [SQL92]. Der Analytiker beschreibt also, genau wie bei SQL, deklarativ, was er als Ergebnisrelation haben möchte. Das bedeutet aber auch, dass Entwickler weniger Kontrolle über den Ablauf, über den Weg zur Gewinnung eines Ergebnisses, haben, als bei Pig Latin. Dafür ist HiveQL für Mitarbeiter mit SQL Hintergrund einfacher zu erlernen. Wie Pig, bietet Hive ebenfalls die Möglichkeit die Abfragesprache mit User Defined Function's zu erweitern. Auch Hive verwendet schema on read, um das Datenschema festzulegen. Allerdings existieren sehr wohl Data Definition Language (DDL) Befehle wie CREATE TABLE, die bei Pig Latin gänzlich fehlen. Die Informationen über das Schema einer Tabelle werden aber extern als Metadaten angelegt und nicht direkt auf die Daten angewendet. Beim Laden von Daten ist Hive nicht so tolerant wie Pig und korrupte Daten führen dazu, dass das Laden fehlschlägt. Von den DML Befehlen bei SQL kennt Hive nur den INSERT Befehl, der kopiert die Daten einfach in den internen Hive Datastore. So etwas wie UPDATE kann es natürlich auch nicht geben. Siehe dazu auch den Vergleich mit Hive hier bei [White11], Seite Vgl. [White11], Seite

130 Seminar MapReduce: Pig Latin 20/21 Jürgen Kofer 8.4 Bewertung Als erstes fällt bei Pig der unglaublich schnelle Einstieg positiv auf. Wenn man sich auf den local Mode beschränkt, reicht es, das ZIP File zu entpacken und schon kann man anfangen zu experimentieren. Auch der Anschluss an das Hadoop Filesystem und den MapReduce Cluster gestaltet sich sehr einfach. Das mitgelieferte, interaktive Entwicklungswerkzeug grunt ist absolut ausreichend für Ad-hoc Abfragen und um Skripte inkrementell aufzubauen. Die Debugging-Tools wie DESCRIBE und ILLUSTRATE erweisen sich als sehr nützlich dabei. Pig ist für die typischen Anwendungsfälle, wie das Analysieren großer Mengen von Log-Dateien, sehr gut geeignet und bei Yahoo dahingehend auch schon jahrelang erprobt. Gegenüber Hive bietet es vor allem da Vorteile, wo mehr Kontrolle über den Ablauf der Datentransformationen notwendig oder erwünscht ist. Wenn also ein Algorithmus nicht in der Lage sein kann die ideale Reihenfolge der Verarbeitungsschritte zu erkennen. Beim Aufbau eines Hadoop Datastores erpart Pig Latin sehr viel Arbeit und Zeit, da die Standard- Datenverarbeitungsschritte nicht erst in einer imperativen Sprache programmiert werden müssen. So kommt man recht schnell zu Ergebnissen und kann produktiv arbeiten. Allerdings wird man kaum ohne Java-Programmierer auskommen, denn mit hoher Wahrscheinlichkeit wird man die eine oder andere Funktion (UDF) selber schreiben müssen. Wenn die Funktionen allgemein gehalten werden, können sie aber sehr gut wiederverwendet werden. Alles in allem ein interessanter Ansatz und ein wertvolles Projekt im Hadoop-Umfeld. 9 Referenzen [ORU+08] Christopher Olston ; Benjamin Reed ; Utkarsh Srivastava ; Ravi Kumar ; Andrew Tomkin: Pig Latin: A Not-So-Foreign Language for Data Processing. Yahoo, [White11] Tom White: Hadoop: The Definitive Guide. O'Reilly, Kapitel Pig, Seiten [DG04] Jeffrey Dean ; Sanjay Ghemawat: MapReduce: Simplified Data Processing on Large Clusters. Google Inc., [HadoopMR] [WikiMR] [Pig] [PigSetup] [PigLatin]

131 Seminar MapReduce: Pig Latin 21/21 Jürgen Kofer [PigUDF] [PigToAp] [PigBug919] https://issues.apache.org/jira/browse/pig-919 [PigPhil] [PigPen] [PigDGen] [Hadoop] [HaFsShell] [HDFS] [Hive] [HiveQL] [WJavaGen] [SQL92]

132 FernUniversität in Hagen - Seminar im Sommersemester 2011 MapReduce und Datenbanken Thema 9 SCOPE Referentin: Silke Rüter 1 / 14

133 1 Einleitung Im Zeitalter von Internet wächst der Bedarf, riesige Mengen an Daten, die auf verschiedenen Rechnern verteilt sind, zu analysieren. Beispiele hierfür sind das Suchen nach bestimmten Begriffen, das Zählen von Zugriffen auf bestimmte URLs oder das Durchsuchen von Log- Dateien für weitere Auswertungen. Ziele solcher Analysen können beispielsweise bessere Unterstützung von Services, Bereitstellung neuer Features oder die Aufdeckung betrügerischer Aktivitäten sein. In diesem Zusammenhang ist ein Programmiermodell gefragt, das auf einfache und effiziente Art und Weise erlaubt, Auswertungen riesiger Datenmengen auf hunderten oder tausenden miteinander vernetzten Rechnern parallel durchzuführen. Die Sprache SCOPE von Microsoft soll diese Anforderungen erfüllen. SCOPE ist die Abkürzung für Structured Computations Optimized for Parallel Execution. Dahinter verbirgt sich eine deklarative und erweiterbare Script-Sprache, die auf einfache Art und Weise die Analyse von sehr großen Datenmengen ermöglicht. Ähnlichkeiten mit SQL vereinfachen das Erlernen und die Anwendung von SCOPE. Die Möglichkeit C#-Ausdrücke und -Bibliotheken einzubinden machen SCOPE zudem zu einer flexiblen und mächtigen Sprache. Die vorliegende Seminararbeit stellt SCOPE auf Basis von [CJL+08] vor. Bevor auf die Sprache und ihre Elemente eingegangen wird, wird zunächst die zugrundeliegende Software-Plattform Cosmos beschrieben. An einem kleinen Beispiel wird zum Schluss die Anwendung und Arbeitsweise von SCOPE veranschaulicht. 2 Cosmos: Die Basis-Software-Plattform Die Basis von SCOPE ist die von Microsoft entwickelte Software-Plattform Cosmos, die im Folgenden beschrieben wird. Sie dient dazu, große Datensätze zu speichern und zu analysieren. Cosmos wurde so konzipiert, dass sie auf großen Clustern, die aus tausenden von Servern bestehen, laufen kann. Beim Design von Cosmos wurde gemäß [CJL+08] auf die folgenden Aspekte besonderer Wert gelegt: Verfügbarkeit Um Datenverlust durch Hardware-Ausfälle so gut wie möglich zu vermeiden, werden die Daten mehrfach im System repliziert und durch eine Quorum-Gruppe 1 von 2ƒ+1 Servern organisiert, so dass ƒ Ausfälle verkraftet werden können. Zuverlässigkeit Die Zuverlässigkeit wird durch regelmäßiges Überprüfen der Systemdaten anhand von Prüfsummen gewährleistet. Die Prüfung findet jeweils vor der Nutzung der Daten statt. Skalierbarkeit Cosmos wurde von vorne herein so ausgelegt, dass es Petabytes 2 von Daten speichern und verarbeiten kann. Die Kapazität kann dabei einfach durch das Hinzufügen weiterer Server vergrößert werden. 1 Unter Quorum versteht man eine Komponente des Cluster Managers eines Computerclusters zur Wahrung der Datenintegrität im Fall eines Teilausfalls [Quorum]. 2 1 Petabyte = Bytes 2 / 14

134 Performanz Cosmos läuft auf Clustern von tausenden Servern, auf denen die Daten verteilt sind. Ein Job wird auf möglichst viele CPUs aufgeteilt, so dass er entsprechend schnell abgearbeitet werden kann. Kosten Cosmos verteilt die Arbeit auf eine hohe Anzahl von Servern, weswegen die Leistung eines einzelnen Servers bei der Abarbeitung eines Jobs nicht so sehr ins Gewicht fällt. Daher können für die Server leistungsschwächere und somit preiswertere Rechner hergenommen werden. In Summe ist es dadurch günstiger, die Last auf viele preiswerte Server zu verteilen, als auf wenige leistungsstarke, die entsprechend teuer sind. Die folgende Abbildung (aus [CJL+08], S. 1266) zeigt den Aufbau der Cosmos Software- Plattform. Die einzelnen Komponenten der Plattform werden im Folgenden beschrieben. 2.1 Cosmos Storage System Das Cosmos Storage System ist ein verteiltes Ablagesystem, entworfen, um zuverlässig und effizient extrem große sequentielle Dateien zu speichern ([CJL+08], S. 1267). Es handelt sich dabei um ein append-only Dateisystem. Petabytes von Daten können dort zuverlässig gespeichert werden. Für deren sequentielle Ein- und Ausgaben wurde das System außerdem optimiert. Gleichzeitige Schreibzugriffe werden vom System automatisch serialisiert. Die Daten werden verteilt, repliziert und darüber hinaus auch noch komprimiert um Speicherplatz zu sparen und gleichzeitig den Datenfluss zu erhöhen. Das Cosmos Storage System erlaubt fortlaufende Dateien unbegrenzter Größe zu speichern. Eine Datei besteht dabei aus einer Folge von sog. Extents. Extents bezeichnen die Einheit von allokiertem Speicher und sind üblicherweise einige 100 Megabytes groß ([CJL+08], S. 1267). Die Daten innerhalb so eines Extents werden in komprimierter Form in Blöcken abgespeichert. Komprimieren und Dekomprimieren erfolgen transparent auf dem Client. In eine Datenbearbeitung sind in der Regel einige wenige nebeneinander angeordnete Extents 3 / 14

135 einbezogen. 2.2 Cosmos Execution Environment Das Cosmos Execution Environment stellt eine Programmierschnittstelle und ein Laufzeitsystem zur Verfügung, das automatisch Optimierungsdetails, Fehlertoleranz, Aufteilung der Daten, Ressourcen Verwaltung und Parallelisierung vornimmt ([CJL+08], S. 1267). Eine Applikation wird als ein gerichteter azyklischer Graph modelliert. Die Knoten stellen dabei die einzelnen Prozesse dar und die Kanten den zugehörigen Datenfluss. Der sog. Job Manager ist dafür zuständig, den Graphen zu konstruieren und die Abarbeitung der einzelnen Prozessknoten innerhalb einer Applikation zu koordinieren. Dazu plant er die Abarbeitung eines Knotens ein, sobald die Eingabedaten für diesen bereitstehen, protokolliert den Fortschritt der Abarbeitung und veranlasst im Fehlerfall die wiederholte Ausführung des Teilgraphen, in dem der Fehler aufgetreten ist. 2.3 Die SCOPE-Komponenten Das SCOPE System besteht aus den Komponenten Compiler, Optimizer und Runtime und setzt auf der Software-Plattform Cosmos auf. SCOPE Runtime stellt einige gebräuchliche Operatoren bereit, auf die der Anwender in seinem SCOPE-Script zurückgreifen kann, ohne sie selbst nochmals implementieren zu müssen. Die Aufgabe des SCOPE Optimizers und Compilers ist es, das SCOPE-Script in einen effizienten parallelen Ausführungsplan zu übersetzen. 3 SCOPE: Die Script-Sprache SCOPE ist die Abkürzung für Structured Computations Optimized for Parallel Execution. Es handelt sich dabei um eine deklarative und erweiterbare Script-Sprache, die auf einfache Art und Weise die Analyse von sehr großen Datenmengen ermöglicht. Der deklarative Ansatz der Sprache erlaubt dem Anwender, sich bei seiner Problemlösung auf die eigentliche Datentransformation zu konzentrieren, ohne sich dabei um die Komplexität der zugrundeliegenden Software-Plattform Cosmos kümmern zu müssen. Im Folgenden werden zunächst ein paar allgemeine Charakteristika von SCOPE beschrieben. Anschließend wird etwas näher auf SCOPE-Kommandos und deren Verwendung in SCOPE- Scripts eingegangen. 3.1 Allgemeine Charakteristika Ähnlichkeiten mit SQL SCOPE hat einige Ähnlichkeiten mit SQL. Dies gilt sowohl für die Organisation der Daten wie auch für die Kommandosyntax. Die Daten basieren - wie bei relationalen Datenbanken - auf einem wohl definierten Schema. Ein Datensatz besteht somit aus einer Zeile, die sich aus Spaltenwerten zusammensetzt. Sowohl der Kommadoumfang wie auch die Kommandosyntax sind an SQL angelehnt. So gibt es beispielsweise ein Select-Statement, innere und äußere Joins, Aggregation und Views. Letztere erlauben unter anderem den Zugriff auf sensible Daten einzuschränken. 4 / 14

136 Die Ähnlichkeiten mit SQL erleichtern nicht nur das Erlernen der Sprache für Anwender, die über SQL-Kenntnisse verfügen, sondern ermöglichen auch die einfache Portierung bestehender SQL-Scripts nach SCOPE Einbindung von C# SCOPE bietet die Möglichkeit C#-Ausdrücke und -Bibliotheken in die Kommandos einzubinden, was die Flexibilität der Anwendung der Sprache gegenüber Standard-SQL enorm erhöht. Das heißt, alle Funktionen und Operatoren, die in C# zur Verfügung stehen, sind auch in SCOPE verfügbar und können somit in SCOPE-Scripts genutzt werden. Dies gilt für skalare Ausdrücke und Prädikate, wie auch für Funktionen und Operatoren, egal ob Standard oder Eigenimplementierung. In eingebundene C#-Klassen können beispielsweise anwendungsspezifische Berechnungen oder auch die Bearbeitung ganzer Datensätze ausgelagert werden. Zu den Operatorklassen, die in den in Kapitel 3.2 beschriebenen SCOPE-Kommandos eingebunden und anwendungsspezifisch angepasst werden können, gehören die Folgenden: Extractor Dient dazu, aus der Eingabequelle (z.b. Text-Datei, Datenbank) die gewünschten Datensätze zu extrahieren und zu konstruieren, die dann im SCOPE-Kommando weiter verarbeitet werden sollen. Outputter Wandelt das Ergebnis der Datenauswertung in das gewünschte Ausgabeformat um (z.b. Text- Datei, Datenbank). Processor Kümmert sich um die zeilenweise Bearbeitung der Daten. Reducer Reduziert, d.h. fasst die Zwischenergebnisse zusammen. Combiner Fügt die Ergebnisse mehrerer Eingabequellen zusammen. Diese Operatoren nehmen also Daten-Transformationen vor. Ein Operator nimmt in der Regel einen oder mehrere Datensätze entgegen, bearbeitet diese und gibt anschließend einen Datensatz als Ergebnis wieder zurück. Für Implementierungsbeispiele zu den Operatoren siehe auch [CJL+08]. Auf die Verwendung der genannten Operatoren innerhalb eines SCOPE-Kommandos wird in den folgenden Abschnitten noch weiter eingegangen. 3.2 SCOPE-Kommandos Prinzipiell besteht ein SCOPE-Script aus einer Folge von Kommandos. Die Ausgabe eines Kommandos ist normalerweise die Eingabe des nachfolgenden. Im Folgenden werden einige der Kommandos und der darin optional verwendbaren Operatoren bzw. Operatorklassen beschrieben. 5 / 14

137 3.2.1 Bereitstellung der Eingabedaten: EXTRACT Wie bereits erwähnt, müssen die Eingabedaten eines SCOPE-Scripts in einem wohldefinierten Schema vorliegen, damit sie ausgewertet werden können. Aus welcher Quelle diese Daten kommen ist allerdings unerheblich. Die Daten können beispielsweise aus Text-Dateien oder auch aus Datenbanken stammen. Die Überführung der Daten in ein Format, das ausgewertet bzw. weiter verarbeitet werden kann, ist die Aufgabe eines Operators, dem sog. Extractor. Standardmäßig bietet SCOPE bereits welche für normale Text-Dateien wie auch für Log-Dateien an. Es können aber auch anwendungsspezifische in C# geschrieben werden, indem einfach die Klasse Extractor überschrieben und entsprechend angepasst wird. Mit dem SCOPE-Kommando EXTRACT und dem entsprechenden Extractor können die Eingabedaten für nachfolgende SCOPE-Kommandos wie folgt gewonnen werden ([CJL+08], S. 1268): EXTRACT column[:<type>] [,...] FROM <input_stream(s)> USING <Extractor> [(args)] [HAVING <predicate>] Das Ergebnis ist ein Datensatz bestehend aus Zeilen und Spalten, auf dem im SCOPE-Script Auswertungen vorgenommen werden können Die Auswertung: SELECT und JOIN Nachdem mit dem EXTRACT-Kommando die Eingabedaten im richtigen Format vorliegen, kann die Auswertung der Daten beginnen. Dazu stellt SCOPE das Kommando SELECT bereit. Anstatt mit dem EXTRACT-Kommando explizit die Daten im gewünschten Format bereitzustellen, kann dies aber auch alternativ innerhalb des Selects per eingebundenem Extractor gemacht werden. Die Syntax des SELECT-Kommandos ist an die von SQL angelehnt und lautet wie folgt ([CJL+08], S. 1268): SELECT [DISTINCT] [TOP count] select_expression [AS <name>] [,...] FROM { <input stream(s)> USING <Extractor> {<input> [<joined input> [...]]} [,...] } [WHERE <predicate>] [GROUP BY <grouping_columns> [,...]] [HAVING <predicate>] [ORDER BY <select_list_item> [ASC DESC] [,...]] joined input: <join_type> JOIN <input> [ON <equijoin>] join_type: [INNER {LEFT RIGHT FULL] OUTER] Im Gegensatz zu SQL sind hier allerdings keine Sub-Selects erlaubt. Diese Einschränkung wird 6 / 14

138 aber durch die Möglichkeit von Outer-Joins wieder entschärft, da dadurch das Ergebnis des ersten Selects entsprechend weiter eingeschränkt werden kann. Zur Aggregation der Daten stehen Funktionen wie COUNT, COUNTIF, MIN, MAX, SUM, AVG, STDEV, VAR, FIRST und LAST bereit Die Ausgabe: OUTPUT Das Ergebnis der Auswertung kann anschließend mit einem sog. Outputter in das gewünschte Format der Datensenke überführt werden. Diese kann analog zur Datenquelle wieder beliebig sein, also beispielsweise eine Text-Datei oder auch eine Datenbank. Standardmäßig wird das Ergebnis als Text ausgegeben. Mit dem SCOPE-Kommando OUTPUT und dem entsprechenden Outputter als Operator kann das Auswertungsergebnis wie folgt in die gewünschte Ausgabe überführt werden ([CJL+08], S. 1268): OUTPUT [<input> [PRESORT column [ASC DESC] [,...]]] TO <output_stream> [USING <Outputter> [(args)]] Anwendungsspezifische Kommandos PROCESS, REDUCE und COMBINE sind drei weitere SCOPE-Kommandos, die ebenfalls durch build-in C#-Komponenten anwendungsspezifisch erweitert werden können. Sie können zusammen mit dem SELECT-Kommando verwendet werden und bieten damit vielfältige Möglichkeiten die Daten zu filtern, zu verbinden, zu berechnen oder zu aggregieren. Damit übernehmen sie die selben Aufgaben wie die Operationen map, reduce und merge im MapReduce Programmiermodell (siehe auch [DG08]). Im Folgenden wird näher auf diese drei Kommandos eingegangen PROCESS Das PROCESS-Kommando dient dazu, einen Datensatz zu bearbeiten und/oder umzuformen. Die eigentliche Arbeit übernimmt hierbei der sog. Processor, der - genau wie die bereits beschrieben Operatorklassen - ebenfalls überschrieben und damit an die Bedürfnisse der Anwendung angepasst werden kann. Der Processor nimmt genau eine Zeile des Datensatzes entgegen, bearbeitet diese und gibt dann keine, eine oder auch mehrere Zeilen wieder zurück. Ein Beispiel für die Anwendung des PROCESS-Kommandos ist, einen Eingabe-Such-String in eine Folge von einzelnen Wörtern aufzuteilen. Die Ausgabe des Kommandos wäre dann eine Menge von Zeilen, die jeweils eins dieser Wörter enthält, ggf. mit zusätzlichen Informationen, die für die weitere Verwendung benötigt werden. Die Kommandosyntax sieht wie folgt aus ([CJL+08], S.1270): PROCESS [<input>] USING <Processor> [(args)] [PRODUCE column [,...]] [WHERE <predicate>] [HAVING <predicate>] 7 / 14

139 REDUCE Das REDUCE-Kommando nimmt einen Datensatz, der nach bestimmten Kriterien gruppiert ist, entgegen. Die einzelnen Zeilen des Datensatzes werden dann pro Gruppe bearbeitet und als Ergebnis zurückgegeben. Die eigentliche Arbeit übernimmt auch hier wieder eine eigene Operatorklasse, der sog. Reducer, der auch wieder anwendungsspezifisch angepasst werden kann. Ein einfaches Beispiel für die Anwendung des REDUCE-Kommandos ist die Anzahl der Zeilen pro Gruppe zu zählen und die dadurch entstandene Zusammenfassung wieder zurückzugeben. Die Kommandosyntax sieht wie folgt aus ([CJL+08], S.1270): REDUCE [<input> [PRESORT column [ASC DESC] [,...]]] ON grouping_column [,...] USING <Reducer> [(args)] [PRODUCE column [,...]] [WHERE <predicate>] [HAVING <predicate>] COMBINE Das COMBINE-Kommando nimmt zwei Datensätze entgegen und fügt diese nach bestimmten Kriterien zusammen. Das Zusammenfügen der Datensätze erfolgt im sog. Combiner, der ebenfalls an die Bedürfnisse der Anwendung angepasst werden kann. Das Ergebnis dieses Kommandos ist eine Menge von neuen Zeilen. Ein Beispiel für die Anwendung des COMBINE-Kommandos ist die Berechnung der Differenz bestimmter Spaltenwerte von zwei Datensätzen. Die Kommandosyntax sieht wie folgt aus ([CJL+08], S.1271): COMBINE [<input1> [AS <alias1>] [PRESORT...] WITH [<input2> [AS <alias2>] [PRESORT...] ON <equality_predicate> USING <Combiner> [(args)] [PRODUCE column [,...]] [WHERE <predicate>] [HAVING <expression>] Import-Scripts: Das View-Konzept von SCOPE In SQL sind Views quasi in der Datenbank abgespeicherte Abfragen. Beim Zugriff auf eine View werden die zu diesem Zeitpunkt gültigen Ergebnisse dieser Datenbankabfrage bereitgestellt. Etwas vergleichbares gibt es auch in SCOPE. Dem Ergebnis eines SCOPE-Kommandos kann ein Name zugewiesen werden, über den es im weiteren Verlauf dann referenziert und somit in folgenden SCOPE-Kommandos weiterverwendet werden kann. Dieses benannte Ergebnis entspricht einer View in SQL. Das IMPORT-Kommando von SCOPE erlaubt es, ein so benanntes Ergebnis in einem anderen Kommando zu verwenden. 8 / 14

140 Die Kommandosyntax sieht wie folgt aus ([CJL+08], S.1271): IMPORT <script_file> [PARAMS <par_name> = <value> [,...]] Der Unterschied zu einem SQL-View ist, dass das Import-Script parametrisiert werden kann. Ein Beispiel für ein Import-Script ist das Heraussuchen von bestimmten Abfragen aus einer Log- Datei und Berechnung der Häufigkeit pro Abfrage. Ein Parameter dieses Scripts wäre die zu durchsuchende Log-Datei. Per weiterem Parameter könnte dann noch abgefragt werden, welche Abfragen mehr oder weniger als eine bestimmte Anzahl vorgenommen wurden. Import-Scripts sind ein mächtiges Instrument von SCOPE. Sie bieten zum einen Modularität und unterstützen gleichzeitig das Geheimnisprinzip und die Wiederverwendung von Code. Zum anderen können sie aber auch dazu genutzt werden, um beispielsweise Daten vor unbefugtem Zugriff zu schützen. 4 Ein Beispiel Im Folgenden soll an einem Beispiel die Umsetzung einer Auswertung mit einem SCOPE-Script erläutert werden. 4.1 Die Aufgabe Aufgabe des angegebenen SCOPE-Scripts ist es, in der Log-Datei search.log die Abfragen herauszusuchen, die mindestens 1000 mal abgesetzt worden sind. Da es sich um eine Text-Datei handelt, wird der Standard-Extractor LogExtractor genutzt, um aus der Log-Datei die Abfragen zu extrahieren. Die Ausgabe des Scripts besteht aus zwei Spalten. Die eine Spalte enthält die Abfrage und die andere die jeweils zugehörige Anzahl der Aufrufe. Die Ausgabe wird absteigend nach der Anzahl der Aufrufe sortiert und in die Cosmos-Datei qcount.result geschrieben. Da die Ausgabe im Textformat erfolgen soll, kann der Standard-Outputter hergenommen werden. 4.2 Das SCOPE-Script Die beschriebene Aufgabe kann schrittweise mit folgendem Script bewerkstelligt werden (aus [CJL+08], S.1266): e = EXTRACT query FROM "search.log" USING LogExtractor; s1 = SELECT query, COUNT(*) as count FROM e GROUP BY query; s2 = SELECT query, count FROM s1 WHERE count > 1000; 9 / 14

141 s3 = SELECT query, count FROM s2 ORDER BY count DESC; OUTPUT s3 TO "qcount.result"; Das Script enthält insgesamt fünf SCOPE-Kommandos. Wie bereits erwähnt, ist das Ergebnis eines SCOPE-Kommandos in der Regel die Eingabe des folgenden SCOPE-Kommandos. Hier werden zunächst die Abfragen mit Hilfe des LogExtractors aus der Log-Datei search.log extrahiert und dem Namen e zugewiesen. Anschließend werden in s1 die extrahierten Abfragen in e gruppiert und aufsummiert. In s2 werden dann alle Abfragen, die mehr als 1000 mal aufgerufen wurden, herausgesucht. s3 sortiert dann nur noch das Ergebnis von s2 absteigend nach Anzahl der Aufrufe. Zum Schluss wird das Gesamtergebnis mit Hilfe des Kommandos OUTPUT in die Datei qcount.result geschrieben. Da kein Outputter explizit angegeben worden ist, wird der Standard hergenommen, d.h. es erfolgt eine Ausgabe im Textformat. Die obigen Schritte e, s1, s2 und s3 kann man alternativ auch in einem SELECT zusammenfassen, so dass folgendes kurzes Script entsteht (aus [CJL+08], S.1266): SELECT query, COUNT() AS count FROM "search.log" USING LogExtractor GROUP BY query HAVING count > 1000 ORDER BY count DESC; OUTPUT TO "qcount.result"; 4.3 Compilierung und Optimierung Zunächst parsed der Compiler das Script, überprüft die Syntax und löst Namen auf. Das Ergebnis des Compile-Vorgangs ist ein sog. interner Parse-Baum. Dieser kann direkt in einen Ausführungsplan überführt werden. Letzterer kann dann vom Optimizer anschließend nochmal optimiert werden, wobei die beste Ausführungsstrategie ermittelt wird. Für die Optimierung gelten die gleichen Regeln, wie auch für die Optimierung von Datenbankabfragen, wie beispielsweise das Löschen von nicht benötigten Spalten, frühestmögliche Aggregation und das Zurückstellen von Auswahlkriterien. 4.4 Der Ausführungsplan Der Ausführungsplan zum obigen Beispiel könnte wie folgt aussehen (entnommen aus [CJL+08], S. 1272): 10 / 14

142 Er besteht aus acht Abschnitten, in denen gemäß [CJL+08] (S.1270) folgendes gemacht wird: 1. Extrahieren Die zu durchsuchende Log-Datei ist auf viele verschiedene Dateien verteilt. Daher laufen parallel entsprechend viele Extractors um die jeweiligen Datei-Fragmente einzulesen. 2. Partielle Aggregation Bei Rechnern, die im selben Rack laufen, werden die Ergebnisdaten der Extractors bereits partiell aggregiert um das Datenvolumen zu reduzieren. 3. Verteilung Die bisherigen Ergebnisse der vorherigen Schritte, die jetzt pro Rack vorliegen, werden schon mal nach den einzelnen Abfragen gruppiert. 4. Volle Aggregation Alle Ergebnisse werden nun pro Abfrage parallel voll aggregiert, bleiben aber immer noch auf mehrere Server verteilt. 5. Filterung Nachdem jetzt alle Ergebnisse voll aggregiert sind, werden die herausgefiltert, die entsprechend der Bedingung, weniger als 1000 mal aufgerufen wurden. 6. Sortierung Die verbliebenen Ergebnisse werden nun absteigend nach der Anzahl der Aufrufe sortiert. 7. Zusammenfügen Die Ergebnisse, die parallel auf mehreren Servern ermittelt worden sind, werden nun auf einem Server zum Endergebnis zusammengefügt. 11 / 14

143 8. Ausgabe Das Endergebnis wird als Cosmos-Datei in Textform bereitgestellt. Der beschriebene Ausführungsplan wird an das Cosmos Execution Environment (siehe Kapitel 2.2) übergeben. Dort werden alle notwendigen Ressourcen bereitgestellt und die Ausführung geplant. Der Job Manager überwacht die Ausführung und veranlasst im Fehlerfall die Wiederholung der fehlgeschlagenen Ausführung. 5 SCOPE und MapReduce Ein alternatives Programmiermodell, das ebenfalls die Analyse von riesigen verteilten Datenmengen erlaubt, ist MapReduce von Google (Details siehe auch [DG08]). Was nun MapReduce von SCOPE unterscheidet soll im Folgenden - ohne Anspruch auf Vollständigkeit - kurz angedeutet werden. Um mit MapReduce eine parallelisierte Auswertung großer Datenmengen vornehmen zu können, müssen zwei Funktionen map und reduce der MapReduce-Schnittstelle implementiert werden. Aufgabe der map Funktion ist es, Werte nach bestimmten Regeln zu gruppieren und diese Gruppierung als Zwischenergebnisse bereitzustellen. Diese Zwischenergebnisse werden dann an die reduce Funktion übergeben und dort aggregiert. MapReduce liegt ein Laufzeitsystem zugrunde, das die Parallelisierung der Bearbeitung durch Aufteilung der zu analysierenden Daten auf verschiedene Rechner bewerkstelligt. Entsprechend werden dann auch die implementierten Funktionen auf den verschiedenen Rechnern parallel ausgeführt. Um also Parallelisierung bei der Datenauswertung mit MapReduce nutzen zu können, muss die Applikation an das Programmiermodell entsprechend angepasst werden. Bei komplexeren Analysen kann es dabei notwendig sein, dass über mehrere Stufen hinweg die Daten gruppiert und anschließend aggregiert werden müssen, d.h. in solchen Fällen müssen mehrere map und reduce Funktionen geschrieben werden. Ein bisschen was von MapReduce steckt auch in SCOPE, wie bereits in Kapitel kurz erwähnt. Die Kommandos PROCESS, REDUCE und COMBINE, die anwendungsspezifisch angepasst werden können, übernehmen genau die selben Aufgaben, wie die Funktionen map und reduce. Sie zerlegen die Daten, gruppieren sie und aggregieren sie zum Schluss zu einem Endergebnis. Ein Unterschied zu MapReduce ist allerdings, dass die o.g. Kommandos erst zum Einsatz kommen, wenn das normale SELECT zur Auswertung nicht ausreicht, d.h. wenn komplexere Möglichkeiten benötigt werden, um Daten zu filtern, zu berechnen, zu verbinden und/oder zu aggregieren. In den anderen Fällen kann die Auswertung mit einem üblichen SELECT erledigt werden und SCOPE übernimmt die Gruppierung und Aggregation. Bei MapReduce müssen die beiden Funktionen map und reduce dagegen immer implementiert werden. 6 Fazit SCOPE bietet eine gute Möglichkeit, große Datenmengen parallelisiert auszuwerten. Die Anlehnung an SQL und die Einbindung von C# erleichtern die Erlernbarkeit und auch die Anwendung. Anwender, die sich mit SQL und relationalen Datenbanken auskennen, finden sich 12 / 14

144 in SCOPE schnell zurecht. Bei der Anwendung von SCOPE kann man sich auf die direkte Auswertung der Daten per SQL konzentrieren. Erst bei komplexeren Angelegenheiten kann es notwendig werden, anwendungsspezifische Operatoren zu programmieren. Bei MapReduce ist das Risiko der Fehleranfälligkeit und der geringen Wiederverwendbarkeit der implementierten Funktionen map und reduce nicht zu verachten und kann daher als gravierender Nachteil von MapReduce gegenüber SCOPE angesehen ([CJL+08], S. 1265). Das in Kapitel 4 zitierte Beispiel verdeutlicht zudem, wie viel kürzer man sich in SCOPE fassen kann als in MapReduce. Dasselbe Beispiel wird in [DG08Sample] (siehe Anhang) mit MapReduce und C++ realisiert und fällt dort deutlich länger aus. Literaturverzeichnis [CJL+08]: Ronnie Chaiken, Bob Jenkins, Per-Ake Larson, Bill Ramsey, Darren Shakib, Simon Weaver, Jingren Zhou, SCOPE: Easy and Efficient Parallel Processing of Massive Data Sets, VLDB Endowment, 2008, [Quorum]: [DG08]: Quorum (Informatik), Jeffrey Dean and Sanjay Ghemawat, MapReduce: Simplified Data Processing on Large Clusters, 2008, [DG08Sample]: Jeffrey Dean and Sanjay Ghemawat, MapReduce: Simplified Data Processing on Large Clusters, OSDI'04: Sixth Symposium on Operating System Design and Implementation, San Francisco, CA, 2004, / 14

145 Anhang Beispiel WordCounter aus [DG08Sample]: #include "mapreduce/mapreduce.h" // User's map function class WordCounter : public Mapper { public: virtual void Map(const MapInput& input) { const string& text = input.value(); const int n = text.size(); for (int i = 0; i < n; ) { // Skip past leading whitespace while ((i < n) && isspace(text[i])) i++; // Find word end int start = i; while ((i < n) &&!isspace(text[i])) i++; if (start < i) Emit(text.substr(start,i-start),"1"); } } }; REGISTER_MAPPER(WordCounter); // User's reduce function class Adder : public Reducer { virtual void Reduce(ReduceInput* input) { // Iterate over all entries with the // same key and add the values int64 value = 0; while (!input->done()) { value += StringToInt(input->value()); input->nextvalue(); } // Emit sum for input->key() Emit(IntToString(value)); } }; REGISTER_REDUCER(Adder); int main(int argc, char** argv) { ParseCommandLineFlags(argc, argv); MapReduceSpecification spec; // Store list of input files into "spec" for (int i = 1; i < argc; i++) { MapReduceInput* input = spec.add_input(); input->set_format("text"); input->set_filepattern(argv[i]); input->set_mapper_class("wordcounter"); } // Specify the output files: // /gfs/test/freq of // /gfs/test/freq of //... MapReduceOutput* out = spec.output(); out->set_filebase("/gfs/test/freq"); out->set_num_tasks(100); out->set_format("text"); out->set_reducer_class("adder"); // Optional: do partial sums within map // tasks to save network bandwidth out->set_combiner_class("adder"); // Tuning parameters: use at most 2000 machines and 100 MB of memory per task spec.set_machines(2000); spec.set_map_megabytes(100); spec.set_reduce_megabytes(100); // Now run it MapReduceResult result; if (!MapReduce(spec, &result)) abort(); // Done: 'result' structure contains info about counters, time taken, number of // machines used, etc. return 0; } 14 / 14

146 FernUniversität in Hagen Seminar Im Sommersemester 2011 MapReduce und Datenbanken Thema 10 Osprey Referent: Markus Zander

147 1 Markus Zander Thema 10 Osprey Inhalt 1 Einleitung Begriffe Data Warehouse Middleware OLAP Osprey Shared-Nothing-Database Motivation Ansatz Osprey und MapReduce Konzept Teile und Herrsche Möglichst wenig Zusatzsoftware Verkettete Replikation Planungsalgorithmen Architektur Umsetzung Datenmodell Aufteilung der Faktentabelle Die Datenverteilung aus Sicht des Koordinators Abfragen auf aufgeteilten Daten Transformation der Abfrage Aggregats-Funktionen Ausführung von Abfragen im Überblick Ablaufkoordination- und Planung Zufällige Verteilung LQF Majorisierung Vergleich der Algorithmen Fehlertoleranz und Leistungsfähigkeit Umgang mit langsamen Knoten Umgang Fehlern während der Ausführung Ausfall des Koordinators Ausfall eines Knotens Fehler bei der Ausführung einer Teilabfrage Experimentelle Ergebnisse Umgebung... 14

148 Thema 10 Osprey Markus Zander Skalierbarkeit Mehraufwand Lastausgleich Vergleich der Ausführungsplanungs-Algorithmen Zusammenfassung Vorteile Kritische Betrachtung Ausblick Literaturverzeichnis... 18

149 3 Markus Zander Thema 10 Osprey 1 Einleitung Zur Kontrolle und Steuerung von Unternehmen ist es erforderlich, dass Daten und Kennzahlen des Unternehmens unter unterschiedlichen Gesichtspunkten ausgewertet werden können. Hierbei werden sogenannte OLAP-Systeme eingesetzt. OLAP steht dabei für Online Analytical Processing. Die vorliegende Arbeit beschäftigt sich mit Osprey, einem verteilten Datenbankmanagementsystem (DBMS), dass für OLAP-Abfragen eine Steigerung der Performanz und der Fehlertoleranz gegenüber herkömmlichen DBMS verspricht. 1.1 Begriffe Um dem Leser das Verständnis des Textes zu erleichtern, soll zunächst eine Auswahl der im Folgenden verwendeten Fachbegriffe näher erläutert werden Data Warehouse Eine logisch zentrale Speicherung einer einheitlichen und konsistenten Datenbasis zur Entscheidungsunterstützung aller Mitarbeiter eines Unternehmens wird als Data-Warehouse bezeichnet. Die Datenbasis eines Data-Warehouses wird getrennt von den operativen Datenbanken des Unternehmens vorgehalten. (Mönch 2010) Bei Osprey ist damit eine Datenbank in einem relationalen DBMS gemeint, bei dem die Daten in einem Sternschema (siehe 3.1) angeordnet sind Middleware Ein allgemein anwendbarer Dienst, der sich zwischen Plattformen und Anwendungen befindet, wird als Middleware bezeichnet. (Mönch 2010) Osprey verwendet einen Koordinator, der sich zwischen der Anwendung und den Arbeiter-Knoten (siehe 2.5) befindet. Aufgrund dieser Zwischenschicht nennen die Entwickler von Osprey ihre Architektur einen Middleware-Ansatz, auch wenn das nach der vorgenannten Definition nicht ganz zutreffend ist OLAP Online Analytical Processing ermöglicht den Nutzern eines Data Warehouses die Daten unter verschiedenen Blickwinkeln (sog. Dimensionen ) und Darstellungsweisen zu sichten. Es dient der dynamischen Analyse der Daten eines Unternehmens. Osprey nutzt hier insbesondere den Aspekt, dass in OLAP-Systemen die Daten fast ausschließlich gelesen werden und die Datenbasis üblicherweise eine Data Warehouse ist Osprey Osprey ist Englisch und bedeutet zu Deutsch Fischadler. In der vorliegenden Arbeit bezeichnet Osprey ein verteiltes DBMS, das von Christine Yen unter Mitarbeit von Christopher Yang, Ceryen Tan und Samuel R. Madden als Beitrag zur International Conference on Data Engineering (ICDE) am 3. März 2010 unter dem Titel Osprey - MapReduce-Style Fault Tolerance in a Shared-Nothing Distributed Database vorgestellt wurde Shared-Nothing-Database Bei einer Shared-Nothing-Database handelt es sich um ein verteiltes System, das keine gemeinsamen Komponenten hat. Deshalb kann der Ausfall einer Komponente nicht das ganze System stören und eine Skalierung ist typischerweise durch das Hinzufügen von weiteren Knoten zu erreichen, da es keinen Flaschenhals gibt. Die Entwickler von Osprey ordnen das von ihnen entwickelte System trotz der Existenz eines zentralen Koordinators als Shared-Nothing- DBMS ein.

150 Thema 10 Osprey Markus Zander Motivation OLAP-Abfragen beziehen sich in der Regel auf große Datenbestände. Es ist nicht unüblich, dass eine solche Abfrage mehrere Minuten oder gar einige Stunden dauert. Tritt hierbei ein Fehler auf, so muss im Normalfall die gesamte Abfrage erneut gestellt werden. Bei Datenbanksystemen mit nur einem Knoten ist das offensichtlich, aber auch bei verteilten Datenbanksystemen ist es üblich, dass die gesamte Abfrage verworfen wird, wenn auf einem Knoten ein Fehler auftritt. DBMS, die Data Warehouses beheimaten, bestehen typischerweise aus sehr vielen Knoten. So bietet beispielsweise der Spezialist Teradata Data Warehouses mit bis zu 4096 Knoten an (Teradata Corporation 2011). Ein solch komplexes System ermöglicht zwar performante Abfragen, gleichzeitig steigt aber auch die Wahrscheinlichkeit, dass während einer lang laufenden Abfrage irgendwo im System ein Fehler auftritt. In einem konstruierten Beispiel schreiben die Osprey-Entwickler, dass der Ausfall eines Betriebssystems mit 35% Wahrscheinlichkeit und der Ausfall einer Festplatte mit 13% Wahrscheinlichkeit Größenordnungen darstellen, die nicht vernachlässigt werden können. Solch ein Fehler führt nämlich dazu, dass die gesamte Abfrage erneut gestellt werden muss, was zu nicht hinnehmbaren Verzögerungen führen kann. Osprey ist angetreten, um einerseits einen mit der Anzahl der Knoten nahezu linear steigenden Geschwindigkeitszuwachs zu erzielen und andererseits mit Fehlern, die während der Abfrage auf den einzelnen Knoten auftreten, tolerant umzugehen, so dass nicht die gesamte Abfrage erneut gestellt werden muss. 1.3 Ansatz Osprey legt sich als Zwischenschicht zwischen die Anwendung, die die Abfragen stellt und die eigentlichen Datenbank-Knoten. Ein zentraler Koordinator nimmt dabei die Anfrage in Form von gewöhnlichem SQL an. Diese Anfrage wird dann in Teilabfragen zerlegt und diese Teilabfragen werden auf den einzelnen Datenbank-Knoten ausgeführt. Die einzelnen Knoten bestehen dabei aus Hardware von der Stange. Da Osprey die Aufträge flexibel auf die einzelnen Arbeiter aufteilt, stellen auch heterogene Hardware-Umgebungen kein Problem dar. Die Autoren von (Christopher Yang 2010) sprechen dabei von einem natürlichem Lastausgleich. Auf den einzelnen Knoten werden dabei je eine Instanz des DBMS PostgreSQL (PostgreSQL Global Development Group 2011) ausgeführt. Außer PostgreSQL kann aber auch jedes andere SQL-basierte DBMS verwendet werden. 1.4 Osprey und MapReduce Osprey und MapReduce sind nur schwach miteinander verwandt. Die Osprey-Autoren sagen selbst, sie haben sich durch MapReduce lediglich inspirieren lassen. Was dabei herauskam ist ein System, das ähnlich wie MapReduce einen großen Auftrag in mehrere kleine Teile aufteilt und diese dann parallel ausführt und dabei sogenannte gierige Arbeiter verwendet, was zu dem bereits erwähnten natürlichen Lastausgleich führt. Auch die Fehlerbehandlung wurde durch MapReduce angeregt: Wenn ein Auftrag fehlschlägt oder ein Arbeiter zu lange für die Ausführung benötigt, so wird der Auftrag erneut zur Ausführung bereitgestellt und kann so von einem anderen Arbeiter ausgeführt werden. Die wichtigsten Gemeinsamkeiten und Unterschiede zeigt die nachfolgende Tabelle. Die Informationen zu MapReduce stammen dabei aus (Jeffrey Dean 2008).

151 5 Markus Zander Thema 10 Osprey Osprey Der wesentliche Mechanismus zum Abfangen von Fehlern bei der Ausführung ist das erneute Ausführen der fehlgeschlagenen Teilabfrage. Anfragen werden in Form von Standard-SQL gestellt. Die Daten werden in Standard-DBMS (z.b. PostgreSQL) gespeichert. Um Ausfälle einzelner Knoten abzufangen, werden die Daten mittels chained declustering auf mehrere Knoten verteilt und repliziert. Die Daten werden schon beim Einspielen in Osprey in Partitionen und Blöcke aufgeteilt. Diese Aufteilung wird unverändert von allen späteren Abfragen verwendet. Osprey verwendet einen Koordinator, um die Arbeit zu koordinieren und die Ergebnisse zusammenzufassen. Die Zwischenergebnisse der Teilabfragen werden im Speicher des Koordinators abgelegt. Das Verhalten von Osprey im Falle eines Speicherüberlaufs beim Zusammenfügen oder Zwischenspeichern der Ergebnisse ist nicht spezifiziert. Das Gesamtergebnis wird im Speicher des Koordinators vorgehalten. Es gibt genau ein Gesamtergebnis. Die Aufträge können neu, zugewiesen oder fertiggestellt sein. Die Verfügbarkeit der Knoten wird mittels Ping geprüft. Fällt während der Ausführung einer Anfrage ein Knoten aus, so bleiben die Ergebnisse der von diesem Knoten bereits fertiggestellten Aufträge gültig und die Aufträge selbst im Zustand fertiggestellt. Um mit langsamen Knoten umzugehen werden am Ende der Bearbeitung einer Anfrage Aufträge, die im Zustand zugewiesen sind möglichst an andere Arbeiter ebenfalls zugewiesen. MapReduce Der wesentliche Mechanismus zum Abfangen von Fehlern bei der Ausführung ist das erneute Ausführen des fehlgeschlagenen Map- oder Reduce-Jobs. Der Anwender erstellt eine Map- und eine Reduce-Funktion, die er dem MapReduce- Framework übergibt. Die Daten werden in dem von Google entwickelten verteilten Dateisystem GFS gespeichert. Um Ausfälle einzelner Rechner abzufangen werden die Daten durch das GFS auf mehrere Rechner verteilt und repliziert. Die Daten werden in dem Moment partitioniert, in dem der MapReduce-Job gestartet wird. MapReduce verwendet einen Master-Knoten, um die Arbeit zu koordinieren. Die Ergebnisse werden auf den Arbeitern zusammengefasst. Die Zwischenergebnisse der Map-Funktionen werden im Speicher der Arbeiter abgelegt (und periodisch auf die Platte geschrieben). Wenn der Speicher beim Sortieren der Zwischenergebnisse (ein Teilschritt eines Reduce-Jobs) nicht ausreicht, so wird das Sortieren auf der Festplatte durchgeführt. Das Ergebnis eines Reduce-Jobs wird in eine Datei auf der lokalen Festplatte des Arbeiters, der den Reduce-Job ausführt, gespeichert. Es gibt so viele End-Ergebnisse, wie es Reduce-Jobs gibt. Die Aufträge können im Leerlauf, in Bearbeitung oder fertiggestellt sein. Die Verfügbarkeit der Knoten wird mittels Ping geprüft. Fällt während der Ausführung eines MapReduce-Jobs ein Rechner aus, so sind die von diesem Rechner ermittelten Ergebnisse nicht mehr zugreifbar. Deshalb werden alle von diesem Rechner bereits bearbeiteten und als fertiggestellt markierten Aufträge wieder zurück in den Zustand im Leerlauf versetzt. Um mit langsamen Rechnern umzugehen werden am Ende der Bearbeitung eines MapReduce-Jobs Aufträge, die im Zustand in Bearbeitung sind möglichst an andere Rechner ebenfalls zugewiesen.

152 Thema 10 Osprey Markus Zander 6 2 Konzept Der folgende Abschnitt soll einen grundlegenden Überblick über das DBMS Osprey aus der Vogelperspektive schaffen. Osprey besteht aus einem zentralen Koordinator, der die Schnittstelle zur aufrufenden Anwendung bereitstellt und für die Kommunikation und Koordination der Datenbank-Knoten zuständig ist. Diese Datenbank-Knoten sind logisch gesehen sternförmig um den Koordinator angeordnet. 2.1 Teile und Herrsche Osprey teilt eine eingehende SQL-Abfrage in viele kleine Abfragen, die dann von den Datenbanksystemen abgearbeitet werden. Dies führt zu einer besseren Auslastung des verteilten Datenbanksystems und zu minimalen Verlusten im Fehlerfall. Der Koordinator behält jedoch stets den Überblick über den Gesamtstatus der Abfrage. 2.2 Möglichst wenig Zusatzsoftware Osprey benötigt lediglich auf dem Koordinator spezielle Software. Alle anderen beteiligten Systeme, vom Client bis zu den DBMS auf den Arbeiter-Knoten sind Standardsoftwareprodukte, die sich nicht um die Existenz von Osprey kümmern müssen. 2.3 Verkettete Replikation Als verkettete Replikation (engl. chained declustering) bezeichnet man eine Methode, bei der die Daten auf die vorhandenen Datenbank-Knoten aufgeteilt werden. Jede Partition wird dabei auf mehreren Datenbank-Knoten gespeichert, um den Ausfall eines Knotens kompensieren zu können. Das Verfahren ist in detailliert beschrieben. 2.4 Planungsalgorithmen Für die Gesamtperformance ist es wichtig, nach welchen Regeln die Teilaufträge auf die einzelnen Arbeiter verteilt werden. Osprey stellt drei verschiedene Ausführungsplaner zu Verfügung, die in 3.3 ausführlich diskutiert werden. 2.5 Architektur Ein Anwender kommuniziert mittels Standard-SQL mit dem Koordinator von Osprey. Dieser kommuniziert wiederum mittels Standard-SQL mit den einzelnen Arbeitern. Abb. 1: Architektur von Osprey; Quelle: (Christopher Yang 2010)

153 7 Markus Zander Thema 10 Osprey 3 Umsetzung Nach dem groben Überblick in Kapitel 2 stellt Kapitel 3 die wesentlichen Punkte von Osprey im Detail dar. 3.1 Datenmodell In Data Warehouses werden die Daten üblicherweise in Hyperwürfeln, also Würfeln mit beliebig vielen Dimensionen, abgespeichert. In einer relationalen Datenbank werden solche Hyperwürfel in Form eines Stern-Schemas, bestehend aus einer großen Fakten-Tabelle und mehreren verhältnismäßig kleinen Dimensions-Tabellen, abgelegt. Dabei bildet die zentrale Fakten- Tabelle den Mittelpunkt des Sterns. Abb. 2: Sternschema für einen Hyperwürfel mit 6 Dimensionen; Quelle: (Mönch 2010) Aufteilung der Faktentabelle In Osprey wird die Faktentabelle mit Hilfe der verketteten Replikation über mehrere Knoten verteilt. Die Faktentabelle wird dabei in kleinere Teile, die Partitionen, zerlegt. Jedem Knoten ist eine Partition zugeordnet. D.h., es gibt so viele Partitionen wie es Knoten gibt. Weiterhin kann eine Partition aus mehreren Blöcken bestehen. Jeder Block wird dabei in einer eigenen Datenbanktabelle gespeichert, die einen systemweit eindeutigen Namen nach dem Schema Faktentabelle_Partitionsnummer_Blocknummer hat. Für diese Aufteilung benötigt Osprey neben der Anzahl der Knoten weitere Parameter: - Den Namen der Faktentabelle, - die Angabe eines Schlüsselfeldes, - den Backupfaktor und - die Anzahl der Blöcke je Partition. Osprey muss dabei für jeden Datensatz der Faktentabelle entscheiden, zu welcher Partition er gehört. Dazu wird von dem Wert des Schlüsselfeldes ein 32-Bit-Hashwert gebildet. Diese Zahl wird durch die Anzahl der vorhandenen Knoten geteilt und der Rest der Division ergibt dann die

154 Thema 10 Osprey Markus Zander 8 Nummer der Partition, der der Datensatz zuzuordnen ist. Dieses Verfahren ist in (Hui-I Hsiao 1990) beschrieben. Es kann allerdings nicht zweifelsfrei belegt werden, dass Osprey wirklich dieses Verfahren einsetzt. Die Blöcke innerhalb der Partition werden reihum gefüllt. Der erste Datensatz einer Partition landet also im ersten Block, der nächste im zweiten und wenn der letzte Block erreicht ist, wird der nächste Datensatz wieder im ersten Block gespeichert. Der Sinn dieser Unterteilung in Blöcke liegt darin, eine höhere Parallelisierung zu erreichen, da eine Teilabfrage, die sich auf eine bestimmte Partition bezieht in so viele kleinere Teilabfragen zerlegt werden kann, wie es Blöcke gibt. Diese Teilabfragen können dann auf mehreren Knoten parallel bearbeitet werden. Der Backupfaktor k gibt an, auf wie vielen zusätzlichen Knoten eine Partition gespeichert werden soll. Bei n Knoten befindet sich eine Partition i dann auf den Knoten i und (i+1 mod n) bis (i+k mod n). Somit ist eine Partition erst dann nicht mehr verfügbar, wenn alle k+1 Knoten, die die Partition enthalten, gleichzeitig ausfallen. Osprey ist als read only -System ausgelegt. Das Einfügen der Daten ist im Normalbetrieb nicht vorgesehen. Das System bietet lediglich einen sogenannten bulk load an. Dabei ist der Abfrageteil von Osprey inaktiv und der gesamte Datenbestand wird auf einmal in das System geladen. Das Nachfolgende Beispiel soll den Vorgang verdeutlichen. Wir treffen hierzu folgende Annahmen: - Anzahl der Knoten: 4 (A, B, C, D) - Backup-Faktor: 1 - Anzahl der Blöcke je Partition: 2 - Feld zur Bildung des Hash-Wertes: Identifikations-Feld, das eine fortlaufende Zahl enthält - Hash-Verfahren: Wert des Identifikationsfeldes Modulo 4 Aufgrund des Hash-Verfahrens landen also die Datensätze in folgenden Partitionen: ID 0, 4, 8, usw. in Partition 0; ID 1, 5, 9, usw. in Partition 1; ID 2, 6, 10, usw. in Partition 2; ID 3, 7, 11, usw. in Partition 3. Wegen des Backupfaktors befindet sich die Partition 0 auf den Knoten A und B, Partition 1 auf B und C, Partition 2 auf C und D sowie Partition 3 auf D und A. Die Aufteilung der Datensätze auf die Blöcke sowie einen Gesamtüberblick zeigt die nachstehende Tabelle: Knoten A Knoten B Knoten C Knoten D Block 1 ID 0, 8, ID 1, 9, ID 2, 10, ID 3, 11, Block 2 ID 4, 12, ID 5, 13, ID 6, 14, ID 7, 15, Block 1 (Backup) ID 3, 11, ID 0, 8, ID 1, 9, ID 2, 10, Block 2 (Backup) ID 7, 15, ID 4, 12, ID 5, 13, ID 6, 14, Die Datenverteilung aus Sicht des Koordinators Für den Koordinator (genauer: den Ausführungsplaner) ist es wichtig zu wissen, welcher Knoten auf welche Daten Zugriff hat, damit er diesem Knoten nur die Teilabfragen zuteilt, die dieser mit seinem Wissen auch bearbeiten kann. Jeder Knoten hat eine vollständige Kopie aller Dimensionstabellen und Zugriff auf seine eigene Partition und die k Backups seiner Nachbarn. Abbildung 3 verdeutlicht diesen Zusammenhang. Die Abkürzung PWQ steht dabei für Partition Work Queue, eine Warteschlange für Teilabfragen, die in näher erläutert wird.

155 9 Markus Zander Thema 10 Osprey Abb. 3: Datenverteilung aus Sicht des Koordinators; Quelle: (Yen 2010) 3.2 Abfragen auf aufgeteilten Daten Transformation der Abfrage Um die Teilabfragen für die einzelnen Arbeiter generieren zu können, muss Osprey die Abfrage des Anwenders umbauen. Dies gelingt nur, wenn die Abfrage sich an einige Einschränkungen hält. Osprey schreibt deshalb vor, dass die Faktentabelle nur einmal in der Abfrage vorkommen darf und self joins nicht gestattet sind. Wie genau Osprey die Abfrage verändert, hängt von deren Aufbau ab. Eine Abfrage, in der nur Dimensions-Tabellen aber nicht die Faktentabelle vorkommt, wird unverändert an einen zufällig gewählten Arbeiter durchgereicht. Sobald die Faktentabelle verwendet wird, generiert Osprey so viele Teilabfragen, wie es Blöcke gibt (siehe 3.1.1). Dabei wird der Name der Faktentabelle durch den Namen der Tabellen, die die einzelnen Blöcke erhalten ersetzt. Heißt z.b. die Faktentabelle facttable und es gibt vier Partitionen zu jeweils zwei Blöcken, so werden insgesamt acht Teilabfragen generiert in denen der Name der Faktentabelle von facttable_0_0 bis facttable_3_1 durchnummeriert ist. So lange in der Abfrage keine Aggregatsfunktionen oder Gruppierungen enthalten sind, ist das Ergebnis, das an den Aufrufer zurückgegeben wird die Vereinigung aller Teilergebnisse Aggregats-Funktionen Sobald Aggregats- oder Gruppierungs-Funktionen in der Abfrage genutzt werden, ist die Transformation der Abfrage etwas aufwendiger. Gruppierungs-Funktionen (GROUP BY) werden in die Teilabfragen unverändert übernommen. Beim Zusammenfassen der Teilergebnisse führt Osprey erneut eine Gruppierung aus, um so Gruppen, die in mehreren Teilergebnissen vorkommen wiederum zusammenzufassen. Aggregatsfunktionen behandelt Osprey unterschiedlich. Die Entwickler schreiben nicht, welche Aggregatsfunktionen Osprey unterstützt, führen aber beispielhaft sum, count, min, max und avg an. Sum (Summierung) wird in die Teilabfragen unverändert übernommen. Beim Zusammenführen der Teilergebnisse summiert Osprey die Werte der Teilergebnisse, um das Gesamtergebnis zu erhalten. Count (Zählen) wird in die Teilabfragen unverändert übernommen. Auch hier summiert Osprey die Werte der Teilergebnisse, um das Gesamtergebnis zu erhalten.

156 Thema 10 Osprey Markus Zander 10 Min (Minimum) wird in die Teilabfragen unverändert übernommen. Beim Zusammenführen der Abfragen ermittelt Osprey das Minimum der Werte der Teilergebnisse, um das Gesamtergebnis zu erhalten. Max (Maximum) wird in die Teilabfragen unverändert übernommen. Beim Zusammenführen der Abfragen ermittelt Osprey das Maximum der Werte der Teilergebnisse, um das Gesamtergebnis zu erhalten. Avg (Durchschnitt) kann nicht unverändert in die Teilabfragen übernommen werden, da beim Zusammenführen nicht einfach der Durchschnitt der Durchschnitte gebildet werden kann. Stattdessen wird die Funktion durch zwei getrennte Funktionen sum und count gebildet. Aus avg(price) wird also sum(price), count(price). Beim Zusammenführen der Ergebnisse berechnet Osprey selbst den Durchschnitt aus den Werten der Teilergebnisse und verwendet diesen Wert für das Gesamtergebnis Ausführung von Abfragen im Überblick Beim Eintreffen einer Abfrage des Anwenders generiert Osprey daraus Teilabfragen (3.2.1). Zu jeder Partition existiert eine korrespondierende Warteschlange, die Partition Work Queue. Die generierten Teilabfragen werden anhand der Partitionsnummer im Tabellennamen der Faktentabelle der entsprechenden Partition Work Queue zugeordnet. Eine Teilabfrage mit der Tabelle facttable_0_x wird demnach der Partition Work Queue 0 zugeordnet. Aggregatsfunktionen werden nötigenfalls modifiziert (3.2.2). Der Ausführungsplaner verteilt nun, in Abhängigkeit von dem jeweils gewählten Planungsalgorithmus, die ersten Teilabfragen aus den Partition Work Queues an die Arbeiter (3.3). Anschließend prüft er zyklisch alle Arbeiter, ob diese noch leben und noch beschäftigt sind. Die Arbeiter bearbeiten die gestellte Teilabfrage und liefern das Ergebnis an den Koordinator zurück. Dieser merkt sich die Teilergebnisse und sobald alle Teilabfragen abgearbeitet sind, generiert der Result Merger daraus durch Vereinigung und Aggregation das Gesamtergebnis (3.2.2). Abbildung 4 illustriert den Vorgang. Abb. 4: Ausführung einer Abfrage in Osprey; Quelle: (Yen 2010)

157 11 Markus Zander Thema 10 Osprey 3.3 Ablaufkoordination- und Planung Der Ausführungsplaner kann verschiedene Algorithmen nutzen, um die Teilaufgaben so schnell wie möglich von den Arbeitern abarbeiten zu lassen. Die in Osprey implementierten Algorithmen sollten im Folgenden vorgestellt werden. Ein wesentlicher Punkt ist, dass Osprey mit sogenannten gierigen Arbeitern arbeitet. Dies bedeutet, dass nicht nur noch nicht angefangene Aufgaben verteilt werden: Sobald eine Partition Work Queue leer ist, beginnt der Scheduler damit, alle noch nicht abgeschlossenen Aufgaben dieser Queue erneut zu verteilen. Auf diese Art wird einerseits umgangen, dass der langsamste Arbeiter das ganze System aufhält, andererseits werden so fehlgeschlagene Teilanfragen auf anderen Arbeitern erneut durchgeführt. Man erhält die Fehlertoleranz von Osprey sozusagen als Nebenprodukt geschenkt. Die Ausführungsplanung ist nur deshalb sinnvoll, weil es im Normalfall immer mehrere Knoten gibt, die eine Teilabfrage bearbeiten können. Bei den weiter unten beschriebenen Auswahlverfahren geht es also immer darum, für einen Arbeiter aus einer der für ihn möglichen Partition Work Queues einen Auftrag auszuwählen. Das Abarbeiten der Partition Work Queues läuft wie folgt ab: 1. Partition Work Queues füllen (siehe 3.2.3) 2. Verfügbarkeit der Arbeiter mittels Ping prüfen 3. Für jeden verfügbaren Arbeiter mit einem der weiter unten beschriebenen Verfahren eine Partition Work Queue auswählen, dieser einen Auftrag entnehmen, diesen dem Arbeiter zuteilen und ihn zusätzlich in eine separate Partition Work Queue für zugeteilte Aufträge übernehmen. Sind für diesen Arbeiter keine Aufträge mehr verfügbar weiter mit Sobald ein Arbeiter ein Teilergebnis zurückliefert, dieses zwischenspeichern, den Auftrag als erledigt markieren und für diesen Arbeiter Vorgang ab Schritt 2 wiederholen. Liefert der Arbeiter statt eines Ergebnisses einen Fehler, wird der Auftrag wieder zurück in die Partition Work Queue für unbearbeitete Aufträge gestellt. 5. Für den verfügbaren Arbeiter gemäß der verwendeten Zuteilungsmethode einen Auftrag, der sich im Status zugeteilt befindet, auswählen und zuteilen. Sind für keinen Arbeiter mehr Aufträge vorhanden weiter mit Sobald ein Arbeiter ein Teilergebnis zurückliefert, dieses zwischenspeichern, den Auftrag als erledigt markieren und für diesen Arbeiter Vorgang ab Schritt 2 wiederholen. Liefert der Arbeiter statt eines Ergebnisses einen Fehler, wird der Auftrag wieder zurück in die Partition Work Queue für unbearbeitete Aufträge gestellt. 7. Aus den zwischengespeicherten Ergebnissen das Gesamtergebnis mittels Vereinigung, Gruppierung und Aggregation zusammensetzen (siehe auch 3.2.2) und an den Aufrufer zurückgeben. Sollten in den Schritten 4 und 7 das Ergebnis einer Teilabfrage eintreffen, das zuvor schon ein anderer Knoten geliefert hat, so wird es verworfen. Die Ergebnisse unterschiedlicher Teilabfragen können sich nicht überschneiden. Dies ist durch die Partitionierung der Faktentabelle gewährleistet Zufällige Verteilung Dies ist die einfachste Art der Verteilung. Aus den für einen Arbeiter in Frage kommenden Partition Work Queues wird zufällig eine ausgewählt LQF Bei der Methode längste Warteschlange zuerst (engl. longest queue first, LQF) wird aus den für einen Arbeiter in Frage kommenden Partition Work Queues diejenige ausgewählt, die am längsten ist. Die Länge einer Warteschlange ist dabei definiert durch die Anzahl der enthaltenen Aufträge.

158 Thema 10 Osprey Markus Zander Majorisierung Ziel der Majorisierungs-Methode ist es, zu vermeiden, dass es gleichzeitig Arbeiter gibt, die einer hohen Last ausgesetzt sind, während andere leer laufen, weil es keine Aufgaben mehr gibt, die sie bearbeiten könnten. Dies soll dadurch erreicht werden, dass der Algorithmus versucht die Unterschiede in der Belastung für den einzelnen Arbeiter auszugleichen. Dazu muss neben der Länge der für den jeweiligen Arbeiter direkt verfügbaren Warteschlangenlänge auch die Länge der Warteschlangen seiner Nachbarn, mit denen er sich Warteschlangen teilt, berücksichtigt werden. Es wird die Partition Work Queue gewählt, die sich der Arbeiter gemeinsam mit dem Nachbarn teilt, der die größte Last hat. Gibt es kein eindeutiges Maximum, so kommt LQF zum Einsatz. Dieses Verfahren geht auf (Golubchik 1991) zurück, es wurde jedoch für den Einsatz in Osprey leicht abgewandelt. Das Verfahren soll mit einem Beispiel erläutert werden. Angenommen, es existieren vier Arbeiterknoten A, B, C und D. Das System arbeitet mit einem Backup-Faktor von 1. Die Länge der Warteschlangen zum betrachteten Zeitpunkt sind wie folgt: PWQ0 enthält sechs Aufträge, PWQ1 enthält einen Auftrag, PWQ2 enthält drei Aufträge und PWQ3 enthält zwei Aufträge. In diesem Moment soll Arbeiter C ein Auftrag zugeteilt werden. Dieser Arbeiter hat aufgrund des Backupfaktors Zugriff auf die Partitionen 1 und 2. Käme jetzt die LQF-Strategie zum Einsatz, würde ihm ein Auftrag aus PWQ2 zugeordnet, da PWQ2 mehr Aufträge enthält als PWQ1. Stattdessen wird aber die Last der Knoten herangezogen. Der Knoten C selbst hat Zugriff auf PWQ1 und PWQ2. Seine Last sind also 4 Aufträge. Da er sich mit Knoten B und D jeweils eine PWQ teilt, muss auch die Last dieser Knoten berücksichtigt werden. Knoten B hat Zugriff auf PWQ 0 und PWQ 1 und somit eine Last von 7 Aufträgen, für Knoten D ergibt sich durch PWQ2 und PWQ 3 eine Last von fünf Aufträgen. Da also Knoten B die größte Last trägt wird der Auftrag für Knoten C aus der Partition Work Queue genommen, die er sich mit Knoten B teilt: PWQ Vergleich der Algorithmen Die Algorithmen sind alle so trivial zu berechnen, dass der durch den Algorithmus verursachte Aufwand vernachlässigt werden kann. Was bleibt, ist ein Vergleich, wie schnell die Warteschlangen abgearbeitet werden. Die zufällige Verteilung schneidet hier am schlechtesten ab: Geht man von einer Gleichverteilung aus, so muss zum Schluss auf den langsamsten Knoten gewartet werden, da die anderen Knoten keine Unterstützung bei der Abarbeitung der Warteschlange des langsamen Knotens geleistet haben. Die beiden anderen Algorithmen scheinen auf den ersten Blick recht ähnlich zu sein. Da die Länge der Warteschlangen bestimmt, von wo der nächste Auftrag genommen wird, ist hier eine Unterstützung langsamer Knoten gewährleistet. Gemäß (Golubchik 1991) bietet die Majorisierung gegen über LQF einen Geschwindigkeitsvorteil von rund 19%. 4 Fehlertoleranz und Leistungsfähigkeit 4.1 Umgang mit langsamen Knoten Damit am Ende einer Abfrage nicht auf die Ergebnisse der langsamsten Knoten gewartet werden muss geht Osprey wie folgt vor: Teilabfragen können sich im Zustand neu, zugewiesen und fertiggestellt befinden. Wird eine Teilabfrage einem Knoten zugewiesen, wird sie zunächst als zugewiesen markiert. Erst nachdem das Ergebnis einer Teilabfrage vorliegt, wird sie als fertiggestellt markiert. Wenn nun keine Teilabfragen mehr den Zustand neu haben, werden leerlaufenden Knoten nach Möglichkeit Teilabfragen im Zustand zugewiesen zugeteilt. Eine

159 13 Markus Zander Thema 10 Osprey solche Abfrage wird nun zeitgleich von mehreren Knoten bearbeitet. Osprey markiert die Abfrage als fertiggestellt, sobald einer der Knoten, die die Teilabfrage bearbeiten, ein Ergebnis zurückliefert. Das bedeutet auch, dass der Koordinator gar nicht merkt, wenn ein Knoten zu langsam ist, denn dies ist aufgrund der beschriebenen Methode nicht notwendig. Lediglich der komplette Ausfall von Knoten wird erkannt, um unnötige Zuteilungsversuche zu vermeiden. Dies ist in beschrieben. 4.2 Umgang Fehlern während der Ausführung Hier muss man verschiedene Klassen von Fehlern unterscheiden: Ausfall des Koordinators Der Koordinator ist der zentrale Punkt von Osprey. Sollte hier ein Fehler auftreten, z.b. der Absturz der Koordinationssoftware oder des darunterliegenden Betriebssystems, so kann das System nicht mehr arbeiten. Gegen solche Ausfälle ist Osprey also nicht geschützt. Bei Fehlern in der vom Benutzer gestellten Abfrage, die eine Bearbeitung unmöglich machen, wäre es sinnvoll, wenn der Koordinator eine geeignete Fehlermeldung an den Aufrufer zurückgeben würde - spezifiziert ist dieses Verhalten jedoch nicht Ausfall eines Knotens Osprey überwacht die Verfügbarkeit der Arbeiter, in dem es regelmäßig reihum einen Ping an die Arbeiter schickt. Wird dieser nicht beantwortet, wird der entsprechende Knoten als tot markiert. Diesem Arbeiter teilt der Ausführungsplaner fortan keine neuen Aufträge mehr zu. Wie und ob ein toter Knoten weiter überwacht wird und eine erneute Verfügbarkeit gehandhabt wird, ist nicht spezifiziert. Es scheint sinnvoll, diese Knoten weiterhin regelmäßig, wenn auch seltener auf Verfügbarkeit zu testen und den Knoten wieder in die Ausführung von Aufträgen einzubinden, wenn er wieder verfügbar ist. Aufträge für einen toten Knoten werden fortan von denjenigen anderen Knoten bearbeitet, die eine Kopie der betroffenen Partition haben. Hierzu ist jedoch kein gesonderter Mechanismus auf dem Koordinator oder im Ausführungsplaner erforderlich. Dies geschieht durch die in 3.3 beschriebenen Zuordnungsalgorithmen automatisch. Es ist also kein Unterschied, ob ein Knoten einfach nur zu langsam oder vollständig ausgefallen ist. Die Entwickler von Osprey beschreiben nicht, wie das System reagiert, wenn auch alle Backup- Knoten ausgefallen sind, so dass eine Partition gar nicht mehr zur Verfügung steht. Da in diesem Fall eine korrekte Bearbeitung der Anfrage nicht garantiert 1 werden kann, scheint es sinnvoll, dass Osprey die Ausführung der Anfrage abbricht und dem Aufrufer eine Fehlermeldung zurückliefert Fehler bei der Ausführung einer Teilabfrage Tritt bei der Abarbeitung einer Teilabfrage auf einem Knoten ein Fehler auf, so wird dieser Teilauftrag vom Zustand zugewiesen in den Zustand neu versetzt und wieder in die zugehörige Partition Work Queue eingereiht. Damit kann der Teilauftrag von einem anderen (oder ggfs. auch von dem selben) Knoten später erneut bearbeitet werden. Leider schreiben die Entwickler nicht, wie und ob sie Fehler bei denen eine erneute Zuweisung sinnvoll ist von solchen unterscheiden, bei denen es angebracht ist den Fehler an den Aufrufer weiterzugeben und die Abarbeitung der Anfrage abzubrechen. Ein Beispiel für einen Fehler erster Art wäre z.b. eine Störung der Festplatte des Knotens, ein Beispiel für einen Fehler der zweiten Art die 1 Da die Teilabfragen, die die ausgefallene Partition betreffen unter Umständen gar keine Datensätze zurückliefern würden, z.b. weil sie die Bedingung des WHERE-Statements nicht erfüllen, kann es Konstellationen geben, in denen auch ohne diese Daten das Ergebnis korrekt wäre.

160 Thema 10 Osprey Markus Zander 14 Abfrage einer nicht vorhandenen Spalte durch den Anwender. Der Koordinator selbst kann das nicht feststellen, da er selbst keine Daten, auch keine Metadaten, kennt. Zusammenfassend kann man festhalten: Fehler, die auf einzelnen Knoten entstehen und nicht schon in der Abfrage begründet sind, werden von Osprey korrekt abgefangen und bleiben für den Anwender unbemerkt, für alle anderen Fehler ist das Verhalten nicht spezifiziert. 4.3 Experimentelle Ergebnisse Die hier vorgestellten Ergebnisse beziehen sich auf die Daten, die die Entwickler von Osprey selbst ermittelt und in (Christopher Yang 2010) publiziert haben Umgebung Als Testumgebung wurde ein Zusammenschluss von neun Rechnern verwendet, die jeweils über zwei Pentium-4-Prozessoren mit 3,06GHz, 2GB Hauptspeicher und Linux-Betriebssystem verfügten. Einer der Rechner wurde als Koordinator genutzt, die anderen acht waren Arbeiter- Knoten auf denen PostgreSQL als DBMS zum Einsatz kam. Die Rechner waren mittels Gigabit- Ethernet verbunden. Die Tests wurden mit dem Star-Schema-Benchmark (Pat O'Neil 2009) durchgeführt. Die Testdaten bestanden aus einer Faktentabelle mit 60 Millionen Datensätzen und einer Größe von 5,4GB sowie insgesamt 105MB Daten für die vier Dimensions-Tabellen. Der Benchmark stellt insgesamt dreizehn ausgewählte Abfragen zur Verfügung, die die typischen Anforderungen in einer Data-Warehouse-Umgebung simulieren sollen. Die Abfragen sind so gestaltet, dass die getesteten DBMS möglichst nicht durch ihren Cache die Ergebnisse verfälschen können. Zusätzlich haben die Entwickler von Osprey bei den PostgreSQL-Instanzen den Cache auf 512MB begrenzt. Da Osprey als Read-Only-System ausgelegt ist, verursachen Indizes nur beim erstmaligen Einspielen der Daten Aufwand. Aus diesem Grund wurden für den Test Indizes auf allen relevanten Feldern, sowohl für Faktentabelle als auch für die Dimensions-Tabellen erstellt. Indizes beschleunigen die Abfragen; Für den relativen Vorteil, den Osprey bietet, sollten sie jedoch keine Rolle spielen. Zum Aufteilen der Faktentabelle wurde das Feld lo_orderdate benutzt. Das dabei verwendete Hashverfahren haben die Osprey-Entwickler nicht beschrieben. Vor dem Testlauf wurden die PostgreSQL-Instanzen mit dem Befehl ANALYZE dazu aufgefordert, die Daten zu analysieren, damit der PostgreSQL-Ausführungsplaner besser arbeiten kann. Um langsame, überlastete Knoten zu simulieren, griffen die Osprey-Entwickler auf ein sogenanntes Burn-In-Tool zurück. Dieses erzeugt künstlich eine hohe CPU-, Speicher- und Festplattenlast, so dass PostgreSQL auf solchen Knoten nur noch mit sehr begrenzten Ressourcen arbeiten kann Skalierbarkeit In dieser Disziplin geht es darum, dass die Geschwindigkeit linear mit der Anzahl der Arbeiter wächst, also die Ausführungszeit sich umgekehrt proportional zur Anzahl der Arbeiter verhält. Das nachfolgende Diagramm bestätigt dieses Verhalten, jedoch fehlt ein Vergleich mit einem einfachen DBMS ohne zwischengeschalteten Osprey-Koordinator.

161 15 Markus Zander Thema 10 Osprey Abb. 5: Zusammenhang zwischen Anzahl der Arbeiter und Ausführungszeit; Quelle: (Christopher Yang 2010) Mehraufwand Osprey selbst verursacht zusätzlichen Aufwand gegenüber einem einfachen DBMS. Dieser Aufwand stammt hauptsächlich aus dem Transformieren der Abfrage, der Ausführungsplanung, der Übermittlung der Teilabfrage an die Arbeiter, dem Abholen der Teilergebnisse sowie deren Zusammenführen zu einem Gesamtergebnis. Die Osprey-Entwickler wählten hier verschiedene Block-Größen der Partitionen und somit eine unterschiedliche Menge von Blöcken und verglichen jeweils die Ausführungszeit von den Arbeitern mit der Gesamtzeit der Abfrage. Hier schnitt Osprey gut ab, auch wenn konkrete Zahlen nicht bekannt sind. Jedoch scheint dieser Ansatz nicht geeignet, um den Osprey- Overhead zu zeigen. Ein Vergleich von Osprey mit einem Arbeiter und einem einfachen DBMS hätte den Overhead besser gezeigt. Aus diesem Grunde wird auf eine ausführliche Darstellung der Ergebnisse an dieser Stelle verzichtet Lastausgleich Bei diesem Test soll Osprey zeigen, dass es mit überlasteten oder ausgefallenen Knoten umgehen kann. Im unten gezeigten Diagramm ist ein Stressfaktor zu sehen, der Werte zwischen 0 und 3 annehmen kann. 0 bedeutet, dass der Knoten keine zusätzliche Last verkraften muss, 3 bedeutet, dass der Knoten vollständig ausgefallen ist. Für die Werte dazwischen liegen keine genauen Definitionen vor. Im ersten Versuch wird in einem System, dass aus vier Arbeitern besteht, ein Arbeiter immer stärker belastet. Die nachfolgende Grafik zeigt das Verhalten von Osprey. Der Backupfaktor ist mit k bezeichnet. Der Anstieg der Ausführungszeit von s=0 zu s=3 ist etwa 4/3, was dem theoretisch zu erwartenden Wert entspricht. Schaut man genau hin, so sieht man, dass mit steigendem k auch die Ausführungszeit ansteigt. Eine Erklärung hierfür bleiben die Osprey- Entwickler schuldig. In weiteren Testreihen zeigten die Osprey-Entwickler außerdem, dass Osprey sich bei Überlastung mehrerer Arbeiter ähnlich verhält und die Arbeit möglichst auf die anderen Arbeiter verteilt und auch, dass die Verteilung bei Ausfall eines Knotens mitten in einer laufenden Abfrage dynamisch angepasst wird.

162 Thema 10 Osprey Markus Zander 16 Abb. 6: Laufzeit bei steigender Last eines Knotens; Quelle (Christopher Yang 2010) Vergleich der Ausführungsplanungs-Algorithmen Wurden in die Algorithmen aufgrund theoretischer Überlegungen verglichen, folgt hier der experimentelle Vergleich. Die Entwickler von Osprey fanden heraus, dass bei der von ihnen verwendeten homogenen Hardware-Umgebung und ohne zusätzliche Last auf den einzelnen Knoten alle drei getesteten Algorithmen (Zufällig, LQF, Majorisierung) ungefähr das gleiche Ergebnis liefern. Sobald ein Knoten überlastet ist, sind LQF und Majorisierung rund 10% besser als die Zufallsauswahl. Der erwartete Vorteil des Majorisierungs-Algorithmus von rund 19% gegenüber LQF trat nicht ein im Gegenteil: Majorisierung war minimal langsamer als LQF. Die Entwickler vermuten den höheren Berechnungsaufwand bei der Majorisierung als Ursache, gehen dieser Vermutung aber nicht weiter nach. 5 Zusammenfassung 5.1 Vorteile Osprey ermöglicht durch das Aufteilen der Daten auf mehrere Knoten eine parallelisierte Ausführung einer Abfrage und erreicht dadurch einen linearen Geschwindigkeitszuwachs. Der Mehraufwand, der hauptsächlich aus dem Aufteilen der Abfragen und dem Zusammenführen der Teilergebnisse besteht, ist im Vergleich zum Aufwand der eigentlichen Abfrage klein und somit zu verschmerzen. Die bereits erwähnte Parallelisierung bringt, unterstützt durch den Ausführungsplaner, einen Lastausgleich der Knoten und eine Fehlertoleranz mit, die herkömmlich verteilte DBMS so nicht leisten können. 5.2 Kritische Betrachtung Trotz dieser Vorteile darf bezweifelt werden, ob Osprey es jemals in den Produktiveinsatz schaffen wird. Zu sehr merkt man ihm die Entstehung am runden Tisch an. Im jetzigen Zustand eignet sich Osprey nur für Datenbanken im Stern-Schema. Wäre dies im angepeilten Data- Warehouse-Einsatz noch akzeptabel, wiegen die weiteren Einschränkungen schwerer:

163 17 Markus Zander Thema 10 Osprey 1. Konkurrierende Schreibzugriffe können das Ergebnis verfälschen. Die Entwickler von Osprey räumen diese Möglichkeit zwar ein, halten sie aber für unkritisch, da es im OLAP-Umfeld aufgrund der starken Aggregation auf ein, zwei Datensätze mehr oder weniger nicht ankäme. Dieser Punkt wird natürlich erst relevant, wenn Osprey Schreibzugriffe unterstützt. 2. Der Ausfall des Koordinators legt das gesamte System lahm. Auf diese Möglichkeit gehen die Entwickler nicht ein. 3. Eine Auswertung der Fehlermeldungen der Teilknoten scheint zu fehlen, was zu Endlosschleifen führen kann. Dieser Punkt wird von den Osprey-Entwicklern nicht erläutert. 4. Eine Strategie für die geschickte erneute Zuweisung bereits zugewiesener Teilabfragen scheint ebenso zu fehlen. Auch hierauf gehen die Osprey-Entwickler nicht ein. Nicht zuletzt muss gefragt werden, ob das System mit einem zentralen Koordinator von den Entwicklern zu Recht als shared nothing -Ansatz bezeichnet wird. Außerdem sind die unter 5.3 beschriebenen Erweiterungen für einen Produktiveinsatz unumgänglich. Osprey ist auch nicht für das OLTP-Umfeld geeignet, da es hier meist um relativ kleine Abfragen geht, bei denen Osprey seine Vorteile nicht ausspielen kann und die durch die Einschränkungen bei der Formulierung der Abfragen bis zur Unmöglichkeit eingeschränkt würden. Dies sehen die Entwickler von Osprey jedoch auch nicht als Zielanwendung. 5.3 Ausblick Einige der erwähnten Einschränkungen waren den Entwicklern von Osprey durchaus bewusst und sie schrieben in (Christopher Yang 2010) und (Yen 2010), dass folgende weitere Arbeiten erforderlich seien: 1. Umgang mit verschachtelten joins oder self-joins 2. Verbesserung des Ausführungsplaners, damit die Vorteile der Caches auf den einzelnen Knoten genutzt werden können. 3. Verbesserte Abschätzung des Aufwandes in den Partition Work Queues nach dem realen Aufwand (Abfragen mit leerem Ergebnis vs. Abfragen mit großem Ergebnissatz). 4. Implementierung von updates, inserts, deletes Leider muss man derzeit davon ausgehen, dass die Arbeiten an Osprey nach Veröffentlichung des Papers eingestellt wurden. Auch die Entwickler selbst waren nicht für eine Stellungnahme zu erreichen.

164 Thema 10 Osprey Markus Zander 18 6 Literaturverzeichnis Christopher Yang, Christine Yen, Ceryen Tan, Samuel R. Madden. Osprey: Implementing MapReduce-Style Fault. Massachusetts: CSAIL, MIT, Golubchik, Leana et al. Chained Declustering: Load balancing and robustness to skew and failures (Zugriff am ). Hui-I Hsiao, David J. DeWitt. Scientific Literature Digital Library and Search Engine. Chained Declustering: A New Availability Strategy for Multiprocssor Database machines B202B028?doi= &rep=rep1&type=pdf (Zugriff am ). Jeffrey Dean, Sanjay Ghemawat. MapReduce: Simplified data processing on large clusters. COMMUNICATIONS OF THE ACM, : Mönch, Prof. Dr. Lars. Grundprinzipien betrieblicher Informationssysteme. Betriebliche Informationssysteme. Bd. 1. Hagen: FernUniversität in Hagen, Pat O'Neil, Betty O'Neil, Xuedong Chen. UMASS Boston. Department of Computer Science (Zugriff am ). PostgreSQL Global Development Group. PostgreSQL (Zugriff am ). Teradata Corporation. Teradata Purpose-Built Platform Pricing. Teradata Corporation (Zugriff am ). Yen, Christine. Osprey as0z5uf0m97zuf8yidq (Zugriff am ).

165 Fernuniversität in Hagen Seminar in Informatik (1912, SS2011) Map Reduce Map Reduce Merge Marcel Endberg 1. Einführung: Suchmaschinen verarbeiten und verwalten enorme Datenmengen, welche sie im gesamten World Wide Web gesammelt haben. Damit diese Aufgaben gleichzeitig effizient und dennoch kostengünstig ausgeführt werden können, sind Suchmaschinen in riesigen shared-nothing Clustern wie parallele DV-Systeme aufgebaut. Diese Cluster bestehen aus herkömmlicher Handelsware und nicht aus teuren Serversystemen. DBMS sind normalerweise mit viel zu vielen unnötigen Features gerade für spezielle Applikationen wie z.b. Suchmaschinen ausgestattet. Suchmaschinenanbieter sind daher einen eigenen Weg gegangen und haben eine "vereinfachte" Infrastruktur für verteilten Speicher und parallele Programmierung entwickelt und betreiben diese erfolgreich. Dazu gehören u.a. Google File System GFS [1], Map Reduce [2], Big Table [3] oder Microsofts Dryad [4]. Dieser einfachen Infrastruktur folgt auch die gesamte Datenverarbeitung bei Map Reduce: a) Eine Map-Funktion verarbeitet ein Schlüssel/Wert Paar als Eingabe und liefert als Ausgabe eine Liste von Schlüssel/Wert Paaren als Zwischenergebnis für die zugewiesenen Reducer. b) Eine Reduce-Funktion verschmilzt die Zwischenergebnisse mit jeweils gleichem Schlüssel und liefert danach seine Ausgabe. Map Reduce ist mit seinen beiden Primitiven "Map" und "Reduce" ausreichend allgemein gehalten, um eine Vielzahl an Aufgaben zu meistern. Das Hauptaugenmerk des Map Reduce Frameworks liegt jedoch in der Bearbeitung von homogenen Datensätzen. Wie in [5] gezeigt wird, passt der Join mehrerer heterogener Datensätze nicht so ganz in das Konzept von Map Reduce. Obwohl technisch mit den beiden Primitiven Map und Reduce realisierbar, lohnt sich der Aufwand durch zusätzliche Map und Reduce Schritte nicht. Kurz gesagt: Die Bearbeitung von Datenrelationen, worin ein RDBMS Map Reduce eindeutig überlegen ist, ist nicht gerade die Stärke von Map Reduce. Für Suchmaschinen können bereits viele Datenverarbeitungsprobleme mit diesem simplen Map Reduce Framework gelöst werden. Allerdings gibt es auch einige Aufgaben, welche am besten als Joins modelliert werden: Eine Suchmaschine z.b. speichert ihre gesammelten URLs mit deren Inhalt in einer Crawler- Datenbank. Invertierte Indexe werden in einer Index-Datenbank gespeichert und Klicks oder Ausführungslogs in verschiedenen Log-Datenbanken. URL Links werden mit diversen Eigenschaften wie z.b. Inlinks und Outlinks in einer Webgraph-Datenbank gespeichert. Diese Datenbanken haben riesige Ausmaße und sind über mehrere Cluster verteilt. Bei der Erstellung der Datenbanken greifen diese wiederum untereinander auf sich zu:

166 Die Index-Datenbank benötigt Daten aus der Crawler- und Webgraph-Datenbank, die Webgraph- Datenbank wiederum benötigt Daten aus der Crawler Datenbank und einer früheren Version der Webgraph-Datenbank usw. Diese Aufgaben sind mit dem Standard Map Reduce Framework kaum handhabbar. Die Verarbeitung von Datenrelationen ist jedoch allgegenwärtig - vor allem in unternehmerischen ITsystemen. Ein Fokus der populären relationalen Algebra und RDBMS ist die effiziente Modellierung und Verwaltung relationaler Daten. Neben Suchmaschinenanbietern sind auch andere Bereiche an einem Join-fähigen Map Reduce Framework interessiert: Beispielsweise haben Fluglinien und Hotelketten beide riesige Datenbanken. Das Verschmelzen dieser Datenbanken erlaubt es Data Minern umfassendere Regeln aufzustellen, als sie es bei der jeweils nur individuellen Betrachtung der Datenbanken könnten. Viele traditionelle RDBMS wurden mittlerweile erfolgreich in OLAP Systemen eingesetzt, jedoch stellt ein Join-fähiges Map Reduce Framework eine kostengünstige Alternative dar. Eine Optimierung des Map Reduce Frameworks besteht nun darin, es zu erweitern und relationale Algebra zu integrieren. Dabei soll jedoch die existierende Allgemeinheit und Einfachheit des Map Reduce Frameworks nicht angetastet werden. Das Map Reduce Framework (Abb. 1) wird zum Map Reduce Merge Framework (Abb. 2) erweitert. Dieses neue Framework ermöglicht die gleichzeitige Verarbeitung heterogener Datensätze. Außerdem wird eine neue Merge-Phase hinzugefügt, welche zwei Ausgaben miteinander verschmelzt. Die endgültige Ausgabe erfolgt nun nicht mehr nach der Reduce-Phase, sondern nach der Merge-Phase. Abb.1: Map Reduce Datenfluss Ein Treiberprogramm (Driver) initiiert einen Koordinator- Prozess (Coordinator), welches Mapper und Reducer verwaltet. Jeder Mapper liest Datenfragmente vom GFS, führt benutzerdefinierte Logiken aus und erzeugt mehrere Ausgabe-Partitionen, jeweils eine pro Reducer. Ein Reducer liest Daten von jedem Mapper, sortiert und gruppiert die Daten und führt ebenfalls benutzerdefinierte Logiken aus. Die Ausgabe erfolgt auf GFS. Abb. 2: Map Reduce Merge Datenfluss Der Koordinator verwaltet für zwei verschiedene Sätze Mapper und Reducer. Nachdem die Aufgaben erledigt sind startet er eine Reihe von Mergern, welche die Ausgaben von ausgewählten Reducern lesen und die Daten mit benutzerdefinierten Logiken verschmelzen. Eine Optimierung ist bereits implementiert: ReduceMerge (Erläuterung folgt in Abschnitt 6). Die Map Reduce Philosophie der Einfachheit bleibt bestehen, das Framework wird jedoch um eine Merge-Phase erweitert. Diese Erweiterung ermöglicht die effizientere und einfachere Verarbeitung heterogener Datensätze. Heterogene Datensätze sind dabei solche Datensätze, die in ihrem Aufbau teils große Unterschiede ausweisen. Die Attribute zweier Eingaberelationen sind z.b. bis auf ein gemeinsames Schlüsselattribut grundverschieden.

167 Map Reduce Aufgaben werden normalerweise nacheinander ausgeführt und bilden so einen linearen Arbeitsablauf. Das Hinzufügen der Merge-Phase kann dabei zu neuen, hierarchischen Arbeitsabläufen für einen kompletten Datenverarbeitungsprozess führen. Ein Map Reduce Merge Ablauf ist vergleichbar mit dem Ablaufplan eines RDBMS, allerdings können Entwickler hier eigene Programmlogiken einbauen und Map Reduce Merge ist speziell für die parallele Datenverarbeitung ausgelegt. In einer Parallelen Konfiguration können relationale Operatoren so modelliert werden, dass sie die drei Primitive Map, Reduce und Merge in verschiedenen Kombinationen nutzen. In einer korrekten Konfiguration können diese drei Primitive zur Implementierung einiger Join-Algorithmen genutzt werden: Sort-Merge, Hash und Block Nested Loop. Weitere Informationen zu diesen Joins folgen in Abschnitt Homogenisierung: Ohne diese neue Merge-Komponente ist es dem Standard-Modell zwar möglich, heterogene Datensätze zu verarbeiten, der Aufwand ist allerdings erheblich. Datensätze müssten dafür zunächst in einem aufwendigen Prozess "homogenisiert" werden. Außerdem wäre diese Methode lediglich auf solche Anfragen anwendbar, die sich als Equi-Joins übertragen lassen. Der Prozess der "Homogenisierung" sieht im Einzelnen wie folgt aus: 1. Jeweils ein Map Reduce Durchlauf pro Datensatz ist zur Vorbereitung notwendig. 2. Jeder dieser bearbeiteten Datensätze erhält eine Markierung für die Datenquelle. 3. Ein Schlüsselattribut wird aus diesen Daten extrahiert. Dieses Schlüsselattribut müssen alle Datensätze gemein haben. 4. Alle so bearbeiteten Datensätze haben nun zwei gleiche (neue) Attribute: Schlüssel und Datenquelle. Diese Daten sind nun "homogenisiert". 5. Ein finaler Map Reduce Durchlauf ist nun auf diese bearbeiteten Datensätze erforderlich. 6. Benutzerdefinierte Logiken können aus den Daten deren Quellen herauslesen, so dass Daten verschiedener Quellen verschmolzen werden können. Dieses Verfahren benötigt erheblich mehr Speicherplatz und sehr viel Map Reduce Kommunikation. Außerdem ist dieses Verfahren auf Equi-Join Anfragen beschränkt. Es liegt daher nahe, dass ein effizienterer Weg für die Bearbeitung heterogener Datensätze gefunden werden muss. 3. Map Reduce Merge: Das Map Reduce Merge Modell ermöglicht die Verarbeitung mehrerer heterogener Datensätze. Die Signaturen der Map Reduce Merge Primitive sieht wie folgt aus, wobei α, β, γ unterschiedliche Datenstämme repräsentieren (also Daten verschiedener Quellen, z.b. aus verschiedenen Datenbanken wie Index-Datenbank, Crawler-Datenbank etc.): Map: (k 1,v 1 )α [(k 2,v 2 )]α Reduce: (k 2,[v 2 ])α (k 2,[v 3 ])α Merge: (k 2,[v 2 ])α, (k 3,[v 4 ])β [(k 4,v 5 )] γ In diesem neuen Modell transformiert die Map-Funktion ein Schlüssel/Wert Paar (k 1,v 1 ) als Eingabe zu einer Liste von Schlüssel/Wert Paaren [(k 2,v 2 )] als Ausgabe. Die Reduce-Funktion sammelt die Liste aller Werte [v 2 ], welche mit dem Schlüssel k 2 assoziiert sind und erstellt eine Liste von Werten [v 3 ], welche ebenfalls mit dem Schlüssel k 2 assoziiert ist. Eingaben und Ausgaben beider Funktionen haben jeweils denselben Datenstamm, also die gleiche Datenquelle (hier: α). Diese Map und Reduce Vorgänge werden gleichzeitig auf einem anderen Datenstamm (hier: β) durchgeführt, wobei als Ausgabe der Reduce-Funktion (k 3,[v 4 ])β resultiert. Ein Merger kombiniert nun die beiden Reducer Ausgaben basierend auf den Schlüsseln k 2 und k 3 zu einer Liste von Schlüssel/Wert Paaren [(k 4,v 5 )] und bildet damit einen eigenen Datenstamm (hier: γ).

168 Ein Sonderfall tritt ein, wenn die Datenstämme beider paralleler Map Reduce Durchläufe gleich ist (also α = β). In diesem Fall führt die Merge-Funktion einen Self-Merge durch, welches vergleichbar mit dem Self-Join der relationalen Algebra ist. Die Map und Reduce Funktionen des neuen Modells entsprechen weitestgehend denen des alten Map Reduce Modells. Die einzigen Unterschiede sind die Datenstämme und die Ausgabe der Reducer, welche nun eine Schlüssel/Werte Liste erstellt statt lediglich einer Liste von Werten. Diese Änderungen sind notwendig, da die Merge-Funktion nach Schlüsseln organisierte (also partitionierte und dann sortierte oder gehashte) Datensätze als Eingabedaten benötigt. Im ursprünglichen Map Reduce Modell ist die Ausgabe nach dem Reducer final und die Weiterleitung des Schlüssels k 2 ist nicht notwendig. Der jeweilige Schlüssel wird also zunächst vom Mapper an den Reducer weitergegeben, danach an den Merger. Dieses Vorgehen stellt sicher, dass die Daten nach dem gleichen Schlüssel partitioniert und danach sortiert (oder gehasht) werden, bevor diese in geeigneter Weise durch einen Merger verschmolzen werden können Beispiel: Ein Map Reduce Merge Durchlauf soll nun an einem kleinen, einfachen Beispiel demonstriert werden. Es zeigt auch, wie Map, Reduce und Merge miteinander arbeiten. In diesem Beispiel gibt es zwei Ausgangstabellen: Angestellte und Abteilung. Das Schlüsselattribut der Angestelltentabelle ist ANG_id, das Schlüsselattribut der Abteilungstabelle ABT_id. Angestellte ANG_id ABT_id Bonus 1 B Innovationspreis ( 100) 1 B ANG des Monats ( 50) 2 A NULL ( 0) 3 A Fleißpreis ( 150) 3 A Innovationspreis ( 100) Map: Bonus berechnen ANG_id ABT_id Bonus 1 B B 50 2 A 0 3 A A 100 ANG_id ABT_id Bonus 2 A 0 3 A B 150 Abb. 3: Beispiel eines Joins zweier Tabellen und Berechnung von Angestellten-Boni Abteilung ABT_id Bonusfaktor A 1.1 B 0.9 ABT_id Bonusfaktor B 0.95 A 1.15 ABT_id Map: Bonusfaktoren abrufen Reduce: Sortierung nach ABT_ID, modifiziert Bonusfaktoren Bonusfaktor A 1.15 B 0.95 Reduce: Sortierung nach (ABT_ID, ANG_ID) und Aufsummierung aller Boni Merge: Ein Sort-Merge Merger verschmelzt beide Reducer Ausgaben anhand des Schlüssels ABT_id und berechnet endgültige Boni ANG_id Bonus

169 Die Tabelle Angestellte bildet unseren Datenstamm α, die Tabelle Abteilung den Datenstamm β. Die Ausgabe vom Merger bildet einen eigenen Datenstamm γ. In diesem Beispiel werden die Daten zweier Tabellen per Join verbunden und die Boni jedes Angestellten berechnet. Bevor die Daten beider Tabellen vom Merger verschmolzen werden können, werden die Daten von einem Paar Mapper und Reducer bearbeitet. Der Ablauf ist in Abb. 3 dargestellt. Auf der linken Seite liest ein Mapper die Daten der Tabelle Angestellte und errechnet den Bonus für jeden Eintrag. Ein Reducer erhält die Daten vom Mapper und summiert alle Boni eines jeden Angestellten auf. Außerdem sortiert der Reducer die Daten nach ABT_id, dann nach ANG_id. Auf der rechten Seite liest ein Mapper die Daten der Tabelle Abteilung und berechnet die einzelnen Bonusfaktoren. Ein Reducer sortiert diese Daten nach ABT_id. Am Ende verschmelzt ein Merger die Ausgaben der beiden Reducer nach dem Schlüssel ABT_id und errechnet anhand der Bonusfaktoren die endgültigen Boni jedes Angestellten. Pseudocode für Mapper und Reducer jeder Seite sind in den Algorithmen 1-4 angegeben. Der Code für Merger wird in Abschnitt näher erläutert: Alg. 1: Map Funktion (Angestellten-Datensatz) 1: map(const Key& key, /* emp id */ 2: const Value& value /* emp info */) { 3: emp id = key; 4: dept id = value.dept id; 5: /* compute bonus using emp info */ 6: output key = (dept id, emp id); 7: output value = (bonus); 8: Emit(output key, output value); 9: } Alg.3: Reduce Funktion (Angestellten-Datensatz) 1: reduce(const Key& key, /* (dept id, emp id) */ 2: const ValueIterator& value 3: /* an iterator for a bonuses collection */) { 4: bonus sum = /* sum up bonuses for each emp id */ 5: Emit(key, (bonus sum)); 6: } Alg. 2: Map Funktion (Abteilungs-Datensatz) 1: map(const Key& key, /* dept id */ 2: const Value& value /* dept info */) { 3: dept id = key; 4: bonus adjustment = value.bonus adjustment; 5: Emit((dept id), (bonus adjustment)); 6: } Alg. 4: Reduce Funktion (Abteilungs-Datensatz) 1: reduce(const Key& key, /* (dept id) */ 2: const ValueIterator& value 3: /* an iterator on a bonus adjustments collection */) { 4: /* aggregate bonus adjustments and 5: compute a final bonus adjustment */ 6: Emit(key, (bonus adjustment)); 7: } 3.2. Implementierung: Das Map Reduce Merge Framework übernimmt mit Ausnahme kleiner Signatur-Änderungen komplett die Komponenten von Map Reduce. Das neue Modell liefert zusätzlich weitere Komponenten: Eine Merge-Funktion, Prozessor-Funktion, Partitions-Selektor und konfigurierbare Iteratoren. Diese neuen Komponenten sollen nun etwas näher erläutert werden. Die Merge-Funktion (Merger) kann genau wie Map und Reduce mit benutzerdefinierten Datenverarbeitungslogiken ausgestattet werden. Während eine Map-Funktion ein Schlüssel/Wert Paar verarbeitet und die Reduce-Funktion eine nach einem Schlüssel geordnete Werteliste, verarbeitet der Merger zwei Schlüssel/Werte-Paare. Diese Schlüssel/Wert-Paare sind durch deren angegebenen Datenstamm eindeutig unterscheidbar. In der Merge-Phase wollen Benutzer je nach Datenquelle eventuell verschiedene Logiken für die Datenverarbeitung implementieren. Ein Beispiel sind die Build und Probe Phasen eines Hash-Joins. Die Build-Logik betrifft dann z.b. nur eine Tabelle und Probe die andere. In solchen Fällen hilft die Prozessor-Funktion, welche nichts anderes als eine benutzerdefinierte Funktion darstellt, die lediglich die Daten einer bestimmten Quelle verarbeitet. Beim Merger können insgesamt zwei Prozessor- Funktionen implementiert werden, da dieser Daten aus zwei verschiedenen Quellen verarbeitet.

170 Nachdem die Map- und Reduce-Aufgaben beendet sind, startet ein Map Reduce Merge-Koordinator (s. Abb. 2) die Merger. Sobald ein Merger gestartet wird, erhält er eine eindeutige Merger-Nummer. Mit Hilfe dieser Nummern kann ein benutzerdefiniertes Modul - der Partitions-Selektor - bestimmen, von welchen Reducern ein Merger seine Eingabedaten erhält. Mapper und Reducer erhalten dafür ebenfalls eindeutige Nummern: Die Mapper erhalten eine Nummer je nach Datenfragment, das sie bearbeiten. Die Reducer hingegen erhalten eine Nummer je nach Eingabebehälter, in denen die zugewiesenen Mapper ihre Ausgaben partitionieren und speichern. Im normalen Map Reduce Framework sind diese Nummern nichts anderes als systeminterne Details, aber im Map Reduce Merge Framework können Benutzer diese Nummern verwenden, um Eingaben und Ausgaben zwischen Mergern und Reducern zu steuern. Merger können genau wie Mapper und Reducer so behandelt werden, als hätten sie logische Iteratoren, welche Daten aus Eingaben lesen. Jeder Mapper und Reducer hat einen logischen Iterator, welcher vom Anfang bis zum Ende des jeweiligen Datenflusses mitläuft (standardmäßig wird ein Iterator um 1 erhöht). Ein Merger liest Daten von zwei unterschiedlichen Quellen, daher kann ein Merger zwei solcher Iteratoren enthalten. Diese beiden Iteratoren rücken üblicherweise wie ihre Mapper- oder Reduce-Pendants vor. Deren relative Bewegung gegeneinander kann jedoch dazu benutzt werden, benutzerdefinierte Merge-Algorithmen zu implementieren. Unser Map Reduce Merge Framework stellt hierzu ein eigenes Modul zur Verfügung (Iterator-Manager), welches die Bewegungen dieser konfigurierbaren Iteratoren ermöglicht. Um diese Iteratoren zu koordinieren wird ein Merge-Phase Treiber benötigt, dessen Pseudocode in Algorithmus 5 angegeben ist: Alg. 5: Merge-Phase Treiber. 1: PartitionSelector partitionselector; // user-defined logic 2: LeftProcessor leftprocessor; // user-defined logic 3: RightProcessor rightprocessor; // user-defined logic 4: Merger merger; // user-defined logic 5: IteratorManager iteratormanager; // user-defined logic 6: int mergernumber; // assigned by system 7: vector<int> leftreducernumbers; // assigned by system 8: vector<int> rightreducernumbers; // assigned by system 9: // select and filter left and right reducer outputs for this merger 10: partitionselector.select( mergernumber, 11: leftreducernumbers, 12: rightreducernumbers); 13: ConfigurableIterator left = /*initiated to point to entries 14: in reduce outputs by leftreducernumbers*/ 15: ConfigurableIterator right =/*initiated to point to entries 16: in reduce outputs by rightreducernumbers*/ 17: while(true) { 18: pair<bool,bool> hasmoretuples = 19: make pair(hasnext(left), hasnext(right)); 20: if (!hasmoretuples.first &&!hasmoretuples.second) {break;} 21: if (hasmoretuples.first) { 22: leftprocessor.process(left key, left value); } 23: if (hasmoretuples.second) { 24: rightprocessor.process(right key, right value); } 25: if (hasmoretuples.first && hasmoretuples.second) { 26: merger.merge( left key, left value, 27: right key, right value); } 28: pair<bool,bool> iteratornextmove = 29: iteratormanager.move(left key, right key, hasmoretuples); 30: if (!iteratornextmove.first &&!iteratornextmove.second) { 31: break; } 32: If (iteratornextmove.first) { left++; } 33: if (iteratornextmove.second) { right++; } 34: } Die Aufgaben dieser vier Komponenten sollen nun anhand des Angestellten- und Abteilungs-Beispiels genauer dargestellt werden.

171 Merger In der Merge-Funktion können Benutzer eigene Logiken zur Datenverarbeitung implementieren. Der Merger bedient sich dazu zweier Datenquellen, nämlich der Reducer-Ausgaben der Angestelltentabelle und der Abteilungstabelle. Der folgende Algorithmus 6 zeigt im Pseudocode die Vorgehensweise des Mergers in unserem Beispiel: Alg. 6 Merge Funktion für den Angestellten-Abteilungs-Join 1: merge(const LeftKey& leftkey, 2: /* (dept id, emp id) */ 3: const LeftValue& leftvalue, /* sum of bonuses */ 4: const RightKey& rightkey, /* dept id */ 5: const RightValue& rightvalue /* bonus-adjustment */){ 6: if (leftkey.dept id == rightkey) { 7: bonus = leftvalue * rightvalue; 8: Emit(leftKey.emp id, bonus); } 9: } Die Aufgabe des Mergers besteht also darin, die Daten der Reducer per Join über die Abteilungs-ID zusammenzufügen. Dabei werden die erzielten Boni mit den entsprechenden Bonusfaktoren multipliziert und als Ergebnis erhalten wir eine dritte Tabelle (unser neuer Datenstamm γ) mit den endgültig berechneten Boni jedes einzelnen Angestellten Prozessoren Hier können Benutzer eigene Logiken zur Bearbeitung von Daten einzelner Quellen einfügen. Diese Prozessoren können nur angewandt, wenn der Hash-Join Algorithmus in der Merge-Funktion implementiert wurde (jeweils ein Prozessor für Build und Probe). Da in unserem Beispiel der Sort- Merge Algorithmus angewendet wird, bleiben diese Prozessoren leer Partitions-Selektor In einem Merger kann ein Benutzer bestimmen, welche Reducer-Partitionen überhaupt verarbeitet werden sollen. Nicht benötigte Partitionen werden dabei aus der Datenkollektion entfernt. Der Partitions-Selektor benötigt hierzu die Nummern von zwei Reducern und eine vom entsprechenden Merger, der die Ausgaben dieser beiden Reducer lesen und verschmelzen soll. Die Nummern der Reducer, die sich nicht mehr in der Datenkollektion befinden, werden dabei außer Acht gelassen Konfigurierbare Iteratoren Benutzer können den relativen Durchlauf der beiden logischen Iteratoren eines Mergers manipulieren. Dieses Vorgehen erlaubt eigene Merge-Algorithmen, öffnet allerdings auch Tür und Tor für ungewollte Endlosschleifen. Bei Algorithmen wie dem Nested-Loop Join sind Iteratoren so konfiguriert, dass sie sich innerhalb einer geschachtelter Schleife bewegen. Bei Algorithmen wie dem Sort-Merge Join wechseln sich Iteratoren ab, wenn sie die beiden Datensätze durchlaufen. Bei Algorithmen wie dem Hash-Join scannen die beiden Iteratoren ihre jeweiligen Daten in verschiedenen Durchgängen: Der erste scannt die Daten und erstellt die Hash-Tabelle (Build), der zweite scannt seine Daten und gleicht diese mit der zuvor erstellten Hash-Tabelle ab (Probe). 4. Map Reduce Merge Implementierung von Relationalen Join Algorithmen Der Join stellt den wahrscheinlich wichtigsten relationalen Operator dar. Drei der geläufigsten Join Algorithmen werden wir etwas genauer betrachten:

172 4.1 Sort-Merge Join Map Reduce ist sehr effektiv wenn es um die parallele Sortierung von Daten geht [2]. Bei der Konfigurierung des Frameworks können Benutzer angeben, dass die Mapper einen Range-Partitioner statt eines Hash-Partitioners verwenden sollen. Mit diesem auf Map Reduce basierenden Partitionierer kann das Map Reduce Merge Framework als ein paralleler Sort-Merge Join Operator implementiert werden. Die einzelnen Phasen sehen wie folgt aus: Map: Der Mapper verwendet einen Range-Partitioner (siehe Abb. 4), um die Daten in geordnete Behälter (Buckets) zu partitionieren. Jeder dieser Behälter deckt einen exklusiven Schlüsselbereich ab und wird genau einem Reducer zugeordnet. Reduce: Für jeden vorhandenen Datenstamm in der Kollektion liest ein Reducer alle ihm zugewiesenen Map-Partitionen ein. Diese Daten werden zu einem sortierten Datensatz zusammengefügt. Die Sortierung der Daten kann entweder komplett beim Reducer erfolgen - wenn nötig auch mit externen Sortierverfahren - oder bereits beim Mapper. Falls der Mapper diese Aufgabe übernehmen soll, so werden die Daten in den Partitionen sortiert, bevor sie an die Reducer übergeben werden. Der Benutzer kann selbst entscheiden, in welcher Funktion er die Sortierung durchführen lassen möchte. Merge: Ein Merger liest die Ausgaben zweier Reducer, wobei beide Ausgaben denselben Schlüsselbereich haben müssen. Da die Sortierung bereits beim Mapper oder Reducer erfolgt ist, muss der Merger sich lediglich noch um den Merge-Part von Merge-Sort kümmern Range-Partitioner Der Range-Partitioner wird in der Map-Funktion benutzt, um die Eingabedaten zu partitionieren. Die Daten werden in größtenteils gleichgroße Partitionen aufgeteilt, wobei jede Partition einen exklusiven Schlüsselbereich abdeckt. Diese Methode stellt außerdem sicher, dass ähnliche Daten in derselben Partition gespeichert werden. Die Range-Partitionierung wird häufig auch zur Vorsortierung vor einer kompletten Sortierung von Daten benutzt. Da mit dieser Methode beinahe eine Gleichverteilung der Daten in den Partitionen sichergestellt wird, wird auch die Arbeit der zugewiesenen Reducer gleichmäßig verteilt. Ein Beispiel einer solchen Partitionierung ist in Abb. 4 zu sehen. Die Partitionierung erfolgt über den Schlüssel "Alter". Jede Partition enthält einen exklusiven Schlüsselbereich und deckt somit einen gewissen Altersbereich ab. Der (Alters-)Schlüsselbereich ist in den jeweiligen Partitionen angegeben. Die Höhe eines Balkens spiegelt die Größe der jeweiligen Partition wieder, was gleichzeitig der Anzahl Datensätze in dieser Partition entspricht. Abb. 4: Range-Partitioner [6] Damit dieses Verfahren angewendet werden kann, benötigt man eine Range-Map. Die Erstellung einer Range-Map erfolgt mithilfe von probabilistischen Split-Techniken. Eine solche Technik wird z.b. in [8] beschrieben. Um die Bereichsgrenzen einer Partition zu bestimmen wird zunächst ein kleiner sortierter Teil-Datensatz übergeben. Mit dieser Datenprobe errechnet der Range-Partitioner daraufhin die endgültigen Bereichsgrenzen für den gesamten Datensatz.

173 4.2 Hash Join Ein wichtiger Aspekt in verteilten Systemen und parallelen Datenbanken ist die gleichmäßige Auslastung und Speichernutzung über alle Verarbeitungsknoten. Eine Strategie ist die Verteilung von Daten anhand ihrer Hash-Werte. Dieses Verfahren ist gerade bei Suchmaschinen und parallelen Datenbanken weit verbreitet und stellt gleichzeitig das Standard-Partitionierungsverfahren von Map Reduce dar [2]. Die Implementierung eines Hash-Joins im Map Reduce Merge Framework sieht die folgenden Aufgaben vor: Map: Zwei Mapper verwenden jeweils denselben Hash-Partitioner (siehe Abb. 5), um ihre Daten in geordnete Hash-Behälter zu partitionieren. Jede Partition wird genau einem Reducer zugewiesen. Reduce: Für jeden Datenstamm in der Kollektion liest ein Reducer alle ihm zugewiesenen Map- Partitionen ein. Die Daten werden mit jeweils derselben Hash-Funktion, die der Hash- Partitioner zum Partitioniern der Daten verwendet hat, in einer Hash-Tabelle gruppiert und zusammengefügt. Diese Hash-Sortierung stellt eine Alternative zum Standardverfahren dar. Eine Sortierung ist nicht mehr notwendig, jedoch muss nun eine Hash-Tabelle verwaltet werden (intern, sofern die Tabelle komplett in den Hauptspeicher passt, extern sonst). Merge: Ein Merger liest die Ausgaben zweier Reducer, wobei beide Ausgaben jeweils in gleichen Hash-Behältern liegen müssen. Eine Ausgabe wird als Build verwendet, die andere als Probe. Die Partitionierung und Sortierung erfolgte bereits bei den Mappern bzw. Reducern, so dass der Build-Datensatz recht klein ausfallen kann und ggf. komplett im Hauptspeicher per Hash-Join verschmolzen werden kann. Dies reduziert Zugriffszeiten enorm, daher sollte man unbedingt auf eine optimale (große) Anzahl an Reduce/Merge-Sätzen achten. Passt der Build-Datensatz nicht komplett in den Hauptspeicher, so erfolgt der Hash-Join extern Hash Partitioner Die Partitionierung der Werte erfolgt mittels einer Hash-Funktion über den oder die Schlüssel. Dazu untersucht der Hash-Partitioner einen oder mehrere Felder (die Hash-Schlüssel) einer Eingabe und verteilt Werte mit denselben Hash-Werten in dieselben Hash-Behälter (Buckets). Diese Methode stellt sicher, dass zusammenhängende Daten in derselben Partition gespeichert werden. Ein Beispiel ist das Entfernen von Duplikaten. Die Daten werden dabei anhand ihrer Hash-Werte partitioniert, wobei Werte mit gleichem Hash-Wert in derselben Partition abgelegt werden. Die Werte innerhalb jeder Partition werden anhand des Hash-Schlüssels sortiert, wobei doppelte Werte entfernt werden. Obwohl die Daten über viele Partitionen verteilt sind, stellt der Hash-Partitioner sicher, dass Werte mit gleichem Schlüssel in derselben Partition landen, um z.b. doppelte Einträge zu finden. Eine mögliche Partitionierung von Daten ist in Abb. 5 angegeben. Die Partitionierung erfolgt über den Schlüssel "Alter". Jede Partition enthält Daten mit denselben Hash-Werten. Die Hash-Werte sind in den jeweiligen Partitionen angegeben. Die Höhe eines Balkens spiegelt die Größe der jeweiligen Partition wieder, was gleichzeitig der Anzahl Datensätze in dieser Partition entspricht. Abb. 5: Hash-Partitioner [7]

174 Der Hash-Partitioner stellt nicht immer eine Gleichverteilung von Daten über alle Partitionen sicher. Ein Beispiel für eine ungleichmäßige Verteilung ist ein großer Datensatz mit Kundendaten, wobei Name, Telefon und Anschrift gespeichert sind. Ist der Schlüssel, anhand dessen die Daten partitioniert werden sollen z.b. die Postleitzahl (PLZ), so kann es durchaus zu einer ungleichmäßigen Verteilung kommen, wenn viele Kunden die gleiche PLZ haben. So können durchaus Engpässe entstehen, da einige Reducer (sehr viel) mehr Arbeit leisten müssen als andere. 4.3 Block-Nested Loop Join Dieser Join entspricht größtenteils dem Algorithmus des Hash-Joins. Anstatt einen Hash-Join im Hauptspeicher durchzuführen wird hier ein Nested-Loop benutzt. Map: siehe Hash-Join Reduce: siehe Hash-Join Merge: siehe Hash-Join. Hier wird allerdings ein Nested Loop-Join statt eines Hash-Joins verwendet. 5. Map Reduce Merge Implementierung von Relationalen Operatoren Wir nehmen für unser Modell an, dass ein Datensatz in eine Relation R mit Attributen (Schema) A abgebildet wird. In den Funktionen Map, Reduce und Merge wählen Benutzer die gewünschten Attribute aus und bilden damit zwei Teilmengen K (Schema von k) und V (Schema von v). Jedes Tupel t aus R besteht aus einem Satz mit zwei Feldern: k (key) und v (value). Mit diesen Annahmen lassen sich relationale Operatoren folgendermaßen implementieren: Projektion: Für jedes Tupel t = (k, v) der Eingaberelation kann der Benutzer einen Mapper bestimmen, der dieses Tupel in die projizierte Ausgabe t' = (k', v') transformieren soll. k', v' werden dabei durch die Schemata K' und V' geschrieben, wobei diese eine Teilmenge von A sind. Nur Mapper können eine Projektion durchführen und somit die Größe eines Datensatzes verringern. Aggregation: In der Reduce-Phase führen Map Reduce und auch Map Reduce Merge die Funktionen "sortby-key" und "group-by-key" aus, um sicherzustellen, dass die Eingaben eines Reducers ein Satz von Tupeln der Form t = (k, [v]) bilden. v entspricht dabei allen Werten des Schlüssels k. Ein Reducer kann nun Aggregationsfunktionen auf diese gruppierten Wertelisten ausführen, also COUNT, SUM, AVERAGE, MAXIMUM, MINIMUM und GROUP BY. Selektion: Die Selektion kann in allen drei Phasen (Map, Reduce oder Merge) erfolgen. Hängt die Selektion von Attributen einer Datenquelle ab, so wird die Selektion im Mapper implementiert. Hängt sie hingegen von Aggregationen ab, so wird die Selektion im Reducer implementiert. Sollte die Selektion von Attributen oder Aggregationen mehr als einer Datenquelle abhängen, so wird sie im Merger implementiert. Set Union (Vereinigung): Nehmen wir an, eine Set Union Operation (oder eine der beiden weiter unten behandelten Set Operationen) wird auf zwei Relationen angewandt. Im Map Reduce Merge Modell wird jede Relation zunächst von Map und Reduce bearbeitet und die sortierten sowie gruppierten Ausgaben eines Reducers werden an den zugewiesenen Merger weitergereicht.

175 Jeder Reducer kann Duplikate von Tupeln der gleichen Quelle sehr einfach überspringen. Die Mapper beider Datenquellen sollten denselben Range-Partitioner verwenden, damit die zugewiesenen Merger ausschließlich Daten desselben Schlüsselbereichs erhalten. Der Merger kann danach gleichzeitig über beide Eingaben iterieren und nur solche Tupel erstellen, die auch tatsächlich in den verschiedenen Eingaben vorkommen. Tupel, die nicht in beiden Eingaben gleichzeitig vorkommen, werden mit diesem Merger ebenfalls erstellt. Set Intersection (Schnitt): Die partitionierten und sortierten Map Reduce Ausgaben werden wie oben beschrieben an die Merger weitergeleitet. Ein Merger kann dann gleichzeitig über beide Eingaben iterieren und Tupel erstellen, die in beiden Reducer-Ausgaben enthalten sind. Set Difference (Differenz): Die partitionierten und sortierten Map Reduce Ausgaben werden wie oben beschrieben an die Merger weitergeleitet. Ein Merger kann dann gleichzeitig über beide Eingaben iterieren und Tupel erstellen, welche die Differenz beider Reducer-Ausgaben darstellen. Set-Operationen allgemein: Map und Reduce werden zum Sortieren und Gruppieren der Daten benötigt. Merger kümmern sich dann lediglich noch um die gewünschte Operation (siehe oben). Kartesisches Produkt: Ein Merger ist so konfiguriert, dass er eine Partition des ersten Reducers (F) und alle Partitionen des zweiten Reducers (S) erhält. Dieser Merger kann nun einen Nested Loop bilden, um die Daten der einzigen Partition von F mit allen Partitionen von S zu verschmelzen. Joins: Wurden oben bereits ausführlich beschrieben. 6. Optimierung: Phasen kombinieren Die Verarbeitung von Daten ist in der Regel nicht mit einem Map Reduce (-Merge) Durchlauf erledigt. Häufig kommt es vor, dass mehrere Durchläufe benötigt werden, wobei die Ausgaben eines Durchlaufs die Eingaben des darauffolgenden Durchlaufs sind. ReduceMap, MergeMap: Die Ausgaben von Reducern und Mergern werden normalerweise an den folgenden Mapper weitergereicht. Diese Ausgaben können direkt an den zugewiesenen Mapper weitergereicht werden, ohne die Daten zunächst temporär abzuspeichern. ReduceMerge: Ein Merger liest die Ausgaben zweier Reducer. Der zugewiesene Merger kann nun mit einem der beiden Reducer kombiniert werden und erhält dessen Ausgaben direkt, wobei nur noch die Ausgaben des zweiten Reducers wie gehabt per Fernzugriff eingelesen werden müssen. ReduceMergeMap: Eine direkte Kombination aus ReduceMerge und MergeMap wird zu ReduceMergeMap. ReduceMerge und ReduceMergeMap sind in Abb. 6 zu sehen. Das erste Bild zeigt das Standard-Map Reduce Vorgehen. Im zweiten Bild ist die direkte Verbindung zwischen einem Merger und einem seiner zwei zugewiesenen Reducer mit einer gestrichelten Verbindungslinie dargestellt. Im dritten Bild ist die Ausgabe der jeweils ersten Merger die Eingabe der darauffolgenden Mapper.

176 Abb. 6: Vergleich der Optimierungen ReduceMerge und ReduceMergeMap gegenüber dem Standard Map Reduce (-Merge) Modell. Der Datenstamm ist jeweils mit angegeben, wird im Standard Map Reduce Modell jedoch nicht benötigt. 7. Verbesserungen Neben den genannten Optimierungen können auch die folgenden Verbesserungen das Programmieren vereinfachen Map Reduce Merge Bibliothek Es gibt einige Varianten und Vorlagen für das Merge-Modul, z.b. solche mit eingebauten Join- Algorithmen. Die Selektoren und konfigurierbaren Iteratoren der geläufigsten Merge-Module können in einer Bibliothek zusammengefasst werden, so dass Benutzer einfacher auf die verschiedenen Varianten zugreifen können, ohne das Rad gleich neu erfinden zu müssen Map Reduce Merge Workflow Map Reduce folgt einem strengen Zwei-Phasen-Ablauf, so folgt z.b. die Reduce Phase nach einer Map-Phase. Benutzer können zwar bestimmte Standardkonfigurationen ändern, allerdings können einige Operationen wie z.b. die Partitionierung und Sortierung nicht übersprungen werden. Gerade wenn es um einfaches Debugging geht, möchte man für das Debugging unnötige Operationen überspringen, um den Ablauf zu beschleunigen. Auch wenn Benutzer lediglich das Mapping durchführen wollen (oder nur Reduce), müssen sie dennoch die anderen Phasen komplett durchlaufen. Dieses Vorgehen macht Map Reduce zwar simpel und erlaubt eine einheitliche Durchführung, erfahrene Benutzer wollen aber manchmal ihre eigenen Abläufe planen. Bei Map Reduce kann man den Workflow nicht großartig anpassen: Erst kommt Map, dann folgt Reduce. Nimmt man allerdings eine dritte Komponente wie dem Merge hinzu, so ergeben sich ganz neue Gestaltungsmöglichkeiten für einen eigenen Ablauf. Zwei Map Reduce Merge Workflows sind in Abb. 6 zu sehen, wobei weitere Varianten natürlich möglich sind. Eine Verbesserung von Map Reduce Merge besteht in der Bereitstellung einer konfigurierbaren API, um eigene Workflows zu erstellen. Eine Workflow-Variante könnte z.b. wie in Abb. 7 aussehen:

177 Abb. 7: Variante eines Map Reduce Merge Workflows. Neben den gezeigten hierarchischen Workflows in Abb. 6 und Abb. 7 sind auch rekursive Workflows denkbar. 8. Fazit: Das Map Reduce Merge Modell behält die vielen Vorteile des Map Reduce Modells bei und fügt neue relationale Operationen in dieses Modell ein. Es enthält einige neue und frei konfigurierbare Komponenten, was dem Benutzer ganz neue Möglichkeiten eröffnet. Ein nächster Schritt besteht nun darin, ein SQL-ähnliches Interface und Optimierer einzubinden. Schlussendlich wird die Idee der "Einfachheit", welche hinter dem Map Reduce Modell steckt, nicht eingeschränkt. 9. Literatur Text basiert auf: H. Yang, A. Dasdan, R. Hsiao, D. Parker: Map-Reduce-Merge: Simplified Relational Data Processing on Large Clusters, S , 2007 [1] S. Ghemawat, H. Gobioff, and S.-T. Leung: The Google file system. In SOSP, Seiten 29 43, 2003 [2] Dean, Ghemawat: Map Reduce: Simplified Data Processing on Large Clusters. In OSDI S , 2004 [3] F. Chang et al. Bigtable: A Distributed Storage System for Structured Data. In OSDI, Seiten , [4] M. Isard et al. Dryad: Distributed Data-Parallel Programs from Sequential Building Blocks. In EuroSys, 2007 [5] R. Pike et al. Interpreting the Data: Parallel Analysis with Sawzall. Scientific Programming Journal, 13(4): Seiten , [6] IBM InfoSphere Information Center, 06/2011 s.parjob.dev.doc/topics/rangepartitioner.html [7] IBM InfoSphere Information Center, 06/2011 s.parjob.dev.doc/topics/hashpartitioner.html [8] DeWitt, Naughton, Schneider: Parallel Sorting on a Shared- Nothing Architecture Using Probabilistic Splitting. In: Lu, Ooi, Tan: Query Processing in Parallel Relational Database Systems IEEE Computer Society Press, 1994

178 FernUniversität in Hagen - Seminar im Sommersemester 2011 MapReduce und Datenbanken Thema 12 Optimierung von Joins Referent: Oliver Schöner

179 12 Optimierung von Joins Oliver Schöner 1 Inhaltsverzeichnis 1 Problemlage und Zusammenfassung 2 2 Beispielhafte Erläuterung eines normalen Joins mit MapReduce 3 3 Joins mit mehr als zwei Relationen Hintereinanderausführung Mehrfachabbildung Kosten Mehrfachabbildung Hintereinanderausführung Kostenvergleich Der Algorithmus Problem Nullwerte Dominierte Attribute Spezialfälle Stern-Join Ketten-Join Ausblick und Kritik Geringer Nutzen Beschränkung auf Natural Joins Fragwürdigkeit des Kostenmodells Literatur 14

180 2 12 Optimierung von Joins Oliver Schöner 1 Problemlage und Zusammenfassung Auch und gerade bei sehr großen Datenbanken stellt sich die Frage, wie Joins effizient durchgeführt werden können. MapReduce bietet auch in diesem Bereich Lösungen, wie auf natürlichem Weg eine Vielzahl von Prozessoren nutzbringend eingesetzt werden kann. Im Folgenden werde ich zunächst darlegen, wie ein einfacher Join intuitiv mit MapReduce durchgeführt wird. Sodann diskutiere ich, welche Vorgehensweise sich empfiehlt, wenn mehr als zwei Relationen bei einem Join involviert sind. Kern dieses Vorgehens ist die Idee, bestimme Tupel auf mehrere Reduce-Prozesse abzubilden. Davon ausgehend werde ich das Kostenmodell diskutieren und einen einfachen allgemeinen Algorithmus vorstellen, der die Kosten generell zu minimieren trachtet. Die Zahl der Reduce-Prozesse zu bestimmen, auf die die Tupel einer Relation abgebildet werden, ist der Kern des Algorithmus. Dieser Algorithmus hat einige (theoretische) Probleme, deren Lösungen ich kurz vorstelle. Nach der Vorstellung zweier Spezialfälle und ein paar kritischer Überlegungen möchte ich die Diskussion eröffnen. 1 Es wird nun ein wenig mathematisch. Zur besseren Übersicht erläutere ich kurz die Konventionen, deren ich mich bediene: Großbuchstaben R, S, T... etc. bezeichnen Relationen. Kleinbuchstaben r, s,t... N bezeichnen die Zahl der Tupel der Relationen R, S, T... Großbuchstaben A,B,C... sind die Attribute, die in einer Relation vorhanden sind. Griechische Buchstaben α, β, γ... sind Werte von Attributen. Kleinbuchstaben a,b,c... N bezeichnen die Zahl der Reduce-Prozesse, auf die diejenigen Tupel abgebildet werden, in denen die Join-Attribute A,B,C... nicht vorkommen. Wir nennen a,b,c... Share-Variablen. Der Kleinbuchstabe k ist die Gesamtzahl der Reduce-Prozesse. Der Kleinbuchstabe h ist die Hashfunktion, mit der ein Key-Value-Paar auf einen Reduce- Prozess abgebildet wird. Der Kleinbuchstabe f bezeichnet die Kostenfunktion. Der Kleinbuchstabe p bezeichnet die Wahrscheinlichkeit, dass Tupel zweier Relationen gejoint werden. 1 Die Basis meiner Ausführungen bildet der Artikel von Afrati und Ullman [AU10]. Sie sind daraufhin konzipiert worden, ohne Zuhilfenahme dieses Artikels oder weiterer Literatur gelesen werden zu können. Wo dennoch auf [AU10] Bezug genommen wird, dient dies lediglich als Quellenangabe.

181 12 Optimierung von Joins Oliver Schöner 3 2 Beispielhafte Erläuterung eines normalen Joins mit MapReduce Wie kann nun ein normaler Join mit MapReduce durchgeführt werden? 2 Betrachten wir zwei Relationen, denen ein Attribut gemein ist: R(A,B) S(B,C). Der Join soll also über das Attribut B durchgeführt werden. Jedes Tupel der beiden Relationen R und S wird zunächst in ein Key-Value-Paar transformiert, wobei die Werte der B-Komponente, über die der Join ausgeführt wird, den Key bilden. Als Value werden Paare aus den Werten des jeweils anderen Attributs und der Relation verwendet. Es entstehen somit Key-Value-Paare der Form (β 1,(α 1,R)),...,(β r,(α r,r)),(β r+1,(γ r+1,s)),...,(β r+s,(γ r+s,s)). Beispiel: Sind A-Werte Strings, B-Werte natürliche Zahlen und befindet sich das Tupel (Heinrich, 8) in der Relation R, so wird daraus das Key-Value-Paar (8,(Heinrich, R)). Nun wenden wir unsere Hashfunktion h auf jeden B-Wert an (im Beispiel auf 8, es wird der Wert h(8) berechnet). Die Hash-Funktion sorgt dafür, dass alle entstandenen Key-Value-Paare auf die maximal k zur Verfügung stehenden Reduce-Prozesse verteilt werden. Wir nehmen einfach an, wir hätten eine geeignete Hash-Funktion h, die gut streut. Tupel mit gleichen B-Werten werden auf ein und denselben Reduce-Prozess abgebildet aber dass sich zwei Tupel im gleichen Reduce-Prozess befinden, heißt nicht, dass sie auch den gleichen B-Wert haben. Folgende Tabelle mit der Zuordnung der Key-Value-Paare könnte entstehen: Reduce-Prozess 1 Reduce-Prozess 2... Reduce-Prozess k (β x,(α x,r)) (β y,(γ y,s)) (β z,(γ z,s)) (β u,(α u,r))... Jetzt sehen wir auch den Grund, weswegen die Relationen R und S als Elemente in den Value-Teil unserer Tupel aufgenommen wurden. Sehen wir uns Reduce-Prozess Nr. 2 kurz an, dann erkennen wir, dass die ersten beiden Key-Value-Paare nicht darauf geprüft werden müssen, ob sie identische B-Werte haben sie stammen ja aus der gleichen Relation S. Geprüft werden muss nur, ob β y = β u und β z = β u ist. Ist nun zum Beispiel β y = β u, dann gelangt das Tupel (α u,β y = β u,γ y ) in das Ergebnis unseres Joins. Um bei unserem Beispiel von vorhin zu bleiben: Es enthalte die Relation R das Tupel (Heinrich, 8) und die Relation S die Tupel (8,Anne) und(7,berta). Wenn nun weiterhin h(8) = h(7) = 2 ist, dann werden alle drei Tupel auf den gleichen Reduce-Prozess Nr. 2 abgebildet. Da 8 7 ist, fließt das Tripel (Heinrich,8,Berta) nicht in das Ergebnis unseres Joins ein, wohl aber (Heinrich,8,Anne). 2 [AU10], 2.1

182 4 12 Optimierung von Joins Oliver Schöner Halten wir fest: Bei einem Join mit MapReduce werden Key-Value-Paare gebildet, wobei das oder die Attribute, über die der Join gebildet wird, den Key bilden. Auf den Key wird dann eine Hashfunktion angewendet und so das Key-Value-Paar auf einen Reduce-Prozess abgebildet; innerhalb jedes Reduce-Prozesses muss dann geprüft werden, ob Tupel aus unterschiedlichen Relationen den gleichen Key besitzen. 3 Joins mit mehr als zwei Relationen Wir wollen nun sehen, wie wir bei einem komplizierteren Join vorgehen, nämlich wenn mehrere Relationen involviert sind. Hier können wir entweder das soeben betrachtete Verfahren wiederholt anwenden oder, wie wir gleich sehen werden, ein ganz anderes. 3.1 Hintereinanderausführung Betrachten wir den zyklischen Join 3 R(A,B) S(B,C) T (A,C). Gemäß dem bisherigen Vorgehen könnten wir zunächst die Relationen R und S mit Key B joinen. Es entsteht einen Zwischenrelation (nennen wir sie RS) mit den Attributen A, B,C. Diese Zwischenrelation RS joinen wir dann mit der Relation T und Key (A,C). 4 Es entsteht die Ergebnisrelation RST, die wiederum die Attribute A,B,C enthält: R(A, B) S(B,C) = RS(A, B,C) RS(A,B,C) T (A,C) = RST (A,B,C). 3.2 Mehrfachabbildung Es gibt aber noch einen anderen Weg, und der besteht darin, jedes Tupel einer Relation auf mehrere Reduce-Prozesse abzubilden. Wir erinnern uns: Es gibt k Reduce-Prozesse. Betrachten wir ein beliebiges Tupel (α,β) R. Wir bilden nun dieses Tupel auf c verschiedene Reduce-Prozesse ab. Wir nennen diese Variable c, weil sie von dem Attribut C abhängt. Das Attribut C gehört nämlich zum Key (schließlich wird auch über C gejoint), doch in der Relation R kommt C gerade nicht vor. Doch welchen Wert hat c? Nun ist c sicher nicht größer als k; im Moment können wir uns irgendeinen Wert für c denken. Wir werden später einen Weg sehen, einen optimalen Wert für c zu finden. Im Folgenden wird die Nummer eines Reduce-Prozesses nicht als natürliche Zahl angegeben, sondern als ein Tripel (x,y,z) als ein Tripel deshalb, weil über drei Attribute gejoint wird. Auch hier möge ein Beispiel zur Veranschaulichung dienen: Angenommen, wir haben sechs Reduce-Prozesse 3 Für dieses Beispiel und die Grundidee siehe [Au10], Wobei dann die Hashfunktion h geeignet intelligent auf eine Kombination der Werte aus A und C angewendet werden muss.

183 12 Optimierung von Joins Oliver Schöner 5 zur Verfügung. Dann können wir diese Prozesse mit 1 bis 6 durchnummerieren. Wir können uns aber auch das Leben künstlich schwer machen und Tripel zur Nummerierung verwenden. Wenn x nur den Wert 1, y die Werte 1 oder 2 und z Werte zwischen 1 und 3 annehmen kann, dann ist die Nummer unseres Reduce-Prozesses durch ein Tripel (x,y,z) eindeutig bestimmt, es gibt = 6 Reduce-Prozesse: Nummer Reduce-Prozess als natürliche Zahl Nummer Reduce-Prozess als Tripel (x,y,z) 1 (1,1,1) 2 (1,1,2) 3 (1,1,3) 4 (1,2,1) 5 (1,2,2) 6 (1,2,3) Doch warum um Himmels willen machen wir das so kompliziert? Die Antwortet lautet, dass es die Zählung vereinfacht. Erinnern wir uns: Wir wollen das Tupel ((α,β),r) auf c verschiedene Reduce-Prozesse abbilden. Wir wenden nun unsere Hash-Funktion h auf α und β an und lassen den z-wert variabel, das heißt, z wird alle Werte zwischen 1 und c annehmen. Es landet dann unser Tupel ((α,β),r) in den Reduce-Prozessen (h(α),h(β),1),(h(α),h(β),2),...,(h(α),h(β),c). Noch einmal ein Beispiel: Sei wieder (Heinrich, 8) Element der Relation R. Weiterhin gelte h(8) = 1 und h(heinrich) = 2. Wie oben sei c = 3. Dann wird das Key-Value-Paar ((Heinrich,8),R) auf die drei Reduce-Prozesse (1,2,1), (1,2,2) und (1,2,3) abgebildet. Kehren wir wieder zur abstrakteren Sicht zurück: Für die Tupel aus den Relationen S und T gilt Entsprechendes wie für die Tupel aus R: Jedes (β,γ) S oder genauer: jedes Key-Value-Paar ((β,γ),s) wird auf die Reduce-Prozesse (x 1 x a,h(β),h(γ)) und jedes (α,γ) T auf die Reduce-Prozesse (h(α),y 1 y b,h(γ)) gemappt. Alle Attribute A, B,C sind in diesem Fall Teil des Keys (über alle Attribute wird gejoint). Wie viele Reduce-Prozesse gibt es nun insgesamt? Jeder Reduce-Prozess hat ja eine Nummer (x,y,z), wobei x den Minimalwert 1 und den Maximalwert a, y den Minimalwert 1 und den Maximalwert b und z den Minimalwert 1 und den Maximalwert c hat. Es gilt also: a b c = k. Innerhalb jedes Reduce-Prozesses müssen nun die Key-Value-Paare darauf geprüft werden, ob sie bezüglich des Keys übereinstimmen und aus verschiedenen Relationen stammen. Dass das Verfahren korrekt arbeitet, machen wir uns wie folgt klar. Damit es einen Treffer gibt, muss es Attributwerte α,β und γ geben mit (α,β) R, (β,γ) S und (α,γ) T. Es landet also das Key-Value-Paar ((α,β),r) in den Reduce-Prozessen (h(α),h(β),1...c). Das Key-Value-

184 6 12 Optimierung von Joins Oliver Schöner Paar ((β,γ),s) wird auf die Reduce-Prozesse (1...a,h(β),h(γ)) gemappt. Und schließlich landet ((α,γ),t ) in (h(α),1...b,h(γ)). Insbesondere befinden sich in dem Reduce-Prozess mit der Nummer (h(α), h(β), h(γ)) alle drei Key-Value-Paare, sodass dieser das korrekte Join-Resultat (α, β, γ) finden kann. 4 Kosten In unserem Kostenmodell zählen wir immer nur die Kosten, die bei der Kommunikation zwischen der Map- und der Reduce-Phase anfallen. 5 Die Kosten des Reduce-Prozesses selbst werden vernachlässigt (wir gehen davon aus, dass diese Operation im Hauptspeicher durchgeführt wird); es sei denn, das Ergebnis des Reduce-Prozesses wird per Mapping einem neuen Reduce-Prozess zugeführt. Das wird in unserem Beispiel R(A,B) S(B,C) T (A,C) gleich klarer werden, wenn wir die Kosten der Hintereinanderausführung mit denen der Mehrfachabbildung vergleichen. Betrachten wir zuerst den Join, bei dem die Tupel auf mehrere Reduce-Prozesse verteilt werden. 4.1 Mehrfachabbildung In unserem Beispiel R(A,B) S(B,C) T (A,C) müssen wir die Kosten einer jeden Relation addieren. Betrachten wir die erste Relation R. Sie hat r Tupel und jedes Tupel wird auf c Reduce- Prozesse abgebildet. Die Kosten für diese Relation betragen also r c. Übertragen wir diese Überlegung auf die anderen Tupel, so erhalten wir die Kosten 6 r c + s a +t b. Auf die Anzahl der Tupel einer Relation haben wir keinen Einfluss, wohl aber auf die Anzahl der Reduce-Prozesse, auf die die Tupel einer Relation abgebildet werden. Folglich können wir diesen Ausdruck als Funktion von a,b,c auffassen: f (a,b,c) = rc + sa +tb. Für diese Funktion gilt es nun ein Minimum zu finden. Da a b c = k ist, können wir diese Funktion auch schreiben als f (a,b,c) = rc + sa +tb λ(abc k), wobei λ eine beliebige reelle Zahl sei. Wir leiten nun diese Funktion nacheinander nach a, b und c ab und setzen das Ergebnis gleich 0, um das Minimum zu erhalten. 7 Daraus ergeben sich die drei Gleichungen 5 Siehe [AU10], Siehe [AU10], Afrati und Ullman erläutern diesen Punkt in [AU10] nicht näher, sondern setzen das Verfahren als gegeben voraus. Ob es wirklich tauglich ist, möchte ich an dieser Stelle offen lassen. Siehe auch meine Kritik unter 7.1.

185 12 Optimierung von Joins Oliver Schöner 7 s λbc = 0 t λac = 0 r λab = 0. Wir multiplizieren die erste Gleichung mit a, die zweite mit b und die dritte mit c und erhalten sa λabc = 0 tb λabc = 0 rc λacb = 0 oder, da abc = k ist, sa = λk tb = λk rc = λk. Wenn wir diese drei Gleichungen miteinander multiplizieren, erhalten wir rstabc = λ 3 k 3 oder λ = 3 rst k 2. An λ selbst sind wir natürlich nicht interessiert. Setzen wir diesen Wert für λ in die obigen Gleichungen sa = λk etc. ein, so erhalten wir sa = 3 rst k 2 k oder a = 3 rtk s 2 b = 3 rsk t 2 c = 3 stk r 2. Durch erneutes Einsetzen in unseren zu minimierenden Term rc + sa +tb sehen wir: rc + sa +tb = 3 3 rstk. Wir nehmen vereinfachend an, dass alle drei Relationen gleich groß sind, also r = s = t gilt. Dann sind die Gesamtkosten bei der Mehrfachabbildung zunächst 3r (jede Relation muss einmal komplett durchlaufen werden, um den Map-Key zu bilden) plus den Kommunikationskosten 3 3 r 3 k. Es ergeben sich die Gesamtkosten

186 8 12 Optimierung von Joins Oliver Schöner 3 r r 3 k = O(r 3 k). 4.2 Hintereinanderausführung Wir blicken noch einmal zurück, was wir bei der Hintereinanderausführung 8 des zyklischen Joins R(A, B) S(B,C) T (A,C) getan haben. Im ersten Schritt werden nur die beiden Relationen R und S durchlaufen; Kosten also 2r, sofern alle Relationen die Größe r haben. Bei dem Zwischenjoin R(A,B) S(B,C) wird im schlechtesten Fall jedes Tupel von R mit jedem Tupel von S daraufhin geprüft, ob sie bezüglich des Attributs B übereinstimmen. Die Wahrscheinlichkeit für einen Treffer sei mit p angegeben, folglich beträgt die Größe des Zwischenergebnisses unabhängig von dem verwendeten Join-Verfahren r 2 p. Im dritten Schritt kommt noch einmal die Größe r der Relation T hinzu. Wenn wir annehmen, dass r 2 p größer als 3r ist das wird der Fall sein, wenn die Relationen wie im richtigen Leben hinreichend groß sind, dann ergeben sich als Gesamtkosten 2r + r 2 p + r = O(r 2 p). 4.3 Kostenvergleich Die Gegenüberstellung von O(r 3 k) bei der Mehrfachabbildung und O(r 2 p) bei der Hintereinanderausführung zeigt: Wenn r 3 k r 2 p bzw. k (rp) 3 ist, dann ist die Mehrfachabbildung günstiger. 5 Der Algorithmus Aus dem konkreten zyklischen Join R(A, B) S(B,C) T (A,C) lässt sich leicht der allgemeine Fall 9 darlegen, wie ein gegebener Join durch Mehrfach-Mapping optimiert werden kann. Wir nehmen an, wir haben die Relationen R 1,...,R n und die Join-Attribute A 1,...,A m. 1. Bilde den Kostenausdruck Für ein beliebiges τ i gilt: τ 1 + τ τ n λ(a 1 a 2...a m k). τ i = r i a j j : A j / R i. Jedes r i wird also genau mit den Share-Variablen multipliziert, deren zugehörige Attribute nicht in der Relation R i enthalten sind. 2. Leite den Ausdruck nach allen a i ab, multipliziere die entstehenden Terme wieder mit a i und setze sie gleich 0. Es entstehen Gleichungen der Form 8 Siehe [AU10], Siehe [AU10], 3.1.

187 12 Optimierung von Joins Oliver Schöner 9 S ai = λk, wobei die S ai Summen sind. 3. Multipliziere alle Gleichungen miteinander und löse diese nach den Share-Variablen a i auf, wobei insbesondere alle λ eliminiert werden. 5.1 Problem Nullwerte Bei der Berechnung der Werte von a i kann es einige Probleme 10 geben. Es ist nämlich nicht garantiert, dass bei der Auflösung auch ganze Zahlen entstehen aber ganze Zahlen werden natürlich gefordert: Die Tupel einer Relation können keinesfalls auf dreieinhalb Reduce-Prozesse abgebildet werden, sondern nur auf drei oder vier. In einem solchen Fall liegt es natürlich nahe zu runden. Dass eine solche Näherung zu guten Ergebnissen führt, klingt zwar plausibel, ist aber keineswegs erwiesen. 11 Ein noch ernsthafteres Problem stellen die Fälle dar, in denen sich für bestimmte Share-Variablen der Wert 0 ergibt. Betrachten wir folgendes Beispiel: R(A,B,C) S(A,B,D) T (A,D,E) U(D,F). Wir identifizieren die Attribute A, B und D als Elemente des Map-Keys (nur über sie wird gejoint). Folglich ergibt sich die Kostenfunktion f (a,b,d) = rd + s +tb + uab λ(abd k). Die Ableitungen nach a, b und d mit anschließendem Multiplizieren und Nullsetzen führen zu den drei Gleichungen uab = λk tb + uab = λk rd = λk Es folgt tb = 0. Das kann natürlich nicht sein. Dies würde nämlich bedeuten, dass entweder t oder b gleich 0 ist. Die Relation T dürfte folglich entweder überhaupt keine Tupel enthalten oder die Tupel der beiden Relationen T und U würden auf keine Reduce-Prozesse abgebildet. Was ist hier das Problem? 10 [AU10], Insbesondere dann, wenn der Wert viel kleiner als 1 und nahezu 0 ist, stellt sich die Frage, wie man vorgehen soll. Es bleibt einem dann nichts anderes übrig, als diesen Wert gleich 1 zu setzen.

188 10 12 Optimierung von Joins Oliver Schöner 5.2 Dominierte Attribute Zumindest in vorliegendem Fall 12 lässt sich dieses Problem dadurch lösen, dass sogenannte dominierte Attribute aus dem Map-Key entfernt werden. Wir sagen: Ein Attribut X dominiert ein Attribut Y, wenn jede Relation, die Y enthält, auch X enthält. Solche dominierten Attribute werden aus dem Map-Key entfernt. Die dahinterstehende Idee sollte intuitiv klar sein: Wenn über dominierte Attribute gejoint wird, dann wird der Join auch immer über die entsprechenden dominierenden Attribute durchgeführt. Eine zusätzliche Vermehrung der Reduce-Prozesse ist dann nicht notwendig. Für unser Beispiel R(A,B,C) S(A,B,D) T (A,D,E) U(D,F) bedeutet das: Attribut B wird von A dominiert, denn B ist nur in R und S enthalten, darin kommt aber auch immer A vor. Hingegen wird A nicht von B dominiert, denn nicht in allen Relationen, in denen A vorkommt, kommt auch B vor in der Relation T ist zwar A enthalten, nicht aber B. 13 Die Folge ist, dass die Variable b nicht mehr als Argument in unserer Kostenfunktion auftritt. Die neue Kostenfunktion lautet somit: f (a,d) = rd + s +t + ua λ(ad k). Da dann auch nicht mehr nach b abgeleitet wird, entstehen bei der Ableitung nur noch die beiden Gleichungen ua = λk rd = λk. Die störende Null-Lösung ist somit verschwunden. Dass durch das Entfernen dominierter Attribute immer ein mindestens ebenso günstiger Kostenausdruck entsteht wie zuvor, lässt sich sogar beweisen. 14 An dieser Stelle verzichten wir darauf, das zu tun. Leider zeigt sich, dass mit dem Konzept der dominierten Attribute nicht alle Null-Lösungen eliminiert werden können. 15 Vielmehr gibt es einen recht komplizierten Algorithmus, der beschreibt, was zu tun ist, wenn es weitere Null-Lösungen gibt. 16 Die Idee ist auch hier, eine der Share- Variablen zu eliminieren und eine mindestens ebenso günstige Lösung zu suchen. Dazu muss das ursprüngliche Problem in Teilprobleme zerlegt werden, von denen wiederum jedes einzelne optimiert wird. Auf Details verzichte ich hier. 12 [AU10], Es gibt hier noch ein paar andere Dominanzen, so wird F von D dominiert. Das ist hier aber nicht von Belang. 14 [AU10], [AU10], [AU10], 3.5

189 12 Optimierung von Joins Oliver Schöner 11 6 Spezialfälle Im Folgenden seien zwei Spezialfälle kurz angerissen, bei denen der Kostenausdruck besonders interessant wird: der Stern-Join und der Ketten-Join. 6.1 Stern-Join Beim Stern-Join 17 gibt es eine in der Regel große, zentrale, sogenannte Faktentabelle und mehrere sogenannte Dimensionstabellen, die sich bildlich gesprochen sternförmig um die Faktentabelle gruppieren. Betrachten wir folgendes Beispiel: Die Faktentabelle sei die Relation R(A, B, D,C), die Dimensionstabellen die Relationen S(A,E), T (B,F), U(C,G) und V (D,H). Wir sehen, dass jede Dimensionstabelle ein gemeinsames Attribut mit der Faktentabelle hat. Der Join führt zu der Kostenfunktion R(A,B,D,C) S(A,E) T (B,F) U(C,G) V (D,H) f (a,b,c,d) = r + sbcd +tacd + uabd + vabc. Wenn wir diese Funktion in der gewohnten Weise nach a,b,c und d ableiten und die Gleichungen nacheinander auflösen, sehen wir nicht nur, dass a = 4 ks 3 tuv ist. (Für die Share-Variablen b,c und d gibt es ähnlich aussehende Lösungen). Bemerkenswert ist auch, dass sich aus den Ableitungen der Kostenfunktionen die Verhältnisse s a = t b = u c = v d ergeben. Dies zeigt uns, dass je mehr Tupel eine Relation hat (S hat s Tupel), desto größer auch die dazugehörige Share-Variable a (deren Attribut A sich in der gleichen Relation S befindet) sein muss. Je größer wiederum a ist, desto kleiner müssen b,c und d sein (da ja abcd = k gilt). Daraus folgt, dass die (vielen) Tupel der Relation S auf vergleichsweise wenige (b c d) Reduce-Prozesse abgebildet werden, oder allgemein: Je größer eine Relation, auf desto weniger Reduce-Prozesse werden ihre Tupel abgebildet. Im Sinne der Kostenminimierung vermag dieser Sachverhalt nicht zu überraschen. 17 Siehe [AU10], 4.1.

190 12 12 Optimierung von Joins Oliver Schöner 6.2 Ketten-Join Bei einem Ketten-Join 18 werden die Relationen verkettet : R 1 (A 0,A 1 ) R 2 (A 1,A 2 ) R n (A n 1,A n ). Wir sehen, dass nur die Attribute A 1 bis A n 1 Teil des Map-Keys sind, nicht aber A 0 und A n. Entsprechend gilt es, die Werte der Share-Variablen a 1 bis a n 1 zu bestimmen. Hier zeigt sich 19 ein überraschendes Ergebnis: Es kommt nämlich darauf an, ob wir es mit einer geraden oder einer ungeraden Zahl an Relationen zu tun haben. Hierzu nehmen wir wieder vereinfachend an, dass alle Relationen die gleiche Größe r haben. Fall 1: n ist gerade. Dann bekommen alle geraden Share-Variablen den Wert 1: a 2 = a 4 = = a n 2 = 1, oder anders ausgedrückt: Die dazugehörigen Join-Attribute A 2,...,A n 2 werden aus dem Map-Key entfernt. Für die ungeraden Share-Variablen wiederum gilt: Auch sie haben alle den gleichen Wert, der nur duch k und n bestimmt ist: a 1 = a 3 = = a n 1 = n k 2. Fall 2: n ist ungerade. Dann sollte zunächst der Wert von a 2 bestimmt werden; und in Abhängigkeit davon gilt für alle i von i = 0 bis 20 i = n 3 2 : a 2i = (a 2 ) i und a 2i+1 = (a 2 ) ((n 1)/2) i Das bedeutet: Je weiter hinten in der Kette die geraden a stehen, desto größer werden sie; und je weiter hinten die ungeraden a in der Kette stehen, desto kleiner werden sie. 7 Ausblick und Kritik Wir haben gesehen, wie die Kosten eines Joins unter Verwendung von MapReduce verringert werden können, sofern man in Kauf nimmt, die Tupel einer Relation auf mehrere Reduce-Prozesse abzubilden. Doch der vorgestellte Algorithmus weist bei näherem Hinsehen einige Schwächen auf, die hier kurz vorgestellt seien: Zum ersten wird doch ein erheblicher algorithmischer Aufwand für einen beschränkten Nutzen betrieben. Zweitens eignet sich das Vorgehen lediglich für Natural Joins. Drittens schließlich bleiben die Kosten recht abstrakt. 18 Siehe [AU10], Ich führe das hier nicht aus, sondern stelle nur das Ergebnis dar. Für Details siehe [AU10], Afrati und Ullman zählen in [AU10], erst ab i = 1. Für i = 0 stimmen die Gleichungen aber ebenso, und es wird auch der Fall von a 1 korrekt erfasst.

191 12 Optimierung von Joins Oliver Schöner Geringer Nutzen Der vorgestellte Algorithmus scheint auf den ersten Blick recht gut umsetzbar: Join-Attribute identifizieren, Kostenfunktion ableiten und die entsprechenden Gleichungen zu lösen scheint nicht schwer. Allerdings ist der Nutzen nicht klar. Natürlich wird auf diese Weise ein Minimum der Kostenfunktion gefunden, aber man findet eben nur ein Minimum. Dass dieses Minimum nicht nur ein lokales Minimum ist, dafür gibt es keine Garantie. Eventuell müsste der Schritt zur Minimumbestimmung erheblich verfeinert werden unter Verwendung etwas anspruchsvollerer mathematischer Methoden. Afrati und Ullman plädieren denn auch dafür, die gefundenen Lösungen nicht zu verabsolutieren. 21 Vielmehr seien die Lösungen eher so aufzufassen, dass die Tupel mancher Relationen eben auf viele und die Tupel anderer Relationen auf wenige Reduce-Prozesse abgebildet werden. Aber das lässt sich natürlich auch mit scharfem Nachdenken ohne einen komplizierten Algorithmus plausibel machen: Wenn ich in einer Relation viele Tupel habe, kann ich die Kosten dadurch verringern, dass ich jedes einzelne dieser Tupel nicht auf zu viele Reduce-Prozesse verteile. Interessanter erscheint daher der Vorschlag, die Zahl der Reduce-Prozesse nicht als Konstante aufzufassen. Gegebenenfalls kann es sinnvoll sein, insgesamt weniger Reduce-Prozesse zu verwenden damit sinken auch die Gesamtkosten. 7.2 Beschränkung auf Natural Joins Ein Punkt, der bei Afrati und Ullman nur einmal ganz kurz anklingt, 22 scheint mir doch von erheblicher Bedeutung zu sein: Das Verfahren, die Tupel einer Relation per Hashfunktion auf bestimmte Reduce-Prozesse abzubilden, funktioniert selbstverständlich nur bei Natural Joins mit Gleichheitsbedingung. Soll ein Join durchgeführt werden mit einer Bereichsbedingung, so ist überhaupt nicht klar, wie MapReduce hier sinnvoll eingesetzt werden kann. 7.3 Fragwürdigkeit des Kostenmodells Schließlich ist das Kostenmodell als solches fragwürdig. Ginge es nämlich darum, nur die erwähnten Kosten einzusparen, dann wäre es am einfachsten, überhaupt nur einen einzigen Reduce- Prozess einzusetzen (also auf MapReduce zu verzichten). Tatsächlich würde dann jedes Tupel nur auf diesen einen Reduce-Prozess abgebildet und die Kosten wären minimal. Dafür würde aber der Zeitaufwand erheblich steigen. Wenn wir auf der anderen Seite beliebig viele Reduce-Prozesse hätten, würden die theoretischen Kosten zwar stark ansteigen (viele, viele Tupel in vielen Reduce- Prozessen), aber insgesamt würde der Join natürlich schneller gehen. Diese reziproke Verhältnis zwischen Kommunikationskosten wird zwar kurz erwähnt; 23 dass der Faktor Zeit in dem Kostenmodell aber keinerlei Rolle spielt, ist schon zu hinterfragen: Kommt es nicht auch darauf an, den Join möglichst schnell durchzuführen? 21 [AU10], [AU10], 4 23 [AU10], 2.6

192 14 12 Optimierung von Joins Oliver Schöner 8 Literatur [AU10] Afrati, Foto N.; Ullman, Jeffrey D.: Optimizing Joins in a Map-Reduce Environment. In: Proceedings of the 13th International Conference on Extending Database Technology ACM, 2010, S

193 FernUniversität in Hagen - Seminar im Sommersemester 2011 MapReduce und Datenbanken Thema 13: Spatial Join with MapReduce on Clusters Referentin: Katharina Eberl

194 Gliederung 1. Einleitung Einführung in Spatial Join Erklärung des Spatial Joins Filter Step Refinement Step Verwendete Algorithmen Probleme bei der Anwendung mit MapReduce Vorstellung Spatial Join mit MapReduce (SJMR) Determinierung der Partitionen Map stage Homogenizing Step Spatial Splitting Step Reduce stage Filter Step Refinement Step Vor- und Nachteile Vermeidung von Duplikaten im Ergebnis Beurteilung der Performance Folgerungen I. Quellen II. Abbildungsverzeichnis Seite 2

195 1. Einleitung MapReduce ist ein von Google eingeführtes Framework, um Berechnungen über große Datenmengen auf Rechnercluster durchführen zu können. Eine Möglichkeit des Joins stellt die Kombination von MapReduce mit Spatial Join dar. Spatial Join with MapReduce on Cluster (kurz SJMR) stellt eine Methode vor, wie dieser Join effizient implementiert und angewendet werden kann. Um die Zusammenhänge besser aufzeigen zu können, erfolgt zuerst eine allgemeine Einführung in Spatial Join, bevor anschließend auf SJMR im Detail eingegangen wird. 2. Einführung in Spatial Join Ein Spatial Join ermöglicht es Informationen aus einem oder mehreren Datenbeständen zu kombinieren und so neue Informationen zu erzeugen. Die Beziehung zwischen den Datenbeständen wird durch geometrische Daten dargestellt. Als Kombinationskriterium dient nicht die Gleichheit, sondern das Enthalten sein bzw. die Überlappung. Deshalb brauchen die geometrischen Wertebereiche nicht identisch zu sein. Sie sollten sich nur auf das gleiche Koordinatensystem beziehen. Beim Spatial Join handelt es sich um ein sehr mächtiges Instrument zur Kombination von Daten unterschiedlicher Herkunft Erklärung des Spatial Joins Der Spatial Join besteht aus zwei mehrdimensionalen Objekte. Eine Abfrage mit Spatial Join findet alle Paar von Objekten, die eine gegebene Spatial Relation erfüllt. 2 Beispiel: Die Fragestellung könnte z. B. sein, dass alle Paare von Flüssen und Städten gefunden werden müssen, die sich kreuzen. Kreuzt man die Flüsse {R1, R2} und die Städte {C1, C2, C3, C4, C5}, so ist das Ergebnis { (R1, C1), (R2, C5)}. 3 Das Beispiel wird in Abb. 1 veranschaulicht. 1 vgl. [2] 2 vgl. [3] Seite 2 3 vgl. [1] Seite 1 Seite 3

196 Abbildung 1: Beispiel für einen Spatial Join Quelle: [1] Seite 1 Die Ausführung des Spatial Joins erfolgt in zwei Schritten. Der erste Schritt ist der Filter Step und der zweite wird Refinement Step bezeichnet. Auf den Algorithmus wird nun detaillierter eingegangen Filter Step Ein wichtiger Begriff für das Verständnis von Spatial Joins ist das minimal umgebende Rechteck, kurz MBR genannt (engl.: minimum bounding rectangle). Es beschreibt das kleinstmögliche Rechteck, das eine vorgegebene Menge von Objekten umrandet. Dabei beschränkt sich das MBR nicht auf zweidimensionale Flächen, sondern es kann auch auf andere Dimensionen erweitert werden. Ein Beispiel hierfür wird in [6] dargestellt: Abbildung 2: Beispiel für ein minimal umgebendes Rechteck Quelle: [6] Seite 6 Durch die Anwendung des MBR soll eine Annäherung bzw. Approximation an die Tupel, die der Abfrage des Spatial Joins entsprechen, erreicht werden. Die identifizierten Objekte, die nicht der Abfrage entsprechen werden eliminiert. Dieser Schritt ist nicht sehr rechenaufwendig, im Gegensatz zum nächsten Schritt, dem Refinement Step. 1 1 vgl. [1] Seite 2 Seite 4

197 Refinement Step Wie der Name schon verrät wird das Ergebnis des Filter Steps noch weiter verfeinert. Die verbleibenden Paare werden geprüft, ob sie den Anforderungen des Spatial Joins auch tatsächlich genügen. Durch die Vorfilterung hat sich die Anzahl der Tupel bereits deutlich reduziert. Dadurch kann dieser rechenintensive Schritt beschleunigt werden Verwendete Algorithmen Für den Filter Step stehen mehrere Algorithmen zur Verfügung. Allerdings verwenden moderne Algorithmen spezielle Spatial-Indexe auf beide Inputdatensätze an. Bei MapReduce wird der Index dynamisch aufgebaut, was zur Folge hat, dass der Index online auf einen oder beide Inputdatensätze angewendet werden muss. Durch den Einsatz von online aufgebauten Indexen kann die index-basierte Spatial Join Technik wieder verwendet werden. Ziel dieser Technik ist es, die Daten so klein zu partitionieren, dass sie in den internen Speicher passen. 1 Somit eigen sich besonders Shared-Nothing-Architekturen. Bei der Shared-Nothing- Architektur kann jeder Knoten unabhängig und eigenständig seine Aufgaben mit seinem eigenen Prozessor und den zugeordneten Speicherkomponenten wie Festplatte und Arbeitsspeicher erfüllen. Es kann aber auch eine Shared-Memory-Architektur verwendet werden. Bei dieser Art nutzen zwei oder mehrere Prozesse einen bestimmten Teil des Arbeitsspeichers gemeinsam. Für alle beteiligten Prozesse liegt dieser gemeinsam genutzte Speicherbereich in deren Adressraum und kann mit normalen Speicherzugriffsoperationen ausgelesen und verändert werden. Hypercube Architekturen stehen ebenfalls zur Diskussion. Der große Vorteil ist, dass bei Verwendung dieser Architekturen die Aufgaben parallel ausgeführt werden können, wodurch sich die Bearbeitungszeit verkürzt wird. Der Refinement Step kann nicht so einfach parallelisiert werden. Daher wird hier ein Prozessor dazu verwendet, die Kandidaten in eine lineare Reihenfolge zu bringen, d.h. die Kandidaten werden in ein einfaches zeitliches nacheinander geordnet. Auf die weiteren Prozessoren werden die Kandidaten mit dem Round Robin Verfahren verteilt. Das Round Robin Verfahren, oder auch Rundlauf-Verfahren genannt, gewährt allen Prozessen nacheinander für jeweils einen kurzen Zeitraum Zugang zu den benötigten Prozessoren Probleme bei der Anwendung mit MapReduce Grundsätzlich ist es nicht einfach MapReduce mit Spatial Join zu kombinieren. Während MapReduce normalerweise auf gleichen Datentypen arbeitet, kann der Spatial Join auch mit heterogenen Datentypen umgehen. MapReduce verwendet als Objekte meist Wörter, 1 vgl. [3] Seite 2 u. 3 2 vgl. [10] Seite 5

198 oder URLs. Spatial Objekte sind hingegen generell länger und komplexer, was dazu führt dass Spatial Joins sehr zeitaufwendig und umfangreich werden können. Ein weiteres Problem ist, dass beim Spatial Join doppelte Datensätze entstehen können, welche die Parallelisierung von Spatial Join Operationen schwierig macht. 1 Darauf wird aber in Kapitel 4 Vermeidung von Duplikaten genauer eingegangen. 3. Vorstellung Spatial Join mit MapReduce (SJMR) Trotz der Differenzen zwischen MapReduce und Spatial Joins wurde ein neuer Algorithmus genannt Spatial Join with MapReduce (SJMR) entworfen, der vor allem auf Clustern eingesetzt wird. Der Algorithmus besteht aus drei Teilen: der Determinierung, dem sogenannten Map Stage und dem Reduce Stage. Um die Ausführungen zu verdeutlichen wird folgendes Beispiel verwendet: Es gibt zwei Relationen R und S, in denen die beiden Inputdatensätze enthalten sind. Für jeden Datensatz gibt es einen eindeutigen Schlüssel, genannt OID (engl.: object identifier). Jeder Datensatz oder auch Tupel genannt, besitzt mindestens einmal das Variablenpaar (k 2,v 2 ). In k 2 wird die Nummer der Partition, in v 2 wird der eindeutige Schlüssel gespeichert Determinierung der Partitionen Die minimale Anzahl von Partitionen (Reduce Tasks) wird von vielen Faktoren determiniert. Um sie zu kalkulieren geht man wie folgt vor: Zuerst benötigt man die Kardinalitäten der Relationen R und S. Die Kardinalität gibt die Anzahl der Elemente einer Menge wieder und wird dargestellt als: R und S. Der vervielfachende Koeffizient wird p genannt. M gibt den zur Verfügung stehenden Speicherplatz im Arbeitsspeicher an und Size kp stellt die Größe des Keypointer Elements dar, das aus dem MBR, OID und Feldinformationen besteht, dar. Somit ergibt sich folgende Formel zur Berechnung der minimalen Anzahl: 3 P= [( R + S ) * (1+p) * Size kp /M] 3.2. Map stage Das Ziel von Map Stage ist es, die Tupel so zu verteilen, dass jede Reduce Task nahezu gleich arbeiten kann und die Verteilung die Validität des Ergebnisses nicht beeinflusst. Als Verteilungsstrategie wird HDFS (Hadoop s Disstributed FileSystem) verwendet. HDFS baut auf den MapReduce-Algorithmus auf und beinhaltet auch Vorschläge aus dem Google-Dateisystem. Es wurde für skalierbare, verteilt arbeitende Software entwickelt und eignet sich besonders für rechenintensive Prozesses in Verbindung mit großen Datenmengen. 4 1 vgl. [3] Seite 1 2 vgl. [3] Seite 3 3 vgl. [3] Seite 3 4 vgl. [4] Seite 6

199 Im Rahmen des Master-Slave-Prinzips übernimmt die Rolle des Masters beim HDFS der NameNode, der alle Metadaten des Filesystems, wie Verzeichnisstrukturen und Dateien verwaltet. Die sogenannten DataNodes übernehmen die Rolle der Slaves und sind für die Verwaltung der Nutzdaten im HDFS zuständig. Die Tupel der Relationen R und S werden somit auf die DataNodes verteilt. Nachdem dies geschehen ist, ist die nächste Aufgabe von SJMR die Tupel von R und S in verschiedene Reduce Tasks zu verteilen. Die Verteilung auf die Reduce Tasks erfolgt in zwei Schritten, dem Homegenizing Step und dem Spatial Splitting Step. Beim zweiten Schritt kommt eine neue Technik genannt n Spatial Partitioning Function (SPF) zum Einsatz Homogenizing Step MapReduce konzentriert sich vor allem auf die Verarbeitung von homogenen Datensätzen. Somit ist der erste Schritt die Datensätze zu vereinheitlichen. Dazu wird ein Zusatz über die Datenquelle an jedes Tupel angehängt. Somit enthält jedes bereits homogenisierte Tupel vier gemeinsame Attribute: OID, MBR, spatial property und die Information zur Datenquelle Spatial Splitting Step Der Gegenstandbereich, auch Universum genannt, wird definiert als das minimale Rechteck, dass alle Tupel von R und S bedeckt. Das Universum wird in mehrere Partitionen P aufgeteilt. Falls es keine einheitliche Regel zur Verteilung geben würde, könnte es dazu kommen, dass manche Partitionen mehr Tupels und andere weniger enthalten. Wie in Abbildung 3 dargestellt, ist der Großteil in Partition 2 enthalten, die anderen Partitionen haben weniger Elemente. Das führt zu unterschiedlichen Speicher und CPU-Verbräuchen. 2 Abbildung 3: Verteilung des Daten Quelle: [3] Seite 4 1 vgl. [3] Seite 3 2 vgl. [3] Seite 4 Seite 7

200 Laut [3] baut SPF aus drei Achsen auf: - Feldnummer (tile number) - Feldkodierungsmethode (tile coding methode) - Feld-zu-Partition Zuordnungsschema (tile-to-partition mapping scheme) SJMR übernimmt davon die feldbasierte Methode, die das Universum in N t gleichgroße Felder (engl: tile) aufteilt. Allerdings verwendet SJMR eine andere Feldkodierungsmethode und ein anderes Feld-zu-Partition Zuordnungsschema. Für die Feldkodierungsmethode wird Spatial-Clustering Technologie verwendet um die Verteilung möglichst ausgeglichen zu gestallten. Das Spatial-Clustering ist ein Prozess der Vereinigung einer Menge von Objekten in Cluster. Hierbei geht es darum, die Objekte die hohe Ähnlichkeit ihn ihren Eigenschaften besitzen zu vergleichen und diese dann zu gruppieren. Andere Cluster mit ihren Objekten sollten wiederum keine Ähnlichkeiten in ihren Eigenschaften zu anderen Cluster Objekten besitzen. Abbildung 4: Menge von Objekten Quelle: [6] Wie in der Abbildung zu sehen, befinden sich dort Bereiche, wo sich die Daten gruppieren. Durch diese Gruppierung kann man erkennen, dass bestimmte Daten in irgendeiner Weise Ähnlichkeit zu anderen Daten aufweisen. 1 Zwischen den Gruppierungen ergeben sich viele Lücken. Diese Lücken müssen durch Kurven gefüllt werden. Die hierfür am besten geeigneten Methoden sind die Z-Kurve und die Hilbert- Kurve. Für das Feld-zu-Partition Zuordnungsschema können verschiedene Verfahren verwendet werden. Besonders eignen sich Round Robin und Hashfunktionen. Um die Zusammenhänge besser zu verstehen, wird jede Methode kurz vorgestellt. Das Verfahren Round Robin wurde bereits erläutert. 1 vgl. [6] Seite 8

201 Unter einer Hashfunktion oder zu Deutsch Streuwertfunktion versteht man eine Funktion, die aus einer großen Eingabemenge eine kleinere Zielmenge als Ausgang erzeugt. Diese Funktion verstreut die Daten anhand eines Hashcodes. Ein einfaches Beispiel ist ein Adressbuch. Ein Name wird anhand seines ersten Buchstabens in das Adressbuch eingeordnet. Das Alphabet wäre somit der Hashcode. Dadurch kann eine große Anzahl an Namen zerkleinert werden. 1 Beim Feld-zu-Partition Zuordnungsschema werden nicht Namen, sondern Feldern in Partitionen eingeordnet. Der Hashcode kann unterschiedlich lang sein. Desto länger er ist, umso kleiner wird die Ausgabe. Im Folgenden werden 4-bit und16-bit lange Hashcodes verwendet. Die Z-Kurve kann als raumfüllende Kurve beschrieben werden, die man auch für mehrdimensionale Datenstrukturen verwenden kann. Ein Raumpunkt ergibt sich durch bitweises Verschränken der Koordinatenwerte. Abbildung 5: Beispiel für die Anwendung der Z-Kurve Quelle: [3] Seite 4 Das letzte Verfahren ist die Hilbert-Kurve. Sie ist ebenfalls eine raumfüllende Kurve. Ziel ist es, einem beliebigen Punkt auf einer quadratischen Fläche beliebig nahe zu kommen und die Fläche vollständig auszufüllen. Erreicht wird dies durch Wiederholung des Konstruktionsverfahren. 3 Abbildung 6: Beispiele für die Hilbert-Kurve Quelle: [9] 1 vgl. [7] 2 vgl. [8] 3 vgl. [9] Seite 9

202 Um die beste Kombination der Methoden für SPF zu finden wird ein Experiment anhand von TIGER/-Line Feldern durchgeführt. TIGER/-Line ist ein Verfahren, welches unter anderem zum Aufzeichnen von Straßen in Kalifornien verwendet wird. (siehe auch Kapitel 5 Beurteilung der Performance ). Durch das Ausführen des Experiments werden die Methoden Round Robin, Hashing, Z-Kurve und Hilbert- Kurve miteinander vergleichen. Abbildung 7 zeigt den Aufwand von den aufgeführten Methoden abhängig vom Faktor, der die Variationsmöglichkeiten festlegt. Eine perfekte Methode würde gleiche Tupel einer Partition zuordnen und die Anzahl der Variation wäre 0. Abbildung 7: Anzahl der Variationen Quelle: [3] Seite 4 Aus Abbildung 7 können folgende Schlussfolgerungen gezogen werden: Als Kodierungsmethode eignet sich am besten Z-Kurve und Hilbert Kurve, kombiniert mit Round Robin für das Zuordnungsschema. Hier ist der Koeffizient der Variationen am niedrigsten. Was allerdings auffällig ist, ist das sich die Performance von allen mit zunehmender Anzahl der Felder verbessert. 1 1 vgl. [3] Seite 4 u. 5 Seite 10

203 Abbildung 8 zeigt den Replication Overhead bei Erhöhung der Anzahl der Felder. Quelle: [3] Seite 5 Mit Zunahme der Feldnummern steigt der Replication Overhead. Am geringsten ist er allerdings bei Round Robin. Auf Grund dieses Experiments wird die Z-Kurve als Feldkodierungsmethode kombiniert mit Round Robin als Feld-zu-Partition Zuordnungsschema für den SPF in SJMR verwendet. Die Vorgehensweise, wie SPF von SJMR im Detail arbeitet wird nun im Folgenden zusammengefasst: 1 1. Schritt: Universum in N T Felder aufteilen, wobei N T >>P 2. Schritt: Die Felder werden nummeriert von 0 bis N T 1 mit Hilfe der Methode der Z- Kurve und werden einer Partition p (0 p P - 1) mit Round Robin zugeordnet. 3. Schritt: SPF überprüft für jedes Tupel das MBR, um alle Felder zu determinieren, dessen MBRs sich überschneiden. Außerdem wird die Variable k 2 als die Nummer der Partitionen, zu denen das Feld gehört, gesetzt. Falls sich das MBR des Tupels mit mehreren Partitionen überschneidet, wird k 2 entsprechen oft generiert und befüllt. 4. Schritt: Als nächstes wird die Variable v 2 befüllt. Für die Vermeidung von Verdopplungen und für die Filterschritte vom Reduce stage werden allerding auch die Feldinformationen von jedem Tupel benötigt. Somit muss die Feldinformation als ein weiteres Attribut von jedem Tupel gespeichert werden. Somit besteht der Wert v 2 von jedem Tupel aus fünf gemeinsamen Attributen: OID, MBR, spatial property, Informationen zur Datenquelle und die Feldinformation. 5. Schritt: Tupel von verschiedenen Datensätzen mit demselben Schlüssel k 2, werden zur selben Reduce Task zugeordnet. User definierte Logik kann die Quelle der Daten bestimmen um die Herkunft festzustellen. Die Einträge von verschiedenen Quellen können somit verbunden werden vgl. [3] Seite 5 Seite 11

204 3.3. Reduce stage Der Reduce stage setzt sich, wie der Spatial Join selbst, aus dem Filter Step und dem Refinement Step zusammen Filter Step Das Ziel des Filter Step ist es, Tupel derselben Partition so zu paaren, dass sich ihr MBR überschneidet. Dazu wird wie folgt beschreiben vorgegangen: 1 1. Zuerst werden alle Werte von v 2, die zur selben Partition k 2 gehören, eingelesen. 2. Die Keypointer Elemente werden für jeden Wert von v 2 in einem von zwei temporäre Relationen R kp und S kp dem Arbeitsspeicher hinzugefügt. Die anderen Informationen des Tupels werden in einem von zwei temporären Relationen R T und S T auf die Festplatte gespeichert. 3. Nun wird nach MBRs in R kp gesucht, welche sich mit MBRs in S kp kreuzen. 4. Gegeben sind zwei Rechtecke. Wenn beide in den Hauptspeicher passen, dann kann ein effektiver sweeping Algorithmus verwendet werden um alle Paare der überlappenden Rechtecke zu ermittelt. Kern eines Sweep im zweidimensionalen ist die line sweeping (Sweep-Gerade) bzw. im dreidimensionalen die plane sweeping (Sweep-Ebene). Durch sie wird der Raum "ausgefegt". Man bewegt sie durch den gesamten Raum bis alle Objekte des Problems besucht und verarbeitet wurden. 2 Durch Map Stage ist sichergestellt, dass R kp und S kp in den Speicher passen, somit kann ein plane sweeping Algorithmus angewendet werden um alle Paare von Keypointer Elementen in R kp und S kp zu finden, die überlappende MBRs haben. Für diese passenden Keypointer Elemente Paare, wird die OID-Information extrahiert und als Output von diesem Schritt erfasst. 5. Um die Feldinformation der Tupels voll ausnutzen zu können, werden die Tupel gesplittet. SJMR adoptiert eine neue streifenbasierte plane sweeping Methode. In dieser Methode wird jede Partition in gleich große Streifen geteilt. Die Streifen sind nebeneinander und parallel zur X-Achse. Dann wird jeder Streifen mit dem plane sweeping Algorithmus gefiltert. Jedes Tupel wird auf einem Steifen anhand seiner Feldinformation zugeordnet. Der Key- Parameter vom streifenbasierten plane sweeping Algorithmus ist die Streifennummer. Eine Aufteilung des Universums in zwei Streifen könnte beim Beispiel zur Z- Kurve wie in Abbildung 5 bereits eingezeichnet aussehen. 1 vgl. [3] Seite 5 2 vgl. [11] Seite 12

205 Der Vollständigkeit halber folgt ein Beispiel, wie die streifenbasierte plane sweeping Methode implementiert werden kann: Abbildung 9: streifenbasierter plane sweeping Algorithmus Quelle: [3] Seite Refinement Step Das Ergebnis des Filter Step sind zwei temporäre Relation, deren Tupel die Form <OID R, OID s > haben. Die Relationen sagen aus, welches MBR von OID(R) sich mit dem MBR von OID(S) überschneiden. Im Refinement Step muss nun geprüft werden, in wieweit das Ergebnis die Join-Bedingungen erfüllt. Um eine chaotische Suche beim Auslesen der Tupel R und S, die in R T und S T auf der Festplatte gespeichert sind, zu vermeiden, wird eine weitere Strategie eingeführt: Zuerst werden die OID-Paare nach OID R als primärer Sortierungsschlüssel und OID s als zweiten sortiert. Anschließend werden so viele Tupeln von R wie möglich zusammen mit den dazugehörigen <OID R, OID S > Paaren in den Arbeitsspeicher eingelesen. Der OID R -Teil von dieser Reihung zeigt auf die R-Tupel im Arbeitsspeicher. Dann wird die Reihung nach OID s sortiert. Die S Tuples in S T auf der Festplatte werden anschließend sequentiell in den Arbeitsspeicher eingelesen. Die Spatial Eigenschaften von R und S Tupels werden im Memory geprüft und es wird festgestellt, ob sie die Join-Bedingungen erfüllen. 1 Um zu vermeiden, dass Duplikate im Ergebnis generiert werden, verwendet SJMR eine feldbasierte Verdopplungsvermeidungstechnologie. Darauf wird im Punkt 4 Vermeidung von Duplikationen noch genauer eingegangen. 1 vgl. [3] Seite 6 Seite 13

206 3.4. Vor- und Nachteile Bei SJMR können die Vorteile von MapReduce mit denen des Spatial Join kombiniert werden. Der Spatial Join ist extrem effizient und kann mit der Hilfe von MapReduce parallel auf Clustern ausgeführt werden. Dadurch verkürzen sich die Bearbeitungszeiten. Des Weiteren können auf diese Weiße auch heterogene Daten miteinander kombiniert werden. Allerdings ist diese Methode sehr kompliziert und komplex. Ein weiterer Nachteil ist, dass Duplikate erzeugt werden. Hierzu muss sich überlegt werden, wie mit den Duplikaten umgegangen wird. Mehr dazu im nächsten Kapitel. 4. Vermeidung von Duplikaten im Ergebnis Es gibt zwei Möglichkeiten das Join-Ergebnis von zwei Tupeln T R und T s mehrmals zu erzeugen. - Falls T R und T S im Map stage verschiedenen Partitionen zugeordnet werden, können im Reduce Task Duplikate erzeugt werden. oder - Beim Reduce Task, wenn T R und T S in mehrere Streifen repliziert werden, dann werden ebenfalls Duplikate generiert. Die Duplikate können durch zwei Methoden vom Ergebnis entfernen werden: Elimination und Vermeidung von Duplikaten. Bei der Eliminierung von Duplikaten wird zuerst das Ergebnis sortiert und anschließend werden die Duplikate entfernt. Da dieser Schritt erst am Ende des Reduce stage ausgeführt werden kann, führt dies zu einer Verlängerung der Bearbeitungszeit und somit auch zu einer Erhöhung der Kosten. Somit ist es besser die Generierung von Duplikaten bei jeder Reduce Task online zu vermeiden. Deshalb wird der Filter Step mit einem simplen Test erweitert, der durchgeführt wird, wenn die Rechtecke auf Überschneidung geprüft werden. Die Technik wird referenzierende Feldmethode genannt. Falls ein Paar von T R und T S in mehrere Reduce Tasks repliziert wurden, werden sie nur in einem Task gejoint. Ausgehend von der Feldinformation von jedem Tupel, berechnet die referenzierende Feldmethode das kleinste gemeinsame Feld von zwei Tupeln. Das Ergebnispaar wird nur berichtet, wenn das kleinste gemeinsame Feld innerhalb der aktuellen Partition und des aktuellen Streifen liegt. 1 Beispiel siehe Abbildung 9: Das Universum ist in 16 Felder aufgeteilt. Das kleinste gemeinsame Feld von T R und T S liegt in Feld 3. Somit werden T R und T S nur gejoint, wenn sowohl der Reduce Task als auch der Streifen das Feld 3 beinhalten. 1 vgl. [3] Seite 6 Seite 14

207 Abbildung 10: Referenzierende Feldmethode Quelle: [3] Seite 6 5. Beurteilung der Performance Zur Beurteilung der Performance wird ein Experiment durchgeführt. Dazu wird wieder HDFS verwendet. Ausgeführt wird das Experiment auf einem DELL Power Edge Sc430 Server. Die Ergebnisse werden auf einem ein Konten, 2 Knoten, 4 Knoten und 8 Knoten großem Cluster erzielt. Als Datenbeispiel werden wieder Datensätze aus dem bereits erwähnte TIGER/-Line verwendet. Einer beinhaltet die Straßeninformationen von Kalifornien. Das andere beinhaltet das Gewässernetz von Kalifornien. Abbildung 11: Übersicht über die Daten Quelle: [3] Seite 6 Es wird nun untersucht, wie sich eine Erhöhung der Streifen und der Knoten auf die Performance auswirkt. Als erstes wird der Einfluss der Streifenanzahl auf den streifenbasierten plane sweeping Algorithmus ermittelt. Der Algorithmus wird auf einem Cluster mit nur einem Knoten implementiert. Seite 15

208 Abbildung 12: Einfluss der Streifenanzahl Quelle: [3] Seite 7 Man kann erkennen, dass die Anzahl der Streife definitiv Einfluss auf die Performance hat. Desto höher die Anzahl der Streifen steigt, umso besser arbeitet der streifenbasierte plane sweeping Algorithmus. Eine gute Performance wird erzielt, wenn die Streifenanzahl acht ist. Daher verwendet der streifenbasierte plane sweeping Algorithmus von SJMR auch acht Steifen. Als nächstes wird der Einfluss der Knotenanzahl und der Anzahl der Reduce Task untersucht. Abbildung 13: Einfluss der Knotenanzahl Quelle: [3] Seite 7 Die Anzahl der Knoten und der Reduce Tasks stehen zueinander in Beziehung. Mit dem Anstieg der Anzahl der Knoten verbessert sich die Performance deutlich. Außerdem verbessert sich die Performance mit zunehmender Anzahl der Reduce Task, bei einer bestimmten Anzahl von Knoten N. Allerdings muss gelten, dass die Anzahl der Reduce Tasks Seite 16

209 P kleiner oder gleich sein muss als 2N, d.h. (P 2N). Aber wenn P>2N gilt, sinkt die Performance mit Zunahme der Reduce Task Anzahl. 1 Um die Performance von SJMR fundiert beurteilen zu können, wird SJMR auch noch mit zwei verwandten Verfahren verglichen. Das erste Verfahren zum Vergleichen ist Partition-Based Spatial-Merge kurz PPBSM. Die Arbeitsweise ist ähnlich wie bei SJMR, nur die Duplikate werden nach dem Spatial Join eliminiert. Die Performance von SJMR und PPBSM verbessert sich mit der Zunahme der Reduce Tasks P, falls P 2N. Aber wenn P>2N verschlechtern sich beide. Aus der Abbildung 14 kann man ablesen, dass die Performance von SJMR grundsätzlich um 20 Sekunden besser ist. Das ist darauf zurückzuführen, dass das Eliminieren von Duplikaten ca. 20 Sekunden in Anspruch nimmt. Abbildung 14: Vergleich der Performance von SJMR und PPBSM (8 nodes/knoten) Quelle: [3] Seite 7 Das zweite Verfahren nennt sich SJMR-Large Mem. Beim Reduce stage von SJMR werden die spatial property von jedem Tupel in lokale Dateien T R und T S auf die Festplatte kopiert. Um die Schreibzugriffe auf die Festplatte zu reduzieren wird der Arbeitsspeicher (Memory) groß genug gewählt. SJMR-LargeMem versucht dies noch zu verbessern, indem er das Schreiben der spatial property auf die Festplatte von Anfang an unterbindet. Abbildung 15 stellt den Vergleich bei einer Reduce Task Anzahl von 8 dar. Man kann erkennen, das SJMR besser arbeitet als SJMR-Large Mem. Das liegt vor allem daran, dass SJMR-Large Mem Konvertierungen durchführen muss. Es muss die spatial property von jedem Tupel von einem String zu einen spatial object konvertieren, während SJMR die spatial propertys einfach nur ausließt. Somit bring das Reduzieren der Schreiboperationen nicht den gewünschten Performancegewinn bei SJMR-Large Mem. 1 vgl. [3] Seite 7 Seite 17

210 Mit Zunahme der Knoten verbessert sich allerdings bei beiden die Performance, da mehr Reduce Tasks gleichzeitig ausgeführt werden können. Abbildung 15: Vergleich der Performance von SJMR und SJMR-LargeMem bei einer Anzahl der Reduce Tasks von 8 Quelle: [3] Seite8 6. Folgerungen In der vorliegenden Ausarbeitung wurde erklärt, wie Spatial Join effektiv implementiert und mit MapReduce auf Clustern beschleunigt werden kann. Der entwickelte Algorithmus wird SJMR (Spatial Join with MapReduce) genannt. Soweit bekannt ist, ist SJMR der erste parallele Spatial Join Algorithmus für MapReduce, der es Spatial Joins erlaubt MapReduce- Plattformen in Clustern zu verwenden. Die Strategie von SJMR kann auch bei anderen parallelen Umgebungen eingesetzt werden, besonders wenn keiner der Inputdatensätze einen Spatial Index hat. In Performancetests wurde auch die Realisierbarkeit und die Effizienz von SJMR nachgewiesen. Es hat sich herausgestellt, dass MapReduce auch in rechenintensiven Spatial- Applikationen und kleinen skalierten Clustern anwendbar ist. Seite 18

211 I. Quellen [1] (zuletzt eingesehen am ) [2] (zuletzt eingesehen am ) [3] SJMR: Parallelizing Spatial Join with Map Reduce on Clusters, Shubin Zhang, Jizhong Han, Zhiyong Liu, Kai Wang [4] (zuletzt eingesehen am ) [5] Spatial Join Techniques, Edwin H. Jacox and Hanan Samet, Computer Science Department, Center for Automation Research, Institute for Advanced Computer Studies, University of Maryland, College Park, Maryland [6] (zuletzt eingesehen am ) [7] (zuletzt eingesehen am ) [8] (zuletzt eingesehen am ) [9] (zuletzt eingesehen am ) [10] (zuletzt eingesehen am ) [11] (zuletzt eingesehen am ) Seite 19

212 II. Abbildungsverzeichnis Abbildung 1: Beispiel für einen Spatial Join... Seite 4 Abbildung 2: Beispiel für ein minimal umgebendes Rechteck....Seite 4 Abbildung 3: Verteilung des Daten. Seite 7 Abbildung 4: Menge von Objekten.. Seite 8 Abbildung 5: Beispiel für die Anwendung der Z-Kurve.....Seite 9 Abbildung 6: Beispiele für die Hilbert-Kurve. Seite 9 Abbildung 7: Anzahl der Variationen....Seite 10 Abbildung 8: Replication Overhead bei Erhöhung der Anzahl der Felder Seite 11 Abbildung 9: streifenbasierter plane sweeping Algorithmus.Seite 13 Abbildung 10: Referenzierende Feldmethode...Seite 15 Abbildung 11: Übersicht über die Daten...Seite 15 Abbildung 12: Einfluss der Streifenanzahl Seite 16 Abbildung 13: Einfluss der Knotenanzahl.....Seite 16 Abbildung 14: Vergleich der Performance von SJMR und PPBSM.Seite 17 Abbildung 15: Vergleich der Performance von SJMR und SJMR-LargeMem bei einer Anzahl der Reduce Tasks von 8 Seite 18 Seite 20

213 Seite 21

214 FernUniversität in Hagen - Seminar Summer semester 2011 Map/Reduce and Databases Topic 14 Map/Reduce for multi-core machines Speaker: Frank Thiele

215 Table of Contents 1 Introduction to Map/Reduce on SMP systems The programming model Map/Reduce Phoenix 2 - Map/Reduce using shared-memory Applied optimizations for shared-memory based Map/Reduce Performance related properties of the input data Optimizations implemented in Phoenix Parameter tuning in Phoenix Ostrich Tiled-Map/Reduce Design related performance improvements Implementation related performance improvements Fault tolerance Test results for Ostrich Metis Phoenix Additional optimizations IO Overlapping Extending the Pipelining concept of Ostrich Optimizing the Final-merge phase Combination of cluster and shared-memory based Map/Reduce Hadoop and Multi-core systems Optimization of Apache Hadoop using Phoenix Summary and Conclusions...20 References

216 1 Introduction to Map/Reduce on SMP systems This article is about the optimization of symmetric multi-processing (SMP) and chip multi-processing (CMP) based Map/Reduce framework implementations. The 1 st chapter will give a short introduction to the algorithm of Map/Reduce and introduces Phoenix 2 as the example to explain some optimizations with. Those optimizations are explained in more detail in the first sub chapters of chapter 2. Chapter 2.4, 2.5 and 2.6 describe some more sophisticated frameworks which were released after Phoenix 2. Chapter 2.7 describes some additional ideas to generate more speedup. The 3 rd chapter shows up some ideas of how to integrate the high performance SMP Map/Reduce frameworks with the cluster based framework Apache Hadoop. The last chapter summarizes this article. 1.1 The programming model Map/Reduce The idea behind the parallel Map/Reduce programming model is to support a lightweight application design easing the efficient use of the emerging multi-core and many-core systems such as CMP/SMP machines and cloud-based clusters. The reason for the simplicity is the small interface given by the Map/Reduce model which enables a framework to encapsulate all parallel activities like socket communication and thread synchronization. The two basic functions of Map/Reduce are map() and reduce(). The map functions normally expects a single parameter called key. The output of the map function is a pair (or a vector) which represents the transformation of the key to a <key, value> pair. The value can contain any simple data type, but also more sophisticated data structures such as trees or hash maps. The keys are retrieved from the input of the problem domain and passed to the map() function. The processing of the input is designed to be done in parallel as the programming model assumes the input data to be independent of each other. This is mostly achieved by splitting up the input into several splits and processing each split in parallel by a separate mapping process called the Mapper. The phase of applying the map() function is called Map phase. The output of each Mapper is usually stored into several partitions to support the parallelization of the reduce() function. The assignment of a key to a partition in the Map phase is done by applying a function on the key, e.g. a hash. Each key of a split is so put into a set of r partitions containing the <key, value> pairs generated by the map() function. In the Merge phase those sets are merged by the Map/Reduce framework into a single set of r partitions which is the input for the Reduce phase. Equal keys (defined by the user) are now often grouped to a <key, values> pair within this phase. This merging is based on the fact that each Mapper has used the same partitioning schema so that a certain key can always be found in the same partition created by any of the various Mappers (if it exists). After the Merge phase (and of course after the Map phase, too) each partition can contain several values for the the same key which needs to be aggregated now. In the Reduce phase it is the reduce() function which aggregates the set of values of a key into a single value. The reduce() function reduces a pair of type <key, set of values> into a pair of type <key, value>. Of course, it is also allowed to generate more than a single record or no record (which applies for the map() function, too). The reduce functions are working on r partitions, for each partition created in the Merge phase there is a single Reducer processing its content. The output generated by the Reducers is split up into r parts which needs to be put together by the framework. As the moving of data from one node to another (e.g. from the Mapper to the Reducer) is one of the 2

217 most important cost factors, an optional Combine phase can be included which is executed between the Map and Reduce phase. By applying a function called combine() by the Combiner (which in most cases is equal to the reduce() function) the local amount of data to copy over the network to another machine can be decreased significantly. If the available memory to a CMP/SMP is limited, this method can also be used to reduce the amount of required memory. The usability of the Combine phase depends on the application: If the reduce() function does not require the exact count and order of the values for a key, the combine() method can be invoked. To summarize this: Each Map/Reduce model implementation consists of 3 (or 4) phases which are executed sequentially: Map phase Combine phase (optional) Merge phase Reduce phase. If one can apply the application based problem into an algorithm using those two or three little methods, he can make use of an easy to implement way of parallel processing, either on clusters or on a single CMP/SMP host. Illustration 1: Basic Map/Reduce design principle 3

218 1.2 Phoenix 2 - Map/Reduce using shared-memory The maybe most popular implementation of the Map/Reduce model based on shared-memory system is Phoenix. The most frequently used version of the framework is and was released in May of It is written in C++ and uses the PThread library. This enables an application using Phoenix to spawn several threads instead of processes to let the Mappers and Reducers communicate via the process internal memory space which results in the lowest overhead possible. The framework supports the Map/Reduce model for all type of data structures where a value can be mapped to a key which is of type Comparable. The difference compared to a normal Map/Reduce implementation designed for cluster computation is that the communication between the Mappers and Reducers is done using shared-memory (the OS system shared-memory model is not meant here). This enables the framework to do a lot of optimizations and grouping of communication related data structures. In Phoenix, the main data structures are the Intermediate buffer and the Final buffer. The Intermediate buffer is filled by the Mapper threads and read by the Reducer (and Combiner threads). The Final buffer is filled by the Reducer threads. As an optimization, the framework allocates a configurable number of threads before starting processing. Those are summarized in the Thread pool and can be used to process data. The data set a thread can processes is called a Task. Phoenix differentiates 3 types of tasks, Map tasks, Reduce tasks and Merge tasks. The processing and the phases are easily comparable to the general Map/Reduce model. The processing is sequential as like as in the original model, meaning that before a phase has not finished, the next one cannot start. The order of the Map, Merge and Reduce phase is also equal. Because the Map and Combine phase both work on the Intermediate buffer, they are summarized in the illustration 2 as a single phase. The Merge phase in between the Map and Reduce phase is done by the framework within the Reduce phase and therefore not explicitly mentioned in the illustration. The little difference between the generic model and Phoenix is the second Merge phase at the end of the processing which is used for sorting the output by key. This one does not exist in the generic model and therefore I named it Final-merge phase. To get an idea of the design of Phoenix the illustration 2 demonstrates the flow of data and the usage of multi-threading. It shows an input data structure that is divided into 4 splits which form the Mapper tasks. Those Mapper tasks are run in parallel by the threads of the Thread pool. There is a so called Dispatcher thread that is responsible for allocating the tasks of the current phase and assigning them the the worker threads. The results (pairs of <key, values>, that means that equal keys are grouped together in Phoenix 2) for each Map task are stored in a row of the intermediate buffer and partitioned into a fixed number if columns which is based on the number of Reduce tasks defined by the user or framework. Then follows the optional Combine phase in which each bucket of the Intermediate buffer is reduced based on the user-defined combine() function. The next step is to execute the Reducers in the Reduce phase for each Reduce task in parallel. Such a task corresponds to the data stored in a column of the Intermediate buffer. As already mentioned, the Merging of the different Mapper outputs is done within this phase by merging the already sorted buckets together (as like as in the normal Merge-sort algorithm). The output of the Reduce phase is put into the Final buffer which keeps <number of Reduce tasks> sorted results (pairs of <key, value>). In the Final-merge phase, those sorted results are then Merge-sorted into the Result buffer which can be used by the application/user. 4

219 Illustration 2: The Phoenix 2 design (based on a figure in [OSTRICH]) The interface to the Phoenix framework consists of a set of functions and data structures accepted and returned by those functions. The important functions of the interface are: int map_reduce_init() and int map_reduce_finalize() int map_reduce(map_reduce_args_t * args) This one is used to start the Map/Reduce job which is further defined by the data structure pointer given as the only argument. The following points are a part of the supported interface options defined by the argument: Pointer and length of the memory location where the data is to be read from Splitter function pointer, to define an application-specific splitting of the input data Mapper function pointer Combiner function pointer, optional 5

220 Reducer function pointer, optional Comparator function pointer, to define application-specific key comparing Partitioner function pointer, to define application-specific partitioning of the keys (used in the Map phase) Result set pointer, used to hand over the pointer to the actual data to the user Flag configuring the amount of Map rows stored in the Intermediate buffer Flag configuring the amount of Reduce task results stored in the Final buffer void emit_intermediate(void *key, void *val, int key_size) This function is used by the user-defined map() function to emit (intermediate) output pairs. void emit(void *key, void *val); This function is used by the user-defined reduce() function to emit (final) output pairs. 6

221 2 Applied optimizations for shared-memory based Map/Reduce 2.1 Performance related properties of the input data According to the [PHOENIX++] paper, there are several types of input data that can occur in real-life applications and for each of them a different set of optimizations is required. They categorize the input by using 3 dimensions: Dimension 1 The amount of keys and its distribution emitted by a Map task are described with this dimension. There are 3 sub-types: *:* Each Mapper emits an unknown number of keys, the distribution of the keys is unpredictable. e.g. Word count *:k Each Mapper emits up to k different keys, but the amount of keys is not known. e.g. Histogram, String match 1:1 Each Mapper creates a single output key. e.g. Matrix multiply Word count is a good example for the *:* distribution type. For this one, Phoenix 2 has been optimized. This can be seen in the Intermediate buffer implementation. It uses a fixed hash partitioning which fits pretty good for normal distributions (if the buckets do net get too big and there is no key that occurs more often than others). But for the other two types, a much smaller, easier to use and more efficient data structure should be used, e.g. a simple and maybe sorted array or a B-tree. Dimension 2 This dimension describes the number of emitted values per key. There are two general sub-types, one or a few values per key and a lot of values per key (e.g. Word count). The latter one is best optimized by using Combiners as those reduce the amount of required memory. A typical property of this dimension is that is scales with the size of the input if more input data is processed, then more values for the same key are generated. As Phoenix 2 was optimized for Word count, it enables the user to insert a Combine phase between the Map and Reduce phase. A Combiner task operates on a bucket of the Intermediate buffer. This dimension becomes more and more important if you take into account, that one could store the <key, value> pairs separately. As Phoenix 2 groups equal keys together (in the buckets), this is also some kind of optimization to reduce the amount of required memory. Dimension 3 The per task computation describes the share of computation time for the custom code (e.g. the map() function) compared to the framework code. Applications like Histogram spend pretty less time in the custom code (low task computation) an so the 7

222 library performance is more affecting the overall performance compared to a typical high task computation application like Matrix multiply or even Word count. 2.2 Optimizations implemented in Phoenix 2 From the algorithmic and implementation point of view Phoenix 2 has been steadily optimized until its stable release The following listing shall summarize the main points grouped by optimization type which I found during studying the source code. Implementation optimizations (PIO1) The keys are grouped together in the Intermediate buffer (<key; values> pairs). This saves memory and reduces the Cache pressure. (PIO2) Instead of copying the whole object (a key or a value) only pointers are used. This enables fix-length data structure implementations, reduces the Memory and Cache pressure and increases Data locality. The latter one is achieved because the pointers are often moved within the bucket which benefits from the less amount of memory space required fitting now better into the limited Caches. (PIO3) The buckets of the Intermediate buffer and Final buffer are pre-allocated using the default value (10 keys). If the bucket gets full, its size is doubled. This reduces the amount of concurrent memory allocations which may be a bottleneck in a multi-threading environment (see [OSTRICH]). (PIO4) The Map tasks (input data splits) and Reduce tasks are tried to be created to fit into the first-level Cache to increase the Data locality of the Mappers and Reducers. [Due to an implementation defect this does work only for the Map task allocation, see function env_init() of map_reduce.c] (PIO5) A typical C data structure optimization is applied, too: Cache-line alignment. (PIO6) A worker is bound to a CPU/Core. In case of CMP, this enables a thread to always work on the same CPU and Core which again enables it to always use the same Cache. This reduces first the duplication of Cache-lines which decreases the Cache pressure and second it speeds up the thread as it is not waiting for the Cache to be filled again with the working set of its current tasks. Algorithmic optimizations (PAO1) The buckets of the Intermediate and Final buffer storing either <key; values> or <key; value> pairs are implemented using a Binary Search based array insert method (before it was a linear search!). (PAO2) The task concept is used to limit the unfairness between the worker threads (Mappers, Reducers and Mergers). If there were no tasks, then the input would be split up into #workers and the partitions into #workers. This tends to be unfair as the input as well as the partitions may have a bad distribution of keys. Also, due to scheduling issues, page faults and so on the workers are never equally fast. Because Phoenix 2 uses the strict phase concept of Map/Reduce (no phase begins before the previous one has completely finished), each phase will be as slow as the slowest worker. The impact of this limitation is reduced by using smaller jobs which Phoenix refers to as tasks. (PAO3) The Intermediate and Final buffer are created in a way preventing the requirement of locks between the different workers of phase. This enables faster processing as the waiting time for RW accesses to the buffer is eliminated and the OS is not involved. The partitioning of the 8

223 keys is one example which is further explained in chapter 2.5. (PAO4) Optionally, the user can decide to use the option single_output_per_thread instead of single_output_per_task (for the Map and Reduce phase). This enables the reduction of the internal bucket fragmentation as less buckets are used. But I think that this can reduce the Data locality as the bucket will become pretty big (factor: #Tasks / #Threads), especially if there are only a few values per key. As this is impacted by PIO3, too, the advantage or disadvantage depends on the input (dimensions 1 and 2) and needs to be tested by the user. (PAO5) There is no lacy master thread dispatching the work only. Even this main thread consumes tasks for processing after having dispatched the work of a phase to the normal worker threads. 2.3 Parameter tuning in Phoenix 2 There is tuning notes document attached to the framework tar ball which gives several hints regarding optimizations which are based on application, library and OS points. For the application, it suggests to increase the L1 Cache size parameter which directly affects the Map task count (and ideally the Reduce task count, too, see PIO4). This one replaces the automatically applied L1 Cache optimization mentioned in PIO4. By manually finding the best size for the application this optimization can be applied. The input data can be read using the mmap or read system call. The document tries to explain a scaling issue in case of using mmap with too many threads and suggests to try to replace the mmap with a simple read system call. What it does not mention is the disadvantage of this version: The increased memory usage of the read system call which is caused by the OS buffer pages and File cache pages as well as the application pages. So the user needs to find the optimal way by sacrificing free memory for enhanced scalability. With respect to library optimizations the document reports a problem with the Intermediate buffer. If the number of partitions is too small, then the number of reallocations grows significantly and reduces performance (especially in case of multi-threading, see PIO3). Too large values on the other hand lead to empty partitions which generate processing overhead in the Reduce phase. The user needs to tune the parameter default_num_reduce_tasks / extended_num_reduce_tasks (related to single_output_per_thread vs. single_output_per_task, see PAO4). This directly refers to the dimension 1 of the input data types. Another library optimization the user can apply is to change the scheduling policies which is not further explained here. The more interesting library optimization is the usability of the combine() function which needs to be turned on by a flag which requires recompilation! This looks like another defect in the framework as the user is already able to configure the usage of combine() by using the C interface. The operating system tuning comments are about the adaptation of the page size and the switch of the memory allocation library. The former one is said to be of less impact than the application-specific optimization of the L1 Cache size parameter. So because of that and the fact that you are hacking your OS which likely creates unwanted side-affects I cannot re-recommend this optimization. The latter one is said to be critical as the Map phase puts heavy pressure on the allocator. With focus on concurrent memory allocations, the resulting scaling problem is also mentioned in [OSTRICH]. So by changing the memory allocator the user can experiment with the best allocator for his environment. 9

224 2.4 Ostrich Tiled-Map/Reduce The Tiled-Map/Reduce functionality is described in the [OSTRICH] paper. It introduces the application of an Compiler optimization technique known as Blocking to the Map/Reduce model. This shall increase Data locality and reduce the memory requirements by processing the input splits fully and merging the final results together. This is best explained with the following graphic that is based on the figures of the original paper. This design was implemented in Ostrich which is based on Phoenix 2. Illustration 3: Tiled-Map/Reduce - The design of Ostrich (based on a figure in [OSTRICH]) The difference to the design of Phoenix 2 is the Iteration buffer and the usage of so called Iterations. The splits of the input done in Phoenix 2 are now grouped into Iterations. In theory, this requires the input not to be completely in memory only the current Iteration is needed to work on it. Those iteration groups are processed in the Map and Combine phase. All rows of a partition (represented by a column) are in contrast to Phoenix 2 reduced in the Combine phase. The reduced results of an Iteration are then stored in the Iteration buffer. 10

225 After having finished the multiple Map and Combine phases, the Reduce phase is invoked. There, the different Iteration results are reduced (and internally merged, too) into the already explained Final buffer. The rest of the processing is now equal to Phoenix 2. The big problem of Ostrich is its licensing model. Neither the code nor the compiled library were published by the Chinese authors Design related performance improvements Reducing the required memory size The performance of Ostrich over Phoenix 2 is increased by several changes. With respect to design the major point is the decreased memory requirement. There are three reasons why Ostrich requires less memory than Phoenix. The first is that Ostrich does not require the input file be be completely in memory all the time as the keys are copied. This seems to be configurable but is not explained directly. To configure this sounds reasonable as there is always a trade between the memory copy costs (time for copying and allocating and the required space) and the costs of the higher memory amount required (time with respect to allocate it and paging/swapping as well as required space (which is also limited by the size of the virtual memory!)) to cache the complete file. The memory copying is done in the Combine phase and becomes more efficient with an increasing share of duplicated keys between the different input splits because the required memory in the Iteration buffer decreases. Furthermore, the access to copied together keys tends to be faster as the keys in the input are more spread around and not compressed together which reduces the Data locality when those keys are accessed. The implementation of this is not mentioned in the paper but a good idea to do this is the following: The unique input keys are copied into a (maybe cache-aligned) length-value buffer (to not negatively impact the Iteration buffer implementation which can store fixed-length pointers only if a separate buffer is used) which exists for each Iteration and each partition of it (to be lock-free usable by Combiners and Compressors). Those buffers are allocated based on the size of the previous Iteration to reduce the allocation time. Within the Compress phase (and maybe the Reduce phase) those buffers are then merged or re-created as well as the normal buffers. If there are applications that use the value as a pointer into the input, too, than the value needs to be copied as well. This of course requires a lot more memory, especially if the value object is pretty big. In such cases the next optimization is even more a valuable improvement. The second reason for efficient memory usage is that the results of the Map phase are earlier reduced by exploiting the Combine phase. All Map task outputs belonging to a certain partition are reduced into a single bucket of the Iteration buffer representing this partition. Before, the Combiners only reduced buckets and they were called only once after the complete Map phase has finished. In addition to better exploit the Combine phase, the Iteration buffer is pre-reduced within the new Compress phase by applying the reduce() function before the Reduce phase formally begins. I think that instead of using the reduce() function here, the combine() function is also functionally correct. The only difference is the use case: According to the hints of the authors, the combine() function is invoked on the Intermediate buffer, the reduce() function in contrast to that to the Iteration buffer. So by differentiating the user-supplied functionality from the framework functionality, the combine() function can replace the reduce() function. 11

226 The Compress phase is triggered by the framework transparently to the user (e.g. when a threshold is reached). Both, the Compress and the Combine phase require the application provided reduce() and combine() function to be independent of the number and order of the values. This may be a reason not to use Tiling for some applications, but for most this will not matter. As a rule of thumb one can say that whenever you can use a combine() function in a cluster based Map/Reduce environment, this can be used in a shared-memory environment, too. Pipelining What is also pushing up the performance is the Pipelining concept of Ostrich. The Map/Reduce model is based on a strict phase concept. If for example a Mapper has not finished all its tasks, the Reduce phase cannot be started. As the tasks in Phoenix 2 are retrieved from a global task buffer created by the Dispatcher, the unbalance is restricted more or less to the very last tasks. The Tiled-Map/Reduce model uses several iterations of the Map and Combine phase. But as the amount of tasks the worker threads are working on has been decreased (Iterations group together less tasks than before) and the step from the Map and Combine phase is invoked several times, the unbalance between the splits/tasks may sum up to an even bigger problem than without using iterations. Ostrich does not solve this problem completely. But Ostrich tries to handle the unbalance between the Combiners (which exists for similar reasons) by allocating two Intermediate buffers. They are used in a round-robin fashion. If one Reducer thread has no tasks left, it is going back to the Map phase and becomes a Mapper of the next Iteration which uses the other Intermediate buffer. After the last Reducer of the current Iteration has finished, he is the last one to switch over/back the the Map phase of the next Iteration Implementation related performance improvements General topics Regarding implementation, Ostrich has done also some steps forward. One thing is the reduction of the memory allocations and deallocations which is achieved by reusing the Intermediate buffer. Between two iterations, the data structure is only reset by (more or less) setting its length parameters to zero. Another optimization is the dynamically adaptation of the task size of a Mapper process which is only indicated in the paper. My interpretation of this is the following: The Mappers process the first Iteration using a default or estimated task size (equals the input split size). After this Iteration has finished, the memory requirement is retrieved and based on that the optimized task size is calculated for the next Iterations. This should be equal to the first-level Cache size (see Phoenix optimization PIO4) but also depends on the relation between task count per Iteration (n times the number of first-level Cache) and the size of the output of the Combine phase (the Iteration buffer requires space in the Cache lines, too). Also the Intermediate data structure requires some Cache lines and therefore can reduce the task size or count per Iteration, too. CMP optimizations There is also a way for Ostrich to improve the scaling on CMP systems, too. The problem there is the duplication of Cache lines reducing the Cache efficiency and performance as well as the non-uniform memory access (NUMA) caused by the architecture. The authors suggestion is to further group the Iterations. Each Iteration group is now processed from the Map phase up to the Reduce phase on a static CPU (with many cores). To balance the Jobs for each CPU, a work steal algorithm is applied. Effectively, the complete Map/Reduce model (map()->combine()->merge()->reduce()) is applied to 12

227 each Iteration group. This enables each CPU to work more autonomic which in general should prevent access to memory of different CPUs or Cache lines. To reach this without a central Dispatcher being likely the bottleneck in a highly scalable environment there is a Dispatcher thread (being a worker, too) on each CPU which starts the phases for the worker threads of each CPU. What is not fully explained but indicated in a figure is the Reduce phase. My interpretation of this is that the Reduce phase is split into two parts. Each CPU reduces there own Iteration buffer into an intermediate Final buffer. Then those intermediate Final buffers are merged and reduced into the (full) Final buffer by Reducers which work on data attached to different CPUs. Instead of splitting the Reduce phase, the Compress phase could also be used to create the intermediate Final buffers. As the data exchanged here has already been minimized, the costs are less then processing the data without taking the dependency between memory, Cache and tasks into account Fault tolerance Ostrich also introduces the ability to store intermediate results which can be restored in the case of an error. As most of the jobs do not take longer than a couple of seconds, this is not really required for typical applications. But as Ostrich can process files larger then the virtual memory and because of applications with a very high computation per task value (dimension 3), this option can be useful Test results for Ostrich The following benchmark results are taken over from the paper and are based on the original Phoenix 2 benchmarks. Performance impact of the input size For the Word count example used in the paper, the speedup is increasing with the size of the input file. For a 1GiB file, the factor is 2.75, for a 4GiB file it is The impact on the distributed sort example is comparable, but the speedup is not that high (2 to 2.25). For applications like Log statistics and Inverted index, the possible performance improvement of up to 50% is still significant, but much lower. This seems to be caused by the different required memory space in the Intermediate buffer. The more space is required there, the higher the speedup is. Memory space required The required memory space is reported to be around 25% compared to the Phoenix 2 library. For applications like Log statistics it is much less, but for Distributed sort it is higher (about 70%). Performance impact of the core count The test setup is based on a SMP machine with up to 16 cores. Throughout all applications, the scalability is improved. The highest speedup was reached for Distributed sort, the smallest for Inverted index. 13

228 2.5 Metis Metis is as like as Phoenix and Ostrich a Map/Reduce framework for multi-core machines. Metis is based on the design of Phoenix 2 but adapts the data structures and some other implementation details to improve the performance. Hash and B+Tree First, the Metis library optimizes the Intermediate buffer. This one is according to the authors of Metis (and Phoenix++) the main bottleneck of a multi-core using Map/Reduce implementation. This is because of the different input data types, the varying formats the Map and Reduce phases require and the potential of locking between different workers. As Phoenix 2 has addressed this with a fast, lockfree and easy to implement Matrix data structure for the buckets to store the key-value pairs in, there was nothing to optimize in the transformation principle itself. But the problem of Phoenix 2 is the data structure of the bucket itself. There, a simple sorted array is used where the insert (and lookup) is boosted with a Binary search. But in the average case the insert itself requires half of the bucket to be moved in memory. Metis addresses this with a B+Tree within each bucket. This data structure can be accessed in a sorted order (as like as in Phoenix 2) which is required by the Reducers to Merge-sort the different columns of the Intermediate buffer representing a partition. But what is more important is the lower complexity: Phoenix insert costs into a bucket: O(log n) + O(n) [Binary search + memory copying] Metis insert costs into a bucket: O(log n) + O(1) [Tree search & adapt + memory copying] What has not been mentioned in the Metis paper is the higher memory usage of a B+Tree which results in worse Data locality. But as the copy operation of an insert is required only in the leafs instead of the complete bucket and because of the little amount of B+containers to write into (log n), the negative influence of less Data locality is smaller than the advantages of the B+Tree access. The paper does not explain that only in the case of an odd key distribution, the B+Tree is advantageous over the sorted array of Phoenix 2. This is because by using a higher partition count, the advantage of the B+Tree in case of an even distribution is gone because the buckets can all be equally filled with the same amount of keys that fit into a leaf of the B+Tree (and so the copying costs are equal). As already indicated, static hashing is used in both libraries as an extension to the B+Tree/sorted array. The key is hashed into one of several partitions which on the one hand enables the lock-free scaling of the Reducer phase. On the other hand allows hashing to reduce the Insert costs because instead of using a single B+Tree (or a sorted array) several buckets are used which reduces the amount of keys per Tree or array. The Metis paper states that by using a well sized partitioning schema to hash the keys into buckets, the usage of a B+Tree does not really matter as the complexity is nearly constant (which must apply for the same reason for Phoenix, too). The usage of static hashing in Metis makes Metis optimal for *:* key distributions, but sub-optimal for others (according to the thoughts of [PHOENIX++]). Metis compares this also against a so called append-only buffer. This one simply appends the keys and sorts them at the end of the Map phase. This data structure is better suited for key distributions with less repeated keys (dimension 2 of the input data types as only a few values for a key are expected) as the final sort depends on the number of keys and the size of the Intermediate buffer is not affected too much. The sorting part can benefit from better Data locality within the bucket compared to the B+Tree. But with an increasing share of repeated keys, the advantage of this structure becomes a disadvantage 14

229 as the B+Tree and the Phoenix 2 sorted array are both grouping together keys which reduces effectively the sorting and inserting complexity. As the optimal prediction of the number of keys and its repetition share is often not possible, the Hash and B+Tree solution fitting good but not perfect for all situations is a sensible one. This has been proved in the performance related tests of Metis. Parallel Sorting by Regular Sampling The Final-merge phase in Phoenix 2 sorts the keys and puts them into the output. The problem there is the Merge-sort algorithm which does not use all of the worker threads. Between each phase of the Merge-sort process, the number of workers is divided by two! Metis addresses this by using the Parallel Sorting by Regular Sampling algorithm which scales better because it uses all cores during the sorting process. Memory allocator As like as documented in the [OSTRICH] paper, the Metis authors found the memory allocator to be a bottleneck in a multi-threaded environment. The authors have tested some alternative allocators and found with Streamflow the best-fitting allocator as it performs synchronization-free allocations in most of the cases. Tiling? Metis does not require the input file to be in memory all the time which enables the application to process input files larger than the virtual memory. How this is achieved (e.g. by tiling) is not explained, but a part of the means to realize the required independence is to copy the keys into an input independent data structure. There is a copy function introduced with Metis which is invoked for every new key that was found. This is also a difference to Ostrich which copies the keys later in the Combine phase. Combiner The Combine phase seems to be adapted, too. The Combiners are invoked much more frequently. For each key that is inserted into the Intermediate buffer, the combine() function is called. This directly optimizes the dimension 2 of the input data type. By calling the combiner() function more often, the memory usage is lower. This results in less memory allocation calls and increases Data locality. The overhead of calling the Combiner more often depends on 2 nd dimensions of the input data type (a few or a lot of values per key). I think it is sensible to build in some kind of Heuristic, e.g. calling combine() for every second (or so) insert of a value to a key and after the Map phase has finished (like in Ostrich where the combine() method is used to fill the Iteration buffer). This divides the number of Combiner calls by 2 but does not increase the memory usage too much. 2.6 Phoenix++ In June of 2011, a team of the Stanford University has released a new version of Phoenix, called Phoenix++ (or Phoenix 3). The changes are described in a paper and will be summarized here. Intermediate buffer The authors found out that the static hash function is sub-optimal for a lot of applications. Even for Word count, where Phoenix 2 was optimized for, the static hash lead to the problem that the buckets 15

230 were not optimally filled. With Phoenix++ they introduced 3 different types of Intermediate storages. The first one is a dynamic hashing algorithm, which creates a hash store for each Mapper thread (not task) which fits best for *:* key distributions. This enables the store to be used much more efficiently as the framework tries to reach O(1) insertions at any time. The problem here is the combination of the possible different hash sizes into a common one the Reducers can work on. This is achieved by recreating a common hash structure. The authors say that this costs some time, but the overall performance shall still be higher compared to a fixed-length table. I think the authors could have used a more sophisticated algorithm to avoid copying, e.g. when using linear hashing, dynamic hashing or expandable hashing one should always find a simple function that transforms the common hash bucket number into the bucket number of a certain Mapper thread. The second alternative is to use a fixed-length array for each Mapper thread which fits best the *:k key distribution. For 1:1 key distributions, a common array is used (one for all Mapper threads). There is also an interface for the user to implement its own Intermediate buffer data structure which best fits the applications input data type. The <key, value> pair is now stored in a so called container. Each hash bucket can contain several containers (or pointers to them) the authors leave the question of sorting the containers within bucket open. This is important to have a fast access to the keys inside. The fixed-length array does only include a single container as there is only a single key per container. Combiners The combine function is now called after every emit of pair from a Mapper. This reduces the memory pressure a lot. It can be compared to the Metis improvements as there the same optimization was applied. Also, the same possible additional improvements I have mentioned could be applied here. Tests have shown that the performance degradation is less than the performance improvement due to better Data locality and less memory usage (which can cause swapping!). C++ Phoenix++ uses C++ as programming language. This means that the usability of Phoenix has been improved severely, but the performance could be negatively affected because of the several micro functions that are called in a object oriented programming language. The authors say that this is prevented by using method inlining. Custom memory allocators The already known bottleneck was now addressed by being able to configure the memory allocator at a central point, the library Interface. Therefore, the allocator needs to implement the STL custom allocator interface and can then be used by the Containers (Mappers) and Combiners. Sorting Sorting is now optional. It can be turned off or a custom sorting algorithm can be used instead of the default one (see also chapter 2.5 (Metis) and 2.7.3). 16

231 2.7 Additional optimizations IO Overlapping The Tiled-Map/Reduce model using only parts of the input in memory loads the input data of the current Iteration and blocks until this has been done. This can consume much time and the worker threads are idle in between. The input file loading can be overlapped with the processing of the data already loaded into the memory which reduces the waiting time of the workers. In the case of not using mmap, a double-buffer (like in the Pipelining concept of Ostrich) and a new user-defined load() method (which was also introduced in Ostrich, too (called acquire())) can be used to achieve the IO overlapping the following way: 1 The user-defined load() function is invoked to store the input data into an input buffer which is allocated by this function. 2 This buffer is then split to generate the Mapper tasks of the first Iteration. The Map phase is now started. The pointer to this buffer is stored by the framework as current Input Iteration Buffer Pointer (current IIBP). 3 While the Map phase of the current Iteration is running, the input data of the next Iteration is preloaded by invoking the user-defined load() function again (in a separate thread). This function allocates again a new buffer and stores the input for the next Iteration in it. The pointer is returned to the framework which refers to this buffer as next IIBP. 4 After the current Iteration has finished the current Map and Combine phase, the next Iteration is dispatched. This means that the next Iteration becomes the current and therefore the next IIBP becomes the current IIBP. The old current IIBP is saved as old IIBP. Please note that this requires the keys (and values) to be copied into a separate buffer, see chapter The old IIBP is used as an argument to the user-defined load() function which is invoked now to preload the input for the next Iteration. As the buffer is already defined, no new space is allocated the buffer is reused instead (this reduces memory allocations). The old IIBP is returned and becomes the next IIBP. If the returned pointer is zero, then the application has no more input left for processing in the next Iteration. 6 Go back to step 4) until there is something to load, otherwise go to 7) after the current Iteration has finished. 7 The current and old IIBP are used as an argument for the new user-defined function release(). This one deallocates the memory of those buffers. As like as the user-defined input splitter() function which splits up the input according to the keys found, the load() function must be aware about the key (and value) structure, too. This can best be explained by an example where the input is a text file and the keys are single words. If the framework requests the load() method to load data from the input beginning from position P with a length L then the end of this part of the file may split a single key effectively into two keys. To prevent this, the load() method needs to be aware about the keys in the input. Skipping not complete or likely not 17

232 complete (which prevents the loading of an additional file block) keys and loading them in the next Iteration can solve this. This can be implemented with returning the effectively used part (P+L*) of the input to the framework that takes this into account when calling load() for the next Iteration (P_next = P+L*). Using mmap does not make sense here, as the blocks of the file are not preloaded. They are normally loaded on access and therefore IO Overlapping cannot be applied Extending the Pipelining concept of Ostrich As already mentioned in chapter the unequal distribution of Map tasks to Mappers is not solved with Ostrich. By using the idle Mapper threads of the current Iteration to start with the Map phase of the next Iteration (the data of the next Iteration has been preloaded by the IO Overlapping optimization and therefor there no waiting is required) as long as the last Mapper has not finished its task of the current Iteration, a theoretical performance improvement can be achieved. This requires a more sophisticated task priority queue where the current Iteration has higher priority than the next one (2 priorities for current and next phase should be enough). Also, this queue needs to include the Information of the task type (Map and Combine), so that the Mappers which are working on the next Iteration can go back and transform themselves into Combiners of the current Iteration after having stored their results in the Intermediate buffer of the next Iteration. Unfortunately, this will reduce the advantages of the Cache optimizations of the Tiled-Map/Reduce model because the data of the next Iteration is filling up the Cache-lines which likely overwrites the blocks of the current phase. This performance degradation can be limited by using only a fraction of the waiting Mappers and/or by decreasing the Iteration size (e.g. the 90% of the normal size, which increases the unbalancing but this is solved by Pipelining) Optimizing the Final-merge phase The Final-merge phase reads the data from all partitions of the Final buffer several times because it applies the Merge algorithm. This reduces the Cache efficiency because there is less Data locality than in a Mapper job and much more data is read than in a typical task of the Map phase (and even of the Combine phase). The problem becomes worse in a CMP environment as the memory accessed may be attached to a different CPU which results in higher latencies. What also consumes are lot of time is the comparing of the keys. This is done first indirectly as the Final-merge buffer includes only pointers to keys which further decreases Data locality. And second is this related to a function call of the user-defined compare() function which may itself take a while to produce the result (e.g. in the case of string comparing). By simply copying together the results in the Final buffer and so skipping first the multiple reading of heavily distributed memory locations and second the comparing of the keys, the performance can be increased. The disadvantage of this solution is that the result is not sorted any more. If the application does not require sorted keys, then a good framework can make the sorting in the Final-merge phase optional. Please note that the [PHOENIX++] paper suggests this kind of improvement, too. But as I found this idea in parallel to the authors of Phoenix 3, I leave this here as my own idea. 18

233 3 Combination of cluster and shared-memory based Map/Reduce 3.1 Hadoop and Multi-core systems Hadoop supports the processing on a single multi-core host, too. In general, one can say that the performance is much slower compared to a native SMP framework. Ostrich for example shall be more than 50x times faster then Hadoop (v0.19.1) on a 16 core machine. The reason for this is according to [OSTRICH] the slow communication between Mappers and Reducers over the file system and the JVM itself which is not able to perform as good as optimized C code. In addition to that, Java byte code and the JIT optimized ASM code does not make use of Cache hierarchy information. The interesting point here is that only in the multi-threading mode where a single buffer with a big lock is used between the workers, Hadoop was able to perform faster than in the single core mode (but the speedup is not that huge as the speedup of Ostrich vs. Hadoop). 3.2 Optimization of Apache Hadoop using Phoenix One can now think about extending the Hadoop framework with Phoenix (or Ostrich and Metis). This seems to be possible as Hadoop offers two features: Hadoop Streaming Hadoop Pipes The Pipes feature creates a socket based communication between the framework and a user program that is based on the Hadoop Pipes C library. The user program could be extended to be based on a native SMP library like Phoenix, too. The problem with Hadoop Pipes is the deprecation of most of its modules! Before using Pipes, one needs to re-factor the Java code (e.g. org.apache.hadoop.mapred > org.apache.hadoop.mapreduce) and fix a lot of bugs (Authentication does not work, input file reading either,...) and think about the optimal solution to pass the data to the user code. The easiest way is to use a (even standard) Java reader that pipes its output to the user process map() function that buffers this and begins processing after the data is fully available. By applying the idea of the IO Overlapping on this approach this seems to be pretty promising. The more sophisticated way is to use a custom record reader which can work as like as in a normal CMP/SMP framework use case. Another open point that needs to be solved here and which is tied to the user-based file reading is the response time to the framework. If the user-defined code takes too long for processing an input file, then the Job tracker will kill the job if there was no response given. Also, does Hadoop offer some kind of progress reporting which needs to be integrated in a Hadoop Pipes based solution where a custom input file reader is used (already prepared by the Pipes interface, but due to buffering this can generate problems). All those things refer to the Map phase only. In general, this can be applied to the Reduce phase, too, but the customizable input file reading must be skipped as the Reducer input is stored in an Hadoop internal format. To reduce the amount of data send around, the Combine phase should be used as well (which is of course supported by Pipes). This can be considered as the Iteration optimization applied in Ostrich. Hadoop Streaming, the other feature of Hadoop, pipes the input via STDIN (supported by Pipes, too) to 19

234 the user process which can buffer those <key, value> pairs and process them as described above for Pipes. In general, I would prefer Hadoop Streaming over Pipes as it seems to be the successor of Pipes and is better maintained by the developers. If you have a cluster which is based on several multi-core machines and want to use it for cluster based SMP Map/Reducing, then you need to also think about how to solve the statically configured parameters like the split size, the first-level Cache size, the core count and so on. This can be solved for example by using a configuration which is included in the job.xml configuration file of the Hadoop Map/Reduce job that is exploited by the user code (via environment variables). Phoenix 2 requires most of the tuning parameters to be set before the compilation of the program. If Phoenix 2 or another library with a comparable feature shall be used, the framework must be extended to dynamically use those parameters. Another problem to be solved is the heterogeneous ISA and OS a cluster (or grid) can contain. This can be implemented by using an intermediate step in the form of a platform independent programming language like Perl that loads the binary according to the environment detected. 4 Summary and Conclusions A lot of general and pretty specific optimization have been explained in this paper. It has been shown that the simple porting of the Map/Reduce model developed for clusters is working fine, but is far away from being efficient. A lot of points needs to be considered to enhance the throughput. Most of them belong to the implementation of data structures and using better algorithms. Some others refer to the design. What is interesting to see is the taking over of some principles from one framework into another, e.g. the combine() methods are called more frequently this was introduced by Metis and applied in Phoenix++. But there are still some significant differences, for example between Ostrich using Tiled- Map/Reduce and the new Phoenix++ release. The reason for not including Tiling in Phoenix++ is the adaptation of the Map/Reduce model, so the authors of Phoenix++. I do not share this opinion because the Tiling approach is normally using combine() to end an Iteration. If one recalls the cluster based Map/Reduce model, he can see that it uses map() followed by combine() only on a part of the input. This is effectively the same like Tiling, which becomes even more clear if you have a look at my explanations of the Compress phase and the CMP optimization used in Ostrich. But in general, this attitude of the Phoenix++ authors demonstrates that there is a branching of the Map/Reduce frameworks going on into a branch which will not adapt the model of Phoenix 2 and focus on the details of storing data and so on, and another branch which will adapt the design as well to reach further performance improvements. 20

235 References [PHOENIX] last visited in June 2011 [OSTRICH] [METIS] Chen, R. ; Chen, H. ; Zang, B.: Tiled-MapReduce: Optimizing Resource Usages of Data-Parallel Applications on Multicore with Tiling. In: Proceedings of the 19th international conference on Parallel architectures and compilation techniques ACM, 2010, S Yandong Mao; Robert Morris; M. Frans Kaashoek: Optimizing MapReduce for Multicore Architectures, June Published on: last visited in June 2011 [PHOENIX++]Justin Talbot, Richard M. Yoo, and Christos Kozyrakis : Phoenix++: Modular MapReduce for Shared-Memory Systems, June Published on: last visited in June

236 FernUniversität in Hagen - Seminar im Sommersemester 2011 MapReduce und Datenbanken Thema 15 Strom- bzw. Onlineverarbeitung mit MapReduce Referent: Jan Kristof Nidzwetzki

237 2 Jan Kristof Nidzwetzki, Thema 15: Strom- bzw. Onlineverarbeitung mit MapReduce Inhaltsverzeichnis 1 Abstract 3 2 Einleitung MapReduce Exkurs: Strom- bzw. Onlineverarbeitung Einsatzbereiche IBM InfoSphere Streams Map-Reduce Online Arbeitsweise des klassischen Hadoop Probleme der Onlineverarbeitung Pipelining Weitere Probleme beim Pipelining Pipelining zwischen verschiedenen MapReduce-Jobs Fehlertoleranz Online Aggregation Online Aggregation innerhalb eines MapReduce-Jobs Online Aggregation zwischen mehreren MapReduce-Jobs Einsatz in der Praxis Continuous Queries Fehlertoleranz Beispielanwendung: Aufbau eines Monitoring Systems Performance von Map-Reduce Online Performance-Tests Weitere Arbeiten DEDUCE: At the Intersection of MapReduce and Stream Processing SPADE Eine Beispielanwendung Beyond Online Aggregation: Parallel and Incremental Data Minding with Online Map-Reduce Architektur des MapReduce Framework Ermittlung des Job-Fortschritts und der Genauigkeit Vergleich der vorgestellten Arbeiten 15

238 Jan Kristof Nidzwetzki, Thema 15: Strom- bzw. Onlineverarbeitung mit MapReduce 3 1 Abstract Das von Jeffrey Dean und Sanjay Ghemawat [DG04] vorgestellte MapReduce Framework ermöglicht es, große Datenmengen parallel auf mehreren Computern zu verarbeiten. Von seinem Aufbau her, gestattet es das MapReduce Framework zunächst nicht, für die Strom- bzw. Onlineverarbeitung eingesetzt zu werden. In dieser Semiararbeit werden drei Arbeiten Map- Reduce Online [CCA + 09], DEDUCE: At the Intersection of MapReduce and Stream Processing [KAGW10] und Beyond Online Aggregation: Parallel and Incremental Data Minding with Online Map-Reduce [BAH10] vorgestellt, welche das Framework um diese Fähigkeiten erweitern. Der Schwerpunkt dieser Seminararbeit liegt auf der Arbeit Map-Reduce Online. 2 Einleitung 2.1 MapReduce Durch das von [DG04] entwickelte MapReduce Framework ist es auch mit wenig Kenntnissen im Bereich der Parallelen- und Verteilten-Programmierung möglich, große Datenmengen auf einem Cluster von Computern effektiv zu verarbeiten. Um Tätigkeiten wie die notwendige Parallelisierung, Fehlertoleranz, Verteilung der Daten auf die Systeme und Lastverteilung muss sich der Programmierer nicht kümmern. Diese Aufgaben werden vom MapReduce- Framework übernommen. 2.2 Exkurs: Strom- bzw. Onlineverarbeitung Unter dem Begriff der Stromverarbeitung versteht man das fortlaufende Verarbeiten von Datenströmen. Im Gegensatz zu traditionellen Auswertungen, auf statischen Datenbeständen, wird hierbei der Datenbestand fortlaufend neu ausgewertet Einsatzbereiche Der Einsatz der Stromverarbeitung ist über all dort interessant, wo sich ändernde Datenbestände zeitnah ausgewertet werden müssen um Entscheidungen zu ermöglichen. Die Einsatzgebiete sind sehr weit gefächert und umfassen unter anderem die folgenden Bereiche: Finanzmärke (Auswertung von Aktienkursen) Medizintechnik (Überwachung von Körperfunktionen) Straßenverkehr (Auswertung von Verkehrsströmen) Radioastronomie (Auswertung von Telemetriedaten) Logistik (Auswertung von Positionsdaten) Unter der dem Begriff der Onlineverarbeitung wird verstanden, dass die Verarbeitung der Daten im Dialog mit dem Anwender erfolgt. Die Onlineverarbeitung kann beispielsweise dadurch erreicht werden, dass dem Benutzer der Fortschritt seiner Berechnung angezeigt wird oder ihm ein vorläufiges Ergebnis präsentiert wird. Dieser Form der Datenverarbeitung steht die klassische Stapelverarbeitung (Batchverarbeitung) gegenüber.

239 4 Jan Kristof Nidzwetzki, Thema 15: Strom- bzw. Onlineverarbeitung mit MapReduce IBM InfoSphere Streams Die Firma IBM hat für die kontinuierliche Auswertung von Datenströmen das Produkt IBM InfoSphere Streams (ehemals System S) entwickelt. Die Auswertung der Datenströme wird mittels Data-Flow Graphen beschrieben. Ein Data-Flow Graph besteht aus einer Menge von Processing Elements (PEs) welche miteinander verbunden werden. Die PEs führen verschiedene Operationen auf den Datenströmen aus. PEs können auf verschiedenen Computern ausgeführt werden. Dies ermöglicht es, die Auswertung der Datenströme über mehrere Computer zu verteilen. Für weitere Einzelheiten zu dieser Software siehe [RM] und [BAH10]. Die in dieser Seminararbeit vorgestellte Arbeit DEDUCE: At the Intersection of MapReduce and Stream Processing erweitert das Produkt IBM InfoSphere Streams um die Fähigkeit, Daten mittels MapReduce auszuwerten. 3 Map-Reduce Online In der Arbeit Map-Reduce Online [CCA + 09] wird das Open Source MapReduce-Framework Hadoop um die Möglichkeit der Onlineverarbeitung (Online Aggregation) erweitert. Das klassische Hadoop unterstützt bislang nur die Form der Batchverarbeitung. Durch die Onlineverarbeitung ist es Anwendern möglich, vorzeitige Ergebnisse (Early returns) zu erhalten, während Ihr MapReduce-Job noch ausgeführt wird. Die Autoren haben im Rahmen dieser Arbeit die Software Hadoop Online Prototype (HOP) entwickelt. Die Software HOP unterstützt neben der Onlineverarbeitung ebenfalls Continuous Queries, welche es ermöglichen, MapReduce-Programme für Dienste wie Ereignisüberwachung oder die Stromverarbeitung zu nutzen. Dabei behält HOP die von MapReduce bekannte Fehlertoleranz bei und erlaubt es, bestehende MapReduce-Programme auszuführen. Zudem senkt HOP die Ausführungszeiten von klassischen MapReduce-Programmen, da sich nun die Map- und die Reduce-Phase überlappen und somit zur Verfügung stehende Ressourcen besser ausgelastet werden können. 3.1 Arbeitsweise des klassischen Hadoop Das zu Hadoop gehörende Dateisystem Hadoop Distributed File System (HDFS) wird bei vielen Hadoop-Jobs dazu eingesetzt, die Eingabedaten für die Map-Funktion bereitzustellen. Die meisten Jobs speichern zudem das Ergebnis der Reduce-Funktion wieder im HDFS. In einer Hadoop-Installation existiert eine Master-Node, der so genannte JobTracker und mehrere Worker-Nodes. Der JobTracker nimmt Jobs entgegen, zerteilt diese in einzelne Tasks und weist diese Tasks den Worker-Nodes zu. Auf den Worker-Nodes laufen wiederum ein oder mehrere Map- und Reduce-Tasks. Eine detaillierte Beschreibung der Architektur von Hadoop ist z.b. in [Whi09] zu finden.

240 Jan Kristof Nidzwetzki, Thema 15: Strom- bzw. Onlineverarbeitung mit MapReduce Probleme der Onlineverarbeitung Die Architektur von Hadoop sieht es vor, dass die Ausgabe der Map-Funktion und die Ausgabe der Reduce-Tasks erst vollständig vorliegen müssen, bevor diese Daten weiterverarbeitet werden können. Dies vorgehen erlaubt es Hadoop mit recht einfachen Mitteln für Fehlertoleranz zu sorgen. Falls ein Map- oder Reduce-Task aufgrund eines Fehlers nicht vollständig ausgeführt werden kann, muss der JobTracker von Hadoop lediglich den Task erneut starten. Die Ausgabe des fehlgeschlagenen Tasks wird von Hadoop verworfen und nur das Ergebnis des neuen Tasks wird zur Weiterverarbeitung genutzt. Erst wenn es möglich ist, Ergebnisse von Map- oder Reduce-Tasks umgehend zu nutzen, kann eine Online-Verarbeitung der Daten erfolgen. Wie dieses genau durchgeführt werden kann, ohne die Fehlertoleranz zu beeinträchtigen, wird in den kommenden Abschnitten erläutert. Die Ausgaben eines Map-Tasks bestehen aus einzelnen Records. Es existiert in Hadoop eine Partition-Funktion, welche für jeden Record die Partition ermittelt, zu der der Record gehört. Jedem Reduce-Task wird beim Start eine Partition zugewiesen, die er verarbeiten soll. Die Partition-Funktion bestimmt somit, wie die einzelnen Records auf die Reduce-Tasks aufgeteilt werden. Die erste Aufgabe eines Reduce-Tasks ist es, alle für seine Partition relevante Daten der Map-Tasks einzusammeln. Da diese Daten nicht im HDFS vorhanden sind, müssen diese von den entsprechenden Rechnern, auf den der Map-Tasks lief, abgeholt werden 1. Der JobTracker sorgt dafür, dass alle TaskTracker bekannt sind, auf welchen Ausgaben eines Map-Tasks liegen. Der Reduce-Task kann erst mit der Verarbeitung der Daten beginnen, wenn alle Daten für die von ihm zu bearbeitende Partition vorliegen. 3.2 Pipelining Um die Strom- bzw. Onlineverarbeitung zu ermöglichen, wird die Entkopplung der Map- und Reduce-Tasks aufgehoben. Statt es dem Reduce-Tasks zu überlassen, die Daten der Map- Tasks einzusammeln, werden bei HOP die Ausgaben der Map-Tasks direkt an die Reduce- Tasks weitergeleitet (Pipelining). Sobald ein Client einen neuen Job übermittelt, sorgt HOP dafür, dass jeder Reduce-Tasks umgehend alle Map-Tasks kontaktiert und eine TCP-Verbindung zu ihnen aufbaut. Über diese Verbindung leitet der Map-Task umgehend die von ihm produzierten Daten an den zuständigen Reduce-Task weiter. Der Reduce-Task nimmt diese Daten an und speichert diese in einem Pufferspeicher zwischen. Sobald der Reduce-Tasks darüber benachrichtigt wird, dass alle Map-Tasks beendet sind, führt er, wie im klassischen Hadoop, die Reduce-Funktion aus. Dieses Design vertraut darauf, dass den gestarteten Jobs sofort von Hadoop genügend freie Map- und Reduce-Tasks zur Verfügung gestellt werden können. Zudem wird davon ausgegangen, dass eine beliebige Anzahl von TCP-Verbindungen aufgebaut werden kann. 1 Dies geschieht bei Hadoop durch das Protokoll HTTP.

241 6 Jan Kristof Nidzwetzki, Thema 15: Strom- bzw. Onlineverarbeitung mit MapReduce Beide Annahmen sind in der Praxis nicht immer zu erfüllen. Um das Pipelining trotzdem zu ermöglichen, bedient sich HOP eines einfachen Tricks: wenn nicht genügend freie Ressourcen zur Verfügung stehen, um alle Reduce-Tasks sofort zu starten, schreiben die Map-Tasks die Daten, wie im klassischen Hadoop, auf die lokale Festplatte. Sobald der Reduce-Task ausgeführt werden kann, sammelt dieser die Daten von den Map-Tasks ein. Um die Anzahl der verwendeten TCP-Verbindungen zu reduzieren, lässt sich die Anzahl der maximalen TCP-Verbindungen der Reduce-Tasks festlegen. Müssen mehr Map-Tasks kontaktiert werden, als dieses Limit zulässt, so baut der Reduce-Task so viele TCP-Verbindungen auf, wie maximal möglich. Die Daten von den restlichen Map-Tasks werden wieder wie im klassischen Hadoop eingesammelt, sobald der Map-Task beendet ist Weitere Probleme beim Pipelining Da die vom Map-Task produzierten Daten sofort an den Reduce-Task übermittelt werden, kann die aus dem klassischen Hadoop bekannte Combiner-Funktion nicht angewendet werden. Sie sorgt dafür, dass Ergebnisse des Map-Tasks zusammengefasst werden und weniger Daten zwischen dem Map- und Reduce-Tasks zu übertragen sind. Zudem werden im klassischen Hadoop die Daten für die Reduce-Tasks von den Map-Tasks vorab sortiert. Da in HOP die Ausgaben der Map-Tasks direkt an die Reduce-Tasks übermittelt werden, müsste diese Arbeit ebenfalls von den Reduce-Tasks erledigt werden. Um nicht zu viel Arbeit von den Map-Tasks auf die Reduce-Tasks zu übertragen und um das Netzwerk nicht übermäßig zu belasten, werden die Daten von den Map-Tasks nicht unmittelbar an die Reduce-Tasks übertragen. Stattdessen hält der Map-Tasks eine gewisse Menge an Ausgaben im Speicher. Wenn diese Datenmenge einen Schwellwert übersteigt, wird die Combiner-Funktion angewendet und der Speicherinhalt nach Partition und Map-Key sortiert in eine Datei geschrieben. In HOP wurde der Task-Tracker um Funktionen für die Verarbeitung derartiger Dateien erweitert. Zudem wurde das Übertragen der Daten von dem Map-Task in den Task-Tracker verlegt. Der Map-Task benachrichtigt lediglich den Task-Traker, dass eine neue Datei mit Ausgaben vorhanden ist. Der Track-Tracker übermittelt nun die Datei umgehend an den zuständigen Reduce-Task. Bevor der Map-Task eine neue Datei dem Task-Tracker meldet, wird der Task-Tracker nach der Anzahl der noch nicht übertragenen Dateien gefragt. Übersteigt das Ergebnis einen Schwellwert, so registriert der Map-Task die Datei vorerst nicht beim Task-Tracker. Erst wenn die Anzahl der ungesendeten Dateien unter diesen Schwellwert sinkt, fügt der Map- Task alle angesammelten Dateien zusammen. Die zusammengefassten Daten werden sortiert, der Combiner-Funktion unterworfen und das Ergebnis in eine neue Ausgabedatei geschrieben. Lediglich diese eine Datei wird dann dem Task-Tracker gemeldet. Durch dieses Vorgehen wird ein Teil der Arbeitslast zwischen den Map- und Reduce-Tasks dynamisch verteilt. Je nachdem, ob das System für den Map-Task oder Reduce-Task stärker ausgelastet ist, wird dem stärker belasteten System ein Teil der Arbeitslast abgenommen.

242 Jan Kristof Nidzwetzki, Thema 15: Strom- bzw. Onlineverarbeitung mit MapReduce Pipelining zwischen verschiedenen MapReduce-Jobs Viele gängige Berechnungen bestehen aus mehreren hintereinander ausgeführten Map-Reduce Jobs. In der traditionellen Hadoop-Architektur wird das Ergebnis eines Jobs im HDFS gespeichert. Sobald dieses Ergebnis vollständig vorliegt, wird es vom nächsten Map-Task als Eingabe verwendet. Durch HOP ist es möglich, dass die Reduce-Tasks ihre Ergebnisse direkt in die Map-Tasks des nächsten Jobs weiterleiten. Das aufwändige Schreiben des Ergebnisses des ersten Jobs ins HDFS entfällt somit. Zu beachten ist jedoch, dass sich der Reduce-Task des ersten Jobs nicht mit dem Map- Task des zweiten Jobs überlappen kann, da das vollständige Ergebnis des ersten Jobs erst nach Beendigung des Reduce-Tasks vorhanden ist. Erst in diesem Moment können die Daten vom nachfolgenden Job gelesen werden. Diese Einschränkung verhindert ein effektives Pipelining zwischen zwei verschiedenen Jobs. Im Abschnitt wird beschrieben, wie mittels Snapshot-Outputs trotzdem schon vorab die Daten des ersten Jobs vom zweiten Job verarbeitet werden können Fehlertoleranz Auch HOP ist in der Lage, mit fehlgeschlagenen Map- und Reduce-Tasks umzugehen. Um einen fehlgeschlagenen Map-Task ausgleichen zu können, führen die Reduce-Tasks Buch darüber, von welchem Map-Task sie welche Daten erhalten haben. Den Reduce-Tasks ist es nur erlaubt, Daten von dem gleichen Map-Task zu kombinieren. Erst wenn der Reduce- Task die Information erhält, dass der Map-Task vollständig durchgeführt worden ist, dürfen die Daten aus diesem Map-Task mit Daten aus andern abgeschlossenen Map-Tasks kombiniert werden. Falls ein Map-Task fehlschlägt, kann der Reduce-Task alle Daten die er bis zum Ausfall von dem Map-Task erhalten hat, vollständig ignorieren. Der Task-Tracker muss nun lediglich einen neuen Map-Task starten, der die gleiche Berechnung wiederholt, um den Ausfall zu kompensieren. Wenn ein Reduce-Task fehlschlägt, wird ein neuer Reduce-Task für die gleiche Partition gestartet. Die Map-Tasks müssen nun den neuen Reduce-Task erneut mit Ihren Ausgaben versorgen. Damit der Map-Task die Berechnung nicht vollständig wiederholen muss, speichert er seine Ergebnisse solange zwischen, bis der zugehörige Reduce-Task erfolgreich beendet worden ist. Diese Art der Fehlertoleranz ist sehr einfach zu implementieren. Jedoch besitzt Sie eine Limitierung. Die Daten der Map-Tasks können erst von den Reduce-Tasks verarbeitet werden, wenn der Map-Task erfolgreich beendet worden ist. Um diese Limitierung zu umgehen wurde das Konzept der Checkpoints eingeführt. Ein Map-Task informiert periodisch den JobTracker dass dieser an dem Offset x in den Eingabedaten angekommen ist. Der JobTracker Informiert darauf hin alle Reduce-Tasks, die Daten von diesem Map-Task konsumieren, dass diese alle Daten verarbeiten können, die vor diesem Offset liegen. Wenn ein Map-Task fehlschlägt, muss dieser lediglich an dem zuletzt bekannten Offset seine Arbeit aufnehmen.

243 8 Jan Kristof Nidzwetzki, Thema 15: Strom- bzw. Onlineverarbeitung mit MapReduce 3.3 Online Aggregation MapReduce wurde entwickelt, um Daten mittels Batchverarbeitung zu verarbeiten. Häufig würden Benutzer jedoch gerne MapReduce verwenden, um interaktiv Daten auszuwerten. Derzeit sieht der typische Arbeitsablauf wie folgt aus: ein MapReduce-Job wird gestartet. Sobald das Ergebnis vorliegt, schaut der Benutzer sich diese Daten an, um zu überprüfen, ob diese seinen Vorstellungen entsprechen. Danach wird entweder ein veränderter Job gestartet, falls das Ergebnis nicht den Vorstellungen des Benutzers entspricht oder die Daten werden weiterverarbeitet. Das klassische Hadoop bietet keine Möglichkeiten, Daten interaktiv auszuwerten. Die Ausgabe eines Jobs kann erst angesehen werden, wenn der Job abgeschlossen worden ist. Häufig wünschen sich jedoch Anwender, ein vorläufiges Ergebnis (Early return) ansehen zu können. Dieses Ergebnis ist zwar noch nicht sehr genau, häufig genügt es jedoch für die Einschätzung, ob der laufende MapReduce-Job die gewünschten Ergebnisse liefert Online Aggregation innerhalb eines MapReduce-Jobs In HOP werden die vom Map-Task produzierten Daten umgehend an die Reduce-Tasks weitergeleitet. Jedoch kann der Reduce-Task erst mit seiner Arbeit anfangen, wenn alle Daten von den Map-Tasks vorliegen. Um die Online Aggregation in HOP zu ermöglichen, wurden Snapshots eingeführt. In einem Snapshot sind alle bislang von den Map-Tasks gelieferten Daten enthalten. Der Reduce-Task beginnt seine Arbeit auf diesen Daten und liefert ein vorläufiges Ergebnis, welches im HDFS abgelegt wird. Anwender möchten bei solchen Snapshots häufig wissen, wie genau dieser ist. Das Problem, zu ermitteln, wie genau ein solches Zwischenergebnis ist, ist selbst für normale SQL Abfragen nur schwer zu bestimmen. HOP gibt daher nur den Fortschritt der laufenden Berechnung an. Eine genauere Betrachtung dieser Fragestellung wird in der Arbeit Beyond Online Aggregation: Parallel and Incremental Data Minding with Online Map-Reduce [BAH10] nachgegangen, welche im Abschnitt 4.2 kurz vorgestellt wird. Der Anwender kann in HOP definieren, wie oft ein solcher Snapshot berechnet werden soll. So kann er beispielsweise einen Snapshot bei 20%, 40%, 60% und 80% Fortschritt eines Jobs anfordern. Darüber hinaus kann der Benutzer angeben, ob nur Daten von vollständig abgeschlossenen Map-Tasks in das Ergebnis einfließen sollen oder ob auch Daten aus noch laufenden Map-Tasks in das Ergebnis aufgenommen werden sollen Online Aggregation zwischen mehreren MapReduce-Jobs Wie bereits beschrieben, erweitert HOP das klassische Hadoop um die Möglichkeit, Daten aus den Map-Task direkt an den Reduce-Task weiterzuleiten. Diese Erweiterung kann ebenfalls dazu genutzt werden, um die Online Aggregation zwischen zwei oder mehr Jobs zu ermöglichen. Im folgenden Beispiel wird angenommen, dass die zwei Jobs j1 und j2 ausgeführt werden sollen und j2 die Ausgaben von j1 als Eingabe ließt. Um die Online Aggregation über mehrere Jobs hinweg zu ermöglichen, produziert der Job j1 wie im Abschnitt erläutert regelmäßige Snapshots. Der Snapshot wird wie bereits beschreiben im HDFS abgelegt. Zu-

244 Jan Kristof Nidzwetzki, Thema 15: Strom- bzw. Onlineverarbeitung mit MapReduce 9 dem werden die Daten direkt an die Map-Tasks des Jobs j2 weitergeleitet. Der Task j2 berechnet nun, wie ein normaler Map-Reduce Job, sein Ergebnis. Mit dieser Methode lassen sich auch mehr als zwei Jobs an einander Reihen. Dieses Verfahren baut jedoch darauf auf, dass alle Berechnungen von j2 für jeden Snapshot von j1 vollständig wiederholt werden müssen. Bereits berechnete Zwischenergebnisse lassen sich bislang nicht weiterverwenden. Eine genaue Untersuchung wie Zwischenergebnisse bei bestimmten Funktionen weiterverwendet werden können, steht bislang noch aus Einsatz in der Praxis Im Rahmen der Entwicklung von HOP wurde die Online Aggregation an einem praktischen Beispiel getestet. In 5,5 GB der englischsprachigen Wikipedia sollte ermittelt werden, welches die K häufigsten Wörter sind. Diese Berechnung wurde in der Amazon Elastic Computer Cloud (EC2) durchgeführt. Dort ist es möglich, sich für eine gewisse Zeit, eine bestimmte Menge an Ressourcen zu mieten. Zum Einsatz für diese Berechnung kamen 60 Systeme vom Typ high-cpu Medium mit jeweils 1,7 GB Arbeitsspeicher und 2 virtual Cores. Ein virtueller Core entspricht der Leistung eines 2,5 GHz Intel Xeon Prozessor aus dem Jahre Die 5,5 GB an Eingabedaten wurden ins HDFS kopiert. Auf diesen Daten wurden zwei MapReduce-Jobs durchgeführt. Der erste Job zählt die Häufigkeit der Wörter und der zweite Job ermittelt die K häufigsten Wörter. In dem Job werden oft Snapshots erzeugt und ausgewertet. Ziel ist es zu ermitteln, nach wie vielen Sekunden des Jobs bereits die finalen k häufigsten Wörter feststehen. Die Ergebnisse dieser Berechnungen sind in Abbildung 1 zu sehen. So ist zu sehen, dass nach ca. 30 Sekunden schon die Top 5 Wörter, nach ca. 50 Sekunden die Top 10 Wörter und nach ca. 80 Sekunden die Top 20 Wörter ermittelt waren. Abbildung 1: Häufigste K Wörter in 5.5 GB Text der englischsprachigen Wikipedia. Quelle: [CCA + 09] S. 07

245 10 Jan Kristof Nidzwetzki, Thema 15: Strom- bzw. Onlineverarbeitung mit MapReduce 3.4 Continuous Queries MapReduce wird häufig dazu eingesetzt, Datenströme wie Logdateien auszuwerten. Durch die Architektur von Hadoop ist es nur möglich, die Logdateien als Momentaufnahme zu verarbeiten. Veränderungen an den Logdateien können erst mit der nächsten Auswertung mit berücksichtigt werden. Wünschenswert wäre es, derartige Ströme von Eingaben kontinuierlich in Echtzeit auszuwerten. Bei jeder Auswertung der Logdatei muss zudem die komplette Berechnung wiederholt werden, sofern der Anwender nicht selber dafür sorgt, die Ergebnisse der letzten Berechnung zwischenzuspeichern und mit der nächsten Berechnung wieder zu laden. HOP bietet für die Stromverarbeitung eine Alternative an. In HOP können Jobs fortwährend laufen und neue Daten auswerten, sobald diese verfügbar sind. Die Umsetzung der Continuous Queries für die Stromverarbeitung gestaltet sich durch die bisher implementierten Funktionen einfach. Genau wie bei der Online Aggregation werden die Ausgaben der Map-Tasks direkt an die Reduce-Tasks weitergeleitet. Lediglich um eine API-Funktion musste HOP erweitert werden. Diese API-Funktion sorgt dafür, dass die Map-Tasks ihr aktuelles Ergebnis unmittelbar an die Reduce-Tasks weiterleiten. Für die Stromverarbeitung wird die Reduce-Funktion periodisch aufgerufen und mit neuen Daten versorgt. Wie oft die Reduce-Funktion aufgerufen wird, hängt von der jeweiligen Anwendung ab. Der Aufruf der Reduce-Funktion kann entweder in einem festen Zeitintervall erfolgen, bei Auftreten eines bestimmten Wertes in der Eingabe der Map-Funktion oder beim erreichen einer bestimmten Anzahl von unverarbeiteten Eingabedaten. Das Ergebnis der Reduce-Tasks kann genau wie bei der Online Aggregation in HDFS geschrieben werden. Auch alternative Ausgabemöglichkeiten sind in der Praxis denkbar. Ein Beispiel hierfür ist die im Abschnitt beschriebene Anwendung Fehlertoleranz In dem vom Hadoop implementierten Fehlertoleranz-Modell ist es einfach, mit fehlgeschlagenen Map- oder Reduce-Tasks umzugehen. Im Bereich der Stromverarbeitung ist dies jedoch nicht so einfach möglich. Es ist in der Praxis nicht realisierbar, alle von der Map-Funktion erzeugten Daten aufzubewahren und bei einem Fehler erneut auszuwerten. Viele Reduce-Tasks benötigen keine vollständige Historie, um Ihre Arbeit fortsetzen zu können. So benötigt ein Reduce-Task, der einen gleitenden 30 Sekunden Durchschnitt berechnet, nur die Eingaben der letzten 30 Sekunden um nach einem Ausfall weiterarbeiten zu können. Um Reduce-Tasks in Ihrer Fehlertoleranz zu unterstützen, wurde in HOP der JobTracker erweitert. Dieser speichert nun, welche Eingabedaten von den Reduce-Tasks verarbeitet worden sind und wie lange diese Daten vorgehalten werden müssen. Sobald bestimmte Daten nicht mehr vorgehalten werden müssen, informiert der JobTracker die Map-Tasks, dass diese Daten entfernt werden können. In unserem Beispiel mit der Berechnung des gleitenden Durchschnitts müssen nur Daten der letzten 30 Sekunden vorgehalten werden. Ältere Daten sind für die Berechnung nicht relevant.

246 Jan Kristof Nidzwetzki, Thema 15: Strom- bzw. Onlineverarbeitung mit MapReduce 11 Es gibt jedoch auch Berechnungen, die eine vollständige Historie der Eingabedaten benötigen, um nach einem Fehler korrekt weiterarbeiten zu können. Diese Map-Tasks müssen derzeit Ihren eigenen Zustand im HDFS speichern und bei einem Neustart diesen Zustand korrekt wieder einlesen. HOP könnte prinzipiell derartige Aufgaben unterstützen. Derartige Funktionen sind jedoch bislang noch nicht in HOP implementiert Beispielanwendung: Aufbau eines Monitoring Systems Im Rahmen dieser Arbeit wurde die Nutzung der Stromverarbeitung im praktischen Einsatz erprobt. Für einen HOP-Cluster wurde ein Monitoring System entworfen, welches sich die Stromverarbeitung von HOP zu nutze macht. Auf jedem System in diesem Cluster kommt ein Agent zum Einsatz, welcher einen Map-Task darstellt, der die Eingabedaten für das Monitoring System liefert. Als Eingabedaten werden Informationen über die Speicher- und CPU-Auslastung, IO-Operationen, etc. eingelesen. Alle Agents liefern Ihre Ergebnisse an einen Aggregator, welcher als Reduce-Tasks implementiert worden ist. Dieser vergleicht die Systemlast der letzten 20 Sekunden mit der Systemlast des gesamten Clusters in den letzten 120 Sekunden. Weichen die Werte eines Agents um mehr als zwei Standardabweichungen vom Durchschnitt des gesamten Systems ab, so wird ein Alarm erzeugt. Das ganze System wurde wieder auf einem Amazon EC2 Cluster mit 7 Systemen eingesetzt. Auf diesen Systemen wurde ein MapReduce-Job ausgeführt, welcher auf 5,5 GB an Daten der Wikipedia die Anzahl der Wörter zählt. 10 Sekunden nachdem dieser Job gestartet worden ist, wurde auf einem der Systeme ein Programm gestartet, was die Systemlast deutlich ansteigen ließ. Das Monitoring System meldete diesen Ausreißer in der Auslastung nach weniger als 5 Sekunden. 3.5 Performance von Map-Reduce Online In einem MapReduce-Job stellt die Map-Phase den größten Teil der Arbeit dar. Die Map- Funktion wird auf alle Eingabedaten angewendet. Danach werden die Ausgaben der Map- Funktion sortiert und dem TaskTracker gemeldet. Die Reduce-Funktion besteht aus drei Phasen. In der ersten Phase Shuffle werden die Daten des Map-Tasks eingesammelt und sortiert. In der Reduce Phase werden die Daten durch die Reduce-Funktion verarbeitet und in der anschließenden Commit Phase ausgegeben. 75% der gesamten Arbeit des Map-Tasks entfallen auf die Shuffle Phase. Die restlichen 25% entfallen auf die Reduce und Commit Phase. Durch das in HOP eingeführte Pipelining zwischen den Map- und den Reduce-Tasks ist es dem Reduce Task möglich, die eintreffenden Daten kurz nach Ihrem eintreffen zu sortieren. Wenn der letzte Map-Task seine Arbeit abgeschlossen hat und die Daten an den Reduce-Task übermittelt worden sind, muss dieser die Daten noch ein letztes mal sortieren und kann danach in die Reduce Phase eintreten. Im klassischen Hadoop werden die Daten erst dann sortiert, wenn alle Daten der Map-Tasks vorliegen.

247 12 Jan Kristof Nidzwetzki, Thema 15: Strom- bzw. Onlineverarbeitung mit MapReduce Performance-Tests Als Performance-Test wurde wieder ein MapReduce-Job auf einem Amazon EC2 Cluster ausgeführt. Zum Einsatz kamen, bei diesem Test, 10 Systeme mit jeweils 16 GB Arbeitsspeicher und vier virtuellen Cores. Als MapReduce-Job wurde ein Wordcount über 10 GB an Eingabedaten ausgeführt. Einmal kam Hadoop zum Einsatz, das andere mal wurde HOP mit Pipelining eingesetzt. Der Job wurde jeweils zwei mal ausgeführt. Einmal mit 20 Map- Tasks und 5 Reduce-Tasks und einmal mit 20 Map-Tasks und ebenfalls 20 Reduce-Tasks. Die Ergebnisse sind in den Abbildungen 2 und 3 dargestellt. Abbildung 2: Wordcount über 10 GB mit 20 Map-Tasks und 5 Reduce-Tasks. Links: Hadoop ohne Pipelining (551 Sekunden), Rechts: HOP mit Pipelining (462 Sekunden). Quelle: [CCA + 09] S. 11 Abbildung 3: Wordcount über 10 GB mit 20 Map-Tasks und 20 Reduce-Tasks. Links: Hadoop ohne Pipelining (361 Sekunden), Rechts: HOP mit Pipelining (290 Sekunden). Quelle: [CCA + 09] S. 11 Sowohl beim klassischen Hadoop als auch bei HOP ist im ersten Test, bei der Ausführung des Reduce-Taks, nach 75% eine gewisse Zeit zu erkennen, in der der Job scheinbar nicht fortschreitet. Der Map-Tasks hat zu diesem Zeitpunkt alle Daten eingesammelt und sortiert diese, bevor die Reduce Phase gestartet wird. Es ist jedoch deutlich zu erkennen, dass durch das Pipelining das sortieren schneller abgeschlossen werden kann, da die Daten schon nach

248 Jan Kristof Nidzwetzki, Thema 15: Strom- bzw. Onlineverarbeitung mit MapReduce 13 dem Eintreffen vorsortiert worden sind. Der Job welcher Pipelining nutzen konnte, kann somit schneller abgeschlossen werden. Der gleiche MapReduce-Job wurde nochmals laufen gelassen. Dieses mal jedoch mit 20 Mapund 20 Reduce-Tasks. Die Ergebnisse sind in der Abbildung 3 zu sehen. Durch die größere Anzahl von Reduce-Tasks ist die Datenmenge für jeden Reduce-Tasks geringer, die verarbeitet werden muss. Auch in diesem Setup kann der Job, welcher Pipelining nutzen konnte schneller abgeschlossen werden. Die Autoren der Arbeit haben noch weitere vergleiche zwischen dem klassischen Hadoop und HOP mit Pipelining durchgeführt. Diese Tests haben ergeben, dass durch Pipelining die Auslastung auf den Systemen gesteigert wird und somit die MapReduce Jobs schneller abgeschlossen werden können. Somit ist HOP auch für den Einsatz mit klassischen MapReduce- Jobs interessant. 4 Weitere Arbeiten Auch andere Gruppen haben sich mit der Nutzung von MapReduce zur Strom- bzw. Onlineverarbeitung auseinandergesetzt. Zwei weitere Arbeiten werden in diesem Abschnitt kurz vorgestellt. In dem Abschnitt 5 werden alle drei Arbeiten miteinander verglichen. 4.1 DEDUCE: At the Intersection of MapReduce and Stream Processing Die Arbeit DEDUCE: At the Intersection of MapReduce and Stream Processing [KAGW10] erweitert das von IBM angebotene und Abschnitt vorgestellte System IBM InfoSphere Streams (ehemals System S) um die Möglichkeit, Daten mittels MapReduce zu verarbeiten SPADE SPADE die Stream Processing Application Declarative Engine stellt im IBM System S die verwendete Sprache zum beschreiben einer Anwendung dar. SPADE selber besitzt die Möglichkeit, durch UBOPs - user-defined build-in operators erweitert zu werden. Diese Fähigkeit macht sich DEDUCE zu nutze. DEDUCE führt einen MapReduce-Operator ein, welcher als Eingabe eine Liste von Dateien und Verzeichnissen erwartet und als Ausgabe die im System S enthaltenen stream processing operators mit Daten versorgt. Dieser Operator erlaubt es zudem, kaskadiert eingesetzt zu werden um auf diese Weise die Ausgabe eines MapReduce-Jobs als Eingabe eines neuen MapReduce-Jobs zu verwenden. Hierbei ist zu beachten, dass der DEDUCE selber nicht für die Strom- bzw. Onlineverarbeitung eingesetzt wird, sondern lediglich als Datenlieferant eingesetzt wird. Die Daten für diesen MapReduce-Opreator werden aus dem schon bekannten Hadoop Distributed Filesystem - HDFS gelesen. An einer Unterstützung für die OpenSource Implementation des Google Filesystems Kosmos File System - KFS wird derzeit gearbeitet.

249 14 Jan Kristof Nidzwetzki, Thema 15: Strom- bzw. Onlineverarbeitung mit MapReduce Eine Beispielanwendung Die Autoren von DEDUCE beschreiben in Ihrer Arbeit eine Beispielanwendung für den MapReduce-Operator. Diese Anwendung wird dazu eingesetzt, Aktienmärkte auszuwerten und Aktien mit bestimmten Kriterien zu ermitteln. Die Stromverarbeitung des System S wird dazu eingesetzt, die sich ständig verändernden Daten auf einem Aktienmarkt wie Preis und Umsatz auszuwerten. Diese Daten werden mit aktuellen Nachrichten kombiniert. Für die Auswertung dieser Nachrichten, wie Analysen und Ad-Hoc-Meldungen 2, wird ein MapReduce-Job eingesetzt. Dieser wertet periodisch die leicht mehrere Gigabyte umfassenden Daten aus und stellt das Ergebnis für die weitere Analyse zur Verfügung. Ein Schema dieser Anwendung ist in der Abbildung 4 dargestellt. In diesem Schema sind drei wichtige Komponenten zu erkennen. Unten links ist der Map- Reduce-Job dargestellt. Dieser wertet periodisch Daten aus externen Quellen aus. Das Ergebnis wird durch einen ModelReader gelesen, welcher diese Daten aus dem Dateisystem ließt zur weiteren Verarbeitung im System S bereitstellt. In dem Schema ist zudem ein Normalizer zu sehen. Dieser ist dafür zuständig, die aus der Stromverarbeitung stammenden Ergebnisse mit den Daten des MapReduce-Jobs zu kombinieren. Abbildung 4: Schematische Darstellung einer Anwendung in System S mit MapReduce- Operator. Quelle: [KAGW10] S Beyond Online Aggregation: Parallel and Incremental Data Minding with Online Map-Reduce In der Arbeit Beyond Online Aggregation: Parallel and Incremental Data Minding with Online Map-Reduce [BAH10] wird ein MapReduce-Framework zur Strom bzw. Onlineverarbeitung vorgestellt, um Probleme wie die Angabe der Genauigkeit einer vorläufigen Berechnung oder die Ermittlung der Laufzeit des gesamten Jobs untersuchen zu können WpHG verpflichtet börsennotierte Unternehmen zur sofortigen Veröffentlichung von Nachrichten, die den Aktienkurs erheblich beeinflussen können. Diese Nachrichten werden als Ad-Hoc-Meldung bezeichnet.

250 Jan Kristof Nidzwetzki, Thema 15: Strom- bzw. Onlineverarbeitung mit MapReduce Architektur des MapReduce Framework Das von den Autoren entwickelte MapReduce-Framework basiert auf einer Shared-Memory Architektur und ist als Testumgebung zur Untersuchung der oben genannten Fragestellungen gedacht. Die Daten werden in diesem Framework lediglich im Arbeitsspeicher gehalten. Dies ist der Grund dafür, dass diese Implementation nicht in einem Cluster von Computern eingesetzt werden kann und nur ebenfalls nur eine sehr geringe Fehlertoleranz aufweist. Die Autoren sehen diese Implementation als reine Testumgebung an und empfehlen für den produktiven Einsatz das in Abschnitt 3 vorgestellte Hadoop Online Prototype - HOP Ermittlung des Job-Fortschritts und der Genauigkeit Es wird vorgeschlagen, dass der Entwickler eines MapReduce-Jobs bestimmte Methoden implementiert, welche es dem MapReduce-Framework ermöglichen, Aussagen über den die Genauigkeit einer vorläufigen Berechnung oder die noch zu erwartende Laufzeit zu geben. Diese Methoden müssen vom jeweiligen Entwickler implementiert werden, da jeder Job unterschiedliche Charakteristiken aufweist und ohne diese Angabe keine genaue Ermittlung dieser Werte möglich wäre. Das vorgestellte MapReduce-Framework ist in der Lage convergence curves zu zeichnen, welche es dem Benutzer erlauben, die Genauigkeit eines vorläufigen Ergebnisses abschätzen zu können. Eine convergence curve stellt einen Graphen dar. Auf der X-Achse wird der Fortschritt des Jobs in dem Intervall von [0,1] angegeben auf der Y-Achse hingegen der Wert der dif()-funktion. Sobald das MapReduce-Framework ein Zwischenergebnis eines Jobs berechnet hat, wird zusätzlich die Signatur sig() berechnet. Dabei handelt es sich um eine durch den Entwickler des MapReduce-Jobs bereitgestellte Funktion, die (sofern möglich) alle für das Ergebnis relevanten Informationen zusammenfasst. Wenn beispielsweise die häufigsten K-Wörter in einem Text ermittelt werden sollen, würde die Funktion genau diese Wörter zurück liefern. Wenn hingegen die Anzahl der Wörter ermittelt werden soll, liefert die Funktion nur die bislang gezählten Wörter zurück. Diese Funktion wurde eingeführt, um eine speichersparende Repräsentation des Zwischenergebnisses zu erhalten. Die Funktion dif() nimmt als Parameter zwei derartige Signaturen entgegen und berechnet den Abstand dieser beiden Signaturen. Um eine convergence curve zu Zeichnen, wird der Abstand aller ermittelten Zwischenergebnisse mit dem letzten berechneten Ergebnis ermittelt und die Differenz als Graph dargestellt. In der Abbildung 5 ist eine convergence curve für einen MapReduce-Job dargestellt, welcher die Wörter eines Textes zählt. Man sieht, dass die Abweichung eines vorläufigen Ergebnisses sehr stark abnimmt. 5 Vergleich der vorgestellten Arbeiten In der Arbeit DEDUCE: At the Intersection of MapReduce and Stream Processing wird das vom IBM entwickelte System S um die Möglichkeit ergänzt, Daten mittels MapReduce zu verarbeiten. Die im System S enthaltene Beschreibungssprache SPADE wird um

251 16 Jan Kristof Nidzwetzki, Thema 15: Strom- bzw. Onlineverarbeitung mit MapReduce Abbildung 5: Wordcount über den Text der englischen Bücher auf Gutenberg Books (http://www.gutenberg.org). Quelle: [BAH10] S. 5 einen MapReduce-Operator erweitert. Dieser eignet sich dafür, bestehende Daten periodisch auszuwerten und die Ergebnisse an die Stromverarbeitungs-Operatoren weiterzuleiten. Eine Strom- bzw. Onlineverarbeitung mittels MapReduce findet jedoch nicht statt. Die Arbeit Beyond Online Aggregation: Parallel and Incremental Data Minding with Online Map-Reduce hingegen stellt ein MapReduce-Framework vor, welches um Aspekte wie Fehlertoleranz oder Skalierbarkeit reduziert worden ist, sich jedoch gut zur Evaluation von Erweiterungen eignet. Die Autoren dieses Systems nutzen es, um die Genauigkeit von vorläufigen Ergebnissen (Online Aggregation / Snapshots) zu Berechnen sowie Aussagen über den Berechnungsfortschritt zu geben. Die Arbeit Map-Reduce Online beschreibt eine Erweiterung der Software Hadoop. Diese Erweiterung mit dem Namen Hadoop Online Prototype (HOP) erweitert Hadoop um die Möglichkeiten der Strom bzw. Onlineverarbeitung. HOP ermöglicht es, Daten aus Map-Tasks schnell an Reduce-Tasks weiterzuleiten. Hierdurch werden Jobs schneller ausgeführt, da sich nun die Bearbeitung der Map- und Reduce-Tasks überlappen kann. Zudem führt HOP das Konzept der Snapshots ein. Hierbei handelt es sich um vorzeitige Ergebnisse eines Jobs. Diese erlauben es, MapReduce-Jobs auch in der Online-Verarbeitung einzusetzen. Darüber hinaus werden Continuous Queries eingeführt, welche HOP die Fähigkeit geben, Datenströme auszuwerten. All diese Erweiterungen bewahren die von Hadoop bekannte Fehlertoleranz.

252 Jan Kristof Nidzwetzki, Thema 15: Strom- bzw. Onlineverarbeitung mit MapReduce 17 Literatur [BAH10] [CCA + 09] [DG04] Joos-Hendrik Böse, Artur Andrzejak, and Mikael Högqvist. Beyond online aggregation: parallel and incremental data mining with online map-reduce. In Proceedings of the 2010 Workshop on Massive Data Analytics on the Cloud, MDAC 10, pages 3:1 3:6, New York, NY, USA, ACM. Tyson Condie, Neil Conway, Peter Alvaro, Joseph M. Hellerstein, Khaled Elmeleegy, and Russell Sears. Mapreduce online. Technical Report UCB/EECS , EECS Department, University of California, Berkeley, Oct Jeffrey Dean and Sanjay Ghemawat. Mapreduce: Simplified data processing on large clusters. In OSDI, pages , [KAGW10] Vibhore Kumar, Henrique Andrade, Bugra Gedik, and Kun-Lung Wu. Deduce: at the intersection of mapreduce and stream processing. In Ioana Manolescu, Stefano Spaccapietra, Jens Teubner, Masaru Kitsuregawa, Alain Léger, Felix Naumann, Anastasia Ailamaki, and Fatma Özcan, editors, EDBT, volume 426 of ACM International Conference Proceeding Series, pages ACM, [RM] [Whi09] Roger Rea and Krishna Mamidipaka, editors. IBM InfoSphere Streams - Redefining Real Time Analytics. IBM Software Group. Tom White. Hadoop: The Definitive Guide. O Reilly, first edition edition, june 2009.

253 MapReduce und Datenbanken - Ähnlichkeitssuche auf Mengen FernUniversität in Hagen Seminar im Sommersemester 2011 MapReduce und Datenbanken Thema 16 Ähnlichkeitssuche auf Mengen Referent: Andreas Kühl

254 MapReduce und Datenbanken - Ähnlichkeitssuche auf Mengen MERKMALSEXTRAKTION... 4 MERKMALSREDUKTION... 4 KLASSIFIKATION... 4 MUSTERERKENNUNG UND MAPREDUCE... 5 ÄHNLICHKEITSSUCHE... 5 Jaccard-Koeffizient... 5 PHASE 1 TOKEN ORDERING... 7 Hauptvariante Basic Token Ordering (BTO)... 7 Alternative Variante Using One Phase to Order Tokens (OPTO)... 8 PHASE 2 RID-PAAR GENERIERUNG... 9 Variante Basic Kernel... 9 Alternative Umsetzungen PHASE 3 RECORD JOIN Variante Basic Record Join (BRJ) Alternative Variante One-Phase Record Join (OPRJ) TECHNIK UND TESTDATEN HERAUSFORDERUNG UNZUREICHENDER SPEICHER WAS BRINGT MAPREDUCE IN DER ÄHNLICHKEITSSUCHE? MAPREDUCE UND ALGORITHMEN Alternative Varianten... 14

255 Einführung In der vorliegenden Veröffentlichung wird beschrieben, wie eine Ähnlichkeitssuche mit MapReduce umgesetzt werden kann. Ähnlichkeitssuche wird in verschiedenen Bereichen der Mustererkennung eingesetzt. Die Autoren haben sich den Bereich der Textvergleiche ausgesucht. Als mögliche Einsatzgebiete geben sie dabei an die Clustern von Dokumenten die Erkennung von Plagiaten der Vergleich von ähnlichen Suchanfragen durch verschiedene Anwender die Erkennung von Betrugsversuchen in Zusammenhang mit Online-Werbung Schwerpunkt und Stärken des Artikels sind 1. Beschreibung der Umsetzung der Map-Reduce-Blöcke (nicht der Algorithmen selbst) 2. Alternative Vorgehensweisen zur Optimierung von Performance und Speicherplatzverbrauch 3. Auswertung der Auslastung der einzelnen Knoten in den Algorithmen. Der letzte Punkt wird hier ausgelassen, der Schwerpunkt liegt auf der Betrachtung der Punkte 1 und 2. Nicht besprochen werden im Artikel die Details der Algorithmen der Mustererkennung, obwohl die Qualität hauptsächlich von der Parametrierung dieser Algorithmen abhängt. Ebenso wurde auf eine qualitative Analyse der Ergebnisse verzichtet.

256 Mustererkennung Die Mustererkennung lässt sich in mehrere Schritte unterteilen: Merkmalsextraktion Merkmalsreduktion Klassifikation Merkmalsextraktion Die Merkmale sind stark vom Kontext abhängig. In dem Fall der Texterkennung oder der Vergleiche von Texten kann es Merkmale geben, die mehr oder weniger aussagekräftig sind. Je bekannter die möglichen Eingangsdaten sind, desto bessere Merkmale lassen sich für gute Suchen definieren. Beispiel - Suche nach Themen: o Ein Merkmal kann hier ein einzelner Begriff, speziell Fachbegriff sein (siehe Suche in Suchmaschinen) Beispiel Suche nach Textpassagen o Merkmalsreduktion Einzelne Begriffe sind hier unzureichend, da gerade Fachbegriffe kein Indiz dafür sind, ob etwas kopiert worden ist. Statt dessen kommt es hier auf ganze Sätze an. Welche Merkmale sind in dem aktuellen Kontext wirklich aussagekräftig? Anmerkung: Beispiel Fachbegriff o o o Im Titel ist dieser Fachbegriff sehr aussagekräftig, auch wenn er sonst nicht mehr im Text vorkommt. Wenn der Fachbegriff im Text nur einmal vorkommt, ist er vermutlich eher irrelevant Wenn der Fachbegriff im Text mehrmals vorkommt, erhöht sich dagegen seine Relevanz, selbst wenn er im Titel nicht erwähnt wird. Das Wissen über Merkmalsextraktion und Merkmalsreduktion ist in der Realität bedeutend. Es wird beispielsweise ausgenutzt, um die Ergebnisse von Google zu manipulieren. Man muss also die eigenen Bewertungsalgorithmen immer wieder in Frage stellen. Klassifikation Bei Klassifizierung werden die Merkmale und ihre Ausprägungen in Klassen zusammengefasst.

257 Mustererkennung und MapReduce Im vorliegenden Beispiel sollen Algorithmen aus der Mustererkennung mit MapReduce verknüpft werden. Mustererkennung funktioniert auch ohne MapReduce und kommt auch auf die gleichen Ergebnisse. Der Vorteil liegt also nicht in der Qualität der Ergebnisse. Die Qualität der Ergebnisse hängt allein von den verwendeten Algorithmen der Mustererkennung ab. Allerdings sind die Datenmengen eine große Herausforderung für die Mustererkennung, und an dieser Stelle kommt MapReduce ins Spiel. Es gibt der Mustererkennung eine Möglichkeit, mit der großen Datenmenge zurecht zu kommen. Im einfachsten Fall kann man die Extraktion der Merkmale in die Map-Phase stecken und die Reduktion in die Reduce-Phase. Oft ist jedoch sinnvoller, mehrere Map-Reduce-Blöcken miteinander zu koppeln. Ähnlichkeitssuche Es gibt verschiedene Algorithmen für Berechnung von Ähnlichkeiten. Im vorliegenden Text werden folgende Algorithmen erwähnt: Jaccard-Koeffizient Cosinus-Koeffizient Tanimoto-Koeffizient PPJoin+Algorithmus Alle Algorithmen haben ihre Stärken und Schwächen. Der Jaccard-Koeffizient ist ein sehr einfacher Algorithmus, an dem man die Problematik gut erläutern kann. Die Autoren des vorliegenden Textes verwenden den PPJoin+ Algorithmus und den Jaccard- Algorithmus. Jaccard-Koeffizient Mit dem Jaccard-Koeffizienten kann die Ähnlichkeit zwischen zwei Elementen berechnet werden. Dabei wird die Summe der gemeinsamen Merkmale durch die Summe aller Merkmale geteilt. J ( A, B) = A A B B Dazu ein Beispiel mit Texten: Ausgangssatz A: I will call you back Vergleichsatz B: I will phone you Vergleichsatz C: I will drive you back home Vergleichssatz D: I will call you back as soon as I am back from London Daraus ergeben sich folgende Koeffizienten: A + B : 3 / 6 = 0.5 A + C : 4 / 7 = 0.57

258 A + D : 5 / 10 = 0.5 Wie man sehen kann, erreicht den besten Wert ein Beispiel, welches vom Sinn am schlechtesten ist. Beim Jaccard-Koeffizienten hängt viel auch von der Länge der Vergleichssätze ab. Dass dabei ein Satzteil einfach nur den andere ergänzt, wird bestraft, weil er zu der Gesamtmenge viele ungleiche Worte liefert. Das heisst nicht, dass der Jaccard-Koeffizient prinzipiell ungeeignet ist. Es hängt sehr stark von den Aufgaben ab. Annahme A: Beim Kopieren von Sätzen werden nur wenige Worte geändert. Folge A: Das würde bedeuten, dass sich auch bei langen Sätzen klare Übereinstimmungen finden lassen. Annahme B: Bei wissenschaftlichen Texten werden oft lange Sätze verwendet. Folge B: die bessere Beurteilung der kurzen Sätze würde nicht ins Gewicht fallen. Annahme C: Bei Interviews werden eher kurze Sätze verwendet Folge C: Beim Vergleich von Interviews würden wir schlechtere Ergebnisse finden. Die Beispiele lassen sich hier beliebig fortsetzen. Es ist daher wichtig für die Qualität der Ergebnisse, dass man sich über zwei Punkte im Klaren ist Wie sind Qualität und Eigenschaften der Eingangsdaten Welche Antworten will ich haben Dies gilt generell in der Mustererkennung und der Vergleich von Texten bildet da keine Ausnahme.

259 Umsetzung mit MapReduce Der Ablauf der Ähnlichkeitssuche besteht aus mehreren Phasen, die im folgenden Detailliert beschrieben werden Phase 1 Token Ordering o Diese Phase kann man mit der Merkmalsdefinition und Merkmalsextraktion aus dem Kapitel Mustererkennung gleichsetzen Phase 2 - RID-Pair Generation o Diese Phase entspricht der Merkmalsreduktion und Klassifikation aus der Mustererkennung Phase 3 Record Join Phase 1 Token Ordering Token lassen sich am besten mit Merkmalen übersetzen. Über die Summe der Merkmale eines Textes oder Satzes lassen sich diese identifizieren und beschreiben. Das Problem dabei ist, dass es fast unendlich viele Merkmale gibt, man muss sich also für bestimmte Merkmale entscheiden. Im vorliegenden Text werden 2 Arten von Merkmalen erwähnt, Worte und q-gramme. Q-Gramme sind ein wichtiges Element, was in vielen Bereichen von Google eingesetzt wird. Im Prinzip schaut man nicht auf Worte, sondern auf Wortteile einer festen Länge. Um eine einfache und auch im Text beschriebene Alternative ist, die einzelnen Worte eines Textes als Merkmale zu betrachten. Der Satz I will call back hätte also die 4 Merkmale I, will, call und back. Aufgabe des Token Orderings ist: It scans the data, computes the frequency of each token, and sorts the tokens based on frequency [aus [4], Seite 497] Der erste Schritt besteht aus dem Extrahieren von Merkmale. Anschliessend werden diese Merkmale sortiert. Jeder dieser beiden Schritte lässt sich in einem eigenen MapReduce-Block realisieren. Hauptvariante Basic Token Ordering (BTO) MapReduce-Block Extrahieren der Merkmale Map-Funktion o o Eingangsparameter sind die Originaldaten. Man könnte hierbei unterteilen in komplette Texte, in Textpassagen oder gar nur in einzelne Sätze. Auf diese Unterscheidungen wird jedoch nicht eingegangen. Für jeden Datensatz werden alle Merkmale extrahiert und in den Zwischenspeicher geschrieben. Für jedes Merkmal wird dabei ein paar produziert: (Merkmal, 1). Die 1 ist dabei die Häufigkeit, die hier immer 1 ist. Combine-Funktion (Zwischenschritt) o Dieser Zwischenschritt wird vorgenommen, um die Last im Netzwerk zu reduzieren.

260 o Alle Merkmalspaare des lokalen Zwischenspeichers werden auf dem Knoten durchgegangen und aufsummiert: (Merkmal, Anzahl) Reduce-Funktion o Die Ergebnisse der einzelnen Knoten werden nach Merkmalen aufsummiert MapReduce-Block Sortieren der Merkmalslisten Map-Funnktion o Für alle Merkmalspaare werden Anzahl und Merkmal miteinander vertauscht und nach Häufigkeit sortiert (Merkmal, Anzahl) => (Anzahl, Merkmal) Reduce-Funktion o Zusammenfassen der Ergebnisse der einzelnen Zwischenspeicher und erstellen einer vollständig sortierten Liste aller Merkmales Hier noch mal eine schematische Darstellung des Ablaufs der Phase 1 [aus [4], S. 498] Alternative Variante Using One Phase to Order Tokens (OPTO) Ein Alternativer Ansatz der Autoren für die erste Phase ist, sich auf einen MapReduce -Block zu beschränken. Bei diesem Ansatz wird der MapReduce-Block Sortieren der Merkmalslisten in die Reduce-Funktion des ersten Blocks integriert. Der Vorteil an diesem Ansatz ist die Reduzierung der Rechenschritte. Der Nachteil ist der Speicherverbrauch. Die Autoren haben festgestellt, dass in ihren Fällen keine Speicherprobleme auftreten.

261 Phase 2 RID-Paar Generierung Prefix-Filterung wird im Deutschen auch als Taubenschlags-Algorithmus bezeichnet. Grundannahme ist dabei, dass man Elemente hat, die zu Sortieren sind, als dass es Kategorien gibt, denen sie zugeordnet werden sollen. Ein Beispiel: Man hat 50 Personen, die im Mai Geburtstag haben und sortiert diese nach den einzelnen Tagen im Mai. Man bekommt entsprechend eine Gruppierung der Personen nach ihren Geburtstagen, wobei es mindestens einen Fall gibt, in dem mehr als eine Person nicht alleine in einer Kategorie ist. Entsprechend ist es auch hier: Man nimmt eine Anzahl von Merkmalen und sucht, welche Datensätze in mindestens einem Merkmal übereinstimmen. Diese Merkmale werden zusammen auf einem Knoten verarbeitet. Aufgabe der zweiten Phase ist es, die Ausgangsdaten zu scannen, und die Prefixes zu berechnen, und zwar auf Grundlage der Merkmale aus Phase 1. Grundannahme ist dabei, dass die Anzahl der Tokens kleiner ist als die Anzahl der Datensätze. Die Token bilden dabei die Kategorien, denen die Datensätze zugeordnet werden. Ergebnis ist dann eine Liste von Datensätze, die mindestens ein Merkmal gemeinsam haben, und in der Folgephase auf einem Knoten verarbeitet werden sollen. Variante Basic Kernel Map-Funktion o o o o o Eingangsdaten sind die Originaldaten imklusive ihrer Join-Attribute und die nach Häufigkeit sortierten Merkmale der Texte. Aus den Ausgangsdaten werden nacheinander alle RIDs und Join-Attribute extrahiert. Reduce-Phase o o o o Join-Attribute können beispielsweise ganze Sätze oder Satzanfänge oder bestimmte Worte eines Satzes sein. Die Join-Attribute werden nach Merkmalen analysiert Die Präfix-Länge und die Präfix-Merkmale werden berechnet Ergebnis der Map-Funktion ist ein paar (Merkmal, RID+Join-Attribut) Die Zwischenergebnisse werden zusammengefasst und ein erstes Ähnlichkeitsmass berechnet Dabei werden weitere Filter eingesetzt, um die Anzahl der weiterzuverarbeitenden Daten zu reduzieren. Für die Filter und die Berechnung der Ähnlichkeit werden beispielsweise PPJoin+ Algorithmen einsetzt Ergebnis ist dann eine Liste (RID 1, RID2, Ähnlichkeit)

262 Hier noch mal eine schematische Darstellung des Ablaufs der Phase 1 [aus [4], S. 499] Alternative Umsetzungen Auch bei diesem Schritt gibt es Möglichkeiten, die Netzwerklast zu verringern. Beschrieben wird hier die Variante, dass für jedes Merkmal in der Map-Funktion ein eigener Ergebnis-Satz generiert wird. Es gibt jedoch auch die Möglichkeit, mehrere Merkmale zusammenzufassen. Dies lässt sich schon in der Map-Funktion realisieren, so dass keine eigene Combine-Funktion wie in Phase 1nötig ist. Eine weitere Alternative sind hier wie schon oben erwähnt andere Ähnlichkeitsmasse. In der alternativen Umsetzung der Autoren verwenden sie den PPJoin+ Algorithmus. Wie schon erwähnt ist die Auswahl des Ähnlichkeitsmasses wesentlich für die Qualität der Ergebnisse. Die Autoren machen hierzu keine Angaben, allerdings verweisen sie auf die Literatur. Zusätzlich muss man beachten, dass die Qualität auch von der Zielsetzung abhängt. Beachtenswert ist jedoch die Feststellung der Autoren, dass der PPJoin+ Algorithmus zu einer guten Ausnutzung des Speichers führt. Insbesondere in diesem Zusammenhang In der Phase 2 kann es passieren, dass die Knoten ungleichmäßig ausgelastet werden. Grund dafür ist die unterschiedliche Häufigkeit der Merkmale, die in Phase 1 berechnet wurden. Allerdings lässt sich über die Häufigkeit der Merkmale auch gut eine Verteilung auf die einzelnen Knoten berechnen.

263 Phase 3 Record Join Nach Phase 2 könnte man sagen, dass die Aufgabe erledigt ist. Die Ähnlichkeit zwischen den Eingangsdatensätzen wurde berechnet und nach einem Schwellwert gefiltert. Allerdings wird im Ergebnis nur auf die Originaldaten verwiesen, die Originaldaten werden nicht direkt ausgegeben. In Phase 2 fand der Ähnlichkeitsvergleich nicht auf den Originaldaten statt, sondern auf den Join- Attributen. Genaugenommen muss es für Phase 2 noch einen weiteren Map-Reduce-Block geben, der diese Join-Attribute erzeugt. Phase 3 könnte damit als optional betrachtet werden. Leider ist die Mustererkennung keine exakte Methode. Es werden Wahrscheinlichkeiten berechnet, keine eindeutigen Ergebnisse. Hier kommt wieder das Wissen eines Menschen ins Spiel, der viel komplexere Vergleiche durchführen kann. Die Kandidaten, die eine hohe Ähnlichkeit haben, sollen komplett und mit der berechneten Ähnlichkeit angezeigt werden, damit der Anwender als letzte Instanz sich diese Daten ansehen und eine letzte Entscheidung treffen kann. Oder damit ein anderes Programm einfacher die Daten weiterverarbeiten kann. Eine generelle Anmerkung noch, warum nicht auf den Originaldaten in Phase 2 gearbeitet wurde: der Grund dafür sind der verfügbare Speicher und die Geschwindigkeit der Verarbeitung. Man reduziert die Daten, die verarbeitet werden müssen, auf die Daten, die man als relevant ansieht, beispielsweise auf die ersten 5 Worte eines Satzes oder alle Nomen eines Satzes. Auf diese Weise kann man die Datenlast deutlich reduzieren. Variante Basic Record Join (BRJ) Eingangsdaten für Phase 2 sind Die Ausgangsdatensätze Die Paare aus Phase 2 (RID1, RID2, Ähnlichkeit) Die Autoren beschreiben zwei Ansätze, die RIDs mit den Ausgangsdaten in Verbindung zu bringen. Hier soll nur Variante 1 beschrieben werden. Basic Record Join: (RID1, RID2, Ähnlichkeit) wird aufgespalten in (RID1, Referenz-ID) und (RID2, Referenz- ID) o Referenz-ID ist dabei die ID des Ergebnis-Datensatzes aus Phase 2. Anhand dieser ID werden dann die beiden Teilergebnisse wieder zusammengeführt Beide RIDs werden auf getrennten Knoten bearbeitet Beide Ergebnisse werden wieder miteinander vereinigt Zur Verarbeitung werden wieder 2 MapReduce-Blöcke verwendet. Im ersten wird die Aufteilung der Datensätze durchgeführt, im zweiten werden die Originaldaten ermittelt und zusammengeführt. Alternative Variante One-Phase Record Join (OPRJ) Die Alternative Variante besteht darin, dass das Mapping zwischen den Originaldaten und den RIDs nicht einzeln passiert. Wieder wird die zweite Phase in die Reduce-Phase mit hineingezogen.

264 Hier noch mal eine schematische Darstellung des Ablaufs der Phase 3 [aus [4], S. 500]

Einführung in Hadoop

Einführung in Hadoop Einführung in Hadoop Inhalt / Lern-Ziele Übersicht: Basis-Architektur von Hadoop Einführung in HDFS Einführung in MapReduce Ausblick: Hadoop Ökosystem Optimierungen Versionen 10.02.2012 Prof. Dr. Christian

Mehr

MapReduce und Datenbanken Thema 15: Strom bzw. Onlineverarbeitung mit MapReduce

MapReduce und Datenbanken Thema 15: Strom bzw. Onlineverarbeitung mit MapReduce MapReduce Jan Kristof Nidzwetzki MapReduce 1 / 17 Übersicht 1 Begriffe 2 Verschiedene Arbeiten 3 Ziele 4 DEDUCE: at the intersection of MapReduce and stream processing Beispiel 5 Beyond online aggregation:

Mehr

Data Mining in der Cloud

Data Mining in der Cloud Data Mining in der Cloud von Jan-Christoph Meier Hamburg, 21.06.2012 1 Ablauf Einführung Verwandte Arbeiten Fazit / Ausblick Literatur 2 Ablauf Einführung Verwandte Arbeiten Fazit / Ausblick Literatur

Mehr

MapReduce in der Praxis

MapReduce in der Praxis MapReduce in der Praxis Rolf Daniel Seminar Multicore Programmierung 09.12.2010 1 / 53 Agenda Einleitung 1 Einleitung 2 3 Disco Hadoop BOOM 4 2 / 53 1 Einleitung 2 3 Disco Hadoop BOOM 4 3 / 53 Motivation

Mehr

Map Reduce on Hadoop Seminar SS09. Similarity Join. Tim Felgentreff, Andrina Mascher

Map Reduce on Hadoop Seminar SS09. Similarity Join. Tim Felgentreff, Andrina Mascher Map Reduce on Hadoop Seminar SS09 Similarity Join Tim Felgentreff, Andrina Mascher Gliederung 2!! Aufgabe!! Demo!! Algorithmus!! Performance!! Veränderte Aufgabenstellung:!! Vergleich mit 1 Seite!! Ausblick!!

Mehr

Seminar Cloud Data Management WS09/10. Tabelle1 Tabelle2

Seminar Cloud Data Management WS09/10. Tabelle1 Tabelle2 Seminar Cloud Data Management WS09/10 Tabelle1 Tabelle2 1 Einführung DBMS in der Cloud Vergleich verschiedener DBMS Beispiele Microsoft Azure Amazon RDS Amazon EC2 Relational Databases AMIs Was gibt es

Mehr

Datenbearbeitung in der Cloud anhand von Apache Hadoop Hochschule Mannheim

Datenbearbeitung in der Cloud anhand von Apache Hadoop Hochschule Mannheim Tobias Neef Cloud-Computing Seminar Hochschule Mannheim WS0910 1/23 Datenbearbeitung in der Cloud anhand von Apache Hadoop Hochschule Mannheim Tobias Neef Fakultät für Informatik Hochschule Mannheim tobnee@gmail.com

Mehr

Parallele Datenverarbeitung Pig, Hive & SystemT/JAQL. Henning Kropp wir02jcr@studserv.uni-leipzig.de 1-39

Parallele Datenverarbeitung Pig, Hive & SystemT/JAQL. Henning Kropp wir02jcr@studserv.uni-leipzig.de 1-39 Parallele Datenverarbeitung Pig, Hive & SystemT/JAQL Henning Kropp wir02jcr@studserv.unileipzig.de 1 2 Übersicht Parallele Datenverarbeitung MapReduce Pig Hive SystemT/JAQL Zusammenfassung Parallele Datenverarbeitung

Mehr

Dateisysteme mit Plugin-Funktion

Dateisysteme mit Plugin-Funktion Dateisysteme mit Plugin-Funktion Basierend auf Reiser 4 unter Linux http://llugb.amsee.de/logo.gif Ausgearbeitet und vorgetragen von Michael Berger 1/23 Agenda Die Idee Dateisysteme mit Plugin-Funktion

Mehr

Lehrgebiet Informationssysteme

Lehrgebiet Informationssysteme Lehrgebiet AG Datenbanken und (Prof. Michel, Prof. Härder) AG Heterogene (Prof. Deßloch) http://wwwlgis.informatik.uni-kl.de/ Was sind? Computergestützte Programmsysteme, die Informationen erfassen, dauerhaft

Mehr

Spark, Impala und Hadoop in der Kreditrisikoberechnung

Spark, Impala und Hadoop in der Kreditrisikoberechnung Spark, Impala und Hadoop in der Kreditrisikoberechnung Big Data In-Memory-Technologien für mittelgroße Datenmengen TDWI München, 22. Juni 2015 Joschka Kupilas, Data Scientist, Adastra GmbH 2 Inhalt Vorwort

Mehr

Big Data. Prof. Robert Jäschke Forschungszentrum L3S Leibniz Universität Hannover

Big Data. Prof. Robert Jäschke Forschungszentrum L3S Leibniz Universität Hannover Big Data Prof. Robert Jäschke Forschungszentrum L3S Leibniz Universität Hannover Agenda Was ist Big Data? Parallele Programmierung Map/Reduce Der Big Data Zoo 2 3Vs oder: Was ist Big Data? Deutsche Telekom:

Mehr

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015 Abstrakt zum Vortrag im Oberseminar Graphdatenbanken Gero Kraus HTWK Leipzig 14. Juli 2015 1 Motivation Zur Darstellung komplexer Beziehungen bzw. Graphen sind sowohl relationale als auch NoSQL-Datenbanken

Mehr

June 2015. Automic Hadoop Agent. Data Automation - Hadoop Integration

June 2015. Automic Hadoop Agent. Data Automation - Hadoop Integration June 2015 Automic Hadoop Agent Data Automation - Hadoop Integration + Aufbau der Hadoop Anbindung + Was ist eigentlich ist MapReduce? + Welches sind die Stärken von Hadoop + Welches sind die Schwächen

Mehr

Hadoop. Simon Prewo. Simon Prewo

Hadoop. Simon Prewo. Simon Prewo Hadoop Simon Prewo Simon Prewo 1 Warum Hadoop? SQL: DB2, Oracle Hadoop? Innerhalb der letzten zwei Jahre hat sich die Datenmenge ca. verzehnfacht Die Klassiker wie DB2, Oracle usw. sind anders konzeptioniert

Mehr

SEMT. Prof. G. Bengel. Searching as a Service (Programming Model: MapReduce)

SEMT. Prof. G. Bengel. Searching as a Service (Programming Model: MapReduce) Hochschule Mannheim Fakultät für Informatik SEMT Prof. G. Bengel Sommersemester 2009 Semester 8I Searching as a Service (Programming Model: MapReduce) Michel Schmitt (520361) 1.06.2009 Inhalt 1. Einführung...

Mehr

Dateisysteme und Datenverwaltung in der Cloud

Dateisysteme und Datenverwaltung in der Cloud Dateisysteme und Datenverwaltung in der Cloud Sebastian Fischer Master-Seminar Cloud Computing - WS 2013/14 Institut für Telematik, Universität zu Lübeck Dateisysteme und Datenverwaltung in der Cloud 1

Mehr

Einführung in Hauptspeicherdatenbanken

Einführung in Hauptspeicherdatenbanken Einführung in Hauptspeicherdatenbanken Harald Zankl Probevorlesung 13. 01., 13:15 14:00, HS C Inhaltsverzeichnis Organisation Überblick Konklusion Harald Zankl (LFU) Hauptspeicherdatenbanken 2/16 Organisation

Mehr

FernUniversität in Hagen. Seminar Big Data Management

FernUniversität in Hagen. Seminar Big Data Management FernUniversität in Hagen Fakultät für Mathematik und Informatik Sommersemester 2013 Seminar Big Data Management Prof. Dr. Ralf Hartmut Güting Fabio Valdés Einführung Angesichts der rasant anwachsenden

Mehr

Parallele und funktionale Programmierung Wintersemester 2013/14. 8. Übung Abgabe bis 20.12.2013, 16:00 Uhr

Parallele und funktionale Programmierung Wintersemester 2013/14. 8. Übung Abgabe bis 20.12.2013, 16:00 Uhr 8. Übung Abgabe bis 20.12.2013, 16:00 Uhr Aufgabe 8.1: Zeigerverdopplung Ermitteln Sie an folgendem Beispiel den Rang für jedes Listenelement sequentiell und mit dem in der Vorlesung vorgestellten parallelen

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

Grundlagen des Grid Computing

Grundlagen des Grid Computing Grundlagen des Grid Computing Grid Middleware Toolkits: glite ICA Joh.. Kepler Universität t Linz glite Grid Middleware für das LHC Grid Wurde im Rahmen des EGEE Projekts entwickelt Basiert auf dem Globus

Mehr

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht)

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Christian Haag, DATA MART Consulting Consulting Manager Oracle DWH Team

Mehr

FernUniversität in Hagen - Seminar 01912 im Sommersemester 2011. MapReduce und Datenbanken

FernUniversität in Hagen - Seminar 01912 im Sommersemester 2011. MapReduce und Datenbanken FernUniversität in Hagen - Seminar 01912 im Sommersemester 2011 MapReduce und Datenbanken Thema 15 Strom- bzw. Onlineverarbeitung mit MapReduce Referent: Jan Kristof Nidzwetzki 2 Jan Kristof Nidzwetzki,

Mehr

DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER

DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER INHALTSVERZEICHNIS 1. Datenbanken 2. SQL 1.1 Sinn und Zweck 1.2 Definition 1.3 Modelle 1.4 Relationales Datenbankmodell 2.1 Definition 2.2 Befehle 3.

Mehr

Big Data in der Forschung

Big Data in der Forschung Big Data in der Forschung Dominik Friedrich RWTH Aachen Rechen- und Kommunikationszentrum (RZ) Gartner Hype Cycle July 2011 Folie 2 Was ist Big Data? Was wird unter Big Data verstanden Datensätze, die

Mehr

11. Mehrrechner-DBMSe / Datenbankmaschinen

11. Mehrrechner-DBMSe / Datenbankmaschinen 11. Mehrrechner-e / Datenbankmaschinen In der Vergangenheit DB-Maschinen oft auf Basis von Spezial-HW-/SW Schnittstelle Anwendungsprogramm - DB-Maschine oft "nicht hoch" genug Interaktion und Integration

Mehr

Persönlichkeiten bei bluehands

Persönlichkeiten bei bluehands Persönlichkeiten bei Technologien bei Skalierbare Anwendungen mit Windows Azure GmbH & co.mmunication KG am@.de; posts..de/am 1 2 3 4 5 6 7 8 9 Immer mehr Mehr Performance Mehr Menge Mehr Verfügbarkeit

Mehr

Ausarbeitung AW2 SS2012. Jan-Christoph Meier Data Mining in der Cloud

Ausarbeitung AW2 SS2012. Jan-Christoph Meier Data Mining in der Cloud Ausarbeitung AW2 SS2012 Jan-Christoph Meier Data Mining in der Cloud Fakultät Technik und Informatik Department Informatik Faculty of Engineering and Computer Science Department of Computer Science Inhaltsverzeichnis

Mehr

Remote Communications

Remote Communications HELP.BCFESDEI Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher

Mehr

DATA WAREHOUSE. Big Data Alfred Schlaucher, Oracle

DATA WAREHOUSE. Big Data Alfred Schlaucher, Oracle DATA WAREHOUSE Big Data Alfred Schlaucher, Oracle Scale up Unternehmensdaten zusammenfassen Noch mehr Informationen aus Unternehmens- Daten ziehen! Datenmengen, Performance und Kosten Daten als Geschäftsmodell

Mehr

Large Scale Data Management

Large Scale Data Management Large Scale Data Management Beirat für Informationsgesellschaft / GOING LOCAL Wien, 21. November 2011 Prof. Dr. Wolrad Rommel FTW Forschungszentrum Telekommunikation Wien rommel@ftw.at Gartner's 2011 Hype

Mehr

on Azure mit HDInsight & Script Ac2ons

on Azure mit HDInsight & Script Ac2ons Willkommen beim #GAB 2015! on Azure mit HDInsight & Script Ac2ons Lokale Sponsoren: HansPeter Grahsl Netconomy Entwickler & Berater FH CAMPUS 02 Twi9er: @hpgrahsl Überblick Inhalte Was ist HDInsight? Wozu

Mehr

Cloud-Infrastrukturen Seminar Cloud Data Management WS09/10

Cloud-Infrastrukturen Seminar Cloud Data Management WS09/10 Cloud-Infrastrukturen Seminar Cloud Data Management WS09/10 Richard Beyer 1 Inhalt 1. Allgemeines 2. Amazon EC2 3. Yahoo Cloud 4. Vergleich 5. Fazit 6. Literatur Richard Beyer 2 Definition Cloud computing

Mehr

Thema: Das MapReduce-Framework

Thema: Das MapReduce-Framework Software as a Service Cloud Computing und aktuelle Entwicklungen Seminararbeit Thema: Das MapReduce-Framework Betreuer: Prof. Dr. Klaus Küspert Dipl.-Inf. Andreas Göbel Nicky Kuhnt Friedrich-Schiller-Universität

Mehr

Autor: Michael Spahn Version: 1.0 1/10 Vertraulichkeit: öffentlich Status: Final Metaways Infosystems GmbH

Autor: Michael Spahn Version: 1.0 1/10 Vertraulichkeit: öffentlich Status: Final Metaways Infosystems GmbH Java Einleitung - Handout Kurzbeschreibung: Eine kleine Einführung in die Programmierung mit Java. Dokument: Autor: Michael Spahn Version 1.0 Status: Final Datum: 23.10.2012 Vertraulichkeit: öffentlich

Mehr

Seminar WS 2012/13. S. Chaudhuri et al, CACM, Aug. 2011. Parallel DBS vs. Open Platforms for Big Data, e.g. HaDoop Near-Realtime OLAP

Seminar WS 2012/13. S. Chaudhuri et al, CACM, Aug. 2011. Parallel DBS vs. Open Platforms for Big Data, e.g. HaDoop Near-Realtime OLAP Seminar WS 2012/13 S. Chaudhuri et al, CACM, Aug. 2011 Parallel DBS vs. Open Platforms for Big Data, e.g. HaDoop Near-Realtime OLAP 2 Vorkonfigurierte, komplette Data Warehouse-Installation Mehrere Server,

Mehr

Detecting Near Duplicates for Web Crawling

Detecting Near Duplicates for Web Crawling Detecting Near Duplicates for Web Crawling Gurmeet Singh Manku et al., WWW 2007* * 16th international conference on World Wide Web Detecting Near Duplicates for Web Crawling Finde near duplicates in großen

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

DATA MINING FÜR BIG DATA. Department Informatik Anwendungen 1 WiSe 2013/14 Anton Romanov

DATA MINING FÜR BIG DATA. Department Informatik Anwendungen 1 WiSe 2013/14 Anton Romanov DATA MINING FÜR BIG DATA Department Informatik Anwendungen 1 WiSe 2013/14 Anton Romanov 29.10.2013 2 Agenda Motivation Data Mining Assoziationsanalyse Clusteranalyse Big Data Map Reduce Apache Hadoop Relevante

Mehr

Einleitung. Literatur. Pierre Fierz. Architektur von Datenbanksystemen. Physische Datenunabhängigkeit. Der Datenbank Administrator (DBA) 1.

Einleitung. Literatur. Pierre Fierz. Architektur von Datenbanksystemen. Physische Datenunabhängigkeit. Der Datenbank Administrator (DBA) 1. Inhalt der Vorlesung Literatur 1 Datenmodellierung (Entity-Relationship Modell) 2 Das relationale Modell 3 Relationenalgebra 4 Datenbanksprache (SQL) 5 Normalisierung 6 Vom ERM zum Datenbankschema 7 Routinen

Mehr

Gliederung. Was ist Cloud Computing Charakteristiken Virtualisierung Cloud Service Modelle Sicherheit Amazon EC2 OnLive Vorteile und Kritik

Gliederung. Was ist Cloud Computing Charakteristiken Virtualisierung Cloud Service Modelle Sicherheit Amazon EC2 OnLive Vorteile und Kritik Cloud Computing Gliederung Was ist Cloud Computing Charakteristiken Virtualisierung Cloud Service Modelle Sicherheit Amazon EC2 OnLive Vorteile und Kritik 2 Bisher Programme und Daten sind lokal beim Anwender

Mehr

BigTable. 11.12.2012 Else

BigTable. 11.12.2012 Else BigTable 11.12.2012 Else Einführung Distributed Storage System im Einsatz bei Google (2006) speichert strukturierte Daten petabyte-scale, > 1000 Nodes nicht relational, NoSQL setzt auf GFS auf 11.12.2012

Mehr

Seminar im Sommersemester 2010 Datenbankanwendungen im Cloud Computing http://dbis.ipd.kit.edu/1535.php

Seminar im Sommersemester 2010 Datenbankanwendungen im Cloud Computing http://dbis.ipd.kit.edu/1535.php Seminar im Sommersemester 2010 Datenbankanwendungen im Cloud Computing http://dbis.ipd.kit.edu/1535.php www.kit.edu 06.09 Veranstalter Institut für Programmstrukturen und Datenorganisation (IPD) Lehrstuhl

Mehr

IBM Netezza Data Warehouse Appliances - schnelle Analysen mit hohen Datenmengen

IBM Netezza Data Warehouse Appliances - schnelle Analysen mit hohen Datenmengen IBM Netezza Data Warehouse Appliances - schnelle Analysen mit hohen Datenmengen Nahezu 70% aller Data Warehouse Anwendungen leiden unter Leistungseinschränkungen der unterschiedlichsten Art. - Gartner

Mehr

Überblick. Verarbeitung großer Datenmengen. MapReduce. Herausforderungen

Überblick. Verarbeitung großer Datenmengen. MapReduce. Herausforderungen Überblick Verarbeitung großer Datenmengen Verarbeitung großer Datenmengen Motivation MapReduce Zusammenfassung Problemstellungen (e) Indexierung des World Wide Web PageRank-Berechnungen für Web-Seiten

Mehr

Projektpraktikum: Verteilte Datenverarbeitung mit MapReduce

Projektpraktikum: Verteilte Datenverarbeitung mit MapReduce Projektpraktikum: Verteilte Datenverarbeitung mit MapReduce Timo Bingmann, Peter Sanders und Sebastian Schlag 21. Oktober 2014 @ PdF Vorstellung INSTITUTE OF THEORETICAL INFORMATICS ALGORITHMICS KIT Universität

Mehr

Semantic Web: Resource Description Framework (RDF)

Semantic Web: Resource Description Framework (RDF) Big Data Semantic Web: RDF Information Retrieval Map Reduce: Massiv parallele Verarbeitung Datenströme Peer to Peer Informationssysteme No SQL Systeme Multi-Tenancy/Cloud-Datenbanken Semantic Web: Resource

Mehr

Download:.../~rieche. gehalten am 2. Februar 2004. Stephan Rieche. Vortrag. Thema: Index Selection. von. Seminar Advanced Data Warehouse

Download:.../~rieche. gehalten am 2. Februar 2004. Stephan Rieche. Vortrag. Thema: Index Selection. von. Seminar Advanced Data Warehouse Seminar Advanced Data Warehouse Thema: Index Selection Vortrag von Stephan Rieche gehalten am 2. Februar 2004 Download:.../~rieche Inhalt des Vortrages 1. Einleitung - Was ist das Index Selection Problem?

Mehr

Big Data Anwendungen

Big Data Anwendungen Big Data Anwendungen Univ.-Prof. Dr.-Ing. Wolfgang Maass Chair in Information and Service Systems Department of Law and Economics WS 2011/2012 Wednesdays, 8:00 10:00 a.m. Room HS 021, B4 1 Wrap-Up Effiziente

Mehr

Integration Services - Dienstarchitektur

Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Dieser Artikel solle dabei unterstützen, Integration Services in Microsoft SQL Server be sser zu verstehen und damit die

Mehr

Proseminar - Data Mining

Proseminar - Data Mining Proseminar - Data Mining SCCS, Fakultät für Informatik Technische Universität München SS 2014, SS 2014 1 Data Mining: Beispiele (1) Hausnummererkennung (Klassifikation) Source: http://arxiv.org/abs/1312.6082,

Mehr

Cloud-Computing. 1. Definition 2. Was bietet Cloud-Computing. 3. Technische Lösungen. 4. Kritik an der Cloud. 2.1 Industrie 2.

Cloud-Computing. 1. Definition 2. Was bietet Cloud-Computing. 3. Technische Lösungen. 4. Kritik an der Cloud. 2.1 Industrie 2. Cloud Computing Frank Hallas und Alexander Butiu Universität Erlangen Nürnberg, Lehrstuhl für Hardware/Software CoDesign Multicorearchitectures and Programming Seminar, Sommersemester 2013 1. Definition

Mehr

Hadoop aus IT-Operations Sicht Teil 1 Hadoop-Grundlagen

Hadoop aus IT-Operations Sicht Teil 1 Hadoop-Grundlagen Hadoop aus IT-Operations Sicht Teil 1 Hadoop-Grundlagen Brownbag am Freitag, den 26.07.2013 Daniel Bäurer inovex GmbH Systems Engineer Wir nutzen Technologien, um unsere Kunden glücklich zu machen. Und

Mehr

MapReduce - Konzept. Seminararbeit. Thomas König (Mat.-Nr. 1740853) Master Informatik (3. Semester)

MapReduce - Konzept. Seminararbeit. Thomas König (Mat.-Nr. 1740853) Master Informatik (3. Semester) Universität Leipzig Institut für Informatik Abteilung Datenbanken Seminararbeit Autor: Studiengang: Thomas König (Mat.-Nr. 1740853) Master Informatik (3. Semester) Betreuer: Gutachter: Lars Kolb Lars Kolb

Mehr

Big Data Informationen neu gelebt

Big Data Informationen neu gelebt Seminarunterlage Version: 1.01 Copyright Version 1.01 vom 21. Mai 2015 Dieses Dokument wird durch die veröffentlicht. Copyright. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH Complex Hosting Autor.: Monika Olschewski Whitepaper Version: 1.0 Erstellt am: 14.07.2010 ADACOR Hosting GmbH Kaiserleistrasse 51 63067 Offenbach am Main info@adacor.com www.adacor.com Complex Hosting

Mehr

Kurs für Microsoft Online Kurs Microsoft Analysten Programmierer

Kurs für Microsoft Online Kurs Microsoft Analysten Programmierer Kurs für Microsoft Online Kurs Microsoft Analysten Programmierer Akademie Domani info@akademiedomani.de Allgemeines Programm des Kurses für Microsoft Modul 1 Basis Programm Erste Lerneinheit Einführung

Mehr

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Name: Matrikel-Nr: Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Bitte schreiben Sie leserlich und antworten Sie kurz und präzise. 1. Zeichnen Sie das Schichten-Modell eines Computersystems und markieren

Mehr

EMC. Data Lake Foundation

EMC. Data Lake Foundation EMC Data Lake Foundation 180 Wachstum unstrukturierter Daten 75% 78% 80% 71 EB 106 EB 133 EB Weltweit gelieferte Gesamtkapazität Unstrukturierte Daten Quelle März 2014, IDC Structured vs. Unstructured

Mehr

MapReduce. Dhyan Blum

MapReduce. Dhyan Blum MapReduce Dhyan Blum Betreuer: Dirk Haage Seminar Innovative Internettechnologien und Mobilkommunikation SS2010 Lehrstuhl Netzarchitekturen und Netzdienste Fakultät für Informatik, Technische Universität

Mehr

Stata I: Analyseorganisation und erste Schritte

Stata I: Analyseorganisation und erste Schritte Stata I: Analyseorganisation und erste Schritte 03. November 2003 Ziel dieser Veranstaltung ist zu lernen: 1. Benutzung der Hilfe-Funktion (help, search) 2. Ein Analyse-File zu erstellen 3. die Arbeit

Mehr

4 Greedy-Algorithmen (gierige Algorithmen)

4 Greedy-Algorithmen (gierige Algorithmen) Greedy-Algorithmen (gierige Algorithmen) Greedy-Algorithmen werden oft für die exakte oder approximative Lösung von Optimierungsproblemen verwendet. Typischerweise konstruiert ein Greedy-Algorithmus eine

Mehr

Neue Ansätze der Softwarequalitätssicherung

Neue Ansätze der Softwarequalitätssicherung Neue Ansätze der Softwarequalitätssicherung Googles MapReduce-Framework für verteilte Berechnungen am Beispiel von Apache Hadoop Universität Paderborn Fakultät für Elektrotechnik, Informatik und Mathematik

Mehr

3. Konzepte der objektorientierten Programmierung

3. Konzepte der objektorientierten Programmierung 3. Konzepte der objektorientierten Programmierung 3.1 Basiskonzepte 3.2 Generalisierung / Spezialisierung 3.3 Aggregation 3.4 Assoziation 3.5 Nachrichten 3.6 Polymorphismus 3. Konzepte der Objektorientierung

Mehr

Peer-to-Peer-basierte kollaborative Spam-Erkennung und Filterung

Peer-to-Peer-basierte kollaborative Spam-Erkennung und Filterung Der folgende Seminarbericht dient als Grundlage für die Studien-/Diplomarbeit über ein P2P basiertes Spambekämpfungssystem. Für die Studien/Diplomarbeit besonders relevante Stellen sind fett markiert.

Mehr

Big-Data-Technologien - Überblick - Prof. Dr. Jens Albrecht

Big-Data-Technologien - Überblick - Prof. Dr. Jens Albrecht Big-Data-Technologien - Überblick - Quelle: http://www.ingenieur.de/panorama/fussball-wm-in-brasilien/elektronischer-fussball-smartphone-app-helfen-training Big-Data-Anwendungen im Unternehmen Logistik

Mehr

EXASOL Anwendertreffen 2012

EXASOL Anwendertreffen 2012 EXASOL Anwendertreffen 2012 EXAPowerlytics Feature-Architektur EXAPowerlytics In-Database Analytics Map / Reduce Algorithmen Skalare Fkt. Aggregats Fkt. Analytische Fkt. Hadoop Anbindung R LUA Python 2

Mehr

Teil XI Spalten-orientierte DBMSs

Teil XI Spalten-orientierte DBMSs Teil XI Spalten-orientierte DBMSs Spalten-orientierte Datenbankmanagementsysteme 1 Motivation 2 Funktionsweise 3 Erweiterungen 4 Literatur c Sattler / Saake / Köppen Data-Warehouse-Technologien Letzte

Mehr

Leistungs- und Geschwindigkeitssteigerung. Dipl.-Ing. Sebastian F. Kleinau Applikationsingenieur

Leistungs- und Geschwindigkeitssteigerung. Dipl.-Ing. Sebastian F. Kleinau Applikationsingenieur Leistungs- und Geschwindigkeitssteigerung von LabVIEW-Projekten Dipl.-Ing. Sebastian F. Kleinau Applikationsingenieur Agenda 1. Einführung 2. Hilfreiche Werkzeuge zur Codeanalyse 3. Benchmarks für LabVIEW-VIs

Mehr

Grundlagen der Informatik. Prof. Dr. Stefan Enderle NTA Isny

Grundlagen der Informatik. Prof. Dr. Stefan Enderle NTA Isny Grundlagen der Informatik Prof. Dr. Stefan Enderle NTA Isny 2 Datenstrukturen 2.1 Einführung Syntax: Definition einer formalen Grammatik, um Regeln einer formalen Sprache (Programmiersprache) festzulegen.

Mehr

Perzentile mit Hadoop ermitteln

Perzentile mit Hadoop ermitteln Perzentile mit Hadoop ermitteln Ausgangspunkt Ziel dieses Projektes war, einen Hadoop Job zu entwickeln, der mit Hilfe gegebener Parameter Simulationen durchführt und aus den Ergebnissen die Perzentile

Mehr

Big Data Mythen und Fakten

Big Data Mythen und Fakten Big Data Mythen und Fakten Mario Meir-Huber Research Analyst, IDC Copyright IDC. Reproduction is forbidden unless authorized. All rights reserved. About me Research Analyst @ IDC Author verschiedener IT-Fachbücher

Mehr

Software as a Service, Cloud Computing und aktuelle Entwicklungen Seminarvorbesprechung

Software as a Service, Cloud Computing und aktuelle Entwicklungen Seminarvorbesprechung Software as a Service, Cloud Computing und aktuelle Entwicklungen Seminarvorbesprechung A. Göbel, Prof. K. Küspert Friedrich-Schiller-Universität Fakultät für Mathematik und Informatik Lehrstuhl für Datenbanken

Mehr

Teamprojekt & Projekt

Teamprojekt & Projekt 2. November 2010 Teamprojekt & Projekt Veranstalter: Betreuer: Prof. Dr. Georg Lausen Alexander Schätzle, Martin Przjyaciel-Zablocki, Thomas Hornung dbis Studienordnung Master: 16 ECTS 480 Semesterstunden

Mehr

API Monitoring mit Predictive Analytics

API Monitoring mit Predictive Analytics API Monitoring mit Predictive Analytics von Björn Baltbardis Björn Baltbardis, M-INF, HAW-Hamburg! Grundseminar, Betreuung durch Prof. Dr. Olaf Zukunft! 05.12.2014! Inhalt des Vortrags Einführung! Motivation!

Mehr

Web Data Mining. Alexander Hinneburg Sommersemester 2007

Web Data Mining. Alexander Hinneburg Sommersemester 2007 Web Data Mining Alexander Hinneburg Sommersemester 2007 Termine Vorlesung Mi. 10:00-11:30 Raum?? Übung Mi. 11:45-13:15 Raum?? Klausuren Mittwoch, 23. Mai Donnerstag, 12. Juli Buch Bing Liu: Web Data Mining

Mehr

Seminar SS 09 Amdahl`s Law and Cloud-Computing

Seminar SS 09 Amdahl`s Law and Cloud-Computing Seminar SS 09 Amdahl`s Law and Cloud-Computing Prof. G. Bengel Fakultät für Informatik SEMB 7IBW 8IB Raum HO609 Mo 9:45-11:15 1. Teil: Amdahl sches Gesetz 1. Vortrag Das Gesetz von Amdahl und Gustafson

Mehr

Lerox DB/2 Datenbankreferenz in QlikView für IBM System AS/400, iseries i5, System i

Lerox DB/2 Datenbankreferenz in QlikView für IBM System AS/400, iseries i5, System i Lerox DB/2 Datenbankreferenz in QlikView für IBM System AS/400, iseries i5, System i Inhaltsverzeichnis Überblick... 3 Die QlikView Applikation im Kontext... 4 Technische Rahmenbedinungen... 5 Funktionelle

Mehr

Verteilte Dateisysteme in der Cloud

Verteilte Dateisysteme in der Cloud Verteilte Dateisysteme in der Cloud Cloud Data Management Maria Moritz Seminar Cloud Data Management WS09/10 Universität Leipzig 1 Inhalt 1.) Anforderungen an verteilte Dateisysteme 2.) GoogleFS 3.) Hadoop

Mehr

Review Freelancer-Workshop: Fit für Big Data. Mittwoch, 29.04.2015 in Hamburg

Review Freelancer-Workshop: Fit für Big Data. Mittwoch, 29.04.2015 in Hamburg Review Freelancer-Workshop: Fit für Big Data Mittwoch, 29.04.2015 in Hamburg Am Mittwoch, den 29.04.2015, hatten wir von productive-data in Zusammenarbeit mit unserem langjährigen Partner Informatica zu

Mehr

Sructred Query Language

Sructred Query Language Sructred Query Language Michael Dienert 11. November 2010 Inhaltsverzeichnis 1 Ein kurzer Versionsüberblick 1 2 SQL-1 mit einigen Erweiterungen aus SQL-92 2 3 Eine Sprache zur Beschreibung anderer Sprachen

Mehr

Managed Cloud Services

Managed Cloud Services Managed Cloud Services Autor.: Monika Olschewski Whitepaper Version: 1.0 Erstellt am: 14.07.2010 ADACOR Hosting GmbH Kaiserleistrasse 51 63067 Offenbach am Main info@adacor.com www.adacor.com Cloud Services

Mehr

Cassandra Query Language (CQL)

Cassandra Query Language (CQL) Cassandra Query Language (CQL) Seminar: NoSQL Wintersemester 2013/2014 Cassandra Zwischenpräsentation 1 Gliederung Basic facts Datentypen DDL/DML ähnlich zu SQL Besonderheiten Basic facts CQL kurz für

Mehr

PostgreSQL in großen Installationen

PostgreSQL in großen Installationen PostgreSQL in großen Installationen Cybertec Schönig & Schönig GmbH Hans-Jürgen Schönig Wieso PostgreSQL? - Die fortschrittlichste Open Source Database - Lizenzpolitik: wirkliche Freiheit - Stabilität,

Mehr

Möglichkeiten für bestehende Systeme

Möglichkeiten für bestehende Systeme Möglichkeiten für bestehende Systeme Marko Filler Bitterfeld, 27.08.2015 2015 GISA GmbH Leipziger Chaussee 191 a 06112 Halle (Saale) www.gisa.de Agenda Gegenüberstellung Data Warehouse Big Data Einsatz-

Mehr

VS7 Slide 1. Verteilte Systeme. Vorlesung 7 vom 27.05.2004 Dr. Sebastian Iwanowski FH Wedel

VS7 Slide 1. Verteilte Systeme. Vorlesung 7 vom 27.05.2004 Dr. Sebastian Iwanowski FH Wedel VS7 Slide 1 Verteilte Systeme Vorlesung 7 vom 27.05.2004 Dr. Sebastian Iwanowski FH Wedel Inhaltsverzeichnis für die Vorlesung Zur Motivation: 4 Beispiele aus der Praxis Allgemeine Anforderungen an Verteilte

Mehr

1 Proseminar: Konzepte von Betriebssystem-Komponenten. Thema: Server OS AS/400 Referend: Sand Rainer. Server OS - AS/400

1 Proseminar: Konzepte von Betriebssystem-Komponenten. Thema: Server OS AS/400 Referend: Sand Rainer. Server OS - AS/400 1 Proseminar: Konzepte von Betriebssystem-Komponenten Server OS - AS/400 Gliederung Was ist eine AS/400? Wie ist OS/400 aufgebaut? Was kann eine AS/400? Bsp.: Logische Partitionierung 2 Proseminar: Konzepte

Mehr

MapReduce Parallelität im Großen und im Kleinen

MapReduce Parallelität im Großen und im Kleinen MapReduce Parallelität im Großen und im Kleinen Jens Lang jens.lang@informatik.tu-chemnitz.de MapReduce ist ein Programmiermodell für Parallelrechner, das die Möglichkeit bietet, effiziente parallele Programme

Mehr

Fachbereich Informatik Praktikum 1

Fachbereich Informatik Praktikum 1 Hochschule Darmstadt DATA WAREHOUSE SS2015 Fachbereich Informatik Praktikum 1 Prof. Dr. S. Karczewski Dipl. Inf. Dipl. Math. Y. Orkunoglu Datum: 14.April.2015 1. Kurzbeschreibung In diesem Praktikum geht

Mehr

Einführung in die OPC-Technik

Einführung in die OPC-Technik Einführung in die OPC-Technik Was ist OPC? OPC, als Standartschnittstelle der Zukunft, steht für OLE for Process Control,und basiert auf dem Komponentenmodel der Firma Microsoft,dem Hersteller des Betriebssystems

Mehr

Carl-Engler-Schule Karlsruhe Datenbank 1 (5)

Carl-Engler-Schule Karlsruhe Datenbank 1 (5) Carl-Engler-Schule Karlsruhe Datenbank 1 (5) Informationen zur Datenbank 1. Definition 1.1 Datenbank-Basis Eine Datenbank-Basis ist eine Sammlung von Informationen über Objekte (z.b Musikstücke, Einwohner,

Mehr

Verteilte Systeme. Map Reduce. Secure Identity Research Group

Verteilte Systeme. Map Reduce. Secure Identity Research Group Verteilte Systeme Map Reduce Map Reduce Problem: Ein Rechen-Job (meist Datenanalyse/Data-Mining) soll auf einer riesigen Datenmenge ausgeführt werden. Teile der Aufgabe sind parallelisierbar, aber das

Mehr

IT-Kompaktkurs. Datenbanken Skript zur Folge 10. Prof. Dr. Dieter Rummler Fachhochschule Deggendorf

IT-Kompaktkurs. Datenbanken Skript zur Folge 10. Prof. Dr. Dieter Rummler Fachhochschule Deggendorf IT-Kompaktkurs Skript zur Folge 10 Prof. Dr. Dieter Rummler Fachhochschule Deggendorf Client Server Architektur Zunächst zur grundsätzlichen Unterscheidung zwischen File-Server Datenbank und Server-Datenbank

Mehr

Das Knowledge Grid. Eine Architektur für verteiltes Data Mining

Das Knowledge Grid. Eine Architektur für verteiltes Data Mining Das Knowledge Grid Eine Architektur für verteiltes Data Mining 1 Gliederung 1. Motivation 2. KDD und PDKD Systeme 3. Knowledge Grid Services 4. TeraGrid Projekt 5. Das Semantic Web 2 Motivation Rapide

Mehr

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

Mehr

Data Warehousing. Sommersemester 2005. Ulf Leser Wissensmanagement in der Bioinformatik

Data Warehousing. Sommersemester 2005. Ulf Leser Wissensmanagement in der Bioinformatik Data Warehousing Sommersemester 2005 Ulf Leser Wissensmanagement in der Bioinformatik ... Der typische Walmart Kaufagent verwendet täglich mächtige Data Mining Werkzeuge, um die Daten der 300 Terabyte

Mehr

TCP/UDP. Transport Layer

TCP/UDP. Transport Layer TCP/UDP Transport Layer Lernziele 1. Wozu dient die Transportschicht? 2. Was passiert in der Transportschicht? 3. Was sind die wichtigsten Protkolle der Transportschicht? 4. Wofür wird TCP eingesetzt?

Mehr

Staff. Tim Conrad. Zeitplan. Blockseminar: Verteiltes Rechnen und Parallelprogrammierung. Sommer Semester 2013. Tim Conrad

Staff. Tim Conrad. Zeitplan. Blockseminar: Verteiltes Rechnen und Parallelprogrammierung. Sommer Semester 2013. Tim Conrad Blockseminar: Verteiltes Rechnen und Parallelprogrammierung Sommer Semester 2013 Tim Conrad Staff Tim Conrad AG Computational Proteomics email: conrad@math.fu-berlin.de Telefon: 838-51445 Büro: Raum 138,

Mehr