Databricks Runtime

Die Databricks Runtime (DBR) ist das Software-Paket, das Databricks auf jedem Rechen-Cluster (Gruppe von Servern, die gemeinsam Datenjobs ausführen) startet. Sie bündelt die Analyse-Engine Apache Spark in einer festen Version mit dem Tabellenformat Delta Lake, der schnelleren Abfrage-Engine Photon und fertig installierten Zusatzbibliotheken. Die gewählte Runtime-Version legt fest, welche Spark-Version, welche Bibliotheken und welche Geschwindigkeits-Optimierungen ein Cluster oder ein SQL Warehouse (dedizierter Cluster für SQL-Abfragen) verwendet.

Was ist die Databricks Runtime?

Die Databricks Runtime ist die vorkonfigurierte Software-Auslieferung, die Databricks auf allen betriebenen Clustern (Server-Gruppen für Datenverarbeitung) startet. Der Kern besteht aus Apache Spark (der zentralen Analyse-Engine) in einer festen Version, kombiniert mit Delta Lake (dem Tabellenformat für zuverlässige Datenhaltung), Zusatzfunktionen für schnelleres Lesen und Zwischenspeichern von Daten sowie einer fest definierten Auswahl an Standardbibliotheken für die Programmiersprachen Python, R und Scala. Auf dieser Basis kommen weitere Bausteine hinzu, darunter die Photon-Engine (eine schnellere Abfrage-Ausführung in C++) und, in der ML-Variante (Ausprägung für Machine Learning), GPU-Treiber und Frameworks für maschinelles Lernen wie PyTorch, TensorFlow und XGBoost.

Databricks pflegt mehrere Versionsstränge parallel. Long-Term-Support-Versionen (LTS) wie DBR 14.3 LTS, 15.4 LTS oder 16.4 LTS erhalten Sicherheits- und Wartungs-Updates über etwa zwei Jahre und sind für Produktionsjobs vorgesehen. Non-LTS-Versionen erscheinen häufiger, bringen neue Spark- und Delta-Features früher, verlieren den Support aber nach wenigen Monaten. Neben der Standard-Runtime gibt es dedizierte Ausprägungen: die ML-Runtime (mit Bibliotheken für Machine Learning), Photon-fähige Runtimes (mit aktivierter C++-Engine für unterstützte Operatoren) und in der Vergangenheit spezielle Genomik- oder Streaming-Runtimes.

Die Runtime-Version wird pro Cluster oder Job-Compute konfiguriert. Auf Classic Compute wird sie beim Anlegen des Clusters ausgewählt und ist danach an diesen Cluster gebunden; ein Wechsel erfordert einen Neustart mit anderer Version. Auf Serverless Compute und Serverless SQL Warehouses verwaltet Databricks die Runtime-Version selbst und aktualisiert sie im Hintergrund, sodass sie nicht mehr Teil der Cluster-Konfiguration ist. Der Begriff existiert, weil Databricks damit einen stabilen, versionierten Software-Stack aus Open-Source-Komponenten (Spark, Delta) und proprietären Erweiterungen (Photon, I/O-Cache, DBIO) zu einer testbaren Einheit zusammenfasst.

Abgrenzung zu Apache Spark, DBU, Photon und Serverless

Die Databricks Runtime wird häufig mit den Komponenten verwechselt, die sie enthält oder mit denen sie zusammen abgerechnet wird.

Die Databricks Runtime ist damit die Software-Schicht auf dem Cluster; DBU, Photon und Serverless benennen dagegen Abrechnung, Ausführungs-Engine und Betriebsmodell. Diese Ebenen werden getrennt konfiguriert und getrennt entschieden.

Beispiel: Runtime-Auswahl in einem gemischten Workspace

In einem gemischten Workspace laufen typischerweise mehrere Cluster mit unterschiedlichen Runtime-Konfigurationen nebeneinander. Ein nächtlicher ETL-Job nutzt „Databricks Runtime 15.4 LTS" mit aktiviertem Photon; die LTS-Version liefert stabile Spark-3.5-Features, die Photon-Engine beschleunigt Scan, Filter und Join auf großen Delta-Tabellen. Ein ML-Training-Notebook desselben Workspace läuft dagegen auf „Databricks Runtime 15.4 LTS ML" mit GPU-Instanzen; die ML-Runtime enthält CUDA-Treiber und die passenden Framework-Versionen, sodass PyTorch- und MLflow-Code ohne zusätzliche Installation läuft.

Parallel dazu bearbeiten Analystinnen und Analysten Ad-hoc-Queries auf einem Serverless SQL Warehouse. Dort ist die Runtime-Version nicht sichtbar konfigurierbar; Databricks rollt Updates im Hintergrund aus und aktiviert Photon standardmäßig. Die Wahl der Runtime verschiebt sich damit von einer Cluster-Konfiguration hin zu einer Produkt-Entscheidung: Classic Compute mit expliziter Runtime-Version oder Serverless mit verwalteter Runtime.