PANORAMA DU BIG DATA

Cours BACHELOR 3

Présenté par : Mr. Menounga Guy Charly, Ingénieur informatique, DG Big Data Solution SARL
PLAN
Le big data
Les des du Big Data
Principes des infrastructures matérielles et logicielles du Big Data
Actions sur les données dans le Big Data
Quelques exemples
Hadoop
Base de données non-relationnelles
ACID/BASE
Catégories des bases NoSQL

Apache Spark
I. Le big data
Historique
1992 : la National Science Foundation autorise le web commercial, premier site e-commerce "books.com"
1994 : premier paiement en ligne securise realise sur le site NetMarket
1995 : debut de l'e-commerce (Pizza Hut, Amazon, Ebay)
❖ Apparition de nouveaux modeles :
❖ B2C : business-to-consumer
❖ C2C : consumer-to-consumer
❖ B2B2C : business-to-business-to-consumer

2000-2010 : smartphones, Google, Facebook, MySpace, Twitter

I. Le big data
Quelque statistique

En une minute sur l'Internet :

❖ 470 000 tweets sur Twitter
❖ 2 millions de snap partagés sur Snapchat
❖ 4 millions de recherches réalisées sur Google
Dans le monde commercial :
❖ Walmart produit 40 péta-octets par jour
De multiples sources : réseaux sociaux, applications mobiles, différents
capteurs (montre, suivi d'activité), systèmes de localisation, tags RFID, etc.
I. Le big data
Quelque statistique
I. Le big data
Définition

Le terme Big Data réfère a l'accroissement exponentielle des données, au

traitement de ces dernières ou de manière plus générale a toutes les étapes
entrant en jeu dans le processus d'extraction d'informations utiles a partir
d’énormes lots de données brutes.
I. Le big data
Les 3V du big data
➢ Volume : la quantité de données augmente ! 1 péta-octets toutes les15 secondes !
• est-ce que ça va continuer ?
• oui ! l'industrie est prête (disques de 10To, bandes de 185 To en 2020, etc.)
• un obstacle ?
• L’énergie ! Actuellement l'industrie de l'information consomme entre 5 et 10% de
l’énergie mondiale

➢ Vélocité : vitesse la laquelle les données sont générées

• entraine des difficultés technologiques de traitement et d'analyse

➢ Variété : variété des types et des sources

• types : texte, audio, vidéo, email, flux de clics, données de géolocalisation, etc.
• sources humaines (mails, clics, etc.) ou des machines (logs, capteurs, sondes, etc.)
• La variété engendre des données non-structurées !

➢ Valeur : représente le gain que peuvent apporter les données

I. Le big data
En résumé

Être dans le Big Data, c'est rencontrer une évolution significative dans un seul
ou dans plusieurs des 3V.
Si les bases de données relationnelles avaient pu gérer les 3V, on ne parlerait
pas de Big Data.
I. Le big data
Les défis du big data

➢ Stockage : les grands volumes résultent d'une agrégation d’un ensemble

d'entrepôts de stockage, éventuellement sur différents sites
➢ Passage à l'échelle, élasticité
Maîtriser les coûts d'acquisition, d'administration et de maintenance
I. Le big data
Principes des infrastructures matérielles et logicielles du Big Data
➢ Paralléliser le stockage
• une multitude de petits serveurs de stockage
• une couche logicielle de gestion, supervision, détection d'erreurs
Objectifs :
▪ protection des données par réplication
▪ faciliter le scale-out
I. Le big data
Principes des infrastructures matérielles et logicielles du Big Data
➢ Paralléliser le stockage
• Différentes architectures de stockage
▪ maitre-esclaves
▪ maitres-esclaves
▪ p2p ou maitre-maitre
I. Le big data
Principes des infrastructures matérielles et logicielles du Big Data
➢ Paralléliser le stockage
maitre-esclaves (1 serveur de méta données) : Hadoop
I. Le big data
Principes des infrastructures matérielles et logicielles du Big Data
➢ Paralléliser le stockage
maitres-esclaves (x serveurs de métadonnées) => MongoDB
I. Le big data
Principes des infrastructures matérielles et logicielles du Big Data
➢ Paralléliser le stockage
p2p ou maitre-maitre (serveur de stockage = serveur de métadonnées) => utilise un algorithme
pour découper/placer les données.
I. Le big data
Principes des infrastructures matérielles et logicielles du Big Data
➢ Paralléliser le stockage
Architecture multisite
I. Le big data
Principes des infrastructures matérielles et logicielles du Big Data
➢ Paralléliser les traitements

Les demandes de traitement sont envoyées aux serveurs de stockage et parallélisées.

=> Localisation des données importante !
Paradigme le plus célèbre : Le MapReduce
I. Le big data
Principes des infrastructures matérielles et logicielles du Big Data
➢ Paralléliser les traitements
❖ MapReduce
Proposé par Google en 2004, deux fonctions principales exécutées de manière séquentielle :
Map est appliquée en parallèle sur chaque partition de données.
Exemple : compter les occurrences de mots dans chaque partition ou chercher un motif
Reduce reçoit en entrée un ou plusieurs résultats intermédiaires et exécute un ensemble
d'opérations, typiquement un tri ou une fusion, et produit un résultat

L'adoption globale de MapReduce a motive son amélioration avec de nouvelles extensions

(HALoop, BigSQL, etc.)
I. Le big data
Principes des infrastructures matérielles et logicielles du Big Data
➢ Paralléliser les traitements
❖ MapReduce
I. Le big data
Actions sur les données dans le Big Data
I. Le big data
Actions sur les données dans le Big Data
❖ Ingestion des données
Plusieurs problématiques se posent lorsque le volume en entrée est trop important (exemple du SKA) :
➢ réduction par calcul des données
➢ traiter au plus près des sources de données

❖ Stockage : le lac de données

➢ processus ELT (Extract Load Transform) != ETL (Extract Transform Load)
➢ espace de données utilisée pour stocker les données dans leur format natif, en attendant d'être analysées
➢ présente une architecture à plat != un entrepôt de données consigne les données de manière
hiérarchique, dans des fichiers ou dossiers
I. Le big data
Actions sur les données dans le Big Data
❖ Etude de la qualité
Les sources et les formes sont hétérogènes ou indignes de confiance :
capteurs défectueux, erreurs d'orthographe dans une publication Facebook, fraude ou
comportement malicieux...
Plusieurs actions :
• contrôler les entrées
• connaître l'impact des erreurs potentielles sur les données
• détection des inexactitudes ou des absences de données
• nettoyage des données (50 à 90 % du temps du métier de data-scientist)

Un cinquième V du Big Data: la Véracité

I. Le big data
Actions sur les données dans le Big Data
❖ Indexation
➢ consiste à ajouter des métadonnées métiers permettant le requêtage des données
➢ semi-structuration des données
➢ métier de "data scientist"
➢ détection automatique d'informations (numéro de tel, carte de crédit, adresse, etc.)
➢ exemple de produit : splunk, graylog, logstash

❖ Streaming ou traitement d'évènements

Objectif de temps de réponse d'un traitement
Deux appellations de traitement de flux de données :
➢ streaming (flux en continu)
➢ traitement d'évènements complexes (CEP : Complexes Event Processing)
Exemple de produit : RabbitMQ, Apex, Storm, Kafka
II. ARCHITECTURE BIG DATA
1. Composants d’une architecture big data
Une architecture Big Data
est conçue pour gérer
l’ingestion, le traitement et
l’analyse de données trop
volumineuses ou
complexes pour les
systèmes de base de
données traditionnels.
II. ARCHITECTURE BIG DATA
2. Composants d’une architecture big data
❖ Sources de données : Toutes les solutions Big Data reposent sur une ou plusieurs sources de données

❖ Stockage de données : Les données destinées aux opérations de traitement par lots sont généralement stockées
dans un magasin de fichiers distribués, qui peut contenir de vastes volumes de fichiers volumineux dans divers
formats.

❖ Traitement par lots : Étant donné que les jeux de données sont trop lourds, une solution Big Data doit souvent
traiter les fichiers de données à l’aide de traitements par lots à longue durée d’exécution pour filtrer, agréger et
préparer les données en vue de l’analyse

❖ Magasin de données analytique : De nombreuses solutions Big Data préparent les données pour l’analyse, puis
fournissent les données traitées dans un format structuré qui peut être interrogé à l’aide des outils d’analyse

❖ Orchestration : La plupart des solutions Big Data consistent en des opérations de traitement de données
répétées, encapsulées dans des workflows, qui transforment les données source, déplacent les données entre
plusieurs sources et récepteurs, chargent les données traitées dans un magasin de données analytique, ou
envoient les résultats directement à un rapport ou à un tableau de bord
II. ARCHITECTURE BIG DATA
3. Architecture Lambda
Lorsque vous utilisez des jeux de données très volumineux, l'exécution des requêtes des
clients peut prendre beaucoup de temps. Ces requêtes ne peuvent pas être effectuées
en temps réel et nécessitent souvent des algorithmes comme MapReduce, qui
s’exécutent en parallèle sur l’ensemble du jeu de données. Les résultats sont ensuite
stockés séparément des données brutes et utilisés à des fins d’interrogation.

Un inconvénient de cette approche est qu’elle entraîne de la latence : si le traitement

dure quelques heures, une requête peut donc retourner des résultats datant de plusieurs
heures. Dans l’idéal, vous devez obtenir des résultats en temps réel (malgré une certaine
perte de précision) et combiner ces résultats avec ceux de l’analyse en mode batch.
II. ARCHITECTURE BIG DATA
3. Architecture Lambda
L’architecture lambda, proposée pour la première fois par Nathan Marz, résout ce
problème en créant deux chemins d’accès aux flux de données. Toutes les données
entrantes dans le système transitent par ces deux chemins d’accès :

• une couche de traitement par lots (chemin à froid) stocke toutes les données
entrantes dans leur forme brute et effectue un traitement par lots de ces
données. Le résultat de ce traitement est stocké sous forme d’une vue de
traitement par lots.

• Une couche vitesse (chemin réactif) analyse les données en temps réel. Cette
couche est conçue pour une faible latence, au détriment de la précision.

La couche de traitement par lots alimente une couche service qui indexe la vue de
traitement par lots pour améliorer l’interrogation. La couche vitesse met à jour de
la couche service avec les mises à jour incrémentielles basées sur les données les
plus récentes.
II. ARCHITECTURE BIG DATA
3. Architecture Lambda
Les données qui circulent dans le chemin réactif sont limitées par les conditions de latence imposées par la couche
vitesse, afin de garantir un traitement aussi rapide que possible. Souvent, cela nécessite d’accepter une certaine perte
de précision afin d’obtenir les données aussi rapidement que possible. Par exemple, imaginons un scénario IoT où un
grand nombre de capteurs de température transmettent des données de télémétrie. La couche vitesse permet de
traiter les données entrantes dans une fenêtre temporelle coulissante.

En revanche, les données qui transitent par le chemin à froid ne sont pas soumises aux mêmes exigences de faible
latence. Cela permet d’obtenir un calcul plus précis sur plusieurs jeux de données volumineux, une tâche qui peut
prendre beaucoup de temps.

Pour finir, le chemin relatif et le chemin à froid convergent au niveau de l’application cliente analytique. Si le client a
besoin d’afficher en temps opportun des données potentiellement moins précises en temps réel, il obtiendra son
résultat avec le chemin réactif. Sinon, il devra sélectionner les résultats avec le chemin à froid pour obtenir des données
plus précises mais à un moment moins opportun.
II. ARCHITECTURE BIG DATA
4. Architecture Kappa
Un inconvénient de l’architecture lambda est sa complexité. La
logique de traitement apparaît dans deux emplacements
différents, le chemin froid et le chemin chaud, utilisant deux
infrastructures différentes. Cela double la logique de calcul et la
complexité de la gestion de l’architecture pour ces deux chemins.

L’architecture kappa a été proposée par Jay Kreps comme

alternative à l’architecture lambda. Elle vise les mêmes objectifs
de base que l’architecture lambda, mais avec une différence
importante : toutes les données transitent via un chemin unique
en utilisant un système de traitement de flux.
II. ARCHITECTURE BIG DATA
4. Architecture Kappa
Il existe certaines similarités avec la couche de traitement par lots de l’architecture lambda, dans la mesure où les
données des événements restent immuables et sont collectées dans leur totalité et non comme un sous-ensemble. Les
données sont reçues sous forme d’un flux d’événements dans un journal unifié, distribué et tolérance aux pannes. Ces
événements sont classés, et l’état actuel d’un événement change uniquement lorsqu’un nouvel événement est ajouté.
Comme pour la couche vitesse de l’architecture lambda, tout le traitement des événements est effectué sur le flux
d’entrée et perdure sous forme d’une vue en temps réel.
III. HADOOP
Hadoop est un système de gestion de données et de traitements distribués. Il contient de
beaucoup de composants, dont :

• HDFS un système de fichier qui répartit les données sur de nombreuses machines,
• YARN un mécanisme d’ordonnancement de programmes de type MapReduce.
III. HADOOP
1. HDFS
a. Présentation
HDFS est un système de fichiers distribué. C’est à dire :

❖ les fichiers et dossiers sont organisés en arbre (comme Unix)

❖ ces fichiers sont stockés sur un grand nombre de machines de manière à rendre invisible la
position exacte d’un fichier.
❖ L’accès est transparent, quelle que soient les machines qui
❖ contiennent les fichiers.
❖ les fichiers sont copiés en plusieurs exemplaires pour la fiabilité et permettre des accès
simultanés multiples

HDFS permet de voir tous les dossiers et fichiers de ces milliers de machines comme un seul
arbre, contenant des Po de données, comme s’ils étaient sur le disque dur local.
III. HADOOP
1. HDFS
b. Organisation des fichiers
Vu de l’utilisateur, HDFS ressemble à un système de fichiers Unix :
il y a une racine, des répertoires et des fichiers. Les fichiers ont un propriétaire, un groupe et des droits
d’accès comme avec ext4.

Sous la racine /, il y a :
❖ des répertoires pour les services Hadoop : /hbase, /tmp, /var
❖ un répertoire pour les fichiers personnels des utilisateurs : /user (attention, ce n’est ni /home, ni /users
comme sur d’autres systèmes Unix). Dans ce répertoire, il y a aussi trois dossiers système : /user/hive,
/user/history et /user/spark.
❖ un répertoire pour déposer des fichiers à partager avec tous les utilisateurs : /share

Vous devrez distinguer les fichiers HDFS des fichiers « normaux ».

III. HADOOP
1. HDFS
c. Commande hdfs dfs
La commande hdfs dfs et ses options permet de gérer les fichiers et dossiers :
❖ hdfs dfs –help
❖ hdfs dfs -ls [noms...] (pas d’option -l)
❖ hdfs dfs -cat nom
❖ hdfs dfs -mv ancien nouveau
❖ hdfs dfs -cp ancien nouveau
❖ hdfs dfs -mkdir dossier
❖ hdfs dfs -rm -f -r dossier (pas d’option -fr)
III. HADOOP
1. HDFS
d. Echanges entre HDFS et le monde
Pour placer un fichier dans HDFS, deux commandes équivalentes :
❖ hdfs dfs -copyFromLocal fichiersrc fichierdst
❖ hdfs dfs -put fichiersrc [fichierdst]
Pour extraire un fichier de HDFS, deux commandes possibles :
❖ hdfs dfs -copyToLocal fichiersrc dst
❖ hdfs dfs -get fichiersrc [fichierdst]
Exemple :
hdfs dfs -mkdir -p livres
wget http://www.textfiles.com/etext/FICTION/dracula
hdfs dfs -put dracula livres
hdfs dfs -ls livres
hdfs dfs -get livres/center_earth
III. HADOOP
1. HDFS
e. Comment fonctionne HDFS ?
Comme avec de nombreux systèmes, chaque fichier HDFS est découpé en blocs de taille fixe. Un bloc HDFS =
256Mo. Selon la taille d’un fichier, il lui faudra un certain nombre de blocs. Sur HDFS, le dernier bloc d’un fichier
fait la taille restante.

Les blocs d’un même fichier ne sont pas forcément tous sur la même machine. Ils sont copiés chacun sur
différentes machines afin d’y accéder simultanément par plusieurs processus. Par défaut, chaque bloc est copié
sur 3 machines différentes (c’est configurable).

Cette réplication des blocs sur plusieurs machines permet aussi de se prémunir contre les pannes. Chaque fichier
se trouve donc en plusieurs exemplaires et à différents endroits.
III. HADOOP
1. HDFS
e. Comment fonctionne HDFS ?
Un cluster HDFS est constitué de machines jouant différents rôles exclusifs entre eux :

❖ L’une des machines est le maître HDFS, appelé le namenode. Cette machine contient tous les noms et blocs des
fichiers, comme un gros annuaire téléphonique.
❖ Une autre machine est le secondary namenode, une sorte de namenode de secours, qui enregistre des
sauvegardes de l’annuaire à intervalles réguliers.
❖ Certaines machines sont des clients. Ce sont des points d’accès au cluster pour s’y connecter et travailler.
❖ Toutes les autres machines sont des datanodes. Elles stockent les blocs du contenu des fichiers.
III. HADOOP
1. HDFS
g. Un schéma des nodes HDFS

Les datanodes contiennent des blocs (A, B, C. . . ), le namenode sait où sont les fichiers : quels blocs et sur quels
datanodes.
III. HADOOP
1. HDFS
h. Explications
Les datanodes contiennent des blocs. Les mêmes blocs sont dupliqués (replication) sur différents datanodes, en
général 3 fois. Cela assure :
❖ fiabilité des données en cas de panne d’un datanode,
❖ accès parallèle par différents processus aux mêmes données.
Le namenode sait à la fois :
❖ sur quels blocs sont contenus les fichiers,
❖ sur quels datanodes se trouvent les blocs voulus.
On appelle cela les metadata.
Inconvénient majeur : panne du namenode = mort de HDFS, c’est pour éviter ça qu’il y a le secondary namenode.
Il archive les metadata, par exemple toutes les heures.
III. HADOOP
1. HDFS
j. Mode high availability
Comme le namenode est absolument vital pour HDFS mais unique, Hadoop propose une configuration appelée
high availability dans laquelle il y a 2 autres namenodes en secours, capables de prendre le relais
instantanément en cas de panne du namenode initial.
Les namenodes de secours se comportent comme des clones. Ils sont en état d’attente et mis à jour en
permanence à l’aide de services appelés JournalNodes.

Les namenodes de secours font également le même travail que le secondary namenode, d’archiver
régulièrement l’état des fichiers, donc ils rendent ce dernier inutile.
III. HADOOP
2. Algorithme MapReduce
a. Principes
On veut recueillir une information synthétique à partir d’un jeu de données.
Exemples sur une liste d’articles possédant un prix :
❖ calculer le montant total des ventes d’un article,
❖ trouver l’article le plus cher,
❖ calculer le prix moyen des articles.
Pour chacun de ces exemples, le problème peut s’écrire sous la forme de la composition de deux fonctions :
❖ map : extraction/calcul d’une information sur chaque n-uplet,
❖ reduce : regroupement de ces informations.
III. HADOOP
2. Algorithme MapReduce
Exemple
Soient les 4 n-uplets fictifs suivants :

Calculer le prix maximal, moyen ou total peut s’écrire à l’aide d’algorithmes, étudiés en première année, du type :

pour chaque n-uplet, faire :

valeur = FonctionM(n-uplet courant)
retourner FonctionR(valeurs rencontrées)
III. HADOOP
2. Algorithme MapReduce
Exemple (suite)
❖ FonctionM est une fonction de correspondance : elle calcule une valeur qui nous intéresse à
partir d’un n-uplet,
❖ FonctionR est une fonction de regroupement (agrégation) : maximum, somme, nombre,
moyenne, distincts. . .

Par exemple, FonctionM extrait le prix d’une voiture, FonctionR calcule le max d’un ensemble de valeurs :

tous_les_prix = liste()
pour chaque voiture, faire :
tous_les_prix.ajouter( getPrix(voiture courante) )
retourner max(tous_les_prix)
Pour l’efficacité, les valeurs intermédiaires ne sont pas stockées mais transmises entre les deux fonctions par une
sorte de tube (comme dans Unix). Le programme ne s’écrit donc pas tout à fait comme ça.
III. HADOOP
2. Algorithme MapReduce
Exemple en Python
Voici comment on l’écrit en Python2 :
III. HADOOP
2. Algorithme MapReduce
b. Explications
❖ L’écriture map(fonction, liste) applique la fonction à chaque élément de la liste. Elle effectue la boucle
« pour » de l’algorithme précédent et retourne la liste des prix des voitures. Ce résultat contient
autant de valeurs que dans la liste d’entrée.
❖ La fonction reduce(fonction, liste) agglomère les valeurs de la liste par la fonction et retourne le
résultat final.

Ces deux fonctions constituent un couple « map-reduce » et le but de ce cours est d’apprendre à les comprendre et
les programmer.
Le point clé est la possibilité de paralléliser ces fonctions afin de calculer beaucoup plus vite sur une machine ayant
plusieurs cœurs ou sur un ensemble de machines reliées entre elles.
III. HADOOP
2. Algorithme MapReduce
c. Parallélisation de Map
La fonction map est par nature parallélisable, car les calculs sont indépendants.
Exemple, pour 4 éléments à traiter :
❖ valeur1 = FonctionM(element1)
❖ valeur2 = FonctionM(element2)
❖ valeur3 = FonctionM(element3)
❖ valeur4 = FonctionM(element4)

Les quatre calculs peuvent se faire simultanément, par exemple sur 4 machines différentes, à condition que
les données y soient copiées.

Remarque : il faut que la fonction mappée soit une pure fonction de son paramètre, qu’elle n’ait pas
d’effet de bord tels que modifier une variable globale ou mémoriser ses valeurs précédentes.
III. HADOOP
2. Algorithme MapReduce
d. Parallélisation de Reduce
La fonction reduce se parallélise partiellement, sous une forme hiérarchique, par exemple :
❖ inter1 et 2 = FonctionR(valeur1, valeur2)
❖ inter3 et 4 = FonctionR(valeur3, valeur4)
❖ resultat = FonctionR(inter1 et 2, inter3 et 4)

Seuls les deux premiers calculs peuvent être faits simultanément. Le 3e doit attendre. S’il y avait davantage de
valeurs, on procéderait ainsi :
1. calcul parallèle de la FonctionR sur toutes les paires de valeurs issues du map
2. calcul parallèle de la FonctionR sur toutes les paires de valeurs intermédiaires issues de la phase
précédente.
3. et ainsi de suite, jusqu’à ce qu’il ne reste qu’une seule valeur.
III. HADOOP
2. Algorithme MapReduce
Un schéma
III. HADOOP
3. YARN
a. Qu’est-ce que YARN ?
YARN (Yet Another Resource Negociator) est un mécanisme dans Hadoop permettant de gérer des travaux (jobs) sur
un cluster de machines.
YARN permet aux utilisateurs de lancer des jobs MapReduce sur des données présentes dans HDFS, et de suivre
(monitor) leur avancement, récupérer les messages (logs) affichés par les programmes.

Éventuellement YARN peut déplacer un processus d’une machine à l’autre en cas de défaillance ou d’avancement
jugé trop lent.

En fait, YARN est transparent pour l’utilisateur. On lance l’exécution d’un programme MapReduce et YARN fait en
sorte qu’il soit exécuté le plus rapidement possible.
III. HADOOP
3. YARN
a. Paires clé-valeurs
C’est en fait un peu plus compliqué que ce qui a été expliqué initialement. Les données échangées entre Map
et Reduce, et plus encore, dans la totalité du job sont des paires (clé, valeur) :

❖ une clé : c’est n’importe quel type de données : entier, texte. . .

❖ une valeur : c’est n’importe quel type de données
Tout est représenté ainsi. Par exemple :
❖ un fichier texte est un ensemble de (n° de ligne, ligne).
❖ un fichier météo est un ensemble de (date et heure, température)

C’est cette notion qui rend les programmes assez étranges au début : les deux fonctions Map et Reduce
reçoivent des paires (clé, valeur) et émettent d’autres paires, selon les besoins de l’algorithme.
III. HADOOP
3. YARN
a. Map
La fonction Map reçoit une paire en entrée et peut produire un nombre quelconque de paires en sortie :
aucune, une ou plusieurs, à volonté. Les types des entrées et des sorties sont comme on veut.
Cette spécification très peu contrainte permet de nombreuses choses. En général, les paires que reçoit Map
sont constituées ainsi :

❖ la valeur de type text est l’une des lignes ou l’un des n-uplets du fichier à traiter
❖ la clé de type integer est la position de cette ligne dans le fichier (on l’appelle offset en bon
français)

Il faut comprendre que YARN lance une instance de Map pour chaque ligne de chaque fichier des données à
traiter. Chaque instance traite la ligne qu’on lui a attribuée et produit des paires en sortie.
III. HADOOP
3. YARN
a. Schéma Map

Les tâches MAP traitent chacune une paire et produisent 0..n paires. Il se peut que les mêmes clés et/ou valeurs
soient produites.
III. HADOOP
3. YARN
a. Reduce
La fonction Reduce reçoit une liste de paires en entrée. Ce sont les paires produites par les instances de Map.
Reduce peut produire un nombre quelconque de paires en sortie, mais la plupart du temps, c’est une seule.
Par contre, le point crucial, c’est que les paires d’entrée traitées par une instance de Reduce ont toutes la
même clé.
YARN lance une instance de Reduce pour chaque clé différente que les instances de Map ont produit, et leur
fournit uniquement les paires ayant la même clé. C’est ce qui permet d’agréger les valeurs.
En général, Reduce doit faire un traitement sur les valeurs, comme additionner toutes les valeurs entre elles,
ou déterminer la plus grande des valeurs. . .

Quand on conçoit un traitement MapReduce, on doit réfléchir aux clés et valeurs nécessaires pour que ça
marche.
III. HADOOP
3. YARN
a. Schéma Reduce

Les tâches Reduce reçoivent une liste de paires ayant toutes la même clé et produisent une paire qui
contient le résultat attendu. Cette paire en sortie peut avoir la même clé que celle de l’entrée.
III. HADOOP
3. YARN
Exemple
Une entreprise de téléphonie veut calculer la durée totale des appels téléphoniques d’un abonné à partir
d’un fichier CSV contenant tous les appels de tous les abonnés (n° d’abonné, n° appelé, date, durée
d’appel). Ce problème se traite ainsi :

1. En entrée, on a le fichier des appels (1 appel par ligne)

2. YARN lance une instance de la fonction Map par appel
3. Chaque instance de Map reçoit une paire (offset, ligne) etproduit une paire (n° abonné, durée) ou rien si
c’est pas l’abonné qu’on veut. NB: l’offset ne sert à rien ici.
4. YARN envoie toutes les paires vers une seule instance de Reduce (car il n’y a qu’une seule clé différente)
5. L’instance de Reduce additionne toutes les valeurs des paires qu’elle reçoit et produit une seule paire en
sortie (n° abonné, durée totale)
III. HADOOP
3. YARN
Remarque
En réalité, il n’y a pas qu’une seule instance de Reduce, il y en a plusieurs pour faire la réduction de manière
hiérarchique plus rapidement. Car en général l’algorithme qu’on écrit dans la fonction Reduce est une boucle sur
chaque valeur reçue.
Également, en réalité, il n’y a pas une instance de Map par ligne de données. C’est la vision qu’on peut avoir en
tant que programmeur, mais ça conduirait à un nombre gigantesque d’instances pour traiter un énorme fichier. En
fait, YARN instancie un seul « Mappeur » par machine esclave et appelle sa méthode map à plusieurs reprises
pour traiter les données séquentiellement.
Également, en réalité, il n’y a pas une instance de Map par ligne de données. C’est la vision qu’on peut avoir en
tant que programmeur, mais ça conduirait à un nombre gigantesque d’instances pour traiter un énorme fichier. En
fait, YARN instancie un seul « Mappeur » par machine esclave et appelle sa méthode map à plusieurs reprises
pour traiter les données séquentiellement.
III. HADOOP
3. YARN
Etapes d’un job MapReduce
Un job MapReduce comprend plusieurs phases :
1. Prétraitement des données d’entrée, ex: décompression des fichiers
2. Split: séparation des données en blocs traitables séparément et mise sous forme de (clé, valeur), ex: en lignes ou
en n-uplets
3. Map: application de la fonction map sur toutes les paires (clé, valeur) formées à partir des données d’entrée,
cela produit d’autres paires (clé, valeur) en sortie
4. Shuffle & Sort: redistribution des données afin que les paires produites par Map ayant les mêmes clés soient sur
les mêmes machines
5. Reduce: agrégation des paires ayant la même clé pour obtenir le résultat final.
III. HADOOP
3. YARN
Schéma
III. HADOOP
3. YARN
Explication du schéma
1. Au début, YARN se renseigne sur l’emplacement des données auprès du namenode et les fait décompresser
si besoin par les datanodes concernés.
2. La phase Split consiste à construire des paires (n° de n-uplet, n-uplet) à fournir aux tâches Map.
3. YARN crée des processus Map sur chaque machine contenant une partie des données et leur fournit les
paires de leur machine successivement.
4. Chaque tâche Map analyse ses données et émet ou non une paire. Ça peut consister à convertir des chaînes
en nombres, à faire des calculs, etc.
5. YARN trie les paires sortant de Map selon leur clé et les envoiesur la machine qui fait tourner la tâche
Reduce concernée par cette clé.
6. Les tâches Reduce reçoivent une liste de paires et effectuent la réduction des valeurs (max, sum, avg. . . ).
Elles émettent seulement la valeur finale. Elles peuvent être mises en cascade quand il y a beaucoup de
paires.
III. HADOOP
3. YARN
Phase de MapReduce
TD HADOOP
Exercices 1:
1. Differentiate between NameNode and DataNode
2. Explain the roles of the JobTracker and TaskTracker in the MapReduce function.
3. Which of the following is not a characteristic of Big Data?
A. Volume
B. Variety
C. Virtual
D. Velocity
E. None of the above

4. Which of the following Big Data Platform components can cost effectively analyze petabytes of structured and
unstructured data at rest?
A. Stream Computing
B. Systems Management
C. Contextual Discovery
D. Hadoop System
E. Accelerators
Exercices 1:
5. What is Hadoop?
A. An open-source software framework for distributed storage and distributed processing of Big Data on clusters of
commodity hardware.
B. It was conceived for high-end, expensive hardware
C. An environment for on-line transaction processing
D. It consists of 3 sub projects: MapReduce, Hive and Hadoop Common.
E. All of the Above

6. What are the main components of Hadoop?

A. Map Reduce, Hive, HDFS
B. Hadoop Common, Map Reduce, HDFS
C. HDFS, BigSQL, Map Reduce
D. Hive, BigSQL, Map Reduce
E. Hive, Hadoop Common, HDFS
Exercices 1:
7. What is NOT true about Hadoop Distributed File System (HDFS)?
A. Can create, delete, copy but not update
B. Files split into blocks
C. Data access through MapReduce
D. Designed for random access not streaming reads
E. None of the above

8. What is NOT true about the Namenode StartUp?

A. NameNode reads fsimage in memory
B. NameNode applies editlog changes
C. NameNode exits safemode when 99.9% of blocks have at least one copy accounted for
D. NameNode stores data blocks
E. NameNode waits for block data from data nodes
Exercices 1:
8. Which of the following is NOT a MapReduce Task?
A. Map
B. Shuffle
C. Reduce
D. Combiner
E. Reader

9. Which of the following does the Map Task need as input?

A. Map and Key
B. Key and Address
C. Key and Value
D. Map and Address
E. Map and Value
Exercices 1:
10. Regarding Task Failure; if a child task fails, where does the child JVM reports before it exits?
A. ReduceTask
B. TaskTracker
C. JobTracker
D. TaskScheduler
E. None of the above

11. A ________ node acts as the Slave and is responsible for executing a Task assigned to it by the JobTracker.
A. MapReduce
B. Mapper
C. TaskTracker
D. JobTracker

12. Point out the correct statement

A. Map Task in MapReduce is performed using the Mapper() function
B. Reduce Task in MapReduce is performed using the Map() function
C. All of the mentioned
D. MapReduce tries to place the data and the compute as close as possible
Exercices 1:
14. _________ function is responsible for consolidating the results produced by each of the Map() functions/tasks.
A. Map
B. Reduce
C. Reducer
D. Reduced

15. __________ maps input key/value pairs to a set of intermediate key/value pairs.
A. Mapper
B. Reducer
C. Both Mapper and Reducer
D. None of the mentioned

16. Which of the following phases occur simultaneously ?

A. Reduce and Sort
B. Shuffle and Sort
C. Shuffle and Map
D. All of the mentioned
Exercices 1:
17. Mapper and Reducer implementations can use the ________ to report progress or just indicate that they are alive.
A. Partitioner
B. OutputCollector
C. Reporter
D. All of the mentioned

18. __________ is a generalization of the facility provided by the MapReduce framework to collect data output by the
Mapper or the Reducer
A. Partitioner
B. OutputCollector
C. Reporter
D. All of the mentioned

19. _________ is the primary interface for a user to describe a MapReduce job to the Hadoop framework for execution.
A. Map Parameters
B. JobConf
C. MemoryConf
D. All of the mentioned
Exercices 1:
20. A ________ serves as the master and there is only one NameNode per cluster
A. Data Node
B. NameNode
C. Data block
D. Replication

21. HDFS works in a __________ fashion

A. master-worker
B. master-slave
C. worker/slave.
D. All of the mentioned

22. Which of the following scenario may not be a good fit for HDFS?
A. HDFS is not suitable for scenarios requiring multiple/simultaneous writes to the same file
B. HDFS is suitable for storing data related to applications requiring low latency data access
C. HDFS is suitable for storing data related to applications requiring high latency data access
D. None of the mentioned
Exercices 1:
23. ________ is the slave/worker node and holds the user data in the form of Data Blocks
A. DataNode
B. NameNode
C. Data block
D. Replication

24. HDFS provides a command line interface called __________ used to interact with HDFS.
A. HDFS Shell
B. FS Shell
C. DFSA Shell
D. None
Exercices 2:
Dans une architecture classique de centre de calcul HPC, on trouve des "baies de nœuds de calculs très fiables" qui lisent
leurs données et écrivent leurs résultats finaux dans des "baies de disques également très fiables" accédées à travers un
réseau rapide.

1. A l’opposé, quel type de matériel trouve-t-on dans une architecture distribuée de stockage et de traitement de
données comme Hadoop (cluster Hadoop) ?
2. Quel est l’impact sur la politique de tolérance aux pannes d’Hadoop ?
3. Que se passe-t-il lorsqu’un nœud de données qui n’accueille aucun calcul tombe en panne ?
4. Quels critères sont utilisés pour décider sur quels nœuds exécuter un traitement des données?
IV. APACHE SPARK
1. Présentation de Spark
Spark est une API de programmation parallèle sur des données.

L’objet principal de Spark est le RDD : Resilient Distributed Dataset. C’est un

dispositif pour traiter une collection de données par des algorithmes parallèles
robustes. Un RDD ne contient pas vraiment de données, mais seulement un
traitement.

Ce traitement n’est effectué que lorsque cela apparaît nécessaire. On appelle cela
l’évaluation paresseuse. D’autre part, Spark fait en sorte que le traitement soit
distribué sur le cluster, donc calculé rapidement, et n’échoue pas même si des
machines tombent en panne.
IV. APACHE SPARK
2. Avantages de spark
Spark permet d’écrire des traitements complexes composés de plusieurs phases map-reduce. On
peut le faire également avec YARN, mais les données issues de chaque phase doivent être
stockées sur HDFS, pour être réutilisées immédiatement après dans la phase suivante. Cela prend
beaucoup de temps et d’espace.

Les jobs YARN sont assez longs à lancer et exécuter. Il y a des temps de latence considérables.

Au contraire, Spark utilise beaucoup mieux la mémoire centrale des machines du cluster et gère
lui-même l’enchaînement des tâches.

Les traitements peuvent être écrits dans plusieurs langages : Scala, Java et Python. On utilisera ce
dernier pour sa simplicité pédagogique et le fait que vous l’apprenez dans d’autres cours.
IV. APACHE SPARK
3. Architecture Spark
IV. APACHE SPARK
3. Architecture Spark

• Application = driver + exécuteurs

• Driver = programme qui lance et coordonne plusieurs tâches sur le
cluster
• Exécuteurs = processus indépendants qui réalisent les tâches de calcul
• SparkContext
➢objet Java qui permet de se connecter au cluster
➢fournit des méthodes pour créer des RDD
IV. APACHE SPARK
4. Fonctionnement de Spark
• Resilient Distributed Datasets (RDDs)
➢Structures accessibles en lecture seule
➢Stockage distribué en mémoire centrale
➢Restriction aux opérations sur gros granules
▪ Transformations de la structure en entier vs MAJ valeurs
atomiques qui nécessite propagation replicats
➢Journalisation pour assurer la tolérance aux fautes
▪ Possibilité de rejouer les transformations vs checkpointing
IV. APACHE SPARK
4. Fonctionnement de Spark

1.Création
➢Chargement données depuis SGF distribué/local
➢Transformation d’une RDD existante
Note : RDD est une séquence d’enregistrements
2.Transformations
➢map : applique une fonction à chaque élément
➢filter : restreint aux éléments selon condition
➢join : combine deux RDD sur la base des clés
IV. APACHE SPARK
4. Fonctionnement de Spark
3. Actions
➢collect : retourne les éléments
➢count : comptes les éléments
➢save : écrit les données sur le SF
4. Paramétrage du stockage en mémoire
➢persist : force le maintien en mémoire
➢unpersist : force l’écriture sur disque
• Notes :
➢par défaut, les RDD sont persistantes en mémoire
➢Si manque d’espace alors écriture sur disque
➢Possibilité d’attribuer des priorités
IV. APACHE SPARK
4. Fonctionnement de Spark
IV. APACHE SPARK
5. Illustration d’une RDD
On considère une chaîne de traitements classique
1. Chargement depuis stockage (local ou hdfs)
2. Application d’un filtre simple
3. Cardinalité du résultat de 2
4. Paramétrage de la persistance

Lazy evaluation
Construire les RDDs seulement si action (mode pipelined)
Exemple : lines n’est construit qu’à la ligne 3
-> Chargement sélectif de file.txt
TD SPARK