Evaluierung Data Ingest nach PoC

Zielsetzung

Nachdem anfänglich in "Evaluierung möglicher Ingest Komponenten" bewertet wurde, welche ETL-Orchestrierungstool in einem PoC betrachten werden sollten, setzt sich diese Dokumentation zum Ziel eine fundierte Bewertung der beiden ETL-Orchestration-Tools Dagster und Apache Airflow im Hinblick auf ihre Eignung für die Datenfabrik. Sie soll zu einer Architekturentscheidung führen.

Evaluierungskriterien

Die Bewertung in %-Zahl erfolgt nach subjektiver Einschätzung und dem Handling im PoC-Test.

Mandantentrennung

Kriterium Dagster Dagster Kommentar Airflow Airflow Kommentar
Unterstützung mehrerer Projekte (Mandantenfähigkeit) 60% Beide Tools Multimandantenfähig; D: Eigene Code Location mit eigenem Image / UI via Self-Host aber nicht multimandantenfähig 80% Multi-DAG-Folder Ansätze notwendig / höhere Aufwand, bessere UI RBAC
Isolation von Ressourcen, Daten, Berechtigungen 100% Eigenes Image und Container-Runtime 90% Gesammeltes Image default, dadurch aber Steuerung. KubernetesExecutor erfüllt Kriterium, trotzdem fraglich, ob andere Execturoren performanter wären.
Wenn Fokus auf maximale Seperation sogar multi-namespace möglich: https://airflowsummit.org/sessions/2023/better-support-for-using-multiple-namespaces-with-kubernetesexecutor/
  • Dagster = 80% Erfüllung der Kategorie
  • Airflow = 86 % Erfüllung der Kategorie

Deploymentstrategie

Kriterium Dagster Dagster Kommentar Airflow Airflow Kommentar
GitOps & CI/CD 100% miteinander vergleichbar, Helm Chart verfügbar 100% miteinander vergleichbar, Helm Chart verfügbar
Mono-Repo vs. Multi-Repo 100% Multi-Repo Ansatz offiziell dokumentiert: https://docs.dagster.io/deployment/dagster-plus/management/managing-multiple-projects-and-teams 100% Beide Strategien technisch möglich, Mono-Repo in der Community verbreitet.

Ansatz mit Multi-Repo und S3 identifiziert: https://medium.com/apache-airflow/what-we-learned-after-running-airflow-on-kubernetes-for-2-years-0537b157acfd
Lokale Entwicklung & Tests 90% Lokaler Start über dagster dev

Bei beiden Tools wäre eine hosted Dev Umgebung trotzdem gut, um die Vergleichbarkeit zu gewährleisten		 90% airflow standalone und offizielle Docker-Compose-Umgebung verfügbar, lokale Tests mit Einschränkungen möglich (anderer Executor)
Flexibilität der Konfiguration: Komponente "wächst" mit Platform 30% Wesentliche Enterprise-Funktionen fehlen im OSS 80% Modular erweiterbar, Plugin-System, hohe Verbreitung, aber auch hohe Hürde die breite Konfigurationsmöglickeiten zu optimieren
Rollback-Strategien 50% In beiden Fällen abhängig von Design der Pipelines (Idempotenz, Checkpoints,etc.)

D. bietet Optionen wie "ReexecutionOptions"

 50% Subset eines DAGs via UI oder CLI ausführen (z.B. airflow backfill)
  • Dagster = 74% Erfüllung der Kategorie
  • Airflow = 84% Erfüllung der Kategorie

Self-Service vs. Operator-Abhängigkeit

Kriterium Dagster Dagster Kommentar Airflow Airflow Kommentar
UI für Entwickler 80% Moderne UI, aber Entwickler-zentriert 80% Mit Airflow 3 auch moderne UI, aber Entwickler zentriert
Autonomie von Entwicklungsteams 50% Schreiben eigene Code Location mit eigenem Image. Secret Management muss mit Operator abgestimmt werden 50% Default dediziertes Image, aber mit Prozessen können Entw. Teams eigenständig testen. Auch hier Bedarf es Abstimmung im Bereich Secret Management mit Operator
Operator-Eingriffe 40% Insb. Secret Mgmt, aber auch UI nur als Full-Admin in OSS aufrufbar daher ggf. Vertreter für Dev Teams (kein IAM möglich) 70% Insb. Secret Mgmt und IAM Regeln für Webserver Zugriffe
GitLab-Integration & Berechtigungen 40% CI/CD-Skripte und Deploy-Pipelines mit GitLab CI möglich, aber Rollentrennung nur begrenzt 80% GitLab + Helm gut integrierbar, RBAC-Funktionalität über Airflow Webserver gegeben
  • Dagster = 53% Erfüllung der Kategorie
  • Airflow = 70% Erfüllung der Kategorie

Authentifizierung & Autorisierung

Kriterium Dagster Dagster Kommentar Airflow Airflow Kommentar
SSO (Keycloak) Integration 10% Keine native OIDC-Unterstützung im OSS; Workaround über Reverse Proxy nötig 100% Native Integration über Flask-AppBuilder, OIDC, OAuth2, Keycloak möglich
Rollenbasierte Zugriffskontrolle (RBAC) 0% Kein echtes RBAC im OSS, nur teamorientierte Separierung über Code-Strukturen 100% Volles RBAC über Web UI konfigurierbar, rollen- & permissionsbasiert
  • Dagster = 5% Erfüllung der Kategorie
  • Airflow = 100% Erfüllung der Kategorie

Entscheidungsgrundlage

Kriterium Dagster Airflow
Mandantentrennung 80% 86%
Deploymentstrategie 74% 84%
Self-Service-Fähigkeit 53% 70%
Auth 5% 100%
Gesamtbewertung
bei gleicher Gewichtung		 53% 85%

Kritische Bewertung der Wahl des ETL-Orchestrierungstools

Im Rahmen der Datenfabrik-Komponenten agieren Dagster und Airflow formal im „Ingest-Layer“, bieten jedoch weitreichendere Funktionen als reines Einlesen. Wichtig ist dabei, zwischen Ingest und Extract zu unterscheiden:

  • Extract wäre eine Aufgabe, die von beiden Tools nur verwaltet wird.

  • Verschiedene Extraktionsmodi erfordern jeweils eigene Toolchains. Ein „One-size-fits-all“-Ansatz erscheint daher wenig zielführend.

  • Apache Airflow stellt aufgrund seiner Flexibilität und seines modularen Designs einen bewährten Einstiegspunkt in die ETL-Orchestrierung dar. Verschiedene moderne Extract Optionen sind hier mit Plugins und Python einbindbar.

Die Kernfrage lautet, welche Fähigkeiten unsere Datenfabrik abdecken soll – abhängig von den jeweiligen Sponsoren und Fokus-Use-Cases. Wir gehen aktuell von drei Haupt-Extract-Szenarien aus:

  1. Real-Source-Extraktion
    Direkter Zugriff auf eine Quell-Datenbank mit halbwegs normalisierten Daten.

  2. Non-standardized Exports
    Teilweise aggregierte Daten, unterschiedlich formatiert je nach Quelle (z. B. CSV, JSON, XML etc.).

  3. Unstructured Data
    Klassische Dokumenten- und Textverarbeitung (z. B. PDFs, E-Mails, Freitext).

Alle genannten Szenarien lassen sich strategisch mit Apache Airflow abbilden – dank seiner breiten Integrationsmöglichkeiten und der ausgereiften Community.

Bewertung & Ableitungen des Ergebnisses

Die Bewertung aus dem PoC bestätigt, dass Apache Airflow in einer Self-Hosted-Umgebung aktuell die bessere Wahl ist. Auf Basis der gewonnenen Erkenntnisse sollten im nächsten Schritt folgende Themen tiefer analysiert und entschieden werden:

  1. Helm-Chart Auswahl
    Welches Chart (offiziell vs. Bitnami) bietet die besten Upgrade- und Rollback-Mechanismen sowie die nötigen Konfigurationsoptionen (Secrets, Ingress, Ressourcen-Limits)?

  2. Executor-Strategie
    Entscheidung zwischen KubernetesExecutor oder CeleryExecutor – jeweils im Hinblick auf Skalierbarkeit, Isolation, Betriebskomplexität und Performance

  3. Isolationstiefe & Multi-Tenancy
    Definition, wie stark Tasks, Datenvolumes und Secrets pro Team oder Projekt getrennt werden müssen (z. B. Namespaces, Pod-Security-Policies, Netzwerk-Policies).

  4. DAG- und Teamprozesse
    Workflow für DAG-Entwicklung, Testing und Deployment:

    • Mono- vs. Multi-Repo
    • CI/CD-Pipelines und Quality Gates
    • Vorgehen bei DAG-Änderungen (Review, Versionierung, Rollbacks)

  5. Daten-Ingest & -Harmonisierung
    Validierung, wie Airflow bei unterschiedlichen Extraktionsmodi (aggregierte vs. rohe Quelldaten) Datenharmonisierung, Schema-Evolution und anschließende Konsolidierung effizient unterstützt, da dies eine wesentliche Aufgabe der Datenfabrik ist.