Metadatengetriebene Governance mit dbt meta

Laufzeitbezug: dbt v1.12 (Python), Stand 17.10.2026. Die Macro-/Artefaktbeispiele dieses Beitrags beziehen sich auf die aktuelle stabile Python-Linie. Für dbt v2.0 müssen Pakete, Adapter-APIs und das veränderte Parse-/Build-Verhalten anhand des offiziellen Upgrade-Guides separat geprüft werden. Eine ausgeführte v2-Validierung dieser Beispiele wird nicht behauptet.

Begriffe vor dem Lesen

• dbt (data build tool) organisiert SQL-basierte Datentransformationen als versionierten Code.
• meta ist ein frei definierbarer Metadatenbereich in dbt. Er speichert Hinweise und Entscheidungen, setzt sie aber nicht von selbst durch.
• Manifest bezeichnet die von dbt erzeugte maschinenlesbare Beschreibung der Modelle, Spalten, Abhängigkeiten und Metadaten.
• CI (Continuous Integration) prüft Änderungen automatisiert, bevor sie zusammengeführt oder bereitgestellt werden.

Governance-Entscheidungen benötigen einen maschinenlesbaren Vertrag

Part 1, End-to-End-Governance-Architektur, hat Governance als verbundenes System definiert:

Richtlinie
→ Metadaten
→ Code
→ Durchsetzung
→ Nachweis

Die Architektur benötigt nun einen technischen Vertrag, der Development, Review und Automatisierung durchlaufen kann.

dbt meta bietet dafür einen praktikablen Ort.

Die meta-Konfiguration akzeptiert eigene Key-Value-Paare auf dbt-Ressourcen. Die Werte werden in manifest.json aufgenommen und können in der generierten Dokumentation erscheinen.

Damit eignet sich meta unter anderem für:

• Verantwortung;
• Domäne;
• personenbezogene Daten-Klassifikation;
• Sensitivität;
• Aufbewahrung;
• Schutz-Richtlinie;
• Quality Tier;
• Review-Status;
• Generierungsstatus.

Ein frei verwendbares Dictionary ist jedoch noch keine Governance.

dbt meta wird erst dann zu einem Governance-Vertrag, wenn Vokabular, Geltungsbereich, Validierung, Freigabe und nachgelagerte Verwendung explizit definiert sind.

meta speichert Kontext — erzwingt aber nicht jede Regel

Ein Metadateneintrag wie:

config:
  meta:
    sensitivity: confidential
    masking_policy: email_mask

bindet nicht automatisch eine Masking Policy im Warehouse an.

Er verhindert nicht automatisch ein unberechtigtes Deployment.

Er beweist nicht, dass ein Steward die Klassifikation genehmigt hat.

Er garantiert nicht, dass eine abgeleitete Downstream-Spalte dieselbe Bedeutung besitzt.

Der Wert des Vertrags entsteht durch die Systeme um ihn herum:

dbt-YAML oder SQL-Config
→ Code Review
→ dbt parse
→ Manifest-Validierung
→ Generierungs- oder Propagierungslogik
→ Warehouse-Implementierung
→ Laufzeitprüfung

Das Vokabular vor den Keys definieren

Ein häufiger Fehler besteht darin, dass jeder Entwickler neue Keys einführt, sobald eine neue Anforderung entsteht.

Das Ergebnis ist gültiges YAML, aber semantisch inkonsistente Metadaten:

pii: yes
personal_data: true
contains_pii: Y
data_class: personal
sensitive: email

Alle fünf Einträge können ein ähnliches Konzept beschreiben. Automatisierung kann sie nicht sicher als gleichwertig behandeln.

Ein kontrolliertes Vokabular sollte definieren:

• exakten Key;
• Zweck;
• erlaubte Werte;
• Geltungsbereich;
• verantwortliche Person;
• Default;
• Freigaberegel;
• Propagierungsverhalten;
• Durchsetzung-Mapping.

Ein kompaktes Governance-Dictionary kann so beginnen:

Dieses Dictionary sollte wie Code versioniert werden.

Explizite Review-Status verwenden

Ein Boolean wie pii: true beschreibt eine Klassifikation, aber nicht deren Freigabestatus.

Eine erkannte oder neu generierte Spalte darf nicht wie eine durch einen Steward genehmigte Klassifikation aussehen.

Verwende einen expliziten Workflow:

unreviewed
→ proposed
→ approved
→ rejected
→ deprecated

Die genauen Status können abweichen. Die Unterscheidung muss jedoch sichtbar bleiben.

Beispiel:

columns:
  - name: email
    config:
      meta:
        pii: true
        pii_category: email
        sensitivity: confidential
        classification_status: approved

  - name: contact_channel
    config:
      meta:
        pii: null
        classification_status: unreviewed

unreviewed sollte normalerweise verhindern, dass ein neues oder potenziell sensibles Feld in governte Downstream-Nutzung überführt wird.

Metadaten am richtigen Scope ablegen

dbt unterstützt Metadaten auf mehreren Ressourcentypen und Ebenen.

Für diese Serie sind besonders wichtig:

• Source;
• Source-Tabelle;
• Modell;
• Spalte.

Metadaten auf Source-Ebene

Source-Metadaten beschreiben das Quellsystem oder den Ingestion-Kontext.

version: 2

sources:
  - name: crm_landing
    database: LANDING
    schema: CRM

    config:
      meta:
        source_system: crm
        ingestion_owner: data_platform
        data_owner: sales_operations
        retention_class: source_delivery_30d

Metadaten auf Source-Tabellenebene

Metadaten auf Tabellenebene beschreiben ein einzelnes geliefertes Objekt.

    tables:
      - name: customer
        config:
          meta:
            domain: customer
            source_of_record: true
            classification_status: approved

Metadaten auf Modellebene

Modellmetadaten beschreiben das governte Datenprodukt oder den Transformationsknoten.

models:
  - name: raw_crm_customer
    description: Source-aligned customer data.

    config:
      meta:
        domain: customer
        data_owner: sales_operations
        steward: data_governance
        custodian: data_platform
        quality_tier: critical
        generated: true

Metadaten auf Spaltenebene

Spaltenmetadaten beschreiben Bedeutung und Behandlung eines einzelnen Feldes.

    columns:
      - name: email
        description: Customer email address.

        config:
          meta:
            pii: true
            pii_category: email
            sensitivity: confidential
            classification_status: approved
            masking_policy: email_mask

Spaltenmetadaten erben nicht vom Modell

Dieser Punkt ist für das Governance-Design entscheidend.

Spalten sind keine eigenständigen dbt-Ressourcen. Ihre meta-Werte erben nicht die meta-Werte der übergeordneten Ressource.

Ein Modell kann als vertraulich klassifiziert sein:

config:
  meta:
    sensitivity: confidential

Das bedeutet nicht, dass jede Spalte automatisch Folgendes enthält:

config:
  meta:
    sensitivity: confidential

Eigene Validierungs- oder Propagierungslogik kann einen organisatorischen Fallback definieren. Das ist jedoch eine eigene Regel und keine implizite dbt-Vererbung.

Ein sinnvolles Muster lautet:

Modellmetadaten
→ Default-Kontext für das Review

Spaltenmetadaten
→ explizite Klassifikations- und Schutzentscheidung

Verantwortung, Klassifikation, Schutz und Lifecycle trennen

Eine flache Liste von Keys wird schwer steuerbar, wenn voneinander unabhängige Konzepte vermischt werden.

Gruppiere die Metadaten logisch.

Verantwortung

data_owner: sales_operations
steward: data_governance
custodian: data_platform
domain: customer

Klassifikation

pii: true
pii_category: email
sensitivity: confidential
classification_status: approved

Schutz

masking_policy: email_mask
row_access_domain: legal_entity
allowed_usage:
  - customer_service
  - finance_reporting

Lifecycle

retention_class: operational_7y
deletion_rule: source_contract
source_of_record: true

Betrieb

quality_tier: critical
criticality: tier_1
review_date: 2027-01-31
generated: true

Ein vollständiges Modellbeispiel

Eine praktische Properties-Datei kann so aussehen:

version: 2

models:
  - name: raw_crm_customer
    description: Source-aligned customer data from the CRM landing table.

    config:
      materialized: view
      tags:
        - raw
        - customer
      meta:
        domain: customer
        data_owner: sales_operations
        steward: data_governance
        custodian: data_platform
        retention_class: operational_7y
        quality_tier: critical
        classification_status: approved
        generated: true

    columns:
      - name: customer_id
        description: Source customer identifier.
        data_tests:
          - not_null
          - unique
        config:
          meta:
            pii: false
            sensitivity: internal
            classification_status: approved

      - name: email
        description: Customer email address.
        config:
          meta:
            pii: true
            pii_category: email
            sensitivity: confidential
            classification_status: approved
            masking_policy: email_mask

      - name: phone
        description: Customer phone number.
        config:
          meta:
            pii: true
            pii_category: phone
            sensitivity: confidential
            classification_status: proposed
            masking_policy: phone_mask

      - name: preferred_contact_time
        description: Newly delivered source field.
        config:
          meta:
            classification_status: unreviewed

Das Beispiel trennt bewusst:

• Modell-Verantwortung;
• Spaltenklassifikation;
• Schutz-Mapping;
• Review-Status;
• Quality Tests.

Stabile Policy-Referenzen in meta ablegen — keine Betriebs-Secrets

Gute meta-Werte sind:

• deterministisch;
• reviewbar;
• ausreichend stabil für Versionierung;
• außerhalb einer einzelnen Ausführung verständlich;
• sicher in Artefakten und Dokumentation.

Geeignete Beispiele:

domain: customer
sensitivity: confidential
masking_policy: email_mask
retention_class: operational_7y

Nicht geeignet sind:

• Passwörter;
• Tokens;
• Secret Keys;
• persönliche Zugangsdaten;
• aktuelle Benutzerberechtigungen;
• große Access-Kontrollregel-Listen;
• volatile Laufzeitwerte;
• unstrukturierte rechtliche Bewertungen.

Die Metadaten sollten eine Policy oder Berechtigung-Domäne referenzieren und nicht das gesamte Laufzeit-Security-System einbetten.

Das Manifest macht den Vertrag konsumierbar

dbt nimmt Ressourcenmetadaten in manifest.json auf.

Damit wird das Manifest zu einem nützlichen Integrationsartefakt für:

• CI-Validierung;
• Dokumentation;
• Kataloge;
• Impact-Analyse;
• Codegenerierung;
• Metadatenpropagierung;
• Warehouse-Richtlinie-Mapping;
• Governance-Reporting.

Die Manifest-Version ist an das dbt-Artefaktschema gebunden. Konsumenten sollten das korrekte Schema für die eingesetzte dbt-Version verwenden und nicht davon ausgehen, dass die JSON-Struktur unverändert bleibt.

Ein vereinfachter Validierungsprozess lautet:

dbt parse
→ target/manifest.json lesen
→ Modell- und Spaltenmetadaten prüfen
→ Organisationsregeln anwenden
→ Pull Request stoppen oder freigeben

Den Vertrag vor dem Build validieren

YAML-Syntaxprüfung reicht nicht aus.

Die folgende Datei ist gültiges YAML:

config:
  meta:
    pii: perhaps
    sensitivity: very_secret
    classification_status: done

Sie enthält jedoch keine gültigen Governance-Metadaten, wenn die freigegebenen Werte lauten:

pii: true | false | null
sensitivity: public | internal | confidential | restricted
classification_status: unreviewed | proposed | approved | rejected | deprecated

Ein CI-Validator sollte mindestens prüfen:

• Pflicht-Verantwortung auf governten Modellen;
• erlaubte Enum-Werte;
• personenbezogene Daten-Spalten besitzen eine Kategorie;
• freigegebene personenbezogene Daten-Spalten besitzen ein freigegebenes Schutz-Mapping;
• ungeprüfte Spalten gelangen nicht in geschützte Downstream-Layer;
• kritische Modelle benennen einen technischer Betreiber;
• Retention Classes existieren im Richtlinie-Katalog;
• generierte Metadaten überschreiben keine freigegebenen manuellen Entscheidungen.

Ein vereinfachter Python-Validator kann das Manifest untersuchen:

for node in manifest["nodes"].values():
    if node.get("resource_type") != "model":
        continue

    model_meta = node.get("config", {}).get("meta", {})

    require(model_meta, "data_owner")
    require(model_meta, "custodian")
    validate_enum(model_meta, "quality_tier", QUALITY_TIERS)

    for column_name, column in node.get("columns", {}).items():
        column_meta = column.get("meta", {})

        validate_enum(
            column_meta,
            "classification_status",
            CLASSIFICATION_STATES,
        )

        if column_meta.get("pii") is True:
            require(column_meta, "pii_category")

            if column_meta.get("classification_status") == "approved":
                require(column_meta, "masking_policy")

Die konkrete Manifest-Struktur muss zum dbt-Artefaktschema des Projekts passen.

Automatisierte Validierung ersetzt keine Freigabe

Automatisierung kann prüfen:

• ein Wert ist vorhanden;
• ein Wert gehört zu einer erlaubten Menge;
• zusammengehörige Felder sind konsistent;
• eine freigegebene personenbezogene Daten-Spalte referenziert eine Masking Richtlinie;
• eine neue Spalte bleibt ungeprüft;
• ein Modell besitzt eine verantwortliche Person.

Automatisierung kann nicht zuverlässig entscheiden:

• ob ein Feld im konkreten Kontext rechtlich personenbezogen ist;
• ob ein fachlicher Zweck erlaubt ist;
• ob eine Aggregation ausreichend anonym ist;
• ob eine Retention-Ausnahme gerechtfertigt ist;
• ob eine Downstream-Nutzung akzeptabel ist.

Der Workflow benötigt deshalb beides:

Automatisierte Validierung
+
menschliche Governance-Freigabe

Ein grünes CI-Ergebnis beweist die strukturelle Einhaltung des Vertrags. Es beweist nicht, dass jede Klassifikation fachlich korrekt ist.

Das Business-Glossar verbinden — nicht duplizieren

dbt meta eignet sich für technische Governance-Attribute in der Nähe des Codes.

Es sollte nicht zum einzigen Enterprise-Glossar werden.

Eine sinnvolle Aufteilung ist:

dbt kann Referenzen speichern:

glossary_term: customer_email
policy_id: privacy_pii_001
retention_class: operational_7y

Dadurch bleibt der Code mit Governance verbunden, ohne vollständige Richtliniendokumente zu duplizieren.

Für Generierung und Propagierung entwerfen

Der Vertrag sollte die nächsten beiden Parts der Serie unterstützen.

Part 3: kontrollierte RAW-Generierung

Ein Generator kann Folgendes kombinieren:

Physische Warehouse-Metadaten
+
freigegebene Governance-Metadaten
+
Generierungskonventionen

und daraus Source-YAML, RAW-SQL und Model Properties erzeugen.

Neue Spalten sollten mit folgendem Status generiert werden:

classification_status: unreviewed

Part 4: Metadatenpropagierung

Ein Propagierungsprozess kann Lineage und Transformationssemantik untersuchen und entscheiden, ob Metadaten:

• kopiert;
• zusammengeführt;
• herabgestuft;
• hochgestuft;
• entfernt;
• zur Prüfung vorgelegt werden.

Dieser Prozess benötigt stabile und explizite Metadaten-Keys. Freie Notizen reichen dafür nicht aus.

Häufige Metadaten-Anti-Patterns

Ein Boolean für jede Sensitivität

pii: true definiert weder Kategorie, Sensitivität, Status noch Schutz.

Freie Werte

high, very high, secret, sensitive und restricted lassen sich nicht konsistent automatisieren.

Kein Freigabestatus

Erkannte und genehmigte Klassifikationen sind nicht unterscheidbar.

Metadaten nur auf Modellebene

Sensible Spalten bleiben technisch uneindeutig.

Angenommene Vererbung

Spaltenverhalten hängt von nicht dokumentierter Fallback-Logik ab.

Eingebettete Laufzeitberechtigungen

Versionierte Projektdateien werden zu einem zweiten Identity-Management-System.

Generierung überschreibt freigegebene Metadaten

Ein Schema-Refresh zerstört stillschweigend Steward-Entscheidungen.

Metadaten ohne Durchsetzung-Mapping

Die Plattform dokumentiert ein Risiko, reduziert es aber nicht.

Die zentrale Erkenntnis

dbt meta ist der versionierte technische Vertrag zwischen Governance-Entscheidungen und Plattformautomatisierung.

Der Vertrag muss:

• kontrolliert;
• explizit;
• validiert;
• reviewbar;
• maschinenlesbar;
• mit führenden Richtlinien verbunden;
• von Betriebs-Secrets getrennt;
• für Generierung und Propagierung vorbereitet sein.

Part 3, Automatische RAW-Generierung mit dbt-Macros, verwendet diesen Vertrag, um wiederkehrendes RAW-Grundgerüst zu erzeugen, ohne Git-Review, Lineage oder Governance-Kontrolle zu verlieren.

Quellen und weiterführende Dokumentation

• dbt — meta configuration
• dbt — columns property
• dbt — source configurations
• dbt — manifest JSON
• dbt — about dbt artifacts
• dbt — docs commands