In our research project PArADISE, the data-driven development of assistive systems is supported by the highly parallel analysis of large amounts of sensor data. To achieve di erent 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 algorithms). These SQL queries should then be evaluated by a parallel DBMS. Of course, parallel row store DBMS are competing with column oriented DBMS architectures, as well as with recent big data analytics environments such as map reduce or data ow 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 reconstruct the results of Stonebraker within two studentsA^ t' projects at the University of Rostock. Additionally, we wanted 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 studentsA^ t' projects.
Andreas Heuer
Universität Rostock Albert-Einstein-Str. 22
18059 Rostock heuer@informatik.unirostock.de Ein Vergleich von Big-Data-Analytics-Plattformen
18059 Rostock daniel.dietrich@ uni-rostock.de
18059 Rostock ole.fenske@ uni-rostock.de
18059 Rostock stefan.schomacker@ uni-rostock.de
18059 Rostock
philipp.schweers@
uni-rostock.de
Im Projekt PArADISE wird die datengetriebene
Entwicklung von Assistenzsystemen durch die hochparallele
Analyse gro er Mengen von Sensordaten unterstutzt. Um dabei
verschiedene Ziele wie die Sicherung von Privatsphare,
Provenance und Nachhaltigkeit zu erreichen, sind wir darauf
angewiesen, die Analyseprogramme (Mining- oder
MachineLearning-Algorithmen) in SQL umzusetzen und dann
moglichst mit parallelen DBMS zu realisieren. Dabei stehen
diese parallelen DBMS-Losungen auf zeilenorientierten
DBMSArchitekturen naturlicherweise in Konkurrenz zu
spaltenorientierten Architekturen, gleichzeitig aber auch zu modernen
Big-Data-Analyse-Umgebungen wie MapReduce- oder
Daten ussprogrammierungsansatzen. In einem Artikel von
Stonebraker [
Information Systems [Database Management System Engines]: MapReduce-based systems; Information Systems [Database Management System Engines]: Relational parallel and distributed DBMSs; Information Systems [Database Administration]: Database performance evaluation; Computer Systems Organization [Parallel Architectures]: Multicore architectures Big Data Analytics, Parallele DBMS, Map-Reduce, Performance, Postgres-XL, Hadoop, Spark, Flink 1.
Im Rostocker Projekt PArADISE [
Um die oben genannten Ziele zu erreichen, sind wir darauf angewiesen, die Analyseprogramme (Mining- oder MachineLearning-Algorithmen) in SQL umzusetzen und dann moglichst mit parallelen DBMS zu realisieren. Dabei stehen diese parallelen DBMS-Losungen auf zeilenorientierten DBMSArchitekturen naturlicherweise in Konkurrenz zu spaltenorientierten Architekturen, gleichzeitig aber auch zu modernen Big-Data-Analyse-Umgebungen wie MapReduce- oder Daten ussprogrammierungsansatzen.
Die Communications of the ACM hatte im Jahre 2010
zwei Artikel mit gegensatzlichen Positionen vero entlicht:
einen Artikel von Google [
Kurz zusammengefasst kann gesagt werden: Stonebraker stellte die U berlegenheit der DBMS-Losungen gegenuber Hadoop nicht nur in Testfallen heraus, in denen man diese U berlegenheit erwarten konnte (Aufgaben, die einen Verbund gro er Datenbestande als Teilproblem hatten), sondern auch in Tasks, fur die eine MapReduce-artige Verarbeitung eigentlich eingefuhrt wurde (Wortsuche in Texten). Nach diesen Tests stand es 1:0 fur die von Stonebraker favorisierten parallelen DBMS als Big-Data-Plattformen.
Die Ergebnisse von Stonebraker sollten nun einige Jahre spater in zwei studentischen Projekten an der Universitat Rostock nachvollzogen, aber auch auf andere Arten von Problemen und neuere Software-Plattformen ubertragen werden (siehe Abschnitt 4 fur die genauere Aufgabenstellung). Neben Hadoop sollten auch neuere Systeme wie Spark, Flink, Naiad und Tensor ow getestet werden. Und neben den drei Task-Typen von Stonebraker sollte noch mindestens ein Data-Mining-Verfahren als komplexere Task erganzt werden. Die Testumgebung und die Testfalle, die in Rostock umgesetzt wurden, werden in den Abschnitten 5 und 6 genauer vorgestellt.
Die Ergebnisse der beiden studentischen Projekte werden ebenfalls in Abschnitt 6 genauer vorgestellt. Sie untermauern die These von Stonebraker, dass nicht nur spaltenorientierte DBMS bei vielen Typen von Analysen auf gro en Datenmengen einer MapReduce-Losung uberlegen sind, sondern auch zeilenorientierte Architekturen mithalten konnen. Die Tests haben also fur die Stonebraker-Argumentation kein Gegentor beschert, sondern die Argumentation bestatigt: es steht damit 2:0 fur die DBMS-Plattformen.
PArADISE (Privacy-AwaRe Assistive Distributed
Information System Environment) [
In der Entwicklungsphase (links im Bild) werden unter
Versuchsbedingungen massiv Sensordaten erfasst, um
daraus Modelle fur Situationen, Handlungen und
Intentionen der beteiligten Personen abzuleiten. Die
Ableitung der Modelle geschieht uber
Machine-LearningAlgorithmen (ML), die in SQL umgesetzt werden. Die
Umsetzung in SQL wird in [
In der Transformationsphase (im Bild der Pfeil von
links nach rechts) wird mit
Provenance-ManagementTechniken eine kleine, aber aussagefahige Auswahl der
Sensoren getro en, mit der unter genugender Kon
denz ahnliche Modelle hergeleitet werden konnen. Die
Rolle des Provenance Management bei der
Entwicklung von Assistenzsystemen skizzieren wir in [
Grep Web Log
Join Sowohl in der Entwicklungsphase als auch in der Nutzungsphase werden wir auf einem Parallelrechner gro e Mengen von Sensordaten analysieren mussen. Das Zielsystem fur diese Analysen ist ein paralleles DBMS, das SQL-Anfragen parallel und e zient verarbeiten kann (in der Architektur mit PSQL und PDBMS bezeichnet). Um abschatzen zu konnen, ob (und wenn ja, wie stark) die Performance durch die Nutzung eines SQL-DBMS leidet, testen wir eine solche Losung gegen spezialisierte Plattformen wie Hadoop, Spark und Flink. Ziel ist dabei nicht unbedingt, in jedem Fall besser zu sein als diese Plattformen, sondern moglichst wenig gegenuber diesen zu verlieren. Die Vorteile der Nutzung von DBMS-Technologien (wie erwahnt: Privacy, Provenance, Nachhaltigkeit) wiegen schwerer als ein geringer Performance-Verlust.
Beim Start des PArADISE-Projektes waren daher die
Ergebnisse von Stonebraker [
Stonebraker et al. publizierten 2010 [
Es wurden die folgenden Szenarien verglichen:
Grep Task. Hierbei werden 10 Milliarden Datensatze (1 TB) nach einer Zeichenkette durchsucht. Bei 100 Knoten ergibt sich eine Datenmenge von 10 GB pro Knoten. Ein Datensatz besteht aus 100 Bytes (10 Bytes Schlussel, 90 Bytes Wert). Es liegt keine Sortierung vor und es darf kein Index verwendet werden. Dieser Task ist die Basis fur Analysen von Webseiten, etwa bei Google. Es ist daher zu erwarten, dass dieser Task sehr gut zu Map-Reduce-Systemen passt.
Web Log Task. Die zweite Aufgabe besteht aus einer Aggregation mit GROUP BY auf einem Web Log mit Besuchen. Der Log hat eine Gro e von 2 TB und beinhaltet 155 Millionen Datensatze. Bei 100 Knoten ergibt sich eine Datenmenge von 20 GB pro Knoten. Diese Aufgabe wurde ohne Index durchgefuhrt.
Join Task. Diese Aufgabe beschreibt einen Verbund uber zwei Tabellen, eine Selektion und eine Aggregation. Der Web Log wird mit einer PageRank-Tabelle verbunden, die 18 Millionen Datensatze und eine Gro e von 100 TB hat. Im ersten Teil muss die IP-Adresse mit der gro ten Besuchsanzahl (Visits) in einem gewissen Zeitraum gefunden werden. Im zweiten Teil wird daraus der durchschnittliche PageRank berechnet.
Grep Task und Join Task waren dann Ausgangspunkt fur die eigenen Untersuchungen, die wir im folgenden Abschnitt Data Scientist / ML Developer
ML-Code ML2PSQL PSQL-Code
PDBMS …
PDBS
Poodle Remainder Query
PDBMS
PDBS … Client 1
Privacy Decomposition
PD PD
ML-Code ML2PSQL PSQL-Code
Privacy
Decomposition Client 2
Privacy Decomposition
PD PD … … …
Client n
Privacy Decomposition
PD PD
Abbildung 1: Das PArADISE-Projekt (aus [
Einordnung der Ergebnisse von Stonebraker.
Sicher war der Stonebraker-Artikel [
Fur unsere Originalfragestellung, ob die von uns aus anderen Grunden favorisierten SQL-basierten Systeme zur parallelen Auswertung gro er Datenmengen von der E zienz her mit den spezialisierten Big-Data-Analytics-Frameworks mithalten konnen, hatten wir nun aber einen interessanten Ausgangspunkt, den wir in eigenen Tests vertiefen wollten.
Im Sommersemester 2017 wurde in zwei verschiedenen Projektveranstaltungen (eine fur den Bachelor Wirtschaftsinformatik, eine fur den Bachelor Informatik) die Aufgabe gestellt, die Stonebraker-Ergebnisse nachzuvollziehen, aber auch auf andere Arten von Problemen und neuere SoftwarePlattformen zu ubertragen. Die Wirtschaftsinformatik-Gruppe sollte dabei neben Hadoop auch neuere Systeme wie Spark, Flink, Naiad und Tensor ow untersuchen und drei davon fur reale Tests aussuchen. Die Informatik-Gruppe sollte diese Tests parallel auf einem parallelen SQL-DBMS, in diesem Fall Postgres-XL, durchfuhren.
Der notige Aufwand fur die Realisierung der Tests ist zwar durch die verschiedenen Projektformen im Wirtschaftsinformatik- und Informatik-Studium nicht direkt vergleichbar, die Aufwande wurden aber in den Projekten gemessen und sind von der Gro enordnung her vergleichbar:
Die funfkop ge Wirtschaftsinformatik-Gruppe wendete nach Abzug von Einarbeitungs- sowie Installationsund Administrations-Tatigkeiten 160 Stunden fur die Datenaufbereitung und 170 Stunden fur die Implementierung der Tasks in den drei fur reale Tests ausgewahlten Plattformen auf.
Von der vierkop gen Informatik-Gruppe waren drei nur fur Installation und Administration des PostgresXL-Systems zustandig, da dieses auch fur mehrere Parallelprojekte benutzt wurde. Nur einer der InformatikStudenten beschaftigte sich dann mit den StonebrakerTests. Fur die Datenaufbereitung wurden durch die Vorarbeiten der Wirtschaftsinformatik-Gruppe nur 40 Stunden benotigt, die Implementierung der Tasks erfolgte dann (nach Abzug der Einarbeitung) in 60 Stunden.
Pro System war der Aufwand zur Umsetzung der Tasks mit 50 bis 60 Stunden erstaunlich gleichma ig verteilt.
Neben den drei Task-Typen von Stonebraker sollte noch mindestens ein Data-Mining-Verfahren als komplexere Task erganzt werden. In den beiden Projektgruppen wurde dann entschieden, den Web Log Task des Stonebraker-Tests durch einen einfachen Data-Mining-Algorithmus (Clustering durch k-Means) zu ersetzen. Die Testumgebung und die Testfalle werden in folgenden Abschnitten 5 und 6 noch genauer vorgestellt.
Nach einer Literaturanalyse wurde von der
Wirtschaftsinformatik-Gruppe die Auswahl der Systeme auf drei
beschrankt: Hadoop [
Postgres-XL [
Wir werden nun die Hardware-Umgebung fur die Tests vorstellen und danach die neuen Tasks sowie die Ergebnisse auf den verschiedenen Plattformen. Bei der HardwareUmgebung muss beachtet werden, dass das RMRDF1-Gro gerat durch die Projektgruppen nur in kleinerem Ma stab benutzt werden konnte, so dass die Ergebnisse zum Vergleich mit den Stonebraker-Daten skaliert werden mussen.
Fur die Durchfuhrung der Testfalle standen drei Virtual Private Server (VPS) zur Verfugung. Jeder Knoten besteht aus einem Intel Haswell mit 4 Kernen, 64 GB Hauptspeicher und einer durchschnittlichen Festplattengeschwindigkeit von 350 MB/s. Ein VPS diente zusatzlich als zentrale Koordinationseinheit. Die verwendete Linux-Distribution ist CentOS 7.
Hadoop in der Version 2.7.2, inklusive Hadoop Distributed File System (HDFS) und Yet Another Resource Negotiator (YARN), bildet die Grundlage fur die Berechnungen auf den Plattformen Flink und Spark. Das HDFS ermoglicht den Zugri und die verteilte Speicherung von folgenden Testdaten: Als hochvernetzte Menge von Dokumenten wurde statt eines Web-Ausschnitts ein Ausschnitt des Twitter-Follower-Graphen gewahlt: der Umfang war hier 26 GB. Das errechnete PageRank-Ergebnis zu diesem Graphen umfasste 1,15 GB.
Die zu untersuchenden Web-Log-Eintrage hatten einen Umfang von 4,29 GB.
Die Kon gurationsparameter des HDFS konnen der nachfolgenden Tabelle entnommen werden. Um einen besseren Vergleich der Messergebnisse herstellen zu konnen, wurde die Kon guration an den Ausgangsparametern angepasst. 1Rostock Massive Data Research Facility, ein Gro gerat fur datengetriebene Forschung, das vier Lehrstuhle im Institut fur Informatik der Universitat Rostock gemeinsam betreiben.
Parameter Speicherblockgro e Heapsize Task Executor Heapsize History Server Heapsize DataNode Rackawareness Replikate Kompression Das Postgres-XL Cluster besteht aus 9 Koordinatoren und 9 Datenknoten. Jedem Koordinator kann somit genau ein Datenknoten zugewiesen werden. Die Kon gurationsparameter jeder Einheit sind wie folgt:
Parameter E ective Cache Size Worker Memory Maintenance Memory Temporary Bu er Shared Bu er Segment Size
Wert 4 GB 512 MB
1 GB 64 MB 1 GB 1 GB An den Hardware-Parametern fallt auf, dass sie in Groenordnungen (Faktor 30) von den beim Stonebraker-Test verwendeten Parametern abweichen. Bei den in Rostock verwendeten Umgebungen di erierten die Hadoop-, Spark- und Flink-Installationen und die Postgres-XL-Installation um den Faktor drei. Damit die Gro enordnungen vergleichbar bleiben, haben wir die Testergebnisse um diese Faktoren skaliert, so dass die Ergebnisse bei Annahme eines linearen Zusammenhangs vergleichbar bleiben.
Wir stellen nun die drei untersuchten Tasks und die Ergebnisse fur die drei getesteten Plattformen Flink, Spark und Postgres-XL vor. Hadoop wurde als Basis fur Flink und Spark genutzt, nicht jedoch fur eigenstandige Tests. 6.
Fur die Evaluierung der drei Plattformen wurden die Testfalle Grep Task und Join Task des Stonebraker-Vergleichs ausgewahlt. Zusatzlich wurde als einfacher Mining-Algorithmus ein Clustering-Verfahren (k-Means) umgesetzt. Wir beschreiben nun die Testfalle und die Ergebnisse auf den drei Systemen.
Grep Task. Diese Aufgabe orientiert sich an dem OriginalGoogle-Map-Reduce-Grep-Task. Dabei sollte die Hau gkeit des Vorkommens einer bestimmte Zeichenkette in dem 26 GB gro en Twitter-Follower-Graphen ohne Sortierung und ohne Nutzung eines Indexes ermittelt werden. Im Beispiel werden im Twitter-Follower-Graphen die Zeilen der relationalen Darstellung extrahiert, die eine 4\ enthalten. Die Anzahl dieser Vorkommen im Graphen "soll dann ausgegeben werden.
Twitter-Follow-Graph
ID1 ID2 12343454 86968792 29656457 94665834 37695979 81632765
Anzahl Zeilen die 4\ enthalten "
Anzahl 2 Die folgende Tabelle enthalt die durchschnittliche Laufzeit des Tests je System: 4. Die Schritte (2) und (3) werden so lange wiederholt, bis sich die Cluster nicht mehr verandern oder die Iterationsobergrenze erreicht ist. Im Folgenden wurde eine Grenze von 10 Wiederholungen verwendet. 1: Beliebige Punkte als Clusterzentren wahlen 2: Distanzen ermitteln und
Cluster bilden 20 40 60 80 100 20 40 60 80 100
Postgres-XL als zeilenorientiertes paralleles DBMS hat hier die schlechteste Laufzeit. Die Unterschiede zwischen Flink und Postgres-XL sind aber nicht so deutlich wie erwartet. Die beste Laufzeit hat Spark.
Join Task. Diese Aufgabe entspricht dem Join Task aus
dem Stonebraker-Artikel [
Diese Aufgabe eignet sich durch die Verknupfung von zwei Datenbestanden sehr gut fur SQL-DBMS, auch wenn diese nur in einer zeilenorientierten Architektur vorliegen. Flink uberholt nun Spark, fallt aber deutlich hinter Postgres-XL zuruck. Die Ergebnisse korrespondieren mit den 2010 von Stonebraker vero entlichten Ergebnissen (Hadoop el dort gegen beide DBMS-Losungen deutlich zuruck).
Sicher stellt diese Join-Task ein Heimspiel fur die
SQLDBMS wie das von uns verwendete Postgres-XL dar.
Allerdings ist ein solches Szenario auch in Data-Science- und
Big-Data-Analytics-Anwendungen nicht unublich. So
werden im Bereich des Forschungsdatenmanagements und
ihrer Auswerte-Prozeduren und -Work ows Daten
verschiedener Messreihen, Projekte und Abteilungen miteinander
verknupft sowie auszuwertende Daten mit Metadaten und
weiteren beschreibenden Daten aus anderen
Datenbestanden kombiniert (siehe etwa [
k-Means. Diese Aufgabe ist nicht Bestandteil des
Stonebraker-Artikels [
Wir stellen hier nun kurz das Prinzip von k-Means dar.
Fur genauere Informationen verweisen wir etwa auf [
Mit diesem Beitrag wollten wir nicht nur die Ergebnisse
eines Artikels von Stonebraker [
Wahrend Stonebraker im Jahre 2010 Hadoop, ein unbekanntes zeilenorientiertes DBMS und Vertica als Vertreter spaltenorientierter, paralleler DBMS verglich, haben wir als Plattformen Spark und Flink (sowie Hadoop als grundlegendes System) und als Vertreter zeilenorientierter, paralleler DBMS Postgres-XL ausgewahlt.
Bei den Szenarien haben wir ein einfaches Data-MiningSzenario (Clustering mit k-Means) erganzt.
Die Tests bestatigen die Tendenz des Stonebraker-Tests: parallele DBMS, selbst in einer eher unpassenden zeilenorientierten Architektur, konnen im eher Information-Retrievalartigen Grep Task zumindest gro enordnungsma ig mithalten, hangen aber die Big-Data-Analytics-Plattformen Spark und Flink bei komplexeren Aufgaben (Join Task und kMeans) deutlich ab.
Nimmt man die Ergebnisse von Stonebraker als das 1:0 fur parallele DBMS, so konnten die Rostocker Tests nun auf 2:0 erhohen. Naturlich ist dieses Ergebnis begunstigt durch das Heimspiel, das die Postgres-XL-Gruppe hier absolvieren konnte: zwar war der konkrete Aufwand im Projekt zwischen den Plattformen vergleichbar, allerdings waren die Erfahrungen bei den studentischen Projektteilnehmern in den DBMS-bezogenen Implementierungs- und Tuning-Aspekten deutlich hoher als in den neueren Plattformen wie Spark und Flink. Ein weiteres Gegentor konnte nur verhindert werden, weil einige Kriterien wie die Skalierbarkeit ausgeblendet wurden: hier hatten Spark und Flink bei einer Veranderung der Hardware-Umgebung (Erhohung der Knotenanzahl) gegenuber dem Uminstallationsaufwand bei Postgres-XL einen klaren Vorteil gehabt.
Fur einen Heimsieg ho en wir aber in Zukunft trotzdem auf weitere Tore fur die SQL-DBMS-basierten Losungen, denn die vorgenommenen Tests konnen nur ein Anfang sein und mussen in folgenden Aspekten erweitert werden: Das RMDRF-Gro gerat lief derzeit noch in einer xierten, sehr kleinen Kon guration (drei Knoten). Hier werden wir in Zukunft die Kon guration verandern, um Auswirkungen der Hardware-Kon guration erkennen zu konnen.
Bei den Tasks werden wir zusatzliche Mining-Algorithmen und Algorithmen Maschinellen Lernens mit aufnehmen und auf den verschiedenen Plattformen implementieren.
Bei den Systemen fehlt uns bisher ein Vertreter von
spaltenorientierten, parallelen DBMS. Als Ersatz fur
das von Stonebraker verwendete Vertica haben wir
bereits erste Tests auf Actian Vector (fruher
VectorWise, siehe etwa [
Die Ho nung ist, dass sich auch weiterhin DBMS-Losungen mit SQL als Schnittstelle als konkurrenzfahige Alternative zu MapReduce-Programmierparadigmen und anderen spezialisierten Big-Data-Analytics-Umgebungen erweisen, damit wir die vielfaltigen Vorteile einer solchen Losung in Bezug auf formalisierbare und automatisierbare Anfragetransformationen ohne gro en Performance-Verlust ausnutzen konnen. Diese Anfragetransformationen benotigen wir, um weitere Kernziele des PArADISE-Projektes zu verwirklichen: die Wahrung der Privatsphare der Nutzer von Assistenzsystemen durch datensparsame Auswertung von Big Data, das Provenance Management zur Ermittlung von Ursachen bei fehlerhaften Modellbildungen, und die Nachhaltigkeit der Analyseprogramme im Kontext einer InformationssystemInfrastruktur beim Anbieter des Assistenzsystems. Letzteres ist durch die Verwendung von SQL-Basisoperationen als "intergalactic dataspeak\ gegeben.