Les jointures spatiales Databricks sont désormais 17 fois plus rapides d'emblée

Le traitement et l'analyse des données spatiales sont essentiels pour les workloads géospatiaux sur Databricks. De nombreuses équipes s'appuient sur des bibliothèques externes ou des extensions Spark comme Apache Sedona, Geopandas, le projet Mosaic de Databricks Lab, pour gérer ces workloads. Bien que les clients aient obtenu de bons résultats, ces approches ajoutent une charge opérationnelle et nécessitent souvent des réglages pour atteindre des performances acceptables.

Au début de cette année, Databricks a lancé la prise en charge du SQL spatial, qui inclut désormais 90 fonctions spatiales et la prise en charge du stockage des données dans des colonnes GEOMETRY ou GEOGRAPHY. Le SQL spatial intégré à Databricks est la meilleure approche pour stocker et traiter les données vectorielles par rapport à n'importe quelle autre alternative, car il répond à tous les principaux défis liés à l'utilisation de bibliothèques complémentaires: haute stabilité, performances fulgurantes et, avec Databricks SQL Serverless, plus besoin de gérer les clusters classiques, la compatibilité des bibliothèques et les versions d'exécution.

L'une des tâches de traitement spatial les plus courantes consiste à comparer si deux géométries se chevauchent, si une géométrie en contient une autre ou à quelle distance elles se trouvent l'une de l'autre. Cette analyse nécessite l'utilisation de jointures spatiales, pour lesquelles d'excellentes performances prêtes à l'emploi sont essentielles pour accélérer l'obtention d'insight spatial.

Jointures spatiales jusqu'à 17 fois plus rapides avec Databricks SQL Serverless

Nous sommes ravis d'annoncer que tous les clients qui utilisent le Spatial SQL intégré pour les jointures spatiales bénéficieront de performances jusqu'à 17 fois plus rapides par rapport aux clusters classiques sur lesquels Apache Sedona1 est installé. Ces améliorations de performances sont disponibles pour tous les clients qui utilisent Databricks SQL Serverless et les clusters classiques avec Databricks Runtime (DBR) 17.3. Si vous utilisez déjà les prédicats spatiaux intégrés de Databricks, tels que ST_Intersects ou ST_Contains, aucun changement de code n'est nécessaire.

L'exécution de jointures spatiales présente des défis uniques, avec des performances influencées par de multiples facteurs. Les datasets géospatiales sont souvent très asymétriques, comme c'est le cas avec des régions urbaines denses et des zones rurales éparses, et leur complexité géométrique varie considérablement, comme le littoral norvégien complexe par rapport aux frontières simples du Colorado. Même après un élagage efficace des fichiers, les candidats à la jointure restants nécessitent toujours des opérations géométriques gourmandes en calcul. C'est là que Databricks excelle.

L'amélioration de la jointure spatiale provient de l'utilisation de l'indexation R-tree, des jointures spatiales optimisées dans Photon et de l'optimisation intelligente des jointures par plage, le tout appliqué automatiquement. Vous écrivez du SQL standard avec des fonctions spatiales, et le moteur gère la complexité.

L'importance commerciale des jointures spatiales 

Une jointure spatiale est similaire à une jointure de base de données, mais au lieu de faire correspondre des ID, elle utilise un prédicat spatial pour faire correspondre des données en fonction de leur emplacement. Les prédicats spatiaux évaluent la relation physique relative, comme la superposition, le confinement ou la proximité, pour connecter deux jeux de données. Les jointures spatiales sont un outil puissant pour l'agrégation spatiale, qui aide les analystes à découvrir des tendances, des motifs et des insights basées sur la localisation dans différents lieux, des centres commerciaux et des fermes aux villes et à la planète entière.

Les jointures spatiales répondent à des questions critiques pour l'entreprise dans tous les secteurs d'activité. Par exemple :

• Les autorités côtières surveillent le trafic des navires au sein d'un port ou de limites nautiques
• Les détaillants analysent le trafic des véhicules et les schémas de visites dans leurs différents points de vente
• Les entreprises agricoles modernes effectuent des analyses et des prévisions de rendement des cultures en combinant les données météorologiques, les données des champs et les données sur les semences
• Les organismes de sécurité publique et les compagnies d'assurance localisent les habitations menacées par les inondations ou les incendies.
• Les équipes des Opérations du secteur de l'énergie et des infrastructures publiques élaborent des plans de service et d'infrastructure en se basant sur l'analyse des sources d'énergie, de l'utilisation des terres à des fins résidentielles et commerciales et des assets existants.

Préparation à l'évaluation comparative de la jointure spatiale

Pour les données, nous avons sélectionné quatre datasets mondiaux à grande échelle de la Overture Maps Foundation : Adresses, Bâtiments, Utilisation du sol et Routes. Vous pouvez tester les requêtes vous-même en utilisant les méthodes décrites ci-dessous. 

Nous avons utilisé les jeux de données Overture Maps, qui ont été initialement téléchargés au format GeoParquet. Un exemple de préparation d'adresses pour le benchmarking de Sedona est présenté ci-dessous. Tous les jeux de données suivaient le même modèle.

Nous avons également traité les données dans des tables Lakehouse, en convertissant le WKB parquet en types de données GEOMETRY natifs pour le benchmarking de Databricks. 

Requêtes de comparaison

Le graphique ci-dessus utilise le même ensemble de trois queries, testées sur chaque compute. 

Query n°1 - ST_Contains(buildings, addresses)

Cette query évalue les 2,5 milliards de polygones de bâtiments qui contiennent les 450 millions de points d'adresses (jointure point dans polygone). Le résultat est de plus de 200 millions de correspondances. Pour Sedona, nous avons inversé cette opération en ST_Within(a.geom, b.geom) pour prendre en charge l'optimisation par default du côté de la construction à gauche. Sur Databricks, il n'y a pas de différence significative entre l'utilisation de ST_Contains ou de ST_Within.

Requête n°2 - ST_Covers(landuse, buildings)

Cette query évalue les 1,3 million de polygones d'affectation des sols de type `industrial` à l'échelle mondiale qui couvrent les 2,5 milliards de polygones de bâtiments. Le résultat est de plus de 25 millions de correspondances.

query n°3 - ST_Intersects(roads, landuse)

Cette query évalue les 300 millions de routes qui croisent les 10 millions de polygones d'affectation des sols de type « residential » à l'échelle mondiale. Le résultat est de plus de 100 millions de correspondances. Pour Sedona, nous avons inversé cette opération en ST_Intersects(l.geom, trans.geom) afin de prendre en charge l'optimisation par default du côté de la construction à gauche. 

Quel avenir pour le SQL spatial et les types natifs ?

Databricks continue d'ajouter de nouvelles expressions spatiales en fonction des demandes des clients. Voici une liste de fonctions spatiales ajoutées depuis la Public Preview : ST_AsEWKB, ST_Dump, ST_ExteriorRing, ST_InteriorRingN, ST_NumInteriorRings. Disponible dès maintenant dans la version bêta 18.0 de DBR : ST_Azimuth, ST_Boundary, ST_ClosestPoint, la prise en charge de l'ingestion d'EWKT, y compris deux nouvelles expressions, ST_GeogFromEWKT et ST_GeomFromEWKT, ainsi que des améliorations de la performance et de la robustesse pour ST_IsValid, ST_MakeLine, et ST_MakePolygon. 

Faites part de vos commentaires à l'équipe Produit

Si vous souhaitez nous faire part de vos demandes d'expressions ST ou de fonctionnalités géospatiales supplémentaires, veuillez remplir ce court sondage. 

Mise à jour : les types géospatiaux deviennent open source dans Apache Spark™

La contribution des types de données GEOMETRY et GEOGRAPHY à Apache Spark™ a beaucoup progressé et devrait être intégrée à Spark 4.2 en 2026.

Essayez SQL Spatial gratuitement

Exécutez votre prochaine requête spatiale sur Databricks SQL dès aujourd'hui et découvrez la vitesse de vos jointures spatiales. Pour en savoir plus sur les fonctions SQL spatiales, consultez la documentation SQL et Pyspark. Pour plus d'informations sur Databricks SQL, consultez le site Web, la visite du produit et l'édition gratuite de Databricks. Si vous souhaitez migrer votre existing warehouse vers un high-performance, serverless data warehouse avec une excellente expérience utilisateur et un coût total inférieur, alors Databricks SQL est la solution qu'il vous faut : essayez-la gratuitement.