Priorité de requête - Amazon Redshift
Configuration de la priorité de file d’attenteModification de la priorité de requête avec QMRSurveillance de la priorité de requête

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

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é la gestion automatique de la charge de travail, 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) :

  1. HIGHEST

  2. HIGH

  3. NORMAL

  4. LOW

  5. LOWEST

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.

Note

Seule une requête CRITICAL peut être exécutée à la fois.

Prenons un exemple dans lequel la priorité d’une charge de travail d’extraction, de transformation et de chargement (ETL) est supérieure à la priorité de la charge de travail d’analyse. La charge de travail ETL s’exécute toutes les 6 heures, et la charge de travail d’analyse 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. Toutefois, lorsque la charge de travail ETL démarre, elle est prioritaire en raison de sa priorité élevée. En plus de bénéficier d’une allocation préférentielle des ressources après avoir été admises, les requêtes s’exécutant dans le cadre de la charge de travail ETL sont prioritaires pendant l’admission. Ainsi, la charge de travail ETL s’exécute de manière prévisible quelles que soient les autres exécutions sur le système. Cela fournit donc des performances prévisibles et la capacité pour les administrateurs à fournir des accords de niveau de service (SLA) à leurs utilisateurs métiers.

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. Ainsi, cela permet à cette charge de travail de conserver sont débit, même si la charge de travail ETL s’exécute à une priorité élevée.

Configuration de la priorité de file d’attente

Si vous avez activé la gestion automatique de la charge de travail, chaque file d’attente a 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 de la CLI ou les opérations d’API, utilisez le paramètre wlm_json_configuration. 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 de requête (QMR) vous permettent de modifier la priorité d’une requête en fonction de son comportement pendant qu’elle s’exécute. Pour ce faire, spécifiez l’attribut de priorité dans une action et un prédicat QMR. Pour plus d’informations, consultez Règles de surveillance de requête WLM.

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.

  • La gestion automatique de la charge de travail (WLM) est activée.

  • Une seule file d’attente WLM est définie.

  • Vous n’avez pas défini de règles de surveillance des requêtes (QMR, Query Monitoring Rules) qui définissent la priorité des requêtes. Ces règles comprennent la métrique QMR query_priority ou l’action QMR change_query_priority. Pour plus d’informations, consultez Règles de surveillance de requête WLM.