Wie spielen all die Tools in meiner VBN Data Platform zusammen?
Durch verschiedene Themen, die eine höhere Priorität in meinem Alltag eingenommen haben, konnte ich mich leider nicht mehr dem VBN-Projekt widmen. Das ändert sich jetzt aber, da ich wieder etwas mehr Zeit habe.
Schauen wir uns also an, wie all die Tools aus dem letzten Artikel zusammenspielen.
Wie sieht die Pipeline eigentlich aus?
Damit wir besser verstehen, welche Teile wie und warum zusammengesteckt werden, müssen wir uns erst einmal darum kümmern, wie unsere Pipeline eigentlich aussehen soll.
Dafür schauen wir uns an, was wir eigentlich haben.
(A) Quelldaten
|
v
(B) Datenmodelle zum Auswerten
|
v
(C) ReportsJetzt müssen wir uns überlegen, wie wir die Zwischenschritte füllen. Wie kommen wir also von A zu B und dann zu C?
Grob sieht das so aus:
Quelldaten speichern
|
v
gespeicherte Quelldaten aufbereiten & validieren
|
v
aufbereitete Daten transformieren & testen
|
v
Reports aktualisierenJetzt wissen wir, was wir brauchen und wie wir zu den jeweiligen Punkten kommen. Bleibt die Frage, womit wir das umsetzen.
Unser Tooling kommt zum Einsatz
Hier noch einmal die Übersicht der Tools, die zum Einsatz kommen:
- Dagster als Orchestrator und Execution Platform
- DuckDB als SQL Engine
- dbt für Transformation, Dokumentation und Testing
- astro für das Reporting (Web-App)
Jedes dieser Tools übernimmt eine bestimmte Aufgabe in der Pipeline. Dagster spielt dabei eine spezielle Rolle, da es unser zentrales Fenster in die Pipeline ist und alle Tools miteinander verbindet.
Dagster liegt somit über allem und die anderen Tools werden für die jeweiligen Schritte integriert.
Das Reporting in astro ist übrigens nicht Teil von Dagster. Dagster initiiert lediglich die Aktualisierung des Reports in astro.
Das Ganze sieht visuell so aus:
+---------------------------------------+
| 🚀 **Dagster** (Orchestrator) |
| |
| +---------------------------------+ |
| | Asset 1 Quelldaten speichern | |
| +---------------------------------+ |
| | |
| v |
| +---------------------------------+ |
| | Asset 2 Quelldaten aufbereiten | |
| +---------------------------------+ |
| | |
| v |
| +---------------------------------+ |
| | **dbt** Transformieren & Testen | |
| +---------------------------------+ |
+---------------------------------------+
|
| Trigger / Refresh
v
+---------------------------------------+
| 📊 **astro** (Reporting & Web-App) |
| (Unabhängig: Stellt Reports bereit) |
+---------------------------------------+Was noch fehlt
Jetzt fehlen uns nur noch DuckDB und ein Plan zur Ausführung.
DuckDB wird als Tool direkt von Dagster und dbt genutzt. dbt bietet einen eigenen Community Connector, den man einfach konfigurieren muss.
In Dagster kann man direkt das DuckDB-Package nutzen oder eine Resource erstellen. Da unsere Pipeline noch sehr klein ist, verzichten wir zu Beginn auf die Dagster Resource.
Damit ist der DuckDB-Part erledigt. Wie lassen wir die Pipeline nun aber laufen?
Auch hier hilft uns Dagster mit Jobs und Schedules. Damit lassen sich zeitgesteuerte Aktionen ausführen und genau das wollen wir.
In unserem Fall erstellen wir drei Jobs mit jeweils einem Schedule:
- Extract & Save Raw Realtime Data (jede Minute)
- Extract & Save Raw Static Data (jeden Tag)
- Update Data Models & Reports (jede Stunde)
Was diese Jobs im Detail machen, führe ich später noch genauer aus. Sie sorgen dafür, dass die zu Beginn definierten Teile regelmäßig laufen.
Damit wird auch sichergestellt, dass die Pipeline stoppt, wenn Daten nicht valide sind oder Datentests fehlschlagen. Mit konfiguriertem Alerting können wir Benachrichtigungen rausschicken oder das astro-Projekt mit einem Hinweis auf veraltete Daten aktualisieren.
Je nach Anforderung lassen sich hier flexibel auch andere Verhaltensweisen abbilden.
Das ist im Wesentlichen die Architektur der Plattform und Pipeline. Von hier an kümmere ich mich um die Implementierung. Künftige Blog-Updates werden entsprechende Artikel zu den Implementierungen enthalten, die dann auch mal etwas kürzer ausfallen können.
Bis dahin Happy Coding!