Verteilte Berechnung exakter Perzentile von Fließkommazahlen

Masterarbeit

Verteilte Berechnung exakter Perzentile vonFließkommazahlen

Lukas Werner, Matrikel-Nr.: 3282957

Betreut durch:

Prof. Dr. Erhard Rahm Universität LeipzigMartin Grimmer Universität Leipzig

Michael Volkhardt CHECK24 Vergleichsportal GmbHDr. Lars Rösler CHECK24 Vergleichsportal GmbH

11. Oktober 2018

Inhaltsverzeichnis

1. Einleitung 14

2. Stand der Forschung 16

3. Grundlagen 183.1. Auswahlproblem . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2. Reservoir Sampling . . . . . . . . . . . . . . . . . . . . . . . . . 193.3. Empirisches Perzentil . . . . . . . . . . . . . . . . . . . . . . . . 193.4. Fließkommazahlen . . . . . . . . . . . . . . . . . . . . . . . . . 203.5. Verteilte Berechnung . . . . . . . . . . . . . . . . . . . . . . . . 21

3.5.1. Abgrenzung zu paralleler Berechnung . . . . . . . . . . . 223.5.2. Vorteile verteilter Systeme . . . . . . . . . . . . . . . . . 223.5.3. Computercluster . . . . . . . . . . . . . . . . . . . . . . 24

4. Technologien 254.1. Apache Hadoop . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1.1. HDFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.1.2. YARN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2. Apache Flink . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2.1. Verteilte Laufzeitumgebung . . . . . . . . . . . . . . . . 274.2.2. DataSet API . . . . . . . . . . . . . . . . . . . . . . . . 284.2.3. Iterative Algorithmen in Apache Flink . . . . . . . . . . 29

4.3. Redis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2

Inhaltsverzeichnis

5. Algorithmen 305.1. Sequentielle Berechnung . . . . . . . . . . . . . . . . . . . . . . 30

5.1.1. Primitiver Ansatz . . . . . . . . . . . . . . . . . . . . . . 305.1.2. QuickSelect . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2. Verteilter Algorithmus für das Auswahlproblem . . . . . . . . . 365.2.1. Ablauf des Algorithmus . . . . . . . . . . . . . . . . . . 395.2.2. Implementierung . . . . . . . . . . . . . . . . . . . . . . 43

6. Evaluation 516.1. Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.1.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 526.1.2. Parameter und Datenmengen . . . . . . . . . . . . . . . 52

6.2. Skalierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.3. Veränderung der Datengröße . . . . . . . . . . . . . . . . . . . 556.4. Vergleich zu anderen Ansätzen . . . . . . . . . . . . . . . . . . 57

6.4.1. Sequentielle Berechnung . . . . . . . . . . . . . . . . . . 576.4.2. Approximative Berechnung . . . . . . . . . . . . . . . . 586.4.3. Berechnung ohne Redis . . . . . . . . . . . . . . . . . . 59

6.5. Weitere Beobachtungen . . . . . . . . . . . . . . . . . . . . . . 60

7. Schluss 627.1. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627.2. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637.3. Einsatzgebiet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

8. Danksagung 65

A. Anhang 66

Eidesstattliche Erklärung 77

3

Abbildungsverzeichnis

4.1. Prozesse in der verteilten Laufzeitumgebung von Flink. Ein Flink-Programm wird vom JobManager entgegengenommen, optimiertund auf die TaskManager verteilt. Letztere bieten einen odermehrere TaskSlots für die Ausführung einzelner Operationen.(Apache Software Foundation 2018a) . . . . . . . . . . . . . . . 27

5.1. Gezeigt wird ein Beispielablauf des QuickSelect-Algorithmus. Injedem Schritt werden eine linke (= left), eine rechte (= right)Grenze, sowie ein Pivot-Element bestimmt. Anschließend wirdsortiert und nur der Zweig verfolgt, in dem das gesuchte Elementliegt. Als Eingabeparameter dienen eine Liste von Fließkomma-werten und das gesuchte k (hier k = 6). . . . . . . . . . . . . . 32

5.2. Visualisierung des Ablaufs bei Coarse Grained Multicompu-ter (CGM): Jeder Prozessor berechnet seine Teillösung für denaktuellen Schritt. Anschließend kommunizieren alle Prozessorenüber einen Router miteinander in einer Barrier Synchronization. 37

5.3. Visualisierung des Iterate-Operator bei Apache Flink: EineSchritt-Funktion wird wiederholt ausgeführt, bis ein Beendigungs-kriterium erfüllt ist. Zu Beginn ist die komplette Datenmenge dieEingabe für die Schrittfunktion, bei jedem weiteren Durchlaufdie Ausgabe der vorherigen Schrittfunktion. Am Ende wird einIterationsergebnis zurückgegeben (Apache Software Foundation2018a). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4


5.4. Aufteilung der Datenmenge nach M . In Al liegen die Elemente,die kleiner als M sind. In Ae und Ag die Elemente, die gleich,respektive größer M sind. . . . . . . . . . . . . . . . . . . . . . 41

5.5. Gezeigt wird die Berechnung des gewichteten Medians M in-nerhalb des vorgestellten Algorithmus. Hier werden die obengezeigten Datentransformationen ausgeführt und es resultierendie unten gezeigten Ergebnisse. . . . . . . . . . . . . . . . . . . 45

5.6. Iteration im vorgestellten Algorithmus: Oben werden die Art derTransformationen und unten die Struktur der Ergebnisse gezeigt. 47

5.7. Es wird gezeigt, wie das Restproblem innerhalb des vorgestelltenAlgorithmus gelöst wird. Oben stehend die Datentransformatio-nen, an der Unterseite die resultierenden Daten. . . . . . . . . . 49

6.1. Laufzeiten des Algorithmus bei steigender Thread-Anzahl fürunterschiedlich große Datenmengen. Auf der linken Seite dieLaufzeiten in Sekunden für 107 Werte, auf der rechten Seite dieLaufzeit in Sekunden für 109 Werte. An der Unterseite der Gradder Parallelität in Threads. . . . . . . . . . . . . . . . . . . . . 54

6.2. Laufzeiten des Algorithmus bei steigender Werte-Anzahl. Auf derlinken Seite die Laufzeiten in Sekunden für 32 Threads (blau)und für 64 Threads (rot). An der Unterseite die Anzahl der Wertein der Eingabedatenmenge. . . . . . . . . . . . . . . . . . . . . 55

6.3. Laufzeiten des QuickSelect bei steigender Werte-Anzahl. An derlinken Seite die Laufzeit des Programms in Sekunden. An derUnterseite die Anzahl der Werte in der Eingabedatenmenge. . . 57

6.4. Vergleich der durchschnittlichen Laufzeiten der einzelnen Imple-mentierungen jeweils mit 32 und 64 Threads für 107 Werte. Derin dieser Arbeit vorgestellte Algorithmus wird hier mit Verteiltbezeichnet, der approximative mit Approx und der ohne Redisimplementierte mit Join. . . . . . . . . . . . . . . . . . . . . . . 61

5


A.1. Apache Flink: Optimierter Datenfluss. Zu sehen ist, wie ApacheFlink aus den Methodenaufrufen seiner Application ProgrammingInterface (API) einen optimierten Datenfluss-Plan baut. . . . . 73

6

Tabellenverzeichnis

6.1. Galaxy Cluster: Konfiguration pro Knoten . . . . . . . . . . . . 526.2. Evaluation: Ladezeiten nach Größe der Eingabemengen. . . . . 56

A.1. Protokoll: Evaluation des Join-Algorithmus. Zu sehen sind dieVerteilung der Eingabedaten, die Anzahl der Werte, die berechne-ten Perzentile, die Parallelität gemessen in Slots und die Laufzeitin Millisekunden. . . . . . . . . . . . . . . . . . . . . . . . . . . 66

A.2. Protokoll: Evaluation des approximativen Algorithmus. Zu sehensind die Verteilung der Eingabedaten, die Anzahl der Werte, dieberechneten Perzentile, die Parallelität gemessen in Slots und dieLaufzeit in Millisekunden. . . . . . . . . . . . . . . . . . . . . . 67

A.3. Protokoll: Evaluation des vorgestellten Algorithmus (1/5). Zusehen sind die Verteilung der Eingabedaten, die Anzahl der Werte,die berechneten Perzentile, die Parallelität gemessen in Slots unddie Laufzeit in Millisekunden. . . . . . . . . . . . . . . . . . . . 68



7

Tabellenverzeichnis



8

Quellcodeverzeichnis

5.1. Funktion partition bei QuickSort und QuickSelect . . . . . . . . 345.2. QuickSelect-Algorithmus (rekursive Variante) . . . . . . . . . . 345.3. QuickSelect-Algorithmus (iterative Variante) . . . . . . . . . . . 355.4. Funktion für die Berechnung des gewichteten Medians M . . . 41

9

Abkürzungsverzeichnis

API Application Programming Interface

CGM Coarse Grained Multicomputer

HDFS Hadoop Distributed File System

KPI Key Performance Indicator

Redis Remote Dictionary Server

YARN Yet Another Resource Negotiator

10

Glossar

Big Data Der Begriff Big Data ist in der Literatur nicht einheitlich definiert.Im Kontext dieser Arbeit ist die Beschreibung aus dem Werk von Fasel undMeier (2016) zutreffend: Big Data sind „Daten, die in ihrer Größe klassischeDatenhaltung, Verarbeitung und Analyse auf konventioneller Hardware über-steigen“.

Conversion Rate Die Conversion Rate (auch Konversionsrate) ist ein KeyPerformance Indicator (KPI) aus dem Online Marketing, der das Verhältnisder Besucher einer Webseite zu den Conversions, also den Übergängen desStatus von Besuchern in einen anderen, beschreibt. Die Conversion Rate wirdin Prozent angegeben und die Conversion muss nicht zwingend ein Kauf odereine Transaktion sein (Amthor und Brommund 2010).

Data Science Data Science beschreibt die Analyse und die Extraktion vonErkenntnissen aus Daten. Hier werden wissenschaftliche Methoden herangezogen,um in strukturierten oder unstrukturierten Daten Muster zu finden und somitneues Wissen zu gewinnen (Dhar 2013).

Framework Nach Balzert (2000) ist ein Framework eine Sammlung von Klassen,die einen wiederverwendbaren Entwurf für einen bestimmten Anwendungsbereichimplementieren. Ziel ist nicht die Wiederverwendung von Code, sondern dieWiederverwendung eines Entwurfs.

11

Quellcodeverzeichnis

Key Performance Indicator Ein KPI ist in der Betriebswirtschaftslehre eineKennzahl, die sich auf Erfolg, die Leistung oder Auslastung des Betriebs, seinereinzelnen organisatorischen Einheiten oder einer Maschine bezieht (Amthor undBrommund 2010).

QuickSort Der QuickSort ist ein Sortieralgorithmus, der eine gute Laufzeitkom-plexität aufweist, rekursiv arbeitet und nicht stabil ist, was heißt, dass gleicheElemente unter Umständen umsortiert werden könnten (Eppstein 2007).

Shared Nothing Architektur Die Shared Nothing Architektur beschreibt eineverteilte Rechnerarchitektur, bei der jeder Knoten unabhängig und eigenständigseine Aufgaben mit seinem eigenen Prozessor und den zugeordneten Speicher-komponenten wie Festplatte und Hauptspeicher erfüllen kann (Stonebraker1986).

Skalierung Als Skalierung wird im Rahmen dieser Arbeit nach Eppstein (2007)die Verbesserung eines Rechnersystems zur Leistungssteigerung bezeichnet. Eswerden horizontale Skalierung, bei der immer mehr Einzelrechner über einKommunikationsnetz zusammenarbeiten und vertikale Skalierung, bei der einEinzelrechner durch Verbesserung seiner Komponenten immer leistungsfähigerwird, unterschieden.

Time on Site Die Time on Site ist ein KPI aus dem Online Marketing undbeschreibt die Zeit, die ein Benutzer auf der Webseite verbringt (Stephane2011).

12

Zusammenfassung

Unternehmen nutzen zur Entscheidungsunterstützung, Steuerung und KontrolleKennzahlen, die eine Zusammenfassung von quantitativen Informationen bieten.Viele Berechnungen von Kennzahlen sind sehr aufwändig und bedürfen einerMenge an Eingabedaten. Vor allem im E-Commerce sind KPIs wie die ConversionRate oder die Time on Site wichtige Metriken, die helfen, das Angebot zuverbessern, indem besser auf Kundenwünsche reagiert werden kann. Oft möchteman dabei gewisse Ausreißer bzw. Zufälle unbetrachtet lassen. Hierbei hilftdas Perzentil; die Kennzahl einer Stichprobe, die letztere so teilt, dass ein festdefinierter Anteil der Stichprobe kleiner ist als das Perzentil selbst. Für großeDatenmengen ist es jedoch schwierig das Perzentil zu berechnen, da es hierfürbisher keine parallelen oder gar verteilten Algorithmen gibt. In dieser Arbeit wirdein Algorithmus zur verteilten Berechnung von Perzentilen auf Shared-Nothing-Architekturen vorgestellt. Es wird gezeigt, dass der vorgestellte Algorithmuseffizienter als andere verteilte Ansätze und ab einer bestimmten Datenmengeebenso effizienter als bewährte sequentielle Ansätze arbeitet.

1. Einleitung

Berechnungen statistischer Kennzahlen werden in Zeiten von stets wachsendenAnteilen des E-Commerce (vgl. Tropf (2016)) immer wichtiger. Von der Ex-traktion von Zeitreihendaten und anderen Verteilungen bis hin zu gewünschtenKPIs sind dabei immer größere Hürden zu nehmen. Die hohe Datenflut, alsodie Geschwindigkeit in der die Daten ankommen, ist genauso zu bewältigen, wiedie Größe der Daten, die selbst den Speicher der Rechenmaschinen in die Kniezwingt.

Hier müssen Lösungen gefunden werden, sodass die entsprechenden Kennzahlenauch verteilt, also auf Clustern von Rechnern, berechnet werden können. DerVerlauf einer verteilten Berechnung besteht im Regelfall aus zwei Schritten:

1. Die einzelnen Knoten, oft Slaves genannt, enthalten einen Teil der Einga-bedaten und berechnen hiermit ein Teilergebnis.

2. Der Hauptknoten, der Master, sammelt die Teilergebnisse und ermitteltdaraus das Endergebnis.

Für einige Kennzahlen, wie dem Mittelwert, das Minimum oder Maximumexistieren bereits Algorithmen zur verteilten Berechnung. Anders verhält essich bei Rang-basierten Maßen, wie dem Rangkorrelationskoeffizienten und demPerzentil. Hier müssen die Daten sortiert werden, was in verteilten Ausfüh-rungsumgebungen zwar möglich, jedoch nicht effizient ist, da hier sehr vieleDaten unter den Knoten ausgetauscht werden müssen. Selbst etablierte Softwa-relösungen und Frameworks im Big Data Umfeld wie Google BigQuery1 oder

1https://cloud.google.com/bigquery

14

1. Einleitung

KairosDB2 bestimmen solche Kennzahlen, wenn überhaupt, nur approximativoder sequentiell. In vielen Fällen sind jedoch auch exakte Werte für das Perzentilund ähnliche Maße notwendig, die dann aufwändig mit Eigenlösungen bestimmtwerden müssen, sofern das aufgrund der großen Datenmengen überhaupt möglichist.

In dieser Arbeit soll deshalb ein Algorithmus entwickelt werden, mit dem verteiltPerzentile für Fließkommawerte exakt berechnet werden können. Als Grundlagefür die Daten dient das Nutzertracking eines großen deutschen Reisevergleich-portals durch Google Analytics. Hier sind beispielsweise die Aufenthaltszeitoder Antwortzeiten pro Seite wichtige Eingabedaten für die Berechnung desPerzentils. Die Daten selbst wurden von Google Analytics in BigQuery, einemData-Warehouse für Unternehmen in der Cloud, das Analysen auf den Roh-daten unterstützt, importiert. Beim Abholen der Daten aus BigQuery ist dasAusgabe-Datenformat in der Regel die JavaScript Object Notation (JSON).Je nach Zeitraum, der analysiert werden soll, kommen schnell viele MillionenErgebniszeilen zurück und Dateien mit vielen Gigabytes an Fließkommawertensind nicht selten.

Nach dieser Einführung in die Thematik sollen in Kapitel 2 Arbeiten vorgestelltwerden, die sich mit ähnlichen Problemen beschäftigen. Anschließend bietet dasdritte Kapitel umfassende Grundlagen, die wichtig sind, um sich mit den weiterenKapiteln auseinanderzusetzen. Hiernach werden Technologien vorgestellt, diewährend der Erarbeitung der Lösung im Rahmen dieser Arbeit eingesetzt wurden.In Kapitel 5 werden in dieser Arbeit verwendete und im Rahmen dieser Arbeiterarbeitete Algorithmen vorgestellt, die im nachfolgenden Kapitel 6 evaluiertwerden. Der Schluss fasst noch einmal alle Erläuterungen zusammen und bieteteinen Ausblick.

2https://kairosdb.github.io

15

2. Stand der Forschung

Es existiert eine Reihe von Arbeiten, die sich mit ähnlichen Thematiken befassen.Das für diese Arbeit wohl naheliegendste Werk ist das von Saukas und Song(1998), welches effiziente parallele Algorithmen für das Auswahlproblem, das inAbschnitt 3.1 näher beschrieben wird, auf Basis des Coarse Grained Multicompu-ter (CGM)-Modells (siehe Abschnitt 5.2) vorstellt. Neben einem Verfahren zurLösung des einfachen Auswahlproblems, also die Lösung des Auswahlproblemsfür ein k, stellen die Autoren zusätzlich einen Algorithmus für die simultaneLösung mehrerer Auswahlprobleme, als auch ein kommunikationsoptimiertesparalleles Sortierverfahren auf Basis der anderen Algorithmen vor. Im Allgemei-nen arbeiten die Algorithmen von Saukas und Song (1998) immer nach demfolgenden Prinzip: Die Datenmenge wird mit einem speziellen Verfahren soweitreduziert, bis das Restproblem sequentiell lösbar wird. Der Algorithmus für dieverteilte Berechnung des Perzentils, der in Kapitel 5 vorgestellt wird, basiert zugroßen Teilen auf dem Algorithmus für das einfache Auswahlproblem, der imWerk von Saukas und Song (1998) zu finden ist.

Die Arbeit von Chaudhuri, Hagerup und Raman (1993) stellt ebenfalls effizienteparallele Lösungen für Auswahlprobleme bereit. Im Gegensatz zum Paper vonSaukas und Song (1998) findet hier jedoch keine Optimierung für die Kommunika-tion unter den Knoten statt, weshalb diese Algorithmen für den massiv-verteiltenAnsatz nicht infrage kommen. In reinen Parallelrechner-Umgebungen könntensolche Algorithmen jedoch definitiv Anwendung finden.

Eine weitere wichtige Arbeit ist die von Swoboda (2017), die sich ebenfallsmit Perzentilen beschäftigt. Hier gibt es allerdings einige Einschränkungen beiden Eingabedaten, die es möglich machen, einen vereinfachten Ansatz zur Be-

16

2. Stand der Forschung

rechnung der Perzentile anzuwenden: Dank der Annahme, dass ausschließlichganzzahlige Temperaturwerte vorliegen, können Histogramme verwendet wer-den, um gleiche Werte zusammenzufassen. Dies reduziert die Datenmenge, diebetrachtet werden muss, wodurch es in allen betrachteten Fällen möglich ist,das Perzentil sequentiell zu berechnen.

Im Werk von Shrivastava u. a. (2004) wird q-Digest vorgestellt, eine neuartigeDatenstruktur, auf Basis derer Anfragen definiert werden können, um Quantilein verteilten Umgebungen approximativ zu bestimmen. Die Besonderheiten andieser Datenstruktur sind, dass eine Fehlergrenze und die maximale Ressour-cennutzung definiert werden und somit garantiert eingehalten werden können.Dieser Ansatz wurde initial für kabellose Sensornetzwerke entwickelt. Die Auto-ren Wang u. a. (2013) nutzen diesen Ansatz, um auch für Datenströme Quantileapproximativ zu berechnen. Dies ist vor allem deshalb möglich, da die Da-tenstruktur Updates mit neuen Informationen bei neu ankommenden Wertenzulässt und nicht immer komplett neu aufgebaut werden muss.

Nach meinem Kenntnisstand gibt es jedoch bis heute noch keine Lösung zurverteilten und exakten Berechnung von Perzentilen mit Fließkommazahlen alsEingabedaten. Deshalb soll im Rahmen dieser Arbeit hierfür ein Algorithmusgefunden werden.

17

3. Grundlagen

In diesem Kapitel sollen für das weitere Verständnis notwendige Grundlagenund Theorien erläutert werden. Neben mathematischen Annahmen werdenauch Konzepte aus der Informatik, die in dieser Arbeit Anwendung finden,erläutert.

3.1. Auswahlproblem

Das Auswahlproblem ist eine wichtige Problemstellung zur Berechnung desPerzentils in einer Folge von Zahlen. Wie in Abschnitt 3.3 beschrieben, lässtsich die Berechnung des Perzentils als Auswahlproblem ausdrücken. Einfachformuliert beschreibt es die Suche nach dem k-ten Element in einer sortiertenFolge X von Zahlen, wobei k ∈ N und 1 ≤ k ≤ |X| ist (vgl. Saukas und Song(1998)).Definition 1. Sei X eine Folge von n Elementen. Zur Einfachheit wird ange-nommen, dass die Folge frei von Duplikaten ist. Der Rang des Elementes x inX, bezeichnet als rank(x,X), ist die Anzahl der Elemente aus X, die kleineroder gleich x sind.Definition 2. Gegeben sei k ∈ N, wobei 1 ≤ k ≤ n mit n = |X|. Das Aus-wahlproblem beschreibt die Suche nach einem x ∈ X, sodass rank(x,X) = k ist.Spezialfälle sind k = 1 und k = n, womit das Minimum respektive das Maximumvon X bestimmt werden kann. Wenn k = dn2 e ist, so wird der Median von X

bestimmt, ein wichtiges Quantil in der Statistik.

Das Auswahlproblem kann nach Blum u. a. (1973) mit einem sequentiellen

18

3. Grundlagen

deterministischen Algorithmus in linearer Zeit gelöst werden. ImWerk von Saukasund Song (1998) wird ein paralleler deterministischer Algorithmus vorgestellt,der das Auswahlproblem in O(log p) Kommunikationsrunden, wobei p die Anzahlder Prozessoren ist, lösen kann. Auf diesem Algorithmus basiert ebenfalls derAlgorithmus, der in Kapitel 5, Abschnitt 5.2 vorgestellt wird.

3.2. Reservoir Sampling

Das Reservoir Sampling wird genutzt, um eine zufällige Stichprobe T von t

Elementen aus einer Menge S mit s Elementen zu entnehmen (vgl. Black (2015)).Dabei findet diese Art von Sampling unter anderem Anwendung, wenn die MengeS nicht mehr in den Hauptspeicher eines Rechners passt. Es gibt eine ganzeReihe an Algorithmen, die eine Menge T ⊆ S finden können. Für diese Arbeitrelevant ist jedoch das verteilte Reservoir Sampling, bei dem angenommen wird,dass die zugrundeliegenden Daten über mehrere Rechenknoten verteilt sind.Auch hier gibt es einige Algorithmen, deren Anwendbarkeit von der Art derVerteilung bzw. des Rechenmodells abhängig ist. Wie das Reservoir Samplingim Rahmen dieser Arbeit implementiert wurde, um mittels Apache Flink einapproximatives Verfahren für das Auswahlproblem zu implementieren, kann inKapitel 6 Abschnitt 6.4.2 nachgelesen werden.

3.3. Empirisches Perzentil

Die Eingabedaten sind im Rahmen dieser Arbeit stets diskret. Deshalb kannhier nur ein empirisches Perzentil berechnet werden, da im Allgemeinen keinekontinuierliche Wahrscheinlichkeitsverteilung vorliegt.

Das empirische Perzentil ist ein Spezialfall des empirischen p-Quantils. Daswiederum ist ein Begriff aus der Statistik und eine Kennzahl einer Stichprobe.Einfach ausgedrückt teilt ein empirisches p-Quantil die Stichprobe so, dassein Anteil der Stichprobe von p kleiner und ein Anteil von 1 − p größer als

19

3. Grundlagen

das empirische p-Quantil ist. Empirische Perzentile sind wie bereits erwähntspezielle Quantile. Hier werden nur Werte für p von 0, 01 bis 0, 99 in Schrittenvon 0, 01 angenommen. Das empirische Perzentil lässt sich als Auswahlproblemausdrücken:Definition 3. Gegeben seien der Wert p des empirischen p-Quantils mit derEinschränkung für Perzentile und eine Folge X von Fließkommazahlen mit derKardinalität n. Das p-Quantil der Folge X ist die Lösung des Auswahlproblemsmit k = dnpe.

Für das Perzentil existieren verschiedene Definitionen. In dieser Arbeit wirddie sogenannte Nearest-rank Methode angewandt. Diese besagt, dass das p-tePerzentil einer aufsteigend sortierten Liste von n Zahlen der kleinste Wert ist,sodass nicht mehr als ein Anteil von p der Werte kleiner als das Perzentil undmindestens ein Anteil von p der Werte kleiner oder gleich dem Perzentil ist.Hiermit wird gewährleistet, dass das Ergebnis auch immer ein Element derEingabemenge und somit nicht interpoliert ist. Für weniger als 100 Werte istdie Anwendung dieser Methode jedoch problembehaftet, da es so nicht immermöglich ist, ein Element zu finden, das den Eigenschaften genügt.

3.4. Fließkommazahlen

Eine Fließkommazahl ist eine approximative Darstellung einer reellen Zahl. Indieser Arbeit werden stets die Standardisierungen und Definitionen aus IEEE-754 (IEEE 2008) angenommen. Demnach besteht eine Fließkommazahl aus denKomponenten:

• Vorzeichen s (1 Bit)

• Mantisse m (p Bits)

• Basis b (nach IEEE-754 : b = 2)

• Exponent e (r Bits)

20

3. Grundlagen

Aus diesen Komponenten kann die Dezimalrepräsentation einer Fließkommazahlerrechnet werden:

x = s ·m · be, wobei

s = (−1)S mit S ∈ {0, 1} ,

e = E −B mit E = Dezimalrepräsentation der Exponentenbits und

m = 1 +M

2pmit M = Dezimalrepräsentation der Mantissenbits

Die Werte für p, r und B hängen von dem Format der Fließkommazahl ab. Indieser Arbeit wurde festgelegt, dass stets mit dem 32-Bit-Binärformat gearbeitetwird. So gilt: p = 23, r = 8 und B = 127.

3.5. Verteilte Berechnung

Verteilte Berechnungen sind in heutigen Anwendungsszenarien oft essentiell,um große Datenmassen in kürzester Zeit verarbeiten zu können. Ab einemgewissen Punkt rentiert sich die vertikale Skalierung eines einzelnen Systemsnicht mehr, sodass mehrere Systeme parallel zum Einsatz kommen. Je nach Artder Aufgabe und Infrastruktur sowie Architektur der Systeme spricht man beiden Programmen, die darauf laufen, von parallelen oder verteilten Anwendungen.In dieser Arbeit liegt der Fokus auf verteilter Berechnung und somit auf verteiltenAnwendungen. Hier im speziellen werden vor allem solche Fälle betrachtet, dieeine Shared-Nothing-Architektur aufweisen, also lose gekoppelte Prozessoren mitjeweils eigenem lokalen Speicher. Dies hat den Vorteil, dass diese Systeme höherskalieren und somit die Anzahl der gekoppelten Rechner praktisch unbegrenztist (Bengel u. a. 2015).

21

3. Grundlagen

Die Hauptaufgabe bei verteilten Berechnungen ist dabei die Koordination vonvielen Rechnern an unterschiedlichen Orten um eine gemeinsame Problemstellungzu lösen. Die Rechner können dabei sehr unterschiedlich sein, müssen jedochüber ein Netzwerk von allen anderen Rechnern aus erreichbar sein (vgl. Bengelu. a. (2015)).

3.5.1. Abgrenzung zu paralleler Berechnung

Während die verteilte Berechnung vor allem darauf abzielt, viele Computerfür eine gemeinsame Aufgabe zu verknüpfen, geht es bei paralleler Berechnungeher darum, eine dedizierte Aufgabe schneller zu erledigen. Besonders in derWissenschaft werden oft sogenannte Supercomputer herangezogen, um sehraufwändige Rechenaufgaben in akzeptabler Zeit zu bewältigen. Ein signifikanterUnterschied zu verteilten Berechnungen ist die Ressourcennutzung. Während inparallelen Berechnungsumgebungen nur auf Ressourcen eines einzelnen Rechnerszugegriffen werden kann, sind diese bei verteilten Systemen stark verstreut. Somitist die Kommunikation von Daten zu anderen Rechnern eine der Hauptaufgabenbei verteilten Systemen, in parallelen Umgebungen jedoch der konkurrierendeZugriff auf dieselben Ressourcen. Außerdem sind parallelen Systemen Grenzenbei der (vertikalen) Skalierung gesetzt, während verteilte Systeme in den meistenFällen beliebig viele Computer ins System einspeisen können (vgl. Bengel u. a.(2015)).

3.5.2. Vorteile verteilter Systeme

Die folgenden Aussagen sind im Wesentlichen aus dem Werk von Bengel u. a.(2015) entnommen, sofern nicht anders angegeben.

Bei verteilten Systemen gibt es Problemsituationen, die in Parallelrechnernim Allgemeinen nicht vorkommen. Eine der Ursachen hierfür ist die notwendi-ge Kommunikation unter den einzelnen Knoten, die Fehler verursachen kann.Deshalb müssen verteilte Systeme gewisse Komponenten für die Korrektur sol-

22

3. Grundlagen

cher und weiterer Fehler besitzen, die wiederum als Vorteile verteilter Systemegesehen werden können:

• Ausfallsicherheit: Dadurch, dass jeder Rechner in einem verteilten Sys-tem eine autarke Komponente darstellt, ist ein Komplettausfall sehr un-wahrscheinlich. Deshalb kann man davon ausgehen, dass Ausfälle in ver-teilten Systemen immer partiell sind. Das heißt, dass trotz eines Ausfallsvon Komponenten andere Teile des Systems ihre Aufgabe weiter verfolgenkönnen.

• Fehlertoleranz: Rechnersysteme sind im Allgemeinen nie fehlerfrei.Durch verschiedenste Umstände können Fehler auftreten, die das Systemzum Absturz bringen könnten, würde es nicht darauf reagieren. Dadurch,dass man bei verteilten Systemen sehr auf die Kommunikation unter denKomponenten angewiesen ist, muss es möglich sein, mit verschiedenstenFehlern umzugehen, wie beispielsweise korrumpierten Nachrichten.

• Verfügbarkeit: Dadurch, dass die Komponenten meist redundant aus-gelegt sind, ist die Verfügbarkeit bei verteilten Systemen höher als beianderen Architekturen. Zusätzlich können die redundanten Komponentenzu einer Geschwindigkeitsverbesserung beitragen.

23

3. Grundlagen

3.5.3. Computercluster

Eine typische Umsetzung für ein verteiltes Rechensystem sind Computerclusteroder einfach Cluster. Dadurch, dass die horizontale Skalierung ab einem gewissenPunkt kostengünstiger ist, als ein paralleles System immer weiter aufzurüsten,sind der Leistung hier deutlich weniger Grenzen gesetzt. Schranken entstehenlediglich durch die Leistung der einzelnen Komponenten, die Geschwindigkeitdes Kommunikationsnetzes und den Aufwand zur Administration der einzelnenKomponenten, die den Cluster bilden. Im Allgemeinen ist ein Cluster eineVernetzung eigenständiger Rechner, die exklusiv für den Cluster auf einemgemeinsamen Datenbestand arbeiten. Die einzelnen Rechner, auch Knotengenannt, können dabei beliebig konfiguriert sein und müssen nicht alle dieselbenSpezifikationen besitzen (vgl. Bengel u. a. (2015)).

24

4. Technologien

Nachdem im vorherigen Kapitel notwendige Grundlagen für weitere Erläuterun-gen geschaffen wurden, sollen in diesem Teil die Technologien vorgestellt werden,die im Rahmen dieser Arbeit Verwendung fanden.

4.1. Apache Hadoop

Apache Hadoop ist ein Framework, das die verteilte Verarbeitung von großen Da-tenmengen über Computerclustern erlaubt, indem einfache Programmiermodellegenutzt werden. Das Framework selbst ist so entworfen, dass es hardware-unabhängig Fehler feststellen und darauf reagieren kann (vgl. Apache SoftwareFoundation (2018b)). Hadoop wird nur indirekt im Rahmen dieser Arbeit ge-nutzt, da für die Verteilung der Jobs Apache Flink dient.

4.1.1. HDFS

Das Hadoop Distributed File System (HDFS) ist ein verteiltes Dateisystem, dasDatenzugriff für Applikationen mit einem hohen Datendurchsatz bietet. DasHDFS ist fehlertolerant und so entworfen, dass es auf Customer Hardware läuft.Im Rahmen dieser Arbeit wird das verteilte Dateisystem genutzt, um die Test-daten für die Evaluierung abzulegen, sowie für die Ablage der Ergebnisse.

25

4. Technologien

4.1.2. YARN

Yet Another Resource Negotiator (YARN) ist ein Framework für Job Schedulingund Cluster Resource Management. Die grundlegende Idee ist es, die Funktio-nalitäten des Job Scheduling und Cluster Resource Management in separateProzesse aufzuteilen. YARN wird im Rahmen dieser Arbeit nur indirekt genutzt,da es bereits auf dem Galaxy Cluster, das in Kapitel 6 beschrieben wird, in-stalliert ist und läuft. Es dient als Schnittstelle für die Ausführung der ApacheFlink Jobs.

4.2. Apache Flink

Wenn es darum geht, eine Applikation für hoch-performante und verteilte Da-tenverarbeitungen zu entwickeln, ist Apache Flink eine der gängigsten Lösungen.Das eigentlich für Stream Processing entwickelte Framework bietet verschiedeneAPIs, unter anderem die Graph API für die Verarbeitung und Analyse vonGraphen, sowie die DataSet API, die im nachfolgenden Teilabschnitt vorgestelltwird. Im Allgemeinen kann man einen Flink Job, also ein Programm, das dieAPIs von Apache Flink nutzt, in folgende Teile untergliedern (vgl. ApacheSoftware Foundation (2018a)):

• Data Source: Ankommende Daten, die mittels Apache Flink verarbeitetwerden sollen.

• Transformations: Die über die Data Source angekommenen Daten wer-den verarbeitet und ggf. modifiziert.

• Data Sink: Das Ergebnis der Verarbeitung wird über eine Data Sinkzurückgegeben.

Apache Flink wird im Rahmen dieser Arbeit genutzt, um mit der DataSet APIdie Algorithmen zu implementieren, die in Kapitel 5 vorgestellt werden.

26

4. Technologien

4.2.1. Verteilte Laufzeitumgebung

Abbildung 4.1.: Prozesse in der verteilten Laufzeitumgebung von Flink. EinFlink-Programm wird vom JobManager entgegengenommen,optimiert und auf die TaskManager verteilt. Letztere bieteneinen oder mehrere TaskSlots für die Ausführung einzelnerOperationen. (Apache Software Foundation 2018a)

Grundsätzlich besteht ein Flink-Programm aus einer Reihe von Operationen, dieauf DataSets angewandt werden (siehe nächsten Abschnitt). Sofern möglich, fasstApache Flink solche Operationen zu sogenannten Tasks zusammen, diese jeweilsin einem Thread abgearbeitet werden. In Abbildung 4.1 aus der Dokumentationvon Apache Flink ist zu sehen, wie die einzelnen Komponenten bei ApacheFlink zusammenwirken und somit die verteilte Laufzeitumgebung verkörpern.Es gibt noch weitere Komponenten, auf die hier nicht eingegangen wurde,deren genauere Beschreibung in der Flink-Dokumentation (Apache Software

27

4. Technologien

Foundation 2018a) nachgelesen werden kann. Demnach gibt es zwei Arten vonProzessen in der Flink Laufzeitumgebung; der JobManager (auch: Master)steuert die Ausführung über die Koordination von Tasks, Kontrollpunkten undKorrekturen bei Fehlern. Es kann mehrere JobManager geben, wobei immernur einer tatsächlich steuert und die anderen im Stand-By-Modus laufen. Diesdient der Ausfallsicherheit und somit der Verfügbarkeit des gesamten Systems.Der TaskManager (auch: Worker) führt die Tasks aus. Zusätzlich werden vonihm Streams gepuffert und ausgetauscht (Apache Software Foundation 2018a).TaskSlots dienen der Kontrolle, wie viele Tasks ein TaskManager annehmen undparallel verarbeiten kann. Jeder TaskManager besitzt mindestens einen TaskSlot.In der Regel jedoch mehrere, die jeweils feste Ressourcen des zugrundeliegendenSystems zugeordnet bekommen. Die gesamte Anzahl der TaskSlots entsprichtder maximalen Parallelität in der ein Flink-Programm abgearbeitet werdenkann.

4.2.2. DataSet API

Die DataSet API in Apache Flink bietet die Möglichkeit endliche, also beschränk-te Daten zu verarbeiten. Intern werden DataSets als beschränkte Streams be-handelt und bieten somit die gleichen Möglichkeiten wie Streams. DataSetswerden initial von verschiedenen Datenquellen erstellt. Anschließend könnenbeliebig viele Transformationen darauf angewendet werden, wobei jeweils einoder mehrere DataSets als Eingabe einer Transformation definiert werden kön-nen. Diese gibt immer jeweils ein neues DataSet als Ergebnis der Modifikationenzurück. Nachdem die Transformationen abgeschlossen sind, kann das Ergebnisan eine Datensenke übergeben werden. Als Datenquellen und -senken könnenunter anderem Dateien in verteilten Dateisystemen dienen, sie können jedochauch selbst definiert werden.

28

4. Technologien

4.2.3. Iterative Algorithmen in Apache Flink

Iterative Algorithmen werden in vielen Kontexten und Umgebungen benötigt.Apache Flink bietet verschiedene Möglichkeiten, iterative Algorithmen massivparallel und verteilt zu implementieren. Im Rahmen dieser Arbeit wird vorallem die sogenannte Bulk Iteration genutzt. Vereinfacht ausgedrückt ist eineBulk Iteration die wiederholte Ausführung einer sogenannten Step-Funktion,solange die Abbruchbedingung nicht erreicht ist. Als Eingabe dient ein DataSetund zurückgegeben wird ebenfalls ein DataSet. Die genauere Beschreibung undAnwendung dieses Operators ist in Abschnitt 5.2 zu finden.

Als Abgrenzung zur Delta Iteration gilt für die Bulk Iteration, dass stets daskomplette Ergebnis aus der vorherigen Iteration als Eingabe für die nächste dient,während bei der Delta Iteration eine Unterscheidung zwischen Workset undSolution Set stattfindet. Während das Workset das tatsächlich zu verarbeitendeDataSet für eine Iteration darstellt, wird das Solution Set gegebenenfalls proDurchgang aktualisiert und am Ende daraus die Lösung gebildet.

Es existieren noch weitere Arten von Iterationen innerhalb der Flink API, aufdie nicht weiter eingegangen werden soll.

4.3. Redis

Die folgenden Angaben sind, sofern nicht anders angegeben, aus der Redis-Dokumentation (Redis labs 2018) entnommen. Redis (= Remote Dictionary Ser-ver) ist eine clusterfähige In-Memory-Datenbank in Form eines Key-Value-Stores.Persistenz wird von Redis durch automatisiertes, regelmäßiges Abspeichern oderdurch Protokolldateien unterstützt. Redis wird im Rahmen dieser Arbeit alsSpeicher für Metadaten während der Ausführung des vorgestellten Algorithmusgenutzt, da dies in Apache Flink bisher nicht möglich ist.

29

5. Algorithmen

Im Folgenden soll eine Reihe von Algorithmen vorgestellt werden, die vor allemdas Auswahlproblem lösen können. Wie in Kapitel 3 beschrieben, lässt sichdie Berechnung des Perzentils für eine Sequenz von Fließkommazahlen alsAuswahlproblem darstellen.

5.1. Sequentielle Berechnung

Zunächst einmal sollen Lösungen vorgestellt werden, die das Problem in Single-Node-Umgebungen, also sequentiell lösen. Wenn man die Klasse der externenAlgorithmen, also solche, die ebenso den externen Speicher nutzen können(vgl. Güting und Dieker (2018)), nicht berücksichtigt, stellt die Größe der zuverarbeitenden Daten eine Beschränkung für die Nutzbarkeit solcher Lösungendar. Nichtsdestotrotz sind diese Algorithmen wichtig und in einer Vielzahl vonApplikationen implementiert. Um das Restproblem des verteilten Algorithmus,der in Abschnitt 5.2 vorgestellt wird, zu lösen, könnte eine solche sequentielleBerechnung herangezogen werden.

5.1.1. Primitiver Ansatz

Wie in den Grundlagen (Kapitel 3) beschrieben, wird beim Auswahlproblemdas k-te Element einer sortierten Folge von Zahlen gesucht. Dadurch, dass dieEingabedaten im Allgemeinen nicht als vorsortiert angenommen werden können,wäre ein erster Ansatz, die Daten zunächst zu sortieren. Anschließend können die

30

5. Algorithmen

Elemente abgezählt werden, um das k-te Element der nun sortierten Daten zufinden. Wird eine entsprechende Datenstruktur genutzt, kann nach der Sortierungbereits direkt der Zugriff auf die gesuchte Zahl über einen Index erfolgen. Einsinnvolles Sortierverfahren wäre hier der QuickSort, der nach Güting und Dieker(2018) im Durchschnitt eine Laufzeitkomplexität von O(n log(n)) aufweist. Eswürde sich jedoch auch jedes weitere performante Sortierverfahren anbieten. DerQuickSort-Algorithmus wurde hier genannt, da er einerseits einer der schnellstenAlgorithmen zum Sortieren von Daten ist und andererseits nachfolgend einvom QuickSort abgewandelter Algorithmus für das Lösen des Auswahlproblemsvorgestellt wird.

5.1.2. QuickSelect

QuickSelect ist ein Algorithmus, der dediziert für die Lösung des Auswahl-problems entwickelt wurde. Das Verfahren stammt ebenfalls vom Entwicklerdes QuickSort, weist jedoch nach Eppstein (2007) eine durchschnittliche Lauf-zeitkomplexität von O(n) auf. Es existieren noch weitere, unter anderem aucheffizientere Lösungen für das Auswahlproblem. So könnte man beispielsweise eineDatenstruktur nutzen, in der die Daten immer sortiert vorliegen. Hier wäre dasAuswahlproblem schneller lösbar, jedoch wäre das Einfügen von neuen Datenineffizienter. Dadurch, dass solche Datenstrukturen in Apache Flink nicht ab-bildbar sind und, da auch die Basis des QuickSelect Algorithmus, der QuickSort,weit verbreitet ist, wurde der QuickSelect Algorithmus im Rahmen dieser Arbeitgewählt und implementiert.

Funktionsprinzip

Der allgemeine Ansatz ist der gleiche wie der des QuickSort. Hier wird eineFunktion für das Partitionieren der Liste in zwei Teile definiert; ein Teil, in demElemente liegen, die kleiner als das Pivot-Element sind und einer, in dem alleanderen Elemente liegen.

31

5. Algorithmen

Abbildung 5.1.: Gezeigt wird ein Beispielablauf des QuickSelect-Algorithmus.In jedem Schritt werden eine linke (= left), eine rechte (=right) Grenze, sowie ein Pivot-Element bestimmt. Anschließendwird sortiert und nur der Zweig verfolgt, in dem das gesuchteElement liegt. Als Eingabeparameter dienen eine Liste vonFließkommawerten und das gesuchte k (hier k = 6).

32

5. Algorithmen

In Abbildung 5.1 ist ein Beispielablauf zum QuickSelect zu sehen. Initial wirdbei einer gegebenen Liste von potentiell unsortierten Zahlen die linke Grenzel auf den ersten und die rechte Grenze r auf den letzten Wert gesetzt. Nunwird ein Pivot-Element zwischen l und r bestimmt. Hier gibt es verschiedeneAnsätze; in diesem Beispiel wurde die aufgerundete Mitte der Liste (p = l +

(r − l)/2) als Pivot-Element herangezogen. Nun wird jedes Element, das kleinerals das Pivot-Element ist, links davon einsortiert, jedes, das größer ist, rechtsdavon. Diesen Vorgang nennt man Partitionierung. Durch dieses Vorgehenlandet das Pivot-Element immer an genau der richtigen Stelle in der Liste. Nunwird geprüft, welche Position das Pivot-Element eingenommen hat. Liegt eszufällig auf Position k, wurde die Lösung gefunden und das Pivot-Element wirdzurückgegeben. Ist k < p, so wird die rechte Grenze auf p− 1 gesetzt und derAlgorithmus erneut ausgeführt. Im anderen Fall wird l auf p+1 gesetzt und mitdiesen Werten der Algorithmus erneut ausgeführt. So wird weiter vorgegangen,bis das gesuchte Element gefunden wurde; in diesem Beispiel die Zahl 6.

In Listing 5.1 ist die Implementierung der Partitionierung in Java zu fin-den.

Die Unterfunktion swap(list, idx1, idx2) tauscht in der gegebenen Liste dieElemente der Positionen idx1 und idx2. Im Allgemeinen ist dem Quellcode zuentnehmen, dass das Pivot-Element zunächst ans Ende der Liste sortiert wird.Anschließend werden alle Elemente, die kleiner als das Pivot-Element sind, inden linken Teil der Liste gesetzt. Am Ende der Partitions-Funktion wird nun dasPivot-Element nach dem zuletzt umsortierten Element eingefügt. Somit wird dasPivot-Element beim Partitionieren immer genau an die richtige Stelle der Listegesetzt. Beim QuickSort werden rekursiv immer beide Teile der Listen sortiert.Der QuickSelect jedoch verfolgt nur die Zweige, in denen auch tatsächlich dasgesuchte Element liegt. Darauf aufbauend sieht die Implementation für denQuickSelect-Algorithmus wie in Listing 5.2 zu sehen aus.

Die Funktion floor(value) gibt den abgerundeten Wert einer Zahl als Integerzurück. Im vorgestellten QuickSelect-Algorithmus wird die Funktion select so oftrekursiv aufgerufen bis letztendlich das gesuchte Element gefunden wurde. Dies

33

5. Algorithmen

int pa r t i t i o n (Lis t<Float> l i s t ,int l e f t ,int r i ght ,int pivotIndex

) {f loat pivotValue = l i s t . get ( p ivotIndex ) ;swap ( l i s t , p ivotIndex , r i g h t ) ;int s to r e Index = l e f t ;

for ( int i = l e f t ; i < r i gh t ; i++) {i f ( l i s t . get ( i ) < pivotValue ) {

swap ( l i s t , s tore Index , i ) ;s to r e Index++;

}}

swap ( l i s t , r i ght , s to r e Index ) ;

return s to r e Index ;}

Listing 5.1: Funktion partition bei QuickSort und QuickSelect

f loat s e l e c t ( L i s t<Float> l i s t , int l e f t , int r i ght , int k ) {i f ( l e f t == r i gh t ) {

return l i s t . get ( l e f t ) ;}

int pivotIndex = l e f t + f l o o r ( ( r i g h t − l e f t + 1) / 2 . 0 ) ;p ivotIndex = pa r t i t i o n ( l i s t , l e f t , r i ght , p ivotIndex ) ;

i f ( k == pivotIndex ) {return l i s t . get ( k ) ;

} else i f ( k < pivotIndex ) {return s e l e c t ( l i s t , l e f t , p ivot Index − 1 , k ) ;

} else {return s e l e c t ( l i s t , p ivot Index + 1 , r i ght , k ) ;

}}

Listing 5.2: QuickSelect-Algorithmus (rekursive Variante)

34

5. Algorithmen

ist der Fall, wenn entweder das richtig sortierte Pivot-Element an der Position k

in der Liste steht oder die durch die Rekursion verminderten Teillistengrößenbei 1 angekommen sind. Bis dies der Fall ist, wird immer die Teilliste verfolgt,in der der Wert für k liegen muss.

Dadurch, dass der Algorithmus in-place arbeitet, ist der Speicher-Overheadvernachlässigbar, vorausgesetzt, es existiert eine Endrekursions-Optimierung1.Da nicht davon ausgegangen wurde, dass diese immer unterstützt wird, wurdeeine Optimierung bei der Implementierung vorgenommen, die in Listing 5.3 zusehen ist. Durch die Schleife ist der Algorithmus nicht mehr rekursiv, arbeitetjedoch weiterhin in-place bei unveränderter Laufzeitkomplexität.

f loat s e l e c t ( L i s t<Float> l i s t , int r i ght , int k ) {int l e f t = 0 ;while ( true ) {

i f ( l e f t == r i gh t ) {return l i s t . get ( l e f t ) ;

}

int pivotIndex = l e f t + f l o o r ( ( r i g h t − l e f t + 1) / 2 . 0 ) ;p ivotIndex = pa r t i t i o n ( l i s t , l e f t , r i ght , p ivotIndex ) ;

i f ( k == pivotIndex ) {return l i s t . get ( k ) ;

} else i f ( k < pivotIndex ) {r i g h t = pivotIndex − 1 ;

} else {l e f t = pivotIndex + 1 ;

}}

}

Listing 5.3: QuickSelect-Algorithmus (iterative Variante)

1Eine Optimierung der Speicherverwaltung bei Rekursionen, die am Ende der Funktionstattfinden.

35

5. Algorithmen

5.2. Verteilter Algorithmus für das Auswahlproblem

Der Grund, warum die Lösung des Auswahlproblems bei Fließkommazahlen imVergleich zu natürlichen Zahlen eine besondere Herausforderung darstellt, ist diehohe Dichte der Fließkommazahlen vor allem im Bereich um 0. Für natürlicheZahlen gibt es einen relativ simplen parallelisierbaren Ansatz zur Berechnungvon Perzentilen (Swoboda 2017):

• Jeder Knoten erstellt ein Histogramm seiner Werte und liefert zusätzlichderen Gesamtanzahl zurück.

• Ein Knoten führt die Histogramme zusammen.

• Durch iteratives Aufsummieren der Kardinalitäten kann die richtige Stelleim Histogramm gefunden werden und das Auswahlproblem ist gelöst.

Während es jedoch bei einem Wertebereich von (0, 100] gerade einmal 100 ver-schiedene natürliche Zahlen gibt, was bedeutet, dass ein Histogramm mit nurmaximal 100 Klassen erstellt werden muss, gibt es nach IEEE-754 für dengleichen Wertebereich über 1,1 Milliarden verschiedene Zahlen (denormalisierteZahlen nicht berücksichtigt). Die Wahrscheinlichkeit, dass die Anzahl der Dupli-kate hier so hoch ist, dass mit der Histogramm-Methode ein signifikanter Vorteilentsteht, geht gegen null.

Deshalb muss für die Berechnung des Perzentils von Fließkommazahlen einneuer verteilter Ansatz gefunden und implementiert werden, was die Haupt-Problemstellung dieser Arbeit ist. Der Großteil der in Apache Flink imple-mentierten Lösung basiert dabei auf dem Werk von Saukas und Song (1998).Hier werden Algorithmen auf Basis des Coarse Grained Multicomputer (CGM)-Modells beschrieben, mit denen das Auswahlproblem gelöst werden kann. DasCGM-Modell bietet Möglichkeiten, parallele Berechnungen und Algorithmen zubeschreiben und zu klassifizieren. Es arbeitet mit zwei Eingabe-Parametern: Nund p, wobei N die Größe der Eingabedaten und p die Anzahl der Prozessorenbeschreibt. Jeder Prozessor kann hierbei auf einen eigenen lokalen Speicherzugreifen. „Coarse Grained“ (deutsch: grobkörnig) bedeutet dabei, dass N � p

36

5. Algorithmen

Abbildung 5.2.: Visualisierung des Ablaufs bei CGM: Jeder Prozessor berechnetseine Teillösung für den aktuellen Schritt. Anschließend kom-munizieren alle Prozessoren über einen Router miteinander ineiner Barrier Synchronization.

ist, was heißt, dass der Speicher pro Prozessor deutlich größer als O(1) sein muss.Die Prozessoren sind dabei über einen Router verknüpft, sodass sie sich Punkt-zu-Punkt-Nachrichten schicken können. Algorithmen, die mit dem CGM-Modellbeschrieben werden, bestehen aus einer Reihe abwechselnder Berechnungs- undKommunikationsrunden, welche durch eine sogenannte Barrier Synchronizationgetrennt sind. Abbildung 5.2 visualisiert hierbei den Ablauf.

Vergleicht man dieses Konzept mit Apache Flink, so kann man feststellen,dass die Iterationen in Apache Flink sehr ähnlich arbeiten. Hier vor allem die

37

5. Algorithmen

Bulk Iteration: Eine Schritt-Funktion (englisch step) wird in jeder Iterationausgeführt und bekommt als Eingabeparameter dabei das Ergebnis aus demvorherigen Schritt. Ist es der erste Durchgang, so wird die Eingabedatenmengeder Schritt-Funktion übergeben. Letztere berechnet nun das nächste Teilergebnis.In Abbildung 5.3 wird das in vier Schritten visualisiert:

1. Eingabedatenmenge: Wird der Schritt-Funktion bei der ersten Iterationübergeben.

2. Schritt-Funktion: Die Schritt-Funktion wird in jeder Iteration ausge-führt. Hier werden Operationen wie map, reduce, join, etc. durchgeführt.

3. Nächste Teillösung: Die Ausgabe der Schritt-Funktion wird in jeder Ite-ration der nächsten Ausführung der Schritt-Funktion als Eingabeparameterübergeben.

4. Iterationsergebnis: Die Ausgabe der letzten Iteration ist das finaleErgebnis des Iterationsoperators.

Abbildung 5.3.: Visualisierung des Iterate-Operator bei Apache Flink: EineSchritt-Funktion wird wiederholt ausgeführt, bis ein Beendi-gungskriterium erfüllt ist. Zu Beginn ist die komplette Daten-menge die Eingabe für die Schrittfunktion, bei jedem weiterenDurchlauf die Ausgabe der vorherigen Schrittfunktion. Am En-de wird ein Iterationsergebnis zurückgegeben (Apache SoftwareFoundation 2018a).

Die Iteration läuft dabei entweder solange, bis eine maximale Anzahl an Durch-läufen erreicht ist oder ein selbst definiertes Beendigungskriterium erfüllt wird.Apache Flink verteilt die Iteration dabei optimiert über alle verfügbaren Task

38

5. Algorithmen

Slots. Im Allgemeinen ist es dadurch möglich, die Algorithmen aus dem Werkvon Saukas und Song (1998) in Apache Flink zu implementieren. Die Unter-schiede zwischen parallelen und verteilten Berechnungen, welche in Abschnitt3.5 eruiert wurden, gleicht Apache Flink durch seine stabile Architektur aus.Eine Herausforderung stellt dabei jedoch die Kommunikation dar. Während dieArt, der Zeitpunkt und der Umfang der Kommunikation beim CGM definierbarist, führt Apache Flink die Kommunikation völlig transparent durch (ApacheSoftware Foundation 2018a). Dort einzugreifen ist über die API nicht möglich.Deshalb muss für CGM -Algorithmen, die nicht über die Kommunikation vonApache Flink abbildbar sind, eine Lösung gefunden werden.

Viele verteilte Programme lösen auf ihren Berechnungsknoten jeweils ein Teilpro-blem. Alle Teillösungen werden von einem einzelnen Knoten, oft der Hauptknoten(englisch Master), zur Berechnung der finalen Lösung genutzt. In diesem Fallist dies nach meinem Kenntnisstand nicht anwendbar, da das Auswahlproblemnur unter Betrachtung der kompletten Datenmenge exakt gelöst werden kann.Prinzipiell kann der im Rahmen dieser Arbeit entwickelte Algorithmus deshalbin zwei größere Schritte unterteilt werden: Die Verringerung der Datengrößeund die Lösung des Restproblems. Ersteres ist dabei sehr gut parallelisierbar,wie in den folgenden Abschnitten nachzulesen. Die Datenmenge wird dabeisoweit reduziert, bis das Restproblem sequentiell, also auf einem Knoten unterBerücksichtigung dessen Ressourcen, lösbar ist.

5.2.1. Ablauf des Algorithmus

Zunächst soll der Ablauf des in dieser Arbeit vorgestellten Algorithmus beschrie-ben werden.

Verringerung der Datengröße

Um die Datengröße der Eingabemenge A verringern zu können muss ein Me-chanismus gefunden werden, der das Endergebnis nicht verfälscht und zugleich

39

5. Algorithmen

parallelisierbar ist. Hierzu dient die von Saukas und Song (1998) vorgestellteVorgehensweise: Jeder Knoten berechnet den Median seiner Teilmenge der Ein-gabedaten, woraufhin der Master daraus einen gewichteten Median M , wie vonCormen u. a. (2005) beschrieben, errechnet. M muss dabei folgender Eigenschaftentsprechen:

n

4≤ rank(M,A) ≤ 3n

4(5.1)

Anschließend wird die Eingabemenge in drei Teile untergliedert: Zahlen diekleiner (Al), gleich (Ae) oder größer (Ag) dem gewichteten Median M sind. Mwird im Werk von Cormen u. a. (2005) definiert und von den Autoren Saukasund Song (1998) wie folgt angewandt:

Gegeben seien p verschiedene Elemente m1,m2, ...,mp mit zugehörigen positivenGewichten w1, w2, ..., wp, sodass

∑1≤i≤pwi = 1. Der gewichtete Median M ist

das Element mk, das die Eigenschaften∑

i,mi<mkwi ≤ 1

2 und∑

i,mi>mkwi ≤ 1

2

erfüllt. Dabei sind die Elemente mi für 1 ≤ i ≤ p die Mediane der Werte, die deneinzelnen Berechnungsknoten zugeordnet sind und wi der Anteil der Werte einesBerechnungsknoten in Relation zur Gesamtmenge: wi =

niN für 1 ≤ i ≤ p.

Da die Berechnung des gewichteten Medians M in dieser Arbeit eine signifikanteRolle spielt, ist in Listing 5.4 die Implementierung dieser Berechnung in derProgrammiersprache Java zu sehen. Um konsistent mit den bisherigen Erläute-rungen zu bleiben, wurden dort die gleichen Bezeichnungen wie zuvor verwendet.Im Allgemeinen ist das Prinzip dieser Funktion, dass sie einmal durch alle ihrübergebenen Mediane mk iteriert und für diese die Summe derjenigen Medianemi, die kleiner (= sumLess), bzw. größer (= sumGreater) als mk sind, bildet.Sind beide Summen kleiner oder gleich 0.5, wird das Element mk als gewichteterMedian M zurückgegeben. Wenn nicht, wird die Iteration fortgeführt. Laut Sau-kas und Song (1998) existiert bei jeder Iteration des vorgestellten Algorithmusein solches Element mk, das diese Eigenschaften erfüllt.

In Abbildung 5.4 wird gezeigt, wie die gesamte Datenmenge anhand von M

eingeteilt wird. Für ein besseres Verständnis des Algorithmus wurde ebenfalls

40

5. Algorithmen

f loat calculateWeightedMedian ( f loat [ ] medians , f loat [ ] we ights ) {for ( int k = 0 ; k < medians . l ength ; k++) {

f loat mk = medians [ k ] ;f loat sumLess = 0 .0 f ;f loat sumGreater = 0 .0 f ;for ( int i = 0 ; i < medians . l ength ; i++) {

f loat mi = medians [ i ] ;f loat wi = weights [ i ] ;i f (mi < mk) {

sumLess += wi ;} else i f (mi > mk) {

sumGreater += wi ;}

}

i f ( sumLess <= 0.5 f && sumGreater <= 0.5 f ) {return mk;

}}

return 0 .0 f ;}

Listing 5.4: Funktion für die Berechnung des gewichteten Medians M

Abbildung 5.4.: Aufteilung der Datenmenge nach M . In Al liegen die Elemente,die kleiner als M sind. In Ae und Ag die Elemente, die gleich,respektive größer M sind.

41

5. Algorithmen

beispielhaft eingezeichnet, wo sich der Wert k befinden könnte. Gegeben seiennun L, E und G als Kardinalitäten der Teilmengen Al, Ae und Ag. Liegt k wiebeispielhaft eingezeichnet innerhalb der Menge Al, so ist k ≤ L. In diesem Fallesind die Elemente aus Ae und Ag für die weitere Betrachtung irrelevant undkönnen verworfen, sowie N auf den Wert von L geändert werden. Der Wert fürk muss hier nicht verändert werden, da das gesuchte Element in diesem Fallseine Position nicht geändert hat. Liegt k jedoch innerhalb der Menge Ae, alsoist L < k ≤ L + E, so wurde die Lösung M gefunden. Als dritten Fall kannk innerhalb der Menge Ag liegen. Dies ist der Fall, wenn k > L+ E ist. Hierkönnen die Elemente aus den Mengen Al und Ae verworfen werden, es müssenjedoch auch hier N auf den Wert von G und k auf k− (L+E) geändert werden,da auch die Position des gesuchten Elementes hier nach vorne wechselt.

Durch diese Vorgehensweise entsteht in jedem Iterationsschritt ein neues Aus-wahlproblem, das zu dem im vorherigen Schritt äquivalent ist, das heißt dasgleiche Ergebnis liefert. Zusätzlich gewährleistet die Eigenschaft aus Gleichung5.1, dass in jedem Durchgang die insgesamt betrachtete Datenmenge um 1

4 re-duziert wird. Weitere Betrachtungen und Beweise hierzu können zur Vertiefungim Werk von Saukas und Song (1998) nachgeschlagen werden.

Lösung des Restproblems

Nachdem die Datengröße in mehreren Schritten soweit reduziert wurde, dass dieverbleibenden Daten auf einem Rechner sequentiell verarbeitet werden können,muss nun noch das Restproblem gelöst werden. Sowohl N , als auch k können sichwährend der Datenreduzierung verändert haben. Das heißt, dass nun ein anderesAuswahlproblem sequentiell gelöst wird, als es ursprünglich verteilt gefordertwar. Wie schon zuvor erwähnt, wurde jedoch die Art der Datenreduzierungso durchgeführt, dass das ursprüngliche Auswahlproblem und das durch dieDatenreduktion erzeugte zueinander äquivalent sind.

Um das Restproblem nun lösen zu können, gibt es viele Möglichkeiten. Einprimitiver Ansatz (5.1.1), sowie der sogenannte QuickSelect-Algorithmus (5.1.2)

42

5. Algorithmen

wurden in diesem Kapitel vorgestellt. Wie im nachfolgenden Abschnitt 5.2.2nachzulesen ist, wird keine dieser Varianten für das Restproblem in der Imple-mentierung mittels Apache Flink herangezogen, da die in dieser Masterarbeitgenutzten Technologien dies nicht unterstützen.

5.2.2. Implementierung

Im Folgenden soll erläutert werden, wie der Algorithmus aus Abschnitt 5.2mittels Apache Flink umgesetzt wurde. Zunächst wird hier auf das Problemeingegangen, das bereits im vorhergehenden Abschnitt erwähnt wurde:

Die Werte für k und N müssen während der Iteration geändert werden. ApacheFlink bietet jedoch keine Möglichkeit, Metadaten während einer Iteration mit zuverwalten. Das Einzige, das sich währenddessen ändern kann, ist die Datenmenge,die der Iteration zugrunde liegt. Für dieses Problem gibt es nach meinemKenntnisstand zwei Lösungsmöglichkeiten:

• Die Metadaten werden als Teile des Tupels eines Wertes mit durchgeschlif-fen. Das heißt, jeder Wert in der Datenmenge besteht aus einem 3-Tupel(f, k,N) mit f als einer der Fließkommazahlen. Dies hat jedoch einenerheblichen Einfluss auf das Speicherverhalten des Algorithmus, da nun inetwa die dreifache Menge an Arbeitsspeicher verbraucht wird. Dies wirdin der Evaluation im nächsten Kapitel aufgegriffen.

• Die Metadaten werden über einen externen Speicher verwaltet. Dieser mussvon allen Knoten aus lesend und schreibend zugreifbar sein. Threadsichermuss dieser Speicher nicht sein, da die Werte im Daten-Reduktions-Vorganggeändert werden, was bei Apache Flink wie eine Art Barrier Synchroniza-tion durchgeführt wird. Dadurch wird das Schreiben der Werte nicht vonmehreren Threads parallel durchgeführt, sondern nur einmal pro Iteration.

Im Rahmen dieser Arbeit wurden beide Varianten implementiert, um die Ansätzein der Evaluation gegenüberzustellen. In Kapitel 6 kann dabei nachgelesenwerden, dass die zweite Lösung deutlich performanter arbeitet, weshalb im

43

5. Algorithmen

Folgenden vor allem auf diese Implementation eingegangen werden soll. Alsexterner Speicher wurde Redis verwendet, ein Key-Value-Store, der in Abschnitt4.3 beschrieben wurde. Zusätzlich zu den Werten für k und N , werden währendder Ausführung des Algorithmus noch weitere Werte in Redis gespeichert. Hierzuzählen der Wert für T , der Schwellwert, ab dessen Unterschreitung sequentiellweitergearbeitet werden kann, r, der Indikator, ob im letzten Durchlauf dieLösung „zufällig“ gefunden wurde und R, das Ergebnis der Ausführung.

Lesen der Daten

Das im Rahmen dieser Masterarbeit entwickelte Java-Programm ist in der Lage,Daten von einem HDFS zu lesen. Die Eingabe-Dateien liefern dabei je Zeile eineFließkommazahl, die einzulesen ist. Die Informationen, wie die Dateien zu ladensind, müssen dem Programm als Kommandozeilenargumente übergeben werden.Die Verarbeitung übernimmt dabei Apache Flink, dessen API Möglichkeitenzum Einlesen von Dateien aus einem HDFS bietet. Die Anzahl der einzulesen-den Werte muss dabei initial bekannt sein und dem Programm ebenfalls alsKommandozeilenargument übergeben werden. Der entwickelte Flink-Job istzusätzlich in der Lage, direkt vor der Ausführung eine definierbare Anzahl anWerten zufällig zu generieren. Es ist auch möglich, bei der Generierung von Ein-gabedaten verschiedene Parameter zu setzen. So können, um die Korrektheit desAlgorithmus zu überprüfen, Zufallsdaten einer Exponentialverteilung generiertwerden. Weiterhin können vorsortierte Wertemengen generiert werden.

Nach dem Lesen der Dateien, wird Redis mit den initialen Metadaten beschrieben.Dazu gehören k, N und T . Dies geschieht noch sequentiell bevor der Flink-Joboptimiert über alle Knoten hinweg verteilt wird.

44

5. Algorithmen

Abbildung 5.5.: Gezeigt wird die Berechnung des gewichteten Medians M in-nerhalb des vorgestellten Algorithmus. Hier werden die obengezeigten Datentransformationen ausgeführt und es resultierendie unten gezeigten Ergebnisse.

45

5. Algorithmen

Berechnung von M

In Abbildung 5.5 ist der Programmablauf bei der Berechnung des gewichte-ten Medians M zu sehen. Hier werden die Daten zunächst zufällig über alleverfügbaren TaskSlots verteilt (partitioniert) und die Teilmengen auf jedemKnoten sortiert. Anschließend werden die Werte gezählt und der Median proPartition berechnet. Die Ergebnisse, die jeweils aus einem Tupel (mi, ni) mitmi der Median pro Partition und ni die Anzahl der Werte pro Partition für1 ≤ i ≤ p bestehen, werden nun von einer Map-Funktion mit den Gewichtenwi (siehe Abschnitt 5.2.1) pro Partition angereichert. Abschließend berechnetdie Reduce Group-Funktion den gewichteten Median M nach den Vorgaben ausAbschnitt 5.2.

46

5. Algorithmen

Abbildung 5.6.: Iteration im vorgestellten Algorithmus: Oben werden die Artder Transformationen und unten die Struktur der Ergebnissegezeigt.

47

5. Algorithmen

Iteration

Die Iteration des Algorithmus basiert maßgebend auf der Berechnung des ge-wichteten Medians. Eine Map-Funktion nimmt nun die Eingabedaten und dengewichteten Median M entgegen und bildet jede Fließkommazahl auf ein Tupel(l, e, g) mit l, e, g ∈ {0, 1} ab, wobei l = 1 bedeutet, dass der aktuelle Wertkleiner, als M ist. Die Werte von e und g bedeuten, dass der aktuelle Wertgleich respektive größer dem gewichteten Median ist. Mit der nachfolgendenReduce-Funktion, werden die einzelnen Tupel positionsweise addiert, woraus dasTupel (L,E,G) entsteht. Letzteres, sowie der gewichtete Median, als auch dieEingabedatenmenge werden nun von einer Filter -Funktion entgegengenommen,die die Datenmenge in jedem Iterationsschritt reduziert. Hierfür wird geprüft,wo sich k in Relation zu L, E und G, wie in Abschnitt 5.2 beschrieben, be-findet. Auf Basis dieser Prüfung ergibt sich die Reduktion der Datenmengeentweder, indem die kleineren und gleichgroßen Elemente oder die größeren undgleichgroßen Elemente im Vergleich zu M entfernt werden. Wird stattdessendas Ergebnis direkt gefunden, verbleibt nur dieses in der Datenmenge für dennächsten Schritt. Das Abbruchkriterium für die Flink-Iteration berücksichtigtauch, dass das Ergebnis während der Datenreduktion zufällig gefunden werdenkann.

48

5. Algorithmen

Abbildung 5.7.: Es wird gezeigt, wie das Restproblem innerhalb des vorgestelltenAlgorithmus gelöst wird. Oben stehend die Datentransformatio-nen, an der Unterseite die resultierenden Daten.

49

5. Algorithmen

Restproblem

Um das Restproblem zu lösen wurde keiner der bisher vorgestellten Ansätzeherangezogen, da diese nicht ohne Weiteres in Apache Flink umsetzbar sind.Dies liegt daran, dass sich die Ansätze nicht in dieser Form parallelisieren odergar verteilen lassen. Stattdessen wurde eine Datentransformation definiert, diealle verbleibenden Daten mit einer Parallelität von 1 partitioniert. Dies sichertzu, dass nun alle verbleibenden Zahlen auf einem Knoten liegen. Anschließendwird mit der Flink-internen sortPartition(...)-Funktion die komplette Da-tenmenge aufsteigend nach Wert sortiert. Zuletzt wird für die Partition eineMap-Funktion ausgeführt, die den aktuellen Wert von k aus Redis liest und denk-ten Wert aus der sortierten Liste der Daten nimmt und als einziges Element ei-nes DataSets zurückgibt. Dieser Ablauf ist in Abbildung 5.7 visualisiert. Für denFall, dass das Ergebnis zufällig gefunden wurde, wird diese Datentransformationnicht mehr ausgeführt.

Speichern des Ergebnisses

Das Ergebnis, das aus der Ausführung des Flink-Jobs resultiert, kann zu Test-zwecken entweder direkt in der Konsole ausgegeben oder in der Produktionsum-gebung ins HDFS zurückgeschrieben werden. Auch hier lässt sich der Speicherortals Kommandozeilenargument übergeben. Die Daten können dann von anderenProgrammen weiterverwendet werden.

50

6. Evaluation

Nachdem im letzten Kapitel ein Algorithmus entwickelt wurde, der das Problemder verteilten und exakten Berechnung von Perzentilen für Fließkommazahlenlöst, soll im nachfolgenden Kapitel evaluiert werden, welche Laufzeiteigenschaftener besitzt. Hier sollen mitunter die Skalierbarkeit für verschiedene Parallelitätenund Datengrößen getestet, aber auch Vergleiche zu anderen ähnlich arbeiten-den Algorithmen angestellt werden, um eine Aussage über die Qualität desentwickelten Algorithmus treffen zu können.

Im Folgenden wird die Parallelität mit der Anzahl der Threads definiert. EinThread ist die kleinste ausführende Einheit innerhalb eines Computer-Systems(Oechsle 2018). Im Kontext von Apache Flink kann dieser Begriff auf dennachfolgenden Seiten mit TaskSlot gleichgesetzt werden und beschreibt dieParallelität der Ausführungsumgebung.

Ein grober Vergleich der drei vorgestellten verteilten Ansätze zur Berechnung desPerzentils ist in Abbildung 6.4 (Seite 61) zu sehen. Hier werden die Laufzeitenfür die Ausführung bei 107 Fließkommazahlen jeweils bei einer Parallelität von32 und 64 Threads gezeigt. Es ist deutlich zu sehen, dass unter allen gezeigtenImplementationen der in dieser Arbeit vorgestellte Algorithmus am bestenperformt.

6.1. Testumgebung

Zunächst soll die Umgebung vorgestellt werden, innerhalb der die Tests für dieEvaluation stattfanden.

51

6. Evaluation

6.1.1. Hardware

Prozessor 2x 6-Core CPUs (Intel Xeon E5-2620 v3, 2.4 GHz)Hauptspeicher 128 GB RAM (DDR4, ECC)

Festplatte 6x 4 TB HD (SATA)Netzwerk 10 GBit/s Ethernet

Betriebssystem CentOS 7.3Dateisystem XFS/ZFS

Tabelle 6.1.: Galaxy Cluster: Konfiguration pro Knoten

Um zuverlässige Aussagen ohne verfälschte Ergebnisse treffen zu können, wurdevom ScaDS Leipzig der Zugang zum Big-Data-Cluster Galaxy gewährt. Er„besteht aus 90 Supermicro-Servern mit über 1.000 Cores, über 11 TerabyteRAM und über 2 Petabyte Speicher“ (URZ Leipzig 2017). Der Cluster istin einer Shared-Nothing-Architektur aufgebaut und konfiguriert. So könnendarauf massiv parallele Berechnungen mit aktuellen Big-Data-Technologiendurchgeführt werden. Jeder Knoten im Cluster setzt sich dabei wie in Tabelle6.1 dargestellt zusammen (vgl. (URZ Leipzig 2017)). Im Rahmen der Evaluationdes in dieser Arbeit beschriebenen Algorithmus konnten Tests auf zwölf solcherKnoten in einer geteilten Umgebung durchgeführt werden. Das heißt, es konntenauch andere Nutzer freie Ressourcen auf denselben Knoten mit nutzen. Diein den nachfolgenden Abschnitten vorgestellten Tests wurden daher auf viersolcher Knoten mit exklusiven Zugriffsrechten durchgeführt, um Verfälschungender Ergebnisse aufgrund gleichzeitiger Ressourcen-Nutzung zu vermeiden.

6.1.2. Parameter und Datenmengen

Wie in Abschnitt 5.2 erwähnt, können dem vorgestellten Programm eine Rei-he an Eingabeparametern übergeben werden. Entsprechend vielseitig könnenExperimente unter verschiedensten Annahmen durchgeführt werden. Im Rah-men der Evaluation der Algorithmen wurden hier verschiedene Perzentile(q ∈ {1, 25, 50, 75, 99}) und Parallelitäten (p ∈ {1, 2, 4, 8, 16, 32, 64}) getes-tet. Weiterhin wurden vorab Eingabedaten verschiedener Kardinalitäten und

52

6. Evaluation

Verteilungen generiert. Hierfür wurden Generatoren implementiert, die zufälligverteilte, exponential verteilte, aufsteigend vorsortierte, absteigend vorsortierteund gleiche Werte generieren. Exponential verteilte Werte helfen, die Korrektheitdes Algorithmus zu prüfen, da sich das tatsächliche (nicht empirische) Quantilbei Exponentialverteilungen leicht berechnen lässt. Für alle Werteverteilungenwurden dabei Testdateien generiert, die jeweils eine festgelegte Anzahl N anFließkommazahlen enthalten (N ∈ {106, 107, 108, 109, 1010}).

6.2. Skalierbarkeit

Einer der wichtigsten Tests in der Evaluation eines parallelen oder verteiltenAlgorithmus ist der, wie skalierbar er ist. Darunter versteht man im Big-Data-Kontext in der Regel, wie sich die Laufzeit eines Programmes ändert, wenn mandas zugrundeliegende System verbessert. Dabei gibt es die vertikale Skalierung(engl. scale up), bei der man einen Knoten selbst leistungsfähiger gestaltet,beispielsweise durch Hinzufügen von CPUs oder RAM. Außerdem gibt es die ho-rizontale Skalierung (engl. scale out), bei der einfach weitere Knoten zum Systemhinzugefügt werden, um mehr Leistung nutzen zu können (Bondi 2000).

Hier wurde ausschließlich die horizontale Skalierbarkeit des Algorithmus getestet,da dies bei hoch verteilten Aufgaben mehr von Bedeutung ist. In Abbildung 6.1sind die Ergebnisse bei horizontaler Skalierung des Systems zu sehen. Dabei wur-de die Anzahl der Threads auf der logarithmisch skalierten x-Achse abgetragen,während die linearen y-Achsen die Laufzeit des Programmes in Sekunden zeigen.Wie man dem Diagramm entnehmen kann, gibt es bei einer Eingabemenge von10.000.000 Fließkommazahlen eine Verbesserung der Laufzeit mit Steigerungder Parallelität bis 32 Threads. Danach erhöht sich die Laufzeit. Das hängtvor allem mit dem Kommunikations-Overhead zusammen, da bei 64 Threadsnur noch verhältnismäßig wenige Fließkommazahlen (< 160.000) pro Threadbearbeitet werden, kann hier die Rechenleistung nicht voll ausgeschöpft werden.In Abschnitt 6.4.1 wird gezeigt, dass Größenordnungen bis über 107 Wertenvon einem Thread performant verarbeitet werden können. Bekräftigt wird das

53

6. Evaluation

1 2 4 8 16 32 640

10

20

30

40

50

Threads

Laufzeitin

s

107 Werte

260

280

300

320

340

360

Laufzeitin

s

107 Werte109 Werte

Abbildung 6.1.: Laufzeiten des Algorithmus bei steigender Thread-Anzahl fürunterschiedlich große Datenmengen. Auf der linken Seite dieLaufzeiten in Sekunden für 107 Werte, auf der rechten Seitedie Laufzeit in Sekunden für 109 Werte. An der Unterseite derGrad der Parallelität in Threads.

durch die Versuche mit einer höheren Anzahl an Eingabedaten, was durch diezweite Linie im Diagramm visualisiert wurde: Hier gibt es auch bei höhererParallelität als 32 Threads noch eine deutliche Verbesserung der Laufzeit. Zubeachten ist hier, dass die Datenmenge bei der Konfiguration der Knoten zugroß für weniger als 16 Threads ist, da während der Experimente beobachtetwerden konnte, dass Apache Flink die Daten nicht immer gleichmäßig auf allephysischen Rechner verteilt und die gesamte Datenmenge so unter Umständenalle auf einem Knoten liegen könnte. Eine definitive Begründung hierfür konnteim Rahmen dieser Arbeit nicht gefunden werden, könnte jedoch in zukünftigenForschungen näher untersucht werden.

54

6. Evaluation

6.3. Veränderung der Datengröße

Im Big-Data-Bereich ist die Änderung der Laufzeit eines Programmes bei derVeränderung der Datengröße der Eingabemenge eine wichtige Beobachtung. DieAlgorithmen sind hier oft darauf spezialisiert vor allem bei vielen Daten guteLaufzeiten aufzuweisen. Deshalb wurde auch der in dieser Arbeit vorgestellteAlgorithmus mit verschiedenen Eingabegrößen getestet.

107 108 109 10100

100

200

300

# Werte

Laufzeitin

s

32 Threads64 Threads

Abbildung 6.2.: Laufzeiten des Algorithmus bei steigender Werte-Anzahl. Aufder linken Seite die Laufzeiten in Sekunden für 32 Threads(blau) und für 64 Threads (rot). An der Unterseite die Anzahlder Werte in der Eingabedatenmenge.

Die Ergebnisse sind in Abbildung 6.2 zu sehen. Auch hier wird eine logarithmischskalierte x-Achse gezeigt, auf der diesmal die Anzahl der Fließkommazahlenabgetragen ist. Die lineare y-Achse zeigt auch hier die Laufzeit des ausgeführtenProgrammes in Sekunden. Weiterhin wurden zwei Wertegruppen abgetragen:zum einen die Veränderung bei 32 und zum anderen die Veränderung bei 64Threads. Man kann direkt sehen, dass sich beide sehr ähnlich verhalten. ZuBeginn nimmt die Laufzeit bei Verzehnfachung der Eingabedaten nur in etwaum das Zweieinhalbfache zu. Beim nächsten Schritt um ca. das Sechsfache und

55

6. Evaluation

zuletzt noch einmal um lediglich 15-20 Prozent. Der Grund hierfür ist, dass beikleineren Datenmengen viel kommuniziert werden muss und die TaskSlots beisehr großen Datenmengen stark ausgelastet sind. Das heißt, der Algorithmuskann sehr gut mit steigenden Eingabegrößen umgehen. Bei großen Datenmengenzeigt sich sogar, dass auch mit 64 Threads noch ein signifikanter Performance-Vorteil besteht. Hier muss jedoch erwähnt werden, dass auch das Laden der Datenbei steigender Datengröße einen erheblichen Einfluss auf die Laufzeit besitzt(siehe Tabelle 6.2). Hier ist zu erkennen, dass die Ladezeiten bei Steigerung derAnzahl der Werte, die zu laden sind, überproportional ansteigen. Dies liegt vorallem daran, dass die Anzahl der Threads, die die Daten gleichzeitig vom HDFSeinlesen können, durch die sogenannte Block Size beschränkt ist. Dies ist dieGröße der einzelnen Datenblöcke, auf die eine große Datei im HDFS aufgeteiltwird. Dies bewirkt, dass die Geschwindigkeit des Einlesens sinkt, je größer dieeinzulesende Datei ist. Dabei ist zu erwähnen, dass Tests mit mehr als einerMilliarde Werten nur selten erfolgreich durchliefen, was sich dadurch äußerte,dass das Flink-Programm unter anderem wegen Timeouts oder auch wegenSpeicherüberläufen abstürzte. Dies lag vor allem an der großen Datenmengeverteilt auf nur vier Knoten und daran, dass Apache Flink die Daten nichtgleichmäßig auf alle Knoten verteilt.

Anzahl der Zahlen Ladezeiten10.000.000 2s

100.000.000 7s1.000.000.000 1min 12s

10.000.000.000 > 25min

Tabelle 6.2.: Evaluation: Ladezeiten nach Größe der Eingabemengen.

56

6. Evaluation

6.4. Vergleich zu anderen Ansätzen

Da es für die exakte und verteilte Berechnung von Perzentilen für Fließkomma-zahlen bisher nach meinem Kenntnisstand keinen weiteren außer die vorgestelltenAnsätze gibt, wurden verschiedene andere Algorithmen zum Vergleich heran-gezogen, um den neuen Ansatz dennoch anhand der Laufzeiten einordnen zukönnen.

6.4.1. Sequentielle Berechnung

1 · 106 4 · 106 16 · 106 64 · 106 256 · 106

0

10

20

30

40

50

# Werte

Laufzeitin

s

Abbildung 6.3.: Laufzeiten des QuickSelect bei steigender Werte-Anzahl. An derlinken Seite die Laufzeit des Programms in Sekunden. An derUnterseite die Anzahl der Werte in der Eingabedatenmenge.

Die sequentielle Berechnung der Perzentile wurde mit dem in Abschnitt 5.1.2beschriebenen QuickSelect-Algorithmus umgesetzt und getestet. Dadurch, dassdie sequentielle Berechnung auf nur einem Knoten läuft, gibt es Beschränkungenbei der Datengröße: Tests waren nur bis 256.000.000 Fließkommazahlen möglich,was eines der Hauptprobleme bei bisherigen Ansätzen ist und durch den indieser Masterarbeit vorgestellten Algorithmus gelöst wird. Ein durchschnittli-

57

6. Evaluation

ches Laufzeitverhalten von O(n log(n)) konnte während der Evaluation nichtbeobachtet werden. Jedoch ist dieser Ansatz bis zu einer Größenordnung von108 Fließkommazahlen deutlich schneller als der in dieser Arbeit vorgestellteAlgorithmus. Dies war jedoch zu erwarten und die gezeigte Lösung wurde vorallem entwickelt, um generell eine verteilte Berechnung für das Perzentil bietenzu können. Bei Datenmengen von mehr als 256 · 106 Zahlen jedoch weist derQuickSelect höhere Laufzeiten als der entwickelte Algorithmus auf.

6.4.2. Approximative Berechnung

Viele Big Data und Datenanalyse Systeme und Frameworks bieten für dasPerzentil beziehungsweise das Quantil approximative Berechnungen an. So gibtes zum Beispiel bei Googles BigQuery System die Funktion APPROX_QUANTILES,welche „die ungefähren Grenzen für eine Gruppe“ (Google 2018) zurückgibt. DieAnzahl der zu erstellenden Quantile ist dabei anzugeben. Wie genau das Systemdiese approximativen Grenzen berechnet, wird nicht angegeben. Weiterhinexistiert für KairosDB ein PercentileAggregator, der mittels Aggregationeine definierte Anzahl an zufälligen Werten von der Eingabemenge entnimmtund daraus das Perzentil sequentiell berechnet. Dieser Ansatz hat jedoch zumNachteil, dass er nicht für alle Verteilungen repräsentativ ist. Dennoch wurdeim Rahmen dieser Arbeit entschieden, diesen Ansatz für einen Vergleich miteiner approximativen Implementation heranzuziehen, da KairosDB mittlerweileeine hohe Verbreitung in der Big Data Welt genießt (KairosDB 2018). Esist zu betonen, dass diese Ansätze alle lediglich eine ungefähre Berechnungvon Perzentilen bieten. Die Fehlertoleranz variiert hierbei je nach Art derLösung.

Hierzu wurde, um gute Vergleichsbedingungen zu gewährleisten, ebenfalls inApache Flink ein Algorithmus entwickelt, der zunächst der Eingabemenge einedefinierbare Anzahl an zufälligen Werten entnimmt, welche klein genug ist,sodass das Restproblem sequentiell gelöst werden kann. Anschließend wird dasRestproblem mit dem gleichen Verfahren, wie in Abschnitt 5.2.1 vorgestellt,gelöst. Hier kommt ein Nachteil, solche Algorithmen mit Apache Flink zu imple-

58

6. Evaluation

mentieren, zur Geltung: Es ist nicht performant, in Apache Flink eine genaueAnzahl an Werten der Eingabemenge zu entnehmen. In der Implementierungwurde das in Abschnitt 3.2 vorgestellte Reservoir Sampling verwendet, umder Eingabemenge eine Stichprobe von k Elementen zu entnehmen. Hier mussApache Flink dennoch über alle Elemente „iterieren“, was zur Folge hat, dassdieser Algorithmus höhere Laufzeiten als der im Rahmen dieser Arbeit entwi-ckelte verteilte Algorithmus hat, was durch Abbildung 6.4 verdeutlicht wird. Diegenauen Zahlen können der Tabelle A.2 im Anhang entnommen werden.

6.4.3. Berechnung ohne Redis

Der erste Ansatz für einen Algorithmus im Rahmen dieser Masterarbeit verwen-dete das Redis-System nicht als Speicher für die Metadaten. Da Apache Flinkjedoch keine Möglichkeit bietet, Daten außerhalb des DataSets während derIteration zu verändern, wurde das Programm so umgesetzt, dass die Metadatenin jedem Tupel der Daten enthalten sind. Hierfür wurde eine Map-Funktiongeschrieben, die als Eingabeparameter k und N erhält und somit jede Fließkom-mazahl in der Eingabedatenmenge zu einem 3-Tupel (f, k,N) abbildet, wobeif eine der Fließkommazahlen ist. In jedem Entscheidungsschritt, also der Teildes Algorithmus, wo k mit den Kardinalitäten von Al, Ae und Ag verglichenwird, werden die Werte für k und N für jedes Tupel der betrachteten Mengeaktualisiert. Dies geschieht mit einer MapPartition-Funktion, die gleichzeitig dieDatenmenge für den nächsten Iterationsschritt reduziert. Da dieses Programmaufgrund des enormen Speicher- und Kommunikations-Overheads nur seltenerfolgreich durchlief, sind im Anhang in Tabelle A.1 nur wenige Werte zu finden.Es war klar erkennbar, dass deutlich mehr Daten unter den einzelnen Knotenkommuniziert werden mussten. Ab einer Milliarde Werten waren die Ausfüh-rungen nicht mehr erfolgreich, weshalb sich dieser Algorithmus gegenüber demsequentiellen Ansatz nicht bewährt.

59

6. Evaluation

6.5. Weitere Beobachtungen

Neben den bisher erwähnten Beobachtungen während der Evaluierung des indieser Arbeit vorgestellten Algorithmus war zu erkennen, dass eine gute Balancezwischen der Anzahl der TaskSlots und der Datenmenge gefunden werden muss,sodass einerseits die Kommunikation weitestgehend reduziert und die Ressourcenpro TaskSlot möglichst voll ausgeschöpft werden. In diesen Fällen arbeitet derAlgorithmus am besten, weshalb man auch an den Diagrammen oft Einbrücheab einer gewissen Parallelität erkennen kann.

Weiterhin können bei gleichbleibenden Parametern aber unterschiedlichen Per-zentilen, die zu berechnen sind, kaum Unterschiede in den Laufzeiten festgestelltwerden (siehe Tabellen A.3 und A.4). Dies bedeutet, dass die Ergebnismengeschneller soweit reduziert ist, dass sequentiell weitergearbeitet werden kann undnur selten das Ergebnis zufällig gefunden wird.

Außerdem spielt die Verteilung bzw. Vorsortierung der Werte eine klare Rollebei den Laufzeiten des Algorithmus. Während die Ausführung deutlich schnellererfolgreich endet, wenn viele bzw. alle Werte gleich sind, was daran liegt, dass dasErgebnis „zufällig“ während der Datenreduktion gefunden wird, ist das Programmbei aufsteigend vorsortierten und zufällig verteilten Zahlen in etwa gleich schnell.Lediglich bei absteigend sortierten Daten steigt die Laufzeit noch einmal. Eineplausible Begründung hierfür konnte während der Evaluationsarbeiten nichtgefunden werden. Dies könnte in weiteren Betrachtungen näher untersuchtwerden.

60

6. Evaluation

Verteilt Approx Join0

20

40

60

80

100

120

Durchschn

ittl.L

aufzeitin

s 32 Threads64 Threads

Abbildung 6.4.: Vergleich der durchschnittlichen Laufzeiten der einzelnen Imple-mentierungen jeweils mit 32 und 64 Threads für 107 Werte. Derin dieser Arbeit vorgestellte Algorithmus wird hier mit Verteiltbezeichnet, der approximative mit Approx und der ohne Redisimplementierte mit Join.

61

7. Schluss

Nachdem mit einer Einleitung an das Thema herangeführt wurde, gab es inKapitel 2 einige Eindrücke zu verwandten Arbeiten und zum aktuellen Stand derForschung bezüglich der verteilten Berechnung von Perzentilen. Anschließendhaben die Kapitel 3 und 4 notwendige Grundlagen erläutert und Technologienvorgestellt, die im Rahmen dieser Arbeit verwendet wurden. In Kapitel 5 wurdenAlgorithmen gezeigt, die entweder im Rahmen dieser Arbeit genutzt wurdenoder neu entwickelt worden sind. Abschließend werden in Kapitel 6 umfassendeEvaluierungsergebnisse vorgestellt.

7.1. Fazit

Zusammenfassend ist zu sagen, dass die Suche nach einem geeigneten Algorith-mus zur verteilten Berechnung von Perzentilen erfolgreich war. Die Implementa-tion, die in Kapitel 5 beschrieben ist, löst das Auswahlproblem mithilfe des BigData Frameworks Apache Flink und nach den Aussagen aus Abschnitt 3.1 somitdie verteilte und exakte Berechnung des Perzentils für Fließkommazahlen. Ausden Evaluierungsergebnissen in Kapitel 6 ergibt sich, dass der Algorithmus mitzunehmenden Daten und zunehmender Parallelität gut skaliert. Er ist Single-Node Lösungen überlegen, sobald Perzentile für mehr als 108 Fließkommazahlenberechnet werden müssen. Somit sollte bei großen Datenmengen immer auf einensolchen Algorithmus zurückgegriffen werden.

62

7. Schluss

7.2. Ausblick

Das Thema dieser Arbeit lässt viel Platz für weitere Forschungen und somitauch für Implementierungen und Evaluationen. Zum einen löst der vorgestellteAlgorithmus das Auswahlproblem jeweils nur für einen Wert für k. Im Allgemei-nen kann jedoch nicht davon ausgegangen werden, dass immer nur ein Perzentilzu berechnen ist. Häufig werden verschiedene Standardwerte berechnet, hierunter anderem das 1%-, 25%-, 50%-, 75%- und das 99%-Perzentil. Mit derLösung aus dieser Arbeit müsste hierbei für jeden Prozentwert der Algorithmuserneut durchlaufen. Auch, wenn man sich für eine der anderen Abbildungen desPerzentils auf das Auswahlproblem entscheidet, in der bei nicht ganzzahligenProdukten [n · p] zwischen den angrenzenden Zahlen interpoliert wird, müsstedas Auswahlproblem mindestens zweimal gelöst werden. Von den Autoren Sau-kas und Song (1998) wird ein Algorithmus für Parallelrechner vorgestellt, derdas Auswahlproblem mehrfach simultan löst. Die Implementation und Adaptiondessen auf Apache Flink hätte jedoch den Rahmen dieser Arbeit gesprengt.

Weiterhin könnte man den vorgestellten Algorithmus in einer ähnlichen Um-gebung, wie sie auch in der Arbeit von Swoboda (2017) genutzt wurde, imple-mentieren. Durch die iterative Natur der Programmierschnittstelle von ApacheAccumulo1 und durch die sortiert und partitioniert abgelegten Schlüssel könnteneinige Annahmen für den implementierten Algorithmus entfallen, wie unteranderem die Nutzung von Redis als Zwischenspeicher oder aber die Sortierungwährend der Iteration, um den Median pro Partition zu bestimmen.

Es liegt ebenso nicht fern, auf den vorgestellten Ansätzen aufbauend eineeffiziente und verteilte globale Sortierung der Daten zu implementieren. DieseMöglichkeit existiert in Apache Flink so bisher nicht. Es lassen sich bislangnur einzelne Partitionen sortieren. Auch Saukas und Song (1998) haben einenAnsatz zur parallelen Sortierung vorgestellt, der laut eigenen Aussagen nurwenige Kommunikationsrunden benötigt.

1Apache Accumolo ist ein sortierter Key-Value-Store.

63

7. Schluss

7.3. Einsatzgebiet

Als Vorarbeit und zur Erarbeitung der Thematik für diese Masterarbeit wurdezu Analyse- und Evaluierungszwecken ein Dashboard für die statistische Aus-wertung der erhobenen Daten eines großen deutschen Reisevergleichsportalsentwickelt. Dieses bietet die Möglichkeit unterschiedliche Datenquellen zu de-finieren und anzubinden. Als Beispielimplementierungen wurden hier GoogleBig Query und Google Analytics als Datenlieferanten herangezogen. Um dieDaten verarbeiten zu können, bietet dieses Dashboard eine flexible Möglichkeit,die Daten in ein externes Programm zu speisen und sich die Ergebnisse wiederabzuholen. An dieser Stelle würde sich die Lösung aus dieser Arbeit als eine derDatenverarbeitungs-Schnittstellen anbieten. So könnte dann für beliebig vieleEingabedaten das Perzentil berechnet werden. Die Resultate aus der Datenverar-beitung können dann mit verschiedenen, definierbaren Frontend-Bibliotheken wiez.B. plotly.js2 oder Highcharts3 visualisiert werden. Erst einmal viele verschiede-ne Datenquellen und Datenverarbeitungs-Schnittstellen angebunden, würde sichdieses Dashboard als wertvolles Data Science-Tool eignen.

2https://plot.ly/javascript3https://www.highcharts.com

64

8. Danksagung

Ich möchte mich herzlich bei Dr. Lars Rösler und Michael Volkhardt für dieBetreuung vor und während meiner Masterarbeit bei CHECK24 VergleichsportalGmbH bedanken. Bei Martin Grimmer möchte ich mich für die Betreuung amScaDS Leipzig und am Lehrstuhl Datenbanksysteme der Universität Leipzigbedanken. Auch möchte ich mich bei Matthias Kricke für die vielen hilfreichenEinwände während meiner Gespräche mit Martin Grimmer und bei Oliver Trab-hardt für die Unterstützung seitens CHECK24 Vergleichsportal GmbH währendund nach meiner Werkstudententätigkeit bedanken. Abschließend möchte ichmich noch ganz herzlich bei Lars-Peter Meyer und dem ScaDS Leipzig dafür be-danken, dass ich für die Evaluation des in dieser Arbeit entwickelten Algorithmusden Big-Data-Cluster Galaxy nutzen durfte.

65

A. Anhang

Tabelle A.1.: Protokoll: Evaluation des Join-Algorithmus. Zu sehen sind die Ver-teilung der Eingabedaten, die Anzahl der Werte, die berechnetenPerzentile, die Parallelität gemessen in Slots und die Laufzeit inMillisekunden.

Verteilung Anzahl Perzentil Slots Laufzeit (ms)Random 10000000 25 32 50712Random 10000000 25 64 28809Random 10000000 50 32 26721Random 10000000 50 64 22559Random 10000000 75 32 22259Random 10000000 75 64 21747Random 100000000 25 32 74040Random 100000000 25 64 115532Random 100000000 50 32 70134

66

A. Anhang

Tabelle A.2.: Protokoll: Evaluation des approximativen Algorithmus. Zu sehensind die Verteilung der Eingabedaten, die Anzahl der Werte, dieberechneten Perzentile, die Parallelität gemessen in Slots und dieLaufzeit in Millisekunden.

Verteilung Anzahl Perzentil Slots Laufzeit (ms)Random 10000000 25 32 28929Random 10000000 25 64 34279Random 10000000 50 32 30568Random 10000000 50 64 30358Random 10000000 75 32 31338Random 10000000 75 64 31975Random 100000000 25 32 322779Random 100000000 25 64 375861Random 100000000 50 32 331954Random 100000000 50 64 381689Random 100000000 75 32 340294Random 100000000 75 64 374040Random 1000000000 25 32 1417584Random 1000000000 25 64 2640380Random 1000000000 50 32 1316151Random 1000000000 50 64 2748633Random 1000000000 75 32 1336305Random 1000000000 75 64 2763248

67

A. Anhang

Tabelle A.3.: Protokoll: Evaluation des vorgestellten Algorithmus (1/5). Zusehen sind die Verteilung der Eingabedaten, die Anzahl der Werte,die berechneten Perzentile, die Parallelität gemessen in Slots unddie Laufzeit in Millisekunden.

Verteilung Anzahl Perzentil Slots Laufzeit (ms)Random 10000000 1 1 41713Random 10000000 1 2 30874Random 10000000 1 4 25043Random 10000000 1 8 19494Random 10000000 1 16 24490Random 10000000 1 32 16444Random 10000000 1 64 23521Random 10000000 25 1 39351Random 10000000 25 2 25567Random 10000000 25 4 25130Random 10000000 25 8 24032Random 10000000 25 16 26407Random 10000000 25 32 17692Random 10000000 25 64 24561Random 10000000 50 1 37723Random 10000000 50 2 27944Random 10000000 50 4 23908Random 10000000 50 8 24721Random 10000000 50 16 23066Random 10000000 50 32 17886Random 10000000 50 64 24690Random 10000000 75 1 40037Random 10000000 75 2 28108Random 10000000 75 4 24335Random 10000000 75 8 22649Random 10000000 75 16 13943Random 10000000 75 32 18523Random 10000000 75 64 22478

68

A. Anhang


Verteilung Anzahl Perzentil Slots Laufzeit (ms)Random 10000000 99 1 38376Random 10000000 99 2 30998Random 10000000 99 4 22264Random 10000000 99 8 18235Random 10000000 99 16 20129Random 10000000 99 32 19442Random 10000000 99 64 22833Random 10000000 1 32 19790Random 10000000 25 32 19881Random 10000000 50 32 17366Random 10000000 75 32 18124Random 10000000 99 32 18603Random 100000000 1 32 56511Random 100000000 25 32 54608Random 100000000 50 32 56068Random 100000000 75 32 57809Random 100000000 99 32 63778Random 1000000000 1 32 315827Random 1000000000 25 32 353617Random 1000000000 50 32 372289Random 1000000000 75 32 512385Random 1000000000 99 32 646086Random 10000000000 25 64 290822Random 10000000000 50 64 316273Random 10000000000 75 64 306680Random 10000000000 25 32 321183Random 10000000000 25 64 332083Random 10000000000 50 32 333205

69

A. Anhang


Verteilung Anzahl Perzentil Slots Laufzeit (ms)Random 10000000000 50 64 799785Random 10000000000 75 32 364774Random 1000000000 1 16 418040Random 1000000000 1 32 313758Random 1000000000 1 64 286271Random 1000000000 25 16 351776Random 1000000000 25 32 356675Random 1000000000 25 64 299688Random 1000000000 50 16 426099Random 1000000000 50 32 311229Random 1000000000 50 64 456124Random 1000000000 75 16 523883Random 1000000000 75 32 346869Random 1000000000 75 64 320131Random 1000000000 99 16 493026Random 1000000000 99 32 417632Random 1000000000 99 64 328265AllEqual 1000000000 1 16 112829AllEqual 1000000000 1 32 117538AllEqual 1000000000 1 64 122869AllEqual 1000000000 25 16 114095AllEqual 1000000000 25 32 153051AllEqual 1000000000 25 64 123719AllEqual 1000000000 50 16 112283AllEqual 1000000000 50 32 149027AllEqual 1000000000 50 64 124246AllEqual 1000000000 75 16 122460AllEqual 1000000000 75 32 129787

70

A. Anhang


Verteilung Anzahl Perzentil Slots Laufzeit (ms)AllEqual 1000000000 75 64 118712AllEqual 1000000000 99 16 120700AllEqual 1000000000 99 32 145248AllEqual 1000000000 99 64 171173Asc 1000000000 1 16 449423Asc 1000000000 1 32 413016Asc 1000000000 1 64 360703Asc 1000000000 25 16 460457Asc 1000000000 25 32 378720Asc 1000000000 25 64 417453Asc 1000000000 50 16 461033Asc 1000000000 50 32 1276233Asc 1000000000 50 64 866642Asc 1000000000 75 16 681451Asc 1000000000 75 32 367578Asc 1000000000 75 64 336199Asc 1000000000 99 16 540415Asc 1000000000 99 32 324868Asc 1000000000 99 64 398485Desc 1000000000 1 16 689456Desc 1000000000 1 32 338715Desc 1000000000 1 64 621107Desc 1000000000 25 16 718020Desc 1000000000 25 32 432558Desc 1000000000 25 64 439430Desc 1000000000 50 16 508531Desc 1000000000 50 32 461408Desc 1000000000 50 64 699043

71

A. Anhang


Verteilung Anzahl Perzentil Slots Laufzeit (ms)Desc 1000000000 75 16 689516Desc 1000000000 75 32 415955Desc 1000000000 75 64 893791Desc 1000000000 99 16 756276Desc 1000000000 99 32 705019Desc 1000000000 99 64 315162

72

A. Anhang

Abbildung A.1.: Apache Flink: Optimierter Datenfluss. Zu sehen ist, wie Apache Flink aus den Metho-denaufrufen seiner API einen optimierten Datenfluss-Plan baut.

73

Literatur

Amthor, Axel und Thomas Brommund (2010). Mehr Erfolg durch Web Analytics.Carl Hanser Verlag GmbH Co. KG. doi: 10.3139/9783446424081.

Apache Software Foundation (13. Mai 2018a). Apache Flink Documentation.Version 1.4. url: https://ci.apache.org/projects/flink/flink-docs-release-1.4/ (besucht am 13. 05. 2018).

– (3. Juni 2018b). Apache Hadoop Documentation. Version 1.4. url: http://hadoop.apache.org/docs/r2.8.4/ (besucht am 13. 05. 2018).

Balzert, Helmut (2000). Lehrbuch der Software-Technik. Software-Entwicklung.Spektrum, Akademischer Verlag.

Bengel, Günther u. a. (2015). Masterkurs Parallele und Verteilte Systeme. Sprin-ger Fachmedien Wiesbaden. doi: 10.1007/978-3-8348-2151-5.

Black, Paul E. (26. Jan. 2015). Reservoir Sampling. Dictionary of Algorithmsund Data Structures. url: https : / / xlinux . nist . gov / dads / HTML /

reservoirSampling.html (besucht am 03. 06. 2018).Blum, M. u. a. (1973). „Bounds for selection“. In: Journal of Computer and

System Sciences International 7, S. 448–461.Bondi, André B. (2000). „Characteristics of scalability and their impact on

performance“. In: Proceedings of the second international workshop on Softwareand performance - WOSP ’00. ACM Press. doi: 10.1145/350391.350432.

Chaudhuri, Shiva, Torben Hagerup und Rajeev Raman (1993). „Approximateand exact deterministic parallel selection“. In: Mathematical Foundations ofComputer Science 1993. Hrsg. von Andrzej M. Borzyszkowski und StefanSokołowski. Berlin, Heidelberg: Springer Berlin Heidelberg, S. 352–361. isbn:978-3-540-47927-7.

74

https://doi.org/10.3139/9783446424081

https://ci.apache.org/projects/flink/flink-docs-release-1.4/

https://ci.apache.org/projects/flink/flink-docs-release-1.4/

http://hadoop.apache.org/docs/r2.8.4/

http://hadoop.apache.org/docs/r2.8.4/

https://doi.org/10.1007/978-3-8348-2151-5

https://xlinux.nist.gov/dads/HTML/reservoirSampling.html

https://xlinux.nist.gov/dads/HTML/reservoirSampling.html

https://doi.org/10.1145/350391.350432

LITERATUR

Cormen, Thomas H. u. a. (22. März 2005). Introduction to Algorithms. 3. Aufl.The MIT Press. isbn: 0262033844.

Dhar, Vasant (Dez. 2013). „Data science and prediction“. In: Communicationsof the ACM 56.12, S. 64–73. doi: 10.1145/2500499.

Eppstein, David (9. Okt. 2007). Blum-style analysis of Quickselect. url: https://11011110.github.io/blog/2007/10/09/blum-style-analysis-of.

html.Fasel, Daniel und Andreas Meier (2016). „Was versteht man unter Big Dataund NoSQL?“ In: Big Data. Springer Fachmedien Wiesbaden, S. 3–16. doi:10.1007/978-3-658-11589-0_1.

Google (2018). Google BigQuery-Dokumentation. url: https://cloud.google.com/bigquery/docs (besucht am 30. 09. 2018).

Güting, Ralf Hartmut und Stefan Dieker (2018). Datenstrukturen und Algorith-men. Springer Fachmedien Wiesbaden. doi: 10.1007/978-3-658-04676-7.

IEEE (2008). „IEEE Standard for Floating-Point Arithmetic“. In: IEEE Std.754-2008. doi: 10.1109/IEEESTD.2008.4610935.

KairosDB (2018). KairosDB Dokumentation. url: https://kairosdb.github.io.

Oechsle, Rainer (1. März 2018). Parallele und verteilte Anwendungen in Java.5. Aufl. Carl Carl Hanser Verlag GmbH Co. KG. isbn: 978-3-446-45118-6. url:https://www.amazon.com/Parallele-verteilte-Anwendungen-Java/dp/

3446451188?SubscriptionId=AKIAIOBINVZYXZQZ2U3A&tag=chimbori05-

20&linkCode=xm2&camp=2025&creative=165953&creativeASIN=3446451188.Redis labs (2018). Introduction to Redis. url: https://redis.io/topics/introduction (besucht am 29. 01. 2018).

Saukas, E L G und S W Song (1998). „Efficient Selection Algorithms on Distri-buted Memory Computers“. In: Proc. Supercomputing ’98, S. 1–29.

Shrivastava, Nisheeth u. a. (2004). „Medians and beyond: New AggregationTechniques for Sensor Networks“. In: SenSys.

Stephane (23. Aug. 2011). Metric converted into KPI: Time on Site. dashthis.url: https://dashthis.com/blog/metric-converted-into-kpi-time-on-site/ (besucht am 26. 09. 2018).

75

https://doi.org/10.1145/2500499

https://11011110.github.io/blog/2007/10/09/blum-style-analysis-of.html



https://doi.org/10.1007/978-3-658-11589-0_1

https://cloud.google.com/bigquery/docs

https://cloud.google.com/bigquery/docs

https://doi.org/10.1007/978-3-658-04676-7

https://doi.org/10.1109/IEEESTD.2008.4610935

https://kairosdb.github.io

https://kairosdb.github.io

https://www.amazon.com/Parallele-verteilte-Anwendungen-Java/dp/3446451188?SubscriptionId=AKIAIOBINVZYXZQZ2U3A&tag=chimbori05-20&linkCode=xm2&camp=2025&creative=165953&creativeASIN=3446451188



https://redis.io/topics/introduction

https://redis.io/topics/introduction

https://dashthis.com/blog/metric-converted-into-kpi-time-on-site/

https://dashthis.com/blog/metric-converted-into-kpi-time-on-site/

LITERATUR

Stonebraker, Michael (1986). „The Case for Shared Nothing Architecture“. In:Database Engineering. Bd. 9. 1. url: http://db.cs.berkeley.edu/papers/hpts85-nothing.pdf (besucht am 26. 09. 2018).

Swoboda, Oliver (2017). „Serverseitige Aggregation von Zeitreihendaten inverteilten NoSQL-Datenbanken“. In: Lecture Notes in Informatices (LNI).Gesellschaft für Informatik. Bonn: B. Mitschang.

Tropf, Teresa Maria (27. Dez. 2016). 2016: Online-Shopper gaben im Schnitt 1.280Euro aus. Hrsg. von Julia Miosga. bitkom. url: https://www.bitkom.org/Presse/Presseinformation/2016-Online-Shopper-gaben-im-Schnitt-

1280-Euro-aus.html (besucht am 19. 08. 2018).URZ Leipzig (8. März 2017). Big-Data-Cluster Galaxy. URZ Leipzig. url: https://www.urz.uni-leipzig.de/fue/sc/galaxy/ (besucht am 15. 04. 2018).

Wang, Lu u. a. (2013). „Quantiles over Data Streams: An Experimental Study“.In: SIGMOD.

76

http://db.cs.berkeley.edu/papers/hpts85-nothing.pdf

http://db.cs.berkeley.edu/papers/hpts85-nothing.pdf

https://www.bitkom.org/Presse/Presseinformation/2016-Online-Shopper-gaben-im-Schnitt-1280-Euro-aus.html



https://www.urz.uni-leipzig.de/fue/sc/galaxy/

https://www.urz.uni-leipzig.de/fue/sc/galaxy/

Eidesstattliche Erklärung

Ich versichere, dass ich die vorliegende Arbeit selbstständig und nur unter Ver-wendung der angegebenen Quellen und Hilfsmittel angefertigt habe, insbesonderesind wörtliche oder sinngemäße Zitate als solche gekennzeichnet. Mir ist bekannt,dass Zuwiderhandlung auch nachträglich zur Aberkennung des Abschlussesführen kann.

Ich versichere, dass das elektronische Exemplar mit den gedruckten Exemplarenübereinstimmt.

Ort, Datum Unterschrift

.................................................. ..................................................

Documents

Verteilte Berechnung exakter Perzentile von Fließkommazahlen