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 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 Optimisez les requêtes grâce à l'indexation et au filtrage des AWS Glue 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 plus élevés nécessitent plus de CPU cycles pour compresser et décompresser les données. Pour Athena, nous vous recommandons d'utiliser Apache Parquet ou ApacheORC, qui compressent les données par défaut. Pour plus d'informations sur la compression des données dans Athena, veuillez consulter Utiliser la compression dans 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 prennent ORC également en charge les fichiers séparables.

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 colonnaires 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 Convertir en formats colonnaires.

Utilisez une taille de bloc de parquet ou de ORC rayure plus grande

Parquettez et ORC disposez de paramètres de stockage de données que vous pouvez régler pour optimiser. Dans Parquet, vous pouvez optimiser la taille des blocs. DansORC, vous pouvez optimiser la taille des rayures. 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 du bloc Parquet est de 128 Mo et la taille des ORC bandes est de 64 Mo.

Si une ORC bande est inférieure à 8 Mo (valeur par défaut dehive.orc.max_buffer_size), Athena lit la bande entièreORC. 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.

Utilisation 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 à utiliserORC.

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 Athena, consultez la section Support de 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 :

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.