Cet article fait partie de notre guide: Ces nouveaux moteurs de l’analytique moderne

AWS Athena : comment améliorer la performance des requêtes… et réduire ses coûts

Amazon Athena permet d’interroger plus de formats de données que son rival Google BigQuery. Toutefois, il est préférable de privilégier certains formats pour tirer pleinement parti du service AWS

Cela est devenu presque une lapalissade : les données n’ont jamais été autant valorisées, et cela met la pression sur les départements IT qui se doivent désormais de les ingérer, gérer, et favoriser leur analyse de la façon la plus rapide possible. Les entreprises ont bien compris l’importance de l’analytique, surtout dans le Cloud, mais beaucoup sont encore confrontées  à des obstacles, notamment en matière de performances.

Toutes les données ne sont pas de bonnes données. Des données, dont la structure est erronée ou incorrecte, peut dès lors conduire à des coûts élevés pour les clients – dans notre article ceux d’AWS. AWS tient à disposition plusieurs outils pour optimiser les données et ainsi améliorer les performances des requêtes et abaisser les coûts. Ceux-ci fonctionnent bien avec Amazon Athena, le service de requêtes SQL interactives du géant du Cloud.

La particularité d’Athena est de permettre aux analystes des données d’interroger de grands volumes de données stockées dans S3, via une simple interface SQL. Athena, qui repose sur une architecture dite serverless, n’implique aucun provisionning et peut prendre en charge rapidement des recherches des pétaoctets de données. En fait, Athena est perçu comme la réponse d’AWS à Google BigQuery, dont la popularité est grandissante depuis 2011.

A l’inverse de BigQuery, Athena n’impose pas aux entreprises de stocker leurs données dans un format spécifique ni aux développeurs d’écrire du code dédié. En revanche, Athena exécute ses requêtes directement sur des fichiers localisés dans S3. En ce sens, les développeurs ont tout intérêt à optimiser leurs données pour améliorer les performances et réduire les coût-  le service supporte les formats standards comme CSV par exemple. Pour démarrer, il suffit d’uploader dans un bucket S3 des documents dans un format supporté et de pointer Athena vers ce bucket.

Il est également préférable de prévoir en amont ses requêtes et de ne pas les lancer de façon continue. Cela pourrait bien faire grimper rapidement la facture finale, car AWS facture en effet son service au téraoctet de données scannées. Les coûts risquent d’être très élevés si l’application interroge, même accidentellement, desgrandes quantités de données toutes les minutes. Pour éviter cela, il est nécessaire de compresser les données et de les stocker dans un format en colonne, comme Apache Parquet, avant même de les uploader dans S3.

Formater les données dans S3

Athena s’appuie sur le standard SQL. Les développeurs ont souvent recours à des backends SQL sur leurs Big Data pour leurs analyses. Une application peut par exemple enregistrer chaque action d’un utilisateur lors d’une session puis créer un fichier log dans S3. L’application peut alors stocker ce fichier dans un format CSV ou texte brut, mais Athena fonctionne mieux avec des données au format Parquet. Apache propose d’ailleurs une bibliothèque C++ pour Parquet ainsi que des adaptateurs pour d’autres langages comme Node.JS par exemple.

Le module node-parquet est simple à utiliser et montre comment compresser ses données dans un format Parquet pour S3 et Athena. Le code ci-dessous passe les données dans un format Parquet et les charge dans S3 :

const parquet = require('node-parquet');

var schema = {

  user_id: {type: 'int32'},

  action_name: {type: 'byte_array'},

  action_value: {type: 'byte_array', optional: true},

  browser: {type: 'byte_array'},

  location: {type: 'byte_array'},

  ip_address: {type: 'byte_array'},

  start_time: {type: 'int32'},

  end_time: {type: 'int32'},

};

var data = [

  [ 1234, 'Login', null, 'Chrome', 'Ohio', '10.0.0.1', 1496941960, 1496942080],

  [ 1234, 'Search', 'Chris Moyer', 'Chrome', 'Ohio', '10.0.0.1', 1496941960, 1496942080],

  [ 1234, 'View', 'Book: Building Applications in the Cloud', 'Chrome', 'Ohio', '10.0.0.1', 1496941960, 1496942080],

  [ 1234, 'Add to Cart', 'Building Applications in the Cloud', 'Chrome', 'Ohio', '10.0.0.1', 1496941960, 1496942080],

  [ 1234, 'Checkout', '1 Item', 'Chrome', 'Ohio', '10.0.0.1', 1496951960, 1496952080],

];

var writer = new parquet.ParquetWriter(`${session_id}.parquet`, schema);

writer.write(data);

writer.close();

writer.on('end', () => {

  s3.upload({

    Bucket: 'my-parquet-data',

    Key: '${session_id}.parquet',

    Body: fs.createReadStream(`${session_id}.parquet`),

  }).promise().catch(e => {

    // Retry logic if there's an issue, or alert

    // if nothing can be retried.

  });

});

 

Les fichiers Parquet reposent sur un formatage strict, vous devez donc définir le schéma avant de charger les données dans S3. Cette opération garantit aussi que ces fichiers seront tous conformes au même schéma et qu’Athena pourra donc plus facilement traiter ces données.  GZIP peut également être utilisé pour compresser les données et améliorer davantage les performances des requêtes.

Interroger les données avec Athena

Une fois les données chargées dans S3, il faut créer une table virtuelle dans Athena. Cela informe Athena sur la façon de parser les données dans un format SQL. Utilisez les expressions regulières ou indiquez que le format d’entrée est Parquet. Les données seront automatiquement déplacées vers le bon schéma et la bonne table.  Assurez-vous également de bien indiquer quelles colonnes doivent être chargées dans Athena ; sélectionnez enfin le format et le nom des colonnes créées lorsque les données sont sauvegardées dans S3.

Les partitions, qui sont identiques aux indexes, peuventt aussi améliorer les performances des requêtes. Vous pouvez par exemple partionner l’ID de l’utilisateur et le nom de l’action ; ce qui aura pour effet de regrouper rapidement toutes les activités d’un unique utilisateur ou le type d’actions.

Une fois la configuration d’Athena finalisée, toutes les requêtes, qu’elles soient exécutées à partir de la console AWS Management Console ou l’API d’Athena, seront effectuées directement sur S3. Il n’y a aucun cache ni synchronisation, les données sont automatiquement mises à jour et la facture n’est calculée que lorsque une recherche est effectuée.

Amazon Athena est ainsi très utile pour les développeurs qui ne souhaitent pas maintenir un serveur SQL. Toutefois, ce service n’est efficace que si les requêtes sont peu fréquentes. Les applications qui se reposent sur des requêtes permanentes, doivent quant à elles s’adosser à des bases de données comme Aurora ou un entrepôt de données comme RedShift.

 

 

Pour approfondir sur Base de données