shuffle query

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

A shuffle consulta é uma transformação de preservação semântica usada com um conjunto de operadores que dão suporte à shuffle estratégia. Dependendo dos dados envolvidos, a consulta com a shuffle estratégia pode gerar melhor desempenho. É melhor usar a estratégia de consulta aleatória quando a shuffle chave (uma join chave, summarize chave, make-series chave ou partition chave) tem uma cardinalidade alta e a consulta do operador regular atinge os limites de consulta.

Você pode usar os seguintes operadores com o comando shuffle:

• join
• summarize
• make-series
• partition

Para usar a shuffle estratégia de consulta, adicione a expressão hint.strategy = shuffle ou hint.shufflekey = <key>. Quando você usa hint.strategy=shuffleo , os dados do operador serão embaralhados por todas as teclas. Use essa expressão quando a chave composta for exclusiva, mas cada chave não for exclusiva o suficiente, portanto, você embaralhará os dados usando todas as chaves do operador embaralhado.

Ao particionar dados com a estratégia de ordem aleatória, a carga de dados é compartilhada em todos os nós do cluster. Cada nó processa uma partição dos dados. O número padrão de partições é igual ao número de nós de cluster.

O número da partição pode ser substituído usando a sintaxe hint.num_partitions = total_partitions, que controlará o número de partições. Isso é útil quando o cluster tem um pequeno número de nós de cluster e o número de partições padrão será pequeno, e a consulta falha ou leva um longo tempo de execução.

Em alguns casos, o hint.strategy = shuffle é ignorado e a consulta não será executada na shuffle estratégia. Isso pode ocorrer quando:

• O join operador tem outro shuffleoperador compatível comjoin (, summarize, make-series ou partition) no lado esquerdo ou direito.
• O summarize operador aparece após outro shuffleoperador compatível comjoin (, summarize, make-series ou partition) na consulta.

Syntax

Com 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

O exemplo nesta seção mostra como usar a sintaxe para ajudá-lo a começar.

Use resumir com embaralhar

A shuffle consulta de estratégia com summarize o operador compartilha a carga em todos os nós do cluster, em que cada nó processa uma partição dos dados.

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

Output

Usar junção com ordem aleatória

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

Use make-series com 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

Usar partição com ordem aleatória

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

Output

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

Quando você usa hint.strategy=shuffle, o operador embaralhado será embaralhado por todas as teclas. No exemplo a seguir, a consulta embaralha os dados usando as EpisodeId chaves e EventId como:

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

A consulta a seguir usa hint.shufflekey = key. A consulta acima é equivalente a esta consulta.

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

Embaralhe os dados com várias chaves

Em alguns casos, o será ignorado hint.strategy=shuffle e a consulta não será executada na estratégia de ordem aleatória. Por exemplo, no exemplo a seguir, a junção tem summarize em seu lado esquerdo, portanto, usar hint.strategy=shuffle não aplicará a estratégia de ordem aleatória à consulta:

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

Para superar esse problema e executar a estratégia de embaralhamento, escolha a chave que é comum para as summarize operações e join . Nesse caso, essa chave é EpisodeId. Use a dica hint.shufflekey para especificar a tecla aleatória no join para 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

Use resumir com ordem aleatória para melhorar o desempenho

Neste exemplo, usar o operador com summarize estratégia melhora o shuffle desempenho. A tabela de origem tem 150 milhões de registros e a cardinalidade do grupo por chave é 10 milhões, que é distribuída por 10 nós de cluster.

Usando summarize o operador sem shuffle estratégia, a consulta termina após 1:08 e o pico de uso de memória é de ~3 GB:

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

Output

Ao usar shuffle a estratégia com summarize, a consulta termina após ~7 segundos e o pico de uso de memória é de 0,43 GB:

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

Output

O exemplo a seguir demonstra o desempenho em um cluster que tem dois nós de cluster, com uma tabela que tem 60 milhões de registros, em que a cardinalidade da chave group by é 2 M.

A execução da consulta sem hint.num_partitions usará apenas duas partições (como número de nós de cluster) e a seguinte consulta levará ~1:10 minutos:

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

Se definir o número das partições como 10, a consulta será encerrada após 23 segundos:

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

Use a junção com o modo aleatório para melhorar o desempenho

O exemplo a seguir mostra como o uso da shuffle estratégia com o operador melhora o join desempenho.

Os exemplos foram amostrados em um cluster com 10 nós onde os dados estão espalhados por todos esses nós.

A tabela de origem do lado esquerdo da consulta tem 15 milhões de registros em que a join cardinalidade da chave é ~ 14 milhões. A origem do lado direito da consulta tem 150 milhões de registros e a join cardinalidade da chave é 10 milhões. A consulta termina após ~28 segundos e o pico de uso de memória é de 1,43 GB:

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

Ao usar shuffle a estratégia com um join operador, a consulta termina após ~4 segundos e o pico de uso de memória é de 0,3 GB:

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

Em outro exemplo, tentamos as mesmas consultas em um conjunto de dados maior com as seguintes condições:

• A fonte do lado esquerdo do join é 150M e a cardinalidade da chave é 148M.
• A fonte do lado direito do join é 1.5B e a cardinalidade da chave é ~ 100M.

A consulta apenas com o join operador atinge limites e atinge o tempo limite após 4 minutos. No entanto, ao usar shuffle a estratégia com o join operador, a consulta termina após ~34 segundos e o pico de uso de memória é de 1,23 GB.

O exemplo a seguir mostra a melhoria em um cluster que tem dois nós de cluster, com uma tabela de 60 milhões de registros, em que a join cardinalidade da chave é 2 milhões. A execução da consulta sem hint.num_partitions usará apenas duas partições (como número de nós de cluster) e a seguinte consulta levará ~1:10 minutos:

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

Ao definir o número das partições como 10, a consulta terminará após 23 segundos:

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