Databricks Streaming: OpenSharing statt Datei-Exporte

Nächtliche CSV-Exporte, SFTP-Verbindungen und Abgleiche fehlender Datensätze: Der regelmäßige Datenaustausch mit Partnern verursacht oft mehr Betriebsaufwand als die eigentliche Auswertung. Mit OpenSharing lässt sich Databricks Streaming direkt auf freigegebene Delta-Tabellen anwenden. Databricks beschreibt dafür einen konkreten Implementierungsweg. Für mittelständische Unternehmen mit Azure und Databricks eröffnet das eine Alternative zu individuell gebauten Exportstrecken – sofern Tabellenhistorie, Änderungsverarbeitung und Verantwortlichkeiten sauber geregelt sind.

Kurz gesagt: OpenSharing ermöglicht Empfängern, freigegebene Delta-Tabellen mit Structured Streaming inkrementell zu lesen, wenn die Freigabe die Tabellenhistorie einschließt. Checkpoints speichern den Verarbeitungsstand; für Änderungen und Löschungen auf Zeilenebene ist Change Data Feed der passende Zugriffspfad. Dadurch können separate Datei-Exporte entfallen, während die nachgelagerte Verarbeitung weiterhin beim Empfänger liegt.

Was zeigt Databricks beim Streaming mit OpenSharing?

Databricks zeigt, wie Empfänger eine freigegebene Delta-Tabelle als inkrementelle Quelle für Structured Streaming nutzen, statt wiederkehrende Datei-Lieferungen einzulesen. Im Mittelpunkt steht eine Implementierungsanleitung, keine pauschale Ankündigung einer neu eingeführten Streaming-Funktion.

Der beschriebene Hauptweg ist Databricks-to-Databricks, kurz D2D: Beide Seiten nutzen Databricks, und der Empfänger greift über einen freigegebenen Katalog in Unity Catalog auf die Tabelle zu. Apache Spark verarbeitet die Daten und hält den Lesefortschritt in einem Checkpoint fest.

Damit verschiebt sich die technische Schnittstelle. Statt Dateinamen, Übertragungszeitpunkte und Importlisten abzustimmen, vereinbaren beide Seiten eine freigegebene Tabelle mit definiertem Inhalt und Änderungsverhalten. Der Anbieter verwaltet die Quelle und ihre Freigabe; der Empfänger verantwortet seine Verarbeitung.

Wichtig ist die Unterscheidung zwischen Zugriff und Speicherung: OpenSharing benötigt keinen separaten Exportbestand für jeden Empfänger. Wer Daten für eigene Auswertungen lokal materialisiert, erzeugt aber weiterhin eine eigene Kopie. „Ohne Export“ bedeutet also nicht automatisch „ohne zusätzliche Datenspeicherung“.

Warum ist das für den deutschen Mittelstand relevant?

OpenSharing kann den Integrationsaufwand senken, wenn ein Unternehmen regelmäßig Tabellendaten mit mehreren Partnern austauscht und dafür bislang eigene Export- und Importprozesse betreibt. Besonders interessant ist das für bestehende Azure-Databricks-Umgebungen, weil sich die Verarbeitung in vorhandene Datenpipelines einordnen lässt.

Ein denkbares Einsatzfeld sind Bestandsinformationen zwischen Hersteller und Vertriebspartnern. Werden ausschließlich Dateien geliefert, brauchen Korrekturen, verspätete Lieferungen und Löschungen zusätzliche Vereinbarungen. Eine gemeinsam definierte Tabellenschnittstelle kann diese Abstimmung vereinfachen. Sie ersetzt allerdings nicht die fachliche Klärung, was etwa ein verfügbarer Bestand tatsächlich bedeutet.

Für Deine Datenplattform lautet die entscheidende Architekturfrage deshalb: Brauchst Du einen weiteren Transportprozess oder einen kontrollierten Zugriff auf ein bestehendes Datenprodukt?

Die größten Vorteile entstehen dort, wo wiederkehrende Exporte tatsächlich entfallen können. Verlangt ein Geschäftspartner weiterhin eine feste Dateischnittstelle, bleibt ein entsprechender Bereitstellungsweg notwendig.

Welche Voraussetzungen braucht Databricks Streaming über OpenSharing?

Für den beschriebenen D2D-Weg braucht der Empfänger einen Databricks-Workspace mit Unity Catalog, Zugriff auf die Freigabe samt Tabellenhistorie und einen dauerhaft gespeicherten Streaming-Checkpoint. Ob zusätzlich Change Data Feed benötigt wird, hängt davon ab, welche Änderungen verarbeitet werden sollen.

Anbieter: Historie und Berechtigungen vorbereiten

Der Anbieter nimmt die Delta-Tabelle mit WITH HISTORY in einen Share auf. Diese Historie ist die Grundlage für den inkrementellen Streaming-Zugriff. Anschließend registriert er den Empfänger über dessen Sharing Identifier und erteilt Zugriff auf den Share.

Dabei reicht die Rolle als Workspace-Administrator nicht automatisch aus: CREATE SHARE und CREATE RECIPIENT benötigen Berechtigungen auf Metastore-Ebene. Das sollte Dein Team vor der Umsetzung mit der Plattformverantwortung klären.

Empfänger: Verarbeitung dauerhaft fortsetzen

Der Empfänger bindet die Freigabe als Katalog ein und richtet den Structured-Streaming-Leseprozess ein. Der Checkpoint gehört in dauerhaften Cloud-Speicher, beispielsweise in Unity Catalog Volumes. Ein temporärer Speicherort ist keine belastbare Grundlage für wiederanlaufende Produktionsprozesse.

Ein kontinuierlich laufender Job ist nicht zwingend nötig. Trigger.AvailableNow verarbeitet die aktuell verfügbaren, noch nicht bearbeiteten Daten in einem oder mehreren Micro-Batches und beendet sich anschließend. Das passt zu zeitgesteuerten inkrementellen Jobs. Alternativ beschreibt Databricks einen Table Update Trigger, der den Job bei neuen Datenänderungen startet.

Für Azure-Databricks-Teams heißt das: Laufzeitmodell und Aktualitätsbedarf gemeinsam planen, statt Streaming automatisch mit dauerhaft laufender Rechenleistung gleichzusetzen.

Neue Zeilen sind nicht dasselbe wie vollständige Änderungen

Der wichtigste fachliche Prüfpunkt liegt nicht beim Verbindungsaufbau, sondern bei der Änderungslogik. Ein einfacher inkrementeller Leseprozess ist noch keine vollständige Synchronisation zweier Tabellen.

Wenn vor allem neue Datensätze hinzukommen

Das beschriebene Delta-Sharing-Lesemuster verwendet ignoreChanges. Diese Option kann bereits gelesene Zeilen erneut ausgeben und überträgt keine Löschungen. Ein Checkpoint macht die Verarbeitung daher nicht automatisch frei von fachlichen Duplikaten.

Für Deine Zieltabellen brauchst Du gegebenenfalls eindeutige Schlüssel und eine Verarbeitung, die wiederholt gelieferte Datensätze korrekt behandelt. Außerdem solltest Du Einstellungen nicht ungeprüft übertragen: Beim direkten Streaming aus regulären Delta-Tabellen verwenden neuere Databricks Runtime-Versionen für das Überspringen geänderter Commits skipChangeCommits.

Wenn Korrekturen und Löschungen ankommen müssen

Sollen Inserts, Updates und Deletes explizit verarbeitet werden, ist Change Data Feed der passende Weg. Im klassischen Setup aktiviert der Anbieter dafür delta.enableChangeDataFeed. Welche Variante verfügbar ist, muss zu Runtime und Tabellenkonfiguration passen.

Der Empfänger muss die Änderungsereignisse anschließend fachlich korrekt in seine Zieltabellen übernehmen. Eine übermittelte Löschung entfernt nicht von selbst jeden nachgelagerten Datenbestand. Gerade bei personenbezogenen Informationen müssen deshalb auch lokale Kopien, Aufbewahrung und Löschprozesse berücksichtigt werden.

Was vor dem produktiven Einsatz geklärt sein sollte

Ein offenes Protokoll bedeutet nicht, dass jede Empfängerplattform dieselben Funktionen bietet. Außerhalb von Databricks können Empfänger mit Open-Source-Apache-Spark und dem delta-sharing Connector ebenfalls Structured Streaming nutzen. Ohne Spark beschreibt Databricks den Abruf von Änderungen über Versionsbereiche statt eines kontinuierlichen Streams. Die konkrete Unterstützung gehört deshalb auf die Prüfliste.

Für einen belastbaren Einstieg solltest Du außerdem festlegen:

• Datenvertrag: Welche Spalten, Schlüssel und Änderungsregeln gelten? Wie werden Schemaänderungen angekündigt?
• Wiederanlauf: Was passiert nach einem Jobabbruch, bei Duplikaten oder bei einem verlorenen Checkpoint?
• Historie: Wie lange bleiben benötigte Versionen verfügbar? Historische Nachladungen funktionieren nur innerhalb der vorhandenen Historie.
• Betrieb: Wer überwacht Aktualität, Fehler und Berechtigungen, und wer reagiert bei Störungen?
• Datenschutz und Kosten: Welche Daten dürfen Empfänger speichern, und welche Aufwände entstehen durch Verarbeitung, Speicherung und gegebenenfalls regionsübergreifenden Datentransfer?

Ein technischer Test sollte nicht nur neue Zeilen prüfen, sondern auch Korrekturen, Löschungen und einen Wiederanlauf. So wird sichtbar, ob die vereinbarte Semantik tatsächlich bis in die Zieltabellen reicht.

Was das für dich bedeutet

OpenSharing ist besonders dann prüfenswert, wenn Du wiederkehrende Datei-Lieferungen durch einen kontrollierten Tabellenzugriff ersetzen möchtest. Der Nutzen liegt in weniger separater Exportlogik und klareren Zuständigkeiten – nicht darin, sämtliche Integrationsaufgaben verschwinden zu lassen.

Starte mit einer geeigneten Tabelle und einem Empfänger. Ailio unterstützt Dich als Databricks-Partner dabei, Architektur, Änderungsverarbeitung und Betrieb für Deine Azure-Databricks-Umgebung zu planen. Besprich Deinen Anwendungsfall mit unserer Databricks Beratung.

Redaktionelle Einordnung auf Basis eines Beitrags im Databricks-Blog.