Databricks Photon Engine: Wann nutzen — und wann nicht?

TL;DR: Photon ist 2–10× schneller für SQL-Aggregationen, große Delta-Reads/Writes und ETL ohne Python-UDFs. Bringt nichts (oder schadet) bei: Python-UDFs, ML-Training, sehr kurzen Queries (< 2 s), High-Frequency-Streaming. Dieselben DBU-Kosten wie Standard-Spark — schneller heißt billiger.

Databricks Photon ist einer der bedeutendsten Performance-Fortschritte im Databricks-Runtime — eine native, vektorisierte C++-Query-Execution-Engine, die für die richtigen Workloads dramatische Speedups liefert. Aber "Photon überall aktivieren" ist keine solide Engineering-Strategie. Photon hat ein spezifisches Kostenprofil, eine fokussierte Stärkenkarte und reale Grenzen.

Dieser Guide gibt dir die technischen Grundlagen, Benchmarks und das Entscheidungs-Framework, um Photon intelligent zu deployen.

Was ist Photon?

Photon ist eine Neuimplementierung der Spark-SQL-Execution-Engine in nativem C++, von Grund auf für moderne CPUs designt. Für unterstützte Operationen ersetzt sie den JVM-basierten Spark-Execution-Layer und verarbeitet Daten spalten-orientiert, vektorisiert — voll im Sinne von CPU-SIMD-Instruktionen (AVX-512, AVX2).

Standard-Spark führt Queries zeilenweise über einen JVM-Call-Stack aus. Photon verarbeitet Daten in Batches von Spalten — heißt:

• Mehr Daten pro CPU-Zyklus
• Drastisch reduzierter JVM-Overhead und Garbage-Collection
• Bessere Cache-Lokalität (Spalten passen in CPU-L1/L2-Cache)
• Nativer Memory-Management (kein JVM-Heap-Druck)

Resultat: für die richtigen Query-Patterns ist Photon typischerweise 2–10× schneller als Standard-Spark bei gleichen Compute-Kosten.

Photon aktivieren

Photon braucht einen Photon-fähigen Instance-Typ. Auf AWS: i3, m5d, r5d. Auf Azure: Standard_E- und Standard_L-Serien. Auf GCP: n2 und n2d.

# Enable Photon via CLI when creating a cluster
databricks clusters create --json '{
  "cluster_name": "photon-cluster",
  "spark_version": "13.3.x-photon-scala2.12",
  "node_type_id": "i3.xlarge",
  "num_workers": 4
}'

# Verify Photon is active in your session
print(spark.conf.get("spark.databricks.photon.enabled"))

In der Databricks-UI: einfach beim Erstellen eines Clusters eine Photon Accelerated-Runtime wählen. Sie sind klar gelabelt.

Wo Photon glänzt

1. SQL-Aggregationen und Analytics

Photons größte Wins liegen bei schweren SQL-Workloads — Aggregationen, GROUP BY, HAVING, Window-Funktionen und Joins auf großen Tabellen.

-- This query type benefits massively from Photon
SELECT
  country,
  event_type,
  DATE_TRUNC('month', event_ts) AS month,
  COUNT(*)                       AS events,
  COUNT(DISTINCT user_id)        AS unique_users,
  SUM(revenue_usd)               AS total_revenue,
  AVG(session_duration_s)        AS avg_session_s
FROM catalog.schema.events
WHERE event_ts >= '2024-01-01'
GROUP BY 1, 2, 3
ORDER BY total_revenue DESC;

Benchmark (100M Rows, 8-Core-Cluster):

8× Speedup bei gleicher DBU-Rate — denn Photon-DBUs kosten auf den meisten Konfigurationen genauso viel wie Standard-DBUs.

2. ETL-Pipelines mit Spalten-Projektion und Filtern

Bulk-Transformationen, die Spalten projizieren, Filter anwenden und in Delta schreiben, profitieren von Photons vektorisiertem Scan- und Write-Path:

# Photon accelerates this entire pipeline
df = (
    spark.table("raw.events")
    .filter("event_date = '2024-01-15'")
    .select("user_id", "event_type", "session_id", "revenue_usd", "country")
    .withColumn("revenue_eur", col("revenue_usd") * 0.92)
    .groupBy("country", "event_type")
    .agg(
        count("*").alias("events"),
        sum("revenue_eur").alias("revenue_eur")
    )
)

df.write.format("delta").mode("append").saveAsTable("gold.country_events_daily")

3. Delta-Lake-Reads und -Writes

Photon hat native Delta-Lake-Integration. Beschleunigt:

• Parquet vektorisierte Reads
• Delta-Write-Path (inkl. OPTIMIZE)
• Data-Skipping via Spalten-Statistiken

-- Photon accelerates the scan and MERGE computation
MERGE INTO target t
USING source s ON t.id = s.id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

4. String-Operationen und Regex

Photons native C++-String-Library outperformt JVM-String-Operationen deutlich:

-- Photon handles this 3-5x faster than standard Spark
SELECT
  user_id,
  REGEXP_EXTRACT(url, 'utm_source=([^&]+)', 1) AS utm_source,
  UPPER(country)                                AS country,
  LENGTH(description)                           AS desc_len
FROM catalog.schema.pageviews
WHERE url LIKE '%utm_%';

Wo Photon NICHT hilft (oder schadet)

Photons Grenzen zu verstehen ist genauso wichtig wie die Stärken zu kennen.

1. Python-UDFs

Die kritischste Limitation. Photon kann keine Python-UDFs ausführen. Trifft Photon eine Python-UDF, fällt es für diese Stage auf Standard-Spark zurück:

from pyspark.sql.functions import udf
from pyspark.sql.types import StringType

# This kills Photon acceleration for the entire stage
@udf(returnType=StringType())
def parse_custom_format(value):
    # Photon falls back to JVM/Python for this
    return value.split("|")[0].strip()

df = df.withColumn("parsed", parse_custom_format(col("raw_value")))

Fix: Python-UDFs durch eingebaute Spark-SQL-Funktionen oder Pandas-UDFs (die teilweise beschleunigt werden) ersetzen:

from pyspark.sql import functions as F

# Photon can accelerate this
df = df.withColumn("parsed", F.split(F.trim(col("raw_value")), "\\|")[0])

2. ML- und Data-Science-Workloads

Photon beschleunigt nicht:

• MLlib-Modell-Training
• Pandas-Operationen auf Spark-DataFrames
• Custom Scala/Java-Transformer außerhalb des Supported-Operator-Sets
• Komplexe verschachtelte Datenstrukturen (Maps, Arrays of Structs)

# Photon provides no benefit here
from pyspark.ml.classification import RandomForestClassifier

rf = RandomForestClassifier(numTrees=100, maxDepth=5)
model = rf.fit(training_df)

Für ML sind Standard-Spark-Runtimes oder GPU-enabled Cluster passender.

3. Small Data und Short-Running Queries

Photon hat einen nicht-trivialen Startup-Overhead pro Query. Für Queries unter 1–2 Sekunden kann der Initialisierungsaufwand den Throughput-Vorteil aufheben:

Implikation: Photon nicht auf Clustern aktivieren, die primär für interaktive, exploratorische Arbeit auf kleinen Datasets genutzt werden.

4. Streaming mit häufigen Micro-Batches

Structured Streaming mit sehr kurzen Trigger-Intervallen (< 5 s) kann Overhead aus Photon-Query-Planning sehen. Vor Aktivierung auf High-Frequency-Streaming-Clustern sorgfältig testen:

# For streaming with very short intervals, benchmark before committing to Photon
(
    spark.readStream
    .format("delta")
    .table("raw.events")
    .writeStream
    .trigger(processingTime="2 seconds")  # Short interval — test Photon carefully
    .format("delta")
    .table("silver.events")
    .start()
)

Das Entscheidungs-Framework

Mit diesem Framework entscheidest du, ob Photon für einen Workload aktiviert wird:

Ist der Workload primär SQL-Aggregationen oder große Delta-Reads/Writes?
  -> JA -> Photon aktivieren

Nutzt der Workload Python-UDFs extensiv?
  -> JA -> Erst UDFs refaktorisieren, dann Photon evaluieren

Ist das ML-Training oder Modell-Inference?
  -> JA -> Standard-Runtime oder GPU-Cluster stattdessen

Sind Queries typischerweise < 5 s auf kleinen Daten?
  -> JA -> Standard-Runtime ist billiger und gleich schnell

High-Frequency-Micro-Batch-Streaming (< 5 s Trigger)?
  -> JA -> Beide Runtimes benchmarken vor Entscheidung

Photon vs Standard-Spark benchmarken

Immer den eigenen Workload benchmarken — nicht auf generische Claims verlassen. Reproducierbares Benchmark-Pattern:

# photon_benchmark.py
import time

def benchmark_query(query: str, label: str, runs: int = 3) -> float:
    times = []
    for i in range(runs):
        # Clear caches between runs
        spark.catalog.clearCache()
        spark.sparkContext._jvm.System.gc()

        start = time.time()
        spark.sql(query).write.format("noop").mode("overwrite").save()
        elapsed = time.time() - start
        times.append(elapsed)
        print(f"  [{label}] Run {i+1}: {elapsed:.2f}s")

    avg = sum(times) / len(times)
    print(f"  [{label}] Average: {avg:.2f}s")
    return avg

BENCHMARK_QUERY = """
    SELECT country, event_type, COUNT(*), SUM(revenue_usd)
    FROM catalog.schema.events
    WHERE event_date >= '2024-01-01'
    GROUP BY 1, 2
    ORDER BY 3 DESC
"""

# Run on standard cluster, record results, then switch to Photon cluster
standard_avg = benchmark_query(BENCHMARK_QUERY, "Standard Spark")

# After switching to Photon-enabled cluster:
photon_avg = benchmark_query(BENCHMARK_QUERY, "Photon")

speedup = standard_avg / photon_avg
print(f"\nPhoton speedup: {speedup:.1f}x")

Cost-Implikationen

Photon-Runtimes kosten dieselben DBUs wie Standard-Runtimes auf Databricks. Wenn Photon einen Job 5× schneller laufen lässt, nutzt du 5× weniger DBUs — das ist direkte Cost-Reduktion.

Photon-kompatible Instance-Typen (mit lokalen NVMe-SSDs) sind allerdings auf Cloud-VM-Ebene leicht teurer als General-Purpose-Instances. Für die meisten analytischen Workloads übersteigen die DBU-Einsparungen das Instance-Premium deutlich.

Photon und Liquid Clustering

Databricks Liquid Clustering — der Nachfolger von Hive-Style-Partitionierung und Z-ORDER — ist tief in Photon integriert. Liquid Clustering nutzt Spalten-Statistiken und ein automatisiertes File-Layout, um effizientes Data-Skipping zu ermöglichen — ohne manuelle OPTIMIZE ZORDER-Calls:

-- Create a table with Liquid Clustering
CREATE TABLE catalog.schema.events
CLUSTER BY (country, event_type, user_id)
AS SELECT * FROM raw.events;

-- Clustering runs automatically during OPTIMIZE
OPTIMIZE catalog.schema.events;

Photon beschleunigt sowohl die OPTIMIZE-Operation als auch die folgenden Scans. Auf Databricks Runtime 13.3+ mit Photon ist Liquid Clustering die bevorzugte Layout-Strategie statt manuellem Z-ORDER.

FAQ

Wann lohnt sich Photon nicht?

Bei Workloads mit vielen Python-UDFs, ML-Training, kurzen Ad-hoc-Queries (< 5 s) oder High-Frequency-Streaming. Auch bei sehr kleinen Datenmengen (< 10 GB) ist der Overhead oft größer als der Speedup.

Muss ich meinen Code für Photon umschreiben?

Nein — Photon ist transparent. Wenn eine Operation nicht unterstützt wird, fällt sie auf Standard-Spark zurück. Aber: Code mit vielen Python-UDFs profitiert kaum, ehe du sie durch native Spark-SQL-Funktionen ersetzt.

Kostet Photon mehr DBUs?

Auf den meisten Konfigurationen nicht — gleicher DBU-Rate. Cloud-VM-Premium für Photon-kompatible Instances ist ~10–15 % höher, aber durch die kürzere Laufzeit oft mehr als kompensiert.

Wie sehe ich, ob Photon wirklich aktiv ist?

spark.conf.get("spark.databricks.photon.enabled") returnt true. In der Spark-UI haben Stages, die von Photon ausgeführt werden, einen "Photon"-Tag im Stage-Detail.

Sollte ich für jedes Team einen Photon-Cluster aufsetzen?

Eher nein. Pro Workload-Typ: ein Photon-Cluster für SQL-Analytics + Delta-ETL, ein Standard-Cluster für ML + UDF-heavy Workloads. Mischung in einem Cluster ist verschwendetes Potenzial.

Schluss

Photon ist eine echte Engineering-Leistung — Databricks-SQL und Delta-Lake sind für analytische und ETL-Workloads spürbar schneller. Aber es ist kein Zauberstaub. Aktiviere es, wenn das Workload-Profil passt: Large-Scale-SQL, schwere Delta-Reads/Writes und ETL-Pipelines frei von Python-UDFs.

Wenn du mehrere Databricks-Cluster über unterschiedliche Workload-Typen managst, ist das Tracking, welche Cluster Photon aktiv haben, welche Jobs von einer Migration profitieren würden und wie Cluster-Konfigurationen sich vergleichen — genau die operative Sichtbarkeit, die Harbinger Explorer bietet.

Stand: 14. Mai 2026.