OpenMetadata anbinden: Vom ersten System zur prüfbaren Datenherkunft
Praktischer Einstieg für BI, lokale Datenbanken, Microsoft und Cloud-Plattformen: Runner, Scope, Identitäten und Abnahme.
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.
Kundenprojekt als Formular und Plan
Die Projektwerkstatt verbindet Kundenanforderungen, Plattform-Steckbrief und Connector-Abnahme in einer JSON-Arbeitsdatei. Markdown und HTML ergeben ein Kapitel für die Gesamtprojektdoku. Der sechsphasige Projektplan führt durch Interviews, Pilot, Tests und Betriebsübergabe. Die Formulare dokumentieren echte Nachweise; sie führen keine Ingestion aus. Referenzstand: Herstellerhilfe 2.0.x, 24.10.2026.
Für den Betrieb ergänzen Fehlerdiagnose, Berechtigungswerkstatt und Upgrade-/Restore-Planer denselben Projektstand und Dokumentationsexport.
Begriffe vor dem Lesen
Metadaten-Ingestion liest Beschreibungen und Strukturen in einen Katalog. Daten-Ingestion lädt Geschäftsdaten, etwa mit Fivetran. Ein Runner/Agent führt den Connector aus. Eine FQN ist der vollständige Objektname aus Service, Datenbank, Schema und Tabelle. Profiling untersucht Datenwerte und benötigt andere Rechte und eine eigene Freigabe.
Ziel und Reihenfolge
Am Ende soll ein Nutzer von einem Bericht zur richtigen Quelltabelle, ihrer Definition und dem Owner gelangen. Diese Serie beschreibt den Weg dorthin mit der Dokumentationslinie OpenMetadata 2.0.x. Sie ergänzt die bestehende Connector-Grundlagenserie um konkrete Systemanleitungen.
Datenbank / Lake → optional Pipeline und dbt → BI → Abgleich mit einem echten Geschäftsbeispiel
Zuerst ein Schema und einen Bericht festlegen, beispielsweise analytics.sales und den Monatsumsatz. Produktions- und Testumgebung erhalten verschiedene Services, etwa warehouse_prod und warehouse_test. Einheitliche Namen vermeiden, dass Tabellen gleicher Namen aus verschiedenen Umgebungen verbunden werden.
1. Vor dem Anlegen erfassen
| Entscheidung | Im Workshop festhalten |
|---|---|
| Installation | OpenMetadata-Serverversion, Runner-/Ingestion-Version und verwendete Connector-Dokumentation |
| Netzwerk | Standort des Runners, DNS, Port, Proxy, TLS-Vertrauen und Rückweg zur OpenMetadata-API |
| Identität | Technischer Benutzer oder Service Principal, Secret-Verantwortlicher, Ablauf und Rotation |
| Scope | Erlaubte Datenbanken, Schemas, Workspaces, Sites, Apps und Ausschlüsse |
| Datenzugriff | Nur Metadaten oder zusätzlich Profiling, Stichproben, Qualität und Abfragehistorie? |
| Inhaltsverantwortung | Was kommt aus der Quelle, was pflegt der Steward im Katalog? |
| Betrieb | Aktualisierung, Alarmempfänger, Wiederanlauf und zulässige Verzögerung |
„Lokal“ bezieht sich auf den Runner. localhost in einem Container bezeichnet diesen Container, nicht den Laptop oder den Datenbankserver. Für private Quellen den Runner im erreichbaren Netz betreiben; die Datenbank muss dafür nicht öffentlich erreichbar gemacht werden.
2. Gemeinsamer Ablauf in der Oberfläche
- Unter Settings → Services den passenden Typ auswählen: Database, Dashboard oder Pipeline.
- Connector und eindeutigen Service-Namen wählen. Vor dem Speichern das Namensschema prüfen.
- Host/Endpunkt und die für diesen Connector dokumentierte Authentifizierung eintragen. Secrets im vorgesehenen Secret-Verfahren verwalten.
- Test Connection ausführen. Verbindungsfehler zuerst nach Netzwerk, TLS, Anmeldung und Objektberechtigung unterscheiden.
- Bei What to Ingest den Pilotumfang festlegen; Include/Exclude gemeinsam prüfen. Ein Filter ersetzt keine Quellberechtigung.
- Vor Create & Deploy die Auswirkungen von Löschmarkierungen, Overrides und zusätzlich gelesenen Werten prüfen. Im vorgesehenen Ingestion-Betrieb den ersten Lauf starten.
- Im Service unter Agents Laufhistorie und Fehler prüfen. Bei externer Ausführung den eigenen Scheduler verwenden; eine UI-Konfiguration allein stellt keinen ausführbaren Runner bereit.
Der Ablauf ist unter anderem in den offiziellen Anleitungen für Tableau und PostgreSQL dokumentiert. Eingesetzte Versionen können andere Feldnamen oder Ausführungsmodelle haben.
3. Sichtbarkeit und Herkunft getrennt abnehmen
Ein erfolgreicher Job kann trotzdem die falsche Umgebung, einen zu engen Scope oder keine Lineage liefern. Vorab eine Soll-Liste mit wenigen bekannten Objekten anlegen. Danach zählen: erwartete Objekte, tatsächlich sichtbare Objekte, fehlende Spalten, erkennbare Herkunft, erreichbarer Quelllink und lesbare Beschreibung.
Als zweiten Test eine Beschreibung in der Quelle ändern, erneut einlesen und den vereinbarten Vorrang prüfen. Einen temporären Testgegenstand entfernen und kontrollieren, wie Löschmarkierungen wirken. Manuelle Katalogpflege darf nicht versehentlich durch einen Override verloren gehen.
Die konkreten Wege
- Qlik Cloud und Qlik Sense
- Tableau mit Workbooks, Views und Datenquellen
- Microsoft: Power BI, SQL, ADLS, Fabric und Purview
- Lokale PostgreSQL-, MySQL- und SQL-Server-Datenbanken
- Snowflake
- Databricks, Unity Catalog und weitere Lakes
Fehlende Rechte, unbekannte Tabellenzuordnung oder unklare Pflegeverantwortung werden als eigene Aufgaben mit Owner und Nachweis in der Deal-Karte aufgenommen. Das ist die Grundlage für einen belastbaren GAP-Plan.
Direkt mit den Werkzeugen arbeiten
Einrichtung und Anbindung planen, Lineage-Mappings prüfen und einen eigenen Adapter vorbereiten. Die Werkzeuge erzeugen lokal Prüfberichte und ein Python-Gerüst; sie verbinden sich nicht automatisch mit Kundensystemen. Der Adapter-Workshop erklärt Entwicklung und Abnahme.
OpenMetadata: practical system connections
Part 1 of 7
View series