Delta Sharing

Delta Sharing ist eine offene Spezifikation für herstellerunabhängiges Datenteilen zwischen Systemen und Clouds. Es ist ein technischer Bauplan, mit dem eine Organisation (der Anbieter) einer anderen (dem Empfänger) Lesezugriff auf Tabellen und Dateien gibt, ohne die Daten zu kopieren. Ein Sharing-Server beim Anbieter prüft die Berechtigung und schickt dem Empfänger zeitlich begrenzte Download-Links auf die Dateien. Ein Sharing-Client (Zugriffsprogramm, z. B. in Power BI, Tableau, Pandas oder Spark) liest die Daten direkt beim Empfänger, live und ohne Zwischenkopie.

Was ist Delta Sharing?

Delta Sharing (auch Delta Sharing Protocol) bezeichnet ein Protokoll, das über gewöhnliche Web-Aufrufe (REST, also HTTPS-Anfragen wie bei jeder Webseite) läuft. Zwei Rollen sind beteiligt: der Sharing-Server auf Anbieter-Seite und der Sharing-Client auf Empfänger-Seite. Der Client fragt beim Server, welche Objekte (Tabellen, Dateien) freigegeben sind. Der Server prüft die Zugriffsrechte und antwortet mit kurzlebigen, signierten Download-Links (pre-signed URLs) auf die eigentlichen Datendateien im Cloud-Speicher (Object Storage) des Anbieters. Der Client lädt die Dateien anschließend direkt aus diesem Speicher. Der Empfänger muss weder eine Kopie ablegen noch eine anbieter-spezifische Software installieren.

Die Spezifikation wurde 2021 von Databricks als offener Standard veröffentlicht und in die Linux Foundation (Delta-Lake-Projekt) überführt. Die Protokoll-Spezifikation liegt öffentlich unter [delta.io/sharing](https://delta.io/sharing/), die Referenz-Implementierung im [delta-io/delta-sharing-Repository auf GitHub](https://github.com/delta-io/delta-sharing) enthält einen Scala-Server und Clients in Python (Pandas), Spark, Java und Rust. Power BI und Tableau binden Delta Sharing über eigene Konnektoren an.

Delta Sharing unterstützt zwei Betriebsmodi. Im Open Sharing liegen Provider und Recipient auf beliebigen Systemen; der Recipient braucht nur einen kompatiblen Client und authentifiziert sich per Bearer Token oder über OIDC-Federation gegen den Identity Provider des Recipients. Im Databricks-to-Databricks-Sharing laufen beide Seiten auf Databricks Unity Catalog, die Verbindung ist identitätsbasiert und kommt ohne Token-Austausch aus; zusätzlich lassen sich in diesem Modus dynamische Views, Notebooks und Modelle teilen, die im offenen Modus nicht Teil des Share-Objekts sind.

Auf Provider-Seite besteht die Sharing-Konfiguration im Unity Catalog aus drei Governance-Objekten. Der Share ist der Container für die freigegebenen Objekte (Tabellen, Views, Volumes, Notebooks und Modelle). Der Recipient identifiziert den Empfänger (per Token oder föderierter Identität). Der Provider registriert den Anbieter selbst mit Metadaten für die Gegenseite. Zeilen- und Spaltenfilter werden über dynamische Views oder Row-Level-Security-Policies auf Provider-Seite ausgewertet, sodass der Recipient nur die genehmigten Zeilen sieht.

Das Protokoll existiert, weil der Markt für Cross-Vendor-Data-Sharing vor 2021 durch proprietäre Formate fragmentiert war: Snowflake Secure Data Sharing setzte Snowflake auf beiden Seiten voraus, BigQuery Analytics Hub band an BigQuery, AWS Data Exchange an AWS-Konten. Delta Sharing entkoppelt das Sharing-Protokoll vom Compute-System und macht die Delta-Lake-Speicherform (Parquet-Dateien plus Transaction-Log) zum Interoperabilitäts-Substrat zwischen Plattformen.

Abgrenzung zu Data Sharing, Data Marketplace, Clean Rooms und anbieter-nativen Sharing-Funktionen

Delta Sharing wird regelmäßig mit vier verwandten Konzepten verwechselt. Die Unterscheidung entscheidet, welches Werkzeug für einen konkreten Anlass passt.

Data Sharing ist der übergreifende Praxis-Begriff für die Live-Freigabe von Datensätzen zwischen Systemen oder Organisationen ohne physische Kopie. Delta Sharing ist eine konkrete offene Spezifikation aus dieser Familie. Data Sharing kann auch anbieter-nativ oder über klassische Extraktion erfolgen; Delta Sharing definiert das vendor-neutrale Protokoll und ist damit ein Baustein dieser Familie.

Ein Data Marketplace ist die Katalog- und Discovery-Schicht mit Lizenz- und Bestell-Workflow, die über einem Sharing-Layer liegt. Der Databricks Marketplace nutzt Delta Sharing als Transport-Protokoll: Das Front-End beantwortet „Wie werden Datenprodukte gefunden und lizenziert", die Sharing-Spezifikation darunter beantwortet „Wie wird Zugriff transportiert". Ohne Marketplace bleibt Delta Sharing eine Direktfreigabe zwischen zwei benannten Parteien.

Data Clean Rooms teilen keine Datensätze. Sie führen vorab freigegebene Berechnungen in einer isolierten Compute-Umgebung aus und geben nur vereinbarte Aggregate frei. Delta Sharing transportiert dagegen Zugriff auf Zeilen und Spalten im Rahmen der Views und Filter. Databricks Clean Rooms setzen intern auf Delta Sharing plus Serverless-Compute mit Output-Gate; das Sharing-Protokoll ist Bestandteil der Architektur und ersetzt das Clean-Room-Konstrukt nicht.

Anbieter-native Sharing-Funktionen sind an ihre jeweilige Plattform gebunden. Snowflake Secure Data Sharing setzt Snowflake auf beiden Seiten voraus und löst Cross-Region- oder Cross-Cloud-Konstellationen über interne Replikation. BigQuery Analytics Hub bindet an BigQuery, AWS Data Exchange an AWS-Konten. Delta Sharing ist demgegenüber cross-vendor: Der Recipient braucht weder einen Databricks-Vertrag noch eine kompatible Datenbank; Client-Bibliotheken decken Pandas, Power BI, Tableau, Spark und generische HTTP-Clients ab.

Beispiel: Cross-Cloud-Analytics ohne Vertragsgleichheit

Ein typischer Einsatzfall ist die Freigabe einer Delta-Tabelle über Cloud- und Vertragsgrenzen hinweg. Ein Konzern-Provider betreibt seine Datenplattform auf Databricks in einer AWS-Region, während die Tochtergesellschaft BI-Reporting mit Power BI auf Azure macht (ohne eigenen Databricks-Vertrag).

Der Provider legt im Unity Catalog einen Share „Sales_Positions" an, fügt die freigegebene Tabelle hinzu und definiert einen Recipient für die Tochter. Für Open Sharing generiert der Provider eine Credential-Datei mit einem zeitlich begrenzten Bearer Token, alternativ richtet er eine OIDC-Federation gegen den Entra-ID-Tenant der Tochter ein. Die Tochter öffnet die Freigabe direkt in Power BI über den Delta-Sharing-Connector, liest die Live-Daten und baut ihren Report auf der Referenz auf. Eine Ingestion-Pipeline, eine parallele Kopie oder ein SFTP-Prozess entstehen dabei nicht.

Analog funktioniert das Zero-Copy-Sharing zwischen SAP Business Data Cloud und Databricks: SAP BDC nutzt Delta Sharing intern, um semantische Views wie Finanzbelege oder Sendungspositionen an einen Databricks-Workspace freizugeben. Der Databricks-Recipient sieht die Objekte im eigenen Unity Catalog und joint sie mit Kundendaten für ein Forecast-Modell. Die Ownership der Daten bleibt bei der SAP-Domäne, jeder Zugriff wird im Sharing-Backend protokolliert, und Widerruf oder Scope-Änderung erfolgen vom Provider aus.

Innerhalb eines Konzerns wird dasselbe Muster für Data-Mesh-Föderation genutzt. Die Domäne Vertrieb stellt das Datenprodukt „Opportunity-Pipeline" als Share bereit, die Domänen Finanzen und Controlling mounten den Share in ihre eigenen Unity Catalogs. Ein dynamischer View auf Provider-Seite filtert die Zeilen so, dass Controlling nur aggregierte Regionaldaten sieht, während Finanzen die Detailtiefe erhält. Die Filterlogik läuft beim Provider, der Recipient sieht nur, was der Filter durchlässt.