Konzeptkarte

Delta Sharing in SAP Datasphere

Stand 27. September 2026

Redaktion: Cédric Mary, 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 Delta Sharing in SAP Datasphere?

Delta Sharing erlaubt es einem Datasphere-Space, eine live governte Sicht als schreibgeschützte Delta-Tabelle an Databricks, Fabric oder Snowflake zu veröffentlichen — und ersetzt damit die alte Wahl zwischen veralteten nächtlichen Extrakten und governance-brechender Live-Föderation.

Worum es geht

SAP Datasphere Delta Sharing ist die offene Protokollfläche, die es einem Datasphere-Space erlaubt, kuratierte Datenprodukte für externe Konsumenten freizugeben — Databricks, Microsoft Fabric, Snowflake, eigene Python-Clients —, ohne die Daten zu kopieren, ohne eine parallele Pipeline aufzubauen und ohne das innerhalb von Datasphere definierte Row-Level-Security-Modell zu untergraben.

Das Problem, das Delta Sharing löst: Endkundenlandschaften betreiben zunehmend einen Multi-Engine-Analytics-Stack. SAP Datasphere hält die governte fachlich-semantische Schicht (Analytic Models, Hierarchien, Währungsumrechnung), während die Data-Science-Teams in Databricks oder Fabric arbeiten. Vor Delta Sharing gab es nur zwei Optionen: nächtliche Extrakte (veraltet, teuer) oder Live-Föderation (langsam, governance-brechend). Delta Sharing veröffentlicht eine Datasphere-View als Delta-Tabelle, die jeder Delta-Sharing-kompatible Client live lesen kann, wobei SAPs Row-Level-Security weiterhin auf der Producer-Seite durchgesetzt wird.

Das Protokoll kennt zwei Rollen. Der Producer ist ein Datasphere-Space, der einen Share — eine benannte Sammlung von Tabellen und Views — mit einem Empfänger-Credential veröffentlicht. Der Producer bestimmt, welche Spalten offengelegt werden, welche Zeilenfilter pro Empfänger gelten und wie oft die zugrundeliegende View aktualisiert wird. Der Consumer liest den Share mit einer beliebigen Delta-Sharing-Client-Bibliothek: pandas, Spark, Databricks SQL oder ein Fabric-Notebook. Der Consumer sieht niemals die zugrundeliegenden Datasphere-Verbindungen oder die HANA-Quelltabellen — nur die veröffentlichte Fläche. Die Authentifizierung nutzt einen an das Empfänger-Credential gebundenen Bearer-Token; das Widerrufen des Credentials entzieht den Zugriff sofort.

Wählen Sie Delta Sharing, wenn das Data-Science-Team außerhalb von SAP arbeitet und governten Zugriff auf SAP-Analytic-Models benötigt. Setzen Sie es nicht für hochfrequente operative Integration ein (dafür BDC Native Shares oder Replikation verwenden) und nicht, wenn der Consumer Rückschreiben benötigt (Delta Sharing ist read-only).

Warum es zählt

SAPs Row-Level-Security gilt weiterhin auf der Producer-Seite, sodass der Consumer stets nur die veröffentlichte Fläche sieht, nie die zugrundeliegenden HANA-Tabellen.
Der Zugriff läuft über einen an das Empfänger-Credential gebundenen Bearer-Token — sein Widerruf entzieht den Zugriff sofort, ohne dass eine separate Infrastrukturänderung nötig ist.
Es ist per Design read-only: Greifen Sie nicht darauf zurück, wenn der Consumer Rückschreiben benötigt oder die Integration hochfrequent operativ ist — verwenden Sie stattdessen BDC Native Shares.

Kernpunkte

Offenes Protokoll — jeder Delta-Sharing-kompatible Client (Databricks, Fabric, Snowflake, pandas, Spark) kann lesen; kein SAP-spezifischer Treiber erforderlich.
Producer-seitige Governance — Spaltenauswahl, Zeilenfilter pro Empfänger, Aktualisierungsrhythmus und Credential-Lifecycle werden vollständig in Datasphere gesteuert.
Row-Level-Security-Übernahme — im Datasphere-Analytic-Model definierte RLS-Regeln gelten für den veröffentlichten Share; der Empfänger sieht nur seine autorisierten Zeilen.
Bearer-Token-Authentifizierung — der Widerruf des Empfänger-Credentials entzieht den Zugriff in Sekunden; keine Schlüsselrotation, keine geteilten Geheimnisse im Code.
Read-only — für Rückschreib-Szenarien stattdessen BDC Native Shares oder HANA-Replikation verwenden.
Zu unterscheiden von den paketierten Konnektoren BDC Connect for Databricks (C166) / BDC Connect for Snowflake (C168), die Delta Sharing oder ein Äquivalent als zugrunde liegenden Mechanismus nutzen, aber einen unterstützten kommerziellen Pfad und eine SLA hinzufügen.
Ein Share je unterschiedlichem Autorisierungsbereich, nicht ein Share mit geweitetem Filter für jeden Empfänger — das Muster, das stille Überexposition verhindert.
Am besten geeignet für eine externe, plattformübergreifend generische, rein lesende, ad hoc oder explorative Integration; das falsche Werkzeug, sobald Rückschreiben oder eine verbindliche Aktualisierungs-SLA gebraucht wird.

Begriffe auf dieser Seite

Delta Sharing: Open-Source-Protokoll (ursprünglich von Databricks, heute ein Linux-Foundation-Projekt) für sicheres plattformübergreifendes Daten-Sharing ohne Kopieren; jeder kompatible Client liest einen veröffentlichten Share über HTTPS mit Bearer-Token-Authentifizierung.
Share: Eine benannte Sammlung von Datasphere-Tabellen und -Views, die für einen oder mehrere Empfänger veröffentlicht wird, mit Spaltenauswahl- und Zeilenfilter-Governance auf der Producer-Seite.
Empfänger-Credential: Der Bearer-Token, der an einen bestimmten externen Consumer gebunden ist; der Widerruf in Datasphere entzieht dessen Zugriff sofort, ohne andere Empfänger zu beeinträchtigen.
Row-Level-Security-Übernahme: Das Muster, bei dem im Datasphere-Analytic-Model definierte RLS-Regeln weiterhin für über Delta Sharing offengelegte Daten gelten — der Consumer kann sie nicht umgehen, indem er den Share direkt liest.
Semantischer Kontrakt: Die gemeinsame Definition von Fachbegriffen, Kennzahlen, Entitäten und Zugriffsregeln, die von Tools und Teams verwendet wird.
Producer (Delta Sharing): Der Datasphere-Space, der als Quelle eines Shares fungiert; er entscheidet, welche Spalten offengelegt werden, welche Zeilenfilter je Empfänger gelten und wie oft die zugrunde liegende View aktualisiert wird.
Consumer (Delta Sharing): Der externe Client — Databricks, Fabric, Snowflake oder ein maßgeschneiderter Python-/Spark-Client —, der einen veröffentlichten Share liest; er sieht nie die zugrunde liegenden Verbindungen oder Quelltabellen des Producers.
BDC Native Share: SAPs eigener governter Sharing-Mechanismus innerhalb der Business Data Cloud, getrennt vom offenen Delta Sharing, genutzt wenn ein Szenario Rückschreiben, engere SAP-seitige Integration oder eine höherfrequente operative Aktualisierung braucht, als ein rein lesender Delta Share bietet.

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 →

Offene SAP-Projekte

Aktuelle SAP-Analytics-Projekte und Stellen im DACH-Raum: SAP-Analytics-Projekte im DACH-Raum.