Metadata Ingestion (Catalog)

Kurzzusammenfassung

• Diese Seite beschreibt Metadata Ingestion für den Catalog (OpenMetadata), nicht die operative Primärausführung der ELT-Pipeline.
• Kernziel ist die Registrierung von Datasets, Contracts, Ownern, Entitlements und Lineage.
• BPMN-Leitpfad: Task Extract Metadata → Gateway Mandatory metadata complete? → Outcome Catalog entity published.
• Die operative ELT-Ausführung ist auf Data Pipeline (ELT + Validierung) dokumentiert.

Ziel

Aus erfolgreichen Pipeline-Runs resultieren konsistente Catalog-Events, sodass Datenobjekte im OpenMetadata-Katalog mit Pflichtmetadaten, Ownership und Entitlements governance-fähig publiziert werden können.

Quelltypen und Katalogisierungsfrequenz

Quelltyp	Typische Systeme	Ingestion-Frequenz	SLA für Katalogsichtbarkeit
OLTP/Relationale DB	PostgreSQL, SQL Server, Oracle	stündlich (Schema), täglich (Profiling)	p95 ≤ 10 min nach erfolgreichem Run
Data Warehouse/Lakehouse	Snowflake, BigQuery, Databricks Unity Catalog	alle 30 min (Schema + Lineage), täglich (Statistiken)	p95 ≤ 15 min
Event/Streaming	Kafka Topics, CDC Streams	alle 15 min Snapshot + täglich Vollabgleich	p95 ≤ 20 min
Files/Objektspeicher	S3/ADLS/Blob (Parquet, CSV)	pro Landing-Run + täglicher Full Scan	p95 ≤ 20 min
BI/ML-Artefakte	dbt, MLflow, Feature Store	pro Deployment/Promotion Event	p95 ≤ 10 min

Technische Metadaten pro Catalog-Run

Jeder Run erzeugt mindestens folgende technische Metadaten:

• run_id, pipeline_id, source_system, connector_version
• ingestion_started_at, ingestion_finished_at, status, error_class
• schema_hash, record_count (falls verfügbar), last_successful_run
• lineage_edges_detected, dq_checks_triggered, policy_tags_applied

Minimale Pflichtfelder pro OpenMetadata-Entity

OpenMetadata Entity	Pflichtfelder (Minimum)	Gate-Relevanz
Table	name, service, databaseSchema, columns[], owner, tags.classification, description, retention_policy, allowed_use, dq_status_initial	Gate A (Data & Purpose), Gate B (Pilot Ready)
Topic	name, service, schemaType, messageSchema, owner, retention, contains_pii, purpose, freshness_sla	Gate A, Gate B
Dashboard	name, service, owner, linked_datasets[], criticality, access_policy	Gate A, Gate C
Pipeline	name, service, tasks, upstream_entities[], downstream_entities[], owner, schedule	Gate B, Gate C
ML Model	name, owner, training_dataset_ref, feature_set_ref, model_stage, lineage_status, risk_class	Gate C

Ablauf (Catalog Registration)

BPMN-Schritt	Mechanik (Task/Gateway/Outcome)	Artefakte & Verantwortlich
Task: Extract Metadata	Scanner liest Schema, Partitionierung, Refresh-Zeit, Source-System aus Pipeline-Resultaten und Quelladaptern	Artefakt: metadata_raw.json; Responsible: Platform Team
Task: Enrich Business Context	Domain, Datenklasse, Owner, Steward, Purpose setzen	Artefakt: dataset_profile; Responsible: Data Steward
Gateway: Mandatory metadata complete?	Prüft entity-spezifische Pflichtfelder und technische Run-Metadaten	Nein: Status draft + Ticket; Accountable: Data Owner
Outcome: Catalog entity published	Versionierter OpenMetadata-Eintrag mit Audit-Event und referenzierter Pipeline-Run-ID	Artefakt: Entity + Change-Event

Catalog-spezifische Kontrollen

Governance- und Risiko-Aspekte

• Pflicht-Policies: Access, Retention, Allowed Use, ggf. Restriktion für research-only.
• Für marktkritische Daten (z. B. EOD-Preisfeed) ist Steward-Vertretung verpflichtend.
• Jeder Ingestion-Lauf ist über run_id auf Quellsystem und Incident rückverfolgbar.

Messbare Akzeptanzkriterien

Kriterium	Grenzwert	Verantwortlich	Eskalation
Gate-A-Pflichtfelder vollständig	100 % pro Entity	Data Steward	sofortiger Publish-Stop
Sichtbarkeit neuer Assets nach technischem Lauf	p95 ≤ 10 min	Platform Team	> 30 min: P2 Incident
Fehlgeschlagene Ingestion-Runs	< 2 % pro Tag	Platform Ops	≥ 5 %: P1 Incident

Entscheidung

• Entity ist technisch + fachlich vollständig (Owner/Policy/Purpose/DQ-Status).
• Gateway-Entscheidung ist im Audit-Log dokumentiert.
• Bei Blockierung existiert Ticket mit Owner und ETA.

Operative ELT-Ausführung siehe /docs/orchestration-prefect/data-pipeline.

Glossar-Begriffe

Diese Seite nutzt die kanonischen Begriffe Data Pipeline, Data Product, DQ und OpenMetadata.

Primärseite für ELT-Ausführung

Die operative Ausführung von CallActivity_DataPipeline (Extract, Load Raw, Transform, Validate, Output Contract) ist auf Data Pipeline (ELT + Validierung) dokumentiert. Diese Seite fokussiert auf die Katalogregistrierung der resultierenden Metadaten und Catalog-Events.

BPMN-Kontext

• IDs: CallActivity_DataPipeline
• Input-Bezug: Pipeline-Run-Artefakte, Schema-/Lineage-Informationen und Governance-Metadaten.
• Entscheidungsbezug: Prüfung von Pflichtmetadaten, Ownership, Entitlements und Publish-Freigabe im Catalog.
• Output-Bezug: Publizierte OpenMetadata-Entities und Catalog-Events für nachgelagerte Governance- und Discovery-Prozesse.