Data Sharing auf Databricks: Delta Sharing, Clean Rooms und Marketplace
Die Kernaussagen auf einen Blick.
- Data Sharing auf Databricks bündelt drei Wege, um Daten kontrolliert zu teilen: direkte Freigaben über Delta Sharing, gemeinsame Auswertungen in Clean Rooms und Datenprodukte über den Marketplace.
- Welcher Weg passt, hängt davon ab, wie die Zusammenarbeit aussieht: Daten direkt bereitstellen, gemeinsam auswerten oder Datenprodukte auffindbar machen.
- Governance, Egress-Kosten und die Art der Empfängeranbindung gehören vor die erste Freigabe geklärt, weil spätere Korrekturen meist aufwendig werden.
- Empfehlenswert ist, alle ausgehenden Datenflüsse einmal vollständig zu erfassen und für jeden Empfänger Verfahren, Zugriffsweg und Kostenträger festzulegen.
Inhaltsverzeichnis
Jeder Datenempfänger bringt neue Komplexität
Eine Datenplattform liefert mit der Zeit Daten an immer mehr Empfänger. Oft bekommt jeder Empfänger seinen eigenen Lieferweg. Eine Tochtergesellschaft bekommt wöchentlich CSV-Dateien über einen alten SFTP-Job. Ein Partner arbeitet in Snowflake und möchte keine Dateien mehr importieren. Das Marketing möchte Zielgruppen mit einer Werbeplattform abgleichen, ohne Kundendaten herauszugeben. Der Einkauf sucht zusätzlich externe Wetter- und Branchendaten, die über drei verschiedene Provider mit drei verschiedenen Lieferpfaden kommen.
Dieses Muster entsteht häufig, sobald eine Plattform produktiv wird und mehrere Abnehmer versorgt. Jeder Datenfluss entsteht einzeln, wird einzeln betrieben und irgendwann kaum noch aktiv gepflegt. Am Ende pflegt niemand mehr den Überblick, welche Daten das Unternehmen verlassen, wie aktuell sie sind und wer dafür verantwortlich ist.
Im Betrieb solcher Datenflüsse stellen sich immer wieder dieselben Fragen:
Wer reagiert, wenn ein Export fehlschlägt, und wer bekommt es überhaupt mit? Welche Daten verlassen das Unternehmen, in welchem Volumen, an wen? Wie schnell kann ein neuer Empfänger angebunden werden: Tage, Wochen, Monate? Welche Zusammenarbeit braucht echten Datenaustausch, und welche nur ein gemeinsames Ergebnis? Wo entstehen Kosten, die heute keinem Empfänger oder Fachbereich zugeordnet werden?
Data Sharing auf Databricks setzt genau hier an. Statt für jeden Empfänger einen eigenen Lieferpfad zu bauen, gibt es eine gemeinsame Schicht für Bereitstellung, Berechtigungen und Nachvollziehbarkeit und drei Verfahren darüber, die unterschiedliche Formen der Zusammenarbeit abdecken. Die wichtigste Arbeit ist deshalb nicht die Tool-Auswahl. Zuerst muss klar sein, welche Art der Zusammenarbeit überhaupt gebraucht wird.
Was ist Data Sharing?
Data Sharing auf Databricks umfasst drei Verfahren, die auf Delta Sharing als offenem Protokoll und Unity Catalog als Governance-Schicht aufbauen. Delta Sharing stellt freigegebene Tabellen und Dateien bereit, ohne eine zusätzliche dauerhafte Kopie anzulegen. Clean Rooms ermöglichen gemeinsame Auswertungen, ohne dass die beteiligten Parteien Rohdaten gegenseitig freigeben. Der Marketplace macht Datenprodukte auffindbar und nutzbar.
Wichtig ist die Abgrenzung zu anderen Datenprozessen. Data Sharing ist kein ETL-Werkzeug, das Daten transformiert, und kein Ersatz für eine saubere Datenmodellierung. Es ist die Schicht, über die kuratierte Daten das Unternehmen verlassen oder externe Daten bezogen werden. Was geteilt wird, muss vorher fachlich sauber definiert sein, sonst verteilt Sharing bestehende Datenprobleme nur an mehr Empfänger.
Diese Einordnung hat eine direkte Folge für die Verantwortung. Sobald Daten geteilt werden, muss die Freigabe selbst gesteuert und überwacht werden: Wer darf welche Daten lesen, wie lange und in welchem Umfang, und wie wird das protokolliert? Genau dafür ist Unity Catalog die gemeinsame Kontrollschicht. Wie Berechtigungen, Ownership und Lineage dort zusammenspielen, erklären wir im Überblick zu Unity Catalog auf Databricks. Die übergeordnete Einordnung in die Plattform findest du im Überblick zur Databricks-Plattform.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Delta Sharing, Clean Rooms und Marketplace im Überblick
Die drei Verfahren lösen unterschiedliche Aufgaben. Die einfache Abgrenzung lautet: Delta Sharing stellt Daten direkt bereit. Clean Rooms ermöglichen gemeinsame Auswertungen. Der Marketplace macht Datenprodukte auffindbar.
| Verfahren | Was geteilt wird | Was der Empfänger sieht | Typischer Anlass |
|---|---|---|---|
| Delta Sharing | freigegebene Tabellen und Dateien, zwischen zwei Databricks-Plattformen auch Notebooks und Modelle | liest die freigegebenen Daten | Datenprodukt an Partner oder Tochter liefern |
| Clean Rooms | geschützte gemeinsame Auswertung | nur freigegebene Ergebnisse, ohne Zugriff auf die fremden Rohdaten | sensible Zusammenarbeit ohne Rohdatenaustausch |
| Marketplace | katalogisierte Datenprodukte, Modelle oder Lösungen | abonniert das Listing und nutzt die bereitgestellten Daten | Datenprodukte auffindbar machen und verteilen |
Alle drei bauen technisch auf Delta Sharing auf. Das ist der zentrale Vorteil: Ein Empfänger, der einmal eingerichtet ist, kann über denselben technischen Weg unterschiedliche Freigaben nutzen. Architektonisch stehen die drei Verfahren als gleichwertige Bausteine nebeneinander, setzen aber auf demselben durchgehenden Fundament auf: Delta Sharing als offenes Transport-Protokoll mit Zero Copy, darunter Unity Catalog mit Provider, Shares, Recipients und Audit als gemeinsame Governance-Schicht.
Daten direkt an Partner und Tochtergesellschaften freigeben
Delta Sharing ist der einfachste direkte Weg: Ein Anbieter definiert eine Freigabe aus Tabellen, Schemas oder Volumes, ein Empfänger erhält Lesezugriff, und der Empfänger liest die Daten direkt aus dem Speicher des Anbieters. Eine separate Export-Pipeline, die Kopien aktuell halten muss, entfällt. Der Empfänger braucht dafür nicht zwingend Databricks; ein Delta-Sharing-kompatibler Client genügt, von Power BI über Snowflake bis zu Pandas und Spark.
Damit ist Delta Sharing der Standardweg für ausgehende Datenflüsse an Tochtergesellschaften, Partner und andere Plattformen, einschließlich der wachsenden Bereitstellung ohne zusätzliche dauerhafte Kopie zu SAP Business Data Cloud. Wie das Provider-Recipient-Modell, die beiden Betriebsmodi und die Empfänger-Anbindung funktionieren und wo die Grenzen liegen, vertiefen wir im Überblick zu Delta Sharing auf Databricks.
Gemeinsam analysieren, ohne Rohdaten zu teilen
Ein Clean Room passt dann, wenn mehrere Parteien ein gemeinsames Ergebnis erzeugen wollen, ihre Rohdaten aber nicht gegenseitig freigeben dürfen. Die Daten bleiben bei den jeweiligen Parteien, die Auswertung läuft in einer kontrollierten, von Databricks verwalteten Umgebung, und nur vorab freigegebene Ergebnisse verlassen die Umgebung. Typische Anlässe sind Zielgruppenabgleiche mit Werbeplattformen, gemeinsame Modellprojekte über Unternehmensgrenzen, konzernweite Kennzahlen, ohne alle Rohdaten zentral zu sammeln, und Forschungskooperationen mit sensiblen Daten.
Ein Clean Room ersetzt keine rechtliche Prüfung und keine saubere Anonymisierung; auch Ergebnisse können weiterhin personenbezogen oder sensibel sein. Databricks beschreibt Clean Rooms als Aufsatz auf Delta Sharing und Serverless-Compute. Wann sich der zusätzliche Aufwand lohnt und welche Compliance-Fragen davorgehören, behandeln wir separat im Überblick zu Databricks Clean Rooms.
Datenprodukte und Modelle auffindbar verteilen
Der Marketplace ist die Katalog- und Verteilungsschicht über Delta Sharing. Statt jede externe Datenquelle einzeln zu suchen, zu verhandeln und anzubinden, werden Daten-, Modell- und Lösungsangebote in einem Katalog auffindbar, und die Bereitstellung erfolgt über Delta Sharing direkt in Unity Catalog des Empfängers. Das kann die Beschaffung externer Datenquellen deutlich vereinfachen und schafft einen Weg, eigene Datenprodukte zu verteilen, ohne für jeden Empfänger eine eigene Bereitstellung aufzubauen.
Der Marketplace garantiert aber weder Datenqualität noch rechtliche Nutzbarkeit; beides hängt weiterhin vom Anbieter und vom Vertrag ab. Databricks betreibt ihn als offenen Marktplatz für Daten, Analytics und KI. Welche Listing-Familien es gibt und wie man Lieferanten bewertet, zeigen wir im Überblick zu Databricks Marketplace.
Delta Sharing vs Clean Rooms vs Marketplace: Welches Verfahren passt wann?
Die Auswahl sollte sich aus dem Anwendungsfall ergeben, nicht aus Gewohnheit oder dem gerade verfügbaren Werkzeug. Drei Fragen reichen oft für die erste Einordnung.
Soll ein Empfänger die Daten direkt lesen und weiterverarbeiten? Dann ist Delta Sharing der einfachste Weg. Ein Partner, eine Tochtergesellschaft oder ein BI-Team liest die freigegebenen Tabellen und arbeitet damit weiter. Das passt für laufend aktuelle Datenstände, für mehrere Empfänger derselben Tabellen und für Anbindungen über Plattformgrenzen hinweg.
Sollen mehrere Parteien gemeinsam auswerten, ohne Rohdaten herauszugeben? Dann ist ein Clean Room das passende Verfahren. Wichtig ist ein klarer Analysezweck mit eindeutigem Ergebnis und eine vorab geklärte Rechtsgrundlage. Ohne diesen klaren Zweck erzeugt ein Clean Room oft mehr Aufwand als Nutzen.
Sollen Datenprodukte auffindbar sein oder viele Empfänger erreichen? Dann lohnt der Marketplace, als Beschaffungskanal für externe Daten und Modelle und als Distributionsweg für eigene Listings. Wenn viele einzelne Freigaben unübersichtlich werden, ist ein katalogisiertes Datenprodukt meist der sauberere Weg.
Die Verfahren können nebeneinander genutzt werden. Eine typische Plattform betreibt Delta Sharing für bilaterale Partner, stellt ein internes Datenprodukt im Marketplace bereit und richtet einen Clean Room für eine klar abgegrenzte regulierte Zusammenarbeit ein, die ihn wirklich braucht. Und es gibt Fälle, in denen keines der drei Verfahren passt: Wenn regulatorisch eine eingefrorene Kopie erforderlich ist oder der Empfänger ein festes Zielformat verlangt, bleibt der klassische Dateiexport die richtige Wahl.
Sobald Daten das Unternehmen verlassen, wird Governance zur eigentlichen Frage. Unity Catalog hält die drei Verfahren zusammen: Anbieter, Freigaben und Empfänger werden dort zentral angelegt und berechtigt, und Erstellung, Änderung und Entzug von Freigaben landen in den Auditdaten.
Drei Punkte sind für Entscheider besonders relevant. Erstens die Sichtbarkeit der Empfängeraktivität: System-Tables zeigen, welcher Empfänger wann auf welche freigegebenen Daten zugreift und in welchem Volumen. Das ist die Basis für ein Reporting über ausgehende Datenflüsse und für eine Kostenzuordnung pro Empfänger. Zweitens die Datenminimierung vor der Freigabe: Dynamische Views können Zeilen und Spalten schon auf Empfänger-Eigenschaften beschränken, bevor die Freigabe genutzt wird. Drittens die Grenze der Nachvollziehbarkeit: Der Anbieter sieht den Lesezugriff, aber nicht jede Weiterverarbeitung beim Empfänger. Für vollständige regulatorische Nachweise braucht es deshalb zusätzlich vertragliche Regelungen.
Diese Kontrollschicht ist der Grund, warum Data Sharing auf Databricks mehr ist als reine Datenübertragung. Ohne klare Ownership, Klassifikation und einen dokumentierten Lebenszyklus der Empfängerfreigaben wird aus jeder Freigabe ein dauerhaftes Risiko, das niemand mehr überblickt.
Was Zero Copy Sharing wirklich kostet
Zero Copy bedeutet, dass keine zusätzliche dauerhafte Datenkopie entsteht. Es bedeutet aber nicht, dass der Zugriff kostenlos ist. Beim Zugriff werden die Daten über das Netzwerk übertragen, und Cloud-Anbieter berechnen ausgehenden Datenverkehr, sobald Daten eine Region oder Cloud verlassen.
Für die Kostenbetrachtung sollten drei Posten getrennt betrachtet werden. Auf der Provider-Seite fallen Egress-Kosten an, wenn der Empfänger außerhalb der Storage-Region liegt; innerhalb derselben Region ist das meist unkritisch, regions- oder cloudübergreifend kann es deutlich steigen. Dazu kommt ein kleiner Compute-Anteil für die Bereitstellung der Freigabe. Und auf der Empfänger-Seite entstehen die Abfragekosten in dessen eigenem Werkzeug. Diese letzte Position wird in Verhandlungen häufig übersehen: Beim Anbieter sinkt der Betriebsaufwand, während beim Empfänger neue Abfragekosten entstehen, die vorher niemand eingeplant hat.
Sinnvoll ist deshalb, vor dem ersten produktiven Share pro Empfänger ein Egress-Profil abzuschätzen und die Kostenverantwortung zu klären. Empfänger in derselben Region sind selten ein Thema. Cloudübergreifende Freigaben mit hohem Lesevolumen gehören dagegen gesondert geprüft, mit klar zugewiesener Budget-Verantwortung.
Open Sharing und Databricks-to-Databricks Sharing richtig einordnen
Quer zu den drei Verfahren liegt eine Frage, die fast jede konkrete Freigabe betrifft: wie sich der Empfänger anmeldet. Delta Sharing kennt dafür zwei Betriebsmodi, und die Wahl bestimmt den späteren Verwaltungsaufwand.
Databricks-to-Databricks Sharing gilt, wenn beide Seiten Databricks mit Unity Catalog betreiben. Die Anbindung läuft über die Metastore-Identitäten beider Plattformen, ohne dass Zugangsdaten ausgetauscht werden. Dieser Modus erlaubt zusätzlich das Teilen von dynamischen Views, Notebooks und Modellen und ist für konzerninterne Töchter oder Partner mit eigener Databricks-Plattform der ruhigere Weg.
Open Sharing gilt für alle Empfänger außerhalb von Databricks, etwa in Snowflake, Power BI, Pandas oder Spark. Hier authentifiziert sich der Empfänger entweder über ein langlebiges Bearer-Token oder über OIDC-Federation an den eigenen Identity Provider. Die Token-Variante verlangt einen klaren Prozess für Ausgabe, Rotation und Entzug; OIDC-Federation verlagert diese Aufgabe an den Identity Provider des Empfängers und senkt damit die laufende Token-Pflege.
In den meisten Plattformen gilt die Faustregel: Databricks-to-Databricks, wo beide Seiten die Plattform nutzen, und Open Sharing nur für externe Empfänger. Welcher Modus im Detail wie eingerichtet wird, vertiefen wir im Überblick zu Delta Sharing auf Databricks.
Wie sich Data Sharing für AI-Assets und Iceberg weiterentwickelt
Im Juni 2026 hat Databricks mit OpenSharing die Weiterentwicklung des Delta-Sharing-Protokolls vorgestellt, ebenfalls Open Source. Das Grundprinzip bleibt gleich: Bereitstellung ohne zusätzliche Kopie, Governance über Unity Catalog. Der Geltungsbereich wird über Tabellen und Dateien hinaus erweitert.
Drei Erweiterungen sind für die mittelfristige Planung relevant. Erstens KI-Assets in Freigaben: Modelle und Genie Agents mit ihrem semantischen Kontext lassen sich auf demselben Weg teilen wie Daten. Zweitens Iceberg-Interoperabilität: Shares können von Apache-Iceberg-kompatiblen Clients gelesen werden, und aus externen Katalogen wie AWS Glue oder Snowflake Horizon lässt sich freigeben. Drittens On-Premises- und Storage-Partner: Datenbestände außerhalb der Cloud rücken über Storage-Partner in Reichweite.
Für heutige Tabellen- und Datei-Freigaben ändert das zunächst wenig; sie laufen unverändert über Delta Sharing. OpenSharing sollte im Blick bleiben, sobald KI-Assets, Iceberg-Clients oder Quellen außerhalb von Databricks Teil der Sharing-Strategie werden. Mehrere Bausteine sind noch in Preview und sollten vor einem produktiven Setup geprüft werden.
Fazit
Data Sharing wird interessant, sobald dieselben Daten regelmäßig an mehrere Partner oder Töchter gehen: die Wahl zwischen den drei Verfahren richtet sich nach der Art der Zusammenarbeit.
Data Sharing auf Databricks wird vor allem dann interessant, wenn dieselben Daten regelmäßig an mehrere Partner, Tochtergesellschaften oder externe Abnehmer verteilt werden müssen und die Pflege der einzelnen Liefer- und Kollaborationswege zum Betriebsproblem wird. Besonders relevant ist das für Plattformen, die mehrere Tochtergesellschaften im Konzernverbund beliefern, für BI-Modernisierungen, bei denen Power BI oder Tableau direkt auf freigegebene Daten zugreifen, und für Unternehmen, die externe Daten und Modelle systematisch beziehen oder eigene Datenprodukte verteilen wollen.
Gute erste Anwendungsfälle sind wöchentliche Dateilieferungen an Tochtergesellschaften, die heute viel Pflege verursachen, ein internes Datenprodukt für mehrere Geschäftsbereiche und eine klar abgegrenzte regulierte Zusammenarbeit, die einen Clean Room wirklich rechtfertigt. Wer diese Probleme nicht hat, braucht Data Sharing nicht zwingend als nächstes Projekt. Und wo regulatorisch eine eingefrorene Kopie oder ein festes Zielformat erforderlich ist, bleibt der klassische Export die richtige Antwort.
Die eigentliche Entscheidung hängt von der Art der Zusammenarbeit ab: Daten direkt bereitstellen, gemeinsam auswerten oder Datenprodukte verteilen. Daran hängen Verfahren, Betriebsmodus, Kostenträger und Governance-Aufwand.
Erfasst zuerst alle ausgehenden Datenflüsse vollständig und legt je Empfänger Verfahren, Modus und Kostenträger fest, bevor das nächste Export- oder Kollaborations-Projekt budgetiert wird. Token-Verwaltung und Lebenszyklus der Empfängerfreigaben gehören dabei ins Initial-Setup und nicht in eine spätere Nacharbeit.
Wo Delta Sharing, Clean Rooms oder Marketplace euren Betrieb entlasten
Am wirkungsvollsten ist dieser Schritt, bevor der nächste Lieferweg gebaut wird. Im ersten Databricks BI & SQL Architecture Review gehen wir eure ausgehenden Datenflüsse konkret durch und zeigen unverbindlich, wo Delta Sharing, Clean Rooms oder der Marketplace den Betrieb spürbar entlasten.
- welche eurer ausgehenden Datenflüsse sich sofort für Delta Sharing, Clean Rooms oder den Marketplace eignen
- welche Risiken bei Governance, Egress und Kosten vor der ersten Aktivierung auf den Tisch gehören
- welcher Sharing-Ansatz konkret zu eurer Empfängerlandschaft und eurem Cloud-Setup passt
FAQ
Data Sharing auf Databricks umfasst drei Verfahren, die auf Delta Sharing als offenem Protokoll und auf Unity Catalog als Governance-Schicht aufsetzen: direkte Freigaben über Delta Sharing, Clean Rooms für gemeinsame Auswertungen ohne Rohdatenaustausch und der Marketplace als Katalog- und Verteilungsschicht für Datenprodukte. Die Bereitstellung erfolgt ohne zusätzliche dauerhafte Kopie.
