Eine. eingereicht. von

Größe: px
Ab Seite anzeigen:

Download "Eine. eingereicht. von"

Transkript

1 ALBERT-LUDWIGS-UNIVERSITÄT FREIBURG INSTITUT FÜR INFORMATIK PigSPARQL Eine Übersetzung von SPARQL nach n Pigg Latin MASTERARBEIT eingereicht von Alexander Schätzle am Lehrstuhl für Datenbanken und Informationssysteme Dozent: Prof. Dr. Georg Lausen Betreuer: Dipl.-Inf. Thomas Hornung 3. September 2010

2 Kurzfassung 2 Kurzfassung Gegenstand dieser Arbeit ist die effiziente Auswertung von SPARQL-Anfragen auf großen RDF-Datensätzen. Zum Einsatz kommt hierfür das Apache Hadoop Framework, eine Open-Source Implementierung von Google's MapReduce, das parallelisierte Berechnungen auf einem verteilten System ermöglicht. Zur Auswertung von SPARQL-Anfragen im Hadoop Framework wird in dieser Arbeit PigSPARQL, eine Übersetzung von SPARQL nach Pig Latin, vorgestellt. Pig Latin ist eine von Yahoo! Research entworfene Sprache zur verteilten Analyse von großen Datensätzen. Pig, die Implementierung von Pig Latin für Hadoop, übersetzt ein Pig Latin-Programm in eine Folge von MapReduce-Jobs, die anschließend auf einem Hadoop-Cluster ausgeführt werden. Die Evaluation von PigSPARQL anhand eines SPARQL spezifischen Benchmarks zeigt, dass der gewählte Ansatz eine effiziente Auswertung von SPARQL-Anfragen mit Hadoop ermöglicht. Schlagwörter: PigSPARQL, SPARQL, Pig Latin, RDF, MapReduce, Hadoop, SP 2 Bench, RDF Triple Store, SPARQL Algebra Abstract The subject of this Master Thesis is the efficient execution of SPARQL-queries on large RDF-datasets. This is done by using the Apache Hadoop Framework, an open-source implementation of Google's MapReduce for parallel calculations on a distributed system. The thesis introduces PigSPARQL, a translation from SPARQL to Pig Latin that can be used to execute SPARQL-queries with Hadoop. Pig Latin is a language for the distributed analysis of large datasets developed by Yahoo! Research. Pig, the implementation of Pig Latin for Hadoop, translates a Pig Latin program into a series of MapReduce-Jobs which are executed on a Hadoop-Cluster. The evaluation of PigSPARQL with a SPARQL specific benchmark shows that the selected approach allows the efficient execution of SPARQL-queries with Hadoop. Keywords: PigSPARQL, SPARQL, Pig Latin, RDF, MapReduce, Hadoop, SP 2 Bench, RDF Triple Store, SPARQL Algebra

3 Inhaltsverzeichnis 3 Inhaltsverzeichnis Kurzfassung... 2 Abstract... 2 Inhaltsverzeichnis... 3 Abbildungsverzeichnis... 6 Tabellenverzeichnis Einleitung Aufbau der Arbeit Grundlagen RDF MapReduce Map-Phase Shuffle-Phase Reduce-Phase Hadoop HDFS Lokalitätsprinzip SPARQL Einführung Allgemeiner Aufbau einer SPARQL-Anfrage Auswertung einer SPARQL-Anfrage SPARQL Algebra Pig Latin Datenmodell Operatoren User Defined Functions (UDF) Übersetzung in MapReduce-Plan... 38

4 Inhaltsverzeichnis Parallelität der Ausführung Übersetzung von SPARQL nach Pig Latin Konzeption der Übersetzung Abbildung von RDF in das Datenmodell von Pig Übersetzung der SPARQL Algebra Basic Graph Pattern (BGP) Filter Join LeftJoin Union ToList OrderBy Project Distinct Reduced Slice Beispiel Optimierungen Optimierung der SPARQL Algebra Filter Optimierung BGP Optimierung Optimierung der Übersetzung Optimierung des Datenmodells Implementierung Generierung des SPARQL Algebra-Baums Visitor Pattern Optimierungen der SPARQL Algebra Übersetzung der SPARQL Algebra Load/Store UDFs Evaluation Kennzahlen SP 2 Bench... 89

5 Inhaltsverzeichnis Auswertung einiger SP 2 Bench-Anfragen Q Q Q Q Q Q6 (modifiziert) Erkenntnisse der Evaluation Verwandte Arbeiten Zusammenfassung Anhang: Übersetzung der Sp 2 Bench-Anfragen Q Q3 (a,b,c) Q5a Q5b Q6 (modifiziert) Q Q Literaturverzeichnis Erklärung

6 Abbildungsverzeichnis 6 Abbildungsverzeichnis Abbildung 1: Aufbau der Arbeit Abbildung 2: einfaches RDF-Dokument Abbildung 3: einfacher RDF-Graph Abbildung 4: MapReduce-Datenfluss Abbildung 5: Zuweisung der Mapper nach dem Lokalitätsprinzip Abbildung 6: einfache SPARQL-Anfrage (A1) Abbildung 7: Graph Pattern Matching Abbildung 8: SPARQL-Anfrage mit Optional (A3) Abbildung 9: SPARQL-Anfrage mit Filter (A2) Abbildung 10: SPARQL-Anfrage mit Union (A4) Abbildung 11: Aufbau einer SPARQL-Anfrage Abbildung 12: SPARQL-Anfrage mit Optional und Filter (A5) Abbildung 13: SPARQL Algebra-Baum Abbildung 14: Index-Erstellung mittels UDFs Abbildung 15: MapReduce-Plan für PigLatin-Programm Abbildung 16: Reducer-Parallelität bei Pig Latin Abbildung 17: Konzeption der Übersetzung Abbildung 18: Konzeption der Auswertung Abbildung 19: RDF-Graph mit drei Prädikaten Abbildung 20: Übersetzung eines BGPs Abbildung 21: Übersetzung von Filter Abbildung 22: Übersetzung von Join Abbildung 23: Übersetzung von LeftJoin ohne Filter Abbildung 24: Übersetzung von LeftJoin mit sicherem Filter Abbildung 25: Übersetzung von LeftJoin mit unsicherem Filter Abbildung 26: Übersetzung von Union Abbildung 27: Übersetzung von OrderBy Abbildung 28: Übersetzung von Project Abbildung 29: Übersetzung von Distinct Abbildung 30: Übersetzung von Reduced Abbildung 31: Übersetzung von Slice Abbildung 32: komplexe SPARQL-Anfrage (A6)... 64

7 Abbildungsverzeichnis 7 Abbildung 33: SPARQL Algebra-Baum zu A Abbildung 34: Pig Latin-Übersetzung einer SPARQL-Anfrage Abbildung 35: IO-Datenfluss in Hadoop Abbildung 36: Variablen-Substitution beim Filter Abbildung 37: Verschieben des Filter-Operators Abbildung 38: Triple-Pattern-Anordnung nach Selektivität Abbildung 39: BGP-Optimierung Abbildung 40: optimierte Übersetzung eines BGPs Abbildung 41: Vertikale Partitionierung eines RDF-Graphen Abbildung 42: Übersetzung eines BGPs bei vertikaler Partitionierung Abbildung 43: Schema der Übersetzung Abbildung 44: SPARQL Algebra in ARQ Abbildung 45: Visitor Pattern Abbildung 46: optimierter Algebra-Baum in ARQ Abbildung 47: PigOp-Hierarchie Abbildung 48: PigOp-Baum vor der Übersetzung Abbildung 49: Übersetzung des PigOp-Baums Abbildung 50: Schema der Auswertung Abbildung 51: DBLP Beispiel-Instanz [Schmidt, et al., 2009] Abbildung 52: SP 2 Bench-Anfrage (Q10) Abbildung 53: Auswertung von Q Abbildung 54: SP 2 Bench-Anfrage (Q11) Abbildung 55: Auswertung von Q Abbildung 56: SP 2 Bench-Anfrage (Q3) Abbildung 57: Auswertung von Q3a Abbildung 58: SP 2 Bench-Anfrage (Q2) Abbildung 59: Auswertung von Q Abbildung 60: SP 2 Bench-Anfrage (Q5) Abbildung 61: Auswertung von Q Abbildung 62: modifizierte SP 2 Bench-Anfrage (Q6) Abbildung 63: Auswertung von Q6 (modifiziert)

8 Tabellenverzeichnis 8 Tabellenverzeichnis Tabelle 1: Ergebnis von A Tabelle 2: Ergebnis von A Tabelle 3: SPARQL Algebra Operatoren und Solution Modifier Tabelle 4: Relation vor (a) und nach (b) Ausführung von Foreach Tabelle 5: Relation vor (a) und nach (b) Ausführung von Filter Tabelle 6: Ergebnis des Group-Operators Tabelle 7: Ergebnis des Join- (a) und Outer Join-Operators (b) Tabelle 8: Relation vor (a) und nach (b) Ausführung von Order By Tabelle 9: RDF-Terme und ihre Repräsentation im Datenmodell von Pig Tabelle 10: Auswertung eines BGPs Tabelle 11: Auswertung von Filter Tabelle 12: Filter-Anpassungen bei der Übersetzung Tabelle 13: Auswertung von Join Tabelle 14: Auswertung von LeftJoin Tabelle 15: Auswertung von Union Tabelle 16: Auswertung von OrderBy Tabelle 17: Auswertung von Project Tabelle 18: Auswertung von Distinct Tabelle 19: Ergebnis von A Tabelle 20: Auswertung von Q Tabelle 21: Auswertung von Q Tabelle 22: Auswertung von Q3a Tabelle 23: Auswertung von Q Tabelle 24: Auswertung von Q Tabelle 25: Auswertung von Q6 (modifiziert)

9 1 Einleitung 9 1 Einleitung Die Menge der verfügbaren Daten im Internet und damit auch das potentiell zur Verfügung stehende Wissen nimmt schnell zu [Cisco, 2010]. Leider können große Teile dieses Wissens von einem Computer nicht automatisiert erfasst und verarbeitet werden, da sich die Aufbereitung und Darstellung an einem menschlichen Betrachter orientiert, wie z.b. ein Artikel auf der Wikipedia- Webseite. Das Ziel des Semantic Web [Berners-Lee, et al., 2001] ist die Erschließung dieses Wissens, indem Informationen in einem für Maschinen zugänglichen Format bereitgestellt werden. Zu diesem Zweck wurde das Resource Description Framework (RDF) [Klyne, et al., 2004] entwickelt, ein Standard zur Modellierung von Metainformationen über Daten. Mit der Einführung von RDF musste allerdings auch eine Möglichkeit entwickelt werden, Anfragen auf RDF-Daten zu spezifizieren. Über die Jahre entwickelte sich SPARQL [Prud'hommeaux, et al., 2008] zur Standard-Anfragesprache für RDF. Mit der Zunahme der Daten im Internet stellt sich auch vermehrt die Frage, wie diese Daten ausgewertet werden sollen. Firmen wie Yahoo! oder Google generieren Daten im Tera- und Petabyte-Bereich, was die Entwicklung neuer Konzepte zur Datenverarbeitung und Datenanalyse erforderlich macht. Google entwickelte hierfür das sehr erfolgreiche MapReduce-Programmiermodell [Dean, et al., 2004], dessen Konzepte im Jahr 2004 der Öffentlichkeit vorgestellt wurden und schnell auf großes Interesse stießen. Es erlaubt dem Anwender, Berechnungen auf sehr großen Datensätzen verteilt auf einem Computer-Cluster durchzuführen, ohne sich um die Details und die damit verbundenen Probleme eines verteilten Systems Gedanken machen zu müssen. Die wohl bekannteste und erfolgreichste öffentlich zugängliche Implementierung des MapReduce-Modells ist das Apache Hadoop Framework 1, das maßgeblich von Yahoo! weiterentwickelt und auch in großem Stil zur Datenanalyse verwendet wird. Da die Entwicklung auf MapReduce-Ebene trotz aller Vorzüge dennoch recht technisch und anspruchsvoll ist, entwickelten Mitarbeiter von Yahoo! eine Sprache zur Analyse von großen Datensätzen, Pig Latin [Olston, et al., 2008], die auch weniger erfahrenen Anwendern den Umgang mit Hadoop ermöglichen sollte. Der Ansatz war so erfolgreich, dass die Implementierung 1 siehe [http://hadoop.apache.org]

10 1 Einleitung 10 von Pig Latin für Hadoop, Pig 2, mittlerweile ein offizielles Subprojekt von Hadoop ist. Die zunehmende Größe von verfügbaren RDF-Datensätzen 3 erfordert auch neue Konzepte zur Auswertung solcher Datensätze, da klassische, auf einem Computer arbeitende Systeme aufgrund der begrenzten Ressourcen oftmals überfordert sind. Die grundlegende Idee dieser Arbeit ist es daher, die Mächtigkeit von Hadoop zur Auswertung von SPARQL-Anfragen auf großen RDF- Datensätzen zu nutzen. Hierfür wurde eine Übersetzung von SPARQL nach Pig Latin entwickelt und implementiert, welche eine SPARQL-Anfrage in ein äquivalentes Pig Latin-Programm überführt. Dieser Ansatz hat den Vorteil, dass keine Anpassungen an einem bestehenden Hadoop-Cluster vorgenommen werden müssen, was eine einfache und zugleich effiziente Auswertung von SPARQL-Anfragen mit Hadoop ermöglicht. 1.1 Aufbau der Arbeit Der Aufbau der Arbeit wird in Abbildung 1 grafisch dargestellt. Zunächst werden in Kapitel 2 einige grundlegende Konzepte und Technologien dargestellt, auf denen diese Arbeit aufbaut. Anschließend erfolgt eine kurze Einführung in die Grundprinzipien und Möglichkeiten von SPARQL und Pig Latin in den Kapiteln 3 und 4. Daraufhin werden in Kapitel 5 die Übersetzung von SPARQL nach Pig Latin, PigSPARQL, sowie eine Abbildung des RDF- Datenmodells in das Datenmodell von Pig dargestellt. In Kapitel 6 folgen einige Vorschläge für Optimierungen auf verschiedenen Ebenen. Kapitel 7 zeigt die grundlegenden Konzepte, die bei der Implementierung von PigSPARQL verwendet wurden. Die Evaluation der Arbeit in Kapitel 8 untersucht die relevanten Eigenschaften der Übersetzung und analysiert die Auswirkungen der vorgeschlagenen Optimierungen. Abschließend werden in Kapitel 9 einige verwandte Arbeiten vorgestellt und die Ergebnisse der Arbeit in Kapitel 10 zusammengefasst. 2 siehe [http://hadoop.apache.org/pig/] 3 siehe [http://esw.w3.org/taskforces/communityprojects/linkingopendata/datasets]

11 1 Einleitung Grundlagen RDF MapReduce Hadoop 3. SPARQL Einführung Aufbau Algebra 4. Pig Latin Datenmodell Operatoren UDFs Hadoop Pig 5. Übersetzung von SPARQL nach Pig Latin RDF-Daten SPARQL Algebra Beispiele 6. Optimierungen SPARQL Algebra Übersetzung Datenmodell 7. Implementierung Algebra- Baum Visitor Pattern PigOp- Baum Pig UDFs 8. Evaluation Hadoop-Cluster SP 2 Bench Ergebnisse 9. Verwandte Arbeiten 10. Zusammenfassung Abbildung 1: Aufbau der Arbeit

12 2 Grundlagen 12 2 Grundlagen In diesem Kapitel wird auf die notwendigen Grundlagen und Technologien eingegangen, auf denen diese Arbeit beruht. Die Darstellung erhebt dabei keinen Anspruch auf Vollständigkeit, erfolgt jedoch in dem für das Verständnis der Arbeit erforderlichen Umfang. Für den interessierten Leser sind zu jedem Bereich weiterführende Quellen zur Vertiefung angegeben. Zunächst erfolgt in Abschnitt 2.1 eine kurze Einführung in RDF, das dazu entwickelt wurde, um Daten mit zusätzlichen Informationen in einem von Maschinen lesbaren Format zu versehen. SPARQL, die offizielle Anfragesprache für RDF, wird in Kapitel 3 gesondert betrachtet. Für das technische Verständnis der Übersetzung von SPARQL nach Pig Latin ist es zudem erforderlich, das zur Auswertung von Pig Latin-Programmen verwendete System sowie dessen Konzepte in seinen Grundzügen darzustellen. Aus diesem Grund werden das MapReduce-Modell in Abschnitt 2.2 und seine Implementierung, Hadoop, in Abschnitt 2.3 in groben Zügen erläutert. Die Einführung in Pig Latin erfolgt gesondert in Kapitel RDF Das Resource Description Framework (RDF) ist ein vom World Wide Web Consortiums (W3C) 4 entwickelter Standard zur Modellierung von Metainformationen bzw. Wissen über beliebige Ressourcen (dazu gehört alles, was eine Identität besitzt, wie z.b. Personen, Gegenstände oder Dokumente) und bildet die Grundlage für die Semantic Web-Aktivitäten des W3C. Das Ziel des Semantic Web ist die Verknüpfung von Daten mit zusätzlichen Informationen in einem für Maschinen zugänglichen Format. Automatisierte Agenten können diese Informationen nutzen, um den Benutzer mit intelligenten Entscheidungen zu unterstützen oder um weitere Informationen abzuleiten, die implizit in den vorhandenen Informationen enthalten sind. Im Internet ist eine große Menge an potentiellem Wissen vorhanden, dessen Bedeutung jedoch von einem Computer nicht erfasst werden kann. So enthält beispielweise eine Wikipedia-Seite viele Informationen, die jedoch größtenteils dem menschlichen Betrachter vorbehalten bleiben. RDF kann als abstraktes 4 Das W3C entwickelt Standards für Techniken im Internet [http://www.w3.org]

13 2 Grundlagen 13 Modell betrachtet werden, mit dessen Hilfe dieses Wissen in kleine Teile zerlegt und von Maschinen interpretiert werden kann [Tauberer, 2008]. Im Folgenden werden die Komponenten von RDF kurz vorgestellt. RDF-Tripel. Grundlage der Wissensrepräsentation in RDF sind Ausdrücke der Form <Subjekt,Prädikat,Objekt>. Das Subjekt wird dabei über das Prädikat mit dem Objekt in Beziehung gesetzt. Prädikate werden daher auch als Eigenschaften bezeichnet. Ein RDF-Tripel lässt sich folgendermaßen interpretieren: <Subjekt> hat die Eigenschaft <Prädikat> mit dem Wert <Objekt>. Das Subjekt in einem RDF-Tripel kann entweder eine URI (U) oder ein Blank Node (B) sein, das Prädikat muss eine URI sein und das Objekt kann entweder eine URI, ein Blank Node oder ein RDF-Literal (L) sein. Daraus ergibt sich für ein gültiges RDF-Tripel folgendes Format: (U B) U (U B L). URIs. Ressourcen werden in RDF über weltweit eindeutige Bezeichner (Uniform Resource Identifier) referenziert, die eine verwechslungsfreie Zuordnung der entsprechenden Metainformationen gewährleisten sollen. Technisch gesehen ist eine URI eine spezifische ASCII-Zeichenkette 5, die einem bestimmten Muster folgt. Ein gutes Beispiel sind die aus dem Internet bekannten URLs (Uniform Resource Locator, z.b. welche eine Teilmenge der URIs darstellen. Das Konzept der URI geht jedoch darüber hinaus und erlaubt auch die Referenzierung beliebiger Ressourcen, die keine URL besitzen. Blank Nodes. Blank Nodes in RDF beziehen sich ebenfalls auf Ressourcen, weisen der Ressource aber keinen global eindeutigen Bezeichner (URI) zu. Sie sind nur innerhalb eines RDF-Dokuments eindeutig und werden meist für Container und Sequenzen oder zum Gruppieren von Informationen verwendet. Da Blank Nodes, Container und Sequenzen in dieser Arbeit keine wesentliche Rolle spielen, sei der interessierte Leser für eine genauere Darstellung auf die Dokumentation von RDF in [Manola, et al., 2004] verwiesen. RDF-Literale. Im Gegensatz zu URIs sind Literale in RDF atomare Werte (Strings), die keine Ressource identifizieren. Sie können beispielsweise dazu verwendet werden, um Eigenschaften von Ressourcen zu beschreiben und enthalten im Regelfall die zu modellierenden Informationen. Man unterscheidet in RDF zwischen einfachen (z.b. "Alice") und getypten Literalen. Getypte Literale können entweder die Angabe der verwendeten Sprache (z.b. 5 siehe [http://tools.ietf.org/html/rfc3986]

14 2 Grundlagen 14 oder eines Datentyps beinhalten. Datentypen sind in RDF nicht fest vorgegeben sondern werden über URIs referenziert. Dabei können bereits definierte und wohlbekannte Datentypen, wie z.b. die Datentypen aus XML Schema (z.b. "24"^^xsd:int), aber auch komplett neu definierte Datentypen (z.b. "x3c"^^<http://example.org/mynewdatatype>) verwendet werden. RDF-Graph. Ein RDF-Dokument besteht im Wesentlichen aus einer Abfolge von RDF-Tripeln in einem speziellen Serialisierungsformat (z.b. RDF/XML 6 oder N3 7 ). Die Ausdrücke in einem RDF-Dokument lassen sich dabei als gerichteter, azyklischer Graph interpretieren. Jedes Tripel entspricht dabei einer beschrifteten Kante (Prädikat) von einem Knoten im Graph (Subjekt) zu einem anderen Knoten (Objekt). Knoten, die sich auf eine Ressource beziehen (URIs, Blank Nodes), werden als Kreise dargestellt. Literale werden hingegen als Rechtecke dargestellt, da von einem Literal keine Kante (Prädikat) ausgehen kann. Das einfache RDF-Dokument im N3-Format aus Abbildung 2 und seine grafische Visualisierung in Abbildung 3 sollen dieses Konzept ex: foaf: <http://xmlns.com/foaf/0.1/>. ex:peter foaf:knows ex:john. ex:john foaf:knows ex:bob. ex:john foaf:knows ex:sarah. ex:bob foaf:knows ex:peter. ex:bob foaf:age "32". ex:sarah foaf:knows ex:peter. ex:sarah foaf:age "17". Abbildung 2: einfaches RDF-Dokument ex:peter ex:john foaf:knows foaf:age ex:sarah 17 ex:bob 32 Abbildung 3: einfacher RDF-Graph 6 siehe [http://www.w3.org/tr/2004/rec-rdf-syntax-grammar /] 7 siehe [http://www.w3.org/designissues/notation3.html]

15 2 Grundlagen 15 Im Sinne einer kompakteren und übersichtlicheren Darstellung werden die URIs mit Hilfe von Präfixen abgekürzt. Zu Beginn des Dokuments werden die beiden Präfixe ex: und foaf: mit ihren entsprechenden URIs definiert. In den RDF-Tripeln können die Präfixe dann als Abkürzung für ihre entsprechenden URIs verwendet werden. Der Ausdruck ex:peter entspricht daher der URI <http://example.org/peter>. Der Hauptteil des Dokuments besteht aus einer einfachen Folge von RDF-Tripeln. Das N3-Format sieht zwar auch Abkürzungsmöglichkeiten vor, diese werden hier allerdings nicht betrachtet. Das Dokument definiert eine einfache Beziehungsstruktur mit Hilfe der beiden Prädikate foaf:knows und foaf:age. So codiert es u.a. die Information "John kennt Bob" (ex:john foaf:knows ex:bob) sowie "Bob hat ein Alter von 32" (ex:bob foaf:age "32"). Eine umfassende Darstellung von RDF und dessen Konzepten ist im Rahmen dieser Arbeit nicht möglich. Die hier dargestellten grundlegenden Eigenschaften von RDF sollten für das Verständnis der Arbeit allerdings ausreichend sein. Der interessierte Leser sei insbesondere auf die offiziellen Dokumente des W3C zur Spezifikation von RDF [Manola, et al., 2004] sowie das Buch "Practical RDF" von Shelley Powers [Powers, 2003] verwiesen. 2.2 MapReduce MapReduce ist ein von Google Inc. im Jahr 2004 vorgestelltes Programmiermodell für nebenläufige Berechnungen auf sehr großen Datenmengen unter Einsatz eines Computer-Clusters 8. Inspiriert wurde das Konzept durch die in der funktionalen Programmierung häufig verwendeten Funktionen map und reduce. Die folgende kurze Darstellung des MapReduce-Paradigmas basiert im Wesentlichen auf der Veröffentlichung von Google aus dem Jahr 2004 [Dean, et al., 2004]. Ausgangspunkt für die Entwicklung des MapReduce-Paradigmas war die Tatsache, dass viele Berechnungen bei Google zwar konzeptuell relativ einfach sind, jedoch zumeist auf sehr großen Datensätzen ausgeführt werden müssen. Eine parallelisierte Ausführung ist daher unerlässlich, weshalb selbst einfache Berechnungen eine komplexe Implementierung erforderten, um mit den speziellen Eigenschaften einer parallelisierten Ausführung umgehen zu können. Andererseits erwiesen sich klassische Datenbanksysteme als eher ungeeignet zur Lösung dieses Problems, da diese im Regelfall einen aufwändigen Import der Da- 8 Ein Computer-Cluster besteht aus einem Netzwerk von eigenständigen Computern.

16 2 Grundlagen 16 ten erfordern und ab einem gewissen Grad nicht linear mit den zur Verfügung stehenden Ressourcen skalieren [Abouzeid, et al., 2009]. Da das Datenaufkommen bei Google jedoch stetig zunimmt, muss das System eine gute Skalierbarkeit aufweisen, um den wachsenden Anforderungen auf Dauer gerecht zu werden. Der Aufbau eines Index über den Daten ist darüber hinaus auch nicht besonders hilfreich, da die Analyse im Regelfall die Verarbeitung des gesamten Datensatzes (Stapelverarbeitung) erfordert, was einen selektiven Zugriff auf einzelne Einträge im Datensatz überflüssig macht. Darüber hinaus werden im Regelfall auch keine Änderungen an den Daten vorgenommen 9, sondern nur lesend darauf zugegriffen. Das Ziel war es daher, ein Framework zu entwickeln, welches dem Entwickler die Details und Probleme der Parallelisierung abnimmt und in der Lage ist, nahezu linear mit den zur Verfügung stehenden Ressourcen zu skalieren. Dabei sollte das Framework keine spezielle und damit teure Hardware erfordern, sondern vielmehr mit gewöhnlicher Standard-Hardware funktionieren. Da bei großen Computer-Netzwerken (Cluster) immer mit Fehlern und Ausfällen gerechnet werden muss, insbesondere beim Einsatz von gewöhnlicher Standard- Hardware, mussten die Entwickler ein besonderes Augenmerk auf die Fehlertoleranz des Systems legen. Google's Lösung für dieses Problem war die Entwicklung eines verteilten Dateisystems, Google File System (GFS), dessen Konzepte bereits 2003 vorgestellt wurden und die Grundlage für die Entwicklung des MapReduce- Frameworks bildeten [Ghemawat, et al., 2003]. Dateien werden beim GFS in Blöcke aufgeteilt und verteilt im Cluster abgelegt. Ausfallsicherheit wird dabei über Replikation gewährleistet, indem jeder Block mehrfach auf unterschiedlichen Computern abgespeichert wird. Aufbauend auf GFS entwickelten die Google-Mitarbeiter ein skalierendes, verteiltes System, das unter dem Namen MapReduce bekannt geworden ist und die Implementierung von datenintensiven Anwendungen erleichtert. Dabei handelt es sich um ein fest vorgegebenes Programmiermodell, das dem Entwickler einen festen Rahmen vorgibt und ihm die Entwicklung von verteilten Anwendungen ohne intensive Kenntnisse der damit verbundenen Schwierigkeiten ermöglicht. Im Wesentlichen muss der Entwickler hierfür lediglich zwei Funktionen, Map und Reduce (daher auch der Name), implementieren. 9 Bei den Datensätzen handelt es sich in der Regel um große Log-Dateien oder Ausgaben eines Web Crawlers (z.b. zum Aufbau des Web-Suchindexes von Google).

17 2 Grundlagen 17 input1 Mapper Reducer output1 input2 Mapper Reducer output2 input3 Mapper Abbildung 4: MapReduce-Datenfluss Shuffle & Sort Abbildung 4 zeigt den schematischen Ablauf eines MapReduce-Jobs mit drei Mappern und zwei Reducern. In der Map-Phase führt jeder Mapper zunächst die vom Entwickler angegebene Map-Funktion auf einem Teil der Eingabedaten aus. Die Ausgaben der Mapper werden in der anschließenden Shuffle- Phase sortiert und auf die Reducer verteilt. Das Sortieren der Daten erfolgt nach dem Merge-Sort-Prinzip. Dabei werden die Daten der Mapper vor dem Verteilen vorsortiert und beim Reducer zu einer komplett sortierten Folge zusammengesetzt. In der abschließenden Reduce-Phase wenden die Reducer dann die Reduce-Funktion auf die sortierten Zwischenergebnisse an. Mapper und Reducer werden vom System idealerweise parallel ausgeführt, wobei die Reduce-Phase erst beginnen darf, wenn die Map-Phase komplett abgeschlossen wurde, da ansonsten nicht gewährleistet werden kann, dass die Eingabe für einen Reducer vollständig ist. Technisch gesehen berechnet ein MapReduce-Job aus einer Liste von Schlüssel-Wert-Paaren (Eingabe) eine neue Liste von Schlüssel-Wert-Paaren (Ausgabe): [(, ),,(, )] [(, ),,(, )] (1) Beispiel. Angenommen es soll für eine Menge an Dokumenten berechnet werden, welche Wörter mit welcher Häufigkeit darin vorkommen. Eine Vorverarbeitung habe bereits eine Liste an Paaren (docid, word) ergeben, wobei docid eine Referenz auf ein Dokument und word ein Wort aus dem entsprechenden Dokument seien. Diese Vorverarbeitung lässt sich beispielsweise auch mit Hilfe eines MapReduce-Jobs berechnen. Ein mögliches Ergebnis der Auswertung könnte dann so aussehen: [( 1, ), ( 1, ), ( 2, ), ( 2, h)] [(, 2), (, 1), ( h, 1)]

18 2 Grundlagen 18 Im Folgenden werden die einzelnen Phasen eines MapReduce-Jobs genauer betrachtet und anhand der schrittweisen Berechnung des angegebenen Beispiels illustriert Map-Phase In der Map-Phase wird die Map-Funktion auf die Eingabedaten angewendet, indem jedem Mapper ein kleiner Teil der Eingabedaten zugewiesen wird. Da es keine Abhängigkeiten zwischen verschiedenen Mappern gibt, können diese parallel und unabhängig voneinander ausgeführt werden. Sollte ein Computer im Cluster ausfallen, so können die von ihm berechneten Map-Ergebnisse einfach zurückgesetzt und auf einem anderen Computer neu berechnet werden. Die Map-Funktion berechnet für jedes Eingabe-Paar beliebig viele Zwischenergebnis-Paare (2). Natürlich kann ein Eingabe-Paar auch verworfen werden, z.b. wenn es einen ungültigen Wert enthält. Der Mapper wendet die Map-Funktion iterativ auf jedes Schlüssel-Wert-Paar aus seiner Eingabe an und generiert daraus eine Liste von neuen Schlüssel-Wert-Paaren: (, ) [(, ),,(, )] (2) Beispiel. Jedes Vorkommen eines Wortes bekommt den Zählwert 1. Der ursprüngliche Wert des Eingabe-Paars wird zum neuen Schlüssel des Ausgabe- Paars: ( 1, ) [(, 1)] ( 1, ) [(, 1)] ( 2, ) [(, 1)] ( 2, Sarah) [(Sarah, 1)] Shuffle-Phase In der Shuffle-Phase werden die Zwischenergebnis-Paare aus der Map-Phase zunächst lokal nach ihren Schlüsseln sortiert und dann in Abhängigkeit ihres Schlüssels auf die Reducer verteilt. Dabei werden alle Paare mit dem gleichen Schlüssel auch dem gleichen Reducer zugeordnet. Nachdem die vorsortierten Zwischenergebnis-Paare zu den Reducern übertragen wurden, werden sie dort zu einer komplett sortierten Liste zusammengefügt (Merge-Sort). Wie viele Schlüssel einem Reducer zugeordnet werden hängt davon ab, wie viele verschiedene Schlüssel es in der Zwischenergebnis-Menge gibt. Werden einem Reducer mehrere Schlüssel zugewiesen, so wendet er die Reduce-Funktion iterativ für jeden Schlüssel an. Die Shuffle-Phase kann bereits vor dem Ende der Map- Phase beginnen. Sobald ein Mapper fertig ist, können dessen Daten sortiert und auf die Reducer verteilt werden.

19 2 Grundlagen Reduce-Phase In der Reduce-Phase wird die Reduce-Funktion auf die von den Mappern erzeugten Zwischenergebnisse angewendet. Einem Reducer werden dazu alle Zwischenergebnis-Werte mit dem gleichen Schlüssel zugeordnet. Diese Zwischenergebnisse müssen über das Netzwerk zum entsprechenden Reducer geschickt werden. Der Reducer wendet dann die Reduce-Funktion auf die Liste der Zwischenergebnisse an (3). Im Regelfall wird die Liste der Zwischenergebnisse zu einer kürzeren Ausgabe-Liste verdichtet (Aggregation), nicht selten liefert die Reduce-Funktion aber auch nur einen einzelnen Wert als Ausgabe (z.b. Summe oder Anzahl der Zwischenergebnisse). (, [,, ]) (k, ),, k, (3) Beispiel. Die Reduce-Funktion bekommt alle Map-Ausgaben mit dem gleichen Wort (Schlüssel) als Eingabe und summiert die Vorkommen auf: (, [1,1]) [(, 2)] (, [1]) [(, 1)] ( h, [1]) [( h, 1)] Im Gegensatz zu der Anzahl an Mappern hängt die Anzahl der Reducer nicht von der Größe der ursprünglichen Eingabe ab. Sie liegt vielmehr im Ermessen des Entwicklers und sollte an die spezifischen Anforderungen der Aufgabe angepasst werden. 2.3 Hadoop Das Apache Hadoop Framework 10 ist eine Open-Source-Implementierung des MapReduce-Paradigmas von Google, welches in Abschnitt 2.2 erläutert wurde. Ursprünglich von Doug Cutting im Jahr 2004 entwickelt, wird das System seit 2006 und dem Wechsel von Cutting zu Yahoo! vor allem von Mitarbeitern bei Yahoo! weiterentwickelt. Ebenfalls seit 2006 ist Hadoop ein Projekt der Apache Software Foundation und wird mittlerweile von vielen Firmen (u.a. Facebook, Yahoo!, IBM) zur Bearbeitung und Analyse von großen Datensätzen eingesetzt. Im Jahr 2008 gewann Hadoop als erstes Open-Source-Projekt den TeraByte Sort Benchmark 11. Eine umfassende Darstellung des Hadoop Frameworks ist im Rahmen dieser Arbeit nicht möglich. Im Folgenden werden lediglich die grundlegenden Kenntnisse vermittelt, die für das Verständnis der Arbeit erforderlich sind. 10 siehe [http://hadoop.apache.org] 11 siehe [http://sortbenchmark.org/yahoohadoop.pdf]

20 2 Grundlagen 20 Dem interessierten Leser sei vor allem das Buch von Tom White "Hadoop - The Definitive Guide" [White, 2009] empfohlen HDFS Das Hadoop Distributed Filesystem (HDFS) wurde nach dem Vorbild des Google File System (GFS) [Ghemawat, et al., 2003] entworfen und bildet die Grundlage für die MapReduce-Implementierung in Hadoop. Wie beim GFS werden beim HDFS die Dateien in Blöcke 12 aufgeteilt und verteilt im Cluster abgespeichert, wobei auch hier die Blöcke zur Gewährleistung der Ausfallsicherheit repliziert werden. Standardmäßig wird ein Block auf drei verschiedenen Rechnern im Cluster gespeichert. Das hat natürlich zur Folge, dass eine Datei beim Speichern in HDFS letztlich auch ein Mehrfaches des ursprünglichen Speicherplatzes belegt und auch ein Mehrfaches der Daten über das Netzwerk gesendet werden muss. Die Replikation bringt jedoch neben der Ausfallsicherheit noch den entscheidenden Vorteil, dass das Lokalitätsprinzip (siehe Abschnitt 2.3.2) besser ausgenutzt werden kann. Entwickelt und optimiert wurde HDFS insbesondere zur effizienten Unterstützung von write-once, readmany Zugriffsmustern bei großen Dateien. Dazu wurde vor allem viel Wert auf einen hohen Datendurchsatz gelegt, was sich allerdings negativ auf die Latenz- Zeiten auswirkt. Konsequenterweise werden auch Update-Operationen auf Dateien nicht unterstützt. In Zukunft könnten diese Operationen zwar zur Verfügung stehen, doch dürften sie erwartungsgemäß relativ ineffizient sein Lokalitätsprinzip Entwickelt wurde Hadoop nach dem Vorbild von Googles MapReduce-System zur parallelen Verarbeitung von sehr großen Datenmengen. Den Google- Mitarbeitern wurde bei der Entwicklung ihres Systems allerdings schnell bewusst, dass insbesondere die Bandbreite des Netzwerkes, mit dem die Rechner im Cluster verbunden sind, eine knappe Ressource darstellt. Um das Netzwerk zu entlasten, wird daher die Tatsache ausgenutzt, dass die Daten durch das Dateisystem bereits verteilt auf den Rechnern im Cluster vorhanden sind. Das System versucht die Mapper so auf die Rechner zu verteilen, dass möglichst viele Daten lokal gelesen werden können und nicht über das Netzwerk übertragen werden müssen (siehe Abbildung 5). Dieses Vorgehen wird auch als Lokalitätsprinzip bezeichnet. 12 Die Standard-Blockgröße beträgt 64 MB, lässt sich jedoch anpassen.

21 2 Grundlagen 21 Umgangssprachlich kann man also sagen, dass nicht die Daten zur Berechnung, sondern die Berechnung zu den Daten kommt. Hier wirkt sich insbesondere die Replikation der Daten durch das Dateisystem vorteilhaft aus, da dadurch die Chance einer lokalen Verfügbarkeit der Daten zunimmt. Das Prinzip wurde von Hadoop übernommen und in der Praxis zeigt sich, dass dadurch die Effizienz des Systems deutlich gesteigert wird, da ein Großteil der Mapper die Daten lokal lesen kann. Block 1 Block 3 Mapper Block 2 Block 3 Mapper Block 4 Block 4 Computer 1 Computer 2 Abbildung 5: Zuweisung der Mapper nach dem Lokalitätsprinzip

22 3 SPARQL 22 3 SPARQL Wie in Kapitel 2 beschrieben, lassen sich mit Hilfe von RDF Metainformationen über Ressourcen definieren und in einem für Computer verständlichen Format darstellen. Zeitgleich mit der Einführung von RDF im Jahr 1998 kam die Frage auf, wie sich Anfragen auf RDF-Daten gestalten lassen. Im Laufe der Jahre wurden hierfür einige Vorschläge entwickelt und implementiert veröffentlichte die RDF Data Access Working Group einen ersten Entwurf einer Anfragesprache für RDF mit dem Namen SPARQL 13. Seit 2008 ist SPARQL die vom W3C empfohlene Anfragesprache für RDF. Die folgende Darstellung beruht auf der offiziellen Dokumentation von SPARQL aus [Prud'hommeaux, et al., 2008] sowie der Semantik von SPARQL, wie sie in [Pérez, et al., 2006] definiert wird. Zunächst wird Abschnitt 3.1 anhand einiger einfacher Beispiele gezeigt, wie mit Hilfe von SPARQL Informationen aus einem RDF-Graph abgefragt werden können und welche grundlegenden Möglichkeiten SPARQL hierfür bietet. In Abschnitt 3.2 wird dann der prinzipielle Aufbau und in Abschnitt 3.3 die Auswertung einer SPARQL-Anfrage näher betrachtet. 3.1 Einführung Eine SPARQL-Anfrage definiert im Wesentlichen ein Graph Pattern (Muster), das mit dem RDF-Graph G, auf dem die Anfrage operiert, verglichen wird. Dazu wird überprüft, ob die Variablen im Graph Pattern durch Knoten (URIs, Blank Nodes, RDF-Literale) aus G ersetzt werden können, sodass der resultierende Graph in G enthalten ist (Pattern Matching). Man nennt eine solche PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT * WHERE {?person A foaf:knows?personb.?personb foaf:age?age } Abbildung 6: einfache SPARQL-Anfrage (A1) 13 SPARQL ist ein rekursives Akronym und steht für SPARQL Protocol and RDF Query Language.

23 3 SPARQL 23 Abbildung von den Anfrage-Variablen auf RDF-Terme aus G ein Solution Mapping. Im Folgenden wird hierfür auch umgangssprachlich der Begriff Ergebnis verwendet. Abbildung 6 zeigt eine einfache SPARQL-Anfrage (A1). Das Ergebnis der Anfrage sind alle Abbildungen von den Variablen auf Knoten des RDF-Graph, so dass die beiden resultierenden RDF-Tripel im Graph enthalten sind. Die Anfrage liefert somit für eine Person A alle Personen, die A kennt und deren Alter bekannt sind. Sollte A allerdings eine Person B kennen, von der das Alter nicht bekannt ist, so wird diese Kombination nicht zur Ergebnismenge hinzugenommen. Abbildung 7 und Tabelle 1 zeigen die Auswertung (Matching) des Graph Patterns aus A1 auf dem dargestellten RDF-Graph (Präfixe werden zur besseren Übersichtlichkeit weggelassen).?persona Peter John knows age?personb Sarah Bob?age Graph Pattern "17" "32" RDF-Graph Abbildung 7: Graph Pattern Matching?personA?personB?age John Sarah 17 John Bob 32 Tabelle 1: Ergebnis von A1 Filter. SPARQL erlaubt den Einsatz von Filtern, um die Werte von Variablen zu beschränken. Angenommen die Anfrage A1 soll so modifiziert werden, dass Person B volljährig sein muss. Dies lässt sich durch eine Beschränkung der Variable?age festlegen. Abbildung 9 zeigt die entsprechend modifizierte Anfrage A2. Das Ergebnis der Auswertung von A2 enthält damit im Gegensatz zur Auswertung von A1 nur noch ein einziges Ergebnis, da "Sarah" noch nicht völljährig ist.

24 3 SPARQL 24 PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT * WHERE {?person A foaf:knows?personb.?personb foaf:age?age FILTER (?age >= 18) } Abbildung 9: SPARQL-Anfrage mit Filter (A2) Optional. Eigenschaften von Ressourcen werden in RDF über Prädikate definiert (Kanten im RDF-Graph). Eine wesentliche Eigenart von RDF-Daten ist allerdings, dass sie oftmals lückenhaft sind, d.h. für eine Ressource sind nicht unbedingt alle Eigenschaften bekannt. Eine Anfragesprache für RDF muss daher in der Lage sein, Informationen optional zum Ergebnis einer Anfrage hinzuzunehmen, wenn diese vorhanden sind. In SPARQL ist dies mit Hilfe von Optional möglich. Sollten die gewünschten Informationen nicht vorhanden sein, so bleiben die entsprechenden Variablen im Ergebnis ungebunden, d.h. es wird ihnen kein Wert zugeordnet. Angenommen die Anfrage A1 soll so modifiziert werden, dass das Alter von Person B optional zur Ergebnismenge hinzugefügt wird, sofern es bekannt ist. Abbildung 8 zeigt die entsprechend modifizierte Anfrage A3. Die Auswertung von A3 (Tabelle 2) liefert nun fünf Ergebnisse, wobei die Variable?age bei drei Ergebnissen ungebunden bleibt. PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT * WHERE {?person A foaf:knows?personb OPTIONAL {?personb foaf:age?age } } Abbildung 8: SPARQL-Anfrage mit Optional (A3)

25 3 SPARQL 25?personA?personB?age John Sarah 17 John Bob 32 Peter Bob Sarah John Peter Peter Tabelle 2: Ergebnis von A3 Union. Mit Hilfe von Union lassen sich zwei alternative Graph Pattern in einer Anfrage definieren. Ein Anfrage-Ergebnis muss dann eines der beiden Patterns erfüllen. Erfüllt ein Ergebnis beide Patterns, so kommt es auch zwei Mal in der Ergebnismenge der Anfrage vor. A4 (Abbildung 10) ermittelt alle Personen, die entweder "Peter" oder "Bob" kennen. PREFIX ex: <http://example.org/> PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT * WHERE {?person foaf:knows ex:peter UNION?person foaf:knows ex:bob } Abbildung 10: SPARQL-Anfrage mit Union (A4) 3.2 Allgemeiner Aufbau einer SPARQL-Anfrage Eine Anfrage in SPARQL setzt sich, wie in Abbildung 11 dargestellt, aus fünf größtenteils optionalen Teilen zusammen: (1) Prolog. (optional) Zu Beginn der Anfrage können Abkürzungen für URIs (Präfixe) definiert werden, so dass URIs im Hauptteil nicht immer voll ausgeschrieben werden müssen. Es gibt einige sehr oft verwendete Präfixe für sehr verbreitete Namensräume wie z.b. foaf 14 (friend of a friend) für <http://xmlns.com/foaf/0.1/>. 14 siehe [http://xmlns.com/foaf/spec/]

26 3 SPARQL 26 (2) Anfragetyp. (notwendig) SPARQL kennt vier Anfragetypen: Select, Ask, Construct und Describe. Der häufigste und wichtigste Typ sind allerdings die Select-Anfragen. Dabei werden die Anfrage- Ergebnisse (Solution Mappings) direkt zurückgegeben (oft in tabellarischer Form). Ask liefert als Ergebnis true, falls es mindestens ein Ergebnis für die Anfrage gibt und false andernfalls. Construct und Describe liefern als Rückgabe jeweils einen neuen RDF-Graph, der auf den Anfrage-Ergebnissen beruht. Da bei der Übersetzung von SPARQL nach Pig Latin nur Select-Anfragen betrachtet wurden, wird auf eine genauere Darstellung der anderen Anfragetypen verzichtet. (3) Datenquellen. (optional) Mit den Schlüsselwörtern From und From Named lassen sich die RDF-Datenquellen (Graphen) angeben, auf der die Anfrage ausgewertet werden soll. Die Angabe ist allerdings optional, da eine Anfrage in SPARQL nicht an einen bestimmten RDF-Graph gebunden sein muss. Im Regelfall wird dieser Teil nur verwendet, wenn mehrere RDF-Graphen in der Anfrage verwendet werden sollen. (4) Graph Pattern. (optional) Im Hauptteil der Anfrage wird das Pattern definiert, welches auf den RDF-Graph angewendet werden soll. Die offizielle Syntax sieht hierfür die Operatoren Filter, Optional, Union und Graph sowie ein Punkt-Symbol (.) zur Verkettung und { } zur Gruppierung vor. Obwohl eine SPARQL-Anfrage nicht notwendigerweise ein Graph Pattern enthalten muss, macht eine Anfrage ohne Graph Pattern im Regelfall wenig Sinn. Die Grundlage jeder Anfrage bilden die sogenannten Basic Graph Patterns (BGP). Ein BGP besteht aus einer endlichen Menge an Triple-Patterns, die mittels (.) verkettet werden. Ein Triple-Pattern ist ein Tupel der Form (U L V) (U V) (U L V), wobei U die Menge der URIs, L die Menge der RDF- Literale und V die Menge der Anfrage-Variablen (disjunkt von U und L) sei. Ein Graph Pattern lässt sich dann formal rekursiv definieren: Ein Basic Graph Pattern ist ein Graph Pattern. Sind P und P' Graph Pattern, dann sind auch (P And P'), (P Union P') und (P Optional P') Graph Pattern. Ist P ein Graph Pattern und, dann ist auch (X Graph P) ein Graph Pattern. Ist P ein Graph Pattern und R eine Filter-Bedingung, dann ist auch (P Filter R) ein Graph Pattern.

27 3 SPARQL 27 Eine Filter-Bedingung erlaubt es, die Werte von Variablen in einer Anfrage zu beschränken (z.b.?var<30 oder?var1=?var2). Für die exakte Syntax einer Filter-Bedingung sei an dieser Stelle auf die offizielle Dokumentation von SPARQL in [Prud'hommeaux, et al., 2008] verwiesen. (5) Solution Modifier. (optional) Die Auswertung eines Graph Patterns in SPARQL generiert eine ungeordnete Liste von Ergebnissen (Solution Mappings). Mit Hilfe der Solution Modifier lässt sich diese Liste modifizieren (z.b. Sortieren der Ergebnisse), bevor sie in der vom Anfragetyp vorgegebenen Form zurückgegeben wird. PREFIX/BASE... (1) SELECT/ASK/CONSTRUCT/DESCRIBE... (2) FROM/FROM NAMED... (3) WHERE { (4)... } ORDER BY/LIMIT/OFFSET... (5) Abbildung 11: Aufbau einer SPARQL-Anfrage 3.3 Auswertung einer SPARQL-Anfrage Die offizielle Dokumentation des W3C schlägt zur Auswertung einer SPARQL- Anfrage eine Abfolge von mehreren Schritten vor: (1) Zunächst wird die Anfrage geparst, auf syntaktische Fehler überprüft und die verwendeten Abkürzungen (z.b. Präfixe bei URIs) werden aufgelöst. Das Ergebnis des Prozesses ist ein abstrakter Syntax-Baum. (2) Der abstrakte Syntax-Baum wird anschließend in einen SPARQL Algebra-Baum überführt. Man spricht hier auch von einer SPARQL Abstract Query. Die offizielle Dokumentation des W3C gibt hierfür eine allgemeine Prozedur an, wie ein Syntax-Baum in einen Algebra-Baum überführt werden kann. (3) Abschließend wird der Algebra-Baum auf dem RDF-Datensatz ausgewertet und die Ergebnisse in der gewünschten Form zurückgegeben.

28 3 SPARQL SPARQL Algebra Die Semantik einer SPARQL-Anfrage ist auf der Ebene der SPARQL Algebra definiert. Tabelle 3 stellt die sechs Operatoren und Solution Modifier der SPARQL Algebra ihren Entsprechungen in der SPARQL Syntax gegenüber. Operatoren SPARQL Syntax Solution Modifier SPARQL Syntax BGP Menge von Triple-Patterns (verkettet über Punkt-Symbol) ToList implizit in jeder SPARQL-Anfrage enthalten Join Verknüpfung zweier Gruppen ({ }.{ }) OrderBy Order By LeftJoin Optional Project Select-Variablen Filter Filter Distinct Select Distinct Union Union Reduced Select Reduced Graph Graph Slice Kombination aus Limit und Offset Tabelle 3: SPARQL Algebra Operatoren und Solution Modifier Der BGP-Operator bildet die Grundlage jeder Anfrage und wird als einziger Operator unmittelbar auf dem RDF-Datensatz (RDF-Graph) ausgewertet. BGPs kommen daher im Algebra-Baum ausschließlich auf der untersten Ebene (Blatt-Ebene) vor und die Blatt-Ebene besteht ausschließlich aus BGPs. Alle weiteren Operatoren bekommen als Eingabe die Ausgabe derjenigen Operatoren, die im Algebra-Baum unter ihnen stehen. Die Solution Modifier dienen dazu, aus den berechneten Ergebnissen für das Graph Pattern die endgültige Antwort auf die Anfrage zu generieren (z.b. Sortieren der Ergebnisse). Eine formale Definition der Semantik der einzelnen Algebra Operatoren und Solution Modifier erfolgt im Rahmen der Übersetzung in Kapitel 5. Ein Ausdruck in der SPARQL Algebra kann in Form eines Baums repräsentiert werden. Abbildung 13 zeigt den SPARQL Algebra-Baum zur SPARQL- Anfrage aus Abbildung 12 (A5). Die Auswertung des Algebra-Baums erfolgt Bottom-up (von unten nach oben), beginnend bei den beiden BGPs, die auf den RDF-Daten ausgewertet werden.

29 3 SPARQL 29 PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT * WHERE {?person foaf:name?name.?person foaf:age?age OPTIONAL {?person foaf:mbox? } FILTER (?age >= 18) } ORDER BY?age DESC Abbildung 12: SPARQL-Anfrage mit Optional und Filter (A5) OrderBy?age DESC ToList Filter?age >= 18 LeftJoin BGP?person foaf:name?name.?person foaf:age?age BGP?person foaf:mbox? Abbildung 13: SPARQL Algebra-Baum Blatt-Ebene

30 4 Pig Latin 30 4 Pig Latin Pig Latin ist eine von Yahoo! Research entworfene Sprache zur Analyse von großen Datenmengen. Konzeptionell ist die Sprache unabhängig von der konkreten Ausführungsplattform 15, sie wurde jedoch hauptsächlich für den Einsatz im Apache Hadoop Framework (siehe Abschnitt 2.3) entwickelt. Die dazugehörende Implementierung, Pig, übersetzt ein Pig Latin-Programm in eine Folge von MapReduce-Jobs und ist mittlerweile ein fester Bestandteil des Hadoop Frameworks. Das von Google im Jahr 2004 vorgestellte MapReduce-Programmiermodell zur Verarbeitung großer Datenmengen erfreut sich in den letzten Jahren stetig wachsender Beliebtheit. Allerdings ist die Entwicklung auf MapReduce-Ebene sehr aufwändig und erfordert in der Regel fortgeschrittene Programmierkenntnisse [Olston, et al., 2008]. Ziel der Entwicklung von Pig Latin war es daher, Entwicklern und Analysten eine möglichst einfache und zugleich mächtige Sprache in die Hand zu geben, welche die Verwendung von MapReduce (Hadoop) auch ohne fundierte Programmierkenntnisse ermöglicht. Laut den Entwicklern von Yahoo! Research verbindet Pig Latin die hochsprachige, deklarative Struktur von SQL mit der recht technischen, prozeduralen Programmierung von MapReduce. Pig Latin wird von Entwicklern bei Yahoo! für vielfältige Zwecke (vor allem zur Daten-Analyse) eingesetzt. Der Erfolg zeigt sich auch daran, dass Pig mittlerweile ein offizielles Subprojekt des Hadoop Frameworks ist. Die folgende kurze Einführung basiert im Wesentlichen auf der offiziellen Dokumentation von Pig Latin [Apache Software Foundation, 2010] sowie dem Überblick aus [Olston, et al., 2008]. 4.1 Datenmodell Pig Latin besitzt ein vollständig geschachteltes Datenmodell und erlaubt dem Entwickler damit eine größere Flexibilität als die von der ersten Normalform vorgeschriebenen flachen Tabellen von relationalen Datenbanken. Dies hat entscheidende Vorteile für viele typische Anwendungsfälle bei großen Datenmen- 15 Ein Pig Latin-Programm wird zunächst in einen von der Ausführungsplattform unabhängigen, logischen Plan übersetzt. Dieser logische Plan muss dann in einen an die Ausführungsplattform angepassten Plan übersetzt werden.

31 4 Pig Latin 31 gen. So ist es z.b. denkbar, dass ein Web Crawler 16 zu jeder URL die Menge an ausgehenden Links von dieser URL sammelt. Für einen Entwickler wäre es dann naheliegend, für jede URL einen Datensatz in der Form (url, Set<outLinks>) zu haben, wobei der erste Eintrag der URL und der zweite Eintrag der Menge an ausgehenden Links entspricht. Bei flachen Tabellen in relationalen Datenbanken würde ein solcher Datensatz für jeden outlink einen separaten Eintrag erfordern. Das Datenmodell von Pig Latin kennt vier verschiedene Typen: Atom. Ein Atom beinhaltet einen einfachen, atomaren Wert. Pig Latin kennt hierfür die Datentypen int, long, float und double für Zahlen, chararray für Unicode-Zeichenketten und bytearray für eine Folge von Bytes. Beispiel: 'Sarah' oder 24 Tupel. Ein Tupel besteht aus einer Sequenz von Feldern, wobei jedes Feld einen beliebigen Datentyp besitzen kann. Jedem Feld in einem Tupel kann zudem ein Name (Alias) zugewiesen werden, über den das Feld referenziert werden kann. Werden den Feldern keine Namen zugewiesen, so ist eine positionelle Referenzierung möglich (z.b. $0, $1 usw.). Anzahl, Typ und Alias-Namen der Felder eines Tupels werden auch als Schema des Tupels bezeichnet. Beispiel: ('John','Doe') mit Alias-Namen (Vorname,Nachname) Bag. Eine Bag besteht aus einer Kollektion von Tupeln, wobei ein Tupel auch mehrfach vorkommen darf. Darüber hinaus müssen die Schemata der Tupel nicht übereinstimmen, d.h. die Tupel können eine unterschiedliche Anzahl von Feldern mit unterschiedlichen Typen aufweisen. Im Regelfall ist dies jedoch keine empfehlenswerte Struktur, da die Reihenfolge der Tupel in einer Bag nicht vorgeschrieben ist und der Entwickler gewährleisten muss, dass unterschiedliche Tupel korrekt behandelt werden. Es sind jedoch auch Fälle denkbar, in denen eine solche Struktur durchaus Sinn machen kann, z.b. bei optionalen, zusätzlichen Informationen. ('Bob','Sarah') Beispiel: 'Peter', ('likes','football') 16 Web Crawler sind Programme, die verschiedenste Daten aus dem Internet automatisiert zusammentragen (z.b. zum Aufbau eines Index bei Web-Suchmaschinen).

32 4 Pig Latin 32 Das erste Tupel in der Bag enthält zwei atomare Felder. Das zweite Tupel enthält ebenfalls zwei Felder, wobei das zweite Feld wiederum ein Tupel mit zwei atomaren Feldern ist. Map. Eine Map beinhaltet eine Kollektion von Datenelementen. Jedes Element kann dabei über einen zugeordneten Schlüssel referenziert werden. Auch hier können die verschiedenen Datenelemente einen unterschiedlichen Typ und eine unterschiedliche Anzahl an Feldern (Schema) haben. Die Schlüssel müssen allerdings atomare Werte sein, um einen effizienten Lookup zu ermöglichen. Maps sind vor allem dann nützlich, wenn sich Schemata im Laufe der Zeit verändern können. Neue Informationen lassen sich so unter einem neuen Schlüssel in der Map ablegen, wodurch ältere Pig Latin-Programme nicht geändert werden müssen. 'name' 'John' Beispiel: 'knows' ('Sarah') ('Bob') Die erste Schlüssel in der Map verweist auf einen atomaren Wert, wohingegen der zweite Schlüssel auf eine Bag, bestehend aus zwei Tupel, verweist. 4.2 Operatoren Ein Pig Latin-Programm besteht aus einer Sequenz von Schritten, wobei jeder Schritt einer einzelnen Daten-Transformation entspricht. Die zur Verfügung stehenden Operatoren erlauben dadurch eine einfache Manipulation der Daten, während die konkrete technische Implementierung der entsprechenden Operatoren im MapReduce-Framework für den Anwender transparent bleibt. Der Anwender kann sich somit voll und ganz auf die zu lösende Aufgabe konzentrieren und muss sich nicht mit technischen Details beschäftigen (z.b. wie ein Join in MapReduce konkret implementiert werden kann). Da Pig Latin für die Bearbeitung von großen Datenmengen mittels Hadoop entwickelt wurde, müssen die Operatoren parallelisierbar sein. Daher wurden konsequenterweise nur solche Operatoren aufgenommen, die sich in eine Folge von MapReduce-Jobs übersetzen und damit parallel ausführen lassen. Jeder Operator liefert als Ergebnis jeweils eine Bag (siehe Abschnitt 4.1), der ein Name (Alias) zugewiesen wird. Man spricht in diesem Fall auch von einer Relation. Das Schema der Relation entspricht dem Schema der Tupel in der Relation (siehe Datentyp Tupel).

33 4 Pig Latin 33 Im Folgenden werden die wichtigsten Operatoren kurz vorgestellt: Load. Der erste Schritt in einem Pig Latin-Programm ist das Laden der Eingabe-Daten. Dazu müssen die Daten deserialisiert und in das Datenmodell von Pig Latin überführt werden. Zu diesem Zweck stehen einige Standard-Loader zur Verfügung, der Entwickler kann aber auch einen eigenen Loader in Form einer User Defined Function (siehe Abschnitt 4.3) implementieren. Optional ist es möglich, beim Laden auch das Schema der Daten zu spezifizieren. Beispiel: persons = LOAD 'file' USING PigStorage() AS (name:chararray, age:int, city:chararray); In diesem Beispiel wird die Eingabe-Datei 'file' mit Hilfe des Standard-Loaders 17 PigStorage() geladen. Jedes Tupel der Eingabe besteht dabei aus drei Feldern. Foreach. Mit Hilfe des Foreach-Operators lässt sich eine Verarbeitung auf jedes Tupel in einer Relation anwenden. Dabei darf es allerdings keine Abhängigkeiten bei der Verarbeitung unterschiedlicher Tupel geben, da eine effiziente Parallelisierung sonst nicht möglich wäre. Die erzeugten Ergebnis-Tupel müssen nicht das gleiche Schema wie die Tupel der Eingabe haben. Insbesondere lassen sich mit Hilfe von Foreach Spalten aus einer Relation entfernen oder neue Spalten hinzufügen. Beispiel: result1 = FOREACH persons GENERATE name, age>=18? 'adult':'minor' AS class; (a) persons (b) result1 name age city name class Sarah 17 Freiburg Sarah minor Bob 32 Berlin Bob adult Paul 16 Berlin Paul minor Alice 24 Freiburg Alice adult Peter 38 Freiburg Peter adult Tabelle 4: Relation vor (a) und nach (b) Ausführung von Foreach 17 Der Standard-Loader dient zum Laden von Textdateien. Ein Tupel entspricht dabei einer Zeile und die einzelnen Felder des Tupels müssen mit Tabs getrennt sein.

34 4 Pig Latin 34 Für jedes Tupel der Eingabe-Relation wird ein neues Tupel in der Ausgabe-Relation erzeugt. Das Feld 'name' wird dabei ohne Änderung übernommen. Die Werte für das Feld 'class' hängen von den Eingabe- Werten im Feld 'age' ab und unterteilen die Personen in Erwachsene und Minderjährige. Filter. Der Filter-Operator ermöglicht das Entfernen ungewollter Tupel aus einer Relation. Dazu wird eine Filter-Bedingung spezifiziert, die dann auf jedes Tupel in der Relation angewendet wird. Eine Filter- Bedingung kann Vergleichsoperatoren (z.b. ==,!=, >, <), arithmetische Operatoren (z.b. +, -, *, /) sowie logische Verknüpfungen (AND, OR, NOT) enthalten. Beispiel: result2 = FILTER persons BY age>=18; (a) persons (b) result2 name age city name age city Sarah 17 Freiburg Bob 32 Berlin Bob 32 Berlin Alice 24 Freiburg Paul 16 Berlin Peter 38 Freiburg Alice 24 Freiburg Peter 38 Freiburg Tabelle 5: Relation vor (a) und nach (b) Ausführung von Filter Group. Der Group-Operator von Pig Latin erlaubt das Gruppieren von Tupeln aus einer oder mehreren Relationen. Dazu wird ein Ausdruck definiert, der auf jedes Tupel der Eingabe angewendet wird. Ergibt der Ausdruck für zwei Tupel den gleichen Wert, so werden die Tupel in dieselbe Gruppe übernommen. In der Ausgabe-Relation eines Group-Befehls gibt es für jede Gruppe ein Tupel. Das erste Feld (mit Alias group) enthält den Gruppen-Bezeichner, jedes weitere Feld (ein Feld für jede Eingabe-Relation) enthält eine Bag, benannt mit dem Alias-Namen der jeweiligen Eingabe-Relation. Diese beinhaltet alle Tupel der Eingabe-Relation, die zur entsprechenden Gruppe gehören. Beispiel: result3 = GROUP persons BY city;

35 4 Pig Latin 35 result3 group Freiburg Berlin persons (Sarah, 17, Freiburg) (Alice, 24, Freiburg ) (Peter, 38, Freiburg) (Bob, 32, Berlin) (Paul, 16, Berlin) Tabelle 6: Ergebnis des Group-Operators Das Ergebnis der Gruppierung enthält jeweils ein Tupel (eine Zeile) für die beiden Gruppen 'Freiburg' und 'Berlin'. Die Eingabe-Relation 'persons' enthält zu jeder Gruppe mehrere Tupel. [Outer] Join. Equi-Joins lassen sich in Pig Latin mit Hilfe des Join- Operators ausdrücken. Dabei müssen die Inhalte eines oder mehrerer Felder der Relationen identisch sein. Eine Besonderheit von Pig Latin ist darüber hinaus, dass sich ein Join auch auf mehr als zwei Relationen beziehen kann (Multi-Join). Über die Schlüsselwörter Left Outer bzw. Right Outer können auch Outer Joins in Pig Latin realisiert werden. Beispiel: result4 = JOIN result1 BY name [LEFT OUTER], result2 BY name; result4 result1:: name result1:: class result2:: name result2:: age result2:: city (a) Bob adult Bob 32 Berlin Alice minor Alice 24 Freiburg Peter adult Peter 38 Freiburg (b) (Sarah) (minor) (Paul) (minor) Tabelle 7: Ergebnis des Join- (a) und Outer Join-Operators (b) Der Join-Operator in Pig Latin übernimmt jedes Feld der ursprünglichen Relationen, insbesondere auch die Felder der Join-Prädikate. Deshalb kommen in den Ergebnis-Tupeln die Join-Werte auch doppelt vor (z.b. 'Bob' im ersten Tupel). Das Ergebnis des Beispiel-Joins (a) ent-

36 4 Pig Latin 36 hält drei Tupel für 'Bob', 'Alice' und 'Peter', wohingegen das Ergebnis des Outer Joins (b) noch zwei weitere Tupel für 'Sarah' und 'Paul' enthält mit Null-Werten in den Feldern, die zur zweiten Relation gehören. Cross. Kreuzprodukte können in Pig Latin über den Cross-Operator ausgedrückt werden. Beim Kreuzprodukt wird jedes Tupel aus der einen Relation mit jedem Tupel aus der anderen Relation verknüpft. Bei zwei Relationen A (n Tupel) und B (m Tupel) hat die Ergebnis-Relation A x B = C folglich n*m viele Tupel. Wie auch der Join-Operator lässt sich der Cross-Operator dabei auf mehrere Relationen gleichzeitig anwenden (Multi-Cross). Erwartungsgemäß ist das Kreuzprodukt eine sehr aufwändige Operation und sollte nach Möglichkeit vermieden werden, da Pig Latin für den Einsatz bei sehr großen Datenmengen konzipiert wurde. Diese Vermutung hat sich bei der Evaluation der Arbeit (siehe Kapitel 8) sehr deutlich bestätigt. Order By. Relationen lassen sich bezüglich eines oder mehrerer Felder sortieren. Werden nach der Sortierung allerdings weitere Operationen auf der Relation ausgeführt (z.b. Filter), so kann aufgrund der Parallelität der Ausführung nicht garantiert werden, dass die Sortierung erhalten bleibt. Ein Sortieren der Daten ist daher im Allgemeinen nur unmittelbar vor der Ausgabe sinnvoll. Beispiel: result5 = ORDER persons BY age DESC; (a) persons (b) result5 name age city name age city Sarah 17 Freiburg Peter 38 Freiburg Bob 32 Berlin Bob 32 Berlin Paul 16 Berlin Alice 24 Freiburg Alice 24 Freiburg Sarah 17 Freiburg Peter 38 Freiburg Paul 16 Berlin Tabelle 8: Relation vor (a) und nach (b) Ausführung von Order By Union. Zwei oder mehr Relationen können mit Hilfe des Union- Operators zu einer Relation zusammengeführt werden, wobei Duplikate (mehrfach vorkommende Tupel) erhalten bleiben. Im Gegensatz zu relationalen Datenbanken müssen die Tupel dabei nicht das gleiche Schema

37 4 Pig Latin 37 und insbesondere nicht die gleiche Anzahl an Feldern besitzen. Der Entwickler muss daher gewährleisten, dass entweder (1) die Tupel der Eingabe-Relationen dasselbe Schema besitzen oder (2) weitere Operationen mit unterschiedlichen Tupeln in der Ausgabe-Relation umgehen können. Im Regelfall ist es nicht besonders empfehlenswert, Relationen mit unterschiedlichen Schemata zu vereinigen, da dabei die Schema- Informationen (speziell die Alias-Namen für die Felder der Tupel) verloren gehen. Mit Hilfe von Foreach können die Schemata zweier Relationen zunächst angeglichen werden, um sie anschließend unproblematisch vereinigen zu können. Store. Der Store-Operator speichert die Inhalte einer Relation in eine Datei. Dazu müssen die Tupel der Relation serialisiert werden. Ebenso wie beim Load-Operator kann der Entwickler entweder eine User Defined Function (siehe Abschnitt 4.3) implementieren oder eine Standard- Implementierung verwenden, um die Werte in das gewünschte Format zu überführen. Beispiel: STORE result7 INTO 'file' USING mystorefunc(); 4.3 User Defined Functions (UDF) Pig Latin wurde hauptsächlich zur Analyse von großen Datensätzen wie Log- Dateien oder Dateien von Web Crawlern entwickelt. Dazu ist oftmals eine sehr spezifische Bearbeitung notwendig, welche die Funktionalität der allgemeinen Operatoren aus Abschnitt 4.2 übersteigt. So könnte es z.b. im Zuge einer Index-Erstellung durchaus sinnvoll sein, zunächst den Wortstamm eines Wortes zu bestimmen, um diesen in den Index aufzunehmen. Hierfür bietet Pig Latin eine umfassende Unterstützung von sogenannten User Defined Functions (UDF), mit deren Hilfe sich nahezu alle Aspekte der Datenverarbeitung in Pig Latin an die gewünschten Bedürfnisse anpassen lassen. Dazu kann eine UDF jeden belieben Datentyp aus Abschnitt 4.1 als Eingabe entgegennehmen und ebenso auch ausgeben. Zum Zeitpunkt der Erstellung dieser Arbeit müssen UDFs in Java geschrieben sein, in Zukunft sollen jedoch beliebige Sprachen (wie z.b. C++ oder Perl) verwendet werden können. Abbildung 14 zeigt eine Verwendung von zwei UDFs zur Erstellung einer einfachen Index-Datei von Wortstämmen. Angenommen die Eingabe-Datei 'list.txt' enthalte bereits eine Liste von Wörtern und zu jedem Wort eine Liste an Dokumenten, in denen das Wort vorkommt. Zunächst werden Stopp-

38 4 Pig Latin 38 wörter 18 aus der Liste entfernt, die nicht in den Index aufgenommen werden sollen. Dazu werden nur diejenigen Wörter beibehalten, die von der UDF isstopword() nicht als Stoppwort erkannt werden. Anschließend wird mit Hilfe der UDF stem() für jedes Wort der entsprechende Wortstamm bestimmt. Die abschließende Gruppierung sorgt dafür, dass alle Wörter mit dem gleichen Wortstamm zu einem Datensatz zusammengefasst werden. list = LOAD 'list.txt' AS (word, doclist); no_stop = FILTER list BY NOT isstopword(word); stemmed = FOREACH no_stop GENERATE stem(word) AS word, doclist; index = GROUP stemmed BY word; STORE index INTO 'index.txt'; Abbildung 14: Index-Erstellung mittels UDFs 4.4 Übersetzung in MapReduce-Plan Pig Latin wurde vollständig in einem System namens Pig implementiert. Konzeptionell kann Pig zwar verschiedene Systeme als Ausführungsplattform einbinden, entwickelt wurde es allerdings für den Einsatz im Hadoop Framework. Zunächst wird das Pig Latin-Programm in einen logischen Plan übersetzt, der unabhängig von der konkreten Ausführungsplattform ist. Um das Pig Latin- Programm auf einer bestimmten Plattform auszuführen, muss ein Compiler entwickelt werden, der den logischen Plan in einen konkreten Plan für die entsprechende Plattform übersetzt. Der Compiler von Pig übersetzt den logischen Plan in eine Sequenz von MapReduce-Jobs, die dann im Hadoop Framework ausgeführt werden. Dabei wird die Ausgabe eines MapReduce-Jobs im Dateisystem von Hadoop, HDFS, abgespeichert, um einem folgenden MapReduce-Job als Eingabe zur Verfügung zu stehen. Nicht jeder Pig Latin-Befehl erfordert allerdings auch einen eigenen MapReduce-Job, oftmals lassen sich mehrere Befehle zu einem Job zusammenfassen. Die Operatoren Group, Join, Distinct, Limit und Order By erfordern jeweils eine separate MapReduce-Phase. Zunächst wird für jeden dieser Befehle ein separater MapReduce-Job erzeugt. Die initialen Befehle ohne eigene MapReduce-Phase können in die Map-Funktion des ersten MapReduce- Jobs J 1 übernommen werden. Die Befehle zwischen zwei aufeinanderfolgenden 18 Stoppwörter sind z.b. wenig selektive Füllwörter wie 'und'. Solche Wörter kommen in nahezu jedem Text vor und haben keine Aussagekraft.

39 4 Pig Latin 39 Jobs J i und J i+1 können entweder (a) in die Reduce-Funktion von J i oder (b) die Map-Funktion von J i+1 übernommen werden. Pig folgt dabei dem Ansatz (a), da auf diese Weise im Regelfall weniger Daten zwischen zwei aufeinander folgenden MapReduce-Jobs im HDFS materialisiert werden müssen. Abbildung 15 zeigt den schematischen Aufbau eines solchen MapReduce-Plans. map 1 reduce 1 map i reduce i Load Filter Group Join Filter Load J 1 J i Abbildung 15: MapReduce-Plan für PigLatin-Programm Quelle: erstellt nach dem Beispiel aus [Olston, et al., 2008] 4.5 Parallelität der Ausführung Die Mapper und Reducer eines MapReduce-Jobs werden von Hadoop parallel und verteilt auf dem Cluster ausgeführt. Der Grad der Parallelität hängt somit insbesondere von der Anzahl der Mapper und Reducer ab, die zur Berechnung eines MapReduce-Jobs verwendet werden. Die Anzahl der Mapper wird von Hadoop automatisch bestimmt und richtet sich nach der Größe der Eingabe, genauer gesagt nach der Anzahl der HDFS-Blöcke. Die Anzahl der Reducer eines MapReduce-Jobs liegt allerdings im Ermessen des Anwenders und richtet sich nach den spezifischen Gegebenheiten. Eine allgemeingültige Richtlinie für die richtige Wahl der Reducer-Anzahl gibt es leider nicht. So spielen neben der Größe des Clusters und der Ressourcen eines Computers im Cluster auch die Anforderungen der zu lösenden Aufgabe eine entscheidende Rolle. Pig Latin kennt hierfür das Schlüsselwort Parallel. Bei den Operatoren Group, Join, Distinct, Limit und Order By kann damit die gewünschte Reducer-Anzahl angegeben werden, die zur Auswertung des Operators verwendet werden soll. Abbildung 16 zeigt ein Beispiel eines Joins mit neun Reducern. C = JOIN A BY pred, B BY pred PARALLEL 9 ; Abbildung 16: Reducer-Parallelität bei Pig Latin

40 5 Übersetzung von SPARQL nach Pig Latin 40 5 Übersetzung von SPARQL nach Pig Latin In diesem Abschnitt wird die Übersetzung einer SPARQL-Anfrage in ein Pig Latin-Programm beschrieben. Zunächst wird in Abschnitt 5.1 das Konzept der Übersetzung vorgestellt und in Abschnitt 5.2 eine Abbildung der RDF-Daten in das Datenmodell von Pig Latin spezifiziert. Anschließend werden in Abschnitt 5.3 Übersetzungsvorschriften für die Operatoren und Solution Modifier der SPARQL Algebra definiert. Die Angaben zur Semantik der SPARQL Algebra beziehen sich auf die offizielle Dokumentation von SPARQL aus [Prud'hommeaux, et al., 2008] sowie die Arbeit von Pérez et al. [Pérez, et al., 2006; Pérez, et al., 2009]. Gegenstand der Arbeit ist die Übersetzung von SPARQL Select-Anfragen, da dieser Anfragetyp die gebräuchlichste und wichtigste Anfrage-Form in SPARQL darstellt. Bei einer Select-Anfrage werden die Ergebnisse für das Graph Pattern der Anfrage in tabellarischer Form zurückgegeben. Der Graph- Operator wurde bei der Übersetzung nicht betrachtet, da er im Kontext der Auswertung von SPARQL-Anfragen im Hadoop-Framework nur eine untergeordnete Rolle spielt. Er dient dazu, unterschiedliche RDF-Graphen in einer SPARQL-Anfrage referenzieren zu können. Hierfür wird über eine URI (typischerweise eine URL) angegeben, wo die RDF-Daten zum jeweiligen Graph abgelegt sind. Um eine SPARQL-Anfrage in Form eines Pig Latin-Programms in Hadoop auswerten zu können, müssen die entsprechenden RDF-Daten aller Graphen allerdings im HDFS vorliegen. Ein Abruf der Daten über das Internet ist nicht vorgesehen und im Sinne der Anwendung für sehr große Datensätze auch nicht zu empfehlen. In diesem Fall können mehrere Datensätze allerdings auch zu einem einzigen Datensatz zusammengefasst werden, um so die Anwendung des Graph-Operators vermeiden zu können 19. Ein wesentliches Problem bei der Übersetzung von SPARQL-Anfragen stellen ungebundene Variablen dar, die durch die Anwendung des Optional- Operators (LeftJoin) entstehen. Ungebundene Variablen können im Datenmodell von Pig in Form von Null-Werten repräsentiert werden. In Pig Latin sind Prädikate beim Join von Relationen, ebenso wie in der relationalen Algebra, Null-abweisend (null-rejecting), d.h. dass sich das Prädikat im Falle eines Null- Wertes (ungebundene Variable) zu false auswertet. Das entspricht allerdings 19 Der Load-Befehl von Pig Latin kann z.b. alle Dateien in einem Ordner auf ein Mal laden.

41 5 Übersetzung von SPARQL nach Pig Latin 41 nicht der Semantik von SPARQL, da eine ungebundene Variable mit einem beliebigen Wert belegt werden kann und somit beim Join insbesondere nicht Null-abweisend sein darf. Um diese Problematik zu vermeiden, werden für die Übersetzung sogenannte wohlgeformte Graph Pattern (bzw. wohlgeformte SPARQL-Anfragen) nach Pérez et al. [Pérez, et al., 2009] betrachtet. Definition 1.1. Bezeichne var(x) die Menge der Variablen in X. Ein Graph Pattern P ist sicher, falls für jedes Sub-Pattern (P' Filter R) von P gilt, dass var(r) var(p'), d.h. im Filter-Ausdruck dürfen keine Variablen vorkommen, die in P' nicht vorkommen. Eine SPARQL-Anfrage ist sicher, wenn das Graph Pattern der Anfrage sicher ist. Definition 1.2. Ein Graph Pattern P ist wohlgeformt, wenn es sicher ist, kein Union enthält und für jedes Sub-Pattern P' = (P 1 Optional P 2 ) von P und jede Variable?X aus P gilt: Falls?X sowohl in P 2 als auch außerhalb von P' vorkommt, dann kommt sie auch in P 1 vor. Eine SPARQL-Anfrage ist wohlgeformt, wenn das Graph Pattern der Anfrage wohlgeformt ist. Wohlgeformte Graph Patterns haben den Vorteil, dass sie effizienter ausgewertet werden können als das bei allgemeinen Graph Patterns in SPARQL der Fall ist. Insbesondere können bei wohlgeformten Graph Patterns keine Joins über Null-Werte auftreten. Ein Null-Wert entspricht einer ungebundenen Variablen, die durch ein Optional erzeugt wurde (Variable kommt in P 2 vor aber nicht in P 1 ). Solche Variablen dürfen bei wohlgeformten Anfragen allerdings per Definition nicht außerhalb des Optionals vorkommen. An einigen Punkten geht die Übersetzung auch über wohlgeformte Anfragen hinaus (z.b. Unterstützung von Union). Hierauf wird jeweils an der entsprechenden Stelle bei der Übersetzung explizit hingewiesen. 5.1 Konzeption der Übersetzung Eine direkte Übersetzung einer SPARQL-Anfrage in ein Pig Latin-Programm wäre aufgrund der komplexen Syntax und der datenorientierten Struktur von SPARQL äußerst schwierig. Die Semantik einer SPARQL-Anfrage ist allerdings auf der Ebene der SPARQL Algebra definiert und orientiert sich an den bekannten Konzepten der relationalen Algebra. Für die Übersetzung einer SPARQL-Anfrage in ein Pig Latin-Programm ist es daher ausreichend, eine Übersetzung für die SPARQL Algebra zu definieren. Eine Auflistung aller Operatoren und Solution Modifier der SPARQL Algebra findet sich in Abschnitt 3.3 dieser Arbeit.

42 5 Übersetzung von SPARQL nach Pig Latin 42 SELECT * WHERE {?x name?n1.?x knows?z. OPTIONAL {?x mail?m1.... BGP OrderBy LeftJoin... A = LOAD B = FILTER A C = FILTER A D = JOIN B BY C BY E = FOREACH D... SPARQL-Anfrage SPARQL Algebra-Baum Pig Latin- Abbildung 17: Konzeption der Übersetzung Abbildung 17 zeigt das grundlegende Konzept der Übersetzung, wie sie in dieser Arbeit vorgestellt wird. Dabei wird die Anfrage zunächst nach dem offiziellen Schema des W3C in einen SPARQL Algebra-Baum überführt. Der Algebra- Baum wird anschließend in ein Pig Latin-Programm übersetzt. Diese modulare Vorgehensweise bietet mehrere Vorteile, so können beispielsweise Optimierungen auf der Algebra-Ebene durchgeführt werden (siehe Kapitel 6) ohne die Übersetzung der Algebra in ein Pig Latin-Programm verändern zu müssen. Das Auswertung-Schema des resultierenden Pig Latin-Programms wird in Abbildung 18 grafisch dargestellt. Dazu müssen die RDF-Daten, auf denen die ursprüngliche SPARQL-Anfrage operiert, in das HDFS übernommen werden. Pig generiert aus dem Pig Latin-Programm eine Folge von MapReduce-Jobs nach dem Prinzip, wie es im Abschnitt 4.4 dieser Arbeit erläutert wurde. Die generierten MapReduce-Jobs werden dann im Hadoop Framework ausgeführt und die berechneten Ergebnisse wieder im HDFS abgelegt. s1 p1 o1. s2 p2 o2. s3 p3 o3.... part-0000 part RDF-Daten A = LOAD B = FILTER A C = FOREACH B... Pig Latin-Programm HDFS Job 1 Job 2 Job 3... Pig Hadoop Abbildung 18: Konzeption der Auswertung

43 5 Übersetzung von SPARQL nach Pig Latin Abbildung von RDF in das Datenmodell von Pig Damit eine SPARQL-Anfrage überhaupt in Form eines Pig Latin-Programms ausgewertet werden kann, muss zunächst festgelegt werden, wie die RDF- Daten im Datenmodell von Pig dargestellt werden können. Eine ausführliche Darstellung der abstrakten Syntax von RDF findet sich in der Dokumentation des W3C [Klyne, et al., 2004], eine Einführung in das Datenmodell von Pig findet sich in Abschnitt 4.1 dieser Arbeit. Die hier vorgestellte Abbildung des RDF-Datenmodells orientiert sich an der zeilenbasierten Syntax von Serialisierungs-Formaten für RDF wie Turtle oder N3. Ein RDF-Datensatz besteht im Wesentlichen aus einer Menge von RDF- Tripeln. In Abschnitt 2.1 dieser Arbeit wurde bereits das korrekte Format eines RDF-Tripels beschrieben. Ein RDF-Tripel setzt sich aus URIs, Literalen und Blank Nodes zusammen. URIs sind nach ihrer Syntax spezielle ASCII- Zeichenfolgen und lassen sich folglich im Datenmodell von Pig als Atome (Strings) repräsentieren. RDF unterscheidet des Weiteren zwischen einfachen und getypten Literalen. Einfache Literale sind ebenso wie URIs Zeichenfolgen in Unicode und können daher ebenfalls als Atome repräsentiert werden. Getypte Literale haben entweder einen zusätzlichen Language-Tag oder eine Datentyp-Angabe. Um hierfür nicht mehrere Felder im Tupel zu benötigen, lassen sich beide Angaben durch einen zusammengesetzten Wert codieren (literal- bzw. literalvalue^^datatype). So können auch getypte Literale als Atome im Pig-Datenmodell repräsentieren werden. Um URIs von Literalen unterscheiden zu können, werden der Wert eines Literals in Anführungszeichen (" ") und URIs in spitze Klammern (< >) gesetzt. Alternativ ist für URIs auch eine Abkürzungsschreibweise mit Präfixen (z.b. foaf:name) erlaubt, eine URI darf aber niemals mit einem Anführungszeichen beginnen. Diese Darstellung von URIs und Literalen entspricht der Codierung, wie sie auch im N3- Format verwendet wird. Blank Nodes werden in RDF zur Repräsentation von Ressourcen verwendet, denen keine eindeutige Bezeichnung (URI) zugeordnet werden kann oder soll (z.b. bei Kollektionen). Sie sind daher lediglich innerhalb eines RDF-Dokuments gültig. Die RDF-Syntax macht keine näheren Angaben zur internen Struktur von Blank Nodes, sie müssen lediglich von URIs und Literalen unterscheidbar sein. Um dies zu gewährleisten, kann wiederum die Darstellung aus dem N3-Format (_:nodeid) übernommen werden. Tabelle 9 zeigt einige RDF-Terme und ihre Repräsentation im Datenmodell von Pig.

44 5 Übersetzung von SPARQL nach Pig Latin 44 URI foaf: foaf:name Pig <http://xmlns.com/foaf/0.1/name> <http://xmlns.com/foaf/0.1/name> Literal Stadt city (lang: en) Pig "Stadt" 24 (Datentyp: xsd:integer) "24"^^xsd:integer Blank Node Blank Node mit ID b1 Pig _:b1 Tabelle 9: RDF-Terme und ihre Repräsentation im Datenmodell von Pig Da sowohl URIs, Literale als auch Blank Nodes jeweils als Atome im Datenmodell von Pig repräsentiert werden können, lässt sich ein RDF-Tripel somit analog zur zeilenbasierten Darstellung im N3-Format als Tupel mit drei Feldern darstellen. Ein RDF-Datensatz entspricht folglich einer Relation (Bag) von Tupeln mit dem Schema (s:chararray, p:chararray, o:chararray). 5.3 Übersetzung der SPARQL Algebra Im Folgenden werden für die Operatoren und Solution Modifier der SPARQL Algebra Vorschriften zur Übersetzung in eine Folge von Pig Latin-Befehlen angegeben. Konkrete Details der Implementierung werden an dieser Stelle außen vor gelassen und in Kapitel 7 gesondert behandelt. Zum Verständnis der Übersetzung ist es erforderlich, die Semantik der entsprechenden Operatoren und Solution Modifier genauer zu betrachten. Hierfür muss zunächst die benötigte Terminologie eingeführt werden. Sei V die unendliche Menge an Anfrage-Variablen und T die Menge der gültigen RDF-Terme (URIs, RDF-Literale, Blank Nodes). Der Ausdruck var(p) bezeichne die Menge der Variablen, die im Graph Pattern P enthalten sind. Definition 2.1. Ein (Solution) Mapping µ ist eine partielle Funktion µ:v T. Die Domain von µ, dom(µ), ist die Teilmenge von V, wo µ definiert ist. Für ein Basic Graph Pattern P bezeichnet µ(p) den RDF-Graph (Menge von RDF- Tripeln), den man erhält, indem man alle Variablen in P durch ihre Werte in µ ersetzt. Im Folgenden wird ein Solution Mapping umgangssprachlich auch als Ergebnis bezeichnet.

45 5 Übersetzung von SPARQL nach Pig Latin 45 Definition 2.2. Zwei Solution Mappings und sind kompatibel, wenn für alle Variablen? ( ) ( ) gilt, dass (? ) = (? ). Es folgt, dass wieder ein Solution Mapping ergibt. Zwei Mappings mit disjunkten Domains sind immer kompatibel und das leere Solution Mapping ist kompatibel zu jedem anderen Solution Mapping. Die offizielle Semantik von SPARQL des W3C weist einen größtenteils kompositionellen Charakter auf, eine Ausnahme bildet jedoch die Auswertung von Filter innerhalb von Optional. An dieser Stelle schreibt die Semantik eine nicht-kompositionelle Form der Auswertung vor und weicht somit von der strikt kompositionellen Semantik aus [Pérez, et al., 2006] ab. Insbesondere können sich daher bei der Auswertung solcher Anfragen Unterschiede in den Ergebnissen der beiden Semantiken ergeben, worauf die Autoren in einer späteren Veröffentlichung [Pérez, et al., 2009] eingehen. Es sei an dieser Stelle angemerkt, dass die Ergebnisse der Auswertung im Falle von sicheren Graph Pattern (siehe Definition 1.1) bei beiden Semantiken identisch sind. Da wohlgeformte SPARQL-Anfragen (siehe Definition 1.2) insbesondere aus sicheren Graph Pattern bestehen müssen, ergeben sich auch bei der Auswertung solcher Anfragen keine Unterschiede zwischen den beiden Semantiken. Zum besseren Verständnis der Operatoren und Solution Modifier der SPARQL-Algebra werden im Folgenden auch immer kleine Beispiele angegeben. Als Grundlage hierfür soll der folgende, vereinfachte RDF-Graph dienen Peter John Sarah Bob knows age mbox Alice Ringo Paul Abbildung 19: RDF-Graph mit drei Prädikaten 20 Zur besseren Übersichtlichkeit werden URIs abgekürzt dargestellt (ohne Präfixe).

46 5 Übersetzung von SPARQL nach Pig Latin Basic Graph Pattern (BGP) Basic Graph Patterns bilden die Grundlage jeder SPARQL-Anfrage und werden direkt auf dem entsprechenden RDF-Graph ausgewertet. Sie liefern als Ergebnis eine Menge von Solution Mappings, welche als Eingabe für die weiteren Operatoren dienen. Genauer gesagt handelt es sich dabei um eine Multi- Menge, da ein Solution Mapping mehrfach vorkommen kann. Definition 3. Sei G ein RDF-Graph und P ein BGP. Die Auswertung von P auf G,, ist definiert als die Menge der Solution Mappings = ( ) = ( ) ( ). Beispiel: P1 = BGP(?A knows Bob.?A age?b.?a mbox?c) (1) Es werden alle Personen gesucht, die Bob kennen und für die sowohl das Alter als auch eine -adresse bekannt sind. Die Auswertung von P1 auf dem RDF-Graph aus Abbildung 19 ergibt drei Solutions Mappings für die Variablen?A,?B und?c. Es gibt zwar insgesamt vier Personen, die Bob kennen, allerdings ist für John keine -adresse bekannt. Da bei einem BGP alle enthaltenen Triple-Patterns erfüllt sein müssen, wird John nicht zur Ergebnis-Menge hinzugefügt.?a?b?c = µ 1 : Peter 38 µ 2 : Sarah 24 µ 3 : Alice 30 Tabelle 10: Auswertung eines BGPs Pig Latin Das Ergebnis der Auswertung eines BGPs ist eine Menge von Solutions Mappings. Diese lassen sich in Pig in Form einer (flachen) Relation analog zur Darstellung in Tabelle 10 repräsentieren. Jedes Tupel der Relation entspricht einem Solution Mapping und die Felder des Tupels entsprechen den Werten für die Variablen. Das Schema der Relation bilden die Namen der Variablen ohne führendes Fragezeichen, da diese bei Alias-Namen in Pig nicht erlaubt sind. Jede Spalte der Relation entspricht somit einer Variablen.

47 5 Übersetzung von SPARQL nach Pig Latin 47 Die Auswertung eines BGPs in Pig Latin besteht im Wesentlichen aus einer Folge von Filter- und Join-Operationen mit abschließendem Foreach. Abbildung 20 zeigt die Übersetzung von P1 in eine Folge von Pig Latin-Befehlen. graph = LOAD 'pathtofile' USING rdfloader() AS (s,p,o) ; (1) t1 = FILTER graph BY p == 'knows' AND o == 'Bob' ; (2) t2 = FILTER graph BY p == 'age' ; t3 = FILTER graph BY p == 'mbox' ; j1 = JOIN t1 BY s, t2 BY s ; (3) j2 = JOIN j1 BY t1::s, t3 BY s; P1 = FOREACH j2 GENERATE (4) t1::s AS A, t2::o AS B, t3::o AS C ; Abbildung 20: Übersetzung eines BGPs (1) Das Laden der Daten erfolgt mit Hilfe des Load-Operators. Hierfür muss eine spezielle Loader-UDF implementiert werden (Details hierzu im Abschnitt 7 Implementierung). Anschließend stehen die Daten im Format aus Abschnitt 5.2 zur Verfügung. (2) Für jedes Triple-Pattern im BGP wird ein Filter benötigt, der diejenigen Tripel aus dem RDF-Graph selektiert, welche das Triple-Pattern erfüllen (Pattern Matching). (3) Die Ergebnisse der Filter werden dann sukzessive mit Hilfe des Join- Operators verknüpft. In jedem Schritt wird dabei ein weiteres Triple- Pattern zur berechneten Lösung hinzugenommen. Besteht das BGP aus n Triple-Patterns, so sind folglich n-1 Joins erforderlich. Das Prädikat des Joins ergibt sich jeweils aus den gemeinsamen Variablen der beiden Argumente. Der Join verknüpft damit die kompatiblen Solution Mappings (siehe Definition 2.2) der beiden Argumente und erzeugt daraus neue Solution Mappings. Sollte es keine gemeinsamen Variablen geben, so muss das Kreuzprodukt der beiden Argumente berechnet werden, da zwei Solution Mappings ohne gemeinsame Variablen per Definition immer kompatibel sind. (4) Durch ein abschließendes Foreach werden die überflüssigen Spalten der Relation mit den berechneten Solution Mappings entfernt und das Schema der Relation an die Variablennamen angepasst.

48 5 Übersetzung von SPARQL nach Pig Latin 48 Die hier beschriebene Übersetzung eines BGP arbeitet die Triple-Patterns genau in der Reihenfolge ab, wie sie im BGP spezifiziert sind. Die Reihenfolge der Triple-Patterns in einem BGP ist allerdings beliebig und hat keinen Einfluss auf das Ergebnis. Es ist daher ersichtlich, dass die beschriebene Überführungsvorschrift noch optimiert werden kann, um z.b. die Auswertung von Kreuzprodukten wenn möglich zu vermeiden. Auf solche Optimierungen wird in Kapitel 6 näher eingegangen Filter Der Filter-Operator der SPARQL Algebra dient dazu, aus einer Multi-Menge an Solutions Mappings diejenigen Mappings zu entfernen, welche die Filter- Bedingung nicht erfüllen. Auf die Syntax einer Filter-Bedingung in SPARQL wird an dieser Stelle nicht näher eingegangen. Der interessierte Leser sei hierfür insbesondere auf die offizielle Dokumentation in [Prud'hommeaux, et al., 2008] verwiesen. Definition 4. Sei G ein RDF-Graph, P ein beliebiges Graph Pattern und R eine Filter-Bedingung mit ( ) ( ). Der Ausdruck bedeute, dass das Solution Mapping µ die Filter-Bedingung R erfülle. Die Auswertung des Filters auf P, (, ), ist definiert als die Menge der Solution Mappings (, ) =. Beispiel: P2 = Filter(?B >= 30 &&?B <= 40, P1) (2) Aus den Ergebnissen (Solution Mappings) für das Pattern P1 sollen diejenigen Personen entfernt werden, die jünger als 30 oder älter als 40 Jahre sind. Da Sarah jünger als 30 Jahre ist, wird somit das entsprechende Solution Mapping aus der Menge der Solution Mappings entfernt.?a?b?c = µ 1 : Peter 38 µ 2 : Sarah 24 µ 3 : Alice 30 Tabelle 11: Auswertung von Filter

49 5 Übersetzung von SPARQL nach Pig Latin 49 Pig Latin Ein Filter lässt sich in Pig Latin mit Hilfe des Filter-Operators ausführen. Logische Verknüpfungen (&&,,!), Vergleichsoperatoren (=,!=, <, >, <=, >=) und arithmetische Berechnungen (+, -, *, /) lassen sich unmittelbar in Pig Latin ausdrücken, wobei ein paar einfache Anpassungen vorgenommen werden müssen: SPARQL && Pig Latin AND OR! NOT = == Tabelle 12: Filter-Anpassungen bei der Übersetzung Nicht alle Filter-Bedingungen in SPARQL lassen sich allerdings direkt in Pig Latin ausdrücken. So ist z.b. die Syntax von regulären Ausdrücken in SPARQL und Pig Latin verschieden 21. Darüber hinaus werden die built-in Funktionen von SPARQL wie isblank() natürlich auch nicht direkt unterstützt. Es wäre allerdings möglich, diese Funktionen in Form einer UDF zu implementieren, da Pig Latin auch beim Filter den Einsatz von UDFs explizit unterstützt. Abbildung 21 zeigt die Übersetzung von P2 in einen Pig Latin-Filter. P2 = FILTER P1 BY (B >= 30 AND B <= 40) ; Abbildung 21: Übersetzung von Filter Join Der Join-Operator der SPARQL Algebra bekommt als Eingabe zwei Multi- Mengen von Solution Mappings. Er kombiniert die kompatiblen Solution Mappings aus den beiden Mengen und erzeugt so eine neue Multi-Menge an Solution Mappings für das zusammengesetzte Pattern. Der Join-Operator entspricht in der SPARQL Syntax einer Verknüpfung von zwei Gruppierungen ({ }. { }), kommt aber in der Praxis nicht allzu häufig vor, da man zwei aufeinan- 21 SPARQL unterstützt reguläre Ausdrücke wie in XPath 2.0 oder XQuery 1.0 während Pig Latin die umfangreicheren regulären Ausdrücke von Java unterstützt.

50 5 Übersetzung von SPARQL nach Pig Latin 50 derfolgende Gruppierungen ohne Optional, Union oder Graph auch zu einer Gruppierung zusammenfassen kann. Definition 5. Sei G ein RDF-Graph und P, P' zwei beliebige Graph Patterns. Die Auswertung des Joins auf P und P', (, ), ist definiert als die Menge der Solution Mappings (, ) =. Beispiel: P3 = Join(BGP(?A knows Bob.?A age?b),bgp(?a mbox?c)) (3) Das linke Pattern (P) liefert alle Personen, die Bob kennen und deren Alter bekannt ist, das rechte Pattern (P') hingegen alle Personen, für die eine - Adresse bekannt ist. Über den Join-Operator werden die beiden Mengen von Solution Mappings zu einer Menge verknüpft. Es gibt im Beispiel-Graph vier Personen, die Bob kennen und deren Alter bekannt ist, allerdings haben nur drei dieser Personen eine -adresse.?a?b?a?c = µ 1 : Peter 38 = µ 1 : Peter µ 2 : John 29 µ 2 : Sarah µ 3 : Sarah 24 µ 3 : Alice µ 4 : Alice 30 µ 4 : Paul = µ 1 : Peter 38 µ 2 : Sarah 24 µ 3 : Alice 30 Tabelle 13: Auswertung von Join P3 liefert das gleiche Ergebnis wie das BGP aus P1. Die beiden BGPs aus P3 könnten folglich auch zu einem BGP zusammengefasst werden. Pig Latin Ein Join lässt sich in Pig Latin analog zum BGP mit Hilfe des Join-Befehls realisieren. Das Prädikat des Joins ergibt sich auch hier aus den gemeinsamen Variablen der beiden Eingabe-Relationen (Mengen von Solution Mappings). Sollte es keine gemeinsamen Variablen geben, so muss das Kreuzprodukt der

51 5 Übersetzung von SPARQL nach Pig Latin 51 beiden Relationen berechnet werden. Abschließend müssen mit einem Foreach die überflüssigen Spalten entfernt und das Schema der Ergebnis- Relation angepasst werden. Abbildung 22 zeigt die Übersetzung von P3 unter der Annahme, dass die Ergebnisse der beiden BGPs in den beiden Relationen BGP1 und BGP2 mit den Schemata (A,B) bzw. (A,C) vorliegen. j1 = JOIN BGP1 BY A, BGP2 BY A ; P3 = FOREACH j1 GENERATE BGP1::A AS A, BGP1::B AS B, BGP2::C AS C ; Abbildung 22: Übersetzung von Join LeftJoin Der LeftJoin-Operator der SPARQL Algebra ist das Pendant zum Optional in der SPARQL Syntax. Es ist sicherlich der interessanteste und zugleich auch komplexeste Operator, dessen exakte Semantik in der Vergangenheit Gegenstand zahlreicher Diskussionen in der SPARQL Community war. Mit seiner Hilfe können zusätzliche Informationen zum Ergebnis hinzugenommen werden, falls diese vorhanden sind. Im Gegensatz zum normalen Join werden diejenigen Ergebnisse, zu denen es keine zusätzlichen Informationen gibt, allerdings nicht verworfen. Konzeptionell entspricht der LeftJoin damit einem klassischen Left- Outer Join, wie der Name bereits vermuten lässt. Schwieriger wird es jedoch, wenn der rechte Teil des LeftJoins einen Filter enthält, wie das bei Pattern der Form {P} OPTIONAL {P' FILTER(R)} der Fall ist. Die offizielle Semantik von SPARQL sieht hier eine nicht-kompositionelle Form der Auswertung vor, wobei der Filter zu einer Bedingung für den Left- Outer Join wird. Eine kompositionelle Form der Auswertung (d.h. zunächst den Filter auf P' anwenden und danach den Left-Outer Join ausführen) ist im Allgemeinen nicht möglich, da sich die Filter-Bedingung R auf Variablen aus P beziehen kann, die in P' gar nicht definiert sind. Definition 6.1. Sei G ein RDF-Graph, P und P' zwei beliebige Graph Patterns und R eine Filter-Bedingung. Die Auswertung des LeftJoins auf P und P' unter der Filter-Bedingung R, (,, ), ist definiert als die Menge der Solution Mappings (,, ) = (, (, ) : h ( ).

52 5 Übersetzung von SPARQL nach Pig Latin 52 Beispiel: P4 = LeftJoin(BGP(?A age?b),bgp(?a mbox?c),true) (4) Beispiel: P5 = LeftJoin(BGP(?A age?b),bgp(?a mbox?c),?a = Paul) (5) Beispiel: P6 = LeftJoin(BGP(?A age?b),bgp(?a mbox?c),?b <= 30) (6) Die Pattern P4, P5 und P6 enthalten dieselben BGPs wie das Pattern P3. Im Gegensatz zum Join werden Ergebnisse für das linke BGP allerdings nicht verworfen, falls es keine kompatiblen Ergebnisse im rechten BGP dazu gibt. Enthält der LeftJoin keinen Filter, so wird dies wie in P4 durch eine Filter- Bedingung ausgedrückt, die immer erfüllt ist. Die Filter-Bedingung aus P5 hat hingegen zur Auswirkung, dass nur die -adresse von Paul zur Ergebnismenge hinzugenommen wird, sofern diese bekannt ist. Bei P6 werden die - Adressen derjenigen Personen hinzugenommen, die höchstens 30 Jahre alt sind. Tabelle 14 zeigt das Ergebnis der Auswertung von P4, P5 und P6.?A?B?C (P 4 )?C (P 5 )?C (P 6 ),, = µ 1 : Peter 38 µ 2 : Sarah 24 µ 3 : Alice 30 µ 4 : Paul 34 µ 5 : John 29 µ 6 : Bob 32 µ 7 : Ringo 45 Tabelle 14: Auswertung von LeftJoin Pig Latin Die Übersetzung des LeftJoin-Operators in Pig Latin weist einige Probleme auf. Das Hinzufügen zusätzlicher, optionaler Informationen zu einem Solution Mapping führt dazu, dass die entsprechenden Variablen in manchen Mappings gebunden sind und in anderen nicht. Es kann folglich der Fall auftreten, dass für zwei Mappings, (,, ) gilt, dass ( ) ( ). Ungebundene Variablen werden in Pig in Form von Null-Werten in den entsprechenden Spalten repräsentiert. Dies kann zu der bereits beschriebenen Problematik des Joins über Null-Werten führen, falls die ungebundene Variable auch außerhalb des LeftJoins referenziert wird. Aus diesem Grund werden für die Übersetzung sogenannte wohlgeformte Anfragen nach Pérez et al. (siehe

53 5 Übersetzung von SPARQL nach Pig Latin 53 Definition 1.2 auf Seite 41) betrachtet. Bei diesen Anfragen können keine Joins über Null-Werten auftreten. Eine weitere, interessante Eigenschaft von wohlgeformten Anfragen ist die Tatsache, dass sie sich vollständig kompositionell auswerten lassen. Das liegt daran, dass wohlgeformte Anfragen insbesondere sicher sein müssen (siehe Definition 1.1) und somit ein Filter in einem Optional nur Variablen enthalten darf, die auch im Optional vorkommen. Daher kann zunächst die Filter- Bedingung auf die Solution Mappings der rechten Seite angewendet und anschließend ein normaler Left-Outer Join ohne zusätzliche Bedingung durchgeführt werden. Im Falle von sicheren Anfragen lässt sich der LeftJoin somit äquivalent zu Definition 6.1 auch effizienter auswerten. Definition 6.2. Sei G ein RDF-Graph, P und P' zwei beliebige Graph Patterns und R eine sichere Filter-Bedingung, d.h. ( ) ( ). Die Auswertung des LeftJoins auf P und P' unter der Filter-Bedingung R, (,, ), ist definiert als die Menge der Solution Mappings (,, ) = (, (, ) : h. Das Pattern P5 enthält beispielsweise eine sichere Filter-Bedingung und kann entsprechend der Definition 6.2 ausgewertet werden. P6 hingegen enthält eine unsichere Filter-Bedingung und muss somit nach Definition 6.1 ausgewertet werden. Da die in der Evaluation verwendeten SPARQL-Anfragen des SP 2 Bench (siehe Kapitel 8) teilweise unsichere Filter-Bedingungen innerhalb von Optional enthalten und somit insbesondere nicht wohlgeformt sind, wurde bei der Übersetzung auch die allgemeine Form des LeftJoins nach Definition 6.1 betrachtet. Hinsichtlich der Übersetzung eines LeftJoins in Pig Latin müssen daher drei unterschiedliche Fälle betrachtet werden, deren Auswertung mehr oder weniger aufwändig ist. LeftJoin ohne Filter Ohne Filter lässt sich der LeftJoin als normaler Outer Join in Pig Latin auf den gemeinsamen Variablen der beiden Eingabe-Relationen realisieren. Gibt es keine gemeinsamen Variablen, so muss auch hier das Kreuzprodukt der beiden Relationen berechnet werden. Ein abschließendes Foreach entfernt die überflüssigen Spalten und passt dabei auch das Schema der Ergebnis-Relation an.

54 5 Übersetzung von SPARQL nach Pig Latin 54 Abbildung 23 zeigt die Übersetzung von P4 unter der Annahme, dass die Ergebnisse der beiden BGPs in den beiden Relationen BGP1 und BGP2 mit den Schemata (A,B) bzw. (A,C) vorliegen. lj = JOIN BGP1 BY A LEFT OUTER, BGP2 BY A ; P4 = FOREACH lj GENERATE BGP1::A AS A, BGP1::B AS B, BGP2::C AS C ; Abbildung 23: Übersetzung von LeftJoin ohne Filter LeftJoin mit sicherem Filter Ist der Filter des LeftJoins sicher, so kann die Auswertung entsprechend der Definition 6.2 erfolgen. Hierfür wird zunächst der Filter auf die rechte Relation angewendet, wie in der Übersetzung des Filter-Operators dargestellt. Im Folgenden können die beiden Relationen analog zu einem LeftJoin ohne Filter weiterverarbeitet werden. Diese Form der Auswertung ist wesentlich effizienter als die Auswertung nach Definition 6.1, da der Filter vor dem Outer Join ausgeführt und somit dessen Eingabegröße teilweise deutlich reduziert wird. Abbildung 24 zeigt die Übersetzung von P5, das eine sichere Filter- Bedingung enthält. f1 = FILTER BGP2 BY A == 'Paul' ; lj = JOIN BGP1 BY A LEFT OUTER, f1 BY A ; P5 = FOREACH lj GENERATE BGP1::A AS A, BGP1::B AS B, f1::c AS C ; Abbildung 24: Übersetzung von LeftJoin mit sicherem Filter LeftJoin mit unsicherem Filter Eine SPARQL-Anfrage, die einen LeftJoin mit einem unsicheren Filter enthält, ist nicht wohlgeformt (siehe Definition 1.2 auf Seite 41). Ein solcher LeftJoin lässt sich nicht nach Definition 6.2 auswerten, da der Filter sich auch auf Variablen bezieht, die nur im linken Graph Pattern definiert sind. Die Auswertung muss daher nach der allgemeinen, nicht kompositionellen Definition 6.1 eines LeftJoins erfolgen, was folglich bedeutet, dass der Filter nicht wie im vorherigen Fall vor dem Outer Join ausgeführt werden kann.

55 5 Übersetzung von SPARQL nach Pig Latin 55 Eine semi-wohlgeformte Anfrage, die zwar einen LeftJoin mit unsicherem Filter enthält, ansonsten aber die übrigen Eigenschaften der Wohlgeformtheit erfüllt, lässt sich in ein äquivalentes Pig Latin-Programm übersetzen. Allerdings ist hierfür eine komplexere Abfolge von Pig Latin-Befehlen erforderlich, um den entsprechenden LeftJoin zu berechnen. Für die Übersetzung ist es zunächst hilfreich, wenn man die Auswertung des LeftJoins aus Definition 6.1, (,, ), in drei Mengen von Solution Mappings zerlegt: (1) (, (, ) (2) : h (3) : ( ) Die Mengen (1) und (2) von Solution Mappings lassen sich in Pig Latin verhältnismäßig einfach mit Hilfe eines Outer Joins mit anschließendem Filter berechnen. Der Outer Join verknüpft dabei die kompatiblen Mappings und zu einem neuen Mapping =( ) und der Filter prüft, ob µ'' die Filter-Bedingung erfüllt. Probleme bereitet der Fall, falls µ'' den Filter nicht erfüllt. Um in diesem Fall entscheiden zu können, ob µ zur Menge (3) und damit zum Ergebnis des LeftJoins gehört, müssen alle Mappings im Ergebnis des Outer Joins betrachtet werden, die aus µ hervorgegangen sind. Falls keines dieser Mappings den Filter erfüllt, so gehört µ zum Ergebnis des LeftJoins, andernfalls nicht. Eine isolierte Betrachtung von µ'' reicht daher nicht aus, um dies entscheiden zu können. Pig Latin ist allerdings hauptsächlich für die tupelweise Verarbeitung von Daten entworfen, wobei zwischen den Tupeln möglichst keine Abhängigkeiten existieren sollten. Da Mappings in Form von Tupeln modelliert werden, ist die gewünschte Unabhängigkeit bei der Verarbeitung hier nicht gegeben. Das folgende Beispiel soll dies verdeutlichen. Beispiel: P7 = LeftJoin(A, B,?var2 = x &&?var3 < 10) (7)?var1?var2?var1?var3 = µ 11 : a x = µ 21 : a 5 µ 12 : a y µ 22 : a 10 µ 13 : b x

56 5 Übersetzung von SPARQL nach Pig Latin 56 Der Outer Join von A und B auf der gemeinsamen Variable?var1 liefert dann folgendes Ergebnis:?var1?var2?var3 µ 1 : a x 5 µ 2 : a x 10 µ 3 : a y 5 µ 4 : a y 10 µ 5 : b x Die Mappings µ 1 und µ 5 gehören zur Menge (1) bzw. (2) und können somit unverändert zum Ergebnis des LeftJoins hinzugenommen werden. Die Mappings µ 2, µ 3 und µ 4 erfüllen die Filter-Bedingung allerdings nicht und sind daher problematisch. Hier zeigen sich beide Varianten, die in diesem Fall auftreten können. Das Mapping µ 11 gehört nicht zur Menge (3) und damit zum Ergebnis des LeftJoins, da das Mapping =( ), welches ebenfalls aus µ 11 hervorgegangen ist, den Filter erfüllt. Da allerdings weder =( ) noch =( ) den Filter erfüllen, gehört µ 12 zur Menge (3). Die korrekte Auswertung des LeftJoins führt dementsprechend zu folgendem Ergebnis:?var1?var2?var3 = µ 1 : a x 5 µ 2 : a y µ 3 : b x Abbildung 25 zeigt die Übersetzung von P7 in eine Folge von Pig Latin- Befehlen unter der Annahme, dass die Solution Mappings für die Pattern A und B in den Relationen A, B mit den Schemata (var1,var2) und (var1,var3) zur Verfügung stehen.

57 5 Übersetzung von SPARQL nach Pig Latin 57 C = JOIN A BY var1 LEFT OUTER, B BY var1 ; (1) D = FOREACH C GENERATE A::var1 AS var1, A::var2 AS var2, B::var3 AS var3 ; SPLIT D INTO (2) P7 IF (var3 is null) OR (var2=='x' AND var3<10), E IF (var3 is not null) AND NOT(var2=='x' AND var3<10); F = FOREACH E GENERATE var1, var2 ; (3) G = DISTINCT F ; H = JOIN G BY (var1,var2) LEFT OUTER, P7 BY (var1,var2) ; I = FOREACH H GENERATE G::var1 AS var1, G::var2 AS var2, P7::var3 AS var3 ; J = FILTER I BY var3 is null ; P7 = UNION P7, J ; (4) Abbildung 25: Übersetzung von LeftJoin mit unsicherem Filter (1) Zunächst wird der Outer Join der beiden Relationen berechnet und mit einem anschließenden Foreach die überflüssigen Spalten entfernt sowie das Schema aktualisiert. (2) Im zweiten Teil werden die Mappings, welche die Filter-Bedingung erfüllen oder Null-Werte enthalten mit Hilfe von Split von den übrigen Mappings getrennt. Sie können direkt zur Ergebnismenge (P7) hinzugenommen werden, da sie den Mengen (1) und (2) entsprechen. Die übrigen Mappings (E) entsprechen den problematischen Fällen, da sie weder den Filter erfüllen noch Null-Werte enthalten. (3) Im dritten Schritt müssen diejenigen Mappings µ aus A identifiziert werden, zu denen es zwar kompatible Mappings µ' aus B gibt, jedoch keine Verknüpfung ( ) die Filter-Bedingung erfüllt. In diesem Fall muss µ ebenfalls zum Ergebnis hinzugefügt werden. Diese Mappings lassen sich aus der Relation E berechnen, da in E alle Verknüpfungen von kompatiblen Mappings enthalten sind, die den Filter nicht erfüllen. Zunächst werden die in E enthaltenen Mappings aus A rekonstruiert, indem E auf die Variablen aus A projiziert wird und anschließend Duplikate mittels Distinct entfernt werden. Als Ergebnis bekommt man in der Relation G alle Mappings µ aus A, zu denen es ein kompatibles Mapping µ' aus B gibt, sodass ( ) den Filter nicht erfüllt. Von den Mappings aus G dürfen allerdings nur diejenigen zum Ergebnis des LeftJoins hinzugenommen werden, für die es überhaupt kein

58 5 Übersetzung von SPARQL nach Pig Latin 58 kompatibles Mapping aus B gibt, sodass die Verknüpfung den Filter erfüllt. Diese Mappings können durch einen Outer Join mit P7 ermittelt werden. Gibt es für ein Mapping µ aus G keinen Verbundpartner (kompatibles Mapping) in P7, so gehört µ zum Ergebnis des LeftJoins hinzu. (4) Abschließend müssen die so identifizierten Mappings (J) nur noch zu den Mappings aus P7 hinzugefügt werden, um das endgültige Ergebnis des LeftJoins zu erhalten. Bei der Evaluation (Kapitel 8) wurde ein Fehler in Pig entdeckt, der zu falschen Berechnungen bei der angegebenen Übersetzung eines LeftJoin mit unsicherem Filter führt. Das Problem wird durch den Filter zur Berechnung der Relation J hervorgerufen, der das Ergebnis des Outer Joins (I) nach Null-Werten filtert. Pig scheint hier gewisse Optimierungen (Vorziehen des Filters) vorzunehmen, die nicht zulässig sind. Der Fehler lässt sich auch leicht mit anderen Beispielen reproduzieren und wurde in einer Diskussion über die Mailing-Liste von Pig auch von anderen Anwendern und Entwicklern bestätigt. In Pig scheint der Fehler allerdings nicht mehr vorhanden zu sein. Um das Problem zu umgehen, kann der Filter- Befehl durch einen Split-Befehl ersetzt werden, wobei der zweite Teil des Splits ungenutzt verworfen werden kann: SPLIT I INTO J IF var3 is null, Trash IF var3 is not null; Union Der Union-Operator der SPARQL Algebra fasst zwei Multi-Mengen von Solution Mappings zu einer Multi-Menge zusammen. Damit lassen sich folglich die Ergebnisse von zwei Graph Patterns vereinigen. Definition 7. Sei G ein RDF-Graph und P, P' zwei beliebige Graph Patterns. Die Auswertung von Union auf P und P', (, ), ist definiert als die Menge der Solution Mappings (, ) =. Beispiel: P8 = Union(BGP(?A knows Bob.?A mbox?b), (8) BGP(?A knows John)) Das linke Pattern (P) liefert alle Personen, die Bob kennen und deren - Adresse bekannt ist. Das rechte Pattern (P') hingegen liefert alle Personen, die John kennen, unabhängig von einer -adresse.

59 5 Übersetzung von SPARQL nach Pig Latin 59?A?B?A = µ 1 : Peter = µ 1 : Peter µ 2 : Sarah µ 3 : Alice = µ 1 : Peter µ 2 : Sarah µ 3 : Alice µ 4 : Peter Tabelle 15: Auswertung von Union Pig Latin Wohlgeformte SPARQL-Anfragen enthalten per Definition keine Union- Patterns. Um jedoch alle Anfragen aus dem SP 2 Bench (siehe Abschnitt 8) zu unterstützen, wurde die Übersetzung des Union-Operators dennoch betrachtet. Die Übersetzung ist allerdings mit einigen Einschränkungen verbunden. Obwohl der Union-Operator zunächst relativ unproblematisch wirkt, können bei der Übersetzung dieselben Probleme wie beim LeftJoin auftreten. Auch hier kann für zwei Mappings und gelten, dass ( ) ( ). Daher können in den Solutions Mappings zum Union von P und P' ungebundene Variablen existieren (siehe µ 4 in Tabelle 15), die in Pig in Form von Null- Werten repräsentiert werden. Dies kann allerdings zu der bereits beschriebenen Problematik eines Joins über Null-Werten führen. Unproblematisch ist der Union-Operator dann, wenn beide Eingabe- Relationen das gleiche Schema aufweisen, d.h. gleiche Anzahl an Spalten mit den gleichen Namen. In diesem Fall können die beiden Relationen einfach mit Union zu einer neuen Relation verbunden werden, die das Schema der Eingabe-Relationen übernimmt. Falls die beiden Relationen allerdings unterschiedliche Schemata aufweisen, so muss zunächst eine Vorverarbeitung erfolgen. Zwar können in Pig Latin mit Union auch Relationen mit unterschiedlichen Schemata zusammengeführt werden, allerdings gehen dabei die Schemata der beiden Relationen verloren, da die Ergebnis-Relation weder das Schema der einen noch das Schema der anderen Relation übernehmen kann. Da die Variablen- Namen der Mappings in einer Relation allerdings im Schema der Relation defi-

60 5 Übersetzung von SPARQL nach Pig Latin 60 niert sind, wäre dies äußerst problematisch. Daher müssen zunächst die Schemata der beiden Relationen mit Hilfe von Foreach aneinander angepasst werden, indem für ungebundene Variablen Null-Werte eingeführt werden. Im Beispiel von P8 muss z.b. zunächst das Schema der rechten Relation an das Schema der linken Relation angepasst werden. Abbildung 26 zeigt die Übersetzung von P8 unter der Annahme, dass die Ergebnisse der beiden BGPs in den beiden Relationen BGP1 und BGP2 mit den Schemata (A,B) bzw. (A) vorliegen. BGP2 = FOREACH BGP2 GENERATE A, null AS B ; P8 = UNION BGP1, BGP2 ; Abbildung 26: Übersetzung von Union ToList Das Graph Pattern einer SPARQL-Anfrage setzt sich aus den Operatoren der SPARQL Algebra zusammen und liefert als Ergebnis eine Multi-Menge von Solution Mappings. Diese hat per Definition allerdings keine definierte Ordnung, was aus formalen Gesichtspunkten jedoch z.b. für die Definition einer Sortierung erforderlich ist. ToList generiert daher aus der Multi-Menge von Solution Mappings zu einem Graph Pattern eine Sequenz von Solution Mappings Ψ in beliebiger Reihenfolge. Alle weiteren Solution Modifier operieren dann auf einer Sequenz von Solution Mappings mit definierter Ordnung. In Pig werden die Solution Mappings zu einem Graph Pattern in Form von Tupeln in einer Relation repräsentiert und enthalten somit bereits eine implizite Ordnung. Eine explizite Übersetzung von ToList ist somit nicht erforderlich OrderBy Mit Hilfe von OrderBy kann eine Sequenz von Solution Mappings in eine gewünschte Reihenfolge gebracht werden. Dazu wird die Sequenz nach den Inhalten einer oder mehrerer Variablen in auf- oder absteigender Reihenfolge sortiert. In Pig Latin kann hierfür der Order By-Befehl verwendet werden. Definition 8. Sei Ψ eine Sequenz von Solution Mappings und C eine Sortierungsvorschrift. Die Auswertung von OrderBy auf Ψ, (Ψ, ), ist definiert als die Sequenz von Solution Mappings (Ψ, ) = [ Ψ] und (Ψ, ) h.

61 5 Übersetzung von SPARQL nach Pig Latin 61 Beispiel: P9 = OrderBy(P8, ASC(?A)) (9)?A?B = µ 1 : Alice µ 2 : Peter µ 3 : Peter µ 4 : Sarah Tabelle 16: Auswertung von OrderBy P9 = ORDER P8 BY A DESC ; Abbildung 27: Übersetzung von OrderBy Project Bei Select-Anfragen kann der Anwender spezifizieren, welche Variablen, die in der Anfrage vorkommen, auch in der Ausgabe enthalten sein sollen. Bei SE- LECT * werden alle Variablen in die Ausgabe aufgenommen, bei SELECT?A?B z.b. nur die Variablen?A und?b. Eine Projektion kann in Pig Latin mit Hilfe von Foreach ausgedrückt werden. Definition 9. Sei PV eine Menge von Variablen und Ψ eine Sequenz von Solution Mappings. Die Auswertung von Project auf Ψ, (Ψ, ), ist definiert als die Sequenz von Solution Mappings (Ψ, ) = [ Ψ h ä ]. Beispiel: P10 = Project(P9,?A) (10)?A = µ 1 : Alice µ 2 : Peter µ 3 : Peter µ 4 : Sarah Tabelle 17: Auswertung von Project P10 = FOREACH P9 GENERATE A ; Abbildung 28: Übersetzung von Project

62 5 Übersetzung von SPARQL nach Pig Latin Distinct Es kann sein, dass ein Solution Mapping mehrfach in einer Sequenz von Solution Mappings enthalten ist. Distinct entfernt diese Duplikate, so dass jedes Mapping nur ein Mal in der Sequenz vorkommt. In Pig Latin lässt sich dies direkt mit Hilfe von Distinct ausdrücken. Definition 10. Sei Ψ eine Sequenz von Solution Mappings und bezeichne [Ψ]( ) die Kardinalität von µ in Ψ. Die Auswertung von Distinct auf Ψ, (Ψ), ist definiert als die Sequenz von Solution Mappings (Ψ) = [ Ψ ] mit [ (Ψ) ]( ) =1. Beispiel: P11 = Distinct(P10) (11)?A = µ 1 : Alice µ 2 : Peter µ 3 : Sarah Tabelle 18: Auswertung von Distinct P11 = DISTINCT P10 ; Abbildung 29: Übersetzung von Distinct Reduced Die Funktion von Reduced ähnelt der von Distinct. Im Gegensatz zu Distinct werden allerdings nicht unbedingt alle Duplikate entfernt. Die Definition des W3C ist an dieser Stelle äußerst ungenau und besagt lediglich, dass Duplikate entfernt werden dürfen, sie können allerdings auch erhalten bleiben. Aus diesem Grund wird Reduced daher bei der Übersetzung in Pig Latin wie Distinct behandelt, d.h. sämtliche Duplikate werden entfernt. Definition 11. Sei Ψ eine Sequenz von Solution Mappings und bezeichne [Ψ]( ) die Kardinalität von µ in Ψ. Die Auswertung von Reduced auf Ψ, (Ψ), ist definiert als die Sequenz von Solution Mappings (Ψ) = [ Ψ ] mit 1 [ (Ψ) ]( ) [Ψ]( ).

63 5 Übersetzung von SPARQL nach Pig Latin 63 Beispiel: P12 = Reduced(P10) (12) P12 = DISTINCT P10 ; Abbildung 30: Übersetzung von Reduced Slice Slice ist eine Kombination aus Limit und Offset. Ein Limit von 10 begrenzt die Anzahl der ausgegebenen Solution Mappings auf 10, während ein Offset von 10 die ersten 10 Solution Mappings in der Sequenz überspringt. Die Anzahl an Tupeln in einer Relation lassen sich in Pig Latin mit Hilfe von Limit begrenzen. Für Offset gibt es allerdings keine Entsprechung in Pig Latin. Aus diesem Grund wird der Offset-Wert x zum Wert von Limit hinzugezählt. Die ersten x Mappings der Ausgabe müssen dann ignoriert werden. Definition 12. Sei Ψ eine Sequenz von Solution Mappings und Ψ[ ] das i- te Solution Mapping in der Sequenz Ψ. Die Auswertung von Slice auf Ψ, (Ψ, start, length), ist definiert als die Sequenz von Solution Mappings (Ψ, start, length) =Ψ[ + ] ü = 0 ( h 1). Beispiel: P13 = Slice(P10,1,2) (13) P13 = LIMIT P10 3; Abbildung 31: Übersetzung von Slice 5.4 Beispiel Im Folgenden soll die dargestellte Übersetzung anhand eines zusammenhängenden Beispiels illustriert werden. Die SPARQL-Anfrage aus Abbildung 32 (A6) liefert als Ergebnis alle Personen, die entweder "Paul" kennen und nicht älter als 30 sind oder die "Bob" kennen (inklusive optionaler -adresse), aufsteigend sortiert nach ihrem Alter. Abbildung 33 zeigt den entsprechenden SPARQL Algebra-Baum zur Anfrage, der die Grundlage für die Übersetzung bildet und Tabelle 19 beinhaltet das Ergebnis der Auswertung.

64 5 Übersetzung von SPARQL nach Pig Latin 64 PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX ex: <http://example.org/> SELECT?person?age? WHERE { {?person foaf:knows ex:bob.?person foaf:age?age OPTIONAL {?person foaf:mbox? } } UNION {?person foaf:knows ex:paul.?person foaf:age?age FILTER (?age <= 30) } } ORDER BY ASC(?age) Abbildung 32: komplexe SPARQL-Anfrage (A6) OrderBy?age ASC ToList Union LeftJoin Filter?age <= 30 BGP (1)?person knows Bob?person age?age BGP (2)?person mbox? BGP (3)?person knows Paul?person age?age Abbildung 33: SPARQL Algebra-Baum zu A6 Zur Übersetzung des Algebra-Baums in eine Folge von Pig Latin-Befehlen wird der Baum von unten nach oben traversiert und die Übersetzung der einzelnen Komponenten zusammengefügt. Das Ergebnis des Übersetzungs-Prozesses ist in Abbildung 34 dargestellt.

65 5 Übersetzung von SPARQL nach Pig Latin 65?person?age? µ 1 : Sarah 24 µ 2 : Sarah 24 µ 3 : John 29 µ 4 : Alice 30 µ 5 : Peter 38 Tabelle 19: Ergebnis von A6 indata = LOAD 'pathtofile' USING rdfloader() AS (s,p,o) ; -- BGP (1) t1 = FILTER indata BY p == 'foaf:knows' AND o == 'ex:bob' ; t2 = FILTER indata BY p == 'foaf:age' ; j1 = JOIN t1 BY s, t2 BY s ; BGP1 = FOREACH j1 GENERATE t1::s AS person, t2::o AS age ; -- BGP (2) t1 = FILTER indata BY p == 'foaf:mbox' ; BGP2 = FOREACH t1 GENERATE s AS person, o AS ; -- LeftJoin j1 = JOIN BGP1 BY person LEFT OUTER, BGP2 BY person ; LJ = FOREACH j1 GENERATE BGP1::person AS person, BGP1::age AS age, BGP2:: AS ; -- BGP (3) t1 = FILTER indata BY p == 'foaf:knows' AND o == 'ex:paul' ; t2 = FILTER indata BY p == 'foaf:age' ; j1 = JOIN t1 BY s, t2 BY s ; BGP3 = FOREACH j1 GENERATE t1::s AS person, t2::o AS age ; -- Filter F = FILTER BGP3 BY age <= 40 ; -- Union u1 = FOREACH F GENERATE person, age, null AS ; U = UNION LJ, u1 ; -- OrderBy OB = ORDER U BY age ASC STORE OB INTO 'pathtofile' ; Abbildung 34: Pig Latin-Übersetzung einer SPARQL-Anfrage

66 6 Optimierungen 66 6 Optimierungen In diesem Kapitel werden einige Optimierungsansätze für die Übersetzung aus Kapitel 5 dargestellt. Bei den ersten Evaluationen hat sich gezeigt, dass eine Optimierung vor allem die Reduktion des Datenaufkommens (Input/Output, I/O) zum Ziel haben sollte. Das beinhaltet zum einen die Daten, welche innerhalb eines MapReduce-Jobs von den Mappern zu den Reducern übertragen werden und zum anderen die Daten, welche zwischen zwei MapReduce-Jobs in das verteilte Dateisystem, HDFS, übernommen werden müssen (siehe Abbildung 35). Map IO Reduce IO IO IO HDFS Map Reduce Abbildung 35: IO-Datenfluss in Hadoop Bei der Optimierung wurden drei verschiedene Ebenen betrachtet, die auf das Datenaufkommen in einer Folge von MapReduce-Jobs einen Einfluss haben können: (1) SPARQL Algebra. Eine SPARQL-Anfrage wird vor der Auswertung in einen SPARQL Algebra-Baum überführt (siehe Abschnitt 3.3). Da die Übersetzung in Pig Latin auf der Ebene der SPARQL-Algebra definiert ist, wirkt sich eine Optimierung des Algebra-Baums auch positiv auf die Auswertung der Anfrage in Pig Latin aus. (2) Übersetzung der SPARQL Algebra. Die dargestellte Übersetzung aus Kapitel 5 lässt einige Aspekte von Pig Latin unbetrachtet, die eine Reduktion des Datenaufkommens ermöglichen. (3) Datenmodell. Es ist naheliegend, zur Reduktion des Datenaufkommens bei der Anfrage-Auswertung in Pig Latin auch die Repräsentation der RDF-Daten zu betrachten.

67 6 Optimierungen Optimierung der SPARQL Algebra Die Optimierung von Anfragen spielt in Datenbanksystemen eine bedeutende Rolle. So wurden z.b. im Laufe der Jahre viele Optimierungsstrategien für die relationale Algebra entworfen. Allerdings lassen sich diese Strategien nicht eins zu eins auf die SPARQL Algebra übertragen. Eine ausführliche Einführung in die Problematik der Anfrage-Optimierung in SPARQL findet sich z.b. in der Arbeit von Michael Schmidt [Schmidt, et al., 2010]. Die in dieser Arbeit verwendeten Ansätze wurden hauptsächlich den Arbeiten von Bernstein et al. [Bernstein, et al., 2007] und Stocker et al. [Stocker, et al., 2008] entnommen. Die Optimierung der SPARQL Algebra hat den Vorteil, dass die Übersetzung der Algebra in ein Pig Latin-Programm davon unberührt bleibt. Es können folglich in der Zukunft weitere Optimierungen betrachtet werden, die in dieser Arbeit nicht berücksichtigt wurden, ohne die dargestellte Übersetzung deswegen verändern zu müssen. Die Auswertung einer SPARQL-Anfrage in Pig Latin profitiert somit direkt von den Optimierungen auf der Ebene der SPARQL Algebra. Ziel der Algebra-Optimierungen ist es, die bei der Auswertung der Anfrage generierten Zwischenergebnisse zu minimieren, da eine Minimierung der Zwischenergebnisse auch eine Reduktion des Datenaufkommens bedeutet. Hierfür wurden Optimierungen des Filter- und des BGP-Operators der SPARQL- Algebra betrachtet Filter Optimierung Wenn man sich über die Reduktion von Zwischenergebnissen Gedanken macht, so kommt offensichtlich die Betrachtung des Filter-Operators der SPARQL- Algebra in Frage. Dabei versprechen insbesondere zwei Ansätze eine deutliche Reduktion der erzeugten Zwischenergebnisse, zum einen die Substitution von Filter-Variablen und zum anderen das Verschieben des Filter-Operators innerhalb des Algebra-Baums. Beide Ansätze werden im Folgenden anhand zweier einfacher Beispiele erläutert. Substitution von Filter-Variablen Die Idee der Substitution von Filter-Variablen besteht darin, dass eine Variable in einem Triple-Pattern unter Umständen ersetzt werden kann, um so den Filter zu vereinfachen oder sogar überflüssig zu machen.

68 6 Optimierungen 68 Filter?B = "Bob" &&?age >= 18 Filter?age >= 18 BGP?A knows?b.?a age?age BGP?A knows Bob.?A age?age Abbildung 36: Variablen-Substitution beim Filter Abbildung 36 zeigt einen Ausschnitt aus einem SPARQL Algebra-Baum, der eine Substitution der Variablen?B im BGP durch den Wert "Bob" ermöglicht. Bei der Auswertung des BGP werden zunächst die Ergebnisse der beiden Triple-Patterns über einen Join verknüpft. Es ist offensichtlich klar, dass eine möglichst frühe Beschränkung der Ergebnisse des ersten Triple-Patterns effizienter ist als die ungewünschten Ergebnisse erst im Anschluss an den Join herauszufiltern. Allerdings ist die Anwendbarkeit dieser Optimierung an einige Bedingungen geknüpft. So müssen die Ausdrücke im Filter mit AND (&&) verknüpft sein, da eine Substitution ansonsten die Semantik der Anfrage verändern würde. Darüber hinaus ist eine Substitution nur dann möglich, wenn die Variable im Filter-Ausdruck über den Gleichheits-Operator (=) gebunden ist. Außerdem muss gewährleistet sein, dass die Variable nirgendwo sonst im Algebra-Baum vorkommt und insbesondere nicht Teil der Ausgabe ist. Verschieben des Filter-Operators Eine weitere Möglichkeit, die Menge der erzeugten Zwischenergebnisse in einer Anfrage zu reduzieren, besteht in der möglichst frühen Anwendung des Filter- Operators. Dabei wird der Filter-Operator im Algebra-Baum so weit wie möglich nach unten verschoben. Abbildung 37 zeigt eine Verschiebung des Filter-Operators im Algebra- Baum. Dabei wird der Filter in zwei Teile aufgetrennt und vor der Ausführung des LeftJoin platziert, wodurch die Eingabe für den LeftJoin deutlich reduziert wird. Eine Auftrennung des Filters ist allerdings nur möglich, wenn die Ausdrücke im Filter mit AND (&&) verknüpft sind, da ansonsten die Semantik der Anfrage verändert wird.

69 6 Optimierungen 69 Filter?B = "Bob" &&?age >= 18 LeftJoin LeftJoin Filter?B = "Bob" Filter?age >= 18 BGP BGP BGP BGP?A knows?b?a age?age?a knows?b?a age?age Abbildung 37: Verschieben des Filter-Operators BGP Optimierung Ein BGP besteht aus einer Menge von Triple-Patterns. Zur Auswertung des BGPs in Pig Latin müssen die Ergebnisse der einzelnen Triple-Patterns sukzessive über Joins zu einem Gesamtergebnis verknüpft werden (siehe Abschnitt 5.3.1). Da hierfür bei einem BGP mit n Triple-Patterns insgesamt (n-1) Joins erforderlich sind, wird offensichtlich klar, dass die Auswertung der BGPs in einer Anfrage mitunter den größten Aufwand verursacht, abhängig von der Anzahl der Triple-Patterns in einem BGP. Daher verspricht die Optimierung der Auswertung von BGPs einen erheblichen Einfluss auf den Gesamtaufwand der Anfrage. Die Übersetzung aus Kapitel 5 verknüpft die Triple-Patterns in einem BGP in der Reihenfolge, wie sie im BGP definiert sind. Die Reihenfolge der Triple- Patterns in einem BGP hat allerdings keine Auswirkung auf die Semantik und ist insofern beliebig. Die Optimierung eines BGPs besteht daher aus einer Neuanordnung der Triple-Patterns, sodass die erzeugten Zwischenergebnisse möglichst reduziert werden. Das grundlegende Konzept hierfür basiert auf der Selektivität eines Triple-Patterns, die analog zur Selektivität einer Bedingung nach Piatetsky et al. [Piatetsky-Shapiro, et al., 1984] definiert werden kann. Definition Die Selektivität eines Triple-Patterns T, bezeichnet mit sel(t), ist der Anteil von RDF-Tripeln in einem RDF-Datensatz, die T erfüllen. Definition Die Selektivität eines Subjekts S, Prädikats P oder Objekts O, bezeichnet mit sel(s), sel(p) und sel(o), ist der Anteil von RDF-Tripeln in einem RDF-Datensatz, die S, P oder O enthalten.

70 6 Optimierungen 70 Zur Reduktion der Zwischenergebnisse werden die Triple-Patterns dann nach aufsteigender Selektivität geordnet, d.h. ( ) ( ). Da die Selektivität eines Triple-Patterns allerdings unbekannt und ihre exakte Berechnung die Auswertung des Patterns erfordern würde, kommen in der Regel Heuristiken zur Abschätzung zum Einsatz. Viele Heuristiken beruhen dabei auf statistischen Informationen über den entsprechenden RDF-Datensatz, auf dem die Anfrage ausgewertet werden soll. Variable Counting Die in dieser Arbeit betrachtete einfache Heuristik zur Abschätzung der Selektivität eines Triple-Patterns, auch als Variable Counting bezeichnet, verwendet keine statistischen Informationen und kann daher ohne weitere Voranalyse des Datensatzes angewendet werden. Die Selektivität wird dabei über die Anzahl und die Position der Variablen im Triple-Pattern abgeschätzt, d.h. für zwei Triple-Patterns T (eine Variable), T' (zwei Variablen) ist ( ) < ( ). Für den Fall, dass zwei Triple-Patterns gleich viele Variablen enthalten, werden die Komponenten des Triple-Patterns betrachtet, die keine Variable enthalten und somit gebunden sind. Dabei wird angenommen, dass ( ) < ( ) und ( ) < ( ) gilt, da in einem typischen RDF-Datensatz im Regelfall mehr Tripel zu einem gewissen Prädikat existieren als zu einem Subjekt oder Objekt. Bei Subjekten und Objekten ist eine Aussage über die Verhältnisse deutlich schwieriger und kann von Datensatz zu Datensatz variieren. Die Heuristik geht allerdings davon aus, dass Subjekte im Allgemeinen selektiver sind als Objekte, d.h. ( ) < ( ). Abbildung 38 zeigt die Neuordnung eines BGPs basierend auf der geschätzten Selektivität eines Triple-Patterns nach der Variable Counting-Heuristik. Das ursprünglich erste Triple-Pattern wird dabei ganz nach hinten geschoben, da es zwei Variablen enthält und somit wahrscheinlich viele Ergebnisse liefert. Das letzte Triple-Pattern wird hingegen ganz nach oben geschoben, da es nur eine Variable enthält. Das zweite Triple-Pattern beinhaltet zwar auch nur eine Variable, doch das Subjekt "Bob" wird selektiver eingeschätzt als das Objekt "Peter". BGP?A knows?b.?a knows Peter. Bob knows?b BGP Bob knows?b.?a knows Peter.?A knows?b Abbildung 38: Triple-Pattern-Anordnung nach Selektivität

71 6 Optimierungen 71 Vermeidung von Kreuzprodukten Eine Neuanordnung der Triple-Patterns in einem BGP, die sich nur an der Selektivität orientiert, lässt allerdings den Typ des Verbunds (Join oder Kreuzprodukt) gänzlich außer Acht. Die Neuanordnung in Abbildung 38 führt so beispielsweise dazu, dass das Kreuzprodukt zwischen den Ergebnissen (Solution Mappings) der ersten beiden Triple-Patterns berechnet werden muss, da es keine gemeinsamen Variablen gibt. Dadurch ist jedes Solution Mapping des ersten Triple-Patterns per Definition kompatibel ist zu jedem Solution Mapping des zweiten Triple-Patterns (siehe Definition 2.2 auf Seite 45). Kreuzprodukte sind in der Regel jedoch sehr aufwändig zu berechnen und sollten, wenn irgendwie möglich, vermieden werden. Aus diesem Grund wird bei der Neuanordnung der Triple-Patterns versucht, Kreuzprodukte so weit wie möglich zu umgehen, auch wenn dadurch das Selektivitäts-Kriterium verletzt wird: (1) Als erstes Triple-Pattern wird das selektivste Triple-Pattern gewählt, d.h. es gilt ( ) ( ). (2) Das (i+1)-te Triple-Pattern wird so gewählt, dass nach Möglichkeit kein Kreuzprodukt berechnet werden muss: Sei (.. ) = ( ) und ( ) (.. ). (2.1) Gibt es kein solches Triple-Pattern, dann wird von den restlichen das selektivste Triple-Pattern gewählt. Die Berechnung des Kreuzprodukts lässt sich somit nicht vermeiden. (2.2) Gibt es mehrere Triple-Patterns, die die gewünschte Eigenschaft erfüllen (Kandidaten), so wird von den Kandidaten das selektivste Triple-Pattern gewählt. Abbildung 39 zeigt die Neuanordnung des BGPs aus Abbildung 38 nach dem vorgestellten Schema. Obwohl das Triple-Pattern mit den beiden Variablen am wenigsten selektiv ist, wird es an die zweite Stelle im neu geordneten BGP übernommen, da die Vermeidung des Kreuzprodukts wichtiger ist als die Einhaltung der Selektivität. BGP?A knows?b.?a knows Peter. Bob knows?b BGP Bob knows?b.?a knows?b.?a knows Peter Abbildung 39: BGP-Optimierung

72 6 Optimierungen Optimierung der Übersetzung Die Übersetzung eines BGPs in eine Folge von Pig Latin-Befehlen, wie sie in Abschnitt vorgestellt wird, lässt einige Aspekte von Pig Latin unbetrachtet, welche eine Reduktion des Datenaufkommens ermöglichen. So werden z.b. viele unnötige Daten erst ganz am Schluss durch die Projektion mit Hilfe von Foreach aus dem Ergebnis entfernt. Das macht die Übersetzung zwar übersichtlich, ist aus Effizienzgründen aber nicht zu empfehlen. Die Dokumentation von Pig Latin schreibt zur Optimierung von Pig Latin- Programmen unter anderem eine Strategie vor, die als "Project Early and Often" 22 bezeichnet wird. Darunter versteht man das Entfernen von unnötigen Daten, sobald diese nicht mehr gebraucht werden. Bei der Auswertung eines BGPs in Pig Latin lässt sich diese Strategie an zwei Stellen anwenden: (1) Die Matchings zu den einzelnen Triple-Patterns werden jeweils durch die Anwendung von Filter selektiert. Die gebundenen Komponenten, die Bestandteil des Filters waren, können anschließend allerdings entfernt werden, da nur die Werte der Variablen zur weiteren Auswertung benötigt werden. Dadurch wird die Menge an Daten reduziert, die in der Shuffle-Phase von den Mappern zu den Reducern transportiert werden muss. (2) Im Ergebnis eines Joins in Pig Latin kommen die Spalten der Join- Prädikate mehrfach vor (ein Mal für jede Relation des Joins). Anstatt die überflüssigen Spalten durch alle Joins durchzuschleifen und erst am Schluss zu löschen, sollten diese besser unmittelbar nach dem Join mit einem Foreach entfernt werden. Auf diese Weise wird die Menge an Daten reduziert, die zwischen zwei MapReduce-Jobs im HDFS gespeichert werden muss. Neben der Reduzierung des Datenaufkommens durch das Entfernen unnötiger Daten, können bei der Übersetzung eines BGPs auch einige Optimierungen innerhalb von Pig ausgenutzt werden. So wird bei der Implementierung eines Joins in Pig Latin die letzte Relation nicht vollständig in den Arbeitsspeicher geladen, sondern vielmehr portionsweise durchgeschoben (Streaming). Aus diesem Grund sollte die größte Relation in einem Join immer ganz hinten stehen. Da die Größe einer Relation aber grundsätzlich unbekannt ist, kommt eine einfache Heuristik zum Einsatz: Da davon ausgegangen werden kann, dass die 22 siehe hierzu "Performance Enhancer" im "Pig Cookbook" [Apache Software Foundation, 2010].

73 6 Optimierungen 73 Größe einer Relation mit einer zunehmenden Anzahl an Joins wächst, wird die Ergebnis-Relation eines Joins im folgenden Join als letzte Relation verwendet. Pig Latin bietet die Möglichkeit, mehrere Joins zu einem Join zusammenzufassen (Multi-Join), falls sie sich auf die gleichen Werte (hier: gleiche Variablen) beziehen. Die Auswertung eines Multi-Joins ist dabei effizienter als die entsprechende Folge von normalen Joins, da er mit nur einem MapReduce-Job berechnet werden kann, wohingegen eine Folge von n normalen Joins auch n MapReduce-Jobs erfordert. Ist das Zusammenfassen mehrerer Joins möglich, so kann folglich die Anzahl der benötigten MapReduce-Jobs zur Auswertung des BGPs reduziert werden. In der Evaluation hat sich bestätigt, dass dadurch eine signifikante Reduzierung der Ausführungszeit erreicht werden kann. Bei der optimierten Übersetzung werden daher alle Joins, die sich auf die gleichen Variablen beziehen, zu einem Multi-Join zusammengefasst. P1 = BGP(?A knows Bob.?A age?b.?a mbox?c) graph = LOAD 'pathtofile' USING rdfloader() AS (s,p,o) ; f1 = FILTER graph BY p == 'knows' AND o == 'Bob' ; t1 = FOREACH f1 GENERATE s AS A ; f2 = FILTER graph BY p == 'age' ; t2 = FOREACH f2 GENERATE s AS A, o AS B ; f3 = FILTER graph BY p == 'mbox' ; t3 = FOREACH f3 GENERATE s AS A, o AS C ; j1 = JOIN t1 BY A, t2 BY A, t3 BY A ; P1 = FOREACH j1 GENERATE t1::a AS A, t2::b AS B, t3::c AS C ; Abbildung 40: optimierte Übersetzung eines BGPs Abbildung 40 zeigt die optimierte Übersetzung des BGPs aus Abschnitt Nach jedem Filter werden die unnötigen Spalten gelöscht und bei der Gelegenheit auch gleich das Schema angepasst (Variablennamen als Alias für die Spalten der Relation). Die beiden Joins aus der nicht optimierten Variante können zu einem Multi-Join zusammengefasst werden, da sie sich auf die gleiche Variable?A beziehen. Ein abschließendes Foreach entfernt die überflüssigen Spalten im Ergebnis des Joins und passt das endgültige Schema für die Ergebnis-Relation an.

74 6 Optimierungen Optimierung des Datenmodells Wie in Abschnitt 5.2 dargestellt wird, kann ein RDF-Datensatz (RDF-Graph) in Pig als flache Relation mit drei Spalten für Subjekt, Prädikat und Objekt repräsentiert werden. Diese sehr einfache Form der Darstellung hat allerdings den großen Nachteil, dass bei der Auswertung eines Triple-Patterns der entsprechende Filter immer auf alle Tripel im RDF-Datensatz angewendet werden muss. Das ist natürlich insbesondere bei großen Datensätzen eine sehr aufwändige Prozedur, die bei mehreren Triple-Patterns sogar wiederholt zur Anwendung kommt. Obwohl viele SPARQL-Anfragen sich nur auf einen kleinen Ausschnitt des RDF-Graphen beziehen, müssen sie jedoch wegen der Repräsentation des Graphen in einer einzigen Relation auf dem gesamten Datensatz ausgewertet werden. In einem Triple-Pattern können Variablen zwar an einer beliebigen Stelle (Subjekt, Prädikat oder Objekt) vorkommen, betrachtet man eine typische SPARQL-Anfrage jedoch genauer, so sind die Prädikate in den Triple-Patterns meistens gebunden (z.b.?a knows?b). Die Auswertung eines Triple-Patterns könnte somit in den meisten Fällen deutlich vereinfacht werden, wenn der RDF-Graph nicht als ein einziger zusammenhängender Datensatz, sondern nach Prädikaten unterteilt im HDFS vorliegen würde. Man nennt eine solche Aufteilung der RDF-Daten nach Prädikaten auch vertikale Partitionierung [Abadi, et al., 2007]. Bei der Auswertung eines Triple-Patterns mit gebundenem Prädikat müsste der Filter dann nicht mehr auf den gesamten Datensatz angewendet werden, was den Aufwand insbesondere bei nur relativ selten vorkommenden Prädikaten deutlich reduziert. Der Nachteil der vertikalen Partitionierung ist allerdings, dass vor der Auswertung einer Anfrage zunächst eine einmalige Vorverarbeitung des RDF- Datensatzes stattfinden muss, bei der die RDF-Tripel anhand ihrer Prädikate partitioniert werden. Dies lässt sich zwar mit Pig Latin relativ einfach realisieren und somit parallelisiert im Hadoop Framework ausführen, dennoch lohnt sich eine solche Vorverarbeitung für eine einzige Anfrage in der Regel nicht. Oftmals werden auf einem RDF-Datensatz allerdings über die Zeit viele Anfragen ausgeführt, was den Aufwand für die Vorverarbeitung relativiert. Abbildung 41 zeigt die vertikale Partitionierung eines RDF-Graphen mit drei Prädikaten mit Hilfe von Pig Latin. Jeder Datensatz zu einem Prädikat enthält dabei eine Folge von (Subjekt, Objekt)-Paaren, die den Tripeln im ursprünglichen RDF-Datensatz entsprechen.

75 6 Optimierungen 75 graph = LOAD 'pathtofile' USING rdfloader() AS (s,p,o) ; SPLIT graph INTO p1 IF p == 'knows', p2 IF p == 'age', p3 IF p == 'mbox' ; p1 = FOREACH p1 GENERATE s,o ; p2 = FOREACH p2 GENERATE s,o ; p3 = FOREACH p3 GENERATE s,o ; STORE p1 INTO 'pathtofile/knows' ; STORE p2 INTO 'pathtofile/age' ; STORE p3 INTO 'pathtofile/mbox' ; knows age mbox Peter Peter Peter John John... John Alice Bob Sarah Bob Peter 38 John 29 Sarah 24 Bob 32 Alice Peter Sarah Alice Paul Abbildung 41: Vertikale Partitionierung eines RDF-Graphen Zur Auswertung einer SPARQL-Anfrage auf einem nach Prädikaten partitionierten RDF-Datensatz in Pig Latin, muss die Übersetzung leicht angepasst werden. Die Änderungen betreffen allerdings nur die Übersetzung des BGPs, da nur ein BGP unmittelbar auf dem RDF-Datensatz ausgewertet wird. Anstatt bei einem BGP den kompletten RDF-Datensatz zu laden, werden nur diejenigen Prädikate geladen, die auch in den Triple-Patterns vorkommen. Zur Auswertung eines Triple-Patterns muss der Filter dann nur auf die Relation des entsprechenden Prädikats angewendet werden. Sollten sowohl Subjekt als auch Objekt im Triple-Pattern ungebunden sein, so kann der Filter gänzlich weggelassen werden, da jedes Tripel in der Relation das Pattern erfüllt. Sollte ein Triple-Pattern ein ungebundenes Prädikat enthalten, so muss dieses Pattern auf dem gesamten Datensatz ausgewertet werden, was allerdings nur selten vorkommt. Darüber hinaus sind keine weiteren Änderungen an der Übersetzung eines BGPs erforderlich. Abbildung 42 zeigt die Übersetzung des BGPs aus Abschnitt zur Auswertung auf einem nach Prädikaten partitionierten RDF-Datensatz. Für das

76 6 Optimierungen 76 zweite und dritte Triple-Pattern sind keine Filter mehr erforderlich, da sowohl Subjekt als auch Objekt ungebunden sind. Lediglich für das erste Triple- Pattern ist noch ein zusätzlicher Filter für das gebundene Objekt "Bob" notwendig. P1 = BGP(?A knows Bob.?A age?b.?a mbox?c) knows = LOAD 'pathtofile/knows' USING rdfloader() AS (s,o) ; age = LOAD 'pathtofile/age' USING rdfloader() AS (s,o) ; mbox = LOAD 'pathtofile/mbox' USING rdfloader() AS (s,o) ; f1 = FILTER knows BY o == 'Bob' ; t1 = FOREACH f1 GENERATE s AS A ; t2 = FOREACH age GENERATE s AS A, o AS B ; t3 = FOREACH mbox GENERATE s AS A, o AS C ; j1 = JOIN t1 BY A, t2 BY A, t3 BY A ; P1 = FOREACH j1 GENERATE t1::a AS A, t2::b AS B, t3::c AS C ; Abbildung 42: Übersetzung eines BGPs bei vertikaler Partitionierung

77 7 Implementierung 77 7 Implementierung In diesem Kapitel wird die Implementierung der in Kapitel 5 vorgestellten Übersetzung dargestellt, im Folgenden als PigSPARQL bezeichnet. Dabei wurden auch die in Kapitel 6 vorgestellten Optimierungen übernommen. Die Implementierung erfolgte in der Programmiersprache Java 23. Abbildung 43 zeigt den schematischen Aufbau von PigSPARQL, angefangen von der SPARQL- Anfrage (Eingabe) über die verwendeten internen Strukturen bis hin zum endgültigen Pig Latin-Programm (Ausgabe). Der Aufbau folgt dabei dem grundlegenden Design-Prinzip im Compilerbau. Die Eingabe (hier: SPARQL-Anfrage) wird zunächst in eine unabhängige Zwischensprache (hier: SPARQL Algebra) überführt und diese anschließend in die gewünschte Zielsprache (hier: Pig Latin) übersetzt. Im Folgenden werden die einzelnen Zwischenschritte und verwendeten Techniken näher erläutert. SPARQL-Anfrage SPARQL Syntax-Baum Anfrage parsen lexikalische Analyse Syntax-Überprüfung SPARQL Algebra-Baum Algebra-Optimierungen Algebra Transformation Filter-Substitution Filter-Platzierung Triple-Pattern im BGP neu anordnen PigOp-Baum Übersetzung Traversierung Serialisierung Pig Latin-Programm Abbildung 43: Schema der Übersetzung 23 siehe [http://www.oracle.com/technetwork/java/index.html]

78 7 Implementierung Generierung des SPARQL Algebra-Baums Da die Übersetzung von SPARQL in Pig Latin auf der Ebene der SPARQL Algebra definiert ist, muss eine SPARQL-Anfrage zunächst in einen Ausdruck der SPARQL Algebra überführt werden. Zur Realisierung dieser Überführung wurde ARQ 24 verwendet, eine Open-Source-Implementierung von SPARQL in Java für das Jena Semantic Web Framework 25. ARQ liefert dabei alle Funktionen, die für das Parsen einer Anfrage und die Generierung des Algebra-Baums erforderlich sind. Die Klassen des Algebra- Baums werden von ARQ als "Ops" bezeichnet. Zu jedem Element aus der SPARQL Algebra gibt es eine entsprechende Op-Klasse, die das Element im Algebra-Baum repräsentiert. So entsprechen die Klassen OpBGP, OpLeftJoin und OpUnion beispielweise den Algebra-Operatoren BGP, LeftJoin und Union. Abbildung 44 zeigt eine einfache SPARQL-Anfrage, den entsprechenden Ausdruck in der SPARQL Algebra und den resultierenden Algebra-Baum in ARQ. SELECT * WHERE {?person age?age.?person knows Bob OPTIONAL {?person mbox? } FILTER (?age < 30) } Filter( LeftJoin( BGP(?person age?age.?person knows Bob), BGP(?person mbox? ), true),?age < 30) OpFilter?age < 30 OpLeftJoin OpBGP?person age?age.?person knows Bob OpBGP?person mbox? Abbildung 44: SPARQL Algebra in ARQ 24 siehe [http://jena.sourceforge.net/arq/] 25 siehe [http://jena.sourceforge.net/index.html]

79 7 Implementierung 79 Leider ist die Implementierung der SPARQL Algebra in ARQ nur recht lückenhaft dokumentiert, da der typische Anwender in der Regel nicht mit der Algebra in Kontakt kommt. Der Code ist zwar öffentlich zugänglich, allerdings enthält er so gut wie keine Kommentare. Das erschwert die Entwicklung auf Algebra-Ebene und erfordert eine aufwändige Einarbeitung, da man sich die Aufgabe und Funktionsweise einer Klasse größtenteils selbst herleiten muss. Um Operationen auf dem von ARQ erzeugten Algebra-Baum relativ einfach ausführen zu können, unterstützt die Baum-Struktur von ARQ das aus der Softwareentwicklung bekannte Visitor-Entwurfsmuster (Visitor Pattern). Im nächsten Abschnitt soll daher die Funktionsweise des Visitor Patterns kurz erläutert werden. 7.2 Visitor Pattern Beim Visitor Pattern handelt es sich um ein Verhaltensmuster in der Objektorientierten Programmierung zur Kapselung von Operationen auf einer aggregierten Struktur, wie z.b. einer Baum-Struktur. Das Ziel ist es dabei, die Implementierung neuer Operationen auf der Struktur zu ermöglichen, ohne die Elemente (Klassen) der Struktur selbst verändern zu müssen. Anstatt jeder Klasse in der Struktur die neue Operation hinzuzufügen, wird die Implementierung in eine externe Besucherklasse (Visitor) ausgelagert. Dazu müssen die Struktur-Klassen eine Schnittstelle (Methode) zum Empfang eines Visitors definieren und der Visitor enthält für jede Klasse eine Methode, welche die gewünschte Operation implementiert. ClassA +accept(v:visitor) ClassB <<interface>> Visitor +visit(o:classa) +visit(o:classb) +accept(v:visitor) v.visit(this); Visitor1 +visit(o:classa) +visit(o:classb) Visitor2 +visit(o:classa) +visit(o:classb) Abbildung 45: Visitor Pattern Abbildung 45 zeigt den klassischen Aufbau eines Visitor Patterns. Die Struktur, für die eine Operation implementiert werden soll, enthalte dabei Objekte der beiden Klassen ClassA und ClassB. Beide Klassen enthalten eine accept-

80 7 Implementierung 80 Methode, die einen Visitor entgegen nimmt und die entsprechende visit- Methode des Visitors aufruft. Der Visitor implementiert dann die eigentliche Operation. Auf diese Weise können die Klassen der Struktur auf ihre Kernfunktion begrenzt bleiben, während Operationen auf der Struktur in Form eines Visitors implementiert werden. Diese Flexibilität beim Hinzufügen neuer Operationen wird allerdings durch eine schlechte Erweiterbarkeit der eigentlichen Struktur erkauft, da das Hinzufügen neuer Klassen die Anpassung aller Visitors erfordert. Da die Elemente der SPARQL Algebra fix sind und somit in der Regel keine neuen Klassen zur Baum-Struktur der Algebra hinzugefügt werden, bietet sich das Visitor Pattern zur Realisierung von Operationen auf der SPARQL Algebra an. Aus diesem Grund unterstützt auch die Baum-Struktur von ARQ zur Repräsentation der SPARQL Algebra das Visitor Pattern, d.h. jede Op-Klasse des Algebra-Baums in ARQ verfügt über eine Visitor-Schnittstelle Optimierungen der SPARQL Algebra In Abschnitt 6.1 wurden einige Optimierungen der SPARQL Algebra vorgestellt, welche eine Reduktion der von einer Anfrage erzeugten Zwischenergebnisse und somit auch des Datenaufkommens versprechen. Es ist daher davon auszugehen, dass sich die entsprechenden Optimierungen auch unmittelbar positiv auf die Auswertung der Anfrage in Pig Latin auswirken. Zur Implementierung der vorgestellten Optimierungen muss der Algebra- Baum traversiert (durchlaufen) werden, um nach potentiellen Optimierungsmöglichkeiten zu suchen. Wird eine solche Möglichkeit gefunden, so müssen die entsprechenden Änderungen am Algebra-Baum vorgenommen werden. ARQ bietet für solche Operationen einen Mechanismus, der auf den Prinzipien des Visitor Patterns beruht. Jede Op-Klasse im Algebra-Baum bietet hierzu die Möglichkeit, eine Transformation auf ein Objekt der Klasse anzuwenden. Der Anwender muss einen sogenannten Transformer (analog zum Visitor) implementieren, welcher für jede Op-Klasse definiert, wie die Transformation aussehen soll. Sollen nur Objekte einer bestimmten Op-Klasse (z.b. OpBGP) transformiert werden, so werden die übrigen Objekte unverändert gelassen. Der Unterschied zu einem Visitor besteht darin, dass ein Objekt nicht nur besucht, sondern auch verändert wird. Die Transformation wird auf alle entsprechenden 26 Entgegen der üblichen Konvention wird die Visitor-Schnittstelle in ARQ nicht mit accept sondern ebenfalls mit visit bezeichnet.

81 7 Implementierung 81 Objekte im Algebra-Baum angewendet und liefert als Ergebnis einen neuen Algebra-Baum, wobei die unveränderten Objekte einfach kopiert werden. Zur Optimierung der Operatoren Filter und BGP der SPARQL Algebra mussten daher die entsprechenden Transformationen für die Klassen OpFilter und OpBGP implementiert werden. Für die Realisierung der Filter-Optimierung konnte größtenteils auf die vorhandenen Optimierungsmöglichkeiten von ARQ zurückgegriffen werden. Die Optimierung eines BGPs ist bei ARQ allerdings Aufgabe der jeweiligen Ausführungsplattform, da für unterschiedliche Plattformen auch unterschiedliche Optimierungen vorteilhaft sein können. Die Realisierung der BGP-Optimierung in PigSPARQL erfolgt in zwei Stufen: (1) Zunächst werden die Triple-Patterns in einem BGP nach ihrer Selektivität geordnet. Hierfür kommt die Variable Counting-Heuristik aus Abschnitt zum Einsatz. (2) Sollte die Anordnung der Triple-Patterns nach Selektivität ein Kreuzprodukt bei der Auswertung zur Folge haben, so wird überprüft, ob ein weniger selektives Triple-Pattern nach vorne geschoben werden kann, um die Auswertung des Kreuzprodukts zu vermeiden. Abbildung 46 zeigt das Ergebnis der Optimierung des Algebra-Baums aus Abbildung 44. Der Filter kann vor dem LeftJoin platziert werden, da die Variable?age nur im linken BGP vorkommt und die Triple-Patterns des linken BGPs wurden neu geordnet. OpLeftJoin OpFilter?age < 30 OpBGP?person mbox? OpBGP?person knows Bob.?person age?age Abbildung 46: optimierter Algebra-Baum in ARQ

82 7 Implementierung Übersetzung der SPARQL Algebra Nachdem die Optimierungen auf den Algebra-Baum angewendet wurden, muss der Baum noch in eine Folge von Pig Latin-Befehlen übersetzt werden. Um die eigentliche Übersetzung zu vereinfachen, wird der Algebra-Baum von ARQ zunächst in einen Zwischenbaum überführt, der im Folgenden als PigOp-Baum bezeichnet wird. Ebenso wie im Algebra-Baum von ARQ gibt es im PigOp- Baum für jeden Operator und Solution Modifier der SPARQL Algebra eine entsprechende PigOp-Klasse. PigBase {abstract} #resultschema:schema #resultname:string +getschema():schema +getresultname():string <<interface>> PigOp +accept(v:pigopvisitor) +getschema():schema +getresultname():string +translate():string PigOp0 {abstract} PigOp1 {abstract} #subop:pigop #rightop:pigop PigOp2 {abstract} #leftop:pigop #rightop:pigop PigBGP +accept(v:pigopvisitor) +translate():string PigFilter +accept(v:pigopvisitor) +translate():string PigOrder +accept(v:pigopvisitor) +translate():string PigProject +accept(v:pigopvisitor) +translate():string PigJoin +accept(v:pigopvisitor) +translate():string PigLeftJoin +accept(v:pigopvisitor) +translate():string PigUnion +accept(v:pigopvisitor) +translate():string PigDistinct +accept(v:pigopvisitor) +translate():string PigReduced +accept(v:pigopvisitor) +translate():string PigSlice +accept(v:pigopvisitor) +translate():string Abbildung 47: PigOp-Hierarchie

83 7 Implementierung 83 Betrachtet man die Struktur eines Algebra-Baums genauer, so lässt sich feststellen, dass ein Knoten im Baum entweder einen, zwei oder keinen Kind- Knoten besitzt. Aus diesem Grund wurde für die Klassen des PigOp-Baums eine Hierarchie entworfen, um so viele Eigenschaften wie möglich zu bündeln und mehrfache Implementierungen zu vermeiden. Die Hierarchie beruht auf der Anzahl an Kind-Knoten, die ein Knoten im PigOp-Baum besitzt. Abbildung 47 zeigt die verwendete Hierarchie der PigOp-Klassen, wobei nur die wichtigsten Eigenschaften in die Darstellung übernommen wurden. Der resultierende PigOp-Baum unterstützt, analog zum Algebra-Baum in ARQ, das Visitor-Pattern. Eine konkrete PigOp-Klasse ergänzt die entsprechende Klasse im Algebra-Baum von ARQ um die für die Übersetzung notwendigen Informationen. Dazu gehören der Name (Alias) und das Schema der Ergebnis-Relation, da dies vom übergeordneten Element im Baum zur Übersetzung benötigt wird. Darüber hinaus enthält jede PigOp-Klasse natürlich auch die Übersetzung des entsprechenden Operators bzw. Solution Modifiers. Um den PigOp-Baum in das endgültige Pig Latin-Programm zu überführen, muss der Baum Bottom-Up (von unten nach oben) traversiert und die Übersetzung der einzelnen Knoten zusammengefügt werden. Da die Traversierung des Baums selbst eine Operation auf der Baum-Struktur darstellt, kann sie ebenfalls in Form eines Visitors implementiert werden. Dazu werden innerhalb einer visit-methode im Visitor (hier: PigOp-Visitor) zunächst die Kinder des Knotens besucht und übersetzt. Im Folgenden soll dieser Vorgang Schritt für Schritt am Beispiel der Übersetzung des Algebra-Baums aus Abbildung 46 illustriert werden. (4) PigLeftJoin resultname: schema: (2) PigFilter PigBGP (3) resultname: schema:?age < 30 resultname: schema:?person mbox? (1) PigBGP resultname: schema:?person knows Bob.?person age?age Abbildung 48: PigOp-Baum vor der Übersetzung

84 7 Implementierung 84 (4) PigLeftJoin resultname: schema: (2) PigFilter PigBGP (3) resultname: schema:?age < 30 resultname: schema:?person mbox? (1) PigBGP resultname: BGP1 schema: person,age?person knows Bob.?person age?age knows = LOAD 'pathtofile/knows' USING rdfloader() AS (s,o) ; age = LOAD 'pathtofile/age' USING rdfloader() AS (s,o) ; f1 = FILTER knows BY o == 'Bob' ; t1 = FOREACH f1 GENERATE s AS person ; t2 = FOREACH age GENERATE s AS person, o AS age ; j1 = JOIN t1 BY person, t2 BY person ; BGP1 = FOREACH j1 GENERATE t1::person AS person, t2::age AS age ; (4) PigLeftJoin resultname: schema: (2) PigFilter PigBGP (3) resultname: F1 schema: person,age?age < 30 resultname: schema:?person mbox? (1) PigBGP resultname: BGP1 schema: person,age?person knows Bob.?person age?age F1 = FILTER BGP1 BY age < 30 ;

85 7 Implementierung 85 (4) PigLeftJoin resultname: schema: (2) PigFilter PigBGP (3) resultname: F1 schema: person,age?age < 30 resultname: BGP2 schema: person, ?person mbox? (1) PigBGP resultname: BGP1 schema: person,age?person knows Bob.?person age?age mbox = LOAD 'pathtofile/mbox' USING rdfloader() AS (s,o) ; BGP2 = FOREACH mbox GENERATE s AS person, o AS ; (4) PigLeftJoin resultname: LJ1 schema: person,age, (2) PigFilter PigBGP (3) resultname: F1 schema: person,age?age < 30 resultname: BGP2 schema: person, ?person mbox? (1) PigBGP resultname: BGP1 schema: person,age?person knows Bob.?person age?age lj = JOIN F1 BY person LEFT OUTER, BGP2 BY person ; LJ1 = FOREACH lj GENERATE F1::person AS person, F1::age AS age, BGP2:: AS ; STORE LJ1 INTO 'pathtooutput' USING resultwriter(); Abbildung 49: Übersetzung des PigOp-Baums

86 7 Implementierung Load/Store UDFs Zur Auswertung des übersetzten Pig Latin-Programms müssen die entsprechenden RDF-Daten im HDFS in das Datenmodell von Pig überführt werden (siehe Abschnitt 5.2). Dazu wurde eine Load UDF implementiert, die das tupelweise Laden der Daten ermöglicht, wobei ein Tupel in diesem Fall einem RDF-Tripel entspricht. Zum Abspeichern der Ergebnisse im HDFS wurde eine Store UDF implementiert, die unter anderem die Anzahl der berechneten Ergebnisse und das Ergebnis-Schema mit ausgibt. Abbildung 50 zeigt das Schema der Auswertung in Hadoop. Pig Latin-Programm Hadoop- Framework Load UDF Store UDF HDFS Anfrage-Ergebnis Abbildung 50: Schema der Auswertung Das Laden der Daten aus dem HDFS findet in der Map-Phase eines MapReduce-Jobs statt. Daher entspricht die Load UDF letztlich einer speziellen Map- Funktion, welche aus einem RDF-Tripel in der Eingabe ein entsprechendes Tupel im Datenmodell von Pig erzeugt (Deserialisierung). Nicht jedes RDF-Serialisierungsformat ist allerdings dafür geeignet, im Hadoop-Framework ausgewertet zu werden, da Dateien beim HDFS in Blöcke unterteilt und verteilt abgespeichert werden. Bei Textdateien ist es daher empfehlenswert, wenn jede Zeile der Eingabe-Datei auch einem kompletten Eintrag (hier: RDF-Tripel) entspricht. Andernfalls kann es nicht oder nur mit erheblichem Aufwand gewährleistet werden, dass auch alle Einträge bei der Verarbeitung rekonstruiert werden können. Besteht ein Eintrag z.b. aus zwei Zeilen, so kann es vorkommen, dass die beiden Zeilen in unterschiedlichen Blöcken im HDFS liegen und damit bei der Verarbeitung auch unterschiedlichen Mappern zugewiesen werden. In diesem Fall wäre keiner der beiden Mapper in der Lage, den Eintrag zu rekonstruieren.

87 7 Implementierung 87 Die implementierte Load UDF unterstützt daher eine Erweiterung des einfachen N-Triples-Formats 27, bei dem jede Zeile einem RDF-Tripel entspricht. Das an sich sehr einfache Format wurde um die Unterstützung von Blank Nodes, getypten Literalen und einigen sehr oft verwendeten Präfixen ergänzt, um insbesondere die Daten des SP 2 Bench (siehe Kapitel 8 Evaluation) zu unterstützen. Für die sehr häufigen XML Schema-Datentypen 28 xsd:integer, xsd:float und xsd:double wurde darüber hinaus eine Konvertierung in die entsprechenden Datentypen von Pig (int, float, double) implementiert, da diese sonst von Pig wegen ihrer Darstellung (z.b. "24"^^xsd:integer) als gewöhnliche Zeichenketten interpretiert würden. Die Konvertierung findet allerdings nur statt, wenn dies auch wirklich erforderlich ist. Das Speichern der Ergebnisse in das HDFS erfolgt meistens in der Reduce- Phase eines MapReduce-Jobs. Daher entspricht die Store UDF letztlich einer speziellen Reduce-Funktion, die jedes Tupel der Ergebnis-Relation in Pig als Zeile in der Ausgabe-Datei abspeichert (Serialisierung). 27 siehe [http://www.w3.org/2001/sw/rdfcore/ntriples/] 28 siehe [http://www.w3.org/tr/xmlschema-2/]

88 8 Evaluation 88 8 Evaluation Zur Evaluation der vorgestellten Übersetzung von SPARQL nach Pig Latin wurden zehn Dell PowerEdge R200 Server mit jeweils einem Dual Core Intel Xeon E3120 3,16 GHz Prozessor, 4 GB DDR2 800 MHz Arbeitsspeicher, 1 TB SATA-Festplatte mit 7200 U/min und einem Dual Port Gigabit Ethernet Adapter verwendet. Die Server wurden über einen 3Com Baseline Switch 2824 zu einem Gigabit-Netzwerk zusammengeschaltet und auf den Servern wurde Ubuntu 9.10 Server (x86_64), Java in der Version 1.6.0_15 und Cloudera's Distribution for Hadoop 3 (CDH3) 29 installiert. Dabei handelt es sich um eine gut dokumentierte und frei zugängliche Distribution des Hadoop-Dienstleisters Cloudera, die Unternehmen und Entwicklern den Einstieg in Hadoop erleichtern soll. Zum Zeitpunkt der Evaluation beinhaltete CDH3 unter anderem Hadoop in der Version sowie Pig in der Version Einer der Server (Master) wurde dabei ausschließlich als Namenode und Jobtracker genutzt, während die restlichen Server (Slaves) zum Speichern der Daten und Ausführen der MapReduce-Jobs verwendet wurden. Der Namenode ist für die Verwaltung des HDFS und der Jobtracker für die Koordination des MapReduce-Frameworks in Hadoop zuständig. Größtenteils wurden für die Konfiguration des Clusters die vorgegebenen Standard-Werte von CDH3 übernommen, lediglich die maximale Heapsize des Hadoop Daemons und seiner Child JVMs 30 (mapred.child.java.opts) wurden auf 2 GB bzw. 1 GB erhöht. Dem HDFS standen insgesamt knapp 8 TB an Festplattenspeicher zur Verfügung, was bei einem Standard-Replikationsfaktor von drei ungefähr 2,5 TB an Nutzdaten entspricht. Im Folgenden werden zunächst in Abschnitt 8.1 die betrachteten Kennzahlen und in Abschnitt 8.2 der für die Evaluation verwendete Benchmark kurz vorgestellt. Anschließend wird in Abschnitt 8.3 die Auswertung einiger Benchmark-Anfragen analysiert und die gewonnenen Erkenntnisse in Abschnitt 8.4 zusammengefasst. 29 siehe [http://www.cloudera.com/hadoop/] 30 Java Virtual Machine (JVM)

89 8 Evaluation Kennzahlen Die Ausführungszeiten der Pig Latin-Programme wurden mit Hilfe eines Timers gemessen, welcher die verstrichene Zeit zwischen dem Starten der Anfrage in Pig und dem Ende des letzten MapReduce-Jobs ermittelt. Dies beinhaltet sowohl die Erstellung als auch die Ausführung des MapReduce-Plans durch Pig inklusive aller Setup-Zeiten zwischen zwei aufeinander folgenden MapReduce- Jobs und entspricht somit der Zeit, die der Anwender auf die Berechnung des Anfrage-Ergebnisses warten muss, oftmals auch als Wall Time bezeichnet. Die in Kapitel 6 dargestellten Optimierungen zielen vor allem darauf ab, das Datenaufkommen während der Anfrage-Auswertung zu reduzieren, da dadurch eine Verbesserung der Performanz erwartet wird. Deshalb wurden bei der Evaluation neben der Ausführungszeit einer Anfrage noch drei weitere Kennzahlen betrachtet, die von Hadoop ermittelt werden und einen Rückschluss auf das Datenaufkommen während der Ausführung ermöglichen: (1) Menge der Daten, die in der Map-Phase eines MapReduce-Jobs aus dem HDFS gelesen werden (HDFS Bytes Read). (2) Menge der Daten, die nach der Reduce-Phase eines MapReduce-Jobs in das HDFS geschrieben werden (HDFS Bytes Written). (3) Menge der Daten, die in der Shuffle-Phase eines MapReduce-Jobs von den Mappern zu den Reducern transportiert werden (Reduce Shuffle Bytes). Da ein Pig Latin-Programm in der Regel aus mehreren MapReduce-Jobs besteht, wurden die Werte für alle Jobs aufsummiert. Mit Hilfe dieser Kennzahlen lässt sich nachvollziehen, wie sich die Optimierungen auf das Datenaufkommen einer Anfrage auswirken. 8.2 SP 2 Bench Für die Evaluation wurde der SPARQL spezifische SP 2 Bench (SPARQL Performance Benchmark) [Schmidt, et al., 2009] verwendet. Im Gegensatz zum oft verwendeten LUBM Benchmark wurde er speziell für SPARQL entworfen und deckt eine Vielzahl der spezifischen Eigenschaften von SPARQL ab. Insbesondere umfasst er auch die wichtigen Operatoren OPTIONAL und UNION sowie die Solution Modifier von SPARQL, die beim LUBM Benchmark aufgrund der Generalität nicht betrachtet werden.

90 8 Evaluation 90 Der SP 2 Bench beinhaltet einenn Daten-Generator zum Erstellen beliebig gro- ßer RDF-Dateien sowie eine Kollektion von 17 Benchmark-Anfragen. Grundla- ge für den Daten-Generator bildet die DBLP-Bibliothek von Michael Ley [Ley, 2010], welche bibliografische Informationenn zu über 1,4 Millionen Veröffentli- chungen (Stand: Juli 2010) im Bereich der Informatikk enthält. Die vom Gene- rator erzeugten RDF-Dateien berücksichtigen dabei die charakteristischen Ei- somit ein realistisches Datenmodell. Da die Generierung der Daten determinis- tisch und aufsteigend nach der Jahreszahl erfolgt, ist ein kleineres Dokument immer vollständig in einem größeren Dokument enthalten. Abbildung 51 zeigt die grafische Visualisierung (RDF-Graph)) eines beispiel- haften Ausschnitts einer RDF-Datei, wie sie vom SP 2 genschaften und Verteilungen der ursprünglichen DBLP-Bibliothek und liefern Bench-Generator erzeugt wird. Für die Evaluation wurdenn RDF-Dateien mit 25, 2 50, 100, 200, 400, 800 und 1600 Millionen RDF-Tripelnn erzeugt. Abbildung 51: DBLP Beispiel-Instanz [Schmidt, et al., 2009] 8.3 Auswertung einigerr SP 2 Bench-Anfragen Der SP 2 Bench beinhaltet insgesamt 14 Select-Anfragen, die einen Großteil der SPARQL-Charakteristika abdecken. Die restlichen drei Anfragen sind Ask-Anfragen, welche von der inn dieser Arbeit vorgestellten Übersetzung nicht betrachtet werden.

91 8 Evaluation 91 Im Vorfeld der Evaluation wurden einige Testläufe durchgeführt, um eine geeignete Anzahl an Reducern zu ermitteln, die von Pig in den Reduce-Phasen der MapReduce-Jobs verwendet werden sollen. Die Anzahl der Mapper in den Map-Phasen richtet sich nach der Größe der Eingabe-Daten und wird vom System automatisch bestimmt. Die besten Ergebnisse konnten in den Tests bei neun Reducern erzielt werden. Da im Test-Cluster neun Server zur Berechnung der MapReduce-Jobs eingesetzt wurden, entspricht dieser Wert größtenteils den Erwartungen. Bei weniger als neun Reducern würden nicht alle Kapazitäten in der Reduce-Phase eines MapReduce-Jobs ausgenutzt, was offensichtlich ineffizient wäre. Da es sich bei der betrachteten Problemstellung (Auswertung von Anfragen auf großen RDF-Datensätzen) um sehr datenintensive Aufgaben handelt, bei denen viele I/O-Operationen anfallen, brachte die Ausführung von mehreren Reducern auf einem Server keinen Vorteil, sondern führte in den Tests sogar zu einem Leistungsabfall. Aus diesem Grund wurde für die Evaluation eine feste Anzahl von neun Reducern gewählt. Es sei an dieser Stelle erwähnt, dass es keine allgemeingültigen Vorgaben zur optimalen Konfiguration eines Hadoop-Clusters gibt. Vielmehr können sich für unterschiedliche Szenarien auch unterschiedliche Konfigurationen als sinnvoll erweisen. Hadoop bietet hierfür eine Vielzahl von Parametern, welche an die Eigenschaften des Anwendungsfalls und die Ressourcen des Clusters angepasst werden können. Bis auf die Heapsize des Hadoop Daemons und der Child JVMs wurden für die Evaluation keine Änderungen an den Konfigurations- Parametern vorgenommen, wie sie von der Hadoop-Distribution von Cloudera (CDH3) vorgegeben werden. Es ist daher davon auszugehen, dass die in diesem Kapitel präsentierten Auswertungs-Ergebnisse durch eine feinere Anpassung der Konfiguration noch verbessert werden können. Die relativ eingeschränkten Monitoring-Möglichkeiten von Hadoop erwiesen sich während der Evaluation als eines der größten Probleme. Zwar werden alle Ereignisse während der Ausführung eines MapReduce-Jobs von Hadoop in großen Log-Dateien abgelegt, die Angaben sind allerdings sehr technischer Natur, was die Fehlersuche deutlich erschwerte. Im Folgenden werden die Auswertungen einiger SP 2 Bench-Anfragen analysiert, mit deren Hilfe grundlegende Erkenntnisse über die Auswertung von SPARQL-Anfragen mit Pig Latin abgeleitet werden können. Die entsprechenden Pig Latin-Programme zu den untersuchten SPARQL-Anfragen gemäß der vorgestellten Übersetzung finden sich im Anhang dieser Arbeit.

92 8 Evaluation Q10 SELECT?subject?predicate WHERE {?subject?predicate person:paul_erdoes } Abbildung 52: SP 2 Bench-Anfrage (Q10) Die Anfrage Q10 besteht lediglich aus einem einzelnen Triple-Pattern, das alle RDF-Tripel selektiert, die "Paul Erdös" als Objekt enthalten. Die Anfrage liefert daher einen Richtwert, wie viel Zeit ein Durchlauf des kompletten Datensatzes benötigt, da jedes RDF-Tripel in der Eingabe ein Mal betrachtet werden muss. Q1 25M 50M 100M 200M 400M 800M 1600M no opt 00:00:42 00:01:17 00:01:58 00:03:29 00:06:29 00:12:19 00:24:16 #results Tabelle 20: Auswertung von Q10 163,44 00:25:00 Input-Größe (in GB) 81,91 41,13 2,64 5,27 10,4720, (a) RDF-Tripel (in Millionen) Zeit (hh:mm:ss) (b) 00:20:00 00:15:00 00:10:00 00:05:00 00:00: RDF-Tripel (in Millionen) Abbildung 53: Auswertung von Q10 Die Auswertung des entsprechenden Pig Latin-Programms erfordert lediglich einen MapReduce-Job, wobei die Berechnung komplett in der Map-Phase stattfinden kann. Es zeigte sich ein erwartet linearer Anstieg der Ausführungszeit in Abhängigkeit der Eingabegröße (siehe Abbildung 53 (b)), wobei der größte Datensatz (1600 Millionen RDF-Tripel) etwas mehr als 24 Minuten benötigte. Die Anzahl der berechneten Ergebnisse war bei allen Datensätzen gleich, was darauf zurückzuführen ist, dass der Autor "Paul Erdös" nur bis zum Jahr 1996 aktiv war. Da aber bereits der Datensatz mit 25 Millionen Tripeln die

93 8 Evaluation 93 generierten Daten bis zum Jahr 2015 enthält, kommen auch bei größeren Datensätzen keine neuen Einträge zu "Paul Erdös" hinzu. Diese Tatsache kann bei der Auswertung allerdings aufgrund der erwünschten ad-hoc Verarbeitung (keine zusätzliche Vorverarbeitung, z.b. zum Erstellen eines Index) nicht ausgenutzt werden. Die in Kapitel 6 vorgestellten Optimierungen haben keinen Einfluss auf die Auswertung von Q10, da die Anfrage keinen Filter enthält und bei nur einem Triple-Pattern auch keine Neuanordnung erfolgen kann. Auch die Partitionierung des Datensatzes nach Prädikaten wirkt sich hier aufgrund des ungebundenen Prädikats im Triple-Pattern (?predicate) nicht positiv aus. Die Anfrage liefert aber einen guten Anhaltspunkt dafür, wie lange ein einfacher Durchlauf des kompletten Datensatzes dauert Q11 SELECT?ee WHERE {?publication rdfs:seealso?ee } ORDER BY?ee LIMIT 10 OFFSET 50 Abbildung 54: SP 2 Bench-Anfrage (Q11) Die Anfrage Q11 ist der Anfrage Q10 recht ähnlich, da sie auch nur aus einem Triple-Pattern besteht, bei dem nur eine Komponente (Prädikat) gebunden ist. Im Gegensatz zu Q10 sollen die gefundenen Ergebnisse allerdings sortiert, die ersten 50 verworfen (Offset) und die Anzahl auf zehn begrenzt werden. Das Sortieren der Daten erhöht natürlich die Komplexität der Anfrage, da das Sortieren vor der Begrenzung stattfinden muss. Q11 25M 50M 100M 200M 400M 800M 1600M no opt 00:02:15 00:03:50 00:04:31 00:06:58 00:12:36 00:21:38 00:41:34 part 00:01:24 00:01:24 00:01:29 00:01:40 00:01:49 00:02:20 00:03:25 #results Tabelle 21: Auswertung von Q11 Die Auswertung von Q11 ergibt einen linearen Anstieg der Ausführungszeit in Abhängigkeit der Eingabegröße. Das entsprechende Pig Latin-Programm lieferte jeweils 60 Ergebnisse, da sich ein Offset in Pig Latin nicht ohne weiteres realisieren lässt. Die ersten 50 Ergebnisse müssen daher ignoriert werden.

94 8 Evaluation 94 Zeit (hh:mm:ss) (a) 00:45:00 00:40:00 00:35:00 00:30:00 00:25:00 00:20:00 00:15:00 00:10:00 00:05:00 00:00:00 Q11 Q11 part RDF-Tripel (in Millionen) (b) 1600M RDF-Tripel HDFS Bytes Read (in GB) Abbildung 55: Auswertung von Q11 Optimierungen der SPARQL Algebra und der Übersetzung lassen sich bei Q11 ebenso wie bei Q10 nicht anwenden, da die Anfrage nur ein einzelnes Triple- Pattern enthält. Durch die Partitionierung des RDF-Datensatzes nach Prädikaten lässt sich die Ausführungszeit allerdings deutlich reduzieren (Q11 part), da bei Q11 das Prädikat im Triple-Pattern gebunden ist. Während bei den nicht partitionierten Daten über den kompletten Datensatz iteriert werden muss, kann die Eingabe durch die Partitionierung bereits erheblich verkleinert werden. Beim größten Datensatz (1600 Millionen RDF-Tripel) konnte dadurch die Ausführungszeit um über 90% reduziert werden, was sich erwartungsgemäß auch in der Menge an Daten wiederspiegelt, die während der Ausführung aus dem HDFS gelesen wurden (siehe Abbildung 55 (b)). Dieses einfache Beispiel zeigt bereits die deutlichen Vorteile, die eine Partitionierung des RDF-Datensatzes haben kann. Vor allem bei Anfragen, die nur wenige, sehr selektive Prädikate enthalten, lässt sich die Eingabegröße signifikant reduzieren. Kommen in der Anfrage hingegen ungebundene oder viele wenig selektive Prädikate vor, bietet eine vertikale Partitionierung nach Prädikaten kaum Vorteile Q3 (a) SELECT?article WHERE {?article rdf:type bench:article.?article?property?value FILTER (?property = swrc:pages) } (b) "swrc:month" statt "swrc:pages" (c) "swrc:isbn" statt "swrc:pages" Abbildung 56: SP 2 Bench-Anfrage (Q3)

95 8 Evaluation 95 Q3 filtert die Artikel im RDF-Datensatz nach drei verschiedenen Eigenschaften (Prädikaten), die mehr oder weniger selektiv sind. Q3a liefert alle Artikel, deren Seitenzahl (swrc:pages) bekannt ist, was allerdings für über 90% der Artikel zutrifft. Der Monat der Veröffentlichung (swrc:month) ist hingegen deutlich selektiver, da nur 0,65% aller Artikel diese Eigenschaft besitzen. Die Filter- Bedingung von Q3c wird hingegen niemals erfüllt sein, da kein Artikel eine ISBN-Nummer (swrc:isbn) hat. Da die Filter-Variable (?property) nicht in der Ausgabe enthalten sein soll, lassen sich die Anfragen auf Algebra-Ebene durch eine Filter-Substitution optimieren, wie sie in Abschnitt vorgestellt wurde. Dabei wird die Variable im zweiten Triple-Pattern durch ihren entsprechenden Filter-Wert ersetzt, wodurch der ursprüngliche Filter überflüssig wird. Damit wird die Eingabe des Joins reduziert, welcher für die Verknüpfung der beiden Triple-Patterns benötigt wird. Ein positiver Nebeneffekt der Algebra-Optimierungen ist die Eliminierung des ungebundenen Prädikats im zweiten Triple-Pattern, wovon insbesondere die Auswertung auf einem vertikal partitionierten Datensatz profitiert. Um die Auswirkungen der Algebra-Optimierung und der Partitionierung nachvollziehen zu können, wurden die Anfragen zunächst ohne Optimierung ausgeführt und anschließend mit der optimierten Ausführung verglichen (mit und ohne Partitionierung der Daten). Im Folgenden wird nur die Auswertung von Q3a genauer analysiert, da deren Erkenntnisse sich analog auf die Auswertungen von Q3b und Q3c übertragen lassen. Zeit (hh:mm:ss) (a) 03:30:00 03:00:00 02:30:00 02:00:00 01:30:00 01:00:00 00:30:00 00:00:00 Q3a Q3a opt Q3a opt+part RDF-Tripel (in Millionen) Q3a Q3a opt Q3a opt+part 326,88 326,88 17,71 196,56 12,72 7,48 HDFS Bytes Read Reduce Shuffle Bytes (b) in GB (1600M RDF-Tripel) Abbildung 57: Auswertung von Q3a

96 8 Evaluation 96 Q3a 25M 50M 100M 200M 400M 800M 1600M no opt 00:02:03 00:03:34 00:07:48 00:16:34 00:35:31 01:14:25 03:26:35 opt 00:02:44 00:02:28 00:04:48 00:07:44 00:14:29 00:28:17 00:56:39 opt+part 00:00:43 00:00:47 00:00:52 00:01:18 00:01:48 00:02:48 00:05:14 #results Tabelle 22: Auswertung von Q3a Ohne die Substitution des Filters (Q3a) wird zunächst der Join zwischen den Ergebnissen der beiden Triple-Patterns berechnet und anschließend die unerwünschten Ergebnisse ausgefiltert. Dazu müssen die Ergebnisse der beiden Triple-Patterns in der Shuffle-Phase zu den Reducern transportiert werden, da die Berechnung des Joins in der Reduce-Phase stattfindet. Allerdings erfüllen alle RDF-Tripel im Datensatz das zweite Triple-Pattern, weshalb in der Shuffle-Phase viele Daten über das Netzwerk transportiert werden müssen. Durch die Optimierungen auf Algebra- und Übersetzungs-Ebene, wie sie in Abschnitt 6.1 und 6.2 vorgestellt wurden, lässt sich die Ausführungszeit der Anfrage beim größten Datensatz um über 70% verringern (Q3a opt), was vor allem auf eine signifikante Reduktion der Reduce Shuffle Bytes (siehe Abbildung 57 (b)) zurückzuführen ist. Durch die Substitution des Filters werden die Ergebnisse des zweiten Triple-Patterns vor der Ausführung des Joins reduziert, weshalb deutlich weniger Daten zu den Reducern übertragen werden müssen. Wird die optimierte Anfrage zusätzlich auf einem nach Prädikaten partitionierten Datensatz ausgeführt (Q3a opt+part), lässt sich die Ausführungszeit nochmals deutlich verkürzen, da nur die beiden Prädikate rdf:type und swrc:pages betrachtet werden müssen. Dies spiegelt sich auch in einer drastischen Reduktion der Daten wieder, die aus dem HDFS gelesen werden (HDFS Bytes Read).

97 8 Evaluation Q2 SELECT?inproc?author?booktitle?title?proc?ee?page?url?yr?abstract WHERE {?inproc rdf:type bench:inproceedings.?inproc dc:creator?author.?inproc bench:booktitle?booktitle.?inproc dc:title?title.?inproc dcterms:partof?proc.?inproc rdfs:seealso?ee.?inproc swrc:pages?page.?inproc foaf:homepage?url.?inproc dcterms:issued?yr OPTIONAL {?inproc bench:abstract?abstract } } ORDER BY?yr Abbildung 58: SP 2 Bench-Anfrage (Q2) Q2 liefert als Ergebnis alle "Inproceedings" mit den Eigenschaften (Prädikaten) rdf:type, dc:creator, bench:booktitle, dc:title, dcterms:partof, rdfs:seealso, swrc:pages, foaf:homepage, dcterms:issued und optional bench:abstract, sortiert nach dem Jahr der Veröffentlichung. Eine Optimierung auf Algebra-Ebene, wie sie in Abschnitt 6.1 vorgestellt wurde, führt bei Q2 zu keinen Verbesserungen, da die meisten Triple-Patterns der Anfrage die gleichen ungebundenen Komponenten (Subjekt und Objekt) besitzen. Ohne statistische Informationen über die Selektivität der verschiedenen Prädikate müssen die Triple-Patterns daher als gleich selektiv angenommen werden. Es sei an dieser Stelle angemerkt, dass alle verwendeten Eigenschaften nicht besonders selektiv sind, da viele "Inproceedings" diese Eigenschaften besitzen. Anhand von Q2 lassen sich allerdings sehr gut die Auswirkungen der in Abschnitt 6.2 vorgestellten Optimierungen der Übersetzung beobachten. In der ursprünglichen Übersetzung nach Kapitel 5 werden für die Auswertung von Q2 mit Pig Latin insgesamt acht Joins und ein Outer Join benötigt. Dabei werden viele unnötigen Informationen erst nach den Joins entfernt, was sich negativ auf das Datenaufkommen auswirkt. In einem ersten Optimierungsschritt werden diese Informationen daher nach der "Project Early and Often"-Strategie so früh wie möglich entfernt. Darüber hinaus lässt sich bei der Übersetzung von Q2 die Multi-Join- Fähigkeit von Pig Latin ausnutzen. Da sich alle acht Joins auf die Variable?inproc beziehen, können sie in Pig Latin zu einem einzigen Join zusammenge-

98 8 Evaluation 98 fasst werden. Dadurch reduziert sich auch die benötigte Anzahl an MapReduce-Jobs zur Auswertung von Q2 von ursprünglich zwölf bei iterierten Joins auf fünf bei Verwendung eines Multi-Joins. Q2 25M 50M 100M 200M 400M 800M 1600M no opt 00:15:11 00:26:02 00:54:00 01:49:30 03:40:06 08:12:04 18:25:57 opt1 00:12:30 00:20:47 00:39:12 01:18:53 02:42:31 05:36:12 12:27:10 opt2 00:16:10 00:31:42 01:01:36 02:00:52 04:05:39 08:59:15 opt2+part 00:02:41 00:04:01 00:06:22 00:12:12 00:25:33 00:53:00 01:59:12 #results Tabelle 23: Auswertung von Q2 Zeit (hh:mm:ss) Q2 Q2 opt1 Q2 opt2 Q2 opt2+part 18:00:00 16:00:00 14:00:00 12:00:00 10:00:00 08:00:00 06:00:00 04:00:00 02:00:00 00:00: (a) RDF-Tripel (in Millionen) 3171, , ,17 168,27 (b) Q2 Q2 opt1 Q2 opt2 Q2 opt2+part HDFS Bytes Read 1345,45 769,70 388,35 125,70 HDFS Bytes Written in GB (1600M RDF-Tripel) 1244,09 647,37 272,46 178,20 Reduce Shuffle Bytes Q2 Q2 opt1 Q2 opt2 Q2 opt2+part Zeit (in s) (c) MapReduce-Jobs (1600M RDF-Tripel) Abbildung 59: Auswertung von Q2 Die Anwendung der "Project Early and Often"-Strategie (Q2 opt1) führt zu einer deutlichen Reduktion des Datenaufkommens über alle zwölf MapReduce- Jobs hinweg (siehe Abbildung 59 (b)), was sich auch in der Ausführungszeit niederschlägt (siehe Abbildung 59 (a) und (c)). Allein durch diese Änderung wird die Ausführungszeit beim größten Datensatz um mehr als 30% verkürzt.

99 8 Evaluation 99 Zwischen den einzelnen Joins (Job 2-9) müssen die Ergebnisse in das HDFS gespeichert werden, damit sie dem nachfolgenden Join als Eingabe zur Verfügung stehen. Durch die Verwendung eines Multi-Joins (Q2 opt2) lässt sich dieser Overhead vermeiden, weil hierfür nur ein MapReduce-Job benötigt wird, was auch in den betrachteten I/O-Kennzahlen zum Ausdruck kommt. Natürlich erhöht sich dadurch der Aufwand für den MapReduce-Job, der den Multi- Join berechnet. Insgesamt führt die Verwendung des Multi-Joins aber zu einer weiteren Reduktion der Ausführungszeit. Durch die Anwendung der Übersetzungs-Optimierungen aus Abschnitt 6.2 lässt sich die Ausführungszeit von Q2 beim größten Datensatz folglich um ca. 50% reduzieren. Bei der Auswertung des optimierten Pig Latin-Programms auf dem nach Abschnitt 6.3 partitionierten Datensatz (Q2 opt2+part) konnte abermals eine starke Verkürzung der Ausführungszeit beobachtet werden, was insbesondere auf die drastische Reduzierung der Daten, welche aus dem HDFS gelesen werden müssen (HDFS Bytes Read), zurückzuführen ist. Insgesamt lässt sich folglich festhalten, dass sich die Ausführungszeit von Q2 auf dem größten Datensatz (1600 Millionen RDF-Tripel) durch die Anwendung aller in Kapitel 6 beschriebenen Optimierungen um insgesamt fast 90% verringerte Q5 (a) SELECT DISTINCT?person?name WHERE {?article rdf:type bench:article.?article dc:creator?person.?inproc rdf:type bench:inproceedings.?inproc dc:creator?person2.?person foaf:name?name.?person2 foaf:name?name2 FILTER (?name =?name2) } (b) SELECT DISTINCT?person?name WHERE {?article rdf:type bench:article.?article dc:creator?person.?inproc rdf:type bench:inproceedings.?inproc dc:creator?person.?person foaf:name?name } Abbildung 60: SP 2 Bench-Anfrage (Q5)

100 8 Evaluation 100 Q5a und Q5b berechnen die gleichen Ergebnisse auf unterschiedliche Weise. Beide liefern die Namen aller Personen, die Autor von mindestens einem "Inproceeding" und einem "Artikel" sind. Bei Q5a wird dies durch einen Filter realisiert, während Q5b einen expliziten Join über die Variable?person verwendet. Es ist anzunehmen, dass Q5b effizienter ist als Q5a, da bei Q5a der Filter erst nach dem Join angewendet wird, während bei Q5b die Bedingung implizit im Join enthalten ist. Bei beiden Anfragen lassen sich die Auswirkungen der Algebra Optimierungen aus Abschnitt 6.1 sehr gut beobachten. Zur Auswertung der Anfrage in Pig Latin werden die Ergebnisse der Triple-Patterns nacheinander über einen Join verknüpft. In der nicht optimierten Übersetzung aus Kapitel 5 erfolgt die Verknüpfung genau in der Reihenfolge, in der die Triple-Patterns in der Anfrage vorkommen. Dies führt jedoch bei beiden Anfragen zu einem Kreuzprodukt, da die ersten beiden Triple-Patterns in den Anfragen keine gemeinsamen Variablen mit dem dritten Triple-Pattern besitzen. Zeit (hh:mm:ss) (a) Zeit (hh:mm:ss) (c) 04:30:00 04:00:00 03:30:00 03:00:00 02:30:00 02:00:00 01:30:00 01:00:00 00:30:00 00:00:00 04:00:00 03:30:00 03:00:00 02:30:00 02:00:00 01:30:00 01:00:00 00:30:00 00:00:00 Q5a opt Q5a opt+part RDF-Tripel (in Millionen) Q5b opt Q5b opt+part RDF-Tripel (in Millionen) 1369,76 125,67 HDFS Bytes Read (b) 1157,70 Q5a opt 248,36 39,88 HDFS Bytes Written Q5a opt+part 171,76 in GB (1600M RDF-Tripel) 102,97 Q5b opt 228,06 24,79 122,80 Reduce Shuffle Bytes Q5b opt+part 138,36 97,50 HDFS Bytes Read HDFS Bytes Written Reduce Shuffle Bytes (d) in GB (1600M RDF-Tripel) Abbildung 61: Auswertung von Q5

101 8 Evaluation 101 Q5 25M 50M 100M 200M 400M 800M 1600M Q5a opt 00:07:24 00:11:16 00:18:49 00:34:18 01:03:37 02:04:18 04:16:09 Q5a opt+part 00:04:22 00:04:52 00:07:18 00:09:48 00:17:41 00:34:40 01:15:02 Q5b opt 00:05:53 00:09:20 00:16:22 00:29:53 00:55:40 01:49:16 03:49:05 Q5b opt+part 00:02:56 00:03:21 00:04:37 00:06:41 00:13:45 00:27:35 00:57:30 #results Tabelle 24: Auswertung von Q5 Die nicht optimierten Übersetzungen von Q5a und Q5b ließen sich bereits auf dem kleinsten Datensatz (25 Millionen RDF-Tripel) nicht auswerten, da die Speicherplatz-Ressourcen des Clusters dafür nicht ausreichten. Dies zeigt ganz deutlich, dass Kreuzprodukte bei großen Datensätzen unbedingt vermieden werden müssen, wenn es irgendwie möglich ist. Durch eine Neuanordnung der Triple-Patterns lässt sich das Kreuzprodukt bei Q5b relativ einfach vermeiden, bei Q5a hingegen ist das allein durch eine Neuanordnung der Triple-Patterns nicht möglich. Da die Variable?name2 jedoch nicht in der Ausgabe zu Q5a enthalten sein soll, lässt sich eine ähnliche Optimierung wie bei Q3 anwenden. Dabei wird die Variable?name2 durch?name ersetzt (Variablen-Substitution), wodurch der ursprüngliche Filter überflüssig wird. Anschließend lässt sich auch bei Q5a das Kreuzprodukt durch eine Neuanordnung der Triple-Patterns umgehen. Haben die nicht optimierten Anfragen die Ressourcen des Clusters bereits beim kleinsten Datensatz überlastet, so konnten die optimierten Anfragen (Q5a opt und Q5b opt) sogar auf dem größten Datensatz relativ problemlos ausgewertet werden. Erwartungsgemäß ist die Auswertung von Q5b etwas effizienter, wobei durch die Substitution des Filters bei Q5a die Unterschiede nicht besonders groß sind. Durch die Auswertung der optimierten Anfragen auf einem partitionierten Datensatz (Q5a opt+part und Q5b opt+part) lässt sich auch hier die Ausführungszeit erwartungsgemäß deutlich verkürzen, was vor allem auf eine signifikante Reduktion der aus dem HDFS gelesen Daten (HDFS Bytes Read) zurückzuführen ist (siehe Abbildung 61 (b) und (d)). Somit bestätigt sich erneut, dass sich eine Reduktion des Datenaufkommens unmittelbar auf die Ausführungszeiten einer Anfrage auswirkt.

102 8 Evaluation Q6 (modifiziert) SELECT?yr?name?document WHERE {?class rdfs:subclassof foaf:document.?document rdf:type?class.?document dcterms:issued?yr.?document dc:creator?author.?author foaf:name?name OPTIONAL {?class2 rdfs:subclassof foaf:document.?document2 rdf:type?class2.?document2 dcterms:issued?yr2.?document2 dc:creator?author FILTER (?yr2<?yr) } FILTER (!bound(?document2)) } Abbildung 62: modifizierte SP 2 Bench-Anfrage (Q6) Q6 liefert für jedes Jahr die Veröffentlichungen von Autoren, die in diesem Jahr das erste Mal etwas veröffentlicht haben. Realisiert wird dies durch eine sogenannte "closed word negation", indem zu einer Veröffentlichung optional alle früheren Veröffentlichungen des gleichen Autors hinzugenommen werden und ein abschließender Filter dann nur diejenigen Veröffentlichungen beibehält, zu denen es keine früheren Veröffentlichungen gibt. Die Anfrage ist dahingehend interessant, weil sie einen Filter in einem Optional enthält, der außerdem nicht sicher ist (?yr kommt im Optional nicht vor). Das führt zu einem LeftJoin mit unsicherem Filter in der SPARQL Algebra, womit die Anfrage insbesondere nicht wohlgeformt (siehe Definition 1.2 auf Seite 41) ist. In Abschnitt wird eine mögliche Übersetzung solcher Anfragen dargestellt, welche eine aufwändige Folge von Pig Latin-Befehlen zur Folge hat. Die hier vorgestellte Version von Q6 entspricht einer leicht modifizierten Variante der entsprechenden SP 2 Bench-Anfrage. Bei der ursprünglichen Anfrage wertet sich der LeftJoin bei der Übersetzung zu einem Kreuzprodukt aus, da es zwischen dem linken und rechten Teil des LeftJoins keine gemeinsamen Variablen gibt. Da hier allerdings der LeftJoin mit unsicherem Filter betrachtet werden sollte, wurde die Anfrage so modifiziert, dass die Auswertung des LeftJoins kein Kreuzprodukt erfordert. Das Ergebnis der Anfrage wird durch die Modifikation nicht verändert.

103 8 Evaluation 103 Q6 25M 50M 100M 200M 400M 800M 1600M opt 00:12:44 00:24:52 00:50:48 01:43:19 03:46:05 09:03:02 opt+part 00:07:37 00:13:41 00:26:33 00:50:50 01:50:56 03:53:55 09:13:54 #results Tabelle 25: Auswertung von Q6 (modifiziert) Zeit (hh:mm:ss) (a) 09:00:00 08:00:00 07:00:00 06:00:00 05:00:00 04:00:00 03:00:00 02:00:00 01:00:00 00:00:00 Q6 opt Q6 opt+part RDF-Tripel (in Millionen) 1544,89 451,11 HDFS Bytes Read (b) Q6 opt 682,39 397,59 HDFS Bytes Written Q6 opt+part 258,04 in GB (800M RDF-Tripel) 183,20 Reduce Shuffle Bytes Abbildung 63: Auswertung von Q6 (modifiziert) Bei der Übersetzung der modifizierten Q6 wurden die in Abschnitt 6.2 dargestellten Optimierungen angewendet (Q6 opt). Die Anfrage erzeugt jedoch eine schnell wachsende Anzahl von Zwischenergebnissen, was beim größten Datensatz zu einer Überlastung der Ressourcen des Clusters führte. Durch die Partitionierung des Datensatzes (Q6 opt+part) konnte dieser Effekt etwas abgemildert werden, sodass auch der größte Datensatz ausgewertet werden konnte. Die Auswertung von Q6 zeigt, dass ein unsicherer Filter in einem Optional die Komplexität einer Anfrage deutlich erhöht und in der Praxis besser vermieden werden sollte. 8.4 Erkenntnisse der Evaluation Durch die Evaluation konnte die ursprüngliche Vermutung bestätigt werden, dass die Ausführungszeit einer Anfrage stark mit dem erzeugten Datenaufkommen korreliert, was in den betrachteten Kennzahlen deutlich zum Ausdruck kommt. Darüber hinaus konnte auch die Wirksamkeit der in Kapitel 6 vorgestellten Optimierungen bestätigt werden, die eine zum Teil starke Verkürzung der Ausführungszeiten ermöglichten, was primär auf eine Reduktion des erzeugten Datenaufkommens zurückzuführen war.

104 8 Evaluation 104 Etwas überraschend war an dieser Stelle die sehr deutliche Auswirkung des partitionierten Datensatzes auf die Ausführungszeiten. Es konnte zwar davon ausgegangen werden, dass dadurch eine Verbesserung erzielt werden kann, die erzielten Resultate übertrafen jedoch die Erwartungen. Auch hier spiegelte sich die Laufzeitverkürzung in den betrachteten Daten-Kennzahlen wieder und bestätigte so abermals den vermuteten Zusammenhang zwischen der Ausführungszeit und dem Datenaufkommen einer Anfrage. Der Erfolg des relativ simplen Prinzips der vertikalen Partitionierung eines Datensatzes nach Prädikaten zeigt, dass eine weitere Verfeinerung dieses Ansatzes ein lohnenswerter Ansatzpunkt für Weiterentwicklungen sein dürfte. Ermutigend für zukünftige Weiterentwicklungen des gewählten Ansatzes zur Auswertung von SPARQL-Anfragen in Hadoop mit Hilfe von Pig Latin sind auch die oftmals beobachteten, linearen Skalierungen der Ausführungszeiten sowie die auf Anhieb erreichten Datensatz-Größen von bis zu 1600 Millionen RDF-Tripeln, selbst ohne vertikale Partitionierung der Daten. Es ist anzunehmen, dass durch die vertikale Partitionierung und eine feinere Optimierung des Hadoop-Clusters dieser Wert sogar noch gesteigert werden kann, von einer Vergrößerung des Clusters ganz abgesehen. Beim Vergleich einiger Plattformen zur Auswertung von SPARQL auf einem Computer in [Schmidt, et al., 2009] konnten für die Anfragen des SP 2 Bench lediglich Datensatz-Größen von bis zu 25 Millionen RDF-Tripel erreicht werden. Dies zeigt das große Potential, welches in der Verwendung von Hadoop zur Auswertung von SPARQL-Anfragen liegt.

105 9 Verwandte Arbeiten Verwandte Arbeiten Im Folgenden werden kurz einige Arbeiten vorgestellt, welche sich ebenfalls mit der Verarbeitung von großen RDF-Datensätzen befassen. Die Idee, das MapReduce-Programmiermodell zur Verarbeitung von RDF- Daten zu verwenden, ist aufgrund des großen Erfolgs insbesondere von Hadoop relativ naheliegend. Allerdings gibt es dafür sehr unterschiedliche Ansätze und ein eindeutiger Trend ist schwer auszumachen. Das im Jahr 2008 angekündigte aber bis heute nicht veröffentlichte HEART-Projekt (Highly Extensible & Accumulative RDF Table) [Yoon, et al., 2010] sollte Hadoop um ein Subsystem zur Speicherung und verteilten Verarbeitung von RDF-Daten auf der Grundlage von HBase 31 erweitern. HBase ermöglicht die verteilte Speicherung von Spalten-orientierten Datenbanken in Hadoop und kann zur Eingabe und Ausgabe von Daten in MapReduce-Jobs verwendet werden. Die Entwicklung scheint jedoch aufgrund von Problemen mit HBase momentan eingestellt zu sein. Der Ansatz zur Auswertung von SPARQL-Anfragen, der in dieser Arbeit vorgestellt wird, beruht auf einer Übersetzung der Anfragen nach Pig Latin. Ein anderer, durchaus interessanter Ansatz ist die direkte Implementierung von SPARQL in MapReduce. Das im Jahr 2010 vorgestellte SHARD-Projekt (Scalable, High-Performance, Robust and Distributed) [Raytheon BBN Technologies, 2010] verfolgt diesen Ansatz, allerdings wurden bisher nur sehr wenige Informationen veröffentlicht. [Myung, et al., 2010] und [Husain, et al., 2009] betrachten ebenfalls die Auswertung von SPARQL Basic Graph Patterns mit MapReduce in Hadoop, die restlichen Operatoren von SPARQL bleiben dabei jedoch unbetrachtet. Wie in der Evaluation dieser Arbeit gezeigt wurde, hängt die Ausführungszeit einer Anfrage stark vom erzeugten Datenaufkommen ab. Bei der Übersetzung aus Kapitel 5 wurde größtenteils auf den Einsatz von UDFs verzichtet, da diese Erweiterungen des Standard-Funktionsumfangs von Pig Latin darstellen und daher insbesondere von Pig nicht optimiert werden können. In [Ravindra, et al., 2010] wurde allerdings gezeigt, dass durch den Einsatz von speziellen UDFs das Datenaufkommen reduziert und damit auch die Ausführungszeiten verringert werden können. 31 siehe [http://hbase.apache.org/]

106 9 Verwandte Arbeiten 106 Neben dem Einsatz von MapReduce-Systemen wie Hadoop wurden auch einige andere Ansätze zur Verarbeitung von großen RDF-Datensätzen entwickelt, welche hauptsächlich auf dem Einsatz von parallelen Datenbanken beruhen. Als Beispiel sei hierfür der Bigdata RDF Store [Thompson, et al., 2009] genannt. Allerdings erforderen solche Lösungen im Regelfall den Aufbau einer speziellen Infrastruktur. Ein Schwachpunkt von SPARQL in seiner aktuellen Version ist die mangelhafte Unterstützung von Pfadanfragen [Pérez, et al., 2008]. So lässt sich mit SPARQL beispielsweise nicht ermitteln, was der kürzeste Pfad von einem Knoten im RDF-Graph zu einem anderen Knoten ist. Eine interessante Möglichkeit hierfür bietet das von Martin Przyjaciel-Zablocki entwickelte RDFPath [Przyjaciel-Zablocki, 2010], das die Auswertung von Pfadanfragen auf RDF- Daten mit Hilfe von Hadoop ermöglicht.

107 10 Zusammenfassung Zusammenfassung In der vorliegenden Arbeit wurde ein Ansatz zur effizienten Auswertung von SPARQL-Anfragen auf großen RDF-Datensätzen vorgestellt. Die Auswertung erfolgt dabei im Apache Hadoop Framework, einer Open-Source Implementierung des von Google entwickelten MapReduce-Programmiermodells für nebenläufige Berechnungen auf sehr großen Datenmengen unter Einsatz eines Computer-Clusters. Dazu wurde eine Übersetzung von SPARQL nach Pig Latin, einer von Yahoo! Research entwickelten Sprache zur Analyse von großen Datenmengen mit Hadoop, entwickelt und implementiert. Gegenstand der Übersetzung sind SPARQL Select-Anfragen, da diese den wichtigsten und am meisten verwendeten Anfragetyp von SPARQL darstellen. Das resultierende Pig Latin-Programm wird von Pig, der Implementierung von Pig Latin für Hadoop, in eine Folge von MapReduce-Jobs überführt und verteilt auf einem Hadoop-Cluster ausgeführt. Zur Übersetzung wird eine SPARQL-Anfrage zunächst in einen Ausdruck der SPARQL Algebra überführt und anschließend nach den allgemeinen Prinzipien des Compilerbaus in eine Folge von Pig Latin-Befehlen übersetzt. Dazu wurden für alle Komponenten der SPARQL Algebra (mit Ausnahme des Graph-Operators) Übersetzungsvorschriften entwickelt und eine Abbildung des RDF-Datenmodells in das Datenmodell von Pig definiert. Im weiteren Verlauf wurden einige Optimierungen auf Ebene der SPARQL Algebra, der Übersetzung und des Datenmodells vorgestellt, die auch in die Implementierung aufgenommen wurden. Für die Evaluation der entwickelten Übersetzung wurde der SP 2 Bench verwendet, ein SPARQL spezifischer Performance Benchmark, der auch einen Generator zum Erstellen eines beliebig großen RDF-Datensatzes beinhaltet. Zur Auswertung der SP 2 Bench-Anfragen wurde ein Hadoop-Cluster aus zehn Computern aufgesetzt und mehrere RDF-Datensätze unterschiedlicher Größe generiert. Die Evaluationsergebnisse haben gezeigt, dass die Verwendung des Map- Reduce-Programmiermodells ein geeigneter und effizienter Ansatz zur Auswertung von SPARQL-Anfragen auf großen RDF-Datensätzen ist. Die verwendeten Datensatz-Größen von bis zu 1600 Millionen RDF-Tripeln übertreffen die Möglichkeiten von Systemen, die nur auf einem Computer ausgeführt werden, bereits um ein Vielfaches, was der Vergleich in [Schmidt, et al., 2009] belegt.

108 10 Zusammenfassung 108 Bedenkt man die Tatsache, dass für die Evaluation nur ein kleiner Hadoop- Cluster zum Einsatz kam (Yahoo! unterhält z.b. einen Hadoop-Cluster mit mehreren tausend Computern) und Pig sich in einer relativ frühen Entwicklungsphase befindet (die Evaluation wurde mit Pig durchgeführt), wird das große Potential des Ansatzes deutlich. Durch die Evaluation konnte auch der vermutete Zusammenhang zwischen der Ausführungszeit einer Anfrage und dem von der Anfrage erzeugten Datenaufkommen bestätigt werden. Besonders deutlich wurde dies durch die vorgestellten Optimierungen, mit deren Hilfe die Ausführungszeit einer Anfrage teilweise drastisch reduziert werden konnte, was auf eine signifikante Reduktion des erzeugten Datenaufkommens zurückzuführen war. Hier erwies sich insbesondere eine vertikale Partitionierung des RDF-Datensatzes nach Prädikaten als sehr effektiv, was allerdings eine Vorverarbeitung des Datensatzes erfordert. Die dadurch erzielten Verbesserungen waren jedoch teilweise so deutlich, dass eine Weiterentwicklung dieses Ansatzes lohnenswert erscheint. Neben den in dieser Arbeit vorgestellten Optimierungen profitiert die Auswertung von SPARQL-Anfragen mit Hilfe von Pig Latin auch von Weiterentwicklungen und Optimierungen auf Seiten von Pig. Da Pig Latin von Yahoo! Research entwickelt wurde und auch im operativen Geschäft von Yahoo! zur Analyse von Daten zum Einsatz kommt, wird die Weiterentwicklung von Pig mit Nachdruck vorangetrieben (zum Zeitpunkt der Abgabe dieser Arbeit war bereits Pig verfügbar). Die Übersetzung einer SPARQL-Anfrage in ein Pig Latin-Programm hat darüber hinaus den Vorteil, dass keine Anpassungen am Hadoop-Framework vorgenommen werden müssen, weil Pig ein offizielles Subprojekt von Hadoop ist. Somit lässt sich ein bestehendes Hadoop-Cluster problemlos zur Auswertung von SPARQL-Anfragen verwenden. Sollte kein eigenes Cluster zur Verfügung stehen, so bieten Firmen wie Amazon die Verwendung eines Hadoop- Clusters mittlerweile auch als Web-Service an (Amazon Elastic MapReduce 32 ), der sich dynamisch an die benötigten Kapazitäten anpassen lässt. Dadurch können SPARQL-Anfragen auch auf großen Datensätzen ausgewertet werden, ohne dafür eine eigene Infrastruktur aufbauen zu müssen. Die in dieser Arbeit vorgestellte Übersetzung bietet somit eine einfache und zugleich effiziente Möglichkeit, die Leistungsfähigkeit eines Hadoop-Clusters zur verteilten und parallelisierten Auswertung von SPARQL-Anfragen auf großen RDF-Datensätzen zu nutzen. 32 siehe [http://aws.amazon.com/de/elasticmapreduce/]

109 Anhang: Übersetzung der Sp2Bench-Anfragen 109 Anhang: Übersetzung der Sp 2 Bench-Anfragen Im Folgenden werden die entsprechenden Pig Latin-Programme zu den Anfragen aus Kapitel 8 dargestellt. Dabei wurden die Optimierungen aus Kapitel 6 (ohne vertikale Partitionierung der Daten) angewendet. Die Java-Bibliothek SPARQL_UDFs.jar enthält die benötigten Load und Store UDFs zum Laden der RDF-Daten und Abspeichern der berechneten Ergebnisse. $inputdata, $outputdata und $reducernum sind Parameter, deren Werte beim Aufruf des Programms übergeben werden Q2 REGISTER SPARQL_UDFs.jar; indata = LOAD '$inputdata' USING rdfloader.exntriplesloader() ; -- BGP f0 = FILTER indata BY p == 'rdf:type' AND o == 'bench:inproceedings' ; t0 = FOREACH f0 GENERATE s AS inproc ; f1 = FILTER indata BY p == 'dc:creator' ; t1 = FOREACH f1 GENERATE s AS inproc, o AS author ; f2 = FILTER indata BY p == 'bench:booktitle' ; t2 = FOREACH f2 GENERATE s AS inproc, o AS booktitle ; f3 = FILTER indata BY p == 'dc:title' ; t3 = FOREACH f3 GENERATE s AS inproc, o AS title ; f4 = FILTER indata BY p == 'dcterms:partof' ; t4 = FOREACH f4 GENERATE s AS inproc, o AS proc ; f5 = FILTER indata BY p == 'rdfs:seealso' ; t5 = FOREACH f5 GENERATE s AS inproc, o AS ee ; f6 = FILTER indata BY p == 'swrc:pages' ; t6 = FOREACH f6 GENERATE s AS inproc, o AS page ; f7 = FILTER indata BY p == 'foaf:homepage' ; t7 = FOREACH f7 GENERATE s AS inproc, o AS url ; f8 = FILTER indata BY p == 'dcterms:issued' ; t8 = FOREACH f8 GENERATE s AS inproc, o AS yr ; BGP1 = JOIN t0 BY inproc, t1 BY inproc, t2 BY inproc, t3 BY inproc, t4 BY inproc, t5 BY inproc, t6 BY inproc, t7 BY inproc, t8 BY inproc PARALLEL $reducernum ; BGP1 = FOREACH BGP1 GENERATE $0 AS inproc, $2 AS author, $4 AS booktitle, $6 AS title, $8 AS proc, $10 AS ee, $12 AS page, $14 AS url, $16 AS yr ; -- BGP f0 = FILTER indata BY p == 'bench:abstract' ; BGP2 = FOREACH f0 GENERATE s AS inproc, o AS abstract ; -- OPTIONAL j1 = JOIN BGP1 BY inproc LEFT OUTER, BGP2 BY inproc PARALLEL $reducernum; OPTIONAL1 = FOREACH j1 GENERATE $0 AS inproc, $1 AS author, $2 AS booktitle, $3 AS title, $4 AS proc, $5 AS ee, $6 AS page, $7 AS url, $8 AS yr, $10 AS abstract ; -- OrderBy Q2 = ORDER OPTIONAL1 BY yr PARALLEL $reducernum ; STORE Q2 INTO '$outputdata' USING resultwriter.selectresultwriter() ;

110 Anhang: Übersetzung der Sp2Bench-Anfragen Q3 (a,b,c) REGISTER SPARQL_UDFs.jar; indata = LOAD '$inputdata' USING rdfloader.exntriplesloader() ; -- BGP f0 = FILTER indata BY p == 'rdf:type' AND o == 'bench:article' ; t0 = FOREACH f0 GENERATE s AS article ; (a) f1 = FILTER indata BY p == 'swrc:pages' ; (b) f1 = FILTER indata BY p == 'swrc:month' ; (c) f1 = FILTER indata BY p == 'swrc:isbn' ; t1 = FOREACH f1 GENERATE s AS article, o AS value ; BGP1 = JOIN t0 BY article, t1 BY article PARALLEL $reducernum ; BGP1 = FOREACH BGP1 GENERATE $0 AS article, $2 AS value ; -- Project Q3 = FOREACH BGP1 GENERATE article ; STORE Q3 INTO '$outputdata' USING resultwriter.selectresultwriter() ; 10.3 Q5a REGISTER SPARQL_UDFs.jar; indata = LOAD '$inputdata' USING rdfloader.exntriplesloader() ; -- BGP f0 = FILTER indata BY p == 'rdf:type' AND o == 'bench:article' ; t0 = FOREACH f0 GENERATE s AS article ; f1 = FILTER indata BY p == 'dc:creator' ; t1 = FOREACH f1 GENERATE s AS article, o AS person ; f2 = FILTER indata BY p == 'foaf:name' ; t2 = FOREACH f2 GENERATE s AS person, o AS name ; f3 = FILTER indata BY p == 'foaf:name' ; t3 = FOREACH f3 GENERATE s AS person2, o AS name ; f4 = FILTER indata BY p == 'dc:creator' ; t4 = FOREACH f4 GENERATE s AS inproc, o AS person2 ; f5 = FILTER indata BY p == 'rdf:type' AND o == 'bench:inproceedings' ; t5 = FOREACH f5 GENERATE s AS inproc ; BGP1 = JOIN t0 BY article, t1 BY article PARALLEL $reducernum ; BGP1 = FOREACH BGP1 GENERATE $0 AS article, $2 AS person ; BGP1 = JOIN t2 BY person, BGP1 BY person PARALLEL $reducernum ; BGP1 = FOREACH BGP1 GENERATE $1 AS name, $2 AS article, $3 AS person ; BGP1 = JOIN t3 BY name, BGP1 BY name PARALLEL $reducernum ; BGP1 = FOREACH BGP1 GENERATE $0 AS person2, $2 AS name, $3 AS article, $4 AS person ; BGP1 = JOIN t4 BY person2, BGP1 BY person2 PARALLEL $reducernum ; BGP1 = FOREACH BGP1 GENERATE $0 AS inproc, $2 AS person2, $3 AS name, $4 AS article, $5 AS person ; BGP1 = JOIN t5 BY inproc, BGP1 BY inproc PARALLEL $reducernum ; BGP1 = FOREACH BGP1 GENERATE $1 AS inproc, $2 AS person2, $3 AS name, $4 AS article, $5 AS person ; -- Project Project = FOREACH BGP1 GENERATE person, name ; -- Distinct Q5a = DISTINCT Project PARALLEL $reducernum ; STORE Q5a INTO '$outputdata' USING resultwriter.selectresultwriter() ;

111 Anhang: Übersetzung der Sp2Bench-Anfragen Q5b REGISTER SPARQL_UDFs.jar; indata = LOAD '$inputdata' USING rdfloader.exntriplesloader() ; -- BGP f0 = FILTER indata BY p == 'rdf:type' AND o == 'bench:article' ; t0 = FOREACH f0 GENERATE s AS article ; f1 = FILTER indata BY p == 'dc:creator' ; t1 = FOREACH f1 GENERATE s AS article, o AS person ; f2 = FILTER indata BY p == 'foaf:name' ; t2 = FOREACH f2 GENERATE s AS person, o AS name ; f3 = FILTER indata BY p == 'dc:creator' ; t3 = FOREACH f3 GENERATE s AS inproc, o AS person ; f4 = FILTER indata BY p == 'rdf:type' AND o == 'bench:inproceedings' ; t4 = FOREACH f4 GENERATE s AS inproc ; BGP1 = JOIN t0 BY article, t1 BY article PARALLEL $reducernum ; BGP1 = FOREACH BGP1 GENERATE $0 AS article, $2 AS person ; BGP1 = JOIN t2 BY person, t3 BY person, BGP1 BY person PARALLEL $reducernum ; BGP1 = FOREACH BGP1 GENERATE $1 AS name, $2 AS inproc, $4 AS article, $5 AS person ; BGP1 = JOIN t4 BY inproc, BGP1 BY inproc PARALLEL $reducernum ; BGP1 = FOREACH BGP1 GENERATE $1 AS name, $2 AS inproc, $3 AS article, $4 AS person ; -- Project Project = FOREACH BGP1 GENERATE person, name ; -- Distinct Q5b = DISTINCT Project PARALLEL $reducernum ; STORE Q5b INTO '$outputdata' USING resultwriter.selectresultwriter() ; 10.5 Q6 (modifiziert) REGISTER SPARQL_UDFs.jar; indata = LOAD '$inputdata' USING rdfloader.exntriplesloader() ; -- BGP f0 = FILTER indata BY p == 'rdfs:subclassof' AND o == 'foaf:document' ; t0 = FOREACH f0 GENERATE s AS class ; f1 = FILTER indata BY p == 'rdf:type' ; t1 = FOREACH f1 GENERATE s AS document, o AS class ; f2 = FILTER indata BY p == 'dcterms:issued' ; t2 = FOREACH f2 GENERATE s AS document, o AS yr ; f3 = FILTER indata BY p == 'dc:creator' ; t3 = FOREACH f3 GENERATE s AS document, o AS author ; f4 = FILTER indata BY p == 'foaf:name' ; t4 = FOREACH f4 GENERATE s AS author, o AS name ; BGP1 = JOIN t0 BY class, t1 BY class PARALLEL $reducernum ; BGP1 = FOREACH BGP1 GENERATE $0 AS class, $1 AS document ; BGP1 = JOIN t2 BY document, t3 BY document, BGP1 BY document PARALLEL $reducernum ; BGP1 = FOREACH BGP1 GENERATE $1 AS yr, $3 AS author, $4 AS class, $5 AS document ; BGP1 = JOIN t4 BY author, BGP1 BY author PARALLEL $reducernum ; BGP1 = FOREACH BGP1 GENERATE $1 AS name, $2 AS yr, $3 AS author, $4 AS class, $5 AS document ;...

112 -- BGP f0 = FILTER indata BY p == 'rdfs:subclassof' AND o == 'foaf:document' ; t0 = FOREACH f0 GENERATE s AS class2 ; f1 = FILTER indata BY p == 'rdf:type' ; t1 = FOREACH f1 GENERATE s AS document2, o AS class2 ; f2 = FILTER indata BY p == 'dcterms:issued' ; t2 = FOREACH f2 GENERATE s AS document2, o AS yr2 ; f3 = FILTER indata BY p == 'dc:creator' ; t3 = FOREACH f3 GENERATE s AS document2, o AS author ; BGP2 = JOIN t0 BY class2, t1 BY class2 PARALLEL $reducernum ; BGP2 = FOREACH BGP2 GENERATE $0 AS class2, $1 AS document2 ; BGP2 = JOIN t2 BY document2, t3 BY document2, BGP2 BY document2 PARALLEL $reducernum ; BGP2 = FOREACH BGP2 GENERATE $1 AS yr2, $3 AS author, $4 AS class2, $5 AS document2 ; -- OPTIONAL j1 = JOIN BGP1 BY author LEFT OUTER, BGP2 BY author PARALLEL $reducernum; lj1 = FOREACH j1 GENERATE $0 AS name, $1 AS yr, $2 AS author, $3 AS class, $4 AS document, $5 AS yr2, $7 AS class2, $8 AS document2 ; SPLIT lj1 INTO OPTIONAL1 IF (document2 is null OR yr2 < yr), lj2 IF NOT(document2 is null OR yr2 < yr) ; lj3 = FOREACH lj2 GENERATE name, yr, author, class, document ; lj4 = DISTINCT lj3 PARALLEL $reducernum ; lj5 = JOIN lj4 BY (name, yr, author, class, document) LEFT OUTER, OPTIONAL1 BY (name, yr, author, class, document) PARALLEL $reducernum ; lj6 = FOREACH lj5 GENERATE $0 AS name, $1 AS yr, $2 AS author, $3 AS class, $4 AS document, $10 AS yr2, $11 AS class2, $12 AS document2 ; SPLIT lj6 INTO lj7 IF yr2 is null, trash IF yr2 is not null ; OPTIONAL1 = UNION OPTIONAL1, lj7 ; -- FILTER SPLIT OPTIONAL1 INTO FILTER1 IF (document2 is null), trash IF (document2 is not null) ; -- Project Q6 = FOREACH FILTER1 GENERATE yr, name, document ; STORE Q6 INTO '$outputdata' USING resultwriter.selectresultwriter() ; REGISTER SPARQL_UDFs.jar; indata = LOAD '$inputdata' USING rdfloader.exntriplesloader() ; -- BGP f0 = FILTER indata BY o == 'person:paul_erdoes' ; Q10 = FOREACH f0 GENERATE s AS subject, p AS predicate ; STORE BGP1 INTO '$outputdata' USING resultwriter.selectresultwriter() ;

Teamprojekt & Projekt

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

Mehr

PigSPARQL: Übersetzung von SPARQL nach Pig Latin

PigSPARQL: Übersetzung von SPARQL nach Pig Latin PigSPARQL: Übersetzung von SPARQL nach Pig Latin Alexander Schätzle, Martin Przyjaciel-Zablocki, Thomas Hornung, Georg Lausen Lehrstuhl für Datenbanken und Informationssysteme Albert-Ludwigs-Universität

Mehr

Verknüpfte Daten abfragen mit SPARQL. Thomas Tikwinski, W3C.DE/AT

Verknüpfte Daten abfragen mit SPARQL. Thomas Tikwinski, W3C.DE/AT Verknüpfte Daten abfragen mit SPARQL Thomas Tikwinski, W3C.DE/AT Agenda SPARQL Eine Anfragesprache für RDF Was ist eine SPARQL-Abfrage? Beispiel Arbeiten mit Variablen Komplexere Anfragen Filtern und sortieren

Mehr

PigSPARQL: Übersetzung von SPARQL nach Pig Latin

PigSPARQL: Übersetzung von SPARQL nach Pig Latin PigSPARQL: Übersetzung von SPARQL nach Pig Latin Alexander Schätzle, Martin Przyjaciel-Zablocki, Thomas Hornung, Georg Lausen Lehrstuhl für Datenbanken und Informationssysteme Albert-Ludwigs-Universität

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

Projektgruppe. Knowledge Representation Persistence and Reasoning

Projektgruppe. Knowledge Representation Persistence and Reasoning Projektgruppe Seminarvortrag von Stefan Middeke Knowledge Representation Persistence and Reasoning 4. Juni 2010 Überblick Motivation Repräsentation der Daten Speicherung und Abfrage von Daten Folgerungen

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

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

Eine völlig andere Form Abfragen zu erstellen ist, sie mit Hilfe der Datenbankabfragesprache SQL zu gestalten.

Eine völlig andere Form Abfragen zu erstellen ist, sie mit Hilfe der Datenbankabfragesprache SQL zu gestalten. Einführung SQL 2010 Niko Becker Mit unseren Übungen zu ACCESS können Sie Aufbau und Struktur einer relationalen Datenbank kennenlernen. Wir zeigen Ihnen wie Sie Tabellen, Formulare und Berichte erstellen

Mehr

Ressourcen-Beschreibung im Semantic Web

Ressourcen-Beschreibung im Semantic Web Ressourcen-Beschreibung im Semantic Web Cristina Vertan Inhaltsübersicht Wie sollen die Ressourcen für Semantic Web annotiert werden? Was ist und wie funktioniert RDF? Wie kodiert man RDF-Statements in

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

Uniform Resource Identifiers (URI) und Domain Name Service (DNS)

Uniform Resource Identifiers (URI) und Domain Name Service (DNS) Kurzvortrag zum Thema: Uniform Resource Identifiers (URI) und Domain Name Service (DNS) Beschreiben Sie Aufbau und Einsatzzweck von URI, URL und URN. Lesen Sie die dazu passenden RFCs. Was ist der Domain

Mehr

RDF und RDF Schema. Einführung in die Problematik Von HTML über XML zu RDF

RDF und RDF Schema. Einführung in die Problematik Von HTML über XML zu RDF RDF und RDF Schema Einführung in die Problematik Von HTML über XML zu RDF Kirsten Albrecht Roland Illig Probleme des HTML-basierten

Mehr

eingereicht von Martin

eingereicht von Martin ALBERT-LUDWIGS-UNIVERSITÄT FREIBURG INSTITUT FÜR INFORMATIK RDFPath Verteilte Analyse von RDF-Graphenn MASTERARBEIT eingereicht von Martin Przyjaciel-Zablocki am Lehrstuhl für Datenbanken und Informationssysteme

Mehr

Hadoop Demo HDFS, Pig & Hive in Action. Oracle DWH Konferenz 2014 Carsten Herbe

Hadoop Demo HDFS, Pig & Hive in Action. Oracle DWH Konferenz 2014 Carsten Herbe Hadoop Demo HDFS, Pig & Hive in Action Oracle DWH Konferenz 2014 Carsten Herbe Wir wollen eine semi-strukturierte Textdatei in Hadoop verarbeiten und so aufbereiten, dass man die Daten relational speichern

Mehr

Veranstalter: Lehrstuhl DBIS - Prof. Georg Lausen Betreuer: Thomas Hornung, Michael Schmidt 21.10.2008

Veranstalter: Lehrstuhl DBIS - Prof. Georg Lausen Betreuer: Thomas Hornung, Michael Schmidt 21.10.2008 Veranstalter: Lehrstuhl DBIS - Prof. Georg Lausen Betreuer: Thomas Hornung, Michael Schmidt 21.10.2008 Laut Studienordnung Master/Diplom: 16ECTS/15KP Entspricht: 480 Semesterstunden = 34h/Woche pp p.p.

Mehr

Informatik 12 Datenbanken SQL-Einführung

Informatik 12 Datenbanken SQL-Einführung Informatik 12 Datenbanken SQL-Einführung Gierhardt Vorbemerkungen Bisher haben wir Datenbanken nur über einzelne Tabellen kennen gelernt. Stehen mehrere Tabellen in gewissen Beziehungen zur Beschreibung

Mehr

Semantic Web Grundlagen

Semantic Web Grundlagen Birte Glimm Institut für Künstliche Intelligenz 19. Dez 2011 Semantic Web Grundlagen SPARQL Syntax & Intuition Foliensatz adaptiert von M. Krötzsch. Die nichtkommerzielle Vervielfältigung, Verbreitung

Mehr

OPERATIONEN AUF EINER DATENBANK

OPERATIONEN AUF EINER DATENBANK Einführung 1 OPERATIONEN AUF EINER DATENBANK Ein Benutzer stellt eine Anfrage: Die Benutzer einer Datenbank können meist sowohl interaktiv als auch über Anwendungen Anfragen an eine Datenbank stellen:

Mehr

Seminar Werkzeuggestütze. tze Softwareprüfung. fung. Slicing. Sebastian Meyer

Seminar Werkzeuggestütze. tze Softwareprüfung. fung. Slicing. Sebastian Meyer Seminar Werkzeuggestütze tze Softwareprüfung fung Slicing Sebastian Meyer Überblick Einführung und Begriffe Static Slicing Dynamic Slicing Erweiterte Slicing-Techniken Fazit 2 Was ist Slicing?? (I) Program

Mehr

SPARQL: Eine RDF Anfragesprache

SPARQL: Eine RDF Anfragesprache SPARQL: Eine RDF Anfragesprache Daniel Beck Seminar "Semantisches Web und Agenten" WS 2006/2007 Übersicht Motivation Einleitung in RDF Tripel Graph Semantik SPARQL Komplexität

Mehr

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

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

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

Übersetzung des Singapore Framework für Dublin-Core-Anwendungsprofile

Übersetzung des Singapore Framework für Dublin-Core-Anwendungsprofile Übersetzung des Singapore Framework für Dublin-Core-Anwendungsprofile Identifier: http://www.kimforum.org/material/pdf/uebersetzung_singapore_20090213.pdf Title: Übersetzung des Singapore Framework für

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

VBA-Programmierung: Zusammenfassung

VBA-Programmierung: Zusammenfassung VBA-Programmierung: Zusammenfassung Programmiersprachen (Definition, Einordnung VBA) Softwareentwicklung-Phasen: 1. Spezifikation 2. Entwurf 3. Implementierung Datentypen (einfach, zusammengesetzt) Programmablaufsteuerung

Mehr

Projektseminar Texttechnologische Informationsmodellierung

Projektseminar Texttechnologische Informationsmodellierung Projektseminar Texttechnologische Informationsmodellierung XQuery Ziele der Sitzung Nach dieser Sitzung sollten Sie: XQuery als wesentlichen Standard zur Abfrage von in XML kodierten Daten kennen Mit Hilfe

Mehr

4 Grundlagen der Datenbankentwicklung

4 Grundlagen der Datenbankentwicklung 4 Grundlagen der Datenbankentwicklung In diesem Kapitel werden wir die Grundlagen der Konzeption von relationalen Datenbanken beschreiben. Dazu werden Sie die einzelnen Entwicklungsschritte von der Problemanalyse

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

Hadoop. High Performance Batches in der Cloud. Hadoop. Folie 1 25. Januar 2011

Hadoop. High Performance Batches in der Cloud. Hadoop. Folie 1 25. Januar 2011 High Performance Batches in der Cloud Folie 1 Alles geht in die Cloud Image: Chris Sharp / FreeDigitalPhotos.net Cloud und Batches passen zusammen Batches Cloud Pay-per-Use Nur zeitweise genutzt Hohe Rechenkapazitäten

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

Hadoop. Eine Open-Source-Implementierung von MapReduce und BigTable. von Philipp Kemkes

Hadoop. Eine Open-Source-Implementierung von MapReduce und BigTable. von Philipp Kemkes Hadoop Eine Open-Source-Implementierung von MapReduce und BigTable von Philipp Kemkes Hadoop Framework für skalierbare, verteilt arbeitende Software Zur Verarbeitung großer Datenmengen (Terra- bis Petabyte)

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

APACHE PIG SEMINARARBEIT SSE - WS12/13 SEBASTIAN WALTHER

APACHE PIG SEMINARARBEIT SSE - WS12/13 SEBASTIAN WALTHER APACHE PIG SEMINARARBEIT SSE - WS12/13 SEBASTIAN WALTHER INHALT Das Hadoop Framework Hadoop s Distributed File System (HDFS) MapReduce Apache Pig Was ist Apache Pig & Pig Latin Anwendungsumgebungen Unterschied

Mehr

Datenbanken 16.1.2008. Die Entwicklung der Datenbanksysteme ist eng an die der Hardware gekoppelt und wird wie jene in Generationen eingeteilt:

Datenbanken 16.1.2008. Die Entwicklung der Datenbanksysteme ist eng an die der Hardware gekoppelt und wird wie jene in Generationen eingeteilt: Datenbanksysteme Entwicklung der Datenbanksysteme Die Entwicklung der Datenbanksysteme ist eng an die der Hardware gekoppelt und wird wie jene in Generationen eingeteilt: 1. Generation: In den fünfziger

Mehr

7. Übung - Datenbanken

7. Übung - Datenbanken 7. Übung - Datenbanken Informatik I für Verkehrsingenieure Aufgaben inkl. Beispiellösungen 1. Aufgabe: DBS a Was ist die Kernaufgabe von Datenbanksystemen? b Beschreiben Sie kurz die Abstraktionsebenen

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

Kapitel 33. Der xml-datentyp. In diesem Kapitel: Der xml-datentyp 996 Abfragen aus xml-datentypen 1001 XML-Indizierung 1017 Zusammenfassung 1023

Kapitel 33. Der xml-datentyp. In diesem Kapitel: Der xml-datentyp 996 Abfragen aus xml-datentypen 1001 XML-Indizierung 1017 Zusammenfassung 1023 Kapitel 33 Der xml-datentyp In diesem Kapitel: Der xml-datentyp 996 Abfragen aus xml-datentypen 1001 XML-Indizierung 1017 Zusammenfassung 1023 995 996 Kapitel 33: Der xml-datentyp Eine der wichtigsten

Mehr

Mengenvergleiche: Alle Konten außer das, mit dem größten Saldo.

Mengenvergleiche: Alle Konten außer das, mit dem größten Saldo. Mengenvergleiche: Mehr Möglichkeiten als der in-operator bietet der θany und der θall-operator, also der Vergleich mit irgendeinem oder jedem Tupel der Unteranfrage. Alle Konten außer das, mit dem größten

Mehr

Implementierung der XPath-Anfragesprache für XML-Daten in RDBMS unter Ausnutzung des Nummerierungsschemas DLN

Implementierung der XPath-Anfragesprache für XML-Daten in RDBMS unter Ausnutzung des Nummerierungsschemas DLN Vorstellung der Diplomarbeit Implementierung der XPath-Anfragesprache für XML-Daten in RDBMS unter Ausnutzung des Nummerierungsschemas DLN Oberseminar Datenbanken WS 05/06 Diplomand: Oliver Schmidt Betreuer:

Mehr

9. Einführung in Datenbanken

9. Einführung in Datenbanken 9. Einführung in Datenbanken 9.1 Motivation und einführendes Beispiel 9.2 Modellierungskonzepte der realen Welt 9.3 Anfragesprachen (Query Languages) 9.1 Motivation und einführendes Beispiel Datenbanken

Mehr

Schulinternes Curriculum im Fach Informatik

Schulinternes Curriculum im Fach Informatik Schulinternes Curriculum im Fach Informatik Unterricht in EF : 1. Geschichte der elektronischen Datenverarbeitung (3 Stunden) 2. Einführung in die Nutzung von Informatiksystemen und in grundlegende Begriffe

Mehr

Einführung in SQL Datenbanken bearbeiten

Einführung in SQL Datenbanken bearbeiten Einführung in SQL Datenbanken bearbeiten Jürgen Thomas Entstanden als Wiki-Buch Bibliografische Information Diese Publikation ist bei der Deutschen Nationalbibliothek registriert. Detaillierte Angaben

Mehr

Apache Lucene. Mach s wie Google! Bernd Fondermann freier Software Architekt bernd.fondermann@brainlounge.de berndf@apache.org

Apache Lucene. Mach s wie Google! Bernd Fondermann freier Software Architekt bernd.fondermann@brainlounge.de berndf@apache.org Apache Lucene Mach s wie Google! Bernd Fondermann freier Software Architekt bernd.fondermann@brainlounge.de berndf@apache.org 1 Apache Apache Software Foundation Software free of charge Apache Software

Mehr

Objektrelationale und erweiterbare Datenbanksysteme

Objektrelationale und erweiterbare Datenbanksysteme Objektrelationale und erweiterbare Datenbanksysteme Erweiterbarkeit SQL:1999 (Objekt-relationale Modellierung) In der Vorlesung werden nur die Folien 1-12 behandelt. Kapitel 14 1 Konzepte objekt-relationaler

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

ISU 1. Ue_08/02_Datenbanken/SQL. 08 Datenbanken. Übung. SQL Einführung. Eckbert Jankowski. www.iit.tu-cottbus.de

ISU 1. Ue_08/02_Datenbanken/SQL. 08 Datenbanken. Übung. SQL Einführung. Eckbert Jankowski. www.iit.tu-cottbus.de 08 Datenbanken Übung SQL Einführung Eckbert Jankowski www.iit.tu-cottbus.de Datenmodell (Wiederholung, Zusammenfassung) Objekte und deren Eigenschaften definieren Beziehungen zwischen den Objekten erkennen/definieren

Mehr

4. Datenabfrage mit QBE 11

4. Datenabfrage mit QBE 11 Informationsbestände analysieren Datenabfrage mit QBE 4. Datenabfrage mit QBE 11 4.1. QBE vs. SQL Relationale Datenbanken haben schon früh den Anspruch gestellt, auch für Nicht- Informatiker nutzbar zu

Mehr

MapReduce. www.kit.edu. Johann Volz. IPD Snelting, Lehrstuhl Programmierparadigmen

MapReduce. www.kit.edu. Johann Volz. IPD Snelting, Lehrstuhl Programmierparadigmen MapReduce Johann Volz IPD Snelting, Lehrstuhl Programmierparadigmen KIT Universität des Landes Baden-Württemberg und nationales Großforschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu Wozu MapReduce?

Mehr

Datenbanktechnologie für Data-Warehouse-Systeme

Datenbanktechnologie für Data-Warehouse-Systeme Wolfgang Lehner Datenbanktechnologie für Data-Warehouse-Systeme Konzepte und Methoden dpunkt.verlag 1 1.1 1.2 1.3 1.4 1. 5 2 2.1 2.2 2.3 Einleitung 1 Betriebswirtschaftlicher Ursprung des Data Warehousing...

Mehr

Graphen: Einführung. Vorlesung Mathematische Strukturen. Sommersemester 2011

Graphen: Einführung. Vorlesung Mathematische Strukturen. Sommersemester 2011 Graphen: Einführung Vorlesung Mathematische Strukturen Zum Ende der Vorlesung beschäftigen wir uns mit Graphen. Graphen sind netzartige Strukturen, bestehend aus Knoten und Kanten. Sommersemester 20 Prof.

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

etutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche

etutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche etutor Benutzerhandbuch Benutzerhandbuch XQuery Georg Nitsche Version 1.0 Stand März 2006 Versionsverlauf: Version Autor Datum Änderungen 1.0 gn 06.03.2006 Fertigstellung der ersten Version Inhaltsverzeichnis:

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

Speicherung von XML in (objekt-)relationalen Datenbanken. Burkhard Schäfer

Speicherung von XML in (objekt-)relationalen Datenbanken. Burkhard Schäfer Speicherung von XML in (objekt-)relationalen Datenbanken Burkhard Schäfer Übersicht Motivation Anforderungen Ansätze modellorientiert strukturorientiert Zusammenfassung Motivation Warum XML in Datenbanken

Mehr

Verteilte Auswertung von RDF-Graphen mit MapReduce und NoSQL-Datenbanken

Verteilte Auswertung von RDF-Graphen mit MapReduce und NoSQL-Datenbanken Bachelorarbeit Verteilte Auswertung von RDF-Graphen mit MapReduce und NoSQL-Datenbanken Antony R. Neu 26.08.2011 Albert-Ludwigs-Universität Freiburg im Breisgau Technische Fakultät Institut für Informatik

Mehr

Big Data und SQL - das passt! Philipp Loer ORDIX AG Paderborn

Big Data und SQL - das passt! Philipp Loer ORDIX AG Paderborn Schlüsselworte Hadoop, Hive, Sqoop, SQL Big Data und SQL - das passt! Philipp Loer ORDIX AG Paderborn Einleitung In diesem Vortrag werden, nach einer kurzen Einführung in Apache Hadoop, die beiden Werkzeuge

Mehr

6SHLFKHUXQJYRQ5')LQ'DWHQEDQNHQ

6SHLFKHUXQJYRQ5')LQ'DWHQEDQNHQ RDF in wissenschaftlichen Bibliotheken 6SHLFKHUXQJYRQ5')LQ'DWHQEDQNHQ Um die spezielle Problematik, die RDF im Zusammenhang mit der Speicherung in Datenbanken verursacht, zu diskutieren, sollen zunächst

Mehr

SQL SQL. SQL = Structured Query Language (SEQUEL) IBM San Jose Research Laboratory SYSTEM R. Grundlagen der Datenbanksysteme I

SQL SQL. SQL = Structured Query Language (SEQUEL) IBM San Jose Research Laboratory SYSTEM R. Grundlagen der Datenbanksysteme I SQL SQL = Structured Query Language (SEQUEL) IBM San Jose Research Laboratory SYSTEM R VII-1 Beispielrelationen Filiale ( Name Leiter Stadt Einlagen ) Konto ( KontoNr KundenNr FilialName Saldo ) Kredit

Mehr

Peter Dikant mgm technology partners GmbH. Echtzeitsuche mit Hadoop und Solr

Peter Dikant mgm technology partners GmbH. Echtzeitsuche mit Hadoop und Solr Peter Dikant mgm technology partners GmbH Echtzeitsuche mit Hadoop und Solr ECHTZEITSUCHE MIT HADOOP UND SOLR PETER DIKANT MGM TECHNOLOGY PARTNERS GMBH WHOAMI peter.dikant@mgm-tp.com Java Entwickler seit

Mehr

SOLISYON GMBH CHRISTIAN WOLF, BENJAMIN WEISSMAN. Optimierung von Abfragen in MS SQL Server DWH-Umgebungen

SOLISYON GMBH CHRISTIAN WOLF, BENJAMIN WEISSMAN. Optimierung von Abfragen in MS SQL Server DWH-Umgebungen WEITER BLICKEN. MEHR ERKENNEN. BESSER ENTSCHEIDEN. Optimierung von Abfragen in MS SQL Server DWH-Umgebungen SOLISYON GMBH CHRISTIAN WOLF, BENJAMIN WEISSMAN VERSION 1.0 OPTIMIERUNG VON ABFRAGEN IN MS SQL

Mehr

Datenbanken (WS 2015/2016)

Datenbanken (WS 2015/2016) Datenbanken (WS 2015/2016) Klaus Berberich (klaus.berberich@htwsaar.de) Wolfgang Braun (wolfgang.braun@htwsaar.de) 0. Organisatorisches Dozenten Klaus Berberich (klaus.berberich@htwsaar.de) Sprechstunde

Mehr

Was bisher geschah. deklarative Programmierung. funktionale Programmierung (Haskell):

Was bisher geschah. deklarative Programmierung. funktionale Programmierung (Haskell): Was bisher geschah deklarative Programmierung funktional: Programm: Menge von Termgleichungen, Term Auswertung: Pattern matsching, Termumformungen logisch: Programm: Menge von Regeln (Horn-Formeln), Formel

Mehr

Die Grundbegriffe Die Daten Die Informationen

Die Grundbegriffe Die Daten Die Informationen Die Grundbegriffe Die Daten sind diejenigen Elemente, die vom Computer verarbeitet werden. Die Informationen sind Wissenselemente, welche durch die Analyse von Daten erhalten werden können. Die Daten haben

Mehr

Vorwort zur 5. Auflage... 15 Über den Autor... 16

Vorwort zur 5. Auflage... 15 Über den Autor... 16 Vorwort zur 5. Auflage...................................... 15 Über den Autor............................................ 16 Teil I Grundlagen.............................................. 17 1 Einführung

Mehr

RDF RESOURCE DESCRIPTION FRAMEWORK. Referentin: Claudia Langer

RDF RESOURCE DESCRIPTION FRAMEWORK. Referentin: Claudia Langer RDF RESOURCE DESCRIPTION FRAMEWORK Referentin: Claudia Langer Überblick RDF allgemein RDF und XML Praktisches Beispiel RDF allgemein vom WWW Konsortium (W3C) für das Semantic Web entwickelt Sprache zur

Mehr

Tutorübung zur Vorlesung Grundlagen Rechnernetze und Verteilte Systeme Übungsblatt 12 (8. Juli 12. Juli 2013)

Tutorübung zur Vorlesung Grundlagen Rechnernetze und Verteilte Systeme Übungsblatt 12 (8. Juli 12. Juli 2013) Technische Universität München Lehrstuhl Informatik VIII Prof. Dr.-Ing. Georg Carle Dipl.-Ing. Stephan Günther, M.Sc. Nadine Herold, M.Sc. Dipl.-Inf. Stephan Posselt Tutorübung zur Vorlesung Grundlagen

Mehr

Die Java Stream API. Funktionale Programmierung mit der Stream API des JDK 1.8. Prof. Dr. Nikolaus Wulff

Die Java Stream API. Funktionale Programmierung mit der Stream API des JDK 1.8. Prof. Dr. Nikolaus Wulff Die Java Stream API Funktionale Programmierung mit der Stream API des JDK 1.8 Prof. Dr. Nikolaus Wulff Funktionale Programmierung Neben der Collection API mit default Methoden ist als weitere Neuerung

Mehr

Gliederung. Tutorium zur Vorlesung. Gliederung. Gliederung. 1. Gliederung der Informatik. 1. Gliederung der Informatik. 1. Gliederung der Informatik

Gliederung. Tutorium zur Vorlesung. Gliederung. Gliederung. 1. Gliederung der Informatik. 1. Gliederung der Informatik. 1. Gliederung der Informatik Informatik I WS 2012/13 Tutorium zur Vorlesung 1. Alexander Zietlow zietlow@informatik.uni-tuebingen.de Wilhelm-Schickard-Institut für Informatik Eberhard Karls Universität Tübingen 11.02.2013 1. 2. 1.

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Proseminar: Website-Management-Systeme

Proseminar: Website-Management-Systeme Proseminar: Website-Management-Systeme Thema: Web: Apache/Roxen von Oliver Roeschke email: o_roesch@informatik.uni-kl.de Gliederung: 1.) kurze Einleitung 2.) Begriffsklärung 3.) Was ist ein Web? 4.) das

Mehr

Motivation. Inhalt. URI-Schemata (1) URI-Schemata (2)

Motivation. Inhalt. URI-Schemata (1) URI-Schemata (2) 14. URIs Uniform Resource Identifier 14-1 14. URIs Uniform Resource Identifier 14-2 Motivation Das WWW ist ein Hypermedia System. Es enthält: Resourcen (Multimedia Dokumente) Verweise (Links) zwischen

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

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

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

OWL Web Ontology Language

OWL Web Ontology Language OWL Web Ontology Language Hauptseminar Ontologien in Informatik und Linguistik SS 2007 Bianca Selzam 27.4.2007 Gliederung 1. Einleitung 2. Resource Description Framework (RDF) 3. Resource Description Framework

Mehr

SQL. strukturierte Datenbankabfragesprache eine Datenbanksprache zur. Structured Query Language:

SQL. strukturierte Datenbankabfragesprache eine Datenbanksprache zur. Structured Query Language: SQL Structured Query Language: strukturierte Datenbankabfragesprache eine Datenbanksprache zur Definition, Abfrage und Manipulation von Daten in relationalen Datenbanken In der SQL-Ansicht arbeiten In

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

SQL für Trolle. mag.e. Dienstag, 10.2.2009. Qt-Seminar

SQL für Trolle. mag.e. Dienstag, 10.2.2009. Qt-Seminar Qt-Seminar Dienstag, 10.2.2009 SQL ist......die Abkürzung für Structured Query Language (früher sequel für Structured English Query Language )...ein ISO und ANSI Standard (aktuell SQL:2008)...eine Befehls-

Mehr

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

Mehr

KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 1/13. Dokumentation KREDITVERZEICHNIS. Teil 2. Konfiguration

KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 1/13. Dokumentation KREDITVERZEICHNIS. Teil 2. Konfiguration KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 1/13 Dokumentation KREDITVERZEICHNIS Teil 2 Konfiguration Stand 20.02.2013 KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 2/13 Inhalt 1. KONFIGURATION...

Mehr

Generalisierung von großen Datenbeständen am Beispiel der Gebäudegeneralisierung mit CHANGE

Generalisierung von großen Datenbeständen am Beispiel der Gebäudegeneralisierung mit CHANGE Institut für Kartographie und Geoinformatik Leibniz Universität Hannover Generalisierung von großen Datenbeständen am Beispiel der Gebäudegeneralisierung mit CHANGE Frank Thiemann, Thomas Globig Frank.Thiemann@ikg.uni-hannover.de

Mehr

Graphenalgorithmen und lineare Algebra Hand in Hand Vorlesung für den Bereich Diplom/Master Informatik

Graphenalgorithmen und lineare Algebra Hand in Hand Vorlesung für den Bereich Diplom/Master Informatik Vorlesung für den Bereich Diplom/Master Informatik Dozent: Juniorprof. Dr. Henning Meyerhenke PARALLELES RECHNEN INSTITUT FÜR THEORETISCHE INFORMATIK, FAKULTÄT FÜR INFORMATIK KIT Universität des Landes

Mehr

Einführung in Hadoop & MapReduce. Dr. Kathrin Spreyer Big Data Engineer

Einführung in Hadoop & MapReduce. Dr. Kathrin Spreyer Big Data Engineer Einführung in Hadoop & MapReduce Dr. Kathrin Spreyer Big Data Engineer München, 19.06.2013 Agenda Einleitung 1. HDFS 2. MapReduce 3. APIs 4. Hive & Pig 5. Mahout Tools aus Hadoop-Ökosystem 6. HBase 2 Worum

Mehr

Vorlesung 30.03.2009 1) Einführung

Vorlesung 30.03.2009 1) Einführung Vorlesung 30.03.2009 1) Einführung Was versteht man unter dem Begriff Datenbank? - Eine Datenbank ist eine Struktur zur Speicherung von Daten mit lesendem und schreibendem Zugriff - Allgemein meint man

Mehr

1. Der Begriff Informatik 2. Syntax und Semantik von Programmiersprachen. I.2. I.2. Grundlagen von von Programmiersprachen.

1. Der Begriff Informatik 2. Syntax und Semantik von Programmiersprachen. I.2. I.2. Grundlagen von von Programmiersprachen. 1. Der Begriff Informatik 2. Syntax und Semantik von Programmiersprachen I.2. I.2. Grundlagen von von Programmiersprachen. - 1 - 1. Der Begriff Informatik "Informatik" = Kunstwort aus Information und Mathematik

Mehr

!"#$"%&'()*$+()',!-+.'/',

!#$%&'()*$+()',!-+.'/', Soziotechnische Informationssysteme 5. Facebook, Google+ u.ä. Inhalte Historisches Relevanz Relevante Technologien Anwendungsarchitekturen 4(5,12316,7'.'0,!.80/6,9*$:'0+$.;.,&0$'0, 3, Historisches Facebook

Mehr

Was ist ein Compiler?

Was ist ein Compiler? Was ist ein Compiler? Was ist ein Compiler und worum geht es? Wie ist ein Compiler aufgebaut? Warum beschäftigen wir uns mit Compilerbau? Wie ist die Veranstaltung organisiert? Was interessiert Sie besonders?

Mehr

Semantic Web Grundlagen

Semantic Web Grundlagen Semantic Web Grundlagen Lösung zur Übung 5: SPARQL Birte Glimm WS 2011/2012 Lösung (5.1. (a Objekte, die um die Sonne oder um einen Satelliten der Sonne kreisen. { ex:sonne ex:satellit?objekt. UNION {

Mehr

Definition der Schnittstelle zur Übertragung der. gemäß Deponieselbstüberwachungsverordnung NRW

Definition der Schnittstelle zur Übertragung der. gemäß Deponieselbstüberwachungsverordnung NRW Jahresberichte gemäß Deponieselbstüberwachungsverordnung NRW Inhaltsverzeichnis... 1 Historie der Änderungen... 2 Einleitung... 2 Rückblick... 2 Auswirkungen der neuen Verordnung... 2 Auslieferung... 2

Mehr

3 Variablen. 3.1 Allgemeines. 3.2 Definition und Verwendung von Variablen

3 Variablen. 3.1 Allgemeines. 3.2 Definition und Verwendung von Variablen 3 Variablen 3.1 Allgemeines Variablen werden in Prozeduren, Mustern und Parameter-Dokumenten definiert und verwendet und bei der Jobgenerierung durch die Werte, die ihnen zugewiesen werden, ersetzt. Variablen

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

SQL (Structured Query Language) Schemata Datentypen

SQL (Structured Query Language) Schemata Datentypen 2 SQL Sprachelemente Grundlegende Sprachelemente von SQL. 2.1 Übersicht Themen des Kapitels SQL Sprachelemente Themen des Kapitels SQL (Structured Query Language) Schemata Datentypen Im Kapitel SQL Sprachelemente

Mehr

Auswertung der Workload-Befragung mit MS ACCESS

Auswertung der Workload-Befragung mit MS ACCESS Auswertung der Workload-Befragung mit MS ACCESS Inhaltsverzeichnis 1. Aufbereitung der Daten... 2 1.1. Herstellung der Textfiles... 2 1.2. Import der Textdateien... 3 1.3. Verbindungen erstellen... 8 2.

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

1 Die Active Directory

1 Die Active Directory 1 Die Active Directory Infrastruktur Prüfungsanforderungen von Microsoft: Configuring the Active Directory Infrastructure o Configure a forest or a domain o Configure trusts o Configure sites o Configure

Mehr

30. Juni 2006 - Technische Universität Kaiserslautern. Paul R. Schilling

30. Juni 2006 - Technische Universität Kaiserslautern. Paul R. Schilling 30. Juni 2006 - Technische Universität Kaiserslautern Paul R. Schilling ! " #$% & '( ( ) *+, - '. / 0 1 2("$ DATEN SIND ALLGEGENWÄRTIG Bill Inmon, father of data warehousing Unternehmen In einer vollkommenen

Mehr

Vorlesung Semantic Web. Vorlesung im Wintersemester 2012/2013 Dr. Heiko Paulheim Fachgebiet Knowledge Engineering

Vorlesung Semantic Web. Vorlesung im Wintersemester 2012/2013 Dr. Heiko Paulheim Fachgebiet Knowledge Engineering Vorlesung Semantic Web Vorlesung im Wintersemester 2012/2013 Dr. Heiko Paulheim Fachgebiet Knowledge Engineering Was bisher geschah Was wir bisher kennen gelernt haben: RDF und RDF Schema als Sprachen

Mehr

Semantic Markup für die Dokumentenklassifizierung. Seminarvortrag von Mirko Pracht

Semantic Markup für die Dokumentenklassifizierung. Seminarvortrag von Mirko Pracht Semantic Markup für die Dokumentenklassifizierung Seminarvortrag von Mirko Pracht Ziel des Vortrags Aufbau digitaler Bibliotheken Verbesserung Informationssuche Semantic Markup Gliederung 1. Grundlagen

Mehr