Zurück zu InsightsTeil der Referenzarchitektur

Orchestrierung

Dagster: der Taktgeber der Data Platform.

Dagster koordiniert, wann und in welcher Reihenfolge Daten fließen – von der dlt-Ingestion bis zu den dbt-Marts. Warum wir es einsetzen, was es ist und wie ein Lauf tatsächlich abläuft.

01

Warum Dagster

Asset-zentriert · deklarativ

Klassische Orchestrierer denken in Tasks: „führe Schritt A aus, dann B“. Dagster denkt in Assets – den Datenprodukten selbst: eine Tabelle, ein dbt-Modell, ein Dashboard. Du beschreibst, was existieren soll und woraus es abgeleitet ist. Reihenfolge, Lineage und Materialisierung leitet Dagster daraus ab.

Task-basiert (klassisch)

Du verdrahtest Schritte manuell. Was eine Tabelle befüllt, steht nirgends – Lineage ist Fleißarbeit im Nachhinein.

Asset-basiert (Dagster)

Du deklarierst Assets und ihre Abhängigkeiten. Der Graph ist die Doku, die Reihenfolge ergibt sich, Datenqualität ist prüfbar.

Ein Graph

Der ganze Stack in einem Lineage

dlt-Loader und dbt-Modelle werden zu Assets im selben Graph. Ende-zu-Ende-Sicht statt verstreuter Cronjobs.

Portabel

Compute von Storage entkoppelt

Über Resources und IO Manager sind Dev/Prod tauschbar und lokal lauffähig – passt zum perimeter-agnostischen Stack.

Observability

Katalog & Checks eingebaut

Asset-Katalog, Run-Logs, Metadaten und Asset Checks (Freshness, Qualität) sind Teil der Plattform, kein Add-on.

Deklarativ

Components als Brücke zum Spec

Mit Components + dg entstehen Assets aus YAML-Konfiguration – der natürliche Andockpunkt für die Use-Case-Spec-Idee.

02

Was ist Dagster

Definition-Ebene · System-Ebene

Ein Open-Source-Orchestrator für Data Assets. Du definierst Assets in Python und bündelst sie in einem Definitions-Objekt, das aus einer Code Location bereitgestellt wird (bei uns: der gRPC code-server). Zwei System-Dienste führen aus: der Daemon und der Webserver.

Dein Code

Definition-Ebene

AssetDatenprodukt (Tabelle, Modell) – ein Knoten im Graph.Asset CheckTest auf Qualität, Freshness oder Vollständigkeit.ResourceVerbindung zu externem System – Postgres, dbt, dlt.IO ManagerRegelt Lesen/Schreiben der Asset-Outputs.PartitionZeit-/Segment-Slice – ermöglicht inkrementelle Läufe & Backfills.JobAusführbare Auswahl von Assets.ScheduleCron-basierter Trigger.SensorEvent-Trigger – neue Datei, Run-Status, externer Zustand.ComponentDeklaratives Scaffolding (YAML) über Assets, z. B. DbtProjectComponent.DefinitionsTop-Level-Objekt – bündelt alles Obige.
Dagster-Dienste

System-Ebene

Code LocationBereitgestellte Definitions in eigener Python-Umgebung (gRPC code-server).DaemonFührt Schedules, Sensors, Run-Queue und Backfills aus.WebserverDie UI: Asset-Graph, Runs, Katalog, Logs.RunEine Ausführungsinstanz – ein einzelner Lauf.

Dagster trennt deinen Code sauber von den System-Werkzeugen. Dein Code beschreibt was; Daemon und Webserver kümmern sich um Ausführung und Beobachtung.

03

Wie ein Lauf abläuft

läuft · Endlosschleife

Ein Schedule feuert – der Daemon stellt einen Run in die Queue – Assets materialisieren in Abhängigkeitsreihenfolge; Resources werden injiziert, der IO Manager persistiert – der Webserver zeigt Lineage und Status live.

Scheduledaily_6am0 6 * * *
Sensorfile_arrivalevent
SystemDaemonRun-Queue
✓Asset · dltraw_finnhubsource
✓Asset · dltraw_orderssource
✓Asset · dbtstg_supplystaging
✓Asset · dbtfct_otifmart
✓Asset · dbtdim_suppliermart
✓Exposuremetabase_kpidashboard
Injizierte Resources
dlt · ingestdbt · transformpostgres · storeio_manager · persist
Webserver · Run-Ansicht
materialize_all#4821
Bereit
0 / 6 AssetsOTIF-Check ✓
Daten-AbhängigkeitTrigger / Steuerungmaterialisiertes Asset

“Der Aha kommt, wenn ich alles End-to-End durchspiele.”

— Prinzip · End-to-End vor Abstraktion