join espaciais do Databricks agora 17x mais rápidas nativamente

O processamento e a análise de dados espaciais são cruciais para as cargas de trabalho geoespaciais no Databricks. Muitas equipes dependem de bibliotecas externas ou extensões do Spark, como Apache Sedona, Geopandas e o projeto Mosaic do Databricks Lab, para lidar com essas cargas de trabalho. Embora os clientes tenham tido sucesso, essas abordagens adicionam sobrecarga operacional e geralmente exigem ajuste para atingir um desempenho aceitável.

No início deste ano, o Databricks lançou o suporte para SQL espacial, que agora inclui 90 funções espaciais e suporte para armazenar dados em colunas GEOMETRY ou GEOGRAPHY. O SQL espacial integrada 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: altamente estável, desempenho ultrarrápido e, com o Databricks SQL Serverless, sem a necessidade de gerenciar clusters clássicos, compatibilidade de bibliotecas e versões de Runtime.

Uma das tarefas de processamento espacial mais comuns é 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. Essa análise requer o uso de joins espaciais, para os quais é essencial um excelente desempenho imediato para acelerar o tempo de obtenção da percepção espacial.

joins espaciais até 17x mais rápidas com o Databricks SQL Serverless

Temos o prazer de anunciar que todos os clientes que usam o Spatial SQL integrada para junções espaciais terão um desempenho até 17x mais rápido em comparação com clusters clássicos com o Apache Sedona1 instalado. As melhorias de desempenho estão disponíveis para todos os clientes que usam o Databricks SQL serverless e clusters clássicos com o Databricks Runtime (DBR) 17.3. Se você já usa os predicados espaciais integrados do Databricks, como ST_Intersects ou ST_Contains, nenhuma alteração de código é necessária.

Executar join espaciais apresenta desafios únicos, com o desempenho influenciado por vários fatores. Os datasets geoespaciais são frequentemente muito assimétricos, como em regiões urbanas densas e áreas rurais esparsas, e variam muito em complexidade geométrica, como a intrincada costa norueguesa em comparação com as fronteiras simples do Colorado. Mesmo após uma poda de arquivos eficiente, os candidatos de join restantes ainda exigem operações geométricas compute intensivas. É aqui que o Databricks se destaca.

A melhoria do join espacial vem do uso da indexação de R-tree, joins espaciais otimizados no Photon e otimização inteligente de join de intervalo, tudo aplicado automaticamente. Você escreve SQL padrão com funções espaciais, e o engine lida com a complexidade.

A importância dos joins espaciais para os negócios 

Uma join espacial é semelhante a uma join de banco de dados, mas, em vez de combinar IDs, ela usa um predicado espacial para combinar dados com base na localização. Os predicados espaciais avaliam a relação física relativa, como sobreposição, contenção ou proximidade, para conectar dois datasets. As joins espaciais são uma ferramenta poderosa para agregação espacial, ajudando os analistas a descobrir tendências, padrões e percepções baseadas em localização em diferentes lugares, de shoppings e fazendas a cidades e todo o planeta.

Os joins espaciais respondem a perguntas essenciais para os negócios em todas as indústrias. Por exemplo:

• Autoridades costeiras monitoram o tráfego de embarcações dentro de um porto ou limites náuticos.
• Varejistas analisam o tráfego de veículos e os padrões de visitação nas localidades das lojas.
• Empresas de agricultura moderna realizam análises e previsões de rendimento de safras combinando dados meteorológicos, de campo e de sementes
• Órgãos de segurança pública e seguradoras localizam quais residências estão em risco de inundação ou incêndio.
• As equipes de operações de energia e utilidades criam planos de serviço e infraestrutura com base na análise de fontes de energia, uso do solo residencial e comercial e ativos existentes

Preparação do benchmark de join

Para os dados, selecionamos quatro datasets mundiais em grande escala da Overture Maps Foundation: Endereços, Edifícios, Uso da terra e Estradas. Você mesmo pode testar as queries usando os métodos descritos abaixo. 

Usamos os datasets do Overture Maps, que foram inicialmente baixados como GeoParquet. Um exemplo de preparação de endereços para o benchmarking do Sedona é mostrado abaixo. Todos os conjuntos de dados seguiram o mesmo padrão.

Também processamos os dados em tabelas do Lakehouse, convertendo o WKB do parquet em tipos de dados GEOMETRY nativos para o benchmarking do Databricks.

Consultas de comparação

O gráfico acima usa o mesmo conjunto de três querys, testadas em cada compute. 

Query 1 - ST_Contains(buildings, addresses)

Esta consulta avalia os 2,5 bilhões de polígonos de edifícios que contêm os 450 milhões de pontos de endereço (junção ponto em polígono). O resultado é de mais de 200 milhões de correspondências. Para o Sedona, revertemos 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 significativa entre usar ST_Contains ou ST_Within.

query nº 2 - ST_Covers(landuse, buildings)

Esta query avalia os 1,3 milhão de polígonos de uso de solo `industrial` em todo o mundo que cobrem os 2,5 bilhões de polígonos de construção. O resultado é mais de 25 milhões de correspondências.

Query nº 3 - ST_Intersects(roads, landuse)

Esta query avalia as 300 milhões de estradas que fazem interseção com os 10 milhões de polígonos de uso de solo ‘residenciais’ em todo o mundo. O resultado é de mais de 100 milhões de correspondências. Para o Sedona, revertemos isso para ST_Intersects(l.geom, trans.geom) para oferecer suporte à otimização default do lado esquerdo da construção. 

O que vem por aí para o Spatial SQL e os tipos nativos

O 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 o Public Preview: ST_AsEWKB, ST_Dump, ST_ExteriorRing, 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_MakeLine e ST_MakePolygon. 

Envie seu feedback para a equipe do produto

Se você quiser compartilhar suas solicitações de expressões ST ou recursos geoespaciais adicionais, preencha esta breve pesquisa.

Atualização: Tipos geográficos de código aberto no Apache Spark™

A contribuição dos tipos de dados GEOMETRY e GEOGRAPHY para o Apache Spark™ fez um grande progresso e está a caminho de ser incorporada ao Spark 4.2 em 2026.

Experimente o SQL Espacial gratuitamente

Execute sua próxima execução spatial no Databricks SQL hoje mesmo e veja como seus joins espaciais podem ser rápidos. Para saber mais sobre as funções SQL espaciais, consulte a documentação do SQL e do Pyspark. Para mais informações sobre o Databricks SQL, confira o site, o tour do produto e o Databricks Free Edition. Se você deseja migrar seu warehouse existente para um data warehouse sem servidor de alto desempenho com uma ótima experiência do usuário e custo total mais baixo, o Databricks SQL é a solução — experimente gratuitamente.

(This blog post has been translated using AI-powered tools) Original Post