- Runtime 17+ bringt 90+ native Spatial-SQL-Funktionen auf Photon - keine Sedona-Abhängigkeit, kein UDF-Overhead, 17x schneller als äquivalente Sedona-Operationen
- Drei raumliche Ansatze koexistieren: Natives Spatial SQL (schnellstes, einfachstes), Mosaic (H3-Indexierung für massive Joins) und Sedona (Legacy, weiterhin sinnvoll für komplexe Geometrie-Operationen)
- H3-Indexierung via Mosaic: Spatial Joins über 100 Mio.+ Datensätze sinken von 47 Minuten auf 12 Sekunden - eine 235x-Verbesserung. Auflösung 9 für Stadt, Auflösung 7 für Region
- Delta Lake ist der Speichervorteil: Z-Ordering nach Geohash liefert 10-50x schnellere raumliche Abfragen, Liquid Clustering (Runtime 13.3+) automatisiert dies vollständig, und Time Travel bietet integrierte Audit-Trails für regulatorische Compliance
- Asset Bundles ersetzen manuelles Notebook-Deployment: eine databricks.yml-Datei definiert Jobs, Cluster und Zeitpläne über Dev/Staging/Prod hinweg. CI/CD validiert vor dem Deploy
- Echter Benchmark: 368x schneller als aquivalenter ArcPy-Workflow auf identischen Daten (847s zu 2,3s) bei 0,47 $ pro Lauf gegenuber 7.000 $/Jahr Lizenzkosten
Sie haben 50 Millionen Flurstuecke. Eine wochentliche Hochwasserrisiko-Analyse, die manuell 4 Wochen dauert. Und Ihr Vorgesetzter will das in der Cloud. Welche Plattform?
Dieser Beitrag handelt von Databricks - ehrlich, produktionserprobt, mit Code, den Sie kopieren können. Wir haben diese Benchmarks auf echten Daten für einen Top-5-Ruckversicherer weltweit durchgefuhrt. Die Zahlen sind konkret, weil sie aus echten Produktionslaeufen stammen - nicht aus Marketingfolien.
Serie: Geospatial in der Cloud
Dies ist Teil 1 unserer Serie "Geospatial in der Cloud". Jeder Beitrag ist in sich geschlossen. Teil 2 behandelt AWS. Teil 3 behandelt GCP. Lesen Sie den Beitrag, der zu Ihrem Stack passt.
Warum Databricks für Geodaten
Vor 2023 war Databricks nur Spark mit einer Notebook-Oberflache. Geodaten bedeutete Apache Sedona nachrusten, mit UDF-Serialisierung kampfen und hoffen, dass dem Cluster beim Join nicht der Arbeitsspeicher ausgeht. Diese Aera ist vorbei.
Runtime 17+ hat alles verändert. Databricks liefert jetzt 90+ native Spatial-SQL-Funktionen, die direkt in die Query-Engine eingebaut sind. Keine externen Bibliotheken zu installieren, keine UDFs zu registrieren, keine JAR-Abhangigkeiten zu verwalten. Spatial Joins, Pufferanalysen, Distanzberechnungen, Verschneidungstests - alles als Standard-SQL, das Ihre Datenanalysten bereits beherrschen.
Natives Spatial SQL auf Photon (Runtime 17+)
ST_Contains, ST_Buffer, ST_Distance, ST_Intersection und 86 weitere Funktionen laufen direkt auf Databricks' vektorisierter C++-Engine. Kein Serialisierungs-Overhead, kein JVM-Interop, kein UDF-Flaschenhals. Das ist 17x schneller als dieselben Operationen via Sedona auf demselben Cluster.
Mosaic-Bibliothek für H3 Spatial Indexing
Ubers hexagonales Gittersystem, als First-Party-Databricks-Bibliothek integriert. Wenn Ihre Spatial Joins 100 Mio.+ Datensätze erreichen, verwandelt H3-Vorindizierung via Mosaic 47-Minuten-Operationen in 12-Sekunden-Operationen. Das ist der Unterschied zwischen Overnight-Batch und interaktiver Analyse.
Unity Catalog für Data Governance
Versionierte Geodatensatze mit Lineage-Tracking. Ein Governance-Modell für Vektoren, Raster und Tabellendaten. Fein granulare Zugriffssteuerung und Audit-Logs. Keine separate Datenverwaltungsschicht für raumliche Dateien.
GeoParquet als natives Format
GeoParquet direkt aus Cloud-Speicher lesen und schreiben (S3, ADLS, GCS). Kein Formatkonvertierungsschritt, keine Shapefile-Einschränkungen. Spaltenspeicherung bedeutet, dass die Query-Engine nur die in Ihrer Abfrage referenzierten Spalten liest und I/O-Kosten drastisch senkt.
Der eigentliche Grund, warum Teams es wahlen: Sie nutzen Databricks bereits für Analytics. Geodaten zu einem bestehenden Lakehouse hinzuzufugen bedeutet inkrementelle Rechenkosten - keine Kosten für eine neue Plattform. Die Spatial-SQL- Funktionen arbeiten auf denselben Tabellen, mit denselben Berechtigungen, in denselben Notebooks, die Ihr Team bereits nutzt.
Natives Spatial SQL (Runtime 17+)
Die haufigste geospatiale Operation ist ein Spatial Join: “Welche Flurstuecke liegen innerhalb welcher Hochwasserzonen?” In Databricks Runtime 17+ ist das Standard-SQL mit raumlichen Praedikaten. Keine Sondersyntax, keine Python-Wrapper, keine externen Bibliotheken. Ihre Datenanalysten beherrschen die Sprache bereits - sie müssen nur eine Handvoll raumlicher Funktionen lernen.
Ein Spatial Join nutzt ST_Contains für Enthaltenseinstests. Eine Pufferanalyse kombiniert ST_Buffer mit ST_Intersects. Distanzberechnungen verwenden ST_Distance. Die Syntax ist identisch mit PostGIS - das erleichtert die Migration für Teams mit PostGIS-Erfahrung erheblich.
Warum Photon hier entscheidend ist: Diese raumlichen Funktionen laufen auf Databricks' vektorisierter C++-Engine. Traditionelles Spark wuerde Geometrie-Objekte zwischen Java und Python serialisieren und an jeder Grenze Leistung verlieren. Photon arbeitet nativ auf Spaltendaten, weshalb derselbe Spatial Join 17x schneller lauft als das Sedona-UDF-Äquivalent auf identischer Cluster-Konfiguration.
KERNAUSSAGE: DIE MEISTEN TUTORIALS SIND VERALTET
Suchen Sie nach “Databricks geospatial” - die meisten Ergebnisse zeigen noch den alten Sedona-Ansatz: JAR installieren, UDFs registrieren, alles in Python verpacken. Mit Runtime 17+ entfallt das alles. Natives Spatial SQL funktioniert sofort. Wenn Sie heute ein neues Geodaten-Projekt auf Databricks starten, beginnen Sie mit nativem SQL. Greifen Sie nur auf Sedona oder Mosaic zurück, wenn natives SQL Ihren konkreten Workload nicht bewaltigt.
Die 90+ raumlichen Funktionen decken das gesamte Spektrum ab: raumliche Praedikate (Contains, Intersects, Within, Touches, Crosses), Messungen (Area, Length, Distance), Transformationen (Buffer, Centroid, Convex Hull, Simplify, Union), Konstruktoren (Point, Polygon, LineString aus WKT/WKB/GeoJSON) und Accessoren (Coordinates, SRID, Envelope). Für die große Mehrheit der Enterprise-Geodaten-Workloads - Hochwasser- Exposition, Flurstueckanalyse, Nahe-Scoring, Portfolio-Aggregation - deckt natives SQL alles ab.
Einen tiefen Einblick in die Dateiformate, die dies effizient machen, bietet unser Leitfaden zu cloud-nativen Geodatenformaten (GeoParquet, COG, STAC).
Sedona vs Mosaic vs Natives SQL
Drei raumliche Ansatze koexistieren jetzt auf Databricks. Zu verstehen, wann man welchen einsetzt, ist der Unterschied zwischen einer 12-Sekunden-Abfrage und einer 47-Minuten-Abfrage - oder zwischen einer sauberen Architektur und einer Wartungslast.
| ANSATZ | IDEAL FUR | LEISTUNG | KOMPLEXITAT |
|---|---|---|---|
| Natives Spatial SQL | Standard-Raumoperationen (Joins, Puffer, Distanz) | Am schnellsten (Photon C++-Engine) | Am geringsten - einfach SQL |
| Mosaic (H3) | Massive Spatial Joins (100 Mio.+ Datensätze), Tessellierung | 235x schneller als Brute-Force bei grossen Joins | Mittel - erfordert H3-Indexierungsschritt |
| Apache Sedona | Komplexe Geometrie-Operationen, R-Tree-Index, Legacy | 17x langsamer als nativ für gangige Operationen | Am hochsten - JAR-Abhangigkeiten, UDF-Registrierung |
Natives Spatial SQL ist die Standardwahl. Es deckt 80-90 % der Enterprise-Geodaten-Workloads ohne Setup-Overhead ab. Standard-Spatial-Joins, Pufferanalysen, Distanzberechnungen, Flachenberechnungen - alles lauft direkt auf Photon ohne externe Abhangigkeiten.
Mosaic ist das Skalierungswerkzeug. Wenn Ihre nativen Spatial Joins an Leistungsgrenzen stossen - typischerweise ab 50 Mio. Datensatzen auf beiden Seiten des Joins - reduziert Mosaics H3-Indexierung den Vergleichsraum dramatisch. Statt jede Geometrie gegen jede andere zu testen, filtert H3 vorab auf Geometrien in derselben Hexagonalzelle. Der Kompromiss ist ein initialer Indexierungsschritt und etwas komplexere Abfragemuster.
Sedona ist die Legacy-Option. Vor Runtime 17+ war Sedona der einzige Weg für Geodaten auf Databricks. Es hat weiterhin berechtigte Einsatzgebiete: benutzerdefinierte R-Tree-Raumindizes, komplexe Geometrie-Operationen, die im nativen SQL noch nicht verfugbar sind (wie Voronoi-Diagramme oder erweiterte Topologie-Operationen), und Workflows, die bereits auf Sedonas API aufbauen. Aber für neue Projekte mit Sedona zu starten, wenn natives SQL verfugbar ist, heisst den langsameren, komplexeren Weg zu wahlen.
WARNUNG: SEDONAREGISTRATOR IST VERALTET
Wenn Tutorials Ihnen sagen, SedonaRegistrator.registerAll() aufzurufen - diese API ist seit Sedona 1.5+ veraltet. Die moderne Initialisierung nutzt SedonaContext. Besser noch: überspringen Sie Sedona für Standardoperationen komplett und nutzen Sie natives Spatial SQL. Eine Abhängigkeit weniger zu verwalten, eine JAR-Version weniger zu pflegen, eine Fehlerquelle weniger bei Runtime-Upgrades.
H3-Indexierung mit Mosaic
H3 ist Ubers hexagonaler hierarchischer Raumindex. Stellen Sie sich vor, der gesamte Planet wird auf mehreren Auflosungsebenen in Sechsecke unterteilt. Jeder Punkt der Erde wird auf jeder Auflosungsebene einer bestimmten Sechseck-ID zugeordnet.
Warum Sechsecke? Im Gegensatz zu Quadraten haben Sechsecke in jede Richtung einen gleichmassigen Abstand vom Mittelpunkt zur Kante. Das ist wichtig für Spatial Joins, weil der Index irrelevante Partitionen gleichmassig prueft - unabhängig von der Richtung.
Der praktische Unterschied ist dramatisch. Ein Spatial Join über 100 Mio. Flurstuecke x 50.000 Hochwasserzonen dauerte 47 Minuten mit ST_Contains. Mit H3-Vorindizierung bei Auflösung 9 dauerte derselbe Join 12 Sekunden.
Die Einrichtung ist unkompliziert: Mosaic-Bibliothek installieren, auf Ihrer Spark-Session aktivieren, dann Ihre Geometrien bei der passenden H3-Auflösung tessellieren. Ab diesem Punkt nutzen Spatial Joins H3-Zellen-Lookups statt vollstandiger Geometrie-Vergleiche. Die Mosaic-Bibliothek übernimmt Tessellierung, Index-Matching und die finale Geometrie-Verfeinerung automatisch.
Die Wahl der Auflösung ist entscheidend. Auflösung 9 (ca. 174 m pro Hexagon) ist optimal für stadtische Analysen - Flurstueckgrenzen, Gebaudeumrisse, Adress-Ebene. Auflösung 7 (ca. 1,2 km pro Hexagon) eignet sich für regionale Analysen - Hochwasserzonen, Verwaltungsgrenzen, Einzugsgebiete. Zu fein verschwenden Sie Speicher für Index-Overhead; zu grob verfehlt der Vorfilter seinen Zweck. Die meisten Enterprise-Workloads, die wir sehen, landen bei Auflösung 8 oder 9.
Eine kritische Falle bei der H3-Koordinatenreihenfolge: Die H3-Funktionen in Mosaic erwarten (Breitengrad, Langengrad) - die umgekehrte Reihenfolge der meisten GIS-Werkzeuge, die (Langengrad, Breitengrad) verwenden. Jedes Team stolpert mindestens einmal daruber. Wenn Ihre Spatial Joins bei Daten, die sich nachweislich uberlappen, null Treffer liefern - prüfen Sie zuerst die Koordinatenreihenfolge.
AUSWIRKUNG DER H3-INDEXIERUNG
100 Mio. Flurstuecke x 50.000 Hochwasserzonen
WANN H3 NICHT VERWENDEN
Point-in-Polygon mit geringer Kardinalitat (weniger als 10.000 Polygone) - natives ST_Contains ist schneller, weil der H3-Indexierungsoverhead die Join-Einsparungen ubersteigt. Der Tessellierungsschritt selbst hat seinen Preis. Verwenden Sie H3 nur, wenn Ihre Polygonanzahl es rechtfertigt.
Unity Catalog für Rasterdaten
Databricks ist vektorzentriert. Aber die meisten realen Geodaten-Workflows beinhalten auch Rasterdaten - DEMs, Satellitenbilder, Klimagitter. Unity Catalog Volumes ermoglichen es, diese zusammen mit Ihren Vektordaten zu speichern und zu versionieren.
DIE FALLE, DIE NIEMAND DOKUMENTIERT
Databricks Volumes scheinen Datei-I/O zu unterstutzen, aber _tiffSeekProc: Operation not supported stoppt jede Bibliothek, die wahlfreie Lesezugriffe auf TIFF-Dateien versucht. GDAL, rasterio und alle TIFF-basierten Workflows schlagen still oder mit kryptischen Fehlermeldungen fehl.
Die Lösung: zweistufiges Lesen.
Die Lösung ist ein zweistufiges Muster: Datei vom Volume nach /local_disk0/tmp auf dem Worker-Knoten kopieren, dann mit rasterio oder GDAL vom lokalen Pfad offnen. Der /local_disk0/-Pfad ist eine ephemere SSD, die an die Instanz angehangen ist - schnelle Lesezugriffe, korrekter Seek-Support, wird beim Cluster-Stopp gelöscht. Das fuhrt zu 2-5 Sekunden zusatzlicher Kopierzeit pro Datei, ist aber das einzige zuverlassige Muster.
STOLPERFALLE: BETRIFFT AUCH LESEZUGRIFFE
GeoPackage-Lesevorgange scheitern auf Volumes ebenfalls. SQLite erstellt eine -wal (Write-Ahead Log) Datei selbst bei reinen Lesezugriffen. Der FUSE-Mount kann das nicht verarbeiten. Erst auf lokale Disk stagen, lesen, dann aufraeumen. Das erwischt jeden beim ersten Mal - die Fehlermeldung gibt keinen Hinweis, dass der Lesepfad das Problem ist.
Dasselbe zweistufige Muster gilt auf jeder Cloud-Plattform. S3 auf AWS, GCS auf Google Cloud - alle Object Stores sind auf Protokollebene append-only. Sie können nicht ruckwarts in einer Datei suchen. Jedes Format mit wahfreiem Zugriff (GeoTIFF, GeoPackage, Shapefile) erfordert lokales Staging. Die AWS- und GCP-Varianten behandeln wir in den jeweiligen Leitfaden dieser Serie.
Bei lang laufenden Jobs /local_disk0/tmp regelmaessig aufraeumen. Die ephemere Disk ist endlich und lauft voll, wenn Sie tausende Raster verarbeiten, ohne Zwischendateien zu löschen. Die Disk wird beim Cluster-Stopp gelöscht, aber während der Ausführung liegt die Verwaltung bei Ihnen.
Der Vorteil von Unity Catalog: Versionierung, Lineage-Tracking und fein granulare Zugriffssteuerung für Ihre Geodatensatze. Eine einzige Governance-Schicht für alles - Vektoren, Raster, Tabellendaten. Kein separates Datenmanagement für raumliche Dateien.
Delta Lake für Raumdaten
Delta Lake ist die Speicherschicht, die Databricks Geospatial wirklich von Spark auf rohen Parquet-Dateien unterscheidet. Drei Fähigkeiten sind für raumliche Workloads entscheidend: physisches Datenlayout, Time Travel und inkrementelle Verarbeitung.
Z-Ordering nach Geospatial-Spalten ist das Erste, was Sie konfigurieren sollten. Wenn Sie OPTIMIZE mit ZORDER BY auf Breitengrad- und Langengrad-Spalten ausführen, reorganisiert Delta Lake die Parquet-Dateien physisch, sodass raumlich nahe Datensätze gemeinsam auf der Disk gespeichert werden. Eine raumliche Abfrage, die zuvor 100 % der Dateien scannte, uberspringt jetzt 90-95 % davon, weil die Datei-Level-Statistiken der Engine mitteilen, dass diese Dateien keine relevanten Geometrien enthalten. Für einen 1-TB-Datensatz bedeutet das typischerweise 10-50x schnellere Abfragezeiten ohne jede Code-Änderung - nur ein einmaliger OPTIMIZE-Befehl.
Liquid Clustering (Runtime 13.3+) ist besser als Z-Ordering. Statt regelmaessige manuelle OPTIMIZE-Laufe zu erfordern, reorganisiert Liquid Clustering Daten kontinuierlich beim Schreiben. Deklarieren Sie Ihre Clustering-Spalten bei der Tabellenerstellung, und Delta Lake übernimmt den Rest. Für Geodaten-Tabellen, die regelmaessige Updates erhalten - Sensor-Feeds, tagliche Flurstueck-Snapshots, inkrementelle Hochwassermodell-Ausgaben - entfallt damit der operative Aufwand für die Planung von OPTIMIZE-Jobs. Die Abfrageleistung ist äquivalent oder besser als Z-Ordering, bei null Wartungsaufwand.
Time Travel ist der Audit-Trail, den Regulierer lieben. Jeder Schreibvorgang auf einer Delta-Tabelle erzeugt eine neue Version. Sie können jede fruhere Version nach Nummer oder Zeitstempel abfragen. Für regulierte Branchen - Versicherung, Banken, Behorden - bedeutet das, Sie können exakt reproduzieren, was die raumliche Analyse an einem bestimmten Datum gezeigt hat. Kein separates Versionierungssystem, keine manuellen Snapshots, keine Frage mehr wie "welche Version des Hochwassermodells war am 15. Marz aktuell?". Delta behalt jede Version automatisch, mit konfigurierbarer Aufbewahrungsfrist (Standard 7 Tage, für Compliance verlangerbar).
Change Data Feed (CDF) ermoglicht inkrementelle Verarbeitung. Aktivieren Sie CDF auf einer Delta-Tabelle, und Sie erhalten ein Protokoll jeder Einfugung, Aktualisierung und Loschung. Für raumliche Pipelines, die täglich auf Datensatzen laufen, bei denen sich nur 1-2 % der Datensätze ändern, bedeutet das: nur die Änderungen verarbeiten statt den gesamten Datensatz. Ein nachtliches Flurstueck-Update, das bisher 50 Mio. Datensätze neu verarbeitete, verarbeitet jetzt nur die 500.000, die sich geandert haben. Die Kostensenkung kumuliert: weniger Rechenleistung, weniger Zeit, weniger Geld.
DELTA LAKE RAUMLICHE OPTIMIERUNG - AUSWIRKUNG
Deployment mit Asset Bundles
Der grosste operative Unterschied zwischen einem Prototyp-Notebook und einer produktiven Geodaten-Pipeline ist das Deployment. Asset Bundles losen das mit einer einzigen deklarativen YAML-Datei - databricks.yml - die alles definiert: Jobs, Cluster-Konfigurationen, Zeitpläne und umgebungsspezifische Overrides für Dev, Staging und Production.
Statt Jobs manuell über die UI zu konfigurieren (was unweigerlich zu Drift zwischen Umgebungen fuhrt), deklarieren Sie die gesamte Pipeline als Code. Ein einziger databricks bundle deploy-Befehl validiert die Konfiguration, prüft auf Fehlkonfigurationen und deployt in die Zielumgebung. Das Bundle validiert vor dem Deploy - und fangt Probleme wie nicht existierende Cluster Policies oder ungultige Instance Types ab, bevor sie zur Laufzeit fehlschlagen.
Für Geodaten-Teams, die von ArcPy migrieren, ersetzt dies das "Skript auf den Server kopieren und hoffen"-Deployment-Modell. Ihre raumliche Pipeline, ihre Cluster- Konfiguration, ihr Zeitplan und ihre Umgebungsvariablen liegen alle in der Versionskontrolle. CI/CD-Pipelines können bei Merge automatisch deployen. Keine "bei mir lief es"-Debugging-Sessions mehr.
FALLE: DER MODULE-CACHE, DER STUNDEN KOSTET
Wenn Sie während der Entwicklung ein geteiltes Python-Modul aktualisieren, übernimmt der Spark-Driver den neuen Code sofort - aber die Executors haben noch die alte Version aus einem vorherigen Task gecacht. Ihr Driver und Ihre Worker laufen mit verschiedenen Code-Versionen. Die Lösung ist dbutils.library.restartPython() nach jedem Modul-Update. Für produktive Jobs pinnen Sie Modul-Versionen in Ihrer Cluster-Library-Konfiguration, statt sich auf notebook-scoped Imports zu verlassen. Das eliminiert das Cache-Problem vollständig.
Echte Benchmarks
Diese Benchmarks vergleichen dieselben Operationen auf identischen Datensatzen. ArcPy lief auf einem Hochleistungs-Desktop. Databricks lief auf einem 4-Knoten-Cluster. Beide verarbeiteten GeoParquet-Daten, die auf Delta Lake gespeichert waren.
ARCPY VS. DATABRICKS - GLEICHE DATEN, GLEICHE OPERATIONEN
368x schneller
173x schneller
108x schneller
CLUSTER-KONFIGURATION
- Cluster: 4x i3.xlarge Worker (4 vCPU, 30,5 GB RAM je Knoten)
- Runtime: 17 LTS mit aktiviertem Photon (natives Spatial SQL)
- Datenformat: GeoParquet auf Delta Lake
- ArcPy-Rechner: Dell Precision 7920 (Xeon W-2295, 128 GB RAM, 7.000 $ ESRI-Advanced-Lizenz)
Die 368x-Zahl sorgt für Aufmerksamkeit, aber die eigentliche Geschichte sind die Kosten. Dieser ArcPy-Lauf benotigte eine 7.000 $/Jahr teure ArcGIS-Advanced-Lizenz auf einem 3.000 $ teuren Desktop. Der Databricks-Lauf kostete 0,47 $ an Rechenleistung. Bei 52 wochentlichen Laeufen: 24,44 $/Jahr gegenuber 10.000 $+/Jahr.
Kostenvergleich vs. ESRI
Über die reine Leistung hinaus addiert sich der Kostenunterschied mit der Zeit. Hier ein direkter Vergleich für ein mittelgrosses Geospatial-Team (20-50 Nutzer, 1 TB Vektordaten, wochentliche Batch-Analyse).
ESRI-STACK
GESAMT JAHR 1
60.000-200.000 $+
GESAMT JAHR 3
180.000-600.000 $+
DATABRICKS-STACK
GESAMT JAHR 1
5.000-15.000 $
GESAMT JAHR 3
15.000-45.000 $
EHRLICHER HINWEIS: MIGRATION IST NICHT KOSTENLOS
Jahr 1 beinhaltet den Migrationsaufwand. Kalkulieren Sie 4-8 Wochen Engineering-Zeit für die Migration von ArcPy-Skripten und die Schulung der Analysten. Das sind reale Kosten, die Cloud-Anbieter gerne verschweigen. Für Teams, die diesen Wechsel prüfen, behandelt unser ArcPy-Migrations-Playbook die Ökosystem-Bewertung im Detail.
Wann Sie Databricks für Geodaten NICHT verwenden sollten
Dieser Abschnitt schafft das meiste Vertrauen. Wir bieten Databricks-Migrationsdienste an. Trotzdem raten wir Kunden in diesen Szenarien davon ab:
1. Kleine Datensätze (unter 1 Mio. Datensätze)
PostGIS auf einem einzelnen Server ist einfacher, gunstiger und schnell genug. Der Databricks-Overhead (Cluster-Start, Job-Scheduling) lohnt sich nicht für kleine Datenmengen. Ein 20 $/Monat teures verwaltetes Postgres bewaltigt die meisten kleinen bis mittleren Workloads besser.
2. Echtzeit-Raumanfragen
Databricks ist batch-orientiert. Der Cluster-Start allein dauert 2-5 Minuten. Für Raumanfragen unter einer Sekunde, die eine Webanwendung bedienen, verwenden Sie PostGIS oder einen dedizierten Raumindex (R-Baum). Databricks wird die Latenz eines warmen In-Memory-Raumindex nie erreichen.
3. Umfangreiche Rasterverarbeitung
Databricks ist vektorzentriert. Für grossskalige Rasteranalysen (Satellitenbild- Zeitreihen, DEM-Verarbeitung, Multibandklassifikation) sollten Sie Google Earth Engine oder eine dedizierte Rasterverarbeitungs-Pipeline in Betracht ziehen. Die FUSE-Dateisystem-Einschränkung bei TIFFs macht rasterintensive Arbeit muhsam.
4. Teams ohne bestehende Databricks-Nutzung
Wenn Ihre Organisation Databricks noch nicht nutzt, ist der Aufwand für die Einführung NUR für Geodaten selten gerechtfertigt. Plattformlizenzierung, Schulungen, Infrastrukturaufbau - das Argument der inkrementellen Kosten fallt weg, wenn keine bestehende Investition vorhanden ist. Beginnen Sie mit PostGIS oder DuckDB Spatial.
5. Desktop-Workflows, die gut funktionieren
Wenn ein Analyst wochentlich 10 Dateien in QGIS bearbeitet und mit den Ergebnissen zufrieden ist, migrieren Sie nicht um des Migrierens willen. Cloud-Migration hat während des Ubergangs reale Produktivitatskosten. Der Analyst, der jeden ArcGIS-Shortcut kannte, ist in Notebooks ein Anfanger. Migrieren Sie nur dann, wenn der Massstab es erfordert.
Erste Schritte
Wenn Sie bis hierher gelesen haben und Databricks für Ihre Workloads noch sinnvoll erscheint, folgt hier das Minimum Viable Setup:
1. Cluster-Konfiguration
Beginnen Sie mit 2x i3.xlarge Workern (4 vCPU, 30,5 GB RAM je). Aktivieren Sie Photon. Verwenden Sie Runtime 17 LTS für natives Spatial SQL. Aktivieren Sie Autoscaling (min. 2, max. 8), um unterschiedliche Workloads ohne Mehrkosten zu bewaltigen. Nutzen Sie Cluster Pools, um die Startzeit von 3-8 Minuten auf unter 60 Sekunden zu reduzieren - Pools halten Instanzen warm und bereit. Diese Konfiguration bewaltigt die meisten mittelgrossen Geodaten-Workloads (bis 100 Mio. Datensätze) problemlos.
2. Mosaic aktivieren (optional)
Installieren Sie das databricks-mosaic-Paket via pip in Ihrem Notebook, dann initialisieren Sie es auf Ihrer Spark-Session. Tun Sie das nur, wenn Ihre Workloads Spatial Joins mit 50 Mio.+ Datensatzen beinhalten, bei denen H3-Indexierung einen messbaren Vorteil bringt. Für kleinere Workloads reicht natives Spatial SQL ohne Mosaic.
3. GeoParquet aus Cloud-Speicher lesen
Lesen Sie GeoParquet-Dateien direkt aus S3, Azure Data Lake Storage oder GCS mit Sparks nativem GeoParquet-Reader. Keine Formatkonvertierung erforderlich. Der Reader übernimmt die Geometrie-Deserialisierung automatisch, und Spaltenzugriff bedeutet, dass nur die in Ihrer Abfrage referenzierten Spalten gelesen werden.
4. Als Delta-Tabelle registrieren und abfragen
Schreiben Sie Ihre GeoParquet-Daten in eine Delta-Lake-Tabelle, die im Unity Catalog registriert ist. Ab diesem Punkt funktioniert jede Spatial-SQL-Abfrage direkt gegen die Tabelle - ST_Contains, ST_Buffer, ST_Distance und der volle Satz von 90+ raumlichen Funktionen. Ihre Analysten können sie aus SQL-Notebooks, BI-Tools oder programmatischen APIs abfragen.
Von null bis zu laufenden Raumanfragen: ca. 30 Minuten, wenn Sie bereits einen Databricks-Workspace haben. Der grosste Teil dieser Zeit entfallt auf das Warten, bis der Cluster startet. Die raumliche Fähigkeit selbst erfordert keine zusatzliche Infrastruktur.
Haufig gestellte Fragen
Kann Databricks Geodaten verarbeiten?
Ja. Databricks verfügt über 90+ native Spatial-SQL-Funktionen, H3-Indexierung via der Mosaic-Bibliothek und nativen GeoParquet-Support. Vektordaten werden im grossen Massstab (100 Mio.+ Datensätze) hervorragend verarbeitet. Die Raster-Unterstützung verbessert sich, erfordert derzeit jedoch Workarounds für wahlfreie Dateizugriffe.
Ist Databricks schneller als ArcGIS für raumliche Analysen?
Bei umfangreichen Batch-Operationen deutlich schneller. Ein Spatial Join über 50 Mio. Flurstuecke lauft in 2,3 Sekunden auf Databricks gegenuber 847 Sekunden in ArcPy (368x schneller). Für kleine Datensätze oder Echtzeit-Abfragen kann jedoch ein einfacheres Werkzeug wie PostGIS besser geeignet sein.
Was kostet Databricks für geospatiale Workloads?
Ein wochentlicher Spatial-Analyse-Job auf einem 4-Knoten-Cluster kostet ca. 0,47 $ pro Lauf (24 $/Jahr). Zum Vergleich: eine ArcGIS-Advanced-Lizenz kostet 7.000 $/Jahr. Speicher auf Delta Lake kostet ca. 23 $/Monat pro TB Vektordaten.
Databricks ist nicht für jeden die richtige Wahl. Aber für Teams, die die Plattform bereits nutzen, gehort das Hinzufügen von Geodaten zu den hochst rentablen Massnahmen.
368x schneller. 90 % gunstiger. Und Ihre Datenanalysten können die Abfragen in SQL schreiben, das sie bereits kennen. Die Hurde ist nicht die Technologie - es sind die Muster, die in der Produktion funktionieren, und die Stolpersteine, die in Tutorials nicht auftauchen.
Dafur ist diese Serie gedacht. Ehrliche, praxiserprobte Anleitungen für den Betrieb geospatialer Workloads in der Cloud.
Workflow-Automatisierung Einblicke erhalten
Monatliche Tipps zur Automatisierung von GIS-Workflows, Open-Source-Tools und Erkenntnisse aus Enterprise-Deployments. Kein Spam.