Connector-Entscheidungsmodell
Bevor der erste Connector läuft: Service-Typ, Scope, Freshness-SLO, Owner, Identity-Namespace und Delete-Policy festlegen — und Metadaten-Ingestion von Daten-Ingestion trennen.
Die Serie OpenMetadata: Quellsysteme anbinden gibt dir den Einstieg und den roten Faden für die folgenden Teile.
Begriffe vor dem Lesen
- Metadata / Metadaten — Beschreibende Informationen über Daten, Systeme, Nutzung, Qualität, Herkunft und Verantwortung.
- verantwortliche Person — Fachlich verantwortliche Person oder Rolle, die Zweck, Bedeutung und Freigabe klärt.
- technischer Betreiber — Technische Rolle, die Plattform, Zugriff, Betrieb oder Umsetzung betreut.
- Nachweis — Nachvollziehbarer Nachweis zu Entscheidung, Prüfung, Umsetzung oder Ausnahme.
Ausgangslage
Bevor der erste Connector läuft: Service-Typ, Scope, Freshness-SLO, Owner, Identity-Namespace und Delete-Policy festlegen — und Metadaten-Ingestion von Daten-Ingestion trennen.
Was diese Serie klärt
- Orientierung: Connector-Entscheidungsmodell
- Vertiefung: Warehouse- und Lakehouse-Services
- Abschluss mit betreibbaren Next Steps über Multi-Source: Identität und Betrieb
Begriffe und Kürzel vor dem Lesen
- dbt — data build tool: SQL-nahe Transformationsschicht; Modelle brauchen verantwortliche Person, Tests und Verträge wie jedes Datenprodukt.
- BI — Business Intelligence: Reporting- und Analyseflächen, die governte Kennzahlen und Datenprodukte nutzen.
- verantwortliche Person — Person oder Rolle mit der Pflicht, Bedeutung, Nutzung, Risiko und Freigabe für ein Datenprodukt oder eine Kennzahl zu entscheiden.
- Metadata — Daten über Daten: Definition, verantwortliche Person, Quelle, Aktualität, Qualität, Klassifikation, Lineage, Status.
- Data Catalog — Auffindbarkeitsschicht für Assets, Begriffe, Owner und Richtlinien — eine Anwendung von Metadata, nicht Metadata selbst.
- Nachweis — Nachweis, dass Kontrolle, Entscheidung oder Test stattfand — Zeitstempel, verantwortliche Person, prüfbare Artefakte.
Lesepfad
- Connector-Entscheidungsmodell
- Warehouse- und Lakehouse-Services
- Transformation und dbt-Handoff
- BI- und Analytics-Services
- Pipelines und Orchestrierung
- Messaging und Storage
- SaaS als Metadatenquellen
- Multi-Source: Identität und Betrieb
Die Beispiele sind Lehrfälle (keine Kundendaten). Ersetzt Tabellen-, Report-, Pfad- und Toolnamen durch eure Catalog-, BI-, Ticket- und Prozessquellen.
Herausforderung
In om-pilot wird „Snowflake-Connector an“ geklickt: alle Schemas, Prod und Dev gemischt, Delete überschreibt Owner-Felder. Metadaten-Ingestion harvestet Kontext — sie lädt keine Auftragsdaten aus sales_otc. Vor dem ersten Run Decision Record: Service snowflake-sales-otc, Scope nur sales_otc, Freshness-SLO, Owner, Identity-Namespace, Delete-Policy.
Größenordnung: KMU — ein Warehouse-Connector, dann dbt/BI bei Bedarf. Mid-Market — geschichtete Sources mit Freshness SLOs. Enterprise — Multi-Source Identity, SaaS Metadata, Ops Scorecards.
Wer Metadaten- und Daten-Ingestion vermischt, plant falsche SLAs, falsche Credentials und falsche Erwartungen an „Vollständigkeit“.
Ansatz
Jeden Connector als Metadatenprodukt behandeln. Vor dem ersten Run einen Decision Record festlegen: Service-Typ, Scope, Freshness-SLO, Owner, Identity-Namespace, Credentials-Pfad und Delete-Policy.
Daten-Ingestion → Warehouse/Lakehouse (Daten bewegen)
Metadaten-Ingestion → OpenMetadata (Kontext verbinden)
Pflichtfelder vor dem ersten Run
| Feld | Frage | Tipp |
|---|---|---|
| Service-Typ | Database, Dashboard, Pipeline, Messaging, Storage, ML? | Ein Typ pro Decision Record — keine Misch-Services |
| Scope | Welche DBs/Schemas/Workspaces — und was bewusst draußen bleibt? | Exclude-Listen sind Teil des Produkts |
| Identity-Namespace | Wie heißen Environments und Instanzen in FQNs? | …-prod / …-dev von Tag 1 |
| Freshness-SLO | Wie alt darf der letzte erfolgreiche Run sein? | Stale ≠ Failure — beides alerten |
| Owner | Wer eskaliert bei Fehler und Stale-Ingestion? | Name/Team, nicht „Platform allgemein“ |
| Delete-Policy | Soft-delete nach N Misses oder nie auto-delete? | Default des Tools ist keine Policy |
| Secrets | Welcher Vault-/Secret-Pfad — Least Privilege? | Nie Human-SSO als Bot |
Abgrenzung
| Thema | Serie / Story |
|---|---|
| Welche SaaS-Tabellen laden | source-load-decisions |
| dbt-Artefakt-How-to | Getting Started Teil 8 |
| Metadatenimport-Architektur allgemein | MetaData Deep Dive Teil 4 |
| Betrieb/Auth der Control Plane | Getting Started Teile 4–6 |
Best Practices
Ein Business Flow, ein enger Scope
Ein Pilotprojekt soll beweisen, dass Metadaten für einen fachlichen Ablauf (z. B. Sales-Mart von Warehouse-Tabelle bis Dashboard) im Katalog auffindbar, owned und frisch sind — nicht, dass der Connector technisch „alles“ sehen kann.
Wenn ihr „alles harvestet“, entstehen oft Zehntausende Assets ohne Owner, ohne Domain und ohne Priorität. Stewardship erstickt im Inventar, Discovery wird laut, und niemand weiß, welcher Scope absichtlich war. Enger Scope heißt: Include-Liste für die Schemas/Workspaces des Flows plus Exclude für Staging/Temp — und erst erweitern, wenn Freshness und Owner für das Pilotprojekt stehen.
Decision Record vor Credentials
Sobald ein Bot-Secret existiert, tendieren Teams dazu, Scope aus Berechtigungen abzuleiten: „Was der Bot darf, harvesten wir.“ Das verdreht die Reihenfolge. Zuerst entscheiden Scope, Owner, SLO und Delete-Policy schriftlich; danach baut ihr eine Identity, die genau diesen Scope abdeckt (Least Privilege).
Sonst wird der Connector zum Spiegel eurer IAM-Zufälle — und Scope-Reviews werden unmöglich, weil niemand mehr sagen kann, was bewusst draußen bleiben sollte.
Owner und SLO zusammen freigeben
Ein Freshness-Ziel ohne Eskalationspfad greift nicht: Der Job wird rot oder stale, und das Ticket landet bei „Platform allgemein“. Owner meint die Person/das Team, das bei Failure und bei Stale handelt — oft Platform für Runner, Domain für Source-Rechte und fachlichen Scope.
Deshalb: Connector erst „prod“ nennen, wenn Owner und SLO im Decision Record stehen und Alerts an diese Adresse gehen. Credentials ohne Owner sind dasselbe Anti-Pattern in anderer Form.
Delete-Policy vor dem ersten Prod-Run reviewen
Ingestion-Defaults können Assets entfernen oder soft-deleten, sobald sie in der Source „fehlen“ (Rename, Outage, Filter-Regression). Kuratierte Descriptions, Glossary-Links und Owner hängen an diesen Assets. Ohne explizite Policy (Soft-delete nach N Misses, Quarantäne, nie auto-delete für kritische Typen) vernichtet der erste Prod-Run Wochen Stewardship-Arbeit.
Review heißt: Policy aufschreiben, auf Staging mit absichtlichem Rename/Miss testen, Ergebnis datieren — nicht „Default des Tools“ akzeptieren.
Environments nie still mischen
snowflake-prod und snowflake-dev (oder harte Namespace-Prefixe) von Tag 1. Ein Service, der beide Environments „irgendwie filtert“, vermischt FQNs, Lineage und Verantwortung. Später lassen sich Prod- und Dev-Assets kaum noch trennen, und dbt-/BI-Connectoren hängen am falschen Ziel.
Regel: getrennte Services oder dokumentierte, maschinenlesbare Namespace-Regeln — nie „wir unterscheiden das in der UI“.
Stolperfallen
Prod zum Ausprobieren. Ein breiter Connector „nur kurz“ auf dem Prod-Warehouse erzeugt sofort Inventar und Delete-Risiko. PoC gehört auf Non-Prod oder auf einen winzigen Prod-Pilotprojekt-Scope mit Decision Record.
Anzeigenamen als Identity. Schemas und Tabellen werden umbenannt. Wenn eure Links und Lineage am Display-Namen hängen, zerbrechen Erwartungen. Stabile Service-IDs und FQN-Konventionen zuerst; Anzeigenamen dürfen sich ändern.
Soft-delete weglassen oder Hard-Delete ohne Quarantäne. Glossary-Terms und Beschreibungen zeigen dann ins Leere — oder verschwinden mit dem Asset. Soft-delete/Quarantäne sind Betriebsfeatures, keine Nice-to-haves.
Metadaten- und Daten-Ingestion in einem Ticket. „Salesforce laden und katalogisieren“ vermischt Load-Decisions (source-load-decisions) mit Katalog-Scope. Zwei Records, zwei Reviews — sonst steuert die Pipeline heimlich den Katalog.
Vorgehen
- Einen Business Flow und eine Domain benennen.
- Den kleinsten Service wählen, der diesen Flow abbildet (meist Warehouse).
- Decision Record ausfüllen und reviewen (Platform + Domain).
- Connector mit engem Scope starten; Smoke: 5–20 kritische Assets sichtbar.
- Erst nach stabiler Freshness und sichtbarem Owner erweitern.
Hilfe beim Umsetzen
Kopiert die Pflichtfeld-Tabelle 1:1 in euer Ticket-Template. Review = Platform + Domain unterschreiben Scope und Delete-Policy. Danach erst Secret anlegen und Config mit OpenMetadata-Ingestions-Generator erzeugen.
Definition of Done für das Pilotprojekt: 5–20 kritische Assets sichtbar, Owner gesetzt oder klar geplant, Freshness-Alert greift, Delete-Policy auf Staging getestet.
Checkliste
- Ist klar, dass dieser Connector keine Daten kopiert?
- Sind Umfang und Exclude-Listen dokumentiert?
- Existiert ein benannter Owner und Eskalationspfad?
- Ist der Identity-Namespace über Environments konsistent?
- Ist die Delete-Richtlinie explizit — nicht „Default des Tools“?
- Liegt das Secret nur im Secret Store?
Artefakt
Einen Connector Decision Record erstellen: Service-Typ, Instanz, Scope, SLO, Owner, Secret-Referenz, Delete-Policy, Review-Datum.
Tools
- OpenMetadata-Ingestions-Generator — Decision Record in Starter-Config/Checkliste überführen.
- OpenMetadata Connectors — Connector-Typen und Ingestion-Übersicht.
- Secret Store + Change-Ticket (intern) — Credentials und Umfang-Review.
Ressourcen
OpenMetadata: Connecting Source Systems
Part 1 of 8
View series