[USI] Lambda-Architecture : comment réconcilier BigData et temps-réel

www.usievents.com #USI2014
Lambda-architecture
ou comment réconcilier les Big-Data avec le temps réel
Mathieu DESPRIEE
@mdeocto

λ-ARCHITECTURE
Quels use-cases ?
Qu’est-ce que la lambda-architecture ?
Quels sont ses principes, comment elle se construit ?
Quelles technologies pour l’implémenter ?

Origines
manning.com/marz
Nathan Marz
Ex-Backtype & Twitter
Initiateur des frameworks
Storm
Cascalog
ElephantDB
Backtype
Capture d’événements et de
logs Twitter pour analyse
25 TB binary data
100 Billions of records
400 QPS Average

BigData + Temps Réel :
Pour quels use-cases ?
Recommandation en temps-réel
Prise en compte de la navigation récente, geolocalisation
Pour : re-marketing, publicité en ligne…
Surveillance de larges infrastructures
Telcos, Industrie, grands data-centers…
Smart-metering
Agrégation de données financières à l’échelle d’une banque
Internet des objets
…
Des flux de données à prendre en compte en temps-réel
Des historiques très volumineux qui recèlent de la valeur

Prend en charge toutes les données
qu’elles soient historique ou datent de la
dernière seconde
Capable de répondre à n’importe quel
type de requête
analytique, datamining, search…
Tolérant les pannes
Robuste aux évolutions, aux erreurs
Scalable :
x 10 TB en stockage
x 1’000 evt / second
x 100 query / second
Basse latence en écriture ET en lecture
Le système BigData à construire
data
flow
big data system
queries
application

De quelles données parle-t-on ?
un tweet
un utilisateur qui se loggue
un utilisateur qui donne une nouvelle adresse
un hit sur un serveur web
un paiement
une métrique d’infrastructure
 Tout est événement
des faits
datés
immuables (« éternellement vrais »)

La bonne vieille base de données
Ex d’une action utilisateur (changement d’adresse) :
Le problème : chaque UPDATE détruit les informations
précédentes
UPDATE

Stockage immuable
Pas d’UPDATE, seulement des INSERT
Toute autre information peut être dérivée/reconstruite à
partir de ces données brutes

Immuabilité : quels gains ?
Performance du stockage
APPEND-only est très performant, ex. Hadoop/HDFS
Pensez-y, au cœur d’une base SQL, il y a un append-log,
qui est le maître en cas de crash…
Robustesse aux erreurs humaines
Un bug ne viendra jamais détruire de la donnée, seulement
ajouter des enregistrements erronés (ou doublonnés, ou…)
Facile à corriger :
Soit on vient supprimer les lignes erronées,
Soit on ajoute des lignes correctrices

Principe #1
Une architecture basée sur des données immuables

query = function ( ALL data )

ALL
DATA
precomputed
view
query
( ie. on sépare les problèmes : stockage, calcul, lecture )
Principe #2
Une architecture basée sur des vues précalculées

hashtag hour_range count
#usi2014 09:00 12
#usi2014 10:00 138
#usi2014 11:00 12543
#lambda 11:00 42
… … …
hashtag day_range count
#usi2014 15/06 12
#usi2014 16/06 138
#lambda 15/06 5
… … …
hashtag user count
#lambda @mdeocto 5
#lambda @nathanmarz 2045
#lambda @mhausenblas 230
… … …
Vues précalculées
Pour chaque classe de requête, on
précalcule des vues dédiées
dénormalisées
indexées
rapides à requêter
supportant des opérations simples
(sum, count…)

SERVING
LAYER
SPEED LAYER
BATCH LAYER
DATA FLOW QUERIES
λ-ARCHITECTURE
REAL TIME
STREAM PROCESSING
BATCH
PROCESSING
PRECOMPUTED
VIEWS

BATCH LAYER

DATA FLOW QUERIES
BATCH LAYER
BATCH
PROCESSING
« BATCH VIEWS »
Batch Layer
Stockage maître + traitements batch
MASTER DATA

Batch Layer : quelle techno ?
Besoins :
Stockage scalable
Tolérant aux pannes
Robuste
notamment aux évolutions de schéma
Permettant tout type de processing

SERVING LAYER

real-time
processing
SPEED LAYER
REAL TIME
STREAM PROCESSING
DATA FLOW QUERIES
BATCH LAYER
SERVING
LAYER
Vues précalculées
2
1
batch processing
full dataset
BATCH VIEW
DATABASE
publish

Stockage des vues : quelle techno ?
Besoins :
Ecritures massives
Lectures indexées (accès aléatoire) à faible temps de
réponse
Scalable et tolérant à la panne

maintenant
TEMPS
Données prises en compte
dans les batch views
Pas encore
absorbées
QUELQUES HEURES
DE DONNÉES

SPEED LAYER

SPEED LAYER
REAL TIME
STREAM PROCESSING
DATA FLOW QUERIES
Speed Layer
Le rôle du speed layer est de mettre à jour des vues, en continu, de
manière incrémentale
La latence de traitement doit être de l’ordre de 10ms à qqs
secondes
« REAL-TIME VIEWS »

Speed layer : caractéristiques recherchées
Traitement en continu (stream processing)
Architecture asynchrone, distribuée et scalable
Tolérant à la panne
Si possible avec des garanties de traitement
capacité à rejouer automatiquement des messages en cas
de perte d’un nœud

Speed layer : technologies
Pour des petites topologies : Queues + Workers
Storm
Spark

Focus : Storm
Framework initié par N. Marz
Storm est un framework de traitement
distribué orienté flux d’événements
prenant en charge :
management de multiple nœuds
queueing, routage
serialisation / de-serialisation
reprise sur panne
Storm est nativement distribué,
performant, tolérant les pannes, et
permet de garantir le traitement des
événements

SPEED LAYER
REAL TIME
STREAM PROCESSING
DATA FLOW QUERIES
Real-time views
Les vues produites doivent pouvoir être requêtées de
façon intensive et performante
temps de réponse court
et fort débit de requête attendu
« REAL-TIME VIEWS »
SERVING
LAYER

Real-time views : quelle techno ?
Besoins :
Doit supporter de fortes sollicitations en lecture
(requêtes) et écritures (mises-à-jour incrémentales)
Doit être scalable et tolérant à la panne
Des fonctions avancées peuvent être utiles à ce niveau
ex : compteurs atomiques distribués, structures type hashsets…

…pour finir…

SERVING
LAYER
QUERIES
Fusion des données batch et real-time
La logique de fusion est un développement custom qui dépend des
vues et de leur modélisation
Pas un sujet facile :
expiration des vues
recouvrement possible entre données batch et temps-réel
…
real-time
views
batch
views

SERVING
LAYER
DATA FLOW QUERIES
SPEED LAYER
BATCH LAYER
real-time
processing
REAL TIME
STREAM PROCESSING
BATCH
PROCESSING
PRECOMPUTED
VIEWS
λ-ARCHITECTURE

Mathieu DESPRIEE
@mdeocto

Backup

BATCH LAYER SPEED LAYER
Persistance Données maîtres Données volatiles
Type de calcul Full-scan Incrémental
Latence des traitements Heures / Jour Secondes
Cohérence vs. Fraicheur Données cohérentes à
terme
Données fraiches mais calculs
moins précis
Contrainte hardware CPU-bound
Disk-bound
Memory-bound
Exemple de tradeoff possible
dans la conception
Preprocessing ++
Batch views + rapides
Durée processing ++
Taille des vues temps-réèl ++
Imprécision ++

Eventual accuracy (précision à terme)
Certains calculs sont difficiles à réaliser en incrémental
ex. Visiteurs uniques d’un site web
un comptage exact nécessite de conserver toutes les visites en
mémoire
Une alternative : HyperLogLog est un algorithme qui permet de
faire une approximation d’un unique count, avec un espace
mémoire très limité
ex2. Le visiteur navigue sur mon site en anonyme, puis se loggue. On
ne peut savoir que le visiteur est unique qu’après cette opération de
login…
Seules les vues batch peuvent calculer cette information
précisément

[USI] Lambda-Architecture : comment réconcilier BigData et temps-réel

Contenu connexe

Tendances

En vedette

Similaire à [USI] Lambda-Architecture : comment réconcilier BigData et temps-réel

[USI] Lambda-Architecture : comment réconcilier BigData et temps-réel