Architektur¶
Zielbild¶
Die Challenge eignet sich für eine modulare, schichtartige Architektur. Sie trennt Quellenanbindung, Verarbeitung, Speicherung, Analyse, Bereitstellung und Dokumentation sauber voneinander. Das erleichtert Nachvollziehbarkeit, Austauschbarkeit einzelner Komponenten und spätere Weiterentwicklung nach dem Hackathon.
Layered Architecture im Überblick¶
| Layer | Aufgabe | Typische Ergebnisse |
|---|---|---|
| Source Layer | Öffentliche Datenquellen, Dokumente und Services anbinden | Rohdaten, Metadaten, Quellreferenzen |
| Ingestion Layer | Abruf, Download, Connector-Logik und technische Erfassung | API-Antworten, Dateien, Snapshots |
| Raw Data Layer | Unveränderte Ablage der Quellartefakte | versionierte Originaldaten und Abrufprotokolle |
| Processing / ETL / ELT Layer | Parsing, Bereinigung, Normalisierung und Mapping | harmonisierte Datensätze und abgeleitete Merkmale |
| Storage Layer | strukturierte Ablage für Analyse und Wiederverwendung | relationale Tabellen, Geodaten, optionale Dokument- oder Vektorspeicher |
| Analytics & Intelligence Layer | Indikatoren, Trendkarten, Weak Signals und Evidenzlogik | berechnete Kennzahlen, Signale, Bewertungen |
| API Layer | standardisierte Bereitstellung für Frontend oder Drittsysteme | REST-Endpunkte, OpenAPI, Swagger UI |
| Presentation Layer | Dashboard, Web-App und Visualisierung | Karten, Zeitachsen, Indikatoren, Filter |
| Documentation Layer | technische und fachliche Nachvollziehbarkeit | Quelleninventar, Architektur, Reproduzierbarkeit |
Architekturprinzipien¶
- Modularität: jede Schicht soll austauschbar und separat testbar bleiben
- Quellentransparenz: jedes Ergebnis bleibt auf konkrete Quellen referenzierbar
- Versionierung: Rohdaten, Transformationslogik und Indikatoren sollen nachvollziehbar versioniert sein
- Reproduzierbarkeit: Doku, Schema und Zugriffslogik müssen nach dem Hackathon wiederverwendbar sein
- Kleiner Kern: lieber wenige tragfähige Komponenten als ein zu breiter Stack ohne Betriebsreife
Technologische Leitplanken¶
| Bereich | Künftige Hosted-/Server-Option | Datei-basierte MVP-Option |
|---|---|---|
| SQL-Datenbank | PostgreSQL | DuckDB oder SQLite |
| Geodatenbank | PostGIS | GeoParquet + DuckDB, oder später PostGIS |
| Dokument- oder NoSQL-Speicher | MongoDB | JSONL/Parquet + DuckDB, SQLite JSON oder TinyDB |
| Vector Store | ChromaDB Server/Cloud | ChromaDB Persistent Folder |
| Suche / Volltext | OpenSearch oder Elasticsearch | SQLite FTS5, DuckDB FTS, Whoosh oder Tantivy |
| Backend / API | FastAPI | FastAPI |
| Frontend | React oder Streamlit | React oder Streamlit |
| Dokumentation | MkDocs | MkDocs |
| API-Dokumentation | Swagger UI / OpenAPI | Swagger UI / OpenAPI |
Minimaler technischer Zuschnitt für ein MVP¶
Ein pragmatischer MVP kann bereits mit folgenden Bausteinen funktionieren:
- Connectoren für 4 öffentliche Quellen
- Rohdatenablage plus einfache Versionierung
- DuckDB, SQLite, Parquet und/oder ChromaDB als kostenlose dateibasierte Speicher im Curated-Data-Ordner
- PostgreSQL/PostGIS, MongoDB oder OpenSearch nur dann, wenn das Team später eine künftige Hosted-/Server-Infrastruktur wählt
- FastAPI für Daten- und Indikatorbereitstellung
- React- oder Streamlit-Frontend mit Karte und Zeitachse
- MkDocs für technische und fachliche Dokumentation
Pragmatischer Fokus
Nicht jede optionale Komponente muss im Hackathon umgesetzt werden. Entscheidend ist, dass der Gesamtfluss von der Quelle bis zur Visualisierung nachvollziehbar funktioniert.