Apache Spark (Teil 1/2)

In Zeiten der Industrie 4.0 und des Internet of Things hat jede Maschine und immer mehr Objekte des täglichen Lebens eine Netzwerkverbindung. Über diese Verbindung tauscht sich das jeweilige Gerät mit der Außenwelt aus und kann über die Zeit eine große Menge an Daten generieren. Um diese Daten zu verarbeiten und in Echtzeit zu analysieren, gibt es große verteilte Systeme, welche diese Daten strukturieren und versuchen, sie möglichst effizient zu verarbeiten. Mit Apache Spark gibt es nun eine Technologie mit dem Potenzial, diese Verarbeitung massiv zu beschleunigen.

Dies ist der erste Artikel einer zweiteiligen Serie zu Apache Spark. Während der erste Artikel die allgemeine Funktionsweise von Apache Spark erklärt, legt der zweite Artikel den Fokus auf die praktische Anwendung anhand einiger Code-Beispiele.

Was ist Apache Spark?

Apache Spark ist eine clusterfähige Datenverarbeitungsengine, welche Daten strukturieren kann und danach unterschiedlichste Operationen auf der Gesamtdatenmenge oder auf Teilmengen ausführen kann. Spark wurde von UC Berkeleys AMP Lab 2009 entwickelt und 2010 an die Apache Software Foundation abgegeben. Seitdem ist Apache Spark ein Open Source Projekt und außerdem ein Top Level Project der Apache Software Foundation. Spark ist in Scala entwickelt und unterstützt als Programmiersprachen neben anderen auch Java, Python und Clojure.

Spark zeichnet sich durch eine besonders schnelle und effiziente Verarbeitung von großen Datensätzen aus. Die hohe Geschwindigkeit wird unter anderem durch In-Memory-Computation erreicht. Dazu später mehr. Außerdem enthält Spark noch eine leicht zu benutzende API, sowie eine integrierte SQL-Schnittstelle, ein Modul für maschinelles Lernen (MLib) und GraphX. GraphX ist eine Graphenverarbeitungsengine und erlaubt auch parallele Graphenverarbeitung. Daneben sind neben einer Streaming Library noch mehrere Adapter für unterschiedliche auf Hadoop basierende Technologien enthalten.

Wie funktioniert Spark?

Natürlich muss Spark die zu verarbeitenden Daten in irgendeiner Form strukturiert speichern. Dazu werden sogenannte Resilient Distributed Datasets (RDD) verwendet. In diesen Datasets werden die eigentlichen Daten gespeichert (vergleichbar mit einer SQL-Tabelle). Dadurch, dass die Datasets auf den Knoten des Spark Clusters auf mehreren Knoten verteilt gespeichert sind und sich die Informationen in den Datasets bei Verlust wiederherstellen können, sind die Daten einerseits fehlertolerant und unterstützen andererseits quasi nativ parallele Verarbeitung. Außerdem sind die Datasets immutable, das heißt es wird immer eine neue Instanz erzeugt, sobald Daten transformiert werden.

Auf den Datasets können Operationen ausgeführt werden. Diese gliedern sich in zwei Gruppen. Auf der einen Seite gibt es die Actions. Dazu zählen alle Operationen, die die Daten nicht transformieren. Beispiele wären eine count-Operation, die die Einträge im Dataset zählen kann, oder eine first-Operation, die den ersten Eintrag aus dem Dataset zurückgibt.

Auf der anderen Seite gibt es die Transformations, welche, wie der Name schon sagt, die Daten transformieren. Da die Datasets, wie oben beschrieben, immutable sind, werden bei der Transformation neue Datasets erzeugt, anstatt bestehende zu verändern. Zu den Transformationsoperationen gehören beispielsweise Load-Operationen, welche Daten aus Dateien oder Datenbanken importieren können, Map-Operationen, sowie Filter-Operationen und Mengenoperationen (Union, Join, Intersection).

Hadoop und Spark

Klingt nach Hadoop. Ist Spark also ein Substitut für Hadoop? Nein, nicht unbedingt. Spark kann sogar als unterliegende Dateisystemebene das Hadoop Distributed File System (HDFS) nutzen.

apache-spark_spark_hadoop

Wie wir sehen, wird der eigentliche Speicher (Festplatten, SSDs oder In-Memory, hier in blau) von Hadoop wegabstrahiert. Apache Spark kann hier als Werkzeug für Hadoop verstanden werden und ersetzt die Implementierung des für Datentransformation zentralen MapReduce-Algorithmus in Hadoop. Mehr dazu später. Hadoop ist also ausschließlich für die verteilte Speicherverwaltung zuständig, während Apache Spark den Teil des Computings übernimmt.

Außerdem ist es vollkompatibel mit Hadoop v1 und v2 und lässt sich in ein bestehendes Hadoop Cluster deployen. Allerdings gibt es auch etliche Adapter wie für das Datenbanksystem Cassandra oder SparkR. Außerdem gibt es Unterstützung für Alluxio/Tachyon, Apache Hive und AWS S3, sowie weitere vergleichbare Technologien. Wenn man kein Hadoop zum Clustermanagement verwenden möchte, gibt es also einige Alternativen. Allerdings wird Spark üblicherweise in Kombination mit Hadoop oder Cassandra verwendet.

Was ist das Besondere an Spark?

Um die Besonderheiten von Spark nachzuvollziehen, müssen wir zunächst den allgemeinen Datenverarbeitungsprozess, beispielsweise mit MapReduce, verstehen. Die aktuelle MapReduce-Implementierung in Hadoop ist darauf optimiert, die Berechnungen von Daten auf möglichst viele Clusterknoten zu verteilen. Dabei werden die Daten vor der Transformation geladen. Dann wird die Transformation ausgeführt und die Daten werden wieder persistiert. Das ist effizient, wenn in den meisten Fällen nur eine Operation auf dem hereinkommenden Datenstrom oder den Datasets im Cluster ausgeführt werden muss.

Wenn ein Algorithmus die Daten jedoch mehrfach transformieren muss, läuft dieser somit nicht mit optimaler Effizienz. Diese Grafik veranschaulicht die alte Implementierung und zeigt den neuen Ansatz von Apache Spark:

apache-spark_inmemory

Wie man sieht, werden die Daten bei der MapReduce-Implementierung in Hadoop zunächst geladen. Danach wird die Transformation ausgeführt und das Zwischenergebnis persistiert. Dies kann man als atomaren Vorgang betrachten, wobei die Transformation selbst natürlich auf mehreren Clusterknoten parallel geschieht. Wenn man jetzt allerdings weitere Transformationen anfügen möchte, muss das Zwischenergebnis wieder geladen, weiter transformiert, und erneut gespeichert werden. Somit müssen bei einer beliebigen Anzahl n von hintereinander gereihten Transformationen die Tupel in den Datasets auch n Mal neu eingeladen und n Mal gespeichert werden.

Bei Apache Spark müssen die Daten hingegen nur einmal geladen werden und können danach durch beliebig viele Transformationsebenen gestreamt werden. Erst wenn alle Transformationen abgeschlossen sind, werden die Daten wieder persistiert. Die Veränderung zu der vorher beschriebenen Methode ist also deutlich gravierender, als einfach nur das gesamte HDFS In-Memory zu verarbeiten.

Die Stärke dieser multiplen Transformationsebenen kann Apache Spark besonders auf Systemen ohne vollständige In-Memory-Realisierung ausspielen. Hier wird die IO-Last spürbar reduziert, was sich wiederum signifikant auf die Gesamtperformance auswirkt.

Fazit

Apache Spark ist besonders in nicht-statischen Systemen, in welchen Daten in Echtzeit verarbeitet werden müssen, eine große Bereicherung. Besonders in Anwendungsfällen, in denen die Datenauswertung nicht trivial ist und ein mehrstufiger Auswertungsprozess vorhanden ist, kann Spark seine Stärken voll ausspielen. Beispiele hierfür wäre etwa eine Echtzeit-Marketingkampagne, Online-Produktempfehlungen in einem Webshop, maschinelles Lernen, aber auch die Optimierung von industriellen Produktionsanlagen. So könnten in einer modernen Industrie-4.0-Fabrik die Daten von tausenden Sensoren in Echtzeit überwacht werden und durch komplexe stochastische Methoden mögliche Ausfälle der Fertigungsmaschinen rechtzeitig vorhergesehen werden.

Wie eine konkrete Implementierung aussehen könnte, werden wir uns im nächsten Artikel ansehen.

Short URL for this post: http://wp.me/p4nxik-2KC
This entry was posted in Open Source BI and tagged , , , , . Bookmark the permalink.

One Response to Apache Spark (Teil 1/2)

  1. Pingback: Apache Spark – Success Story | techscouting through the java news

Leave a Reply