Cours Big Data Niveau : L3

Chapitre VII :
Architectures Big Data

DR. RAOU DHA C HEBIL ENS I

Plan
 Introduction
 Motivations
 Contexte
 Architecture Lambda
 Architecture Kappa
 Autres architectures
 Etude de cas
 Conclusion
2
2

Enseignante : R. CHEBIL 1
Cours Big Data Niveau : L3

Motivations
L'exploitation des données massives ouvre des possibilités de
transformation radicales au niveau des entreprises et des
usages.

Mais pour atteindre cet objectif il y a plusieurs défis à relever :

 Acquisition
 Stockage
 Exploitation/analyse

3
3

Motivations
Il y a tellement d'outils autour des mégadonnées qu’il paraît
facile de mettre en place une architecture Big Data qui va à peu
près tenir la route.

Mais est-ce que ce sera une architecture de qualité ?

Quels sont les critères d’une bonne architecture Big Data?

La tolérance aux pannes
Une bonne maintenabilité
Un coût faible

4
4

Enseignante : R. CHEBIL 2
Cours Big Data Niveau : L3

Motivations
C’est exactement l’intérêt du rôle d’architecte des données
(data architect)!

L’architecte de données est responsable de :

La création et l'administration de tous les systèmes techniques
qui vont permettre la bonne exploitation des données.

5
5

Objectif

L’objectif de ce cours consiste à montrer comment définir des

interactions entre différentes technologies pour construire une
architecture Big Data répondant aux besoins en question.

6
6

Enseignante : R. CHEBIL 3
Cours Big Data Niveau : L3

Contexte

Volume

Variété Vélocité

Traitement?
7
7

Contexte

Batch
processing
Stream
NOSQL
processing

8
8

Enseignante : R. CHEBIL 4
Cours Big Data Niveau : L3

Traitement par lot

 Batch processing
 A accès à toutes les données
 Peut réaliser des traitements lourds et complexes
 Sa latence est calculée en minutes (voire plus)
 Est en général plus concerné par le débit que par la latence
des différents composants du traitement.
 Hadoop Map-Reduce est un exemple de système utilisant le
traitement par lot.
9
9

Traitement par lot – Limites

 Toutes les données doivent être prêtes avant le
début du job
N’est pas approprié pour des traitements en temps réel

 Latence d’exécution élevée

Produit des résultats sur des données relativement
anciennes

10
10

Enseignante : R. CHEBIL 5
Cours Big Data Niveau : L3

Traitement par lot – cas

d’utilisation
 Les chèques de dépôt dans une banque sont accumulés et
traités chaque jour

 Les statistiques par mois/jour/année

 Factures générées pour les cartes de crédit (en général

mensuelles)
 Traitement d’Evénements complexes CEP

11
11

Traitement par streaming -

caractéristiques
 Les traitements se font sur un petit nombre de données
récentes

 Doit compléter chaque traitement en un temps proche du

temps-réel

 La latence du traitement est estimée en secondes

12
12

Enseignante : R. CHEBIL 6
Cours Big Data Niveau : L3

Traitement par streaming -

Limites
 Pas de visibilité sur l’ensemble des données
Certains types de traitements ne peuvent pas être réalisés

 Complexité opérationnelle élevée

 Plus complexes à maintenir que les traitements batch
 Le système doit être toujours connecté, toujours prêt, avoir des temps
de réponses courts, et gérer les données à l’arrivée

 Risque de perte de données

13
13

Traitement par streaming – cas

d’utilisation
 Recommandations en temps réel
Prise en compte de navigation récente, géolocalisation
Publicité en ligne, re-marketing
 Surveillance de larges infrastructures
 Agrégation de données financières à l’échelle d’une banque
 Internet des objets
 Vente au détail : diminution du nombre de transactions
abandonnées de 80% en passant au traitement par streaming.

14
14

Enseignante : R. CHEBIL 7
Cours Big Data Niveau : L3

Traitement par streaming

Doug cutting :
« Le traitement par lots a constitué une première étape
naturelle, parce qu'il était relativement facile à mettre en œuvre
et offrait une valeur considérable »
Va-t-on abandonner le traitement par lot?
« Je ne pense pas qu'il y aura un mouvement général vers la
diffusion en continu. Elle vient plutôt simplement rejoindre la
suite d'options de traitement que les individus ont à leur
disposition. »

15
15

Architecture Lambda

 Créée par Nathan MARZ et James WARREN en 2011.

 Objectif : fournir un nouveau modèle de calcul qui soit
capable de faire du traitement presque temps réel (à faible
latence) sur des données de grand volume.
 Modèle Hybride
 Architecture indépendante de la technologie
 Basée sur le pré-calcul des résultats

16
16

Enseignante : R. CHEBIL 8
Cours Big Data Niveau : L3

Architecture Lambda
Architecture de :

 Traitement de données

 Requêtage de haut niveau

17
17

Architecture Lambda

18
18

Enseignante : R. CHEBIL 9
Cours Big Data Niveau : L3

Architecture Lambda
L’architecture Lambda est basée sur trois couches :

◦ Batch Layer : traitement des données historiques

◦ Speed Layer : traitement à faible latence

◦ Serving Layer : capacité d’interrogation et de consultation

qui unifie les 2 autres couches.

19
19

Batch Layer
Récupérer les données et les stocker sous leur format
brut dans des puits de données ;

Lancer périodiquement des traitements sur les données,

pour pré-calculer les résultats sous forme de vue logique :
batch views.

Le résultat est ensuite stocké typiquement dans des bases

en lecture seule et les mises à jour remplacent les vues
logiques pré-calculées.
20
20

Enseignante : R. CHEBIL 10
Cours Big Data Niveau : L3

Speed Layer
 Gère les données récentes uniquement

 Traite les nouveaux flux de données en temps réel, sans aucun

prétraitement.

 Calcule des vues incrémentales qui vont compléter les vues

batch afin de fournir des données plus récentes.

 Suppression des vues temps réel obsolètes (postérieures à un

traitement batch)
21
21

Serving Layer
 Permet d’indexer les batch views pour qu’elles soient
requêtées au besoin avec une faible latence.

 Rend exploitables les résultats pré-calculés par la couche

batch et la couche temps réel, pour effectuer des requêtes à la
volée (ad hoc).

22
22

Enseignante : R. CHEBIL 11
Cours Big Data Niveau : L3

https://www.slideshare.net/DanielMarcous/big-data-real-time-architectures-51967547 23
23

Architecture Lambda
Avantages

 Données de base sont immuables et conservées en entier avec

un historique qui pourrait être très utile en cas de panne…

 Grande tolérance aux pannes

 Supporte une variété de cas d’utilisation qui incluent un

requêtage à faible latence tout autant que des mises à jour

 Indépendante des technologies

 Facilement extensible 24
24

Enseignante : R. CHEBIL 12
Cours Big Data Niveau : L3

Architecture Lambda
Inconvénients

 La logique métier est implémentée deux fois (dans la filière

temps réel et dans la filière batch).

 Plusieurs frameworks à maîtriser.

 Peut s’avérer coûteuse en terme de mise en place et expertise

25
25

Architecture KAPPA
Constats :
 La plupart des solutions de traitement sont capables de traiter
à la fois des batchs et des flux.

 L’architecture Lambda est assez complexe.

 Éviter la maintenance de deux codes séparés (batch et speed)

Jay Kreps (LinkedIn) a proposé l’architecture KAPPA.

26
26

Enseignante : R. CHEBIL 13
Cours Big Data Niveau : L3

Architecture KAPPA
Idée :
Simplifier l’architecture Lambda en fusionnant les couches
temps réel et batch.
=>Manipuler les traitements batch et streaming en utilisant un
seul moteur de traitement de flux.

27
27

Architecture KAPPA
 Système de stockage des données est plus restreint que celui
de Lambda et doit être un système de fichiers de type log non
modifiable (tel que Kafka).

 Les données sont conservées pendant un certain temps

afin de pouvoir être retraitées en cas de besoin.

 Architecture dédiée au traitement.

28
28

Enseignante : R. CHEBIL 14
Cours Big Data Niveau : L3

Architecture KAPPA

29
29

Architecture KAPPA
La couche streaming "Stream Processing System" exécute le
traitement en temps réel.

Normalement, ce type de job est effectué pour les données

temps réel, mais dans Kappa, toute donnée est considérée
récente.

La couche de service, tout comme Lambda, est utilisée pour

requêter les résultats.

30
30

Enseignante : R. CHEBIL 15
Cours Big Data Niveau : L3

Architecture KAPPA
Avantages :

 Un seul système à gérer ;

 Des résultats near real time ;

 Architecture indépendante des technologies.

31
31

Architecture KAPPA
Inconvénients :

 Destinée au traitement mais ne permet pas le stockage ;

 Il n’y a pas de séparation entre les besoins.

32
32

Enseignante : R. CHEBIL 16
Cours Big Data Niveau : L3

Technologies
Collecte des données
• Kafka
• Apache Flume
• Samza

Batch
• MR (Hive, Pig etc.)
• Tez
• Spark

33
33

Technologies
Stream
• Storm
• Spark Streaming
• Samza
• Flink

34
34

Enseignante : R. CHEBIL 17
Cours Big Data Niveau : L3

Technologies
Serving

 Bases de données NOSQL

• HBase /Cassandra
• ElasticSearch
• MongoDB…

 Queries
• Impala
• Presto
• Big Query

35
35

Utilisateurs
Lambdas
o Twitter

o Spotify (music recommendations)

o Liveperson

o Inneractive

Kappas
o LinkedIn
o Yahoo

36
36

Enseignante : R. CHEBIL 18
Cours Big Data Niveau : L3

https://www.slideshare.net/DanielMarcous/big-data-real-time-architectures-51967547 37
37

Autres architectures
Autres architectures :
Zeta
Mu
iot – a

Regroupées sous le qualificatif polyglotte

Polyglot Programming
Utilisation de plusieurs langages et paradigmes de programmation dans
une seule application
Polyglot Persistence
Utilisation de plusieurs technologies de stockage

38
38

Enseignante : R. CHEBIL 19
Cours Big Data Niveau : L3

Etude de cas
 Pour concrétiser les aspects étudiés dans les transparents
précédents
 Pour voir mieux l’intérêt des architectures
 Nous nous focalisons sur l’architecture Lambda
 Prise d’un cours de openclassroom sur les architectures big
data :
https://openclassrooms.com/fr/courses/4467491-concevez-des-
architectures-big-data/4891241-faites-vos-premiers-pas-sur-la-lambda-
architecture

39
39

Etude de cas
Contexte :
 Administration d'une application web qui connaît un certain
succès.
 Des utilisateurs visitent le site, s'inscrivent, réalisent des
recherches et consultent des pages.
 Pour mesurer l'évolution de la popularité de l’application, il
est demandé de mettre en place les deux fonctionnalités
suivantes :
 Pour chaque page du site, donner le nombre de visites
qu'elle a reçues.
 Lister les 100 pages ayant reçu le plus grand nombre de
visites.

40
40

Enseignante : R. CHEBIL 20
Cours Big Data Niveau : L3

Etude de cas
Pour implémenter les deux fonctionnalités demandées, nous
avons besoin que d'une table visits dotée de deux colonnes
: url (de type VARCHAR) et count (de type BIGINT).

Nous allons voir pourquoi ce choix technique ne permet pas

de passer à l'échelle.

Au début, l’appli peut incrémenter les valeurs de count à

chaque visite.
A partir d’un certain nombre de visites et de pages,
l’incrémentation sera de plus en plus lente car les BDR ne sont
pas faites pour un grand nombre d’écritures concurrentes !
41
41

Etude de cas
=> remplacer la BDR par une BD NOSQL

On décide de remplacer MySQL par une solution NOSQL qui

supporte nativement le sharding (répartir les lignes sur
plusieurs serveurs) et assure la cohérence des données. Par
exemple, on choisit MongoDB.
L’architecture ressemble alors à cela :

42
42

Enseignante : R. CHEBIL 21
Cours Big Data Niveau : L3

Etude de cas

43
43

Etude de cas
Cette architecture passe à l'échelle sans problème : elle va
continuer à fonctionner en ajoutant de nouveaux workers et en
augmentant le sharding de la base MongoDB au fur et à
mesure de l'augmentation du nombre d'urls et de visites.

Si un jour il y a un bug, on n’a pas le moyen de recalculer le

nombre de visites!

On est obligés d'informer les utilisateurs du service d'analytics

que les stats de visite du site sont biaisées sur la période
pendant laquelle le bogue a été mis en production.
44
44

Enseignante : R. CHEBIL 22
Cours Big Data Niveau : L3

Etude de cas
=> les bases NOSQL sont indispensables au big data,
mais ne sont qu'une partie de la solution.

On ne peut pas se contenter de ne stocker que le

décompte agrégé des visites.
Pour être à l'abri d'une erreur de programmation, on doit faire
en sorte que les statistiques de visites des différentes pages
soient re-calculables à tout instant.
Pour cela, on doit disposer du log intégral de toutes les visites.
Ainsi on sera en mesure de regénérer les statistiques agrégées à
tout instant.
45
45

Etude de cas
Solution = architecture Lambda

46
46

Enseignante : R. CHEBIL 23
Cours Big Data Niveau : L3

Etude de cas
Les données reçues vont être collectées à l'état brut dans le
master dataset qui se trouve dans la batch layer. Ces données
seront agrégées et le résultat de ces agrégations sera exposé
aux clients par une vue dans la serving layer. Les clients
pourront alors faire des requêtes sur cette vue.

47
47

Etude de cas
La conception d'une architecture lambda est guidée par les contraintes
suivantes :
Passage à l'échelle : l'architecture proposée doit pouvoir passer à l'échelle
de manière horizontale, c'est à dire en ajoutant des serveurs. Cette
croissance doit se faire en garantissant la robustesse et la tolérance aux
pannes des différents systèmes.
Facilité de maintenance : les choix techniques réalisés doivent favoriser le
débogage et la modification des applications exploitant cette architecture.
Enfin, peu d'interventions manuelles doivent être nécessaires pour réaliser
la maintenance des systèmes.
Facilité d'exploitation des données : le but d'une architecture lambda
n'est pas uniquement de stocker des données, mais également de les mettre
à disposition d'autres applications pour les exploiter et en extraire de la
valeur. Il doit être possible de réaliser des analyses personnalisées sur ces
données de manière aisée.
48
48

Enseignante : R. CHEBIL 24
Cours Big Data Niveau : L3

Conclusion
Architectures :

 Indépendantes des technologies ;

 Basées sur le pré-calcul des résultats ;

 Permettent de contourner les contraintes de latence de

Hadoop.

49
49

Enseignante : R. CHEBIL 25