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

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