Partager via

Importance des charges de travail Azure Synapse Analytics

  • Article

Cet article explique comment l’importance des charges de travail peut influer sur l’ordre d’exécution des requêtes de pool SQL dédié dans Azure Synapse.

importance

Certaines charges de travail d'entreposage de données peuvent être plus importantes que d'autres pour une entreprise. Imaginez un scénario dans lequel les données de vente critiques sont chargées avant la clôture de la période fiscale. Les chargements de données pour d'autres sources, telles que les données météo, n'ont pas de contrats de niveau de service stricts. Définir une haute importance pour une requête de chargement de données de vente et une faible importance pour une demande de chargement de données météo confère au chargement des données de vente une priorité sur les ressources et permet son exécution plus rapide.

Niveaux d'importance

Il existe cinq niveaux d’importance : low (faible), below_normal (inférieure à la normale), normal (normale), above_normal (supérieure à la normale) et high (haute). Par défaut, les requêtes se voient attribuer une importance normale. Les requêtes dotées du même niveau d’importance répondent au même comportement de planification qu'actuellement.

Scénarios avec importance

Au-delà du scénario avec importance de base décrit ci-dessus et portant sur des données de vente et données météo, il existe d'autres scénarios dans lesquels l'importance des charges de travail contribue à répondre aux besoins de traitement et d'interrogation des données.

Verrouillage

L'accès aux verrous des activités de lecture et d’écriture est un point de contention naturelle. Des activités telles que le basculement des partitions ou RENAME OBJECT requièrent des verrous avec élévation de privilèges. Sans l’importance des charges de travail, un pool SQL dédié dans Azure Synapse optimise le débit. Il y a optimisation du débit lorsque les requêtes en cours d'exécution et en file d'attente présentent les mêmes besoins de verrouillage en présence de ressources disponibles, et que les requêtes en file d'attente peuvent contourner les requêtes présentant des besoins de verrouillage plus élevés que celles arrivées dans la file d'attente plus tôt. L'importance des charges de travail est appliquée aux requêtes présentant des besoins de verrouillage plus élevés. Les requêtes présentant une importance plus élevée sont exécutées avant les requêtes présentant une plus faible importance.

Prenons l’exemple suivant :

  • Q1 est en cours d’exécution et sélectionne des données dans SalesFact.
  • Q2 est en file d’attente en attendant que Q1 se termine. Cette requête a été soumise à 9h00 et tente de procéder au basculement des partitions de nouvelles données dans SalesFact.
  • Q3 est soumise à 9h01 et souhaite sélectionner des données dans SalesFact.

Si Q2 et Q3 présentent la même importance, Q1 continue de s'exécuter et Q3 va commencer à s'exécuter. Q2 continue d'attendre un verrou exclusif sur SalesFact. Si Q2 présente une importance plus élevée que Q3, Q3 attend que Q2 ait terminé avant de commencer à s'exécuter.

Requêtes non uniformes

Les requêtes soumises avec différentes classes de ressources sont un autre exemple de scénario dans lequel l'importance contribue à répondre aux besoins d'interrogation. Comme indiqué précédemment, si l’importance est la même, un pool SQL dédié dans Azure Synapse optimise le débit. Quand des demandes de tailles différentes (par exemple, smallrc ou mediumrc) sont mises en file d’attente, un pool SQL dédié choisit la première demande arrivée en fonction des ressources disponibles. Si l’importance des charges de travail est appliquée, la requête présentant la plus haute importance est planifiée ensuite.

Considérez l'exemple suivant sur DW500c :

  • Q1, Q2, Q3 et Q4 exécutent des requêtes smallrc.
  • Q5 est soumise avec la classe de ressources mediumrc à 9h00.
  • Q6 est soumise avec la classe de ressources smallrc à 9h01.

La classe de ressources de Q5 étant mediumrc, elle nécessite deux emplacements de concurrence. Q5 doit attendre la fin de deux requêtes. Cela étant, lorsqu’une des requêtes en cours d’exécution (Q1 à Q4) se termine, Q6 est immédiatement planifiée, car les ressources permettent son exécution. Si Q5 présente une importance plus élevée que Q6, Q6 attend la fin de Q5 pour commencer à s'exécuter.

Étapes suivantes