Architecture Streaming temps réel : Kafka, Avro et Évolution de Schémas

Contexte et Vision Globale : Le Vrai Défi du Streaming

Dans le cadre de mon apprentissage continu des domaines de la data, j’ai voulu tester et consolider ma compréhension du streaming. J’ai réalisé une chose importante : lorsqu’on parle de streaming, on parle de temps réel. Et selon moi (et les recherches que j’ai menées), c’est l’un des concepts les plus mal compris par les Data Engineers juniors, ce qui conduit souvent à de mauvaises implémentations.

Le streaming a des domaines d’application très précis et critiques, comme la détection de fraude dans le secteur bancaire. J’ai constaté que le véritable différenciateur dans ces systèmes, c’est le délai (la latence). Plus le délai de traitement est court, plus la résolution du problème est efficace. Mais cela m’a amené à me poser une question technique fondamentale: comment un système en temps réel peut-il gérer de manière autonome les changements brusques d’état et les variations de structure de données lors du chargement, sans faire planter tout le pipeline ?

L’Enjeu : Tolérance aux Changements en Temps Réel

Pour illustrer et comprendre ces mécanismes fondamentaux, j’ai décidé de mettre en place une architecture simple de production, consommation et visualisation en streaming. Le but n’était pas de créer un système de production d’une complexité absolue, mais plutôt de comprendre comment les concepts interagissent ensemble. Je me suis concentré sur trois piliers : la gestion des changements de schémas de données, le mécanisme de stockage adapté au streaming, et la visualisation en temps réel via un dashboard.

D’un point de vue infrastructure, j’ai choisi de conteneuriser via Docker les trois composants centraux (Kafka, MongoDB et le Dashboard) pour faciliter le déploiement et isoler les environnements. Pour l’instant, mon script Producteur et mon script Consommateur, rédigés en Python, tournent localement. Une évolution logique et future de ce projet sera de les conteneuriser également afin de garantir la portabilité totale de l’environnement.

Architecture et Flux de Données

Le pipeline que j’ai mis en place est direct et efficace. Nous avons d’abord le Producteur Python qui génère des événements utilisateurs simulés (des clics, des interactions) toutes les 2 secondes. Ces événements sont envoyés vers Apache Kafka, qui agit comme le chef d’orchestre : il ingère le flux de données de manière asynchrone et le distribue aux consommateurs abonnés.

De l’autre côté, le Consommateur lit les messages depuis Kafka et les insère dans une base de données MongoDB. Enfin, le Dashboard se connecte à MongoDB pour requêter et afficher ces données fraîches. Si j’ai choisi MongoDB pour le stockage en temps réel, c’est pour une raison très précise liée au streaming : sa nature NoSQL orientée document offre une flexibilité indispensable pour absorber des schémas de données qui évoluent à la volée, sans avoir à exécuter des requêtes ALTER TABLE bloquantes.

Le Cœur du Projet : Apache Avro et Schema Registry

La vraie valeur de ce projet réside dans la gestion de l’évolution des schémas. Dans la vraie vie, l’application source évolue : on ajoute des champs, on en supprime. Pour simuler cela, mon Producteur génère deux versions de données : 30% utilisent un schéma V1 et 70% utilisent un schéma V2.

Pour gérer cela proprement, on ne peut pas envoyer du JSON brut dans Kafka au risque de casser le consommateur. J’ai donc utilisé le format Apache Avro (.avsc). C’est un format de sérialisation binaire, extrêmement gourmand en performances mais très léger, qui oblige la donnée à respecter un contrat (un schéma). Documentation Avro.

Couplé à Kafka Schema Registry, le système gère les versions automatiquement. Le schéma V1 contient les champs de base : user_id, event_type, event_timestamp, et des metadata (device, location). Le schéma V2 est une évolution directe : il reprend la V1 et y ajoute un champ browser. La subtilité ici est la rétrocompatibilité : ce nouveau champ est défini comme optionnel, ce qui permet au système de continuer à accepter les messages V1 sans générer d’erreur.

Consommation Intelligente et Stockage Flexible

Côté réception, le Consommateur Python ingère les messages. Grâce au Schema Registry, il détecte automatiquement si le message entrant est au format V1 ou V2, le désérialise, et l’enrichit en y ajoutant un champ received_at (le timestamp d’arrivée dans le système).

Le document est ensuite poussé dans la collection events de la base de données streaming_db sous MongoDB. Voici à quoi ressemble la structure finale d’un document V2 stocké :

{
  "user_id": "user_3",
  "event_type": "CLICK",
  "event_timestamp": 1738800123456,
  "metadata": {
    "device": "mobile",
    "location": "Paris"
  },
  "browser": "Chrome",
  "received_at": "2026-02-09T14:30:23.456Z",
  "schema_version": "v2"
}

Bilan des Apprentissages

Ce projet a parfaitement validé mon hypothèse de départ. J’ai pu observer en temps réel que le pipeline ne s’effondre pas lorsqu’une nouvelle version de la donnée est poussée en production.

En maîtrisant la sérialisation Avro et la validation via Schema Registry, j’ai compris comment on sécurise un flux de streaming contre les données mal formées. J’ai également confirmé que le choix de la base de données cible (ici MongoDB) est intimement lié à la nature de la donnée entrante. C’est une architecture résiliente, prête à absorber les aléas de la production avec une latence minimale.

Liens pertinents

• Spécifications Avro : Documentation Apache Avro
• Gestion des schémas : Confluent Schema Registry
• Code Source : Mon dépôt GitHub de l’architecture streaming

Récapitulatif des apprentissages

• Gouvernance de la donnée en mouvement : Utilisation d’Apache Avro et de Schema Registry pour garantir l’intégrité et la rétrocompatibilité des données en temps réel.
• Architecture Découplée : Mise en œuvre du paradigme Pub/Sub avec Kafka pour séparer logiquement la production d’événements de leur consommation.
• Flexibilité NoSQL : Exploitation de MongoDB pour stocker un flux de données polymorphe (documents V1 et V2 cohabitant dans la même collection).
• Déploiement : Conteneurisation de l’infrastructure critique (Kafka, Zookeeper, MongoDB) via Docker pour simuler un environnement reproductible.
• Vision de l’évolution : Conception d’une architecture capable d’absorber les changements de schémas sans interruption, un pilier essentiel pour tout système de streaming en production.