Databricks Workflows vs Apache Airflow: Was passt zu deinem Data-Stack?

Wer auf Databricks Daten verarbeitet, steht früher oder später vor der Orchestrierungsfrage: Apache Airflow (der Industriestandard) oder Databricks Workflows (nativ und integriert)?

Beide orchestrieren deine ETL-Pipelines. Aber sie haben spürbar unterschiedliche Design-Philosophien, Kostenstrukturen und Betriebslasten. Dieser Guide bringt einen direkten technischen Vergleich — ohne Marketing-Watte.

TL;DR

• Databricks Workflows: zero Setup, kein Orchestrierungs-Fee, beste Wahl bei rein Databricks-nativen Workloads.
• Apache Airflow: maximale Flexibilität, 1000+ Provider, ideal für heterogene Daten-Stacks.
• Hybrid: Airflow als Top-Level-Orchestrator, Databricks Workflows als Execution-Layer — die häufigste Production-Pattern bei größeren Teams.
• Faustregel: 90 %+ Databricks-native → Workflows. Mixed-Vendor (Snowflake + Databricks + APIs) → Airflow.

Was die Tools wirklich sind

Apache Airflow ist eine Open-Source-Workflow-Orchestrierungsplattform auf Basis von Python-DAGs (Directed Acyclic Graphs). Ursprünglich aus Airbnb, jetzt Top-Level-Apache-Projekt mit massiver Community-Adoption. Die meisten Teams betreiben es als Managed Service: MWAA (AWS), Cloud Composer (GCP) oder Astro (Astronomer).

Databricks Workflows ist der native Job-Orchestrator innerhalb der Databricks-Plattform. Er führt Notebooks, Python-Scripts, SQL-Queries, Delta-Live-Tables-Pipelines und dbt-Projekte aus — im selben Interface, das du für Development nutzt.

Feature-Vergleich

Architektur-Deep-Dive

Databricks Workflows

Ein Databricks Workflow ist ein Job mit einem oder mehreren Tasks. Tasks können sein:

• Notebooks
• Python-Scripts (Wheel oder .py)
• SQL-Queries
• Delta-Live-Tables-Pipelines
• dbt-Projekte
• Spark-Submit-Jobs

Tasks werden über Dependency-Arrows verknüpft und bilden eine DAG-ähnliche Struktur — aber definiert in JSON oder UI, nicht Python.

{
  "name": "daily_etl_pipeline",
  "tasks": [
    {
      "task_key": "ingest_raw",
      "notebook_task": {
        "notebook_path": "/Repos/data-team/etl/01_ingest"
      },
      "existing_cluster_id": "0101-123456-abc123"
    },
    {
      "task_key": "transform_silver",
      "depends_on": [{"task_key": "ingest_raw"}],
      "python_wheel_task": {
        "package_name": "my_etl",
        "entry_point": "transform_silver"
      },
      "job_cluster_key": "silver_cluster"
    }
  ],
  "job_clusters": [
    {
      "job_cluster_key": "silver_cluster",
      "new_cluster": {
        "spark_version": "14.3.x-scala2.12",
        "node_type_id": "Standard_D4ds_v5",
        "num_workers": 4
      }
    }
  ],
  "schedule": {
    "quartz_cron_expression": "0 0 2 * * ?",
    "timezone_id": "UTC"
  }
}

Deploy mit der Databricks-CLI:

databricks jobs create --json @daily_etl_pipeline.json
databricks jobs run-now --job-id 12345

Apache Airflow

Airflow-DAGs sind pures Python. Das gibt dir volle programmatische Kontrolle:

from airflow import DAG
from airflow.providers.databricks.operators.databricks import DatabricksRunNowOperator
from airflow.operators.python import BranchPythonOperator
from datetime import datetime, timedelta

default_args = {
    "owner": "data-team",
    "retries": 3,
    "retry_delay": timedelta(minutes=5),
    "email_on_failure": True,
}

with DAG(
    dag_id="daily_etl_pipeline",
    default_args=default_args,
    schedule_interval="0 2 * * *",
    start_date=datetime(2024, 1, 1),
    catchup=False,
    tags=["databricks", "etl"],
) as dag:

    ingest = DatabricksRunNowOperator(
        task_id="ingest_raw",
        databricks_conn_id="databricks_default",
        job_id=11111,
    )

    def check_data_quality(**context):
        # Dynamic branching based on row counts, schema checks, etc.
        row_count = context["ti"].xcom_pull(task_ids="ingest_raw")
        return "transform_silver" if row_count > 0 else "alert_empty_load"

    branch = BranchPythonOperator(
        task_id="check_quality",
        python_callable=check_data_quality,
    )

    transform = DatabricksRunNowOperator(
        task_id="transform_silver",
        databricks_conn_id="databricks_default",
        job_id=22222,
    )

    ingest >> branch >> transform

Kostenvergleich

Databricks Workflows:

• Kein Orchestrierungs-Fee — du zahlst nur das Compute (DBUs), das Tasks während ihrer Laufzeit verbrauchen.
• Job-Cluster spinnen pro Run hoch und runter → Kosten sind direkt an den Workload gekoppelt.
• Für Databricks-native Pipelines fast immer die günstigste Option.

Apache Airflow (MWAA-Beispiel):

• MWAA Small Environment: ~$300/Monat Base-Kosten, unabhängig von der Nutzung.
• Plus Worker-Compute für Task-Execution.
• Plus Databricks-DBUs, wenn du Databricks-Operatoren laufen lässt.

Faustregel: Wenn 90 %+ deiner Workloads Databricks-nativ sind, ist Workflows fast immer günstiger. Wenn du eine Mischung aus Databricks, Redshift, Snowflake, APIs und Custom-Python orchestrierst, kann Airflow trotz Base-Kosten günstiger sein als der operative Aufwand mehrerer nativer Scheduler.

Wann Databricks Workflows

Workflows wählen, wenn:

• Alle (oder die meisten) Orchestrierungsziele Databricks-Jobs sind.
• Du Null Infrastruktur-Overhead willst.
• Du bereits Delta Live Tables oder dbt-on-Databricks nutzt.
• Dein Team UI-getriebenes Workflow-Design bevorzugt.
• Du tight Integration mit Unity-Catalog-Lineage brauchst.
• Schnelle Iteration zählt (kein DAG-Deployment-Cycle).

Wann Apache Airflow

Airflow wählen, wenn:

• Du über mehrere Plattformen orchestrierst (Databricks + Snowflake + S3 + APIs).
• Du komplexes Branching, Dynamic Task Generation oder XCom-basiertes State-Sharing brauchst.
• Dein Team Python-native ist und Code-as-Infrastructure bevorzugt.
• Du Airflows extensives Provider-Ökosystem brauchst (1000+ Integrationen).
• Cross-Organizational-DAG-Sharing wichtig ist.
• Du SLA-Monitoring und fortgeschrittenes Alerting eingebaut in den Scheduler willst.

Die Hybrid-Architektur

Viele Production-Teams nutzen beide:

• Airflow als Top-Level-Orchestrator: Scheduling, externe Trigger, Cross-System-Dependencies, Alerting.
• Databricks Workflows als Execution-Layer: führt die eigentlichen Spark-/Notebook-Jobs aus, die von Airflow getriggert werden.

# Airflow kicks off a Databricks Workflow and waits for completion
from airflow.providers.databricks.operators.databricks import DatabricksRunNowOperator

run_etl = DatabricksRunNowOperator(
    task_id="run_databricks_etl",
    databricks_conn_id="databricks_default",
    job_id=99999,  # A complex multi-task Databricks Workflow
    wait_for_termination=True,
)

Diese Pattern gibt dir Airflows Orchestrierungsflexibilität, ohne dass du Databricks-Workflows-natives Cluster-Management und Lineage-Tracking aufgibst.

Observability-Vergleich

Migration-Pfad

Wenn du von Airflow zu Workflows migrierst:

# Export existing Airflow DAG schedules and dependencies
# Map each DatabricksSubmitRunOperator → Databricks Workflow task
# Recreate branching logic as Databricks conditional tasks
# Test in dev workspace before cutover

# Useful CLI for bulk job creation from YAML definitions
databricks bundle deploy --target prod

Das Databricks-Asset-Bundles-(DAB-)Framework ist der moderne Weg, Workflows als Code zu definieren — Git-basiertes Versioning ähnlich wie Airflows DAG-as-Code-Approach.

FAQ

Kann ich Airflow lokal als Open Source betreiben, oder muss ich Managed nehmen?

Du kannst Airflow self-hosten — Docker-Compose oder Kubernetes. Realistisch wirst du aber 0,5–1 FTE für Betrieb (Upgrades, Worker-Skalierung, Auth, Monitoring) brauchen. Bei Teams unter 10 Data Engineers ist MWAA/Composer/Astro fast immer billiger als Self-Hosting.

Lohnt sich Airflow nur für Databricks-Jobs?

Selten. Wenn 100 % deiner Workloads in Databricks laufen, gewinnt Workflows. Airflow rentiert sich erst, wenn du Cross-Vendor-Dependencies hast — Snowflake-Refresh nach Databricks-Ingest, externe APIs anstoßen, Kubernetes-Jobs orchestrieren.

Wie sieht Cross-Workspace-Orchestrierung bei Workflows aus?

Limitiert. Workflows orchestriert primär innerhalb eines Workspace. Über REST-API-Calls kannst du Jobs in anderen Workspaces triggern, aber Dependency-Tracking und Lineage funktionieren nicht über Workspace-Grenzen. Wenn du mehrere Workspaces ernsthaft koordinieren musst, hat Airflow hier einen klaren Vorteil.

Wie ist die DACH-Datenresidenz bei den Managed-Services?

MWAA läuft in der Region deines AWS-Accounts — Frankfurt verfügbar. Cloud Composer ebenfalls EU-Region wählbar. Astro Cloud hat EU-Region (Frankfurt). Databricks Workflows läuft in der Workspace-Region — Azure Frankfurt oder AWS eu-central-1 sind die typischen DACH-Wahlen.

Fazit

Kein Tool gewinnt universell. Databricks Workflows ist die richtige Wahl für Teams, die voll auf das Databricks-Lakehouse setzen — einfacher, günstiger, tief integriert. Airflow ist die richtige Wahl, wenn du ein heterogenes Daten-Ökosystem orchestrierst und maximale Flexibilität brauchst.

Für die meisten Teams, die ein modernes Data Lakehouse auf Databricks bauen: starte mit Workflows. Addiere Airflow erst, wenn du an Workflows' Limits stößt.

Stand: Mai 2026. Databricks und Apache Airflow entwickeln sich schnell — verifiziere kritische Annahmen direkt in der jeweiligen Dokumentation.