etant construit sur Hadoop. Il n’est pas exclusivement destin´e aux graphes mais pr´esente de tr`es nombreux avantages. Il fut con¸cu pour g´erer de tr`es grandes matrices ainsi que leurs op´erations ´el´ementaires (multiplication, inversion, etc.). Il est principalement destin´e `a l’alg`ebre lin´eaire. HAMA pr´esente cependant un int´erˆet particulier pour les algorithmes it´eratifs car il permet de conserver les donn´ees en m´emoire et de ne pas les ´ecrire sur le disque, tel un pr´ecurseur de Spark. Les exp´erimentations r´ealis´ees sur PageRank ont montr´e que HAMA ´
etait jusqu’`a trois fois plus rapide que Giraph.
Syst`emes permettant le traitement de graphes parall`eles
Syst`eme Langage Mod`ele optimisation partitionnement Hadoop Java MapReduce - hashage Spark Scala RDD r´eutilisation 1D−2D
des donn´ees
Pregel C + + BSP - hashage GPS Java BSP GLAP, GLAP
migration dynamique
Mizan C + + BSP migration, Mizan α − β r´eplication hashage Giraph Java BSP, MapReduce ´ecriture en m´emoire hashage GraphLab C + + RAD calcul synchrone Metis,
et asynchrone ParMetis, hashage Powergraph C + + BSP,RAD graphes sur les arˆetes
de terrains avec une coupe
minimale
Tableau 2.3 – Caract´eristiques globales des syst`emes pour le traitement de graphes de mani`ere parall`ele et distribu´ee
2.3 D´etection de communaut´es dans un
envi-ronnement parall`ele et distribu´e
Des m´ethodes issues de la litt´erature de la d´etection de communaut´es ont ´et´e appliqu´ees et retranscrites pour de grands graphes. Nous nous proposons d’ex-poser les plus importantes et celles qui permettront d’aboutir `a une strat´egie
pour notre solution concernant les grands graphes.
Riedy et al. (2011) ont impl´ement´e l’algorithme de Clauset et al., algorithme agglom´eratif optimisant la modularit´e, en utilisant le multithreading Cray XMT. Cray XMT est une gamme de super-ordinateurs qui poss`edent plusieurs proces-seurs. L’algorithme fut lanc´e sur un graphe de deux milliards d’arˆetes et 122 millions de sommets avec plus de 128 processeurs. Les r´esultats sont satisfaisants mais la qualit´e ne fut jug´ee que par le score de la modularit´e. Les technologies Cray XMT permettent de r´ealiser des calculs sur de gros volumes de donn´ees mais sont tr`es on´ereuses. De plus, depuis l’apparition des technologies Hadoop et Spark, la technologie Cray XMT est de moins en moins utilis´ee. Riedy et al. (2012) ont am´elior´e leur algorithme en y incluant une implementation OpenMP. En utilisant 4 processeurs de 80 cœurs, les auteurs ont fait marcher leurs algo-rithmes sur un graphe de 3,3 milliards d’arˆetes en 500 secondes. Cependant, les tests concernant la qualit´e ne purent ˆetre faits `a cause de la taille des graphes. Bahmani et al. (2012) ont propos´e un algorithme pour d´etecter des groupes de nœuds denses, fond´e sur la maximisation de fonctions fond´ees sur la densit´e de sous graphes. Soit G = (V, E) et S ⊆ V , la densit´e de Bahman Bahmani et al. est d´efinie par ρ(S) = |E(S)||S| . Plus ρ(S) augmente, plus la structure se rapproche de celle d’un graphe complet. Les auteurs proposent un algorithme avec deux versions. La premi`ere concerne les graphes denses et construira la communaut´e S si l’in´egalit´e degS(i) ≤ 2(1 + )ρ(S) est v´erifi´ee, avec un r´eel donn´e par l’utilisateur. On peut comprendre cette in´egalit´e comme le fait que chaque nœud doit avoir un degr´e suffisant pour appartenir `a la communaut´e S. La seconde version, destin´ee `a des graphes tr`es denses, doit v´erifier pour la cr´eation de structures communautaires l’in´egalit´e suivante degS(i) ≤ 1+ |S|. Les deux versions op`erent de la mˆeme mani`ere. Des nœuds sont enlev´es dans le but de maximiser la densit´e des structures communautaires. L’inconv´enient majeur de cette m´ethode est la param´etrisation qui a une grande influence sur la qualit´e de partitionnement. Il faut d´ej`a avoir une id´ee de la densit´e ρG du graphe r´esultant que l’on cherche `a obtenir mais ´egalement avoir `a l’esprit une taille moyenne pour les communaut´es `a pr`es. La derni`ere contrainte peut poser probl`eme pour des graphes complexes, o`u la taille des communaut´es peut ˆetre tr`es variable. On peut en effet, avec une mauvaise param´etrisation, d´etecter des communaut´es contenant elles mˆemes d’autres communaut´es. L’une des forces de cet algorithme est d’avoir ´et´e appliqu´e `a de grands graphes, avec plus de 6 milliards d’arˆetes avec 2000 reducers pour un temps d’ex´ecution d’environ 260 minutes. La qualit´e de partitionnement des m´ethodes n’a pas ´et´e sujette `a des ´
etudes, le seul crit`ere ´etant de maximiser les densit´es des communaut´es. Tsironis et al. (2013) ont impl´ement´e une m´ethode spectrale sous Hadoop. La m´ethode consiste `a construire la matrice Laplacienne sur laquelle vont ˆetre calcul´es les K vecteurs propres associ´es aux K plus petites valeurs propres de la matrice, puis `a lancer un k-means pour obtenir k clusters. Le calcul des vecteurs
propres se fait en utilisant HEIGEN (Kang et al. (2014)), un algorithme sous MapReduce reprenant la m´ethode de Lanczos.
Cette m´ethode pr´esente l’inconv´enient d’ˆetre fond´ee sur le k-means, mais est ce-pendant destin´ee au partitionnement de graphes. De plus, il faut effectuer une recherche pr´ealable pour s´electionner les vecteurs propres contenant le plus d’in-formation. Bien que l’algorithme soit parall`ele et distribu´e, la taille des graphes sur lesquels il a ´et´e appliqu´e est relativement faible, le plus grand graphe ne contenant que 20000 nœuds.
Ovelgonne (2013) propose un algorithme ensembliste fond´e sur la propaga-tion de label tout en r´eduisant la complexit´e du probl`eme, via une r´eduction de la taille des donn´ees de d´epart. En lan¸cant en parall`ele plusieurs propagations de labels, une m´ethode de chevauchement maximale permet de trouver les cœurs. Cependant, Ovelg¨onne n’a pas appliqu´e la m´ethode asynchrone sous Hadoop car trop gourmande en temps. Il choisit plutˆot une version avec mise `a jour en fonction de probabilit´es de telle sorte que le nombre de propagations de labels synchrones soit minimis´e. Cela d´et´eriore la qualit´e de partitionnement. De plus, pour ´eviter d’´ecrire de trop nombreuses fois sur le disque, certains nœuds ne sont mis `a jour qu’une seule fois avec un nombre d’it´erations assez faible d`es le d´epart.
Les r´esultats ont ´et´e appliqu´es sur de tr`es grands r´eseaux de terrain comme LiveJournal avec une heure pour 20 propagations de labels en parall`ele sur un cluster de 50 machines. Les r´esultats sont ´evalu´es avec la modularit´e qui donne des valeurs correctes pour la qualit´e de partitionnement.
Staudt et Meyerhenke (2013) proposent une version ”OpenMP” impl´ementant la propagation de labels et la m´ethode de Louvain en C ++, avec trois m´ethodes fond´ees sur le clustering d’ensemble et vote par consensus :
— Ensemble de pr´etraitement — Ensemble multi-niveaux
— Clustering de cœur et contraction de graphe
Ensemble de pr´etraitement (EPP) : il consiste dans un premier temps `a assigner le graphe `a plusieurs algorithmes de d´etection de communaut´es. Une contraction du graphe a lieu selon un consensus entre tous les r´esultats des diff´erentes d´etections de communaut´es. Le graphe est ainsi contract´e. L’objectif de ce syst`eme est de pouvoir allier qualit´e (par le consensus) et rapidit´e (par la contraction).
Ensemble multi-niveaux (EM) : il est une am´elioration de l’EPP dans un sens it´eratif. A la fin de l’´etape de contraction, un nouveau graphe G0 est cr´e´e et le processus fond´e sur l’EPP continue de mani`ere it´erative. Les conditions pour arrˆeter la contraction sont multiples comme i) obtenir un singleton ii) mettre un seuil sur la taille du graphe r´eduit en dessous duquel la contraction est in-terdite iii) la pr´esence d’une diminution de la modularit´e d’une contraction `a la suivante et iv) la stagnation de la qualit´e des communaut´es d´etect´ees. Clustering de cœur et contraction de graphe (CCGC) : repr´esente la m´ethode la plus stricte en termes de consensus. Si une paire de nœuds a
´
et´e identifi´ee comme appartenant `a la mˆeme communaut´e, et ceci dans toutes les d´etections de communaut´es, alors ces deux nœuds seront contract´es. Cette derni`ere m´ethode permet de trouver les meilleurs cœurs en termes de qualit´e. Cependant, il se peut que certains r´esultats de d´etection de communaut´es ne soient pas de bonne qualit´e. La cons´equence est que des cœurs ne puissent ˆetre trouv´es.
C’est en utilisant ces derni`eres m´ethodes que la propagation de labels pond´er´ee et la m´ethode de Louvain ont ´et´e appliqu´ees dans leurs versions parall`eles. Le parall´elisme de la propagation de labels sur OpenMP (not´e PLP) r´eside en un tri des nœuds se faisant sur plusieurs threads qui op´erent sur des tableaux de labels communs. La mise `a jours des labels peut ainsi se faire de mani`ere syn-chrone ou asynsyn-chrone. Il s’agit d’une impl´ementation pour des graphes pond´er´es, avec une mise `a jour des labels dont les arˆetes liant le nœud sont les plus impor-tantes. Un seuil δ doit cependant ˆetre sp´ecifi´e en dessous duquel le changement de labels devient impossible.
Le parall´elisme de l’algorithme de Louvain sur OpenMP intervient dans le calcul de la fonction de modularit´e, qui se fait en utilisant plusieurs threads. En effet, chaque mouvement d’un nœud dans une autre communaut´e a pour cons´equence la variation de la modularit´e qui est calcul´ee localement.
Il ressort des exp´erimentations que CCGC semble donner les meilleurs r´esultats en termes de qualit´e pour PLM et PLP. PLP est extrˆemement rapide mais de qualit´e moyenne, alors que PLM obtient de meilleurs r´esultats, mais n´ecessite plus de temps.
Moon et al. (2014) d´evelopp`erent l’algorithme de Girvan et Newman (2002b) sous Hadoop. Une version du plus court chemin fut d´evelopp´ee sous MapReduce en quatre ´etapes. La premi`ere phase consiste `a calculer entre chaque paire de nœuds le plus court chemin. La seconde ´etape consiste dans le calcul de la centralit´e d’interm´ediarit´e. La troisi`eme ´etape permet de s´electionner k arˆetes ayant les centralit´es d’interm´ediarit´e les plus ´elev´ees. k est un param`etre de l’utilisateur. La derni`ere phase consiste `a retirer les arˆetes s´electionn´ees. L’al-gorithme fut appliqu´e `a deux graphes de petite taille de 6000 et 10000 nœuds avec respectivement 290 000 et 51 000 arˆetes. Avec plus de 20 machines, le syst`eme requiert un temps d’ex´ecution de pr`es de 300 secondes. Bien que les r´esultats en termes de qualit´e soient encourageants, l’algorithme pr´esente deux inconv´enients majeurs. Le premier est le choix du nombre d’arˆetes `a retirer qui n’est a priori pas connu de l’utilisateur. Le second inconv´enient est le temps de calcul du plus court chemin entre chaque paire de nœuds qui est beaucoup trop important pour des graphes ayant quelques dizaines de milliers d’arˆetes. De ce fait, l’algorithme ne peut pas ˆetre appliqu´e `a de grands graphes de plusieurs millions d’arˆetes.
Kuzmin et al. (2015) ont impl´ement´e le SLPA dans sa version parall`ele dans un contexte multithreading. Chaque thread r´ealise une propagation de labels sur un sous ensemble de nœuds qui a ´et´e pr´ealablement partitionn´e. Le parti-tionnement est utilis´e pour ne pas d´epasser la m´emoire vive. C’est alors que les
sous-graphes r´esultants sont assign´es `a des threads o`u les propagations de labels sont lanc´ees.
Les r´esultats ont montr´e que la m´ethode ´etait ´equivalente en termes de qualit´e de partionnement `a la version non parall`ele. Elle obtient cependant de meilleurs r´esultats en choisissant une m´ethode de partitionnement particuli`ere, mais une ´
etude pr´ealable doit ˆetre effectu´ee. Elle fut lanc´ee sur des graphes comme DBLP, Amazon ou Livejournal, avec plusieurs millions de sommets et jusqu’`a une cen-taine de millions d’arˆetes.
La propagation de label a ´egalement ´et´e d´evelopp´ee sous Apache Spark, par une impl´ementation et par une int´egration Pregel dont le mod`ele suit un BSP. Comme nous l’avons vu, Pregel est un BSP qui permet l’impl´ementation d’algo-rithmes sur les graphes. Pregel fut construit sur la philosophie ”Penser comme un sommet”. Chaque calcul est fait sur chaque sommet et les arˆetes sont des canaux de communication permettant d’envoyer ou de recevoir des informa-tions ou op´erations des voisinages des nœuds (ou mˆeme d’un nœud `a un autre nœud en connaissant l’identifiant). Pregel finit une ”super ´etape” lorsque tous les nœuds du graphe sont dans un ´etat inactif. La propagation de labels fut ainsi impl´ement´ee de mani`ere synchrone o`u chaque it´eration consiste en une ”super ´
etape”. A la fin d’une super ´etape, chaque nœud prend connaissance du label majoritaire de son voisin et un vote est ainsi effectu´e. Le processus se continue un nombre de fois sp´ecifi´e par l’utilisateur. En consid´erant l’impl´ementation sur Spark, `a chaque super ´etape, un RDD (Resilient distributed dataset) est cr´e´e et est utilis´e pour l’it´eration de la propagation de labels suivante. La signature du LPA sous Spark est lib.LabelPropagation.run(par1, par2).vertices o`u par1 se r´ef`ere au graphe o`u sera appliqu´e le LPA et par2 sera le nombre d’it´erations (de super ´etapes) du LPA. Cette impl´ementation peut ˆetre ap-pliqu´ee `a des graphes de plusieurs millions d’arˆetes en utilisant un cluster de machines important, mais souffre d’un inconv´enient qui lui est intrins`eque. Son impl´ementation synchrone laisse l’algorithme instable et non d´etermiste. La so-lution pour r´esoudre ce probl`eme est que l’ordre de visite des nœuds soit toujours le mˆeme, afin de rendre plus d´eterministe l’algorithme. Cependant, si l’ordre de visite commence par un nœud qui est situ´e entre plusieurs structures commu-nautaires, de mauvaises propagations peuvent se produire.