Amazon Redshift ne prendra plus en charge la création de nouveaux Python à UDFs partir du patch 198. UDFs Le Python existant continuera de fonctionner jusqu'au 30 juin 2026. Pour plus d’informations, consultez le [ billet de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
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 (WLM). Les sections suivantes expliquent comment configurer les files d’attente de la gestion de la charge de travail, 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é la [gestion automatique de la charge de travail](automatic-wlm.md), 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`
1. `HIGH`
1. `NORMAL`
1. `LOW`
1. `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\$1QUERY\$1PRIORITY](r_CHANGE_QUERY_PRIORITY.md), [CHANGE\$1SESSION\$1PRIORITY](r_CHANGE_SESSION_PRIORITY.md), et [CHANGE\$1USER\$1PRIORITY](r_CHANGE_USER_PRIORITY.md). 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\$1SESSION\$1PRIORITY](r_CHANGE_SESSION_PRIORITY.md).
**Note**
Seule une requête `CRITICAL` peut être exécutée à la fois.
Les restaurations sont toujours exécutées en tant que priorité CRITIQUE.
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. 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é](concurrency-scaling.md) 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](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html) 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](cm-c-wlm-query-monitoring-rules.md).
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\$1wlm\$1query\$1state.
```
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\$1wlm\$1query.
```
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 (QMRs) 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](cm-c-wlm-query-monitoring-rules.md).