Condividi tramite

Lavorare con i join su Azure Databricks

  • Articolo

Databricks supporta la sintassi di join standard ANSI. Questo articolo descrive le differenze tra join con l'elaborazione batch e di flusso e fornisce alcune raccomandazioni per ottimizzare le prestazioni di join.

Nota

Databricks supporta anche la sintassi standard per gli operatori set UNION, INTERSECT e EXCEPT. Vedere Impostare gli operatori.

Informazioni sulle differenze tra dati batch e di streaming

I join in Azure Databricks sono con stato o senza stato.

Tutti i join batch sono join senza stato. I risultati elaborano immediatamente e riflettono i dati al momento dell'esecuzione della query. Ogni volta che viene eseguita la query, i nuovi risultati vengono calcolati in base ai dati di origine specificati. Vedere Join di batch.

I join tra due origini dati di streaming sono con stato. Nei join con stato, Azure Databricks tiene traccia delle informazioni sulle origini dati e i risultati e aggiorna in modo iterativo i risultati. I join con stato possono offrire potenti soluzioni per l'elaborazione dei dati online, ma possono essere difficili da implementare in maniera efficace. Hanno una semantica operativa complessa che dipende dalla modalità di uscita, dall'intervallo di attivazione e dalla filigrana. Vedere Join di stream-stream.

I join statici di flusso sono senza stato, ma offrono una buona opzione per unire un'origine dati incrementale (come una tabella di dati) con un'origine dati statica (come una tabella dimensionale che cambia lentamente). Anziché unire tutti i record da entrambi i lati ogni volta che viene eseguita una query, solo i nuovi record ricevuti dall'origine di streaming vengono uniti alla versione corrente della tabella statica. Vedere Join statici di flusso.

Join di batch

Azure Databricks supporta la sintassi di join SQL standard, tra cui inner, outer, semi, anti e cross join. Vedere JOIN.

Nota

Databricks consiglia di usare una vista materializzata per ottimizzare il calcolo incrementale dei risultati di un inner join. Vedere Utilizzare le viste materializzate in Databricks SQL.

Join stream-stream

L'unione di due origini dati di streaming può presentare problematiche significative nella gestione delle informazioni sullo stato e nel ragionamento sui risultati di calcolo e output. Prima di implementare un join di flusso, Databricks consiglia di sviluppare una conoscenza approfondita della semantica operativa per lo streaming con stato, compreso l'impatto delle filigrane sulla gestione dello stato. Fai riferimento ai seguenti articoli:

Databricks consiglia di specificare filigrane per entrambi i lati di tutti i join stream-steam. Sono supportati i seguenti tipi di join:

  • Inner join
  • Left outer join
  • Right outer join
  • Full outer join
  • Semi join di sinistra

Vedere la documentazione di Apache Spark Structured Streaming sui join stream-steam.

Join statici di flusso

Nota

Il comportamento descritto per i join statici di flusso presuppone che i dati statici vengano archiviati usando Delta Lake.

Un join statico di flusso aggiunge la versione valida più recente di una tabella Delta (i dati statici) a un flusso di dati usando un join senza stato.

Quando Azure Databricks elabora un micro batch di dati in un join statico di flusso, la versione valida più recente dei dati della tabella Delta statica unisce i record presenti nel micro batch corrente. Poiché il join è senza stato, non è necessario configurare la filigrana e può elaborare i risultati con bassa latenza. I dati nella tabella Delta statica usata nel join devono essere a modifica lenta.

Nel seguente esempio viene illustrato questo modello:

streamingDF = spark.readStream.table("orders")
staticDF = spark.read.table("customers")

query = (streamingDF
  .join(staticDF, streamingDF.customer_id==staticDF.id, "inner")
  .writeStream
  .option("checkpointLocation", checkpoint_path)
  .table("orders_with_customer_info")
)

Ottimizzare le prestazioni di join

L’ambiente di calcolo con Photon abilitato seleziona sempre il tipo di join migliore. Vedere Che cos'è Photon?.

L'uso di una versione recente di Databricks Runtime con Photon abilitato in genere offre buone prestazioni di join, ma è opportuno prendere in considerazione anche le seguenti raccomandazioni:

  • I cross join sono molto costosi. Rimuovere cross join dai carichi di lavoro e dalle query che richiedono bassa latenza o frequente ricompilazione.

  • L'ordine dei join è importante. Quando si eseguono più join, unire sempre le tabelle più piccole e poi unire il risultato con tabelle più grandi.

  • L'utilità di ottimizzazione può avere difficoltà nelle query con molti join e aggregazioni. Il salvataggio dei risultati intermedi può accelerare la pianificazione e il calcolo dei risultati delle query.

  • Mantenere le statistiche aggiornate per migliorare le prestazioni. L'ottimizzazione predittiva con ANALYZE (anteprima pubblica) può aggiornare e gestire automaticamente le statistiche. È anche possibile eseguire la query ANALYZE TABLE table_name COMPUTE STATISTICS per aggiornare le statistiche in Query Planner.

Importante

L'ottimizzazione predittiva con ANALYZE è disponibile in anteprima pubblica. Include una raccolta di statistiche intelligenti durante le scritture. Usare questo modulo per iscriversi all'anteprima pubblica.

Nota

In Databricks Runtime 14.3 LTS e versioni successive è possibile modificare le colonne raccolte da Delta Lake per ignorare i dati e poi ricompilare le statistiche esistenti nel log Delta. Vedere Specificare le colonne delle statistiche Delta.

Hint di join in Azure Databricks

Apache Spark supporta la specifica di hint di join per join di intervallo e join di asimmetria. I suggerimenti per i join di asimmetria non sono necessari perché Azure Databricks ottimizza automaticamente questi join. Vedere Hint

I suggerimenti per i join di intervallo possono essere utili se le prestazioni di join sono scarse e si eseguono join di disuguaglianza. Gli esempi includono l'unione in intervalli di timestamp o un intervallo di ID clustering. Vedere Ottimizzazione dei join di intervallo.