Lakeflow Jobs: Wie der Task-Graph in Databricks funktioniert
Die Kernaussagen auf einen Blick.
- Lakeflow Jobs ist die native Orchestrierung von Databricks und verbindet unterschiedliche Task-Typen, Abhängigkeiten, Parameter und Compute-Modelle in einem gemeinsamen Workflow.
- Die Umbenennung ist für die Architektur weniger relevant als die Frage, welche Workloads über Lakeflow Jobs orchestriert werden sollen.
- Vor der Umsetzung weiterer Jobs sollten drei Punkte festgelegt werden: Compute-Strategie für die jeweiligen Task- und Lastprofile, Trigger-Modell, Deployment-Pfad über Asset Bundles.
- Empfehlenswert ist, Lakeflow Jobs als Standard für Databricks-zentrische Workflows zu setzen.
- Airflow ist dabei selten eine echte Alternative: Was über Airflow läuft, lässt sich in der Regel ebenso als Lakeflow Job abbilden.
- Ein zweiter Orchestrator rechtfertigt sich eher über einen großen produktiven Altbestand als über fehlende Fähigkeiten.
Inhaltsverzeichnis
Lakeflow Jobs sind mehr als ein Scheduler
In einem Plattform-Review zeigte sich ein Bestand von zweihundert Jobs, sechs Clusterprofilen und drei unterschiedlichen Trigger-Modellen, ohne einheitliche Standards. Ein Teil der Abläufe wurde über verschachtelte dbutils.notebook.run-Aufrufe aus einem zentralen Notebook gesteuert. Andere Jobs wurden über Airflow gestartet, weil die Plattform bereits vorhanden war. Ein Drittel lief auf einem dauerhaft laufenden All-Purpose-Cluster, weil die Startzeit von Job-Clustern als zu hoch eingeschätzt wurde. Die Möglichkeit, Compute innerhalb eines Job-Runs gemeinsam zu verwenden, wurde nicht genutzt.
Eine solche Entwicklung ist in vielen über mehrere Jahre gewachsenen Datenplattformen zu beobachten. Die Orchestrierungslandschaft wird häufig schrittweise erweitert, ohne ein übergreifendes Zielmodell festzulegen: erst ein Notebook, dann ein Cron, dann ein Airflow, später entsteht möglicherweise eine weitere Orchestrierungslösung für Workloads, die im bestehenden Setup nicht zuverlässig funktionieren. Dadurch ist nicht mehr eindeutig nachvollziehbar, welches System welche Workflows steuert.
Was passiert, wenn jeder Job anders gebaut ist? Welches Team ist für Betrieb und Fehlerbehebung verantwortlich, wenn der Job um drei Uhr morgens scheitert? Welches Compute-Modell passt zum jeweiligen Task- und Lastprofil, wenn vier Tasks im Job laufen? Wann lohnt sich Serverless, wann ein klassisches Job-Cluster? Wie viel Orchestrierungslogik gehört in Databricks, wie viel außerhalb?
Wer Lakeflow Jobs ausschließlich als zeitgesteuerten Notebook-Starter nutzt, verwendet nur einen kleinen Teil des Funktionsumfangs. Lakeflow Jobs bildet Workflows als Graph aus typisierten Tasks, Abhängigkeiten, Compute-Zuordnungen und Bedingungen ab.
Was sind Lakeflow Jobs?
Lakeflow Jobs übernimmt innerhalb der Lakeflow-Familie die Orchestrierung von Tasks und Pipelines auf der Databricks Data Intelligence Platform. Es koordiniert mehrere Tasks und führt sie in einer definierten Abhängigkeitsstruktur aus. Die Funktion wurde zunächst unter dem Namen Databricks Jobs eingeführt und später als Databricks Workflows weitergeführt. Seit 2025 ist sie unter „Lakeflow Jobs" Teil der Lakeflow-Familie (Connect, Pipelines, Jobs, Designer).
Ein Job besteht aus mehreren Tasks mit definierten Abhängigkeiten. Technisch bildet dieser Aufbau einen gerichteten azyklischen Graphen. Für jeden Task werden Ausführungstyp (Notebook, Python-Skript, JAR, SQL, Pipeline, dbt, Model Serving, Run Job, If/Else, For Each), Compute, Parameter und Fehlerverhalten festgelegt. Trigger steuern, wann der Job läuft.
Innerhalb von Lakeflow sind Ingestion (Connect), Transformation (Declarative Pipelines), Orchestrierung (Jobs) und visuelle Entwicklung (Designer) auf unterschiedliche Komponenten verteilt. Wie diese Komponenten in einem Betriebsmodell zusammenspielen, klären wir im Überblick zu Data Engineering auf Databricks.
Architektonisch sitzt Lakeflow Jobs zwischen Quellen und Consumption-Layer: ERP-Systeme, Lakeflow Connect, Cloud Storage und Message Bus liefern die Trigger und Rohdaten, Lakeflow Jobs orchestriert darauf die Lakeflow Declarative Pipelines über die Medallion-Schichten Bronze, Silver und Gold, und die Ergebnisse fließen anschließend in DBSQL, BI-Dashboards und ML-Modelltraining.
Lakeflow Jobs übernimmt jedoch nicht alle Aufgaben einer Datenplattform: kein Framework zur deklarativen Definition von Tabellen und Transformationen (das ist Declarative Pipelines), kein Deployment-Werkzeug (das sind Asset Bundles). Externe Systeme kann ein Job dagegen sehr wohl ansteuern, über Python-Tasks, REST-Calls und Sub-Jobs; die Grenze zu Airflow verläuft am Betriebsmodell, nicht an der Fähigkeit (dazu weiter unten mehr).
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Databricks Jobs, Databricks Workflows und Lakeflow Jobs: Was sich geändert hat
Die grundlegende Funktionalität bleibt bestehen, während sich die Produktbezeichnung geändert hat. Databricks hat 2024 mit der Lakeflow-Familie eine gemeinsame Produktfamilie für Ingestion, Transformation und Orchestrierung eingeführt. „Databricks Jobs" und „Databricks Workflows" sind die Vorgängernamen. Die bisherigen Bezeichnungen beziehen sich auf dieselben APIs und Kernkonzepte und dieselben Compute-Modelle. Microsoft Learn führt die Begriffe explizit zusammen und nutzt im DE-Tenant noch die Übersetzung „Lakeflow-Aufträge".
Für bestehende Plattformen hat die Umbenennung nur geringe technische Auswirkungen: bestehende Job-Definitionen, Asset-Bundle-YAMLs, Terraform-Resources, Job-APIs bleiben kompatibel. Bei der Recherche muss jedoch berücksichtigt werden, dass Dokumentationen unterschiedliche Produktnamen verwenden. Abhängig vom Veröffentlichungszeitpunkt wird dieselbe Funktionalität unter mehreren Bezeichnungen beschrieben.
Tasks, Abhängigkeiten und Compute-Zuordnung
Ein Lakeflow Job ist ein gerichteter Graph aus Tasks mit depends_on-Beziehungen. Jeder Task läuft auf einem definierten Compute: Job-Cluster (neu pro Run), Shared Job-Cluster (geteilt innerhalb eines Runs), Serverless Compute oder einem existierenden All-Purpose-Cluster. Die Zuordnung des Computes sollte deshalb bereits beim Entwurf des Task-Graphen berücksichtigt werden, bevor die einzelnen Tasks implementiert werden.
Ein Beispiel aus der Databricks-Workflows-UI verdeutlicht das: Der Job bakehouse_orchestration startet mit der ingest-pipeline. Danach entscheidet die If/Else-Bedingung is_AI_enabled zur Laufzeit über zwei Pfade: im True-Fall folgt query_DBRX_in_SQL auf einem Serverless SQL Warehouse und anschließend update_downstream, im False-Fall folgt lediglich email-exit-without_AI.
Das Beispiel zeigt genau das: nicht eine lineare Kette von Notebooks, sondern einen Graphen mit Verzweigung. Die If/Else-Bedingung is_AI_enabled entscheidet zur Laufzeit über zwei Pfade, ohne dass diese Logik in Notebook-Code versteckt ist.
Ein Job unterstützt eine Reihe typisierter Task-Typen. Die wichtigsten mit ihrer Cluster-Bindung:
| Task-Typ | Use Case | Cluster-Bindung |
|---|---|---|
| Notebook | bestehende Notebook-Logik oder schrittweise Migration vorhandener Workflows | Job-Cluster · Shared · Serverless |
| Python Script | versionierter Python-Code aus dem Repository | Job-Cluster · Shared · Serverless |
| JAR | Scala/Java-Workloads | Job-Cluster · Shared |
| SQL Query / Dashboard / Alert / File | SQL-getriebene Schritte | SQL Warehouse (kein Job-Cluster) |
| Pipeline (Lakeflow Declarative Pipelines) | Ausführung einer deklarativen Pipeline innerhalb eines übergeordneten Workflows | Pipeline-eigenes Compute |
| dbt | dbt-Modelle als Job-Schritt | SQL Warehouse oder Job-Cluster |
| Model Serving Job | Batch-Inferenz auf produktivem Modell | Serverless Model Serving |
| Run Job | Aufruf eines eigenständig verwalteten Sub-Jobs | erbt vom Sub-Job |
| If/Else Condition | Verzweigung im Graph | kein Compute |
| For Each | dynamische Iteration über Werte-Liste | erbt vom Sub-Task |
Drei Funktionen erweitern Lakeflow Jobs über eine reine zeitgesteuerte Ausführung hinaus:
Conditional Execution
Nachgelagerte Tasks laufen abhängig vom Status oder Ergebnis vorheriger Tasks: run_if: at_least_one_failed, all_done oder none_failed. Fehler- und Recovery-Pfade lassen sich so explizit im Workflow statt im Notebook-Code modellieren.
For Each
Ein Task läuft für jedes Element einer zur Laufzeit bereitgestellten Liste, sinnvoll für Multi-Tenant-Workloads, Partitions-Schleifen oder parallele Verarbeitung vieler Quellen. Die Liste kann aus Task-Werten eines Vorgängers stammen.
Run Job
Ein Task ruft einen anderen Job auf. Umfangreiche Workflows lassen sich so in eigenständig verwaltete Teiljobs zerlegen: Ingest-, Transform- und Publish-Layer, jeweils mit eigener Verantwortlichkeit und eigenem Lebenszyklus.
Mit diesen drei Mechaniken lassen sich komplexe Workflows direkt innerhalb von Databricks umsetzen. Werden sie ignoriert, muss Verzweigungs- und Fehlerlogik andernfalls häufig im Anwendungscode umgesetzt werden und ist in der Workflow-Ansicht und Ausführungshistorie nur eingeschränkt nachvollziehbar.
Schedule, File Arrival, Table Update und Continuous
Lakeflow Jobs unterstützt vier produktive Trigger plus manuelle und API-Ausführung. Microsoft Learn beschreibt im Detail, wie sich Trigger und Schedules pro Job konfigurieren lassen:
Schedule
Cron-Ausdruck (Quartz-Syntax) mit Zeitzone. Geeignet für periodische Batch- und ETL-Prozesse, Granularität bis auf Minuten-Ebene.
File Arrival
Trigger auf neue Files in einem Unity-Catalog-Volume. Ersetzt separate Polling- oder Event-Grid-Logik; Latenz im Minuten-Bereich, nicht für Sub-Sekunden-Reaktion geeignet.
Table Update
Startet nachgelagerte Jobs auf Grundlage von Änderungen an einer Delta-Tabelle, sinnvoll, wenn Downstream-Jobs auf eine vorgelagerte Pipeline reagieren sollen, ohne dieselbe Definition zu teilen.
Continuous
Der Job läuft permanent und startet bei Abschluss sofort neu. Sinnvoll für fortlaufend wiederholte Verarbeitung mit kurzen Pausen zwischen den Runs.
Manuell / API
Trigger über UI, REST API (POST /api/2.2/jobs/run-now) oder Job-Run-Trigger aus einem anderen Job (siehe Run Job).
Das Trigger-Modell beeinflusst Latenz, Compute-Nutzung und Wiederanlaufverhalten. Zeitpläne sind gut planbar und erleichtern Backfills sowie Audits. File Arrival reagiert auf neu eingehende Dateien, kann bei klassischem Compute jedoch wiederholte Startzeiten verursachen. Table Update koppelt Jobs an Daten-Events; die Ausführung richtet sich dadurch nach dem Datenereignis statt nach einem festen Zeitplan. Continuous vermeidet wiederholte Clusterstarts, verursacht dafür aber dauerhaft laufenden Compute.
Die Compute-Zuordnung gehört zu den wichtigsten Kosten- und Betriebsentscheidungen eines Jobs. Drei Modelle stehen zur Wahl:
Databricks dokumentiert die Konfiguration eines geteilten Job-Clusters über job_clusters und job_cluster_key im Detail.
Job-Cluster pro Task
Für jeden Task wird ein eigener, zeitlich begrenzter Cluster bereitgestellt, der nach Abschluss terminiert. Vorteil: gute Isolation und eindeutige Kostenzuordnung. Nachteil: bei jedem Task erneut Cold Start (typisch 2–5 Minuten).
Shared Job-Cluster
Der Cluster wird einmal pro Job-Run gestartet und von mehreren Tasks genutzt. Vorteil: Cold Start nur einmal, günstiger bei vielen kurzen Tasks. Nachteil: mögliche Konflikte bei Bibliotheken und Spark-Konfiguration zwischen den Tasks.
Serverless Compute für Jobs
Databricks startet das Compute on-demand ohne Cluster-Konfiguration. Vorteil: kein Cluster-Management, keine Cold-Start-Kosten. Nachteil: weniger manuelle Kontrolle, Pricing pro DBU höher als auf klassischen Job-Clustern.
Als erste Orientierung gilt:
- Ein Task pro Run, lange Laufzeit (über 15 min): Job-Cluster pro Task. Bei langen Laufzeiten fällt die Startzeit weniger ins Gewicht, während die Isolation Vorteile bietet.
- Mehrere kurze Tasks im selben Run, gleicher Stack: Shared Job-Cluster. Cold Start einmal, dann teilen.
- Tasks mit stark schwankendem Datenvolumen oder schwer vorhersehbarem Ressourcenbedarf, Self-Service-Charakter: Serverless Compute für Jobs. Weniger manuelle Konfiguration bei stärker automatisierter Skalierung.
- All-Purpose-Cluster sollten für produktive Jobs nur in begründeten Ausnahmefällen verwendet werden. Die gemeinsame Nutzung mit interaktiven Workloads erschwert verlässliche Laufzeiten und eine klare Kostenzuordnung.
Job-Cluster werden für jeden Run neu bereitgestellt und nicht zwischen einzelnen Runs weiterverwendet. Innerhalb eines Runs erlaubt der Shared-Modus die Wiederverwendung. Für weitere Cold-Start-Reduktion bleibt Serverless die Option.
Job-Parameter, Task-Werte und Inter-Task-Kommunikation
Drei Mechanismen ermöglichen den Austausch von Parametern und kleinen Steuerungswerten innerhalb eines Job-Runs, ohne dafür zwingend einen zusätzlichen Zustandsdienst einzusetzen:
Job-Parameter
Werden beim Job-Start gesetzt (UI, API oder Run-Now-With-Different-Parameters) und sind allen Tasks lesbar. Sinnvoll für Zeiträume oder Stichtage für Backfills, Umgebungskennzeichen, Tenant-IDs.
Task-Werte
Kleine Key-Value-Paare, die ein Task während des Runs schreibt (taskValues.set) und nachfolgende Tasks lesen (taskValues.get), etwa eine Liste neu verarbeiteter Partitionen, die ein Transform-Task über For Each expandiert.
Dynamische Platzhalter
Platzhalter in der Job-Konfiguration wie {{job.run_id}}, {{tasks.upstream.values.partition_count}} oder {{job.parameters.run_date}} nutzen Parameter und Task-Werte direkt in Konfigurationen und Pfaden.
Für einfache Steuerungsinformationen können Task-Werte und Job-Parameter zusätzliche Zustandsdienste (Redis, eine Steuerungs-Tabelle, ein S3-Lock) ersetzen. Die verwendeten Parameter und Task-Ergebnisse bleiben im jeweiligen Job-Run nachvollziehbar.
Retries, Timeouts und Error Handling in Lakeflow Jobs
Wiederholungen, Zeitlimits und Fehlerpfade sollten möglichst in der Job-Konfiguration definiert werden. Sie sollten nicht für jeden Workflow individuell im Notebook-Code implementiert werden.
| Mechanismus | Ebene | Zweck |
|---|---|---|
| Retries pro Task | Task | Anzahl der Wiederholungen, minimale und schrittweise steigende Wartezeit zwischen Versuchen. Sinnvoll für transiente Fehler (Cluster-Start, Netzwerk, kurzfristige Service-Ausfälle). |
| Timeout pro Task | Task | Hartes Limit; nach Ablauf gilt der Task als gescheitert. Verhindert, dass blockierte oder fehlerhafte Tasks unbegrenzt Compute verbrauchen. |
| Zeitlimit für den Job-Run | Job | Hartes Limit für den gesamten Run. Begrenzt die Kosten, falls ein kontinuierlicher oder komplexer Job nicht ordnungsgemäß beendet wird. |
| Concurrent Runs | Job | Maximale Anzahl paralleler Runs desselben Jobs. Standardmäßig wird eine überlappende Ausführung verhindert. |
| Conditional Execution | Graph | Über run_if reagieren Downstream-Tasks auf den Status der Vorgänger. Wiederherstellungs- und Benachrichtigungsschritte lassen sich direkt im Workflow-Graphen modellieren statt in Notebook-Logik. |
| Notifications | Job | E-Mail, Slack-Webhook, PagerDuty-Webhook, Microsoft Teams. Auf Job-Start, -Erfolg, -Fehler, -Dauer-Überschreitung. Empfänger pro Job konfigurierbar. |
| Repair & Rerun | Run | Gezielte Wiederholung fehlgeschlagener Tasks und ihrer Downstream-Abhängigkeiten; erfolgreiche Tasks bleiben unangetastet. Spart Compute bei langen Graphen und macht Recovery deterministisch. |
Individuell implementierte Retry-Logik führt zu mehreren betrieblichen Nachteilen: Die Run-History zeigt die Retries nicht, Wiederholungs- und Fehlerregeln unterscheiden sich zunehmend zwischen den Workflows, und eine spätere Standardisierung erfordert eine aufwendige Überarbeitung des Anwendungscodes.
Lakeflow Jobs, Declarative Pipelines und Lakeflow Designer im Zusammenspiel
Lakeflow Jobs steuert die Abfolge von Tasks, während Declarative Pipelines tabellenorientierte Transformationen und deren Zustand verwalten. Beide laufen in derselben Plattform, sind aber unterschiedliche Werkzeuge.
Eine Declarative Pipeline (ehemals Delta Live Tables) ist ein deklarativ definiertes ETL-Konstrukt: Quell-Tabellen, Transformationen, Expectations, automatisches Materialisierungs- und Refresh-Verhalten. Sie wird über Pipeline-Code (Python oder SQL) definiert und über die Pipeline-API getriggert. Aus Sicht des übergeordneten Workflows ist eine Pipeline lediglich ein weiterer Task-Typ, also ein Schritt im Graph.
Ein typisches Einsatzmuster: ein Job orchestriert die Reihenfolge mehrerer Pipelines, ergänzt um vorgelagerte Prüfungen, Notifications, nachgelagerte dbt-Modelle oder Veröffentlichungsschritte und Conditional Execution für Recovery. Die Pipeline selbst kümmert sich um Inkremente, Expectations und Materialisierung.
Wie wir die Pipeline-Schicht und ihre Verzahnung mit Jobs designen, klären wir im Überblick zu Lakeflow Declarative Pipelines.
Lakeflow Designer stellt eine visuelle Entwicklungsoberfläche für Pipeline- und Workflow-Komponenten bereit, also eine Authoring-Oberfläche und kein eigenes Produkt. Produktive Workflows sollten weiterhin versioniert und über einen geregelten Deployment-Prozess bereitgestellt werden. YAML-im-Asset-Bundle oder Terraform bleiben hier der bessere Pfad. Designer ist sinnvoll für Prototyping, Exploration und gemeinsame Entwürfe mit analytisch-technischen Nutzern.
Lakeflow Jobs mit Asset Bundles deployen
Produktive Jobs sollten nicht ausschließlich manuell in der Benutzeroberfläche konfiguriert werden. Daraus entstehen drei wesentliche Nachteile: fehlende Versionierung, keine geregelte technische Prüfung von Änderungen und abweichende Konfigurationen zwischen Entwicklung, Staging und Produktion.
Databricks Asset Bundles (DABs) bündeln Jobs, Pipelines, Notebooks, Cluster-Profile, Permissions und Konfigurationen in einer databricks.yml und deployen sie pro Target (Dev, Staging, Prod). Die Jobdefinition wird dadurch versioniert, geprüft und reproduzierbar bereitgestellt: Pull Request, Review, Deployment, Audit. Asset Bundles laufen in CI/CD-Pipelines wie GitHub Actions oder Azure DevOps und nutzen databricks bundle validate plus databricks bundle deploy.
Wie wir Asset-Bundle-Strukturen für mehrere Jobs und Environments aufsetzen, zeigen wir im Überblick zu Databricks Asset Bundles.
Werden Compute-Konfigurationen in jedem Job separat gepflegt, entwickeln sich die Einstellungen zwischen Teams und Workflows auseinander. Wiederverwendbare Compute-Standards sollten zentral über Includes, Variablen oder Cluster Policies bereitgestellt werden. Ohne diese Zentralisierung können Job-Cluster zwischen Teams bereits nach kurzer Zeit in Spark-Version, Library-Set und Photon-Aktivierung voneinander abweichen.
System Tables, Run History und Notifications
Lakeflow Jobs schreibt Telemetrie in das Unity Catalog System-Schema system.lakeflow.*. Die wichtigsten Tabellen:
system.lakeflow.jobs
Definitionen aller Jobs im Workspace, mit Owner, Tags, Cluster-Konfig.
system.lakeflow.job_run_timeline
Run-Status, Start- und Endzeitpunkt, Trigger-Typ, Dauer.
system.lakeflow.job_task_run_timeline
Run-Status pro Task innerhalb eines Runs.
Auf dieser Grundlage lassen sich Bestandsübersichten, SLA-Auswertungen und Kostenberichte erstellen sowie Drift-Erkennung als SQL-Query umsetzen. Für viele Analysen ist dadurch keine vollständige Abfrage und Paginierung der Job-API mehr erforderlich. Wie wir System-Tables für Plattform-Observability nutzen, zeigen wir im Überblick zu Unity Catalog System Tables.
Auf Workspace-Ebene ergänzen Ausführungshistorie, Benachrichtigungen (Slack, Teams, PagerDuty) und Cluster-Logs (in DBFS oder Unity-Catalog-Volume) die Systemtabellen. Für workspaceübergreifende Bestandsaufnahmen kann abhängig von der verfügbaren Systemtabellenstruktur weiterhin eine zentrale API-Auswertung erforderlich sein.
Wann externe Orchestrierung sinnvoll bleibt
Die verbreitete Faustregel lautet: Sobald ein Workflow Systeme außerhalb von Databricks berührt, gehört er in einen externen Orchestrator. Diese Regel greift zu kurz. Ein Lakeflow-Task führt beliebigen Code auf einem Cluster aus und kann darüber jedes System ansprechen, das im Netzwerk erreichbar ist.
Was Teams typischerweise zu Airflow führt, lässt sich innerhalb von Lakeflow Jobs abbilden:
Externe REST-Calls und APIs
Ein Python-Task ruft beliebige Endpunkte auf, inklusive komplexer Auth über OAuth, mTLS oder Secrets aus Unity Catalog. Was ein Airflow-Operator als HTTP-Call macht, macht ein Python-Task ebenso.
Trigger und Ladevorgänge in andere Systeme
Snowflake-Loads, SAP-Calls, Aufrufe lokaler Unternehmenssysteme, solange das Compute das Zielsystem über das Netz erreicht (Private Link, VNet-Injection, SHIR-Äquivalent). Airflow-Worker brauchen denselben Netzzugang.
Sensoren und Wartebedingungen
Ein pollender Task oder die Trigger File Arrival und Table Update ersetzen die meisten Airflow-Sensoren.
Zerlegung großer Graphen
Run Job verschaltet Teil-Workflows mit eigenen Ownern und Lebenszyklen, das Pendant zu Sub-DAGs und Cross-DAG-Dependencies.
Die Frage ist deshalb selten, ob Lakeflow Jobs einen plattformübergreifenden Graphen ausführen kann. Sie lautet, wo der Schwerpunkt des Workflows liegt und ob ein zweiter Orchestrator den Betrieb vereinfacht oder verdoppelt.
Ein ehrlicher Grund, Airflow zu behalten, bleibt: ein großer, produktiv genutzter DAG-Bestand, bei dem Databricks nur einer von vielen Knoten ist und der Schwerpunkt der Orchestrierung bewusst außerhalb der Plattform liegt. Eine Ablösung ist dann eine Investitions- und Risikoentscheidung, kein technisches Defizit von Lakeflow Jobs. Ein kleiner Airflow-Bestand dagegen, der ausschließlich Databricks-Jobs startet, verursacht mehr Betriebsaufwand als Nutzen.
Andere externe Orchestratoren ordnen sich nach demselben Maßstab ein:
Azure Data Factory
Trägt in Microsoft-zentrischen Stacks, wenn Integration-Runtime-Anforderungen (SHIR), Power-Platform-Trigger oder Logic-App-Verzahnung den Schwerpunkt bilden. ADF stößt Databricks-Jobs an, die Task-Orchestrierung bleibt in Databricks.
Prefect
Eine Option für Python-zentrierte Workloads, deren Schwerpunkt außerhalb des Lakehouse liegt.
GitHub Actions
Deckt Deployment und einfache Auslöser für Asset-Bundle-Deployment ab. Kein Orchestrator für zustandsbehaftete Datenworkflows: keine Task-Retries, kein State, keine SLAs.
Die Entscheidung richtet sich damit weniger nach Systemgrenzen als nach Schwerpunkt und Bestand:
| Kriterium | Lakeflow Jobs | Externe Orchestrierung |
|---|---|---|
| Graph komplett innerhalb Databricks | besser | zusätzlicher Betriebsaufwand ohne funktionalen Mehrwert |
| Graph mit Steps außerhalb Databricks | deckt es über Python-Tasks, REST-Calls und Run Job ab | gleichwertig möglich, aber zweite Control Plane |
| großer, produktiv genutzter Airflow-Bestand | Ablösung kostet Migrationsaufwand | trägt, solange Databricks nicht der Schwerpunkt ist |
| Cluster-Hoheit und FinOps-Transparenz auf Job-Ebene | besser (System Tables) | hängt vom Worker-Modell |
| Audit und Lineage in einer Plattform | besser | erfordert zusätzliche Integration |
| Schwerpunkt der Orchestrierung außerhalb Databricks | unnötiger Sonderweg | passender |
Ein häufiger Fehler besteht darin, einen vorhandenen Orchestrator ohne erneute Bewertung für alle neuen Workflows weiterzuverwenden. Das Argument „wir hatten Airflow schon" trägt nur, wenn der Airflow-Bestand produktiv genutzt wird. Ein kleiner Airflow-Bestand, der ausschließlich Databricks-Jobs startet, kann mehr Betriebsaufwand verursachen als Nutzen liefern. FinOps-Reviews aus der Praxis zeigen, dass mehrere gleichzeitig betriebene Orchestrierungsplattformen schnell einen zweistelligen Prozent-Anteil an den Job-Kosten der Plattform ausmachen, obwohl dieser Aufwand in der technischen Zielarchitektur häufig nicht berücksichtigt wird.
Architektur, Ingestion und Compute-Standards
Die konkrete Jobdefinition setzt mehrere vorgelagerte Architekturentscheidungen voraus. Zunächst müssen übergreifende Standards für Schichten, Ingestion, Compute und Deployment festgelegt werden, die Lakeflow Jobs nicht für dich trifft.
Die Ingestion-Strategie entscheidet sich meist zwischen Auto Loader und Lakeflow Connect:
Layering
Welche Schichten hat die Lakehouse-Architektur (Bronze, Silver, Gold)? Welche Schicht wird per Job orchestriert, welche per Pipeline transformiert? Das Schichten- und Verarbeitungsmodell sollte vor der Job-Implementierung feststehen.
Ingestion-Strategie
Werden Daten per Auto Loader gestreamt, per Lakeflow Connect ingestiert oder per File Arrival angeschoben? Der Trigger des Jobs hängt von dieser Entscheidung ab.
Compute-Hoheit
Wer legt zulässige Compute-Profile und deren Grenzen fest: eine zentrale Plattform-Owner-Gruppe per Cluster Policies oder jedes Team frei? Ohne zentrale Standards entwickeln sich Compute-Konfigurationen auseinander.
Deployment-Pfad
Asset Bundles, Terraform, beide oder UI? Manuell gepflegte Jobs lassen sich nur eingeschränkt versionieren, prüfen und reproduzieren.
Diese Grundsatzentscheidungen sollten nicht dezentral in einzelnen Jobdefinitionen getroffen werden. Wie wir sie für Databricks-Plattformen strukturieren, zeigen wir im Überblick zu Data Engineering auf Databricks.
Grenzen von Lakeflow Jobs
Lakeflow Jobs ist eine Orchestrierungs-Komponente innerhalb Databricks. Aufgaben außerhalb dieses Scopes sollten nicht in die Jobdefinition verlagert werden. Microsoft Learn dokumentiert die konkreten Workspace-Limits im Detail.
Kein dedizierter Workflow-Server
Lakeflow Jobs läuft im Databricks-Workspace, nicht als eigenständiger Service. Workspaceübergreifende Abläufe sind möglich, gehören aber nicht zu den Kernstärken. Eine Verteilung über fünf Workspaces ohne klaren Owner kann schwer überschaubar werden.
Keine Lock-Mechanismen für gemeinsame Ressourcen
Concurrent-Runs verhindern nur Job-internen Overlap. Konkurrenz- und Schreibkonflikte mehrerer Jobs auf dieselben Zielobjekte müssen über Tabellen-, Pipeline- oder Architekturmechanismen behandelt werden (Delta-Concurrency-Modi, Tabellen-Design).
Keine konsolidierte Sicht über mehrere Workspaces
Die Job-API liefert Job-Definitionen pro Workspace. Ein konsolidiertes Estate-View erfordert System-Tables-Inventur oder externe Aggregation.
Visueller Editor nicht produktionsfähig allein
Lakeflow Designer beschleunigt das Authoring, ersetzt aber keinen versionierten Deployment- und Review-Prozess. Ein ausschließlich geklickter Job hat keinen Audit-Pfad.
Serverless Compute für Jobs noch in Reifung
Pricing pro DBU liegt über klassischen Job-Clustern. Bei kurzen oder stark schwankenden Tasks überwiegen die Vorteile der schnellen Bereitstellung, für lange Tasks rechnet sich klassisches Job-Cluster oft besser.
Harte Workspace-Limits
2.000 gleichzeitig laufende Task-Runs, 10.000 neue Jobs pro Stunde (inkl. runs/submit), 12.000 gespeicherte Jobs, 1.000 Tasks pro Job, 10.000 Zeichen für Job-Parameter bei Dynamic Values. Für sehr große Estates gehören diese Limits in die Architektur-Planung.
Innerhalb dieser Grenzen ist Lakeflow Jobs eine leistungsfähige Orchestrierung für Databricks-Workloads. Ohne diesen Blick entsteht entweder eine zweite Plattform daneben, oder es wird Prozess- oder Datenlogik in die Orchestrierung verlagert, die besser in anderen Plattformkomponenten aufgehoben wäre.
Fazit
Lakeflow Jobs wird besonders relevant, sobald mehrere produktive Workflows einheitlich orchestriert und betrieben werden müssen.
Besonders relevant ist das für Plattformen, die bereits auf Databricks aufsetzen und zusätzlich einen externen Orchestrator einsetzen, obwohl dieser ausschließlich Databricks-interne Abläufe startet. Auch für Plattformen, deren Job-Bestand eine historisch gewachsene Joblandschaft ohne einheitliche Standards bildet und die Cluster-Reuse, Standards und konsistente Trigger bisher nicht etabliert haben.
Typische Ausgangssituationen sind:
- eine große Anzahl von Jobs mit unterschiedlichen Trigger-, Compute- und Fehlerbehandlungsmodellen
- ein paralleler Airflow, der nur Databricks-Notebooks triggert
- mehrere kurze Tasks, die jeweils unnötig eigenes Compute starten
- individuell im Anwendungscode umgesetzte Wiederholungs- und Fehlerlogik
- manuell verwaltete Jobdefinitionen ohne Versionierung und Deployment-Prozess
Reicht der Job-Graph über Databricks hinaus (SAP, Snowflake, On-Prem-Systeme, komplexe Cross-Cloud-Trigger), bildet Lakeflow Jobs das über Python-Tasks, REST-Calls und Run Job ab. Ein externer Orchestrator wird erst dann zur besseren Wahl, wenn der Schwerpunkt der Orchestrierung bewusst außerhalb von Databricks liegt oder ein großer, produktiv genutzter Bestand seine Ablösung nicht rechtfertigt.
Entscheidend ist nicht die Einführung eines weiteren Orchestrierungswerkzeugs. Ziel ist ein einheitliches Betriebsmodell für Abhängigkeiten, Compute, Fehlerbehandlung und Deployment.
<!-- CTA rendert automatisch zwischen Fazit und FAQ aus Frontmatter cta: (articleCta-Block), kein eigener Body-Content mehr nötig, siehe SKILL.md Body-Konvention #3. -->
Lakeflow Jobs als Default für Databricks-zentrische Workflows etablieren, externe Orchestrierung auf Fälle mit Schwerpunkt außerhalb von Databricks oder großem produktivem Altbestand begrenzen und Cluster-Reuse vom ersten Job an aktivieren. Ein zusätzlicher Airflow-Betrieb, der nur Databricks-Jobs startet, verursacht eigene Betriebs- und Governance-Aufwände ohne Gegenwert.
FAQ
Lakeflow Jobs ist die native Orchestrierungs-Komponente der Databricks Data Intelligence Platform. Sie steuert mehrstufige Workflows als Task-Graph mit definierten Abhängigkeiten, Trigger-Modellen, Cluster-Bindung und Conditional Execution. Sie ist Teil der Lakeflow-Familie und löst die früheren Markennamen „Databricks Jobs" und „Databricks Workflows" ab.
