Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Priorité de requête

Avec Amazon Redshift, vous pouvez gérer la priorisation des requêtes et l'allocation des ressources entre les requêtes et les charges de travail simultanées à l'aide de la gestion de la charge de travail (WM). Les sections suivantes expliquent comment configurer les files d'attente WM, définir les propriétés des files d'attente telles que l'allocation de mémoire et le dimensionnement de la simultanéité, et implémenter des règles de priorité adaptées aux exigences de votre charge de travail.

Toutes les requêtes n’ont pas la même importance, et souvent les performances d’une charge de travail ou d’un ensemble d’utilisateurs peuvent être plus importantes. Si vous avez activé le mode automatique WLM, vous pouvez définir l'importance relative des requêtes dans une charge de travail en définissant une valeur de priorité. La priorité est spécifiée pour une file d’attente et héritée par toutes les requêtes associées à la file d’attente. Vous associez des requêtes à une file d’attente en mappant des groupes d’utilisateurs et des groupes de requêtes sur la file d’attente. Vous pouvez définir les priorités suivantes (de la plus élevée à la plus faible) :

Les administrateurs utilisent ces priorités pour montrer l’importance relative de leurs charges de travail lorsque des requêtes aux priorités différentes sont liées aux mêmes ressources. Amazon Redshift utilise la priorité lorsqu’il laisse des requêtes dans le système et pour déterminer la quantité de ressources allouées à une requête. Par défaut, les requêtes s’exécutent avec leur priorité définie sur NORMAL.

Une priorité supplémentaire, CRITICAL, qui est une priorité plus élevée que HIGHEST, est disponible pour les super-utilisateurs. Pour définir cette priorité, vous pouvez utiliser les fonctions CHANGE_QUERY_PRIORITY, CHANGE_SESSION_PRIORITY, et CHANGE_USER_PRIORITY. Pour autoriser un utilisateur de base de données à utiliser ces fonctions, vous pouvez créer une procédure stockée et accorder l’autorisation à un utilisateur. Pour obtenir un exemple, consultez CHANGE_SESSION_PRIORITY.

Prenons un exemple où la priorité d'une charge de travail d'extraction, de transformation, de chargement (ETL) est supérieure à la priorité de la charge de travail d'analyse. La ETL charge de travail s'exécute toutes les six heures et la charge de travail analytique s'exécute tout au long de la journée. Lorsque seule la charge de travail d’analyse s’exécute sur le cluster, les priorités de requête permettent au système de générer un haut débit avec une utilisation optimale du système. Cependant, lorsque la ETL charge de travail commence, elle est réglée car elle a une priorité plus élevée. Les requêtes exécutées dans le cadre de la ETL charge de travail sont réglées lors de l'admission et bénéficient également d'une allocation préférentielle des ressources après leur admission. Par conséquent, la ETL charge de travail fonctionne de manière prévisible, quels que soient les autres éléments en cours d'exécution sur le système. Il fournit ainsi des performances prévisibles et permet aux administrateurs de fournir des accords de niveau de service (SLAs) à leurs utilisateurs professionnels.

Au sein d’un cluster donné, les performances prévisibles d’une charge de travail à priorité élevée s’effectuent au prix de charges de travail à priorité plus faible. Les charges de travail à priorité plus faible s’exécutent plus longtemps, car leurs requêtes attendent que des requêtes plus importantes se terminent. Ou, elles s’exécutent plus longtemps car elles récupèrent moins de ressources lorsqu’elles s’exécutent simultanément avec des requêtes à priorité plus élevée. Les requêtes à priorité plus faible ne connaissent pas de pénurie, mais poursuivent leur progression à un rythme inférieur.

Dans l’exempleprécédent, l’administrateur peut activer mise à l’échelle de la simultanéité pour la charge de travail d’analyse. Cela permet à cette charge de travail de maintenir son débit, même si elle est exécutée avec une priorité élevée. ETL

Configuration de la priorité de file d’attente

Si vous avez activé l'option automatiqueWLM, chaque file d'attente possède une valeur de priorité. Les requêtes sont acheminées vers les files d’attente en fonction des groupes d’utilisateurs et des groupes de requêtes. Commencez avec une priorité de file d’attente définie sur NORMAL. Définissez la priorité plus élevée ou plus faible en fonction de la charge de travail associée aux groupes d’utilisateurs et groupes de requêtes de la file d’attente.

Vous pouvez modifier la priorité d’une file d’attente sur la console Amazon Redshift. Sur la console Amazon Redshift, la page Gestion de la charge de travail affiche les files d’attente et permet de modifier les propriétés des files d’attente telles que la priorité. Pour définir la priorité à l'aide API des opérations CLI ou, utilisez le wlm_json_configuration paramètre. Pour plus d’informations, consultez Configuration de la gestion de la charge de travail dans le Guide de la gestion du cluster Amazon Redshift.

L’exemple suivant wlm_json_configuration définit trois groupes d’utilisateurs (ingest, reporting et analytics). Les requêtes envoyées par les utilisateurs de l’un de ces groupes s’exécutent avec respectivement les priorités highest, normal et low.

[
    {
        "user_group": [
            "ingest"
        ],
        "priority": "highest",
        "queue_type": "auto"
    },
    {
        "user_group": [
            "reporting"
        ],
        "priority": "normal",
        "queue_type": "auto"
    },
    {
        "user_group": [
            "analytics"
        ],
        "priority": "low",
        "queue_type": "auto",
        "auto_wlm": true
    }
]

Modification de la priorité de requête avec les règles de surveillance de requête

Les règles de surveillance des requêtes (QMR) vous permettent de modifier la priorité d'une requête en fonction de son comportement pendant son exécution. Pour ce faire, spécifiez l'attribut de priorité dans un QMR prédicat en plus d'une action. Pour de plus amples informations, veuillez consulter WLMrègles de surveillance des requêtes.

Par exemple, vous pouvez définir une règle pour annuler n’importe quelle requête classée en tant que priorité high qui s’exécute pendant plus de 10 minutes.

"rules" :[
  {
    "rule_name":"rule_abort",
    "predicate":[
      {
        "metric_name":"query_cpu_time",
        "operator":">",
        "value":600
      },
      {
        "metric_name":"query_priority",
        "operator":"=",
        "value":"high"
      }
    ],
    "action":"abort"
  }
]

Un autre exemple consiste à spécifier une règle pour définir la priorité de requête sur lowest pour n’importe quelle priorité normal actuelle qui déverse plus de 1 To sur un disque.

"rules":[
  {
    "rule_name":"rule_change_priority",
    "predicate":[
      {
        "metric_name":"query_temp_blocks_to_disk",
        "operator":">",
        "value":1000000
      },
      {
        "metric_name":"query_priority",
        "operator":"=",
        "value":"normal"
      }
    ],
    "action":"change_query_priority",
    "value":"lowest"
  }
]

Surveillance de la priorité de requête

Pour afficher la priorité pour les requêtes en attente et en cours d’exécution, consultez la colonne query_priority dans la table du système stv_wlm_query_state.

query    | service_cl | wlm_start_time             | state            | queue_time | query_priority
---------+------------+----------------------------+------------------+------------+----------------
2673299  | 102        | 2019-06-24 17:35:38.866356 | QueuedWaiting    | 265116     | Highest
2673236  | 101        | 2019-06-24 17:35:33.313854 | Running          | 0          | Highest
2673265  | 102        | 2019-06-24 17:35:33.523332 | Running          | 0          | High
2673284  | 102        | 2019-06-24 17:35:38.477366 | Running          | 0          | Highest
2673288  | 102        | 2019-06-24 17:35:38.621819 | Running          | 0          | Highest
2673310  | 103        | 2019-06-24 17:35:39.068513 | QueuedWaiting    | 62970      | High
2673303  | 102        | 2019-06-24 17:35:38.968921 | QueuedWaiting    | 162560     | Normal
2673306  | 104        | 2019-06-24 17:35:39.002733 | QueuedWaiting    | 128691     | Lowest           

Pour répertorier les priorités de requête pour les requêtes terminées, consultez la colonne query_priority dans la table de système stl_wlm_query.

select query, service_class as svclass, service_class_start_time as starttime, query_priority 
from stl_wlm_query order by 3 desc limit 10;

  query  | svclass |         starttime          |    query_priority
---------+---------+----------------------------+----------------------
 2723254 |     100 | 2019-06-24 18:14:50.780094 | Normal
 2723251 |     102 | 2019-06-24 18:14:50.749961 | Highest  
 2723246 |     102 | 2019-06-24 18:14:50.725275 | Highest
 2723244 |     103 | 2019-06-24 18:14:50.719241 | High
 2723243 |     101 | 2019-06-24 18:14:50.699325 | Low
 2723242 |     102 | 2019-06-24 18:14:50.692573 | Highest
 2723239 |     101 | 2019-06-24 18:14:50.668535 | Low
 2723237 |     102 | 2019-06-24 18:14:50.661918 | Highest
 2723236 |     102 | 2019-06-24 18:14:50.643636 | Highest            

Pour optimiser le débit de votre charge de travail, Amazon Redshift peut modifier la priorité des requêtes soumises par l’utilisateur. Amazon Redshift utilise des algorithmes de machine learning avancés pour déterminer quand cette optimisation profite à votre charge de travail et l’applique automatiquement lorsque toutes les conditions suivantes sont remplies.