Suche
Next Generation Big Data mit SMACK

Spark, Mesos, Akka, Cassandra, Kafka: Aus Big Data werde Fast Data

Jochen Mader

Im Rahmen unseres Themen-Dossiers Scala betrachten wir neben der JVM-Sprache selbst auch populäre Scala-Frameworks. Für die Entwicklung Daten-intensiver, reaktiver Anwendungen haben sich die Scala-basierten Projekte Spark, Akka und Kafka etabliert, die im Zusammenspiel mit Cassandra und Mesos den sogenannten SMACK-Stack bilden. Was die Kombination SMACK zu leisten imstande ist, erklärt Jochen Mader in diesem Artikel.

Aus Big Data werde Fast Data

Big Data verändert sich. Auf Konferenzen werden die bisherigen Buzzwords Hadoop, Storm, Pig und Hive immer mehr durch die Begriffe Fast Data und SMACK verdrängt. Eine derartige Veränderung in einem vergleichsweise jungen Ökosystem wirft einiges an Fragen auf: Was stimmt mit dem bisherigen Vorgehen nicht? Was unterscheidet Fast von Big Data? Und was ist eigentlich SMACK?

Next Generation Big Data mit SMACK

Auf der I/O 2014 hat Google MapReduce offiziell in Rente geschickt: Man habe zu diesem Zeitpunkt bereits auf das neue Dataflow-Framework umgestellt und die bestehenden MapReduce-Jobs entfernt. Diese Meldung sorgte für Aufsehen, nahm man Hadoop und sein Ökosystem zu diesem Zeitpunkt doch immer noch als Innovationsträger wahr. Einige apokalyptische Blogposts und hitzige Diskussionen später kehrte wieder Ruhe in das Thema ein. Viele Unternehmen hatten gerade erst ihre Zehen in den Big-Data-Pool gesteckt und die bisherigen Technologien noch nicht annähernd ausgereizt. Jene Unternehmen, die sich tief genug in die Big-Data-Welt begeben, kommen früher oder später zu der Erkenntnis: Die Grenzen vieler Technologien sind zu eng für die gewünschten schnellen Analysezyklen. Ein neues Konzept war gefragt. Der folgende Artikel wird den Weg von Big Data auf Hadoop zu Fast Data mit SMACK aufzeigen.

scala-iconDossier Scala
Im Themen-Dossier „Scala“ dreht sich alles um die JVM-Sprache Scala. Nach unserer Einführung in die grundlegenden Konzepte von Scala ordnet Martin Odersky die Evolution Scalas für uns im Interview ein. Außerdem beleuchten wir den reaktiven Technologie-Stack um Scala und lassen Scala-Entwickler zu Wort kommen, um uns von ihren persönlichen Scala-Tops und Flops zu berichten.
Bisher erschienen:

Am Anfang war das Lambda

Über die Jahre hat sich die Big-Data-Welt zu einem schwer zu überblickenden Zoo miteinander verwobener Frameworks und Infrastrukturkomponenten entwickelt: HDFS, Ceph, ZooKeeper, HBase, Storm, Kafka, Pig, Hive und so weiter. Viele dieser Komponenten sind sehr spezialisiert und bilden nur eine Teilmenge der angestrebten Funktionalitäten ab. Erst ihre – nicht ganz problemlose – Kombination erlaubte die Umsetzung komplexerer Anwendungsfälle. Mit der Zeit hat sich gezeigt, dass viele der Frameworks grob in zwei Gruppen eingeteilt werden können: Da sind zum einen jene Frameworks, die sofort oder zeitnah antworten (siehe Kasten: „Real Time“). In diese Kategorie fallen Storm, Samza, verschiedene CEP Engines, aber auch reaktive Frameworks wie Akka, Vert.x oder Quasar.

Die zweite Gruppe sind Frameworks, die ihre Antwort erst nach einer etwas längeren Zeit liefern können. Hierunter fällt alles, was auf MapReduce aufbaut, z. B. Pig oder Hive. Da die beiden Gruppen immer gemeinsam aufgetreten sind, hat sich daraus ein entsprechender Architekturstil entwickelt. Dieser ist bis heute in praktisch allen Big-Data-Plattformen zu finden und hat von Nathan Marz die Bezeichnung Lambda Architecture [1] erhalten (Abb. 1).

mader_fast_data_1

Abb. 1: Darstellung der Lambda-Architektur

In dieser Architektur werden eingehende Daten (1) von zwei Layern konsumiert. Im Batch Layer (2) finden Langläuferanalysen basierend auf den abgelegten Rohdaten statt. Die Ergebnisse dieser Analysen werden dem Serving Layer (4) bereitgestellt, wo sie für Clients abrufbar sind. Der Speed Layer (3) verzichtet auf performancehungrige Persistenzlösungen und erledigt den Großteil seiner Arbeit im Hauptspeicher. Da er nie die Gesamtheit der Daten vorhalten kann, muss er sich auf einen engen Ausschnitt beschränken. Bestimmte Ergebnisse kann er deutlich schneller ermitteln. Am Ende wandern auch seine Aggregate in den Serving Layer und können dort mit den Ergebnissen aus dem Batch Layer verbunden werden. Bei genauerem Hinsehen fällt die bidirektionale Verbindung zwischen Serving und Speed Layer auf. Bestimmte Werte liegen als verteilte In-Memory-Datenstrukturen vor, z. B. verteilte Counter, und dürfen natürlich live abgegriffen werden.

Real Time

Der Begriff Real Time verursacht mir regelmäßig Ausschlag. Leider verstehen viele Menschen unter Echtzeit etwas ganz anderes, als es die eigentliche Definition vorsieht. Echtzeit meint die Fähigkeit eines Systems, Ergebnisse in einer festgelegten Zeitspanne zu liefern. Bremscontroller, medizinische Geräte und viele Bestandteile von Satelliten müssen echtzeitfähig sein, um Katastrophen zu verhindern. Eine Bremse muss innerhalb einer festgelegten Zeitspanne auf das Treten des Pedals reagieren oder der Fahrer hat ein ernst zu nehmendes Problem. Es geht nicht um „die Antwort kommt so schnell wie möglich“, sondern um „die Antwort kommt garantiert innerhalb dieser Zeitspanne“. Viel passender erscheint mir der Begriff Near Time, um zu beschreiben, was wir in Big-Data-/Fast-Data-Anwendungen anstreben.

Redundante Logik kann problematisch sein

In diesen drei Layern haben sich in den letzten Jahren viele technisch ausgereifte Frameworks etabliert und große Erfolge gefeiert. Mit den Erfolgen wuchsen auch die Anforderungen. Immer schneller und flexibler sollten neue Analysen formuliert werden. Man wollte Ergebnisse in unterschiedlichen Auflösungen sehen: Sekunden-, Minuten-, Stunden- oder Tagestakt. MapReduce erreichte hier schnell die Grenze des Machbaren. Dank seiner Flexibilität und den deutlich geringeren Antwortzeiten wanderten deshalb immer mehr Analysen in den Speed Layer. Allerdings führte dies nicht zu weniger Logik im Batch Layer. Da die In-Memory-Verarbeitung durch die Größe des Hauptspeichers beschränkt ist, müssen viele Analysen immer noch in Batches durchgeführt werden. Die oft inkompatiblen Programmiermodelle führten dazu, dass viel Logik mehrfach implementiert werden musste. Solche Redundanzen können zu gravierend unterschiedlichen Ergebnissen bei der Auswertung der gleichen Datenquellen führen. An dieser Stelle ist klar, warum ein einheitliches Programmiermodell, das große Bereiche der Analyse abdeckt, wünschenswert ist.

Die Geburt von Fast Data

Das AMPLab der University of California in Berkeley veröffentlichte 2010 ein neues Open-Source-Analysewerkzeug, das genau dieses Problem lösen sollte. Spark wurde 2013 zum Apache-Projekt und hat seither eine beeindruckende Entwicklung durchgemacht. Im Kern dreht sich bei Spark alles um die so genannten Resilient Distributed Datasets (RDD): verteilte, fehlertolerante, parallelisierbare Datenstrukturen. Diese können in Verbindung mit vielen verschiedenen Modulen genutzt werden:

  • Verarbeitung von Graphen (GraphX)
  • Spark SQL, um mit den Daten aus verschiedenen strukturierten Datenquellen umzugehen (Hive, JDBC, Parquet etc.)
  • Streaming (Kafka, HDFS, Flume, ZeroMQ, Twitter)
  • Machine Learning basierend auf der MLib

Neben Scala unterstützt Spark mittlerweile auch Python und R als Programmiersprachen. Das erleichtert Data Scientists den Einstieg, die bereits Erfahrung mit einem der beiden gesammelt haben. Wie Sie aus der Liste entnehmen können, ist Spark ein recht verbindungsfreudiges Framework und schafft es so, viele der bereits existierenden Datenquellen unter einem einheitlichen API zu vereinen. Das so entstandene Analyseframework hat sich schnell durchgesetzt.

Durch die Kombination aus strukturierten Datenquellen und Streams ist es möglich, weite Teile des Speed Layers mit dem Batch Layer unter einer einheitlichen Oberfläche zu vereinen. Analysen können nun in beinahe beliebiger Auflösung durchgeführt werden. Spark-Jobs können auch von Nichtentwicklern in erstaunlicher Zeit entwickelt und deployt werden. Die Argumente für Spark sind ziemlich deutlich:

  • skalierbar, um auch mit Millionen von Datensätzen umgehen zu können
  • schnell genug, um Antworten in Near Time zu liefern
  • geeignet, um Analysen mit beliebiger Laufzeit umzusetzen
  • ein einheitliches, verständliches Programmiermodell für den Umgang mit verschiedenen Datenquellen

Aber auch Spark hat seine Grenzen. Tools zur Datenanlieferung und Persistierung sind weiterhin notwendig. Hier können wir auf die Erfahrungen der letzten Jahre zurückgreifen.

Enter the SMACK

Häufig hört man von Spark in Verbindung mit dem SMACK-Stack. Dabei handelt es sich um die Kombination bekannter Technologien aus verschiedenen Bereichen der Big-Data-Analyse zu einem mächtigen Basisframework. Das Akronym SMACK steht dabei für: Spark, Mesos, Akka, Cassandra und Kafka.

Auf den ersten Blick könnte man annehmen, dass hier jemand tief in die Kiste „Hippe Technologien“ gegriffen hätte. Ich nehme an, Sie haben von jedem der gerade genannten Frameworks zumindest schon mal gehört. Welche Aufgaben sie aber im Kontext dieses Stacks erfüllen, möchte ich dennoch kurz erklären:

Apache Mesos [2] ist ein Kernel für verteilte Systeme. Es stellt eine Abstraktionsschicht über einem Cluster aus Maschinen dar. Statt eine Anwendung auf einem Knoten zu deployen, wird diese samt einer Bedarfsbeschreibung (Zahl CPUs, benötigter RAM etc.) an Mesos übergeben und auf entsprechende Maschinen verteilt. So lassen sich vergleichsweise einfach mehrere tausend Maschinen gezielt auslasten. Mesos ist das zentrale Nervensystem des Stacks. Alle Komponenten des SMACK-Stacks sind in Mesos verfügbar und integrieren sich perfekt in seine Ressourcenverwaltung. Hinzu kommt, dass die kommerzielle Variante Mesosphere bereits direkt auf Amazon AWS und Microsoft Azure verfügbar ist. Ein passendes Cloud-Rechenzentrum lässt sich somit in Rekordzeit aufbauen.

Das reaktive Framework Akka [3] basiert auf dem aus Erlang bekannten Aktorenkonzept. Akka hat sich in den letzten Jahren zu einem der führenden Frameworks für verteilte, fehlertolerante Anwendungen entwickelt. In diesem Kontext findet es vor allem im Ingestion-Bereich und als Zugriffsschicht im Serving Layer Verwendung.

Ein weiteres Mitglied im Apache-Ökosystem ist Cassandra [4]. Cassandra ist eine verteilte, resiliente, skalierbare Datenbank zur Ablage gigantischer Datenmengen. Sie unterstützt die Verteilung über mehrere Rechenzentren und überlebt den Ausfall mehrerer Knoten. In diesem Fall wird sie als primäre Datenablage verwendet.

Apache Kafka [5] wird oft als verteiltes Messaging-System betrachtet, was es auch im engeren Sinne ist. Tatsächlich ist es nichts weiter als ein verteiltes Commit-Log. Seine einfache Struktur erlaubt es, gigantische Mengen an Daten zwischen mehreren Systemen zu transferieren und dabei linear zu skalieren.

mader_fast_data_2

Abb. 2: Der SMACK-Stack: eine solide Basis für Fast-Data-Infrastrukturen

Alle zusammen ergeben eine solide Basis für Fast-Data-Infrastrukturen (Abb. 2): Akka (1) konsumiert eingehende Daten wie MQTT-Events, einen Clickstream oder Binärdaten und schreibt diese direkt in entsprechende Topics in Kafka (2). Nachdem die Daten jetzt bereits persistiert sind, können wir entscheiden, wie schnell wir die verschiedenen Antworten erhalten wollen. Verschiedene Spark-Jobs (3) konsumieren die Daten und werten sie in unterschiedlicher Auflösung aus:

  • Rohdatenpersistenz: Ein Job, der eingehende Rohdaten nach S3, HDFS oder Ceph schreibt, um sie für eine spätere Verarbeitung vorzuhalten.
  • Speed Layer: Umsetzung von Quick-Win-Analysen, deren Ergebnisse im Sekundenbereich liegen.
  • Batch Layer: Langfristige Analysen oder Machine Learning.

Ergebnisse werden nach HDFS (5) und Cassandra geschrieben (4) und können für andere Jobs wieder als Input verwendet werden. Am Ende (6) steht wieder Akka als HTTP-Layer, um die Daten z. B. in einer Weboberfläche anzuzeigen.

Automatisierung entscheidet

Neben den technischen Kernkomponenten ist die Automatisierung ein zentraler Punkt, der über Erfolg oder Misserfolg einer echten Fast-Data-Plattform entscheidet. Mesos liefert hier bereits viele wichtige Basiskomponenten. Dennoch werden wir auch weiterhin Tools wie Terraform, Ansible, Kubernetes und eine umfangreiche Monitoring-Infrastruktur benötigen. An dieser Stelle dürfte klar werden, worauf ich hinaus möchte: Ohne DevOps wird es schwer, die gesetzten Ziele zu erreichen. Die Zusammenarbeit zwischen Developer und Operator ist essenziell in einem System, das elastisch über mehrere hundert Maschinen skalieren und funktionieren soll.

To Scala or not

An Scala scheiden sich die Geister. Ich möchte diesen Artikel jedoch bewusst nicht dazu nutzen, eine weitere Diskussion um Sprachfeatures anzustoßen. In diesem speziellen Fall schlägt die normative Kraft des Faktischen zu, weil alle verwendeten Frameworks entweder in Scala geschrieben oder sehr Scala-affin sind:

  • Akka: in Scala geschrieben, primär API in Scala, aber auch in Java verfügbar
  • Spark: in Scala geschrieben, primär API in Scala, Python und R verfügbar
  • Kafka: in Scala geschrieben, integriert in Spark und wenig direktes Coding notwendig (allerdings seit 0.9 primär Java-API)
  • Cassandra: In Java geschrieben, Interaktion erfolgt primär über CQL und Spark-Integration

Ein SMACK-Entwickler wird nicht an Scala-Code vorbeikommen. Scala ist die pragmatische Entscheidung, um mit diesem Stack erfolgreich zu sein.

Fazit

Hadoop ist nicht tot. Auch in Zukunft werden HDFS, YARN, ZooKeeper und Co. wichtige Bestandteile unserer Big-Data-Welt bleiben. Was sich jedoch ändert, ist die Art, wie sie verwendet werden. Existierende Komponenten werden dank Spark unter einem einheitlichen Programmiermodell verwendbar. Spark ist nur ein Tool. Viel wichtiger sind die Ziele, die hinter dem Schlagwort Fast Data stecken:

  • Niedrige Einstiegshürde für Data Scientists
  • Unterschiede zwischen Speed und Batch Layer sollen verschwinden
  • Explorative Analysen werden deutlich erleichtert
  • Deployment neuer Jobs wird einfacher und schneller
  • Bestehende Infrastruktur wird einfacher nutzbar

SMACK bietet diese Kombination und setzt auf bewährte Technologien. Der Schlüssel liegt in ihrer Verwendung und der Kombination mit hoher Automatisierung. So entsteht eine Plattform, die in ihrer Flexibilität nur schwer zu überbieten ist.

Geschrieben von
Jochen Mader
Jochen Mader
Jochen Mader ist Lead IT Consultant bei der codecentric AG, Autor verschiedener Fachartikel und generell an allem interessiert, was Softwareentwicklung spannend macht. Auf Twitter findet man ihn unter dem Handle @codeptibull
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.