Consulta aleatória

Aplica-se a: ✅Microsoft Fabric✅Azure Data Explorer✅Azure Monitor✅Microsoft Sentinel

A consulta shuffle é uma transformação de preservação semântica usada com um conjunto de operadores que suportam a estratégia de shuffle. Dependendo dos dados envolvidos, consultar a estratégia shuffle pode gerar um melhor desempenho. É melhor usar a estratégia de consulta aleatória quando a chave shuffle (uma chave join, chave summarize, chave make-series ou chave partition) 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:

• junte-se a
• resumir
• série de make-series
• partição

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

Ao particionar dados com a estratégia shuffle, 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 falhar ou levar um longo tempo de execução.

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

• O operador join tem outro operador compatível com shuffle(join, summarize, make-series ou partition) no lado esquerdo ou direito.
• O operador summarize aparece depois de outro operador compatível com shuffle(join, summarize, make-series ou partition) na consulta.

Sintaxe

Com hint.strategy = shuffle

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

T|summarizehint.strategy = shuffleDataExpression

T|Consulta| partição hint.strategy = shuffle(SubQuery)

Com hint.shufflekey = chave

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

T|summarizehint.shufflekey = chaveDataExpression

T|make-serieshint.shufflekey = chaveDataExpression

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

Saiba mais sobre convenções de sintaxe.

Parâmetros

Exemplos

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

Use resumir com embaralhar

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

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

Output

Use a junção com 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

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 shuffle

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 chaves. No exemplo a seguir, a consulta embaralha os dados usando EpisodeId e EventId como chaves:

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 teclas

Em alguns casos, o hint.strategy=shuffle será ignorado e a consulta não será executada na estratégia de embaralhamento. Por exemplo, no exemplo a seguir, a junção tem um resumo no lado esquerdo, portanto, usar hint.strategy=shuffle não aplicará a estratégia de embaralhar à 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 shuffle, escolha a chave que é comum para as operações summarize e join. Neste caso, esta chave é EpisodeId. Use o hint.shufflekey de dicas para especificar a tecla shuffle 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 embaralhar para melhorar o desempenho

Neste exemplo, usar o operador summarize com shuffle estratégia melhora o desempenho. A tabela de origem tem 150M registros e a cardinalidade do grupo por chave é 10M, que está espalhada por 10 nós de cluster.

Usando summarize operador sem estratégia shuffle, 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 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 registros de 60M, onde a cardinalidade do grupo por chave é 2M.

Executar a 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 terminará 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 shuffle para melhorar o desempenho

O exemplo a seguir mostra como o uso de shuffle estratégia com o operador join melhora o 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 onde a cardinalidade da chave join é ~14 milhões. A fonte do lado direito da consulta tem 150 milhões de registros e a cardinalidade da chave join é 10 milhões. A consulta termina após ~28 segundos e o pico de utilização 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 estratégia com um operador join, 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 com apenas o operador join atinge limites e tempos limite após 4 minutos. No entanto, ao usar shuffle estratégia com o operador join, 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 registros de 60M, onde a cardinalidade da chave join é 2M. Executar a 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