Esecuzione di query adattive

Articolo
01/21/2025

L'esecuzione di query adattive (AQE) è la ri-ottimizzazione delle query che si verifica durante la loro esecuzione.

La motivazione per la riottimizzazione del runtime è che Azure Databricks ha le statistiche più accurate up-to-date alla fine di uno scambio casuale e broadcast (detto fase di query in AQE). Di conseguenza, Azure Databricks può scegliere una strategia fisica migliore, individuare una dimensione ottimale e un numero di partizioni post-shuffle, oppure eseguire ottimizzazioni che in precedenza richiedevano suggerimenti, come ad esempio la gestione dei join sbilanciati.

Ciò può essere molto utile quando la raccolta delle statistiche non è attivata o quando le statistiche non sono aggiornate. È utile anche in contesti in cui le statistiche derivate in modo statico sono imprecise, ad esempio nel mezzo di una query complessa o dopo l'occorrenza di distorsioni dei dati.

Funzionalità

AQE è abilitato per impostazione predefinita. Ha 4 funzionalità principali:

Modifica dinamicamente l'ordinamento del merge join in broadcast hash join.
Unisce dinamicamente le partizioni (combina partizioni di piccole dimensioni in partizioni di dimensioni ragionevoli) dopo lo scambio di shuffle. Le attività molto piccole hanno una velocità effettiva di I/O peggiore e tendono a soffrire di più dal sovraccarico di pianificazione e dal sovraccarico di configurazione delle attività. La combinazione di attività di piccole dimensioni consente di risparmiare risorse e migliorare la velocità effettiva del cluster.
Gestisce dinamicamente lo sbilanciamento nel join di tipo merge sort e nel join di tipo hash shuffle suddividendo (e replicando, se necessario) le attività sbilanciate in attività di dimensioni approssimativamente uguali.
Rileva e propaga dinamicamente le relazioni vuote.

Applicazione

AQE si applica a tutte le interrogazioni che sono:

Non streaming
Contiene almeno uno scambio (in genere quando è presente un join, un'aggregazione o una finestra), una sottoquery o entrambe le cose.

Non tutte le query applicate all'AQE sono necessariamente riottimizzate. La riottimizzazione potrebbe o meno fornire un piano di query diverso rispetto a quello compilato staticamente. Per determinare se il piano di una query è stato modificato da AQE, consultare la sezione sottostante Piani di query.

Piani di query

In questa sezione viene illustrato come esaminare i piani di query in modi diversi.

Interfaccia utente di Spark

nodo `AdaptiveSparkPlan`

Le query applicate AQE contengono uno o più nodi AdaptiveSparkPlan, solitamente come nodo radice di ciascuna query principale o sottoquery. Prima dell'esecuzione della query o quando è in esecuzione, il flag isFinalPlan del nodo AdaptiveSparkPlan corrispondente viene visualizzato come false; al termine dell'esecuzione della query, il flag di isFinalPlan cambia in true.

Piano in evoluzione

Il diagramma del piano di query si evolve man mano che l'esecuzione avanza e riflette il piano più recente in esecuzione. I nodi che sono già stati eseguiti (in cui sono disponibili le metriche) non cambiano, ma quelli che non sono stati eseguiti possono cambiare nel tempo a seguito di riottimizzazioni.

Di seguito è riportato un esempio di diagramma del piano di query:

diagramma dello schema di query

`DataFrame.explain()`

nodo `AdaptiveSparkPlan`

Le query applicate AQE contengono uno o più nodi AdaptiveSparkPlan, solitamente come nodo radice di ciascuna query principale o sottoquery. Prima dell'esecuzione della query o quando è in esecuzione, il flag isFinalPlan del nodo AdaptiveSparkPlan corrispondente viene visualizzato come false; Al termine dell'esecuzione della query, il flag di isFinalPlan cambia in true.

Piano corrente e iniziale

In ogni nodo AdaptiveSparkPlan sarà presente sia il piano iniziale (il piano prima di applicare le ottimizzazioni AQE) sia il piano corrente o finale, a seconda che l'esecuzione sia stata completata. Il piano corrente si evolverà man mano che l'esecuzione procede.

Statistiche di esecuzione

Ogni fase di miscelazione e broadcast contiene statistiche sui dati.

Prima o durante l'esecuzione della fase, le statistiche sono stime calcolate in fase di compilazione e il flag isRuntime è false, ad esempio: Statistics(sizeInBytes=1024.0 KiB, rowCount=4, isRuntime=false);

Una volta completata l'esecuzione della fase, le statistiche sono quelle raccolte durante l'esecuzione, e il flag isRuntime diventerà true, ad esempio: Statistics(sizeInBytes=658.1 KiB, rowCount=2.81E+4, isRuntime=true)

Di seguito è riportato un esempio di DataFrame.explain:

Prima dell'esecuzione
Durante l'esecuzione
Dopo l'esecuzione

`SQL EXPLAIN`

nodo `AdaptiveSparkPlan`

Le query AQE applicate contengono uno o più nodi AdaptiveSparkPlan, di solito come nodo principale di ogni query principale o sottoquery.

Nessun piano attuale

Poiché SQL EXPLAIN non esegue la query, il piano corrente è sempre uguale al piano iniziale e non riflette ciò che alla fine verrebbe eseguito da AQE.

Di seguito è riportato un esempio di SQL explain:

SQL explain

Efficacia

Il piano di query cambierà se una o più ottimizzazioni di AQE diventano effettive. L'effetto di queste ottimizzazioni AQE è dimostrato dalla differenza tra i piani correnti e finali e il piano iniziale e i nodi di piano specifici nei piani correnti e finali.

Modificare dinamicamente l'unione di ordinamento in broadcast hash join: nodi di join fisici diversi tra il piano corrente/finale e il piano iniziale
Unire dinamicamente le partizioni: nodo CustomShuffleReader con proprietà Coalesced
Gestire dinamicamente lo skew join: nodo SortMergeJoin con campo isSkew come vero.
Rilevare e propagare dinamicamente le relazioni vuote: parte di (o dell'intero) piano viene sostituita dal nodo LocalTableScan con il campo delle relazioni vuoto.