Delta Sharing Databricks: Daten direkt teilen statt ETL exportieren

Delta Sharing ist ein offener Standard für die sichere Bereitstellung von Tabellen und Dateien auch zwischen unterschiedlichen Plattformen und Cloud-Anbietern. Der Standard ist als Open Source veröffentlicht (delta-io/delta-sharing auf GitHub), inklusive Referenz-Server und Referenz-Clients in Python, Spark, Power BI und Pandas. Die Protokoll-Spezifikation steht auf delta.io/sharing, die Databricks-Integration ist in der Delta-Sharing-Dokumentation beschrieben.

Delta Sharing funktioniert auch über Databricks hinaus. Der Empfänger muss Databricks nicht selbst nutzen, sondern nur ein Tool einsetzen, das Delta Sharing unterstützt. Dadurch ist der Austausch weniger stark an eine einzelne Plattform gebunden als bei Lösungen wie Snowflake Secure Data Sharing, BigQuery Analytics Hub oder Fabric OneLake Sharing, die primär innerhalb ihres jeweiligen Ökosystems funktionieren.

Delta Sharing unterstützt zwei Betriebsmodi. Die Wahl entscheidet vor allem darüber, wie sich der Empfänger authentifiziert und wie viel Verwaltungsaufwand später entsteht. In der Praxis verteilt Delta Sharing Daten oft an eine Mischung aus Empfängern: Databricks-Partner binden die Freigabe über ihren eigenen Unity Catalog schreibgeschützt ein (Databricks-zu-Databricks-Modus), während ein Nicht-Databricks-Partner auf beliebiger Cloud oder on-premises über Open Sharing mit Werkzeugen wie Power BI, Apache Spark, pandas, Tableau oder Java zugreift. Die Daten liegen provider-seitig in beiden Fällen unverändert im Cloud Storage.

Open Sharing kommt zum Einsatz, wenn der Empfänger kein eigenes Databricks-System nutzt. Dafür gibt es zwei Authentifizierungswege.

Der klassische Weg ist ein Bearer Token. Der Anbieter erstellt Zugangsdaten für den Empfänger, übermittelt sie sicher als Credential File, und der Empfänger greift anschließend mit einem Delta-Sharing-kompatiblen Client auf die freigegebenen Daten zu. Wichtig ist dabei: Wer Zugriff auf dieses Token hat, kann auch die für diesen Empfänger freigegebenen Daten lesen. Token können mit einem Ablaufdatum versehen und rotiert werden. In der Praxis müssen deshalb Ausgabe, sichere Speicherung, Ablauf, Rotation und Widerruf sauber geregelt werden, etwa wenn sich Zuständigkeiten ändern oder ein externer Partner keinen Zugriff mehr erhalten soll.

Der neuere Weg ist OIDC-Federation. Dabei wird kein langlebiges Databricks-Token an den Empfänger übergeben. Stattdessen nutzt Databricks den Identity Provider des Empfängers, zum Beispiel Microsoft Entra ID oder Okta. Dieser stellt kurzlebige JWTs aus, die Databricks gegen eine Federation Policy prüft. In dieser Policy wird festgelegt, welcher Issuer, welcher Subject Claim und welche konkrete Identität auf den Share zugreifen darf, also etwa ein Nutzer, eine Gruppe, ein Service Principal oder eine OAuth-App.

Für interaktive Nutzer wird ein User-to-Machine-Flow genutzt, bei dem MFA greift, sofern sie im Identity Provider des Empfängers vorgeschrieben ist. Für automatisierte Workloads gibt es einen Machine-to-Machine-Flow auf Basis von OAuth Client Credentials. Secrets müssen dabei nicht zwischen Anbieter und Empfänger ausgetauscht werden. Die Lebensdauer der Tokens steuert der Identity Provider des Empfängers. Damit entfällt eine der kritischsten Aufgaben im Open Sharing: die Verwaltung langlebiger Zugangsdaten durch den Anbieter. Für externe Empfänger, die ohnehin Entra ID oder Okta einsetzen, ist OIDC-Federation daher meist die bessere Wahl als ein statisches Bearer Token. Details zur Einrichtung beschreibt die Databricks-Dokumentation zur OIDC-Federation.

Databricks-zu-Databricks-Sharing eignet sich, wenn beide Seiten Databricks mit Unity Catalog einsetzen. Die beiden Umgebungen werden über ihre eindeutigen Plattformidentitäten miteinander verbunden. Eine separate Token-Datei muss nicht ausgetauscht werden, und der Aufwand für die regelmäßige Erneuerung externer Zugangsdaten entfällt. Der Empfänger kann die geteilten Daten anschließend mit den gewohnten Unity-Catalog-Rechten an seine eigenen Nutzer weitergeben.

Dieser Modus bietet außerdem zusätzliche Möglichkeiten, die im reinen Open Sharing nicht verfügbar sind. Dazu gehören unter anderem das Teilen von dynamischen Views, Notebooks und AI-Modellen.

Welcher Modus passt, hängt ausschließlich von der technischen Umgebung des Empfängers ab:

Eine pragmatische Faustregel hat sich in den meisten Plattform-Setups bewährt: Databricks-zu-Databricks verwenden, wenn beide Seiten die Plattform einsetzen, weil Anmeldung und Berechtigungen einfacher zentral verwaltet werden können. Open Sharing nur für Empfänger außerhalb von Databricks einsetzen, und dort, wo der Empfänger einen eigenen Identity Provider betreibt, OIDC-Federation dem statischen Bearer Token vorziehen. Die häufigste Falle: ein Open-Share an einen internen Empfänger einzurichten, weil es „schneller geht", und dauerhaft zusätzliche Prozesse für Zugangsdaten betreiben müssen.

Wie einfach die Anbindung ist, hängt stark vom System und der Cloud des Empfängers ab. Vier Gruppen sind im Plattform-Alltag relevant:

Andere Databricks-Workspaces. Die einfachste Konstellation. Mit Unity Catalog auf beiden Seiten ist Databricks-zu-Databricks-Sharing mit vergleichsweise wenig Konfigurationsaufwand eingerichtet. Etwa nach Unternehmenszukäufen oder bei getrennten Geschäftsbereichen. Volumes und Notebooks gehen direkt mit.

Power BI. Der Power-BI-Connector für Delta Sharing ist GA. Power BI verbindet sich über die bereitgestellten Zugangsdaten mit dem Share, sieht den Share als Datenquelle und die Daten können direkt abgefragt oder in Power BI importiert werden. Ein zusätzlicher Exportprozess nur für Power BI kann dadurch entfallen, ohne dass Power BI direkt am Lakehouse hängen muss.

Snowflake, Fabric, BigQuery. Die Anbindung ist grundsätzlich möglich, unterscheidet sich aber bei Funktionsumfang und Betriebsaufwand. Ein Snowflake-Konto kann einen Delta Sharing Recipient über externe Funktionen oder über die Snowflake-Marketplace-Mechanik anbinden. Snowflake liest die Daten dabei über eine externe Delta-Sharing-Verbindung, also ausdrücklich keine native Snowflake-Sharing-Funktion. Microsoft Fabric kann freigegebene Tabellen über OneLake-Verknüpfungen anbinden. Für BigQuery existieren Lese-Adapter, die produktiv nutzbar sind, aber mit mehr Einschränkungen als bei einer vollständig nativen Anbindung.

SAP Business Data Cloud (BDC). Ein zunehmend relevanter Austausch zwischen SAP und Databricks. SAP nutzt Delta Sharing als Mechanismus für Zero-Copy-Sharing zwischen Databricks und BDC: SAP-Anwendungen können auf freigegebene Lakehouse-Daten zugreifen, ohne klassische Exportdateien zu erzeugen. Umgekehrt können auch SAP-Daten für Databricks bereitgestellt werden, die SAP über Delta Sharing exponiert. Wie der konkrete Anbindungspfad zwischen Databricks und SAP-BDC aussieht und welche Governance-Themen er aufwirft, zeigen wir im SAP-Pendant zu Zero-Copy Delta Sharing zwischen SAP BDC und Databricks.

Python-, Spark- und eigene Anwendungen. Über den Open-Source-Client lässt sich jeder Empfänger anbinden, der Python oder Spark betreibt. Eine flexible Option für interne und externe Anwendungen: ein Risk-Reporting-Team mit eigenem Jupyter-Stack, ein internes Daten-Produkt mit eigener Compute-Schicht, ein interner Data-Science-Workspace ohne eigenen Databricks-Account. Auch hier müssen die Zugangsdaten sicher verwaltet und regelmäßig erneuert werden.

Über die Existenz eines Connectors hinaus entscheidet, in welcher Cloud und Region die Daten gespeichert sind, wo die Empfänger sitzen, über welche Regionen und Clouds die Daten übertragen werden und welche Antwortzeiten für den Empfänger noch akzeptabel sind. Cloudübergreifende Freigaben sind möglich, können aber hohe Transferkosten und längere Ladezeiten verursachen, und das Latenz-Profil ist deutlich schlechter als Same-Region-Sharing.

Es muss zwischen der Anbieter- und der Empfängerseite unterschieden werden.

Auf der Provider-Seite läuft alles über Unity Catalog. Anlage, Änderung und Entzug von Freigaben werden in den Auditdaten protokolliert. System-Tables liefern Recipient-Aktivität: welcher Empfänger wann auf welche freigegebenen Tabellen zugreift, in welchem Volumen. Das ist die Basis für ein internes Reporting darüber, wer welche Daten abgreift, und für ein Compliance-Modell, das ausgehende Datenflüsse genauso behandelt wie eingehende.

Nach dem Lesezugriff kann der Anbieter nicht mehr vollständig nachvollziehen, wie der Empfänger die Daten weiterverwendet. Der Empfänger kann die Daten weiterverarbeiten, speichern oder in Berichten verwenden. Der Provider sieht nur den Lesezugriff. Diese weitere Nutzung muss vor allem über Verträge und organisatorische Regeln gesteuert werden, technisch nur eingeschränkt. Unternehmen, die den gesamten weiteren Datenfluss lückenlos nachweisen müssen, etwa für regulatorisches Reporting, müssen berücksichtigen, dass Delta Sharing nur den Zugriff bis zur Freigabegrenze dokumentiert.

Dynamische Views können bereits vor der Freigabe Daten auf die benötigten Zeilen und Spalten beschränken. Sie filtern Zeilen und Spalten basierend auf Recipient-Eigenschaften, bevor der Share überhaupt geliefert wird. Damit lässt sich Row-Level- und Column-Level-Security in den Share einbauen, ohne dass der Empfänger selbst zusätzliche Filter umsetzen muss. Diese Mechanik gibt es im Databricks-zu-Databricks-Modus voll, im Open Sharing eingeschränkt.

Die sichere Verwaltung der Zugangsdaten ist die größte organisatorische Herausforderung bei Open Sharing mit Bearer Token. Die Tokens können über längere Zeit gültig bleiben (typischerweise mehrere Monate), übergeben werden sie meist per Datei. Jede Person oder Anwendung mit Zugriff auf das Token kann die freigegebenen Daten abrufen. Personalwechsel beim Empfänger, kompromittierte Endgeräte, ungesicherte Mail-Übergabe: alles ein dauerhaftes Sicherheitsrisiko, wenn Tokens nicht regelmäßig erneuert und entzogen werden. Empfehlenswert ist, Open Sharing mit Bearer Token nur mit dokumentierter Token-Verwaltung freizugeben, mit einer möglichst kurzen und verbindlich festgelegten Gültigkeitsdauer und mit einem klar benannten Verantwortlichen beim Empfänger.

OIDC-Federation entschärft dieses Problem, weil es kein langlebiges Databricks-Token mehr gibt, das übergeben, gespeichert und rotiert werden muss. Die Tokens stellt der Identity Provider des Empfängers aus, er bestimmt auch ihre Lebensdauer. Multi-Faktor-Authentifizierung und Sperrung laufen über die Richtlinien dieses Identity Providers, und Databricks prüft die Tokens nur noch gegen die Federation-Policy. Für Empfänger mit eigenem Identity Provider wandert die Verwaltung der Zugangsdaten damit aus dem manuellen Betrieb in eine bereits vorhandene Identitäts-Infrastruktur. Betreibt der Empfänger keinen geeigneten Identity Provider, bleibt das Bearer Token der Weg, und die dokumentierte Token-Verwaltung gilt weiter.

Delta Sharing ist eines von drei Sharing-Verfahren in der Databricks-Familie, und die Abgrenzung ist Architektur-relevant.

Delta Sharing Mit Delta Sharing erhält ein Empfänger direkten Lesezugriff auf freigegebene Daten. Du gibst eine Tabelle frei, der Empfänger liest. Volumen und Identität des Empfängers sind dem Provider sichtbar, der Empfänger kann die freigegebenen Daten selbst weiterverarbeiten (gegebenenfalls über dynamische Views gefiltert).

Clean Rooms eignen sich dagegen für gemeinsame Berechnungen, bei denen die Rohdaten nicht direkt geteilt werden sollen. Mehrere Parteien lassen ihre Daten in einer geschützten Umgebung gemeinsam auswerten, lassen darauf zugelassene Queries laufen, und ausgegeben werden nur vorher festgelegte Ergebnisse. Sinnvoll für Datenpartnerschaften zwischen Wettbewerbern, für Audience-Analysen ohne PII-Austausch, für Forschungs-Kooperationen.

Marketplace macht Datenprodukte auffindbar und erleichtert deren Bereitstellung an viele Interessenten. Ein Provider veröffentlicht ein Daten-Produkt im Databricks Marketplace, Konsumenten finden, abonnieren, lesen. Alles läuft über Delta Sharing als technisches Protokoll im Hintergrund. Wenn viele Datenprodukte und Empfänger verwaltet werden und direkte Einzel-Freigaben unübersichtlich werden, kann ein katalogisiertes Datenprodukt im Marketplace sinnvoller sein.

Die drei Verfahren ergänzen sich und sollten je nach Art der Zusammenarbeit eingesetzt werden. Zwei davon vertiefen wir in eigenen Artikeln: Clean Rooms für die kollaborative Auswertung ohne Rohdatenzugriff und der Databricks Marketplace als Distributions-Layer für Datenprodukte. Den Überblick über alle Verfahren gibt der Artikel Data Sharing auf Databricks.

Delta Sharing ist inzwischen produktiv nutzbar, deckt aber nicht jedes Austauschmodell ab und hat Eigenheiten, die vor der produktiven Nutzung benannt gehören.

Empfänger können freigegebene Daten lesen, aber nicht zurückschreiben. Schreibender Zugriff über einen Share ist nicht vorgesehen und auch nicht geplant. Sollen beide Seiten Daten bereitstellen, muss jede Seite einen eigenen Share anbieten.

Delta Sharing ist nicht für eine sekundengenaue Übertragung laufender Ereignisse gedacht. Presigned URLs werden ausgestellt, Manifest-Files gelesen, Files heruntergeladen. Für Echtzeit-Streaming bleiben Kafka, Event Hubs oder vergleichbare Dienste besser geeignet. Aktualisierte Tabellen können zwar geteilt werden, der Empfänger sieht jedoch nur den jeweils bereitgestellten Tabellenstand.

Nicht alle Inhaltsarten werden von jedem Empfänger und jeder Cloud gleich gut unterstützt. Volume-Sharing ist GA, für Dateien, Notebooks und Modelle stehen weniger kompatible Clients zur Verfügung als für Tabellen. Notebook- und AI-Model-Sharing funktionieren nur Databricks-zu-Databricks und setzen passende Berechtigungen auf der Empfänger-Seite voraus. Der aktuelle Funktionsumfang sollte deshalb vor der Einführung geprüft werden.

Freigaben zwischen verschiedenen Clouds können höhere Kosten und längere Ladezeiten verursachen. Daten von Azure nach AWS zu sharen funktioniert. Die Egress-Kosten und die Latenz machen es selten zur ersten Wahl, wenn der Empfänger viel liest. Für gelegentliche Datenübergaben tragbar, für häufige direkte BI-Abfragen ist eine cloudübergreifende Verbindung oft unwirtschaftlich.

Der Anbieter sieht, dass Daten gelesen wurden, aber nicht jede weitere Verarbeitung beim Empfänger. Auf der Empfänger-Seite verlierst du Lineage. Was der Empfänger mit den Daten macht, steht in seiner Plattform. Für lückenlose regulatorische Nachweise über die weitere Nutzung sind zusätzliche Vereinbarungen und Kontrollen beim Empfänger erforderlich.

Open Sharing benötigt einen verbindlichen Prozess für Zugangsdaten. Ohne sauberen Rotations-Prozess entsteht ein Sicherheitsrisiko mit Halbjahres-Halbwertszeit. Token-Rotation und Recipient-Lifecycle gehören in einen dokumentierten Prozess. Eine manuell gepflegte Liste reicht für einen sicheren laufenden Betrieb nicht aus.

Diese Einschränkungen sollten bereits bei der Auswahl der ersten Empfänger berücksichtigt werden. Dadurch lassen sich spätere Kosten-, Sicherheits- und Betriebsprobleme reduzieren.