Streaming data & Apache Kafka : architecture temps réel

La donnée en temps réel n'est pas un luxe. Pour un nombre croissant de cas d'usage, c'est une exigence business.

Une détection de fraude qui tourne sur les transactions de la veille ne sert à rien. Une personnalisation basée sur le comportement de la semaine dernière rate le moment. Des dashboards opérationnels qui se rafraîchissent toutes les heures ne peuvent pas piloter des décisions en temps réel. La valeur business de la donnée se dégrade avec le temps, et pour certains cas d'usage, elle se dégrade très vite.

Ce qu'est réellement la streaming datastreaming dataDonnées générées et traitées en continu, en temps réel, par opposition au traitement batch, essentielles pour les cas d'usage nécessitant une réponse immédiate (fraude, IoT, trading).

La streaming data est une séquence continue et non bornée d'événements. Contrairement à la donnée en batch (un dataset borné traité à intervalles planifiés), la streaming data circule en continu et doit être traitée avec une faible latence.

Un exemple concret : chaque clic, page vue, ajout au panier et achat sur un site e-commerce est un événement de streaming. Ces événements sont produits par les actions utilisateurs en millisecondes. Les traiter en temps réel permet : la mise à jour du stock en temps réel, le scoring de fraude instantané, la personnalisation live et des dashboards opérationnels.

Apache kafka : la plateforme de streaming dominante

Kafka est le standard de fait pour l'infrastructure de streaming data. Comprendre son architecture :

Topics : des canaux logiques. Les événements sont publiés dans des topics (par exemple « checkout-events », « user-clicks »). Un topic peut avoir de nombreux producers et de nombreux consumers.

Producers : les applications qui publient des événements dans les topics. Votre service de checkout publie un événement « purchase-completed » à chaque commande passée.

Consumers : les applications qui s'abonnent aux topics et traitent les événements. Votre service de détection de fraude consomme les événements « purchase-completed » et score chaque transaction.

Consumer groups : plusieurs consumers peuvent former un groupe et se répartir le travail. Si vous avez un topic avec 10 partitions et 10 instances de consumer, chaque instance traite une partition : scalabilité horizontale.

Retention : Kafka conserve les événements pendant une durée configurable (par défaut : 7 jours). Des consumers tardifs peuvent rejouer l'historique. C'est différent d'une message queue, où les messages consommés sont supprimés.

LinkedIn, où Kafka a été inventé, y traite plus de mille milliards d'événements par jour. Uber, Netflix et Airbnb gèrent chacun des centaines de milliards d'événements par jour via des clusters Kafka.

Stream processing : apache flink et spark streaming

Consommer des événements depuis Kafka est une chose. Les enrichir, les joindre, les agréger et agir dessus en temps réel nécessite du stream processing.

Apache Flink est le moteur de stream processing dominant. Il traite les événements avec une latence inférieure à la seconde, supporte les calculs stateful (maintien de totaux courants, fenêtres de session) et gère proprement les données arrivant en retard.

Apache Spark Structured Streaming est l'approche native de Spark, familière aux équipes qui utilisent déjà Spark pour le batch. Supporte le micro-batch (quasi temps réel) nativement, le vrai streaming avec une complexité plus élevée.

Exemple de cas d'usage : un pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète → de streaming pour la détection de fraude en temps réel :

1. Kafka consomme les événements d'achat depuis le service de checkout
2. Flink enrichit chaque événement avec l'historique client (récupéré depuis un feature storefeature storeRéférentiel centralisé qui gère les features de ML et garantit la cohérence entre les environnements d'entraînement et de production.Voir la définition complète →)
3. Flink applique le modèle de scoring de fraude (sous les 100 ms)
4. Si le score dépasse le seuil, l'événement est publié dans le topic « flagged-transactions »
5. Un service en aval déclenche une revue humaine ou un blocage de carte

L'ensemble du flux s'exécute en moins de 500 ms entre l'événement d'achat et le flag de fraude.

Quand le streaming en vaut (et n'en vaut pas) la peine

Une infrastructure de streaming est nettement plus complexe à construire et à exploiter que du batch. Avant de vous engager :

Le temps réel en vaut la peine quand :

• Les décisions business se dégradent fortement avec la latence des données (fraude, personnalisation live)
• Les processus opérationnels exigent l'état courant (stock, logistique)
• Des fonctionnalités exposées aux clients dépendent de données temps réel

Le batch suffit quand :

• Les charges analytiques n'ont pas besoin de données à jour (rapports hebdomadaires, modèles mensuels)
• Une latence de quelques heures est acceptable
• L'expertise streaming de l'équipe est limitée

La taxe du streaming, complexité d'ingénierie supplémentaire, charge opérationnelle, difficulté de debug, est réelle. Ne la payez que quand la valeur business le justifie.

Quiz Questions

1. Quelle est la principale différence entre le streaming et le batch processing ?

A) Le streaming est toujours plus coûteux

B) Le streaming traite des événements continus avec une faible latence, le batch traite des datasets bornés à intervalles planifiés

C) Le batch ne peut pas gérer de grandes quantités de données

D) Le streaming nécessite obligatoirement Apache Kafka

Réponse: B

1. Dans l'architecture Kafka, qu'est-ce qu'un "topic" ?

A) Un type de message d'erreur

B) Un canal logique auquel les producteurs publient des événements et que les consommateurs lisent

C) Une base de données de streaming

D) Un outil de monitoring

Réponse: B

1. Pour quel cas d'usage le streaming en temps réel est-il absolument nécessaire par rapport au batch ?

A) Rapports hebdomadaires de revenus

B) Modèles de prévision mensuels

C) Détection de fraude en temps réel lors des transactions

D) Consolidation des données comptables

Réponse: C