Athena, solution serverless d’Amazon, mise en perspective de “Buzz Query”, moteur de requêtes de dashboarding serverless bigdata

Nous avions exploré dans l’article précédent les forces et faiblesses de Spark et Elasticsearch. Nous allons à présent creuser en quoi la solution Athena d’Amazon est une brique pertinente, notamment quand elle est intégrée dans une solution comme celle de BuzzQuery de CloudFuse.io pour une solution de moteur de requête de dashboarding bigdata.

Amazon a construit Athena dans le but de faire des requêtes SQL en serverless. Le stockage s’appuie sur S3. Athena s’appuie sur une flotte de serveurs Presto qui sont évidemment stockés chez Amazon. Amazon s’occupe ensuite de générer la requête résultat. Un avantage d’Athena est qu’il est gratuit si on ne l’utilise pas (principe commun en serverless). Athena est utilisable quelle que soit la taille de la base de données, qu’elle soit grande ou petite. 

Au-delà d’atouts certains, Athena ne fournit pas de niveau de services garantis (SLA), ie d’avoir un serveur Presto pour n’importe quelle requête. Cela peut devenir prohibitif dans le cas de certains applicatifs. 

Un autre inconvénient est l’absence de cache. Si on fait deux fois des requêtes proches, les performances de la seconde requête ne seront pas optimisées.

Le prix et la puissance de calcul dépendent de la quantité de données utilisée. 1 To = 5 $ (environ). Il peut y avoir une inadaptation entre les capacités de calculs et les besoins en calculs, ce qui peut bloquer certaines requêtes. 

C’est le revers de la médaille que d’avoir beaucoup simplifié. 

La solution BigQuery de Google est très similaire à Athena. Ils n’utilisent pas Presto. Il semble qu’il y ait un peu de flexibilité, par exemple avec une provision de calcul customizable… Mais on perd alors le serverless.

On voit donc poindre le besoin d’une solution en pay-as-you-go, donc serverless qui aurait un SLA en termes de temps de latence.

La solution développée par CloudFuse.io (Rémi DETTAI) s’appelle “Buzz Query”. Son but est donc de proposer une solution à faible latence à bon marché, permettant une interactivité suffisante pour les utilisateurs finaux.

Mais comment construire une telle solution?

Buzz Query va tirer profit d’un composant clef d’Amazon, les Lambdas, et les combiner avec des solutions issues du monde de l’embarqué pour leur déclenchement, en moins de 50 ms.

AWS Lambda est un service de calcul sans serveur qui vous permet d’exécuter du code sans provisionner ou gérer des serveurs, créer une logique de dimensionnement de cluster prenant en charge la charge de travail, maintenir les intégrations d’événements ou gérer les environnements d’exécution. Les Lambdas ont justement une propriété intéressante, leur faible durée d’activation. Ainsi, pour compenser le fait que la donnée est stockée sur un stockage froid et peu coûteux, en l’occurrence Amazon S3, le moteur est capable de paralléliser la requête massivement sur un très grand nombre de machines (plusieurs milliers).

Rémi utilise également un maximum de composants existants, comme Apache Arrow, un projet Open Source très versatile et dynamique qui est en train de créer un standard du stockage des données en mémoires.

A qui pourrait bénéficier Buzz Query?

Rémi Dettai a justement eu le besoin d’une telle solution alors qu’il travaillait pour une startup dans le domaine de la pub. De gros volumes de données. Un besoin d’interactivité côté utilisateur. Des besoins fonctionnels pas encore clarifiés, donc une barrière à l’agrégation préliminaire. Des moyens financiers limités dans ce contexte. C’est donc de cette expérience qu’est venue le besoin d’une solution comme Buzz Query. Par extension, nous pouvons donc imaginer que d’autres adopteurs potentiels: des leaders de projet d’analytics pas encore mature en termes d’usages, donc peu à même que quantifier les ressources à provisionner en terme de capacité de calcul, nécessitant de gros volumes de données, et désireux de fournir un dashboard interactif à l’utilisateur. S’ils devaient provisionner un cluster, ça leur coûterait cher. Athena serait un peu lent. L’intégration des Lambda d’Amazon que propose Rémi pourrait être la solution.

Amis geeks du BigData, venez donc contribuer

Paris ne s’est pas fait en un jour. La solution de Rémi est par conviction en open source. Rémi a besoin de contributeurs pour consolider, pérenniser et faire évoluer sa solution. N’hésitez pas à le contacter via LinkedIn, sur GitHub (https://github.com/cloudfuse-io/buzz-rust), ou via son site web (https://www.cloudfuse.io/). Il en sera ravi.

Et vous, quelle solution de dashboarding bigdata avez-vous déployée?

Vous devriez également aimer

“Buzz Query”, un moteur de requêtes pour dashboarding bigdata serverless

L’histoire commence par la rencontre entre l’équipe DataPy et Rémi Dettai… Rémi est un ingénieur de talent spécialisé en Data et Cloud. Rémi a eu de nombreuses expériences dans les domaines de la tech, chez des industriels com...

Forces et faiblesses de Spark et Elasticsearch

Nous avons partagé les enjeux liés à la techno du Serverless dans le précédent article. Nous allons creuser aujourd’hui les solutions les plus connues dans le domaine du traitement de données à grande échelle, Spark et Elasticsearch.

Le serverless, une approche efficace à bas prix

Nous avions introduit dans l’article précédent ce qu’était la notion de moteur de requête de dashboarding. Nous allons à présent nous concentrer sur une nouvelle notion, plus proche des ressources matérielles, le serverless.