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.

Optimisez les données

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

Partitionner vos données

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

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

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

Éviter l'optimisation des requêtes rares

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

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

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

Utiliser la projection de partition

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

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

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

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

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 Utiliser la projection de partitions 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 de plus amples informations, veuillez consulter Utiliser la projection de partition.

Évitez de l'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 des AWS Glue robots d'exploration AWS Glue Data Catalog APIsALTER TABLE ADD PARTITION, 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 Utiliser la projection de partitions 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 Utiliser EXPLAIN et EXPLAIN ANALYZE dans Athéna, consultez Comprendre les résultats de la déclaration d'Athéna EXPLAIN.

Utiliser les formats de fichier en colonnes

Les formats de fichier en colonnes tels que Parquet 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 :

À 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 les parquets ORC sont organisés en interne par groupes de rangées (Parquet) et 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 Athena, vous pouvez utiliser AWS Glue ETL ou Athena. Pour de plus amples informations, veuillez consulter Convertir en formats colonnaires.

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 JSON et CSV des données, 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 Utiliser la compression dans 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.

Évitez le cloisonnement lorsque les requêtes recherchent fréquemment plusieurs valeurs dans une colonne

La compartimentation est moins utile lorsque les requêtes recherchent fréquemment plusieurs valeurs dans la colonne dans laquelle les données sont compartimentées. Plus le nombre de valeurs demandées est élevé, plus il est probable que tous les fichiers ou la plupart d'entre eux devront être lus. Par exemple, si vous avez trois compartiments et qu'une requête recherche trois valeurs différentes, il est possible que tous les fichiers doivent être lus. La compartimentation fonctionne mieux lorsque les requêtes recherchent des valeurs uniques.

Pour de plus amples informations, veuillez consulter Utiliser le partitionnement et le cloisonnement.

É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 de plus amples informations, veuillez consulter É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.