Réglage de performances dans Athena - Amazon Athena
Quotas de serviceLimites des ressourcesTechniques d'optimisation des requêtesTechniques d'optimisation des donnéesRessources supplémentaires

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.

Réglage de performances dans Athena

Cette rubrique fournit des informations générales et des suggestions spécifiques pour améliorer les performances de vos requêtes Athena, et explique comment contourner les erreurs liées aux limites et à l'utilisation des ressources.

Quotas de service

Athena applique des quotas pour les métriques telles que la durée d'exécution des requêtes, le nombre de requêtes simultanées dans un compte et les taux de demandes d'API. Pour de plus amples informations sur ces quotas, consultez Service Quotas. Le dépassement de ces quotas entraîne l'échec d'une requête, soit lors de son envoi, soit lors de son exécution.

La plupart des conseils d'optimisation des performances présentés sur cette page peuvent contribuer à réduire la durée d'exécution des requêtes. L'optimisation libère de la capacité afin que vous puissiez exécuter davantage de requêtes dans les limites du quota de simultanéité et évite que les requêtes ne soient annulées pour cause de trop longue durée.

Les quotas relatifs au nombre de requêtes simultanées et de demandes d'API sont calculés par Compte AWS et Région AWS. Nous recommandons d'exécuter une charge de travail par charge de travail Compte AWS (ou d'utiliser des réservations de capacité provisionnées distinctes) pour éviter que les charges de travail ne soient en concurrence pour le même quota.

Si vous exécutez deux charges de travail dans le même compte, l'une des charges de travail peut exécuter une rafale de requêtes. Cela peut entraîner une limitation de la charge de travail restante ou l'empêcher d'exécuter des requêtes. Pour éviter cela, vous pouvez déplacer les charges de travail vers des comptes distincts afin de donner à chaque charge de travail son propre quota de simultanéité. La création d'une réserve de capacité allouée pour l'une ou les deux charges de travail permet d'atteindre le même objectif.

Quotas dans d'autres services

Lorsqu'Athena exécute une requête, il peut appeler d'autres services qui appliquent des quotas. Pendant l'exécution des requêtes, Athena peut effectuer des appels d'API vers Amazon S3 et d'autres AWS services tels que IAM et. AWS Glue Data Catalog AWS KMS Si vous utilisez des requêtes fédérées, 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 des erreurs pertinentes sont abordées dans ce document.

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 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 dans le Guide de l'utilisateur Amazon S3.

Limites des ressources

Athena exécute des requêtes dans un moteur de requête distribué. Lorsque vous soumettez une requête, le planificateur de requêtes du moteur Athena estime la capacité de calcul requise pour exécuter la requête et prépare un cluster de nœuds de calcul en conséquence. Certaines requêtes, telles que les requêtes DDL, ne s'exécutent que sur un seul nœud. Les requêtes complexes portant sur des jeux de données volumineux s'exécutent sur des clusters beaucoup plus importants. Les nœuds sont uniformes, avec les mêmes configurations de mémoire, d'UC et de disque. Athena monte en puissance, mais n'augmente pas en capacité, pour traiter des requêtes plus exigeantes.

Parfois, les exigences d'une requête dépassent les ressources disponibles pour le cluster exécutant la requête. Dans ce cas, la requête échoue avec le message d'erreur La requête a épuisé les ressources à ce facteur d'échelle.

La ressource la plus souvent épuisée est la mémoire, mais dans de rares cas, il peut également s'agir d'espace disque. Les erreurs de mémoire se produisent généralement lorsque le moteur exécute une fonction de jointure ou de fenêtrage, mais elles peuvent également se produire lors de comptages et d'agrégations distincts.

Même si une requête échoue une fois avec une erreur « manque de ressources », elle peut réussir lorsque vous l'exécutez à nouveau. L'exécution des requêtes n'est pas déterministe. Des facteurs tels que le temps nécessaire au chargement des données et la manière dont les jeux de données intermédiaires sont répartis sur les nœuds peuvent entraîner une utilisation différente des ressources. Par exemple, imaginez une requête qui joint deux tables et dont la distribution des valeurs pour la condition de jointure est fortement asymétrique. Une telle requête peut réussir la plupart du temps, mais échouer parfois lorsque les valeurs les plus courantes finissent par être traitées par le même nœud.

Pour éviter que vos requêtes n'excèdent les ressources disponibles, suivez les conseils de réglage des performances mentionnés dans ce document. En particulier, pour obtenir des conseils sur la manière d'optimiser les requêtes qui épuisent les ressources disponibles, consultez Optimisation des jointures, Optimisation des fonctions de fenêtrage et Optimisation des requêtes à l'aide d'approximations.

Techniques d'optimisation des requêtes

Utilisez les techniques d'optimisation des requêtes décrites dans cette section pour accélérer l'exécution des requêtes ou pour contourner les requêtes qui dépassent les limites de ressources dans Athena.

Optimisation des jointures

Il existe de nombreuses stratégies différentes pour exécuter des jointures dans un moteur de requête distribué. Les deux plus courantes sont les jointures par hachage distribuées et les requêtes comportant des conditions de jointure complexes.

Jointure par hachage distribuée

Le type de jointure le plus courant utilise une comparaison d'égalité comme condition de jointure. Athena exécute ce type de jointure en tant que jointure par hachage distribuée.

Dans une jointure par hachage distribuée, le moteur crée une table de recherche (table de hachage) à partir de l'un des côtés de la jointure. Ce côté est appelé côté build. Les enregistrements du côté build sont répartis entre les nœuds. Chaque nœud crée une table de recherche pour son sous-ensemble. L'autre côté de la jointure, appelé côté sonde, est ensuite diffusé via les nœuds. Les enregistrements du côté sonde sont répartis sur les nœuds de la même manière que du côté build. Cela permet à chaque nœud d'effectuer la jointure en recherchant les enregistrements correspondants dans sa propre table de recherche.

Lorsque les tables de recherche créées à partir du côté build de la jointure ne rentrent pas dans la mémoire, les requêtes peuvent échouer. Même si la taille totale du côté build est inférieure à la mémoire disponible, les requêtes peuvent échouer si la répartition des enregistrements présente une asymétrie importante. Dans un cas extrême, tous les enregistrements peuvent avoir la même valeur pour la condition de jointure et doivent être conservés en mémoire sur un seul nœud. Même une requête moins asymétrique peut échouer si un ensemble de valeurs est envoyé au même nœud et que le total des valeurs dépasse la mémoire disponible. Les nœuds ont la capacité de répartir des enregistrements sur le disque, mais le déversement ralentit l'exécution des requêtes et peut s'avérer insuffisant pour empêcher l'échec de la requête.

Athena tente de réorganiser les jointures pour utiliser la relation la plus grande comme côté sonde, et la plus petite relation comme côté build. Cependant, comme Athena ne gère pas les données contenues dans les tables, il dispose de peu d'informations et doit souvent partir du principe que la première table est la plus grande et la seconde la plus petite.

Lorsque vous écrivez des jointures avec des conditions de jointure basées sur l'égalité, supposez que la table située à gauche du mot-clé JOIN correspond au côté sonde et que la table de droite correspond au côté build. Assurez-vous que la bonne table, le côté build, est la plus petite des tables. S'il n'est pas possible de réduire le côté build de la jointure suffisamment pour tenir en mémoire, envisagez d'exécuter plusieurs requêtes qui joignent des sous-ensembles de la table de build.

Autres types de jointure

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 et Explication des résultats de l'instruction EXPLAIN d'Athena.

Optimisation des fonctions de fenêtrage

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.

Utiliser des fonctions autres que de fenêtrage à la place

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_by, min_by et arbitrary.

Supposons, par exemple, que vous disposiez d'un jeu de données actualisé par un capteur. Le capteur indique régulièrement l'état de la batterie et inclut certaines métadonnées, telles que l'emplacement. Si vous souhaitez connaître le dernier état de la batterie de chaque capteur et son emplacement, vous pouvez utiliser cette requête :

SELECT sensor_id,
       arbitrary(location) AS location,
       max_by(battery_status, updated_at) AS battery_status
FROM sensor_readings
GROUP BY sensor_id

Les métadonnées telles que l'emplacement étant les mêmes pour chaque enregistrement, vous pouvez utiliser la fonction arbitrary pour sélectionner n'importe quelle valeur dans le groupe.

Pour connaître le dernier état de la batterie, vous pouvez utiliser la fonction max_by. La fonction max_by sélectionne la valeur d'une colonne dans l'enregistrement où la valeur maximale d'une autre colonne a été trouvée. Dans ce cas, il renvoie l'état de la batterie de l'enregistrement avec l'heure de la dernière mise à jour au sein du groupe. Cette requête s'exécute plus rapidement et utilise moins de mémoire qu'une requête équivalente dotée d'une fonction de fenêtrage.

Optimisation des agrégations

Lorsqu'Athena effectue une agrégation, il répartit les enregistrements entre les composants master en utilisant les colonnes de la clause GROUP BY. Pour que la tâche de mise en correspondance des enregistrements avec des groupes soit aussi efficace que possible, les nœuds tentent de conserver les enregistrements en mémoire mais les déversent sur le disque si nécessaire.

Il est également conseillé d'éviter d'inclure des colonnes redondantes dans les clauses GROUP BY. Le nombre réduit de colonnes nécessitant moins de mémoire, une requête décrivant un groupe utilisant moins de colonnes est plus efficace. Les colonnes numériques utilisent également moins de mémoire que les chaînes. Par exemple, lorsque vous agrégez un jeu de données qui possède à la fois un ID de catégorie numérique et un nom de catégorie, utilisez uniquement la colonne ID de catégorie dans la clause GROUP BY.

Parfois, les requêtes incluent des colonnes dans la clause GROUP BY pour contourner le fait qu'une colonne doit faire partie de la clause GROUP BY ou d'une expression agrégée. Si cette règle n'est pas respectée, vous pouvez recevoir un message d'erreur du type suivant :

EXPRESSION_NOT_AGGREGATE : 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, 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 requêtes Top N

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 plus d’informations, consultez Optimisation des fonctions de fenêtrage.

Inclure uniquement les colonnes obligatoires

Si vous n'avez pas strictement besoin d'une colonne, ne l'incluez pas dans votre requête. Moins une requête doit traiter de données, plus elle sera exécutée rapidement. Cela réduit à la fois la quantité de mémoire requise et la quantité de données à envoyer entre les nœuds. Si vous utilisez un format de fichier en colonnes, la réduction du nombre de colonnes réduit également la quantité de données lues à partir d'Amazon S3.

Athena n'impose aucune limite spécifique quant au nombre de colonnes dans un résultat, mais la manière dont les requêtes sont exécutées limite la taille combinée possible des colonnes. La taille combinée des colonnes inclut leur nom et leur type.

Par exemple, l'erreur suivante est due à une relation qui dépasse la limite de taille d'un descripteur de relation :

ERREUR INTERNE GÉNÉRIQUE : io.airlift.bytecode. CompilationException

Pour contourner ce problème, réduisez le nombre de colonnes dans la requête ou créez des sous-requêtes et utilisez une commande JOIN qui récupère une plus petite quantité de données. Si vous avez des requêtes effectuant SELECT * dans la requête la plus externe, vous devez remplacer l'* par une liste contenant uniquement les colonnes dont vous avez besoin.

Optimisation des requêtes à l'aide d'approximations

Athena prend en charge les fonctions d'agrégation d'approximations 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_distinct utilise beaucoup moins de mémoire et s'exécute plus rapidement. De même, l'utilisation de numeric_histogram au lieu de histogram utilise des méthodes approximatives et donc moins de mémoire.

Optimisation de LIKE

Vous pouvez utiliser LIKE pour trouver des chaînes correspondantes, mais avec de longues chaînes, cela demande beaucoup de calcul. La fonction regexp_like est dans la plupart des cas une alternative plus rapide et offre également plus de flexibilité.

Vous pouvez souvent optimiser une recherche en ancrant la sous-chaîne que vous recherchez. Par exemple, si vous recherchez un préfixe, il est préférable d'utiliser « substr% » au lieu de « %substr% ». Ou, si vous utilisez regexp_like « ^ substr ».

Utiliser UNION ALL au lieu de UNION

UNION ALL et UNION sont deux manières de combiner les résultats de deux requêtes en un seul résultat. UNION ALL concatène les enregistrements de la première requête avec la seconde, et UNION fait de même, mais supprime également les doublons. UNION doit traiter tous les enregistrements et trouver les doublons, ce qui demande beaucoup de mémoire et de calcul, mais UNION ALL est une opération relativement rapide. À moins que vous n'ayez besoin de dédupliquer des enregistrements, utilisez UNION ALL pour de meilleures performances.

Utiliser UNLOAD pour les grands ensembles de résultats

Lorsque les résultats d'une requête sont censés être volumineux (par exemple, des dizaines de milliers de lignes ou plus), utilisez UNLOAD pour exporter les résultats. Dans la plupart des cas, cela est plus rapide que l'exécution d'une requête normale, et l'utilisation de UNLOAD vous permet également de mieux contrôler le résultat.

Lorsque l'exécution d'une requête est terminée, Athena stocke le résultat sous la forme d'un seul fichier CSV non compressé sur Amazon S3. Cela prend plus de temps que UNLOAD, non seulement parce que le résultat n'est pas compressé, mais également parce que l'opération ne peut pas être parallélisée. En revanche, UNLOAD écrit les résultats directement à partir des composants master et utilise pleinement le parallélisme du cluster de calcul. En outre, vous pouvez configurer UNLOAD pour écrire les résultats au format compressé et dans d'autres formats de fichier tels que JSON et Parquet.

Pour plus d’informations, consultez UNLOAD.

Utiliser CTAS ou ETL Glue pour matérialiser les agrégations fréquemment utilisées

La « matérialisation » d'une requête est un moyen d'accélérer les performances des requêtes en stockant des résultats de requêtes complexes précalculés (par exemple, des agrégations et des jointures) pour les réutiliser dans les requêtes suivantes.

Si bon nombre de vos requêtes incluent les mêmes jointures et agrégations, vous pouvez matérialiser la sous-requête commune sous la forme d'une nouvelle table, puis exécuter des requêtes sur cette table. Vous pouvez créer la nouvelle table avec Création d'une table à partir des résultats des requêtes (CTAS) ou un outil ETL dédié tel que ETL Glue.

Supposons, par exemple, que vous disposiez d'un tableau de bord comprenant des widgets qui présentent différents aspects d'un jeu de données de commandes. Chaque widget possède sa propre requête, mais les requêtes partagent toutes les mêmes jointures et filtres. Une table des commandes est jointe à une table des articles, et un filtre permet de n'afficher que les trois derniers mois. Si vous identifiez les caractéristiques communes de ces requêtes, vous pouvez créer une nouvelle table que les widgets pourront utiliser. Cela réduit les doublons et améliore les performances. L'inconvénient est que vous devez maintenir la nouvelle table à jour.

Réutiliser les résultats des requêtes

Il est courant qu'une même requête soit exécutée plusieurs fois dans un court laps de temps. Cela peut se produire, par exemple, lorsque plusieurs personnes ouvrent le même tableau de bord de données. Lorsque vous exécutez une requête, vous pouvez demander à Athena de réutiliser les résultats précédemment calculés. Vous spécifiez l'âge maximal des résultats à réutiliser. Si la même requête a déjà été exécutée pendant cette période, Athena renvoie ces résultats au lieu de réexécuter la requête. Pour plus d'informations, consultez Réutilisation des résultats des requêtes 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 sur le blog AWS Big Data.

Techniques d'optimisation des données

Les performances dépendent non seulement des requêtes, mais aussi et surtout de la manière dont votre jeu de données est organisé, ainsi que du format de fichier et de la compression qu'il utilise.

Partitionner vos données

Le partitionnement divise votre table en plusieurs parties et conserve les données associées en fonction de propriétés telles que la date, le pays ou la région. Les clés de partition agissent comme des colonnes virtuelles. Vous définissez les clés de partition lors de la création de la table et vous les utilisez pour filtrer vos requêtes. Lorsque vous filtrez sur les colonnes de clés de partition, seules les données des partitions correspondantes sont lues. Par exemple, si votre jeu de données est partitionné par date et que votre requête comporte un filtre qui ne correspond qu'à la semaine dernière, seules les données de la dernière semaine sont lues. Pour plus d'informations sur le partitionnement, consultez Partitionnement de données dans Athena.

Sélectionner les clés de partition qui répondront à vos requêtes

Le partitionnement ayant un impact significatif sur les performances des requêtes, veillez à bien réfléchir à la manière dont vous partitionnez lorsque vous concevez votre jeu de données et vos tables. Un trop grand nombre de clés de partition peut entraîner la fragmentation des jeux de données contenant trop de fichiers et des fichiers trop petits. À l'inverse, le fait d'avoir trop peu de clés de partition ou de ne pas partitionner du tout, entraîne des requêtes qui analysent plus de données que nécessaire.

Éviter l'optimisation des requêtes rares

Une bonne stratégie consiste à optimiser pur les requêtes les plus courantes et à éviter d'optimiser les requêtes rares. Par exemple, si vos requêtes portent sur des périodes de plusieurs jours, ne partitionnez pas par heure, même si certaines requêtes filtrent à ce niveau. Si vos données comportent une colonne d'horodatage précise, les rares requêtes filtrées par heure peuvent utiliser la colonne d'horodatage. Même si de rares cas analysent un peu plus de données que nécessaire, réduire les performances globales au profit de cas rares ne constitue généralement pas un bon compromis.

Pour réduire la quantité de données que les requêtes doivent analyser et améliorer ainsi les performances, utilisez un format de fichier en colonnes et triez les enregistrements. Au lieu de partitionner par heure, gardez les enregistrements triés par horodatage. Pour les requêtes portant sur des fenêtres temporelles plus courtes, le tri par horodatage est presque aussi efficace que le partitionnement par heure. En outre, le tri par horodatage ne nuit généralement pas aux performances des requêtes sur des fenêtres temporelles comptées en jours. Pour plus d’informations, consultez Utiliser les formats de fichier en colonnes.

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 plus d’informations, consultez Interroger les partitions par égalité.

Utiliser la projection de partition

La projection de partition est une fonctionnalité d'Athena qui stocke les informations de partition non pas dans le AWS Glue Data Catalog, mais sous forme de règles dans les propriétés de la table dans. AWS Glue Lorsqu'Athena planifie une requête sur une table configurée avec une projection de partition, il lit les règles de projection de partition de la table. Athena calcule les partitions à lire en mémoire en fonction de la requête et des règles au lieu de rechercher des partitions dans le AWS Glue Data Catalog.

Outre la simplification de la gestion des partitions, la projection de partition peut améliorer les performances des jeux de données comportant un grand nombre de partitions. Lorsqu'une requête inclut des plages au lieu de valeurs spécifiques pour les clés de partition, la durée de la recherche des partitions correspondantes dans le catalogue est fonction du nombre de partitions. Avec la projection de partition, le filtre peut être calculé en mémoire sans passer par le catalogue, et cela peut être beaucoup plus rapide.

Dans certaines circonstances, la projection de partition peut entraîner une baisse des performances. Un exemple se produit lorsqu'une table est « fragmentée ». Une table fragmentée ne contient pas de données pour chaque permutation des valeurs de clé de partition décrite par la configuration de projection de partition. Avec une table fragmentée, l'ensemble de partitions calculé à partir de la requête et la configuration de projection de partition sont tous répertoriés sur Amazon S3, même s'ils ne contiennent aucune donnée.

Lorsque vous utilisez la projection de partition, veillez à inclure des prédicats sur toutes les clés de partition. Restreignez la portée des valeurs possibles pour éviter des listes inutiles sur Amazon S3. Imaginez une clé de partition comportant une plage d'un million de valeurs et une requête sans filtre sur cette clé de partition. Pour exécuter la requête, Athena doit effectuer au moins un million d'opérations de liste Amazon S3. Les requêtes sont plus rapides lorsque vous interrogez des valeurs spécifiques, que vous utilisiez la projection de partition ou que vous stockiez les informations de partition dans le catalogue. Pour plus d’informations, consultez Interroger les partitions par égalité.

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é.

Pour plus d'informations sur la projection de partition, voir Projection de partition avec Amazon Athena.

Utiliser les index de partition

Les index de partition sont une fonctionnalité du AWS Glue Data Catalog qui améliore les performances de recherche de partitions pour les tables contenant un grand nombre de partitions.

La liste des partitions du catalogue est similaire à une table dans une base de données relationnelle. La table comporte des colonnes pour les clés de partition et une colonne supplémentaire pour l'emplacement de la partition. Lorsque vous interrogez une table partitionnée, les emplacements des partitions sont recherchés en analysant cette table.

Tout comme pour les bases de données relationnelles, vous pouvez améliorer les performances des requêtes en ajoutant des index. Vous pouvez ajouter plusieurs index pour prendre en charge différents modèles de requêtes. L'index de AWS Glue Data Catalog partition prend en charge à la fois les opérateurs d'égalité et de comparaison tels que >>=, et < combinés avec l'ANDopérateur. Pour plus d'informations, consultez les sections Utilisation des index de partition AWS Glue dans 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 dans AWS le blog Big Data.

Toujours utiliser STRING comme type pour les clés de partition

Lorsque vous interrogez les clés de partition, n'oubliez pas qu'Athena exige que les clés de partition soient de type STRING afin de pousser vers le bas le filtrage des partitions dans AWS Glue. Si le nombre de partitions n'est pas faible, l'utilisation d'autres types peut entraîner une baisse des performances. Si les valeurs de vos clés de partition sont de type date ou numérique, convertissez-les dans le type approprié dans votre requête.

Supprimer les partitions anciennes et vides

Si vous supprimez des données d'une partition sur Amazon S3 (par exemple, en utilisant le cycle de vie 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é.

Interroger les partitions par égalité

Les requêtes qui incluent des prédicats d'égalité sur toutes les clés de partition s'exécutent plus rapidement, car les métadonnées de partition peuvent être chargées directement. Évitez les requêtes dans lesquelles une ou plusieurs clés de partition n'ont pas de prédicat ou dans lesquelles le prédicat sélectionne une plage de valeurs. Pour de telles requêtes, la liste de toutes les partitions doit être filtrée pour trouver les valeurs correspondantes. Pour la plupart des tables, la surcharge est minime, mais pour les tables comportant des dizaines de milliers de partitions ou plus, elle peut devenir importante.

S'il n'est pas possible de réécrire vos requêtes pour filtrer les partitions par égalité, vous pouvez essayer la projection de partition. Pour plus d’informations, consultez Utiliser la projection de partition.

Éviter d'utiliser MSCK REPAIR TABLE pour la maintenance des partitions

Étant donné que l'exécution de MSCK REPAIR TABLE peut prendre du temps, qu'elle ajoute uniquement de nouvelles partitions et qu'elle ne supprime pas les anciennes partitions, ce n'est pas une méthode efficace pour gérer les partitions (voir Considérations et restrictions).

Il est préférable de gérer les partitions manuellement à l'aide d'API AWS Glue Data Catalog, ALTER TABLE ADD PARTITION ou de Crawlers AWS Glue. Vous pouvez également utiliser la projection de partition, qui élimine complètement le besoin de gérer les partitions. Pour plus d’informations, consultez Projection de partition avec Amazon Athena.

Vérifiez que vos requêtes sont compatibles avec le schéma de partitionnement

Vous pouvez vérifier à l'avance les partitions qu'une requête analysera à l'aide de l'instruction EXPLAIN. 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, consultez Explication des résultats de l'instruction EXPLAIN d'Athena.

Utiliser les formats de fichier en colonnes

Les formats de fichiers en colonnes tels que Parquet et ORC sont conçus pour les charges de travail d'analyse distribuées. Ils organisent les données par colonne plutôt que par ligne. L'organisation des données sous forme de colonnes présente les avantages suivants :

  • Seules les colonnes nécessaires à la requête sont chargées

  • La quantité globale de données à charger est réduite

  • Les valeurs des colonnes sont stockées ensemble, de sorte que les données peuvent être compressées efficacement

  • Les fichiers peuvent contenir des métadonnées qui permettent au moteur d'éviter de charger des données inutiles

À titre d'exemple de la manière dont les métadonnées des fichiers peuvent être utilisées, les métadonnées des fichiers peuvent contenir des informations sur les valeurs minimales et maximales d'une page de données. Si les valeurs demandées ne se situent pas dans la plage indiquée dans les métadonnées, la page peut être ignorée.

L'un des moyens d'utiliser ces métadonnées pour améliorer les performances consiste à s'assurer que les données contenues dans les fichiers sont triées. Supposons, par exemple, que vous ayez des requêtes qui recherchent des enregistrements dont l'entrée created_at se trouve dans un court laps de temps. Si vos données sont triées par colonne created_at, Athena peut utiliser les valeurs minimale et maximale des métadonnées des fichiers pour ignorer les parties inutiles des fichiers de données.

Lorsque vous utilisez des formats de fichier en colonnes, assurez-vous que vos fichiers ne sont pas trop petits. Comme indiqué dans Éviter d'avoir trop de fichiers, 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 plus d'informations sur l'utilisation d'Athena pour ETL, consultez Utilisation de CTAS et INSERT INTO pour ETL et l'analyse des données.

Compresser les données

Athena prend en charge un large éventail de formats de compression. L'interrogation de données compressées est plus rapide et moins coûteuse, car vous payez pour le nombre d'octets analysés avant la décompression.

Le format gzip fournit de bons taux de compression et est largement compatible avec d'autres outils et services. Le format 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, 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 Prise en charge de la compression Athena.

Utiliser la compartimentation pour les recherches sur des clés à cardinalité élevée

La compartimentation est une technique qui permet de répartir les enregistrements dans des fichiers séparés en fonction de la valeur de l'une des colonnes. Cela garantit que tous les enregistrements ayant la même valeur figurent dans le même fichier. La compartimentation est utile lorsque vous avez une clé à cardinalité élevée et que bon nombre de vos requêtes recherchent des valeurs spécifiques de cette clé.

Supposons, par exemple, que vous interrogiez un ensemble d'enregistrements pour un utilisateur spécifique. Si les données sont compartimentées par nom d'utilisateur, Athena sait à l'avance quels fichiers contiennent des enregistrements pour un identifiant spécifique et quels fichiers n'en contiennent pas. Cela permet à Athena de lire uniquement les fichiers pouvant contenir l'identifiant, ce qui réduit considérablement le volume de données lues. Cela réduit également le temps de calcul qui serait autrement nécessaire pour rechercher l'identifiant spécifique dans les données.

Inconvénients de la compartimentation

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 plus d’informations, consultez Partitionnement et compartimentation dans Athena.

Éviter d'avoir trop de fichiers

Les jeux de données composés de nombreux petits fichiers se traduisent par de faibles performances globales pour les requêtes. Lorsqu'Athena planifie une requête, il répertorie tous les emplacements des partitions, ce qui prend du temps. La gestion et la demande de chaque fichier entraînent également une surcharge de calcul. Par conséquent, le chargement d'un seul fichier plus volumineux à partir d'Amazon S3 est plus rapide que le chargement des mêmes enregistrements à partir de nombreux fichiers plus petits.

Dans des cas extrêmes, vous pouvez rencontrer des limites de service Amazon S3. Amazon S3 prend en charge jusqu'à 5 500 demandes par seconde adressées à une seule partition d'index. Au départ, un compartiment est traité comme une seule partition d'index, mais à mesure que la charge de demandes augmente, il peut être divisé en plusieurs partitions d'index.

Amazon S3 examine les modèles de demandes et les fractionne en fonction de préfixes clés. Si votre jeu de données se compose de plusieurs milliers de fichiers, les demandes provenant d'Athena peuvent dépasser le quota de demandes. Même avec moins de fichiers, le quota peut être dépassé si plusieurs requêtes simultanées sont effectuées sur le même jeu de données. Les autres applications qui accèdent aux mêmes fichiers peuvent contribuer au nombre total de demandes.

Lorsque le taux de demandes limit est dépassé, Amazon S3 renvoie l'erreur suivante. Cette erreur est incluse dans les informations d'état de la requête dans Athena.

SlowDown: Veuillez réduire votre taux de demandes

Pour résoudre le problème, commencez par déterminer si l'erreur est due à une seule requête ou à plusieurs requêtes qui lisent les mêmes fichiers. Dans ce dernier cas, coordonnez l'exécution des requêtes afin qu'elles ne s'exécutent pas en même temps. Pour ce faire, ajoutez un mécanisme de mise en file d'attente ou réessayez dans votre application.

Si l'exécution d'une seule requête déclenche l'erreur, essayez de combiner des fichiers de données ou de modifier la requête pour lire moins de fichiers. Il est préférable de combiner les petits fichiers avant leur écriture. Pour ce faire, envisagez les techniques suivantes :

Éviter les hiérarchies de stockage supplémentaires au-delà de la partition

Pour éviter de surcharger la planification des requêtes, stockez les fichiers dans une structure plate à l'emplacement de chaque partition. N'utilisez aucune hiérarchie de répertoire supplémentaire.

Lorsqu'Athena planifie une requête, il répertorie tous les fichiers de toutes les partitions correspondant à la requête. Bien qu'Amazon S3 ne dispose pas de répertoires en soi, la convention consiste à interpréter la barre oblique / comme séparateur de répertoires. Lorsqu'Athena répertorie les emplacements des partitions, il répertorie de manière récursive tous les répertoires qu'il trouve. Lorsque les fichiers d'une partition sont organisés en hiérarchie, plusieurs séries de listes ont lieu.

Lorsque tous les fichiers se trouvent directement à l'emplacement de la partition, la plupart du temps, une seule opération de liste doit être effectuée. Cependant, plusieurs opérations de liste séquentielles sont nécessaires si vous avez plus de 1 000 fichiers dans une partition, car Amazon S3 ne renvoie que 1 000 objets par opération de liste. La présence de plus de 1 000 fichiers dans une partition peut également créer d'autres problèmes de performances plus graves. Pour plus d’informations, consultez Éviter d'avoir trop de fichiers.

Utiliser SymlinkTextInputFormat uniquement lorsque cela est nécessaire

L'utilisation de la technique 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.

Ressources supplémentaires

Pour plus d'informations sur le réglage des performances dans Athena, consultez les ressources suivantes :