Databricks Spatial Joins jetzt standardmäßig 17-mal schneller

Die Verarbeitung und Analyse von Geodaten ist für Geodaten-Workloads auf Databricks geschäftskritisch. Viele Teams verlassen sich auf externe Bibliotheken oder Spark-Erweiterungen wie Apache Sedona, Geopandas und das Databricks Lab-Projekt Mosaic, um diese Workloads zu verarbeiten. Obwohl Kunden erfolgreich waren, führen diese Ansätze zu zusätzlichem Betriebsaufwand und erfordern oft ein Tuning, um eine akzeptable Performance zu erreichen.

Anfang dieses Jahres veröffentlichte Databricks die Unterstützung für Spatial SQL, das jetzt 90 Spatial-Funktionen und die Unterstützung für die Speicherung von Daten in GEOMETRY - oder GEOGRAPHY -Spalten umfasst. Das in Databricks integrierte Spatial SQL ist im Vergleich zu allen Alternativen der beste Ansatz für die Speicherung und Verarbeitung von Vektordaten, da es alle primären Herausforderungen bei der Verwendung von Add-on-Bibliotheken löst: hohe Stabilität, rasante Performance und mit Databricks SQL Serverless entfällt die Notwendigkeit, klassische Cluster, Bibliothekskompatibilität und Laufzeitversionen zu verwalten.

Eine der häufigsten Tasks bei der räumlichen Verarbeitung ist der Vergleich, ob sich zwei Geometrien überlappen, eine Geometrie die andere enthält oder wie nahe sie beieinander liegen. Diese Analyse erfordert die Verwendung von Spatial Joins, für die eine hervorragende Out-of-the-Box-Performance unerlässlich ist, um die Zeit bis zu räumlichen Erkenntnissen zu verkürzen.

Räumliche Joins bis zu 17-mal schneller mit Databricks SQL Serverless

Wir freuen uns, bekannt zu geben, dass jeder Kunde, der das integrierte Spatial SQL für Spatial Joins verwendet, eine bis zu 17-mal schnellere Performance feststellen wird, im Vergleich zu klassischen Clustern mit installiertem Apache Sedona1. Die Performance-Verbesserungen sind für alle Kunden verfügbar, die Databricks SQL serverlos und klassische Cluster mit Databricks Runtime (DBR) 17.3 verwenden. Wenn Sie bereits die integrierten räumlichen Prädikate von Databricks wie ST_Intersects oder ST_Contains verwenden, ist keine Codeänderung erforderlich.

Die Ausführung von Spatial Joins birgt besondere Herausforderungen, wobei die Performance von mehreren Faktoren beeinflusst wird. Geodatasets sind oft stark verzerrt, z. B. in dicht besiedelten städtischen Regionen und dünn besiedelten ländlichen Gebieten, und weisen eine sehr unterschiedliche geometrische Komplexität auf, wie z. B. die komplexe norwegische Küstenlinie im Vergleich zu den einfachen Grenzen von Colorado. Selbst nach einem effizienten „File Pruning“ erfordern die verbleibenden Join-Kandidaten immer noch rechenintensive geometrische Operationen. Hier kann Databricks seine Stärken ausspielen.

Die Verbesserung bei Spatial Joins ergibt sich aus der Verwendung von R-Tree-Indizierung, optimierten Spatial Joins in Photon und intelligenter Range-Join-Optimierung, die alle automatisch angewendet werden. Sie schreiben Standard-SQL mit räumlichen Funktionen und die Engine übernimmt die Komplexität.

Die geschäftliche Bedeutung von räumlichen Joins 

Ein räumlicher Join ähnelt einem Datenbank-Join, aber anstatt IDs abzugleichen, wird ein räumliches Prädikat verwendet, um Daten anhand des Standorts abzugleichen. Räumliche Prädikate bewerten die relative physische Beziehung, wie z. B. Überlappung, Einschluss oder Nähe, um zwei Datasets zu verbinden. Räumliche Joins sind ein leistungsstarkes Werkzeug für die räumliche Aggregation und helfen Analysten, Trends, Muster und standortbezogene Erkenntnisse an verschiedenen Orten aufzudecken, von Einkaufszentren und landwirtschaftlichen Betrieben bis hin zu Städten und dem gesamten Planeten.

Räumliche Joins beantworten geschäftskritische Fragen branchenübergreifend. Zum Beispiel:

• Küstenbehörden überwachen den Schiffsverkehr innerhalb eines Hafens oder nautischer Grenzen
• Einzelhändler analysieren den Fahrzeugverkehr und die Besuchsmuster an den verschiedenen Filialstandorten
• Moderne Landwirtschaftsunternehmen führen Ertragsanalysen und -prognosen durch, indem sie Wetter-, Feld- und Saatgutdaten kombinieren.
• Behörden für öffentliche Sicherheit und Versicherungen ermitteln, welche Häuser durch Hochwasser oder Feuer gefährdet sind.
• Betriebsteams von Energie- und Versorgungsunternehmen erstellen Dienst- und Infrastrukturpläne auf der Grundlage von Analysen von Energiequellen, der Wohn- und Gewerbeflächennutzung und bestehenden Assets (Vermögenswerte).

Vorbereitung für den Spatial-Join-Benchmark

Für die Daten haben wir vier weltweite, umfangreiche Datensätze von der Overture Maps Foundation ausgewählt: Adressen, Gebäude, Landnutzung und Straßen. Sie können die Abfragen mithilfe der unten beschriebenen Methoden selbst testen. 

Wir haben Overture Maps-Datasets verwendet, die ursprünglich als GeoParquet heruntergeladen wurden. Ein Beispiel für die Vorbereitung von Adressen für das Sedona-Benchmarking wird unten gezeigt. Alle Datasets folgten demselben Muster.

Wir haben die Daten auch in Lakehouse-Tabellen verarbeitet und dabei das Parquet-WKB in native GEOMETRY Datentypen für das Databricks-Benchmarking konvertiert. 

Vergleichsabfragen

Das obige Diagramm verwendet denselben Satz von drei Abfragen, die mit jedem Compute getestet wurden. 

Abfrage Nr. 1 – ST_Contains(buildings, addresses)

Diese Abfrage wertet die 2,5 Mrd. Gebäudepolygone aus, die die 450 Mio. Adresspunkte enthalten (Punkt-in-Polygon-Join). Das Ergebnis sind über 200 Mio. Übereinstimmungen. Für Sedona haben wir dies in ST_Within(a.geom, b.geom) umgekehrt, um die standardmäßige linksseitige Build-Optimierung zu unterstützen. Auf Databricks gibt es keinen wesentlichen Unterschied zwischen der Verwendung von ST_Contains oder ST_Within.

Abfrage #2 – ST_Covers(landuse, buildings)

Diese Abfrage wertet die 1,3 Mio. weltweiten `industrial`-Landnutzungspolygone aus, die die 2,5 Mrd. Gebäudepolygone abdecken. Das Ergebnis sind mehr als 25 Mio. Übereinstimmungen.

Abfrage #3 - ST_Intersects(roads, landuse)

Diese Abfrage wertet die 300 Mio. Straßen aus, die sich mit den 10 Mio. weltweiten „Wohngebiet“-Flächennutzungspolygonen überschneiden. Das Ergebnis sind mehr als 100 Mio. Übereinstimmungen. Für Sedona haben wir dies zu ST_Intersects(l.geom, trans.geom) umgekehrt, um die Standard- linksseitige Build-Optimierung zu unterstützen. 

Die Zukunft von Spatial SQL und nativen Typen

Databricks fügt auf der Grundlage von Kundenwünschen weiterhin neue räumliche Ausdrücke hinzu. Hier ist eine Liste der räumlichen Funktionen, die seit der Public Preview hinzugefügt wurden: ST_AsEWKB, ST_Dump, ST_ExteriorRing, ST_InteriorRingN, ST_NumInteriorRings. Jetzt in DBR 18.0 Beta verfügbar: ST_Azimuth, ST_Boundary, ST_ClosestPoint, Unterstützung für die Aufnahme von EWKT, einschließlich zwei neuer Ausdrücke, ST_GeogFromEWKT und ST_GeomFromEWKT, sowie Leistungs- und Stabilitätsverbesserungen für ST_IsValid, ST_MakeLine und ST_MakePolygon. 

Geben Sie dem Produktteam Ihr Feedback

Wenn Sie uns Ihre Wünsche für zusätzliche ST-Ausdrücke oder Geospatial-Features mitteilen möchten, füllen Sie bitte diese kurze Umfrage aus. 

Update: Veröffentlichung von Geotypen in Apache Spark™ als Open Source.

Der Beitrag von GEOMETRY und GEOGRAPHY Datentypen zu Apache Spark™ hat große Fortschritte gemacht und ist auf gutem Weg, 2026 in Spark 4.2 übernommen zu werden.

Testen Sie Spatial SQL kostenlos

Führen Sie noch heute Ihre nächste räumliche Query in Databricks SQL aus – und erleben Sie, wie schnell Ihre räumlichen Joins sein können. Weitere Informationen zu den Spatial-SQL-Funktionen finden Sie in der SQL - und der Pyspark -Dokumentation. Zusätzliche Informationen zu Databricks SQL finden Sie auf der Website, in der Produkttour und in der Databricks Free Edition. Wenn Sie Ihr bestehendes Warehouse auf ein hochleistungsfähiges, serverloses Data Warehouse mit hervorragender Benutzererfahrung und geringeren Gesamtkosten migrieren möchten, ist Databricks SQL die Lösung – testen Sie es kostenlos.