Jochen Mader codecentric AG

Was sich ändert, ist die Art, wie HDFS, YARN, ZooKeeper und Co. verwendet werden. Existierende Komponenten werden dank Spark unter einem einheitlichen Programmiermodell verwendbar.

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?

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. Dabei dient er als Einleitung zu den weiteren Artikeln dieses Titelthemas.

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 (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 erhalten.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 7.16 - "SMACK: Die neue Generation Big Data"

Alle Infos zum Heft
246865Aus Big Data werde Fast Data
X
- Gib Deinen Standort ein -
- or -