wake-up-neo.com

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 kenne Spark/Flink und versuche, die Vor- und Nachteile von Beam zu erkennen für die Stapelverarbeitung.

Betrachtet man das Beispiel Anzahl der Wörter übertragen , scheint es den nativen Spark/Flink-Entsprechungen 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 anstelle von Spark/Flink zu wählen. Die einzigen Beobachtungen, die ich bisher machen kann:

  • Pro: Abstraktion über verschiedene Ausführungs-Backends.
  • Con: Diese Abstraktion kostet weniger Kontrolle darüber, 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 diese Frage behandelt und in dieser Artikel zusammengefasst werden (veraltet aufgrund von Spark 1.X).

54
bluenote10

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

  • Vereinheitlichen von Batch und Streaming Viele Systeme können sowohl Batch als auch Streaming verarbeiten, dies geschieht jedoch häufig über separate APIs. Bei Beam sind Batch und Streaming jedoch nur zwei Punkte in Bezug auf Latenz, Vollständigkeit und Kosten. Es gibt kein Lernen/Umschreiben von Cliff von Batch zu Streaming. Wenn Sie heute eine Batch-Pipeline schreiben, aber morgen Ihre Latenzzeit geändert werden muss, ist die Anpassung unglaublich einfach. Sie können diese Art von Reise in den Mobile Gaming Beispielen sehen .

  • APIs, die den Abstraktionsgrad erhöhen : Die APIs von Beam konzentrieren sich auf die Erfassung der Eigenschaften Ihrer Daten und Ihrer Logik, anstatt Details der zugrunde liegenden Laufzeit durchzulassen. Dies ist sowohl für die Portabilität von entscheidender Bedeutung (siehe nächster Absatz) als auch für die Laufzeit sehr flexibel. So etwas wie ParDo Fusion (auch bekannt als Function Composition) ist eine ziemlich grundlegende Optimierung, die die große Mehrheit der Läufer bereits durchführt. Für einige Läufer werden noch weitere Optimierungen durchgeführt. Beams Quell-APIs wurden speziell entwickelt, um eine Überspezifikation der Splitter innerhalb einer Pipeline zu vermeiden. Stattdessen geben sie den Läufern die richtigen Haken, um die Arbeit auf den verfügbaren Maschinen dynamisch auszugleichen. Dies kann einen großen Unterschied in der Leistung bewirken, indem Streunersplitter im Wesentlichen beseitigt werden. Im Allgemeinen gilt: Je mehr Smarts wir in die Läufer einbauen können, desto besser ist es für uns. Selbst die sorgfältigste Handabstimmung schlägt fehl, wenn sich Daten, Code und Umgebungen ändern.

  • Laufzeitübergreifende Portabilität : Da Datenformen und Laufzeitanforderungen sauber voneinander getrennt sind, kann dieselbe Pipeline auf verschiedene Arten ausgeführt werden. Und das bedeutet, dass Sie den Code nicht umschreiben 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 die Optionen sehr einfach vergleichen, um die für Ihre aktuellen Anforderungen am besten geeignete Mischung aus Umgebung und Leistung zu finden. Und das könnte eine Mischung aus Dingen sein - die Verarbeitung sensibler Daten vor Ort mit einem Open Source-Runner und die Verarbeitung anderer Daten auf einem verwalteten Dienst in der Cloud.

Das Beam-Modell so zu gestalten, dass es eine nützliche Abstraktion über viele verschiedene Engines darstellt, ist schwierig. Beam ist weder die Schnittstelle der Funktionalität aller Motoren (zu begrenzt!) Noch die Vereinigung (zu viel von einem Küchenspülbecken!). Stattdessen versucht Beam, an der Spitze der Datenverarbeitung zu stehen, indem Funktionen in die Runtime-Engines übertragen und Muster daraus extrahiert werden.

  • Keyed State ist ein großartiges Beispiel für die Funktionalität, die in verschiedenen Engines vorhanden war und interessante und häufige Anwendungsfälle ermöglichte, aber ursprünglich in Beam nicht ausdrückbar war. Wir haben kürzlich das Beam-Modell erweitert, um eine Version dieser Funktionalität nach Beams Designprinzipien aufzunehmen.
  • Und umgekehrt hoffen wir, dass Beam auch die Roadmaps verschiedener Motoren beeinflusst. Zum Beispiel wurde die Semantik von Flinks DataStreams beeinflusst vom Beam-Modell (geb. Dataflow).
  • Dies bedeutet auch, dass die Fähigkeiten der verschiedenen Beam-Läufer zu einem bestimmten Zeitpunkt nicht immer exakt gleich sind. Deshalb verwenden wir Capability Matrix , um den Zustand der Dinge klar zu kommunizieren.
80
Frances