Photon ist Databricks' Abfrage-Motor (die Software, die SQL-Abfragen und Daten-Transformationen auf dem Databricks-Cluster tatsächlich rechnet), neu geschrieben in der Programmiersprache C++, um Auswertungen auf großen Datenmengen schneller zu machen. Photon ersetzt auf Databricks-Rechnern den bisherigen, in Java geschriebenen Spark-Motor bei allen Abfragen, die er versteht; bestehender SQL- oder DataFrame-Code (Datenverarbeitungs-Code in Python oder Scala) läuft ohne Änderung weiter. Aktiviert wird Photon über einen Schalter am Cluster oder SQL-Warehouse (der Umgebung, in der SQL-Abfragen laufen); auf Serverless-Umgebungen ist er bereits eingebaut.
Was ist Photon?
Photon ist eine Neuentwicklung des Databricks-Abfrage-Motors in C++, der Daten anders verarbeitet als der klassische Java-Spark-Motor: Er greift nicht mehr Zeile für Zeile auf die Tabelle zu, sondern rechnet ganze Spalten-Blöcke (mehrere tausend Werte einer Spalte am Stück) parallel durch. Dabei nutzt er Spezial-Befehle moderner Prozessoren, mit denen sich dieselbe Rechen-Operation gleichzeitig auf viele Werte anwenden lässt (Fachbegriff: SIMD-Verarbeitung). Das Ergebnis: dieselbe Abfrage läuft deutlich schneller und braucht weniger Rechenzeit. Der eigentliche Abfrage-Plan (die Reihenfolge der Rechenschritte, die Spark aus dem SQL-Statement ableitet) ändert sich dabei nicht. Spark entscheidet weiterhin, was gerechnet werden muss, Photon führt es nur schneller aus. Rechenschritte, die Photon noch nicht beherrscht, fallen automatisch auf den Java-Spark-Motor zurück, sodass jeder Job weiter durchläuft.
Databricks hat Photon ab 2019 als Antwort auf die Performance-Grenzen der JVM-Execution entwickelt und in den Hauptpfad der Databricks-Runtime integriert. Microsoft Learn beschreibt Photon als das Azure-Databricks-native vektorisierte Abfragemodul für SQL-Workloads, DataFrame-API-Aufrufe, ETL-Pipelines und zustandsloses Streaming; auf AWS und GCP gilt dieselbe Engine.
Auf Serverless SQL Warehouses und auf Serverless Compute ist Photon fester Bestandteil des Produkts und lässt sich dort nicht separat deaktivieren. Auf Classic Compute ist Photon optional und wird per Cluster-Flag aktiviert. Abgerechnet wird Photon über einen DBU-Multiplikator auf die jeweilige Compute-Klasse: Der Aufpreis pro Stunde wird nur dann durch eine kürzere Laufzeit überkompensiert, wenn der Workload vektorisierbare Operatoren auf passenden Daten enthält. Photon greift typischerweise bei SQL- und DataFrame-Operationen mit Scans, Joins und Aggregationen über große Delta-Tabellen. Nicht unterstützt werden Python- oder Scala-UDFs, RDD- und Dataset-APIs, zustandsbehaftete Streaming-Operatoren sowie sehr kurze Abfragen.
Abgrenzung zu Spark, Serverless und Predictive Optimization
Photon wird häufig mit verwandten Begriffen vermischt, weil Engine, Compute-Modell und Storage-Optimierung in derselben Produktoberfläche zusammenliegen.
| Begriff | Schicht | Verhältnis zu Photon |
|---|---|---|
| Spark / Databricks Runtime | JVM-Execution + Catalyst-Optimizer | Voraussetzung; Photon ersetzt nur die Execution unterstützter Operatoren |
| Serverless SQL Warehouses | Compute- und Betriebsmodell | Produkt, in dem Photon Default-Engine ist; Photon ist nicht das Produkt selbst |
| Predictive Optimization | Storage-/Layout-Optimierung auf Delta-Tabellen | orthogonal zur Query-Execution |
| Photon Acceleration Tier | Pricing-Variante | Vermarktungsname für Photon-aktivierte Compute, technisch dieselbe Engine |
Photon ist die Execution-Schicht innerhalb der Databricks-Runtime, die unterstützte Operatoren übernimmt. Das Compute-Modell (Serverless oder Classic), die Tabellen-Wartung über Predictive Optimization und das Storage-Format Delta Lake bleiben davon getrennt und werden separat konfiguriert.
Beispiel: Photon in einem nächtlichen ETL-Job
Ein nächtlicher ETL-Job aggregiert mehrere hundert Millionen Zeilen einer Delta-Tabelle auf Tages-Kennzahlen für ein BI-Dashboard. Der Job liest die Tabelle, filtert auf ein Datumsfenster, joint zwei Stammdaten-Tabellen und schreibt das Ergebnis in eine aggregierte Delta-Tabelle. Sämtliche Operationen sind SQL- oder DataFrame-basiert. Mit aktiviertem Photon laufen Scan, Filter, Hash-Join und Group-By-Aggregation über die vektorisierte C++-Engine; die Laufzeit sinkt typischerweise um den Faktor zwei bis vier, der DBU-Aufpreis pro Stunde wird durch die kürzere Compute-Zeit überkompensiert.
Läuft auf demselben Cluster parallel ein Job mit einer Python-UDF, die jede Zeile durch eine eigene Funktion schickt, ändert sich die Rechnung. Die UDF fällt auf die JVM zurück, Photon greift dort nicht, die Laufzeit bleibt nahezu identisch. Der Photon-DBU-Aufpreis fällt aber für die gesamte Cluster-Stunde an. Daraus folgt für die Compute-Konfiguration, dass UDF- oder RDD-lastige Pipelines nicht auf Photon-aktiviertem Compute laufen sollten, solange die UDFs nicht durch SQL- oder DataFrame-Operationen ersetzt sind.
Photon (Databricks Query Engine) im eigenen Unternehmen umsetzen?
Wir zeigen, wie sich das in deiner Systemlandschaft konkret abbilden lässt.