dbt-Artefakte in OpenMetadata ingestieren

Herausforderung

Warehouse und Glossar für sales_otc in om-pilot stehen; dbt-Beschreibungen und Tests liegen nur in CI. Im Katalog fehlt der produktionsreife Handoff am dbt-Modell (z. B. fct_orders): manifest/catalog/run_results aus einem CI-Run und einer Umgebung — sonst Drift und Schein-Lineage.

Ohne belastbare Artefakt-Pipeline entstehen drei typische Fehler:

• manifest.json, catalog.json und run_results.json stammen aus unterschiedlichen Runs oder Umgebungen und werden trotzdem zusammengeführt;
• Artefakte liegen in Entwickler-Ordnern statt in einem versionierten, CI-publizierten Speicher;
• meta.* aus dbt-YAML erscheint nicht konsistent in OpenMetadata, weil Mapping und Provenance fehlen.

Ansatz

dbt-Artefakte als eigenes Ingestion-Produkt behandeln — mit klarer Identity pro Umgebung, Invocation und Commit. OpenMetadata Deep Diveet die Evidenz; dbt bleibt autoritativ für Transformation, Tests und deklarierte Metadaten.

dbt run (CI) → Artefakt-Set publizieren → OpenMetadata dbt-Ingestion
→ Lineage + Modellkontext + Test-Trust-Signals im Katalog

Welche Artefakte — und wofür

Regel: Ein Ingestion-Run verarbeitet nur Artefakte, die dieselbe Projektidentität, Umgebung, Invocation-ID und Commit-Revision teilen.

Vorgehen

1. dbt-Projekt und Umgebung benennen — z. B. sales-transform / prod; keine gemischten Pfade.
2. CI nach jedem relevanten dbt run Artefakte publizieren — fester Pfad oder Objektspeicher, nicht „neueste Datei im Ordner“.
3. OpenMetadata dbt-Ingestion konfigurieren — Service, Credentials, Artefakt-Locations, Schedule.
4. Warehouse zuerst ingestieren — physische Tabellen müssen existieren, bevor Lineage sinnvoll verknüpft wird (Connectors Teil 2 (Warehouse-Service)).
5. Ersten Scope begrenzen — ein Business Flow, ein dbt-Projekt, eine Umgebung.
6. meta.*-Mapping prüfen — Owner, Domain, Klassifikation sichtbar und mit Provenance.
7. run_results als Trust Signal nutzen — Teststatus am Asset; Details siehe operational-data-quality-dbt und Governance Teil 5.

Minimales CI-Muster

# Nach dbt run / dbt test — Artefakte mit Kontext publizieren
artifacts:
  paths:
    - target/manifest.json
    - target/catalog.json
    - target/run_results.json
  metadata:
    dbt_project: sales-transform
    environment: prod
    git_commit: ${CI_COMMIT_SHA}
    invocation_id: ${DBT_INVOCATION_ID}

Der OpenMetadata-Workflow liest aus dem publizierten Speicher — nicht aus lokalen target/-Ordnern auf Entwickler-Laptops.

Provenance pro Ingestion-Run

Jeder erfolgreiche Import sollte festhalten:

• Projekt- und Service-Identität;
• Umgebung (prod, staging, …);
• invocation_id oder äquivalenten Run-Identifier;
• Commit / Deployment-Identifier;
• Artefakt-Schemaversion (dbt-Version);
• Zeitpunkt der Erfassung.

Hilfe beim Umsetzen

Gates (alle grün): Warehouse-Service desselben Environments fresh → CI publiziert manifest+catalog+run_results in den Environment-Pfad → Mapping dbt→OM reviewt. Dann erst Workflow scharf.

Nutzt OpenMetadata-Ingestions-Generator für die Workflow-Checkliste und Schema YML Editor für saubere meta.*, bevor ihr Artefakte published. Bei kaputter Lineage zuerst Environment-Mismatch und Service-Namen prüfen, nicht dbt neu bauen.

Checkliste

• Liegen alle drei Kernartefakte (manifest, catalog, run_results) aus demselben Run vor?
• Ist der Artefakt-Speicher nur über CI/Deployment beschreibbar?
• Ist Warehouse-Ingestion für die referenzierten Schemas aktiv?
• Zeigt OpenMetadata Lineage für mindestens ein kritisches Modell?
• Sind meta.*-Felder (verantwortliche Person, Domain, Klassifikation) im Katalog sichtbar?
• Sind fehlgeschlagene Tests am dbt-Modell als Trust Signal erkennbar?
• Gibt es Monitoring, wenn Ingestion stale wird oder fehlschlägt?

Artefakt

Einen dbt-Ingestion Decision Record erstellen: Projekt, Umgebungen, Artefakt-Pfade, OpenMetadata-Service, Schedule, Mapping-Regeln für meta.*, Owner, Freshness-SLO und Eskalationspfad.

Tools

• OpenMetadata-Ingestions-Generator — Starter-YAML und Checkliste für dbt-Ingestion-Workflow.
• Schema YML Editor — meta.* und schema.yml vor dem Publish sauber halten.
• OpenMetadata Connectors — dbt-Connector-Doku.
• dbt Core + CI/CD + Artifact Store (intern) — Veröffentlichungspfad pro Environment.

Ressourcen

• OpenMetadata dbt Connector
• dbt — manifest JSON
• dbt — run_results JSON
• dbt — catalog JSON

Weiterlesen

• Governance mit OpenMetadata
• OpenMetadata: Quellsysteme anbinden