Our experience in using Apache Giraph for computing the diameter of large graphs Paul Bertot - Flavian Jacquot
Plan 1. 2. 3. 4. 5. 6. Contexte Hadoop Giraph L étude Partitionnement ifub 2
1. Contexte - L ADT BigGraphs Action de Développement Technologique portée par les EPIs COATI, SCALE et DIANA qui vise au développement d un outil de calcul distribué sur les grands graphes. J évalue Apache Giraph ; Nicolas Chleq (SED) évalue GraphX ; Luc Hogie évalue une solution ad hoc (BigGraph). 3
1. Contexte - Le calcul distribué Coût élevé d un super ordinateur SWAP trop coûteux en performance De toutes façons, on pourra toujours imaginer des instances plus grandes Solution : un outil de calcul distribué économique (réutilisation du matériel) performant (répartition du calcul) scalable (par son architecture) 4
Plan 1. 2. 3. 4. 5. 6. Contexte Hadoop Giraph L étude Partitionnement ifub 5
2. Hadoop - Utilisateurs Wordcloud of Companies by their Relative Hadoop Cluster Sizes, Number of Nodes, Dec. 2012 6
2. Hadoop - Origine : BigData Données Volumineuses Facebook : 15 To/jour Twitter : 7To/jour Deux besoins : Stocker et Traiter Réponses : Google File System et MapReduce Logiciel propriétaire, équivalent open source 7
2. Hadoop - Présentation High-Availability Distributed Object-Oriented Platform Développé par la Fondation Apache Stockage : HDFS Traitement : MapReduce Tolérance aux pannes, Scalable Ensemble de machines Cluster Parallélisation transparente pour l utilisateur 8
2. Hadoop - Schéma général 9
2. Hadoop - MapReduce : Détail Les étapes de fonctionnement d une application MapReduce 10
Exemple de MapReduce (2) MapReduce is a programming model and an associated implementation for processing and generating large data sets. Users specify a map function that processes a key/value pair to generate a set of intermediate key/value pairs, and a reduce function that merges all intermediate values associated with the same intermediate key. Many real world tasks are expressible in this model, as shown in the paper. Découpé en Records MapReduce is a programming model and an associated implementation for processing and generating large data sets. Users specify a map function that processes a key/value pair to generate a set of. intermediate key/value pairs, and a reduce function that merges all intermediate values associated with the same intermediate key. Many real world tasks are expressible in this model, as shown in the paper. 11
Exemple de MapReduce (3) large data sets. Users specify a map function that processes a key/value pair to generate a set of. MAP Mot (clé) Nb Occurrences (valeur) Large 1 Data 1 Sets 2 Users 1 Specify 1 A 3 12
Exemple de MapReduce (4) MapReduce is a programming model and an associated implementation for processing and generating large data sets. Users specify a map function that processes a key/value pair to generate a set of intermediate key/value pairs, and a reduce function that merges all intermediate values associated with the same intermediate key. Many real world tasks are expressible in this model, as shown in the paper. Mot (clé) Nb Occurrences (valeur) Large 1 Data 1 Sets 2 Users 1 Specify 1 A 1, 3, 1, 0 13
Exemple de MapReduce (5) REDUCE Mot (clé) Nb Occurrences (valeur) Large 1 Data 1 Sets 2 Users 1 Specify 1 A 5 14
Hadoop - MapReduce : Utilisations Tri distribué Inversion des liens d un graphe Web Construction d un index inversé Apprentissage automatique Minage de données Permis par la modularité 15
Plan 1. 2. 3. 4. 5. 6. Contexte Hadoop Giraph L étude Partitionnement ifub 16
3. Giraph - Introduction Système itératif de traitement de graphes Inspiré par Google Pregel (2010) Donné à l ASF par Yahoo! en 2011 Version 1.1 en novembre 2014 17
3. Giraph - Généralités Propose une implémentation de BSP++ Modulaire (OO), interopérable (I/O formats) Basé sur Hadoop : gestionnaire de ressources Open source (GIT) 8 contributeurs 18
BSP - Bulk Synchronous Parallel Modèle de programmation Créé par Leslie Valiant ~1980s, finalisé en 90 «Calcul parallèle synchronisé en vrac» 3 composants : - Traitement CPU, mémoire - communication messages - synchronisation barrières 19
BSP- Bulk Synchronous Parallel Calcul Messages Barrière 20
3. Giraph - BSP orienté sommets Algorithmes localisés : Un sommet n a pas de vision globale du graphe : il ne connait que ses voisins Penser comme un sommet 21
3. Giraph - Architecture 22
3. Giraph - Cycle de vie d un Job Cycle de vie d un Job Giraph : Chargement Traitement Résultats 23
3. Giraph - Exemple : ShortestPath Algorithme de calcul des distances Source unique Applications : - GPS - Graphe social - Diamètre -... 24
3. Giraph - Exemple (2) Après Map et merge on obtient une Liste <vertex_id,list<out_vertex_id>> SuperStep -1 25
3. Giraph - Exemple (3) SuperStep 0 26
3. Giraph - Exemple (4) SuperStep 1 27
3. Giraph - Exemple (5) SuperStep 2 28
3. Giraph - Exemple (6) SuperStep 3 29
3. Giraph - Récapitulatif Avantages Communauté Open Source Adaptable Scalable Mature Algorithmes Inconvénients Repose sur Hadoop Lourd Moins de contrôle 30
Notre expérience 2 jours pour configurer Hadoop sur 1 machine - Tutoriel de Giraph pas à jour - Configuration SSH - Utilisation fastidieuse (mode console) - Pas prévu pour les clusters Torque 1 semaine pour le faire tourner sur le cluster 31
Notre expérience Grâce à la doc, on a pu : - implémenter des algos - écrire des formats d input personnalisés - jouer sur les options Réponse sur la mailling liste en une journée 32
Plan 1. 2. 3. 4. 5. 6. Contexte Hadoop Giraph L étude Partitionnement ifub 33
4. L étude - Datasets Graphes des followers de Twitter Graphe du réseau social Friendster Nom Taille (en octets) Nombre d arêtes 2006_1 19K 980 2006_2 3,1M 165 416 2007_1 129M 6 870 660 2007_2 317M 16 988 093 2008_1 1,2G 62 595 022 2008_2 3,8G 204 336 559 Friendster 32.3G 1 806 067 135 34
4. L étude - Algorithmes - Breath First Search : Plus courts chemins simplifié Parcours d un graphe à partir d une source - PageRank Calcul de popularité des sommets Touts les sommets à chaque étape 35
4. L étude - Tableau de résultats Exécution sur 4 noeuds avec 4 cores de BFS Graphe Arrêtes Sommets Taille (Mo) Temps Chargement Chargement en CPU dans HDFS (s) mémoire (s) cumulé (s) Total selon Giraph (s) Total Messages absolu (s) envoyés (Mo) Mémoire utilisée (Mo) 2006_1 980 120 0,019 3 0,5 27 13 46 0,01 1 829 2006_2 165 416 8 812 3,236 3 1,3 37 12 44 2 2 009 2007_1 6 870 660 188 741 134,452 4 7,1 75 20 50 81 4 043 2007_2 16 988 093 420 836 332,382 7 14 169 28 59 201 6 230 2008_1 62 595 022 1 243 656 1 224,685 16 31 389 52 82 744 7 927 2008_2 204 336 559 3 143 252 3 997,264 61 88 1154 149 184 2432 12 477 36
4. L étude - Graphiques : Temps 37
4. L étude - Graphiques : Temps 38
4. L étude - Graphiques : Mémoire 39
4. L étude - Graphiques : Analyse 2 Go de mémoire utilisé minimum Courbes linéaires Bonne Scalabilité Performances faussées par : partage des ressources sur NEF configuration non adaptée 40
4. L étude - Graphiques : Noeuds # Cores # Nodes Cores/node Temps (s) 32 16 2 378 32 8 4 383 32 cores reparti sur 16 ou 8 noeud : 1% de différence BFS sur friendster 41
4. InfiniBand Réseau de mémoire à mémoire bypass la couche TCP/IP et OS Infiniband est tellement rapide que le surcout réseau devient négligeable 42
4. L étude - Et après? Script d installation automatique Parser de résultats Documentation pour : - l utilisation sur NEF - le développement 43
4. L étude - Amélioration Le temps d'exécution à été réduit par 3 en utilisant les mêmes ressources grace à : - InfiniBand - meilleur conf (4x plus de workers) BFS sur Twitter 2008_2 (4GB) 180s 60s 44
Plan 1. 2. 3. 4. 5. 6. Contexte Hadoop Giraph L étude Partitionnement ifub 45
5. Partitionnement - Principe But : Améliorer les performances Besoin d équilibrer les charges Nombre d'arêtes équivalent Minimiser les messages réseau Minimiser les coupes Coupes 24a 10s 28a 12s 46
5. Partitionnement - Spinner Créé par : - Claudio Martella à VU University Amsterdam - Dionysios Logothetis Telefonica Research - Georgos Siganos Telefonica Research Basé sur la propagation de labels (LPA) Graphe G, k partitions Fichier de partitionnement 47
Partitionnement - Expérimentation 61 64,26 % 56 64,09 % Fenètre = 5 Uniformément répartit au départ acc2008_2 en 4 partitions 1 partition/worker 4 worker 48
Partitionnement - Exp (2) 49
5. Partitionnement - Exp (3) 50
5. Partitionnement - Conclusion Peu intéressant sur BFS à cause de la nature de l algorithme Donne de mauvais résultats sur un petit nombre de workers et partition/worker. Une solution : augmenter le ratio de partitions par Worker (de 1 à 4) 51
Plan 1. 2. 3. 4. 5. 6. Contexte Hadoop Giraph L étude Partitionnement ifub 52
6. ifub Algorithm for diameter computation Published by Pilu Crescenzi, Roberto Grossi, Michel Habib, Leonardo Lanzi and Andrea Marino 53
6. ifub It uses the BFS, that most frameworks implement The algorithm is very efficient on real-world graphs due to their structure (O(n*m) but O(m) in practice). 54
6. ifub - Step 1 Several methods to chose the source : - a random vertex - highest degree - lowest eccentricity 2-sweep 55
6. ifub - Step 2 Triangular inequality : d(1,2) d(1,s) + d(2,s) d(1,s) = d(2,s) = i d(1,2) 2 * i 56
6. ifub 4 classes : IFUB : main class IFUBComputationRequest : remote code executed by each worker of the cluster IFUBCompResult : internal message class IFUBResult : extends DiameterResult 57
6. ifub - Results On a 100x100 grid graph: Centralised, results are similar to those on Sage, around the second Slower in distributed, around 20 seconds Performance gap explained by the communications of the cluster. The code was integrated in the 0.0.30 release of BigGrph 58
THE END 59
Autres Frameworks Boost graph library Pegasus, GraphLabPowerGraph the Knowledge Discovery Toolkit GPS, and Grace 60
Autres Frameworks - GPS Graph Processing System Université de Stanford Équivalent à Giraph Travail sur le partitionnement intelligent Pas mal d algorithmes implémentés Pas Multi-Threads 61
GraphLab Pas de BSP Gather, Apply, Scatter Accès direct aux voisins, sans messages Partitionnement différent : mise en cache des sommets Not mutable 62
Ligra Pour machine à mémoire partagé Carnegie Mellon University 41 millions sommets 1.47 Milliard arêtes GitHub : 3 contributeurs, 52 commits Non mutable 63
Partitionnement - Spinner (2) Étapes initiales: - Charger le graphe en mémoire - Transformer en Graphe non dirigé - Assigner les partitions au hasard Puis répétition de deux étapes jusqu'à : - Convergence, ou - Nombre maximum d itérations 64
Partitionnement - Spinner (3) Étape 1 LPA, pour chaque sommet : - Calcul du score/partition - Score Maximum Partition la + attrayante - Si changement Demande de migration Etape 2 Migration - Migration effective selon une probabilité - Propagation du changement 65