Join spaziali di Databricks ora 17 volte più veloci e pronti all'uso

L'elaborazione e l'analisi dei dati spaziali sono fondamentali per i carichi di lavoro geospaziali su Databricks. Molti team si affidano a librerie esterne o estensioni di Spark come Apache Sedona, Geopandas, il progetto Mosaic di Databricks Lab per gestire questi carichi di lavoro. Anche se i clienti hanno avuto successo, questi approcci aggiungono un sovraccarico operativo e spesso richiedono una messa a punto per raggiungere prestazioni accettabili.

All'inizio di quest'anno, Databricks ha rilasciato il supporto per Spatial SQL, che ora include 90 funzioni spaziali e il supporto per l'archiviazione dei dati in colonne GEOMETRY o GEOGRAPHY. Lo Spatial SQL integrato di Databricks è l'approccio migliore per archiviare ed elaborare dati vettoriali rispetto a qualsiasi alternativa, perché risolve tutte le principali sfide legate all'uso di librerie aggiuntive: elevata stabilità, prestazioni fulminee e, con Databricks SQL Serverless, non è necessario gestire cluster classici, compatibilità delle librerie e versioni di runtime.

Una delle attività di elaborazione spaziale più comuni consiste nel confrontare due geometrie per stabilire se si sovrappongono, se una contiene l'altra o qual è la loro prossimità. Questa analisi richiede l'uso di join spaziali, per cui sono essenziali ottime prestazioni out-of-the-box per accelerare l'ottenimento di approfondimenti spaziali.

Join spaziali fino a 17 volte più veloci con Databricks SQL Serverless

Siamo lieti di annunciare che tutti i clienti che utilizzano le funzioni SQL spaziali integrato per i join spaziali otterranno prestazioni fino a 17 volte più veloci rispetto ai cluster classici con Apache Sedona1 installato. I miglioramenti delle prestazioni sono disponibili per tutti i clienti che utilizzano Databricks SQL Serverless e i cluster classici con Databricks Runtime (DBR) 17.3. Se stai già utilizzando i predicati spaziali integrati di Databricks, come ST_Intersects o ST_Contains, non è richiesta alcuna modifica al codice.

L'esecuzione di join spaziali presenta sfide uniche, con prestazioni influenzate da più fattori. I set di dati geospaziali sono spesso molto asimmetrici, come nel caso di regioni urbane dense e aree rurali sparse, e variano ampiamente in termini di complessità geometrica, come l'intricata costa norvegese rispetto ai semplici confini del Colorado. Anche dopo un'efficiente eliminazione dei file, i candidati join rimanenti richiedono ancora attività operative geometriche a elevato compute-intensive. È qui che Databricks dà il meglio di sé.

Il miglioramento dei join spaziali deriva dall'uso dell'indicizzazione R-tree, dei join spaziali ottimizzati in Photon e dell'ottimizzazione intelligente dei join di intervallo, il tutto applicato automaticamente. Scrivi codice SQL standard con funzioni spaziali e il motore gestisce la complessità.

L'importanza a livello di business dei join spaziali 

Un join spaziale è simile a un join di database ma, invece di abbinare gli ID, utilizza un predicato spaziale per associare i dati in base alla posizione. I predicati spaziali valutano la relazione fisica relativa, come la sovrapposizione, il contenimento o la prossimità, per collegare due set di dati. I join spaziali sono un potente strumento per l'aggregazione spaziale e aiutano gli analisti a scoprire tendenze, pattern e informazioni dettagliate basate sulla posizione in luoghi diversi, dai centri commerciali e dalle fattorie, alle città e all'intero pianeta.

I join spaziali rispondono a domande business-critical in ogni settore industriale. Ad esempio:

• Le autorità costiere monitorano il traffico navale all'interno di un porto o dei confini nautici
• I retailer analizzano il traffico veicolare e i modelli di visita nelle varie sedi dei negozi
• Le moderne aziende agricole eseguono analisi e previsioni sulla resa delle colture combinando dati meteorologici, sul campo e sulle sementi.
• Gli enti di pubblica sicurezza e le compagnie assicurative individuano quali abitazioni sono a rischio di inondazioni o incendi.
• I team delle attività operative del settore energetico e delle Utilities elaborano piani di assistenza e infrastrutturali sulla base dell'analisi di fonti energetiche, uso del suolo residenziale e commerciale e degli asset esistenti

Preparazione del benchmark per il join spaziale

Per i dati, abbiamo selezionato quattro set di dati su larga scala a livello mondiale da Overture Maps Foundation: Indirizzi, Edifici, Uso del suolo e Strade. Puoi testare le query in autonomia utilizzando i metodi descritti di seguito. 

Abbiamo utilizzato i set di dati di Overture Maps, scaricati inizialmente come GeoParquet. Di seguito è riportato un esempio di preparazione degli indirizzi per il benchmarking di Sedona. Tutti i set di dati hanno seguito lo stesso schema.

Abbiamo anche elaborato i dati in tabelle Lakehouse, convertendo il parquet WKB in tipi di dati nativiGEOMETRY per il benchmarking Databricks.

Query di confronto

Il grafico riportato sopra utilizza lo stesso set di tre query, testate su ciascun compute. 

Query n. 1 - ST_Contains(buildings, addresses)

Questa query valuta i 2,5 miliardi di poligoni di edifici che contengono i 450 milioni di punti di indirizzo (join punto-in-poligono). Il risultato è di oltre 200 milioni di corrispondenze. Per Sedona, abbiamo invertito l'operazione in ST_Within(a.geom, b.geom) per supportare l'ottimizzazione del lato di compilazione sinistro default. Su Databricks non c'è alcuna differenza sostanziale tra l'uso di ST_Contains o di ST_Within.

Query n. 2 - ST_Covers(landuse, buildings)

Questa query valuta gli 1,3 milioni di poligoni `industrial` di destinazione d'uso del suolo a livello mondiale che coprono i 2,5 miliardi di poligoni di edifici. Il risultato è di oltre 25 milioni di corrispondenze.

Query n. 3 - ST_Intersects(roads, landuse)

Questa query valuta i 300 milioni di strade che si intersecano con i 10 milioni di poligoni di uso del suolo "residenziale" a livello mondiale. Il risultato è di oltre 100 milioni di corrispondenze. Per Sedona, abbiamo invertito l'operazione in ST_Intersects(l.geom, trans.geom) per supportare l'ottimizzazione predefinita left build-side. 

Novità per SQL spaziale e tipi nativi

Databricks continua ad aggiungere nuove espressioni spaziali in base alle richieste dei clienti. Ecco un elenco di funzioni spaziali aggiunte dopo la Public Preview: ST_AsEWKB, ST_Dump, ST_ExteriorRing, ST_InteriorRingN, ST_NumInteriorRings. Disponibili ora in DBR 18.0 Beta: ST_Azimuth, ST_Boundary, ST_ClosestPoint, supporto per l'inserimento di EWKT, incluse due nuove espressioni, ST_GeogFromEWKT e ST_GeomFromEWKT, e miglioramenti in termini di prestazioni e robustezza per ST_IsValid, ST_MakeLine, e ST_MakePolygon. 

Fornisci il tuo feedback al team di prodotto

Se desideri condividere le tue richieste di ulteriori espressioni ST o funzionalità geospaziali, compila questo breve sondaggio. 

Aggiornamento: open sourcing dei tipi geografici in Apache Spark™

Il contributo dei tipi di dati GEOMETRY e GEOGRAPHY ad Apache Spark™ ha fatto grandi progressi ed è sulla buona strada per essere integrato in Spark 4.2 nel 2026.

Prova gratuitamente Spatial SQL

Esegui oggi la tua prossima query spaziale su Databricks SQL e scopri la velocità dei tuoi join spaziali. Per saperne di più sulle funzioni SQL spaziali, consulta la documentazione per SQL e Pyspark. Per maggiori informazioni su Databricks SQL, visita il sito web, il tour del prodotto e la versione gratuita di Databricks. Se desideri migrare il tuo warehouse esistente in un data warehouse serverless ad alte prestazioni con un'ottima user experience e un costo totale inferiore, Databricks SQL è la soluzione ideale — provalo gratuitamente.