Generierung und Vergleich von Charakteristika von ......Generierung und Vergleich von...
Transcript of Generierung und Vergleich von Charakteristika von ......Generierung und Vergleich von...
Generierung und Vergleich vonCharakteristika von Umweltsystemen in
Zeitmessreihen mittels Stratosphere
Diplomarbeit
zur Erlangung des akademischen GradesDiplominformatiker(in)
Humboldt-Universität zu BerlinMathematisch-Naturwissenschaftliche Fakultät II
Institut für Informatik
eingereicht von: Christian Fiebriggeboren am: 01.03.1978in: Leipzig
Gutachter(innen): Prof. Johann-Christoph Freytag, Ph.D.Dr. Mike Sips
eingereicht am: . . . . . .
Inhaltsverzeichnis
1 Einleitung 1
2 Spatial-Pyramid-Ansatz 52.1 Berechnung der räumlichen Pyramiden . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Vergleich der räumlichen Zustände . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3 Komplexität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.4 SSE - Sum of Squared Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.5 Kernel-Trick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.6 Benutzung des Spatial-Pyramid-Ansatzes in einem Clustering-Algorithmus . . . . . 172.7 Andere Verfahren zur Ähnlichkeitsabschätzung . . . . . . . . . . . . . . . . . . . . 18
3 Verteilte Systeme 203.1 Map/Reduce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.1 Operationen in Map/Reduce . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.2 Implementierungen von Map/Reduce . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Stratosphere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2.1 Architektur von Stratosphere . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.2 Das PACT-Programmiermodell in Stratosphere . . . . . . . . . . . . . . . . 313.2.3 Die Ausführungsschicht Nephele . . . . . . . . . . . . . . . . . . . . . . . . 34
4 Umsetzung des Spatial-Pyramid-Ansatzes in Stratosphere 354.1 Vorverarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2 Featuregenerierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.3 Implementierung des Spatial-Pyramid-Ansatzes . . . . . . . . . . . . . . . . . . . . 38
4.3.1 Featureermittlung und Erstellung der Featuresignaturen . . . . . . . . . . . 384.3.2 Vergleich und Bildung der Ähnlichkeitsmatrix . . . . . . . . . . . . . . . . . 47
4.4 Diskussion Parallelimplementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5 Evaluierung 525.1 Cluster am Geoforschungszentrum Potsdam . . . . . . . . . . . . . . . . . . . . . . 525.2 Test- und Vergleichsgegenstand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.3 Erwarteter Einfluss von Parametern des Spatial-Pyramid-Ansatzes . . . . . . . . . 555.4 Referenzdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.4.1 Ozeandaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.4.2 Synthetische Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.5 Evaluation Ozeandaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.5.1 Güte des Spatial-Pyramid-Ansatzes . . . . . . . . . . . . . . . . . . . . . . 645.5.2 Performance des Spatial-Pyramid-Ansatzes . . . . . . . . . . . . . . . . . . 66
i
ii INHALTSVERZEICHNIS
5.5.3 Qualität des Spatial-Pyramid-Ansatzes . . . . . . . . . . . . . . . . . . . . . 695.6 Evaluation der synthetischen Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.7 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6 Ausblick 74
A Anzahl der Vergleiche 78
B Tabellen für das Implementierungsbeispiel 79
C Evaluation Ozeandaten 81C.1 Messungen Laufzeit für den Spatial-Pyramid-Ansatz . . . . . . . . . . . . . . . . . 81
C.1.1 Graphen für die durchschnittlichen Laufzeiten . . . . . . . . . . . . . . . . . 81C.1.2 Tabellen für durchschnittlichen Laufzeiten . . . . . . . . . . . . . . . . . . . 87C.1.3 Standardabweichungen für die durchschnittlichen Laufzeiten . . . . . . . . . 90C.1.4 Verhältnisse der Laufzeiterhöhung . . . . . . . . . . . . . . . . . . . . . . . 94C.1.5 Separate durchschnittliche Laufzeiten für Pyramidisierung und Vergleich . . 96
C.2 Durchschnittliche Laufzeiten des Spatial-Pyramid-Ansatzes für 256 Features . . . . 97C.3 Durchschnittliche Laufzeiten für die SSE . . . . . . . . . . . . . . . . . . . . . . . . 98
C.3.1 Standardabweichung für SSE . . . . . . . . . . . . . . . . . . . . . . . . . . 99C.4 Güte der Vergleiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99C.5 Qualität der Vergleiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101C.6 Dauer eines Vergleichs zweier räumlicher Zustände . . . . . . . . . . . . . . . . . . 103
D Evaluation der synthetischen Daten 104
Abbildungsverzeichnis
1.1 Darstellung zweier verschiedener räumlicher Zustände . . . . . . . . . . . . . . . . 2
2.1 Vergleich unterschiedlich großer Teilbereiche . . . . . . . . . . . . . . . . . . . . . . 62.2 Aufteilung eines räumlichen Zustandes in Features . . . . . . . . . . . . . . . . . . 82.3 Darstellung eines Quad-Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Auflösungen eines räumlichen Zustands von Level 0 bis Level 3 . . . . . . . . . . . 112.5 Vergleich zweier räumliche Zustände . . . . . . . . . . . . . . . . . . . . . . . . . . 122.6 Beispiel für die Gewichtung des Vorkommen von gemeinsamen Features . . . . . . 14
3.1 Datenparallelität im Vergleich zur Pipeline-Parallelität . . . . . . . . . . . . . . . . 223.2 Symbolische Darstellung der Verteilung von Map- und Reduce-Operationen . . . . 253.3 Strukturierte Übersicht über Komponenten in Stratosphere . . . . . . . . . . . . . 303.4 Plan eines beliebigen PACT-Programms . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1 Aufteilung der Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.2 PACT-Schema (1.Teil) - Einlesen der Daten . . . . . . . . . . . . . . . . . . . . . . 384.3 PACT-Schema (2.Teil) - Erstellen der Features und der Featuresignaturen . . . . . 404.4 Alternativer Plan (Idee 1) zur Erstellung der räumlichen Pyramide . . . . . . . . . 424.5 Alternativer Plan (Idee 2) zur Erstellung der räumlichen Pyramide . . . . . . . . . 434.6 PACT-Schema (3.Teil) - Vergleich der räumlichen Zustände . . . . . . . . . . . . . 47
5.1 Visualisierung eines räumlichen Zustandes der Ozeandaten . . . . . . . . . . . . . . 575.2 Durchschnittliche Laufzeit für 1024 räumliche Zustände . . . . . . . . . . . . . . . 605.3 Grafische Darstellung der Anzahl der Vergleichsoperationen je Level . . . . . . . . 615.4 Durchschnittliche Laufzeiten für 256 Features . . . . . . . . . . . . . . . . . . . . . 625.5 Durchschnittliche Laufzeiten nur für die Pyramidisierung . . . . . . . . . . . . . . 645.6 Durchschnittliche Laufzeiten nur für den Vergleich . . . . . . . . . . . . . . . . . . 645.7 Güte des Spatial-Pyramid-Ansatzes gegenüber der SSE . . . . . . . . . . . . . . . . 655.8 Vergleich der Laufzeiten der SSE gegen eine Beispielkonfiguration . . . . . . . . . . 675.9 Verhältnis der Laufzeiten zwischen Spatial-Pyramid-Ansatz und SSE . . . . . . . . 685.10 Qualität des Spatial-Pyramid-Ansatzes gegenüber der SSE . . . . . . . . . . . . . . 705.11 Durchschnittliche Laufzeit für die synthetischen Daten für 1.000 Zustände . . . . . 71
C.1 Durchschnittliche Laufzeit bei Eingabemenge (grafische Darstellung): 1 . . . . . . . 81C.2 Durchschnittliche Laufzeit bei Eingabemenge (grafische Darstellung): 2 . . . . . . . 82C.3 Durchschnittliche Laufzeit bei Eingabemenge (grafische Darstellung): 4 . . . . . . . 82C.4 Durchschnittliche Laufzeit bei Eingabemenge (grafische Darstellung): 8 . . . . . . . 83C.5 Durchschnittliche Laufzeit bei Eingabemenge (grafische Darstellung): 16 . . . . . . 83C.6 Durchschnittliche Laufzeit bei Eingabemenge (grafische Darstellung): 32 . . . . . . 84
iii
iv ABBILDUNGSVERZEICHNIS
C.7 Durchschnittliche Laufzeit bei Eingabemenge (grafische Darstellung): 64 . . . . . . 84C.8 Durchschnittliche Laufzeit bei Eingabemenge (grafische Darstellung): 128 . . . . . 85C.9 Durchschnittliche Laufzeit bei Eingabemenge (grafische Darstellung): 256 . . . . . 85C.10 Durchschnittliche Laufzeit bei Eingabemenge (grafische Darstellung): 512 . . . . . 86C.11 Durchschnittliche Laufzeit bei Eingabemenge (grafische Darstellung): 1024 . . . . . 86C.12 Fehler des Spatial-Pyramid-Ansatzes . . . . . . . . . . . . . . . . . . . . . . . . . . 100C.13 Qualität des Spatial-Pyramid-Ansatzes . . . . . . . . . . . . . . . . . . . . . . . . . 102
Tabellenverzeichnis
3.1 Beispielinhalt für das Map/Reduce-Beispiel . . . . . . . . . . . . . . . . . . . . . . 27
4.1 Featureintervalle für Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2 Beispiel Teilbereichskoordinaten für einen Punkt . . . . . . . . . . . . . . . . . . . 46
5.1 Anzahl der Teilbereiche und Gesamtanzahl der Teilbereiche je Level . . . . . . . . 59
A.1 Anzahl der Vergleichsoperationen je Level und Feature . . . . . . . . . . . . . . . . 78
B.1 Inhalt der Beispieldatei ’file1.asc’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79B.2 Inhalt der Beispieldatei ’file2.asc’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79B.3 Signaturen aller Level der Datei file1.asc . . . . . . . . . . . . . . . . . . . . . . . . 79B.4 Signaturen aller Level der Datei file2.asc . . . . . . . . . . . . . . . . . . . . . . . . 80B.5 Gewichtungsfaktoren je Level für L = 3 . . . . . . . . . . . . . . . . . . . . . . . . 80B.6 Featuredistanzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
C.1 Durchschnittliche Laufzeit bei Eingabemenge: 1 . . . . . . . . . . . . . . . . . . . . 87C.2 Durchschnittliche Laufzeit bei Eingabemenge: 2 . . . . . . . . . . . . . . . . . . . . 87C.3 Durchschnittliche Laufzeit bei Eingabemenge: 4 . . . . . . . . . . . . . . . . . . . . 87C.4 Durchschnittliche Laufzeit bei Eingabemenge: 8 . . . . . . . . . . . . . . . . . . . . 88C.5 Durchschnittliche Laufzeit bei Eingabemenge: 16 . . . . . . . . . . . . . . . . . . . 88C.6 Durchschnittliche Laufzeit bei Eingabemenge: 32 . . . . . . . . . . . . . . . . . . . 88C.7 Durchschnittliche Laufzeit bei Eingabemenge: 64 . . . . . . . . . . . . . . . . . . . 89C.8 Durchschnittliche Laufzeit bei Eingabemenge: 128 . . . . . . . . . . . . . . . . . . 89C.9 Durchschnittliche Laufzeit bei Eingabemenge: 256 . . . . . . . . . . . . . . . . . . 89C.10 Durchschnittliche Laufzeit bei Eingabemenge: 512 . . . . . . . . . . . . . . . . . . 90C.11 Durchschnittliche Laufzeit bei Eingabemenge: 1024 . . . . . . . . . . . . . . . . . . 90C.12 Standardabweichung der Laufzeit bei Eingabemenge: 1 . . . . . . . . . . . . . . . . 90C.13 Standardabweichung der Laufzeit bei Eingabemenge: 2 . . . . . . . . . . . . . . . . 91C.14 Standardabweichung der Laufzeit bei Eingabemenge: 4 . . . . . . . . . . . . . . . . 91C.15 Standardabweichung der Laufzeit bei Eingabemenge: 8 . . . . . . . . . . . . . . . . 91C.16 Standardabweichung der Laufzeit bei Eingabemenge: 16 . . . . . . . . . . . . . . . 92C.17 Standardabweichung der Laufzeit bei Eingabemenge: 32 . . . . . . . . . . . . . . . 92C.18 Standardabweichung der Laufzeit bei Eingabemenge: 64 . . . . . . . . . . . . . . . 92C.19 Standardabweichung der Laufzeit bei Eingabemenge: 128 . . . . . . . . . . . . . . 93C.20 Standardabweichung der Laufzeit bei Eingabemenge: 256 . . . . . . . . . . . . . . 93C.21 Standardabweichung der Laufzeit bei Eingabemenge: 512 . . . . . . . . . . . . . . 93C.22 Standardabweichung der Laufzeit bei Eingabemenge: 1024 . . . . . . . . . . . . . . 94
v
vi TABELLENVERZEICHNIS
C.23 Verhältnismäßige Erhöhung der Laufzeit von einem Level zu vorhergehenden Levelfür 1024 räumliche Zustände . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
C.24 Verhältnismäßige Erhöhung der Laufzeit von einem Feature zu vorhergehenden Fea-ture für 1024 räumliche Zustände . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
C.25 Messwerte der Laufzeit getrennt nach Laden und Vergleichen mit 1024 räumlichenZuständen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
C.26 Alle durchschnittliche Laufzeiten für 256 Feature über alle Level . . . . . . . . . . 97C.27 Durchschnittliche Laufzeiten für die Implementierung der SSE . . . . . . . . . . . . 98C.28 Standardabweichung für die Implementierung der SSE . . . . . . . . . . . . . . . . 99C.29 Vergleich der Güte zwischen SSE und Spatial-Pyramid-Ansatz . . . . . . . . . . . 99C.30 Vergleich der Qualität zwischen SSE und Spatial-Pyramid-Ansatz . . . . . . . . . . 101C.31 Durchschnittliche Dauer pro paarweisem Vergleich von räumlichen Zuständen . . . 103
D.1 Durchschnittliche Laufzeiten bei der Berechnung synthetischer Daten für die Einga-bemenge: 1000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Kapitel 1
Einleitung
Um komplexe Umweltsysteme besser verstehen zu können, untersuchen Geowissen-
schaftler in Simulationen Prozesse wie atmosphärische Veränderungen, Bewegungen
der Erdplatten oder von Wassermassen. Um ein tieferes Verständnis der simulier-
ten Systeme zu erhalten, werden diese Simulationen mehrfach ausgeführt und dabei
die Eingabeparameter verändert. Simulationen und die zugrundeliegenden Model-
le dienen dazu, reale Umgebungen und Einflussfaktoren eines Systems abzubilden
[13]. So soll das Spektrum der Aus- und Wechselwirkungen in zeitlicher und räumli-
cher Hinsicht in der simulierten Umgebung beobachtet werden. Als Ergebnis solcher
Simulationen und Messungen können riesige Datenmengen entstehen, deren Volu-
men schnell einige hunderte Gigabyte umfassen kann. Der Umfang der Daten ist
abhängig von der zeitlichen oder räumlichen Auflösung des verwendeten Sensoren.
Die Möglichkeit, diese Daten in vertretbarer Zeit zu untersuchen und entsprechend
auszuwerten, ist essentiell, um einen Einblick in das Verhalten der Umweltsysteme
zu erlangen.
Diese Diplomarbeit untersucht geowissenschaftliche Zeitreihen, bei denen jeder Zeit-
schritt einen räumlichen Zustand eines realen Prozesses wiedergibt. Eine Eigenschaft
dieser geowissenschaftlichen Zeitreihen ist es, dass sie das Verhalten des untersuch-
ten Systems über einen langen Zeitraum darstellen und einige tausend Einzelschritte
umfassen kann. Daraus ergibt sich eine große Menge von Daten, die von Geowiss-
chenschaftlern untersucht werden, um charakteristische räumliche Muster in diesen
1
2 KAPITEL 1. EINLEITUNG
Reihen zu finden. Dazu können diese Daten ihrer Ähnlichkeit nach gruppiert wer-
den [10]. Diese Gruppen können dann entsprechend fachlich beurteilt und untersucht
werden. Um diese Gruppen zu bilden, muss man die Ähnlichkeit zweier räumlicher
Zustände messen können.
Abbildung 1.1: Darstellung zweier verschiedener räumlicher Zustände aus einer Hochwassersimula-
tion. Die Ähnlichkeit beider Zustände in SSE ist ∼ 135.388 und unter dem Spatial-Pyramid-Ansatz
∼ 38.745 (bei Level 4 und 8 Features).
Eine einfache Methode, die Ähnlichkeit zwischen räumlichen Zuständen zu messen,
ist die Summe der Quadratischen Fehler (engl.: Sum of Squared Errors, kurz: SSE).
Die SSE berechnet die quadratische Differenz zwischen zwei Punkten in räumli-
chen Zuständen aus zwei Zeitschritten. Es wird davon ausgegangen, dass die geo-
graphische Position der räumlichen Zustände sich über die Zeit nicht ändern (Abbil-
dung 1.1). Die Berechnung der SSE hängt von der Anzahl der Messpunkte ab und
ist in der Regel sehr teuer, da alle Punkte eines räumlichen Zustandes miteinander
verglichen werden müssen. Ein weiterer Nachteil ist, dass die SSE nur Punkt für
Punkt vergleicht und den räumlichen Zustand daher immer in seiner ganzen Dimen-
sion betrachtet. Verschieben sich räumliche Zustände in andere räumliche Regionen
kann die SSE dies nicht berücksichtigen. In der vorliegenden Arbeit soll eine alterna-
tive Möglichkeit untersucht werden, die Ähnlichkeit zwischen räumlichen Zuständen
mit Hilfe einer räumlichen Pyramide zu bestimmen, die nicht so teuer wie die SSE
ist, aber ähnlich gute Ergebnisse liefert. Weiterhin soll der hier untersuchte Ansatz
3
parallelisierbar sein.
Die Idee einer räumlichen Pyramide in dieser Arbeit ist es, den Wertebereich in eine
Anzahl von Intervallen zu quantisieren, und die Häufigkeit von Messwerten, die in
bestimmte Intervalle fallen, zu messen. Zusätzlich wird der räumliche Zustand in im-
mer kleinere Teilbereiche aufgeteilt, so dass eine räumliche Pyramide entsteht. Die
Featurehistogramme, also die gemessenen Intervalle in den Teilbereichen, werden
miteinander verglichen. In Abhängigkeit von der Größe der Teilbereiche werden die
Vergleichswerte umgekehrt proportional gewichtet. Die Gewichtung ist notwendig,
da sich ein Feature in einem größeren Teilbereich schwerer lokalisieren lässt als in
einem kleineren [20].
Der Vorteil einer räumlichen Pyramide ist, dass die Anzahl der Elemente, die zur
Berechnung der Ähnlichkeit erforderlich sind, erheblich reduziert wird und dass Ähn-
lichkeiten in Abhängigkeit des räumlichen Auftretens berücksichtigt und bewertet
werden. Ein weiterer Vorteil ist, dass sich mit Hilfe des sogenannten Kernel-Tricks
[22] aus den Ähnlichkeitswerten der räumlichen Pyramide eine Euklidische Distanz
ableiten lässt. Dies kann in vielen Clusteringalgorithmen eingesetzt werden, die auf
der Berechnung der Euklidischen Distanz basieren und diese signifikant beschleuni-
gen1.
Um die Ähnlichkeiten für ein großes Volumen an räumlichen Zuständen in einer ver-
tretbaren Zeit zu berechnen, reicht ein effizienter Algorithmus allein nicht aus. Die
Ähnlichkeitswerte, die gewonnen werden, werden zwischen allen räumlichen Zustän-
den errechnet. Auch mit einem effizienten Ansatz würde die Berechnung bei hinrei-
chend großer Datenmenge sehr lange dauern. Daher soll im Folgenden eine parallele
Beispielimplementierung des Spatial-Pyramid-Ansatzes in Stratosphere umgesetzt
werden, die einerseits Parallelisierbarkeit des hier verfolgten Ansatzes zeigt und an-
dererseits bei einer Skalierung der Eingabemenge ebenfalls skalieren kann. Stratos-
phere ist ein Verteiltes System, welches das Map/Reduce Paradigma erweitert und
ein eigenes Programmier- und Ausführungsmodell mit sich bringt. Die parallele Im-
1Die meisten Clusteringalgorithmen basieren auf der Euklidischen Distanz und hängen stark von deren Berech-
nung ab. Diese Abhängigkeit kann reduziert werden, wenn aus den schnell berechneten Ähnlichkeiten der räumlichen
Pyramide die Euklidische Distanz per Lookup in der Ähnlichkeitsmatrix gebildet wird.
4 KAPITEL 1. EINLEITUNG
plementierung bedient sich verteilter Ressourcen, damit eine Berechnung über riesige
Datenmengen, wie sie typischerweise bei geowissenschaftlichen Zeitreihen vorkom-
men, schneller vonstatten gehen kann.
Abschließend soll die Implementierung bezüglich Laufzeit gegen eine Beispielimple-
mentierung der SSE verglichen werden. Im Vergleich zu der SSE bietet der Spatial-
Pyramid-Ansatz einen Geschwindigkeitsvorteil, der bei ausreichender Qualität der
Ergebnisse zu einer deutlichen Beschleunigung der Berechnung der Ähnlichkeitsma-
trix führt.
Kapitel 2
Spatial-Pyramid-Ansatz
Die zu untersuchenden Daten der räumlichen Zustände liegen als Punktmatrix vor
und enthalten Messwerte in einem 2-D Raster. Die Ähnlichkeit zwischen zwei räum-
lichen Zuständen wird sehr oft mit Hilfe der Sum of Squared Errors (SSE) als Di-
stanz berechnet. Die Distanz zweier räumlichen Zustände errechnet sich bei der SSE
aus der Summe aller quadrierten Punktabstände. Diese Art des Vergleichs benötigt
aber bei einer Implementierung sehr viel Zeit und Speicherressourcen, da hierfür
jeder Punkt bei einem Vergleich zweier räumlicher Zustände miteinander verglichen
werden muss. Der Vergleich zweier räumlicher Zustand mit je m ∗ n Messpunkten
hat eine Komplexität von O(m ∗ n). Die Pyramide [16] soll durch eine gleichmäßige
Unterteilung des Raumes und das Reduzieren des Wertebereiches auf Features die
Anzahl der notwendigen Vergleiche pro paarweisen Vergleich der räumliche Zustän-
de deutlich reduzieren. Der Spatial-Pyramid-Ansatz beschleunigt Vergleiche enorm,
wenn das Produkt der Unterteilungen S und der Features F deutlich unter der
Anzahl der Messpunkte liegt. Der Vorteil der Pyramide liegt darin, dass die hohe
Dimensionalität des Eingaberaumes reduziert wird [32].
Die räumliche Pyramide reduziert die Menge der einzelnen Vergleiche durch das
Zusammenfassen der Messpunkte in regelmäßige Teilbereiche und die Aggregation
der Messpunkte in einem Histogramm. Dadurch geht zwar die Detailinformation mit
der genauen Lage der Punkte verloren, aber Ähnlichkeiten benachbarter Teilbereiche
können durch die Abstufung der Teilbereiche trotzdem gemessen werden. Dafür ge-
5
6 KAPITEL 2. SPATIAL-PYRAMID-ANSATZ
winnt man bei der räumlichen Pyramide eine stark reduzierte Menge an Information,
die noch in den Vergleich einfließen. Die Pyramide ist ein Multi-Resolution-Ansatz,
da sie einen räumlichen Zustand in regelmässige Teilbereich unterteilt, gemeinsa-
me Eigenschaften in unterschiedlich großen Bereichen misst und bewertet. Würde
nur eine Ebene der Teilbereiche benutzt werden, so könnten Eigenschaften, die in
benachbarten Teilbereichen liegen, nicht als gemeinsame Eigenschaften beim Ver-
gleich erfasst werden. Wird der Teilbereich größer, so können in diesem die Feature
beim gemeinsamen Vergleich erfasst werden (Abbildung 2.1). Features, die aber nur
in größeren Teilbereichen übereinstimmen, werden umgekehrt proportional zu der
Größe des Levels gewichtet. Ein Level ist eine Ebene der räumlichen Pyramide, das
alle gleich großen Teilbereiche enthält. Features in kleineren Level werden so schlech-
ter gestellt, als in größeren, da in kleineren Level die Features schwerer lokalisierbar
sind.
Grid 1 Grid 2
x
x
x
x
# Featuresvon x
x
x
x
x
0
0 1
0
2Level 0
Level 1
Abbildung 2.1: Der Vergleich aller Teilbereiche zweier räumlicher Zustände für das Feature x. Im
Level 1 wird das Feature nur in einem Teilbereich übereinstimmend gefunden. Im Level 0 sind die
Features, die vorher in benachbarten Teilbereichen lagen, in einem Teilbereich zusammengefasst
und können so beim Vergleich in diesem Level erfasst werden.
7
Zur Aufteilung eines räumlichen Zustandes in eine räumliche Pyramide in mehreren
Level unterteilt. Im ersten Level umfasst der einzige Teilbereich dieses Level den ge-
samten räumlichen Zustand. In jedem weiteren Level werden die vorher ermittelten
Teilbereiche in jeder Ausdehnung in der Mitte geteilt, so dass je vorher vorhande-
nem Teilbereich vier neue gleich große Teilbereiche entstehen. Jedes Level enthält
also viermal so viele Teilbereiche wie das Vorgänger-Level. Dadurch entsteht eine
räumliche Pyramide, bei der in jedem Level die Teilbereiche kleiner werden. Alle
Teilbereiche eines Level ergeben immer wieder die gesamte Matrix des räumlichen
Zustandes (Abbildung 2.3).
Sind die Teilbereiche gebildet, werden die jeweils darin enthaltenen Features gezählt
und in Histogrammen zusammengefasst. Um Features aus den Messwerten zu ermit-
teln, wird der Wertebereich über alle Punkte der räumlichen Zustände, der durch
ein globales Minimum und Maximum begrenzt ist, in F gleich große Intervalle auf-
geteilt. Die Intervalle werden fortlaufend nummeriert und als Feature f bezeichnet.
Liegt ein Punkt in einem Intervall des Feature f , so wird zur Repräsentation dieses
Punktes das Feature f gezählt.
Durch die Einteilung des Wertebereiches in Featureintervalle werden nahe beiein-
ander liegende Messwerte, die sich innerhalb eines Featureintervalls befinden, beim
Vergleich identisch bewertet (Abbildung 2.2). Beim späteren Vergleich werden nur
identische Features miteinander verglichen, und es findet kein Vergleich bezüglich
der Ähnlichkeit von Features statt.
8 KAPITEL 2. SPATIAL-PYRAMID-ANSATZ
(a) (b)
(c) (d)
Abbildung 2.2: Die Messwerte eines räumlichen Zustandes einer Hochwassersimulation wurden
hier in eine unterschiedlich große Anzahl Features aufgeteilt. Das in (a) verteilte Spektrum der
Werte wurde in 8 Features aufgeteilt (b). Jedem Feature wurde in (a), (b) und (c) ein Grauwert
zugeordnet. Die Features zeigen in (a) nur ein schemenhaftes Bild des räumlichen Zustandes;
manche Information ist in der Darstellung auch nicht mehr sichtbar. Mit 16 Features (c) und
32 Features (d) wird die strukturelle Aufteilung deutlich sichtbarer. Details treten mit höherer
Featureanzahl auch umso deutlicher hervor.
Eine feinere Quantisierung des Wertebereiches erfasst auch kleine räumliche Ver-
änderungen und hat zur Folge, dass die später über die Features gebildeten Histo-
gramme sehr groß werden können. Die Anzahl der Vergleichsoperationen bildet sich
aus dem Produkt der Anzahl der Features und der Größe der räumlichen Pyramide,
und sollte die Anzahl der Messpunkte nicht übersteigen. Daher ist es wichtig, ein
9
gutes Maß für die Anzahl der Features zu finden, um einen effizienten Vergleich zu
ermöglichen.
Durch das Zählen der Features entsteht ein Histogramm für jeden Teilbereich mit
der Anzahl der Eigenschaften in jedem Bin des Histogramms. Ein Bin steht in ei-
nem Histogramm für ein Feature und die Höhe eines Bins gibt die Häufigkeit des
Auftretens des Feature in dem Teilbereich wieder.
Die räumliche Pyramide des Spatial-Pyramid-Ansatzes kann man auch als Quad-
Tree-Struktur darstellen (Abbildung 2.3), die den gesamten Bereich in jedem Level
in vier gleich große Teile unterteilt. Die Berechnung der Pyramide kann effizient
durchgeführt werden, wenn die Pyramide als Quad-Tree interpretiert wird. Der
Histogramm-Eintrag eines Knotens bildet sich aus der Summe der Histogramme
seiner Kinder [30]. Eine Summe der Histogramme wird gebildet, indem ein neues
Histogramm erstellt wird, bei dem jeder Bin aus der Summe der korrespondieren-
den Bins in den Kindknoten repräsentiert wird. Die Gesamtmenge der Teilbereiche
und damit auch die Tiefe des Quad-Tree wird eingegrenzt, indem der Anwender eine
maximale Tiefe der Pyramide angibt.
10 KAPITEL 2. SPATIAL-PYRAMID-ANSATZ
Level 0
Level 1
Level 2
QuadTree Aufteilung eines Gridsin unterschiedliche Auflösungen
Abbildung 2.3: Jeder Knoten im Quad-Tree stellt ein Histogramm des entsprechenden Teilbereiches
dar (gestrichelte Linie). Ein Knoten im Quad-Tree lässt sich als Summe der vier Kindknoten
auffassen.
Um zwei räumliche Zustände miteinander zu vergleichen, werden nur noch die Histo-
gramme der verschiedenen korrespondierenden Teilbereiche miteinander verglichen,
indem die Schnittmenge dieser beiden Histogramme [20] gebildet wird. Im Gegensatz
zur SSE ist die Menge der durchgeführten Vergleiche pro Vergleich zweier räumlicher
Zustände nur noch abhängig von der Anzahl der gewählten Stufen aus dem Quad-
Tree der Anzahl der Features. Es liegt keine Abhängigkeit der Komplexität mehr
zur ursprünglichen Größe der räumliche Zustände vor. Die Menge der Vergleiche,
die durchgeführt werden ist:
O(22∗L ∗ F )
Mit L als die Höhe der Pyramide und F für die Anzahl der Features.
Die Effizienz des Spatial-Pyramid-Ansatzes resultiert daraus, dass die Elemente der
räumlichen Pyramide, die verglichen werden, deutlich geringer in der Anzahl sind
als ein Punktvergleich der räumlichen Zustände bei der SSE. Die räumliche Pyra-
2.1. BERECHNUNG DER RÄUMLICHEN PYRAMIDEN 11
mide und die dazugehörigen Histogramme können vorberechnet werden, so dass der
Vergleich nur noch auf der Pyramide stattfindet.
2.1 Berechnung der räumlichen Pyramiden
Zur Anwendung des Spatial-Pyramid-Ansatzes wird ein Quad-Tree über den räumli-
chen Zustand gebildet. Dazu werden der räumliche Zustand und die darauf basieren-
den Teilbereiche immer wieder in vier gleich große Teile unterteilt. Die Unterteilung
stoppt an einer vorher definierten Schranke, welche vom Nutzer als die maxima-
le Anzahl der Level definiert wird. Jede Unterteilung der Teilbereiche wird Level
genannt (Abbildung 2.4).
Level 0 Level 1 Level 2 Level 3
Abbildung 2.4: Auflösungen eines räumlichen Zustands von Level 0 bis Level 3: In jedem Level
werden die Teilbereiche des vorhergehenden Levels wieder in vier gleich große Teile geteilt. Für
jeden Teilbereich wird jeweils ein Histogramm gebildet.
Die in jedem Teilbereich vorkommenden Features werden gezählt und in einem Hi-
stogramm H l(i) je Teilbereich zusammengefasst, wobei l für das Level und i ∈ 1..22l
für einen fortlaufenden Index der Teilbereiche innerhalb des Levels steht. Das Hi-
stogramm gibt die Häufigkeit des Auftretens von Messwerten innerhalb des Teilbe-
reiches des räumlichen Zustandes wieder.
2.2 Vergleich der räumlichen Zustände
Zum Vergleich zweier räumlicher Zustände G1 und G2 werden zunächst die ge-
meinsamen Features je korrespondierendem Teilbereich (Abbildung 2.5) mittels der
Schnittmenge der Histogramme für jedes Level gebildet [33], indem für jeden Bin der
12 KAPITEL 2. SPATIAL-PYRAMID-ANSATZ
beiden Histogramme das Minimum gebildet und summiert wird. Korrespondierende
Teilbereiche sind jene, die aus demselben Level stammen und denselben Teilbereich
umfassen. Die Schnittmenge Il wird mit folgender Formel berechnet:
Il(H lG1, H l
G2) =
22∗l∑i=1
min(H lG1((i)), H l
G2((i)))
Grid 1 Grid 2
Level 0
Level 1
Level 2
Abbildung 2.5: Vergleich zweier räumliche Zustände. Beim Vergleich von zwei räumlichen Zustän-
den werden die Histogramme der korrespondierenden Teilbereiche (gestrichelte Linien) miteinander
verglichen.
Diese Summe Il(H lG1, H l
G2) stellt nun die gemeinsamen Features je Level dar, die in
beiden räumlichen Zuständen G1 und G2 in den Teilmengen zugleich vorkommen.
Da beim Erstellen der Schnittmengen in jedem kleineren Level auch die Features
mitgezählt werden, die in dem nächstgrößeren Level vorkommen, sollen je Level
nur die Features gezählt werden, die „neu“ sind. Um die in diesem Level exklusiv
2.2. VERGLEICH DER RÄUMLICHEN ZUSTÄNDE 13
neu hinzugekommenen Features zu ermitteln wird die Differenz Dl jeweils zweier
aufeinander folgender Level über die gemeinsamen Features gebildet.
Dl = Il − Il+1; l ∈ {0..L− 2}
Für das größte Level wird keine Differenz gebildet, da für diese nichts doppelt gezählt
werden kann, denn es liegt keine größeres Level vor. Für das größte Level gilt:
DL−1 = IL−1
Diese Differenzen, also die „neuen“ Features je Level, werden in Abhängigkeit ihres
Levels gewichtet, so dass gemeinsame Features in größeren Leveln stärker gewich-
tet werden. Je größer die Teilbereiche von ihrem Umfang her sind, desto schwächer
werden die gemeinsamen Features bewertet. Die Gewichtung wird in dieser Art vor-
genommen, da Features in größeren Teilbereichen schwerer zu lokalisieren sind als in
kleineren (Abbildung 2.6). Gemeinsame Features, die sich erst in einem niedrigeren
Level ergeben, sollen so in der Gesamtbetrachtung durch die Gewichtung schlechter
gestellt werden als Features in größeren Leveln. Der Gewichtungsfaktor wl ergibt
sich aus der Tiefe des Levels:
wl = 2−(L−1−l)
Die Ähnlichkeit der beiden räumlichen Zustände G1, G2 ergibt sich, indem alle ge-
wichteten Werte über alle Level aufsummiert werden:
KL(G1, G2) =L−1∑l=0
wlDl
14 KAPITEL 2. SPATIAL-PYRAMID-ANSATZ
Z1
Z3
Z2
Z4
x
x
x
Abbildung 2.6: Vier räumliche Zustände sollen miteinander verglichen werden. Für den Vergleich
wird das Feature ’x’ benutzt und die räumliche Pyramide wird über 2 Level gebildet. Z1 und Z2 sind
zueinander identisch, denn in Level 1 haben beide in demselben Teilbereich das gesuchte Feature.
Hätte man das Level 1 nicht, wären Z1 und 2 zu Z3 genauso identisch. Z3 und Z4 wären gleich
unähnlich zu Z1 und Z2, wenn nur das Level 1 betrachtet werden. Eine umgekehrt proportionale
Gewichtung über die Größe des Levels gibt in eine Abstufung darüber, in welchem Level ein
gemeinsames Feature gefunden wird. Nur für ’x’ wären die Ähnlichkeiten nun (Z1, Z2)=1.0; (Z1,
Z3)=0.5; (Z1, Z4)=0.0
2.3 Komplexität
Die für einen Vergleich von räumlichen Zuständen notwendigen Operationen für
den Spatial-Pyramid-Ansatz hängen linear von der Anzahl der Features F , also der
Anzahl der Bins in den Histogrammen ab. Außerdem spielt die Anzahl der Level
L eine Rolle. Die Menge der einzelnen Vergleiche pro paarweisem Vergleich der
räumlichen Zustände ist:
F
L−1∑l=0
22l
Dies bedeutet, ein Performancegewinn gegenüber der SSE ist für den Spatial-Pyra-
mid-Ansatz nicht in jedem Fall gegeben, sondern hängt von einer geeigneten Wahl
der Parameter l und F ab. Bei entsprechend hohen Level und einer Anzahl Fea-
tures kann die Anzahl der Vergleichsoperation die Anzahl der Messwerte in einem
räumlichen Zustand, die für die SSE die Anzahl der Vergleiche ist, übersteigen.
2.4. SSE - SUM OF SQUARED ERRORS 15
Zusammenfassend lässt sich sagen, dass die Effizienz des Spatial-Pyramid-Ansatzes
gegenüber anderen Vergleichen davon abhängt, dass die Anzahl der Vergleiche redu-
ziert wird. Dies gelingt nur, wenn die Anzahl der Level und Features so gewählt wird,
dass eine Reduktion der Datenmenge vorliegt. Dies gilt vor allem wenn folgendes
gilt:
F
L−1∑l=0
22l < dimx ∗ dimy
dimx und dimy sind die Dimensionen der räumlichen Zustände.
2.4 SSE - Sum of Squared Errors
Die Summe der quadratischen Fehler (kurz: SSE) dient in dieser Arbeit als Ver-
gleichsmaß dazu, Ähnlichkeiten, die aus dem Spatial-Pyramid-Ansatz gewonnen
wurden, in Relation zueinander zu stellen. Dabei können die Ähnlichkeiten und
Distanzen aber nicht direkt verglichen werden. Beim Vergleich der zwei Verfahren
gegeneinander wird nach Übereinstimmung der direkten Nachbarn gesucht. Um die
direkten Nachbarn zu ermitteln, werden für jeden räumlichen Zustand die n ähn-
lichsten räumlichen Zustände aus dem Spatial-Pyramid-Ansatz und die n räumlichen
Zustände mit der geringsten Distanz aus der SSE gewählt. Diese beiden Mengen wer-
den mit NSSEn für die SSE und NSP
n für den Spatial-Pyramid-Ansatz bezeichnet. Die
Schnittmenge der beiden Mengen NSSEn ∩NSP
n gibt die gemeinsamen Nachbarn aus
den n ähnlichsten Nachbarn wieder. |NSSEn ∩NSP
n | ergibt die Anzahl der gemeinsa-
men Nachbarn, die zu n ins Verhältnis gesetzt werden kann.
Um mit der SSE die Distanz zweier räumliche Zustände G1 und G2 mit den Kan-
tenlängen dimx und dimy zu bilden, wird die Summe der quadrierten Differenzen
der Werte für jeden Punkt erstellt. Je mehr dieses Maß gegen null tendiert, desto
ähnlicher sind sich die beiden räumlichen Zustände. Davon ausgehend, dass beide
räumlichen Zustände denselben Umfang haben, ermittelt folgende Formel die Di-
stanz der beiden räumlichen Zustände G1 und G2 zueinander:
d(G1, G2) =dimx∑
i
dimy∑j
(G1(i, j)−G2(i, j))2
16 KAPITEL 2. SPATIAL-PYRAMID-ANSATZ
G(i, j) steht für einen Messwert im räumlichen Zustand G mit den Koordinaten i
und j. Das SSE-Maß vergleicht also jeden Punkt zweier räumlicher Zustände mit-
einander. Wenn die räumlichen Zustände die Dimension dimx und dimy haben,
sind (dimx ∗ dimy) Vergleiche notwendig. Diese Komplexität bei jedem paarweisen
Vergleich zweier räumlicher Zustände, resultierend aus der Abhängigkeit der Be-
rechnung von den Dimensionen der räumlichen Zustände, hat zur Folge, dass die
Laufzeit sehr lang werden kann.
2.5 Kernel-Trick
Mit dem Spatial-Pyramid-Ansatz erhalten wir eine nicht-lineare Abbildung aus ei-
nem Raum mit der Dimension dimx × dimy, also mit den Dimensionen der räum-
lichen Zustände in einen n-dimensionalen Featureraum [8]. n steht hier für die An-
zahl der räumlichen Zustände, die alle miteinander verglichen werden. Es gibt viele
Clustering-Algorithmen, die einen euklidischen Abstand benutzen [18], um die Di-
stanz eines Elementes zum Zentrum eines Clusters zu bestimmen. Um bei einer
späteren Implementierung eines Clustering-Algorithmus die Ähnlichkeiten aus dem
Spatial-Pyramid-Verfahren zu benutzen, müssen bei einigen Clustering-Algorithmen
diese Ähnlichkeiten in Distanzen transformierbar sein2. Der Spatial-Pyramid-Ansatz
ist eine Kernel-Funkion, die das Mercer-Theorem [21] erfüllt. Für das Ergebnis des
Spatial-Pyramid-Verfahrens als Kernel-Funktion [20, 31] gilt folgendes: K(xi, xj) =
φ(xi) ∗ φ(xj);xi, xj ∈ X [16]; wobei X die Menge der räumlichen Zustände ist. Die
Kernel-Funktion ist somit beschrieben als inneres Produkt der Funktion φ auf den
Vektoren xi und xj. Mit Hilfe des Kernel-Tricks [22] kann ein euklidischer Abstand
zwischen den räumlichen Zuständen aus den vorher gewonnenen Ähnlichkeiten er-
rechnet werden, ohne Kenntnis über die originalen räumlichen Zustände haben zu
2Mit Hilfe des Kernel-Tricks wird die euklidische Distanz im Feature-Raum berechnet.
2.6. BENUTZUNG DES SPATIAL-PYRAMID-ANSATZES IN EINEM CLUSTERING-ALGORITHMUS17
müssen:
||φ(xi)− φ(xj)||2 = (φ(xi)− φ(xj))(φ(xi)− φ(xj))T
=n∑
k=1
(φ(xik)− φ(xjk))2
=n∑
k=1
(φ(xik)2 − 2φ(xik)φ(xjk) + φ(xjk)
2)
= φ(xi)φ(xi) + φ(xj)φ(xj)− 2φ(xi)φ(xj)
= K(xi, xi) +K(xj, xj)− 2K(xi, xj)
Die Ähnlichkeiten können nun mittels der einer Summe und Differenz als Distanz
abgebildet werden. Sie drücken so den euklidischen Abstand der Ähnlichkeit der bei-
den räumlichen Zustände zueinander aus. Dies Abbildung kann in distanzbasierten
Clusteringverfahren eingesetzt werden, um ähnliche Zustände zu gruppieren.
2.6 Benutzung des Spatial-Pyramid-Ansatzes in einem Clus-
tering-Algorithmus
Ein Clustering-Algorithmus soll aus einer Menge von Eingabeobjekten Gruppen bil-
den. Diese Gruppen sollen möglichst zueinander ähnliche Objekte enthalten, aber
diese Cluster sollen selbst wieder so unähnlich wie möglich sein. Es gibt hierar-
chische und partitionierende Verfahren, mit denen Cluster gebildet werden können
[10]. Ein partitionierendes Verfahren ist zum Beispiel k-Means [17]. Bei k-Means
wird zur Optimierung der Cluster immer wieder die Distanz zwischen zwei Punk-
ten, also zwischen den räumlichen Zuständen, gebildet. Mit Hilfe des Kernel-Tricks
(Abschnitt 2.5) muss diese Distanz nun nicht mehr zwischen den Eingabeobjek-
ten, also den räumlichen Zuständen, gebildet werden, sondern kann aus der effizient
berechneten Ähnlichkeitsmatrix gebildet werden.
18 KAPITEL 2. SPATIAL-PYRAMID-ANSATZ
2.7 Andere Verfahren zur Ähnlichkeitsabschätzung
Neben dem Spatial-Pyramid-Ansatz und der SSE gibt es noch andere Verfahren, um
2D-Raster räumlicher Zustände miteinander zu vergleichen. Die meisten Methoden
stammen aus der Bildverarbeitung und werden in der Regel dazu benutzt, Muster
in Bildern zu erkennen oder Bilder zu klassifizieren. Diese Verfahren benutzen zum
Beispiel Farben, Formen oder Texturen, um Ähnlichkeiten zwischen Bildern zu fin-
den [24].
Eines dieser Verfahren ist zum Beispiel der Pyramid Match Kernel [16], bei dem
ein Histogramm über den gesamten räumlichen Zustand gebildet wird und diese
Histogramme in eine Pyramide unterteilt werden. Bei dem Pyramid Match Kernel
werden die Bins nicht als separate Kanäle betrachtet und so können ähnliche Bins
zusammengefasst werden.
Auf der untersten Ebene des Vergleiches werden auch bei dem Spatial-Pyramid-
Ansatz Histogramme verglichen, wobei jedes Histogramm-Bin als ein Feature be-
handelt wird. Für den Spatial-Pyramid-Ansatz werden die Histogramme mit Hil-
fe der Histogramm-Intersection verglichen. Es gibt zwei verschiedene Klassen von
Histogrammvergleichen [29]; die eine vergleicht Bin für Bin eines Histogramms, die
andere führt Vergleiche über Bin-Grenzen hinweg durch und versucht Korresponden-
zen zwischen den Bins zu finden. Zur ersten Klasse gehören die Minkowski-Distanz
oder die Jeffrey Divergenz [26]. Zur zweiten Klasse der Histogrammvergleichsmetho-
den gehört die Kolmogorov-Smirnov-Distanz [29]. Alle diese Methoden werden zur
Suche von Bildern und Mustern benutzt und könnten unter Umständen ebenso für
den Vergleich von räumlichen Zuständen benutzt werden.
Methodisch anders ist zum Beispiel die Earth-Movers-Distanz [28], die ein Distanz-
maß liefert, das beim Vergleich ermitteln soll, wie sich Eigenschaften eines Zustan-
des in einen anderen transformieren lassen. In der Regel auf Bilder angewandt, wird
hierfür der Raum in Cluster aufgeteilt und mit dem Cluster eines anderen Raumes
verglichen. Die zu errechnende Distanz drückt aus, wie „teuer“ es ist, ein Cluster
in das andere umzuwandeln. Dieses Problem wird angegangen, indem eine Form
des Transportproblems gelöst wird. Diese Methode eignet sich auch als metrische
2.7. ANDERE VERFAHREN ZUR ÄHNLICHKEITSABSCHÄTZUNG 19
Distanz zum Clustern von größeren Datenmengen [3]. Die Earth-Movers-Distanz
unterscheidet sich auch dadurch von dem Spatial-Pyramid-Ansatz, dass Ähnlichkei-
ten zwischen den Features gesucht werden. Dies ist vor allem von Bedeutung, wenn
die Features nicht per Quantisierung der Messwerte, wie in der vorliegenden Arbeit,
sondern auch mittels anderer Methoden gewonnen werden.
Kapitel 3
Verteilte Systeme
Bei der Berechnung der Ähnlichkeiten mittels des Spatial-Pyramid-Verfahrens führt
zu einer Reduzierung der einzelnen Vergleiche auf die räumliche Pyramide und den
Featureraum. Trotz der Reduktion der Vergleiche bleibt das Problem, dass zumin-
dest jeder paarweise Vergleich für sich steht und in einer sequentiellen Implemen-
tierung nacheinander ausgeführt wird. Daher ist es sinnvoll, eine Implementierung
des Spatial-Pyramid-Ansatzes als parallele Implementierung durchzuführen. Eine
solche parallele Implementierung soll die Berechnung der Ähnlichkeitsmatrix be-
schleunigen. Außerdem soll eine parallele Implementierung besser skalieren, so dass
der Einfluss größerer Datenmengen auf die Laufzeit minimiert werden kann. Für eine
parallele Implementierung müssen die parallelisierbaren Bestandteile des zu paralle-
lisierenden Verfahrens ermittelt werden und in ein entsprechendes System umgesetzt
werden. Man spricht hierbei von Dekomposition [27]. Ein Bestandteil lässt sich par-
allel ausführen, wenn er unabhängig von anderen Parametern als den Eingabepara-
metern ausgeführt werden kann. Unabhängig bedeutet, dass eine Ausführung nicht
erst zur Laufzeit andere Parameter verlangen kann, sondern alle für die Berechnung
notwendigen Parameter zur Verfügung hat. Für diese Datenparallelität können Tei-
le einer Datenmenge parallel verarbeitet werden. Für den Spatial-Pyramid-Ansatz
können verschiedene Bestandteile als unabhängig identifiziert werden, wie zum Bei-
spiel die Bildung der räumlichen Pyramide oder auch die einzelnen Vergleiche der
Histogramme und der Teilbereiche. Ersteres ist unabhängig, weil es nur auf einem
20
21
räumlichen Zustand operiert. Die paarweisen Vergleiche der räumlichen Pyrami-
de hängen nicht davon ab, welche Ergebnisse andere Vergleiche liefern. Diese sehr
einfache Granularität wird später noch weiter in einzelne Bestandteile verfeinert
(Abschnitt 4).
Neben der eben erwähnten Datenparallelität gibt es noch die Pipeline-Parallelität.
Diese Pipeline-Parallelität kann die verschiedenen Aufgaben einer Verarbeitungsket-
te aufteilen. Alle diese Aufgaben würden parallel zueinander laufen (Abbildung 3.1).
Die beiden Parallelitäten schließen einander nicht aus. Eine parallele Implementie-
rung kann beide Parallelitäten nutzen. Für den Spatial-Pyramid-Ansatz soll einer-
seits nach Trennlinien in der Verarbeitungskette gesucht werden, die ein System
zur parallelen Verteilung im Sinne der Pipeline-Parallelität nutzen kann. Anderer-
seits sollen auch Bereiche des Spatial-Pyramid Ansatzes gesucht werden, die sich
datenparallel ausführen lassen.
22 KAPITEL 3. VERTEILTE SYSTEME
Data1
Op1 Op2 Op3Data1Data2Data3
Op1 Op2 Op3
Data2 Op1 Op2 Op3
Data3 Op1 Op2 Op3
Datenparallele Ausführung
Pipeline-parallele Ausführung
Abbildung 3.1: Datenparallelität im Vergleich zur Pipeline-Parallelität: Eine Verarbeitungskette
mit 3 Operationen wird mit 3 Blöcken an Daten gestartet. Daten- und Pipeline-Parallelität verteilen
jeweils anders die entsprechenden Aufgaben auf die verschiedenen Prozessoren (gelb). Bei der
Pipeline-Parallelität kann der Block Daten2 mit der Op1 schon starten, wenn Op1 mit Daten1
fertig ist und Op2 die daraus resultierenden Daten weiterverarbeitet. Wenn jede Operation eine
Dauer von 1 hat, so dauert die komplette Verarbeitung für Datenparallelität 3 und bei der Pipeline-
Parallelität 5.
Zur Implementierung eines Algorithmus als parallele Implementierung nutzt man
ein Verteiltes System. Von einem Verteilten System spricht man, wenn mittels ei-
ner Abstraktionsebene mehrere Ressourcen aus einem Pool zusammengefasst und
einem Benutzer als Einheit sichtbar gemacht werden [34]. Mit der Verteilung der
Ressourcen und der daraus folgenden parallelen Verarbeitung können große Daten-
mengen verarbeitet werden, die sonst den Rahmen einer einzelnen Rechenressource
überschreiten würde. Ein Verteiltes System kann sich in vielfacher Art und Weise
präsentieren. In der Regel wird Rechenleistung verteilt und durch das darüberlie-
gende System verwaltet. Ressourcen sind zumeist Computer, die autonom, also von-
einander unabhängig, spezifische Teile ihrer eigenen Ressourcen wie zum Beispiel
3.1. MAP/REDUCE 23
Rechenleistung bereitstellen. Auf diese Ressourcen kann ein Nutzer, der sowohl ein
Mensch als auch ein Programm sein kann, zugreifen, ohne konkretes Wissen über die
Ressourcen zu haben. Für einen Nutzer reicht es aus, Wissen über eine Zwischen-
schicht, also über eine Konvention oder ein Programmiermodell, zu haben. Solch
eine Zwischenschicht ermöglicht dann den Zugriff auf die verteilten Ressourcen.
Ein Verteiltes System soll Ressourcen leicht verfügbar machen. Es soll einen trans-
parenten Zugriff ermöglichen, also verbergen, dass die Ressourcen verteilt vorliegen.
Transparenz kann sich in verschiedene Typen gliedern. So gibt es unter anderem die
Ortstransparenz, die verbirgt, wo eine Ressource gespeichert wird. Eine weitere Art
von Transparenz ist die Migrationstransparenz, die verbirgt, dass eine Ressource
verschoben wurde. Außerdem soll ein solches System Schnittstellen zum Zugriff auf
die Ressourcen anbieten, und das System sollte skalierbar sein, in dem leicht neue
Ressourcen dem Gesamtsystem hinzugefügt werden können und bei der Berechnung
angegeben werden kann, welchen Ressourcenbedarf eine Aufgabe hat.
3.1 Map/Reduce
Map/Reduce bezeichnet ein ursprünglich 2004 von Google vorgestelltes System und
Programmiermodell [9], um die Implementierung paralleler Berechnung zu verein-
fachen. Map/Reduce wurde von Google dazu benutzt, zum Beispiel den Suchindex
zu erstellen. Diese Berechnungen mussten auf einer großen Anzahl von Rechnern
laufen, und jede einzelne Aufgabe sollte unabhängig von anderen Aufgaben arbeiten
können. Da jede einzelne Aufgabe mit Fehlern umgehen musste und auch in einer
bestimmbaren Zeit beendet sein sollte, wurde Map/Reduce als Verteiltes System
entwickelt. So sollte es in der Lage sein, Aufgaben über mehrere Rechner zu vertei-
len und die Verwaltung der Aufgaben zu übernehmen.
Für die Implementierung des Spatial-Pyramid-Ansatzes soll ein auf Map/Reduce
basierendes System, genauer gesagt Stratosphere (Abschnitt 3.2), benutzt werden,
da sich die parallele Verarbeitung und Verteilung in einem solchen System schon
befindet. Es muss bei einem solchen System nur noch die Funktionalität implemen-
tiert werden. Konzepte, wie zum Beispiel der Datenaustausch zwischen den Knoten
24 KAPITEL 3. VERTEILTE SYSTEME
abläuft, sind in einem solchen System implementiert und brauchen nicht Teil der
Implementierung des Spatial-Pyramid-Ansatzes zu sein.
Ein Map/Reduce-System ist im ursprünglichen Sinne dazu konzipiert, verteilt auf
mehreren Rechnern zu laufen. Jeder Rechner soll dabei einen oder mehrere Threads
parallel ausführen können. Für jede Recheneinheit, die genau eine Aufgabe gleich-
zeitig ausführen kann, spricht man von einem Knoten. Ein Map/Reduce-System soll
eine an dieses gestellte Aufgabe über alle Knoten verteilen (Abbildung 3.2). Damit
ist Map/Reduce ein Verteiltes System mit einer zentralisierten Architektur. Eine
zentralisierte Architektur bedeutet, dass es einen Master gibt, der sich um die Ver-
teilung kümmert und mit dem der Benutzer kommuniziert. Dieser Master kümmert
sich um die Bearbeitung von Aufgaben und um die Koordination der Ressourcen.
Der Master kümmert sich um den Erhalt der Transparenzkriterien und gewährleistet
die Integrität des Gesamtsystems. Ein Schwachpunkt dieses zentralisierten Ansatzes
ist, dass es nur einen Zugriffspunkt von außen auf das System als Ganzes gibt. Wenn
dieser Zugriffspunkt ausfällt, steht auch das gesamte System nicht mehr zur Verfü-
gung. Auch kann der Master mit der Verteilung und Koordination so überlastet sein,
dass die Ressourcen nicht mehr effektiv genutzt werden können. Der zentralisierte
Ansatz ist trotzdem am verbreitetsten, da er insgesamt einfacher zu implementieren
ist.
Eine Aufgabe bekommt das Map/Reduce-System als Nutzerprogramm mit Anwei-
sungen von Operationen und einzelnen Nutzerfunktionen geliefert. Eine einzelne
Aufgabe darf keine Seiteneffekte haben, und alle notwendigen Parameter müssen
zum Start der Aufgabe vorliegen.
3.1. MAP/REDUCE 25
Datensatz 1
Datensatz 2
Datensatz 3
Datensatz 4
Datensatz 5
K1
K2
K3
Map
Datensatz 1 <Key1, Value>
Datensatz 4 <Key2, Value>
Datensatz 2 <Key1, Value>
Datensatz 5 <Key2, Value>
Datensatz 3 <Key3, Value>
Task 1
Task 2
Task 3
Reduce
K1
K2
K3
Task 1
Task 2
Task 3
Task 4
Task 5
Abbildung 3.2: Symbolische Darstellung der Verteilung von Map- und Reduce-Operationen: bei
der Map-Operation wird jeder Datensatz nacheinander an die freien Knoten (K1-K3) verteilt. Bei
Reduce-Operationen werden die Schlüssel gruppiert und diese Gruppen über die Knoten verteilt.
Das Map/Reduce-System muss eine Aufgabe entlang der einzelnen Operation tren-
nen und zusammen mit dem dazugehörigen Teil der Daten an die einzelnen Knoten
als Bearbeitungsschritt übergeben. Die Art der Verteilung obliegt dem Map/Reduce-
System und kann nicht explizit beeinflusst werden. Knotenfehler soll das Map/Red-
uce-System behandeln und entscheiden, wie nach einem Fehler weiter gemacht wer-
den soll. Zum Beispiel könnte die Aufgabe noch einmal gestartet werden, oder die
gesamte Berechnung abgebrochen werden. Die parallele Ausführung soll dabei die
Rechenleistung des Gesamtsystems besser ausnutzen, indem alle Ressourcen zur Be-
rechnung eines Gesamtergebnis benutzt werden. Die Teilaufgaben werden so nicht
hintereinander ausgeführt und die Laufzeit einer Gesamtaufgabe kann reduziert wer-
den.
Der Vorteil eines solchen Map/Reduce-Systems ist, dass es ein generalisiertes Pro-
grammiermodell gibt, welches es erlaubt, ohne Wissen über das Gesamtsystems eine
Aufgabe zu modellieren und die Berechnung auf diesem System zu starten.
3.1.1 Operationen in Map/Reduce
Die Grundidee in Map/Reduce ist es, dass innerhalb des Nutzercodes von der Par-
allelisierung nichts zu sehen ist. Dies bedeutet, dass der Nutzercode sich nur um die
eigentlich zu bearbeitende Aufgabe kümmert [9]. Für den Programmierer bedeutet
das, dass er sich nur um die Implementierung der Funktionalität kümmern muss,
26 KAPITEL 3. VERTEILTE SYSTEME
und durch das Programmiermodell sind die Reihenfolge und die Art der Bearbei-
tung der Daten durch das System bestimmt. Die Parallelisierung und Verteilung
übernimmt das darüberliegende System über Konventionen und kümmert sich um
Fehlerbehandlungen und Ausführungsoptimierungen. Somit wird die Komplexität
einer parallelen Implementierung verborgen.
In einem Map/Reduce-System werden nur Schlüssel-Wert-Paare benutzt, die in den
einzelnen Phasen verarbeitet und transportiert werden. Dies bedeutet, dass die Ein-
heit, die ein solches System kennt, aus einem Schlüssel- und einemWertefeld besteht.
Ein solches Datum bezeichnet man mit < K, V >, wobei K für den Schlüssel und
V für den dazugehörigen Wert steht.
Es gibt zwei verschiedene Grundoperationen in einen Map/Reduce-System, die auch
namensgebend für das System sind: Map und Reduce [9]. Zu jeder Funktion gibt
es spezifischen Nutzercode, der auf die zu der Operation gehörige Datenmenge ent-
sprechende Berechnungen oder Transformationen vornimmt.
Map-Operationen bilden neue Schlüssel-Wert-Paare. Dazu werden die vorliegenden
Daten gelesen, und die Nutzerfunktion wird für jedes Dokument einmal aufgerufen.
Diese Nutzerfunktion kann nun entsprechend ihrer Aufgabe das Dokument verarbei-
ten und beliebig viele Schlüssel-Wert-Paare zurückgeben, die zur Weiterverarbeitung
geeignet sind.
In einer Reduce-Operation fasst das System alle Schlüssel-Wert-Paare mit demsel-
ben Schlüssel zusammen und gibt diese Gruppe als Eingabe an eine Nutzerfunktion.
Dies bedeutet, dass die Nutzerfunktion alle Werte mit dem selben Schlüssel verar-
beitet. Eine Nutzerfunktion einer Reduce-Operation kann beliebig viele Schlüssel-
Wert-Paare zurückgeben. Jeder Aufruf einer solchen Nutzerfunktion erfolgt verteilt,
entsprechend der Konfiguration des Gesamtsystems. Es wird dazu ein < K, V > auf
einen Knoten übergeben und dort ein Ergebnis generiert. Wenn die Aufgabe fertig
ist, ist der Knoten frei für die nächste Aufgabe. Auch das Berechnen von Gruppen
innerhalb der Reduce-Operation kann verteilt erfolgen.
In einer Implementierung des Spatial-Pyramid-Ansatzes werden diese beiden Ope-
rationen zum Beispiel benutzt werden, um die räumliche Pyramide zu bilden. Mit
einer Map-Operation werden die Teilbereichskoordinaten der räumlichen Zustände
3.1. MAP/REDUCE 27
für alle Level gebildet. Mit diesen Teilbereichskoordinaten als Schlüssel zählt eine
Reduce-Operation alle Feature in einem Teilbereich. Am Ende steht so nach der
Reduce-Operation jeweils ein Datensatz mit einer Teilbereichskoordinate und dem
Featurehistogramm (Abschnitt 4.3).
Beispiel - Map/Reduce: Die Funktionalität von Map/Reduce soll an die-
ser Stelle anhand eines Beispiel demonstriert werden. Dieses soll sowohl die
grundlegende Funktionsweise des Systems veranschaulichen als auch zei-
gen, wie sich bestimmte Problemstellungen lösen lassen. Als Beispiel soll
eine Menge unstrukturierter Daten dienen, die Temperaturmessungen ent-
halten Tabelle 3.1. Das Ziel ist die Berechnung Jahresdurchschnittswerte
der gemessenen Daten zu ermitteln.
19800305 -008
19810406 +005
19801005 +011
19800810 +025
19810727 +021
Tabelle 3.1: Beispielinhalt für das Map/Reduce-Beispiel: In jeder Zeile des Dokuments steht das
Datum der Messung dargestellt als Jahr (4-stellig), Monat, Tag. Nach einem Leerzeichen erscheint
die gemessene Temperatur des Tages mit Vorzeichen als Ganzzahl.
Das Map/Reduce-System liest nun als erstes die Datei. In dem Beispiel soll
dies zeilenweise geschehen, so dass die je eine Zeile an eine Map-Operation
gegeben wird. Jede Map-Operation wird dabei auf einem freien Knoten aus-
geführt, der gerade nicht in Benutzung ist. Die Map-Operation trennt die
Zeilen auf und liest die Jahreszahl aus den ersten 4 Zeichen und die Tem-
peratur aus den letzten 4 Zeichen heraus. Als Rückgabe wird das Schlüssel-
Wert-Paar aus dem Jahr als Schlüssel und der Temperatur als Wert gebildet.
Das Zwischenergebnis hat die folgende Form:
28 KAPITEL 3. VERTEILTE SYSTEME
<1980, -8>, <1981, 5>, <1980, 11>, <1980, 25>, <1981, 21>,
Für die nun folgende Reduce-Operation bildet das Map/Reduce-System nun
einen globalen Index über alle Schlüssel. Jeder Wert wird einem Schlüssel
zugeordnet, dabei entstehen folgende Gruppen über die Jahreszahl:
<1980, [-8, 11, 25]>, <1981, [5, 21]>
Jede Gruppe wird separat an den Nutzercode der Reduce-Funktion über-
geben, die aus den Werten den Durchschnitt ermittelt und die Schlüssel-
Wert-Paare mit dem Jahr als Schlüssel und der Durchschnittstemperatur
als Wert erstellt.
<1980, 9.33>
<1981, 13>
Das Gesamtergebnis des Programms wären also die beiden obenstehenden
Datensätze.
3.1.2 Implementierungen von Map/Reduce
Seitdem Map/Reduce 2004 von Google als Framework [9] zur Bearbeitung paralle-
lisierbarer Abfragen vorgestellt wurde, gab es eine Anzahl von Implementierungen,
die entweder das Map/Reduce-Modell direkt umsetzten, oder dieses erweiterten, an-
passten oder benutzten.
Eine der bekanntesten Map/Reduce Implementierungen ist Hadoop [14], welches in-
nerhalb der Apache Software Foundation als Open-Source-Software gewartet wird.
Ein Beispiel für die Benutzung von Map/Reduce ist Facebook, welches die anfallen-
den Nutzerdaten in einem Map/Reduce-Cluster basierend auf Hadoop für Abfragen
zur Verfügung stellt. Facebook verwaltet so Daten von mehr als 100 PB [11], welches
pro Tag um mehr als einen halben Petabyte wächst [12].
3.2 Stratosphere
Stratosphere [6] ist ein auf Map/Reduce basierendes Verteiltes System, das eine
Weiterentwicklung des Map-Reduce-Ansatzes bietet. Stratosphere besteht aus ver-
3.2. STRATOSPHERE 29
schiedenen Bestandteilen: der Ausführungsschicht Nephele, dem PACT Program-
miermodell, und der Abfragesprache Meteor. Stratosphere wird an der Humboldt-
Universität zu Berlin, der Technischen Universität Berlin und dem Hasso-Plattner-
Institut in Potsdam entwickelt.
Stratosphere wurde vollständig in Java entwickelt, und liegt zum Zeitpunkt des
Schreibens dieser Arbeit in der offiziell veröffentlichten Version 0.2 (Release:
17.08.2012) vor. Der Abarbeitungsplan, also das Programm, welches an Stratosphere
übermittelt wird, sowie alle benutzten Funktionen müssen ebenfalls in Java vorlie-
gen. Stratosphere ist derzeit nur lauffähig auf linux-basierten Betriebssystemen und
nur mittels Oracle JRE (Java Runtime Environment) [25].
Stratosphere soll dabei gegenüber anderen Map/Reduce-Systemen mit PACT für
Entwickler einen einfacheren Programmieransatz bieten. Dieser einfachere Ansatz
soll eine modularere und flexiblere Entwicklung ermöglichen, wodurch das Vermi-
schen von Funktionalitäten im Nutzercode vermieden werden kann. Stratosphere
soll außerdem die Ausführung von Aufgaben beschleunigen, was gegenüber anderen
Map/Reduce-Systemen einen wesentlichen Vorteil darstellt [5].
3.2.1 Architektur von Stratosphere
In einem laufenden Stratosphere-System sind zwei Komponenten sichtbar (Abbil-
dung 3.3), die für die Funktionalität von Stratosphere verantwortlich sind. Diese
beiden Komponenten sind der Jobmanager (JM) und die Taskmanager (TM). Der
Jobmanager hat die Aufgabe, Teilaufgaben und die verschiedenen Instanzen der
Taskmanager zu steuern. Eine Instanz ist ein Rechner, der seine Rechenkapazität
zur Verfügung stellt. Dazu muss der Jobmanager erfassen, welche Instanzen im Sys-
tem vorhanden sind und welche Ausstattung sie haben. Außerdem benötigt er, um
richtig zu funktionieren, auch Informationen über die aktuelle Aktivität der Instan-
zen. Die auf jeder Instanz laufenden Taskmanager verwalten einen Rechner und
stellen die Schnittstelle zwischen der Rechnerressource und dem Jobmanager her.
Neben dem aktuellen Status der Bearbeitung stellen die Taskmanager auch Infor-
mationen über den Rechner bereit, wie Anzahl der Kerne, Anzahl der Prozessoren
30 KAPITEL 3. VERTEILTE SYSTEME
und verfügbarer Speicher. Die Datenquelle muss für alle Taskmanager unter dem
gleichen Namen beziehungsweise über die gleiche Referenz erreichbar sein.
Client
TMJM
TM
TM
Stratosphere
Abbildung 3.3: Strukturierte Übersicht über Komponenten in Stratosphere. Ein Client startet über-
gibt einen Job an den Jobmanager (JM). Der Jobmanager verteilt die Aufgabe an die verschiedenen
Taskmanager (TM) im System.
Stratosphere ermöglicht es, heterogene Knoten in ein Rechencluster einzubeziehen,
so dass der Jobmanager von Stratosphere bei der Verteilung der Aufgaben die Pa-
rameter der einzelnen heterogenen Bereiche mit in Betracht ziehen kann. Die Task-
manager können also auf verschiedenen Knoten liegen und teilen dem Jobmanager
ihre Konfiguration mit. Die ermittelten konfigurierten Eigenschaften können in die
Verteilung der parallelen Aufgaben einfließen.
Zum Starten eines Stratosphere-Programms benötigt man einen Abarbeitungsplan,
der mittels Usercode über ein Client-Programm an den Jobmanager übermittelt
wird. Ein Abarbeitungsplan ist eine Sammlung von PACT-Operationen, die mit-
einander verbunden werden. Eine Verbindung zwischen zwei Operationen wird her-
gestellt, indem die Ausgabe einer Operation einer nächsten Operation als Eingabe
dient. Dabei muss die Verbindung zwischen Eingabe und Ausgabe keine 1:1 Bezie-
hung sein, sondern eine Ausgabe kann mehreren Operationen als Eingabe dienen.
Ebenso ist es möglich, dass eine Operation mehrere Eingaben zusammenfasst, wo-
bei die Daten der entsprechenden Eingaben über spezifische Funktionen miteinan-
3.2. STRATOSPHERE 31
der gemischt werden [5]. Durch dedizierte Eingabe- und Ausgabe-Operationen kann
Stratosphere den Anfang und das Ende des Plans detektieren (Abbildung 3.4). Der
Ausführungsplan ist ein gerichteter azyklischer Graph, der mit dem Einlesen der
Daten beginnt.
Abbildung 3.4: Einfacher Plan eines beliebigen PACT-Programms, das aus mehreren verschiede-
nen Operationen besteht. Auf der linken Seite sind zwei verschiedene Eingabequellen, die in einer
Operation zusammengefasst und dann weiterverarbeitet werden. Auf der rechten Seite ist die Aus-
gabeoperation zu sehen (Screenshot aus dem PACT-WebClient).
Darauf folgt die eigentliche Verarbeitung der Daten. Eine Ausgabeoperation am
Ende des Plans beendet die Verarbeitungskette und somit auch das Stratosphere-
Programm.
3.2.2 Das PACT-Programmiermodell in Stratosphere
Für die Umsetzung des Spatial-Pyramid-Ansatz wurde Stratosphere gewählt, weil
mit dem PACT ein Programmiermodell zur Verfügung steht, welches eine modu-
lare Entwicklung erlaubt. Es lassen sich mit PACT Tupel erstellen, in denen de-
taillierter als mit den Schlüssel-Wert-Paaren aus Map/Reduce Daten verwaltet und
transportiert werden können. Zusätzliche Operationen, die es erlauben verschiedene
Datenquellen zu verknüpfen, waren auch ausschlaggebend für die Entscheidung für
Stratosphere, auch wenn diese am Ende kaum benutzt wurden. Durch die Tupelbil-
dung und das flexible Angeben der Schlüsselparameter für eine Operation konnten
verschiedene Ansätze immer ausprobiert werden ohne vorherige Operationen für die
Tupelerstellung selbst anzupassen, da nur die Ausgabe der Operation in eine neue
Operation zum Testen umgeleitet wurde, und neue Schlüsselfelder angegeben wur-
den. Der modulare Aufbau des Planes erlaubte es so bestehende Funktionen einfach
32 KAPITEL 3. VERTEILTE SYSTEME
wiederzuverwenden.
Das in Stratosphere eingesetzte Programmiermodell heißt PACT und der Begriff
steht für Parallelization Contracts. Das PACT-Programmiermodell erweitert die
Funktionalität des herkömmlichen Map/Reduce-Modells, indem es nicht Schlüssel-
Wert-Paare sondern Tupel zum Transport von Informationen benutzt. Außerdem er-
weitert Stratosphere die Menge an zur Verfügung stehenden Operationen um einige
Funktionen zweiter Ordnung. Eine Funktionen zweiter Ordnung nimmt als Eingabe
neben anderen Parameteren auch eine Funktion an. In dem vorliegenden Fall wird
einer Operation neben den Daten auch die Nutzerfunktion übergeben, die ausgeführt
wird, wenn die Daten entsprechend einer Konvention vorverarbeitet oder organisiert
wurden.
Bei anderen Map/Reduce-Systemen ist das Anwendungsmodell sehr eng mit Aus-
führungsmodell verknüpft3. Bei Stratosphere können beliebige Operationen hinter-
einander in beliebiger Reihenfolge verbunden werden. So entsteht die Möglichkeit
entsprechend des Anwendungsfalls die Operationen zu benutzen. Erst später wird
der PACT-Plan in einen Ausführungsplan umgesetzt. Die Trennung des Program-
miermodells von der Ausführungsstrategie bietet so die Möglichkeit, komplexere
Pläne zusammenzustellen [1] als bei anderen Map/Reduce-System.
Tupel sind eine Sammlung von Werten, die keinem Schema unterliegen. Wenn die
Tupel keinem Schema unterliegen heißt das, dass die Werte beliebig angeordnet
werden können. Die in Stratosphere benutzten Tupel sind Datensätze, die untypi-
siert und schemalos transportiert werden und eine beliebige Länge haben können.
Dadurch, dass diese Tupel eine beliebige Länge haben können und schemalos sind,
ist die Dualität von Schlüsseln und Werten, die in anderen Map/Reduce Systemen
vorliegt, aufgehoben. Damit für Funktionen anzugeben, die Schlüssel benötigen, ein
ebensolcher zugewiesen werden kann, können eine beliebige Anzahl von Feldern in-
nerhalb des Tupels als Schlüsselfelder angegeben werden. Aus diesen Feldern kann
Stratosphere dann die notwendige Schlüsselinformation bilden, um zum Beispiel
Gruppen von Werten zu einem Schlüssel aufzufinden. Eine Transformation von Wer-
3Bei anderen Map/Reduce-Systemen ist das Programmiermodell identisch mit dem Ausführungsmodell, das
heißt, es wird genau eine Map-Operation ausgeführt, und darauf folgt eine Reduce-Operation.
3.2. STRATOSPHERE 33
ten zu synthetischen Schlüsseln ist somit nicht notwendig. Stratosphere übernimmt
die Aufgabe, Werte aus den angegebenen Schlüsselfeldern für einen Vergleich sinn-
voll zu benutzen. Für die Bildung eines Tupels stehen in Stratosphere verschiedene
Grundtypen wie String, Integer, Double oder Long zur Verfügung. Außerdem ste-
hen die komplexen Typen List und Map zur Verfügung, mit denen Felder gebildet
werden können.
Stratosphere erweitert das von herkömmlichen Map/Reduce-Systemen bekannte Pro-
grammiermodell von Map und Reduce um weitere Operationen wie Match, CoGroup
und Cross [1]. Diese neuen Operationen sind, im Gegensatz zu den unären Opera-
tionen Map und Reduce, binäre Operationen. Die Funktionalität der Operationen
Map und Reduce ist identisch mit der Funktionalität in anderen Systemen.
Bei einer Match-Operation werden zwei Datenquellen so behandelt, dass anhand
der Schlüsselinformation für alle Tupel je Datenquelle Paare gebildet werden, wenn
die Schlüssel beider Tupel übereinstimmen. Diese übereinstimmenden Tupel werden
dann an die Nutzerfunktion weitergereicht. Ein Match-Operator behandelt also die
Verkettung zweier Datenmengen bei Gleichheit der Schlüssel.
Die Operationen Cross und CoGroup werden innerhalb dieser Arbeit nicht benutzt.
Weiter Informationen zu diesen sind in [5] zu finden.
Diese zusätzlichen Operationen haben den Vorteil, dass Stratosphere als System un-
terschiedliche Operationen anbietet, um verschiedene Datenquellen miteinander zu
konnektieren, ohne diese vorher die Daten vorher zu transformieren, damit sie zum
Beispiel einem festen Schema entsprechen. Nutzercode, der versucht die Funktionali-
tät dieser neuen Operationen zu nachzubilden, muss dadurch nicht mehr geschrieben
werden4. Dadurch kann der Nutzercode entschlackt werden, da er keine Aufgaben
ausführen muss, die für die eigentlich zu erreichende Funktion nicht zwingend not-
wendig sind. Stattdessen kann dafür das Ausführungssystem benutzt werden [2],
das dann zum Beispiel Daten so miteinander verknüpfen kann, dass neue Paare
entstehen, die wiederum verteilt werden können. Außerdem kann Stratosphere die
optimale Art für jede Operation anwenden und verteilen, und von optimierten Pro-
4Als Beispiel wie ein Join aussehen könnte, welches nur unter Zuhilfenahme der Map- und Reduce-Operationen
umgesetzt wird, dient [35].
34 KAPITEL 3. VERTEILTE SYSTEME
zessen im Hintergrund profitieren. Außerdem bietet Stratosphere die Möglichkeit,
mehr als eine Datenquelle zu benutzen. Diese Datenquellen können mit den binären
Funktionen zweiter Ordnung zusammengefasst und weiterverarbeitet werden.
Die Verteilung der zu verarbeitenden Daten wird über Schlüssel geregelt. Ein Schlüs-
sel wird aus einem oder mehreren Feldern eines Tupels gebildet, die bei der Erstel-
lung der Operation angegeben wurden. Ein Schlüssel wird, wenn zur Ausführung
einer Operation notwendig, benutzt, um Tupel miteinander zu vergleichen und Paa-
re zu bilden oder um Tupel mit gleichen Schlüsseln einer Gruppe zuzuordnen. Sind
entsprechende Paare oder Gruppen gefunden, wird die Nutzerfunktion auf diese an-
gewandt.
3.2.3 Die Ausführungsschicht Nephele
Der PACT-Compiler übersetzt den PACT-Plan in einen JobGraph. Aus diesem
JobGraph erstellt die Ausführungsschicht Nephele einen Ausführungsplan. Ein Aus-
führungsplan ist ein gerichteter azyklischer Graph (Abbildung 3.4), bei dem die
Knoten die Subtasks sind und die Kanten Kommunikationskanäle darstellen. Jeder
Knoten kann dabei mehrere Ein- und Ausgabekanäle haben, um das Zusammenfüh-
ren verschiedenster Datenströme zu ermöglichen. Während der Ausführung küm-
mert sich Nephele um den Zugriff auf Ressourcen und die Verteilung der Subtasks.
Außerdem ist Nephele dafür verantwortlich, wie mit Ausfällen von Knoten umge-
gangen wird [36].
Nephele kann außerdem, wenn in einen bestimmten Modus versetzt und konfiguriert,
dynamisch Ressourcen von Clouddiensten wie AmazonEC2 anfordern und diese in
die Ausführung einbinden [5].
Kapitel 4
Umsetzung des
Spatial-Pyramid-Ansatzes in
Stratosphere
Die parallele Umsetzung des Spatial-Pyramid-Ansatzes in Stratosphere, soll die ver-
teilte Berechnung für besonders große Datenmengen die Berechnung einer Ähnlich-
keitsmatrix beschleunigen. Eine parallele Implementierung in Stratosphere hat den
Vorteil, dass eine Berechnung der Ähnlichkeitswerte gut skalieren kann, und große
Eingabemengen effizient und schnell berechnet werden können. Die Skalierung kann,
je nach Anforderung und Größe der Eingangsdaten, so gewählt werden, dass in ver-
tretbarer Zeit die Ähnlichkeitsmatrix als Ergebnis liefert.
Eine Schwierigkeit bei der Implementierung ist, dass gewisse Vorkenntnisse über die
Daten notwendig sind, ohne die eine Berechnung der Ähnlichkeiten nicht möglich
ist. Diese müssen einmalig vor dem Start der Implementierung ermittelt werden. Zu
diesen Vorkenntnissen gehört unter anderem die Dimensionen der räumlichen Zu-
stände, da für das Erstellen der räumliche Pyramide der räumliche Zustand immer
wieder in der Mitte geteilt werden muss. Ebenso ist es notwendig, vorher das glo-
bale Minimum und Maximum über alle räumlichen Zustände vorher zu ermitteln,
um später eine Unterteilung dieses Wertebereichs in Featureintervalle vorzunehmen.
Diese Werte können während der Laufzeit der Spatial-Pyramid-Implementierung
35
36 KAPITEL 4. UMSETZUNG DES SPATIAL-PYRAMID-ANSATZES IN STRATOSPHERE
nicht gewonnen werden, da dafür zuerst Kenntnis über alle Daten erlangt werden
müsste, bevor man die einzelnen Daten weiterverarbeitet.
Bei der parallelen Datenverarbeitung ist es wichtig, alle Teilaufgaben so zu gliedern
beziehungsweise zu implementieren, dass diese keine Seiteneffekte haben. Auch darf
eine Teilaufgabe nicht von anderen Informationen abhängen, die nicht zum Start der
Aufgabe bekannt waren. Dies resultiert daraus, dass es keinen garantierten Ausfüh-
rungszeitpunkt einer Aufgabe gibt und auch der Ort, also die Maschine der Ausfüh-
rung nicht bekannt ist. Es kann grundsätzlich ebenso passieren, dass die Bearbeitung
einer Teilaufgabe auch von dem darüberliegenden System, also in diesem Falle von
Stratosphere gestoppt und auf einer anderen Maschine wieder gestartet wird. Daher
müssen alle für die Bearbeitung notwendigen Informationen zuvor ermittelt und als
Metainformation den entsprechenden Operationen übergeben werden.
Stratosphere kann außerdem die Instanz einer Klasse zur Bearbeitung einer Operati-
on wiederverwenden, weshalb keine Zwischenzustände in der Klasse erhalten bleiben
dürfen, die die eigentliche Bearbeitung beeinflussen können. Unter solchen Umstän-
den ist es wichtig, dass die Bearbeitung frei von Seiteneffekten ist. Daher findet in
den Operationen innerhalb der Nutzerfunktion keine Speicherung oder Wiederver-
wendung von Werten statt. Jede Operation muss unabhängig sein, darf also nicht
von anderen parallel laufenden Tasks abhängen.
Bei der Implementierung in Stratosphere galt es zusätzlich zu beachten, dass keine
Zwischenergebnisse gespeichert werden können. Dies ist keine spezifische Eigenschaft
von Stratosphere, sondern ist bedingt durch die Architektur. Eine an Stratosphere
übergebene Aufgabe wird bearbeitet und hat genau ein Ergebnis. Die Implemen-
tierung muss daher so aufgebaut sein, dass alle Parameter zum Anfang festgelegt
werden. Während der Bearbeitung müssen alle Informationen, die für spätere Ope-
rationen benötigt werden, in die Datensätze geschrieben und transportiert werden.
Mit den Features und der räumlichen Pyramide kann eine große Menge an Daten-
sätzen entstehen, die bei der Bearbeitung von Stratosphere verwaltet werden muss.
Daher wurde bei der Implementierung des Spatial-Pyramid-Ansatzes darauf geach-
tet, dass die Datensätze möglichst kompakt und nicht zu detailliert sind. Zu viele
einzelne Details können schnell zu einer sehr großen Datenmenge führen, wenn für
4.1. VORVERARBEITUNG 37
jedes Detail ein Datensatz erzeugt wird. Daher wurden im vorliegenden Fall die
Daten auf kompakte Datenstrukturen umgelegt. So wurden Daten, die ein Feature
in einem Teilbereich in einem Level darstellen zu kompakteren Featuresignaturen
zusammengefasst. Operationen, die auf der gesamten Datenmenge arbeiten müssen,
können so schneller vonstatten gehen, da eine reduzierte Menge an Datensätzen
vorliegt. Beim Erstellen dieser Featuresignaturen wird die gesamte Datenmenge um
den Faktor F reduziert. Stratosphere profitiert in der Weise, dass es nicht zu kleine
Informationsschnipsel transportieren und verwalten muss, bei denen der Overhead
größer wäre als der Nutzen der Verteilung.
4.1 Vorverarbeitung
Um die Daten der Simulation zu verarbeiten, mussten diese vorher in einem Schritt
vorverarbeitet und die Zeilen der jeweiligen Quelldateien um Zeilennummern ergänzt
werden5. Stratosphere liest alle Dateien blockweise ein und liefert keine Kontextin-
formationen wie Zeilennummern. Konkret bedeutet das, dass eine Nutzerfunktion in
Stratosphere zum Beispiel nur eine Zeile aus einer Datei als Eingabe bekommt, ohne
Information darüber, an welcher Stelle in der Datei sich diese Zeile befindet. Da jede
Operation unabhängig sein muss, kann innerhalb einer Operation nicht über die Zei-
len Buch geführt werden. Ebenso kann durch die parallele Ausführung, nicht davon
ausgegangen werde, dass das Einlesen einer Datei auf nur einem Knoten geschieht.
Aus diesen Gründen wird von der Implementierung erwartet, dass die Eingabedaten
die Zeilennummern am Anfang jeder Zeile enthalten. So kann mit einer Operation
aus den Zeilendaten die Zeilenposition ausgelesen werden.
4.2 Featuregenerierung
In einem weiteren Vorverarbeitungsschritt wird der maximale und minimale Wert
über alle räumlichen Zustände ermittelt. Diese beiden Werte sind als Eingabepara-
meter notwendig, um die Wertebereiche der Features festzulegen. Mit der Angabe5In der vorliegenden Implementierung wird jede eingelesene Datei als ein räumlicher Zustand behandelt.
38 KAPITEL 4. UMSETZUNG DES SPATIAL-PYRAMID-ANSATZES IN STRATOSPHERE
der gewünschten Anzahl der Features kann dieser Bereich zwischen dem Minumum
und dem Maximum gleichmäßig aufgeteilt werden (Abbildung 4.1). Durch die Er-
mittlung des Minimums und des Maximums vor der eigentlichen Verarbeitung wird
außerdem gewährleistet, dass alle Features in demselben Intervall liegen, da der ge-
samte Wertebereich über das globale Minimum und Maximum gebildet wird.
Wertebereich
Featureraum
min max
1 2 3 F
Abbildung 4.1: Aufteilung der Features: Der gesamte Wertebereich wird in gleich große Teile un-
terteilt. Jedes Feature-Intervall wird nummeriert 1,2,3, ... ,F.
4.3 Implementierung des Spatial-Pyramid-Ansatzes
Die Implementierung des PACT-Programms besteht aus zwei logischen Schritten.
Als erstes wird die Pyramide für jeden räumlichen Zustand berechnet. Dazu wer-
den alle Teilbereiche ermittelt und alle zu den Teilbereichen gehörigen Histogramme
gebildet. Als zweites erfolgt das Berechnen der Ähnlichkeitsmatrix, indem die par-
weisen Vergleiche aller räumlichen Zustände durchgeführt werden. Als Parameter
hat das implementierte PACT-Programm folgende Werte bekommen: die Anzahl
der Level, die Anzahl der gewünschten Features sowie als Metainformation die vor-
her ermittelten Werte des globalen Maximums und Minimums über alle Werte.
4.3.1 Featureermittlung und Erstellung der Featuresignaturen
INPUTZeilen der
Dateien einlesen
MAPAuslesen der Zeilennummern
MAPAuslesen der Werte
MAPErmitteln der Features
Abbildung 4.2: PACT-Schema (1.Teil) zur Implementierung des Spatial-Pyramid-Ansatzes - Ein-
lesen der Daten.
4.3. IMPLEMENTIERUNG DES SPATIAL-PYRAMID-ANSATZES 39
Im ersten Schritt (Abbildung 4.2) erhält man beim Einlesen der Daten einen Daten-
satz der Form 〈id, line〉, wobei id für den Namen oder einen eindeutigen Bezeichner
der Datei steht. In line steht der gesamte Inhalt der eingelesenen Zeile.
Danach wird, mittels einer Map-Operation, aus der Zeile die Zeilennummer y aus-
gelesen, so dass der nun folgende Datensatz die Form 〈id, y, content〉 hat.In einem weiteren Schritt werden nun die Punkte der räumlichen Zustände ermittelt,
indem der Inhalt der Zeile content unter Zuhilfenahme eines Trennzeichens aufge-
teilt und die entsprechende Position jedes Messwertes v in content gespeichert wird.
Daraus resultiert der Datensatz 〈id, x, y, v〉, wobei hier x für den Spaltenindex des
Messwertes v in der Zeile y steht. Nun hat man für jeden Punkt des räumlichen
Zustands einen Datensatz.
Im nun folgenden Schritt wird für jeden Messwert v das Histogramm-Bin f ermittelt,
und der Datensatz besteht nun aus 〈id, x, y, f〉. Ein Feature f liegt vor, wenn der
Wert v in dem f -ten Intervall liegt, das sich bei Teilung des Gesamtwertebereiches
in F gleich große Intervalle bildet.
Beispiel - Implementierung Spatial-Pyramid-Ansatz: Zur Beschrei-
bung und besseren Nachvollziehbarkeit soll im weiteren Verlauf parallel zur
Erläuterung der Implementierung ein Beispiel durchgearbeitet werden. Ge-
geben sei hierzu eine Datei ’file1.asc’ mit den Dimensionen von 4× 4 Punk-
ten, deren Werte, ohne Einschränkung der Allgemeinheit, nur ganze Zahlen
enthalten (Tabelle B.1). Als Featurebereich wird hier der Bereich zwischen
1 und 4 angenommen, der gleichmäßig auf 4 Features aufgeteilt wird. Für
das Beispiel ist also der Wert v identisch mit dem Feature.
Zuerst stehen in jeder Zeile der Beispieldatei die Zeilennummern, die von
einem Vorverarbeitungsschritt hinzugefügt wurden, gefolgt von den Werten
des entsprechenden räumlichen Zustands. In der Datei selbst liegen die Da-
ten ohne weitere Metainformationen vor.
Nach dem ersten Schritt des Einlesens liegen für unser Beispiel nun die Da-
tensätze derart vor, dass in jedem Datensatz mit id der Dateiname und mit
40 KAPITEL 4. UMSETZUNG DES SPATIAL-PYRAMID-ANSATZES IN STRATOSPHERE
line der Inhalt der Zeile beschrieben wird. Für die erste Zeile sieht der Da-
tensatz folgendermassen aus: 〈„file1.asc“; „0 1 3 4 2“〉Die Daten werden also zuerst einfach nur eingelesen und zusammen mit dem
zugehörigen Dateinamen als id an die nächste Operation weitergereicht. Im
nächsten Schritt werden nun die Zeilennummern aus den Zeilen ausgele-
sen. Der Datensatz der ersten Zeile würde nun folgenden Inhalt haben:
〈„file1.asc“; 0; „1 3 4 2“〉. Nun erfolgt die Auftrennung der einzelnen Punkte
jeder einzelnen Zeile, was zu einer Vergrößerung das Datenvolumens führt,
da nun jeder Punkt als ein Datensatz behandelt wird. In dem vorliegenden
Fall erhalten wir insgesamt 16 Datensätze für 4× 4 Punkte.
Feature Featureintervall
1 [1,00; 1,75]
2 (1,75; 2,50]
3 (2,50; 3,25]
4 (3,25; 4,00]
Tabelle 4.1: Featureintervalle für Beispiel
Für den Wertebereich 1−4 wird der Wertebereich in 4 gleich große Feature-
intervalle geteilt (Tabelle 4.1). Bei dem Schritt der Ermittlung der Features
ändert sich für den vorliegenden Fall nichts an den Datensätzen, da jeder
Wert auf ein gleichnamiges Feature gemappt wird und so für die vorliegen-
den Daten bei dieser Konfiguration v = f gilt.
REDUCEZählen der Features
je Subgridvektor
REDUCEErstellen der
Feature-Signaturen
MAPKalkulation der
Subgridvektoren
Abbildung 4.3: PACT-Schema (2.Teil) zur Implementierung des Spatial-Pyramid-Ansatzes - Er-
stellen der Features und der Featuresignaturen.
Im nächsten Schritt (Abbildung 4.3) werden die Teilbereiche für die verschiedenen
4.3. IMPLEMENTIERUNG DES SPATIAL-PYRAMID-ANSATZES 41
Auflösungen, auch Level genannt, gebildet. Dafür wird zuerst mittels einer Map-
Operation für alle Punkte die Position des Teilbereiches ermittelt. Im Gegensatz zu
einer sequentiellen Implementierung muss hier an dieser Stelle etwas anders vorge-
gangen werde. Bei einer sequentiellen Implementierung würde man zuerst die Teil-
bereiche in der Auflösung des höchsten Levels erstellen und in diesem Teilbereich
die notwendigen Histogramme bilden. Da ein Quad-Tree vorliegt, kann man die Hi-
stogramme der jeweils vier benachbarten Teilbereiche zusammen addieren, die das
Histogramm des Teilbereichs des nächstniedrigeren Levels bilden. Histogramme wer-
den addiert, indem die einzelnen die Summe der einzelnen Bins gebildet werden.
In der vorliegenden Implementierung wird etwas anders verfahren als bei einer mög-
lichen sequentiellen Implementierung, wie sie oben beschrieben wurde. Zuerst wird
für einen einzelnen Punkt für jedes Level die Koordinate des entsprechenden Teil-
bereichs ermittelt. Erst dann werden im darauf folgenden Schritt die Histogramme
je Teilbereich erzeugt.
Zur Ermittlung des gesuchten Teilbereichs je Punkt wird in Abhängigkeit von den
Koordinaten des Punktes die Funktion angewandt:
p(i,max, l) = bmin(2l, (i/(max/2l)))c
Die Funktion p gibt, angewandt mit dem Wert x oder y und der entsprechenden Sei-
tenlänge max, die Teilkoordinaten iX oder iY zurück. p berechnet also die Position
der Achse des Teilbereichs in seiner zweidimensionalen Lage im Level l. Mit max/2l
wird die Seitenlänge des Teilbereichs in Punkten ermittelt. Wird die aktuelle Sei-
tenlänge der Dimension durch die Seitenlänge pro Teilbereich geteilt, erhält man die
Teilbereichskoordinate des jeweiligen Indexes il. Mit der floor Funktion wird das
Ergebnis abgerundet und so das ganzzahlige Resultat ermittelt. Diese Berechnung
nutzt die maximale Ausdehnung der räumlichen Zustände mit maxx und maxy, um
die Seitenlänge eines Teilbereiches zu ermitteln.
Zuerst wird also für das feinste Level L der Datenbereich gebildet, so dass ein Da-
tensatz die Form 〈id, iX , iY , l, f〉 hat. Für alle anderen Level ermittelt die Map-
Operation ebenfalls in diesem Schritt die Datensätze mit den Teilbereichspositionen,
indem es ganzzahlig die vorherigen Teilbereichspositionen durch 2 teilt. Da wir es
42 KAPITEL 4. UMSETZUNG DES SPATIAL-PYRAMID-ANSATZES IN STRATOSPHERE
hier mit einem Quad-Tree zu tun haben, ergibt dies die Position des höherliegenden
Teilbereichs. Nach dieser Map-Operation hat sich die zu verwaltende Datenmenge
ver-L-facht, da für jeden Punkt L Teilbereichspositionen jeweils als ein Tupel ausge-
geben werden. Diese Erhöhung des Datenvolumens ist notwendig, um im Folgenden
die Features pro Teilbereich und damit die Histogramme zu bilden.
Im eben durchgeführten Schritt wurden für alle Punkte die Koordinaten der räum-
lichen Pyramide ermittelt. Diese sollen nun zu der effizienten räumlichen Pyramide
zusammengefasst werden. Während der Implementierung wurde mit verschiedenen
Ansätzen experimentiert, um das Problem der Erhöhung der Datensätze zu vermei-
den. Dazu wurden zwei weitere Ideen untersucht, die beide relativ ähnlich zueinander
sind.
REDUCEZählen der Features
Level 0
REDUCEZählen der Features
Level 1
MAPErmittllung aller
Featurekoordinaten
REDUCEZählen der Features
Level L-1
Abbildung 4.4: Alternativer Plan (Idee 1) zur Erstellung der räumlichen Pyramide: Alle Pyramiden-
koordinaten werden mit einmal erstellt. Danach werden L Reduce-Operationen parallel ausgeführt,
um die Histogramm-Bins zu erstellen.
Bei der ersten Idee wurden alle möglichen Koordinaten der Pyramide für einen
Datensatz erstellt, so dass ein Datensatz ein solches Aussehen hatte:
〈id, iX1, iY 1, l1, .., iXL, iY L, lL, f〉
Da die Tiefe der Pyramide bekannt war, wurde der PACT-Plan derart erstellt, dass
auf dieser Datenmenge parallel Reduce-Operationen mit den Schlüsselfeldern des
entsprechenden Levels ausgeführt werden (Abbildung 4.4). Die Idee war hier, dass
4.3. IMPLEMENTIERUNG DES SPATIAL-PYRAMID-ANSATZES 43
sich die Datenmenge gar nicht erhöhen werde. Die Datenmenge sollte bis auf die Zwi-
schenergebnisse aus den Reduce-Operationen und den zusätzlichen Feldern in den
Datensätzen identisch sein mit der Anzahl aller Messpunkte innerhalb des räumli-
chen Zustandes.
Die zweite Idee war, sich die Effizienz eines Quad-Trees zu bedienen, wenn es darum
geht, dass ein Knoten sich aus der Summe der Kindknoten bildet. Zuerst werden mit
einer Map-Operation Datensätze mit den Koordinaten des größten Level erstellt, al-
so den kleinsten Teilbereichen. Danach wird eine Reduce-Operation iterativ auf der
Ergebnismenge wiederholt ausgeführt, um die Histogramme aller Teilbereiche zu bil-
den (Abbildung 4.5). Diese Reduce-Operation schreibt ans Ende jedes ausgegebenen
Datensatzes die Koordinaten des nächsten Levels. Die Ergebnismenge der Reduce-
Operation ist also immer sowohl die Eingabe der nächsten Reduce-Operation für
das nächste Level als auch Eingabe für die Operation, die nach der Pyramidisierung
folgt. Wie bei der ersten Idee wird dazu bei der Erstellung des PACT-Planes diese
Stelle des Planes in Abhängigkeit der Levels angepasst. Der Vorteil dieser Idee ist,
dass die Menge an Daten, die in die nächste Reduce-Operation einfließen, sich bei
jedem Schritt viertelt und so die Berechnung der Reduce-Operation iterativ immer
schneller vonstatten gehen kann.
REDUCEZählen der Features
Level L-1
REDUCEZählen der Features
Level L-2
MAPErmittllung aller
Featurekoordinaten
REDUCEZählen der Features
Level 0
Abbildung 4.5: Alternativer Plan (Idee 2) zur Erstellung der räumlichen Pyramide: Zuerst werden
nur die Pyramidenkoordinaten des größten Levels erstellt. Danach reduziert jede Reduce-Operation
die Datenmenge und schreibt die nächsten Pyramidenkoordinaten in den Datensatz.
44 KAPITEL 4. UMSETZUNG DES SPATIAL-PYRAMID-ANSATZES IN STRATOSPHERE
Leider konnte bei verschiedenen Experimenten kein Performancegewinn der beiden
Ideen gegenüber der oben aufgeführten Methode, bei der die Datenmenge ver-L-
facht wird, festgestellt werden. Teilweise waren die Ergebnisse der beiden Ideen sogar
schlechter als mit der endgültig durchgeführten Methode. Dies liegt wohl daran, dass
zum Beispiel bei der Idee 1 die Reduce-Operation die Daten L-mal repliziert und
doch wieder eine Ver-L-fachung der Datenmenge entsteht. Durch die zusätzlichen
Felder, die generiert werden, kommt es so sogar zu einer Erhöhung der erzeugten
Datenmenge. Die während einer Reduce-Operation durchgeführten Vergleiche wer-
den aber reduziert, da anstatt einer großen Sortieroperation, um die Schlüssel für die
Datenmenge zu bilden, nur mehrere kleine Operationen benötigt werden. Vor allem
bei der Idee 2 sollte sich das auswirken, da die zu sortierende Datenmenge mit jedem
Schritt geviertelt wird. Insgesamt steigt bei diesen Szenarien die Netzwerklast, da
alle Datensätze repliziert werden müssen. Bei der zweiten Idee wäre der Einsatz, der
früher in Stratosphere (bis Version 0.1.2) vorhandenen Output-Contracts eigentlich
in Betracht gekommen [1]. Mit solchen Output-Contracts konnte der Programmie-
rer, den PACT-Compiler auf bestimmte Eigenschaften der Daten hinweisen. So zum
Beispiel, dass im vorliegenden Fall die Datensätze die Datensätze nicht global neu-
sortiert werden müssten. Eine Einführung dieser Output-Contracts ist in zukünftigen
Versionen von Stratosphere wieder geplant. Die genaue Zahl der benötigten Level
hängt vom Anwendungsfall und den zu untersuchenden räumlichen Zuständen ab.
Je größer die räumlichen Zustände, umso mehr Level sind sinnvoll, da so Teilberei-
che gebildet werden, die nicht zu groß sind und Features gut darstellen können. Da
potenziell also eher mehr Level benötigt werden, um den Spatial-Pyramid-Ansatz
einzusetzen, wovon auch die Anzahl der Reduce-Operationen in den beiden Ideen
abhängt, wurden diese beiden Ideen nicht weiter verfolgt.
Mittels einer nun folgenden Reduce-Operation wird also die Menge der Datensätze
zusammengefasst. Der Schlüssel dieser Operation liegt auf den Feldern
〈id, iX , iY , l, f〉. Die Operation zählt die Features je Teilbereich, so dass folgendes
Schema als Ergebnis vorliegt 〈id, ilX , ilY , l, f, ctf〉. ctf steht für die Anzahl der Fea-
tures in dem Teilbereich ilX , ilY im Level l. Ein Tupel stellt so einen Bin im Histo-
gramm des entsprechenden Teilbereichs dar. Diese Reduce-Operation benutzt das
4.3. IMPLEMENTIERUNG DES SPATIAL-PYRAMID-ANSATZES 45
in Stratosphere implementierte Combinable Attribut. Dieses Attribut bewirkt, dass
Stratosphere beim Bilden des globalen Schlüssels die Daten einer Gruppe nicht erst
an den Nutzercode weiterreicht, wenn der Schlüssel vollständig gebildet ist und die
gesamte Gruppe bekannt ist. Stratosphere kann mittels der Combine-Funktion eine
Menge an Daten an den Nutzercode reichen. Die Combine-Funktion kann die Da-
ten in einem Vorverarbeitungsschritt schon voraggregieren. Diese Combine-Funktion
kann angewandt werden, wenn die Reduce-Funktion assoziativ und kommutativ ist.
Die Combine-Funktion wendet Stratosphere zum Beispiel an, wenn ein Cache voll
ist oder bevor die Daten über das Netzwerk verschickt werden. So kann Stratos-
phere erreichen, dass die Daten immer wieder „komprimiert“ werden und nicht alle
Datensätze über das Netzwerk verschickt werden6.
Beispiel - Implementierung Spatial-Pyramid-Ansatz (Fortsetzung):
Ausgehend von dem vorher aufgeführten Beispiel wird das weitere Vorgehen
demonstriert. Im nächsten Schritt werden nun die verschiedenen Teilberei-
che erstellt. Mit L = 3 ist die maximale Leveltiefe max(l) = 2, für die alle
Teilbereiche berechnet werden. Zuerst werden hierzu die Teilbereiche des
größten Levels erstellt. Dazu wird für jeden Bildpunkt die Formel
il = bmin(2l, (i/(max/2l)))c
(Abschnitt 4.3.1) angewandt.max ist im aktuellen Fall für jede Dimension x
und y gleich 4 und l = 2. Daraus ergibt sich konstant für max/2l = 4/4 = 1.
Außerdem werden in dieser Map-Operation die Werte für alle anderen Teil-
bereiche erstellt. Hierzu werden die Teilbereichskoordinaten des vorher er-
mittelt größeren Levels genommen und Level für Level ganzzahlig durch 2
geteilt.
6Combiner gibt es schon bei Map/Reduce und sollen auch dort die Daten voraggregieren [9].
46 KAPITEL 4. UMSETZUNG DES SPATIAL-PYRAMID-ANSATZES IN STRATOSPHERE
Level (l) Teilbereichskoordinaten
für den Punkt (1, 3)
2 1,3
1 0,1
0 0,0
Tabelle 4.2: Für den Punkt 〈1, 3〉 des räumlichen Zustands ergeben sich die folgenden Koordinaten
absteigend für jedes Level.
Aus dieser Operation folgt nun, dass für jeden Bildpunkt und jedes Level ein
Datensatz erstellt wird. Die Menge der Datensätze wurde nun ver-L-facht,
und es liegen zu den vorher 16 Datensätzen nun 48 Datensätze vor7. Mit der
nun folgenden Reduce-Operationen auf den Feldern id, iX , iY , l, f werden die
Vorkommen je Feature und Teilbereich gezählt. Dadurch erweitert sich der
Datensatz um die Anzahl der Features ctf je Teilbereich. Für das Level 0
und das Feature 2 hätte der Datensatz folgenden Inhalt:
file1.asc 0 0 0 2 4
Der nächste Schritt in der Berechnung der Ähnlichkeiten ist das Zusammenfassen
der Datensätze pro Teilbereich und Feature. Hierbei werden alle vorliegenden Wer-
te in einem Feld gespeichert, so dass eine kompakte Struktur entsteht. Um diese
kompakte Struktur zu erhalten, wird zunächst ein Reduce-Operator angewandt, der
als Schlüssel die Werte 〈id, f〉 umfasst. Die dazugehörige Nutzerfunktion fasst die
gezählten Features pro Teilbereich zusammen, so dass ein festes Muster je Feature
entsteht, das in ein Feld geschrieben wird. Dadurch wird die vorliegende Anzahl der
Tupel reduziert. Die Anzahl eines Feature ctf im Teilbereich mit den Koordinaten
ix und iy im Level l wird hier repräsentiert durch den Wert c(ilX , ilY , l). Alle diese
Werte werden nacheinander geschrieben, so dass ein festes Schema beginnend mit
7Es sind nur 48 Datensätze, weil nicht in allen Teilbereichen jedes Feature existiert. Zum Beispiel existiert in
Level 2 für jeden Teilbereich nur ein Feature.
4.3. IMPLEMENTIERUNG DES SPATIAL-PYRAMID-ANSATZES 47
Level 0 der folgenden Form entsteht:
[c(0, 0, 0), c(0, 0, 1), c(0, 1, 1), c(1, 0, 1), c(1, 1, 1), c(0, 0, 2)..., c(2L−1, 2L−1, L− 1)]
Diese Struktur wird Signatur genannt und mit sigfL bezeichnet. Die Signatur steht
für alle Vorkommen des Feature f in den Teilbereichen der Level l ∈ {0, . . . , L− 1}.
Beispiel - Implementierung Spatial-Pyramid-Ansatz (Fortsetzung):
Zur Bildung der Signaturen wird eine Reduce-Operation benutzt, welche als
Schlüssel die Felder 〈id, f〉 benutzt. Durch die Signatur wird die Datenmen-
ge insgesamt kompakter, und es liegen nun insgesamt weniger Datensätze
vor. Der Inhalt der vorher 48 Datensätze ist nun in nur noch vier Datensät-
zen dargestellt (Tabelle B.3).
In den Signaturen, von der je Feature und Datei genau eine vorliegt, sind an
der ersten Position die Vorkommen des Features in Level 0, in der zweiten
bis fünften Position die Features von Level 1 und in den Positionen 6 - 21
die Vorkommen aus Level 2.
Jede Position in der Signatur entspricht einem Bin in dem Histogramm des
entsprechenden Teilbereichs. Ein Bin steht für ein Feature in dem Histo-
gramm.
4.3.2 Vergleich und Bildung der Ähnlichkeitsmatrix
REDUCEErstellen der
Vergleichspaare
MAPVergleichen der
Featuresignaturen
OUTPUTAusgabe der
Distanzen
REDUCESummieren der
Featuredistanzen
Abbildung 4.6: PACT-Schema (3.Teil) zur Implementierung des Spatial-Pyramid-Ansatzes - Ver-
gleich der räumlichen Zustände.
Als nächstes erfolgt nun der eigentliche Vergleich der räumlichen Zustände mit-
einander (Abbildung 4.6). Dazu ermittelt ein Reduce-Operator zunächst die Ver-
48 KAPITEL 4. UMSETZUNG DES SPATIAL-PYRAMID-ANSATZES IN STRATOSPHERE
gleichspaare für alle räumlichen Zustände und je Feature. Dies geschieht, indem als
Schlüsselfeld das Feld 〈f〉 gewählt wird. Dadurch umfasst eine Gruppe jeweils alle
Datensätze, die dasselbe Feature haben. Eine Nutzerfunktion sorgt für eine Permu-
tation aller Datensätze per Gruppe. So erhält man ein Tupel mit den Feldern
〈id1, f, sig(id1), id2, sig(id2)〉. Da das Ähnlichkeitsmaß symmetrisch ist, wird hier
bei der Generierung der Paare darauf geachtet, dass jedes Paar nur einmal gebildet
wird, um unnötige Paare und damit Netzwerkverkehr und Rechenaufwand zu ver-
meiden. Es wird ein Datensatz für id1, id2 erstellt, aber nicht für id2, id1. Der Fall,
bei dem beide id-Felder identisch sind, wird ebenfalls abgedeckt und dafür exakt ein
Datensatz erstellt.
Der Fall, dass beide räumlichen Zustände in einem Vergleichspaar vorkommen, wird
hier nicht separat in der Implementierung behandelt. In der hier behandelten Ver-
sion des Spatial-Pyramid-Ansatzes wird aus jeden Punkt ein Feature erstellt. Da-
durch ist der maximale Ähnlichkeitswert bei einem Vergleich bekannt, denn dieser
ist m∗n, mit m und n den jeweiligen Achslängen. Dieser maximale Ähnlichkeitswert
entsteht aus der Summe der gemeinsamen Features identischer räumlicher Zustände
auf dem höchsten Level. Die Anzahl aller Features im höchsten Level ist die An-
zahl der Punkte des räumlichen Zustandes. Eine Sonderbehandlung der identischen
räumlichen Zustände wurde an dieser Stelle der Paarbildung aber nicht vorgenom-
men, um die Implementierung des Vergleiches nicht an die hier behandelt Methode
der Featuregenerierung zu binden. Andere Möglichkeiten Feature zu bilden, könnten
in einem Punkt zum Beispiel kein Feature erkennen oder auch mehrere Features an
einem Punkt finden. Für ein anderes Modell der Featuregenerierung könnte eben kei-
ne Abschätzung des Ähnlichkeitswertes für identische räumliche Zustände errechnet
werden. Eine mögliche Sonderbehandlung identischer räumlicher Zustände würde
hier dann verhindern, dass das modulare Programmiermodell, welches Stratosphere
bietet, nicht genutzt werden würde. Ein einfacher Austausch der Featuregenerierung
innerhalb der Implementierung wäre dann nicht mehr möglich.
An dieser Stelle wäre eigentlich ein Match-Operator die logische Wahl gewesen. Bei
einem solchen Match-Operator hätte man auf der linken und rechten Seite diesel-
be Eingabemenge gesetzt, und als Schlüsselfeld für die Match-Operation hätte das
4.3. IMPLEMENTIERUNG DES SPATIAL-PYRAMID-ANSATZES 49
Feature-Feld 〈f〉 gedient. Der Nutzercode wäre deutlich einfacher als bei der hier
gewählten Reduce-Operation. Stattdessen wurde jedoch entschieden, den Reduce-
Operator zu benutzen, da es sich bei dem Match-Operator, bei dem auf beiden
Seiten dieselbe Eingabemenge vorliegt, um einen Self-Match handelt. Stratosphe-
re kann eine solche Konstruktion jedoch nicht erkennen und verschickt alle Daten
doppelt über die Netzwerkschnittstelle und zwar jeweils einmal für beide Inputs.
Um diese doppelte Behandlung zu vermeiden, wurde die in dem Fall des Self-Match
effizientere Reduce-Operation gewählt (siehe auch Abschnitt 4.4).
Bei dem auf die Bildung Vergleichspaare folgenden Vergleich wird mittels eines Map-
Operators der Vergleich der Features durchgeführt. Dies erfolgt, indem die beiden
Signaturen durchiteriert werden und das paarweise Minimum gebildet wird. Dieses
Minimum wird dann pro Level aufsummiert, die Differenzen je benachbarten Level
werden gebildet, und diese Differenz wird gewichtet. Die aufsummierten gewichte-
ten Differenzen ergeben das skalare Ähnlichkeitsmaß je Feature. Das Schema der
Ausgabe dieser Operation lautet 〈id1, id2, f, simf〉.
Beispiel - Implementierung Spatial-Pyramid-Ansatz (Fortsetzung):
Zu dem oben gezeigten Beispiel um die Datei ”file1.asc” wird nun ein zwei-
ter räumlicher Zustand ”file2.asc” hinzugezogen (Tabelle B.2). Mit diesem
räumlichen Zustand werden dieselben Schritte vollzogen, wie vorher auch
mit dem anderen räumlichen Zustand, und so wird die Signatur für den
räumlichen Zustand ermittelt (Tabelle B.4).
Zwischen diesen beiden räumlichen Zuständen wird nun ein Vergleich zur
Ermittlung der Ähnlichkeit durchgeführt. Die Reduce-Operation, die als
erste die Permutation zur Bildung von Vergleichspaaren durchführt, erstellt
nur die Vergleichsdatensätze. Es entstehen die Vergleichspaare
〈file1.asc, file1.asc〉, 〈file2.asc, file2.asc〉 und 〈file1.asc, file2.asc〉. Je-der Datensatz für ein Vergleichspaar enthält außerdem das Feature f und
die beiden zugehörigen Featuresignaturen.
Die nächste Operation führt mehrere Schritte aus, die zunächst die Ähnlich-
50 KAPITEL 4. UMSETZUNG DES SPATIAL-PYRAMID-ANSATZES IN STRATOSPHERE
keit pro Feature ermitteln. Dazu werden zuerst die Minima je Feature-Bin
gebildet. Diese Minima werden je Level addiert. Sie ergeben ergeben eine
Art Feature-Index pro Level. Jeder Eintrag in der Liste stellt nun einen
solchen Feature-Index dar. Die Liste beginnt mit dem Index des niedrigs-
tens Level. Da je Level nur die Features betrachtet werden sollen, die ”neu”
hinzugekommen sind, wird je Level die Differenz mit dem nächsten Level
gebildet. Die vorliegenden Differenzen werden je Level mit einem vom Level
abhängigen Gewichtungsfaktor multipliziert (Tabelle B.5). Danach werden
die gewichteten Werte aufsummiert, wodurch sich je Feature eine Feature-
Ähnlichkeit ergibt (Tabelle B.6).
Eine weitere Reduce-Operation, durchgeführt über die Schlüsselfelder
〈id1, id2〉, summiert die Ähnlichkeitswerte pro Feature zu einem skalaren
Gesamtähnlichkeitswert, der zu einem Datensatz 〈id1, id2, sim〉 führt. Die
Ähnlichkeit der beiden räumlichen Zustände nach dem Spatial-Pyramid-
Ansatz ist für die räumlichen Zustände file1.asc und file2.asc nun 9.25.
4.4 Diskussion Parallelimplementierung
Nach der Extraktion der Features und der Generierung der Pyramideninformationen
erfolgt die Generierung der Vergleichspaare. Dies bedeutet, dass eine Informations-
menge mit sich selbst Paare bilden muss, so dass eine Permutation für alle räumlichen
Zustände entsteht, die paarweise Vergleiche erlaubt. In den ersten Versuchen wurde
dazu in Stratosphere der Match-Operator verwendet. Hierzu wurde als Eingabe für
die beiden Eingabesätze die gesamte vorliegende Datenmenge benutzt. Mittels einer
Nutzerfunktion wurden die entstehenden Paare so gefiltert, dass jeder mögliche Ver-
gleich nur einmal stattfindet. Derzeit sind in Stratosphere Self-Matches nicht in der
Implementierung berücksichtigt und rufen deshalb eventuell ungewolltes Verhalten
bei der Ausführung hervor. Ein Self-Match bedeutet, dass ein Match-Operator ange-
wandt wird, der auf der rechten und linken Seite die gleiche Eingabemenge besitzt.
Bei einem Match müssen die Daten, die auf einem Knoten liegen, an alle anderen
Knoten gesandt werden, damit diese dort verarbeitet werden können. Im Falle des
4.4. DISKUSSION PARALLELIMPLEMENTIERUNG 51
Spatial-Pyramid-Ansatzes ist die Verarbeitung ein Vergleich der id, und das Ver-
werfen des Paares, wenn das Paar nicht benötigt wird. Das kann zu einem höheren
Netzwerkverkehr führen, der sich negativ auf das Laufzeitverhalten auswirkt. Wenn
Stratosphere erkennen würde, dass auf beiden Seiten des Match-Operators dieselbe
Menge vorliegt, könnte eventuell unnötiger Netzwerkverkehr unterbunden werden.
Da dies aber nicht der Fall ist, wurde die Implementierung der Paarbildung geändert
und stattdessen ein Reduce-Operator benutzt, der in der Funktion ersten Grades die
möglichen Permutationen bildet. Bei der Wahl dieses Operators ging es ausschließ-
lich um die Reduzierung des möglichen Netzwerkverkehrs. Bei dem Reduce-Operator
ist dies implizit so, da alle Datensätze einer Gruppe nur auf einem Knoten bearbeitet
werden und nur die benötigten Daten an den zuständigen Knoten versandt werden.
Bei einem Match-Operator würden passende Datensätze mit demselben Schlüssel
von der rechten und linken Seite des Operators an den zuständigen Knoten versandt
werden und erst dort würden „unpassende“ Paare herausgefiltert werden.
Der Reduce-Operator kann aber auch zu Nachteilen führen, denn zur Bildung der
Gruppen muss dieser einen globalen Schlüssel bilden, der über alle Knoten ausge-
tauscht wird. Zusätzlich muss der Nutzercode die Paarbildung vornehmen und hier
ist die Reduce-Operation durch den Arbeitsspeicher begrenzt, in dem alle Werte für
die Paarbildung einmal eingelesen werden müssen. Da die Nutzerfunktion keine Sei-
teneffekte haben darf, ist ein Auslagern von Daten auf die Festplatte nicht möglich.
Bei einer Match-Operation würde aber Stratosphere die Paare bilden. Das System
könnte die Daten temporär auf die Festplatte auslagern, und hätte keine derartige
Beschränkung. Im Falle einer neueren Version von Stratosphere, die ein Self-Match
erkennen würde, wie dies in früheren Versionen möglich war, wird die Benutzung
des Match-Operators empfohlen.
Kapitel 5
Evaluierung
Es wurden verschiedene Experimente mit Daten aus einem geowisschenschaftlichen
Kontext und synthetischen Daten durchgeführt, um die Performance der Imple-
mentierung und den Einfluss verschiedenster Parameter zu messen. Die Messungen
wurden dabei auf einem Cluster am Geoforschungszentrum Potsdam durchgeführt.
5.1 Cluster am Geoforschungszentrum Potsdam
Das Cluster am Geoforschungszentrum Potsdam [15] ist ein heterogenes Cluster,
bei dem Ressourcen transparent alloziert werden können. Innerhalb dieses Cluster
gibt es verschiedene Ressourcen von Servern, die eine unterschiedliche Konfigurati-
on haben und unterschiedlichen Beschränkungen unterliegen. Diese Beschränkungen
umfassen zum Beispiel, wie lange ein Job auf dem Rechner maximal laufen darf oder
wieviel Ressourcen des Servers er maximal verbrauchen darf. Das Cluster ist nicht
originär darauf ausgelegt, Jobs wie Stratosphere laufen zu lassen. Für die Experi-
mente wurde daher ein Clusterbereich gewählt, der die meisten Freiheiten bezüglich
der zeitlichen Beschränkung der laufenden Jobs hatte. Der Servertyp, der innerhalb
des Cluster während der Experimente benutzt wurde, hat als Prozessor einen Intel
Opteron 280 mit 2,4 GHz. Pro Server standen 4 GB RAM zur Verfügung, und die
lokale Festplatte eines jeden Servers hatte ein Fassungsvermögen von 160 GB.
Zum Start von Stratosphere müssen ein Jobmanager und eine entsprechende Anzahl
52
5.2. TEST- UND VERGLEICHSGEGENSTAND 53
von Taskmanagern gestartet werden (Abschnitt 3.2.1). Das Cluster ist durch mehre-
re Schichten unterteilt, die die Ressourcen für alle Nutzer verteilen. Die Ressourcen
werden in Anwendungs- und Rechnergruppen geteilt, wobei die Anwendungsgruppe
regelt, wieviele Ressourcen pro Job zur Verfügung stehen. Außerdem gibt es noch
Einschränkungen wieviele Ressourcen pro Job gleichzeitig reserviert werden können.
Ein Ressourcenpool im Rechencluster gibt auf Anfrage eine reservierte Ressource zu-
rück, auf der man einen Prozess starten kann.
Zum Start von Stratosphere auf dem Cluster mussten am Startprozedere einige An-
passungen vorgenommen werden. Im Regelfall werden im Cluster Jobs in eine Queue
gesteckt, die irgendwann abgearbeitet werden, je nachdem welchen Einschränkungen
die Queue oder der Nutzer unterliegt. Für den Start von Stratosphere ist es notwen-
dig, dass alle Taskmanager sofort starten, da diese sich beim Jobmanager registrieren
müssen. Ein verzögerter Start eines Bestandteils von Stratosphere war somit nicht
möglich. Das angepasste Skript zum Starten der Taskmanager auf den verschiedenen
Instanzen musste dabei auch berücksichtigen, dass keine zwei Taskmanager auf einer
Maschine gestartet wurden, wenn das Cluster einen Server zurückgab, der schon von
Stratosphere benutzt wurde. Im vorliegenden Fall kam nur eine Queue zum Einsatz,
die eine Parallelisierungseinschränkung von 1 hatte8 und von der maximal 24 Jobs
gleichzeitig gestartet werden durften. Bei dieser Queue durften die Jobs allerdings
beliebig lange laufen.
5.2 Test- und Vergleichsgegenstand
Um die parallele Implementierung des Spatial-Pyramid-Ansatzes zu messen, wurde
zuerst die Laufzeit mit einer unterschiedlich großen Anzahl von räumlichen Zustän-
den untersucht. Dazu wurden eine stetig wachsende Menge räumlicher Zustände
benutzt, um das Lastverhalten der Implementierung zu beobachten. Jede Messung
wurde 5-mal wiederholt und der Mittelwert dieser 5 Vergleiche zur weiteren Analyse
herangezogen. Außerdem wurden neben den äußeren Faktoren wie die Anzahl der
räumlichen Zustände für jede Messung ebenfalls die Parameter über die Level und8Pro Job durfte maximal ein Core benutzt werden.
54 KAPITEL 5. EVALUIERUNG
die Anzahl der Features variiert. Dabei entstand eine Permutation über die Einga-
beparameter #Zustande× Feature× Level.Weiterhin wurde eine Beispielimplementierung für die SSE erstellt und diese Imple-
mentierung den Ergebnissen der Spatial-Pyramid-Implementierung gegenüber ge-
stellt. Das Laufzeitverhalten der SSE-Implementierung wurde auch hier bezüglich
der Anzahl der räumlichen Zustände untersucht.
Alle Experimente über die Laufzeit wurden mit einer Parallelität von 24 durchge-
führt.
Neben der Laufzeit wurden die Ergebnisse auch auf ihre Qualität hin untersucht.
Betrachtet wurde, in welchem Verhältnis Geschwindigkeit und Qualität stehen. Da-
zu wurde die Qualität der Ähnlichkeiten ausgewertet. Für die Distanzen der SSE
und die Ähnlichkeiten der Spatial-Pyramid wurden je räumlichen Zustand die zehn
direkten Nachbarn ermittelt. Aus diesen ähnlichsten zehn Zuständen aus beiden Im-
plementierungen wurden die übereinstimmenden Kandidaten ermittelt. In der Aus-
wertung sollte sich so ergeben, welche Übereinstimmung die Ergebnisse des Spatial-
Pyramid-Ansatzes zu den Daten der SSE haben. Ziel ist es bei dieser Auswertung zu
erkennen, unter welchen Parametern die Ähnlichkeit des Spatial-Pyramid-Ansatzes
hoch genug ist, damit die Ergebnisse eine gute Qualität haben. Dieser Vergleich
wurde ebenfalls über Anzahl der Features und der Anzahl der Level variiert.
Außerdem wurde die Güte der Implementierung ermittelt. Vergleichbar zu der eben
genannten Qualität wird aus der Distanzmatrix beziehungsweise Ähnlichkeitsmatrix
beider Implementierungen der direkte Nachbar für jeden räumlichen Zustand aus-
gewertet. Stimmen die aus beiden Implementierungen gewählten Elemente überein,
steigert dies die Güte, und es wird prozentual ermittelt, wie hoch die Güte über alle
räumlichen Zustände ist.
Die Qualität soll im Gegensatz zu der Untersuchung der Güte feststellen wie gut
das Gesamtergebnis ist. Die Güte ist wichtig, um messen zu können, ob ähnliche
Ergebnisse zwischen der SSE und dem Spatial-Pyramid zu erwarten sind, wenn
centroid-basierte Clusteringverfahren benutzt werden. Solche Verfahren untersuchen
nur den generellen Abstand eines Zustands zu dem Cluster. Nutzt man k-Nearest-
Neighboring Verfahren zum Clustern wird ein räumlicher Zustand zu einem Cluster
5.3. ERWARTETER EINFLUSS VON PARAMETERN DES SPATIAL-PYRAMID-ANSATZES55
zugeordnet, in welchem die meisten seiner k-Nachbarn liegen [7]. Der Vorteil eines
solchen Clustering ist, dass nicht ein herausragender Nachbar für die Ähnlichkeit
eines Clusters zu einem räumlichen Zustand genommen wird, sondern jenes Cluster,
welches dem Zustand insgesamt am ähnlichsten ist. Mit der Analyse der Qualität
kann man für genau diese Fälle, die Übereinstimmung für die ersten zehn Nachbarn
zwischen der SSE und des Spatial-Pyramid-Ansatzes feststellen.
5.3 Erwarteter Einfluss von Parametern des Spatial-Pyra-
mid-Ansatzes
Insgesamt kann die Implementierung durch mehrere Parameter beeinflusst werden,
die sich auf die Genauigkeit der errechneten Ähnlichkeiten und die Laufzeit der
Implementierung auswirken können. Als erstes wäre an dieser Stelle die Tiefe der
Pyramide L zu nennen, die auf die Menge der zu behandelnden Teilbereiche di-
rekt einwirkt. Mit jeder Erhöhung von L erhöht sich die Anzahl der Teilbereiche
um 22∗(L−1). Durch feinere Teilbereiche können bestimmte Features auch in ihrer
räumlichen Ausprägung besser erfasst werden. Diese kleineren Teilbereiche haben
zur Folge, dass die größere Menge der Teilbereiche zuerst berechnet werden muss
und dann auch die Vergleiche je Teilbereich durchgeführt werden müssen. Hier gibt
es in der Abwägung bei der Wahl des Parameters eine direkte Wechselwirkung zwi-
schen der Laufzeit der Implementierung und der Qualität der Vergleichswerte (Ab-
schnitt 5.5.1).
Ein weiterer Parameter in dem Algorithmus ist die Anzahl der Features. Wie oben
beschrieben (Abschnitt 2), werden die Features so gebildet, dass der Wertebereich
aller räumlichen Zustände in gleichgroße Intervalle geteilt wird; dabei steht jeder
Intervall für ein Feature. Als Parameter für die Implementierung gibt es einen Wert
F , der die gewünschte Anzahl Features steuert. Dieser Wert ist auch identisch mit
der Anzahl der Bins in den Histogrammen der Teilbereiche. Der Benutzer kann die
Quantisierung des Wertebereiches in Bits angeben. Je größer der Wert F ist, desto
kleiner sind die Intervalle des Wertebereiches je Feature, und desto feiner können
56 KAPITEL 5. EVALUIERUNG
gleiche Features ausfallen. Bei dem Algorithmus werden nur identische Features de-
tektiert. Werden bei steigender Anzahl der Features die Featureintervalle kleiner,
so kann es passieren, dass keine Ähnlichkeiten mehr detektiert werden können und
so eine ausreichende Qualität der Ergebnisse nicht mehr gegeben ist. Das Ziel der
Features soll es ja sein, Ähnlichkeiten der Messwerte innerhalb eines Intervalls als
ein Feature zu beschreiben. Werden die Featureintervalle sehr klein, gibt es folglich
auch weniger Messwerte, die je Feature vorliegen, und der Vergleich der Histogram-
me könnte so auch kaum noch Ergebnisse liefern. Außerdem erhöht die Anzahl der
Features linear die Breite der Histogramme und entsprechend auch die Laufzeit der
Implementierung.
5.4 Referenzdaten
5.4.1 Ozeandaten
Im Zentrum der Untersuchung standen Daten aus Satellitenmessungen der Wasser-
höhen der Ozeanoberflächen. Diese Messungen wurden erstellt von Ssalto/Duacs und
von Aviso bereitgestellt, mit Unterstützung des CNES [4]. Diese Daten resultieren
aus Messungen von Satelliten, die von 1992 bis 2009 die Höhe des Meeresspiegels
der Ozeane gescannt haben. Die Wasserhöhen wurden dabei über einen längeren
Zeitraum gemessen, um Langzeitphänomene zu erkennen und zu verfolgen. Die Auf-
lösung der vorliegenden Daten beträgt 194 × 92 Punkte und umfasst die gesamte
Erdoberfläche. Für jeden als Bildpunkt dargestellten Punkt wurde das langfristige
Mittel gebildet, und die gemessenen Werte wurden dazu in Beziehung gestellt. Dar-
aus ergibt sich, dass die Daten nur die Abweichung von diesem langfristigen Mittel
enthalten (Abbildung 5.1). Bildpunkte, die keine Daten enthalten, weil an dieser
Stelle zum Beispiel nur Landmassen vorliegen, haben den Wert NA.
5.4. REFERENZDATEN 57
Abbildung 5.1: Visualisierung eines räumlichen Zustandes der Ozeandaten. Konturen der Konti-
nente wurden hervorgehoben. Der minimale und maximale Wert für die Visualisierung wurden
beschränkt. (Visualisierung mit Panoply [23])
Von diesen Ozeandaten lagen 876 räumliche Zustände vor. Erfasst sind jeweils die
wöchentlichen Mittelwerte. Diese Daten stehen im Zentrum der Untersuchung, da
sie schon weitgehend untersucht worden sind und dementsprechend die Ergebnisse
mit den schon vorhandenen verglichen werden können [19]. An diesen Daten wurden
die Wetter-Phänomene El Niño und La Niña untersucht, die relativ regelmäßig im
Pazifischen Ozean beziehungsweise in der Karibik auftauchen. Mittels SSE wurde
eine Distanzmatrix auf diesen Daten aufgebaut. Diese Ähnlichkeiten wurden in den
schon bestehenden Untersuchungen geclustert, und es wurde untersucht, ob sich
anhand der Cluster Rückschlüsse auf tatsächlich stattgefundene Wetterphänome-
ne ziehen lassen. Diese ausgewerteten Daten wurden von Geowissenschaftlern des
Geoforschungszentrums Potsdam begutachtet.
58 KAPITEL 5. EVALUIERUNG
5.4.2 Synthetische Daten
Da die Ozeandaten relativ geringe Dimensionen haben, wurden zusätzlich noch syn-
thetische Matrizen mit zufälligen Werten erzeugt, die eine höhere Dimensionalität
als die Ozeandaten haben sollen. Bei einem Umfang von 512× 512 Punkten hat ein
solcher synthetischer räumlicher Zustand eine durchschnittliche Größe von 2,9 MB.
Auch mit diesen räumlichen Zuständen wurden Untersuchungen bezüglich Perfor-
mance im Vergleich zu einer SSE-Implementierung durchgeführt. Ziel der Untersu-
chung dieser Daten sollte es sein zu zeigen, dass bei einer höheren Dimensionalität
der Ursprungsdaten die Performance der parallelen Implementierung steigt.
5.5 Evaluation Ozeandaten
Für den ersten Teil der Evaluierung wurde die Laufzeitleistung der Implementierung
des Spatial-Pyramid-Ansatzes anhand der Ozeandaten untersucht. Zunächst wurde
die Anzahl der räumlichen Zustände jeweils schrittweise verdoppelt. Es entstanden
Eingabemengen mit der folgenden Anzahl von räumlichen Zuständen {2, 4, 8, 16,
32, 64, ..., 1.024}. Wenn mehr als die vorhandenen 876 räumlichen Zustände benutzt
wurden, wurden beliebige räumliche Zustände aus der Menge aller räumlichen Zu-
stände kopiert und unter einem neuen Namen verwendet. Bei diesem Versuch wurde
lediglich eine Laufzeitevaluierung vorgenommen. Das Betrachten der Güte würde
auf Grund der kopierten Zustände verfälschte Ergebnisse liefern. Außerdem wurde
für jede Menge an räumlichen Zustände die Anzahl der Level jeweils zwischen 1 und
6 durchiteriert und die Anzahl der Features von 2 beginnend auf 256 erhöht, indem
in jedem Erhöhungsschritt die Featureanzahl verdoppelt wurde9.
Im Anhang sind alle gemittelten Laufzeiten (Abschnitt C.1.2) und die Standard-
abweichungen (Abschnitt C.1.3) dieser Experimente aufgeschlüsselt. Zu sehen ist,
dass sich die benötigte Laufzeit zur Berechnung bei geringer Menge an räumlichen
Zuständen relativ stabil verhält (Tabelle C.1 - Tabelle C.8, Abbildung C.1 - Ab-
bildung C.8). Dies liegt daran, dass die Eingabemenge von bis zu 128 räumlichen9In den Auswertungen wird häufig auf den Featureexponenten verwiesen. Dieser Featureexponent beschreibt die
Länge des Featurevektors in bit. Daher ergibt sich aus 2Featureexponent die Anzahl der verwendeten Features.
5.5. EVALUATION OZEANDATEN 59
Zuständen zu gering ist, um eine Veränderung des Laufzeitverhalten durch die Para-
meter Level oder Feature zuverlässig festzustellen. Somit ist an dieser Stelle vor al-
lem sichtbar, dass ein Overhead beim Start und Stopp des Stratosphere-Programms
vorliegt, was den Großteil der Messung ausmacht. Im Bereich ab 256 räumlichen Zu-
ständen (Tabelle C.9 - Tabelle C.11, Abbildung C.9 - Abbildung C.11 ) erhöht sich
die Laufzeit bei doppelter Eingabemenge recht drastisch. Diese Erhöhung resultiert
daraus, dass die Anzahl der paarweisen Vergleiche der räumlichen Zustände qua-
dratisch wächst, weil jeder räumliche Zustand mit jedem anderen verglichen werden
muss. Eine Reduzierung dieser Laufzeiterhöhung bei Erhöhung der Eingabemenge
kann nur mit einer Erhöhung der Parallelität erreicht werden.
Level (l) Anzahl der Teilberei-
che im Level
Gesamtanzahl der Teilberei-
che von Level 0 . . . l
0 1 1
1 4 5
2 16 21
3 64 85
4 256 341
5 1024 1365
6 4096 5461
7 16384 21845
Tabelle 5.1: Anzahl der Teilbereiche und Gesamtanzahl der Teilbereiche je Level
Betrachtet man die Tabelle mit den gemittelten Messwerten für die Eingabemenge
der 1024 räumlichen Zuständen (Tabelle C.11, Abbildung 5.2), so ist an diesen Daten
zu sehen, wie die Erhöhung der Levels - in der horizontalen Achse - und die Erhö-
hung der Features - in der vertikalen Achse - sich auf die Gesamtlaufzeit auswirken.
Jede Erhöhung des Levels hat eine ungefähre Vervierfachung (Tabelle 5.1) der ein-
zelnen Detailvergleiche beim paarweisen Vergleich räumlicher Zustände zueinander
zur Folge, weil ein Level in der räumlichen Pyramide hinzukommt und jeder Teilbe-
reich in 4 neue Teilbereiche unterteilt wird. Dabei verhalten sich die Laufzeiten für
diesen Eingabesatz für die Erhöhung der Level unterhalb einer Vervierfachung (Ta-
60 KAPITEL 5. EVALUIERUNG
belle C.23). Der größte Erhöhungsfaktor für diese Daten mit 2, 99 ist noch deutlich
unter einer maximalen linearen Erhöhung von 4.
0
50
100
150
200
250
300
350
400
1 2 3 4 5 6 7 8
Lauf
zeit
in s
Featureexponent
Level 1Level 2Level 3Level 4Level 5Level 6
SSE
Abbildung 5.2: Grafische Darstellung der durchschnittlichen Laufzeit für 1024 räumliche Zustände.
Ein Graph steht für die SSE, die anderen je für ein Level.
Eine Verdopplung der Features hat nur eine Verdopplung der einzelnen Vergleiche
zur Folge, da nur die zu vergleichenden Histogramme entsprechend verbreitert wer-
den. In Tabelle A.1 ist zu sehen, wie sich die Anzahl der Vergleiche zu der Anzahl
der Level und Features für den Spatial-Pyramid-Ansatz verhält (Abbildung 5.3).
Mit ∗ markiert sind in dieser Tabelle die Werte, die die Anzahl der Punktvergleiche
bei einer SSE Implementierung übertreffen. Bei einer SSE Implementierung werden
jeweils 192 ∗ 94 = 18.048 Punktvergleiche pro paarweisen Vergleich räumlicher Zu-
stände durchgeführt. Daher kann es passieren, dass in Bezug auf die Laufzeit je nach
Art des räumlichen Zustandes der Nutzen der Implementierung des Spatial-Pyramid-
Ansatz verringert wird, wenn die Anzahl der Vergleiche, die der SSE überschreitet.
Dieser eingeschränkte Nutzen ist auch darauf zurückzuführen, dass die Dimensionen
der räumlichen Zustände der Ozeandaten nicht so groß sind. Für solche Konfiguratio-
nen kann man auch sagen, dass das Ziel des Spatial-Pyramid-Ansatzes nicht erreicht
wurde. Dessen Ziel ist es ja die Dimensionalität des Vergleichsvektors zu reduzieren.
Die Effizienz des Spatial-Pyramid-Ansatzes und die Reduzierung der Einzelverglei-
5.5. EVALUATION OZEANDATEN 61
che kann bei ungünstiger Wahl der Parameter aufgehoben werden.
0
50000
100000
150000
200000
250000
300000
350000
1 2 3 4 5 6 7 8
Anz
ahl d
er V
ergl
eich
sope
ratio
nen
Featureexponent
Level 1Level 2Level 3Level 4Level 5Level 6
Abbildung 5.3: Grafische Darstellung der Anzahl der Vergleichsoperationen je Level.
Betrachtet man die Laufzeit der SSE-Implementierung (Tabelle C.27) im Vergleich
zu den entsprechenden mittleren Laufzeiten des Spatial-Pyramid-Ansatzes (Tabel-
le C.1 - Tabelle C.11), so kann man sehen, dass für alle Eingabemengen von räumli-
chen Zuständen fast nur bei Level 6 und der Featureanzahl 128 (Featurexponent: 7)
und 256 (Featurexponent: 8) eine Überschreitung der Messwerte aus der SSE erreicht
wird. An diesem Punkt liegt also die Schwelle für den Nutzen der Implementierung,
da für diese Daten die SSE Implementierung performanter wäre. In Abbildung 5.4
ist sichtbar wie die Laufzeiten für das Level 6 bei einer Konfiguration mit 256 Fea-
tures immer langsamer ist als die anderen Konfigurationen und gegenüber der SSE
keinen Laufzeitvorteil bringt.
62 KAPITEL 5. EVALUIERUNG
0
50
100
150
200
250
300
350
400
1 2 4 8 16 32 64 128 256 512 1024
Lauf
zeit
in s
räumliche Zustände
Level 1Level 2Level 3Level 4Level 5Level 6
SSE
Abbildung 5.4: Grafische Darstellung der durchschnittlichen Laufzeiten für alle räumlichen Zustän-
de für 256 Features. Ein Graph steht für die SSE, die anderen je für ein Level (basiert auf den
Daten in Tabelle C.26).
Um herauszufinden, welcher Teil der Implementierung den größten Einfluss auf die
Laufzeit hat, wurde noch eine zusätzliche Untersuchung vorgenommen. Hierbei soll-
te ausgeschlossen werden, dass das Bilden der räumlichen Pyramide und der Fea-
turesignaturen zu einem zu großen Aufwand führt und den Laufzeitvorteil der par-
allelen Implementierung, und damit auch des Spatial-Pyramid-Ansatzes, zunichte
macht (siehe S. 42). Dazu wurden die beiden logischen Bestandteile, das Bilden
der räumlichen Pyramide und der Vergleich, voneinander getrennt beobachtet. In
Stratosphere gibt es keine Schnittstelle, mit der man ermitteln kann, welcher Be-
standteil einer Implementierung welche Ressourcen verbraucht hat, wie zum Beispiel
CPU-Cycles, Speicher, Größe der Auslagerungsdatei oder Netzwerkverkehr. Daher
wurde die Implementierung zweimal getrennt aufgerufen. Beim ersten Aufruf wur-
den die Featuresignaturen gebildet und ausgegeben, und beim zweiten wurden diese
Daten eingelesen und nur der Vergleich durchgeführt (Tabelle C.25). Diese Untersu-
chung wurde mit 1.024 räumlichen Zuständen durchgeführt und der Mittelwert aus
5 Durchläufen je Untersuchung gebildet. In der Summe ergeben die beiden Werte
dieser Untersuchung nicht dieselben Werte wie in dem Experiment zuvor, in dem der
5.5. EVALUATION OZEANDATEN 63
gesamte Prozess als Ganzes durchgeführt wurde (Tabelle C.11), weil es durch den
zweifachen Start von Stratosphere einen gewissen Overhead gibt. Außerdem müssen
die Daten am Ende des ersten Programms (Aktion: Pyramidisieren) weggeschrie-
ben und beim Start des zweiten Programms (Aktion: Vergleich) wieder eingelesen
werden. Wie in der Tabelle zu erkennen ist, hat die Wahl der Parameter einen Ein-
fluss auf die mittlere Laufzeit der Pyramidisierung (Abbildung 5.5). Die Laufzeit der
Pyramidisierung ist aber eher moderat und die Parameter führen zu eher geringen
Erhöhungen der Laufzeiten. Beim Vergleich wirkt sich der Parameter der Level -
jedenfalls in den Leveln in denen er die Laufzeit deutlich erhöht - linear aus. Er
führt also zu einer ungefähren Vervierfachung der Laufzeit (für den Vergleich). Die
Erhöhung der Featureanzahl selbst hat nur einen geringen Einfluss, soweit dies in
den Messungen nachvollziehbar ist (Abbildung 5.6). Die Erhöhung dieses Parameters
führt zu keiner Verdopplung der Laufzeiten, wie man das erwarten könnte. Wie zu
erwarten, hat die Wahl der Parameter auf die Pyramidisierung und den Vergleich
Einfluß. Der Anteil der Pyramidisierung an der Gesamtberechnung ist aber eher
gering. Bei Konfigurationen mit hohen Parameterwerten liegt er teilweise deutlich
unter 10%10. Es zeigt sich also, dass die Ver-L-fachung der Datenmenge beim Bilden
der Pyramide zu keinen Nachteilen bei der Implementierung führt und der Hauptteil
der Laufzeit im Bereich des eigentlichen Vergleiches liegt.
10Betrachtet man die getrennten Teile Pyramidisierung und Vergleich in Summe.
64 KAPITEL 5. EVALUIERUNG
0
5
10
15
20
25
30
35
1 2 3 4 5 6 7 8
Lauf
zeit
in s
Featureexponent
Level 1Level 2Level 3Level 4Level 5Level 6
Abbildung 5.5: Durchschnittliche Laufzeiten nur für die Pyramidisierung (basiert auf den Daten
in Tabelle C.25).
0
50
100
150
200
250
300
350
400
450
500
1 2 3 4 5 6 7 8
Lauf
zeit
in s
Featureexponent
Level 1Level 2Level 3Level 4Level 5Level 6
Abbildung 5.6: Durchschnittliche Laufzeiten nur für den Vergleich (basiert auf den Daten in Ta-
belle C.25).
5.5.1 Güte des Spatial-Pyramid-Ansatzes
Für diese Untersuchung wurde aus den Ergebnissen beider Implementierungen für
jeden räumlichen Zustand der jeweils direkte Nachbar ermittelt, wobei natürlich
5.5. EVALUATION OZEANDATEN 65
derselbe räumliche Zustand als direkter Nachbar ausgeschlossen wurde. Wenn der
direkte Nachbar identisch ist zwischen beiden Implementierungen, wurde dies ge-
wertet, woraus sich die in Tabelle C.29 verzeichnete prozentuale Güte über alle
räumlichen Zustände für die Ozeandaten ergibt. Im Bereich mit wenigen Levels und
wenigen Features ist die Güte des Spatial-Pyramid-Ansatzes nicht so hoch. Doch ab
Level 4 mit 8 Features (Featurexponent: 3) liegt die Güte immer über 50 Prozent
und steigt nur noch relativ wenig mit steigenden Levels oder Featureanzahl (Abbil-
dung 5.7).
0
20
40
60
80
100
1 2 3 4 5 6 7 8
Güt
e in
Pro
zent
Featureexponent
Level 1Level 2Level 3Level 4Level 5Level 6
Abbildung 5.7: Grafische Darstellung der Güte in Prozent über alle Level und Features (basiert
auf den Daten in Tabelle C.29).
Zur weiteren Untersuchung der Ergebnisse wurde für die räumlichen Zustände, de-
ren direkter Nachbar sowohl für die SSE als auch die Spatial-Pyramid nicht derselbe
waren, die Abweichung der beiden direkten Nachbarn zueinander ermittelt. Es wur-
den also für einen räumlichen Zustand (i) der direkte Nachbar der SSE (k) und
der direkte Nachbar der Spatial-Pyramid (l) genommen und für beide die Distanz
(d(i, k), d(i, j)) ermittelt. Dann wurde gemessen, wie groß die Abweichung dieser bei-
den Distanzen zueinander ist. Dies wurde für alle Experimente der Spatial-Pyramid
wiederholt (Abbildung C.12). In der Darstellung sind die Abweichungen der direk-
66 KAPITEL 5. EVALUIERUNG
ten Nachbarn als Histogramme je Konfiguration der Spatial-Pyramid zu sehen, mit
jeweils 11 Bins in einem Histogramm. Der Bin mit dem Index 0 enthält die Elemen-
te, die komplett übereinstimmen und keinerlei Abweichung zeigen, also bei denen
die direkten Nachbarn übereinstimmen11. In den anderen Bins sind die räumlichen
Zustände entsprechend ihrer prozentualen Abweichung der Distanzen voneinander
dargestellt. So sind in dem Bin mit dem Index 1 die Zustände, die bis zu 10% Abwei-
chung aufweisen, in Bin 2 diejenigen mit bis zu 20% usw. Es ist zu sehen, wie in den
Bereichen mit wenigen Leveln und Features die Abweichung der direkten Nachbarn
zueinander noch sehr hoch ist, denn viele direkte Nachbarn haben über 80% Abwei-
chung. Ungefähr ab Level 3 und der Featureanzahl 8 (Featureexponent: 3) treten
kaum noch hohe Fehler auf. Der Hauptteil der Fehler liegt bei diesen Konfigurationen
unter 10%.
5.5.2 Performance des Spatial-Pyramid-Ansatzes
Um die Performance der beiden Implementierungen und Ansätze miteinander zu
vergleichen, wurde eine exemplarische Konfiguration mit den gemittelten Zeiten der
SSE-Implementierung verglichen (Tabelle C.27, Abbildung 5.8). Mit 4 Level und
8 Feature (Featureexponent: 3) wurde eine Konfiguration gewählt, die eine Güte
von über 50% hat. Andere Konfigurationen mit mehr Level oder Features steigern
die Güte nicht wesentlich. In den Daten sieht man, dass bei einer immer größer
werdenden Eingabemenge räumlicher Zustände die Implementierung des Spatial-
Pyramid-Ansatzes immer besser wird und sich das Verhältnis der Laufzeit zwischen
den beiden Implementierungen immer mehr zu Gunsten der Implementierung des
Spatial-Pyramid-Ansatzes verschiebt. Der Spatial-Pyramid-Ansatz ist in der Konfi-
guration mit 1.024 räumlichen Zuständen bis zu 9-mal schneller als die SSE Imple-
mentierung (Abbildung 5.9). Desto größer die Menge der räumlichen Zustände ist
desto deutlicher tritt hier die Effizienz des Spatial-Pyramid-Ansatzes hervor.
11Dies sind die gleichen räumlichen Zustände, die in der Tabelle C.29 die Güte in Prozent darstellen.
5.5. EVALUATION OZEANDATEN 67
0
50
100
150
200
250
1 2 4 8 16 32 64 128 256 512 1024
Lauf
zeit
in s
räumliche Zustände
SSESpatial-Pyramid: Level 4, 8 Features
Abbildung 5.8: Vergleich der Laufzeiten der SSE gegen eine Beispielkonfiguration des Spatial-
Pyramid-Ansatzes (4 Level, 8 Features). (basiert auf den Daten in Tabelle C.27)
Außerdem tritt deutlich hervor, wie sich die Parallelisierung und die Reduzierung
der Detailvergleiche pro paarweisem Vergleich der räumlichen Zustände auf die Lauf-
zeit auswirkt. Dazu wird die Anzahl der paarweisen Vergleiche räumlicher Zustände
ermittelt, die in Abhängigkeit von der Anzahl der räumlichen Zustände quadratisch
wächst. Die Anzahl der Vergleiche Anzcomp kann aus der Anzahl der räumlichen
Zustände z berechnet werden:
Anzcomp(z) =z2 + z
2
Mit der Anzahl der Vergleiche kann nun durch die gemittelte Dauer der Berechnung
geteilt werden, um die Zeit pro Vergleich zweier räumlicher Zustände zu ermitteln.
Zu sehen ist (Tabelle C.31), wie mit steigender Anzahl räumlicher Zustände in der
Eingabe die Dauer pro paarweisen Vergleich stetig sinkt.
68 KAPITEL 5. EVALUIERUNG
1
2
3
4
5
6
7
8
9
10
1 2 4 8 16 32 64 128 256 512 1024
Zei
tver
hältn
is d
er b
eide
n Im
plem
entie
rung
en
räumliche Zustände
Geschwindigkeitsvorteil Spatial-Pyramid zu SSE
Abbildung 5.9: Verhältnis der Laufzeiten zwischen Spatial-Pyramid-Ansatz und SSE. Es ist das
Verhältnis dargestellt, um wieviel die exemplarische Konfiguration des Spatial-Pyramid-Ansatzes
(4 Level, 8 Features) schneller ist als die SSE für die gleiche Eingabemenge. (basiert auf den Daten
in Tabelle C.27)
Diese bessere Performance pro paarweisen Vergleich hängt wohl mit Stratosphere
selbst zusammen. Der Overhead beim Verteilen der Daten und Operationen erreicht
mit steigenden Datensätzen einen geringeren Anteil an der Gesamtlaufzeit. Solange
die gesamte Datenmenge immer in den Hauptspeicher passt, wird die Dauer pro
Vergleich sinken, da Stratosphere die Daten nicht auslagern muss. Sobald die Be-
grenzung des Hauptspeichers erreicht wird, sollte in zukünftigen Experimenten zu
sehen sein, wie sich dieser Mittelwert pro Vergleich an einer Schranke einpendelt.
Im Vergleich der durchschnittlichen Dauer pro paarweisen Vergleich zweier räumli-
cher Zustände mit der SSE kann man erkennen, dass unter fast allen Konfigurationen
die Vergleiche deutlich schneller vonstatten gehen. Das Level 6 teilt die räumlichen
Zuständen in zu viele Teilbereiche auf, so dass in Zusammenhang mit der Anzahl
der Features (hier: 256) sehr viele einzelne Vergleiche pro räumlichen Zustand statt-
finden. Die Konfiguration mit dem Level 6 zeigt daher auch ein schlechteres Lauf-
zeitverhalten als die SSE-Implementierung. Aber obwohl in dem Level 6 (für 256
Features) ungefähr ∼ 20-mal soviele Vergleiche über die Histogramme und Teilbe-
reiche (Tabelle A.1) pro paarweisen Vergleich durchgeführt werden als bei der SSE,
5.5. EVALUATION OZEANDATEN 69
zeigt sich das nicht in den durchschnittlichen Laufzeiten. Die effiziente Implemen-
tierung und der modulare Aufbau des PACT-Programmes sorgen für eine effiziente
parallele Verarbeitung der Daten.
5.5.3 Qualität des Spatial-Pyramid-Ansatzes
In weiteren Untersuchungen wurden die Ergebnisse der Vergleiche, also die Di-
stanzmatrizen der SSE-Implementierung gegen die Implementierung des Spatial-
Pyramid-Ansatzes verglichen. Dabei wurde für die jeweils ähnlichsten zehn Ele-
mente ermittelt, wieviele davon sich auch in der Menge der ähnlichsten zehn in
der anderen Implementierung befinden. Die Untersuchung hat Ähnlichkeit zur Güte
(Abschnitt 5.5.1), soll aber zusätzlich noch ermitteln, ob die ähnlichsten zehn Nach-
barn ebenfalls übereinstimmen.
Man erkennt, wie die Ähnlichkeit mit steigender Anzahl der Level und Features ins-
gesamt zunimmt (Abbildung C.13). Beide Implementierungen haben immer mehr
gemeinsame Nachbarn, wenn die Anzahl der Features und das Level steigen. In Ab-
bildung 5.10 kann man sehen, dass sich die Qualität deutlich anders verhält als die
Güte (Abbildung 5.7). Die Güte ist nahezu identisch für die Level 2-6. Ab dem Fea-
tureexponenten 3 gibt es kaum noch einen Zuwachs der Güte und diese ist bei knapp
unter 60%. Für die Qualität kann man sagen, dass sich die verschiedenen Level gut
unterscheiden lassen. Aber auch hier kann man sehen, dass die Menge der Features
ab dem Featureexponenten 3 für die Level 3-6 keinen deutlichen Qualitätszuwachs
mehr bringen. Es zeigt sich, dass der Einfluss der Features auf die Qualität für die
Ozeandaten relativ geringen Einfluss hat. Insgesamt betrachtet sieht man, dass die
Qualität der Ergebnisse für den Spatial-Pyramid-Ansatz im Vergleich zur SSE steigt
und die räumliche Aufteilung der Pyramide den wesentlichsten Einfluss hat.
Da bei späteren Clustering-Verfahren, die Cluster nach der Gruppierung der Ähn-
lichkeiten gebildet werden, ist es wichtig zu sehen, dass nicht nur die direkten Nach-
barn (Abschnitt 5.5.1) sondern auch die Ähnlichkeit einer Anzahl von Nachbarn
übereinstimmt. Die verschiedenen Level machen für die Qualität der Ergebnisse
einen teilweise deutlichen Unterschied aus. Eine Abschätzung zwischen Kosten und
70 KAPITEL 5. EVALUIERUNG
Nutzen, also Laufzeit und Qualität, zeigt sich besonders stark, da die Qualität der
Ergebnisse doch erheblich voneinander abweichen kann.
0
20
40
60
80
100
1 2 3 4 5 6 7 8
Qua
lität
in P
roze
nt
Featureexponent
Level 1Level 2Level 3Level 4Level 5Level 6
Abbildung 5.10: Grafische Darstellung der Qualität in Prozent über alle Level und Features (basiert
auf den Daten in Tabelle C.30).
5.6 Evaluation der synthetischen Daten
Die Messwerte für den Spatial-Pyramid-Ansatz im Anhang (Tabelle D.1, Abbil-
dung 5.11) zeigen, dass die Dauer einer Berechnung sich ähnlich verhält wie bei den
Ozeandaten (Abschnitt 5.5). Das Verhältnis zwischen den einzelnen Erhöhungen
(Level oder Feature) steigt ab einem gewissen Punkt. Es ist auch erkennbar, dass
die derzeitige Implementierung des Spatial-Pyramid-Ansatzes nicht unabhängig von
der Größe eines räumlichen Zustandes ist, sondern dass die Größe des räumlichen
Zustandes auch die Laufzeit der Implementierung erhöht. Die Größe der räumlichen
Zustände hat aber nur Einfluß auf die Pyramidisierung, da nur diese den gesamten
räumlichen Zustand einlesen muss. Der Vergleich der Featuresignaturen ist immer
konstant bei gleicher Konfiguration, da die Featuresignaturen auch immer gleich
groß sind.
Leider konnten bei der Evaluation der synthetischen Daten nicht alle Messwerte ge-
neriert werden, da Stratosphere bei den Messungen der SSE-Implementierung keine
5.7. FAZIT 71
Ergebnisse lieferte. Diese Messungen wurden wiederholt gestartet, ohne dass nach ei-
ner akzeptablen Zeitspanne ein Ergebnis sichtbar war. Auch in den Log-Dateien von
Stratosphere war nicht erkennbar, ob es einen Fehler oder ähnliches gegeben hatte.
Das Experiment wurde bis zu 36 Stunden laufen gelassen, ohne dass die Ausführung
zu einem Ende gekommen war. Daher war es leider nicht möglich, die Experimente
in aller Vollständigkeit abzuschließen. Es wurde nicht auf die noch nicht freigegebene
Entwicklungsversion umgestellt, sondern bei der restlichen Umsetzung der Aufgabe
nur die offiziell freigegebene Version benutzt. Bei der Entwicklungsversion hätten
andere Probleme auftreten können, da neue Features noch nicht vollständig getestet
wären, oder auch die Schnittstelle sich verändert hätte.
0
200
400
600
800
1000
1200
1400
1600
1 2 3 4 5 6 7 8
Lauf
zeit
in s
Featureexponent
Level 1Level 2Level 3Level 4Level 5Level 6
Abbildung 5.11: Durchschnittliche Laufzeit für die synthetischen Daten für 1.000 Zustände für alle
Level und Features (basiert auf den Daten in Tabelle D.1).
5.7 Fazit
Im Zuge der Arbeit wurde gezeigt, dass der Spatial-Pyramid-Ansatz mehrere Vor-
teile gegenüber der SSE bietet. Dazu gehören, dass mit der räumlichen Pyramide
und der Aufteilung der Werte in einen Featureraum die Anzahl der Vergleiche pro
Vergleich eines räumlichen Zustandes drastisch gesenkt werden kann. Mittels der
Reduzierung der Dimensionalität kann sehr schnell eine Ähnlichkeitsmatrix berech-
72 KAPITEL 5. EVALUIERUNG
net werden, die von nachfolgenden Clusteringalgorithmen benutzt werden kann, um
Gruppen von ähnlichen Zuständen zu bilden. Ist die räumliche Pyramide einmal
gebildet, hängt der Vergleich zweier Zustände nur noch von der Anzahl der Features
und der Größe der Pyramide ab.
Im Zuge der Experimente mit den Ozeandaten wurden die parallelen Implementie-
rungen beider Methoden zur Generierung von Ähnlichkeiten beziehungsweise Di-
stanzen gegeneinander verglichen. Es wurde gezeigt, dass sich bei der Implementie-
rung des Spatial-Pyramid-Ansatzes die Laufzeit nur entsprechend der Erwartungen
erhöht, wenn sich zum Beispiel mit einer Verdopplung der Features auch die Anzahl
der Vergleiche verdoppelt.
Der Vergleich der Ergebnisse aus beiden Implementierungen hat gezeigt, dass bei
Konfigurationen von mehr als 4 Leveln und 8 Features eine Güte der Ergebnisse der
Spatial-Pyramid von über 50% gegenüber der SSE erreicht werden kann. Bei einer
geeigneten Wahl der Eingabeparameter Level und Anzahl der Feature ergibt sich
ein Kosten-Nutzen-Verhältnis zwischen Güte und Laufzeit. Dieses Kosten-Nutzen-
Verhältnis zeigt, dass bei einer Güte von über 50% (ab Level 4 und bei mehr 8
Features), die Implementierung des Spatial-Pyramid-Ansatzes bis zu 9-mal schnel-
ler als die der SSE ist (Tabelle C.27). Dadurch, dass die Güte ab einem gewissen
Punkt (mehr als Level 4 und 8 Features) eine Erhöhung der Parameter keinen deut-
lichen zusätzlichen Gewinn gegenüber der zusätzlichen Laufzeit mehr ergibt. Bei Be-
trachtung dieser Parameter konnte gezeigt werden, dass das Zeitverhältnis zwischen
der SSE-Implementierung und der Implementierung des Spatial-Pyramid-Ansatzes
mehr und mehr für den Spatial-Pyramid-Ansatz spricht, da dieser bei einer steigen-
den Eingabemenge eine immer bessere Performance zeigt.
Für die Qualität konnte im Gegensatz dazu gezeigt werden, dass eine Übereinstim-
mung der zehn ähnlichsten Nachbarn von fast 90% für das Level 6 erreicht werden
kann. Da die Berechnung des Spatial-Pyramid-Ansatzes ab Level 6 fast durchge-
hend schlechter war als die SSE, kann man für das Level 6 davon sprechen, dass
eine negatives Verhältnis von Kosten gegenüber dem Nutzen steht. Jedoch zeigt die
Qualität, dass man sehr genau die Ergebnisse abstufen kann unter welchen man die
Ähnlichkeitsmatrix generieren könnte. Die anderen Level (ab circa Level 3 und 8
5.7. FAZIT 73
Features erreichen eine Qualität von über 50%) kann man so einstufen, dass man
pro Level in etwa eine 10%-ige Steigerung der Qualität erreichen für eine knappe
Vervierfachung der Laufzeit bekommen kann. Die Anzahl der Features erhöht die
Qualität nur um wenige Prozent. Daher ist ihr Nutzen gegenüber der ungefähren
Verdopplung der Laufzeit kaum darzustellen.
Es hat sich auch gezeigt, dass die Wahl der Parameter Level und Anzahl der Featu-
res einen starken Einfluss auf die Laufzeit, die Güte und die Qualität der Ergebnisse
haben können. Während mit der Anzahl der Features die Laufzeit linear wächst und
mit der Anzahl der Level sich vervierfacht, konnte man sehen, dass es bezüglich des
Levels und der Features eine Schranke in der Güte gab, die die Güte nicht merklich
weiter steigen ließen. Für die Qualität war diese Schranke nur in den Features zu
sehen. In zukünftigen Anwendungen sollte vor dem Anwenden des Ansatzes auf eine
große Menge von Daten an einem Teilsatz der Daten die beste Einstellung ermittelt
werden, bevor man die komplette Ähnlichkeitsmatrix berechnet. Eine generelle Ab-
schätzung, welche Parameter ein gutes Ergebnis liefern, kann an dieser Stelle nicht
gegeben werden, da dies von den Dimensionen der räumlichen Zustände und auch
von der Art der Daten, also dem Kontext, abhängt.
Kapitel 6
Ausblick
Im folgenden sollen Punkte benannt werden, die bei weiteren Untersuchungen des
Spatial-Pyramid-Ansatzes berücksichtigt werden sollten. Diese Punkte resultieren
aus Erfahrungen im Umgang mit der Implementierung und der Thematik als Gan-
zes.
Zuerst wäre hier die Erkundung der Parameter für einen Kontext zu nennen. Wie in
der Arbeit gezeigt haben die Parameter Feature und Level einen recht unterschiedli-
chen Einfluss auf die verschiedensten Metriken mit denen man die Implementierung
messen kann. Bevor man die Daten und deren Kontext erkundet hat, ist es schwer
sich festzulegen, welche Parameter am passendsten sind, um gute Ergebnisse zu
erzielen. Betrachtet man die Laufzeit, so kann man als obere Schranke für die Pa-
rameter sehen, dass die Anzahl der Vergleiche nicht die Anzahl der Punkte eines
räumlichen Zustandes überschreiten sollte. Zukünftig könnte man untersuchen, in-
wieweit man mit einem gegebenen Satz an räumlichen Zuständen automatisch gut
passende Parameter findet, die eine entsprechende Qualität haben und bei denen
die Laufzeit, zum Beispiel gegenüber der SSE, deutlich reduziert werden kann.
Weiterhin soll hier auf die Featuregenerierung eingegangen werden. Die in dieser
Arbeit benutzte Methode erstellt aus jedem Punkt genau ein Feature. Theoretisch
ist es wünschenswert, den Wertebereich in möglichst viele Intervalle zu unterteilen
und dabei die Featureintervalle nicht zu groß werden zu lassen, so dass sich gut
unterscheidbare Features herausbilden. Daher ist es je nach Kontext der räumli-
74
75
chen Zustände notwendig, sehr viele Features zu generieren. Diese Ermittlung von
Features über Intervalle kann, wie oben gezeigt (Abschnitt 5.5), zu einer nicht un-
beträchtlichen Erhöhung der Laufzeit und der Komplexität der Implementierung
führen. Je nach Kontext der Implementierung können aber auch andere Verfahren
zur Featuregenerierung in Betracht kommen, wie zum Beispiel Verfahren zur Kan-
tenerkennung. Der Vorteil der in dieser Arbeit benutzten Methode ist, dass sie auf
jedem Punkt unabhängig vom Kontext ausgeführt werden kann. Hierfür muss jedoch
jeder räumliche Zustand einmal komplett eingelesen werden. Andere Methoden der
Featureermittlung müssten eventuell vor der parallelen Implementierung ausgeführt
werden, da sie Features nur aus dem Kontext der umliegenden Punkte oder nur
aus der Betrachtung des gesamten räumlichen Zustandes ermitteln können. Diese
Features müssten dann separat gespeichert werden. Solch eine Generierung kann
derzeit in Stratosphere nicht umgesetzt werden, da die eingebauten FileReader Da-
teien nur blockweise einlesen. Wenn die bisherige Methode der Featuregenerierung
ersetzt werden würde, könnten unter Umständen einerseits weniger Features benutzt
werden. Andererseits könnten auch für einen Messwert mehrere Features vorliegen,
wenn mehrere Methoden der Featureermittlung nacheinander ausgeführt werden.
Einer der Nachteile der bisherigen Implementierung ist, dass aus einem vorliegenden
räumlichen Zustand jeder einzelne Punkt in einen Datensatz eingelesen wird und für
jeden Datensatz die Position in den Teilbereichen errechnet wird. Die darauf folgen-
de Durchführung der Reduce-Operation führt hier zu einer sehr großen Datenmenge,
auf die ein globaler Schlüssel berechnet werden muss, um die Nutzerfunktionen der
Reduce-Operation aufzurufen. Es konnte gezeigt werden, dass die Bildung der Fea-
turesignaturen sich nicht wesentlich auf die Laufzeit der parallelen Spatial-Pyramid-
Implementierung auswirkt. Eine theoretische Überlegung ist aber, dass das Generie-
ren der Featuresignaturen eigentlich nur Operationen enthalten sollte, die pro Datei
verfahren. Daher erscheint es sinnvoll, für diesen Teil der Bearbeitung eine einzige
Input-Operation zu benutzen und sich diese Daten-Parallelität zunutze zu machen
[27]. Diese Operation sollte pro Knoten eine Datei gesamthaft einlesen können. In
dieser Operation könnte die Bildung des Quadtree, die Quantisierung der Teilbe-
reiche und die Bildung der Signaturen pro Knoten absolviert werden. Dafür wäre
76 KAPITEL 6. AUSBLICK
dann keine Reduce-Operation mehr notwendig, und das Einlesen der Daten könnte
trotzdem verteilt mit einer Datei pro Knoten erfolgen. Dies setzt natürlich voraus,
dass jeder Knoten genügend Speicher hat, um eine ganze Quelldatei einzulesen und
zu verarbeiten. Bei einer hohen Dimensionalität der Eingabedaten könnte dies auch
zu einem Problem werden. Auch könnte bei einer solchen Methode die oben bespro-
chene Methode der Featuregenerierung innerhalb des Einlese-Vorgangs geschehen,
da ja die komplette Datei innerhalb einer Operation zur Verfügung steht.
Was leider während der Implementierung des Spatial-Pyramid-Ansatzes in Strato-
sphere auffiel, war, dass sich schwer feststellen ließ, welche Ansätze in der Imple-
mentierung dieses Anwendungsfall die beste Performance liefern. Es konnten nur
lokal Beobachtungen gemacht werden, die sich zumeist auch nur auf die Laufzeit
beschränkten. Im Cluster waren keine Beobachtungen außer der Laufzeit möglich,
da jeder Knoten einzeln betrachtet werden müsste. Es gibt keine Schnittstelle, mit
der Optimierungen des Code oder des PACT-Planes beobachtet werden können. So
fehlen zuverlässige Metriken im System, um verschiedene Ansätze der Implemen-
tierung zu untersuchen. So konnte nicht festgestellt werden, ob eine Konfiguration
zum Beispiel besonders viel Netzwerkverkehr verursacht, besonders viele Schlüssel
erzeugt werden mussten oder Knoten sogar lange Pausen hatten, weil sie auf die
Beendigung einer vorhergehenden Operation warten mussten. Es wäre in Zukunft
wünschenswert, wenn in Stratosphere in einem PACT-Plan solche Metriken gene-
rierbar wären, um bei Entwicklung des optimalen Planes die notwendigen Metriken
zur Verfügung zu haben.
Derzeit wurde gezeigt, dass die Implementierung gut mit den Ozeandaten funktio-
niert und für diese auch einen deutlichen Geschwindigkeitsvorteil bringt. Zukünftig
sollten größere Datensätze mit dem Ansatz evaluiert werden, um auch für diese die
Schnelligkeit nachzuweisen. Diese Datensätze sollten nicht nur mehr räumliche Zu-
stände umfassen, sondern auch in ihren Dimensionen größer sein, denn so kann sich
die Effizienz der räumlichen Pyramide besser zeigen, wenn die den Vergleichsvektor
stark reduzieren kann. Mit größeren Datensätzen lässt sich dann auch herausfin-
den, wie das Verhältnis des Geschwindigkeitsvorteils sich weiter entwickelt und ob
es Steigerungen diesbezüglich gibt.
77
Nachdem die Güte und die Schnelligkeit der Implementierung gezeigt wurden, könn-
te als nächster Schritt die Umsetzung der Ähnlichkeitsmatrix in einem Clustering-
verfahren erfolgen, idealerweise auch in einer parallelen Implementierung. Mit einem
parallelisierbaren Clusteringverfahren könnten Geowissenschaftler in Zukunft große
Datenmengen gruppieren. Diese Cluster könnten dann von diesen Wissenschaftlern
untersucht werden, um Zusammenhänge in den Modellen der Umweltsysteme zu
untersuchen oder neue Modelle zu entwickeln.
Anhang A
Anzahl der Vergleiche
Level
Featureexponent 1 2 3 4 5 6
1 2 10 42 170 682 2.730
2 4 20 84 340 1.364 5.460
3 8 40 168 680 2.728 10.920
4 16 80 336 1.360 5.456 21.840*
5 32 160 672 2.720 10.912 43.680*
6 64 320 1.344 5.440 21.824* 87.360*
7 128 640 2.688 10.880 43.648* 174.720*
8 256 1.280 5.376 21.760* 87.296* 349.440*
Tabelle A.1: Auflistung der Anzahl der einzelnen Vergleiche pro räumlichen Zustand in Abhängig-keit von der Größe des Histogramms und des Levels
78
Anhang B
Tabellen für das
Implementierungsbeispiel
0 1 3 4 21 2 1 2 42 3 3 3 23 1 4 4 1
Tabelle B.1: Inhalt der Beispiel-datei ’file1.asc’
0 3 3 1 21 4 1 3 12 3 1 3 23 1 1 4 2
Tabelle B.2: Inhalt der Beispiel-datei ’file2.asc’
file1.asc 1 4, 2, 0, 1, 1, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 1file1.asc 3 4, 1, 0, 2, 1, 0, 1, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, 0, 0, 0, 0file1.asc 4 4, 0, 2, 1, 1, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 1, 1, 0file1.asc 2 4, 1, 2, 0, 1, 0, 0, 0, 1, 1, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0
Tabelle B.3: Signaturen aller Level der Datei file1.asc. Die Spalten sind: Name, Level, Featuresi-gnatur.
79
80 ANHANG B. TABELLEN FÜR DAS IMPLEMENTIERUNGSBEISPIEL
file2.asc 1 6, 1, 2, 3, 0, 0, 0, 1, 0, 0, 1, 0, 1, 0, 1, 0, 0, 1, 1, 0, 0file2.asc 3 5, 2, 1, 1, 1, 1, 1, 0, 0, 0, 0, 1, 0, 1, 0, 1, 0, 0, 0, 0, 0file2.asc 4 2, 1, 0, 0, 1, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0file2.asc 2 3, 0, 1, 0, 2, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1
Tabelle B.4: Signaturen aller Level der Datei file2.asc. Die Spalten sind: Name, Level, Featuresi-gnatur.
Level Gewichtungsfaktor des Levels für L = 3
0 1/(2(2− 0)) = 1/(22) = 1/4 = 0.25
1 1/(2(2− 1)) = 1/(21) = 1/2 = 0.50
2 1/(2(2− 2)) = 1/(20) = 1/1 = 1.00
Tabelle B.5: Gewichtungsfaktoren je Level fürL = 3
file1.asc file2.asc 1 2.50file1.asc file2.asc 3 3.25file1.asc file2.asc 2 2.25file1.asc file2.asc 4 1.25
Tabelle B.6: Featuredistanzen
Anhang C
Evaluation Ozeandaten
In diesem Abschnitt werden alle Daten aus den Messungen wiedergegeben. Soweit nicht andersspezifiziert sind alle Werte in Millisekunden angegeben. Der Parameter Featureexponent gibt an,dass 2Featureexponent Features für die Messung ermittelt wurden.
C.1 Messungen Laufzeit für den Spatial-Pyramid-Ansatz
C.1.1 Graphen für die durchschnittlichen Laufzeiten
3
3.5
4
4.5
5
5.5
6
6.5
7
7.5
8
1 2 3 4 5 6 7 8
Lauf
zeit
in s
Featureexponent
Level 1Level 2Level 3Level 4Level 5Level 6
SSE
Abbildung C.1: Grafische Darstellung der durchschnittlichen Laufzeit für 1 räumlichen Zustand(basiert auf den Daten in Tabelle C.1).
81
82 ANHANG C. EVALUATION OZEANDATEN
3
4
5
6
7
8
9
10
1 2 3 4 5 6 7 8
Lauf
zeit
in s
Featureexponent
Level 1Level 2Level 3Level 4Level 5Level 6
SSE
Abbildung C.2: Grafische Darstellung der durchschnittlichen Laufzeit für 2 räumliche Zustände(basiert auf den Daten in Tabelle C.2).
3
3.5
4
4.5
5
5.5
1 2 3 4 5 6 7 8
Lauf
zeit
in s
Featureexponent
Level 1Level 2Level 3Level 4Level 5Level 6
SSE
Abbildung C.3: Grafische Darstellung der durchschnittlichen Laufzeit für 4 räumliche Zustände(basiert auf den Daten in Tabelle C.3).
C.1. MESSUNGEN LAUFZEIT FÜR DEN SPATIAL-PYRAMID-ANSATZ 83
3
3.5
4
4.5
5
5.5
6
1 2 3 4 5 6 7 8
Lauf
zeit
in s
Featureexponent
Level 1Level 2Level 3Level 4Level 5Level 6
SSE
Abbildung C.4: Grafische Darstellung der durchschnittlichen Laufzeit für 8 räumliche Zustände(basiert auf den Daten in Tabelle C.4).
3
3.5
4
4.5
5
5.5
1 2 3 4 5 6 7 8
Lauf
zeit
in s
Featureexponent
Level 1Level 2Level 3Level 4Level 5Level 6
SSE
Abbildung C.5: Grafische Darstellung der durchschnittlichen Laufzeit für 16 räumliche Zustände(basiert auf den Daten in Tabelle C.5).
84 ANHANG C. EVALUATION OZEANDATEN
3.2
3.4
3.6
3.8
4
4.2
4.4
4.6
4.8
5
1 2 3 4 5 6 7 8
Lauf
zeit
in s
Featureexponent
Level 1Level 2Level 3Level 4Level 5Level 6
SSE
Abbildung C.6: Grafische Darstellung der durchschnittlichen Laufzeit für 32 räumliche Zustände(basiert auf den Daten in Tabelle C.6).
3
3.5
4
4.5
5
5.5
6
6.5
7
1 2 3 4 5 6 7 8
Lauf
zeit
in s
Featureexponent
Level 1Level 2Level 3Level 4Level 5Level 6
SSE
Abbildung C.7: Grafische Darstellung der durchschnittlichen Laufzeit für 64 räumliche Zustände(basiert auf den Daten in Tabelle C.7).
C.1. MESSUNGEN LAUFZEIT FÜR DEN SPATIAL-PYRAMID-ANSATZ 85
3
4
5
6
7
8
9
10
11
12
1 2 3 4 5 6 7 8
Lauf
zeit
in s
Featureexponent
Level 1Level 2Level 3Level 4Level 5Level 6
SSE
Abbildung C.8: Grafische Darstellung der durchschnittlichen Laufzeit für 128 räumliche Zustände(basiert auf den Daten in Tabelle C.8).
0
5
10
15
20
25
30
35
1 2 3 4 5 6 7 8
Lauf
zeit
in s
Featureexponent
Level 1Level 2Level 3Level 4Level 5Level 6
SSE
Abbildung C.9: Grafische Darstellung der durchschnittlichen Laufzeit für 256 räumliche Zustände(basiert auf den Daten in Tabelle C.9).
86 ANHANG C. EVALUATION OZEANDATEN
0
10
20
30
40
50
60
70
80
90
100
1 2 3 4 5 6 7 8
Lauf
zeit
in s
Featureexponent
Level 1Level 2Level 3Level 4Level 5Level 6
SSE
Abbildung C.10: Grafische Darstellung der durchschnittlichen Laufzeit für 512 räumliche Zustände(basiert auf den Daten in Tabelle C.10).
0
50
100
150
200
250
300
350
400
1 2 3 4 5 6 7 8
Lauf
zeit
in s
Featureexponent
Level 1Level 2Level 3Level 4Level 5Level 6
SSE
Abbildung C.11: Grafische Darstellung der durchschnittlichen Laufzeit für 1024 räumliche Zustände(basiert auf den Daten in Tabelle C.11).
C.1. MESSUNGEN LAUFZEIT FÜR DEN SPATIAL-PYRAMID-ANSATZ 87
C.1.2 Tabellen für durchschnittlichen Laufzeiten
Level
Featureexponent 1 2 3 4 5 6
1 7.126 4.124 3.838 3.982 3.678 3.537
2 4.764 4.525 4.014 3.929 3.929 3.415
3 4.713 4.354 3.824 3.630 3.694 3.383
4 4.652 3.566 3.913 3.652 3.559 3.383
5 4.297 4.115 3.595 3.673 3.441 3.721
6 4.542 3.851 3.716 3.356 3.529 3.476
7 4.459 3.730 3.627 3.434 3.470 3.258
8 3.992 3.796 3.713 3.546 3.727 3.388Tabelle C.1: Durchschnittliche Laufzeit der Berechnung für 1 räumlichen Zustand
Level
Featureexponent 1 2 3 4 5 6
1 3.890 3.681 3.595 3.888 3.608 3.488
2 3.737 3.586 3.729 3.439 3.926 3.316
3 4.038 3.654 3.446 3.492 3.736 3.791
4 4.073 3.719 3.841 3.484 3.673 3.478
5 3.657 3.836 3.432 3.441 3.835 3.622
6 3.815 3.791 3.684 3.924 3.409 3.261
7 4.047 3.616 3.402 3.570 3.472 4.665
8 3.767 3.397 3.300 3.629 3.505 4.384Tabelle C.2: Durchschnittliche Laufzeit der Berechnung für 2 räumliche Zustände
Level
Featureexponent 1 2 3 4 5 6
1 3.993 3.437 3.362 3.366 3.552 3.224
2 3.596 3.385 3.458 3.440 3.199 3.392
3 3.722 3.590 3.462 3.412 3.397 3.249
4 3.890 3.600 3.548 3.456 3.359 3.261
5 3.775 3.421 3.459 3.246 3.306 3.474
6 3.826 3.640 3.428 3.391 3.518 3.277
7 3.640 3.583 3.281 3.299 3.368 3.058
8 3.382 3.570 3.501 3.470 3.235 3.317Tabelle C.3: Durchschnittliche Laufzeit der Berechnung für 4 räumliche Zustände
88 ANHANG C. EVALUATION OZEANDATEN
Level
Featureexponent 1 2 3 4 5 6
1 3.462 3.297 3.404 3.304 3.464 3.318
2 3.243 3.187 3.363 3.301 3.279 3.217
3 3.308 3.647 3.453 3.441 3.765 3.822
4 3.332 3.260 3.853 3.434 3.352 3.952
5 3.246 3.508 3.389 3.333 3.361 3.287
6 3.248 3.306 3.373 3.217 3.268 3.845
7 3.275 3.351 3.322 3.497 3.186 4.230
8 3.142 3.239 3.214 3.315 3.267 4.303Tabelle C.4: Durchschnittliche Laufzeit der Berechnung für 8 räumliche Zustände
Level
Featureexponent 1 2 3 4 5 6
1 5.247 3.420 3.330 3.349 3.347 3.336
2 4.009 3.658 3.270 3.339 3.290 3.316
3 3.581 3.284 3.247 3.389 3.233 3.291
4 3.413 3.425 3.338 3.359 3.324 3.305
5 3.375 3.494 3.452 3.418 3.313 3.411
6 3.309 3.379 3.177 3.120 3.260 3.331
7 3.255 3.188 3.171 3.314 3.261 3.550
8 3.402 3.266 3.222 3.325 3.230 3.876Tabelle C.5: Durchschnittliche Laufzeit der Berechnung für 16 räumliche Zustände
Level
Featureexponent 1 2 3 4 5 6
1 3.309 3.471 3.494 3.634 3.889 3.901
2 3.370 3.587 3.510 3.467 3.541 3.878
3 3.378 3.429 3.596 3.538 3.631 4.167
4 3.278 3.314 3.486 3.577 3.507 3.730
5 3.226 3.252 3.554 3.507 3.634 4.216
6 3.361 3.271 3.427 3.442 3.565 3.991
7 3.221 3.247 3.551 3.622 3.743 4.088
8 3.294 3.363 3.519 3.664 3.834 4.874Tabelle C.6: Durchschnittliche Laufzeit der Berechnung für 32 räumliche Zustände
C.1. MESSUNGEN LAUFZEIT FÜR DEN SPATIAL-PYRAMID-ANSATZ 89
Level
Featureexponent 1 2 3 4 5 6
1 4.940 3.748 3.684 3.695 3.837 3.871
2 3.711 3.605 3.763 3.779 3.742 4.045
3 3.480 3.707 3.645 3.745 3.840 4.021
4 3.690 3.552 3.598 3.733 3.802 3.991
5 3.511 3.654 3.662 3.688 3.924 4.419
6 3.556 3.574 3.855 3.727 3.899 4.583
7 3.488 3.698 3.817 3.649 4.091 5.357
8 3.465 3.874 4.089 4.038 4.707 6.729Tabelle C.7: Durchschnittliche Laufzeit der Berechnung für 64 räumliche Zustände
Level
Featureexponent 1 2 3 4 5 6
1 3.724 4.095 3.920 3.934 4.227 5.526
2 3.746 3.806 4.469 3.951 4.188 6.206
3 3.685 3.724 3.814 3.968 4.498 6.034
4 3.672 3.703 3.760 3.966 4.375 6.262
5 3.612 3.566 3.630 3.847 4.148 6.740
6 3.636 3.748 3.819 3.935 4.543 7.570
7 3.916 3.908 4.072 4.418 5.332 9.668
8 4.070 4.228 4.257 4.706 6.373 11.785Tabelle C.8: Durchschnittliche Laufzeit der Berechnung für 128 räumliche Zustände
Level
Featureexponent 1 2 3 4 5 6
1 5.610 4.467 4.807 5.173 6.491 11.561
2 4.660 4.558 4.864 5.297 6.576 11.811
3 4.347 4.530 4.834 5.210 6.522 11.653
4 4.526 4.564 4.922 5.308 6.874 12.214
5 4.380 4.657 4.991 5.515 6.802 12.783
6 4.986 5.315 5.654 6.492 8.976 18.996
7 5.328 5.643 6.265 7.401 10.431 22.857
8 6.287 6.591 7.417 8.874 13.454 32.217Tabelle C.9: Durchschnittliche Laufzeit der Berechnung für 256 räumliche Zustände
90 ANHANG C. EVALUATION OZEANDATEN
Level
Featureexponent 1 2 3 4 5 6
1 6.957 7.916 9.110 10.471 14.909 33.477
2 7.560 8.303 9.350 10.693 15.161 34.382
3 7.287 8.089 9.289 11.149 14.680 31.222
4 7.679 8.789 9.968 11.101 13.839 27.515
5 7.914 9.016 10.244 11.625 16.013 35.496
6 11.297 12.628 13.929 15.974 20.976 49.664
7 14.021 15.419 16.967 19.042 27.785 76.476
8 19.647 21.609 23.190 25.974 35.558 97.252Tabelle C.10: Durchschnittliche Laufzeit der Berechnung für 512 räumliche Zustände
Level
Featureexponent 1 2 3 4 5 6
1 17.458 19.148 20.818 23.336 39.819 99.837
2 17.171 19.519 21.366 24.336 38.865 91.798
3 17.789 19.896 21.638 24.181 37.674 115.603
4 18.599 21.099 22.684 24.906 41.118 80.814
5 19.743 22.474 24.419 27.144 41.376 114.606
6 36.586 39.227 40.883 45.080 72.769 175.190
7 45.009 47.606 50.588 55.574 100.183 277.651
8 52.007 57.827 57.289 66.394 124.006 370.706Tabelle C.11: Durchschnittliche Laufzeit der Berechnung für 1024 räumliche Zustände
C.1.3 Standardabweichungen für die durchschnittlichen Laufzeiten
Level
Featureexponent 1 2 3 4 5 6
1 4.323 428 401 778 145 261
2 489 1.027 261 295 320 195
3 581 1.027 163 195 235 147
4 481 229 203 331 238 305
5 343 192 328 218 133 448
6 411 313 315 207 82 498
7 595 250 285 147 82 283
8 171 239 419 134 519 154Tabelle C.12: Standardabweichung der Laufzeit der Berechnung für 1 räumlichen Zustand
C.1. MESSUNGEN LAUFZEIT FÜR DEN SPATIAL-PYRAMID-ANSATZ 91
Level
Featureexponent 1 2 3 4 5 6
1 679 395 319 787 252 110
2 424 316 227 234 334 296
3 517 301 158 325 896 721
4 457 378 249 102 583 183
5 308 334 383 130 432 174
6 503 509 410 302 199 260
7 484 302 207 265 131 1.318
8 321 191 191 478 71 442Tabelle C.13: Standardabweichung der Laufzeit der Berechnung für 2 räumliche Zustände
Level
Featureexponent 1 2 3 4 5 6
1 868 181 199 270 56 280
2 78 445 192 209 227 257
3 191 440 85 146 199 108
4 761 217 134 402 183 218
5 247 379 142 220 243 223
6 255 420 183 206 77 261
7 344 344 283 117 247 46
8 135 136 349 301 185 141Tabelle C.14: Standardabweichung der Laufzeit der Berechnung für 4 räumliche Zustände
Level
Featureexponent 1 2 3 4 5 6
1 169 427 288 243 304 214
2 254 214 296 225 202 53
3 255 1.068 262 245 1.140 506
4 207 248 863 439 161 695
5 79 169 185 295 189 210
6 321 246 242 123 120 261
7 271 292 300 476 110 372
8 76 247 128 87 150 372Tabelle C.15: Standardabweichung der Laufzeit der Berechnung für 8 räumliche Zustände
92 ANHANG C. EVALUATION OZEANDATEN
Level
Featureexponent 1 2 3 4 5 6
1 2.250 175 178 371 165 57
2 593 420 168 238 82 68
3 243 154 132 172 92 184
4 171 215 149 154 23 122
5 182 424 421 170 84 88
6 187 253 59 83 106 94
7 92 94 35 31 91 28
8 190 162 116 169 47 115Tabelle C.16: Standardabweichung der Laufzeit der Berechnung für 16 räumliche Zustände
Level
Featureexponent 1 2 3 4 5 6
1 174 134 254 95 611 320
2 127 117 110 81 72 300
3 118 189 261 228 109 1.112
4 107 92 133 130 176 187
5 122 86 341 162 176 482
6 281 119 119 59 89 585
7 124 132 555 98 41 155
8 71 76 163 95 78 274Tabelle C.17: Standardabweichung der Laufzeit der Berechnung für 32 räumliche Zustände
Level
Featureexponent 1 2 3 4 5 6
1 1.482 259 198 218 123 118
2 370 259 151 162 151 177
3 105 162 83 178 236 275
4 348 45 100 343 153 177
5 264 122 204 132 133 533
6 191 119 133 93 111 420
7 88 185 242 84 161 326
8 189 152 262 388 793 475Tabelle C.18: Standardabweichung der Laufzeit der Berechnung für 64 räumliche Zustände
C.1. MESSUNGEN LAUFZEIT FÜR DEN SPATIAL-PYRAMID-ANSATZ 93
Level
Featureexponent 1 2 3 4 5 6
1 250 225 98 224 88 165
2 163 147 1.304 122 161 458
3 105 63 80 80 804 686
4 147 70 153 126 315 392
5 51 120 127 145 36 436
6 112 234 79 101 98 657
7 155 130 168 37 130 997
8 461 47 237 52 191 908Tabelle C.19: Standardabweichung der Laufzeit der Berechnung für 128 räumliche Zustände
Level
Featureexponent 1 2 3 4 5 6
1 1.267 120 99 58 62 142
2 393 111 190 383 132 191
3 52 120 134 93 171 456
4 232 146 48 100 449 299
5 72 136 63 175 167 426
6 57 77 82 130 488 2.158
7 304 231 209 72 128 1.983
8 457 429 312 185 956 5.271Tabelle C.20: Standardabweichung der Laufzeit der Berechnung für 256 räumliche Zustände
Level
Featureexponent 1 2 3 4 5 6
1 360 184 239 521 763 2.824
2 190 177 283 111 642 656
3 315 137 263 1.217 1.293 2.522
4 126 68 316 209 623 1.382
5 154 152 524 98 818 1.170
6 340 409 483 818 901 4.920
7 437 449 132 476 1.275 4.645
8 738 534 896 604 550 3.996Tabelle C.21: Standardabweichung der Laufzeit der Berechnung für 512 räumliche Zustände
94 ANHANG C. EVALUATION OZEANDATEN
Level
Featureexponent 1 2 3 4 5 6
1 917 60 228 762 448 17.309
2 238 219 400 784 3.010 6.275
3 329 347 362 852 4.071 1.151
4 403 1.184 663 93 3.259 3.598
5 499 440 461 275 2.105 6.288
6 1.938 800 1.093 1.989 5.834 22.875
7 476 526 495 1.552 10.108 19.418
8 2.493 2.620 3.366 2.667 20.281 30.454Tabelle C.22: Standardabweichung der Laufzeit der Berechnung für 1024 räumliche Zustände
C.1.4 Verhältnisse der Laufzeiterhöhung
Level
Featureexponent 2 3 4 5 6
1 0,83 1,12 1,07 1,80 3,27
2 1,06 1,11 1,06 1,82 3,24
3 0,67 1,02 1,09 1,72 3,09
4 1,03 1,01 1,25 1,56 2,80
5 1,05 1,02 1,08 1,66 3,13
6 1,03 1,04 1,10 1,65 3,57
7 1,00 1,02 1,12 1,78 4,29
8 1,09 0,74 1,41 1,80 3,42
Tabelle C.23: Verhältnismäßige Erhöhung der Laufzeit von einem Level zu vorhergehenden Levelfür 1024 räumliche Zustände
C.1. MESSUNGEN LAUFZEIT FÜR DEN SPATIAL-PYRAMID-ANSATZ 95
Level
Featureexponent 1 2 3 4 5 6
2 0,80 1,03 1,02 1,01 1,02 1,01
3 1,83 1,15 1,05 1,09 1,03 0,98
4 0,70 1,08 1,07 1,22 1,11 1,00
5 0,96 0,98 1,00 0,87 0,92 1,03
6 1,58 1,54 1,57 1,59 1,59 1,81
7 1,30 1,27 1,25 1,27 1,37 1,64
8 1,65 1,80 1,29 1,63 1,65 1,31
Tabelle C.24: Verhältnismäßige Erhöhung der Laufzeit von einem Feature zu vorhergehenden Fea-ture für 1024 räumliche Zustände
96 ANHANG C. EVALUATION OZEANDATEN
C.1.5 Separate durchschnittliche Laufzeiten für Pyramidisierung undVergleich
Level
Featureexponent Aktion 1 2 3 4 5 6
1 Pyramidisierung 4.181 6.339 7.069 8.281 9.643 11.152
Vergleich 13.556 15.061 15.389 15.358 30.460 103.677
2 Pyramidisierung 4.015 5.786 7.231 8.372 9.768 11.430
Vergleich 13.802 15.623 16.000 15.851 31.030 106.934
3 Pyramidisierung 4.236 5.588 7.076 8.741 10.201 11.874
Vergleich 16.360 17.918 16.924 17.660 31.607 107.623
4 Pyramidisierung 4.136 5.931 7.490 8.954 10.405 12.836
Vergleich 15.874 15.431 15.491 17.012 30.175 113.843
5 Pyramidisierung 4.477 6.126 7.685 9.384 11.405 14.395
Vergleich 18.617 18.900 21.688 23.013 34.665 120.785
6 Pyramidisierung 4.525 6.563 8.449 10.266 12.671 17.764
Vergleich 32.708 34.127 33.780 35.182 55.284 216.087
7 Pyramidisierung 4.809 7.501 9.428 11.773 14.993 22.721
Vergleich 42.347 42.558 43.723 43.878 80.819 312.932
8 Pyramidisierung 5.366 8.158 11.348 13.610 18.617 30.834
Vergleich 58.913 61.710 59.146 65.609 121.300 458.411
Tabelle C.25: Gemittelte Messwerte der Laufzeit getrennt nach Pyramidisierung und Vergleich mit1024 räumlichen Zuständen: Für jede Messung wurden die Daten geladen (Bilden der Pyramideund Featuresignaturen) und der Vergleich separat durchgeführt.
C.2. DURCHSCHNITTLICHE LAUFZEITEN DES SPATIAL-PYRAMID-ANSATZES FÜR 256 FEATURES97
C.2 Durchschnittliche Laufzeiten des Spatial-Pyramid-Ansatzes
für 256 FeaturesAlle durchschnittlichen Laufzeiten für 256 Features sind hier in einer Tabelle zusammengefasst,damit die Entwicklung über die Erhöhung der räumlichen Zustände sichtbar werden kann.
Level
Grids 1 2 3 4 5 6
1 3.992 3.796 3.713 3.546 3.727 3.388
2 3.767 3.397 3.300 3.629 3.505 4.384
4 3.382 3.570 3.501 3.470 3.235 3.317
8 3.142 3.239 3.214 3.315 3.267 4.303
16 3.402 3.266 3.222 3.325 3.230 3.876
32 3.294 3.363 3.519 3.664 3.834 4.874
64 3.465 3.874 4.089 4.038 4.707 6.729
128 4.070 4.228 4.257 4.706 6.373 11.785
256 6.287 6.591 7.417 8.874 13.454 32.217
512 19.647 21.609 23.190 25.974 35.558 97.252
1024 52.007 57.827 57.289 66.394 124.006 370.706
Tabelle C.26: Alle durchschnittliche Laufzeiten für 256 Feature über alle Level
98 ANHANG C. EVALUATION OZEANDATEN
C.3 Durchschnittliche Laufzeiten für die SSE
Grids SSE Spatial-Pyramid(Level:4; Featureex-ponent: 3)
Geschwindigkeitsvorteilgegenüber der SSE
1 7.665 3.630 2,11
2 9.105 3.492 2,61
4 5.123 3.412 1,50
8 5.528 3.441 1,61
16 4.597 3.389 1,36
32 4.089 3.538 1,16
64 4.826 3.745 1,29
128 6.862 3.968 1,73
256 16.684 5.210 3,20
512 57.013 11.149 5,11
1024 218.392 24.181 9,03
Tabelle C.27: Durchschnittliche Laufzeiten für die Implementierung der SSE in Abhängigkeit vonder Anzahl der räumlichen Zustände. Außerdem wird die exemplarische Konfiguration von 4 Levelund 8 Features gegen die SSE verglichen. Der Geschwindigkeitsvorteil als Verhältnis der Laufzeitenzueinander ist in der letzten Spalte wiedergegeben.
C.4. GÜTE DER VERGLEICHE 99
C.3.1 Standardabweichung für SSE
Grids SSE
1 1.334
2 905
4 286
8 226
16 702
32 574
64 445
128 248
256 63
512 623
1024 2.027
Tabelle C.28: Standardabweichung für die Implementierung der SSE.
C.4 Güte der Vergleiche
Level
Featureexponent 1 2 3 4 5 6
1 0,7% 3,4% 7,4% 17,0% 17,9% 18,9%
2 1,9% 5,8% 14,9% 27,0% 29,3% 31,4%
3 4,2% 29,1% 49,0% 53,1% 54,6% 55,1%
4 7,9% 32,1% 49,1% 52,1% 50,9% 53,5%
5 11,1% 40,0% 51,9% 53,4% 53,9% 55,4%
6 25,3% 49,7% 53,9% 54,7% 56,5% 57,4%
7 28,7% 49,5% 51,2% 52,8% 54,7% 56,9%
8 29,7% 50,4% 51,1% 53,7% 53,1% 56,0%
Tabelle C.29: Vergleich der Güte zwischen SSE und Spatial-Pyramid-Ansatz
100 ANHANG C. EVALUATION OZEANDATEN
0 1 2 3 4 5 6 7 8 9 10
L = 1, F = 2
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 2, F = 2
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 3, F = 2
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 4, F = 2
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 5, F = 2
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 6, F = 2
0 1 2 3 4 5 6 7 8 9 10
L = 1, F = 4
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 2, F = 4
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 3, F = 4
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 4, F = 4
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 5, F = 4
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 6, F = 4
0 1 2 3 4 5 6 7 8 9 10
L = 1, F = 8
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 2, F = 8
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 3, F = 8
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 4, F = 8
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 5, F = 8
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 6, F = 8
0 1 2 3 4 5 6 7 8 9 10
L = 1, F = 16
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 2, F = 16
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 3, F = 16
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 4, F = 16
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 5, F = 16
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 6, F = 16
0 1 2 3 4 5 6 7 8 9 10
L = 1, F = 32
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 2, F = 32
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 3, F = 32
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 4, F = 32
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 5, F = 32
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 6, F = 32
0 1 2 3 4 5 6 7 8 9 10
L = 2, F = 64
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 2, F = 64
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 2, F = 64
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 2, F = 64
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 2, F = 64
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 2, F = 64
0 1 2 3 4 5 6 7 8 9 10
L = 2, F = 128
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 2, F = 128
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 2, F = 128
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 2, F = 128
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 2, F = 128
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6 7 8 9 10
L = 2, F = 128
L = 1, F = 256
100
200
300
400
500
600
700
800
L = 2, F = 256
100
200
300
400
500
600
700
800
L = 3, F = 256
100
200
300
400
500
600
700
800
L = 4, F = 256
100
200
300
400
500
600
700
800
L = 5, F = 256
100
200
300
400
500
600
700
800
L = 6, F = 256
Abbildung C.12: Fehler des Spatial-Pyramid-Ansatzes bei der Ermittlung der Güte für alle Kon-figurationen. Wenn die direkten Nachbarn nicht übereinstimmen, wird der Fehler der direktenNachbarn ermittelt.
C.5. QUALITÄT DER VERGLEICHE 101
C.5 Qualität der Vergleiche
Level
Featureexponent 1 2 3 4 5 6
1 3,53% 6,74% 10,65% 19,52% 23,62% 25,51%
2 3,33% 9,03% 14,82% 25,60% 30,78% 34,08%
3 10,48% 29,77% 48,91% 63,06% 75,76% 85,29%
4 9,85% 29,27% 51,93% 67,75% 78,83% 87,53%
5 14,94% 34,89% 54,46% 66,94% 79,10% 87,67%
6 27,51% 43,94% 61,58% 72,69% 82,27% 88,83%
7 29,58% 45,92% 63,97% 74,80% 83,47% 89,58%
8 29,99% 46,48% 63,37% 74,37% 82,62% 88,70%
Tabelle C.30: Vergleich der Qualität zwischen SSE und Spatial-Pyramid-Ansatz: In Prozent ist indieser Tabelle angegeben wieviele der zehn direkten Nachbarn jeweils übereinstimmen.
102 ANHANG C. EVALUATION OZEANDATEN
L = 1, F = 2
0
2
4
6
8
10
L = 1, F = 2
0
2
4
6
8
10
L = 3, F = 2
0
2
4
6
8
10
L = 4, F = 2
0
2
4
6
8
10
L = 5, F = 2
0
2
4
6
8
10
L = 6, F = 2
L = 1, F = 4
0
2
4
6
8
10
L = 2, F = 4
0
2
4
6
8
10
L = 3, F = 4
0
2
4
6
8
10
L = 4, F = 4
0
2
4
6
8
10
L = 5, F = 4
0
2
4
6
8
10
L = 6, F = 4
L = 1, F = 8
0
2
4
6
8
10
L = 2, F = 8
0
2
4
6
8
10
L = 3, F = 8
0
2
4
6
8
10
L = 4, F = 8
0
2
4
6
8
10
L = 5, F = 8
0
2
4
6
8
10
L = 6, F = 8
L = 1, F = 16
0
2
4
6
8
10
L = 2, F = 16
0
2
4
6
8
10
L = 3, F = 16
0
2
4
6
8
10
L = 4, F = 16
0
2
4
6
8
10
L = 5, F = 16
0
2
4
6
8
10
L = 6, F = 16
L = 1, F = 32
0
2
4
6
8
10
L = 2, F = 32
0
2
4
6
8
10
L = 3, F = 32
0
2
4
6
8
10
L = 4, F = 32
0
2
4
6
8
10
L = 5, F = 32
0
2
4
6
8
10
L = 6, F = 32
L = 2, F = 64
0
2
4
6
8
10
L = 2, F = 64
0
2
4
6
8
10
L = 2, F = 64
0
2
4
6
8
10
L = 2, F = 64
0
2
4
6
8
10
L = 2, F = 64
0
2
4
6
8
10
L = 2, F = 64
L = 2, F = 128
0
2
4
6
8
10
L = 2, F = 128
0
2
4
6
8
10
L = 2, F = 128
0
2
4
6
8
10
L = 2, F = 128
0
2
4
6
8
10
L = 2, F = 128
0
2
4
6
8
10
L = 2, F = 128
L = 1, F = 256
0
2
4
6
8
10
L = 2, F = 256
0
2
4
6
8
10
L = 3, F = 256
0
2
4
6
8
10
L = 4, F = 256
0
2
4
6
8
10
L = 5, F = 256
0
2
4
6
8
10
L = 6, F = 256
Abbildung C.13: Qualität des Spatial-Pyramid-Ansatzes. Hier ist Übereinstimmung der 10 ähn-lichsten Nachbarn zwischen den beiden Implementierungen der SSE und Spatial-Pyramid für alleKonfigurationen zu sehen. Jeder räumliche Zustand ist durchnummeriert (x-Achse). Jeder Punktzeigt die Anzahl der gleichen Nachbarn unter den 10 direkten Nachbarn (y-Achse).
C.6.
DA
UE
RE
INE
SV
ER
GLE
ICH
SZW
EIE
RR
ÄU
MLIC
HE
RZU
STÄ
ND
E103
C.6 Dauer eines Vergleichs zweier räumlicher Zustände
Level
Anzahl der Vergleichevon räumlichen Zu-ständen
räumlicheZustände
1 2 3 4 5 6 SSE
1 1 3.992,00 3.795,60 3.713,40 3.545,80 3.727,00 3.388,20 12.848,00
3 2 1.255,53 1.132,20 1.100,00 1.209,60 1.168,47 1.461,40 3.763,07
10 4 338,24 356,96 350,12 346,96 323,54 331,70 793,52
36 8 87,29 89,97 89,27 92,07 90,76 119,54 286,86
136 16 25,02 24,01 23,69 24,45 23,75 28,50 56,29
528 32 6,24 6,37 6,67 6,94 7,26 9,23 9,81
2080 64 1,67 1,86 1,97 1,94 2,26 3,24 2,73
8256 128 0,49 0,51 0,52 0,57 0,77 1,43 0,87
32896 256 0,19 0,20 0,23 0,27 0,41 0,98 0,47
131328 512 0,15 0,16 0,18 0,20 0,27 0,74 0,39
524800 1024 0,10 0,11 0,11 0,13 0,24 0,71 0,37
Tabelle C.31: Durchschnittliche Dauer pro paarweisem Vergleich: Zu sehen ist die Dauer pro paarweisem Vergleich der räumlichen Zuständefür alle Eingabemengen der räumliche Zustände. Für alle Messungen wurden hier 256 Features benutzt.
Anhang D
Evaluation der synthetischen Daten
Level
Featureexponent 1 2 3 4 5 6
1 32.021 55.098 67.212 99.292 92.040 196.351
2 33.319 55.468 87.682 114.200 117.802 299.895
3 42.310 68.023 99.105 139.746 129.738 310.829
4 50.533 74.289 98.882 135.505 157.772 335.088
5 56.514 87.923 133.967 179.944 198.200 440.606
6 70.966 107.031 162.292 211.288 257.027 532.183
7 111.110 164.229 205.332 285.145 419.153 970.325
8 168.381 210.069 301.168 368.855 582.469 1.486.746
Tabelle D.1: Durchschnittliche Laufzeit der Berechnung synthetischer Daten für 1000 räumlicheZustände
104
Literaturverzeichnis
[1] Alexander Alexandrov, Dominic Battré, Stephan Ewen, Max Heimel, Fabian Hueske, OdejKao, Volker Markl, Erik Nijkamp, and Daniel Warneke. Massively Parallel Data Analysiswith PACTs on Nephele. PVLDB, 3(2):1625–1628, 2010.
[2] Alexander Alexandrov, Stephan Ewen, Max Heimel, Fabian Hueske, Odej Kao, Volker Markl,Erik Nijkamp, and Daniel Warneke. MapReduce and PACT - Comparing Data Parallel Pro-gramming Models. In Proceedings of the 14th Conference on Database Systems for Business,Technology, and Web (BTW), BTW 2011, pages 25–44, Bonn, Germany, 2011. GI.
[3] David Applegate, Tamraparni Dasu, Shankar Krishnan, and Simon Urbanek. Unsupervisedclustering of multidimensional distributions using earth mover distance. In Proceedings of the17th ACM SIGKDD international conference on Knowledge discovery and data mining, KDD’11, pages 636–644, New York, NY, USA, 2011. ACM.
[4] Aviso. Ssalto/Duacs. http://www.aviso.oceanobs.com/duacs/.
[5] Dominic Battré, Stephan Ewen, Fabian Hueske, Odej Kao, Volker Markl, and Daniel Warneke.Nephele/PACTs: A Programming Model and Execution Framework for Web-Scale AnalyticalProcessing. In Proc. of the 1st ACM symposium on Cloud computing, SoCC ’10, pages 119–130, New York, NY, USA, 2010. ACM.
[6] TU Berlin, HU Berlin, and HPI Potsdam. Stratosphere: Above the Clouds.http://stratosphere.eu/.
[7] Sébastien Bubeck and Ulrike von Luxburg. Nearest Neighbor Clustering: A Baseline Methodfor Consistent Clustering with Arbitrary Objective Functions. Journal of Machine LearningResearch, 10:657–698, March 2009.
[8] Trevor F. Cox and Michael A. A. Cox. Multidimensional Scaling. Chapman & Hall, London,1994.
[9] Jeffrey Dean and Sanjay Ghemawat. MapReduce: Simplified Data Processing on Large Clus-ters. In OSDI, pages 137–150, 2004.
[10] Martin Ester and Jörg Sander. Knowledge Discovery in Databases. Springer-Verlag, 2000.
[11] Facebook. Under the Hood: Hadoop Distributed Filesystem reliability with Name-node and Avatarnode. https://www.facebook.com/notes/facebook-engineering/under-the-hood-hadoop-distributed-filesystem-reliability-with-namenode-and-avata/10150888759153920.
105
106 LITERATURVERZEICHNIS
[12] Facebook. Under the Hood: Scheduling MapReduce jobs more efficient-ly with Corona. https://www.facebook.com/notes/facebook-engineering/under-the-hood-scheduling-mapreduce-jobs-more-efficiently-with-corona/10151142560538920.
[13] Joachim Fischer and Klaus Ahrens. Objektorientierte Prozeßsimulation in C++. Addison-Wesley Publishing Company, 1996.
[14] The Apache Software Foundation. Hadoop. http://hadoop.apache.org/.
[15] GFZ. GFZ Cluster. https://rz.gfz-potsdam.de/compute-server.
[16] Kristen Grauman and Trevor Darrell. The pyramid match kernel: Discriminative classificationwith sets of image features. In ICCV, pages 1458–1465, 2005.
[17] J. A. Hartigan and M. A. Wong. A K-Means Clustering Algorithm. Journal of the RoyalStatistical Society. Series C (Applied Statistics), 28:100–108, 1979.
[18] Anil K. Jain and Richard C. Dubes. Algorithms for Clustering Data. Prentice-Hall, 1988.
[19] Patrick Köthur, Mike Sips, Julian Kuhlmann, and Doris Dransch. Visualization of GeospatialTime Series from Environmental Modeling Output. In Miriah Meyer and Tino Weinkauf,editors, EuroVis - Short Papers, pages 115–119, Vienna, Austria, Eurographics Association2012. Eurographics Association.
[20] Svetlana Lazebnik, Cordelia Schmid, and Jean Ponce. Beyond bags of features: Spatial pyra-mid matching for recognizing natural scene categories. In Proc. of the 2006 IEEE Conferenceon Computer Vision and Pattern Recognition - Volume 2, CVPR ’06, pages 2169–2178, Wa-shington, DC, USA, 2006.
[21] James Mercer. Functions of positive and negative type and their connection with the theoryof integral equations. Philos. Trans. Roy. Soc., 209:415–446, 1909.
[22] Klaus-Robert Müller, Sebastian Mika, Gunnar Rätsch, Koji Tsuda, and Bernhard Schölkopf.An introduction to kernel-based learning algorithms. IEEE TRANSACTIONS ON NEURALNETWORKS, 12(2):181–201, 2001.
[23] NASA GISS. Panoply netCDF, HDF and GRIB Data Viewer. http://www.giss.nasa.gov/tools/panoply/.
[24] Carlton W. Niblack, Ron Barber, Will Equitz, Myron D. Flickner, Eduardo H. Glasman,Dragutin Petkovic, Peter Yanker, Christos Faloutsos, and Gabriel Taubin. QBIC project:querying images by content, using color, texture, and shape. In Carlton W. Niblack, editor,Conference on Storage and Retrieval for Image and Video Databases, volume 1908, pages173–187. SPIE, 1993.
[25] Oracle. Java. http://www.oracle.com/technetwork/java/index.html.
[26] Jan Puzicha, Thomas Hofmann, and Joachim M. Buhmann. Non-parametric similarity mea-sures for unsupervised texture segmentation and image retrieval. In Proceedings of the IEEEComputer Society Conference on Computer Vision and Pattern Recognition (CVPR), pages267–272, 1997.
[27] Thomas Rauber and Gudula Rünger. Parallel Programming. Springer-Verlag, 2010.
LITERATURVERZEICHNIS 107
[28] Yossi Rubner, Carlo Tomasi, and Leonidas J. Guibas. A metric for distributions with applica-tions to image databases. In Proceedings of the Sixth International Conference on ComputerVision, pages 59–66, 1998.
[29] Yossi Rubner, Carlo Tomasi, and Leonidas J. Guibas. The earth mover’s distance as a metricfor image retrieval. International Journal of Computer Vision, 40(2):99–121, 2000.
[30] Hanan Samet. Application of Spatial Data Structures. Addison-Wesley Publishing Company,1995.
[31] Bernhard Schölkopf, Alexander Smola, and Klaus-Robert Müller. Nonlinear component ana-lysis as a kernel eigenvalue problem. Neural Computation, 10:1299–1319, 1996.
[32] Johan A.K. Suykens, Tony van Gestel, Jos De Brabanter, Bart De Moor, and Joos Vandewalle.Least Squares support vector machines. World Scientific Publishing Co. Pte. Ltd., 2002.
[33] Michael Swain and Dana Ballard. Color indexing. IJCV, 7(1):11–32, 1991.
[34] Andrew S. Tanenbaum and Marten van Steen. Verteilte Systeme. Pearson Studium, 2003.
[35] Rares Vernica, Michael J. Carey, and Chen Li. Efficient parallel set-similarity joins using Ma-pReduce. In Proceedings of the 2010 ACM SIGMOD International Conference on Managementof data, SIGMOD ’10, pages 495–506, New York, NY, USA, 2010. ACM.
[36] Daniel Warneke and Odej Kao. Nephele: Efficient parallel data processing in the cloud. InProc. of the 2nd Workshop on Many-Task Computing on Grids and Supercomputers, MTAGS’09, pages 8:1–8:10, New York, NY, USA, 2009. ACM.
108 LITERATURVERZEICHNIS
SelbständigkeitserklärungIch erkläre hiermit, dass ich die vorliegende Arbeit selbständig verfasst und nur unter Verwendungder angegebenen Quellen und Hilfsmittel angefertigt habe. Weiterhin erkläre ich, eine Diplomarbeitin diesem Studiengebiet erstmalig einzureichen.
Berlin, den 26. Juni 2013 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .