shuffle lekérdezés

A következőkre vonatkozik: ✅Microsoft Fabric✅Azure Data Explorer✅Azure Monitor✅Microsoft Sentinel

A shuffle lekérdezés a shuffle stratégiát támogató operátorokkal használt szemantikai-megőrző átalakítás. Az érintett adatoktól függően a shuffle stratégiával való lekérdezés jobb teljesítményt eredményezhet. Érdemesebb az shuffle lekérdezési stratégiát használni, ha a shuffle kulcs (join kulcs, summarize kulcs, make-series kulcs vagy partition kulcs) nagy számossággal rendelkezik, és a reguláris operátori lekérdezés eléri a lekérdezési korlátokat.

Az shuffle paranccsal a következő operátorokat használhatja:

• csatlakozás
• összegzése
• sorozat
• partíciós

A shuffle lekérdezési stratégia használatához adja hozzá a hint.strategy = shuffle vagy hint.shufflekey = <key>kifejezést. Ha hint.strategy=shufflehasznál, az operátor adatait az összes kulcs el fogja keverni. Ezt a kifejezést akkor használja, ha az összetett kulcs egyedi, de az egyes kulcsok nem elég egyediek, ezért az adatokat az elkeverett operátor összes kulcsával fogja elkeverni.

Az adatok shuffle stratégiával való particionálásakor az adatbetöltés minden fürtcsomóponton meg van osztva. Minden csomópont feldolgozza az adatok egy partícióját. A partíciók alapértelmezett száma megegyezik a fürtcsomópontok számával.

A partíció számát felül lehet bírálni a hint.num_partitions = total_partitionsszintaxissal, amely a partíciók számát szabályozza. Ez akkor hasznos, ha a fürtnek kis számú fürtcsomópontja van, és az alapértelmezett partíciók száma kicsi lesz, és a lekérdezés meghiúsul vagy hosszú végrehajtási időt vesz igénybe.

Bizonyos esetekben a hint.strategy = shuffle figyelmen kívül hagyja, és a lekérdezés nem fut shuffle stratégiában. Ez akkor fordulhat elő, ha:

• A join operátor bal vagy jobb oldalon egy másik shuffle-kompatibilis operátorral (join, summarize, make-series vagy partition) rendelkezik.
• A summarize operátor egy másik shuffle-kompatibilis operátor (join, summarize, make-series vagy partition) után jelenik meg a lekérdezésben.

Szintaxis

A hint.strategy = shuffle

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

T|summarizehint.strategy = shuffleDataExpression

T|Lekérdezés| partíció hint.strategy = shuffle(SubQuery)

hint.shufflekey = kulccsal

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

T|summarizehint.shufflekey = keyDataExpression

T|make-serieshint.shufflekey = keyDataExpression

T|Lekérdezés| partíció hint.shufflekey = kulcs(SubQuery)

További információ szintaxiskonvenciákról.

Paraméterek

Példák

Az ebben a szakaszban szereplő példa bemutatja, hogyan használható a szintaxis az első lépésekhez.

Összegzés használata a shuffle használatával

A shufflesummarize operátorral végzett stratégiai lekérdezés az összes fürtcsomópont terhelését osztja meg, ahol minden csomópont az adatok egy partícióját dolgozza fel.

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

kimeneti

Illesztés használata shuffle használatával

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

kimeneti

Sorozatok használata shuffle használatával

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

kimeneti

Partíció használata shuffle használatával

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

kimeneti

Hint.strategy=shuffle és hint.shufflekey=key összehasonlítása

Ha hint.strategy=shufflehasznál, az összes kulcs elkeveri az elkeveredett operátort. A következő példában a lekérdezés az adatokat EpisodeId és EventId kulcsként is összekeveri:

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

kimeneti

Az alábbi lekérdezés hint.shufflekey = keyhasznál. A fenti lekérdezés egyenértékű ezzel a lekérdezésrel.

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

kimeneti

Az adatok összefűzése több kulccsal

Bizonyos esetekben a hint.strategy=shuffle figyelmen kívül hagyja a rendszer, és a lekérdezés nem fut a shuffle stratégiában. Az alábbi példában például az illesztés a bal oldalán található összegzést tartalmazza, így a hint.strategy=shuffle használata nem alkalmazza az shuffle stratégiát a lekérdezésre:

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

kimeneti

A probléma megoldásához és a shuffle stratégiában való futtatáshoz válassza ki a summarize és join műveletekhez gyakran használt kulcsot. Ebben az esetben ez a kulcs EpisodeId. A hint.shufflekey segítségével adja meg a join shuffle billentyűt a 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

kimeneti

Az összegzés és a shuffle használata a teljesítmény javítása érdekében

Ebben a példában a summarize operátor használata shuffle stratégiával javítja a teljesítményt. A forrástábla 150 M rekordot tartalmaz, a csoport kulcsonkénti számossága pedig 10 M, amely 10 fürtcsomópontra oszlik.

Ha summarize operátort használ shuffle stratégia nélkül, a lekérdezés 1:08 után ér véget, és a memóriahasználati csúcs ~3 GB:

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

kimeneti

Miközben shuffle stratégiát használ summarize, a lekérdezés ~7 másodperc után fejeződik be, a memóriahasználat csúcsa pedig 0,43 GB:

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

kimeneti

Az alábbi példa egy két fürtcsomóponttal rendelkező fürt teljesítményét mutatja be egy 60M rekordot tartalmazó táblával, ahol a csoport számossága kulcsonként 2M.

A lekérdezés hint.num_partitions nélkül történő futtatása csak két partíciót használ (fürtcsomópontok számaként), és a következő lekérdezés ~1:10 percet vesz igénybe:

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

Ha a partíciók számát 10-esre állítja, a lekérdezés 23 másodperc után befejeződik:

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

Az illesztés és a shuffle használata a teljesítmény javítása érdekében

Az alábbi példa bemutatja, hogyan javítja a teljesítményt shuffle stratégia használata az join operátorral.

A példákat egy 10 csomópontot tartalmazó fürtön vettük mintául, ahol az adatok az összes csomóponton el vannak osztva.

A lekérdezés bal oldali forrástáblája 15 M rekordot tartalmaz, ahol a join kulcs számossága ~14 M. A lekérdezés jobb oldali forrása 150 M rekordokkal rendelkezik, és a join kulcs számossága 10M. A lekérdezés ~28 másodperc után véget ér, és a memóriahasználati csúcs 1,43 GB:

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

Ha shuffle stratégiát használ egy join operátorral, a lekérdezés ~4 másodperc után ér véget, és a memóriahasználati csúcs 0,3 GB:

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

Egy másik példában ugyanazokkal a lekérdezésekkel próbálkozunk egy nagyobb adathalmazon a következő feltételekkel:

• A join bal oldali forrása 150M, a kulcs számossága pedig 148 M.
• A join jobb oldali forrása 1,5B, a kulcs számossága pedig ~100M.

A join operátorral rendelkező lekérdezés 4 perc után eléri a korlátokat és az időtúllépést. Ha azonban shuffle stratégiát használ a join operátorral, a lekérdezés ~34 másodperc után ér véget, és a memóriahasználati csúcs 1,23 GB.

Az alábbi példa egy két fürtcsomóponttal rendelkező fürt fejlesztését mutatja be egy 60 M rekordból álló táblával, ahol a join kulcs számossága 2 M. A lekérdezés hint.num_partitions nélkül történő futtatása csak két partíciót használ (fürtcsomópontok számaként), és a következő lekérdezés ~1:10 percet vesz igénybe:

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

Amikor a partíciók számát 10-esre állítja, a lekérdezés 23 másodperc után befejeződik:

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