The Coder's Breakfast - Mot-clé - hadoop - Commentaires2022-11-22T14:44:11+01:00Olivier Croisierurn:md5:7bccc57fa40daaa0bbb47c16f3d66529DotclearOpenSource Exchange : compte-rendu sur Hadoop - Olivier Croisierurn:md5:785ab4645adc91cf6445a2a8b95e41f02010-04-06T21:54:38+01:002010-04-06T20:54:38+01:00Olivier Croisier<p>Cela dépend de votre besoin.</p>
<ul>
<li>S'il faut manipuler des volumes très importants de données, et que celles-ci peuvent être réparties en sous-ensembles indépendants, alors une solution de type <a href="http://hadoop.apache.org/" rel="nofollow">Hadoop</a> ou <a href="http://www.gridgain.com/" rel="nofollow">GridGain</a> pourra vous être utile.</li>
<li>Si au contraire les données ne peuvent être partitionnées et ne peuvent tenir en mémoire d'un seul bloc, <a href="http://www.terracotta.org/" rel="nofollow">Terracotta</a> pourrait vous aider grâce à ses capacités de "paging" mémoire.</li>
<li>Enfin, si vous devez plutôt traiter des flux de données continus en temps réel, regardez du côté de <a href="http://esper.codehaus.org/" rel="nofollow">Esper</a></li>
</ul>OpenSource Exchange : compte-rendu sur Hadoop - yahyaurn:md5:3095c124112c39bc4193680db47c34cc2010-04-06T15:32:28+01:002010-04-06T14:32:28+01:00yahya<p>je vois que hadoop est très utile et il permet de résoudre beaucoup de problèmes.<br />
moi je bosse sur un système de détection de fraudes bancaire.A votre avis sans hadoop comment pourrais-je traiter toutes ces données en temps réel.</p>OpenSource Exchange : compte-rendu sur Hadoop - Olivier Croisierurn:md5:514d7ea5eb6888a6e061bb46cf313ea52008-11-19T18:59:55+00:002008-11-19T18:59:55+00:00Olivier Croisier<p>Le but de Hadoop n'est pas tant de paralléliser la puissance de calcul que de manipuler des volumes de données très importants. Ce n'est donc pas ce framework qui aidera à utiliser au mieux la puissance de calcul des ordinateurs multi-coeurs.</p>OpenSource Exchange : compte-rendu sur Hadoop - HollyDaysurn:md5:1780e0bc1d66b47e264af6df06baa83f2008-11-19T17:14:11+00:002008-11-23T04:47:01+00:00HollyDays<p>«<em>étranger à nos problématiques quotidiennes de développement d'applications de gestion...</em>».<br />
Vraiment ?</p>
<p>Tant que les développeurs écriront des applications fondamentalement synchrones et séquentielles, cela y restera étranger, je suis d'accord. Mais l'évolution des processeurs ces dernières années, et la direction que cette évolution prend pour les 5 ou 10 ans qui viennent (au bas mot) - en l'occurrence, une augmentation importante du nombre de cœurs dans chaque processeur - montre quelque chose de très différent : ainsi, Intel annonce un processeur à 80 cœurs à horizon de 5 ans.</p>
<p>Car comment exploiter le parallélisme disponible au niveau du matériel si on continue à écrire du code intrinsèquement et explicitement itératif et séquentiel ? Certes, les optimiseurs juste-à-temps sont puissants (VM et optimiseur interne du processeur), mais on atteint déjà les limites de leurs capacités prédictives. Pour accroître encore les performances, il va donc falloir que le code du développeur, à défaut d'être explicitement parallèle, soit au moins compatible avec une exécution parallèle.</p>
<p>Ces problématiques de code parallélisable ont été étudiées il y a longtemps déjà, et la réponse appropriée à ces problématiques est bien connue. Il ne s'agit pas des threads, qui sont une forme de parallélisation explicite, et qui sont complexes à maîtriser sans bugs pour le développeur. Il s'agit de la <strong>parallélisation implicite</strong> : le code ne dit pas ce qui doit être parallélisé, il se contente de <ins>ne pas présupposer un ordre d'exécution particulier</ins>.</p>
<p>Principal obstacle à cela : les structures de contrôle explicitement (et inutilement) séquentielles. Par exemple, en Java, parcourir des collections avec des <code>Iterator</code> pose un gros problème dans le processus de parallélisation du code : l'itérateur spécifie explicitement l'ordre de parcours des éléments de la collection, même lorsque le traitement sur chaque élément est indépendant de celui des autres. Et il n'y a pas vraiment moyen de garantir que ces traitements élémentaires sont indépendants et exécutables simultanément plutôt que séquentiellement.</p>
<p>Autre obstacle : les modifications de données partagées, qui sont vus comme autant d'effets de bord dans un monde parallèle.</p>
<p>Principal outil pour écrire du code implicitement parallélisable : des blocs de code sans effet de bord.</p>
<p><em>MapReduce</em> utilise justement des blocs de code sans effet de bord, et c'est pour cela qu'il est massivement parallélisable, aussi bien à l'échelle d'une machine multi-cœurs qu'à l'échelle d'une grille de processeurs : chaque item de la fonction <em>Map</em> est indépendant des autres et peut être exécuté sur un cœur ou un processeur indépendant ; souvent, même <em>Reduce</em> peut être partiellement parallélisé (si on a <em>N</em>=<em>n</em>*<em>m</em> résultats à "réduire", on peut répartir le traitement sur <em>n</em> processeurs en les faisant réduire <em>m</em> résultats chacun ; puis on réduit ensuite les <em>n</em> réductions en une seule).</p>
<p>Comment exprime-t-on des blocs de code sans effet de bord ? <br /> En Java, aujourd'hui, par des classes internes qui implémentent des interfaces comme <code>Runnable</code>. Ce qui est un peu verbeux dès lors qu'on veut en avoir un usage intensif.<br />
Et dans les autres langages (Python, Groovy, Scala, ou même LISP, qui est le langage dans lequel on a inventé le <em>MapReduce</em>) ? Avec des closures.</p>