SAP-Hasen kennen das Muster: Unklare Verantwortung kostet später doppelt.

Wer schon einmal eine SAP-Landschaft betreut hat, kennt das Problem: Unklare Verantwortlichkeiten führen zu Chaos im Berechtigungskonzept, zu Sicherheitslücken oder zu Reibungsverlusten im Betrieb. Genau dieses Muster wiederholt sich in modernen Analytics-Plattformen – nur schneller und mit grösserer Tragweite. Databricks Unity Catalog ist ein mächtiges Werkzeug für Governance, Sicherheit und zentrale Datenverwaltung. Doch ohne saubere Klärung der Unity-Catalog-Admin-Hierarchie vor dem ersten Klick entstehen Probleme, die sich später nur mit erheblichem Aufwand korrigieren lassen.

Dieser Artikel richtet sich an Platform Engineers, Analytics-Architekten und SAP-erfahrene Datenverantwortliche, die Unity Catalog strukturiert aufsetzen möchten. Sie erfahren, welche Rollen es gibt, wie Storage Credentials und External Locations funktionieren, und erhalten eine praxisnahe Anleitung für Ihr erstes Setup – inklusive konkreter Code-Snippets und einer Checkliste zum Download.

---

Warum die Unity-Catalog-Admin-Hierarchie vor dem ersten Klick geklärt sein sollte

Unity Catalog ist weit mehr als ein klassischer Datenkatalog. Es ist die zentrale Governance-Schicht für Ihre gesamte Databricks-Plattform – über Workspaces, Clouds und Datenquellen hinweg. Wer hier ohne klare Rollenverteilung startet, riskiert:

• Berechtigungschaos: Wenn nicht klar ist, wer Catalogs, Schemas oder External Locations verwaltet, entstehen Ad-hoc-Berechtigungen, die später schwer nachvollziehbar sind.
• Sicherheitslücken: Storage Credentials und External Locations ohne zentrale Kontrolle öffnen Tür und Tor für unkontrollierte Datenzugriffe.
• Ineffizienz im Betrieb: Fehlende Verantwortlichkeiten führen zu Rückfragen, Wartezeiten und Abstimmungsschleifen – genau das, was eine moderne Plattform vermeiden soll.

SAP-erfahrene Teams kennen das aus der Praxis: Eine saubere Trennung zwischen zentraler Administration, Plattformbetrieb und Fachverantwortung ist die Grundlage für stabile, skalierbare Systeme. Bei Unity Catalog ist das nicht anders. Die Metastore-Admin-Rolle von Databricks und ihre Abgrenzung zu Account- und Workspace-Admins müssen von Anfang an klar definiert sein.

---

Rollen-Matrix: Account Admin, Metastore Admin, Workspace Admin

Unity Catalog kennt drei zentrale Administrationsrollen, die jeweils unterschiedliche Verantwortungsbereiche abdecken. Die folgende Übersicht zeigt, wer was tut – und wo typische Missverständnisse lauern:

Account Admin

• Verantwortungsbereich: Gesamte Databricks-Account-Ebene
• Typische Aufgaben: Verwaltung von Workspaces, Nutzern, Gruppen, Metastores; Zuweisung von Metastores zu Workspaces; Billing und Account-Einstellungen
• Fachlich oder technisch? Technisch-organisatorisch (IT-Leitung, Plattformverantwortung)
• Häufiger Fehler: Account Admin übernimmt auch operative Metastore-Verwaltung – das führt zu Engpässen und fehlender Delegation

Metastore Admin

• Verantwortungsbereich: Ein spezifischer Metastore (zentrale Governance-Einheit)
• Typische Aufgaben: Verwaltung von Catalogs, Schemas, Storage Credentials und External Locations; Berechtigungen auf Metastore-Ebene; Governance-Regeln
• Fachlich oder technisch? Technisch-fachlich (Data Governance Lead, Platform Engineer)
• Häufiger Fehler: Metastore Admin wird nicht explizit zugewiesen – dann bleibt die Verantwortung unklar oder liegt beim Account Admin

Workspace Admin

• Verantwortungsbereich: Ein einzelner Workspace
• Typische Aufgaben: Verwaltung von Workspace-Nutzern, Clustern, Jobs, Notebooks; Integration von Catalogs in den Workspace; lokale Berechtigungen
• Fachlich oder technisch? Technisch-operativ (Team Lead, Data Engineer)
• Häufiger Fehler: Workspace Admin versucht, Catalogs oder External Locations anzulegen – das funktioniert nicht ohne Metastore-Admin-Rechte

SAP-Vergleich: Zentral vs. dezentral

In SAP-Systemen kennen Sie die Trennung zwischen Basis-Administration (technische Plattform), Berechtigungsadministration (zentrale Sicherheit) und Fachbereichsverantwortung (operative Nutzung). Unity Catalog folgt einem ähnlichen Muster:

• Account Admin = SAP Basis + Lizenzmanagement
• Metastore Admin = Berechtigungsadministrator + Data Steward
• Workspace Admin = Fachbereichs-IT oder Team Lead

Diese Analogie hilft, die Rollen intuitiv zu verstehen und Verantwortlichkeiten sauber zu trennen.

---

Storage Credentials & External Locations

Ein zentraler Baustein der Admin-Hierarchie ist die Verwaltung von Storage Credentials und External Locations. Ohne diese beiden Komponenten können Sie keine externen Daten sicher einbinden – und genau hier entstehen häufig die ersten Stolpersteine.

Was sind Storage Credentials?

Storage Credentials sind die Zugangsdaten, mit denen Databricks auf externe Cloud-Speicher zugreift, zum Beispiel Azure Data Lake, AWS S3 oder Google Cloud Storage. Sie werden zentral im Metastore hinterlegt und sind die Grundlage für alle External Locations.

Wichtig: Storage Credentials werden ausschliesslich vom Metastore Admin verwaltet. Workspace Admins haben keinen Zugriff auf diese Ebene.

Was sind External Locations?

External Locations sind benannte Pfade zu externen Speicherorten, die auf Storage Credentials basieren. Sie definieren, wo Daten physisch liegen – und wer darauf zugreifen darf.

Beispiel:

• Storage Credential: azuredatalakecred
• External Location: abfss://raw-data@storageaccount.dfs.core.windows.net/sap-exports/

External Locations ermöglichen es, Berechtigungen granular zu steuern: Nicht jeder Nutzer braucht Zugriff auf den gesamten Storage, sondern nur auf definierte Bereiche.

Warum ist das für Governance entscheidend?

Ohne saubere Verwaltung von Storage Credentials und External Locations entstehen:

• Wildwuchs bei Speicherzugriffen
• Unklare Datenhoheit
• Sicherheitsrisiken durch unkontrollierte Credential-Nutzung
• Schwierigkeiten bei Audits und Compliance-Prüfungen

SAP-Vergleich: Denken Sie an RFC-Verbindungen in SAP. Auch hier definieren Sie zentral, welche Systeme miteinander kommunizieren dürfen – und nicht jeder Entwickler legt eigene Verbindungen an.

Praxis-Checkliste: Storage vorbereiten

Bevor Sie Ihren ersten Catalog anlegen, sollten folgende Punkte geklärt sein:

• Storage-Strategie definiert: Wo liegen SAP-Daten, wo Non-SAP-Daten? Welche Bereiche sind „managed“, welche „external“?
• Credential-Zuständigkeit geklärt: Wer verwaltet Storage Credentials? Das sollte beim Metastore Admin liegen.
• Namenskonventionen festgelegt: Einheitliche Benennung für Credentials und Locations erleichtert den Betrieb.
• Berechtigungsmodell skizziert: Wer darf auf welche External Locations zugreifen?
• Dokumentation angelegt: Storage-Pfade, Credentials und Zuordnungen sollten zentral dokumentiert sein.

---

Erstes Setup: Catalog, Schema und Managed Table anlegen

Jetzt wird es praktisch. Sie haben Ihre Rollen geklärt, Storage Credentials und External Locations vorbereitet – Zeit für das erste Setup.

Schritt 1: Catalog erstellen

Ein Catalog ist die oberste Organisationsebene in Unity Catalog. Er gruppiert Schemas und Tables und definiert Berechtigungen auf hoher Ebene.

-- Catalog erstellen (als Metastore Admin)
CREATE CATALOG IF NOT EXISTS sapanalytics
COMMENT 'Catalog für SAP- und Non-SAP-Daten';

Hinweis: Nur der Metastore Admin kann Catalogs erstellen. Workspace Admins können bestehende Catalogs nutzen, aber keine neuen anlegen.

Schritt 2: Schema erstellen

Schemas strukturieren die Daten innerhalb eines Catalogs – vergleichbar mit Datenbankschemas in klassischen Systemen.

-- Schema erstellen
CREATE SCHEMA IF NOT EXISTS sapanalytics.finance
COMMENT 'Schema für Finanzdaten aus SAP und externen Quellen';

Schritt 3: Managed Table erstellen

Managed Tables werden vollständig von Databricks verwaltet – inklusive Storage und Lifecycle.

-- Managed Table erstellen
CREATE TABLE IF NOT EXISTS sapanalytics.finance.costcenters (
  costcenterid STRING,
  costcentername STRING,
  department STRING,
  createdat TIMESTAMP
)
COMMENT 'Kostenstellen aus SAP';

Wichtig: Bei Managed Tables legt Databricks automatisch den Speicherort fest. Sie müssen sich nicht um Storage Credentials oder External Locations kümmern.

SAP-Vergleich: Transportwesen und Namensräume

In SAP kennen Sie Namensräume und Transportwege, um Objekte strukturiert zu organisieren. Catalogs und Schemas in Unity Catalog erfüllen eine ähnliche Funktion: Sie schaffen Ordnung, ermöglichen Berechtigungstrennung und erleichtern den Betrieb.

---

Managed vs. External Tables aus SAP-Batch-Sicht

Eine der häufigsten Fragen beim Setup: Wann nutze ich Managed Tables, wann External Tables? Für SAP-erfahrene Teams lässt sich das gut über die Perspektive der Datenbewirtschaftung erklären.

Managed Tables: Plattformverwaltete Datenhaltung

Managed Tables werden vollständig von Databricks verwaltet. Das bedeutet:

• Databricks bestimmt den Speicherort im Metastore-Storage.
• Databricks verwaltet den Lifecycle, zum Beispiel automatisches Löschen bei DROP TABLE.
• Databricks übernimmt Governance und Optimierung, etwa Delta-Lake-Funktionen.

Wann sinnvoll?

• Daten, die innerhalb der Plattform erzeugt und verarbeitet werden
• Transformierte Daten, die nicht extern geteilt werden müssen
• Daten, bei denen Databricks die Hoheit haben soll

SAP-Vergleich: Managed Tables sind wie SAP-interne Tabellen, die im SAP-Schema liegen und vom SAP-System verwaltet werden. Sie sind Teil der kontrollierten Datenhaltung.

External Tables: Angebundene, extern verantwortete Datenhaltung

External Tables verweisen auf Daten, die ausserhalb von Databricks liegen – zum Beispiel in einem Azure Data Lake oder S3-Bucket. Das bedeutet:

• Der Speicherort wird explizit über eine External Location definiert.
• Databricks liest die Daten, verwaltet sie aber nicht.
• Bei DROP TABLE werden nur die Metadaten gelöscht – die Daten bleiben erhalten.

Wann sinnvoll?

• SAP-Exporte, die von anderen Systemen genutzt werden
• Daten, die extern verwaltet und archiviert werden
• Daten, bei denen die Hoheit ausserhalb von Databricks liegt

SAP-Vergleich: External Tables sind wie externe Datenquellen, die per RFC oder Schnittstelle angebunden werden. SAP nutzt die Daten, ist aber nicht für deren Lifecycle verantwortlich.

Entscheidungshilfe: Managed oder External?

• Managed: Wenn Databricks die Datenhoheit haben soll und Sie volle Governance-Kontrolle wünschen
• External: Wenn Daten extern verwaltet werden oder von mehreren Systemen genutzt werden

Tipp: Viele Teams starten mit External Tables für SAP-Exporte und nutzen Managed Tables für transformierte, plattforminterne Daten. Das schafft klare Verantwortlichkeiten und erleichtert den Betrieb.

---

Praxis-Checkliste für ein sauberes Setup

Bevor Sie produktiv gehen, sollten Sie folgende Punkte abhaken:

• Rollen geklärt: Account Admin, Metastore Admin und Workspace Admins sind benannt und eingewiesen
• Metastore-Zuständigkeit definiert: Wer ist für Catalogs, Schemas und Governance verantwortlich?
• Storage-Pfade dokumentiert: Alle External Locations und Storage Credentials sind zentral erfasst
• Credential-Strategie abgestimmt: Wer darf Storage Credentials anlegen und verwalten?
• Namenskonventionen definiert: Einheitliche Benennung für Catalogs, Schemas, Tables, Credentials und Locations
• Erster Catalog/Schema sauber angelegt: Testweises Setup durchgeführt und dokumentiert
• Managed-vs.-External-Entscheidung bewusst getroffen: Für jeden Datenbereich ist klar, welche Variante genutzt wird
• Berechtigungsmodell skizziert: Wer darf auf welche Catalogs, Schemas und Tables zugreifen?

Möchten Sie diese Checkliste als praktisches PDF? Laden Sie unsere Setup-Checklist für Unity Catalog herunter und nutzen Sie sie als Vorlage für Ihr Team.

Möchten Sie Ihr Unity Catalog Setup von Anfang an professionell aufsetzen? Laden Sie unsere Setup-Checklist herunter oder sprechen Sie uns an – wir begleiten Sie gerne auf dem Weg zu einer faktenbasierten, zukunftssicheren Analytics-Plattform.