Introduction aux Big Data

Introduction
Chaque jour, nous générons 2,5 trillions d’octets de données
90% des données dans le monde ont été créées au cours des deux dernières années
90% des données générées sont non structurées
Source:
◦ Capteurs utilisés pour collecter les informations climatiques
◦ Messages sur les médias sociaux
◦ Images numériques et vidéos publiées en ligne
◦ Enregistrements transactionnels d’achat en ligne
◦ Signaux GPS de téléphones mobiles
◦…
Données appelées Big Data ou Données Massives

2
Big Data - Définition
“Le Big Data (ou mégadonnées) représente les collections de
données caractérisées par un volume, une vélocité et une
variété si grands que leur transformation en valeur utilisable
requiert l’utilisation de technologies et de méthodes analytiques
spécifiques."

3
Big Data - Pourquoi?
 Augmentation exponentielle de la quantité de données non structurées
 Email, chat, blog, web, musique, photo, vidéo, etc.
 Augmentation de la capacité de stockage et d’analyse
 L’utilisation de plusieurs machines en parallèle devient accessible
 Les technologies existantes ne sont pas conçues pour intégrer ces données
 Bases de données relationnelles (tabulaires), mainframes, tableurs (Excel), etc.
 De “nouvelles” technologies et techniques d’analyse sont nécessaires
 “Google File System” - Google 2003
 “MapReduce: Simplified Data Processing on Large Clusters” - Google, 2004
 Hadoop: circa 2006
 D’où le “Big Data”: pas strictement plus de data...

4
Utilisations multiples
Sources multiples: sites, bases de données, téléphones, serveurs:
◦ Détecter les sentiments et réactions des clients
◦ Détecter les conditions critiques ou potentiellement mortelles dans les hôpitaux , et à temps
pour intervenir
◦ Prédire des modèles météorologiques pour planifier l’usage optimal des Éoliennes
◦ Prendre des décisions risquées basées sur des données transactionnelles en temps réel
◦ Identifier les criminels et les menaces à partir de vidéos, sons et flux de Données
◦ Étudier les réactions des étudiants pendant un cours, prédire ceux qui vont réussir, d’après
les statistiques et modèles réunis au long des années (domaine Big Data in Education)

5
Challenges
 Réunir un grand volume de données variées pour trouver de nouvelles idées

 Capturer des données créées rapidement

 Sauvegarder toutes ces données

 Traiter ces données et les utiliser

 Analyser rapidement de larges quantités et contenus hétérogènes et

changeants, et en extraire les informations pertinentes à un coût accessible

6
BDD Relationnelles
 Existent depuis plus de 48 ans
 Utilisent l’Algèbre relationnelle
 Forte consistance, concurrence, récupération
 Populaire
 Langage de requête standard (SQL)
 Fonctionne très bien dans la plupart des cas

7
Avantages
 Transactions ACID
 Contexte mathématique (Algèbre relationnelle)
 Langage de requête standard (SQL)
 Garantie de la non duplication des données
 SQL et SGBDR ont rendu les requêtes flexibles avec des schémas rigides
 Un écosystème massif d’outils, de bibliothèques et d’intégrations
 Existe depuis plus de 48 ans

8
Propriétés ACID
Atomicité : L’ensemble des opérations d’une transaction est soit exécuté en
bloc, soit annulé en bloc

Cohérence : Les transactions respectent les contraintes d’intégrité de la base

Isolation : Deux exécutions concurrentes de transactions résultent en un état

équivalent à l’exécution sérielle des transactions

Durabilité : Une fois une transaction confirmée, les données correspondantes

restent durablement dans la base, même en cas de panne

9
Inconvénients
 Schéma défini, attributs optionnels (NULL)
 Les requêtes sont parfois très complexes (jointure)
 Utilisation des jointures pour agréger des données liées
 Mise à l'échelle horizontale difficile (horizontal scaling)
 Les jointures sont couteuses
 Lenteur causée par les transactions ACID

10
C’est quoi une BDD NoSQL ?
 La théorie et les offres NoSQL modernes ont débuté au début des années
2000
 L’usage moderne du terme NOSQL introduit en 2009
 NoSQL = Not Only SQL (pas seulement SQL)
 Une collection de produits très différents
 Alternatives aux bases de données relationnelles quand elles sont un
mauvais ajustement

11
NoSQL
 Principalement utilisé sur des clusters de serveurs
 Permet un modèle qui peut s’étendre plus facilement (scalability)
 Assouplit les contraintes habituellement présentes sur les bases de données
relationnelles
 Permet de gérer rapidement des tonnes de données

12
Big Data
Gartner utilise les 3V pour définir:
Volume
 Volume important
Variété
 données changeantes ou évolutives
 Formats non contrôlés
 N'adhère pas facilement à un seul schéma
 Inconnu au moment de la conception
Rapidité
 Données entrantes élevées ou volatiles
 Hautes requêtes et lectures
 Faible latence
13
L’ère des Systèmes distribués
 A cause de la quantité énorme de données qui est apparue la seule solution
pour remédier a ce problème était les systèmes distribués
 Ce qui a introduit à la terminologie horizontal scaling
 L’apparition du théorème de CAP.

14
BASE
Les propriétés ACID sont incompatibles avec le NoSQL  Propriétés BASE
Basic Availability : le système garantit la disponibilité des données et il y aura une
réponse à toute demande
Soft-state : La base peut changer lors des mises à jour ou lors d'ajout/suppression
de serveurs. La base NoSQL n'a pas à être cohérente à tout instant, elle est
« souple »
Eventual consistency : Au fur et à mesure que des données sont ajoutées au
système, son état est progressivement répliqué sur tous les nœuds (consistance à
terme).

15
Théorème de CAP
Théorème formalisé en 2000 par Eric A. Brewer qui repose sur 3 propriétés des
bases de données (relationnelles, NoSQL et autres) :
Consistency (cohérence) : Une donnée n'a qu'un seul état visible quel que soit le
nombre de réplicas
Availability (Disponibilité) : Tant que le système tourne (distribué ou non), la
donnée doit être disponible
Partition Tolerance (Distribution) : Le système continue de fonctionner et
maintient sa cohérence malgré les partitions de réseau

Un système distribué ne peut prendre en charge que deux de ces

caractéristiques

16
Théorème de CAP
CA (Consistency-Availability) : lors d'opérations concurrentes sur une même
donnée, les requêtes L1 et L2 retournent la nouvelle version (v2) et sans délai
d'attente. Cette combinaison n'est possible que dans le cadre de bases de
données transactionnelles telles que les SGBDR.

17
Théorème de CAP
CP (Consistency-Partition Tolerance) : distribution des données sur plusieurs serveurs en
garantissant la tolérance aux pannes (réplication). En même temps, il est nécessaire de
vérifier la cohérence des données en garantissant la valeur retournée malgré des mises à jour
concurrentielles. La gestion de cette cohérence nécessite un protocole de synchronisation
des réplicas, introduisant des délais de latence dans les temps de réponse (L1 et L2 attendent
la synchronisation pour voir v2). C'est le cas de la base NoSQL MongoDB.

18
Théorème de CAP
AP (Availability-Partition Tolerance) à contrario s'intéresse à fournir un temps de réponse
rapide tout en distribuant les données et les réplicas. De fait, les mises à jour sont
asynchrones sur le réseau, et la donnée est "Eventually Consistent" (L1 voit la version v2,
tandis que L2 voit la version v1). C'est le cas de Cassandra dont les temps de réponses sont
appréciables, mais le résultat n'est pas garanti à 100% lorsque le nombre de mises à jour
simultanées devient important.

19
Le triangle de CAP et les bases de
données

20
Avantages des BD NoSQL
 Conçu pour les systèmes distribués
 La BD n’a pas de schéma (flexible)
 BASE transactions
 Les requêtes sont simples (pas de jointure)
 Mise à l'échelle horizontale (scale out)
 Développement rapide

21
Inconvénients des BD NoSQL
 Pas de schéma
 Pas un langage de requête standard
 Pas de transactions ACID.

22
SQL vs NOSQL
SQL NOSQL
Type Relationnel Non-relationnel
Données Données structurées stockées dans des Données non structurées
tables
Schéma Statique Dynamique/Pas de schéma
Scalabilité Verticale Horizontale
Langage Langage de requêtes structurées Langage de requêtes non structurées
Jointures Jointures complexes Requêtes limitées/Pas de jointures
Flexibilité Schéma rigide Schéma non-rigide et flexible
Transactions ACID Théorème de CAP / BASE

23
Les type du BDD NOSQL
 BDD Clé / valeur
 BDD Orienté Document
 BDD Orienté Colonne
 BDD Orienté Graph

24
BDD Clé / valeur
 Le but de la famille clé-valeur est l'efficacité et la simplicité.
 Un système clé-valeur agit comme une énorme table de hachage distribuée
sur le réseau.
 Tout repose sur le couple Clé/Valeur :
 La clé identifie la donnée de manière unique et permet de la gérer.
 La valeur contient n'importe quel type de données.
 Pas de schéma, ni structure pour le stockage.
 D'un point de vue de bases de données, il n'y a pas la possibilité d'exploiter ni
de contrôler la structure des données et de fait, pas de langage (SQL =
Structured Query Language).

25
26
BDD Orientées Documents
 Conçues pour gérer et stocker les documents
 Pas de schéma
 Ces documents sont encodés dans un format standard d'échange de données
tel que XML, JSON (notation d'option JavaScript) ou BSON (JSON binaire)
 Généralement, un modèle d’échange de type JSON (BSON), qui prend en
charge les listes, cartes, dates, objets avec imbrication
 Modèle de requête: JavaScript ou personnalisé
 Agrégations: map / reduce.

27
28
BDD Orientées Colonnes
 Traditionnellement, les données sont représentées en colonnes
 Il est alors possible de focaliser les requêtes sur une ou plusieurs colonnes,
sans avoir à traiter les informations inutiles (les autres colonnes).

29
BDD Orientées Colonnes
 Elle consiste en une paire clé/valeur dans laquelle la valeur consiste en un
ensemble des colonnes
 Les bases de données de familles de colonnes sont représentées dans des
tables, chaque paire clé/valeur étant une ligne
 Toutes les données associées peuvent être regroupées dans une même famille
 Conçu pour stocker une quantité énorme de données
 Facile pour le scaling horizontale

30
BDD Orientées Graphes
 Les trois premières familles NoSQL n'adressent pas le problème de
corrélations entre les éléments  apport des BD orientées graphes
 Basé sur la théorie des graphes
 Pratique lorsque les relations entre les données peuvent être représentées
sous forme de graphes
 Plus complexe à utiliser
 Les requêtes et les mises à jour de grandes quantités de données peuvent
être très lentes

31
BDD Orientées Graphes
 Données stockées sont : les nœuds, les liens et des propriétés sur ces
nœuds et ces liens.

 Les requêtes que l'on peut exprimer sont basées sur la gestion de
chemins, de propagations, d'agrégations, voire de recommandations.

 Toutefois, contrairement aux solutions précédentes la distribution

des nœuds sur le réseau n'est pas triviale.

32
33