=Paper=
{{Paper
|id=Vol-2126/paper16
|storemode=property
|title=Stonebraker versus Google: 2-0 Scores in Rostock - A Comparison of Big Data
Analytics Environments (Stonebraker gegen Google: Das 2:0 fällt in Rostock)
|pdfUrl=https://ceur-ws.org/Vol-2126/paper16.pdf
|volume=Vol-2126
|authors=Daniel Dietrich,Ole Fenske,Stefan Schomacker,Philipp Schweers,Andreas Heuer
|dblpUrl=https://dblp.org/rec/conf/gvd/DietrichFSSH18
}}
==Stonebraker versus Google: 2-0 Scores in Rostock - A Comparison of Big Data
Analytics Environments (Stonebraker gegen Google: Das 2:0 fällt in Rostock)==
https://ceur-ws.org/Vol-2126/paper16.pdf
Stonebraker versus Google: 2-0 scores in Rostock - A
comparison of big data analytics environments
Daniel Dietrich Ole Fenske
Universität Rostock Universität Rostock
Albert-Einstein-Str. 22 Albert-Einstein-Str. 22
18059 Rostock 18059 Rostock
daniel.dietrich@uni- ole.fenske@uni-
rostock.de rostock.de
Stefan Schomacker Philipp Schweers Andreas Heuer
Universität Rostock Universität Rostock Universität Rostock
Albert-Einstein-Str. 22 Albert-Einstein-Str. 22 Albert-Einstein-Str. 22
18059 Rostock 18059 Rostock 18059 Rostock
stefan.schomacker@uni- philipp.schweers@uni- heuer@informatik.uni-
rostock.de rostock.de rostock.de
ABSTRACT
In our research project PArADISE, the data-driven develop-
ment of assistive systems is supported by the highly parallel
analysis of large amounts of sensor data. To achieve diffe-
rent aims such as the preservation of privacy, provenance,
and sustainability, we stick to SQL as a basis to express
the evaluation programs (mining or machine learning algo-
rithms). These SQL queries should then be evaluated by a
parallel DBMS. Of course, parallel row store DBMS are com-
peting with column oriented DBMS architectures, as well as
with recent big data analytics environments such as map
reduce or dataflow programming environments. In a paper
of Stonebraker (CACM, 2010), the superiority of row and
column stores over a map reduce framework (Hadoop) has
been shown several years ago. Years later, we wanted to re-
construct the results of Stonebraker within two studentsÂt’
projects at the University of Rostock. Additionally, we wan-
ted to transfer the results to other kinds of tasks and to
more recent software environments. The aim of this paper is
to present the results of these two studentsÂt’ projects.
30th GI-Workshop on Foundations of Databases (Grundlagen von Daten-
banken), 22.05.2018 - 25.05.2018, Wuppertal, Germany.
Copyright is held by the author/owner(s).
Stonebraker gegen Google: Das 2:0 fällt in Rostock
Ein Vergleich von Big-Data-Analytics-Plattformen
Daniel Dietrich Ole Fenske
Universität Rostock Universität Rostock
Albert-Einstein-Str. 22 Albert-Einstein-Str. 22
18059 Rostock 18059 Rostock
daniel.dietrich@ ole.fenske@
uni-rostock.de uni-rostock.de
Stefan Schomacker Philipp Schweers Andreas Heuer
Universität Rostock Universität Rostock Universität Rostock
Albert-Einstein-Str. 22 Albert-Einstein-Str. 22 Albert-Einstein-Str. 22
18059 Rostock 18059 Rostock 18059 Rostock
stefan.schomacker@ philipp.schweers@ heuer@informatik.uni-
uni-rostock.de uni-rostock.de rostock.de
ABSTRACT tures]: Multicore architectures
Im Projekt PArADISE wird die datengetriebene Entwick-
lung von Assistenzsystemen durch die hochparallele Analy- Keywords
se großer Mengen von Sensordaten unterstützt. Um dabei Big Data Analytics, Parallele DBMS, Map-Reduce, Perfor-
verschiedene Ziele wie die Sicherung von Privatsphäre, Pro- mance, Postgres-XL, Hadoop, Spark, Flink
venance und Nachhaltigkeit zu erreichen, sind wir darauf
angewiesen, die Analyseprogramme (Mining- oder Machine-
Learning-Algorithmen) in SQL umzusetzen und dann mög-
1. MOTIVATION
lichst mit parallelen DBMS zu realisieren. Dabei stehen die- Im Rostocker Projekt PArADISE [7, 9] wird die datenge-
se parallelen DBMS-Lösungen auf zeilenorientierten DBMS- triebene Entwicklung von Assistenzsystemen durch die hoch-
Architekturen natürlicherweise in Konkurrenz zu spaltenori- parallele Analyse großer Mengen von Sensordaten unter-
entierten Architekturen, gleichzeitig aber auch zu modernen stützt. Dabei sollen neben der effizienten Datenanalyse zur
Big-Data-Analyse-Umgebungen wie MapReduce- oder Da- Unterstützung der Modellbildung in Assistenzsystemen di-
tenflussprogrammierungsansätzen. In einem Artikel von Sto- verse weitere Ziele erreicht werden: die Sicherung der Pri-
nebraker [11] wurde die Überlegenheit von zeilen- und spal- vatsphäre der das Assistenzsystem nutzenden Personen, das
tenorientierten DBMS gegenüber eines MapReduce-Ansatzes Provenance Management zur Ermittlung von Ursachen bei
(Hadoop) gezeigt. Die Ergebnisse von Stonebraker sollten fehlerhaften Modellbildungen, und die Nachhaltigkeit der
nun einige Jahre später in zwei studentischen Projekten an Analyseprogramme im Kontext einer Informationssystem-
der Universität Rostock nachvollzogen, aber auch auf ande- Infrastruktur beim Diensteanbieter des Assistenzsystems. Die
re Arten von Problemen und neuere Software-Plattformen Architektur des PArADISE-Frameworks wird in Abschnitt
übertragen werden. Ziel dieses Artikels ist, die Ergebnisse 2 noch genauer beschrieben.
der beiden studentischen Projekte zu präsentieren. Um die oben genannten Ziele zu erreichen, sind wir darauf
angewiesen, die Analyseprogramme (Mining- oder Machine-
Learning-Algorithmen) in SQL umzusetzen und dann mög-
Categories and Subject Descriptors lichst mit parallelen DBMS zu realisieren. Dabei stehen die-
Information Systems [Database Management System se parallelen DBMS-Lösungen auf zeilenorientierten DBMS-
Engines]: MapReduce-based systems; Information Systems Architekturen natürlicherweise in Konkurrenz zu spaltenori-
[Database Management System Engines]: Relational entierten Architekturen, gleichzeitig aber auch zu modernen
parallel and distributed DBMSs; Information Systems [Da- Big-Data-Analyse-Umgebungen wie MapReduce- oder Da-
tabase Administration]: Database performance evaluati- tenflussprogrammierungsansätzen.
on; Computer Systems Organization [Parallel Architec- Die Communications of the ACM hatte im Jahre 2010
zwei Artikel mit gegensätzlichen Positionen veröffentlicht:
einen Artikel von Google [6] über den Sinn und die Vor-
teile MapReduce-artiger Lösungen wie Hadoop, dazu einen
Artikel von Michael Stonebraker [11] über die Überlegen-
heit von zeilen- und spaltenorientierten DBMS gegenüber ei-
nes MapReduce-Ansatzes, speziell Hadoop. Stonebraker hat
dabei neben Hadoop auch sein eigenes spaltenorientiertes
DBMS Vertica (heute bei HP) und ein nicht genanntes zei-
30th GI-Workshop on Foundations of Databases (Grundlagen von Daten-
banken), 22.05.2018 - 25.05.2018, Wuppertal, Germany. lenorientiertes DBMS genutzt. Die drei Systeme wurden in
Copyright is held by the author/owner(s). drei verschiedenen Aufgaben (Tasks) getestet. Die drei Ori-
ginalaufgaben von Stonebraker, die Testumgebung und die Hadoop DBMS-X Vertica
Testergebnisse stellen wir in Abschnitt 3 noch genauer vor. Grep 284 s 194 s 108 s
Kurz zusammengefasst kann gesagt werden: Stonebraker Web Log 1146 s 740 s 268 s
stellte die Überlegenheit der DBMS-Lösungen gegenüber Ha- Join 1158 s 32 s 55 s
doop nicht nur in Testfällen heraus, in denen man diese
Überlegenheit erwarten konnte (Aufgaben, die einen Ver-
Tabelle 1: Ergebnisse der Stonebraker-Tests
bund großer Datenbestände als Teilproblem hatten), son-
dern auch in Tasks, für die eine MapReduce-artige Verar-
beitung eigentlich eingeführt wurde (Wortsuche in Texten).
Nach diesen Tests stand es 1:0 für die von Stonebraker fa- Sowohl in der Entwicklungsphase als auch in der Nut-
vorisierten parallelen DBMS als Big-Data-Plattformen. zungsphase werden wir auf einem Parallelrechner große Men-
Die Ergebnisse von Stonebraker sollten nun einige Jah- gen von Sensordaten analysieren müssen. Das Zielsystem für
re später in zwei studentischen Projekten an der Univer- diese Analysen ist ein paralleles DBMS, das SQL-Anfragen
sität Rostock nachvollzogen, aber auch auf andere Arten parallel und effizient verarbeiten kann (in der Architektur
von Problemen und neuere Software-Plattformen übertra- mit PSQL und PDBMS bezeichnet). Um abschätzen zu kön-
gen werden (siehe Abschnitt 4 für die genauere Aufgaben- nen, ob (und wenn ja, wie stark) die Performance durch
stellung). Neben Hadoop sollten auch neuere Systeme wie die Nutzung eines SQL-DBMS leidet, testen wir eine sol-
Spark, Flink, Naiad und Tensorflow getestet werden. Und che Lösung gegen spezialisierte Plattformen wie Hadoop,
neben den drei Task-Typen von Stonebraker sollte noch min- Spark und Flink. Ziel ist dabei nicht unbedingt, in jedem
destens ein Data-Mining-Verfahren als komplexere Task er- Fall besser zu sein als diese Plattformen, sondern möglichst
gänzt werden. Die Testumgebung und die Testfälle, die in wenig gegenüber diesen zu verlieren. Die Vorteile der Nut-
Rostock umgesetzt wurden, werden in den Abschnitten 5 zung von DBMS-Technologien (wie erwähnt: Privacy, Pro-
und 6 genauer vorgestellt. venance, Nachhaltigkeit) wiegen schwerer als ein geringer
Die Ergebnisse der beiden studentischen Projekte werden Performance-Verlust.
ebenfalls in Abschnitt 6 genauer vorgestellt. Sie untermau- Beim Start des PArADISE-Projektes waren daher die Er-
ern die These von Stonebraker, dass nicht nur spaltenori- gebnisse von Stonebraker [11] ein interessanter Ausgangs-
entierte DBMS bei vielen Typen von Analysen auf großen punkt, den wir in diesem studentischen Teilprojekt näher
Datenmengen einer MapReduce-Lösung überlegen sind, son- untersuchen wollten.
dern auch zeilenorientierte Architekturen mithalten können.
Die Tests haben also für die Stonebraker-Argumentation 3. DIE ERGEBNISSE VON STONEBRAKER
kein Gegentor beschert, sondern die Argumentation bestä-
Stonebraker et al. publizierten 2010 [11] die Ergebnisse ei-
tigt: es steht damit 2:0 für die DBMS-Plattformen.
nes Vergleichs zwischen Hadoop 0.19.0, DBMS-X und Ver-
tica. DBMS-X ist dabei ein nicht benanntes, kommerziel-
2. DAS PROJEKT PARADISE les, zeilenorientiertes und paralleles DBMS. Vertica hat eine
PArADISE (Privacy-AwaRe Assistive Distributed Infor- spaltenorientierte und parallele Architektur. Der Test ver-
mation System Environment) [7, 9] unterstützt die datenge- wendete ein Cluster mit 100 Knoten. Jeder dieser Knoten
triebene Entwicklung von Assistenzsystemen durch die hoch- hatte einen 2.4 GHz Intel Core 2 Duo Prozessor und 4 GB
parallele Analyse großer Mengen von Sensordaten. Das in RAM. Die Resultate sind der Tabelle 1 zu entnehmen.
dem Projekt entwickelte Framework besteht aus drei großen Es wurden die folgenden Szenarien verglichen:
Phasen (siehe Abbildung 1): Grep Task. Hierbei werden 10 Milliarden Datensätze (1
TB) nach einer Zeichenkette durchsucht. Bei 100 Knoten er-
• In der Entwicklungsphase (links im Bild) werden unter gibt sich eine Datenmenge von 10 GB pro Knoten. Ein Da-
Versuchsbedingungen massiv Sensordaten erfasst, um tensatz besteht aus 100 Bytes (10 Bytes Schlüssel, 90 Bytes
daraus Modelle für Situationen, Handlungen und In- Wert). Es liegt keine Sortierung vor und es darf kein Index
tentionen der beteiligten Personen abzuleiten. Die Ab- verwendet werden. Dieser Task ist die Basis für Analysen
leitung der Modelle geschieht über Machine-Learning- von Webseiten, etwa bei Google. Es ist daher zu erwarten,
Algorithmen (ML), die in SQL umgesetzt werden. Die dass dieser Task sehr gut zu Map-Reduce-Systemen passt.
Umsetzung in SQL wird in [9] näher erläutert. Web Log Task. Die zweite Aufgabe besteht aus einer
• In der Transformationsphase (im Bild der Pfeil von Aggregation mit GROUP BY auf einem Web Log mit Be-
links nach rechts) wird mit Provenance-Management- suchen. Der Log hat eine Größe von 2 TB und beinhaltet
Techniken eine kleine, aber aussagefähige Auswahl der 155 Millionen Datensätze. Bei 100 Knoten ergibt sich eine
Sensoren getroffen, mit der unter genügender Konfi- Datenmenge von 20 GB pro Knoten. Diese Aufgabe wurde
denz ähnliche Modelle hergeleitet werden können. Die ohne Index durchgeführt.
Rolle des Provenance Management bei der Entwick- Join Task. Diese Aufgabe beschreibt einen Verbund über
lung von Assistenzsystemen skizzieren wir in [8]. zwei Tabellen, eine Selektion und eine Aggregation. Der Web
Log wird mit einer PageRank-Tabelle verbunden, die 18 Mil-
• In der Nutzungsphase (rechts im Bild) werden beim lionen Datensätze und eine Größe von 100 TB hat. Im ers-
späteren Einsatz des Assistenzsystems die in SQL vor- ten Teil muss die IP-Adresse mit der größten Besuchsan-
liegenden Machine-Learning-Algorithmen automatisch zahl (Visits) in einem gewissen Zeitraum gefunden werden.
auf sensornahe Schichten des gesamten Verarbeitungs- Im zweiten Teil wird daraus der durchschnittliche PageRank
netzwerkes transformiert. Diese Phase wird in [7] vor- berechnet.
gestellt und realisiert die datensparsame Analyse der Grep Task und Join Task waren dann Ausgangspunkt für
Sensordaten. die eigenen Untersuchungen, die wir im folgenden Abschnitt
Data Scientist / Poodle
ML Developer ML-Code
ML-Code
ML2PSQL
ML2PSQL
PSQL-Code
Remainder Query
PSQL-Code PDBMS Privacy
PDBS Decomposition
…
PDBMS
PDBS
…
Client 1 Client 2 Client n
…
Privacy Privacy Privacy
Decomposition Decomposition Decomposition
PD PD … PD
PD PD … PD
Abbildung 1: Das PArADISE-Projekt (aus [9] und [7])
beschreiben. pe sollte dabei neben Hadoop auch neuere Systeme wie Spark,
Einordnung der Ergebnisse von Stonebraker. Si- Flink, Naiad und Tensorflow untersuchen und drei davon für
cher war der Stonebraker-Artikel [11] von den Kriterien her reale Tests aussuchen. Die Informatik-Gruppe sollte diese
sehr einseitig. So wurden die Effizienzaussagen ohne genaue- Tests parallel auf einem parallelen SQL-DBMS, in diesem
re Details veröffentlicht. Etwa ist nicht klar, welche Join- Fall Postgres-XL, durchführen.
Implementierungen in welchen DBMS in den internen An- Der nötige Aufwand für die Realisierung der Tests ist zwar
frageplänen generiert bzw. welche Join-Implementierungen durch die verschiedenen Projektformen im Wirtschaftsinfor-
in der Hadoop-Umgebung durch das Test-Team umgesetzt matik- und Informatik-Studium nicht direkt vergleichbar,
wurden. In unserer eigenen Testumgebung wurden daher die Aufwände wurden aber in den Projekten gemessen und
bei keiner Plattform die Join-Varianten bzw. die Datenpar- sind von der Größenordnung her vergleichbar:
titionierung auf dem parallelen System von außen beein-
flusst. Weiterhin wurden Vorteile der Big-Data-Analytics- • Die fünfköpfige Wirtschaftsinformatik-Gruppe wende-
Plattformen wie Hadoop (und eventuelle Nachfolger) nicht te nach Abzug von Einarbeitungs- sowie Installations-
weiter betrachtet: außer der Effizienzfragestellung gibt es und Administrations-Tätigkeiten 160 Stunden für die
auch Kriterien wie Cost of Ownership, Administrationsauf- Datenaufbereitung und 170 Stunden für die Implemen-
wand und Ease of Use, verfügbare Schnittstellen und vor tierung der Tasks in den drei für reale Tests ausgewähl-
allem die einfache Skalierbarkeit, bei der in vielen Fällen die ten Plattformen auf.
eingesetzten DBMS-Lösungen schlechter als Hadoop ausge-
sehen hätten. • Von der vierköpfigen Informatik-Gruppe waren drei
Für unsere Originalfragestellung, ob die von uns aus ande- nur für Installation und Administration des Postgres-
ren Gründen favorisierten SQL-basierten Systeme zur par- XL-Systems zuständig, da dieses auch für mehrere Par-
allelen Auswertung großer Datenmengen von der Effizienz allelprojekte benutzt wurde. Nur einer der Informatik-
her mit den spezialisierten Big-Data-Analytics-Frameworks Studenten beschäftigte sich dann mit den Stonebraker-
mithalten können, hatten wir nun aber einen interessanten Tests. Für die Datenaufbereitung wurden durch die
Ausgangspunkt, den wir in eigenen Tests vertiefen wollten. Vorarbeiten der Wirtschaftsinformatik-Gruppe nur 40
Stunden benötigt, die Implementierung der Tasks er-
folgte dann (nach Abzug der Einarbeitung) in 60 Stun-
den.
4. AUFGABENSTELLUNG
Im Sommersemester 2017 wurde in zwei verschiedenen Pro System war der Aufwand zur Umsetzung der Tasks mit
Projektveranstaltungen (eine für den Bachelor Wirtschafts- 50 bis 60 Stunden erstaunlich gleichmäßig verteilt.
informatik, eine für den Bachelor Informatik) die Aufgabe Neben den drei Task-Typen von Stonebraker sollte noch
gestellt, die Stonebraker-Ergebnisse nachzuvollziehen, aber mindestens ein Data-Mining-Verfahren als komplexere Task
auch auf andere Arten von Problemen und neuere Software- ergänzt werden. In den beiden Projektgruppen wurde dann
Plattformen zu übertragen. Die Wirtschaftsinformatik-Grup- entschieden, den Web Log Task des Stonebraker-Tests durch
einen einfachen Data-Mining-Algorithmus (Clustering durch Parameter Wert
k-Means) zu ersetzen. Die Testumgebung und die Testfälle Speicherblockgröße 256 MB
werden in folgenden Abschnitten 5 und 6 noch genauer vor- Heapsize Task Executor 1024 MB
gestellt. Heapsize History Server 1024 MB
Nach einer Literaturanalyse wurde von der Wirtschafts- Heapsize DataNode 1024 MB
informatik-Gruppe die Auswahl der Systeme auf drei be- Rackawareness deaktiviert
schränkt: Hadoop [6] als Basis auch für die neueren Systeme Replikate 3/Block
Spark [12] und Flink [4] wurden auf der zur Verfügung ste- Kompression deaktiviert
henden Systemumgebung installiert und evaluiert. Zunächst
war auch Tensorflow (von Google) [2] ein Kandidat für die Das Postgres-XL Cluster besteht aus 9 Koordinatoren und 9
realen Evaluierungen: erste Tests ergaben aber, dass Ten- Datenknoten. Jedem Koordinator kann somit genau ein Da-
sorflow in der 2017 zur Verfügung stehenden Fassung auf tenknoten zugewiesen werden. Die Konfigurationsparameter
den großen Datenmengen und den noch wenig auf Machine- jeder Einheit sind wie folgt:
Learning-Algorithmen zugeschnittenen Problemen mit deut-
lichem Abstand nicht konkurrenzfähig war. Das Microsoft- Parameter Wert
System Naiad [10] wurde schon nach der Literaturanalyse Effective Cache Size 4 GB
aufgrund von zu spärlichen Informationen und Manuals aus- Worker Memory 512 MB
geschlossen. Maintenance Memory 1 GB
Postgres-XL [1] wurde in der Informatik-Gruppe als ein- Temporary Buffer 64 MB
ziges paralleles SQL-DBMS ausgewählt, da es als Open- Shared Buffer 1 GB
Source-System zur Verfügung stand und da auch andere For- Segment Size 1 GB
schungsprojekte am Lehrstuhl diese Plattform als Basis be-
nutzten. Beachtet werden sollte also bei dieser Auswahl, dass An den Hardware-Parametern fällt auf, dass sie in Grö-
im Gegensatz zum Stonebraker-Test keine spaltenorientierte ßenordnungen (Faktor 30) von den beim Stonebraker-Test
Architektur zur Verfügung stand. verwendeten Parametern abweichen. Bei den in Rostock ver-
Wir werden nun die Hardware-Umgebung für die Tests wendeten Umgebungen differierten die Hadoop-, Spark- und
vorstellen und danach die neuen Tasks sowie die Ergebnis- Flink-Installationen und die Postgres-XL-Installation um den
se auf den verschiedenen Plattformen. Bei der Hardware- Faktor drei. Damit die Größenordnungen vergleichbar blei-
Umgebung muss beachtet werden, dass das RMRDF1 -Groß- ben, haben wir die Testergebnisse um diese Faktoren ska-
gerät durch die Projektgruppen nur in kleinerem Maßstab liert, so dass die Ergebnisse bei Annahme eines linearen Zu-
benutzt werden konnte, so dass die Ergebnisse zum Vergleich sammenhangs vergleichbar bleiben.
mit den Stonebraker-Daten skaliert werden müssen. Wir stellen nun die drei untersuchten Tasks und die Er-
gebnisse für die drei getesteten Plattformen Flink, Spark
und Postgres-XL vor. Hadoop wurde als Basis für Flink und
5. TESTUMGEBUNGEN Spark genutzt, nicht jedoch für eigenständige Tests.
Für die Durchführung der Testfälle standen drei Virtual Pri-
vate Server (VPS) zur Verfügung. Jeder Knoten besteht aus
einem Intel Haswell mit 4 Kernen, 64 GB Hauptspeicher und 6. TESTFÄLLE
einer durchschnittlichen Festplattengeschwindigkeit von 350 Für die Evaluierung der drei Plattformen wurden die Test-
MB/s. Ein VPS diente zusätzlich als zentrale Koordinati- fälle Grep Task und Join Task des Stonebraker-Vergleichs
onseinheit. Die verwendete Linux-Distribution ist CentOS ausgewählt. Zusätzlich wurde als einfacher Mining-Algorith-
7. mus ein Clustering-Verfahren (k-Means) umgesetzt. Wir be-
Hadoop in der Version 2.7.2, inklusive Hadoop Distributed schreiben nun die Testfälle und die Ergebnisse auf den drei
File System (HDFS) und Yet Another Resource Negotiator Systemen.
(YARN), bildet die Grundlage für die Berechnungen auf den Grep Task. Diese Aufgabe orientiert sich an dem Original-
Plattformen Flink und Spark. Das HDFS ermöglicht den Zu- Google-Map-Reduce-Grep-Task. Dabei sollte die Häufigkeit
griff und die verteilte Speicherung von folgenden Testdaten: des Vorkommens einer bestimmte Zeichenkette in dem 26
GB großen Twitter-Follower-Graphen ohne Sortierung und
• Als hochvernetzte Menge von Dokumenten wurde statt ohne Nutzung eines Indexes ermittelt werden. Im Beispiel
eines Web-Ausschnitts ein Ausschnitt des Twitter-Fol- werden im Twitter-Follower-Graphen die Zeilen der relatio-
lower-Graphen gewählt: der Umfang war hier 26 GB. nalen Darstellung extrahiert, die eine 4“ enthalten. Die An-
”
• Das errechnete PageRank-Ergebnis zu diesem Graphen zahl dieser Vorkommen im Graphen soll dann ausgegeben
umfasste 1,15 GB. werden.
• Die zu untersuchenden Web-Log-Einträge hatten einen Twitter-Follow-Graph
Anzahl Zeilen
Umfang von 4,29 GB. ID1 ID2
12343454 86968792 Anzahl
Die Konfigurationsparameter des HDFS können der nach- 29656457 94665834 2
folgenden Tabelle entnommen werden. Um einen besseren 37695979 81632765 die ”4“ enthalten
Vergleich der Messergebnisse herstellen zu können, wurde
die Konfiguration an den Ausgangsparametern angepasst. Die folgende Tabelle enthält die durchschnittliche Laufzeit
1
Rostock Massive Data Research Facility, ein Großgerät für des Tests je System:
datengetriebene Forschung, das vier Lehrstühle im Institut
für Informatik der Universität Rostock gemeinsam betrei- Flink Spark Postgres-XL
ben. 100 s 53 s 121 s
Postgres-XL als zeilenorientiertes paralleles DBMS hat 3. In jedem Cluster wird der Durchschnitt aller enthalte-
hier die schlechteste Laufzeit. Die Unterschiede zwischen ner Punkte als neues Clusterzentrum (grün) gewählt.
Flink und Postgres-XL sind aber nicht so deutlich wie er-
wartet. Die beste Laufzeit hat Spark. 4. Die Schritte (2) und (3) werden so lange wiederholt, bis
Join Task. Diese Aufgabe entspricht dem Join Task aus sich die Cluster nicht mehr verändern oder die Itera-
dem Stonebraker-Artikel [11]. Dabei wurde zunächst die IP- tionsobergrenze erreicht ist. Im Folgenden wurde eine
Adresse ermittelt, welche die meisten Twitter-Konten in ei- Grenze von 10 Wiederholungen verwendet.
nem bestimmten Zeitraum besucht hat. Anschließend wur-
den die Zeilen der Weblog-Tabelle selektiert, welche diese IP- 1: Beliebige Punkte als 2: Distanzen ermitteln und
Adresse enthalten, um diese mit der PageRank-Tabelle über Clusterzentren wählen Cluster bilden
100 100
die ID zu verbinden (natürlicher Verbund). Zum Schluss
wurden die PageRank-Werte zu einem Durchschnitt aggre- 80 80
giert. In diesem Fall wurde keine Sortierung benutzt.
60 60
PageRank Weblog
40 40
ID PageRank ID IP t ØIP =10
1 0,0016546 ./ 1 10 150 ⇒ PageRank 20 20
2 0,0857657 ID 2 08 10 0,2275596
3 0,4534646 3 10 30 0
0 20 40 60 80 100
0
0 20 40 60 80 100
100 100
Die folgende Tabelle enthält die durchschnittliche Laufzeit
80 80
des Tests je System:
60 60
Flink Spark Postgres-XL
121 s 140 s 27 s 40 40
Diese Aufgabe eignet sich durch die Verknüpfung von zwei 20 20
Datenbeständen sehr gut für SQL-DBMS, auch wenn diese
0 0
nur in einer zeilenorientierten Architektur vorliegen. Flink 0 20 40 60 80 100 0 20 40 60 80 100
überholt nun Spark, fällt aber deutlich hinter Postgres-XL 3: Neue Zentren berechnen 4: Distanzen ermitteln und
zurück. Die Ergebnisse korrespondieren mit den 2010 von und Punkt minimaler Cluster bilden
Stonebraker veröffentlichten Ergebnissen (Hadoop fiel dort Distanz wählen
gegen beide DBMS-Lösungen deutlich zurück).
Sicher stellt diese Join-Task ein Heimspiel für die SQL- Aus den Daten des Twitter-Follower-Graphen wurde für je-
DBMS wie das von uns verwendete Postgres-XL dar. Al- de enthaltene Konto-ID die Anzahl der Follower und die
lerdings ist ein solches Szenario auch in Data-Science- und Anzahl der Pursuer ermittelt. Über die Menge dieser Da-
Big-Data-Analytics-Anwendungen nicht unüblich. So wer- tenpunkte wurde dann der k-Means-Algorithmus mit k = 3
den im Bereich des Forschungsdatenmanagements und ih- durchgeführt.
rer Auswerte-Prozeduren und -Workflows Daten verschie- In dieser Aufgabe konnte das parallele Datenbanksystem
dener Messreihen, Projekte und Abteilungen miteinander Postgres-XL wiederum Flink und Spark überflügeln. Die Er-
verknüpft sowie auszuwertende Daten mit Metadaten und gebnisse entnehme man folgender Tabelle:
weiteren beschreibenden Daten aus anderen Datenbestän-
Flink Spark Postgres-XL
den kombiniert (siehe etwa [3]).
705 s 917 s 335 s
k-Means. Diese Aufgabe ist nicht Bestandteil des Stone-
braker-Artikels [11], wurde aber in die Tests aufgenommen, Die Ergebnisse entsprechen von der Tendenz her dem des
weil weder der Grep Task noch der Join Task die Komple- Join Task, auch wenn dort die Abstände zwischen DBMS-
xität der in PArADISE umzusetzenden Machine-Learning- Lösung und den Big-Data-Frameworks noch deutlicher wa-
Algorithmen (ML) aufweisen. Eine Umsetzung von ech- ren.
”
ten“ ML-Algorithmen wie dem im PArADISE-Projekt auch
verwendeten Hidden-Markov-Modell (siehe [9]) erwies sich
für das 14 Wochen andauernde, in der Vorlesungsperiode 7. ZUSAMMENFASSUNG UND AUSBLICK
stattfindende Projekt als zu aufwendig. Daher wurde mit Mit diesem Beitrag wollten wir nicht nur die Ergebnisse ei-
k-Means ein Clustering-Algorithmus als einfacher Vertreter nes Artikels von Stonebraker [11] nachvollziehen, sondern die
von Data-Mining-Techniken ausgewählt. Szenarien (Tasks), Plattformen und Hardware-Umgebungen
Wir stellen hier nun kurz das Prinzip von k-Means dar. auf die Anforderungen im PArADISE-Projekt hin anpassen
Für genauere Informationen verweisen wir etwa auf [5]. Die sowie gerade die Plattformen auf den heutige Stand aktua-
folgende Erklärung bezieht sich jeweils auf die folgende gra- lisieren.
phische Darstellung der Datenpunkte und Cluster. Während Stonebraker im Jahre 2010 Hadoop, ein unbe-
1. Es werden k beliebige Datenpunkte als initiale Clus- kanntes zeilenorientiertes DBMS und Vertica als Vertreter
terzentren (grün) gewählt. spaltenorientierter, paralleler DBMS verglich, haben wir als
Plattformen Spark und Flink (sowie Hadoop als grundlegen-
2. Anschließend werden die Distanzen von jedem Daten- des System) und als Vertreter zeilenorientierter, paralleler
punkt zu jedem Clusterzentrum berechnen und der Da- DBMS Postgres-XL ausgewählt.
tenpunkt dem Zentrum minimaler Distanz zugeordnet. Bei den Szenarien haben wir ein einfaches Data-Mining-
Dadurch werden k Cluster (rot und blau) gebildet. Szenario (Clustering mit k-Means) ergänzt.
Die Tests bestätigen die Tendenz des Stonebraker-Tests: Literatur
parallele DBMS, selbst in einer eher unpassenden zeilenori- [1] 2ndQuadrant. “Postgres-XL official website”. In: (2018).
entierten Architektur, können im eher Information-Retrieval- url: https : / / www . postgres - xl . org (besucht am
artigen Grep Task zumindest größenordnungsmäßig mithal- 07. 03. 2018).
ten, hängen aber die Big-Data-Analytics-Plattformen Spark
und Flink bei komplexeren Aufgaben (Join Task und k- [2] Martı́n Abadi u. a. “TensorFlow: A System for Large-
Means) deutlich ab. Scale Machine Learning”. In: OSDI. USENIX Associa-
Nimmt man die Ergebnisse von Stonebraker als das 1:0 tion, 2016, S. 265–283.
für parallele DBMS, so konnten die Rostocker Tests nun auf [3] Ilvio Bruder u. a. “Daten wie Sand am Meer - Date-
2:0 erhöhen. Natürlich ist dieses Ergebnis begünstigt durch nerhebung, -strukturierung, -management und Data
das Heimspiel, das die Postgres-XL-Gruppe hier absolvie- Provenance für die Ostseeforschung”. In: Datenbank-
ren konnte: zwar war der konkrete Aufwand im Projekt zwi- Spektrum 17.2 (2017), S. 183–196.
schen den Plattformen vergleichbar, allerdings waren die Er- [4] Paris Carbone u. a. “Apache FlinkTM : Stream and Batch
fahrungen bei den studentischen Projektteilnehmern in den Processing in a Single Engine”. In: IEEE Data Eng.
DBMS-bezogenen Implementierungs- und Tuning-Aspekten Bull. 38.4 (2015), S. 28–38. url: http : / / sites .
deutlich höher als in den neueren Plattformen wie Spark computer.org/debull/A15dec/p28.pdf.
und Flink. Ein weiteres Gegentor konnte nur verhindert wer-
den, weil einige Kriterien wie die Skalierbarkeit ausgeblendet [5] Jürgen Cleve und Uwe Lämmel. Data Mining – 2. Auf-
wurden: hier hätten Spark und Flink bei einer Veränderung lage. De Gruyter, 2016.
der Hardware-Umgebung (Erhöhung der Knotenanzahl) ge- [6] Jeffrey Dean und Sanjay Ghemawat. “MapReduce: a
genüber dem Uminstallationsaufwand bei Postgres-XL einen flexible data processing tool”. In: Commununications
klaren Vorteil gehabt. of the ACM 53.1 (2010), S. 72–77.
Für einen Heimsieg hoffen wir aber in Zukunft trotzdem
[7] Hannes Grunert und Andreas Heuer. “Datenschutz im
auf weitere Tore für die SQL-DBMS-basierten Lösungen,
PArADISE”. In: Datenbank-Spektrum 16.2 (2016), S. 107–
denn die vorgenommenen Tests können nur ein Anfang sein
117. doi: 10.1007/s13222-016-0216-7. url: https:
und müssen in folgenden Aspekten erweitert werden:
//doi.org/10.1007/s13222-016-0216-7.
• Das RMDRF-Großgerät lief derzeit noch in einer fi- [8] Andreas Heuer. “METIS in PArADISE: Provenance
xierten, sehr kleinen Konfiguration (drei Knoten). Hier Management bei der Auswertung von Sensordatenmen-
werden wir in Zukunft die Konfiguration verändern, gen für die Entwicklung von Assistenzsystemen”. In:
um Auswirkungen der Hardware-Konfiguration erken- BTW Workshops. Bd. 242. LNI. GI, 2015, S. 131–136.
nen zu können.
[9] Dennis Marten und Andreas Heuer. “Machine Lear-
• Bei den Tasks werden wir zusätzliche Mining-Algorith- ning on Large Databases: Transforming Hidden Mar-
men und Algorithmen Maschinellen Lernens mit auf- kov Models to SQL Statements”. In: Open Journal of
nehmen und auf den verschiedenen Plattformen imple- Databases (OJDB) 4.1 (2017), S. 22–42. issn: 2199-
mentieren. 3459. url: https : / / www . ronpub . com / ojdb / OJDB _
2017v4i1n02_Marten.html.
• Bei den Systemen fehlt uns bisher ein Vertreter von [10] Derek Gordon Murray u. a. “Naiad: a timely dataflow
spaltenorientierten, parallelen DBMS. Als Ersatz für system”. In: SOSP. ACM, 2013, S. 439–455.
das von Stonebraker verwendete Vertica haben wir be-
reits erste Tests auf Actian Vector (früher VectorWi- [11] Michael Stonebraker u. a. “MapReduce and parallel
se, siehe etwa [13]) durchgeführt, die vielversprechend DBMSs: friends or foes?” In: Communications of the
sind. Vector gibt es auch in einer parallelen Variante ACM 53.1 (2010), S. 64–71.
als VectorH (Vector in Hadoop). [12] Matei Zaharia u. a. “Apache Spark: A Unified Engine
for Big Data Processing”. In: Communications of the
Die Hoffnung ist, dass sich auch weiterhin DBMS-Lösungen ACM 59.11 (Okt. 2016), S. 56–65. issn: 0001-0782.
mit SQL als Schnittstelle als konkurrenzfähige Alternative doi: 10.1145/2934664. url: http://doi.acm.org/
zu MapReduce-Programmierparadigmen und anderen spe- 10.1145/2934664.
zialisierten Big-Data-Analytics-Umgebungen erweisen, da-
mit wir die vielfältigen Vorteile einer solchen Lösung in Be- [13] Marcin Zukowski und Peter A. Boncz. “Vectorwise:
zug auf formalisierbare und automatisierbare Anfragetrans- Beyond Column Stores”. In: IEEE Data Eng. Bull.
formationen ohne großen Performance-Verlust ausnutzen kön- 35.1 (2012), S. 21–27.
nen. Diese Anfragetransformationen benötigen wir, um wei-
tere Kernziele des PArADISE-Projektes zu verwirklichen:
die Wahrung der Privatsphäre der Nutzer von Assistenzsys-
temen durch datensparsame Auswertung von Big Data, das
Provenance Management zur Ermittlung von Ursachen bei
fehlerhaften Modellbildungen, und die Nachhaltigkeit der
Analyseprogramme im Kontext einer Informationssystem-
Infrastruktur beim Anbieter des Assistenzsystems. Letzte-
res ist durch die Verwendung von SQL-Basisoperationen als
intergalactic dataspeak“ gegeben.
”