O processamento e a análise de dados espaciais são essenciais para os negócios para cargas de trabalho geoespaciais no Databricks. Muitas equipes contam com bibliotecas externas ou extensões Spark como Apache Sedona, Geopandas, projeto Mosaic do Databricks Lab, para lidar com essas cargas de trabalho. Embora os clientes tenham tido sucesso, essas abordagens acrescentam sobrecarga operacional e muitas vezes exigem ajustes para atingir um desempenho aceitável.
No início deste ano, o Databricks lançou suporte para SQL espacialque agora inclui 90 funções espaciais e suporte para armazenamento de dados em GEOMETRIA ou GEOGRAFIA colunas. Spatial SQL integrado do Databricks é a melhor abordagem para armazenar e processar dados vetoriais em comparação com qualquer alternativa porque aborda todos os principais desafios do uso de bibliotecas complementares: desempenho altamente estável e incrível e com Databricks SQL Serverless, não há necessidade de gerenciar clusters clássicos, compatibilidade de biblioteca e versões de tempo de execução.
Uma das tarefas mais comuns de processamento espacial é comparar se duas geometrias se sobrepõem, onde uma geometria contém a outra ou quão próximas elas estão uma da outra. Esta análise requer o uso de junções espaciais, para as quais um excelente desempenho pronto para uso é essencial para acelerar o tempo de obtenção de insights espaciais.
Spatial junta-se até 17x mais rápido com Databricks SQL Serverless
Temos o prazer de anunciar que todos os clientes que usam SQL Espacial integrado para junções espaciais, verá um desempenho até 17x mais rápido em comparação com clusters clássicos com Apache Sedona1 instalado. As melhorias de desempenho estão disponíveis para todos os clientes que usam Databricks SQL sem servidor e clusters clássicos com Databricks Runtime (DBR) 17.3. Se você já estiver usando predicados espaciais integrados do Databricks, como ST_Intersecta ou ST_Contémnenhuma alteração de código é necessária.
Apache Sedona 1.7 não period compatível com DBR 17.x na época dos benchmarks, foi usado DBR 16.4.
A execução de junções espaciais apresenta desafios únicos, com desempenho influenciado por múltiplos fatores. Os conjuntos de dados geoespaciais são frequentemente altamente distorcidos, como acontece com regiões urbanas densas e áreas rurais esparsas, e variam amplamente em complexidade geométrica, como a intrincada costa norueguesa em comparação com as fronteiras simples do Colorado. Mesmo após a remoção eficiente dos arquivos, os candidatos restantes à junção ainda exigem operações geométricas com uso intensivo de computação. É aqui que o Databricks brilha.
A melhoria da junção espacial vem do uso de indexação de árvore R, junções espaciais otimizadas no Photon e otimização de junção de intervalo inteligente, todas aplicadas automaticamente. Você escreve SQL padrão com funções espaciais e o mecanismo lida com a complexidade.
A importância comercial das junções espaciais
Uma junção espacial é semelhante a uma junção de banco de dados, mas em vez de IDs correspondentes, ela usa um predicado espacial para combinar dados com base na localização. Os predicados espaciais avaliam o relacionamento físico relativo, como sobreposição, contenção ou proximidade, para conectar dois conjuntos de dados. As junções espaciais são uma ferramenta poderosa para agregação espacial, ajudando os analistas a descobrir tendências, padrões e insights baseados em localização em diferentes locais, desde purchasing facilities e fazendas até cidades e todo o planeta.
As junções espaciais respondem a questões críticas de negócios em todos os setores. Por exemplo:
- As autoridades costeiras monitorizam o tráfego de navios dentro de um porto ou limites náuticos
- Os varejistas analisam o tráfego de veículos e os padrões de visitação nas lojas
- As empresas agrícolas modernas realizam análises e previsões do rendimento das colheitas combinando dados meteorológicos, de campo e de sementes
- Agências de segurança pública e companhias de seguros localizam quais casas estão em risco de inundação ou incêndio
- As equipes de operações de energia e serviços públicos criam planos de serviços e infraestrutura com base na análise de fontes de energia, uso de terrenos residenciais e comerciais e ativos existentes
Preparação de benchmark de junção espacial
Para os dados, selecionamos quatro conjuntos de dados mundiais de grande escala da Overture Maps Basis: Endereços, Edifícios, Uso do Solo e Estradas. Você mesmo pode testar as consultas usando os métodos descritos abaixo.
Usamos conjuntos de dados do Overture Maps, que foram inicialmente baixados como GeoParquet. Um exemplo de preparação de endereços para o benchmarking de Sedona é mostrado abaixo. Todos os conjuntos de dados seguiram o mesmo padrão.
Também processamos os dados em tabelas Lakehouse, convertendo o parquet WKB em nativo GEOMETRIA tipos de dados para benchmarking do Databricks.
Consultas de comparação
O gráfico acima usa o mesmo conjunto de três consultas, testadas em cada computação.
Consulta nº 1 – ST_Contains(edifícios, endereços)
Esta consulta avalia os polígonos de construção de 2,5B que contêm os pontos de endereço de 450M (junção de ponto no polígono). O resultado são mais de 200 milhões de partidas. Para Sedona, invertemos isso para ST_Within(a.geom, b.geom) para oferecer suporte à otimização padrão do lado esquerdo da construção. No Databricks, não há diferença materials entre usar ST_Contém ou ST_Dentro.
Consulta nº 2 – ST_Covers(uso do solo, edifícios)
Esta consulta avalia os 1,3 milhões de polígonos de uso do solo “industriais” em todo o mundo que cobrem os 2,5 bilhões de polígonos de construção. O resultado são mais de 25 milhões de partidas.
Consulta nº 3 – ST_Intersects(estradas, uso do solo)
Esta consulta avalia os 300 milhões de estradas que se cruzam com os 10 milhões de polígonos de uso do solo “residenciais” mundiais. O resultado são mais de 100 milhões de partidas. Para Sedona, invertemos isso para ST_Intersects(l.geom, trans.geom) para oferecer suporte à otimização padrão do lado esquerdo da construção.
O que vem por aí para SQL espacial e tipos nativos
Databricks continua adicionando novas expressões espaciais com base nas solicitações dos clientes. Aqui está uma lista de funções espaciais que foram adicionadas desde a Visualização Pública: ST_AsEWKB, ST_Dump, ST_AnelExterior, ST_InteriorRingN, ST_NumInteriorRings. Disponível agora no DBR 18.0 Beta: ST_Azimuth, ST_Boundary, ST_ClosestPoint, suporte para ingestão de EWKT, incluindo duas novas expressões, ST_GeogFromEWKT e ST_GeomFromEWKT, e melhorias de desempenho e robustez para ST_IsValid, ST_MakeLinee ST_MakePolygon.
Forneça seu suggestions à equipe de produto
Se você gostaria de compartilhar suas solicitações de expressões ST adicionais ou recursos geoespaciais, preencha este breve enquete.
Atualização: tipos geográficos de código aberto no Apache Spark™
A contribuição de GEOMETRIA e GEOGRAFIA tipos de dados para Apache Spark™ fez um grande progresso e está no caminho certo para se comprometer com o Spark 4.2 em 2026.
Experimente o Spatial SQL gratuitamente
Execute sua próxima consulta espacial no Databricks SQL hoje mesmo – e veja quão rápidas podem ser suas junções espaciais. Para saber mais sobre funções SQL espaciais, consulte o SQL e Pyspark documentação. Para obter mais informações sobre Databricks SQL, confira o website, tour do produtoe Edição gratuita do Databricks. Se você deseja migrar seu warehouse existente para um information warehouse de alto desempenho e sem servidor, com uma ótima experiência do usuário e custo whole mais baixo, então o Databricks SQL é a solução — experimente de graça.