Reference Architecture

9 min

9. Juli 2026

Eine portable Open-Source Data Platform

Beratungsprojekte brauchen eine Datenplattform, die sich pro Engagement eigenständig aufsetzen lässt, unabhängig von der Kundeninfrastruktur – ohne Abstriche bei Sicherheit oder Engineering-Qualität. Hier ist die Referenzarchitektur, die das löst.

Referenzarchitektur

Auf eine Komponente klicken, um zum jeweiligen Deep Dive zu springen.

SECURITY OVERLAY

QuellenExt.API & Files

NutzerClientHTTPS

DatenflussSteuerung / OrchestrierungSecurity-Overlay

Dagster

Wer orchestriert die Pipeline?

Dagster verantwortet den kompletten Lebenszyklus jedes Assets in der Plattform – von der Roh-Ingestion bis zu den BI-fertigen Marts – als software-definierten, versionierten Code statt eines Geflechts aus Ad-hoc-Cron-Jobs.

Was es steuert:

Asset-Abhängigkeitsgraph über dlt & dbt

Schedules & Sensors

Run-Historie und Retries

Ein gRPC code-server pro Engagement

Warum hier

Vollständige Lineage statt HerrschaftswissenEin Ort, um zu sehen, was wann lief – und warum es fehlschlug

Deep Dive in Dagster

dlt

Wie gelangen Daten in die Plattform?

dlt übernimmt die Ingestion als deklarative Python-Loader – Schema-Erkennung, Normalisierung und inkrementelles Laden werden pro Quelle erledigt, ohne handgeschriebenes Boilerplate.

Was es übernimmt:

API-Quellen (z. B. Finnhub)

Flatfile-Quellen (CSV)

Schema-Evolution

Inkrementelles / merge-basiertes Laden nach raw

Warum hier

Neue Quellen in Stunden statt TagenKonsistentes raw-Schema unabhängig von der Quellstruktur

Deep Dive in dlt

PostgreSQL

Wo liegen die Daten?

Eine einzelne PostgreSQL-Instanz enthält zwei Schemata mit klar getrennter Verantwortung: raw als unangetastete Landing Zone und marts als modelliertes Ergebnis, das dbt veröffentlichen darf.

Trennung der Verantwortlichkeiten:

schema · raw — exakte Kopie der Quelldaten

schema · marts — von dbt modellierte, BI-fertige Tabellen

Keine direkten Schreibzugriffe auf marts außerhalb von dbt

Eine Engine, eine Backup-Strategie, ein zu betreibendes System

Warum hier

Kein versehentliches Auseinanderdriften von raw und modellierten DatenEin zu betreibendes Werkzeug statt Warehouse plus Lake

Deep Dive in PostgreSQL

dbt

Wie werden Rohdaten nutzbar gemacht?

dbt verantwortet jede Transformation als getestetes, dokumentiertes SQL – aus Rohdaten werden die Kennzahlen, nach denen Stakeholder tatsächlich fragen, etwa OTIF, Lead Time und Fill Rate.

Was es liefert:

Geschichtete Modelle (staging → intermediate → marts)

Automatisierte Tests auf jedem Modell

Automatisch generierte Dokumentation & Lineage-Graph

Business-Kennzahlen: OTIF, Lead Time, Fill Rate

Warum hier

Transformationen, die sich tatsächlich reviewen lassenFehlerhafte Logik lässt einen Test fehlschlagen, nicht ein Dashboard

Deep Dive in dbt

Metabase · pgweb

Wie nutzen Menschen das Ganze?

Zwei Zugriffs-Oberflächen bedienen zwei unterschiedliche Zielgruppen: Metabase für Dashboards und Self-Service-Fragen, pgweb für Engineers, die direkt in eine Tabelle schauen müssen.

Wer nutzt was:

Metabase — Dashboards & Ad-hoc-Fragen für Stakeholder

pgweb — leichtgewichtiger SQL-/Tabellen-Browser für Engineers

Beide lesen ausschließlich aus dem marts-Schema

Warum hier

Stakeholder bedienen sich selbst statt Tickets zu schreibenEngineers debuggen ohne separaten DB-Client

Deep Dive in Metabase

Caddy · Authentik

Wie ist der gesamte Stack abgesichert?

Security ist bewusst ein Overlay statt fest in jeden Service verdrahtet: Caddy ist der einzige Ingress, Authentik stellt davor das SSO bereit. Keines der beiden weiß etwas über Dagster, dbt oder Postgres.

Was es bereitstellt:

Einziger Ingress für jeden Service im Stack

SSO vor Metabase, pgweb & dem Dagster UI

TLS-Terminierung & automatische Zertifikate

Pro Engagement austauschbar, ohne den Core anzufassen

Warum hier

Ein Ort, um Zugriff zu gewähren oder zu entziehenDie Kernplattform bleibt über Kunden hinweg portabel

Deep Dive in authentik

Docker

Was führt das alles eigentlich aus?

Jede Komponente oben – Dagster, dlt, PostgreSQL, dbt, Metabase, pgweb, Caddy, Authentik – läuft isoliert in ihrem eigenen Container. Der ganze Stack ist als Code in einer Compose-Datei deklariert, pro Engagement klonbar.

Was es steuert:

Eine compose.yml für den ganzen Stack

Abhängigkeitsreihenfolge via depends_on & Healthchecks

Security über eine separate Override-Datei angeflanscht

Identisch auf dem Mac, auf Hetzner und beim Kunden

Warum hier

Kein „works on my machine“Ein Engagement klont sich als eine Datei, nicht als manuelle Setup-Checkliste

Deep Dive in Docker

“Security ist ein Overlay, nie im Core.”

— Architekturprinzip

DagsterdltdbtPostgreSQLMetabaseCaddyAuthentikReference Architecture