Datenaustausch mit Databricks: Was OpenSharing verändert

Dateien abholen, API-Endpunkte abfragen, Ladezustände prüfen: Der Datenaustausch mit Databricks beginnt in vielen Unternehmen noch mit klassischen Übertragungsstrecken. Jede zusätzliche Anbindung bringt eigene Fehlerquellen und Betriebsaufgaben mit. Databricks stellt mit OpenSharing einen anderen Ansatz vor: Empfänger lesen freigegebene Tabellen direkt, statt zunächst eine separate Datenlieferung entgegenzunehmen. Für Mittelständler mit Azure und Databricks ist das vor allem eine Architekturfrage: Welche Kopien brauchst Du wirklich – und welche entstehen nur, weil Deine Schnittstellen sie voraussetzen?

Kurz gesagt: OpenSharing ermöglicht laut Databricks den direkten Lesezugriff auf freigegebene Tabellen über ein offenes Protokoll, auch ohne Databricks auf Empfängerseite. Unterstützte Änderungsdaten und freigegebene historische Bestände können inkrementelle Verarbeitung und Nachberechnungen vereinfachen. Das kann separate Datei- und API-Feeds ersetzen, beseitigt aber weder die Verarbeitung beim Empfänger noch die Verantwortung für Berechtigungen und Datenqualität.

Was verändert OpenSharing beim Datenaustausch mit Databricks?

OpenSharing verlagert die Bereitstellung von Daten vom individuellen Export auf den Zugriff auf bereits gepflegte Tabellen. Der Anbieter muss dadurch nicht für jeden Empfänger eine eigene Dateilieferung oder einen zusätzlichen API-Feed betreiben.

Databricks beschreibt OpenSharing als offenes Protokoll auf Basis offener Tabellenformate wie Delta Lake und Iceberg. Entscheidend ist die Trennung von Datenbereitstellung und Verarbeitung: Der Empfänger liest aus dem Cloud Storage und nutzt dafür eigene Compute-Ressourcen. Seine analytischen Abfragen laufen damit nicht gegen die operative Datenbank des bereitstellenden Unternehmens.

Die relevante Neuerung liegt weniger im bloßen Teilen von Daten als in der Verbindung mehrerer Funktionen:

• Tabellenzugriff statt Exportdatei: Die gepflegte Tabelle wird zur gemeinsamen Datenbasis.
• Änderungen statt vollständiger Neuladung: Ein verfügbarer Change Data Feed kann eingefügte, geänderte und gelöschte Datensätze zugänglich machen.
• Historie statt erneuter Lieferung: Freigegebene historische Daten lassen sich für Nachberechnungen lesen.
• Nachvollziehbarkeit statt bloßer Übergabe: Databricks system tables ermöglichen Einblicke in Zugriffe auf geteilte Tabellen.

Das ist kein pauschaler Ersatz für jede Schnittstelle. Der Ansatz setzt voraus, dass die benötigten Daten in geeigneten Tabellen bereitstehen und der Empfänger den Zugriff technisch nutzen kann.

Für wen lohnt sich der Wechsel von SFTP- und API-Feeds?

Der Wechsel lohnt sich besonders für Unternehmen, die regelmäßig tabellarische Daten mit Partnern austauschen und viel Aufwand in Exporte, inkrementelle Ladeprozesse und Nachlieferungen investieren. Ein stabiler, selten genutzter Dateitransfer allein ist dagegen noch kein guter Migrationsgrund.

Im Mittelstand entstehen die eigentlichen Kosten häufig nach der ersten Anbindung. Ein Export kommt verspätet an, eine API begrenzt die Abrufrate oder ein fehlerhafter Zeitstempel lässt Datensätze aus. Solche Probleme binden Data Engineering, obwohl fachlich lediglich dieselben Tabellen erneut benötigt werden.

Besonders interessant bei wiederkehrenden Nachberechnungen

Musst Du nach einer korrigierten Berechnungslogik ältere Daten erneut verarbeiten, wird deren Verfügbarkeit entscheidend. Mit OpenSharing kannst Du die benötigten Bestände direkt lesen, sofern der Anbieter sie tatsächlich vorhält und freigibt. Eine erneute Exportanforderung entfällt dann.

Wichtig ist die Unterscheidung zwischen historischen Datensätzen und früheren Tabellenständen: Eine Tabelle mit alten Geschäftsvorfällen garantiert nicht automatisch den Zugriff auf jede frühere Version. Aufbewahrung, Freigabeumfang und verfügbare Änderungshistorie müssen zur geplanten Verarbeitung passen.

Weniger passend für operative Transaktionen

Eine API, über die Du Bestellungen auslöst oder Stammdaten schreibst, erfüllt eine andere Aufgabe als ein lesender Tabellenzugriff. Auch für Partner ohne geeignete Datenplattform kann eine Datei weiterhin die praktikablere Lösung sein. Entscheidend ist deshalb der Zweck der Schnittstelle, nicht ihr Alter.

Was heißt das konkret für Azure- und Databricks-Umgebungen?

Für Azure- und Databricks-Umgebungen bedeutet OpenSharing, dass bestehende Importstrecken teilweise durch den Zugriff auf freigegebene Tabellen ersetzt werden können. Nachgelagerte Transformationen, Qualitätsprüfungen und fachliche Datenmodelle bleiben jedoch notwendig.

Eine sinnvolle Architekturentscheidung beginnt deshalb nicht mit dem Abschalten von SFTP, sondern mit einer Bestandsaufnahme Deiner Datenplattform. Welche Daten werden nur kopiert, um sie anschließend unverändert abzufragen? Wo braucht Dein Unternehmen dagegen eigene, dauerhaft gespeicherte Ergebnisse?

Weniger Kopien bedeutet nicht keine Datenbewegung

Beim Lesen werden weiterhin Daten übertragen und verarbeitet. Der mögliche Vorteil besteht darin, eine zusätzliche, vollständig gespeicherte Eingangskopie zu vermeiden. Eigene Ergebnistabellen, Zwischenspeicher oder fachlich erforderliche Archivbestände können trotzdem sinnvoll sein.

Auch Kosten verschwinden nicht automatisch. Rechenleistung, Lesezugriffe und mögliche Gebühren für Datenübertragung gehören in die Bewertung. Gerade bei unterschiedlichen Cloud-Regionen solltest Du das geplante Zugriffsmuster prüfen, statt Einsparungen allein aus weniger Speicher abzuleiten.

Aktuelle Daten sind noch keine Echtzeitverarbeitung

Neue Daten können nach dem Schreiben in die freigegebene Tabelle verfügbar sein. Wann sie in Deinem Bericht oder Modell ankommen, hängt zusätzlich von der Verarbeitung auf Empfängerseite ab.

Für inkrementelle Prozesse können Streaming und Change Data Feed genutzt werden. Der Verarbeitungsfortschritt wird dabei über Checkpoints verwaltet, statt vollständig über selbst entwickelte Zeitstempel-Logik. Checkpoints, Wiederanlauf und Fehlerüberwachung bleiben dennoch Betriebsaufgaben.

Welche Regeln braucht der Datenaustausch zwischen Unternehmen?

Der Datenaustausch braucht klare Vereinbarungen zu Freigaben, Datenstruktur, Aufbewahrung, Verfügbarkeit und Verantwortlichkeiten. Ein offenes Protokoll ersetzt diese Regeln nicht, sondern macht ihre technische Umsetzung anders organisierbar.

Für deutsche Mittelständler sollten insbesondere folgende Punkte vor einer produktiven Nutzung geklärt sein:

• Datenumfang: Welche Tabellen und Inhalte darf der Empfänger für welchen Zweck nutzen?
• Änderungen: Wer kündigt neue Spalten, geänderte Datentypen oder entfernte Felder an?
• Historie: Wie lange stehen Daten und Änderungsinformationen für Wiederanläufe bereit?
• Datenschutz: Welche personenbezogenen Daten sind enthalten, und welche vertraglichen sowie technischen Anforderungen gelten?
• Zugriffsentzug: Was passiert bei Vertragsende mit Berechtigungen und bereits erzeugten Ergebnissen?
• Nachweisbarkeit: Welche Zugriffsereignisse werden protokolliert, aufbewahrt und regelmäßig ausgewertet?

Ein Audit Trail schafft Transparenz über protokollierte Zugriffe. Er beweist jedoch nicht automatisch, wie ein Empfänger gelesene Daten anschließend verwendet. Ebenso löscht ein Berechtigungsentzug keine bereits gespeicherten Verarbeitungsergebnisse. Diese Grenzen gehören ausdrücklich in das Betriebskonzept.

So prüfst Du den Einstieg ohne Komplettumbau

Beginne mit einer abgegrenzten, lesenden Datenlieferung, deren heutiger Betrieb gut dokumentiert ist. Damit lässt sich der Nutzen gegenüber SFTP oder API nachvollziehbar bewerten.

Ein Pilot mit klaren Prüfkriterien

1. Ausgangslage erfassen: Dokumentiere Betriebsaufwand, Aktualitätsbedarf und typische Fehler der bestehenden Anbindung.
2. Voraussetzungen prüfen: Kläre Tabellenformat, unterstützte Zugriffsmöglichkeiten, Freigaben und verfügbare Historie.
3. Verarbeitung testen: Prüfe neben neuen Datensätzen auch Änderungen, Löschungen und einen Wiederanlauf nach Unterbrechung.
4. Betrieb vergleichen: Bewerte Kosten, Datenqualität, Aktualität und Nachvollziehbarkeit gegenüber dem bisherigen Verfahren.
5. Umstellung entscheiden: Lege Verantwortlichkeiten und einen Rückfallweg fest, bevor Du den alten Feed abschaltest.

Was das für dich bedeutet

OpenSharing ist vor allem dann interessant, wenn Dein Team mehr Zeit mit Datenlieferungen als mit deren fachlicher Nutzung verbringt. Der Hebel liegt in weniger individuellen Exportstrecken und besser nutzbaren Tabellenzugriffen – nicht in einer Datenarchitektur ohne Betriebsaufwand.

Du möchtest wissen, welche Anbindungen in Deiner Azure- und Databricks-Landschaft dafür geeignet sind? Ailio unterstützt Dich als Databricks-Partner bei Architektur und Umsetzung. Besprich Deine nächsten Schritte mit unserer Databricks Beratung.

Redaktionelle Aufbereitung und Einordnung auf Basis eines Beitrags im Databricks-Blog.