Stratégie de partitionnement

S’applique à : ✅Microsoft Fabric✅Azure Data Explorer

La stratégie de partitionnement définit si et comment les étendues (partitions de données) doivent être partitionnées pour une table spécifique ou une vue matérialisée.

La stratégie déclenche un processus en arrière-plan supplémentaire qui a lieu après la création d’étendues, suite à l’ingestion des données. Ce processus inclut la réutilisation des données à partir des étendues sources et la production d’étendues homogènes , dans lesquelles toutes les valeurs de la colonne désignée comme clé de partition résident dans une seule partition.

L’objectif principal de la stratégie de partitionnement est d’améliorer les performances des requêtes dans des scénarios pris en charge spécifiques.

Remarque

Par défaut, lorsqu’une stratégie de partitionnement de données n’est pas définie (est null), les étendues sont partitionnée par heure de création (ingestion). Dans la plupart des cas, il n’est pas nécessaire de définir une stratégie de partitionnement de données.

Scénarios pris en charge

Voici les seuls scénarios dans lesquels la définition d’une stratégie de partitionnement de données est recommandée. Dans tous les autres scénarios, la définition de la stratégie n’est pas recommandée.

• Filtres fréquents sur une cardinalité string ou guidune colonne moyenne ou élevée :
  • Par exemple : solutions multilocataires ou table de métriques où la plupart ou toutes les requêtes filtrent sur une colonne de type string ou, par exemple, le ou le MetricIdTenantId .guid
  • La cardinalité moyenne est d’au moins 10 000 valeurs distinctes.
  • Définissez la clé de partition de hachage comme étant la ou guid la string colonne, puis définissez la PartitionAssignmentMode propriété uniformsur .
• Agrégations ou jointures fréquentes sur une cardinalité string ou guid une colonne élevée :
  • Par exemple, les informations IoT provenant de nombreux capteurs différents ou des enregistrements universitaires de nombreux étudiants différents.
  • La cardinalité élevée est d’au moins 1 000 000 valeurs distinctes, où la distribution des valeurs dans la colonne est approximativement égale.
  • Dans ce cas, définissez la clé de partition de hachage sur la colonne fréquemment groupée par ou jointe, puis définissez la PartitionAssignmentMode propriété ByPartition sur .
• Ingestion de données hors ordre :
  • Les données ingérées dans une table peuvent ne pas être triées et partitionnées dans des étendues (partitions) en fonction d’une colonne spécifique datetime qui représente le temps de création des données et qui est couramment utilisée pour filtrer les données. Cela peut être dû à un remplissage à partir de fichiers sources hétérogènes qui incluent des valeurs datetime sur un intervalle de temps important.
  • Dans ce cas, définissez la clé de partition datetime de plage uniforme sur la datetime colonne.
  • Si vous avez besoin de stratégies de rétention et de mise en cache pour s’aligner sur les valeurs datetime de la colonne, au lieu d’aligner sur l’heure d’ingestion, définissez la OverrideCreationTime propriété truesur .

Attention

• Aucune limite codée en dur n’est définie sur le nombre de tables avec la stratégie de partitionnement définie. Toutefois, chaque table supplémentaire ajoute une surcharge au processus de partitionnement des données en arrière-plan. La définition d’une stratégie sur davantage de tables entraîne l’utilisation de ressources supplémentaires et un coût plus élevé en raison des transactions de stockage sous-jacentes. Pour plus d’informations, consultez capacité.
• Il n’est pas recommandé de définir une stratégie de partitionnement si la taille compressée des données par partition est censée être inférieure à 1 Go.
• Le processus de partitionnement entraîne des artefacts de stockage résiduels pour toutes les étendues remplacées pendant le processus de partitionnement et pendant le processus de fusion. La plupart des artefacts de stockage résiduels sont censés être supprimés pendant le processus de nettoyage automatique. L’augmentation de la valeur de la MaxPartitionCount propriété augmente le nombre d’artefacts de stockage résiduels et peut réduire les performances de nettoyage.
• Avant d’appliquer une stratégie de partitionnement sur une vue matérialisée, passez en revue les recommandations pour la stratégie de partitionnement de vues matérialisées.

Clés de partition

Les types de clés de partition suivants sont pris en charge.

Type	Type de colonne	Propriétés de partition	Valeur de partition
Hash	string ou guid	Function, , MaxPartitionCountSeed, ,PartitionAssignmentMode	Function(ColumnName, , SeedMaxPartitionCount)
Plage uniforme	datetime	RangeSize, , ReferenceOverrideCreationTime	bin_at(ColumnName, , ReferenceRangeSize)

Clé de partition de hachage

Si la stratégie inclut une clé de partition de hachage, toutes les étendues homogènes qui appartiennent à la même partition sont affectées au même nœud de données.

Remarque

L’opération de partitionnement des données ajoute une charge de traitement significative. Nous vous recommandons d’appliquer une clé de partition de hachage sur une table uniquement dans les conditions suivantes :

• Si la majorité des requêtes utilisent des filtres d’égalité (==, in()).
• La majorité des requêtes agrége/jointure sur une colonne spécifique de type string ou guid qui est de grande dimension (cardinalité de 10M ou supérieure), telle qu’un device_ID, ou user_ID.
• Le modèle d’utilisation des tables partitionnée est en charge de requête concurrentiel élevée, par exemple dans la supervision ou les applications de tableau de bord.

• Une fonction hash-modulo est utilisée pour partitionner les données.
• Les données dans des étendues homogènes (partitionnés) sont classées par la clé de partition de hachage.
  • Vous n’avez pas besoin d’inclure la clé de partition de hachage dans la stratégie d’ordre des lignes, si celle-ci est définie sur la table.
• Les requêtes qui utilisent la stratégie de hachage et dans lesquelles la shuffle key clé de partition de hachage de la table est utilisée joinsummarize ou make-series dans laquelle la clé de partition de hachage de la table sont censées s’améliorer, car la quantité de données requises pour se déplacer entre les nœuds est réduite.

Propriétés de partition

Propriété	Description	Valeurs prises en charge	Valeur recommandée
Function	Nom d’une fonction hash-modulo à utiliser.	XxHash64
MaxPartitionCount	Nombre maximal de partitions à créer (l’argument modulo à la fonction hash-modulo) par période.	Dans la plage (1,2048].	Des valeurs plus élevées entraînent une surcharge accrue du processus de partitionnement des données et un plus grand nombre d’étendues pour chaque période. 128 est la valeur recommandée. Les valeurs plus élevées augmenteront considérablement la surcharge de partitionnement des données après l’ingestion et la taille des métadonnées, et ne sont donc pas recommandées.
Seed	Permet de randomiser la valeur de hachage.	Entier positif.	1, qui est également la valeur par défaut.
PartitionAssignmentMode	Mode utilisé pour affecter des partitions à des nœuds.	ByPartition: toutes les étendues homogènes (partitionnée) qui appartiennent à la même partition sont affectées au même nœud. Uniform: les valeurs de partition des étendues sont ignorées. Les étendues sont affectées uniformément aux nœuds.	Si les requêtes ne rejoignent pas ou n’agrègent pas sur la clé de partition de hachage, utilisez Uniform. Sinon, utilisez ByPartition.

Exemple de clé de partition de hachage

Clé de partition de hachage sur une stringcolonne -typée nommée tenant_id. Elle utilise la XxHash64 fonction de hachage, avec MaxPartitionCount la valeur 128recommandée et la valeur par défaut Seed .1

{
  "ColumnName": "tenant_id",
  "Kind": "Hash",
  "Properties": {
    "Function": "XxHash64",
    "MaxPartitionCount": 128,
    "Seed": 1,
    "PartitionAssignmentMode": "Uniform"
  }
}

Clé de partition datetime de plage uniforme

Remarque

Appliquez uniquement une clé de partition datetime de plage uniforme sur une datetimecolonne typée dans une table lorsque les données ingérées dans la table sont peu susceptibles d’être ordonnées en fonction de cette colonne.

Dans ces cas, vous pouvez resufflé les données entre les étendues afin que chaque extension inclut des enregistrements d’un intervalle de temps limité. Ce processus entraîne l’efficacité des filtres sur la colonne au moment de la datetime requête.

La fonction de partition utilisée est bin_at() et n’est pas personnalisable.

Propriétés de partition

Propriété	Description	Valeur recommandée
RangeSize	Constante timespan scalaire qui indique la taille de chaque partition datetime.	Commencez par la valeur 1.00:00:00 (un jour). Ne définissez pas de valeur plus courte, car cela peut entraîner une grande quantité de petites étendues qui ne peuvent pas être fusionnées.
Reference	Constante datetime scalaire qui indique un point fixe dans le temps, selon laquelle les partitions datetime sont alignées.	Commencez par 1970-01-01 00:00:00. S’il existe des enregistrements dans lesquels la clé de partition datetime a null des valeurs, leur valeur de partition est définie sur la valeur de Reference.
OverrideCreationTime	Indiquant bool si les durées de création minimale et maximale de l’étendue du résultat doivent être remplacées par la plage des valeurs de la clé de partition.	La valeur par défaut est false. Définissez la valeur true si les données ne sont pas ingérées dans l’ordre de l’arrivée. Par exemple, un fichier source unique peut inclure des valeurs datetime distantes et/ou vous souhaiterez peut-être appliquer la rétention ou la mise en cache en fonction des valeurs datetime plutôt que de l’heure d’ingestion. Lorsque OverrideCreationTime la valeur est définie true, les étendues peuvent être manquées dans le processus de fusion. Les étendues sont manquées si leur durée de création est antérieure à la période de la Lookback stratégie de fusion Étendues de la table. Pour vous assurer que les étendues sont détectables, définissez la Lookback propriété HotCachesur .

Exemple de partition datetime de plage uniforme

L’extrait de code affiche une clé de partition de plage datetime uniforme sur une datetime colonne typée nommée timestamp. Il utilise datetime(2021-01-01) comme point de référence, avec une taille pour 7d chaque partition, et ne remplace pas les heures de création des étendues.

{
  "ColumnName": "timestamp",
  "Kind": "UniformRange",
  "Properties": {
    "Reference": "2021-01-01T00:00:00",
    "RangeSize": "7.00:00:00",
    "OverrideCreationTime": false
  }
}

Par objet de stratégie

Par défaut, la stratégie de partitionnement des données d’une table est null, auquel cas les données de la table ne seront pas repartitionnées après son ingestion.

La stratégie de partitionnement des données a les propriétés principales suivantes :

• PartitionKeys :

  • Collection de clés de partition qui définissent comment partitionner les données dans la table.
  • Une table peut avoir jusqu’à 2 des clés de partition, avec l’une des options suivantes :
    • Une clé de partition de hachage.
    • Une clé de partition datetime de plage uniforme.
    • Une clé de partition de hachage et une clé de partition datetime uniforme.
  • Chaque clé de partition a les propriétés suivantes :
    • ColumnName: - string Nom de la colonne selon laquelle les données seront partitionnée.
    • Kind: - string Type de partitionnement de données à appliquer (Hash ou UniformRange).
    • Properties: : property bag définit les paramètres selon lesquels le partitionnement est effectué.

• EffectiveDateTime :

  • Datetime UTC à partir de laquelle la stratégie est effective.
  • Cette propriété est facultative. S’il n’est pas spécifié, la stratégie prend effet pour les données ingérées après l’application de la stratégie.

Attention

• Vous pouvez définir une valeur datetime dans le passé et partitionner des données déjà ingérées. Toutefois, cette pratique peut augmenter considérablement les ressources utilisées dans le processus de partitionnement.
• Dans la plupart des cas, il est recommandé d’avoir uniquement des données nouvellement ingérées partitionnées et d’éviter de partitionner de grandes quantités de données historiques.
• Si vous choisissez de partitionner des données historiques, envisagez de le faire progressivement, en définissant EffectiveDateTime sur un précédent datetime dans les étapes allant jusqu’à quelques jours chaque fois que vous modifiez la stratégie.

Exemple de partitionnement de données

Objet de stratégie de partitionnement de données avec deux clés de partition.

1. Clé de partition de hachage sur une stringcolonne -typée nommée tenant_id.
   • Elle utilise la XxHash64 fonction de hachage, avec MaxPartitionCount la valeur 128recommandée et la valeur par défaut Seed .1
2. Clé de partition de plage datetime uniforme sur une datetime colonne de type nommée timestamp.
   • Il utilise datetime(2021-01-01) comme point de référence, avec une taille de 7d chaque partition.

{
  "PartitionKeys": [
    {
      "ColumnName": "tenant_id",
      "Kind": "Hash",
      "Properties": {
        "Function": "XxHash64",
        "MaxPartitionCount": 128,
        "Seed": 1,
        "PartitionAssignmentMode": "Uniform"
      }
    },
    {
      "ColumnName": "timestamp",
      "Kind": "UniformRange",
      "Properties": {
        "Reference": "2021-01-01T00:00:00",
        "RangeSize": "7.00:00:00",
        "OverrideCreationTime": false
      }
    }
  ]
}

Propriétés supplémentaires

Les propriétés suivantes peuvent être définies dans le cadre de la stratégie. Ces propriétés sont facultatives et nous vous recommandons de ne pas les modifier.

Propriété	Description	Valeur recommandée	Valeur par défaut
MinRowCountPerOperation	Cible minimale pour la somme du nombre de lignes des étendues sources d’une seule opération de partitionnement de données.		0
MaxRowCountPerOperation	Cible maximale pour la somme du nombre de lignes des étendues sources d’une opération de partitionnement de données unique.	Définissez une valeur inférieure à 5M si vous constatez que les opérations de partitionnement consomment une grande quantité de mémoire ou d’UC par opération.	0, avec une cible par défaut de 5 000 000 enregistrements.
MaxOriginalSizePerOperation	Cible maximale pour la somme de la taille d’origine (en octets) des étendues sources d’une opération de partitionnement de données unique.	Si les opérations de partitionnement consomment une grande quantité de mémoire ou d’UC par opération, définissez une valeur inférieure à 5 Go.	0, avec une cible par défaut de 5 368 709 120 octets (5 Go).

Processus de partitionnement des données

• Le partitionnement des données s’exécute en tant que processus en arrière-plan post-ingestion.
  • Une table qui est ingérée en continu est censée toujours avoir une « queue » de données qui n’est pas encore partitionnée (étendues nonhomogènes).
• Le partitionnement des données s’exécute uniquement sur des étendues chaudes, quelle que soit la valeur de la EffectiveDateTime propriété dans la stratégie.
  • Si le partitionnement des étendues à froid est nécessaire, vous devez ajuster temporairement la stratégie de mise en cache.

Vous pouvez surveiller l’état de partitionnement des tables avec des stratégies définies dans une base de données à l’aide de la commande de partitionnement des statistiques de partitionnement des étendues de base de données .show et des métriques de partitionnement.

Capacité de partitionnement

• Le processus de partitionnement des données entraîne la création d’étendues supplémentaires. La capacité de fusion des étendues peut augmenter progressivement, afin que le processus de fusion des étendues puisse continuer.

• S’il existe un débit d’ingestion élevé ou un nombre suffisant de tables qui ont une stratégie de partitionnement définie, la capacité de partitionnement des étendues peut augmenter progressivement afin que le processus de partitionnement puisse continuer.

::: moniker range = « azure-data-explorer »

• Pour éviter de consommer trop de ressources, ces augmentations dynamiques sont limitées. Vous devrez peut-être les augmenter progressivement et linéairement au-delà du plafond, s’ils sont entièrement utilisés.
  • Si l’augmentation des capacités entraîne une augmentation significative de l’utilisation des ressources du cluster, vous pouvez effectuer un scale-out/ du cluster, manuellement ou en activant la mise à l’échelle automatique. ::: moniker-end

Limites

• Les tentatives de partitionnement de données dans une base de données qui ont déjà plus de 5 000 000 étendues seront limitées.
  • Dans ce cas, la EffectiveDateTime propriété des stratégies de partitionnement des tables de la base de données sera automatiquement retardée de plusieurs heures, afin que vous puissiez réévaluer votre configuration et vos stratégies.

Valeurs hors norme dans les colonnes partitionnée

• Les situations suivantes peuvent contribuer à une distribution déséquilibrée des données entre les nœuds et dégrader les performances des requêtes :
  • Si une clé de partition de hachage inclut des valeurs qui sont beaucoup plus répandues que d’autres, par exemple, une chaîne vide ou une valeur générique (par null exemple, ou N/A).
  • Les valeurs représentent une entité (par exemple tenant_id) plus répandue dans le jeu de données.
• Si une clé de partition datetime d’une plage uniforme a un pourcentage suffisant de valeurs « éloignées » de la majorité des valeurs de la colonne, la surcharge du processus de partitionnement des données est augmentée et peut entraîner de nombreuses petites étendues pour effectuer le suivi. Un exemple de telle situation est les valeurs datetime du passé ou du futur lointains.

Dans ces deux cas, « corrigez » les données ou filtrez les enregistrements non pertinents dans les données avant ou au moment de l’ingestion, afin de réduire la surcharge du partitionnement des données. Par exemple, utilisez une stratégie de mise à jour.

Contenu connexe

• Commandes de gestion des stratégies de partitionnement