Wie wir Wetterdaten in Echtzeit auf die Karte bringen
Wir befinden uns aktuell in der geschlossenen Invite-only-Phase für den meteoCORE Navigator. Das Feedback der ersten Tester ist überwältigend – und eine Frage taucht dabei immer wieder auf: „Wie gelingt es Ihnen eigentlich, dass die Karten sich so extrem flüssig anfühlen und bei Gewitterlagen nicht in die Knie gehen?“
Wetterdaten sind riesig und komplex. Wenn ein globaler oder lokaler Modelllauf aktualisiert wird, sprechen wir von gigantischen Datenpaketen. In der Meteorologie – speziell bei kritischen Entscheidungen für Kommunen oder Einsatzkräfte – zählt jedoch jede Minute.
Wir haben uns deshalb bewusst gegen klassische, starre IT-Architekturen entschieden und den meteoCORE Navigator sowie das dahinter liegende Backend von Grund auf für maximale Geschwindigkeit und digitale Souveränität gebaut.
Hier ist ein kleiner Blick unter die Haube unseres Maschinenraums.
Zweigleisige Speicherung: Der richtige Speicher für das richtige Format
Der größte Fehler in klassischen Systemen ist es, alle Wetterdaten in dieselbe Datenbank zu pressen. Wir trennen strikt nach der Art der Daten:
- Für Punkte und Polygone: Schnelle Ingest-Datenbanken Wenn Live-Messwerte von Wetterstationen (Punktdaten) oder neue Unwetterwarnungen (Polygone) eintreffen, übernehmen hochspezialisierte räumliche Datenbanken. Sie fungieren als extrem schneller Trichter. Ihre einzige Aufgabe: Diese Flut an punktuellen und vektorbasierten Daten in Millisekunden aufzusaugen und für die Karte und für den Versand von Mitteilungen bereitzustellen.
- Für Rasterdaten und Vorhersagen: Cloud-nativer Zarr-Storage Wettermodelle (wie Temperatur, Wind oder Radar) sind gigantische, multidimensionale Raster. Möchten Sie wissen, wie das Wetter an Ihrem genauen Standort in den nächsten 48 Stunden wird, müsste ein klassisches System hunderte riesige Kartendateien durchsuchen. Das ist zu langsam. Wir transformieren unsere Rasterdaten deshalb kontinuierlich in das Zarr-Format. Zarr zerlegt diese massiven Datenwürfel so intelligent, dass unser System die Vorhersage-Zeitserie für exakt Ihren Ort wie mit einer Nadel aus dem Heuhaufen stechen kann. Das Ergebnis: Lokale Vorhersagen laden ohne spürbare Verzögerung.
Der intelligente Dirigent: Dynamische Queuing-Systeme
Damit diese Datenmengen überhaupt reibungslos im Speicher landen, greift unser Queuing-System. Das Wetter ist unvorhersehbar, und genauso dynamisch ist die Last auf unseren Servern. Die Queue funktioniert als Puffer und Verteiler. Selbst wenn extrem viele Daten auf einmal verarbeitet werden müssen, geht nichts verloren. Die Queue teilt die Datenberge auf und dirigiert sie an die nächste Station.
Eine Armee von Spezialisten: Parallele Go-Worker
Anstatt die Datenpakete nacheinander abzuarbeiten, stürzen sich unzählige parallele „Worker“ – geschrieben in der hochperformanten Programmiersprache Go – gleichzeitig auf die Arbeit. Während ältere Systeme oft einen großen Prozess starten, der schnell zum Flaschenhals wird, skalieren unsere Go-Worker die Verarbeitung auf ein Maximum. Das reduziert die Zeit vom Rohdatum zum fertigen Datensatz drastisch.
Hierarchische Microservices statt monolithischer Blöcke
Der gesamte Navigator besteht unter der Haube nicht aus einem riesigen Software-Block, sondern aus einer Hierarchie vieler kleiner, spezialisierter Dienste (Microservices). Einer kümmert sich nur um den Ingest der Stationsdaten, ein anderer nur um die Zarr-Konvertierung, wieder ein anderer nur um das Ausliefern der Karten-Kacheln. Der große Vorteil: Wenn bei einer Gewitterlage plötzlich tausende Zugriffe auf das aktuelle Radar prasseln, skaliert unsere Architektur gezielt nur diesen einen Microservice hoch. Der Rest der Infrastruktur läuft unbeeindruckt und flüssig weiter.
Python & intelligentes Caching für On-the-fly-Rendering
Ein weiterer Schlüssel für flüssige Live-Ansichten ist unser On-the-fly-Rendering. Anstatt jede mögliche Karte im Vorfeld starr und zeitaufwendig durchzurechnen, generieren wir viele Ansichten exakt in dem Moment, in dem sie angefragt werden. Hierbei setzen wir auf „Polyglot Programming“ – wir nutzen die beste Sprache für die jeweilige Aufgabe: Während Go unsere Datenströme dirigiert, übernehmen spezialisierte Python-Microservices das eigentliche Rendering. Das Python-Ökosystem ist in der wissenschaftlichen Geodaten-Verarbeitung unübertroffen und nimmt uns durch extrem performante, auf C basierende Bibliotheken komplexe Bildberechnungen und Projektionen ab. Damit diese dynamischen Berechnungen bei vielen Zugriffen nicht zum Flaschenhals werden, haben wir ein mehrstufiges Caching-System etabliert. Häufig abgerufene Kartenausschnitte werden in rasend schnellen Zwischenspeichern vorgehalten. Das schont die Rechenleistung und liefert Ihnen sofortige Ergebnisse.
Das Echtzeit-Erlebnis: Push statt Poll
Der vielleicht wichtigste Paradigmenwechsel für das flüssige Nutzererlebnis: Klassischerweise fragen Browser alle paar Sekunden beim Server nach: „Gibt es neue Daten?“ (Polling). Das erzeugt unnötige Netzwerklast und hinkt der Realität immer hinterher. Wir haben die Architektur auf ein Push-Prinzip umgestellt. Sobald unsere Systeme einen neuen Datensatz verarbeitet haben, wird dieses Update aktiv vom Server an die geöffneten Browserfenster geschoben. Die Karte aktualisiert sich nahtlos in dem Moment, in dem die Information physisch bei uns vorliegt – ohne Wartezeiten, ohne manuelles Neuladen der Seite.
Fazit: Maximale Flexibilität und digitale Souveränität
All diese Rädchen greifen nahtlos ineinander, um das komplexe Thema Wetter so schnell und intuitiv wie möglich nutzbar zu machen. Ein wesentliches Merkmal unserer Architektur haben wir uns dabei für den Schluss aufgehoben: die strikte technologische Trennung zwischen dem nutzbaren Frontend (dem meteoCORE Navigator) und unserer Datenbereitstellung (der meteoCORE-API) sowie den Push/Queueing-Diensten.
Diese konsequente Entkopplung ist weit mehr als nur modernes Software-Design – sie ist ein entscheidender Flexibilitäts-Vorteil für Sie. Bei besonders strengen IT-Richtlinien oder in geschlossenen Behörden- und KRITIS-Netzwerken erlaubt dieses Design, das Frontend auf Wunsch vollständig „on-premise“ in der eigenen Infrastruktur zu hosten und zu betreiben.
Passend dazu liegt uns das Thema digitale Souveränität auch bei unseren eigenen Systemen am Herzen: Unsere gesamte Backend-Architektur läuft völlig autark auf europäischen Servern – ohne Vendor-Lock-in bei großen US-Cloud-Anbietern.
Wir freuen uns darauf, diese Kapazitäten in den kommenden Wochen gemeinsam mit unseren ersten Testern weiter auszuloten!