Condividi tramite

Lavorare con i join su Azure Databricks

  • Articolo

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

Nota

Databricks supporta anche la sintassi standard per gli operatori setUNION, INTERSECTe EXCEPT. Visualizzare gli operatori Set.

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 a seconda della modalità di output, dell'intervallo di trigger e watermark. Vedere Join di stream-stream.

I join di flusso-statico sono senza stato, ma offrono una buona opzione per l'unione di un'origine dati incrementale (come i fatti table) con un'origine dati statica (come una dimensione a modifica lenta table). Anziché unire tutti i record da entrambi i lati ogni volta che viene eseguita una query, vengono uniti solo i record appena ricevuti dall'origine di streaming con la versione corrente del tablestatico. Vedere Join statici di flusso.

Join di batch

Azure Databricks supporta la sintassi sql join standard, tra cui inner, outer, semi, anti e cross join. Vedi JOIN.

Nota

Databricks consiglia di usare una vista materializzata per il optimize calcolo incrementale dei risultati di un joininterno. Vedere Usare views materializzati 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 flusso a flusso join, Databricks consiglia di sviluppare una conoscenza approfondita della semantica operativa per lo streaming con stato, incluso il modo in cui le filigrane influenzano la 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 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 unisce la versione valida più recente di un table Delta (i dati statici) a un flusso di dati usando un joinsenza stato .

Quando Azure Databricks elabora un micro-batch di dati in un contesto di flusso-statico join, l'ultima versione valida dei dati dal Delta statico table si unisce ai record presenti nel micro-batch corrente. Poiché il join è senza stato di conservazione, non è necessario configurare la marcatura e può elaborare i risultati con bassa latenza. I dati nel Delta statico table utilizzati nel contesto di join dovrebbero cambiare lentamente.

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")
)

prestazioni Optimizejoin

Il calcolo con Photon abilitato seleziona sempre il miglior tipo di join. Vedere Che cos'è Photon?.

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

  • I cross join sono molto costosi. Remove cross join nei carichi di lavoro e nelle query che richiedono bassa latenza o ricalcolo frequente.

  • Join L'ordine è importante. Quando si eseguono più join, inizia join con il più piccolo tables e quindi join il risultato con i tablespiù 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ò update e gestire automaticamente le statistiche. È anche possibile eseguire la query ANALYZE TABLE table_name COMPUTE STATISTICS per update 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 il columns su cui Delta Lake raccoglie statistiche per il skipping dei dati e quindi ricalcolare le statistiche esistenti nel Delta log. Vedere Specificare le statistiche delta columns.

Suggerimenti Join su Azure Databricks

Apache Spark supporta la specifica di hint join per i join di intervallo e i join asimmetri. 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 diseguali. Gli esempi includono l'unione in intervalli di timestamp o un intervallo di ID clustering. Vedere intervallo join ottimizzazione.