 Big Data = ensemble de technologies et méthodes permettant de collecter, stocker et

analyser rapidement des volumes massifs de données (structurées et non structurées),

souvent en temps réel, pour en tirer des insights utiles.

Challenges

• Volume énorme, difficile à stocker.

• Variété des formats (structurés, non structurés).

• Vitesse de création et de traitement.

• Besoin de qualité (Véracité) et de visualisation (Valeur).

Définitions & Vocabulaire

• Big Data = exploration de vastes ensembles pour insights utiles.

• Open Data = données ouvertes, réutilisables.(  Données ouvertes au public,

accessibles gratuitement ou librement.)

• Smart Data = données filtrées, utiles.

• NoSQL = bases non relationnelles.

• MapReduce, Hadoop, Cassandra, MongoDB = outils de traitement distribué.

 MapReduce : modèle de programmation qui découpe un gros calcul en petites tâches
distribuées sur plusieurs machines.

Hadoop : framework open source basé sur MapReduce, pour stocker et traiter des
données massives.

Cassandra : base NoSQL distribuée, très performante pour gérer de gros volumes.

MongoDB : base NoSQL orientée documents, flexible et populaire.

Tous ces outils servent à traiter le Big Data de manière distribuée (plusieurs serveurs
travaillent ensemble).

6. Les 5V du Big Data

• Volume : quantité énorme (Go → Yottabytes).

• Variété : données structurées / non structurées.

• Vélocité : rapidité d’arrivée et de traitement.

• Valeur (Visualisation) : transformer les données en insights.

• Véracité : qualité et fiabilité des données.

1. Hadoop

• Apache Hadoop = framework open source pour le calcul distribué.

• Avantages : tolérance aux pannes, extensible, facile à déployer, multi-langages (Java,

Python, etc.).

• Deux composants principaux :

• HDFS (Hadoop Distributed File System) → stockage distribué.

• MapReduce → traitement distribué.

2. HDFS

• Inspiré du Google File System (GFS).

• Stocke les données en blocs (64 Mo ou 128 Mo).

• NameNode (NN) = maître, gère la localisation des blocs.

• DataNode (DN) = esclaves, stockent les blocs.

• Replication factor = nombre de copies (souvent 3).

• Lecture/écriture : le client contacte le NN, puis les DN.

• Problème : NN = point unique de défaillance → solution = Standby NameNode.

3. MapReduce

• Paradigme de programmation distribué (Google, 2004).

• Principe : Divide and Conquer.

• Étapes :

1. Split → découper les données.

2. Map → transformer en couples (clé, valeur).

3. Shuffle → regrouper par clé.

4. Reduce → agréger les valeurs par clé.

• Exemple classique : WordCount (compter les occurrences de mots).

4. Écosystème Hadoop

• Hive ( C’est un outil qui permet d’écrire des requêtes SQL sur des données stockées
dans Hadoop.

• ), Pig ( Langage de script (Pig Latin) pour manipuler les données dans Hadoop),

• HBase ( Base de données NoSQL orientée colonnes, construite sur Hadoop.

• ).

• Sqoop, Flume, Kafka → intégration et transfert de données.

Sqoop : transfert de données entre Hadoop et bases relationnelles (SQL).

 Flume : collecte et transfert de gros volumes de logs vers Hadoop.

Kafka : système de messagerie distribué (publish/subscribe), très utilisé pour les flux de
données en temps réel.

• Spark → concurrent de MapReduce, plus rapide (in-memory).

• Extensions : Storm, Spark Streaming (temps réel), Mahout/Spark ML (Machine Learning),

Solr/Elastic (moteurs de recherche).

• Distributions majeures : HortonWorks, Cloudera, MapR.

Architecture fonctionnelle

 JobTracker :

distribue les sous-tâches aux machines.

 TaskTracker : exécute les tâches Map/Reduce sur les blocs de données.

 Communication constante via heartbeats (signaux de vie).

 Master Node = machine avec JobTracker + NameNode.

Slave Nodes = machines avec TaskTracker + DataNode.

Programmation MapReduce en Java

• Trois classes principales :

o Driver : configure le job (classes Map/Reduce, types de données, fichiers HDFS).

o Mapper : transforme les données en couples (clé, valeur).

o Reducer : agrège les valeurs par clé.

• Exemple classique : WordCount (compter les occurrences de mots).

• Mapper : chaque mot → (mot, 1).

• Reducer : somme des valeurs pour chaque mot → (mot, nombre total).

• Le fonctionnement de MapReduce sous Hadoop peut se résumer ainsi : tu as un

énorme fichier de données (par exemple des millions de lignes de texte) que tu veux
analyser. Hadoop commence par découper ce fichier en morceaux et les distribue à
plusieurs machines du cluster. Chaque machine applique alors la fonction Map, qui
transforme les données en petites paires (clé, valeur) faciles à manipuler, comme (mot,
1) pour dire “j’ai trouvé ce mot une fois”. Ensuite, Hadoop regroupe automatiquement
toutes les paires ayant la même clé grâce à l’étape Shuffle (par exemple, toutes les
occurrences du mot “am” sont regroupées ensemble). Enfin, la fonction Reduce prend
chaque clé et additionne les valeurs associées pour donner un résultat final, comme
(am, 3) si le mot “am” apparaît trois fois. Tout ce processus est orchestré par le
JobTracker (qui distribue les tâches) et les TaskTrackers (qui exécutent les calculs
sur les données stockées dans HDFS). En résumé, le développeur n’a qu’à écrire le
 code des fonctions Map et Reduce, et Hadoop s’occupe de tout le reste : découpage,
distribution, regroupement, tolérance aux pannes.

Au départ, Hadoop obligeait les développeurs à écrire du code Java pour définir les fonctions
Map et Reduce, ce qui était puissant mais compliqué et long. Pour simplifier, des langages de
requêtes ont été créés afin de rendre l’utilisation de Hadoop plus accessible.

-Pig (Yahoo!) propose un langage appelé Pig Latin basé sur des flux de données, avec des
commandes simples comme LOAD, TRANSFORM et DUMP/STORE pour charger, transformer et
sauvegarder les résultats.

-Hive (Facebook) permet d’écrire des requêtes en HiveQL, un langage très proche du SQL, ce
qui facilite le travail des analystes qui connaissent déjà SQL et veulent interroger des données
massives dans Hadoop. Enfin,

-Jaql (IBM) est un langage orienté JSON et semi-structuré, qui fonctionne comme un pipeline
avec des étapes successives (read → filter → transform → write), idéal pour manipuler des
données comme JSON, XML ou CSV.

En résumé, Pig, Hive et Jaql traduisent automatiquement les instructions simples de l’utilisateur
en jobs MapReduce, évitant ainsi d’avoir à coder directement en Java.

1. Qu’est-ce que Spark ?

• Apache Spark = moteur de traitement distribué, open source, créé en 2009 (UC
Berkeley).

• Plus rapide que Hadoop MapReduce car il utilise la mémoire (in-memory) au lieu
d’écrire/relire sur disque à chaque étape.

• Compatible avec HDFS, Hive, HBase, etc.

• Supporte plusieurs langages : Scala, Python, R, Java.

• Permet aussi le temps réel (streaming).

RDD (Resilient Distributed Dataset)

• Structure de base de Spark.

• RDD = collection distribuée d’objets, stockée en mémoire, tolérante aux pannes.

• Transformations possibles : map, filter, flatMap, reduceByKey, groupByKey, etc.

• Actions : collect(), count(), first(), take(n), reduce().

3. Facilité d’utilisation

• Exemple WordCount en Java MapReduce = dizaines de lignes de code.

• Exemple WordCount en Spark (Scala) = quelques lignes :

file = [Link]("hdfs://...") [Link](line => [Link](" ")) .map(word => (word, 1))
.reduceByKey(_ + _)

Spark est beaucoup plus concis et lisible.

4. Écosystème Spark

• Spark Core : moteur principal.

• Spark SQL / Shark : requêtes SQL rapides.

• Spark Streaming : traitement temps réel des flux.

• MLlib : machine learning (classification, clustering, régression).

• GraphX : calculs sur graphes.

• SparkR : interface R sur Spark.

5. Exemple pratique

• Fichier CSV avec arbres de Paris (hauteur, année de plantation).

• Objectif : trouver l’année de plantation de l’arbre le plus grand.

Avec Spark (PySpark), quelques lignes suffisent : charger fichier, transformer, filtrer, trier,
afficher le premier résultat.

Bases NoSQL

1. Pourquoi NoSQL ?

• Les SGBD relationnels (RDBMS) classiques atteignent leurs limites avec le Big Data :

o Trop coûteux à distribuer.

o Difficile de maintenir les contraintes ACID (Atomicité, Cohérence, Isolation,

Durabilité) sur des systèmes massifs.

• Les géants du web (Google, Amazon, Facebook…) ont donc inventé des bases NoSQL
pour gérer des données massives, variées et distribuées.

• NoSQL = Not Only SQL → complément aux bases relationnelles, pas un remplacement
total.

2. Caractéristiques générales

• Non relationnelles (pas de tables fixes).

• Schéma flexible ou absent (les données peuvent être semi-structurées ou non

structurées). ( Dans NoSQL, tu peux ajouter ou enlever des champs librement.

Exemple : un client peut avoir un champ âge, un autre non → pas de problème.

• Distribution horizontale (scalabilité en ajoutant des serveurs). ( Si tu as trop de

données, au lieu d’acheter un super-ordinateur, tu ajoutes plusieurs serveurs normaux.
 Les données sont réparties entre eux.

Exemple : Facebook stocke ses milliards de messages en les répartissant sur des
milliers de serveurs.)

• Réplication des données pour disponibilité.

• Souvent privilégient Disponibilité + Partition tolerance (AP) plutôt que Cohérence

stricte (théorème de CAP).

• Mode d’utilisation : beaucoup de lectures, peu d’écritures complexes.

3. Taxonomie des bases NoSQL

• Clé/Valeur (Key-Value Store)

o Données sous forme de paires clé → valeur.

o Très simple, rapide, scalable.

o Exemples : Redis, Riak, Voldemort.

o Utilisation : sessions, cache, profils utilisateurs, paniers d’achat.

• Colonnes (Column Store)

o Données stockées par colonnes, pas par lignes.

o Très adapté aux données massives et semi-structurées.

o Exemples : Cassandra, HBase.

o Utilisation : logs, BI, analyse clientèle.

• Documents (Document Store)

o Valeur = document JSON ou XML, flexible et hiérarchique.

o Exemples : MongoDB, CouchDB.

o Utilisation : profils utilisateurs, contenus web.

• Graphes (Graph Databases)

• Données organisées en nœuds et relations.

• Exemples : Neo4j, OrientDB.

• Utilisation : réseaux sociaux, recommandations, relations complexes.

4. Avantages / Inconvénients

Avantages :

• Scalabilité horizontale.

• Flexibilité du schéma.

• Performance en lecture/écriture.
• Adapté aux données massives et hétérogènes.

Inconvénients :

• Moins de cohérence stricte (ACID relâché).

• Requêtes parfois limitées (pas de jointures complexes).

• Complexité reportée sur l’application.

MongoDB

1. Qu’est-ce que MongoDB ?

• Base de données NoSQL orientée documents, écrite en C++.

• Stocke les données sous forme de documents JSON (flexibles, hiérarchiques).

• Supporte la réplication maître/esclave (sécurité et disponibilité).

• Interprète les requêtes en JavaScript côté serveur.

• Limite : taille max d’un document = 4 Mo (pour les gros fichiers → système GridFS).

• Utilisée pour des bases de grande taille avec hautes performances.

2. Installation et instance

• Répertoire par défaut : /data/db.

• Serveur lancé avec mongod (port par défaut 27017).

• Outils principaux :

• mongod (moteur),

• mongo (shell interactif),

• mongos (sharding),

• mongoimport/export, mongodump/restore (sauvegarde),

• mongostat (stats), mongosniff (analyse réseau).

3. Bases et collections

• Base de données : créée avec use .

• Collections : équivalent des tables relationnelles.

o Création : [Link]("nom").

o Insertion : [Link]({ champ1:"valeur", champ2:"valeur" }).

o Suppression : [Link]().

• Documents : équivalent des enregistrements (tuples).

• Stockés en JSON.

• Chaque document a un champ _id (clé primaire auto-générée).

4. Requêtes

• findOne() → retourne un document.

• find() → retourne une liste de documents.

• Exemples :

o [Link]({ titre:"Germinal" })

o [Link]({"[Link]":"Zola"}, {titre:1})

o [Link]({"annee":{$gt:2000}}, {titre:1})

• Fonctions d’agrégation : count, distinct, group.

• Indexation possible pour optimiser les recherches.

Réplication (Replica Sets)

La réplication sert à sécuriser les données et assurer la disponibilité même si un serveur

tombe en panne.

• Primaire (Primary) :

o C’est le serveur principal.

o Toutes les opérations d’écriture (insert, update, delete) passent par lui.

o Les lectures par défaut passent aussi par lui.

• Secondaires (Secondary) :

o Ce sont des copies du primaire.

o Ils reçoivent automatiquement les mises à jour du primaire (via un journal appelé
oplog).

o Ils servent surtout pour la lecture (lecture seule).

• Élection automatique :

o Si le primaire tombe (panne, crash), les secondaires organisent une élection

pour choisir un nouveau primaire.

o Cela garantit que le système continue de fonctionner sans interruption.

• Arbitre (Arbiter) :

• C’est un serveur spécial qui ne stocke pas de données.

• Son rôle est uniquement de voter lors d’une élection pour départager les secondaires.

• Exemple : si tu as 2 secondaires, l’arbitre permet d’avoir un nombre impair de votes pour

éviter les égalités.

En résumé : Replica Set = 1 primaire + plusieurs secondaires + éventuellement un

arbitre → haute disponibilité et sécurité des données.
 Sharding (Partitionnement horizontal)

Le sharding sert à répartir les données sur plusieurs serveurs pour gérer des bases
énormes.

• Pourquoi ?

o Si une base devient trop grosse pour tenir sur un seul serveur, on la découpe en
morceaux (chunks) et on les distribue sur plusieurs serveurs.

o Cela permet de scaler horizontalement (ajouter des serveurs au lieu de

renforcer un seul).

• Composants du sharding :

o Shards : ce sont les serveurs qui contiennent les données (chaque shard est
souvent un Replica Set pour la sécurité).

o Config servers : stockent la configuration du cluster (qui contient quoi, où).

o mongos : c’est le routeur. Quand une application envoie une requête, mongos
décide vers quel shard envoyer la requête.

• Clé de sharding :

• C’est un champ choisi dans les documents (par ex. user_id).

• Cette clé détermine comment les données sont réparties entre les shards.

• Exemple : les utilisateurs avec ID 1–1000 vont sur shard A, ceux avec ID 1001–2000 sur
shard B, etc.

En résumé : Sharding = découper les données en morceaux et les répartir sur

plusieurs serveurs grâce à un routeur (mongos) → permet de gérer des bases
gigantesques.

1. Qu’est-ce que Cassandra ?

• Base NoSQL orientée colonnes.

• Initiée par Facebook, écrite en Java.

• Architecture P2P (peer-to-peer) → pas de maître unique, tous les nœuds sont égaux.

• Haute disponibilité (pas de SPOF = Single Point Of Failure).

• Scalabilité linéaire : plus tu ajoutes de nœuds, plus tu augmentes la capacité.

• Optimisée pour les écritures rapides (plus rapide à écrire qu’à lire).

• Utilise le protocole Gossip pour que les nœuds échangent des infos entre eux.

2. Partitionnement

• Les données sont réparties sur les nœuds du cluster grâce à une clé de partition.

• Deux stratégies principales :

 o RandomPartitioner (par défaut) → répartit équitablement les données via un
hash.

o ByteOrderedPartitioner → range les clés par ordre, mais peut créer des
déséquilibres.

• Chaque nœud est responsable d’une partie des données.

3. Réplication

• Définie par le Replication Factor (RF) → nombre de copies des données dans le cluster.

• Stratégies :

o SimpleStrategy → copie sur le nœud suivant (utile pour un seul DataCenter).

o NetworkTopologyStrategy → copie sur différents racks ou DataCenters (plus

robuste).

• Utilisation des Snitch pour définir la topologie (ex. Simple Snitch, Rack-Inferring, EC2
Snitch).

4. Consistance

• Cassandra est P2P : tu peux lire/écrire depuis n’importe quel nœud.

• Le Consistency Level définit combien de répliques doivent répondre avant de valider

une opération.

• Écriture :

o Données d’abord dans un commit log (durabilité).

o Puis en mémoire (MemTable).

o Ensuite sur disque (SSTable).

• Stratégies d’écriture :

o ANY → au moins un nœud (disponibilité max, cohérence faible).

o ONE → au moins une réplique.

o QUORUM → majorité des répliques.

o ALL → toutes les répliques (cohérence max, disponibilité faible).

• Stratégies de lecture similaires (ONE, QUORUM, LOCAL-QUORUM, EACH-QUORUM,

ALL).

• Mécanismes de correction : Hinted Handoff (rattrapage des nœuds en panne), Read

Repair (synchronisation en lecture).

5. Gestion et outils

• CQL (Cassandra Query Language) → langage proche du SQL pour manipuler

Cassandra.

o CREATE, ALTER, DROP, INSERT, UPDATE, DELETE, SELECT.

 o Pas de jointures complexes ni de GROUP BY avancé.

• OPSCenter (DataStax) → outil graphique de monitoring et administration.

• Drivers et mappings : Hector (Java), Pycassa (Python), PhpCassa (PHP).

Théorème de CAP

Le théorème de CAP dit qu’un système distribué (plusieurs serveurs qui travaillent
ensemble) ne peut pas garantir en même temps les 3 propriétés suivantes :

1. C = Cohérence (Consistency)

o Tous les serveurs voient exactement les mêmes données au même moment.

o Exemple : si tu retires 100 € de ton compte à Tunis, le serveur à Paris doit

immédiatement voir que ton solde a baissé.

o Cohérence stricte = pas de décalage entre les copies.

2. A = Disponibilité (Availability)

o Le système répond toujours aux requêtes, même si certains serveurs tombent

en panne.

o Exemple : tu peux toujours consulter ton fil Facebook, même si un serveur est en
panne.

o Disponibilité = le service ne s’arrête jamais.

3. P = Tolérance au partitionnement (Partition tolerance)

• Le système continue à fonctionner même si la communication entre certains serveurs

est coupée (réseau divisé en morceaux).

• Exemple : si le serveur en Europe ne peut plus parler au serveur en Amérique, chacun

continue à répondre aux utilisateurs de sa région.

• Partition tolerance = résister aux coupures réseau.

Pourquoi les bases NoSQL privilégient AP (Disponibilité + Partition tolerance)

• Dans les systèmes modernes (web, big data), les coupures réseau et les pannes de
serveurs sont inévitables.

• Les utilisateurs veulent que le service reste toujours disponible (A) et qu’il continue à
fonctionner même si le réseau est divisé (P).

• La cohérence stricte (C) est souvent sacrifiée, car il vaut mieux avoir une donnée
légèrement en retard que de bloquer tout le système.

• Exemple concret :

• Sur Amazon, si tu ajoutes un produit au panier, il peut apparaître avec quelques

secondes de retard sur un autre serveur.
• Mais le site reste disponible et tu peux continuer à acheter → priorité à Disponibilité
+ Partition tolerance.