Dans cette approche (repr´esent´ee par la figure 4.13), nous traitons la probl´ematique de recherche des histogrammes les plus discriminants de cette fac¸on :
4 CloudHistSyr : Impl´ementation et tests du programme global 159 1. Lancer le module de calcul des bornes possibles : ce module retourne `a partir de toutes
les valeurs d’une variable continue la liste de valeurs fronti`eres.
2. Lancer le module de calcul d’histogrammes en prenant la liste enti`ere (r´esultat de la premi`ere ´etape) comme liste de bornes.
3. Utiliser un module de calcul des histogrammes de k modalit´es qui discriminent le mieux les diff´erents concepts. Cet algorithme est l’adaptation de l’algorithme de Fisher afin qu’il prenne en entr´ee le r´esultat du deuxi`eme module au lieu de travailler sur les donn´ees initiales brutes.
Data set
Calcul des hitogrammes Calcul des bornes
Map/Reduce
Map/Reduce
Recherche des meilleurs histogrammes de k modalités
Centralized
FIGURE4.13 – Composition de CloudHistSyr suivant la deuxi`eme approche.
4.2.1 Test de la deuxi`eme approche sur les donn´ees des Iris
Pour tester cette deuxi`eme approche nous avons utilis´e les donn´ees des iris Fisher (de taille 13.6Go) avec un cluster EMR compos´e d’un master et de 16 nœuds de types m3.xlarge.
L’ex´ecution des deux jobs ”Calcul bornes” et ”Calcul Histogrammes ” a n´ecessit´e presque 7 minutes. La figure 4.14 illustre les d´etails de l’ex´ecution du job sur EMR. D’apr`es cette figure :
• Le premier module a ´et´e ex´ecut´e au bout de 281.150 sec = 4min 42 sec .
• La liste des bornes I ={4.85 ; 4.95 ; 5.05 ; 5.15 ; 5.25 ; 5.35 ; 5.45 ; 5.55 ; 5.65 ; 5.75 ; 5.85 ; 5.95 ; 6.05 ; 6.15 ; 6.25 ; 6.35 ; 6.45 ; 6.55 ; 6.65 ; 6.75 ; 6.85 ; 6.95 ; 7.05}
FIGURE 4.14 – Temps d’ex´ecution des deux jobs de calcul des bornes suivi du calcul d’histogrammes.
• Le deuxi`eme module a ´et´e ex´ecut´e au bout de 147.379 sec = 2 min 27 sec.
Les fichiers r´esultats du module de calcul d’histogrammes sont regroup´es dans un mˆeme fichier. Ce dernier sera introduit avec le fichier contenant les bornes possibles au programme centralis´e de recherche du meilleur histogramme. Ce programme retourne alors les histogrammes de 3 modalit´es les plus discriminants en 94 ms. L’ensemble des fichiers g´en´er´es par ce programme sont repr´esent´es dans la figure 4.15.
FIGURE 4.15 – Les fichiers r´esultats du module de recherches des histogrammes les plus discriminants.
NB :Ces r´esultats sont identiques `a celles obtenues en lanc¸ant HistSyr sur la base de donn´ees initiale de 150 Iris. Ce qui permet de valider la justesse de l’ensemble des modules constituants CloudHistSyr.
4.2.2 Avantages et inconv´enients de la deuxi`eme approche Avantages :
• Cette solution est moins couteuse que la premi`ere.
5 Application de CloudHistSyr sur les donn´ees r´eelles du portique de Nantes 161
• Les r´esultats des jobs Map/Reduce sont r´eutilisables puisqu’ils permettent : de calculer la liste des bornes fronti`eres et de r´esumer les donn´ees initiales par rapport `a cette liste.
Ce qui rend possible de changer le nombre des modalit´es des histogrammes sans refaire les tests dans le Cloud.
Inconv´enients :
• Le temps d’ex´ecution du deuxi`eme module peut augmenter de fac¸on consid´erable si le nombre de bornes possibles augmente (voir section 5).
• Le dernier composant de cette solution (l’algorithme centralis´e de recherche des meilleurs bornes de d´ecoupages), peut avoir des limites avec des donn´ees ayant plusieurs milliers de bornes possibles.
La probl´ematique du temps d’ex´ecution du deuxi`eme module peut ˆetre r´esolue soit en augmentant le nombre de nœuds dans le cluster, soit en lanc¸ant d’une fac¸on parall`ele des jobs de calcul d’histogrammes prenant des sous liste de la liste initiale des bornes. Ce qui reviendrait
`a subdiviser la liste des bornes et lancer un nombre n´egligeable de clusters en parall`ele compar´e
`a ce qui est propos´e dans la premi`ere approche.
5 Application de CloudHistSyr sur les donn´ees r´eelles du portique de Nantes
5.1 Pr´esentation des donn´ees initiales
Les donn´ees ont ´et´e recueillies dans le temps par 21 capteurs install´es sur un portique d’autoroute≪test≫. Les 21 capteurs peuvent ˆetre divis´es en deux groupes diff´erents :
• 11 capteurs de changement d’´etat dont : – 3 acc´el´erom`etres ACC1, ACC2, ACC3 ; – 2 inclinom`etres INC1, INC2
– 6 jauges de d´eformation GAG1 `a GAG6
• 1 station m´et´eo compos´ee de 10 capteurs dont : – 5 capteurs de pression PR1 `a PR5
– 2 capteurs de temp´eratures TEMP1 et TEMP2
Trois ´etats diff´erents ont ´et´e simul´es chronologiquement ”Avant”, ”Pendant” et ”Apr`es” :
• Un premier ´etat sans d´efaut = Avant le 20 f´evrier 2013
• Un second ´etat d ˆu `a l’ajout de deux masses sur le portique. L’ajout de ces deux masses est consid´er´e ´equivalent `a un d´efaut = Pendant (entre le 21 f´evrier le 03 mars 2013)
• Un troisi`eme ´etat apr`es le retrait des masses = Apr`es le 4 mars 2013
Les donn´ees consid´er´ees ont ´et´e enregistr´ees entre le 19 d´ecembre 2012 et le 15 avril 2013.
Durant cette p´eriode, plusieurs enregistrements sont effectu´es chaque jour durant une dur´ee limit´ee (le nombre d’enregistrements quotidiens et leurs dur´ees ne sont pas toujours les mˆemes sur la p´eriode ´etudi´ee). Ces enregistrements sont appel´es ”´ev`enements dynamiques”. Par exemple, ”Event 2013-01-15 08” d´esigne l’´ev`enement du 15 janvier 2013 num´ero 8. Nous avons au total 2100 ´ev`enements dynamiques. Chaque ´ev`enement dynamique produit un fichier de donn´ees recueillant les mesures `a chaque instant. Dans ce fichier, les lignes sont des instants et les colonnes repr´esentent les valeurs relatives `a chacun des 21 capteurs (changement d’´etat + station m´et´eo).