www.usievents.com #USI2014
Lambda-architecture
ou comment réconcilier les Big-Data avec le temps réel
Mathieu DESPRIEE
@md...
www.usievents.com #USI2014
λ-ARCHITECTURE
Quels use-cases ?
Qu’est-ce que la lambda-architecture ?
Quels sont ses principe...
www.usievents.com #USI2014
Origines
manning.com/marz
Nathan Marz
Ex-Backtype & Twitter
Initiateur des frameworks
Storm
Cas...
www.usievents.com #USI2014
BigData + Temps Réel :
Pour quels use-cases ?
Recommandation en temps-réel
Prise en compte de l...
www.usievents.com #USI2014
Prend en charge toutes les données
qu’elles soient historique ou datent de la
dernière seconde
...
www.usievents.com #USI2014
De quelles données parle-t-on ?
un tweet
un utilisateur qui se loggue
un utilisateur qui donne ...
www.usievents.com #USI2014
La bonne vieille base de données
Ex d’une action utilisateur (changement d’adresse) :
Le problè...
www.usievents.com #USI2014
Stockage immuable
Pas d’UPDATE, seulement des INSERT
Toute autre information peut être dérivée/...
www.usievents.com #USI2014
Immuabilité : quels gains ?
Performance du stockage
APPEND-only est très performant, ex. Hadoop...
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ées
qu’elles soient historique ou datent de la
dernière seconde
...
www.usievents.com #USI2014
query = function ( ALL data )
www.usievents.com #USI2014
ALL
DATA
precomputed
view
query
( ie. on sépare les problèmes : stockage, calcul, lecture )
Pri...
www.usievents.com #USI2014
hashtag hour_range count
#usi2014 09:00 12
#usi2014 10:00 138
#usi2014 11:00 12543
#lambda 11:0...
www.usievents.com #USI2014
SERVING
LAYER
SPEED LAYER
BATCH LAYER
DATA FLOW QUERIES
λ-ARCHITECTURE
REAL TIME
STREAM PROCESS...
www.usievents.com #USI2014
BATCH LAYER
www.usievents.com #USI2014
DATA FLOW QUERIES
BATCH LAYER
BATCH
PROCESSING
« BATCH VIEWS »
Batch Layer
Stockage maître + tr...
www.usievents.com #USI2014
Batch Layer : quelle techno ?
Besoins :
Stockage scalable
Tolérant aux pannes
Robuste
notamment...
www.usievents.com #USI2014
SERVING LAYER
www.usievents.com #USI2014
real-time
processing
SPEED LAYER
REAL TIME
STREAM PROCESSING
DATA FLOW QUERIES
BATCH LAYER
SERV...
www.usievents.com #USI2014
Stockage des vues : quelle techno ?
Besoins :
Ecritures massives
Lectures indexées (accès aléat...
www.usievents.com #USI2014
maintenant
TEMPS
Données prises en compte
dans les batch views
Pas encore
absorbées
QUELQUES HE...
www.usievents.com #USI2014
SPEED LAYER
www.usievents.com #USI2014
SPEED LAYER
REAL TIME
STREAM PROCESSING
DATA FLOW QUERIES
Speed Layer
Le rôle du speed layer es...
www.usievents.com #USI2014
Speed layer : caractéristiques recherchées
Traitement en continu (stream processing)
Architectu...
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é orien...
www.usievents.com #USI2014
SPEED LAYER
REAL TIME
STREAM PROCESSING
DATA FLOW QUERIES
Real-time views
Les vues produites do...
www.usievents.com #USI2014
Real-time views : quelle techno ?
Besoins :
Doit supporter de fortes sollicitations en lecture
...
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évelop...
www.usievents.com #USI2014
SERVING
LAYER
DATA FLOW QUERIES
SPEED LAYER
BATCH LAYER
real-time
processing
REAL TIME
STREAM P...
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 ...
www.usievents.com #USI2014
Eventual accuracy (précision à terme)
Certains calculs sont difficiles à réaliser en incrémenta...
Prochain SlideShare
Chargement dans…5
×

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

3 183 vues

Publié le

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]

Publié dans : Technologie
0 commentaire
14 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
3 183
Sur SlideShare
0
Issues des intégrations
0
Intégrations
153
Actions
Partages
0
Téléchargements
157
Commentaires
0
J’aime
14
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

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

  1. 1. www.usievents.com #USI2014 Lambda-architecture ou comment réconcilier les Big-Data avec le temps réel Mathieu DESPRIEE @mdeocto
  2. 2. 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 ?
  3. 3. www.usievents.com #USI2014 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
  4. 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. 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. 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. 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
  8. 8. 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
  9. 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
  10. 10. www.usievents.com #USI2014 Principe #1 Une architecture basée sur des données immuables
  11. 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
  12. 12. www.usievents.com #USI2014 query = function ( ALL data )
  13. 13. www.usievents.com #USI2014 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
  14. 14. 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…)
  15. 15. www.usievents.com #USI2014 SERVING LAYER SPEED LAYER BATCH LAYER DATA FLOW QUERIES λ-ARCHITECTURE REAL TIME STREAM PROCESSING BATCH PROCESSING PRECOMPUTED VIEWS
  16. 16. www.usievents.com #USI2014 BATCH LAYER
  17. 17. www.usievents.com #USI2014 DATA FLOW QUERIES BATCH LAYER BATCH PROCESSING « BATCH VIEWS » Batch Layer Stockage maître + traitements batch MASTER DATA
  18. 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
  19. 19. www.usievents.com #USI2014 SERVING LAYER
  20. 20. www.usievents.com #USI2014 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
  21. 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
  22. 22. www.usievents.com #USI2014 maintenant TEMPS Données prises en compte dans les batch views Pas encore absorbées QUELQUES HEURES DE DONNÉES
  23. 23. www.usievents.com #USI2014 SPEED LAYER
  24. 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. 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
  26. 26. www.usievents.com #USI2014 Speed layer : technologies Pour des petites topologies : Queues + Workers Storm Spark
  27. 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. 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. 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…
  30. 30. www.usievents.com #USI2014 …pour finir…
  31. 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
  32. 32. www.usievents.com #USI2014 SERVING LAYER DATA FLOW QUERIES SPEED LAYER BATCH LAYER real-time processing REAL TIME STREAM PROCESSING BATCH PROCESSING PRECOMPUTED VIEWS λ-ARCHITECTURE
  33. 33. www.usievents.com #USI2014 Mathieu DESPRIEE @mdeocto
  34. 34. www.usievents.com #USI2014 Backup
  35. 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. 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

×