Partager via


Importance de la charge de travail Azure Synapse Analytics

Cet article explique comment l’importance de la charge de travail peut influencer l’ordre d’exécution des requêtes de pool SQL dédiées dans Azure Synapse.

Importance

Les besoins métier peuvent exiger que les charges de travail d’entreposage de données soient plus importantes que d’autres. Envisagez un scénario dans lequel les données de ventes 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éorologiques, n’ont pas de SLA strict. La définition d’une importance élevée pour une demande de chargement des données de vente et une faible importance pour une demande de chargement des données météorologiques garantit que la charge des données de vente obtient d’abord l’accès aux ressources et se termine plus rapidement.

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 d’importance

Au-delà du scénario d’importance de base décrit ci-dessus avec les données commerciales et météorologiques, il existe d’autres scénarios où l’importance de la charge de travail permet de répondre aux besoins de traitement et d’interrogation des données.

Verrouillage

L’accès aux verrous pour l’activité de lecture et d’écriture est une zone de contention naturelle. Les activités telles que le changement de partition ou RENAME OBJECT nécessitent des verrous élevés. Sans importance de la charge de travail, le pool SQL dédié dans Azure Synapse optimise le débit. L’optimisation du débit signifie que lorsque les requêtes en cours d’exécution et en file d’attente ont les mêmes besoins en verrouillage et que les ressources sont disponibles, les requêtes en attente peuvent passer avant celles avec des besoins de verrouillage plus élevés qui sont arrivées dans la file d’attente de requêtes auparavant. Lorsque l'importance de la charge de travail est appliquée aux requêtes nécessitant des besoins de verrouillage plus élevés. La demande avec une importance plus élevée sera exécutée avant la demande avec une importance inférieure.

Prenons l'exemple suivant :

  • Q1 s'exécute activement et sélectionne des données de SalesFact.
  • Q2 est mis en file d'attente en attendant la complétion de Q1. Cette requête a été soumise à 9h00 et tente de procéder au basculement des partitions de nouvelles données dans SalesFact.
  • Q3 est envoyé à 9h01 et souhaite sélectionner des données dans SalesFact.

Si Q2 et Q3 ont la même importance et que Q1 est toujours en cours d’exécution, Q3 commence à s’exécuter. Q2 continuera d'attendre l'obtention d'un verrou exclusif sur SalesFact. Si le Q2 a une importance supérieure à la Q3, le Q3 attend que le Q2 soit terminé avant de pouvoir commencer l’exécution.

Demandes non uniformes

Un autre scénario où l’importance peut aider à répondre aux demandes de requêtes est le cas où les requêtes avec différentes classes de ressources sont envoyées. Comme mentionné précédemment, sous la même importance, le pool SQL dédié dans Azure Synapse optimise le débit. Lorsque les demandes de taille mixte (telles que smallrc ou mediumrc) sont mises en file d’attente, le pool SQL dédié choisit la demande la plus ancienne qui s’adapte aux ressources disponibles. Si l’importance de la charge de travail est appliquée, la demande d’importance la plus élevée est planifiée ensuite.

Prenons 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.

Étant donné que Q5 est mediumrc, il nécessite deux créneaux de simultanéité. Q5 doit attendre que deux des requêtes en cours d’exécution se terminent. Toutefois, lorsque l’une des requêtes en cours d’exécution (Q1-Q4) se termine, Q6 est planifié immédiatement, car les ressources existent pour exécuter la requête. Si Q5 a une importance supérieure à Q6, Q6 attend que Q5 soit en cours d’exécution avant qu’il puisse commencer à s’exécuter.

Étapes suivantes