Was sind die Vorteile von Apache Beam gegenüber Spark / Flink für die Stapelverarbeitung?

Apache Beam unterstützt mehrere Runner-Backends, einschließlich Apache Spark und Flink. Ich bin mit Spark / Flink vertraut und versuche, die Vor- und Nachteile von Beam für die Stapelverarbeitung zu erkennen.

Wenn man sich das Beispiel für die Anzahl der Beam-Wörter ansieht , scheint es den nativen Spark / Flink-Äquivalenten sehr ähnlich zu sein, möglicherweise mit einer etwas ausführlicheren Syntax.

Ich sehe derzeit keinen großen Vorteil darin, Beam für eine solche Aufgabe gegenüber Spark / Flink zu wählen. Die einzigen Beobachtungen, die ich bisher machen kann:

• Pro: Abstraktion über verschiedene Ausführungs-Backends.
• Con: Diese Abstraktion hat den Preis, weniger Kontrolle darüber zu haben, was genau in Spark / Flink ausgeführt wird.

Gibt es bessere Beispiele, die andere Vor- und Nachteile des Beam-Modells hervorheben? Gibt es Informationen darüber, wie sich der Kontrollverlust auf die Leistung auswirkt?

Beachten Sie, dass ich nicht nach Unterschieden bei den Streaming-Aspekten frage , die teilweise in dieser Frage behandelt und in diesem Artikel zusammengefasst werden (aufgrund von Spark 1.X veraltet).

Es gibt ein paar Dinge, die Beam über viele der vorhandenen Motoren hinzufügt.

• Batch und Streaming vereinheitlichen. Viele Systeme können sowohl Batch als auch Streaming verarbeiten, dies geschieht jedoch häufig über separate APIs. In Beam sind Batch und Streaming jedoch nur zwei Punkte in einem Spektrum von Latenz, Vollständigkeit und Kosten. Es gibt kein Lernen / Umschreiben von Klippen vom Batch bis zum Streaming. Wenn Sie also heute eine Batch-Pipeline schreiben, aber morgen Ihre Latenz ändern muss, ist die Anpassung unglaublich einfach. Sie können diese Art von Reise in den Beispielen für Mobile Gaming sehen .

• APIs, die den Abstraktionsgrad erhöhen : Die APIs von Beam konzentrieren sich darauf, die Eigenschaften Ihrer Daten und Ihrer Logik zu erfassen, anstatt Details der zugrunde liegenden Laufzeit durchzulassen. Dies ist sowohl der Schlüssel für die Portabilität (siehe nächster Absatz) als auch kann den Laufzeiten viel Flexibilität bei der Ausführung geben. So etwas wie ParDo Fusion (auch bekannt als Funktionskomposition) ist eine ziemlich grundlegende Optimierung, die die überwiegende Mehrheit der Läufer bereits durchführt. Für einige Läufer werden noch weitere Optimierungen implementiert. Zum Beispiel die Quell-APIs von Beamwurden speziell entwickelt, um eine Überspezifikation des Shards innerhalb einer Pipeline zu vermeiden. Stattdessen geben sie den Läufern die richtigen Haken, um die Arbeit auf den verfügbaren Maschinen dynamisch neu auszugleichen. Dies kann einen großen Unterschied in der Leistung bewirken, indem Straggler-Shards im Wesentlichen eliminiert werden. Im Allgemeinen sind wir umso besser dran, je mehr Intelligenz wir in die Läufer einbauen können. Selbst die sorgfältigste Handoptimierung schlägt fehl, wenn sich Daten, Code und Umgebungen ändern.

• Portabilität über Laufzeiten. : Da Datenformen und Laufzeitanforderungen sauber voneinander getrennt sind, kann dieselbe Pipeline auf mehrere Arten ausgeführt werden. Und das bedeutet, dass Sie den Code nicht neu schreiben müssen, wenn Sie von On-Prem in die Cloud oder von einem bewährten System zu etwas auf dem neuesten Stand wechseln müssen. Sie können Optionen sehr einfach vergleichen, um die Mischung aus Umgebung und Leistung zu finden, die für Ihre aktuellen Anforderungen am besten geeignet ist. Und das könnte eine Mischung aus Dingen sein - vertrauliche Daten vor Ort mit einem Open Source Runner verarbeiten und andere Daten auf einem verwalteten Dienst in der Cloud verarbeiten.

Es ist schwierig, das Beam-Modell als nützliche Abstraktion für viele verschiedene Engines zu entwerfen. Der Strahl ist weder der Schnittpunkt der Funktionalität aller Motoren (zu begrenzt!) Noch der Vereinigung (zu viel Küchenspüle!). Stattdessen versucht Beam, an der Spitze der Datenverarbeitung zu stehen, indem Funktionen in die Laufzeit-Engines integriert und Muster daraus entfernt werden.

• Keyed State ist ein großartiges Beispiel für Funktionen, die in verschiedenen Engines vorhanden waren und interessante und häufig verwendete Anwendungsfälle ermöglichten, in Beam jedoch ursprünglich nicht ausgedrückt werden konnten. Wir haben das Beam-Modell kürzlich um eine Version dieser Funktionalität gemäß den Designprinzipien von Beam erweitert .
• Und umgekehrt hoffen wir, dass Beam auch die Roadmaps verschiedener Motoren beeinflusst. Zum Beispiel wurden die Semantik von Flink die Datenströme beeinflusst durch den Strahl (née Datenfluß - Modell).
• Dies bedeutet auch, dass die Fähigkeiten zu einem bestimmten Zeitpunkt für verschiedene Beam-Läufer nicht immer exakt gleich sind. Deshalb verwenden wir die Fähigkeitsmatrix, um zu versuchen, den Stand der Dinge klar zu kommunizieren.