Databricks Unity Catalog: Speicherorte gezielt steuern

Wer Tabellen automatisch verwalten lässt, muss dafür nicht die Kontrolle über den Speicher abgeben. Im Databricks Unity Catalog kannst du Managed Tables in deinem eigenen Cloud-Speicher ablegen und ihre Speicherziele über Kataloge und Schemas steuern. Der aktuelle Databricks-Leitfaden erläutert dabei eine wichtige Unterscheidung: Einen neuen Zielpfad festzulegen ist nicht dasselbe, wie bestehende Daten zu verschieben. Für Mittelständler mit Azure ist das relevant, sobald Fachbereiche getrennte Speicherbereiche benötigen oder eine gewachsene Plattform neu geordnet werden soll.

Kurz gesagt: Mit SET MANAGED LOCATION lässt sich ändern, wo neue Managed Tables und Volumes eines Katalogs oder Schemas gespeichert werden; vorhandene Objekte bleiben an ihrem bisherigen Ort. Bei der Umwandlung einer externen Tabelle in eine Managed Table werden dagegen Daten und Transaktionsprotokoll in den aktuell zugeordneten verwalteten Speicherbereich kopiert. Damit kannst du Speichergrenzen gezielt gestalten, musst Bestandsmigrationen aber separat planen.

Was ist die zentrale Neuerung für deine Speicherplanung?

Die zentrale Änderungsmöglichkeit ist, das Speicherziel für künftig angelegte Tabellen eines bestehenden Katalogs oder Schemas neu festzulegen, ohne dadurch vorhandene Tabellen zu verschieben. Der Leitfaden beschreibt diese Steuerung mit ALTER CATALOG beziehungsweise ALTER SCHEMA und der Klausel SET MANAGED LOCATION.

Das ist vor allem eine Frage sauberer Betriebsplanung: Ein ursprünglich gemeinsam genutzter Speicherbereich muss nicht dauerhaft das Ziel für alle neuen Tabellen bleiben. Du kannst beispielsweise einem Fachbereich einen eigenen Bereich zuweisen, während seine bisherigen Tabellen zunächst unverändert weiterlaufen.

Wichtig für die Einordnung: Der Leitfaden erklärt das Speichermodell und die Änderungsmöglichkeiten. Er ist nicht mit einer pauschalen Ankündigung gleichzusetzen, dass sämtliche beschriebenen Funktionen gerade neu oder in jeder Umgebung uneingeschränkt verfügbar seien. Vor einer Umsetzung solltest du die aktuellen Voraussetzungen für deine Databricks-Umgebung prüfen.

Wie legt Databricks Unity Catalog den Speicherort fest?

Databricks Unity Catalog bestimmt den Speicherort einer Managed Table über die spezifischste konfigurierte Managed Storage Location: Schema vor Katalog vor Metastore. Eine Festlegung auf Schema-Ebene überschreibt damit für dieses Schema den übergeordneten Standard.

Für deine Architektur bedeutet das:

• Metastore: Ein übergreifendes Speicherziel kann als Standard dienen.
• Katalog: Eine fachliche Domäne kann einen eigenen Speicherbereich erhalten.
• Schema: Einzelne Bereiche innerhalb eines Katalogs können nochmals abweichend abgelegt werden.

Du musst also nicht für jede Tabelle einen individuellen Pfad organisieren. Stattdessen definierst du eine nachvollziehbare Zuordnung zwischen fachlicher Struktur und physischem Speicher. Managed Tables werden ohne eigene LOCATION-Klausel angelegt; Unity Catalog übernimmt die Verwaltung ihrer Ablage.

Was „managed“ in Azure tatsächlich bedeutet

Wenn du eigenen Azure-Speicher einbindest, liegen die Tabellendateien in deinem Cloud-Konto, beispielsweise in einem Container von Azure Data Lake Storage. Databricks verwaltet dabei unter anderem Datenlayout, Optimierung und Bereinigung. „Managed“ beschreibt also die Verantwortung für die Tabellenverwaltung, nicht automatisch das Eigentum am zugrunde liegenden Speicher.

Davon zu unterscheiden ist die alternative Option „Default Storage“, bei der Databricks den Speicher bereitstellt. Für eine belastbare Architekturentscheidung solltest du deshalb ausdrücklich dokumentieren, welches Speichermodell deine Umgebung nutzt.

Eine weitere wichtige Unterscheidung: Eine External Location ist ein Unity-Catalog-Objekt, das einen Cloud-Pfad mit Zugangsinformationen verknüpft. Sie ist nicht gleichbedeutend mit einer externen Tabelle. Auch ein verwalteter Speicherbereich auf Katalog- oder Schema-Ebene liegt innerhalb einer solchen External Location.

Wann braucht dein Unternehmen getrennte Speicherbereiche?

Getrennte Speicherbereiche sind sinnvoll, wenn Anforderungen an Administration, Kostenverantwortung oder Datenresidenz über die logische Trennung durch Kataloge, Schemas und Berechtigungen hinausgehen. Für jede Abteilung einen eigenen Container anzulegen, ist dagegen kein Selbstzweck.

Für einen deutschen Mittelständler ergeben sich beispielsweise folgende Prüffragen:

• Benötigt eine Gesellschaft eine eigenständige Speicheradministration?
• Sollen Speicherkosten einem Geschäftsbereich klar zugeordnet werden?
• Müssen bestimmte Daten nachweisbar in einer festgelegten Region liegen?
• Verlangen interne Richtlinien eine physische Trennung bestimmter Datenbestände?

Bei der Kostenbetrachtung solltest du unterscheiden: Ein separater Speicherbereich kann die Zuordnung von Speicherkosten unterstützen. Rechenkosten für gemeinsame Verarbeitung werden dadurch nicht automatisch nach Fachbereichen aufgeteilt.

Physische Trennung ersetzt kein Berechtigungskonzept

Ein eigener Container macht eine Datenverarbeitung nicht automatisch DSGVO-konform. Ebenso wenig garantiert ein geänderter Zielpfad allein die vollständige Einhaltung von Vorgaben zur Datenresidenz. Entscheidend bleiben unter anderem die tatsächliche Azure-Region, Zugriffsrechte, Verarbeitung und weitere Datenkopien.

Lege deshalb zuerst fest, welche Grenze du wirklich brauchst: eine fachliche Zuständigkeit, eine Zugriffsschranke oder eine physische Speichergrenze. Diese Entscheidung gehört in die Architektur deiner Datenplattform, nicht allein in die technische Einrichtung eines Containers.

Was passiert mit bestehenden Tabellen bei einer Änderung?

Bestehende Managed Tables bleiben nach einer Änderung der Managed Storage Location an ihrem bisherigen Speicherort; nur neue Tabellen und Volumes verwenden das neue Ziel. Ein geänderter Katalogpfad ist deshalb kein Migrationswerkzeug für den gesamten Datenbestand.

Das kann im laufenden Betrieb hilfreich sein: Du änderst zunächst die Ablageregel für neue Objekte und planst den Umgang mit älteren Beständen getrennt. Es entsteht aber möglicherweise eine Übergangsphase mit mehreren Speicherorten innerhalb derselben fachlichen Struktur. Diese muss dein Betriebsteam kennen und dokumentieren.

Anders verhält sich die Umwandlung einer externen Tabelle mit ALTER TABLE … SET MANAGED. Dabei kopiert Databricks laut beschriebenem Verfahren die Daten und das Transaktionsprotokoll in den verwalteten Speicherbereich, der sich zum Umwandlungszeitpunkt aus Katalog und Schema ergibt.

Daraus folgt eine klare Reihenfolge: Erst den gewünschten Zielspeicher festlegen, dann die Umwandlung durchführen. Prüfe dabei Speicherbedarf, Zugriffsrechte und mögliche Auswirkungen auf abhängige Prozesse. Behandle die Konvertierung nicht wie eine reine Änderung von Metadaten.

So gehst du die Umsetzung kontrolliert an

Für eine bestehende Azure-Databricks-Plattform empfiehlt sich ein überschaubarer Ablauf:

1. Bestand erfassen: Dokumentiere Kataloge, Schemas, Speicherzuordnungen sowie externe und verwaltete Tabellen.
2. Trennungsbedarf begründen: Halte fest, welche Anforderungen einen eigenen Speicherbereich tatsächlich erforderlich machen.
3. Ziel vorbereiten: Prüfe Azure-Speicher, Region, External Location und erforderliche Berechtigungen.
4. Änderung testen: Kontrolliere mit einer neuen Tabelle, ob die gewünschte Speicherzuordnung greift.
5. Bestand separat behandeln: Plane notwendige Umwandlungen oder Migrationen einschließlich Abhängigkeiten und Validierung.

Dabei sollte nicht nur das Plattformteam beteiligt sein. Fachbereich, Cloud-Betrieb und Datenschutzverantwortliche müssen dieselbe Vorstellung davon haben, welche Daten künftig wohin gehören und welche Bestände unverändert bleiben.

Was das für dich bedeutet

Du kannst automatisierte Tabellenverwaltung und Kontrolle über deinen eigenen Azure-Speicher verbinden. Der entscheidende Punkt ist, Speicherregeln für neue Tabellen, die Umwandlung externer Tabellen und den Umzug bestehender Managed Tables als unterschiedliche Aufgaben zu behandeln.

Wenn du deine Speicherstruktur überprüfen oder neu ordnen möchtest, unterstützt dich Ailio als Databricks-Partner bei Architektur und Umsetzung. Sprich mit uns über deine Databricks-Speicherstrategie.

Redaktionelle Einordnung auf Basis eines Beitrags im Databricks-Blog.