Apache Beam: ein Pipeline-Modell, sieben Runner, drei SDKs
Apache Beam ist ein einheitliches Programmiermodell für die Batch- und Streaming-Datenverarbeitung.
Auf einen Blick
- Was ist das?
- Apache Beam definiert Batch- und Streaming-Verarbeitung in einem gemeinsamen Modell aus PCollection, PTransform und Pipeline und lässt dieselbe Pipeline über Runner auf Flink, Spark, Dataflow, Hazelcast Jet oder Twister2 laufen. Der Text ordnet Modellherkunft, Runner-Auswahl, SDK-Umfang und die dokumentarischen Lücken ein.
- Für wen ist es gedacht?
- Geeignet ist Beam für Teams, die eine Pipeline einmal beschreiben und auf mehreren Ausführungs-Backends betreiben wollen, oder die zwischen Batch und Streaming nicht zwei Codebasen pflegen möchten. Weniger geeignet ist es für Vorhaben, die auf Sonderfunktionen eines einzelnen Systems angewiesen sind, weil das Modell nur weitergibt, was es selbst ausdrücken kann.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Java, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Was das Beam-Modell aus MapReduce, FlumeJava und Millwheel gemacht hat
Beam beschreibt sich als einheitliches Modell, um Pipelines für Batch und für Streaming zu definieren, ergänzt um sprachspezifische SDKs zum Bauen dieser Pipelines und um Runner, die sie auf verteilten Backends ausführen. Genannt werden Apache Flink, Apache Spark, Google Cloud Dataflow und Hazelcast Jet. Das Repository apache/beam führt Java als Hauptsprache, steht unter Apache-2.0 und entwickelt auf dem Branch master.
Die Herkunft des Modells ist ungewöhnlich gut belegt. Es entstand laut README aus mehreren internen Google-Projekten, namentlich MapReduce, FlumeJava und Millwheel, und trug zunächst den Namen Dataflow Model. Wer die Grundlagen nachlesen will, findet im README Verweise auf die Beiträge Streaming 101 und Streaming 102 sowie auf das VLDB-Papier von 2015. Diese Fußnoten sind mehr als Beiwerk: Sie erklären, warum Begriffe wie Watermark und Fensterung im Modell eine eigene Rolle spielen.
Zum Stand der Veröffentlichung: Der letzte aufgezeichnete Push stammt vom 11. August 2026, verknüpft mit dem Tag v2.76.0-RC4. Das jüngste abgeschlossene Release ist v2.75.0 vom 8. Juli 2026, davor liegt v2.74.0 vom 22. Mai 2026. Wer eine stabile Linie sucht, sollte sich an 2.75.0 halten und den Release-Candidate nicht in Produktion nehmen.
PCollection, PTransform, Pipeline und PipelineRunner im Zusammenspiel
Vier Begriffe tragen das Modell, und sie sind im README sauber getrennt. PCollection steht für eine Datenmenge, die begrenzt oder unbegrenzt sein kann. Genau diese Unterscheidung erlaubt es, denselben Code als Batch-Lauf über einen festen Bestand oder als Streaming-Lauf über eine offene Quelle zu betreiben.
PTransform bezeichnet die Umwandlung, die aus Eingabe-PCollections Ausgabe-PCollections macht. Pipeline verwaltet den gerichteten azyklischen Graphen aus PTransforms und PCollections und hält ihn ausführungsbereit. PipelineRunner legt fest, wo und wie die Pipeline anschließend läuft.
Die Trennung von Aufbau und Ausführung ist der Punkt, an dem Beam seinen Nutzen verdient. Der Graph wird zunächst nur beschrieben, die Entscheidung über das Backend fällt am Ende und bleibt damit änderbar. Für den Einstieg nennt das README ein minimales WordCount-Beispiel im Repository sowie Schnellstarts für Java, Python und Go. Als Begriffe, die man vor dem ersten eigenen Graphen verstanden haben sollte, listet es PCollection, PTransform und Pipeline.
DirectRunner, FlinkRunner, DataflowRunner: sieben Wege zur Ausführung
Die Runner-Liste im README umfasst sieben Einträge. DirectRunner führt die Pipeline auf der lokalen Maschine aus, PrismRunner ebenfalls lokal, aber über Beam Portability. DataflowRunner übergibt an Google Cloud Dataflow. FlinkRunner arbeitet auf einem Apache-Flink-Cluster, SparkRunner auf Apache Spark, JetRunner auf einem Hazelcast-Jet-Cluster und Twister2Runner auf Twister2.
Drei dieser Runner sind zugekauftes Erbe, und das README sagt das offen: FlinkRunner stammt aus dataArtisans/flink-dataflow, JetRunner aus hazelcast/hazelcast-jet, Twister2Runner aus DSC-SPIDAL/twister2. Für die Einschätzung der Pflegequalität ist das ein nützlicher Hinweis, denn ein gespendeter Runner bringt seine eigene Geschichte mit. Neue Vorschläge werden über das Label runner-ideas im Issue-Tracker gesammelt.
Praktisch folgt daraus eine Reihenfolge. Entwickelt wird gegen DirectRunner oder PrismRunner, ausgerollt wird gegen den Runner des Zielsystems. Ob ein Runner den vollen Funktionsumfang des Modells abbildet, steht im Material nicht; die README nennt keine Fähigkeitsmatrix. Wer auf einem dieser Backends plant, sollte diese Frage vor der Architekturentscheidung im jeweiligen Runner-Kapitel der Dokumentation klären.
Java, Python und Go: die SDKs im Verzeichnis sdks/
Im Repository liegen SDKs für Java, Python und Go. Für Python gibt es ein eigenes README unter sdks/python/README.md, das deutlich weiter ins Detail geht als die Datei im Wurzelverzeichnis. Wer mit Python arbeitet, sollte deshalb diese Datei und nicht die Kurzfassung oben lesen. Vorschläge für weitere SDKs oder domänenspezifische Sprachen sammelt das Projekt unter dem Label sdk-ideas.
Aus dem Python-README kommen mehrere Besonderheiten. Da Python dynamisch typisiert ist, nutzt das SDK Typ-Hinweise während des Aufbaus und der Ausführung, um statische Typisierung nachzubilden. Bei entfernt ausgeführten Pipelines müssen die Abhängigkeiten auf den fernen Workern verfügbar sein, wofür das Projekt einen eigenen Leitfaden bereithält. Python-Streaming-Pipelines sind ab Version 2.5.0 des SDK möglich, mit Einschränkungen, die in der Dokumentation aufgeführt sind. Mehrsprachige Pipelines erlauben es, Umwandlungen aus verschiedenen SDKs zu kombinieren.
Für maschinelle Inferenz nennt das Material die RunInference-API mit Unterstützung für PyTorch und Scikit-learn. TensorFlow-Modelle laufen über eine getrennte Bibliothek namens tfx_bsl. Wer Inferenz in eine Pipeline einbauen will, hat damit einen dokumentierten Weg, sollte aber prüfen, ob das eigene Modellformat abgedeckt ist.
Endnutzer, SDK-Autoren und Runner-Autoren: drei Zielgruppen
Das README unterscheidet drei Gruppen, die Beam ansprechen will, und diese Aufteilung erklärt so manche Designentscheidung. Endnutzer schreiben Pipelines mit einem bestehenden SDK und lassen sie auf einem bestehenden Runner laufen; sie sollen sich auf Anwendungslogik konzentrieren können. SDK-Autoren entwickeln ein SDK für eine Sprachgemeinschaft und wollen von den Einzelheiten der Runner abgeschirmt sein. Runner-Autoren bringen eine Ausführungsumgebung mit und möchten Programme gegen das Beam-Modell unterstützen, ohne jedes SDK im Detail zu kennen.
Beam ist also bewusst als Schnittstelle zwischen zwei Seiten gebaut, nicht als fertiges Datenbanksystem. Das hat eine Folge: Die Funktionstiefe, die am Ende zur Verfügung steht, ist die des gewählten Runners, und das Modell gibt nur weiter, was es selbst ausdrücken kann.
Eingeschränkt wird der Anspruch bereits im README selbst. Beam adressiert laut eigener Beschreibung Pipelines, die sich gut parallelisieren lassen. Für Arbeitslasten mit engen Kopplungen zwischen den Elementen hält das Modell keine Antwort bereit.
Was im Material fehlt: Installationsbefehl und Verhaltenskodex
Ein Punkt fällt beim Lesen auf, und er ist für die Praxis nicht nebensächlich. Das README im Wurzelverzeichnis enthält keinen Installationsbefehl. Es verweist stattdessen auf die Schnellstarts für Java, Python und Go unter beam.apache.org sowie auf die Anleitung im Python-SDK. Wer erwartet, hier eine Paketzeile zum Kopieren zu finden, wird stattdessen auf die Dokumentation verwiesen.
Ebenso fehlt eine Fähigkeitsmatrix der Runner. Welche Umwandlung auf welchem Backend vollständig unterstützt wird, sagt das Material nicht. Das ist bei sieben Runnern mit teils gespendetem Code eine spürbare Lücke, und sie verschiebt die Klärung in die Dokumentation des jeweiligen Ziels.
Zur Projektorganisation nennt das README Wege zur Beteiligung: die Mailinglisten user@ und dev@, der Kanal #beam im ASF-Slack und der Issue-Tracker auf GitHub. Ein Verhaltenskodex oder Angaben zur Governance stehen nicht darin; in der Dokumentation nicht angegeben. Build- und Testanleitungen für Beam selbst liegen in der Datei CONTRIBUTING.md.
Beam gegen die direkte Flink- oder Spark-Programmierung
Die nächstliegende Alternative ist, unmittelbar gegen das Zielsystem zu programmieren, also Flink oder Spark ohne Zwischenschicht. Der Unterschied liegt im Grad der Bindung. Wer direkt gegen Flink schreibt, erreicht jede Funktion des Systems, ohne auf die Ausdrucksfähigkeit eines Modells Rücksicht nehmen zu müssen, und verliert beim Wechsel des Backends den gesamten Code. Wer Beam dazwischen schaltet, gewinnt die Freiheit, denselben Graphen auf einem anderen Runner zu starten, und bezahlt mit der Beschränkung auf die Begriffe des Modells.
Diese Rechnung geht auf, wenn ein Wechsel des Ausführungs-Backends wahrscheinlich ist oder wenn Batch und Streaming aus einer Quelle bedient werden sollen. Sie geht nicht auf, wenn eine Pipeline ohnehin für Jahre auf einem System bleibt und dort Spezialfunktionen braucht, die über PTransform hinausgehen.
Als falsches Werkzeug ist Beam dort zu nennen, wo die Arbeit nicht parallelisierbar ist, weil das README den Anspruch selbst auf gut parallelisierbare Pipelines begrenzt. Ein zweiter Fall ist ein Team, das nur ein einziges Backend einsetzt und dessen native API bereits beherrscht; dort bringt die zusätzliche Schicht vorerst nichts.
Redaktionelles Fazit
Geeignet ist Beam für Teams, die eine Pipeline einmal beschreiben und auf mehreren Ausführungs-Backends betreiben wollen, oder die zwischen Batch und Streaming nicht zwei Codebasen pflegen möchten. Weniger geeignet ist es für Vorhaben, die auf Sonderfunktionen eines einzelnen Systems angewiesen sind, weil das Modell nur weitergibt, was es selbst ausdrücken kann. Vor dem Einstieg sollte dieselbe Pipeline mit dem DirectRunner lokal und danach mit dem eigentlich vorgesehenen Runner laufen, weil sich daran zeigt, welche Teile der Logik der Ziel-Runner wirklich trägt; ob das eigene Backend überhaupt vorkommt, klärt ein Blick in die Runner-Liste des Repositories.
Community-Notizen