Apache Beam vs Spark 2026: Unified Pipelines und Interviewfragen im Vergleich

Apache Beam vs Spark gehört zu den häufigsten Architekturentscheidungen im modernen Data Engineering. Beam 2.76 (August 2026) und Spark 4.2 (Juli 2026) verarbeiten beide Batch- und Streaming-Workloads, unterscheiden sich jedoch grundlegend in ihrer Designphilosophie: Beam abstrahiert die Execution Engine, während Spark eine eng integrierte Runtime bereitstellt.

Beams Portabilitätsmodell vs Sparks Unified Engine

Apache Beam trennt das Programmiermodell von der Ausführung. Eine einzelne Pipeline-Definition läuft auf Google Cloud Dataflow, Apache Flink, Apache Spark oder anderen Runnern ohne Codeänderungen. Diese Abstraktion entsteht durch das Beam SDK, das eine portable Pipeline-Repräsentation generiert, die jeder kompatible Runner interpretiert.

Spark 4.2 verfolgt den entgegengesetzten Ansatz. Die DataFrame API, Structured Streaming und MLlib teilen sich denselben Catalyst Optimizer und die Tungsten Execution Engine. Diese enge Kopplung ermöglicht Optimierungen wie Adaptive Query Execution, die Pläne zur Laufzeit basierend auf tatsächlichen Datenstatistiken anpassen.

# beam_pipeline.py
import apache_beam as beam
from apache_beam.options.pipeline_options import PipelineOptions

# Same code runs on Dataflow, Flink, or Spark runner
options = PipelineOptions([
    '--runner=DataflowRunner',  # Switch to FlinkRunner or SparkRunner
    '--project=my-project',
    '--region=us-central1',
    '--temp_location=gs://my-bucket/temp'
])

with beam.Pipeline(options=options) as pipeline:
    (pipeline
     | 'ReadEvents' >> beam.io.ReadFromPubSub(topic='projects/p/topics/events')
     | 'ParseJSON' >> beam.Map(lambda x: json.loads(x))
     | 'FilterValid' >> beam.Filter(lambda e: e.get('status') == 'valid')
     | 'WindowByMinute' >> beam.WindowInto(beam.window.FixedWindows(60))
     | 'CountPerWindow' >> beam.combiners.Count.Globally()
     | 'WriteToBQ' >> beam.io.WriteToBigQuery('project:dataset.table'))

Das Spark-Äquivalent bindet direkt an die Spark-Runtime:

# spark_streaming.py
from pyspark.sql import SparkSession
from pyspark.sql.functions import from_json, col, window

spark = SparkSession.builder \
    .appName("EventProcessing") \
    .config("spark.sql.adaptive.enabled", "true") \
    .getOrCreate()

# Spark 4.2: ANSI mode enabled by default, stricter type checking
events = spark.readStream \
    .format("kafka") \
    .option("kafka.bootstrap.servers", "broker:9092") \
    .option("subscribe", "events") \
    .load()

processed = events \
    .select(from_json(col("value").cast("string"), schema).alias("data")) \
    .filter(col("data.status") == "valid") \
    .groupBy(window(col("data.timestamp"), "1 minute")) \
    .count()

processed.writeStream \
    .format("bigquery") \
    .option("table", "project.dataset.table") \
    .outputMode("append") \
    .start()

Beams Portabilität ermöglicht Cloud-agnostische Architekturen, fügt aber eine Übersetzungsschicht hinzu. Sparks direkte Ausführung zeigt typischerweise geringere Latenz für äquivalente Operationen auf derselben Hardware.

Windowing und Event-Time-Verarbeitung im Vergleich

Beide Frameworks verarbeiten Event-Time-Semantik, aber ihre APIs spiegeln unterschiedliche Hintergründe wider. Beams Windowing-Modell stammt aus dem Dataflow Model Paper (2015) und behandelt Windows als erstklassige Pipeline-Elemente. Spark adaptierte sein Windowing für Structured Streaming und integrierte es in die DataFrame API.

Session Windows zeigen den Unterschied am deutlichsten. Beam behandelt Sessions als native Windowing-Strategie:

# beam_sessions.py
from apache_beam import window

# 30-minute session gap, allow 1 hour late data
windowed = (
    events
    | 'SessionWindow' >> beam.WindowInto(
        window.Sessions(30 * 60),  # 30 min gap closes session
        trigger=beam.trigger.AfterWatermark(
            early=beam.trigger.AfterProcessingTime(60),
            late=beam.trigger.AfterCount(1)
        ),
        allowed_lateness=3600,  # Accept data up to 1 hour late
        accumulation_mode=beam.trigger.AccumulationMode.ACCUMULATING
    )
)

Spark erfordert Stateful Processing für Sessions:

# spark_sessions.py
from pyspark.sql.streaming import GroupState, GroupStateTimeout

def update_session(key, events, state: GroupState):
    # Manual session management with state API
    session_data = state.getOption() or {"count": 0, "start": None, "end": None}
    
    for event in events:
        ts = event.timestamp
        if session_data["end"] and (ts - session_data["end"]).seconds > 1800:
            # Gap exceeded 30 min, emit previous session
            yield session_data
            session_data = {"count": 0, "start": ts, "end": ts}
        
        session_data["count"] += 1
        session_data["end"] = ts
        if not session_data["start"]:
            session_data["start"] = ts
    
    state.update(session_data)
    state.setTimeoutDuration(30 * 60 * 1000)  # 30 min timeout

# Spark 4.2 Arbitrary State API v2
result = events \
    .groupByKey(lambda e: e.user_id) \
    .flatMapGroupsWithState(
        update_session,
        outputMode="append",
        stateType=session_schema,
        timeoutConf=GroupStateTimeout.ProcessingTimeTimeout
    )

Für die Interviewvorbereitung zu diesen Themen bietet das Apache Beam und Dataflow Interviewfragen Modul umfassende Übungen.

Performance: Benchmark-Daten aus 2026

Direkte Vergleiche erfordern sorgfältiges Setup, da Beam auf Spark als Runner-Option laufen kann. Der relevante Vergleich ist Beam-auf-Dataflow vs natives Spark.

Aktuelle Benchmarks von Databricks und Google Cloud zeigen:

Spark 4.2s Performance-Verbesserungen stammen aus mehreren Features:

• ANSI-Modus standardmäßig: strengere SQL-Semantik erkennt Fehler früher
• VARIANT-Datentyp: natives Handling semi-strukturierter Daten
• Adaptive Query Execution: Runtime-Planoptimierung
• Java 21 Support: Virtual Threads reduzieren Overhead

Beam 2.76 kontert mit:

• Flink 2.0 Runner Support: produktionsreifes Stateful Streaming
• CDC Offset Persistence: DebeziumIO FileSystemOffsetRetainer
• ADK Integration: Google Agent Development Kit Support im Python SDK

Häufige Interviewfragen: Beam vs Spark

Technische Interviews für Data Engineering Rollen vergleichen häufig diese Frameworks. Hier sind Fragen aus 2026er Interviews mit erwarteter Antworttiefe.

Q1: Wann würde man Beam gegenüber nativem Spark wählen?

Erwartete Antwortpunkte:

• Multi-Cloud oder Hybrid-Deployments, bei denen Pipeline-Code unverändert laufen muss
• Google Cloud Umgebungen, wo Dataflow verwaltete Infrastruktur bereitstellt
• Komplexe Event-Time-Semantik mit Session Windows oder Custom Triggers
• Teams mit bestehender Beam-Expertise aus Dataflow-Hintergrund

Red Flag Antwort: "Beam ist immer besser, weil es portabel ist." Portabilität hat Overhead-Kosten.

Q2: Wie beeinflusst Beams Runner-Abstraktion das Debugging?

Erwartete Antwortpunkte:

• Stack Traces referenzieren sowohl Beam SDK als auch Runner-Implementierung
• Runner-spezifische Optimierungen können sich unterschiedlich verhalten (Flink Checkpoints vs Spark Checkpoints)
• Metrics API bietet einheitliches Monitoring, aber Runner-Dashboards zeigen unterschiedliche Details
• Testing mit DirectRunner vor Deployment zum Produktions-Runner

Q3: Exactly-once Semantik in beiden Frameworks erklären.

Erwartete Antwort:

# Beam: exactly-once via runner guarantees
# Dataflow provides exactly-once for both sources and sinks
# The SDK handles deduplication and checkpoint coordination

with beam.Pipeline() as p:
    (p
     | beam.io.ReadFromPubSub(subscription='...')  # Exactly-once read
     | beam.Map(process)
     | beam.io.WriteToBigQuery(...)  # Exactly-once write with retries
    )

# Spark: exactly-once via checkpointing and idempotent sinks
spark.readStream \
    .format("kafka") \
    .load() \
    .writeStream \
    .option("checkpointLocation", "/checkpoint")  # State recovery
    .foreachBatch(idempotent_write)  # Application-level deduplication
    .start()

Für weitere Streaming-Interviewthemen bietet das PySpark Modul umfassende Vorbereitung.

Q4: Wie würde man einen Spark Batch Job nach Beam migrieren?

Diese Frage testet das Verständnis beider APIs. Kernpunkte:

1. DataFrame-Operationen auf PCollections und Transforms abbilden
2. spark.read durch entsprechende Beam I/O Connectors ersetzen
3. UDFs zu beam.Map oder beam.ParDo Funktionen konvertieren
4. Partitionierung anders handhaben (Beams Reshuffle vs Sparks repartition)
5. Mit DirectRunner testen vor Deployment zum Produktions-Runner

Das richtige Tool wählen: Entscheidungsmatrix

Die Wahl hängt mehr vom organisatorischen Kontext ab als von technischen Fähigkeiten. Beide Frameworks bewältigen die meisten Data Engineering Workloads kompetent.

Für ETL/ELT Pattern-Entscheidungen sollten Datenvolumen und Latenzanforderungen vor der Framework-Auswahl berücksichtigt werden.

Praxis-Architektur: Hybrider Ansatz

Viele Organisationen nutzen beide Frameworks. Ein gängiges Pattern:

[Streaming Ingestion]     [Batch Processing]     [ML Training]
        |                        |                    |
   Beam/Dataflow           Spark on Databricks    Spark MLlib
        |                        |                    |
        v                        v                    v
    BigQuery  <----- dbt -----> Delta Lake -----> Model Registry

Beam übernimmt Streaming Ingestion, wo Dataflows Autoscaling zu Traffic-Patterns passt. Spark verarbeitet Batch-Workloads, wo Cluster-Ökonomie nachhaltiges Compute begünstigt. Beide speisen in ein einheitliches Data Warehouse.

Diese Architektur erscheint im Apache Spark Tutorial mit Implementierungsdetails.

Kernpunkte für die Beam vs Spark Entscheidung

• Beam 2.76 bietet Runner-Portabilität über Dataflow, Flink 2.0 und Spark, tauscht dabei Performance gegen Deployment-Flexibilität
• Spark 4.2 liefert engere Integration zwischen SQL, Streaming und ML-Workloads mit Features wie VARIANT-Typen und Adaptive Query Execution
• Session Windows und komplexe Trigger begünstigen Beams natives Windowing-Modell
• Batch-Performance auf äquivalenter Hardware favorisiert typischerweise Spark durch Catalyst/Tungsten-Optimierung
• Interviewfragen fokussieren auf Trade-offs statt ein Framework als überlegen zu deklarieren
• Hybride Architekturen mit beiden Frameworks sind in Produktionsumgebungen üblich
• Kostenvergleich hängt von Workload-Patterns ab: Dataflows Per-GB-Pricing vs Spark Cluster-Provisionierung