Apache Spark vs. Apache Flink: Hat Big Data made in Germany eine Chance?

Aufgrund seiner konkurrenzlosen Schnelligkeit, der reichhaltigen Funktionalität und weil es sich perfekt in Hadoop-Umgebungen einpasst, gilt das an der renommierten Berkeley-Universität entwickelte Open Source Projekt Spark weltweit als Schlüsseltechnologie für Big Data-Projekte. Ob da ein in Deutschland entstandenes Pendant mithalten kann?

Seit dem offiziellen Release im Mai 2014 hat Spark den Big Data Markt ordentlich durcheinandergewirbelt. Als Projekt im AMPLab der University of California in Berkeley gestartet, ist das Open Source Projekt mittlerweile als Apache Top Level-Projekt geführt und wird von vielen verschiedenen Seiten unterstützt und mit über 1000 Beteiligten weiterentwickelt. Angeblich bis zu hundert Mal schneller als Apache Hadoop, auf dem Spark basiert, sollen bestimmte Big Data Szenarien bewältigt werden können. Kann angesichts dieser Zahlen ein Big Data Framework aus Deutschland mithalten? Welches Framework ist schneller und effizienter – Apache Spark oder das noch relative neue Apache Flink? Die Antwort auf diese Fragen zu finden, war das Ziel meiner Masterarbeit.

 

Vergleicht man die Historie der beiden Frameworks, ergeben sich zunächst viele Parallelen: Ebenso wie Spark entstand auch Flink im universitären Umfeld, genauer gesagt beim gemeinsamen Forschungsprojekt Stratosphere  der TU Berlin, HU Berlin und des Hasso-Plattner-Instituts. Aus diesem Forschungsprojekt wurde dann ein Teil als eigenständige Entwicklung ausgegliedert und später auch unter der Schirmherrschaft der Apache Software Foundation als Open Source Projekt aufgenommen. Bereits nach kurzer Zeit wurde Flink als Top Level-Projekt geführt und erhielt einiges an Aufmerksamkeit.

 

Grundlagen beider Frameworks - Apache Spark vs. Apache Flink

Betrachtet man die technischen Grundlagen beider Frameworks, so lassen sich aufgrund einer ähnlichen Ausrichtung viele Gemeinsamkeiten (unterstützte Programmiersprachen, Memory Management, Machine Learning Bibliotheken, Nutzung von directed acyclic graphs - DAGs) finden. Im Detail gibt es jedoch teils gravierende Unterschiede. Viele lassen sich auf die jeweilige Philosophie zurückführen: Flink sieht Batches als Spezialfall von Streaming-Daten und legt daher das Hauptaugenmerk auf das Streaming, während Spark hauptsächlich auf die Verarbeitung von Batches spezialisiert ist. Dies zeigt sich vor allem im Processing Model, den genutzten Datenstrukturen und dem Windowing.

 

Wie genau sich die technischen Feinheiten auf die Effektivität der Frameworks auswirkt und wie sie gegeneinander konkurrieren, ist bisher kaum dokumentiert. Aus diesem Grund habe ich einen Vergleich aufgebaut, der in verschiedenen Szenarien auf unterschiedlich großen Clustern beide Frameworks gegeneinander testet.

 

Die Cluster, auf denen der Vergleich basiert, wurden über Amazon Web Services EMR initialisiert. Dabei wurden drei verschiedene Clustergrößen aufgebaut (5-, 10- und 20-Workerknoten). Die Cluster bestanden aus Instanzen des Typs m3.xlarge. Dieser bietet je Instanz vier virtuelle CPUs, 15 GiB (Gibibyte) Arbeitsspeicher und 2 x 40 GB SSDSpeicher. Der Vorteil von Amazon EMR besteht in der Konfigurationsauswahl, welche Apache Spark bereits zur Verfügung stellt. Über ein Bootstrap-Skript wurde dann auch Apache Flink auf allen Knoten installiert sowie einige weitere Konfigurationen der Cluster vorgenommen. Spark wurde in der Version 1.6.0 und Flink in der Version 0.10.3 installiert.

 

Um Spark und Flink miteinander zu vergleichen, wurden drei Szenarien im jeweiligen Framework in Java entwickelt. Das erste Szenario ist ein Word Count, das der Big Data Welt auch als „Hello World“ bekannt ist. Das Word Count Programm gibt von eingegebenen Texten ein Histogramm der Wörter wieder. Das zweite Szenario ist ein relationales Szenario und erstellt aus JSON-Dateien zwei Tabellen, verbindet diese über einen Join und führt eine Aggregation durch. Das dritte Szenario kommt aus dem Machine Learning Bereich und integriert den k-means Algorithmus, welcher Daten in Cluster einteilt. So können, wie in diesem Szenario, zum Beispiel zweidimensionale Punkte in einzelne Cluster eingeteilt werden. Die Daten für die Szenarien wurden auf Amazon S3 gehalten und von dort heraus geladen. 

  

Die Ergebnisse des Vergleichs kann man in den folgenden vier Diagrammen erkennen:

 

Das Machine Learning Szenario wurde zweimal durchgeführt. Die Ursache dafür liegt in der Verarbeitung der Eingabedaten von Spark. Nach der ersten Durchführung und der Betrachtung der Ergebnisse ließ sich erkennen, dass Spark die zur Verfügung gestellte Rechenleistung der höheren Cluster nicht nutzen kann. Nach detaillierterer Ursachenforschung konnte festgestellt werden, dass Spark die Eingabedaten nicht effektiv auf dem Cluster verteilen konnte. So wurden nur jeweils zwei Knoten zur Ausführung des Szenarios genutzt. Da die Eingabedaten aus nur einer einzelnen Datei stammten, konnte Spark diese nicht über den gesamten Cluster verteilen. Wenn die Eingabedaten, wie in der zweiten Durchführung des Szenarios, in mehrere Dateien aufgesplittet werden, gelingt es Spark, die Aufgaben auf den gesamten Cluster zu parallelisieren.

 

Aus den Ergebnissen lassen sich verschiedene Schlussfolgerungen ziehen: Zum einen lässt sich erkennen, dass Spark mit größeren Datenmengen besser zurechtkommt als Flink, währenddessen Flink jedoch die Skalierung des Clusters besser nutzen kann, um Performance-Gewinne zu erzielen. Weiterhin haben die Ergebnisse die Spezialisierung von Spark auf die Verarbeitung von relationalen Daten untermauert. Hier konnte Spark deutlich schneller arbeiten als Flink. Bemerkenswert ist auch, was bei der Durchführung des Machine Learning Szenarios zutage kam – nämlich dass Sparks Performance in großem Maße von der Art der Eingabedaten abhängig sein kann. Ohne die Aufteilung der Eingabedaten war Spark nicht in der Lage, die Aufgabe auf mehr als zwei Instanzen zu verteilen und konnte somit den Vorteil der Cluster nicht ansatzweise ausnutzen.

 

Zusammenfassend lässt sich sagen, dass trotz der ähnlichen Ausrichtung und Entwicklung beide Frameworks ihre eigene Nische gefunden haben. Beide haben technische Feinheiten, die beim jeweils anderen nicht zu finden sind. Daraus entstehen auch unterschiedliche Geschwindigkeiten in der Verarbeitung verschiedener Szenarien. Dennoch lässt sich anhand der Ergebnisse nicht ein Framework als per se besser bezeichnen. Viel mehr kommt es darauf an, welche Ziele man verfolgt und wie genau man diese erreichen will. Zu beachten ist, dass die hier präsentierten Ergebnisse nur eine Momentaufnahme darstellen und beide Tools bereits weiterentwickelt wurden. Die Ergebnisse können jedoch als eine erste Richtungsweisung dienen. Zum Schluss lässt sich sagen, dass sich Big Data made in Germany keineswegs verstecken muss und einiges an Potenzial aufweist.

Daniel Andreas

Seit seinem Master-Abschluss in Wirtschaftsinformatik im Frühjahr 2016 ist Daniel Andreas Teil des Berater-Teams von pmOne. Mit der Spezialisierung auf Data Warehouse- und Business Intelligence-Themen bringt er sein Fachwissen ein.

Blog-Beiträge von diesem Autor