Tutoriel pour découvrir le monde du Big Data : définition, applications et outils

Ce tutoriel permet de découvrir le monde du Big Data en présentant les définitions, les applications majeures et les systèmes qui le supportent.

Pour réagir au contenu de ce tutoriel, un espace de dialogue vous est proposé sur le forum 1 commentaire .

Article lu fois.

Les deux auteurs

Mehdi Acheli

Selma Khouri

L'article

Publié le 20 juillet 2017

Version PDF Version hors-ligne

ePub, Azw et Mobi

Liens sociaux

I. Introduction▲

En une minute sur l'Internet, les utilisateurs de Facebook éditent 3,4 millions de statuts et génèrent 4 GB de données digitales, Google répond à 300 000 recherches et reçoit 126 heures de vidéos et pas moins de 700 nouveaux utilisateurs rejoignent Twitter. Au même moment, 350 000 tweets sont générés et 10 000 recherches sont exécutées sur LinkedIN. D'un autre côté, dans le monde commercial, Walmart produit 2,5 pétaoctets par jour et traite un million de transactions par heure. Alibaba, un des plus importants sites de e-commerce, a également déclaré que son stock de données traitées a atteint 100 pétaoctets [Sakr, 2016]. Ces statistiques prouvent que le monde devient le théâtre d'un accroissement de données sans précédent. Un accroissement provoqué par l'ubiquité de l'Internet, l'adoption des réseaux sociaux et des applications mobiles, la vulgarisation des capteurs, des systèmes de localisations géographiques et des tags RFID… [Sakr, 2016]. Dans le présent tutoriel, nous allons aborder de manière concise ce phénomène qu'on appelle Big Data. Nous commencerons par présenter ses définitions et caractéristiques dans la section 1, nous discuterons ses applications majeures dans la section 2 et puis nous nous attarderons sur les systèmes qui le supportent dans la Section 3.

II. Définitions▲

Le terme Big Data réfère à la croissance exponentielle des données, au traitement de ces dernières ou de manière plus générale à toutes les étapes entrant en jeu dans le processus d'extraction d'informations utiles à partir de l'énorme lot de données brutes [Tudoran, 2014]. En 2011, le McKinsey Global Report [Manyika et al., 2011] l'a défini comme étant des données dont l'échelle, diversité et distribution temporelle requièrent de nouvelles architectures techniques et des analyses plus poussées afin d'extraire des connaissances qui représentent une nouvelle source de valeur entrepreneuriale. Même si les définitions diffèrent, elles s'articulent autour de certaines caractéristiques que partagent les données. Il s'agit originellement des « 3V » du Big Data : Volume, Vélocité et Variété [Sakr, 2016] ensuite étendue pour couvrir la « Véracité » et la « Valeur » devenant ainsi les « 5V » du Big Data [Tudoran, 2014].

Le plus souvent, on parle des 4V du Big Data; l'aspect Valeur n'étant pas trop cité.

Nous présenterons dans ce qui suit ces caractéristiques plus en détail.

II-A. Volume▲

Chaque journée, plus de données sont produites que toutes celles contenues dans les supports imprimés à travers le monde [Tudoran, 2014]. Les études estiment que la taille des données digitales augmentera jusqu'à atteindre 35 zettaoctets alors qu'elle était à tout juste 0,5 zettaoctet en 2008 [Gantz and Reinsel, 2010] comme le montre la figure ci-dessous.

La croissance des données d'entreprise de 2008 à 2020

Le volume est la propriété la plus importante et la plus caractéristique du Big Data. En effet, de nos jours, tous les domaines qu'ils soient à aspect scientifique ou commercial produisent des centaines de téraoctets. Ce phénomène évolue d'autant plus facilement à cause du coût faible de stockage des données. De plus, plus la taille est élevée, plus les résultats de leur analyse sont précis, des résultats très importants pour extraire l'information utile et la transformer en connaissance pour la branche scientifique tout comme pour les branches commerciales [Tudoran, 2014].

Cette multitude de données représente le défi majeur à relever pour les systèmes supportant le Big Data. Ils devront ainsi être extensibles et assurer la scalabilité nécessaire afin de s'adapter au flot grandissant [Carey, 2013]. De même, du côté des traitements, le grand volume mettant en échec la puissance de calcul actuelle exige un traitement divisé sur plusieurs sites qu'ils soient distants, géographiquement parlant, ou non. La répartition géographique est de fait nécessaire lorsque les sources elles-mêmes sont réparties comme c'est le cas pour l'expérience scientifique CERN LHC Atlas qui produit 40 pétaoctets de données par année distribuées dans différents centres de stockage à travers la planète [Tudoran, 2014].

II-B. Vélocité▲

Cette propriété tient pour la grande allure à laquelle les données sont générées, recueillies et ingérées ou analysées [Han et al., 2014][Sakr, 2016]. Cette vitesse impose de nombreux problèmes lorsque ces données doivent être prétraitées (formatage, filtrage, épuration…) ou lorsqu'elles doivent être analysées en temps réel. On réfère à ce phénomène par « Flux de données », un autre aspect tout aussi problématique du Big Data. Jadis, réservé à certains secteurs de l'industrie, il touche aujourd'hui de nombreux domaines : réseaux de capteurs sans fil, flux des publications dans les réseaux sociaux, données des observatoires scientifiques, suivi des clics utilisateurs dans un large service web… Il est même attendu que la majeure partie des données composant le « Big Data » soit collectée en temps réel. Autrement dit, la vitesse à laquelle elles seront collectées surpassera la vitesse avec laquelle on peut les produire artificiellement [Tudoran, 2014].

II-C. Variété▲

Les données composant le Big Data proviennent de différentes sources et se présentent ainsi sous différents formats [Tudoran, 2014]. Elles sont dites hétérogènes. En effet, elles peuvent être structurées (format CSV, relationnel, tables Excel…) ou non (textes, images, vidéos…) selon qu'elles obéissent à un schéma unifié. Elles peuvent également être semi-structurées, autrement dit à mi-route entre les deux (format flexible pouvant être interprété : XML) [Sakr, 2016][Han et al., 2014]. Dans les rares cas où c'est possible de transformer des données non structurées afin d'extraire un schéma relationnel, les SGBDR (SGBD Relationnels) actuels ne pourraient pas supporter le grand volume. La solution est de stocker ces données de manière non ou semi-structurée et de laisser l'extraction du contexte ou d'un schéma descripteur si nécessaire à une partie de l'analyse. Cette extraction peut constituer dans certains cas une analyse à part entière. Il est à noter qu'enregistrer les données de manière non structurée améliore les performances et encourage l'extensibilité au détriment d'une perte d'informations pouvant être très utiles dans l'extraction de connaissances. En effet, la structuration même des données, par exemple à travers un modèle Entité/Association, peut apporter des informations significatives telles que les objets considérés dans l'ensemble de données et leurs associations, informations perdues si on se repose sur un modèle non structuré.

Ainsi, construire des systèmes pouvant cohabiter les différents types de données est primordial pour tirer pleine puissance du Big Data [Tudoran, 2014]. D'un autre côté, la variété peut aussi référer à la vaste panoplie de ces mêmes systèmes. Que ce soit en matière d'infrastructures matérielles, plateformes de traitement ou langages et paradigmes de programmation, il est très difficile d'effectuer le meilleur choix en respectant les budgets et les préférences ou compétences des utilisateurs [Abadi et al., 2016].

II-D. Véracité▲

Compte tenu des différentes formes que peut prendre le Big Data, de l'instabilité de ses manifestations et de son évolution continue, la correction, précision et qualité des données deviennent douteuses ce qui altère leur valeur. Ceci s'applique autant sur les données collectées que sur les résultats de leur analyse. En effet, les sources et les formes sont hétérogènes parfois, indignes de confiance : capteurs défectueux, erreurs d'orthographe dans une publication Facebook, fraude ou comportement malicieux… Autant de facteurs qui résultent en de fausses données se mêlant de manière indiscernable aux données correctes. Compte tenu de la proportion faible des données erronées, augmenter le volume pourrait augmenter la taille de la proportion correcte et assurer la justesse de l'analyse non sans impacter les performances et augmenter encore plus le temps de calcul. Les systèmes de traitement doivent offrir la possibilité de paramétrer l'analyse de sorte à assurer une certaine qualité des résultats au détriment du temps de traitement [Tudoran, 2014].

II-E. Valeur▲

Si ce n'était la valeur qu'apportent les données, on ne parlerait sûrement pas de Big Data. En effet, ce phénomène présente un nombre important de défis et problématiques dont une grande partie n'a pas encore été résolue. Le travail de recherche, la conception, réalisation et maintenance des systèmes supportant la croissance exponentielle des données présentent des coûts énormes qu'il faudra rentabiliser. La valeur des données représente ce qu'elles peuvent apporter comme gain, à la fois à la communauté scientifique à travers le quatrième paradigme de la science qui est la science des données (l'extraction de connaissances scientifiques sur les phénomènes du monde physique) mais aussi aux secteurs de l'industrie et de l'entreprise de manière générale à travers l'étude effective des marchés. D'un autre côté, comme la valeur change selon les ensembles de données ou l'importance de l'application et que des performances élevées engendrent des coûts dans la même mesure, les systèmes de traitement Big Data doivent offrir différents niveaux de performances selon la valeur qu'on accorde à l'ensemble traité [Tudoran, 2014].

Maintenant que nous avons exploré le concept du Big Data à travers ses cinq principales propriétés, nous allons parler plus en détail de la valeur qu'il peut apporter à travers ses applications et le processus de traitement qu'elles adoptent.

III. Processus de traitement des applications Big Data▲

Comme indiqué dans la section précédente, les applications du Big Data couvrent de nombreux domaines, dont le secteur scientifique, le secteur commercial et l'Internet. Des exemples sur le premier incluent des projets tels que le Sloan Digital Sky Survey (SDSS) ou le grand collisionneur de Hadrons (LHC ou Large Hadron Collider) qui génèrent un lot prodigieux de données devant être analysées [Baru et al., 2012]. Dans le secteur commercial, les données Big Data sont traitées afin d'extraire une valeur offrant des opportunités d'innovation et de compétitivité comme stipulé dans le McKinsey Global Report [Manyika et al., 2011]. Cette valeur est réalisée en améliorant les processus de prise de décision, en étudiant de manière précise la satisfaction des clients et la performance des produits ou encore en personnalisant plus que jamais les produits et services. Enfin dans l'Internet, les géants du Web tels que les réseaux sociaux font face à un lot énorme de données qu'ils doivent stocker, organiser et transférer. Ces données peuvent également servir à l'analyse afin de recueillir les préférences utilisateur et rendre les publicités plus ciblées. En effet, le secteur commercial s'incruste également dans l'Internet à travers le e-commerce et les sites de vente en ligne tels que e-Bay et Amazon qui doivent gérer des millions de transactions et pister les clics des utilisateurs afin de leur offrir les meilleurs produits [Baru et al., 2012]. D'autres domaines incluent l'Internet des objets, la domotique et le secteur de la santé [Sakr, 2016][Carey, 2013].

Les applications Big Data appliquent un processus de traitement sur les données passant par différentes phases présentées de manière abstraite dans la figure ci-dessous. Nous allons décrire succinctement chacune de ces étapes dans ce qui suit [Alexandros Labrinidis and H. V. Jagadish, 2012].

Les différentes phases d'analyse des données [Alexandros Labrinidis and H. V. Jagadish, 2012]

Acquisition/Enregistrement : correspond à la procédure d'acquisition des données Big Data à l'instar de la capture de la température ou l'estimation du taux de pollution dans l'air à travers les objets connectés. Compte tenu du gros volume des données recueillies, cette phase devra éliminer certaines données inutiles grâce à des filtrages et des compressions. Seulement, elle devra faire attention à ce que des informations significatives ne soient pas écartées telles que les données aberrantes qui puissent refléter des pannes ou des fraudes. Ce stage devra également assurer la génération des métadonnées sur la structure et la provenance des données, mais également sur les détails de l'opération de capture. Les métadonnées auront une importance capitale pour la suite des phases, plus particulièrement, l'analyse des données.
Extraction/Nettoyage/Annotation : souvent, les données capturées se trouvent dans un format inadapté à l'analyse. Cette phase s'occupe de corriger leur structure et d'extraire l'information significative, mais également d'éliminer les données potentiellement erronées. En effet, le critère de véracité du Big Data stipule que les données sont parfois indignes de confiance et doivent être épurées avant l'analyse.
Intégration/Agrégation/Représentation : les analyses à grande échelle font appel à des ensembles de données différents en structure et en taille. Un défi important correspond à trouver la représentation la plus adéquate pour les stocker et à intégrer ces ensembles entre eux de façon à conduire une analyse globale.
Analyse/Modélisation : il s'agit de l'analyse des données afin de déceler des modèles intrinsèques, d'extraire des relations et des connaissances, mais aussi de corriger les erreurs et d'éliminer les ambiguïtés.
Interprétation : les décideurs doivent interpréter les résultats d'une analyse Big Data. Cette interprétation est obligatoire, car les données et par conséquent l'analyse elle-même ne sont pas exemptes d'erreurs. De plus, la plupart des modèles et théorèmes appliqués se basent sur des hypothèses qui ne sont pas toujours vérifiables. Les décideurs devront valider les résultats en retraçant les opérations effectuées. Des outils doivent être mis en place afin de faciliter ce processus. Ils doivent offrir des visualisations interactives des données, permettre de retracer leur provenance et d'appliquer des modifications dessus puis voir l'impact sur les résultats en temps réel.

Transversalement à ces phases ou stages, un ensemble de défis accompagne leur application. Il s'agit de l'hétérogénéité et du gros volume de données qui ralentissent et complexifient les calculs, de la nécessité de prendre en compte leur opportunité vu que certaines données perdent leur pertinence si elles ne sont pas traitées rapidement, de la confidentialité qui est un souci majeur aujourd'hui pour beaucoup de personnes (dossier médical, informations personnelles…) [Abadi et al., 2016] et enfin de la nécessité d'inclure les capacités d'analyse d'un humain dans le processus. Ce dernier point peut être accompli en autorisant un humain à ingérer des informations dans le système tel qu'un modèle qu'il a reconnu ou son propre avis sur un diagnostic [Alexandros Labrinidis and H. V. Jagadish, 2012].

Afin de concrétiser les applications Big Data, les systèmes conçus interviennent dans les différentes phases de ce processus. Dans la section suivante, nous présenterons ces systèmes ainsi que leurs catégorisation et propriétés.

IV. Systèmes Big Data▲

L'apparition du phénomène des mégadonnées amène bon nombre de défis et met à rude épreuve les systèmes conventionnels dédiés au stockage et au traitement des données. Ces solutions, principalement les SGBD relationnels, qui ont longtemps été le couteau suisse de l'industrie, ont essayé de s'adapter au lot grandissant des données en adoptant des configurations distribuées [Carey, 2013]. Parmi ces nouvelles approches, nous retrouvons Teradata, SQL Server PDW, Vertica, Greenplum, ParAccel et Netezza1. Seulement, elles sont difficiles à gérer, coûteuses, souvent incompatibles avec les données semi ou non structurées et n'assurent pas la tolérance aux pannes pour les requêtes à longue durée [Sakr, 2016]. D'un autre côté, leur conformité avec la règle ACID (Atomicité, Cohérence, Isolation, Durabilité) devient un handicap puisqu'elle inclut des traitements additionnels pour la maintenir.

ACID : A : les modifications qu'applique une transaction s'exécutent de manière atomique, soit elles sont toutes exécutées soit aucune n'est exécutée ; C : la transaction conduit la base d'un état cohérent à un autre état cohérent ; I : si plusieurs transactions sont exécutées en parallèle, chacune aura l'impression qu'elle est la seule en cours d'exécution ; D : si l'exécution d'une transaction réussit, alors les changements qu'elle a apportés à l'état de la base survivront aux pannes [Gray and Reuter, 1992].

Surtout que de nombreuses applications Big Data ne suivent pas un modèle transactionnel [Zarate Santovena, 2013]. Lorsque la cohérence des données est primordiale, le lot énorme de données et la vélocité à laquelle elles sont ingérées dans le système garantissent une mise à jour continue qui élimine les incohérences au fur et à mesure.

Par ailleurs, l'application duale des SGBD relationnels dans le stockage des données pour des fins opérationnelles, mais aussi dans l'analyse décisionnelle se retrouve retranscrite dans les systèmes Big Data. Ainsi, on retrouve des systèmes dédiés au stockage et à la récupération rapide des mégadonnées qui naquirent du besoin des géants du Web à rechercher des attributs spécifiques sur leurs utilisateurs (opérations dites Cloud OLTP pour Cloud Online Transaction Processing) et d'autres systèmes orientés analyse et extraction de la connaissance. Ces derniers sont tout aussi utilisés par les acteurs de l'industrie pour les planifications stratégiques et l'analyse des marchés que par les communautés scientifiques [Carey, 2013]. Avant de parler plus en détail de ces deux types de systèmes, nous présentons leurs propriétés les plus importantes.

IV-A. Propriétés▲

IV-A-1. Scalabilité▲

Dans leur tentative d'aborder le Big Data, les nouvelles technologies s'efforcent à satisfaire une propriété primordiale qui est la scalabilité. On entend par cela la capacité d'un système à améliorer ses performances en augmentant la taille ou le nombre de ses ressources lorsqu'il fait face à une charge plus grande. En pratique, on retrouve deux approches dites scalabilité verticale et son analogue horizontale. La première est réalisée en augmentant la taille du système et la puissance de ses composants (RAM, CPU…). Par contre, la scalabilité horizontale se manifeste sous la forme d'un Cluster [Sakr, 2016]. Il s'agit d'un système distribué composé de plusieurs machines de capacité modérée appelées nœuds. Ces machines ou nœuds communiquent dans le but de réaliser certaines opérations et manipuleront chacune une partie de la charge imposée au système adoptant ainsi la politique « diviser pour régner ». Ladite charge peut représenter une problématique de stockage d'une grande masse de données ou leur traitement. La figure ci-dessous résume le concept.

La scalabilité horizontale et la scabilité verticale [Sakr, 2016]

Il est important de noter que la scalabilité verticale rencontre des limites d'applicabilité. À partir d'un certain point, il n'est plus possible d'augmenter la puissance d'un système résidant sur une seule machine indépendamment de la disponibilité des ressources et de la taille du budget. Comme la scalabilité est nécessaire à n'importe quel système Big Data vu le volume et la vélocité imprédictibles des données, l'approche horizontale est le plus souvent adoptée [Sakr, 2016]. De plus, puisque les machines ne sont pas nécessairement très puissantes, les clusters pour systèmes Big Data peuvent être loués en tant que ressource chez les fournisseurs cloud. Ceci a, entre autres, l'avantage de réduire les coûts et de faciliter les configurations, le déploiement et les opérations de maintenance [Tudoran, 2014].

IV-A-2. Théorème CAP▲

Même si les systèmes distribués, qu'ils soient ou non hébergés sur le cloud, semblent être la solution idéale pour gérer les applications Big Data, ils apportent un lot de contraintes énoncées dans le théorème CAP (Consistency, Availability, Partition tolrance) [Gilbert and Lynch, 2002]. Celui-ci déclare qu'il est impossible pour un système distribué de garantir les trois propriétés suivantes simultanément [Gilbert and Lynch, 2012].

Consistance (Consistency) : le système retourne la bonne réponse à chaque requête. À comprendre, une réponse sans incohérence ni erreurs. La définition exacte de la correction de la réponse dépend du service rempli par le système.
Disponibilité (Availability) : le système est tout le temps disponible et répond à tout moment à ses utilisateurs. En d'autres mots, toutes les opérations sont exécutées avec succès au bout d'un temps fini.
Tolérance aux partitions réseau (Partition tolerance) : dans ce genre de systèmes avec des machines à puissance moyenne, les pannes réseau sont inévitables. Lorsqu'elles occurrent, elles créent des partitions de telle sorte que les machines à l'intérieur d'une même partition peuvent communiquer entre elles, mais sont isolées des autres. Cette propriété stipule que l'existence d'un tel partitionnement ne doit pas empêcher ou altérer le bon fonctionnement du système.

L'énonciation de ce théorème a obligé les concepteurs à faire un choix entre ces trois propriétés. Toutefois comme les défaillances de communication sont inévitables dans un cluster de plusieurs machines, la tolérance aux partitions devient primordiale et doit être obligatoirement assurée [Wang et al., 2014a]. Pour le reste, les systèmes choisissent soit d'assurer une disponibilité élevée au profit de lacunes dans la cohérence des données ou bien d'assurer la consistance au détriment de la disponibilité.

Comme indiqué précédemment, les systèmes Big Data se divisent en deux catégories selon qu'ils interviennent dans les premières étapes du processus de traitement, à comprendre représentation et stockage des données, ou alors dans leur analyse. Afin d'accomplir leurs fonctions, ils adoptent un ensemble de modèles soit pour le stockage ou pour le traitement.

IV-B. Modèles de stockage▲

L'une des principales missions d'un système gérant le Big Data est le stockage de la multitude de données. Trois catégories de solutions de stockage, chacune adoptant un modèle particulier, existent [Tudoran, 2014].

IV-B-1. Systèmes à base d'objets▲

Ce genre de systèmes stockent les données dans des champs BLOB (Binary Large OBject) de sorte qu'ils n'offrent aucun moyen de les structurer.

[BLOB] : Les SGBDR traditionnels étaient conçus pour stocker de simples données dont la taille ne dépasse pas 255 octets. Les applications actuelles traitent des objets qui dépassent largement cette taille dits Large OBjects (images, vidéos…). Lorsqu'ils sont représentés sous forme d'octets bruts, ils sont appelés BLOB [Shapiro and Miller, 1999].

Ils supposent ainsi que les données sont fréquemment lues, mais rarement mises à jour. Ils garantissent leur durabilité et une grande disponibilité sans fournir d'aspects structurels qui pourraient servir aux requêtes complexes. Ces solutions sont donc inadéquates pour des opérations d'analyse ou d'extraction des connaissances. De fait, les traitements sont entièrement indépendants du stockage et se font à part. Parmi les fournisseurs cloud qui proposent ce genre de systèmes, on retrouve Google Cloud Storage, Azure BLOBS, Amazon S3… [Tudoran, 2014].

IV-B-2. Systèmes de fichiers distribués▲

En vue de rapprocher les données du traitement, ces systèmes utilisent un stockage distribué au-dessus des nœuds d'un système de fichiers tout en tenant compte du paradigme de traitement utilisé. Ils s'installent ainsi au-dessous d'un système de traitement [Tudoran, 2014]. Des exemples incluent :

Apache HDFS (Hadoop Distributed File System) : c'est le système de stockage par excellence pour les plateformes MapReduce. Son architecture générale consiste en un nœud central de contrôle appelé NameNode et plusieurs autres nœuds qui stockent les données appelés DataNodes comme décrit dans la figure ci-dessous. Le rôle du NameNode est de détenir les métadonnées et de partager et fragmenter les données sur les nœuds de stockage qui les sauvegardent au format de chunk (un chunk équivaut à 64 MB par défaut). Afin de garantir la tolérance aux pannes, chaque chunk est répliqué sur plusieurs autres DataNodes (par défaut 3). Il faut savoir que ce système est fortement optimisé pour travailler en étroite collaboration avec les plateformes de traitement MapReduce, mais rencontre quelques limites comme le faible débit en lectures concurrentes et l'impossibilité d'exécuter des écritures concurrentes [Tudoran, 2014].

Architecture du système HDFS [Tudoran, 2014]

BSFS (BlobSeerted File System) : est un système de fichiers distribué optimisé pour les opérations concurrentes. Il reprend une structure de cluster et gère la fragmentation et la réplication des données de manière transparente pour les applications. Sa gestion des métadonnées sous forme de versions permet d'avoir plusieurs opérations concurrentes sur les mêmes données. Autrement dit, plusieurs versions d'une même donnée peuvent exister en même temps de sorte que la version finale sera reconstruite par des composants spécialisés lorsque la donnée est requise. Le système offre un haut débit, mais requiert une configuration méticuleuse qui n'est pas toujours facile à maitriser [Tudoran, 2014] ;
GFarm : il s'agit d'un système de fichiers distribué conçu pour supporter le stockage et le partage des données dans les plateformes de traitement sous forme de grilles [Tudoran, 2014].

Les grilles sont des infrastructures matérielles et logicielles fiables, pervasives et peu coûteuses qui donnent accès à des capacités computationnelles hautement performantes. Elles gèrent notamment des ressources qui ne sont pas sujettes à un contrôle centralisé et adoptent des protocoles standards et ouverts [Foster, 2002].

IV-B-3. Systèmes basés sur des modèles NoSQL▲

On assiste aujourd'hui à une explosion des données générées par les utilisateurs accentuée par la pervasivité de l'Internet et du Web 2.0. Ce déluge de données s'est accompagné d'une diversité de formats allant parfois à l'absence de structures ce qui a rendu inutilisables les méthodes traditionnelles de stockage nécessitant un schéma unifié comme les SGBDR. Afin de faire face aux nouveaux défis, surtout dans le monde du Web où la disponibilité et l'extensibilité des systèmes sont primordiales, une nouvelle classe de modèles et de SGBD les adoptant, dite NoSQL (Not Only SQL), a émergé. Elle garantit les propriétés de scalabilité en s'affranchissant de la règle ACID qui a longtemps gouverné les systèmes conventionnels [Sakr, 2016][Zarate Santovena, 2013].

Cette nouvelle génération de systèmes est divisée en quatre catégories de bases de données [Sakr, 2016].

Clé-valeur : il s'agit d'un modèle de données simple où des données opaques sont associées à une clé formant un objet identifié de manière unique par cette dernière. Le modèle est très semblable aux tables de hachage qu'on retrouve dans les langages de programmation. Parmi les SGBD clé-valeur open source, on retrouve : Memcached, Redis, Riak et Voldemort [Sakr, 2016].
Exemple : supposons qu'on veuille stocker un utilisateur d'un réseau social défini de manière unique par un identifiant (96), un nom d'utilisateur (johndoe), un mot de passe (sesam) et une adresse représentée par le nom d'une rue (Baker), une ville (London) et enfin un pays (England). Le concept d'un SGBD clé-valeur est d'associer une donnée à une clé (la clé est le plus souvent une chaine de caractères). La représentation la plus naturelle serait un ensemble d'objets sous forme de paires : [username96: johndoe], [password96: sesam], [road96: Baker], [city96: London], [country96: England]. L'ajout de l'identifiant dans la construction de la clé permet d'associer la bonne adresse au bon utilisateur au cas où il en existe plusieurs.
Même si ces associations sont praticables, elles sont illisibles et difficilement interprétables. Que se passe-t-il si l'on veut connaitre le nombre d'utilisateurs dans la base ? Afin de pallier ce problème, les SGBD actuels adoptant ce modèle offrent d'autres types de valeurs telles que les tables de hachage. Une table de hachage est un objet composé qui contient plusieurs paires clé/valeur. Ainsi, un utilisateur peut être représenté par une « valeur », table de hachage, liée à une clé sous la forme de son identifiant. Le résultat serait : [96 : {[username: johndoe], [password: sesam], [road: Baker], [city: London], [country: England]}]. Une autre décomposition réunirait toutes les clés : road, city et country dans une table de hachage identifiée par address. L'avantage avec une telle représentation est qu'un utilisateur peut ne pas comporter une clé : road s'il ne spécifie pas le nom d'une route dans son adresse. Dans la même optique, on peut rajouter une clé : firstname, si l'utilisateur renseigne son prénom. Il s'agit là de toute la puissance en termes de flexibilité d'un modèle NoSQL.
Orientées colonnes : contrairement aux bases orientées lignes comme les SGBDR, cette catégorie stocke les données sous forme de tables où les éléments composant une même colonne sont localisés ensemble de manière adjacente. Ceci permet de réorganiser ou d'ajouter des colonnes dans une table de manière flexible, d'effectuer des recherches rapidement sur une seule colonne et d'avoir un nombre différent d'attributs sur chaque ligne, ce qui assure une adaptation au manque de structuration des données Big Data. Finalement, les tables se retrouvent avec des lignes de différentes largeurs. Les solutions les plus populaires dans cette catégorie sont Cassandra offerte par Facebook et l'open source Apache HBase [Sakr, 2016][Tudoran, 2014].
Exemple : si nous reprenons notre utilisateur johndoe, nous créerons une table Utilisateurs tout comme nous l'aurions fait dans le modèle relationnel. Cette table comportera un certain nombre de familles de colonnes. Leur nombre et leur définition ne changeront pas et seront partagés par toutes les lignes de la table. Par contre, nous pourrons définir à l'intérieur d'une même famille n'importe quel nombre de colonnes et personnaliserons ces dernières selon chaque ligne. Ainsi, notre table Utilisateurs comportera les familles suivantes : identifiant (clé primaire), username, password, address. Pour la ligne identifiée par 96, nous définirons les colonnes road, city, country dans la famille address. Pour rejoindre l'idée précédemment énoncée, nous aurions pu définir une famille persoinfo qui abritera des colonnes spécifiant les informations personnelles des utilisateurs telles que le prénom.
Orientées documents : dans cette catégorie, des objets dits « documents » stockent les données sous forme d'attributs où chaque attribut peut être un autre document offrant ainsi une structure récursive. MongoDB et CouchDB sont des exemples de systèmes qui implémentent ce modèle [Sakr, 2016].
Exemple : l'utilisateur johndoe tout comme n'importe quel utilisateur du réseau social peut être représenté par un document. Un document est un ensemble de couples clé/valeur où la clé est dite attribut. Une collection nommée Utilisateurs abritera tous les documents représentant les utilisateurs. Il est à savoir que l'appartenance d'un document à une collection ne définit en aucun cas sa structure. Des documents appartenant à une même collection peuvent contenir des attributs complètement différents même si, le plus souvent, ils adoptent une organisation similaire. La figure ci-dessous offre un aperçu de la structure du document associé à l'utilisateur johndoe. Nous remarquons que l'adresse de l'utilisateur est en fait un document imbriqué contenant d'autres attributs tels que la rue ou la cité. Un document associé à un autre utilisateur pourrait abriter en plus un attribut firstname pour spécifier le prénom. Par ailleurs, les documents sont identifiés de manière unique à l'intérieur d'une même collection par un attribut spécial (il s'agit de _id dans MongoDB).

Orientées graphes : offrent un modèle basé sur des graphes avec des nœuds, arêtes et leurs propriétés respectives. Cette catégorie excelle dans la manipulation des données présentant un haut niveau d'interdépendance et permet de traverser rapidement des données complexes en parcourant les relations entre les nœuds. Neo4J est la base orientée graphe la plus populaire en ce moment [Sakr, 2016].

La solution NoSQL assure une scalabilité massive atteignant l'échelle des pétaoctets [Tudoran, 2014] et une haute disponibilité au détriment d'une perte en consistance comme le stipule le théorème CAP. Ces caractéristiques font d'elle le candidat idéal pour gérer les services Web dans les réseaux sociaux ou les sites de e-commerce qui regroupent des millions d'utilisateurs effectuant des opérations à tout moment [Wang et al., 2014a].

IV-C. Modèles de traitement▲

Face à l'énormité des données, les méthodes traditionnelles de traitement s'avèrent inefficaces. De nouveaux paradigmes ont été mis en place qui s'attaquent au volume du Big Data en parallélisant les traitements sur des parties des données. Ces techniques assurent l'adaptation à la taille des données en étendant le nombre de processus afin d'assurer la propriété de scalabilité. De plus, ils considèrent des processus tournant sur des machines de puissance modérée en vue d'un déploiement sur le cloud. Les deux paradigmes principaux en effet actuellement sont MapReduce et la méthode par Workflows (ou flux de travail). Les systèmes traitant du Big Data sont classifiés selon qu'ils adoptent l'un ou l'autre de ces paradigmes [Tudoran, 2014].

IV-C-1. Modèle MapReduce▲

Proposé par Google en 2004 [Dean and Ghemawat, 2008], ce paradigme est composé de deux fonctions principales exécutées de manière séquentielle : Map et Reduce. Les données en entrée sont partitionnées, ensuite la fonction Map est appliquée en parallèle à chacune des partitions. Un exemple de fonction Map peut être de compter les occurrences des mots dans chaque partition ou alors de chercher un patron. Ses résultats sont appelés résultats intermédiaires et sont assignés à des processus exécutant la fonction Reduce dits Reducer. Ainsi, chacun de ces processus reçoit en entrée un ou plusieurs résultats intermédiaires et exécute un ensemble d'opérations, typiquement, un tri ou une fusion, et produit un résultat. Les résultats de toute la procédure sont ceux délivrés par les processus Reducer [Tudoran, 2014]. La figure ci-dessous résume le fonctionnement du paradigme.

Le fonctionnement classique de MapReduce illustré par un exemple (compteur de lettres) [Chen and Schlosser, 2008]

Cette technique s'adapte particulièrement au contexte Big Data, car elle assure la scalabilité et l'adaptation aux ressources disponibles. Il suffit de partitionner l'ensemble de données en entrée selon le nombre de processus mis à disposition de l'utilisateur qui s'assurera de personnaliser les fonctions Map et Reduce selon ses besoins [Tudoran, 2014]. De plus, elle rapproche les traitements des données et isole l'application des détails de gestion d'un système distribué tels que la tolérance aux pannes, partitionnement des données et planification des tâches [Sakr, 2016]. Ceci fait que MapReduce est le paradigme le plus adopté pour affronter les applications Big Data. L'implémentation la plus populaire et la plus utilisée de ce paradigme est la plateforme open source Apache Hadoop mise au point par Yahoo, Facebook et d'autres acteurs du Web [Carey, 2013]. Elle utilise le système de stockage HDFS et adopte une architecture contenant un nœud central et des nœuds de traitement dits worker. La plateforme garantit un haut niveau de tolérance aux pannes et apporte beaucoup d'optimisations afin de planifier les traitements selon la localité des données [Tudoran, 2014]. De fait, elle a été un tel succès que le terme « Hadoop » a dominé de 2008 à 2012 le terme « Big Data » dans les recherches Google comme le montre la figure ci-dessous selon l'outil Google Trend Analysis [Sakr, 2016].

Les tendances de recherche pour les deux termes : Big Data et Hadoop [Sakr, 2016]

La simplicité du paradigme et son utilisation native d'un cluster de machines de commodité ont facilité son adoption comme service cloud. On retrouve donc des solutions comme AzureMapReduce, HDInsight de Microsoft, Elastic MapReduce Service de Amazon, etc [Tudoran, 2014]. La notoriété de Hadoop boostée par l'adoption d'un modèle de cloud computing a permis de vulgariser les analyses et traitements sur données Big Data et protège les clients de la complexité et du coût nécessaires pour maintenir de tels systèmes [Sakr, 2016].

L'adoption globale de MapReduce comme paradigme pour le traitement des données Big Data a motivé son amélioration par l'introduction d'extensions permettant de traiter une plus grande classe d'applications. Plusieurs systèmes ont été ainsi proposés pour introduire un aspect itératif jusqu'alors non supporté. Parmi les solutions, nous citons HaLoop construit au-dessus de Hadoop, Twister, une solution qui a été intégrée à AzureMapReduce et notamment iMapReduce. Il est à noter que l'introduction d'une structure de boucle rend le système moins tolérant aux pannes et requiert des nœuds de puissance plus élevée et une configuration plus complexe [Tudoran, 2014].

Par ailleurs, même si la plateforme Hadoop semble être la réponse à tous les cas d'analyse Big Data, elle rencontre des limitations qui appellent à développer de nouveaux systèmes optimisés et spécialisés dans leurs domaines d'applications respectifs [Sakr, 2016]. La figure ci-dessous montre le développement de ces nouvelles solutions appelées Systèmes Big Data 2.0. Ces derniers peuvent être classifiés en plusieurs catégories.

Developpement des systèmes de traitement Big Data. (Les drapeaux refèrent aux systèmes à usage général, les rectangles aux Big SQL, les étoiles aux Big Graph et enfin les losanges aux Big Stream.) [Sakr, 2016]

Systèmes à usage général : utilisés lorsque la charge de travail est inconnue ou trop diversifiée. Par exemple, lorsque l'application implique l'utilisation de données structurées issues d'activités opérationnelles d'entreprise, mais aussi de données semi et non structurées issues de l'activité de la même entreprise sur le Web telles que l'historique des clics utilisateurs, des logs applicatifs… Ils sont également prisés lorsque les traitements incluent à la fois de l'analyse de texte, de l'apprentissage automatique, des statistiques et de l'analyse des séries chronologiques [Sakr, 2016].
Systèmes Big SQL : Hadoop est inadapté aux requêtes interactives visant un temps de réponse qui ne dépasse pas une poignée de secondes. De plus, les développeurs ne sont pas familiers avec le paradigme MapReduce et préfèrent utiliser un langage déclaratif de plus haut niveau comme SQL pour spécifier leurs requêtes. Les systèmes Big SQL s'installent au-dessus d'une plateforme Hadoop et répondent à ce besoin en gérant l'optimisation et les détails de l'exécution des requêtes de manière transparente [Sakr, 2016]. Il est également intéressant de noter que le même besoin s'applique aux bases de données NoSQL et que des solutions existent permettant de les requêter à l'aide d'un langage déclaratif non trop différent de SQL [Carey, 2013]. La figure ci-dessous décrit la pile logicielle basée sur Hadoop pour systèmes Big Data.

Pile logicielle basée sur Hadoop pour systèmes Big Data [Carey, 2013]

Systèmes Big Graph : le modèle de données en graphe devient de plus en plus commun avec la popularité des réseaux sociaux et la structure même du Web 2.0 basée sur les hyperliens. Sachant que le parcours et l'exploration des graphes requièrent le plus souvent des structures itératives, de nouveaux systèmes optimisés pour de telles applications sont nécessaires [Sakr, 2016].
Systèmes Big Stream : ce genre de systèmes fait face à l'aspect vélocité des données Big Data et traitent les flux continus arrivant depuis les technologies ubiquitaires telles que les capteurs, systèmes de localisation et les équipements mobiles. Il a également pour but d'assurer le transfert des données entre les différents composants des systèmes Big Data lors de traitements complexes [Sakr, 2016].

IV-C-2. Modèle des Workflows▲

MapReduce a été largement apprécié pour sa simplicité, mais cette propriété peut être limitante pour certaines applications scientifiques où l'on a besoin d'exprimer plus précisément les interdépendances entre les tâches et le flot de données. Les Workflows ou flux de travail présentent une manière abstraite de schématiser l'évolution des données et des opérations. Cependant, ils sont difficiles à implémenter dans un contexte à large échelle. En effet, décrire des interdépendances aussi complexes entre plusieurs nœuds de traitement répartis peut rapidement devenir ingérable. Parmi les systèmes qui ont adopté ce paradigme, on retrouve Pegasus, e-science Central, Generic Worker [Tudoran, 2014].

Afin d'en apprendre plus sur le modèle, nous prendrons comme exemple le système Pegasus. Ce dernier permet de spécifier dans un premier temps des workflows dits abstraits sous forme de graphes. Les nœuds représentent les tâches à exécuter et les arcs définissent leurs ordonnancements. Chaque tâche doit être accompagnée de ses entrées/sorties et arguments d'exécution. Par ailleurs, le graphe peut être défini de manière hiérarchique de sorte qu'une tâche puisse représenter un autre workflow abstrait. Ces premiers workflows sont indépendants des ressources. Ils sont transformés en workflows exécutables dans un second temps en indiquant au système des informations sur l'environnement d'exécution telles que le système de stockage, les ressources de traitement disponibles et leurs ordonnanceurs ou encore la localisation des données et des exécutables. Pegasus s'occupera ensuite de l'invocation des ressources, des transferts de données et de l'optimisation du graphe initial et finira par produire un graphe exécutable. Ce dernier contiendra, en plus des tâches exécutables, des nœuds relatifs à la gestion des données (nœuds de rassemblement des données en entrées, nœuds de rassemblement de données en sortie, nœuds de catalogage…) [Deelman et al., 2015]. La figure qui suit montre la transformation en workflow exécutable d'un workflow abstrait trivial composé de deux tâches successives.

Transformation d'un workflow abstrait composé de deux tâches successives en workflow exécutable dans Pegasus [Deelman et al., 2015]

À travers la multitude de systèmes que nous avons cités, il est facile de se rendre compte de la grande diversité des systèmes Big Data, une diversité qui participe à renforcer son aspect Variété. Cependant, les problématiques que ce nouveau phénomène apporte ne se limitent pas à ce qui semble être la préoccupation majeure des systèmes existants tels que la scalabilité et l'hétérogénéité des données, mais aussi leurs confidentialité, provenance, visualisation, opportunité et correction. D'autres aspects tels que l'utilisabilité des systèmes et leur permissivité à l'intervention humaine sont également à prendre en compte [Alexandros Labrinidis and H. V. Jagadish, 2012]. Afin de réaliser tous ces objectifs, des recherches plus poussées doivent être financées et davantage de spécialistes dans la science des données doivent être formés [Abadi et al., 2016].

V. Conclusion▲

Dans ce tutoriel, nous avons passé en revue les notions fondamentales autour du Big Data. Nous avons ainsi vu qu'il s'agissait d'une notion complexe, non complètement définie et qui évolue encore de la même façon que les systèmes qui la traitent. La tendance s'oriente aujourd'hui vers une spécialisation des solutions à travers les systèmes Big Data 2.0, mais il reste encore de nombreux problèmes à régler. Le Big Data se résume ainsi à une opportunité majeure pour réaliser à la fois de grandes découvertes scientifiques et de larges profits commerciaux, mais aussi à un ensemble de défis qu'il est important de maîtriser afin de tirer plein profit de la nouvelle ère des données.

VI. Remerciements▲

Cet article a été publié avec l'aimable autorisation de Mehdi Acheli. Le document original est issu d'un mémoire de Master pour l'obtention du diplôme de l'ESI - Ecole Nationale Supérieure d'Informatique en Algérie. Ce document a été rédigé pendant l'année de stage de Mehdi Acheli réalisé au sein du laboratoire LIAS de Poitiers / Futuroscope.

Nous tenons à remercier Claude Leloup pour la relecture orthographique attentive de cet article et Mickael Baron pour la mise au gabarit.

VII. Références▲

[Abadi et al., 2016] Abadi, D., Agrawal, R., Ailamaki, A., Balazinska, M., Bernstein, P. A., Carey, M. J., Chaudhuri, S., Dean, J., Doan, A., Franklin, M. J., Gehrke, J., Haas, L. M., Halevy, A. Y., Hellerstein, J. M., Ioannidis, Y. E., Jagadish, H. V., Kossmann, D., Madden, S., Mehrotra, S., Milo, T., Naughton, J. F., Ramakrishnan, R., Markl, V., Olston, C., Ooi, B. C., Re, C., Suciu, D., Stonebraker, M., Walter, T., and Widom, J. (2016). Beckman Report on Database. Communications of the ACM, 59(2):92-99.

[Alexandros Labrinidis and H. V. Jagadish, 2012] Alexandros Labrinidis and H. V. Jagadish (2012). Challenges and Opportunities with Big Data. Proceedings of the VLDB Endowment, pages 1-15.

[Carey, 2013] Carey, M. J. (2013). LNCS 7755 - BDMS Performance Evaluation: Practices, Pitfalls, and Possibilities. LNCS, 7755:108-123.

[Gantz and Reinsel, 2010] Gantz, J. and Reinsel, D. (2010). The Digital Universe Decade - Are You Ready? Technical Report May.

[Gilbert and Lynch, 2012] Gilbert, S. and Lynch, N. A. (2012). Perspectives on the cap theorem. Institute of Electrical and Electronics Engineers.

[Han et al., 2014] Han, R., Xiaoyi, L., and Jiangtao, X. (2014). On big data benchmarking. Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 8807:3-18.

[Manyika et al., 2011] Manyika, J., Chui, M., Brown, B., Bughin, J., Dobbs, R., Roxburgh, C., and Byers, A. H. (2011). Big data: The next frontier for innovation, competition, and productivity.

[Sakr, 2016] Sakr, S. (2016). Big Data 2.0 Processing Systems. SpringerBriefs in Computer Science. Springer International Publishing, Cham.

[Tudoran, 2014] Tudoran, R. (2014). High-Performance Big Data Management Across Cloud Data Centers. PhD thesis.

[Wang et al., 2014a] Wang, H., Li, J., Zhang, H., and Zhou, Y. (2014a). Benchmarking replication and consistency strategies in cloud serving databases: HBase and Cassandra. Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 8807:71-82.

[Zarate Santovena, 2013] Zarate Santovena, A. (2013). Big data : evolution, components, challenges and opportunities. Technical report.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants :

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2017 Mehdi Acheli. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.