Un détaillant en ligne stocke les journaux d'accès ALB dans S3 et les interroge avec Amazon Athena. L'ingénieur a créé une table Athena non partitionnée, et les temps de réponse des requêtes ont augmenté à mesure que le volume de données augmentait. Quelle approche améliorera les performances des requêtes Athena avec le moins d'effort opérationnel ?

La création d'un crawler AWS Glue est la solution la plus efficace car il détecte automatiquement le schéma et les partitions des journaux ALB stockés dans S3, puis met à jour le AWS Glue Data Catalog. Athena utilise ces métadonnées de partition pour filtrer les données et ne scanner que les fichiers pertinents, améliorant ainsi considérablement les performances des requêtes et réduisant les coûts, avec un effort opérationnel minimal. La création d'une tâche AWS Glue est moins optimale car elle implique généralement plus de configuration et de script pour l'inférence de schéma et la gestion des partitions, par rapport à un crawler qui automatise cela. La transformation des journaux en Parquet via une fonction Lambda améliorerait les performances, mais cela représente un effort opérationnel plus important pour le développement et la maintenance de la fonction, ainsi que la gestion du processus de transformation. L'utilisation d'Apache Hive et d'une fonction Lambda est une approche beaucoup plus complexe et lourde en termes d'effort opérationnel, et n'est généralement pas la solution la plus simple pour optimiser les requêtes Athena sur des journaux S3.