agsandrew - Fotolia
Avec Athena, AWS chasse sur les terres de BigQuery
AWS présente une implémentation de Presto pour S3. Les données contenues dans le service de stockage de la marque peuvent être directement interrogées sans opérations de transformation.
Comme un arrière-goût de BigQuery mais avec la touche AWS. C’est ainsi que l’on pourrait qualifier Amazon Athena, un moteur de requêtes interactives SQL qui permet d’interroger directement les données dans le service de stockage d’AWS, S3. Avec ce service, il est inutile de préparer en amont les données ou d’effectuer les très chronophages opérations de transformation et d’intégration propre à l’ETL (Extract, Transform, Load). Selon AWS, avec Athena, les données sont maintenues telles quelles dans S3 ; les analystes et data scientists peuvent directement effectuer des requêtes SQL pour les analyser. Les formats standards sont supportés : AWS cite par exemple JSON, CSV, ou encore Parquet (pour le colonnage) et ORC.
Le service d’AWS s’appuie pour cela sur des technologies standards, à l’image de Presto. Celui-ci est un projet Open Source né chez Facebook pour ses besoins internes, puis ouvert par le groupe. S’il compte plusieurs supporters comme NetFlix ou AirBnB, Presto est aussi supporté par Teradata, qui en a fait un pilier de son offre SQL-On-Hadoop et de moteur SQL multi-sources. En gros, Presto s’appuie sur un moteur massivement parallèle et permet d’effectuer des requêtes interactives là où se trouvent les données, que ce soit dans un cluster Hadoop, ou une base NoSQL ou SQL. Presto unifie les sources de données pour étendre la portée de la requête. La communauté y a ainsi développé plusieurs connecteurs pour cibler les principales technologies du marché. AWS a donc adapté Presto aux spécificités de S3 – à ses spécificités d’élasticité, par exemple.
Google BigQuery, lui, est une implémentation publique de la technologie Dremel née à Mountain View. Cette technologie est restée propriétaire, mais MapR a développé en Open Source le projet Drill qui reprend les mêmes principes de requêtage SQL multi-sources et directement sur les données.
Schéma à la volée
Athena s’adosse à la mécanique dite de schema-on-read ; ce qui signifie, en clair, que les schémas de données, et les définitions des tables, sont appliqués, uniquement lors de l’exécution de la requête. A l’inverse donc d’une technologie de schema-on-write, qui implique de définir bien amont, un schéma type, avant même de charger les données. Les données sont donc finalement transformées selon un modèle défini.
Avec le modèle schema-on-read, finalement, on décrit le schéma à la volée sans que les données soient chargées ni transformées. Elles sont parsées à l’exécution de la requête dans leur format d’origine. Il s’agit d’avantage d’un modèle descriptif.
Outre Presto, Athena fait également usage de Hive, connu dans la sphère Hadoop pour ses capacités de requêtes sur des données contenues dans des clusters Hadoop – mais avec un sous-segment de SQL, HiveSQL. Le service AWS supporte ainsi DLL (Data Definition Language) avec lequel on peut définir les tables en amont, directement dans l’éditeur de code du service. Ce même éditeur (Athena Query Editor) supporte aussi les requêtes SQL ANSI, logiquement.
Parmi les cas d’usages, AWS cible surtout l’analyse et la création de rapports ad hoc effectuées sur de grands volumes de données. Ce qui pourrait expliquer le modèle de tarification. Athena est en effet facturé en fonction du volume de données passées au crible par les requêtes, à raison de 5$ par To. Des capacités de partionnement et de compression des données permettent de réduire la facture, assure AWS.