MapReduce ne serait donc pas la panacée ?
Il y a environ un an était publié une étude comparant l’approche Map Reduce, celle de la base de donnée parallèle à, enfin, la base de données exploitant un stockage en colonnes. Une évaluation de performances plusieurs fois remise au gout du jour et à prendre au sérieux de par la qualité de ses auteurs. On y retrouve deux universitaires de la Brown University, Daniel Abadi de Yale, Erik Paulson de l’University du Winsconsin, ainsi que David DeWitt de Microsoft et enfin Samuel Madden et Michael Stonebraker du MIT.
But de l’étude : mesurer les performances de ces trois solutions pour des approches de type scale out, c’est-à-dire de grosses volumétries de données réparties sur un grand nombre de PC banalisés, en l’occurrence jusqu’à 100 nœuds dans cette étude. L’étude date un peu mais elle revient de façon cyclique sur Twitter, et le jour où IBM a lancé InfoSphere BigInsights, son offre analytique sur Hadoop, il était temps que j’y jette un oeil…
Des écarts… énormes !
L'évolution des performances des 3 solutions lors des différentes éditions du benchmark.
Premier constat : les disparités sont extrêmement fortes d’une solution à l’autre, voire d’une version de logiciel à une autre. C’est notamment le cas pour la base Vertica qui a vue ses performance s’améliorer de façon conséquente entre les premiers tests, menés à l’automne 2008, puis ceux du printemps 2009 et enfin les derniers qui remontent à l’été 2009. On est sur des technologies encore jeunes et le passage au 64 bits à permis de booster la solution de manière décisive. L’amélioration de performance est aussi vraie pour Hadoop dont le code à été optimisé sur la même période de temps.
L’amélioration est moins sensible pour DBMS-X qui a néanmoins bénéficié de la compression de données au printemps 2009.
Quelles conclusions en tirer ?
Le test de chargement de données fait apparaître la supériorité d'Hadoop et donc de Map Reduce pour cette tâche.
Quel que soit le nombre de nœuds et la volumétrie en jeu, Hadoop est la solution la plus efficace pour le chargement des données. L’écart est considérable avec la base en colonnes qui est elle-même incomparativement plus efficace que le SGBD parallèle classique. Pas étonnant que tous les éditeurs d’ETL sérieux ne finissent par s’aligner sur le framework Hadoop.
Sur le volet recherche d’information, tout betememnt une requête « SELECT * FROM Data WHERE field LIKE ‘%XYZ%’; ». Le test tourne à l’aigre pour MapReduce. Ses deux concurrents consomment deux fois moins de temps pour délivrer le résultat de la requête sur une configuration à 535 Mo par nœud. Le constat est un peu moins catastrophique lorsqu’on monte à 1 To et lorsqu’on pousse le nombre de nœud à 100 mais Hadoop reste plus lent.
Sur des tâches analytiques,la base en colonne s'est montrée la plus performante, devant la base classique parallèle elle même bien plus efficace qu'Hadoop.
Nos chercheurs ont ensuite durcit l’épreuve pour passer à des applications analytiques. En gros une batterie de tests impliquant des appels de fonctions UDF, des jointures, des agrégations de données. Dans tous ces tests, Hadoop se voit nettement distancés par ces concurrents. En moyenne sur 100 nœuds, DBMS-X s’est montré 3,2 fois plus rapide qu’Hadoop, sachant que Vertica s’est montré 2,3 fois plus rapide que DBMS-X. Les chercheurs estiment que jusqu’à 1000 nœuds ces écarts devraient rester identiques.
Pour résumer, il faut plus de nœud Hadoop pour réaliser le même boulot que sur un SGBD ou une base en colonnes massivement parallèle. Atout pour les défenseurs de l’approche : en augmentant le nombre de nœuds, on améliore la fiabilité de la base en cas de perte d’un nœud. Toujours est-il qu’eBay exploite une configuration Teradata de 72 nœuds pour héberger 2 Po de données alors que Facebook exploite plus de 600 nœuds Hive (data warehouse basé sur Hadoop) pour 2,5 Po de données.
L’étude peut être téléchargée sur le site de l’université de Brown.
Loading ...
2,5 To ? ce n’est pas beaucoup pour Facebook !
Il s’agit de pétaoctet et non de To…
Ces messieurs de Facebook annoncent charger 15 To par jour… ce qui est stratosphérique vu de France.
Exact, il fallait lire Po à la place de To pour les projets d’eBay et de Facebook. J’ai édité mon texte, merci !
J’ajouterai un autre projet à 4,5 Po sur 96 noeuds Greenplum chez eBay et encore un chez Yahoo! avec 3658 noeuds Hadoop pour 1 Po.
Depuis quand Map/Reduce permet-il de faire du chargement de données ?
Map/Reduce n’est fait que pour le requetage il me semble…
Merci de m’éclairer…