Introduction au traitement temps-réel avec Storm

1. Benjamin Houdu@benjaminhoudu
Architecte, Zenika
Florian Hussonnois@fhussonnois
Lead Développeur Java, Zenika

2. Stockage
HDFS
•Système BigDataet Temps-réel
•Qu’est ce que Storm ?
•Les principaux concepts
•Parallélisme et fiabilité de traitement
•Architecture physique et tolérance à la panne
1
2
3
3
4

5. Stockage
HDFS
Flickr. By jonel hanopol
Flickr. By fdecomite
Flickr. By NOAA'sNational OceanService

7. Données absorbées par le batch
Non absorbées
Quelques heures
de données

8. Vision erronée de la réalité
Données absorbées par le batch
Non absorbées
Quelques heures
de données

9. Capteurs / logs
Cliques web
Transactions
financières
1

10. Capteurs / logs
Cliques web
Transactions
financières
Data Lake
2
1

11. Batch
View
(Map-Reduce)
Capteurs / logs
Cliques web
Transactions
financières
Data Lake
2
3
1

12. Batch
View
(Map-Reduce)
Capteurs / logs
Cliques web
Transactions
financières
Data Lake
Real Time
View
Traitements
Analyses
4
2
3
1

13. Batch
View
(Map-Reduce)
Capteurs / logs
Cliques web
Transactions
financières
Data Lake
2
3
Real Time
View
Traitements
Analyses
4
5
1

14. Batch
View
(Map-Reduce)
Capteurs / logs
Cliques web
Transactions
financières
Data Lake
2
3
Real Time
View
Traitements
Analyses
4
5
1

15. Batch
View
(Map-Reduce)
Capteurs / logs
Cliques web
Transactions
financières
Data Lake
2
3
Real Time
View
Traitements
Analyses
4
5
1

17. Stockage
HDFS
Créé par Nathan Marz@BackType
Analyse en temps réel d'impact sur les réseaux sociaux
Open-source(Twitter) Septembre 2011
Licence Eclipse Public 1.0
V 0.5.2
Evolution rapide
Incubateur Apache Septembre 2013
0.9.110 Février 2014
0.9.225 Juin 2014
0.9.3 -RC20 Octobre 2014
«Apache Top-Level» projet depuis Septembre 2014

18. Stockage
HDFS
Logs serveurs, clicks, capteurs
Mise à jour continue de bases de données
Paralléliser d’intenses calculs

19. Traitement au fil de l'eau et en continu de gros volumes de données issues de flux

20. Traitement au fil de l'eau et en continu de gros volumes de données issues de flux

21. Plusieurs milliers de workers/ clusters
Parallélisme

22. Plusieurs milliers de workers/ clusters
Parallélisme
Réassignementautomatique des tâches en échecs

23. Plusieurs milliers de workers/ clusters
Parallélisme
Réassignementautomatique des tâches en échecs
Fiabilité de traitement de chaque message
Sémantique : au moins une fois & exactement une fois

24. Plusieurs milliers de workers/ clusters
Parallélisme
Réassignementautomatique des tâches en échecs
Fiabilité de traitement de chaque message
Sémantique : au moins une fois & exactement une fois
Possibilité d’implémenter la logique de traitement avec n'importe quels langages

26. Stockage
HDFS
Principale structure de données
Liste de valeurs nommées –typage dynamique
Immuable 

27. Stockage
HDFS
Flux de données
Séquence illimité de tuples
Un flux de données est créé et traité en temps réel de manière distribué.
Tuple
Tuple
Tuple
Tuple

28. Stockage
HDFS
Source de flux de données.
Se connecte à une source de données externe puis émet des Tuples.
Output streams

29. Stockage
HDFS
Source de flux de données.
Se connecte à une source de données externe puis émet des Tuples.
Output streams
Kafka
RabbitMQ
Kestrel
Redis -PublishSubscribe

30. Stockage
HDFS
Principaux composants pour manipuler les flux de données.
Encapsulent la logique des traitements à appliquer sur un où plusieurs flux.
Input stream
Flickr. By kaveman743

31. Stockage
HDFS
Input stream
Souscrit à n’importe quels flux devant être:
Transformés
Filtrés
Agrégés
Peut lire / écrire depuis et vers une base de données

32. Stockage
HDFS
Un boltpeut émettre de nouveaux flux.
Input stream
Output streams

33. Stockage
HDFS
Un boltpeut émettre de nouveaux flux.
Input stream
Output streams
Kafka
HDFS / HBase
Cassandra
MongoDB
Elasticsearch

35. Stockage
HDFS
Graphe orienté acyclique (DAG)
Modélisation d’un Workflow
Les Bolts/Spouts’exécutent en parallèle en tant que tâches.
Une topologie s’exécute indéfiniment.

37. Les tuplessont distribués aléatoirement et de manière équitable entre les tâches.

38. Field=A
Field=B
Le flux est partitionné en fonction d’un ou plusieurs champs.

39. Le flux est répliqué vers l’ensemble des tâches

40. La totalité du flux est redirigé vers une unique tâche.

42. Parallélisme = 1
Parallélisme = 4
Parallélisme = 2
Chaque (instance) est exécuté par un exécuteur.
Chaque(thread) s’exécute au sein d’un (JVM).

43. Parallélisme = 1
Parallélisme = 4
Parallélisme = 2
Storm répartit de manière égale le nombre d’executorà travers les workers.

44. Parallélisme = 1
Parallélisme = 4
Parallélisme = 2, Tâches = 6
Chaque exécute séquentiellement 3 tâches

46. Storm garantit que chaque «tuplespout» émis sera traité dans son intégralité par la topologie.
Un tuplepeut être ancré avec un ou plusieurs tuplesparents.
Un tuplepeut ne pas être rattaché à un arbre.

47. Les boltsinforment le système de la réussite du traitement d’un tuple

48. Les boltsinforment le système de l’échec du traitement d’un tuple

49. Un tupleest automatiquement considéré en échec après un certain lapse de temps.
Timeout à 30 secondes par défaut

51. Un de par tuple

52. Un de par tuple

53. Storm utilise des boltssystèmes (ackers) pour suivre l’état de complétion d’un tuplespout.
Etat de l’arbre
de tuples

54. Le tupleB est ancré au tupleA lorsqu’il est émis.
Etat de l’arbre
de tuples

55. Le bolttransmet l’état de l’arbre à la tâche acker.
Etat de l’arbre
de tuples
{A} XOR {A} XOR {B} != 0

56. Etat de l’arbre
de tuples
{A} XOR {A} XOR {B} != 0
{A} XOR {A} XOR {B} XOR {B} = 0

57. La tâche ackernotifie la tâche spoutdu succès du traitement du tupleA.
Etat de l’arbre
de tuples
{A} XOR {A} XOR {B} != 0
{A} XOR {A} XOR {B} XOR {B} = 0

59. Zookeeper
Quorum
Workers
Workers
(Master node)
(Slave node)
Architecture master/slave
NSPOF
(Slave node)

60. Zookeeper
Quorum
Workers
Workers
(Master node)
(Slave node)
(Slave node)
Un service centralisé pour maintenir des informations de configuration, fournir une synchronisation distribuée, etc.
Coordonne le cluster Storm
Permet à nimbus de découvrir les Supervisors

61. Zookeeper
Quorum
Workers
Workers
(Master node)
(Slave node)
(Slave node)
Distribue le code à travers le cluster
Assigne les tâches
Traite les erreurs et réassigne les tâches en conséquence

62. Zookeeper
Quorum
(Master node)
(Slave node)
(Slave node)
$ /bin/stormjar
Nimbus calcule les assignements des tâches et les envoie à Zookeeper.
Les supervisorssont notifiés via Zookeeper.
Chaque supervisorrécupère le code depuis nimbus (Thrift)
1
2
3
1
2
3

63. Zookeeper
Quorum
Workers
Workers
(Master node)
(Slave node)
(Slave node)
Les supervisorsdémarrent le nombre de workersnécessaires à l’exécution de la topologie
4
4

65. Zookeeper
Quorum
Workers
Workers
(Master node)
(Slave node)
(Slave node)
Worker
Le supervisorredémarre le worker.
Nimbus peut réassigner les tâches.
Supervisor
Nimbus réassigne les tâches.
Nimbus
Les topologies continuent de fonctionner.
Les ré-assignements sont impossibles.
Heartbeat

67. Stockage
HDFS
Framework au dessus de Storm
Orienté micro-batch
Sémantique «exactement une fois» (DistributedRemoteProcedureCall)
Paralléliser des calculs intenses
Topologie coordonnée via une serveur DRPC

68. Documentation officielle: http://storm.apache.org
Mailing liste
Storm Blueprints: Patterns for DistributedReal- time Computation
P. Taylor Goetz, Brian O’Neil
Big Data -Principles and best practices of scalable realtimedata systems,
Nathan Marzand James Warren

69. http://www.meetup.com/Paris-Storm-User-Group/