BI- und Analytics-Services
Power BI, Tableau oder Qlik als Dashboard-Service in OpenMetadata: Asset-Typen, Verantwortung und Lineage zurück zum Warehouse.
Herausforderung
BI-Metadaten ohne Warehouse- und Transformationskontext erzeugen einen zweiten Inventar-Graphen: Dashboards ohne Owner, Measures ohne Grain, Lineage die im Tool endet. Zusätzlich harvesten Teams ganze Tenants und wundern sich über Rauschen und fehlende Upstream-Links.
Ansatz
BI als Dashboard-Service anbinden, nachdem Warehouse (und idealerweise dbt) für denselben Flow stehen. OpenMetadata verknüpft Charts/Dashboards mit Tabellen — Zugriff bleibt in der BI-Plattform bzw. im Warehouse.
Warehouse (+ dbt) → BI-Service-Ingestion
→ Dashboards/Charts mit Lineage zu Tabellen
→ Owner und Domäne kuratieren
Typische Tools
| Tool | Fokus in OM | Scope-Tipp |
|---|---|---|
| Power BI | Workspaces, Datasets, Reports | Ein Pilotprojekt-Workspace, nicht der ganze Tenant |
| Tableau | Sites, Workbooks, Datasources | Projekt/Site begrenzen; Personal Spaces meiden |
| Qlik | Streams/Apps, Master Items wo verfügbar | Stream/App des Business Flows |
Best Practices
Derselbe Business Flow wie das Warehouse
BI-Ingestion soll denselben Pilotprojekt abbilden (Workspace/App des Sales-Flows), nicht den ganzen Tenant. Tenant-weiter Metadatenimport erzeugt Orphan-Dashboards, Personal Spaces und Rauschen — Stewardship kommt nie hinterher.
Workspace-Allowlist gehört in den Decision Record, nicht nur in die UI-Config. Zehn kritische Dashboards mit Owner schlagen fünfhundert Orphans.
Service Principal, kein persönlicher Admin-Token
Prod-Metadatenimport mit dem Token eines Admins kaputt, wenn die Person geht oder MFA greift. Service Principal / App-Registration mit Least Privilege; Secret im Vault; Rotation wie bei Warehouse-Bots.
Lineage-Smoke vor dem „fertig“
Mindestens ein Dashboard bis zu einer Warehouse-Tabelle nachverfolgen. Scheitert das (Gateway-/DSN-Name ≠ OM-FQN, falsches Environment), wirkt der Graph verbunden, ist aber kein Impact-Werkzeug. Connection-Namen mit dem Warehouse-Service abgleichen, bevor ihr skaliert.
Owner zuerst auf kritischen Dashboards
Nicht jedes Report braucht sofort Stewardship. Tier/Domain auf den Dashboards setzen, die Incidents und Entscheidungen treiben; Rest darf vorerst dünn bleiben. Sonst blockiert Vollständigkeitsdruck das Pilotprojekt.
OM ersetzt keine BI-Rechte
Katalogsicht ist nicht Workspace-Zugriff, nicht RLS, nicht der Zertifizierungs-Workflow im Tool. OM zeigt und verknüpft; Durchsetzung bleibt in Power BI/Tableau/Qlik bzw. im Warehouse. Measure-Namen in OM sind oft Labels — Grain und Zertifizierung liegen häufig im Tool oder Glossary.
Stolperfallen
BI vor Warehouse. Orphan-Dashboards ohne Upstream — Stewardship pflegt Beschreibungen ins Leere.
Ganzer Tenant. Discovery unbrauchbar; Security-Reviews blockieren.
Personal/Embedded Spaces. Kein Owner, hohe Churn, Delete-Wellen bei Rename.
Delete-Default bei Rename. Kuratierte Descriptions weg — Soft-delete/Quarantäne wie in Teil 1.
Parallel „zum Lernen“ harvesten, während Teil 2 noch instabil ist — warten ist billiger.
Vorgehen
- Pilotprojekt-Workspace/App wählen (derselbe Business Flow wie Teil 2).
- Service und Credentials anlegen.
- Scope auf relevante Workspaces begrenzen.
- Lineage zu Warehouse-Assets prüfen.
- Owner und Domain für kritische Dashboards setzen.
- Freshness-SLO und Stale-Alert wie bei Database-Services.
Troubleshooting
- Keine Lineage-Kanten: Dataset zeigt auf andere DB/Environment; Gateway-/Connection-Namen mappen.
- Auth-Fehler: App-Registration, Scopes, Admin-Consent — getrennt vom Human-Login.
- Zu viele Assets: Workspace-Filter verschärfen, bevor Governance startet.
Reihenfolge im Flow
BI erst nach Warehouse (und idealerweise dbt) anbinden. Sonst entstehen Dashboards ohne Upstream-Assets — Stewardship pflegt dann Beschreibungen an Orphans. Wenn das Pilotprojekt-Flow in Teil 2 noch nicht stable ist: BI warten lassen, nicht „parallel zum Lernen“ harvesten.
Typische Erwartungen vs. Realität
| Erwartung | Realität |
|---|---|
| OM zeigt alle Measures korrekt | Grain und Zertifizierung oft im BI-Tool oder Glossary |
| Lineage immer vollständig | Gateway-/DSN-Mapping und Embedded Datasets brechen oft |
| Metadatenimport = Governance | Owner und Domain müssen kuratiert werden |
| Ein Tenant-Connector reicht | Scope und Environments brauchen Disziplin wie beim Warehouse |
Plane Stewardship-Kapazität: 10 kritische Dashboards mit Owner schlagen 500 Orphans.
Hilfe beim Umsetzen
Workspace-Allowlist in den Decision Record. Service Principal im Vault. Nach dem ersten Run: ein Dashboard → eine Warehouse-Tabelle nachverfolgen. Scheitert das, Connection-/DSN-Mapping fixen bevor ihr den Scope öffnet. Config-Gerüst: OpenMetadata-Ingestions-Generator.
Checkliste
- Sind Warehouse-Assets für die genutzten Datasets vorhanden?
- Ist der BI-Umfang auf das Pilotprojekt begrenzt?
- Sind kritische Dashboards mit verantwortliche Person sichtbar?
- Ist Lineage zu mindestens einer Upstream-Tabelle nachvollziehbar?
- Ist klar, dass BI-Rechte im Tool bleiben?
Artefakt
BI Connector Decision Record: Tool, Tenant/Site, Scope, Secret, SLO, Owner.
Tools
- OpenMetadata-Ingestions-Generator — Dashboard-Service-Starter und Umfang-Checkliste.
- OpenMetadata Connectors — Dashboard-Connectoren (Power BI, Tableau, Qlik, …).
- IdP + Secret Store (intern) — Service Principal / App-Registration.
Ressourcen
OpenMetadata: Connecting Source Systems
Part 4 of 8
View series