Data Science & KI

Delta Sharing

In diesem Blogartikel wird erklärt, wie Delta Sharing als offenes Protokoll das Zero Copy Prinzip im Kontext moderner Datenplatformen skalierbar macht.

Im ersten Artikel („Zero Copy in modernen Datenplattformen“) ging es um das Prinzip: weniger Datenkopien, mehr gemeinsame Datenebene ,schnellere Time-to-Value. In der Praxis stellt sich dann sofort die Umsetzungsfrage: Wie teile ich Daten zwischen Plattformen so, dass es für Anwender simpel ist – und für Security & Governance sauber kontrollierbar bleibt? Genau dafür wurde Delta Sharing entwickelt.

Was ist Delta Sharing?

Delta Sharing ist ein offenes, REST-basiertes Protokoll, mit dem ein Datenanbieter (Provider) Datensätze aus Cloud-Object-Storage (z. B. S3, ADLS, GCS) mit Empfängern (Recipients) teilen kann – ohne die Daten physisch zu duplizieren. Im Kern ist es damit eine sehr direkte technische Umsetzung des Zero-Copy-Gedankens.

Wichtig dabei: Delta Sharing ist nicht „ein Exportformat“, sondern ein standardisiertes Protokoll um Metadaten, Zugriffskontrolle und den Zugriffspfad so zu kapseln, dass unterschiedliche Tools und Plattformen sicher auf dieselben Daten zugreifen können.

Wie funktioniert Delta Sharing – verständlich, aber korrekt?

Wie so viele Kommunikationsprotokolle ist das Delta Sharing Protokoll in unterschiedliche Schichten abstrahiert worden.

Die zwei Ebenen, die man sich wie „Steuerung“ und „Transport“ vorstellen kann, sind folgende:

Control Plane (Steuerung): Wer darf was sehen? Welche Tabellen werden geteilt? Welche Policies gelten? Logging, Auditing, Metadaten.
Data Plane (Datenfluss): Der eigentliche Datenstrom läuft direkt vom Object Storage zum Client.

Das Protokoll kennt zentrale Objekte wie Provider, Recipient, Share, Schema und Table.

Der Empfänger nutzt eine Profil-Datei oder eine OIDC-basierte URL, um die geteilten Tabellen zu adressieren (sinngemäß <profile>#<share>.<schema>.<table>). Er ruft dann über REST Metadaten und Dateilisten ab. Für die eigentlichen Daten bekommt er kurzlebige, signierte Zugriffsinformationen (z. B. pre-signed URLs), und liest die Daten direkt aus dem Storage.

So entsteht ein sehr wichtiges Ergebnis: Der Provider behält Kontrolle, der Recipient bekommt eine „native“ Leseerfahrung. In Databricks kann das sogar so wirken, als lägen die Daten im eigenen Katalog: Ein Data Engineer kann per einfachem SELECT zugreifen, obwohl die Daten physisch in einer anderen Plattform liegen – etwa in der SAP Business Data Cloud.

Sicherheit: „Geteilt“ heißt nicht „offen“

Delta Sharing ist für Governance-orientierte Umgebungen gebaut. Typische Bausteine sind:

Identity-Föderation über OpenID Connect (OIDC), z. B. im Machine-to-Machine Flow,
kurzlebige Zugriffstoken/URLs auf den Storage, die das Risiko dauerhaft gültiger Schlüssel reduzieren,
Governance-Mechanismen wie Row-/Column-Level Security (je nach Plattform), plus Auditierbarkeit.

Für Entscheider ist zentral: Wenn weniger Kopien existieren, wird Governance i. d. R. einfacher, da man nicht mehr dutzende Schattenkopien „nachregieren“ muss.

Wo Delta Sharing heute besonders relevant ist

Databricks: Unity Catalog + Open Sharing

Databricks beschreibt Delta Sharing als Weg, Daten aus einem Unity-Catalog-fähigen Workspace an Nutzer „auf jeder Computing-Plattform“ zu teilen. Außerdem gibt es Databricks-to-Databricks Sharing, das den Zugang für Empfänger in Databricks-Umgebungen noch stärker integriert.

SAP Business Data Cloud (BDC) + Databricks: Data Products ohne ETL nutzen

SAP BDC stellt Business Data Products bereit, und über den BDC Connector können diese per Delta Sharing in Databricks konsumiert werden – inklusive bidirektionalem Sharing.

Auch Databricks selbst hebt die Integration als „live, zero-copy“ hervor, um SAP-Semantik einfacher für Analytics und AI zu nutzen.

Zwei Use Cases, die den Nutzen greifbar machen

Use Case 1: SAP-nahe Daten für AI/Analytics, ohne Datenreplikation

Ein kuratiertes Data Product (z. B. „Sales Orders“) wird in SAP BDC freigegeben. Ein Team in Databricks nutzt es sofort für Feature Engineering oder Forecasting – ohne dass erst Extraktions- und Staging-Pipelines gebaut werden müssen.

Typische Effekte: schneller Start, weniger „Pipeline-Ballast“, geringeres Risiko widersprüchlicher Kopien.

Use Case 2: Partner daten teilen – kontrolliert und skalierbar

Ein OEM teilt ausgewählte Datenprodukte mit Lieferanten. Diese können die Daten in ihrer eigenen Plattform nutzen, ohne CSV-Exporte, ohne manuelle Dateiübertragung, und mit klarer Zugriffskontrolle.

Gerade bei wiederkehrenden Partner-Use-Cases (Quality, Supply Chain, Nachhaltigkeitsreporting) ist der Standardisierungseffekt hoch.

Best Practices: So wird Delta Sharing in der Realität erfolgreich

Starten Sie mit Data Products statt „Tabellen-Suppe“: Definieren Sie fachlich sinnvolle Produkte, nicht nur technische Tabellen.

Schreiben Sie einen Data Contract: Welche Felder sind stabil, welche dürfen sich ändern? Welche SLAs gelten?

Planen Sie Performance & Kosten: Partitionierung und Clustering helfen, ein Blick auf Egress-/Netzwerkkosten verhindert Überraschungen.

Auditing von Anfang an: Wer greift worauf zu? Welche Shares werden wie genutzt? Databricks verweist hierfür explizit auf Audit Logs und Monitoring.

Fazit

Delta Sharing macht Zero Copy operativ: Es schafft eine standardisierte, sichere Brücke zwischen Datenplattformen, bei der Daten „am Ort“ bleiben und dennoch einfach konsumierbar sind.

Wenn Sie das Grundprinzip noch einmal strukturiert einordnen wollen (inkl. Varianten wie Shortcuts und Zero-Copy-Clones), lesen Sie gerne den vorausgegangenen Artikel: „Zero Copy in modernen Datenplattformen: Das Prinzip, die Varianten und der Business-Mehrwert“.