Welche Tools kommen beim Nahverkehrs-Dashboard zum Einsatz
Wie im vorherigen Artikel beschrieben, werde ich ein Nahverkehrs-Dashboard bauen. Ziel ist es, eine Enterprise-Lösung im Kleinen zu bauen. Eine Lösung, die Features wie Verlässlichkeit, Transparenz, Sicherheit, Monitoring & Alerting enthalten soll, dabei aber auch von mir alleine bezahlt und gewartet werden kann.
Warum ich das mache und was genau ich vorhabe, kannst du im Artikel Warum ich ein Nahverkehr-Dashboard baue herausfinden.
Hier möchte ich erklären, womit das gemacht werden soll und welche Tools zum Einsatz kommen.
Disclaimer: Dies ist meine initiale Idee. Ich will nicht ausschließen, dass sich während der Entwicklung Entscheidungen ändern. Falls das passiert, werde ich diesen Artikel entsprechend aktualisieren.
Was kommt zum Einsatz?
Infrastruktur
Die Infrastruktur ist wesentlich und definiert die Möglichkeiten, die dem Gesamtsystem zur Verfügung stehen.
Ich habe mich dazu entschieden, Hetzners VPS zu nutzen. Deployed wird dann via Docker Compose. So habe ich ein kleines und leicht zu reproduzierendes Setup, das ich lokal zum Entwickeln oder in Production laufen lassen kann.
Jetzt stellen sicherlich einige die Frage, warum ein VPS? Ganz einfach: Aus meiner Sicht ist ein VPS günstiger und kostentransparenter als z. B. ein Kubernetes-Cluster oder die Cloud.
Hinzu kommt, dass das Deployment deutlich näher am Development Environment ist und somit deutlich einfacher zu warten ist.
Grafana nutze ich als Monitoring- und Alerting-System für meine Infrastruktur. Es passt perfekt zu meinem Gesamt-Setup und erlaubt es mir, alles im Blick zu behalten.
Data-Plattform
Die Datenplattform bildet die Schaltzentrale meines Projekts. Hier kommen alle wesentlichen Teile zusammen und bilden das System, das die Daten aus verschiedenen Quellen holt, prüft, aufbereitet und zur Verfügung stellt.
Orchestrator
Der Orchestrator dient als Integrator oder Vernetzer und organisiert Pipelines, verbindet Tools und macht all das sichtbar.
Für Dagster habe ich mich entschieden, da ich auch schon in der Vergangenheit Plattformen damit gebaut habe. Ich finde den Ansatz mit den Data-Assets großartig und das Framework bietet alle Möglichkeiten, die man von einem Orchestrator erwartet: Data-Quality-Checks, Data Observation, Monitoring & Alerting usw.
Compute
Die Compute-Ebene nutzt eine Engine, oft basierend auf SQL oder Python, um Daten so zu transformieren, wie es in der Transformationsebene definiert wurde.
Mit DuckDB wollte ich schon immer arbeiten. Es ist eine Column-based In-Memory-Datenbank und kann als das Gegenstück zu SQLite im Datenbereich betrachtet werden. Ich finde besonders spannend, dass DuckDB direkt mit Files umgehen kann, und die Integration mit dbt scheint ebenfalls sehr gut zu sein.
Der Einsatz von DuckDB, um eine Enterprise-Datenplattform zu betreiben, ist eher unüblich. Meiner Meinung nach spielt es seine Stärken in solchen Szenarien eher als eine Art Hybridlösung aus. So ist es denkbar, dass im Produktivsystem z. B. Snowflake zum Einsatz kommt, für die lokale Entwicklung aber DuckDB.
Da mein System aber eher klein ist und sein soll, ist es aber ein passender Use Case, sodass DuckDB auch im kompletten Lifecycle zum Einsatz kommen kann.
Transformation, Testing & Dokumentation
dbt kommt in der Plattform als Transformations-Layer zum Einsatz. Es ist die Schnittstelle zwischen Dagster und DuckDB und ermöglicht es, Daten so auf- und vorzubereiten, dass sie zur Auswertung und Präsentation genutzt werden können.
Besonders spannend finde ich, dass es plattformagnostisch ist. Theoretisch ließen sich so leicht unterschiedliche Warehouses nutzen, ohne dass man die Transformationen anpassen muss.
Praktisch ließe sich meine Plattform auch ohne dbt direkt mit Dagster-Data-Assets betreiben. Meiner Erfahrung nach funktioniert das aber nur am Anfang sehr gut und irgendwann fragt man sich, warum man nicht direkt auf dbt gesetzt hat. Stichwort: Testing, Dokumentation & Templating.
Kosten
Neben allen genannten Punkten für die Tools kommt noch ein wesentlicher hinzu. All diese Tools können in meiner Infrastruktur selbst gehostet werden.
Das bedeutet, dass ich nicht durch plötzlich explodierende Cloud-Rechnungen überrascht werde. Es bedeutet keine externen Abhängigkeiten und ein System komplett in meiner Hand.
Das heißt aber auch, dass mein Gesamtsystem komplexer und mein persönlicher Aufwand größer ist. Aber diesen Trade-off nehme ich für die geringeren Kosten und die gewonnene Kostentransparenz gerne in Kauf.
Frontend & Dashboarding - Astro
Und zum Schluss das Dashboard.
Ich habe mich ganz bewusst gegen BI-Tools wie Power BI, Tableau oder Metabase entschieden.
- Mache ich keine BI.
- Erstelle ich ein individuelles Datenprodukt.
Mein Ziel ist es, ein End-to-End-System mit einem coolen Dashboard am Ende zu haben. Dieses Produkt möchte ich nach meinen Vorstellungen gestalten können und keine Kompromisse eingehen.
Meiner Erfahrung nach stehen mir BI-Tools, wenn es nicht um BI geht, für solche individuellen Lösungen eher im Weg, als dass sie mich unterstützen.
Das ist meine ganz persönliche Einschätzung und ich verstehe, wenn das nicht alle so sehen. 🙂
Für Astro habe ich mich entschieden, da ich eine statische Lösung präferiere. Anstatt zusätzlich eine API zu schaffen, die dann noch mit dem Frontend kommunizieren muss, möchte ich es bewusst schlank halten. Außerdem finde ich das Templating-System, das Astro bietet, ziemlich gut.
Aus meiner Sicht ist diese Lösung nicht nur schlank, sondern hält auch die Anforderungen an das Backend gering.
That’s it
Und das ist es, das sind die Tools, die für meine Data-Plattform zum Einsatz kommen. Ich hoffe, meine Entscheidungen können nachvollzogen werden, auch wenn der eine oder die andere eine andere Entscheidung treffen würde.
Ich jedenfalls freue mich darauf, herauszufinden, wie die bekannten und unbekannten Tools zusammenarbeiten und ob mein aktueller Plan sich so umsetzen lässt.
Für mich geht es als Nächstes an die Implementierung.
Auf diesem Blog werde ich als Nächstes die Architektur der Plattform näher beleuchten. Dann werde ich die Frage beantworten, wie all die von mir genannten Tools und Systeme zusammenspielen sollen.