Comment intégrer le big-data et le temps-réel au sein d'une même architecture sans qu'elle ne se transforme en un monstre de Frankeinstein, trop complexe et trop coûteuse à maintenir ?
La « Lambda architecture » nous propose une approche simple et élégante : stocker et traiter de larges volumes de données, en intégrant dans la seconde les données les plus récentes, le tout en préservant scalabilité et tolérance aux pannes.
[conférence présentée à l'USI 2014 : https://www.youtube.com/watch?v=tw3X7eMOVEM]
4. www.usievents.com #USI2014
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
5. www.usievents.com #USI2014
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
6. www.usievents.com #USI2014
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 »)
7. www.usievents.com #USI2014
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
9. www.usievents.com #USI2014
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
11. www.usievents.com #USI2014
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
18. www.usievents.com #USI2014
Batch Layer : quelle techno ?
Besoins :
Stockage scalable
Tolérant aux pannes
Robuste
notamment aux évolutions de schéma
Permettant tout type de processing
21. www.usievents.com #USI2014
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
24. www.usievents.com #USI2014
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 »
25. www.usievents.com #USI2014
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
27. www.usievents.com #USI2014
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
28. www.usievents.com #USI2014
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
29. www.usievents.com #USI2014
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…
31. www.usievents.com #USI2014
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
35. www.usievents.com #USI2014
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 ++
36. www.usievents.com #USI2014
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