Im ersten Teil haben wir cloud-native Geodatenformate kritisch eingeordnet: Was können sie, wo liegen die Grenzen, und wann lohnt sich der Einsatz? Heute wird es konkret. In diesem Beitrag zeigen wir, wie wir InSAR-Daten mit COG, PMTiles, Parquet und DuckDB in die Gemeinsame Informationsplattform Naturgefahren (GIN) integriert haben – inklusive der Stolperfallen, denen wir dabei ausweichen mussten.
Die Ausgangslage: Millionen Messpunkte für eine bestehende Plattform
Die GIN ist die zentrale Informationsplattform für Naturgefahren in der Schweiz. Fachleute von Bund, Kantonen und Gemeinden nutzen sie, um Wetter-, Pegel-, Abfluss- und weitere naturgefahrenrelevante Messdaten in einer Kartenapplikation zu kombinieren – oft unter erheblichem Zeitdruck. Die Plattform wird gemeinsam von Bundesamt für Umwelt BAFU, MeteoSchweiz, dem WSL-Institut für Schnee- und Lawinenforschung SLF und dem Schweizerischen Erdbebendienst SED betrieben und umfasst über 100 Messgrössen von mehr als 700 automatischen Messstationen.
Neu sollten auch sogenannte InSAR-Daten integriert werden. Das sind satellitengestützt erhobene Daten, welche Bodenbewegungen in der ganzen Schweiz messen können. Das wiederum ist relevant für die Früherkennung von Rutschungen und anderen Massenbewegungen.
Exkurs: Was ist InSAR?
«InSAR» steht für Interferometric Synthetic Aperture Radar. Dabei werden Radar«bilder» satellitengestützt mit einem aktiven Radar mit sogenannter synthetischer Apertur (SAR) zu verschiedenen Zeitpunkten aufgenommen und anschliessend interferometrisch miteinander verglichen. Aus den ermittelten Unterschieden in der Phase der von der Erdoberfläche reflektierten Radarwellen lassen sich aus der Erdumlaufbahn der oder des Satelliten (z.B. der europäischen Sentinel-1-Konstellation) zwischen den Aufnahmen aufgetretetene Bodenbewegungen im Millimeterbereich (!) ableiten – und zwar flächendeckend und, dank der Funktionsweise im Radar-Spektrum, bei jedem Wetter und auch bei Nacht.
Das Resultat sind Millionen von Messpunkten (persistent scatterers), die jeweils eine Zeitreihe von Bewegungsmessungen enthalten: Pro Satellitenüberflug ein Messwert, über Jahre hinweg. Zusätzlich lassen sich aggregierte Produkte ableiten, die einzelne Punkte zu Gebieten relativ homogener Bewegung zusammenfassen. Im Kontext der GIN dienen diese InSAR-Daten der Überwachung von Hanginstabilitäten und Bodensenkungen in der Schweiz.
Die Herausforderung: Die InSAR-Daten umfassen je nach Produkt zwischen 30 MB und 25 GB, verteilt auf 7 verschiedene Datensätze (4 Produkte, teils mit Untergruppen für aufsteigende (von Süden nach Norden) und absteigende (von Norden nach Süden) Satellitenbahnen). Jeder Messpunkt enthält nicht nur eine Position, sondern eine vollständige Zeitreihe mit Dutzenden bis Hunderten von Messwerten. Das sind in Summe Millionen von Geometrien mit einer enormen Menge an Attributdaten – und das Datenvolumen wächst jährlich, da jedes Jahr weitere Messungen zur bestehenden Zeitreihe hinzukommen.
Warum nicht einfach PostgreSQL?
Die naheliegende Frage: Warum nicht den bewährten Weg für das Hosting von umfangreichen räumlichen Daten gehen? Alle anderen Datensätze auf GIN werden über spezialisierte Transformer aufbereitet und in eine PostgreSQL-Datenbank importiert, von wo sie über eine REST-API zur Applikation ausgeliefert werden. Dieser Ansatz ist erprobt, performant (dank Indizes) und gut verstanden.
Für die InSAR-Daten scheitert dieser Ansatz aber an zwei Stellen gleichzeitig:
- Erstens auf der Geovisualisierungs-Seite: Millionen von Punkten über die bestehende REST-API an den Karten-Client auszuliefern ist schlicht nicht performant – die API und die dahinterliegende Architektur sind dafür nicht ausgelegt. Zudem ist die Konversion von GeoJSON-Objekten im Frontend mit OpenLayers ineffizient und führt zu Performanceproblemen.
- Zweitens auf der Daten-Seite: Millionen von Punkten mit jeweils Hunderten von Messwerten über komplexe Import-Pipelines in die Datenbank zu laden – bei einem Datenvolumen von bis zu 25 GB pro Datensatz – wäre schon initial aufwendig. Noch schwieriger wäre das jährliche Update: Da die InSAR-Daten komplett ersetzt werden (auch die IDs ändern sich), müssten bei jedem Update sowohl die Geovisualisierung als auch die Rohdaten synchron ausgetauscht werden. Das heisst: Selbst wenn man «nur» die Datenbereitstellung über PostgreSQL löst, bräuchte man für die Kartenvisualisierung trotzdem einen eigenen Weg – und müsste dann beide Wege synchron halten.
Die Entscheidung für Cloud-Native
Im ersten Blogpost zum Thema haben wir geschrieben, dass die Nutzung des cloud-native geospatial-Paradigmas dort Sinn macht, wo bestimmte Voraussetzungen erfüllt sind. Bei den InSAR-Daten trafen gleich mehrere dieser Kriterien zu und der cloud-native Ansatz löst gleichzeitig das Synchronisationsproblem: Die Grundlagen der Geovisualisierung (COG, PMTiles) und die Rohdaten (Parquet) sind eigenständige Dateien, die unabhängig voneinander erzeugt und bei einem Update einfach komplett ersetzt werden können. Kein komplexer Transformer, keine Synchronisation, kein koordinierter Datenbankimport. Im Einzelnen präsentieren sich die cloud-native Kriterien vom letzten Blogpost wie folgt:
- Die Daten sind statisch und ändern sich selten. InSAR-Daten werden jährlich aktualisiert, und zwar als vollständiger Ersatz – es gibt keine inkrementellen Updates. Genau dieses Muster – write once, read many – ist die Parade-Disziplin cloud-nativer Formate.
- Die Datenmenge übersteigt das, was über klassische APIs sinnvoll ausgeliefert werden kann. Millionen von Punkten mit umfangreichen Zeitreihen über eine REST-API auszuliefern, wie es bei kleineren Datensätzen auf GIN gemacht wird, wäre schlicht nicht performant.
- Es gab bereits eine Kubernetes-Infrastruktur. GIN läuft auf einer Kubernetes-Instanz. Die cloud-nativen Formate konnten in einer ersten Phase über NFS gemountet und direkt bedient werden, ohne eine komplett neue Infrastruktur aufzubauen.
- Der Datenzugriff ist nicht komplex. Nutzerinnen und Nutzer schauen sich die Daten in der Karte an und klicken auf einen Punkt, um dessen Zeitreihe zu sehen. Dieses simple Zugriffsmuster – räumliche Übersicht plus Einzelabfrage per ID – eignet sich hervorragend für eine Kombination aus vorberechneten Kacheln und spaltenbasierten Dateiformaten.
Die Architektur: Zwei Wege zu den Daten
Wir haben die InSAR-Daten auf zwei parallelen Wegen verfügbar gemacht, die sich in der Benutzeroberfläche nahtlos ergänzen:
Weg 1: Geovisualisierung mit COG und PMTiles
Für die Kartendarstellung verwenden wir einen zweistufigen Ansatz:
Herausgezoomt: Cloud-Optimized GeoTIFF (COG). In der Übersicht zeigen wir eine vorberechnete Rasterdarstellung der Messpunkte. Das COG erlaubt es, je nach Zoomstufe nur den benötigten Ausschnitt und die passende Auflösung zu laden – effizient und schnell, auch bei schweizweiter Darstellung.
Hineingezoomt: PMTiles. Sobald die Nutzerin genügend hineingezoomt hat, wechseln wir auf die vektorbasierte Darstellung mit PMTiles. Der Grund: Bei InSAR-Daten können wir nicht einfach Features weglassen oder aggregieren – jeder Punkt ist ein eigenständiger Messpunkt mit einer eigenen Zeitreihe. Wir müssen alle Daten zeigen, was natürlich voraussetzt, dass der Kartenausschnitt ausreichend klein ist.
Weg 2: Datenabfrage mit Parquet und DuckDB
Wenn eine Nutzerin auf einen Messpunkt in der Karte klickt, um dessen gesamten Sachdaten zu sehen, kommt der zweite Weg zum Zug: Der Klick auf ein PMTiles-Objekt liefert die ID des Messpunkts. Diese wird an die bestehende GIN-API gesendet, wo im Backend (Spring Boot) DuckDB als JDBC-Treiber die ID direkt gegen die Parquet-Dateien abfragt. Die Sachdaten werden zurückgeliefert und können dargestellt werden. Der Vorteil: Wir konnten die bestehende API-Schicht der GIN nutzen und mussten «nur» die Datenquelle austauschen – statt einer Datenbank liest DuckDB die Parquet-Dateien direkt.
Die Stolperfallen: Wo es nicht einfach war
Und jetzt zum Teil, der auf Konferenzen und in einschlägigen LinkedIn-Posts gerne unterschlagen wird: Was hat nicht funktioniert bzw. nicht auf Anhieb? Denn genau wie im ersten Teil beschrieben ist der Einsatz cloud-nativer Formate kein Selbstläufer.
COG-Erzeugung: Nicht so trivial wie erhofft
Ein Cloud-Optimized GeoTIFF aus Punktdaten zu erzeugen klingt einfacher, als es ist. Die Rohdaten liegen als Vektordaten vor (Punkte mit Attributen), nicht als Raster oder nur schon als Punktraster. Die Vektor-Raster-Konversion erfordert zahlreiche Entscheidungen, die direkt die Brauchbarkeit der Übersichtsdarstellung beeinflussen: Welche Auflösung soll gewählt werden, welche Farbskala, welche Aggregationsregel bei überlappenden Punkten, …? Dazu kommen die technischen Details der COG-Erzeugung selbst: Tiling-Schema, Kompression, Overview-Stufen. Das ist alles lösbar, aber eben kein Einzeiler.
PMTiles und OpenLayers: Artefakte an Kachelgrenzen
Das PMTiles-Format funktioniert grundsätzlich gut mit OpenLayers. Aber bei Geometrien, die an Kachelgrenzen liegen, treten Artefakte auf. PMTiles splittet Geometrien an Kachelgrenzen, was bei Punkten weniger problematisch ist als bei Polygonen (die wir für die aggregierten Bewegungsgebiete verwenden). Das Resultat sind sichtbare Schnitte in den eigentlich kachelübergreifend durchgängigen Flächen (siehe z.B. dieses Issue, das für MVT ein ähnliches Problem aufzeigt). Als Workaround haben wir für den Mouse-Over Effekt die Einfärbung so gelegt, dass alle Polygone mit derselben ID beim Hovern eingefärbt werden – das ist etwas ineffizient hinsichtlich der Rendering-Performance, löst aber das Problem elegant.
DuckDB auf Parquet: Schnell – aber nur wenn man optimiert
Die Abfrage einzelner Messpunkte per DuckDB auf Parquet-Dateien funktioniert im Prinzip hervorragend. In der Praxis sind wir aber auf erhebliche Performance-Probleme gestossen, insbesondere beim grössten Datensatz. Diese zeigen exemplarisch, dass «einfach Parquet nutzen» nicht immer ausreicht:
- Extrem breite Tabellen. Die InSAR-Daten sind so strukturiert, dass jeder Messzeitpunkt als eigene Spalte abgebildet ist. Bei Datensätzen mit vielen Satellitenüberflügen führt das zu Parquet-Dateien mit bis zu 1000 oder mehr Spalten. Weil wir die gesamte Zeitreihe eines Punktes benötigen, müssen wir
SELECT *verwenden – und DuckDB muss alle Spalten lesen. Der zentrale Vorteil von Parquet, nämlich nur die relevanten Spalten zu laden, kann so nicht greifen. - Mehrere Dateien mit unterschiedlichen Schemata. Die Daten sind auf mehrere Parquet-Dateien verteilt, ohne dass aus der ID hervorgeht, in welcher Datei ein bestimmter Punkt liegt. DuckDB muss daher alle Dateien scannen. Erschwerend kommt hinzu, dass nicht alle Dateien dasselbe Schema haben – nicht jeder Satellitenüberflug ist in jedem File als Spalte vorhanden. Deshalb ist
UNION BY NAMEnötig, was zusätzlichen Aufwand bedeutet: DuckDB muss die Schemata aller Dateien zusammenführen und fehlende Spalten mitNULL-Werten auffüllen. - Die «conference-driven architecture»-Falle. Auch wir sind nicht immun. Manche Entscheidung war stärker von der Begeisterung für neue Technologien getrieben als von einer nüchternen Analyse. DuckDB als JDBC-Treiber in einer Spring-Boot-Applikation? Funktioniert – aber man bewegt sich damit ausserhalb der typischen DuckDB-Use-Cases (analytische Batch-Abfragen) und in ein Terrain, wo man weniger auf etablierte Patterns zurückgreifen kann.
Die Migration auf AWS: Gewinner und Verlierer
GIN wird derzeit auf AWS migriert. Die Erfahrungen dabei sind aufschlussreich, weil sie die Stärken und Schwächen cloud-nativer Formate unter realen Bedingungen nochmals deutlich hervorheben.
Die Gewinner: COG und PMTiles. Die Geovisualisierung profitiert enorm von der Migration. COG und PMTiles liegen nun auf S3 und werden über CloudFront ausgeliefert. Weil sie für HTTP Range Requests konzipiert sind und der Client immer nur kleine, klar definierte Datenblöcke anfordert, funktioniert Caching hier hervorragend. Die Kartenvisualisierung ist nach der Migration spürbar schneller als vorher.
Der Verlierer: DuckDB auf Parquet via S3. Umgekehrt verhält es sich mit den Parquet-Abfragen. Die kombinierten Probleme – breite Tabellen mit SELECT *, mehrere Dateien mit UNION BY NAME, kein gezielter Dateizugriff – werden durch die S3-Latenz nochmals verschärft. Jeder HTTP-Request gegen S3 bringt eine Grundlatenz mit sich, und wenn DuckDB Metadaten und Datenblöcke aus mehreren Dateien laden muss, summiert sich das schnell. Dazu kommt, dass DuckDB bei lokalen Dateien deutlich stärker vom Dateisystem-Cache profitieren kann als bei Zugriffen über S3. Das Ergebnis: Die Abfragen sind nach der Migration langsamer als auf dem ursprünglichen NFS-Mount – genau das Szenario, vor dem wir im ersten Blogpost gewarnt haben.
Mögliche Optimierungen
Aus den bisherigen Erfahrungen ergeben sich verschiedene Ansatzpunkte, um die Performance der Parquet-Abfragen zu verbessern. Einige davon sind eher niedrigschwellig, andere erfordern Anpassungen an der Datenaufbereitung oder der Architektur:
Dateien konsolidieren und partitionieren. Statt mehrere Dateien mit UNION BY NAME zu kombinieren, können die Daten pro Datensatz in eine einzelne Datei zusammengeführt werden – oder, bei sehr grossen Datensätzen, sinnvoll partitioniert werden, etwa nach den ersten Zeichen der UIDs. Beides reduziert den Overhead des Datei-Scannings und erlaubt DuckDB, gezielter zu lesen. Idealerweise weiss das Backend aus dem Klick auf das PMTiles-Objekt bereits, in welcher Datei oder Partition der gesuchte Punkt liegt.
Spaltenanzahl reduzieren. Das grösste Performance-Problem ist die breite Tabellenstruktur. Statt jede Messung als eigene Spalte abzubilden, könnte die gesamte Zeitreihe als JSON oder als verschachtelte Struktur in einer einzigen Spalte gespeichert werden. Das würde die Spaltenanzahl von über 1000 auf eine Handvoll reduzieren, SELECT * massiv beschleunigen und die Problematik mit UNION BY NAME entschärfen – denn alle Dateien hätten dann dasselbe Schema. Für unser Zugriffsmuster (gesamte Zeitreihe eines einzelnen Punktes laden) wäre das kein Verlust, da wir ohnehin alle Messwerte benötigen.
Oder doch PostgreSQL? Weil unsere Implementierung entkoppelt ist, wäre ein Wechsel der Datenquelle auf PostgreSQL mit vertretbarem Aufwand möglich. Damit würde allerdings genau die Komplexität zurückkehren, die wir mit dem cloud-nativen Ansatz vermeiden wollten – Import-Pipelines, Synchronisation, Datenbankmanagement. Für die kleineren Datensätze wäre das Overkill, für den grössten Datensatz aber eine ernstzunehmende Alternative, falls die skizzierten Parquet-Optimierungen nicht ausreichen.
Was wir gelernt haben
Einige der konkreten Learnings, die wir aus dem Projekt mitnehmen:
- Cloud-native Formate sind ein Distributionsformat, kein Universalformat. COG, PMTiles und Parquet haben im Projekt ihre Stärken ausgespielt – aber nur dort, wo die Rahmenbedingungen stimmten. Für die Geovisualisierung grosser statischer Datensätze sind sie eine ausgezeichnete Wahl. Für performante Einzelabfragen gegen noch unoptimierte Datenstrukturen? Da stösst man schnell an Grenzen.
- Das Update-Muster ist ein unterschätzter Vorteil. Einer der grössten praktischen Vorteile gegenüber dem klassischen Datenbankansatz ist die Einfachheit beim jährlichen Update: Dateien ersetzen statt komplexe Import-Pipelines pflegen. Gerade bei Datensätzen, die vollständig ersetzt statt inkrementell aktualisiert werden, spart das erheblichen Aufwand.
- Die Datenstruktur entscheidet über die Performance, nicht das Format. Parquet ist schnell, wenn die Daten so strukturiert sind, dass DuckDB seine Stärken ausspielen kann: wenige Spalten, gezielter Zugriff, Partitionierung. Die gleichen Daten in einer ungünstigen Struktur (breite Tabellen,
SELECT *, kein Partitioning) sind auch in Parquet langsam. Die Datenaufbereitung ist der eigentliche Hebel. - CDN-Caching und cloud-native Formate passen perfekt zusammen, für Geodaten. Die Erfahrung aus der AWS-Migration zeigt: COG und PMTiles profitieren enorm von CloudFront, weil ihre kleinen, klar adressierbaren Blöcke ideal cachebar sind. Analytische Abfragen über Parquet hingegen profitieren kaum von einem CDN, weil jede Abfrage andere Datenblöcke braucht. Cloud-native heisst nicht automatisch «schneller in der Cloud» – es kommt auf das Zugriffsmuster an.
- Bestehende Infrastruktur und Pragmatismus schlagen Purismus. Der anfängliche NFS-Mount-Ansatz war nicht «richtig cloud-native», aber er hat es ermöglicht, die Daten innerhalb der bestehenden Infrastruktur verfügbar zu machen, ohne eine S3-Migration vorauszusetzen. Manchmal ist die pragmatische Lösung die bessere.
- Neue Technologien bedeuten neue Optimierungsarbeit. Wir haben jahrelange Erfahrung damit, PostGIS-Abfragen zu optimieren. Bei Parquet und DuckDB ist dieses Wissen noch jung und im Aufbau begriffen. Das ist kein Argument gegen neue Technologien, aber man muss den Lernaufwand einplanen.
Ausblick
Die Geovisualisierung mit COG und PMTiles läuft stabil und performant insbesondere seit der AWS-Migration mit CloudFront-Caching. Die Parquet/DuckDB-Seite erfordert hingegen noch Arbeit. Aktuell nutzen wir als Workaround EFS statt S3 für die Parquet-Dateien, um die Latenzprobleme zu umgehen. Das ist eine teurere, aber funktionale Zwischenlösung.
Parallel arbeiten wir gemeinsam mit dem neu aufgebauten Datenplattform-Team des Kunden an einer nachhaltigen Lösung. Im Fokus steht die Optimierung der Parquet-Dateien selbst: Reduktion der Spaltenanzahl, Harmonisierung der Schemata über Datensätze hinweg und eine sinnvollere Strukturierung der Daten. Mittelfristig besteht zudem die Möglichkeit, die Datenbereitstellung ganz an die Datenplattform des Kunden zu übergeben über deren eigene APIs, sodass der Umweg über DuckDB entfallen könnte. Das wäre ein sauberer Schnitt: Die Geovisualisierung bleibt cloud-native (COG/PMTiles), die Datenbereitstellung wird von der dafür vorgesehenen Infrastruktur übernommen.
Dieses Szenario zeigt auch, dass «cloud-native» kein monolithisches Alles-oder-nichts ist. Man kann cloud-native Formate dort einsetzen, wo sie ihre Stärken ausspielen, und für andere Aspekte bewusst auf andere Lösungen setzen.
Fazit
Die Integration der InSAR-Daten in die GIN war ein lehrreiches Projekt. Die Kombination aus COG, PMTiles und Parquet/DuckDB hat funktioniert. Optimal dort, wo die Voraussetzungen gestimmt haben: grosse, statische Datensätze, einfache Zugriffsmuster, ein Update-Muster, das perfekt zu dateibasierten Formaten passt. Gleichzeitig hat das Projekt gezeigt, dass «cloud-native» kein Autopilot ist. Jedes dieser Formate bringt eigene Optimierungsanforderungen mit und die smarte Datenaufbereitung bleibt der grösste Hebel für die Performance.
Oder, um es mit unserem Fazit aus dem ersten Blogpost zum vorliegenden Thema zu sagen: Die beste Technologieentscheidung ist die, die man aus tiefem Verständnis trifft. Dieses Verständnis haben wir mit dem InSAR-Projekt ein gutes Stück vertieft, auch und gerade durch die Stolperfallen.
Interessieren Sie sich ebenfalls für Cloud-Native Geospatial und wie der Ansatz Ihnen nützen kann? – Kontaktieren Sie uns ganz unverbindlich.