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. # Surveillance des requêtes et des charges de travail avec Amazon Redshift sans serveur Vous pouvez surveiller vos requêtes Amazon Redshift sans serveur et votre charge de travail à l’aide des vues système fournies. Les *vues de surveillance* sont des vues système dans Amazon Redshift sans serveur utilisées pour contrôler l’utilisation des requêtes et des charges de travail. Ces vues se trouvent dans le schéma `pg_catalog`. Les vues système disponibles ont été conçues pour vous fournir les informations nécessaires pour surveiller Amazon Redshift sans serveur, ce qui s’avère beaucoup plus simple que nécessaire pour les clusters mis en service. Les vues système SYS ont été conçues pour fonctionner avec Amazon Redshift sans serveur. Pour afficher les informations fournies par ces vues, exécutez les instructions SQL SELECT. Les vues système sont définies pour prendre en charge les objectifs de surveillance suivants. **Surveillance de la charge de travail** Vous pouvez contrôler vos activités de requête au fil du temps pour les tâches suivantes : + Comprenez les modèles de charge de travail afin de savoir ce qui est normal (base de référence) et ce qui figure dans les accords de niveau de service aux entreprises (SLAs). + Identifier rapidement l’écart par rapport à la normale, qui peut être un problème transitoire ou quelque chose qui justifie une action supplémentaire. **Surveillance du chargement et du déchargement de données** Le mouvement des données vers et depuis Amazon Redshift sans serveur constitue une fonction essentielle. Vous utilisez COPY et UNLOAD pour charger ou décharger des données, et vous devez suivre de près les progrès en termes de bytes/rows transfert et de finalisation des fichiers afin de vérifier le respect des activités. SLAs Cela se fait généralement en exécutant fréquemment des requêtes dans les tables système (c'est-à-dire toutes les minutes) afin de suivre les progrès et de déclencher des alertes pour que des investigation/corrective mesures soient prises si des écarts importants sont détectés. **Diagnostic d’échecs et des problèmes** Dans certains cas, vous devez prendre des mesures en cas d’échec de requête ou d’exécution. Les développeurs s’appuient sur des tables système pour auto-diagnostiquer les problèmes et déterminer les solutions correctes. **Personnalisation de performances** Vous devrez peut-être régler les requêtes qui ne répondent pas aux exigences de SLA depuis le début ou qui se sont dégradées au fil du temps. Pour effectuer un réglage, vous devez disposer de détails sur l’exécution, notamment le plan d’exécution, les statistiques, la durée et la consommation de ressources. Il vous faut des données de référence pour les requêtes incriminées afin de déterminer la cause de l’écart et de vous indiquer comment améliorer les performances. **Surveillance des événements des objets utilisateur** Vous devez contrôler les actions et les activités sur les objets utilisateur, comme l’actualisation des vues matérialisées, le vide et l’analyse. Cela inclut les événements gérés par le système, tels que l’actualisation automatique des vues matérialisées. Vous souhaitez contrôler la moment où un événement se termine s’il est initié par l’utilisateur, ou la dernière exécution réussie si le système est initié. **Suivi de l’utilisation pour la facturation** Vous pouvez contrôler vos tendances d’utilisation au fil du temps pour effectuer les actions suivantes : + Informer la planification budgétaire et les estimations de l’expansion opérationnelle. + Identifier les opportunités potentielles d’économies telles que la suppression des données froides. Utilisez les vues système SYS pour surveiller Amazon Redshift sans serveur. Pour plus d’informations sur les vues de surveillance SYS, consultez [Vues de surveillance SYS](https://docs.aws.amazon.com//redshift/latest/dg/serverless_views-monitoring.html) dans le Guide du développeur de base de données Amazon Redshift. # Ajout d’une politique de surveillance des requêtes Un super-utilisateur peut fournir un accès à des utilisateurs qui ne sont pas des super-utilisateurs afin de pouvoir effectuer une surveillance des requêtes pour tous les utilisateurs. Tout d’abord, vous ajoutez une politique pour un utilisateur ou un rôle afin de fournir un accès à la surveillance des requêtes. Vous accordez ensuite une autorisation de surveillance des requêtes à l’utilisateur ou au rôle. **Pour ajouter la politique de surveillance des requêtes** 1. Sélectionnez [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. Sous **Access Management (Gestion des accès)**, choisissez **Policies (politiques)**. 1. Choisissez **Create Policy** (Créer une politique). 1. Choisissez **JSON**, puis collez la définition de politique suivante. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "redshift-data:ExecuteStatement", "redshift-data:DescribeStatement", "redshift-data:GetStatementResult", "redshift-data:ListDatabases" ], "Resource": "*" }, { "Effect": "Allow", "Action": "redshift-serverless:GetCredentials", "Resource": "*" } ] } ``` ------ 1. Choisissez **Examiner une politique**. 1. Dans le champ **Nom**, saisissez le nom de la politique, par exemple `query-monitoring`. 1. Choisissez **Create Policy** (Créer une politique). Après avoir créé la politique, vous pouvez accorder les autorisations appropriées. Pour activer l’accès, ajoutez des autorisations à vos utilisateurs, groupes ou rôles : + Utilisateurs et groupes dans AWS IAM Identity Center : Créez un jeu d’autorisations. Suivez les instructions de la rubrique [Création d’un jeu d’autorisations](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html) du *Guide de l’utilisateur AWS IAM Identity Center *. + Utilisateurs gérés dans IAM par un fournisseur d’identité : Créez un rôle pour la fédération d’identité. Suivez les instructions de la rubrique [Création d’un rôle pour un fournisseur d’identité tiers (fédération)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) dans le *Guide de l’utilisateur IAM*. + Utilisateurs IAM : + Créez un rôle que votre utilisateur peut assumer. Suivez les instructions de la rubrique [Création d’un rôle pour un utilisateur IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) dans le *Guide de l’utilisateur IAM*. + (Non recommandé) Attachez une politique directement à un utilisateur ou ajoutez un utilisateur à un groupe d’utilisateurs. Suivez les instructions de la rubrique [Ajout d’autorisations à un utilisateur (console)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) du *Guide de l’utilisateur IAM*. # Octroi d’autorisations de surveillance des requêtes à un utilisateur Les utilisateurs avec une autorisation `sys:monitor` peuvent afficher toutes les requêtes. En outre, les utilisateurs avec une autorisation `sys:operator` peuvent annuler des requêtes, analyser l’historique des requêtes et effectuer des opérations de vide. **Pour accorder une autorisation de surveillance des requêtes à un utilisateur** 1. Saisissez la commande suivante pour fournir un accès au moniteur système, où *user-name* correspond au nom de l’utilisateur auquel vous souhaitez fournir un accès. ``` grant role sys:monitor to "IAM:user-name"; ``` 1. (Facultatif) Saisissez la commande suivante pour fournir un accès à l’opérateur système, où *user-name* correspond au nom de l’utilisateur auquel vous souhaitez fournir un accès. ``` grant role sys:operator to "IAM:user-name"; ``` # Octroi d’autorisations de surveillance des requêtes à un rôle Les utilisateurs ayant un rôle avec une autorisation `sys:monitor` peuvent afficher toutes les requêtes. En outre, les utilisateurs ayant un rôle qui a une autorisation `sys:operator` peuvent annuler des requêtes, analyser l’historique des requêtes et effectuer des opérations de vide. **Pour accorder une autorisation de surveillance des requêtes à un rôle** 1. Saisissez la commande suivante pour fournir un accès au moniteur système, où *role-name* correspond au nom du rôle auquel vous souhaitez fournir un accès. ``` grant role sys:monitor to "IAMR:role-name"; ``` 1. (Facultatif) Saisissez la commande suivante pour fournir un accès à l’opérateur système, où *role-name* correspond au nom du rôle auquel vous souhaitez fournir un accès. ``` grant role sys:operator to "IAMR:role-name"; ``` # Définition des limites d’utilisation, y compris la définition des limites des RPU Dans l'onglet **Limites** d'un groupe de travail, vous pouvez ajouter une ou plusieurs limites d'utilisation pour contrôler le maximum RPUs que vous utilisez sur une période donnée, ou pour définir une limite d'utilisation pour le partage de données. 1. Choisissez **Manage usage limits** (Gérer les limites d’utilisation). La section des limites apparaît au bas du panneau **Utilisation du calcul par période**. 1. Définissez une limite d’utilisation sous la forme d’un nombre d’heures de RPU. 1. Choisissez une **Fréquence**, qui peut être **Quotidienne**, **Hebdomadaire** ou **Mensuelle**. Ce paramètre définit la période de temps pour la limite d’utilisation. Choisir **Daily** (Quotidienne) dans ce cas vous donne un contrôle plus détaillé. 1. Définissez une limite d’utilisation, en nombre d’heures. 1. Définissez l’action. Les actions sont les suivantes : + **Journaliser dans la table système** : ajoute un enregistrement à la vue système [SYS\$1QUERY\$1HISTORY](https://docs.aws.amazon.com/redshift/latest/dg/SYS_QUERY_HISTORY.html). Vous pouvez interroger la colonne `usage_limit` dans cette vue pour déterminer si une requête a dépassé la limite. + **Alert** (Alerte) : utilise Amazon SNS pour configurer les abonnements aux notifications et envoyer des notifications si une limite est dépassée. Vous pouvez choisir une rubrique Amazon SNS existante ou en créer une autre. + **Turn off user queries** (Désactiver les requêtes de l’utilisateur) : désactive les requêtes pour arrêter l’utilisation d’Amazon Redshift sans serveur. L’action envoie également une notification. Les deux premières actions ont une visée informative, mais la dernière désactive le traitement des requêtes. 1. Vous pouvez éventuellement définir une **Cross-Region data sharing usage limit** (Limite d’utilisation du partage de données entre régions), qui limite la quantité de données transférées de la région productrice à la région consommatrice que les consommateurs peuvent interroger. Pour ce faire, choisissez **Add limit** (Ajouter une limite) et suivez les étapes. 1. En bas de la page, choisissez **Enregistrer les modifications** pour enregistrer cette limite. 1. Définissez jusqu’à 3 limites supplémentaires si nécessaire. Pour plus d'informations conceptuelles sur la facturation RPUs et sur la facturation, consultez la section [Facturation pour Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-billing.html) Serverless. # Définition des limites des requêtes Sous l’onglet **Limits** (Limites) d’un groupe de travail, vous pouvez ajouter une limite pour surveiller les performances et les limites. Pour plus d’informations sur les limites de surveillance de requête, consultez [Règles de surveillance de requête WLM](https://docs.aws.amazon.com/redshift/latest/dg/cm-c-wlm-query-monitoring-rules.html). 1. Choisissez **Manage query limits** (Gérer les limites des requêtes). Choisissez **Add new limit** (Ajouter une nouvelle limite) dans la boîte de dialogue **Manage query limits** (Gérer les limites des requêtes). 1. Choisissez le type de limite que vous souhaitez définir et saisissez une valeur pour la limite correspondante. 1. Choisissez **Save changes** (Enregistrer les modifications) pour enregistrer la limite. Lorsque vous modifiez votre limite de requête et vos paramètres de configuration, votre base de données redémarre. # Configuration de files d'attente de requêtes Amazon Redshift Serverless prend en charge la gestion des ressources de requêtes basée sur les files d'attente. Vous pouvez créer des files d’attente de requêtes dédiées avec des règles de surveillance personnalisées pour différentes charges de travail. Cette fonctionnalité permet un contrôle granulaire de l’utilisation des ressources. Les règles de surveillance des requêtes (QMR) s'appliquent uniquement au niveau du groupe de travail Redshift Serverless, affectant de manière uniforme toutes les requêtes exécutées dans ce groupe de travail. L’approche basée sur les files d’attente vous permet de créer des files d’attente avec des règles de surveillance distinctes. Vous pouvez attribuer ces files d’attente à des rôles d’utilisateur et à des groupes de requêtes spécifiques. Chaque file d’attente fonctionne indépendamment, les règles n’affectant que les requêtes de cette file d’attente. Les files d'attente vous permettent de définir des prédicats basés sur des métriques et des réponses automatisées. Par exemple, vous pouvez configurer des règles pour abandonner automatiquement les requêtes qui dépassent les limites de temps ou consomment trop de ressources. ## Considérations Lorsque vous utilisez des files d'attente sans serveur, tenez compte des points suivants : + Les clés de configuration de gestion de la charge de travail (WLM) suivantes utilisées dans les clusters provisionnés par Amazon Redshift ne sont pas prises en charge dans les files d'attente Redshift Serverless `max_execution_time` :`short_query_queue`,,,,,,,`auto_wlm`,`concurrency_scaling`. `priority` `queue_type` `query_concurrency` `memory_percent_to_use` `user_group` `user_group_wild_card` De plus, les actions hop, change\$1query\$1priority ne sont pas prises en charge dans Serverless. + L'action hop (déplacement des requêtes entre les files d'attente) n'est pas prise en charge dans Amazon Redshift Serverless. + Les priorités de file d'attente ne sont prises en charge que pour les clusters provisionnés par Amazon Redshift. + Amazon Redshift Serverless gère automatiquement le dimensionnement et l'allocation des ressources pour des performances optimales. Vous n'avez donc pas besoin de configurer manuellement les priorités des files d'attente. ## Configuration de files d'attente de requêtes Vous pouvez créer des files d'attente sous l'onglet Limits pour un groupe de travail sans serveur à l'aide de l' AWS Management Console API Redshift Serverless AWS CLI ou Redshift. ------ #### [ Console ] Suivez ces étapes pour créer une file d'attente pour votre groupe de travail sans serveur. 1. Accédez à votre groupe de travail Redshift Serverless. 1. Sélectionnez l'onglet Limites. 1. Sous **Query Queues**, sélectionnez **Activer les files** d'attente. **Important** L'activation des files d'attente de requêtes est une modification permanente. Vous ne pouvez pas revenir à la surveillance sans file d'attente une fois activée. 1. Configurez vos files d'attente à l'aide des paramètres suivants : **Paramètres de niveau de file d'attente** + `name`- Identifiant de file d'attente (obligatoire, unique, non vide) + `user_role`- Tableau de rôles utilisateur (facultatif) + `query_group`- Tableau de groupes de requêtes (facultatif) + `query_group_wild_card`- 0 ou 1 pour activer la correspondance par caractères génériques (facultatif) + `user_group_wild_card`- 0 ou 1 pour activer la correspondance par caractères génériques (facultatif) + `rules`- Ensemble de règles de surveillance (facultatif) **Paramètres au niveau des règles** + `rule_name`- Identifiant unique, 32 caractères maximum (obligatoire) + `predicate`- Ensemble de conditions, 1 à 3 prédicats (obligatoire) + `action`- « abort » ou « log » (obligatoire) **Paramètres du niveau du prédicat** + `metric_name`- Métrique à surveiller (obligatoire) + `operator`- « = », « < », or « > » (obligatoire) + `value`- Seuil numérique (obligatoire) **Restrictions** + 8 files d'attente maximum + 25 règles maximum pour toutes les files d'attente + 3 prédicats maximum par règle + Les noms de règles doivent être uniques à l'échelle mondiale **Exemple de configuration** Trois exemples de files d'attente : une pour les requêtes de tableau de bord avec un délai d'attente court, une pour les requêtes ETL avec un long délai d'attente et une file d'administration : ``` [ { "name": "dashboard", "user_role": ["analyst", "viewer"], "query_group": ["reporting"], "query_group_wild_card": 1, "rules": [ { "rule_name": "short_timeout", "predicate": [ { "metric_name": "query_execution_time", "operator": ">", "value": 60 } ], "action": "abort" } ] }, { "name": "ETL", "user_role": ["data_scientist"], "query_group": ["analytics", "ml"], "rules": [ { "rule_name": "long_timeout", "predicate": [ { "metric_name": "query_execution_time", "operator": ">", "value": 3600 } ], "action": "log" }, { "rule_name": "memory_limit", "predicate": [ { "metric_name": "query_temp_blocks_to_disk", "operator": ">", "value": 100000 } ], "action": "abort" } ] }, { "name": "admin_queue", "user_role": ["admin"], "query_group": ["admin"] } ] ``` Dans cet exemple : + Les requêtes du tableau de bord sont abandonnées si elles durent plus de 60 secondes + Les requêtes ETL sont enregistrées si elles durent plus d'une heure + La file d'attente des administrateurs n'a aucune limite de ressources ------ #### [ CLI ] Vous pouvez gérer les files d'attente à l'aide du paramètre CreateWorkgroup ou UpdateWorkgroup APIs avec le paramètre de `wlm_json_configuration` configuration pour spécifier les files d'attente au format JSON. ``` aws redshift-serverless create-workgroup \ --workgroup-name test-workgroup \ --namespace-name test-namespace \ --config-parameters '[{"parameterKey": "wlm_json_configuration", "parameterValue": "[{\"name\":\"dashboard\",\"user_role\":[\"analyst\",\"viewer\"],\"query_group\":[\"reporting\"],\"query_group_wild_card\":1,\"rules\":[{\"rule_name\":\"short_timeout\",\"predicate\":[{\"metric_name\":\"query_execution_time\",\"operator\":\">\",\"value\":60}],\"action\":\"abort\"}]},{\"name\":\"ETL\",\"user_role\":[\"data_scientist\"],\"query_group\":[\"analytics\",\"ml\"],\"rules\":[{\"rule_name\":\"long_timeout\",\"predicate\":[{\"metric_name\":\"query_execution_time\",\"operator\":\">\",\"value\":3600}],\"action\":\"log\"},{\"rule_name\":\"memory_limit\",\"predicate\":[{\"metric_name\":\"query_temp_blocks_to_disk\",\"operator\":\">\",\"value\":100000}],\"action\":\"abort\"}]},{\"name\":\"admin_queue\",\"user_role\":[\"admin\"],\"query_group\":[\"admin\"]}]"}]' ``` ------ ## Bonnes pratiques Gardez à l'esprit les meilleures pratiques suivantes lorsque vous utilisez des files d'attente sans serveur. + Utilisez des files d'attente distinctes pour les charges de travail soumises à des exigences de limites distinctes (par exemple, ETL, rapports ou analyses ad hoc). + Commencez par des seuils simples et ajustez-les en fonction du comportement des requêtes et des modèles d'utilisation. Vous pouvez surveiller les modèles d'utilisation des requêtes à l'aide des tables et des vues documentées dans la [section Tables et vues système pour les règles de surveillance des requêtes](https://docs.aws.amazon.com/redshift/latest/dg/cm-c-wlm-query-monitoring-rules.html#cm-c-wlm-qmr-tables-and-views). # Vérification des données récapitulatives d’Amazon Redshift sans serveur à l’aide du tableau de bord Le tableau de bord Amazon Redshift Serverless contient un ensemble de panneaux qui présentent des at-a-glance métriques et des informations sur votre groupe de travail et votre espace de noms. Ces volets sont les suivants : + **Resources summary** (Récapitulatif des ressources) : affiche des informations de haut niveau à propos d’Amazon Redshift sans serveur, telles que le stockage utilisé et d’autres métriques. + **Query summary** (Résumé des requêtes) : affiche des informations sur les requêtes, notamment les requêtes terminées et les requêtes en cours d’exécution. Choisissez **View details** (Afficher les détails) pour accéder à un écran offrant des filtres supplémentaires. + **RPU capacity used** (Capacité de RPU utilisée) : affiche la capacité globale utilisée sur une période donnée, comme les dix heures précédentes, par exemple. + **Partage de données** : indique le nombre de partages de données utilisés pour partager des données entre, par exemple, des comptes. AWS Les métriques indiquent les unités de partage de données nécessitant une autorisation et d’autres informations. + **Utilisation totale du calcul** : indique le nombre total d’heures de RPU consommées pour le groupe de travail sélectionné sur une plage de temps sélectionnée, jusqu’aux 7 derniers jours. À partir du tableau de bord, vous pouvez vous plonger rapidement dans ces métriques disponibles pour vérifier un détail concernant Amazon Redshift sans serveur, ou analyser des requêtes, ou encore suivre des éléments de travail.