Condividi tramite

Usare join in 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 UNIONset , INTERSECTe EXCEPT. Vedere Impostare gli operatori.

Differenze tra il flusso e i join batch

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 modo efficace. Hanno una semantica operativa complessa a seconda della modalità di output, dell'intervallo di trigger e della filigrana. Vedere Stream-stream joins (Join di stream).

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

Join 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 Usare viste materializzate in Databricks SQL.

Join di flusso

L'unione di due origini dati di streaming può presentare sfide significative nella gestione delle informazioni sullo stato e del 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, incluso il modo in cui le filigrane influiscano 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 tipi di join seguenti:

  • Inner join
  • Left outer join
  • Right outer join
  • Full outer join
  • Semi join a 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.

L'esempio seguente illustra 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

Calcolo con Photon abilitato seleziona sempre il tipo di join migliore. Vedi Che cos'è Photon?.

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

  • I cross join sono molto costosi. Rimuovere cross join dai carichi di lavoro e dalle query che richiedono bassa latenza o ricompilazione frequente.
  • L'ordine di partecipazione è importante. Quando si eseguono più join, unire sempre le tabelle più piccole e quindi 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 aggiornate le statistiche per migliorare le prestazioni. Eseguire la query ANALYZE TABLE table_name COMPUTE STATISTICS per aggiornare le statistiche in Query Planner.

Nota

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

Hint di aggiunta 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 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 join di intervalli.