SAP Databricks

SAP Databricks ist eine im Februar 2025 vorgestellte Kombination aus zwei Systemen: SAP baut die Analyse- und KI-Plattform von Databricks (spezialisierter Anbieter für Datenauswertung und Machine Learning) direkt in die SAP Business Data Cloud ein, kurz BDC, die zentrale Datenplattform von SAP. Betriebsdaten aus den SAP-Systemen für Finanzen und Logistik (S/4HANA), Reporting (BW/4HANA) und die Cloud-Datenmodellierung (SAP Datasphere) werden dabei nicht kopiert, sondern per Delta Sharing (Freigabeverfahren ohne physische Datenkopie) bereitgestellt. Fachbegriffe wie Kennzahlen und Berechtigungen aus der SAP-Welt bleiben erhalten.

Was ist SAP Databricks?

SAP Databricks ist ein Baustein innerhalb der SAP Business Data Cloud (BDC), also der zentralen SAP-Datenplattform. SAP integriert die komplette Databricks-Plattform als eingebautes Modul: dazu gehören der Datenspeicher (Delta Lake), die Rechte- und Katalogverwaltung (Unity Catalog), Arbeitsumgebungen für Datenauswertung (Notebooks) sowie Werkzeuge für Machine Learning und KI-Assistenten. Vertrag, Preise und die Anbindung an die Sicherheitsregeln der BDC verantwortet SAP; die technische Engine liefert Databricks. Fachlich sitzt SAP Databricks als Auswertungs- und KI-Schicht über den BDC-Datenprodukten und ergänzt SAP Datasphere, die klassische Modellierungsebene für ein Cloud-Data-Warehouse (zentrale Datensammlung fürs Berichtswesen).

Der zentrale Mechanismus ist Delta Sharing. BDC-Datenprodukte aus SAP Datasphere, der SAP BW Bridge oder direkt aus S/4HANA-CDS-Views werden als geteilte Delta-Tabellen im Databricks-Katalog sichtbar. Databricks-Workloads lesen diese Tabellen ohne physische Replikation, ohne separaten Storage-Bucket auf Databricks-Seite, ohne ETL-Pipeline, ohne CDC-Wartung. Der Zugriff erfolgt referenziell auf den BDC-Speicher, die Kompute-Schicht läuft im BDC-eigenen Databricks. Dieser Zero-Copy-Ansatz bedeutet, dass die Daten die SAP-Governance-Grenze nicht verlassen und nur einmal existieren.

Zweitens reist die SAP-Business-Semantik mit. Ein Analytic Model aus SAP Datasphere, das eine Kennzahl wie „Deckungsbeitrag II" mit Berechtigungen und Hierarchien definiert, wird als semantisches Datenprodukt bereitgestellt statt als Roh-Tabelle. Databricks-Notebooks und ML-Modelle greifen auf die berechnete Kennzahl zu, ohne selbst die zugrundeliegenden Fakten- und Dimensionstabellen zu joinen. Berechtigungen aus dem SAP-Kontext werden über den BDC-Katalog durchgereicht.

Der Kanal funktioniert bidirektional. In Databricks berechnete Ergebnisse wie ein Kunden-Score aus einem ML-Modell oder ein aggregiertes Data Product lassen sich als eigenes Datenprodukt in die BDC zurückreichen und dort in SAP Analytics Cloud oder in SAP-Fachanwendungen konsumieren.

Abgrenzung zu SAP Datasphere, Replication Flow, Databricks Standalone und SAP HANA Cloud

Der Begriff SAP Databricks wird häufig mit den benachbarten SAP-Datenprodukten und mit einem klassischen Databricks-Workspace verwechselt. Die folgende Tabelle klärt die typischen Abgrenzungen.

Die zentrale Abgrenzung verläuft zwischen SAP Databricks und einem Databricks-Standalone-Setup. Beide nutzen dieselbe technische Plattform, unterscheiden sich aber im Vertragsmodell, in der Datenübergabe und im Umgang mit der SAP-Semantik. Standalone verlangt eigene Verträge, eigenen Katalog und eine explizite Datenanbindung; die SAP-Business-Semantik geht dabei verloren. SAP Databricks kommt ohne eigenen Databricks-Vertrag, nutzt Delta Sharing als Übergabemechanik und trägt die semantische Ebene mit.

Die zweite häufige Verwechslung betrifft SAP Databricks und SAP Datasphere. Beide sind Bausteine derselben BDC-Landschaft, decken aber verschiedene Schichten ab: Datasphere ist die EDW- und Modellierungsschicht, SAP Databricks die Analytics- und AI-Engine darüber. Wer SAP-Daten harmonisieren und semantisch modellieren will, arbeitet in Datasphere; wer auf denselben Daten Data-Engineering-, ML- oder AI-Workloads betreibt, arbeitet in SAP Databricks. Die Verbindung zwischen beiden Schichten läuft über Delta Sharing.

Beispiel: Kunden-Churn-Modell auf SAP-Daten ohne Datenexport

Ein Konzern betreibt SAP S/4HANA für Finance und Logistik, SAP BW/4HANA für klassisches Reporting und SAP Datasphere als Cloud-EDW-Schicht. Für ein neues Kunden-Churn-Modell werden Finance-Kennzahlen aus dem BW-Bestand und Verhaltensdaten aus einem CRM benötigt. Der klassische Weg über einen CSV-Export aus den SAP-Systemen und die Ingestion in einen separaten Databricks-Workspace bricht die Kennzahl-Definitionen und die Berechtigungslogik; die Reproduzierbarkeit gegenüber den SAP-Reports geht verloren.

Mit SAP Databricks werden die BW-Bridge-Objekte und ein Analytic Model aus SAP Datasphere als Datenprodukte in der BDC veröffentlicht. Über Delta Sharing tauchen sie im BDC-integrierten Databricks-Katalog auf; die Kennzahl „Deckungsbeitrag II" kommt inklusive Berechtigungen mit. Ein Data-Engineering-Team modelliert das Churn-Feature-Set in einem Databricks-Notebook auf den geteilten Objekten und ergänzt die CRM-Daten aus einem eigenen Delta-Bereich. Das trainierte Modell erzeugt einen Kunden-Score, der als eigenes Data Product in die BDC zurückgeschrieben wird.

SAP Analytics Cloud konsumiert das zurückgereichte Data Product in einer Story neben den etablierten Finance-Kennzahlen. Für die Endanwendung ist nicht sichtbar, ob die Kennzahl aus einem BW-Objekt, einem Datasphere-Modell oder einem Databricks-ML-Modell stammt; die Semantik-Ebene der BDC vereinheitlicht den Zugriff. Der SAP-Investitionsbestand bleibt unangetastet, die neuen Analytics- und AI-Workloads laufen auf denselben Daten.