Ein Jahr ist vergangen, seit SAP im Februar 2025 die neue Produktstrategie für ihre Datenplattform vorgestellt hat. Mit der SAP Business Data Cloud ist in diesem Zusammenhang auch SAP Databricks entstanden, das neue Mischprodukt aus der Kooperation der beiden Datenkonzerne. Seit der Ankündigung diskutieren wir regelmäßig die Frage, was SAP Databricks und das Originalprodukt, mittlerweile meist “Enterprise Databricks” genannt, konkret voneinander unterscheidet. Welche Systemumgebung eignet sich für ein bestimmtes Nutzungsszenario, welche Funktionen sind in SAP Databricks enthalten oder nicht enthalten, und gibt es strategische Gründe für die eine oder andere Variante?
Wir geben Einblick in die Ergebnisse unserer Recherchen und geben Ihnen alle Informationen mit, die Sie für eine informierte Entscheidung benötigen. Im heutigen ersten Teil dieser Übersicht legen wir den Fokus auf den Funktionsumfang der beiden Databricks-Varianten und wie sich diese hinsichtlich des technischen Systembetriebs aus Kundensicht unterscheiden. Im zweiten Teil betrachten wir das sogenannte “Zero-Copy Data Sharing”, Betriebskosten und strategische Überlegungen zur Entscheidung zwischen den Varianten.
Was umfasst die SAP Business Data Cloud über SAP Databricks hinaus? Mehr dazu erfahren Sie in unserer BDC Blog-Serie aus dem letzten Jahr.
SAP Databricks ist ein im Funktionsumfang reduzierter Databricks Workspace, der direkt in die Systemlandschaft der SAP Business Data Cloud integriert ist. Neben Datasphere und der Analytics Cloud ist SAP Databricks damit eine Kernkomponente von BDC. Innerhalb einer Instanz von BDC ist genau ein SAP Databricks Workspace verfügbar und wird in der Cloud-Infrastruktur des für BDC gewählten Hyperscalers bereitgestellt, Amazon Web Services, Google Cloud Platform oder Microsoft Azure.
In der Funktionalität beschränkt sich der SAP Databricks Workspace auf Kernfunktionen von Databricks, die seit vielen Jahren als wichtige Bausteine bekannt sind: Databricks Notebooks als interaktive und kollaborative Entwicklungsumgebung für Python und SQL. Skalierbare Compute-Ressourcen auf Basis von Apache Spark oder der eigens entwickelten Databricks Photon Engine für SQL Warehouses. Die Entwicklung von Machine Learning Applikationen wird durch das MLflow Framework und eine entsprechende Benutzeroberfläche für Monitoring, Modell-Versionierung und -Evaluierung, sowie die Bereitstellung von Modellen als Webdienst unterstützt. Nicht zuletzt setzen alle diese Funktionen auf dem Lakehouse-Storage Modell mit Delta Tables als Speicherformat auf und sind mit dem Unity Catalog als zentrale Anlaufstelle für Zugriffssteuerung und Berechtigungsmanagement verbunden.
Hinsichtlich der Konnektivität bzw. Integration von Daten aus BDC und Drittsystemen gibt es ebenfalls einige Besonderheiten: SAP Databricks kann mittels Delta Sharing Protokoll Tabellen oder Views für die restliche BDC-Umgebung freigeben, sodass Daten direkt und ohne Replikation in der Analytics Cloud oder in Datasphere genutzt werden können. Umgekehrt können freigegebene Daten aus der BDC oder aus Drittsystemen im Databricks Workspace genutzt werden. Aus dem SAP Databricks Workspace heraus können allerdings keine Delta Shares für Drittsysteme freigegeben werden. Ausgehend ist dieses effiziente Zugriffsprotokoll auf die BDC-Umgebung eingeschränkt.
Hinsichtlich eingehender Datenintegration unterstützt SAP Databricks grundsätzlich beliebige Quellen, insofern die Anbindung mit Python programmiert werden kann. In kleinerem Rahmen ist dies sicherlich eine gute Ergänzung zu nativen Konnektoren anderer BDC Komponenten wie Datasphere, aber nicht ideal. Neben der Möglichkeit, Daten per Delta Sharing aus Drittsystemen zu lesen, fehlen im SAP Databricks Workspace hier Low-Code Konnektoren für weit verbreitete Business Software und Datenbanken, sowie von Databricks entwickelte Komfortfunktionen für das Einlesen von Near-Live-Datenströmen (Databricks Autoloader). Das Databricks Jobs Framework zur Prozesssteuerung und Orchestrierung ist in SAP Databricks vorhanden, aber ebenfalls auf grundständige zeitbasierte Trigger und einfache Abläufe beschränkt, native Spark Jobs, SQL Skripte oder Pipelines auf Basis des dbt-Frameworks können nicht wie gewohnt ausgeführt werden.
Schließlich muss noch erwähnt werden, dass im SAP Databricks Workspace sämtliche Compute-Ressourcen ausschließlich im “Serverless” Modus genutzt werden können. Anwender und Administratoren des Workspace haben somit keine direkte Möglichkeit, spezifische Ressourcen zu konfigurieren und für bestimmte Aufgaben zu skalieren.
Enterprise Databricks kommt ohne vergleichbare Einschränkungen und darüber hinaus mit einer langen Liste weiterer Funktionen und Systemkomponenten. Dazu zählt insbesondere eine eigene, vollwertige Benutzeroberfläche für Dashboarding und Business Intelligence samt LLM-gestützter Interaktionsmöglichkeiten in natürlicher Sprache. Im Bereich der generativen KI-Modelle und agentischer Systeme integriert Databricks regelmäßig die nötigen Werkzeuge für Entwicklung und Betrieb der aktuellen Innovationen: Retrieval Augmented Generation (RAG) und Agentic-AI können sowohl programmiert als auch über low-code Eingabemasken aus vorkonfigurierten Bausteinen komponiert werden.
Datenintegrationsfunktionen gehen in Enterprise Databricks deutlich weiter als in SAP Databricks: Autoloader für effizientes Laden von Dateiinhalten aus Storage-Diensten in beinahe Echtzeit und low-code Konnektoren für die Anbindung von verbreiteten Softwareprodukten und Datenbanken sind vorhanden. Darüber hinaus können mit Databricks Job unterschiedlichste Workflows zusammengestellt und orchestriert werden. Mit Spark Declarative Pipelines (bis 2025 als Delta Live Tables bezeichnet) können komplett virtuelle Datenmodelle konstruiert und für maximale Performance in Echtzeit synchronisiert und vorberechnet werden. Das eigene Applikationsentwicklungsframework und ein Marktplatz zum Austausch von Daten und Applikationen mit anderen Databricks Workspaces runden das Angebot ab.
Als Zwischenfazit kann festgestellt werden, dass SAP Databricks hinsichtlich der Funktionalität keinerlei Vorteile gegenüber Enterprise Databricks bringt. Exklusive Features im SAP Databricks Workspace für eine tiefere Integration mit der SAP-Landschaft z.B. hinsichtlich übergreifender Zugriffssteuerung gibt es (derzeit) nicht.
Plattformbetrieb als Entscheidungsfaktor: SaaS vs. PaaS
SAP Databricks und Enterprise Databricks stellen im Betrieb durchaus unterschiedliche Anforderungen an eine Organisation. Kurz und pointiert formuliert heißt das: SAP Databricks ist Software-as-a-Service (SaaS), Enterprise Databricks ist Platform-as-a-Service (PaaS). Ganz zutreffend ist diese Feststellung nicht, denn auch in SAP Databricks haben Sie wiederum eine weitgehend offene Plattform, die ich in vielerlei Weise nutzen kann. Aber die Aufwände, den Workspace für Anwender zur Verfügung zu stellen, sind auf ein Minimum reduziert. Compute-Ressourcen sind komplett hinter dem “Serverless”-Label versteckt und die Anbindung an Cloud-Storage erfolgt ebenfalls vollständig durch das SAP BDC Deployment. Wiederum verkürzt ausgedrückt: SAP Databricks bekomme ich auf Knopfdruck in meine SAP BDC Systemlandschaft bereitgestellt.
Enterprise Databricks betreiben Organisationen in aller Regel selbst oder mit Unterstützung durch einen Dienstleister im eigenen Cloud-Mandanten. Für einen schnellen POC lassen sich die benötigten Ressourcen wie Storage und Netzwerkkomponenten ebenfalls auf Knopfdruck beim gewünschten Hyperscaler ausrollen, im produktiven Betrieb erfordern die Anforderungen hinsichtlich Informationssicherheit allerdings immer vollständig definierte und nachvollziehbare Konzepte und Prozesse, die am besten mit einem Infrastructure-as-Code-Ansatz und den zugehörigen CI/CD Pipelines erreicht werden können. Die Einstiegshürde liegt hier deutlich höher als im Gesamtpaket der SAP Business Data Cloud, die dem Kunden solche Prozesse weitestgehend abnimmt.
Im ersten Teil unseres Vergleichs von Enterprise Databricks und SAP Databricks zeigt sich schon deutlich, dass die Entscheidung zwischen diesen Varianten eine Abwägung zwischen Funktionsumfang und Betriebsaufwand darstellt. SAP Databricks erfordert weniger Know-How aus hinsichtlich Infrastruktur-DevOps-Feld oder verspricht zumindest deutlich geringerer Konfigurationsaufwand für Kunden und ihre Teams. Demgegenüber fehlen einige spannende technische Features der Databricks Plattform. Insbesondere, dass in einem SAP Databricks Workspace viele der Low-Code-Komponenten zur Anbindung an Drittsysteme nicht verfügbar sind, widerspricht gewissermaßen dem Anspruch der SAP-Systemlandschaft, Technologie für ein möglichst breites Publikum zugänglich zu gestalten.
Im zweiten Teil unseres Systemvergleichs schauen wir genauer auf das sogenannte “Zero-Copy Data Sharing” und welche Unterschiede sich daraus ergeben. Zudem werden wir einen Blick auf die Kostenstruktur werfen und weitere strategische Aspekte beleuchten, die für eine Entscheidung wichtig sind.
Wenn Sie bereits heute bewerten möchten, welche Databricks-Variante besser zu Ihrer Systemlandschaft, Ihren Use Cases und Ihrem Betriebsmodell passt, sprechen Sie uns gerne an. Wir unterstützen Sie bei der Einordnung, Bewertung und Entscheidungsfindung - von der ersten Analyse bis zur konkreten Architektur.