Gestion des données distribuées à large échelle
Professeur: MOLLI Pascal
Étudiants: BA RAGAA Mohammed ali ahmed, JIMENEZ Oswaldo
PageRank - comparaison Pig vs PySpark. Consigne: https://madoc.univ-nantes.fr/mod/assign/view.php?id=1523335
1. Introduction - Description de l'expérience
2. Exécutions pagerank - Pig vs PySpark
3. Meilleur pagerank
4. Conclusions et recommendations
Le but de cette expérience c'est de comparer les performances de l'algorithme pagerank, entre une implémentation Pig et une implémentation PySpark. Cette expérience est inspiré d'une démonstration realisée lors de la conférence NDSI 2012 présentation des Resilient Distributed Datasets (RDD).
Premièrement, nous présentons les configurations utilisées pour réaliser cette expérience, ensuite nous comparons les temps d'exécution du pagerank avec des diagrammes à ligne brisée et nous illustrons les meilleurs pagerank computés. Finalement, nous présentons les conclusions et récomendations issues des comparaisons et le déroulement de l'expérience.
Afin de mesurer la performance entre les implémentations Pig et Pyspark, nous avons eu recours au service d'exécution de tâches Dataproc de la suite Google cloud. Les configurations et considérations tenus en comptes pour réaliser cette expérience s'énumèrent ci-après:
- Paramètres pagerank: le nombre d'iterations a été fixé à 3, et le facteur pagerank utilisé à {d = 0.85}, pour les deux implémentations.
- Nombre de noeuds: 2, 3, 4 et 5. Le nombre de noeuds a été déterminé en raison des restrictions du quota et la puissance minimale requise pour le fonctionnement des algorithmes.
- Région du cluster: fixé à europe-west1, définie en function de la proximité avec le bucket hébergeant les données d'entrée.
- Données d'entrée: le dataset page_links_en.nt.bz2, préchargé dans le bucket public gs://public_lddm_data//page_links_en.nt.bz2
- Version PIG installée dans le cluster: Apache Pig version 0.18.0-SNAPSHOT
- Version PySpark installée dans le cluster: Spark 3.1.3
Implémentations du pagerank utilisées:
- Implémentation Pig
https://github.com/oahjimenez/x3ia020_pagerank/blob/main/pig/dataproc.py - Commandes d'exécution Pig
https://github.com/oahjimenez/x3ia020_pagerank/blob/main/pig/run.sh - Implémentation PySpark
https://github.com/oahjimenez/x3ia020_pagerank/blob/main/pyspark/pagerank.py - Commandes d'exécution PySpark
https://github.com/oahjimenez/x3ia020_pagerank/blob/main/pyspark/run.sh - Code source original, auteur professeur Pascal MOLLI: https://github.com/momo54/large_scale_data_management
- Rajout du calcul DISTINCT dans la méthode INIT, afin de supprimer des tuples url dupliquées et de rendre les résultats équivalents à ceux obtenus avec PySpark.
- Rajout du calcul des top pageranks, retenant les url voisines (to_url) qui sont autrement écartées dans la prochaine itération lors de l'application du cogroup inner.
- Applique un partitionnement aux rdds links et ranks, visant la réduction des Shuffles entre les joins par itération. Nous avons utilisé la function de partition portable_hash sur les clés et le calcul du nombre de partitions par défaut.
Les résultats issus des exécutions pageranks en utilisant les différentes configurations de cluster sont présentés ci-dessous. Pour l'implémentation PySpark, on distingue le temps d'exécution entre l'implémentation sans et avec partitionnement contrôlé.
| Nombre de noeuds | Temps d'exécution | Dataproc Job id |
|---|---|---|
| 2 | 57 min 19 sec | 83edf25aa5e24364a1ea968a99ab415f |
| 3 | 47 min 50 sec | 85961f8339bc43bcbaf5cf69cd13719d |
| 4 | 38 min 8 sec | 6d80276d638d4d0096f0d2bbad55debc |
| 5 | 35 min 27 sec | 1ad6eaf435d24191878899943ae73a15 |
| Nombre de noeuds | Temps d'exécution | Dataproc Job id |
|---|---|---|
| 2 | 43 min 30 sec | 895b7b281f794d4393278962e01169ad |
| 3 | 38 min 23 sec | 527ace71d1ce4f9da1b5f5ab5581c2dd |
| 4 | 35 min 28 sec | e870244c239b47e1bf2e6c86691d4bfa |
| 5 | 35 min 04 sec | 9d52c020836c41cba2c50e3da3de29e7 |
| Nombre de noeuds | Temps d'exécution | Dataproc Job id |
|---|---|---|
| 2 | 42 min 48 sec | 71dd624351af42128d8d321c5fc314dd |
| 3 | 31 min 41 sec | f0c04b5b485b4504952c75b7e51b3e44 |
| 4 | 29 min 12 sec | 3f475ada46de4c7ab8e0ca526c1ed5a5 |
| 5 | 30 min 20 sec | 98c8047900634a33882b2296b8a8293a |
Ci-après suit un diagramme à ligne brisée illustrant la comparaison des temps d'exécution entre les implémentations pagerank, pour chaque configuration de cluster utilisée
Sur ce graphique nous pouvons constater les points suivants:
- Pig est l'implémentation la moins performante avec peu des noeuds, ce qui pourrait s'expliquer par les écritures des résultats intermediaries sur le disque avec des ressources limitées.
- PySpark avec du partitionnement est l'implémentation qui performe le mieux en moyen, néanmoins cette implémentation atteint un seuil à 4 noeuds.
- Pig bénéficie le plus de l'augmentation du nombre de noeuds, ce qui devient plus évident dans le range de 4 à 5 noeuds. Nous pouvons apprécier que les implémentations sur PySpark atteignent un seuil dans leurs temps d'exécution dans cette range de 4 à 5 noeuds, tandis que le temps d'exécution continue à diminuer pour Pig.
- L'implémentation sur Pig rattrape l'implémentation sur PySpark Basic pour la configuration à 5 noeuds.
- Avec des ressources limitées (2 noeuds), Pyspark ne semble pas bénéficier d'une amélioration en raison du partionnement.
Les meilleurs pagerank computés dans le cadre de ces exécutions sont présentés dans la section suivante.
Nous avons obtenu que l'entité avec le meilleur pagerank c'est l'uri http://dbpedia.org/resource/Living_people, avec un pagerank de 36,794.33. On présente ci-après le top 10 des uri ayant le meilleur pagerank, issue de 3 itérations de l'algorithme pagerank.
| Rank | Url | Pagerank |
|---|---|---|
| 🥇 | http://dbpedia.org/resource/Living_people | 36794.33146754463 |
| 🥈 | http://dbpedia.org/resource/United_States | 13201.340151981207 |
| 🥉 | http://dbpedia.org/resource/Race_and_ethnicity_in_the_United_States_Census | 10371.162005541351 |
| 4 | http://dbpedia.org/resource/List_of_sovereign_states | 5195.34736186218 |
| 5 | http://dbpedia.org/resource/United_Kingdom | 4923.82130931521 |
| 6 | http://dbpedia.org/resource/Year_of_birth_missing_%28living_people%29 | 4615.7939763369795 |
| 7 | http://dbpedia.org/resource/France | 4595.730518177778 |
| 8 | http://dbpedia.org/resource/Germany | 4111.195621667528 |
| 9 | http://dbpedia.org/resource/Canada | 3765.46156061246 |
| 10 | http://dbpedia.org/resource/Animal | 3692.395898434714 |
Ces valeurs de pagerank correspondent aux résultats issus de l'implémentation Pyspark. Des résultats équivalents sont obtenus avec Pig, à condition de rajouter la clause DISTINCT dans la méthode INIT et de calculer les pageranks sur le jeu de données to_url avant de computer le dernier cogroup.
Cette étude nous a permis d'appliquer les savoir-faire appris dans ce module afin de mettre en oeuvre et comparer les implémentations Pig et PySpark de l'algorithme PageRank, dans le contexte du traitement des données massives sur l'environnement distribué GCP. Nous résumons les principales conclusions dérivées de cette expérience ci-dessous:
-
PySpark avec du partitionnement contrôlé est l'implémentation qui performe le mieux en moyen. Bien que nous espérions que les opérations des RDD dans le RAM et les optimisations en matière de partage de ressources allaient dépasser significativement l'implémentation sur Pig, nous avons obtenu qu'au but de 5 noeuds, Pig a rattrapé en temps d'exécution, ce qui pourrait indiquer que les avantages offerts par les RDD et le partionnement contrôlé n'ont pas été exploités au maximum pour cette expérience.
-
Quant à l'implementation PySpark avec du partitionnement contrôlé, nous avons utilisé le calcul du nombre de partitions par défaut. Nous recommandons de mettre en oeuvre des configurations plus exactes pour mieux bénéficier des avantages du partionnement, par exemple une sélection du nombre de partitions en function du nombre de coeurs disponibles dans le cluster.
-
Pour une même configuration d'exécution, nous avons constaté des différences non négligables en termes du temps d'exécution. Nous attribuons ce comportement aux variations dans les disponibilités et l'état des santé des clusters. Afin de minimiser ce bruit dans l'analyse du temps d'exécution, nous recommandons, pour chaque configuration, d'exécuter les expériences à plusieurs reprises pour ensuite présenter les résultats moyens. Les résultats présentés pour cette expérience correspondent aux modes des paires d'exécutions, en raison des limites sur les crédits GC.
-
Nous recommandons d'explorer les types de données suggérés autres que le float pour éviter une perte de précision pour les calculs sur Pig, au but de minimiser les différences entre les valeurs pagerank de chaque implémentation.