Konzeptkarte

SAP Datasphere vs Databricks — Entscheidungsrahmen für die SAP-Datenplattform

Stand 2026-08-02T20:00:00Z

Redaktion: Cédric-Olivier Mâry, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist SAP Datasphere vs Databricks — Entscheidungsrahmen für die SAP-Datenplattform?

Datasphere und Databricks sind keine Rivalen — BDC liefert ein von Databricks verwaltetes Lakehouse. Die eigentliche Entscheidung ist, wie viel der Verdrahtung zwischen beiden man selbst baut: Datasphere allein, federiertes eigenständiges Databricks oder das vorverdrahtete BDC-Bundle.

Fragt man einen SAP-Datenarchitekten „Datasphere oder Databricks?", lautet die ehrliche erste Antwort, dass die Frage falsch gestellt ist. In SAPs eigener Architektur sind die beiden keine Rivalen, die um denselben Platz konkurrieren: Business Data Cloud liefert mit einem von Databricks verwalteten Lakehouse als offener Speicherschicht, vorprovisioniert und über SAP abgerechnet, statt als separater Databricks-Vertrag ausgehandelt zu werden. Datasphere ist die semantische und Governance-Schicht; Databricks ist die Lakehouse- und Machine-Learning-Engine darunter. Zu fragen, wer gewinnt, ist wie zu fragen, ob man den Motor oder das Getriebe braucht.

Die Entscheidung, die wirklich zählt — und die Geld kostet, wenn sie schlecht getroffen wird — ist, wie viel der Verdrahtung zwischen beiden man selbst baut. Das ist eine Entscheidung mit drei Optionen, und diese Seite ist der Rahmen dafür.

Die drei Architekturen, zwischen denen Sie tatsächlich wählen

A — Nur Datasphere. Die semantische Schicht mit ihren Spaces, Views und Analytic Models, konsumiert von SAP Analytics Cloud, ohne Lakehouse dahinter. Richtig, wenn die Workload aus Business-User-Modellierung und Reporting über SAP-Daten besteht und kein Data-Engineering-Team vorhanden ist, um mehr zu betreiben. Das ist keine minderwertige Architektur; sie ist die richtige, wenn niemand im Projekt Spark nutzen würde, selbst wenn man es ihm gäbe.

Warum es zählt

Wer das falsch entscheidet, kauft ein Lakehouse, das niemand im Team betreiben kann, oder zahlt doppelt für Governance, die SAP bereits paketiert. Das ist eine der zwei oder drei Architekturentscheidungen, die ein Kunde nicht billig rückgängig machen kann.

Kernpunkte

Es ist kein Gegeneinander: Business Data Cloud liefert ein von Databricks verwaltetes Lakehouse als offene Speicherschicht, vorprovisioniert und über SAP abgerechnet.
Datasphere ist die semantische und Governance-Schicht; Databricks ist die Lakehouse- und ML-Engine. Unterschiedliche Aufgaben, ein Stack.
Die eigentliche Dreier-Wahl: (A) nur Datasphere, (B) Datasphere + eigenständiges Databricks föderiert, (C) das vorverdrahtete BDC-Bundle.
Option A ist keine minderwertige Architektur — sie ist richtig, wenn niemand im Projekt Spark nutzen würde, selbst wenn man es ihm gäbe.
Option B gewinnt, wenn bereits eine ausgereifte Databricks-Praxis existiert; sie in SAP-native Werkzeuge zu migrieren kostet fast immer mehr, als sie zu föderieren.
BDC ändert, wer für das Lakehouse ABRECHNET; es beseitigt nicht die Notwendigkeit jemandes, der Spark, Delta und Unity Catalog im Tagesgeschäft betreibt.
Der Kunde, für den BDC konzipiert ist, hält 70–80 % der analyserelevanten Daten innerhalb des SAP-Bestands. Kehrt sich dieses Verhältnis um, schwächt sich das Paketierungsargument ab.
Delta Sharing (2021 als Open Source veröffentlicht, Apache-lizenziert) ist tatsächlich multi-konsumentenfähig — Power-BI-Direct-Query und Tableau lesen dieselbe governte Ausgabe.
BDC Connect erreichte am 6. Oktober 2025 GA für Databricks und föderiert außerdem Snowflake, S3/Iceberg und BigQuery.
Bei Option B trägt man selbst die Verantwortung für die Schema-Evolution über zwei Plattformen, die beide dieselben Delta-Tabellen schreiben — das erfordert einen schriftlichen Vertrag, nicht nur eine Verbindung.

Begriffe auf dieser Seite

Delta Sharing: Offenes, Apache-lizenziertes Protokoll, 2021 von Databricks als Open Source veröffentlicht, um Delta-Lake-Tabellen über Organisationsgrenzen hinweg zu lesen, ohne sie zu kopieren. Multi-konsumentenfähig: Auch Power-BI-Direct-Query und Tableau lesen es.
BDC Connect: SAP-seitige Föderationsschicht, die externe Plattformen — Databricks, Snowflake, Amazon S3/Iceberg, BigQuery — innerhalb des Business-Data-Cloud-Katalogs registriert, sodass die Datasphere-Modellierung und das Joule-Grounding sie als native Objekte sehen.
Unity Catalog: Metastore- und Governance-Schicht von Databricks; der Endpunkt, mit dem BDC Connect für Delta Sharing direkt spricht, ohne SAP-spezifischen Treiber.
Lakehouse: Speicherarchitektur, die die offenen Dateiformate eines Data Lake mit den transaktionalen Garantien und der Governance eines Warehouse kombiniert. In BDC ist es die von Databricks verwaltete, offene Speicherschicht.
Data Access Controls (DAC): Datasphere's Row-Level-Security-Mechanismus. Seine Vererbung über einen Delta Share hinweg muss auf der lesenden Seite verifiziert werden, niemals angenommen.
Analytic Model: Das Datasphere-Objekt, das die Geschäftssemantik trägt — Measures, Dimensionen, Hierarchien — und das, was ein governter Share tatsächlich exponiert.
Data Product: Ein governter, veröffentlichter Datensatz mit einem Owner, einer Aktualitätszusage, einer Sensibilitätsklassifizierung und einer Abonnentenliste; die Einheit, die BDC in beide Richtungen teilt.
Zero-Copy-Föderation: Das Lesen von Daten an Ort und Stelle über Plattformen hinweg, ohne Duplizierung. Es beseitigt Replikationsverzögerung und doppelte Speicherung — es beseitigt nicht die Compute-Kosten auf der lesenden Seite.

Quellen

Vollständige Karte für Mitglieder. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · den Vergleich SAP · Snowflake · Databricks · Fabric · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Architekturschemata · die Codeblöcke · die zitierfähigen Kennzahlen.

In der App öffnen →