Streaming vs Batch : Compromis d'Architecture
Tous les pipelines de données n'ont pas besoin d'être temps réel. Le choix entre streaming et batch — ou leur combinaison — dépend des exigences de latence, des contraintes de coût et de la tolérance à la complexité opérationnelle.
Vue d'Ensemble
| Dimension | Batch | Streaming |
|---|---|---|
| Latence | Minutes à heures | Millisecondes à secondes |
| Modèle de traitement | Datasets bornés (fichiers, partitions) | Flux d'événements non bornés |
| Complexité | Plus faible — plus facile à déboguer, rejouer, tester | Plus élevée — ordonnancement, exactly-once, backpressure |
| Coût | Paiement par job (start/stop) | Infrastructure toujours active |
| Récupération d'erreurs | Retraiter le batch | Complexe (replay depuis l'offset, dead letter queues) |
| Outils typiques | Spark, dbt, Airflow | Kafka, Flink, Kafka Streams, Kinesis |
Quand le Batch Suffit
- Reporting quotidien/horaire — dashboards rafraîchis sur un planning
- Chargement d'entrepôt — pipelines ELT nocturnes
- Entraînement de modèles ML — entraînement sur données historiques
- Charges sensibles au coût — batch Spark sur instances spot 5–10x moins cher que Flink toujours actif
Quand le Streaming Est Nécessaire
- Détection de fraude — décisions en millisecondes
- Personnalisation temps réel — recommandations pendant la session utilisateur
- Monitoring opérationnel — alertes sur les métriques live
- Microservices événementiels — services réagissant aux événements du domaine
- IoT — traitement continu des données capteurs
Patterns d'Architecture
Architecture Lambda
Exécuter les deux pipelines batch et streaming. Batch pour la précision (retraitement), streaming pour la vitesse. Fusionner dans une couche de service. Inconvénient : maintenir deux codebases pour la même logique.
Architecture Kappa
Streaming uniquement. Retraiter en rejouant le journal d'événements (rétention Kafka). Plus simple à maintenir mais nécessite une infrastructure robuste de traitement de flux.
Medallion avec Streaming
Bronze (événements bruts) → Silver (nettoyés, dédupliqués) → Gold (agrégés). Peut être implémenté en streaming (Flink/Spark Structured Streaming) ou batch (dbt) à chaque couche.
Paysage d'Outils
| Outil | Type | Forces |
|---|---|---|
| Apache Kafka | Plateforme de streaming | Journal durable, écosystème (Connect, Streams, ksqlDB) |
| Apache Flink | Processeur de flux | Vrai streaming, exactly-once, traitement d'événements complexes |
| Spark Structured Streaming | Streaming micro-batch | API unifiée batch+stream, large adoption |
| Kafka Streams | Bibliothèque légère de streaming | Pas de cluster séparé, natif Java/Kotlin |
| AWS Kinesis | Streaming managé | Natif AWS, option serverless (Data Firehose) |
| GCP Dataflow | Runner Beam managé | Auto-scaling, batch+stream unifié |
| Apache Beam | Modèle de programmation unifié | Écrire une fois, exécuter sur Flink/Spark/Dataflow |
Matrice de Décision
| Votre besoin | Approche recommandée |
|---|---|
| Latence > 1 heure acceptable | Batch |
| Latence 1–15 minutes | Micro-batch (Spark Structured Streaming) |
| Latence < 1 seconde | Vrai streaming (Flink, Kafka Streams) |
| Analyse historique et live | Lambda ou Kappa |
| Budget contraint | Batch d'abord, streaming uniquement où nécessaire |
Ressources
- Streaming Systems — Tyler Akidau et al.
- Kafka: The Definitive Guide — Gratuit chez Confluent
- Designing Data-Intensive Applications — Chapitre 11 sur le traitement de flux
- Documentation Flink — Référence pour le traitement de flux stateful
:::