Spark Streaming

452 vues

Publié le

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.

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

Aucun téléchargement
Vues
Nombre de vues
452
Sur SlideShare
0
Issues des intégrations
0
Intégrations
5
Actions
Partages
0
Téléchargements
16
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Spark Streaming

  1. 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. 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. 3. Streaming et architecture BigData
  4. 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. 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. 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. 7 SPARK STREAMING
  8. 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. 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. 10. 1010 WORD COUNT
  11. 11. 1111 WORD COUNT
  12. 12. 12 Intégration avec Flume
  13. 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. 14. 1414 DATASOURCE FLUME Configuration Type
  15. 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. 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. 17 DEMO : USE CASE LOG APPLICATIF
  18. 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. 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. 20. ARCHITECTURE
  21. 21. 21 ARCHITECTURE Cluster Manager : Standalone, MESOS, YARN et local( dev/test/debug) WorkerNode : Receives + Processes Driver : programme principale contenant « sparkContext »
  22. 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. 23. TOLERANCE AUX PANNES
  24. 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. 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. 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. 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. 28 TOLERANCE AUX PANNES Mode Normal
  29. 29. 29 TOLERANCE AUX PANNES Mode « Recover »
  30. 30. Tunning et performance
  31. 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. 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. 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. 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 !

×