Native Metadaten im Data Stack

Jede Plattform weiß bereits etwas Wichtiges

Bevor ein weiterer Catalog für sales_otc gekauft wird: Snowflake kennt Schema und Grants, dbt Lineage und Tests, Qlik Measures — und niemand hat das inventarisiert. Native Metadaten zuerst kartieren; sonst kauft man eine zweite Kopie unbekannter Lücken.

Ein moderner Data Stack enthält bereits viele partielle Metadatensysteme:

• eine operative Anwendung kennt Feldbezeichnungen, Prozesszustände und Quell-Constraints;
• eine Database kennt Schemas, Objekte, Berechtigungen und Query-Aktivität;
• ein Lakehouse kennt Tabellen, Files, Notebooks, Jobs und Betrieb Lineage;
• Transformationscode kennt Models, Abhängigkeiten, Tests und Dokumentation;
• ein Orchestrator kennt Zeitpläne, Runs, Retries und Fehler;
• eine BI-Plattform kennt Measures, Dimensions, Reports und nutzernahe Semantik;
• eine Identity-Plattform kennt User, Groups, Roles und Access Events;
• eine Streaming-Plattform kennt Topics, Partitions, Offsets und Schema-Versionen;
• ein Observability-System kennt Checks, Incidents und Freshness-Evidenz;
• eine KI-Plattform kennt Datasets, Experiments, Parameters, Metrics und Models.

Jede Plattform besitzt eine lokale Perspektive. Normalerweise versteht keine davon den vollständigen Enterprise-Kontext.

Ein Warehouse kann wissen, dass analytics.fct_sales_order_line.net_sales_amount ein Decimal-Feld ist, das von mehreren Usern abgefragt wird. Es weiß möglicherweise nicht, ob der Wert bestellten, fakturierten oder realisierten Umsatz repräsentiert. Ein BI Model kann den freigegebenen Measure-Ausdruck und das Format kennen, aber nicht den ursprünglichen operativen Statusübergang, der bestimmt hat, ob eine Zeile berücksichtigt werden durfte. Eine Identity-Plattform kann beweisen, dass eine Group Zugriff erhalten hat, aber nicht, ob das zugrunde liegende Dataset die richtige Quelle für einen Management-KPI war.

Eine gute Metadatenarchitektur beginnt mit einem Inventar nativer Fähigkeiten, Interfaces, Autorität und Lücken. Ein zusätzliches Tool sollte fehlenden Kontext und systemübergreifende Beziehungen verbinden — nicht Metadaten neu erzeugen, die eine andere Plattform bereits korrekt pflegt.

Das erste Ergebnis ist deshalb keine Vendor Shortlist. Es ist ein Inventar nativer Metadaten.

Metadatendimensionen trennen, bevor Produkte verglichen werden

Ein Produkt sollte nicht als „metadatenreich“ oder „metadatenarm“ klassifiziert werden, ohne die Metadatendimension zu benennen.

Sieben Dimensionen decken die meisten Enterprise-Anforderungen ab.

Schema-Metadaten

Schema-Metadaten beschreiben implementierte Strukturen:

catalog
schema
table
view
file
topic
column
data type
nullability
key
constraint
partition
format

Databases, Warehouses, Lakehouses, Schema Registries und Semantic Models kennen diese Dimension normalerweise gut.

Lineage-Metadaten

Lineage-Metadaten beschreiben Abhängigkeit und Bewegung:

source asset
transformation or process
target asset
column mapping
runtime observation
code reference
execution identifier
lineage confidence

Transformation Tools, Query Engines, Orchestrators, Streaming-Plattformen und BI-Systeme können jeweils unterschiedliche Lineage-Segmente beitragen.

Semantische Metadaten

Semantische Metadaten beschreiben Bedeutung und analytisches Verhalten:

business definition
measure
dimension
calculation
aggregation
grain
filter behaviour
format
synonym
approved use

Semantic Layers und BI-Plattformen enthalten häufig die vollständigste nutzernahe Semantik. Ein zentraler Catalog, der diese Schicht ignoriert, verfehlt möglicherweise die Definitionen, die Menschen tatsächlich verwenden.

Operative Metadaten

Operative Metadaten beschreiben Ausführung:

schedule
run
duration
status
retry
checkpoint
refresh
failure
deployment
environment

Orchestrators, Transformation Platforms, Stream Processors, Warehouses und Observability Tools sind normalerweise autoritativ für diese Evidenz.

Usage-Metadaten

Usage-Metadaten beschreiben beobachtete Nutzung:

query
report view
dashboard access
model invocation
consumer group activity
popular asset
unused asset
last accessed

Usage kann über Engines, BI-Plattformen, Identity Logs und Application Telemetry verteilt sein. Sie ist selten an einem Ort vollständig.

Security-Metadaten

Security-Metadaten beschreiben Identität und Kontrolle:

user
group
role
grant
entitlement
classification
policy
masking rule
audit event
access decision

Identity-Plattformen, Data Engines, BI-Plattformen und Governance-Systeme halten jeweils unterschiedliche Teile des Security Models.

AI-Metadaten

AI-Metadaten beschreiben Data-Science- und Model-Lifecycle-Kontext:

training dataset
feature
experiment
run
parameter
metric
artifact
model version
evaluation
prompt
deployment

Experiment Tracker und Model Registries sind in dieser Dimension stark, aber normalerweise schwach bei Enterprise Business Vocabulary und Policy Interpretation.

Diese Dimensionen überlappen. Sie sollten unterscheidbar bleiben, weil Verantwortung, Extraction Methods, Freshness und Control Requirements unterschiedlich sind.

Produktkategorien kennen unterschiedliche Teile der Wahrheit

Operative Systeme kennen das ursprüngliche Geschäftsverhalten

CRM-, ERP-, Finance-, Service- und Logistics-Anwendungen kennen häufig:

• ursprüngliche Labels und Help Text;
• Source Identifier;
• gültige Codes und Statuswerte;
• Prozessübergänge;
• Validierungs-Constraints;
• lokale Verantwortung;
• Source-of-Record-Verantwortung;
• Erstellungs- und Änderungszeitpunkte;
• operative Audit Events.

Ihre Schwäche ist häufig die konsistente Extraktion.

Einige Anwendungen stellen strukturierte APIs, Dictionaries oder Configuration Exports bereit. Andere besitzen nur Database Schemas, Administrationsoberflächen oder proprietäre Metadata Endpoints. Eine kopierte Datenbanktabelle kann Feldnamen und Typen zeigen, während die in der Anwendung konfigurierte Prozesssemantik verborgen bleibt.

Source Owner sollte das Application Team oder der accountable Business Process Owner sein — nicht das zentrale Catalog-Team.

Databases und Warehouses kennen implementierte Strukturen und Engine-Aktivität

Relationale Databases und Cloud Warehouses kennen normalerweise:

• Catalogs, Schemas, Tables, Views und Columns;
• Data Types, Keys und Constraints;
• Comments oder Extended Properties;
• verantwortliche Person, Roles und Grants;
• Object Dependencies;
• Statistics und Storage Properties;
• Query oder Access History;
• Engine-spezifische Richtlinien und Tags.

Typische Interfaces sind:

• INFORMATION_SCHEMA;
• System Catalog Views;
• Account-Usage-Schemas;
• SQL Functions;
• Audit Logs;
• REST APIs;
• JDBC- oder ODBC-Metadaten;
• Platform Event Streams.

Die Engine ist autoritativ für die aktuelle physische Implementierung. Sie ist nicht automatisch autoritativ für fachliche Bedeutung.

Lakehouse- und Streaming-Plattformen kennen Files, Tables, Events und Processing State

Lakehouse-Plattformen können verbinden:

• Files und Managed Tables;
• Notebooks und Jobs;
• Catalogs und Schemas;
• Table Versions;
• Access Kontrollregeln;
• Betrieb Operations;
• Data und Model Lineage.

Streaming-Plattformen kennen typischerweise:

• Topics;
• Partitions;
• Offsets;
• Brokers;
• Nutzer Groups;
• Retention und Configuration;
• Producer- und Nutzer-Aktivität.

Ein Broker kennt nicht zwingend die fachliche Bedeutung eines Event Payloads. Schema Registry, Data Contracts, Topic Descriptions und Producer Verantwortung können erforderlich sein, um diesen Kontext zu ergänzen.

Transformation und Orchestration kennen Code und Ausführung

Transformation Tools kennen:

• Source Declarations;
• Models;
• Dependencies;
• Tests;
• Documentation;
• kompiliertes oder ausgeführtes SQL;
• Deployment Environments;
• Run Results.

Orchestrators kennen:

• Workflows oder DAGs;
• Tasks;
• Schedules;
• Dependencies;
• Retries;
• Runs;
• Failures;
• Duration;
• Execution Parameters.

Das Transformation Repository sollte autoritativ für implementierte Business Logic bleiben. Der Orchestrator sollte autoritativ für Execution State bleiben. Eine zentrale Plattform kann beide Sichten verbinden, ohne Code in Prosa zu kopieren.

Semantic- und BI-Plattformen kennen Consumption Semantics

Qlik, Power BI, Tableau und ähnliche Tools können kennen:

• Fields;
• Associations oder Relationships;
• Dimensions;
• Measures;
• Calculations;
• semantisches Modells;
• Data Sources;
• Applications, Reports und Dashboards;
• Publication State;
• Usage und Verantwortung;
• usernahe Lineage.

Diese Schicht kann Business Logic enthalten, die weder im Warehouse noch im Transformation Repository existiert.

Ein Measure wie Recognized Revenue YTD kann ausschließlich in einem Semantic Model existieren. Eine Qlik Expression kann Selections, Set Analysis und Aggregation Behaviour verbinden. Ein Power-BI-Measure kann DAX Logic und Filter Context kodieren. Ein Tableau Calculated Field kann eine Consumer-nahe Definition tragen, die in der Source Database nicht sichtbar ist.

BI-Metadaten zu ignorieren erzeugt die falsche Annahme, dass das governte Datenmodell am Warehouse endet.

Identity- und Security-Plattformen kennen Personen und Berechtigungs

Identity-Plattformen kennen:

• Users;
• Groups;
• Service Principals;
• Roles;
• Memberships;
• Berechtigungs;
• Authentication Events;
• Provisioning;
• Administrative Changes;
• Access Reviews.

Sie sind autoritativ für Identity State. Sie wissen normalerweise nicht, warum ein Dataset existiert oder was ein Measure bedeutet.

Security-Metadaten müssen ebenfalls geschützt werden. Group Memberships, Audit Details und Access Paths können selbst sensitiv sein.

AI- und Data-Science-Plattformen kennen Experiments und Model Lifecycle

MLflow und ähnliche Plattformen können erfassen:

• Experiments und Runs;
• Parameters und Metrics;
• Code References;
• Artifacts;
• Datasets;
• Model Versions;
• Aliases und Tags;
• Evaluations;
• Deployment Context.

Diese Evidenz unterstützt Reproducibility und Model Governance.

Sie belegt nicht automatisch, ob das Training Dataset für den vorgesehenen Zweck freigegeben war, ob die Target Variable konzeptionell valide ist oder ob eine Feature Definition zum Enterprise Vocabulary passt. Diese Verbindungen müssen durch Governance-Metadaten ergänzt werden.

Plattformfamilien über Fähigkeitskategorien vergleichen, nicht über eine volatile Checkliste

Ein Vergleich über Fähigkeitskategorien ist dauerhafter als eine Matrix aus grünen und roten Haken.

Diese Tabelle bestimmt keinen Sieger. Sie zeigt, wo ein Inventar suchen muss.

Snowflake

Snowflake stellt breite technische und operative Metadaten über Information Schema und Account Usage Views bereit. Object Metadata, Dependencies, Query History, Access History, Tags und Policy References können über unterstützte SQL Interfaces abgefragt werden.

Wichtige Einschränkungen bleiben:

• View Latency und Retention unterscheiden sich;
• einige Fähigkeiten hängen von Edition oder Configuration ab;
• Object Dependencies repräsentieren nicht jede Form von Data Movement;
• Query-abgeleitete Lineage und deklarierte Dependencies sind unterschiedliche Evidenztypen;
• Business Definitions und Cross-Platform Semantics benötigen weiterhin externen Kontext.

Die richtige Inventarfrage lautet nicht „Hat Snowflake Metadaten?“, sondern:

Welche Snowflake Views sind aktiviert,
welche Environments werden abgedeckt,
wie lang ist die Retention,
wer verantwortet die Extraktion
und welche Beziehungen liegen außerhalb von Snowflake?

Databricks

Databricks mit Unity Catalog stellt Catalogs, Schemas, Tables, Columns, Permissions und Governance Context bereit. Information Schema, REST APIs und System Tables unterstützen programmatische Extraktion. Native Lineage kann Beziehungen für unterstützte Workloads erfassen und über Lineage System Tables abgefragt werden.

Die Coverage muss trotzdem bewertet werden:

• Objekte außerhalb von Unity Catalog können anders sichtbar sein;
• externe Systeme erscheinen möglicherweise nicht automatisch;
• Notebook-, Job-, Model- und Table-Beziehungen besitzen unterschiedliche Scopes;
• Preview Interfaces sollten ohne Prüfung nicht als stabile Vereinbarungen behandelt werden;
• Business Vocabulary und BI Semantics bleiben extern, solange sie nicht bewusst verbunden werden.

Unity Catalog kann eine starke quellnahe Governance-Schicht sein. Es entfernt nicht den Bedarf nach Enterprise Identity Resolution über mehrere Plattformen.

Microsoft Fabric

Microsoft Fabric verteilt Metadaten über Workspaces, OneLake, Lakehouse, Warehouse, Data Factory, Real-Time Intelligence, Semantic Models, Reports und administrative Services.

Der OneLake Catalog unterstützt Discovery innerhalb von Fabric. Metadata Scanner APIs können Tenant-, Workspace-, Item- und ausgewählte Semantic-Model-Subartifact-Metadaten liefern, wenn erforderliche Tenant Settings und Permissions konfiguriert sind. Fabric und Microsoft Purview können Metadaten und Lineage austauschen, die Granularität variiert jedoch nach Item Type und aktuellem Product Support.

Ein Inventar muss deshalb unterscheiden:

Fabric Item Metadata
Power BI Semantic Model Metadata
OneLake Object Metadata
Lineage shown in Fabric
Metadata returned by Scanner APIs
Metadata available to Purview
Activity and Audit Evidence

Alles als eine „Fabric Metadata API“ zu behandeln verdeckt wichtige Unterschiede.

Klassisches SQL Warehouse

Ein klassisches SQL Warehouse oder eine relationale Database stellt typischerweise langlebige System Catalogs, Information Schema, Roles, Grants, Constraints, Statistics und Engine Logs bereit. SQL Server ergänzt beispielsweise Catalog Views, Extended Properties, Query Store und Audit-Fähigkeiten.

Die Hauptlücke ist normalerweise der systemübergreifende Kontext.

Eine Database kann ihre eigenen Objekte sehr gut beschreiben und gleichzeitig wenig wissen über:

• vorgelagerte operative Anwendungen;
• außerhalb ausgeführte Transformationen;
• BI Measures;
• Report Usage;
• Enterprise Vocabulary;
• Model-Training-Nutzung;
• Stewardship Decisions.

Ein Lightweight Central Index kann deshalb erheblichen Mehrwert liefern, obwohl die Database selbst bereits starke Metadaten bereitstellt.

Transformation- und BI-Metadaten verbinden, nicht abflachen

dbt und Code Repositories

Ein dbt Project erzeugt ein besonders nutzbares Metadatenpaket.

Project und generierte Artifacts können beschreiben:

• Models und Sources;
• Tests;
• Macros;
• Exposures;
• semantisches Modells und Metrics;
• Dependencies;
• Descriptions;
• Verantwortung Conventions;
• Compiled Properties;
• Run Results;
• Source Freshness.

manifest.json repräsentiert Project Resources und Relationships. Weitere Artifacts ergänzen Catalog Details und Execution Evidence.

Git trägt eine andere Dimension bei:

• Commit Identifier;
• Author und Committer;
• Timestamp;
• Branch und Tag;
• Change History;
• Pull-Request- oder Review-Kontext, wenn die Hosting-Plattform ihn bereitstellt.

Git beweist, welcher Code sich wann geändert hat. Es beweist nicht, dass die fachliche Definition korrekt ist.

Das passende Muster lautet:

dbt resource
→ linked to source tables
→ linked to Git revision
→ linked to run evidence
→ linked to BI consumers
→ linked to approved business terms

Orchestration

Airflow und andere Orchestrators verstehen den Betrieb Graph.

Eine DAG Definition kann Task Dependencies zeigen. DAG Runs und Task Instances zeigen den tatsächlichen Execution State. Stabile APIs können Workflows, Runs und Task Results bereitstellen.

Diese Metadaten sind wesentlich für:

• Operational Lineage;
• Freshness;
• Incident Analysis;
• SLA Nachweis;
• Retry Behaviour;
• Failure Verantwortung.

Sie sollten nicht als einzige Quelle für Transformation Semantics verwendet werden. Ein Orchestrator kann wissen, dass Task B nach Task A läuft, ohne jede Column-Level Transformation innerhalb des Tasks zu verstehen.

Qlik

Qlik Applications enthalten Data Models, Fields, Dimensions, Measures, Expressions, Scripts und Consumption Context. Qlik Cloud stellt außerdem Lineage- und Impact-Analysis-Fähigkeiten für unterstützten katalogisierten Content bereit.

Coverage hängt von Deployment, Content Type und Ladeart ab. App Metadata, Script Logic und Catalog Lineage sind zusammenhängende, aber nicht identische Quellen.

Ein Metadateninventar sollte deshalb trennen:

• App Object Metadata;
• Load Script Metadata;
• Logical Data Model Metadata;
• Master Dimensions und Measures;
• Reload History;
• Catalog Lineage;
• Usage;
• Security Rules oder Berechtigungs.

Power BI

Power BI und Fabric Semantic Models können enthalten:

• Tables und Columns;
• Relationships;
• Measures;
• DAX Expressions;
• Power Query oder Mashup Expressions;
• Sensitivity Labels;
• Endorsements;
• Reports und Dashboards;
• Refresh- und Usage-Kontext.

Administrative Scanner APIs können ausgewählte Artifact- und Subartifact-Metadaten liefern, wenn Tenant Settings, Permissions und Scan Options konfiguriert sind.

Ein Warehouse-only Catalog verfehlt Semantic-Model-Logik, wenn er diese Schicht nicht erfasst.

Tableau

Die Tableau Metadata API verwendet ein GraphQL Metadata Model, um veröffentlichte Workbooks, Data Sources, Flows und zugehörige externe Assets bereitzustellen. Tableau Catalog kann je Deployment und Lizenz Lineage, Impact Analysis, Descriptions, Certifications und Data Quality Warnings ergänzen.

Die wesentliche Lücke ist der Scope: veröffentlichter Tableau Content kann detailliert indexiert werden, während Logic oder Source Context außerhalb von Tableau weiterhin andere Systeme benötigt.

Streaming-Metadaten benötigen Contracts, nicht nur Broker-Inventar

Apache Kafka kennt seine operative Topologie:

cluster
broker
topic
partition
replica
consumer group
offset
configuration
retention

Das sind wertvolle operative Metadaten.

Sie definieren allein nicht:

• fachliche Bedeutung eines Events;
• Field-Level Schema;
• Compatibility Expectations;
• Producer Verantwortung;
• erlaubte Nutzer-Nutzung;
• Klassifikation personenbezogener Daten;
• Begründung der Retention.

Eine Schema Registry ergänzt Schema Versions und Compatibility. Ein Stream Catalog oder Data-Contract-Layer kann Tags, Verantwortung und Business Metadata ergänzen. Producer Repositories können Code und Deployment Lineage hinzufügen. Consumer Groups ergänzen beobachtete Usage.

Die vollständige Streaming-Sicht wird deshalb aus mehreren nativen Quellen zusammengesetzt.

Observability liefert Evidenz, keine freigegebene Bedeutung

Observability- und Data-Quality-Systeme können kennen:

• erwartete Freshness;
• Validation Rules;
• Validation Results;
• Volume Changes;
• Schema Drift;
• Anomaly Signals;
• Incidents;
• Acknowledgements;
• betroffene Assets;
• Recovery Time.

Great Expectations erzeugt beispielsweise Validation Results aus ausgeführten Expectations. OpenLineage repräsentiert Jobs, Runs, Datasets und erweiterbare Facets, die Lineage- und Quality-Kontext transportieren können.

Diese Evidenz ist operativ wichtig. Sie sollte freigegebene Business Definitions oder Classifications nicht still überschreiben.

Ein fehlgeschlagener Uniqueness Test beweist, dass beobachtete Daten eine Expectation verletzt haben. Er beweist nicht, ob die Expectation selbst freigegeben, richtig gescoped oder weiterhin angemessen war.

Extraction Interfaces sind Teil der Architektur

Eine Fähigkeit ist praktisch nicht verfügbar, nur weil eine Product UI sie anzeigt.

Für jede Metadatenkategorie muss das unterstützte Extraction Interface dokumentiert werden.

Das Inventar muss außerdem enthalten:

authentication method
required role
scope
pagination
rate limit
retention
latency
history
incremental extraction
deletion detection
schema version
owner
failure handling

Ein Connector-Name ohne diese Eigenschaften ist kein Integrationsdesign.

Mit dem einfachsten tragfähigen Inventar nativer Metadaten starten

Die einfachste tragfähige Implementierung ist ein strukturiertes Inventar.

Schritt 1: Plattformen und Environments auflisten

Nicht nur strategische Produkte erfassen.

Einzubeziehen sind:

• Production- und Non-Production-Environments;
• Source Applications;
• Databases und Warehouses;
• Lakehouses;
• Streaming Platforms;
• Transformation Repositories;
• Orchestrators;
• BI Platforms;
• Identity Systems;
• Observability Systems;
• KI- und Model-Plattformen;
• bestehende Catalogs und Spreadsheets.

Shadow Metadata Systems sind relevant, weil sie häufig Definitionen oder Verantwortung enthalten, die keine offizielle Plattform erfasst hat.

Schritt 2: Native Metadaten identifizieren

Für jede Plattform die sieben Metadatendimensionen prüfen.

Nicht nur fragen, was in der UI verfügbar ist. Prüfen, was:

• gespeichert;
• generiert;
• beobachtbar;
• exportierbar;
• abfragbar;
• historisch aufbewahrt;
• durch Permissions geschützt

ist.

Schritt 3: Unterstützte Interfaces identifizieren

Das exakte unterstützte Interface und den Extraction Scope dokumentieren.

Beispiele:

Snowflake ACCOUNT_USAGE view
Databricks information_schema
Fabric scanner API
dbt manifest artifact
Airflow REST API
Qlik Engine or repository API
Power BI admin scan result
Tableau Metadata API
Kafka AdminClient
Schema Registry REST API
Microsoft Graph
MLflow REST or client API
OpenLineage events

Ein Beispielinterface garantiert keine vollständige Coverage. Das Inventar muss die tatsächlich zurückgegebenen Objekte dokumentieren.

Schritt 4: Source Verantwortung zuordnen

Jede Extraktion braucht zwei technische Hüte — und genau ein fachliches A:

Source metadata hat (Custodian/Steward für Bedeutung und Permissions)
Connector or integration hat (Custodian für Collection, Mapping, Monitoring)

Der Source-Hut versteht Bedeutung und Permissions. Der Integration-Hut pflegt Collection, Mapping, Monitoring und Failure Recovery. Das fachliche A für erlaubte Nutzung bleibt beim Data Owner.

Ohne beide Hüte wird der Connector langfristig zu einem verwaisten technischen Asset.

Schritt 5: Coverage und Freshness messen

Coverage sollte anhand benötigter Consumer Questions gemessen werden.

Beispiel:

Können wir jedes Production Dataset finden?
Können wir jeden Report identifizieren, der ein deprecated Field verwendet?
Können wir die freigegebene KPI-Definition abrufen?
Können wir beweisen, wer auf vertrauliche Daten zugegriffen hat?
Können wir eine Model Version zu ihrem Training Dataset zurückverfolgen?
Können wir erkennen, ob Metadaten veraltet sind?

Freshness muss explizit sein:

source observed at
collected at
last successful sync
expected interval
current staleness status

Schritt 6: Lücken identifizieren

Jede Lücke klassifizieren.

Not available in source
Available but not extractable
Extractable but not retained
Available but permission-restricted
Available but not normalized
Available but not linked across systems
Available but not approved
Available but too stale
Available but not trusted

Unterschiedliche Lücken benötigen unterschiedliche Lösungen.

Schritt 7: Integrate, Extend oder Replace entscheiden

Drei Aktionen verwenden.

Integrate, wenn die Quelle bereits autoritative Metadaten hält und ein nutzbares Interface bereitstellt.

Extend, wenn die Quelle autoritativ ist, aber ausgewählte Attribute, Historie, Workflow oder Cross-System Relationships fehlen.

Replace nur dann, wenn die bestehende Fähigkeit das erforderliche Operating Model nicht erfüllen kann und die Migrationskosten gerechtfertigt sind.

Einen Catalog zu kaufen, um eine verfügbare System View zu duplizieren, ist kein Replacement. Es ist eine zusätzliche Synchronisierungsverpflichtung.

Eine Assessment-Tabelle über den gesamten Stack verwenden

Ein praktisches Inventar kann mit diesen Spalten beginnen:

Die Werte sind Beispiele. Jede Organisation muss ihre realen Interfaces und Permissions testen.

Konkretes Beispiel: Ein Sales-Feld über den Stack verfolgen

Betrachten wir net_sales_amount.

Operative Quelle

Die Sales Application kennt:

• das ursprüngliche Amount Field;
• Order Status;
• Discount- und Tax-Flags;
• Source Currency;
• Cancellation Behaviour;
• Source Identifier;
• Process Owner.

Dies ist der beste Ursprung für Source Meaning und Process Constraints.

Streaming oder Ingestion

Kafka kann kennen:

• das Topic für Order Events;
• Partition- und Retention-Settings;
• Producer- und Nutzer-Aktivität.

Schema Registry kann kennen:

• das Event Schema;
• Field Name und Type;
• Schema Version;
• Compatibility Rules;
• registrierte Tags.

Keine dieser Quellen kennt automatisch die freigegebene Enterprise-Revenue-Definition.

Warehouse oder Lakehouse

Die Data Platform kennt:

• Physical Table und Column;
• Type und Nullability;
• Grants;
• Queries;
• Object Dependencies;
• Storage- oder Betrieb History.

Sie kann Implementierung und Nutzung innerhalb der Plattform belegen.

dbt

Das dbt Project kennt:

• Source Mapping;
• Transformation Model;
• Dependency Graph;
• Tests;
• Documentation;
• Code Revision;
• aktuelles Run Result.

Es kann erklären, wie aus dem Source Value net_sales_amount wurde.

Orchestration

Der Orchestrator kennt:

• wann die Pipeline lief;
• welcher Task fehlschlug;
• ob der Retry erfolgreich war;
• welches Environment ausgeführt wurde;
• wie lange der Run dauerte.

Dies unterstützt Freshness und Operational Accountability.

BI

Der Semantic- oder BI-Layer kann kennen:

• Net Sales;
• den freigegebenen Kennzahl-Ausdruck;
• Currency Formatting;
• Date Relationship;
• Filters;
• Report Nutzer;
• Usage.

Dies kann der einzige Ort sein, an dem der Wert in den KPI übersetzt wird, den User sehen.

Governance

Die Governance-Schicht sollte verbinden:

source field
→ event field
→ warehouse column
→ dbt model column
→ semantic measure
→ report
→ business term
→ KPI
→ owner
→ policy

Sie sollte nicht jede native Property manuell neu schreiben.

Die verbleibenden Lücken können sein:

• eine stabile Cross-System Identity;
• freigegebene Revenue Definition;
• Verantwortung und Stewardship;
• Cross-Platform Lineage;
• Richtlinie Classification;
• Metadata Quality und Freshness;
• Change-Impact Workflow.

Diese Lücken rechtfertigen zentrale Fähigkeiten. Bestehende Schemas, Runs und Expressions müssen nicht manuell neu erstellt werden.

Alternative Implementierungsmuster

Nur quellnative Metadaten

Source Systems und ihre eigenen Interfaces ohne zentrale Metadatenplattform verwenden.

Geeignet, wenn:

• der Stack klein ist;
• dasselbe Team die meisten Systeme besitzt;
• Cross-Platform Search nicht kritisch ist;
• Audit- und Impact-Analysis-Anforderungen begrenzt sind.

Warnung:

User müssen wissen, wo sie suchen müssen, und Cross-System Relationships bleiben manuell.

Lightweight Central Index

Identifier, ausgewählte Descriptions, Verantwortung, Relationships und Freshness in einen durchsuchbaren Index harvesten.

Geeignet, wenn:

• Source Metadata grundsätzlich stark sind;
• Central Discovery die Hauptlücke ist;
• Detail-Properties an der Quelle verbleiben sollen;
• die Organisation geringe Operating Complexity anstrebt.

Warnung:

Identity Resolution, Connector Monitoring und Stale-Reference Handling benötigen weiterhin Engineering.

Federated Catalog

Central Search, Vocabulary und Minimum Standards bereitstellen, während Domains detaillierte Metadaten verantworten.

Geeignet, wenn:

• mehrere Domains unterschiedliches Fachwissen besitzen;
• lokale Verantwortung real existiert;
• Cross-Domain Navigation und Richtlinie benötigt werden.

Warnung:

Federation ohne verpflichtende Contracts wird zu fragmentierter Dokumentation.

Enterprise Active-Metadata-Plattform

Breites Metadatenimporting, Lineage, Workflow, Policy, Automation und Downstream Activation verbinden.

Geeignet, wenn:

• die Landschaft groß ist;
• Metadaten Kontrollregeln auslösen müssen;
• Cross-System Impact operativ wichtig ist;
• dedizierte Platform Verantwortung vorhanden ist.

Warnung:

Eine breite Plattform erhöht Connector-, Licensing-, Mapping-, Security- und Operating-Verpflichtungen. Sie entfernt Source Verantwortung nicht.

Häufige Anti-Patterns

Kauf vor Inventar

Die Organisation wählt eine Product Category, bevor die fehlende Fähigkeit definiert wurde.

Ergebnis:

• bestehende Metadaten werden dupliziert;
• Connectors werden ohne Nutzer Questions konfiguriert;
• Platform Umfang wächst schneller als der Nutzen.

Eine UI als API behandeln

Ein Produkt zeigt Lineage oder Usage in seiner Oberfläche. Das Team nimmt deshalb an, dieselben Metadaten seien extrahierbar.

Ergebnis:

• unsupported Scraping;
• unvollständige Exports;
• fragile Integration;
• kein vertragliches Schema.

Jede Beziehung Lineage nennen

Declared Dependency, Parsed SQL, Betrieb Observation, Manual Mapping und Inferred Similarity werden als derselbe Edge gespeichert.

Ergebnis:

User können Confidence nicht bewerten und Impact nicht korrekt interpretieren.

Consumption-Layer-Logik ignorieren

Das Inventar endet bei Warehouse Tables.

Ergebnis:

Measures, Calculations, Filters und Report-Level Definitions bleiben unsichtbar.

Code in Beschreibungen kopieren

Transformation Logic wird in ein Catalog Field eingefügt.

Ergebnis:

Die Beschreibung veraltet und verliert ihre Verbindung zur ausführbaren Version.

High-Volume Operational Evidence wahllos zentralisieren

Jede Query, jedes Event, jeder Audit Record und jedes Profiling Result wird in einen allgemeinen Metadata Store kopiert.

Ergebnis:

Kosten, Sensitivität und Retention-Probleme steigen, ohne Discovery zu verbessern.

Extraction Verantwortung mit Metadata Verantwortung verwechseln

Das Catalog-Team betreibt einen Connector und wird deshalb zum Owner der importierten Metadaten erklärt.

Ergebnis:

Kein accountable Source Team korrigiert Bedeutung oder Qualität.

Permissions und Licensing ignorieren

Eine Fähigkeit wird aus einer Product Page dokumentiert, ohne Tenant, Edition, Role und API Scope zu testen.

Ergebnis:

Der Implementierungsplan setzt Metadaten voraus, die in der realen Umgebung nicht abgerufen werden können.

Entscheidungshilfe

Vor der Auswahl eines weiteren Tools müssen diese Fragen beantwortet werden.

Coverage

Welche Consumer Questions können mit bestehenden nativen Metadaten nicht beantwortet werden?

Authority

Welches System ist für jedes Metadatenattribut autoritativ?

Interface

Können die Metadaten über ein unterstütztes, automatisierbares Interface extrahiert werden?

Freshness

Wie aktuell müssen die Metadaten sein, und kann die Quelle diese Anforderung erfüllen?

History

Bewahrt die Quelle genug Historie für Audit, Impact Analysis und Incident Investigation?

Identity

Kann dasselbe Asset über Source-, Transformation-, Warehouse-, BI- und AI-Systeme aufgelöst werden?

Semantics

Wo liegen die tatsächlichen Business Definitions und Calculations?

Security

Können Metadaten gesammelt werden, ohne eingeschränkte Identities, Samples oder Audit Evidence offenzulegen?

Operations

Wer überwacht Connector Health, Schema Changes, Failed Scans und Stale Metadata?

Value

Welche fehlende Fähigkeit verändert eine reale Entscheidung, Control oder einen Workflow?

Die Tool-Entscheidung folgt aus diesen Antworten.

Zentrale Empfehlungen

1. Native Metadaten inventarisieren, bevor eine Vendor Shortlist erstellt wird.
2. Schema-, Lineage-, semantische, operative, Usage-, Security- und AI-Metadaten trennen.
3. Jedes Attribut mit einer autoritativen Quelle und accountable Verantwortung verbinden.
4. Exaktes Extraction Interface, Scope, Freshness, History und Permissions dokumentieren.
5. Transformation Repositories, Orchestration und BI einbeziehen — nicht nur Databases.
6. Declared, Parsed, Observed, Manual und Inferred Lineage unterscheiden.
7. Zentrale Plattformen für Cross-System Identity, Discovery, Vocabulary, Policy und Workflow verwenden.
8. High-Volume oder sensitive Evidenz nicht kopieren, wenn Reference oder Aggregate ausreichen.
9. Connector Operations als governte Data-Engineering-Verantwortung behandeln.
10. Zusätzliche Tools nur für gemessene Lücken und definierte Consumer Needs auswählen.

Das Ziel ist nicht, die größtmögliche Menge an Metadaten zu sammeln. Das Ziel ist, die richtige native Evidenz mit ausreichender Autorität, Freshness und Kontext für vertrauenswürdige Entscheidungen zu verbinden.

Als Nächstes: Lineage, Impact Analysis und Metadatenvererbung

Native Metadaten zeigen, was jede Plattform weiß.

Die nächste Herausforderung besteht darin, diese lokalen Beobachtungen zu belastbaren End-to-End-Beziehungen zu verbinden.

Part 10 behandelt Lineage, Impact Analysis und Metadata Propagation:

• wie Lineage aus Code, Queries, Events und Manual Mappings erfasst wird;
• wie Column-Level Relationships dargestellt werden sollten;
• wie Confidence und Provenance die Impact Analysis beeinflussen;
• welche Metadaten sicher propagiert werden können;
• wann vererbter Kontext reviewed oder überschrieben werden muss;
• wie Änderungen ein Downstream Assessment auslösen sollten.

Ein Inventar nativer Metadaten liefert die Evidenz. Lineage bestimmt, wie daraus ein verbundenes Change Model entsteht.

Hinweis zur aktuellen Verifikation

Die Produktbeispiele in diesem Artikel wurden anhand offizieller Dokumentation geprüft, die im Juli 2026 verfügbar war. Product Scope ändert sich häufig. Vor der Implementierung müssen aktuelle Editions, Tenant Settings, Retention, API Versions, Permissions, Preview Status und Object Coverage erneut geprüft werden.

Offizielle Referenzen:

• Snowflake Account Usage
• Snowflake Object Dependencies
• Databricks Information Schema
• Databricks Lineage System Tables
• Microsoft Fabric Metadata Scanning
• Microsoft Fabric OneLake Catalog
• dbt Manifest Artifact
• Qlik Lineage
• Power BI Workspace Scanner API
• Tableau Metadata API
• Apache Airflow REST API
• Apache Kafka Documentation
• MLflow Tracking
• OpenLineage Object Model