Bachelorarbeit. Birger Kamp. Stream Processing in einem Spark Cluster. Fakultät Technik und Informatik Studiendepartment Informatik

Transkript

1 Bachelorarbeit Birger Kamp Stream Processing in einem Spark Cluster Fakultät Technik und Informatik Studiendepartment Informatik Faculty of Engineering and Computer Science Department of Computer Science

2 Birger Kamp Stream Processing in einem Spark Cluster Bachelorarbeit eingereicht im Rahmen der Bachelorprüfung im Studiengang Bachelor of Science Angewandte Informatik am Department Informatik der Fakultät Technik und Informatik der Hochschule für Angewandte Wissenschaften Hamburg Betreuender Prüfer: Prof. Dr. Olaf Zukunft Zweitgutachter: Prof. Dr. Ulrike Steffens Eingereicht am: XX XX XXXX

3 Birger Kamp Thema der Arbeit Stream Processing in einem Spark Cluster Stichworte Echtzeit Überwachung, Web Performance, Datenfluss Verarbeitung, Apache Spark, Apache Storm, ARM Kurzzusammenfassung Ein Webauftritt ist heutzutage das Mittel der Wahl um sich zu präsentieren. Die Webseite muss entwickelt, gewartet und gepflegt werden, dabei kann eine Messung der Web Performance unterstützen. Die Werte die man dabei erhält, sagen viel über die eigene Seite aus. Allerdings ist in den Messdaten viel mehr enthalten als man auf den ersten Blick sieht. Diese Arbeit beschäftigt sich damit, die Daten komplexer zu verarbeiten als es bislang getan wird, um noch mehr Informationen aus den Messdaten zu erhalten. Damit man zeitnah Zugriff auf diese Daten erhält, wird ein Spark-Cluster die Berechnungen durchführen. Birger Kamp Title of the paper Stream Processing in a Spark Cluster Keywords Realtime Monitoring, Web Performance, Stream Processing, Apache Spark, Apache Storm, ARM Abstract This document is about the processing of WebPageTest-Results by an ARM-Cluster.

4 Inhaltsverzeichnis 1 Spark mal in klein [5] Motivation Produktwahl Gliederung der Arbeit Grundlagen[20] Apache Spark Architektur Das Driver-Programm RDD Daten im Cluster Transformations und Actions Zusammengefasster Ablauf Spark Streaming Monitoring von Spark-Anwendungen Berkeley Data Analysis Stack Map-Reduce Verarbeitungsprinzip Verarbeitungsansatz von Spark Streaming Stream Processing Batch Processing Micro-Batch Processing Batch vs. Stream Architektur des Clusters[10] Zielsetzung Hardware Netzwerk Anforderungen an die Implementation Anforderungskatalog Input Daten Output Daten Software-Architektur Kontext des Systems Komponentendiagramm der Software Implementationsdetails iv

5 Inhaltsverzeichnis 4 Verarbeitung im Cluster[10] Vorverarbeitung des Inputs Der Algorithmus in der Verarbeitung Spark-Konfiguration Analyse der Verarbeitung[15] Erwartung Vergleichsaspekte Durchsatz Antwortzeit Auslastung der Hardware-Ressourcen Monitoring-Ergebnisse Node Cluster Node Cluster Analyse des Monitorings Durchsatz Antwortzeit Skalierung mit Anzahl der Nodes Analyse-Zusammenfassung Fazit[5] Zusammenfassung Ausblick v

6 1 Spark mal in klein [5] In der heutigen Zeit werden Daten nicht mehr nur durch manuelle Eingaben von Menschen erzeugt, die meisten Daten werden heutzutage vollautomatisch von Computern erschaffen. Beispielsweise durch Sensoren, die permanent Daten erstellen, die an anderer Stelle mit anderen Sensordaten zusammengeführt werden. Dieses Ergebnis wiederum erzeugt ein Ereignis auf das ein anderes System mit einer langen Reihe von weiterführenden Schritten reagiert. Diese Datenflut wurde von den Medien Big Data getauft. Dort beschäftigt sich das Thema vor allem mit der Erkennung von Mustern und dem Voraussagen bevorstehender Ereignisse. Inzwischen wird in der Gesellschaft der Begriff durch Edward Snowden vor allem in Verbindung mit Geheimdiensten und Internet-Datenkraken gebracht, wodurch das Thema in Verruf geraten ist. Für die Informatik bleibt das Buzzword nachwievor ein großes Thema, denn unter diesen Begriff fällt alles, was sich damit beschäftigt diese riesigen Datenmengen zu bewältigen. Große Firmen wie Google, Facebook, Twitter und Amazon verwenden riesige Server-Farmen und teilweise proprietäre Software-Systeme, die nicht der Öffentlichkeit zugänglich sind, um die riesigen Datenmengen verarbeiten zu können. Bis vor einiger Zeit war der Map-Reduce Pionier Apache Hadoop die Antwort wenn man Big Data Probleme lösen möchte. Hadoop erlaubt die Verarbeitung durch das Map-Reduce-Paradigma, was die Verteilung der Berechnung auf mehrere Rechner erlaubt. Dadurch hat der einzelne Computer eine geringere Last zu bewältigen. Matei Zaharia und eine Gruppe von Entwicklern haben daraufhin Hadoop modifiziert und performanter gestaltet, sodass es nun als Apache Spark weitergeführt wird. Vor einigen Wochen erst hat IBM 1 im großen Stil in die Spark-Entwicklung investiert. Sie haben nicht nur durch finanzielle Mittel unterstützt, sondern auch ein Team mit einer 4-stelligen Anzahl beigesteuert. Dies unterstreicht noch einmal die Wichtigkeit von BigData- Anwendungen für den aktuellen Trend im Cloud Computing. 1 IBM (2015) 1

7 1 Spark mal in klein [5] 1.1 Motivation Inzwischen wird auch vermehrt das Stream-Processing-Paradigma bei Big Data Problemen verwendet. Diese Art der Datenverarbeitung wird häufig verwendet bei solchen Problem wie einem Datenstrom von Sensordaten. Denn hier auf eine endliche Menge an Daten zu warten, wäre ein langwieriges Unterfangen. Also ist es empfehlenswert alle ankommenden direkt zu verarbeiten, wenn sie erhalten werden. In den großen Rechenzentren werden die ankommenden Daten mit modernster Server- Hardware begegnet, um die Rechenzeit so klein wie möglich zu halten. Üblicherweise findet man Spark auf produktiven System mit leistungsstarker Hardware. Da stellt sich die Frage, weshalb nicht Hardware verwendet wird, die etwas weniger Leistung aufbringt, aber dafür deutlich energiesparsamer ist. Die nachfolgende Arbeit wird diese Frage mit einem möglichst starken Kontrast beantworten, in dem Cluster entwickelt wird, der auf ARM-Computern und einem BigData-Framework basiert. 1.2 Produktwahl Um Daten durch Stream-Processing im BigData-Stil zu verarbeiten, werden derzeit zwei Frameworks groß gehandelt 2 : Apache Spark mit der Library Spark Streaming und Apache Storm. Beide Projekte werden von der Apache Foundation unterstützt und weiterentwickelt. Beide Frameworks haben völlig unterschiedliche Hintergrundgeschichten. Storm bekam durch die Entwicklung und Nutzung bei Twitter großen Zuspruch, sodass es in das Portfolio der Apache Foundation aufgenommen und dort weiterentwickelt wurde. Spark war ehemals eine performantere Version von Hadoop, bis es ein eigenständiges Projekt wurde. Die Community um das Projekt wuchs und bereicherte Spark um einige Erweiterungen, darunter auch das Spark Streaming. Dadurch unterstützt Spark nicht nur Batch-Processing, das es von seinem Vorgänger Hadoop übernommen hat, sondern nun auch das Stream-Processing. Storm und Spark unterscheiden sich stark in verschiedenen technischen Aspekten, im folgenden eine Auflistung die Unterschiede der beiden Frameworks 3 : 2 spark-and-storm-for-real-time-computation.html 3 spark-and-storm-for-real-time-computation.html und /05/14/storm-vs-spark/ 2

8 1 Spark mal in klein [5] Spark Streaming Storm Verarbeitung nach Map-Reduce- Verarbeitung durch Quelle (Spout), Knoten (Bolt) Paradigma und Senke (letzter Bold) Latenz durch Batch-Intervall und Verarbeitung Latenz durch Warteschlange und Verarbeitung 625 Contributors Contributors 5 Ein Record wird höchstens einmal verarbeitet Ein Record wird mindestens einmal verarbeitet Implementiert in Scala Implementiert in Clojure Framework kann in Scala, Java oder Python verwendet werden Framework kann in einer beliebigen Sprache verwendet werden Skaliert mit der aufkommenden Last Skaliert nach einer Metrik auf vorhandenen auf vorhandene Hardware-Ressourcen Hardware-Ressourcen Wie dargestellt gibt es Kompromisse, die man eingehen muss, wenn man eins der Frameworks für sein System wählt. Da Apache Storm zum Zeitpunkt dieser Arbeit noch keine Produktiv-Version veröffentlicht hat die Major-Versionsnummer ist 0 und steht gemäß dem Semantic Versioning 6 für die initiale Entwicklungsphase wird in dieser Arbeit das Framework Apache Spark verwendet. 1.3 Gliederung der Arbeit In Kapitel 2 werden dem fachfremden Leser einige der grundlegenden Begriffe erläutert. Dies ist nötig, da es in den nachfolgenden Kapiteln sehr Spark-spezifisch wird und an der Stelle ein technisches Verständnis zu schaffen. Das Kapitel 3 beschäftigt sich mit der Erstellung eines fiktiven Systems und dessen Anforderungen. Der Kontext des zu entwicklenden Systems wird klar definiert und die verwendete Hardware wird dokumentiert. Weiter wird die Architektur der Implementierung schrittweise anhand der gestellten Anforderungen erarbeitet. In Kapitel 4 wird dargestellt mit welchen Algorithmen in dem System gearbeitet wird. Dadurch wird nachvollziehbar gemacht wie der Cluster belastet wird und auf welche Belastung sich die Ergebnisse dieser Arbeit beziehen

9 1 Spark mal in klein [5] Das Monitoring der Hardware sowie während der Verarbeitung im Cluster ist in Kapitel 5 zu finden. Dort werden einige Szenarien miteinander verglichen und die gestellte Hypothese dieser Arbeit mit den gemessenen Werten und einem Vergleich zu einem Server-System beantwortet. Abschließend fasst Kapitel 6 diese Arbeit zusammen und stellt die Forschungsfragen, die sich während der Erarbeitung ergeben haben, in einem Ausblick zusammen. 4

10 2 Grundlagen[20] 2.1 Apache Spark Der Vorgänger Apache Hadoop gilt als der Pionier in der Map-Reduce-Szene. Die Verarbeitungsfunktionen können beliebig komplex entworfen werden, die Verarbeitung skaliert performant mit der Anzahl der vorhandenen Slaves und es kann im laufenden Betrieb ohne Fehlfunktion gewartet werden. Das alles gilt auch für Apache Spark mit einem kleinen Unterschied: Es kann nach Apache- Foundation (2015e) ca. 100 mal schneller als Hadoop die Daten verarbeiten und unterstützt iteratives Ausführen von Jobs. Der Performance-Gewinn kommt vor allem daher, dass die zu verarbeitenden Daten im Arbeitsspeicher statt im HDFS gehalten werden. Außerdem unterstützt Spark Pseudo-Stream-Processing, dazu mehr in Kapitel 2.3. Aufgrund dieses Vorteils und der Zukunftssicherheit der Software, bietet Spark für diese Arbeit Apache Spark ein stabiles BigData-Verarbeitungssystem. Spark-Programme lassen sich nativ in drei verschiedenen Programmiersprachen schreiben Java, Scala und Python. Die Programme können beliebig komplex sein, und es kann jede Code- Abhängigkeit mit an den Cluster übergeben werden. Man hat also bei der Implementation keine Einschränkungen, außer dass die Verarbeitung dem Map-Reduce-Schema folgt es ist sogar so, dass die Spark API den Code um einige Möglichkeiten erweitert. Was bei der Entwicklung mit Spark zu beachten ist, wird im Folgenden näher erläutert Architektur Grundsätzlich basiert Spark auch auf einer klassischen Master-Slave-Architektur. Der Master hält die Informationen über die verfügbaren Slaves, führt das Driver-Programm (s ) aus und gibt den Slaves die Aufträge. Die Slaves führen nur die Aufträge des Masters aus. Definition 1 (Master) Ein Master-Node ist der Verwalter der zu ihm gehörenden Slaves. Er bietet Clients im Rahmen seiner Fachlichkeit Dienste an, deren Durchführung er meist an seine Slaves weiterdelegiert. Damit führt er eine Art Lastverteilung durch, ohne dass der Client alle vorhandenen Slaves kennt. 5

11 2 Grundlagen[20] Definition 2 (Slave) Ein Slave-Node bietet seinem Master seine Dienste an, und wartet auf einen Auftrag von diesem. Dabei kann er, je nach Anforderung, einen oder mehrere Master haben. Die Ressourcenverwaltung wird bei Spark standardmäßig man kann auch Apache Mesos 1 verwenden von Apache YARN (ausgeschrieben heißt es "Yet Another Ressource Negatiator") übernommen. YARN besteht auch aus einer Master-Slave-Architektur. Der Master hält die Informationen über die vorhandenen Ressourcen aller angebundenen Slaves. Jeder Slave meldet seinem Master, welche Ressourcen (Anzahl CPU-Cores, Arbeitsspeicher-Kapazität, Festplattenkapazität und vorhandene Netzwerkanbindung) zur Verfügung stehen. Wie eine YARN-Architektur aussehen kann, ist in Abbildung 2.1 zu sehen. Sobald sich ein Client am YARN-Master meldet und eine Applikation (bspw. Hadoop oder Spark) registriert, erstellt der YARN-Master auf einem seiner Slaves einen sog. Application-Master. Angenommen, es wurde ein Application-Master für Spark erstellt, dann werden alle am YARN-Master ankommenden Spark-Aufträge an den Spark-Application-Master weitergeleitet. Der Spark- Application-Master meldet daraufhin am YARN-Master einen Ressourcen-Bedarf an. Falls freie Ressourcen vorhanden sind, erhält der Spark-Application-Master die Erlaubnis und die Information welche Slave-Nodes er mit seinem Job belegen darf. Dazu wird auf den jeweiligen Slave-Nodes ein Container angelegt, in dem die erteilten Tasks ausgeführt werden. Abbildung 2.1: Beispiel-Architektur eines YARN-Clusters von Apache-Foundation (2015g) 1 Apache-Foundation (2015a) 6

12 2 Grundlagen[20] Wann immer im Folgenden die Rede von einem Spark-Master ist, ist immer der Spark- Application-Master im YARN-Cluster gemeint Das Driver-Programm Das Driver-Programm (im Folgenden auch Driver genannt) kann man sich vorstellen wie die main-funktion in Java. Es wird auf dem Master ausgeführt und stellt den "Mittelpunkt"der ganzen Applikation dar. Dort werden die Input-Daten bestimmt (werden die Daten beispielsweise von einem TCP-Port geliefert oder von einem HDFS gelesen?), die Verarbeitung der Daten durch Transformations und Actions, und den Output der Daten (werden die Daten zum Beispiel an eine Datenbank übergeben oder in ein HDFS geschrieben?). Sobald der Driver das Ende der Bearbeitung erreicht hat, ist auch den Spark-Job vorbei, und die belegten Slave-Nodes werden freigegeben RDD Daten im Cluster Daten, die durch Slaves verarbeitet werden sollen, müssen durch das Driver-Programm als sogenannte Resilient Distributed Datasets (RDD) im Cluster deklariert werden. Ein RDD kann man sich grob vorstellen wie eine über mehrere Rechner verteilte unveränderbare Collection, deren einzelne Elemente man verarbeiten kann (s ), dabei erhält jeder am Job beteiligte Slave nur einen Bruchteil des RDD. Dieser Bruchteil wird als Partition bezeichnet. Jedem Node kann eine oder mehrere Partitionen eines RDD zugewiesen werden. Die RDDs sind das besondere Alleinstellungsmerkmal von Spark. Es sorgt dafür, dass die Daten verteilt durch die Slaves verarbeitet werden können Transformations und Actions Auf den RDDs lassen sich zwei verschiedene Arten von Operationen durchführen: Transformation Operation an einem RDD, die auf den Slaves ausgeführt wird, wird Transformation genannt. Hier verarbeitet jeder Slave seinen Teil des RDD durch einen im Code bestimmten Algorithmus. Eine Transformation gibt selbst wieder ein RDD an den Driver zurück, der durch eine weitere Transformation oder eine Action weiterverarbeitet werden kann. Transformations werden vor allem dazu genutzt, um Daten umzustrukturieren. Zum Beispiel von einer Liste zu Key-Value-Pairs oder dem Herausfiltern von Daten nach bestimmten Kriterien. 7

13 2 Grundlagen[20] Action Ähnlich wie eine Transformation wird auch eine Action auf einem RDD von den Slaves durchgeführt, die Operation ist vor Beginn der Laufzeit im Driver bestimmt worden. Actions werden dazu genutzt um einen Ergebnis bzw. einen Output aus den Eingabedaten zu generieren. Jede Transformation und Action auf einem RDD wird im Directed-Acyclic-Graph Scheduler (DAG) registriert. Er generiert systemintern einen Graphen, wobei ein Knoten einem RDD und die Kanten dazwischen einer Transformation oder Action entspricht. Der DAG sorgt unter anderem dafür, dass eine Transformation nur ausgewertet wird, wenn es sich auf dem Weg von der Wurzel zu einem Blatt befindet. Ein Blatt des Graphen muss immer eine Action sein. Transformations werden lazy ausgewertet. Das bedeutet, alle Transformations an einem RDD werden erst ausgeführt, wenn eine Action das Ergebnis der vorherigen Transformations zur weiteren Verarbeitung benötigt. Das bedeutet im Umkehrschluss, dass der Driver erst nach einer erfolgten Action verwendbare Daten aus einem RDD erhält. Ein Spark-Programm lässt sich in Stages einteilen. Eine Stage ist eine Ansammlung von Transformations und der abschließenden Action. Für jede auszuführende Stage und RDD-Partition wird eine Task an jeden der Slaves geschickt, der eine Partition des RDDs hat. Dazu ein Beispiel aus Karau u. a. (2015): 1 // Begin Stage 1 2 scala> val input = sc.textfile("input.txt") 3 scala> val temp = input.map(line => line.split(" ")) 4 scala> val tokenized = temp.take(0) 5 // End Stage 1 6 // Begin Stage 2 7 scala> val pre_counts = tokenized.map(words => (words(0), 1)). 8 scala> val counts = pre_counts.reducebykey{ (a, b) => a + b } 9 scala> val result = counts.collect() 10 // End Stage 2 Listing 2.1: Code-Beispiel zum Staging, s. Karau u. a. (2015) Das Diagramm 2.2 zeigt den DAG-Graph des Beispiel-Codes 2.1. In dem Graphen sind die Knoten jeweils die RDDs und die Kanten dazwischen sind jeweilis die Transformation oder Action durch die sie erzeugt werden. Aus dem Diagramm lässt sich ablesen, dass die Transformations in Zeile 2 und 3 erst mit der Action in Zeile 4 durchgeführt wird. Anschließend wird das erzeugte RDD tokenized weiterverarbeitet. Die Stage 2 ist nicht komplett im Diagramm 8

14 2 Grundlagen[20] Abbildung 2.2: Staging des Beispiel-Codes, s. Karau u. a. (2015) abgebildet, der Code zeigt aber, dass auch sie mit einer Action in Zeile 9 abschließt, die Stage würde also auch ausgeführt werden. Angenommen Slave A hat X Partitionen des input-rdd, dann erhält er in diesem Beispiel für die Stage 1 X Tasks vom Master. Eine Aufzählung der verwendbaren Transformations und Actions ist unter Apache-Foundation (2015d) einzusehen. Unter den Transformations gibt es einige, die verhältnismäßig teuer sind mit Blick auf die Verarbeitungszeit, die sie benötigen. Dazu gehört auch die Operation groupbykey() (s. Databricks (2014)), mit der Methode lassen sich Records anhand ihres Keys zu einer Collection zusammenfassen. Das ist sehr praktisch, wenn man die Daten ordnen möchte, um sie dann per foreach() an ein externes System zu senden. In der Abbildung 2.3 ist der Ablauf der groupbykey()-methode dargestellt. Die drei oberen blauen Kästen sind Slaves, die eine oder mehrere Partitionen eines RDD halten. In den Kästen sind die Key-Value-Pairs enthalten, die zum RDD gehören. Durch die groupbykey()-operation werden nun die Tupel je nach Key an einen anderen Node gesendet. So sind nun wenn der Speicher des Slaves ausreicht alle Tupel eines Keys auf einem Slave gesammelt. Da hier je nach Datenaufkommen ein hoher Netzwerk-Verkehr auftreten kann, sollte diese Methode nach Möglichkeit gemieden werden. 9

15 2 Grundlagen[20] Abbildung 2.3: Vorgehen der groupbykey()-transformation Zusammengefasster Ablauf Um nochmal zu verdeutlichen, wie der lineare Ablauf eines Spark-Programms aussieht, soll folgende Auflistung unterstützen (vgl. Karau u. a. (2015)): 1. Übertragung des kompilierten Java-, Scala- oder Python-Programms mit allen Abhängigkeiten an den Master 2. Master führt den Code lokal aus ( Driver-Programm) 3. Falls im Driver eine Transformation ausgeführt werden soll, wird ein RDD angelegt mit den Meta-Informationen, was die Transformation als Ergebnis haben soll 4. Sobald im Driver eine Action auf ein RDD ausgeführt werden soll, wird das RDD im Cluster bekannt gemacht und die Operation wird durchgeführt 5. Wenn das Ende des Drivers erreicht ist, werden die Slaves freigegeben und der Master wartet auf den nächsten Job 10

16 2 Grundlagen[20] Spark Streaming Der Streaming-Teil von Spark ähnelt sehr stark der bereits gezeigten Batch-Verarbeitung. Denn es sind alle bekannten Spark-Mechanismen vorhanden und verwendbar. Es gibt Transformations, Actions, RDDs und es wird verteilt gearbeitet. Mit dem Unterschied, dass nicht hauptsächlich auf RDDs gearbeitet wird, sondern auf sogenannten Discretized Streams (kurz: DStreams). Diese ähneln sehr stark den bereits bekannten RDDs. Sie werden verteilt gespeichert, verteilt verarbeitet und sie lassen sich genauso im Code verwenden wie ein RDD. Intern besteht ein DStream nur aus temporären RDDs. Was man dabei beachten muss: der DStream beinhaltet nur den derzeitigen Micro-Batch. Ein Micro-Batch beinhaltet alle Daten die innerhalb einer konfigurierbar kurzen Zeitspanne dem Spark-System bekannt geworden ist, man arbeitet also zu keinem Zeitpunkt auf allen Daten. Bei der Implementierung muss darauf geachtet werden, dass die Verarbeitung der Daten nicht die Micro-Batch-Zeitspanne überschreitet, ansonsten stauen sich mehr und mehr Streaming-Daten an, dem das konstruierte Spark-System nicht gerecht werden kann. In der Praxis hat sich eine untere Zeitspanne von 0,5s bewährt, was etwa dem Spark-Overhead zur Initialisierung eines neuen Batches entspricht (s.karau u. a. (2015)). This gives us also the main performance guideline for Spark Streaming: The time to process the data of a batch interval must be less than the batch interval time. - Gerard Maas, virdata Fluss der Daten Wie Abbildung 2.4 gezeigt, wird jeder erhaltene Micro-Batch erst im nächsten Batch-Intervall verarbeitet. So wird der Micro-Batch der zum Zeitpunkt 0 ankommt erst zum Zeitpunkt 1 verarbeitet, und der Micro-Batch der zum Zeitpunkt 1 ankommt, wird zum Zeitpunkt 2 verarbeitet. Damit hat man innerhalb eines Batches eine endliche Datenmenge auf die der Code angewandt wird. Abbildung 2.4: Verarbeitungsreihenfolge der Micro-Batches, s. Apache-Foundation (2015f) 11

17 2 Grundlagen[20] Für jeden vorhandenen InputStream wird ein Spark-Slave reserviert, der sich ausschließlich um den Erhalt der Daten kümmert. Durch mehrere InputStreams lässt sich die parallele Verarbeitung im Rest des System steigern. Vom InputStream bzw. einem DStream werden die verarbeiteten Daten an den nächsten DStream weitergeleitet, ähnlich wie bei den RDDs. In Abbildung 2.5 ist zu sehen wie die Ergebnisse vom lines.flatmap()-aufruf an den DStream words weitergeleitet wird, um dort weiterverarbeitet zu werden. Abbildung 2.5: Weiterleitung an den nächsten DStream, s. Apache-Foundation (2015f) Windows über DStreams Es gibt eine Möglichkeit auf einige bisherige Micro-Batches zuzugreifen. Dabei kann man nicht auf einen spezifischen Batch zugreifen, sondern auf ein sogenanntes Window. Damit erhält man eine beliebige Anzahl der letzten Batches. Die Bedingung dabei ist, dass die Hardware den nötigen Speicher hat um die gesammelten Batches solange vorzuhalten. Ein Window lässt sich durch einige bestimmte Operationen verarbeiten (s. Apache-Foundation (2015f)). Die grünen Kästchen in Abbildung 2.6 stellen die einzelnen Micro-Batches dar, die zu den jeweiligen Zeitpunkten erhalten wurden. In diesem Beispiel wurden die letzten 3 Batches zu einem Window zusammengefasst, welches alle 2 Batches verarbeitet wird Monitoring von Spark-Anwendungen Mit dieser Komponente können einige Messwerte bei der Verarbeitung der Jobs überwacht werden. Bspw. Laufzeit eines Jobs, Anzahl der am Job beteiligten Slaves, welche Ressourcen der Slaves bei dem Job wie belegt waren, Messwerte aus der JVM, etc. 12

18 2 Grundlagen[20] Abbildung 2.6: Sammeln von Micro-Batches zu einem Window, s. Apache-Foundation (2015f) Sobald der Spark-Master gestartet ist, stellt er ein Web-Interface bereit auf dem er detailliert Auskunft gibt über sich, seine Slaves und den Verarbeitungsstand des erteilten Spark-Jobs. Es ist außerdem die Ausgabe an folgende Senken konfigurierbar: einfache Konsolenausgabe in eine CSV-Datei an eine JMX-Konsole in eine Graphite Datenbank an ein sl4j-log Man kann allerdings auch beliebige Senken dazu implementieren. Diese Komponente wird diese Arbeit bei der Aussage unterstützen, wie belastbar das System ist und wie es auf eine Lastveränderung reagiert Berkeley Data Analysis Stack Spark wurde ehemals an der UC Berkeley entwickelt. Die Gründer des Projekts führten die Entwicklung später als Suborganisation AMPLab weiterhin unter der Obhut der UC Berkeley fort. Von dort wurde Spark in das Portfolio der Apache Foundation übernommen und weiterentwickelt. Die Spark-Gründer haben die Firma Databricks gegründet und treiben von dort die Entwicklung des Frameworks maßgeblich voran. AMPLab hat in dem Zusammenhang den sogenannten Berkeley Data Analysis Stack (BDAS) 2 definiert. Der BDAS besteht aus mehreren Schichten die jeweils einen Bereich des Datenanalyse

19 2 Grundlagen[20] Stacks abdecken. Der Kern des Stacks ist Spark, das selbst auf einigen Frameworks aufbaut und als Grundlage für darüber liegende Frameworks dient. Abbildung 2.7: Berkeley Data Analysis Stack, s.ampley (2015) In Diagramm 2.7 ist der Stack mit seinen fünf Layern und Frameworks dargestellt. Der Layer 1 dient als Abstraktion der Hardware-Ressourcen. Dort sind Tools wie Mesos, YARN oder Nimbus angesiedelt. Je nach Framework ist das Protokoll der Ressourcenbereitstellung etwas anders, aber grob ist es immer der folgende Ablauf: Eins der höheren Layer braucht Hardware-Ressourcen um seinen Dienst zu erfüllen und das Layer 1 vergibt Ressourcen falls noch welche verfügbar sind. Dadurch wird eine flexible und optimale Nutzung der vorhandenen Hardware erreicht. Im Layer 2 befinden sich Technologien, die den höheren Layern eine Daten-Persistenz anbieten für In- und Outputdaten. Spark bietet integrierte Unterstützung für HDFS. Je nach Design und Ansprüchen der höheren Schicht, könnten auch andere Technologien, wie beispielsweise das In-Memory Dateisystem Tachyon 3 interessant sein. Der Spark-Core selbst befindet sich in Layer 3. Es verwendet und kapselt die Dienste aus den ersten beiden Layern und bietet den höheren Schichten ein abstraktes Framework zur Verarbeitung der vorhandenen Daten. Es wurden einige Frameworks um den Spark-Core entwickelt, die in Layer 4 aufgeführt sind. Sie alle kapseln die Spark-Funktionalitäten und bieten sie dem Entwickler in unterschiedlich abstrahierter Weise wieder an. Spark Streaming ermöglicht Stream-Processing mit Spark, 3 Li u. a. (2014) 14

20 2 Grundlagen[20] SparkSQL bietet Zugriff und Verarbeitung von Daten mit SQL-ähnlichen Statements an, SparkR ermöglicht das Implementieren von Spark-Programmen in der Sprache R, GraphX ist ein Framework um Graphen effizienter durch Spark verarbeiten zu lassen und MLib erweitert den Spark-Core um Machine-Learning Funktionalitäten, um nur ein paar der Frameworks zu nennen. Letztendlich gibt es noch die konkrete Anwendung der Spark-Funktionalitäten in Layer 5. In der Abbildung sind einige Anwendungen von AMPLab genannt. Dort würde man auch das System ansiedeln, das in dieser Arbeit entwickelt wird. 2.2 Map-Reduce Verarbeitungsprinzip Diese Art der Verarbeitung wurde durch das bereits erwähnt Apache Hadoop populär. Auch sein Quasi-Nachfolger Spark verwendet das Map-Reduce-Verarbeitungsschema, was den Wechsel vom einen Framework zum anderen vereinfacht. Das besondere Merkmal von MapReduce ist, dass sich die Verarbeitung der Daten in zwei Phasen einteilen lässt. Das ist die Map-Phase und die Reduce-Phase, wobei das Map immer vor dem Reduce erfolgt. Für diese beiden Phase werden jeweils Funktionen angeben, die dann auf die erhaltenen Daten angewandt werden. Je nach Quelle gibt es noch andere Phasen, die vor der Map-Phase, zwischen Map und Reduce, oder nach der Reduce-Phase erfolgen. Hier wird nur das vereinfachte Grundkonzept dieser Verarbeitungsart erläutert. In der Map-Phase werden nach Miner und Shook (2012) die Input-Daten für die folgende Reduce-Phase strukturiert. Hier werden die Daten für die Reduce-Phase aufbereitet. Üblicherweise wird der Input in Key-Value-Pairs umgewandelt und in die nächste Phase übergeben. In der Reduce-Phase werden die vorher strukturierten Daten reduziert bzw. zusammengeführt. Dies kann man sich vorstellen wie einen Trichter, bei dem man oben die strukturierten Daten vom Map bekommt und unten vom Trichter kommt das erhaltene Ergebnis raus. In dieser Phase liegt üblicherweise die eigentliche Kernlogik der Anwendung (s.miner und Shook (2012)). In Abbildung 2.8 ist eine Beispiel MapReduce-Anwendung zu sehen. In diesem Fall ist es eine Wordcount-Anwendung, es sollen die Wörter eines Eingabe-Texts gezählt werden. Die einzelnen Spalten stehen für jeweils eine Phase der Verarbeitung, der Name der Phase steht im Kopf der Spalte. Die Verarbeitung beginnt mit dem Input, was beispielsweise ein Buch ist mit seinen einzelnen Sätzen. Danach wird im Splitting der Input in Sätze aufgeteilt und an jeweils einen Node 15

21 2 Grundlagen[20] Abbildung 2.8: MapReduce-Beispiel: Wordcount (s. AlexHanna) weitergeleitet. Mapping erhält die einzelnen Zeilen und wandelt die Wörter des Satzes jeweils in Key-Value-Pairs um, wobei der Key das Wort ist und der Value immer mit "1"belegt wird. Der Mapping-Output geht an Shuffling, das die Key-Value-Pairs nach den Keys sortiert an Nodes übergibt. Das Reducing führt nun die einzelnen Key-Value-Pairs zusammen, wobei die Values eines Keys aufsummiert werden. Abschließend wird der Output im Final Result beispielsweise über die Konsole ausgegeben. In diesem Beispiel liegt die Geschäftslogik in der Reduce-Phase, denn dort werden die einzelnen Wörter zusammengezählt. Alle anderen Schritte dienen lediglich der Vorbereitung bzw. Optimierung des Prozesses. Der Vorteil dieser Verarbeitungsparadigmas liegt in der Skalierung mit mehreren Nodes. Denn die Map- und Reduce-Funktion wurden im vornherein definiert und können durch unterschiedliche Nodes parallel ausgeführt werden (s. Miner und Shook (2012)). Daher skaliert die Verarbeitungsdauer mit der Anzahl der Nodes, die daran beteiligt sind. 2.3 Verarbeitungsansatz von Spark Streaming Das Stream Processing ist ein daten-orientierter Verarbeitungsansatz, der im Rahmen dieser Arbeit verwendet wird, um der Menge der ankommenden Daten bei möglichst kurzer Antwortzeit gerecht zu werden. 16

22 2 Grundlagen[20] Im Vergleich dazu wird das Batch Processing vorgestellt, um den Unterschied zum tream Processing aufzuzeigen. Außerdem lässt sich damit erklären, weshalb Spark nur eine Art Pseudo Stream Processing unterstützt Stream Processing Es gibt in der Literatur keine eindeutige Definition von Stream Processing. Viele davon ziehen den Vergleich zum Batch Processing. Eine Definition 4 fässt den Begriff in klare Schranken: In stream processing, you do not collect your data to reach certain quorum or timeout before you trigger your process. As soon as the data event is received, the program processes it, and creates the output. It?s event processing. - Chetan Narsude In der heutigen Zeit von BigData-Anforderungen hat diese Art der Verarbeitung nach Götz (2013) den Vorteil, dass es die Eingabedaten nicht komplett im Speicher halten muss, sondern immer nur einen Bruchteil davon Batch Processing Die einfachste Form der Verarbeitung ist die funktions-orientierte Stapelverarbeitung. Dabei wird eine Liste von Operationen auf eine vorher festgelegte Menge an Daten angewandt. Vorteile nach Qian (2010): Einfaches Konzept Kurze Entwicklungszeit (Ïch brauche mal eben schnell... ) Nachteile nach Qian (2010): Braucht ein externes System um mehrfach nacheinander Daten zu verarbeiten Wird in Zeitabständen aufgerufen -> Latenz! Ein Beispiel dafür ist ein Shell-Skript, das aufgerufen wird. Oder ein Hadoop-Job der gestartet wird. Was dabei auffällt ist, dass bei dieser Art der Verarbeitung immer der Aufruf von einer externen Komponente gestartet werden muss. Das Shell-Skript muss vom Benutzer oder von Cron zeitgesteuert gestartet werden, dasselbe gilt für den Hadoop-Job. Sobald das Skript seine letzte Operation ausgeführt hat, terminiert es. Wenn es nach der Terminierung nochmal etwas tun soll, muss es erneut von außen gestartet werden

23 2 Grundlagen[20] Micro-Batch Processing Spark unterstützt kein echtes Stream Processing, sondern dass sogenannte Micro-Batch- Processing. Es sammelt für eine konfigurierbare kurze Zeitspanne meist im Sekundenbereich Input-Daten und verarbeitet diese als Micro-Batch-Job. Die dabei anfallende Datenmenge soll so klein sein, dass die Verarbeitungszeit im Sekundenbereich bleibt. Der Vorteil dabei ist, dass die Output-Daten schnell verfügbar sind und die Hardware-Ressourcen wieder frei sind für den nächsten Job. Diese Methode wird laut Karau u. a. (2015) Micro Batch Processing genannt, da die Input-Daten verhältnismäßig klein sind zu den üblichen Hadoop-Jobs (vgl. Shahrivari (2014)) Batch vs. Stream Der wesentliche Unterschied zwischen Batch-orientierter Verarbeitung und dem Verarbeiten eines Datenflusses liegt darin, woher die Input-Daten kommen. Beim Batch orientated Programming liegen die Input-Daten vor Beginn des Jobs vollständig meist auf der HDD vor und werden vollständig durch den Batch-Job verarbeitet. Der de facto Standard Apache Hadoop bietet dafür ein sehr gutes Beispiel: Alle Daten die durch einen Hadoop-Job verarbeitet werden sollen, liegen vor Verarbeitungsbeginn vollständig im HDFS oder einem anderen Dateisystem vor. Man kann bei diesem Verfahren immer davon ausgehen, auf einer endlichen Datenmenge zu arbeiten. Das Stream Processing arbeitet anders: Die zu verarbeitenden Daten liegen nicht vollständig dem System vor, sondern werden dem System nach und nach bekannt, beispielsweise durch eine Socket-Verbindung, die Daten von außen erhält. Sobald Input-Daten vorhanden sind, werden diese verarbeitet. Dabei werden die Daten üblicherweise nicht auf das Dateisystem geschrieben, sondern werden für die Verarbeitung im Arbeitsspeicher bereitgehalten. 18

24 3 Architektur des Clusters[10] Im Folgenden wird die Konfiguration und der Aufbau des Clusters beschrieben, damit nachvollziehbar ist, unter welchen Bedingungen in dieser Arbeit geforscht wurde. Es wird beschrieben, welche Rechenleistung die Hardware zur Verfügung stellt, wie die einzelnen Nodes im Netzwerk miteinander kommunizieren, wie die Software in Komponenten strukturiert wurde und wie die Spark-eigenen Parameter konfiguriert sind. 3.1 Zielsetzung Ziel ist es ein System zu entwickeln, das die gestellte These dieser Arbeit beantworten kann. Dazu ist es notwendig, dass Hardware aus dem Low-Performance-Bereich verwendet wird und dass auf dieser Hardware das Framework Apache Spark lauffähig ist. Die zu entwickelnde Architektur muss der Hardware die Möglichkeit geben, seine volle Leistung erbringen zu können. Der definierte Anforderungskatalog muss Anforderungen enthalten, die an ein mögliches Echt-System gestellt werden könnten. 3.2 Hardware Um die Datenverarbeitung möglichst parallel zu gestalten, sollen mehrere Slave-Nodes in dem Cluster verfügbar sein. Damit der finanzielle Rahmen dieser Arbeit eingehalten wird, darf der einzelne Node nicht zu viel kosten und muss dennoch für den Kaufpreis viel Rechenleistung bringen. Ein guter Kompromiss stellen derzeit ARM-Computer dar, die in den letzten Jahren vermehrt für günstige Heimprojekte genutzt werden. Es gibt derzeit einige Hersteller und Gruppierungen, die solche Boards anbieten. Da man sich die Option offen halten möchte, später die Hardware durch aktuelle Geräte zu ersetzen, muss auf die Portierbarkeit der Software (mit Blick auf das Unix-Betriebssystem, die Treiber, die Prozessorarchitektur der Hardware,...) auf die Folgehardware geachtet werden. Besonders tut sich da die Raspberry Pi Foundation mit ihren gleichnamigen energiesparsamen Computern 19

25 3 Architektur des Clusters[10] hervor. Hinter dem Rechner steht nicht nur die Foundation selbst, sondern auch eine breite Entwickler-Gemeinschaft die mit hohem Engagement für eine Kompatibilität mit jeder üblichen Unix-Software sorgt. Unter anderem wurde dafür gearbeitet, dass das installierte System von einem RaspberryPi 1 durch ein Update problemlos auf dem Nachfolgemodell weiter verwendet werden konnte. Wegen dieser breiten öffentlichen Unterstützung und Kompatibilität zur Nachfolgehardware, wird in dieser Arbeit der RaspberryPi 2 als Hardwarebasis verwendet. Jeder der Nodes hat daher folgende Konfiguration 1 : 900 MHz Quadcore-CPU 1 GB RAM 100 MBit/s Ethernet (onboard) 1 Gbit/s Ethernet USB-Adapter 32GB Class 10 SD-Card Bei dem RaspberryPi muss beachtet werden, dass es nur einen Controller gibt, der für die USB- Operationen, das Netzwerk-Interface und alle Aktionen auf der MicroSD-Karte verantwortlich ist. Die Beanspruchung einer dieser Komponenten beeinflusst entsprechend die verbleibende Bandbreite für den Rest des Systems. 3.3 Netzwerk Da die Hardware nur ein Mbit-Interface anbietet, wird hier ein Mbit-Netzwerk verwendet. Das Netzwerk ist das Medium über das die Daten von der Datenquelle zum System und weiter zur Datensenke gelangen und der Master seine Slaves koordiniert. Mit dem Ziel, das Micro-Batching eng takten zu können, darf hier nur möglichst wenig Verzögerung durch die Datenübertragung entstehen. Bei der gewählten Hardware ist weniger die geringe Prozessortaktung der Flaschenhals, sondern maßgeblich für die Gesamtrechenleistung des Clusters ist die Netzwerkübertragungsgeschwindigkeit jedes einzelnen Nodes. Vor allem die des Master-Nodes, denn er muss die einzelnen Tasks an den jeweiligen Slave übertragen. Wie in Abbildung 3.1 gezeigt, erhält der Cluster Zugriff auf das Internet. Von dort erhält er die Input-Daten und hat außerdem die Möglichkeit die verarbeiteten Daten zu einem Server im Internet zu versenden. 1 Raspberry-Pi-Foundation (2015) 20

26 3 Architektur des Clusters[10] Abbildung 3.1: Netzwerk-Architektur des Clusters Die genaue Verteilung der einzelnen Dienste ist exemplarisch für 3 Slaves in Abbildung 3.2 gezeigt. Dort ist zu sehen, dass alle verwaltenden Dienste (YARN, park-master, DHCP und DNS) auf dem Master-Node laufen. Auf den Slaves läuft nur der YARN-Nodemanager und wenn erforderlich ein Spark-Slave. 3.4 Anforderungen an die Implementation Um der Implementation und der Konfiguration des Clusters einen Rahmen zu geben, wird im vornherein ein Pflichtenheft aufgestellt, an das sich das System zu halten hat. Dort ist klar festgelegt, welchem Zweck die Software dienen soll und welchen Anforderungen sie genügen muss. Es unterstützt damit bei der Beantwortung der gestellten Forschungsfrage und bildet die Basis für den Entwurf der Software-Architektur Anforderungskatalog Die Anforderungen dieses Katalogs werden mit einer eindeutigen Nummer versehen, um später auf sie referenzieren zu können. Wenn in einer Anforderung Das System geschrieben wird, ist damit die Implementation im Zusammenspiel mit der Hardware des Clusters gemeint. 21

27 3 Architektur des Clusters[10] Abbildung 3.2: Verteilungssicht des Clusters Wenn in einer Anforderung externes System geschrieben wird, ist damit ein vom Spark- Cluster unabhängiges System gemeint, beispielsweise ein Server im Internet oder ein Computer im lokalen Netzwerk. Wenn in einer Anforderung Die Software geschrieben wird, ist damit die Implementation des Drivers gemeint. Wenn in einer Anforderung anderer Entwickler geschrieben wird, ist damit ein Entwickler gemeint, der bislang nicht an der Entwicklung des Systems beteiligt war. 1. Funktionale Anforderungen a) Das System erwartet die Input-Daten wie sie in angegeben sind. b) Das System ermittelt die Informationen die in formuliert sind. 2. Nichtfunktionale Anforderungen a) Das System verarbeitet die Daten auf Basis von Apache Spark Streaming. b) Das System hat die Daten unverzüglich nach Erhalt verarbeitet und an den Output übergeben, spätestens jedoch nach 10 Sekunden. c) Das System kann mindestens Datensätze pro Stunde und Datensätze pro Minute verarbeiten. d) Das System bietet externen Systemen eine Schnittstelle an, über die das externe System Input-Daten an das System zur Verarbeitung übergeben kann. 22

28 3 Architektur des Clusters[10] e) Die Software ist in einer der nativen Spark-Programmiersprachen (Java,Scala oder Python) implementiert. f) Die Architektur der Software ist gemäß dem Paradigma Separation of Concern 2 modular aufgeteilt. g) Die Module der Software sind in technische und fachliche Kompetenzen unterteilt. h) Die Software ist so gestaltet, dass sie durch andere Entwickler leicht verstanden und modifiziert werden kann. i) Die Software ist dokumentiert und kommentiert, sodass andere Entwickler den Zweck des jeweiligen Codes nachvollziehen können Input Daten Bei den Input-Daten handelt es sich um erfasste Real-User-Monitoring (RUM)-Daten, die u.a. folgende Informationen enthalten: Eindeutige ID des Besuchers, die die Session über dieselbe bleibt Smoothed-Roundtrip-Time (SRTT) zum Zeitpunkt des Seitenaufrufs DocComplete-Zeit des Seitenaufrufs Time-To-First-Byte (TTFB) des Seitenaufrufs Vollständige URL des Seitenaufrufs und einige Messdaten mehr, die allerdings nicht für die Berechnung des Outputs relevant sind Die Messdaten werden dem System als URI 3 zur Verfügung gestellt. In Beispiel 3.1 ist einer der Messwerte beispielhaft gezeigt. In dieser Form hat das System den Input zu erwarten. 1 ""GET /static/all/img/latest/global-resources/beacons/rum.gif? parenturl=https%3a%2f%ftestseite.de%2ftechnik%2ffernseher%2 F&htmlLength=427798&numberStylesheets=7&timeToFirstByte=81& networktime=457&domcontentloadedstart=715&domcontentloaded= 729&domTime=647&complete=903&rum_complete=903&domComplete=7 2 Vogel u. a. (2008) 3 Network-Working-Group (1998) 23

29 3 Architektur des Clusters[10] 29&rum_domComplete=729&dnsTime=1&sslHandshakeTime=-1&vid=ef 90d4e6-4af3-4c7b-a5c7-040a222b1ba6.v1&bid=ce6f c-46 cc-b fd08210c4.v1&firstview=true&app=false&bp=xl& latencymeasurementtype=performanceapi&width=1280&height=102 4&clientWidth=991&clientHeight=673&innerWidth=1008& innerheight=673&rum_width=1280&rum_height=1024& rum_clientwidth=991&rum_clientheight=673&rum_innerwidth=100 8&rum_innerHeight=673&devicePixelRatio=1& rum_devicepixelratio=1&devicetype=desktop&deviceos=windows% 207&deviceBrowser=Firefox&deviceOrientation=landscape& supportstouch=false&rum_deviceorientation=landscape& rum_supportstouch=false&connection=-2&rum_connectiontype=-2 &psfids=07ce23f742bea18a4f0d75657bc995ea &scid= &cachefix=sqcE2QFPkA6&ts_Type=merge&srtt=190&rttv=5 65&ttfcs=7951&ttfcc=6990&ttfcm=-1&clickObject=ANaNBHs&avi= false&ava=false&macvx=false&rum_avi=false&rum_ava=false& rum_macvx=false&latency=318&rum_latency=318 HTTP/1.1"" Listing 3.1: Beispiel-Datum ungeparster RUM-Messwert Das aufgeführte Attribut vid ist die Visitor- oder auch Session-ID, die es ermöglicht, den Aufruf-Verlauf eines Users nachzuvollziehen. So lässt sich beispielsweise bestimmen, ob ein User eine Bestellung getätigt hat und wie oft er vorher welche Artikel sich angesehen hat. Die Reihenfolge der Aufrufe lässt sich anhand der mitgelieferten Timestamps bestimmen. Die restlichen auslesbaren Werte sind mit ausreichend sprechenden Namen identifizierbar. Für den Zweck dieser Arbeit wurden von einem Kunden ein Online-Shop Betreiber der Iteratec GmbH, der nicht namentlich genannt werden möchte, einige Terabyte RUM-Daten zur Verfügung gestellt. Diese Daten werden dem Spark-Cluster zur Verarbeitung zu geführt Output Daten Das Ergebnis der Berechnung soll folgende Information aus den Input-Daten extrahieren: Output-1. Es soll die nächste zu erwartende SRTT eines Webseiten-Besuchers ermittelt werden. Die Berechnung des Werts soll für alle Besucher zunächst einheitlich nach folgender Formel geschehen: (letztersrt T + jetzigersrt T )/2 = erwartetersrt T 24

30 3 Architektur des Clusters[10] 3.5 Software-Architektur Anhand der in Abschnitt 3.4 gestellten Anforderungen, wird nun schrittweise die Architektur und dessen Implementation entwickelt Kontext des Systems Abbildung 3.3 zeigt in welchem Kontext sich das zu entwickelnde System befindet. Der blaue Kasten in der Mitte ist der Spark-Cluster, den diese Arbeit konstruiert. Links davon ist ein System in der Cloud oder auch im lokalen Netzwerk das dem Cluster die Input-Daten liefert. Die Wolke auf der rechten Seite ist ebenso ein System, das über Ethernet erreichbar ist. Dorthin werden die errechneten Daten als Output übergeben. In diesem Fall wird der Output an eine MongoDB-Instanz übergeben. Um das System während der Verarbeitung zu überwachen, sendet der Cluster zur Laufzeit interne Überwachungsdaten an den Monitoring-Server (vgl. Abbildung 3.3 unten rechts). Diese Daten werden hilfreich sein bei der Feststellung, ob der Cluster die Input-Daten schnell genug verarbeitet oder ob das System nicht dem ankommenden Stream gerecht wird. Abbildung 3.3: Kontext des Clusters zu Nachbarsystemen Die interne Netzwerkstruktur des Clusters ist im vorherigen Kapitel 3.3 beschrieben Komponentendiagramm der Software Wie in Diagramm 3.4 zu sehen ist, wurde die Implementation in Komponenten aufgeteilt. Diese werden durch Interfaces miteinander verbunden, so kann bspw. der Daten-Input beliebig 25

31 3 Architektur des Clusters[10] verändert werden es muss lediglich das Interface InputManager in einer Klasse neu implementiert werden. Der Vorteil dieser Architektur ist, dass der Überblick über das Projekt im Driver erhalten bleibt und jede Komponente nur über seine eigene Kompetenz verfügt. Damit wird die Anforderung 2f erfüllt. Abbildung 3.4: Komponentendiagramm der Implementation Die Anforderung 2g erwartet außerdem, dass diese Module nun nach technischer und fachlicher Kompetenz untergliedert wird. Das vorherige Komponentendiagramm 3.4 wird nun also noch etwas angepasst, sodass die Architektur wie sie Abbildung 3.5 zeigt, den Anforderungen genügt. Im Folgenden werden die einzelnen Software-Komponenten näher erklärt: DataInput Diese Komponente sorgt dafür, dass Spark Daten zum Verarbeiten erhält. Wie in Kapitel 2.1 erwähnt, erwartet Spark in einem InputStream ankommende Daten. In dieser Implementation werden KafkaInputStreams verwendet und führt diese per join()-aufruf zusammen, sodass sie während der Entwicklung als ein DStream verwendbar sind. DataOutput Sobald die Verarbeitung beendet ist, werden die Output-Daten an das Interface PersistentDatastorage übergeben. DataOutput kümmert sich asynchron von Spark darum, dass die Daten persistiert werden, beispielsweise werden sie in ein HDFS oder eine 26

32 3 Architektur des Clusters[10] Abbildung 3.5: Erweitertes Komponentendiagramm der Implementation Datenbank geschrieben. Dadurch dass dieser Schritt asynchron von Spark passiert, wird die weitere Datenverarbeitung nicht unterbrochen. DistributedFunctions Die komplexen Operationen an den Daten, die der Driver lokal und verteilt ausführt, werden in dieser Komponente gesammelt. Dies dient hauptsächlich dem Zweck den Driver-Code übersichtlich zu halten und die Map- und Reduce-Funktionen einer Verarbeitungskette in einem Java-Package zu sammeln. MeasureData Die Fachlichkeit der zu verarbeitenden Daten in diesem Fall RUM-Messdaten werden in dieser Komponente als strukturierte Java-Klassen bereitgestellt. Spark-Core Diese Komponente stellt die Apache Spark API 4 dar, auf der diese Java-Implementation aufbaut. Driver-Programm Der Mittelpunkt der ganzen Implementation ist der Spark-Driver. Er kombiniert alle vorher genannten Komponenten und macht ein lauffähiges Java-Programm daraus. Er verarbeitet die Daten auf zwei verschiedene Weisen: lokal der Master führt beliebig komplexe Java-Operationen aus ( Actions) verteilt die Slave-Nodes im Cluster führen durch die Spark API Java-Operationen auf den DStreams aus (s. Abschnitt 2.1.6) 4 Apache-Foundation (2015c) 27

33 3 Architektur des Clusters[10] Richtig wäre es diese Komponente weder in die technische noch in die fachliche Hälfte der Architektur zu setzen. Sie ist viel mehr das Bindeglied zwischen der technischen (Spark) und der fachlichen Seite (Web Performance). Der Driver ist allerdings eine Notwendigkeit der Spark-Implementation, weshalb es in die technische Komponente definiert wurde Implementationsdetails Da das Komponentendiagramm 3.5 einen ausreichenden Überblick über die Implementation bietet, wird an dieser Stelle auf ein zu feingranulares Klassendiagramm verzichtet. Der gesamte Projektcode ist allerdings in einem öffentlichen Git-Repository 5 einsehbar und kann dort bei weitergehendem Interesse bezogen werden. Die Implementation des Systems und der erforderlichen Algorithmen erfolgte in Java. Sie wurde soweit mit JavaDoc und Code-Kommentaren versehen, dass andere Entwickler sich leicht in die Arbeit einfinden. Die Input-Daten werden vom System in Java-Objekte übersetzt, sodass sie nativ im Code genutzt werden können. Anforderung 2e und 2h sind damit erfüllt

34 4 Verarbeitung im Cluster[10] Die Belastung der einzelnen Nodes hängt maßgeblich von der Komplexität der Datenverarbeitung ab, welche durch den Quellcode bestimmt wird. Daher ist es umso wichtiger, dass die Verarbeitung auf das nötigste reduziert wird und die Rechenleistung der Hardware optimal ausgenutzt wird. Teure Spark-Operationen sollten daher gemieden werden. Das nachfolgende Kapitel verdeutlicht, welche Daten wie verarbeitet werden um welches Ergebnis zu erreichen. In dieser Arbeit handelt es sich speziell um die Verarbeitung von Messdaten. Das Vorgehen soll im Folgenden nachvollziehbar gemacht werden, auf diese Weise kann das Ergebnis der Arbeit auch auf andere Bereiche übertragen werden. 4.1 Vorverarbeitung des Inputs Als Input-Daten stehen die in Abschnitt 1a vorgestellten RUM-Daten zur Verfügung. Damit der Input verwendbar ist, muss er zunächst von seiner URI-Form in native Java-Objekte umgewandelt werden. Dies erfolgt durch das Parsen mit einem regulären Ausdruck. 4.2 Der Algorithmus in der Verarbeitung Es wird ein Algorithmus auf die Input-Daten angewandt, um die in der Anforderung 1b erwarteten Daten zu gewinnen. Der Algorithmus wird mit möglichst einfach gehaltenem Pseudocode erläutert und mit bekannten Metriken in seiner Komplexität beschrieben, so ist er besser mit anderem Code vergleichbar. Eine der Metriken ist die O-Notation, bei der die Dauer der auszuführenden Operationen in Abhängigkeit von den Eingabedaten skaliert. Die Zeilen im Code, die ein spark vorangestellt haben, werden verteilt auf den Spark- Slaves ausgeführt. Die restlichen Zeilen werden im Driver in diesem Fall auf dem Master durchgeführt. Es wird nur der verwendete Algorithmus beschrieben ohne näher auf den fachlichen Zweck und Wert der erhaltenen Informationen einzugehen. Wie mit den gewonnen Ergebnissen weiter verfahren werden könnte, wird in Kapitel 6.2 angesprochen. Dieser Algorithmus ermittelt gem. Anforderung 1b die Ergebnisse von Output-1: 29

35 4 Verarbeitung im Cluster[10] Input RUM-Daten, die ausschließlich erfolgreiche Webseitenaufrufe enthalten und die Ergebnisse dieses Algorithmus aus vorhergehenden Batches welche mittels Windows erhalten werden(s. Abschnitt 2.1.6). Output Voraussichtlicher nächster zu erwartender SRTT eines Besuchers, berechnet aus dem Durchschnitt der beiden Input-Werte, gem. Output-1. Pseudocode Der Pseudocode ist gemäß dem MapReduce-Prinzip zu lesen: Die Methode parse wird beispielsweise auf jeden erhaltenen Record in input angewandt. Die Variable websiterequests entspricht dem DStream der die Ausgabe-Werte von parse sammelt. 1 > websiterequests = parse(input) 2 > filteredrequests = filter(websiterequests) 3 > expectedsrttpervisitor = reduce(filteredrequests) 4 > sendresulttopersistence(expectedsrttpervisitor) Listing 4.1: Algorithmus Driver Pseudocode 1 function parse(inputrow) 2 spark> rumrequestobject = parseuritoobject(inputrow) 3 spark> return rumrequestobject Listing 4.2: Algorithmus Parsing Pseudocode 1 function reduce(rumrequest1,rumrequest2) 2 spark> result = (rumrequest1.srtt + rumrequest2.srtt)/2 3 spark> return result Listing 4.3: Algorithmus Reduce Pseudocode 1 function sendresulttopersistence(result) 2 spark> output = formattojson(result) 3 spark> sendasynchron(output,externalsystem) Listing 4.4: Algorithmus Output Pseudocode Komplexität Sei n die Menge der erhaltenen Records im letzten Batch, wobei 1Record = 1RUM- M essung und m die Menge aller Records die durch das Window mitverarbeitet werden, dann ist die Komplexität des Pseudocodes O(n + m). Die tatsächliche Rechenzeit hängt außerdem von der Anzahl der beteiligten Spark-Slaves ab, die aber in der O-Notation nicht berücksichtigt wird. 30

36 4 Verarbeitung im Cluster[10] 4.3 Spark-Konfiguration Spark lässt sich durch das Setzen verschiedener Parameter in seiner Verarbeitung beeinflussen, einige davon sind unter Apache-Foundation (2015b) aufgeführt. Manche Parameter lassen sich nur im Code setzen. Dazu gehört unter anderem der Wert, der den Batch-Intervall bestimmt. Um die Anforderung 2b zu erfüllen, wird das Batch-Intervall auf 5 Sekunden gesetzt, das ist das höchstmögliche Intervall um noch der Anforderung zu genügen. Folgendes Szenario zeigt den schlimmstmöglichen Fall: Der frühstmögliche Zeitpunkt X, wann ein Record erhalten werden kann, ist, zu Beginn des Batch-Intervalls wenn Daten für den nächsten Batch gesammelt werden. Angenommen zu Zeitpunkt X wird der Record A erhalten. Laut der Anforderung muss das Ergebnis von A spätestens um X+10s an den Output übergeben worden sein. Spätestens umm X+5s geht Record A über in den Verarbeitungsprozess. Ausgehend davon, dass alle Input-Daten innerhalb eines Batch-Intervalls verarbeitet werden, ist A spätestens um X+10s vollständig verarbeitet und dessen Output weitergegeben. Die Anforderung 2b kann also mit einem Batch-Intervall von 5s erfüllt werden, unter der Bedingung dass die erhaltenen Input-Daten in einem Batch-Intervall verarbeitet werden. Damit ist auch das oben skizzierte worst-case Szenario abgedeckt. Ein Blog-Eintrag 1 der Firma virdata 2 beschreibt wie sich die Leistung von Spark durch das Setzen einiger Parameter noch steigern lässt. Darin wird unter anderem beschrieben, dass sich für den Parameter spark.locality.wait ein Wert von 50ms-100ms bewährt hat. Damit wird bewirkt, dass der einzelne Node nicht länger als den gesetzten Wert darauf wartet, ob er Daten von einem anderen Node zur Verarbeitung erhält. Je kürzer der Wert ist, desto früher beginnt er mit der Verarbeitung seiner vorliegenden Daten. Das Warte-Intervall wird daher auf 50ms konfiguriert. Mit dem Parameter spark.streaming.receiver.maxrate lässt sich bestimmen, wieviele Records pro Sekunde und pro Slave vom Kafka-Broker empfangen werden soll. Mit diesem Parameter werden die Grenzwerte festgestellt, ab denen die maximal erlaubte Antwortzeit noch erreicht wird. Alle hier nicht genannten Parameter wurden in der Standard-Belegung belassen

37 5 Analyse der Verarbeitung[15] Das vorgestellte System wurde in verschiedenen Szenarien getestet und durch das Monitoring konnten die höchstmöglichen Lastspitzen festgestellt werden. Zunächst wird dem Master nur ein Slave zur Verfügung gestellt, im zweiten Szenario erhält der Master alle 12 Slaves. Dadurch lässt sich eine Aussage zur Skalierung von Spark mit mehreren Slaves treffen. Beide Szenarien werden außerdem jeweils mit und ohne Output an ein externes System vorgestellt. Dadurch erhält man einen Eindruck wieviel Rechenzeit für eine Ausgabe benötigt wird bzw. auf wieviel Durchsatz man für die Weitergabe des Outputs an ein anderes System verzichten muss. Abhängig davon wie schnell die Output-Daten an das externe System übergeben werden können, variiert der Durchsatz den man dadurch einbüßt. Bei der Messung des höchsten Durchsatzes muss darauf geachtet werden, dass die Rechenzeit eines Batches nicht die Batchzeit überschreitet, da ansonsten eine Verzögerung bei der Verarbeitung eines Batches eintritt. Damit kann nicht mehr die Anforderung 2b erfüllt werden. Bei den folgenden genannten Datendurchsatz-Messungen kann davon ausgegangen werden, dass die Rechenzeit im Durchschnitt kleiner als die Batchzeit ist und dadurch keine Batches aufgestaut werden. 5.1 Erwartung Da in dieser Arbeit leistungsschwache Hardware verwendet wird, ist davon auszugehen, dass eine der Komponenten der Flaschenhals sein wird. Die Quadcore-CPU ist mit 900 MHz zwar nicht sehr hoch getaktet, sollte aber genug Rechenleistung bieten, um nicht der begrenzende Faktor der Hardware zu sein. Spark benutzt die Java Virtual Machine (JVM), die sehr speicherhungrig ist, dabei hat der einzelne Raspberry Pi 2 ohnehin nicht sehr viel Arbeitsspeicher. Hier wird es wahrscheinlich zum Engpass kommen. Ein weiteres Problem ist die Hardware-Komponente, die für den Zugriff auf die SD-Karte, Netzwerk und USB-Ports zuständig ist. Da die USB-Ports nicht genutzt werden, können diese 32

38 5 Analyse der Verarbeitung[15] unbeachtet bleiben. Um die Schreib- und Lese-Zugriffe auf die SD-Karte möglichst gering zu halten, passieren im Code keine Zugriffe auf das HDFS. Da über das Netzwerk-Interface viel mit den anderen Nodes, dem Input im Internet und dem Output im Internet kommuniziert wird, könnte an dieser Stelle dennoch die Leistung eingeschränkt werden. Vermutlich wird also der Arbeitsspeicher nicht ausreichen oder das Netzwerk-Interface die Daten nicht rechtzeitig nach innen oder außen weitergeben können. Bei diesen Ressourcen wird man eventuell beobachten können, wie sie an ihrer oberen Leistungsgrenze arbeiten. Beim Vergleich der Szenarien wird vermutlich die Variante, die nicht den Output an ein externes System weitergibt, einen höheren Durchsatz und eine kürzere Antwortzeit erreichen als die Variante mit Output. 5.2 Vergleichsaspekte Die verschiedenen Szenarien werden anschließend miteinander verglichen, dazu ist es nötig im vornherein einige Kriterien festzulegen, nach denen das Szenario bewertet wird Durchsatz Bei einem Spark-Cluster vergleicht man die Performance unter anderem mit dem Durchsatz, den das System maximal erreicht. Im Folgenden wird der Durchsatz in records/min angegeben. Ein Record ist ca. 1kB groß, damit gilt 1record/min = 1kB/min. Um den Durchsatz zu errechnen wird folgende Formel verwendet: B records A records X Y Dabei ist Y der Zeitpunkt zu dem A gemessen wird, und X der Zeitpunkt zu dem B gemessen wird. B liegt zeitlich hinter A. Z ist das Ergebnis und wird in records/min gemessen Antwortzeit Die Performance eines Streaming-Systems lässt sich auch durch die Reaktions- oder Antwortzeit messen. Dabei wird nicht die Masse der ankommenden Daten betrachtet, sondern wie lange es dauert bis der Output eines Input-Datums ausgegeben wurde, also wie lange es braucht "bis auf den Input geantwortet wurde". Bei beispielsweise einer Realtime-Anwendung tendiert die Antwortzeit idealerweise gegen 0, da hier die Antwort direkt nach Eingang der Antwort erwartet wird (s. Stonebraker u. a. (2005)). Bei Spark Streaming hängt die Antwortzeit stark von dem gewählten Batch-Intervall ab, genauer wann es im Batch-Intervall vom Cluster empfangen wird und wann der Output des Datums ausgegeben wird. Das liegt an der in Kapitel erklärten Micro-Batch Verarbeitung von Spark Streaming. = Z 33

39 5 Analyse der Verarbeitung[15] 5.3 Auslastung der Hardware-Ressourcen Um den begrenzenden Faktor bei den Nodes zu finden, wurde während der Spark-Verarbeitung die Auslastung der Hardware-Komponenten überwacht. Beobachtet wurde die Auslastung der CPU, des Arbeitsspeichers, des Netzwerk-Interfaces und des persistenten Speichers der Micro-SD Karte. Die nachfolgenden Diagramme zeigen die Auslastung der einzelnen Ressourcen jedes Nodes. Die grüne Kurve ist die Auslastung des Master-Nodes während die anderen Farben die Auslastung der Slaves zeigen. Abbildung 5.1: Auslastung der CPU aller Nodes Abbildung 5.2: Auslastung des Arbeitsspeichers aller Nodes In den einzelnen Diagramme lassen sich die Phasen des Systems ablesen. Die Abschnitte, die mit Leerlauf bezeichnet sind, zeigen die Auslastung der Nodes wenn kein Benutzer-Prozess die Ressourcen beansprucht. Zu diesem Zeitpunkt wird die Hardware kaum beansprucht. Nur der Arbeitsspeicher wird zu ca. 50MB verwendet (s. Abbildung 5.2). 34

40 5 Analyse der Verarbeitung[15] Abbildung 5.3: Auslastung der HDD aller Nodes Abbildung 5.4: Auslastung des Netzwerk-Interface aller Nodes 35

41 5 Analyse der Verarbeitung[15] Die Phase Overhead zeigt die Grundauslastung der Nodes sobald man Spark mit seinem YARN- und HDFS-Dienst gestartet hat. Ab diesem Zeitpunkt wartet das System auf eingehende Jobs. Sobald der Cluster einen Spark-Job erhalten hat, geht es über in die Auslastungs-Phase Spark-Vorbereitung. Dort wird der Job initialisiert, indem die Slaves vorbereitet werden. Der Master erstellt einen lokalen HTTP-Dienst auf dem Monitoring-Daten eingesehen werden können, das.jar-file wird an die Slaves übergeben daher die hohe Netzwerk- (s. 5.4) und Disk-Auslastung (s. 5.3) in dieser Phase. Außerdem werden die Receiver registriert, die dem System als Daten-Input dienen. Anschließend beginnt die Verarbeitung des Jobs im Abschnitt Spark Laufzeit. Hier erhalten die Slaves ihr Input-Daten, weshalb deren RAM-Auslastung (s. Abbildung 5.2) ansteigt, bis sie bei ca. 850MB stagniert. Dann ist der Zeitpunkt erreicht, wenn der Java-eigene Garbage Collector alte Objekte entfernt. Die CPU-Auslastung des Masters die grüne Kurve zeigt in dieser Phase, dass die CPU stark beansprucht ist, sie erreicht dennoch nie die 100%-Marke, weshalb dort noch Ressourcen zur Verfügung stehen. 5.4 Monitoring-Ergebnisse Die folgenden Auswertungen wurden während der Ausführung der einzelnen Szenarien erhalten Node Cluster Die folgenden Ergebnisse sind gemessen worden mit einem Cluster bestehend aus einem Master-Node und einem Slave-Node. Code mit Output In diesem Szenario wird der produktive Anwendungsfall analysiert. Wie im Anforderungskatalog wird der Output an ein externes System weitergegeben, die in der Architektur erwähnte MongoDB-Instanz (s. Abschnitt 3.5.1). Die Abbildung 5.5 zeigt mit der gelben Kurve wieviel Zeit es brauchte den letzten Batch zu verarbeiten. Die grüne Kurve zeigt dagegen wieviele Batches noch auf ihre Verarbeitung warten, solange dieser Wert auf 0 bleibt, konnten alle Input-Daten in time verarbeitet werden. Es ist zu sehen, dass die Verarbeitungszeit eines Batches knapp unter dem Batch-Intervall gehalten werden kann und keine Daten auf ihre Verarbeitung warten. 36

42 5 Analyse der Verarbeitung[15] Abbildung 5.5: Verarbeitungslatenz des einzelnen Slaves mit Output Abbildung 5.6: Verarbeitete Records des einzelnen Slaves mit Output Im Diagramm?? ist der Verlauf der erhaltenen und verarbeiteten Records aufgetragen. Die Kurven verlaufen nahezu deckungsgleich, wobei die gelbe Kurve die verarbeiteten Records unterhalb der grünen Kurve verläuft. Es lassen sich die Datenpunkte 15:24:00 mit verarbeiteten Records und 15:34:00 mit verarbeiteten Records ablesen. Mit der Formel in Abschnitt und folgender Variablen-Belegung: B = records; A = records; X = 15 : 24 h; Y = 15 : 34 h lässt sich das Ergebnis records/min berechnen. In dieser Variante liegt die Leistungsspitze des verwendeten Spark-Systems bei records/min. Code ohne Output Es wurden in dieser Variante die Output-Daten nicht an ein externes System gegeben und auch nicht auf das systemeigene HDFS geschrieben, da dies beides sehr teure Operationen mit Sicht auf die dafür benötigte Rechenzeit sind. Stattdessen wurden die Ergebnisse nur systemintern durch die Action count() gezählt. Das reicht bereits aus, damit der DAG-Scheduler die jeweiligen DStreams bzw. RDDs verarbeiten lässt, aber es entsteht dadurch keine Verzögerung durch das Weitergeben des Outputs an ein externes System. 37