Software • 13. Januar 2021
Tilemaker am Limit
Wer OpenStreetMap-Daten als VectorTiles bereitstellen möchte, stolpert früher oder später auch über Tilemaker. Während viele andere Tile-Generatoren auf eine Postgres-Datenbank als Zwischenschicht setzen, verzichtet Tilemaker auf diese und schreibt die Daten direkt in eine Verzeichnisstruktur oder .mbtiles-Dateien.
Schnell ist die Idee geboren, auf diesem Weg einfach die weltweiten OpenStreetMap-Daten ”in einem Rutsch” bereitzustellen. Die Projektseite macht aber gleich klar, dass das vielleicht nicht die beste Idee ist: “If you're processing a country extract or larger, you'll need a lot of RAM. It's best suited to city and region extracts.”
Endlose Ressourcen
Nun gut, wofür gibt es denn dann die großen Public-Cloud-Anbieter mit ihren nahezu endlosen Ressourcen? Endlich mal ein Problem für die Lösung! Ein kurzer Blick in die Preisliste von Azure ist vielversprechend: Von der kleinsten Entwicklermaschine bis zum Monster mit 416 CPU und über 11 TB Arbeitsspeicher ist alles zu haben - und rechnet man mit dem Stundenpreis, auch zu überschaubaren Preisen. Andere Anbieter liegen bei Preis und Leistung in ähnlichen Bereichen.
Die ersten Versuche mit dem deutschen OpenStreetMap-Datenbestand (germany-latest.osm.pbf mit 3,2 GB) auf den kleineren VMs scheitern dann aber schnell: Der sparsam vergebene Arbeitsspeicher veranlasst die Systeme schnell zur Nutzung der Auslagerungsdatei (Swap); in so einem Fall ließ sich auch nach mehreren Stunden Prozessierung niemals ein Erfolg erzielen.
Faktor 12
Auf einem Laptop rechnen wir ein paar kleinere Dateien, um herauszufinden, wie viel Arbeitsspeicher Tilemaker denn nun benötigt. Ein Faktor von 12 (RAM zu Dateigröße) kristallisiert sich dabei als Ergebnis heraus.
Beim nächsten Versuch auf Azure kommt es unter Nutzung dieses Faktors dann endlich zum Erfolg: Bei 64GB RAM und 8 CPUs ist das Ergebnis bereits nach 60 Minuten da. Eine Gegenprobe mit gleichem RAM, aber nur 4 CPUs kommt fast zur gleichen Zeit ins Ziel. Das überrascht, da Tilemaker für das Einlesen der Datei zwar nur eine CPU benutzt, für das Schreiben der .mbtiles-Datei dann aber alle CPUs ausnutzt. Am Ende stehen jedenfalls keine 50 Cent Kosten für das Experiment auf der Rechnung.
Ein Runterschrauben des RAM auf 32 GB führt durch den zu kleinen Arbeitsspeicher zum Abbruch von Tilemaker, was die Faktor-12-Hypothese stützt.
Größenwahn
Gut, was kommt nach germany-latest.osm.pbf? Richtig, die europe-latest.osm.pbf mit knapp über 22 GB Größe - macht eine geschätzte RAM-Forderung von 268 GB RAM. Die nächst-passende VM bringt neben 378 GB RAM gleich 48 CPUs mit - letzteres kann htop ohne weitere Konfiguration schon gar nicht mehr darstellen.
Die Datei ist schnell geladen, danach beginnen alle CPUs am Anschlag zu arbeiten. Nach ein paar Stunden folgt aber die Ernüchterung: Lediglich eine CPU rödelt noch einsam vor sich hin, so dass erst nach über 25 Stunden die Datei erfolgreich fertig gerechnet ist. Diese unzureichende Ressourcennutzung führt dann auch schon zu Kosten von 65 EUR.
Lieber kein Planet-File
Die hypothetische Verarbeitung der ganzen Welt, dem planet-latest.osm.pbf mit 53 GB, rückt dann schnell in kostspielige Bereiche vor: Nimmt man eine optimistische Prozessierungszeit von 50 Stunden an (vermutlich liegt sie deutlich höher), stehen schnell mittlere dreistellige Beträge auf der Rechnung.
Das kann für spezielle Anforderungen durchaus noch interessant sein, angesichts des anhaltend schnellen Wachstums des Planet-Files werden die Kosten hier aber schnell steigen.
Fazit
Tilemaker ist eine tolle Möglichkeit, schnell VectorTiles für überschaubare, regionale Extrakte der OSM zu erzeugen. Ab PBF-Größen im niedrigen einstelligen GB-Bereich wird die Verarbeitung dann aber schnell teuer: Hohe RAM-Forderungen machen die nötigen VMs teuer, gleichzeitig werden die CPU-Ressourcen nur unzureichend genutzt.
Für die weltweite Erzeugung von VectorTiles für die OSM dürften die Postgres-basierten Ansätze wegen deutlich geringerer Ressourcenforderungen jedoch besser sein. Neben der ständig neuen Erzeugung aus dem Planet-File besteht hier die Möglichkeit, mit Diff-Files zu arbeiten und damit den Aufwand für das Einlesen in die Datenbank zu verkürzen - allerdings muss dafür die dauerhafte Vorhaltung der Daten sichergestellt werden.
Auch wenn das hier gezeigte Beispiel kein Happy-End hatte, so sollte man “Wegwerf-VMs” in der Public Cloud für die Prozessierung von Geodaten unbedingt im Hinterkopf behalten. Wenn die verwendeten Programme die Ressourcen gut ausnutzen, sind die Kosten häufig überraschend günstig. Deutlich günstiger jedenfalls als die dauerhafte Vorhaltung entsprechend leistungsfähiger Infrastruktur.
