Verteilte Auswertung von RDF-Graphen mit MapReduce und ...

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

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

Bearbeitungszeitraum
26. 05. 2011 – 26. 08. 2011
Gutachter
Prof. Dr. Georg Lausen
Betreuer
Alexander Schätzle
Martin Przyjaciel-Zablocki

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

Inhaltsverzeichnis
Kurzfassung 1
1 Einführung 4
2 Grundlagen 6
2.1 Semantic Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Resource Description Framework . . . . . . . . . . . . . . . . 6
2.1.2 SPARQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Apache Hadoop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Apache Cassandra . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1 Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2 Verteilung der Daten im Cluster . . . . . . . . . . . . . . . . . 15
2.3.3 Datenzugriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Strategien zur Auswertung und Speicherung der RDF-Daten 18
3.1 Speicherstrategie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Auswertungsstrategie . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4 Implementierung und Optimierungen 25
4.1 Einlesen der Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Auswerten der Anfragen . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.1 Generieren der Jobs . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.2 Map-Side Join . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.3 Alternativen zum Map-Side Join . . . . . . . . . . . . . . . . 28
4.2.4 Optimierung für Hadoop . . . . . . . . . . . . . . . . . . . . . 30
5 Evaluation 33
5.1 Allgemeine Rahmenbedingunen . . . . . . . . . . . . . . . . . . . . . 33
2

5.2 Laufzeiten und Beobachtungen . . . . . . . . . . . . . . . . . . . . . . 34
5.2.1 Q1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2.2 Q2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.3 Q3A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.4 Q10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2.5 Einfluss des Konsistenzgrads . . . . . . . . . . . . . . . . . . . 39
5.2.6 Einfluss des Replikationsfaktors . . . . . . . . . . . . . . . . . 40
5.2.7 Datenverteilung . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3 Probleme und mögliche Ursachen . . . . . . . . . . . . . . . . . . . . 41
6 Verwandte Arbeiten 43
7 Zusammenfassung 45
7.1 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3

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

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

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.
2.1.1 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

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 http://www.w3.org/People/
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.
1 http://www.w3.org/TeamSubmission/turtle/
7

2.1 Semantic Web
@prefix r d f : .
@prefix 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 3 .
2.1.2 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 .
?buch 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
2 http://www.openrdf.org/
3 http://jena.sourceforge.net/
8

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

2.2 Apache Hadoop
PREFIX p1
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. 2008 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
4 http://nutch.apache.org/
10

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

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.
5 http://nosql-database.org/
6 http://couchdb.apache.org/
7 http://neo4j.org/
8 http://www.zodb.org/
12

2.3 Apache Cassandra
2.3.1 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 ] = value
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

2.3 Apache Cassandra
Student
(SuperColumnFamily)
Rowkey
:
217654
SuperColumn: Kontakt
Telefon 004848
Mobil 789705408
SuperColumn: Noten
Info 1 3,7
Info 2 2,0
Praktikum 1,3
Rowkey
:
235678
SuperColumn: Kontakt
Telefon 4589
ICQ 549879
SuperColumn: Noten
Info 1 1,7
BWL 1 1,3
eMail
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 0.8.2 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

2.3 Apache Cassandra
bank entsprechend aufzubauen. Hewitt empfiehlt eine Spaltenfamilie pro möglicher
Art der Anfrage.
2.3.2 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].
2.3.3 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,
9 http://wiki.apache.org/cassandra/FAQ#replicaplacement
10 http://thrift.apache.org/
15

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

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

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

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 25
...
Cluster: Cluster01
Keyspace: RDF-Data
SPO
ex:Jerry
ex:userKnows
ex:userAge
ex:Tom „“
ex:Chris „“
...
25 „“
...
...
ex:Tom
ex:userKnows
ex:Jerry „“
ex:Chris „“
...
...
ex:userAge
28 „“
...
...
POS
ex:userKnows
ex:Chris
ex:Tom
ex:Tom „“
ex:Jerry „“
...
ex:Jerry „“
...
...
ex:userAge
ex:25
ex:28
ex:Jerry „“ ex:Tom „“
...
...
...
OSP
...
25
ex:Jerry
ex:userAge „“
...
ex:Chris
...
ex:Tom
ex:userKnows „“
...
...
...
Abbildung 3.1: Beispielhafte Speicherung der Daten
19

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

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. 4.2.4 erläutert.
21

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

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=http:inproc:Inproceeding1}
{?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

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

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.
1 http://prettyprint.me/2010/02/23/hector-a-java-cassandra-client/
25

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.
2 http://www.openrdf.org/
26

4.2 Auswerten der Anfragen
4.2 Auswerten der Anfragen
Abb. 4.2 zeigt den Datenfluss der ersten Anwendung. Nach dem Parsen werden aus
den Tripelmustern die MapReduce Jobs erzeugt. Anschließend wird die Sequenz
dieser Jobs ausgeführt.
Anfrage
ARQ Parser
●
Parsen der Anfrage
●
Aufteilung in Tripelmuster
Tripelmuster
JobCreator
JoinConfigHelper
●
Erzeugung der MapReduce-Jobs
●
Festlegung von Spaltenfamilien und
Prädikaten in der Konfiguration
MapReduce-Jobs mit Konfigurationen
●
Ausführung der Jobs auf dem
Cluster
●
Zugriff auf Cassandra
●
Verbund erfolgt als Map-Side-Join
●
Ausgabe auf HDFS
Ergebnis
Abbildung 4.2: Übersicht des Programmverlaufs
4.2.1 Generieren der Jobs
Die Anfrage wird zuerst an den ARQ-Parser des Jena-Frameworks 3 übergeben und
wird in Tripelmuster aufgeteilt. Diese werden an die Klasse JobCreator übergeben.
3 http://jena.sourceforge.net/ARQ/
27

4.2 Auswerten der Anfragen
Die Klasse JobCreator erstellt anhand dieser Eingabe eine Liste von MapReduce-
Jobs mit jeweils eigener Konfiguration. Zum Erstellen der Konfiguration wird die
Klasse JoinConfigHelper verwendet, die Funktionen zum Lesen und Schreiben der
Programm-Parameter bereitstellt. Für jeden Job wird nun die Eingabe, Ausgabe,
Mapper-Klasse, sowie weitere Parameter, die vom Hector Client benötigt werden,
festgelegt. Die Ausgabe ist eine Liste ausführbarer MapReduce-Jobs, die einen im
Folgenden beschriebenen Map-Side-Join durchführen.
4.2.2 Map-Side Join
Der Verbund (engl. join), der zur Auswertung mehrerer Tripelmuster notwendig ist,
wurde wie in Kap. 3.2 beschrieben als Map-Side-Join implementiert. Die Daten werden
beim ersten Verbund per ColumnFamilyInputFormat für Hadoop in die Mapper
geladen. In jedem weiteren Verbund wird das FileInputFormat verwendet, um die
Zwischenergebnisse vom HDFS zu laden. Werden die Daten vom HDFS geladen,
liegen sie bereits als Mapping vor. Werden sie aus Cassandra geladen, muss daraus
zunächst ein Mapping erzeugt werden. Zu jedem Verbund gibt es ein linkes und
ein rechtes Tripelmuster. Aus jedem Tripelmuster der Anfrage ergibt sich gemäß
der vorgestellten Speicherstrategie eine Spaltenfamilie. Außerdem werden, je nach
Anzahl der Variablen, Namen für Zeilenschlüssel, Super- und Subspalten anhand
der Konfiguration festgelegt. Jeder Mapper lädt die Daten, die lokal auf seinem
Cassandra-Knoten zur Verfügung stehen. Da jeweils zwei Mapper-Klassen, für das
Laden der Daten aus Cassandra oder dem HDFS, benötigt werden, wurde die Durchführung
des Verbunds ausgelagert. Die Berechnung des Verbunds erfolgt stattdessen
mit der Klasse JoinPerformer, um redundanten Code zu vermeiden.
4.2.3 Alternativen zum Map-Side Join
Alternativ zum vorgestellten Map-Side Join gibt es Map-Side-Merge-Joins und Reduce-
Side-Joins. Im Folgenden werden die Funktionsweisen kurz vorgestellt und begründet,
warum eine Implementierung dieser Verbünde nicht möglich war.
Ein Reduce-Side-Join markiert die Daten während der Map-Phase, sodass in der
Reduce-Phase alle Daten so gruppiert sind, dass ein Reducer alle Datensätze hat, die
verbunden werden müssen. Um die Daten zu laden, wird die MultipleInputs-Klasse
verwendet, die es erlaubt verschiedene Datenquellen als Input festzulegen und ihnen
28

4.2 Auswerten der Anfragen
jeweils einen eigenen Mapper zuzuweisen. Dies funktioniert problemlos, wenn die Daten
vom HDFS und Cassandra geladen werden sollen, was ab dem zweiten Join der
Fall ist. Der erste Join, bei dem aus zwei Spaltenfamilien die Daten geladen werden,
bereitet jedoch Probleme. Die Ursache befindet sich hauptsächlich in den Klassen
ColumnFamilyInputformat und JoinConfigHelper. Diese Klassen sind so ausgelegt,
dass nur eine Spaltenfamilie und SlicePredicate pro Job ausgewählt werden kann. Es
wurde versucht die Klassen um diese Funktionalität zu erweitern. Dies gelang auch
für kleinere Inputdateien. Ab einer bestimmten Größe der Input-Dateien schlugen
die Jobs mit einer OutOfMemory-Ausnahme fehl. Eine Implementierung gestaltete
sich somit schwierig und konnte aus Zeitgründen nicht fertiggestellt werden, da
tiefgreifendere Änderungen am bereitgestellten Quellcode nötig gewesen wären.
Ein Map-Side-Merge-Join hat viele Gemeinsamkeiten mit dem implementierten Map-
Side-Join. Bei einem solchen Verbund wird ebenfalls auf die Reduce-Phase verzichtet.
Allerdings wird versucht durch gezieltes Partitionieren und Sortieren der Daten
den Verbund schon beim Laden der Daten in den Mapper zu sortieren. Es gibt
verschiedene Vorraussetzungen für einen Map-Side-Merge-Join [15]:
1. Beide Datensätze müssen identisch partitioniert und sortiert sein. Ist dies der
Fall muss der Verbund der ersten Partition des ersten Datensatzes mit der
ersten Partition des zweiten Datensatzes berechnet werden. Anschließend wird
der Verbund der weiteren Partitionen berechnet bis schließlich der gesamte
Verbund berechnet worden ist.
2. Der Typ der Input- und Output-Schlüssel muss identisch sein, da sonst die
Daten nicht identisch partitioniert würden.
Das Hadoop-Framework stellt zu diesem Zweck die Klasse CompositeInputformat
bereit. Zunächst trat das gleiche Problem wie beim Reduce-Side-Join auf, da die
Daten aus mehreren Spaltenfamilien geladen werden müssen. Ein weiteres Problem
betraf die Ordnung und Partitionierung. Datensätze werden in Cassandra prinzipiell
so geordnet, wie sie geschrieben werden. In der Regel erfolgt also keine Ordnung der
Schlüssel. Verwendet man den OrderPreservingPartitioner, ist zwar eine Ordnung
gegeben, die Daten werden aber dann nicht mehr gleichmäßig im Cluster verteilt.
Außerdem werden nicht alle Datensätze über den Zeilenschlüssel verbunden. Insgesamt
wären sowohl tiefgreifendere Änderungen am Quelltext vorzunehmen, als auch
das Speicherverfahren soweit abzuändern, damit die Daten richtig partitioniert würden.
29

4.2 Auswerten der Anfragen
4.2.4 Optimierung für Hadoop
Für den ersten Verbund wird das ColumnFamilyInputFormat für Hadoop, das von
Cassandra zur Verfügung gestellt wird, verwendet. Ist der Cluster richtig konfiguriert,
greift der Mapper auf die Daten zu, die lokal auf seinem Knoten in Cassandra
gespeichert werden. Folglich wird Lokalität ausgenutzt und die Daten können verteilt
ausgewertet werden. Es wird am folgenden Beispiel (Listing 4.1) erläutert, warum
das verwendete Nachschlageverfahren für den ersten Verbund nicht sinnvoll ist:
ex : Thomas ex : userKnows ? person
Listing 4.1: Tripelmuster einer SPARQL-BGP-Anfrage
Nach dem oben beschriebenen Nachschlageverfahren sollte die ColumnFamily „SPO“
verwendet werden. Zeilenschlüssel und Spaltenname sind bekannt und es muss nur
über alle Subspalten itereriert werden, die mit Daten, die aus einem weiteren Tripel
gewonnen werden, verbunden werden. Es ergibt sich jedoch ein entscheidender
Nachteil. Die Daten werden auf die Knoten per Random-Partitioner verteilt, indem
der Zeilenschlüssel verwendet wird. Eine Zeile wird komplett auf einem Knoten
abgespeichert. Je nach Replikationsfaktor gibt es weitere Kopien, die aber bei der
Verwendung des ColumnFamilyInputformat nicht ausreichend verwendet werden.
Da der Schlüssel im Beispiel mit “ex:Thomas” festgelegt wurde, werden die Daten
nur auf einem Knoten lokal verfügbar sein und auch nur hier verarbeitet. Dies hat
zur Folge, dass nur ein Knoten den Verbund ausführt, während die anderen Knoten
schnell ihre Map-Tasks abarbeiten und untätig für die weitere Job-Ausführung
bleiben.
Abbildung 4.3: Zustand der Mapper ohne Optimierung (Bildschirmaufnahme)
30

4.2 Auswerten der Anfragen
Abb. 4.3 veranschaulicht diesen Sachverhalt in einem Cluster mit 9 Knoten. 8 der 9
Knoten sind nach wenigen Sekunden fertig, während der letzte Knoten sehr lange
rechnet. Der Kreis in der Grafik verdeutlicht, dass der 9. Map-Task noch nicht
fertiggestellt worden ist. Bei der Auswertung der Anfrage Q3A auf 25 Millionen
Tripel dauerte der Verbund 39 Minuten, da eine Teilung des Rechenaufwands nicht
stattfand.
Beim Zugriff auf Cassandra wird die Spaltenfamilie so gewählt, dass der Zeilenschlüssel
festgelegt werden kann. Ändert man das Verfahren so ab, dass der Zeilenschlüssel
nicht festgelegt wird und somit eine andere Spaltenfamilie festgelegt wird, werden alle
Knoten am Verbund beteiligt. Bei dem obigen Beispiel wird auf die Spaltenfamilie
„OSP“ zugegriffen. Es wird ein SlicePredicate mit dem Namen „ex:Thomas“ festgelegt
und außerdem ein Subspaltenname „ex:userknows“. Es wird auf allen Knoten
über alle Objekte iteriert.
Abbildung 4.4: Zustand der Mapper nach der Optimierung (Bildschirmaufnahme)
Abb. 4.4 zeigt den Zustand der Mapper wenige Sekunden nach Programmstart und
illustriert die Optimierung. Alle Knoten führen Map-Tasks aus, deren Anzahl kann
außerdem vom ColumnFamilyInputFormat erhöht werden (von 9 auf 117). Die Ausführung
verbesserte sich durch diese Optimierung bei 25 Millionen Tripeln von 39 auf
2 Minuten. Für die acht möglichen Tripelmuster ergeben sich die Spaltenfamilien,
die in Tab. 4.1 aufgeführt sind.
Enthält ein Tripelmuster zwei Variablen, werden diese auf den Zeilenschlüssel und
Subspaltenname abgebildet, um ein Slicepredicate definieren zu können. Sonst würden
alle Subspalten geladen werden und anschließend gefiltert. Dies liegt daran, dass
es kein SubSlicepredicate gibt. Es ist daher unvorteilhafter einen Zeilenschlüssel und
31

4.2 Auswerten der Anfragen
Triple Pattern Index
(s, p, o) SPO, POS, OSP
(s, p, ?) OSP
(?, p, o) SPO
(s, ?, o) POS
(?, p, ?) SPO
(s, ?, ?) OSP
(?, ?, o) POS
(?, ?, ?) nicht unterstützt
Tabelle 4.1: Tripelmuster mit zu verwendender Spaltenfamilie für ColumnFamily-
Inputformat beim ersten Verbund
Subspaltennamen zu definieren und den Superspaltennamen undefiniert zu lassen.
Da die Zwischenergebnisse vom HDFS gelesen werden, sodass eine gute Skalierung
gegeben ist, gilt diese Optimierung nur für den ersten Verbund. Alle weiteren Zugriffe
auf Cassandra via Hector Client erfolgen nach dem Schema, das in [14] vorgestellt
wird.
32

5 Evaluation
In diesem Kapitel wird geprüft, wie sich die Implementierung bei unterschiedlichen
Datensätzen verhält. Es soll überprüft werden, ob die Kombination aus Hadoop und
Cassandra effizient im Hinblick auf die Laufzeit ist. Dafür werden die Laufzeiten verglichen,
die sich bei der Anwendung auf unterschiedlichen Datensatzgrößen ergeben.
Außerdem werden verschiedene Cassandra-spezifische Einstellungen variiert, um deren
Einfluss auf die Laufzeit zu untersuchen. Es werden zunächst die Rahmenbedingen
der Evaluation betrachtet, anschließend werden die Laufzeiten präsentiert und
interpretiert. Abschließend werden Probleme aufgezeigt, die während der Evaluation
auftraten und mögliche Ursachen benannt.
5.1 Allgemeine Rahmenbedingunen
Zur Evaluation wird ein Cluster bestehend aus 10 Servern verwendet. Jeder Server
hat einen Intel Xeon Prozessor 3,16 GHZ, 4GB Arbeitsspeicher und 3 TeraByte
Festplattenkapazität. Die einzelnen Server, fortan Knoten genannt, kommunizieren
über ein Gigabit-Lan miteinander. Das Betriebssystem ist die 64-Bit Version der
Ubuntu-Distribution in der Version 9.10. Als MapReduce-Framework wurde „Cloudera’s
Distribution for Hadoop 3“ (CDH3) 1 verwendet. Java ist in Version 1.6.0_26
installiert. Cassandra ist zur Zeit der Auswertung in Version 0.8.2 installiert. Einer
der Knoten fungiert ausschließlich als Jobtracker und Namenode und ist somit an
der Berechnung nicht direkt beteiligt. Die Datenbank läuft ebenfalls nur auf 9 der
10 Knoten, um Störungen mit dem Hadoop Jobtracker zu vermeiden.
Die Grundlage der Evaluation bilden Daten, die mit dem Benchmark SP 2 Bench generiert
worden sind. Der Benchmark generiert Semantic Web Daten im RDF-Format,
die auf der Verteilung echter Daten basieren. Als Referenz dient die Literaturdatenbank
DBLP. Als Benchmark für SPARQL-Anfragen entwickelt, stellt SP 2 Bench
1 http://www.cloudera.com/hadoop/
33

5.2 Laufzeiten und Beobachtungen
außerdem ausgewählte Anfragen zum Testen bereit [16]. Es wurden insgesamt Daten
zwischen 1 Millionen und 50 Millionen Tripel evaluiert. Größere Datensätze
konnten leider aufgrund wiederholter Ausfälle des Clusters nicht eingespielt werden.
Die Ausfälle sind höchstwahrscheinlich auf eine suboptimale Konfiguration der Speicherzuweisung
zurückzuführen. Aus zeitlichen Gründen war eine Optimierung der
entsprechenden Konfigurationsparameter leider nicht möglich. Allerdings ist davon
auszugehen, dass weitere Optimierungen die Ausfälle beheben würden.
5.2 Laufzeiten und Beobachtungen
Die Zeitmessung erfolgt mit dem Java-Befehl System.nanoTime(). Dieser wird als
erster und letzter Befehl des Programms aufgerufen. Insgesamt wurden 4 Anfragen
an das System gerichtet, die auf den von SP 2 Bench bereitgestellten Anfragen basieren.
Es wurden eine kurze Anfrage (Q10), zwei Anfragen mittlerer Länge (Q1, Q3a)
und eine lange Anfrage (Q2) ausgewählt. Bei einigen Anfragen mussten Teile der
Anfrage weggelassen oder umgeschrieben werden, da es sich nicht bei allen Anfragen
um reine BGP-Anfragen handelt. Der Replikationsfaktor der Cassandra-Datenbank
wurde auf 3 gesetzt. Dies entspricht dem Replikationsfaktor des HDFS.
5.2.1 Q1
SELECT *
WHERE {
}
?journal rdf:type bench:Journal .
?journal dc:title "Journal 1 (1940)"^^xsd:string .
?journal dcterms:issued ?yr .
Listing 5.1: Anfrage Q1
Die Anfrage Q1 aus Listing 5.1 besteht aus drei Tripelmustern und wird mit zwei
Verbünden ausgewertet. Die Laufzeiten (Tab. 5.1, Abb. 5.1) wachsen wie erwartet
annähernd linear für unterschiedliche Datensatzgrößen.
34

5.2 Laufzeiten und Beobachtungen
Q1 1M 5M 10M 25M 50M
Laufzeit 00:00:19 00:00:36 00:00:40 00:01:00 00:01:54
Ergebnisse 1 1 1 1 1
Tabelle 5.1: Auswertung der Anfrage Q1
00:02:01
00:01:44
00:01:26
Zeit (hh:mm:ss)
00:01:09
00:00:52
00:00:35
00:00:17
00:00:00
0 10 20 30 40 50 60
RDF Tripel( in Millionen)
Abbildung 5.1: Auswertung der Anfrage Q1
35

5.2 Laufzeiten und Beobachtungen
5.2.2 Q2
SELECT *
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.
Listing 5.2: Anfrage Q2
Die Anfrage Q2, die in Listing 5.2 aufgeführt wird, ist die längste Anfrage und besteht
aus insgesamt 8 Verbünden. Es handelt sich hierbei nicht um die ursprüngliche
Anfrage von SP 2 Bench, da „OPTIONAL“- und „ORDER BY“-Befehle weggelassen
werden mussten.
Q2 1M 5M 10M 25M 50M
Laufzeit 00:02:31 00:06:26 00:14:20 00:51:20 01:48:29
Ergebnisse 64679 252754 613729 1896297 4230949
Tabelle 5.2: Auswertung der Anfrage Q2
Die Laufzeiten, dargestellt in Tab. 5.2 und Abb. 5.2 sind deutlich länger verglichen
mit den anderen Anfragen. Auch bei dieser Anfrage kann ein linearer Verlauf der
Laufzeiten festgestellt werden, wobei das Maximum bei 01:48:29 liegt.
5.2.3 Q3A
Die Anfrage Q3A (Listing 5.3) ist ähnlich zur Anfrage Q1 und besteht aus einem
Verbund. Die Anfrage Q3A, die von SP2Bench bereitsgestellt wird, sah einen
„FILTER“-Befehl vor. Dies wurde vermieden, indem der Wert als Prädikat des
zweiten Tripelmusters eingefügt worden ist. Die Laufzeiten werden in Tab. 5.3 und
Abb. 5.3 tabellarisch und graphisch dargestellt. Auch hier ist eine Linearität der
Laufzeit in Abhängigkeit der Datengröße zu erkennen.
36

5.2 Laufzeiten und Beobachtungen
01:55:12
01:40:48
01:26:24
Zeit (hh:mm:ss)
01:12:00
00:57:36
00:43:12
00:28:48
00:14:24
00:00:00
0 10 20 30 40 50 60
RDF-Tripel (in Millionen)
Abbildung 5.2: Auswertung der Anfrage Q2
SELECT *
WHERE {
}
?article rdf:type bench:Article .
?article swrc:pages ?value .
Listing 5.3: Anfrage Q3A
Q3 1M 5M 10M 25M 50M
Laufzeit 00:00:18 00:00:38 00:00:58 00:02:15 00:03:41
Ergebnisse 52406 193786 323456 598936 929547
Tabelle 5.3: Auswertung der Anfrage Q3A
37

5.2 Laufzeiten und Beobachtungen
00:04:19
00:03:36
Zeit (hh:mm:ss)
00:02:53
00:02:10
00:01:26
00:00:43
00:00:00
0 10 20 30 40 50 60
RDF-Tripel (in Millionen)
Abbildung 5.3: Auswertung der Anfrage Q3A
5.2.4 Q10
SELECT *
WHERE { ?subject ?predicate person:Paul_Erdoes. }
Listing 5.4: Anfrage Q10
Q10 1M 5M 10M 25M 50M
Laufzeit 00:00:12 00:00:43 00:00:59 00:01:55 00:02:45
Ergebnisse 572 656 656 656 656
Tabelle 5.4: Auswertung der Anfrage Q10
Q10, dargestellt in Listing 5.4, ist die kleinste der betrachteten Anfragen und besteht
lediglich aus einem Tripelmuster. Somit werden die Daten in der Map-Phase
eingelesen und direkt auf das HDFS geschrieben. Für die ersten beiden Datensätze
lieferte das Programm das richtige Ergebnis und terminierte. Bei größeren Datensätzen
blieb die Map-Phase bei 99% stehen und wurde nach wenigen Minuten
abgebrochen, jedoch waren die Ergebnisse korrekt. Die in Tab. 5.4 und Abb. 5.4 aufgeführten
Laufzeiten beziehen sich bei diesem Datensatz auf die Zeit, bei der das
Programm 99% erreicht hat. Insgesamt ist auch hier eine Linearität der Laufzeit mit
steigender Datensatzgröße zu erkennen. Allerdings machte sich die Instabilität des
Systems bemerkbar.
38

5.2 Laufzeiten und Beobachtungen
00:03:36
00:02:53
Zeit in hh:mm:ss
00:02:10
00:01:26
00:00:43
00:00:00
0 10 20 30 40 50 60
RDF-Tripel (in Millionen)
Abbildung 5.4: Auswertung der Anfrage Q10
5.2.5 Einfluss des Konsistenzgrads
Nachdem unterschiedliche Datensatzgrößen betrachtet wurden, wurden unterschiedliche
Konsistenzgrade bei den Anfragen betrachtet. Der Hector Client geht standardmäßig
zum Lesen vom Konsistenzgrad „QUORUM“ aus. Für den größten Datensatz
(50M ) wurden die ersten drei Anfragen mit den Konsistenzgraden „ONE“
und „ALL“ wiederholt. Die gemessenen Laufzeiten, in Tabelle Tab. 5.5 aufgeführt,
weisen nur geringe Änderungen auf, die vernachlässigt werden können, da sie auf
Schwankungen der Auslastung des Clusters zurückzuführen sind. Folglich scheint
eine Änderung des Konsistenzgrads bei den gewählten Anfragen keinen Einfluss auf
die Laufzeit zu haben.
50M ONE QUORUM ALL
Q1 00:02:05 00:02:05 00:02:04
Q2 01:41:58 01:48:42 01:40:37
Q3A 00:03:48 00:03:31 00:03:51
Tabelle 5.5: Anfragen mit unterschiedlichem Konsistenzgrad
39

5.2 Laufzeiten und Beobachtungen
5.2.6 Einfluss des Replikationsfaktors
Zunächst wurde versucht, den Replikationsfaktor schrittweise zu erhöhen. Nachdem
der Replikationsfaktor für den Keyspace 10M auf 4 gesetzt wurde, musste nach
Anleitung ein Repair-Vorgang aufgerufen werden. Nach einigen Minuten war der
Repair-Vorgang abgeschlossen, jedoch gaben die Anfragen fehlerhafte Ergebnisse
aus. Es war zu beobachten, dass bei jedem Programmaufruf die Anzahl eingelesener
Rekords schwankte. Auch nach mehreren Stunden Wartens, einem Cleanup-Vorgang
und einem weiteren Repair-Vorgang, gab es keine Verbesserung. Daher wurde ein
weiterer Keyspace mit einem Replikationsfaktor von 6 erstellt und die Daten erneut
eingespielt. Die Map-Tasks griffen wie erwartet auf sechs verschiedene Knoten
zu, um die Daten zu laden. Die Ergebnisse waren korrekt, die Laufzeiten (Abb. 5.5,
Tab. 5.6) zeigten jedoch keine Verbesserung, sondern waren durchschnittlich um ca.
50% erhöht. Da mit einem höheren Replikationsfaktor mehr Kopien der Daten im
Cluster vorhanden sind, wurden kürzere Zugriffszeiten und somit kürzere Gesamtlaufzeiten
erwartet.
02:52:48
02:24:00
Zeit (hh:mm:ss)
01:55:12
01:26:24
00:57:36
50M RF 3
50M RF 6
00:28:48
00:00:00
Q1 Q2 Q3A
Anfrage
Abbildung 5.5: Vergleich der Laufzeiten bei unterschiedlichem Replikationsfaktor
bei 50 Millionen Tripel
40

5.3 Probleme und mögliche Ursachen
Q1 Q2 Q3A
10M RF 3 00:00:40 00:14:20 00:00:58
10M RF 6 00:01:20 00:22:13 00:02:07
25M RF 3 00:01:00 00:51:20 00:02:15
25M RF 6 00:02:51 01:13:56 00:04:11
50M RF 3 00:01:54 01:48:29 00:03:41
50M RF 6 00:05:42 02:35:52 00:07:43
Tabelle 5.6: Anfragen mit unterschiedlichem Replikationsfaktor
5.2.7 Datenverteilung
Die Verteilung der Daten erfolgt trotz Verwendung des RandomPartitioner nicht
ganz gleichmäßig. Abb. 5.6 zeigt die neun Knoten, auf denen Cassandra installiert
ist, sowie die Größe der gespeicherten Daten. Die Größen variieren von 10,69 GB
bis 16,61 GB.
Abbildung 5.6: Auszug aus der Clusterübersicht (Bildschirmaufnahme)
5.3 Probleme und mögliche Ursachen
Bei der Evaluation traten verschiedene Probleme auf, die sowohl das Einlesen als
auch das Auswerten der Daten betrafen. Beim Einlesen der Datensätze mit 50 Millionen
Tripeln oder größer war nach einigen Stunden mehrere Knoten nicht verfügbar
und das Einlesen war fehlgeschlagen. Auch nach einem Neustart der Systeme stürzten
einige wieder ab. Erst das Löschen des zum Datensatz gehörenden Keyspace
löste das Problem. Nach Auswerten der log-Dateien wurde ein Überlaufen des Java-
Heap-Space festgestellt. Cassandra schreibt die Daten zunächst in eine Datenstruktur
MemTable, die im Speicher liegt. Erreicht die Tabelle eine in der Konfiguration
41

5.3 Probleme und mögliche Ursachen
festgelegte Größe, werden die Daten auf die Festplatte geschrieben. Um die Auslastung
der Datenbank zu senken, wurde die einzulesende Datei zunächst in Dateien
mit 250.000 Zeilen Länge aufgeteilt. Die aufgeteilten Dateien wurden mit jeweils 3
Minuten Pause zwischen den einzelnen Teilen eingelesen, um der Datenbank mehr
Zeit zum Leeren der internen Datenstrukturen zu geben. Da dies immer noch zu
Problemen führte, wurde das Einleseprogramm durch Einfügen von Sleep-Befehlen
verändert, sodass das Einlesen künstlich verlangsamt wurde. Durch diese Änderungen
gelang es, den Datensatz bestehend aus 50 Millionen Tripel einzulesen. Allerdings
war es nicht möglich, größere Datensätze in akzeptabler Zeit einzulesen. Da ein
Absturz immer mit dem Neustart des gesamten Clusters verbunden war, gestaltete
sich die Problemsuche und das Testen verschiedener Einleseparameter schwierig.
42

6 Verwandte Arbeiten
In diesem Kapitel werden Arbeiten und Projekte, die mit dieser Arbeit verwandt
sind vorgestellt. Dabei werden die Gemeinsamkeiten und Unterschiede aufgezeigt.
Das Heart-Projekt 1
(Highly Extensible & Accumulative RDF Table) kombiniert
Apache Hadoop und die NoSQL-Datenbank HBase zur effizienten Speicherung und
Auswertung von RDF-Daten. Ähnlich zur der in dieser Arbeit vorgestellten Implementierung
werden die Daten in HBase so abgespeichert, dass Verbünde berechnet
werden können. Das Projekt befindet sich im Anfangsstadium und scheint noch keine
Implementierung aufzuweisen.
Die Kombination aus Hadoop und HBase lässt sich ebenfalls in [2] wiederfinden.
Die Autoren Sun und Jin präsentieren einen skalierbaren RDF-Store, der HBase zur
Speicherung der Daten verwendet. Die Daten werden ähnlich zu der in Kap. 3.1 vorgestellten
Speicherstrategie mehrfach abgespeichert, um eine effiziente Auswertung
aller Tripelmuster zu gewährleisten. Außerdem wird ein Greeedy-Algorithmus zur
Auswertung von SPARQL Basic Graph Pattern mit Hadoop vorgestellt.
Der in [14] beschriebene RDF-Triple-Store CumulusRDF speichert RDF-Daten in
Cassandra, um effizientes Nachschlagen einzelner Tripelmuster zu gewährleisten . Eine
Auswertung komplexerer Anfragen, wie etwa SPARQL-BGP-Anfragen, ist jedoch
nicht möglich. Die Speicherstrategie von CumulusRDF wurde in der vorgestellten
Implementierung übernommen und zur Auswertung angepasst. Eine konkrete Implementierung
des beschrieben RDF-Triple-Stores ist vorhanden und frei zugänglich 2 .
Ein weiteres Projekt, das sich mit der Speicherung von RDF-Daten mit Cassandra
befasst, ist rdf-cassandra 3 . Das Projekt stellt einen StorageAdapter für die Programmiersprache
Ruby bereit. Die Daten werden nur einfach abgespeichert und entsprechen
demnach ungefähr dem Schema der Spaltenfamilie „SPO“ in der vorliegenden
1 http://wiki.apache.org/incubator/HeartProposal
2 http://code.google.com/p/cumulusrdf/
3 https://github.com/bendiken/rdf-cassandra
43

Verwandte Arbeiten
Implementierung.
Die von dem Unternehmen Datastax entwickelte Hadoop-Distribution Brisk 4 kombiniert
Hadoop und Cassandra. Es handelt sich dabei zwar nicht um einen RDF-
Triple-Store, jedoch wird auch hier das Potenzial der Kombination beider Technologien
deutlich. Das HDFS wird durch ein auf Cassandra basierendes Dateisystem,
CassandraFS, ersetzt. Die Distribution stellt außerdem die Kernfunktionalitäten
MapReduce, Hive, sowie Job- und Tasktracker zur Verfügung. Aus der Kombination
ergibt sich die Möglichkeit sowohl Echtzeit-Anwendungen zu realisieren als auch die
zeitintensivere Analyse mit MapReduce durchzuführen.
4 http://www.datastax.com/products/brisk
44

7 Zusammenfassung
Die vorliegende Arbeit untersuchte, ob eine effiziente Speicherung und Auswertung
von RDF-Daten mit der Kombination aus dem quelloffenen Apache Hadoop Framework
und und der NoSQL-Datenbank Apache Cassandra möglich ist. Das hierfür
entwickelte System ermöglicht die Speicherung von RDF-Daten, sowie die Auswertung
von SPARQL Basic Graph Pattern-Anfragen auf diesen Daten.
Um einen schnellen Zugriff auf die gewünschten RDF-Daten zu erhalten, werden die
RDF-Daten dreimal in verschiedene Spaltenfamilien abgespeichert. Bei der Auswertung
wird die Anfrage zunächst in Tripelmuster unterteilt. Anschließend wird eine
Sequenz von MapReduce-Jobs erzeugt, die Verbünde zwischen den Tripelmustern
berechnen. Der Verbund selbst ist ein Map-Side-Join, bei dem die Daten während
der Map-Phase für jedes Tripel dynamisch geladen und verbunden werden. Die Zwischenergebnisse
und das Endergebnis werden auf das verteilte Dateisystem HDFS
geschrieben.
Die Evaluation der Anwendung mit dem SPARQL-Benchmark SP 2 Bench zeigte einerseits
vielversprechende Laufzeiten der Anwendung auf größeren Datensätze, andererseits
Probleme bei der Ausführung auf dem Cluster.
Zusammenfassend kann die Implementierung als „Proof-of-Concept“ betrachtet werden,
dessen Erkenntnisse bei der Implementierung als Grundlage weiterer Projekte
in diesem Bereich dienen können.
7.1 Ausblick
Über die Implementierung der Anwendung und der vorliegenden Arbeit hinausgehend
sollten verschiedene Einstellungen bei der Konfiguration von Hadoop und Cassandra
betrachtet werden. Insbesondere der parallele Einsatz im Rechner-Cluster
45

7.1 Ausblick
kann weiter untersucht und dokumentiert werden. Ebenfalls ist es vorstellbar verschiedene
Joins zu implementieren und deren Effizienz zu untersuchen, was aufgrund
der aufgeführten Limitierung seitens des ColumnFamilyInputFormat noch
nicht möglich ist. Die Implementierung unterstützt nur einen Teil des SPARQL-
Standards und könnte zur Unterstützung des gesamten SPARQL-Standards erweitert
werden. Außerdem hat die Reihenfolge der Tripelmuster einen großen Einfluss
auf die Laufzeit der Verbünde und bietet somit Möglichkeiten der Optimierung. Abschließend
könnte das Gesamtsystem mit einem ähnlichen System, z.B. auf HBase
aufbauend, verglichen werden, um die Gesamtleistung einordnen zu können.
46

Literaturverzeichnis
[1] T. Berners-Lee, J. Hendler, and O. Lassila, “The Semantic Web (Berners-Lee
et. al 2001),” May 2001.
[2] J. Sun and Q. Jin, “Scalable rdf store based on hbase and mapreduce,” in Advanced
Computer Theory and Engineering (ICACTE), 2010 3rd International
Conference on, vol. 1. IEEE, 2010, pp. V1–633.
[3] N. Shadbolt, W. Hall, and T. Berners-Lee, “The semantic web revisited,” Intelligent
Systems, IEEE, vol. 21, no. 3, pp. 96 –101, jan.-feb. 2006.
[4] P. Hitzler, M. Krötzsch, S. Rudolph, and Y. Sure, Semantic Web: Grundlagen.
Springer, 2008.
[5] F. Manola and E. Miller, Eds., RDF Primer, ser. W3C Recommendation.
World Wide Web Consortium, Feb. 2004.
[6] E. Prud’hommeaux and A. Seaborne, Eds., SPARQL Query Language for RDF,
ser. W3C Recommendation. World Wide Web Consortium, Jan. 2008.
[7] S. Ghemawat, H. Gobioff, and S.-T. Leung, “The google file system,” in SOSP,
M. L. Scott and L. L. Peterson, Eds. ACM, 2003, pp. 29–43.
[8] J. Dean and S. Ghemawat, “Mapreduce: a flexible data processing tool,” Commun.
ACM, vol. 53, no. 1, pp. 72–77, 2010.
[9] T. White, Hadoop: The Definitive Guide; 2nd rev. ed. O’Reilly, 2011.
[10] “Module 4: Mapreduce,” http://developer.yahoo.com/hadoop/tutorial/
module4.html, Online, letzter Aufruf 03.08.2011.
[11] E. Hewitt, Cassandra: The Definitive Guide. O’Reilly Media, 2010.
[12] R. Cattell, “Scalable sql and nosql data stores,” 2010.
[13] “Cassandra wiki api,” http://wiki.apache.org/cassandra/API/, Online, letzter
Aufruf 03.08.2011.
47

[14] G. Ladwig and A. Harth, “An rdf storage scheme on key-value stores for linked
data publishing,” Tech. Rep., 2010.
[15] J. Lin and C. Dyer, “Data-intensive text processing with mapreduce,” vol. 3,
no. 1, pp. 1–177, 2010.
[16] M. Schmidt, T. Hornung, G. Lausen, and C. Pinkel, “Sp2bench: A sparql performance
benchmark,” 2008.

Erklärung
Hiermit erkläre ich, dass ich diese Abschlussarbeit selbständig verfasst habe, keine
anderen als die angegebenen Quellen/Hilfsmittel verwendet habe und alle Stellen,
die wörtlich oder sinngemäß aus veröffentlichten Schriften entnommen wurden, als
solche kenntlich gemacht habe. Darüber hinaus erkläre ich, dass diese Abschlussarbeit
nicht, auch nicht auszugsweise, bereits für eine andere Prüfung angefertigt
wurde.
Ort, Datum
Unterschrift