Actuellement, on parle beaucoup de traitement en lots (batch) dans le monde du Big Data. Mais qu’en est-il du Streaming et du temps réel ? Beaucoup de frameworks Big Data tentent de répondre à cette problématique. En tête de liste figure Spark : grâce à son composant Spark Streaming, il permet un traitement en continu des flux de données et une disponibilité 24/7. Au programme : - Streaming et Architecture Big Data - Hello world Spark Streaming - Intégration de Flume à Spark Streaming - Use case “métriques sur des logs applicatifs” - Architecture physique : driver / workers / receivers - Monitoring de Spark Streaming - Fail over : reliable / unreliable sources, checkpoint, recover - Tuning et performance. Speakers : - Nadhem LAMTI, Architecte Technique chez PALO IT Depuis 10 ans, Nadhem intervient principalement sur des projets JAVA JEE de grande envergure dans différents secteurs (Télécommunication, Banque, Finance, Transports, Tourisme, etc.), développant ainsi une expertise polyvalente en abordant multiples technologies et architectures. Fort d’une expérience concluante en tant qu’Ingénieur Performance & Support, Nadhem est capable d’intervenir sur des problématiques de production liées à des systèmes d’informations complexes. Actuellement en mission chez Voyages SNCF, il contribue à un grand chantier Big Data de centralisation de logs et s’intéresse tout particulièrement au nouveau produit phare de traitement de données Apache Spark. - Saâd-Eddine MALTI, Expert BDD chez Voyages SNCF En poste depuis 10 ans chez Voyages SNCF, Saâd-Eddine intervient en tant qu’Expert BDD sur toutes les applications de manière transverse. L’orientation affichée de Voyages SNCF vers le Big Data pousse Saâd-Eddine à s’investir pleinement dans ce domaine, également sur le nouveau produit phare de traitement de données Apache Spark.

1. Présentation Société
Mars 2013 @ Paris
Stanislas BOCQUET
CEO
+33(0)1 43 12 89 42
sbocquet@palo-it.com
SPARK STREAMING, LES DONNÉES QUI
VOUS PARLENT EN TEMPS RÉEL
30 SEPTEMBRE 2015 @Paris
Nadhem LAMTI
Architecte Technique chez PALO IT
Saâd-Eddine MALTI
Expert BDD chez Voyages SNCF
&

2. 2
Au programme
Streaming et Architecture Big Data
Introduction to Spark Streaming : Word Count
Intégration de Flume à Spark Streaming
Use case « logs applicatifs »
Architecture générale : driver / workers / receivers
Monitoring
Fail over : reliable / unreliable sources, checkpoint, recover
Tuning et performance

3. Streaming et architecture
BigData

4. 4
RAPPELS
Juin 2015
HDFS : système de fichiers distribués
MAPREDUCE : traitement distribué
PIG HIVE
SCRIPTING
SEQUENTIEL
SQL
LIKE
JAVA
Plumbing
• In Memory
• RDD
• Scala/Java/Python

5. 5
ARCHITECTURE BIG DATA
Plus familièrement : architecture LAMBDA
STOCKENT : en vue d’un REPORTING mensuel
par ex
Et TRAITENT en temps réel la donnée : en vue
d’un MONITORING par ex
Savent gérer la donnée à la fois comme :
UN STOCK
UN FLUX
Cas d’utilisation :
Systèmes de recommandations
Statistiques en temps réel : ex taux d’erreur
Pub en ligne : nombre de clics/transformations
par campagne

6. 6
ARCHITECTURE BIG DATA
Batch LAYER
Stocker l’ensemble de données
Itération pouvant prendre plusieurs heures
Speed LAYER : « temps réel »
Traite que les données récentes et compense
la latence élevée de la couche Batch
Calculées de manière incrémentale en
s’appuyant sur des systèmes de traitement de
flux et des bases de données en
lectures/écritures aléatoires.
Serving LAYER:
Charger et Exposer les vues des couches
batch et temps réel

7. 7
SPARK STREAMING

8. 88
SPARK STREAMING
Etend l’API de Spark Core
Scalable, haut débit, tolérance au panne
Traitement au fil de l’eau des données
temps réelles

9. 99
SPARK STREAMING
Plusieurs sources possibles
Processing utilisant des algorithmes
complexes mais des APIs simples :
map, reduce, join, window, …
Les données traitées peuvent être
poussées vers des systèmes de
stockage, Dashboards, …
Haut niveau d’abstraction : Discritized
Stream (DStream)  Séquence de
RDDs

10. 1010
WORD COUNT

11. 1111
WORD COUNT

12. 12
Intégration avec Flume

13. 1313
DATASOURCE FLUME
Système distribué, fiable, à haute disponibilité
Solution de collecte et d’agrégation de gros
volumes données depuis plusieurs sources
Pusher vers un entrepôt de données centralisé
(HDFS, ELS …)
Agents
Source, Channel, Sink

14. 1414
DATASOURCE FLUME
Configuration Type

15. 1515
DATASOURCE FLUME
Spark Streaming + Flume Integration Guide
Approche 1 : Push-based approach :
Spark Streaming, essentiellement, initialise un “receiver” agissant comme un
agent Avro pour Flume, dans lequel ce dernier peut pousser ses données
Configuration de Flume :
 Linking : Package spark-streaming-flume_2.10
Programming :

16. 1616
DATASOURCE FLUME
Spark Streaming + Flume Integration Guide
Approche 2 : Pull-based approach :
Flume pousse les données dans le sink, et ces dernières restent en mémoire
tampon.
Spark Streaming utilize un reliable Flume receiver de manière transactionnelle
pour récupérer les données du sink. Une transaction est considérée OK
seulement après acquittement et replication de la donnée par Spark Streaming
Configuration Flume :
 Sink Jars : spark-streaming-flume-sink_2.10, scala-library
 Config file
 Linking : Package spark-streaming-flume_2.10
Programming :

17. 17
DEMO : USE CASE LOG
APPLICATIF

18. 1818
DEMO : USE CASE LOG APPLICATIF
Operations :
Transformations : lazy
Stateless : map, reduce, filter, join, combineByKey
Stateful : utilise les données et les résultat du batch précédent. Nécessite un checkpoint.
» window / silde :
exemple : reduceByKeyAndWindow
» Statut à travers le temps : updateByState
Actions : output des operations. Sert pour évaluer le contenu d’un Dstream et démarrer un contexte
exemple : myDStream.saveAsTextFiles(“mydir”,”.txt”)
foreachRDD() : generic output operation

19. 1919
DEMO : USE CASE LOG APPLICATIF
Déploiement
Inclure les dépendances Spark et celles des sources
Générer un package avec Maven Assembly
Exécution
./bin/spark-submit -- class …
-- master …
-- jars [jar_1,jar_2,…,jar_n]
-- conf p1=v1
….
<app-jar>
[app-arguments]
Configuration
SparkConf.set(“p1”,”v1”)
Dynamique :
-- conf p1=v1
-- conf p2=v2
Config Chargée depuis conf/spark-defaults.conf :
Les propriétés peuvent être consultées depuis la webUI(http://<driver>:4040) # TAB “Environment”

20. ARCHITECTURE

21. 21
ARCHITECTURE
Cluster Manager : Standalone,
MESOS, YARN et local(
dev/test/debug)
WorkerNode : Receives +
Processes
Driver : programme principale
contenant « sparkContext »

22. 22
MONITORING
webUI : http://<driver>:4040
Streaming tab
Running Receivers :
Active
Number of records received
Receiver error
Batches :
Processing Time
Times
Queing delays
Environment tab
…

23. TOLERANCE AUX PANNES

24. 24
TOLERANCE AUX PANNES
3 étapes pour traiter les données
Recevoir les données
Traiter/transformer les données
Pusher les données vers l’éxterieur

25. 25
TOLERANCE AUX PANNES
Réception des données :
Reliable : acquittement après avoir s’assurer que la donnée reçue est
répliquée : cas de « PollingFlume »
Unreliable : à partir de « Spark 1.2 », « WriteAheadLog »
(spark.streaming.receiver.writeAheadLog.enabled -> true)
Attention aux performances : utiliser plus qu’un Receiver en // et désactiver la
réplication

26. 26
TOLERANCE AUX PANNES
Traiter/Transformer les données :
CHECKPOINT : Sauvegarder le statut périodiquement dans un système de
fichier fiable :
Data : RDD intermédiaires sur les opération de transformation Statefull
Metadata : Recover from Driver :
 Utiliser “getOrCreate” : recréer sparkStreamingContext depuis checkpoint
Data dans le répertoire checkpoint
 -- supervise : redémarrage en cas d’échec du Driver (seulement on
standalone mode)
 -- deploy-mode cluster : lancer sur un cluster distant

27. 27
TOLERANCE AUX PANNES
Push des données vers l’éxterieur:
Mise à jour transactionnelle
Doit avoir un identifiant de transaction
Du moment ou ça concerne un système externe, c’est de la
responsabilité du système d’assurer la cohérence des données

28. 28
TOLERANCE AUX PANNES
Mode Normal

29. 29
TOLERANCE AUX PANNES
Mode « Recover »

30. Tunning et performance

31. 31
Tunning et performance
Important : Le temps totale d’exécution d’un batch (scheduling delay + processing time) < batchInterval
Suivi via Spark UI Monitoring
Data Receiving :
Setter le bon « BatchInterval » : tester la limite en jouant sur le débit
Augmenter le nombre de Receivers :
 Attention : un « Receiver » = un « Worker » ou un « Core »
 Merge des Dstream de chaque receiver
Alternative au multiple Dstream : « inputStream.repartition () » distribue les données reçues sur des machines du
« Cluster » avant « processing »
« spark.streaming.backpressure.enabled » : gestion dynamique de la conf « spark.streaming.receiver.maxRate »

32. 32
Tunning et performance
Data Processing :
Niveau du parallélisme
 Spark.core.max - nbr consommateurs
 Ajouter la conf « spark.default.parallelism » selon le type du cluster Manager
Réduire le nombre de partitions pour réduire le temps de Processing :
 Chaque block de données généré par le « Receiver » produit une partition
 « spark.streaming.blockInterval » : les données reçu se transforment en un block de données
 Partitions = « consumers » * « bactchInterval » / « blockInterval »
 « spark.streaming.blockInterval » nbr Partitions mais « batchInterval » mod « blockInterval » = 0
 Recommandé par Spark : nb Partition = 2x-3x nombre de « Cores » disponibles
 « spark.streaming.blockInterval » = « consumers » * « bactchInterval » / 2 ou 3 * « nb Cores »
Eviter les log de parcours des « Dstream » logs mode verbeux et silencieux
Kryo pour une sérialisation plus efficace : « spark.serializer org.apache.spark.serializer.KryoSerializer »

33. 33
Tunning et performance
Setting the right batch interval : >=500 ms
Traite la donnée dès sa réception
Memory tuning and GC behavior :
Taille de la Window
 Mémoire requise de la taille de donnée dans chaque “executor” Set spark.default.parallelism
Large pause causée par JVM GC non désirable :
 Utiliser plus d’éxécuteurs avec une taille mémoire plus petite
CMS GC : diminuer les pauses
 In Driver : --driver-java-options
 In Executor : spark.executor.extraJavaOptions
Contrôler l’éviction des données si pas besoin
 Peut se faire explicitement pour les vieilles données au delà de “spark.cleaner.ttl” (peut réduire la
pression de l’activité GC)

34. Présentation Société
Mars 2013 @ Paris
Stanislas BOCQUET
CEO
+33(0)1 43 12 89 42
sbocquet@palo-it.com
MERCI DE VOTRE
ATTENTION !