Data Mesh : l'avenir de la gestion des données
Les architectures modernes pour les données à grande échelle.
De Kafka à Flink, en passant par Spark Streaming et Kinesis : découvrez comment les architectures de streaming transforment le traitement des données massives en temps réel.
Le streaming de données (ou data streaming) est une technique de traitement de données qui consiste à traiter des flux continus de données au fur et à mesure de leur arrivée, avec une latence très faible (de la milliseconde à la seconde). Contrairement au traitement par lots (batch) qui traite des volumes de données à intervalles réguliers (toutes les heures, tous les jours), le streaming réagit en temps réel.
Le streaming, c'est comme regarder une rivière couler : vous voyez chaque goutte d'eau passer et vous pouvez réagir immédiatement. Le batch, c'est comme vider un lac une fois par jour : vous avez une vue d'ensemble, mais vous perdez la dynamique fine.
schéma illustrant un flux continu de données (capteurs → brokers → applications).
Les entreprises modernes ont besoin de réagir instantanément aux événements : transaction suspecte, panne de machine, tweet viral, variation de prix. Le traitement batch (par lots) introduit une latence inacceptable dans ces cas.
Une transaction bancaire suspecte doit être bloquée avant qu'elle ne soit validée, pas 24h plus tard. Le streaming permet une analyse en millisecondes.
Des capteurs sur une machine d'usine détectent une vibration anormale. Le streaming déclenche une alerte immédiate, évitant une panne coûteuse (maintenance prédictive).
Un client navigue sur un site e-commerce. Le streaming analyse son comportement en temps réel et ajuste les recommandations produits instantanément.
Les tendances Twitter, les likes Instagram, les vues YouTube sont calculés en temps réel grâce à des pipelines streaming.
Une entreprise qui passe du batch au streaming peut réduire son temps de réaction de plusieurs heures à quelques secondes, un avantage concurrentiel majeur.
| Critère | Traitement batch | Traitement streaming |
|---|---|---|
| Latence | Minutes à heures | Millisecondes à secondes |
| Volumes | Très grands volumes (téraoctets) | Flux continu, potentiellement infini |
| Traitement | Périodique (fixe) | Continu (dès réception) |
| Complexité | Plus simple | Plus complexe (état, exactly-once) |
| Cas d'usage | Reporting, analytics, ML batch | Détection de fraude, monitoring, recommandations |
De nombreuses architectures combinent batch et streaming : le streaming pour l'alerte temps réel, le batch pour l'analyse historique. L'architecture Kappa va plus loin : tout est traité comme un flux, y compris le batch.
schéma comparatif batch (intervalles fixes) vs streaming (flux continu).
| Technologie | Type | Points forts | Utilisation typique |
|---|---|---|---|
| Apache Kafka | Message broker distribué | Haute performance, durable, écosystème riche | Collecte et distribution de flux (épine dorsale) |
| Apache Flink | Moteur de traitement | Vrai streaming (pas micro-batch), état, exactly-once | Traitements complexes, fenêtres, état |
| Spark Streaming | Moteur de traitement | Intégration avec écosystème Spark, mature | Micro-batch, bon compromis |
| Amazon Kinesis | Broker + processing (géré) | Fully managed, intégration AWS | Cloud AWS, sans gestion d'infra |
| Google Pub/Sub + Dataflow | Broker + processing | Fully managed, intégration GCP | Cloud GCP, serverless |
| Redpanda | Broker (compatible Kafka) | Plus rapide que Kafka, sans JVM | Alternative moderne à Kafka |
Kafka pour l'ingestion + Flink ou Spark Streaming pour le traitement. En cloud : Kinesis (AWS) ou Pub/Sub + Dataflow (GCP).
collage des logos Kafka, Flink, Spark, Kinesis, Pub/Sub.
Sources (capteurs, logs, apps)
↓
[Message Broker] (Kafka, Kinesis) ← ingestion, buffer, distribution
↓
[Stream Processor] (Flink, Spark) ← transformation, agrégation, fenêtrage
↓
[Sinks] (base de données, data lake, dashboard)Les données arrivent en continu depuis des sources variées (applications web, capteurs IoT, logs serveur, transactions bancaires).
Un broker comme Kafka ou Kinesis collecte les données, les tamponne et les distribue aux consommateurs. Il garantit la durabilité et l'ordre des messages.
Flink ou Spark Streaming applique des transformations : filtres, agrégations, fenêtres (ex: moyenne glissante sur 5 minutes), jointures entre flux.
Les résultats sont envoyés vers des bases de données (PostgreSQL, Cassandra), des data lakes (S3, HDFS), des dashboards (Tableau, Grafana) ou des systèmes d'alerte.
diagramme complet de l'architecture (sources → broker → processing → sinks).
| Entreprise | Cas d'usage | Technologie |
|---|---|---|
| Uber | Suivi des courses en temps réel, calcul des prix dynamiques, matching chauffeur-client | Kafka, Flink |
| Netflix | Recommandations personnalisées en temps réel, monitoring des millions de streams vidéo | Kafka, Flink |
| PayPal | Détection de fraude (analyse des transactions en millisecondes) | Kafka, Flink |
| Airbnb | Pricing dynamique, détection d'anomalies, personnalisation | Kafka, Spark Streaming |
| Fil d'actualité personnalisé, suggestions de connexions | Kafka (créé chez LinkedIn) |
Une transaction bancaire arrive → Kafka la reçoit → Flink analyse en moins de 50ms → Si suspecte, envoie une alerte à un système qui bloque la transaction avant validation.
Garantir qu'un événement n'est traité qu'une seule fois (ni perdu, ni dupliqué). Kafka + Flink offrent cette garantie. C'est complexe, mais critique pour la finance.
Les traitements streaming ont besoin de mémoire de l'état (ex: moyenne glissante). Flink gère l'état de manière performante et permet la reprise après panne.
Si le consommateur est plus lent que le producteur, il faut ralentir l'ingestion ou bufferiser. Kafka gère bien la backpressure.
Définir des fenêtres de temps (tumbling, sliding, session) pour agréger les données (ex: nombre de transactions par minute).
Un pipeline streaming est plus complexe qu'un batch. Des outils comme Prometheus + Grafana sont indispensables pour surveiller latence, débit, état.
Infographie des 6 tendances.
Kafka est un message broker (ingestion, buffer, distribution). Flink est un moteur de traitement (analyse, transformation, agrégation). Ils sont complémentaires : Kafka pour transporter les données, Flink pour les traiter.
Oui. Spark Streaming est mature, a un écosystème riche (Spark SQL, MLlib) et est plus simple à prendre en main. Flink est plus performant pour le vrai streaming (latence plus faible, meilleure gestion de l'état). Le choix dépend du besoin.
Le micro-batch (utilisé par Spark Streaming) découpe le flux en petits lots (ex: toutes les 500ms). C'est plus simple à implémenter, mais la latence est légèrement plus élevée que le vrai streaming (Flink).
Pas obligatoirement. On peut lire directement depuis une source (API, socket) et traiter avec Flink. Mais Kafka apporte durabilité, rejeu, distribution et est devenu le standard de facto.
C'est la garantie qu'un événement est traité exactement une fois (ni perdu, ni dupliqué). Kafka + Flink l'offrent. C'est crucial pour les cas financiers (ne pas débiter deux fois un client).
Non. Le batch reste pertinent pour les analyses historiques, les rapports financiers, les entraînements de modèles ML. Les deux coexistent (architecture Lambda).
Le streaming de données est devenu incontournable pour les entreprises qui veulent réagir en temps réel. Des technologies comme Kafka, Flink et Spark Streaming permettent de traiter des flux continus avec une latence inférieure à la seconde.