Databricks, Unity Catalog und weitere Lakes anbinden

Quellen- und Prüfstand: 15. Oktober 2026. OpenMetadata-Anleitungen beziehen sich auf die verlinkte Dokumentation 2.0.x. Einrichtungsschritte und Voraussetzungen vor Einsatz mit Server-, Runner- und Connector-Version abgleichen. Redaktionell geprüft; keine Verbindung zu einem Kundensystem durchgeführt.

Erst den Metadatenzugang bestimmen

Ein Lakehouse kann Tabellen über einen Katalog verwalten; ein Storage-Container enthält Dateien; ein SQL-Dienst liefert wieder eine andere Sicht. Diese Zugänge können dieselben Nutzdaten beschreiben, aber unterschiedliche Asset-Identitäten und Herkunft liefern.

Die Databricks-Anleitung verweist für Unity-Catalog-Nutzung ausdrücklich auf den eigenen Unity-Catalog-Connector. Nicht beide Wege ungeprüft parallel auf denselben Bestand richten.

Databricks mit Unity Catalog

1. Workspace-URL, Cloud, verwendete Kataloge/Schemas und eine bekannte Tabelle aufnehmen. Technische Identität und erlaubten SQL-Zugriff festlegen.
2. Die vom Connector unterstützte Authentifizierung wählen, zum Beispiel OAuth/Machine-to-Machine oder den für das Setup dokumentierten Token-Weg. Laufzeit und Secret-Rotation planen.
3. Beim ausgewählten SQL Warehouse dessen Verbindungseinstellungen übernehmen, insbesondere Host und HTTP Path. Das ist nicht der Pfad einer Tabelle oder eines Notebooks.
4. Unter Database Services → Unity Catalog einen Service wie databricks_uc_prod anlegen. Host, HTTP Path, Credentials und Pilotscope eintragen.
5. Katalog-/Schema-Sichtbarkeit, Leserechte und Compute-Zugriff anhand der Connector-Anforderungen prüfen. Nur sichtbare Assets zu listen genügt nicht für Profiling oder Query-Historie.
6. Verbindung testen und Metadaten importieren. Die dreiteiligen Namen catalog.schema.table mit dem Quellsystem vergleichen.
7. Lineage-/Usage-Umfang und zusätzlich benötigte Systemtabellen oder Historienquellen separat konfigurieren. Einen realen Transformationslauf im Pilot nachvollziehen.

Für einen älteren Hive-Metastore-/Databricks-Bestand zunächst den dafür dokumentierten Databricks-Connector prüfen. Die Entscheidung nach tatsächlicher Umgebung treffen, nicht nach dem gemeinsamen Herstellerlogo.

Prüfen, was eine Kante wirklich belegt

Eine Unity-Catalog-Darstellung in Databricks und ein OpenMetadata-Graph müssen nicht denselben Erfassungszeitraum oder dieselbe Tiefe haben. Eine bekannte Tabelle in einen Test-Output schreiben lassen und anschließend Quelle, Output, Verarbeitung und Zeitfenster vergleichen. Bei BI-Importen den Service-Namensraum explizit zuordnen.

Wenn externe Engines oder Dateien direkt auf Storage zugreifen, kann der Katalog diese Verarbeitung nur zeigen, wenn der passende Metadaten-/Lineage-Zugang sie liefert. Eine korrekte Zugriffspolitik in Unity Catalog ist außerdem nicht automatisch eine Zugriffspolitik für beliebige externe Storage-Pfade.

BigQuery, S3 und ADLS

Ein SQL- oder Storage-Zugang setzt nicht automatisch die Rechte des anderen Pfads durch. Fehlende Herkunft bleibt im Abnahmeprotokoll sichtbar. Teilabgleich 23.10.2026: Unity-Catalog-Connector 2.0.x. Authentifizierung, HTTP Path und Abdeckung im tatsächlich eingesetzten Release prüfen.

Die Storage-Anbindung importiert keine vollständige Unternehmens-Lineage allein aus Dateinamen. Bei paralleler SQL- und Storage-Sicht entscheiden, welches Objekt führend ist und wie beide Identitäten zusammenhängen. Für Cloudera gilt ergänzend die bestehende Plattform-Einordnung.

Abschluss und Übergabe

Die Abnahme enthält erwartete Kataloge/Schemas/Tabellen, bewusst ausgeschlossene Datenräume, Quelllinks, eine demonstrierte Verarbeitung und einen zugeordneten BI-Bericht. Hinzu kommen Refresh-Frist, Betriebskosten, Alarmempfänger und Wiederanlauf. Fehlende Pipelines nicht durch manuelle Fantasiekanten verdecken, sondern mit Quelle und Owner als Arbeitspaket festhalten.

Wenn die Daten erst in diese Plattformen gelangen sollen: Fivetran und Alternativen. Für die gemeinsame Planung: Deal-Karte.