Cours de Big Data

Exposés

1- Entrepôts de données
2- Méthode ACP
3- Méthode AFC
4- Bases de données NoSQL
5- MongoDB
6- Hadoop & MapReduce
7- Hadoop & Spark

Références
1- Pr. A. Elouardighi, Cours & TD Datawarehouse, High-Tech
2- Pirmin Lemberger et autres, Big Data et Machine Learning – Manuel du datascientist
3- Arnaud Martin, L’analyse de données, Polycopié de cours ENSIETA _ Réf. : 1453,
Septembre 2004
4- Lcsqa, Principe de l’analyse en composantes principales, INERIS DRC-03-45597-LRl-LMa –
LCSQA-n°140_v1, disponible à l’adresse :
https://lcsqa.org/system/files/Etude14.1_guide_Annexe2_ACP.pdf
5- Wikipédia, Analyse factorielle des correspondances, disponible à l’adresse :
https://fr.wikipedia.org/wiki/Analyse_factorielle_des_correspondances
Table des matières
Chapitre 1 : Entrepôts de Données ......................................................................................................... 5
Notions et Architecture d’un DWH .................................................................................................... 5
Systèmes transactionnels vs Systèmes décisionnels ....................................................................... 5
Systèmes décisionnels.................................................................................................................... 5
Des données aux décisions .............................................................................................................. 6
Applications transactionnelles v.s Applications décisionnelles ................................................. 6
Incompatibilités des deux activités .............................................................................................. 6
Naissance du Datawarehouse .......................................................................................................... 7
Exemple: un DW dans les télécoms.................................................................................................... 9
Architecture centralisée................................................................................................................. 10
Architecture fédérée ...................................................................................................................... 10
OLAP et Analyse multidimensionnelles ........................................................................................... 10
OLAP ............................................................................................................................................ 10
Modèle conceptuel ........................................................................................................................ 11
Vue multidimensionnelle .................................................................................................................. 11
Agrégation des données .................................................................................................................... 11
Granularité des dimensions ............................................................................................................... 12
Opérations OLAP.............................................................................................................................. 12
Opérations sur la structure des cubes ............................................................................................ 12
Opérations sur le contenu des cubes ............................................................................................. 12
Opérations entre cubes .................................................................................................................. 13
Exemple d’outils OLAP .................................................................................................................... 14
Modélisation et Conception d’un DWH ........................................................................................... 14
Construction d’un Datawarehouse ................................................................................................ 14
Modélisation ................................................................................................................................. 15
Alimentation ................................................................................................................................. 16
Outils ETL .................................................................................................................................... 17
Chapitre 2 : Analyse de données .......................................................................................................... 18
Les données ...................................................................................................................................... 18
Objectifs ............................................................................................................................................ 19
Méthodes .......................................................................................................................................... 20
Analyse en Composantes Principales............................................................................................ 21
Analyse Factorielle de Correspondances ...................................................................................... 23
Les logiciels ....................................................................................................................................... 25
Domaine d’applications .................................................................................................................... 26
Chapitre 3 : Le big data dans les organisations..................................................................................... 27
La recherche de l’innovation............................................................................................................. 27
L'entreprise dans un écosystème ................................................................................................. 27
Une volonté de maîtrise................................................................................................................ 28
Des besoins forts ........................................................................................................................... 28
L’avancé par le cloud ........................................................................................................................ 28
La création de la valeur ..................................................................................................................... 29
Les « 3V » du Big Data ....................................................................................................................... 29
Le volume ...................................................................................................................................... 30
La vélocité ..................................................................................................................................... 30
La variété ....................................................................................................................................... 30
Un champ immense d’application .................................................................................................... 31
Exemples de compétences à acquérir .............................................................................................. 32
Chapitre 4 : Les bases de données NoSQL ............................................................................................ 34
Bases de données relationnelles ...................................................................................................... 34
Le Mouvement NoSQL ...................................................................................................................... 37
Les contraintes des applications web à très grande échelle......................................................... 37
Le « théorème » CAP..................................................................................................................... 38
Sacrifier la flexibilité pour la vélocité ............................................................................................ 39
Une définition pour une base de données NoSQL ? ..................................................................... 40
Les solutions NoSQL .......................................................................................................................... 41
Les entrepôts clé-valeur ................................................................................................................ 42
Les bases orientées documents .................................................................................................... 44
Les bases orientées colonnes........................................................................................................ 46
Les bases de données orientées graphes ..................................................................................... 50
Résumé ............................................................................................................................................. 51
Chapitre 5 : L’algorithme MapReduce et le framwork Hadoop............................................................ 53
Automatiser le calcul parallèle.......................................................................................................... 53
Le pattern MapReduce ..................................................................................................................... 54
Le Framework Hadoop ...................................................................................................................... 56
Planning des exécutions................................................................................................................ 56
Tolérance aux pannes ................................................................................................................... 57
Découpage des données en lots ................................................................................................... 58
Monitoring des processus ............................................................................................................. 60
Au-delà de MapReduce................................................................................................................. 60
Résumé ............................................................................................................................................. 61
 Chapitre 1 : Entrepôts de Données
Notions et Architecture d’un DWH

Systèmes transactionnels vs Systèmes décisionnels

Systèmes transactionnels
Les outils traditionnels de gestion et d’exploitation des données sont du type
transactionnel ou OLTP (On-Line Transaction Processing). L’exploitation de données
tourné vers la saisie, le stockage, la mise à jour, la sécurité et l’intégrité des données. Le
système transactionnel est développé pour gérer les transactions quotidiennes. Ces bases de
données supportent habituellement des applications particulières telles que les inventaires
de magasins, les réservations d’hôtel, etc. Le contenu est fait de données actuelles, pas
d’archives. Les données sont très détaillées (détails de chacune des transactions). La mise
à jour s’effectue par de nouvelles transactions. Très souvent plusieurs de ces systèmes
existent indépendamment les uns des autres

Opérations dans les systèmes transactionnels

• Ajout
• Effacement
• Mise à jour des enregistrements
• Requêtes simples
• Interrogations et modifications fréquentes des données par de nombreux utilisateurs

Systèmes décisionnels
Le terme décisionnel « Business Intelligence » couvre l'ensemble des technologies
permettant en bout de chaîne d'apporter une aide à la décision.
Le système décisionnel est un Système d’Information (SI) capable d'agréger les données
internes ou externes et de les transformer en information servant à une prise de décision
rapide.
Ce SI est capable de répondre à certains types de questions:
- Quelles sont les ventes du produit X pendant le trimestre A de l'année B dans la région
C?
- Comment se comporte le produit X par rapport au produit Y? o Quel type de client peut
acheter le produit X?
- Est-ce qu'une baisse de prix de 10% par rapport à la concurrence ferait redémarrer les
ventes du produit X ?
Ces exemples mettent en évidence les faits suivants:
 - Les questions doivent pouvoir être formulées dans le langage de l’utilisateur en fonction
de son secteur d’activité:
◼ Service marketing, Service économique, service relation clients… o La prévision
des interrogations est difficile car elles sont du ressort de l’utilisateur.
- Les questions vont varier selon les réponses obtenues:
◼ Si le produit X s’est vendu moins bien que l’année précédente, il va être utile de
comprendre les raisons: Détailler les ventes par région par type de magasin,…
- Des questions ouvertes vont nécessiter la mise en place de méthodes d’extraction
d’informations
Des données aux décisions
- Données : Points de ventes, géographiques, démographiques,
- Informations : I vit dans R, I est âgé de A, …
- Connaissances : o Dans X%, le produit Y est vendu en même temps que le produit Z, …
- Décisions : Lancer la promotion de Y & Z dans R auprès des clients plus âgés que A,
...
Applications transactionnelles v.s Applications décisionnelles
Les applications transactionnelles sont constituées de traitements factuels de type OLTP (On
Line Transaction Processing) Les applications d'aide à la décision sont constituées de
traitements ensembliste de type OLAP: On Line Analytical Processing

Incompatibilités des deux activités

Les deux activités (OLTP & OLAP) ne peuvent co-exister sur des données dans le même
système d’information: leurs objectifs de performance sont exactement opposés:
- Les requêtes complexes et lourdes dégradent les performances des systèmes
transactionnels,
- Les données temporelles sont réparties entre données actuelles et données
archivées, rendant la vue historique des données très difficile ou impossible,
Le support efficace d’une activité OLAP nécessite la constitution d’un système d’information
propre: Le Datawarehouse
Naissance du Datawarehouse

Datawarehouse : Définition
- « Collection de données orientées sujets, intégrées, non volatiles et historisées,
organisées pour le support du processus d’aide à la décision »
- Base de données dans laquelle sont déposées après nettoyage et homogénéisation les
informations en provenance des différents systèmes de production de l’entreprise OLTP

Caractéristiques des données d'un DW

Orientées sujet : Organisées autour de sujets majeurs de
l’entreprise
- Données pour l’analyse et la modélisation en vue de l’aide à la décision, et non pas pour
les opérations et transactions journalières
- Vue synthétique des données selon les sujets intéressant les décideurs
Intégrées :
- Construit en intégrant des sources de données multiples et hétérogènes : BD
relationnelles, fichiers, enregistrements de transactions
- Les données doivent être mises en forme et unifiées afin d’avoir un état cohérent o
Phase la plus complexe (60 à 90 % de la charge totale d’un projet DW)
Historisées : Fournies par les sources opérationnelles, Matière
première pour l'analyse, Stockage de l'historique des données, pas
de mise à jour, Un référentiel temps doit être associé aux données
Non volatiles : Conséquence de l’historisation
- Une même requête effectuée à intervalle de temps, en précisant la date référence de
l’information donnera le même résultat
- Stockage indépendant des BD opérationnelles o Pas de mises à jour des données dans
le DW
Données multidimensionnelles
- Notion de dimension : C’est une catégorie linguistique selon
laquelle les données sont organisées: Nom d’un attribut,
Valeur d’un attribut
 Représentation :

Tableau simple Tableau croisé

Graphique 3D Hyper cube:

Notion de Datamart
Définition: « C'est un sous-ensemble de données dérivées du DW ciblé sur un sujet
unique».
Caractéristiques:
- Orienté vers un sujet unique. Ex: comportement de la clientèle
- Données fortement agrégées : Le DW joue le rôle de source et d'historique pour le
Datamart
- Organisation multidimensionnelle (cubique)
• Dont l'une des dimensions indique souvent le temps o Lien dynamique avec le
DW
• Association entre valeur agrégée et valeur détaillée
- Interfaces simples et conviviales

Les domaines d’application du décisionnel

• La gestion de la relation client (CRM) est l’un des premiers champs d’application de la
Business Intelligence.
• Le contrôle de gestion pour l’analyse des coûts, l’analyse de la rentabilité, l’élaboration
budgétaire, les indicateurs de performance…
 • La direction marketing pour le ciblage, le pilotage de gamme, les applications de
géomarketing, de fidélisation clients…
• La direction commerciale pour le pilotage des réseaux, les prévisions des ventes,
l’optimisation des territoires…
• Les ressources humaines pour la gestion des carrières,
• La direction de la production pour l’analyse qualité, la prévision des stocks, la gestion
des flux, la fiabilité industrielle…
• La direction générale pour les tableaux de bord, indicateurs de pilotage, gestion
d’alertes…

Exemple: un DW dans les télécoms

• Sujets :
o Suivi du marché: lignes installées/
désinstallées, services et options choisis,
répartition géographique, répartition entre
public et différents secteurs d'organisations
o Comportement de la clientèle o
Comportement du réseau
• Historique
o 5 ans pour le suivi du marché o 1 an pour le
comportement de la clientèle o 1 mois pour
le comportement du réseau
• Sources
o Fichiers clients élaborés par les agences o
Fichiers de facturation
• Requêtes
o Comportement clientèle
o Nombre moyen d'heures par client, par mois
et par région o Durée moyenne d'une
communication urbaine par ville o Durée
moyenne d'une communication
internationale
Architecture d’un Datawarehouse
Architecture centralisée

Il s’agit de la version centralisée et intégrée d’un entrepôt regroupant l’ensemble des

données de l’entreprise. Les différentes bases de données sources sont intégrées et sont
distribuées à partir de la même plate-forme physique
Architecture fédérée

Il s’agit de la version intégrée d’un entrepôt où les données sont introduites dans les
marchés de données orientés selon les différentes fonctions de l’entreprise

OLAP et Analyse multidimensionnelles

OLAP :
• « Il s’agit d’une catégorie de logiciels axés sur l’exploration et l’analyse rapide des
données selon une approche multidimensionnelle à plusieurs niveaux d’agrégation ».
• OLAP vise à assister l’usager dans son analyse en lui facilitant l’exploration de ses
données et en lui donnant la possibilité de le faire rapidement.
o L’usager n’a pas à maîtriser des langages d’interrogation et des interfaces
complexes o L’usager interroge directement les données, en interagissant avec
celles-ci
Modèle conceptuel
Approche multidimensionnelle o Souvent représentés par une
structure à plusieurs dimensions o Une dimension est un attribut ou
un ensemble d’attributs:

▪ Temps
▪ Géographie
▪ Produits
▪ Clients
o Les cellules contiennent des données agrégées appelées Faits ou Indicateurs:
▪ Nombre d’unités vendues
▪ Chiffre d’Affaire
▪ Coût
o Représentations:
▪ Relations,
▪ Cube de données,
▪ hyper cube de données

Vue multidimensionnelle

Agrégation des données

• Plusieurs niveaux d’agrégation o Les données peuvent être groupées à différents
niveaux de granularité o Les regroupements sont pré-calculés,
Par exemple, le total des ventes pour le mois dernier calculé à partir de la
somme de toutes les ventes du mois.
• Granularité : niveau de détail des données emmagasinées dans un
Datawarehouse
Granularité des dimensions

Opérations OLAP
Opérations sur la structure des cubes
• Pivot (Rotation)

• Switch (Permutation)

• Split (Décomposition

Opérations sur le contenu des cubes

• Roll-up (passage au grain supérieur) / Drill-down (passage au grain inférieur)
 • Slice (Restriction)

• Dice (Projection)

Opérations entre cubes

• Jointure

• Union
Exemple d’outils OLAP
• BusinessObjects, BusinessObjects : http://www.businessobjects.fr/
• SAS:
http://www.sas.com/offices/europe/france/software/technologies/olap/index.html
• HarrySoftware , HarryPilot, HarryCube :
http://www.harrysoftware.com/jahia/Jahia/pid/61

Modélisation et Conception d’un DWH

Construction d’un Datawarehouse

Caractéristiques:
• Le Datawarehouse est différent des bases de données de production:
o Les besoins pour lesquels on veut le construire sont différents
o Il contient des informations historisées, organisées selon les métiers de
l’entreprise pour le processus d’aide à décision
• Le Datawarehouse n’est pas un produit ou un logiciel mais un environnement, qui se
bâtit et ne s’achète pas.
Phases de construction d’un DW:
• Il y’a trois parties interdépendante qui relève la construction d’un Datawarehouse:
o L’étude préalable qui va définir les objectifs, la démarche à suivre, le retour sur
investissement,…
o L’étude du modèle de données qui représente le DW conceptuellement et
logiquement o L’étude de l’alimentation du Datawarehouse
Etude préalable

• Etude des besoins:

o Définir les objectifs du DW o Déterminer le contenu du DW et son organisation,
d’après:
▪ Les résultats attendus par les utilisateurs,
▪ Les requêtes qu’ils formuleront,
 ▪ Les projets qui ont été définie o Recenser les données nécessaires
à un bon fonctionnement du DW:
▪ Recenser les données disponibles dans les bases de production
▪ Identifier les données supplémentaires requises o Choisir les
dimensions
▪ Typiquement: le temps, le client, le produit, le magasin...
o Choisir les mesures de fait
▪ De préférences de quantités numériques additives o Choisir la
granularité des faits
▪ Niveau de détails des dimensions Coûts de déploiement:
o Nécessite des machines puissantes, souvent une machine parallèle o Capacité
de stockage très importante (historisation des données)
▪ Evaluer la capacité de stockage o Equipes de maintenance et
d’administration o Les coûts des logiciels
▪ Les logiciels d’administration du DW
▪ Les outils ETL (Extract-Transform- Loading)
▪ Les outils d’interrogation et de visualisation
▪ Les outils de Datamining
Modélisation
• Niveau conceptuel:
o Un DW est basé sur une modélisation multidimensionnelle qui représente les
données dans un cube
o Un cube permet de voir les données suivant plusieurs dimensions:
▪ Tables de dimensions
▪ La table des faits contient les mesures et les clés des
dimensions Niveau Logique:
o Plusieurs schémas types sont proposés pour représenter un DW:
▪ Schéma en étoile;
▪ Schéma en flocon;
• Schéma en étoile
o Une (ou plusieurs) table(s) de faits : identifiants des tables de dimension ; une
ou plusieurs mesures.
o Plusieurs tables de dimension : descripteurs des dimensions.
 • Schéma en flocons o Raffinement du schéma étoile avec des tables normalisées par
dimensions.

Alimentation
• L’alimentation est la procédure qui permet de transférer des données du
système opérationnel vers le DWH
• La conception de cette opération est une tâche complexe o 60 à 90 % de la
charge totale d’un projet DWH
• Elle doit être faite en collaboration avec l’administrateur des bases de
productions Il est nécessaire de déterminer:
o Quelles données seront chargées o Les transformations
et les vérifications nécessaires
o La périodicité et le moment de transferts des données
Alimentation d’un DWH (ETL)
• Extraction (Extract)
• Transformation (Transform) :
Filtrer, Homogénéiser, Nettoyer, Etc
…
• Chargement (Loading)
Extraction:
• Depuis les bases sources
• Périodique et Répétée
 • Dater ou marquer les données envoyées Difficulté:
o Ne pas perturber les applications OLTP Différentes
techniques d’extraction:
o Méthode Push: Le système opérationnel qui au fil des
transactions alimente le DWH o Méthode Pull : Le système
décisionnel cherche périodiquement les données dans les bases de
production
Transformation
C’est une suite d’opérations qui a pour but de rendre les données cibles homogènes et puissent
être traitées de façon cohérente.
- Unification des modèles
- Convertir / uniformiser les noms des attributs
- Uniformiser les valeurs d ’attributs
- Nettoyer ( Valeurs manquantes, aberrantes…)
Chargement
• C’est l’opération qui consiste à charger les données nettoyées et préparées dans le DW.
• C’est une opération qui peut être longue :
o Mettre en place des stratégies pour assurer de bonnes conditions à sa
réalisation o Définir la politique de rafraîchissement.
• C’est une phase plutôt mécanique et la moins complexe
Outils ETL
• BusinessObjects, Data Integrator,
• Talend Open Studio
• Oracle Corporation, Warehouse builder,
http://www.oracle.com/technology/products/warehouse/index.html/
• IBM, Websphere Datastage , http://www.ascential.com/products/datastage.html
 Chapitre 2 : Analyse de données
Les statistiques peuvent être vues en fonction de l'objectif fixé ; classiquement les
méthodes statistiques sont employées soit pour explorer les données (nommée statistique
exploratoire) soit pour prédire un comportement (nommée statistique prédictive ou
décisionnelle ou encore inférentielle). La statistique exploratoire s'appuie sur des techniques
descriptives et graphiques. Elle est généralement décrite par la statistique descriptive qui
regroupe des méthodes exploratoires simples, uni- ou bidimensionnelle (moyenne, moments,
quantiles, variance, corrélation, ...) et la statistique exploratoire multidimensionnelle. L'analyse
de données s'inscrit dans ce cadre de la statistique exploratoire multidimensionnelle. Nous
verrons que des méthodes issues de l'analyse de données peuvent également servir la statistique
prédictive.
L'Analyse de Données est un ensemble de méthodes mathématiques qui permettent
de traiter des "items" dans un tableau. Ces items sont décrit par un ensemble de variables.
L'objectif de l'Analyse de Données est de traiter des informations du type : quels sont les items
identiques ou dissemblables, quelles sont les relations entre les items et les variables associées.
Le plus souvent les résultats de ces analyses permettent d'ajuster et d'optimiser les
politiques ou stratégies commerciales des entreprises.
L'analyse de données fait toujours l'objet de recherche pour s'adapter à tout type de
données et faire face à des considérations de traitements en temps réel en dépit de la quantité
de données toujours plus importante. Les méthodes développées (et l'analyse de données) sont
maintenant souvent intégrées avec des méthodes issues de l'informatique et de l'intelligence
artifcielle (apprentissage numérique et symbolique) dans le data mining traduit en français par
« fouille de données » ou encore extraction de connaissance à partir de données.

Les données

Nous considérons tout d'abord que la population peut être décrite par des données de
deux types de caractères : qualitatif ou quantitatif. Les caractères qualitatifs peuvent être purs
(variables nominales) i.e. que les modalités ne possèdent pas de structure d'ordre ou ordonnés
(variables ordinales) i.e. que les modalités qualitatives sont ordonnées. Il est aisé de
comprendre que les données à caractère qualitatif doivent être adaptées pour les méthodes
numériques. Les méthodes d'analyse de données supposent souvent une organisation des
données particulière, naturelle, mais parfois difficile à réaliser selon l'application et les
données. Le choix d'un tableau permet une organisation dans le plan de toutes les données et
ainsi de traiter simultanément toute l'information. Ainsi la plupart des méthodes nécessitent
une organisation des données présentée par le suivant. Nous verrons plus tard que selon les
données ce tableau est quelque peu modifié, mais l'idée de tableau reste présente dans toutes
les méthodes d'analyse de données.
 Tableau : Représentation des données

Ainsi les observations ou individus ou encore unités statistiques sont représentés en

ligne et sont chacun décrits par des variables ou caractères. Nous conserverons les notations du
tableau précédent dans la suite du document. xij est donc la valeur de la variable k pour
l'individu i avec k = 1, …, K et i = 1, …, I. Par abus de notations, pour des considérations de
simplication de celles-ci, I représente à la fois le nombre d'individus et l'ensemble des individus
{1, …, i, …, I}, de même K représente le nombre de variables et l'ensemble des variables {1,
…, k, …, K}.
Cette représentation des données peut faciliter la lecture de petits tableau, i.e. lorsqu'il
y a peu de données. Cependant, dès lors que la taille du tableau est grand, ou que nous
recherchons des relations entre plus de deux individus ou plus de deux variables, cette
représentation et les techniques simples de la statistique descriptive ne su-sent plus.

Objectifs
Les objectifs que se sont fixés les chercheurs en analyse de données sont donc de
répondre aux problèmes posés par des tableaux de grandes dimensions. Les objectifs sont
souvent présentés en fonction du type de méthodes, ainsi deux objectifs ressortent : la
visualisation des données dans le meilleur espace réduit et le regroupement dans tout l'espace.
Les méthodes de l'analyse de données doivent donc permettre de représenter
synthétiquement de vastes ensembles numériques pour faciliter l'opérateur dans ses décisions.
En fait d'ensembles numériques, les méthodes d'analyse de données se proposent également de
traiter des données qualitatives, ce qui en fait des méthodes capables de considérer un grand
nombre de problèmes. Les représentations recherchées sont bien souvent des représentations
graphiques, comme il est difficile de visualiser des points dans des espaces de dimensions
supérieures à deux, nous chercherons à représenter ces points dans des plans. Ces méthodes ne
se limitent pas à une représentation des données, ou du moins pour la rendre plus aisée, elles
cherchent les ressemblances entre les individus et les liaisons entre les variables. Ces
proximités entre individus et variables vont permettre à l'opérateur de déterminer une typologie
des individus et des variables, et ainsi il pourra interpréter ses données et fournir une synthèse
des résultats des analyses. Nous voyons donc que les deux objectifs précédemment cités sont
très liés voir indissociables, ce qui entraîne souvent l'utilisation conjointe de plusieurs
méthodes d'analyse de données.

Méthodes

L'analyse de données regroupe deux familles de méthodes suivant les deux objectifs
cités précédemment :
- Une partie des méthodes cherche à représenter de grands ensembles de données par peu
de variables i.e. recherche les dimensions pertinentes de ces données. Les variables
ainsi déterminées permettent une représentation synthétique recherchée. Parmi ces
méthodes de nombreuses analyses sont issues de l'analyse factorielle, telles que
l'analyse en composantes principales (ACP), l'analyse factorielle des
correspondances (AFC), l'analyse factorielle des correspondances multiples, ou
encore l'analyse canonique.
L'analyse en composantes principales est l'une des méthodes les plus employées. Elle
est particulièrement adaptée aux variables quantitatives, continues, a priori corrélées
entre elles. Une fois les données projetées dans différents plans, les proximités entre
variables s'interprètent en termes de corrélations, tandis que les proximités entre
individus s'interprètent en termes de similitudes globales des valeurs observées.
L'analyse factorielle des correspondances (ou analyse des correspondances binaires) a
été conçue pour l'étude des tableaux de contingence obtenus par croisement de variables
qualitatives. Cette analyse permet donc de traiter des variables qualitatives et est surtout
adaptée à ce type de variables. Dans cette approche, les lignes et les colonnes ont un
rôle symétrique et s'interprètent de la même façon. L'analyse factorielle des
correspondances multiples est une extension de l'analyse factorielle des
correspondances qui ne permet que le croisement de deux variables qualitatives. Elle
est donc adaptée à la description de grands tableaux de variables qualitatives par
exemple pour le traitement d'enquêtes. L'analyse canonique est très peu utilisée en
pratique, son intérêt porte sur son aspect théorique. Elle cherche à analyser les relations
entre deux groupes de variables de nature différente. De ce fait l'analyse factorielle des
correspondances peut être vu comme analyse canonique particulière.
- Une autre partie des méthodes cherche à classer les données de manière automatique.
Ces méthodes sont complémentaires avec les précédentes pour synthétiser et analyser
les données et répondre plus particulièrement à l'objectif fixé de caractériser les
proximités entre individus et celles entre variables. Ces méthodes de classification sont
soit à apprentissage supervisé (i.e. qui nécessitent une base de données d'apprentissage
ces méthodes sont appelées en statistique les analyses discriminantes) soit à
apprentissage non-supervisée (i.e. qui ne nécessitent aucune donnée préalable).
 - Parmi les méthodes issues de l'analyse discriminante et directement rattachées à
l'analyse de données il y a l'analyse linéaire discriminante, la régression logistique,
les k plus proches voisins ou encore les arbres de décision. D'autres méthodes issues
de l'intelligence artificielle et du monde de la reconnaissance des formes peuvent être
rattachées à l'analyse discriminante telles que le perceptron multicouche (et les autres
réseaux de neurones) et les chaînes de Markov ou encore issues de la théorie de
l'apprentissage statistique telle que les machines à vecteurs de supports. Si ces
dernières ne sont pas toujours considérées comme faisant partie de l'analyse de données,
elles sont parfaitement intégrées dans le data mining.
L'analyse linéaire discriminante est aussi appelée analyse factorielle discriminante car
elle est en fait une analyse en composantes principales supervisée. Elle décrit les
individus en classes (celles-ci sont données par une variable issue de l'apprentissage) et
ensuite affecte de nouveaux individus dans ces classes. C'est donc une méthode à la fois
descriptive et prédictive. Elle permet de traiter aussi bien des variables quantitatives
que qualitatives.
La régression logistique consiste à exprimer les probabilités a posteriori d'appartenance
à une classe p(C=x) comme une fonction de l'observation.
L'approche des k plus proches voisins repose sur l'idée simple d'attribuer un nouvel
individu à la classe majoritaire parmi ses k plus proches voisins (individus de la base
d'apprentissage les plus proches au sens d'une certaine distance).
Les arbres de décision nécessitent souvent une construction délicate et difficilement
généralisable si les données d'apprentissage sont peu représentatives de la réalité. La
méthode CART (Classification And Regression Tree) possède une construction d'arbre
aux propriétés intéressantes pour la segmentation.
- Les méthodes de classification automatique ne nécessitant pas d'apprentissage offrent
un intérêt important lorsque les données sont complètement inconnues. Elles permettent
ainsi de dégager des classes qui ne sont pas évidentes a priori. Les deux principales
méthodes développées sont la méthode des centres mobiles (apparentée à la méthode
des k-means ou des nuées dynamiques (comme un cas particulier)) et la classification
hiérarchique ascendante ou descendante. Nous pouvons également citer les approches
fondées sur les graphes et hypergraphes.
La méthode des centres mobiles consiste à associer les individus à des centres de classes
choisis aléatoirement, puis à recalculer ces centres jusqu'à obtenir une convergence. La
difficulté consiste dans un choix astucieux des centres au départ pour une convergence
plus rapide et dans le choix d'une distance appropriée. La classification hiérarchique
ascendante (resp. descendante) consiste à regrouper les individus selon leur
ressemblance (resp. dissemblance). Toute la difficulté est dans la définition d'une
mesure de ressemblance et de la distance associée.
Ci-dessous nous donnons le principe général de deux des méthodes d’analyse de données les
plus populaires.

Analyse en Composantes Principales

L’analyse en composantes principales (ACP) sert à mettre en évidence des similarités

ou des oppositions entre variables et à repérer les variables les plus corrélées entre elles.
 Ces variables sont par exemple des concentrations hebdomadaires ou bihebdomadaires
mesurées pendant plusieurs périodes successives sur un ensemble de tubes. A ces
concentrations peuvent s’ajouter des variables auxiliaires connues, migrées ou interpolées en
ces mêmes tubes.
Dans l’exemple de la figure suivante, les variables introduites dans l’ACP sont quatorze
concentrations hebdomadaires d’ozone, la concentration moyenne qui en résulte, les
coordonnées de l’espace x et y, l’altitude et la densité de population. Les valeurs de ces
variables sont connues en au moins 25 des 32 points d’échantillonnage. En raison de leur
hétérogénéité, ces variables sont préalablement centrées et réduites (cette opération est
effectuée automatiquement par Isatis).

Principe de l’ACP
L’ACP consiste à remplacer une famille de variables par de nouvelles variables de
variance maximale, non corrélées deux à deux et qui sont des combinaisons linéaires des
variables d’origine. Ces nouvelles variables, appelées composantes principales, définissent des
plans factoriels qui servent de base à une représentation graphique plane des variables initiales.
L’interprétation des résultats se restreint généralement aux deux premiers plans factoriels, sous
réserve que ceux-ci expliquent la majeure partie de la variance du nuage des variables initiales.

Interprétation des résultats de l’ACP

En ACP normée, les variables projetées sur chaque plan factoriel se trouvent à
l’intérieur d’un cercle de rayon unité. Plus une variable est projetée vers le bord du cercle,
mieux elle est représentée. Par ailleurs, deux variables bien représentées et proches l’une de
l’autre sont corrélées positivement tandis que deux variables qui s’opposent sont corrélées
négativement. Une orthogonalité entre deux variables traduit l’absence de corrélation linéaire.
Notons que l’ACP ne mesure que des liens linéaires entre variables Avant de conclure
sur l’existence ou l’absence de relations entre variables, il est donc utile d’examiner l’allure de
leurs nuages de corrélation.
Le diagramme en haut à droite de la figure suivante indique le pourcentage de l’inertie
totale du nuage des variables porté par chaque axe factoriel. Ce pourcentage est respectivement
de 66%, 10% et 5% pour les trois premiers axes qui sont retenus pour la représentation
graphique. La première composante principale sépare les variables de concentration
(concentration moyenne, minimale et maximale et concentrations des quatorze semaines) de la
densité de population. Compte tenu des différences de concentration entre ville et campagne,
cette opposition était prévisible. On observe de plus une corrélation positive entre la
concentration d’ozone et l’altitude. Aucune corrélation n’apparaît avec les coordonnées de
l’espace.
Les autres composantes sont essentiellement liées à la position géographique des tubes
passifs, représentée par les coordonnées X et Y, et à la densité de population. Cela se vérifie
aisément en examinant le plan F2-F3 dans lequel toutes les variables de concentration sont
projetées vers le centre du cercle.
 Notons que le nuage des variables de concentration associées aux quatorze semaines de
mesure est dispersé autour de la concentration moyenne. Quelques périodes se démarquent,
telle la semaine 8 qui correspond à une chute des concentrations liée à une diminution brutale
de température.

Figure : Exemple d’ACP. Données d’ATMO Auvergne : 14 semaines consécutives de mesure

de l’ozone (été 2001) et variables auxiliaires. Projection du nuage des variables sur les deux
premiers plans factoriels

Analyse Factorielle de Correspondances

L'Analyse Factorielle des Correspondances (ou analyse des correspondances binaires) a été
conçue pour l'étude des tableaux de contingence obtenus par croisement de variables qualitatives.
Cette analyse permet donc de traiter des variables qualitatives et est surtout adaptée à ce type de
variables. Dans cette approche, les lignes et les colonnes ont un rôle symétrique et s'interprètent de
la même façon. L'Analyse Factorielle des Correspondances Multiples est une extension de l'analyse
factorielle des correspondances qui ne permet que le croisement de deux variables qualitatives. Elle
est donc adaptée à la description de grands tableaux de variables qualitatives par exemple pour le
traitement d'enquêtes.

Principe de l’AFC

Le principe de ces méthodes est de partir sans a priori sur les données et de les décrire
en analysant la hiérarchisation de l'information présente dans les données. Pour ce faire, les
analyses factorielles étudient l'inertie du nuage de points ayant pour coordonnées les valeurs
présentes sur les lignes du tableau de données.
La « morphologie du nuage » et la répartition des points sur chacun de ces axes d'inertie
permettent alors de rendre lisible et hiérarchisée l'information contenue dans le tableau.
Mathématiquement, après avoir centré et réduit le tableau de données que l'on a affecté d'un
système de masse (par exemple, les sommes marginales de chaque ligne), on calcule la matrice
d'inertie associée et on la diagonalise (la répartition de l'information selon les différents axes
est représentée par l'histogramme des valeurs propres). On effectue alors un changement de
base selon ses vecteurs propres, c'est-à-dire selon les axes principaux d'inertie du nuage de
points. On projette alors les points figurant chaque ligne sur les nouveaux axes. L'ensemble de
l'information est conservée, mais celle-ci est maintenant hiérarchisée, axe d'inertie par axe
d'inertie. L'histogramme des valeurs propres permet de voir le type de répartition de
l'information entre les différents axes et l'étendue en dimension de celle-ci.
Le premier axe d'inertie oppose les points, c'est-à-dire les lignes du tableau ayant les
plus grandes distances ou « différences ». La première valeur propre d'inertie, (associée à ce
premier axe) mesure la quantité d'information présente le long de cet axe, c'est-à-dire dans cette
opposition. On analyse ainsi les différents axes, en reconstituant progressivement la totalité des
données.
Plusieurs méthodes d'analyse des correspondances existent, qui diffèrent par le type de
représentation de l'information, c'est-à-dire de métrique, ou de système de masse qu'elles
utilisent.
L'analyse factorielle des correspondances AFC développée par Jean-Paul Benzecri et
ses collaborateurs emploie la métrique du chi-deux : chaque ligne est affectée d'une masse qui
est sa somme marginale, le tableau étudié est le tableau des profils des lignes, ce qui permet de
représenter dans le même espace à la fois les deux nuages de points associés aux lignes et aux
colonnes du tableau de données ; elle est par ailleurs très agréablement complétée par des outils
de classification ascendante hiérarchique (CAH) qui permettent d'apporter des visions
complémentaires, en particulier en construisant des arbres de classification des lignes ou des
colonnes.
Pour chaque point représentatif des lignes ou des colonnes du tableau de données,
nouvel axe par nouvel axe, on s'intéresse à ses nouvelles coordonnées, au cosinus carré de
l'angle avec l'axe (ce qui est équivalent à un coefficient de corrélation), ainsi qu'à sa
contribution à l'inertie expliquée par l'axe (c'est-à-dire à sa contribution à la création de l'axe).
Deux contraintes particulières sur les données sont à signaler : d'une part, les tableaux
ne peuvent comporter de cases vides et d'autre part, seules des valeurs positives sont permises.
De plus, compte tenu de la métrique du chi-deux employée par l'AFC, cette méthode accorde
une importance plus grande aux lignes de somme marginale élevée. Si nous utilisons des
tableaux quantitatifs et souhaitons équilibrer la contribution de chaque ligne au calcul de
l'inertie, nous devons transformer le tableau pour assurer à chaque ligne une somme marginale
égale. Pour ce faire, on peut dédoubler chaque ligne, en lui adjoignant un tableau de
complément. À chaque valeur fij, on fait correspondre une valeur dédoublée k-fij, avec k ⩾
max(fij).
Par l'AFC, il est tout autant possible d'analyser des tableaux contenant des mesures
quantitatives que des indications qualitatives, (par exemple une donnée « couleur »), ces deux
types ne pouvant être mélangés. Un cas particulier de la deuxième catégorie de tableau est
constituée par les tableaux « disjonctifs » ; plusieurs variables constituent les colonnes : elles
sont toutes découpées en plusieurs modalités, dont une et une seule est vraie par individu. Lors
d'une analyse factorielle, on peut rajouter des données « supplémentaires », c'est-à-dire que l'on
ne fait pas intervenir dans le calcul de l'inertie, mais que l'on projette sur les axes.

Les logiciels

Les méthodes d'analyse de données nées de la recherche universitaire sont depuis

longtemps entrées dans le monde industriel. Il y a cependant peu de logiciels qui savent intégrer
ces méthodes pour une recherche exploratoire aisée dans les données. Nous citons ici cinq
logiciels :
- SAS :
Ce logiciel est un logiciel de statistique très complet et très performant. Il a d'abord été
développé pour l'environnement Unix, mais est maintenant accessible sous tout
environnement. Il permet une puissance de calcul importante et ainsi est très bien adapté
à tous traitements statistiques sur des données très volumineuses. Son manque de
convivialité et surtout son prix fait qu'il est encore peu employé dans les entreprises qui
ne se dédient pas complètement à la statistique. De nombreux cours universitaires de
statistique sont proposés avec ce logiciel qui s'approche d'un langage (ex. Université de
Rennes 1).
- Splus :
Splus est à la fois un langage statistique et graphique interactif interprété et orienté
objet. C'est donc à la fois un logiciel statistique et un langage de programmation. La
particularité de ce langage est qu'il permet de mélanger des commandes peu évoluées à
des commandes très évoluées. Il a été développé par Statistical Sciences autour du
langage S, conçu par les Bell Laboratories. Depuis, Splus est devenu propriété de
Mathsoft après le rachat de Statistical Sciences. Il est parfois employé pour
l'enseignement.
- R:
Ce logiciel est la version gratuite de Splus. Il est téléchargeable sous www.r-project.org
pour tous systèmes d'exploitation. Il soffre également de peu de convivialité et semble
 encore très peu employé en industrie. De part sa gratuité, il est de plus en plus employé
pour la réalisation de cours de statistiques.
- Le langage Python est largement employé en STM mais également en SHS. En plus de
modules (on parle également de librairies) d’analyse statistique, il permet aussi de
travailler sur de grandes bases de données (lien avec le langage SQL) mais aussi
d’appliquer un ensemble d’algorithmes (suite d’instructions logiques compréhensibles
par une machine) issu du machine learning. Python peut être employé en ligne de
commande ou bien via différentes applications notamment les jupyter notebook.
- XlStat :
Excel propose une macro payante permettant d'exectuer quelques méthodes d'analyse
de données. Elle est cependant très limitée, utilisable qu'avec Excel sous Windows et
de plus payante. Certaines écoles d'ingénieurs s'en contentent.
- UniWin Plus :
Statgraphics est un logiciel de statistiques générales, qui propose un module d'analyse
de données de treize méthodes. Développé uniquement pour les environnements
Windows, l'accent est porté sur les interfaces graphiques. Statgraphics propose un grand
nombre d'analyses statistiques et permet l'utilisation de beaucoup de format de données.
Il est commercialisé par Sigma Plus. Statgraphics est enseigné par exemple à l'IUT de
Vannes.
- Stalab :
Ce logiciel développé par M. Jambu était initialement prévu pour Windows. Sa
convivialité a permis un essor industriel qui semble s'être réduit. Il a été utilisé pour
l'enseignement en écoles d'ingénieurs.
- SPAD :
Le logiciel SPAD supporté entre autre par A. Morineau est toujours maintenu à jour
avec de nouvelles méthodes issues de la recherche universitaire. Sa version sous
Windows est conviviale ce qui a poussé son achat par de plus en plus d'industriels. Le
soucis de coller à une réalité industrielle fait qu'il est employé en enseignement (ex.
IUT de Vannes, ENSIETA).

Domaine d’applications

Aujourd'hui les méthodes d'analyse de données sont employées dans un grand nombre
de domaines qu'il est impossible d'énumérer. Actuellement ces méthodes sont beaucoup
utilisées en marketing par exemple pour la gestion de la clientèle (pour proposer de nouvelles
o res ciblées par exemple). Elles permettent également l'analyse d'enquêtes par exemple par
l'interprétation de sondages (où de nombreuses données qualitatives doivent être prises en
compte). Nous pouvons également citer la recherche documentaire qui est de plus en plus utile
notamment avec internet (la di-culté porte ici sur le type de données textuelles ou autres). Le
grand nombre de données en météorologie a été une des première motivation pour le
développement des méthodes d'analyse de données. En fait, tout domaine scienti que qui doit
gérer de grande quantité de données de type varié ont recours à ces approches (écologie,
linguistique, économie, etc) ainsi que tout domaine industriel (assurance, banque, téléphonie,
etc). Ces approches ont également été mis à profit en traitement du signal et des images, où
elles sont souvent employées comme prétraitements (qui peuvent être vus comme des filtres).
En ingénierie mécanique, elles peuvent aussi permettre d'extraire des informations
intéressantes sans avoir recours à des modèles parfois alourdis pour tenir compte de toutes les
données.

Chapitre 3 : Le big data dans les organisations

Depuis le début de l'informatique personnelle dans les années 1 980, jusqu'à
l'omniprésence du Web actuelle dans la vie de tous les jours, les données ont été produites en
quantités toujours croissantes. Photos, vidéos, sons, textes, logs en tout genre... Depuis la
démocratisation de l'Internet, ce sont des volumes impressionnants de données qui sont créés
quotidiennement par les particuliers, les entreprises et maintenant aussi les objets et machines
connectés. Désormais, le terme « Big Data » , littéralement traduit par « grosses données » ou
« données massives » désigne cette explosion de données. On parle également de « datamasse
» en analogie avec la biomasse, écosystème complexe et de large échelle. À titre d'exemple, le
site Planetoscope (http://www.planetoscope.com) estime à 3 millions le nombre d'e-mails
envoyés dans le monde chaque seconde, soit plus de 200 milliards par jour en comptant les
spams qui représentent presque 90 % des flux, et ce pour une population d'internautes qui
avoisine les 2 ,5 milliards d'individus. En 2010, le zettaoctet de données stockées dans le monde
a été dépassé et on prévoit en 2020 10 Zo (zettaoctets), soit1 0 400 milliards de gigaoctets de
données déversés tous les mois sur Internet.
L'ambition clairement formulé e du Big Data a rendu les entreprises impatientes
d'atteindre le Graal de la valeur tant vanté par les acteurs du Web. Ce chapitre décrit les
principaux changements inhérents à la révolution numérique dans les entreprises et en quoi,
celles-ci doivent se réorganiser pour optimiser l'accès à l'information, aussi bien en interne
qu'en externe.

La recherche de l’innovation

L'entreprise dans un écosystème

Le paysage autour de l'entreprise a radicalement changé. À la fois dans les informations
qu'elle requiert et les informations qu'elle doit fournir pour exister dans un écosystème
économique et social où elle se doit d'être présente et ré active pour se développer. La notion
de proximité numérique avec les clients est inscrite dans de nombreux plans stratégiques. C'est
une vraie rupture culturelle qui a bousculé les repères qu'ils soient dans l'entreprise comme
chez ses clients.
 L'entreprise à l'ère du numérique devient de plus en plus ouverte aux flux
d'informations, de façon directe ou indirecte (ne serait-ce que par ses collaborateurs). Il est
attendu de plus en plus de la part de l'entreprise une contribution numérique au devenir citoyen,
de la même manière que ses actions pouvaient, il y a trente ans, contribuer au développement
de l'économie nationale. Progressivement le réel enjeu des données est compris non seulement
comme un moyen de simplifier le contact avec ses partenaires, ses prospects ou ses clients mais
également comme le moyen d'acquérir des données nécessaires à la compréhension des grandes
tendances de société.

Une volonté de maîtrise

Ces données, de plus en plus d'entreprises cherchent à les exploiter dans de nombreux
domaines : personnalisation de leur relation client, marketing ciblé, traçabilité des parcours et
retours clients, pilotage et valorisation de leur image sur les réseaux sociaux, optimisation des
processus logistiques... ces données constituent un gisement d'informations au potentiel quasi
illimité, à condition de pouvoir les maîtriser. Or les outils traditionnels ne suffisent plus.
Formatées sur le traitement de données dites structurées, les applications, qui
jusqu'alors donnaient satisfaction, sont devenues impuissantes devant la diversité des données
à traiter : origines diverses sous formes de texte, mais aussi sons, images, vidéos, sites web et
blogs aux formats très variés.

Des besoins forts

Les éditeurs qui ont compris ce bouleversement et ces nouveaux besoins, ont commencé
à regarder du côté du calcul scientifique pour traiter toutes ces données avec le maximum
d'efficacité. Pour le marketing, de nouvelles méthodes ont permis de stocker indifféremment
des formats, presque de manière brute, principalement pour offrir des possibilités de
recouvrements avec des données issues de processus complètement différents (réseau des
boutiques, parcours sur le web, fréquentation des sites, échanges téléphoniques, dossiers
clients, etc.). Cela a permis d'établir des regroupements d'informations totalement nouveaux et
constituer des profils opportunistes sur les clients, sur leur potentiel, leurs projets et leurs
envies.
Les exemples ne manquent pas dans la presse décrivant des entreprises qui ont assemblé
des données de plusieurs sources et peuvent désormais proposer à leurs clients un ciblage des
offres (réduction, abonnement) en fonction de leur localisation, à proximité d'une galerie
commerciale par exemple et cela, grâce au Big Data.

L’avancé par le cloud

Un des facteurs importants dans l'émergence du Big Data est le cloud computing qui a
grandement facilité l'accès aux infrastructures. Basé sur des ressources ajustables, par durée
identifiée et à un coût plus adapté, le cloud computing a ouvert de nombreuses portes aux
projets innovants en abaissant considérablement le coût du ticket d'entrée sur ces solutions.
 Place est faite aux expérimentations, aux POC (Proof of Concept) sur plateformes
performantes qui permettent d'essayer certains traitements, certains recoupements et
transformations, sans (trop) ponctionner le budget de la DSI.
Lieu de convergence des données d'origines très diverses (météo, localisation,
économie, tendances multiples), le cloud a fait entrer l'entreprise dans des domaines de
croisement et d'études rarement tentés par le passé, en combinant l'analyse de la mesure plus
ou moins poussée, pour aborder celui fascinant de la prédiction.

La création de la valeur
Deux manières de créer de la valeur grâce au Big Data sont :
- La conception de nouveaux produits. Les grands acteurs du Web aujourd'hui sont des
exemples suivis par des centaines de startups en Europe et aux USA. Les domaines
touchés sont immenses et même dans des métiers connus, ces produits peuvent apporter
une étendue de vision et de justesse très appréciée, comme dans le domaine bancaire
ou celui de l'assurance en fournissant le produit réellement attendu par le public.
- L'angle analytique en élargissant le champ d'investigation à des données qui n'étaient
pas accessibles sur d'autres outils. Par exemple, la mise en relation de données
disponibles sur des réseaux plus personnels (réseaux sociaux) pour déterminer
l'écosystème autour du client, son réseau, ses influences et celui des ventes potentielles
en le reliant avec le contexte géographique et la proximité du réseau des magasins.
C'est-à-dire construire les conditions favorables pour assurer le meilleur accueil du
produit auprès du client.
Le déploiement de tels outils ne peut se faire sans effort. L'émergence du Big Data en
entreprise doit impérativement bénéficier de changements culturels profonds afin qu'il soit un
succès (la section 2.7 reviendra sur le sujet).
La promotion des valeurs telles que celles de l'agilité et la flexibilité est indispensable,
alors que souvent elles sont opposées aux modes d'organisations pyramidales actuels.
L'innovation portée par ces approches Big Data doit reposer sur l'ambition et la confiance des
structures managériales.
Les cycles courts de test doivent stimuler la créativité dans les équipes et de nombreux
efforts doivent être maintenus pour sortir de la culture de l'échec trop souvent présente dans les
entreprises françaises. C'est à ce prix que de nouvelles opportunités s'offriront aux équipes
s'attelant aux défis du Big Data.

Les « 3V » du Big Data

Afin de mieux cerner les caractéristiques du Big Data des spécialistes d'IBM ont
proposé trois propriétés qui les caractérisent à des degrés divers, il s'agit du volume, de la
vélocité et de la variété. On les appelle communément les 3V. D'autres dimensions sont
fréquemment rajoutées, mais on ciblera ici la présentation sur ces trois propriétés.
Le volume
L'une des technologies aujourd'hui couramment utilisées pour y faire face est le
framework Hadoop. Le sujet sera abordé en détail aux chapitres 4 et 9. Disons simplement ici
que le stockage est assuré par un système de fichiers distribué appelé HDFS et que la
parallélisation des traitements exploite un pattern appelé MapReduce. Tous les problèmes de
parallélisation ne peuvent exploiter l'algorithme MapReduce, mais lorsque c'est le cas, celui-ci
offre un e scalabilité quasi infinie. Hadoop est aujourd'hui un projet de la fon dation Apache.
La version 2.0 de Hadoop réutilise la gestion distribuée des ressources développées pour
exécuter MapReduce pour permettre l'exécution d'autres schémas de calcul, plus généraux.
Hadoop est aujourd'hui disponible dans le cloud, la solution Elastic Map Reduce de Amazon
est un exemple.

La vélocité

Au cœur du Time To Market

La vélocité ou vitesse de circulation des données a connu une évolution similaire à celle
du volume au sein des entreprises. Co texte économique et évolution de la technologie, les
entreprises se trouvent de plus en plus au milieu d'un flux continuel de données, qu'il soit in
terne ou externe.
Rien de bien nouveau pour certains métiers comme celui de la fin an ce, où le trading,
par exemple, tire de la vélocité un avantage concurrentiel fondamental qui permet chaque jour
de prendre une longueur d'avance dans la décision, source de gains financiers. Le temps réel
est déjà là, depuis plusieurs années dans ces familles de métiers, bien installé. Le sujet sera
abordé en détail aux chapitres 11 et 12.

Au service des clients

Le paramètre vélocité est déterminant dans les situations où il s'agit de tenir compte en
temps réel des souhaits exprimés par un client et de l'état de disponibilité du stock pour fournir
le meilleur service possible. Dans d'autres situations on pourra utiliser des données de
géolocalisation pour guider un client vers un magasin moins exposé aux problèmes de
circulation ou pour lui offrir des services de proximités.

La variété
L'une des grandes ambition s du Big Data est de proposer le recoupement
d'informations ou la mise en correspondance de données d'origines très diverses. Ce serait
même l'une des principales sources de valeur. Pourtant, il ne faut pas se leurrer, parmi les 3V
c'est le seul pour lequel il n'existe à l'heure actuelle aucune méthode universelle. C'est sans nul
doute le problème le plus épineux car le traitement et le recoupement de données de sources et
de formats variés demandent une étude adaptée à chaque situation.
 Un exemple typique d'utilisation de données hétéroclites est celui d'un croisement entre
des données contenues dans un CRM (gestionnaire de la relation client), des données de
géolocalisation, des données extraites d'un réseau social qui, collectivement, permettront
d'enrichir un profil utilisateur avec des informations à caractère affectif très souvent corrélées
au déclenchement d'un acte d'achat.
Pour faire face à cette diversité de structures, certains systèmes NoSQL (voir le chapitre
3) utilisent des schémas de données qui s'écartent du modèle relationnel classique. Les bases
orientées graphes ou les bases orientées colonnes sont des exemples.
La prise en compte de la diversité des formats de données fera typiquement partie de la
phase de préparation des données.

Figure : Le Big Data à l’intersection des trois « V ».

Un champ immense d’application

Voici quelques exemples d'applications du Big Data en entreprise. La liste est loin d'être
exhaustive :
Analyser les données en mouvement
- La surveillance d'un grand nombre de nœuds de données (cloud, hébergement,
traitements répartis).
- La sécurité électronique et la détection de fraude dans un contexte banque assurance.
- Le suivi en temps réel et à forte réactivité de clients (commerce de détail,
téléassistance).
- Le pilotage avancé de systèmes complexes (recherche en astronomie et en physique des
particules, domaine spatial, forces armées).
- L'analyse des logs (voir chapitre 10) et surveillance des processus.
- Le tracking des identifiants, connexions et pistage des transports (avec le RFID par
exemple).
 - La logistique avancée avec ou sans contact physique.
Analyser une grande variété de données
- Le décodage et l'analyse des humeurs sur les réseaux sociaux ou dans la blogosphère.
- L'accostage avec la stratégie d'entreprise. Le suivi de phénomènes propagés (santé :
épidémies, intrusions, ingénierie sociale, terrorisme).
- L'analyse multimédia à partir de formats vidéo, audio, texte, photos (sécurité,
traductions, médiamétrie).
Traiter un volume conséquent de données
- Rapprochement d'objets métiers : produits, clients, déploiement, stocks, ventes,
fournisseurs, lieux promotionnels.
- Détection de fraudes, repérage de clients indélicats ou manipulateurs.
- Toxicité, défense des intérêts d'un groupe, feedback de crise.
- Management du risque, prise de décision sensible appuyée de modèles prévisionnels.
- Analyse de contexte, d'environnement.
Découvrir et expérimenter
- Approcher la notion de désir ou de sentiment déclencheur d'action.
- Cerner l'entourage social d'un client, les conditions favorables.
- Expérimenter l'impact d'un nouveau produit, son ressenti.
- Mesurer l'efficacité d'une stratégie de conquête, mesurer des écarts ou des erreurs de
positionnement d'image.
- Profilage de nouveaux comportements.
- Identification de nouveaux indicateurs d'influence.

Exemples de compétences à acquérir

Les paragraphes qui suivent illustrent quelques exemples de compétences qu'une

société pourra être amenée à acquérir pour faire du Big Data. Il serait vain de vouloir en donner
une liste exhaustive mais les exemples qui suivent aideront à s'en faire une idée.

- Appréhender de nouveaux modèles de traitement des données

- Maitriser le déploiement de Hadoop ou utiliser une solution cloud
- Se familiariser avec de nouvelles méthodes de modélisation
- Découvrir de nouveaux outils d'analyse de données
 Chapitre 4 : Les bases de données NoSQL

Apparus dans le sillage du mouvement Big Data, les systèmes NoSQL sont des
systèmes stockage d'un genre nouveau. Ce chapitre décrit le contexte historique dans lequel
ils sont apparus, comment et dans quelle mesure ils parviennent à résoudre les problèmes
spécifiques au Big Data. Leurs caractéristiques seront comparées à celles des SGBDR
classiques. Nous décrirons ensuite quatre catégories de systèmes NoSQL : les entrepôts
clé,valeur, les bases orientées documents, les bases de données orientées colonnes et enfin les
bases de données orientées graphes. L'accent est mis sur la compréhension des différents
modèles de données et sur les compromis qu'ils impliquent en termes de disponibilité, de
performance et de tolérance aux pannes. Des exemples d'usages seront proposés à chaque fois.

Bases de données relationnelles

Le but de cette section est de comprendre les raisons qui expliquent la domination,
quasiment sans partage depuis quarante ans, des prédécesseurs du NoSQL: les bases de
données relationnelles (SGBDR)).
De manière assez surprenante les fondements conceptuels des bases de données
relationnelles furent essentiellement l' œuvre d'un seul individu : E. F. Codd (19232 003) qui,
en 1970, publia un article intitulé « A Relational Madel of Data for Large Shared Data Banks
». Ignorés dans un premier temps par les équipes d'IBM, les travaux de Codd inspirèrent en
revanche Larry Ellison qui fonda Oracle. La suite de l'histoire est connue. Le succès originel
du modèle relationnel ne doit rien au hasard. En réalité, son origine est mathématique.
Paraphrasant L. Kronecker, un mathématicien du XIXe siècle qui forgea l'aphorisme célèbre «
God made the integers, all else is the work of man », R. Ramakrishnan, l'auteur d'un manuel
sur les bases de données relationnelles, proposa le jeu de mot (intraduisible) « Codd made
relations, all else is the work of man » . Ce clin d'œil a pour but d'attirer l'attention sur ce qui
fait la spécificité du modèle relationnel inventé par Codd. Son fondement n'est pas une
technologie, inévitablement vouée à l'obsolescence, mais une série de théorèmes qui décrivent
une structure mathématique intemporelle appelée algèbre des relations. Les principaux
éléments de cette algèbre ne sont autres que les opérations bien connues des informaticiens, la
sélection, la projection, l'agrégation, l'union, la jointure, etc. qui opèrent sur données
structurées en tables pour en créer de nouvelles.
 Figure : Les principales opérations de l’algèbre de relations
La notion de jointure est particulièrement importante puisque c'est elle qui permet de
relier entre eux des enregistrements situés dans des tables différentes et de le faire
implicitement, au moyen de clés étrangères, plutôt qu'à l'aide de pointeurs explicites. Elle est
au cœur des principes de normalisation des données et de la flexibilité du modèle relationnel.
Utilisées en cascade, les jointures peuvent cependant rapidement s'avérer très gourmandes en
ressources. Pour cette raison, leur usage sera remis en question par les systèmes NoSQL.

Un modèle de données est défini schématiquement par trois éléments

Une structure : plus précisément la structure logique selon laquelle les données sont enregistrées
sur disque. Dans le cas des SGBDR par exemple, il s'agit de tables constituées de lignes et de
colonnes. Pour une base de données de type document il s'agit d'une collection de documents aux
formats JSON ou XML indexés par une clé. Pour une base de données objet la structure est celle
d'une collection de grappes et des hiérarchies d'objets, etc.

Des contraintes : elles définissent les données que l'on considère valides. À titre d'exemple, une
contrainte pour un SGBDR est que tous les enregistrements possèdent impérativement les mêmes
colonnes. Le schéma d'un SGBDR contient la description de toutes les contraintes, qu'il s'agisse de
limites sur des valeurs numériques, de la syntaxe admise pour des chaînes de caractères ou
d'intégrité des références.

Des opérations : elles définissent comment on lit les données, com ment on les met à jour et
comment les supprime. Dans le cas d'un SGBRD et à un haut niveau d'abstraction, elles sont
définies par le langage de requêtes SQL. Au niveau de l'implémentation, il s'agira plutôt des
opérations de l'algèbre relationnelle. Pour une base de données orientée graphe, une opération
pourra consister à récupérer, par exemple, tous les parents d'un certain nœud.

Les règles de l'algèbre usuelle, celles qui permettent par exemple de transformer une
formule faisant appel à quatre opérations élémentaires, sont utiles car elles permettent de
simplifier une expression a priori complexe comme x - (y/y) - x + 1 en une autre beaucoup,
plus simple, 0 en l'occurrence. De manière similaire, l'étude de l'algèbre des relations effectuées
par Codd a démontré qu'il est possible de transformer une succession d'opérations en une autre,
équivalente, non pour la simplifier, mais pour optimiser les ressources utilisées comme le temps
de calcul et la quantité de mémoire utilisée. Les SGBDR prennent en charge cette tâche
d'optimisation du plan d'exécution. Le problème est complexe et des années de R&D ont été
investies par les éditeurs pour parvenir à des solutions à la fois robustes et performantes.
La valeur ajoutée d'un SGBDR ne se limite pas cependant à ce travail d'optimisation
puisqu'un développeur n'a nullement à se soucier d'écrire des relations algébriques. Plus
simplement, il utilise un langage déclaratif qui lui permet de spécifier la réponse qu'il cherche
plutôt que la manière d'effectuer cette recherche. C'est le rôle du langage SQL devenu depuis
lors un quasi standard dans l'industrie informatique.

SELECT DISTINCT c.nom FROM Clients c

WHERE Pays=’Cameroun’
AND City=’Dschang’

Les SGBDR, enfin, gèrent les transactions. Une transaction correspond par exemple à
un transfert d'argent entre deux comptes bancaires ou à la réservation d'un billet d'avion et d'une
chambre d'hôtel. Réalisée comme une succession d'opérations sur une ou plusieurs bases de
données, son rôle est de garantir que, soit toutes les opérations qu'elle englobe sont effectuées
avec succès, soit qu'aucune opération n'est effectuée. Les transactions, tout comme les
contraintes d'intégrité imposées par le schéma du SGBDR, contribuent ainsi à garantir la
cohérence des données hébergées.
Les exigences qui caractérisent une transaction SGBDR sont définies par le célèbre
acronyme ACID. Rappelons-en brièvement la signification :
- Atomicité : désigne le caractère indivisible d'une transaction évoqué plus haut.
- Cohérence : désigne l'objectif même des transactions, à savoir laisser les données dans
un état cohérent.
- Isolation : deux transactions simultanées A et B n'interfèrent jamais. La transaction B
ne peut ni voir ni modifier les données sur lesquelles A opère tant que A n'a pas été
validé.
- Durabilité : une fois une transaction validée, les données doivent être permanentes.
Ces facteurs à eux seuls ne suffisent pas cependant à expliquer le demi-siècle d'hégémonie
des SGBDR. Des facteurs de politique interne aux DSI entrent aussi en considération. Le fait
que les SGBDR soient progressivement devenus un mécanisme d'intégration pour une majorité
de DSI est l'un de ces facteurs. Remplacer un système comme un SGBDR auquel de lourds
investissements ont été consentis est dès lors devenu de plus en plus problématique. De ce point
de vue, il n'est pas exagéré d'affirmer que la domination des SGBDR a probablement entravé
l'avènement d'autres solutions parfois plus rationnelles et plus performantes.
Donnons un exemple. Les SGBDR sont notoirement mal adaptés lorsqu'il s'agit de
sauvegarder et de récupérer des grappes d'objets tels que celles qui sont manipulées par des
langages objet comme Java ou C#. C'est le célèbre problème du « mismatch d'impédance ».
Alors que les bases de données objets apparues au milieu des années 1990 promettaient
d'éradiquer ce genre de misères, l'industrie IT a préféré développer des frameworks d'un
maniement souvent complexe, comme Hibemate, pour pallier ces inconvénients. Sans même
parler du coût de l'inélégance de ces solutions bâtardes, leur coût en complexité et en
abstraction a finalement été jugé moins élevé que la migration complète d'un SGBDR.
Les SGBDR, assurément, ont la peau dure ! Ni les bases de données objets, plus
performantes, ni les sommes astronomiques englouties dans des projets d'intégration sans fin
n'ont eu raison d'elles. Le coup de boutoir viendra d'ailleurs. Au début des années 2 000, les
applications web à très grande échelle et l'émergence des réseaux sociaux ont fini par changer
la donne.

Le Mouvement NoSQL

Les contraintes des applications web à très grande échelle

Avec ces nouveaux systèmes, sont apparus de nouveaux besoins métiers et de nouvelles
exigences techniques. Via l'isolation des transactions et l'application de contraintes d'intégrité
les SGBDR garantissent des données avec un haut niveau de cohérence. Dans les applications
e- business à grande échelle comme Amazon ou dans les réseaux sociaux comme Twitter, les
priorités sont cependant très différentes. Pour une entreprise comme Amazon, par exemple,
une plateforme indisponible, ne serait-ce que quelques minutes, est inenvisageable car elle
causerait la perte de dizaine de milliers de commandes. Priorité absolue est donc donnée aux
performances et à la disponibilité. Celles- ci sont assurées aujourd'hui par la mise en œuvre
d'architectures distribuées sur des centaines voire des milliers de machines. Dans un tel
contexte, parvenir à parfaite intégrité des données et une stricte isolation des transactions est
extrêmement difficile et coûteux. Le volume des échanges d'information nécessaires pour
parvenir à une synchronisation parfaite des nœuds d'un SGBDR distribué limite en effet le
nombre de serveurs à quelques dizaines, tout au plus. De manière encore plus significative
encore, l'ancienne exigence de cohérence des données ne correspond souvent plus aux priorités
du business. Qui se soucie vraiment que la liste des commentaires d'un post sur un réseau social
soit vue de la même manière au même instant par tous les utilisateurs ?
Naturellement l'inconsistance des données pourra avoir des conséquences qu'il faudra
traiter le moment venu. Une même chambre a-t-elle été réservée par deux clients sur Booking.
com ? U n même article a-t- il été commandé sur Amazon par plusieurs clients à qui l'on a
indiqué qu'il était disponible alors qu'il ne restait plus qu’un exemplaire ? Dans chacune de ces
situations la solution est d'ordinaire humaine et pragmatique. Dans le cas d'Amazon par
exemple, les clients lésés se verront contactés par le service client qui, pour atténuer leur
courroux, leur présentera un mot d'excuse assorti d'un chèque à h auteur du préjudice subi.
Quant au surbooking pour des billets d'avion ou des chambres d'hôtel, on peut imaginer des
partenariats avec d'autres compagnies aériennes ou un quota de chambres réservé pour des
situations d'urgence. Quoi qu'il en soit, la solution dans ce genre de situations n'est pas
technique. C'est aux métiers de prendre une décision éclairée basée sur une analyse
comparative entre les c oûts des inconsistances qu'il faudra inévitablement gé re r avec les c
oûts d'une indisponibilité chronique d'un système pénalisé par l'exigence d'une cohérence de
tous les instants. On retrouve ici la distinction usuelle entre l'approche pessimiste de la gestion
des conflits, qui cherche à les éviter au moyen de verrous, et l'approche optimiste, qui cherche
à détecter les conflits et à les traiter au moment où ils surviennent, le cas échéant manuellement.
Les remarques qui précèdent n'impliquent pas pour autant que toute notion de cohérence soit
désormais caduque. Dans les faits, l'exigence de cohérence est le plus souvent remplacée par
une contrainte plus faible dite de cohérence à terme ( ou eventual consistency en anglais).

Par cohérence à terme (eventual consistency) on entend le fait qu'un système distribué converge
à longue échéance vers un état où tout utilisateur verra chaque donnée dans l'état où l'a laissée
la dernière mise à jour. Une propriété qui contraste avec la consistance permanente prônée par
les systèmes qui vérifient les propriétés ACID de manière stricte.

Un nouvel acronyme, sous forme de jeu de mot un peu alambiqué, a été forgé pour caractériser
ces systèmes : BASE pour Bosicolly Avo!loble Soft Stote Eventuol Consistency.

Aux considérations précédentes sur la disponibilité des données, il convient d'ajouter

encore leur caractère souvent non structuré dans un contexte Big Data, souvenons-nous du V
= « variété ». Lui aussi contribue à une mise en cause du modèle de données structurées des
SGBDR. Des informations précieuses ne demandant qu'à être analysées sont aujourd’hui tapies
dans d' obscurs fichiers logs, des feuilles Excel, des m ails ou même des fichiers multimédias.

Le « théorème » CAP

Même si les termes de disponibilité et de cohérence n'ont pas été définis avec une
grande rigueur, la discussion qui précède suggère qu'il est possible de choisir, selon les
circonstances, entre ces deux caractéristiques. Lorsqu' un système est distribué il convient de
prendre en compte une troisième caractéristique : la tolérance aux partitions accidentelles.

Cohérence - Disponibilité - Résistance au morcellement

Sur un plan intuitif, une base de données distribuée devrait idéalement posséder les trois
caractéristiques suivantes :

- Cohérence (consistency) : chaque donnée est présente dans la même version sur
tous les nœuds du réseau. Il n'y a pas de retard dans la propagation des mises à jour.
- Disponibilité (availability) : l'application est accessible à tout instant et chaque
requête reçoit une réponse qui confirme si elle a été traitée avec succès ou non.
- Résistance au morcellement (partition toleronce) : le système doit pouvoir
continuer à fonctionner lorsque différents nœuds sont isolés consécutivement à
une rupture du réseau.
 En 2000, lors d'un symposium consacré au calcul distribué à l'université de Berkeley,
l'un des participants, Eric Brewer, proposa une conjecture qui stipulait que parmi les trois
caractéristiques précédentes, seules deux pouvaient être réalisées simultanément. Bien
qu'aucun des trois termes invoqués dans cette conjecture n'ait été défi ni avec la précision
qu'exigerait une formulation mathématique, l'expression « théorème CAP » est restée. Des
tentatives de formulations plus précises et des démonstrations partielles ont bien été proposées
mais aucune ne répond aux critères d'un authentique théorème. Le « théorème » CAP est donc
à considérer comme une intuition utile, en partie folklorique, concernant les systèmes
distribués.
L'intuition qui se cache derrière cette affirmation est en réalité assez simple à saisir.
Imaginons pour cela un processus de réservation d'un billet d'avion qui implique simultanément
deux clients. Imaginons par ailleurs que le système de réservation soit distribué sur plusieurs
nœuds et que les nœuds qui traitent les deux requêtes soient distants. En cas de rupture de
connexion entre les deux serveurs l’alternative est alors la suivante :
- soit l'on exige une stricte cohérence des donnée s auquel cas il faudra attendre le
rétablissement de la connexion ;
- soit l'on exige une disponibilité du système à tout instant et dans ce cas il faudra
réconcilier les donnée s incohérentes ultérieurement et assumer les risques de cet
ajustement différé.
Dans la réalité le compromis est plus subtil que ne le laisse croire l’affirmation
strictement binaire du « théorème CAP ». La cohérence et la disponibilité, ou plus précisément
le temps de latence, sont toutes deux des variables continues que l'on peut ajuster selon les
besoins. En fonction des priorités, ce choix pourra d'ailleurs être adapté au type d'opération
effectuée. Cependant, quoi qu'il en soit, disposer d'un haut niveau de cohérence parmi les
donnée s répliquées implique forcément un échange d'information important entre ces nœuds,
ce qui occasionnera un temps de latence accru.
Dans une approche plus fine de la notion de cohérence des données il faudrait aussi
spécifie r le niveau de granularité des donnée s sur lesquelles opèrent les transactions. Là encore
il ne s'agit pas d'une variable binaire. En effet, pour prémunir un système des modifications
intempestives de deux transactions concurrentes qui risqueraient de le laisser dans un état
incohérent, la première transaction peut poser un des verrous sur les données qu'elle manipule.
Selon le degré d'isolation souhaité, ces verrous pourront affecter soit toutes les tables
concernées par une trans action, soit tous les enregistrements d'une t able en particulier ou
seulement certains agrégats dont on souhaite à tout prix préserver la cohérence. Dans la section
suivante, lorsque nous d écrirons les différents types de systèmes NoSQL, nous indiquerons à
chaque fois en quoi consiste, lors qu'il existe, l'agrégat atomique. Au-delà, la cohérence devra
être assurée par l'application cliente ou, comme on l'a vu, par une intervention humaine.

Sacrifier la flexibilité pour la vélocité

Un haut niveau de cohérence des données pénalise les performances ou la disponibilité

d'une base de données, telle était l'une des conclusions du paragraphe précédent. De manière
analogue, la nouvelle donne du Big Data suggère de redéfinir les compromis entre flexibilité
dans l'usage des données et performances.
L'un des grands atouts des SGBDR est le découplage logique qu'ils autorisent entre les
applications clientes et la structure des données que celles-ci utilisent. Tous les usages sont en
principe possibles, puisque chaque requête SQL est automatiquement convertie par le SGBDR
en plan d'exécution. Cette flexibilité a toutefois un coût, car un schéma de données n'est
évidemment optimal que pour certaines requêtes.
Dans les contextes Big Dat a où la vélocité prime souvent sur toute autre considération,
ce postulat de flexibilité des SGBDR, devra donc lui aussi remis en question. Un changement
de priorité qui n'est évidemment pas sans conséquences, puisque c'est désormais au
développeur d'une application d'anticiper les usages qu'il fera des données. Il devra concevoir
un code optimisé pour la structure de données spécifique à l'application qu'il développe. Tout
changement ultérieur du modèle de données nécessitera une révision du code.
Dans le même ordre d'idée, examinons l'utilité des jointures entre tables. Étroitement
liées au modèle de données relationnel dont elles assurent la flexibilité et la non-redondance,
celle-ci ne sont plus perçues désormais comme des opérations incontournables. Pour le
comprendre, considérons l'exemple type d'un client auquel on souhaite associer ses
commandes. Rien n'empêche en effet de co-localiser les données du client et celles de ses
commandes au sein d'une même table. Il suffit pour cela d'insérer dans l'enregistrement du
client des groupes de colonnes contenant ses commandes. Le prix à payer est double :
- Le chemin d'accès aux données devient alors essentiellement unique. Il sera possible
d'accéder aisément aux commandes à partir des données clients. Le chemin inverse, à
savoir trouver les clients ayant commandé un certain produit, ne sera cependant plus
disponible. Plus précisément, il sera excessivement inefficace car il faudra examiner
tous les clients, un par un.
- Il faut parfois accepter une part de redondance dans les données enregistrées. Des
commandes identiques émises par des clients différents seront inévitablement
dupliquées dans un tel schéma là où le mécanisme de clés étrangères des SGBDR
permettait précisément d'éviter cette redondance.

Une définition pour une base de données NoSQL ?

Jusque-là nous n'avons proposé aucune définition des bases de données NoSQL, et pour
cause, car celle-ci s'avère particulièrement délicate. Aucun concept clair en effet ne les
caractérise vraiment et le sigle NoSQL suggère tout au plus, ce qu'elles ne sont pas. Apparues
ces dernières années dans le contexte d'application e-commerce à grande échelle, les priorités
auxquelles elles répondent sont les suivantes :
- Distribuer les traitements et le stockage sur des centaines voire des milliers de nœuds
constitués de serveurs banalisés.
- Donner la priorité aux performances et à la disponibilité sur l'intégrité des données.
- Traiter efficacement les données non structurées ou seulement partiellement
structurées.
 Bien qu'une définition honnête soit impossible à notre avis il est possible néanmoins
d'identifier un certain nombre de points communs à ces systèmes :
1. Ces systèmes sont le plus souvent clusterisables et permettent une montée en charge
approximativement linéaire. En d'autres termes, un doublement du nombre de serveurs
permet, grosso modo, de traiter deux fois plus de requêtes dans un même laps de temps.
2. Ils sont en règle générale dépourvus de schémas, inadaptés aux données non structurées.
Cette caractéristique leur confère d'ailleurs un a tout significatif vis-à-vis des SGBDR
: ils permettent une grande rapidité de développement précisément à cause de cette
simplicité. De ce fait ils sont particulièrement adaptés aux méthodes de développement
agiles.
3. Ils sont souvent dépourvus de transactions au sens habituel du terme, ou alors proposent
des transactions qui garantissent seulement l'intégrité de certains agrégats de données
naturels. Nous y reviendrons dans la prochaine section consacrée à une classification
de ces systèmes.
4. I ls sont non relationnels dans le sens où ils n'offrent pas de jointures.
5. Beaucoup de ces systèmes sont aujourd'hui proposés en open source.
Que dire alors du sigle « NoSQL » ? Le moins que l'on puisse dire est que cette
dénomination est malheureuse. D'une part, aux dires de certains, le « No » ne voudrait pas
forcément dire « no », il pourrait signifier aussi « not only ». La partie « SQL » est plus
trompeuse encore puisque ce n'est pas tant l'absence du langage SQL qui est significative pour
beaucoup de ces systèmes, mais plutôt l'absence de transactions au sens usuel du terme. En
réalité ce sigle n'a pas été choisi suite à de profondes réflexions conceptuelles. Il s'agit d'un
simple hashtag utilisé en 2009 pour notifier sur Twitter l'organisation d'un débat à San
Fransisco sur ces bases de données d'un nouveau genre.

Les solutions NoSQL

Mettre un peu d'ordre dans lefoisonnement de systèmes de bases de données auxquels

on peut accoler l' éti quette NoSQL n'est pas une chose aisée car proposer une catégorisati on
revient, defait, à définir des cloisons étanches qui ne correspondent ni à la réalité technologique,
ni à celle des usages. Au plus haut niveau de granulari té on peut cependant distinguer deux
catégories vraiment disj ointes.
La première est constituée de ce que l' on pourrait appeler les bases de données orientées
agrégats (BDOA), un terme dû à Martin Fowler1 . L' un des fa cteurs qui a déterminé l'
émergence des systèmes NoSQL est la nécessité, on l'a vu, de déployer les systèmes sur des
clusters. L'une des stratégies pour y parvenir est de renoncer à éclater les données dans une
multitude de tables et de les regrouper plutôt au sein d'agrégats qui contiennent les données
auxquelles l'on accède le plus souvent. Le « mismatch d'impédance » disparaît dans ce cas et
les agrégats fonctionnent alors à la fois comme unités pour les opérations de mise à jour et
comme frontières naturelles pour les transactions. Enfin les différentes stratégies de
distributions, de réplication et de partitionnement horizontal (sharding) utilisent elles aussi ces
agrégats comme unités de base.
 Parmi ces BDOA nous distinguerons trois sous-catégories, selon la structure des
agrégats qu'elles manipulent :
- les entrepôts clé-valeur,
- les bases de données orientées documents,
- et enfin les bases de données orientées colonnes.
La seconde grande catégorie est celle des bases de données orientées graphes (BDOG)
conçues pour naviguer efficacement dans un graphe de données, une tâche pour lesquelles, les
SGBDR sont paradoxalement inadaptés. Dans les quatre sections suivantes nous décrirons
chacun de ces quatre modèles.
Dans la mesure du possible nous établirons des parallèles avec les concepts plus familiers
des SGBDR et nous examinerons en particulier dans quelle mesure ils gèrent les transactions.
Enfin nous donnerons à chaque fois les principaux cas d'usage.

Les entrepôts clé-valeur

Concepts
Un entrepôt clé-valeur (ECV ) peut être envisagé comme une collection de tables de
hachage persistantes c'est-à-dire comme une collection de couples clé-valeur persistées sur
disque. La valeur en question peut être un morceau d'information (un blob) sans aucune
structure a priori. Il peut s'agit d'un nombre, d'un fichier XML, d'une vidéo, d'une grappe
d'objets métiers sérialisés ou encore d'un fichier texte sans structure particulière.

Figure : Parmi toute la panoplie des systèmes NoSQL, l'entrepôt clé-valeur est le système le
plus rudimentaire. Il s'agit d'une simple collection de couples clé-valeur enregistrée sur le
disque.
Les opérations que l'on peut effectuer sur un tel entrepôt sont : la récupération de la
valeur pour une clé donnée, la mise à jour, la création ou la suppression d'une valeur pour une
certaine clé. La base ne « connaît » pas la structure des données, charge étant à l'application
cliente d'interpréter le contenu des valeurs. La contrepartie d'une telle rusticité qui n'autorise
l'accès aux données que par le biais d'une clé primaire est la performance de ces systèmes.
Dans un tel contexte, stocker toutes les données dans un seul espace est générale, ment
considéré comme une mauvaise pratique car, chaque agrégat ayant potentielle, ment une
structure différente, les risques de conflits entre clés augmentent. Un usage typique d'un ECV
est celui du stockage des sessions de multiples utilisateurs.
 Figure : Un identifiant de session fonctionne comme une clé primaire pour désigner la
grappe d'objets associée à une session utilisateur, en l'occurrence un profil utilisateur, de
données de session ainsi qu'une liste d'articles.
Certains entrepôts clé-valeur proposent pour cette raison de partitionner l'espace des
clés en différentes zones dédiées chacune à un type de données spécifique, facilitant ainsi la
sérialisation et la désérialisation par le client de l'ECV. Le modèle de cohérence à terme
(eventual consistance) est celui qui est retenu par une majorité des implémentations d'ECV. Le
paramétrage fin de la consistance peut alors se faire au moyen de trois paramètres :
- Le facteur de réplication qui définit le nombre N de nœuds sur lesquels doivent être
répliquées les données.
- Le quorum d'écriture W qui spécifie le nombre de nœuds dont on exige qu'ils notifient
que les données ont été écrites avec succès pour considérer une opération d'écriture
comme valide.
- Le quorum de lecture R enfin, qui spécifie le nombre de nœuds minimal qu'il convient
d'interroger pour être sûr d'obtenir la dernière version d'une donnée.
On parle deconsistance forte lorsque R + W > N. La montée en charge des ECV est
généralement assurée par un mécanisme dit de sharding (ou de partition horizontale). Alors
que la réplication consiste à enregistrer des copies d'une donnée sur plusieurs nœuds, le
sharding consiste à répartir des données différentes sur des nœuds différents. Dans le contexte
d'un ECV, c'est la valeur de la clé qui déterminera sur quel serveur est hébergée la valeur
associée. Les implémentations les plus répandues des entrepôts clé-valeur sont Riak, Redis,
MemcacheDB et DynamoDB chez Amazon.

Usages
Le stockage de données de session utilisateur est le cas typique d'utilisation d'un
entrepôt clé-valeur. De manière similaire, le stockage des préférences ou des profils des
utilisateurs ou encore les associations entre clients et paniers d'achat des sites d'e-commerce
conviennent bien aux ECV. La structure des données en table de hachage les rend cependant
inadaptés pour retrouver des données à partir d'une valeur plutôt que d'une clé.

Les bases orientées documents

Concepts
Sur un plan conceptuel, les bases de données orientées document (BDOD) diffèrent peu
des ECV. Une BDOD peut schématiquement se décrire comme un ECV dont les valeurs sont
des documents semi-structurés. Par ce terme on entend des documents autodescriptifs
généralement écrits avec un format de type XML, J SON ou similaire. Par contraste avec les
SGBDR qui exigent que chaque enregistrement d'une table ait les mêmes colonnes, spécifiées
par un schéma, rien n'exige que les documents stockés dans une BDOD aient tous le même
format.
De ce point de vue, une BDOD est donc beaucoup plus flexible qu'un SGBDR dans la
mesure où il est possible de modifier au coup par coup la structure d'un document sans avoir à
respecter un schéma préétabli. Alors qu'une valeur non définie d'une colonne d'un
enregistrement d'un SGBDR est représentée par la valeur NULL, un document d'une BDOD
ne fera tout simplement pas figurer l'attribut en question.
Pour clarifier la relation entre SGBDR (Oracle) et BDOD (MongoDB).
Les BDOD offrent par ailleurs la possibilité d'examiner le contenu d'un document sans
qu'il soit nécessaire pour autant de le récupérer en intégralité, en quoi elles se distinguent des
ECV. Rappelons que c'est à l'application cliente d'un ECV d'interpréter le contenu d'une valeur.
Dans une BDOD chaque document constitue un élément atomique qui délimite une
frontière transactionnelle naturelle. En règle générale il n'est pas possible d'impliquer plusieurs
documents comme le ferait un SGBDR sur différents enregistrements.
 Figure : Une base orientée document. Les documents peuvent chacun avoir leur propre
structure.
Tableau : Equivalences entre SGBDR et BDOD

La disponibilité des BDOD est généralement assurée par un mécanisme de réplication

qui utilise un schéma de type maître-esclave. Les requêtes sont adressées par défaut au maître
qui les redirige vers l'un des esclaves pour les opé rations de lecture. La montée en charge se
fait par simple aj out de nœuds esclaves. Si le maître tombe en panne, les nœuds esclaves
procèdent à un vote pour élire un nouveau maître selon des critères de distance entre les nœuds
ou de quantité de RAM disponible. L'application cliente n'a pas, quant à elle, à se soucier de se
connecter à un nœud particulier ni à gérer les pannes de réseau. La technique de sharding est
souvent utilisée par les BDOD, le système assurant une ré partition équilibrée des données
entre les nœuds en tenant compte notamment de la distance qui les sépare.
Les implémentations les plus répandues de BDOD à ce jour sont : MongoDB,
CouchDB, RavenDB et Lotus Notes.
Usages
Les applications d'e-commerce dont les produits varient trop souvent pour être décrits
au moyen d'un schéma stable, bénéficieront de l'usage d'une BDOD.
Les applications qui manipulent naturellement des documents comme les systèmes de
gestion de contenu ou les plateformes de blogs pourront elles aussi utiliser avec profit une
BDOD.
Mentionnons encore les systèmes de logs qui, par définition, ont à stocker des
associations entre des évènements et des contenus sans structure prédéfinie.

Les bases orientées colonnes

Concepts
Parmi les bases de données orientées agrégats (BDOA), les bases orientées colonnes
(BDOC) sont sans aucun doute celles dont le modèle de données est le plus riche. De fait, la
principale difficulté pour aborder ce sujet tient moins à sa complexité intrinsèque qu'à la
barrière d'une nomenclature hélas souvent confuse et qui, de surcroît, varie d'un produit à un
autre. Pour cette raison, nous décrirons ici le modèle de données de la BDOC Cassandra, son
modèle étant particulièrement complet et clair. D'autres BDOC, comme HBase , pourront alors
être envisagées, tout au moins sur un plan conceptuel, comme des cas particuliers de celui que
nous présentons.
Pour tenter d'y voir clair, établissons d'emblée le parallèle avec deux catégories de
systèmes qui nous sont d'ores et déjà familiers : les ECV et les SGBDR classiques.
La première manière de définir, sur le plan conceptuel, une BDOC comme Cassandra
est qu'il s'agit d'un ECV dont les valeurs possèdent une structure bien particulière. Cette
structure en l'occurrence est celle de colonnes dont les noms peuvent être soit statiques , ils
sont alors partagés par tous les enregistrements d'une collection de colonnes, soit dynamiques,
c'est-à-dire qu'ils peuvent varier d'un enregistrement à l'autre au sein d'une telle collection.
La possibilité d'avoir des colonnes dynamiques permet d'avoir des enregistrements avec
colonnes différentes en type et en nombre, chose impossible dans un SGBDR. Un autre élément
des structures, commun à beaucoup de BDOC, est la possibilité de regrouper entre elles des
colonnes contenant des données sémantiquement liées. L'enregistrement d'un client contiendra
toutes ses commandes par exemple. Ces regroupements s'appellent des super-colonnes. Elles
aussi peuvent à leur tour être statiques ou dynamiques. Selon que les colonnes ou les super-
colonnes sont statiques ou dynamiques on peut alors construire quatre types de structures, que
l'on appellera des familles de colonnes, appropriées à des situations différentes. Les quatre
figures qui suivent illustrent chacune de ces structures.
 Figure : Les colonnes d'une BDOC peuvent être statiques ou dynamiques. Dans le cas
statique, on retrouve la structure habituelle d'une table d'un SGBDR, avec des
enregistrements possédant un nombre fixe de colonnes prédéfinies. Les données d'un
enregistrement qui utilisent des colonnes dynamiques peuvent aussi se concevoir comme une
hashmap qui associe des noms (de colonne) à des valeurs.

Figure : Lorsque les super-colonnes et les colonnes sont statiques la structure de la famille de
colonnes est celle d'une table de SGBDR classique.
Figure : Lorsque les super-colonnes sont statiques et les colonnes dynamiques, ces dernières
permettent de représenter une hashmap associée à chaque clé.

Figure : Des super-colonnes dynamiques à l'intérieur desquelles figurent des colonnes

statiques permettent de stocker, par exemple, des commentaires d'un article de blog.
Comme on le constate, les familles de colonnes autorisent une grande flexibilité et sont
par conséquent adaptées à une grande variété d'usages. Pour clarifier définitivement le sujet,
les analogies les plus pertinentes avec un SGBDR sont résumées dans le tableau suivant.
 Figure : La forme la plus flexible correspond à la situation où les super-colonnes et les
colonnes sont toutes deux dynamiques. Un cas d'utilisation possible est le stockage des
nombres de visites d'un site web, classés par page dans le site. Une autre manière de voir
cette structure est que pour chaque enregistrement on a deux hashmap imbriquées. Dans
l'exemple, la première associe une URL à une collection de pages du site visité. La seconde
associe une page à un nombre de visites.
Tableau : Les analogies les plus pertinentes entre BDOC et SGBDR

Comme pour les BDOD, il est généralement possible de paramétrer le niveau de cohérence
souhaité, en lecture ou en écriture. En écriture par exemple, Cassandra propose les niveaux
suivants :
- ONE : permet d'optimiser la performance. Il se peut que certaines opé rations d'écriture
soient perdues si le nœud auquel on envoie la requête tombe.
- QUORUM : on exige qu'une opération d'écriture se propage à une majorité de nœuds
du cluster avant d'être validée.
- ALL : on exige que tous les nœuds aient répondu positivement pour qu'une opé ration
d'écriture (ou de lecture) soit validée.
Le nombre de répliques peut être choisi lors de la création du keyspace.
 S'agissant des transactions, c'est l'enregistrement qui fait figure de frontière naturelle.
Autrement dit une opération d'insertion ou de mise à jour est atomique au niveau d'un
enregistrement mais pas au-delà.
La disponibilité est assurée par un mécanisme de réplication dans un mode pair-à- pair
sans nœud maître.
Les BDOC les plus populaires à l'heure actuelle sont : Cassandra (dont nous avons
repris les concepts et le vocabulaire), HBase, Hypertable (une implémentation open source
inspirée du système propriétaire BigTable de Google), Amazon SimpleDB.

Usages
La flexibilité des BDOC en fait un choix idéal, par exemple, pour stocker des rapports
d'erreur issus de plusieurs applications dont chacune pourra utiliser le groupe de colonnes qui
lui convient. Les blogs avec leurs publications, leurs liens, les rétro-liens ainsi que les
commentaires associés sont particulièrement bien adaptés à l'utilisation d'une BDOC. Les
systèmes de comptage de nombre de visites, comme nous l'avons vu dans le dernier exemple,
peuvent tirer profit de la classification à deux niveaux, par site et par page, que permet le
modèle des colonnes dynamiques.

Les bases de données orientées graphes

Concepts
Dans de nombreuses situations comme les réseaux sociaux, il s'agit de relier des entités
par différentes relations, elles-mêmes dotées d'attributs et d'un sens de navigation. Telle
personne « aime », « connaît » ou « fait partie du cercle professionnel » de telle autre. Malgré
leur nom, les SGBDR (où « R » = relationnel) sont mal adaptés pour parcourir rapidement un
graphe. Un SGBDR n'est bien adapté que pour décrire des relations simples, comme celles qui
lient un client à ses commandes, par exemple. Cependant, dès que le nombre de liens à
parcourir excède un ou deux, la nécessité de définir à chaque fois des clés étrangères et
d'effectuer de nombreuses jointures pénalise les performances au point de rendre cette approche
impraticable.
À ces limitations des SGBDR, il faut ajouter encore l'impossibilité pure et simple
d'effectuer certaines opérations naturelles sur un graphe. Parcourir l'intégralité d'un graphe ou
trouver un chemin entre deux nœuds vérifiant certaines contraintes sont deux exemples
élémentaires. Les bases de données orientées graphes ont été conçues pour répondre
spécifiquement à cette catégorie de besoins. Elles permettent dans un premier temps de créer
des nœuds puis, indépendamment, de créer des associations entre eux et de les modifier par la
suite.
Beaucoup de BDOG ne prennent pas en charge la distribution des nœuds de données
sur un cluster et l'ACIDité n'est assurée qu'au sein d'un seul serveur. On pourrait peut-être
arguer qu'elles n'ont pas vraiment leur place dans un ouvrage consacré au Big Data. Nous les
présentons néanmoins rapidement par souci de cohérence dans ce chapitre consacré aux
systèmes NoSQL.
 Figure : Un exemple de graphe qui relie des individus, des services et des lieux
géographiques.
D'une certaine manière la stratégie mise en œuvre dans une BDOG est à l'opposé de
celle utilisée par BDOA. Alors que ces dernières regroupent des données au sein d'agrégats,
les BDOG les éclatent autant que possible dans un graphe. Pour cette raison les BDOG sont
généralement ACID, comme les SGBDR, pour la simple raison que l'éclatement des données
exige que celles-ci soient protégées encore davantage que dans un SGBDR. Alors que les
agrégats constituent des limites transactionnelles naturelles pour les BDOA, celles-ci n'existent
pas dans le cas des BDOG et doivent donc être défi nies explicitement.
Parmi les BDOG les plus utilisées aujourd'hui citons : Neo4], Infinite Graph et
OrientDB.

Usages
A priori tous les domaines métiers qui s'expriment naturellement à l'aide de graphes
sont éligibles à l'utilisation d'une BDOG. I ls sont particulièrement utiles dans les situations où
différentes catégories de liens expriment des appartenances à certains groupes sociaux ou
géographiques. Dans ce dernier cas, l'un des attributs des liens sera la distance qui sépare les
nœuds qu'ils connectent. Tous les systèmes de recommandation ou de détection de fraude qui
ont à tenir compte d'une certaine proximité, géographique, sociale ou autre pourront tirer profit
d'un BDOG.

Résumé
La force du modèle relationnel classique réside avant tout dans la flexibilité de l'usage
de données qu'il permet, et dans les garanties offertes par le caractère ACID des transactions.
 Dans le contexte des applications web à grande échelle, ce modèle universel est
désormais remis en question. Les exigences de performance et de disponibilité demandent de
l'abandonner au profit des systèmes dont les modèles de données sont spécifiquement adaptés
aux applications qui les exploitent tout en étant simultanément moins flexible.
Les applications métiers devront par ailleurs prendre en charge tout ou partie de la
gestion de la cohérence des données. Les bases de données NoSQL coexisteront encore pendant
de nombreuses années avec les SGBDR. Le recours à l'option NoSQL se fera avant tout sur la
base d'un examen lucide et chiffré des compromis acceptables entre consistance des données
et disponibilité des systèmes. Il s'agit donc au moins autant d'un choix commercial que d'un
choix technologique.
 Chapitre 5 : L’algorithme MapReduce et le
framwork Hadoop
Ce chapitre présente MapReduce, un modèle de programmation, qui a permis
d'automatiser le déploiement de traitements massivement parallèles sur des clusters de
centaines ou de milliers de serveurs peu coûteux. Nous examinerons les atouts et les contraintes
qu'impose ce paradigme de programmation ainsi que ses limitations. Pour nous forger une
intuition sur ses possibilités, nous illustrerons son fonctionnement au moyen de trois exemples
simples. Dans un contexte Big Data, l'algorithme MapReduce à lui seul ne serait pas d'une
grande utilité sans une infrastructure logicielle dédiée, raison pour laquelle nous présenterons
les grandes lignes du fonctionnement de Hadoop, qui est à ce jour la principale implémentation
open source d'une telle infrastructure.

Automatiser le calcul parallèle

Au chapitre précédent nous avons décrit comment les contraintes propres au Big Data,
notamment celles liées au volume de données et aux performances, ont contribué à faire
émerger une nouvelle classe de systèmes de stockage, les bases NoSQL. Ce chapitre examine
maintenant l'impact de ces contraintes sur les traitements de ces grands volumes de données.
Une des voies praticables pour passer à l'échelle consiste à les paralléliser sur un cluster de
plusieurs centaines ou milliers de machines. Hélas, cette mise en parallèle est en règle générale
une tâche excessivement ardue qui nécessite un savoir faire spécialisé et une longue phase de
conception. De plus, dans les situations où un code non parallélisé existe déjà, un important
travail de réécriture est le plus souvent nécessaire.
Un des progrès les plus significatifs dans l'automatisation de la parallélisation est venu
de travaux de recherches effectués par Google pour les besoins de son moteur de recherche.
Au début des années 2000, des centaines de processus parallèles avaient été conçus par les
ingénieurs de Mountain View pour traiter les quantités pharamineuses d'information récoltées
par les web crawlers du moteur de recherche : création d'annuaires inversés (liste de documents
contenant certains mots clés), analyse des graphes de liens entre documents, identification des
requêtes les plus fréquentes, etc. Bien que tous ces processus aient été conçus à l'origine par
des équipes différentes, les ingénieurs se sont aperçus a posteriori que nombre de ces
programmes mettaient en œuvre une stratégie similaire pour paralléliser les traitements.
C'est ce pattern de répartition des tâches que nous allons décrire dans ce chapitre et que
l'on appelle MapReduce. Après l'avoir défini formellement, nous décrirons trois exemples
d'utilisation élémentaires qui donneront une idée du mode de pensée qu'implique la conception
d'un tel algorithme. La seule logique des traitements, telle qu'elle est prescrite par MapReduce,
ne serait cependant pas d'une grande utilité, du moins dans un contexte Big Data, sans une
infrastructure logicielle qui prend en charge la complexité liée à la distribution des traitements,
à la réplication des données et à la tolérance aux pannes. Nous présenterons pour cette raison
les grandes lignes du fonctionnement de Hadoop, à ce jour l'implémentation open source de
référence d'un tel framework d'exécution distribuée du pattern MapReduce. Le chapitre 9 sera
consacré à une description des principaux éléments de l'écosystème Hadoop.
Ajoutons encore pour être précis, que la définition des abstractions MapReduce a été
inspirée non seulement par une synthèse d'expériences chez Google mais aussi par des travaux
antérieurs dans le domaine de la programmation fonctionnelle.

Le pattern MapReduce

Le pattern MapReduce a été décrit la première fois en 2004 dans un articlefondateur2

rédigé par deux ingénieurs de Google. Sur un plan intuitif, MapReduce part de l'observation
que, dans de nombreuses situations, la mise en parallèle d'un traitement peut s'effectuer sur un
plan logique au moyen de seulement deux types d'opérations, possédant une structure bien
précise que nous allons décrire.
La première contrainte imposée par l'algorithme MapReduce est que les données en
entrée doivent être structurées comme une liste de couples clé-valeur, analogues à celles qui
sont stockées dans l es ECV ou les BDOD décrits au chapitre précédent. En pratique, cette liste
peut s'avérer très volumineuse, sa taille pouvant se chiffrer en téraoctets ou même en petaoctets.
Cette liste en entrée est tout d'abord scindée en plusieurs lots (par le framework), chaque lot
étant attribué à une des machines appelées mapper, voir la figure suivante.

Figure : Les données initiales sont scindées en lots. Chaque lot, aussi appelé splits, est confié
à un mapper qui évalue la fonction map sur chaque enregistrement. Les listes obtenues en
sortie des mappers sont concaténées, classées par valeur de la clé intermédiaire et scindées en
lots par le Framework. C'est la phase dite du shuffle. Les reducers évaluent la fonction reduce
sur des listes de valeurs associées à une même valeur de clé intermédiaire.
Remarque : l'indépendance des traitements map est absolument cruciale puisque c'est elle qui
autorise la mise en parallèle de leur exécution, soit sur des machines différentes, soit au sein
de processus distincts.
 Dans une seconde phase, une fois que tous les mappers ont tous achevé leur tâche, les
fonctions « reduce», exécutées par des reducers, agrègent systématiquement toutes les valeurs
intermédiaires associées à une même clé intermédiaire. Pour cela le framework fusionne au
préalable les listes intermédiaires en sortie des mappers, les trie selon la valeur des clés, les
répartit en lots puis enfin les achemine vers les reducers. Chaque lot sera assigné à un seul
reducer et les lots sont constitués de telle manière que les toutes les valeurs associées à une
même clé figurent dans le même lot.
L'opération « reduce » peut donc être envisagée comme une opération de recombinaison
ou d' agrégation des résultats partiels obtenus par les mappers lors de la première phase. Pour
rendre les choses plus concrètes, envisageons le calcul de données agrégées à partir d'un
historique de vente sur plusieurs années, voir la figure suivante. Chaque enregistrement de la
liste correspond à une vente de plusieurs articles. Les seules données qui nous intéressent en
l'occurrence sont les noms des articles, leur prix ainsi que la quantité vendue. Notre objectif est
d'utiliser MapReduce pour calculer le prix de vente total et le nombre de ventes par produit.
Conceptuellement, le calcul se réduit à une longue liste d'additions. La difficulté pratique, n'est
donc pas de nature conceptuelle mais tient au fait qu'en pratique il faut généralement réunir des
données réparties sur un grand nombre de serveurs. La tâche de la fonction map consiste alors
à extraire pour chaque vente, la liste des produits associés à leur prix et au nombre de ventes.
Après un regroupement par nom de produit, pris en charge par le framework, les fonctions
reduce calculeront les deux sommes qui nous intéressent.

Figure : Un exemple de fonctions map et reduce adaptées au calcul d'un prix total et d'une
quantité totale par ventes à partir d'un historique de ventes.
Remarque : l'écriture d'algorithmes MapReduce est une tâche délicate qui ne peut être confiée
qu'à des développeurs spécialisés qui se seront forgé au préalable des intuitions propres à ce
nouveau modèle de programmation. Le plus souvent les tâches complexes à paralléliser sont
converties non pas en un seul job MapReduce mais en une succession de petits jobs plus faciles
à concevoir.
 Nous retrouvons au niveau des traitements MapReduce une situation que nous avions
déj à décrite à propos des bases NoSQL. Dans un cas comme l'autre le prix à payer pour la
performance se traduit par un surcroît de complexité du code (celui des fonctions Map et
Reduce en l'occurrence) qui devra être spécifiquement adapté au jeu de données utilisé. La
situation est donc en contraste marqué avec celle des SGBDR où la connaissance du langage
SQL suffisait dans la plupart des cas de figure.
Considérant, d'une part, la disponibilité des compétences SQL et, d'autre part, les
subtilités de la programmation MapReduce, on comprend vite l'intérêt de disposer d'un
mécanisme qui convertirait des scripts écrits dans un langage de haut niveau, dans l'idéal proche
de SQL, en jobs MapReduce. De tels mécanismes de compilation existent. Les plus connus se
nomment Pig et Hive et seront décrits dans d’autres chapitres.

Le Framework Hadoop

Notre présentation de l'algorithme MapReduce s'est limitée jusque-là à ses seuls aspects
logiques, en particulier aux éléments principaux que sont les deux abstractions « map » et «
reduce ». Si la maîtrise de ces API et l'aptitude à les utiliser pour reformuler un problème de
parallélisation sont des compétences indispensables pour quiconque souhaite utiliser
MapReduce, elles ne suffisent pas cependant pour construire un système performant.
En effet, aussi élégantes soient-elles, les abstractions « map » et « reduce » ne masquent
pas, hélas, toute la complexité de la parallélisation d'un calcul. Une connaissance élémentaire
de ce qui se trame dans les coulisses du framework reste in dispensable. En d'autres termes, si
un framework comme Hadoop prend effectivement en charge un grand nombre de tâches de
bas niveau, encore faut-il savoir lesquelles, dans quel ordre celles-ci sont invoquées et quelles
ressources elles consomment. Nous retrouvons, une fois encore, le phénomène de non-
découplage entre les abstractions et leur implémentation lorsqu'il s'agit d'optimiser les
performances.
L'implémentation de l'algorithme MapReduce dépend de l'environnement dans lequel
on souhaite l'exécuter. Dans un contexte Big Data, c'est une implémentation sur un cluster de
serveurs qui nous intéresse. Les deux paragraphes qui suivent présentent les grandes lignes du
fonctionnement de Hadoop, le framework MapReduce le plus populaire à l'heure actuelle
Hadoop est un framework open source écrit en Java et développé sous l'égide de la fondation
Apache depuis 2005. La version 1.0 a vu le jour fin 2011. Actuellement nous sommes à la
version 3.3.

Planning des exécutions

L'unité de travail qu'une application cliente peut exécuter dans Hadoop s'appelle un job
MapReduce. Chaque job est découpé en tâches qui peuvent appartenir à deux catégories : les
tâches map ou les tâches reduce.
 L'ensemble des jobs en cours d'exécution par le framework est coordonné et supervisé
par un processus maître appelé le jobtracker. Son rôle est de planifier l'exécution des tâches
qu'il attribue à des processus esclaves, appelés tasktrackers. Pour isoler les exécutions des
tâches map et reduce et éviter que celles-ci ne fassent tomber le serveur qui les exécute en cas
de plantage, le tasktracker démarre chaque tâche map ou reduce dans une JVM séparée. Voilà
qui nous amène naturellement au sujet de la tolérance aux pannes.

Figure : Les relations entre un client d'un job MapReduce, le jobtracker et un tasktracker. Un
processus de notification régulier informe le jobtracker (maître) de l'état d'avancement des
tâches exécutées par chaque tasktracker (esclave). Par sécurité, chaque tâche map ou reduce
s'exécute au sein d'une JVM séparée du processus du tasktracker.

Tolérance aux pannes

Jobtrackers et tasktrackers
Le système Hadoop, comme le système propriétaire de Google dont il s'inspire, est
conçu pour exécuter MapReduce sur un cluster homogène de plusieurs milliers de serveurs bon
marché. De ce fait, la tolérance aux pannes est au cœur même de sa conception. Imaginons à
titre d'exemple une fréquence d'une panne par machine et par an. La fréquence des pannes pour
un cluster de10000 machines sera dès lors d'environ une par heure. La responsabilité du
framework est donc de faire en sorte qu'en dépit de ces pannes inévitables le résultat de
l'exécution de MapReduce soit le même que celui que produirait une machine parfaite.
Le cœur du mécanisme qui assure la tolérance aux pannes est un mécanisme de
notification. Chaque tasktracker est censé envoyer à intervalles réguliers au jobtracker un
rapport d'avancement des tâches qui lui ont été confiées. Ce signal s'appelle le heartbeat call.
E n c as de besoin, le jobtracker ordonnera la réexécution de toutes les tâches dont on sait
explicitement qu'elles ont échoué ou des tâches exécutées par des tasktrackers qui n'ont pas
donné de nouvelles après un certain délai.
Les causes possibles d'une panne sont évidemment nombreuses : un bug dans
l'implémentation d'une des tâches map ou reduce, un plantage du tasktracker lui-même ou la
panne d'une machine physique, etc. Les causes d'erreur les plus communes sont toutefois des
erreurs d'implémentation dans le code des fonctions map ou reduce. En cas d'erreur, le code
utilisateur lève une exception d'exécution que la JVM répercute au tasktracker avant que celle-
ci ne s'arrête. L'erreur est historisée dans un log utilisateur et la tâche qui a échoué est notée
comme telle par le tasktracker qui libère alors les ressources utilisées par la tâche fautive pour
les allouer à une autre tâche. Le jobtracker sera notifié de l'échec au prochain heartbeat call et
c'est à lui que revient la responsabilité de planifier une nouvelle tentative d'exécution en évitant
autant que possible de réallouer la tâche à un tasktracker où celle-ci aurait déjà échoué
précédemment. Le nombre de tentatives de réexécution d'une tâche est paramétrable.

HDFS : un système de fichiers distribué

Dans un contexte Big Data le volume de donnée à traiter excède le plus souvent la
capacité d'une seule machine. Un système de fichiers distribués sur tous les nœuds du réseau
devient dès lors indispensable. L'implémentation que propose Hadoop se nomme HDFS pour
Hadoop Distributed File System. Il prend en charge toute la complexité liée à la distribution et
à la réplication des données sur les nœuds du cluster pour garantir qu'aucune donnée ne soit
perdue en cas de panne d' un ou plusieurs disques durs. Nous décrirons ce système plus en
détail dans un autre chapitre.

Exécutions spéculatives
Mis à part les plantages, il peut également arriver aussi qu'une tâche s'exécute plus
lentement que prévu lorsque l'on compare son temps d'exécution à la moyenne des autres
tâches. Statistiquement, ce phénomène est en réalité tout aussi inévitable que les plantages.
Remarquons qu'un tel ralentissement est particulièrement préjudiciable à la performance
globale d'un job lorsqu'il se produit dans une tâche map. En effet, rappelons que la totalité des
processus map doit être achevée avant de pouvoir passer à la phase reduce. C'est donc la tâche
map la plus lente qui est déterminante pour la performance globale d'un job.
Plutôt que de diagnostiquer les raisons d'un éventuel ralentissement, Hadoop lancera
alors une ou plusieurs nouvelles exécution s de la même tâche, les mettant ainsi en concurrence.
Sitôt qu'un des processus en compétition s'achève avec succès, les autres tâches devenues
redondantes sont stoppées. Ce mécanisme de mise en compétition est appelé l'exécution
spéculative.

Découpage des données en lots

La possibilité même d'un calcul parallèle repose sur le découpage des données en entrée
en plusieurs lots. Comme cela a été mentionné dans une section précedente , chaque mapper se
voit affecter un des lots que l'on nomme aussi split dans le vocabulaire Hadoop. Len ombre de
mappers coïncide donc avec celui des splits. Il sera fonction du volume des données à traiter,
du temps d'exécution individuel des fonctions map et du temps d'exécution moyen attendu pour
chaque job.
La bonne taille des splits est le résultat d'un compromis. Un grand nombre de petits lots
favorise une bonne répartition de la charge entre les différents processus map et donc les
performances du système. Mais, passé un certain seuil, le découpage pénalisera les
performances car les ressources nécessaires à la gestion des splits et à la création des processus
map l'emporteront sur le bénéfice d'une bonne répartition de la charge. En règle générale un
bon choix pour la taille des splits correspond à la taille des blocs du système de fichiers
distribué, environ64 Mo.

Fusion et tri des listes intermédiaires

Cette tâche a déjà été largement décrite précédemment. C'est la phase de shuffle durant
laquelle les listes de clé-valeur intermédiaires en sortie des opérations map sont d'abord
fusionnées avant d'être triées par valeur de clé puis enfin transmises aux reducers.
Remarque : la phase de shuffle constitue le véritable cœur de l'algorithme MapReduce. C'est
le tri opéré durant cette phase qui relie les mappers aux reducers et permet en définitive la
parallélisation des traitements. Une compréhension de ce qui s'y passe est indispensable dès
lors que l'on souhaite procéder à certaines optimisations. Cette partie centrale du framework
Hadoop bénéficie d'améliorations continuelles.
Le processus de shuffle est réparti entre les mappers et les reducers.

Figure : Articulation des phases map, shuffle et reduce

Le tri côté mapper

Les listes de clé-valeurs intermédiaires produites par les mappers, sont des objets
temporaires, raison pour laquelle elles ne sont pas stockées sur le système de fichiers distribués
HDFS. L'écriture de ces listes se fait d'abord dans un buffer en mémoire alors qu'un processus
en arrière-plan effectue un tri en mémoire selon les valeurs des clés intermédiaires et construit
des partitions associée s aux reducers auxquelles les listes seront transmises. Toutes les valeurs
associées à une même clé intermédiaire sont écrites dans une même partition. Régulièrement,
le conte nu du buffer est copié sur le disque local du tasktracker qui héberge le processus map.
 Le contenu du disque local n'est effacé qu'une fois les données consommées par les
reducers et lorsque ceux-ci ont notifié le succès de l'opération au jobtracker.
Pour économiser la bande passante consommée par la transmission des listes triées aux
mappers, un développeur peut intervenir sur l'opération de tri pour rendre la sortie des mappers
plus compacte. Il devra pour cela en implémenter une défi nie par l'API MapReduce de Hadoop
appelée combiner.

Le tri côté reducer

Contrairement aux donnée s des mappers, les listes intermédiaires en entrée d'un
reducer ne sont pas localisées sur le disque local du tasktracker qui l'exécute. Elles proviennent
d'une multitude de mappers répartis dans le cluster. La copie des listes des mappers vers les
reducers, qui s'opère en mémoire ou sur le disque local selon le volume des données, débute
sitôt que la totalité des mappers ont terminé leur travail. Une fois l'intégralité des listes
intermédiaires copiées localement, les listes sont fusionnées. Chaque invocation de fonction
reduce traite la liste de valeurs associées à une clé. À l'issue du traitement le résultat est écrit
sur HDFS qui répliquera les résultats sur d'autres nœuds par sécurité.

Monitoring des processus

Étant donné que les disfonctionnements, matériels ou logiciels, sont inévitables dans
un cluster, il est crucial de pouvoir superviser en continu son état de santé pour être en mesure
d'intervenir à temps, qu'il s'agisse d'augmenter le nombre de machines dans le cluster ou de
remplacer celles qui sont défectueuses. En plus des traditionnels mécanismes de logs, Hadoop
offre toute une panoplie de métriques et de compteurs.
Les métriques sont collectées par des processus en arrière-plan et fournissent aux
administrateurs systèmes des informations techniques comme le nombre de requêtes
utilisateurs ou le nombre de blocs répliqués. Certaines de ces métriques sont disponibles via
l'API Java standard JMX.
Les compteurs s'adressent quant à eux aux utilisateurs MapReduce que sont les
concepteurs d'applications métiers. Ils contiennent des informations globales à l'échelle d'un
job comme le nombre d'enregistrements invalides par exemple. Il s'agit d'outils de contrôle de
qualité ou d'aide à la création de statistiques.

Au-delà de MapReduce
Depuis quelques années le modèle de programmation MapReduce et le framework
d'exécution Hadoop offrent une solution pragmatique à la parallélisation massive des
traitements pour des volumes de données qui, désormais, peuvent se chiffrer en pétaoctets.
Pour autant ce modèle comporte aussi des faiblesses dont il faut être conscient. Rappelons à ce
titre quelques-unes des contraintes qu'impose le paradigme MapReduce :
a- Seuls les traitements que l'on peut reformuler à l'aide d'un couple de fonctions map et
reduce sont éligibles à ce type de parallélisme.
 b- Même lorsque la chose est possible, le temps nécessaire pour écrire un job MapReduce
et le tester se chiffre souvent en jours.
c- Le framework Hadoop reste un outil complexe dont le paramétrage et l'optimisation
requièrent un niveau de compétence élevé.
d- Bien que l'architecture en cluster garantisse une scalabilité linéaire, les temps de latence
sont caractéristiques d'un traitement batch. Ils s'échelonnent entre quelques dizaines de
secondes, au mieux, à plusieurs heures.

Résumé
MapReduce est un pattern logiciel qui permet de paralléliser le traitement de très grands
volumes de données à condition que le calcul puisse se formuler à l'aide de deux fonctions,
map et reduce, qui opèrent sur des listes de clé-valeur.
Hadoop est aujourd'hui le standard de fait en tant que plateforme d'exécution de
MapReduce. Conçu pour fonctionner sur des clusters homogènes de machines peu coûteuses,
il prend en charge l'essentiel des problématiques de bas niveau lié à la planification des tâches,
à la répartition de charge et à la réplication des données. Hadoop est particulièrement bien
adapté pour le traitement batch de très grands volumes de données comme le nettoyage ou la
préparation d'un jeu de donnée en amont d'une analyse de type machine learning.
MapReduce en tant que tel n'est cependant pas adapté aux traitements interactifs en
temps réel.