consulta shuffle
Aplica-se a: ✅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:
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.
Observação
O uso de muitas partições pode consumir mais recursos de cluster e degradar o desempenho. Escolha o número da partição com cuidado, começando com o hint.strategy = shuffle e comece a aumentar as partições gradualmente.
Em alguns casos, o hint.strategy = shuffle é ignorado e a consulta não será executada na shuffle estratégia. Isso pode ocorrer quando:
- O
joinoperador tem outroshuffleoperador compatível comjoin(,summarize,make-seriesoupartition) no lado esquerdo ou direito. - O
summarizeoperador aparece após outroshuffleoperador compatível comjoin(,summarize,make-seriesoupartition) na consulta.
Sintaxe
Com hint.strategy = shuffle
Expressão de | join = ( hint.strategyshuffle Dados T | Expressão de Dados )
Expressão de Dados T | summarize hint.strategy = shuffle
Subconsulta de partição = ( hint.strategyshufflede consulta T | | )
Com hint.shufflekey = chave
Chave T | DataExpression join = hint.shufflekey | DataExpression ( )
Tecla T = | summarize hint.shufflekeyDataExpression
Tecla T = | make-series hint.shufflekeyDataExpression
SubQuery de chave de ( partição de consulta = T | | hint.shufflekey )
Saiba mais sobre as convenções de sintaxe.
Parâmetros
| Nome | Digitar | Obrigatória | Descrição |
|---|---|---|---|
| T | string |
✔️ | A fonte tabular cujos dados devem ser processados pelo operador. |
| Expressão de Dados | string |
Uma expressão de transformação tabular implícita ou explícita. | |
| Consulta | string |
Uma expressão de transformação executada nos registros de T. | |
| chave | string |
Use uma join chave, summarize chave, make-series chave ou partition chave. |
|
| Subconsulta | string |
Uma expressão de transformação. |
Observação
DataExpression ou Query devem ser especificados dependendo da sintaxe escolhida.
Exemplos
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
Saída
| Count |
|---|
| 67 |
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
Saída
| Count |
|---|
| 103 |
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
Saída
| Estado | sum_DamageProperty | StartTime |
|---|---|---|
| DAKOTA DO NORTE | [60000,0,0] | ["2006-12-31T00:00:00.0000000Z","2007-01-15T00:00:00.0000000Z","2007-01-30T00:00:00.0000000Z"] |
| NORTH CAROLINA | [20000,0,1000] | ["2006-12-31T00:00:00.0000000Z","2007-01-15T00:00:00.0000000Z","2007-01-30T00:00:00.0000000Z"] |
| ATLANTIC NORTH | [0,0,0] | ["2006-12-31T00:00:00.0000000Z","2007-01-15T00:00:00.0000000Z","2007-01-30T00:00:00.0000000Z"] |
Usar partição com ordem aleatória
StormEvents
| partition hint.strategy=shuffle by EpisodeId
(
top 3 by DamageProperty
| project EpisodeId, State, DamageProperty
)
| count
Saída
| Count |
|---|
| 22345 |
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
Saída
| Count |
|---|
| 14 |
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
Saída
| Count |
|---|
| 14 |
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
Saída
| EpisodeId | EventId | ... | Episódio Id1 | EventId1 | ... |
|---|---|---|---|---|---|
| 1030 | 4407 | ... | 1030 | 4407 | ... |
| 1030 | 13721 | ... | 1030 | 13721 | ... |
| 2477 | 12530 | ... | 2477 | 12530 | ... |
| 2103 | 10237 | ... | 2103 | 10237 | ... |
| 2103 | 10239 | ... | 2103 | 10239 | ... |
| ... | ... | ... | ... | ... | ... |
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
Saída
| EpisodeId | EventId | ... | Episódio Id1 | EventId1 | ... |
|---|---|---|---|---|---|
| 1030 | 4407 | ... | 1030 | 4407 | ... |
| 1030 | 13721 | ... | 1030 | 13721 | ... |
| 2477 | 12530 | ... | 2477 | 12530 | ... |
| 2103 | 10237 | ... | 2103 | 10237 | ... |
| 2103 | 10239 | ... | 2103 | 10239 | ... |
| ... | ... | ... | ... | ... | ... |
Use resumir com ordem aleatória para melhorar o desempenho
Neste exemplo, usar o operador com shuffle estratégia melhora o summarize 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
Saída
| Count |
|---|
| 1086 |
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
Saída
| Count |
|---|
| 1086 |
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