View
1.243
Download
0
Category
Preview:
DESCRIPTION
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]
Citation preview
www.usievents.com #USI2014
Lambda-architecture
ou comment réconcilier les Big-Data avec le temps réel
Mathieu DESPRIEE
@mdeocto
www.usievents.com #USI2014
λ-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 ?
www.usievents.com #USI2014
Origines
manning.com/marz
Nathan MarzEx-Backtype & Twitter
Initiateur des frameworksStorm
Cascalog
ElephantDB
BacktypeCapture d’événements et de logs Twitter pour analyse
25 TB binary data
100 Billions of records
400 QPS Average
www.usievents.com #USI2014
BigData + Temps Réel :Pour quels use-cases ?
Recommandation en temps-réelPrise 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éelDes historiques très volumineux qui recèlent de la valeur
www.usievents.com #USI2014
Prend en charge toutes les donnéesqu’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 stockagex 1’000 evt / secondx 100 query / second
Basse latence en écriture ET en lecture
Le système BigData à construire
dataflow
big data system
queries
application
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énementdes faits
datés
immuables (« éternellement vrais »)
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
www.usievents.com #USI2014
Stockage immuable
Pas d’UPDATE, seulement des INSERT
Toute autre information peut être dérivée/reconstruite à partir de ces données brutes
www.usievents.com #USI2014
Immuabilité : quels gains ?
Performance du stockageAPPEND-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 humainesUn 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
www.usievents.com #USI2014
Principe #1
Une architecture basée sur des données immuables
www.usievents.com #USI2014
Prend en charge toutes les donnéesqu’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 stockagex 1’000 evt / secondx 100 query / second
Basse latence en écriture ET en lecture
Le système BigData à construire
dataflow
big data system
queries
application
www.usievents.com #USI2014
query = function ( ALL data )
www.usievents.com #USI2014
ALL DATA
precomputedview
query
( ie. on sépare les problèmes : stockage, calcul, lecture )
Principe #2
Une architecture basée sur des vues précalculées
www.usievents.com #USI2014
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…)
www.usievents.com #USI2014
SERVING LAYER
SPEED LAYER
BATCH LAYER
DATA FLOW QUERIES
λ-ARCHITECTURE
REAL TIMESTREAM
PROCESSING
BATCHPROCESSING
PRECOMPUTED
VIEWS
www.usievents.com #USI2014
BATCH LAYER
www.usievents.com #USI2014
DATA FLOW QUERIES
BATCH LAYER
BATCHPROCESSING
« BATCH VIEWS »
Batch Layer
Stockage maître + traitements batch
MASTER DATA
www.usievents.com #USI2014
Batch Layer : quelle techno ?
Besoins :Stockage scalableTolérant aux pannesRobuste
notamment aux évolutions de schéma
Permettant tout type de processing
www.usievents.com #USI2014
SERVING LAYER
www.usievents.com #USI2014
real-timeprocessing
SPEED LAYER
REAL TIMESTREAM
PROCESSING
DATA FLOW QUERIES
BATCH LAYER
SERVING LAYER
Vues précalculées
2
1batch processingfull dataset
BATCH VIEWDATABASE
publish
www.usievents.com #USI2014
Stockage des vues : quelle techno ?
Besoins :Ecritures massivesLectures indexées (accès aléatoire) à faible temps de réponseScalable et tolérant à la panne
www.usievents.com #USI2014
maintenant
TEMPS
Données prises en comptedans les batch views
Pas encore absorbées
QUELQUES HEURESDE DONNÉES
www.usievents.com #USI2014
SPEED LAYER
www.usievents.com #USI2014
SPEED LAYER
REAL TIMESTREAM
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 »
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 traitementcapacité à rejouer automatiquement des messages en cas de perte d’un nœud
www.usievents.com #USI2014
Speed layer : technologies
Pour des petites topologies : Queues + Workers
Storm
Spark
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
www.usievents.com #USI2014
SPEED LAYER
REAL TIMESTREAM
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
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 panneDes fonctions avancées peuvent être utiles à ce niveau
ex : compteurs atomiques distribués, structures type hashsets…
www.usievents.com #USI2014
…pour finir…
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-timeviews
batchviews
www.usievents.com #USI2014
SERVING LAYERDATA FLOW QUERIES
SPEED LAYER
BATCH LAYER
real-timeprocessing
REAL TIMESTREAM
PROCESSING
BATCHPROCESSING
PRECOMPUTED
VIEWS
λ-ARCHITECTURE
www.usievents.com #USI2014
Mathieu DESPRIEE
@mdeocto
www.usievents.com #USI2014
Backup
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-boundDisk-bound
Memory-bound
Exemple de tradeoff possible dans la conception
Preprocessing ++Batch views + rapidesDurée processing ++
Taille des vues temps-réèl ++Imprécision ++
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
Recommended