Successfully reported this slideshow.
Your SlideShare is downloading. ×

Alan Poe appliqué au data streaming - toutes choses sont bonnes ou mauvaises par comparaison

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Upcoming SlideShare
Propostion un Iaas
Propostion un Iaas
Loading in …3
×

Check these out next

1 of 47 Ad

Alan Poe appliqué au data streaming - toutes choses sont bonnes ou mauvaises par comparaison

J'ai eu l'occasion de mettre en œuvre :
- 4 solutions techniques différentes de data streaming (Apache Nifi, Apache Flink, Apache Spark Streaming et Apache Kafka Streams)
- 3 solutions de stockage de forte volumétrie (Apache Cassandra, TimescaleDB et Oracle DB)
- sur 3 projets différents de télécollecte IoT et de traitements de données Big Data.

Cela représente 8 ans de recul sur le traitement de données de forte volumétrie. Cette expérience s'est construite "grâce" à des dizaines de problèmes de performances, de cohérence des données, d'engorgement de nos systèmes distribués... J'ai donc de belles histoires techniques à vous raconter sur le pire et le meilleur de ces différentes solutions. Vous voulez savoir quelle est la meilleure et celle que je vous recommande ? Je suis sûr que vous connaissez la réponse courte "ça dépend". Pour la réponse longue, consultez nous...

J'ai eu l'occasion de mettre en œuvre :
- 4 solutions techniques différentes de data streaming (Apache Nifi, Apache Flink, Apache Spark Streaming et Apache Kafka Streams)
- 3 solutions de stockage de forte volumétrie (Apache Cassandra, TimescaleDB et Oracle DB)
- sur 3 projets différents de télécollecte IoT et de traitements de données Big Data.

Cela représente 8 ans de recul sur le traitement de données de forte volumétrie. Cette expérience s'est construite "grâce" à des dizaines de problèmes de performances, de cohérence des données, d'engorgement de nos systèmes distribués... J'ai donc de belles histoires techniques à vous raconter sur le pire et le meilleur de ces différentes solutions. Vous voulez savoir quelle est la meilleure et celle que je vous recommande ? Je suis sûr que vous connaissez la réponse courte "ça dépend". Pour la réponse longue, consultez nous...

Advertisement
Advertisement

More Related Content

Similar to Alan Poe appliqué au data streaming - toutes choses sont bonnes ou mauvaises par comparaison (20)

Recently uploaded (20)

Advertisement

Alan Poe appliqué au data streaming - toutes choses sont bonnes ou mauvaises par comparaison

  1. 1. Alan Poe appliqué au data streaming SnowCamp 2023 Toutes choses sont bonnes ou mauvaises par comparaison Slides et code
  2. 2. © 2022 CGI inc. Interne 2023
  3. 3. © 2022 CGI inc. Interne Edgar Allan Poe 1809 - 1849 © Nong V / Unsplash
  4. 4. © 2022 CGI inc. Interne 4 Jean-Michel DURAND Tech lead Expertise sur le data engineering (Kafka, Spark Streaming, Oracle, PostgreSQL), la modélisation de données et les technologies de développement back-end Java Julien COGNET Architecte SI Directeur technique CGI Grenoble, expert data streaming, modélisation de données et processus métier, professeur et conférencier
  5. 5. © 2022 CGI inc. Interne © 20XX CGI inc. Interne Besoin Prologue © Braden COLLUM / Unsplash
  6. 6. © 2022 CGI inc. Interne Décompte ferroviaire 6 Collecte fiabilisation et diffusion des données de consommation d’énergie ferroviaire mesurées par des compteurs embarqués dans les trains Vélocité : 100 messages / sec Volumétrie : 1,5 TB (hors réplication) 10 pers. 4 ans
  7. 7. © 2022 CGI inc. Interne Décompte ferroviaire Compteurs intelligents Routeur de flux Services de traitement API publique Portail web Référentiel Entrepôt de publication Légende Flux de traitement asynchrone via Connexion aux équipements Requêtes HTTP synchrones 7 Passerelles de communication Systèmes externes
  8. 8. © 2022 CGI inc. Interne Performance énergétique de bâtiments 8 Plateforme d’acquisition et supervision centralisée à distance de plus de 90 000 installations (télégestion, télécollecte, téléalarmes). 6,2 TWh économisés en 2021 Volumétrie : 20 TB Vélocité : 10 000 valeurs / sec 15 pers. 20 ans
  9. 9. © 2022 CGI inc. Interne Performance énergétique de bâtiments 9 Compteurs intelligents Stream processors Micro-services Portail web Base de données stream Frontaux et bridges de communication Bus de données Passerelles IoT Exports Systèmes externes Systèmes externes
  10. 10. © 2022 CGI inc. Interne © 20XX CGI inc. Interne Solutions mise en œuvre Chapitre 1 © Olav Ahrens RØTNE / Unsplash
  11. 11. © 2022 CGI inc. Interne • Conception graphique et gestion de l’exécution de traitements sur des flux de données • IHM web et API REST • Environnement distribué, résilient et scalable • Logiciel libre sous licence Apache • Historique : projet interne de la NSA débuté en 2006, libéré en opensource en 2014 Présentation rapide et démonstration de 11
  12. 12. © 2022 CGI inc. Interne • Framework Java de définition de calculs sur flux de donnée • DSL fonctionnel • Environnement d’exécution distribué et scalable de data streaming • Compilation standard via Maven • Déploiement via soumission de jar et de paramètres sur le cluster Flink • IHM d’administration & API REST Présentation rapide et démonstration de 12
  13. 13. © 2022 CGI inc. Interne Présentation rapide et démonstration de 13 • Commit log distribué • Montée en charge horizontale quasi infinie • Haute disponibilité • Performance (millions de messages par seconde) • Projet Open Source depuis 2011, Confluent étant la principal entreprise soutenant le projet
  14. 14. © 2022 CGI inc. Interne Contexte / architecture des démonstrations 14 Injecteur de données Association avec données de référence Référentiel BDD timeseries Visualisation Change Data Capture Agrégation des données streams Contexte: gestion technique de bâtiments Objectif: découvrir quel bâtiment a la consommation par m² la plus élevée 1.1 1.2 2 3
  15. 15. © 2022 CGI inc. Interne © 20XX CGI inc. Interne Identification des données Chapitre 2 © Tarik HAIGA / Unsplash
  16. 16. © 2022 CGI inc. Interne Solution 1 – Appel de référentiel à la volée 16 Capteur Service de traitement Référentiel Message de données relevée Appel à la volée Interrogation à la volée du référentiel (appel BDD ou API REST dédiée) Performance et scalabilité à surveiller Cache HTTP / JDBC Simplicité Consistance des données Améliorations Inconvénients, précautions Avantages Principe
  17. 17. © 2022 CGI inc. Interne Solution 2 – Cache avec invalidation 17 Cache en mémoire des données de référence initialisé au démarrage et rafraichi périodiquement ou à la demande Consistance non garantie Hazelcast, Redis Relativement simple Performance de la solution Outils de cache Inconvénients, précautions Avantages Principe Capteur Service de traitement Référentiel Message de données relevée Référentiel en mémoire Initialisation au démarrage Invalidation périodique ou sur demande Indisponibilité pendant rafraichissement Partitionnement et distribution des données
  18. 18. © 2022 CGI inc. Interne Solution 3 – Change data capture 18 Capteur Service de traitement Référentiel Message de données relevée Interception des changements apportés au données de référence et mise à jour en temps quasi réel du référentiel en cache Consistance à terme Debezium Solution 100% évènementielle Réactivité de la solution, pas d’interruption Outils de CDC open source Inconvénients, précautions Avantages Principe Information de changement de donnée du référentiel Référentiel en mémoire Interception changements Kafka Connect Empreinte du mécanisme de CDC sur la BDD Coût et complexité
  19. 19. © 2022 CGI inc. Interne Retour d’expérience – gestion du référentiel Projet Choix S2 – Cache avec invalidation S3 – Change Data Capture Taille de référentiel 10 000 4 000 000 Fréquence de rafraichissement 1 modification par heure 1 modification par seconde Pourquoi • Focus fort sur l’intégrité des données • Référentiel de petite taille (< 10000) • Volumétrie de données en entrée raisonnable • Poids de l’historique • Changement trop important • Solution 1 et 2 expérimentée mais inadaptées 19
  20. 20. © 2022 CGI inc. Interne © 20XX CGI inc. Interne Chapitre 3 Garantie de traitement © Duncan MEYER/ Unsplash
  21. 21. © 2022 CGI inc. Interne Différents types de garantie 21 EXACTLY once At LEAST once AT MOST once
  22. 22. © 2022 CGI inc. Interne 22 Transactions au sein d’un environnement totalement maîtrisé Exactly Once processing > solution 1 Solution choisie par
  23. 23. © 2022 CGI inc. Interne 23 2 phases commit Exactly Once processing > solution 2 Solution choisie par
  24. 24. © 2022 CGI inc. Interne 24 Orchestration (Supervision et rejeu avec idempotence / sagas) Exactly Once processing > solution 3 Superviseurs applicatifs Routeur de flux Orchestrateur Archivage 3 Services de traitement 1 2
  25. 25. © 2022 CGI inc. Interne Idempotence 25 Action idempotente Action non idempotente
  26. 26. © 2022 CGI inc. Interne Retour d’expérience – garantie de traitement Projet Solution Choix Supervision et rejeu avec idempotence Environnement Kafka & DLQ en cas d’erreur Pourquoi • Nécessité fonctionnelle (facturation) • Idempotence garantie via historisation du référentiel • Orchestrateur présent pour autre besoin fonctionnel • Pas d’enjeu strict de garantie de traitement • Transactions 2PC Kafka + Oracle évitées en raison de la complexité 26
  27. 27. © 2022 CGI inc. Interne © 20XX CGI inc. Interne Données retardataires Chapitre 4 © Pierre BAMIN / Unsplash
  28. 28. © 2022 CGI inc. Interne 28 Différentes notions de date Compteur intelligent Stream processors Event Time Processing Time Ingestion Time Entrée du système de traitement
  29. 29. © 2022 CGI inc. Interne 29 Monde idéal 12h02 12h11 12h03 12h06 12h07 12h09 12h12 12h14 12h15 12h19 12h18 12h17 2 1 1 2 2 2 1 1 1 12h 12h15 12h10 12h05 12h20 12h01
  30. 30. © 2022 CGI inc. Interne 30 Données retardataires – pas de gestion de la date de l’évènement 12h02 12h11 12h06 12h07 12h09 12h12 12h14 12h15 12h19 12h18 12h17 0 (-2) 1 2 (+1) 2 3 (+1) 2 1 1 1 12h 12h15 12h10 12h05 12h20 12h01 12h03
  31. 31. © 2022 CGI inc. Interne 31 Données retardataires – solution d’attente pour traitement 12h02 12h11 12h06 12h07 12h09 12h12 12h14 12h15 12h19 12h18 12h17 1 (-1) 1 1 2 2 2 12h 12h15 12h10 12h05 12h20 12h01 12h03
  32. 32. © 2022 CGI inc. Interne 32 Données retardataires – solution de réémission avec idempotence 12h02 12h11 12h06 12h07 12h09 12h12 12h14 12h15 12h19 12h18 12h17 12h 12h15 12h10 12h05 12h20 12h01 12h03 0 (-2) 1 1 2 2 2 1 1 1 1 (-1) 1 2 1
  33. 33. © 2022 CGI inc. Interne Retour d’expérience – données retardataires Projet Choix • Toute donnée retardataire acceptée • Idempotence garantie via référentiel historisé • Recalcul asynchrone en cas de modification de référentiel dans le passé (coûteux !) Pas de gestion spécifique de la date de l’évènement Pourquoi Retard potentiel de 13 mois (impossible à conserver en mémoire) Le système n’est pas idempotent. Le référentiel courant est utilisé quel que soit la date de la donnée. 33 Conclusion
  34. 34. © 2022 CGI inc. Interne © 20XX CGI inc. Interne Gestion d’erreurs Chapitre 5 © David CLODE/ Unsplash
  35. 35. © 2022 CGI inc. Interne Poison pill 35 1 2 3 1 2 3 > Cas parfait > Introduction d’une pilule empoisonnée 4
  36. 36. © 2022 CGI inc. Interne Premières solutions 36 1 2 5 4 > Redémarrage automatique avec acquittement automatique 1 2 > Acquittement et réduction de la taille des lots 3 4 5 6 7 3
  37. 37. © 2022 CGI inc. Interne Nouvelles expérimentations 37 1 2 3 4 > Skip corrupted (log de l’erreur) 1 2 3 4 > Sentinel pattern (donnée d’erreur annotée exploitable)
  38. 38. © 2022 CGI inc. Interne Quarantaine (Dead Letter Queue) 38 1 3 4 2 +
  39. 39. © 2022 CGI inc. Interne Retour d’expérience – gestion d’erreur Projet Choix • Amélioration de la source RabbitMq • Implémentation acquittement • Limitation de la taille des lots de données • Redémarrage automatique • Mise en œuvre d’un mécanisme de quarantaine • Skip Corrupted pour les erreurs de désérialisation • DLQ Kafka (topics Kafka dédié) pour les erreurs fonctionnelles 39 Conclusion
  40. 40. © 2022 CGI inc. Interne © 20XX CGI inc. Interne Scalabilité et résilience Chapitre 6 © Chetan KOLTE / Unsplash
  41. 41. © 2022 CGI inc. Interne Du bon usage du partitionnement 41 Eléments à traiter Histoire de la fausse bonne idée
  42. 42. © 2022 CGI inc. Interne Du bon usage du partitionnement 42 Eléments à traiter Un meilleur équilibrage de charge
  43. 43. © 2022 CGI inc. Interne Implémentations du partitionnement et de la résilience 43 Server node Server node Server node Cluster Zookeeper Primary Cluster Zookeeper Shared storage (s3, hdfs…) Job Manager Task Manager Task Manager Task Manager Job Manager Job Manager Cluster Kafka Stream Processor Stream Processor Stream Processor Cluster Zookeeper Cluster coordinator
  44. 44. © 2022 CGI inc. Interne © 20XX CGI inc. Interne Comparatif et conclusion Epilogue © Tim FOSTER / Unsplash
  45. 45. © 2022 CGI inc. Interne Capacités fonctionnelles ●●◌ ●●● ●●● Ouverture / interconnexion autres systèmes ●●● ●◌◌ ●●◌ Résilience et scalabilité ●●◌ ●●◌ ●●● Exploitabilité ●●● ●●◌ ●◌◌ Facilité d’apprentissage ●●● ●●◌ ●◌◌ Testabilité & intégration CI/CD ●◌◌ ●●● ●●● Comparaison 45
  46. 46. © 2022 CGI inc. Interne 46 choses sont bonnes ou mauvaises par comparaison » Slides et code
  47. 47. © 2022 CGI inc. Interne ENSEMBLE QUELQUE CHOSE CRÉONS D’INCROYABLE

Editor's Notes

  • Edgar Alan Poe est un romancier et un poète du 19ème siècle.
    Inventeur du roman policier, c’est un style qui met en avant la réflexion, la recherche de pistes souvent fausses mais parfois bonne heureusement, c’est ce que nous vivons au quotidien sur nos projets et que nous voulons vous raconter maintenant
    Il est connu pour la théorie de l’effet qui vise à susciter chez le lecteur une émotion particulière. Cela nécessite un texte ni trop court, ni trop long, chaque syllabe sera choisi consciemment pour susciter l’effet choisi. C’est ce que nous allons essayer de faire pour vous tenir en haleine à travers 2 histoires issues de notre expérience, qui vont parler de traitement de données en temps réel sur des données de forte volumétrie, ce que l’on peut résumer en 2 mots: data streaming.
    Enfin, dans son recueil de nouvelles « Histoires extraordinaires », il cite la phrase suivante : « toutes choses sont bonnes ou mauvaises par comparaison » et c’est un gros spoil de notre conclusion. Mais j’ose espérer que si vous êtes venus là, c’est que vous vouliez connaître les péripéties et avoir un peu plus de détails sur les solutions expérimentées.

  • Mais commençons maintenant nos histoires. Nous allons repartir en arrière, et s’intéresser à la genèse de nos 2 projets, revenir au besoin qui a nécessité la mise en œuvre de data streaming.
  • Histoire commencée il y a 4 ans, grand acteur du transport d’énergie avec qui nous avons mis en place la telérelève de la consommation électrique des grands industriels
    Ouverture du marché ferroviaire à la concurrence, auparavant 1 entreprise ferroviaire et 1 gestionnaire d’infrastructure qui injecte l’électricité
    Nécessité de savoir quelle entreprise ferroviaire a consommé quoi auprès de quel fournisseur d’énergie


    Photo by <a href="https://unsplash.com/es/@sm83?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Peter Scherbatykh</a> on <a href="https://unsplash.com/s/photos/electric-train?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>

    data meter half by Juicy Fish from <a href="https://thenounproject.com/browse/icons/term/data-meter-half/" target="_blank" title="data meter half Icons">Noun Project</a>
    Misirlou from Noun Project
  • https://www.le-tout-lyon.fr/le-reseau-de-chauffage-urbain-de-lyon-duchere-etendu-a-ecully-et-champagne-au-mont-d-or-13921.html

    smart building by LINECTOR from <a href="https://thenounproject.com/browse/icons/term/smart-building/" target="_blank" title="smart building Icons">Noun Project</a>
  • Paserelle IoT Objenious Bouygues Telecom

  • 3 solutions de data streaming ont été mise en œuvre sur les 2 projets :

    Apache Nifi
    Apache Flink
    Kafka Stream

  • Projet de premier niveau de la fondation apache en développement actif
  • Exactly Once 0.11 dans Kafka (https://www.confluent.io/fr-fr/blog/exactly-once-semantics-are-possible-heres-how-apache-kafka-does-it/)
    Numéro de séquence affecté à chaque lot de message pour déduplication
    Transaction atomique
  • Définition: en mathématique ou en informatique, l’idempotence signifie qu’une opération a le même effet qu’on l’applique une ou plusieurs fois.
  • https://developer.confluent.io/learn-kafka/kafka-streams/time-concepts/
    https://nightlies.apache.org/flink/flink-docs-release-1.10/dev/event_time.html
    https://nightlies.apache.org/flink/flink-docs-release-1.10/dev/stream/operators/windows.html#allowed-lateness
    https://beam.apache.org/documentation/programming-guide/#watermarks-and-late-data
  • Attention à la mémoire occupée par traitements fenêtrés
    Juste milieu entre retard accepté et inconsistance
    S’autoriser à refuser une donnée en retard
    Attention au partitionnement (concurrence et ordre)


    Rejeu avec recalcul = long et coûteux
    Minimiser les périodes de temps recalculables
    Challenger le besoin fonctionnel
    Opération asynchrone moins prioritaire
  • (poison pill, relance, rejeu…)
    https://www.confluent.io/fr-fr/kafka-summit-san-francisco-2019/streaming-apps-and-poison-pills-handle-the-unexpected-with-kafka-streams/
    https://www.youtube.com/watch?v=DTEext4DUN0 - Streaming Apps Poison Pill: Comment Kafka-Streams compte faire passer la pilule (Loïc DIVAD)

    4 stratégies:
    Log, crash and restart
    Flink : restart strategy
    Nifi : indépendance des composants, erreurs à brancher obligatoirement
    Skip corrupted
    KafkaStreamDeserializationHandler
    Sentinel value pattern
    Définition d’un élément <null> qui porte l’erreur
    Kafka Stream: extension d’un deserializer
    Dead letter queue pattern
    Topic qui contient les messages corrompus

    A aborder : Schema Registry (Nifi, Kafka)
  • Nifi
    Paradigme Zero master clustering
    Stockage distribué du contenu traité et des métadonnées
    Election de coordinateur et nœud primaire via consensus avec Zk

    Flink
    Election du job manager leader via consensus avec Zookeeper
    Stockage des résultats de jobs et des données de tolérance à la panne sur filesystem partagé

    Kafka Streams
    Kafka Stream est une librairie
    Stream processors indépendants
    Distribution de charge et résilience via fonctionnalités client Kafka
    Stockages sur cluster Kafka


    Flink (https://nightlies.apache.org/flink/flink-docs-master/docs/deployment/ha/overview/) : The JobManager coordinates every Flink deployment. It is responsible for both scheduling and resource management.
    Nifi (https://docs.cloudera.com/HDPDocuments/HDF3/HDF-3.0.2/bk_administration/content/clustering.html)
  • Pour conclure:
    Décompte ferroviaire : priorité au time to market (facilité d’apprenstissage, testabilité, CI / CD), à l’implémentation de plusieurs normes de communication et donc différents formats d’échange
    CRT : priorité à la gestion de volumétrie (scalabilité)

    Autres critères : devops,
    Nifi 16
    Flink 15
    Kafka 15

×