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

Alan Poe appliqué
au data streaming
SnowCamp 2023
Toutes choses sont bonnes ou
mauvaises par comparaison
Slides et
code

© 2022 CGI inc. Interne
Edgar Allan Poe
1809 - 1849
© Nong V / Unsplash

© 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

© 20XX CGI inc. Interne
Besoin
Prologue
© Braden COLLUM / Unsplash

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

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

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

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

Solutions mise
en œuvre
Chapitre 1
© Olav Ahrens RØTNE / Unsplash

• 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

• 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
12

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

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

Identification des données
Chapitre 2
© Tarik HAIGA / Unsplash

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

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
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

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
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é

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

Chapitre 3
Garantie de
traitement
© Duncan MEYER/ Unsplash

Différents types de garantie
21
EXACTLY once
At LEAST once
AT MOST once

Transactions au sein d’un environnement totalement maîtrisé
Exactly Once processing > solution 1
Solution choisie par

2 phases commit
Solution choisie par

Orchestration (Supervision et rejeu avec idempotence / sagas)
Superviseurs applicatifs
Routeur
de flux
Orchestrateur
Archivage
3
Services de
traitement
1
2

Idempotence
25
Action
idempotente
Action
non
idempotente

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

Données
retardataires
Chapitre 4
© Pierre BAMIN / Unsplash

Différentes notions de date
Compteur
intelligent
Stream
processors
Event Time Processing Time
Ingestion Time
Entrée du système
de traitement

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

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

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

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

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

Poison pill
35
1 2 3
1 2 3
> Cas parfait
> Introduction d’une pilule empoisonnée
4

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

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)

Quarantaine (Dead Letter Queue)
38
1 3 4
2
+

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

Du bon usage du partitionnement
41
Eléments à traiter
Histoire de la fausse bonne idée

Du bon usage du partitionnement
42
Eléments à traiter
Un meilleur équilibrage de charge

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

Capacités fonctionnelles ●●◌ ●●● ●●●
Ouverture / interconnexion autres systèmes ●●● ●◌◌ ●●◌
Résilience et scalabilité ●●◌ ●●◌ ●●●
Exploitabilité ●●● ●●◌ ●◌◌
Facilité d’apprentissage ●●● ●●◌ ●◌◌
Testabilité & intégration CI/CD ●◌◌ ●●● ●●●
Comparaison
45

choses sont
bonnes ou
mauvaises
par
comparaison
»
Slides et
code

ENSEMBLE
QUELQUE CHOSE
CRÉONS
D’INCROYABLE

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

Recommandé

Recommandé

Contenu connexe

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

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

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

Notes de l'éditeur