Apache Spark 4 im Jahr 2026: Neue Features, Structured Streaming und Interview-Fragen

Apache Spark 4 stellt das bedeutendste Upgrade seit der Version 3.0 dar und bringt grundlegende Veraenderungen fuer das gesamte Data-Engineering-Oekosystem. Mit der Einfuehrung des ANSI-SQL-Modus als Standard, dem neuen VARIANT-Datentyp fuer semi-strukturierte Daten und einem voellig ueberarbeiteten Streaming-Framework positioniert sich Spark 4 als zentrale Plattform fuer moderne Datenpipelines. Dieser Artikel analysiert die wichtigsten Neuerungen, demonstriert deren praktische Anwendung anhand konkreter Codebeispiele und bereitet gezielt auf technische Interviewfragen im Bereich Data Engineering vor.

ANSI-SQL-Modus als neuer Standard

Eine der weitreichendsten Aenderungen in Spark 4 betrifft die Aktivierung des ANSI-SQL-Modus als Standardkonfiguration. Waehrend fruehere Versionen bei fehlerhaften Typkonvertierungen stillschweigend NULL-Werte zurueckgaben, wirft Spark 4 nun eine ArithmeticException. Diese Verhaltensaenderung verbessert die Datenqualitaet erheblich, erfordert jedoch eine systematische Migration bestehender Pipelines.

Der Uebergang gelingt am zuverlaessigsten durch den Einsatz von TRY_CAST, das die bisherige NULL-Semantik beibehaltend und gleichzeitig ANSI-konform arbeitet.

# ansi_mode_migration.py
from pyspark.sql import SparkSession
from pyspark.sql.functions import col, try_cast

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

# This now throws ArithmeticException in Spark 4 ANSI mode
# SELECT CAST('abc' AS INT)  -- runtime error

# Safe migration: use TRY_CAST to preserve NULL behavior
df = spark.sql("""
    SELECT
        TRY_CAST(raw_value AS INT) AS parsed_value,
        TRY_CAST(amount AS DECIMAL(10,2)) AS safe_amount
    FROM raw_events
    WHERE TRY_CAST(raw_value AS INT) IS NOT NULL
""")

# Alternatively, wrap arithmetic in try_divide / try_add
result = df.withColumn(
    "ratio",
    col("safe_amount") / col("parsed_value")  # throws on zero
)

Teams, die grosse Codebases migrieren, sollten zunaechst eine vollstaendige Audit-Phase einplanen, in der alle CAST-Ausdruecke identifiziert und durch TRY_CAST ersetzt werden. In der Praxis hat sich bewahrt, den ANSI-Modus zunaechst in Staging-Umgebungen zu aktivieren und die resultierenden Exceptions systematisch zu protokollieren, bevor die Aenderung in Produktion uebernommen wird.

VARIANT-Datentyp fuer semi-strukturierte Daten

Der neue VARIANT-Datentyp loest ein langjaeaehriges Problem in der Spark-Welt: die effiziente Verarbeitung semi-strukturierter Daten wie JSON, Avro oder Protobuf. Bisher erforderte die Arbeit mit verschachtelten JSON-Strukturen entweder aufwaendige Schema-Definitionen oder den Umweg ueber String-Parsing. VARIANT speichert die Daten in einem optimierten Binaerformat mit automatischem Shredding, wodurch Zugriffe auf verschachtelte Felder deutlich schneller ablaufen als bei herkoemmlichem JSON-Parsing.

import org.apache.spark.sql.SparkSession

val spark = SparkSession.builder.appName("VariantDemo").getOrCreate()
import spark.implicits._

// Create a table with VARIANT column
spark.sql("""
    CREATE TABLE events (
        event_id BIGINT,
        timestamp TIMESTAMP,
        payload VARIANT
    ) USING PARQUET
""")

// Insert JSON data — automatically converted to VARIANT
spark.sql("""
    INSERT INTO events VALUES
    (1, current_timestamp(),
     PARSE_JSON('{"user_id": 42, "action": "click", "metadata": {"page": "/home", "duration_ms": 320}}')),
    (2, current_timestamp(),
     PARSE_JSON('{"user_id": 87, "action": "purchase", "metadata": {"item_id": "SKU-9001", "amount": 49.99}}'))
""")

// Query nested fields with dot notation — uses shredding for fast access
val clicks = spark.sql("""
    SELECT
        event_id,
        payload:user_id::INT AS user_id,
        payload:action::STRING AS action,
        payload:metadata.page::STRING AS page
    FROM events
    WHERE payload:action::STRING = 'click'
""")
clicks.show()

Der entscheidende Vorteil von VARIANT gegenueber klassischen STRING-Spalten mit from_json liegt in der Speichereffizienz und Abfragegeschwindigkeit. Durch das automatische Shredding extrahiert Spark haeufig abgefragte Felder in separate Spalten, waehrend seltener benoetigte Daten komprimiert gespeichert bleiben. In Benchmarks zeigt VARIANT eine bis zu 10-fache Beschleunigung bei typischen Abfragen auf verschachtelten JSON-Daten im Vergleich zur String-basierten Verarbeitung.

Fuer Data Engineers bedeutet dies, dass Event-Daten aus Kafka, REST-APIs oder IoT-Geraeten ohne vorherige Schema-Definition direkt in Spark-Tabellen geschrieben und anschliessend mit SQL-Syntax abgefragt werden koennen.

Real-Time Mode Streaming in Spark 4.1

Spark 4.1 fuehrt den Real-Time Mode als neue Streaming-Option ein, der die Verarbeitungslatenz auf unter eine Sekunde senkt. Waehrend das bisherige Micro-Batch-Modell Daten in diskreten Intervallen verarbeitet, operiert der Real-Time Mode kontinuierlich und leitet Ergebnisse sofort an nachgelagerte Systeme weiter.

Die Konfiguration erfolgt ueber den Parameter spark.sql.streaming.mode, der auf realtime gesetzt wird.

# real_time_streaming.py
from pyspark.sql import SparkSession
from pyspark.sql.functions import from_json, col, window
from pyspark.sql.types import StructType, StructField, StringType, DoubleType, TimestampType

spark = SparkSession.builder \
    .appName("RTMDemo") \
    .config("spark.sql.streaming.mode", "realtime") \
    .getOrCreate()

schema = StructType([
    StructField("sensor_id", StringType()),
    StructField("temperature", DoubleType()),
    StructField("event_time", TimestampType())
])

# Read from Kafka with Real-Time Mode enabled
raw_stream = spark.readStream \
    .format("kafka") \
    .option("kafka.bootstrap.servers", "broker:9092") \
    .option("subscribe", "sensor-readings") \
    .option("startingOffsets", "latest") \
    .load()

parsed = raw_stream \
    .select(from_json(col("value").cast("string"), schema).alias("data")) \
    .select("data.*")

# Write to Kafka sink — sub-second end-to-end
query = parsed \
    .filter(col("temperature") > 80.0) \
    .writeStream \
    .format("kafka") \
    .option("kafka.bootstrap.servers", "broker:9092") \
    .option("topic", "alerts") \
    .option("checkpointLocation", "/tmp/checkpoints/alerts") \
    .start()

query.awaitTermination()

Der Real-Time Mode eignet sich besonders fuer Anwendungsfaelle wie Betrugserkennung, Echtzeit-Alerting und operative Dashboards, bei denen jede Sekunde Verzoegerung geschaeftskritische Auswirkungen haben kann. Es ist jedoch zu beachten, dass dieser Modus hoehere Ressourcenanforderungen stellt als das traditionelle Micro-Batch-Modell und daher nur fuer Szenarien eingesetzt werden sollte, in denen die Sub-Sekunden-Latenz tatsaechlich erforderlich ist.

Spark Connect und der leichtgewichtige PySpark-Client

Spark Connect trennt den Client vollstaendig vom Cluster und ermoeglicht die Ausfuehrung von Spark-Operationen ueber eine duenne Client-Bibliothek ohne lokale JVM. Diese Architekturentscheidung vereinfacht die Bereitstellung in containerisierten Umgebungen erheblich, da Entwickler und Data Scientists Spark-Jobs direkt aus Jupyter Notebooks oder CI/CD-Pipelines ausfuehren koennen, ohne eine vollstaendige Spark-Installation auf dem lokalen Rechner zu benoetigen.

# spark_connect_client.py
from pyspark.sql import SparkSession

# Connect to remote Spark cluster — no local JVM needed
spark = SparkSession.builder \
    .remote("sc://spark-cluster.internal:15002") \
    .getOrCreate()

# Full DataFrame API available through thin client
df = spark.read.parquet("s3a://data-lake/events/2026/")

aggregated = df.groupBy("country", "event_type") \
    .count() \
    .orderBy("count", ascending=False)

aggregated.show(20)

Das Spark-Connect-Protokoll basiert auf gRPC und serialisiert die logischen Abfrageplaene, anstatt Daten zwischen Client und Server zu verschieben. Dies fuehrt zu einer drastischen Reduktion des Netzwerk-Overheads und ermoeglicht Multi-Tenancy-Szenarien, in denen Hunderte von Nutzern gleichzeitig auf denselben Cluster zugreifen. Fuer Unternehmen bedeutet dies eine bessere Ressourcenauslastung und vereinfachte Governance, da der Zugang ueber standardisierte Endpunkte verwaltet wird.

transformWithState API fuer komplexe Streaming-Logik

Die neue transformWithState-API ersetzt die veralteten mapGroupsWithState und flatMapGroupsWithState durch ein typsicheres, kompositionsfaehiges Interface. Der zentrale Vorteil liegt in der expliziten Zustandsverwaltung mit TTL (Time-to-Live), die das automatische Aufraumen inaktiver Sessions ermoeglicht und damit ein haeufiges Problem in Produktions-Streaming-Pipelines loest.

import org.apache.spark.sql.streaming._
import org.apache.spark.sql.streaming.StatefulProcessor
import java.time.Duration

case class UserEvent(userId: String, action: String, timestamp: Long)
case class SessionSummary(userId: String, actionCount: Int, durationMs: Long)

class SessionProcessor extends StatefulProcessor[String, UserEvent, SessionSummary] {

  // ValueState with 30-minute TTL — auto-cleanup of idle sessions
  @transient private var sessionStart: ValueState[Long] = _
  @transient private var actionCount: ValueState[Int] = _

  override def init(outputMode: OutputMode, timeMode: TimeMode): Unit = {
    sessionStart = getHandle.getValueState[Long]("start", TTLConfig(Duration.ofMinutes(30)))
    actionCount = getHandle.getValueState[Int]("count", TTLConfig(Duration.ofMinutes(30)))
  }

  override def handleInputRows(
      key: String,
      rows: Iterator[UserEvent],
      timerValues: TimerValues
  ): Iterator[SessionSummary] = {
    rows.flatMap { event =>
      if (!sessionStart.exists()) {
        sessionStart.update(event.timestamp)
        actionCount.update(1)
        Iterator.empty
      } else {
        val count = actionCount.get() + 1
        actionCount.update(count)
        // Emit summary every 10 actions
        if (count % 10 == 0) {
          val duration = event.timestamp - sessionStart.get()
          Iterator(SessionSummary(key, count, duration))
        } else Iterator.empty
      }
    }
  }
}

Die TTL-Konfiguration stellt sicher, dass der Zustand inaktiver Benutzer-Sessions nach 30 Minuten automatisch bereinigt wird. Ohne diesen Mechanismus wuerde der State-Store bei lang laufenden Streaming-Anwendungen kontinuierlich wachsen und letztlich zu Speicherproblemen fuehren. In Vorstellungsgespraechen wird haeufig nach genau diesem Aspekt gefragt, da er das Verstaendnis fuer die operativen Herausforderungen von Streaming-Systemen demonstriert.

Spark Declarative Pipelines (SDP) in Spark 4.1

Spark Declarative Pipelines (SDP) ermoeglicht die Definition von ETL-Workflows auf deklarative Weise. Anstatt den Ausfuehrungsplan manuell zu orchestrieren, beschreibt der Entwickler lediglich die gewuenschten Tabellen und deren Abhaengigkeiten. Spark uebernimmt die Erstellung des Ausfuehrungs-DAG, die Parallelisierung und das Fehler-Handling automatisch.

# declarative_pipeline.py
from pyspark.sql import SparkSession
from pyspark.sql.functions import col, sum as _sum, current_date

spark = SparkSession.builder.appName("SDP-Demo").getOrCreate()

# Define datasets declaratively — Spark resolves dependencies
@spark.declarative.table("clean_orders")
def clean_orders():
    return spark.read.table("raw_orders") \
        .filter(col("status") != "cancelled") \
        .filter(col("amount") > 0)

@spark.declarative.table("daily_revenue")
def daily_revenue():
    return spark.read.table("clean_orders") \
        .groupBy("order_date", "region") \
        .agg(_sum("amount").alias("total_revenue"))

@spark.declarative.table("revenue_summary")
def revenue_summary():
    return spark.read.table("daily_revenue") \
        .groupBy("region") \
        .agg(_sum("total_revenue").alias("grand_total")) \
        .orderBy("grand_total", ascending=False)

# Execute — Spark builds the DAG, parallelizes, handles retries
spark.declarative.run()

Der Ansatz aehnelt konzeptuell dbt, operiert jedoch direkt innerhalb der Spark-Laufzeitumgebung. Dies eliminiert die Notwendigkeit externer Orchestrierungstools fuer einfache bis mittlere Pipelines und reduziert die Gesamtkomplexitaet des Data-Engineering-Stacks. Besonders wertvoll ist die automatische Abhaengigkeitsaufloesung: Wenn revenue_summary von daily_revenue abhaengt und dieses wiederum von clean_orders, berechnet Spark die optimale Ausfuehrungsreihenfolge selbststaendig.

Data Engineering Interview-Fragen zu Spark 4

Die folgenden Fragen erscheinen regelmaessig in technischen Vorstellungsgespraechen fuer Data-Engineering-Positionen und decken die zentralen Neuerungen von Spark 4 ab.

Frage 1: Warum hat Spark 4 den ANSI-SQL-Modus als Standard aktiviert, und welche Auswirkungen hat das auf bestehende Pipelines?

Der ANSI-SQL-Modus verbessert die Datenqualitaet, indem er ungueltige Typkonvertierungen und arithmetische Ueberlaeufe nicht mehr stillschweigend als NULL behandelt, sondern explizite Exceptions wirft. Bestehende Pipelines muessen alle CAST-Ausdruecke auf TRY_CAST umstellen, um das bisherige Verhalten beizubehalten. Diese Aenderung deckt versteckte Datenfehler auf, die zuvor unbemerkt durch die Pipeline propagiert wurden.

Frage 2: Was ist der VARIANT-Datentyp und wie unterscheidet er sich von der STRING-basierten JSON-Verarbeitung?

VARIANT speichert semi-strukturierte Daten in einem optimierten Binaerformat mit automatischem Column Shredding. Im Gegensatz zu STRING-Spalten mit from_json erfordert VARIANT keine Schema-Definition bei der Speicherung, bietet aber trotzdem typisierte Zugriffe ueber Pfadnotation. Die Abfragegeschwindigkeit ist bis zu 10x hoeher, da haeufig abgefragte Felder automatisch als separate Spalten materialisiert werden.

Frage 3: Worin unterscheidet sich der Real-Time Mode vom bisherigen Micro-Batch-Verfahren in Structured Streaming?

Das Micro-Batch-Modell verarbeitet Daten in diskreten Zeitintervallen mit typischen Latenzen von 100ms bis mehreren Sekunden. Der Real-Time Mode verarbeitet jeden Datensatz sofort bei Eintreffen und erreicht Sub-Sekunden-Latenzen. Der Modus eignet sich fuer zeitkritische Anwendungen wie Betrugserkennung, erfordert aber mehr Ressourcen und unterstuetzt aktuell nur Kafka-zu-Kafka-Szenarien.

Frage 4: Welche Vorteile bietet Spark Connect gegenueber dem traditionellen Client-Modus?

Spark Connect trennt den Client vollstaendig vom Cluster ueber eine gRPC-Schnittstelle. Der Client benoetigt keine lokale JVM, was die Integration in Container-Umgebungen und Notebooks vereinfacht. Logische Abfrageplaene werden serialisiert uebertragen, nicht die Daten selbst, was den Netzwerk-Overhead minimiert. Mehrere Benutzer koennen denselben Cluster ueber standardisierte Endpunkte nutzen.

Frage 5: Was loest die transformWithState-API und warum wurde sie eingefuehrt?

Die transformWithState-API ersetzt mapGroupsWithState und flatMapGroupsWithState mit einem typsicheren Interface und nativer TTL-Unterstuetzung. Sie loest das Problem des unbegrenzten Zustandswachstums in lang laufenden Streaming-Anwendungen durch automatische Bereinigung inaktiver Zustaende. Die API ermoeglicht kompositionsfaehige State-Definitionen mit ValueState, ListState und MapState.

Vollstaendige Spark 4 ETL-Pipeline: Bronze-Silver-Gold

Das folgende Beispiel demonstriert eine produktionsreife ETL-Pipeline, die saemtliche neuen Features von Spark 4 integriert: ANSI-SQL-Modus, VARIANT-Datentyp und Structured Streaming mit Kafka als Quelle und Delta Lake als Senke.

# spark4_etl_pipeline.py
from pyspark.sql import SparkSession
from pyspark.sql.functions import col, from_json, current_timestamp, parse_json

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

# Bronze: raw ingestion from Kafka
bronze = spark.readStream \
    .format("kafka") \
    .option("kafka.bootstrap.servers", "broker:9092") \
    .option("subscribe", "user-events") \
    .load() \
    .select(
        col("key").cast("string").alias("event_key"),
        parse_json(col("value").cast("string")).alias("payload"),
        col("timestamp").alias("kafka_ts")
    )

# Silver: extract typed fields from VARIANT
silver = bronze.select(
    col("event_key"),
    col("payload:user_id").cast("int").alias("user_id"),
    col("payload:action").cast("string").alias("action"),
    col("payload:metadata.session_id").cast("string").alias("session_id"),
    col("kafka_ts"),
    current_timestamp().alias("processed_at")
).filter(
    col("user_id").isNotNull()  # ANSI mode makes this explicit
)

# Gold: write to Delta Lake with schema enforcement
query = silver.writeStream \
    .format("delta") \
    .outputMode("append") \
    .option("checkpointLocation", "s3a://checkpoints/user-events/") \
    .option("mergeSchema", "true") \
    .toTable("gold.user_events")

query.awaitTermination()

Die Bronze-Schicht nimmt die Rohdaten aus Kafka auf und konvertiert sie mittels parse_json direkt in den VARIANT-Datentyp. In der Silver-Schicht erfolgt die typisierte Extraktion einzelner Felder ueber die Pfadnotation. Der ANSI-Modus stellt sicher, dass fehlerhafte Konvertierungen sofort erkannt werden, anstatt als NULL-Werte in die Gold-Schicht zu gelangen. Die Gold-Schicht schreibt die bereinigten und typisierten Daten in Delta Lake mit aktivierter Schema-Evolution.

Diese Architektur repraesentiert den aktuellen Best-Practice-Ansatz fuer Streaming-ETL mit Spark 4 und kombiniert alle wesentlichen Neuerungen in einem kohaerenten System.

Fazit

Apache Spark 4 markiert einen Generationswechsel in der Big-Data-Verarbeitung. Die Neuerungen adressieren konkrete Schwachstellen frueherer Versionen und positionieren Spark als umfassende Plattform fuer Batch- und Echtzeit-Verarbeitung gleichermassen.

Die zentralen Fortschritte im Ueberblick:

• ANSI-SQL-Modus als Standard verbessert die Datenqualitaet durch explizite Fehlerbehandlung bei Typkonvertierungen
• VARIANT-Datentyp vereinfacht die Arbeit mit semi-strukturierten Daten bei gleichzeitig deutlich hoeherer Abfragegeschwindigkeit
• Real-Time Mode Streaming senkt die End-to-End-Latenz auf Sub-Sekunden-Niveau fuer zeitkritische Anwendungsfaelle
• Spark Connect entkoppelt Client und Cluster und ermoeglicht leichtgewichtige Integrationen ohne lokale JVM
• transformWithState API bietet typsichere Zustandsverwaltung mit automatischer TTL-basierter Bereinigung
• Spark Declarative Pipelines reduzieren die Komplexitaet von ETL-Workflows durch automatische Abhaengigkeitsaufloesung

Fuer Data Engineers und Entwickler, die sich auf technische Interviews vorbereiten, sind die Kenntnisse dieser Features mittlerweile unverzichtbar. Die Faehigkeit, die Unterschiede zwischen Micro-Batch und Real-Time Mode zu erklaeren, die Vorteile von VARIANT gegenueber STRING-basiertem JSON-Parsing zu demonstrieren und eine vollstaendige Bronze-Silver-Gold-Pipeline mit Spark 4 aufzubauen, bildet die Grundlage fuer erfolgreiche Bewerbungsgespraeche im Bereich Data Engineering.