Je n’écris plus beaucoup, et j’en suis le premier désolé. Frustré. J’aime écrire, mais le temps me manquait, les préoccupations étant ailleurs ces derniers temps. Mais certains commentaires m’ont re-motivé au plus haut point, alors je vais tenter de reprendre l’exercice, en douceur.
Pour ce premier nouvel article, j’aimerais reprendre quelques points sur Hadoop, le géant des systèmes distribués, et adopter ici une nouvelle orientation, plus orientée « revue de presse ». Il y a de la littérature formidable sur Internet, et plutôt que chacun ne perde son temps à se perdre dans les dédales des blogs et e-magazines, je vous propose des rapides résumés et ressentis.
« Hadoop Doesn’t Solve All Problems (lien) »
est le nom de l’article qui a suscité mon attention. Ces dernières semaines, à plusieurs reprises, j’ai pu entendre LA question : « est-ce qu’Hadoop me permet de faire ceci, cela ?« . La publication des exploits d’eBay et autres géants a certainement contribué au succès grandissant d’Hadoop. Néanmoins, il ne faut pas oublier que l’utilisation en production de la plate-forme libre de « Big-Data » au sein de ces entreprises se fait en connaissance de cause.
Tout d’abord, Hadoop tout seul ne répond pas à tous les besoins, et la plus-value se situe sur l’ensemble de l’éco-système. Il faut penser la plate-forme dans son intégralité. Les motifs d’accès aux données ou les calculs à effectuer peuvent influer sur la manière dont seront organisées les données et sur les outils environnants : faut-il stocker des résultats dans une grille analytique ? Dois-je privilégier une approche par flux ou par batch ?
Après Google, Hadoop a complètement démocratisé le Map/Reduce, ou comment effectuer de puissants calculs sur des petabytes de données. Encore faut-il savoir écrire de tels calculs. J’ai eu plusieurs fois l’occasion d’observer des jobs mal pensés, mal définis. La nature de Map/Reduce se prête mal à certains calculs sur des graphes géants comme certains algorithmes de recommendations par exemple, comme mentionné dans l’article (un petit tour du côté de Pregel s’impose…). Mais la non-maîtrise du style fonctionnel de Map/Reduce n’est pas seule la raison des lenteurs ou de le non-utilisabilité du cluster. La mauvaise maîtrise d’Hadoop lui même peut mener à la catastrophe.
Celui qui n’a pas compris que le namenode est source de SPOF, ou qu’un Combiner bien écrit est parfois utile pour limiter le I/O, se rendra vite compte que « Hadoop ne résout pas tous les problèmes ». De même, la connaissance des problèmes « de base » de l’informatique répartie — coût des transmissions vs. coût des calculs, synchronisations, etc. — me semble inévitable pour concevoir une plate-forme pérenne. Maîtriser son architecture technique et chacune des briques me semble bien plus important qu’arriver à écrire des jobs Java pour Hadoop.
Abonnement Fil RSS