“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 comme Continental ou encore dans des startups. Rémi a fondé Cloudfuse en 2020 et sa solution opensource mérite d’être partagée. 

Le but de cet article est donc de présenter son produit “Buzz Query”, une solution innovante de moteur de requêtes de dashboarding qui présente l’avantage d’être peu coûteuse comparée aux solutions des GAFA, tout en offrant des temps de latences très faibles. 

Cet article est donc l’opportunité de partager un panorama des solutions du marché de dashboarding BigData, d’en comprendre les enjeux et de mesurer pourquoi la solution de Rémi pourrait vous séduire.

C’est aussi l’opportunité pour des potentiels passionnés d’open source de rentrer en contact avec Rémi et de contribuer à sa belle initiative.

Compte tenu de la richesse technique des technologies mises en oeuvre au sein de cet article, nous vous proposons d’aborder successivement les thèmes suivants: 

  • Qu’est-ce que le dashboarding de BigData?
  • Le serverless, une approche efficace à bas prix
  • Forces et faiblesse de Spark et Elasticsearch
  • “Buzz Query”, une solution  de dashboarding serverless bigdata idéale pour les startups

Bonne lecture 😉

Qu’est-ce que le dashboarding de BigData?

On peut segmenter le monde du bigdata en deux parties, à l’image du moteur de recherche Google. 

D’une part, certaines solutions BigData vont permettre à un grand nombre d’utilisateurs d’accéder à un service (une application) en même temps. A titre d’exemple, Google aspire les sites du web, classifie les éléments clefs de chacun d’entre eux, puis permet à des millions d’utilisateurs d’obtenir les réponses à leurs requêtes en parallèle.

D’autre part, certaines solutions de BigData permettent à un nombre restreint d’utilisateurs d’accéder à un grand volume de données, en leur donnant la possibilité d’avoir des vues synthétiques, tout en leur permettant d’aller les étudier dans le détail. Là aussi, par exemple, Google permet aux webmasters ou autres responsables marketing d’analyser les audiences des sites (pages vues à telle heures… par tel type de population, dans tel et tel pays …). Cette solution qui s’appelle Google Analytics est une solution de dashboarding. Les utilisateurs veulent avoir des résultats de manière rapide, être capable à la fois d’aller dans le détail et d’avoir une vue de synthèse.

On commence à saisir le dilemme qui s’offre à l’ingénieur BigData lors de la création de chaque nouvelle architecture bigdata… Au moment de la création de telles solutions, leurs créateurs ne connaissent généralement pas totalement les usages futurs. Leur tendance est donc de vouloir stocker toutes les données, toutes leurs dimensions. La finesse des résultats demande des capacités de stockage et de calculs importantes. Une exigence du client interne est également souvent d’avoir une réponse à ses requêtes au bout de quelques secondes. On imagine mal devoir attendre plus de 30 secondes les stats de Google Analytics. Le temps de réponse est donc un paramètre clef de l’expérience utilisateur. Mais plus on souhaite avoir un temps de réponse rapide, et plus le coût de la solution augmentera. Faut-il donc stocker toutes les informations ou seulement des agrégations? Ne pourrait-on pas trouver d’autres types d’architectures combinant capacité à traiter des gros volumes de données, dans un temps satisfaisant pour l’utilisateur et à un prix ‘acceptable’?

C’est là que le serverless commence à intervenir, et nous vous présenterons cette approche dans un article dédié la semaine prochaine.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *