Von Delta Sharing zu OpenSharing: Was sich geändert hat und wie es weitergeht

Delta Sharing war jahrelang die Methode, mit der Tausende von Organisationen Live-Daten über Clouds und Plattformen hinweg austauschten, ohne sie zu kopieren. Im Juni 2026 gaben Databricks und die Linux Foundation bekannt, dass sich Delta Sharing zu OpenSharing weiterentwickelt hat – einem offenen, anbieterneutralen Protokoll für den Austausch nicht nur von Tabellen, sondern auch von dem breiteren Spektrum an Assets, auf das KI-Teams heute angewiesen sind: Agentenfähigkeiten, KI-Modellen und unstrukturierten Daten. Wenn Sie Daten bereits über Delta Sharing austauschen oder prüfen, wie Sie mit Partnern bei Daten- und KI-Assets zusammenarbeiten können, zeigt dieser Beitrag, was OpenSharing genau ist, was sich im Hintergrund geändert hat und wohin sich das Projekt entwickelt.

Eine kurze Zusammenfassung: Was Delta Sharing gelöst hat

Als Databricks Delta Sharing auf dem Data + AI Summit 2021 vorstellte, war das zugrundeliegende Problem leicht zu benennen, aber schwer zu lösen: Organisationen wollten Live-Daten mit Partnern, Kunden und anderen Teams teilen, ohne Dateien zu exportieren, fehleranfällige ETL-Jobs einzurichten oder jeden Empfänger auf dieselbe Plattform zu zwingen. Delta Sharing wurde als offenes Protokoll an die Linux Foundation übergeben, basierend auf Delta Lake und Parquet. So konnte ein Anbieter den Zugriff auf eine Tabelle gewähren und ein Empfänger konnte diese direkt und in Echtzeit abfragen – über Tools wie Apache Spark, Power BI, Tableau, pandas und viele andere.

Dieses offene Zero-Copy-Modell fand großen Anklang. Delta Sharing entwickelte sich zum am weitesten verbreiteten offenen Protokoll für den sicheren Datenaustausch und wird laut Databricks von Unternehmen wie Amadeus, Atlassian, LSEG, SAP, Stripe und The Trade Desk für die übergreifende Zusammenarbeit über Clouds und Plattformen hinweg genutzt (Databricks-Pressemitteilung). Als Databricks im Juni 2026 OpenSharing ankündigte, hatte Delta Sharing mehr als 28.000 Datenempfänger erreicht, wobei etwa ein Drittel der Freigaben über offene Konnektoren plattformübergreifend erfolgte, statt auf den Databricks-zu-Databricks-Austausch beschränkt zu bleiben (Databricks-Blog).

Warum sich Delta Sharing weiterentwickeln musste

Der Datenaustausch ging bereits weit über Tabellen hinaus. Durch den Databricks-zu-Databricks-Austausch tauschten Teams schon Jahre vor dem Aufkommen von Agenten Sichten, Mengen unstrukturierter Dateien, Notebooks und registrierte ML-Modelle aus, sodass strukturierte Daten nie die ganze Geschichte waren. Was durch Agenten verändert wurde, war die Art des Assets, das verschoben werden musste, und die Distanz, die es zurücklegen musste. Agentenfähigkeiten, die Agenten selbst und der semantische Kontext, auf dem sie basieren, erforderten denselben verwalteten Zero-Copy-Zugriff, den der Datenaustausch bereits bewiesen hatte. Unternehmen wollten diesen Zugriff zudem über Plattformen hinweg und über Databricks-zu-Databricks-Verbindungen hinaus nutzen. Da sich das offene Protokoll jedoch nach wie vor auf Tabellen konzentrierte, fielen diese neueren Assets aus dem heraus, was ein offener, plattformübergreifender Datenaustausch tatsächlich leisten konnte.

Gleichzeitig forderten Unternehmen kontinuierlich zwei zusammenhängende Dinge: eine breitere Interoperabilität mit Formaten wie Apache Iceberg und eine Möglichkeit, Daten aus lokalen Umgebungen (On-Premises) oder Private Clouds in dasselbe verwaltete Freigabemodell einzubinden, ohne sie vorher migrieren zu müssen. Um beide Lücken zu schließen, reichte es nicht aus, lediglich Funktionen hinzuzufügen; der Anwendungsbereich von Delta Sharing musste grundlegend überdacht werden.

Was OpenSharing tatsächlich ist

Am 10. Juni 2026 gaben Databricks und die Linux Foundation gemeinsam OpenSharing als die nächste Evolutionsstufe von Delta Sharing bekannt (Databricks-Pressemitteilung, Pressemitteilung der Linux Foundation). Präzision ist hier wichtig, da OpenSharing auf zwei verschiedenen Ebenen arbeitet:

1. Ein Open-Source-Protokoll und eine Spezifikation, die von Databricks beigesteuert wurden und nun als Projekt unter der Linux Foundation AI & Data Foundation entwickelt werden. Die Spezifikation steht unter der Apache-2.0-Lizenz und ist auf GitHub verfügbar, wo jeder Anbieter oder Community-Mitglied sie völlig unabhängig von Databricks implementieren kann (GitHub, OpenSharing).
2. Databricks OpenSharing, die Unternehmensimplementierung dieses Protokolls innerhalb der Databricks-Plattform, integriert in Unity Catalog, Databricks Marketplace und Clean Rooms.

Das offene Ökosystem geht über das Protokoll selbst hinaus. Der Open-Source Unity Catalog, ein ebenfalls unter der Linux Foundation verwaltetes Apache-2.0-Projekt, bietet einen anbieterneutralen Katalog und eine Governance-Ebene für diese Assets, sodass ein Team ihn mit einem offenen Freigabeserver koppeln und eine verwaltete Freigabe vollständig außerhalb von Databricks ausführen kann (GitHub, Unity Catalog).

Matei Zaharia, Mitbegründer und CTO von Databricks, formulierte diesen Schritt so: „Delta Sharing hat bewiesen, dass sich die Branche für Offenheit statt für Insellösungen entscheidet. OpenSharing überträgt dieses Prinzip auf den gesamten KI-Stack und erweitert gleichzeitig das plattformübergreifende Ökosystem auf Iceberg-Empfänger und lokale Anbieter“ (Databricks-Pressemitteilung). Jim Zemlin, CEO der Linux Foundation, fügte hinzu, das Ziel sei „ein gemeinsames, anbieterneutrales Framework, das Unternehmen in die Lage versetzt, KI-Assets sicher und interoperabel über Plattformen und Ökosysteme hinweg auszutauschen“ (Pressemitteilung der Linux Foundation).

Eine Klarstellung vorab: Bestehende Delta Sharing-Clients und -Integrationen bleiben mit OpenSharing kompatibel. Dies ist eine Weiterentwicklung des Protokolls und kein Bruch damit, und das Repository delta-io/delta-sharing existiert weiterhin parallel zur neuen GitHub-Organisation OpenSharing-IO/OpenSharing.

Diagramm: Delta Sharing entwickelt sich zu OpenSharing, das als offene Protokollebene auf GitHub sowie als Databricks-Unternehmensimplementierungsebene fungiert und neue Reichweite für Iceberg REST Catalog-Clients sowie lokalen oder Private-Cloud-Speicher bietet.

Was sich technisch geändert hat

Ein breiteres Asset-Modell. Das ursprüngliche offene Delta Sharing-Protokoll konzentrierte sich auf Tabellen, obwohl der Databricks-zu-Databricks-Austausch längst mehr Asset-Typen umfasste. OpenSharing bringt dieses breitere Modell in die offene Spezifikation selbst ein und führt eine Share → Schema → Asset-Hierarchie ein, die die Freigabe über Tabellen hinaus auf neue Asset-Typen ausdehnt, darunter Volumes (Dateiverzeichnisse in einem beliebigen Format), Agentenfähigkeiten und KI-Modelle (GitHub, OpenSharing). Dies bedeutet, dass ein Anbieter ein Datenprodukt zusammenstellen kann, das sowohl die zugrundeliegenden Tabellen als auch die darauf aufbauenden KI-Assets umfasst, und das Ganze über ein einziges Protokoll teilen kann.

Diagramm: Die Asset-Hierarchie von OpenSharing. Tabellen, Volumes, Agentenfähigkeiten und Modelle sind die aktuellen spezifizierten Asset-Typen. Agenten- sowie Seiten- oder Glossartypen werden als Community-Vorschläge aufgeführt, die noch diskutiert werden.

Unterstützung für den Iceberg REST Catalog. OpenSharing fügt Unterstützung für Clients hinzu, die mit dem Apache Iceberg REST Catalog (IRC) kompatibel sind, sodass Anbieter Daten für jede Iceberg-kompatible Engine freigeben können – nicht nur für native Delta Sharing-Clients. Databricks beschreibt dies als eine Ausweitung der Reichweite des offenen Datenaustauschs auf Organisationen, die auf Iceberg-Tools standardisiert sind (Databricks-Produktseite).

Reichweite für lokale und Private-Cloud-Umgebungen. Über das Databricks Storage Ecosystem können Speicheranbieter einen OpenSharing-Server betreiben, der direkt mit Unity Catalog verbunden ist. So können Daten, die in lokalen Umgebungen oder einer Private Cloud liegen, verwaltet und geteilt werden, ohne sie vorher zu migrieren (Databricks-Blog). Die Integration von MinIO AIStor ist allgemein verfügbar, während weitere Speicherpartner als Vorschau verfügbar oder für später im Jahr 2026 zugesagt sind.

Zero-Copy-Anmeldeinformationsverwaltung bleibt das Modell. Anbieter verschieben keine Daten, um sie zu teilen. Der Freigabeserver stellt temporäre, bereichsspezifische Anmeldeinformationen aus, und der Server selbst befindet sich außerhalb des Datenpfads – ganz im Einklang mit der Funktionsweise von Delta Sharing (GitHub, OpenSharing).

Neue Freigabefunktionen. Parallel zur Protokolländerung hat Databricks mehrere Funktionen auf Basis von OpenSharing eingeführt:

• SecureConnect (allgemein verfügbar), ein von Databricks verwalteter Proxy, der die Notwendigkeit überflüssig macht, Firewall- oder Netzwerkregeln für jeden neuen Empfänger zu konfigurieren (Databricks-Blog).
• Global Distribution (Private Preview), wodurch gemeinsam genutzte Daten näher an Empfänger über Regionen und Clouds hinweg repliziert werden, um die Latenz zu reduzieren und die Egress-Kosten vorhersehbarer zu machen.
• Genie Agent Sharing (Beta) ermöglicht es Anbietern, konversationalen Zugriff auf Daten in natürlicher Sprache mit externen Partnern zu teilen, inklusive Kontrollmöglichkeiten für Kontingente und die offengelegte zugrunde liegende Logik.
• Lakebase table und change data feed sharing (Public Preview) zum Teilen von Live-Betriebsdaten ohne separaten ETL-Schritt.

Governance an die Linux Foundation übergeben. OpenSharing wurde an die Linux Foundation AI & Data Foundation übergeben, wo es sich derzeit in der Sandbox-Phase befindet. Dies ist die Einstiegsphase für neue Projekte dieser Foundation, bevor sie in die Inkubationsphase übergehen (GitHub, OpenSharing und opensharing.io). Änderungen an der Spezifikation durchlaufen einen öffentlichen Vorschlags- und Prüfungsprozess, anstatt einseitig entschieden zu werden. Dies ist dasselbe Governance-Muster, dem Delta Lake und Delta Sharing als Projekte der Linux Foundation bereits gefolgt sind.

Was das bedeutet, wenn Sie Delta Sharing bereits nutzen

Wenn Sie bereits Freigaben, Empfänger und Konnektoren eingerichtet haben, bleibt das alles erhalten. OpenSharing ist additiv: Ihre bestehenden Tabellen, Konnektoren und Workflows funktionieren weiterhin, und die neuen Asset-Typen und Funktionen stehen zur Verfügung, sobald Sie sie nutzen möchten. Das Aktivieren von OpenSharing für einen Unity Catalog-Metastore ist ein Konfigurationsschritt und keine Migration. Der bekannte Workflow für das Erstellen von Freigaben (Create Share), Empfängern (Create Recipient) und das Erteilen von Zugriffsberechtigungen (Grant Access) gilt auch für neue Asset-Typen, sobald diese verfügbar sind (Databricks-Dokumentation).

Für Teams, die bisher benutzerdefinierte Integrationen gepflegt haben, um Agenten-Fähigkeiten oder Modell-Artefakte zwischen Plattformen zu verschieben, liegt der praktische Nutzen in einem einzigen Satz offener APIs für Erkennung, Autorisierung und Zugriff – anstelle von separaten, maßgeschneiderten Pipelines für jeden Partner und jeden Asset-Typ.

Was noch auf der Roadmap steht

Einige der im Juni 2026 angekündigten Funktionen befinden sich ausdrücklich noch in einem frühen Stadium und sind zum heutigen Zeitpunkt noch nicht allgemein verfügbar. Das Teilen externer Iceberg-Tabellen, mit dem Anbieter Tabellen aus externen Katalogen direkt teilen können, befand sich beim Start in der Public Preview; die allgemeine Verfügbarkeit wurde für bald angekündigt. Auch das E-Mail-basierte Teilen, bei dem ein Anbieter einen Mitarbeiter durch die Eingabe einer E-Mail-Adresse anstelle eines längeren Einrichtungsprozesses einladen kann, wurde bei der Ankündigung als demnächst verfügbar aufgeführt.

Über das hinaus, was Databricks verbindlich bereitstellen möchte, listet die öffentliche Roadmap des OpenSharing-Projekts auf GitHub eine Reihe von Community-Vorschlägen auf, die noch offene Designfragen und keine finalen Funktionen darstellen. Dazu gehören die Unterstützung beim Teilen von Evaluierungsdatensätzen und Benchmarks mit eingeschränktem Zugriff, das Teilen synthetischer Datensätze mit Provenienz-Metadaten sowie ein vorgeschlagener Asset-Typ zum Teilen vorab berechneter Vektorindizes (OpenSharing ROADMAP.md). Da es sich hierbei um Community-Vorschläge handelt, können sich Zeitpläne und der finale Umfang ändern. Es ist daher ratsam, diese auf GitHub zu verfolgen, anstatt sie als feste Termine zu betrachten.

OpenSharing nimmt zudem eine spezifische Ebene innerhalb eines umfassenderen, sich schnell entwickelnden Sets offener Standards für KI ein. Wie Akram Chetibi, Director of Product Management bei Databricks, es ausgedrückt hat, lösen Protokolle für die Kommunikation von Agent zu Tool und Agent zu Agent ein anderes Problem als OpenSharing: „OpenSharing stellt APIs zur Verfügung, um den Zugriff auf gespeicherte Assets wie Agenten-Fähigkeiten oder KI-Modelle zu entdecken und zu autorisieren“ (diginomica). Dieses Unterscheidungsmerkmal zu verstehen ist wichtig, wenn Sie eine Architektur entwerfen, bei der beide Arten von Protokollen Hand in Hand arbeiten müssen.

Erste Schritte

Wenn OpenSharing für Sie neu ist, funktioniert der Einstieg genauso wie bei Delta Sharing: Aktivieren Sie OpenSharing im Unity Catalog-Metastore, der die Daten verwaltet, die Sie teilen möchten. Erstellen Sie eine Freigabe mit den Assets, die Sie bereitstellen möchten, legen Sie einen Empfänger an und erteilen Sie diesem Zugriff (Databricks-Dokumentation). Danach können Sie entscheiden, ob sich ein bestimmter Empfänger über Databricks-zu-Databricks-Freigabe, Databricks-zu-Open-Freigabe für Nicht-Databricks-Empfänger oder über einen selbst gehosteten OpenSharing-Server verbinden soll, falls Sie das Protokoll vollständig außerhalb von Databricks betreiben möchten. Bitte beachten Sie beim Lesen der Dokumentation, dass das Protokoll und die Marke als ein Wort – OpenSharing – geschrieben werden, während in der Plattformdokumentation für den Modus zum Teilen mit Empfängern außerhalb von Databricks die kleingeschriebene Formulierung „Databricks-zu-Open-Freigabe“ verwendet wird.

Vertiefende Informationen:

• Lesen Sie die ursprüngliche Ankündigung von Databricks und der Linux Foundation.
• Lesen Sie die technische Deep-Dive-Analyse Introducing OpenSharing: the Next Evolution of Delta Sharing for the Agentic Era.
• Entdecken Sie die Protokollspezifikation und Roadmap auf GitHub.
• Gehen Sie die Schritte zur Einrichtung in der Databricks-Dokumentation zu OpenSharing durch.
• Erfahren Sie mehr über das Anbinden von On-Premises- und Private-Cloud-Speichern in der Ankündigung zum Databricks Storage Ecosystem.

Delta Sharing hat die Art und Weise verändert, wie Teams über den Datenaustausch zwischen Plattformen denken. OpenSharing überträgt diesen offenen Zero-Copy-Ansatz auf die Assets, auf denen eine agentenbasierte Welt basiert. Wenn Sie heute bereits Daten mit Delta Sharing teilen, ist der nächste logische Schritt zu prüfen, welche weiteren Inhalte in Ihrem Tech-Stack auf dieselbe Weise geteilt werden könnten – sei es eine Agenten-Fähigkeit, ein Modell oder eine Reihe unstrukturierter Dateien. Probieren Sie aus, OpenSharing für einen Unity Catalog-Metastore in Ihrem Workspace zu aktivieren, oder lesen Sie sich zunächst die Protokollspezifikation auf GitHub durch, um zu sehen, wie sich eine selbst gehostete Implementierung in Ihre eigene Plattform einfügen könnte.

Bereit, OpenSharing auszuprobieren? Aktivieren Sie es für einen Unity Catalog-Metastore in Ihrem Workspace oder lesen Sie die Protokollspezifikation auf GitHub, um zu sehen, wie eine selbst gehostete Implementierung zu Ihrer Plattform passen könnte. Haben Sie Fragen oder Feedback? Wenden Sie sich an Ihr Databricks-Kontoteam, öffnen Sie ein Issue im OpenSharing-GitHub-Repository oder nehmen Sie an der Diskussion in der Databricks Community teil.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag