Lakeflow Jobs

Lakeflow Jobs ist der eingebaute Ablaufplaner (Orchestrator) der Databricks-Plattform. Es startet mehrstufige Datenprozesse in einer festgelegten Reihenfolge: welche Aufgabe (Task) läuft zuerst, welche danach, welche parallel und welche nur, wenn eine vorherige Aufgabe erfolgreich war. Die früheren Produktnamen Databricks Jobs und Databricks Workflows bezeichnen dasselbe Produkt.

Was ist Lakeflow Jobs?

Lakeflow Jobs gehört zur Databricks-Lakeflow-Familie, einem Bündel aus vier Bausteinen für die Datenverarbeitung: Datenanlieferung aus Quellsystemen (Lakeflow Connect), Datenaufbereitung über deklarative Regeln (Lakeflow Declarative Pipelines), eine grafische Oberfläche zum Zusammenklicken von Abläufen (Lakeflow Designer) und die Ablaufsteuerung über Lakeflow Jobs. Lakeflow Jobs übernimmt darin die Rolle des Taktgebers: Es legt fest, welche Schritte in welcher Reihenfolge, auf welchem Rechen-Cluster und unter welcher Bedingung laufen.

Ein Lakeflow Job ist ein gerichteter azyklischer Graph aus Tasks mit depends_on-Beziehungen. Jeder Task ist typisiert (Notebook, Python Script, JAR, SQL Query, Dashboard, Alert, File, Pipeline, dbt, Model Serving Job, Run Job, If/Else Condition, For Each), läuft auf einem definierten Compute und kann eigene Parameter, Retries, Timeouts und Fehlerpfade tragen. Trigger steuern, wann der Job startet, und Notifications informieren über Zustand und Dauer.

Historisch ist Lakeflow Jobs das umbenannte Produkt „Databricks Jobs" (ursprünglich) beziehungsweise „Databricks Workflows" (zwischenzeitlich). Mit der Konsolidierung der Lakeflow-Familie 2024/2025 firmiert es als Lakeflow Jobs. Microsoft Learn führt die Begriffe im deutschen Tenant unter „Lakeflow-Aufträge". Bestehende Asset-Bundle-YAMLs, Terraform-Resources und Job-API-Skripte bleiben kompatibel; die Umbenennung hat keine Bruchstelle in Definition und Konfiguration.

Zur Laufzeit gehören vier Compute-Modelle zur Wahl: ein neuer Job-Cluster pro Task (Isolation, aber Cold Start bei jedem Task), ein Shared Job-Cluster (einmal pro Run gestartet, von mehreren Tasks geteilt), Serverless Compute für Jobs (managed, ohne Cluster-Konfiguration, höherer DBU-Preis) sowie optional ein existierender All-Purpose-Cluster (für produktive Jobs nicht empfohlen). Beobachtbarkeit läuft über Unity-Catalog-System-Tabellen (system.lakeflow.jobs, system.lakeflow.job_run_timeline, system.lakeflow.job_task_run_timeline) sowie Webhook-Notifications für Slack, Microsoft Teams und PagerDuty.

Abgrenzung: Airflow, Declarative Pipelines, Asset Bundles, Lakeflow Connect

Lakeflow Jobs wird oft mit anderen Bausteinen der Lakeflow-Familie oder mit externen Orchestratoren verwechselt, weil die Namen und Zuständigkeiten nah beieinanderliegen.

Die häufigste inhaltliche Verwechslung betrifft Airflow. Ein Lakeflow-Task führt beliebigen Code auf einem Cluster aus und kann darüber jedes System ansprechen, das im Netzwerk erreichbar ist (Snowflake-Loads, SAP-Calls, REST-APIs). Was ein Airflow-Operator als HTTP-Call macht, macht ein Python-Task ebenso. Die Entscheidung zwischen beiden Orchestratoren richtet sich weniger nach Fähigkeiten als nach Schwerpunkt und Bestand des Workflow-Portfolios.

Beispiel: Nächtlicher End-to-End-Workflow

Ein typisches Einsatzmuster ist ein nächtlicher Workflow über die Medaillon-Architektur eines Databricks-Lakehouse. Ein Lakeflow Job startet um 03:00 Uhr per Schedule-Trigger und läuft als Graph aus fünf Tasks.

Der erste Task ist eine Lakeflow-Connect-Ingestion aus Salesforce, die neue Account- und Opportunity-Daten in Bronze-Delta-Tabellen unter Unity Catalog schreibt. Danach starten zwei parallele Lakeflow-Declarative-Pipeline-Tasks: die eine transformiert die Vertriebsdaten zu Silver, die andere ergänzt Marketing-Domänen aus einer separaten Bronze-Quelle. Beide Pipeline-Tasks nutzen denselben Shared Job-Cluster, sodass der Cluster-Cold-Start nur einmal pro Run anfällt.

Nach erfolgreicher Silver-Ebene läuft ein dbt-Task, der Gold-Aggregate für das Reporting berechnet, gefolgt von einem SQL-Task, der ein Genie-Dashboard aktualisiert. Eine If/Else-Condition auf Basis von run_if: at_least_one_failed steuert einen Recovery-Pfad: schlägt ein Pipeline- oder dbt-Task fehl, sendet ein Notification-Task eine Nachricht an einen Slack-Kanal und öffnet ein Incident-Ticket über einen REST-Call. Bei Erfolg endet der Graph ohne Verzweigung.

resources:
  jobs:
    nightly_sales_pipeline:
      name: nightly_sales_pipeline
      schedule:
        quartz_cron_expression: "0 0 3 * * ?"
        timezone_id: Europe/Berlin
      job_clusters:
        - job_cluster_key: shared_transform
          new_cluster:
            spark_version: 15.4.x-scala2.12
            node_type_id: Standard_D4ads_v5
            num_workers: 4
      tasks:
        - task_key: ingest_salesforce
          pipeline_task:
            pipeline_id: ${resources.pipelines.connect_salesforce.id}
        - task_key: silver_sales
          depends_on:
            - task_key: ingest_salesforce
          pipeline_task:
            pipeline_id: ${resources.pipelines.silver_sales.id}
        - task_key: gold_dbt
          depends_on:
            - task_key: silver_sales
          job_cluster_key: shared_transform
          dbt_task:
            project_directory: ./dbt

Der Job wird über ein [Databricks Asset Bundle](/insights/glossar/databricks-asset-bundles/) mit Dev-, Stage- und Prod-Target versioniert. Damit ist die Job-Definition Git-verwaltet, review- und rollback-fähig; Änderungen wandern über CI/CD von Entwicklung nach Produktion.