shuffle query

Applies to: ✅Microsoft Fabric✅Azure Data Explorer✅Azure Monitor✅Microsoft Sentinel

La shuffle query è una trasformazione con mantenimento semantico usata con un set di operatori che supportano la shuffle strategia. A seconda dei dati coinvolti, l'esecuzione di query con la shuffle strategia può offrire prestazioni migliori. È preferibile usare la strategia di query casuale quando la shuffle chiave (una chiave, una chiave, join una chiave, summarize una make-series chiave o partition una chiave) ha una cardinalità elevata e la query dell'operatore regolare raggiunge i limiti di query.

È possibile usare gli operatori seguenti con il comando shuffle:

• join
• summarize
• make-series
• partition

Per usare la strategia di shuffle query, aggiungere l'espressione hint.strategy = shuffle o hint.shufflekey = <key>. Quando si usa hint.strategy=shuffle, i dati dell'operatore verranno rimescolati da tutte le chiavi. Usare questa espressione quando la chiave composta è univoca, ma ogni chiave non è sufficientemente univoca, quindi si ri shuffleranno i dati usando tutte le chiavi dell'operatore casuale.

Quando si partiziona i dati con la strategia casuale, il caricamento dei dati viene condiviso in tutti i nodi del cluster. Ogni nodo elabora una partizione dei dati. Il numero predefinito di partizioni è uguale al numero di nodi del cluster.

È possibile eseguire l'override del numero di partizione usando la sintassi hint.num_partitions = total_partitions, che controlla il numero di partizioni. Ciò è utile quando il cluster ha un numero ridotto di nodi del cluster e il numero di partizioni predefinite sarà ridotto e la query ha esito negativo o richiede molto tempo di esecuzione.

In alcuni casi, l'oggetto hint.strategy = shuffle viene ignorato e la query non verrà eseguita nella shuffle strategia. Ciò può verificarsi quando:

• L'operatore join ha un altro shuffleoperatore compatibile con -(join, summarizeo make-seriespartition) sul lato sinistro o sul lato destro.
• L'operatore summarize viene visualizzato dopo un altro shuffleoperatore compatibile con -(join, summarizeo make-seriespartition) nella query.

Syntax

Con hint.strategy = shuffle

T|DataExpression|joinhint.strategy = shuffle(DataExpression)

T|summarizehint.strategy = shuffleDataExpression

T|Query| partition hint.strategy = shuffle(SubQuery)

With hint.shufflekey = key

T|DataExpression|joinhint.shufflekey = key(DataExpression)

T|summarizehint.shufflekey = keyDataExpression

T|make-serieshint.shufflekey = keyDataExpression

T|Query| partition hint.shufflekey = key(SubQuery)

Learn more about syntax conventions.

Parameters

Examples

L'esempio in questa sezione illustra come usare la sintassi per iniziare.

Usare summarize con shuffle

La shuffle query di strategia con summarize l'operatore condivide il carico in tutti i nodi del cluster, in cui ogni nodo elabora una partizione dei dati.

StormEvents
| summarize hint.strategy = shuffle count(), avg(InjuriesIndirect) by State
| count 

Output

Usare join con shuffle

StormEvents
| where State has "West"
| where EventType has "Flood"
| join hint.strategy=shuffle 
    (
    StormEvents
    | where EventType has "Hail"
    | project EpisodeId, State, DamageProperty
    )
    on State
| count

Output

Usare make-series con shuffle

StormEvents
| where State has "North"
| make-series hint.shufflekey = State sum(DamageProperty) default = 0 on StartTime in range(datetime(2007-01-01 00:00:00.0000000), datetime(2007-01-31 23:59:00.0000000), 15d) by State

Output

Usare la partizione con shuffle

StormEvents
| partition hint.strategy=shuffle by EpisodeId
(
    top 3 by DamageProperty
    | project EpisodeId, State, DamageProperty
)
| count

Output

Confrontare hint.strategy=shuffle e hint.shufflekey=key

Quando si usa hint.strategy=shuffle, l'operatore casuale verrà casuale da tutte le chiavi. Nell'esempio seguente la query sposta i dati usando sia EpisodeIdEventId che come chiavi:

StormEvents
| where StartTime > datetime(2007-01-01 00:00:00.0000000)
| join kind = inner hint.strategy=shuffle (StormEvents | where DamageCrops > 62000000) on EpisodeId, EventId
| count

Output

Nella query seguente viene utilizzata la parola chiave hint.shufflekey = key. La query precedente equivale a questa query.

StormEvents
| where StartTime > datetime(2007-01-01 00:00:00.0000000)
| join kind = inner hint.shufflekey = EpisodeId hint.shufflekey = EventId (StormEvents | where DamageCrops > 62000000) on EpisodeId, EventId

Output

Eseguire lo shuffle dei dati con più chiavi

In alcuni casi, l'oggetto hint.strategy=shuffle verrà ignorato e la query non verrà eseguita in una strategia casuale. Nell'esempio seguente, ad esempio, il join ha riepilogo sul lato sinistro, quindi l'uso hint.strategy=shuffle di non applicherà la strategia casuale alla query:

StormEvents
| where StartTime > datetime(2007-01-01 00:00:00.0000000)
| summarize count() by EpisodeId, EventId
| join kind = inner hint.strategy=shuffle (StormEvents | where DamageCrops > 62000000) on EpisodeId, EventId

Output

Per risolvere questo problema ed eseguire una strategia casuale, scegliere la chiave comune per le summarize operazioni e join . In questo caso, questa chiave è EpisodeId. Usare l'hint hint.shufflekey per specificare la chiave casuale in join su hint.shufflekey = EpisodeId:

StormEvents
| where StartTime > datetime(2007-01-01 00:00:00.0000000)
| summarize count() by EpisodeId, EventId
| join kind = inner hint.shufflekey=EpisodeId (StormEvents | where DamageCrops > 62000000) on EpisodeId, EventId

Output

Usare summarize con shuffle per migliorare le prestazioni

In questo esempio, l'uso dell'operatore con summarize la shuffle strategia migliora le prestazioni. La tabella di origine ha 150M record e la cardinalità del gruppo per chiave è 10M, che viene distribuita su 10 nodi del cluster.

Usando summarize l'operatore senza shuffle strategia, la query termina dopo le 1:08 e il picco di utilizzo della memoria è di circa 3 GB:

orders
| summarize arg_max(o_orderdate, o_totalprice) by o_custkey 
| where o_totalprice < 1000
| count

Output

Quando si usa shuffle la strategia con summarize, la query termina dopo circa 7 secondi e il picco di utilizzo della memoria è di 0,43 GB:

orders
| summarize hint.strategy = shuffle arg_max(o_orderdate, o_totalprice) by o_custkey 
| where o_totalprice < 1000
| count

Output

L'esempio seguente illustra le prestazioni in un cluster con due nodi del cluster, con una tabella con 60M record, in cui la cardinalità del gruppo per chiave è 2M.

L'esecuzione della query senza hint.num_partitions userà solo due partizioni (come numero di nodi del cluster) e la query seguente richiederà circa 1:10 minuti:

lineitem 
| summarize hint.strategy = shuffle dcount(l_comment), dcount(l_shipdate) by l_partkey 
| consume

Se si imposta il numero di partizioni su 10, la query terminerà dopo 23 secondi:

lineitem 
| summarize hint.strategy = shuffle hint.num_partitions = 10 dcount(l_comment), dcount(l_shipdate) by l_partkey 
| consume

Usare join con shuffle per migliorare le prestazioni

L'esempio seguente mostra come l'uso shuffle della strategia con l'operatore join migliora le prestazioni.

Gli esempi sono stati campionati in un cluster con 10 nodi in cui i dati vengono distribuiti in tutti questi nodi.

La tabella di origine sul lato sinistro della query ha 15M record in cui la join cardinalità della chiave è di circa 14M. L'origine sul lato destro della query ha 150M record e la cardinalità della join chiave è 10M. La query termina dopo circa 28 secondi e il picco di utilizzo della memoria è di 1,43 GB:

customer
| join
    orders
on $left.c_custkey == $right.o_custkey
| summarize sum(c_acctbal) by c_nationkey

Quando si usa shuffle la strategia con un join operatore, la query termina dopo circa 4 secondi e il picco di utilizzo della memoria è di 0,3 GB:

customer
| join
    hint.strategy = shuffle orders
on $left.c_custkey == $right.o_custkey
| summarize sum(c_acctbal) by c_nationkey

In un altro esempio si provano le stesse query su un set di dati di dimensioni maggiori con le condizioni seguenti:

• L'origine join sul lato sinistro di è 150M e la cardinalità della chiave è 148M.
• L'origine join sul lato destro di è 1,5B e la cardinalità della chiave è ~100M.

La query con solo l'operatore join raggiunge i limiti e il timeout dopo 4 minuti. Tuttavia, quando si usa shuffle la strategia con l'operatore join , la query termina dopo circa 34 secondi e il picco di utilizzo della memoria è di 1,23 GB.

L'esempio seguente illustra il miglioramento in un cluster con due nodi del cluster, con una tabella di 60M record, in cui la cardinalità della join chiave è 2M. L'esecuzione della query senza hint.num_partitions userà solo due partizioni (come numero di nodi del cluster) e la query seguente richiederà circa 1:10 minuti:

lineitem
| summarize dcount(l_comment), dcount(l_shipdate) by l_partkey
| join
    hint.shufflekey = l_partkey   part
on $left.l_partkey == $right.p_partkey
| consume

Quando si imposta il numero di partizioni su 10, la query terminerà dopo 23 secondi:

lineitem
| summarize dcount(l_comment), dcount(l_shipdate) by l_partkey
| join
    hint.shufflekey = l_partkey  hint.num_partitions = 10    part
on $left.l_partkey == $right.p_partkey
| consume