Amazon Athena : SQL sans serveur sur S3

Amazon Athena est un service de requêtes interactif sans serveur qui vous permet d’exécuter du SQL standard directement sur les données stockées dans Amazon S3. Vous n’avez aucun serveur à mettre en service ni aucun cluster à gérer, et vous ne payez que les données analysées par requête (environ 5 $ par TB analysé). Athena utilise Presto en interne et s’intègre nativement au Catalogue Data Glue pour les métadonnées des tables.

Avant d’exécuter des requêtes, configurez un groupe de travail Athena et indiquez un chemin S3 pour la sortie des résultats. Les groupes de travail permettent de séparer l’historique des requêtes et le suivi des coûts entre les équipes, d’imposer le chiffrement des résultats et de définir des limites de données analysées par requête afin d’éviter les coûts incontrôlés. Chaque résultat de requête est écrit au format CSV dans le bucket S3 de sortie configuré.

Associez Athena à une base de données du Catalogue Data Glue et exécutez du SQL ANSI. Athena prend en charge SELECT, JOIN, GROUP BY, les fonctions de fenêtrage et les CTE. Vous pouvez également utiliser CREATE TABLE AS SELECT (CTAS) pour enregistrer les résultats d’une requête dans une nouvelle table au format Parquet, ce qui matérialise efficacement les résultats intermédiaires afin d’accélérer les requêtes ultérieures.

Athena facture les données analysées par TB. La réduction des coûts la plus importante consiste à effectuer un élagage des partitions : incluez toujours les colonnes de partition dans votre clause WHERE. Si les données sont partitionnées par year/month/day, le filtrage sur ces colonnes empêche Athena d’analyser les autres partitions. Sans filtre de partition sur une table à l’échelle du pétaoctet, une simple requête peut coûter plusieurs centaines de dollars.

Stocker les données au format Apache Parquet ou ORC plutôt qu’en CSV ou JSON réduit considérablement la quantité de données analysées par Athena pour chaque requête. Une requête en colonnes qui utilise 3 colonnes sur 50 n’analyse que les données de ces 3 colonnes sur le disque. Associés à la compression intégrée (Snappy, Zstd), les fichiers Parquet sont généralement 5 à 10 fois plus petits que les fichiers CSV équivalents, ce qui multiplie les économies.

Athena Federated Query étend Athena au-delà de S3 pour interroger des données dans RDS, DynamoDB, Redshift, Elasticsearch et des sources personnalisées à l’aide de connecteurs de sources de données basés sur Lambda. Vous déployez une fonction Lambda de connecteur depuis le Serverless Application Repository, vous l’enregistrez comme source de données Athena, puis vous pouvez interroger les tables S3 et les bases de données en direct dans un même JOIN SQL, sans déplacer les données au préalable.

Amazon QuickSight se connecte directement à Athena comme source de données, ce qui permet aux analystes métier de créer des tableaux de bord interactifs à partir de données S3 sans base de données intermédiaire. QuickSight utilise SPICE (Super-fast, Parallel, In-memory Calculation Engine) pour mettre en cache les résultats des requêtes Athena et accélérer l’affichage des tableaux de bord. Cette pile BI sans serveur (S3 + Glue + Athena + QuickSight) constitue un schéma courant d’examen pour l’analyse à moindre coût.

Au-delà du partitionnement et du format en colonnes, vous pouvez encore optimiser les requêtes Athena en : scindant les fichiers volumineux (visez 128 Mo à 1 Go par fichier pour permettre le traitement parallèle), en utilisant le regroupement en buckets pour les colonnes fréquemment jointes, en évitant SELECT * et en utilisant des fonctions d’agrégation approximatives comme approx_distinct() et approx_percentile() lorsque les valeurs exactes ne sont pas nécessaires. Ces techniques réduisent à la fois les coûts et la latence.

Athena s’intègre à IAM pour le contrôle des accès : les utilisateurs doivent disposer des autorisations nécessaires pour exécuter des requêtes Athena (athena:StartQueryExecution), accéder au bucket S3 de sortie et lire les données S3 sous-jacentes. Pour un accès précis au niveau des colonnes et des lignes, associez Athena à Lake Formation. Vous pouvez également limiter un groupe de travail à certaines bases de données grâce aux clés de condition IAM portant sur l’ARN du groupe de travail.

Les résultats des requêtes Athena sont stockés sous forme de fichiers CSV dans S3 et mis en cache pendant 7 jours. Ainsi, la réexécution d’une requête identique pendant cette période ne réanalyse pas les données. Pour les besoins récurrents de génération de rapports, utilisez Athena Scheduled Queries pour exécuter une requête selon une planification cron et enregistrer les résultats dans un nouvel emplacement S3 ou directement dans une table. Vous pouvez également déclencher une requête Athena depuis une machine d’état Step Functions ou une règle EventBridge.

Pour l’examen SAA-C03, vous devez savoir quand recommander Athena plutôt que Redshift. Choisissez Athena pour des requêtes ponctuelles et peu fréquentes sur S3, sans infrastructure à gérer. Choisissez Redshift lorsque vous avez besoin de temps de réponse inférieurs à la seconde sur des jointures complexes, lorsqu’une équipe d’analyse dédiée exécute des centaines de requêtes simultanées ou lorsque vous souhaitez utiliser Redshift Spectrum pour étendre un entrepôt de données avec des données S3. Le critère essentiel est la fréquence et la complexité des requêtes.

Testez votre compréhension des concepts AWS Solutions Architect (SAA-C03) abordés dans cette leçon.

Dans cette leçon, vous avez appris que Athena facture les données analysées par TB, et que l’élagage des partitions ainsi que le format Parquet sont essentiels pour maîtriser les coûts, qu’Athena Federated Query étend le SQL aux sources de données qui ne sont pas S3 grâce aux connecteurs Lambda, et qu’Athena convient mieux aux requêtes ponctuelles, tandis que Redshift est adapté aux analyses à forte concurrence. Nous allons maintenant découvrir Kinesis pour la diffusion et l’analyse de données en temps réel.