Las uniones espaciales de Databricks ahora son 17 veces más rápidas de inmediato

El procesamiento y el análisis de datos espaciales son fundamentales para el negocio para las cargas de trabajo geoespaciales en Databricks. Muchos equipos utilizan bibliotecas externas o extensiones de Spark como Apache Sedona, Geopandas, Databricks Lab project Mosaic, para gestionar estas cargas de trabajo. Aunque los clientes han tenido éxito, estos enfoques añaden sobrecarga operativa y a menudo requieren ajustes para alcanzar un rendimiento aceptable.

A principios de este año, Databricks lanzó la compatibilidad con Spatial SQL, que ahora incluye 90 funciones espaciales y compatibilidad para almacenar datos en columnas GEOMETRY o GEOGRAPHY. El Spatial SQL integrado de Databricks es el mejor enfoque para almacenar y procesar datos vectoriales en comparación con cualquier otra alternativa porque soluciona todos los desafíos principales del uso de bibliotecas complementarias: es altamente estable, tiene un rendimiento ultrarrápido y, con Databricks SQL Serverless, no es necesario gestionar clústeres clásicos, compatibilidad de bibliotecas ni versiones de tiempo de ejecución.

Una de las tareas de procesamiento espacial más comunes es comparar si dos geometrías se superponen, si una contiene a la otra o qué tan cerca están una de la otra. Este análisis requiere el uso de uniones espaciales, para las cuales un gran rendimiento inmediato es esencial para acelerar el tiempo de obtención de información espacial.

Uniones espaciales hasta 17 veces más rápidas con Databricks SQL Serverless

Nos complace anunciar que todos los clientes que utilizan SQL espacial integrado para uniones espaciales, experimentarán un rendimiento hasta 17 veces más rápido en comparación con los clústeres clásicos con Apache Sedona1 instalado. Las mejoras de rendimiento están disponibles para todos los clientes que utilizan Databricks SQL Serverless y clústeres clásicos con Databricks Runtime (DBR) 17.3. Si ya utiliza los predicados espaciales integrados de Databricks, como ST_Intersects o ST_Contains, no se requiere ningún cambio en el código.

La ejecución de uniones espaciales presenta desafíos únicos, y el rendimiento se ve influenciado por múltiples factores. Los conjuntos de datos geoespaciales suelen estar muy sesgados, como en el caso de las regiones urbanas densas y las zonas rurales dispersas, y varían mucho en complejidad geométrica, como la intrincada costa noruega en comparación con las sencillas fronteras de Colorado. Incluso después de una poda eficiente de archivos, los candidatos de unión restantes aún requieren operaciones geométricas de cómputo intensivo. Aquí es donde Databricks se destaca.

La mejora de la unión espacial se debe al uso de la indexación R-tree, las uniones espaciales optimizadas en Photon y la optimización inteligente de la unión de rangos, todo ello aplicado automáticamente. Escribes SQL estándar con funciones espaciales y el motor se encarga de la complejidad.

La importancia comercial de las uniones espaciales 

Una unión espacial es similar a una unión de base de datos, pero en lugar de hacer coincidir los ID, utiliza un predicado espacial para hacer coincidir los datos según la ubicación. Los predicados espaciales evalúan la relación física relativa, como la superposición, la contención o la proximidad, para conectar dos conjuntos de datos. Las uniones espaciales son una herramienta potente para la agregación espacial, ya que ayudan a los analistas a descubrir tendencias, patrones y estadísticas basadas en la ubicación en diferentes lugares, desde centros comerciales y granjas hasta ciudades y el planeta entero.

Las uniones espaciales responden a preguntas críticas para el negocio en todos los sectores. Por ejemplo:

• Las autoridades costeras supervisan el tráfico de embarcaciones dentro de un puerto o de los límites náuticos
• Los minoristas analizan el tráfico vehicular y los patrones de visita en las distintas sucursales
• Las empresas agrícolas modernas analizan y pronostican el rendimiento de los cultivos combinando datos meteorológicos, de campo y de semillas.
• Las agencias de seguridad pública y las compañías de seguros localizan qué viviendas corren riesgo de inundación o incendio.
• Los equipos de operaciones de energía y servicios públicos elaboran planes de servicio e infraestructura basados en el análisis de las fuentes de energía, el uso de la tierra residencial y comercial y los activos existentes

Preparación del benchmark de unión espacial

Para los datos, seleccionamos cuatro conjuntos de datos a gran escala de todo el mundo de Overture Maps Foundation: Addresses, Buildings, Landuse y Roads. Puede probar las consultas usted mismo utilizando los métodos que se describen a continuación. 

Usamos los conjuntos de datos de Overture Maps, que se descargaron inicialmente como GeoParquet. A continuación, se muestra un ejemplo de preparación de direcciones para el benchmarking de Sedona. Todos los conjuntos de datos siguieron el mismo patrón.

También procesamos los datos en tablas de Lakehouse, convirtiendo el WKB de parquet en tipos de datos nativos de GEOMETRY para la evaluación comparativa de Databricks. 

Consultas de comparación

El gráfico anterior utiliza el mismo conjunto de tres consultas, probadas en cada cómputo. 

Consulta n.º 1: ST_Contains(buildings, addresses)

Esta consulta evalúa los 2500 millones de polígonos de edificios que contienen los 450 millones de puntos de dirección (unión punto en polígono). El resultado son más de 200 millones de coincidencias. Para Sedona, invertimos esto a ST_Within(a.geom, b.geom) para admitir la optimización predeterminada de la compilación en el lado izquierdo. En Databricks, no hay ninguna diferencia sustancial entre usar ST_Contains o ST_Within.

Consulta n.º 2 - ST_Covers(landuse, buildings)

Esta consulta evalúa los 1.3 millones de polígonos de uso de suelo `industrial` de todo el mundo que cubren los 2500 millones de polígonos de edificios. El resultado es más de 25 millones de coincidencias.

Consulta n.º 3 - ST_Intersects(roads, landuse)

Esta consulta evalúa los 300 millones de carreteras que se cruzan con los 10 millones de polígonos de 'uso residencial' de suelo en todo el mundo. El resultado es más de 100 millones de coincidencias. Para Sedona, invertimos esto a ST_Intersects(l.geom, trans.geom) para admitir la optimización predeterminada de la compilación del lado izquierdo. 

¿Qué sigue para Spatial SQL y los tipos nativos?

Databricks continúa agregando nuevas expresiones espaciales según las solicitudes de los clientes. Esta es una lista de funciones espaciales que se agregaron desde la versión preliminar pública: ST_AsEWKB, ST_Dump, ST_ExteriorRing, ST_InteriorRingN, ST_NumInteriorRings. Ya disponibles en la versión beta de DBR 18.0: ST_Azimuth, ST_Boundary, ST_ClosestPoint, compatibilidad con la ingesta de EWKT, incluidas dos expresiones nuevas, ST_GeogFromEWKT y ST_GeomFromEWKT, y mejoras de rendimiento y solidez para ST_IsValid, ST_MakeLine y ST_MakePolygon. 

Envía tus comentarios al equipo de producto

Si desea compartir sus solicitudes de expresiones ST o funciones geoespaciales adicionales, complete esta breve encuesta. 

Actualización: tipos geográficos de código abierto en Apache Spark

La contribución de los tipos de datos GEOMETRY y GEOGRAPHY a Apache Spark™ ha avanzado considerablemente y está previsto que se incorpore a Spark 4.2 en 2026.

Prueba Spatial SQL gratis

Ejecute su próxima consulta espacial en Databricks SQL hoy mismo y compruebe lo rápidas que pueden ser sus uniones espaciales. Para obtener más información sobre las funciones de SQL espacial, consulte la documentación de SQL y Pyspark. Para obtener más información sobre Databricks SQL, consulte el sitio web, la visita guiada del producto y la edición gratuita de Databricks. Si desea migrar su almacén de datos existente a un almacén de datos sin servidor y de alto rendimiento con una excelente experiencia de usuario y un menor costo total, entonces Databricks SQL es la solución: pruébelo gratis.