Prévention de la limitation Amazon S3

La limitation est le processus qui consiste à limiter le taux d'utilisation d'un service, d'une application ou d'un système. Dans AWS, vous pouvez utiliser la régulation pour empêcher la surutilisation du service Amazon S3 et augmenter la disponibilité et la réactivité d'Amazon S3 pour tous les utilisateurs. Cependant, étant donné que la limitation restreint la vitesse à laquelle les données peuvent être transférées vers ou depuis Amazon S3, il est important d'en tenir compte pour éviter que vos interactions ne soient limitées.

Réduire la limitation au niveau du service

Pour éviter la limitation d'Amazon S3 au niveau du service, vous pouvez surveiller votre utilisation et ajuster vos Service Quotas, 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 maximum de demandes par seconde pour un seul objet, 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 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 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 ? (Centre de AWS connaissances)

• Lecture de fichiers d'entrée en groupes plus importants (Guide AWS Glue du développeur)

Optimisation de vos tables

Il est important de structurer vos données si vous rencontrez des problèmes de limitation. Bien qu'Amazon S3 puisse gérer de grandes quantités de données, une limitation se produit parfois en raison de la structure des données.

Les sections suivantes proposent des suggestions sur la manière de structurer vos données dans Amazon S3 afin d'éviter les problèmes de limitation.

Utiliser le partitionnement

Vous pouvez utiliser le partitionnement pour réduire la limitation en limitant la quantité de données auxquelles il est nécessaire d'accéder à un moment donné. En partitionnant les données sur des colonnes spécifiques, vous pouvez répartir les demandes de manière uniforme sur plusieurs objets et réduire le nombre de demandes pour un seul objet. La réduction de la quantité de données devant être analysées permet d'améliorer les performances des requêtes et de réduire les coûts.

Vous pouvez définir des partitions, qui agissent comme des colonnes virtuelles, lorsque vous créez une table. Pour créer une table avec des partitions dans une instruction CREATE TABLE, vous utilisez la clause PARTITIONED BY (column_name data_type) pour définir les clés permettant de partitionner vos données.

Pour restreindre les partitions analysées par une requête, vous pouvez les spécifier sous forme de prédicats dans une clause WHERE de la requête. Les colonnes fréquemment utilisées comme filtres se prêtent donc parfaitement au partitionnement. Il est d'usage de partitionner les données en fonction de l'heure, ce qui peut conduire à un schéma de partitionnement à plusieurs niveaux.

Notez que le partitionnement a également un coût. Lorsque vous augmentez le nombre de partitions dans votre table, le temps nécessaire pour récupérer et traiter les métadonnées des partitions augmente également. Ainsi, le surpartitionnement peut supprimer les avantages que vous obtenez en partitionnant de manière plus judicieuse. Si vos données sont fortement asymétriques par rapport à une valeur de partition et que la plupart des requêtes utilisent cette valeur, vous risquez d'avoir à supporter des frais généraux supplémentaires.

Pour plus d'informations sur le partitionnement dans Athena, consultez Qu'est-ce que le partitionnement ?.

Compartimenter vos données

Une autre façon de partitionner vos données consiste à les compartimenter dans une seule partition. La compartimentation vous permet de spécifier une ou plusieurs colonnes contenant des lignes que vous souhaitez regrouper. Ensuite, vous placez ces lignes dans plusieurs compartiments. De cette manière, vous interrogez uniquement le compartiment qui doit être lu, ce qui réduit le nombre de lignes de données devant être analysées.

Lorsque vous sélectionnez une colonne à utiliser pour la compartimentation, sélectionnez la colonne présentant une cardinalité élevée (c'est-à-dire comportant de nombreuses valeurs distinctes), distribuée uniformément et fréquemment utilisée pour filtrer les données. Une clé primaire, telle qu'une colonne ID, est un exemple de colonne appropriée à utiliser pour la compartimentation.

Pour plus d'informations sur la compartimentation dans Athena, consultez Qu'est-ce que la compartimentation ?.

Utiliser des index AWS Glue de partition

Vous pouvez utiliser les index de AWS Glue partition pour organiser les données dans une table en fonction des valeurs d'une ou de plusieurs partitions. AWS Glue les index de partition peuvent réduire le nombre de transferts de données, la quantité de données traitées et le temps de traitement des requêtes.

Un index de AWS Glue partition est un fichier de métadonnées qui contient des informations sur les partitions de la table, notamment les clés de partition et leurs valeurs. L'index de partition est stocké dans un compartiment Amazon S3 et est mis à jour automatiquement au AWS Glue fur et à mesure que de nouvelles partitions sont ajoutées à la table.

Lorsqu'un index de AWS Glue partition est présent, les requêtes tentent de récupérer un sous-ensemble des partitions au lieu de charger toutes les partitions de la table. Les requêtes s'exécutent uniquement sur le sous-jeu de données correspondant à la requête.

Lorsque vous créez une table dans AWS Glue, vous pouvez créer un index de partition sur n'importe quelle combinaison de clés de partition définie sur la table. Après avoir créé un ou plusieurs index de partition sur une table, vous devez y ajouter une propriété permettant le filtrage des partitions. Ensuite, vous pouvez interroger la table à partir d'Athena.

Pour plus d'informations sur la création d'index de partition dans AWS Glue, consultez la section Utilisation des index de partition AWS Glue dans 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 AWS Glue indexation et filtrage des partitions.

Utiliser la compression des données et le fractionnement des fichiers

La compression des données peut accélérer considérablement les requêtes si les fichiers ont une taille optimale ou s'ils peuvent être fractionnés en groupes logiques. En général, des taux de compression élevés nécessitent plus de cycles d'UC pour compresser et décompresser les données. Pour Athena, nous vous recommandons d'utiliser Apache Parquet ou Apache ORC, qui compressent les données par défaut. Pour plus d'informations sur la compression des données dans Athena, veuillez consulter Prise en charge de la compression Athena.

Le fractionnement de fichiers augmente le parallélisme en permettant à Athena de répartir la tâche de lecture d'un seul fichier entre plusieurs lecteurs. Si un fichier unique n'est pas fractionnable, seul un lecteur peut lire le fichier tandis que les autres lecteurs sont inactifs. Apache Parquet et Apache ORC prennent également en charge les fichiers fractionnables.

Utiliser les magasins de données en colonnes optimisés

Les performances des requêtes Athena s'améliorent de manière significative si vous convertissez vos données dans un format en colonnes. Lorsque vous générez des fichiers en colonnes, l'une des techniques d'optimisation à prendre en compte consiste à ordonner les données en fonction de la clé de partition.

Apache Parquet et Apache ORC sont des magasins de données en colonnes open source couramment utilisés. Pour plus d'informations sur la conversion d'une source de données Amazon S3 existante vers l'un de ces formats, consultez Conversion en formats de colonne.

Utiliser une taille supérieure de bloc Parquet ou de bande ORC

Parquet et ORC disposent de paramètres de stockage de données que vous pouvez régler pour les optimiser. Dans Parquet, vous pouvez optimiser la taille des blocs. Dans ORC, vous pouvez optimiser la taille des bandes. Plus le bloc ou la bande est grand(e), plus vous pouvez stocker de lignes dans chaque bloc ou bande. Par défaut, la taille de bloc Parquet est de 128 Mo et la taille de bande ORC est de 64 Mo.

Si une bande ORC est inférieure à 8 Mo (valeur par défaut de hive.orc.max_buffer_size), Athena lit l'intégralité de la bande ORC. C'est le compromis qu'Athena fait entre la sélectivité des colonnes et les opérations d'entrée/sortie par seconde pour les bandes plus petites.

Si vous avez des tables comportant un très grand nombre de colonnes, une petite taille de bloc ou de bande peut entraîner l'analyse d'un plus grand nombre de données que nécessaire. Dans ces cas, une taille de bloc plus grande peut s'avérer plus efficace.

Utiliser ORC pour les types complexes

Actuellement, lorsque vous interrogez les colonnes stockées dans Parquet qui ont des types de données complexes (par exemple array, map ou struct), Athena lit une ligne de données entière au lieu de lire sélectivement les colonnes spécifiées. Il s'agit d'un problème connu dans Athena. Pour contourner le problème, pensez à utiliser ORC.

Choix d'un algorithme de compression

Un autre paramètre que vous pouvez configurer est l'algorithme de compression des blocs de données. Pour plus d'informations sur les algorithmes de compression pris en charge pour Parquet et ORC dans Athena, consultez Prise en charge de la compression Athena.

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

Utiliser les tables Iceberg

Apache Iceberg est un format de table ouvert pour les jeux de données analytiques très volumineux conçu pour une utilisation optimisée sur Amazon S3. Vous pouvez utiliser les tables Iceberg pour permettre de réduire la limitation dans Amazon S3.

Les tables Iceberg vous offrent les avantages suivants :

• Vous pouvez partitionner les tables Iceberg sur une ou plusieurs colonnes. Cela permet d'optimiser l'accès aux données et de réduire la quantité de données devant être analysées par les requêtes.

• Comme le mode de stockage d'objets Iceberg optimise les tables Iceberg pour qu'elles fonctionnent avec Amazon S3, il peut traiter des volumes de données importants et de lourdes charges de travail liées aux requêtes.

• Les tables Iceberg en mode de stockage d'objets sont évolutives, tolérantes aux pannes et durables, ce qui peut contribuer à réduire la limitation.

• La prise en charge des transactions ACID signifie que plusieurs utilisateurs peuvent ajouter et supprimer des objets Amazon S3 de manière atomique.

Pour plus d'informations sur Apache Iceberg, consultez Apache Iceberg. Pour plus d'informations sur l'utilisation de tables Apache Iceberg dans Athena, consultez Utilisation des tables Iceberg.

Optimisation des requêtes

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

Utiliser LIMIT avec la clause ORDER BY

La clause ORDER BY renvoie les données dans un ordre trié. Cela oblige Athena à envoyer toutes les lignes de données à un seul composant master, puis à trier les lignes. Ce type de requête peut s'exécuter pendant une longue période, voire échouer.

Pour plus d'efficacité dans vos requêtes, examinez les valeurs N supérieures ou inférieures, puis utilisez également une clause LIMIT. Cela réduit considérablement le coût du tri en poussant le tri et la limitation vers des composants master individuels plutôt qu'à un seul composant master.

Optimiser les clauses JOIN

Lorsque vous joignez deux tables, Athena répartit la table de droite sur les composants master, puis diffuse la table de gauche pour effectuer la jointure.

Pour cette raison, spécifiez la table la plus grande du côté gauche de la jointure et la plus petite du côté droit de la jointure. De cette manière, Athena utilise moins de mémoire et exécute la requête avec une latence plus faible.

Notez également les points suivants :

• Lorsque vous utilisez plusieurs commandes JOIN, spécifiez les tables de la plus grande à la plus petite.

• Évitez les jointures croisées, sauf si elles sont requises par la requête.

Optimiser les clauses GROUP BY

L'opérateur GROUP BY répartit les lignes en fonction des colonnes GROUP BY sur les composants master. Ces colonnes sont référencées en mémoire et les valeurs sont comparées au fur et à mesure que les lignes sont ingérées. Les valeurs sont agrégées lorsque la colonne GROUP BY correspond. Compte tenu du fonctionnement de ce processus, il est conseillé d'ordonner les colonnes de la cardinalité la plus élevée à la plus faible.

Utiliser des nombres au lieu des chaînes

Comme les nombres nécessitent moins de mémoire et sont plus rapides à traiter que les chaînes, utilisez des nombres plutôt que des chaînes lorsque cela est possible.

Limiter le nombre de colonnes

Pour réduire la quantité totale de mémoire requise pour stocker vos données, limitez le nombre de colonnes spécifié dans votre instruction SELECT.

Utiliser des expressions régulières au lieu de LIKE

Les requêtes qui incluent des clauses, par exemple LIKE '%string%' sur de grandes chaînes, peuvent être très gourmandes en calculs. Lorsque vous filtrez plusieurs valeurs sur une colonne de chaîne, utilisez plutôt la fonction regexp_like() et une expression régulière. Cela est particulièrement utile lorsque vous comparez une longue liste de valeurs.

Utiliser la clause LIMIT

Au lieu de sélectionner toutes les colonnes lorsque vous exécutez une requête, utilisez la clause LIMIT pour renvoyer uniquement celles dont vous avez besoin. Cela réduit la taille du jeu de données traité via le pipeline d'exécution des requêtes. Les clauses LIMIT sont plus utiles lorsque vous interrogez des tables comportant un grand nombre de colonnes basées sur des chaînes. Les clauses LIMIT sont également utiles lorsque vous effectuez plusieurs jointures ou agrégations sur une requête.

Ressources supplémentaires

Schémas de conception des bonnes pratiques : optimisation des performances Amazon S3 dans le Guide de l'utilisateur Amazon Simple Storage Service

Réglage de performances dans Athena