Batch vs streaming choisir pragmatiquement

Le streaming n’est pas un trophée à collectionner. C’est une solution complexe et coûteuse qui ne se justifie que si la fraîcheur de la donnée change une décision métier. Pour la majorité des cas d’usage analytiques, un traitement par lots (batch) est plus simple, plus robuste et moins cher. Quand les deux sont nécessaires, le piège est de maintenir deux logiques de code distinctes. L’approche pragmatique est de garder une source de vérité unique pour la logique de transformation.

prérequis

Avoir défini le délai de décision : le temps maximum acceptable entre un événement et l’action qu’il déclenche.
Connaître les volumes de données et les fenêtres d’agrégation nécessaires (ex: “somme des ventes par minute sur la dernière heure”).
Disposer d’un outil capable de gérer le streaming de manière robuste (ex: Flink, Spark Streaming, ksqlDB).

idées clefs

Le sla métier guide le choix: La technologie est une conséquence du besoin métier, pas l’inverse. Si une donnée vieille d’une heure ne change rien, le batch est la bonne réponse.
Une seule source de vérité pour la logique (architecture kappa): Le cauchemar de la double logique (une pour le batch, une pour le stream) mène à des divergences silencieuses. La meilleure approche est d’avoir un code unique qui peut traiter à la fois des données en flux et des données historiques.
Tests sur les fenêtres temporelles: La complexité du streaming réside dans la gestion du temps (données en retard, fenêtres qui se chevauchent). Des tests rigoureux sur ces cas de figure sont non-négociables.

pas à pas

étape 1: cadrer le besoin métier

C’est une simple discussion à avoir avec les équipes métier. La question n’est pas “voulez-vous du temps réel ?”, mais plutôt :

Quelle décision cette donnée permet-elle de prendre ?
Quelle est la valeur d’avoir cette information en 5 secondes par rapport à 15 minutes ou 1 heure ?
Si le délai de 15 minutes est acceptable, un traitement par lots (batch) orchestré toutes les 15 minutes est infiniment plus simple.

étape 2: implémenter une logique partagée

Pour éviter la double maintenance, la logique de transformation doit être définie une seule fois. Des outils comme Flink SQL ou dbt sur des moteurs de streaming permettent d’écrire une logique agnostique qui fonctionnera pour le batch (backfill) et le streaming.

-- Cette requête de somme sur une fenêtre glissante (tumbling window)
-- est la même en Flink SQL qu'elle soit exécutée sur un flux Kafka (streaming)
-- ou sur un fichier Parquet dans S3 (batch).

SELECT
    window_start,
    window_end,
    source_ip,
    COUNT(*) AS request_count
FROM TABLE(
    TUMBLE(TABLE events, DESCRIPTOR(event_ts), INTERVAL '5' MINUTE)
)
GROUP BY
    window_start,
    window_end,
    source_ip;

étape 3: planifier la réconciliation (backfill)

Même dans une architecture streaming, il y aura des moments où il faudra recalculer l’histoire (correction de bug, changement de logique). Le système doit permettre de relire les événements bruts depuis leur source (ex: un topic Kafka avec une longue rétention, ou un data lake) et de les ré-appliquer à travers la logique de transformation unique.

exemples concrets

cas 1: reporting financier mensuel (batch)

besoin: Le département finance a besoin du chiffre d’affaires consolidé pour le mois précédent.
délai: J+5 jours ouvrés.
solution: Un simple job batch (dbt, Spark) qui tourne une fois par nuit est largement suffisant. Le streaming serait une complexité inutile et coûteuse.

cas 2: détection de fraude à la transaction (streaming)

besoin: Bloquer une transaction par carte de crédit si elle est jugée frauduleuse.
délai: Moins de 2 secondes.
solution: Un pipeline de streaming est obligatoire. Il consomme les transactions, les enrichit avec des features calculées en temps réel (ex: nombre de transactions de l’utilisateur sur la dernière minute) et appelle un modèle de machine learning.

pièges fréquents

Symptôme: Deux développeurs passent une semaine à chercher pourquoi le dashboard temps réel et le rapport batch ne donnent pas le même chiffre.
- Cause: Double maintenance de la logique de calcul.
- Correctif: Adopter une librairie ou un framework commun (ex: Flink, dbt) pour définir la logique une seule fois.
Symptôme: Les agrégats en streaming sont incorrects à cause de données qui arrivent en retard.
- Cause: Mauvaise gestion des fenêtres temporelles et des “watermarks”.
- Correctif: Utiliser le temps de l’événement (event-time) plutôt que le temps de traitement (processing-time). Mettre en place des watermarks pour permettre au système d’attendre les données en retard avant de finaliser un calcul.
Symptôme: Le pipeline de streaming est instable et nécessite des redémarrages constants.
- Cause: Pas de gestion de l’état (state management) ou pas de “checkpointing”.
- Correctif: Utiliser un framework de streaming robuste (comme Flink) qui gère l’état de manière distribuée et tolérante aux pannes, permettant de reprendre le traitement là où il s’est arrêté sans perte de données.

faq

Le streaming est-il toujours plus cher que le batch ? Oui, en général. Un pipeline de streaming nécessite des ressources de calcul allumées 24/7 pour traiter les messages à faible latence, alors qu’un pipeline batch ne consomme des ressources que pendant sa courte fenêtre d’exécution.
Puis-je commencer en batch et évoluer vers le streaming plus tard ? Oui, c’est même l’approche la plus pragmatique. En choisissant des outils qui supportent les deux paradigmes (comme Spark ou Flink), vous pouvez commencer avec un simple job batch et, si le besoin de fraîcheur se justifie, le “transformer” en un job de streaming en changeant simplement la source de données (d’un fichier à un topic Kafka).

Menu