Hadoop, Storm, Samza, Spark und Flink: Vergleich von Big Data Frameworks

Die Verarbeitungsfunktionalität von Hadoop stammt von der MapReduce-Engine. Die Verarbeitungstechnik von MapReduce folgt dem Map-, Shuffle- und Reduction-Algorithmus unter Verwendung von Schlüssel-Wert-Paaren. Das grundlegende Verfahren umfasst:

Da diese Methode die permanente Speicherung, das mehrmalige Lesen und Schreiben pro Task in hohem Maße nutzt, ist sie in der Regel relativ langsam. Auf der anderen Seite bedeutet dies, dass MapReduce enorme Datenmengen verarbeiten kann, da Speicherplatz normalerweise eine der am häufigsten vorkommenden Serverressourcen ist. Dies bedeutet auch, dass MapReduce von Hadoop in der Regel auf kostengünstigerer Hardware als manche Alternativen ausgeführt werden kann, da nicht versucht wird, alles im Speicher zu speichern. MapReduce verfügt über ein unglaubliches Skalierbarkeitspotenzial und wurde in der Produktion auf Zehntausenden von Knoten verwendet.

MapReduce ist als Entwicklungsziel dafür bekannt, eine ziemlich steile Lernkurve zu haben. Andere Ergänzungen des Hadoop-Ökosystems können die Auswirkungen in unterschiedlichem Maße verringern, können aber dennoch ein Faktor für die schnelle Implementierung einer Idee in einem Hadoop-Cluster sein.

Hadoop verfügt über ein umfangreiches Ökosystem, wobei der Hadoop-Cluster selbst häufig als Baustein für andere Software verwendet wird. Viele andere Verarbeitungsframeworks und Engines verfügen über Hadoop-Integrationen, um HDFS und den YARN-Ressourcenmanager zu verwenden.

Apache Hadoop und seine MapReduce-Verarbeitungsengine bieten ein bewährtes Stapelverarbeitungsmodell, das sich am besten für die Verarbeitung sehr großer Datenmengen eignet, bei denen die Zeit keine Rolle spielt. Die geringen Kosten für Komponenten, die für ein gut funktionierendes Hadoop-Cluster erforderlich sind, machen diese Verarbeitung für viele Anwendungsfälle kostengünstig und effektiv. Durch die Kompatibilität und Integration mit anderen Frameworks und Engines kann Hadoop häufig als Grundlage für mehrere Verarbeitungs-Workloads mit unterschiedlichen Technologien dienen.

Die Storm Stream-Verarbeitung funktioniert, indem DAGs (Directed Acyclic Graphs) in einem Framework orchestriert werden, das sie * Topologien * nennt. Diese Topologien beschreiben die verschiedenen Transformationen oder Schritte, die für jedes eingehende Datenelement beim Eintritt in das System ausgeführt werden.

Die Topologien setzen sich zusammen aus:

Die Idee hinter Storm ist es, kleine, diskrete Operationen unter Verwendung der obigen Komponenten zu definieren und diese dann zu einer Topologie zusammenzusetzen. Standardmäßig bietet Storm Garantien für die mindestens einmalige Verarbeitung. Dies bedeutet, dass garantiert werden kann, dass jede Nachricht mindestens einmal verarbeitet wird. In einigen Fehlerszenarien kann es jedoch zu Duplikaten kommen. Storm garantiert nicht, dass Nachrichten in der richtigen Reihenfolge verarbeitet werden.

Um eine genau einmalige, zustandsbehaftete Verarbeitung zu erreichen, steht auch eine Abstraktion mit dem Namen * Trident * zur Verfügung. Um genau zu sein, wird Storm without Trident oft als * Core Storm * bezeichnet. Trident ändert die Verarbeitungsdynamik von Storm erheblich, erhöht die Latenz, fügt der Verarbeitung einen Status hinzu und implementiert ein Mikro-Batching-Modell anstelle eines reinen Element-für-Element-Streaming-Systems.

Storm-Benutzer empfehlen normalerweise die Verwendung von Core Storm, wann immer dies möglich ist, um diese Nachteile zu vermeiden. Vor diesem Hintergrund ist die Garantie von Trident, dass Artikel genau einmal verarbeitet werden, in Fällen nützlich, in denen das System doppelte Nachrichten nicht intelligent verarbeiten kann. Trident ist auch die einzige Option in Storm, wenn Sie den Status zwischen Elementen beibehalten müssen, z. B. wenn Sie zählen, wie viele Benutzer innerhalb einer Stunde auf einen Link klicken. Trident gibt Storm Flexibilität, obwohl es die natürlichen Stärken des Frameworks nicht ausnutzt.

Dreizack-Topologien bestehen aus:

Storm ist wahrscheinlich die beste derzeit verfügbare Lösung für die Echtzeitverarbeitung. Es ist in der Lage, Daten mit extrem geringer Latenz für Workloads zu verarbeiten, die mit minimaler Verzögerung verarbeitet werden müssen. Storm ist häufig eine gute Wahl, wenn sich die Verarbeitungszeit direkt auf die Benutzererfahrung auswirkt, z. B. wenn das Feedback aus der Verarbeitung direkt auf die Seite eines Besuchers auf einer Website zurückgeführt wird.

Storm with Trident bietet Ihnen die Möglichkeit, Micro-Batches anstelle der reinen Stream-Verarbeitung zu verwenden. Dies gibt dem Benutzer zwar mehr Flexibilität bei der Anpassung des Tools an die beabsichtigte Verwendung, negiert jedoch tendenziell einige der größten Vorteile der Software gegenüber anderen Lösungen. Trotzdem ist es immer noch hilfreich, eine Auswahl für den Stream-Verarbeitungsstil zu haben.

Core Storm bietet keine Bestellgarantie für Nachrichten. Core Storm bietet mindestens einmalige Verarbeitungsgarantien, dh, die Verarbeitung jeder Nachricht kann garantiert werden, es können jedoch Duplikate auftreten. Trident bietet genau einmalige Garantien und kann Bestellungen zwischen Chargen anbieten, jedoch nicht innerhalb.

Im Hinblick auf die Interoperabilität kann Storm in Hadoops YARN-Ressourcen-Negotiator integriert werden, wodurch die Anbindung an eine vorhandene Hadoop-Bereitstellung vereinfacht wird. Storm bietet mehr als die meisten Verarbeitungsframeworks eine umfassende Sprachunterstützung und bietet Benutzern viele Optionen zum Definieren von Topologien.

Für reine Stream-Verarbeitungs-Workloads mit sehr hohen Latenzanforderungen ist Storm wahrscheinlich die ausgereifteste Option. Es kann die Nachrichtenverarbeitung gewährleisten und kann mit einer großen Anzahl von Programmiersprachen verwendet werden. Da Storm keine Stapelverarbeitung durchführt, müssen Sie zusätzliche Software verwenden, wenn Sie diese Funktionen benötigen. Wenn Sie einen hohen Bedarf an Garantien für die einmalige Bearbeitung haben, kann Trident dies bereitstellen. Zu diesem Zeitpunkt könnten jedoch auch andere Stream-Processing-Frameworks besser passen.

Samza verwendet die Semantik von Kafka, um die Art und Weise zu definieren, in der Streams verarbeitet werden. Kafka verwendet im Umgang mit Daten die folgenden Konzepte:

Da Kafka ein unveränderliches Protokoll darstellt, handelt Samza mit unveränderlichen Streams. Dies bedeutet, dass alle Transformationen neue Streams erstellen, die von anderen Komponenten verwendet werden, ohne dass dies Auswirkungen auf den ursprünglichen Stream hat.

Samzas Vertrauen in ein Kafka-ähnliches Warteschlangensystem scheint auf den ersten Blick restriktiv. Es bietet dem System jedoch einige einzigartige Garantien und Funktionen, die in anderen Stream-Verarbeitungssystemen nicht üblich sind.

Beispielsweise bietet Kafka bereits die replizierte Speicherung von Daten an, auf die mit geringer Latenz zugegriffen werden kann. Es bietet auch ein sehr einfaches und kostengünstiges Mehrteilnehmermodell für jede einzelne Datenpartition. Die gesamte Ausgabe, einschließlich der Zwischenergebnisse, wird ebenfalls an Kafka geschrieben und kann von den nachgeschalteten Stufen unabhängig verwendet werden.

In vielerlei Hinsicht spiegelt diese enge Abhängigkeit von Kafka die Art und Weise wider, in der die MapReduce-Engine häufig auf HDFS verweist. Während das Verweisen auf HDFS zwischen den einzelnen Berechnungen zu schwerwiegenden Leistungsproblemen bei der Stapelverarbeitung führt, werden bei der Stream-Verarbeitung eine Reihe von Problemen behoben.

Die enge Beziehung von Samza zu Kafka ermöglicht es, die Verarbeitungsschritte selbst sehr locker miteinander zu verknüpfen. Eine beliebige Anzahl von Teilnehmern kann ohne vorherige Koordination zu der Ausgabe jedes Schritts hinzugefügt werden. Dies kann für Organisationen sehr nützlich sein, in denen mehrere Teams möglicherweise auf ähnliche Daten zugreifen müssen. Alle Teams können das Thema der Daten abonnieren, die in das System eingegeben werden, oder sie können problemlos Themen abonnieren, die von anderen Teams erstellt wurden, die sich einer bestimmten Verarbeitung unterzogen haben. Dies ist möglich, ohne die lastsensitive Infrastruktur wie Datenbanken zusätzlich zu belasten.

Das direkte Schreiben an Kafka beseitigt auch die Probleme des * Gegendrucks *. Der Gegendruck tritt auf, wenn Lastspitzen einen Datenfluss mit einer Geschwindigkeit verursachen, die größer ist als die der Komponenten, die in Echtzeit verarbeitet werden können, was zu Verarbeitungsstillständen und potenziellem Datenverlust führt. Kafka ist darauf ausgelegt, Daten für sehr lange Zeiträume zu speichern. Dies bedeutet, dass Komponenten nach Belieben verarbeitet und ohne Konsequenzen neu gestartet werden können.

Samza kann den Status mithilfe eines fehlertoleranten Prüfpunktsystems speichern, das als lokaler Schlüsselwertspeicher implementiert ist. Auf diese Weise kann Samza eine mindestens einmalige Zustellgarantie anbieten, die jedoch keine genaue Wiederherstellung des aggregierten Zustands (z. B. Anzahl) im Falle eines Ausfalls ermöglicht, da Daten möglicherweise mehrmals zugestellt werden.

Samza bietet Abstraktionen auf hoher Ebene, mit denen in vielerlei Hinsicht einfacher gearbeitet werden kann als mit den von Systemen wie Storm bereitgestellten Grundelementen. Samza unterstützt derzeit nur JVM-Sprachen, was bedeutet, dass es nicht die gleiche Sprachflexibilität wie Storm hat.

Apache Samza ist eine gute Wahl für Streaming-Workloads, bei denen Hadoop und Kafka entweder bereits verfügbar sind oder sinnvoll implementiert werden können. Samza selbst eignet sich gut für Organisationen mit mehreren Teams, die Datenströme in verschiedenen Phasen der Verarbeitung verwenden (aber nicht unbedingt eng koordinieren). Samza vereinfacht viele Teile der Stream-Verarbeitung erheblich und bietet eine geringe Latenzzeit. Dies ist möglicherweise keine gute Lösung, wenn die Bereitstellungsanforderungen nicht mit Ihrem aktuellen System kompatibel sind, wenn Sie eine Verarbeitung mit extrem geringer Latenz benötigen oder wenn Sie ein starkes Bedürfnis nach genau einmaliger Semantik haben.

Im Gegensatz zu MapReduce verarbeitet Spark alle Daten im Speicher und interagiert nur mit der Speicherebene, um die Daten zunächst in den Speicher zu laden und am Ende die endgültigen Ergebnisse beizubehalten. Alle Zwischenergebnisse werden im Speicher verwaltet.

Während die In-Memory-Verarbeitung wesentlich zur Geschwindigkeit beiträgt, ist Spark auch bei festplattenbezogenen Aufgaben schneller, da eine ganzheitliche Optimierung erzielt werden kann, indem der gesamte Aufgabensatz vorab analysiert wird. Dies wird durch die Erstellung von gerichteten azyklischen Diagrammen (Directed Acyclic Graphs, DAGs) erreicht, die alle auszuführenden Vorgänge, die zu bearbeitenden Daten sowie die Beziehungen zwischen ihnen darstellen. Auf diese Weise kann der Prozessor die Arbeit intelligenter koordinieren.

Zur Implementierung der In-Memory-Batch-Berechnung verwendet Spark ein Modell mit dem Namen Resilient Distributed Datasets (* RDDs *), um mit Daten zu arbeiten. Hierbei handelt es sich um unveränderliche Strukturen im Speicher, die Datensammlungen darstellen. Operationen an RDDs erzeugen neue RDDs. Jedes RDD kann seine Herkunft über seine übergeordneten RDDs und letztendlich bis zu den Daten auf der Festplatte zurückverfolgen. Grundsätzlich bieten RDDs eine Möglichkeit für Spark, die Fehlertoleranz aufrechtzuerhalten, ohne nach jedem Vorgang auf die Festplatte zurückschreiben zu müssen.

Stream-Verarbeitungsfunktionen werden von Spark Streaming bereitgestellt. Spark selbst wurde für chargenorientierte Workloads entwickelt. Um die Diskrepanz zwischen dem Motorkonzept und den Merkmalen von Streaming-Workloads zu beseitigen, implementiert Spark ein Konzept mit dem Namen micro-batches *. Diese Strategie dient dazu, Datenströme als eine Reihe sehr kleiner Stapel zu behandeln, die unter Verwendung der nativen Semantik der Batch-Engine verarbeitet werden können.

Spark Streaming puffert den Stream in Schritten von weniger als einer Sekunde. Diese werden als kleine feste Datensätze für die Stapelverarbeitung gesendet. In der Praxis funktioniert dies recht gut, aber es führt zu einem anderen Leistungsprofil als bei echten Stream-Processing-Frameworks.

Der offensichtliche Grund für die Verwendung von Spark über Hadoop MapReduce ist die Geschwindigkeit. Spark kann dieselben Datasets aufgrund seiner speicherinternen Berechnungsstrategie und seiner fortschrittlichen DAG-Planung erheblich schneller verarbeiten.

Ein weiterer großer Vorteil von Spark ist seine Vielseitigkeit. Es kann als eigenständiger Cluster bereitgestellt oder in einen vorhandenen Hadoop-Cluster integriert werden. Es kann sowohl Batch- als auch Stream-Verarbeitung ausführen, sodass Sie einen einzelnen Cluster betreiben können, um mehrere Verarbeitungsstile zu verarbeiten.

Abgesehen von den Funktionen der Engine selbst verfügt Spark auch über ein Bibliothekssystem, das für maschinelles Lernen, interaktive Abfragen usw. verwendet werden kann. Es wird allgemein anerkannt, dass Spark-Aufgaben einfacher zu schreiben sind als MapReduce, was erhebliche Auswirkungen auf die Produktivität haben kann.

Das Anpassen der Batch-Methode für die Stream-Verarbeitung umfasst das Puffern der Daten beim Eintritt in das System. Mit dem Puffer kann ein hohes Datenaufkommen verarbeitet werden, wodurch der Gesamtdurchsatz erhöht wird. Das Warten auf das Leeren des Puffers führt jedoch auch zu einer deutlichen Erhöhung der Latenz. Dies bedeutet, dass Spark Streaming möglicherweise nicht für die Verarbeitung geeignet ist, bei der eine geringe Latenz erforderlich ist.

Da RAM im Allgemeinen teurer ist als Festplattenspeicher, kann der Betrieb von Spark mehr kosten als bei festplattenbasierten Systemen. Die höhere Verarbeitungsgeschwindigkeit bedeutet jedoch, dass Aufgaben viel schneller erledigt werden können, was die Kosten vollständig ausgleichen kann, wenn Sie in einer Umgebung arbeiten, in der Sie stündlich für Ressourcen zahlen.

Eine weitere Konsequenz des In-Memory-Designs von Spark ist, dass die Ressourcenknappheit bei der Bereitstellung in gemeinsam genutzten Clustern ein Problem darstellen kann. Im Vergleich zu MapReduce von Hadoop verbraucht Spark deutlich mehr Ressourcen, wodurch andere Aufgaben beeinträchtigt werden können, die möglicherweise versuchen, den Cluster zu diesem Zeitpunkt zu verwenden. Im Wesentlichen ist Spark möglicherweise ein weniger rücksichtsvoller Nachbar als andere Komponenten, die auf dem Hadoop-Stapel ausgeführt werden können.

Spark ist eine großartige Option für Benutzer mit unterschiedlichen Verarbeitungsaufgaben. Die Spark-Batch-Verarbeitung bietet unglaubliche Geschwindigkeitsvorteile und sorgt für eine hohe Speichernutzung. Spark Streaming ist eine gute Stream-Verarbeitungslösung für Workloads, bei denen Durchsatz und Latenz gleichermaßen wichtig sind.

Das Stream-Verarbeitungsmodell von Flink behandelt eingehende Daten Element für Element als echten Stream. Flink stellt seine DataStream-API zur Verfügung, um mit unbegrenzten Datenströmen zu arbeiten. Die grundlegenden Komponenten, mit denen Flink arbeitet, sind:

Stream-Verarbeitungs-Tasks erstellen während der Berechnung Momentaufnahmen zu festgelegten Zeitpunkten, die bei Problemen zur Wiederherstellung verwendet werden können. Zum Speichern des Status kann Flink mit einer Reihe von Status-Back-Ends arbeiten, die sich durch unterschiedliche Komplexität und Persistenz auszeichnen.

Darüber hinaus kann die Stream-Verarbeitung von Flink das Konzept der „Ereigniszeit“ verstehen, dh die Zeit, zu der das Ereignis tatsächlich eingetreten ist, und auch Sitzungen verarbeiten. Dies bedeutet, dass die Bestellung und Gruppierung auf interessante Weise garantiert werden kann.

Das Stapelverarbeitungsmodell von Flink ist in vielerlei Hinsicht nur eine Erweiterung des Stream-Verarbeitungsmodells. Anstatt aus einem kontinuierlichen Stream zu lesen, wird ein begrenzter Datensatz aus dem persistenten Speicher als Stream gelesen. Flink verwendet für beide Verarbeitungsmodelle genau dieselbe Laufzeit.

Flink bietet einige Optimierungen für Batch-Workloads. Da Batch-Vorgänge beispielsweise durch dauerhaften Speicher gesichert sind, entfernt Flink Snapshots aus Batch-Ladevorgängen. Die Daten können weiterhin wiederhergestellt werden, die normale Verarbeitung wird jedoch schneller abgeschlossen.

Eine weitere Optimierung besteht darin, Batch-Aufgaben aufzulösen, sodass Phasen und Komponenten nur bei Bedarf beteiligt sind. Dies hilft Flink, gut mit anderen Benutzern des Clusters zu spielen. Durch die vorbeugende Analyse der Aufgaben kann Flink auch optimieren, indem der gesamte Vorgangssatz, die Größe des Datensatzes und die Anforderungen der nachfolgenden Schritte angezeigt werden.

Flink ist derzeit eine einzigartige Option in der Welt der Verarbeitungs-Frameworks. Während Spark die Stapel- und Stream-Verarbeitung durchführt, ist das Streaming aufgrund seiner Mikro-Batch-Architektur für viele Anwendungsfälle nicht geeignet. Der Stream-First-Ansatz von Flink bietet niedrige Latenzzeiten, hohen Durchsatz und echte Verarbeitung von Einträgen zu Einträgen.

Flink erledigt viele Dinge für sich. Etwas unkonventionell verwaltet es seinen eigenen Speicher, anstatt sich aus Leistungsgründen auf die systemeigenen Garbage Collection-Mechanismen von Java zu verlassen. Im Gegensatz zu Spark muss Flink nicht manuell optimiert und angepasst werden, wenn sich die Eigenschaften der verarbeiteten Daten ändern. Es übernimmt auch die automatische Partitionierung und Zwischenspeicherung von Daten.

Flink analysiert seine Arbeit und optimiert Aufgaben auf verschiedene Weise. Ein Teil dieser Analyse ähnelt dem, was SQL-Abfrageplaner in Beziehungsdatenbanken tun, um die effektivste Methode zum Implementieren einer bestimmten Aufgabe zu ermitteln. Es ist in der Lage, Phasen, die parallel abgeschlossen werden können, zu parallelisieren und gleichzeitig Daten für blockierende Aufgaben zusammenzuführen. Bei iterativen Aufgaben versucht Flink aus Performancegründen, Berechnungen auf den Knoten durchzuführen, auf denen die Daten gespeichert sind. Es kann auch eine "Delta-Iteration" oder eine Iteration nur für die Teile von Daten durchgeführt werden, die Änderungen aufweisen.

In Bezug auf die Benutzertools bietet Flink eine webbasierte Planungsansicht, mit der Aufgaben einfach verwaltet und das System angezeigt werden können. Benutzer können auch den Optimierungsplan für übermittelte Aufgaben anzeigen, um zu sehen, wie er tatsächlich im Cluster implementiert wird. Für Analyseaufgaben bietet Flink SQL-ähnliche Abfrage-, Grafikverarbeitungs- und Maschinenlernbibliotheken sowie In-Memory-Berechnungen.

Flink funktioniert gut mit anderen Komponenten. Es wird geschrieben, um ein guter Nachbar zu sein, wenn es innerhalb eines Hadoop-Stacks verwendet wird und nur die erforderlichen Ressourcen zu einem bestimmten Zeitpunkt beansprucht. Es lässt sich problemlos in YARN, HDFS und Kafka integrieren. Flink kann Aufgaben ausführen, die für andere Verarbeitungsframeworks wie Hadoop und Storm mit Kompatibilitätspaketen geschrieben wurden.

Einer der größten Nachteile von Flink ist derzeit, dass es sich um ein noch sehr junges Projekt handelt. Großeinsatz in freier Wildbahn ist immer noch nicht so verbreitet wie bei anderen Verarbeitungs-Frameworks, und die Skalierungsbeschränkungen von Flink wurden nicht eingehend untersucht. Mit dem schnellen Entwicklungszyklus und Funktionen wie den Kompatibilitätspaketen gibt es möglicherweise mehr Flink-Bereitstellungen, da Unternehmen die Möglichkeit haben, damit zu experimentieren.

Flink bietet sowohl Stream-Verarbeitung mit geringer Latenz als auch Unterstützung für herkömmliche Batch-Aufgaben. Flink ist wahrscheinlich am besten für Unternehmen geeignet, die hohe Anforderungen an die Stream-Verarbeitung und einige stapelorientierte Aufgaben haben. Die Kompatibilität mit nativen Storm- und Hadoop-Programmen und die Fähigkeit, auf einem YARN-verwalteten Cluster ausgeführt zu werden, können die Evaluierung vereinfachen. Aufgrund seiner rasanten Entwicklung lohnt es sich, ein Auge darauf zu werfen.