shuffle query

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

La shuffle consulta es una transformación que conserva la semántica que se usa con un conjunto de operadores que admiten la shuffle estrategia. En función de los datos implicados, la consulta con la shuffle estrategia puede producir un mejor rendimiento. Es mejor usar la estrategia de consulta de orden aleatorio cuando la shuffle clave (una join clave, summarize clave, make-series clave o partition clave) tiene una cardinalidad alta y la consulta de operador normal alcanza los límites de consulta.

Puede usar los operadores siguientes con el comando shuffle:

• join
• summarize
• make-series
• partition

Para usar la estrategia de shuffle consulta, agregue la expresión hint.strategy = shuffle o hint.shufflekey = <key>. Cuando se usa hint.strategy=shuffle, todos los datos del operador se ordenan aleatoriamente por todas las claves. Use esta expresión cuando la clave compuesta sea única, pero cada clave no es lo suficientemente única, por lo que ordenará los datos mediante todas las claves del operador aleatorio.

Al crear particiones de datos con la estrategia de orden aleatorio, la carga de datos se comparte en todos los nodos del clúster. Cada nodo procesa una partición de los datos. El número predeterminado de particiones es igual al número de nodos de clúster.

El número de partición se puede invalidar mediante la sintaxis hint.num_partitions = total_partitions, que controlará el número de particiones. Esto resulta útil cuando el clúster tiene un pequeño número de nodos de clúster y el número de particiones predeterminado será pequeño y la consulta produce un error o tarda mucho tiempo de ejecución.

En algunos casos, hint.strategy = shuffle se omite y la consulta no se ejecutará en shuffle la estrategia. Esto puede suceder cuando:

• El join operador tiene otro shuffleoperador compatible (join, summarizeo make-seriespartition) en el lado izquierdo o en el lado derecho.
• El summarize operador aparece después de otro shuffleoperador compatible (join, summarizeo make-seriespartition) en la consulta.

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

En el ejemplo de esta sección se muestra cómo usar la sintaxis para ayudarle a empezar.

Uso de summarize con orden aleatorio

La shuffle consulta de estrategia con summarize el operador comparte la carga en todos los nodos de clúster, donde cada nodo procesa una partición de los datos.

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

Output

Uso de combinación con orden aleatorio

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

Uso de make-series con orden aleatorio

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

Uso de particiones con orden aleatorio

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

Output

Comparar hint.strategy=shuffle and hint.shufflekey=key

Cuando se usa hint.strategy=shuffle, el operador aleatorio se ordenará mediante todas las claves. En el ejemplo siguiente, la consulta ordena los datos mediante y EpisodeIdEventId como claves:

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

En la siguiente consulta se usa hint.shufflekey = key. La consulta anterior es 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

Orden aleatorio de los datos con varias claves

En algunos casos, hint.strategy=shuffle se omitirá y la consulta no se ejecutará en la estrategia de orden aleatorio. Por ejemplo, en el ejemplo siguiente, la combinación tiene un resumen en su lado izquierdo, por lo que el uso hint.strategy=shuffle de no aplicará la estrategia de orden aleatorio a la 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 solucionar este problema y ejecutarse en la estrategia de orden aleatorio, elija la clave que es común para las summarize operaciones y join . En este caso, esta clave es EpisodeId. Use la sugerencia hint.shufflekey para especificar la clave de orden aleatorio en a joinhint.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

Uso de summarize con orden aleatorio para mejorar el rendimiento

En este ejemplo, el uso del operador con summarize estrategia mejora el shuffle rendimiento. La tabla de origen tiene 150 millones de registros y la cardinalidad del grupo por clave es 10M, que se distribuye en 10 nodos de clúster.

El uso del summarize operador sin shuffle estrategia, la consulta finaliza después de las 1:08 y el pico de uso de memoria es de ~3 GB:

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

Output

Al usar shuffle la estrategia con summarize, la consulta finaliza después de aproximadamente 7 segundos y el pico de uso de memoria es de 0,43 GB:

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

Output

En el ejemplo siguiente se muestra el rendimiento en un clúster que tiene dos nodos de clúster, con una tabla que tiene registros de 60M, donde la cardinalidad del grupo por clave es 2M.

La ejecución de la consulta sin hint.num_partitions solo usará dos particiones (como número de nodos de clúster) y la consulta siguiente tardará unos 1:10 minutos:

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

Si establece el número de particiones en 10, la consulta finalizará después de 23 segundos:

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

Uso de combinación con orden aleatorio para mejorar el rendimiento

En el ejemplo siguiente se muestra cómo el uso shuffle de la estrategia con el operador mejora el join rendimiento.

Los ejemplos se muestrearon en un clúster con 10 nodos donde los datos se reparten en todos estos nodos.

La tabla de origen del lado izquierdo de la consulta tiene 15M registros donde la cardinalidad de la join clave es ~14M. El origen del lado derecho de la consulta tiene 150 M de registros y la cardinalidad de la join clave es de 10 M. La consulta finaliza después de aproximadamente 28 segundos y el pico de uso de memoria es de 1,43 GB:

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

Cuando se usa shuffle la estrategia con un join operador, la consulta finaliza después de aproximadamente 4 segundos y el pico de uso de memoria es de 0,3 GB:

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

En otro ejemplo, se prueban las mismas consultas en un conjunto de datos mayor con las siguientes condiciones:

• El origen izquierdo de join es 150M y la cardinalidad de la clave es 148M.
• La fuente del lado derecho de join es 1,5B y la cardinalidad de la clave es ~100M.

La consulta con solo el join operador alcanza los límites y agota el tiempo de espera después de 4 minutos. Sin embargo, cuando se usa shuffle la estrategia con el join operador , la consulta finaliza después de unos 34 segundos y el pico de uso de memoria es de 1,23 GB.

En el ejemplo siguiente se muestra la mejora en un clúster que tiene dos nodos de clúster, con una tabla de 60 millones de registros, donde la cardinalidad de la join clave es 2M. La ejecución de la consulta sin hint.num_partitions solo usará dos particiones (como número de nodos de clúster) y la consulta siguiente tardará unos 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

Al establecer el número de particiones en 10, la consulta finalizará después de 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