Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Alan Poe appliqué au data streaming : "Toutes choses sont bonnes ou mauvaises par comparaison"

Alan Poe appliqué au data streaming : "Toutes choses sont bonnes ou mauvaises par comparaison"

Nous avons 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...

Julien COGNET

January 26, 2023
Tweet

Other Decks in Programming

Transcript

  1. Alan Poe appliqué au data streaming SnowCamp 2023 Toutes choses

    sont bonnes ou mauvaises par comparaison Slides et code
  2. © 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
  3. © 2022 CGI inc. Interne © 20XX CGI inc. Interne

    Besoin Prologue © Braden COLLUM / Unsplash
  4. © 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
  5. © 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
  6. © 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
  7. © 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
  8. © 2022 CGI inc. Interne © 20XX CGI inc. Interne

    Solutions mise en œuvre Chapitre 1 © Olav Ahrens RØTNE / Unsplash
  9. © 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
  10. © 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
  11. © 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
  12. © 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
  13. © 2022 CGI inc. Interne © 20XX CGI inc. Interne

    Identification des données Chapitre 2 © Tarik HAIGA / Unsplash
  14. © 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
  15. © 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
  16. © 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é
  17. © 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
  18. © 2022 CGI inc. Interne © 20XX CGI inc. Interne

    Chapitre 3 Garantie de traitement © Duncan MEYER/ Unsplash
  19. © 2022 CGI inc. Interne Différents types de garantie 21

    EXACTLY once At LEAST once AT MOST once
  20. © 2022 CGI inc. Interne 22 Transactions au sein d’un

    environnement totalement maîtrisé Exactly Once processing > solution 1 Solution choisie par
  21. © 2022 CGI inc. Interne 23 2 phases commit Exactly

    Once processing > solution 2 Solution choisie par
  22. © 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
  23. © 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
  24. © 2022 CGI inc. Interne © 20XX CGI inc. Interne

    Données retardataires Chapitre 4 © Pierre BAMIN / Unsplash
  25. © 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
  26. © 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
  27. © 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
  28. © 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
  29. © 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
  30. © 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
  31. © 2022 CGI inc. Interne © 20XX CGI inc. Interne

    Gestion d’erreurs Chapitre 5 © David CLODE/ Unsplash
  32. © 2022 CGI inc. Interne Poison pill 35 1 2

    3 1 2 3 > Cas parfait > Introduction d’une pilule empoisonnée 4
  33. © 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
  34. © 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)
  35. © 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
  36. © 2022 CGI inc. Interne © 20XX CGI inc. Interne

    Scalabilité et résilience Chapitre 6 © Chetan KOLTE / Unsplash
  37. © 2022 CGI inc. Interne Du bon usage du partitionnement

    41 Eléments à traiter Histoire de la fausse bonne idée
  38. © 2022 CGI inc. Interne Du bon usage du partitionnement

    42 Eléments à traiter Un meilleur équilibrage de charge
  39. © 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
  40. © 2022 CGI inc. Interne © 20XX CGI inc. Interne

    Comparatif et conclusion Epilogue © Tim FOSTER / Unsplash
  41. © 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
  42. © 2022 CGI inc. Interne 46 « Toutes choses sont

    bonnes ou mauvaises par comparaison » Slides et code