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.

# Optimisation des performances d’Athena
<a name="performance-tuning"></a>

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
<a name="performance-tuning-service-level-considerations"></a>

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
<a name="performance-tuning-service-quotas"></a>

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
<a name="performance-tuning-quotas-in-other-services"></a>

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
<a name="performance-tuning-resource-limits"></a>

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
<a name="performance-tuning-query-optimization-techniques"></a>

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
<a name="performance-tuning-optimizing-joins"></a>

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
<a name="performance-tuning-distributed-hash-join"></a>

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
<a name="performance-tuning-other-join-types"></a>

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
<a name="performance-tuning-optimizing-window-functions"></a>

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
<a name="performance-tuning-optimizing-window-functions-rewrite"></a>

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
<a name="performance-tuning-optimizing-aggregations"></a>

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
<a name="performance-tuning-optimizing-top-n-queries"></a>

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
<a name="performance-tuning-include-only-required-columns"></a>

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
<a name="performance-tuning-optimizing-queries-by-using-approximations"></a>

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
<a name="performance-tuning-optimizing-like"></a>

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
<a name="performance-tuning-use-union-all-instead-of-union"></a>

 `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
<a name="performance-tuning-use-unload-for-large-result-sets"></a>

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
<a name="performance-tuning-use-ctas-or-glue-etl-to-materialize-frequently-used-aggregations"></a>

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
<a name="performance-tuning-reuse-query-results"></a>

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
<a name="performance-tuning-data-optimization-techniques"></a>

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
<a name="performance-tuning-partition-your-data"></a>

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
<a name="performance-tuning-pick-partition-keys-that-will-support-your-queries"></a>

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
<a name="performance-tuning-avoid-optimizing-for-rare-queries"></a>

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
<a name="performance-tuning-use-partition-projection"></a>

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
<a name="performance-tuning-use-partition-indexes"></a>

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
<a name="performance-tuning-always-use-string-as-the-type-for-partition-keys"></a>

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
<a name="performance-tuning-remove-old-and-empty-partitions"></a>

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é
<a name="performance-tuning-query-partitions-by-equality"></a>

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
<a name="performance-tuning-avoid-using-msck-repair-table-for-partition-maintenance"></a>

É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
<a name="performance-tuning-validate-that-your-queries-are-compatible-with-the-partitioning-scheme"></a>

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
<a name="performance-tuning-use-columnar-file-formats"></a>

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
<a name="performance-tuning-compress-data"></a>

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
<a name="performance-tuning-use-bucketing-for-lookups-on-keys-with-high-cardinality"></a>

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
<a name="performance-tuning-disadvantages-of-bucketing"></a>

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
<a name="performance-tuning-avoid-having-too-many-files"></a>

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
<a name="performance-tuning-avoid-additional-storage-hierarchies-beyond-the-partition"></a>

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
<a name="performance-tuning-use-symlinktextinputformat-only-when-necessary"></a>

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
<a name="columnar-storage"></a>

[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
<a name="columnar-storage-choosing"></a>

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
<a name="convert-to-columnar"></a>

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
<a name="ctas-partitioning-and-bucketing"></a>

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 ?
<a name="ctas-partitioning-and-bucketing-what-is-partitioning"></a>

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
<a name="ctas-partitioning-and-bucketing-deciding-how-to-partition"></a>

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
<a name="ctas-partitioning-and-bucketing-creating-a-partitioned-table"></a>

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
<a name="ctas-partitioning-and-bucketing-querying-partitioned-tables"></a>

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
<a name="ctas-partitioning-and-bucketing-partitioned-table-example-queries"></a>

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 ?
<a name="ctas-partitioning-and-bucketing-what-is-bucketing"></a>

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
<a name="ctas-partitioning-and-bucketing-bucketing-benefits"></a>

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
<a name="ctas-partitioning-and-bucketing-data-types-supported-for-filtering-on-bucketed-columns"></a>

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
<a name="ctas-partitioning-and-bucketing-hive-and-spark-support"></a>

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
<a name="ctas-partitioning-and-bucketing-bucketing-create-table-example"></a>

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)
<a name="ctas-partitioning-and-bucketing-bucketing-create-table-as-example"></a>

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
<a name="ctas-partitioning-and-bucketing-bucketing-query-example"></a>

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
<a name="ctas-partitioning-and-bucketing-additional-resources"></a>
+ 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
<a name="partitions"></a>

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
<a name="partitions-considerations-limitations"></a>

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
<a name="partitions-creating-loading"></a>

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
<a name="partitions-preparing-data"></a>

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
<a name="scenario-1-data-already-partitioned-and-stored-on-s3-in-hive-format"></a>

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
<a name="creating-a-table"></a>

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<modelLookup:string, requestTime:string>,
    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
<a name="run-msck-repair-table"></a>

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
<a name="query-the-data"></a>

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
<a name="scenario-2-data-is-not-partitioned"></a>

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
<a name="run-alter-table-add-partition"></a>

É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
<a name="partitions-partition-projection"></a>

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
<a name="partitions-additional-resources"></a>
+ 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
<a name="partition-projection"></a>

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
<a name="partition-projection-pruning-vs-projection"></a>

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
<a name="partition-projection-using"></a>

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
<a name="partition-projection-use-cases"></a>

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
<a name="partition-projection-known-data-structures"></a>

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
<a name="partition-projection-custom-s3-storage-locations"></a>

Par défaut, Athena construit des emplacements de partition à l'aide du formulaire `s3://amzn-s3-demo-bucket/<table-root>/partition-col-1=<partition-col-1-val>/partition-col-2=<partition-col-2-val>/`, 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
<a name="partition-projection-considerations-and-limitations"></a>

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
<a name="partition-projection-video"></a>

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
<a name="partition-projection-setting-up"></a>

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
<a name="partition-projection-specifying-custom-s3-storage-locations"></a>

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
<a name="partition-projection-supported-types"></a>

Une table peut avoir n'importe quelle combinaison de types de colonnes de partition `enum`, `integer`, `date,` ou `injected`.

## Type d'énumération
<a name="partition-projection-enum-type"></a>

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
<a name="partition-projection-integer-type"></a>

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
<a name="partition-projection-date-type"></a>

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é
<a name="partition-projection-injected-type"></a>

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
<a name="partition-projection-dynamic-id-partitioning"></a>

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`
<a name="partition-projection-injection"></a>

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
<a name="partition-projection-kinesis-firehose-example"></a>

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`
<a name="partition-projection-kinesis-firehose-example-using-the-date-type"></a>

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
<a name="partition-projection-kinesis-firehose-example-choosing-partition-keys"></a>

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
<a name="partition-projection-kinesis-firehose-example-partition-key-types-and-partition-projection-types"></a>

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
<a name="partition-projection-kinesis-firehose-example-using-custom-prefixes-and-dynamic-partitioning"></a>

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
<a name="partition-projection-kinesis-firehose-example-iso-formatted-dates"></a>

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
<a name="performance-tuning-s3-throttling"></a>

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
<a name="performance-tuning-s3-throttling-reduce-throttling-at-the-service-level"></a>

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
<a name="performance-tuning-s3-throttling-optimizing-your-tables"></a>

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
<a name="performance-tuning-s3-throttling-use-partitioning"></a>

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
<a name="performance-tuning-s3-throttling-bucket-your-data"></a>

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
<a name="performance-tuning-s3-throttling-use-aws-glue-partition-indexes"></a>

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
<a name="performance-tuning-s3-throttling-use-data-compression-and-file-splitting"></a>

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
<a name="performance-tuning-s3-throttling-use-optimized-columnar-data-stores"></a>

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
<a name="performance-tuning-s3-throttling-use-a-larger-parquet-block-size-or-orc-stripe-size"></a>

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
<a name="performance-tuning-s3-throttling-use-orc-for-complex-types"></a>

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
<a name="performance-tuning-s3-throttling-choose-a-compression-algorithm"></a>

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
<a name="performance-tuning-s3-throttling-use-iceberg-tables"></a>

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
<a name="performance-tuning-s3-throttling-optimizing-queries"></a>

Utilisez les suggestions de cette section pour optimiser vos requêtes SQL dans Athena.

## Utiliser LIMIT avec la clause ORDER BY
<a name="performance-tuning-s3-throttling-use-limit-with-the-order-by-clause"></a>

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
<a name="performance-tuning-s3-throttling-optimize-join-clauses"></a>

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
<a name="performance-tuning-s3-throttling-optimize-group-by-clauses"></a>

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
<a name="performance-tuning-s3-throttling-use-numbers-instead-of-strings"></a>

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
<a name="performance-tuning-s3-throttling-limit-the-number-of-columns"></a>

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
<a name="performance-tuning-s3-throttling-use-regular-expressions-instead-of-like"></a>

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
<a name="performance-tuning-s3-throttling-use-the-limit-clause"></a>

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
<a name="performance-tuning-additional-resources"></a>

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**)