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

Transkript

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

2 Anyone can build a fast CPU. The trick is to build a fast system. - Seymour Cray

3 Bearbeitungszeitraum Gutachter Prof. Dr. Georg Lausen Betreuer Alexander Schätzle Martin Przyjaciel-Zablocki

4 Kurzfassung In der vorliegenden Arbeit wird die Speicherung und Auswertung von RDF-Daten mit der Kombination aus dem Apache Hadoop Framework und der NoSQL-Datenbank Cassandra untersucht. Cassandra ermöglicht die verteilte Speicherung der Daten und vereint dabei die Eigenschaften von Google BigTable und Amazon Dynamo. Um SPARQL Basic Graph Pattern-Anfragen auf den RDF-Daten parallel auszuwerten, wird das quelloffene Projekt Apache Hadoop verwendet. Dabei wird die Komponente MapReduce des Frameworks zur Berechnung der notwendigen Verbünde eingesetzt, während das verteilte Dateisystem HDFS der Speicherung der Zwischenergebnisse dient. Nachdem die Strategien zur Auswertung und Speicherung vorgestellt wurden, werden die technischen Details der Implementierung erläutert. Anschließend wird die Implementierung mit synthetisch generierten Daten evaluiert. Die Evaluation liefert zwar gute Laufzeiten bei der Auswertung der Daten, jedoch zeigen sich Probleme bei der Systemstabilität. Schlagwörter: MapReduce, Hadoop, Cassandra, NoSQL, RDF Triple Store, SP 2 Bench, Map-Side-Join 1

5 Inhaltsverzeichnis Kurzfassung 1 1 Einführung 4 2 Grundlagen Semantic Web Resource Description Framework SPARQL Apache Hadoop Apache Cassandra Datenmodell Verteilung der Daten im Cluster Datenzugriff Strategien zur Auswertung und Speicherung der RDF-Daten Speicherstrategie Auswertungsstrategie Implementierung und Optimierungen Einlesen der Daten Auswerten der Anfragen Generieren der Jobs Map-Side Join Alternativen zum Map-Side Join Optimierung für Hadoop Evaluation Allgemeine Rahmenbedingunen

6 5.2 Laufzeiten und Beobachtungen Q Q Q3A Q Einfluss des Konsistenzgrads Einfluss des Replikationsfaktors Datenverteilung Probleme und mögliche Ursachen Verwandte Arbeiten 43 7 Zusammenfassung Ausblick

7 1 Einführung Die Idee des Semantic Web, die im Jahr 2001 von Tim Berners-Lee vorgestellt wurde, ermöglicht Maschinen das automatische Ableiten von Wissen aus dem World Wide Web. Das stichwortbasierte World Wide Web, das man heute größtenteils vorfindet, verhindert, dass Maschinen die Semantik hinter den Wörtern verstehen. Das Resource Description Framework (RDF) wurde entwickelt, um eine Ressource mit semantischen Annotationen zu versehen [1]. Eine Ressource kann nicht nur eine Webseite sein, sondern jede Entität, die sich durch eine eindeutige URI (Unique Resource Identifier) identifizieren lässt. Die Vision des Semantic Web funktioniert nur dann, wenn es möglich ist, die riesigen Daten auszuwerten. Die Speicherung und Analyse der Datensätze können oft nicht von einem Rechner alleine realisiert werden. Auch Supercomputer bieten keine Alternative, denn das Semantic Web soll allen, auch kleineren Firmen oder Institutionen zur Verfügung stehen. Abhilfe schafft das Konzept des Cloud Computing: Die Berechnungen finden nicht mehr lokal statt, sondern werden an ein skalierbares Rechnernetz ausgelagert. Firmen wie Amazon und Rackspace vermieten solche Rechnernetze (Clouds), deren Leistung und Kosten sich nach der tatsächlichen Rechenlast richten. Zur Nutzung dieser skalierbaren Systeme bedarf es Anwendungen und Frameworks, die diese Form der Berechnungen unterstützen. Hadoop MapReduce ist eine quelloffene Implementierung des MapReduce-Frameworks, das ursprünglich von Google entwickelt worden ist. Es ermöglicht das Speichern großer Daten auf dem verteilten Dateisystem HDFS (Hadoop Distributed File System) und das Anwenden von Programmen auf diesen Daten. Facebook und Twitter setzen diese Technologie ein, um tausende Petabyte an Daten zu verwalten. Die Daten können nicht nur blockweise auf dem verteilten Dateisystem, sondern auch strukturiert mit Indizes in Datenbanken gespeichert werden. Das Hadoop-Projekt beinhaltet zu diesem Zweck eine eigene NoSQL-Datenbank HBase, die bereits zur Speicherung und Auswertung von RDF-Daten untersucht worden ist [2]. NoSQL- 4

8 Einführung Datenbanken zeichnen sich durch den Verzicht auf Schemata zur besseren horizontalen Skalierung aus. Cassandra ist eine weitere NoSQL-Datenbank, mit der Firmen wie beispielsweise Facebook, Digg und Twitter gute Erfahrungen gemacht haben. Ziel dieser Arbeit ist es, die Eigenschaften, die sich aus der Kombination von Cassandra mit MapReduce ergeben, in Hinblick auf die Auswertung von SPARQL Basic Graph Patterns auf großen RDF-Graphen zu untersuchen. Die Arbeit beschränkt sich auf das Auswerten einer Folge von SPARQL Basic Graph Patterns mit maximal zwei Variablen pro Tripel. Hierfür wurde eine Implementierung entwickelt, die die Besonderheiten des Datenmodells zum schnellen Zugriff auf die Daten ausnutzt. Die Arbeit ist wie folgt aufgebaut: In Kapitel 2 werden die Grundlagen des Semantic Webs und der verwendeten Technologien vorgestellt. Darauf aufbauend werden im folgenden Kapitel die allgemeinen Strategien zur Auswertung und Speicherung der RDF-Daten vorgestellt. Kapitel 4 erläutert wie diese Strategien in der Implementierung technisch umgesetzt worden sind. Die Ergebnisse der Evaluation werden in Kapitel 5 vorgestellt. Es wurden sowohl das Verhalten bei verschiedenen Datengrößen, als auch der Einfluss verschiedener Parameter untersucht. In Kapitel 6 werden verwandte Arbeiten vorgestellt und die Unterschiede aufgezeigt. Abschließend wird in Kapitel 7 ein Fazit und Ausblick gegeben. 5

9 2 Grundlagen 2.1 Semantic Web Im Jahr 2001 stellte Tim Berners-Lee, der Direktor des W3C, seine Vision des Semantic Webs in einem Artikel in Scientific American vor [1]. Das Semantic Web soll nach Lee nicht das damalige World Wide Web ersetzen, sondern eine Erweiterung dessen sein. Webseiten sind größtenteils so aufgebaut, dass Menschen sie lesen und verstehen können, Maschinen allerdings nicht. Maschinen können nicht erkennen, ob mit dem Wort Bank das Finanzinstitut oder eine Sitzmöglichkeit im Park gemeint ist. Das Semantic Web erlaubt es Maschinen, Wissen aus Webseiten zu gewinnen und diese zu verknüpfen. In dem Artikel beschreibt Berners-Lee, dass es im Semantic Web intelligenten Systemen möglich sein wird, Informationen für die Benutzer zu gewinnen und zu verbinden, die sie sonst selbst recherchieren müssten. Dies sei nur mit einem offenen Standard möglich, der jedoch bis heute noch nicht ausreichend verwendet wird [3]. Seiten wie Wikipedia, Twitter oder Flickr stellen zwar diese Informationen bereit, da sie aber nicht gemeinsam offene Standards verwenden, können sie nicht miteinander verknüpft werden Resource Description Framework Das Resource Description Framework (RDF) ist ein W3C-Standard, der es ermöglicht, Inhalte von Webseiten mit ihrer Bedeutung zu verknüpfen [4]. Das Hauptelement eines RDF-Dokuments ist die sogenannte Aussage. Sie besteht aus drei Elementen: Subjekt, Prädikat und Objekt. Das Subjekt ist eine URI (Unique Resource Identifier), die eindeutig eine Ressource, z.b. eine Person, beschreibt. Das Prädikat ist ebenfalls eine URI und dient der Beschreibung der Relation zwischen Subjekt und Objekt. Beim Objekt handelt es sich entweder um eine URI, wenn eine Beziehung zwischen zwei Ressourcen hergestellt werden soll, oder um ein Literal, 6

10 2.1 Semantic Web zum Beispiel eine Zahl [3]. Sollen Subjekt oder Objekt nicht benannt werden, kann auch ein sogenannter leerer Knoten anstatt einer URI verwendet werden. Dadurch lassen sich Beziehungen zu Objekten modellieren, die nicht bekannt sind oder nicht benannt werden sollen. Betrachtet man die Aussagen als eine vom Subjekt ausgehende gerichtete Kante zwischen Subjekt und Objekt, die mit dem Prädikat beschriftet wird, so ergibt sich ein gerichteter Graph für das RDF-Dokument, der als RDF- Graph bezeichnet wird. Abb. 2.1 zeigt ein Beispiel eines solchen RDF-Graphen, der Informationen zur Person Eric Miller beschreibt. Abbildung 2.1: Beispiel eines RDF-Graphen. Quelle: [5] Die Person wird dabei eindeutig anhand der URI EM/contact#me identifiziert, sodass es zu keinen Mehrdeutigkeiten kommen kann. Als Enkodierung wird häufig die XML-Syntax oder die Turtle-Syntax (Terse RDF Triple Language 1 ) gewählt, während Letztere leichter für Menschen zu lesen ist und im Folgenden verwendet wird. In der Turtle-Syntax werden Aussagen wie Sätze der natürlichen Sprache mit der Reihenfolge Subjekt, Prädikat und Objekt geschrieben und mit einem Punkt beendet. Zur Abkürzung können für jedes RDF-Dokument Präfixe definiert werden, die automatisch ergänzt werden. Einige Tripel des RDF- Graphen aus Abb. 2.1 werden demnach wie in Listing 2.1 dargestellt enkodiert

11 2.1 Semantic r d f : <http : / /www. w3. org /1999/02/22 rdf syntax contact : <http : / /www. w3. org /2000/10/ swap/pim/ contact#>. http : / /www. w3. org / People /EM/ contact#me r d f : type contact : Person. http : / /www. w3. org / People /EM/ contact#me contact : fullname Eric M i l l e r. http : / /www. w3. org / People /EM/ contact#me contact : mailbox mailto :em@w3. org. Listing 2.1: Beispielhaft Enkodierung von RDF-Daten Datenspeicher für RDF-Tripel werden häufig als Triple-Stores bezeichnet. Die Funktionalität solcher Stores reicht von einfachen Datenspeichern bis hin zu ausgereiften Datenbanksystemen, die Anfragen auf RDF-Daten auswerten können. Vertreter solcher ausgereifter Triple-Stores sind beispielsweise Sesame 2 und Jena SPARQL SPARQL (SPARQL Protocol And RDF Query Language) ist eine Anfragesprache für RDF-Daten, ähnlich SQL für relationale Datenbanken. Seit dem 15. Januar 2008 ist SPARQL eine offizielle Empfehlung des W3C (W3C recommendation) [6]. Diese Einführung soll im Wesentlichen nur den Teil der Syntax abdecken, der auch von der Implementierung unterstützt wird. Zum leichteren Verständnis, wird die Syntax anhand eines Beispiels aus [4] eingeführt. PREFIX ex < SELECT?titel?author WHERE {?buch ex:verlegtbei < ex:titel?titel.?buch ex:autor?autor. } Listing 2.2: Beispielhafte SPARQL-Anfrage (Quelle: [4]) Die in Listing 2.2 dargestellte Anfrage gibt die Titel und Autoren aller Bücher, die beim Springer-Verlag verlegt wurden, zurück. Wie im Beispiel zu sehen ist, besteht eine SPARQL-Anfrage zum größten Teil aus RDF-Tripeln, die in Turtle-Syntax geschrieben sind. Die Tripel beschreiben einen Subgraph des RDF-Graphen, auf den

12 2.1 Semantic Web man die Anfrage stellt. An jeder Tripelposition (Subjekt, Prädikat oder Objekt) ist es möglich, eine Variable zu platzieren, die durch ein? gekennzeichnet wird. Eine Menge solcher Tripel wird als Basic Graph Pattern bezeichnet. Die Formatierung der Ausgabe erfolgt mit dem Befehl SELECT gefolgt von einer Teilmenge der verwendeten Variablen, d. h. es werden nur die Werte der Variablen ausgegeben, die nach SELECT aufgeführt werden. Wie bei der Deklaration von RDF-Daten ist es möglich Präfixe zu definieren, um gekürzte Schreibweisen zu verwenden. SPARQL erlaubt weitere Befehle wie zum Beispiel FILTER, LIMIT und UNION, um die Ergebnisse weiter einzuschränken oder zu erweitern. PREFIX ex < SELECT?titel?author WHERE {?buch ex:titel?titel.?buch ex:autor?autor. {?buch ex:verlegtbei < UNION {?buch ex:verlegtbei < } } Listing 2.3: Beispielhafte SPARQL-Anfrage mit Operatoren Die Anfrage, die in Listing 2.3 dargestellt ist, selektiert alle Paare aus Titel und Autor der Verlage Springer und O Reilly. Diese weiteren Befehle werden im Folgenden in dieser Arbeit nicht weiter betrachtet, da sie von der Implementierung nicht unterstützt werden. Ebenso erfolgt keine Formatierung durch SELECT. Die Implementierung beschränkt sich auf die Auswertung von Anfragen, die aus einem Basic Graph Pattern bestehen. Weiterhin wird angenommen, dass pro Tripel nicht mehr als zwei Variablen vorkommen. Die Anfragen haben also alle die Form, die in Listing 2.4 dargestellt wird. 9

13 2.2 Apache Hadoop PREFIX p1 <uri> PREFIX... SELECT * WHERE { s1 p1?v1. }?v1 p2 o2.... Listing 2.4: SPARQL-Anfrage, die von der Implementierung unterstützt wird. 2.2 Apache Hadoop Hadoop ist ein quelloffenes Projekt mit vielen Unterprojekten zur Speicherung und Analyse großer Daten, das seine Wurzeln im Apache Nutch 4 Projekt hat. Hadoop wurde ursprünglich von Doug Cutting entwickelt und basiert auf dem verteilten Dateisystem Google FS, sowie Google MapReduce, einem Framework für nebenläufige Berechnungen über große Daten. MapReduce wurde ebenfalls von Google zur Wartung der Suchindizes entwickelt. Die beiden Technologien wurden 2003 und 2004 in [7, 8] vorgestellt. Seit 2006 beteiligt sich Yahoo an dem Projekt und entwickelte zwischenzeitlich seine eigene Distribution wurde das Projekt zu einem offiziellen Apache Top-Level-Projekt und wurde seitdem von Unternehmen wie Last.fm, Facebook und der NewYork-Times eingesetzt [9]. Das Projekt besteht aus mehreren Bestandteilen und Unterprojekten, unter anderem: Pig, Hive und HBase. Letzteres ist eine NoSQL Datenbank, die Ähnlichkeiten zu Cassandra aufweist, jedoch auf Hadoop basiert. Pig vereinfacht die Analyse von Daten und stellt häufig genutze Methoden, z.b. Joins bereit. Hive ist eine Datawarehouse-Applikation, die eine SQL-ähnliche Sprache zur Analyse der auf dem HDFS gespeicherten Daten implementiert. Im Folgenden wird ausschließlich auf die Bestandteile MapReduce und HDFS eingegangen, da sie in der Implementierung verwendet wurden. Eine wichtige Kernidee von MapReduce ist die Ausnutzung von Lokalität. Die Daten werden mittels HDFS auf den verschiedenen Rechnern (Knoten) im Netzwerk gespeichert. Möchte eine Anwendung auf die Daten zugreifen, greift jeder Knoten

14 2.3 Apache Cassandra auf die Daten zu, die ihm lokal zur Verfügung stehen. Dadurch werden weniger Daten über das Netzwerk ausgetauscht und im Idealfall haben alle Knoten die gleiche Größe an Daten zu verarbeiten. Damit dies möglich ist, müssen die Anwendungen dem Map-Reduce-Paradigma folgen. Das Paradigma besagt, dass jedes Programm, ein sogenannter Job, aus einer Map- und einer Reduce-Phase besteht. Ein Knoten verarbeitet zunächst mehrere Map-Tasks, die eine Teilmenge der Daten (Inputsplits) als Eingabe erhalten. Die Inputsplits sind lokal auf dem Knoten gespeichert. Eine Eingabe besteht immer aus einem Schlüssel und einem Wert, ebenso die Ausgabe der Mapper (MapInputKey, MapInputValue, MapOutputKey und MapOutputValue). Nach der Map-Phase werden die Daten anhand des MapOutputKey sortiert und zusammengefasst. Sie werden dann an Reduce-Tasks, die auf anderen Knoten laufen können, geschickt. Ein Reduce-Task erhält einen Schlüssel (ReduceInputKey) und eine Menge von Werten (ReduceInputValues) als Eingabe. Die Ausgabe der Reducer ist ebenfalls ein Schlüssel und ein zugehöriger Wert. Das Format des ReduceInputKey ist identisch mit dem Format des MapOutputKey. Die Eingabewerte sind die Werte, die sortiert und zusammengefasst worden sind, und den gleichen MapOutputKey haben. Es ist also gewährleistet, dass allen Reduce-Tasks jeweils alle diejenigen Werte zur Verfügung stehen, die mit dem gleichen MapOutputKey versehen worden sind. Schließlich werden nach der Verarbeitung in der Reduce-Phase ReduceOutputKey und ReduceOutputValue auf das HDFS geschrieben. Abb. 2.2 visualisiert den Workflow einer MapReduce-Anwendung[9, 10]. Setzt man die Anzahl der Reduce-Tasks auf null, so erfolgt weder eine Sortierung noch eine weitere Verarbeitung durch den Reducer. Die Ergebnisse der Map-Phase werden direkt in das HDFS geschrieben. Das bedeutet, dass auch kein Austausch der Daten über das Netzwerk erfolgt, wie es beim Sortieren und Zusammenfassen vor der Reduce-Phase der Fall wäre. 2.3 Apache Cassandra Klassiche SQL-Datenbanken haben sich in allen Bereichen der Informatik fest etabliert. Wachsende Datenmengen erfordern jedoch eine Möglichkeit der Skalierung bei der Analyse der Daten. Um dieser Nachfrage gerecht zu werden, entstanden die sogenannten NoSQL-Datenbanken ( not only SQL oder no SQL ). Eine Gemeinsam- 11

15 2.3 Apache Cassandra Abbildung 2.2: MapReduce Workflow. Quelle: [10] keit aller NoSQL-Datenbanken, ist der Verzicht auf fixe Schemata zu Gunsten einer besseren horizontalen Skalierung. Weitere Gemeinsamkeiten sind die verteilte Speicherung der Daten, dynamische Anpassung der gespeicherten Daten und der Verzicht auf ACID-Eigenschaften wie sie bei SQL-Systemen üblich sind. Momentan gibt es mehr als hundert verschiedene NoSQL-Datenbanken 5 mit verschiedenen Datenmodellen. Sie lassen sich u. a. in dokumentenorientierte Datenbanken (CouchDB 6 ), Graphendatenbanken (Neo4J 7 ) oder Objektdatenbanken (ZODB 8 ) einteilen. Cassandra fällt in die Kategorie Key-Value-Store [11, 12]. Cassandras Datenmodell basiert auf der NoSQL-Datenbank Google Bigtable, während die Verteilung der Daten Gemeinsamkeiten mit Amazon Dynamo aufweist. Ursprünglich wurde es von Facebook entwickelt, um das Durchsuchen des Nachrichtensystems zu realisieren. Seit 2010 ist das Projekt ein Top-Level-Projekt der Apache Foundation

16 2.3 Apache Cassandra Datenmodell Das Grundelement des Datenmodells ist die Spalte (engl. column). Eine Spalte besteht aus drei Elementen: einem Schlüssel, einem Wert und einem Zeitstempel. Der Zeitstempel wird verwendet, um eventuell auftretende Konflikte in der verteilten Datenmenge zu lösen. Der Schlüssel und der Wert lassen sich als Abbildung verstehen, in der der Schlüssel auf den Wert abgebildet wird. Eine Spalte kann auch weitere Spalten enthalten und wird in diesem Fall als Superspalte (engl. super column) bezeichnet. Superspalten haben keinen Zeitstempel, da die Subspalten Zeitstempel enthalten. Ein Datensatz besteht aus mehreren Spalten oder Superspalten und wird als Zeile (engl. row) bezeichnet. Der Datensatz wird eindeutig anhand seines Zeilenschlüssels (engl. row key) identifiziert [11]. Datensätze werden in Spaltenfamilien (engl. column families) zusammengefasst, ähnlich den Tabellen in SQL. Eine Spaltenfamilie kann nur entweder Spalten oder Superspalten enthalten. Enthält sie Letzteres handelt es sich um eine Superspaltenfamilie. Im Gegensatz zum relationalen Datenmodell, hat nicht jeder Datensatz die gleiche Anzahl Columns. Ebenso können Datensätze frei um weitere Columns erweitert werden. In relationalen Datenbanken wäre eine Änderung der Tabelle notwendig. Mehre Spaltenfamilien werden in einem Keyspace zusammengefasst. Ein alternativer Ansatz ist das Betrachten des Datenmodells als multidimensionale Map. Abhängig davon, ob Superspaltenfamilien oder Spaltenfamilien verwendet werden, ergibt sich eine Map mit 4 oder 5 Dimensionen, die in Listing 2.5 dargestellt wird. Keyspace [ ColumnFamilyName ] [ Rowkey ] [ Columnname ] = value Keyspace [ ColumnFamilyName ] [ Rowkey ] [ SuperColName ] [ SubColName ] = v a l u e Listing 2.5: Cassandras Datenmodell als multidimensionale Map Abb. 2.3 zeigt den Aufbau einer Superspaltenfamilie anhand eines Beispiels. Die Studenten-Superspalten enthalten unterschiedliche Subspalten, da nicht zu jedem Studenten eine Handynummer existiert. Außerdem besuchen nicht alle Studenten die gleichen Veranstaltungen, sodass auch hier eine unterschiedliche Anzahl an Subspalten entsteht. Auch die Anzahl Superspalten ist nicht fix und könnte unterschiedlich sein. Die Daten werden beim Einfügen in die Datenbank sortiert, sodass keine nachträgliche Sortierung erfolgt. Eine Funktion wie ORDER BY aus SQL gibt es nicht. 13

17 2.3 Apache Cassandra Student (SuperColumnFamily) Rowkey : SuperColumn: Kontakt Telefon Mobil SuperColumn: Noten Info 1 3,7 Info 2 2,0 Praktikum 1,3 Rowkey : SuperColumn: Kontakt Telefon 4589 ICQ SuperColumn: Noten Info 1 1,7 BWL 1 1,3 ex@example.org... Abbildung 2.3: Beispielhafte SuperColumnFamily Dadurch werden hohe Leseraten erzielt, jedoch kann die Sortierung nicht beim Lesezugriff festgelegt werden. Bei Spaltenfamilien erfolgt die Sortierung über den Namen der Spalte, bei Superspaltenfamilien über den Namen der Superspalten und Subspalten. Der Datenbankentwickler kann zwischen verschiedenen vordefinierten Vergleichern (engl. Comparator) auswählen oder einen eigenen implementieren. In der Version stellt Cassandra folgende Vergleicher zur Verfügung: AsciiType, BytesType, CompositeType, LexicalUUIDType, LongType, TimeUUIDType und UTF8Type [11]. Beim Erstellen einer Spaltenfamilie wird jeweils ein Vergleicher für die Super- und Subspalten festgelegt. Während klassische relationale Datenbanken aus Tabellen bestehen, die über einen Verbund bei einer Anfrage miteinander verknüpft werden können, müssen bei Cassandra die Daten vorab denormalisiert werden. Die Daten werden bei der Denormalisierung mehrmals unterschiedlich formatiert in die Datenbank geschrieben, z.b. würden alle benötigten Verbünde vorab berechnet und abgespeichert werden. Eben Hewitt beschreibt in [11], dass es wichtig ist, sich bei der Entwicklung einer Anwendung mögliche Anfragen an die Datenbank vorab zu überlegen und die Daten- 14

18 2.3 Apache Cassandra bank entsprechend aufzubauen. Hewitt empfiehlt eine Spaltenfamilie pro möglicher Art der Anfrage Verteilung der Daten im Cluster Cassandra bietet verschiedene Möglichkeiten der Partitionierung. Es werden vordefinierte Partitionierer (engl. Partitioners) mitgeliefert, die um eigene Partitionierer, die das IPartitioner Interface implementieren, erweitert werden können [11]. Grundsätzlich werden zur Bestimmung des Knotens, auf dem die Daten gespeichert werden sollen, der Zeilenschlüssel, der Replikationsfaktor (engl. replication factor) und die Replikationsstrategie verwendet 9. Der Replikationsfaktor gibt an, wieviele Kopien der Daten im Cluster existieren. Ein Replikationsfaktor von 3 bedeutet beispielsweise, dass ein Datensatz dreimal im Cluster abgespeichert wird. Der Randompartitioner erlaubt es, die Daten gleichmäßig über den Cluster zu verteilen, da als Schlüssel der MD5-Hashwert des Zeilenschlüssels verwendet wird. Allerdings bedeutet dies auch, dass die Daten unsortiert vom System ausgegeben werden und Anfragen, die gezielte Zeilenbereiche auswählen, ineffizient ausgeführt werden. Der OrderPreservingPartitioner verwendet die UTF8-Repräsentation des Zeilenschlüssels als Schlüssel. Folglich werden die Daten anhand des Zeilenschlüssels physisch abgespeichert. Je nach Zeilenschlüssel kann dies bedeuten, dass die Daten unregelmäßig über den Cluster verteilt werden, da die zu speichernden Daten oftmals nicht gleichverteilt sind. Wird als Zeilenschlüssel zum Beispiel der Nachname einer Person verwendet, so gäbe es eine Häufung bei den Knoten, die die Nachnamen, die mit S beginnen, abspeichern. Die Last wäre also nicht regelmäßig verteilt. Vorteilhaft ist allerdings das Ausgeben sortierter Daten und die Möglichkeit, effizient Zeilenbereichsanfragen auszuwerten [11, 13] Datenzugriff Die Speicherung der Daten weist erhebliche Unterschiede zu relationalen Datenbanksystemen auf, folglich erfolgt der Datenzugriff ebenfalls auf eine andere Art. Cassandra ermöglicht den Zugriff der gespeicherten Daten per Thrift 10 und stellt hierfür eine API zur Verfügung. Die Entwickler von Cassandra empfehlen jedoch,

19 2.3 Apache Cassandra nicht direkt per Thrift auf Cassandra zuzugreifen, sondern auf einen Client in der gewünschten Programmiersprache zurückzugreifen[11, 13]. Der Konsistenzgrad (engl. consistency level) wird pro Schreib- oder Leseanfrage angegeben und definiert die Dauerhaftigkeit (engl. durability) der Anfrage. Die möglichen Konsistenzgrade bei einer Leseanfrage werden nachfolgend aufgelistet[11, 13]: ONE: Die Anfrage wird sofort vom ersten Knoten, an den die Anfrage gestellt wird, beantwortet. Dabei ist es möglich, dass das Ergebnis veraltet ist. Im Hintergrund wird ein Prozess gestartet, der überprüft, ob die Daten auf den Knoten identisch sind, die gemäß Replikationsfaktor Kopien der Daten speichern. Ist dies nicht der Fall, wird das Datum verwendet, dessen Zeitstempel aktueller ist. Dieser Vorgang wird als read repair bezeichnet. QUORUM: Die Anfrage wird erst beantwortet, wenn n + 1 Knoten die Daten auf 2 Konsistenz überprüft haben, wobei n der Replikationsfaktor ist. Im Hintergrund wird ein read repair -Prozess gestartet, der alle Kopien im Cluster überprüft. ALL : Alle n Knoten, auf denen sich eine Kopie der Daten befindet, müssen die Konsistenz bestätigen. Die Anfrage schlägt fehl, wenn einer der Knoten nicht verfügbar ist. Werden die Konsistenzgrade ONE oder QUORUM verwendet, ist es möglich, dass die Anfrage einen veralteten Wert zurückliefert. Das Reparieren der Daten erfolgt in diesem Falle erst, nachdem der Wert zurückgegeben worden ist. Da alle weiteren Anfragen nach der Reparatur konsistent sind, wird die Konsistenz von Cassandra als eventually consistent bezeichnet. Beim Schreiben stehen weitere Konsistenzgrade zur Verfügung: ANY : Der Schreibvorgang muss nur von einem Knoten bestätigt werden, unabhängig vom Replikationsfaktor. Dabei wird ein sogenannter Hint als Bestätigung akzeptiert. Ein Hint wird dann zurückgeliefert, wenn ein Knoten, auf dem die Daten als Kopie vorliegen, nicht verfügbar ist. Cassandra speichert den Schreibvorgang zwischen und schreibt die Daten, sobald der Knoten wieder erreichbar ist. ONE : Dieser Konsistenzgrad verhält sich wie ANY, jedoch reicht ein Hint als Bestätigung nicht aus. 16

20 2.3 Apache Cassandra QUORUM : n + 1 Knoten, wobei n der Replikationsfaktor ist, müssen den Schreibvorgang bestätigen. 2 ALL : Alle n Knoten müssen den Schreibvorgang bestätigen. Nachdem ein Konsistenzgrad ausgewählt worden ist, kann nun der Zugriff auf die Daten erfolgen. Wird das Datenmodell als multidimensionale Map betrachtet, erfolgt der Zugriff durch Angeben der Schlüssel. Je nachdem, welche Schlüssel angegeben worden sind, werden Subspalten, Superspalten oder ganze Zeilenbereiche zurückgegeben. Eine Filterung der gewünschten Daten ist durch Definition von Wertebereichen (engl. ranges) möglich. Wird bei einer Anfrage ein SlicePredicate definiert, so werden nur die dadurch definierten Spalten zurückgegeben. Dabei gibt es zwei Möglichkeiten, die gewünschten Spalten zu definieren. Entweder werden die Spaltennamen explizit angegeben oder es wird ein Bereich definiert, der durch einen Anfangs- und Endschlüssel gegeben ist. Die Daten zwischen Start und Ende ergeben sich aus dem verwendeten Vergleicher. Per SlicePredicate kann außerdem eine Limitierung der Spaltenanzahl ( count ) und die Umkehrung der Reihenfolge ( reversed ) erfolgen. Es ist nicht möglich ein SlicePredicate für Subspalten zu definieren. Wird eine Superspalte ausgewählt, werden immer alle Subspalten serialisiert. Eine Anwendung, die nicht alle Subspalten benötigt, muss also nach der Serialisierung filtern. Die Funktionen get_range_slices und multi_get_range der Cassandra API erlauben es, die resultierenden Zeilen der Anfrage einzuschränken. Sie erfordern aber, um effektiv genutzt werden zu können, den Einsatz des veralteten OrderPreserving- Partitioner. Eine Übersicht aller weiteren Funktionen findet sich in [11, 13]. 17

21 3 Strategien zur Auswertung und Speicherung der RDF-Daten In diesem Kapitel werden die Strategien zur Speicherung und Auswertung der RDF- Daten mit Cassandra und Hadoop beschrieben. Details der Implementierung werden in Kapitel 4 erläutert. 3.1 Speicherstrategie Die Speicherstrategie der Implementierung basiert auf einem Vorschlag, der von Ladwig und Harth in [14] vorgestellt wurde. Die Autoren präsentieren ein Speicherschema für RDF-Daten, sowie einen RDF-Layer und RDF-Store (CumulusRDF) für Cassandra. Die Daten werden insgesamt dreimal abgespeichert, um schnelles Nachschlagen aller acht möglichen Tripelmuster zu gewährleisten. Zum Speichern der Daten werden in Cassandra drei Superspaltenfamilien verwendet: SPO, POS und OSP. Die Tripel werden auf Zeilenschlüssel, Superspaltenname und Subspaltenname abgebildet, wobei der Wert der Subspalte leer gelassen wird. Dies ist notwendig, um mehrwertige Prädikate zu unterstützen. In der Spaltenfamilie SPO wird das Subjekt als Zeilenschlüssel, das Prädikat als Superspaltenname und das Objekt als Subspaltenname verwendet. Äquivalent werden die Tripel für die Spaltenfamilien POS und OSP abgebildet. Abb. 3.1 verdeutlicht die Speicherstrategie anhand eines Beispiels. Die RDF-Daten modellieren Bekanntschaften zwischen Benutzern, sowie deren Alter. Es werden die drei Superspaltenfamilien, sowie die zugehörigen Schlüssel und Spaltennamen aufgeführt. Aus Platzgründen werden lediglich Auszüge gezeigt. 18

22 3.1 Speicherstrategie data.n3... ex:tom ex:userknows ex:jerry ex:tom ex:userknows ex:chris ex:jerry ex:userknows ex:chris ex:tom ex:userage 28 ex:tom ex:userage Cluster: Cluster01 Keyspace: RDF-Data SPO ex:jerry ex:userknows ex:userage ex:tom ex:chris ex:tom ex:userknows ex:jerry ex:chris ex:userage POS ex:userknows ex:chris ex:tom ex:tom ex:jerry... ex:jerry ex:userage ex:25 ex:28 ex:jerry ex:tom OSP ex:jerry ex:userage... ex:chris... ex:tom ex:userknows Abbildung 3.1: Beispielhafte Speicherung der Daten 19

23 3.1 Speicherstrategie Tab. 3.1 führt die möglichen Tripelmuster auf, sowie die Spaltenfamilien, die zur Auswertung verwendet werden können. Es wird bei dieser Strategie versucht, möglichst viele Schlüssel beim Zugriff festzulegen. Die Schlüssel werden immer in der Reihenfolge Zeilenschlüssel, Superspaltenname und Subspaltenname festgelegt. Bei einer Variablen werden folglich Zeilenschlüssel und Superspaltenname (via SlicePredicate) beim Zugriff festgelegt. Bei zwei Variablen im Tripelmuster kann nur der Zeilenschlüssel festgelegt werden. Bei dieser Strategie muss also nur im Falle von drei Variablen über die Zeilenschlüssel iteriert werden. Dadurch wird das Ergebnis der Anfrage frühzeitig eingeschränkt. Ein wesentlicher Nachteil ist der hohe Speicherplatzbedarf. Ein Datum wird in drei verschiedenen Spaltenfamilien gespeichert. Wird zusätzlich ein Replikationsfaktor größer 1 gewählt, existieren weitere Kopien der Daten. Bei einem Replikationsfaktor von 3 ergäben sich somit 9 Kopien (insgesamt) der Daten im System. Triple Pattern Index (s, p, o) SPO, POS, OSP (s, p,?) SPO (?, p, o) POS (s,?, o) OSP (?, p,?) POS (s,?,?) SPO (?,?, o) OSP (?,?,?) SPO, POS, OSP Tabelle 3.1: Tripelmuster mit zu verwendender Spaltenfamilie. Quelle: [14] Der RDF-Store CumulusRDF[14] unterstützt keine leeren Knoten, da hier ein Verbund notwendig ist. Die Autoren beschränken sich aber hier auf das Nachschlagen von Tripelmustern. Implementierungen, die RDF-Daten auf Hadoops verteilten Dateisystem speichern, nutzen häufig das Prinzip der vertikalen Partitionierung aus. Die RDF-Tripel werden anhand des Prädikats in Dateien aufgeteilt. Bei der Auswertung von Anfragen muss, sofern ein Prädikat gegeben ist, nur die Datei geladen werden, die das Prädikat enthält. Es wurde versucht diesen Ansatz auf Cassandra zu übertragen, indem man pro Prädikat einen Keyspace anlegt. Allerdings zeigte sich, dass Cassandra Datenmodell nicht zur Verwendung vieler Keyspaces ausgelegt ist. So wird der Keyspace gewöhnlich bei der Initialisierung festgelegt, danach folgen die Anfragen auf diesen Keyspace. Außerdem müsste zur Beantwortung von Anfragen mit einer Variable als 20

24 3.1 Speicherstrategie Prädikat ein Index gespeichert werden, der alle Keyspace-Namen enthält. Mit dessen Hilfe würde dann über alle Keyspaces iteriert. Bei der Implementierung wurde festgestellt, dass die Verteilung der Daten auf die Knoten im Cluster mit Hadoop nicht optimal ist. Die Rechenlast wird nicht ausgeglichen verteilt, sondern wird nur einem Knoten zugewiesen. Dies liegt an den ausgewählten Spaltenfamilien, sowie dem frühzeitigen Festlegen des Zeilenschlüssels. Daher werden für den ersten Verbund, bei dem die Daten von Hadoop geladen werden, andere Spaltenfamilien verwendet. Details zur Optimierung werden in Kap erläutert. 21

25 3.2 Auswertungsstrategie 3.2 Auswertungsstrategie Die vorgestellte Implementierung unterstützt Anfragen, die aus Basic Graph Patterns mit bis zu 2 Variablen pro Tripelmuster bestehen. Zur Auswertung wird für jedes konsekutive Paar an Tripelmustern ein Verbund (engl. join) über die gemeinsamen Variablen dieser Tripel durchgeführt. Pro Verbund wird ein MapReduce-Job generiert, der die Daten aus Cassandra lädt und das Zwischen- oder Endergebnis auf das HDFS schreibt. Für n Tripel sind also n-1 MapReduce-Jobs nötig, um die Anfrage zu beantworten. Abb. 3.2 zeigt den Datenfluss der MapReduce-Jobs. Der erste der insgesamt n-1 Join- Jobs lädt den ersten und zweiten Datensatz aus Cassandra. Die Zwischenergebnisse werden auf das HDFS in einem temporären Ordner gespeichert. Der zweite Job erhält die Zwischenergebnisse vom HDFS, sowie den zweiten Datensatz aus Cassandra. Der Job speichert die Zwischenergebnisse auf das HDFS. Dieser Vorgang wiederholt sich bis zum letzten Job, der das Endergebnis auf das HDFS schreibt. Das Endergbnis enthält alle resultierenden Abbildungen der Variablen auf einen der Anfrage entsprechenden Wert. Cassandra 1.Input laden 2.Input laden 2.Input Join 1 Join 2 Join n-1... Zwischenergebnisse laden Zwischenergebnisse speichern Zwischenergebnisse speichern Zwischenergebnisse laden Endergebnis speichern HDFS Abbildung 3.2: Job-Sequenz mit Datenfluss 22

26 3.2 Auswertungsstrategie Der Verbund wird als sogenannter Map-Side-Join realisiert. Das bedeutet, dass der Verbund innerhalb der Map-Phase des MapReduce-Programms bereits abgeschlossen wird. Bei einem Verbund werden Tripel, die sich aus einem linken Tripelmuster ergeben, mit Tripeln, die von einem rechten Tripelmuster stammen, verbunden. In der Map-Phase werden die Tripel der linken Seite geladen und es werden dynamisch für jedes dieser Tripel die zu verbindenden Tripel der rechten Seite geladen. Da auf eine Reduce-Phase bei dieser Methode verzichtet wird, wird die Zeit eingespart, die sonst nötig wäre, um die Daten zu sortieren und nach Schlüssel zu gruppieren. Schließlich wird auch Netzwerkverkehr eingespart, da die Daten nicht an die Reducer geschickt werden müssen. In der Map-Phase wird jeweils über die Daten iteriert, die sich aus dem linken Tripelmuster ergeben. Es ergibt sich eine Menge an Abbildungen von der Menge der Variablen auf die jeweiligen Werte, die nachfolgend Mapping genannt wird. Für jedes Mapping werden nun die Daten, die verbunden werden sollen, angefragt und geladen. Dabei wird ausgenutzt, dass es eine Schnittmenge der Variablen zwischen den beiden Tripelmustern gibt. Linkes Tripelmuster:?inproc rdf:type bench: Inproceeding Rechtes TripelMuster:?inproc dc:creator?author Mappings: Gemeinsame Variable:?inproc {?author =persons:eileen_heick,?inproc=inproc:inproceeding1} {?author=persons:paul_erdoes,?inproc=inproc:inproceeding1} Iteration {?inproc=inproc:inproceeding1} Iteration {?inproc=inproc:inproceeding2} {?inproc=inproc:inproceeding3} null null {?inproc=inproc:inproceeding4} {?author=persons:gizla_nordmark,?inproc=inproc:inproceeding4} Iteration {?author=persons:eileen_heick,?inproc=inproc:inproceeding1} {?author=persons:paul_erdoes,?inproc= {?author=persons:gizla_nordmark,?inproc=inproc:inproceeding4} Abbildung 3.3: Beispielhafter Verbund in der Map-Phase des Jobs Abb. 3.3 verdeutlicht den Verbund anhand eines Beispiels. Die linke und rechte Seite 23

27 3.2 Auswertungsstrategie bilden jeweils Mappings (Abbildungen) der Variablen auf den jeweiligen Wert, der in der Zeile in Cassandra vorliegt oder vom HDFS geladen wurde, wenn es sich um ein Zwischenergebnis handelt. Im Beispiel wird über alle möglichen Werte für die Variable?inproc iteriert. Durch die vorhandene Schnittmenge der linken und rechten Seite ergeben sich vor dem Zugriff auf die Datenbank Werte für die gemeinsamen Variablen. Nun wird für die rechte Seite dynamisch auf Cassandra zugegriffen. Dabei werden die bekannten Schlüssel, die sich aus den gemeinsamen Variablen ergeben, berücksichtigt. Im Beispiel wird also erkannt, dass?inproc eine gemeinsame Variable ist. Folglich gibt es für die rechte Seite nur noch die Variable?author, da der jeweilige Wert für?inproc von der linken Seite übernommen wird. Es gibt nun zwei Möglichkeiten: Entweder erhält man eine Menge an Mappings, über die man nun iteriert und das Kreuzprodukt mit dem linken Mapping bildet oder es gibt kein Mapping für die rechte Seite. Dies ist dann der Fall, wenn die Cassandra-Datenbank für die definierten Schlüssel keinen Wert liefert. In diesem Fall wird diese Zeile nicht im Verbund berücksichtigt. Im Beispiel liegen also für inproc:inproceeding2 und inproc:inproceeding3 keine Daten über die Autoren vor, sodass der Verbund für diese Werte nicht berechnet wird. Für die anderen Werte liegen Daten über die Autoren vor, sodass das Kreuzprodukt berechnet werden kann. 24

28 4 Implementierung und Optimierungen Insgesamt wurden zwei Anwendungen implementiert. Die erste Anwendung dient zum Speichern von RDF-Daten in Cassandra. Sie erhält eine im N3-Format vorliegende RDF-Datei als Eingabe und speichert die Daten in die drei Spaltenfamilien SPO, POS und OSP (siehe Kap. 3.1). Der Benutzer kann den Keyspace festlegen, sowie die Anzahl der Tripel, die pro Batch in die Datenbank geschrieben werden, um die Schreibgeschwindigkeit zu regulieren. Die Anwendung wird auf einem Knoten des Clusters geladen und dort ausgeführt. Die zweite Anwendung, die der Auswertung der SPARQL-BGP Anfragen dient, wird mit Hadoop gestartet und läuft verteilt auf dem Cluster. Als Eingabe erhält das Programm die Anfrage, sowie den Namen des Keyspace, auf dem die Auswertung durchgeführt werden soll. Die Ausgabe erfolgt auf dem HDFS. Abb. 4.1 zeigt die Systemarchitektur. Links ist die Anwendung zur Auswertung der SPARQL-BGP- Anfragen zu sehen, während rechts das Einleseprogramm dargestellt wird. Beide Anwendungen wurden in der Programmiersprache Java implementiert. Der Hector Client 1 ermöglicht den Zugriff auf Cassandra in Java-Programmen und wird in beiden Anwendungen verwendet. Das selbsternannte Ziel von Hector ist es, dem Entwickler Funktionen zur Verfügung zu stellen, um einfacher auf Cassandra zuzugreifen. Dabei greift der Client selbst per Thrift-API auf Cassandra zu und ist somit ein Wrapper dieser Funktionen. Die MapReduce-Jobs greifen per ColumnFamilyInputFormat und Hector-Client auf die Datenbank zu. Das ColumnFamilyInputFormat wird vom Cassandra-Projekt zur Verfügung gestellt, um Daten aus Cassandra mit MapReduce zu verarbeiten

29 4.1 Einlesen der Daten Abbildung 4.1: Systemarchitektur der Implementierung 4.1 Einlesen der Daten Die Daten liegen im N3-Format auf dem Server vor. Zum Einlesen wurde ein Programm implementiert, das die Daten mit dem Parser des Sesame-Frameworks 2 in Aussagen unterteilt. Die Präfixe werden vom Parser automatisch erweitert, sodass die URIs in voller Länge abgespeichert werden. Zum Schreiben der Daten in die Cassandra-Datenbank wird der Hector-Client eingesetzt. Die Laufzeit wird verbessert, wenn die Funktion addinsertion statt insert verwendet wird. Auf diese Weise werden die Daten zunächst als sogenannter Batch gesammelt und dann gleichzeitig in die Datenbank geladen. Batchgrößen zwischen 500 und 2000 lieferten gute Ergebnisse. Die Laufzeit verbessert sich bei größeren Batchgrößen wenig, aber das Risiko einer OutOfMemory-Exception steigt, da die Daten auf den Heap der Java Virtual Machine zwischengespeichert werden