Batch vs Stream : quand quoi

Pourquoi choisir

Tout système de données équilibre entre la fraîcheur (latitude), le coût, la complexité du support et la fiabilité.
Batch - « portions » périodiques de données avec une bande passante élevée et un coût d'enregistrement faible.
Stream : Traitement continu des événements avec un retard et un état minimaux dans la mémoire/les sockets locaux.

Bref sur les modèles

Batch

Source : fichiers/tables/snapshots.
Déclencheur : horaire (heure/jour) ou condition (nouveau fichier de parquet).
Points forts : simplicité, déterminisme, contexte complet des données, grands recalculs bon marché.
Faibles : pas « en ligne », latence élevée, « fenêtres » sans signaux en temps réel.

Stream

Source : courtiers (Kafka/NATS/Pulsar), CDC, files d'attente.
Déclencheur : événement.
Forte : faible latence, réactivité, intégration naturelle avec le produit.
Faibles : complexité du temps (event vs processing), ordre/prise, état, fonctionnement.

Solution : matrice de sélection

Règle 80/20 : Si l'ALS permet des retards de minutes/heures et qu'il n'y a pas de fiches réactives - prenez batch. Si la réaction « ici et maintenant » est critique ou si vous avez besoin de vitrines vivantes - stream (souvent + batch de nuit supplémentaire pour le rapprochement).

Scénarios types

• Reporting quotidien, facturation par périodes, formation ML, grandes joines, déduplication « tout ensemble ».
• Modèle médaillon (bronze/argent/or) avec validation profonde.
• Des bricolages massifs et des vitrines.

• Antifrod/monitoring, alertes SRE, bilan temps réel/missions, recommandations « maintenant ».
• Intégration événement-comme-fait (EDC), mise à jour des représentations matérialisées (CQRS).
• Microservices : notations, webhooks, réactions aux événements commerciaux.

• Le flux forme des vitrines opérationnelles et des signaux ; la bataille nocturne fait le rapprochement, la voûte et les recalculs historiques bon marché.

Architectures

Lambda (Stream + Batch)

Stream pour incrément et en ligne ; Batch pour l'exhaustivité et les corrections.
Avantages : flexibilité et SLA. Inconvénients : double logique, duplication de code.

Kappa (все — Stream + Replay)

Un seul journal comme source de vérité ; batch-recalculs = replay.
Avantages : une base de code, une sémantique unique. Inconvénients : fonctionnement plus difficile, exigences de stockage de la loge.

Hybrid-Pragmatic

Streaming « operation » + jobs batch périodiques pour les joins lourds/ML/corrections.
Dans la pratique, c'est l'option la plus courante.

Heure, ordre, fenêtres (pour Stream)

Reposez-vous sur le temps de l'événement, pas sur le temps de traitement.
Contrôlez watermark et 'allowed _ lateness' ; prendre en charge les retractions/upserts pour les événements tardifs.
Expédier par les clés des unités, planifier les « clés chaudes ».

Fiabilité et sémantique des effets

Batch

Opérations OBD ou remplacement atomique de lots/tables.
L'idempotence est via le calcul deterministe et l'overwrite/insert-overwrite.

Stream

At-least-once + inks idempotent (upsert/merge, versions des agrégats).
Transactionnel « lu-enregistré-enregistré-enregistré la position » pour EOS par effet.
Tables de déduplication par 'event _ id '/' operation _ id'.

Stockage et formats

Batch

Data Lake (Parquet/Delta/Iceberg), OLAP (ClickHouse/BigQuery), stockage d'objets.
Tables ACID pour replace atomique, temps de voyage.

Stream

Logs/thèmes dans les courtiers, stores d'état (RocksDB/embedded), KV/Redis, OLTP pour les projections.
Registre des schémas (Avro/JSON/Proto), modes de compatibilité.

Coût et SLO

Batch : vous payez en « paquets » - bénéfique pour de gros volumes, mais un retard dans l'horaire ≥.
Stream : ressources de rentim permanentes, coût de pointe à QPS élevé ; Mais l'ALS est en secondes.
Comptez p95/p99 latency, la latence de bout en bout, le coût en u.e./événement et le support TCO.

Tests

Général : ensembles golden, invariants property-based, génération d'entrées sales.
Batch : déterminisme, redémarrage idempotent, comparaison des voûtes « avant/après ».
Stream : out-of-order/duplicate, fault-injection entre l'effet et la fixation offset, replay-tests.

Observability

Batch : durée du job, proportion de feels/rétrogras, fraîcheur des vitrines, scan-cost.
Stream : lag par temps/messages, watermark, late-rate, taille state/fréquence checkpoint, taux DLQ.
Partout : 'trace _ id', 'event _ id', versions de schémas/convoyeurs.

Sécurité et données

PII/PCI - Minimiser, crypter at-rest/in-flight, lancer des champs dans les schémas ('x-pii').
Pour Stream, protection state/checkpoint's, ACL sur les tops.
RGPD/droit à l'oubli : dans Stream - crypto-effacement/révision dans les projections ; dans Batch - recalculer les lots.

Stratégies de transition

Batch → Stream : commencez par publier des événements (Outbox/CDC), soulevez une petite vitrine de temps réel sans toucher à la voûte existante.
Stream → Batch : ajoutez des voûtes quotidiennes pour rapporter/rapprocher et réduire la charge de travail sur le streaming.

Anti-modèles

« Tout dans Stream » pour la mode : cher et difficile sans besoin réel.
« Une bataille de nuit géante » avec des exigences de moins de 5 minutes.
Utilisation du temps de traitement pour les métriques métiers.
Les CDC bruts sont comme des événements publics : connectivité dure, douleur dans l'évolution.
Il n'y a pas d'idempotence dans les sinks → de doubles effets sur les restarts.

Chèque de sélection

• SLO de fraîcheur : combien de secondes/minutes/heures est autorisé ?
• Stabilité des entrées : y a-t-il un out-of-order/duplicata ?
• Ai-je besoin de réactions/vitrines en ligne ?
• Coût : rantim 24/7 vs « fenêtre programmée ».
• Méthode de correction : retract/upsert ou recalculer la nuit.
• Équipe et maturité opérationnelle (observabilité, on-call).
• Exigences pour « exactement un effet ».
• Politiques PII/retraite/droit à l'oubli.

Modèles de référence

• Stream : EDC de projection → (KV/Redis, OLTP) pour UI, idempotent upsert.
• Batch : voûte nocturne en OLAP, reconciliation, ML-fiches.

• Stream : fenêtres de session, règles PPE, alertes <1-5 s.
• Batch : réapprentissage des modèles, validation hors ligne.

• Stream : déclencheurs, segments en temps réel.
• Batch : scores, modèles LTV, rapports.

FAQ

Est-il possible d'obtenir un « temps quasi réel » sur batch ?
Oui : les microbatches/jobs de déclenchement (toutes les 1 à 5 minutes) sont un compromis, mais sans la complexité des fenêtres/late-events.

L'approche Lambda est-elle nécessaire partout ?
Non. Si le flux ferme toutes les tâches et que vous savez faire replay - Kappa est plus facile à long. Sinon, un hybride.

Comment compter le coût ?
Résumer compute + storage + ops. Pour Stream, ajoutez le prix d'arrêt « 24/7 » et les nuits d'urgence ; pour Batch, le prix du « retard » de données.

Total

Choisissez Batch lorsque le faible coût, la simplicité et les voûtes périodiques sont importants ; Stream - quand la réactivité et la fraîcheur sont critiques. Dans la pratique, l'hybride gagne : le flux - pour les signaux en ligne et les signaux, le batch - pour l'exhaustivité et les nouveaux calculs historiques bon marché. L'essentiel est de définir le SLO, d'assurer l'idempotence/observabilité et de concevoir à l'avance le chemin des corrections.