Datenfluss
Technische Umsetzung
Daten, die von außen über externe Datenquellen in die Plattform gelangen, durchlaufen Datenpipelines mit folgenden Stufen:
Die nachfolgende Grafik zeigt die verwendeten Komponenten, die bei der Umsetzung des Datenflusses zum Einsatz kommen.
Für die Ende-zu-Ende-Sicht von der Rohdatenquelle bis zu Datenprodukten, APIs und Open Data kann die Verarbeitung auch wie folgt gelesen werden:
Ergänzend zeigt die folgende Skizze typische Integrationswege zwischen kommunalen Netzen, Quellsystemen und der Plattform:
Datenintegration
Eingangsseitig unterscheidet die UDSP drei grundlegende Integrationsmuster:
Aktive Datenquellen liefern Daten eigeninitiativ per HTTP-POST an die API, per Webhook oder per S3-PUT in den zentralen Storage.
Passive Datenquellen werden von der Plattform angesteuert, etwa externe REST-APIs zyklisch per HTTP-GET oder interne Systeme über definierte Abrufmechanismen.
Manuelle Bereitstellung: Ergänzend können Datenlieferanten Dateien manuell per Web-Upload, per CKAN-API oder über S3-kompatible Upload-Wege bereitstellen.
Direkte API-Einspeisung: Für bestimmte Use Cases können Clients Entitäten direkt via NGSI-LD in den Context Broker oder Messreihen via SensorThings in FROST schreiben. Dieses Muster eignet sich insbesondere dann, wenn die Quelle bereits standardkonform publiziert und keine vorgelagerte Harmonisierung erforderlich ist.
Für die Anbindung konkreter Fachdatenquellen stehen in der Urban ETL-Toolbox vorgefertigte Data-Connector-Nodes für Node-RED bereit, die typische Smart-City-Domänen abdecken:
- Wetter und Umwelt: DWD-Wetterdaten und -Warnungen, UV-Index (OpenUV), Feinstaub- und Luftqualitätsdaten (Luftdaten), Pegelstände (Pegelonline), Erdbebenereignisse
- Mobilität: Ladeinfrastruktur (OpenChargeMap), Bike- und Scooter-Sharing (GBFS), öffentlicher Nahverkehr (GTFS, statisch und in Echtzeit)
- Points of Interest und Geodaten: Open Data Germany, OpenStreetMap via Overpass-API
- Informationsfeeds: RSS/Atom-Feeds aus beliebigen Quellen
Neue Datenquellen aus diesen Domänen werden dadurch typischerweise durch Konfiguration statt durch Neuentwicklung angebunden. Für Quellen außerhalb dieser Kategorien stehen generische Protokoll-Nodes wie MQTT, HTTP, REST, S3 und Datei-Upload zur Verfügung, die dieselbe Anbindungslogik erlauben.
Die Anbindung einer neuen Quelle folgt im Regelfall einem standardisierten Vorgehen:
- Quellanalyse und Festlegung des Integrationsmusters
- Auswahl oder Konfiguration eines Konnektors
- Mapping auf das Zielmodell
- Test und Validierung in Staging
- kontrollierte Produktivsetzung
Zentrales Werkzeug ist Node-RED als Urban ETL-Toolbox. Dort werden eingehende Rohdaten normalisiert, transformiert, validiert und angereichert. Strukturierte Echtzeitdaten werden an den Context Broker übergeben, der Änderungen per Publish/Subscribe an nachgelagerte Dienste verteilt.
Um Integrationen mit Massendaten effizient zu verarbeiten, werden in diesen Fällen die Daten zunächst in der PostgreSQL-Datenbank abgelegt und anschließend aggregiert. Dies ist performanter, als die Daten direkt in den FIWARE Context Broker zu senden und ermöglicht einen höheren Durchsatz. Periodisch werden aus den Rohdaten veredelte Datenprodukte erstellt (z. B. aus einzelnen Verkehrszählungen werden 15-minütige Aggregate), die dann in den Context Broker gespielt werden, um für die NGSI-LD-Schnittstelle bereitzustehen.
Datenverarbeitung
Die aus den Konnektoren eingehenden Rohdaten durchlaufen anschließend die Verarbeitungskette der Urban ETL-Toolbox. Hier kommen Data-Operations-Nodes zum Einsatz, die insbesondere die Überführung in NGSI-LD-Entitäten standardisieren: Der ngsi-builder konstruiert aus eingehenden Nachrichten Smart-Data-Model-konforme Entitäten, der post-to-stellio-Node publiziert diese an den Context Broker, und über dedizierte Nodes lassen sich NGSI-LD-Subscriptions anlegen, auslesen und löschen. Ergänzend übernehmen Node-RED-Standard-Nodes die typischen ETL-Aufgaben wie Normalisierung von Zeitstempeln und Einheiten, Bereinigung, Validierung und Anreicherung um Kontextinformationen.
Für Querschnittsaufgaben stellt die Toolbox zusätzlich Utility-Nodes bereit – etwa den location-group-Node, der eingehende Datenpunkte auf Basis von Turf.js und Nominatim nach Radius oder administrativer Fläche gruppiert, oder den mqtt-debug-Node für die Inspektion von MQTT-Payloads während der Entwicklung.
Node-RED dient dabei als Orchestrierungsumgebung für diese Toolbox und bildet die Rolle der Urban ETL-Toolbox in der Pipeline ab – von der Rohdatenstufe über die Informationsstufe bis zur Erzeugung aggregierter Datensätze.
Qualitätssicherung in der Verarbeitung
Die Qualitätssicherung ist Teil jeder Integrationsstrecke und erfolgt typischerweise in mehreren Schritten:
- strukturelle Validierung von Pflichtfeldern, Datentypen, Einheiten und Zeitstempeln
- fachliche Plausibilisierung über konfigurierbare Regeln für Wertebereiche, Ausreißer und Dubletten
- definierte Fehlerpfade für nicht valide Datensätze statt stillschweigendem Verwerfen
- Monitoring der Liefertreue und Aktualität je Quelle als betriebliche Qualitätskennzahl
Damit bleibt sichtbar, mit welcher Aktualität und Qualität Daten in der Plattform vorliegen.
Die fachlich-technische Sicht auf diese Überwachung ist im Abschnitt Datenmonitoring beschrieben.
Datenspeicherung
Die aufbereiteten Daten werden zunächst in PostgreSQL (mit TimescaleDB- und PostGIS-Erweiterung) persistiert, das als zentrale Persistenzschicht fungiert. TimescaleDB sorgt für die effiziente Speicherung und Abfrage von Zeitreihen, PostGIS für den Raumbezug. Rohdateien, die nicht in eine relationale Struktur überführt werden, landen im zentralen S3-Storage. Von PostgreSQL aus werden gezielt diejenigen Datensätze nach Stellio übernommen, die als standardisierte NGSI-LD-Entitäten über die API bereitgestellt werden sollen. Stellio stellt damit die kuratierte, semantisch modellierte API-Schicht für die nach außen publizierten Datensätze dar, während PostgreSQL alle eingehenden und verdichteten Daten verlustfrei vorhält – unabhängig davon, ob sie extern exponiert werden oder nur intern für Analysen und Dashboards dienen.
Datenbereitstellung
Für die Bereitstellung nach außen werden mehrere Kanäle kombiniert. Geodaten werden über GeoServer als standardisierte OGC-Dienste wie WMS oder WFS ausgeliefert und unter anderem vom Masterportal als Geoportal konsumiert. Analysen und Visualisierungen erfolgen über Grafana und Apache Superset als nativ eingebettete Plattformkomponenten, die direkt auf PostgreSQL zugreifen.
Der programmatische Zugriff externer Datenkonsumenten – mobile Apps, Fachsoftware und externe Dashboards – erfolgt über die zentrale API-Schicht Apache APISIX. Sie übernimmt Authentifizierung, Autorisierung, Routing und die kontrollierte Exponierung von NGSI-LD-, OGC- und weiteren REST-Schnittstellen. Darüber lassen sich auch externe Pflichtschnittstellen oder standardisierte Datenausleitungen an bestehende IT-Infrastrukturen umsetzen.