Discussion :

[Cedric Chevalier]

Facebook sort Presto, son moteur de requêtes open source pour le big data
qui serait dix fois plus performant que celui de Hadoop

De nombreuses entreprises comme Facebook dépendent du Big data. Dans le domaine, on compte la paire Hadoop/Hive parmi les références. Pour rappel, Hive c’est le moteur de requêtes populaire pour Hadoop.

Cependant, il se pourrait que le MapReduce élément essentiel sur lequel repose Hive ne soit pas optimisé pour des situations ou la quantité de données excède un certain seuil. En effet, la latence deviendrait ainsi élevée pour les requêtes effectuées avec Hive.

Les ingénieurs de Facebook, ayant cherché sans succès une solution de remplacement de Hive, en sont venus à créer leur propre moteur de requêtes open source écrit en Java, qu’ils ont baptisé « Presto ».

Presto diffère de Hive sur plusieurs points, bien que leurs clusters présentent tous les deux des architectures assez similaires (il y a toujours au moins un nœud maître et des nœuds esclaves).

Presto implémente une méthode personnalisée de distribution de tâche au sein de son cluster, qui n’est pas basée sur MapReduce. De plus, il utilise un langage de requête compatible ANSI SQL.

Selon les ingénieurs du réseau social, Presto serait dix fois plus performant qu’Hive en termes de réduction de charge sur le CPU, ainsi que la diminution de la latence pour les requêtes (raison pour laquelle il a d’ailleurs été conçu).

Pour les mois à venir, l’équipe de développement de Presto annonce travailler pour la création de connecteurs pour les solutions Hbase, Scribe et bien d’autres.


Télécharger Presto

Source: Facebook

Et vous ?

Utiliserez-vous Presto ?

[CapFlow]

Le nom Presto me dit bizarrement quelque chose ...

[pmithrandir]

Bonjour

Je trouve l'initiative intéressante.
Je n'ai par contre pas pou voir si presto reprenait les avantages des BDD relationnelles.

En effet, j'ai bien trouvé des solutions multiples pour multiplier la puissance de calcul (avec une redondance des données sur chaque serveur) mais par contre, c'est très difficile de trouver une solution SQL qui permettrait un stockage réparti sur plusieurs serveurs. (quand on a besoin de beaucoup de stockage, mais de peu de puissance / réactivité / concurrence)

En tout cas, leur initiative de le mettre en open source montre bien la tendance actuelle de partager les efforts.

[alex_vino]

En tout cas, leur initiative de le mettre en open source montre bien la tendance actuelle de partager les efforts.

Malheuresement ce n'est pas toujours pour seulement "partager ses efforts" et par pure gentillesse, sinon a quoi bon recruter et payer une fortune beaucoup des meilleurs ingénieurs au monde.

[pmithrandir]

pour moi, partager les effort, c'est pragmatique, pas une gentillesse.

On le fait la ou je bosse, mais jamais par bonté d'ame.
On le fait pour encourager une solution a grandir, pour imposer une solution sur le marché, ou vraiment pour partager les couts.

C'est ce que je voulais dire.

[psychadelic]

Le nom Presto me dit bizarrement quelque chose ...

C'est le nom de l'ancien Moteur de rendu du navigateur d'Opera

[Marco46]

Je n'ai par contre pas pou voir si presto reprenait les avantages des BDD relationnelles.

Ce n'est pas possible d'avoir une bdd relationnelle avec des contraintes d'intégrités, des clefs étrangères, etc ... dans un contexte big data.

Cela demande une trop grande concentration de ressources au même endroit (pour la gestion de l'intégrité) alors que le principe du big data c'est de répartir les données et les calculs afin d'être scalable.

Malheuresement ce n'est pas toujours pour seulement "partager ses efforts" et par pure gentillesse, sinon a quoi bon recruter et payer une fortune beaucoup des meilleurs ingénieurs au monde.

Ce n'est pas de la gentillesse, c'est simplement plus efficace dans ce contexte. Si tu regardes la liste des commiters Hadoop, tu as 80% des dev qui sont employés chez Google et Facebook.

[Njörd]

Bonjour,

Ce n'est pas possible d'avoir une bdd relationnelle avec des contraintes d'intégrités, des clefs étrangères, etc ... dans un contexte big data.

Que penses-tu du NewSQL permettant d'avoir les avantages du NoSQL avec les principes ACID ? Trop contraignant pour le big data ?

[CapFlow]

C'est le nom de l'ancien Moteur de rendu du navigateur d'Opera

Oui je sais, c'était justement pour montrer que FaceBook n'avait pas eu d'imagination (désolé si mon ironie était trop cachée :p)

[pmithrandir]

Que penses-tu du NewSQL permettant d'avoir les avantages du NoSQL avec les principes ACID ? Trop contraignant pour le big data ?

Je regarde ca en ce moment... tu as des liens de préférence open source sur le sujet ?

J'ai pour ma part l'impression que c'est très possible. Je ne dit pas que les perfs seront géniales, mais ca aurait le mérite de s'intégrer dans des env cloud sur le principe "beaucoup de petite VM pour remplacer un gros serveur"

[alex_vino]

Si tu regardes la liste des commiters Hadoop, tu as 80% des dev qui sont employés chez Google et Facebook.

Comment faire pour consulter cette liste ?

[Njörd]

Je regarde ca en ce moment... tu as des liens de préférence open source sur le sujet ?

Désolé je n'ai rien sur le sujet, j'ai eu vent de la notion via le livre "Les bases de données NoSQL" de Rudi Bruchez. En regardant un peu par-ci, par-là j'en suis arrivé à faire un parallèle (cela n'engage que moi donc) avec le BigTable de 2004. Soit, la réponse des ingénieurs R&D de Google pour résoudre la problématique des grands volumes de données sur un site à forte charge.

Le NewSQL serait donc la prochaine évolution pour traiter ce genre de problématique et promet de prendre le meilleur des deux univers : SQL (OLAP) et NoSQL (OLTP).

Quelques liens d'introduction :
NewSQL
VoltDB, une base NewSQL

Wait & see