Streaming vs Batch Processing: Wann was

Dein Fraud-Detection-Model feuert 90 Sekunden nach Abschluss der Transaktion. Bis dahin ist das Geld weg. Das ist das falsche Processing-Modell für den falschen Use-Case — und ein Fehler, der häufiger passiert, als du denkst.

Die Wahl zwischen Streaming und Batch ist nicht, welches technisch überlegen ist. Es geht darum, das Modell zur Latenz-Anforderung deines Use-Cases zu matchen. Klares Framework dafür:

TL;DR

Was ist Batch Processing?

Batch sammelt Daten über einen Zeitraum — Stunde, Tag, Woche — und verarbeitet sie auf einmal. Das Paradigma ist einfach: bounded Dataset lesen, transformieren, Ergebnis schreiben.

Die meisten Data-Warehouses sind auf Batch gebaut. Dein nightly dbt-Run, deine wöchentliche Reporting-Pipeline, dein monatlicher ML-Retraining-Job — alles Batch.

# PySpark Batch-Job — tägliche Aggregation
from pyspark.sql import SparkSession
from pyspark.sql.functions import col, sum as spark_sum, to_date

spark = SparkSession.builder.appName("daily_orders").getOrCreate()

df = spark.read.parquet("s3://datalake/orders/date=2024-01-15/")

daily_summary = (
    df
    .groupBy(to_date(col("created_at")).alias("order_date"), col("region"))
    .agg(
        spark_sum("amount").alias("total_revenue"),
        spark_sum(col("amount") > 0).cast("long").alias("order_count")
    )
)

daily_summary.write.mode("overwrite").parquet("s3://datalake/daily_order_summary/date=2024-01-15/")

Batch ist der richtige Default. Operativ einfacher, billiger im Betrieb, leichter zu debuggen. Die Frage: kann dein Use-Case die Latenz tolerieren?

Was ist Streaming Processing?

Streaming behandelt Daten als unbounded, kontinuierlichen Flow. Jedes Event wird beim Eintreffen verarbeitet — oder in einem konfigurierbaren Time-Window.

Das Latenz-Profil ist fundamental anders: statt "wir wissen es in 6 Stunden" bist du im Bereich Millisekunden bis wenige Sekunden.

# PySpark Structured Streaming — Real-Time Kafka-Consumer
from pyspark.sql import SparkSession
from pyspark.sql.functions import from_json, col, window
from pyspark.sql.types import StructType, StringType, DoubleType, TimestampType

spark = SparkSession.builder.appName("fraud_alerts").getOrCreate()

schema = StructType() \
    .add("transaction_id", StringType()) \
    .add("user_id", StringType()) \
    .add("amount", DoubleType()) \
    .add("event_time", TimestampType())

raw = (
    spark.readStream
    .format("kafka")
    .option("kafka.bootstrap.servers", "broker:9092")
    .option("subscribe", "transactions")
    .load()
)

transactions = raw.select(from_json(col("value").cast("string"), schema).alias("data")).select("data.*")

# 5-Minuten-Tumbling-Window — User über $10k flaggen
windowed = (
    transactions
    .withWatermark("event_time", "10 minutes")
    .groupBy(col("user_id"), window(col("event_time"), "5 minutes"))
    .sum("amount")
    .filter(col("sum(amount)") > 10000)
)

query = (
    windowed.writeStream
    .format("kafka")
    .option("kafka.bootstrap.servers", "broker:9092")
    .option("topic", "fraud_alerts")
    .option("checkpointLocation", "/checkpoints/fraud_alerts")
    .outputMode("append")
    .start()
)
query.awaitTermination()

Die drei wichtigsten Frameworks im Vergleich

Apache Kafka

Kafka ist kein Stream-Processor — es ist verteilter Event-Log und Message-Broker. Die Ingestion-Schicht: Events werden zu Kafka-Topics produziert, und Downstream-Consumer (Flink, Spark, eigene Apps) lesen davon.

Was Kafka gut macht:

• Durable, replayable Event-Storage (konfigurierbare Retention)
• High-Throughput Ingestion (Millionen Events/Sek)
• Decoupling von Producern und Consumern
• Exactly-Once Delivery (mit Kafka Streams oder transaktionalen Producern)

Was Kafka nicht ist:

• Full Stream-Processor (kein Windowed Aggregation, kein SQL-Join out of the box ohne Kafka Streams/ksqlDB)
• Eine Datenbank (Topic-Retention ist zeitbasiert, nicht query-optimiert)

Kafka ist das Fundament. Fast jede Production-Streaming-Architektur startet hier.

Spark Structured Streaming

Spark Structured Streaming ist Micro-Batch unter der Haube. Verarbeitet Daten in kleinen Intervallen (konfigurierbar bis ~100 ms mit Continuous-Processing).

Stärken:

• Gleiche DataFrame/SQL-API wie Batch-Spark — niedrige Lernkurve für Spark-Teams
• Enge Integration mit Delta Lake (Streaming-Writes, MERGE)
• Starkes Ökosystem: MLlib, GraphX, Delta Live Tables
• Läuft gut auf Databricks, EMR, GCP Dataproc

Schwächen:

• Echte Sub-Second-Latenz schwer verlässlich zu erreichen
• Stateful Operations (Joins, Aggregationen) brauchen sorgfältiges Watermark-Tuning
• Operative Komplexität deutlich höher als Batch

Guter Fit, wenn dein Team Spark für Batch nutzt und du "Near-Real-Time" (Sekunden bis Minuten) brauchst.

Apache Flink

Flink ist ein echter Stream-Processor — verarbeitet Events einzeln, nicht in Micro-Batches. Vom ersten Tag für Streaming gebaut.

Stärken:

• Echtes Event-Time-Processing mit niedriger, vorhersagbarer Latenz
• Anspruchsvolle Stateful Operations (Session-Windows, Complex Event Processing)
• Exactly-Once-Garantien mit minimalem Overhead
• SQL-API (Table API) und Java/Python DataStream-API

Schwächen:

• Steilere Lernkurve als Spark
• Kleineres Ökosystem und Community als Spark
• Operative Komplexität (JobManager, TaskManagers, Checkpointing)

Guter Fit für genuine Low-Latency (sub-sekunde), komplexe Event-Driven Logic oder Event-Driven Microservices.

-- Flink SQL — Tumbling-Window-Aggregation
CREATE TABLE transactions (
    transaction_id STRING,
    user_id STRING,
    amount DOUBLE,
    event_time TIMESTAMP(3),
    WATERMARK FOR event_time AS event_time - INTERVAL '5' SECOND
) WITH (
    'connector' = 'kafka',
    'topic' = 'transactions',
    'properties.bootstrap.servers' = 'broker:9092',
    'format' = 'json'
);

SELECT
    user_id,
    TUMBLE_START(event_time, INTERVAL '5' MINUTE) AS window_start,
    SUM(amount) AS total_amount,
    COUNT(*) AS tx_count
FROM transactions
GROUP BY user_id, TUMBLE(event_time, INTERVAL '5' MINUTE);

Framework-Vergleich

Wann Streaming wählen

Streaming ist richtig, wenn:

• Latenz < 1 Minute Business-Anforderung ist (Fraud, Alerting, Live-Dashboards)
• Downstream-Systeme auf Events reagieren müssen (Workflows triggern, User-State updaten, Microservices powern)
• Daten-Volumen Full-Reprocessing unpraktisch macht (du kannst 1 TB/Tag nicht jedes Mal neu lesen)
• Stateful Per-User-Tracking in Real-Time nötig ist (Session-Tracking, Live-Recommendation-Updates)

Wann Batch wählen

Batch ist richtig, wenn:

• Reports und Dashboards T+1 oder T+wenige Stunden Frische tolerieren (die meiste BI)
• ML-Modell-Training — Modelle brauchen volle Dataset-Passes, keine inkrementellen Event-by-Event-Updates
• Komplexe Transformationen und Joins, die genuin einfacher über bounded Datasets sind
• Kosten ein Constraint sind — Always-on Flink/Kafka ist teuer
• Dein Team klein ist — Streaming verdoppelt operativen Overhead

Ehrliche Wahrheit: das meiste Data-Engineering ist Batch. Die große Mehrheit von Dashboards, Reports und analytischen Pipelines braucht keine Sub-Minute-Frische. Default Batch, Streaming nur dort, wo Latenz-Anforderung es echt verlangt.

Lambda vs Kappa Architektur

Zwei Patterns für die Kombination:

Lambda: Separater Batch-Layer (präzise, verzögert) + Speed-Layer (approximativ, frisch). Ergebnisse zur Query-Zeit gemerged. Operativ schmerzhaft — zwei Codebases.

Kappa: Eine Streaming-Pipeline, die Real-Time und historisches Reprocessing per Event-Log-Replay handhabt. Operativ einfacher, braucht aber durables Event-Log (Kafka mit langer Retention oder Iceberg-backed Storage).

Moderne Teams bevorzugen meist Kappa, wenn sie sich Streaming verpflichten — Lambda-Komplexität zahlt sich selten aus.

Häufige Stolperfallen

1. Operativen Overhead unterschätzen. Ein Kafka + Flink Stack braucht Consumer-Lag-Monitoring, Checkpoint-Management, Rebalance-Handling, Stateful-Failure-Debugging. Plane dafür.

2. Late Data ignorieren. Events kommen spät an. Immer. Watermarks in Flink und Spark definieren, wie lange du wartest — zu eng setzt Daten weg, zu locker erhöht Latenz. Kein Free-Lunch.

3. Für zukünftige Anforderungen überbauen. "Wir brauchen vielleicht mal Real-Time" ist kein Grund, heute Streaming zu bauen. Batch ist drastisch leichter zu pflegen und debuggen.

4. Kafka mit Stream-Processing verwechseln. Kafka bewegt Daten; es transformiert sie nicht. Wenn du komplexe Aggregationen in Kafka-Consumern ohne Kafka Streams oder ksqlDB machst, baust du versehentlich einen Stream-Processor.

Praktisches Entscheidungs-Framework

Brauchst du Ergebnisse in < 1 Minute?
├── Nein -> Batch. Fertig.
└── Ja   -> Brauchst du Sub-Second-Latenz?
          ├── Nein -> Spark Structured Streaming (einfacher, Spark-Teams)
          └── Ja   -> Apache Flink (echtes Streaming, mehr Komplexität)

Wenn du Streaming-Event-Daten erkundest oder Ad-hoc-Queries gegen ingestierten Kafka-Output brauchst, lässt dich Harbinger Explorer Result-Datasets direkt im Browser mit DuckDB WASM abfragen — nützlich für Window-Aggregations-Validierung oder Spot-Checks von Event-Verteilungen, ohne einen weiteren Spark-Cluster aufzubauen. Die AI-Natural-Language-Query-Schicht ist besonders praktisch für explorative Analyse von Streaming-Outputs in Object-Storage.

FAQ

Reicht Spark Structured Streaming, oder brauche ich Flink? Wenn du Sekunden-Latenz tolerieren kannst und schon Spark nutzt: Spark. Wenn du echte Sub-Second oder komplexe Stateful Logic brauchst: Flink.

Wie viel kostet ein Streaming-Stack? Selbst gehostet: ab ~2.000 €/Monat Compute. Managed (Confluent + Databricks Streaming): ab ~5.000 €/Monat ohne Ops.

Brauche ich Kafka, oder reicht Kinesis/PubSub? Funktional ähnlich. Kafka hat das stärkste Ökosystem; Cloud-Varianten reduzieren Ops bei AWS/GCP-only.

DACH-Streaming-Hosting? Confluent Cloud, AWS MSK, Aiven für Kafka — alle mit EU-Regionen. AVV verfügbar.

Wann lohnt sich Real-Time wirklich? Wenn Latenz direkt Business-Value beeinflusst (Fraud, Trading, Operationelles Monitoring). Sonst ist Batch fast immer kostengünstiger.

Fazit

Streaming ist mächtig und manchmal genuin nötig. Aber es kommt mit echten operativen Kosten, die Batch nicht hat. Kenne deine Latenz-Anforderung vor der Architektur-Wahl — nicht danach.

Für die meisten Teams: mit Batch starten, SLAs monitoren und Streaming chirurgisch dort einführen, wo die Latenz-Lücke wirklich weh tut.

Nächster Schritt: Wenn du heute Batch-Pipelines laufen hast, Airflow vs Dagster vs Prefect lesen, um sicherzustellen, dass deine Orchestration den Übergang trägt.

Weiterlesen

• ETL vs ELT: Welcher Ansatz passt zu deinem Stack?
• Delta Live Tables vs Classic ETL
• Data Pipeline Monitoring

Stand: 14. Mai 2026.