partition, opérateur

  • Article

L’opérateur de partition partitionne les enregistrements de sa table d’entrée en plusieurs sous-tableaux en fonction des valeurs d’une colonne clé. L’opérateur exécute une sous-requête sur chaque sous-table et produit une table de sortie unique qui est l’union des résultats de toutes les sous-requêtes.

Cet opérateur est utile lorsque vous devez effectuer une sous-requête uniquement sur un sous-ensemble de lignes qui appartient à la même clé de partition et ne pas interroger l’ensemble du jeu de données. Ces sous-requêtes peuvent inclure des fonctions d’agrégation, des fonctions de fenêtre, un N supérieur et d’autres.

L’opérateur de partition prend en charge plusieurs stratégies d’opération de sous-requête :

  • Natif : utiliser avec une source de données implicite avec des milliers de valeurs de partition clés.
  • Lecture aléatoire : utilisez avec une source implicite avec des millions de valeurs de partition de clé.
  • Hérité : utiliser avec une source implicite ou explicite pour 64 valeurs de partition clé ou moins.

Syntax

T|partition [ hint.strategy=Stratégie ] [ Indicateurs ] byTransformation de colonneSubQuery()

T|partition [ hint.strategy=legacy ] [ Indicateurs ] byColonne{SubQueryWithSource}

Découvrez les conventions de syntaxe.

Paramètres

Nom Type Obligatoire Description
T string ✔️ Source tabulaire d’entrée.
Stratégie string legacyValeur , shuffleou native. Cet indicateur définit la stratégie d’exécution de l’opérateur de partition.

Si aucune stratégie n’est spécifiée, la legacy stratégie est utilisée. Pour plus d’informations, consultez Stratégies.
Colonne string ✔️ Nom d’une colonne en T dont les valeurs déterminent comment partitionner la source tabulaire d’entrée.
TransformationSubQuery string ✔️ Expression de transformation tabulaire. La source est implicitement les sous-tables produites par le partitionnement des enregistrements de T. Chaque sous-tableau est homogène sur la valeur de Column.

L’expression ne doit fournir qu’un seul résultat tabulaire et ne doit pas avoir d’autres types d’instructions, comme let des instructions.
SubQueryWithSource string ✔️ Expression tabulaire qui inclut sa propre source tabulaire, telle qu’une référence de table. Cette syntaxe est uniquement prise en charge avec la stratégie héritée. La sous-requête peut uniquement référencer la colonne clé, Colonne, à partir de T. Pour référencer la colonne, utilisez la syntaxe toscalar(Column).

L’expression ne doit fournir qu’un seul résultat tabulaire et ne doit pas avoir d’autres types d’instructions, comme let des instructions.
Indicateurs string Zéro ou plusieurs paramètres séparés par l’espace sous la forme : Valeur HintName= qui contrôle le comportement de l’opérateur. Consultez les indicateurs pris en charge par type de stratégie.

Indicateurs pris en charge

Nom de l’indicateur Type Stratégie Description
hint.shufflekey string lecture aléatoire Clé de partition utilisée pour exécuter l’opérateur de partition avec la shuffle stratégie.
hint.materialized bool Héritage Si la valeur est définie truesur , matérialise la source de l’opérateur partition . La valeur par défaut est false.
hint.concurrency int Héritage Détermine le nombre de partitions à exécuter en parallèle. La valeur par défaut est 16.
hint.spread int Héritage Détermine comment distribuer les partitions entre les nœuds de cluster. La valeur par défaut est 1.

Par exemple, s’il existe N partitions et que l’indicateur de propagation est défini sur P, les partitions N seront traitées par des nœuds de cluster différents P de manière parallèle/séquentielle en fonction de l’indicateur d’accès concurrentiel.

Retours

L’opérateur retourne une union des résultats des sous-requêtes individuelles.

Stratégies

L’opérateur de partition prend en charge plusieurs stratégies d’opération de sous-requête : native, aléatoire et héritée.

Notes

La distinction entre les native stratégies et shuffle permet à l’appelant d’indiquer la cardinalité et la stratégie d’exécution de la sous-requête. Ce choix peut affecter la durée de la sous-requête, mais ne modifie pas le résultat final.

Stratégie native

Cette stratégie doit être appliquée lorsque le nombre de valeurs distinctes de la clé de partition n’est pas élevé, à peu près en milliers.

La sous-requête doit être une transformation tabulaire qui ne spécifie pas de source tabulaire. La source est implicite et est affectée en fonction des partitions de sous-table. Seuls certains opérateurs pris en charge peuvent être utilisés dans la sous-requête. Il n’existe aucune restriction sur le nombre de partitions.

Pour utiliser cette stratégie, spécifiez hint.strategy=native.

Stratégie de shuffle

Cette stratégie doit être appliquée lorsque le nombre de valeurs distinctes de la clé de partition est élevé, en millions.

La sous-requête doit être une transformation tabulaire qui ne spécifie pas de source tabulaire. La source est implicite et est affectée en fonction des partitions de sous-table. Seuls certains opérateurs pris en charge peuvent être utilisés dans la sous-requête. Il n’existe aucune restriction sur le nombre de partitions.

Pour utiliser cette stratégie, spécifiez hint.strategy=shuffle. Pour plus d’informations sur la stratégie et les performances de lecture aléatoire, consultez requête aléatoire.

Opérateurs pris en charge pour les stratégies natives et aléatoires

La liste suivante d’opérateurs peut être utilisée dans les sous-requêtes avec les stratégies natives ou aléatoires :

Notes

  • Les opérateurs qui référencent une source de table autre que les partitions subtables ne sont pas compatibles avec les native stratégies et shuffle . Par exemple, rejoindre, union, externaldata et évaluer (plug-ins). Pour de tels scénarios, recourez à la stratégie héritée.
  • L’opérateur fork n’est pris en charge pour aucun type de stratégie, car la sous-requête doit retourner un résultat tabulaire unique.

Stratégie héritée

Pour des raisons historiques, la legacy stratégie est la stratégie par défaut. Toutefois, nous vous recommandons de privilégier les stratégies natives ou aléatoires , car l’approche legacy est limitée à 64 partitions et est moins efficace.

Dans certains scénarios, la legacy stratégie peut être nécessaire en raison de sa prise en charge de l’inclusion d’une source tabulaire dans la sous-requête. Dans ce cas, la sous-requête peut uniquement référencer la colonne clé, Colonne, à partir de la source tabulaire d’entrée, T. Pour référencer la colonne, utilisez la syntaxe toscalar(Column).

Si la sous-requête est une transformation tabulaire sans source tabulaire, la source est implicite et est basée sur les partitions sous-tables.

Pour utiliser cette stratégie, spécifiez hint.strategy=legacy ou omettez toute autre indication de stratégie.

Notes

Une erreur se produit si la colonne de partition, Column, contient plus de 64 valeurs distinctes.

Exemples

Rechercher les valeurs principales

Dans certains cas, il est plus performant et plus facile d’écrire une requête à l’aide de l’opérateur partition que de l’utiliser top-nested . La requête suivante exécute une sous-requête de calcul summarize et top pour chacune State d’elles commençant par W: « WYOMING », « WASHINGTON », « WEST VIRGINIA » et « WISCONSIN ».

Exécuter la requête

StormEvents
| where State startswith 'W'
| partition hint.strategy=native by State 
    (
    summarize Events=count(), Injuries=sum(InjuriesDirect) by EventType, State
    | top 3 by Events 
    )

Sortie

Type d’événement État Événements Préjudices
Grêle WYOMING 108 0
Vent fort WYOMING 81 5
Tempête hivernale WYOMING 72 0
Neige lourde WASHINGTON 82 0
Vent fort WASHINGTON 58 13
Feu de forêt WASHINGTON 29 0
Vent d’orage WEST VIRGINIA 180 1
Grêle WEST VIRGINIA 103 0
Météo hivernale WEST VIRGINIA 88 0
Vent d’orage WISCONSIN 416 1
Tempête hivernale WISCONSIN 310 0
Grêle WISCONSIN 303 1

Stratégie native

La requête suivante retourne les 2 EventType premières valeurs par pour chacune State d’elles qui commence par TotalInjuries « W » :

Exécuter la requête

StormEvents
| where State startswith 'W'
| partition hint.strategy = native by State
    (
    summarize TotalInjueries = sum(InjuriesDirect) by EventType
    | top 2 by TotalInjueries
    )

Sortie

Type d’événement TotalInjueries
Tornade 4
Grêle 1
Vent d’orage 1
Chaleur excessive 0
Vent fort 13
Lightning 5
Vent fort 5
Avalanche 3

Stratégie de shuffle

La requête suivante retourne les 3 DamagedProperty premières valeurs foreach EpisodeId et les colonnes EpisodeId et State.

Exécuter la requête

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

Sortie

Count
22345

Stratégie héritée avec source explicite

La requête suivante exécute deux sous-requêtes :

  • Quand x == 1, la requête retourne toutes les lignes de StormEvents qui ont InjuriesIndirect == 1.
  • Quand x == 2, la requête retourne toutes les lignes de StormEvents qui ont InjuriesIndirect == 2.

Le résultat final est l’union de ces deux sous-requêtes.

Exécuter la requête

range x from 1 to 2 step 1
| partition hint.strategy=legacy by x {StormEvents | where x == InjuriesIndirect}
| count

Sortie

Count
113

Référence de partition

L’exemple suivant montre comment utiliser l’opérateur as pour donner un « nom » à chaque partition de données, puis comment réutiliser ce nom dans la sous-requête. Cette approche s’applique uniquement à la legacy stratégie.

T
| partition by Dim
(
    as Partition
    | extend MetricPct = Metric * 100.0 / toscalar(Partition | summarize sum(Metric))
)