Pipelines und Orchestrierung

Begriffe vor dem Lesen

• RBAC — Role-Based Access Kontrollregel: Zugriff über Rollen wie Steward, Analyst, Admin oder Auditor.

Herausforderung

Ohne Pipeline-Metadaten fehlen Run-Status und Job-Abhängigkeiten im Katalog. Teams suchen Incidents in der Airflow-UI und Lineage getrennt in OpenMetadata — ohne gemeinsame Asset-Identität. Umgekehrt wird der Orchestrator zum Pseudo-Katalog: tausende DAGs ohne fachlichen Owner und ohne Link zu Tabellen.

Ansatz

Orchestrierung als Pipeline-Service anbinden: DAGs/Jobs und Runs harvesten, Lineage zu Datasets verbinden, Orchestrator aber nicht zum fachlichen Katalog machen. Scheduling-Autorität bleibt beim Orchestrator.

Pipeline-Service → Jobs/Runs/Lineage-Facets
→ verknüpft mit Warehouse- und dbt-Assets
→ Incident-Fragen mit Run-Evidenz

Best Practices

Nur DAGs des Pilotprojekt-Flows

„Alle Folders“ erzeugt Job-Inventar ohne Incident-Nutzen. Scope über Tags/Folder (domain:sales, om:pilot) und archivierte DAGs ausschließen. Lieber enger Scope mit ehrlichen Lineage-Lücken als Pseudo-Vollständigkeit.

Environment im Service-Namen

Wie beim Warehouse: airflow-prod vs airflow-dev. Dev-DAGs im Prod-Service vermischen Run-Evidenz und Owner. Copy-Config ohne Rename ist die häufigste Ursache.

Run-Evidenz für Incidents — nicht nur Pretty Graphs

Gute Pipeline-Metadaten beantworten in unter einer Minute: Welcher Job baute den Mart zuletzt erfolgreich? Welche Downstream-Tabellen? Wer owned DAG und Tabelle? Wenn die Antwort nur in der Airflow-UI liegt, fehlt die Verknüpfung; wenn nur ein Graph ohne Zeiten da ist, fehlen Runs/Facets — beides im Decision Record nachziehen.

Owner = DAG-Owner, nicht nur Airflow-Admin

Platform owned die Orchestrator-Betrieb; die Domain owned die Job-Logik und Source-Abhängigkeiten. Eskalation bei fachlich kritischen Failures muss beim DAG-Owner landen — analog zu Warehouse-Credentials.

Freshness auch für Pipeline-Metadaten

Ein stale DAG-Inventar ist so riskant wie ein stale Schema: Incidents treffen auf veraltete Abhängigkeiten. Stale-Alert und SLO wie bei Database-Services; fehlende OpenLineage-Facets als bekannte Grenze dokumentieren, sonst glauben Consumer an vollständige Impact Analysis.

Stolperfallen

Orchestrator vor Warehouse. Jobs ohne Dataset-Links — Inventar ohne Nutzen.

OM ersetzt Scheduling. Retry, SLA und Trigger bleiben im Orchestrator.

Nur OM-Ingestion alerten, nicht den kritischen Job-Failure im Orchestrator — beides brauchen.

Halb angebundene Facets. Ohne Dokumentation erzeugen sie falsche Sicherheit.

Alle Dev-DAGs in Prod. Environment-Diff vor Go-Live.

Vorgehen

1. Orchestrator-Instanz und Environment benennen.
2. Scope: nur DAGs des Pilotprojekt-Flows.
3. OpenMetadata Pipeline-Connector konfigurieren.
4. Verknüpfung zu Warehouse-Tabellen und ggf. dbt-Models prüfen.
5. Decision Record: SLO, Owner, Secret, welche Facets erwartet werden.

Troubleshooting

• Jobs sichtbar, keine Lineage: Hooks/OpenLineage/Dataset-URIs prüfen; Warehouse-FQNs matchen.
• Auth zur Airflow-API: Service-Account, RBAC, Netzwerk — getrennt vom UI-Login.
• Rauschen: Tag-/Folder-Filter; archivierte DAGs ausschließen.

Reihenfolge und Abhängigkeiten

Pipeline-Service nach Warehouse (und oft nach dbt) für denselben Flow. Jobs ohne Dataset-Links sind Inventar ohne Incident-Nutzen. Facets und OpenLineage sind optional — aber fehlende Facets müssen als bekannte Grenze im Decision Record stehen, sonst glauben Consumer an vollständige Impact Analysis. Lieber einen engen DAG-Scope mit ehrlichen Lücken als „alle Folder“ mit Pseudo-Vollständigkeit.

Was Pipeline-Metadaten leisten sollen

Gute Pipeline-Ingestion beantwortet in unter einer Minute:

• Welcher Job hat den Sales-Auswertungstabelle zuletzt erfolgreich gebaut?
• Welche Downstream-Tabellen hängen daran?
• Wer owned den DAG — und wer owned die Tabelle?

Wenn die Antwort weiterhin nur in der Airflow-UI liegt, fehlt Verknüpfung oder Scope. Wenn die Antwort nur ein Graph ohne Run-Zeiten ist, fehlen Facets oder Run-Metadatenimport — beides im Decision Record nachziehen.

Hilfe beim Umsetzen

DAG-Tags om:pilot / domain:… als Filter. Incident-Checkliste: Job, letzter Erfolg, Downstream in OM, Owner. OpenMetadata-Ingestions-Generator für Pipeline-Service-Starter. Fehlende OpenLineage-Facets als Grenze im Record — nicht als stillschweigende Vollständigkeit.

Checkliste

• Ist der Orchestrator-Umfang auf das Pilotprojekt begrenzt?
• Sind kritische Jobs mit Owner und Upstream/Downstream sichtbar?
• Wird Run-Evidenz für Incident-Fragen genutzt?
• Bleibt Scheduling-Autorität beim Orchestrator?
• Ist klar, welche Lineage-Facets nicht geliefert werden?

Artefakt

Pipeline Connector Decision Record: Instanz, DAG-Scope, SLO, Owner, Secret, Facet-Erwartungen.

Tools

• OpenMetadata-Ingestions-Generator — Pipeline-Service-Config und Job-Umfang.
• OpenMetadata Connectors — Pipeline-Connectoren / OpenLineage-Hinweise.
• Airflow (o. ä.) + Secret Store (intern) — API-Zugriff und DAG-Filter.

Ressourcen

• OpenMetadata Pipeline connectors