Task Chain (Databricks Jobs): Definition und Abgrenzung

Eine Task Chain ist eine Kette einzelner Arbeitsschritte (Tasks) in einem Databricks-Job, die in einer festen Reihenfolge ablaufen. Die Reihenfolge wird als Abhängigkeitsgraph modelliert (gerichteter azyklischer Graph, kurz DAG, also ein Ablaufplan ohne Schleifen). Jeder Task hat definierte Vorgänger, optionale Bedingungen (verzweigen mit If/Else, Schleifen mit For Each) und Wiederholungsregeln (Retry bei Fehlern). Ein Task startet erst, wenn seine Vorgänger den geforderten Status erreicht haben.

Was ist eine Task Chain?

Eine Task Chain ist die Ablaufstruktur innerhalb eines Databricks-Jobs. Der Begriff stammt aus der Databricks-Job- und Workflow-Welt (heute [Lakeflow Jobs](https://docs.databricks.com/aws/en/jobs), früher Databricks Workflows) und beschreibt die Kette von Arbeitsschritten, die die Job-Engine (der interne Ablauf-Planer von Databricks) als Abhängigkeitsgraph plant und ausführt. Jeder Task ist eine konkrete Ausführungseinheit: ein Notebook, ein JAR (kompiliertes Java-Paket), ein Python-Skript, ein SQL-Statement, eine Declarative Pipeline (deklarative Tabellen-Pipeline), ein dbt-Task (SQL-Transformationsframework) oder ein Run-Job-Task (der einen anderen Databricks-Job startet). Die Abhängigkeiten zwischen den Tasks werden über das Feld depends_on explizit deklariert; die Engine startet einen Task, sobald alle seine Vorgänger den erwarteten Zustand erreicht haben, und führt unabhängige Zweige parallel aus.

Zur Steuerung stehen mehrere Mechanismen bereit. run_if-Bedingungen (all_success, all_done, at_least_one_success, none_failed, all_failed) legen fest, unter welchem Status der Vorgänger ein Task startet. If/Else-Tasks verzweigen den Graphen über Task-Values, die Vorgänger-Tasks setzen. For-Each-Tasks iterieren über eine Liste und starten für jeden Eintrag denselben Sub-Task, wahlweise sequenziell oder parallel. Pro Task lassen sich Retry-Policy, Timeout und Benachrichtigungen konfigurieren. Task-Values dienen als leichtes Datenübergabe-Vehikel zwischen Tasks, wenn kein Zwischenschritt über eine Tabelle nötig ist.

Definiert wird eine Task Chain über die Databricks-UI, in YAML über [Databricks Asset Bundles](https://docs.databricks.com/aws/en/dev-tools/bundles/), über die REST-API, Terraform oder das Databricks-SDK. Der Bundle-Weg ist die produktionsreife Form: Die Task Chain wird versionierbar, reviewbar und über Umgebungen (Dev, Staging, Prod) deploybar wie Anwendungscode. Historisch gab es vor 2021 nur Single-Task-Jobs; die Einführung der Multi-Task Jobs 2021 hat die Task-Kette in Databricks etabliert. Mit dem Lakeflow-Rebranding (2024/2025) und späteren Databricks-Runtime-Versionen sind For Each, Task Values und kombinierte Run-If-Regeln Standard.

Als sekundäre Bedeutung wird der Begriff „Task Chain" im LLM-Umfeld (unter anderem in LangChain) für die sequenzielle Verkettung von LLM-Aufrufen verwendet, meist synonym mit [Prompt Chaining](/insights/glossar/prompt-chaining/). Diese Verwendung ist im DACH-B2B-Umfeld deutlich seltener und wird sprachlich häufig durch „Chain" oder „Prompt Chain" ersetzt. Die folgenden Abschnitte beziehen sich auf den Databricks-Kontext.

Abgrenzung zu Declarative Pipelines, Notebook-Pipeline, Airflow und Dagster

Der Begriff Task Chain wird häufig mit vier verwandten Konzepten vermengt, die dieselbe Grundaufgabe (Datenpipelines koordiniert ablaufen lassen) auf unterschiedlichen Ebenen lösen.

Konzept	Abgrenzung zur Task Chain
Delta Live Tables / Spark Declarative Pipelines	Deklarativ und datenzentriert. Beschrieben werden Zieltabellen, Abhängigkeiten und Datenqualitätsregeln; die Engine erzeugt den Ausführungsgraphen selbst. Eine Task Chain ist dagegen imperativ und task-zentriert: Jede Ausführungseinheit wird explizit deklariert. Beide Modelle werden oft kombiniert; eine Task Chain kann eine Declarative Pipeline als einen ihrer Tasks starten.
Notebook-Pipeline (%run, dbutils.notebook.run)	Die Kette wird im Notebook-Code selbst orchestriert. Es gibt kein DAG-Bild, keine parallele Ausführung out of the box, kein Retry-Modell auf Task-Ebene und kein separates Monitoring. Task Chains sind die produktionsreife Umsetzung desselben Musters.
Apache Airflow	Externer Orchestrator, definiert DAGs in Python außerhalb von Databricks. Ruft Databricks-Jobs typischerweise über den DatabricksRunNowOperator auf. Eine Task Chain ist die interne Ablaufstruktur eines dieser Databricks-Jobs; Airflow sitzt als Klammer über heterogenen Systemen.
Dagster	Framework-basierter Python-Orchestrator mit Software-defined Assets, extern zu Databricks. Anderer konzeptioneller Ansatz (Assets statt Tasks) und andere Position im Stack: Klammer über Systemen statt Ablaufsteuerung innerhalb eines Jobs.

Die zentrale Verwechslung ist Task Chain versus Declarative Pipeline. Beide erzeugen einen Abhängigkeitsgraphen, das Modellierungs-Niveau ist aber ein anderes: Task Chains modellieren, welche Ausführungseinheiten in welcher Reihenfolge laufen; Declarative Pipelines modellieren, welche Tabellen aus welchen Quellen entstehen und welche Qualitätsregeln gelten. Beide Modelle stehen nicht in Konkurrenz.

Beispiel: Medaillon-Pipeline als Task Chain

Ein typischer Einsatz ist eine Medaillon-Pipeline, die vollständig als Task Chain in einem Lakeflow-Job modelliert ist. Task 1 lädt Rohdaten aus einem S3-Bucket in ein Bronze-Delta-Layer (Auto Loader in einem Notebook). Task 2 transformiert Bronze zu Silver (SQL-Task). Task 3 aggregiert Silver zu Gold (Notebook). Task 4 startet eine dbt-Testsuite. Task 5 schickt eine Slack-Benachrichtigung und läuft mit run_if: all_done, damit auch Fehler gemeldet werden. Die Engine löst die Abhängigkeiten auf und startet unabhängige Zweige parallel.

yaml

resources:
  jobs:
    daily_sales_pipeline:
      tasks:
        - task_key: ingest
          notebook_task:
            notebook_path: /Repos/prod/ingest_sales
        - task_key: transform_silver
          depends_on:
            - task_key: ingest
          sql_task:
            file:
              path: /Repos/prod/silver_sales.sql
          max_retries: 2
        - task_key: aggregate_gold
          depends_on:
            - task_key: transform_silver
          notebook_task:
            notebook_path: /Repos/prod/gold_sales
        - task_key: dbt_tests
          depends_on:
            - task_key: aggregate_gold
          dbt_task:
            project_directory: /Repos/prod/dbt_sales
            commands: ["dbt test"]
        - task_key: notify
          depends_on:
            - task_key: dbt_tests
          run_if: all_done
          notebook_task:
            notebook_path: /Repos/prod/slack_notify

Diese YAML-Definition liegt in einem Databricks Asset Bundle. Deployment über databricks bundle deploy erzeugt oder aktualisiert den Job in der Zielumgebung. Für dynamische Fälle wie Ingestion pro Ländercode ersetzt ein For-Each-Task die feste Task-Liste durch eine Iteration über eine Werte-Liste, die ein Vorgänger-Task als Task-Value bereitstellt.