Data in Motion Tour 2022 - Paris

1. Tartine — Pixelle
Refonte de l’ingestion — présentation de l’architecture

2. Agenda

3. • WayKonect, qui sommes-nous
• Pourquoi devons-nous évoluer
• De quoi avons-nous besoin
• Nouvelle architecture
• Kafka for the Dummies
• Merci
Tartine-Pixelle — agenda

4. Présentation
WayKonect

5. GREENTECH DE LA MOBILITÉ

6. GreenTech de la mobilité
• Être exemplaire en termes de sécurité des
collaborateurs et des données
• Faire de WayKonect une « low carbon
company »
• Être un acteur local reconnu
en matière de développement durable
Une entreprise humaine
et responsable
NOS
VALEURS
D’ENTREPRISE
NOS
SOLUTIONS
POUR
NOS
CLIENTS
• Être une entreprise où il fait bon vivre
• Développer une équipe engagée prête
à défendre notre stratégie et nos valeurs
• Être reconnu sur le marché et dans
la compagnie comme un expert de la data au
service de la mobilité responsable
Une équipe soudée et fière
de participer à la révolution énergétique
• Contribuer à réduire l’empreinte carbone et
renforcer la sécurité de la mobilité.
• Développer notre capacité d’innovation et
renforcer notre culture Data driven
• Développer des solutions modulables,
ouvertes, 100% digitales
• Avoir des produits rentables
Concevoir des solutions
Innovantes, performantes et durables
• Créer une relation de proximité avec nos
clients pour concevoir et faire évoluer nos
solutions
• Avoir des clients satisfaits et promoteurs
de nos solutions
• Délivrer de la valeur à chaque itération
Le client au cœur
de nos décisions
NOS
VALEURS
D’ENTREPRISE
NOS
SOLUTIONS
POUR
NOS
CLIENTS

7. Une proposition de solutions riches et complètes
Parcours digitaux
Véhicules Electriques
Connect
Car sharing
Parcours digitaux
Mobility Corporate

8. Pourquoi
devons-nous
évoluer

9. Contexte — l’ingestion ? koi cé t’esk?
• L'ingestion joue un rôle majeur dans la structure Iot de la solution du portail Mobility
Business: elle est responsable de l'essentiel des traitements d’intégration des données de
télématique.
• La solution comportait certains défauts. De la performance à la fiabilité, l'ingestion devait
être renforcée, repensée pour pouvoir évoluer.
• Pour atteindre ses objectifs, l’architecture doit évoluer en permanence
• Dans sa version actuelle, l'ingestion lit les informations de plusieurs fournisseurs de
données de télémétrie de véhicules (boitiers sur prise Obd, ou système préembarqué du
constructeur automobile)
• L'ingestion gère actuellement de nombreux concepts fonctionnels et déclenche de
nombreux processus externes

10. Contexte — Architecture actuelle

11. Contexte — quels problèmes résoudre
Que faut-il faire avec l’ingestion pour que cela fonctionne:
- Les autres concepts métiers et fonctionnels doivent être retirés et pris en charge au sein traitements séparés.
- La logique itérative de ces processus actuellement au sein de l'ingestion est une cause principale des différentes préoccupations identifiées :
ü Montée en charge limitée par les choix techniques initiaux.
ü Gestion des erreurs techniques complexes.
ü Interfaçage avec un modèle de donnée en graph .
ü Complexité de la maintenance de la solution initiale.
ü L'ingestion, écrite en 'C#,' est actuellement hébergée sur un cluster Azure Service Fabric ce qui implique un accès contraint aux journaux d’application (Logs)
ü Montée en capacité limitée
Au centre de ces notions d'entreprise se trouve celle de voyage, ou trajets J
L'ingestion doit être le seul processus à gérer ces derniers.
Autrement dit, l’ingestion devrait être un Micro Service
Comme vous pouvez le voir, l'ingestion est ce que l’on appelle un point de défaillance unique

12. De quoi
avons-nous
besoin

13. - Un outil capable de centraliser les flux de données provenant des systèmes externes ou au sein de l’entreprise.
- Un système distribué capable d'évoluer horizontalement
- Un système capable de lire tout type de flux de données (JSON, binaire pur, etc.)
- Un système capable de prendre en charge des vitesses très élevées pour la publication ou la lecture de données.
- Le rythme actuel relevé auprès de notre principal prestataire de données est de 400 000 messages / minutes
- 1 message représente 8000 enregistrements
- Nous avons plusieurs milliers de boitiers roulant simultanément aujourd’hui.
- Une télémétrie (mesure enregistrée sur un véhicule) pour un boitier d’usage basique c’est 150 champs
- Une télémétrie (mesure enregistrée sur un véhicule) pour un boitier d’usage prémium c’est 500 champs
- Ce produit doit supporter la consommation d'un flux de données par de multiples consommateurs,
- Il faut s’assurer d’un découplage des systèmes producteurs et consommateurs de données,
la défaillance de l’un ne doit pas impacter l’autre
- Il faut permettre la consommation de messages en temps réel et en mode batch.
Besoin 1 : La réception des données
Nous devions trouver un système de messagerie distribué en mode Producteur — Consommateur, capable de s'adapter
facilement, de supporter des débits de données très élevés et d'assurer la persistance des données qu'il reçoit.

14. Réponse 1 — Kafka
Nous devions trouver un système de messagerie distribué en mode Producteur — Consommateur, capable de
s'adapter facilement, de supporter des débits de données très élevés et d'assurer la persistance des données qu'il
reçoit.
Ø Créer en 2010 à LinkedIn pour gérer les envois de batch et
l’analytique temps-réel
Ø Besoin d’avoir un système performant capable de gérer des
volumétries importantes de manière Scrabble (près de 2 000
milliards de messages par jour traités par 1 800 serveurs)
Ø Technologie mature utilisée dans de nombreuses organisations
(Twitter, Netflix, Uber, EDF, Société Générale, etc.)
Ø Solution OpenSource avec une déclinaison « Entreprise » avec
support proposé par Confluent

15. Besoin 2 : Granularité des process
- Nous avions un processus très monolithique assurant plusieurs responsabilités et traitements.
- Ces services devaient être séparés en un ensemble de microservices ou de traitements laissant à l'ingestion son rôle de la
gestion des trajets
- Lorsqu’une information de trajets est traitée, les autres services dépendant du trajet doivent être informés de la disponibilité
de cette dernière pour pouvoir être traités suivant leur propre process
SANS IMPACTER LA GESTION DU TRAJET LUI-MÊME

16. Réponse 2 — Docker/Kubernetes …
- Nous avons un microservice trajet qui porte l’ensemble des appels (API)
- Un Topic Kafka recevra les informations pivots des boitiers
- Le process de gestion interne Kafka Stream traite l’identification d’un trajet et son fenêtrage, traitement in event
- Ce microservice est écrit dans un langage conteneurisable pour pouvoir être intégré dans l’architecture kubernetes
- Les données de trajets seront persisté non plus sur un modèle de donnée en graph, mais sur une base de données PostgreSQL, afin de
profiter des capacités géospatiales de ce dernier

17. Réponse 2 bis — … et Kafka Stream !
Kafka Streams, mais encore ?
- Il s’agit d’une librairie embarquée dans le cluster Kafka dont le but est de traiter ou d’analyser les données présentes dans des topic Kafka, puis de les
faire ressortir dans un nouveau topic Kafka ou dans un service externe (une base de données, par exemple).
- Disponible depuis la version 0.10 de Kafka, cette librairie à de nombreux avantages :
ü Aucune dépendance externe autre que Kafka
ü Librairie simple et légère
ü Fault tolérant et scalable
ü Traitement de la donnée event-time (contrairement aux approches microbatch)
Performance
- En plus de proposer une installation simple et rapide, l’API proposée par Confluent offre de très hautes performances, car elle utilise les mécanismes de Kafka et
son système de partitionnement pour consommer les évènements; ceci garantit une grande performance des applications, une scalabilité ainsi que le respect de
l’ordre d’arrivée des données.
- De plus, la particularité clé de cette librairie réside dans son architecture. La plupart des applications de stream processing classiques nécessitent l’installation d’un
cluster dédié au traitement de la donnée en plus de Kafka (Kafka + Spark streaming par exemple), comme les applications Kafka se lancent via une ligne de
commande, les ops et les développeurs n’auront plus à monter, maintenir et tuner un cluster supplémentaire en plus de Kafka.
- De même, toutes les améliorations faites dans un cluster Kafka se feront ressentir au niveau de Kafka Streams.
- Enfin, l’emploi du traitement de la donnée event-time au lieu de microbatchs assure un temps de latence du traitement de la donnée extrêmement faible.
Et la panne ?
La librairie est basée sur la tolérance à la panne embarquée dans Kafka, les partitions se veulent hautement disponibles et répliquées. Cette réplication
permet, en cas de panne, de redémarrer une tâche à partir de son “point-of-failure” dans une instance déjà existante.

18. Nouvelle
Architecture

19. Tartine-Pixelle — architecture cible lot 1

20. Tartine-Pixelle — on explique
- Les données brutes des boitiers transitent par des bus de messages en entrée, pour bénéficier de
performances en adéquation avec l’ensemble de la solution proposée, sachant que la limite maximale d’un
message sur un topic Kafka est de 7 Mo, on autorise des volumes d’informations par message important,
toutefois pour Kafka plus le message est petit mieux c’est J
- Service Bus,
- SQS,
- Rabbit Mq
- etc..
- Microservice(s) Parser(s): Service de transcodage des données des boitiers qui formate les messages à
notre format pivot, ces données sont envoyées un topic principal qui centralise l’ensemble des télémétries de
tous les fournisseurs de données
- Le processus Kafka stream qui est attaché au topic central des télémétries qui est capable d’extraire les
trajets des véhicules depuis les données de télémétries
- Microservice Trip qui est un consommateur des topics de sorti du processus kafka stream, ce
microservice consommateur va enrichir les données de trajets avec d’autres informations utiles pour identifier
le trajet est son/ses acteurs

21. Tartine-Pixelle — tester n’est pas douter
(désolé CommitStrip J )
- Extraction des jeux de test depuis les bus (filtrage des données sur des méta-informations)
- Extraction des jeux de test depuis les topic via Kafka Stream, Kafka-Connect (duplication de topic filtré)
- Création de topic spécifiques pour jouer des tests au niveau de toutes les fonctionnalités (tests unitaire, tests d’intégration,
et les tests de charge au niveau de la source de données
- Rétention des données sur les topic de test limitée à la durée des tests
- Jouabilité infinie des tests par déplacement de la tête de lecture (Offset de la partition/topic)

22. Tartine-Pixelle – La data
Registre de schémas (Schema Registry)
- Les producteurs Kafka écrivent des données dans les Topic et les consommateurs lisent les données des Topic.
- Il existe un « contrat » implicite selon lequel les producteurs écrivent des données avec un schéma pouvant être lu par les consommateurs, même lorsque les
producteurs et les consommateurs font évoluer leurs schémas.
- Schema Registry permet de s'assurer que ce contrat est respecté avec des contrôles de compatibilité. Il est utile de considérer les schémas comme des API.
- Les applications dépendent des API et s'attendent à ce que toutes les modifications apportées aux API soient toujours compatibles et que les applications puissent
toujours s'exécuter.
- De même, les applications de streaming dépendent des schémas et s'attendent à ce que toutes les modifications apportées aux schémas soient toujours compatibles et
peuvent toujours s'exécuter.
- L'évolution du schéma nécessite des contrôles de compatibilité pour s'assurer que le contrat producteur-consommateur n'est pas rompu.
- C'est là que Schema Registry est utile : il fournit une gestion centralisée des schémas et des contrôles de compatibilité à mesure que les schémas évoluent.
- Les données typées sont validées par les propriétaires des données en accord avec les prérequis recommandés par le comité de gouvernance de la donnée, et
documentés dans le registre central de données

23. Tartine-Pixelle – La data dans les faits
Alimentation du futur data Lake
- Le data Lake est alimenté par Kafka à travers le topic « donnée de télémétries»
- Le topic calibré pour assurer la résistance à la perte de données.
- La consommation du topic (pour déversement ADLS 2) se fait à travers Kafka-Connect en mode distribué (plusieurs tâches en parallèle.
- Les équipes Data consommeront les données dans Azure Data Lake

24. - Ces mécanismes rendent l'ingestion plus facile à maintenir, réduisent sa responsabilité à son rôle seul à savoir la création
de trajets
- Cela rend le système plus robuste et tolérant face aux défauts de l'un des composants
- La montée en charge est garantie par l’implémentation de métrique métiers qui déclenchent des processus
automatiques de redimensionnement des composants
- L'ensemble des fonctions nécessaire à transformer des télémétries en trajet sont devenues modulaires, tout nouvel ajout
de fonctionnalité résultant de la gestion d'une information pour un trajet est abonné à un topic qui est alimenté par un
message du microservice Trajet ou un process Kafka Stream.
- Enfin, l'adhérence entre les fonctionnalités à été fortement réduite
- Nous pouvons définir une SLA métier sur ce sous-ensemble, calcul résultant des SLA techniques fournisseur (Azure
Service Bus 99,9%, Confluent Kafka dédie 99,95% ) et de mesure résultant d’un monitoring des messages au sein du
cluster Kafka
Tartine-Pixelle — gains attendus

25. Tartine-Pixelle — un peu de chiffres
Dimensionnement de cluster Confluent Kafka dédié (Production)
L’unité de facturation pour un serveur dédié est la CKU, qui représente un ensemble de métriques disponible par unité, la limite supérieure est de 24 CKU par cluster dédié.
Les clusters à zone unique peuvent avoir 1 ou plusieurs CKU, tandis que les clusters multizones nécessitent un minimum de 2 CKU et offrent une haute disponibilité. La disponibilité de la
zone ne peut pas être modifiée une fois le cluster créé.
Dimension Maximum per CKU
Ingress ~50 megabytes per second (MBps)
Egress ~150 megabytes per second (MBps)
Storage (pre-replication) Infinite (billing limited J)
Partitions (pre-replication) 4,500 partitions
Total client connections ~3,000 connections
Connection attempts 250 connection attempts per second
Requests ~15,000 requests per second

26. Kafka for the
dummies

27. Kafka — Concepts de base !
Multisouscription
Throughput élevé
Scalabilité
Consommation batch et
temps réels
Haute disponibilité
Robustesse
Rétention de données

28. Le concept de cœur de Kafka repose sur les logs!
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
……
1er record
Dernier record écrit
Source donnée
Application A (offset 7) Application B (offset 12)
lecture lecture
Publication
Souscription
Kafka — Log,log,log,log………….

29. Topic
Ø Les données écrites dans Kafka sous forme de record
Ø Kafka est très bien adapté pour des messages de petite taille (1ko < taille < 7Mo).
Ø Un record est fait par un couple « Clé », « Valeur ».
Ø Un record appartient à un topic.
Ø Un topic est partitionné par 1 ou n partitions.
Record
0
1
2
Partition
Kafka — Record, Partition, Topic
Record en offset 12 de la partition
1 du topic

30. Kafka – Broker, Producer, Consumer
Ø Le cœur de Kafka est constitué de broker Kafka
Ø Les Producers poussent (push) les données aux brokers
Ø Les Consumers souscrivent (pull) à un ou plusieurs topics pour lire les données dans les brokers
Producer Producer
Consumer Consumer
Broker 1 Broker 2 Broker 3 Broker 4

31. Kafka – produire et souscrire
Ø Il est très simple de produire ou de consommer des messages Kafka
Ø Kafka propose des clients Java, Python, C/C++, C#, Go et bien d’autres langages hétéroclites avec une API très simple
Ø .
Ø Kafka par le biais d’un de ses composants permet également de lire et de produire des messages à travers des services
API REST (Kafka REST).

32. Kafka — Cluster Kafka
Ø Le cluster Kafka est formé de l’ensemble des nœuds Broker.
Ø Un Broker héberge un ou plusieurs partitions pour un ou plusieurs topics
À quoi servent les partitions ?
Ø Les partitions permettent de paralléliser l’exposition des données (sharding).
Ø Producer, écrivant dans un topic, va écrire dans les partitions du topic.
Ø On peut choisir la stratégie d’écriture du producer (également appelé stratégie de
partitionnement)
Ø L’augmentation du nombre de partitions permet à plus à de consommateurs à souscrire aux
données
Comment Kafka pallie à la perte de données?
Ø Les données sont répliquées plusieurs fois au sein du cluster.
Ø On paramètre le nombre de répliqua souhaité par topic.
Ø Le leader est élu par partitionnement pour un topic donné pour signaler à un Producer la
partition dans laquelle il peut écrire

33. Kafka — Détail sur le TOPIC
Pour chaque consommateur, pour un topic et une partition donnée, Kafka suit les offsets suivants :
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
……
Last committed offset
(du consommateur) Log End Offset (LEO)
Il s’agit du dernier message synchronisé avec les
ISRs. Un consommateur peut consommer sans
inquiétude tout record avec un offset inférieur.
Le consommateur communique
régulièrement le dernier offset
du message qu’il a traité
(committed).
Position courante
Offset du dernier message que le
consommateur est en train de
lire
High watermark offset
(HWO)

34. Kafka — Stockage et Rétention de données
Ø Les données sont persisté sur disque sous forme de log.
Ø La durée de la rétention des données est configurable par topic.
Ø La rétention est une mécanique importante, car elle permet de dissocier les modes de production des modes de
consommation.

35. Kafka — Synthèse
Multisouscription
Throughput élevé
Scalabilité
Consommation batch et
temps réels
Haute disponibilité
Robustesse
Rétention de données
Redundancy & fail-over
Garanties & Données
stockées sous forme de
log
Persistance de la donnée
sur disque
Partitions
Transferts directs et
écriture batchée sur
disque
Architecture distribuée
scalable horizontalement
API simple avec de
multiples modes de
conso.

36. Remerciement

37. 37
WayKonect — ACE / Data / CoDir
Je remercie le Comité de direction de WayKonect qui m’a
accompagné dans la prise de décision pour déployer une architecture
novatrice
Qui malgré nos doutes au début de la phase d’étude nous a
soutenus et a suivi nos recommandations
Notre Chief Technology Officer Laurent Gutierrez
qui a suivi la phase d’architectures et nous a accompagné
auprès de Confluent
Nos CEO Aurélia Doublet et Morgan Ferrier
Enfin je remercie les équipes ACE (développement noyau IoT)
et Data de WayKonect qui ont participé aux séminaires préparatoires d’architecture,
ce qui vous a été présenté est un travail fait en complète synergie avec les
équipes qui vont implémenter les briques qui vous ont été présentées,
c’est une condition impérative à la réussite de ce type de projet

38. Kafka — L’équipe de suivi Confluent
Je tiens à remercier toute l’équipe de soutien de Confluent
En particulier les CSTA qui vous permettent d’avancer sur votre
projet, n’hésitent pas à vous challenger, et sont toujours
là pour répondre à toutes vos questions.
Donc merci à Chaz Sarrazin et Olivier Laplace
Mais également deux hommes sans qui nous n’aurions jamais
commencé à mettre les yeux sur confluent:
Florent Ramière, consultant architecte avant vente, tueurs de doutes
Phillipe Amiel notre responsable de compte pour WayKonect

39. THANK
YOU
FOR
WATCHING
Tartine
Pixelle

40. + 3 3 ( 0 ) 3 6 6 7 2 5 6 2 0
W A Y K O N E C T
2 2 5 r u e d e s t e m p l i e r s
5 9 0 0 0 L i l l e ( F r a n c e )