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

2,613 views
2,391 views

Published on

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]

Published in: Technology
0 Comments
13 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,613
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
124
Comments
0
Likes
13
Embeds 0
No embeds

No notes for slide

[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

×