Zielarchitektur¶
Diese Seite zeigt die Zielarchitektur der Open Data Infrastruktur (ODI) als kompakte Gesamtübersicht: links die Datenquellen, rechts die Nutzer, dazwischen die fachlichen Stacks im Verwaltungskontext und darunter die Cloud-Infrastruktur.
Die ODI wird von Dataport für das Land Schleswig-Holstein entwickelt, läuft auf Managed Kubernetes bei IONOS und ist als Open Source auf openCode veröffentlicht.
Zwei Darstellungen – zum Vergleich
Über die Tabs lässt sich zwischen einer technischen Sicht (mit Produktnamen) und einer fachlichen Sicht (ohne Produktnamen) umschalten. Ein Klick auf das Diagramm öffnet es groß und zoombar.
Der Datenfluss in Kürze¶
- Annahme. Daten von außen (Fachverfahren, Fachportale, Dateien, Geodaten, Mobilitätsdaten, IoT-Sensoren) gelangen über das Staging in die Plattform. Davor prüft die Daten-Governance (Apache Ranger), welcher Benutzer bzw. Client welchen Datensatz veröffentlichen darf.
- Verteilung. Das Staging validiert die Daten und verteilt sie an drei Veröffentlichungs-Stacks: Geo-, Semantic- (Linked Open Data) und Datenkatalog-Stack.
- Echtzeitdaten (IoT). Der Dynamic-Data-Stack nimmt Sensordaten entgegen (FROST SensorThings-API und MQTT), speichert sie selbst und liefert zusätzlich an den Datenkatalog-Stack.
- Bereitstellung. Über ein zentrales API-Gateway (Traefik) stehen den Nutzern mehrere Schnittstellen bereit: die Open-Data-/DCAT-AP-API (Portal-Download & -Upload), die neue Data API (zeilenbasierte Abfrage & Inhaltssuche), der SPARQL-Endpoint, Geodienste (WFS/WMS) und die Real-Time API (SensorThings · MQTT) – u. a. genutzt über das neue Frontend ODW (Open Data Web).
- Visualisierung. Der eigenständige Visualization-Stack liest Daten aus dem Datenkatalog-Stack und stellt sie als einbettbare Web Components (Diagramme, Karten) dar (nutzt ebenfalls die Identitätsverwaltung).
Bausteine¶
| Stack (Namespace) | Aufgabe | Wesentliche Komponenten |
|---|---|---|
Staging (odi-staging) |
Annahme, Qualitätssicherung, Verteilung | staging-backend, frictionless, metadata-service, ckan-service, ckan-harvester |
Schema-Repository (odi-schema-repo) |
Datenstrukturen (Frictionless), versioniert | schema-repo-backend/-frontend, Redis |
Geo (odi-udp) |
Geodaten als Dienste & Karten | GeoServer, Masterportal, UDP-Manager, PostGIS |
Semantic (odi-triple-*) |
Linked Open Data | Triple-Converter, Apache Jena Fuseki (Triple Store), SPARQL-Frontend |
| Datenkatalog | Zentraler Datenkatalog & Portal | DCAT-AP-Service (CKAN-Service), CKAN-Datenkatalog (ggf. Piveau) |
Dynamic Data / IoT (odi-dynamic-data) |
Echtzeit-/Sensordaten | FROST-Server (SensorThings), MQTT, sensorthings-backend/-webapp |
Visualization (odi-visualization) |
Diagramme aus Katalogdaten | visualization-backend/-frontend |
| ODW – Open Data Web | Neues Frontend der Infrastruktur | Microfrontends (Suche, Datenansichten, Karten/Diagramme, API-Beispiele) |
Governance & Identität¶
- Identitätsverwaltung (Keycloak). Ein eigener ODI-Keycloak, der per Föderation an einen Dataport Identity Provider (ebenfalls Keycloak) angebunden ist – darüber melden sich Mitarbeitende der Verwaltung an. Alle Stacks (inkl. Visualization) nutzen die Identitätsverwaltung.
- Daten-Governance (Apache Ranger). Liegt vor der Staging-API und entscheidet, welcher Benutzer/Client welchen Datensatz veröffentlichen darf.
Betrieb & Infrastruktur¶
- Cloud: Managed Kubernetes, Managed PostgreSQL-Cluster, Managed S3-Objektspeicher und NFS-Dateispeicher bei IONOS – statt selbst betriebener Datenbanken/Objektspeicher.
- Edge: API-Gateway (Traefik) als zentraler Zugang zu den APIs (geplant), Ingress (NGINX).
- Betrieb: Monitoring/Logging (Grafana, Loki, Promtail), TLS (cert-manager / Let’s Encrypt).
- Quellcode & Auslieferung: öffentlich auf openCode inklusive CI/CD (GitOps via FluxCD).
- Test-Automatisierung: eigener Bestand automatisierter Tests (
automated-tests).
Ziel- vs. Ist-Stand
Die Übersicht zeigt die Zielarchitektur. Einige Elemente sind neu bzw. im Aufbau – etwa das Frontend ODW, das API-Gateway (Traefik) und die Apache-Ranger-Governance vor der Staging-API – und in der aktuellen produktiven Cluster-Konfiguration noch nicht vollständig abgebildet.
Weiterführend¶
- Architektur – Übersicht Staging – Detailsicht auf das Staging-Backend und seine Fachdienste
- Hauptprozess: Datensatz hochladen (CSV) – fachlicher Ablauf
- API-Referenz – die REST-Schnittstellen im Detail