Databricks Unity Catalog: Tabellenwechsel ohne Datenkopie

Offene Tabellenformate machen eine Datenplattform noch nicht vollständig unabhängig. Entscheidend ist auch, ob Du die Verwaltung Deiner Tabellen an einen anderen Katalog übergeben kannst, ohne Datenbestände neu aufzubauen. Genau hier setzt eine Neuerung rund um Databricks Unity Catalog an: REGISTER und UNREGISTER sollen den Wechsel der Tabellenverwaltung ermöglichen, während die Dateien unverändert im eigenen Objektspeicher bleiben. Für mittelständische Unternehmen mit Azure und Databricks ist das ein wichtiger Baustein für eine Architektur, die spätere Veränderungen zulässt.

Kurz gesagt: REGISTER und UNREGISTER ermöglichen die Übergabe einer Iceberg-Tabelle zwischen unterstützenden Katalogen, ohne ihre Daten- und Metadatendateien zu kopieren. UNREGISTER löst die bisherige Katalogzuordnung und liefert den aktuellen Metadatenverweis, den der Zielkatalog für REGISTER benötigt. Für Unity Catalog ist die Funktion als Private Preview angekündigt; ein produktiver Wechsel erfordert weiterhin eine kontrollierte Umstellung der Schreibprozesse und Zugriffe.

Was ist neu an Databricks Unity Catalog?

Neu ist die angekündigte Kombination aus REGISTER und UNREGISTER für eine geregelte Übergabe der Tabellenverwaltung, die Databricks für Unity Catalog zunächst als Private Preview bereitstellt.

REGISTER ist bereits in der Apache-Iceberg-REST-Katalogspezifikation vorgesehen. Damit lässt sich eine bestehende Tabelle anhand ihrer Metadatenposition in einen Katalog aufnehmen. Databricks beschreibt UNREGISTER als die beigesteuerte Ergänzung: Der bisherige Katalog entfernt seinen Tabelleneintrag, lässt die zugrunde liegenden Dateien bestehen und gibt die Position der aktuellen Metadaten zurück.

Das adressiert eine bisher problematische Lücke. Eine Tabelle im neuen Katalog anzumelden reicht nicht aus, solange der alte Katalog sie weiterhin verwaltet. Ebenso darf das Entfernen einer Katalogzuordnung nicht mit dem Löschen der Tabelle verwechselt werden. Ein Löschvorgang kann abhängig von Operation und Implementierung auch Daten oder Metadaten entfernen.

Für Deine Planung wichtig: Die Meldung beschreibt einen Mechanismus im Iceberg-REST-Umfeld, keine pauschale Umzugsfunktion für sämtliche Tabellenarten und Katalogprodukte. Ob Ausgangs- und Zielsystem die erforderlichen Operationen unterstützen, musst Du konkret prüfen. Der Zugang zur Private Preview erfolgt über das Databricks-Account-Team.

Warum genügt ein offenes Tabellenformat nicht?

Ein offenes Tabellenformat allein genügt nicht, weil der Katalog den aktuellen Tabellenzustand vermittelt und Schreibvorgänge koordiniert.

Bei einer Abfrage fragt die Verarbeitungsengine zunächst den Katalog nach der Tabelle. Über die zurückgegebenen Metadaten findet sie unter anderem Schema und Datendateien im Objektspeicher. Der Katalog ist damit nicht bloß ein Verzeichnis lesbarer Tabellennamen. Er ist die maßgebliche Instanz dafür, welcher Stand einer Tabelle aktuell ist.

Zwei aktive Kataloge können widersprüchliche Datenstände erzeugen

Wird dieselbe Tabelle zusätzlich in einem zweiten, unabhängig arbeitenden Katalog registriert, können beide Kataloge Schreibvorgänge zulassen. Dann entstehen auseinanderlaufende Tabellenstände: Änderungen über den einen Katalog sind über den anderen möglicherweise nicht sichtbar.

Für Dein Unternehmen wäre das beispielsweise dann kritisch, wenn operative Auswertungen und Finanzberichte scheinbar dieselbe Tabelle verwenden, tatsächlich aber unterschiedliche Änderungen sehen. Ein offenes Dateiformat verhindert diesen Koordinationsfehler nicht.

UNREGISTER schafft deshalb eine explizite Abgabe der bisherigen Verwaltung. Der entscheidende Nutzen liegt nicht nur im eingesparten Kopieren, sondern in einer klar geregelten Zuständigkeit für weitere Schreibvorgänge.

Wie läuft die Übergabe ohne Datenkopie ab?

Die Übergabe erfolgt, indem der bisherige Katalog die Tabelle freigibt und der Zielkatalog sie anschließend anhand des zurückgegebenen Metadatenverweises registriert.

Der technische Kern besteht aus drei Schritten:

1. Bisherige Zuordnung lösen: UNREGISTER entfernt den Tabelleneintrag im Ausgangskatalog. Daten- und Metadatendateien bleiben am vorhandenen Speicherort.
2. Aktuellen Verweis übernehmen: Die Antwort enthält die Position der zuletzt gültigen Tabellenmetadaten.
3. Im Zielkatalog registrieren: REGISTER verknüpft den gewünschten Tabellennamen mit diesen bestehenden Metadaten. Dafür werden keine Datendateien verschoben oder neu geschrieben.

Das ist nicht automatisch eine unterbrechungsfreie oder katalogübergreifend atomare Migration. Zwischen Freigabe und Registrierung liegt ein Übergabeschritt, den Dein Betrieb absichern muss. Die APIs ersetzen weder das kontrollierte Stoppen von Schreibern noch die Umstellung abhängiger Jobs.

Was nicht automatisch mitwandert

Die beschriebene Übergabe betrifft die Tabellenregistrierung. Daraus lässt sich keine automatische Übernahme sämtlicher Berechtigungen, Richtlinien oder anderer kataloggebundener Governance-Informationen ableiten. Auch Anwendungskonfigurationen und Verbindungen müssen im Zielbetrieb geprüft werden.

Datenportabilität und Governance-Portabilität sind deshalb getrennte Aufgaben. Für eine tragfähige Datenplattform brauchst Du neben offenen Formaten auch dokumentierte Zuständigkeiten, Zugriffskonzepte und Betriebsabläufe.

Was bedeutet das für Unternehmen mit Azure und Databricks?

Für Unternehmen mit Azure und Databricks eröffnet der Mechanismus eine Möglichkeit, die Katalogverwaltung unterstützter Tabellen zu wechseln, während die Dateien im unternehmenseigenen Speicher verbleiben.

Wenn Deine Tabellen beispielsweise in einem von Deinem Unternehmen kontrollierten Azure Data Lake Storage liegen, ist die Trennung von Speicher und Katalog strategisch relevant. Bei einer späteren Architekturänderung muss nicht zwangsläufig der gesamte Datenbestand exportiert und erneut geladen werden. Der angekündigte Mechanismus adressiert allerdings den Katalogwechsel, nicht den Umzug in eine andere Cloud oder Speicherregion.

Für den deutschen Mittelstand sind vor allem drei Punkte wichtig:

• Mehr Entscheidungsspielraum: Ein zukünftiger Katalogwechsel lässt sich als Architekturpfad berücksichtigen, statt erst bei einer Ablösung über Datenexporte nachzudenken.
• Weniger migrationsbedingte Datenbewegung: Die Übergabe benötigt keine zusätzliche Kopie der Tabellendateien. Welcher Aufwand dadurch entfällt, hängt von Deiner bisherigen Migrationsalternative ab.
• Klare Sicherheitsprüfung: Unveränderte Speicherorte bedeuten nicht unveränderte Zugriffswege. Der Zielkatalog und die verwendeten Engines benötigen passende Identitäten, Netzwerkzugänge und Speicherberechtigungen.

Aus Datenschutz- und Compliance-Sicht bleibt eine eigene Bewertung erforderlich. Dass Dateien am selben Ort liegen, beantwortet noch nicht, welche Systeme darauf zugreifen dürfen oder wie Zugriffe protokolliert werden.

Was solltest Du vor einem Test prüfen?

Vor einem Test solltest Du die Unterstützung beider Kataloge, den Speicherzugriff und einen kontrollierten Ablauf für die Schreibunterbrechung prüfen.

Für einen ersten Versuch eignet sich eine unkritische Tabelle mit überschaubaren Abhängigkeiten. Arbeite dabei eine kurze Prüfliste ab:

• Unterstützen beide Kataloge die benötigten Endpunkte und Tabellenfunktionen?
• Sind alle schreibenden Jobs bekannt und kontrolliert anhaltbar?
• Kann der Zielbetrieb auf Metadaten und Datendateien zugreifen?
• Sind Berechtigungen und Richtlinien im Zielsystem vorbereitet?
• Lassen sich Tabellenzustand und Abfrageergebnisse nach der Übergabe überprüfen?
• Gibt es einen dokumentierten Wiederanlauf- und Rückfallplan?

Bewerte dabei nicht nur, ob die Registrierung funktioniert. Entscheidend ist, ob anschließend Verarbeitung, Zugriffsschutz und Überwachung verlässlich zusammenspielen.

Was das für dich bedeutet

REGISTER und UNREGISTER verringern eine konkrete Abhängigkeit auf Katalogebene. Sie machen aus einer bestehenden Databricks-Umgebung aber weder automatisch eine vollständig portable Plattform noch eine Migration ohne Betriebsaufwand. Prüfe die Funktion zunächst gezielt und berücksichtige den Private-Preview-Status in Deiner Planung.

Du möchtest wissen, wie wechselbereit Deine Azure-Datenplattform ist? Mit unserer Databricks Beratung kannst Du Architektur, Katalogabhängigkeiten und die technischen Voraussetzungen einer kontrollierten Übergabe bewerten.

Redaktionelle Einordnung auf Basis eines Beitrags im Databricks-Blog.