Data Sharing: Definition, Delta Sharing, Abgrenzung

Data Sharing ist die kontrollierte Freigabe von Daten an andere Systeme oder Unternehmen, ohne die Daten zu kopieren. Der Empfänger sieht die Daten live beim ursprünglichen Anbieter, statt eine eigene Kopie zu bekommen. Möglich wird das über ein Freigabe-Protokoll wie Delta Sharing (eine offene technische Spezifikation für Datenfreigabe) oder über die Sharing-Funktion einer bestimmten Datenplattform; jede Freigabe ist über Regeln, Rechte und Protokollierung (Audit-Logs) abgesichert.

Was ist Data Sharing?

Data Sharing (auf Deutsch Datenaustausch oder Datenweitergabe) beschreibt eine Art des Datenzugriffs, bei dem die Daten beim Anbieter (Provider) bleiben und der Empfänger (Recipient) eine Live-Verbindung zu den Daten bekommt, statt eine eigene Kopie. Es gibt keinen Datei-Export, keine Übertragung per SFTP (ein klassisches Datei-Übertragungs-Protokoll) und keine zweite, parallel gepflegte Kopie beim Empfänger. Die Grenze zwischen zwei Systemen oder Organisationen gehört zur Definition dazu. Eine Freigabe innerhalb derselben Datenbank läuft als normale Berechtigung, nicht als Data Sharing.

Technisch existieren zwei Betriebs-Familien. Offene Protokolle wie [Delta Sharing](https://delta.io/sharing/) sind als Spezifikation frei verfügbar (Delta Sharing wurde 2021 von Databricks initiiert und in die Linux Foundation überführt); auf der Client-Seite sprechen Spark, Pandas, Power BI, Tableau, Java und Rust die Spezifikation, unabhängig von der Datenbank des Konsumenten. Anbieter-native Sharing-Funktionen wie [Snowflake Secure Data Sharing](https://docs.snowflake.com/en/user-guide/data-sharing-intro) binden Provider und Recipient dagegen an dieselbe Plattform (Snowflake ↔ Snowflake), Cross-Region und Cross-Cloud werden über interne Replikation gelöst. BigQuery Analytics Hub und AWS Data Exchange folgen analogen Modellen innerhalb der jeweiligen Cloud.

Jede Freigabe kennt drei Rollen. Der Provider definiert das Share-Objekt, dessen Scope (welche Tabelle, welche Spalten, welche Zeilen), den Empfänger und die Gültigkeit. Der Recipient mountet die Freigabe in den eigenen Katalog oder Workspace und konsumiert lesend. Ein optionaler Broker oder Marketplace legt Discovery, Lizenz und Bestell-Workflow als Katalog-Schicht über den Sharing-Layer, etwa der [Databricks Marketplace](https://www.databricks.com/product/marketplace) auf Basis von Delta Sharing.

Governance-seitig braucht jede Freigabe ein Katalog-Objekt (bei Databricks: der Share im Unity Catalog), einen Recipient-Eintrag, definierte Objekte im Share (Tabellen, Views, Volumes, Notebooks, Modelle) und ein Audit-Log über die Zugriffe. Zeilenfilter, Spalten-Masking, Widerruf und Ablauf gehören zum Sharing-Modell selbst, sind also unabhängig vom Transport implementiert. Der Begriff Data Sharing hat sich etabliert, weil er die Lücke zwischen klassischem Datenexport (Kopie mit Aktualisierungs-Drift und doppelter Governance-Verantwortung) und reinem Katalog (nur Metadaten, kein Zugriff) schließt und die Live-Referenz zum Standard-Konsum-Pattern zwischen Systemen und Unternehmen macht.

Abgrenzung zu Data Marketplace, Data Product, Clean Room und Replication

Data Sharing wird regelmäßig mit vier benachbarten Konzepten verwechselt, die technisch und funktional getrennte Aufgaben lösen.

Konzept	Was passiert	Kontrollpunkt
Data Sharing (z. B. Delta Sharing)	Live-Freigabe eines Datensatzes an einen benannten Recipient	Share + Recipient-Berechtigung
Data Marketplace	Discovery, Lizenz und Bereitstellung von Datenprodukten	Katalogeintrag + Lizenz
Data Product	Verwaltbares Daten-Artefakt mit Owner, Contract und SLO	Ownership + Data Contract
Data Clean Room	Gemeinsame Berechnung auf mehreren Datenbeständen	Output-Gate im geteilten Compute
Data Replication	Physische Kopie beim Konsumenten mit eigener Aktualisierung	Kopie- und Ingest-Pipeline

Ein Data Marketplace fügt Discovery, Lizenz und Bestell-Workflow als Katalog-Schicht über Sharing hinzu. Sharing bleibt darunter der Transport-Layer. Ohne Marketplace ist Sharing eine Direktfreigabe zwischen zwei benannten Parteien; wer Discovery durch Dritte braucht, benötigt zusätzlich einen Marketplace-Aufsatz.

Ein Data Product ist das Artefakt selbst (eine Tabelle, ein View, ein Feature-Set oder ein Modell-Endpunkt mit Owner, versioniertem Schema, Contract und SLO). Sharing ist der Bereitstellungs-Mechanismus, über den ein Data Product einem Konsumenten zugänglich gemacht wird. Ein Data Product kann auch ohne Sharing existieren (interner Zugriff innerhalb einer Domäne), und eine Freigabe kann auch eine reine Tabelle ohne Product-Status transportieren; die beiden Konzepte greifen typischerweise ineinander, sind aber trennbar.

Ein [Data Clean Room](/insights/glossar/clean-rooms/) teilt keine Datensätze. Die Rohdaten bleiben bei ihren Eigentümern, und eine isolierte Compute-Umgebung führt vorab freigegebene Berechnungen aus; die Umgebung verlassen ausschließlich vereinbarte Aggregate. Sharing gibt dagegen einen Datensatz zum Lesen frei; der Recipient sieht Zeilen und Spalten im Rahmen der Sharing-Policies. Für Werbe-Overlap-Analysen und Cross-Organisation-Modell-Trainings ohne Rohdatenaustausch sind Clean Rooms das passende Muster; für Live-Referenzen auf gemeinsame Datenprodukte ist Sharing der Standard.

Data Replication und klassischer ETL-Export erzeugen eine physische Kopie beim Konsumenten. Der Recipient betreibt einen eigenen Ingest, verwaltet Latenz und Drift, hält doppelte Speicher- und Governance-Verantwortung. Sharing liefert stattdessen eine Live-Referenz auf die Quelle, es entstehen beim Recipient keine dauerhaften Kopien der Daten. Wenn eine Kopie unvermeidbar ist (etwa wegen Air-Gap-Netzen oder anbieter-spezifischer Retention), bleibt Replication die richtige Wahl.

Beispiel: SAP-Daten über Zero-Copy-Sharing an einen Databricks-Workspace

Ein typischer Einsatzfall ist das Cross-System-Sharing zwischen SAP Business Data Cloud und einem analytischen Databricks-Workspace. Ein Konzern will Finanzbelege, Materialstammdaten oder Sendungsstatus aus dem SAP-System für Analytics und ML im Databricks-Umfeld verfügbar machen, ohne die klassische Extraktions-Pipeline (SFTP, Batch-Nightly, doppelte Governance-Verantwortung) zu bauen.

Der Anbieter (die SAP-Fachdomäne mit Business Data Cloud) legt einen Share im internen BDC-Katalog an, wählt die freigegebenen Objekte (etwa den semantischen View „Sendungspositionen") und benennt den Recipient (den Databricks-Workspace mit seinem Unity-Catalog-Endpunkt). Der Transport läuft über Delta Sharing als offene Spezifikation, sodass beim Recipient keine BDC-native Client-Library nötig ist. Der Konsument sieht die Objekte anschließend im Unity Catalog wie eine lokale Tabelle, joint sie mit den eigenen Kundendaten und trainiert darauf ein Forecast-Modell. Die Ownership bleibt bei der SAP-Domäne, jeder Zugriff ist im Sharing-Audit protokolliert, und Widerruf oder Scope-Änderungen sind vom Provider aus jederzeit möglich.

Das interne Data-Mesh-Muster funktioniert analog. Die Domäne Vertrieb stellt das Datenprodukt „Opportunity-Pipeline" als Share im Unity Catalog bereit; die Domänen Finanzen und Controlling mounten den Share in ihre eigenen Kataloge und kombinieren die Daten mit ihrem Forecast. Der Cross-Cloud-Fall folgt demselben Muster: Ein Anbieter auf einer Cloud stellt eine kuratierte Delta-Tabelle bereit, der Recipient auf einer anderen Cloud öffnet den Share mit pandas oder Power BI und arbeitet auf der Live-Referenz.