Développement d’un prototype

Contexte

Depuis quelques années, nous assistons à une augmentation du volume d’information créé. Cette quantité d’information provient de l’utilisation des réseaux sociaux, de l’accroissement de l’usage des téléphones intelligents et des tablettes connectés à Internet et de leur capteur intégré. Elle provient aussi des transactions commerciales que nous faisons, des réseaux de capteurs industriels, de vidéos, de caméra de surveillance, de journaux (logs) qui suivent nos comportements sur Internet et sur nos appareils électroniques et, bientôt, d’une panoplie d’objets connectés qui formera l’Internet des objets. Il faut aussi ajouter à ce flot les données provenant des balises géoréférencées WiFi et Bluetooth. Ces balises permettent de détecter les appareils électroniques et de faire leur suivi en milieu urbain. La majorité de ces informations sont produites en continu sous la forme de flux de données.

En 2014, une recherche de l’International Data Corporation (IDC) rapportait que les objets connectés mobiles généraient 18 % des données de l’univers numérique et qu’en 2020, cette proportion serait de 27 %(International Data Corporation, 2014a, 2014b). Traditionnellement, les jeux de données sont peu changeants, c’est-à-dire que l’information n’évolue pas avec le temps ou évolue lentement. On dit que ces données sont au repos, persistantes ou statiques. Une classe d’entité représentant les bornes-fontaines d’une municipalité est un exemple de données statiques. De l’autre côté du spectre, nous avons des objets dont les changements d’état rapides requièrent des mises à jour fréquentes. Ces données sont dites dynamiques. Une classe d’entité représentant des objets mobiles et ayant des mises à jour de position et d’état à la seconde est considérée comme étant dynamique.

Ce mémoire fait référence aux données statiques comme étant des données traditionnelles. Bien qu’il y ait une gradation entre les données purement statiques et celles dynamiques, le terme dynamique sera réservé à celles dont la mise à jour est rapide et fait l’objet d’une surveillance ou d’un traitement en continu. Pour une application traitant des données de façon dynamique, les données récentes auront plus de valeur que les données anciennes. Par exemple, une application de surveillance d’objets mobiles voudra avertir le plus tôt possible son utilisateur de la détection d’un patron de déplacement suspect. Plus le temps pour obtenir et traiter la donnée est éloigné du temps où celle-ci a été produite, plus la valeur de l’information obtenue sera de moindre intérêt. Dans un processus décisionnel, il devient donc avantageux de les traiter le plus tôt possible (Laney, 2001; Golab et Özsu, 2003; Stonebraker et al., 2005; Hurwitz et al., 2013). La valeur intrinsèque de ces flux de données, qui sont produits sans arrêt, peut s’avérer somme toute limitée.

Toutefois, lorsqu’ils sont combinés entre eux ou à des données traditionnelles, ils peuvent servir à comprendre des phénomènes et être utilisés pour offrir de nouvelles perspectives de traitements et d’analyses spatiales pour de nouvelles applications utilisant des flux géospatiaux à grande échelle (Kazemitabar et al., 2011). De plus, cette information est souvent géoréférencée. Par exemple, les messages d’un utilisateur de Twitter peuvent être géoréférencés à l’aide du GPS de son cellulaire, un capteur connecté à Internet peut transmettre aussi bien le résultat de son analyse que sa position et le journal des transactions d’une carte de crédit peut contenir des éléments spatiaux comme l’endroit de la transaction.

Finalement, les véhicules intelligents et autonomes seront à même de fournir une masse d’information géoréférencée sous la forme de flux (Kazemitabar et al., 2011; Wang et Yuan, 2014). Ces flux géoréférencés deviennent donc des flux spatiaux qui nous parviennent avec de très grands débits et volumes. Il devient donc impossible de traiter ces flux dans un temps raisonnable à l’aide de méthodes dites conventionnelles (Kazemitabar et al., 2011; Shekhar et al., 2014). L’utilisation de techniques de traitement de données massives (Big Data) devient donc une solution pour tirer avantage du dynamisme de cette information ainsi que de son aspect changeant et volatil. Dans le domaine de la géomatique, cela signifie de pouvoir effectuer des opérations spatiales en temps réel utilisant ces flux géoréférencés.

Les flux

Les données peuvent être classifiées en deux grandes catégories, soit 1) les données persistantes et 2) les données sous forme de flux. Les données dites persistantes sont celles qui nous sont les plus familières. Elles sont considérées comme « constantes » dans le temps ou ayant un faible taux de changement. Par exemple, elles peuvent représenter un réseau routier, une couche écoforestière ou une répartition démographique. Ces jeux de données persistantes ne sont en fait qu’une vue instantanée sur une période de temps donné. Le réseau routier est en évolution, le jeu de données démographiques sera mis à jour lors du prochain recensement et il en va de même pour les couches écoforestières. Une des composantes importantes dans le choix des jeux de données est la date d’acquisition. Bien que ces données soient en constant changement, leur fréquence de mise à jour est faible comparativement à leur fréquence d’utilisation.

Ces données possèdent donc une valeur durable dans le temps, sans quoi elles deviendraient obsolètes et inutilisées. Selon les besoins, ces données seront stockées et structurées de manière à faciliter les traitements et les requêtes sur celles-ci. Par exemple, les données seront réparties dans une base de données relationnelle afin de minimiser la répétition d’information. Celles-ci seront aussi indexées, spatialement ou non, afin d’augmenter la rapidité des requêtes sur le jeu de données. Une autre particularité des données persistantes réside dans le fait que l’entièreté du jeu de données est disponible au moment du traitement. De plus, ces données seront sauvegardées dans le système que si l’état du système reste cohérent.

Dans l’autre catégorie, on retrouve les flux de données. Ces données sont rendues disponibles à travers une séquence de données transmises dans le temps. Comparativement aux données persistantes, la fréquence de mise à jour est très élevée. On considérera que ce flux d’information est potentiellement illimité en taille. Bien que la fréquence de mise à jour soit élevée, celle-ci n’est pas nécessairement constante. De plus, ces données ne nous parviennent pas nécessairement dans l’ordre. Par ailleurs, une des caractéristiques des flux de données est leur nature éphémère, pour laquelle il n’est pas toujours possible de les refaire jouer. Ainsi, les données ne sont transmises qu’une seule fois et si elles ne sont pas traitées ou stockées, elles sont perdues (Babcock et al., 2002; Arasu et al., 2004; Hershberger et al., 2009; Gama, 2010; Bifet et al., 2011). Les applications utilisant des flux de données diffèrent de celles utilisant des données persistantes.

Dans le cas des données persistantes, l’application aura accès au jeu de données entier et ses requêtes seront limitées à l’étendue temporelle de validité du jeu de données. Les résultats seront statiques dans le temps, c’est-à-dire qu’une requête faite à deux moments différents retournera le même résultat. La composante temporelle est quant à elle inhérente aux données transmises en flux. Comme elles sont mises à jour fréquemment, leurs valeurs et les résultats d’analyse de celles-ci diminuent dans le temps. Dès lors, il s’avérera nécessaire de traiter ces informations en temps réel (Stonebraker et al., 2005; Hurwitz et al., 2013).

L’utilisation de systèmes de gestion de bases de données (SGBD) n’étant pas adaptée aux flux de données, des systèmes de gestion de flux de données (SGFD) ont été proposés pour gérer l’arrivée et le traitement rapide de ces données. Ces SGFD permettent aussi de répondre aux requêtes en continu, qui sont intrinsèques à ce type de données (Babcock et al., 2002). Ces applications produisent elles-mêmes des résultats en continu sous la forme d’un flux. Ces requêtes en continu doivent pouvoir intégrer tant les données sous forme de flux que celles provenant de jeux de données persistantes (Huang et Zhang, 2008; Galić et al., 2014). Qui plus est, ces applications doivent aussi gérer les opérateurs dits bloquants (Golab et Özsu, 2003; Stonebraker et al., 2005). Par exemple, trouver la moyenne, effectuer un tri ou même faire une opération de jointure nécessitent de disposer de l’ensemble des données.

Or, un flux est par définition illimité. Pour résoudre ce problème, certaines techniques, basées sur des accumulateurs, ont été développées. L’accumulation des données pendant une période de temps ou jusqu’à l’obtention d’une quantité d’information déterminée permet alors de traiter l’information sous la forme de fenêtre. Plusieurs types de fenêtres ont été imaginées, telles que les fenêtres à bascules (tumbling window) et les fenêtres glissantes (sliding window) (Babcock et al., 2002; Gama, 2010; Bifet et al., 2011). Dans une fenêtre à bascule, une période de temps ou une quantité de données sont assignées, ce qui correspond à la dimension de la fenêtre. Dans le cas d’une période prédéfinie, toutes les données seront accumulées pendant cette période et seront traitées ensemble. Il n’y a pas de chevauchement de données dans une fenêtre à bascule. Quant à elles, les fenêtres glissantes comportent, en plus de la dimension de la fenêtre, un paramètre de glissement. Celui-ci permet à une seconde fenêtre de partager une partie des données de la première avec pour conséquence un chevauchement des fenêtres. L’image suivante représente les fenêtres à bascule en haut et glissantes en bas.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport gratuit propose le téléchargement des modèles gratuits de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

Résumé
Abstract
Table des matières
Liste des figures
Liste des tableaux
Liste des codes et pseudo-codes
Remerciements
Chapitre 1 Introduction
1.1 Contexte
1.2 Notions liées aux traitements spatiaux de flux massifs géoréférencés
1.2.1 Les flux
1.2.2 Les données massives (Big data) et leurs traitements
1.2.3 Les opérateurs spatiaux
1.3 Revue de l’existant
1.3.1 Traitement de flux spatiaux
1.3.2 La donnée spatiale dans les traitements massifs de données
1.4 Problématique
1.5 Objectifs
1.6 Méthodologie
1.6.1 Phase d’analyse
1.6.2 Phase de prototypage
1.6.3 Validation
1.7 Description des prochains chapitres
Chapitre 2 Phase d’analyse
2.1 Analyse des facteurs influençant les traitements spatiaux de flux massifs
2.1.1 Les opérateurs spatiaux de base et leurs propriétés
2.1.2 Les caractéristiques des données
2.2 Classification
2.2.1 Cas des opérateurs unaires
2.2.2 Cas des opérateurs binaires
2.3 Choix de la classe pour l’étude de cas
2.4 Analyse de l’étude de cas
2.4.1 Accumulation des flux par fenêtre
2.4.2 Le partitionnement spatial
2.5 Application du géo-hachage sur des traitements spatiaux
2.5.1 Cas d’étude sur un traitement de relation topologique
2.5.2 Cas d’étude sur une relation de proximité
2.6 Inventaire des caractéristiques requises pour le système de traitement spatial de flux massifs
2.7 Conclusion
Chapitre 3 Développement d’un prototype
3.1 Choix de la plateforme technologique
3.1.1 Apache Storm
3.1.2 Apache Spark
3.1.3 Apache Flink
3.1.4 Comparaison des plateformes
3.2 Description d’une architecture Apache Flink
3.2.1 Utilisation de Kafka comme source et destination
3.2.2 Plateforme Apache Flink
3.3 Architecture du prototype
3.3.1 Simulateur de jeux de données
3.3.2 Cluster Flink
3.3.3 Moniteur de performance
3.4 Prototypes de traitement spatial
3.4.1 Cadre pour le développement des prototypes
3.4.2 Relation spatiale
3.4.3 Analyse de proximité
3.5 Banc de tests
3.5.1 Cadre de tests
3.5.2 Plan de test pour le prototype de relation spatiale
3.5.3 Plan de test pour l’analyse de proximité
Chapitre 4 Résultats et analyses
4.1 Résultats du prototype de relation spatiale
4.2 Analyse des résultats du prototype de relation spatiale
4.2.1 Première observation
4.2.2 Deuxième observation
4.2.3 Troisième observation
4.3 Résultats du prototype de l’analyse de proximité
4.4 Analyse des résultats du prototype d’analyse de proximité
4.4.1 Rappel de notions
4.4.2 Analyse des observations
4.5 Conclusion
Chapitre 5 Conclusion générale
5.1 Conclusion
5.2 Contribution
5.3 Limites de la recherche
5.4 Perspectives
Références