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. # Gestion de la charge de travail Vous pouvez utiliser les fonctionnalités d'Athena relatives aux groupes de travail, à la gestion des capacités, au réglage des performances, à la prise en charge de la compression, aux balises et aux Service Quotas pour gérer votre charge de travail. **Topics** + [Utilisation de groupes de travail pour contrôler l’accès aux requêtes et les coûts](workgroups-manage-queries-control-costs.md) + [Gestion de la capacité de traitement des requêtes](capacity-management.md) + [Optimisation des performances d’Athena](performance-tuning.md) + [Utilisation de la compression dans Athena](compression-formats.md) + [Balisage des ressources Athena](tags.md) + [Service Quotas](service-limits.md) # Utilisation de groupes de travail pour contrôler l’accès aux requêtes et les coûts Vous pouvez utiliser des groupes de travail Athena pour séparer des charges de travail, contrôler l’accès des équipes, appliquer une configuration et suivre les métriques des requêtes et contrôler les coûts. **Séparation de vos charges de travail** Vous pouvez utiliser des groupes de travail pour séparer les charges de travail. Par exemple, vous pouvez créer deux groupes de travail indépendants, un pour les applications planifiées automatisées, telles que la génération de rapport, et un autre pour une utilisation ponctuelle par des analystes. **Contrôle de l’accès des équipes** Les groupes de travail agissant comme des ressources IAM, vous pouvez utiliser des stratégies basées sur l’identité au niveau des ressources pour déterminer qui peut accéder à un groupe de travail spécifique et y exécuter des requêtes. Pour isoler les requêtes de deux équipes de votre organisation, vous pouvez créer un groupe de travail distinct pour chaque équipe. Chaque groupe de travail dispose de son propre historique de requêtes et de la liste de ses requêtes enregistrées (et non de toutes les requêtes du compte). Pour de plus amples informations, veuillez consulter [Utilisation de politiques IAM pour contrôler l’accès aux groupes de travail.](workgroups-iam-policy.md). **Application d’une configuration** Vous pouvez éventuellement appliquer les mêmes paramètres à l’ensemble d’un groupe de travail pour toutes les requêtes exécutées dans ce groupe de travail. Ces paramètres incluent l’emplacement des résultats des requêtes dans Amazon S3, le propriétaire attendu du compartiment, le chiffrement et le contrôle des objets écrits dans le compartiment de résultats des requêtes. Pour de plus amples informations, veuillez consulter [Remplacer les paramètres côté client](workgroups-settings-override.md). **Suivi des métriques et événements des requêtes et contrôle des coûts** Pour suivre les métriques et événements des requêtes et contrôler les coûts pour chaque groupe de travail Athena, vous pouvez utiliser les fonctionnalités suivantes : + **Publier les métriques des requêtes** : publiez les métriques des requêtes pour votre groupe de travail sur CloudWatch. Vous pouvez consulter les métriques de requêtes de chaque groupe de travail dans la console Athena. Dans CloudWatch, vous pouvez créer des tableaux de bord personnalisés et définir des seuils et des alarmes pour ces mesures. Pour plus d’informations, consultez [Activer les métriques de CloudWatch requête dans Athena](athena-cloudwatch-metrics-enable.md) et [Surveillez les métriques des requêtes Athena avec CloudWatch](query-metrics-viewing.md). + **Surveillez les statistiques d'utilisation d'Athena** : découvrez comment votre compte utilise les ressources en affichant votre utilisation actuelle des services au moyen de CloudWatch graphiques et de tableaux de bord. Pour de plus amples informations, consultez [Surveillez les statistiques d'utilisation d'Athena avec CloudWatch](monitoring-athena-usage-metrics.md). + **Surveillez les événements liés aux requêtes** : utilisez Amazon EventBridge pour recevoir des notifications en temps réel concernant l'état de vos requêtes. Pour de plus amples informations, veuillez consulter [Surveillez les événements de requête Athena avec EventBridge](athena-events.md). + **Création de contrôles d’utilisation des données** : dans Athena, vous pouvez configurer des contrôles d’utilisation des données par requête et par groupe de travail. Athena annule les requêtes lorsqu’elles dépassent le seuil spécifié ou active une alarme Amazon SNS lorsque le seuil d’un groupe de travail est dépassé. Pour de plus amples informations, veuillez consulter [Configuration des contrôles d’utilisation des données par requête et par groupe de travail](workgroups-setting-control-limits-cloudwatch.md). + **Utilisation de balises de répartition des coûts** : utilisez la console de facturation et de gestion des coûts pour attribuer des balises de répartition des coûts aux groupes de travail. Les coûts associés à l’exécution de requêtes dans le groupe de travail apparaissent dans vos rapports d’utilisation et de coûts avec la balise de répartition des coûts correspondante. Pour plus d’informations, consultez [Using user-defined cost allocation tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html) dans le *Guide d’utilisation d’AWS Billing *. + **Utilisation de réserves de capacité** : vous pouvez créer des réserves de capacité avec un nombre d’unités de traitement de données spécifié et y ajouter un ou plusieurs groupes de travail. Pour de plus amples informations, veuillez consulter [Gestion de la capacité de traitement des requêtes](capacity-management.md). Pour plus d'informations sur l'utilisation des groupes de travail Athena pour séparer les charges de travail, contrôler l'accès des utilisateurs et gérer l'utilisation et les coûts des requêtes, consultez le billet de blog AWS Big Data [Séparer les requêtes et gérer les coûts à l'aide des groupes de travail Amazon Athena](https://aws.amazon.com/blogs/big-data/separating-queries-and-managing-costs-using-amazon-athena-workgroups/). **Note** Les ressources Amazon Athena sont désormais accessibles dans Amazon SageMaker Unified Studio (version préliminaire), qui vous permet d'accéder aux données de votre organisation et d'agir en conséquence avec les meilleurs outils. Vous pouvez migrer les requêtes enregistrées d'un groupe de travail Athena vers un projet SageMaker Unified Studio, configurer des projets avec des groupes de travail Athena existants et conserver les autorisations nécessaires grâce aux mises à jour des rôles IAM. Pour plus d'informations, consultez la section [Migration des ressources Amazon Athena vers SageMaker Amazon Unified Studio (](https://github.com/aws/Unified-Studio-for-Amazon-Sagemaker/tree/main/migration/athena)version préliminaire). ## Considérations et restrictions Lorsque vous utilisez des groupes de travail dans Athena, gardez à l’esprit les points suivants : + Chaque compte dispose d’un groupe de travail principal. Par défaut, si vous n'avez pas créé de groupes de travail, toutes les requêtes de votre compte s'exécutent dans le groupe de travail principal. Le groupe de travail principal ne peut pas être supprimé. Les autorisations par défaut permettent à tous les utilisateurs authentifiés d’accéder à ce groupe de travail. + Lorsque vous avez accès à un groupe de travail, vous pouvez consulter ses paramètres, ses métriques et ses limites de contrôle d'utilisation des données. Des autorisations supplémentaires vous permettent de modifier les paramètres et les limites de contrôle d'utilisation des données. + Lorsque vous exécutez des requêtes, elles s'exécutent dans le groupe de travail existant. Vous pouvez exécuter des requêtes dans le cadre d’un groupe de travail dans la console en utilisant des opérations d’API, l’interface de ligne de commande ou une application cliente via un pilote JDBC ou ODBC. + Dans l’éditeur de requête de la console Athena, vous pouvez ouvrir jusqu’à 10 onglets de requête dans chaque groupe de travail. Lorsque vous basculez entre des groupes de travail, vous pouvez conserver vos onglets de requête ouverts pour trois groupes de travail. + Vous pouvez créer jusqu'à 1 000 groupes de travail par Région AWS compte. + Les groupes de travail peuvent être désactivés. Lorsqu’un groupe de travail est désactivé, il n’est plus possible d’y exécuter des requêtes tant qu’il n’a pas été réactivé. + Athena génère un avertissement si vous tentez de supprimer un groupe de travail contenant des requêtes enregistrées. Avant de supprimer un groupe de travail auquel d’autres utilisateurs ont accès, assurez-vous que ces utilisateurs peuvent accéder à un autre groupe de travail pour exécuter des requêtes. **Topics** + [Considérations et restrictions](#workgroups-considerations-limitations) + [Créer un groupe de travail](creating-workgroups.md) + [Gestion des groupes de travail](workgroups-create-update-delete.md) + [Utiliser CloudWatch et EventBridge surveiller les requêtes](workgroups-control-limits.md) + [Utiliser le groupe de travail Athena APIs](workgroups-api-list.md) + [Résolution des problèmes liés aux groupes de travail](workgroups-troubleshooting.md) # Créer un groupe de travail Créer un groupe de travail nécessite des autorisations pour les actions d'API `CreateWorkgroup`. Consultez [Configuration de l’accès aux groupes de travail et aux balises](workgroups-access.md) et [Utilisation de politiques IAM pour contrôler l’accès aux groupes de travail.](workgroups-iam-policy.md). Si vous ajoutez des identifications, vous devez également ajouter des autorisations à `TagResource`. Consultez [Exemples de politique d'identification pour les groupes de travail](tags-access-control.md#tag-policy-examples-workgroups). La procédure suivante explique comment créer un groupe de travail à l’aide de la console Athena. Pour créer un groupe de travail à l'aide de l'API Athena, consultez. [CreateWorkGroup](https://docs.aws.amazon.com/athena/latest/APIReference/API_CreateWorkGroup.html) **Pour créer un groupe de travail dans la console Athena** 1. Définir des groupes de travail à créer. Vous pouvez notamment prendre en compte les facteurs suivants : + Qui peut exécuter des requêtes dans chaque groupe de travail, et à qui appartient la configuration du groupe de travail. Utilisez des politiques IAM pour appliquer les autorisations sur les groupes de travail. Pour de plus amples informations, veuillez consulter [Utilisation de politiques IAM pour contrôler l’accès aux groupes de travail.](workgroups-iam-policy.md). + L’emplacement Amazon S3 à utiliser pour les résultats des requêtes du groupe de travail. Tous les utilisateurs du groupe de travail doivent avoir accès à cet emplacement. + Est-il nécessaire de chiffrer résultats des requêtes du groupe de travail ? Le chiffrement étant effectué par groupe de travail (et non par requête), vous devez créer des groupes de travail distincts pour les résultats de requêtes chiffrés et non chiffrés. Pour de plus amples informations, veuillez consulter [Chiffrement des résultats de requêtes Athena stockés dans Amazon S3](encrypting-query-results-stored-in-s3.md). 1. Si le panneau de navigation de la console n'est pas visible, choisissez le menu d'extension sur la gauche. ![\[Choisissez le menu d'expansion.\]](http://docs.aws.amazon.com/fr_fr/athena/latest/ug/images/nav-pane-expansion.png) 1. Dans le panneau de navigation de la console Athena, choisissez **Workgroups** (Groupes de travail). 1. Sur la page **Workgroups** (Groupes de travail), choisissez **Create workgroup** (Créer un groupe de travail). 1. Sur la page **Create workgroup** (Créer un groupe de travail), remplissez les champs comme suit : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/athena/latest/ug/creating-workgroups.html) 1. Choisissez **Create workgroup** (Créer un groupe de travail). Le groupe de travail s'affiche sur la liste de la page **Workgroups** (Groupes de travail). Dans l’éditeur de requête, Athena affiche le groupe de travail actuel dans l’option **Groupe de travail** qui se trouve dans le coin supérieur droit de la console. Vous pouvez utiliser cette option pour passer d'un groupe de travail à un autre. Lorsque vous exécutez des requêtes, elles s'exécutent dans le groupe de travail existant. 1. Création de politiques IAM pour vos utilisateurs, groupes ou rôles afin d'activer leur accès aux groupes de travail. Les politiques établissent l'appartenance au groupe de travail et l'accès aux actions sur une ressource `workgroup`. Pour de plus amples informations, veuillez consulter [Utilisation de politiques IAM pour contrôler l’accès aux groupes de travail.](workgroups-iam-policy.md). Pour voir des exemples les politiques JSON, consultez [Configuration de l’accès aux groupes de travail et aux balises](workgroups-access.md). 1. (Facultatif) Configurez un niveau de chiffrement minimal dans Amazon S3 pour tous les résultats des requêtes du groupe de travail lorsque l’option de remplacement des paramètres côté client n’applique pas le chiffrement au niveau du groupe de travail. Vous pouvez utiliser cette fonctionnalité pour vous assurer que les résultats des requêtes ne sont jamais stockés dans un compartiment Amazon S3 à l'état non chiffré. Pour de plus amples informations, veuillez consulter [Configuration d’un chiffrement minimal pour un groupe de travail](workgroups-minimum-encryption.md). 1. (Facultatif) Utilisez Amazon CloudWatch et Amazon EventBridge pour surveiller les requêtes de votre groupe de travail et contrôler les coûts. Pour de plus amples informations, veuillez consulter [Utiliser CloudWatch et EventBridge surveiller les requêtes et contrôler les coûts](workgroups-control-limits.md). 1. (Facultatif) Utilisez la console de facturation et de gestion des coûts pour attribuer des balises de répartition des coûts aux groupes de travail. Pour plus d’informations, consultez [Using user-defined cost allocation tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html) dans le *Guide d’utilisation d’AWS Billing *. 1. (Facultatif) Pour obtenir une capacité de traitement dédiée aux requêtes du groupe de travail, ajoutez le groupe de travail à une réserve de capacité. Vous pouvez attribuer un ou plusieurs groupes de travail à une réserve. Pour de plus amples informations, veuillez consulter [Gestion de la capacité de traitement des requêtes](capacity-management.md). # Remplacer les paramètres côté client Lorsque vous créez ou modifiez un groupe de travail, vous pouvez choisir l’option **Remplacer les paramètres côté client**. Cette option n’est pas sélectionnée par défaut. En fonction de votre choix, Athena effectue les actions suivantes : + Si **Remplacer les paramètres côté client** n'est pas sélectionné, les paramètres du groupe de travail ne sont pas appliqués au niveau du client. Lorsque l'option Remplacer les paramètres côté client n'est pas sélectionnée pour le groupe de travail, Athena utilise les paramètres côté client pour toutes les requêtes exécutées dans le groupe de travail, y compris l'emplacement des résultats des requêtes, le propriétaire du compartiment attendu, le chiffrement et le contrôle des objets écrits dans le compartiment des résultats des requêtes. Chaque utilisateur peut spécifier ses propres paramètres dans le menu **Paramètres** sur la console. Si les paramètres côté client ne sont pas définis, les paramètres à l'échelle du groupe de travail s'appliquent. Si vous utilisez les AWS CLI actions d'API ou les pilotes JDBC et ODBC pour exécuter des requêtes dans un groupe de travail qui ne remplacent pas les paramètres côté client, vos requêtes utilisent les paramètres que vous spécifiez dans vos requêtes. + Si **Remplacer les paramètres côté client** est sélectionné, les paramètres du groupe de travail sont appliqués au niveau du groupe de travail pour tous les clients du groupe de travail. Lorsque l'option Remplacer les paramètres côté client est sélectionnée pour le groupe de travail, Athena utilise les paramètres du groupe de travail pour toutes les requêtes exécutées dans le groupe de travail, y compris l'emplacement des résultats des requêtes, le propriétaire du compartiment attendu, le chiffrement et le contrôle des objets écrits dans le compartiment des résultats des requêtes. Les paramètres du groupe de travail remplacent tous les paramètres côté client que vous spécifiez pour une requête lorsque vous utilisez la console, les actions d'API ou les pilotes JDBC ou ODBC. Dans ce cas, vous pouvez omettre les paramètres côté client dans les pilotes ou l’API. Si vous remplacez les paramètres côté client, la prochaine fois que vous ou un utilisateur du groupe de travail ouvrirez la console Athena, Athena vous informera que les requêtes dans le groupe de travail utilisent les paramètres du groupe de travail et vous invitera à confirmer cette modification. **Note** Étant donné que le remplacement des paramètres côté client peut perturber l’automatisation personnalisée basée sur la disponibilité des résultats dans un compartiment Amazon S3 arbitraire, il est conseillé d’informer les utilisateurs avant de procéder au remplacement. **Important** Si vous utilisez des actions d'API AWS CLI, les pilotes JDBC ou ODBC pour exécuter des requêtes dans un groupe de travail qui remplacent les paramètres côté client, veillez à omettre les paramètres côté client dans vos requêtes ou à les mettre à jour pour qu'ils correspondent aux paramètres du groupe de travail. Si vous spécifiez des paramètres côté client dans vos requêtes mais que vous les exécutez dans un groupe de travail qui remplace les paramètres, les requêtes seront exécutées mais en utilisant les paramètres du groupe de travail. Pour plus d'informations sur l'affichage des paramètres d'un groupe de travail, consultez [Afficher les détails du groupe de travail](viewing-details-workgroups.md). # Gestion des groupes de travail Dans la console Athena à l'adresse [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home), vous pouvez effectuer les tâches suivantes : | Instruction | Description | | --- | --- | | [Créer un groupe de travail](creating-workgroups.md) | Créer un nouveau groupe de travail. | | [Afficher les détails du groupe de travail](viewing-details-workgroups.md) | Affichez les détails du groupe de travail, tels que son nom, sa description, les limites d'utilisation des données, l'emplacement des résultats de la requête, le propriétaire prévu du compartiment des résultats de la requête, le chiffrement et le contrôle des objets écrits dans le compartiment des résultats de la requête. Vous pouvez également vérifier si ce groupe de travail applique ses paramètres, si Override Client-Side Setting (Remplacer les paramètres côté client) est sélectionné. | | [Spécification d’un groupe de travail pour les requêtes](specify-wkgroup-to-athena-in-which-to-run-queries.md) | Avant de pouvoir exécuter des requêtes, vous devez indiquer à Athena le groupe de travail à utiliser. Vous devez avoir les autorisations nécessaires au groupe de travail. | | [Changer de groupe de travail](switching-workgroups.md) | Basculer entre des groupes de travail auxquels vous avez accès. | | [Modifier un groupe de travail](editing-workgroups.md) | Modifier un groupe de travail et ses paramètres. Vous ne pouvez pas modifier le nom d'un groupe de travail, mais vous pouvez créer un nouveau groupe de travail avec les mêmes paramètres et un autre nom. | | [Activation ou désactivation d’un groupe de travail](workgroups-enabled-disabled.md) | Activer ou désactiver un groupe de travail. Lorsqu'un groupe de travail est désactivé, ses utilisateurs ne peuvent pas exécuter de requêtes ou créer de nouvelles requêtes nommées. Si vous y avez accès, vous pouvez toujours afficher les métriques, les contrôles de limite d'utilisation des données, les paramètres du groupe de travail, l'historique des requêtes et les requêtes enregistrées. | | [Copier une requête enregistrée entre les groupes de travail](copy-a-query-between-workgroups.md) | Copier une requête enregistrée entre les groupes de travail. Vous pouvez procéder ainsi si, par exemple, vous avez créé une requête dans un groupe de travail de prévisualisation et que vous souhaitez la rendre disponible dans un groupe de travail sans prévisualisation. | | [Supprimer un groupe de travail](deleting-workgroups.md) | Supprimer un groupe de travail. Si vous supprimez un groupe de travail, l'historique des requêtes, les requêtes enregistrées, les paramètres du groupe de travail et les contrôles de limite des données par requête sont supprimés. Les contrôles de limite de données à l'échelle du groupe de travail restent actifs CloudWatch et vous pouvez les supprimer individuellement. Le groupe de travail principal ne peut pas être supprimé. | | [Utilisation de politiques IAM pour contrôler l’accès aux groupes de travail.](workgroups-iam-policy.md) | Permet d’utiliser des politiques IAM pour contrôler l’accès des groupes de travail. Pour découvrir des exemples de politiques de groupe de travail, consultez [Exemple de politiques de groupe de travail](example-policies-workgroup.md). | | [Création d’un groupe de travail Athena qui utilise l’authentification IAM Identity Center](workgroups-identity-center.md) | Pour utiliser les identités IAM Identity Center avec Athena, vous devez créer un groupe de travail compatible avec IAM Identity Center. Après avoir créé le groupe de travail, vous pouvez utiliser la console ou l’API IAM Identity Center pour attribuer des utilisateurs ou des groupes IAM Identity Center au groupe de travail. | | [Configuration d’un chiffrement minimal pour un groupe de travail](workgroups-minimum-encryption.md) | Permet d’appliquer un niveau de chiffrement minimal dans Amazon S3 pour tous les résultats de requêtes du groupe de travail. Vous pouvez utiliser cette fonctionnalité pour vous assurer que les résultats des requêtes ne sont jamais stockés non chiffrés dans un compartiment Amazon S3. | # Afficher les détails du groupe de travail Vous pouvez afficher les détails de chaque groupe de travail. Les détails comprennent le nom du groupe de travail, sa description, le fait qu'il soit activé ou désactivé, et les paramètres utilisés pour les requêtes qui s'exécutent dans le groupe de travail, qui comprennent l'emplacement des résultats de la requête, le propriétaire attendu du compartiment, le chiffrement et le contrôle des objets écrits dans le compartiment des résultats de la requête. Si un groupe de travail a des limites d'utilisation des données, elles sont également affichées. **Pour afficher les détails du groupe de travail** 1. Dans le panneau de navigation de la console Athena, choisissez **Workgroups** (Groupes de travail). 1. Sur la page **Workgroups** (Groupes de travail), choisissez le lien du groupe de travail à consulter. La page **Overview Details** (Détails de présentation) pour le groupe de travail s'affiche. # Spécification d’un groupe de travail pour les requêtes Pour spécifier un groupe de travail à utiliser, vous devez avoir les autorisations nécessaires sur le groupe de travail. **Spécification du groupe de travail à utiliser** 1. Assurez-vous que vos autorisations vous permettent d'exécuter des requêtes dans le groupe de travail que vous prévoyez d'utiliser. Pour de plus amples informations, veuillez consulter [Utilisation de politiques IAM pour contrôler l’accès aux groupes de travail.](workgroups-iam-policy.md). 1. Pour spécifier le groupe de travail, utilisez l'une des options suivantes : + Si vous utilisez la console Athena, définissez le groupe de travail en [changeant de groupes de travail](switching-workgroups.md). + Si vous utilisez les opérations d'API Athena, spécifiez le nom du groupe de travail dans l'action d'API. Par exemple, vous pouvez définir le nom du groupe de [StartQueryExecution](https://docs.aws.amazon.com/athena/latest/APIReference/API_StartQueryExecution.html)travail comme suit : ``` StartQueryExecutionRequest startQueryExecutionRequest = new StartQueryExecutionRequest() .withQueryString(ExampleConstants.ATHENA_SAMPLE_QUERY) .withQueryExecutionContext(queryExecutionContext) .withWorkGroup(WorkgroupName) ``` + Si vous utilisez le pilote JDBC ou ODBC, définissez le nom du groupe de travail dans la chaîne de connexion à l'aide du paramètre de configuration `Workgroup`. Le pilote transmet le nom du groupe de travail à Athena. Spécifiez le paramètre du groupe de travail dans la chaîne de connexion, comme dans l'exemple suivant : ``` jdbc:awsathena://AwsRegion=;UID=; PWD=;S3OutputLocation=s3://amzn-s3-demo-bucket/-/; Workgroup=; ``` # Changer de groupe de travail Vous pouvez passer d'un groupe de travail à un autre si vous avez les autorisations pour chacun d'entre eux. Vous pouvez ouvrir jusqu'à dix onglets de requête au sein de chaque groupe de travail. Lorsque vous basculez entre des groupes de travail, vos onglets de requête restent ouverts pour un maximum de trois groupes de travail. **Changement de groupe de travail** 1. Dans la console Athena, choisissez l'option **Workgroup** (Groupe de travail) en haut à droite pour choisir un groupe de travail. 1. Si la boîte de dialogue des ***workgroup-name*paramètres du groupe de travail** apparaît, choisissez **Reconnaître.** L'option **Workgroup (Groupe de travail)** indique le nom du groupe de travail vers lequel vous avez basculé. Vous pouvez désormais exécuter des requêtes dans ce groupe de travail. # Modifier un groupe de travail Modifier un groupe de travail nécessite les autorisations requises pour les opérations d'API `UpdateWorkgroup`. Consultez [Configuration de l’accès aux groupes de travail et aux balises](workgroups-access.md) et [Utilisation de politiques IAM pour contrôler l’accès aux groupes de travail.](workgroups-iam-policy.md). Si vous ajoutez ou modifiez des identifications, vous devez également avoir des autorisations pour `TagResource`. Consultez [Exemples de politique d'identification pour les groupes de travail](tags-access-control.md#tag-policy-examples-workgroups). **Pour modifier un groupe de travail dans la console** 1. Dans le panneau de navigation de la console Athena, choisissez **Workgroups** (Groupes de travail). 1. Sur la page **Workgroups** (Groupes de travail), sélectionnez le bouton du groupe de travail à modifier. 1. Choisissez **Actions**, **Edit** (Modifier). 1. Modifiez les champs si nécessaire. Pour obtenir la liste des champs, consultez [Créer un groupe de travail](creating-workgroups.md). Vous pouvez modifier tous les champs à l'exception du nom du groupe de travail. Si vous devez modifier le nom, créez un autre groupe de travail avec le nouveau nom et les mêmes paramètres. 1. Sélectionnez **Enregistrer les modifications**. Le groupe de travail mis à jour s'affiche sur la liste de la page **Workgroups** (Groupes de travail). # Activation ou désactivation d’un groupe de travail Si vous avez les autorisations nécessaires, vous pouvez activer ou désactiver des groupes de travail dans la console, en utilisant les opérations d'API, ou les pilotes JDBC et ODBC. **Pour activer ou désactiver un groupe de travail** 1. Dans le panneau de navigation de la console Athena, choisissez **Workgroups** (Groupes de travail). 1. Sur la page **Workgroups** (Groupes de travail), choisissez le lien du groupe de travail. 1. Dans le coin supérieur droit, choisissez **Enable workgroup** (Activer le groupe de travail) ou **Disable workgroup** (Désactiver le groupe de travail). 1. Lorsque l'invite de confirmation s'affiche, choisissez **Enable** (Activer) ou **Disable** (Désactiver). Si vous désactivez un groupe de travail, ses utilisateurs ne peuvent pas y exécuter de requêtes ou y créer de nouvelles requêtes nommées. Si vous activez un groupe de travail, les utilisateurs peuvent l'utiliser pour exécuter des requêtes. # Copier une requête enregistrée entre les groupes de travail Actuellement, la console Athena ne dispose pas d'une option permettant de copier directement une requête enregistrée d'un groupe de travail à un autre, mais vous pouvez effectuer la même tâche manuellement en utilisant la procédure suivante. **Copier une requête enregistrée entre groupes de travail** 1. Dans la console Athena, depuis le groupe de travail à partir duquel vous souhaitez copier la requête, choisissez l'onglet **Saved queries** (Requêtes enregistrées). 1. Choisissez le lien de la requête enregistrée à copier. Athena ouvre la requête dans l'éditeur de requêtes. 1. Dans l'éditeur de requêtes, sélectionnez le texte de la requête, puis appuyez sur **Ctrl\$1C** pour le copier. 1. [Passez](switching-workgroups.md) au groupe de travail de destination ou [créez un groupe de travail](creating-workgroups.md), puis passez-y. 1. Ouvrez un nouvel onglet dans l'éditeur de requêtes, puis appuyez sur **Ctrl\$1V** pour coller le texte dans le nouvel onglet. 1. Dans l'éditeur de requêtes, choisissez **Save as** (Enregistrer sous) pour enregistrer la requête dans le groupe de travail de destination. 1. Dans la boîte de dialogue **Choose a name** (Choisir un nom), saisissez un nom pour la requête et une description facultative. 1. Choisissez **Enregistrer**. # Supprimer un groupe de travail Vous pouvez supprimer un groupe de travail si vous en avez l'autorisation. Le groupe de travail principal ne peut pas être supprimé. Si vous disposez des autorisations, vous pouvez supprimer un groupe de travail vide à tout moment. Vous pouvez également supprimer un groupe de travail qui contient des requêtes enregistrées. Dans ce cas, avant de procéder à la suppression d'un groupe de travail, Athena vous avertit que les requêtes enregistrées sont supprimées. Si vous supprimez un groupe de travail pendant que vous vous y trouvez, la console se concentre sur le groupe de travail principal. Si vous y avez accès, vous pouvez exécuter des requêtes et afficher ses paramètres. Si vous supprimez un groupe de travail, ses paramètres et ses contrôles de limite de données par requête sont supprimés. Les contrôles de limite de données à l'échelle du groupe de travail restent CloudWatch actifs et vous pouvez les supprimer si nécessaire. **Important** Avant de supprimer un groupe de travail, assurez-vous que ses utilisateurs ont également accès à d'autres groupes de travail dans lesquels ils peuvent continuer à exécuter des requêtes. Si les politiques IAM des utilisateurs leur permettaient d'exécuter des requêtes *uniquement* dans ce groupe de travail et que vous le supprimez, ils n'ont plus l'autorisation d'exécuter des requêtes. Pour de plus amples informations, veuillez consulter [Example policy for running queries in the primary workgroup](example-policies-workgroup.md#example4-run-in-primary-access). **Pour supprimer un groupe de travail dans la console** 1. Dans le panneau de navigation de la console Athena, choisissez **Workgroups** (Groupes de travail). 1. Sur la page **Workgroups** (Groupes de travail), sélectionnez le bouton du groupe de travail à supprimer. 1. Sélectionnez **Actions**, **Supprimer**. 1. Lorsque l'invite de confirmation **Delete workgroup** (Supprimer le groupe de travail) s'affiche, saisissez le nom du groupe de travail, puis choisissez **Delete** (Supprimer). Pour supprimer un groupe de travail avec l'opération d'API, utilisez l'action `DeleteWorkGroup`. # Utiliser CloudWatch et EventBridge surveiller les requêtes et contrôler les coûts Les groupes de travail vous permettent de définir des limites pour le contrôle d'utilisation des données par requête ou par groupe de travail, de configurer des alarmes en cas de dépassement de ces limites et de publier des métriques de requête dans CloudWatch. Dans chaque groupe de travail, vous pouvez : + Configurer des **Data usage controls** (Contrôles d'utilisation des données) par requête et par groupe de travail, et mettre en place des actions si les requêtes dépassent les seuils. + Affichez et analysez les métriques des requêtes, puis publiez-les sur CloudWatch. Si vous créez un groupe de travail dans la console, le paramètre de publication des métriques CloudWatch est sélectionné pour vous. Si vous utilisez les opérations d'API, vous devez [activer la publication des métriques](athena-cloudwatch-metrics-enable.md). Une fois les métriques publiées, elles s'affichent dans l'onglet **Metrics** (Métriques) du panneau **Workgroups** (Groupes de travail). Les métriques sont désactivées par défaut pour le groupe de travail principal. ## Vidéo La vidéo suivante montre comment créer des tableaux de bord personnalisés et définir des alarmes et des déclencheurs sur les métriques dans CloudWatch. Vous pouvez utiliser des tableaux de bord préremplis directement à partir de la console Athena pour utiliser ces métriques de requête. [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/x1V_lhkdKCg/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/x1V_lhkdKCg) **Topics** + [Vidéo](#athena-cloudwatch-metrics-video) + [Activation des métriques de requêtes](athena-cloudwatch-metrics-enable.md) + [Surveillez les métriques des requêtes avec CloudWatch](query-metrics-viewing.md) + [Surveillez les statistiques d'utilisation avec CloudWatch](monitoring-athena-usage-metrics.md) + [Surveillez les événements liés aux requêtes avec EventBridge](athena-events.md) + [Configuration des contrôles d’utilisation des données](workgroups-setting-control-limits-cloudwatch.md) # Activer les métriques de CloudWatch requête dans Athena Lorsque vous créez un groupe de travail dans la console, le paramètre de publication des métriques de requête vers CloudWatch est sélectionné par défaut. **Activation ou désactivation des métriques de requête dans la console Athena pour un groupe de travail** 1. Ouvrez la console à l'adresse [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Si le panneau de navigation de la console n'est pas visible, choisissez le menu d'extension sur la gauche. ![\[Choisissez le menu d'expansion.\]](http://docs.aws.amazon.com/fr_fr/athena/latest/ug/images/nav-pane-expansion.png) 1. Dans le panneau de navigation, choisissez **Workgroups** (Groupes de travail). 1. Choisissez le lien du groupe de travail à modifier. 1. Sur la page des détails du groupe de travail, choisissez **Edit** (Modifier). 1. Dans la section **Paramètres**, sélectionnez ou désactivez **Publier les métriques de requête sur AWS CloudWatch**. Si vous utilisez les opérations d'API, l'interface de ligne de commande ou l'application client avec le pilote JDBC pour créer des groupes de travail, afin de permettre la publication des métriques de requête, définissez `PublishCloudWatchMetricsEnabled` ce paramètre sur in. `true` [WorkGroupConfiguration](https://docs.aws.amazon.com/athena/latest/APIReference/API_WorkGroupConfiguration.html) L'exemple suivant illustre uniquement la configuration des métriques et fait abstraction de toute autre configuration : ``` "WorkGroupConfiguration": { "PublishCloudWatchMetricsEnabled": "true" .... } ``` # Surveillez les métriques des requêtes Athena avec CloudWatch Athena publie les métriques relatives aux requêtes sur Amazon CloudWatch, lorsque l'option [Publier les métriques de requête sur](athena-cloudwatch-metrics-enable.md) est sélectionnée. CloudWatch Vous pouvez créer des tableaux de bord personnalisés, définir des alarmes et des déclencheurs sur les métriques ou utiliser des tableaux de bord préremplis directement depuis la console Athena. CloudWatch Lorsque vous activez des métriques de requête pour des requêtes dans les groupes de travail, les métriques sont affichées dans l'onglet **Metrics** (Métriques) du panneau **Workgroups** (Groupes de travail) pour chaque groupe de travail de la console Athena. Athena publie les métriques suivantes sur la CloudWatch console : + `DPUAllocated`— Le nombre total DPUs (d'unités de traitement des données) prévues dans une réservation de capacité pour exécuter des requêtes. + `DPUConsumed`— Le nombre de requêtes DPUs activement consommées par un `RUNNING` État à un moment donné dans une réservation. Métrique émise uniquement lorsque le groupe de travail est associé à une réserve de capacité et inclut tous les groupes de travail associés à une réserve. + `DPUCount`— Le nombre maximum de données DPUs consommées par votre requête, publié une seule fois à la fin de la requête. + `EngineExecutionTime` : le nombre de millisecondes nécessaires à l'exécution de la requête. + `ProcessedBytes` : le nombre d'octets qu'Athena a analysé par requête DML. + `QueryPlanningTime` : le nombre de millisecondes nécessaires à Athena pour planifier le flux de traitement des requêtes. + `QueryQueueTime` : le nombre de millisecondes pendant lesquelles la requête est restée dans la file d'attente des ressources. + `ServicePreProcessingTime` : le nombre de millisecondes nécessaires à Athena pour prétraiter la requête avant de la soumettre au moteur de requête. + `ServiceProcessingTime` : le nombre de millisecondes nécessaires à Athena pour traiter les résultats de la requête après que le moteur de requête ait fini d'exécuter la requête. + `TotalExecutionTime` : le nombre de millisecondes nécessaires à Athena pour exécuter une requête DDL ou DML. Pour des descriptions plus complètes, veuillez consulter les rubriques [Liste des CloudWatch métriques et des dimensions d'Athena](#athena-cloudwatch-metrics-table) plus avant dans le présent document. Ces métriques ont les dimensions suivantes : + `CapacityReservation` : le nom de la réserve de capacité utilisée pour exécuter la requête, le cas échéant. + `QueryState` : `SUCCEEDED`, `FAILED` ou `CANCELED` + `QueryType` : `DML`, `DDL` ou `UTILITY` + `WorkGroup` – nom du groupe de travail Athena publie la métrique suivante sur la CloudWatch console sous l'espace de `AmazonAthenaForApacheSpark` noms : + `DPUCount`— nombre de personnes DPUs consommées pendant la session pour exécuter les calculs. Cette métrique a les dimensions suivantes : + `SessionId` – L'ID de la session dans laquelle les calculs sont soumis. + `WorkGroup` – nom du groupe de travail. Pour de plus amples informations, veuillez consulter [Liste des CloudWatch métriques et des dimensions d'Athena](#athena-cloudwatch-metrics-table) plus loin dans cette rubrique. Pour plus d'informations sur les métriques d'utilisation d'Athena, veuillez consulter [Surveillez les statistiques d'utilisation d'Athena avec CloudWatch](monitoring-athena-usage-metrics.md). Vous pouvez consulter les métriques des requêtes dans la console Athena ou dans la CloudWatch console. ## Affichage des métriques de requêtes dans la console Athena **Pour afficher les métriques de requêtes d’un groupe de travail dans la console Athena** 1. Ouvrez la console à l'adresse [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Si le panneau de navigation de la console n'est pas visible, choisissez le menu d'extension sur la gauche. ![\[Choisissez le menu d'expansion.\]](http://docs.aws.amazon.com/fr_fr/athena/latest/ug/images/nav-pane-expansion.png) 1. Dans le panneau de navigation, choisissez **Workgroups** (Groupes de travail). 1. Choisissez le groupe de travail souhaité dans la liste, puis choisissez l'onglet **Metrics** (Métriques). Le tableau de bord des métriques s'affiche. **Note** Si vous venez d'activer les métriques pour le groupe de travail and/or , aucune activité de requête récente n'a été effectuée, les graphiques du tableau de bord sont peut-être vides. L'activité de requête est extraite CloudWatch en fonction de l'intervalle que vous spécifiez à l'étape suivante. 1. Dans la section **Metrics**, choisissez l'intervalle de métriques qu'Athena doit utiliser pour récupérer les métriques de requête CloudWatch, ou spécifiez un intervalle personnalisé. ![\[Spécification de l'intervalle de récupération des métriques pour un groupe de travail dans la console Athena.\]](http://docs.aws.amazon.com/fr_fr/athena/latest/ug/images/wg-custom-interval.png) 1. Pour actualiser les métriques affichées, choisissez l'icône Actualiser. ![\[Choisissez l'icône d'actualisation.\]](http://docs.aws.amazon.com/fr_fr/athena/latest/ug/images/wg-refresh-metrics.png) 1. Cliquez sur la flèche à côté de l'icône d'actualisation pour choisir la fréquence à laquelle vous souhaitez que l'affichage des métriques soit mis à jour. ![\[Choix d'un intervalle de rafraîchissement pour l'affichage des métriques du groupe de travail dans la console Athena.\]](http://docs.aws.amazon.com/fr_fr/athena/latest/ug/images/wg-choose-refresh-interval.png) ## Afficher les métriques des requêtes dans la CloudWatch console **Pour consulter les statistiques dans la CloudWatch console Amazon** 1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). 1. Dans le panneau de navigation, sélectionnez **Métriques**, **Toutes les métriques**. 1. Sélectionnez l'espace de nom **AWS/Athena**. ## Affichez les métriques des requêtes à l'aide du AWS CLI **Pour consulter les statistiques à l'aide du AWS CLI** + Effectuez l’une des actions suivantes : + Pour répertorier les métriques d'Athena, ouvrez une invite de commandes et utilisez la commande suivante : ``` aws cloudwatch list-metrics --namespace "AWS/Athena" ``` + Pour répertorier toutes les métriques disponibles, utilisez la commande suivante : ``` aws cloudwatch list-metrics" ``` ## Liste des CloudWatch métriques et des dimensions d'Athena Si vous avez activé CloudWatch les métriques dans Athena, celle-ci envoie les métriques suivantes à CloudWatch chaque groupe de travail. Les métriques suivantes utilisent l'espace de noms `AWS/Athena`. | Nom des métriques | Description | | --- | --- | | DPUAllocated | Nombre total DPUs (d'unités de traitement des données) allouées dans le cadre d'une réservation de capacité pour exécuter des requêtes. | | DPUConsumed | Le nombre de requêtes DPUs activement consommées par un RUNNING État à un moment donné dans une réservation. Cette métrique n'est émise que lorsque le groupe de travail est associé à une réserve de capacité et inclut tous les groupes de travail associés à une réserve. Par conséquent, si vous déplacez un groupe de travail d'une réserve à une autre, la métrique inclut les données de la période pendant laquelle le groupe de travail appartenait à la première réserve. Pour plus d'informations sur les réserves de capacité, veuillez consulter [Gestion de la capacité de traitement des requêtes](capacity-management.md). | | DPUCount | Le nombre maximum de données DPUs consommées par votre requête, publié une seule fois à la fin de la requête. Cette métrique n'est émise que pour les groupes de travail associés à une réserve de capacité. | | EngineExecutionTime | Le nombre de millisecondes nécessaires à l'exécution de la requête. | | ProcessedBytes | Le nombre d'octets qu'Athena a analysé par requête DML. Pour les requêtes qui ont été annulées (soit par les utilisateurs, soit automatiquement, si la limite a été atteinte), cela inclut la quantité de données analysées avant l'heure de l'annulation. Cette métrique n'est pas signalée pour les requêtes DDL. | | QueryPlanningTime | Le nombre de millisecondes nécessaires à Athena pour planifier le flux de traitement des requêtes. Cela inclut le temps passé à récupérer les partitions de la table à partir de la source de données, Notez que, dans la mesure où le moteur de requêtes effectue la planification des requêtes, le temps de planification des requêtes est un sous-ensemble de EngineExecutionTime. | | QueryQueueTime | Le nombre de millisecondes pendant lesquelles la requête est restée dans la file d'attente des ressources. Notez que si des erreurs transitoires se produisent, la requête peut être automatiquement replacée dans la file d'attente. | | ServicePreProcessingTime | Le nombre de millisecondes nécessaires à Athena pour prétraiter la requête avant de la soumettre au moteur de requête. | | ServiceProcessingTime | Le nombre de millisecondes nécessaires à Athena pour traiter les résultats de la requête après que le moteur de requête ait fini d'exécuter la requête. | | TotalExecutionTime | Le nombre de millisecondes nécessaires à Athena pour exécuter une requête DDL ou DML. TotalExecutionTime inclut QueryQueueTime QueryPlanningTime, EngineExecutionTime, et ServiceProcessingTime. | Ces métriques pour Athena ont les dimensions suivantes. | Dimension | Description | | --- | --- | | CapacityReservation | Le nom de la réserve de capacité qui a été utilisée pour exécuter la requête, le cas échéant. Lorsqu'aucune réserve de capacité n'est utilisée, cette dimension ne renvoie aucune donnée. | | QueryState | L'état de la requête. Statistiques valides : SUCCEEDED (réussite), FAILED (échec) ou CANCELED (annulé). | | QueryType | Le type de requête. Statistiques valides : `DDL`, `DML` ou `UTILITY`. Type d'instruction de requête exécutée. `DDL` indique les instructions de requête DDL (Data Definition Language). `DML` indique les instructions de requête DML (Data Manipulation Language), telles que `CREATE TABLE AS SELECT`. `UTILITY` indique des instructions de requête autres que DDL et DML, telles que `SHOW CREATE TABLE` ou `DESCRIBE TABLE`. | | WorkGroup | Le nom du groupe de travail. | # Surveillez les statistiques d'utilisation d'Athena avec CloudWatch Vous pouvez utiliser les statistiques CloudWatch d'utilisation pour avoir une idée de la manière dont votre compte utilise les ressources en affichant votre utilisation actuelle des services sur CloudWatch des graphiques et des tableaux de bord. Pour Athena, les mesures de disponibilité d'utilisation correspondent aux Service AWS quotas pour Athena. Vous pouvez configurer des alarmes qui vous alertent lorsque votre utilisation approche d’un quota de service. Pour de plus amples informations sur les quotas de service Athena, consultez [Service Quotas](service-limits.md). Pour plus d'informations sur les statistiques AWS d'utilisation, consultez les [statistiques AWS d'utilisation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Service-Quota-Integration.html) dans le *guide de CloudWatch l'utilisateur Amazon*. Athena publie les métriques suivantes dans l'espace de noms `AWS/Usage`. | Nom des métriques | Description | | --- | --- | | `ResourceCount` | Somme de toutes les requêtes en file d'attente et en cours d'exécution Région AWS par compte, séparées par type de requête (DML ou DDL). La valeur maximale est la seule statistique utile pour cette métrique. Cette métrique est publiée périodiquement toutes les minutes. Si vous n'exécutez aucune requête, la métrique ne signale rien (même pas 0). La métrique est publiée uniquement si des requêtes actives sont en cours d'exécution au moment de la prise de la mesure. | Les dimensions suivantes permettent d'affiner les métriques d'utilisation publiées par Athena. | Dimension | Description | | --- | --- | | `Service` | Le nom du Service AWS conteneur de la ressource. Pour Athena, la valeur de cette dimension est au format `Athena`. | | `Resource` | Type de ressource en cours d’exécution. La valeur de ressource pour l'utilisation de la requête Athena est `ActiveQueryCount`. | | `Type` | Type d'entité faisant l'objet d'un rapport. Actuellement, la seule valeur valide pour les métriques d'utilisation d'Athena est `Resource`. | | `Class` | Classe de ressource suivie. Pour Athena, `Class` peut être `DML` ou `DDL`. | ## Afficher les statistiques d'utilisation des ressources Athena dans la console CloudWatch Vous pouvez utiliser la CloudWatch console pour consulter un graphique des indicateurs d'utilisation d'Athena et configurer des alarmes qui vous alertent lorsque votre utilisation approche un quota de service. **Pour afficher les mesures d'utilisation des ressources Athena** 1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). 1. Dans le panneau de navigation, sélectionnez **Métriques**, **Toutes les métriques**. 1. Choisissez **Utilisation**, puis **Par ressource AWS **. La liste des métriques d'utilisation des Service Quotas s'affiche. 1. Cochez la case située à côté d'**Athéna** et. **ActiveQueryCount** 1. Sélectionnez l'onglet **Graphed metrics (Graphiques des métriques)**. Le graphique ci-dessus montre votre utilisation actuelle de la AWS ressource. Pour plus d'informations sur l'ajout de quotas de service au graphique et sur le paramétrage d'une alarme qui vous avertira si vous approchez du quota de service, consultez [Visualisation de vos quotas de service et définition d'alarmes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Quotas-Visualize-Alarms.html) dans le guide de * CloudWatch l'utilisateur Amazon*. Pour plus d'informations sur la définition de limites d'utilisation par groupe de travail, consultez [Configuration des contrôles d’utilisation des données par requête et par groupe de travail](workgroups-setting-control-limits-cloudwatch.md). # Surveillez les événements de requête Athena avec EventBridge Vous pouvez utiliser Amazon Athena avec Amazon EventBridge pour recevoir des notifications en temps réel concernant l'état de vos requêtes. Lorsqu'une requête à laquelle vous avez soumis des états de transition, Athena publie un événement EventBridge contenant des informations sur cette transition d'état de requête. Vous pouvez écrire des règles simples pour les événements qui vous intéressent et effectuer des actions automatisées lorsqu'un événement correspond à une règle. Par exemple, vous pouvez créer une règle qui invoque une AWS Lambda fonction lorsqu'une requête atteint un état terminal. Les événements sont générés dans la mesure du possible. Avant de créer des règles d'événement pour Athena, vous devez procéder comme suit : + Familiarisez-vous avec les événements, les règles et les cibles dans EventBridge. Pour plus d'informations, consultez [Qu'est-ce qu'Amazon EventBridge ?](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) Pour plus d'informations sur la configuration des règles, consultez [Getting started with Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html). + Créez la ou les cible(s) à utiliser dans vos règles d'événement. **Note** Athena propose actuellement un type d'événement appelé événement de changement d'état de requête Athena, mais peut ajouter d'autres types et détails d'événement. Si vous désérialisez par programmation les données JSON d'événement, veillez à ce que votre application soit prête à traiter des propriétés inconnues si ces propriétés supplémentaires sont ajoutées. ## Format des événements Athena Voici le modèle de base d'un événement Amazon Athena. ``` { "source":[ "aws.athena" ], "detail-type":[ "Athena Query State Change" ], "detail":{ "currentState":[ "SUCCEEDED" ] } } ``` ## Événement de changement d'état de requête Athena L'exemple suivant montre un événement de changement d'état de requête Athena dont la valeur `currentState` est `SUCCEEDED`. ``` { "version":"0", "id":"abcdef00-1234-5678-9abc-def012345678", "detail-type":"Athena Query State Change", "source":"aws.athena", "account":"123456789012", "time":"2019-10-06T09:30:10Z", "region":"us-east-1", "resources":[ ], "detail":{ "versionId":"0", "currentState":"SUCCEEDED", "previousState":"RUNNING", "statementType":"DDL", "queryExecutionId":"01234567-0123-0123-0123-012345678901", "workgroupName":"primary", "sequenceNumber":"3" } } ``` L'exemple suivant montre un événement de changement d'état de requête Athena dont la valeur `currentState` est `FAILED`. Le bloc `athenaError` apparaît uniquement lorsque `currentState` est `FAILED`. Pour plus d'informations sur les valeurs de `errorCategory` et `errorType`, voir [Catalogue d'erreurs Athena](error-reference.md). ``` { "version":"0", "id":"abcdef00-1234-5678-9abc-def012345678", "detail-type":"Athena Query State Change", "source":"aws.athena", "account":"123456789012", "time":"2019-10-06T09:30:10Z", "region":"us-east-1", "resources":[ ], "detail":{ "athenaError": { "errorCategory": 2.0, //Value depends on nature of exception "errorType": 1306.0, //Type depends on nature of exception "errorMessage": "Amazon S3 bucket not found", //Message depends on nature of exception "retryable":false //Retryable value depends on nature of exception }, "versionId":"0", "currentState": "FAILED", "previousState": "RUNNING", "statementType":"DML", "queryExecutionId":"01234567-0123-0123-0123-012345678901", "workgroupName":"primary", "sequenceNumber":"3" } } ``` ### Propriétés de sortie La sortie JSON inclut les propriétés suivantes. **** | Propriété | Description | | --- | --- | | athenaError | Apparaît uniquement lorsque currentState est FAILED. Contient des informations sur l'erreur qui s'est produite, notamment la catégorie d'erreur, le type d'erreur, le message d'erreur et la possibilité de réessayer l'action qui a conduit à l'erreur. Les valeurs de chacun de ces champs dépendent de la nature de l'erreur. Pour plus d'informations sur les valeurs de errorCategory et errorType, voir [Catalogue d'erreurs Athena](error-reference.md). | | versionId | Numéro de version du schéma de l'objet détaillé. | | currentState | État dans lequel la requête a été placée au moment de l'événement. | | previousState | État initial de la requête au moment de l'événement. | | statementType | Type d'instruction de requête exécutée. | | queryExecutionId | Identifiant unique de la requête exécutée. | | workgroupName | Nom du groupe de travail dans lequel la requête a été exécutée. | | sequenceNumber | Nombre croissant de façon monotone qui permet de dédupliquer et d'ordonner les événements entrants qui impliquent une seule requête exécutée. Lorsque des événements dupliqués sont publiés pour le même changement d'état, la valeur sequenceNumber est la même. Lorsqu'une requête subit plusieurs changements d'état, par exemple des requêtes faisant l'objet d'un rare remplacement en file d'attente, vous pouvez utiliser sequenceNumber pour ordonner des événements avec des valeurs currentState et previousState identiques. | ## Exemple L'exemple suivant publie des événements dans une rubrique Amazon SNS à laquelle vous êtes abonné. Lorsque Athena est interrogé, vous recevez un e-mail. L'exemple suppose que la rubrique Amazon SNS existe et que vous y êtes abonné. **Publication des événements Athena dans une rubrique Amazon SNS** 1. Créez la cible pour votre rubrique Amazon SNS. `events.amazonaws.com`Autorisez le EventBridge responsable du service des événements à publier sur votre rubrique Amazon SNS, comme dans l'exemple suivant. ``` { "Effect":"Allow", "Principal":{ "Service":"events.amazonaws.com" }, "Action":"sns:Publish", "Resource":"arn:aws:sns:us-east-1:111111111111:your-sns-topic" } ``` 1. Utilisez la AWS CLI `events put-rule` commande pour créer une règle pour les événements Athena, comme dans l'exemple suivant. ``` aws events put-rule --name {ruleName} --event-pattern '{"source": ["aws.athena"]}' ``` 1. Utilisez la AWS CLI `events put-targets` commande pour associer la cible de la rubrique Amazon SNS à la règle, comme dans l'exemple suivant. ``` aws events put-targets --rule {ruleName} --targets Id=1,Arn=arn:aws:sns:us-east-1:111111111111:your-sns-topic ``` 1. Interrogez Athena et observez la cible invoquée. Vous devriez recevoir les e-mails correspondants à partir de la rubrique Amazon SNS. ## Utilisation Notifications des utilisateurs AWS avec Amazon Athena Vous pouvez utiliser [Notifications des utilisateurs AWS](https://docs.aws.amazon.com/notifications/latest/userguide/what-is.html) pour configurer des canaux de diffusion afin d’être averti des événements Amazon Athena. Vous recevez une notification lorsqu'un événement correspond à une règle que vous avez spécifiée. Vous pouvez recevoir des notifications relatives à des événements via plusieurs canaux, notamment par email, via des notifications de chat [Amazon Q Developer dans les applications de chat](https://docs.aws.amazon.com/chatbot/latest/adminguide/what-is.html) ou via des notifications push de l’[AWS Console Mobile Application](https://docs.aws.amazon.com/consolemobileapp/latest/userguide/what-is-consolemobileapp.html). Vous pouvez également consulter les notifications dans le [centre de notifications de la console](https://console.aws.amazon.com/notifications/). Notifications des utilisateurs prend en charge l'agrégation, ce qui peut réduire le nombre de notifications que vous recevez lors d'événements spécifiques. Pour plus d’informations, consultez le [Guide de l’utilisateur *Notifications des utilisateurs AWS *](https://docs.aws.amazon.com/notifications/latest/userguide/what-is.html). # Configuration des contrôles d’utilisation des données par requête et par groupe de travail Athena vous permet de définir deux types de contrôles des coûts : la limite par requête et la limite par groupe de travail. Pour chaque groupe de travail, vous pouvez définir une seule limite par requête et plusieurs limites par groupe de travail. + La **limite pour le contrôle par requête** spécifie le volume total de données analysées par requête. Si une requête s'exécutant dans le groupe de travail dépasse la limite, elle est annulée. Vous pouvez créer une seule limite pour le contrôle par requête dans un groupe de travail qui s'applique à chaque requête exécutée dans ce dernier. Modifiez la limite si nécessaire. Pour obtenir des informations plus détaillées, consultez [Pour créer un contrôle d'utilisation des données par requête](#configure-control-limit-per-query). + La **limite pour le contrôle d'utilisation des données à l'échelle du groupe de travail** spécifie le volume total de données analysées pour toutes les requêtes s'exécutant dans ce groupe de travail au cours de la période spécifiée. Vous pouvez créer plusieurs limites par groupe de travail. La limite de requêtes à l'échelle du groupe de travail vous permet de définir plusieurs seuils sur des volumes horaires ou quotidiens de données analysées par des requêtes s'exécutant dans le groupe de travail. Si la quantité globale de données analysées dépasse le seuil, vous pouvez envoyer une notification à une rubrique Amazon SNS. Configurez une alarme Amazon SNS et une action dans la console Athena pour informer un administrateur en cas d'utilisation hors limites. Pour obtenir des informations plus détaillées, consultez [Pour créer un contrôle d'utilisation des données par groupe de travail](#configure-control-limit-per-workgroup). Vous pouvez également créer une alarme et une action sur n'importe quelle métrique publiée par Athena depuis la CloudWatch console. Par exemple, vous pouvez définir une alerte sur plusieurs requêtes en échec. Cette alerte peut déclencher l'envoi d'un e-mail à un administrateur si le nombre dépasse un certain seuil. En cas de dépassement de la limite, une action envoie une notification d'alarme Amazon SNS aux utilisateurs spécifiés. Autres actions que vous pouvez effectuer : + Invoque une fonction Lambda. Pour plus d'informations, consultez [Invocation des fonctions Lambda en utilisant des notifications Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda-as-subscriber.html) dans le *Guide du développeur Amazon Simple Notification Service*. + Désactivation du groupe de travail pour arrêter l'exécution d'autres requêtes. Pour les étapes, consultez [Activation ou désactivation d’un groupe de travail](workgroups-enabled-disabled.md). Les limites par requête et par groupe de travail sont indépendantes les unes des autres. Une action spécifiée est exécutée à chaque dépassement de l'une des limites. Si deux ou plusieurs utilisateurs exécutent des requêtes au même moment dans le même groupe de travail, il est possible que chacune des requêtes ne dépasse pas les limites spécifiées, mais que le volume total de données analysées dépasse la limite d'utilisation des données par groupe de travail. Dans ce cas, une alarme Amazon SNS est envoyée à l'utilisateur. ## Création d’un contrôle d’utilisation des données par requête **Pour créer un contrôle d’utilisation des données par requête** La limite pour le contrôle par requête spécifie le volume total de données analysées par requête. Si une requête s'exécutant dans le groupe de travail dépasse la limite, elle est annulée. Les requêtes annulées sont facturées conformément à la [Tarification Amazon Athena](https://aws.amazon.com/athena/pricing/). **Note** Dans le cas de requêtes annulées ou échouées, il est possible qu'Athena ait déjà écrit des résultats partiels sur Simple Storage Service (Amazon S3). Dans ce cas, Athena ne supprime pas les résultats partiels du préfixe Simple Storage Service (Amazon S3) où sont stockés les résultats. Vous devez supprimer le préfixe Simple Storage Service (Amazon S3) avec des résultats partiels. Athena utilise les téléchargements partitionnés Simple Storage Service (Amazon S3) pour écrire des données Simple Storage Service (Amazon S3). Nous vous recommandons de définir la politique du cycle de vie du compartiment pour interrompre les chargements partitionnés en cas d'échec des requêtes. Pour de plus amples informations, consultez la section [Utilisation d'une politique de cycle de vie des compartiments pour l'interruption des chargements partitionnés inachevés](https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html#mpu-abort-incomplete-mpu-lifecycle-config) dans le *Guide de l'utilisateur Amazon Simple Storage Service*. Dans certaines conditions, Athena peut tenter automatiquement de réexécuter des requêtes. Dans la plupart des cas, ces requêtes s’exécutent normalement et présentent l’ID `Completed`. Elles peuvent produire des résultats partiels lors des premières tentatives et générer des chargements partitionnés incomplets. Vous pouvez créer une seule limite pour le contrôle par requête dans un groupe de travail qui s'applique à chaque requête exécutée dans ce dernier. Modifiez la limite si nécessaire. 1. Ouvrez la console à l'adresse [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Dans le panneau de navigation, choisissez **Groupes de travail**. 1. Choisissez le nom du groupe de travail dans la liste. 1. Dans l'onglet **Contrôles d'exécution**, choisissez **Modifier les contrôles**. 1. Modifiez la valeur de la **limite de données numérisées**. + Spécifiez une valeur comprise entre 10 Mo (minimum) et 7 EB (maximum). + Sélectionnez une valeur unitaire dans la liste déroulante (par exemple, **Kilo-octets KB ou **Exaoctets**** EB). **Note** L'action par défaut consiste à annuler la requête si elle dépasse la limite. Ce paramètre ne peut pas être modifié. 1. Choisissez **Enregistrer** pour appliquer immédiatement vos modifications. ## Création ou modification d’une alerte d’utilisation des données par groupe de travail **Pour créer une alerte d'utilisation des données par groupe de travail** Vous pouvez définir plusieurs seuils d'alerte lorsque des requêtes exécutées dans un groupe de travail analysent une quantité de données spécifiée au cours d'une période donnée. Les alertes sont mises en œuvre à l'aide des CloudWatch alarmes Amazon et s'appliquent à toutes les requêtes du groupe de travail. Lorsqu'un seuil est atteint, Amazon SNS peut envoyer un e-mail aux utilisateurs que vous spécifiez. Les requêtes ne sont pas automatiquement annulées lorsqu'un seuil est atteint. 1. Ouvrez la console à l'adresse [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Si le panneau de navigation de la console n'est pas visible, choisissez le menu d'extension sur la gauche. 1. Dans le panneau de navigation, choisissez **Groupes de travail**. 1. Choisissez le nom du groupe de travail dans la liste. 1. Choisissez **Edit** (Modifier) pour modifier les paramètres du groupe de travail. 1. Faites défiler l'écran jusqu'à et développer **Workgroup data usage alerts – optional** (Alertes d'utilisation des données de groupe de travail – facultatif). 1. Choisissez **Add alert** (Ajouter une alerte). 1. Pour **Data usage threshold configuration** (Configuration du seuil d'utilisation des données), spécifiez les valeurs comme suit : + Pour **Data threshold** (Seuil de données), spécifiez un nombre, puis sélectionnez une valeur unitaire dans la liste déroulante. + Pour **Time period** (Période), choisissez une période dans la liste déroulante. + Pour **SNS topic selection** (Sélection des rubriques SNS), choisissez une rubrique Amazon SNS dans la liste déroulante. Vous pouvez aussi choisir **Create SNS topic** (Créer une rubrique SNS) pour accéder directement à la [Console Amazon SNS](https://console.aws.amazon.com/sns/v2/home), créer la rubrique Amazon SNS et configurer un abonnement pour l'un des utilisateurs de votre compte Athena. Pour plus d'informations, consultez [Prise en main d'Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html) dans le *Guide du développeur Amazon Simple Notification Service*. 1. Choisissez **Add alert** (Ajouter une alerte) si vous créez une alerte, ou **Save** (Enregistrer) pour enregistrer une alerte existante. # Utiliser le groupe de travail Athena APIs Voici quelques-unes des opérations d'API REST utilisées pour les groupes de travail Athena. Dans toutes les opérations suivantes à l'exception de `ListWorkGroups`, vous devez spécifier un groupe de travail. Dans d'autres opérations, par exemple `StartQueryExecution`, le paramètre du groupe de travail est facultatif et les opérations ne sont pas répertoriées ici. Pour la liste complète des opérations, consultez la [Référence API Amazon Athena](https://docs.aws.amazon.com/athena/latest/APIReference/). + [CreateWorkGroup](https://docs.aws.amazon.com/athena/latest/APIReference/API_CreateWorkGroup.html) + [DeleteWorkGroup](https://docs.aws.amazon.com/athena/latest/APIReference/API_DeleteWorkGroup.html) + [GetWorkGroup](https://docs.aws.amazon.com/athena/latest/APIReference/API_GetWorkGroup.html) + [ListWorkGroups](https://docs.aws.amazon.com/athena/latest/APIReference/API_ListWorkGroups.html) + [UpdateWorkGroup](https://docs.aws.amazon.com/athena/latest/APIReference/API_UpdateWorkGroup.html) # Correction des erreurs liées aux groupes de travail Utilisez les conseils suivants pour dépanner des groupes de travail. + Vérifiez les autorisations pour chaque utilisateur dans votre compte. Ils doivent avoir accès à l'emplacement pour les résultats des requêtes et au groupe de travail dans lequel ils souhaitent exécuter des requêtes. S'ils veulent changer de groupes de travail, ils ont également besoin d'autorisations pour les deux groupes de travail. Pour plus d'informations, consultez [Utilisation de politiques IAM pour contrôler l’accès aux groupes de travail.](workgroups-iam-policy.md). + Faites attention au contexte dans la console Athena, pour voir dans quel groupe de travail vous allez exécuter les requêtes. Si vous utilisez le pilote, assurez-vous de définir le groupe de travail comme celui dont vous avez besoin. Pour plus d'informations, consultez [Spécification d’un groupe de travail pour les requêtes](specify-wkgroup-to-athena-in-which-to-run-queries.md). + Si vous utilisez l'API ou les pilotes pour exécuter des requêtes, vous devez spécifier l'emplacement des résultats de la requête de l'une des manières suivantes : pour les requêtes individuelles, utilisez [OutputLocation](https://docs.aws.amazon.com/athena/latest/APIReference/API_ResultConfiguration.html#athena-Type-ResultConfiguration-OutputLocation)(côté client). Dans le groupe de travail, utilisez [WorkGroupConfiguration](https://docs.aws.amazon.com/athena/latest/APIReference/API_WorkGroupConfiguration.html). Si l'emplacement n'est pas spécifié de l'une ou l'autre manière, Athena génère une erreur au moment de l'exécution de la requête. + Si vous remplacez les paramètres côté client avec les paramètres du groupe de travail, vous pouvez rencontrer des erreurs avec l'emplacement de vos résultats de requête. Par exemple, il est possible que l'utilisateur d'un groupe de travail n'ait pas l'autorisation d'accéder à l'emplacement du groupe de travail dans Simple Storage Service (Amazon S3) pour stocker les résultats des requêtes. Dans ce cas, ajoutez les autorisations nécessaires. + Les groupes de travail présentent des changements dans le comportement des opérations d'API. Les appels aux opérations API existantes suivantes nécessitent que les utilisateurs de votre compte aient des autorisations basées sur les ressources dans IAM pour les groupes de travail dans lesquels ils effectuent ces appels. S'il n'existe aucune autorisation d'accès au groupe de travail et aux actions de groupe de travail, les actions d'API suivantes génèrent `AccessDeniedException` : **CreateNamedQuery**DeleteNamedQuery**GetNamedQuery******, **ListNamedQueries**, **StartQueryExecution**,, **StopQueryExecution**, **ListQueryExecutions**GetQueryExecution**GetQueryResults******, et **GetQueryResultsStream**(cette action d'API n'est disponible que pour une utilisation avec le pilote et n'est pas exposée autrement à un usage public). Pour plus d'informations, consultez la rubrique [Actions, ressources et clés de condition pour Amazon Athena](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonathena.html) dans la section *Référence de l'autorisation de service*. Les appels aux opérations d'**BatchGetNamedQuery**API **BatchGetQueryExecution**et d'API renvoient des informations uniquement sur les requêtes exécutées dans des groupes de travail auxquels les utilisateurs ont accès. Si l'utilisateur n'a pas accès au groupe de travail, ces opérations d'API renvoient la requête IDs non autorisée dans la liste des requêtes non traitées IDs . Pour de plus amples informations, veuillez consulter [Utiliser le groupe de travail Athena APIs](workgroups-api-list.md). + Si le groupe de travail dans lequel une requête sera exécutée est configuré avec un [emplacement imposé pour les résultats de la requête](workgroups-settings-override.md), ne spécifiez pas de `external_location` pour la requête CTAS. Athena émet une erreur et fait échouer une requête qui spécifie un `external_location` dans ce cas. Par exemple, cette requête échoue si vous remplacez les paramètres côté client par l'emplacement de vos résultats de requête, ce qui force le groupe de travail à utiliser son propre emplacement : `CREATE TABLE . WITH (format='Parquet', external_location='s3://amzn-s3-demo-bucket/test/') AS SELECT * FROM . LIMIT 10;` Les erreurs suivantes peuvent s'afficher. Ce tableau fournit une liste de certaines des erreurs liées aux groupes de travail et suggère des solutions. **Erreurs de groupe de travail** | Erreur | Se produit lorsque... | | --- | --- | | query state CANCELED (état de la requête ANNULÉ). Bytes scanned limit was exceeded (La limite d'octets analysés a été dépassée). | Une requête atteint une limite de données par requête et est annulée. Envisagez de réécrire la requête afin qu'elle lise moins de données, ou contactez votre administrateur de compte. | | Utilisateur : n'arn:aws:iam::123456789012:user/abcest pas autorisé à exécuter : athena : StartQueryExecution on resource : arn:aws:athena:us-east-1:123456789012:workgroup/workgroupname | Un utilisateur exécute une requête dans un groupe de travail, mais n'y a pas accès. Mettez à jour votre politique pour avoir accès au groupe de travail. | | SAISIE\$1INVALIDE. WorkGroup est désactivé. | Un utilisateur exécute une requête dans un groupe de travail, mais le groupe de travail est désactivé. Votre groupe de travail peut être désactivé par votre administrateur. Il est également possible que vous n'y ayez pas accès. Dans les deux cas, contactez un administrateur y ayant accès pour modifier les groupes de travail. | | SAISIE\$1INVALIDE. WorkGroup n'est pas trouvé. | Un utilisateur exécute une requête dans un groupe de travail, mais le groupe de travail n'existe pas. Cela peut se produire si le groupe de travail a été supprimé. Basculer vers un autre groupe de travail pour exécuter votre requête. | | InvalidRequestException: lors de l'appel de l' StartQueryExecutionopération : aucun emplacement de sortie n'est fourni. An output location is required either through the Workgroup result configuration setting or as an API input (Un emplacement de sortie est nécessaire, soit par le biais du paramètre de configuration des résultats du groupe de travail, soit en tant qu'entrée API). | Un utilisateur exécute une requête avec l'API sans spécifier l'emplacement pour les résultats de la requête. Vous devez définir l'emplacement de sortie pour les résultats des requêtes de l'une des deux manières suivantes : soit pour les requêtes individuelles, en utilisant [OutputLocation](https://docs.aws.amazon.com/athena/latest/APIReference/API_ResultConfiguration.html#athena-Type-ResultConfiguration-OutputLocation)(côté client), soit dans le groupe de travail, en utilisant. [WorkGroupConfiguration](https://docs.aws.amazon.com/athena/latest/APIReference/API_WorkGroupConfiguration.html) | | The Create Table As Select query failed because it was submitted with an 'external\$1location' property to an Athena Workgroup that enforces a centralized output location for all queries (La requête « Create Table As Select » a échoué parce qu'elle a été soumise avec une propriété «∘external\$1location∘» à un groupe de travail Athena qui impose un emplacement de sortie centralisé pour toutes les requêtes). Please remove the 'external\$1location' property and resubmit the query (Supprimez la propriété «∘external\$1location∘» et soumettez à nouveau la requête). | Si le groupe de travail dans lequel une requête s'exécute est configuré avec un [emplacement imposé pour les résultats de la requête](workgroups-settings-override.md), et que vous spécifiez un external\$1location pour la requête CTAS. Dans ce cas, supprimez le external\$1location et exécutez à nouveau la requête. | | Impossible de créer une déclaration préparéeprepared\$1statement\$1name. The number of prepared statements in this workgroup exceeds the limit of 1000 (Le nombre d'instructions préparées dans ce groupe de travail dépasse la limite de 1∘000). | Le groupe de travail contient plus que la limite de 1 000 instructions préparées. Pour résoudre ce problème, utilisez [DEALLOCATE PREPARE](sql-deallocate-prepare.md) pour supprimer une ou plusieurs instructions préparées du groupe de travail. Vous pouvez également créer un nouveau groupe de travail. | # Gestion de la capacité de traitement des requêtes Vous pouvez utiliser les réservations de capacité pour obtenir une capacité de traitement sans serveur dédiée aux requêtes que vous exécutez dans Athena. Avec les réservations de capacité, vous pouvez tirer parti des fonctionnalités de gestion des charges de travail qui vous aident à hiérarchiser, contrôler et dimensionner vos charges de travail les plus importantes. Par exemple, vous pouvez ajouter de la capacité pour contrôler le nombre de requêtes que vous pouvez exécuter simultanément, choisir les charges de travail qui peuvent utiliser cette capacité et partager la capacité entre les charges de travail. La capacité est sans serveur, entièrement gérée par Athena et conservée pour vous aussi longtemps que vous en avez besoin. La configuration est simple et aucune modification de vos requêtes SQL n'est requise. Pour obtenir une capacité de traitement pour vos requêtes, vous créez une réservation de capacité, vous spécifiez le nombre d'unités de traitement des données (DPUs) dont vous avez besoin et vous assignez un ou plusieurs groupes de travail à la réservation. Les groupes de travail jouent un rôle important lorsque vous utilisez les réserves de capacité. Les groupes de travail vous permettent d'organiser les requêtes en groupes logiques ou en cas d'utilisation. Grâce aux réserves de capacité, vous attribuez une capacité de manière sélective aux groupes de travail afin de contrôler le comportement des requêtes pour chaque groupe de travail et la manière dont elles sont facturées. Pour plus d'informations sur les groupes de travail, consultez [Utilisation de groupes de travail pour contrôler l’accès aux requêtes et les coûts](workgroups-manage-queries-control-costs.md). L'attribution de groupes de travail aux réservations de capacité vous permet de donner la priorité à ces requêtes, car elles s'exécutent sur votre capacité réservée et ne sont pas prises en compte dans votre quota de requêtes DDL et DML. Par exemple, vous pouvez allouer de la capacité à un groupe de travail utilisé pour les requêtes d'information financière urgentes afin d'isoler ces requêtes des requêtes moins critiques d'un autre groupe de travail. Cela permet une exécution prévisible des requêtes pour les charges de travail critiques tout en permettant aux autres charges de travail de s'exécuter indépendamment. Vous pouvez utiliser les réserves de capacité et les groupes de travail ensemble pour répondre à différentes exigences. Voici des exemples de scénarios : + **Isolez les requêtes importantes** : pour garantir qu'une charge de travail importante dispose de la capacité dont elle a besoin au moment où vous en avez besoin, créez une réservation de capacité et assignez son groupe de travail à la réservation. Seules les requêtes du groupe de travail désigné utilisent la capacité de traitement de votre réservation. Par exemple, pour garantir l'exécution fiable des requêtes qui prennent en charge une application de production, assignez le groupe de travail de production chargé de ces requêtes à une réservation de capacité. Lorsque vous développez des requêtes, utilisez un groupe de travail distinct qui n'est pas associé à une réservation et déplacez les requêtes vers le groupe de travail de production lorsque vous êtes prêt. + **Partagez la capacité entre des charges de travail similaires : plusieurs charges** de travail peuvent partager la capacité d'une seule réservation. Cela vous permet d'obtenir un coût prévisible pour ces charges de travail et de contrôler leur simultanéité. Par exemple, si vous avez des charges de travail planifiées qui tolèrent les délais de début d'exécution des requêtes, vous pouvez affecter leurs groupes de travail à une seule réservation. Cela libère votre quota de requêtes DDL et DML pour les requêtes interactives exécutées dans le même compte, ce qui garantit que ces requêtes démarrent dans un délai minimal. ## Comprendre DPUs La capacité est mesurée en unités de traitement des données (DPUs). DPUs représentent les ressources de calcul et de mémoire sans serveur utilisées par Athena pour accéder aux données et les traiter en votre nom. Un processeur fournit généralement 4 V CPUs et 16 Go de mémoire. Le nombre de requêtes DPUs que vous détenez influence le nombre de requêtes que vous pouvez exécuter simultanément. Par exemple, une réservation avec 256 DPUs peut prendre en charge environ deux fois plus de requêtes simultanées qu'une réservation avec 128 DPUs. Pour plus d'informations sur l'estimation de vos exigences de capacité, consultez[Détermination des exigences de capacité](capacity-management-requirements.md). Pour de plus amples informations, consultez la rubrique [Tarification Amazon Athena](https://aws.amazon.com/athena/pricing/). ## Considérations et restrictions + Vous pouvez utiliser les réservations de capacité et la facturation par requête, sur la base des données numérisées, en même temps dans le même compte. + Les requêtes exécutées dans le cadre de réservations de capacité ne sont pas prises en compte dans votre quota de requêtes DDL et DML. + Si votre capacité est occupée à répondre à d'autres demandes, les demandes nouvellement soumises sont mises en file d'attente jusqu'à ce que la capacité soit disponible. La durée maximale autorisée dans la file d'attente est de 10 heures. + Un groupe de travail peut être affecté à une seule réservation de capacité à la fois. Vous pouvez affecter un total de 20 groupes de travail à une seule réservation. Lorsque vous attribuez plusieurs groupes de travail à une réservation, la capacité est partagée entre les groupes de travail et allouée aux requêtes en fonction de leur ordre de soumission. L'ordre d'exécution peut varier en raison de la façon dont Athena alloue dynamiquement la capacité aux requêtes. + Athena alloue automatiquement entre 4 et 124 requêtes DML DPUs en fonction de leur complexité. Les requêtes DDL en consomment 4 DPUs chacune. Consultez les rubriques suivantes pour plus d'informations : + [Détermination des exigences de capacité](capacity-management-requirements.md) + [Contrôler l'utilisation de la capacité](capacity-management-control-capacity-usage.md) + Le nombre minimum DPUs requis pour chaque réservation de capacité est de 4. Pour de plus amples informations, consultez la rubrique [Tarification Amazon Athena](https://aws.amazon.com/athena/pricing/). + Vous pouvez créer jusqu'à 100 réservations de capacité avec un total de 1 000 DPUs par compte et par région. Si vous en avez besoin de plus de 1 000 DPUs pour votre cas d'utilisation, veuillez contacter [athena-feedback@amazon.com](mailto:athena-feedback@amazon.com?subject=Athena Provisioned Capacity DPU Limit Request). + Les demandes de capacité ne sont pas garanties et peuvent prendre jusqu'à 30 minutes. La capacité n'est pas transférable à une autre réservation de capacité Compte AWS, ou Région AWS. + La `DPUConsumed` CloudWatch métrique est par groupe de travail plutôt que par réservation. Si vous déplacez un groupe de travail d'une réserve à une autre, la métrique `DPUConsumed` inclut les données de la période pendant laquelle le groupe de travail appartenait à la première réserve. Pour plus d'informations sur l'utilisation CloudWatch des métriques dans Athena, consultez. [Surveillez les métriques des requêtes Athena avec CloudWatch](query-metrics-viewing.md) + Pour supprimer un groupe de travail attribué à une réserve, supprimez d'abord le groupe de travail de la réserve. + Les groupes de travail configurés pour utiliser Apache Spark ne sont pas pris en charge. + Les réservations de capacité ne sont pas disponibles pour les publicités suivantes Régions AWS : + Israël (Tel Aviv) + Moyen-Orient (EAU) + Middle East (Bahrain) + Asie-Pacifique (Nouvelle Zélande) **Topics** + [Comprendre DPUs](#capacity-management-understanding-dpus) + [Considérations et restrictions](#capacity-management-considerations-limitations) + [Détermination des exigences de capacité](capacity-management-requirements.md) + [Création de réserves de capacité](capacity-management-creating-capacity-reservations.md) + [Contrôler l'utilisation de la capacité](capacity-management-control-capacity-usage.md) + [Régler automatiquement la capacité](capacity-management-automatically-adjust-capacity.md) + [Gestion des réserves](capacity-management-managing-reservations.md) + [Politiques IAM pour les réserves de capacité](capacity-reservations-iam-policy.md) + [Réservation de capacité à Athena APIs](capacity-management-api-list.md) # Détermination des exigences de capacité Avant de créer une réservation de capacité, vous pouvez estimer la capacité requise afin de pouvoir lui attribuer le nombre correct de DPUs. Ensuite, une fois qu'une réserve est en cours d'utilisation, vous souhaiterez peut-être vérifier si sa capacité est insuffisante ou excédentaire. Cette rubrique décrit les techniques que vous pouvez utiliser pour réaliser ces estimations et décrit également certains AWS outils permettant d'évaluer l'utilisation et les coûts. **Topics** + [Estimation de la capacité requise](#capacity-management-requirements-estimating) + [Signes indiquant qu'une capacité accrue est requise](#capacity-management-requirements-insufficient-capacity) + [Vérification de la capacité inactive](#capacity-management-requirements-idle-capacity) + [Surveillance de la consommation du DPU](#capacity-management-requirements-monitoring-dpu-consumption) ## Estimation de la capacité requise Lors de l'estimation des exigences de capacité, il est utile de prendre en compte deux points de vue : la capacité dont une requête particulière peut avoir besoin et la capacité dont vous pourriez avoir besoin en général. ### Estimation des exigences de capacité par requête Pour déterminer le nombre DPUs requis par une requête, vous pouvez suivre les instructions suivantes : + Les requêtes DDL consomment 4 DPUs. + Les requêtes DML consomment entre 4 et 124 DPUs. Athena détermine le nombre de caractères DPUs requis par une requête DML lorsque celle-ci est soumise. Le nombre varie en fonction de la taille des données, du format de stockage, de la construction de la requête et d'autres facteurs. En général, Athena essaie de sélectionner le nombre de DPU le plus bas et le plus efficace. Si Athena détermine qu'une puissance de calcul plus importante est nécessaire pour que la requête soit menée à bien, elle augmente le nombre de données DPUs attribuées à la requête. ### Estimation des exigences de capacité spécifiques à la charge de travail Pour déterminer la capacité dont vous pourriez avoir besoin pour exécuter plusieurs requêtes en même temps, prenez en compte les directives générales du tableau suivant : **** | Requêtes simultanées | DPUs requis | | --- | --- | | 10 | 40 ou plus | | 20 | 96 ou plus | | 30 ou plus | 240 ou plus | Notez que le nombre réel dont vous avez besoin dépend de vos objectifs et de vos modèles d'analyse. DPUs Par exemple, si vous souhaitez que les requêtes démarrent immédiatement sans mise en file d'attente, déterminez votre demande maximale de requêtes simultanées, puis indiquez le nombre de DPUs requêtes simultanées en conséquence. Vous pouvez fournir une quantité DPUs inférieure à votre demande de pointe, mais des files d'attente peuvent survenir en cas de pic de demande. Lors de la mise en file d'attente, Athena place vos requêtes dans une file d'attente et les exécute lorsque la capacité devient disponible. Si votre objectif est d'exécuter des requêtes dans les limites d'un budget fixe, vous pouvez utiliser le [calculateur de AWS prix](https://calculator.aws/#/addService/Athena) pour déterminer le nombre de requêtes DPUs correspondant à votre budget. Enfin, n'oubliez pas que la taille des données, le format de stockage et la manière dont une requête est écrite DPUs influencent les besoins de celle-ci. Pour améliorer les performances des requêtes, vous pouvez compresser ou partitionner vos données ou les convertir en formats en colonnes. Pour de plus amples informations, veuillez consulter [Optimisation des performances d’Athena](performance-tuning.md). ## Signes indiquant qu'une capacité accrue est requise Les messages d'erreur relatifs à une capacité insuffisante et la mise en file d'attente des requêtes indiquent que la capacité qui vous est attribuée est inadéquate. Si vos requêtes échouent avec un message d'erreur indiquant une capacité insuffisante, c'est que le nombre de DPU de votre réserve de capacité est trop faible pour votre requête. Par exemple, si vous avez une réservation avec 24 DPUs et que vous exécutez une requête nécessitant plus de 24 DPUs, la requête échouera. Pour détecter cette erreur de requête, vous pouvez utiliser les [EventBridge événements](athena-events.md) d'Athéna. Essayez d'en ajouter d'autres DPUs et de réexécuter votre requête. Si de nombreuses requêtes sont mises en file d'attente, cela signifie que votre capacité est pleinement utilisée par d'autres requêtes. Pour réduire la mise en file d'attente, effectuez l'une des actions suivantes : + Ajoutez DPUs à votre réservation pour augmenter la simultanéité des requêtes. + Supprimer des groupes de travail de votre réserve afin de libérer de la capacité pour d'autres requêtes. Pour vérifier l'absence de files d'attente excessives, utilisez l'[CloudWatchindicateur](query-metrics-viewing.md) de temps de file d'attente des requêtes Athena pour les groupes de travail inclus dans votre réservation de capacité. Si la valeur est supérieure à votre seuil préféré, vous pouvez l'ajouter DPUs à la réservation de capacité. ## Vérification de la capacité inactive Pour vérifier la capacité inutilisée, vous pouvez soit diminuer le nombre de personnes DPUs dans la réservation, soit augmenter sa charge de travail, puis observer les résultats. **Pour vérifier la capacité inutilisée** 1. Effectuez l’une des actions suivantes : + Réduisez le nombre de DPUs personnes figurant dans votre réservation (réduisez les ressources disponibles) + Ajouter des groupes de travail à votre réserve (augmenter la charge de travail) 1. [CloudWatch](query-metrics-viewing.md)À utiliser pour mesurer le temps d'attente des requêtes. 1. Si le temps de file d'attente augmente au-delà d'un niveau souhaitable, effectuez l'une des actions suivantes : + Supprimer des groupes de travail + Ajoutez DPUs à votre réservation de capacité 1. Après chaque modification, vérifiez les performances et le temps de file d'attente des requêtes. 1. Continuez à ajuster le nombre de and/or DPU de charge de travail pour atteindre l'équilibre souhaité. Si vous ne souhaitez pas maintenir la capacité en dehors d'une période préférée, vous pouvez [annuler](capacity-management-cancelling-a-capacity-reservation.md) la réserve et en créer une autre ultérieurement. Toutefois, même si vous avez récemment annulé la capacité d'une autre réserve, les demandes de nouvelles capacités ne sont pas garanties et la création de nouvelles réserves prend du temps. ## Surveillance de la consommation du DPU Une fois vos requêtes exécutées, vous pouvez consulter le DPU consommé par vos requêtes afin d'affiner vos estimations de capacité. Athena fournit des mesures de consommation du DPU via la console, les opérations de l'API et. CloudWatch Ces informations vous aident à identifier les requêtes qui consomment plus ou moins de ressources que prévu et à optimiser votre allocation de capacité en fonction de données réelles. Pour des informations détaillées sur l'affichage et le suivi de la consommation du DPU, consultez[Surveiller l'utilisation du DPU](capacity-management-control-capacity-usage.md#capacity-management-monitor-dpu-usage). ## Outils d'évaluation des exigences de capacité et des coûts Vous pouvez utiliser les services et fonctionnalités suivants AWS pour mesurer votre utilisation et vos coûts d'Athena. ### CloudWatch métriques Vous pouvez configurer Athena pour publier les métriques liées aux requêtes sur Amazon CloudWatch au niveau du groupe de travail. Une fois que vous avez activé les métriques pour le groupe de travail, les métriques pour les requêtes du groupe de travail s'affichent dans la console Athena sur la page de détails du groupe de travail. Pour plus d'informations sur les métriques Athena publiées sur CloudWatch et leurs dimensions, consultez. [Surveillez les métriques des requêtes Athena avec CloudWatch](query-metrics-viewing.md) ### CloudWatch métriques d'utilisation Vous pouvez utiliser les statistiques CloudWatch d'utilisation pour avoir une idée de la manière dont votre compte utilise les ressources en affichant votre utilisation actuelle des services sur CloudWatch des graphiques et des tableaux de bord. Pour Athena, les mesures de disponibilité d'utilisation correspondent aux [quotas de AWS service](service-limits.md) pour Athena. Vous pouvez configurer des alarmes qui vous alertent lorsque votre utilisation approche d’un quota de service. Pour de plus amples informations, veuillez consulter [Surveillez les statistiques d'utilisation d'Athena avec CloudWatch](monitoring-athena-usage-metrics.md). ### EventBridge Événements Amazon Vous pouvez utiliser Amazon Athena avec Amazon EventBridge pour recevoir des notifications en temps réel concernant l'état de vos requêtes. Lorsqu'une requête que vous avez soumise change d'état, Athena publie un événement EventBridge contenant des informations sur le changement d'état de la requête. Vous pouvez écrire des règles simples pour les événements qui vous intéressent et effectuer des actions automatisées lorsqu'un événement correspond à une règle. Pour plus d'informations, veuillez consulter les ressources suivantes. + [Surveillez les événements de requête Athena avec EventBridge](athena-events.md) + [Qu'est-ce qu'Amazon EventBridge ?](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) + [ EventBridgeÉvénements Amazon](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-events.html) ### Étiquettes Dans Athena, les réserves de capacité prennent en charge les balises. Une balise se compose d'une clé et d'une valeur. Pour suivre vos coûts dans Athena, vous pouvez utiliser des balises de AWS répartition des coûts générées. AWS utilise les balises de répartition des coûts pour organiser les coûts des ressources dans votre [rapport sur les coûts et l'utilisation](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html). Cela vous permet de classer et de suivre plus facilement vos AWS coûts. Pour activer les balises de répartition des coûts pour Athena, vous devez utiliser la [console AWS Billing and Cost Management](https://console.aws.amazon.com/billing/). Pour plus d'informations, veuillez consulter les ressources suivantes. + [Balisage des ressources Athena](tags.md) + [Activation des AWS balises de répartition des coûts générées](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activate-built-in-tags.html) + [Utilisation des balises de répartition des coûts  AWS](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) # Création de réserves de capacité Pour commencer, vous créez une réservation de DPUs capacité dont vous avez besoin, puis vous assignez un ou plusieurs groupes de travail qui utiliseront cette capacité pour leurs requêtes. Vous pouvez ajuster votre capacité ultérieurement si nécessaire pour fournir des performances plus constantes ou mieux gérer les coûts. Pour plus d'informations sur l'estimation de vos exigences de capacité, consultez[Détermination des exigences de capacité](capacity-management-requirements.md). **Important** Les demandes de capacité ne sont pas garanties et peuvent prendre jusqu'à 30 minutes. **Pour créer une réserve de capacité** 1. Ouvrez la console à l'adresse [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Si le panneau de navigation de la console n'est pas visible, choisissez le menu d'extension sur la gauche. 1. Choisissez **Administration**, **Réserves de capacité**. 1. Choisissez **Créer une réserve de capacité**. 1. Sur la page **Créer une réserve de capacité**, saisissez le nom dans le champ **Nom de la réserve de capacité**. Le nom doit être unique, compter de 1 à 128 caractères, et utiliser uniquement les caractères a-z, A-Z, 0-9, \$1 (trait de soulignement), . (point) et - (trait d'union). Vous ne pouvez pas modifier le nom une fois la réserve créée. 1. Pour le **DPU**, choisissez ou entrez le nombre d'unités de traitement de données (DPUs) que vous souhaitez par incréments de 4. Pour de plus amples informations, veuillez consulter [Comprendre DPUs](capacity-management.md#capacity-management-understanding-dpus). 1. (Facultatif) Développez l'option **Balises**, puis choisissez **Ajouter une nouvelle balise** pour ajouter une ou plusieurs key/value paires personnalisées à associer à la ressource de réservation de capacité. Pour de plus amples informations, veuillez consulter [Balisage des ressources Athena](tags.md). 1. Choisissez **Examiner**. 1. À l'invite **Confirmer la réservation de capacité**, confirmez le nombre de DPUs Région AWS, et les autres informations. Si vous acceptez, choisissez **Soumettre**. Sur la page de détails, l'**état** de votre réserve de capacité indique **En attente**. Lorsque votre réserve de capacité est disponible pour exécuter des requêtes, son état s'affiche comme **Actif**. À ce stade, vous êtes prêt à ajouter un ou plusieurs groupes de travail à votre réserve. Pour les étapes, consultez [Ajout de groupes de travail à une réserve](capacity-management-adding-workgroups-to-a-reservation.md). # Contrôler l'utilisation de la capacité Vous pouvez contrôler le nombre de DPU qu'Athena alloue à vos requêtes en définissant des contrôles DPU maximum ou minimum. Vous pouvez les configurer au niveau du groupe de travail pour établir des contrôles de base pour toutes les requêtes, ou au niveau des requêtes individuelles pour un contrôle précis. Cela vous permet de contrôler directement les performances des requêtes, la simultanéité de la charge de travail et les coûts. + Lorsque vous définissez un nombre maximal de DPU, les requêtes ne peuvent pas consommer plus de capacité que ce que vous spécifiez. Cela facilite le contrôle des coûts et de la simultanéité de la charge de travail. Par exemple, si votre réservation de capacité comporte 200 DPU, le fait de définir le maximum de DPU par requête sur 8 vous permet d'exécuter 25 requêtes simultanément. Si vous augmentez votre réservation à 400 DPU, vous pouvez exécuter 50 requêtes simultanément. + Lorsque vous définissez un nombre minimum de DPU, vous vous assurez que les requêtes sont exécutées avec le nombre minimum de DPU souhaité. Cela est utile lorsque vous connaissez à l'avance le profil d'utilisation de la capacité typique pour vos requêtes. **Note** Les contrôles d'utilisation du DPU ne s'appliquent qu'aux requêtes exécutées avec des réservations de capacité. **Note** Pour utiliser le même nombre de DPU pour toutes les requêtes, utilisez la même valeur pour le DPU minimum et maximum. ## Définissez les commandes du DPU au niveau du groupe de travail Définissez les contrôles DPU au niveau du groupe de travail afin de gérer les coûts et de contrôler les performances de la charge de travail pour le groupe de travail de votre choix. Les contrôles DPU définis au niveau du groupe de travail s'appliquent à toutes les requêtes lorsque l'option Ignorer les **paramètres côté client** est activée. **Pour configurer les commandes du DPU à l'aide de la console** 1. Ouvrez la console à l'adresse [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Dans le panneau de navigation, choisissez **Groupes de travail**. 1. Sélectionnez un groupe de travail qui utilise une réservation de capacité. 1. Dans l'onglet **Contrôles d'exécution**, choisissez **Modifier les contrôles**. 1. Configurez ce qui suit : + Pour **Min. DPU par requête**, entrez une valeur comprise entre 4 et 124 par incréments de 4. + Pour le **DPU maximal par requête**, entrez une valeur comprise entre 4 et 124 par incréments de 4. 1. Choisissez **Enregistrer**. 1. (Facultatif) Sélectionnez **Remplacer les paramètres côté client pour appliquer ces paramètres** et ignorer les configurations DPU au niveau des requêtes. **Pour configurer les commandes du DPU à l'aide du AWS CLI** + Utilisez la `update-work-group` commande pour définir les contrôles DPU pour un groupe de travail : ``` aws athena update-work-group \ --work-group my_workgroup \ --configuration-updates '{ "EngineConfiguration": { "Classifications": [ { "Name": "athena-query-engine-properties", "Properties": { "max-dpu-count" : "24", "min-dpu-count" : "12" } } ] }}' ``` Si vous définissez cette option`true`, `EnforceWorkGroupConfiguration` les paramètres du groupe de travail remplacent tous les contrôles DPU spécifiés au niveau de la requête lors de leur envoi via. [StartQueryExecution](https://docs.aws.amazon.com/athena/latest/APIReference/API_StartQueryExecution.html) Cela garantit une allocation cohérente des ressources pour toutes les requêtes du groupe de travail. ## Définissez les contrôles du DPU avec des requêtes individuelles Définissez des contrôles DPU au niveau des requêtes lorsque vous avez besoin d'un contrôle précis avec des requêtes ayant des besoins en ressources différents. **Les contrôles DPU au niveau de la requête ont priorité sur les paramètres au niveau du groupe de travail, sauf si le groupe de travail a activé l'option Remplacer les paramètres côté client.** **Pour définir les contrôles DPU pour une requête à l'aide de la console** 1. Ouvrez la console à l'adresse [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Dans le panneau de navigation, choisissez **Query Editor (Éditeur de requête)**. 1. Sélectionnez un groupe de travail qui utilise une réservation de capacité. 1. Choisissez l'onglet **Paramètres de requête**. 1. Dans la section **Contrôles d'exécution**, choisissez **Modifier les contrôles**. 1. Configurez ce qui suit : + Pour **Min. DPU par requête**, entrez une valeur comprise entre 4 et 124 par incréments de 4. + Pour le **DPU maximal par requête**, entrez une valeur comprise entre 4 et 124 par incréments de 4. 1. Choisissez **Enregistrer**. **Pour définir les contrôles DPU pour une requête à l'aide du AWS CLI** + Utilisez la `start-query-execution` commande avec le `engine-configuration` paramètre : ``` aws athena start-query-execution \ --query-string "SELECT * FROM my_table LIMIT 10" \ --work-group "my_workgroup" \ --engine-configuration '{ "Classifications": [ { "Name": "athena-query-engine-properties", "Properties": { "max-dpu-count" : "32", "min-dpu-count" : "8" } } ]}' ``` La relation entre les paramètres DPU au niveau de la requête et au niveau du groupe de travail dépend de la configuration de votre groupe de travail : + Lorsque l'option **Ignorer les paramètres côté client** est activée, les contrôles DPU au niveau du groupe de travail ont priorité sur les paramètres au niveau des requêtes. Cela garantit une utilisation cohérente des ressources pour toutes les requêtes du groupe de travail spécifié. + Lorsque le **remplacement des paramètres côté client** n'est pas activé, les contrôles DPU au niveau des requêtes ont priorité sur les paramètres au niveau du groupe de travail. Cela permet une certaine flexibilité pour optimiser les requêtes individuelles. Si vous ne spécifiez aucun contrôle DPU à aucun niveau, Athena alloue automatiquement la capacité en fonction de la complexité des requêtes. **Note** Pour les requêtes DDL, la valeur maximale du minimum DPUs est de 4. La définition d'un minimum plus élevé pour les requêtes DDL entraîne une erreur. ## Surveiller l'utilisation du DPU Une fois vos requêtes terminées, vous pouvez consulter son utilisation du DPU. Athena fournit des métriques d'utilisation du DPU via la console, les opérations d'API et. CloudWatch **Pour afficher la consommation de DPU dans la console** 1. Ouvrez la console à l'adresse [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Dans le panneau de navigation, choisissez **Query Editor (Éditeur de requête)**. 1. Une fois la requête terminée, consultez sa valeur de **DPU consommée** dans le conteneur des résultats de la requête. 1. Pour consulter la consommation de DPU pour les requêtes précédentes, procédez comme suit : 1. Choisissez **Requêtes récentes** dans le volet de navigation. 1. Sélectionnez l'icône des paramètres pour ajouter la colonne **DPU consommée** au tableau si elle n'est pas déjà affichée. 1. Vérifiez la consommation de DPU pour chaque requête terminée. 1. Dans l'**éditeur de requêtes**, choisissez éventuellement l'onglet **Statistiques de requête** et passez en revue le **DPU consommé**. **Pour récupérer la consommation de DPU à l'aide de l'API** 1. Utilisez les opérations d'API suivantes pour récupérer la consommation de DPU par programmation : + `GetQueryExecution`- Renvoie les détails d'exécution d'une requête spécifique + `BatchGetQueryExecution`- Renvoie les détails d'exécution pour plusieurs requêtes 1. Exemple d’utilisation de AWS CLI : ``` aws athena get-query-execution \ --query-execution-id "123e4567-e89b-12d3-a456-426614174000" ``` La réponse inclut le `DpuCount` champ dans l'`Statistics`objet : ``` { "QueryExecution": { "Statistics": { "DpuCount": 8 } } } ``` **Pour surveiller l'utilisation du DPU avec CloudWatch** + Athena publie des métriques liées aux requêtes CloudWatch qui vous aident à surveiller l'utilisation des capacités et d'autres données de performance. Pour en savoir plus, veuillez consulter la section [Surveillez les métriques des requêtes Athena avec CloudWatch](query-metrics-viewing.md). # Régler automatiquement la capacité Vous pouvez ajuster automatiquement la capacité de votre réservation en fonction de l'utilisation de la charge de travail à l'aide de la solution d'auto-scaling d'Athena. Il augmente automatiquement la capacité lorsque l'utilisation dépasse le seuil configuré et supprime de la capacité pendant les périodes de faible utilisation afin de réduire les coûts. Vous pouvez personnaliser son comportement en définissant différents seuils d'utilisation, des quantités minimales et maximales de DPU, des incréments de dimensionnement et une fréquence d'évaluation de l'utilisation. Cela élimine les ajustements manuels de capacité tout en vous aidant à trouver un équilibre entre les exigences de performance et l'optimisation des coûts. Vous déployez cette solution sans serveur à l'aide d'un CloudFormation modèle. Il crée une machine d'état Step Functions qui surveille les indicateurs d'utilisation et prend des décisions de dimensionnement. Vous pouvez personnaliser davantage le modèle ou la machine à états pour répondre à vos besoins spécifiques. Pour commencer, utilisez la console Athena et choisissez **Configurer l'auto-scaling** sur la page détaillée de votre réservation de capacité, qui vous redirige vers le modèle préchargé. CloudFormation Vous pouvez également suivre la procédure ci-dessous. ## Conditions préalables + Une réservation de capacité active est requise + Autorisations IAM requises pour déployer des CloudFormation stacks et créer des ressources Step Functions ## Lancez la CloudFormation pile Ce CloudFormation modèle automatisé déploie la solution d'auto-scaling Athena Capacity Reservation. Vous devez suivre les étapes applicables [Conditions préalables](#capacity-management-auto-scaling-prerequisites) avant de lancer la pile. [https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?&templateURL=https:%2F%2Fathena-downloads.s3.us-east-1.amazonaws.com%2F%2Ftemplates%2F%2Fcapacity-reservation-scaling%2F%2Fstate-machine%2F%2Fathena-capacity-reservation-scaling-template-v1.1.yaml](https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?&templateURL=https:%2F%2Fathena-downloads.s3.us-east-1.amazonaws.com%2F%2Ftemplates%2F%2Fcapacity-reservation-scaling%2F%2Fstate-machine%2F%2Fathena-capacity-reservation-scaling-template-v1.1.yaml) **Pour lancer la solution d'auto-scaling** 1. Connectez-vous à [AWS la console de gestion](https://console.aws.amazon.com/) et sélectionnez le bouton pour lancer le `AWSAccelerator-InstallerStack` CloudFormation modèle. 1. Le modèle est lancé par défaut dans l'est des États-Unis (Virginie du Nord). Pour lancer la solution sous une autre forme Région AWS, utilisez le sélecteur de région dans la barre de navigation de la console. 1. Sur la page **Create stack**, vérifiez que l'URL du modèle se trouve dans la **zone de texte URL Amazon S3** et choisissez **Next**. 1. Sur la page **Spécifier les détails de la pile**, attribuez un nom à votre pile de solutions. 1. Sous **Paramètres**, passez en revue les paramètres de ce modèle de solution et modifiez-les si nécessaire. Cette solution utilise les valeurs par défaut suivantes. **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/athena/latest/ug/capacity-management-automatically-adjust-capacity.html) **Note** Toutes les valeurs DPU doivent être des multiples de 4 pour être conformes aux exigences de réservation de capacité d'Athena. 1. Choisissez **Next** (Suivant). 1. Sur la page **Configurer les options de pile**, choisissez **Suivant**. 1. Sur la page **Réviser et créer**, vérifiez et confirmez les paramètres. Cochez la case indiquant que le modèle est susceptible de créer des ressources IAM. 1. Choisissez **Submit** pour déployer la pile. Vous pouvez consulter l'état de la pile dans la CloudFormation console dans la colonne **État**. Vous devriez recevoir un `CREATE_COMPLETE` statut dans quelques minutes. # Gestion des réserves Vous pouvez consulter et gérer vos réserves de capacité sur la page **Réserves de capacité**. Vous pouvez effectuer des tâches de gestion telles que l'ajout ou la réduction DPUs, la modification des attributions des groupes de travail et le balisage ou l'annulation de réservations. **Pour consulter et gérer des réserves de capacité** 1. Ouvrez la console à l'adresse [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Si le panneau de navigation de la console n'est pas visible, choisissez le menu d'extension sur la gauche. 1. Choisissez **Administration**, **Réserves de capacité**. 1. Vous pouvez effectuer les tâches suivantes sur la page des réserves de capacité : + Pour créer une réserve de capacité, sélectionnez **Créer une réserve de capacité**. + Utilisez le champ de recherche pour filtrer les réservations par nom ou par numéro de DPUs. + Choisissez le menu déroulant d'état pour filtrer par état de réserve de capacité (par exemple, **Actif** ou **Annulé**). Pour de plus amples informations sur l'état des réserves, consultez [Présentation de l’état des réserves](#capacity-management-understanding-reservation-status). + Pour consulter les détails d'une réserve de capacité, cliquez sur le lien correspondant à la réserve. La page de détails de la réserve inclut des options relatives à la [modification de la capacité](capacity-management-editing-capacity-reservations.md), à l’[ajout de groupes de travail](capacity-management-adding-workgroups-to-a-reservation.md), à la [suppression de groupes de travail](capacity-management-removing-a-workgroup-from-a-reservation.md) et à l’[annulation](capacity-management-cancelling-a-capacity-reservation.md) de la réserve. + Pour modifier une réservation (par exemple, en ajoutant ou en supprimant DPUs), sélectionnez le bouton correspondant à la réservation, puis choisissez **Modifier**. + Pour annuler une réserve, sélectionnez le bouton correspondant à la réserve, puis cliquez sur **Annuler**. ## Présentation de l’état des réserves Le tableau suivant décrit les valeurs d'état possibles pour une réserve de capacité. **** | État | Description | | --- | --- | | En suspens | Athena est en train de traiter votre demande de capacité. La capacité n'est pas prête à exécuter des requêtes. | | Actif | La capacité est disponible pour exécuter des requêtes. | | Échec | Votre demande de capacité n'a pas été traitée avec succès. Notez que le traitement des demandes de capacité n'est pas garanti. Les réserves qui ont échoué sont prises en compte dans le calcul des limites de DPU de votre compte. Pour libérer l'utilisation, vous devez annuler la réserve. | | Mise à jour en attente | Athena est en train de modifier la réserve. Par exemple, ce statut apparaît une fois que vous avez modifié la réservation pour l'ajouter ou la supprimer DPUs. | | Annulation | Athena est en train de traiter une demande d'annulation de réserve. Les requêtes toujours en cours d'exécution dans les groupes de travail qui utilisaient la réserve sont autorisées à se terminer, mais les autres requêtes du groupe de travail utiliseront la capacité à la demande (non allouée). | | Annulée | L'annulation de la réserve de capacité est terminée. Les réserves annulées restent dans la console pendant 45 jours. Après 45 jours, Athena annulera la réserve. Pendant les 45 jours, vous ne pouvez pas réaffecter ou réutiliser la réserve, mais vous pouvez vous référer à ses balises et consulter ses détails pour une référence historique. Il n'est pas garanti que la capacité annulée puisse être réservée à nouveau à une date future. La capacité ne peut pas être transférée à une autre réservation, Compte AWS ou Région AWS. | ## Comprendre Active DPUs et Target DPUs Dans la liste des réserves de capacité de la console Athena, votre réserve affiche deux valeurs DPU : **DPU active** et **DPU cible**. + **DPU actif** : le nombre de DPUs DPU disponibles dans votre réservation pour exécuter des requêtes. Par exemple, si vous demandez 100 DPUs et que votre demande est satisfaite, **Active DPU** affiche **100**. + **DPU cible** : numéro vers DPUs lequel votre réservation est en train d'être transférée. **Le DPU cible** affiche une valeur différente de celle du **DPU actif** lorsqu'une réservation est créée ou lorsqu'une augmentation ou une diminution du nombre de réservations DPUs est en attente. **Par exemple, après avoir soumis une demande pour créer une réservation avec 24 DPUs, le **statut** de la réservation sera **En attente**, le **DPU actif** sera **0** et le **DPU cible** sera 24.** **Si vous avez une réservation de 100 DPUs et que vous modifiez votre réservation pour demander une augmentation de 20 DPUs, le **statut** sera **En attente de mise à jour**, le **DPU actif** sera de **100** et le **DPU cible** de 120.** **Si vous avez une réservation de 100 DPUs et que vous modifiez votre réservation pour demander une réduction de 20 DPUs, le **statut** sera **En attente de mise à jour**, le **DPU actif** sera de **100** et le **DPU cible** de 80.** Au cours de ces transitions, Athena travaille activement à acquérir ou à réduire le nombre de en DPUs fonction de votre demande. Lorsque **DPU active** devient égal à **DPU cible**, le nombre cible est atteint et aucune modification n'est en attente. Pour récupérer ces valeurs par programmation, vous pouvez appeler l'action [GetCapacityReservation](https://docs.aws.amazon.com/athena/latest/APIReference/API_GetCapacityReservation.html)API. L'API fait référence à **DPU active** et **DPU cible** sous `AllocatedDpus` et `TargetDpus`. **Topics** + [Présentation de l’état des réserves](#capacity-management-understanding-reservation-status) + [Comprendre Active DPUs et Target DPUs](#capacity-management-understanding-dpu-status) + [Modification des réserves de capacité](capacity-management-editing-capacity-reservations.md) + [Ajout de groupes de travail à une réserve](capacity-management-adding-workgroups-to-a-reservation.md) + [Suppression d’un groupe de travail d’une réserve](capacity-management-removing-a-workgroup-from-a-reservation.md) + [Annulation d’une réserve de capacité](capacity-management-cancelling-a-capacity-reservation.md) + [Suppression d’une réserve de capacité](capacity-management-deleting-a-capacity-reservation.md) # Modification des réserves de capacité Après avoir créé une réservation de capacité, vous pouvez ajuster son nombre DPUs et ajouter ou supprimer ses balises personnalisées. **Pour modifier une réserve de capacité** 1. Ouvrez la console à l'adresse [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Si le panneau de navigation de la console n'est pas visible, choisissez le menu d'extension sur la gauche. 1. Choisissez **Administration**, **Réserves de capacité**. 1. Dans la liste des réserves de capacité, effectuez l'une des opérations suivantes : + Sélectionner le bouton en regard de la réserve, puis choisir **Modifier**. + Choisir le lien de la réserve, puis choisir **Modifier**. 1. Pour **DPU**, choisissez ou entrez le nombre d'unités de traitement de données que vous souhaitez. Pour de plus amples informations, veuillez consulter [Comprendre DPUs](capacity-management.md#capacity-management-understanding-dpus). **Note** Vous pouvez demander à ajouter DPUs à une réservation de capacité active à tout moment. Vous pouvez demander la réduction d'une réservation DPUs de capacité active lorsqu'une minute s'est écoulée depuis que la réservation est devenue active ou quand elle a DPUs été ajoutée pour la dernière fois. Lorsque vous demandez une réduction DPUs, Athena donne la priorité à la suppression des périodes d'inactivité par rapport à celles d'activité. DPUs DPUs Si les requêtes marquées pour suppression sont gourmandes, Athena attend DPUs qu'elles soient terminées avant de supprimer le. DPUs 1. (Facultatif) Dans **Balises**, choisissez **Supprimer la balise** pour supprimer une balise ou **Ajouter une balise** pour ajouter une nouvelle balise. 1. Sélectionnez **Soumettre**. La page de détails de la réserve affiche la configuration mise à jour. # Ajout de groupes de travail à une réserve Après avoir créé une réserve de capacité, vous pouvez ajouter jusqu'à 20 groupes de travail à la réserve. L'ajout d'un groupe de travail à une réserve indique à Athena quelles requêtes doivent être exécutées sur la capacité réservée. Les requêtes provenant de groupes de travail qui ne sont pas associées à une réserve continuent d'être exécutées selon le modèle de tarification par téraoctet (To) analysé par défaut. Lorsqu'une réserve comporte deux groupes de travail ou plus, les requêtes provenant de ces groupes de travail peuvent utiliser la capacité de la réserve. Vous pouvez ajouter et supprimer des groupes de travail à tout moment. Lorsque vous ajoutez ou supprimez des groupes de travail, les requêtes en cours d'exécution ne sont pas interrompues. Lorsque votre réserve est en attente, les requêtes provenant des groupes de travail que vous avez ajoutés continuent de s'exécuter en utilisant le modèle de tarification par téraoctet (To) analysé par défaut jusqu'à ce que la réserve soit active. **Pour ajouter un ou plusieurs groupes de travail à votre réserve de capacité** 1. Sur la page de détails de la réserve de capacité, choisissez **Ajouter des groupes de travail**. 1. Sur la page **Ajouter des groupes de travail**, sélectionnez les groupes de travail que vous souhaitez ajouter, puis choisissez **Ajouter des groupes de travail**. Vous pouvez attribuer un groupe de travail à plusieurs réserves. La page de détails de votre réserve de capacité répertorie les groupes de travail que vous avez ajoutés. Les requêtes exécutées dans ces groupes de travail utiliseront la capacité que vous avez réservée lorsque la réserve est active. # Suppression d’un groupe de travail d’une réserve Si vous n'avez plus besoin de capacité dédiée pour un groupe de travail ou si vous souhaitez déplacer un groupe de travail vers sa propre réserve, vous pouvez le supprimer à tout moment. La suppression d'un groupe de travail d'une réserve est un processus simple. Une fois que vous avez retiré un groupe de travail d'une réservation, les requêtes du groupe de travail supprimé utilisent à nouveau la capacité à la demande et sont facturées sur la base des téraoctets (To) analysés. **Pour supprimer un ou plusieurs groupes de travail d'une réserve** 1. Sur la page de détails de la réserve de capacité, sélectionnez les groupes de travail que vous souhaitez supprimer. 1. Choisissez **Supprimer les groupes de travail**. L'invite **Supprimer les groupes de travail ?** vous informe que toutes les requêtes actuellement actives seront terminées avant que le groupe de travail ne soit supprimé de la réserve. 1. Cliquez sur **Supprimer**. La page de détails de votre réserve de capacité indique que les groupes de travail supprimés ne sont plus présents. # Annulation d’une réserve de capacité Si vous ne souhaitez plus utiliser la réserve de capacité, vous pouvez l'annuler. Les requêtes toujours en cours d'exécution dans les groupes de travail qui utilisaient la réserve seront autorisées à se terminer, mais les autres requêtes du groupe de travail n'utiliseront plus la réserve. **Note** Il n'est pas garanti que la capacité annulée puisse être réservée à nouveau à une date future. La capacité ne peut pas être transférée à une autre réservation, Compte AWS ou Région AWS. **Pour annuler une réserve de capacité** 1. Ouvrez la console à l'adresse [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Si le panneau de navigation de la console n'est pas visible, choisissez le menu d'extension sur la gauche. 1. Choisissez **Administration**, **Réserves de capacité**. 1. Dans la liste des réserves de capacité, effectuez l'une des opérations suivantes : + Sélectionner le bouton en regard de la réserve, puis choisir **Annuler**. + Choisir le lien de réserve, puis choisir **Annuler la réserve de capacité**. 1. À l'invite **Annuler la réserve de capacité ?**, saisissez **Annuler**, puis choisissez **Annuler la réserve de capacité**. L'état de la réserve passe à **Annulation**, et une bannière de progression vous informe que l'annulation est en cours. Lorsque l'annulation est terminée, la réserve de capacité est maintenue, mais son état est **Annulé**. La réserve sera supprimée 45 jours après l'annulation. Pendant les 45 jours, vous ne pouvez pas réaffecter ou réutiliser la réserve annulée, mais vous pouvez vous référer à ses balises et consulter ses détails pour une référence historique. # Suppression d’une réserve de capacité Si vous souhaitez supprimer toutes les références à une réserve de capacité annulée, vous pouvez supprimer la réserve. La réserve doit être annulée avant de pouvoir être supprimée. Une réserve supprimée est immédiatement supprimée de votre compte et ne peut plus être référencée, y compris par son ARN. **Pour supprimer une réserve de capacité** 1. Ouvrez la console à l'adresse [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Si le panneau de navigation de la console n'est pas visible, choisissez le menu d'extension sur la gauche. 1. Choisissez **Administration**, **Réserves de capacité**. 1. Dans la liste des réserves de capacité, effectuez l'une des opérations suivantes : + Sélectionner le bouton en regard de la réserve annulée, puis choisir **Actions**, **Supprimer**. + Choisir le lien de la réserve, puis choisir **Supprimer**. 1. À l'invite **Supprimer la réserve de capacité ?**, choisissez **Supprimer**. Une bannière vous informe que la réserve de capacité a été supprimée avec succès. La réserve supprimée n'apparaît plus dans la liste des réserves de capacité. # Politiques IAM pour les réserves de capacité Pour contrôler l'accès aux réserves de capacité, utilisez des autorisations IAM au niveau des ressources ou des politiques IAM basées sur l'identité. Chaque fois que vous utilisez des politiques IAM, veillez à respecter les bonnes pratiques IAM. Pour plus d'informations, consultez la rubrique [Bonnes pratiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) du *Guide de l'utilisateur IAM*. La procédure suivante est spécifique à Athena. Pour des informations spécifiques à IAM, consultez les liens répertoriés à la fin de cette section. Pour de plus amples informations sur les politiques de réserve de capacité JSON, consultez [Exemples de politiques de réserve de capacité](example-policies-capacity-reservations.md). **Utilisation de l'éditeur visuel dans la console IAM pour créer une politique de réserve de capacité** 1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse. 1. Dans le panneau de navigation à gauche, choisissez **politiques**, puis **Créer une politique**. 1. Dans l'onglet **Visual editor** (Éditeur visuel), sélectionnez **Choose a service** (Choisir un service). Choisissez ensuite Athena pour l'ajouter à la politique. 1. Choisissez **Sélectionner des actions**, puis choisissez les actions à ajouter à la politique. L'éditeur visuel affiche les actions disponibles dans Athena. Pour plus d'informations, consultez la rubrique [Actions, ressources et clés de condition pour Amazon Athena](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonathena.html) dans la section *Référence de l'autorisation de service*. 1. Choisissez **Ajouter des actions** pour entrer une action spécifique ou utilisez des caractères génériques (\$1) pour spécifier plusieurs actions. Par défaut, la politique que vous créez autorise les actions que vous choisissez. Si vous avez choisi une ou plusieurs actions qui prennent en charge les autorisations au niveau des ressources pour la ressource `capacity-reservation` dans Athena, l'éditeur visuel affiche la ressource `capacity-reservation`. 1. Choisissez **Ressources** pour spécifier les réserves de capacité spécifiques de votre politique. Pour un exemple de politiques de réserve de capacité JSON, consultez [Exemples de politiques de réserve de capacité](example-policies-capacity-reservations.md). 1. Spécifiez la ressource du `capacity-reservation` comme suit : ``` arn:aws:athena:::capacity-reservation/ ``` 1. Choisissez **Review policy** (Examiner une politique), puis saisissez un **Name** (Nom) et une **Description** (facultatif) pour la politique que vous êtes en train de créer. Passez en revue le résumé de politique afin de vous assurer que les autorisations nécessaires vous ont été accordées. 1. Choisissez **Create policy** (Créer une politique) pour enregistrer votre nouvelle politique. 1. Attachez cette politique basée sur l'identité à un utilisateur, un groupe ou un rôle. Pour plus d'informations, consultez les rubriques suivantes dans la *Référence de l'autorisation de service* et le *Guide de l'utilisateur IAM* : + [Actions, ressources et clés de condition pour Amazon Athena](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonathena.html) + [Création de politiques avec l'éditeur visuel](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-visual-editor) + [Ajout et suppression de politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) + [Contrôle de l'accès aux ressources](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html#access_controlling-resources) Pour un exemple de politiques de réserve de capacité JSON, consultez [Exemples de politiques de réserve de capacité](example-policies-capacity-reservations.md). Pour obtenir une liste complète d'actions Amazon Athena, consultez les noms d'action d'API dans la [Référence d'API Amazon Athena](https://docs.aws.amazon.com/athena/latest/APIReference/). # Exemples de politiques de réserve de capacité Cette section inclut des exemples de politiques que vous pouvez utiliser pour activer plusieurs actions sur des réserves de capacité. Chaque fois que vous utilisez des politiques IAM, veillez à respecter les bonnes pratiques IAM. Pour plus d'informations, consultez la rubrique [Bonnes pratiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) du *Guide de l'utilisateur IAM*. Une réserve de capacité est une ressource IAM gérée par Athena. Par conséquent, si votre politique de réserve de capacité utilise des actions prenant `capacity-reservation` en entrée, vous devez spécifier l'ARN de la réserve de capacité comme suit : ``` "Resource": [arn:aws:athena:::capacity-reservation/] ``` Où `` est le nom de votre réserve de capacité. Par exemple, pour une réserve de capacité nommée `test_capacity_reservation`, spécifiez-la en tant que ressource comme suit : ``` "Resource": ["arn:aws:athena:us-east-1:123456789012:capacity-reservation/test_capacity_reservation"] ``` Pour obtenir une liste complète d'actions Amazon Athena, consultez les noms d'action d'API dans la [Référence d'API Amazon Athena](https://docs.aws.amazon.com/athena/latest/APIReference/). Pour plus d'informations sur les politiques IAM, consultez la rubrique [Création de politiques avec l'éditeur visuel](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-visual-editor) du *Guide de l'utilisateur IAM*. **Example Exemple de politique pour répertorier les réserves de capacité** La politique suivante permet à tous les utilisateurs de répertorier toutes les réserves de capacité. **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "athena:ListCapacityReservations" ], "Resource": "*" } ] } ``` **Example Exemple de politique pour les opérations de gestion** La politique suivante permet à un utilisateur de créer, d'annuler, d'obtenir des informations sur et de mettre à jour la réserve de capacité `test_capacity_reservation`. La politique permet également à un utilisateur d'attribuer les `workgroupA` et `workgroupB` à la `test_capacity_reservation`. **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect": "Allow", "Action": [ "athena:CreateCapacityReservation", "athena:GetCapacityReservation", "athena:CancelCapacityReservation", "athena:UpdateCapacityReservation", "athena:GetCapacityAssignmentConfiguration", "athena:PutCapacityAssignmentConfiguration" ], "Resource": [ "arn:aws:athena:us-east-1:123456789012:capacity-reservation/test_capacity_reservation", "arn:aws:athena:us-east-1:123456789012:workgroup/workgroupA", "arn:aws:athena:us-east-1:123456789012:workgroup/workgroupB" ] } ] } ``` # Réservation de capacité à Athena APIs La liste suivante contient des liens de référence vers les actions des API de réserve de capacité Athena. Pour les structures de données et les autres actions des API Athena, voir la [https://docs.aws.amazon.com/athena/latest/APIReference/](https://docs.aws.amazon.com/athena/latest/APIReference/). + [CancelCapacityReservation](https://docs.aws.amazon.com/athena/latest/APIReference/API_CancelCapacityReservation.html) + [CreateCapacityReservation](https://docs.aws.amazon.com/athena/latest/APIReference/API_CreateCapacityReservation.html) + [DeleteCapacityReservation](https://docs.aws.amazon.com/athena/latest/APIReference/API_DeleteCapacityReservation.html) + [GetCapacityAssignmentConfiguration](https://docs.aws.amazon.com/athena/latest/APIReference/API_GetCapacityAssignmentConfiguration.html) + [GetCapacityReservation](https://docs.aws.amazon.com/athena/latest/APIReference/API_GetCapacityReservation.html) + [ListCapacityReservations](https://docs.aws.amazon.com/athena/latest/APIReference/API_ListCapacityReservations.html) + [PutCapacityAssignmentConfiguration](https://docs.aws.amazon.com/athena/latest/APIReference/API_PutCapacityAssignmentConfiguration.html) + [UpdateCapacityReservation](https://docs.aws.amazon.com/athena/latest/APIReference/API_UpdateCapacityReservation.html) # Optimisation des performances d’Athena Cette rubrique fournit des informations générales et des suggestions spécifiques pour améliorer les performances de vos requêtes Athena, et explique comment contourner les erreurs liées aux limites et à l'utilisation des ressources. De manière générale, les optimisations peuvent être regroupées en catégories de services, de requêtes et de structures de données. Les décisions prises au niveau du service concernant l’écriture de vos requêtes et la structuration de vos données et de vos tables peuvent influencer sur les performances. **Topics** + [Optimisation de l’utilisation des services](performance-tuning-service-level-considerations.md) + [Optimisation des requêtes](performance-tuning-query-optimization-techniques.md) + [Optimisation des données](performance-tuning-data-optimization-techniques.md) + [Utilisation des formats de stockage en colonnes](columnar-storage.md) + [Utilisation du partitionnement et de la compartimentation](ctas-partitioning-and-bucketing.md) + [Partitionner vos données](partitions.md) + [Utilisation de la projection de partition avec Amazon Athena](partition-projection.md) + [Prévention de la limitation d’Amazon S3](performance-tuning-s3-throttling.md) + [Ressources supplémentaires](performance-tuning-additional-resources.md) # Optimisation de l’utilisation des services Les éléments pris en compte au niveau des services concernant le nombre de charges de travail exécutées par compte, les quotas de service pour Athena et pour l’ensemble des services et la réduction des erreurs liées au manque de ressources. **Topics** + [Exécution de plusieurs charges de travail dans le même compte](#performance-tuning-service-quotas) + [Réduction des erreurs liées au manque de ressources](#performance-tuning-resource-limits) ## Exécution de plusieurs charges de travail dans le même compte Athena utilise des quotas pour limiter la simultanéité des requêtes et les taux de demandes d’API au niveau du compte. Le dépassement de ces quotas peut entraîner l’échec des requêtes exécutées ou soumises. Pour de plus amples informations sur ces quotas, consultez [Service Quotas](service-limits.md). Si vous gérez plusieurs charges de travail au sein d'un même AWS compte, elles se disputent le même quota au niveau du compte. Par exemple, si une charge de travail fait l’objet d’une rafale inattendue de requêtes, une autre charge de travail exécutée sur le même compte peut être confrontée à un temps d’attente élevé, voire à des échecs de soumission de requêtes en raison de la limitation. Nous vous recommandons de suivre l'utilisation CloudWatch de vos services à l'aide de graphiques et de tableaux de bord. Vous pouvez également configurer des CloudWatch alarmes qui vous alertent lorsque votre utilisation approche le quota de service pour les requêtes simultanées, ce qui vous permet de prendre des mesures avant d'atteindre les limites de quota. Pour de plus amples informations, veuillez consulter [Surveillez les statistiques d'utilisation d'Athena avec CloudWatch](monitoring-athena-usage-metrics.md). Utilisez des réserves de capacité pour contrôler la simultanéité des requêtes et pour isoler les charges de travail au sein de votre compte. Les réserves de capacité fournissent une capacité de traitement des requêtes dédiée au sein d’un compte. La capacité est mesurée en unités de traitement des données (DPUs) et peut être ajoutée ou supprimée pour augmenter ou diminuer la simultanéité des requêtes, respectivement. Les réserves de capacité vous permettent d’isoler les charges de travail de votre compte les unes des autres en attribuant des capacités à un ou plusieurs groupes de travail. Pour de plus amples informations, veuillez consulter [Gestion de la capacité de traitement des requêtes](capacity-management.md). Bien que vous deviez isoler les charges de travail indépendantes dans différents AWS comptes (par exemple en isolant les environnements de développement des environnements de production), cette approche ne constitue pas un moyen évolutif d'augmenter la simultanéité des requêtes. Utilisez plutôt les réserves de capacité pour gérer vos besoins en matière de traitement des requêtes et les mettre à l’échelle au sein d’un compte. ### Quotas d’autres services Lorsqu'Athena exécute une requête, il peut appeler d'autres services qui appliquent des quotas. Pendant l'exécution des requêtes, Athena peut effectuer des appels d'API vers Amazon S3 et d'autres AWS services tels que IAM et. AWS Glue Data Catalog AWS KMS Si vous utilisez des [requêtes fédérées](federated-queries.md), Athena appelle également. AWS Lambda Tous ces services ont leurs propres limites et quotas qui peuvent être dépassés. Lorsque l'exécution d'une requête rencontre des erreurs provenant de ces services, elle échoue et inclut l'erreur provenant du service source. Les erreurs récupérables font l'objet de nouvelles tentatives, mais les requêtes peuvent toujours échouer si le problème ne se résout pas de lui-même à temps. Assurez-vous de lire attentivement les messages d'erreur afin de déterminer s'ils proviennent d'Athena ou d'un autre service. Certaines erreurs pertinentes sont abordées dans cette section consacrée à l’optimisation des performances. Pour plus d'informations sur la manière de contourner les erreurs causées par les Service Quotas d'Amazon S3, consultez [Éviter d'avoir trop de fichiers](performance-tuning-data-optimization-techniques.md#performance-tuning-avoid-having-too-many-files) ultérieurement dans ce document. Pour de plus amples informations sur l'optimisation des performances Amazon S3, consultez [Schémas de conception des bonnes pratiques : optimisation des performances Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html) dans le *Guide de l'utilisateur Amazon S3*. ## Réduction des erreurs liées au manque de ressources Athena exécute des requêtes dans un moteur de requête distribué. Lorsque vous soumettez une requête, le planificateur de requêtes du moteur Athena estime la capacité de calcul requise pour exécuter la requête et prépare un cluster de nœuds de calcul en conséquence. Certaines requêtes, telles que les requêtes DDL, ne s'exécutent que sur un seul nœud. Les requêtes complexes portant sur des jeux de données volumineux s'exécutent sur des clusters beaucoup plus importants. Les nœuds sont uniformes, avec les mêmes configurations de mémoire, d'UC et de disque. Athena monte en puissance, mais n'augmente pas en capacité, pour traiter des requêtes plus exigeantes. Parfois, les exigences d'une requête dépassent les ressources disponibles pour le cluster exécutant la requête. Dans ce cas, la requête échoue avec le message d'erreur La requête a épuisé les ressources à ce facteur d'échelle. La ressource la plus souvent épuisée est la mémoire, mais dans de rares cas, il peut également s'agir d'espace disque. Les erreurs de mémoire se produisent généralement lorsque le moteur exécute une fonction de jointure ou de fenêtrage, mais elles peuvent également se produire lors de comptages et d'agrégations distincts. Même si une requête échoue une fois avec une erreur « manque de ressources », elle peut réussir lorsque vous l'exécutez à nouveau. L'exécution des requêtes n'est pas déterministe. Des facteurs tels que le temps nécessaire au chargement des données et la manière dont les jeux de données intermédiaires sont répartis sur les nœuds peuvent entraîner une utilisation différente des ressources. Par exemple, imaginez une requête qui joint deux tables et dont la distribution des valeurs pour la condition de jointure est fortement asymétrique. Une telle requête peut réussir la plupart du temps, mais échouer parfois lorsque les valeurs les plus courantes finissent par être traitées par le même nœud. Pour éviter que vos requêtes n'excèdent les ressources disponibles, suivez les conseils de réglage des performances mentionnés dans ce document. En particulier, pour obtenir des conseils sur la manière d'optimiser les requêtes qui épuisent les ressources disponibles, consultez [Optimisation des jointures](performance-tuning-query-optimization-techniques.md#performance-tuning-optimizing-joins), [Réduction de la portée des fonctions de fenêtrage ou suppression de ces fonctions](performance-tuning-query-optimization-techniques.md#performance-tuning-optimizing-window-functions) et [Optimisation des requêtes à l’aide d’approximations](performance-tuning-query-optimization-techniques.md#performance-tuning-optimizing-queries-by-using-approximations). # Optimisation des requêtes Utilisez les techniques d'optimisation des requêtes décrites dans cette section pour accélérer l'exécution des requêtes ou pour contourner les requêtes qui dépassent les limites de ressources dans Athena. ## Optimisation des jointures Il existe de nombreuses stratégies différentes pour exécuter des jointures dans un moteur de requête distribué. Les deux plus courantes sont les jointures par hachage distribuées et les requêtes comportant des conditions de jointure complexes. ### Positionnement des grandes tables à gauche et des petites tables à droite dans une jointure de hachage distribuée Le type de jointure le plus courant utilise une comparaison d'égalité comme condition de jointure. Athena exécute ce type de jointure en tant que jointure par hachage distribuée. Dans une jointure par hachage distribuée, le moteur crée une table de recherche (table de hachage) à partir de l'un des côtés de la jointure. Ce côté est appelé *côté build*. Les enregistrements du côté build sont répartis entre les nœuds. Chaque nœud crée une table de recherche pour son sous-ensemble. L'autre côté de la jointure, appelé *côté sonde*, est ensuite diffusé via les nœuds. Les enregistrements du côté sonde sont répartis sur les nœuds de la même manière que du côté build. Cela permet à chaque nœud d'effectuer la jointure en recherchant les enregistrements correspondants dans sa propre table de recherche. Lorsque les tables de recherche créées à partir du côté build de la jointure ne rentrent pas dans la mémoire, les requêtes peuvent échouer. Même si la taille totale du côté build est inférieure à la mémoire disponible, les requêtes peuvent échouer si la répartition des enregistrements présente une asymétrie importante. Dans un cas extrême, tous les enregistrements peuvent avoir la même valeur pour la condition de jointure et doivent être conservés en mémoire sur un seul nœud. Même une requête moins asymétrique peut échouer si un ensemble de valeurs est envoyé au même nœud et que le total des valeurs dépasse la mémoire disponible. Les nœuds ont la capacité de répartir des enregistrements sur le disque, mais le déversement ralentit l'exécution des requêtes et peut s'avérer insuffisant pour empêcher l'échec de la requête. Athena tente de réorganiser les jointures pour utiliser la relation la plus grande comme côté sonde, et la plus petite relation comme côté build. Cependant, comme Athena ne gère pas les données contenues dans les tables, il dispose de peu d'informations et doit souvent partir du principe que la première table est la plus grande et la seconde la plus petite. Lorsque vous écrivez des jointures avec des conditions de jointure basées sur l'égalité, supposez que la table située à gauche du mot-clé `JOIN` correspond au côté sonde et que la table de droite correspond au côté build. Assurez-vous que la bonne table, le côté build, est la plus petite des tables. S'il n'est pas possible de réduire le côté build de la jointure suffisamment pour tenir en mémoire, envisagez d'exécuter plusieurs requêtes qui joignent des sous-ensembles de la table de build. ### Analyse des requêtes contenant des jointures complexes à l’aide d’EXPLAIN Les requêtes comportant des conditions de jointure complexes (par exemple, les requêtes qui utilisent des opérateurs `LIKE`, `>` ou autres) sont souvent exigeantes en termes de calcul. Dans le pire des cas, chaque enregistrement d'un côté de la jointure doit être comparé à tous les enregistrements de l'autre côté de la jointure. Comme la durée d'exécution augmente avec le carré du nombre d'enregistrements, ces requêtes risquent de dépasser la durée d'exécution maximale. Pour savoir à l'avance comment Athena exécutera votre requête, vous pouvez utiliser l'instruction `EXPLAIN`. Pour plus d’informations, consultez [Utilisation de EXPLAIN et EXPLAIN ANALYZE sur Athena](athena-explain-statement.md) et [Présentation des résultats de l’instruction EXPLAIN d’Athena](athena-explain-statement-understanding.md). ## Réduction de la portée des fonctions de fenêtrage ou suppression de ces fonctions Les fonctions de fenêtrage étant des opérations gourmandes en ressources, elles peuvent ralentir ou même faire échouer les requêtes avec le message La requête a épuisé les ressources à ce facteur d'échelle. Les fonctions de fenêtrage conservent en mémoire tous les enregistrements sur lesquels elles opèrent afin de calculer leur résultat. Lorsque la fenêtre est très grande, la fonction de fenêtrage peut manquer de mémoire. Pour vous assurer que vos requêtes s'exécutent dans les limites de mémoire disponibles, réduisez la taille des fenêtres sur lesquelles vos fonctions de fenêtrage opèrent. Pour ce faire, vous pouvez ajouter une clause `PARTITIONED BY` ou réduire la portée des clauses de partitionnement existantes. ### Utilisation de fonctions autres que les fonctions de fenêtrage Parfois, les requêtes comportant des fonctions de fenêtrage peuvent être réécrites sans fonctions de fenêtrage. Par exemple, au lieu d'utiliser `row_number` pour rechercher les meilleurs enregistrements `N`, vous pouvez utiliser `ORDER BY` et `LIMIT`. Au lieu d'utiliser `row_number` ou `rank` pour dédupliquer des enregistrements, vous pouvez utiliser des fonctions d'agrégation telles que [max\$1by](https://trino.io/docs/current/functions/aggregate.html#max_by), [min\$1by](https://trino.io/docs/current/functions/aggregate.html#min_by) et [arbitrary](https://trino.io/docs/current/functions/aggregate.html#arbitrary). Supposons, par exemple, que vous disposiez d'un jeu de données actualisé par un capteur. Le capteur indique régulièrement l'état de la batterie et inclut certaines métadonnées, telles que l'emplacement. Si vous souhaitez connaître le dernier état de la batterie de chaque capteur et son emplacement, vous pouvez utiliser cette requête : ``` SELECT sensor_id, arbitrary(location) AS location, max_by(battery_status, updated_at) AS battery_status FROM sensor_readings GROUP BY sensor_id ``` Les métadonnées telles que l'emplacement étant les mêmes pour chaque enregistrement, vous pouvez utiliser la fonction `arbitrary` pour sélectionner n'importe quelle valeur dans le groupe. Pour connaître le dernier état de la batterie, vous pouvez utiliser la fonction `max_by`. La fonction `max_by` sélectionne la valeur d'une colonne dans l'enregistrement où la valeur maximale d'une autre colonne a été trouvée. Dans ce cas, il renvoie l'état de la batterie de l'enregistrement avec l'heure de la dernière mise à jour au sein du groupe. Cette requête s'exécute plus rapidement et utilise moins de mémoire qu'une requête équivalente dotée d'une fonction de fenêtrage. ## Optimisation des agrégations Lorsqu'Athena effectue une agrégation, il répartit les enregistrements entre les composants master en utilisant les colonnes de la clause `GROUP BY`. Pour que la tâche de mise en correspondance des enregistrements avec des groupes soit aussi efficace que possible, les nœuds tentent de conserver les enregistrements en mémoire mais les déversent sur le disque si nécessaire. Il est également conseillé d'éviter d'inclure des colonnes redondantes dans les clauses `GROUP BY`. Le nombre réduit de colonnes nécessitant moins de mémoire, une requête décrivant un groupe utilisant moins de colonnes est plus efficace. Les colonnes numériques utilisent également moins de mémoire que les chaînes. Par exemple, lorsque vous agrégez un jeu de données qui possède à la fois un ID de catégorie numérique et un nom de catégorie, utilisez uniquement la colonne ID de catégorie dans la clause `GROUP BY`. Parfois, les requêtes incluent des colonnes dans la clause `GROUP BY` pour contourner le fait qu'une colonne doit faire partie de la clause `GROUP BY` ou d'une expression agrégée. Si cette règle n'est pas respectée, vous pouvez recevoir un message d'erreur du type suivant : EXPRESSION\$1NOT\$1AGGREGATE : ligne 1:8 : « catégorie » doit être une expression agrégée ou apparaître dans la clause GROUP BY Pour éviter d'avoir à ajouter des colonnes redondantes à la clause `GROUP BY`, vous pouvez utiliser la fonction [ARBITRARY](https://trino.io/docs/current/functions/aggregate.html#arbitrary), comme dans l'exemple suivant. ``` SELECT country_id, arbitrary(country_name) AS country_name, COUNT(*) AS city_count FROM world_cities GROUP BY country_id ``` La fonction `ARBITRARY` renvoie une valeur arbitraire à partir du groupe. La fonction est utile lorsque vous savez que tous les enregistrements du groupe ont la même valeur pour une colonne, mais que cette valeur n'identifie pas le groupe. ## Optimisation des N requêtes principales La clause `ORDER BY` renvoie les résultats d'une requête dans un ordre trié. Athena utilise le tri distribué pour exécuter l'opération de tri en parallèle sur plusieurs nœuds. Si vous n'avez pas strictement besoin que votre résultat soit trié, évitez d'ajouter une clause `ORDER BY`. Évitez également d'ajouter des clauses `ORDER BY` à des requêtes internes si elles ne sont pas strictement nécessaires. Dans de nombreux cas, le planificateur de requêtes peut supprimer le tri redondant, mais cela n'est pas garanti. Il existe une exception à cette règle si une requête interne effectue une opération Top `N`, telle que la recherche des valeurs `N` les plus récentes ou `N` les plus courantes. Quand Athena voit `ORDER BY` en même temps que `LIMIT`, il comprend que vous exécutez une requête Top `N` et utilise des opérations dédiées en conséquence. **Note** Bien qu'Athena puisse également souvent détecter des fonctions de fenêtrage telles `row_number` qui utilisent `N` principal, nous recommandons la version plus simple qui utilise `ORDER BY` et `LIMIT`. Pour de plus amples informations, veuillez consulter [Réduction de la portée des fonctions de fenêtrage ou suppression de ces fonctions](#performance-tuning-optimizing-window-functions). ## Inclure uniquement les colonnes obligatoires Si vous n'avez pas strictement besoin d'une colonne, ne l'incluez pas dans votre requête. Moins une requête doit traiter de données, plus elle sera exécutée rapidement. Cela réduit à la fois la quantité de mémoire requise et la quantité de données à envoyer entre les nœuds. Si vous utilisez un format de fichier en colonnes, la réduction du nombre de colonnes réduit également la quantité de données lues à partir d'Amazon S3. Athena n'impose aucune limite spécifique quant au nombre de colonnes dans un résultat, mais la manière dont les requêtes sont exécutées limite la taille combinée possible des colonnes. La taille combinée des colonnes inclut leur nom et leur type. Par exemple, l'erreur suivante est due à une relation qui dépasse la limite de taille d'un descripteur de relation : ERREUR INTERNE GÉNÉRIQUE : io.airlift.bytecode. CompilationException Pour contourner ce problème, réduisez le nombre de colonnes dans la requête ou créez des sous-requêtes et utilisez une commande `JOIN` qui récupère une plus petite quantité de données. Si vous avez des requêtes effectuant `SELECT *` dans la requête la plus externe, vous devez remplacer l'`*` par une liste contenant uniquement les colonnes dont vous avez besoin. ## Optimisation des requêtes à l’aide d’approximations Athena prend en charge les [fonctions d'agrégation d'approximations](https://trino.io/docs/current/functions/aggregate.html#appro) pour compter les valeurs distinctes, les valeurs les plus fréquentes, les percentiles (y compris les médianes approximatives) et créer des histogrammes. Utilisez ces fonctions chaque fois que des valeurs exactes ne sont pas nécessaires. Contrairement aux opérations `COUNT(DISTINCT col)`, [approx\$1distinct](https://trino.io/docs/current/functions/aggregate.html#approx_distinct) utilise beaucoup moins de mémoire et s'exécute plus rapidement. De même, l'utilisation de [numeric\$1histogram](https://trino.io/docs/current/functions/aggregate.html#numeric_histogram) au lieu de [histogram](https://trino.io/docs/current/functions/aggregate.html#histogram) utilise des méthodes approximatives et donc moins de mémoire. ## Optimisation de LIKE Vous pouvez utiliser `LIKE` pour trouver des chaînes correspondantes, mais avec de longues chaînes, cela demande beaucoup de calcul. La fonction [regexp\$1like](https://trino.io/docs/current/functions/regexp.html#regexp_like) est dans la plupart des cas une alternative plus rapide et offre également plus de flexibilité. Vous pouvez souvent optimiser une recherche en ancrant la sous-chaîne que vous recherchez. Par exemple, si vous recherchez un préfixe, il est préférable d'utiliser « *substr* % » au lieu de « *substr* % % ». Ou, si vous utilisez `regexp_like` « ^ *substr* ». ## Utiliser UNION ALL au lieu de UNION `UNION ALL` et `UNION` sont deux manières de combiner les résultats de deux requêtes en un seul résultat. `UNION ALL` concatène les enregistrements de la première requête avec la seconde, et `UNION` fait de même, mais supprime également les doublons. `UNION` doit traiter tous les enregistrements et trouver les doublons, ce qui demande beaucoup de mémoire et de calcul, mais `UNION ALL` est une opération relativement rapide. À moins que vous n'ayez besoin de dédupliquer des enregistrements, utilisez `UNION ALL` pour de meilleures performances. ## Utiliser UNLOAD pour les grands ensembles de résultats Lorsque les résultats d'une requête sont censés être volumineux (par exemple, des dizaines de milliers de lignes ou plus), utilisez UNLOAD pour exporter les résultats. Dans la plupart des cas, cela est plus rapide que l'exécution d'une requête normale, et l'utilisation de `UNLOAD` vous permet également de mieux contrôler le résultat. Lorsque l'exécution d'une requête est terminée, Athena stocke le résultat sous la forme d'un seul fichier CSV non compressé sur Amazon S3. Cela prend plus de temps que `UNLOAD`, non seulement parce que le résultat n'est pas compressé, mais également parce que l'opération ne peut pas être parallélisée. En revanche, `UNLOAD` écrit les résultats directement à partir des composants master et utilise pleinement le parallélisme du cluster de calcul. En outre, vous pouvez configurer `UNLOAD` pour écrire les résultats au format compressé et dans d'autres formats de fichier tels que JSON et Parquet. Pour de plus amples informations, veuillez consulter [UNLOAD](unload.md). ## Utiliser CTAS ou ETL Glue pour matérialiser les agrégations fréquemment utilisées La « matérialisation » d'une requête est un moyen d'accélérer les performances des requêtes en stockant des résultats de requêtes complexes précalculés (par exemple, des agrégations et des jointures) pour les réutiliser dans les requêtes suivantes. Si bon nombre de vos requêtes incluent les mêmes jointures et agrégations, vous pouvez matérialiser la sous-requête commune sous la forme d'une nouvelle table, puis exécuter des requêtes sur cette table. Vous pouvez créer la nouvelle table avec [Création d’une table à partir des résultats des requêtes (CTAS)](ctas.md) ou un outil ETL dédié tel que [ETL Glue](https://aws.amazon.com/glue). Supposons, par exemple, que vous disposiez d'un tableau de bord comprenant des widgets qui présentent différents aspects d'un jeu de données de commandes. Chaque widget possède sa propre requête, mais les requêtes partagent toutes les mêmes jointures et filtres. Une table des commandes est jointe à une table des articles, et un filtre permet de n'afficher que les trois derniers mois. Si vous identifiez les caractéristiques communes de ces requêtes, vous pouvez créer une nouvelle table que les widgets pourront utiliser. Cela réduit les doublons et améliore les performances. L'inconvénient est que vous devez maintenir la nouvelle table à jour. ## Réutiliser les résultats des requêtes Il est courant qu'une même requête soit exécutée plusieurs fois dans un court laps de temps. Cela peut se produire, par exemple, lorsque plusieurs personnes ouvrent le même tableau de bord de données. Lorsque vous exécutez une requête, vous pouvez demander à Athena de réutiliser les résultats précédemment calculés. Vous spécifiez l'âge maximal des résultats à réutiliser. Si la même requête a déjà été exécutée pendant cette période, Athena renvoie ces résultats au lieu de réexécuter la requête. Pour plus d'informations, consultez [Réutilisation des résultats des requêtes dans Athena](reusing-query-results.md) ici dans le *Guide de l'utilisateur Amazon Athena* et [Réduction des coûts et amélioration des performances des requêtes grâce à la réutilisation des résultats des requêtes Amazon Athena](https://aws.amazon.com/blogs/big-data/reduce-cost-and-improve-query-performance-with-amazon-athena-query-result-reuse/) sur le *blog AWS Big Data*. # Optimisation des données Les performances dépendent non seulement des requêtes, mais aussi et surtout de la manière dont votre jeu de données est organisé, ainsi que du format de fichier et de la compression qu'il utilise. ## Partitionner vos données Le partitionnement divise votre table en plusieurs parties et conserve les données associées en fonction de propriétés telles que la date, le pays ou la région. Les clés de partition agissent comme des colonnes virtuelles. Vous définissez les clés de partition lors de la création de la table et vous les utilisez pour filtrer vos requêtes. Lorsque vous filtrez sur les colonnes de clés de partition, seules les données des partitions correspondantes sont lues. Par exemple, si votre jeu de données est partitionné par date et que votre requête comporte un filtre qui ne correspond qu'à la semaine dernière, seules les données de la dernière semaine sont lues. Pour plus d'informations sur le partitionnement, consultez [Partitionner vos données](partitions.md). ## Sélectionner les clés de partition qui répondront à vos requêtes Le partitionnement ayant un impact significatif sur les performances des requêtes, veillez à bien réfléchir à la manière dont vous partitionnez lorsque vous concevez votre jeu de données et vos tables. Un trop grand nombre de clés de partition peut entraîner la fragmentation des jeux de données contenant trop de fichiers et des fichiers trop petits. À l'inverse, le fait d'avoir trop peu de clés de partition ou de ne pas partitionner du tout, entraîne des requêtes qui analysent plus de données que nécessaire. ### Éviter l'optimisation des requêtes rares Une bonne stratégie consiste à optimiser pur les requêtes les plus courantes et à éviter d'optimiser les requêtes rares. Par exemple, si vos requêtes portent sur des périodes de plusieurs jours, ne partitionnez pas par heure, même si certaines requêtes filtrent à ce niveau. Si vos données comportent une colonne d'horodatage précise, les rares requêtes filtrées par heure peuvent utiliser la colonne d'horodatage. Même si de rares cas analysent un peu plus de données que nécessaire, réduire les performances globales au profit de cas rares ne constitue généralement pas un bon compromis. Pour réduire la quantité de données que les requêtes doivent analyser et améliorer ainsi les performances, utilisez un format de fichier en colonnes et triez les enregistrements. Au lieu de partitionner par heure, gardez les enregistrements triés par horodatage. Pour les requêtes portant sur des fenêtres temporelles plus courtes, le tri par horodatage est presque aussi efficace que le partitionnement par heure. En outre, le tri par horodatage ne nuit généralement pas aux performances des requêtes sur des fenêtres temporelles comptées en jours. Pour de plus amples informations, veuillez consulter [Utiliser les formats de fichier en colonnes](#performance-tuning-use-columnar-file-formats). Notez que les requêtes sur des tables contenant des dizaines de milliers de partitions sont plus performantes si toutes les clés de partition comportent des prédicats. C'est une autre raison de concevoir votre schéma de partitionnement pour les requêtes les plus courantes. Pour de plus amples informations, veuillez consulter [Interroger les partitions par égalité](#performance-tuning-query-partitions-by-equality). ## Utiliser la projection de partition La projection de partition est une fonctionnalité d'Athena qui stocke les informations de partition non pas dans le AWS Glue Data Catalog, mais sous forme de règles dans les propriétés de la table dans. AWS Glue Lorsqu'Athena planifie une requête sur une table configurée avec une projection de partition, il lit les règles de projection de partition de la table. Athena calcule les partitions à lire en mémoire en fonction de la requête et des règles au lieu de rechercher des partitions dans le AWS Glue Data Catalog. Outre la simplification de la gestion des partitions, la projection de partition peut améliorer les performances des jeux de données comportant un grand nombre de partitions. Lorsqu'une requête inclut des plages au lieu de valeurs spécifiques pour les clés de partition, la durée de la recherche des partitions correspondantes dans le catalogue est fonction du nombre de partitions. Avec la projection de partition, le filtre peut être calculé en mémoire sans passer par le catalogue, et cela peut être beaucoup plus rapide. Dans certaines circonstances, la projection de partition peut entraîner une baisse des performances. Un exemple se produit lorsqu'une table est « fragmentée ». Une table fragmentée ne contient pas de données pour chaque permutation des valeurs de clé de partition décrite par la configuration de projection de partition. Avec une table fragmentée, l'ensemble de partitions calculé à partir de la requête et la configuration de projection de partition sont tous répertoriés sur Amazon S3, même s'ils ne contiennent aucune donnée. Lorsque vous utilisez la projection de partition, veillez à inclure des prédicats sur toutes les clés de partition. Restreignez la portée des valeurs possibles pour éviter des listes inutiles sur Amazon S3. Imaginez une clé de partition comportant une plage d'un million de valeurs et une requête sans filtre sur cette clé de partition. Pour exécuter la requête, Athena doit effectuer au moins un million d'opérations de liste Amazon S3. Les requêtes sont plus rapides lorsque vous interrogez des valeurs spécifiques, que vous utilisiez la projection de partition ou que vous stockiez les informations de partition dans le catalogue. Pour de plus amples informations, veuillez consulter [Interroger les partitions par égalité](#performance-tuning-query-partitions-by-equality). Lorsque vous configurez une table pour la projection de partition, assurez-vous que les plages que vous spécifiez sont raisonnables. Si une requête n'inclut pas de prédicat sur une clé de partition, toutes les valeurs de la plage correspondant à cette clé sont utilisées. Si votre jeu de données a été créé à une date précise, utilisez cette date comme point de départ pour toutes les plages de dates. Utiliser `NOW` comme fin des plages de dates. Évitez les plages numériques contenant un grand nombre de valeurs et envisagez plutôt d'utiliser le type [injecté](partition-projection-dynamic-id-partitioning.md#partition-projection-injection). Pour plus d'informations sur la projection de partition, voir [Utilisation de la projection de partition avec Amazon Athena](partition-projection.md). ## Utiliser les index de partition Les index de partition sont une fonctionnalité du AWS Glue Data Catalog qui améliore les performances de recherche de partitions pour les tables contenant un grand nombre de partitions. La liste des partitions du catalogue est similaire à une table dans une base de données relationnelle. La table comporte des colonnes pour les clés de partition et une colonne supplémentaire pour l'emplacement de la partition. Lorsque vous interrogez une table partitionnée, les emplacements des partitions sont recherchés en analysant cette table. Tout comme pour les bases de données relationnelles, vous pouvez améliorer les performances des requêtes en ajoutant des index. Vous pouvez ajouter plusieurs index pour prendre en charge différents modèles de requêtes. L'index de AWS Glue Data Catalog partition prend en charge à la fois les opérateurs d'égalité et de comparaison tels que `>``>=`, et `<` combinés avec l'`AND`opérateur. Pour plus d'informations, consultez les [sections Utilisation des index de partition AWS Glue dans](https://docs.aws.amazon.com/glue/latest/dg/partition-indexes.html) le *guide du AWS Glue développeur* et [amélioration des performances des requêtes Amazon Athena à AWS Glue Data Catalog l'aide d'index de partition](https://aws.amazon.com/blogs/big-data/improve-amazon-athena-query-performance-using-aws-glue-data-catalog-partition-indexes/) dans *AWS le* blog Big Data. ## Toujours utiliser STRING comme type pour les clés de partition Lorsque vous interrogez les clés de partition, n'oubliez pas qu'Athena exige que les clés de partition soient de type `STRING` afin de pousser vers le bas le filtrage des partitions dans AWS Glue. Si le nombre de partitions n'est pas faible, l'utilisation d'autres types peut entraîner une baisse des performances. Si les valeurs de vos clés de partition sont de type date ou numérique, convertissez-les dans le type approprié dans votre requête. ## Supprimer les partitions anciennes et vides Si vous supprimez des données d'une partition sur Amazon S3 (par exemple, en utilisant le [cycle de vie](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html) d'Amazon S3), vous devez également supprimer l'entrée de partition du AWS Glue Data Catalog. Lors de la planification des requêtes, toute partition correspondant à la requête est répertoriée sur Amazon S3. Si vous avez de nombreuses partitions vides, la surcharge liée à la liste de ces partitions peut être préjudiciable. De même, si vous avez plusieurs milliers de partitions, pensez à supprimer les métadonnées de partition pour les anciennes données qui ne sont plus pertinentes. Par exemple, si les requêtes ne portent jamais sur des données datant de plus d'un an, vous pouvez régulièrement supprimer les métadonnées des partitions les plus anciennes. Si le nombre de partitions atteint des dizaines de milliers, la suppression des partitions inutilisées peut accélérer les requêtes qui n'incluent pas de prédicats sur toutes les clés de partition. Pour plus d'informations sur l'inclusion de prédicats sur toutes les clés de partition dans vos requêtes, consultez [Interroger les partitions par égalité](#performance-tuning-query-partitions-by-equality). ## Interroger les partitions par égalité Les requêtes qui incluent des prédicats d'égalité sur toutes les clés de partition s'exécutent plus rapidement, car les métadonnées de partition peuvent être chargées directement. Évitez les requêtes dans lesquelles une ou plusieurs clés de partition n'ont pas de prédicat ou dans lesquelles le prédicat sélectionne une plage de valeurs. Pour de telles requêtes, la liste de toutes les partitions doit être filtrée pour trouver les valeurs correspondantes. Pour la plupart des tables, la surcharge est minime, mais pour les tables comportant des dizaines de milliers de partitions ou plus, elle peut devenir importante. S'il n'est pas possible de réécrire vos requêtes pour filtrer les partitions par égalité, vous pouvez essayer la projection de partition. Pour de plus amples informations, veuillez consulter [Utiliser la projection de partition](#performance-tuning-use-partition-projection). ## Éviter d'utiliser MSCK REPAIR TABLE pour la maintenance des partitions Étant donné que l'exécution de `MSCK REPAIR TABLE` peut prendre du temps, qu'elle ajoute uniquement de nouvelles partitions et qu'elle ne supprime pas les anciennes partitions, ce n'est pas une méthode efficace pour gérer les partitions (voir [Considérations et restrictions](msck-repair-table.md#msck-repair-table-considerations)). Il est préférable de gérer les partitions manuellement à l'aide des [AWS Glue robots d'exploration [AWS Glue Data Catalog APIs](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-catalog.html)[ALTER TABLE ADD PARTITION](alter-table-add-partition.md)](https://docs.aws.amazon.com/glue/latest/dg/crawler-running.html), ou. Vous pouvez également utiliser la projection de partition, qui élimine complètement le besoin de gérer les partitions. Pour de plus amples informations, veuillez consulter [Utilisation de la projection de partition avec Amazon Athena](partition-projection.md). ## Vérifiez que vos requêtes sont compatibles avec le schéma de partitionnement Vous pouvez vérifier à l'avance les partitions qu'une requête analysera à l'aide de l'instruction [`EXPLAIN`](athena-explain-statement.md). Préfixez votre requête avec le mot-clé `EXPLAIN`, puis recherchez le fragment source (par exemple,`Fragment 2 [SOURCE]`) pour chaque table en bas de du résultat `EXPLAIN`. Recherchez les affectations dont la partie droite est définie comme clé de partition. La ligne ci-dessous inclut une liste de toutes les valeurs de cette clé de partition qui seront analysées lors de l'exécution de la requête. Supposons, par exemple, que vous ayez une requête sur une table contenant une clé de partition `dt` et que vous la préfixiez avec `EXPLAIN`. Si les valeurs de la requête sont des dates et qu'un filtre sélectionne une plage de trois jours, le résultat `EXPLAIN` peut ressembler à ceci : ``` dt := dt:string:PARTITION_KEY :: [[2023-06-11], [2023-06-12], [2023-06-13]] ``` Le résultat `EXPLAIN` indique que le planificateur a trouvé trois valeurs pour cette clé de partition correspondant à la requête. Il vous indique également quelles sont ces valeurs. Pour plus d'informations sur l'utilisation de `EXPLAIN` et de [Utilisation de EXPLAIN et EXPLAIN ANALYZE sur Athena](athena-explain-statement.md), consultez [Présentation des résultats de l’instruction EXPLAIN d’Athena](athena-explain-statement-understanding.md). ## Utiliser les formats de fichier en colonnes Les formats de fichiers en colonnes tels que Parquet et ORC sont conçus pour les charges de travail d'analyse distribuées. Ils organisent les données par colonne plutôt que par ligne. L'organisation des données sous forme de colonnes présente les avantages suivants : + Seules les colonnes nécessaires à la requête sont chargées + La quantité globale de données à charger est réduite + Les valeurs des colonnes sont stockées ensemble, de sorte que les données peuvent être compressées efficacement + Les fichiers peuvent contenir des métadonnées qui permettent au moteur d'éviter de charger des données inutiles À titre d'exemple de la manière dont les métadonnées des fichiers peuvent être utilisées, les métadonnées des fichiers peuvent contenir des informations sur les valeurs minimales et maximales d'une page de données. Si les valeurs demandées ne se situent pas dans la plage indiquée dans les métadonnées, la page peut être ignorée. L'un des moyens d'utiliser ces métadonnées pour améliorer les performances consiste à s'assurer que les données contenues dans les fichiers sont triées. Supposons, par exemple, que vous ayez des requêtes qui recherchent des enregistrements dont l'entrée `created_at` se trouve dans un court laps de temps. Si vos données sont triées par colonne `created_at`, Athena peut utiliser les valeurs minimale et maximale des métadonnées des fichiers pour ignorer les parties inutiles des fichiers de données. Lorsque vous utilisez des formats de fichier en colonnes, assurez-vous que vos fichiers ne sont pas trop petits. Comme indiqué dans [Éviter d'avoir trop de fichiers](#performance-tuning-avoid-having-too-many-files), les jeux de données contenant de nombreux petits fichiers entraînent des problèmes de performances. Cela est particulièrement vrai pour les formats de fichiers en colonnes. Pour les petits fichiers, la surcharge du format de fichier en colonnes l'emporte sur les avantages. Notez que Parquet et ORC sont organisés en interne par groupes de lignes (Parquet) et de bandes (ORC). La taille par défaut pour les groupes de lignes est de 128 Mo et pour les bandes, de 64 Mo. Si vous avez de nombreuses colonnes, vous pouvez augmenter la taille des groupes de lignes et des bandes pour de meilleures performances. Il n'est pas recommandé de réduire la taille des groupes de lignes ou des bandes à une valeur inférieure à leurs valeurs par défaut. Pour convertir d'autres formats de données en Parquet ou ORC, vous pouvez utiliser AWS Glue ETL ou Athena. Pour de plus amples informations, veuillez consulter [Conversion dans des formats en colonnes](columnar-storage.md#convert-to-columnar). ## Compresser les données Athena prend en charge un large éventail de formats de compression. L'interrogation de données compressées est plus rapide et moins coûteuse, car vous payez pour le nombre d'octets analysés avant la décompression. Le format [gzip](https://www.gnu.org/software/gzip/) fournit de bons taux de compression et est largement compatible avec d'autres outils et services. Le format [zstd](https://facebook.github.io/zstd/) (Zstandard) est un format de compression plus récent offrant un bon équilibre entre performances et taux de compression. Lorsque vous compressez des fichiers texte tels que des données JSON et CSV, essayez de trouver un équilibre entre le nombre de fichiers et leur taille. La plupart des formats de compression nécessitent que le lecteur lise les fichiers dès le début. Cela signifie que les fichiers texte compressés ne peuvent généralement pas être traités en parallèle. Les fichiers non compressés volumineux sont souvent répartis entre les outils de traitement afin d'obtenir un parallélisme accru lors du traitement des requêtes, mais cela n'est pas possible avec la plupart des formats de compression. Comme indiqué dans [Éviter d'avoir trop de fichiers](#performance-tuning-avoid-having-too-many-files), il est préférable de n'avoir ni trop ni trop peu de fichiers. Le nombre de fichiers étant la limite du nombre de travailleurs autorisés à traiter la requête, cette règle est particulièrement vraie pour les fichiers compressés. Pour plus d'informations sur l'utilisation de la compression dans Athena, consultez [Utilisation de la compression dans Athena](compression-formats.md). ## Utiliser la compartimentation pour les recherches sur des clés à cardinalité élevée La compartimentation est une technique qui permet de répartir les enregistrements dans des fichiers séparés en fonction de la valeur de l'une des colonnes. Cela garantit que tous les enregistrements ayant la même valeur figurent dans le même fichier. La compartimentation est utile lorsque vous avez une clé à cardinalité élevée et que bon nombre de vos requêtes recherchent des valeurs spécifiques de cette clé. Supposons, par exemple, que vous interrogiez un ensemble d'enregistrements pour un utilisateur spécifique. Si les données sont compartimentées par nom d'utilisateur, Athena sait à l'avance quels fichiers contiennent des enregistrements pour un identifiant spécifique et quels fichiers n'en contiennent pas. Cela permet à Athena de lire uniquement les fichiers pouvant contenir l'identifiant, ce qui réduit considérablement le volume de données lues. Cela réduit également le temps de calcul qui serait autrement nécessaire pour rechercher l'identifiant spécifique dans les données. ### Éviter la compartimentation lorsque les requêtes recherchent fréquemment plusieurs valeurs dans une colonne La compartimentation est moins utile lorsque les requêtes recherchent fréquemment plusieurs valeurs dans la colonne dans laquelle les données sont compartimentées. Plus le nombre de valeurs demandées est élevé, plus il est probable que tous les fichiers ou la plupart d'entre eux devront être lus. Par exemple, si vous avez trois compartiments et qu'une requête recherche trois valeurs différentes, il est possible que tous les fichiers doivent être lus. La compartimentation fonctionne mieux lorsque les requêtes recherchent des valeurs uniques. Pour de plus amples informations, veuillez consulter [Utilisation du partitionnement et de la compartimentation](ctas-partitioning-and-bucketing.md). ## Éviter d'avoir trop de fichiers Les jeux de données composés de nombreux petits fichiers se traduisent par de faibles performances globales pour les requêtes. Lorsqu'Athena planifie une requête, il répertorie tous les emplacements des partitions, ce qui prend du temps. La gestion et la demande de chaque fichier entraînent également une surcharge de calcul. Par conséquent, le chargement d'un seul fichier plus volumineux à partir d'Amazon S3 est plus rapide que le chargement des mêmes enregistrements à partir de nombreux fichiers plus petits. Dans des cas extrêmes, vous pouvez rencontrer des limites de service Amazon S3. Amazon S3 prend en charge jusqu'à 5 500 demandes par seconde adressées à une seule partition d'index. Au départ, un compartiment est traité comme une seule partition d'index, mais à mesure que la charge de demandes augmente, il peut être divisé en plusieurs partitions d'index. Amazon S3 examine les modèles de demandes et les fractionne en fonction de préfixes clés. Si votre jeu de données se compose de plusieurs milliers de fichiers, les demandes provenant d'Athena peuvent dépasser le quota de demandes. Même avec moins de fichiers, le quota peut être dépassé si plusieurs requêtes simultanées sont effectuées sur le même jeu de données. Les autres applications qui accèdent aux mêmes fichiers peuvent contribuer au nombre total de demandes. Lorsque le taux de demandes `limit` est dépassé, Amazon S3 renvoie l'erreur suivante. Cette erreur est incluse dans les informations d'état de la requête dans Athena. SlowDown: Veuillez réduire votre taux de demandes Pour résoudre le problème, commencez par déterminer si l'erreur est due à une seule requête ou à plusieurs requêtes qui lisent les mêmes fichiers. Dans ce dernier cas, coordonnez l'exécution des requêtes afin qu'elles ne s'exécutent pas en même temps. Pour ce faire, ajoutez un mécanisme de mise en file d'attente ou réessayez dans votre application. Si l'exécution d'une seule requête déclenche l'erreur, essayez de combiner des fichiers de données ou de modifier la requête pour lire moins de fichiers. Il est préférable de combiner les petits fichiers avant leur écriture. Pour ce faire, envisagez les techniques suivantes : + Modifiez le processus d'écriture des fichiers pour écrire des fichiers plus volumineux. Par exemple, vous pouvez mettre les enregistrements en mémoire tampon plus longtemps avant qu'ils ne soient écrits. + Placez les fichiers dans un emplacement sur Amazon S3 et utilisez un outil tel que ETL Glue pour les combiner en fichiers plus volumineux. Déplacez ensuite les fichiers les plus volumineux vers l'emplacement indiqué dans la table. Pour plus d'informations, consultez les [sections Lecture de fichiers d'entrée en groupes plus importants](https://docs.aws.amazon.com/glue/latest/dg/grouping-input-files.html) dans le *guide du AWS Glue développeur* et [Comment configurer une tâche AWS Glue ETL pour générer des fichiers plus volumineux ?](https://repost.aws/knowledge-center/glue-job-output-large-files) dans le centre de *connaissances AWS Re:post*. + Réduisez le nombre de clés de partition. Lorsque vous avez trop de clés de partition, chaque partition peut ne contenir que quelques enregistrements, ce qui entraîne un nombre excessif de petits fichiers. Pour plus d'informations sur le choix des partitions à créer, consultez [Sélectionner les clés de partition qui répondront à vos requêtes](#performance-tuning-pick-partition-keys-that-will-support-your-queries). ## Éviter les hiérarchies de stockage supplémentaires au-delà de la partition Pour éviter de surcharger la planification des requêtes, stockez les fichiers dans une structure plate à l'emplacement de chaque partition. N'utilisez aucune hiérarchie de répertoire supplémentaire. Lorsqu'Athena planifie une requête, il répertorie tous les fichiers de toutes les partitions correspondant à la requête. Bien qu'Amazon S3 ne dispose pas de répertoires en soi, la convention consiste à interpréter la barre oblique `/` comme séparateur de répertoires. Lorsqu'Athena répertorie les emplacements des partitions, il répertorie de manière récursive tous les répertoires qu'il trouve. Lorsque les fichiers d'une partition sont organisés en hiérarchie, plusieurs séries de listes ont lieu. Lorsque tous les fichiers se trouvent directement à l'emplacement de la partition, la plupart du temps, une seule opération de liste doit être effectuée. Cependant, plusieurs opérations de liste séquentielles sont nécessaires si vous avez plus de 1 000 fichiers dans une partition, car Amazon S3 ne renvoie que 1 000 objets par opération de liste. La présence de plus de 1 000 fichiers dans une partition peut également créer d'autres problèmes de performances plus graves. Pour de plus amples informations, veuillez consulter [Éviter d'avoir trop de fichiers](#performance-tuning-avoid-having-too-many-files). ## Utiliser SymlinkTextInputFormat uniquement lorsque cela est nécessaire L'utilisation de la technique [https://athena.guide/articles/stitching-tables-with-symlinktextinputformat](https://athena.guide/articles/stitching-tables-with-symlinktextinputformat) peut être un moyen de contourner les situations dans lesquelles les fichiers d'une table ne sont pas bien organisés en partitions. Par exemple, les liens symboliques peuvent être utiles lorsque tous les fichiers se trouvent dans le même préfixe ou lorsque des fichiers avec des schémas différents se trouvent au même emplacement. Cependant, l'utilisation de liens symboliques ajoute des niveaux d'indirection à l'exécution de la requête. Ces niveaux d'indirection ont un impact sur les performances globales. Les fichiers de liens symboliques doivent être lus et les emplacements qu'ils définissent doivent être répertoriés. Cela ajoute plusieurs allers-retours vers Amazon S3, ce qui n'est pas nécessaire pour les tables Hive habituelles. En conclusion, vous ne devez utiliser `SymlinkTextInputFormat` que lorsque de meilleures options, telles que la réorganisation des fichiers, ne sont pas disponibles. # Utilisation des formats de stockage en colonnes [Apache Parquet](https://parquet.apache.org) et [ORC](https://orc.apache.org/) sont des formats de stockage en colonnes optimisés pour une récupération rapide des données et utilisés dans AWS les applications analytiques. Les formats de stockage en colonnes ont les caractéristiques suivantes qui les rendent adaptés à l'utilisation avec Athena : + *Compression par colonne, avec algorithme de compression sélectionné pour le type de données de colonne* afin d'économiser de l'espace de stockage dans Amazon S3 et de réduire l'espace disque ainsi que I/O pendant le traitement des requêtes. + Le *prédicat pushdown* dans Parquet et ORC permet aux requêtes Athena d'extraire uniquement les blocs dont elles ont besoin, améliorant ainsi les performances de requête. Lorsqu'une requête Athena obtient des valeurs de colonne spécifiques à partir de vos données, elle utilise les statistiques des prédicats de blocs de données, tels que les max/min valeurs, pour déterminer s'il faut lire ou ignorer le bloc. + Le *fractionnement des données* dans Parquet et ORC permet à Athena de fractionner la lecture des données en plusieurs lecteurs et d'augmenter le parallélisme lors du traitement des requêtes. Pour convertir vos données brutes existantes d'autres formats de stockage vers Parquet ou ORC, vous pouvez exécuter des requêtes [CREATE TABLE AS SELECT (CTAS)](ctas.md) dans Athena et spécifier un format de stockage de données tel que Parquet ou ORC, ou utiliser le Crawler. AWS Glue ## Choix entre Parquet et ORC Le choix entre ORC (Optimized Row Columnar) et Parquet dépend de vos besoins d'utilisation spécifiques. Apache Parquet fournit des schémas de compression et de codage de données efficaces et convient parfaitement à l'exécution de requêtes complexes et au traitement de grandes quantités de données. Parquet est optimisé pour une utilisation avec [Apache Arrow](https://arrow.apache.org/), ce qui peut être avantageux si vous utilisez des outils liés à Arrow. ORC fournit un moyen efficace de stocker les données Hive. Les fichiers ORC sont souvent plus petits que les fichiers Parquet, et les index ORC peuvent accélérer les requêtes. De plus, ORC prend en charge les types complexes tels que les structures, les cartes et les listes. Lorsque vous choisissez entre Parquet et ORC, prenez en considération les facteurs suivants : **Performances des requêtes** : étant donné que Parquet prend en charge un plus large éventail de types de requêtes, Parquet peut s'avérer un meilleur choix si vous prévoyez d'effectuer des requêtes complexes. **Types de données complexes** : si vous utilisez des types de données complexes, ORC peut se révéler un meilleur choix, car il prend en charge un plus large éventail de types de données complexes. **Taille des fichiers** : si l'espace disque est un problème, ORC génère généralement des fichiers plus petits, ce qui peut réduire les coûts de stockage. **Compression** : Parquet et ORC offrent tous deux une bonne compression, mais le format qui vous convient le mieux peut dépendre de votre cas d'utilisation spécifique. **Évolution** : Parquet et ORC prennent tous deux en charge l'évolution du schéma, ce qui signifie que vous pouvez ajouter, supprimer ou modifier des colonnes au fil du temps. Parquet et ORC sont tous deux de bons choix pour les applications de big data, mais tenez compte des exigences de votre scénario avant de choisir. Vous souhaiterez peut-être effectuer des points de référence sur vos données et vos requêtes afin de déterminer quel format convient le mieux à votre cas d'utilisation. ## Conversion dans des formats en colonnes Les options permettant de convertir facilement des données sources telles que JSON ou CSV en un format en colonnes incluent l'utilisation de requêtes [CREATE TABLE AS](ctas.md) ou l'exécution de tâches dans AWS Glue. + Vous pouvez utiliser les requêtes `CREATE TABLE AS` (CTAS) pour convertir les données en Parquet ou ORC en une seule étape. Pour un exemple, consultez la section [Exemple : écriture des résultats d'une requête dans un format différent](https://docs.aws.amazon.com/athena/latest/ug/ctas-examples.html#ctas-example-format) sur la page [Exemples de requêtes CTAS](ctas-examples.md). + Pour plus d’informations concernant l’utilisation d’Athena dans le cadre de l’extraction, de la transformation et du chargement (ETL) pour transformer des données CSV en données Parquet, consultez [Utilisation de CTAS et INSERT INTO pour les opérations ETL et l’analyse des données](ctas-insert-into-etl.md) + Pour plus d'informations sur l'exécution AWS Glue d'une tâche visant à transformer des données CSV en Parquet, consultez la section « Transformer les données du format CSV au format Parquet » dans le billet de blog AWS Big [Data Build a data lake AWS Glue foundation with Amazon S3](https://aws.amazon.com/blogs/big-data/build-a-data-lake-foundation-with-aws-glue-and-amazon-s3/). AWS Glue permet d'utiliser la même technique pour convertir les données CSV en ORC, ou les données JSON en Parquet ou ORC. # Utilisation du partitionnement et de la compartimentation Le partitionnement et la compartimentation sont deux moyens de réduire la quantité de données qu'Athena doit analyser lorsque vous exécutez une requête. Le partitionnement et la compartimentation sont complémentaires et peuvent être utilisés ensemble. La réduction de la quantité de données analysées permet d'améliorer les performances et de réduire les coûts. Pour des instructions générales sur les performances des requêtes Athena, consultez [10 meilleurs conseils de réglage des performances pour Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/). **Topics** + [Qu'est-ce que le partitionnement ?](ctas-partitioning-and-bucketing-what-is-partitioning.md) + [Qu'est-ce que la compartimentation ?](ctas-partitioning-and-bucketing-what-is-bucketing.md) + [Ressources supplémentaires](ctas-partitioning-and-bucketing-additional-resources.md) # Qu'est-ce que le partitionnement ? Le partitionnement consiste à organiser les données dans des répertoires (ou « préfixes ») sur Amazon S3 en fonction d'une propriété particulière des données. Ces propriétés sont appelées clés de partition. Une clé de partition courante est la date ou une autre unité de temps telle que l'année ou le mois. Cependant, un jeu de données peut être partitionné par plusieurs clés. Par exemple, les données relatives aux ventes de produits peuvent être partitionnées par date, catégorie de produit et marché. ## Choix du mode de partitionnement Les propriétés qui sont toujours ou fréquemment utilisées dans les requêtes et qui ont une faible cardinalité peuvent être utilisées comme clés de partition. Il y a un compromis entre le fait d'avoir trop de partitions et d'en avoir trop peu. Lorsque le nombre de partitions est trop élevé, l'augmentation du nombre de fichiers entraîne une surcharge. Le filtrage des partitions elles-mêmes entraîne également une certaine surcharge. Lorsque le nombre de partitions est trop faible, les requêtes doivent souvent analyser davantage de données. ## Création d’une table partitionnée Lorsqu'un jeu de données est partitionné, vous pouvez créer une table partitionnée dans Athena. Une table partitionnée est une table qui possède des clés de partition. Lorsque vous utilisez `CREATE TABLE`, vous ajoutez des partitions à la table. Lorsque vous utilisez `CREATE TABLE AS`, les partitions créées sur Amazon S3 sont automatiquement ajoutées à la table. Dans une instruction `CREATE TABLE`, vous spécifiez les clés de partition dans la clause `PARTITIONED BY (column_name data_type)`. Dans une instruction `CREATE TABLE AS`, vous spécifiez les clés de partition dans une clause `WITH (partitioned_by = ARRAY['partition_key'])` ou `WITH (partitioning = ARRAY['partition_key'])` pour les tables Iceberg. Pour des raisons de performances, les clés de partition doivent toujours être de type `STRING`. Pour de plus amples informations, veuillez consulter [Utiliser STRING comme type de données pour les clés de partition](data-types-timestamps.md#data-types-timestamps-partition-key-types). Pour des informations de syntaxe `CREATE TABLE` et `CREATE TABLE AS` supplémentaires, consultez [CREATE TABLE](create-table.md) et [Propriétés de la table CTAS](create-table-as.md#ctas-table-properties). ## Interrogation des tables partitionnées Lorsque vous interrogez une table partitionnée, Athena utilise les prédicats de la requête pour filtrer la liste des partitions. Il utilise ensuite les emplacements des partitions correspondantes pour traiter les fichiers trouvés. Athena peut réduire efficacement la quantité de données analysées en ne lisant simplement pas les données contenues dans les partitions qui ne correspondent pas aux prédicats de la requête. ### Exemples Supposons que vous ayez une table partitionnée par `sales_date` et `product_category` et que vous souhaitiez connaître le chiffre d'affaires total sur une semaine dans une catégorie spécifique. Vous incluez des prédicats dans les colonnes `sales_date` et `product_category` pour vous assurer qu'Athena analyse uniquement la quantité minimale de données, comme dans l'exemple suivant. ``` SELECT SUM(amount) AS total_revenue FROM sales WHERE sales_date BETWEEN '2023-02-27' AND '2023-03-05' AND product_category = 'Toys' ``` Supposons que vous disposiez d'un jeu de données partitionné par date mais également doté d'un horodatage précis. Avec les tables Iceberg, vous pouvez déclarer qu'une clé de partition a une relation avec une colonne, mais avec les tables Hive, le moteur de requête n'a aucune connaissance des relations entre les colonnes et les clés de partition. Pour cette raison, vous devez inclure un prédicat à la fois sur la colonne et sur la clé de partition de votre requête afin de vous assurer que celle-ci n'analyse pas plus de données que nécessaire. Supposons, par exemple, que la table `sales` de l'exemple précédent comporte également une colonne `sold_at` du type de données `TIMESTAMP`. Si vous souhaitez obtenir le chiffre d'affaires uniquement pour une période spécifique, vous devez écrire la requête comme suit : ``` SELECT SUM(amount) AS total_revenue FROM sales WHERE sales_date = '2023-02-28' AND sold_at BETWEEN TIMESTAMP '2023-02-28 10:00:00' AND TIMESTAMP '2023-02-28 12:00:00' AND product_category = 'Toys' ``` Pour plus d'informations sur cette différence entre l'interrogation des tables Hive et Iceberg, consultez [Comment écrire des requêtes pour des champs d'horodatage qui sont également partitionnés dans le temps](data-types-timestamps.md#data-types-timestamps-how-to-write-queries-for-timestamp-fields-that-are-also-time-partitioned). # Qu'est-ce que la compartimentation ? La compartimentation est une méthode pour organiser les enregistrements d'un jeu de données en catégories appelées compartiments. La présente signification des termes compartiment et compartimentation diffère de celle des compartiments Amazon S3 et ne doit pas être confondue avec celle-ci. Lors de la compartimentation des données, les enregistrements ayant la même valeur pour une propriété sont placés dans le même compartiment. Les enregistrements sont répartis aussi uniformément que possible entre les compartiments afin que chaque compartiment contienne à peu près la même quantité de données. Dans la pratique, les compartiments sont des fichiers, et une fonction de hachage détermine le compartiment dans lequel un enregistrement est placé. Un jeu de données compartimenté comportera un ou plusieurs fichiers par compartiment et par partition. Le compartiment auquel appartient un fichier est codé dans le nom du fichier. ## Avantages de la compartimentation La compartimentation est utile lorsqu'un jeu de données est compartimenté par une certaine propriété et que vous souhaitez récupérer des enregistrements dans lesquels cette propriété possède une certaine valeur. Comme les données sont compartimentées, Athena peut utiliser la valeur pour déterminer les fichiers à consulter. Supposons, par exemple, qu'un jeu de données soit compartimenté par `customer_id` et que vous souhaitiez rechercher tous les enregistrements d'un client spécifique. Athena détermine le compartiment qui contient ces enregistrements et ne lit que les fichiers qu'il contient. Les colonnes présentant une cardinalité élevée (c'est-à-dire comportant de nombreuses valeurs distinctes), qui sont distribuées de manière uniforme et que vous interrogez fréquemment concernant des valeurs spécifiques se prêtent bien à la compartimentation. **Note** Athena ne prend pas en charge l'utilisation `INSERT INTO` pour ajouter de nouveaux enregistrements à des tables compartimentées. ## Types de données pris en charge pour le filtrage sur les colonnes compartimentées Vous pouvez ajouter des filtres sur des colonnes compartimentées contenant certains types de données. Athena prend en charge le filtrage uniquement sur les colonnes compartimentées avec les types de données suivants : + BOOLEAN + BYTE + DATE + DOUBLE + FLOAT + INT + LONG + SHORT + CHAÎNE + VARCHAR ## Prise en charge de Hive et Spark La version 2 du moteur Athena prend en charge les jeux de données compartimentés à l'aide de l'algorithme de compartiment Hive, et la version 3 du moteur Athena prend également en charge l'algorithme de compartimentation Apache Spark. La compartimentation Hive est le méthode par défaut. Si votre jeu de données est compartimenté à l'aide de l'algorithme Spark, utilisez la clause `TBLPROPERTIES` pour définir la valeur de la propriété `bucketing_format` sur `spark`. **Note** Athena a une limite de 100 partitions dans une requête `CREATE TABLE AS SELECT` ([CTAS](ctas.md)). De même, vous pouvez ajouter un maximum de 100 partitions à une table de destination avec une instruction [INSERT INTO](insert-into.md). Si vous dépassez cette limite, le message d'erreur HIVE\$1TOO\$1MANY\$1OPEN\$1PARTITIONS: Exceeded limit of 100 open writers for partitions/buckets (Dépassement de la limite de 100 rédacteurs ouverts pour les partitions/compartiments) peut s'afficher. Pour contourner ces limitations, vous pouvez utiliser une instruction CTAS et une série d'instructions `INSERT INTO` qui créent ou insèrent jusqu'à 100 partitions chacune. Pour de plus amples informations, veuillez consulter [Utilisation de CTAS et INSERT INTO pour contourner la limite de 100 partitions](ctas-insert-into.md). ## Exemple de compartimentation CREATE TABLE Pour créer une table pour un jeu de données compartimenté existant, utilisez la clause `CLUSTERED BY (column)` suivie de la clause `INTO N BUCKETS`. La clause `INTO N BUCKETS` spécifie le nombre de compartiments dans lesquels les données sont compartimentées. Dans l'exemple `CREATE TABLE` suivant, le jeu de données `sales` est compartimenté par `customer_id` en 8 compartiments à l'aide de l'algorithme Spark. L'instruction `CREATE TABLE` utilise les clauses `CLUSTERED BY` et `TBLPROPERTIES` pour définir les propriétés en conséquence. ``` CREATE EXTERNAL TABLE sales (...) ... CLUSTERED BY (`customer_id`) INTO 8 BUCKETS ... TBLPROPERTIES ( 'bucketing_format' = 'spark' ) ``` ## Exemple de compartimentation CREATE TABLE AS (CTAS) Pour spécifier la compartimentation avec `CREATE TABLE AS`, utilisez les paramètres `bucketed_by` et `bucket_count`, comme dans l'exemple suivant. ``` CREATE TABLE sales WITH ( ... bucketed_by = ARRAY['customer_id'], bucket_count = 8 ) AS SELECT ... ``` ## Exemple de requête de compartimentation L'exemple de requête suivant recherche les noms de produits qu'un client spécifique a achetés au cours d'une semaine. ``` SELECT DISTINCT product_name FROM sales WHERE sales_date BETWEEN '2023-02-27' AND '2023-03-05' AND customer_id = 'c123' ``` Si cette table est partitionnée par `sales_date` et compartimentée par `customer_id`, Athena peut calculer le compartiment dans lequel se trouvent les enregistrements du client. Athena lit tout au plus un fichier par partition. # Ressources supplémentaires + Pour un exemple `CREATE TABLE AS` qui crée des tables tant partitionnées que compartimentées, consultez [Exemple : création de tables partitionnées et compartimentées](https://docs.aws.amazon.com/athena/latest/ug/ctas-examples.html#ctas-example-bucketed). + Pour plus d'informations sur la mise en œuvre du AWS cloisonnement sur les lacs de données, notamment à l'aide d'une instruction Athena CTAS AWS Glue , pour Apache Spark, et du partitionnement pour les tables Apache Iceberg, consultez AWS le [billet de blog consacré au Big Data Optimize data layout by buketing with Amazon Athena](https://aws.amazon.com/blogs/big-data/optimize-data-layout-by-bucketing-with-amazon-athena-and-aws-glue-to-accelerate-downstream-queries/) and to accelerating queries in aval. AWS Glue # Partitionner vos données En partitionnant vos données, vous pouvez limiter la quantité de données numérisées par chaque requête, améliorant ainsi les performances et réduisant les coûts. Vous pouvez partitionner vos données en fonction de n’importe quelle clé. Il est d'usage de partitionner les données en fonction de l'heure, ce qui conduit souvent à un schéma de partitionnement à plusieurs niveaux. Par exemple, un client qui reçoit des données toutes les heures peut décider de les partitionner par année, par mois, par date et par heure. Un autre client, qui reçoit des données de nombreuses sources différentes mais qui sont chargées une seule fois par jour, peut les partitionner par date et par identifiant de source de données. Athena peut utiliser des partitions de style Apache Hive dont les chemins de données contiennent des paires de valeur clé connectées par des signes égal (par exemple `country=us/...` ou `year=2021/month=01/day=26/...`). Ainsi, les chemins incluent à la fois les noms des clés de partition et les valeurs que chaque chemin représente. Pour charger de nouvelles partitions Hive dans une table partitionnée, vous pouvez utiliser la commande [MSCK REPAIR TABLE](msck-repair-table.md) qui fonctionne uniquement avec des partitions de style Hive. Athena peut également utiliser des schémas de partitionnement non compatibles avec Hive. Par exemple, les CloudTrail journaux et les flux de diffusion Firehose utilisent des composants de chemin distincts pour les parties de date, telles que. `data/2021/01/26/us/6fc7845e.json` Pour les partitions de style non compatibles avec Hive, utilisez [ALTER TABLE ADD PARTITION](alter-table-add-partition.md) pour ajouter les partitions manuellement. ## Considérations et restrictions Lorsque vous utilisez le partitionnement, gardez à l'esprit les points suivants : + Si vous interrogez une table partitionnée et spécifiez la partition dans la clause `WHERE`, Athena analyse les données uniquement à partir de cette partition. + Si vous exécutez des requêtes sur les compartiments Simple Storage Service (Amazon S3) avec un grand nombre d'objets et que les données ne sont pas partitionnées, de telles requêtes peuvent affecter les limites de débit de demande `GET` dans Simple Storage Service (Amazon S3) et conduire à des exceptions Simple Storage Service (Amazon S3). Pour éviter des erreurs, partitionnez vos données. En outre, envisagez de régler vos taux de demande Simple Storage Service (Amazon S3). Pour plus d'informations, consultez la rubrique [Bonnes pratiques de conception : optimisation des performances Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/request-rate-perf-considerations.html). + Les emplacements de partition à utiliser avec Athena doivent utiliser le protocole `s3` (par exemple, `s3://amzn-s3-demo-bucket/folder/`). Dans Athena, les emplacements qui utilisent d'autres protocoles (par exemple, `s3a://amzn-s3-demo-bucket/folder/`) provoquent des échecs de requête lorsque les requêtes `MSCK REPAIR TABLE` sont exécutées sur les tables contenant les données. + Assurez-vous que le chemin Simple Storage Service (Amazon S3) est en minuscules et non en casse mixte (par exemple, `userid` au lieu de `userId`). Si le chemin S3 est en casse mixte, `MSCK REPAIR TABLE` n'ajoute pas les partitions au AWS Glue Data Catalog. Pour de plus amples informations, veuillez consulter [MSCK REPAIR TABLE](msck-repair-table.md). + Étant donné que `MSCK REPAIR TABLE` analyse à la fois un dossier et ses sous-dossiers pour trouver un schéma de partition correspondant, veillez à conserver les données des différentes tables dans des hiérarchies de dossiers distinctes. Par exemple, supposons que vous avez des données pour la table 1 dans `s3://amzn-s3-demo-bucket1` et des données pour la table 2 dans `s3://amzn-s3-demo-bucket1/table-2-data`. Si les deux tables sont partitionnées par chaîne, `MSCK REPAIR TABLE` ajoutera les partitions de la table 2 à la table 1. Pour éviter cela, utilisez des structures de dossiers distinctes telles que `s3://amzn-s3-demo-bucket1` et `s3://amzn-s3-demo-bucket2`. Notez que ce comportement est compatible avec Amazon EMR et Apache Hive. + Si vous l'utilisez AWS Glue Data Catalog avec Athena, consultez la section [AWS Glue Points de terminaison et quotas pour les quotas](https://docs.aws.amazon.com/general/latest/gr/glue.html) de service sur les partitions par compte et par table. + Bien qu'Athena prenne en charge l'interrogation de AWS Glue tables contenant 10 millions de partitions, Athena ne peut pas lire plus d'un million de partitions en un seul scan. Dans de tels scénarios, l’indexation des partitions peut s’avérer utile. Pour plus d'informations, consultez l'article du blog AWS Big Data [Améliorez les performances des requêtes Amazon Athena à l'aide d'index de AWS Glue Data Catalog partition](https://aws.amazon.com/blogs/big-data/improve-amazon-athena-query-performance-using-aws-glue-data-catalog-partition-indexes/). + Pour demander une augmentation du quota de partitions si vous utilisez le AWS Glue Data Catalog, visitez la [console Service Quotas pour AWS Glue](https://console.aws.amazon.com/servicequotas/home?region=us-east-1#!/services/glue/quotas). ## Création et chargement d’une table avec des données partitionnées Pour créer une table qui utilise des partitions, utilisez la clause `PARTITIONED BY` dans votre instruction [CREATE TABLE](create-table.md). La clause `PARTITIONED BY` définit les clés sur lesquelles les données doivent être partitionnées, comme dans l'exemple suivant. La clause `LOCATION` spécifie l'emplacement racine des données partitionnées. ``` CREATE EXTERNAL TABLE users ( first string, last string, username string ) PARTITIONED BY (id string) STORED AS parquet LOCATION 's3://amzn-s3-demo-bucket' ``` Après avoir créé la table, vous chargez les données dans les partitions pour l'interrogation. Pour les partitions de style Hive, exécutez [MSCK REPAIR TABLE](msck-repair-table.md). Pour les partitions de style non compatibles avec Hive, utilisez [ALTER TABLE ADD PARTITION](alter-table-add-partition.md) pour ajouter les partitions manuellement. ## Préparation de données compatibles avec Hive et non compatibles avec Hive pour l’interrogation Les sections suivantes expliquent comment préparer des données compatibles avec Hive et non compatibles avec Hive pour l'interrogation dans Athena. ### Scénario 1 : données stockées sur Amazon S3 au format Hive Les partitions sont stockées dans des dossiers distincts, dans Amazon S3. Par exemple, voici une liste partielle pour un exemple d'impressions publicitaires produites par la commande [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3/ls.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3/ls.html), qui répertorie les objets S3 sous un préfixe spécifié : ``` aws s3 ls s3://elasticmapreduce/samples/hive-ads/tables/impressions/ PRE dt=2009-04-12-13-00/ PRE dt=2009-04-12-13-05/ PRE dt=2009-04-12-13-10/ PRE dt=2009-04-12-13-15/ PRE dt=2009-04-12-13-20/ PRE dt=2009-04-12-14-00/ PRE dt=2009-04-12-14-05/ PRE dt=2009-04-12-14-10/ PRE dt=2009-04-12-14-15/ PRE dt=2009-04-12-14-20/ PRE dt=2009-04-12-15-00/ PRE dt=2009-04-12-15-05/ ``` Ici, les fichiers journaux sont stockés avec le nom de colonne (dt) défini sur les incréments de date, d'heures et de minutes. Lorsque vous fournissez une DDL avec l'emplacement du dossier parent, le schéma et le nom de la colonne partitionnée, Athena peut exécuter des requêtes sur les données figurant dans ces sous-dossiers. #### Création de la table Pour générer une table à partir de ces données, créez une partition avec 'dt' comme dans l'instruction DDL Athena suivante : ``` CREATE EXTERNAL TABLE impressions ( requestBeginTime string, adId string, impressionId string, referrer string, userAgent string, userCookie string, ip string, number string, processId string, browserCookie string, requestEndTime string, timers struct, threadId string, hostname string, sessionId string) PARTITIONED BY (dt string) ROW FORMAT serde 'org.apache.hive.hcatalog.data.JsonSerDe' LOCATION 's3://elasticmapreduce/samples/hive-ads/tables/impressions/' ; ``` Cette table utilise le sérialiseur-désérialiseur JSON natif de Hive pour lire des données JSON stockées dans Simple Storage Service (Amazon S3). Pour de plus amples informations sur les formats pris en charge, veuillez consulter [Choisissez un SerDe pour vos données](supported-serdes.md). #### Exécuter MSCK REPAIR TABLE Après avoir exécuté la requête `CREATE TABLE`, exécutez la commande `MSCK REPAIR TABLE` dans l'éditeur de requêtes Athena pour charger les partitions, comme dans l'exemple suivant. ``` MSCK REPAIR TABLE impressions ``` Une fois que vous avez exécuté cette commande, les données sont prêtes à être interrogées. #### Exécution des requêtes de données Exécutez des requêtes sur les données sur la table des impressions en utilisant la colonne de partition. Voici un exemple : ``` SELECT dt,impressionid FROM impressions WHERE dt<'2009-04-12-14-00' and dt>='2009-04-12-13-00' ORDER BY dt DESC LIMIT 100 ``` Cette requête devrait montrer des résultats similaires aux suivants : ``` 2009-04-12-13-20 ap3HcVKAWfXtgIPu6WpuUfAfL0DQEc 2009-04-12-13-20 17uchtodoS9kdeQP1x0XThKl5IuRsV 2009-04-12-13-20 JOUf1SCtRwviGw8sVcghqE5h0nkgtp 2009-04-12-13-20 NQ2XP0J0dvVbCXJ0pb4XvqJ5A4QxxH 2009-04-12-13-20 fFAItiBMsgqro9kRdIwbeX60SROaxr 2009-04-12-13-20 V4og4R9W6G3QjHHwF7gI1cSqig5D1G 2009-04-12-13-20 hPEPtBwk45msmwWTxPVVo1kVu4v11b 2009-04-12-13-20 v0SkfxegheD90gp31UCr6FplnKpx6i 2009-04-12-13-20 1iD9odVgOIi4QWkwHMcOhmwTkWDKfj 2009-04-12-13-20 b31tJiIA25CK8eDHQrHnbcknfSndUk ``` ### Scénario 2 : Les données ne sont pas partitionnées au format Hive Dans l'exemple suivant, la commande `aws s3 ls` affiche les journaux [ELB](elasticloadbalancer-classic-logs.md) stockés dans Amazon S3. Notez que la mise en page des données n'utilise pas de paires `key=value` et n'est donc pas au format Hive. (L'option `--recursive` pour la commande `aws s3 ls` précise que tous les fichiers ou objets du répertoire ou du préfixe spécifié doivent être répertoriés.) ``` aws s3 ls s3://athena-examples-myregion/elb/plaintext/ --recursive 2016-11-23 17:54:46 11789573 elb/plaintext/2015/01/01/part-r-00000-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:46 8776899 elb/plaintext/2015/01/01/part-r-00001-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:46 9309800 elb/plaintext/2015/01/01/part-r-00002-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:47 9412570 elb/plaintext/2015/01/01/part-r-00003-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:47 10725938 elb/plaintext/2015/01/01/part-r-00004-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:46 9439710 elb/plaintext/2015/01/01/part-r-00005-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:47 0 elb/plaintext/2015/01/01_$folder$ 2016-11-23 17:54:47 9012723 elb/plaintext/2015/01/02/part-r-00006-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:47 7571816 elb/plaintext/2015/01/02/part-r-00007-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:47 9673393 elb/plaintext/2015/01/02/part-r-00008-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 11979218 elb/plaintext/2015/01/02/part-r-00009-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 9546833 elb/plaintext/2015/01/02/part-r-00010-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 10960865 elb/plaintext/2015/01/02/part-r-00011-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 0 elb/plaintext/2015/01/02_$folder$ 2016-11-23 17:54:48 11360522 elb/plaintext/2015/01/03/part-r-00012-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 11211291 elb/plaintext/2015/01/03/part-r-00013-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 8633768 elb/plaintext/2015/01/03/part-r-00014-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:49 11891626 elb/plaintext/2015/01/03/part-r-00015-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:49 9173813 elb/plaintext/2015/01/03/part-r-00016-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:49 11899582 elb/plaintext/2015/01/03/part-r-00017-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:49 0 elb/plaintext/2015/01/03_$folder$ 2016-11-23 17:54:50 8612843 elb/plaintext/2015/01/04/part-r-00018-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:50 10731284 elb/plaintext/2015/01/04/part-r-00019-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:50 9984735 elb/plaintext/2015/01/04/part-r-00020-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:50 9290089 elb/plaintext/2015/01/04/part-r-00021-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:50 7896339 elb/plaintext/2015/01/04/part-r-00022-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 8321364 elb/plaintext/2015/01/04/part-r-00023-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 0 elb/plaintext/2015/01/04_$folder$ 2016-11-23 17:54:51 7641062 elb/plaintext/2015/01/05/part-r-00024-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 10253377 elb/plaintext/2015/01/05/part-r-00025-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 8502765 elb/plaintext/2015/01/05/part-r-00026-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 11518464 elb/plaintext/2015/01/05/part-r-00027-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 7945189 elb/plaintext/2015/01/05/part-r-00028-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 7864475 elb/plaintext/2015/01/05/part-r-00029-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 0 elb/plaintext/2015/01/05_$folder$ 2016-11-23 17:54:51 11342140 elb/plaintext/2015/01/06/part-r-00030-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 8063755 elb/plaintext/2015/01/06/part-r-00031-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 9387508 elb/plaintext/2015/01/06/part-r-00032-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 9732343 elb/plaintext/2015/01/06/part-r-00033-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 11510326 elb/plaintext/2015/01/06/part-r-00034-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 9148117 elb/plaintext/2015/01/06/part-r-00035-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 0 elb/plaintext/2015/01/06_$folder$ 2016-11-23 17:54:52 8402024 elb/plaintext/2015/01/07/part-r-00036-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 8282860 elb/plaintext/2015/01/07/part-r-00037-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 11575283 elb/plaintext/2015/01/07/part-r-00038-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:53 8149059 elb/plaintext/2015/01/07/part-r-00039-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:53 10037269 elb/plaintext/2015/01/07/part-r-00040-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:53 10019678 elb/plaintext/2015/01/07/part-r-00041-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:53 0 elb/plaintext/2015/01/07_$folder$ 2016-11-23 17:54:53 0 elb/plaintext/2015/01_$folder$ 2016-11-23 17:54:53 0 elb/plaintext/2015_$folder$ ``` #### Exécuter ALTER TABLE ADD PARTITION Étant donné que les données ne sont pas au format Hive, vous ne pouvez pas utiliser la commande `MSCK REPAIR TABLE` pour ajouter les partitions à la table une fois que vous l'avez créée. Au lieu de cela, vous pouvez utiliser la commande [ALTER TABLE ADD PARTITION](alter-table-add-partition.md) pour ajouter chaque partition manuellement. Par exemple, pour charger les données dans s3://athena-examples - *myregion* /elb/plaintext/2015/01/01/, vous pouvez exécuter la requête suivante. Notez qu'une colonne de partition distincte pour chaque dossier Simple Storage Service (Amazon S3) n'est pas requise et que la valeur clé de partition peut être différente de celle de la clé Simple Storage Service (Amazon S3). ``` ALTER TABLE elb_logs_raw_native_part ADD PARTITION (dt='2015-01-01') location 's3://athena-examples-us-west-1/elb/plaintext/2015/01/01/' ``` Si une partition existe déjà, vous recevez l'erreur Partition already exists (Partition déjà existante). Pour éviter cette erreur, vous pouvez utiliser la clause `IF NOT EXISTS`. Pour de plus amples informations, veuillez consulter [ALTER TABLE ADD PARTITION](alter-table-add-partition.md). Pour supprimer une partition, vous pouvez utiliser [ALTER TABLE DROP PARTITION](alter-table-drop-partition.md). ## Prise en considération de la projection de partition Si vous ne souhaitez pas gérer les partitions vous-mêmes, vous pouvez utiliser la projection de partition. La projection de partitions est une option pour les tables hautement partitionnées dont la structure est connue à l'avance. Dans une projection de partition, les valeurs et les emplacements de partition sont calculés à partir des propriétés de la table que vous configurez au lieu d'être lus à partir d'un référentiel de métadonnées. Étant donné que les calculs en mémoire sont plus rapides que la recherche à distance, l'utilisation de la projection de partition peut réduire considérablement les temps d'exécution des requêtes. Pour de plus amples informations, veuillez consulter [Utilisation de la projection de partition avec Amazon Athena](partition-projection.md). ## Ressources supplémentaires + Pour plus d’informations sur les options de partitionnement pour les données Firehose, consultez [Example : Amazon Data Firehose](partition-projection-kinesis-firehose-example.md). + Vous pouvez automatiser l'ajout de partitions en utilisant le [pilote JDBC](connect-with-jdbc.md). + Vous pouvez utiliser CTAS et INSERT INTO pour partitionner un jeu de données. Pour de plus amples informations, veuillez consulter [Utilisation de CTAS et INSERT INTO pour les opérations ETL et l’analyse des données](ctas-insert-into-etl.md). # Utilisation de la projection de partition avec Amazon Athena Vous pouvez utiliser la projection de partition dans Athena pour accélérer le traitement des requêtes de tables hautement partitionnées et automatiser la gestion des partitions. Dans une projection de partition, Athena calcule les valeurs et les emplacements de partition à l'aide des propriétés de table que vous configurez directement sur votre table dans AWS Glue. Les propriétés de table permettent à Athena de « projeter », ou de déterminer, les informations de partition nécessaires au lieu d'avoir à effectuer une recherche de métadonnées fastidieuse dans le AWS Glue Data Catalog. Étant donné que les opérations en mémoire sont souvent plus rapides que les opérations distantes, la projection de partition peut réduire le temps d'exécution des requêtes sur les tables hautement partitionnées. Selon les caractéristiques spécifiques de la requête et des données sous-jacentes, la projection de partition peut réduire considérablement le temps d'exécution des requêtes qui sont contraintes lors de la récupération des métadonnées de partition. ## Présentation de l’élagage des partitions et de la projection de partition L'élagage des partitions rassemble les métadonnées et les « élaguent » afin de ne conserver que les partitions qui s'appliquent à votre requête. Cette approche accélère souvent les requêtes. Athena utilise l'élagage de partition pour toutes les tables contenant des colonnes de partition, y compris les tables configurées pour la projection de partition. Normalement, lors du traitement des requêtes, Athena `GetPartitions` appelle le AWS Glue Data Catalog avant de procéder à l'élagage de la partition. Si une table comporte un grand nombre de partitions, l'utilisation de `GetPartitions` peut nuire aux performances. Pour pallier ce problème, vous pouvez utiliser la projection de partition. La projection de partition permet à Athena d'éviter d'appeler `GetPartitions`, car la configuration de la projection de partition donne à Athena toutes les informations nécessaires pour créer les partitions. ## Comment utiliser la projection de partition Pour utiliser la projection de partition, vous devez spécifier les plages de valeurs de partition et les types de projection pour chaque colonne de partition dans les propriétés de table du [métastore Hive externe AWS Glue Data Catalog](connect-to-data-source-hive.md) ou dans celui-ci. Ces propriétés personnalisées permettent à Athena d'identifier les modèles de partition prévus lorsqu'il exécute une requête au niveau de la table. Pendant l'exécution de la requête, Athena utilise ces informations pour projeter les valeurs de partition au lieu de les récupérer depuis le métastore Hive AWS Glue Data Catalog ou depuis un autre métastore Hive. Cette approche permet non seulement de réduire le temps d'exécution des requêtes, mais aussi d'automatiser la gestion des partitions, car cela élimine la nécessité de créer manuellement des partitions dans Athena, AWS Glue ou dans votre métastore Hive externe. **Important** L'activation de la projection de partition sur une table oblige Athena à ignorer toutes les métadonnées de partition enregistrées sur la table dans le métastore AWS Glue Data Catalog ou Hive. ## Cas d’utilisation Les scénarios dans lesquels la projection de partition est utile sont les suivants : + Les requêtes relatives à une table hautement partitionnée ne se terminent pas aussi rapidement que vous le souhaitez. + Vous ajoutez régulièrement des partitions aux tables au fur et à mesure que de nouvelles partitions de date ou d'heure sont créées dans vos données. Avec la projection de partition, vous configurez des plages de dates relatives qui peuvent être utilisées lors de l'arrivée de nouvelles données. + Des données sont hautement partitionnées dans Simple Storage Service (Amazon S3). Les données ne sont pas pratiques à modéliser dans votre métastore AWS Glue Data Catalog ou dans Hive, et vos requêtes n'en lisent que de petites parties. ### Structures de partition projetables La projection de partition est plus facilement configurée lorsque vos partitions respectent un modèle prévisible comme suit (exemple non exhautif) : + **Entiers** : toute séquence continue d'entiers, telle que `[1, 2, 3, 4, ..., 1000]` ou `[0500, 0550, 0600, ..., 2500]`. + **Dates** : toute séquence continue de dates ou de dates et heures, telle que `[20200101, 20200102, ..., 20201231]` ou `[1-1-2020 00:00:00, 1-1-2020 01:00:00, ..., 12-31-2020 23:00:00]`. + **Valeurs énumérées** : ensemble fini de valeurs énumérées, telles que les codes d'aéroport ou. Régions AWS + **Service AWS journaux** — Service AWS les journaux ont généralement une structure connue dont vous pouvez spécifier le schéma de partition AWS Glue et qu'Athena peut donc utiliser pour la projection de partitions. ### Comment personnaliser le modèle de chemin de partition Par défaut, Athena construit des emplacements de partition à l'aide du formulaire `s3://amzn-s3-demo-bucket//partition-col-1=/partition-col-2=/`, mais si vos données sont organisées différemment, Athena offre un mécanisme pour personnaliser ce modèle de chemin. Pour les étapes, consultez [Comment spécifier des emplacements de stockage S3 personnalisés](partition-projection-setting-up.md#partition-projection-specifying-custom-s3-storage-locations). ## Considérations et restrictions Les considérations suivantes s'appliquent : + La projection de partition élimine le besoin de spécifier manuellement des partitions dans AWS Glue ou dans un métastore Hive externe. + Lorsque vous activez la projection de partition sur une table, Athena ignore les métadonnées de partition présentes dans le métastore Hive AWS Glue Data Catalog ou dans un métastore Hive externe pour cette table. + Si une partition projetée n'existe pas dans Simple Storage Service (Amazon S3), Athena projette quand même la partition. Athena ne renvoie pas d'erreur, mais aucune donnée n'est renvoyée. Toutefois, si un trop grand nombre de vos partitions sont vides, les performances peuvent être ralenties par rapport aux AWS Glue partitions traditionnelles. Si plus de la moitié de vos partitions projetées sont vides, il est recommandé d'utiliser des partitions traditionnelles. + Les requêtes portant sur des valeurs qui dépassent les limites de l'intervalle défini pour la projection de partition ne renvoient pas d'erreur. Au lieu de cela, la requête s'exécute, mais retourne zéro ligne. Par exemple, si vous avez des données temporelles qui commencent en 2020 et qui sont définies comme `'projection.timestamp.range'='2020/01/01,NOW'`, une requête comme `SELECT * FROM table-name WHERE timestamp = '2019/02/02'` se terminera avec succès, mais renverra zéro ligne. + La projection des partitions n'est utilisable que lorsque la table est interrogée par Athena. Si la même table est lue par un autre service tel que Amazon Redshift Spectrum, Athena pour Spark ou Amazon EMR, les métadonnées de partition standard sont utilisées. + La projection de partition étant une fonctionnalité uniquement DML, `SHOW PARTITIONS` elle ne répertorie pas les partitions projetées par Athena mais non enregistrées dans le AWS Glue catalogue ou dans le métastore Hive externe. + Athena n'utilise pas les propriétés des tables des vues comme configuration pour la projection des partitions. Pour contourner cette limitation, configurez et activez la projection de partition dans les propriétés des tables auxquelles les vues font référence. ## Vidéo La vidéo suivante montre comment utiliser la projection de partition pour augmenter les performances de vos requêtes dans Athena. [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/iUD5pPpcyZk/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/iUD5pPpcyZk) **Topics** + [Présentation de l’élagage des partitions et de la projection de partition](#partition-projection-pruning-vs-projection) + [Comment utiliser la projection de partition](#partition-projection-using) + [Cas d’utilisation](#partition-projection-use-cases) + [Considérations et restrictions](#partition-projection-considerations-and-limitations) + [Vidéo](#partition-projection-video) + [Configuration de la projection de partition](partition-projection-setting-up.md) + [Types pris en charge pour la projection de partition](partition-projection-supported-types.md) + [Utilisation du partitionnement d’ID dynamique](partition-projection-dynamic-id-partitioning.md) + [Example : Amazon Data Firehose](partition-projection-kinesis-firehose-example.md) # Configuration de la projection de partition La configuration de la projection de partition dans les propriétés d'une table s'effectue en deux étapes : 1. Spécifiez les plages de données et les modèles pertinents pour chaque colonne de partition, ou utilisez un modèle personnalisé. 1. Activez la projection de partition pour la table. **Note** Avant d'ajouter des propriétés de projection de partition à une table existante, la colonne de partition pour laquelle vous configurez les propriétés de projection de partition doit déjà exister dans le schéma de la table. Si la colonne de partition n'existe pas encore, vous devez ajouter manuellement une colonne de partition à la table existante. AWS Glue n'exécute pas cette étape automatiquement pour vous. Cette section explique comment définir les propriétés de la table pour AWS Glue. Pour les définir, vous pouvez utiliser la AWS Glue console, les [CREATE TABLE](create-table.md) requêtes Athena ou [AWS Glue API](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api.html)les opérations. La procédure suivante indique comment définir les propriétés dans la AWS Glue console. **Pour configurer et activer la projection de partitions à l'aide de la AWS Glue console** 1. Connectez-vous à la AWS Glue console AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/). 1. Choisissez l'onglet **Tables**. Sous l'onglet **Tables**, vous pouvez modifier des tables existantes ou choisir **Add tables** (Ajouter des tables) pour en créer de nouvelles. Pour plus d'informations sur l'ajout de tables manuellement ou à l'aide d'un Crawler, consultez la rubrique [Travail avec des tables dans la console AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/console-tables.html) du *Guide du développeur AWS Glue *. 1. Dans la liste des tables, choisissez le lien correspondant à la table que vous souhaitez modifier. ![\[Dans la AWS Glue console, choisissez le tableau à modifier.\]](http://docs.aws.amazon.com/fr_fr/athena/latest/ug/images/partition-projection-1.png) 1. Sélectionnez **Actions**, puis **Edit table** (Modifier la table). 1. Sur la page **Edit table** (Modifier la table), dans la section **Table properties** (Propriétés de la table), ajoutez la paire clé-valeur suivante pour chaque colonne partitionnée : 1. Pour **Key** (Clé), ajoutez `projection.columnName.type`. 1. Pour **Value** (Valeur), ajoutez l'un des types pris en charge : `enum`, `integer`, `date`, ou `injected`. Pour de plus amples informations, veuillez consulter [Types pris en charge pour la projection de partition](partition-projection-supported-types.md). 1. En suivant les instructions indiquées dans [Types pris en charge pour la projection de partition](partition-projection-supported-types.md), ajoutez des paires clé-valeur supplémentaires en fonction de vos exigences de configuration. L'exemple de configuration de table suivant configure la colonne `year` pour la projection de partition, limitant les valeurs susceptibles d'être renvoyées à une plage comprise entre 2010 et 2016. ![\[Configuration de la projection de partition pour une colonne de partition dans les propriétés de la table de la console AWS Glue .\]](http://docs.aws.amazon.com/fr_fr/athena/latest/ug/images/partition-projection-3.png) 1. Ajoutez une paire clé-valeur pour activer la projection de partition. Pour **Key** (Clé), saisissez `projection.enabled` et pour **Value** (Valeur), saisissez `true`. **Note** Vous pouvez désactiver la projection de partition sur cette table à tout moment en définissant la valeur `projection.enabled` sur `false`. 1. Lorsque vous avez terminé, choisissez **Save**. 1. Dans l'éditeur de requête Athena, testez les colonnes que vous avez configurées pour la table. L'exemple de requête suivant utilise `SELECT DISTINCT` pour renvoyer les valeurs uniques de la colonne `year`. La base de données contient des données comprises entre la plage de dates 1987 et 2016, mais la propriété `projection.year.range` limite les valeurs renvoyées aux années 2010 à 2016. ![\[Interrogation d'une colonne qui utilise la projection de partition.\]](http://docs.aws.amazon.com/fr_fr/athena/latest/ug/images/partition-projection-5.png) **Note** Si vous définissez `projection.enabled` sur `true`, mais ne parvenez pas à configurer une ou plusieurs colonnes de partition, un message d'erreur du type suivant s'affiche : `HIVE_METASTORE_ERROR: Table database_name.table_name is configured for partition projection, but the following partition columns are missing projection configuration: [column_name] (table database_name.table_name)`. ## Comment spécifier des emplacements de stockage S3 personnalisés Lorsque vous modifiez les propriétés d'une table dans AWS Glue, vous pouvez également spécifier un modèle de chemin Amazon S3 personnalisé pour les partitions projetées. Un modèle personnalisé permet à Athena de mapper correctement les valeurs de partition à des emplacements de fichiers Simple Storage Service (Amazon S3) personnalisés qui ne suivent pas un modèle `.../column=value/...` typique. L'utilisation d'un modèle personnalisé est facultative. Toutefois, si vous utilisez un modèle personnalisé, celui-ci doit contenir un espace réservé pour chaque colonne de partition. Les emplacements modélisés doivent se terminer par une barre oblique afin que les fichiers de données partitionnés se trouvent dans un « dossier » par partition. **Pour spécifier un modèle d'emplacement de partition personnalisé** 1. En suivant les étapes pour [configurer et activer la projection de partition à l'aide de la AWS Glue console](#partition-projection-setting-up-procedure), ajoutez une paire clé-valeur supplémentaire qui spécifie un modèle personnalisé comme suit : 1. Pour **Key** (Clé), saisissez `storage.location.template`. 1. Pour **Value** (Valeur), spécifiez un emplacement qui inclut un espace réservé pour chaque colonne de partition. Assurez-vous que chaque espace réservé (et le chemin S3 lui-même) se termine par une barre oblique unique. Les exemples de valeurs de modèle suivants reposent sur une table avec les colonnes de partition `a`, `b` et `c`. ``` s3://amzn-s3-demo-bucket/table_root/a=${a}/${b}/some_static_subdirectory/${c}/ ``` ``` s3://amzn-s3-demo-bucket/table_root/c=${c}/${b}/some_static_subdirectory/${a}/${b}/${c}/${c}/ ``` Pour la même table, l'exemple de valeur de modèle suivant n'est pas valide, car il ne contient aucun espace réservé pour la colonne `c`. ``` s3://amzn-s3-demo-bucket/table_root/a=${a}/${b}/some_static_subdirectory/ ``` 1. Cliquez sur **Appliquer**. # Types pris en charge pour la projection de partition Une table peut avoir n'importe quelle combinaison de types de colonnes de partition `enum`, `integer`, `date,` ou `injected`. ## Type d'énumération Utilisez le `enum` type pour les colonnes de partition dont les valeurs sont membres d'un ensemble énuméré (par exemple, des codes d'aéroport ou Régions AWS). Définissez les propriétés de partition dans le tableau comme suit : **** | Nom de la propriété | Exemples de valeur | Description | | --- | --- | --- | | projection.columnName.type | `enum` | Obligatoire. Type de projection à utiliser pour la colonnecolumnName. La valeur doit être enum (insensible à la casse) pour signaler l'utilisation du type énumération. L'espace de début et de fin est autorisé. | | projection.columnName.values | `A,B,C,D,E,F,G,Unknown` | Obligatoire. Liste séparée par des virgules des valeurs de partition énumérées pour la colonne. columnName Tout espace est considéré comme faisant partie d'une valeur d'énumération. | **Note** En tant que bonne pratique, nous recommandons de limiter l'utilisation des projections de partitions basées sur `enum` à quelques dizaines ou moins. Bien qu'il n'existe aucune limite spécifique pour les `enum` projections, la taille totale des métadonnées de votre table ne peut pas dépasser la AWS Glue limite d'environ 1 Mo lors de la compression gzip. Notez que cette limite est partagée entre les éléments clés de votre table, comme les noms de colonnes, l'emplacement, le format de stockage, etc. Si vous utilisez plus de quelques dizaines d'unités uniques IDs dans votre `enum` projection, envisagez une autre approche, par exemple en répartissant un plus petit nombre de valeurs uniques dans un champ de substitution. En échangeant la cardinalité, vous pouvez contrôler le nombre de valeurs uniques dans votre champ `enum`. ## Type d'entier Utilisez le type entier pour les colonnes de partition dont les valeurs possibles peuvent être interprétées comme des entiers dans une plage définie. Les colonnes d'entier projetées sont actuellement limitées à la plage d'un entier Java long signé (-263 à 263-1 inclus). **** | Nom de la propriété | Exemples de valeur | Description | | --- | --- | --- | | projection.columnName.type | `integer` | Obligatoire. Type de projection à utiliser pour la colonnecolumnName. La valeur doit être integer (insensible à la casse) pour signaler l'utilisation du type entier. L'espace de début et de fin est autorisé. | | projection.columnName.range | `0,10` `-1,8675309` `0001,9999` | Obligatoire. Liste à deux éléments séparés par des virgules qui fournit les valeurs de plage minimale et maximale à renvoyer par les requêtes sur la colonne. columnName Notez que les valeurs doivent être séparées par une virgule, et non par un tiret. Ces valeurs sont inclusives, peuvent être négatives et peuvent contenir des zéros de début. L'espace de début et de fin est autorisé. | | projection.columnName.interval | `1` `5` | Facultatif. Un entier positif qui indique l'intervalle entre les valeurs de partition successives de la colonnecolumnName. Par exemple, la valeur range « 1,3 » avec une valeur interval correspondant à « 1 » génère les valeurs 1, 2 et 3. La même valeur range avec une valeur interval correspondant à « 2 » génère les valeurs 1 et 3 et ignore 2. L'espace de début et de fin est autorisé. La valeur par défaut est 1. | | projection.columnName.digits | `1` `5` | Facultatif. Un entier positif qui indique le nombre de chiffres à inclure dans la représentation finale de la valeur de partition pour la colonnecolumnName. Par exemple, la valeur range « 1,3 » avec une valeur digits correspondant à « 1 » génère les valeurs 1, 2 et 3. La même valeur range avec une valeur digits correspondant à « 2 » génère les valeurs 01, 02 et 03. L'espace de début et de fin est autorisé. La valeur par défaut est un nombre non statique de chiffres et ne contient aucun zéro de début. | ## Type de date Utilisez le type de date pour les colonnes de partition dont les valeurs sont interprétables comme des dates (avec des heures facultatives) dans une plage définie. **Important** Les colonnes de date projetée sont générées en temps universel coordonné (UTC) au moment de l'exécution de la requête. **** | Nom de la propriété | Exemples de valeur | Description | | --- | --- | --- | | projection.columnName.type | `date` | Obligatoire. Type de projection à utiliser pour la colonnecolumnName. La valeur doit être date (insensible à la casse) pour signaler l'utilisation du type date. L'espace de début et de fin est autorisé. | | projection.columnName.range | `201701,201812` `01-01-2010,12-31-2018` `NOW-3YEARS,NOW` `201801,NOW+1MONTH` | Obligatoire. Liste à deux éléments séparés par des virgules qui fournit les `range` valeurs minimale et maximale de la colonne. *columnName* Ces valeurs sont inclusives et peuvent utiliser n'importe quel format compatible avec les types de date Java `java.time.*`. Les valeurs minimales et maximales doivent utiliser le même format. Le format spécifié dans la propriété `.format` doit correspondre au format utilisé pour ces valeurs. Cette colonne peut également contenir des chaînes de date relatives, formatées dans ce modèle d'expression régulière : `\s*NOW\s*(([\+\-])\s*([0-9]+)\s*(YEARS?\|MONTHS?\|WEEKS?\|DAYS?\|HOURS?\|MINUTES?\|SECONDS?)\s*)?` Les espaces sont autorisés, mais les littéraux de type date sont considérés comme faisant partie des chaînes de date elles-mêmes. | | projection.columnName.format | `yyyyMM` `dd-MM-yyyy` `dd-MM-yyyy-HH-mm-ss` | Obligatoire. Chaîne de format de date basée sur le format de date Java [DateTimeFormatter](https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html). Il peut s'agir de n'importe quel type Java.time.\$1 pris en charge. | | projection.columnName.interval | `1` `5` | Un entier positif qui indique l'intervalle entre les valeurs de partition successives d'une colonne*columnName*. Par exemple, la valeur `range` `2017-01,2018-12` avec une valeur `interval` correspondant à `1` et une valeur `interval.unit` correspondant à `MONTHS` génère les valeurs 2017-01, 2017-02, 2017-03, etc. La même valeur `range` avec une valeur `interval` correspondant à `2` et une valeur `interval.unit` correspondant `MONTHS` génère les valeurs 2017-01, 2017-03, 2017-05, etc. L'espace de début et de fin est autorisé. Lorsque les dates fournies sont précises à un jour ou à un mois, la valeur `interval` est facultative, et la valeur par défaut est 1 jour ou 1 mois, respectivement. Dans le cas contraire, la valeur `interval` est obligatoire. | | projection.columnName.interval.unit | `YEARS` `MONTHS` `WEEKS` `DAYS` `HOURS` `MINUTES` `SECONDS` `MILLIS` | Un mot d'unité de temps qui représente la forme sérialisée de a. [ChronoUnit](https://docs.oracle.com/javase/8/docs/api/java/time/temporal/ChronoUnit.html) Les valeurs possibles sont `YEARS`, `MONTHS`, `WEEKS`, `DAYS`, `HOURS`, `MINUTES`, `SECONDS` ou `MILLIS`. Ces valeurs ne sont pas sensibles à la casse. Lorsque les dates fournies sont précises à un jour ou à un mois, la valeur `interval.unit` est facultative, et la valeur par défaut est 1 jour ou 1 mois, respectivement. Dans le cas contraire, la valeur `interval.unit` est obligatoire. | **Example : partitionnement par mois** L’exemple de configuration de table ci-dessous partitionne les données par mois de 2015 à aujourd’hui. ``` 'projection.month.type'='date', 'projection.month.format'='yyyy-MM', 'projection.month.interval'='1', 'projection.month.interval.unit'='MONTHS', 'projection.month.range'='2015-01,NOW', ... ``` ## Type injecté Utilisez le type injecté pour les colonnes de partition avec des valeurs possibles qui ne peuvent pas être générées de manière procédurale dans une plage logique, mais qui sont fournies dans la clause `WHERE` d'une requête en tant que valeur unique. Il est important de garder à l'esprit les points suivants : + Les requêtes au niveau des colonnes injectées échouent si aucune expression de filtre n'est fournie pour chaque colonne injectée. + Les requêtes comportant plusieurs valeurs pour une expression de filtre sur une colonne injectée réussissent uniquement si les valeurs sont disjointes. + Seules les colonnes de type `string` sont prises en charge. + Lorsque vous utilisez la clause `WHERE IN` avec une colonne de partition injectée, vous pouvez spécifier au maximum 1 000 valeurs dans la liste `IN`. Pour interroger un jeu de données contenant plus de 1 000 partitions pour une colonne injectée, divisez la requête en plusieurs requêtes de plus petite taille contenant chacune jusqu’à 1 000 valeurs dans la clause `WHERE IN`, puis agrégez les résultats. **** | Nom de la propriété | Value | Description | | --- | --- | --- | | projection.columnName.type | `injected` | Obligatoire. Type de projection à utiliser pour la colonnecolumnName. Seul le type string est pris en charge. La valeur spécifiée doit être injected (insensible à la casse). L'espace de début et de fin est autorisé. | Pour de plus amples informations, veuillez consulter [Quand utiliser le type de projection `injected`](partition-projection-dynamic-id-partitioning.md#partition-projection-injection). # Utilisation du partitionnement d’ID dynamique Lorsque vos données sont partitionnées par une propriété avec une cardinalité élevée ou lorsque les valeurs ne peuvent pas être connues à l’avance, vous pouvez utiliser le type de projection `injected`. Les noms d'utilisateur et les noms d'appareils ou de produits sont IDs des exemples de telles propriétés. Lorsque vous utilisez le type de projection `injected` pour configurer une clé de partition, Athena utilise les valeurs de la requête elle-même pour calculer l’ensemble des partitions qui seront lues. Pour qu’Athena puisse exécuter une requête sur une table dont la clé de partition est configurée avec le type de projection `injected`, les critères suivants doivent être remplis : + Votre requête doit inclure au moins une valeur pour la clé de partition. + La ou les valeurs doivent être des littéraux ou des expressions qui peuvent être évalués sans lire aucune donnée. Si l’un de ces critères n’est pas rempli, votre requête échoue avec l’erreur suivante : CONSTRAINT\$1VIOLATION : Pour la colonne de partition projetée injectée*column\$1name*, la clause WHERE doit contenir uniquement des conditions d'égalité statiques, et au moins une de ces conditions doit être présente. ## Quand utiliser le type de projection `injected` Imaginez que vous disposiez d'un ensemble de données composé d'événements provenant d'appareils IoT, répartis sur les appareils IDs. Ce jeu de données possède les caractéristiques suivantes : + Les appareils IDs sont générés de manière aléatoire. + de nouveaux appareils sont fréquemment alloués ; + il existe actuellement des centaines de milliers d’appareils, et dans le futur, il y en existera des millions. Ce jeu de données est difficile à gérer en utilisant des métastores classiques. Il est difficile de synchroniser les partitions entre le stockage de données et le métastore, et le filtrage des partitions peut être lent lors de la planification des requêtes. Mais si vous configurez une table pour utiliser la projection de partition et que vous utilisez le type de projection `injected`, vous avez deux avantages : vous n’avez pas à gérer les partitions dans le métastore et vos requêtes n’ont pas à rechercher les métadonnées des partitions. L’exemple `CREATE TABLE` suivant crée une table pour le jeu de données d’événements d’appareil que nous venons de décrire. La table utilise le type de projection injecté. ``` CREATE EXTERNAL TABLE device_events ( event_time TIMESTAMP, data STRING, battery_level INT ) PARTITIONED BY ( device_id STRING ) LOCATION "s3://amzn-s3-demo-bucket/prefix/" TBLPROPERTIES ( "projection.enabled" = "true", "projection.device_id.type" = "injected", "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${device_id}" ) ``` L’exemple de requête suivant recherche le nombre d’événements reçus par trois appareils spécifiques sur une période de 12 heures. ``` SELECT device_id, COUNT(*) AS events FROM device_events WHERE device_id IN ( '4a770164-0392-4a41-8565-40ed8cec737e', 'f71d12cf-f01f-4877-875d-128c23cbde17', '763421d8-b005-47c3-ba32-cc747ab32f9a' ) AND event_time BETWEEN TIMESTAMP '2023-11-01 20:00' AND TIMESTAMP '2023-11-02 08:00' GROUP BY device_id ``` Lorsque vous exécutez cette requête, Athena voit les trois valeurs de la clé de partition `device_id` et les utilise pour calculer les emplacements des partitions. Athena utilise la valeur de la propriété `storage.location.template` pour générer les emplacements suivants : + `s3://amzn-s3-demo-bucket/prefix/4a770164-0392-4a41-8565-40ed8cec737e` + `s3://amzn-s3-demo-bucket/prefix/f71d12cf-f01f-4877-875d-128c23cbde17` + `s3://amzn-s3-demo-bucket/prefix/763421d8-b005-47c3-ba32-cc747ab32f9a` Si vous omettez la propriété `storage.location.template` dans la configuration de projection de partition, Athena utilise le partitionnement de style Hive pour projeter les emplacements des partitions en fonction de la valeur contenue dans `LOCATION` (par exemple, `s3://amzn-s3-demo-bucket/prefix/device_id=4a770164-0392-4a41-8565-40ed8cec737e`). # Example : Amazon Data Firehose Lorsque vous utilisez Firehose pour fournir des données à Amazon S3, la configuration par défaut écrit des objets avec des clés semblables à l’exemple suivant : ``` s3://amzn-s3-demo-bucket/prefix/yyyy/MM/dd/HH/file.extension ``` Pour créer une table Athena qui trouve les partitions automatiquement au moment de la requête, au lieu de devoir les ajouter à AWS Glue Data Catalog mesure que de nouvelles données arrivent, vous pouvez utiliser la projection de partitions. L’exemple d’instruction `CREATE TABLE` suivant utilise la configuration Firehose par défaut. ``` CREATE EXTERNAL TABLE my_ingested_data ( ... ) ... PARTITIONED BY ( datehour STRING ) LOCATION "s3://amzn-s3-demo-bucket/prefix/" TBLPROPERTIES ( "projection.enabled" = "true", "projection.datehour.type" = "date", "projection.datehour.format" = "yyyy/MM/dd/HH", "projection.datehour.range" = "2021/01/01/00,NOW", "projection.datehour.interval" = "1", "projection.datehour.interval.unit" = "HOURS", "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${datehour}/" ) ``` La clause `TBLPROPERTIES` dans l'instruction `CREATE TABLE` indique à Athena ce qui suit : + Utiliser la projection de partition lors de l'interrogation de la table + La clé de partition `datehour` est de type `date` (qui inclut une heure facultative) + Comment les dates sont formatées + La plage de dates et heures. Notez que les valeurs doivent être séparées par une virgule, et non par un tiret. + Où trouver les données sur Amazon S3. Lorsque vous interrogez la table, Athena calcule les valeurs pour `datehour` et utilise le modèle d'emplacement de stockage pour générer une liste d'emplacements de partition. **Topics** + [Comment utiliser le type `date`](partition-projection-kinesis-firehose-example-using-the-date-type.md) + [Comment choisir les clés de partition](partition-projection-kinesis-firehose-example-choosing-partition-keys.md) + [Comment utiliser des préfixes personnalisés et le partitionnement dynamique](partition-projection-kinesis-firehose-example-using-custom-prefixes-and-dynamic-partitioning.md) # Comment utiliser le type `date` Lorsque vous utilisez le type `date` pour une clé de partition projetée, vous devez spécifier une plage. Puisque vous ne disposez pas de données pour les dates antérieures à la création du flux de diffusion Firehose, vous pouvez utiliser la date de création comme début. Et comme vous ne disposez pas de données pour les dates à l'avenir, vous pouvez utiliser le jeton spécial `NOW` comme fin. Dans l'exemple `CREATE TABLE`, la date de début est spécifiée le 1er janvier 2021 à minuit UTC. **Note** Configurez une plage qui correspond aussi précisément que possible à vos données afin qu'Athena ne recherche que les partitions existantes. Lorsqu'une requête est exécutée sur la table d'exemple, Athena utilise les conditions sur la clé de partition `datehour` en combinaison avec la plage pour générer des valeurs. Considérons la requête suivante : ``` SELECT * FROM my_ingested_data WHERE datehour >= '2020/12/15/00' AND datehour < '2021/02/03/15' ``` La première condition dans la requête `SELECT` utilise une date antérieure au début de la plage de dates spécifiée par l'instruction `CREATE TABLE`. Étant donné que la configuration de projection de partitions ne spécifie aucune partition pour les dates antérieures au 1er janvier 2021, Athena recherche des données uniquement aux emplacements suivants et ignore les dates antérieures dans la requête. ``` s3://amzn-s3-demo-bucket/prefix/2021/01/01/00/ s3://amzn-s3-demo-bucket/prefix/2021/01/01/01/ s3://amzn-s3-demo-bucket/prefix/2021/01/01/02/ ... s3://amzn-s3-demo-bucket/prefix/2021/02/03/12/ s3://amzn-s3-demo-bucket/prefix/2021/02/03/13/ s3://amzn-s3-demo-bucket/prefix/2021/02/03/14/ ``` De même, si la requête s'est exécutée à une date et une heure avant le 3 février 2021 à 15 h 00, la dernière partition refléterait la date et l'heure actuelles, et non la date et l'heure dans la condition de requête. Si vous souhaitez rechercher les données les plus récentes, vous pouvez profiter du fait qu'Athena ne génère pas de dates futures et ne spécifier qu'une `datehour` de début, comme dans l'exemple suivant. ``` SELECT * FROM my_ingested_data WHERE datehour >= '2021/11/09/00' ``` # Comment choisir les clés de partition Vous pouvez spécifier comment la projection de partition mappe les emplacements des partitions aux clés de partition. Dans l'exemple `CREATE TABLE` de la section précédente, la date et l'heure ont été combinées dans une clé de partition appelée datehour, mais d'autres schémas sont possibles. Par exemple, vous pouvez également configurer une table avec des clés de partition distinctes pour l'année, le mois, le jour et l'heure. Cependant, si vous divisez les dates en année, mois et jour, le type de projection de partition de `date` ne peut pas être utilisé. Une alternative consiste à séparer la date de l'heure afin de continuer à exploiter le type de projection de partition de `date`, tout en facilitant la lecture des requêtes qui spécifient des plages d'heures. Dans cette optique, l'exemple `CREATE TABLE` suivant sépare la date de l'heure. Étant donné que `date` est un mot réservé dans SQL, l'exemple utilise `day` comme nom de la clé de partition qui représente la date. ``` CREATE EXTERNAL TABLE my_ingested_data2 ( ... ) ... PARTITIONED BY ( day STRING, hour INT ) LOCATION "s3://amzn-s3-demo-bucket/prefix/" TBLPROPERTIES ( "projection.enabled" = "true", "projection.day.type" = "date", "projection.day.format" = "yyyy/MM/dd", "projection.day.range" = "2021/01/01,NOW", "projection.day.interval" = "1", "projection.day.interval.unit" = "DAYS", "projection.hour.type" = "integer", "projection.hour.range" = "0,23", "projection.hour.digits" = "2", "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${day}/${hour}/" ) ``` Dans l'exemple d'instruction `CREATE TABLE`, l'heure est une clé de partition distincte, configurée comme un nombre entier. La configuration de la clé de partition des heures spécifie la plage 0 à 23, et que l'heure doit être formatée à deux chiffres lorsque Athena génère les emplacements de partition. Une requête pour la table `my_ingested_data2` pourrait ressembler à ceci : ``` SELECT * FROM my_ingested_data2 WHERE day = '2021/11/09' AND hour > 3 ``` ## Présentation des types de données de clé de partition et de projection de partition Notez que la clé `datehour` dans le premier exemple `CREATE TABLE` est configurée comme `date` dans la configuration de projection de partition, mais le type de clé de partition est `string`. Il en va de même pour `day` dans le second exemple. Les types de la configuration de projection de partition indiquent uniquement à Athena comment formater les valeurs lorsqu'elle génère les emplacements de partition. Les types que vous spécifiez ne modifient pas le type de clé de partition. Dans les requêtes, `datehour` et `day` sont de type `string`. Lorsqu'une requête inclut une condition telle que `day = '2021/11/09'`, Athena analyse la chaîne située à droite de l'expression en utilisant le format de date spécifié dans la configuration de projection de partition. Après avoir vérifié que la date est comprise dans la plage configurée, Athena utilise à nouveau le format de date pour insérer la date sous forme de chaîne dans le modèle d'emplacement de stockage. De même, pour une condition de requête telle que `day > '2021/11/09'`, Athena analyse le côté droit et génère une liste de toutes les dates correspondantes dans la plage configurée. Le format de date est ensuite utilisé pour insérer chaque date dans le modèle d'emplacement de stockage afin de créer la liste des emplacements de partition. Écrire la même condition que `day > '2021-11-09'` ou `day > DATE '2021-11-09'` ne fonctionne pas. Dans le premier cas, le format de date ne correspond pas (notez les traits d'union plutôt que les barres obliques) et, dans le second cas, les types de données ne correspondent pas. # Comment utiliser des préfixes personnalisés et le partitionnement dynamique Firehose peut être configuré pour utiliser des [préfixes personnalisés](https://docs.aws.amazon.com/firehose/latest/dev/s3-prefixes.html) et le [partitionnement dynamique](https://docs.aws.amazon.com/firehose/latest/dev/dynamic-partitioning.html). À l'aide de ces fonctions, vous pouvez configurer les clés Amazon S3 et configurer des schémas de partitionnement qui prennent mieux en charge votre cas d'utilisation. Vous pouvez également utiliser la projection de partitions avec ces schémas de partitionnement et les configurer en conséquence. Par exemple, vous pouvez utiliser la fonction de préfixe personnalisé pour obtenir des clés Amazon S3 dont les dates sont au format ISO au lieu du schéma par défaut `yyyy/MM/dd/HH`. Vous pouvez également combiner des préfixes personnalisés avec le partitionnement dynamique pour extraire une propriété telle que `customer_id` de messages Firehose, comme illustré dans l’exemple suivant. ``` prefix/!{timestamp:yyyy}-!{timestamp:MM}-!{timestamp:dd}/!{partitionKeyFromQuery:customer_id}/ ``` Avec ce préfixe Amazon S3, le flux de diffusion Firehose écrit les objets dans des clés telles que `s3://amzn-s3-demo-bucket/prefix/2021-11-01/customer-1234/file.extension`. Pour une propriété comme `customer_id`, où les valeurs peuvent ne pas être connues à l'avance, vous pouvez utiliser le type de projection de partition `injected` et utilisez une instruction `CREATE TABLE` comme suit : ``` CREATE EXTERNAL TABLE my_ingested_data3 ( ... ) ... PARTITIONED BY ( day STRING, customer_id STRING ) LOCATION "s3://amzn-s3-demo-bucket/prefix/" TBLPROPERTIES ( "projection.enabled" = "true", "projection.day.type" = "date", "projection.day.format" = "yyyy-MM-dd", "projection.day.range" = "2021-01-01,NOW", "projection.day.interval" = "1", "projection.day.interval.unit" = "DAYS", "projection.customer_id.type" = "injected", "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${day}/${customer_id}/" ) ``` Lorsque vous interrogez une table comportant une clé de partition de type `injected`, votre requête doit inclure une valeur pour cette clé de partition. Une requête pour la table `my_ingested_data3` pourrait ressembler à ceci : ``` SELECT * FROM my_ingested_data3 WHERE day BETWEEN '2021-11-01' AND '2021-11-30' AND customer_id = 'customer-1234' ``` ## Utilisation du type DATE pour la clé de partition de jour Comme les valeurs de la clé de partition `day` sont au format ISO, vous pouvez également utiliser le type `DATE` pour la clé de partition day au lieu de `STRING`, comme dans l'exemple suivant : ``` PARTITIONED BY (day DATE, customer_id STRING) ``` Lorsque vous effectuez une requête, cette stratégie vous permet d'utiliser des fonctions de date sur la clé de partition sans analyse ni diffusion, comme dans l'exemple suivant : ``` SELECT * FROM my_ingested_data3 WHERE day > CURRENT_DATE - INTERVAL '7' DAY AND customer_id = 'customer-1234' ``` **Note** La spécification d'une clé de partition du type `DATE` suppose que vous avez utilisé la fonctionnalité de [préfixe personnalisé](https://docs.aws.amazon.com/firehose/latest/dev/s3-prefixes.html) pour créer des clés Amazon S3 dont les dates sont au format ISO. Si vous utilisez le format Firehose par défaut `yyyy/MM/dd/HH`, vous devez spécifier la clé de partition comme type `string`, même si la propriété de table correspondante est de type `date`, comme dans l’exemple suivant : ``` PARTITIONED BY ( `mydate` string) TBLPROPERTIES ( 'projection.enabled'='true', ... 'projection.mydate.type'='date', 'storage.location.template'='s3://amzn-s3-demo-bucket/prefix/${mydate}') ``` # Prévention de la limitation d’Amazon S3 La limitation est le processus qui consiste à limiter le taux d'utilisation d'un service, d'une application ou d'un système. Dans AWS, vous pouvez utiliser la régulation pour empêcher la surutilisation du service Amazon S3 et augmenter la disponibilité et la réactivité d'Amazon S3 pour tous les utilisateurs. Cependant, étant donné que la limitation restreint la vitesse à laquelle les données peuvent être transférées vers ou depuis Amazon S3, il est important d'en tenir compte pour éviter que vos interactions ne soient limitées. Comme indiqué dans le chapitre relatif à l’[optimisation des performances](performance-tuning.md), les optimisations peuvent dépendre de vos décisions au niveau du service, de la manière dont vous structurez vos tables et vos données et de la manière dont vous écrivez vos requêtes. **Topics** + [Réduire la limitation au niveau du service](performance-tuning-s3-throttling-reduce-throttling-at-the-service-level.md) + [Optimisation de vos tables](performance-tuning-s3-throttling-optimizing-your-tables.md) + [Optimisation de vos requêtes](performance-tuning-s3-throttling-optimizing-queries.md) # Réduire la limitation au niveau du service Pour éviter la limitation d'Amazon S3 au niveau du service, vous pouvez surveiller votre utilisation et ajuster vos [Service Quotas](https://docs.aws.amazon.com/general/latest/gr/s3.html#limits_s3), ou utiliser certaines techniques telles que le partitionnement. Voici certaines des conditions qui peuvent entraîner une limitation : + **Dépassement des limites de demandes d'API de votre compte** : Amazon S3 a des limites de demandes d'API par défaut qui sont basées sur le type de compte et son utilisation. Si vous dépassez le nombre maximal de demandes par seconde pour un seul préfixe, vos demandes peuvent être limitées afin d’éviter une surcharge du service Amazon S3. + **Partitionnement insuffisant des données** : si vous ne partitionnez pas correctement vos données et que vous transférez une grande quantité de données, Amazon S3 peut limiter vos demandes. Pour plus d'informations sur le partitionnement, consultez la section [Utiliser le partitionnement](performance-tuning-s3-throttling-optimizing-your-tables.md#performance-tuning-s3-throttling-use-partitioning) plus haut dans ce document. + **Grand nombre de petits objets** : si possible, évitez d'avoir un grand nombre de petits fichiers. Amazon S3 a une limite de [5 500 demandes GET](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html) par seconde et par préfixe partitionné, et vos requêtes Athena partagent cette même limite. Si vous analysez des millions de petits objets en une seule requête, votre requête peut être facilement limitée par Amazon S3. Pour éviter une analyse excessive, vous pouvez utiliser l' AWS Glue ETL pour compacter régulièrement vos fichiers, ou vous pouvez partitionner la table et ajouter des filtres de clé de partition. Pour plus d'informations, veuillez consulter les ressources suivantes. + [Comment configurer une tâche AWS Glue ETL pour générer des fichiers plus volumineux ?](https://aws.amazon.com/premiumsupport/knowledge-center/glue-job-output-large-files/) (*Centre de AWS connaissances*) + [Lecture de fichiers d'entrée en groupes plus importants](https://docs.aws.amazon.com/glue/latest/dg/grouping-input-files.html) (*Guide AWS Glue du développeur*) # Optimisation de vos tables Il est important de structurer vos données si vous rencontrez des problèmes de limitation. Bien qu'Amazon S3 puisse gérer de grandes quantités de données, une limitation se produit parfois en raison de la structure des données. Les sections suivantes proposent des suggestions sur la manière de structurer vos données dans Amazon S3 afin d'éviter les problèmes de limitation. ## Utiliser le partitionnement Vous pouvez utiliser le partitionnement pour réduire la limitation en limitant la quantité de données auxquelles il est nécessaire d'accéder à un moment donné. En partitionnant les données sur des colonnes spécifiques, vous pouvez répartir les demandes de manière uniforme sur plusieurs objets et réduire le nombre de demandes pour un seul objet. La réduction de la quantité de données devant être analysées permet d'améliorer les performances des requêtes et de réduire les coûts. Vous pouvez définir des partitions, qui agissent comme des colonnes virtuelles, lorsque vous créez une table. Pour créer une table avec des partitions dans une instruction `CREATE TABLE`, vous utilisez la clause `PARTITIONED BY (column_name data_type)` pour définir les clés permettant de partitionner vos données. Pour restreindre les partitions analysées par une requête, vous pouvez les spécifier sous forme de prédicats dans une clause `WHERE` de la requête. Les colonnes fréquemment utilisées comme filtres se prêtent donc parfaitement au partitionnement. Il est d'usage de partitionner les données en fonction de l'heure, ce qui peut conduire à un schéma de partitionnement à plusieurs niveaux. Notez que le partitionnement a également un coût. Lorsque vous augmentez le nombre de partitions dans votre table, le temps nécessaire pour récupérer et traiter les métadonnées des partitions augmente également. Ainsi, le surpartitionnement peut supprimer les avantages que vous obtenez en partitionnant de manière plus judicieuse. Si vos données sont fortement asymétriques par rapport à une valeur de partition et que la plupart des requêtes utilisent cette valeur, vous risquez d'avoir à supporter des frais généraux supplémentaires. Pour plus d'informations sur le partitionnement dans Athena, consultez [Qu'est-ce que le partitionnement ?](ctas-partitioning-and-bucketing-what-is-partitioning.md). ## Compartimenter vos données Une autre façon de partitionner vos données consiste à les compartimenter dans une seule partition. La compartimentation vous permet de spécifier une ou plusieurs colonnes contenant des lignes que vous souhaitez regrouper. Ensuite, vous placez ces lignes dans plusieurs compartiments. De cette manière, vous interrogez uniquement le compartiment qui doit être lu, ce qui réduit le nombre de lignes de données devant être analysées. Lorsque vous sélectionnez une colonne à utiliser pour la compartimentation, sélectionnez la colonne présentant une cardinalité élevée (c'est-à-dire comportant de nombreuses valeurs distinctes), distribuée uniformément et fréquemment utilisée pour filtrer les données. Une clé primaire, telle qu'une colonne ID, est un exemple de colonne appropriée à utiliser pour la compartimentation. Pour plus d'informations sur la compartimentation dans Athena, consultez [Qu'est-ce que la compartimentation ?](ctas-partitioning-and-bucketing-what-is-bucketing.md). ## Utiliser des index AWS Glue de partition Vous pouvez utiliser les index de AWS Glue partition pour organiser les données dans une table en fonction des valeurs d'une ou de plusieurs partitions. AWS Glue les index de partition peuvent réduire le nombre de transferts de données, la quantité de données traitées et le temps de traitement des requêtes. Un index de AWS Glue partition est un fichier de métadonnées qui contient des informations sur les partitions de la table, notamment les clés de partition et leurs valeurs. L'index de partition est stocké dans un compartiment Amazon S3 et est mis à jour automatiquement au AWS Glue fur et à mesure que de nouvelles partitions sont ajoutées à la table. Lorsqu'un index de AWS Glue partition est présent, les requêtes tentent de récupérer un sous-ensemble des partitions au lieu de charger toutes les partitions de la table. Les requêtes s'exécutent uniquement sur le sous-jeu de données correspondant à la requête. Lorsque vous créez une table dans AWS Glue, vous pouvez créer un index de partition sur n'importe quelle combinaison de clés de partition définie sur la table. Après avoir créé un ou plusieurs index de partition sur une table, vous devez y ajouter une propriété permettant le filtrage des partitions. Ensuite, vous pouvez interroger la table à partir d'Athena. Pour plus d'informations sur la création d'index de partition dans AWS Glue, consultez la section [Utilisation des index de partition AWS Glue dans](https://docs.aws.amazon.com/glue/latest/dg/partition-indexes.html) le Guide du *AWS Glue développeur*. Pour plus d'informations sur l'ajout d'une propriété de table pour activer le filtrage des partitions, consultez [Optimisez les requêtes grâce à l'indexation et au filtrage des AWS Glue partitions](glue-best-practices-partition-index.md). ## Utiliser la compression des données et le fractionnement des fichiers La compression des données peut accélérer considérablement les requêtes si les fichiers ont une taille optimale ou s'ils peuvent être fractionnés en groupes logiques. En général, des taux de compression élevés nécessitent plus de cycles d'UC pour compresser et décompresser les données. Pour Athena, nous vous recommandons d'utiliser Apache Parquet ou Apache ORC, qui compressent les données par défaut. Pour plus d'informations sur la compression des données dans Athena, veuillez consulter [Utilisation de la compression dans Athena](compression-formats.md). Le fractionnement de fichiers augmente le parallélisme en permettant à Athena de répartir la tâche de lecture d'un seul fichier entre plusieurs lecteurs. Si un fichier unique n'est pas fractionnable, seul un lecteur peut lire le fichier tandis que les autres lecteurs sont inactifs. Apache Parquet et Apache ORC prennent également en charge les fichiers fractionnables. ## Utiliser les magasins de données en colonnes optimisés Les performances des requêtes Athena s'améliorent de manière significative si vous convertissez vos données dans un format en colonnes. Lorsque vous générez des fichiers en colonnes, l'une des techniques d'optimisation à prendre en compte consiste à ordonner les données en fonction de la clé de partition. Apache Parquet et Apache ORC sont des magasins de données en colonnes open source couramment utilisés. Pour plus d'informations sur la conversion d'une source de données Amazon S3 existante vers l'un de ces formats, consultez [Conversion dans des formats en colonnes](columnar-storage.md#convert-to-columnar). ### Utiliser une taille supérieure de bloc Parquet ou de bande ORC Parquet et ORC disposent de paramètres de stockage de données que vous pouvez régler pour les optimiser. Dans Parquet, vous pouvez optimiser la taille des blocs. Dans ORC, vous pouvez optimiser la taille des bandes. Plus le bloc ou la bande est grand(e), plus vous pouvez stocker de lignes dans chaque bloc ou bande. Par défaut, la taille de bloc Parquet est de 128 Mo et la taille de bande ORC est de 64 Mo. Si une bande ORC est inférieure à 8 Mo (valeur par défaut de `hive.orc.max_buffer_size`), Athena lit l'intégralité de la bande ORC. C'est le compromis qu'Athena fait entre la sélectivité des colonnes et les opérations d'entrée/sortie par seconde pour les bandes plus petites. Si vous avez des tables comportant un très grand nombre de colonnes, une petite taille de bloc ou de bande peut entraîner l'analyse d'un plus grand nombre de données que nécessaire. Dans ces cas, une taille de bloc plus grande peut s'avérer plus efficace. ### Utiliser ORC pour les types complexes Actuellement, lorsque vous interrogez les colonnes stockées dans Parquet qui ont des types de données complexes (par exemple `array`, `map` ou `struct`), Athena lit une ligne de données entière au lieu de lire sélectivement les colonnes spécifiées. Il s'agit d'un problème connu dans Athena. Pour contourner le problème, pensez à utiliser ORC. ### Choix d'un algorithme de compression Un autre paramètre que vous pouvez configurer est l'algorithme de compression des blocs de données. Pour plus d'informations sur les algorithmes de compression pris en charge pour Parquet et ORC dans Athena, consultez [Prise en charge de la compression Athena](https://docs.aws.amazon.com/athena/latest/ug/compression-formats.html). Pour plus d'informations sur l'optimisation des formats de stockage en colonnes dans Athena, consultez la section « Optimiser la génération de banques de données en colonnes » dans AWS le [billet de blog Big Data Les 10 meilleurs conseils d'optimisation des performances pour Amazon](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/) Athena. ## Utiliser les tables Iceberg Apache Iceberg est un format de table ouvert pour les jeux de données analytiques très volumineux conçu pour une utilisation optimisée sur Amazon S3. Vous pouvez utiliser les tables Iceberg pour permettre de réduire la limitation dans Amazon S3. Les tables Iceberg vous offrent les avantages suivants : + Vous pouvez partitionner les tables Iceberg sur une ou plusieurs colonnes. Cela permet d'optimiser l'accès aux données et de réduire la quantité de données devant être analysées par les requêtes. + Comme le mode de stockage d'objets Iceberg optimise les tables Iceberg pour qu'elles fonctionnent avec Amazon S3, il peut traiter des volumes de données importants et de lourdes charges de travail liées aux requêtes. + Les tables Iceberg en mode de stockage d'objets sont évolutives, tolérantes aux pannes et durables, ce qui peut contribuer à réduire la limitation. + La prise en charge des transactions ACID signifie que plusieurs utilisateurs peuvent ajouter et supprimer des objets Amazon S3 de manière atomique. Pour plus d'informations sur Apache Iceberg, consultez [Apache Iceberg](https://iceberg.apache.org/). Pour plus d'informations sur l'utilisation de tables Apache Iceberg dans Athena, consultez [Utilisation des tables Iceberg](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg.html). # Optimisation de vos requêtes Utilisez les suggestions de cette section pour optimiser vos requêtes SQL dans Athena. ## Utiliser LIMIT avec la clause ORDER BY La clause `ORDER BY` renvoie les données dans un ordre trié. Cela oblige Athena à envoyer toutes les lignes de données à un seul composant master, puis à trier les lignes. Ce type de requête peut s'exécuter pendant une longue période, voire échouer. Pour plus d'efficacité dans vos requêtes, examinez les *N* valeurs supérieures ou inférieures, puis utilisez également une `LIMIT` clause. Cela réduit considérablement le coût du tri en poussant le tri et la limitation vers des composants master individuels plutôt qu'à un seul composant master. ## Optimiser les clauses JOIN Lorsque vous joignez deux tables, Athena répartit la table de droite sur les composants master, puis diffuse la table de gauche pour effectuer la jointure. Pour cette raison, spécifiez la table la plus grande du côté gauche de la jointure et la plus petite du côté droit de la jointure. De cette manière, Athena utilise moins de mémoire et exécute la requête avec une latence plus faible. Notez également les points suivants : + Lorsque vous utilisez plusieurs commandes `JOIN`, spécifiez les tables de la plus grande à la plus petite. + Évitez les jointures croisées, sauf si elles sont requises par la requête. ## Optimiser les clauses GROUP BY L'opérateur `GROUP BY` répartit les lignes en fonction des colonnes `GROUP BY` sur les composants master. Ces colonnes sont référencées en mémoire et les valeurs sont comparées au fur et à mesure que les lignes sont ingérées. Les valeurs sont agrégées lorsque la colonne `GROUP BY` correspond. Compte tenu du fonctionnement de ce processus, il est conseillé d'ordonner les colonnes de la cardinalité la plus élevée à la plus faible. ## Utiliser des nombres au lieu des chaînes Comme les nombres nécessitent moins de mémoire et sont plus rapides à traiter que les chaînes, utilisez des nombres plutôt que des chaînes lorsque cela est possible. ## Limiter le nombre de colonnes Pour réduire la quantité totale de mémoire requise pour stocker vos données, limitez le nombre de colonnes spécifié dans votre instruction `SELECT`. ## Utiliser des expressions régulières au lieu de LIKE Les requêtes qui incluent des clauses, par exemple `LIKE '%string%'` sur de grandes chaînes, peuvent être très gourmandes en calculs. Lorsque vous filtrez plusieurs valeurs sur une colonne de chaîne, utilisez plutôt la fonction [regexp\$1like()](https://trino.io/docs/current/functions/regexp.html#regexp_like) et une expression régulière. Cela est particulièrement utile lorsque vous comparez une longue liste de valeurs. ## Utiliser la clause LIMIT Au lieu de sélectionner toutes les colonnes lorsque vous exécutez une requête, utilisez la clause `LIMIT` pour renvoyer uniquement celles dont vous avez besoin. Cela réduit la taille du jeu de données traité via le pipeline d'exécution des requêtes. Les clauses `LIMIT` sont plus utiles lorsque vous interrogez des tables comportant un grand nombre de colonnes basées sur des chaînes. Les clauses `LIMIT` sont également utiles lorsque vous effectuez plusieurs jointures ou agrégations sur une requête. # Ressources supplémentaires Pour plus d'informations sur le réglage des performances dans Athena, consultez les ressources suivantes : + AWS Article de blog sur le Big Data : [Les 10 meilleurs conseils d'optimisation des performances pour Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/). + AWS Article de blog sur le Big Data : [exécutez les requêtes 3 fois plus vite et réalisez jusqu'à 70 % d'économies sur le dernier moteur Amazon Athena](https://aws.amazon.com/blogs/big-data/run-queries-3x-faster-with-up-to-70-cost-savings-on-the-latest-amazon-athena-engine/) publié dans *AWS le blog Big Data*. + AWS Article de blog sur le Big Data : [Améliorez les requêtes fédérées grâce au push down de prédicats dans Amazon Athena.](https://aws.amazon.com/blogs/big-data/improve-federated-queries-with-predicate-pushdown-in-amazon-athena/) + Guide d’utilisation d’Amazon Simple Storage Service : [Best practices design patterns: optimizing Amazon S3 performance](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html) + Autres [articles du blog AWS  Big Data Blog concernant Athena](https://aws.amazon.com/blogs/big-data/tag/amazon-athena/) + [AWS  re:Post](https://repost.aws/tags/TA78iVOM7gR62_QqDe2-CmiA/amazon-athena) : poser une question avec la mention **Amazon Athena** + Consultez les [rubriques relatives à Athena dans le centre de AWS connaissances](https://aws.amazon.com/premiumsupport/knowledge-center/#Amazon_Athena). + Contact AWS Support (dans le AWS Management Console, cliquez sur **Support**, **Centre de support**) # Utilisation de la compression dans Athena Athena prend en charge divers formats de compression pour la lecture et l'écriture de données, y compris la lecture d'une table qui utilise plusieurs formats de compression. Par exemple, Athena peut lire avec succès les données d’une table qui utilise le format de fichier Parquet lorsque certains fichiers Parquet sont compressés avec Snappy et d’autres fichiers Parquet sont compressés avec GZIP. Le même principe s’applique aux formats de stockage ORC, fichier texte et JSON. ## Formats de compression pris en charge Athena prend en charge les formats de compression suivants : + **BZIP2** – Format qui utilise l'algorithme Burrows-Wheeler. + **DEFLATE** – Algorithme de compression basé sur [LZSS](https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Storer%E2%80%93Szymanski) et sur le [codage Huffman](https://en.wikipedia.org/wiki/Huffman_coding). [Deflate](https://en.wikipedia.org/wiki/Deflate) n'est pertinent que pour le format de fichier Avro. + **GZIP** – Algorithme de compression basé sur Deflate. Pour les tables Hive dans les versions 2 et 3 du moteur Athena, et les tables Iceberg dans la version 2 du moteur Athena, GZIP est le format de compression d’écriture par défaut des fichiers aux formats de stockage de fichier texte et Parquet. Les fichiers au format `tar.gz` ne sont pas pris en charge. + **LZ4**— Ce membre de la famille Lempel-Ziv 77 (LZ7) met également l'accent sur la vitesse de compression et de décompression plutôt que sur la compression maximale des données. LZ4 possède les formats de cadrage suivants : + **LZ4 Raw/Unframed — Implémentation** standard non encadrée du format de compression par blocs. LZ4 Pour plus d'informations, consultez la [description du format de LZ4 bloc](https://github.com/lz4/lz4/blob/dev/doc/lz4_Block_format.md) sur GitHub. + **LZ4 framed** — Implémentation de cadrage habituelle de. LZ4 Pour plus d'informations, consultez la [description du format de LZ4 cadre](https://github.com/lz4/lz4/blob/dev/doc/lz4_Frame_format.md) sur GitHub. + **LZ4 compatible avec hadoop** — Implémentation d'Apache Hadoop de. LZ4 Cette implémentation permet d'encapsuler LZ4 la compression avec la classe [BlockCompressorStream.java.](https://github.com/apache/hadoop/blob/f67237cbe7bc48a1b9088e990800b37529f1db2a/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/io/compress/BlockCompressorStream.java) + **LZO** – Format utilisant l'algorithme Lempel–Ziv–Oberhumer, qui se concentre sur une vitesse de compression et de décompression élevée plutôt que sur la compression maximale des données. LZO a deux implémentations : + **LZO standard** – Pour en savoir plus sur, consultez le [résumé](http://www.oberhumer.com/opensource/lzo/#abstract) LZO sur le site web d'Oberhumer. + **Compatible avec Hadoop LZO** [— Cette implémentation intègre l'algorithme LZO à la classe .java. BlockCompressorStream](https://github.com/apache/hadoop/blob/f67237cbe7bc48a1b9088e990800b37529f1db2a/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/io/compress/BlockCompressorStream.java) + **SNAPPY** — Algorithme de compression appartenant à la famille Lempel-Ziv 77 (). LZ7 Snappy met l'accent sur une vitesse de compression et de décompression élevée plutôt que sur la compression maximale des données. + **ZLIB** – Basé sur Deflate, ZLIB est le format de compression en écriture par défaut pour les fichiers au format de stockage de données ORC. Pour plus d'informations, consultez la page [zlib](https://github.com/madler/zlib) sur GitHub. + **ZSTD** – L'[algorithme de compression de données en temps réel Zstandard](http://facebook.github.io/zstd/) est un algorithme de compression rapide qui fournit des taux de compression élevés. La bibliothèque Zstandard (ZSTD) est fournie sous forme de logiciel open source utilisant une licence BSD. ZSTD est la compression par défaut pour les tables Iceberg. Lors de l’écriture de données compressées ZSTD, Athena utilise par défaut le niveau 3 de compression ZSTD. Pour plus d’informations sur l’utilisation des niveaux de compression ZSTD dans Athena, consultez [Utilisation des niveaux de compression ZSTD](compression-support-zstd-levels.md). **Note** Athena ne prend pas en charge l'écriture de fichiers Parquet compressés au format LZ4 LZO. La lecture de ces formats de compression est prise en charge. ## Spécification de formats de compression Lorsque vous écrivez des instructions CREATE TABLE ou CTAS, vous pouvez spécifier des propriétés de compression qui précisent le type de compression à utiliser lorsque Athena écrit dans ces tables. + Pour CTAS, consultez [Propriétés de la table CTAS](create-table-as.md#ctas-table-properties). Pour obtenir des exemples, consultez [Exemples de requêtes CTAS](ctas-examples.md). + Pour CREATE TABLE, consultez [ALTER TABLE SET TBLPROPERTIES](alter-table-set-tblproperties.md) pour obtenir la liste des propriétés de la table de compression. ## Spécification de l’absence de compression Les instructions CREATE TABLE prennent en charge l'écriture de fichiers non compressés. Pour écrire des fichiers non compressés, utilisez la syntaxe suivante : + CREATE TABLE (fichier texte ou JSON) — Dans `TBLPROPERTIES`, spécifiez `write.compression = NONE`. + CREATE TABLE (Parquet) — Dans `TBLPROPERTIES`, spécifiez `parquet.compression = UNCOMPRESSED`. + CREATE TABLE (ORC) — Dans `TBLPROPERTIES`, spécifiez `orc.compress = NONE`. ## Remarques et ressources + Actuellement, les extensions de fichier en majuscules telles que `.GZ` ou `.BZIP2` ne sont pas reconnues par Athena. Évitez d'utiliser des jeux de données avec des extensions de fichier en majuscules ou renommez les extensions des fichiers de données en minuscules. + Pour des données aux formats CSV, TSV et JSON, Athena détermine le type de compression à partir de l'extension de fichier. Si aucune extension de fichier n'est présente, Athena traite les données comme du texte brut non compressé. Si vos données sont compressées, assurez-vous que le nom de fichier comprend l'extension de compression, par exemple `gz`. + Le format de fichier ZIP n'est pas pris en charge. + Dans le cadre de l’interrogation des journaux Amazon Data Firehose depuis Athena, les formats pris en charge incluent la compression GZIP ou les fichiers ORC avec compression SNAPPY. + Pour plus d'informations sur l'utilisation de la compression, consultez la section 3 (« Compresser et diviser des fichiers ») du billet de blog AWS Big Data sur les [10 meilleurs conseils d'optimisation des performances pour Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/). **Topics** + [Spécification de formats de compression](#compression-support-specifying-compression-formats) + [Spécification de l’absence de compression](#compression-support-specifying-no-compression) + [Remarques et ressources](#compression-support-notes-and-resources) + [Compression de la table Hive](compression-support-hive.md) + [compression de la table Iceberg](compression-support-iceberg.md) + [Niveaux de compression ZSTD](compression-support-zstd-levels.md) # Utilisation de la compression des tables Hive Les options de compression des tables Hive dans Athena varient en fonction de la version du moteur et du format de fichier. ## Prise en charge de la compression Hive dans la version 3 du moteur Athena Le tableau suivant résume la prise en charge des formats de compression dans la version 3 du moteur Athena pour les formats de fichier de stockage dans Apache Hive. Le format de fichier texte inclut TSV, CSV, JSON et personnalisé SerDes pour le texte. La mention « Oui » ou « Non » dans une cellule s'applique de la même manière aux opérations de lecture et d'écriture, sauf indication contraire. Pour les besoins de cette table, les instructions CREATE TABLE, CTAS et INSERT INTO sont considérées comme des opérations d'écriture. Pour plus d’informations sur l’utilisation des niveaux de compression ZSTD sur Athena, consultez [Utilisation des niveaux de compression ZSTD](compression-support-zstd-levels.md). **** | | Avro | Ion | ORC | Parquet | Fichier texte | | --- | --- | --- | --- | --- | --- | | BZIP2 | Oui | Oui | Non | Non | Oui | | DEFLATE | Oui | Non | Non | Non | Non | | GZIP | Non | Oui | Non | Oui | Oui | | LZ4 | Non | Oui | Oui | Écriture - Non Lecture - Oui | Oui | | LZO | Non | Écriture - Non Lecture - Oui | Non | Écriture - Non Lecture - Oui | Écriture - Non Lecture - Oui | | SNAPPY | Oui | Oui | Oui | Oui | Oui | | ZLIB | Non | Non | Oui | Non | Non | | ZSTD | Oui | Oui | Oui | Oui | Oui | | NONE | Oui | Oui | Oui | Oui | Oui | # Utilisation de la compression des tables Iceberg Les options de compression des tables Iceberg dans Athena varient en fonction de la version du moteur et du format de fichier. ## Prise en charge de la compression Iceberg dans la version 3 du moteur Athena Le tableau suivant résume la prise en charge des formats de compression dans la version 3 du moteur Athena pour les formats de fichier de stockage dans Apache Iceberg. La mention « Oui » ou « Non » dans une cellule s'applique de la même manière aux opérations de lecture et d'écriture, sauf indication contraire. Pour les besoins de cette table, les instructions CREATE TABLE, CTAS et INSERT INTO sont considérées comme des opérations d'écriture. Le format de stockage par défaut pour Iceberg dans la version 3 du moteur Athena est Parquet. Le format de compression par défaut pour Iceberg dans la version 3 du moteur Athena est ZSTD. Pour plus d’informations sur l’utilisation des niveaux de compression ZSTD sur Athena, consultez [Utilisation des niveaux de compression ZSTD](compression-support-zstd-levels.md). **** | | Avro | ORC | Parquet (par défaut) | | --- | --- | --- | --- | | BZIP2 | Non | Non | Non | | GZIP | Oui | Non | Oui | | LZ4 | Non | Oui | Non | | SNAPPY | Oui | Oui | Oui | | ZLIB | Non | Oui | Non | | ZSTD | Oui | Oui | Oui (par défaut) | | NONE | Oui (précisez None ou Deflate) | Oui | Oui (précisez None ou Uncompressed) | # Utilisation des niveaux de compression ZSTD L’[algorithme de compression de données en temps réel Zstandard](http://facebook.github.io/zstd/) est un algorithme de compression rapide qui fournit des taux de compression élevés. La bibliothèque Zstandard est un logiciel open source qui utilise une licence BSD. Athena prend en charge la lecture et l’écriture de données ORC, Parquet et de fichiers texte compressés selon la norme ZSTD. Vous pouvez utiliser les niveaux de compression ZSTD pour ajuster le taux et la vitesse de compression en fonction de vos besoins. La bibliothèque ZSTD prend en charge des niveaux de compression compris entre 1 et 22. Athena utilise le niveau de compression ZSTD 3 par défaut. Les niveaux de compression offrent des compromis précis entre la vitesse de compression et le niveau de compression atteint. Des niveaux de compression plus faibles offrent une vitesse plus importante, mais des fichiers de plus grande taille. Par exemple, vous pouvez utiliser le niveau 1 si la vitesse est la plus importante et le niveau 22 si la taille est la plus importante. Le niveau 3 convient à de nombreux cas d’utilisation et constitue le niveau par défaut. Utilisez les niveaux supérieurs à 19 avec prudence, car ils nécessitent plus de mémoire. La bibliothèque ZSTD propose également des niveaux de compression négatifs qui étendent la plage de vitesses et de taux de compression. Pour plus d’informations, consultez le [RFC de compression Zstandard](https://datatracker.ietf.org/doc/html/rfc8478). L’abondance de niveaux de compression offre de nombreuses possibilités de réglage précis. Toutefois, assurez-vous de mesurer vos données et de prendre en compte les compromis lorsque vous décidez d’un niveau de compression. Nous vous recommandons d’utiliser le niveau 3 par défaut ou un niveau compris entre 6 et 9 pour obtenir un compromis raisonnable entre la vitesse de compression et la taille des données compressées. Réservez les niveaux 20 et plus pour les cas où la taille est la plus importante et où la vitesse de compression n’est pas un problème. ## Considérations et restrictions Lorsque vous utilisez le niveau de compression ZSTD dans Athena, tenez compte des points suivants. + La propriété `compression_level` ZSTD est prise en charge uniquement dans la version 3 du moteur Athena. + La propriété `compression_level` ZSTD est prise en charge pour les instructions `ALTER TABLE`, `CREATE TABLE`, `CREATE TABLE AS` (CTAS) et `UNLOAD`. + La propriété `compression_level` est facultative. + La propriété `compression_level` est prise en charge uniquement pour la compression ZSTD. + Les niveaux de compression possibles sont compris entre 1 et 22. + Le niveau de compression par défaut est le niveau 3. Pour de plus amples informations sur la prise en charge de la compression ZSTD Apache Hive dans Athena, consultez [Utilisation de la compression des tables Hive](compression-support-hive.md). Pour de plus amples informations sur la prise en charge de la compression ZSTD Apache Iceberg dans Athena, consultez [Utilisation de la compression des tables Iceberg](compression-support-iceberg.md). ## Spécification des niveaux de compression ZSTD Pour spécifier le niveau de compression ZSTD pour les instructions `ALTER TABLE`, `CREATE TABLE`, `CREATE TABLE AS` et `UNLOAD`, utilisez la propriété `compression_level`. Pour spécifier la compression ZSTD elle-même, vous devez utiliser la propriété de compression individuelle utilisée par la syntaxe de l’instruction. ### ALTER TABLE SET TBLPROPERTIES Dans la clause `SET TBLPROPERTIES` de l’instruction [ALTER TABLE SET TBLPROPERTIES](alter-table-set-tblproperties.md), spécifiez la compression ZSTD à l’aide de `'write.compression' = ' ZSTD'` ou de `'parquet.compression' = 'ZSTD'`. Utilisez ensuite la propriété `compression_level` pour spécifier une valeur comprise entre 1 et 22 (par exemple, ’`compression_level' = '5'`). Si vous ne spécifiez aucune propriété de niveau de compression, le niveau de compression est défini par défaut sur 3. #### Exemple L’exemple suivant modifie la table `existing_table` pour utiliser le format de fichier Parquet avec une compression ZSTD et un niveau de compression ZSTD 4. Notez que dans la clause `TBLPROPERTIES`, la valeur de niveau de compression doit être saisie sous la forme d’une chaîne plutôt que d’un entier et doit donc être placée entre guillemets simples ou doubles. ``` ALTER TABLE existing_table SET TBLPROPERTIES ('parquet.compression' = 'ZSTD', 'compression_level' = '4') ``` ### CREATE TABLE Dans la clause `TBLPROPERTIES` de l’instruction [CREATE TABLE](create-table.md), spécifiez '`write.compression' = 'ZSTD'` ou `'parquet.compression' = 'ZSTD'`, puis utilisez `compression_level = compression_level` et spécifiez une valeur comprise entre 1 et 22 sous la forme d’une chaîne. Si la propriété `compression_level` n’est pas spécifiée, le niveau de compression par défaut est 3. #### Exemple L’exemple suivant crée un tableau au format de fichier Parquet à l’aide de la compression ZSTD et du niveau de compression ZSTD 4. ``` CREATE EXTERNAL TABLE new_table ( `col0` string COMMENT '', `col1` string COMMENT '' ) STORED AS PARQUET LOCATION 's3://amzn-s3-demo-bucket/' TBLPROPERTIES ('write.compression' = 'ZSTD', 'compression_level' = '4') ``` ### CREATE TABLE AS (CTAS) Dans la clause `WITH` de l’instruction [CREATE TABLE AS](create-table-as.md), spécifiez `write_compression = 'ZSTD'` ou `parquet_compression = 'ZSTD'`, puis utilisez `compression_level = compression_level` et spécifiez une valeur comprise entre 1 et 22 sous la forme d’un entier. Si la propriété `compression_level` n’est pas spécifiée, le niveau de compression par défaut est 3. #### Exemple L’exemple CTAS suivant spécifie Parquet comme format de fichier utilisant la compression ZSTD avec un niveau de compression 4. Notez que dans la clause `WITH`, la valeur de niveau de compression doit être spécifiée sous la forme d’un entier, et non sous la forme d’une chaîne. ``` CREATE TABLE new_table WITH ( format = 'PARQUET', write_compression = 'ZSTD', compression_level = 4) AS SELECT * FROM old_table ``` ### UNLOAD Dans la clause `WITH` de l’instruction [UNLOAD](unload.md), spécifiez `compression = 'ZSTD'`, puis utilisez `compression_level = compression_level` et spécifiez une valeur comprise entre 1 et 22 sous la forme d’un entier. Si la propriété `compression_level` n’est pas spécifiée, le niveau de compression par défaut est 3. #### Exemple L’exemple suivant décharge les résultats de la requête vers l’emplacement spécifié à l’aide du format de fichier Parquet, de la compression ZSTD et du niveau de compression ZSTD 4. ``` UNLOAD (SELECT * FROM old_table) TO 's3://amzn-s3-demo-bucket/' WITH (format = 'PARQUET', compression = 'ZSTD', compression_level = 4) ``` # Balisage des ressources Athena Une identification est constituée d’une clé et d’une valeur que vous définissez. Lorsque vous étiquetez une ressource Athena, vous lui attribuez des métadonnées personnalisées. Vous pouvez utiliser des étiquettes pour classer vos ressources AWS de différentes manières, par exemple, par objectif, par propriétaire ou par environnement. Dans Athena, les ressources telles que les groupes de travail, les catalogues de données et les réserves de capacité sont des ressources étiquetables. Par exemple, vous pouvez créer un ensemble d'identifications pour les groupes de travail de votre compte, afin de vous aider à suivre les propriétaires de groupes de travail ou à identifier les groupes de travail grâce à leur objectif. Si vous activez également les balises en tant que balises de répartition des coûts dans la console de Billing and Cost Management, les coûts associés à l’exécution de requêtes apparaissent dans votre rapport sur les coûts et l’utilisation avec cette balise de répartition des coûts. Nous vous recommandons d'utiliser les AWS bonnes pratiques de balisage [https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html) pour créer un ensemble d'identifications cohérent capable de répondre aux exigences de votre organisation. Vous pouvez utiliser les étiquettes à l'aide de la console Athena ou des opérations d'API. **Topics** + [Principes de base des étiquettes](#tag-basics) + [Restrictions liées aux étiquettes](#tag-restrictions) + [Utilisation des balises pour les groupes de travail](tags-console.md) + [Utiliser les opérations d'API et de AWS CLI balises](tags-operations.md) + [Utilisation des politiques de contrôle d’accès IAM basé sur des balises](tags-access-control.md) ## Principes de base des étiquettes L'étiquette est une identification que vous attribuez à une ressource Athena. Chaque identification est constituée d'une clé et d'une valeur facultative que vous définissez. Les balises vous permettent de classer vos AWS ressources de différentes manières. Par exemple, vous pouvez définir un ensemble d'identifications pour les groupes de travail de votre compte vous permettant de suivre chaque propriétaire ou objectif de groupe de travail. Vous pouvez ajouter des étiquettes lors de la création d'un nouveau groupe de travail ou catalogue de données Athena, ou vous pouvez ajouter, modifier ou supprimer des étiquettes de ceux-ci. Vous pouvez modifier une identification dans la console. Si vous utilisez les opérations d'API, pour modifier une identification, supprimez l'ancienne et ajoutez-en une nouvelle. Si vous supprimez une ressource, les identifications associées à celle-ci seront également supprimées. Athena n'attribue pas automatiquement d'étiquettes à vos ressources. Vous pouvez modifier les clés et valeurs d'identification, et vous pouvez retirer des identifications d'une ressource à tout moment. Vous pouvez définir la valeur d'une identification sur une chaîne vide, mais vous ne pouvez pas définir la valeur d'une identification sur null. N'ajoutez pas de clés d'identification en double à la même ressource. Dans ce cas, Athena envoie un message d'erreur. Si vous utilisez l'action **TagResource** pour identifier une ressource à l'aide d'une clé d'identification existante, la nouvelle valeur d'identification remplace l'ancienne valeur. Dans IAM, vous pouvez contrôler quels utilisateurs de votre compte Amazon Web Services disposent d'autorisations de créer, modifier et supprimer ou répertorier des étiquettes. Pour de plus amples informations, veuillez consulter [Utilisation des politiques de contrôle d’accès IAM basé sur des balises](tags-access-control.md). Pour obtenir liste complète des actions des étiquettes Amazon Athena, consultez les noms des actions de l'API dans la rubrique [Référence d'API Amazon Athena](https://docs.aws.amazon.com/athena/latest/APIReference/). Vous pouvez utiliser des identifications pour la facturation. Pour plus d'informations, consultez la rubrique [Utilisation d'identifications pour la facturation](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html) dans le *guide de l'utilisateur AWS Billing and Cost Management *. Pour de plus amples informations, veuillez consulter [Restrictions liées aux étiquettes](#tag-restrictions). ## Restrictions liées aux étiquettes les identifications disposent des restrictions suivantes : + Dans Athena, vous pouvez baliser des groupes de travail, des catalogues de données et des réserves de capacité. Vous ne pouvez pas identifier de requêtes. + Le nombre maximum d'identifications par ressource est de 50. Pour rester dans la limite, vérifiez et supprimez les identifications non utilisées. + Pour chaque ressource, chaque clé d'identification doit être unique, et chaque clé d'identification peut avoir une seule valeur. N'ajoutez pas simultanément de clés d'identification dupliquées à la même ressource. Dans ce cas, Athena envoie un message d'erreur. Si vous identifiez une ressource à l'aide d'une clé d'identification existante en exécutant une action `TagResource` distincte, la nouvelle valeur d'identification remplace l'ancienne. + La longueur de la clé d'identification est comprise entre 1 et 128 caractères Unicode en UTF-8 + La longueur de la valeur d'identification est comprise entre 0 et 256 caractères Unicode en UTF-8 Les opérations de balisage, telles que l'ajout, la modification, la suppression ou la liste des identifications, exigent que vous spécifiez un ARN pour la ressource de groupe de travail. + Athena vous permet d'utiliser des lettres, des chiffres, des espaces représentés en UTF-8, ainsi que les caractères suivants : \$1 - = . \$1 : / @. + Les clés et valeurs d'identification sont sensibles à la casse. + Le `"aws:"` préfixe des clés de balise est réservé à l' AWS usage. Vous ne pouvez pas modifier ou supprimer des clés d'identification ayant ce préfixe. les identifications ayant ce préfixe ne sont pas comptabilisées dans votre limite d'identifications par ressource. + Les étiquettes que vous attribuez sont disponibles uniquement pour votre compte Amazon Web Services. # Utilisation des balises pour les groupes de travail À l'aide de la console Athena, vous pouvez voir quelles étiquettes sont en cours d'utilisation pour chaque groupe de travail de votre compte. Vous pouvez afficher des identifications uniquement par le groupe de travail. Vous pouvez également utiliser la console Athena pour appliquer, modifier ou supprimer des étiquettes dans un seul groupe de travail à la fois. Vous pouvez rechercher des groupes de travail à l'aide des identifications créées. **Topics** + [Affichage des balises de groupes de travail individuels](#tags-display) + [Ajout et suppression de balises sur un groupe de travail individuel](#tags-add-delete) ## Affichage des balises de groupes de travail individuels **Affichage des identifications d'un groupe de travail individuel dans la console Athena** 1. Ouvrez la console à l'adresse [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Si le panneau de navigation de la console n'est pas visible, choisissez le menu d'extension sur la gauche. ![\[Choisissez le menu d'expansion.\]](http://docs.aws.amazon.com/fr_fr/athena/latest/ug/images/nav-pane-expansion.png) 1. Dans le menu de navigation, choisissez **Workgroups** (Groupes de travail), puis choisissez le groupe de travail souhaité. 1. Effectuez l’une des actions suivantes : + Sélectionnez l'onglet **Tags** (Identifications). Si la liste des identifications est longue, utilisez la zone de recherche. + Choisissez **Edit** (Modifier), puis faites défiler jusqu'à la section **Tags** (Identifications). ## Ajout et suppression de balises sur un groupe de travail individuel Vous pouvez gérer les identifications d'un groupe de travail individuel directement à partir de l'onglet **Workgroups** (Groupes de travail). **Note** Si vous souhaitez que les utilisateurs ajoutent des étiquettes lorsqu'ils créent un groupe de travail dans la console ou transmettent des étiquettes lorsqu'ils utilisent l'action **CreateWorkGroup**, assurez-vous que vous accordez aux utilisateurs IAM des autorisations pour les actions **TagResource** et **CreateWorkGroup**. **Ajout d'une identification lors de la création d'un nouveau groupe de travail** 1. Ouvrez la console à l'adresse [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Dans le menu de navigation, choisissez **Workgroups** (Groupes de travail). 1. Choisissez **Create workgroup** (Créer un groupe de travail) et saisissez les valeurs nécessaires. Pour obtenir des instructions complètes, consultez [Créer un groupe de travail](creating-workgroups.md). 1. Dans la section **Tags** (Identifications), ajoutez une ou plusieurs identifications en spécifiant les clés et les valeurs. N'ajoutez pas simultanément de clés d'identification dupliquées au même groupe de travail. Dans ce cas, Athena envoie un message d'erreur. Pour de plus amples informations, veuillez consulter [Restrictions liées aux étiquettes](tags.md#tag-restrictions). 1. Une fois que vous avez terminé, choisissez **Create workgroup** (Créer un groupe de travail). **Pour ajouter une identification à un groupe de travail existant ou la modifier** 1. Ouvrez la console à l'adresse [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Dans le panneau de navigation, choisissez **Workgroups** (Groupes de travail). 1. Choisissez le groupe de travail à modifier. 1. Effectuez l’une des actions suivantes : + Choisissez l'onglet **Tags** (Identifications), puis **Manage tags** (Gérer les identifications). + Choisissez **Edit** (Modifier), puis faites défiler jusqu'à la section **Tags** (Identifications). 1. Spécifiez une clé et une valeur pour chaque identification. Pour de plus amples informations, veuillez consulter [Restrictions liées aux étiquettes](tags.md#tag-restrictions). 1. Choisissez **Enregistrer**. **Pour supprimer une identification d'un groupe de travail individuel** 1. Ouvrez la console à l'adresse [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Dans le panneau de navigation, choisissez **Workgroups** (Groupes de travail). 1. Choisissez le groupe de travail à modifier. 1. Effectuez l’une des actions suivantes : + Choisissez l'onglet **Tags** (Identifications), puis **Manage tags** (Gérer les identifications). + Choisissez **Edit** (Modifier) puis faites défiler jusqu'à la section **Tags** (Identifications). 1. Dans la liste des identifications, choisissez **Remove** (Supprimer) pour l'identification à supprimer, puis choisissez **Save** (Enregistrer). # Utiliser les opérations d'API et de AWS CLI balises Utilisez les opérations d'identification suivantes pour ajouter, supprimer ou répertorier des identifications sur une ressource. **** | API | INTERFACE DE LIGNE DE COMMANDE (CLI) | Description de l'action | | --- | --- | --- | | TagResource | tag-resource | Ajoutez ou remplacez une ou plusieurs identifications sur la ressource où l'ARN est spécifié. | | UntagResource | untag-resource | Supprimez une ou plusieurs identifications de la ressource ayant l'ARN spécifié. | | ListTagsForResource | list‑tags‑for‑resource | Répertorie une ou plusieurs identifications pour la ressource qui a l'ARN spécifié. | **Ajout de balises lors de la création d’une ressource** Pour ajouter des balises lorsque vous créez un groupe de travail ou un catalogue de données, utilisez le `tags` paramètre avec les opérations `CreateWorkGroup` ou `CreateDataCatalog` API ou avec les `create-data-catalog` commandes AWS CLI `create-work-group` or. ## Gestion des balises à l’aide d’actions d’API Les exemples suivants montrent comment utiliser les actions d’API de balisage pour gérer les balises sur les groupes de travail et les catalogues de données. Les exemples sont dans le langage de programmation Java. ### Exemple — TagResource L'exemple suivant ajoute deux identifications au groupe de travail   `workgroupA`: ``` List tags = new ArrayList<>(); tags.add(new Tag().withKey("tagKey1").withValue("tagValue1")); tags.add(new Tag().withKey("tagKey2").withValue("tagValue2")); TagResourceRequest request = new TagResourceRequest() .withResourceARN("arn:aws:athena:us-east-1:123456789012:workgroup/workgroupA") .withTags(tags); client.tagResource(request); ``` L'exemple suivant ajoute deux identifications au catalogue de données   `datacatalogA`: ``` List tags = new ArrayList<>(); tags.add(new Tag().withKey("tagKey1").withValue("tagValue1")); tags.add(new Tag().withKey("tagKey2").withValue("tagValue2")); TagResourceRequest request = new TagResourceRequest() .withResourceARN("arn:aws:athena:us-east-1:123456789012:datacatalog/datacatalogA") .withTags(tags); client.tagResource(request); ``` **Note** N'ajoutez pas de clés d'identification en double à la même ressource. Dans ce cas, Athena envoie un message d'erreur. Si vous identifiez une ressource à l'aide d'une clé d'identification existante en exécutant une action `TagResource` distincte, la nouvelle valeur d'identification remplace l'ancienne. ### Exemple — UntagResource L'exemple suivant supprime `tagKey2` du groupe de travail `workgroupA` : ``` List tagKeys = new ArrayList<>(); tagKeys.add("tagKey2"); UntagResourceRequest request = new UntagResourceRequest() .withResourceARN("arn:aws:athena:us-east-1:123456789012:workgroup/workgroupA") .withTagKeys(tagKeys); client.untagResource(request); ``` L'exemple suivant supprime `tagKey2` du catalogue de données `datacatalogA` : ``` List tagKeys = new ArrayList<>(); tagKeys.add("tagKey2"); UntagResourceRequest request = new UntagResourceRequest() .withResourceARN("arn:aws:athena:us-east-1:123456789012:datacatalog/datacatalogA") .withTagKeys(tagKeys); client.untagResource(request); ``` ### Exemple — ListTagsForResource L'exemple suivant répertorie les identifications du groupe de travail   `workgroupA`: ``` ListTagsForResourceRequest request = new ListTagsForResourceRequest() .withResourceARN("arn:aws:athena:us-east-1:123456789012:workgroup/workgroupA"); ListTagsForResourceResult result = client.listTagsForResource(request); List resultTags = result.getTags(); ``` L'exemple suivant répertorie les identifications du catalogue de données   `datacatalogA`: ``` ListTagsForResourceRequest request = new ListTagsForResourceRequest() .withResourceARN("arn:aws:athena:us-east-1:123456789012:datacatalog/datacatalogA"); ListTagsForResourceResult result = client.listTagsForResource(request); List resultTags = result.getTags(); ``` ## Gérez les balises à l'aide du AWS CLI Les exemples suivants montrent comment utiliser le pour AWS CLI créer et gérer des balises dans des catalogues de données. ### Ajout de balises à une ressource : tag-resource La commande `tag-resource` ajoute une ou plusieurs identifications à une ressource spécifiée. **Syntaxe** `aws athena tag-resource --resource-arn arn:aws:athena:region:account_id:datacatalog/catalog_name --tags Key=string,Value=string Key=string,Value=string` Le paramètre `--resource-arn` spécifie la ressource à laquelle les identifications sont ajoutées. Le paramètre `--tags` spécifie une liste de paires clé-valeur séparées par des espaces à ajouter en tant qu’identifications à la ressource. **Example** L'exemple suivant ajoute des identifications au catalogue de données `mydatacatalog`. ``` aws athena tag-resource --resource-arn arn:aws:athena:us-east-1:111122223333:datacatalog/mydatacatalog --tags Key=Color,Value=Orange Key=Time,Value=Now ``` Pour afficher le résultat, utilisez la commande `list-tags-for-resource`. Pour plus d'informations sur l'ajout de balises lors de l'utilisation de la commande `create-data-catalog`, consultez [Enregistrement d'un catalogue : Create-data-catalog](datastores-hive-cli.md#datastores-hive-cli-registering-a-catalog). ### Répertoriez les balises d'une ressource : list-tags-for-resource La commande `list-tags-for-resource` répertorie les identifications de la ressource spécifiée. **Syntaxe** `aws athena list-tags-for-resource --resource-arn arn:aws:athena:region:account_id:datacatalog/catalog_name` Le paramètre `--resource-arn` spécifie la ressource pour laquelle les identifications sont répertoriées. L'exemple suivant répertorie les identifications du catalogue de données `mydatacatalog`. ``` aws athena list-tags-for-resource --resource-arn arn:aws:athena:us-east-1:111122223333:datacatalog/mydatacatalog ``` L'exemple de résultat suivant est au format JSON. ``` { "Tags": [ { "Key": "Time", "Value": "Now" }, { "Key": "Color", "Value": "Orange" } ] } ``` ### Suppression des balises d’une ressource. : untag-resource La commande `untag-resource` supprime les clés d'identification spécifiées et leurs valeurs associées provenant de la ressource spécifiée. **Syntaxe** `aws athena untag-resource --resource-arn arn:aws:athena:region:account_id:datacatalog/catalog_name --tag-keys key_name [key_name ...]` Le paramètre `--resource-arn` spécifie la ressource à partir de laquelle les identifications sont supprimées. Le paramètre `--tag-keys` prend une liste de noms de clés séparés par des espaces. Pour chaque nom de clé spécifié, la commande `untag-resource` supprime à la fois la clé et sa valeur. L'exemple suivant supprime les clés `Color` et `Time`, et leurs valeurs issues de la ressource de catalogue `mydatacatalog`. ``` aws athena untag-resource --resource-arn arn:aws:athena:us-east-1:111122223333:datacatalog/mydatacatalog --tag-keys Color Time ``` # Utilisation des politiques de contrôle d’accès IAM basé sur des balises Le fait de disposer d'étiquettes vous permet d'écrire une politique IAM qui inclut le bloc `Condition` permettant de contrôler l'accès à une ressource en fonction de ses étiquettes. Cette section présente des exemples de stratégies de balisage pour les ressources des groupes de travail et des catalogues de données. ## Exemples de politique d'identification pour les groupes de travail ### Exemple : stratégie de balisage de base La politique IAM suivante vous permet d'exécuter des requêtes et d'interagir avec des étiquettes pour le groupe de travail nommé `workgroupA` : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "athena:ListWorkGroups", "athena:ListEngineVersions", "athena:ListDataCatalogs", "athena:ListDatabases", "athena:GetDatabase", "athena:ListTableMetadata", "athena:GetTableMetadata" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "athena:GetWorkGroup", "athena:TagResource", "athena:UntagResource", "athena:ListTagsForResource", "athena:StartQueryExecution", "athena:GetQueryExecution", "athena:BatchGetQueryExecution", "athena:ListQueryExecutions", "athena:StopQueryExecution", "athena:GetQueryResults", "athena:GetQueryResultsStream", "athena:CreateNamedQuery", "athena:GetNamedQuery", "athena:BatchGetNamedQuery", "athena:ListNamedQueries", "athena:DeleteNamedQuery", "athena:CreatePreparedStatement", "athena:GetPreparedStatement", "athena:ListPreparedStatements", "athena:UpdatePreparedStatement", "athena:DeletePreparedStatement" ], "Resource": "arn:aws:athena:us-east-1:123456789012:workgroup/workgroupA" } ] } ``` ------ ### Exemple : bloc de stratégie refusant des actions sur un groupe de travail basé sur une paire clé de balise-valeur de balise Les identifications associées à un groupe de travail existant sont appelées identifications de ressource. les identifications de ressources vous permettent d'écrire des blocs de politique comme les suivants qui refusent les actions répertoriées sur un groupe de travail marqué avec une paire clé-valeur comme `stack`, `production`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "athena:GetWorkGroup", "athena:UpdateWorkGroup", "athena:DeleteWorkGroup", "athena:TagResource", "athena:UntagResource", "athena:ListTagsForResource", "athena:StartQueryExecution", "athena:GetQueryExecution", "athena:BatchGetQueryExecution", "athena:ListQueryExecutions", "athena:StopQueryExecution", "athena:GetQueryResults", "athena:GetQueryResultsStream", "athena:CreateNamedQuery", "athena:GetNamedQuery", "athena:BatchGetNamedQuery", "athena:ListNamedQueries", "athena:DeleteNamedQuery", "athena:CreatePreparedStatement", "athena:GetPreparedStatement", "athena:ListPreparedStatements", "athena:UpdatePreparedStatement", "athena:DeletePreparedStatement" ], "Resource": "arn:aws:athena:us-east-1:123456789012:workgroup/*", "Condition": { "StringEquals": { "aws:ResourceTag/stack": "production" } } } ] } ``` ------ ### Exemple : bloc de stratégie limitant les demandes d’action de changement de balise aux balises spécifiées Les identifications qui sont transmises en tant que paramètres aux opérations qui modifient les identifications (par exemple `TagResource`, `UntagResource` ou `CreateWorkGroup` avec des identifications) sont appelées identifications de requête. L'exemple de bloc de politique suivant n'autorise l'opération `CreateWorkGroup` que si l'une des identifications passées a la clé `costcenter` et la valeur `1`, `2` ou `3`. **Note** Si vous voulez permettre à un rôle IAM de transmettre des identifications dans le cadre d'une opération `CreateWorkGroup`, assurez-vous d'accorder au rôle des autorisations pour les actions `TagResource` et `CreateWorkGroup`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "athena:CreateWorkGroup", "athena:TagResource" ], "Resource": "arn:aws:athena:us-east-1:123456789012:workgroup/*", "Condition": { "StringEquals": { "aws:RequestTag/costcenter": [ "1", "2", "3" ] } } } ] } ``` ------ ## Exemples de politique d'identification pour les catalogues de données ### Exemple : stratégie de balisage de base La politique IAM suivante vous permet d'interagir avec les étiquettes pour le catalogue de données nommé `datacatalogA` : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "athena:ListWorkGroups", "athena:ListEngineVersions", "athena:ListDataCatalogs", "athena:ListDatabases", "athena:GetDatabase", "athena:ListTableMetadata", "athena:GetTableMetadata" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "athena:GetWorkGroup", "athena:TagResource", "athena:UntagResource", "athena:ListTagsForResource", "athena:StartQueryExecution", "athena:GetQueryExecution", "athena:BatchGetQueryExecution", "athena:ListQueryExecutions", "athena:StopQueryExecution", "athena:GetQueryResults", "athena:GetQueryResultsStream", "athena:CreateNamedQuery", "athena:GetNamedQuery", "athena:BatchGetNamedQuery", "athena:ListNamedQueries", "athena:DeleteNamedQuery" ], "Resource": [ "arn:aws:athena:us-east-1:123456789012:workgroup/*" ] }, { "Effect": "Allow", "Action": [ "athena:CreateDataCatalog", "athena:GetDataCatalog", "athena:UpdateDataCatalog", "athena:DeleteDataCatalog", "athena:ListDatabases", "athena:GetDatabase", "athena:ListTableMetadata", "athena:GetTableMetadata", "athena:TagResource", "athena:UntagResource", "athena:ListTagsForResource" ], "Resource": "arn:aws:athena:us-east-1:123456789012:datacatalog/datacatalogA" } ] } ``` ------ ### Exemple : bloc de stratégie refusant des actions sur un catalogue de données basé sur une paire clé de balise-valeur de balise Vous pouvez utiliser des identifications de ressource pour écrire des blocs de politique qui refusent des actions spécifiques sur les catalogues de données qui sont balisés avec des paires clé-valeur d'identification spécifiques. L'exemple de politique suivant refuse les actions sur les catalogues de données qui ont la paire clé-valeur d'identification `stack`, `production`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "athena:CreateDataCatalog", "athena:GetDataCatalog", "athena:UpdateDataCatalog", "athena:DeleteDataCatalog", "athena:GetDatabase", "athena:ListDatabases", "athena:GetTableMetadata", "athena:ListTableMetadata", "athena:StartQueryExecution", "athena:TagResource", "athena:UntagResource", "athena:ListTagsForResource" ], "Resource": "arn:aws:athena:us-east-1:123456789012:datacatalog/*", "Condition": { "StringEquals": { "aws:ResourceTag/stack": "production" } } } ] } ``` ------ ### Exemple : bloc de stratégie limitant les demandes d’action de changement de balise aux balises spécifiées Les identifications qui sont transmises en tant que paramètres aux opérations qui modifient les identifications (par exemple `TagResource`, `UntagResource` ou `CreateDataCatalog` avec des identifications) sont appelées identifications de requête. L'exemple de bloc de politique suivant n'autorise l'opération `CreateDataCatalog` que si l'une des identifications passées a la clé `costcenter` et la valeur `1`, `2` ou `3`. **Note** Si vous voulez permettre à un rôle IAM de transmettre des identifications dans le cadre d'une opération `CreateDataCatalog`, assurez-vous d'accorder au rôle des autorisations pour les actions `TagResource` et `CreateDataCatalog`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "athena:CreateDataCatalog", "athena:TagResource" ], "Resource": "arn:aws:athena:us-east-1:123456789012:datacatalog/*", "Condition": { "StringEquals": { "aws:RequestTag/costcenter": [ "1", "2", "3" ] } } } ] } ``` ------ # Service Quotas **Note** La console Service Quotas fournit des informations sur les quotas dans Amazon Athena. Vous pouvez également utiliser la console Service Quotas pour [demander des augmentations de quota](https://console.aws.amazon.com/servicequotas/home?region=us-east-1#!/services/athena/quotas) pour les quotas ajustables. Pour connaître les limites de schéma associées à AWS Glue , consultez la page [Points de terminaison et quotas AWS Glue](https://docs.aws.amazon.com/general/latest/gr/glue.html). Pour des informations générales sur les quotas AWS de service, consultez la section sur [les quotas de AWS service](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) dans le *Références générales AWS*. ## Requêtes Votre compte dispose des quotas de requête par défaut suivants pour Amazon Athena. Pour obtenir des détails, consultez la page [Points de terminaison et quotas Amazon Athena](https://docs.aws.amazon.com/general/latest/gr/athena.html#amazon-athena-limits) de la Références générales AWS. + **Requêtes DDL actives** – Nombre de requêtes DDL actives. Les requêtes DDL comprennent les requêtes `CREATE TABLE` et `ALTER TABLE ADD PARTITION`. + **Expiration d'une requête DDL** – Durée maximale, en minutes, pendant laquelle une requête DDL peut s'exécuter avant son annulation. + **Requêtes DML actives** – Nombre de requêtes DML actives. Les requêtes DML comprennent `SELECT`, `CREATE TABLE AS` (CTAS) et des requêtes `INSERT INTO`. Les quotas spécifiques varient selon la région AWS . + **Expiration d'une requête DML** – Durée maximale, en minutes, pendant laquelle une requête DML peut s'exécuter avant son annulation. Vous pouvez demander une augmentation de ce délai d'attente jusqu'à un maximum de 240 minutes. Pour demander des augmentations de quota, vous pouvez utiliser la console [Service Quotas Athena](https://console.aws.amazon.com/servicequotas/home?region=us-east-1#!/services/athena/quotas). Athena traite les requêtes en affectant des ressources en se basant sur la charge globale du service et le nombre de demandes entrantes. Vos requêtes peuvent être temporairement mises en attente avant d'être exécutées. Les processus asynchrones récupèrent les requêtes dans les files d'attente et les exécutent sur les ressources physiques dès que celles-ci sont disponibles et aussi longtemps que la configuration de votre compte le permet. Les quotas de requêtes DML et DDL actives incluent les requêtes en cours d’exécution et en file d’attente. Par exemple, si votre quota de requêtes Active DML est de 25 et que le nombre total de requêtes en cours et en file d'attente est de 26, la requête 26 provoquera une erreur. TooManyRequestsException **Note** Si vous souhaitez contrôler directement la simultanéité des requêtes que vous exécutez dans Athena, vous pouvez utiliser les réserves de capacité. Pour de plus amples informations, veuillez consulter [Gestion de la capacité de traitement des requêtes](capacity-management.md). ### Longueur de chaîne de requête La longueur de chaîne de requête maximum autorisée est de 262 144 octets, où les chaînes sont encodées en UTF-8. Il ne s'agit pas d'un quota ajustable. Toutefois, vous pouvez contourner cette limitation en divisant les longues requêtes en plusieurs petites requêtes. Pour plus d'informations, consultez la rubrique [Comment augmenter la longueur maximale de la chaîne de requête dans Athena ?](https://aws.amazon.com/premiumsupport/knowledge-center/athena-query-string-length/) dans le Centre de connaissances AWS . ## Groupes de travail Lorsque vous travaillez avec des groupes de travail Athena, n'oubliez pas les points suivants : + Les Service Quotas (Service Quotas) Athena sont partagés entre tous les groupes de travail d'un compte. + Le nombre maximal de groupes de travail que vous pouvez créer par région dans votre compte est de 1 000. + Le nombre maximal d'instructions préparées dans un groupe de travail est de 1 000. + Le nombre maximum d'identifications par groupe de travail est de 50. Pour de plus amples informations, veuillez consulter [Restrictions liées aux étiquettes](tags.md#tag-restrictions). ## Bases de données, tables et partitions Athéna utilise le. AWS Glue Data Catalog Pour connaître les quotas de service pour les tables, les bases de données et les partitions (par exemple, le nombre maximal de bases de données ou tables par compte), consultez [AWS Glue endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/glue.html). Notez que, bien qu'Athena prenne en charge l'interrogation de AWS Glue tables contenant 10 millions de partitions, Athena ne peut pas lire plus d'un million de partitions en un seul scan. ## Compartiments Amazon S3 Lorsque vous travaillez avec des compartiments Simple Storage Service (Amazon S3), rappelez-vous les points suivants : + Amazon S3 dispose d'un quota de service par défaut de 10 000 compartiments par compte. + Athena a également besoin d'un compartiment distinct pour journaliser les résultats. + Vous pouvez demander une augmentation de quota jusqu’à un million de compartiments Amazon S3 par compte AWS . ## Quotas d'appel d'API par compte Athena APIs dispose de quotas par défaut pour le nombre d'appels à l'API par compte (et non par requête). Pour une liste complète des quotas par défaut, consultez le tableau [des quotas de service](https://docs.aws.amazon.com/general/latest/gr/athena.html#amazon-athena-limits) du Références générales AWS guide. Si vous utilisez l'une de ces options APIs et que vous dépassez le quota par défaut pour le nombre d'appels par seconde ou la capacité de rafale de votre compte, l'API Athena émet une erreur similaire à la suivante : « » ClientError : Une erreur s'est produite (ThrottlingException) lors de l'appel de l'**opération : Dépassement du débit. » Réduisez le nombre d'appels par seconde ou la capacité de transmission en mode rafale pour l'API pour ce compte. Vous pouvez modifier le quota Athena pour les appels d’API par compte dans la [console Athena Service Quotas](https://console.aws.amazon.com/servicequotas/home?region=us-east-1#!/services/athena/quotas).