Le traitement BigData - Hadi Hashem - E-Book

Le traitement BigData E-Book

Hadi Hashem

0,0

Beschreibung

Comment exploiter rentablement et efficacement les données dans un monde où tout va de plus en plus vite?

Dans le monde d’aujourd’hui de multiples acteurs de la technologie numérique produisent des quantités infinies de données. Capteurs, réseaux sociaux ou e-commerce, ils génèrent tous de l’information qui s’incrémente en temps réel selon les « 3 V » de Gartner : en Volume, en Vitesse et en Variabilité. Afin d’exploiter efficacement et durablement ces données, il est important de respecter la dynamicité de leur évolution chronologique à travers 2 approches : le polymorphisme d’une part, au moyen d’un modèle dynamique capable de supporter le changement de type à chaque instant sans failles de traitement ; d’autre part le support de la volatilité par un modèle intelligent prenant en compte des donnés-clés seulement interprétables à un instant « t », au lieu de traiter toute la volumétrie des données actuelle et historique.

Un guide indispensable pour un potentiel maximal d'exploitation des données.

À PROPOS DE L'AUTEUR

Hadi Hashem est un acteur engagé dans le monde du conseil logiciel et particulièrement le potentiel d’exploitation des données. Diplômé ingénieur en informatique, il a travaillé dans des entreprises des domaines d’énergie, de pharmaceutique vétérinaire et d’électroménager, en France et en Europe. Titulaire d’un doctorat dans le domaine du traitement BigData, il développe ses activités d'enseignement et de recherche dans les universités de France. Ses méthodes concrétisent un mariage entre les connaissances théoriques de la science des données et les besoins pratiques dans le quotidien des entreprises.

Sie lesen das E-Book in den Legimi-Apps auf:

Android
iOS
von Legimi
zertifizierten E-Readern
Kindle™-E-Readern
(für ausgewählte Pakete)

Seitenzahl: 382

Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:

Android
iOS
Bewertungen
0,0
0
0
0
0
0
Mehr Informationen
Mehr Informationen
Legimi prüft nicht, ob Rezensionen von Nutzern stammen, die den betreffenden Titel tatsächlich gekauft oder gelesen/gehört haben. Wir entfernen aber gefälschte Rezensionen.



Couverture

Page de titre

TABLE DES MATIÈRES

INTRODUCTION DE L’OUVRAGE
La problématique et le contexte du travail
Les objectifs de cet ouvrage
Le plan de développement
PARTIE 1. ÉTAT DE L’ART
CHAPITRE 1. LE TRAITEMENT DES DONNÉES BIGDATA
1.1 Introduction au chapitre
1.2 Les bases de données NoSQL
1.2.1 Le mouvement NoSQL et l’élaboration du terme
1.2.2 La définition NoSQL et les avantages pour les développeurs
1.2.3 Les caractéristiques des bases de données NoSQL
1.2.4 Les limitations des bases de données NoSQL
1.2.5 Conclusion
1.3 NewSQL en route vers la base de données moderne
1.3.1 L’architecture NewSQL
1.3.2 Les avantages de la solution NewSQL
1.3.3 Les limitations des bases de données NewSQL
1.3.4 Conclusion
1.4 L’efficacité des moteurs de traitement existants
1.4.1 MapReduce
1.4.2 Apache Hadoop
1.4.3 Les bases de données non-relationnelles
1.4.4 BigTable et HBase
1.4.5 GFS et HDFS
1.4.6 Conclusion
1.5 Les modèles de données non-relationnels
1.5.1 Le stockage clé-valeur
1.5.2 La base de données BigTable
1.5.3 Le modèle de données orienté document
1.5.4 Le modèle de données orienté graphe
1.5.5 La base de données multi-modèle
1.5.6 Conclusion
1.6 Le modèle orienté graphe comparé au model relationnel
1.6.1 Rappel des bases fondamentales
1.6.2 Les critères d’évaluation des modèles
1.6.3 Conclusion
1.7 L’activité principale des systèmes distribués
1.7.1 La consistance des données
1.7.2 La création des données
1.7.3 La coordination des systèmes
1.7.4 La capacité à répartir la charge
1.7.5 La tolérance aux pannes
1.7.6 La haute disponibilité
1.7.7 Les difficultés de mise en œuvre
1.7.8 Conclusion
1.8 Conclusion du chapitre
CHAPITRE 2. LE MODÈLE DE MAPREDUCE
2.1 Introduction au chapitre
2.1.1 MapReduce et Cloud Computing
2.1.2 Les idées de départ
2.1.3 L’importance du MapReduce
2.2 Les notions de base
2.2.1 Le Framework d’exécution
2.2.2 L’architecture de la couche de données
2.2.3 Conclusion
2.3 Le concept MapReduce
2.3.1 Les patrons de conception
2.3.2 Les jointures relationnelles
2.3.3 Conclusion
2.4 Le traitement par indexation inversée
2.4.1 L’indexation
2.4.2 L’indexation inversée
2.4.3 Le classement
2.4.4 Conclusion
2.5 Le traitement des graphes
2.5.1 L’application
2.5.2 La représentation
2.5.3 La recherche initiale parallèle
2.5.4 L’algorithme PageRank
2.5.5 Les problèmes rencontrés
2.5.6 Conclusion
2.6 Les algorithmes EM de traitement de texte
2.6.1 L’estimation de vraisemblance maximale
2.6.2 Les variables latentes
2.6.3 Le modèle HMM
2.6.4 L’application dans MapReduce
2.6.5 La traduction automatique statistique
2.6.6 Conclusion
2.7 La nouvelle génération de MapReduce
2.7.1 Les avantages de YARN
2.7.2 YARN pour les entreprises
2.7.3 Conclusion
2.8 Apache Storm
2.8.1 La puissante combinaison de Storm et de YARN
2.8.2 Les limitations de Storm
2.8.3 Storm Trident
2.8.4 Conclusion
2.9 Apache Spark
2.9.1 L’écosystème de Spark
2.9.2 Les avantages de Spark
2.9.3 Les limitations de Spark
2.9.4 Conclusion
2.10 Les améliorations apportées par Hadoop 3
2.10.1 La compatibilité avec Java
2.10.2 La restauration des données
2.10.3 La refonte de Hadoop Shell Script
2.10.4 La prise en charge de plus de 2 nœuds-maîtres
2.10.5 Le service YARN Timeline
2.10.6 L’équilibreur interne aux nœuds de données
2.10.7 Les changements dans l’attribution des ports par défaut
2.10.8 La gestion des dépendances
2.10.9 La prise en charge de la planification distribuée
2.10.10 L’optimisation au niveau des tâches natives MapReduce
2.10.11 La prise en charge d’autres systèmes de fichiers
2.10.12 La refonte du démon
2.10.13 Conclusion
2.11 Hadoop 3 comparé à Hadoop 2 et Spark
2.11.1 Généralités
2.11.2 Le niveau d’abstraction
2.11.3 Les ressources matérielles
2.11.4 La prise en charge des langages de programmation
2.11.5 La rapidité
2.11.6 La sécurité
2.11.7 La tolérance aux pannes
2.11.8 La couche YARN
2.11.9 Le nombre de nœuds-maîtres
2.11.10 Les systèmes de fichiers
2.11.11 Conclusion
2.12 La solution BigQuery de Google
2.12.1 L’historique de BigQuery
2.12.2 Les critères d’analyse de BigQuery
2.12.3 L’architecture technique
2.12.4 Les composants de BigQuery
2.12.5 Le mode d’accès à BigQuery
2.12.6 Le chargement des données
2.12.7 BigQuery SQL
2.12.8 Les cas d’emploi
2.12.9 Conclusion
2.13 La solution MongoDB
2.13.1 Rappel du modèle orienté document
2.13.2 La nature des données
2.13.3 La relation
2.13.4 Le cycle de vie
2.13.5 Le schéma et les opérations CRUD
2.13.6 La consistance des données
2.13.7 La performance
2.13.8 La volumétrie
2.13.9 L’agrégation des données
2.13.10 La persistance et la résilience
2.13.11 La confidentialité
2.13.12 Conclusion
2.14 La solution Neo4J
2.14.1 Rappel du modèle orienté graphe
2.14.2 La gestion des schémas
2.14.3 La gestion des opérations CRUD
2.14.4 La conformité aux propriétés ACID
2.14.5 La performance
2.14.6 Conclusion
2.15 Conclusion du chapitre
2.15.1 Les limitations de MapReduce
2.15.2 Les solutions alternatives
2.15.3 Au-delà de MapReduce
2.15.4 Tableau comparatif des technologies Hadoop
CHAPITRE 3. LA MODÉLISATION INTÉGRATRICE
3.1 Introduction au chapitre
3.2 Les techniques de modélisation
3.2.1 La modélisation conceptuelle
3.2.2 La modélisation générale
3.2.3 La modélisation hiérarchique
3.2.4 Conclusion
3.3 L’approche de la modélisation intégratrice
3.3.1 La modification de la chaîne de traitement
3.3.2 Conclusion
3.4 Conclusion du chapitre
CHAPITRE 4. LES ALGORITHMES DE MODÉLISATION AVEC HADOOP MAPREDUCE
4.1 Introduction au chapitre
4.1.1 L’algorithme MapReduce (rappel)
4.2 Les algorithmes correspondant aux principaux opérateurs de modélisation
4.2.1 La transformation
4.2.2 Le filtre
4.2.3 Le découpage
4.2.4 La fusion
4.2.5 Conclusion
4.3 Les patrons basiques MapReduce
4.3.1 Le comptage et l’addition
4.3.2 L’assemblage
4.3.3 Les filtres, l’analyse et la validation
4.3.4 L’exécution des tâches distribuées
4.3.5 Le tri
4.3.6 Conclusion
4.4 Les patrons non-basiques MapReduce
4.4.1 Le traitement des graphes
4.4.2 Les valeurs distinctes
4.4.3 La corrélation croisée
4.4.4 Conclusion
4.5 Les patrons relationnels MapReduce
4.5.1 La sélection
4.5.2 La projection
4.5.3 L’union
4.5.4 L’intersection
4.5.5 La différence
4.5.6 Le groupement et l’agrégation
4.5.7 Les jointures
4.5.8 Conclusion
4.6 Les opérations Trident
4.6.1 Les opérations locales
4.6.2 Les opérations de repartitionnement
4.6.3 Les opérations d’agrégation
4.6.4 Les opérations correspondant aux flux groupés
4.6.5 Les opérations de fusion et de jointure
4.6.6 Conclusion
4.7 L’apprentissage automatique et les algorithmes mathématiques
4.7.1 Les systèmes d’apprentissage automatique
4.7.2 Les algorithmes d’apprentissage automatique
4.7.3 Les facteurs de pertinence et d’efficacité
4.7.4 L’apprentissage automatique à l’échelle BigData
4.7.5 Conclusion
4.8 Conclusion du chapitre
PARTIE 2. LA MODÉLISATION INTÉGRATRICE DU TRAITEMENT BIGDATA
CHAPITRE 5. LE PRÉ-TRAITEMENT PAR ÉTUDE DE CAS
5.1 Introduction au chapitre
5.1.1 Les idées de départ
5.1.2 Le format JSON
5.1.3 Le schéma de données implicite
5.1.4 Le concept de pré-traitement
5.2 Les systèmes experts
5.2.1 Les notions de base des systèmes experts
5.2.2 La connexion SGBD et SE
5.2.3 Les règles de traitement
5.2.4 Le moteur d’inférence
5.2.5 Le pré-traitement par étude de cas
5.2.6 L’apprentissage automatique
5.2.7 Conclusion
5.3 La surveillance des réseaux sociaux
5.3.1 La nature et les avantages des réseaux sociaux
5.3.2 Le mécanisme de surveillance des réseaux sociaux
5.3.3 La surveillance par étude de cas
5.3.4 Conclusion
5.4 L’apprentissage automatique pour les nouvelles situations
5.4.1 L’architecture du modèle à définir
5.4.2 Conclusion
5.5 Conclusion du chapitre
CHAPITRE 6. LA MODÉLISATION INTÉGRATRICE EN PRATIQUE
6.1 Introduction au chapitre
6.1.1 L’approche de la modélisation intégratrice
6.2 Les perspectives de la modélisation intégratrice
6.2.1 Les données Twitter
6.2.2 Le passage à l’échelle
6.2.3 Conclusion
6.3 Le pré-traitement par étude de cas
6.3.1 Cas d’emploi 1 : L’évaluation du profil revendeur
6.3.2 Cas d’emploi 2 : Les changements dans le trafic routier
6.3.3 Cas d’emploi 3 : La détection d’un taux d’attrition élevé
6.3.4 Conclusion
6.4 Conclusion du chapitre
PARTIE 3. L’INTERNET DES OBJETS
CHAPITRE 7. LE MÉCANISME IOT
7.1 Introduction au chapitre
7.1.1 La définition de l’IoT
7.2 La naissance de l’IoT
7.2.1 La technologie RFID
7.2.2 Conclusion
7.3 Le concept de base
7.3.1 Les origines de la montée de l’IoT
7.3.2 Conclusion
7.4 L’impact sur le consommateur
7.4.1 La maison intelligente
7.4.2 La ville intelligente
7.4.3 Conclusion
7.5 Les applications dans le domaine professionnel
7.5.1 L’industrie 4.0
7.5.2 L’IoT par satellite
7.5.3 La technologie Blockchain
7.5.4 Conclusion
7.6 Les opportunités et les risques
7.6.1 La sécurité des échanges
7.6.2 Conclusion
7.7 Conclusions du chapitre
CHAPITRE 8. LA MODÉLISATION DANS L’UNIVERS IOT
8.1 Introduction au chapitre
8.2 L’architecture et les plateformes
8.2.1 L’architecture IoT
8.2.2 Les plateformes IoT
8.2.3 Conclusion
8.3 L’exploitation des données IoT
8.3.1 L’application des principes-clés
8.3.2 La modélisation des données IoT
8.3.3 Le format des données échangées
8.3.4 Le traitement des données IoT à grande échelle
8.3.5 Le traitement des événements IoT
8.3.6 Conclusion
8.4 Conclusions du chapitre
CONCLUSION ET PERSPECTIVES
Conclusion
Conclusion
Bibliographie
Liste des abréviations
Listes des figures
Liste des tableaux

INTRODUCTION DE L’OUVRAGE

LA PROBLÉMATIQUE ET LE CONTEXTE DU TRAVAIL

Des volumes considérables de données sont créés tous les jours à partir des données utilisateur générées automatiquement sur Internet. Réseaux sociaux, appareils mobiles, messagerie électronique, blogs, vidéos, transactions bancaires et autres interactions utilisateur, pilotent désormais les campagnes Marketing, les études sociodémographiques, les enquêtes de polices et les intentions électorales, en établissant une nouvelle dimension appelée BigData.

Les moteurs de base de données basés sur le standard SQL et créés dans les années 1970 ont de bonnes performances lors du traitement de petites quantités de données relationnelles mais ces outils sont très limités face à l’expansion des données en volume et en complexité. Le traitement MPP créé initialement au début des années 1980 a amélioré légèrement les indicateurs de performance pour les volumes de données complexes. Cependant, ce traitement n’a pas pu être utilisé pour le traitement des données non-relationnelles à expansion permanente.

Des outils puissants sont requis pour stocker et exploiter ces données en expansion quotidienne, dans le but de soumettre un traitement simple et fiable, des données récoltées des utilisateurs. Des résultats rapides et de bonne qualité sont attendus. Pour les industriels et les décideurs en général, ces résultats sont aussi importants que les plus lourds investissements métier. Les opérateurs de modélisation traditionnels sont confrontés à leurs limitations dans ce défi, puisque les informations se multiplient en volume et complexité, une chose qui actuellement ne peut être gérée que par des techniques de modélisation non-relationnelles. Hadoop MapReduce est considéré comme la technique de traitement la plus efficace, comparée aux bases de données SQL et au traitement MPP. Hadoop dispose d’une performance proportionnelle à la complexité des données volumineuses. C’est un outil efficace pour résoudre les problèmes de données massives mais c’est aussi un concept qui a changé l’organisation des systèmes de traitement en large échelle. Cependant, malgré le succès qu’il a eu, ce modèle n’a pas encore atteint son aspect final en tant que solution informatique mature. Au contraire, il s’agit d’un point de départ vers d’autres perspectives.

Par ailleurs, l’interaction consommateur sur Internet est considérée comme un nouveau canal digital entre les marques et leur audience. Plusieurs EO de données sont créés au quotidien sous forme d’information basée sur des modèles de données en expansion continue, en volume et complexité. Les modèles de notation consommateur intégrant des fonctionnalités de prédiction ont atteint des résultats significatifs en termes de taux de conversion. En utilisant des techniques statistiques et d’autres données consommateurs disponibles sur Internet, des modèles de prédiction personnalisés peuvent être créés afin d’identifier le potentiel des consommateurs.

Dans le contexte de cet ouvrage, le travail consiste à adresser cette question en se basant sur une boîte à outils contenant des opérateurs de modélisation permettant d’établir un pré-traitement des données avant l’envoi au serveur de calcul. Ce travail propose également un mariage de 2 technologies du domaine informatique pour créer un modèle d’application générique : les systèmes de gestion des bases de données (SGBD) et le raisonnement par étude de cas (CBR). Les SGBD fournissent des facilités bas niveau, en revanche, ils assurent une assistance minime en termes d’interface utilisateur et d’extraction de données. Les SGBD ne permettent pas de faire des raisonnements logiques à partir des données stockées, ce qui empêche de mettre en avant la valeur intrinsèque des données. Comme nous le verrons, le SGBD couplé à un moteur d’inférence CBR est plus performant et plus efficace sur cet aspect.

Le rapprochement entre ces 2 techniques permet d’obtenir un concept personnalisable, facilitant la création d’une chaîne de traitement basée sur des opérateurs de modélisation à la carte et profitant des performances de calcul de Hadoop MapReduce. Il s’agit donc d’un traitement BigData en utilisant les règles du raisonnement par étude de cas à l’échelle des réseaux distribués et garantissant un traitement décentralisé, séquentiel, isolé du développeur et évolutif selon le besoin en vigueur.

LES OBJECTIFS DE CET OUVRAGE

L’objectif premier de ce travail est de contribuer à l’établissement d’une vision intégratrice du cycle de vie des données. Cette vision s’intéresse en particulier mais sans exclusive, au pré-traitement des données et s’appuie sur les 3 étapes suivantes :

1.L’acquisition des micro-données diverses et variées, de sources multiples, de tailles, de sémantiques et de formats différents, à travers des connecteurs assurant une conversion des flux en fichiers à stocker, selon le modèle de base de données utilisé.

2.Le pré-traitement via des opérateurs de modélisation sélectionnés par l’utilisateur selon une configuration précise et adéquate avec son besoin, dans le but d’identifier les données nécessaires pour calculer le résultat final parmi le reste.

3.Le traitement des données présélectionnées par les opérateurs de modélisation dans le moteur de calcul et l’obtention d’une indication sur le résultat final recherché.

Cette vision intégratrice mènera à l’étude d’un modèle de pré-traitement à base de cas reposant sur un rapprochement entre un système expert et un système de gestion de base de données permettant d’élaborer un concept de moteur d’inférence avec une base de connaissance de prédicats. Ce modèle étant un moyen efficace pour lancer un pré-traitement des données BigData en se basant sur des cas similaires et permettant par conséquent d’arriver rapidement à une indication sur le résultat final, avec un niveau de tolérance raisonnable. Les approches proposées ont été validées par des prototypes logiciels traitant des jeux de données réalistes et exhibant des gains d’efficacité tangibles.

Enfin, dans le cadre de ce travail, on veille à proposer un modèle intuitif clé en main, permettant d’améliorer les performances du traitement avec des coûts moins importants, ne nécessitant pas une connaissance technique approfondie dans un domaine technologique en expansion continue et ayant à la fois un impact positif sur les performances de la chaîne de traitement, par conséquent, sur l’environnement.

LE PLAN DE DÉVELOPPEMENT

Cet ouvrage est organisé en 4 parties, dans le but de fournir au lecteur une vue panoramique sur l’histoire de traitement des données.

La première partie introduira l’état de l’art du traitement des données BigData.

Dans le premier chapitre, on détaillera l’évolution des systèmes de gestion des bases de données non-relationnelles. On définira les bases de données NoSQL, dont l’usage est le plus répandu aujourd’hui dans les technologies de traitement BigData. Ensuite, on introduira sa dérivée, la base de données NewSQL, tout en exposant son architecture, ses avantages, ainsi que ses limitations. On exposera par la suite la technologie Hadoop MapReduce dans le cadre d’une analyse de l’efficacité des moteurs de traitement existants. Cela permettra de définir plus tard les différents modèles de base de données non-relationnelles existants et leur usage, ainsi que les bases de données multi-modèle. Ensuite, on consacrera la dernière section à l’activité principale des systèmes distribués en termes de consistance, de création des données, de coordination, ainsi que les autres aspects de gestion, notamment la répartition de la charge, la tolérance aux pannes et la haute disponibilité. Enfin, on terminera ce chapitre par la description des difficultés générales de mise en œuvre de ces technologies.

Le deuxième chapitre introduira le Framework MapReduce et ses principales caractéristiques le mettant en avant par rapport aux autres technologies. On présentera par la suite les différentes techniques de traitement et patrons de conception, tels que le tri, les jointures, l’indexation, le classement et la conversion. Le traitement des graphes avec MapReduce sera abordé, ainsi que les algorithmes de traitement de texte. Ensuite on évoquera les différents projets et évolutions de l’univers MapReduce, en particulier la nouvelle génération appelée YARN et les principaux projets dérivés d’Apache Hadoop, Apache Storm et Apache Spark. On évoquera par la suite la publication d’Apache Hadoop 3, pour finir ce chapitre avec un tableau comparatif des différentes possibilités proposées.

Le troisième chapitre exposera les recherches portant plus particulièrement sur l’approche de la modélisation intégratrice. On définira également les 3 grandes familles des techniques de modélisation, la modélisation conceptuelle, la modélisation générale et la modélisation hiérarchique. Ensuite, on présentera le périmètre de cette recherche et la motivation de ce travail qui consiste à proposer un modèle de traitement intuitif et clé en main, ne nécessitant pas une connaissance technique approfondie dans le domaine BigData et permettant d’optimiser les performances de la chaîne de traitement.

Le quatrième chapitre expliquera en détail les principaux algorithmes de modélisation avec MapReduce. Cela comprend les principaux opérateurs de modélisation, tels que le filtre, le découpage, la transformation ou la fusion, ainsi que les patrons basiques et non-basiques de MapReduce. Dans cette catégorie, on définira les algorithmes d’agrégation et d’assemblage, le tri, les tâches distribuées, ainsi que les algorithmes de traitement des graphes. Par la suite, on évoquera les patrons relationnels MapReduce, comme la sélection, l’intersection, la projection, l’union, les jointures et d’autres. Pour finir, on présentera l’API Trident d’Apache Storm, ainsi que les potentiels de l’apprentissage automatique (Machine Learning ou apprentissage-machine) avec MapReduce.

La seconde partie décrira le travail élaboré pour approcher la problématique de la modélisation.

Le cinquième chapitre introduira un algorithme de pré-traitement via un raisonnement par étude de cas et ce en 2 parties. D’abord, on présentera brièvement les systèmes experts et les avantages d’un rapprochement avec les systèmes de gestion des bases de données. On expliquera par la suite le concept du moteur d’inférence basé sur les règles et les profils à définir, ainsi que son utilisation dans un contexte de modélisation intégratrice à l’échelle BigData. Pour finir, on évoquera les perspectives d’enrichissement de la base de cas via l’apprentissage automatique. Dans la deuxième partie, on se situera dans un contexte de surveillance des réseaux sociaux. On appliquera alors le concept de pré-traitement par étude de cas et son adaptation aux besoins métier.

Le sixième chapitre permettra de présenter quelques cas d’emploi, ainsi que les résultats expérimentaux. Dans ce contexte, on réalisera d’abord une étude des données Twitter suivie d’une autre étude plus globale. Ensuite, on abordera le pré-traitement par étude de cas, à travers 3 cas d’emploi adaptés à la vie quotidienne en entreprise et le besoin d’outils performants de traitement des données :

1.L’évaluation du profil revendeur

2.Les changements dans le trafic routier

3.La détection d’un taux d’attrition élevé

La troisième partie est consacrée à l’Internet des objets en tant que concept et applications dans la vie quotidienne d’un individu, ainsi que dans le domaine professionnel.

Le septième chapitre décrira brièvement le mécanisme de l’Internet des objets. On détaillera ensuite l’histoire de sa naissance, son concept de base et ses applications dans la sphère privée sous la forme d’une maison intelligente et d’une ville intelligente, ainsi que dans la dimension professionnelle, notamment la notion d’industrie 4.0, la liaison par satellite et la technologie Blockchain. Pour finir, on expliquera les opportunités et les risques tout en mettant en avant l’aspect de la sécurité des échanges.

Le huitième chapitre sera consacré à la modélisation dans l’univers de l’Internet des objets. Dans ce contexte on présentera concrètement 2 aspects correspondants :

1.L’architecture et les plateformes

2.L’exploitation des données

Finalement, la dernière partie présentera la conclusion et les perspectives de développement de la modélisation en général et le pré-traitement par étude de cas.

PARTIE 1. ÉTAT DE L’ART

CHAPITRE 1. LE TRAITEMENT DES DONNÉES BIGDATA

1.1 Introduction au chapitre

Depuis leur création, les bases de données, à taille petite ou volumineuse, sont devenues une entité essentielle et inséparable d’un applicatif ou d’un site Internet quelconque. Les bases de données relationnelles les plus répandues à l’époque, avaient leurs SGBD disponibles par défaut dans les systèmes informatiques.

Avec l’expansion du nombre d’internautes et la multitude des terminaux et objets connectés, les bases de données relationnelles ne sont plus capables de supporter les données volumineuses (stocker, extraire, déplacer et copier), surtout si elles sont distribuées sur plusieurs serveurs. D’où la nécessité d’une nouvelle génération de bases de données avancées, compatible avec l’étendue géographique des réseaux immenses de serveurs, dits Clusters et capable de gérer des quantités importantes de données, principalement liées à l’essor des plateformes numériques, des capteurs sans fil, des applications de réalité virtuelle, et des milliards de smartphones en circulation.

Figure 1 : Expansion exponentielle des données échangées sur Internet

La Figure 1 montre l’évolution des systèmes d’information et des données échangées depuis la création des réseaux informatiques jusqu’à la nouvelle génération du Web, permettant aux internautes de contribuer à l’échange d’information et d’interagir de façon simple, à la fois au niveau du contenu et de la structure des pages, créant notamment ce qu’on appelle de nos jours, le Web social.

1.2 Les bases de données NoSQL

Désormais, l’ubiquité de la connexion Internet est une réalité (les voitures que nous conduisons, les montres que nous portons, nos petits appareils médicaux domestiques, nos réfrigérateurs et congélateurs, nos Smartphones et ordinateurs portables). De plus, les données numériques produites par les êtres humains, dont les documents, les enregistrements vocaux, les séquences vidéo, les photos et autres, atteignent des volumes importants de plusieurs EO par jour.

Ces données actuellement stockées dans des bases qui leur ont été conçues spécifiquement, sont gérées par des logiciels de gestion de bases de données volumineuses, jouant le rôle d’intermédiaires entre les bases de données d’un côté et les applicatifs et leurs utilisateurs de l’autre. On parle ici des bases de données non-relationnelles, dites NoSQL.

1.2.1 Le mouvement NoSQL et l’élaboration du terme

Carlo Strozzi a utilisé le terme NoSQL ou Not Only SQL en premier en 1998 pour désigner la base de données relationnelle Open Source qu’il a développée et qui ne disposait pas d’une interface SQL comme ses homologues. Carlo Strozzi a proposé par la suite de changer le terme NoSQL en NoRel pour non-relationnelles, vu que ce mouvement a convergé avec le temps vers les bases de données non-relationnelles uniquement. En 2009, le terme NoSQL a été réintroduit par Eric Evans à une échelle plus large, décrivant les nombreuses bases de données s’opposant à la notion relationnelle et possédant les caractéristiques suivantes :

1.Elles sont toutes compatibles avec les systèmes distribués.

2.Elles sont de type Open Source.

3.Elles sont de type non-relationnel.

1.2.2 La définition NoSQL et les avantages pour les développeurs

NoSQL est un type spécifique de bases de données, permettant de stocker et de récupérer les données après restructuration, en utilisant des techniques différentes de celles connues dans les bases de données relationnelles. Les développeurs de nos jours ont tendance à utiliser ce type de bases de données pour la simplicité de leur implémentation et leur évolutivité sans limites (horizontalement, à travers de nouvelles colonnes).

Afin d’obtenir de meilleures performances, les bases de données NoSQL ont abandonné certaines fonctionnalités proposées par défaut par les bases relationnelles comme les transactions ou encore les vérifications d’intégrités. Le premier besoin fondamental auquel répond NoSQL est la performance. C’est pour répondre à ce besoin que cette solution a vu le jour en procédant à des compromis sur le caractère ACID des systèmes de gestion de bases de données relationnels. Ces intelligents compromis sur la notion de relationnel ont permis de dégager les systèmes de gestion de bases de données relationnels de leurs freins à l’évolutivité.

De nos jours, NoSQL est devenu inséparable du BigData, le terme décrivant les données volumineuses et en expansion permanente, ainsi que des applicatifs temps réel. Cette technologie remplace progressivement les bases de données relationnelles, assurant ainsi une haute performance.

1.2.3 Les caractéristiques des bases de données NoSQL

Les bases de données NoSQL regroupent plusieurs caractéristiques apportant chacune une valeur ajoutée à leur usage :

1.Le coût raisonnable et la facilité de mise en œuvre.

2.Le partitionnement et la copie des fichiers de données sur plusieurs machines.

3.La structure dynamique n’ayant pas de schéma de données fixe.

4.L’évolutivité en rajoutant des colonnes, ce qui permet de traiter les données plus rapidement.

5.La rapidité du transfert des données, comparé aux bases de données classiques.

6.L’évolutivité en rajoutant des nœuds supplémentaires dans le Cluster sans avoir besoin de faire une répartition.

De plus les bases de données NoSQL sont sujettes au théorème CAP et ne sont pas conformes aux propriétés ACID, contrairement aux bases de données relationnelles. Les réseaux sociaux appliquent fortement l’utilisation des bases de données NoSQL, vu leurs besoins compatibles avec CAP et contrairement aux banques nécessitant plus de rigidité.

1.2.3.1 Les propriétés ACID

Il s’agit d’un ensemble de propriétés qui garantissent une transaction exécutée de façon fiable :

1.L’atomicité, dite Atomicity, est une propriété qui assure qu’une transaction se fait au complet ou pas du tout. Si une partie d’une transaction ne peut être faite, il faudra effacer toute trace de la transaction et remettre les données dans l’état où elles étaient avant la transaction. L’atomicité doit être respectée dans toute situation, comme une panne d’électricité, une défaillance de l’ordinateur ou une panne d’un disque magnétique.

2.La consistance, dite Consistency, qui assure que chaque transaction amènera le système d’un état valide à un autre état valide. Tout changement à la base de données doit être valide selon toutes les règles définies, incluant mais non-limitées aux contraintes d’intégrité, aux restaurations du système en cascade, dites Rollbacks, aux déclencheurs de base de données et à toute combinaison d’événements.

3.L’isolation, dite Isolation, qui fait en sorte que toute transaction doit s’exécuter comme si elle était la seule sur le système. Aucune dépendance possible entre les transactions. Cette propriété assure que l’exécution simultanée de transactions produit le même état que celui qui serait obtenu par l’exécution en série des transactions. Chaque transaction doit s’exécuter en isolation totale. Si 2 transactions s’exécutent simultanément, alors chacune devra demeurer indépendante de l’autre.

4.La durabilité, dite Durability, qui assure que lorsqu’une transaction a été confirmée, elle demeure enregistrée même à la suite d’une panne d’électricité, d’une panne de l’ordinateur ou d’un autre problème. Par exemple, dans une base de données relationnelle, lorsqu’un groupe de requêtes SQL est exécuté, les résultats doivent être enregistrés de façon permanente, même dans le cas d’une panne immédiatement après l’exécution des requêtes.

1.2.3.2 Le théorème CAP

Le théorème CAP, en français dit CDP, connu également sous le nom de théorème de Brewer, affirme qu’il est impossible sur un système informatique de calcul distribué de garantir en même temps les 3 contraintes de consistance, disponibilité et persistance au morcellement :

1.La consistance, dite Consistency, de façon à ce que tous les nœuds du système voient exactement les mêmes données au même moment.

2.La disponibilité, dite Availability, de façon à garantir que toutes les requêtes reçoivent une réponse.

3.La persistance au morcellement, dite Partition Tolerance, faisant en sorte qu’aucune panne moins importante qu’une coupure totale du réseau ne doit empêcher le système de répondre correctement (en cas de morcellement en sous-réseaux, chacun doit pouvoir fonctionner de manière autonome).

1.2.3.3 La consistance des données

Mis à part leurs nombreux avantages, les bases de données NoSQL ne sont pas à l’abri des problèmes de consistance des données. Les développeurs des applications et les concepteurs de bases de données doivent gérer cet aspect selon la nature du métier. À titre d’exemple, sur un site Internet de réservation de chambres d’hôtel, il est possible que 2 personnes puissent réserver à un intervalle de temps relativement réduit une même chambre d’hôtel. Il sera envoyé par la suite un mail à la personne qui a réservé en deuxième, lui expliquant que sa réservation n’a pas été prise en considération. Même principe lors de l’achat d’un produit sur une boutique en ligne. Les administrateurs des sites marchands préfèrent ce fonctionnement, plutôt que d’afficher un message d’erreur à l’écran, invitant l’utilisateur à recommencer.

1.2.4 Les limitations des bases de données NoSQL

Globalement les systèmes NoSQL ne respectent pas les propriétés ACID ou en tout cas pas complètement. Cet aspect ne permet pas d’offrir une grande sûreté dans l’accès aux données. Par ailleurs la base de données NoSQL reste très contraignante par certains aspects. Ainsi le traitement des requêtes de type OLAP nécessite une programmation importante au niveau applicatif.

1.2.5 Conclusion

Tout d’abord, cette génération de bases de données est encore relativement jeune et n’a pas encore atteint l’apogée de la maturité. Seules les petites et les moyennes entreprises les font évoluer pour le moment. Les grandes entreprises mettent encore en avant leurs SGBD classiques pour ce qu’ils offrent en termes de stabilité et de structuration. IBM toutefois, laisse le choix à l’utilisateur d’intégrer une base NoSQL sous forme d’application base de données.

1.3 NewSQL en route vers la base de données moderne

NewSQL est un stockage distribué et potentiellement entièrement en mémoire et pouvant être requêté classiquement par une interface SQL. NewSQL est tiré du monde NoSQL mais reste différent. Comme NoSQL il s’agit d’une nouvelle architecture logicielle qui propose de repenser le stockage des données. Cette base de données moderne profite des architectures distribuées, des progrès du matériel et des connaissances théoriques depuis 35 ans. Mais contrairement à NoSQL elle permet de conserver le modèle relationnel au cœur du système.

NewSQL est né de la rencontre de 3 types d’architecture, relationnelle, non-relationnelle et grille de données appelée également cache distribué, comme indiqué dans la Figure 2. En effet il se positionne comme un stockage distribué conçu dans le prolongement des architectures NoSQL, pour des accès transactionnels à fort débit, au moyen d’une interface SQL. Les systèmes NewSQL peuvent être généralement groupés en 3 catégories : les nouvelles architectures ; les moteurs SQL ; et enfin, le partage transparent. D’un point de vue évolutivité, il se situe en tant que concurrent direct des solutions NoSQL. Mais contrairement à ces solutions il conserve une interface relationnelle via le SQL, ce qui est l’une de ses forces.

Par ailleurs, la plupart des solutions NewSQL proposent un stockage en mémoire. Ce stockage en mémoire distribué sur plusieurs machines sous forme de grille de données est largement utilisé depuis une dizaine d’années dans les environnements où une faible latence est critique, notamment dans certaines applications des banques d’investissement et de traitement de commandes. Les solutions NewSQL partagent ainsi un positionnement intermédiaire entre les solutions NoSQL et les grilles de données.

Figure 2 : Naissance du NewSQL à partir de 3 architectures

1.3.1 L’architecture NewSQL

L’architecture NewSQL reprend des expériences antérieures du SQL relationnel et du NoSQL plusieurs caractéristiques, tout en ayant certaines particularités en termes de choix et d’avantages :

1.Le choix d’une interface SQL et d’un schéma relationnel.

2.Le schéma relationnel avec des limitations pour faciliter la distribution des données et des traitements.

3.La distribution et la réplication des données pour assurer l’évolutivité et la résilience.

1.3.2 Les avantages de la solution NewSQL

La solution NewSQL présente des avantages intéressants en termes de performances par rapport à ses prédécesseurs :

1.Elle utilise le SQL comme langage commun de requêtes.

2.Elle présente une architecture qui a de meilleures performances par nœud que les solutions classiques de type SGBD relationnel.

3.Elle minimise la complexité des applications tout en améliorant la consistance des données et en fournissant un support transactionnel complet.

4.Elle est compatible avec les outils de travail du standard SQL.

5.Elle fournit des analyses plus riches des traitements.

6.Elle est compatible avec l’architecture distribuée des Clusters.

7.Elle fournit un traitement plus performant des données en mémoire.

1.3.3 Les limitations des bases de données NewSQL

La solution NewSQL est confrontée à quelques limitations l’empêchant d’atteindre un niveau de maturité suffisant :

1.Son architecture de calcul en mémoire, dit In-Memory, ne fonctionne pas au-delà de quelques TO de données.

2.Cette architecture nécessite un matériel spécifique avec des capacités importantes de stockage en mémoire, ce qui revient très onéreux.

3.Malgré son attitude à vouloir intégrer le modèle relationnel, le NewSQL fournit un accès limité aux outils de travail du standard SQL.

1.3.4 Conclusion

Une base de données NewSQL conserve la structure classique en colonnes mais fait appel à différents procédés pour conserver la rapidité même sur de larges volumes. En revanche, cette technologie n’a pas le recul suffisant pour aller plus loin et n’a pas encore pu suffisamment faire ses preuves. Par conséquent les entreprises sont encore réticentes à l’adoption de cette toute nouvelle architecture.

1.4 L’efficacité des moteurs de traitement existants

Hadoop MapReduce est considéré comme la technique de traitement la plus efficace, comparée aux bases de données SQL et au traitement MPP. Hadoop dispose de bonnes performances à l’échelle de la complexité des données volumineuses. La Figure 3 donne une indication sur la performance de traitement de Hadoop comparée aux 2 autres moteurs de traitement.

1.4.1 MapReduce

En 2004, Google a publié un nouvel article introduisant l’utilisation d’une technique simplifiée de traitement des données, affichant de hautes performances dans le traitement des données volumineuses. Un modèle aussi intuitif que le MapReduce ne nécessite pas d’expertise concernant le parallélisme et les systèmes distribués. Son Framework Plug-and-Play embarque tous les détails pour implémenter les systèmes de calcul parallèle, la persistance et la résilience, l’optimisation et l’équilibre des ressources[1].

Figure 3 : Performance des moteurs de traitement

Google a obtenu un brevet sur la fonction MapReduce mais la validité de ce brevet est contestée, vu que « map » et « reduce » sont 2 fonctions primitives de programmation qui ont été utilisées dans le développement logiciel pendant des décennies.

1.4.1.1 La fonction map

Une opération faisant appel à la fonction « map » permet de lancer une fonction pour chaque élément dans une séquence afin d’obtenir en retour une séquence de taille égale des valeurs résultant.

1.4.1.2 La fonction reduce

Une opération faisant appel à la fonction « reduce » permet d’accumuler le contenu d’une séquence dans une seule valeur de retour, en utilisant une fonction qui va combiner chaque élément dans la séquence avec la valeur de retour de l’itération précédente.

1.4.2 Apache Hadoop

En 2009, un Framework Open Source de type Java a été créé. Ce nouveau projet Apache a été inspiré du papier publié par Google. Le traitement décentralisé des données dans Hadoop est optimisé pour des Clusters. Cette technique est déjà utilisée par des entreprises comme Yahoo, Microsoft et Facebook. Yahoo dispose en ce moment du plus grand réseau de serveurs Hadoop (plus de 40,000 machines).

L’évolutivité de Hadoop permet d’améliorer les performances de traitement des données sans avoir besoin d’une connaissance de fond de son architecture. Désormais, il n’y a plus besoin de faire une montée de niveau des composants matériels. Le fait d’augmenter le nombre de serveurs de calcul dans le réseau améliore significativement le traitement des données.

1.4.3 Les bases de données non-relationnelles

Les données informatiques générées actuellement, en expansion continue, contiennent des types de données complexes et hétérogènes (texte, images, vidéos, données de géolocalisation, transactions d’achat) qui nécessitent des moteurs de traitement puissants, capables de stocker et traiter ces structures complexes de données. Les « 3 V » de la définition de Gartner (volume, vitesse et variété) qui décrivent cette expansion de données permettront de déduire un « 4ème V », valeur du BigData. Cette valeur ajoutée met en avant le besoin de valoriser les données en entreprise[2].

Les SGBD relationnels sont incapables de traiter cette problématique pour diverses raisons :

1.Le facteur contraignant principalement est le schéma de données, à cause des changements permanents de structure du BigData ne pouvant être représentés dans un schéma de données.

2.La complexité et la taille des données saturent la capacité des SGBD relationnels traditionnels pendant l’acquisition, le stockage et le traitement des données à coûts raisonnables (durée et performance de calcul).

3.La modélisation relationnelle du BigData ne s’adapte pas facilement à la persistance au morcellement des systèmes distribués.

Le NoSQL utilisé pour la première fois en 1998 est de plus en plus utilisé comme une alternative viable aux bases de données relationnelles, particulièrement pour les applications Web et les services interactifs[3][4].

1.4.4 BigTable et HBase

BigTable développé et exploité par Google, est une table de données multidimensionnelle, distribuée et triée. Cette table est indexée par un identifiant de ligne, dit RowKey, un identifiant de colonne, dit ColumnKey et un horodatage, dit Timestamp, dont chaque valeur est un tableau d’octets non-interprétés.

BigTable est utilisé par plusieurs applications de Google et répond à la nécessité d’un système de stockage de données structurées hautement évolutif, puisqu’il fournit un accès aléatoire aux données et en temps réel. BigTable n’est pas une base de données relationnelle, vu qu’il structure les données dans des enregistrements agrégés dans de gigantesques fichiers indexés.

Ces enregistrements de données sont composés de colonnes groupées dans des familles. Les enregistrements de données sont identifiés par des RowKeys triés d’une manière lexicographique. Les valeurs dans chaque colonne disposent d’un Timestamp pour sauvegarder les valeurs antérieures[5]. Apache HBase créé en 2008, est l’homologue de Google BigTable au sein de Hadoop.

1.4.4.1 Apache HBase

Apache HBase est un projet lié à Hadoop. Apache décrit HBase comme ayant été conçu au-dessus de HDFS, de la même manière que BigTable est conçu au-dessus de GFS. Cette architecture est illustrée dans la Figure 4. Comme avec beaucoup d’autres projets Apache, une communauté importante s’est créée autour de HBase[6]. La distribution HBase contient également des logiciels de cryptographie.

1.4.4.2 Facebook MyRocks

Jusqu’en 2018, Apache HBase était utilisé dans l’application de messagerie de Facebook. Depuis, l’entreprise a pris la décision de changer vers MyRocks, le projet base de données Open Source de Facebook, écrit en C++ et intégrant les fonctionnalités revisitées de MySQL et de RocksDB, une variante de LevelDB de Google :

1.L’efficacité de compression des données stockées.

2.Le nombre minime de données séquentielles en lecture / écriture.

3.La gestion optimisée des index permettant de gagner de l’espace pendant la codification.

4.La rapidité de réplication des données.

5.La rapidité de chargement pour établir une session.

Le projet MyRocks est centré dès le départ autour de l’efficacité de stockage des données. Il peut toutefois, être étendu à un périmètre plus large intégrant d’autres fonctionnalités innovantes et assurant une plus grande attractivité au sein de la communauté BigData.

1.4.5 GFS et HDFS

Le réseau de serveurs GFS est orchestré par un nœud-maître et contient un grand nombre de serveurs de stockage. Chaque fichier est divisé en plusieurs blocs de fichiers de taille fixe de 64 MO chacun, dits Chunks. Au moment de la création, le nœud-maître affecte à chacun un libellé 64-bits unique. Les Chunks sont stockés et remplacés plusieurs fois tout au long du réseau avec un minimum de 3 fois. Le nœud-maître stocke les métadonnées associées. Ces informations sont tenues à jour grâce aux messages de mise à jour de statut de chaque serveur de stockage, dits HeartBeat[7].

HDFS est l’homologue de GFS. Il est conçu pour être un système de stockage distribué, évolutif, résilient et pour interagir facilement avec MapReduce. Il fournit une bande passante d’agrégation importante tout au long du réseau. Comme pour GFS, un réseau HDFS est composé d’un nœud-maître appelé Namenode et des serveurs de données appelés Datanodes, comme expliqué dans la Figure 5. La structure du fichier HDFS est divisée en blocks de 128 MO.

Figure 4 : Piles de Hadoop et de Google

Figure 5 : Architecture HDFS

1.4.6 Conclusion

Le Framework MapReduce permet à la technologie BigData telle que fournie par Hadoop de fonctionner grâce à des composants système. Le système de fichiers HDFS utilise ces composants pour la gestion de la persistance, exécute des fonctions avancées sur les données, afin de trouver des résultats en très peu de temps. Ce mécanisme consiste donc à exécuter une transformation des données, déléguée et traitée par une architecture dite Cluster et pouvant inclure des milliers d’ordinateurs qui opèrent simultanément. Hadoop possède les structures de base nécessaires pour effectuer les calculs : un système de fichiers, un langage de programmation et une méthode pour distribuer les programmes à travers le Cluster HDFS.

Avec Hadoop, le BigData est distribué en segments étalés sur une série de nœuds s’exécutant sur des périphériques de base. Au sein de cette structure, les données sont dupliquées à différents endroits, afin de récupérer l’intégralité des informations en cas de panne. Les données ne sont pas organisées par rangs ni par colonnes relationnelles, comme dans le cas de la gestion classique de la persistance, ce qui comporte une capacité à stocker du contenu structuré, semi-structuré et non-structuré.

1.5 Les modèles de données non-relationnels

Les modèles de données relationnels et non-relationnels sont profondément différents. Le modèle relationnel intègre les données dans des tables interconnectées contenant des lignes et des colonnes prédéfinies. Chaque table fait référence aux autres à travers les clés étrangères stockées dans les colonnes également[8]. Lors de l’interrogation des données par l’utilisateur, l’information requise sera collectée depuis plusieurs tables et affichée. Dans l’esprit, on se pose la question de type « quelle est la réponse à ma question parmi ces données ? ».

Les modèles de données non-relationnels sont souvent initiés par les requêtes applicatives, contrairement à la modélisation relationnelle. La modélisation des données non-relationnelles sera alors pilotée par des patrons d’accès applicatifs. Une compréhension avancée de la structure de données et de l’algorithme est requise afin que la logique globale soit de type « quelles questions correspondent aux données que j’ai sélectionnées ? ». Le théorème CAP s’applique bien aux systèmes non-relationnels.

Étant donné que les modèles relationnels ont été conçus pour réagir avec l’utilisateur final, les modèles non-relationnels ont tendance à évoluer dans le but d’atteindre une structure orientée utilisateur. On distingue seulement 5 grandes familles parmi les types de modélisations de données non-relationnelles :

1.Le stockage clé-valeur.

2.La base de données BigTable.

3.Le modèle de données orienté document.

4.Le modèle de données orienté graphe.

5.La base de données multi-modèle.

1.5.1 Le stockage clé-valeur

Chaque enregistrement de données dans un stockage clé-valeur est présent sous la forme d’un couple composé d’une clé unique pouvant être utilisée pour identifier la valeur de données. Il s’agit du modèle non-relationnel le plus simple. Dans une base de données NoSQL grandeur nature, le stockage clé-valeur doit être partitionné à travers les systèmes distribués. Afin de s’assurer que les données sont réparties uniformément sur les partitions, plusieurs stockages clé-valeur procèdent à la technique de hachage du couple clé-valeur, dans le but de déterminer l’endroit de stockage de ces données.

Figure 6 : Disposition orientée colonne des stockages clé-valeur

Un stockage clé-valeur se focalise uniquement sur la capacité de stocker et récupérer les données, plutôt que de gérer sa structure. Certains stockages clé-valeur sont optimisés pour prendre en charge les requêtes, permettant de récupérer une série d’éléments de données contigües, plutôt que des données individuelles. Ces derniers stockent régulièrement les données dans une partition selon un ordre de tri par clé, plutôt que de calculer l’endroit par la technique de hachage. Le modèle de stockage clé-valeur trié améliore significativement les performances des fonctions d’agrégation. La Figure 6 montre la disposition orientée colonne des stockages clé-valeur par rapport à la disposition orientée ligne dans un modèle SGBD traditionnel.

1.5.2 La base de données BigTable

La base de données BigTable contient une seule table et peut atteindre une taille immense (plusieurs PO) via un stockage distribué, à travers un grand nombre de serveurs[9]. La base de données BigTable permet de modéliser les données comme étant une carte de cartes de cartes à savoir, les familles de colonnes, les colonnes et les versions horodatées, dites Timestamps. Sa disposition orientée colonne et ses zones de stockage multi-valeur permettent de sauvegarder efficacement les données éparpillées.

Dans une base de données BigTable, les clés des colonnes ayant les mêmes caractéristiques se regroupent ensemble dans des familles de colonnes. Les colonnes d’une même famille partagent en général les données de même type. Google utilise les familles de colonnes dans leur implémentation de BigTable pour stocker toutes les ancres qui pointent à la même page Web. Cette conception permet de rendre la lecture et l’écriture plus efficace dans un environnement distribué. La composition distribuée des bases de données BigTable rend néanmoins complexe toute jointure entre 2 tables. Le développeur doit implémenter cette logique dans son application ou encore la concevoir de façon à rendre cette fonctionnalité non-indispensable.

Finalement, dans le but de vulgariser l’usage de BigTable, Google a introduit en 2010 BigQuery, son outil permettant d’interroger les modèles de données orientés colonne. Dans le chapitre 2, on présentera une étude de la solution BigQuery de Google.

1.5.3 Le modèle de données orienté document

Une base de données orientée document est conçue pour stocker, récupérer et gérer des données orientées document ou semi-orientées document. Il s’agit d’une extension du modèle clé-valeur de façon à ce que les valeurs soient stockées dans un format structuré de document que la base de données puisse interpréter. Par exemple, ce document peut être une publication sur un blog avec ses commentaires et ses Hashtags, stockés d’une façon dé-normalisée.

Du moment que les données sont transparentes, ce modèle de stockage est capable de faire des opérations avancées (comme l’indexation des champs dans le document) et permet de récupérer les données d’une page Web entière avec une seule requête. Ce modèle est bien adapté pour les applications orientées contenu. L’avantage de la base de données orientée document par rapport au type BigTable se résume essentiellement par 2 améliorations significatives dont le concept est illustré dans la Figure 7 :

1.Les valeurs avec les régimes de complexité arbitraires, pas seulement une carte de cartes.

2.L’index géré dans la base de données dans certaines implémentations.

Les moteurs de recherche par mots-clés peuvent être considérés comme un type de base de données orientée document, dans le sens où ils fournissent un schéma flexible et une indexation automatique. La seule différence est que la base de données orientée document classique groupe les index par nom de champs, alors que les moteurs de recherche le font par valeur.

Figure 7 : Comparaison entre le modèle BigTable et le modèle orienté document

La modélisation orientée document suppose que l’encodage et la structuration des données se fait en formats standards, tels que le XML, XAML, YAML, JSON et BSON mais encore les types binaires, comme le PDF et l’ancien format des documents Microsoft Office. Dans le chapitre 2, on présentera une évaluation du modèle de données orienté document de NoSQL, dans le cadre de la solution MongoDB.

1.5.4 Le modèle de données orienté graphe